Re: request for NID review: "iana"

["Martin J. Dürst" <[e-mail]>]

Hello Peter,

I have a few questions/concerns.

First, is creation of URNs planned for all registries? I can't remember 
an example, but some registry entries already probably have URNs 
associated with them. Or is this only going to be used when requested in 
a IANA consideration section?

Next, there is wording such as:
       The IANA is responsible for managing the assignment of both
       "RegistryName" and "EntryName" strings.
What does this mean? That e.g. the Charset Registry will be under 
RegistryName "Character%20Sets" (because that's how it appears at 
http://www.iana.org/protocols, with the space escaped), or something 
else? If something else, then what?

Another main concern is this uniqueness/persistence:
    Identifier Uniqueness Considerations:

       The IANA ensures the uniqueness of all IANA URNs by checking
       RegistryNames and EntryNames against existing names for both
       registries and entries.  The IANA directly ensures the
       uniqueness of the assigned strings and does not assign
       secondary responsibility for management of any sub-trees.
       In no case will the resulting URNs be re-assigned.

    Identifier Persistence Considerations:

       Through its existing registration procedures, the IANA
       ensures that registrants provide clear documentation of
       the entries in IANA registries.

The uniqueness of the identifier isn't a problem. But what about the 
uniqueness of the "protocol entity" (or whatever) that is identified? 
There may be identifier reallocation for registries where there's not 
that much space. Also, if definitions of entries change because they are 
being updated, is a new URN needed, or is the old one still good enough? 
Personally, I'm fine with either way, but I think it should be discussed 
more.

Also, it says:
    The Internet community will benefit from this namespace by having
    more permanent and reliable names for parameters used in the context
    of Internet protocols and applications.

How do e.g. port assignments get more permanent or more reliable by 
creating this kind of URN? Similar question for other registries. Just 
because I can write urn:iana:charsets:iso-8859-1, how does this make it 
more permanent? Or more reliable?

Regards,   Martin.

On 2012/11/08 9:24, Peter Saint-Andre wrote:
> The following is a formal namespace registration for the namespace ID
> "iana". Review and feedback would be appreciated. The related I-D is:
>
> https://datatracker.ietf.org/doc/draft-saintandre-iana-urn/
>
> Peter
>
> ###
>
>     Namespace ID:
>
>        The Namespace ID "iana" is requested.
>
>     Registration Information:
>
>        Version 1
>        Date: [[to be assigned by the RFC Editor]]
>
>     Declared Registrant of the Namespace:
>
>        Registering organization
>           Organization: Internet Assigned Numbers Authority (IANA)
>           Address: 4676 Admiralty Way, Suite 330
>                    Marina del Rey, CA
>                    90292-6601
>                    USA
>
>        Designated contact
>           Role: IANA team
>           Email: [e-mail]
>
>     Declaration of Syntactic Structure:
>
>        The Namespace Specific String (NSS) of all URNs that use the
>        "iana" NID shall have the following structure:
>
>           urn:iana:{RegistryName}:{EntryName}
>
>        The keywords have the following meaning:
>
>           (1) the "RegistryName" is a required ASCII string that
>           conforms to the URN syntax (RFC 2141) and defines a
>           particular registry maintained by the IANA.
>
>           (2) the "EntryName" is a required ASCII string that
>           conforms to the URN syntax (RFC 2141) and defines a
>           particular entry in the relevant registry.
>
>        The IANA is responsible for managing the assignment of both
>        "RegistryName" and "EntryName" strings.
>
>     Relevant Ancillary Documentation:
>
>        Information about IANA registration procedures can be found
>        on the IANA website and in RFC 5226.
>
>     Identifier Uniqueness Considerations:
>
>        The IANA ensures the uniqueness of all IANA URNs by checking
>        RegistryNames and EntryNames against existing names for both
>        registries and entries.  The IANA directly ensures the
>        uniqueness of the assigned strings and does not assign
>        secondary responsibility for management of any sub-trees.
>        In no case will the resulting URNs be re-assigned.
>
>     Identifier Persistence Considerations:
>
>        Through its existing registration procedures, the IANA
>        ensures that registrants provide clear documentation of
>        the entries in IANA registries.
>
>     Process of Identifier Assignment:
>
>        The processes and procedures for identifier assignment are
>        documented on the IANA website and in RFC 5226.
>
>     Process for Identifier Resolution:
>
>        The namespace is not currently listed with a Resolution
>        Discovery System (RDS).  However, nothing about the namespace
>        prohibits the future definition of appropriate resolution
>        methods or listing with an RDS.
>
>     Rules for Lexical Equivalence:
>
>        No special considerations; the rules for lexical
>        equivalence specified in RFC 2141 apply.
>
>     Conformance with URN Syntax:
>
>        No special considerations.
>
>     Validation Mechanism:
>
>        None specified.
>
>     Scope:
>
>        Global.
>
> ###
>