Re: uri, urn and info

Hi Eric,
	Note that the requirements for the URN NID process are set
out in RFC 3406 and that they do not require that the documentation
be a standards track document.  It requires review by a specific
mailing list (urn-nid@apps.ietf.org) and review by the IESG.   The
term "IETF consensus" has been seen as ambiguous on this, but
this case is very clear, as RFC 3406 sets out the steps admirably
well.
	The IETF tree of the URI scheme registration mechanisms are
set out in RFC 2717, and Larry Masinter is currently working on an
update to the document to define registration procedures for other
trees.  There are two key issues for me in scheme registrations: 
can the registration adequately inform the reader where to turn
for information on protocol processing based on the scheme, and
can the registration adequately indicate who has change control
over those procedures?  Like many others, I don't see a great deal
of point for the proliferation of schemes, unless the protocol processing
indicated by the schemes is different.  For "pure" identifiers, not
intended to trigger protocol processing (be it dereferencing or something
else), I can see the need for a small handful of schemes, based on
expectations of permanence or minting algorithms suited to different
environments.  But a thousand flowers in that arena will only give us
hay fever, in my opinion.
			regards,
				Ted Hardie

 

At 6:29 PM -0400 10/07/2003, Michael Mealling wrote:
>On Tue, 2003-10-07 at 17:45, Eric Hellman wrote:
>> urn
>> rigorous requirements but the real hurdle with urn is to get IETF
>> consensus.
>
>Which is proving to be a fairly easy thing to do. At present we have the
>following registered IDs:
>IETF       [RFC2648]
>PIN        [RFC3043]	
>ISSN       [RFC3044]
>OID        [RFC3061]
>NEWSML     [RFC3085]
>OASIS      [RFC3121]
>XMLORG     [RFC3120]
>publicid   [RFC3151]
>ISBN       [RFC3187]
>NBN        [RFC3188]
>WEB3D      [RFC3541]
>MPEG       [RFC3614]
>mace       [RFC-hazelton-mace-urn-namespace-02.txt]
>fipa       [RFC3616]
>swift      [RFC3615]
>
>I submitted the 'liberty' NID proposal and the process once I submitted
>it to the NID list was completely comment free. The time between request
>and approval was about 1 month total. The RFC Editor will probably
>publish it shortly. Its a heck of a lot faster than the MIME types
>registration process. ;-)
>
>> IETF lapses most URN proposals and doesn't promote or use
>> the ones it does.
>
>What do you mean by 'lapses'? All of the proposals except 'tag' and some
>where the project dropped off the face of the earth have made it through
>the process. The IETF is using the 'ietf' space fairly heavily,
>especially as it concerns the XML registry defined in
>draft-mealling-iana-xmlns-registry-05.txt. Presently the standards
>waiting on is publication are simple, provreg, and sipping (those are
>the ones the RFC Editor has, there are more I think).
>
>The identifiers have been assigned and the processes are in place. If
>there is some confusion on that process let me know and I'll make sure
>it gets clarified or straightened out....
>
>-MM

Received on Tuesday, 7 October 2003 19:06:55 UTC