NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 27-Oct-97
Chair(s):
Rich Petke <r.petke@csi.compuserve.com>
Ian King <iking@microsoft.com>
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Applications Area Advisor:
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Mailing Lists:
General Discussion:ietf-url@imc.org
To Subscribe: ietf-url-request@imc.org
In Body: subscribe in message body
Archive: http://www.imc.org/ietf-url/
Description of Working Group:
This working group exists for the purpose of creating two documents: The first document, a BCP RFC, will be the process for registering new URL schemes. The second document, an Informational RFC, will be a guideline for the creators of new URL schemes. The purpose of this guideline will be to help ensure that new URL schemes:
- Consistently implement the general syntax of URLs as specified in the URL Generic Syntax and Semantics RFC. - Are compatible with existing URL schemes. - Have clearly specified character encoding rules. - Have a well defined set of operations specified for them. - Properly address security considerations.
The following issues are considered beyond the scope of this working group and shall not be addressed by it:
- Modifications to the URL Generic Syntax and Semantics RFC. - Specific URL schemes, previously proposed or not, except as test cases for the guidelines document. - UR* schemes other than URLs.
Justification for working group:
RFC 1738 defined URL schemes for a number of protocols popular at the time that it was written. Many URL schemes for protocols not addressed in RFC 1738 have been proposed since the publication of that RFC.
Due to the absence of guidelines for the development of new URL schemes, some of these recently proposed schemes lack completeness. Further, while some of these schemes are now on the standards track, no mechanism for the registration of these new schemes has yet been specified.
The output of this working group is needed in order to help ensure the overall integrity and consistency of URLs in the future.
Goals and Milestones:
Jul 97 |
|
Publish drafts of the registration and guidelines documents which capture all open issues and propose possible resolutions for each. |
Dec 97 |
|
Submit guidelines document to IESG as an Informational RFC. |
Dec 97 |
|
Conclude WG. |
Dec 97 |
|
Submit registration document to IESG as BCP RFC. |
Internet-Drafts:
· Guidelines for new URL Schemes
· Uniform Resource Locators (URL): NOREG URL Naming Scheme
No Request For Comments
Minutes of the URL Registration Procedures (URLREG ) WG
Minutes taken by Alec Dun, Edited by Rich Petke
A brief review of the WG's current guidelines draft (draft-ietf-urlreg-guide-00.txt) was held. The group agreed that once a few minor edits concerning references to the forthcoming registration procedures document were made, the document was ready for a WG last call. Larry Masinter (masinter@parc.xerox.com) agreed to make the changes and to post the draft to the mailing list and to the IETF drafts directory. [Larry did this before the week was over.]
The WG then turned its attention to the issue of the actual registration procedure for URL schemes. Several options were presented in order to stimulate discussions. They included:
1) Requiring every URL scheme to be documented in one or more standards track RFCs.
2) Creating a standing review committee for URL schemes.
3) Some process that mimics the MIME registration process as described in RFC 2048.
4) An option for "no registration" for private schemes.
It was pointed out that a standing working group to review URL schemes would be an exception to the way the IETF operates and thus not a good solution. There was support in the group for requiring standards track documents, for the MIME media type registration mechanism, and for the DNS name based "no reg" option proposed by Yaron.
A suggestion was made to examine the document "draft-iesg-iana-considerations-01.txt" which lays out in great detail example policies that could be used. The methods extracted from the draft were:
1) Free-for-all. For local use only. Don't try to avoid conflicts. No need to be reviewed by IANA.
2) Hierarchical allocation. (Yaron's draft is an example of this.) IANA controls a higher level of the namespace. We could use DNS here, or another mechanism is fine.
3) First-come-first-serve. Anyone can obtain a value as long as they provide point of contact, and describe what it will be used for. Advantage is that you will get a short name (rather than using hierarchical allocation). For example "vnd." mime types.
4) Specification required. There must be an RFC.
5) IESG approved committee. Extensions are approved by IESG.
It was pointed out that not all mechanisms need to exist for the URL registration process but that these mechanisms were an "approved" set to select from.
There was general agreement in the group that while not all of the mechanisms needed to be implemented, there was a need to include more than just one of the mechanisms in the URL registration procedures.
A long discussion followed concerning the value of short URL scheme names and the issues surrounding their creation (like name space collisions and trademarks). It was pointed out that trademark collisions have turned out not to be a problem with the "vnd." convention used with MIME registration.
While there were some voices for a sliding scale mechanism, most people seemed to be moving towards a registration procedure with three mechanisms as follows:
1) Short names ("vnd.") by review. The short description is sent to a mailing list and feedback is given in an advisory way. There is no enforcement. There is enough process to let people find conflicts. This would be done in the same way that it works for "vnd."
2) Short-short names (RFC required, standards track, IESG action)
3) Long name - your review.
There was a suggestion from one of the Area Directors that a mechanism for pre-registering (reserving) a short name be included in the procedures. No RFC would be required but the "right" people would have to sign off on it.
Dan Zigmond (djz@corp.webtv.net) volunteered to author a draft capturing today's discussions.
There was a desire on the part of the working group to conclude before the next IETF meeting.
None Received