Edited minutes from Washington, DC

Here are the minutes from our meeting in Washington, edited to be in the
format required by the IETF.  Please review them and forward all correction
to Rich Petke ([email protected]).  If no corrections are received
in a day or two, I'll submit the minutes.

Rich Petke, co-chair


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.

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 review committee 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.  (Pretty much what Yaron was talking about.) 
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:

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 by 'vnd.'

Short-short names (RFC required, standards track, IESG action)
 
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 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.