[urn] 3406bis-07 -editorial comments

John C Klensin <john-ietf@jck.com> Wed, 22 January 2014 07:07 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570F11A02B7 for <urn@ietfa.amsl.com>; Tue, 21 Jan 2014 23:07:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.135
X-Spam-Level:
X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITpfLwq2qOnM for <urn@ietfa.amsl.com>; Tue, 21 Jan 2014 23:07:40 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7771A02B5 for <urn@ietf.org>; Tue, 21 Jan 2014 23:07:40 -0800 (PST)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1W5ruW-000PPD-5E; Wed, 22 Jan 2014 02:07:40 -0500
Date: Wed, 22 Jan 2014 02:07:35 -0500
From: John C Klensin <john-ietf@jck.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <9A334FA8F11296BE57D85C03@JcK-HP8200.jck.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: urn@ietf.org
Subject: [urn] 3406bis-07 -editorial comments
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 07:07:42 -0000

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.