Re: [urn] More comments on draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02

[Peter Saint-Andre <[e-mail]>]

On 7/10/12 8:11 AM, Svensson, Lars wrote:
> All,
> 
> I have some more comments on 3406bis:
> 
> Introduction:
> 
> "I.e., not all syntactically correct URN Namespaces (per the URN 
> syntax definition) are valid URN Namespaces.  A URN Namespace must 
> have a recognized definition in order to be valid."
> 
> Is it enough for a URN Namespace to have a recognized definition to
> be valid or does it have to be registered somewhere? If recognized is
> enough: recognized by whom?

I tend to agree that the notion of validity used here is not well
specified. Formal namespaces and informal namespaces do have recognized
definitions, because they are registered with the IANA. Experimental
namespaces (which personally I would prefer to deprecate, see the
"example" namespace I-D that I will submit when the window opens again)
do not have recognized definitions, I think.

Perhaps: "A URN Namespace must be registered in accordance with the
procedures specified in this document in order to be considered valid."

> Sec. 4.1: Experimental namespaces
> 
> If we desire to register example as a NID, this whole section will
> probably not be needed any more.

I hope so. I wrote the I-D, but I missed the submission deadline.

> As a corollary, sec 4.3 needs to change:
> 
> "NIDs for Formal URN Namespaces MUST NOT have the forms indicated in 
> the preceding two sections for the other two Namespace types.  (The 
> detailed formal rules are given below in Section 4.4.4.)
> Applicants, in concert with the IANA experts, should ensure that the
> sought NID strings are "proper" for the designated purpose, according
> to common sense (and applicable legal rules)."
> 
> Proposed text (moving parts from 4.4.4 to 4.3):
> 
> "NIDs for Formal URN Namespaces MUST adhere to the following 
> constraints: -  not be an already-registered NID; 

Isn't it the responsibility of the expert reviewer and the IANA to
ensure that people don't register duplicates? In any case, given that
the NID is the "key" here, I don't see much danger in duplicates.

> -  not start with
> "urn-" (see Section 4.1 above); -  not start with "X-" (see NOTE
> below); -  not start with "xy-", where xy is any combination of 2
> ASCII letters (see NOTE below); -  not be equal to or start with
> "example" (see NOTE below); 

Actually I plan to register "urn:example" as a replacement for
experimental namespaces. Why would we forbid that? Or would the I-D I
wrote lock that down?

> -  be more than 2 characters long.
> 
> NOTE: All two-letter combinations as well as two-letter combinations 
> followed by "-" and any sequence of valid NID characters are
> reserved for potential future use as countrycode-based NIDs for
> eventual national registrations of URN Namespaces.  The definition
> and scoping of rules for allocation of responsibility for such
> Namespaces is beyond the scope of this document. Further, to avoid
> confusion, "urn" is not allowed as an NID string; To allow neutral
> example URNs in code and documentation, NID strings starting with
> "example" are set aside for use in documentation; 

I think it's better to do that in the I-D I've written, not in the
registration document.

> IANA has
> permanently reserved these string to prohibit assignment. Earlier
> versions of this RFC [RFC 2141] defined NID strings starting with
> "X-" as belonging to the class of experimental namespaces. In order 
> to avoid confusion, the registration of NIDs starting with "X-" is 
> prohibited."

I suppose that's OK given the history behind the "X-" space here.

> 4.4.4 IANA Considerations in Registration Documents
> 
> "According to the general procurements for RFCs, URN Namespace 
> definitions documents must include an "IANA Considerations" section 
> (cf. BCP 26 [RFC5226]).  That section has to indicate that the 
> document includes a URN Namespace registration that is to be entered 
> into the IANA registry of Formal URN Namespaces."
> 
> This might not be correct if the registration request is for an
> informal namespace...

Corrent.

> Further, I suggest that constraints on NIDs are moved to 4.3.
> Suggested wording of 4.4.4:
> 
> "According to the general procurements for RFCs, URN Namespace 
> definitions documents must include an "IANA Considerations" section 
> (cf. BCP 26 [RFC5226]).  That section has to indicate that the 
> document includes a URN Namespace registration that is to be entered 
> into the IANA registry of informal or formal URN Namespaces,
> respectively.
> 
> Registration documents for formal URN Namespaces will provide a 
> particular, unique, desired NID string, and this will be assigned by 
> the Standards/Protocol Action of the IESG that approves the 
> publication of the registration document as an RFC.  RFC 2141bis 
> [I-D.ietf-urnbis-rfc2141bis-urn] specifies that NID strings are
> ASCII strings that are interpreted in a case-insensitive manner, but
> the NID string SHALL be registered in the capitalization form
> preferred by the registrant.  The proposed NID string MUST conform
> with the <nid> syntax rule in Section 2.1 of RFC 2141bis 
> [I-D.ietf-urnbis-rfc2141bis-urn] and it MUST adhere to constraints 
> specified in sec 4.3, above.
> 
> Applicants and the IANA experts have to ensure that the sought NID 
> strings are suitable and proper for the designated purpose and not 
> misleading, according to common sense and applicable legal rules. The
> IETF Review process gives interested parties the opportunity to rise
> concerns if they want to challenge proposed strings; the final 
> approval decision still remains with the IESG.
> 
> Registrations may be revised by updating the RFC through standard 
> IETF RFC update processes.  In any case, a revised document, in the 
> form of a new Internet-Draft, must be published, and the proposed 
> updated template must be circulated on the urn-nid discussion list, 
> allowing for a four-week review period before pursuing RFC 
> publication of the new document."

That all seems fine.

Peter

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