draft-rosen-urn-nena-00

[Alfred Hönes <[e-mail]>]

Hello,
I apologize for the belated review, but things happen ...

I also have a few remarks on your I-D, draft-rosen-urn-nena-00,
mostly editorial in nature (and overlapping my comments for the
cablelabs-urn draft, thus borrowing from that posting ...).


(1)  Abstract (ff.)

In some places in the draft text, I find terminological confusion
between "URN" (Uniform Resource Name") and "URN Namespace".
The first instance already is in the abstract; others will be
corrected as well below without further mention of the issue.

I suggest to correct the terminology, add precision and clarify
the first sentence in the Abstract as shown below; further, the
final sentence there (yet in a preliminary version) is perhaps
not required, as it does not add essential information for a
prospective reader, on whether or not she should read the memo.

|  This document describes the Namespace Identifier (NID) for Uniform
|  Resource Namespace (URN) resources published by National Emergency
   Number Association (NENA).  NENA defines and manages resources that
   utilize this URN name model.  Management activities for these and
   other resource types are provided by the National Emergency Number
|  Association (NENA) Registry System (NRS).  For the processes that NRS
|  uses to manage this and other registries, see NENA ??-???
---
   This document describes the Namespace Identifier (NID) 'nena' for
   Uniform Resource Names (URNs) used to identify resources published by
   National Emergency Number Association (NENA).  NENA defines and
   manages resources that utilize this URN name model.  Management
   activities for these and other resource types are provided by the
|  National Emergency Number Association (NENA) Registry System (NRS).


(2)  Section 1, 3rd para -- adding precision

   Some of the solutions being developed by NENA need XML namespaces
   that are managed so that they are unique and persistent.  To assure
   that the uniqueness is absolute, the registration of a specific
|  Namespace ID (NID) for use by NENA was deemed appropriate.
   Therefore, a full and complete registration will follow the namespace
   specification process as defined in [RFC3406].
---
   Some of the solutions being developed by NENA need XML namespaces
   that are managed so that they are unique and persistent.  To assure
   that the uniqueness is absolute, the registration of a specific
|  Uniform Resource Name (URN) [RFC2141] Namespace ID (NID) for use by
   NENA was deemed appropriate.  Therefore, a full and complete
   registration will follow the namespace specification process as
   defined in [RFC3406].


(3)  Section 2

(3a)  1st clause

I suggest to simplify and make the information better suited
for simple full-text search tools.  Please change:

| Namespace ID:
| The NID "nena" is requested.
---
| Namespace ID: nena

(3b)  Registration Information:  clause

The draft requests:

|   registration date: YYYY-MM-DD  [RFC Editor, please replace with the
|                                       data of publication of this RFC]

Procedurally, that is impractical (see the RFC Editor process
flowchart), because IANA action needs to be complete (but not yet
published) before the draft enters the AUTH48 state for final author
(and AD) review and signoff.  Usually, the date of approval of the
document is conceived as the act establishing the authority for the
registration and hence is used in the IANA registry and in the
published document.  Therefore, I suggest a more practical text:

|   registration date: YYYY-MM-DD
|     [RFC Editor: Please replace YYYY-MM-DD with the date
|     of approval of this document for publication as an RFC.]

(3c)  Declaration of syntactic structure:  clause

There is a contradiction in the draft text:

   Declaration of syntactic structure:
|  The Namespace Specific String (NSS) of all URNs that use the "nena"
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|  NID will have the following structure:
|
|  urn:nena:{NENAresource}:{ResourceSpecificString}
   ^^^^^^^^^
|  where the "NENAresource" is a US-ASCII string that conforms to the
   URN syntax requirements [RFC2141] and defines a specific class of
|  resource type.  Each resource type has a specific labeling scheme
   that is covered by "ResourceSpecificString", which also conforms to
   the naming requirements of [RFC2141].

The pattern indicated is *not* for the NSS (only) as explained in the
prose, but for a full 'nena' URN.  That's confusing.

Therefore, I strongly recommend to drop the constant elements not
being part of the NSS from the pattern (and adjust the indentation).
The text also is poorly balanced, placing the restrictions for one
syntactical element in the "where" clause of the first sentence and
comparable information for the other element into a second sentence.
I recommend to use shorter, independent sentences.
Also, the term 'class', once introduced should preferably also be
*used* to denote that subject.

Arguably, "NENAresource" and "ResourceSpecificString" are misnomers,
"NENAclass" or "NENArclass" and "ClassSpecificString" would be
better, respectively.

In total, still disregarding this final observation, the paragraph
above should better say:

        The Namespace Specific String (NSS) of all URNs that use the
        "cablelabs" NID will have the following structure:
|
|               {NENAresource}:{ResourceSpecificString}
|
|       The "NENAresource" is a US-ASCII string that conforms to the URN
        syntax requirements specified in [RFC2141] and defines a
|       specific class of resource type.  Each class will have a
        specific labeling scheme that is covered by
        "ResourceSpecificString", which also conforms to the naming
        requirements of [RFC2141].

In the subsequent paragraph, double-quoting once is unbalanced;
please    s/of NENAresources"/of "NENAresources"/

(4)  Section 3

(4a)
There's a typo disregarding the specified syntax.  Please correct:

|  Syntax: "urn:nena.emergencyresponders:<responder name>"
---                 ^
|  Syntax: "urn:nena:emergencyresponders:<responder name>"

(4b)
In the Examples list, the line
   urn:nena.emergencyresponders:ambulance
appears twice; please delete one instance.


(5)  Section 8

IMHO, RFC 2141 should be promoted to Normative!


(6)  Ceterum censeo ...

Apparently, this draft shares a lot of common text with other
documents.
If this draft is not the original source of that text, it is
deemed a question of politeness to recognize the authorship
in an 'Acknowledgments' section at the end of the document --
and arguably the applicable copyright rules (see BCP 78 and
the IETF Trust web site) even make this a legal requirement.


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+