Re: DRAFT Minutes, URL BOF

["Martin J. Duerst" <[e-mail]>]

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.