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

["Svensson, Lars" <[e-mail]>]

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?

Sec. 4.1: Experimental namespaces

If we desire to register example as a NID, this whole section will probably not be needed any more.

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;
      -  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);
      -  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; 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."

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

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

Thanks and all the best,

Lars

***Lesen. Hören. Wissen. 100 Jahre Deutsche Nationalbibliothek***
***Reading. Listening. Understanding. A century of the German National Library***

-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek / Informationstechnik
http://www.dnb.de/
[e-mail]
http://www.dnb.de/100jahre