- From: Martin J. Duerst <mduerst@ifi.unizh.ch>
- Date: Thu, 19 Dec 1996 16:48:07 +0100 (MET)
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: uri@bunyip.com
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.
Received on Thursday, 19 December 1996 10:49:39 UTC