Subject: [urn] 3406bis-07 -editorial comments

From: John C Klensin <[email-masked]>
Date: Wed, 22 Jan 2014 02:07:35 -0500

Peter, 

Editorial comments on draft-ietf-urnbis-rfc3406bis-urn-ns-reg-07

WG,

For information.

best,
   john

 -------------------------

(1) Section 3, item 1: Suggest adding something like "even if
the identifier itself is deprecated or becomes obsolete" to the
end of the sentence to make the intent completely clear.

(2) Section 3, item 2: Please get rid of "minted".  I know what
it means in this context, but, for anyone not completely
familiar with colloquial American English, it is weird and
might imply, e.g., vigorously rubbing the identifier with mint.
:-)

(3) End of Section 3: "URN namespaces inherit certain rights
and responsibilities, e.g.:" would be a lot more clear if it
said "...responsibilities from [[reference]], e.g.:"

(4) Section 4.1, parenthetial note in first sentence:
Partially because of the double negative, I can't parse this
well enough to know what is intended.

(5) Section 4.2:  I finally figured out why you said
"alphanumeric" but, since the part after "urn-" is entirely
numeric and 2141bis restricts all NIDs to alphanumeric, it
is confusing and doesn't add information.  Couldn't you just
say "IANA will assign an NID consisting of the string 'urn-'
followed by one or more digits" and then clean the rest of the
sentence up as needed?  And wouldn't that be more clear?

(6) Section 5.1, bullet 2:  This is hard to follow.  I suggest
that "...and why no existing URN namespace is a good fit."
would be more clear and convey what I think was intended.

(7) Section 5.1, bullet 4: I know what this example intends,
but the term "social security" is actually problematic.  For
example, in some countries, a term is used that would translate
exactly as "social welfare" but that a different translator
might render as "social security".  We need to start assuming
that RFCs will be translated and that the translations will be
done my amateurs, and this could create a bit of a mess.  I
don't know quite what to do with it, but your "global" case
might indicate that the hypothetical global namespace also
needs to be concerned with concepts that might reasonably be
translated into "social security".

(8) Section 5.2, bullet 3, last sentence: I think this would be
slightly more clear if it said "...they are statements limited
to one particular specific namespace only.)"  (or drop
"specific" from that because it is mostly redundant).

(9) Section 5.3, last bullet: If I understand the intent of
this rule, it would be helpful to add "or intended to support
global identification" at the end of the sentence.  If that is
not consistent with the intent, I'm confused.

(10) Section 7.2:  If the applicant gets to specify a preferred
number for assignment, this section probably needs to indicate
that the number should be supplied to IANA.  If the applicant
doesn't, then this is fine.

(11) (General): this spec used bullet lists in many places and
numbered lists in a few.  I was unable to discover the
rationale for which form was used where.  Unless there is one
and it is obvious to others, I recommend picking one and
staying with it.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 24 Jan 2014 10:42:45 -0700

> Editorial comments on draft-ietf-urnbis-rfc3406bis-urn-ns-reg-07

Thanks, John.

For various reasons, I'll process these today and push out an updated
version. I'll then work on the substantive issues separately (and soon).

Comments in line.

Good point.

> might imply, e.g., vigorously rubbing the identifier with mint.

I've changed "mint" to "create".

> said "...responsibilities from [[reference]], e.g.:"

How about this?

   URN namespaces inherit certain rights and responsibilities by the

> well enough to know what is intended.

I suggest:

   A formal namespace provides benefit to some subset of users on the
   Internet (e.g., it would not make sense for a formal namespace to be
   used only by a community or network that is not connected to the
   Internet).

> sentence up as needed?  And wouldn't that be more clear?

Yes, it would. :-)

I suggest:

   Informal namespaces are full-fledged URN namespaces, with all the
   associated rights and responsibilities.  Informal namespaces differ
   from formal namespaces in the process for assigning a NID: for an
   informal namespace, IANA will assign an NID consisting of the string
   'urn-' followed by one or more digits (e.g., "urn-7").  Thus the
   syntax of an informal namespace is:

       "urn-" <number>

> would be more clear and convey what I think was intended.

Much better.

> translated into "social security".

Yes, this example has bothered me, too (it comes from RFC 3406, which
was published in 2002, when perhaps we were less attuned to such matters).

This seems more neutral:

   o  The scope of the namespace (public vs. private, global vs. local
      to a particular organization, nation, or industry).  For example,
      a namespace claiming to deal in "national identification numbers"
      ought to have a global scope and address all identity number
      structures, whereas a URN scheme for a particular national
      identification number system would need to handle only the
      structure for that nation's identity numbers.

> "specific" from that because it is mostly redundant).

Acknowledged.

> not consistent with the intent, I'm confused.

I would prefer to remove this bullet, since I don't think it adds much
if anything to the considerations mentioned elsewhere in the document.

> doesn't, then this is fine.

As I understand it, the applicant doesn't get to request a number, it's
simply assigned by IANA.

> and it is obvious to others, I recommend picking one and

Numbered lists seem fine.

I'll submit a revised I-D in the next few minutes, then work on your
substantive comments as soon as possible.

Thanks again,

Peter

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