[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.
- [urn] 3406bis-07 -editorial comments John C Klensin
- Re: [urn] 3406bis-07 -editorial comments Peter Saint-Andre