ATTENTION! Second draft of the minutes

OK, Rich sent this out a week ago and we've not heard any objections.
And, Harald is letting us know our minutes aren't in.  So, unless you
send something to the list, Rich ([email protected]) or me
([email protected]) by end of day tomorrow, I'm shipping this second
draft off to the Secretariat as our official minutes.  

> -----Original Message-----
> From:	Rich Petke [SMTP:[email protected]]
> Sent:	Thursday, January 15, 1998 7:23 AM
> To:	URL List
> Subject:	Second draft of the minutes
> 
> Here is a revised draft of the minutes from our December meeting.
> This draft incorporates some clarifications which I have received
> and hopefully will not be creatively reformatted by the mail
> software prior to transmission.  Comments to:
> 
> Rich Petke ([email protected])
> 
> 
> 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 ([email protected]) 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 ([email protected]) 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.