Subject: Re: [urn] Comments on draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 03 Jul 2012 14:03:38 -0600

On 6/27/12 5:17 PM, SM wrote:

> Hi,
> 
> This comments are on draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.  The
> Abstract Section is too long.  The draft is about procedures to register
> a URN namespace.
> 
> In the Introduction Section:
> 
>   "URNs are part of the larger Uniform Resource Identifier (URI) family
>    (see the joint W3C/IETF memorandum, RFC 3305 [RFC3305], and the IETF
>    STD 66, RFC 3986 [RFC3986]) with the specific goal of providing
>    persistent naming of resources."
> 
> The first line is useful; the rest is unnecessary information.

Good edit.

>   "To actually leverage the potential synergetic advantage of this
>    unification"
> 
> This is not a document about pharmaceuticals. :-)

Yes, that's some kind of marketing-speak.

>   'The purpose of this document is to outline a mechanism and provide a
>    template for explicit URN Namespace definition, as well as provide
>    the mechanism for associating an identifier (called a "Namespace ID",
>    or NID), which is registered with the Internet Assigned Numbers
>    Authority (IANA) [IANA] in the URN Namespaces registry maintained at
>    [IANA-URN].'
> 
> Could this text be made shorter?

Sure it could: "This document defines procedures for registering URN
Namepace Identifiers (NIDs) with IANA."

>   "The URN Namespace definition and registration mechanisms originally
>    have been specified in RFC 2611 [RFC2611], which has been obsoleted
>    by BCP 66, RFC 3406 [RFC3406].  Guidelines for documents prescribing
>    IANA procedures have been revised as well over the years, and at the
>    time of this writing, BCP 26, RFC 5226 [RFC5226] is the normative
>    document.  This document is a revision of RFC 3406 based on the
>    revised URN Syntax specification RFC 2141bis
>    [I-D.ietf-urnbis-rfc2141bis-urn] and RFC 5226."
> 
> There is ample historical information.  Is it necessary in the
> introduction?

I don't think so.

> The discussion about URN namespace (Section 2) should be moved to
> draft-ietf-urnbis-rfc2141bis-urn-02.

That seems sensible.

> In Section 3.1:
> 
>   "No provision is made for avoiding collision of experimental NIDs;
>    they are intended for use within internal or limited experimental
>    contexts.  However, as described below in Section 4.1, these are
>    designated by a specific form of the NID to allow differentiation
>    (without preexisting knowledge of details) from the other URN
>    Namespace types."
> 
> This could be formulated as guidance about when NIDs should be
> registered.  Given the discussion about X- for other protocols, it's
> better to also drop it here.

I think it would be helpful to register the 'example' NID
(urn:example:*) and deprecate the experimental NIDs. I'd be happy to
write an I-D registering the NID.

> In Section 4:
> 
>   "The IANA Considerations Guidelines document (BCP 26 [RFC5226])
>    suggests the need to specify update mechanisms for registrations --
>    who is given the authority to do so, from time to time, and what are
>    the processes."
> 
> Why is this text needed in this draft?

I doubt it.

>   "The official list of registered URN Namespaces is currently
>    maintained by IANA at [IANA-URN]."
> 
> The "who" is not important.  What is important is to point the reader to
> the location of the list of URN Namespaces.

Sure.

> In Section 4.3:
> 
>   "The designated expert(s) for URN Namespace registrations are
>    nominated by the IESG, and their role adheres to the regulations
>    in BCP 26, unless specified otherwise below."
> 
> BCPs are not about regulations.  I suggest using the term "guidelines".

Good point.

>   '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).'
> 
> Who are the IANA experts?

Perhaps the author meant the designated experts.

>   '"IETF Review" (per [RFC5226]) means that the Formal NID application
>    is made via submission to the IETF of an Internet-Draft that contains
>    the Namespace definition and targets publication as an RFC of
>    Informational or Standards-Track category, which needs to be approved
>    by the IESG after performing an IETF Last Call on the document and
>    evaluating review comments.  The applicant can be an individual or an
>    IETF working group, in alignment with the designation of the
>    Internet-Draft.  The actual choice should be properly considered by
>    applicants, but it is RECOMMENDED that the registration documents for
>    NIDs belonging to an established standard namespace aim at Standards-
>    Track, whereas other applications aim at Informational RFC.'
> 
> There is a reference to RFC 5226 in this draft.  The reader interested
> in the details of "IETF Review" can find the information in that RFC.  I
> don't think that it is a good idea to explain about IETF process in this
> draft.

Agreed.

> In Section 4.4.3:
> 
>   'According to the general procurements for RFCs, URN Namespace
>    definition documents must include a "Security Considerations" section
>    (cf. BCP 72 [RFC3552]).  That section has to identify the security
>    considerations specific to the subject URN Namespace.'
> 
> The above should be trimmed.  Provide the reader with actionable
> information so that the person knows what security issues to look out for.
> 
> Why is Section 4.4.4 needed?  This should be more about how to devise an
> appropriate registration request.  This section seems like registration
> guidelines.

Yeah, there's a lot of step-by-step information here. I'm not sure how
useful it is. I'd prefer to tell people the general rules and then
recommend that they look at some of the recent registration documents.

> In Section 6:
> 
>   "Until recently, that registry has been available in HTML, XML, and
>    plain text from the generic web page at
>    <http://www.iana.org/assignments/urn-namespaces/> [IANA-URN]"
> 
> Why is it important to tell IANA that the registry is available in three
> formats?

It isn't.

> Appendix A is informative for the registrant.  I suggest separating the
> template and the "how to fill" information.
> 
> AppendiX B reminds me of another RFC where the WG replicated information
> about procedures to help future authors.  The draft should be about the
> registration steps in practice instead of a "formal" section and the
> actual steps.

Agreed.

Peter

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

---

From: "Svensson, Lars" <[email-masked]>
Date: Tue, 10 Jul 2012 14:11:02 +0000

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/
[email-masked]
http://www.dnb.de/100jahre

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Jul 2012 16:20:08 -0600

On 7/10/12 8:11 AM, Svensson, Lars wrote:
> 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."

> probably not be needed any more.

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

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

> 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 

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

> This might not be correct if the registration request is for an

Corrent.

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

That all seems fine.

Peter

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