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

[Peter Saint-Andre <[e-mail]>]

On 1/22/14 12:07 AM, John C Klensin wrote:
> Peter, 
> 
> 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.

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

Good point.

> (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.
> :-)

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

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

How about this?

   URN namespaces inherit certain rights and responsibilities by the
   nature of URNs [I-D.ietf-urnbis-rfc2141bis-urn], 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.

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

> (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?

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>

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

Much better.

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

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.

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

Acknowledged.

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

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.

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

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

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

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/