From john-ietf@jck.com Tue Jan 21 22:55:10 2014 Return-Path: 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 89F441A02B3 for ; Tue, 21 Jan 2014 22:55:10 -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 BrfWspscvEJL for ; Tue, 21 Jan 2014 22:55:08 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 584191A024E for ; Tue, 21 Jan 2014 22:55:08 -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 ) id 1W5riL-000PO1-2U; Wed, 22 Jan 2014 01:55:05 -0500 Date: Wed, 22 Jan 2014 01:54:59 -0500 From: John C Klensin To: Peter Saint-Andre Message-ID: <8CE245D723DEE2BB953F028F@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 - substantive comments X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 06:55:10 -0000 Hi. Apologies for the long silence. The comments below are ones that WG participants should review because they contain suggestions for changes to the Namespace Definition Mechanisms spec (draft-ietf-urnbis-rfc3406bis-urn-ns-reg-07) that some may consider substantive. Editorial comments that are mostly for Peter by that I will post for the information of the WG will follow, as will an updated version of the transition I-D. best wishes to all for what is left of 2014 john ------------------------- (1) End of Section 4 proper (before 4.1): It seems to me that you need to say what happens with any Experimental namespaces that are in the registry. You should either say "there aren't any", specify that they are automatically reclassified as "formal", or specify that they have to be registered or re-registered using this document's template and indicate that formal namespaces starting in "x-" are explicitly allowed. Presumably the prohibition of trailing hyphens in 2141bis eliminates the possibility of someone registering "x-" itself as an NID, but clarity might benefit by mentioning that in this Note or in the syntax description bullets of Section 4.1. (2) End of Section 4.1: Just a question, but would there be any point in further reserving "xn--". (3) Section 4.2 or IANA Considerations (Section 9): I think this document needs to be clear about whether the expectation is that IANA will assign the next available number or whether applicants get to pick their favorite number as long as it isn't assigned already. I don't have a preference about the choice, but I think the document needs to give IANA clear instructions. (4) Given the recent and ongoing privacy snit, there are several places in this spec where at least a nod to potential privacy issues would be in order. For example, Section 5.4 might indicate that any privacy issues other than "leakage of..." should be described and the second paragraph of Section 10 might say "...potential security and privacy issues...". (5) Sections 6.9 and 8: I'd be a lot happier with this if there was a clear preference expressed for what the RFC Editor traditionally describes as a "stable specification", especially since IANA has seemingly gone out of the business of keeping library of documents submitted in support of registrations. That is expecially important given the formal non-archival status of I-Ds and the observation that "published document" doesn't have nearly as much meaning today as it might have had 20 or 30 years ago. If you/we really want to allow I-Ds, I recommend "Any Internet-Draft, RFC, specification, or other stable document..." in 6.9 and "...Expert Review and a stable and clear specification is not required, the designated experts for NID registration requests are encouraged to prefer that a stable specification exist documenting the namespace definition." in Section 8. I think the intent of that sentence in Section 8 might be a bit more clear if it said "...experts for NID registration requests should strongly encourage applicants to provide a stable specification that documents...". (6) Section 7.1, item 4: It seems to me that this allows a possibility in which the designated experts simply refuse to approve and application, perhaps by engaging in never-ending nitpicking. Do we need an appeal procedure? From john-ietf@jck.com Tue Jan 21 23:07:42 2014 Return-Path: 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 ; 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 ; 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 ; 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 ) 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 To: Peter Saint-Andre 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. From john-ietf@jck.com Wed Jan 22 01:01:46 2014 Return-Path: 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 3C9DA1A0150 for ; Wed, 22 Jan 2014 01:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.135 X-Spam-Level: X-Spam-Status: No, score=-5.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 u8In85hfN5UH for ; Wed, 22 Jan 2014 01:01:42 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id F15EF1A008E for ; Wed, 22 Jan 2014 01:01:41 -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 ) id 1W5tgr-000PwR-3P; Wed, 22 Jan 2014 04:01:41 -0500 Date: Wed, 22 Jan 2014 04:01:36 -0500 From: John C Klensin To: Peter Saint-Andre Message-ID: 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] 2141bis-06 -syntax and internationalization (maybe 3406bis too) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 09:01:46 -0000 Hi. In reviewing 3406bis, I discovered what may be some issues in the basic syntax definitions in 2141bis that might require changes to 3406bis as well. draft-ietf-urnbis-rfc2141bis-urn-06 defines the syntax for an NID in terms of plus embedded hyphens. Since (from 3986) is restricted to ASCII letters and digits, non-ASCII characters are prohibited, even in %-escaped form. That seems wise to me, but I want to be sure everyone is aware of it. Also, names with leading digits have a long history of causing problems. Noting that informal namespaces start with "urn-" and not with the digits that follow, unless there is a good reason to allow NIDs with numeric digits, I think we should disallow them. So... Suggestions: (1) In Section 4, change Old: NID = (alphanum) 0*30(ldh) (alphanum) New: NID = (ALPHA) 0*30(ldh) (alphanum) and, if the editor things it necessary, change Old: ; alphanum is defined in RFC 3986 New: ; alphanum is defined in RFC 3986 ; ALPHA is defined in RFC 5234 (2) Add a brief "Internationalization" section, as required by RFC 2277, to explain why NIDs are expected to remain ASCII-only protocol identifiers. In addition, the current definition for NSS is based on pchar, which allows percent-encoded non-ASCII characters as well as other things. Given the somewhat confused state of IRIs [1] and the stability and persistence requirements for URNs, I'd prefer that we restrict the use of percent-encoding in NSSs to ASCII characters only, i.e., escaping the reserved characters of RFC 3986. If that is not possible, i.e., if people are convinced that non-ASCII characters must really be allowed in the NSS part of a URN, I believe that 3406bis should discourage that usage and should add an i18n section to the template that specifies whether or not non-ASCII characters are permitted (with a clear default of "no") and, if they are, explain why and under what circumstances. That template change would suggest that 3406bis should have an "Internationalization" section as well. best, john [1] As far as I can tell, we've got an IETF Proposed Standard (RFC 3987) that is sufficiently in need of updating that we chartered a WG to do the work, a WG that shut down without either doing that work or clarifying applicability, and a W3C effort that could produce either a competing standard or at least clarifications/ interpretations that would fork 3987 in practice if not in theory. From internet-drafts@ietf.org Wed Jan 22 01:19:21 2014 Return-Path: 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 55DD81A03F3; Wed, 22 Jan 2014 01:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 fgT8bcspL0kV; Wed, 22 Jan 2014 01:19:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 479DA1A03DE; Wed, 22 Jan 2014 01:19:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140122091919.16620.34675.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2014 01:19:19 -0800 Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-ns-reg-transition-01.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 09:19:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Uniform Resource Names, Revised Working G= roup of the IETF. Title : Uniform Resource Name (URN) Namespace Registratio= n Transition Authors : John C Klensin Juha Hakala Filename : draft-ietf-urnbis-ns-reg-transition-01.txt Pages : 6 Date : 2014-01-22 Abstract: The original registration procedure for formal Uniform Resource Name (URN) namespaces required IETF Consensus. That requirement discouraged some registrations and increased the risk for problems that could occur as a result. The requirements have now been changed in [[RFC 3406bis]] to adopt a different model. This document specifies IANA instructions to adapt selected existing registrations to the new model. It also obsoletes some previous RFCs to eliminate any ambiguity about the status of new templates and updated registrations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-reg-transition/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-urnbis-ns-reg-transition-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-urnbis-ns-reg-transition-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stpeter@stpeter.im Thu Jan 23 16:03:30 2014 Return-Path: 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 D3DE61A0485 for ; Thu, 23 Jan 2014 16:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.837 X-Spam-Level: X-Spam-Status: No, score=-3.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 0YBEEfOiu3sL for ; Thu, 23 Jan 2014 16:03:29 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 491421A01D3 for ; Thu, 23 Jan 2014 16:03:29 -0800 (PST) Received: from [192.168.1.6] (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B80AF400AD; Thu, 23 Jan 2014 17:03:27 -0700 (MST) Message-ID: <52E1ADCE.8000502@stpeter.im> Date: Thu, 23 Jan 2014 17:03:26 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: John C Klensin References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] 2141bis-06 -syntax and internationalization (maybe 3406bis too) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 00:03:31 -0000 Hi John, thank you for raising these issues. On 01/22/2014 02:01 AM, John C Klensin wrote: > Hi. In reviewing 3406bis, I discovered what may be some issues > in the basic syntax definitions in 2141bis that might require > changes to 3406bis as well. > > draft-ietf-urnbis-rfc2141bis-urn-06 defines the syntax for an > NID in terms of plus embedded hyphens. Since > (from 3986) is restricted to ASCII letters and > digits, non-ASCII characters are prohibited, even in %-escaped > form. That seems wise to me, but I want to be sure everyone is > aware of it. Also, names with leading digits have a long > history of causing problems. Noting that informal namespaces > start with "urn-" and not with the digits that follow, unless > there is a good reason to allow NIDs with numeric digits, I > think we should disallow them. I'll note that the following NIDs are already registered: 3gpp s1000d web3d http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml Have these caused harm? Personally I am not worried about them, but I might be missing something. > So... > > Suggestions: > > (1) In Section 4, change > > Old: > NID = (alphanum) 0*30(ldh) (alphanum) > New: > NID = (ALPHA) 0*30(ldh) (alphanum) > > and, if the editor things it necessary, change > > Old: > ; alphanum is defined in RFC 3986 > New: > ; alphanum is defined in RFC 3986 > ; ALPHA is defined in RFC 5234 > > (2) Add a brief "Internationalization" section, as > required by RFC 2277, to explain why NIDs are expected > to remain ASCII-only protocol identifiers. We definitely need that, yes. > In addition, the current definition for NSS is based on pchar, > which allows percent-encoded non-ASCII characters as well as > other things. Given the somewhat confused state of IRIs [1] and > the stability and persistence requirements for URNs, I'd prefer > that we restrict the use of percent-encoding in NSSs to ASCII > characters only, i.e., escaping the reserved characters of RFC > 3986. > > If that is not possible, i.e., if people are convinced that > non-ASCII characters must really be allowed in the NSS part of a > URN, I believe that 3406bis should discourage that usage and > should add an i18n section to the template that specifies > whether or not non-ASCII characters are permitted (with a clear > default of "no") and, if they are, explain why and under what > circumstances. That template change would suggest that 3406bis > should have an "Internationalization" section as well. Personally I am not convinced that non-ASCII characters must be allowed in the NSS part of a URN, so I find your proposal acceptable. Peter From internet-drafts@ietf.org Thu Jan 23 18:41:21 2014 Return-Path: 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 94CD11A02D4; Thu, 23 Jan 2014 18:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 MaflBRUo5uHW; Thu, 23 Jan 2014 18:41:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 475661A0201; Thu, 23 Jan 2014 18:41:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140124024120.24777.58147.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2014 18:41:20 -0800 Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-07.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 02:41:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Uniform Resource Names, Revised Working G= roup of the IETF. Title : Uniform Resource Name (URN) Syntax Author : Peter Saint-Andre Filename : draft-ietf-urnbis-rfc2141bis-urn-07.txt Pages : 9 Date : 2014-01-23 Abstract: A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is intended to serve as a persistent, location-independent resource identifier. This document defines the canonical syntax for URIs under the "urn" scheme, guidelines for URN namespaces, requirements for URN presentation and transmission, and methods for determining URN equivalence. This document obsoletes RFC 2141. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-urnbis-rfc2141bis-urn-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stpeter@stpeter.im Thu Jan 23 18:42:46 2014 Return-Path: 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 370491A035A for ; Thu, 23 Jan 2014 18:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 8wQ4ySalqCbX for ; Thu, 23 Jan 2014 18:42:44 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1CC1A0380 for ; Thu, 23 Jan 2014 18:42:44 -0800 (PST) Received: from [192.168.1.6] (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 09AF7400AD; Thu, 23 Jan 2014 19:42:42 -0700 (MST) Message-ID: <52E1D322.5020601@stpeter.im> Date: Thu, 23 Jan 2014 19:42:42 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: urn@ietf.org References: <20140124024120.24777.58147.idtracker@ietfa.amsl.com> In-Reply-To: <20140124024120.24777.58147.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-07.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 02:42:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Some small editorial changes... On 01/23/2014 07:41 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Uniform Resource > Names, Revised Working Group of the IETF. > > Title : Uniform Resource Name (URN) Syntax Author > : Peter Saint-Andre Filename : > draft-ietf-urnbis-rfc2141bis-urn-07.txt Pages : 9 Date > : 2014-01-23 > > Abstract: A Uniform Resource Name (URN) is a Uniform Resource > Identifier (URI) that is intended to serve as a persistent, > location-independent resource identifier. This document defines > the canonical syntax for URIs under the "urn" scheme, guidelines > for URN namespaces, requirements for URN presentation and > transmission, and methods for determining URN equivalence. This > document obsoletes RFC 2141. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-07 > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ urn mailing list > urn@ietf.org https://www.ietf.org/mailman/listinfo/urn > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS4dMhAAoJEOoGpJErxa2ptJAP/jYaMQbsW2bTUu4U3IEOPmKl lgLa2zwAIPcCvZ2r9+mqt5x6LSkTyBHzcDaaN7+YkmC/cDNh96Rz9fBa0IG6+EQf wvx6iZT2y7brut/PXZLQHwSUfE/1028wiMv9hJR8mdFhcPZA4J5V+cNLf+0u8BX8 pFb+fthnYSjzw7YRfxy8+Z/b8JbAZjABoxLAB6kavO4OSPhAp6CwaCCNCmLfmzAR Jn01K/3mz5tdoSMceU/Hm8a/wu7fXktsydR31plRgWue7tmVkIi6Wm6R2Ok6vHS9 5GTMSbc6bUIkOFNJ+UXmyliRQe3616b9CTB6FmD7s/HfkwPVOZaO37q4PajMK5E7 x5Th0srSP0kOz1m7FeAQPkBCbpBZ0swhWBIP84yozeMLiXdLpUeDHLgxx2cR0heZ xuAZlPrU3uax5Azud6r26AiPPUpZgy8IKte1o0d0GDimF7t5yV/FP/70+orx/PrG 7JJZWzwWYGyAQTGOJNkSH5l7RL/AYOCaffP/mwz10vlT5nPlI5o3vzeR0T3j0q7e zM4mA+qZSO2jvLEBc4B6p6jhJ1FBK1JuMV5tz52nMmMf04l5qd5uyxJCoMy+NAIQ YPst2lZkKekDwE1lGJ5f5omckLHtDfaTGDbU+G5E15N6dUZFGiWIfShz1ARfhtxn nnaCn1YDvXYKBzmDWGOO =n0rj -----END PGP SIGNATURE----- From john-ietf@jck.com Fri Jan 24 02:13:50 2014 Return-Path: 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 56B521A018D for ; Fri, 24 Jan 2014 02:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.535 X-Spam-Level: X-Spam-Status: No, score=-4.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_31=0.6, 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 KunPXC_OvR2L for ; Fri, 24 Jan 2014 02:13:46 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id D0C191A0226 for ; Fri, 24 Jan 2014 02:13:46 -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 ) id 1W6dlf-0004jJ-HF; Fri, 24 Jan 2014 05:13:43 -0500 Date: Fri, 24 Jan 2014 05:13:38 -0500 From: John C Klensin To: Peter Saint-Andre Message-ID: <6DDB5C8621F987BC10E0663A@JcK-HP8200.jck.com> In-Reply-To: <52E1ADCE.8000502@stpeter.im> References: <52E1ADCE.8000502@stpeter.im> 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: Re: [urn] 2141bis-06 -syntax and internationalization (maybe 3406bis too) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 10:13:50 -0000 --On Thursday, January 23, 2014 17:03 -0700 Peter Saint-Andre wrote: > Hi John, thank you for raising these issues. > > On 01/22/2014 02:01 AM, John C Klensin wrote: >> Hi. In reviewing 3406bis, I discovered what may be some >> issues in the basic syntax definitions in 2141bis that might >> require changes to 3406bis as well. >> >> draft-ietf-urnbis-rfc2141bis-urn-06 defines the syntax for an >> NID in terms of plus embedded hyphens. Since >> (from 3986) is restricted to ASCII letters and >> digits, non-ASCII characters are prohibited, even in %-escaped >> form. That seems wise to me, but I want to be sure everyone >> is aware of it. Also, names with leading digits have a long >> history of causing problems. Noting that informal namespaces >> start with "urn-" and not with the digits that follow, unless >> there is a good reason to allow NIDs with numeric digits, I >> think we should disallow them. > > I'll note that the following NIDs are already registered: > > 3gpp > s1000d > web3d > > http://www.iana.org/assignments/urn-namespaces/urn-namespaces. > xhtml > > Have these caused harm? Personally I am not worried about > them, but I might be missing something. Of course, only the first of these would violate a "no leading digits" rule. But the existence of that one may be a compelling argument to say "too late to impose a more restrictive, no-leading-digits, rule, let's move on". >> So... >> >> Suggestions: >... >> (2) Add a brief "Internationalization" section, as >> required by RFC 2277, to explain why NIDs are expected >> to remain ASCII-only protocol identifiers. > > We definitely need that, yes. >> In addition, the current definition for NSS is based on pchar, >> which allows percent-encoded non-ASCII characters as well as >> other things. Given the somewhat confused state of IRIs [1] >> and the stability and persistence requirements for URNs, I'd >> prefer that we restrict the use of percent-encoding in NSSs >> to ASCII characters only, i.e., escaping the reserved >> characters of RFC 3986. >> >> If that is not possible, i.e., if people are convinced that >> non-ASCII characters must really be allowed in the NSS part >> of a URN, I believe that 3406bis should discourage that usage >> and should add an i18n section to the template that specifies >> whether or not non-ASCII characters are permitted (with a >> clear default of "no") and, if they are, explain why and >> under what circumstances. That template change would suggest >> that 3406bis should have an "Internationalization" section as >> well. > > Personally I am not convinced that non-ASCII characters must > be allowed in the NSS part of a URN, so I find your proposal > acceptable. As we know from IDNA, PRECIS, and other work, allowing non-ASCII characters in identifiers requires that we dive into a rather large can of venomous serpents (not merely open one containing worms). IMO, there should be a really compelling argument for going down that path. I'm not convinced either... and strongly suspect that compelling argument doesn't exist. thanks, john From stpeter@stpeter.im Fri Jan 24 09:42:51 2014 Return-Path: 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 8F42E1A000B for ; Fri, 24 Jan 2014 09:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 vz-M3lz11hst for ; Fri, 24 Jan 2014 09:42:49 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F34451A0006 for ; Fri, 24 Jan 2014 09:42:48 -0800 (PST) Received: from ergon.local (unknown [64.101.72.104]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F407D400AD; Fri, 24 Jan 2014 10:42:46 -0700 (MST) Message-ID: <52E2A615.5080200@stpeter.im> Date: Fri, 24 Jan 2014 10:42:45 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: John C Klensin References: <9A334FA8F11296BE57D85C03@JcK-HP8200.jck.com> In-Reply-To: <9A334FA8F11296BE57D85C03@JcK-HP8200.jck.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] 3406bis-07 -editorial comments X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 17:42:51 -0000 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-" > (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/ From internet-drafts@ietf.org Fri Jan 24 09:46:28 2014 Return-Path: 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 D6BD01A0037; Fri, 24 Jan 2014 09:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 XcEqqXoZMhFs; Fri, 24 Jan 2014 09:46:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBB31A0006; Fri, 24 Jan 2014 09:46:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140124174627.18236.63764.idtracker@ietfa.amsl.com> Date: Fri, 24 Jan 2014 09:46:27 -0800 Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-08.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 17:46:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Uniform Resource Names, Revised Working G= roup of the IETF. Title : Uniform Resource Name (URN) Namespace Definition = Mechanisms Author : Peter Saint-Andre Filename : draft-ietf-urnbis-rfc3406bis-urn-ns-reg-08.txt Pages : 14 Date : 2014-01-24 Abstract: This document supplements the Uniform Resource Name (URN) syntax specification by defining the concept of a URN namespace, as well as mechanisms for defining and registering such namespaces. This document obsoletes RFC 3406. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc3406bis-urn-ns-reg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-urnbis-rfc3406bis-urn-ns-reg-= 08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/