Re: [urn] Review period Re: I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt

[Juha Hakala <[e-mail]>]

Hello,

Leslie Daigle wrote:
> 
> Hi,
> 
> This document questions the 2-week mailing list review period for formal 
> namespace registrations, suggestion 4 weeks (or possibly 8).

I had a similar concern. But following the discussion in IETF 83 it 
seems that even 2 weeks is sufficient, provided that each iteration (new 
version of the namespace registration) gets the same two weeks.

> What I've seen (as the designated expert that needs to be replaced):
> 
> + namespace proposals that don't  get published as I-D's
>  -- Step 0:  please publish this as an I-D

Some target communities lack the expertise needed. It is hard to 
eliminate this problem.

> + namespace proposals that don't follow the correct version of the RFC
>  -- authors need guidance about current version
> 
> + namespace proposals that need to be cleaned up in terms of having 
> reasonable explanations in the Considerations sections
>  -- offer guidance and repeat

"Unreasonable" may mean at least two different things. First, some 
required bits may be missing completely. These problems are easy to 
spot. Second, we may receive namespace registration which is not 
functional. For instance, we may have a non-semantic (dumb) identifier, 
and the namespace registration describes a decentralized resolution 
mechanism. In this case there would be no hint how to find the correct 
resolver. Of course these problems do not need to be glaringly obvious 
like the one described above. Subtle issues will be hard to spot, and 
require at least some level of familiarity with the identifier system.

There may also be requests which seem to be OK (for instance, following 
the consensus concerning the <fgrament>, I could allow its use in the 
URN namespace since <fragment> is not part of the URN. But the 
International ISBN Agency may not approve this. Checking that the people 
who have written the registration request are fully authorized may not 
be that easy.

> + namespace proposals that come in through *other* IETF wgs, and never 
> get put on the urn-nid mailing list
>  -- need AD help to get them to the URN reviewers
> 
> 
> What I have *not* seen, surprisingly (but pleasantly):
> 
> + a lot of discussion about whether something really should be a URN 
> namespace.  Hurrah.

Again, we may have different issues here. I suppose that we will not 
often have cases where an identifier system is a priori technically 
unsuitable (for instance, you could give the same identifier again and 
again for different resources). Such identifiers should never make it, 
of course. Same would apply to identifier systems that do not identify 
anything that would be useful in the Internet context. But the 
administrative issues related to the persistence of the URNs assigned 
from a given namespace are a problem. There are certainly differences 
between URNs in this respect: while URN:ISBNs are trustworthy, I have no 
idea how persistent URN:UUID will be.

Remembering the discussion we had about UUIDs, I believe that the 
community does not want to introduce stringent administrative criteria 
for people or organizations sending namespace registration requests. 
Which, I think, is feasible and acceptable.

Juha
> 
> Leslie.
> 
> On 3/12/12 4:20 PM, [e-mail] wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories. This draft is a work item of the Uniform Resource Names, 
>> Revised Working Group of the IETF.
>>
>>     Title           : Uniform Resource Name (URN) Namespace Definition 
>> Mechanisms
>>     Author(s)       : Alfred Hoenes
>>     Filename        : draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt
>>     Pages           : 30
>>     Date            : 2012-03-12
>>
>>     Uniform Resource Names (URNs) are intended to serve as persistent,
>>     location-independent, resource identifiers.  To structure and
>>     organize their usage, the URN syntax (RFC 2141bis) specifies a
>>     hierarchy that divides the set of possible URNs into "URN Namespaces"
>>     that can be individually defined and managed.  URN Namespaces in
>>     particular serve to map existing identifier systems into the URN
>>     system and thereby make available generic, network-based resolution
>>     services for the identified documents, artifacts, and other objects
>>     (and metadata related to them).
>>
>>     To achive these goals, URN Namespaces need to be specified in a
>>     comparable manner, and their Namespace Identifiers (NIDs) need to be
>>     registered with IANA, so that naming conflicts are avoided and
>>     implementers of services can follow a structured approach in support
>>     of various namespaces, guided by the registry to the related
>>     documents and the particularities of specific namespaces, as
>>     described in these Namespace registration documents.
>>
>>     This RFC serves as a guideline for authors of URN Namespace
>>     definition and registration documents and the process to be followed
>>     to register a URN Namespace with IANA.  It describes the essential
>>     content of such documents and how they shall be structured to allow
>>     readers familar with the scheme to quickly assess the properties of a
>>     specific URN Namespace.
>>
>>     This document is a companion document to the revised URN Syntax
>>     specification, RFC 2141bis; it supersedes and replaces RFC 3406.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt 
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt 
>>
>>
>> _______________________________________________
>> urn mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/urn
> 

-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email [e-mail], tel [phone]