Date: Thu, 19 Dec 1996 16:48:07 +0100 (MET) From: "Martin J. Duerst" <firstname.lastname@example.org> To: Larry Masinter <email@example.com> Cc: firstname.lastname@example.org Subject: Re: DRAFT Minutes, URL BOF In-Reply-To: <96Dec14.151151pst."2695"@golden.parc.xerox.com> Message-Id: <Pine.SUN.3.95.961219162033.245J-100000@enoshima> On Sat, 14 Dec 1996, Larry Masinter wrote: > The URL BOF was convened to decide if there was a need to form a URL > working group for either of two purposes: > > - Advance URL syntax draft to Draft Standard > - Create an RFC for BCP to describe the process for creating new URL > schemes > Many people expressed the feeling that no new working group is needed > to process draft-fielding-url-syntax (except via mail on the mailing > list), but a working group is needed to deal with the process. Harald > Avelstraad had a web page about _his_ requirements for URL schemes, > (http://www.apps.ietf.org/apps) and this was proposed as a starting > point. > The working group will NOT consider the generic syntax draft. There's > some desire to make sure that the Draft Standard gets advanced before > the working group is chartered, just to keep the boundary clear. If we have separate documents for URL syntax and for URL requirements/ registration/..., then the URL syntax draft should be cleaned from any requirements to URLs. Exceptions are of course purely syntactical requirements. An appendix might list the current requirements, or a reference could be given to requirements in earlier RFCs to avoid a hole up to the time the requirements/registration work is done. To give an impression of what I mean, here a few examples of language that contains requirements outside syntax. I'll exclude internationalization, as I will deal with it separately. > Abstract > > A Uniform Resource Locator (URL) is a compact string representation > of a location for use in identifying an abstract or physical > resource. This document defines the general syntax and semantics of > URLs, including both absolute and relative locators, and guidelines ^^^^^^^^^^ > for their use and for the definition of new URL schemes. It revises ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > and replaces the generic definitions in RFC 1738 and RFC 1808. > 1.2. Example URLs > Many other URL schemes have been defined. Section 6 describes how > new schemes are defined and registered. > 6. Adding New Schemes > > The Internet Assigned Numbers Authority (IANA) maintains a registry > of URL schemes. > > The current process for defining URL schemes is via the Internet > standards process: new URL schemes should be described in > standards-track RFCs. Over time, other methods of registering URL > schemes may be added. > > URL schemes must have demonstrable utility and operability. One way > to provide such a demonstration is via a gateway which provides > objects in the new scheme for clients using an existing protocol. If > the new scheme does not locate resources that are data objects, the > properties of names in the new space must be clearly defined. Regards, Martin.