From owner-ietf-url@imc.org Thu Apr 1 09:38:13 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22125 for ; Thu, 1 Apr 1999 09:38:12 -0500 (EST) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA24571 for ietf-url-bks; Thu, 1 Apr 1999 06:26:53 -0800 (PST) Received: from smtpgw02.wanmail.net (smtpgw02.wanmail.net [149.174.10.62]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA24566 for ; Thu, 1 Apr 1999 06:26:52 -0800 (PST) Received: from wcomexch1.wcom.net (wcomexch1.wcom.net [209.154.236.12]) by smtpgw02.wanmail.net (8.9.1/8.9.1) with ESMTP id JAA02325 for ; Thu, 1 Apr 1999 09:26:32 -0500 (EST) Received: by wcomexch1.wcom.net with Internet Mail Service (5.5.2232.9) id <2BBMYP5F>; Thu, 1 Apr 1999 09:28:52 -0500 Message-ID: <9A74C89D6696D2118E500008C7BA7C5601A81B24@wcomexch1.wcom.net> From: "Petke, Rich" To: "'URLREG List'" Subject: [URLREG WG] Procedures Draft - WG Last Call Date: Thu, 1 Apr 1999 09:28:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ietf-url@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi gang - The latest revision of the procedures draft, "draft-ietf-urlreg-procedures-06.txt" has been announced and is now available. (This is NOT an April Fool's joke!) This revision addresses and incorporates comments received to date. The document authors and WG co-chairs believe this revision of the document is ready for WG last call. Accordingly, this message announces the beginning of a WG last call period which will conclude at 5:00 PM (Eastern Time), on April 16, 1999. Unless there are major objections to this revision of the document, the co-chairs intend to present this draft to the area directors along with the statement that the WG has reached [rough] consensus. Also recently announced and available is "draft-ietf-urlreg-guide-05.txt". This revision of the guidelines document only updated the required boilerplate in the heading of the draft and an author's address. Otherwise, the draft is identical to that which was already submitted for WG last call several months ago. This draft references the procedures draft and as such has been held back until the procedures draft was ready. It will be presented to the area directors along with the procedures draft. Please take a few moments to read the procedures draft and post any comments to the list. Thank you, Rich Petke (rpetke@wcom.net) Product Development (pd.inhouse.wcom.net) UUNET Technologies (www.wcom.net) 5000 Britton Road P. O. Box 5000 Hilliard, OH 43026-5000 Voice: +1-614-723-4157 FAX: +1-614-723-8407 From owner-ietf-url@imc.org Wed Apr 7 00:21:10 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24085 for ; Wed, 7 Apr 1999 00:21:09 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA08406 for ietf-url-bks; Tue, 6 Apr 1999 21:06:44 -0700 (PDT) Received: from ixpres.com (AM3-10-53-206.ixpres.com [209.75.53.206]) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA07726; Tue, 6 Apr 1999 20:53:14 -0700 (PDT) Date: Tue, 6 Apr 1999 20:53:14 -0700 (PDT) From: bizusa@ixpres.com Message-Id: <199904070353.UAA07726@mail.proper.com> Reply-To: bizusa@ixpres.com To: bizusa@ixpres.com Subject: Organize Web Info... Sender: owner-ietf-url@imc.org Precedence: bulk List-Archive: List-Unsubscribe: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% This message is sent in compliance of the new Email bill: SECTION 301. Sender: INFOtrepreneur, 11012 Avenida De Los Lobos, San Diego, California, CA 92127 - Fax: (619) 672-1000 Email: webmaster@infotrepreneur.com Per Section 301, Paragraph (a)(2)(C) of S.1618, further transmissions to you by the sender of this email may be stopped at no cost to you by ending a reply to this email address with the word "remove" in the subject line. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% NO MORE! BACKTRACKING OF LOST AND CONFUSING WEB BOOKMARKS AND TEXT DATA FILES... Based upon your Internet interests, I thought that you would be interesed in Web Info Catcher which allows you to capture and store text data from various sources, index, categorize and edit it instantly on screen while online. Access all your reference and source material instantly at a click of a button, while you are working, browsing, searching or offline. It's the fastest, up-to-date, and most efficient means to "RECALL" your data. * No need... to bookmark a multitude of web sites * No need... to search for misplaced or lost text files * No need... to print out endless reports * No need... for a web browser to reference data - Perfect for academics, researchers, business, info junkies, etc. - Create your own projects, reports, topics, favorites, research, etc. - Open numerous projects and setup your own index references - Attach and Capture text information from various sources - Edit your projects - Effectively organize your information - Categorize your information - Add custom indexes - Automatic alpha indexing - Searchable index - Scrollable index - View information on screen while working - A Stand alone program - Add and delete information - Print out data in your own time WHY BOOKMARK OR SAVE YOUR TEXT FILES? DON'T DELAY!  Visit INFOtrepreneur today and discover a whole new way to capture and store your information sources, we will be happy to assist you. DOWNLOAD your software demo: ftp://ftp.infotrepreneur.com/pub/wicdemo.exe OR for more info: http://www.infotrepreneur.com/webcth.htm Sincerely Gail van der Merwe From owner-ietf-url@imc.org Sun Apr 18 18:37:45 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04644 for ; Sun, 18 Apr 1999 18:37:44 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA05647 for ietf-url-bks; Sun, 18 Apr 1999 15:28:02 -0700 (PDT) Received: from unknown (dialuppool.gatecom.net [206.117.220.241]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA05641 for ; Sun, 18 Apr 1999 15:27:51 -0700 (PDT) From: Licensing@CAPIAwards.com To: ietf-url@imc.org Subject: Internet Awards seek TALENT! Date: Sun, 18 Apr 1999 15:29:40 Message-Id: <521.704933.739839@unknown> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-url@imc.org Precedence: bulk List-Archive: List-Unsubscribe: (**ADDITIONAL TEXT VERSION INCLUDED BELOW FOR THOSE WITHOUT HTML EMAIL BROWSERS**)

THE CRITICS ARE UNANIMOUS!...

One Of The Most Exciting Ways To Use The Internet To Bring New Talent To The Attention Of The Hollywood Entertainment And Communications Industries!

KALEIDOSPACE

(MicroTimes Platinum Award Winner)


A Professional Way For Creative New Talent To Present Their Work Directly To The Decision Makers In Our Industry!

MICRO PUBLISHING NEWS


A Truly Great Idea...An Exciting Way For New Talent To Be Seen By The Entertainment Industry In A Professional Manner...Instantly!

P.E.I.

(Photo Electronic Imaging Magazine)


Judged by Award-Winning Producers...Directors...and Artists. Don't Miss This Career Opportunity!

NEW TIMES MAGAZINE


We Wish You The Best Of Luck With The CAPI Awards!

LUCASFILM LTD.



The International CAPI Awards Invite Your Entry

In Our Second Annual International Competition!



The CAPI AWARDS are the World's First Professional Awards of Excellence created by Award Winning Producers and Directors in the Hollywood/Entertainment Industry...dedicated to discovering and honoring the most creative talent on the globe in the fields of Computer Animation... Photography...and Illustration (CAPI) (Website Design Catagory Added This Year!) ...directly through the Internet's World Wide Web!

The CAPI Awards showcases this gifted new talent pool to the Entertainment and Communications Industries by way of a Central Link on the World Wide Web (www.capiawards.com). The CAPI Awards web site displays the Award Winning Entries for easy access by the Top Studios...Advertising Agencies...and Film and TV Producers throughout the World!


CAPI Award Winners receive International Recognition and will be showcased in a Professional Industry Website! Furthermore, the CAPI Awards will actively promote and encourage the Entertainment/Communications Industry to actually license the winners entries for use in Film, TV, Video, Multi-Media, Magazines, and Websites... providing hot new cutting edge talent the opportunity to be discovered... be financially compensated ... and recieve a Professional Award of Achievement!



COMPETITION OPEN TO PROFESSIONALS and AMATEURS!

ENTRY DEADLINE IS MAY 31,1999!


Visit Our Webite To For Entry Information

and Current

Award Winners Gallery

www.capiawards.com




We apologize if you received this valuable information in error.

Tremendous effort has been undertaken to keep our list of referred artists updated and filtered.

We are attempting to get this information to as many artists as possible

due to the enourmous demand for new talent and material.

*****************************************************************************************************

To be removed from our mailing list at no cost to you, simply hit REPLY to:

support@capiawards.com with REMOVE in the subject.

Your name will be removed from our list immediately.

*************************************************************************

This message is sent in compliance of the new e-mail bill: SECTION 301,

Paragraph (a)(2)(C) of s. 1618

Sender : International "CAPI" Awards, 2219 W. Olive Ave., Suite 312, Burbank, CA 91506

Phone : 1-818-372-3635

E-mail : support@capiawards.com






******************************************************** TEXT VERSION BELOW FOR THOSE WITHOUT HTML EMAIL BROWSERS ******************************************************** THE CRITICS ARE UNANIMOUS!... One Of The Most Exciting Ways To Use The Internet To Bring New Talent To The Attention Of The Hollywood Entertainment And Communications Industries! KALEIDOSPACE (MicroTimes Magazine Platinum Award Winner) A Professional Way For Creative New Talent To Present Their Work Directly To The Decision Makers In Our Industry! MICRO PUBLISHING NEWS A Truly Great Idea...An Exciting Way For New Talent To Be Seen By The Entertainment Industry In A Professional Manner...Instantly! P.E.I. (Photo Electronic Imaging Magazine) Judged by Award-Winning Producers...Directors...and Artists. Don't Miss This Career Opportunity! NEW TIMES MAGAZINE We Wish You The Best Of Luck With The CAPI Awards! LUCASFILM LTD. The International CAPI AwardsInvite Your Entry In Our Second Annual International Competition! The CAPI AWARDS are the World's First Professional Awards of Excellence created by Award Winning Producers and Directors in the Hollywood/Entertainment Industry...dedicated to discovering and honoring the most creative talent on the globe in the fields of Computer Animation... Photography...and Illustration (CAPI) (Website Design Catagory Added This Year!) ...directly through the Internet's World Wide Web! The CAPI Awards showcases this gifted new talent pool to the Entertainment and Communications Industries by way of a Central Link on the World Wide Web (www.capiawards.com). The CAPI Awards web site displays the Award Winning Entries for easy access by the Top Studios...Advertising Agencies...and Film and TV Producers throughout the World! CAPI Award Winners receive International Recognition and will be showcased in a Professional Industry Website! Furthermore, the CAPI Awards will actively promote and encourage the Entertainment/Communications Industry to actually license the winners entries for use in Film, TV, Video, Multi-Media, Magazines, and Websites... providing hot new cutting edge talent the opportunity to be discovered... be financially compensated ... and recieve a Professional Award of Achievement! COMPETITION OPEN TO PROFESSIONALS and AMATEURS! ENTRY DEADLINE IS MAY 31,1999! Visit Our Webite To For Entry Information and Current Award Winners Gallery www.capiawards.com We apologize if you received this valuable information in error. Tremendous effort has been undertaken to keep our list of referred artists updated and filtered. We are attempting to get this information to as many artists as possible due to the enourmous demand for new talent and material. ************************************************************************ To be removed from our mailing list at no cost to you, simply hit REPLY to: support@capiawards.comwith REMOVE in the subject. Your name will be removed from our list immediately. ************************************************************************ This message is sent in compliance of the new e-mail bill: SECTION 301, Paragraph (a)(2)(C) of s. 1618 Sender : International "CAPI" Awards, 2219 W. Olive Ave., Suite 312, Burbank, CA 91506 Phone : 1-818-372-3635 E-mail : support@capiawards.com From owner-ietf-url@imc.org Tue Apr 20 15:05:07 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15941 for ; Tue, 20 Apr 1999 15:05:06 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA05824 for ietf-url-bks; Tue, 20 Apr 1999 11:51:51 -0700 (PDT) Received: from alceste.w3.org (liberte@alceste.w3.org [18.29.0.72]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA05820 for ; Tue, 20 Apr 1999 11:51:50 -0700 (PDT) Received: (from liberte@localhost) by alceste.w3.org (8.8.7/8.8.7) id OAA15340; Tue, 20 Apr 1999 14:52:42 -0400 From: Daniel LaLiberte Message-ID: <14108.52474.873132.270478@alceste.w3.org> Date: Tue, 20 Apr 1999 18:52:42 +0000 (/etc/localtime) To: ietf-url@imc.org Cc: liberte@w3.org Subject: URI scheme registration procedures X-Mailer: VM 6.67 under 20.4 "Emerald" XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-url@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This is a response to "Registration Procedures for URL Scheme Names", draft-ietf-urlreg-procedures-06.txt, by Petke, King Also "Some Alternatives to draft-ietf-urlreg-procedures-03" by Petke. and "The VND Tree for URL Scheme Names" by King. The remainder of this message contains some of my ideas for the general problem of not enough URI schemes, rather than too many. ============= The registration procedures document is OK as far as it goes, and I don't have any strong objection. Good thing since the deadline for comments has passed. Consider these comments in that light. Three general recommendations: 1. Change "locator" to "identifier" throughout, URL -> URI 2. Separate identification from protocol. 3. Impose URI based registration of each scheme name. Section "URL Scheme Name Registration Trees", "General" 'the need is recognized for multiple registration "trees"' It is not clear from the text whether the "trees" are arbitrarily deep trees or are the just two levels deep, where lower level subtrees are really just a flat list? A two-level tree seems to be intended. I would favor general trees where higher levels would "own" lower levels and could impose any restrictions desired as long as they are more strict than the Guidelines for new schemes. The top-most levels, whether official IETF or alternative schemes, should be reviewed and approved via a Standards Track document, but a lower level scheme would follow the rules established by its ancestors. Section "Registration Template", the "Intended usage" part confuses identifiers with protocols to some extent. I can go along with giving an intended use as long as it is made clear this is not a protocol binding and there may be new protocols implemented in the future that impart otherwise unintended uses. One area that should be addressed, perhaps in a separate document, is automatically associating a URI with each scheme name, where resolving that URI will provide at least a human-readable definition of the scheme. Doing this would provide documentation in a way that more actively encourages conformance since everyone is referred to the same document. If machine-readable semantics could also be accessed by a similar URI, this would provide a greatly needed extensible mechanism for deploying new schemes. Since there not likely to be many IETF standardized schemes, the need for associating a URI with each scheme is not so important. With the ability to add many schemes (to the alternative trees) in a less controlled fashion, there is a far greater need to associate each scheme with its documentation. But allowing many more schemes to be deployed is not the same as actually facilitating their deployment. More on this below. ================= Regarding the "Some alternatives..." document, two ideas are suggested for supporting alternative scheme trees. The idea of composing vanity names by reversing DNS names is preferrable to the NOREG syntax proposed by Goland (in noreg-00.txt: 'NOREG+' domain name '+' URL-Scheme), but it seems a bit unkempt. More on this below. The Numeric OIDs idea should be avoided until such time as we can communicate telepathically to avoid seeing or entering URIs, or we have a higher-level human-readable URI scheme that hides the numeric OID level, but if we have that, why bother with OIDs. But I would like to argue against one of the supposed advantages of OIDs: "Scheme names can stay the same even if the owning entity changes it's name or is acquired by another entity". This may be true, but if so, it is only because the OID space is separate from the owning entities ultimate control, not because the OID space uses numbers. Numbers can be owned just as well as readable names. The main problem with the VND Tree suggestion is that it creates a new top level name space that will result in disputes if there are eventually enough parties interested in using it. It is even more of a problem because it is "vendor" specific and only a flat name space. Many public organizations (government, libraries, non-profit orgs) might have more of a reason to use their own schemes, and nothing is stopping them from registering their own top-level alternative tree. But it would be odd to have different trees operating by different syntactic rules. =================== The remainder addresses how to satisfy two goals: 1. Binding short schemes names to URIs, grandfathering in existing scheme names and allowing registration of new scheme names. 2. A non-centralized mechanism for adding new schemes names in a way that avoids collisions and facilitates deployment. The first goal can be accomplished by mapping the abbreviated short name of a scheme to a full URI as if it were a relative URI with a base URI of some long-standing form such as "http://www.ietf.org/urireg/". So the "http" scheme would itself be identified by the full URI "http://www.ietf.org/urireg/http", and resolving that URI would result in a human readable document, the current HTTP spec that defines how to process http URIs. This registration mechanism is not intended to be flat, but to allow structured names, we need to specify a translation from a structured form such as left-to-right '-' separated scheme names to the corresponding left-to-right '/' separated URIs. So a scheme name such as 'http-secure' would map to "http://www.ietf.org/urireg/http/secure". To accomplish the second goal of non-centralized registration, we need to rely on DNS itself, or some other existing name system that will deal with name space disputes. Name space disputes are inevitable if enough parties want to own parts of the same space. Trademark registration deals with name space disputes, and DNS needs to inherit the same dispute resolution mechanisms, if not do them better. So if we inherit from DNS, we are doing no worse. (Several people have made this argument.) To allow any party to independently create their own scheme, otherwise unregistered, I suggest we define one more top-level scheme for this purpose, call it 'dns'. The dns URI would look like: 'dns:///'. This is directly analogous to the http URI, but the difference is in the way a client resolves it. First it asks DNS for a particular kind of record for the , call it the 'URIREG' record for now. That record would give another URI for the document(s) defining the scheme. If a client knows how to use that scheme, it proceeds with the remainder of the URI, the . If it doesn't, see below on extensible semantics. The 'dns' scheme would be registered as above, and resolving "http://www.ietf.org/urireg/dns/" using the in the URI (perhaps reversed and '/' separated) could cause the server to fetch the URIREG record and produce a scheme definition document just as for other schemes. === All this presumes that deploying new URI schemes is relatively easy. Otherwise, why bother with all this bureaucratic overhead? (We should also ask In what areas do the existing schemes fall short?) It is easy enough to deploy clients that understand new schemes which documents will use in very constrained ways that are either backward compatible or there is nothing to be backward compatible with. The 'javascript' scheme is a case of this. If a browser doesn't understand a javascript link, it probably doesn't understand the javascript language at all, and the browser-local action that the link should invoke will not occur. Thus browsers that don't support javascript won't provide this functionality, but it is not a loss on a global scale. On the other hand, new schemes associated with new network protocols for global access are very difficult to deploy. Note that we have the same set of global URI schemes today as we did at the beginning of the web. This is because providers are very unlikely to use a new scheme in documents if few clients support it, and producers of client software are unlikely to support a new scheme unless there are providers that use them to make the extra code worth while. It is clearly not impossible, but it is obviously very difficult unless there is a long term cooperation between providers and client software producers. One approach to the deployment problem is to use proxies associated with each new scheme that process the identifiers for clients. If the registered information associated with a scheme name included how to find a proxy that understands the scheme, this would provide at least a foot in the door to deployment. But it is not a terribly scalable approach unless the proxy mechanism can be sufficiently distributed as well. Another partial solution to the deployment problem is to allow multiple URIs per link. Instead of only one URI in a single anchor, if a list of somewhat equivalent URIs were allowed, the client could pick the first one it understood, or pick one the user would prefer to use if there is something to prefer. This will at least allow new URI schemes to be used in documents while continuing to support the old schemes, so it makes deployment less problematic, but it doesn't otherwise address how new scheme handlers get deployed in clients. Another approach to work around this impass is automatically deployable, executable semantics in the form of Java code (or something at least as powerful) that may be downloaded into clients as needed to process identifiers in the associated scheme. Clients that already understand a scheme by some other means (i.e. it's hard-coded into the client) need not download the code, but clients that can accept this form of extension will have access to any scheme defined in this way. There are obviously significant security concerns here, and current Java runtime systems don't permit unlimited access to all network services, nor should they do so. But there should be several possible solutions to this set of concerns. For example, proxies that do resolution on behalf of other clients as described above could download the resolution code and take on the additional burden of verifying the integrity of the resolution code. With an extensible scheme mechanism in place (it has to be deployed too) we would not have to worry about deployment of any schemes that fit within this one extensible scheme. Indeed, there are several hard questions that must be addressed, such as how extensible does it need to be, and how are security problems to be avoided. But deploying this one extensible scheme would greatly facilitate the more rapid evolution of the internet. Hmm, maybe we don't really need that after all. :-) -- Daniel LaLiberte liberte@w3.org From owner-ietf-url@imc.org Tue Apr 20 15:07:21 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16000 for ; Tue, 20 Apr 1999 15:07:20 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA05884 for ietf-url-bks; Tue, 20 Apr 1999 11:53:49 -0700 (PDT) Received: from alceste.w3.org (liberte@alceste.w3.org [18.29.0.72]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA05873 for ; Tue, 20 Apr 1999 11:53:48 -0700 (PDT) Received: (from liberte@localhost) by alceste.w3.org (8.8.7/8.8.7) id OAA15346; Tue, 20 Apr 1999 14:54:42 -0400 From: Daniel LaLiberte Message-ID: <14108.52594.112866.11@alceste.w3.org> Date: Tue, 20 Apr 1999 18:54:42 +0000 (/etc/localtime) To: ietf-url@imc.org Cc: liberte@w3.org Subject: Response to Guidelines for new URI Schemes X-Mailer: VM 6.67 under 20.4 "Emerald" XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-url@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This is a response to "Guidelines for new URL Schemes, draft-ietf-urlreg-guide-05.txt, by Masinter, Alvestrand, Zigmond, Petke Summary: Good overall, but I have two general recommendations, described in more detail below. 1. Change "locator" to "identifier" throughout. 2. Separate identification from protocol throughout. Section "Syntactic compatibility" Regarding the sentence starting "If a URI scheme that has embedded links in content accessed by that scheme does not share syntax with a different scheme," do we agree that "accessed by that scheme" is shorthand for "accessed by a protocol associated with that scheme"? I have more comments on protocol relationships below. Regarding the general caution that "new schemes must have demonstrable utility and operability", it is fine to consider what might happen if a new scheme is deployed. But there is another concern that would appear to make this caution is almost irrelevant since very few if any new schemes will likely be deployed for use by global identifiers. The main reason is the catch 22 that providers are very unlikely to use a new scheme in documents if few clients support it, and producers of client software are unlikely to support a new scheme unless there are providers that use them to make the extra code worth while. On the other hand, this extreme difficulty of deployment would make it all the more important that any new scheme that does get deployed follow the compatibility guidelines. And furthermore, use of relative URIs will actually make deployment of new schemes easier since the same document could potentially be accessed by both old and new schemes. So it is probably worth explicitly pointing this out in the guidelines. Section "Motivations for syntactic compatibility". It is good to point out the motivations by stating what would go wrong with incompatibility, but there probably some positive ways to state the same thing, and some additional positive motivations, such as easing deployment, greater predictability and hence readability, and leveraging the power of relative URIs. It appears most of the text of this section comes almost directly from Jim Gettys' mail of February 1998. Perhaps he should be a co-author. Because the fragment syntax for http URLs is a property of the media type of the returned object, the fragment syntax should probably be avoided entirely unless it can be used in a media independent way. This is a stronger way of saying what the draft says regarding the fragment syntax. The paragraph about the '/' syntax is rather confusing. The example helps, but even it could be more explicit. Also, "see section 2.1.1" is in section 2.1.1. Regarding the paragraph on naming authority syntax, it suggests that relative URIs starting with '//' are meaningful, but it doesn't quite say that. Regarding improper use of '//', the text "is not simply an artistic indicator that what follows is a URL", "a URL" should be "the rest of a URL". And in "what follows is the top hierarchical element for a naming authority", the "naming authority" is not necessarily correct, regardless what RFC 2396 says. Any other higher level use of this element is possible that has nothing to do with being a naming authority. Section "Compatibility with fragment syntax": "Fragments indicate a location within a particular document" the "location" is too specific since there may be no such clearly defined point in a space. Rather it should just be "local label", leaving the interpretation up to the handler of the media type. Section "Is the scheme well defined?": in the phrase 'the "resource" that a URL "locates"', replace "locates" with "identifies". In fact, the draft should be "Guidelines for new URI schemes", and most uses of "locator" should be replaced with "identifier", and "locate" with "identify", etc. (This will also make the guidelines for the non-protocol URLs less problematic.) Maybe split this document into two documents, one for "Guidelines for new identifier schemes" and another for "Guidelines for mapping identifier schemes to protocols". Section "Definition of non-protocol URL schemes" seems to have some problems that relate to the whole model of identifiers and resources. In some cases, URL schemes do not have particular network protocols associated with them, because their use is limited to contexts where the access method is understood. The "access method" could be interpreted as a protocol, unless "protocol" can be clearly defined as some "over-the-wire" mechanism. (Wires are increasingly irrelevant as distributed object mechanisms gain force.) But whether the access method is "understood" by the application seems irrelevant because whatever is done with a URL, protocol or not, must be understood by the application otherwise it is meaningless. The "complete mapping of the locator from its source" doesn't make any sense to me. I think what is missing here is that these identifiers are used just for labeling a piece of data in a context and for referencing those labelled pieces of data in the same context. The access method is in fact just "use the piece of data with this label". The very same identifier might also be useable via a protocol to access an object remotely, if it makes sense to do so. So what this section should be talking about seems to be the use of an identifier merely for labelling, local access, and comparison, regardless of whether the scheme is associated with any protocols. Also related to this "non-protocol" issue is how to deal with identifiers that are associated with non-internet resources such that there can be no internet protocol associated with it, at least not in the near future. For example, ISBN numbers for physical books, and street/city/country addresses for people. Phone numbers are a case where we might soon have internet protocols that use them. Backing up to the section "URL schemes associated with network protocols", I like the weakness of term "associated" since it doesnt suggest the tight binding that people often assume. But I would weaken it more explicitly. The ability to change a protocol for the same identifier scheme is important to ensure the evolution of network applications while maintaining continued use of the same identifiers. In fact, I believe scheme writers should be *encouraged* to specify the syntax and abstract semantics of a scheme *without* having to specify any concrete semantics of a particular network protocol. The mapping from a scheme to a particular network protocol could be done in a separate document. The abstract semantics of a scheme could be given in the form of relatively fuzzy, intended effects or more formal declarations that constrain the cause-effect relationships without specifying how to achieve those results. The section "Definition of URL schemes not associated with data resources" is at least titled ambiguously, and it has possibly several other problems. That title suggests a distinction between "resources that correspond to data objects that may be retrieved or modified" and resources that one can only interact with via a protocol or service. But most protocol interactions are of that form, and whether you retrieve or modify an object is an independent question. What this section seems to really be about is a distinction between protocols that mostly request data (e.g. ftp and http) and protocols that mostly send data (e.g. mailto). But notice that all these protocols involve one or more synchronous connections across a network where the client sends some data to a server and receives some response, perhaps repeatedly during one connection. So the distinction at this level is not clear. Finally, it says 'the "mailto" URL scheme corresponds to an Internet mail address'. But what one does with an internet mail address is not self-evident. The "mailto" scheme associates the particular action of composing and sending an email message to that address, and that would seem to be the limit of its scope, not so much because of the name of the scheme, but because of established use. But other actions relative to an internet address might be possible that *are* related to data resources, such as accessing a local collection of messages previously sent to or received from that address, or sending a request for data. Also consider that one mailto action might cause a second mail transaction that is a response to the first, or it might cause a cascade or chain of messages to other recipients, and these transactions might all be regarding some data resource on the server. Back to the issue of associating particular protocols with identifiers, this section seems to assume that some identifiers are associated with particular *kinds* of protocols relative to the identifiers. But it turns out that what kinds of protocols those are is not so clear, and there probably should not be any particular protocol binding in the first place. I hope I have at least shown the muddle of concepts that come to mind when reading this section, though I admit I haven't made it much clearer. One thing seems clear: separate identifiers from protocols. The section "Definition of operations" is really about the operations of particular protocols associated with identifiers, and so it has similar problems as described above. The problem is more obvious when the same identifier can be used in different ways, with different "methods" of the same protocol. Another important issue not discussed or referenced in this document is registration of identifier schemes and associated protocols. I realize this is covered in a separate document, but it should be mentioned here as well. =========== The remainder of my comments are typographical or stylistic. Section "Demonstrated utility" "needless" => "needlessly" Too many "things". I'm not sure what kinds of things are meant in "kinds of things that are useful". Section "Proxy into HTTP/HTML" HTML seems to be unrelated to this proxying function. Requiring use of HTML for representing non-HTML objects would seem to change the functionality of the protocol. "the new URL object" => "the new URL scheme" Under "Are the operations mappable ... to HTTP operations?" add the question "If so, why use a new scheme?" -- Daniel LaLiberte liberte@w3.org