[urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-02

[SM <[e-mail]>]

Hi,

These comments are on draft-ietf-urnbis-rfc2141bis-urn-02.  The 
comments may sound abrupt.  It is not intentional.

In the Abstract Section:

   "The requirements and procedures for URN Namespace registration
    documents are set forth in BCP 66, for which RFC 3406bis is the
    companion revised specification document replacing RFC 3406."

The above paragraph isn't relevant to the document contents.

In the Introduction Section:

   "Uniform Resource Names (URNs) are intended to serve as persistent,
    location-independent, resource identifiers and are designed to make
    it easy to map other namespaces (that share the properties of URNs)
    into URI-space."

RFC 3986 mentions that 'the term "Uniform Resource Name" (URN) has 
been used historically to refer to both URIs under the "urn" scheme 
[RFC2141], which are required to remain globally unique and 
persistent even when the resource ceases to exist or becomes 
unavailable, and to any other URI with the properties of a 
name'.  The above text does not mention global uniqueness and 
persistence even when the resource ceases to be unavailable.  Are 
those characteristics important?

In Section 1.1:

   "Since this RFC will be of particular interest for groups and
    individuals that are interested in persistent identifiers in general
    and not in continuous contact with the IETF and the RFC series, this
    section gives a brief outline of the evolution of the matter over
    time.  Appendix E gives hints on how to obtain RFCs and related
    information."

This is unnecessary.  if a person cannot find RFC XXXX, it's unlikely 
that the person would find this document.

   "Registration procedures for URI Schemes originally had been laid down
    in RFC 2717 [RFC2717] and guidelines for the related specification
    documents were given in RFC 2718 [RFC2718].  These documents have
    been obsoleted and consolidated into BCP 35, RFC 4395 [RFC4395], which
    is based on, and aligned with, RFC 3986."

The history of the registration procedures is not as important.  I 
suggest moving it into an appendix if the author wants to keep that 
information.  I found the text informative but most readers won't 
share that view.

In Section 1.2:

   "This section aims at quoting requirements as identified in the past;
    it does not attempt to revise or redefine these requirements, but it
    gives some hints where more than a decade of experience with URNs has
    shed a different light on past views.  The citations below are given
    here to make this document self-contained and avoid normative down-
    references to old work."

Such information might only be informative for a small subset of IETF 
participants.  People reading a document about URN syntax might find 
it confusing.  This this is a stylistic nit.  I suggest targeting the 
average reader.  Describe the properties of URNs and move the 
historical information to an appendix if the author would like to keep that.

In Section 1.3:

   "RFC 2141 does not seamlessly match current Internet Standards.  The
    primary objective of this document is the alignment with the URI
    standard [RFC3986] and URI Scheme guidelines [RFC4395], the ABNF
    standard [RFC5234] and the current IANA Guidelines [RFC5226] in
    general.

The objective should be in the Introduction Section.  Move the 
Historical information to the section about history.

   "For advancing the URN specification on the Internet Standards-Track,
    it needs to be based on documents of comparable maturity.  Therefore,
    to further advancements of the formal maturity level of this RFC, it
    deliberately makes normative references only to documents at Full
    Standard or Best Current Practice level."

This above is not that useful in the context of this document.

In Section 2:

   "The syntax definitions below do, and syntax definitions in dependent
    documents MUST, conform to the URI syntax specified in RFC 3986, in
    the sense that additional syntax rules must only constrain the
    general rules from RFC 3986."

This requirement is incorrect as it isn't that good to have one based 
on "dependent documents".  Keep the text simple by telling the reader 
what are the syntax requirements.

   "RFC 2141 was published before the URI Generic Syntax was finalized
    and therefore had to defer the decision on whether <query> and
    <fragment> components are applicable to URNs.  RFC 2141 therefore
    has reserved the use of bare (unencoded) question mark ("?") and
    hash ("#") characters in URNs for future usage in conformance with
    the generic URI syntax."

What's the impact of keeping this; i.e. would it break a generic URI parser?

   "The <fragment> part is not generally allowed in URNs.  It is only
    applicable to URN Namespaces that specifically opt to support its
    usage."

I suggest removing this sentence or rewording the following sentence 
to cover the optional (MAY) case.

Section 2 comes out as being too lengthy.

In Section 2.1:

   "To avoid confusion with the URI Scheme name "urn", the NID "urn" is
    permanently reserved by this RFC and MUST NOT be used or registered."

If this memo reserves the NID, it cannot be registered.

In Section 3:

   "Any identifier to be used as a URN MUST be expressed in conformance
    with the URI and URN syntax specifications ([RFC3986], this
    document)."

Why is this requirement necessary?

In Section 6:

   "Namespace registrations must include guidance on how to determine
    functional equivalence for that URN Namespace, i.e., when two URNs
    are identical within a namespace."

Why is the above in this document?

In Section 7:

   "At the time of publication of RFC 2141, no formal registration
    procedure for URI Schemes had been established yet, and so IANA only
    informally has registered the 'urn' URI Scheme with a reference to
    [RFC2141]."

The above paragraph is not important within the context of this document.

Although the draft is well-written, it was tedious for me to find 
actionable information.  This turned into a disincentive to suggest 
text changes.  RFC 2141 contained eight pages.  The draft contains 32 
pages.  I suggest trimming the text.  Using RFC 3906 as an 
example.  the draft is clear when it discusses about syntax components.

Regards,
-sm