Subject: request for NID review: "iana"

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Nov 2012 19:24:56 -0500

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: [email-masked]

   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.

###

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 11 Nov 2012 00:08:55 +0900

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 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.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 10 Nov 2012 19:43:10 -0700

On 11/10/12 8:08 AM, "Martin J. Dürst" wrote:
> 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?

All this document really does is reserve the "iana" namespace
identifier. It is up to the IANA whether they use the namespace at
all. This is made clear in the IANA Considerations for this document:

   This document defines a URN NID registration of "iana" and thus opens
   the possibility that the IANA can use that namespace if desired.
   However, this document does not stipulate that the IANA is to create
   names for every entry in every registry that it maintains.  The
   IANA's use of the namespace is a matter for IANA policy, which is
   outside the scope of this document.

> 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?

Really that should be "RegistryString" instead of "RegistryName".

> Another main concern is this uniqueness/persistence: Identifier
> Uniqueness Considerations:
> 
> 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.
> 
> 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.

I think that's a matter for IANA policy documents, but those are good
questions.

> 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?

The parameters you have mentioned are stable, but the names for them
are not, as explained in the Introduction (indeed, currently we don't
really have names for parameters, only for the registries themselves).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/