Minutes URLREG - URL Registration Procedures WG 40th IETF, Washington, DC 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.