From nobody Wed Mar 4 06:45:31 2015 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 BE1371A1A0C for ; Wed, 4 Mar 2015 06:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 iYPZ5dFU7SWx for ; Wed, 4 Mar 2015 06:45:28 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28D531A1B51 for ; Wed, 4 Mar 2015 06:45:21 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YTAY4-0008ex-17 for urn@ietf.org; Wed, 04 Mar 2015 09:45:20 -0500 Date: Wed, 04 Mar 2015 09:45:15 -0500 From: John C Klensin To: urn@ietf.org 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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] Resolution services and Section 7.5 of draft-ietf-urnbis-rfc2141bis-urn-09 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, 04 Mar 2015 14:45:29 -0000 Hi. I've gotten several offlist comments about this document that require attention. In several cases, I've incorporated responses as or with notes in what will become -10 assuming those will become the text if no one objects. However, a few of them seem to require WG consideration. This is the first note in that series. Section 7.5 of draft-ietf-urnbis-rfc2141bis-urn-09 seems to be a little more specific about resolution than the direction in which we seem to be headed. In particular, it calls out the notion of registration of the namespace with an RFC 2276 Resolution Discovery System, an idea that has been honored mostly in the breach, and calls out DDDS, which I believe has not been used very much for URNs (if I'm wrong, details would be appreciated). If we are going to retain the DDDS example, it needs a reference (probably easy). However, the section also says "Resolution then proceeds according to standard URI resolution processes, as well as the mechanisms of the RDS." In contemporary terms, that is probably Section 5 of 3986, but that section not only goes well beyond what I think was contemplated when RFC 2141 was written but is mostly made irrelevant to URNs by the "syntax only" decision. One possibility is just to strip the RDS and DDDS material out of that paragraph, saying instead: The "Resolution" section specifies the rules for resolution of URNs assigned within the namespace. This section SHOULD list the requirements for becoming a recognized resolver of URNs in the relevant namespace. Answers might include, but are not limited to: Other suggestions and comments welcome. john From nobody Wed Mar 4 07:16:57 2015 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 3741E1A6EDB for ; Wed, 4 Mar 2015 07:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 Pc0X5yWfy7Ul for ; Wed, 4 Mar 2015 07:16:50 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8E541A6EF9 for ; Wed, 4 Mar 2015 07:16:50 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YTB2X-0008j7-Ss for urn@ietf.org; Wed, 04 Mar 2015 10:16:49 -0500 Date: Wed, 04 Mar 2015 10:16:44 -0500 From: John C Klensin To: urn@ietf.org Message-ID: <7248E8A902BB366E16773856@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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] Expert reveiw and draft-ietf-urnbis-rfc2141bis-urn-09 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, 04 Mar 2015 15:16:55 -0000 We agreed some time ago that URN registrations for Formal namespaces and their NIDs should be shifted from IETF Consensus (see Section 4.3 of RFC 3406) to Expert Review and that Expert Review should apply to Informal Namespaces as well. There has been some discussion in the WG (and the IETF more generally) about issues with registration Expert Review, especially for registrations that are expected to be reflected in standards track documents. Some of that discussion is hinted at in draft-ietf-urnbis-ns-reg-transition, but it has not yet been reflected in 2141bis. For those who have not followed the other discussion, one key problem is that, if something is registered with particular properties and specifications and then the authors want to standardize the technology, the IETF is told that discussion of design choices is out of order because the registration cannot be changed. That is, I hope obviously, bad news. I think we are headed in the following direction, but want to get confirmation (or corrections) from the WG before Peter and I start struggling with draft text: (1) We want Expert Review, with the guidance that now appears in Sections 7 and 9, for namespaces that are not intended to be standardized in/by the IETF. (2) For namespaces intended for standardization, IETF Consensus is necessary for registration although a preliminary expert review may be helpful. (3) While namespaces that are essentially overlays on identifier standards produced and managed by other standards bodies, the Expert Review process is intended more as an advisory and coordination on rather than one or acceptance or rejection and some sort of "fast track" procedure (and/or even a different review process) may be in order. I would hope we can explicitly give the IESG some flexibility in those situations rather than having to spell everything out in 2141bis. (4) For namespaces that do not fall into categories (2) or (3), we have a strong preference for registration, even poor-quality registrations that only assure uniqueness of NIDs, over a slow and/or onerous registration approval process that encourages use of names without registration. Does that about cover it? Does anyone want to suggest text? john From nobody Wed Mar 4 07:45:47 2015 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 EA8371A89B3 for ; Wed, 4 Mar 2015 07:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8-GunZdFObP5 for ; Wed, 4 Mar 2015 07:45:43 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7911A88C2 for ; Wed, 4 Mar 2015 07:45:42 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id t24FjQIL000198; Wed, 4 Mar 2015 15:45:32 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t24FjQne027086; Wed, 4 Mar 2015 15:45:26 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t24FjQNE006349; Wed, 4 Mar 2015 15:45:26 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id t24FjPlA006345; Wed, 4 Mar 2015 15:45:25 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: John C Klensin References: From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 04 Mar 2015 15:45:25 +0000 In-Reply-To: (John C. Klensin's message of "Wed\, 04 Mar 2015 09\:45\:15 -0500") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Resolution services and Section 7.5 of draft-ietf-urnbis-rfc2141bis-urn-09 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, 04 Mar 2015 15:45:46 -0000 John C Klensin writes: > ... > Section 7.5 of draft-ietf-urnbis-rfc2141bis-urn-09 seems to be a > little more specific about resolution than the direction in > which we seem to be headed. In particular, it calls out the > notion of registration of the namespace with an RFC 2276 > Resolution Discovery System, an idea that has been honored > mostly in the breach > ... > One possibility is just to strip the RDS and DDDS material out > of that paragraph, saying instead: > > The "Resolution" section specifies the rules for resolution > of URNs assigned within the namespace. This section SHOULD > list the requirements for becoming a recognized resolver of > URNs in the relevant namespace. Answers might include, but > are not limited to: I like that suggestion as far as it goes. I would only add that since it involves stripping out reference to RDS, that the numbered examples that follow should probably also be modified so they don't give such a central role to RDS. In fact, having spent a small amount of time trying to redraft the numbered items, I wonder if even less is not more in this case. What about The "Resolution" section MUST specify whether resolution mechanisms are supported or anticipated for URNs assigned within the namespace, and if so SHOULD specify or reference the rules governing those mechanisms. In particular, if resolution is anticipated and resolver registration of some kind is required, for example via a Resolution Discovery System [RFC2276], this section SHOULD list the requirements for becoming a recognized resolver of URNs in the relevant namespace. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Fri Mar 6 10:15:45 2015 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 723401A0636 for ; Fri, 6 Mar 2015 10:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=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 7Kx0eazhuu_w for ; Fri, 6 Mar 2015 10:15:39 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4F21A037F for ; Fri, 6 Mar 2015 10:15:39 -0800 (PST) Received: by iery20 with SMTP id y20so34269626ier.12 for ; Fri, 06 Mar 2015 10:15:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=U2Lj5QQcml9kiExZcQkRf0Koqf1IDQ/QPkhanRg92Ho=; b=HtI8syKR5Uz03+O8nd6Er8NUsJ7TdBwmixYP5Zdxmdyf9TXUjglt1Xaj8ZkAQpOEeZ HtPRinWfwTBBekxKi5TqQBB5rsjpyynEfDQWRO1ftZftddFUoOb36fHy633yBQteERyD 3/HGOVJU1b1jD5heUdUUKGf4hUnsSTU79lS9H+6EpGEoVgtyKFrSpQrmEqdHw3aC6hoX XDrP96cF2CeXTmiby1bLn0V97wcpIeoMPxyHi0yK8IF49A0yoOMahqltjPoDH06GXN0y hqYytu4ayQjqCFIgiGuGUc9r4E70o0xNd/Oc8yxdZoZX/ZVFwt4ZTDWnHQrC9Re13Lrg 3I+g== MIME-Version: 1.0 X-Received: by 10.50.43.130 with SMTP id w2mr29629656igl.30.1425665738862; Fri, 06 Mar 2015 10:15:38 -0800 (PST) Received: by 10.42.129.17 with HTTP; Fri, 6 Mar 2015 10:15:38 -0800 (PST) Date: Fri, 6 Mar 2015 10:15:38 -0800 Message-ID: From: Ted Hardie To: "urn@ietf.org" , Andrew Newton , Melinda Shore Content-Type: multipart/alternative; boundary=089e0103de4eeef6470510a2abbe Archived-At: Subject: [urn] Brief review of draft-ietf-urnbis-semantics-clarif-01 and draft-ietf-urnbis-rfc2141bis-urn-09 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, 06 Mar 2015 18:15:43 -0000 --089e0103de4eeef6470510a2abbe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Howdy, I have not been particularly engaged in this work over the past year or so, so this review is based on a read of the documents themselves and a necessarily brief skim through the working group mailing list archives. That may make me a reasonable approximation of the eventual reader, or simply confused. Please understand, though, that suggestions made are intended simply to suggest ways to make the document set effective, not to challenge anything about the current consensus. If anything I suggest would change the current consensus, please put that down to bad writing or confusion on my part. For draft-ietf-urnbis-semantics-clarif-01, I believe I understand the necessity of pulling this decision into a separate document and getting consensus around it. Now that the consensus is done, however, I believe the document could be folded back into 2141bis and that the result would be stronger. As I read the document now, the core statements that would need to be folded into 2141bis are these: This specification removes URN semantics from the scope of RFC 3896 . It makes no changes to the generic URI syntax. That syntax still applies to URNs as well as to other URI types. In particular, the generic URI syntax for path segments that appear after the NID and NSS of a URN, is unchanged, but the terms for those path segments, "query" and "fragment" become, for URNs, terms of convenience that are defined in URN-specific ways as p-components, q-components, and f-components [RFC2141bis ]. the concern that led to this document was a desire to accommodate URN components that would be analogous to the query and fragment components of generalized URNs but that might have different properties. For many cases, the analogy cannot be exact. The security considerations would also have to be folded into 2141bis. I realize that this is a somewhat radical proposal, given the working group history, but I think having a single document with that text in it would be adequate to the purpose and simpler. (Basically, we don't need to have the working group history recapitulated in the document set) For draft-ietf-urnbis-rfc2141bis-urn-09, some general comments. First, the document currently has this text: This document rests on two key assumptions: 1. Assignment of a URN is a managed process. A string that conforms to the URN syntax is not necessarily a valid URN, because a URN needs to be assigned according to the rules of a particular namespace (in terms of syntax, semantics, and process). 2. The space of URN namespaces is itself managed. A string in the namespace identifier slot of the URN syntax is not necessarily a valid URN namespace identifier, because in order to be valid a namespace needs to be defined and registered in accordance with the rules specified in this document. These appear to be critically important, and getting them fixed in the readers' minds early seems to be a good thing. I worry, though, that the explanator= y text below the bullets is delving into the complexity at the very moment you want the reader to be focused. I'd suggest adapting this slightly: This document rests on two key assumptions: 1. Assignment of a URN is a managed process. 2. The space of URN namespaces is itself managed. While other schemes may allow identifiers to be freely minted, this is not the case for URNs. The syntactical correctness of a string appearing after "urn:" is not sufficient to make it a URN; both the namespace identifier and namespace specific string must be registered or generated according to the rules given for it to be a valid URN. =E2=80=8BThe document currently has this text: Depending on the rules governing a namespace, names that are valid in a namespace might contain characters that are not allowed in URNs according to the "pchar" rule (e.g., characters outside the ASCII range or characters that are reserved in URIs, such as "/", "?", and "#"). Such a string MUST be translated into a conformant NSS before using it as a protocol element or otherwise passing it on to other applications. Translation is done by percent-encoding each disallowed character using the method defined in Section 2.1 of [RFC3986] . Note that the "%" character is allowed only for the purpose of percent-encoding. =E2=80=8BI don't believe that this is clear that urn:nid:nss is de facto a = protocol element, so I worry that you may see folks creating urn:nid:non-pchar productions in specific applications, with the presumption that they must be percent encoded only when being passed outside that context. That seems to me fragile, and I'd suggest the following replacement text: Depending on the rules governing a namespace, names that are valid in a namespace might contain characters that are not found in the "pchar" production above (e.g., characters outside the ASCII range or characters that are reserved in URIs, such as "/", "?", and "#"). While these may be valid names, they are not valid URNs until those strings are translated into a conformant NSS. Translation is done by percent-encoding each disallowed character using the method defined in Section 2.1 of [RFC3986] . Note that the "%" character is allowed only for the purpose of percent-encoding. 3.3.1. has this text: As described under Section 4 = , the p-component SHALL be taken into account when determining URN equivalence. It is not actually described in section 4 specifically, though the document does have this: If a q-component or f-component (or both) are included in a URN, they MUST be ignored for purposes of determining equivalence. For completeness, I suggest that the p-component text be added to section 4= . The document currently has this text: Ultimately, specifications of where it is appropriate to use URNs, or URNs created within particular URN namespaces, are the responsibility of descriptions of individual URI schemes and contexts; this specification cannot possibly anticipate all of the relevant cases. I believe that including both "schemes and contexts" is confusing here, because the main point is that these are likely to be context dependent (e.g. they are valid in some SNMP MIB slots and not others, so defining it in terms of an "SNMP" uri won't work.) While there may be some where there is a single protocol context per scheme, that is still a context. I suggest eliding "schemes and". The document currently has this text: However, a single resource can have more than one URN assigned to it for different purposes (e.g., some numbers might be valid identifiers in two different identifier systems, where the namespace identifier differentiates between the resulting URNs). A more concrete example would be very welcome here, as this seems likely to be open to confusion. The RFC 5031 emergency services may provide one (e.g. urn:service:counseling.mental-health and urn:service:counseling.suicide may be the same resource), but any concrete example would likely be an improvement. The document currently has this text: All two-letter strings, and all two-letter strings followed by "-" and any sequence of valid NID characters, are reserved for potential use as country-code-based NIDs for eventual national registrations of URN namespaces. The definition and scoping of rules for allocation of responsibility for such country-code-based namespaces is beyond the scope of this document. This matches current practice. I note, however, that this was a source of contention when New Zealand wanted to create country-code-based name space (see rfc4350). The interim step taken in discussion with the folks on the URN-NID list of the time was to allocate the three-letter ISO country as a NID. You may want to add advice to the designated expert on this point, so that three-letter NIDs which match country codes are considered from that angle. regards, Ted --089e0103de4eeef6470510a2abbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

I have not been pa= rticularly engaged in this work over the past year or so, so this review is= based on a read of the documents themselves and a necessarily brief skim t= hrough the working group mailing list archives.=C2=A0 That may make me a re= asonable approximation of the eventual reader, or simply confused.=C2=A0 Pl= ease understand, though, that suggestions made are intended simply to sugge= st ways to make the document set effective, not to challenge anything about= the current consensus.=C2=A0 If anything I suggest would change the curren= t consensus, please put that down to bad writing or confusion on my part.
For draft-ietf-urnbis-semantics-clarif-01, I believe = I understand the necessity of pulling this decision into a separate documen= t and getting consensus around it.=C2=A0 Now that the consensus is done, ho= wever, I believe the document could be folded back into 2141bis and that th= e result would be stronger.=C2=A0 As I read the document now, the core stat= ements that would need to be folded into 2141bis are these:

   =
This specification removes URN semantics from the scope of RFC 3896.
   It makes no changes to the generic URI syntax.  That syntax still
   applies to URNs as well as to other URI types.  
<snip>
   In particular, the generic URI syntax for path segments that appear
   after the NID and NSS of a URN, 
<snip>
  =C2=A0is unchanged=
, but the terms for
   those path segments, "query" and "fragment" become, =
for URNs, terms
   of convenience that are defined in URN-specific ways as p-components,
   q-components, and f-components [RFC21=
41bis].

<snip>
   the concern that led to this document was a d=
esire to
   accommodate URN components that would be analogous to the query and
   fragment components of generalized URNs but that might have different
   properties.  For many cases, the analogy cannot be exact.
The s= ecurity considerations would also have to be folded into 2141bis.

I realize that this is a somewhat radical proposal, given the= working group history, but I think having a single document with that text= in it would be adequate to the purpose and simpler.=C2=A0 (Basically, we d= on't need to have the working group history recapitulated in the docume= nt set)

For draft-ietf-urnbis-rfc2141bis-urn-09,=C2= =A0 some general comments.

First, the document curr= ently has this text:

This document rests on two key =
assumptions:

   1.  Assignment of a URN is a managed process.

       A string that conforms to the URN syntax is not necessarily a
       valid URN, because a URN needs to be assigned according to the
       rules of a particular namespace (in terms of syntax, semantics,
       and process).



   2.  The space of URN namespaces is itself managed.

       A string in the namespace identifier slot of the URN syntax is
       not necessarily a valid URN namespace identifier, because in
       order to be valid a namespace needs to be defined and registered
       in accordance with the rules specified in this document.
These = appear to be critically important, and getting them fixed in the readers= 9;
minds early seems to be a good thing.=C2=A0 I worry, = though, that the explanatory
text below the bullets is d= elving into the complexity at the very moment
you want t= he reader to be focused.=C2=A0 I'd suggest adapting this slightly:
<= br>
This document rests on two key assumptions:

   1.  Assignment of a URN is a managed process.
   2.  The space of URN=
 namespaces is itself managed.
While other schemes may allow identifiers to be f= reely minted,
this is not the case for URNs.=C2=A0 The syntactical corr= ectness of a
string appearing after "urn:" is not sufficient = to make it a URN; both
the namespace identifier and namespace specific = string must be registered
or generated according to the rules given for= it to be a valid URN.

=E2=80=8BThe document currently has this text:

   D=
epending on the rules governing a namespace, names that are valid in
   a namespace might contain characters that are not allowed in URNs
   according to the "pchar" rule (e.g., characters outside the AS=
CII
   range or characters that are reserved in URIs, such as "/", &q=
uot;?", and
   "#").  Such a string MUST be translated into a conformant NSS =
before
   using it as a protocol element or otherwise passing it on to other
   applications.  Translation is done by percent-encoding each
   disallowed character using the method defined in Section=C2=A02.1 of
   [RFC3986].  Note that the "%" character is allowed only fo=
r the
   purpose of percent-encoding.
=E2=80=8BI don't believe that this= is clear that urn:nid:nss is de facto a protocol element, so I worry that = you may see folks creating urn:nid:non-pchar productions in specific applic= ations, with the presumption that they must be percent encoded only when be= ing passed outside that context.=C2=A0 That seems to me fragile, and I'= d suggest the following replacement text:
   Depending o=
n the rules governing a namespace, names that are valid in
   a namespace might contain characters that are not found in the=20
   "pchar" production above (e.g., characters outside the ASCII
   range or characters that are reserved in URIs, such as "/", &q=
uot;?", and
   "#").  While these may be valid names, they are not valid URNs=
    
    until those strings are translated into a conformant NSS.
  =
=C2=A0Translation is done by percent-encoding each
   disallowed character using the method defined in Section=C2=A02.1 of
   [RFC3986].  Note that the "%" character is allowed only fo=
r the
   purpose of percent-encoding.
3.3.1. has this text:

As described under Section 4, the p-component SHALL b=
e taken into
   account when determining URN equivalence.

It is= not actually described in section 4 specifically, though the document does= have this:

If a q-component or f-component (or both=
) are included in a URN, they
   MUST be ignored for purposes of determining equivalence.


For completeness, I suggest that the p-component text be =
added to section 4.

The document currently=
 has this text:

   Ultimately, specifications of where=
 it
   is appropriate to use URNs, or URNs created within particular URN
   namespaces, are the responsibility of descriptions of individual URI
   schemes and contexts; this specification cannot possibly anticipate
   all of the relevant cases.
I believe that including both "= schemes and contexts" is confusing here, because the main point is tha= t these are likely to be context dependent (e.g. they are valid in some SNM= P MIB slots and not others, so defining it in terms of an "SNMP" = uri won't work.)=C2=A0 While there may be some where there is a single = protocol context per scheme, that is still a context.=C2=A0 I suggest elidi= ng "schemes and".

The document currently h= as this text:

   However, a single resource can have
   more than one URN assigned to it for different purposes (e.g., some
   numbers might be valid identifiers in two different identifier
   systems, where the namespace identifier differentiates between the
   resulting URNs).
A more concrete example would be very welcome her= e, as this seems likely to be open to confusion.=C2=A0 The RFC 5031 emergen= cy services may provide one (e.g. urn:service:counseling.mental-health and= urn:service:counseling.suicide may be the same resource), but any concrete= example would likely be an improvement.

The documen= t currently has this text:
   All two-letter strings, an=
d all two-letter strings followed by "-"
   and any sequence of valid NID characters, are reserved for potential
   use as country-code-based NIDs for eventual national registrations of
   URN namespaces.  The definition and scoping of rules for allocation
   of responsibility for such country-code-based namespaces is beyond
   the scope of this document.
This matches current practice.=C2=A0 I = note, however, that this was a source of contention when New Zealand wanted= to create country-code-based name space (see rfc4350).=C2=A0 The interim s= tep taken in discussion with the folks on the URN-NID list of the time was = to allocate the three-letter ISO country as a NID.=C2=A0 You may want to ad= d advice to the designated expert on this point, so that three-letter NIDs = which match country codes are considered from that angle.

regards,

Ted


=
--089e0103de4eeef6470510a2abbe-- From nobody Fri Mar 6 12:09:29 2015 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 7B3901A1EE8 for ; Fri, 6 Mar 2015 12:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.61 X-Spam-Level: X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 5njJp-Y4TIat for ; Fri, 6 Mar 2015 12:09:24 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440CE1A1AF0 for ; Fri, 6 Mar 2015 12:09:24 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YTyYj-000Mki-Pi; Fri, 06 Mar 2015 15:09:21 -0500 Date: Fri, 06 Mar 2015 15:09:16 -0500 From: John C Klensin To: Ted Hardie , urn@ietf.org, Andrew Newton , Melinda Shore Message-ID: <99C0FBB1DB3B622B0B3E6FF0@JcK-HP8200.jck.com> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Brief review of draft-ietf-urnbis-semantics-clarif-01 and draft-ietf-urnbis-rfc2141bis-urn-09 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, 06 Mar 2015 20:09:27 -0000 Ted, Thanks for the careful reading. Personal comments, no particular hats on except when I discuss the document editing process... --On Friday, March 06, 2015 10:15 -0800 Ted Hardie wrote: >... > For draft-ietf-urnbis-semantics-clarif-01, I believe I > understand the necessity of pulling this decision into a > separate document and getting consensus around it. Now that > the consensus is done, however, I believe the document could > be folded back into 2141bis and that the result would be > stronger. As I read the document now, the core statements > that would need to be folded into 2141bis are these: >=20 > This specification removes URN semantics from the scope of > RFC 3896 . > It makes no changes to the generic URI syntax. That syntax > still applies to URNs as well as to other URI types. > > In particular, the generic URI syntax for path segments > that appear after the NID and NSS of a URN, > > is unchanged, but the terms for > those path segments, "query" and "fragment" become, for > URNs, terms of convenience that are defined in URN-specific > ways as p-components, q-components, and f-components > [RFC2141bis > -01#ref-RFC2141bis>]. >=20 > > the concern that led to this document was a desire to > accommodate URN components that would be analogous to the > query and fragment components of generalized URNs but that > might have different properties. For many cases, the > analogy cannot be exact. >=20 > The security considerations would also have to be folded into > 2141bis. >=20 > I realize that this is a somewhat radical proposal, given the > working group history, but I think having a single document > with that text in it would be adequate to the purpose and > simpler. (Basically, we don't need to have the working group > history recapitulated in the document set) I don't have any problem with this in principle, but doing it and having the resulting document read smoothly is a fair amount of work and somewhat error-prone. It certainly cannot be done before the I-D cutoff (I can probably spin up one more version of the semantics piece by Monday and Peter has a working draft of 2141bis (and a lot of questions) in hand so, assuming he has time to look at it, I'd expect that to be posted sometime over the weekend. I doubt that I can even get a consolidated document done and checked before the end of the month, especially if I do come to Dallas (still thinking about it). > For draft-ietf-urnbis-rfc2141bis-urn-09, some general > comments. >=20 > First, the document currently has this text: >=20 > This document rests on two key assumptions: >=20 > 1. Assignment of a URN is a managed process. >=20 > A string that conforms to the URN syntax is not > necessarily a valid URN, because a URN needs to be > assigned according to the rules of a particular > namespace (in terms of syntax, semantics, and process). >=20 > 2. The space of URN namespaces is itself managed. >=20 > A string in the namespace identifier slot of the URN > syntax is not necessarily a valid URN namespace > identifier, because in order to be valid a namespace > needs to be defined and registered in accordance with > the rules specified in this document. >=20 > These appear to be critically important, and getting them > fixed in the readers' > minds early seems to be a good thing. I worry, though, that > the explanatory text below the bullets is delving into the > complexity at the very moment you want the reader to be > focused. I'd suggest adapting this slightly: >=20 > This document rests on two key assumptions: >=20 > 1. Assignment of a URN is a managed process. > 2. The space of URN namespaces is itself managed. >=20 > While other schemes may allow identifiers to be freely minted, > this is not the case for URNs. The syntactical correctness of > a string appearing after "urn:" is not sufficient to make it a > URN; both the namespace identifier and namespace specific > string must be registered or generated according to the rules > given for it to be a valid URN. Wfm and, IMO, an improvement in other ways. "Freely minted" feels a little too much like English-specific jargon to me, so I'd appreciate suggestions of other wording or will use something like "freely chosen and assigned". Modulo that, I'll make this change in the working draft unless someone objects. One caution: I think the above is ok, but note that we may still not have completely resolved just how much of what follows "nid:" is the NSS versus other stuff. This has been discussed a bit on the list; the current syntax in 2141bis puts p-, f-, and q- components after the NSS rather than as part of it. > =E2=80=8BThe document currently has this text: >=20 > Depending on the rules governing a namespace, names that > are valid in a namespace might contain characters that are > not allowed in URNs according to the "pchar" rule (e.g., > characters outside the ASCII range or characters that are > reserved in URIs, such as "/", "?", and "#"). Such a > string MUST be translated into a conformant NSS before > using it as a protocol element or otherwise passing it on to > other applications. Translation is done by > percent-encoding each disallowed character using the method > defined in Section 2.1 of [RFC3986] > . Note that > the "%" character is allowed only for the > purpose of percent-encoding. >=20 > =E2=80=8BI don't believe that this is clear that urn:nid:nss = is de > facto a protocol element, so I worry that you may see folks > creating urn:nid:non-pchar productions in specific > applications, with the presumption that they must be percent > encoded only when being passed outside that context. That > seems to me fragile, and I'd suggest the following replacement > text: >=20 > Depending on the rules governing a namespace, names that > are valid in a namespace might contain characters that are > not found in the "pchar" production above (e.g., characters > outside the ASCII range or characters that are reserved in > URIs, such as "/", "?", and "#"). While these may be valid > names, they are not valid URNs until those strings are > translated into a conformant NSS. Translation is done by > percent-encoding each > disallowed character using the method defined in Section > 2.1 of [RFC3986] > . Note that > the "%" character is allowed only for the > purpose of percent-encoding. Ok if others agree, but I'd suggest "translated into a conformant URI" instead of "translated into a conformant NSS" to avoid the issue described above. Or we could try more text.=20 > 3.3.1. has this text: >=20 > As described under Section 4 > 09#section-4>, the p-component SHALL be taken into > account when determining URN equivalence. > It is not actually described in section 4 specifically, though > the document does have this: >=20 > If a q-component or f-component (or both) are included in a > URN, they MUST be ignored for purposes of determining > equivalence. >=20 > For completeness, I suggest that the p-component text be added > to section 4. I/we were specifically told to remove p-component from the numbered list in section 4.1 because the WG wanted it to be case sensitive. I could add another sentence to the fifth full paragraph so it would read: "If a p-component is included in a URN, it must be identical (including case sensitivity) in the strings being compared. If a q-component or f-component (or both) are included..." Other suggestions welcome, but I think we need guidance from the WG on this. > The document currently has this text: >=20 > Ultimately, specifications of where it > is appropriate to use URNs, or URNs created within > particular URN namespaces, are the responsibility of > descriptions of individual URI schemes and contexts; this > specification cannot possibly anticipate all of the > relevant cases. >=20 > I believe that including both "schemes and contexts" is > confusing here, because the main point is that these are > likely to be context dependent (e.g. they are valid in some > SNMP MIB slots and not others, so defining it in terms of an > "SNMP" uri won't work.) While there may be some where there > is a single protocol context per scheme, that is still a > context. I suggest eliding "schemes and". This is more complicated because the current text was an attempt to work around the question of whether URNs generally are expected to be used and function correctly in HTML "" environments and generalizations from them. Some will work, some won't. I wouldn't expect most SNMP URIs to work well in those environments either. Similarly, consider such constructions as=20 ArbitraryScheme:...?x=3Durn:SomeNID:SomeNSS... That is definitely valid 3986 syntax, but whether it makes sense or not is certainly going to depend on the scheme as well as other things. =20 Also, Henry Thompson made different suggestion, which was to get rid of "contexts" and make the offending sentence fragment read "...individual URI schemes and their expected uses;". The two suggestions have somewhat different meaning.=20 WG discussion is probably needed before we finalize text. > The document currently has this text: >=20 > However, a single resource can have > more than one URN assigned to it for different purposes > (e.g., some numbers might be valid identifiers in two > different identifier systems, where the namespace > identifier differentiates between the resulting URNs). >=20 > A more concrete example would be very welcome here, as this > seems likely to be open to confusion. The RFC 5031 emergency > services may provide one (e.g. > urn:service:counseling.mental-health and > urn:service:counseling.suicide may be the same resource), but > any concrete example would likely be an improvement. Placeholder added to working copy. > The document currently has this text: >=20 > All two-letter strings, and all two-letter strings followed > by "-" and any sequence of valid NID characters, are > reserved for potential use as country-code-based NIDs for > eventual national registrations of URN namespaces. The > definition and scoping of rules for allocation of > responsibility for such country-code-based namespaces is = beyond > the scope of this document. >=20 > This matches current practice. I note, however, that this was > a source of contention when New Zealand wanted to create > country-code-based name space (see rfc4350). The interim step > taken in discussion with the folks on the URN-NID list of the > time was to allocate the three-letter ISO country as a NID. > You may want to add advice to the designated expert on this > point, so that three-letter NIDs which match country codes are > considered from that angle. Arggh. I'm not sure what you are suggesting. It is a little late in the game to be reserving three character strings for 3166-1 alpha-3 use and I see a bit of a slippery slope. E.g., if we are going to advise experts to consider three-letter codes in case they match present (and possibly past or future) 3166-1 alpha-3 codes, should we also advise looking out for language codes or 3166-2 subdivisions codes, POSIX or other locale codes, etc.? Could you suggest some text? best, john From nobody Fri Mar 6 12:50:54 2015 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 0577F1A7034 for ; Fri, 6 Mar 2015 12:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=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 MyFwuVfSlWG7 for ; Fri, 6 Mar 2015 12:50:48 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C85D21A6F12 for ; Fri, 6 Mar 2015 12:50:47 -0800 (PST) Received: by igkb16 with SMTP id b16so6968986igk.1 for ; Fri, 06 Mar 2015 12:50:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p0+dMZ4lDauLXzTIu+UoNhjTDIzcsSWJxvW3PtrvKlc=; b=x1mMyAmrn1qJQXOkUIfEE/RPrLGvvUOcpzFRQkP+Puq/yJUJTt+xoWa1PMtCjJCRfC 33R6nei5z5oyTz7cWQIhgmZ3E1xsL6nAUbTkB14M5NAwzBQCh0k2zmJyE1ajodIlZesC 9eewNASlr4XXIJgNXbCdino9UVgungvffKKCco9P+55DLz76vB59pS+BMaB5BRBgnppD XbT6YJ18zvJLxTMCNo79qCjbT0U7rFDWZ1h8SWVXGTp77JQ3S4OdIuJuD5CeiabDcO3B lqNqpK5TJON+8Ae90vVer4P8GJpZnnAPI9v5trXJdXVl1UYGMccyXul1VVc/io5sfEXm +JEA== MIME-Version: 1.0 X-Received: by 10.50.93.70 with SMTP id cs6mr56549776igb.6.1425675047228; Fri, 06 Mar 2015 12:50:47 -0800 (PST) Received: by 10.42.129.17 with HTTP; Fri, 6 Mar 2015 12:50:47 -0800 (PST) In-Reply-To: <99C0FBB1DB3B622B0B3E6FF0@JcK-HP8200.jck.com> References: <99C0FBB1DB3B622B0B3E6FF0@JcK-HP8200.jck.com> Date: Fri, 6 Mar 2015 12:50:47 -0800 Message-ID: From: Ted Hardie To: John C Klensin Content-Type: multipart/alternative; boundary=047d7b41444cc15d960510a4d6a7 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Brief review of draft-ietf-urnbis-semantics-clarif-01 and draft-ietf-urnbis-rfc2141bis-urn-09 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, 06 Mar 2015 20:50:53 -0000 --047d7b41444cc15d960510a4d6a7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi John, Thanks for your quick reply. Some additional thoughts below, On Fri, Mar 6, 2015 at 12:09 PM, John C Klensin wrote: > > I don't have any problem with this in principle, but doing it > and having the resulting document read smoothly is a fair amount > of work and somewhat error-prone. It certainly cannot be done > before the I-D cutoff (I can probably spin up one more version > of the semantics piece by Monday and Peter has a working draft > of 2141bis (and a lot of questions) in hand so, assuming he has > time to look at it, I'd expect that to be posted sometime over > the weekend. I doubt that I can even get a consolidated > document done and checked before the end of the month, > especially if I do come to Dallas (still thinking about it). > > > =E2=80=8BUnderstood, and the working group may have good reasons to prefer not to make so big a change at this stage.=E2=80=8B > > > For draft-ietf-urnbis-rfc2141bis-urn-09, some general > > comments. > > > > First, the document currently has this text: > > > > This document rests on two key assumptions: > > > > 1. Assignment of a URN is a managed process. > > > > A string that conforms to the URN syntax is not > > necessarily a valid URN, because a URN needs to be > > assigned according to the rules of a particular > > namespace (in terms of syntax, semantics, and process). > > > > 2. The space of URN namespaces is itself managed. > > > > A string in the namespace identifier slot of the URN > > syntax is not necessarily a valid URN namespace > > identifier, because in order to be valid a namespace > > needs to be defined and registered in accordance with > > the rules specified in this document. > > > > These appear to be critically important, and getting them > > fixed in the readers' > > minds early seems to be a good thing. I worry, though, that > > the explanatory text below the bullets is delving into the > > complexity at the very moment you want the reader to be > > focused. I'd suggest adapting this slightly: > > > > This document rests on two key assumptions: > > > > 1. Assignment of a URN is a managed process. > > 2. The space of URN namespaces is itself managed. > > > > While other schemes may allow identifiers to be freely minted, > > this is not the case for URNs. The syntactical correctness of > > a string appearing after "urn:" is not sufficient to make it a > > URN; both the namespace identifier and namespace specific > > string must be registered or generated according to the rules > > given for it to be a valid URN. > > Wfm and, IMO, an improvement in other ways. "Freely minted" > feels a little too much like English-specific jargon to me, so > I'd appreciate suggestions of other wording or will use > something like "freely chosen and assigned". Modulo that, I'll > make this change in the working draft unless someone objects. > > One caution: I think the above is ok, but note that we may still > not have completely resolved just how much of what follows > "nid:" is the NSS versus other stuff. This has been discussed a > bit on the list; the current syntax in 2141bis puts p-, f-, and > q- components after the NSS rather than as part of it. > > =E2=80=8BThat makes sense to me, and I think that it would not impact the basic point that syntactical correctness does not guarantee validity.=E2=80=8B > > > =E2=80=8BThe document currently has this text: > > > > Depending on the rules governing a namespace, names that > > are valid in a namespace might contain characters that are > > not allowed in URNs according to the "pchar" rule (e.g., > > characters outside the ASCII range or characters that are > > reserved in URIs, such as "/", "?", and "#"). Such a > > string MUST be translated into a conformant NSS before > > using it as a protocol element or otherwise passing it on to > > other applications. Translation is done by > > percent-encoding each disallowed character using the method > > defined in Section 2.1 of [RFC3986] > > . Note that > > the "%" character is allowed only for the > > purpose of percent-encoding. > > > > =E2=80=8BI don't believe that this is clear that urn:nid:nss is de > > facto a protocol element, so I worry that you may see folks > > creating urn:nid:non-pchar productions in specific > > applications, with the presumption that they must be percent > > encoded only when being passed outside that context. That > > seems to me fragile, and I'd suggest the following replacement > > text: > > > > Depending on the rules governing a namespace, names that > > are valid in a namespace might contain characters that are > > not found in the "pchar" production above (e.g., characters > > outside the ASCII range or characters that are reserved in > > URIs, such as "/", "?", and "#"). While these may be valid > > names, they are not valid URNs until those strings are > > translated into a conformant NSS. Translation is done by > > percent-encoding each > > disallowed character using the method defined in Section > > 2.1 of [RFC3986] > > . Note that > > the "%" character is allowed only for the > > purpose of percent-encoding. > > Ok if others agree, but I'd suggest "translated into a > conformant URI" instead of "translated into a conformant NSS" to > avoid the issue described above. Or we could try more text. > > =E2=80=8BA conformant URN would also work for me.=E2=80=8B > > 3.3.1. has this text: > > > > As described under Section 4 > > > 09#section-4>, the p-component SHALL be taken into > > account when determining URN equivalence. > > > It is not actually described in section 4 specifically, though > > the document does have this: > > > > If a q-component or f-component (or both) are included in a > > URN, they MUST be ignored for purposes of determining > > equivalence. > > > > For completeness, I suggest that the p-component text be added > > to section 4. > > I/we were specifically told to remove p-component from the > numbered list in section 4.1 because the WG wanted it to be case > sensitive. I could add another sentence to the fifth full > paragraph so it would read: > > "If a p-component is included in a URN, it must be > identical (including case sensitivity) in the strings > being compared. If a q-component or f-component (or > both) are included..." > > Other suggestions welcome, but I think we need guidance from the > WG on this. > > =E2=80=8BI don't have an opinion on what the comparison method should be for p-component should be, I was merely noting that =E2=80=8B3.3.1 pointed somewhere for guidance on it that did not appear to have that guidance. =E2=80=8BThe draft currently requires that it be taken into account but doe= s not explain how to do so (or I missed it, which is entirely possibly). =E2=80=8BGiven the parallel to path-absolute, I could see case-sensitive comparison being desirable, and if that is the desire, then the text above seems close, but likely needs to account for the case insensitivity of the %-encoded parts (that is, you want case sensitivity for pchar-valid portions, but the %-encoded parts are treated according to 6.2.2.1 of RFC 3986) > > > The document currently has this text: > > > > Ultimately, specifications of where it > > is appropriate to use URNs, or URNs created within > > particular URN namespaces, are the responsibility of > > descriptions of individual URI schemes and contexts; this > > specification cannot possibly anticipate all of the > > relevant cases. > > > > I believe that including both "schemes and contexts" is > > confusing here, because the main point is that these are > > likely to be context dependent (e.g. they are valid in some > > SNMP MIB slots and not others, so defining it in terms of an > > "SNMP" uri won't work.) While there may be some where there > > is a single protocol context per scheme, that is still a > > context. I suggest eliding "schemes and". > > This is more complicated because the current text was an attempt > to work around the question of whether URNs generally are > expected to be used and function correctly in HTML "" > environments and generalizations from them. Some will work, > some won't. I wouldn't expect most SNMP URIs to work well in > those environments either. Similarly, consider such > constructions as > ArbitraryScheme:...?x=3Durn:SomeNID:SomeNSS... > > That is definitely valid 3986 syntax, but whether it makes sense > or not is certainly going to depend on the scheme as well as > other things. > > Also, Henry Thompson made different suggestion, which was to get > rid of "contexts" and make the offending sentence fragment read > "...individual URI schemes and their expected uses;". The two > suggestions have somewhat different meaning. > > WG discussion is probably needed before we finalize text. > > =E2=80=8BIt sounds like the WG understands the concern, and that there are various possible wording to handle it. One additional option might be to shift to something like: Ultimately, specification of where it is appropriate to use URNs, or URNs created within particular URN namespaces, should be in the descriptions of the individual contexts. This is slightly more vaugue, but gets the point that there is no simple answer here across. > > > The document currently has this text: > > > > However, a single resource can have > > more than one URN assigned to it for different purposes > > (e.g., some numbers might be valid identifiers in two > > different identifier systems, where the namespace > > identifier differentiates between the resulting URNs). > > > > A more concrete example would be very welcome here, as this > > seems likely to be open to confusion. The RFC 5031 emergency > > services may provide one (e.g. > > urn:service:counseling.mental-health and > > urn:service:counseling.suicide may be the same resource), but > > any concrete example would likely be an improvement. > > Placeholder added to working copy. > > > The document currently has this text: > > > > All two-letter strings, and all two-letter strings followed > > by "-" and any sequence of valid NID characters, are > > reserved for potential use as country-code-based NIDs for > > eventual national registrations of URN namespaces. The > > definition and scoping of rules for allocation of > > responsibility for such country-code-based namespaces is beyond > > the scope of this document. > > > > This matches current practice. I note, however, that this was > > a source of contention when New Zealand wanted to create > > country-code-based name space (see rfc4350). The interim step > > taken in discussion with the folks on the URN-NID list of the > > time was to allocate the three-letter ISO country as a NID. > > You may want to add advice to the designated expert on this > > point, so that three-letter NIDs which match country codes are > > considered from that angle. > > Arggh. I'm not sure what you are suggesting. It is a little > late in the game to be reserving three character strings for > 3166-1 alpha-3 use and I see a bit of a slippery slope. E.g., > if we are going to advise experts to consider three-letter codes > in case they match present (and possibly past or future) 3166-1 > alpha-3 codes, should we also advise looking out for language > codes or 3166-2 subdivisions codes, POSIX or other locale codes, > etc.? Could you suggest some text? > > =E2=80=8BWell, I think there are two choices. One is drop the restrictio= n here and stick the designated expert with determining when a request is coming from a national authority to whom such a country-code based namespace should be delegated. If this document does not remove this reservation, frankly, I'm not sure it ever will be removed. Where the designated expert gets the budget for their headache pills is an exercise left to the reader. The other option is simply to note that in advance of this restriction being relaxed some country-code-based name spaces have been allocated by three letter code and that the designated expert may take this into account. I would not consider firm reservation there useful, just a heads-up to both parties that requesting a NID of USA may get pushback and why. Thanks again for the quick reply, Ted > best, > john > > --047d7b41444cc15d960510a4d6a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi John,

Thanks for your = quick reply.=C2=A0 Some additional thoughts below,

On Fri, Mar 6, 2015 at 12:09 PM= , John C Klensin <john-ietf@jck.com> wrote:

I don't have any problem with this in principle, but doing it and having the resulting document read smoothly is a fair amount
of work and somewhat error-prone.=C2=A0 It certainly cannot be done
before the I-D cutoff (I can probably spin up one more version
of the semantics piece by Monday and Peter has a working draft
of 2141bis (and a lot of questions) in hand so, assuming he has
time to look at it, I'd expect that to be posted sometime over
the weekend.=C2=A0 I doubt that I can even get a consolidated
document done and checked before the end of the month,
especially if I do come to Dallas (still thinking about it).


=E2=80=8BUnderstood, and the wo= rking group may have good reasons
to prefer not to make = so big a change at this stage.=E2=80=8B

=C2=A0

> For draft-ietf-urnbis-rfc2141bis-urn-09,=C2=A0 some general
> comments.
>
> First, the document currently has this text:
>
> This document rests on two key assumptions:
>
>=C2=A0 =C2=A0 1.=C2=A0 Assignment of a URN is a managed process.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 A string that conforms to the URN syntax is= not
> necessarily a=C2=A0 =C2=A0 =C2=A0 =C2=A0 valid URN, because a URN need= s to be
> assigned according to the=C2=A0 =C2=A0 =C2=A0 =C2=A0 rules of a partic= ular
> namespace (in terms of syntax, semantics,=C2=A0 =C2=A0 =C2=A0 =C2=A0 a= nd process).
>
>=C2=A0 =C2=A0 2.=C2=A0 The space of URN namespaces is itself managed. >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 A string in the namespace identifier slot o= f the URN
> syntax is=C2=A0 =C2=A0 =C2=A0 =C2=A0 not necessarily a valid URN names= pace
> identifier, because in=C2=A0 =C2=A0 =C2=A0 =C2=A0 order to be valid a = namespace
> needs to be defined and registered=C2=A0 =C2=A0 =C2=A0 =C2=A0 in accor= dance with
> the rules specified in this document.
>
> These appear to be critically important, and getting them
> fixed in the readers'
> minds early seems to be a good thing.=C2=A0 I worry, though, that
> the explanatory text below the bullets is delving into the
> complexity at the very moment you want the reader to be
> focused.=C2=A0 I'd suggest adapting this slightly:
>
> This document rests on two key assumptions:
>
>=C2=A0 =C2=A0 1.=C2=A0 Assignment of a URN is a managed process.
>=C2=A0 =C2=A0 2.=C2=A0 The space of URN namespaces is itself managed. >
> While other schemes may allow identifiers to be freely minted,
> this is not the case for URNs.=C2=A0 The syntactical correctness of > a string appearing after "urn:" is not sufficient to make it= a
> URN; both the namespace identifier and namespace specific
> string must be registered or generated according to the rules
> given for it to be a valid URN.

Wfm and, IMO, an improvement in other ways.=C2=A0 =C2=A0"F= reely minted"
feels a little too much like English-specific jargon to me, so
I'd appreciate suggestions of other wording or will use
something like "freely chosen and assigned".=C2=A0 =C2=A0Modulo t= hat, I'll
make this change in the working draft unless someone objects.

One caution: I think the above is ok, but note that we may still
not have completely resolved just how much of what follows
"nid:" is the NSS versus other stuff.=C2=A0 This has been discuss= ed a
bit on the list; the current syntax in 2141bis puts p-, f-, and
q- components after the NSS rather than as part of it.

=E2=80=8BThat makes= sense to me, and I think that it would not impact
the b= asic point that syntactical correctness does not guarantee
validity.=E2=80=8B

=C2=A0

> =E2=80=8BThe document currently has this text:
>
>=C2=A0 =C2=A0 Depending on the rules governing a namespace, names that<= br> > are valid in=C2=A0 =C2=A0 a namespace might contain characters that ar= e
> not allowed in URNs=C2=A0 =C2=A0 according to the "pchar" ru= le (e.g.,
> characters outside the ASCII=C2=A0 =C2=A0 range or characters that are=
> reserved in URIs, such as "/", "?", and=C2=A0 =C2= =A0 "#").=C2=A0 Such a
> string MUST be translated into a conformant NSS before
> using it as a protocol element or otherwise passing it on to
> other=C2=A0 =C2=A0 applications.=C2=A0 Translation is done by
> percent-encoding each=C2=A0 =C2=A0 disallowed character using the meth= od
> defined in Section 2.1 of=C2=A0 =C2=A0 [RFC3986]
> <https://tools.ietf.org/html/rfc3986#section-2.1>.= =C2=A0 Note that
> the "%" character is allowed only for the >=C2=A0 =C2=A0 purpose of percent-encoding.
>
> =E2=80=8BI don't believe that this is clear that urn:nid:nss is de=
> facto a protocol element, so I worry that you may see folks
> creating urn:nid:non-pchar productions in specific
> applications, with the presumption that they must be percent
> encoded only when being passed outside that context.=C2=A0 That
> seems to me fragile, and I'd suggest the following replacement
> text:
>
>=C2=A0 =C2=A0 Depending on the rules governing a namespace, names that<= br> > are valid in=C2=A0 =C2=A0 a namespace might contain characters that ar= e
> not found in the=C2=A0 =C2=A0 "pchar" production above (e.g.= , characters
> outside the ASCII=C2=A0 =C2=A0 range or characters that are reserved i= n
> URIs, such as "/", "?", and=C2=A0 =C2=A0 "#&q= uot;).=C2=A0 While these may be valid
> names, they are not valid URNs=C2=A0 =C2=A0 =C2=A0until those strings = are
> translated into a conformant NSS.=C2=A0 =C2=A0 Translation is done by<= br> > percent-encoding each
>=C2=A0 =C2=A0 disallowed character using the method defined in Section<= br> > 2.1 of=C2=A0 =C2=A0 [RFC3986]
> <https://tools.ietf.org/html/rfc3986#section-2.1>.= =C2=A0 Note that
> the "%" character is allowed only for the >=C2=A0 =C2=A0 purpose of percent-encoding.

Ok if others agree, but I'd suggest "translated into a
conformant URI" instead of "translated into a conformant NSS"= ; to
avoid the issue described above.=C2=A0 Or we could try more text.

=E2=80=8BA conforma= nt URN would also work for me.=E2=80=8B

=C2=A0
> 3.3.1. has this text:
>
> As described under Section 4
> <https://tools.ietf.org/html/draft-ietf-urn= bis-rfc2141bis-urn-
> 09#section-4>, the p-component SHALL be taken into
>=C2=A0 =C2=A0 account when determining URN equivalence= .

> It is not actually described in section 4 specifically, though
> the document does have this:
>
> If a q-component or f-component (or both) are included in a
> URN, they=C2=A0 =C2=A0 MUST be ignored for purposes of determining
> equivalence.
>
> For completeness, I suggest that the p-component text be added
> to section 4.

I/we were specifically told to remove p-component from the
numbered list in section 4.1 because the WG wanted it to be case
sensitive.=C2=A0 =C2=A0I could add another sentence to the fifth full
paragraph so it would read:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "If a p-component is included in a URN, it= must be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 identical (including case sensitivity) in the s= trings
=C2=A0 =C2=A0 =C2=A0 =C2=A0 being compared.=C2=A0 If a q-component or f-com= ponent (or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 both) are included..."

Other suggestions welcome, but I think we need guidance from the
WG on this.

=E2=80=8BI don'= t have an opinion on what the comparison method should be
for p-component should be, I was merely noting that =E2=80=8B3.3.1 pointe= d
somewhere for guidance on it that did not appear to ha= ve that guidance.
=E2=80=8BThe draft currently requires = that it be taken into account but does not
explain how t= o do so (or I missed it, which is entirely possibly).
= =E2=80=8BGiven the parallel to path-absolute, I could see case-sensitive
comparison being desirable, and if that is the desire, the= n the text
above seems close, but likely needs to accoun= t for the case insensitivity
of the %-encoded parts (tha= t is, you want case sensitivity for pchar-valid
portions= , but the %-encoded parts are treated according to 6.2.2.1 of
RFC 3986)

=C2=A0

> The document currently has this text:
>
>=C2=A0 =C2=A0 Ultimately, specifications of where it
>=C2=A0 =C2=A0 is appropriate to use URNs, or URNs created within
> particular URN=C2=A0 =C2=A0 namespaces, are the responsibility of
> descriptions of individual URI=C2=A0 =C2=A0 schemes and contexts; this=
> specification cannot possibly anticipate=C2=A0 =C2=A0 all of the
> relevant cases.
>
> I believe that including both "schemes and contexts" is
> confusing here, because the main point is that these are
> likely to be context dependent (e.g. they are valid in some
> SNMP MIB slots and not others, so defining it in terms of an
> "SNMP" uri won't work.)=C2=A0 While there may be some wh= ere there
> is a single protocol context per scheme, that is still a
> context.=C2=A0 I suggest eliding "schemes and".

This is more complicated because the current text was an attempt
to work around the question of whether URNs generally are
expected to be used and function correctly in HTML "<a href>&quo= t;
environments and generalizations from them.=C2=A0 Some will work,
some won't.=C2=A0 I wouldn't expect most SNMP URIs to work well in<= br> those environments either.=C2=A0 =C2=A0 Similarly, consider such
constructions as
=C2=A0 =C2=A0ArbitraryScheme:...?x=3Durn:SomeNID:SomeNSS...

That is definitely valid 3986 syntax, but whether it makes sense
or not is certainly going to depend on the scheme as well as
other things.

Also, Henry Thompson made different suggestion, which was to get
rid of "contexts" and make the offending sentence fragment read "...individual URI schemes and their expected uses;".=C2=A0 The t= wo
suggestions have somewhat different meaning.

WG discussion is probably needed before we finalize text.


=E2=80=8BIt sou= nds like the WG understands the concern, and that there are
various possible wording to handle it.=C2=A0 One additional option migh= t
be to shift to something like:

Ultimately, specification of where it is appropriate to use URNs, or URNs = created within particular URN=C2=A0 =C2=A0 namespaces, should be in the des= criptions of the individual=C2=A0 contexts.

= This is slightly more vaugue, but gets the point that there is no simple an= swer here across.
=C2=A0

> The document currently has this text:
>
>=C2=A0 =C2=A0 However, a single resource can have
>=C2=A0 =C2=A0 more than one URN assigned to it for different purposes > (e.g., some=C2=A0 =C2=A0 numbers might be valid identifiers in two
> different identifier=C2=A0 =C2=A0 systems, where the namespace
> identifier differentiates between the=C2=A0 =C2=A0 resulting URNs). >
> A more concrete example would be very welcome here, as this
> seems likely to be open to confusion.=C2=A0 The RFC 5031 emergency
> services may provide one (e.g.
> urn:service:counseling.mental-health and
> urn:service:counseling.suicide may be the same resource), but
> any concrete example would likely be an improvement.

Placeholder added to working copy.

> The document currently has this text:
>
>=C2=A0 =C2=A0 All two-letter strings, and all two-letter strings follow= ed
> by "-"=C2=A0 =C2=A0 and any sequence of valid NID characters= , are
> reserved for potential=C2=A0 =C2=A0 use as country-code-based NIDs for=
> eventual national registrations of=C2=A0 =C2=A0 URN namespaces.=C2=A0 = The
> definition and scoping of rules for allocation=C2=A0 =C2=A0 of
> responsibility for such country-code-based namespaces is beyond
>=C2=A0 =C2=A0 the scope of this document.
>
> This matches current practice.=C2=A0 I note, however, that this was > a source of contention when New Zealand wanted to create
> country-code-based name space (see rfc4350).=C2=A0 The interim step > taken in discussion with the folks on the URN-NID list of the
> time was to allocate the three-letter ISO country as a NID.
> You may want to add advice to the designated expert on this
> point, so that three-letter NIDs which match country codes are
> considered from that angle.

Arggh.=C2=A0 I'm not sure what you are suggesting.=C2=A0 It is a= little
late in the game to be reserving three character strings for
3166-1 alpha-3 use and I see a bit of a slippery slope.=C2=A0 E.g.,
if we are going to advise experts to consider three-letter codes
in case they match present (and possibly past or future) 3166-1
alpha-3 codes, should we also advise looking out for language
codes or 3166-2 subdivisions codes, POSIX or other locale codes,
etc.?=C2=A0 =C2=A0Could you suggest some text?

=E2=80=8BWell, I think there are two choice= s.=C2=A0 One is drop the restriction here
and stick the = designated expert with determining when a request
is com= ing from a national authority to whom such a country-code
based namespace should be delegated.=C2=A0 If this document does
not remove this reservation, frankly, I'm not sure it ever w= ill be removed.
Where the designated expert gets the bud= get for their headache pills
is an exercise left to the = reader.

The other option is simply to note that in a= dvance of this restriction
being relaxed some country-co= de-based name spaces have been allocated
by three letter= code and that the designated expert may take this into
= account.=C2=A0 I would not consider firm reservation there useful, just a h= eads-up
to both parties that requesting a NID of USA may= get pushback and why.

Thanks again for the quick re= ply,

Ted

=C2=A0
best,
=C2=A0 =C2=A0 john


--047d7b41444cc15d960510a4d6a7-- From nobody Fri Mar 6 13:17:00 2015 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 602DE1A7035 for ; Fri, 6 Mar 2015 13:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.61 X-Spam-Level: X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 TXMAzd9z0c2u for ; Fri, 6 Mar 2015 13:16:56 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95CF91A1B28 for ; Fri, 6 Mar 2015 13:16:56 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YTzc6-000MvD-T0; Fri, 06 Mar 2015 16:16:54 -0500 Date: Fri, 06 Mar 2015 16:16:49 -0500 From: John C Klensin To: Ted Hardie Message-ID: In-Reply-To: References: <99C0FBB1DB3B622B0B3E6FF0@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Brief review of draft-ietf-urnbis-semantics-clarif-01 and draft-ietf-urnbis-rfc2141bis-urn-09 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, 06 Mar 2015 21:16:59 -0000 --On Friday, March 06, 2015 12:50 -0800 Ted Hardie wrote: > Hi John, >=20 > Thanks for your quick reply. Some additional thoughts below, I'm really anxious to move this stuff forward and will do everything I can to reinforce careful and on-topic reviews like yours :-) Comments on your additional notes/thoughts were they seem relevant below (with much trimming). =20 > =E2=80=8BUnderstood, and the working group may have good = reasons > to prefer not to make so big a change at this stage. (This is about folding the "semantics" piece into 2141bis). Really up to the WG. If things are going to drag out anyway, then finding time to fold the two together may be worthwhile. On the other hand, I'd prefer that they not drag out and there are significant risks of bad things happening if they = do.=E2=80=8B =20 >> > For draft-ietf-urnbis-rfc2141bis-urn-09, some general >> > comments. >> >=20 >> > First, the document currently has this text: >> >=20 >> > This document rests on two key assumptions: >> >=20 >> > 1. Assignment of a URN is a managed process. >... >> Wfm and, IMO, an improvement in other ways. "Freely minted" >> feels a little too much like English-specific jargon to me, = so >> I'd appreciate suggestions of other wording or will use >> something like "freely chosen and assigned". Modulo that, >> I'll make this change in the working draft unless someone >> objects. >>=20 >> One caution: I think the above is ok, but note that we may >> still not have completely resolved just how much of what >> follows "nid:" is the NSS versus other stuff. This has been >> discussed a bit on the list; the current syntax in 2141bis >> puts p-, f-, and q- components after the NSS rather than as >> part of it. >>=20 >> =E2=80=8BThat makes sense to me, and I think that it would = not >> impact > the basic point that syntactical correctness does not = guarantee > validity.=E2=80=8B Concur. >... >> Ok if others agree, but I'd suggest "translated into a >> conformant URI" instead of "translated into a conformant NSS" >> to avoid the issue described above. Or we could try more >> text. >>=20 >> =E2=80=8BA conformant URN would also work for me.=E2=80=8B I deliberately said "translated into a conformant URI" (perhaps with a reference to 3986 and some hand-waving about syntax) deliberately. "A conformant URN" in this section would seem a bit circular. Or do you see that differently? >> > 3.3.1. has this text: >> >=20 >> > As described under Section 4 >> > > > rn- 09#section-4>, the p-component SHALL be taken into >> > account when determining URN equivalence. >>=20 >> > It is not actually described in section 4 specifically, >> > though the document does have this: >> >=20 >> > If a q-component or f-component (or both) are included in a >> > URN, they MUST be ignored for purposes of determining >> > equivalence. >> >=20 >> > For completeness, I suggest that the p-component text be >> > added to section 4. >>=20 >> I/we were specifically told to remove p-component from the >> numbered list in section 4.1 because the WG wanted it to be >> case sensitive. I could add another sentence to the fifth >> full paragraph so it would read: >>=20 >> "If a p-component is included in a URN, it must be >> identical (including case sensitivity) in the strings >> being compared. If a q-component or f-component (or >> both) are included..." >>=20 >> Other suggestions welcome, but I think we need guidance from >> the WG on this. >>=20 >> =E2=80=8BI don't have an opinion on what the comparison = method >> should be > for p-component should be, I was merely noting that = =E2=80=8B3.3.1 > pointed somewhere for guidance on it that did not appear to > have that guidance. =E2=80=8BThe draft currently requires that = it be > taken into account but does not explain how to do so (or I > missed it, which is entirely possibly). =E2=80=8BGiven the = parallel > to path-absolute, I could see case-sensitive comparison being > desirable, and if that is the desire, then the text above > seems close, but likely needs to account for the case > insensitivity of the %-encoded parts (that is, you want case > sensitivity for pchar-valid portions, but the %-encoded parts > are treated according to 6.2.2.1 of RFC 3986) Yes. The reference to Section 4 was correct when the original statement was there and should have been fixed, somehow, when we took the p-component statement out, so you clearly identified a real issue. >... >> > I believe that including both "schemes and contexts" is >> > confusing here, because the main point is that these are >... >> Also, Henry Thompson made different suggestion, which was to >> get rid of "contexts" and make the offending sentence >> fragment read "...individual URI schemes and their expected >> uses;". The two suggestions have somewhat different meaning. >>=20 >> WG discussion is probably needed before we finalize text. >>=20 >>=20 > =E2=80=8BIt sounds like the WG understands the concern, and = that > there are various possible wording to handle it. One > additional option might be to shift to something like: >=20 > Ultimately, specification of where it is appropriate to use > URNs, or URNs created within particular URN namespaces, > should be in the descriptions of the individual contexts. >=20 > This is slightly more vaugue, but gets the point that there is > no simple answer here across. Yes. I'd like to hear from the WG (and Henry in particular) rather than changing text several times. >... >> > The document currently has this text: >> >=20 >> > All two-letter strings, and all two-letter strings >> > followed by "-" and any sequence of valid NID >> > characters, are reserved for potential use as >> > country-code-based NIDs for eventual national registrations >> > of URN namespaces. The definition and scoping of rules >> > for allocation of responsibility for such >> > country-code-based namespaces is beyond the scope of this >> > document. >> >=20 >> > This matches current practice. I note, however, that this >> > was a source of contention when New Zealand wanted to = create >> > country-code-based name space (see rfc4350). The interim >> > step taken in discussion with the folks on the URN-NID list >> > of the time was to allocate the three-letter ISO country as >> > a NID. You may want to add advice to the designated expert >> > on this point, so that three-letter NIDs which match >> > country codes are considered from that angle. >>=20 >> Arggh. I'm not sure what you are suggesting. It is a little >> late in the game to be reserving three character strings for >> 3166-1 alpha-3 use and I see a bit of a slippery slope. = E.g., >> if we are going to advise experts to consider three-letter >> codes in case they match present (and possibly past or >> future) 3166-1 alpha-3 codes, should we also advise looking >> out for language codes or 3166-2 subdivisions codes, POSIX or >> other locale codes, etc.? Could you suggest some text? >>=20 >> =E2=80=8BWell, I think there are two choices. One is drop = the >> restriction here > and stick the designated expert with determining when a = request > is coming from a national authority to whom such a = country-code > based namespace should be delegated. If this document does > not remove this reservation, frankly, I'm not sure it ever > will be removed. Where the designated expert gets the budget > for their headache pills is an exercise left to the reader. >=20 > The other option is simply to note that in advance of this > restriction being relaxed some country-code-based name spaces > have been allocated by three letter code and that the > designated expert may take this into account. I would not > consider firm reservation there useful, just a heads-up > to both parties that requesting a NID of USA may get pushback > and why. Speaking strictly as an individual participant, what would be the problem or retaining the alpha-2 restriction (with and without a trailing hyphen) and noting that there are other strings that some entities might consider intrinsically reserved for their use including 3166-1 alpha-3 codes and assorted locality, etc., names and the review process might discourage their use by other then the obvious parties? Henry suggested that we should probably think about dispute resolution policies for names, trademark issues, etc. I had to suppress a gag reflex, mentioned to him that the historic IANA position on such issues (at least pre-ICANN) has been "not our problem, you folks go work it out among yourselves", and suggested he take the issue to the list, so your alpha-3 concern may be an introduction to a more complex discussion. best, john From nobody Fri Mar 6 13:30:50 2015 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 5D3491A044D for ; Fri, 6 Mar 2015 13:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=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 Ru2ZNWmQ_7sN for ; Fri, 6 Mar 2015 13:30:47 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011B61A1A8A for ; Fri, 6 Mar 2015 13:30:47 -0800 (PST) Received: by iecrp18 with SMTP id rp18so21125837iec.10 for ; Fri, 06 Mar 2015 13:30:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gCVhm0qDn8brMXPQBn/IShG18fntZkQA4GHNQ7rnN7Y=; b=v3FMH1Zjvi75pJJajnXRailOMeeoB/O3svrIt78xVpuGv96Ig59DmbuJMQO+Lzqdu2 Jh4DmsV6j5/zLHjcNhgA02XB6CEadajHiUTtikyXUbaNEDV+pBN2MAG0RQN2wWgnHoRh N+XbEshcmqZ7108EyE2Duky2YuhXsPUjDvCUYXy/BMidP78nRftzmgcGCh2ur0EtcWnP i4y6glBIWDoSJP3FFxXlPs9bPowDMu8uotDWVeMFS+MOVZ5HH8iRCay+LfxS1fT1wQpo i6AQE9rjRoMsNQeCP/ouNyu4gBYnzK0RKmYRt7x7YF17RfXCW2K91b4Gkp/6aJMBBxrZ je2g== MIME-Version: 1.0 X-Received: by 10.42.82.199 with SMTP id e7mr7264668icl.18.1425677446377; Fri, 06 Mar 2015 13:30:46 -0800 (PST) Received: by 10.42.129.17 with HTTP; Fri, 6 Mar 2015 13:30:46 -0800 (PST) In-Reply-To: References: <99C0FBB1DB3B622B0B3E6FF0@JcK-HP8200.jck.com> Date: Fri, 6 Mar 2015 13:30:46 -0800 Message-ID: From: Ted Hardie To: John C Klensin Content-Type: multipart/alternative; boundary=20cf30334657c176910510a56500 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Brief review of draft-ietf-urnbis-semantics-clarif-01 and draft-ietf-urnbis-rfc2141bis-urn-09 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, 06 Mar 2015 21:30:49 -0000 --20cf30334657c176910510a56500 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 6, 2015 at 1:16 PM, John C Klensin wrote: > > >... > >> Ok if others agree, but I'd suggest "translated into a > >> conformant URI" instead of "translated into a conformant NSS" > >> to avoid the issue described above. Or we could try more > >> text. > >> > >> =E2=80=8BA conformant URN would also work for me.=E2=80=8B > > I deliberately said "translated into a conformant URI" (perhaps > with a reference to 3986 and some hand-waving about syntax) > deliberately. "A conformant URN" in this section would seem a > bit circular. Or do you see that differently? > > =E2=80=8BI think "conformant URI" is fine, and a reference to 3986 there would help. (I personally don't see "conformant URN" as problematically circular, but it also not a huge advantage to have it, so it sounds like "conformant URI" makes the=E2=80=8B best sense) > > Ultimately, specification of where it is appropriate to use > > URNs, or URNs created within particular URN namespaces, > > should be in the descriptions of the individual contexts. > > > > This is slightly more vaugue, but gets the point that there is > > no simple answer here across. > > Yes. I'd like to hear from the WG (and Henry in particular) > rather than changing text several times. > > =E2=80=8BSounds good. =E2=80=8B > > > Speaking strictly as an individual participant, what would be > the problem or retaining the alpha-2 restriction (with and > without a trailing hyphen) and noting that there are other > strings that some entities might consider intrinsically reserved > for their use including 3166-1 alpha-3 codes and assorted > locality, etc., names and the review process might discourage > their use by other then the obvious parties? > > =E2=80=8BI think that is fine. Given that the review process includes urn-nid@ as well as the designated experts, it's also a fairly general formulation. > Henry suggested that we should probably think about dispute > resolution policies for names, trademark issues, etc. I had to > suppress a gag reflex, mentioned to him that the historic IANA > position on such issues (at least pre-ICANN) has been "not our > problem, you folks go work it out among yourselves", and > suggested he take the issue to the list, so your alpha-3 concern > may be an introduction to a more complex discussion. > > =E2=80=8BThe only thing I really want to avoid is having someone say "I have all the boxes ticked for a formal namespace, why can't I have the 3-letter one I want?" where the designated expert or review process sees a risk of an eventual country code request. Given that there is no mechanism for a two-letter code being given, that would have to be a three letter code. If there is a note in the document that this may be taken into account, I think we've done what we need to. Further mechanisms than our normal appeals chain are not going to help much, in my opinion, and I wouldn't spend any time designing them. regards, Ted > best, > john > > > --20cf30334657c176910510a56500 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 6, 2015 at 1:16 PM,= John C Klensin <john-ietf@jck.com> wrote:

>...
>> Ok if others agree, but I'd suggest "tra= nslated into a
>> conformant URI" instead of "translated into a conformant= NSS"
>> to avoid the issue described above.=C2=A0 Or we could try more
>> text.
>>
>> =E2=80=8BA conformant URN would also work for me.=E2=80=8B

I deliberately said "translated into a conformant URI" (pe= rhaps
with a reference to 3986 and some hand-waving about syntax)
deliberately.=C2=A0 =C2=A0"A conformant URN" in this section woul= d seem a
bit circular.=C2=A0 Or do you see that differently?

=E2=80= =8BI think "conformant URI" is fine, and a reference to 3986 ther= e
would help. (I personally don't see "conforma= nt URN" as
problematically circular, but it also n= ot a huge advantage to have
it, so it sounds like "= conformant URI" makes the=E2=80=8B best sense)


> Ultimately, specification of where it is appropriate to use
> URNs, or URNs created within particular URN=C2=A0 =C2=A0 namespaces, > should be in the descriptions of the individual=C2=A0 contexts.
>
> This is slightly more vaugue, but gets the point that there is
> no simple answer here across.

Yes.=C2=A0 I'd like to hear from the WG (and Henry in particular= )
rather than changing text several times.


=E2=80=8BSounds good.=E2=80=8B
=C2=A0


Speaking strictly as an individual participant, what would be the problem or retaining the alpha-2 restriction (with and
without a trailing hyphen) and noting that there are other
strings that some entities might consider intrinsically reserved
for their use including 3166-1 alpha-3 codes and assorted
locality, etc., names and the review process might discourage
their use by other then the obvious parties?

=E2=80=8BI think that is fine.=C2=A0 Given = that the review process includes
urn-nid@ as well as the= designated experts, it's also a fairly
general for= mulation.

=C2=A0
Henry suggested that we should probably think about dispute
resolution policies for names, trademark issues, etc.=C2=A0 I had to
suppress a gag reflex, mentioned to him that the historic IANA
position on such issues (at least pre-ICANN) has been "not our
problem, you folks go work it out among yourselves", and
suggested he take the issue to the list, so your alpha-3 concern
may be an introduction to a more complex discussion.

=E2=80=8BThe only thing I really want to av= oid is having someone say
"I have all the boxes ti= cked for a formal namespace, why
can't I have the 3-= letter one I want?" where the designated expert
or = review process sees a risk of an eventual country code
= request.=C2=A0 Given that there is no mechanism for a two-letter
<= div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-siz= e:small">code being given, that would have to be a three letter code.
If there is a note in the document that this may be taken int= o
account, I think we've done what we need to.=C2=A0= Further
mechanisms than our normal appeals chain are no= t going
to help much, in my opinion, and I wouldn't = spend any time
designing them.

= regards,

Ted

=C2=A0
best,
=C2=A0 =C2=A0john



--20cf30334657c176910510a56500-- From nobody Mon Mar 9 06:02:17 2015 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 36C6C1A8029; Mon, 9 Mar 2015 06:02:08 -0700 (PDT) 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 1abdthseYdi5; Mon, 9 Mar 2015 06:02:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D352B1A8783; Mon, 9 Mar 2015 06:02:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309130206.5309.52413.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 06:02:06 -0700 Archived-At: Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-10.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: Mon, 09 Mar 2015 13:02:08 -0000 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 Names (URNs) Authors : Peter Saint-Andre John C Klensin Filename : draft-ietf-urnbis-rfc2141bis-urn-10.txt Pages : 27 Date : 2015-03-09 Abstract: A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" scheme and a particular URN namespace, typically with the intent that the URN will be a persistent, location-independent resource identifier or abstract designator. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFC 2141 and RFC 3406. 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-10 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 nobody Wed Mar 11 18:52:27 2015 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 B68041A8999 for ; Wed, 11 Mar 2015 18:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 FN95wGvMd20u for ; Wed, 11 Mar 2015 18:52:24 -0700 (PDT) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E441A899E for ; Wed, 11 Mar 2015 18:52:24 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so8572417iec.2 for ; Wed, 11 Mar 2015 18:52:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=DaipB8ownvjwlDeLaTWlOkzphlWhg7l996kHE48DkT8=; b=Jxn5AZb0lXr7hbM9s+gf7r+6VblMF5piSEHropfSTWpFE1BWpf7IjK5NFgBKgwb9g/ t7RXlZ7pi2UJk2tXi4c+Zj/5gDii/JWQQd+nl3ZzPggHpketKi+hs/BcsYyNGFuC35Ki 66yaDhsSckPP+Mmj1OpVnculXOwgsYCQcO35k1aojD2nL+vNXdjviFviwt76F97MNevb QKTV5NBX5ZuDMuNdu6iRTx1eS9G83PZDfrv5tcyimIk5CMLRFy9dqyty2sRESfnhhhr5 8sj6Cs2NENMggwH+LdHP3nU2kXnexTQ+JlXExdArbqzYdKl5LmgFmFk4K1FDYUAKaRRx JZ8A== X-Gm-Message-State: ALoCoQmMNgBBj0TEjlgVrHJvwvWyCGcP8dGM+tLP2eNI5uP04mSjTp3UelmRiUo/xmJXuXu0laZO X-Received: by 10.107.159.20 with SMTP id i20mr25519619ioe.12.1426125139762; Wed, 11 Mar 2015 18:52:19 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id g71sm3540210ioe.43.2015.03.11.18.49.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 18:52:19 -0700 (PDT) Message-ID: <5500F0C3.6070807@andyet.net> Date: Wed, 11 Mar 2015 19:49:55 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] NSS syntax (CREFs 2,3,4) 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: Thu, 12 Mar 2015 01:52:25 -0000 In draft-ietf-urnbis-rfc2141bis-urn-10, we included a note about Ted Hardie's proposed text change for the NSS syntax. OLD Depending on the rules governing a namespace, names that are valid in a namespace might contain characters that are not allowed in URNs according to the "pchar" rule (e.g., characters outside the ASCII range or characters that are reserved in URIs, such as "/", "?", and "#"). Such a string MUST be translated into a conformant NSS before using it as a protocol element or otherwise passing it on to other applications. Translation is done by percent-encoding each disallowed character using the method defined in Section 2.1 of [RFC3986]. Note that the "%" character is allowed only for the purpose of percent-encoding. NEW Depending on the rules governing a namespace, names that are valid in a namespace might contain characters that are not found in the "pchar" production above (e.g., characters outside the ASCII range or characters that are reserved in URIs, such as "/", "?", and "#"). While these may be valid names, they are not valid URNs until those strings are translated into a conformant NSS. Translation is done by percent-encoding each disallowed character using the method defined in Section 2.1 of the generic URI specification [RFC3986] Note that the "%" character is allowed only for the purpose of percent- encoding. I have no strong objections to this proposal, modulo some slight editorial adjustments (e.g., changing "are not found in" to "are not allowed by"). Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Mar 11 18:53:47 2015 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 F19651A89A5 for ; Wed, 11 Mar 2015 18:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 EOQBW7vMZJYz for ; Wed, 11 Mar 2015 18:53:36 -0700 (PDT) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B45401A89A7 for ; Wed, 11 Mar 2015 18:53:36 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so8628251iec.2 for ; Wed, 11 Mar 2015 18:53:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=O2vGIxFtZGydR/s6d+zxV8bcBwKsxTmi654piOpDilA=; b=OlpQQc5A9usVGteJuc7Xn2PIAPxbnTIQuPlGo+LsXq5Kusy0b9vyEYBGUSqHpCt5ps mRDGbji+vVQTc7DRBk+xRyEv6zJiU8/5t8xlsPHJNfSJXaiv5tg8hWqs65/+aa30zleY i1gnVb2jiyX2rLfrQ7obxtVrSB0grnOfg1c8vIp73/81SvIaKvca1ZI68ePpsdFJkD9d 05xcYZlhfLPTVVlrZ/pSb1C8hAnm+Rn0y1CosVilIU9c27sojwyBLwP+WKzkTTdPWdeQ tdmDnPNsZBbUUOcd1R+gfaNEPKJRlaBzG8+HwAGgvgbXP0hYwnfjadRqKvtP2oQ/T8O8 gJ1g== X-Gm-Message-State: ALoCoQkio4+D4ljSvyGeTuBj74gJC6nQbJVrdEVvOZijabDYSQ/rxDUoCVO5Vr2+l0fh+u6ukARj X-Received: by 10.43.81.20 with SMTP id zw20mr44954373icb.84.1426125216047; Wed, 11 Mar 2015 18:53:36 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id ha4sm3572214igb.21.2015.03.11.18.53.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 18:53:35 -0700 (PDT) Message-ID: <5500F1A2.4010400@andyet.net> Date: Wed, 11 Mar 2015 19:53:38 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] percent-encoding in NSS syntax (CREFs 2,3,4) 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: Thu, 12 Mar 2015 01:53:42 -0000 In draft-ietf-urnbis-rfc2141bis-urn-10, we included a note about Ted Hardie's proposed text change regarding percent-encoding of characters in the NSS syntax (CREFs 2, 3, and 4 in the published document). OLD Depending on the rules governing a namespace, names that are valid in a namespace might contain characters that are not allowed in URNs according to the "pchar" rule (e.g., characters outside the ASCII range or characters that are reserved in URIs, such as "/", "?", and "#"). Such a string MUST be translated into a conformant NSS before using it as a protocol element or otherwise passing it on to other applications. Translation is done by percent-encoding each disallowed character using the method defined in Section 2.1 of [RFC3986]. Note that the "%" character is allowed only for the purpose of percent-encoding. NEW Depending on the rules governing a namespace, names that are valid in a namespace might contain characters that are not found in the "pchar" production above (e.g., characters outside the ASCII range or characters that are reserved in URIs, such as "/", "?", and "#"). While these may be valid names, they are not valid URNs until those strings are translated into a conformant NSS. Translation is done by percent-encoding each disallowed character using the method defined in Section 2.1 of the generic URI specification [RFC3986] Note that the "%" character is allowed only for the purpose of percent- encoding. I have no strong objections to this proposal, modulo some slight editorial adjustments (e.g., changing "are not found in" to "are not allowed by"). Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Mar 11 18:54:51 2015 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 A536C1A89AB for ; Wed, 11 Mar 2015 18:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 zunWI6G6ZHEx for ; Wed, 11 Mar 2015 18:54:49 -0700 (PDT) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490F41A89A7 for ; Wed, 11 Mar 2015 18:54:49 -0700 (PDT) Received: by iegc3 with SMTP id c3so9454413ieg.3 for ; Wed, 11 Mar 2015 18:54:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=4G5rDw5IHtBsr8YL8f32wPqIecF0FEKVK3t7c+M7FSw=; b=BoQCEbRTXgXn5od7KkjvYw9p0WntHsFLMHfU2UVZrA9/sT8Tq1iSp01SoYCGFkyrPv OSmomC363g8t84Z9zVM3NEt6QS54qAHe1eXppr05DCZZX58NM9Ks43NctQ53w0MDxMML DG9pjX8Ybr394YLPkTU9Ydd9iyKbdIYtidqh/SvZa/NBDxSVDBzjx+lELTFWsEO1s9h4 QdHX2R2GR6DYb3uNxnUh7Xf6kkR9iZR5LQJ5UXR8EkOUmzPKgzIuKSnDGra7WGPjgUK9 d6mRGQAUMtXA5fCmfV5mq63K7ePhYdvItY9Gw2H5nJlih06kiSdvfcz2jy3eS1cMzoGg jU7g== X-Gm-Message-State: ALoCoQnLj5+urpuBXeS3h+dOV3aKyNkKAThez6llDhkDnRfaf/CoHJQAyAeHydoMZBKC4lozNub2 X-Received: by 10.107.133.16 with SMTP id h16mr30285099iod.31.1426125288708; Wed, 11 Mar 2015 18:54:48 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id j87sm3559067iod.21.2015.03.11.18.54.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 18:54:48 -0700 (PDT) Message-ID: <5500F1EA.3050507@andyet.net> Date: Wed, 11 Mar 2015 19:54:50 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] possible conditions for using p-components (CREF5) 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: Thu, 12 Mar 2015 01:54:50 -0000 Section 3 states: As general guidance that might not apply to all cases, it would be inappropriate for namespaces that do not intend to support resolution services to allow q-components. Namespaces that deal with digital manifestations might be able to support f-components. CREF5 poses a question for the working group: "What, if anything, should be said about p-components here?" Personally, I am not sure of any general suggestions we can make about when it might be appropriate or inappropriate to use p-components, so I'd prefer to remain silent about the matter. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Mar 11 19:08:34 2015 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 9FABB1A89AE for ; Wed, 11 Mar 2015 19:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 38wiacm1sNLN for ; Wed, 11 Mar 2015 19:08:31 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 434BE1A89AB for ; Wed, 11 Mar 2015 19:08:31 -0700 (PDT) Received: by iecsl2 with SMTP id sl2so9019770iec.1 for ; Wed, 11 Mar 2015 19:08:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=GBl9VdKakGH2SqEkij9y8QurjHOzQhMPjW9WzD3VaUU=; b=cMyIpizWYT7qTfFRTniGvD0/Mwo2hpLRYib7omJ6ffEseFL7ajrDHOech9ggc6+ffH 5UZFwdzhXBz7Q/h96GeoV9Kj7PRR6CD9updqaHAdAaEt9iuHNThJ/zfn0Em0HQG6sPBL lnG+rfosiu8So1jpkDQQDorvtsTpmAzySRxW0HtpUS+nDoEvI06DqDLao2c6MZ0cJmBx C0w0llNER6osAxq+w432n+rXbdXyOuL3s4IZ2Kgr1lVK4PN5Mp9a9TqtJU+LxpbRkBb8 YQiNXDCjA9hzxVBC4yj0NotHYJOBvRXLCeprlIZ8MFaB1D+tSwgRinHenpGsHu8NSFqx I7Ew== X-Gm-Message-State: ALoCoQlUT8IUuMoCg4pTSk/EhaVaTNOVcV1si2pfW+wOWVyAxhtVbZZGvYbIYu+KHQww5IOoYAeq X-Received: by 10.50.79.161 with SMTP id k1mr69725435igx.14.1426126106579; Wed, 11 Mar 2015 19:08:26 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id 17sm3568675iol.39.2015.03.11.19.08.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 19:08:26 -0700 (PDT) Message-ID: <5500F51C.90904@andyet.net> Date: Wed, 11 Mar 2015 20:08:28 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] case normalization (CREFs 6,7) 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: Thu, 12 Mar 2015 02:08:32 -0000 Section 4.1 talks about applying "case normalization" to certain parts of a URN in order to determine equivalence. Ted Hardie is right that we need to mention p-components here. (CREF7) I suggest that we exclude p-components from the case normalization process, as we have done for q-components and f-components. This means that case normalizaton would be applied only to the scheme, the NID, and any percent-encoded characters. As a result, we can (I hope) avoid some of the issues pointed to by CREF6 (see https://github.com/MelindaShore/urnbis/issues/3), because any characters outside the ASCII range would be percent-encoded (not included "natively" as, say, UTF-8-encoded Unicode characters). At least one question would remain: are p-components ignored or not for purposes of determining equivalence? Personally I would prefer that only the assigned-urn be used for determining equivalence. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Mar 11 19:10:33 2015 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 2A6491A89B3 for ; Wed, 11 Mar 2015 19:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 0QKp0Apf2h3X for ; Wed, 11 Mar 2015 19:10:31 -0700 (PDT) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06C251A8990 for ; Wed, 11 Mar 2015 19:10:31 -0700 (PDT) Received: by iecsl2 with SMTP id sl2so9114881iec.1 for ; Wed, 11 Mar 2015 19:10:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=n3obXhTmE2/+b7NuBrTcn1jKQLlKko4XSQQ5tKbzPe8=; b=I11MGdKnn9pu2EMRi1+pGuYXC+2R3f/pmTqn6eqzInklrpjpZw6dGu+7X2DPaflnMF s5wMh45K+r1tuef8ruFqoFd4BTKJGXqOr2xODgN+jJZaJM78yylaGeYW3bFVqZ+iQYlv gPbM1WZdlfzRenmvtIl/QSWBt9QKrGg296uA0LNwxqxnSjvhqhm72tlVn5kdDymzJgp+ 3Q+vUxn6O4jT5ROoVbX2bIcoLpyoOQMJ1656ghy2jUp9abOLUsoR921Y7aYGF8TgCaF2 N7lQgEncrLhtwBTMJQmfOP633Y7jsBtqtXyv8mDtJwleI4kGuDMeWenrS00TOpCRjnNh tiTg== X-Gm-Message-State: ALoCoQmKzjnoOnGw9yeDuuQnGJd4su5JbH3TVnc0zK/ey21yqXCUaZ+nKktUYs39weBEpdCCZIfH X-Received: by 10.107.31.14 with SMTP id f14mr32260222iof.28.1426126230241; Wed, 11 Mar 2015 19:10:30 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id 3sm3589328iom.4.2015.03.11.19.10.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 19:10:29 -0700 (PDT) Message-ID: <5500F598.20108@andyet.net> Date: Wed, 11 Mar 2015 20:10:32 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] examples (CREF8) 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: Thu, 12 Mar 2015 02:10:32 -0000 In Section 4.2, CREF8 states: "We should still add some examples with p-, q-, and/or f-components to the above list." I did add some examples with q-components and f-components, but not with p-components. Also we need to add some examples with percent-encoding of characters outside the ASCII range as well as disallowed or reserved characters. I can add more examples in the next version. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Mar 11 19:13:37 2015 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 594A81A89B4 for ; Wed, 11 Mar 2015 19:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 YBpSiVRBw9n0 for ; Wed, 11 Mar 2015 19:13:34 -0700 (PDT) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F16E1A89B3 for ; Wed, 11 Mar 2015 19:13:34 -0700 (PDT) Received: by iecsl2 with SMTP id sl2so9253424iec.1 for ; Wed, 11 Mar 2015 19:13:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=iA/i9nzNjbPwMsh0iqDlqYFxoEWO3nc9VDS2B8Grkj0=; b=S0kOI2Qe0Rl3/gMwbO+haWnX2s8SApQHnyITEd3/3ibmXoEREoroJGgvJBuCZY/Gt0 2ZZbprAVXfw08Hgev8MRlPvQ9MrulPOVcxGsVMhaj5MPxgUT/kSEaqM4T8SF0UZOP6Yl vPpbLKXgBDlIngzwdchO1tBGODfvDoscOlwuNEyxfjBNE8z5VKORUab1gasklaMDQVdM QOwlZt7jpfN4iM2hRdlaGivoHgMy5bx8Uvsyoin/J08jWhikkUvBQTDArmlJ6sF9KzpF gc0oQzyK7SzjCRMK7D26UJSSk2aNFz1JZhv2Htj4U58RYPMHE2BwRZPf3smHT3u2CYWh iAug== X-Gm-Message-State: ALoCoQkT7J06PgqccBi10jvYA9Wppt7IWWKCRYQQzWbgI1aMWTYYryK1+87zgul5U2tbRqWoS0js X-Received: by 10.50.78.131 with SMTP id b3mr96168889igx.0.1426126413712; Wed, 11 Mar 2015 19:13:33 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id ht8sm3622831igb.0.2015.03.11.19.13.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 19:13:33 -0700 (PDT) Message-ID: <5500F64F.8090508@andyet.net> Date: Wed, 11 Mar 2015 20:13:35 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] URI contexts (CREF9) 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: Thu, 12 Mar 2015 02:13:36 -0000 Section 5 states: Because a URN is, syntactically, a URI under the "urn" scheme, in theory a URN can be placed in any protocol slot that allows for a URI (e.g., an XML namespace name [XML-NAMES]). However, this does not imply that, semantically, it always makes sense in practice to place a URN in a given URI protocol slot; in particular, because a URN might not specify the location of a resource or even point indirectly to one, it might not be appropriate to place a URN in a URI protocol slot that points to a resource (examples include the 'href' and 'src' attributes and the element in HTML, as well as the 'xml:base' attribute in XML [XML-BASE]). Ultimately, specifications of where it is appropriate to use URNs, or URNs created within particular URN namespaces, are the responsibility of descriptions of individual URI schemes and their expected uses; this specification cannot possibly anticipate all of the relevant cases. Ted suggested "individual URI contexts" instead of "individual URI schemes". (CREF9) I wholeheartedly agree, and I thought that I had already made a similar change but I see that I had not. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Mar 11 19:16:21 2015 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 5A6911A89C6 for ; Wed, 11 Mar 2015 19:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 x933mLiVdVtH for ; Wed, 11 Mar 2015 19:16:19 -0700 (PDT) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E690C1A89B1 for ; Wed, 11 Mar 2015 19:16:18 -0700 (PDT) Received: by iecvj10 with SMTP id vj10so9112685iec.0 for ; Wed, 11 Mar 2015 19:16:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=mF/tols4ArmpQx3sI/i9zOZbA0zIygBbh9jjgDkv8Rg=; b=JFihBiH2hy8CWjflk1wbRTDoaJUlf+pN8Wh+QXPFSwDUT1mf4cdANLyGyP4K6kXk3f 9ftRFs087wPmcWUNFzF8YNOOVlAI6iGXrI67T2xl8VJgWLQxu0ZU2p4JCaJldFctm3/a C68DsepHSlx0Iu9NtIM5GYdREYZGpo+1RsolnmVXpnUH8uo363QpfhsJcLLnOVIQUQ9e bTFsfvTBbiimy6MqUJzQo3C5YkWCs+XYQUcYliyQY52zVGUAaH8tpyqJvRpqa2SAACoj 50vCvzER5ZooGTYKuOdG3y7As+qITq/REzibFeJUq3wQHd7QeJd81CGueRApiQLp9UjS YvEg== X-Gm-Message-State: ALoCoQlZ5X7t11dVFu7P9nsxuPUPToC8MoyVwRa2julcq/ZbZrtVS852Il7JwAg6XFnbSHehE5tH X-Received: by 10.42.203.147 with SMTP id fi19mr45335094icb.12.1426126574695; Wed, 11 Mar 2015 19:16:14 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id tg4sm3619390igb.4.2015.03.11.19.16.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 19:16:14 -0700 (PDT) Message-ID: <5500F6F0.8090603@andyet.net> Date: Wed, 11 Mar 2015 20:16:16 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] constraining URI resolvers (CREF10) 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: Thu, 12 Mar 2015 02:16:20 -0000 Section 5 states: A resolver that conforms to the URI specification [RFC3986] will extract a scheme of "urn" rather than a scheme value of "urn:". CREF10 proposes alternate text (because, as Henry Thompson points out, we cannot constrain URI resolvers in general): In part because of the separation of semantics from syntax [I-D.ietf-urnbis-semantics-clarif], generic URI processors must pay special attention to the parsing and analysis rules of RFC 3986 and, in particular, must treat the URI as opaque unless the scheme and its requirements are recognized. The URN resolver can either be an external resolver that the URI resolver knows of, or it can be functionality built into the URI resolver. Note that this requirement MAY impose constraints on the contexts in which URNs are appropriately used; see the previous section. This looks good to me. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Mar 11 19:25:02 2015 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 62E011A89B5 for ; Wed, 11 Mar 2015 19:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 HyzYXEjjLCMF for ; Wed, 11 Mar 2015 19:24:59 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE4441A89B9 for ; Wed, 11 Mar 2015 19:24:59 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so10090679iec.2 for ; Wed, 11 Mar 2015 19:24:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=JYwNhcJhXk6tzyLhCK8uPbsonXONpci2zuFdTvGNXFY=; b=QHlT2Bt/xsgsgBrwwBRrwFC/Qi67Hv4JDoRDeAyt/bP33ZSdelqhUKkzGaqKIr0V7g 0k/sp3uzN+8g8iUWTfyqhuStaGc/heed/jv9ca6T71ODxMEHTqtQGJbkZ6rH1avft6jY AMthzKcX6pEjScNz233r8wEm4ch0w1GgSv4reiDg9iWI/vPnKX/VX5nluwqXBKBtGvFn Lw3T/s/XSQfdMfEvRhSuhX3xcvEgBD7qVYS8QXoN5EeKM1fIR+Ao8+ALZxpQdPMRfJmS w0oV/tj3fsgvcPNp+Zm+9ZwV1QvaQ4FrX3GoDFsAaeZK68KiW0O7a4NlYoZvEhP1ypXk GnIQ== X-Gm-Message-State: ALoCoQmPmz7bVnqsG7Wri5CoxUjBwhSN2Ibl/JgxD7kzBvetNwd3KBESvK+gOMHMi0jlLBhR3cE0 X-Received: by 10.50.66.170 with SMTP id g10mr96200442igt.49.1426127096431; Wed, 11 Mar 2015 19:24:56 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id nv8sm11130125igb.6.2015.03.11.19.24.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 19:24:55 -0700 (PDT) Message-ID: <5500F8F9.1010001@andyet.net> Date: Wed, 11 Mar 2015 20:24:57 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] multiple URNs for the same resource (CREF11) 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: Thu, 12 Mar 2015 02:25:01 -0000 Section 6 states: With regard to global uniqueness, using different NIDs for different collections of identifiers ensures that no two URNs will be the same for different resources, since each collection is required to uniquely assign each identifier. However, a single resource can have more than one URN assigned to it for different purposes (e.g., some numbers might be valid identifiers in two different identifier systems, where the namespace identifier differentiates between the resulting URNs). Subject to other constraints, such as those imposed by the URI syntax [RFC3986], the rules of the URN scheme are intended to allow preserving the normal and natural form of identifiers specified elsewhere and treated as URN namespaces. CREF11 poses a question for the WG: Ted suggested adding a concrete example, "as this seems likely to be open to confusion. The RFC 5031 emergency services may provide one (e.g. urn:service:counseling.mental-health and urn:service:counseling.suicide may be the same resource), but any concrete example would likely be an improvement." Is that example ok? Would anyone like to suggest other text or an additional example?]] I think that example is fine - we might want to clearly describe that the "resource" here is the same service number or dial string as explained in the introduction to RFC 5031. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Mar 11 19:38:11 2015 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 1FBE31A89D3 for ; Wed, 11 Mar 2015 19:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 a8kJ8re7Trxj for ; Wed, 11 Mar 2015 19:38:09 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B803E1A89C7 for ; Wed, 11 Mar 2015 19:38:09 -0700 (PDT) Received: by padbj1 with SMTP id bj1so16404147pad.12 for ; Wed, 11 Mar 2015 19:38:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=x1Fi9rNkbSrrWF59DzpNgYc7QAiszH6+lP7hqbPk6CA=; b=YQKv6LOBK5haivs/pN/F01ImpAkjY97x+dLccUQtg5URkQTvIVs7hjT8B/sQXaPlQ2 AaYttR6IIbjbQwvehGmWkU72zUqBKv16Khuf+dBSKIXgS+yrRguDq5X3dHBktSWfhgv5 ltDlcqujc3YxPXxm4kwF26GVlvjqgotzw7rWsCAQ4zgy73FccH6a74UwgG1jzt7c2uM8 hwLhOwnFxgnQudbo0mfVRpc8991qezqjCEnzqdyiP1U8s/D8p8WfO8X9ZK2YnNPgP+xp Ag2suQ2762pH9o+ZBbxb06JWcjYfFqglkpLlA6GY7uWRlmUZl/3Rie1ULQomv4q920D6 /D3g== X-Gm-Message-State: ALoCoQnOr7VvqV2C8Wltoz5j+jf4/UQHm0q19Akk7/qcFMvjjlmVVrSwMJ4L/CxbjzcEGNylFDhU X-Received: by 10.70.101.226 with SMTP id fj2mr42861496pdb.23.1426127889372; Wed, 11 Mar 2015 19:38:09 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id q4sm5895941pdj.2.2015.03.11.19.38.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 19:38:08 -0700 (PDT) Message-ID: <5500FC11.1060109@andyet.net> Date: Wed, 11 Mar 2015 20:38:09 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] continued validity of URNs (CREF12) 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: Thu, 12 Mar 2015 02:38:11 -0000 Section 6.1 states: 3. Commitment to not reassigning existing names and to allowing old names to continue to be valid, even if the owners or assignees of those names are no longer members or customers of that organization. With regard to URN resolution [RFC2276], this does not mean that there needs to be resolution of such names, only that the names will not resolve to false or stale information. CREF12 poses a question for the WG about how we should handle this question from Henry Thompson: "Really? If a piece of retrievable metadata for some URN is the name and (postal) address of the publisher of whatever it identifies, and they've gone out of business, that metadata is necessarily stale, isn't it?" First, I'm not sure what we mean by "retrievable metadata for some URN" here because I think it confuses the issue, which is about the URNs themselves. Let's say that someone defines a urn:publisher namespace and that a publisher "Leblanc Press" is identified by urn:publisher:24601. The rule about not reassigning the URN doesn't have anything to do with the address of Leblanc Press, the continued business operations of Leblanc Press, or any other metadata associated with Leblanc Press. All it says is "don't reassign urn:publisher:24601 to, say, Madeleine Press". The URN always refers to Leblanc Press, even if that "resource" has been out of business for 1000 years. If some clarifying text is in order here, let the authors know. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Mar 11 19:38:25 2015 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 C10751A89F9 for ; Wed, 11 Mar 2015 19:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 khHz45eNbnCN for ; Wed, 11 Mar 2015 19:38:22 -0700 (PDT) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E410B1A89F6 for ; Wed, 11 Mar 2015 19:38:21 -0700 (PDT) Received: by padfa1 with SMTP id fa1so16420524pad.9 for ; Wed, 11 Mar 2015 19:38:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=x1Fi9rNkbSrrWF59DzpNgYc7QAiszH6+lP7hqbPk6CA=; b=k2ZEQ/3+r6QSbVb54PxzE8cVTasOo9Yu0pdETV6H4DuCSgJqP1NFVvVNIbx0q7o21n Ax41gAIWFsgBsLtrZ8YkNjX1ZkJZ+Czg96AmAu9lxeGJfRlhEcg5mdYEbCSWvQtmPpZF sSOb0Mmc0r51PtXcLY63LlL5jKUAwdQ1cqnRwHX+CkajsgC469J1Nb6X5HSGygTMPSrY wgO8333YH+VL70eqNFOEMNrOb0jH0D/9mOJ3j/J3dY1UfBKeJc6CmAcnep1uC3L9xylB 6cIoyDPyHST1dcAdf8WljxwCfSHYjGwloL0sFNAiVc1pVEazlCEMdv0FP88Fdu6Sv2xs ZxWg== X-Gm-Message-State: ALoCoQnGpV8xETMnKK7tPJ9J5aYZ3TTC//H+jJD0VyY+hjTLHLcGFDJtbLyF70c2rU29gvthXQMM X-Received: by 10.70.39.106 with SMTP id o10mr66317800pdk.88.1426127901551; Wed, 11 Mar 2015 19:38:21 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id g3sm8144418pdg.39.2015.03.11.19.37.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 19:38:20 -0700 (PDT) Message-ID: <5500FBB8.5030006@andyet.net> Date: Wed, 11 Mar 2015 20:36:40 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] continued validity of URNs (CREF12) 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: Thu, 12 Mar 2015 02:38:23 -0000 Section 6.1 states: 3. Commitment to not reassigning existing names and to allowing old names to continue to be valid, even if the owners or assignees of those names are no longer members or customers of that organization. With regard to URN resolution [RFC2276], this does not mean that there needs to be resolution of such names, only that the names will not resolve to false or stale information. CREF12 poses a question for the WG about how we should handle this question from Henry Thompson: "Really? If a piece of retrievable metadata for some URN is the name and (postal) address of the publisher of whatever it identifies, and they've gone out of business, that metadata is necessarily stale, isn't it?" First, I'm not sure what we mean by "retrievable metadata for some URN" here because I think it confuses the issue, which is about the URNs themselves. Let's say that someone defines a urn:publisher namespace and that a publisher "Leblanc Press" is identified by urn:publisher:24601. The rule about not reassigning the URN doesn't have anything to do with the address of Leblanc Press, the continued business operations of Leblanc Press, or any other metadata associated with Leblanc Press. All it says is "don't reassign urn:publisher:24601 to, say, Madeleine Press". The URN always refers to Leblanc Press, even if that "resource" has been out of business for 1000 years. If some clarifying text is in order here, let the authors know. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Mar 11 19:41:38 2015 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 F19791A89FE for ; Wed, 11 Mar 2015 19:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.601 X-Spam-Level: X-Spam-Status: No, score=-4.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, 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 xIfOWvfKGrsX for ; Wed, 11 Mar 2015 19:41:30 -0700 (PDT) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961321A89C7 for ; Wed, 11 Mar 2015 19:41:28 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so10840422iec.2 for ; Wed, 11 Mar 2015 19:41:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=4qFVh2STHx2UkBCwJWxPnUkMEcxDEA3IfI92URTghio=; b=F3RUcAMeugcJ9YfLnifp22Jf/9uLvGr0i5UJuI0gz4+de1vMCvPWcNpPMi0KRSG3ZG wC7ZGsGJSGJQgZDcHQ7q2Hbwpbv3/e2PaSdjRLHkELvUNoz6sbDtZQ6vqLorZKKa+ZU3 UjtWttXUBA1hUQc6LbAUX7ilz/8GCW9JdMziSC6r5WhSxHVRm7nc8K4vSLSnyfQIWkWR lVpFKEf31x07HOcOyu7A2TF1FiUoSexHypAjlyogNyPcYScwoZmgLkdg+pMbsjQ6n16E a1w+QtHMoeLSxl9lOeEz84gS5HkBj6Sc8PHUyKmEK1NmZ7TQ596J8sWdv2DGLuO1ju3j lLpQ== X-Gm-Message-State: ALoCoQmYyQzMS7gE5SRG8S/5IqIz+EFz/+3heI8Bh8oWngJMF1lE0lHnbRdHWRHqjPpT8Otc3qNM X-Received: by 10.43.96.196 with SMTP id ch4mr44848256icc.68.1426128087854; Wed, 11 Mar 2015 19:41:27 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id i16sm3625545ioe.17.2015.03.11.19.41.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 19:41:26 -0700 (PDT) Message-ID: <5500FCD6.1000605@andyet.net> Date: Wed, 11 Mar 2015 20:41:26 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] reserved NID strings (CREFs 13,14) 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: Thu, 12 Mar 2015 02:41:32 -0000 Section 6.1 states the following constraint about NIDs: 5. It MUST NOT start with the string "xn--" or any other string consisting of two letters followed by two hyphens. Those strings are reserved for potential representation of DNS A-labels and similar strings in the future [RFC5890]. CREF13 points out that IDNA reserves the entire collection of strings starting with two characters followed by two hyphens. I think it would be fine to add that restriction. CREF14 poses a question for the WG: Ted also points out that proposed NIDs that are, or resemble, ISO 3166-1 alpha-3 codes may need special consideration in expert review becuase some countries claim ownership of them (and, at least implicitly, their use by anyone other than that country could be deceptive. On a related and more general note, Henry inquired whether we need dispute resolution and/or trademark procedures. The WG needs to decide whether to address those issues and, if so, how. RFC 2141 was published in May 1997, before ISO 3166-1 (September 1997). Thus it's not surprising that RFC 2141 didn't account for alpha-3 codes. I think it's reasonable to add a constraint about that now. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Mar 11 19:43:24 2015 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 8F3171A89C7 for ; Wed, 11 Mar 2015 19:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 PPIIcadD6eQ9 for ; Wed, 11 Mar 2015 19:43:19 -0700 (PDT) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F071A8953 for ; Wed, 11 Mar 2015 19:43:19 -0700 (PDT) Received: by iecsl2 with SMTP id sl2so10587021iec.1 for ; Wed, 11 Mar 2015 19:43:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=vfpt3YAWXyBRigT10WKRMDnShmjvvcDf/cZMxXNHtrw=; b=SBfZJMIYsLx0axdRl9FfikYeVto0jh37vFW8w+ttm4eqS0UvMxfjX4S3oe/IiLX/f7 hn/rlJYPYbVhaUkGNzm+h2B8aUQVodoukn6IXUu7KU8YjVzmVrW2fv3zZpjt87YcAOLo DQ8grL+8g2mzSF8bfRfF+7pbiqOWdGvZQCFgWqrD8KdsMdiJq9pzzFLG/3WjDPI/7sMn rSpEEFf/14JxM4IxWHavOIIPsuYI14lAmjlpd8MDCgBkbuB0gNzKT1h5RzIxlLPxP1Ll cHv0+8Ab1n5kcmlBm0xln4vrUcNvXN98XnUL3z0+PxK4BtUhHrgwKg1Ht9ZoJaJCXS1+ bytw== X-Gm-Message-State: ALoCoQlDHt8fcYqO1uyWnnjdS2MTw2Vg1MtsIh6olmHNdMTpl8KLyguaWw7TmhRSYQciFYrI2aoe X-Received: by 10.50.25.166 with SMTP id d6mr49156938igg.41.1426128197216; Wed, 11 Mar 2015 19:43:17 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id ie15sm3649992igb.12.2015.03.11.19.43.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 19:43:16 -0700 (PDT) Message-ID: <5500FD46.7070402@andyet.net> Date: Wed, 11 Mar 2015 20:43:18 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] defining URN namespaces (CREF15) 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: Thu, 12 Mar 2015 02:43:23 -0000 Section 7 states: The material in this section is intended as guidance to both designers of URN namespaces and (expert) reviewers of proposed URN namespace registrations. More information for the latter appears in Section 9. CREF15 poses a question for the WG: Henry would like to see a SHOULD requirement on the definitions here. The WG needs to decide whether that is necessary and/or desirable. Although I'm not a big fan of procedural SHOULDs and MUSTs, I have no strong objections to using normative keywords here. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Mar 11 19:45:07 2015 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 E157C1A89C7 for ; Wed, 11 Mar 2015 19:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 K3exxu4NZggx for ; Wed, 11 Mar 2015 19:45:05 -0700 (PDT) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1341A8953 for ; Wed, 11 Mar 2015 19:45:05 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so11005107iec.2 for ; Wed, 11 Mar 2015 19:45:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=yCKJo0wxKDX25Ie+IFdWwj9pOtKub35Jp570H/EA1sI=; b=McXD3p+oNM8ZaP4FvhBVuToQUS6BtUD54TNT/4m+ztpVNR9qRMOIJE2eaLIt7oMfyX vTUyWmWaPBqGRSJJcoLnxDHF8i4/jAqfAKA/fMDyXhHW7C3Rmpy9BX5VsT3/RYJ8/DgZ 10Um+M1QJKC88Vaj3Cnqvtsgg7OxY1Lzo7PEavNJJ7omzJdihFWwglXw4+0CD6oeG4ny dM3QzUIjwQGMLKw23DftqEjypt9o7zHZSeCFJpiY8z1Z48Gg07kzb5mHTC+qaJ5tOmJW iQ55YYln6HLYtuiCefI2qYuewdAf5rYSmD4ANP7OyXYt7/fPQvLLGlMtLU+IoeaOKhOi ncew== X-Gm-Message-State: ALoCoQms+TYhul7s14op58/Ez8DVevu0jSGhZCQDOiZuIQ845mob4hpQ714bhbVCQ4C1PKXXYW+F X-Received: by 10.50.60.72 with SMTP id f8mr98065566igr.31.1426128304125; Wed, 11 Mar 2015 19:45:04 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id m132sm3622880ioe.33.2015.03.11.19.45.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 19:45:03 -0700 (PDT) Message-ID: <5500FDAF.1030009@andyet.net> Date: Wed, 11 Mar 2015 20:45:03 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] resolution section (CREF16) 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: Thu, 12 Mar 2015 02:45:07 -0000 Section 7.5 states: The "Resolution" section specifies the rules for resolution of URNs assigned within the namespace. If such URNs are intended to be resolvable, the namespace needs to be registered in a Resolution Discovery System (RDS, see [RFC2276]) such as DDDS. Resolution then proceeds according to standard URI resolution processes, as well as the mechanisms of the RDS. This section ought to list the requirements for becoming a recognized resolver of URNs in the relevant namespace (and being so listed in the RDS registry). Answers might include, but are not limited to: CREF16 proposes alternate text: The "Resolution" section specifies the rules for resolution of URNs assigned within the namespace. This section SHOULD list the requirements for becoming a recognized resolver of URNs in the relevant namespace. Answers might include, but are not limited to: That seems simpler, so I approve. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Mar 11 19:57:18 2015 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 1C3241A89D3 for ; Wed, 11 Mar 2015 19:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 PyGO6w6sVCGv for ; Wed, 11 Mar 2015 19:57:15 -0700 (PDT) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6921A8990 for ; Wed, 11 Mar 2015 19:57:15 -0700 (PDT) Received: by iegc3 with SMTP id c3so12364238ieg.3 for ; Wed, 11 Mar 2015 19:57:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=bLdWB29LXdJVVnQNUwBXioThLo1eINo4DrFFJpTNAqc=; b=S73NvCXq36p/R4NS8ps+BfMu7xU0hXXSAQeso/SpoxSVLKnkwrs0AuTo6Qa6sLYx8R ev7GVZq5Trmv8R/Xn6W9LkusW21BQlxXhmgkho8QMG6mh+pf4NRKVcPNlBpFENcHj6EO W483BW/8KuFlVR1YqgpfAeGlle1kq4squxoWpg4nxUrg7E3+RON3tPsy2IURG8vjKMmS RneCTGUYMvTmYuevO34zuZ7cli5paaqyos+xMP//taaSU7HZoR1//36Pn45LXMEWHrki ursy6FrH0fPsK0J6u9/hhXJCU8eJk+ZZ6u26InQGmZH0fGfetr6lUUL2hnL2ilTrULWv vjsA== X-Gm-Message-State: ALoCoQmQDeYeAFYUHUW0WHiUBiXJJmr5SHQLpTyODuh7nLcWZ0x6gHOCMnoqbdyj1TD0bT04NrkC X-Received: by 10.42.37.69 with SMTP id x5mr45619397icd.15.1426129034944; Wed, 11 Mar 2015 19:57:14 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id i1sm11176340igh.5.2015.03.11.19.57.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 19:57:14 -0700 (PDT) Message-ID: <5501008C.1000402@andyet.net> Date: Wed, 11 Mar 2015 20:57:16 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] expert review procedures (CREF17) 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: Thu, 12 Mar 2015 02:57:17 -0000 Regarding Section 8, CREF17 notes: We've had several discussions that suggest a somewhat different Expert Review model than is covered by RFC 5226. Those discussions haven't gotten quite far enough to let us generate specific text, so the WG has work to do in this area. John provided the following suggestions: ### (1) We want Expert Review, with the guidance that now appears in Sections 7 and 9, for namespaces that are not intended to be standardized in/by the IETF. (2) For namespaces intended for standardization, IETF Consensus is necessary for registration although a preliminary expert review may be helpful. (3) While namespaces that are essentially overlays on identifier standards produced and managed by other standards bodies, the Expert Review process is intended more as an advisory and coordination on rather than one or acceptance or rejection and some sort of "fast track" procedure (and/or even a different review process) may be in order. I would hope we can explicitly give the IESG some flexibility in those situations rather than having to spell everything out in 2141bis. (4) For namespaces that do not fall into categories (2) or (3), we have a strong preference for registration, even poor-quality registrations that only assure uniqueness of NIDs, over a slow and/or onerous registration approval process that encourages use of names without registration. ### I think that's mostly right. I do have a few questions and comments: (a) I'm not sure exactly what it means for a URN namespace to be standardized within the IETF. I suppose we mean something like RFC 5031 or the various IETF specifications that have established URNs for XML namespaces (say, RFC 6501 or RFC 6120). Some of these are in existing namespaces (e.g., urn:ietf:params:xml:ns....). Some of them are more novel (urn:sos in RFC 5031). To my mind, it might be fine to specify Expert Review for the namespaces themselves here, whereas the relevant specifications require IETF Consensus. I think this affects the order of events (e.g., preliminary expert review, IESG approval, then assignment / registration) more than the registration policy itself. (b) It seems sensible to have a "fast track" for other SDOs to register URN namespaces (similar to approaches we've taken or have talked about taking for things like media type registrations). Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Mar 11 20:06:31 2015 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 CF2261A89FE for ; Wed, 11 Mar 2015 20:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 msAHxZf3w_5Y for ; Wed, 11 Mar 2015 20:06:29 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637FE1A89FC for ; Wed, 11 Mar 2015 20:06:29 -0700 (PDT) Received: by iecsl2 with SMTP id sl2so11654264iec.1 for ; Wed, 11 Mar 2015 20:06:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=a13SpCCIIs9X1GhWK5eMVkF0lxmTlQKc4fB3oYlGXEs=; b=Pb3GMZdHipVG+im6VnJYUK0N6hTD0yAvyiY2aRtKhYknt0SHnzIRGu4j8cMfoVOHi6 t2W2Z6rO/YHNEDcyHtgQTj62owB7yG26t5lfY0/vF74q1wb347mt2ijOMKIR3gbSwaUL kL1jtpzQY2ydDkCivjtdN3FCX/wrMA1B7xxOt0J2bQnL8UNsfWtyfMADoXkPWZECyxfl pfMuUvEXVD8SKd7SQHidZzuOonMSdMXS4Ese8bNuc31DnZsU5AlzoRLMB0xZmAWneABA JLRxwgLgNz3Cj5ZpE4MYSbG6LsI+Q+itUwDOr6HMzoEvJ1NaMqoUMuMyNGe3IOAy/Oo9 lcwg== X-Gm-Message-State: ALoCoQm+4OtWf0cgYIV5G1i8NRNwBlLQjdNpdUh2BD/i1Bc0sRvEQnrl6pzH3O1irIKdF0VeGsr5 X-Received: by 10.107.46.230 with SMTP id u99mr69684520iou.21.1426129586008; Wed, 11 Mar 2015 20:06:26 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id i1sm11189192igh.5.2015.03.11.20.06.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 20:06:25 -0700 (PDT) Message-ID: <550102B3.2050308@andyet.net> Date: Wed, 11 Mar 2015 21:06:27 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] URI interoperability considerations (CREF18) 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: Thu, 12 Mar 2015 03:06:31 -0000 Section 10.1 (which registers the 'urn' URI scheme) points to Section 5 ("URI Conformance") regarding interoperability considerations with regard to URIs. CREF18 suggests that more text is needed here, possibly along the lines of what Juha posted on January 13: "If interoperability concerns arise during the registration of a URN namespace due to e.g. syntax or scope of an identifier system, they should be resolved in the namespace registration request." I hesitate about this slightly, because Section 10.1 is about registration of the 'urn' scheme, not registration of URN namespaces. However, I do see that particular NIDs might be defined in such a way they introduce concerns about interoperability at the URI level. It seems to me that a better way to handle this would be to add another section to the namespace registration template so that we can get any such issues out in the open during the registration process. Then we can say something like what Juha proposes, and have a way to bring those discussions into the open for any particular NID. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Fri Mar 13 04:04:45 2015 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 94AE51A012D for ; Fri, 13 Mar 2015 04:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.911 X-Spam-Level: X-Spam-Status: No, score=-0.911 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 vZq5tk_-bLdl for ; Fri, 13 Mar 2015 04:04:41 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10AA91A011D for ; Fri, 13 Mar 2015 04:04:40 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id t2DB4br5015597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 13 Mar 2015 13:04:38 +0200 Message-ID: <5502C445.6030409@helsinki.fi> Date: Fri, 13 Mar 2015 13:04:37 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: urn@ietf.org References: <5500F8F9.1010001@andyet.net> In-Reply-To: <5500F8F9.1010001@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] multiple URNs for the same resource (CREF11) 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, 13 Mar 2015 11:04:43 -0000 Hello, The most common reason for a single resource having more than one identifier is the overlap in the scopes of identifier systems. For instance, a book can have both ISBN and ISSN if the book has been published in monograph series (and the series has an ISSN). Also, multivolume books like The Lord of the Rings have one ISBN for the entire work, and in addition each volume has its own ISBN. Note that the results of resolving these identifiers will differ: in the former example ISSN would typically resolve to metadata about the monograph series, and in the latter example ISBN of the entire work will retrieve e.g. metadata about all volumes. If we need to give an example of identifier overlap, I prefer using urn:issn and urn:isbn instead of RFC 5031 -based one since ISBN and ISSN are better known and more widely used than the identifier system defined in RFC 5031. Actionable identifiers add another dimension to this. A DOI the publisher has assigned to the article will only resolve to the copy the publisher has in its own repository, and it is possible that the life span of the DOI will not exceed that of the publisher. Therefore the national library which gets the article via legal deposit may assign e.g. a URN:NBN to it, in order to be able to control the resolution process (and, also, to make sure that the persistent identifier used will remain actionable even if the publisher goes out of business). As an example of this, a Swiss article published in German may get three persistent identifiers: DOI by the publisher, and URN:NBNs by German and Swiss national libraries, which will both have a legal deposit copy of the text. Juha On 12.3.2015 4:24, Peter Saint-Andre - &yet wrote: > Section 6 states: > > With regard to global uniqueness, using different NIDs for different > collections of identifiers ensures that no two URNs will be the same > for different resources, since each collection is required to > uniquely assign each identifier. However, a single resource can have > more than one URN assigned to it for different purposes (e.g., some > numbers might be valid identifiers in two different identifier > systems, where the namespace identifier differentiates between the > resulting URNs). Subject to other constraints, such as those imposed > by the URI syntax [RFC3986], the rules of the URN scheme are intended > to allow preserving the normal and natural form of identifiers > specified elsewhere and treated as URN namespaces. > > CREF11 poses a question for the WG: > > Ted suggested adding a concrete example, "as this seems likely to be > open to confusion. The RFC 5031 emergency services may provide one > (e.g. urn:service:counseling.mental-health and > urn:service:counseling.suicide may be the same resource), but any > concrete example would likely be an improvement." Is that example ok? > Would anyone like to suggest other text or an additional example?]] > > I think that example is fine - we might want to clearly describe that > the "resource" here is the same service number or dial string as > explained in the introduction to RFC 5031. > > Peter > -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Fri Mar 13 14:03:04 2015 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 207A41A86E0 for ; Fri, 13 Mar 2015 14:02:53 -0700 (PDT) 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 igw61AEy3NUF for ; Fri, 13 Mar 2015 14:02:51 -0700 (PDT) Received: from zoidberg.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5BD61A6FF1 for ; Fri, 13 Mar 2015 14:02:50 -0700 (PDT) Received: from aran.int.lexiconix.com (pool-108-44-246-138.clppva.fios.verizon.net [108.44.246.138]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by zoidberg.ecotroph.net (Postfix) with ESMTP id 912C7A0512; Fri, 13 Mar 2015 17:02:49 -0400 (EDT) Message-ID: <55035078.9050002@thinkingcat.com> Date: Fri, 13 Mar 2015 17:02:48 -0400 From: "Leslie Daigle (ThinkingCat)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John C Klensin References: <20140826001727.20837.82843.idtracker@ietfa.amsl.com> In-Reply-To: <20140826001727.20837.82843.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] I-D Action: draft-ietf-urnbis-semantics-clarif-00.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, 13 Mar 2015 21:02:53 -0000 I just wanted to register a comment on-list to say I've read this document, and the discussion around it, and I think this document is in good shape for publication. Leslie. On 8/25/14 8:17 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 : URN Semantics Clarification > Author : John C Klensin > Filename : draft-ietf-urnbis-semantics-clarif-00.txt > Pages : 18 > Date : 2014-08-25 > > Abstract: > Experience has shown that identifiers associated with persistent > names have properties and requirements that may be somewhat different > from identifiers associated with the locations of objects. This is > especially true when such names are expected to be stable for a very > long time or when they identify large and complex entities. In order > to allow Uniform Resource Names (URNs) to evolve to meet the needs of > the Library, Museum, Publisher, and Informational Sciences > communities and other users, this specification separates URNs from > the semantic constraints that many people believe are part of the > specification for Uniform Resource Identifiers (URIs) specified in > RFC 3986, updating that document accordingly. The syntax of URNs is > still constrained to that of RFC 3986, so generic URI parsers are > unaffected by this change. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-urnbis-semantics-clarif/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-00 > > > 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 > -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- -- ------------------------------------------------------------------- Leslie Daigle Principal, ThinkingCat Enterprises ldaigle@thinkingcat.com ------------------------------------------------------------------- From nobody Mon Mar 16 05:25:43 2015 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 391CD1A870B for ; Mon, 16 Mar 2015 05:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.85 X-Spam-Level: X-Spam-Status: No, score=-5.85 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] 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 1br9F4_FejzH for ; Mon, 16 Mar 2015 05:25:32 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id B78191A8704 for ; Mon, 16 Mar 2015 05:25:31 -0700 (PDT) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 76E288B84B for ; Mon, 16 Mar 2015 13:25:30 +0100 (CET) X-AuditID: 0a453fe7-f79b36d0000032b6-ac-5506cbba1428 Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id 0A.10.12982.ABBC6055; Mon, 16 Mar 2015 13:25:30 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Mon, 16 Mar 2015 13:25:29 +0100 From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: Comments on draft-ietf-urnbis-rfc2141bis-urn-10 Thread-Index: AdBf5EXxmQCfXUbTSausW6Ov9qCjfg== Date: Mon, 16 Mar 2015 12:25:28 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFFAC84913@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.141] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLsWRmVeSWpSXmKPExsXC5Wr/VXfXabZQgzW/xS2mNn9gcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsbrn9gK/hlULD7fw9rAeEe/i5GTQ0LAROLkssVMELaYxIV7 69m6GLk4hAQOM0p0TX3ECuFsZ5RYve0jkMPOwSagJfE+A6ReREBRYt+zJvYuRg4OYQELiUPH nSHCthKvJ09hhbD1JHqO7AezWQRUJda2fwVbxSvgKXH81VpGEJtRQFZiw4bzzCA2s4C4xKZn 31khzhGQWLIHIi4hICrx8vE/qLiixMKW72BrmQU0Jdbv0odoVZSY0v2QHWK8oMTJmU9YJjAK z0IydRZCxywkHbOQdCxgZFnFyFecm26ol5iil5KSpJeSuokREszPdzD2XXI5xCjAwajEw9ui wBYqxJpYVlyZe4jRn4NJSZTX/yBQiC8pP6UyI7E4I76oNCe1WEmE1+kUUJgXLpxUmpOtJMd7 1pg1VEgcLlpcWlyQmZyZX1ocX1qUc4hRgoMZqPXTSZDWlMTKqtSifIiBhxilOViUxHkn7m4M ERJITyxJzU5NLUgtgslGcHAoSfBeBNkpWJSanlqRlplTApMG6ss7DpQRQJYBO0iRt9oE6CAp ZAl0NzFxcB5i9OHgATpM9jTIYcUFibnFmelQs4V5008ARXlgomBzZXltQeaKwQRRzTzFGCwl zvsL5FgBkIqM0jy4W6XEeGNAWvmRJEBGSinwLukAapBEEkc19RWjJzCKhHkdQObyADMLwo1C vBNAQcoNFQQ7UYbXF2SPKFQM3SwfYNyK8La0gz1ckliC7GGhDrCHoaJQD0uABMVggqjGSTUw svA2bpD5JMPRbvp24dKIP7fFddpumaepyma03nrNqnTsUtzLQ1I3vosHKFbuzWZJfv3r9+qQ xhmbt0yaOvkyu3z77YtXbi9lOTz3c+ZTT/8zf//WFyfkchfdO3tHlXH/XWPhh8qSb4Sy16ap sz1NPK7qfULHsGuau+YORckrwjr1r3f2Lnm0SImlOCPRUIu5qDgRAH5Iv9VPBAAA Archived-At: Subject: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10 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: Mon, 16 Mar 2015 12:25:39 -0000 QWxsLA0KDQpIYXZpbmcgYmVlbiBhd2F5IGZyb20gVVJOIG1hdHRlcnMgZm9yIGEgd2hpbGUsIEkg ZmluYWxseSBnb3QgYXJvdW5kIHRvIHJlYWRpbmcgZHJhZnQtaWV0Zi11cm5iaXMtcmZjMjE0MWJp cy11cm4tMTAuIEEgZ29vZCBwaWVjZSBvZiB3b3JrLCB0aGFuayB5b3UsIFBldGVyIGFuZCBKb2hu IQ0KDQpJIGhhdmUgYSBmZXcgcXVlc3Rpb25zL2NvbW1lbnRzOg0KDQoxKSDCpzMgVVJOIHN5bnRh eDogSSBoYXZlIHNvbWUgaXNzdWVzIHdpdGggdGhlIHVzZSBvZiBwLWNvbXBvbmVudCB2cy4gcGVy Y2VudC1lbmNvZGluZyBvZiAiLyIuIElmIEkgY3JlYXRlIGEgKHN1Yi0pbmFtZXNwYWNlIGZvciBE T0kgKHVybjpleGFtcGxlOmRvaSkgYW5kIHdhbnQgdG8gY3JlYXRlIGFuIGlkZW50aWZpZXIgZm9y IHRoZSBET0kgIjEwLjEwMDcvMTA5MjkxNzlfNjUiLCBJIGNvdWxkIGNob29zZSBiZXR3ZWVuICgx KSAidXJuOmV4YW1wbGU6ZG9pOjEwLjEwMDcvMTA5MjkxNzlfNjUiIGFuZCAoMikgInVybjpleGFt cGxlOmRvaToxMC4xMDA3JTJGMTA5MjkxNzlfNjUiLiBJbiB0aGUgc3ludGF4IGRlZmluZWQgYnkg MjE0MWJpcywgdGhlIGZpcnN0IG9uZSB1c2VzIE5TUyArIHAtY29tcG9uZW50LCB0aGUgc2Vjb25k IG9uZSBwdXRzIHRoZSBjb21wbGV0ZSBET0kgaW4gdGhlIE5TUy4gVGhpcyBpcyBwb3RlbnRpYWxs eSBjb25mdXNpbmcgZm9yIGNvbnN1bWVycywgc2luY2Ugwqc1IHNheXMgdGhhdCANCltbDQpbdXJu LWF3YXJlXSBhcHBsaWNhdGlvbnMgbWlnaHQgc3VwcG9ydCBkaXNwbGF5IG9mIFVSTnMgaW4gYSBt b3JlIGh1bWFuLWZyaWVuZGx5DQogZm9ybSBhbmQgbWlnaHQgdXNlIGEgY2hhcmFjdGVyIHNldCB0 aGF0IGluY2x1ZGVzIGNoYXJhY3RlcnMgdGhhdCBhcmUNCiBub3QgcGVybWl0dGVkIGluIFVSTiBz eW50YXggYXMgZGVmaW5lZCBpbiB0aGlzIHNwZWNpZmljYXRpb24gKGUuZy4sDQogd2hlbiBkaXNw bGF5aW5nIFVSTnMgdG8gaHVtYW5zLCBzdWNoIGFwcGxpY2F0aW9ucyBtaWdodCByZXBsYWNlDQog cGVyY2VudC1lbmNvZGVkIHN0cmluZ3Mgd2l0aCBjaGFyYWN0ZXJzIGZyb20gYW4gZXh0ZW5kZWQg Y2hhcmFjdGVyDQogcmVwZXJ0b2lyZSBbLi4uXSkuDQpdXQ0KDQpUaGF0IG1lYW5zIHRoYXQgaWYg SSBjaG9vc2Ugb3B0aW9uICgyKSAocHV0dGluZyB0aGUgY29tcGxldGUgRE9JIGludG8gdGhlIE5T UyB1c2luZyBwZXJjZW50LWVuY29kaW5nKSwgYSBjb25mb3JtaW5nIHVybi1hd2FyZSBhcHBsaWNh dGlvbiBNVVNUIHNob3cgInVybjpleGFtcGxlOmRvaToxMC4xMDA3JTJGMTA5MjkxNzlfNjUiIGFu ZCBNQVkgc2hvdyAidXJuOmV4YW1wbGU6ZG9pOjEwLjEwMDcvMTA5MjkxNzlfNjUiLiBUaGlzIGlz IGxpa2VseSB0byBiZSBfdmVyeV8gY29uZnVzaW5nIHRvIHNvbWUgdXNlcnMgbm90IGF3YXJlIG9m IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHR3by4NCg0KSSBzdWdnZXN0IHRoYXQgdGhlIHAt Y29tcG9uZW50IGlzIGluY29ycG9yYXRlZCBpbnRvIHRoZSBOU1M7IHRoaXMgaXMgbW9yZSBpbnR1 aXRpdmUuDQoNCjIpIENSRUY5Og0KSSBhZ3JlZSB3aXRoIFRlZCB0aGF0ICIgLi4uaW5kaXZpZHVh bCBVUkkgY29udGV4dHM7IiBpcyBiZXR0ZXIsIHNpbmNlIHRoZSB1cm4gbmFtZXNwYWNlIGRlc2Ny aXB0aW9uIGNhbm5vdCBhbnRpY2lwYXRlIGFsbCBwbGFjZXMgd2hlcmUgVVJJcyBjYW4gYmUgdXNl ZCBpbiB0aGUgZnV0dXJlLg0KDQozKSBDUkVGMTA6DQpJIGZlZWwgdGhhdCB0aGVyZSBpcyBhIHBp ZWNlIG1pc3NpbmcgaW4gdGhlIGZvbGxvd2luZyB0ZXh0Og0KW1sNClsuLi5dIG11c3QgdHJlYXQg dGhlIFVSSSBhcyBvcGFxdWUgdW5sZXNzIHRoZSBzY2hlbWUgYW5kIGl0cw0KIHJlcXVpcmVtZW50 cyBhcmUgcmVjb2duaXplZC4gVGhlIFVSTiByZXNvbHZlciBjYW4gZWl0aGVyIGJlIGFuDQogZXh0 ZXJuYWwgcmVzb2x2ZXIgdGhhdCB0aGUgVVJJIHJlc29sdmVyIGtub3dzIG9mIFsuLi5dLg0KXV0N Cg0KTXkgc3VnZ2VzdGlvbjoNCltbDQpbLi4uXSBtdXN0IHRyZWF0IHRoZSBVUkkgYXMgb3BhcXVl IHVubGVzcyB0aGUgc2NoZW1lIGFuZCBpdHMNCiByZXF1aXJlbWVudHMgYXJlIHJlY29nbml6ZWQu IElmIHRoZSBVUkkgcmVzb2x2ZXIgZXh0cmFjdHMgYSBVUkkNCnNjaGVtZSBvZiAidXJuIiwgaXQg Y2FuIGNob29zZSB0byByZXNvbHZlIHRoZSB1cm4gYnkgaXRzZWxmICh0aGUgVVJJDQpyZXNvbHZl ciBiZWluZyBhbHNvIHRoZSBVUk4gcmVzb2x2ZXIpIG9yIHRvIHBhc3MgdGhlIHVybiB0bw0KYW4g ZXh0ZXJuYWwgcmVzb2x2ZXIgdGhhdCB0aGUgVVJJIHJlc29sdmVyIGtub3dzIG9mIFsuLi5dLg0K XV0NCg0KVGhlIGN1cnJlbnQgdGV4dCB0aGVuIGdvZXMgb24gd2l0aA0KW1sNCk5vdGUgdGhhdCB0 aGlzDQogcmVxdWlyZW1lbnQgTUFZIGltcG9zZSBjb25zdHJhaW50cyBvbiB0aGUgY29udGV4dHMg aW4gd2hpY2ggVVJOcyBhcmUNCiBhcHByb3ByaWF0ZWx5IHVzZWQ7IHNlZSB0aGUgcHJldmlvdXMg c2VjdGlvbi4NCl1dDQoNCklzIGl0IGNvcnJlY3QgdGhhdCBNQVkgaXMgY2FwaXRhbGlzZWQgbWFr aW5nIGl0IFJGQyAyMTE5IGxhbmd1YWdlPw0KDQo0KSBDUkVGMTINClRoaXMgZG9lcyBvcGVuIGEg bmV3IGNhbiBvZiB3b3Jtcy4gRG8gd2UgbmVlZCB0byBhZGQgc29tZSB0ZXh0IHRoYXQgb3JnYW5p c2F0aW9ucyBvcGVyYXRpbmcgcmVzb2x1dGlvbiBzZXJ2aWNlcyBuZWVkIHRvIGVuc3VyZSB0aGF0 IHRoZSAobWV0YS0pZGF0YSB0aGV5IHJlc29sdmUgdG8gaXMgYWNjdXJhdGU/IE9uIHRoZSBvdGhl ciBoYW5kLCB3ZSBjb3VsZCBhbHNvIGVtcGhhc2lzZSB0aGF0IHVybiBhc3NpZ25tZW50IGlzIGFi b3V0IGlkZW50aWZpY2F0aW9uIGFuZCB0aGF0IGFueSByZXRyaWV2YWJsZSBtZXRhZGF0YSBpcyBv bmx5IHRoZXJlIHRvIGhlbHAgaWRlbnRpZnkgdGhhdCBJJ3ZlIGZvdW5kIHRoZSByaWdodCBlbnRp dHkuLi4gDQoNCjUpIE5JRCBzeW50YXgNClRoZSBsaXN0IGl0ZW1zIDQuIGFuZCA1LiBnaXZlIHRo ZSBleGFtcGxlcyAiYWEtIiBhbmQgInhuLS0iIHdoZXJlICJhYSIgb3IgInhuIiBjYW4gYmUgYW55 IHR3byBjaGFyYWN0ZXJzLiBJcyB0aGVyZSBhIHJlYXNvbiB0aGF0IDUuIHVzZXMgInhuIiBhbmQg bm90ICJhYSI/DQpUaGUgdGV4dCBhdCB0aGUgZW5kIG9mIHRoZSBzZWN0aW9uICgiQWxsIHR3byAt bGV0dGVyIHN0cmluZ3MgWy4uLl0gYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Iikg Y291bGQvc2hvdWxkIGJlIG1vdmVkIHRvIGxpc3QgaXRlbSA0IHNpbmNlIGl0IGRlYWxzIHdpdGgg dGhlIHR3by1sZXR0ZXIgc3RyaW5ncy4NCg0KNikgQ1JFRjE0DQpXZSBzaG91bGQga2VlcCBjb21w bGV0ZWx5IG91dCBvZiB0cmFkZW1hcmsgcHJvY2VkdXJlcy4gTmFtZXNwYWNlIHJlZ2lzdHJhbnRz IG11c3QgZW5zdXJlIHRoYXQgdGhleSBkbyBub3QgaW5mcmluZ2Ugb24gdHJhZGVtYXJrcyAoYSBy ZXF1aXJlbWVudCBmb3IgdGhlIHJlZ2lzdHJhdGlvbiB0ZW1wbGF0ZT8pLg0KUmVnYXJkaW5nIElT TyAzMTY2LTEgYWxwaGEtMyBjb2RlcyBpdCB1bmZvcnR1bmF0ZWx5IGlzIHRvbyBsYXRlIHRvIHBy b2hpYml0IHRocmVlLWxldHRlciBOSURzIGFuZCBzaW5jZSB0aGUgb2YgdGhvc2UgY29kZXMgaXMg bm90IGNsb3NlZCAob3IgaXMgaXQ/KSwgd2UgY2FuIG9ubHkgc2F5IHRoYXQgaXQgaXMgbm90IGFs bG93ZWQgdG8gcmVnaXN0ZXIgYSBOSUQgdGhhdCBpcyBlcXVpdmFsZW50IHRvIHN1Y2ggYSBjb2Rl Lg0KDQo3KSDCpzcuMSBTeW50YXgNCkxpc3QgaXRlbSA3IHNheXMgdGhhdCAicnVsZXMgW2ZvciBk ZXRlcm1pbmluZyBlcXVpdmFsZW5jZV0gb3VnaHQgdG8gYWx3YXlzIGhhdmUgdGhlIGVmZmVjdCBv ZiBlbGltaW5hdGluZyBmYWxzZSBuZWdhdGl2ZXMgWy4uLl0iLiBJcyB0aGF0IGdvb2QgZW5vdWdo IG9yIGlzIHRoZXJlIGFueXRoaW5nIG9wcG9zaW5nIHVzIHNheWluZyB0aGF0ICJbdGhvc2VdIHJ1 bGVzIE1VU1QgYWx3YXlzIGhhdmUgdGhlIGVmZmVjdCBvZiBlbGltaW5hdGluZyBmYWxzZSBuZWdh dGl2ZXMgYW5kIE1VU1QgTk9UIHByb2R1Y2UgYW55IGZhbHNlIHBvc2l0aXZlcyBbLi4uXSI/DQpB bHNvIEkgY2Fubm90IGZpbmQgYSByZWFzb24gZm9yIHRoZSBtZW50aW9uIG9mIGRvdWJsZS0gdnMu IHNpbmdsZS1xdW90ZXM7IGNhbiBhbnlvbmUgZ2l2ZSBhbiBleGFtcGxlIHdoZXJlIHN1Y2ggYSBy dWxlIHdvdWxkIGJlIGhlbHBmdWw/DQoNCkJlc3QgcmVnYXJkcywNCg0KTGFycw0KDQoqKiogTGVz ZW4uIEjDtnJlbi4gV2lzc2VuLiBEZXV0c2NoZSBOYXRpb25hbGJpYmxpb3RoZWsgKioqIA0KLS0g DQpEci4gTGFycyBHLiBTdmVuc3Nvbg0KRGV1dHNjaGUgTmF0aW9uYWxiaWJsaW90aGVrDQpJbmZv cm1hdGlvbnNpbmZyYXN0cnVrdHVyIHVuZCBCZXN0YW5kZXJoYWx0dW5nDQpBZGlja2VzYWxsZWUg MQ0KRC02MDMyMiBGcmFua2Z1cnQgYW0gTWFpbg0KVGVsZWZvbjogKzQ5LTY5LTE1MjUtMTc1Mg0K VGVsZWZheDogKzQ5LTY5LTE1MjUtMTc5OQ0KbWFpbHRvOmwuc3ZlbnNzb25AZG5iLmRlIA0KaHR0 cDovL3d3dy5kbmIuZGUNCg0KDQo= From nobody Mon Mar 16 13:31:49 2015 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 778A61A90DE for ; Mon, 16 Mar 2015 13:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 cBzc3Nuy2Aqy for ; Mon, 16 Mar 2015 13:31:46 -0700 (PDT) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5998F1A90C5 for ; Mon, 16 Mar 2015 13:31:45 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so181929595iec.2 for ; Mon, 16 Mar 2015 13:31:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fhoHUkHHmUzrm6rchN7BRsf539U4r+phLDLTlwFm/FI=; b=LLhcWWjkI3b151jXWhXvGpJiPJbq5aw9s6WpjP6RPacNeo2RjNQ7SafptRJXAz8xyp nMeydpTA5hYrDJ4O9vNhG07UDOfDt1DJo7CAxzniBCabHh/F1+ytUuIAsVWseWGMj4Wt tYcAC/VSlhEOfosPouCgOvKrgPcdD7/RGHBuhrN7mQvyV3hnwtjF8vXSyQ6SglttYPQN HeMtEZoYaJyjQTYmtbaSUVb2pLPdEY631E2oJeoQPqmB/h/vpQoa3F6eKv7ro63X7JfL strlmk99JFJfeo8f3RRVQSSItcOPz1pSsyz3bEVTsIdFFgry/pF07PgFvNUUdBPtWbAM SMGQ== X-Gm-Message-State: ALoCoQnDqRRnmN2JZf6aLlD2qCG8eDAOqGz3kvuNV+c49mCJpb9idfBuiAAV/C5qbBk5Sjed7VC0 X-Received: by 10.43.110.136 with SMTP id ek8mr10021371icc.87.1426537904803; Mon, 16 Mar 2015 13:31:44 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id h15sm7352324ioh.27.2015.03.16.13.31.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2015 13:31:43 -0700 (PDT) Message-ID: <55073DAF.4080009@andyet.net> Date: Mon, 16 Mar 2015 14:31:43 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Juha Hakala , urn@ietf.org References: <5500F8F9.1010001@andyet.net> <5502C445.6030409@helsinki.fi> In-Reply-To: <5502C445.6030409@helsinki.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] multiple URNs for the same resource (CREF11) 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: Mon, 16 Mar 2015 20:31:47 -0000 On 3/13/15 5:04 AM, Juha Hakala wrote: > Hello, > > The most common reason for a single resource having more than one > identifier is the overlap in the scopes of identifier systems. > > For instance, a book can have both ISBN and ISSN if the book has been > published in monograph series (and the series has an ISSN). Also, > multivolume books like The Lord of the Rings have one ISBN for the > entire work, and in addition each volume has its own ISBN. Yes, that is a good example, too. > Note that the > results of resolving these identifiers will differ: in the former > example ISSN would typically resolve to metadata about the monograph > series, and in the latter example ISBN of the entire work will retrieve > e.g. metadata about all volumes. > > If we need to give an example of identifier overlap, I prefer using > urn:issn and urn:isbn instead of RFC 5031 -based one since ISBN and ISSN > are better known and more widely used than the identifier system defined > in RFC 5031. I see no harm in giving more than one example, although I agree with you about the commonality of ISBNISSN vs. RFC 5031 identifiers. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Mar 16 19:36:31 2015 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 6BB7A1ACC87 for ; Mon, 16 Mar 2015 19:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.601 X-Spam-Level: X-Spam-Status: No, score=-4.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, 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 SCuEFqcCKLMn for ; Mon, 16 Mar 2015 19:36:26 -0700 (PDT) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4350A1A1EF9 for ; Mon, 16 Mar 2015 19:36:26 -0700 (PDT) Received: by igcqo1 with SMTP id qo1so61157640igc.0 for ; Mon, 16 Mar 2015 19:36:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+ktPnB/j7p+UIkccCqZwtWwYGHPaPJ94vXzf4t9bo28=; b=hdAutII7kk96HGRx25Gl7rwsjv0SjaIdDqh3OPPLP07oFiutPjcSkUyM/bgis+TrkT mEdXL37jGOqYX768Wh9Dkvyrw0C38+E9/FAnFFjYD8gwggMNCo23tLcbTUDm6OCQwk3E 9mxrJIVu7qGWgF4gmQafDoPa6wXfc0DnjtZQGqoxVVj/ZEAz+MKnkr1RuB2c9YYRvSg+ +IoN6isseBwsEQspjlaX0MwAbCA2qHFax/y3yuNI07dzISdw2ufRbZXI/amjmrc/y8xi F5Fbf9Rj3r/0zQDBiM2tNLO3blQNSz1O0vPha/HesfbPJZawdEEYMV454KqBqqud/56t FgXA== X-Gm-Message-State: ALoCoQkar8+MdxOvWK2zicM/84dIXlgOfMpqtOOLTzJ7MXsi3RwXfz8RZCB4iIlWFVa4qpiasmod X-Received: by 10.50.147.99 with SMTP id tj3mr114907821igb.41.1426559785721; Mon, 16 Mar 2015 19:36:25 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id g195sm7882360iog.24.2015.03.16.19.36.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2015 19:36:24 -0700 (PDT) Message-ID: <55079325.1010300@andyet.net> Date: Mon, 16 Mar 2015 20:36:21 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Svensson, Lars" , "urn@ietf.org" References: <24637769D123E644A105A0AF0E1F92EFFAC84913@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFFAC84913@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10 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: Tue, 17 Mar 2015 02:36:29 -0000 Lars, thank you for taking the time to review the document and to provide feedback. Please find my comments inline. On 3/16/15 6:25 AM, Svensson, Lars wrote: > All, > > Having been away from URN matters for a while, I finally got around > to reading draft-ietf-urnbis-rfc2141bis-urn-10. A good piece of work, > thank you, Peter and John! > > I have a few questions/comments: > > 1) §3 URN syntax: I have some issues with the use of p-component vs. > percent-encoding of "/". Although I don't claim to fully understand the DOI numbering system (with regard to URNs, Section 2.6.3 of the DOI Handbook is especially confusing to me because it implies that in a URN the slash could be replaced by a colon), let's take your example at face value. > If I create a (sub-)namespace for DOI > (urn:example:doi) and want to create an identifier for the DOI > "10.1007/10929179_65", I could choose between (1) > "urn:example:doi:10.1007/10929179_65" and (2) > "urn:example:doi:10.1007%2F10929179_65". I'm curious to hear your reasoning about why we would use a p-component to represent the identifier (DOI suffix). I don't think it's wrong, but I think it would helpful to explain your reasoning on the list. Further: are there alternative representations? For example, might it make sense to represent the complete DOI (prefix and suffix) as a p-component? Such as: urn:example:doi/10.1007/10929179_65 > In the syntax defined by > 2141bis, the first one uses NSS + p-component, the second one puts > the complete DOI in the NSS. As far as I understand things, putting the complete DOI in the p-component makes the most sense (option 3). > This is potentially confusing for > consumers, since §5 says that [[ [urn-aware] applications might > support display of URNs in a more human-friendly form and might use a > character set that includes characters that are not permitted in URN > syntax as defined in this specification (e.g., when displaying URNs > to humans, such applications might replace percent-encoded strings > with characters from an extended character repertoire [...]). ]] I agree that using option 1 or option 2 is potentially confusing. > That means that if I choose option (2) (putting the complete DOI into > the NSS using percent-encoding), a conforming urn-aware application > MUST show "urn:example:doi:10.1007%2F10929179_65" and MAY show > "urn:example:doi:10.1007/10929179_65". This is likely to be _very_ > confusing to some users not aware of the difference between the two. > > I suggest that the p-component is incorporated into the NSS; this is > more intuitive. Either that or don't split an identifier (e.g., a DOI name) across the NSS/p-component boundary. > 2) CREF9: I agree with Ted that " ...individual URI contexts;" is > better, since the urn namespace description cannot anticipate all > places where URIs can be used in the future. Agreed. > 3) CREF10: I feel that there is a piece missing in the following > text: [[ [...] must treat the URI as opaque unless the scheme and > its requirements are recognized. The URN resolver can either be an > external resolver that the URI resolver knows of [...]. ]] You didn't quote the complete text: In part because of the separation of semantics from syntax [I-D.ietf-urnbis-semantics-clarif], generic URI processors must pay special attention to the parsing and analysis rules of RFC 3986 and, in particular, must treat the URI as opaque unless the scheme and its requirements are recognized. The URN resolver can either be an external resolver that the URI resolver knows of, or it can be functionality built into the URI resolver. > My suggestion: [[ [...] must treat the URI as opaque unless the > scheme and its requirements are recognized. If the URI resolver > extracts a URI scheme of "urn", it can choose to resolve the urn by > itself (the URI resolver being also the URN resolver) or to pass the > urn to an external resolver that the URI resolver knows of [...]. ]] Thanks for the proposal. I'll look more closely at the URI resolver issue tomorrow. > The current text then goes on with [[ Note that this requirement MAY > impose constraints on the contexts in which URNs are appropriately > used; see the previous section. ]] > > Is it correct that MAY is capitalised making it RFC 2119 language? I'd prefer "might". > 4) CREF12 This does open a new can of worms. Do we need to add some > text that organisations operating resolution services need to ensure > that the (meta-)data they resolve to is accurate? On the other hand, > we could also emphasise that urn assignment is about identification > and that any retrievable metadata is only there to help identify that > I've found the right entity... See my separate note on the topic: http://www.ietf.org/mail-archive/web/urn/current/msg02802.html Here is possible text: 3. Commitment to not reassigning existing names and to allowing old names to continue to be valid (e.g., if the assignee of a name is no longer a member or customer of the assigning organization, if various information about the assignee or named entity happen to change, or even if the assignee or the named entity itself is no longer in existence; in all these cases, the name is still valid). With regard to URN resolution [RFC2276], this does not mean that there needs to be resolution of such names, only that the names will not resolve to false or stale information. > 5) NID syntax The list items 4. and 5. give the examples "aa-" and > "xn--" where "aa" or "xn" can be any two characters. Is there a > reason that 5. uses "xn" and not "aa"? The text at the end of the > section ("All two -letter strings [...] beyond the scope of this > document") could/should be moved to list item 4 since it deals with > the two-letter strings. These cases are slightly distinct so I would prefer to mention them in separate items. > 6) CREF14 We should keep completely out of trademark procedures. Agreed. > Namespace registrants must ensure that they do not infringe on > trademarks (a requirement for the registration template?). I'm not quite sure what you're suggesting here, since you just said that we should keep out of trademark issues and now you seem to be saying that perhaps the expert reviewers need to keep trademarks in mind. > Regarding > ISO 3166-1 alpha-3 codes it unfortunately is too late to prohibit > three-letter NIDs and since the of those codes is not closed (or is > it?), we can only say that it is not allowed to register a NID that > is equivalent to such a code. I think we could say something like this: 6. It MUST NOT start with a string that is the same as a three- letter country code in accordance with the ISO 3166-1 standard [ISO.3166-1.2006], or any similar code that could be considered deceptive or confusing. > 7) §7.1 Syntax List item 7 says that "rules [for determining > equivalence] ought to always have the effect of eliminating false > negatives [...]". Is that good enough or is there anything opposing > us saying that "[those] rules MUST always have the effect of > eliminating false negatives and MUST NOT produce any false positives > [...]"? Although I don't think that a MUST from RFC 2119 makes much of a difference here, I'm not actively opposed to it. > Also I cannot find a reason for the mention of double- vs. > single-quotes; can anyone give an example where such a rule would be > helpful? Well, in HTML href='foo' and href="foo" are the same. However, I don't have an example from URNs. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Mar 17 06:16:31 2015 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 2E81C1A0470 for ; Tue, 17 Mar 2015 06:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.55 X-Spam-Level: X-Spam-Status: No, score=-8.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] 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 zF2O2It5_zxJ for ; Tue, 17 Mar 2015 06:16:19 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 190031A066C for ; Tue, 17 Mar 2015 06:16:18 -0700 (PDT) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 942B7934EE; Tue, 17 Mar 2015 14:16:17 +0100 (CET) X-AuditID: 0a453fe7-f79b36d0000032b6-1f-55082921924b Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id 51.73.12982.12928055; Tue, 17 Mar 2015 14:16:17 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Tue, 17 Mar 2015 14:16:17 +0100 From: "Svensson, Lars" To: Peter Saint-Andre - &yet , "urn@ietf.org" Thread-Topic: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10 Thread-Index: AdBf5EXxmQCfXUbTSausW6Ov9qCjfgAbn+CAABcUiFA= Date: Tue, 17 Mar 2015 13:16:16 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFFAC85A6E@dnbf-ex1.AD.DDB.DE> References: <24637769D123E644A105A0AF0E1F92EFFAC84913@dnbf-ex1.AD.DDB.DE> <55079325.1010300@andyet.net> In-Reply-To: <55079325.1010300@andyet.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.163] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12TW0gUYRTH+2bGnXHbz8bx9rlp6EKZQprdEKkUK9K0qy5IJDXbjrtbq24z u6L5ormRqEiZUumDQkqglKJRmYaxWpCVSg+9ZEVpd7opZRktzbcXXXs78zvn/z//w8cwJPeS VjOmQqsgFvJmjUJJKXek/FgTHcto1765EJE08nqYTGqs/EakEumjE0/p9La238Q+4qBys14w m4oFMWHrEaWxtvU0ZakqLhm/PE2XA7tUDfwZxG5ALR3PSXcdisZfdCmqgZLh2CGABr/cI90f NwGyT56jqwHNKNg49NWI54PZPej+x0kK10FsGrpSaSfdfBtyTp8i3HUyqp25AHBNsSvRndo3 NK4hm4F6yz+5tBxrQi3Ndte8v+zurLyowDVgI1F395jLk2TDUM/bWT93Tha1DYx5MoegD5NO D49CnYOz8i5Gno9FXbcT3NJo1FDzyrM2ED24NEWdBSFNPq5NC4omH0WTj6IVUB0gQCowJMbz +ni9XhevF3qA+yXe3QJ1T7Y7AMsAjQpSIq3l/PhiqbTAAfYyhCYE9kYxWi5AV6QvNfKS8bBo MwuSJhg+jJExnMc6m/m4ZgV8vN5Py4XNU8kmWUxHTUU26bBNNDsAYkhZWshiqZ4vPSmIRW5D B1jOUJoweK6/IodjDbxVOC4IFkH0dnMZRoPgHN4ZKAoGoSTfZLZ627KuCHdY344rUDQs2yAH Uvs2/s9EMP4OkMWo5GC/XDdJFr5AMhk83kGQxVTlpS7fSLgF+4Z64WLPEZCtDoOfXZHwhNFW OJ9VHQoPYekynwa2VEfBtiqFlgv34YtdP4IM+YmC4M7VOI78Py1k5OB+DJd6oCtiBNyN94R4 2P9eWfLbBkP7GQU+2MpbfQ/mcBCVl3oORhiGeuFiO3U5QKOzzX/u5uWcyEztbWjY3WFJz7x2 g0+e1qkH69V1qu/HnL+6UsKturnm0fay+lV56zKqlH0xPycGNpU5P6iuBm/ML/4mZKMjmTMJ icT3zkfP6Pa9nQVdaQf6ys+TI3EpEzNfRg3DnUO9jdQS0j5u/Xv9c25E3ZR/DU1Mva/o36Wh JCOfGEeKEv8PapDTGXIEAAA= Archived-At: Subject: Re: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10 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: Tue, 17 Mar 2015 13:16:26 -0000 RGVhciBQZXRlciwNCg0KT24gVHVlc2RheSwgTWFyY2ggMTcsIDIwMTUgMzozNiBBTSwgUGV0ZXIg U2FpbnQtQW5kcmUgd3JvdGU6DQogDQo+IExhcnMsIHRoYW5rIHlvdSBmb3IgdGFraW5nIHRoZSB0 aW1lIHRvIHJldmlldyB0aGUgZG9jdW1lbnQgYW5kIHRvDQo+IHByb3ZpZGUgZmVlZGJhY2suIFBs ZWFzZSBmaW5kIG15IGNvbW1lbnRzIGlubGluZS4NCj4gDQo+IE9uIDMvMTYvMTUgNjoyNSBBTSwg U3ZlbnNzb24sIExhcnMgd3JvdGU6DQo+ID4gQWxsLA0KPiA+DQo+ID4gSGF2aW5nIGJlZW4gYXdh eSBmcm9tIFVSTiBtYXR0ZXJzIGZvciBhIHdoaWxlLCBJIGZpbmFsbHkgZ290IGFyb3VuZA0KPiA+ IHRvIHJlYWRpbmcgZHJhZnQtaWV0Zi11cm5iaXMtcmZjMjE0MWJpcy11cm4tMTAuIEEgZ29vZCBw aWVjZSBvZiB3b3JrLA0KPiA+IHRoYW5rIHlvdSwgUGV0ZXIgYW5kIEpvaG4hDQo+ID4NCj4gPiBJ IGhhdmUgYSBmZXcgcXVlc3Rpb25zL2NvbW1lbnRzOg0KPiA+DQo+ID4gMSkgwqczIFVSTiBzeW50 YXg6IEkgaGF2ZSBzb21lIGlzc3VlcyB3aXRoIHRoZSB1c2Ugb2YgcC1jb21wb25lbnQgdnMuDQo+ ID4gcGVyY2VudC1lbmNvZGluZyBvZiAiLyIuDQo+IA0KPiBBbHRob3VnaCBJIGRvbid0IGNsYWlt IHRvIGZ1bGx5IHVuZGVyc3RhbmQgdGhlIERPSSBudW1iZXJpbmcgc3lzdGVtDQo+ICh3aXRoIHJl Z2FyZCB0byBVUk5zLCBTZWN0aW9uIDIuNi4zIG9mIHRoZSBET0kgSGFuZGJvb2sgaXMgZXNwZWNp YWxseQ0KPiBjb25mdXNpbmcgdG8gbWUgYmVjYXVzZSBpdCBpbXBsaWVzIHRoYXQgaW4gYSBVUk4g dGhlIHNsYXNoIGNvdWxkIGJlDQo+IHJlcGxhY2VkIGJ5IGEgY29sb24pLCBsZXQncyB0YWtlIHlv dXIgZXhhbXBsZSBhdCBmYWNlIHZhbHVlLg0KPiANCj4gPiBJZiBJIGNyZWF0ZSBhIChzdWItKW5h bWVzcGFjZSBmb3IgRE9JDQo+ID4gKHVybjpleGFtcGxlOmRvaSkgYW5kIHdhbnQgdG8gY3JlYXRl IGFuIGlkZW50aWZpZXIgZm9yIHRoZSBET0kNCj4gPiAiMTAuMTAwNy8xMDkyOTE3OV82NSIsIEkg Y291bGQgY2hvb3NlIGJldHdlZW4gKDEpDQo+ID4gInVybjpleGFtcGxlOmRvaToxMC4xMDA3LzEw OTI5MTc5XzY1IiBhbmQgKDIpDQo+ID4gInVybjpleGFtcGxlOmRvaToxMC4xMDA3JTJGMTA5Mjkx NzlfNjUiLg0KPiANCj4gSSdtIGN1cmlvdXMgdG8gaGVhciB5b3VyIHJlYXNvbmluZyBhYm91dCB3 aHkgd2Ugd291bGQgdXNlIGEgcC1jb21wb25lbnQNCj4gdG8gcmVwcmVzZW50IHRoZSBpZGVudGlm aWVyIChET0kgc3VmZml4KS4gSSBkb24ndCB0aGluayBpdCdzIHdyb25nLCBidXQNCj4gSSB0aGlu ayBpdCB3b3VsZCBoZWxwZnVsIHRvIGV4cGxhaW4geW91ciByZWFzb25pbmcgb24gdGhlIGxpc3Qu DQoNCkkgY2hvb3NlIHRvIHVzZSBhIHAtY29tcG9uZW50IGJlY2F1c2UgSSBndWVzcyB0aGF0IG1v c3QgKG5vbi10ZWNobmljYWwpIHVzZXJzIHdpbGwgc2ltcGx5IGNvcHkgdGhlIERPSSBmcm9tIHRo ZSBzb21ld2hlcmUsIHB1dCBhICh1cm4tYmFzZWQpIHByZWZpeCBpbiBmcm9udCBvZiBpdCBhbmQg dGhpbmsgdGhleSBhcmUgZG9uZS4gSS4gZS4gZ2l2ZW4gImRvaToxMC4xMDA3LzEwOTI5MTc5XzY1 IiBhbmQgdGhlaXIga25vd2xlZGdlIHRoYXQgdGhlcmUgaXMgYSB1cm4gbmFtZXNwYWNlICJ1cm46 ZXhhbXBsZTpkb2kiIHRoZXkgd2lsbCBjcmVhdGUgInVybjpleGFtcGxlOmRvaToxMC4xMDA3LzEw OTI5MTc5XzY1IiBieSBzaW1wbGUgc3RyaW5nIGNvbmNhdGVuYXRpb24uIEl0IHdpbGwgcmVxdWly ZSBhIHN1YnN0YW50aWFsIGFtb3VudCBvZiBlZHVjYXRpb24gdG8gbWFrZSBwZW9wbGUgc3Vic3Rp dHV0ZSB0aGUgc2xhc2ggaW4gdGhlIERPSSBmb3IgYSBjb2xvbi4NCg0KPiBGdXJ0aGVyOiBhcmUg dGhlcmUgYWx0ZXJuYXRpdmUgcmVwcmVzZW50YXRpb25zPyBGb3IgZXhhbXBsZSwgbWlnaHQgaXQN Cj4gbWFrZSBzZW5zZSB0byByZXByZXNlbnQgdGhlIGNvbXBsZXRlIERPSSAocHJlZml4IGFuZCBz dWZmaXgpIGFzIGENCj4gcC1jb21wb25lbnQ/IFN1Y2ggYXM6DQo+IA0KPiB1cm46ZXhhbXBsZTpk b2kvMTAuMTAwNy8xMDkyOTE3OV82NQ0KDQpZZXMsIGZvciBET0lzIHRoYXQgd291bGQgYmUgYSBt dWNoIGJldHRlciBpZGVhLg0KDQpNeSBwb2ludCBpcywgaG93ZXZlciwgdGhhdCB3aGVuIG5vbi10 ZWNobmljYWwgdXNlcnMgY3JlYXRlIHVybnMganVzdCBhZGRpbmcgYSBwcmVmaXggdG8gYW4gZXhp c3RpbmcgaWRlbnRpZmllciwgd2Ugc2hvdWxkIG1ha2Ugc3VyZSB0aGF0IHRoaW5ncyB3b3JrIGFz IGludHVpdGl2ZWx5IGFzIHBvc3NpYmxlLiBTaW5jZSAyMTQxYmlzIGFsbG93cyB0aGUgIi8iIGlu IHRoZSBzeW50YXgsIGEgZ2VuZXJpYyBVUk4gcGFyc2VyIHdpbGwgYWNjZXB0ICIgdXJuOmV4YW1w bGU6ZG9pOjEwLjEwMDcvMTA5MjkxNzlfNjUiIChvciBhbnkgb3RoZXIgVVJOIGNyZWF0ZWQgZnJv bSBhbiBpZGVudGlmaWVyIHdpdGggYSAiLyIgaW4gaXQpIGFzIGEgdmFsaWQgVVJOLiBJIHJlYWxp c2UgdGhhdCB0aGlzIG1pZ2h0IGFsc28gYmUgdGhlIGNhc2UgZm9yIG90aGVyIGNoYXJhY3RlcnMg d2l0aCBzcGVjaWFsIG1lYW5pbmcsIGJ1dCBJIGFsc28gdGhpbmsgdGhhdCB0aGUgIi8iIGNoYXJh Y3RlciB3aWxsIGJlIG1vcmUgY29uZnVzaW5nIHRvIGltcGxlbWVudGVycyBhbmQgdXNlcnMgc2lu Y2UgaXQncyBtb3JlIGNvbW1vbmx5IHVzZWQgYXMgYSBkZWxpbWl0ZXIgdGhhbiBlLiBnLiAiQCIu DQoNCj4gPiBJbiB0aGUgc3ludGF4IGRlZmluZWQgYnkNCj4gPiAyMTQxYmlzLCB0aGUgZmlyc3Qg b25lIHVzZXMgTlNTICsgcC1jb21wb25lbnQsIHRoZSBzZWNvbmQgb25lIHB1dHMNCj4gPiB0aGUg Y29tcGxldGUgRE9JIGluIHRoZSBOU1MuDQo+IA0KPiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kIHRo aW5ncywgcHV0dGluZyB0aGUgY29tcGxldGUgRE9JIGluIHRoZQ0KPiBwLWNvbXBvbmVudCBtYWtl cyB0aGUgbW9zdCBzZW5zZSAob3B0aW9uIDMpLg0KDQpBZ3JlZWQuDQoNCj4gPiBUaGlzIGlzIHBv dGVudGlhbGx5IGNvbmZ1c2luZyBmb3INCj4gPiBjb25zdW1lcnMsIHNpbmNlIMKnNSBzYXlzIHRo YXQgW1sgW3Vybi1hd2FyZV0gYXBwbGljYXRpb25zIG1pZ2h0DQo+ID4gc3VwcG9ydCBkaXNwbGF5 IG9mIFVSTnMgaW4gYSBtb3JlIGh1bWFuLWZyaWVuZGx5IGZvcm0gYW5kIG1pZ2h0IHVzZSBhDQo+ ID4gY2hhcmFjdGVyIHNldCB0aGF0IGluY2x1ZGVzIGNoYXJhY3RlcnMgdGhhdCBhcmUgbm90IHBl cm1pdHRlZCBpbiBVUk4NCj4gPiBzeW50YXggYXMgZGVmaW5lZCBpbiB0aGlzIHNwZWNpZmljYXRp b24gKGUuZy4sIHdoZW4gZGlzcGxheWluZyBVUk5zDQo+ID4gdG8gaHVtYW5zLCBzdWNoIGFwcGxp Y2F0aW9ucyBtaWdodCByZXBsYWNlIHBlcmNlbnQtZW5jb2RlZCBzdHJpbmdzDQo+ID4gd2l0aCBj aGFyYWN0ZXJzIGZyb20gYW4gZXh0ZW5kZWQgY2hhcmFjdGVyIHJlcGVydG9pcmUgWy4uLl0pLiBd XQ0KPiANCj4gSSBhZ3JlZSB0aGF0IHVzaW5nIG9wdGlvbiAxIG9yIG9wdGlvbiAyIGlzIHBvdGVu dGlhbGx5IGNvbmZ1c2luZy4NCj4gDQo+ID4gVGhhdCBtZWFucyB0aGF0IGlmIEkgY2hvb3NlIG9w dGlvbiAoMikgKHB1dHRpbmcgdGhlIGNvbXBsZXRlIERPSSBpbnRvDQo+ID4gdGhlIE5TUyB1c2lu ZyBwZXJjZW50LWVuY29kaW5nKSwgYSBjb25mb3JtaW5nIHVybi1hd2FyZSBhcHBsaWNhdGlvbg0K PiA+IE1VU1Qgc2hvdyAidXJuOmV4YW1wbGU6ZG9pOjEwLjEwMDclMkYxMDkyOTE3OV82NSIgYW5k IE1BWSBzaG93DQo+ID4gInVybjpleGFtcGxlOmRvaToxMC4xMDA3LzEwOTI5MTc5XzY1Ii4gVGhp cyBpcyBsaWtlbHkgdG8gYmUgX3ZlcnlfDQo+ID4gY29uZnVzaW5nIHRvIHNvbWUgdXNlcnMgbm90 IGF3YXJlIG9mIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHR3by4NCj4gPg0KPiA+IEkgc3Vn Z2VzdCB0aGF0IHRoZSBwLWNvbXBvbmVudCBpcyBpbmNvcnBvcmF0ZWQgaW50byB0aGUgTlNTOyB0 aGlzIGlzDQo+ID4gbW9yZSBpbnR1aXRpdmUuDQo+IA0KPiBFaXRoZXIgdGhhdCBvciBkb24ndCBz cGxpdCBhbiBpZGVudGlmaWVyIChlLmcuLCBhIERPSSBuYW1lKSBhY3Jvc3MgdGhlDQo+IE5TUy9w LWNvbXBvbmVudCBib3VuZGFyeS4NCg0KUmlnaHQuIE5vbmV0aGVsZXNzIEknZCBhcmd1ZSB0aGF0 IGl0J3MgbW9yZSBpbnR1aXRpdmUgdGhhdCB0aGUgcC1jb21wb25lbnQgaXMgaW5jb3Jwb3JhdGVk IGludG8gdGhlIE5TUy4gSWYgd2Ugc2F5IHRoYXQgYSBVUk4gY29uc2lzdHMgb2Ygc2NoZW1hICsg TklEICsgTlNTICsgcC1jb21wb25lbnQgKCsgcS1jb21wb25lbnQgKyBmLWNvbXBvbmVudCksIHRo aXMgKGF0IGxlYXN0IHRvIG1lKSBpbmRpY2F0ZXMgdGhhdCB0aGUgcC1jb21wb25lbnQgaXMgbm90 IGEgcmVhbCBwYXJ0IG9mIHRoZSBuYW1lLCBidXQgc29tZXRoaW5nIHRoYXQgaXMgYWRkZWQgdG8g aXQuIFdoZW4gZGV0ZXJtaW5pbmcgVVJOIGVxdWFsaXR5LCBob3dldmVyLCB0aGUgcC1jb21wb25l bnQgaXMgY29uc2lkZXJlZC4gSXQgd291bGQgYmUgbW9yZSBjb25zaXN0ZW50IHRvIHNheSB0d28g VVJOcyBhcmUgZXF1aXZhbGVudCBpZmYgYWxsIHBhcnRzIG9mIHRoZSBuYW1lIGFyZSBvY3RldC1i eS1vY3RldCBlcXVhbCAobW9kdWxvIG5vcm1hbGlzYXRpb24pLiBVUk4gY29tcG9uZW50cyB0aGF0 IGFyZSBub3QgcGFydCBvZiB0aGUgbmFtZSAoaS4gZS4gcS1jb21wb25lbnQgYW5kIGYtY29tcG9u ZW50KSBhcmUgbm90IGNvbnNpZGVyZWQgd2hlbiBkZXRlcm1pbmluZyBlcXVhbGl0eS4NCiANCj4g PiAyKSBDUkVGOTogSSBhZ3JlZSB3aXRoIFRlZCB0aGF0ICIgLi4uaW5kaXZpZHVhbCBVUkkgY29u dGV4dHM7IiBpcw0KPiA+IGJldHRlciwgc2luY2UgdGhlIHVybiBuYW1lc3BhY2UgZGVzY3JpcHRp b24gY2Fubm90IGFudGljaXBhdGUgYWxsDQo+ID4gcGxhY2VzIHdoZXJlIFVSSXMgY2FuIGJlIHVz ZWQgaW4gdGhlIGZ1dHVyZS4NCj4gDQo+IEFncmVlZC4NCj4gDQo+ID4gMykgQ1JFRjEwOiBJIGZl ZWwgdGhhdCB0aGVyZSBpcyBhIHBpZWNlIG1pc3NpbmcgaW4gdGhlIGZvbGxvd2luZw0KPiA+IHRl eHQ6IFtbIFsuLi5dIG11c3QgdHJlYXQgdGhlIFVSSSBhcyBvcGFxdWUgdW5sZXNzIHRoZSBzY2hl bWUgYW5kDQo+ID4gaXRzIHJlcXVpcmVtZW50cyBhcmUgcmVjb2duaXplZC4gVGhlIFVSTiByZXNv bHZlciBjYW4gZWl0aGVyIGJlIGFuDQo+ID4gZXh0ZXJuYWwgcmVzb2x2ZXIgdGhhdCB0aGUgVVJJ IHJlc29sdmVyIGtub3dzIG9mIFsuLi5dLiBdXQ0KPiANCj4gWW91IGRpZG4ndCBxdW90ZSB0aGUg Y29tcGxldGUgdGV4dDoNCj4gDQo+ICAgICBJbiBwYXJ0IGJlY2F1c2Ugb2YgdGhlIHNlcGFyYXRp b24gb2Ygc2VtYW50aWNzIGZyb20gc3ludGF4DQo+ICAgICBbSS1ELmlldGYtdXJuYmlzLXNlbWFu dGljcy1jbGFyaWZdLCBnZW5lcmljIFVSSSBwcm9jZXNzb3JzIG11c3QgcGF5DQo+ICAgICBzcGVj aWFsIGF0dGVudGlvbiB0byB0aGUgcGFyc2luZyBhbmQgYW5hbHlzaXMgcnVsZXMgb2YgUkZDIDM5 ODYgYW5kLA0KPiAgICAgaW4gcGFydGljdWxhciwgbXVzdCB0cmVhdCB0aGUgVVJJIGFzIG9wYXF1 ZSB1bmxlc3MgdGhlIHNjaGVtZSBhbmQgaXRzDQo+ICAgICByZXF1aXJlbWVudHMgYXJlIHJlY29n bml6ZWQuICBUaGUgVVJOIHJlc29sdmVyIGNhbiBlaXRoZXIgYmUgYW4NCj4gICAgIGV4dGVybmFs IHJlc29sdmVyIHRoYXQgdGhlIFVSSSByZXNvbHZlciBrbm93cyBvZiwgb3IgaXQgY2FuIGJlDQo+ ICAgICBmdW5jdGlvbmFsaXR5IGJ1aWx0IGludG8gdGhlIFVSSSByZXNvbHZlci4NCj4gDQo+ID4g TXkgc3VnZ2VzdGlvbjogW1sgWy4uLl0gbXVzdCB0cmVhdCB0aGUgVVJJIGFzIG9wYXF1ZSB1bmxl c3MgdGhlDQo+ID4gc2NoZW1lIGFuZCBpdHMgcmVxdWlyZW1lbnRzIGFyZSByZWNvZ25pemVkLiBJ ZiB0aGUgVVJJIHJlc29sdmVyDQo+ID4gZXh0cmFjdHMgYSBVUkkgc2NoZW1lIG9mICJ1cm4iLCBp dCBjYW4gY2hvb3NlIHRvIHJlc29sdmUgdGhlIHVybiBieQ0KPiA+IGl0c2VsZiAodGhlIFVSSSBy ZXNvbHZlciBiZWluZyBhbHNvIHRoZSBVUk4gcmVzb2x2ZXIpIG9yIHRvIHBhc3MgdGhlDQo+ID4g dXJuIHRvIGFuIGV4dGVybmFsIHJlc29sdmVyIHRoYXQgdGhlIFVSSSByZXNvbHZlciBrbm93cyBv ZiBbLi4uXS4gXV0NCj4gDQo+IFRoYW5rcyBmb3IgdGhlIHByb3Bvc2FsLiBJJ2xsIGxvb2sgbW9y ZSBjbG9zZWx5IGF0IHRoZSBVUkkgcmVzb2x2ZXINCj4gaXNzdWUgdG9tb3Jyb3cuDQo+IA0KPiA+ IFRoZSBjdXJyZW50IHRleHQgdGhlbiBnb2VzIG9uIHdpdGggW1sgTm90ZSB0aGF0IHRoaXMgcmVx dWlyZW1lbnQgTUFZDQo+ID4gaW1wb3NlIGNvbnN0cmFpbnRzIG9uIHRoZSBjb250ZXh0cyBpbiB3 aGljaCBVUk5zIGFyZSBhcHByb3ByaWF0ZWx5DQo+ID4gdXNlZDsgc2VlIHRoZSBwcmV2aW91cyBz ZWN0aW9uLiBdXQ0KPiA+DQo+ID4gSXMgaXQgY29ycmVjdCB0aGF0IE1BWSBpcyBjYXBpdGFsaXNl ZCBtYWtpbmcgaXQgUkZDIDIxMTkgbGFuZ3VhZ2U/DQo+IA0KPiBJJ2QgcHJlZmVyICJtaWdodCIu DQoNCldvcmtzIGZvciBtZS4NCg0KPiA+IDQpIENSRUYxMiBUaGlzIGRvZXMgb3BlbiBhIG5ldyBj YW4gb2Ygd29ybXMuIERvIHdlIG5lZWQgdG8gYWRkIHNvbWUNCj4gPiB0ZXh0IHRoYXQgb3JnYW5p c2F0aW9ucyBvcGVyYXRpbmcgcmVzb2x1dGlvbiBzZXJ2aWNlcyBuZWVkIHRvIGVuc3VyZQ0KPiA+ IHRoYXQgdGhlIChtZXRhLSlkYXRhIHRoZXkgcmVzb2x2ZSB0byBpcyBhY2N1cmF0ZT8gT24gdGhl IG90aGVyIGhhbmQsDQo+ID4gd2UgY291bGQgYWxzbyBlbXBoYXNpc2UgdGhhdCB1cm4gYXNzaWdu bWVudCBpcyBhYm91dCBpZGVudGlmaWNhdGlvbg0KPiA+IGFuZCB0aGF0IGFueSByZXRyaWV2YWJs ZSBtZXRhZGF0YSBpcyBvbmx5IHRoZXJlIHRvIGhlbHAgaWRlbnRpZnkgdGhhdA0KPiA+IEkndmUg Zm91bmQgdGhlIHJpZ2h0IGVudGl0eS4uLg0KPiANCj4gU2VlIG15IHNlcGFyYXRlIG5vdGUgb24g dGhlIHRvcGljOg0KPiANCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Vy bi9jdXJyZW50L21zZzAyODAyLmh0bWwNCj4gDQo+IEhlcmUgaXMgcG9zc2libGUgdGV4dDoNCj4g DQo+ICAgICAzLiAgQ29tbWl0bWVudCB0byBub3QgcmVhc3NpZ25pbmcgZXhpc3RpbmcgbmFtZXMg YW5kIHRvIGFsbG93aW5nIG9sZA0KPiAgICAgICAgIG5hbWVzIHRvIGNvbnRpbnVlIHRvIGJlIHZh bGlkIChlLmcuLCBpZiB0aGUgYXNzaWduZWUgb2YgYSBuYW1lIGlzDQo+ICAgICAgICAgbm8gbG9u Z2VyIGEgbWVtYmVyIG9yIGN1c3RvbWVyIG9mIHRoZSBhc3NpZ25pbmcgb3JnYW5pemF0aW9uLCBp Zg0KPiAgICAgICAgIHZhcmlvdXMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGFzc2lnbmVlIG9yIG5h bWVkIGVudGl0eSBoYXBwZW4gdG8NCj4gICAgICAgICBjaGFuZ2UsIG9yIGV2ZW4gaWYgdGhlIGFz c2lnbmVlIG9yIHRoZSBuYW1lZCBlbnRpdHkgaXRzZWxmIGlzIG5vDQo+ICAgICAgICAgbG9uZ2Vy IGluIGV4aXN0ZW5jZTsgaW4gYWxsIHRoZXNlIGNhc2VzLCB0aGUgbmFtZSBpcyBzdGlsbA0KPiAg ICAgICAgIHZhbGlkKS4gIFdpdGggcmVnYXJkIHRvIFVSTiByZXNvbHV0aW9uIFtSRkMyMjc2XSwg dGhpcyBkb2VzIG5vdA0KPiAgICAgICAgIG1lYW4gdGhhdCB0aGVyZSBuZWVkcyB0byBiZSByZXNv bHV0aW9uIG9mIHN1Y2ggbmFtZXMsIG9ubHkgdGhhdA0KPiAgICAgICAgIHRoZSBuYW1lcyB3aWxs IG5vdCByZXNvbHZlIHRvIGZhbHNlIG9yIHN0YWxlIGluZm9ybWF0aW9uLg0KDQpZZXMsIEkndmUg cmVhZCB0aGUgZGlzY3Vzc2lvbi4gSSBzaGFsbCB0aGluayBhYm91dCBpdCBhbmQgY29tZSBiYWNr IHRvIHlvdS4NCg0KPiA+IDUpIE5JRCBzeW50YXggVGhlIGxpc3QgaXRlbXMgNC4gYW5kIDUuIGdp dmUgdGhlIGV4YW1wbGVzICJhYS0iIGFuZA0KPiA+ICJ4bi0tIiB3aGVyZSAiYWEiIG9yICJ4biIg Y2FuIGJlIGFueSB0d28gY2hhcmFjdGVycy4gSXMgdGhlcmUgYQ0KPiA+IHJlYXNvbiB0aGF0IDUu IHVzZXMgInhuIiBhbmQgbm90ICJhYSI/IFRoZSB0ZXh0IGF0IHRoZSBlbmQgb2YgdGhlDQo+ID4g c2VjdGlvbiAoIkFsbCB0d28gLWxldHRlciBzdHJpbmdzIFsuLi5dIGJleW9uZCB0aGUgc2NvcGUg b2YgdGhpcw0KPiA+IGRvY3VtZW50IikgY291bGQvc2hvdWxkIGJlIG1vdmVkIHRvIGxpc3QgaXRl bSA0IHNpbmNlIGl0IGRlYWxzIHdpdGgNCj4gPiB0aGUgdHdvLWxldHRlciBzdHJpbmdzLg0KPiAN Cj4gVGhlc2UgY2FzZXMgYXJlIHNsaWdodGx5IGRpc3RpbmN0IHNvIEkgd291bGQgcHJlZmVyIHRv IG1lbnRpb24gdGhlbSBpbg0KPiBzZXBhcmF0ZSBpdGVtcy4NCg0KT0suIEJ1dCBpcyB0aGVyZSBh IHJlYXNvbiB0aGF0IGl0ZW0gNCBnaXZlcyB0d28tbGV0dGVyIGNvZGVzIGFzICJhYSIgYW5kIGl0 ZW0gNSBhcyAieG4iPw0KDQo+ID4gNikgQ1JFRjE0IFdlIHNob3VsZCBrZWVwIGNvbXBsZXRlbHkg b3V0IG9mIHRyYWRlbWFyayBwcm9jZWR1cmVzLg0KPiANCj4gQWdyZWVkLg0KPiANCj4gPiBOYW1l c3BhY2UgcmVnaXN0cmFudHMgbXVzdCBlbnN1cmUgdGhhdCB0aGV5IGRvIG5vdCBpbmZyaW5nZSBv bg0KPiA+IHRyYWRlbWFya3MgKGEgcmVxdWlyZW1lbnQgZm9yIHRoZSByZWdpc3RyYXRpb24gdGVt cGxhdGU/KS4NCj4gDQo+IEknbSBub3QgcXVpdGUgc3VyZSB3aGF0IHlvdSdyZSBzdWdnZXN0aW5n IGhlcmUsIHNpbmNlIHlvdSBqdXN0IHNhaWQgdGhhdA0KPiB3ZSBzaG91bGQga2VlcCBvdXQgb2Yg dHJhZGVtYXJrIGlzc3VlcyBhbmQgbm93IHlvdSBzZWVtIHRvIGJlIHNheWluZw0KPiB0aGF0IHBl cmhhcHMgdGhlIGV4cGVydCByZXZpZXdlcnMgbmVlZCB0byBrZWVwIHRyYWRlbWFya3MgaW4gbWlu ZC4NCg0KU29ycnksIEkgc2VlIHRoYXQgbXkgcHJvcG9zYWwgd2FzIHVuY2xlYXIuIFdoYXQgSSdt IHN1Z2dlc3RpbmcgaXMgdGhhdCB0aGUgcmVnaXN0cmF0aW9uIHRlbXBsYXRlIGNvbnRhaW5zIHRl eHQgdGhhdCBzYXlzIHRoYXQgdGhlIHJlZ2lzdHJhbnRzIGFyZSByZXNwb25zaWJsZSB0aGF0IHRo ZWlyIHByb3Bvc2VkIE5JRCBkb2VzIG5vdCBpbmZyaW5nZSBvbiB0cmFkZW1hcmtzIChhbmQgdGhh dCB0aGUgZXhwZXJ0cyBvciBJRVRGIG9yIElBTkEgYXNzdW1lIG5vIGxpYWJpbGl0eSkuIFRoZSBw b2ludCBpcyB0aGF0IHRoZSBleHBlcnRzIG5lZWQgX25vdF8ga2VlcCB0cmFkZW1hcmtzIGluIG1p bmQuDQoNCj4gPiBSZWdhcmRpbmcNCj4gPiBJU08gMzE2Ni0xIGFscGhhLTMgY29kZXMgaXQgdW5m b3J0dW5hdGVseSBpcyB0b28gbGF0ZSB0byBwcm9oaWJpdA0KPiA+IHRocmVlLWxldHRlciBOSURz IGFuZCBzaW5jZSB0aGUgb2YgdGhvc2UgY29kZXMgaXMgbm90IGNsb3NlZCAob3IgaXMNCj4gPiBp dD8pLCB3ZSBjYW4gb25seSBzYXkgdGhhdCBpdCBpcyBub3QgYWxsb3dlZCB0byByZWdpc3RlciBh IE5JRCB0aGF0DQo+ID4gaXMgZXF1aXZhbGVudCB0byBzdWNoIGEgY29kZS4NCj4gDQo+IEkgdGhp bmsgd2UgY291bGQgc2F5IHNvbWV0aGluZyBsaWtlIHRoaXM6DQo+IA0KPiAgICAgNi4gIEl0IE1V U1QgTk9UIHN0YXJ0IHdpdGggYSBzdHJpbmcgdGhhdCBpcyB0aGUgc2FtZSBhcyBhIHRocmVlLQ0K PiAgICAgICAgIGxldHRlciBjb3VudHJ5IGNvZGUgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBJU08g MzE2Ni0xIHN0YW5kYXJkDQo+ICAgICAgICAgW0lTTy4zMTY2LTEuMjAwNl0sIG9yIGFueSBzaW1p bGFyIGNvZGUgdGhhdCBjb3VsZCBiZSBjb25zaWRlcmVkDQo+ICAgICAgICAgZGVjZXB0aXZlIG9y IGNvbmZ1c2luZy4NCg0KT0sgd2l0aCBtZS4NCg0KPiA+IDcpIMKnNy4xIFN5bnRheCBMaXN0IGl0 ZW0gNyBzYXlzIHRoYXQgInJ1bGVzIFtmb3IgZGV0ZXJtaW5pbmcNCj4gPiBlcXVpdmFsZW5jZV0g b3VnaHQgdG8gYWx3YXlzIGhhdmUgdGhlIGVmZmVjdCBvZiBlbGltaW5hdGluZyBmYWxzZQ0KPiA+ IG5lZ2F0aXZlcyBbLi4uXSIuIElzIHRoYXQgZ29vZCBlbm91Z2ggb3IgaXMgdGhlcmUgYW55dGhp bmcgb3Bwb3NpbmcNCj4gPiB1cyBzYXlpbmcgdGhhdCAiW3Rob3NlXSBydWxlcyBNVVNUIGFsd2F5 cyBoYXZlIHRoZSBlZmZlY3Qgb2YNCj4gPiBlbGltaW5hdGluZyBmYWxzZSBuZWdhdGl2ZXMgYW5k IE1VU1QgTk9UIHByb2R1Y2UgYW55IGZhbHNlIHBvc2l0aXZlcw0KPiA+IFsuLi5dIj8NCj4gDQo+ IEFsdGhvdWdoIEkgZG9uJ3QgdGhpbmsgdGhhdCBhIE1VU1QgZnJvbSBSRkMgMjExOSBtYWtlcyBt dWNoIG9mIGENCj4gZGlmZmVyZW5jZSBoZXJlLCBJJ20gbm90IGFjdGl2ZWx5IG9wcG9zZWQgdG8g aXQuDQoNCk9LLCB0aGUgTVVTVCBpbiB0aGUgZmlyc3QgcGFydCBpcyBub3QgcmVhbGx5IG5lY2Vz c2FyeSwgYnV0IHdoYXQgYWJvdXQgdGhlICJNVVNUIE5PVCBwcm9kdWNlIGFueSBmYWxzZSBwb3Np dGl2ZXMiPw0KDQo+ID4gQWxzbyBJIGNhbm5vdCBmaW5kIGEgcmVhc29uIGZvciB0aGUgbWVudGlv biBvZiBkb3VibGUtIHZzLg0KPiA+IHNpbmdsZS1xdW90ZXM7IGNhbiBhbnlvbmUgZ2l2ZSBhbiBl eGFtcGxlIHdoZXJlIHN1Y2ggYSBydWxlIHdvdWxkIGJlDQo+ID4gaGVscGZ1bD8NCj4gDQo+IFdl bGwsIGluIEhUTUwgaHJlZj0nZm9vJyBhbmQgaHJlZj0iZm9vIiBhcmUgdGhlIHNhbWUuIEhvd2V2 ZXIsIEkgZG9uJ3QNCj4gaGF2ZSBhbiBleGFtcGxlIGZyb20gVVJOcy4NCg0KT0sNCg0KQmVzdCwN Cg0KTGFycw0KDQoqKiogTGVzZW4uIEjDtnJlbi4gV2lzc2VuLiBEZXV0c2NoZSBOYXRpb25hbGJp Ymxpb3RoZWsgKioqIA0KLS0gDQpEci4gTGFycyBHLiBTdmVuc3Nvbg0KRGV1dHNjaGUgTmF0aW9u YWxiaWJsaW90aGVrDQpJbmZvcm1hdGlvbnNpbmZyYXN0cnVrdHVyIHVuZCBCZXN0YW5kZXJoYWx0 dW5nDQpBZGlja2VzYWxsZWUgMQ0KRC02MDMyMiBGcmFua2Z1cnQgYW0gTWFpbg0KVGVsZWZvbjog KzQ5LTY5LTE1MjUtMTc1Mg0KVGVsZWZheDogKzQ5LTY5LTE1MjUtMTc5OQ0KbWFpbHRvOmwuc3Zl bnNzb25AZG5iLmRlIA0KaHR0cDovL3d3dy5kbmIuZGUNCg0KDQoNCg== From nobody Wed Mar 18 09:46:07 2015 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 BA82D1A1BF5 for ; Wed, 18 Mar 2015 09:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Oxk3aj4jG0XF for ; Wed, 18 Mar 2015 09:46:03 -0700 (PDT) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539181A86EB for ; Wed, 18 Mar 2015 09:46:03 -0700 (PDT) Received: by igcau2 with SMTP id au2so68073319igc.0 for ; Wed, 18 Mar 2015 09:46:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sYjjlq7n9MXY+z4VV/i3aXoJsTi0wJmVJ0Zgw78HgIs=; b=ccBTpUvAw/Wso0lkL6VjLXIOJye3h7+iwZzdcvCEz5DyqDQ1uGEhUIo96ANSbEp4mw f6coa3hcK/yhssc8zd9keBLjRvLOlG30gbVPj00jKD9YgJd5qWMPdn+T/jYD0Q6Gaj36 swGrw/wkndNde/hGQhtWOhwFnDPQue30NzDyzYDITNllh9OSkgGgeeQMeIKPbEO5TBjV 6zr3xcJu5VLitoQ27HCJ/lkqktrLZ3lLOxiL3+Q8sTI2SzTCQ1wt715C6Y1/0oLtR0/L sPaV/t1ruwZViYRBn9npJxudz0VJAah4Ld2Qe+rfjt3nHqSvA5BYr0tDFX7hAIqBvr3U 5wLA== X-Gm-Message-State: ALoCoQkltyhdsbP6YRr4NXBATFECxcHnmUJRT1jzkFqVtCSOap1ykOHGma0UOQQ5gPTZ+XwC3YR9 X-Received: by 10.107.134.219 with SMTP id q88mr85252007ioi.27.1426697162553; Wed, 18 Mar 2015 09:46:02 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id h19sm2046753igq.10.2015.03.18.09.45.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Mar 2015 09:45:59 -0700 (PDT) Message-ID: <5509ABC6.2040707@andyet.net> Date: Wed, 18 Mar 2015 10:45:58 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Svensson, Lars" , "urn@ietf.org" References: <24637769D123E644A105A0AF0E1F92EFFAC84913@dnbf-ex1.AD.DDB.DE> <55079325.1010300@andyet.net> <24637769D123E644A105A0AF0E1F92EFFAC85A6E@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFFAC85A6E@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10 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, 18 Mar 2015 16:46:05 -0000 On 3/17/15 7:16 AM, Svensson, Lars wrote: > Dear Peter, > > On Tuesday, March 17, 2015 3:36 AM, Peter Saint-Andre wrote: > >> Lars, thank you for taking the time to review the document and to >> provide feedback. Please find my comments inline. >> >> On 3/16/15 6:25 AM, Svensson, Lars wrote: >>> All, >>> >>> Having been away from URN matters for a while, I finally got >>> around to reading draft-ietf-urnbis-rfc2141bis-urn-10. A good >>> piece of work, thank you, Peter and John! >>> >>> I have a few questions/comments: >>> >>> 1) §3 URN syntax: I have some issues with the use of p-component >>> vs. percent-encoding of "/". >> >> Although I don't claim to fully understand the DOI numbering >> system (with regard to URNs, Section 2.6.3 of the DOI Handbook is >> especially confusing to me because it implies that in a URN the >> slash could be replaced by a colon), let's take your example at >> face value. >> >>> If I create a (sub-)namespace for DOI (urn:example:doi) and want >>> to create an identifier for the DOI "10.1007/10929179_65", I >>> could choose between (1) "urn:example:doi:10.1007/10929179_65" >>> and (2) "urn:example:doi:10.1007%2F10929179_65". >> >> I'm curious to hear your reasoning about why we would use a >> p-component to represent the identifier (DOI suffix). I don't think >> it's wrong, but I think it would helpful to explain your reasoning >> on the list. > > I choose to use a p-component because I guess that most > (non-technical) users will simply copy the DOI from the somewhere, > put a (urn-based) prefix in front of it and think they are done. But non-technical users aren't creating URNs. > I. > e. given "doi:10.1007/10929179_65" and their knowledge that there is > a urn namespace "urn:example:doi" But non-technical users don't know about URNs. > they will create > "urn:example:doi:10.1007/10929179_65" by simple string concatenation. > It will require a substantial amount of education to make people > substitute the slash in the DOI for a colon. I'd assume that the International DOI Foundation would create these URNs. (And remember this is just an example - we have no idea if the IDF has any plans to use URNs. But the same reasoning would apply to any similarly structured identifier system.) >> Further: are there alternative representations? For example, might >> it make sense to represent the complete DOI (prefix and suffix) as >> a p-component? Such as: >> >> urn:example:doi/10.1007/10929179_65 > > Yes, for DOIs that would be a much better idea. So, if the IDF registers a URN namespace, we'd encourage them to do the right thing regarding the p-component. > My point is, however, that when non-technical users create urns just > adding a prefix to an existing identifier, I question many assumptions in that part of your sentence. :-) > we should make sure that > things work as intuitively as possible. Since 2141bis allows the "/" > in the syntax, a generic URN parser will accept " > urn:example:doi:10.1007/10929179_65" (or any other URN created from > an identifier with a "/" in it) as a valid URN. I realise that this > might also be the case for other characters with special meaning, but > I also think that the "/" character will be more confusing to > implementers and users since it's more commonly used as a delimiter > than e. g. "@". If we're going to reuse URI syntax, then "/" is what we have as a delimiter between the authority and the p-component. Are you suggesting that we diverge from URI syntax? >>> In the syntax defined by 2141bis, the first one uses NSS + >>> p-component, the second one puts the complete DOI in the NSS. >> >> As far as I understand things, putting the complete DOI in the >> p-component makes the most sense (option 3). > > Agreed. > >>> This is potentially confusing for consumers, since §5 says that >>> [[ [urn-aware] applications might support display of URNs in a >>> more human-friendly form and might use a character set that >>> includes characters that are not permitted in URN syntax as >>> defined in this specification (e.g., when displaying URNs to >>> humans, such applications might replace percent-encoded strings >>> with characters from an extended character repertoire [...]). ]] >> >> I agree that using option 1 or option 2 is potentially confusing. >> >>> That means that if I choose option (2) (putting the complete DOI >>> into the NSS using percent-encoding), a conforming urn-aware >>> application MUST show "urn:example:doi:10.1007%2F10929179_65" and >>> MAY show "urn:example:doi:10.1007/10929179_65". This is likely to >>> be _very_ confusing to some users not aware of the difference >>> between the two. >>> >>> I suggest that the p-component is incorporated into the NSS; this >>> is more intuitive. >> >> Either that or don't split an identifier (e.g., a DOI name) across >> the NSS/p-component boundary. > > Right. Nonetheless I'd argue that it's more intuitive that the > p-component is incorporated into the NSS. If we say that a URN > consists of schema + NID + NSS + p-component (+ q-component + > f-component), this (at least to me) indicates that the p-component is > not a real part of the name, but something that is added to it. When > determining URN equality, however, the p-component is considered. It > would be more consistent to say two URNs are equivalent iff all parts > of the name are octet-by-octet equal (modulo normalisation). URN > components that are not part of the name (i. e. q-component and > f-component) are not considered when determining equality. The use of the p-component is up to the URN namespace. Again using the example of DOI numbers, the IDF has identifiers like "10.1007/10929179_65" and if they decided to define a URN namespace, they could place that existing identifier in the p-component. Although we are not following URI *semantics*, the description of the path component from RFC 3896 is not irrelevant: The path component contains data, usually organized in hierarchical form, that ... serves to identify a resource within the scope of the URI's scheme and naming authority (if any). As far as I understand it, a DOI number is hierarchical. It serves to identify a resource or entity or item of intellectual property. The naming authority for a urn:doi namespace would be the IDF. So if this namespace were defined, using a p-component for the DOI number would seem sensible. (Just because it wasn't done that way for ISBNs and ISSNs doesn't mean we couldn't do it for DOI numbers.) Again, this is all hypothetical with regard to DOI numbers because we don't know the IDF's intentions, but the same reasoning might apply to similar identifier systems. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Mar 18 10:00:41 2015 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 190F91A872A for ; Wed, 18 Mar 2015 10:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 IjEjn1sy9OhI for ; Wed, 18 Mar 2015 10:00:38 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 643CC1A86F5 for ; Wed, 18 Mar 2015 10:00:38 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YYHKd-000KTh-3v; Wed, 18 Mar 2015 13:00:35 -0400 Date: Wed, 18 Mar 2015 13:00:30 -0400 From: John C Klensin To: Peter Saint-Andre - &yet , "Svensson, Lars" , urn@ietf.org Message-ID: In-Reply-To: <5509ABC6.2040707@andyet.net> References: <24637769D123E644A105A0AF0E1F92EFFAC84913@dnbf-ex1.AD.DDB.DE> <55079325.1010300@andyet.net> <24637769D123E644A105A0AF0E1F92EFFAC85A6E@dnbf-ex1.AD.DDB.DE> <5509ABC6.2040707@andyet.net> 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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10 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, 18 Mar 2015 17:00:40 -0000 --On Wednesday, March 18, 2015 10:45 -0600 Peter Saint-Andre - &yet wrote: >... >> they will create >> "urn:example:doi:10.1007/10929179_65" by simple string >> concatenation. It will require a substantial amount of >> education to make people substitute the slash in the DOI for >> a colon. > > I'd assume that the International DOI Foundation would create > these URNs. > > (And remember this is just an example - we have no idea if the > IDF has any plans to use URNs. But the same reasoning would > apply to any similarly structured identifier system.) >... FWIW, my understanding is that the International DOI Foundation has lost interest in URNs and is instead looking at a separate URI scheme or use of HTTP ones, so that the example above would appear rather more like doi:10.1007/10929179_65 or http://doi.example.org/10.1007/10929179_65 The examples may still be useful to clarify our thinking, but, if this particular case is directly relevant to URNs, it would be useful to have some pointers to documents, etc. > Again, this is all hypothetical with regard to DOI numbers > because we don't know the IDF's intentions, but the same > reasoning might apply to similar identifier systems. Exactly. john From nobody Thu Mar 19 02:59:58 2015 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 E35D61A00FF for ; Thu, 19 Mar 2015 02:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ecMy23nkHk3q for ; Thu, 19 Mar 2015 02:59:55 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 422611A014C for ; Thu, 19 Mar 2015 02:59:54 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id t2J9xbTY017840; Thu, 19 Mar 2015 09:59:42 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t2J9xcap017385; Thu, 19 Mar 2015 09:59:38 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t2J9xbe4020410; Thu, 19 Mar 2015 09:59:37 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id t2J9xbWO020406; Thu, 19 Mar 2015 09:59:37 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Peter Saint-Andre - &yet References: <5500F0C3.6070807@andyet.net> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 19 Mar 2015 09:59:37 +0000 In-Reply-To: <5500F0C3.6070807@andyet.net> (Peter Saint-Andre's message of "Wed\, 11 Mar 2015 19\:49\:55 -0600") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] NSS syntax (CREFs 2,3,4) 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: Thu, 19 Mar 2015 09:59:58 -0000 Peter Saint-Andre - &yet writes: > In draft-ietf-urnbis-rfc2141bis-urn-10, we included a note about Ted > Hardie's proposed text change for the NSS syntax. > > OLD > ... > NEW > ... I prefer the new wording. It makes clear that URNs (as opposed to names in namespaces, which are out of scope for this document) have to conform to the URI syntax productions. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Thu Mar 19 04:05:00 2015 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 5EE611A897D for ; Thu, 19 Mar 2015 04:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 KXwAFvmVOMgW for ; Thu, 19 Mar 2015 04:04:57 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id BC5E01A8974 for ; Thu, 19 Mar 2015 04:04:56 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id t2JB4fXk002953 for ; Thu, 19 Mar 2015 11:04:46 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t2JB4eXU020596 for ; Thu, 19 Mar 2015 11:04:40 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t2JB4ev8022200 for ; Thu, 19 Mar 2015 11:04:40 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id t2JB4dw5022196; Thu, 19 Mar 2015 11:04:39 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: urn@ietf.org From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 19 Mar 2015 11:04:39 +0000 Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Subject: [urn] Case normalization (CREF 6) 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: Thu, 19 Mar 2015 11:04:59 -0000 I support the changes in section 4.1. I am agnostic about the p-component issue. Wrt https://github.com/MelindaShore/urnbis/issues/3 1) I agree with Melinda that the reference to 3986 6.2.2.1 is not really sufficient to explain what is actually _meant_ by "case normalization", so suggest that each of the three numbered items have a clause of the form ", by conversion to {upper,lower} case", as appropriate; 2) On the other hand, her concerns that suggest the whole vexed question of case normalization for Unicode is involved here are, in my view, mistaken. URIs, and hence URNs, are constrained to be ASCII, for which upper- and lower-casing _are_ well-defined. In this I disagree with what I _think_ Peter [1] is implying: I don't see any interaction here with the p-component question. p-components are no different from any other part of URNs: they have to be expressed in ASCII, including %-encoding as necessary. ht [1] http://www.ietf.org/mail-archive/web/urn/current/msg02797.html -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Thu Mar 19 04:15:04 2015 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 4372E1A8999 for ; Thu, 19 Mar 2015 04:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 DBG0V2nWQwvo for ; Thu, 19 Mar 2015 04:14:52 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1D39F1A897D for ; Thu, 19 Mar 2015 04:14:51 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id t2JBEphk009596; Thu, 19 Mar 2015 11:14:51 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t2JBEoBY021053; Thu, 19 Mar 2015 11:14:50 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t2JBEoxr022415; Thu, 19 Mar 2015 11:14:50 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id t2JBEoIk022411; Thu, 19 Mar 2015 11:14:50 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Peter Saint-Andre - &yet References: <5500F64F.8090508@andyet.net> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 19 Mar 2015 11:14:50 +0000 In-Reply-To: <5500F64F.8090508@andyet.net> (Peter Saint-Andre's message of "Wed\, 11 Mar 2015 20\:13\:35 -0600") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] URI contexts (CREF9) 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: Thu, 19 Mar 2015 11:14:54 -0000 Peter Saint-Andre - &yet writes: > Section 5 states: > > Because a URN is, syntactically, a URI under the "urn" scheme, in > theory a URN can be placed in any protocol slot that allows for a URI > (e.g., an XML namespace name [XML-NAMES]). However, this does not > imply that, semantically, it always makes sense in practice to place > a URN in a given URI protocol slot; in particular, because a URN > might not specify the location of a resource or even point indirectly > to one, it might not be appropriate to place a URN in a URI protocol > slot that points to a resource (examples include the 'href' and 'src' > attributes and the element in HTML, as well as the 'xml:base' > attribute in XML [XML-BASE]). Ultimately, specifications of where it > is appropriate to use URNs, or URNs created within particular URN > namespaces, are the responsibility of descriptions of individual URI > schemes and their expected uses; this specification cannot possibly > anticipate all of the relevant cases. > > Ted suggested "individual URI contexts" instead of "individual URI > schemes". (CREF9) I wholeheartedly agree, and I thought that I had > already made a similar change but I see that I had not. I disagree. What's a "URI context"? It's not defined, or even used earlier in the document. If it means "context of use", how can that make sense here? Suppose we adopted Ted's wording: the result would read: specifications of where it is appropriate to use URNs, or URNs created within particular URN namespaces, are the responsibility of descriptions of individual URI contexts. Who is now expected to provide such specifications? The HTML5 specification, when it talks about the 'href' attribute? Elsevier, in some document about authoring guidelines for journal landing pages? Surely the right place for guidelines about the use of urn:mynid:... is in the NID definition for 'mynid'. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Thu Mar 19 04:26:40 2015 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 76EA01A897D for ; Thu, 19 Mar 2015 04:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 0niylAaq8Ngk for ; Thu, 19 Mar 2015 04:26:35 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 86B941A883A for ; Thu, 19 Mar 2015 04:26:35 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id t2JBQX26018654; Thu, 19 Mar 2015 11:26:33 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t2JBQXHB021582; Thu, 19 Mar 2015 11:26:33 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t2JBQXaI022676; Thu, 19 Mar 2015 11:26:33 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id t2JBQXAv022672; Thu, 19 Mar 2015 11:26:33 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Peter Saint-Andre - &yet References: <5500F6F0.8090603@andyet.net> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 19 Mar 2015 11:26:33 +0000 In-Reply-To: <5500F6F0.8090603@andyet.net> (Peter Saint-Andre's message of "Wed\, 11 Mar 2015 20\:16\:16 -0600") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] constraining URI resolvers (CREF10) 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: Thu, 19 Mar 2015 11:26:38 -0000 Peter Saint-Andre - &yet writes: > Section 5 states: > > A resolver that conforms to the URI specification [RFC3986] will > extract a scheme of "urn" rather than a scheme value of "urn:". > > CREF10 proposes alternate text (because, as Henry Thompson points out, > we cannot constrain URI resolvers in general): Actually, what it proposes to replace is, if I read it correctly, is not the bit quoted above, but rather the next bit, i.e. A URN MUST be considered an opaque URI by URI resolvers and passed (with the "urn" scheme) to a URN resolver for resolution. > In part because of the separation of semantics from syntax > [I-D.ietf-urnbis-semantics-clarif], generic URI processors must pay > special attention to the parsing and analysis rules of RFC 3986 and, > in particular, must treat the URI as opaque unless the scheme and its > requirements are recognized. The URN resolver can either be an > external resolver that the URI resolver knows of, or it can be > functionality built into the URI resolver. Note that this > requirement MAY impose constraints on the contexts in which URNs are > appropriately used; see the previous section. > > This looks good to me. It's better, but there's now a disconnect here: generic URI processors must ... treat the URI as opaque unless the scheme and its requirements are recognized. The URN resolver can either ... Would something like this serve to bridge the gap: generic URI processors must ... treat the URI as opaque unless the scheme and its requirements are recognized, in which case they may be in a position to invoke scheme-appropriate processing, that is, a URN resolver. The URN resolver can either ... ? ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Thu Mar 19 04:52:00 2015 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 9D7D41A8987 for ; Thu, 19 Mar 2015 04:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] 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 M9iYRgV3aLJV for ; Thu, 19 Mar 2015 04:51:56 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 581D51A6F0B for ; Thu, 19 Mar 2015 04:51:56 -0700 (PDT) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 2571E8B4A5; Thu, 19 Mar 2015 12:51:55 +0100 (CET) X-AuditID: 0a453fe7-f79b36d0000032b6-8e-550ab85ae75f Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id 46.D9.12982.A58BA055; Thu, 19 Mar 2015 12:51:55 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Thu, 19 Mar 2015 12:51:54 +0100 From: "Svensson, Lars" To: "Henry S. Thompson" , Peter Saint-Andre - &yet Thread-Topic: [urn] constraining URI resolvers (CREF10) Thread-Index: AQHQYjeTZYtBg6MD9EWj127BlZQBM50jsXgg Date: Thu, 19 Mar 2015 11:51:53 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFFAC865DA@dnbf-ex1.AD.DDB.DE> References: <5500F6F0.8090603@andyet.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.163] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLsWRmVeSWpSXmKPExsXC5Wr/VTd6B1eowe3PLBZnbzYyWZx6dITZ YmrzByYHZo9zd66xeyxZ8pPJY9GTDawBzFFcNimpOZllqUX6dglcGa8f/WQrWMhfcXHXYtYG xnPcXYycHBICJhKLVy1ghrDFJC7cW8/WxcjFISRwmFHiz8n7LBDOdkaJVSseATnsHGwCWhLv M0DqRQQiJD50XGYHsZkFFCU23Z/CBGILC5hJfJhyjxmixlxiZ9NyoDgHkG0kcXCdGkiYRUBV 4v2cK+wgYV4BT4nu91EgYSGBEImz3UtZQWxOAVOJJY0TWUBsRgFZiQ0bzjNDbBKX2PTsOyvE xQISS/ach7peVOLl439QcQWJ1fu/M0LUG0i8PzcfqldbYtnC12A2r4CgxMmZT1gmMIrNQjJ2 FpKWWUhaZiFpWcDIsoqRrzg33VAvMUUvJSVJLyV1EyMkfp7vYOy75HKIUYCDUYmH18aNK1SI NbGsuDL3EKM/B5OSKC/XCqAQX1J+SmVGYnFGfFFpTmqxkgiv8HagMC9cOKk0J1tJjtfXmDNU SBwuWlxaXJCZnJlfWhxfWpRziFGCgxmo9XQZSGtKYmVValE+xMBDjNIcLErivBN3N4YICaQn lqRmp6YWpBbBZCM4OJQkeM1AdgoWpaanVqRl5pTApIH6tLYBZQSQZcAOUuRVATlIClkC3U1M HJyHGH04eIAOKwH7qbggMbc4Mx1qtjBvCshsHpgo2FxZXiWQuWIwQVQzTzEGS4nzmoMMEwCp yCjNg7tVSoxX0wSolR9JAmSklAJvQB1QgySSOKqprxg9gVEkzFsFMpcHmMsQbhTiLQC5kRsq CHaiDK8RyImiUDF0s3yAcSvC+68W7OGSxBJkDzPUgT0MFYV6+A9IqRhMENU4qQZG1dN+W3d/ CLh0xz5hY8i+H2v2vJph9XTp/5p0ZYmNJzQ7JsvKhnmEtSWolq8y/WTAXj5vfsdHD+f1nDHz G0+6vwzcx8dhvOT5XYW/M9iX9VnNnr5vkkg84wKjyb/2yEp+i4+4fGjNf4N01cAv967Z2HNt f7HoU8VHmwcHN8394pilIup4zC63QImlOCPRUIu5qDgRAGDXZSaIBAAA Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] constraining URI resolvers (CREF10) 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: Thu, 19 Mar 2015 11:51:58 -0000 On Thursday, March 19, 2015 12:27 PM, Henry wrote: > > Section 5 states: > > > > A resolver that conforms to the URI specification [RFC3986] will > > extract a scheme of "urn" rather than a scheme value of "urn:". > > > > CREF10 proposes alternate text (because, as Henry Thompson points out, > > we cannot constrain URI resolvers in general): >=20 > Actually, what it proposes to replace is, if I read it correctly, is > not the bit quoted above, but rather the next bit, i.e. >=20 > A URN MUST be considered an opaque URI by URI resolvers and passed > (with the "urn" scheme) to a URN resolver for > resolution. >=20 > > In part because of the separation of semantics from syntax > > [I-D.ietf-urnbis-semantics-clarif], generic URI processors must pay > > special attention to the parsing and analysis rules of RFC 3986 and, > > in particular, must treat the URI as opaque unless the scheme and it= s > > requirements are recognized. The URN resolver can either be an > > external resolver that the URI resolver knows of, or it can be > > functionality built into the URI resolver. Note that this > > requirement MAY impose constraints on the contexts in which URNs are > > appropriately used; see the previous section. > > > > This looks good to me. >=20 > It's better, but there's now a disconnect here: >=20 > generic URI processors must ... treat the URI as opaque unless the > scheme and its requirements are recognized. The URN resolver can > either ... >=20 > Would something like this serve to bridge the gap: >=20 > generic URI processors must ... treat the URI as opaque unless the > scheme and its requirements are recognized, in which case they may > be in a position to invoke scheme-appropriate processing, that is, > a URN resolver. The URN resolver can either ... >=20 > ? Looks good to me. Best, Lars=20 From nobody Thu Mar 19 05:50:54 2015 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 B3CB21A0065 for ; Thu, 19 Mar 2015 05:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 OoAhNAD-Eu53 for ; Thu, 19 Mar 2015 05:50:51 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 28FB61A008B for ; Thu, 19 Mar 2015 05:50:48 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id t2JCofq9022509; Thu, 19 Mar 2015 12:50:41 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t2JCohrC026192; Thu, 19 Mar 2015 12:50:43 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t2JCogb1025262; Thu, 19 Mar 2015 12:50:42 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id t2JCogSL025258; Thu, 19 Mar 2015 12:50:42 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Peter Saint-Andre - &yet References: <5500FD46.7070402@andyet.net> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 19 Mar 2015 12:50:42 +0000 In-Reply-To: <5500FD46.7070402@andyet.net> (Peter Saint-Andre's message of "Wed\, 11 Mar 2015 20\:43\:18 -0600") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] defining URN namespaces (CREF15) 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: Thu, 19 Mar 2015 12:50:53 -0000 Peter Saint-Andre - &yet writes: > Section 7 states: > > The material in this section is intended as guidance to both > designers of URN namespaces and (expert) reviewers of proposed URN > namespace registrations. More information for the latter appears in > Section 9. > > CREF15 poses a question for the WG: > > Henry would like to see a SHOULD requirement on the definitions > here. The WG needs to decide whether that is necessary and/or > desirable. > > Although I'm not a big fan of procedural SHOULDs and MUSTs, I have no > strong objections to using normative keywords here. Actually, that comment was about section _6_. Section 6, *URN Namespaces*, is in many ways the core of this specification. It basically amounts to guidance for reviewers of URN namespace registrations. Perhaps this should be made explicit. That is, what is presented here as a _definition_ of a namespace is actually a set of SHOULD requirements on a namespace definition. It's not quite the same as section 7, which is informal (and I'm happy with that) guidance for _authors_ of such definitions. I'm also not a 2119-or-die extremist, but some explicit statement of the essentially normative nature of section 6 would be a good idea, IMO. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Thu Mar 19 06:16:43 2015 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 F3CB01A89A6 for ; Thu, 19 Mar 2015 06:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 I7to6YoqcJud for ; Thu, 19 Mar 2015 06:16:39 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 58D621A8706 for ; Thu, 19 Mar 2015 06:16:38 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id t2JDGUnY009327; Thu, 19 Mar 2015 13:16:31 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t2JCcmGl025667; Thu, 19 Mar 2015 12:38:48 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t2JCclgs025078; Thu, 19 Mar 2015 12:38:47 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id t2JCckDN025074; Thu, 19 Mar 2015 12:38:46 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Peter Saint-Andre - &yet References: <5500FC11.1060109@andyet.net> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 19 Mar 2015 12:38:46 +0000 In-Reply-To: <5500FC11.1060109@andyet.net> (Peter Saint-Andre's message of "Wed\, 11 Mar 2015 20\:38\:09 -0600") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] continued validity of URNs (CREF12) 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: Thu, 19 Mar 2015 13:16:42 -0000 Peter Saint-Andre - &yet writes: > Section 6.1 states: > > 3. Commitment to not reassigning existing names and to allowing old > names to continue to be valid, even if the owners or assignees of > those names are no longer members or customers of that > organization. With regard to URN resolution [RFC2276], this does > not mean that there needs to be resolution of such names, only > that the names will not resolve to false or stale information. > > CREF12 poses a question for the WG about how we should handle this > question from Henry Thompson: > > "Really? If a piece of retrievable metadata for some URN is the > name and (postal) address of the publisher of whatever it > identifies, and they've gone out of business, that metadata is > necessarily stale, isn't it?" > > First, I'm not sure what we mean by "retrievable metadata for some > URN" here because I think it confuses the issue, which is about the > URNs themselves. > > Let's say that someone defines a urn:publisher namespace and that a > publisher "Leblanc Press" is identified by urn:publisher:24601. The > rule about not reassigning the URN doesn't have anything to do with > the address of Leblanc Press, the continued business operations of > Leblanc Press, or any other metadata associated with Leblanc > Press. All it says is "don't reassign urn:publisher:24601 to, say, > Madeleine Press". The URN always refers to Leblanc Press, even if that > "resource" has been out of business for 1000 years. > > If some clarifying text is in order here, let the authors know. I should have been more careful to make clear that my comment was about the second sentence, that is, the one about resolution. To continue with your example, suppose urn:publisher URNs have a resolver, and that resolver, when queried wrt urn:publisher:24601, supplies some form of information describing Leblanc Press, giving its address and company number, as of the last year of its existence. 500 years from now that information, although true (provided it is clearly date-constrained), is certainly stale. The minimum necessary to declare victory, in my view, is just to remove the final clause, i.e. so the sentence reads With regard to URN resolution [RFC2276], this does not mean that there needs to be resolution of such names. In my view requiring the human-interpretable content of HTTP messages to be true is way outside the remit of a protocol standard :-). ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Thu Mar 19 06:19:45 2015 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 854561A8A04 for ; Thu, 19 Mar 2015 06:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Nzixk5WKbAmy for ; Thu, 19 Mar 2015 06:19:42 -0700 (PDT) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE8B1A89FF for ; Thu, 19 Mar 2015 06:19:41 -0700 (PDT) Received: by iedm5 with SMTP id m5so1432320ied.3 for ; Thu, 19 Mar 2015 06:19:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2EZGGPLL3VTHf/zkzdsgh6I2Q3hz05bfq5goQ95QDEc=; b=BWlIYG9mokku116/+cPQsHwQdk2oRKRUDFPAQfRwEfU/34Kr+6nHww/rxu/LyAePas rgq5XrjCN4wBRXRLpNJrLyh360HnwyH0LQQ/knz6XqJHbOM1VFS2xH0YOyqD+MbfbEJ4 S/sChmdvW7oTjVvtt6ukyBZnHgvqkbzbvubyg3XzVWrXJ6Vut5bsGtUF+y0KZTgvkqq9 p0VAnu9Beq0bfg4yPoMZLAmONywmR197/1eTDxL6usMFUYedCi1fqvodIHS8jZHgQ0GG BuYB/VUbi4DUHo7PmXpXcAE0Sswt6sd6kPAhLnvVbXflb9/8gNTW3SkAGfhGNHXKFj4n qJBg== X-Gm-Message-State: ALoCoQkeRJp20wPUrGl4ASodcsW2jzHRQ+5si3JR0wEBWWISTUiQzXF/NriEji2PXy3fhomzb+7i X-Received: by 10.42.20.11 with SMTP id e11mr38984674icb.91.1426771181289; Thu, 19 Mar 2015 06:19:41 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id p143sm882299ioe.33.2015.03.19.06.19.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2015 06:19:39 -0700 (PDT) Message-ID: <550ACCEA.9040204@andyet.net> Date: Thu, 19 Mar 2015 07:19:38 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Henry S. Thompson" References: <5500F64F.8090508@andyet.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] URI contexts (CREF9) 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: Thu, 19 Mar 2015 13:19:43 -0000 On 3/19/15 5:14 AM, Henry S. Thompson wrote: > Peter Saint-Andre - &yet writes: > >> Section 5 states: >> >> Because a URN is, syntactically, a URI under the "urn" scheme, in >> theory a URN can be placed in any protocol slot that allows for a URI >> (e.g., an XML namespace name [XML-NAMES]). However, this does not >> imply that, semantically, it always makes sense in practice to place >> a URN in a given URI protocol slot; in particular, because a URN >> might not specify the location of a resource or even point indirectly >> to one, it might not be appropriate to place a URN in a URI protocol >> slot that points to a resource (examples include the 'href' and 'src' >> attributes and the element in HTML, as well as the 'xml:base' >> attribute in XML [XML-BASE]). Ultimately, specifications of where it >> is appropriate to use URNs, or URNs created within particular URN >> namespaces, are the responsibility of descriptions of individual URI >> schemes and their expected uses; this specification cannot possibly >> anticipate all of the relevant cases. >> >> Ted suggested "individual URI contexts" instead of "individual URI >> schemes". (CREF9) I wholeheartedly agree, and I thought that I had >> already made a similar change but I see that I had not. > > I disagree. What's a "URI context"? I would think of it as the equivalent of a "protocol slot" from IDNA2008 and PRECIS: a place where a URI can be used. > It's not defined, Yes, let's do that. > or even used > earlier in the document. Only by example in that paragraph. > If it means "context of use", how can that > make sense here? Suppose we adopted Ted's wording: the result would > read: > > specifications of where it is appropriate to use URNs, or URNs > created within particular URN namespaces, are the responsibility > of descriptions of individual URI contexts. > > Who is now expected to provide such specifications? The HTML5 > specification, when it talks about the 'href' attribute? Yes. > Elsevier, in > some document about authoring guidelines for journal landing pages? > Surely the right place for guidelines about the use of > urn:mynid:... is in the NID definition for 'mynid'. But this is true of all URNs and is not namespace-specific. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Mar 19 06:35:06 2015 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 DCD601A8A70 for ; Thu, 19 Mar 2015 06:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 KVh5fmxS-JXZ for ; Thu, 19 Mar 2015 06:35:03 -0700 (PDT) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D091A8A6A for ; Thu, 19 Mar 2015 06:35:03 -0700 (PDT) Received: by pdbop1 with SMTP id op1so76539447pdb.2 for ; Thu, 19 Mar 2015 06:35:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KiwUXB3PeoZj7fFBxboeOWdp4e0fxKQOdZQ/WMrjAP4=; b=eUz0qA5RxjGPMFZXAvffJyqXqDlKXvWBf9hmeA56KYz+5kORUXhz1PcMwKXY1gkrrr 4zhn9EPIl16G57pd/efwNPjHMcw4jwFxRqNDMie3LDhjgecZsyimBP7qhlERWrYIg0bT 5uTtkOoDZ8TprH+bPNtffDfw+7MZm3W5qRM929J5d25R/QZnZjw282mIMx8lIWpJWA0y /s/KsdxQ0csRwJ5z+Q8npZIUy8yAPdYF2o50KcYkzA1jq/t+6yzUV2NlTFGyl3Vq4B5F Qrut0dmdGTGITtTkeo19lraXx9p6AZOWMDab3wBYreoi05zL3KCYJUUORhxcQklWxyCQ BAbQ== X-Gm-Message-State: ALoCoQnBrecXIIV3XGDIGfLckQZTNsjPxMx9Xh36FtTxrvKMTX9lx/7/BX/rLHbHAGhZJEUMIrw+ X-Received: by 10.70.62.7 with SMTP id u7mr25364917pdr.108.1426772102831; Thu, 19 Mar 2015 06:35:02 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id qz3sm3175836pab.13.2015.03.19.06.35.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2015 06:35:02 -0700 (PDT) Message-ID: <550AD085.4030204@andyet.net> Date: Thu, 19 Mar 2015 07:35:01 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Henry S. Thompson" References: <5500FC11.1060109@andyet.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] continued validity of URNs (CREF12) 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: Thu, 19 Mar 2015 13:35:05 -0000 On 3/19/15 6:38 AM, Henry S. Thompson wrote: > Peter Saint-Andre - &yet writes: > >> Section 6.1 states: >> >> 3. Commitment to not reassigning existing names and to allowing old >> names to continue to be valid, even if the owners or assignees of >> those names are no longer members or customers of that >> organization. With regard to URN resolution [RFC2276], this does >> not mean that there needs to be resolution of such names, only >> that the names will not resolve to false or stale information. >> >> CREF12 poses a question for the WG about how we should handle this >> question from Henry Thompson: >> >> "Really? If a piece of retrievable metadata for some URN is the >> name and (postal) address of the publisher of whatever it >> identifies, and they've gone out of business, that metadata is >> necessarily stale, isn't it?" >> >> First, I'm not sure what we mean by "retrievable metadata for some >> URN" here because I think it confuses the issue, which is about the >> URNs themselves. >> >> Let's say that someone defines a urn:publisher namespace and that a >> publisher "Leblanc Press" is identified by urn:publisher:24601. The >> rule about not reassigning the URN doesn't have anything to do with >> the address of Leblanc Press, the continued business operations of >> Leblanc Press, or any other metadata associated with Leblanc >> Press. All it says is "don't reassign urn:publisher:24601 to, say, >> Madeleine Press". The URN always refers to Leblanc Press, even if that >> "resource" has been out of business for 1000 years. >> >> If some clarifying text is in order here, let the authors know. > > I should have been more careful to make clear that my comment was > about the second sentence, that is, the one about resolution. Ah, that helps. > To > continue with your example, suppose urn:publisher URNs have a > resolver, and that resolver, when queried wrt urn:publisher:24601, > supplies some form of information describing Leblanc Press, giving its > address and company number, as of the last year of its existence. 500 > years from now that information, although true (provided it is clearly > date-constrained), is certainly stale. > > The minimum necessary to declare victory, in my view, is just to > remove the final clause, i.e. so the sentence reads > > With regard to URN resolution [RFC2276], this does not mean that > there needs to be resolution of such names. Agreed. I would prefer to say as little as possible (if anything) in this specification about URN resolution. > In my view requiring the human-interpretable content of HTTP messages > to be true is way outside the remit of a protocol standard :-). Indeed! Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Mar 19 06:36:21 2015 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 8881A1A8A6A for ; Thu, 19 Mar 2015 06:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 HAu5DzdWFKT8 for ; Thu, 19 Mar 2015 06:36:18 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB0C1A8A08 for ; Thu, 19 Mar 2015 06:36:17 -0700 (PDT) Received: by pdbop1 with SMTP id op1so76568947pdb.2 for ; Thu, 19 Mar 2015 06:36:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pFp1vZoCjqMet3iGHINiYor4AWWycrqNYIJwVikkDpA=; b=ghJLA6SuGjpADBgt2V2J1+xPckLvwdeDtfqtzA8QLqyqIO6YxzOrweF4NAibifE+R5 UrXMTRGeW4IE31EvRYzTsKO/gvbE8B4KW6cSIRrEHuZqjCwOJCCIBOVrx1+I+4qFC1OY CZCJxFpHfILaPGjRICQpQaYTZqcibCILcyLp1I3k9MP6adpsm+5UdJE4M7HdtDe8hjOR Xe8JrTMynabJDV1h4jGnk40ORIUFlZOPUNJiuzF39JLtdF9dX107xigOp+NbRPno/kST UTDVv1dN8DjVheU5XpV4Wc1tPORqI/EIjWU9fR4xzDQkvi5XX5mktciP4VaePTIodL1/ /V+w== X-Gm-Message-State: ALoCoQly1myUsH1LtvA1ZaWYvUDGWxo2XrmFgXF6hTgW5tbPd8rrpTERolun5GSTcLYjuUtlAvYX X-Received: by 10.70.90.233 with SMTP id bz9mr94784083pdb.47.1426772177531; Thu, 19 Mar 2015 06:36:17 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id o17sm3172762pdj.26.2015.03.19.06.36.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2015 06:36:16 -0700 (PDT) Message-ID: <550AD0D0.6000009@andyet.net> Date: Thu, 19 Mar 2015 07:36:16 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Henry S. Thompson" References: <5500FD46.7070402@andyet.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] defining URN namespaces (CREF15) 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: Thu, 19 Mar 2015 13:36:19 -0000 On 3/19/15 6:50 AM, Henry S. Thompson wrote: > Peter Saint-Andre - &yet writes: > >> Section 7 states: >> >> The material in this section is intended as guidance to both >> designers of URN namespaces and (expert) reviewers of proposed URN >> namespace registrations. More information for the latter appears in >> Section 9. >> >> CREF15 poses a question for the WG: >> >> Henry would like to see a SHOULD requirement on the definitions >> here. The WG needs to decide whether that is necessary and/or >> desirable. >> >> Although I'm not a big fan of procedural SHOULDs and MUSTs, I have no >> strong objections to using normative keywords here. > > Actually, that comment was about section _6_. Section 6, *URN > Namespaces*, is in many ways the core of this specification. It > basically amounts to guidance for reviewers of URN namespace > registrations. Perhaps this should be made explicit. That is, what > is presented here as a _definition_ of a namespace is actually a set > of SHOULD requirements on a namespace definition. It's not quite > the same as section 7, which is informal (and I'm happy with that) > guidance for _authors_ of such definitions. > > I'm also not a 2119-or-die extremist, but some explicit statement of > the essentially normative nature of section 6 would be a good idea, > IMO. Thanks, I'll look at Section 6 again from that perspective and make some suggestions on the list. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Mar 19 06:41:20 2015 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 49EC01AC3D0 for ; Thu, 19 Mar 2015 06:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 J_JfhuMqNeBa for ; Thu, 19 Mar 2015 06:41:16 -0700 (PDT) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E3301AC3CA for ; Thu, 19 Mar 2015 06:41:16 -0700 (PDT) Received: by igcau2 with SMTP id au2so10917138igc.1 for ; Thu, 19 Mar 2015 06:41:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2ca/GGWuUwJKXv/gFZUGwm8yiF9n2ZDtSc3MKTU7/Xw=; b=dImy3g5QnocG0tYJ1uxl9q+a2PVFy0t7nPKvsXnvEOMMNzQCn9SF9SkcmfzI7GPXpp zX/L24vu/RaZ7/shOvg2C4zKYfuxOC3QSS+xJznnRileyT/1ifIhWMGDkCLc59eoNd9n EUEXOy2LoHE6p3oT1g8ecFL0ghCTDfK+2cLituseseTFkQFfxRbmGEUELTpuuIdZWQ3y +xwj+6M62A6mE24mat0dUMcsi/jj1EPyV26XU0S8/EtFrfnRk2BUzZSb5V2Ncbm41hm9 Fnk7ffrnYBZA+k2FSVTuwxGKrANOCB2LO+SWuH6NehrHOCNhegux95J4RQr+beiic0C0 Jjug== X-Gm-Message-State: ALoCoQlqtGr4h5yFpYEJIvMN1mvnyRPhe8iyu2aCH0oSPqbfdwEQ6JJpQ3JkG/MEtbIm/QPySlEs X-Received: by 10.50.80.12 with SMTP id n12mr16186987igx.29.1426772475736; Thu, 19 Mar 2015 06:41:15 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id q78sm922158ioi.28.2015.03.19.06.41.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2015 06:41:15 -0700 (PDT) Message-ID: <550AD1FB.7090907@andyet.net> Date: Thu, 19 Mar 2015 07:41:15 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Henry S. Thompson" References: <5500F6F0.8090603@andyet.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] constraining URI resolvers (CREF10) 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: Thu, 19 Mar 2015 13:41:18 -0000 On 3/19/15 5:26 AM, Henry S. Thompson wrote: > Peter Saint-Andre - &yet writes: > >> Section 5 states: >> >> A resolver that conforms to the URI specification [RFC3986] will >> extract a scheme of "urn" rather than a scheme value of "urn:". >> >> CREF10 proposes alternate text (because, as Henry Thompson points out, >> we cannot constrain URI resolvers in general): > > Actually, what it proposes to replace is, if I read it correctly, is > not the bit quoted above, but rather the next bit, i.e. > > A URN MUST be considered an opaque URI by URI resolvers and passed > (with the "urn" scheme) to a URN resolver for > resolution. > >> In part because of the separation of semantics from syntax >> [I-D.ietf-urnbis-semantics-clarif], generic URI processors must pay >> special attention to the parsing and analysis rules of RFC 3986 and, >> in particular, must treat the URI as opaque unless the scheme and its >> requirements are recognized. The URN resolver can either be an >> external resolver that the URI resolver knows of, or it can be >> functionality built into the URI resolver. Note that this >> requirement MAY impose constraints on the contexts in which URNs are >> appropriately used; see the previous section. >> >> This looks good to me. > > It's better, but there's now a disconnect here: > > generic URI processors must ... treat the URI as opaque unless the > scheme and its requirements are recognized. The URN resolver can > either ... > > Would something like this serve to bridge the gap: > > generic URI processors must ... treat the URI as opaque unless the > scheme and its requirements are recognized, in which case they may > be in a position to invoke scheme-appropriate processing, that is, > a URN resolver. The URN resolver can either ... Good catch. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Mar 19 10:24:39 2015 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 231451A7017 for ; Thu, 19 Mar 2015 10:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 PWiHXAg1zz_5 for ; Thu, 19 Mar 2015 10:24:35 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 543F01A7011 for ; Thu, 19 Mar 2015 10:24:34 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id t2JHOXgv015242; Thu, 19 Mar 2015 17:24:33 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t2JHOXqJ017003; Thu, 19 Mar 2015 17:24:33 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t2JHOWv3031166; Thu, 19 Mar 2015 17:24:32 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id t2JHOV2V031162; Thu, 19 Mar 2015 17:24:31 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Peter Saint-Andre - &yet References: <5500F64F.8090508@andyet.net> <550ACCEA.9040204@andyet.net> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 19 Mar 2015 17:24:31 +0000 In-Reply-To: <550ACCEA.9040204@andyet.net> (Peter Saint-Andre's message of "Thu\, 19 Mar 2015 07\:19\:38 -0600") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] URI contexts (CREF9) 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: Thu, 19 Mar 2015 17:24:38 -0000 Peter Saint-Andre - &yet writes: > On 3/19/15 5:14 AM, Henry S. Thompson wrote: >> Peter Saint-Andre - &yet writes: >> >>> Section 5 states: >>> >>> ... Ultimately, specifications of where it is appropriate to >>> use URNs, or URNs created within particular URN namespaces, >>> are the responsibility of descriptions of individual URI >>> schemes and their expected uses; this specification cannot >>> possibly anticipate all of the relevant cases. >>> >>> Ted suggested "individual URI contexts" instead of "individual URI >>> schemes". (CREF9) I wholeheartedly agree, and I thought that I had >>> already made a similar change but I see that I had not. >> >> I disagree. What's a "URI context"? > > I would think of it as the equivalent of a "protocol slot" from > IDNA2008 and PRECIS: a place where a URI can be used. > >> It's not defined, > > Yes, let's do that. > >> or even used earlier in the document. > > Only by example in that paragraph. > >> If it means "context of use", how can that >> make sense here? Suppose we adopted Ted's wording: the result would >> read: >> >> specifications of where it is appropriate to use URNs, or URNs >> created within particular URN namespaces, are the responsibility >> of descriptions of individual URI contexts. >> >> Who is now expected to provide such specifications? The HTML5 >> specification, when it talks about the 'href' attribute? > > Yes. > >> Elsevier, in some document about authoring guidelines for journal >> landing pages? Surely the right place for guidelines about the use >> of urn:mynid:... is in the NID definition for 'mynid'. > > But this is true of all URNs and is not namespace-specific. I'm confused. The text quoted above from (5) says "where it is appropriate to use URNs, or URNs created within a particular URN namespace". That _makes_ this, at least to some extent, namespace-specific, doesn't it? And so, I think, it should. I have been assuming this para. is here to address concerns about the appropriateness of e.g. constitutionally unresolvable URNs appearing in retrieval-expected slots. Being constitutionally unresolvable is a property of URNs from URN namespaces whose constitution makes that a requirement. Surely it follows that the right place for advice about appropriate contexts of use then is in that constitution, where you can say "So, don't use these in contexts that imply retrieval, e.g. HTTP GET or anywhere that might result in HTTP GET". It feels impractical to the point of inviting consternation from our readers to suggest, as I think I understand your reply above, that _every possible_ context of use of should note that you shouldn't put constitutionally-unresolvable URNs there. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Thu Mar 19 11:42:19 2015 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 438ED1A8782 for ; Thu, 19 Mar 2015 11:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 bLqqS3SEsNBD for ; Thu, 19 Mar 2015 11:42:15 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 813CF1A87C4 for ; Thu, 19 Mar 2015 11:42:12 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YYfOP-000PTs-7u; Thu, 19 Mar 2015 14:42:05 -0400 Date: Thu, 19 Mar 2015 14:42:00 -0400 From: John C Klensin To: "Henry S. Thompson" , Peter Saint-Andre - &yet Message-ID: <48E0F5BA7AB03B3AE91FEAF2@JcK-HP8200.jck.com> In-Reply-To: References: <5500F64F.8090508@andyet.net> <550ACCEA.9040204@andyet.net> 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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] URI contexts (CREF9) 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: Thu, 19 Mar 2015 18:42:17 -0000 --On Thursday, March 19, 2015 17:24 +0000 "Henry S. Thompson" wrote: > I have been assuming this para. is here to address concerns > about the appropriateness of e.g. constitutionally > unresolvable URNs appearing in retrieval-expected slots. > Being constitutionally unresolvable is a property of URNs from > URN namespaces whose constitution makes that a requirement. > Surely it follows that the right place for advice about > appropriate contexts of use then is in that constitution, > where you can say "So, don't use these in contexts that imply > retrieval, e.g. HTTP GET or anywhere that might result in HTTP > GET". > > It feels impractical to the point of inviting consternation > from our readers to suggest, as I think I understand your > reply above, that _every possible_ context of use of should > note that you shouldn't put constitutionally-unresolvable URNs > there. My response, not Peter's (I have no idea whether we agree on the details at this level or note): I agree with the above, but there is another side of this, which is that there should not be statements in docs that define URI references that say, e.g., "every URI is usable in the context of ". The statements in those places really need to either be a little more equivocal or to confine themselves to URIs where they know what they are talking about. At least IMO, suggestions for text that would say that, together with what the document now says and your observation about "constitutional unresolvability" in a way that would be clear would be most welcome. That said, "constitutionally-unresolvable" is not the only issue that concerned me. As has been discussed on this list in the past, there is a great deal of potential for URNs that do resolve but whose resolution is a multi-step process that might involve either external information (e.g., knowing the network location of the client application requesting resolution obtaining a URL that was appropriate to that location and then resolving the URL) or analysis or one or more of p-components, q-components, or f-components (but most likely q-components) to determine, to invoke a first-generation library computer automation joke, whether a URN associated with a namespace for cat information should, on resolution, return pictures of cats, descriptions of cats, or sample cats in designated states of repair [2]. Both of those hypothetical URNs resolve, so there is no "constitutional unresolvability". Whether they are appropriate for use in an HTTP context (or any similar context in any other format that might be associated with invocation of URIs) really should not -- can not-- be the responsibility of URN specifications, even per-namespace ones, to specify. On the other hand, we should be sure that namespace specifications and registrations are adequate for systems in those various contexts to make appropriate determinations and I really hope we can do that without creating a formal typology of URN namespaces. best, john [1] Capitalized if you like, but here we get into issues about what URN specs can demand of specs like HMTL(n). [2] And, no, I don't want to touch the question of a fragment identifier in that context, especially wrt separation of the cat-fragment from the cat. :-( From nobody Fri Mar 20 03:45:23 2015 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 448E21B2C54 for ; Fri, 20 Mar 2015 03:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 wA-hGcL52tgR for ; Fri, 20 Mar 2015 03:45:19 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3641A896D for ; Fri, 20 Mar 2015 03:45:19 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id t2KAjIdi019356 for ; Fri, 20 Mar 2015 10:45:18 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t2KAjI4g026963 for ; Fri, 20 Mar 2015 10:45:18 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t2KAjHRq028507 for ; Fri, 20 Mar 2015 10:45:17 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id t2KAjHj2028503; Fri, 20 Mar 2015 10:45:17 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: urn@ietf.org References: <54DE69F1.7030004@gmail.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 20 Mar 2015 10:45:17 +0000 In-Reply-To: <54DE69F1.7030004@gmail.com> (Melinda Shore's message of "Fri\, 13 Feb 2015 12\:17\:37 -0900") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Subject: [urn] draft-ietf-urnbis-rfc2141bis-urn: Sections 3.3.1 -- 3.3.3 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, 20 Mar 2015 10:45:22 -0000 [I'm very encouraged by the progress on 2141bis overall, and have recently followed up on some of the editors' feedback points as included in ...-10. There are a few more substantial points where I still think some improvement is both needed and possible---this is the first of some specific comments/suggestions.] I find the "The inner syntax of the [pqf]-component is to be defined..." phrasing awkward and confusing. Are you specifically trying to _avoid_ 2119 terminology? If so, why? This specification is clearly in a position to place normative requirements on URN namespace definitions. In other words, why _not_ say URN namespace definitions which allow the [pqf]-component MAY restrict its syntax further [in the case of p- and q-components: ... and MUST define its semantics]. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Mon Mar 23 19:59:34 2015 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 355FC1B2BE7 for ; Mon, 23 Mar 2015 19:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 e-7vxjGOShbW for ; Mon, 23 Mar 2015 19:59:31 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7528F1B2BB9 for ; Mon, 23 Mar 2015 19:59:31 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so51053814iec.2 for ; Mon, 23 Mar 2015 19:59:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HJZRkrbL+VnbhuUdqbNODHhSwBK5xLvklSCGHya2Dd4=; b=OWXWkex4rFyYSxLLWmqXwYttkER4vSXZVTmU+bIM8bxIYTTN2QnaFeEn3c2snvdjXn 5xTtcHz0YRcwnJiP+KL3o30QErmUvM5WHcky6HP8dF7tGjkx9R7BdwhUmZwjaZ8JK85q 3vX83Zq1QyYwewGAp04uj1GVnBt9KriW9x5JTSKcUiuEUrrqAuS03dqmdE2Vtz6dWscw 1m+ulLunlTc+w79/meIiQYcX2twgBB+xvnxSXIeWcTDG5yBmYKs8eteZ10daztQoIDFt 2DVF2+9b98qQsOqKnTzqQVr4I2PsyGwldUxcj28EVCCKPLIfy5TWdvWlzXKZTeTbAEts UoZg== X-Gm-Message-State: ALoCoQkOswYjNFmXwnkx7sE01n9Hf1X0WTo72ojvOGgD/yuvqVMRZVDmOu/sHAx/MO43YjoVooIc X-Received: by 10.50.129.9 with SMTP id ns9mr18729344igb.24.1427165970870; Mon, 23 Mar 2015 19:59:30 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id z3sm7739885igl.11.2015.03.23.19.59.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 19:59:29 -0700 (PDT) Message-ID: <5510D310.2020203@andyet.net> Date: Mon, 23 Mar 2015 20:59:28 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John C Klensin , "Henry S. Thompson" References: <5500F64F.8090508@andyet.net> <550ACCEA.9040204@andyet.net> <48E0F5BA7AB03B3AE91FEAF2@JcK-HP8200.jck.com> In-Reply-To: <48E0F5BA7AB03B3AE91FEAF2@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] URI contexts (CREF9) 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: Tue, 24 Mar 2015 02:59:33 -0000 On 3/19/15 12:42 PM, John C Klensin wrote: > > > --On Thursday, March 19, 2015 17:24 +0000 "Henry S. Thompson" > wrote: > >> I have been assuming this para. is here to address concerns >> about the appropriateness of e.g. constitutionally >> unresolvable URNs appearing in retrieval-expected slots. >> Being constitutionally unresolvable is a property of URNs from >> URN namespaces whose constitution makes that a requirement. >> Surely it follows that the right place for advice about >> appropriate contexts of use then is in that constitution, >> where you can say "So, don't use these in contexts that imply >> retrieval, e.g. HTTP GET or anywhere that might result in HTTP >> GET". >> >> It feels impractical to the point of inviting consternation >> from our readers to suggest, as I think I understand your >> reply above, that _every possible_ context of use of should >> note that you shouldn't put constitutionally-unresolvable URNs >> there. > > My response, not Peter's (I have no idea whether we agree on the > details at this level or note): > > I agree with the above, Probably the clause "or URNs created within particular URN namespaces" is confusing. I don't want to forestall the use of URNs from some particular (perhaps future) URN namespace from being appropriate for use in individual URI protocol slots, but it's likely best to leave out such future-proofing text at this time. > but there is another side of this, which > is that there should not be statements in docs that define URI > references that say, e.g., "every URI is usable in the context > of ". The statements in those places really need to > either be a little more equivocal or to confine themselves to > URIs where they know what they are talking about. Agreed. It might not be appropriate to put a 'data' or 'iax' or 'info' or 'tag' URI in the 'xml:base' attribute, and it's the responsbility of the XML-BASE spec to say what's appropriate there. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Mar 23 20:04:01 2015 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 73F9C1B2BEE for ; Mon, 23 Mar 2015 20:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 fOj5JNRkCeph for ; Mon, 23 Mar 2015 20:03:58 -0700 (PDT) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A0D21B2BE7 for ; Mon, 23 Mar 2015 20:03:58 -0700 (PDT) Received: by igcau2 with SMTP id au2so44365836igc.1 for ; Mon, 23 Mar 2015 20:03:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bVqGxUzxeOh31bFfIOx+TzwEuvUEQNgrX7UISejZZvU=; b=DMhltcP/zTQZnTcQrji3trYTw5JvBWaIvwqzkaZ0OMtpEgh6ADr33+kVKjYOGwB2g8 jA+Rme8SHLfhCPDBSD/+Xy1Cz9w6LMHwxkuUjW2HBSieP0J/tNRsu2DpPhI2n9VmzI8Q 2xZ6IiuZgKLgpHduwoNMk9T5ybXp+zWr6ax+lEwuwCZdkPMVHMrsjRolMmL0ndk0dnnk ywHUxcgNPxtknPOU7z617HUqh3UtMowLQR33GpcfjFl0e3lJviIl/dc32SLpSgFOkvRj h+G0LHxzXtsbQ+47nHXsBT6ehVFyvYNpGLf61W7T1q/aUzsIT0Kg1vKVLA8KYqQa8N7T uyNQ== X-Gm-Message-State: ALoCoQkEaxU8lx6GNJAkje8H35QYBRG5a3r6An3FpdCGpETfHLqKoGYBVpOryCK9jO6rIeCDEZTk X-Received: by 10.42.249.77 with SMTP id mj13mr9980300icb.80.1427166238077; Mon, 23 Mar 2015 20:03:58 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id 17sm1840909iol.39.2015.03.23.20.03.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 20:03:57 -0700 (PDT) Message-ID: <5510D41B.5060508@andyet.net> Date: Mon, 23 Mar 2015 21:03:55 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John C Klensin , "Henry S. Thompson" References: <5500F64F.8090508@andyet.net> <550ACCEA.9040204@andyet.net> <48E0F5BA7AB03B3AE91FEAF2@JcK-HP8200.jck.com> <5510D310.2020203@andyet.net> In-Reply-To: <5510D310.2020203@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] URI contexts (CREF9) 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: Tue, 24 Mar 2015 03:04:00 -0000 On 3/23/15 8:59 PM, Peter Saint-Andre - &yet wrote: > On 3/19/15 12:42 PM, John C Klensin wrote: >> >> >> --On Thursday, March 19, 2015 17:24 +0000 "Henry S. Thompson" >> wrote: >> >>> I have been assuming this para. is here to address concerns >>> about the appropriateness of e.g. constitutionally >>> unresolvable URNs appearing in retrieval-expected slots. >>> Being constitutionally unresolvable is a property of URNs from >>> URN namespaces whose constitution makes that a requirement. >>> Surely it follows that the right place for advice about >>> appropriate contexts of use then is in that constitution, >>> where you can say "So, don't use these in contexts that imply >>> retrieval, e.g. HTTP GET or anywhere that might result in HTTP >>> GET". >>> >>> It feels impractical to the point of inviting consternation >>> from our readers to suggest, as I think I understand your >>> reply above, that _every possible_ context of use of should >>> note that you shouldn't put constitutionally-unresolvable URNs >>> there. >> >> My response, not Peter's (I have no idea whether we agree on the >> details at this level or note): >> >> I agree with the above, > > Probably the clause "or URNs created within particular URN namespaces" > is confusing. I don't want to forestall the use of URNs from some > particular (perhaps future) URN namespace from being appropriate for use > in individual URI protocol slots, but it's likely best to leave out such > future-proofing text at this time. > >> but there is another side of this, which >> is that there should not be statements in docs that define URI >> references that say, e.g., "every URI is usable in the context >> of ". The statements in those places really need to >> either be a little more equivocal or to confine themselves to >> URIs where they know what they are talking about. > > Agreed. It might not be appropriate to put a 'data' or 'iax' or 'info' > or 'tag' URI in the 'xml:base' attribute, and it's the responsbility of > the XML-BASE spec to say what's appropriate there. Would the following text be agreeable? Because a URN is, syntactically, a URI under the "urn" scheme, in theory a URN can be placed in any protocol slot that allows for a URI (e.g., the 'href' and 'src' attributes in HTML, the element in HTML, the 'xml:base' attribute in XML [XML-BASE], and the 'xmlns' attribute in XML for XML namespace names [XML-NAMES]). However, this does not imply that, semantically, it always makes sense in practice to place a URN in a given URI protocol slot; in particular, because a URN might not specify the location of a resource or even point indirectly to one, it might not be appropriate to place a URN in a URI protocol slot that points to a resource (e.g., the aforementioned 'href' and 'src' attributes). Ultimately, guidelines regarding when it is appropriate to use URIs under the "urn" scheme (or any other scheme) are the responsibility of specifications for individual URI protocol slots (e.g., the specification for the 'xml:base' attribute in XML might recommend that it is inappropriate to use URNs in that protocol slot). This specification cannot possibly anticipate all of the relevant cases, and it is not the place of this specification to legislate usage for individual protocol slots. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Mar 23 20:13:54 2015 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 E033B1B2C27 for ; Mon, 23 Mar 2015 20:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 sJ7VBwSGVfCm for ; Mon, 23 Mar 2015 20:13:51 -0700 (PDT) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F11951B2C1C for ; Mon, 23 Mar 2015 20:13:50 -0700 (PDT) Received: by igbud6 with SMTP id ud6so60924615igb.1 for ; Mon, 23 Mar 2015 20:13:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=03ZQhcfj18+w6zPbZGoYa/1+HT8n9qU9y+3LNuz/wuA=; b=hHoVXMBuaty+/IhmkEWuf7zjXCgR3ebBs/ikECZTo77ImAaNfwtwGVCFqfrw870mxx mYmvVGIBYEbUtTuVY5McuyIFzT/shnfgC+zp0v08o6YhRcw80mFwkKQs6hXnxBkjvon+ rTPcrkKjUkZyZhVxJSkqV4wwF1tPTD2tHn42xZjI1rbkzeikB9g7GKWBdqGzM3MLTbLy FzN19E3+Odlo8I6zd2YMRS4i8vOcmfufNYzmuV3XXN6JY2ZPAi3iBH7sttQP3yWaLDve ROXxN1fAvBhlGfEZ2ZsfTnymnw+h7Fq4350w6Pyy0CxT3qePxu6C3xCB4diB+75TVCnA 7+Sg== X-Gm-Message-State: ALoCoQnieVCvI3q3pTegtU7pLD74Ytp9/8T55Py4zD6A6igMsJf38Jt9NckVPTC6H/fjlXz7ARua X-Received: by 10.42.240.4 with SMTP id ky4mr22843136icb.70.1427166830450; Mon, 23 Mar 2015 20:13:50 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id c41sm1888963ioj.2.2015.03.23.20.13.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 20:13:49 -0700 (PDT) Message-ID: <5510D66B.1080408@andyet.net> Date: Mon, 23 Mar 2015 21:13:47 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Henry S. Thompson" References: <5500FC11.1060109@andyet.net> <550AD085.4030204@andyet.net> In-Reply-To: <550AD085.4030204@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] continued validity of URNs (CREF12) 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: Tue, 24 Mar 2015 03:13:53 -0000 On 3/19/15 7:35 AM, Peter Saint-Andre - &yet wrote: > On 3/19/15 6:38 AM, Henry S. Thompson wrote: >> Peter Saint-Andre - &yet writes: >> >>> Section 6.1 states: >>> >>> 3. Commitment to not reassigning existing names and to allowing old >>> names to continue to be valid, even if the owners or >>> assignees of >>> those names are no longer members or customers of that >>> organization. With regard to URN resolution [RFC2276], this >>> does >>> not mean that there needs to be resolution of such names, only >>> that the names will not resolve to false or stale information. >>> >>> CREF12 poses a question for the WG about how we should handle this >>> question from Henry Thompson: >>> >>> "Really? If a piece of retrievable metadata for some URN is the >>> name and (postal) address of the publisher of whatever it >>> identifies, and they've gone out of business, that metadata is >>> necessarily stale, isn't it?" >>> >>> First, I'm not sure what we mean by "retrievable metadata for some >>> URN" here because I think it confuses the issue, which is about the >>> URNs themselves. >>> >>> Let's say that someone defines a urn:publisher namespace and that a >>> publisher "Leblanc Press" is identified by urn:publisher:24601. The >>> rule about not reassigning the URN doesn't have anything to do with >>> the address of Leblanc Press, the continued business operations of >>> Leblanc Press, or any other metadata associated with Leblanc >>> Press. All it says is "don't reassign urn:publisher:24601 to, say, >>> Madeleine Press". The URN always refers to Leblanc Press, even if that >>> "resource" has been out of business for 1000 years. >>> >>> If some clarifying text is in order here, let the authors know. >> >> I should have been more careful to make clear that my comment was >> about the second sentence, that is, the one about resolution. > > Ah, that helps. > >> To >> continue with your example, suppose urn:publisher URNs have a >> resolver, and that resolver, when queried wrt urn:publisher:24601, >> supplies some form of information describing Leblanc Press, giving its >> address and company number, as of the last year of its existence. 500 >> years from now that information, although true (provided it is clearly >> date-constrained), is certainly stale. >> >> The minimum necessary to declare victory, in my view, is just to >> remove the final clause, i.e. so the sentence reads >> >> With regard to URN resolution [RFC2276], this does not mean that >> there needs to be resolution of such names. > > Agreed. > > I would prefer to say as little as possible (if anything) in this > specification about URN resolution. I propose that we remove this sentence from Section 6.1: With regard to URN resolution [RFC2276], this does not mean that there needs to be resolution of such names, only that the names will not resolve to false or stale information. If RFC2276 is updated or replaced, that specification can say something about the matter. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Mar 23 20:21:37 2015 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 850751B2C32 for ; Mon, 23 Mar 2015 20:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 N-rsv_4VlK-6 for ; Mon, 23 Mar 2015 20:21:31 -0700 (PDT) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0B1F1B2C30 for ; Mon, 23 Mar 2015 20:21:30 -0700 (PDT) Received: by igcqo1 with SMTP id qo1so56491946igc.0 for ; Mon, 23 Mar 2015 20:21:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BgiHVL9KIZXexoBuH5EOkPbSgFMT7dw77F0z19Y3Frg=; b=caCNAHBtjMTbQ+rLFcEldMFSLRVLc+4CfUkjAEdBwJmPGh5VeQcSoHMRNlcsYUv+Lg HWPOLmRDPFkdSyhoqPmFnDDmz1rcGa/QXQnJLvlcxPrZmMAt9uPu0DCBfatO1X25BmU+ ValbK8XRZ5Pd4PRSn9J+eeR/DXZNvE/KwEonVsSsIezwcwDvstGvVnyttR97kuCdy6zV f+G4CCIkRFvLEwUMJfNdwCwaUFrqpfC8CYsGZahKacf24XVjoHrn+fHUmlbJUExRKbwL 1E4/OJOyixBFrNWazbK9Ck0W6Q8i7+hHkvni1TaI6rrndavSffrhCkxX5t8j8QXLRgUV IKFQ== X-Gm-Message-State: ALoCoQlAPpjQ4qpzad3izBdVWqpSSPzsHR1QBbMRyfyw1H9Cfu7W75MzPLM59FUeUv5qnEMQq3b3 X-Received: by 10.107.32.73 with SMTP id g70mr3179538iog.55.1427167290134; Mon, 23 Mar 2015 20:21:30 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id w5sm7772213igk.7.2015.03.23.20.21.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 20:21:29 -0700 (PDT) Message-ID: <5510D837.8020302@andyet.net> Date: Mon, 23 Mar 2015 21:21:27 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Henry S. Thompson" , John C Klensin References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Resolution services and Section 7.5 of draft-ietf-urnbis-rfc2141bis-urn-09 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: Tue, 24 Mar 2015 03:21:35 -0000 On 3/4/15 8:45 AM, Henry S. Thompson wrote: > John C Klensin writes: > >> ... >> Section 7.5 of draft-ietf-urnbis-rfc2141bis-urn-09 seems to be a >> little more specific about resolution than the direction in >> which we seem to be headed. In particular, it calls out the >> notion of registration of the namespace with an RFC 2276 >> Resolution Discovery System, an idea that has been honored >> mostly in the breach >> ... >> One possibility is just to strip the RDS and DDDS material out >> of that paragraph, saying instead: >> >> The "Resolution" section specifies the rules for resolution >> of URNs assigned within the namespace. This section SHOULD >> list the requirements for becoming a recognized resolver of >> URNs in the relevant namespace. Answers might include, but >> are not limited to: > > I like that suggestion as far as it goes. I would only add that since > it involves stripping out reference to RDS, that the numbered examples > that follow should probably also be modified so they don't give such a > central role to RDS. > > In fact, having spent a small amount of time trying to redraft the > numbered items, I wonder if even less is not more in this case. What > about > > The "Resolution" section MUST specify whether resolution mechanisms > are supported or anticipated for URNs assigned within the > namespace, and if so SHOULD specify or reference the rules governing > those mechanisms. > > In particular, if resolution is anticipated and resolver > registration of some kind is required, for example via a Resolution > Discovery System [RFC2276], this section SHOULD list the > requirements for becoming a recognized resolver of URNs in the > relevant namespace. Works for me. Thanks for the proposed text. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Mar 23 20:36:34 2015 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 EA17E1B2C37 for ; Mon, 23 Mar 2015 20:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ez2MbhLcODRk for ; Mon, 23 Mar 2015 20:36:31 -0700 (PDT) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419261B2BE6 for ; Mon, 23 Mar 2015 20:36:31 -0700 (PDT) Received: by igcqo1 with SMTP id qo1so56680605igc.0 for ; Mon, 23 Mar 2015 20:36:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3ytAQlAOO1T7eU8+Nt3glu3iPlhtd9YDcwDUlesKtTY=; b=ekYp0bcc8vr29W5lIGci8/1zJ/FkVgmdD8InxSS7j3S3UEEq7dxl/wUnCUViiWqx4K C6qA/rzdrcFKSu+jXawQrKMeWmgaTXpGqIAVf5IYOlyqFiWPiuihn3798wAlPSaGYifJ /eU/BwT847iXZwdFXjAuB8VYLoSbb/7j+OCzQ/U70ZFXVAOAji4iEcLQDafjOq2wYr1y YcKhqc4w0QG60tK+6VfDtdulbfaQrTfkIlhJvrcG0JsE30MshercXa5IfwicgwpIIBRN Q8zfmqzgi9fH95UnjMDWdY0/BZeC+FjhABVVoX/bUi9bHA2acu6wfwI85iAr2yz8mS0Q ENGg== X-Gm-Message-State: ALoCoQnFTd7BmCp6oNL+CGCOuwS89Zaq9dUWpjzrJFXQ+EsQ74ysBeclT/qun9+O3iza5Pi+5JJ3 X-Received: by 10.50.80.12 with SMTP id n12mr18857374igx.29.1427168190723; Mon, 23 Mar 2015 20:36:30 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id qs3sm7788555igb.8.2015.03.23.20.36.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 20:36:30 -0700 (PDT) Message-ID: <5510DBBC.7060606@andyet.net> Date: Mon, 23 Mar 2015 21:36:28 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Henry S. Thompson" , urn@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Case normalization (CREF 6) 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: Tue, 24 Mar 2015 03:36:33 -0000 Hi Henry, thanks for your continued engagement in these issues. On 3/19/15 5:04 AM, Henry S. Thompson wrote: > I support the changes in section 4.1. I am agnostic about the > p-component issue. > > Wrt https://github.com/MelindaShore/urnbis/issues/3 > > 1) I agree with Melinda that the reference to 3986 6.2.2.1 is not > really sufficient to explain what is actually _meant_ by "case > normalization", so suggest that each of the three numbered items > have a clause of the form ", by conversion to {upper,lower} case", > as appropriate; That seems fine to me, and more readable for sure. > 2) On the other hand, her concerns that suggest the whole vexed > question of case normalization for Unicode is involved here are, > in my view, mistaken. URIs, and hence URNs, are constrained to be > ASCII, for which upper- and lower-casing _are_ well-defined. Agreed. > In this I disagree with what I _think_ Peter [1] is implying: I > don't see any interaction here with the p-component question. > p-components are no different from any other part of URNs: they > have to be expressed in ASCII, including %-encoding as necessary. I think that what you propose here is fine (since we're talking about URIs), but as always in matters of internationalization I prefer to be especially careful, so I was hedging my bets in the email that you referenced. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Mar 23 20:51:57 2015 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 214C31B2C47 for ; Mon, 23 Mar 2015 20:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 RksU4WMRxnu7 for ; Mon, 23 Mar 2015 20:51:54 -0700 (PDT) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF6E1B2C4D for ; Mon, 23 Mar 2015 20:51:53 -0700 (PDT) Received: by igbud6 with SMTP id ud6so61452855igb.1 for ; Mon, 23 Mar 2015 20:51:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ip5peC+j53x0uZCQGocm7gMGOfccoimqHXNlI11brlE=; b=i08c+TIsCu7rsoBW3CyZlHWwmEwWtRRbJLyeKDCSQ0QX7i/JmgCE9a7AgbxeTv7fsd EfoZQVvIb+p7tgRJin3/4qsz0J16tqDL1ftCofkf3WSLI92xCD3TLIPLfnNUa6Fwk4cJ nqDYGTEYRueVXf5nNqIYWJuDp9+d3sUYt/3Rq+GEFEU39LeUKSfNtWB+AfzlrFce0TjQ 93DQ3Lu4rNZQuLG2r++Z4lZsyZUDlOn77zMjDO+ogthnsgds0gW0lJkvGH3l9qd+U2OU +ncdi2Mu05k8HbZcmwDjFhHvGmE9xk5Y/47UQ6+t4Q/yFw+uyAFkd8tOIku4h9cyDRdv ngZw== X-Gm-Message-State: ALoCoQm7VxdqgO5zhmG+z4OawB51/D3qJSCpKKb5TpWA6VwKgTPE6u1n3JgDfbcIrBP47OMfxfaR X-Received: by 10.43.14.10 with SMTP id po10mr22842726icb.64.1427169113398; Mon, 23 Mar 2015 20:51:53 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id x2sm7794519igg.9.2015.03.23.20.51.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 20:51:52 -0700 (PDT) Message-ID: <5510DF56.9090302@andyet.net> Date: Mon, 23 Mar 2015 21:51:50 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Henry S. Thompson" , urn@ietf.org References: <54DE69F1.7030004@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] draft-ietf-urnbis-rfc2141bis-urn: Sections 3.3.1 -- 3.3.3 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: Tue, 24 Mar 2015 03:51:56 -0000 On 3/20/15 4:45 AM, Henry S. Thompson wrote: > [I'm very encouraged by the progress on 2141bis overall, Thanks for the encouraging words and for contributing to the recent progress. > and have > recently followed up on some of the editors' feedback points as > included in ...-10. There are a few more substantial points where I > still think some improvement is both needed and possible---this is the > first of some specific comments/suggestions.] > > I find the "The inner syntax of the [pqf]-component is to be > defined..." phrasing awkward and confusing. Are you specifically > trying to _avoid_ 2119 terminology? If so, why? This specification > is clearly in a position to place normative requirements on URN > namespace definitions. In other words, why _not_ say > > URN namespace definitions which allow the [pqf]-component MAY > restrict its syntax further [in the case of p- and q-components: > ... and MUST define its semantics]. Yes, that's better. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Mar 23 23:08:32 2015 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 AFD5E1B2CA9 for ; Mon, 23 Mar 2015 23:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 1DxNEhWVdKFD for ; Mon, 23 Mar 2015 23:08:31 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE74A1B2CA5 for ; Mon, 23 Mar 2015 23:08:30 -0700 (PDT) Received: from [IPv6:2a02:80:3ffc::5432:db05:d1c7:f014] (unknown [IPv6:2a02:80:3ffc:0:5432:db05:d1c7:f014]) by mail.frobbit.se (Postfix) with ESMTPSA id 547CB2135D; Tue, 24 Mar 2015 07:08:29 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_06FFBD63-01C3-441B-8351-78F0A2E54B84"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b6 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <5510DBBC.7060606@andyet.net> Date: Tue, 24 Mar 2015 07:08:29 +0100 Message-Id: <9CF64715-E723-436E-BB15-84E09F2AD2D3@frobbit.se> References: <5510DBBC.7060606@andyet.net> To: Peter Saint-Andre - &yet X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Case normalization (CREF 6) 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: Tue, 24 Mar 2015 06:08:31 -0000 --Apple-Mail=_06FFBD63-01C3-441B-8351-78F0A2E54B84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 24 mar 2015, at 04:36, Peter Saint-Andre - &yet = wrote: >=20 >> 2) On the other hand, her concerns that suggest the whole vexed >> question of case normalization for Unicode is involved here are, >> in my view, mistaken. URIs, and hence URNs, are constrained to = be >> ASCII, for which upper- and lower-casing _are_ well-defined. >=20 > Agreed. Small detail...the question is not so much wether upper- and = lower-casing (the functions) are well-defined. It is whether the two = functions are inverse to each other or not, and how they are applied in = combination with whatever normalization function that might also be = applied. I.e. for each string one can absolutely apply a lower case = function and get a well defined result. Patrik --Apple-Mail=_06FFBD63-01C3-441B-8351-78F0A2E54B84 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFVEP9drMabGguI180RApsNAJ0ROFQ/vffOFDZVyKtqcpn9wOuUUwCeNr11 GVi46H+iJSfOJkWO2xA+X/k= =foFn -----END PGP SIGNATURE----- --Apple-Mail=_06FFBD63-01C3-441B-8351-78F0A2E54B84-- From nobody Tue Mar 24 00:49:03 2015 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 97CB51B2CC5 for ; Tue, 24 Mar 2015 00:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 ePXQ0S8Aokpq for ; Tue, 24 Mar 2015 00:49:00 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF2B91B2CBC for ; Tue, 24 Mar 2015 00:49:00 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YaJa1-000Pad-95; Tue, 24 Mar 2015 03:48:53 -0400 Date: Tue, 24 Mar 2015 03:48:48 -0400 From: John C Klensin To: Peter Saint-Andre - &yet , "Henry S. Thompson" , urn@ietf.org Message-ID: In-Reply-To: <5510DBBC.7060606@andyet.net> References: <5510DBBC.7060606@andyet.net> 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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Case normalization (CREF 6) 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: Tue, 24 Mar 2015 07:49:02 -0000 --On Monday, March 23, 2015 21:36 -0600 Peter Saint-Andre - &yet wrote: > Hi Henry, thanks for your continued engagement in these issues. Yes. >... >> Wrt https://github.com/MelindaShore/urnbis/issues/3 >> >> 1) I agree with Melinda that the reference to 3986 6.2.2.1 >> is not really sufficient to explain what is actually >> _meant_ by "case normalization", so suggest that each of >> the three numbered items have a clause of the form ", by >> conversion to {upper,lower} case", as appropriate; > > That seems fine to me, and more readable for sure. First of all, I thought we decided that p-components were to be case-sensitive (see Section 4.1 of 2141bis-10, including CREF7, and elsewhere). Second, while this is a non-issue as long as the NID and NSS (less any p-components) are strictly ASCII (see below), evolution in other areas probably makes it unwise to assume that URIs with the "urn" scheme will really be constructed and treated that way long term (this is part of the downside of "generic URI" assumptions). The rules in 3986 are actually fairly complicated, hand waving with "as appropriate" is no better, and might be worse, than the reference. The more important part of this is that the Unicode doctrine about case-independent matching involves CaseFold (to a first approximation, "convert to upper, then convert to lower") and not either one of upper or lower. I've got a lot of issues with case folding, especially wrt local variations (see recent note to the LUCID list), but, if anything generic is applied, it is likely what will be used. >> 2) On the other hand, her concerns that suggest the whole >> vexed question of case normalization for Unicode is >> involved here are, in my view, mistaken. URIs, and >> hence URNs, are constrained to be ASCII, for which >> upper- and lower-casing _are_ well-defined. > > Agreed. Blame me, the stress some people want to put on "generic URI resolution", and a number of other conversations, not Melinda. Let me try to be clear about where I personally stand on this: my preference is precisely "constrained to ASCII". I have some doubts that it is, and will remain, practical in the light of changes going on in WHATWG and W3C because, if a new "URI" spec is established that intermixes URI and IRI concepts (including a revised definition of the latter), the IETF semi-formally abandons the generic URI (as well as IRI definition business (as seems very likely at this stage), and people continue to focus on generic URI processing, we can reference 3986 all we like but the libraries, etc., will almost certainly be built around that new spec. That doesn't mean that we shouldn't say whatever we need to say (and on which the WG can reach rough consensus). It does mean that we need to be very clear about what we want to say and that the document needs to then say it very quickly, not reference something else and hope that the reader will figure out, e.g., that URNs expect strict enforcement of the "URIs are entirely ASCII" principle. >> In this I disagree with what I _think_ Peter [1] is >> implying: I don't see any interaction here with the >> p-component question. p-components are no different from >> any other part of URNs: they have to be expressed in >> ASCII, including %-encoding as necessary. > > I think that what you propose here is fine (since we're > talking about URIs), but as always in matters of > internationalization I prefer to be especially careful, so I > was hedging my bets in the email that you referenced. See above. If we are relying on "have to be expressed in ASCII" that is fine with me but I think the document needs to remind people of that at critical points. best, john From nobody Tue Mar 24 00:57:12 2015 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 E6E951B2CD3 for ; Tue, 24 Mar 2015 00:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 R6BVNGQ7v5h0 for ; Tue, 24 Mar 2015 00:57:10 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEDF1A890E for ; Tue, 24 Mar 2015 00:57:10 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YaJhz-000Pdy-VB; Tue, 24 Mar 2015 03:57:07 -0400 Date: Tue, 24 Mar 2015 03:57:02 -0400 From: John C Klensin To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , Peter Saint-Andre - &yet Message-ID: In-Reply-To: <9CF64715-E723-436E-BB15-84E09F2AD2D3@frobbit.se> References: <5510DBBC.7060606@andyet.net> <9CF64715-E723-436E-BB15-84E09F2AD2D3@frobbit.se> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Case normalization (CREF 6) 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: Tue, 24 Mar 2015 07:57:12 -0000 --On Tuesday, March 24, 2015 07:08 +0100 Patrik = F=C3=A4ltstr=C3=B6m wrote: > Small detail...the question is not so much wether upper- and > lower-casing (the functions) are well-defined. It is whether > the two functions are inverse to each other or not, and how > they are applied in combination with whatever normalization > function that might also be applied. I.e. for each string one > can absolutely apply a lower case function and get a well > defined result. To be a bit more specific, (1) Outside the ASCII range, ToUpper(string) is generally not equal to ToUpper(ToLower(string)) and similarly for the lower-case variation. The operations are not only not "inverse" to each other, for particular characters, they many-one rather than one-one too). That is, more or less, where the preference for case folding comes from. Again, if the string in question is limited strictly to ASCII, these are non-issues. =20 (2) Outside the ASCII range, the statement "absolutely apply a lower case function and get a well defined result" is strictly true only if one knows the locale (or possibly just the language) or has a rule that a "locale-insensitive" (really "locale-ignoring and some locales lose") operation is being = used. john From nobody Tue Mar 24 01:20:04 2015 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 8383E1B2D27 for ; Tue, 24 Mar 2015 01:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 TYF6HikDH1NW for ; Tue, 24 Mar 2015 01:20:00 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2F91B2D05 for ; Tue, 24 Mar 2015 01:20:00 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id t2O8Jg0B016782; Tue, 24 Mar 2015 08:19:42 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t2O8JhOc018581; Tue, 24 Mar 2015 08:19:43 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t2O8JggJ006002; Tue, 24 Mar 2015 08:19:42 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id t2O8JebM005998; Tue, 24 Mar 2015 08:19:40 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: John C Klensin References: <5510DBBC.7060606@andyet.net> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 24 Mar 2015 08:19:40 +0000 In-Reply-To: (John C. Klensin's message of "Tue\, 24 Mar 2015 03\:48\:48 -0400") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: Cc: urn@ietf.org, Peter Saint-Andre - &yet Subject: Re: [urn] Case normalization (CREF 6) 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: Tue, 24 Mar 2015 08:20:03 -0000 John C Klensin writes: >>> >>> 1) I agree with Melinda that the reference to 3986 6.2.2.1 >>> is not really sufficient to explain what is actually >>> _meant_ by "case normalization", so suggest that each of >>> the three numbered items have a clause of the form ", by >>> conversion to {upper,lower} case", as appropriate; >> >> That seems fine to me, and more readable for sure. > > First of all, I thought we decided that p-components were to be > case-sensitive (see Section 4.1 of 2141bis-10, including CREF7, > and elsewhere). Sure, none of the clauses I am referring to applhy to the p-component. > Second, while this is a non-issue as long as the NID and NSS > (less any p-components) are strictly ASCII (see below), > evolution in other areas probably makes it unwise to assume that > URIs with the "urn" scheme will really be constructed and > treated that way long term (this is part of the downside of > "generic URI" assumptions). See our previous failure to communicate wrt what I have called the distinction between human-appropriate and protocol-appropriate forms. We really do have to come back to that once this document is sorted. > The rules in 3986 are actually fairly complicated, hand waving with > "as appropriate" is no better, and might be worse, than the > reference. Sorry I was too brief and hence confusing -- that 'as appropriate' is _outside_ the quote marks, i.e. _not_ meant to go in the spec. Rather I meant that for the three clauses, in some cases the text should read 'upper-case' and in others 'lower-case'. > The more important part of this is that the Unicode > doctrine about case-independent matching involves CaseFold (to a > first approximation, "convert to upper, then convert to lower") and > not either one of upper or lower. I've got a lot of issues with > case folding, especially wrt local variations (see recent note to > the LUCID list), but, if anything generic is applied, it is likely > what will be used. Not if we don't call it case-folding, which 3986 doesn't either, IIRC. >>> 2) On the other hand, her concerns that suggest the whole >>> vexed question of case normalization for Unicode is >>> involved here are, in my view, mistaken. URIs, and >>> hence URNs, are constrained to be ASCII, for which >>> upper- and lower-casing _are_ well-defined. >> >> Agreed. > > Blame me, the stress some people want to put on "generic URI > resolution", and a number of other conversations, not Melinda. Noted :-). >> [concerns about creeping loss of consensus wrt ASCII-only] Agreed that the discourse around this topic is in a less-than-wonderful place. And that staying out of that debate is the right thing _for this document, at this time_. > See above. If we are relying on "have to be expressed in ASCII" > that is fine with me but I think the document needs to remind > people of that at critical points. For sure. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Tue Mar 24 07:39:27 2015 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 2900D1A87B2; Tue, 24 Mar 2015 07:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 MI6XmaQFegxU; Tue, 24 Mar 2015 07:39:20 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E341A87A6; Tue, 24 Mar 2015 07:38:31 -0700 (PDT) Received: by iedm5 with SMTP id m5so61861882ied.3; Tue, 24 Mar 2015 07:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=d/Kl/0JzbRgmyFyQPuoUsV7j+/HTEsS342ol+ox5HWI=; b=SXMRXyd/QESlEe3aErOUNYF5FGo+3rHosZrlgnxQo+tw8lPfk+xqZqonYW3ihXeeys OTKE+1GyrxJqWw/RtaNJFSJqo95YoIi2F5NOcHGnwdvzyb6Mwt2WWnu1iBVgmqsRDnaP MI6mYcUzm3HLYFGlUv0amyY0JBAlVKzw6h12MYlB+6Cwagohr74MpRimvR1MGKy9WrLF UG7YO80MkJMNjTmr2giEqBq8aS2qgEXBN4JqIYAiF9vZIH4d+DWZsD7I32GvfYrS24Cq m5zuDU2QuU0l+ZB6v8cVpLoW2nvlcv9ld5/Qeredf3ngB5VxRFuwwPeSwBsndr2+4fsp Lz/w== MIME-Version: 1.0 X-Received: by 10.50.176.196 with SMTP id ck4mr22947659igc.40.1427207911065; Tue, 24 Mar 2015 07:38:31 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.17.26 with HTTP; Tue, 24 Mar 2015 07:38:31 -0700 (PDT) Date: Tue, 24 Mar 2015 09:38:31 -0500 X-Google-Sender-Auth: F_RRqaChwwZxbqZ5L-eQKb9lZpo Message-ID: From: Barry Leiba To: Apps Discuss , "urn@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Subject: [urn] URNbis working group session is postponed to a conference call within a few weeks 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: Tue, 24 Mar 2015 14:39:22 -0000 At the request of the URNbis chair and document editors, I am cancelling the URNbis session at IETF 92, postponing the meeting to a conference call within a few weeks. We'll get that set up and announced with at least two weeks' notice, and everyone will be welcome to join it. The document authors think this is wise because most of the key people will have trouble attending, even remotely, on Thursday, and because they think they can be better ready for a meeting if they have a chance to work out another revision of the documents first. The chairs (and I) agree. Please watch for details and discussion. The conference call details will also be posted to ietf-announce. Barry, Applications AD From nobody Tue Mar 24 09:58:25 2015 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 E32221A9101 for ; Tue, 24 Mar 2015 09:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 9D2kt8rFC3G8 for ; Tue, 24 Mar 2015 09:58:19 -0700 (PDT) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429E01A911B for ; Tue, 24 Mar 2015 09:58:19 -0700 (PDT) Received: by igcxg11 with SMTP id xg11so2960866igc.0 for ; Tue, 24 Mar 2015 09:58:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=O9BkmzccliGToFr7tRQBvdsIsnSx/OcZjZBQmu+SqYE=; b=NNOSjMrQ/qQyN0X+y9WmmjEXo6I6l3Aw7MqR9nl5yhYqTwWQns6XvoBB5DXejGqnBB SkHhSwaNp64quduhk8fvVSfcTgR0w+A2lBBuDIqOjQx+HvmnNw37oN/bPACBKbQsUQ3R SSo/t6lGPhoGzu6lNgx5hnCNytAjWUTp1HyW1RVgK0cEIoaKIfG+U4EMtescuckDINSW xaf52pRF1029amd9TEXF4UxubHPLpnbKCKMm7GsEIkyeT4rIXl3MjQbeiBrvZ9ssqF00 pEc8m2H8nffzy1GnhB5VYOj+PoTz7VOzjALalg/8v7dztXDGKM+8QzxgoQXUeDXV9iTK OmAQ== X-Gm-Message-State: ALoCoQkFq5vGf0q/gltp/aO0il3NYPqEYiA/wNhwPwiXIzuVW8fzNMFjiontmTo4KSkEjkJC6vAQ X-Received: by 10.42.67.19 with SMTP id r19mr2261813ici.30.1427216298682; Tue, 24 Mar 2015 09:58:18 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id mw1sm161178igb.18.2015.03.24.09.58.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2015 09:58:17 -0700 (PDT) Message-ID: <551197A8.90602@andyet.net> Date: Tue, 24 Mar 2015 10:58:16 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Barry Leiba , "urn@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] URNbis working group session is postponed to a conference call within a few weeks 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: Tue, 24 Mar 2015 16:58:23 -0000 On 3/24/15 8:38 AM, Barry Leiba wrote: > At the request of the URNbis chair and document editors, I am > cancelling the URNbis session at IETF 92, postponing the meeting to a > conference call within a few weeks. We'll get that set up and > announced with at least two weeks' notice, and everyone will be > welcome to join it. > > The document authors think this is wise because most of the key people > will have trouble attending, even remotely, on Thursday, and because > they think they can be better ready for a meeting if they have a > chance to work out another revision of the documents first. The > chairs (and I) agree. Yes, John and I are committed to submitting a revised I-D by March 31. Peter From nobody Tue Mar 24 11:49:33 2015 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 1C18E1A8A5E for ; Tue, 24 Mar 2015 11:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 qYvJeghalMxp for ; Tue, 24 Mar 2015 11:49:23 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239CE1A8A4A for ; Tue, 24 Mar 2015 11:49:21 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YaTt8-0001im-M1; Tue, 24 Mar 2015 14:49:18 -0400 Date: Tue, 24 Mar 2015 14:49:13 -0400 From: John C Klensin To: Peter Saint-Andre - &yet , urn@ietf.org Message-ID: <359F73CA2C48E17B745369A5@JcK-HP8200.jck.com> In-Reply-To: <551197A8.90602@andyet.net> References: <551197A8.90602@andyet.net> 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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Barry Leiba Subject: Re: [urn] URNbis working group session is postponed to a conference call within a few weeks 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: Tue, 24 Mar 2015 18:49:30 -0000 --On Tuesday, March 24, 2015 10:58 -0600 Peter Saint-Andre - &yet wrote: >> The document authors think this is wise because most of the >> key people will have trouble attending, even remotely, on >> Thursday, and because they think they can be better ready for >> a meeting if they have a chance to work out another revision >> of the documents first. The chairs (and I) agree. > > Yes, John and I are committed to submitting a revised I-D by > March 31. Note that this means that anyone who has comments, especially on the questions raised in the most recent 2141bis and on-list, should get them posted to the list as soon as possible if you have not done so already. Peter and I have not discussed specific cutoffs, but comments posted before this Friday (27 March) are a lot more likely to be discussed as needed and reflected in the document than ones that appear as we are finishing things up. Anyone who needs time to post such comments should note that we just gave you back two hours of this Thursday :-( john From nobody Tue Mar 24 15:58:17 2015 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 3A7D01ACCEF for ; Tue, 24 Mar 2015 15:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 odseyj7twppJ for ; Tue, 24 Mar 2015 15:58:13 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299E91A1B8A for ; Tue, 24 Mar 2015 15:58:13 -0700 (PDT) Received: by iecvj10 with SMTP id vj10so9905352iec.0 for ; Tue, 24 Mar 2015 15:58:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NMXskLaYRYkPAlR+dBJEQkuMvWrk6jYt1bxCYhWXtws=; b=dCl8rvrob9qlcwkmhRm/OOzMSDafq+X2RvJ8oPzhiX76J49vBZkO+2/0snOaOan+5b qkrwYBru1oUIMpPR8jyHuvclgNT75YAlcRrdk7Naq6rZ6ZtPQ/sE537x/+a0qfjwd/Rr e2IfKJ+wtS+p1HEfJtonz9ynC//iRji/5jFBL0xdNWu7ihj3GniC4zdkqsy9h0adatDz +zmHQe/tfUE+ulSw+e4mGwHCwgrV/8mKjsD+KdSs9tfL2OnsJBo4RiHFdXmpvsTVUx1w HBKliiPvJmKEQnghu3Yip1expMx1iWu4F3Ez3h8suLaGOb7fRmJGlsCv+JhKfOOIH4zC NAlA== X-Gm-Message-State: ALoCoQkERZr35Fl7SKYXn1EZvx2STL8EmY8P+fzau/8YFlkGPZ0jy0qB04CTBzrWDhoA5ToM18XB X-Received: by 10.50.253.12 with SMTP id zw12mr25433289igc.24.1427237892533; Tue, 24 Mar 2015 15:58:12 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id g76sm454823iod.8.2015.03.24.15.58.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2015 15:58:11 -0700 (PDT) Message-ID: <5511EC02.4020209@andyet.net> Date: Tue, 24 Mar 2015 16:58:10 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John C Klensin , "Henry S. Thompson" , urn@ietf.org References: <5510DBBC.7060606@andyet.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Case normalization (CREF 6) 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: Tue, 24 Mar 2015 22:58:15 -0000 On 3/24/15 1:48 AM, John C Klensin wrote: > > > --On Monday, March 23, 2015 21:36 -0600 Peter Saint-Andre - &yet > wrote: > >> Hi Henry, thanks for your continued engagement in these issues. > > Yes. > >> ... >>> Wrt https://github.com/MelindaShore/urnbis/issues/3 >>> >>> 1) I agree with Melinda that the reference to 3986 6.2.2.1 >>> is not really sufficient to explain what is actually >>> _meant_ by "case normalization", so suggest that each of >>> the three numbered items have a clause of the form ", by >>> conversion to {upper,lower} case", as appropriate; >> >> That seems fine to me, and more readable for sure. > > First of all, I thought we decided that p-components were to be > case-sensitive (see Section 4.1 of 2141bis-10, including CREF7, > and elsewhere). > > Second, while this is a non-issue as long as the NID and NSS > (less any p-components) are strictly ASCII (see below), > evolution in other areas probably makes it unwise to assume that > URIs with the "urn" scheme will really be constructed and > treated that way long term (this is part of the downside of > "generic URI" assumptions). The rules in 3986 are actually > fairly complicated, hand waving with "as appropriate" is no > better, and might be worse, than the reference. The more > important part of this is that the Unicode doctrine about > case-independent matching involves CaseFold (to a first > approximation, "convert to upper, then convert to lower") and > not either one of upper or lower. I've got a lot of issues with > case folding, especially wrt local variations (see recent note > to the LUCID list), but, if anything generic is applied, it is > likely what will be used. > >>> 2) On the other hand, her concerns that suggest the whole >>> vexed question of case normalization for Unicode is >>> involved here are, in my view, mistaken. URIs, and >>> hence URNs, are constrained to be ASCII, for which >>> upper- and lower-casing _are_ well-defined. >> >> Agreed. > > Blame me, the stress some people want to put on "generic URI > resolution", and a number of other conversations, not Melinda. > > Let me try to be clear about where I personally stand on this: > my preference is precisely "constrained to ASCII". For now that is, I think, the only reasonable path toward completing this work soon. > I have some > doubts that it is, and will remain, practical in the light of > changes going on in WHATWG and W3C because, if a new "URI" spec > is established that intermixes URI and IRI concepts (including a > revised definition of the latter), the IETF semi-formally > abandons the generic URI (as well as IRI definition business (as > seems very likely at this stage), and people continue to focus > on generic URI processing, we can reference 3986 all we like but > the libraries, etc., will almost certainly be built around that > new spec. I wish good luck to the folks who work on 2141ter. :-) > That doesn't mean that we shouldn't say whatever we need to say > (and on which the WG can reach rough consensus). It does mean > that we need to be very clear about what we want to say and that > the document needs to then say it very quickly, not reference > something else and hope that the reader will figure out, e.g., > that URNs expect strict enforcement of the "URIs are entirely > ASCII" principle. > >>> In this I disagree with what I _think_ Peter [1] is >>> implying: I don't see any interaction here with the >>> p-component question. p-components are no different from >>> any other part of URNs: they have to be expressed in >>> ASCII, including %-encoding as necessary. >> >> I think that what you propose here is fine (since we're >> talking about URIs), but as always in matters of >> internationalization I prefer to be especially careful, so I >> was hedging my bets in the email that you referenced. > > See above. If we are relying on "have to be expressed in ASCII" > that is fine with me but I think the document needs to remind > people of that at critical points. Yes, I will look for some places in the document to say this loud and clear. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Mar 24 20:07:06 2015 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 C0F901A92DF for ; Tue, 24 Mar 2015 20:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 cqBEW9g4wjac for ; Tue, 24 Mar 2015 20:07:03 -0700 (PDT) Received: from APAC01-SG1-obe.outbound.protection.outlook.com (mail-sg1on0111.outbound.protection.outlook.com [134.170.132.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91191ACD33 for ; Tue, 24 Mar 2015 20:07:02 -0700 (PDT) Received: from [133.2.210.64] (133.2.210.64) by KAWPR01MB0065.jpnprd01.prod.outlook.com (25.161.25.147) with Microsoft SMTP Server (TLS) id 15.1.125.19; Wed, 25 Mar 2015 03:06:57 +0000 Message-ID: <55122649.4060504@it.aoyama.ac.jp> Date: Wed, 25 Mar 2015 12:06:49 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John C Klensin , Peter Saint-Andre - &yet , References: <551197A8.90602@andyet.net> <359F73CA2C48E17B745369A5@JcK-HP8200.jck.com> In-Reply-To: <359F73CA2C48E17B745369A5@JcK-HP8200.jck.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: HKXPR02CA0064.apcprd02.prod.outlook.com (25.161.48.49) To KAWPR01MB0065.jpnprd01.prod.outlook.com (25.161.25.147) Authentication-Results: computer.org; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:KAWPR01MB0065; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6049001)(6009001)(479174004)(24454002)(46034005)(30513003)(86362001)(64126003)(77156002)(62966003)(66066001)(65956001)(50986999)(76176999)(65806001)(99136001)(42186005)(23676002)(54356999)(87266999)(65816999)(50466002)(83506001)(85182001)(87976001)(46102003)(558084003)(2950100001)(117636001)(122386002)(40100003)(92566002)(74482002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:KAWPR01MB0065; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5002010)(5005006); SRVR:KAWPR01MB0065; BCL:0; PCL:0; RULEID:; SRVR:KAWPR01MB0065; X-Forefront-PRVS: 052670E5A4 X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Mar 2015 03:06:57.3862 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: KAWPR01MB0065 Archived-At: Cc: Barry Leiba Subject: Re: [urn] URNbis working group session is postponed to a conference call within a few weeks 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, 25 Mar 2015 03:07:05 -0000 On 2015/03/25 03:49, John C Klensin wrote: > Anyone who needs time to post such comments should note that we > just gave you back two hours of this Thursday :-( Strictly speaking, that only applies to those who planned to attend (in person or remotely :-). Regards, Martin. From nobody Tue Mar 24 20:25:10 2015 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 4216A1ACD50 for ; Tue, 24 Mar 2015 20:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 qOZj4zyffOtN for ; Tue, 24 Mar 2015 20:25:08 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1901ACD63 for ; Tue, 24 Mar 2015 20:25:07 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YabwD-0003Dg-OA; Tue, 24 Mar 2015 23:25:01 -0400 Date: Tue, 24 Mar 2015 23:24:56 -0400 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , Peter Saint-Andre - &yet , urn@ietf.org Message-ID: <55D1A520FB2FC3AC00CFC913@JcK-HP8200.jck.com> In-Reply-To: <55122649.4060504@it.aoyama.ac.jp> References: <551197A8.90602@andyet.net> <359F73CA2C48E17B745369A5@JcK-HP8200.jck.com> <55122649.4060504@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Barry Leiba Subject: Re: [urn] URNbis working group session is postponed to a conference call within a few weeks 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, 25 Mar 2015 03:25:09 -0000 --On Wednesday, March 25, 2015 12:06 +0900 "\"Martin J. D=C3=BCrst\"" wrote: > On 2015/03/25 03:49, John C Klensin wrote: >=20 >> Anyone who needs time to post such comments should note that >> we just gave you back two hours of this Thursday :-( >=20 > Strictly speaking, that only applies to those who planned to > attend (in person or remotely :-). Yes. But I assumed that everyone participating was so interested and dedicated that they expected to attend one way or the other :-) I have lots of delusions of that sort. :-) :-) john From nobody Tue Mar 24 20:38:28 2015 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 5DE691ACD79 for ; Tue, 24 Mar 2015 20:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 Dy3bcVxLCJzQ for ; Tue, 24 Mar 2015 20:38:25 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCA981ACD78 for ; Tue, 24 Mar 2015 20:38:25 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8EF1820AEE for ; Tue, 24 Mar 2015 23:38:22 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Tue, 24 Mar 2015 23:38:25 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=D23n8Ud/7+vdFmu0upXoPB u/9ks=; b=ApBPNXmBC3zysA0YHAx0V00Pg+sLHw978SHNWvTN5amYM0gOBj26i4 aFiVFj7eDnB6Ax7qIbPys9bKzeMPjjz2cjHz5TmkXFnTSB915kn1RwoMwFyM6Ctl Ii9uoi6hnGRLG71gFWCIfv4ct+shd/2LCO0lgCIJqDc0NSKix73NU= X-Sasl-enc: y1QdRXf4efCMiyZ4MJYjam21o0jX3jpZrlKN/rr7oYzA 1427254704 Received: from [10.248.42.126] (unknown [64.183.197.98]) by mail.messagingengine.com (Postfix) with ESMTPA id D2E5E680190; Tue, 24 Mar 2015 23:38:23 -0400 (EDT) Message-ID: <55122D9E.70005@network-heretics.com> Date: Tue, 24 Mar 2015 23:38:06 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: urn@ietf.org References: <551197A8.90602@andyet.net> <359F73CA2C48E17B745369A5@JcK-HP8200.jck.com> In-Reply-To: <359F73CA2C48E17B745369A5@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] URNbis working group session is postponed to a conference call within a few weeks 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, 25 Mar 2015 03:38:27 -0000 On 03/24/2015 02:49 PM, John C Klensin wrote: > Note that this means that anyone who has comments, especially on > the questions raised in the most recent 2141bis and on-list, > should get them posted to the list as soon as possible if you > have not done so already. Peter and I have not discussed > specific cutoffs, but comments posted before this Friday (27 > March) are a lot more likely to be discussed as needed and > reflected in the document than ones that appear as we are > finishing things up. > > Anyone who needs time to post such comments should note that we > just gave you back two hours of this Thursday:-( Except that some of us are busy at IETF and may not have any free time until next week :) From nobody Tue Mar 24 20:40:22 2015 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 BBA6A1ACD7B for ; Tue, 24 Mar 2015 20:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 jCqW1n6U9ThA for ; Tue, 24 Mar 2015 20:40:20 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A770D1ACD79 for ; Tue, 24 Mar 2015 20:40:20 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 78C7A20A77 for ; Tue, 24 Mar 2015 23:40:17 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 24 Mar 2015 23:40:20 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=0ZwW0PJX5tOtffj8ZvZpZJ bsk5k=; b=TCinIbAwqUe2Ow+eK49kd3j3IpOJNwR63FGKY2fcaOJML14SY5q8Hr TmPcWW+iPSL9wznAs+dVA0+5fcA++N9D7SN4nK/f3X6QGsVhakvd+69dzYM341Or ubVWPd4t9+zXzI9ghqkm1NfKNG9ZRi15X6Bkg4/QxGQw90sT4vUw8= X-Sasl-enc: uomMPfJK+tmlwtoCuvA8Ah0g+C64cR850m6SEV9rCo7q 1427254819 Received: from [10.248.42.126] (unknown [64.183.197.98]) by mail.messagingengine.com (Postfix) with ESMTPA id 92369C00022; Tue, 24 Mar 2015 23:40:19 -0400 (EDT) Message-ID: <55122E11.7030701@network-heretics.com> Date: Tue, 24 Mar 2015 23:40:01 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: urn@ietf.org References: <551197A8.90602@andyet.net> <359F73CA2C48E17B745369A5@JcK-HP8200.jck.com> <55122649.4060504@it.aoyama.ac.jp> <55D1A520FB2FC3AC00CFC913@JcK-HP8200.jck.com> In-Reply-To: <55D1A520FB2FC3AC00CFC913@JcK-HP8200.jck.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] URNbis working group session is postponed to a conference call within a few weeks 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, 25 Mar 2015 03:40:21 -0000 On 03/24/2015 11:24 PM, John C Klensin wrote: > > --On Wednesday, March 25, 2015 12:06 +0900 "\"Martin J. > Dürst\"" wrote: > >> On 2015/03/25 03:49, John C Klensin wrote: >> >>> Anyone who needs time to post such comments should note that >>> we just gave you back two hours of this Thursday :-( >> Strictly speaking, that only applies to those who planned to >> attend (in person or remotely :-). > Yes. But I assumed that everyone participating was so > interested and dedicated that they expected to attend one way or > the other :-) I have lots of delusions of that sort. :-) :-) I, apparently, have the delusion that people who are interested and dedicated to this work will actually show up at meetings. Silly me for shelling out the bucks to get there, out of the realization that trying to communicate my concerns from a distance wasn't working. Keith From nobody Tue Mar 24 20:45:51 2015 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 C82A01ACD80 for ; Tue, 24 Mar 2015 20:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 gN3VBicoFF-b for ; Tue, 24 Mar 2015 20:45:49 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8501ACD7F for ; Tue, 24 Mar 2015 20:45:49 -0700 (PDT) Received: by obbgg8 with SMTP id gg8so10199527obb.1 for ; Tue, 24 Mar 2015 20:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=/zC/+oDs0Pw1vDhN/dqdCXIvPBoCcSTOL3KOeQIkagY=; b=Lwuw0bT2+IfJ6DDuZbsuQCfals3Wehj5t65YNPawiHkyAHj/O/wyaTQVnZJof3wN19 9NAzWzsQZTkDUNryop5egOQ/nRpe+ebY94eQE0oQ+ja3lhIBacyLHxLkK0C8jH06PHZ+ RwXrEfCk3MJyxG2FwEZ7ognNMERLzJ4P52QQN1mvCG/SAKR+MoBm8xNyo35bqvnU7Nzc juPntfkCE7GT/r82FJlNJrbbvnCuCkJtmJnBdjDNmScpqPGp3wOTdZdvUjkw8ronWXVT jLhyyGYQZK0BQkwyRGfOqbaEkiNStTYSwymC7i9y75JGydLf+TXFOOXSlqW/1LEWummc E5kQ== X-Received: by 10.202.111.131 with SMTP id v3mr5404173oik.133.1427255149026; Tue, 24 Mar 2015 20:45:49 -0700 (PDT) Received: from Melindas-MacBook-Pro.local ([38.96.210.190]) by mx.google.com with ESMTPSA id vj2sm1086529obb.10.2015.03.24.20.45.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2015 20:45:48 -0700 (PDT) Message-ID: <55122F6B.9080403@gmail.com> Date: Tue, 24 Mar 2015 22:45:47 -0500 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: urn@ietf.org References: <551197A8.90602@andyet.net> <359F73CA2C48E17B745369A5@JcK-HP8200.jck.com> <55122649.4060504@it.aoyama.ac.jp> <55D1A520FB2FC3AC00CFC913@JcK-HP8200.jck.com> <55122E11.7030701@network-heretics.com> In-Reply-To: <55122E11.7030701@network-heretics.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] URNbis working group session is postponed to a conference call within a few weeks 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, 25 Mar 2015 03:45:50 -0000 On 3/24/15 10:40 PM, Keith Moore wrote: > I, apparently, have the delusion that people who are interested and > dedicated to this work will actually show up at meetings. Silly me for > shelling out the bucks to get there, out of the realization that trying > to communicate my concerns from a distance wasn't working. I'm not sure what's going on but it does seem to be the case that active participants are not showing up for meetings quite as reliably as they used to. We're seeing this in a number of working groups. They're still cranking out text and active on mailing lists but they may or may not show up for meetings. I think this has quite a bit to do with institutional support, so the challenge, aside from making more effective use of mailing lists and tools suck as issue trackers, is how to provide better support for remote participants, whether they're document authors, or they're working group participants and document reviewers. I'm hopeful that we can have a very effective virtual interim in early-to-mid April, but we need for people who have concerns about the documents to show up. I hope you'll be there. Melinda From nobody Tue Mar 24 22:14:28 2015 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 2113F1ACDB1 for ; Tue, 24 Mar 2015 22:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 QbZNfF5eKp3J for ; Tue, 24 Mar 2015 22:14:25 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB3211ACDAB for ; Tue, 24 Mar 2015 22:14:25 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 55B8220D25 for ; Wed, 25 Mar 2015 01:14:22 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Wed, 25 Mar 2015 01:14:25 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=K7FkupNDeW1nWbHw9WX67I 9zitU=; b=tqbn8K9AGWcg3WqsaphbIJFWKmaBqsDPBLM6EHHAh15zcsgutJ0QIF Wrkl0QtQ8wYnLZvusFcfhJIqTegMfho/RLyrRwBU4TY27GDDfnGFVS6eTn22vo5Z YaxiF4FF8xFHKdmBCn7aN05GK2+woHO/46qQSUVOrTX5hBGGbWm8E= X-Sasl-enc: rRK5A68ZyJ6I7zMEIyUyQPXuayGdaEE+B1gH/fkadrg9 1427260464 Received: from [10.248.42.126] (unknown [64.183.197.98]) by mail.messagingengine.com (Postfix) with ESMTPA id 803A7C00013; Wed, 25 Mar 2015 01:14:24 -0400 (EDT) Message-ID: <5512442F.2040904@network-heretics.com> Date: Wed, 25 Mar 2015 01:14:23 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: urn@ietf.org References: <551197A8.90602@andyet.net> <359F73CA2C48E17B745369A5@JcK-HP8200.jck.com> <55122649.4060504@it.aoyama.ac.jp> <55D1A520FB2FC3AC00CFC913@JcK-HP8200.jck.com> <55122E11.7030701@network-heretics.com> <55122F6B.9080403@gmail.com> In-Reply-To: <55122F6B.9080403@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] URNbis working group session is postponed to a conference call within a few weeks 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, 25 Mar 2015 05:14:27 -0000 On 03/24/2015 11:45 PM, Melinda Shore wrote: > On 3/24/15 10:40 PM, Keith Moore wrote: >> I, apparently, have the delusion that people who are interested and >> dedicated to this work will actually show up at meetings. Silly me for >> shelling out the bucks to get there, out of the realization that trying >> to communicate my concerns from a distance wasn't working. > > I'm not sure what's going on but it does seem to be the case > that active participants are not showing up for meetings quite > as reliably as they used to. We're seeing this in a number > of working groups. They're still cranking out text and active > on mailing lists but they may or may not show up for meetings. > I think this has quite a bit to do with institutional support, > so the challenge, aside from making more effective use of mailing > lists and tools suck as issue trackers, is how to provide better > support for remote participants, whether they're document > authors, or they're working group participants and document reviewers. > > I'm hopeful that we can have a very effective virtual interim > in early-to-mid April, but we need for people who have concerns > about the documents to show up. I hope you'll be there. Melinda, the history of this WG in particular seems to be that the people who have been driving it have been hostile not only to input from people whom they deemed as "outsiders", but also hostile to any URN functionality other than that which they wanted, and in fact hostile to the primary intended purpose of URNs. Keith From nobody Wed Mar 25 01:18:54 2015 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 503CA1ACE12 for ; Wed, 25 Mar 2015 01:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] 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 baMQ49Edbc1F for ; Wed, 25 Mar 2015 01:18:51 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 803A31ACE09 for ; Wed, 25 Mar 2015 01:18:44 -0700 (PDT) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id DC7378AF3A; Wed, 25 Mar 2015 09:18:42 +0100 (CET) X-AuditID: 0a453fe7-f79b36d0000032b6-75-55126f62f100 Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id 56.A6.12982.26F62155; Wed, 25 Mar 2015 09:18:42 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Wed, 25 Mar 2015 09:18:42 +0100 From: "Svensson, Lars" To: John C Klensin , Peter Saint-Andre - &yet , "urn@ietf.org" Thread-Topic: [urn] URNbis working group session is postponed to a conference call within a few weeks Thread-Index: AQHQZkBb17jLJKQyVUuHKDjjNk1SHJ0ryi0AgAAe/4CAAPKUQA== Date: Wed, 25 Mar 2015 08:18:41 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFFAC8FD86@dnbf-ex1.AD.DDB.DE> References: <551197A8.90602@andyet.net> <359F73CA2C48E17B745369A5@JcK-HP8200.jck.com> In-Reply-To: <359F73CA2C48E17B745369A5@JcK-HP8200.jck.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.158] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12Ta0gUURTHuTvj7uzq3e6Ountbew6GZGgqQltEhRhtFFSkRX2oxmbcXVx3 l5ndSMHoYVCKPaiItrCHIhRSIkXZA3QLKz9YmNSHbCWNIjUUxMowa+4+bOzbmd/5n//5Hy7D UGwtY2VcHr8oeXg3pzXQhvVrJ7JKvGxxztSpPFuooSfBdrxnSmvrGnhG2S4cG9Oso+3dfW91 9upbdZS9sXFSY39zc5jaSu82rBZEt+uAKC1fs8/gfPehTecbYg7+HunVHQYT2hrAMBjl45Ph tBqgV0ozfh2+o2ADw6KnAAer22Mf9wEem7yYUAN0jBZl4lEn0acgPz7fPKAlNYWW4kf36ilS J6NS3P+4hY5qHPjN1QZAVqWgAjwe1hNMoyW4bWw8IodoI+64+yQiZ9EVgJv7/aTWo1W4+eRN HakBmo9bWl5R0VUW3Pr5R0I0MsKNj6Mco1T8dXA6xhfh9uk2OqrPwaPdV2Ozy3DT9eHYXhN+ eekTfQaYgyrboGokqBoJqkauAfoWMMrljtxsXsgWhJJsQWwF0Zf68gCc6ikMAcQALgmmW9li NoE/IFeUh8AWRsOlwn5BQcYSr1Dh5GXnXingFmUuBW7yKBjO4JKAu4xbAJcZTMWsZYbKAdnn 2u/yBuS9AckdApihlNEqJxkV+IpKUfJGDUMgjaE5Czz76EgRixy8XywTRZ8oxbsCw6DejmeX gZX2eD0ih2ET2W+SRId4sNTl9seliscal9JB6k4k3GLYRMJZ1Y3/82kYfQhsZpKUkPWR+2Qf Xy67HDHvZJhKaFKcRnznwym94muOw9meXWC71QIlMoaIwhnwzGS1muFHEmmOqkEsrYtglc9Y zM5V8dmuQ2Cj8lzJsCgSR/n3/mVkYQaBiTEYiTgPziF7UmPsf6/NyjunwG6vkRzs5/3qg0+T IElxGju4lkBzHM62sx4GYm7l8wJN4fufKxemm16HLz3oXF9XdLk6f7RyT+Ghp9smE3fuqtqe 1eFZYamp21fgyDNnFKzQ3UhP23Shc9A7/JArfDHvV6g768+Gjtu93vYNGbYdJ0ZewtbFJt2k rjnckzg2Xmva0QVyvsl9md/tXSury5zn7vyZcHca66f5o/pOjpadfG4mJcn8X11kjJGeBAAA Archived-At: Cc: Barry Leiba Subject: Re: [urn] URNbis working group session is postponed to a conference call within a few weeks 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, 25 Mar 2015 08:18:53 -0000 On Tuesday, March 24, 2015 7:49 PM, John wrote: > --On Tuesday, March 24, 2015 10:58 -0600 Peter Saint-Andre - > &yet wrote: >=20 > >> The document authors think this is wise because most of the > >> key people will have trouble attending, even remotely, on > >> Thursday, and because they think they can be better ready for > >> a meeting if they have a chance to work out another revision > >> of the documents first. The chairs (and I) agree. > > > > Yes, John and I are committed to submitting a revised I-D by > > March 31. >=20 > Note that this means that anyone who has comments, especially on > the questions raised in the most recent 2141bis and on-list, > should get them posted to the list as soon as possible if you > have not done so already. Peter and I have not discussed > specific cutoffs, but comments posted before this Friday (27 > March) are a lot more likely to be discussed as needed and > reflected in the document than ones that appear as we are > finishing things up. I shall send my comments to the list either later today or tomorrow. Best, Lars=20 From nobody Wed Mar 25 01:20:10 2015 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 36C561ACE1B for ; Wed, 25 Mar 2015 01:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 hE9eepzJl7EL for ; Wed, 25 Mar 2015 01:20:05 -0700 (PDT) Received: from APAC01-HK1-obe.outbound.protection.outlook.com (mail-hk1on0135.outbound.protection.outlook.com [134.170.140.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549B91ACE14 for ; Wed, 25 Mar 2015 01:20:05 -0700 (PDT) Received: from [133.2.151.117] (133.2.151.117) by OS1PR01MB0072.jpnprd01.prod.outlook.com (25.161.230.13) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 25 Mar 2015 08:20:02 +0000 Message-ID: <55126FAE.7080103@it.aoyama.ac.jp> Date: Wed, 25 Mar 2015 17:19:58 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John C Klensin , Peter Saint-Andre - &yet , References: <551197A8.90602@andyet.net> <359F73CA2C48E17B745369A5@JcK-HP8200.jck.com> <55122649.4060504@it.aoyama.ac.jp> <55D1A520FB2FC3AC00CFC913@JcK-HP8200.jck.com> In-Reply-To: <55D1A520FB2FC3AC00CFC913@JcK-HP8200.jck.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.151.117] X-ClientProxiedBy: KAWPR01CA0015.jpnprd01.prod.outlook.com (25.161.24.25) To OS1PR01MB0072.jpnprd01.prod.outlook.com (25.161.230.13) Authentication-Results: computer.org; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS1PR01MB0072; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(6049001)(30513003)(24454002)(479174004)(51704005)(46034005)(122386002)(33656002)(87976001)(59896002)(83506001)(19580395003)(19580405001)(80316001)(40100003)(42186005)(2950100001)(23676002)(85182001)(92566002)(46102003)(74482002)(99136001)(77156002)(62966003)(54356999)(87266999)(50986999)(76176999)(65816999)(64126003)(65956001)(47776003)(66066001)(65806001)(85202003)(86362001)(50466002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS1PR01MB0072; H:[133.2.151.117]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5002010)(5005006); SRVR:OS1PR01MB0072; BCL:0; PCL:0; RULEID:; SRVR:OS1PR01MB0072; X-Forefront-PRVS: 052670E5A4 X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Mar 2015 08:20:02.6125 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS1PR01MB0072 Archived-At: Cc: Barry Leiba Subject: Re: [urn] URNbis working group session is postponed to a conference call within a few weeks 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, 25 Mar 2015 08:20:08 -0000 On 2015/03/25 12:24, John C Klensin wrote: > --On Wednesday, March 25, 2015 12:06 +0900 "\"Martin J. > Dürst\"" wrote: > >> On 2015/03/25 03:49, John C Klensin wrote: >> >>> Anyone who needs time to post such comments should note that >>> we just gave you back two hours of this Thursday :-( >> >> Strictly speaking, that only applies to those who planned to >> attend (in person or remotely :-). > > Yes. But I assumed that everyone participating was so > interested and dedicated that they expected to attend one way or > the other :-) I have lots of delusions of that sort. :-) :-) The meeting would be 02:00-04:00 (am) here in Tokyo. I could put some headphone plugs into my ears to pretend that I'm listening, but my brain wouldn't be awake (sorry!), even if during my daytime, I'm quite interested in the work of the WG. Regards, Martin. From nobody Wed Mar 25 06:24:26 2015 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 CD00D1ACE9D for ; Wed, 25 Mar 2015 06:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 stWo7mnI9C9Q for ; Wed, 25 Mar 2015 06:24:22 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E3A1ACF07 for ; Wed, 25 Mar 2015 06:24:14 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YalI1-0005B4-LE; Wed, 25 Mar 2015 09:24:09 -0400 Date: Wed, 25 Mar 2015 09:24:04 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: <90F5E2412BCE2CE86D96642C@JcK-HP8200.jck.com> In-Reply-To: <5512442F.2040904@network-heretics.com> References: <551197A8.90602@andyet.net> <359F73CA2C48E17B745369A5@JcK-HP8200.jck.com> <55122649.4060504@it.aoyama.ac.jp> <55D1A520FB2FC3AC00CFC913@JcK-HP8200.jck.com> <55122E11.7030701@network-heretics.com> <55122F6B.9080403@gmail.com> <5512442F.2040904@network-heretics.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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] URNbis working group session is postponed to a conference call within a few weeks 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, 25 Mar 2015 13:24:25 -0000 --On Wednesday, March 25, 2015 01:14 -0400 Keith Moore wrote: >> I'm hopeful that we can have a very effective virtual interim >> in early-to-mid April, but we need for people who have >> concerns about the documents to show up. I hope you'll be >> there. > > Melinda, > > the history of this WG in particular seems to be that the > people who have been driving it have been hostile not only to > input from people whom they deemed as "outsiders", but also > hostile to any URN functionality other than that which they > wanted, and in fact hostile to the primary intended purpose of > URNs. Keith, While I think there has certainly been some difficulty in different communities talking with each other and some resistance to the idea of URNs generally, I think I've been doing some of the driving, think I've been trying to bring "outsiders" (if by that you mean people in communities who are not normally active in the IETF) into the discussions, and have not only been open to new functionality but have been looking and pushing hard for what is needed to support it. So, from my perspective, the comment above is both incorrect and insulting. I do believe the WG has had problems with different communities of use and users having trouble talking with, and listening to, each other. That has slowed progress, but I believe we are making progress. Similarly, I think we have spent too much time on relationships with 3986, some of that possibly complicated by people who don't like the idea of URNs and would like to kill them by forcing them into a narrow, locator-oriented, box. Those are just personal opinions and I'm not pointing any fingers. But I don't think advocates of either position are either a majority of the WG or "driving the WG". Maybe "driving" a few of us nuts occasionally, but that is a different issue that may go more to the patience of those who are being thus driven than to any evil intentions. As far as I can tell, almost everyone who has been participating actively wants the effort to succeed and sincerely wants to be sure their particular needs and perspectives are represented. One may disagree with some of them (as I often have), but I don't think any of it rises (or falls) to a level that would justify your comments above. I do believe that one of our problems is that, even if one excludes those who don't like the idea of URNs, different participants have different views as to the "primary intended purpose" of URNs. I have personally wished on several occasions that I had tried harder 20 years ago to force enough of typology of what are now URNs to give us a few different URI schemes with different properties. For example, it appears to me that our work would be easier today if pure names that didn't resolve at all, names whose resolution was tied to DDDS, and at least one category of names that resolved in some other way or through some other mechanisms were each associated with a separate scheme. However, even if I'm right (and I may not be), it is much too late now and I (and, AFAICT, most others here, at least most days) are trying to work to make the best of what we have. I think that, if you think there is a "primary intended purpose" from which the WG is departing in some pathological way, it would be very helpful if you posted a short and clear description of that purpose to the list (or, if more detail is needed, in an I-D) and do it soon. Such a statement would be most useful if coupled with a clear statement about what you think should be done, but even the description alone would be helpful, at least to me. I think there is still an opportunity to change people's thinking or at least to have other perspectives reflected in the documents. But it also seems to me that, precisely because progress is being made, we are running out of time for that kind of input. As you certainly know from your time as an AD, a response to Last Call comments of "complained a lot, never could be pinned down to specifics of his concerns and details of what changes he thought were needed" would not get those comments much of a hearing. best, john From nobody Wed Mar 25 08:39:55 2015 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 BC9151B2A62 for ; Wed, 25 Mar 2015 08:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] 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 uAF6Fvvccc84 for ; Wed, 25 Mar 2015 08:39:51 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1B01B2A5D for ; Wed, 25 Mar 2015 08:39:50 -0700 (PDT) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 990988AF6F for ; Wed, 25 Mar 2015 16:39:49 +0100 (CET) X-AuditID: 0a453fe7-f79106d0000047dd-18-5512d6c5777f Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id B2.B0.18397.5C6D2155; Wed, 25 Mar 2015 16:39:49 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Wed, 25 Mar 2015 16:39:49 +0100 From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: [urn] URI contexts (CREF9) Thread-Index: AQHQYjX0lbV/NuCUZ0CWR6sYWZayJJ0q+LUQ///wb4CAAnYMUA== Date: Wed, 25 Mar 2015 15:39:48 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFFAC922FA@dnbf-ex1.AD.DDB.DE> References: <5500F64F.8090508@andyet.net> <550ACCEA.9040204@andyet.net> <48E0F5BA7AB03B3AE91FEAF2@JcK-HP8200.jck.com> <5510D310.2020203@andyet.net> <5510D41B.5060508@andyet.net> In-Reply-To: <5510D41B.5060508@andyet.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.158] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12TbUhTURzGO3dTr2tn3l3ddpoZejF6kdSgD0HSG0kKWoIJJUFe282NTbfu 3UIDQV1ETNL8kNKIslpGomVmqCUWkzLDLCyLKHqhmjgh60P0inbP7mZXv/3v7znPc54/h0sq 6JcxRtJS4eT4CtbGRKuUquwt39fdf0EXZd7sTd542v2V2ApyfL5fRAEoVmWZOJvlCMdnbC5R mYNn3xCOd0mVPyf6FTXgnMEDYklEbUCvhy4S0qxHT99ej/YAFUlTQwBdujYc/ugFaMDjjvKA GDKaWotmzPh8ApWCBgN1MR5AkvHUKjRbmyrh1eiW2xslzdtRQ+NxBZ6V1Er0cOBbaIZULmoP vCGk9HoCNX/wR2MhVky/N/gK4BlQSair60nIoKAMqDvwI0rqSSHfgMQRpUNTH2fDPBndm+1X Sucz0czY+bA3DbVdmA5frEUjZz4pTwGdVxbrlVm8MotXZmkFynagEcrL1qezpnSTqTTdxHUD 6QUm+0DD+A4/oEjAqOFoJ11ER7FHhKpyP9hNEowO3h0VkabUbqoys4L5AO+ycQKTAOkJEcN5 XOqyWZkVME2lLaIN81RwCQ7LQYvdJRxw8TY/QKRCtPZ3Y6uJrTrK8XYp0A8SSSVjgE13avfQ VBnr5Kwc5+D4iLqXJBkEG/CdWp4r4yoPWWzOiCz6do2LCiVXQoVSYBsuZJQLizsRZKwf5JFq sVhlaCfBwZYLlrJwdjxMfC5SdYSGcpPg31gxVx+BCzMfgUKjARbiMAqfMLsq5rsa9fADrhQn E3CkMRlWOzRF9DIZX5gaBLniE8VDO85Vi//R/4403I/h0jAMVVwO4/A9ujBbnJUnvm0CHLNr 8MJO1ilfuBEXUUdoeOF6DPURuDDOWAOG1xz8fREwn6/4+GL9cPblmBrtXE9rEDw8oZwCx75/ Dt7Q3OYGbbVJJ3Ma3XVM4swst0R3td515937VOvwVN+P/Ja0jjmQ/2VTy7Pf1Wk5+au3T5Kd BRtKDjdlPHl5Mquv5HKPe8TaoQ182ze060Gw2enbZu0gpne6Rh5b/tRXMUrBzK5fq+AF9h+m zyM/agQAAA== Archived-At: Subject: Re: [urn] URI contexts (CREF9) 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, 25 Mar 2015 15:39:53 -0000 On Tuesday, March 24, 2015 4:04 AM, Peter wrote: > To: John C Klensin; Henry S. Thompson > Cc: urn@ietf.org > Subject: Re: [urn] URI contexts (CREF9) >=20 > On 3/23/15 8:59 PM, Peter Saint-Andre - &yet wrote: > > On 3/19/15 12:42 PM, John C Klensin wrote: > >> > >> > >> --On Thursday, March 19, 2015 17:24 +0000 "Henry S. Thompson" > >> wrote: > >> > >>> I have been assuming this para. is here to address concerns > >>> about the appropriateness of e.g. constitutionally > >>> unresolvable URNs appearing in retrieval-expected slots. > >>> Being constitutionally unresolvable is a property of URNs from > >>> URN namespaces whose constitution makes that a requirement. > >>> Surely it follows that the right place for advice about > >>> appropriate contexts of use then is in that constitution, > >>> where you can say "So, don't use these in contexts that imply > >>> retrieval, e.g. HTTP GET or anywhere that might result in HTTP > >>> GET". > >>> > >>> It feels impractical to the point of inviting consternation > >>> from our readers to suggest, as I think I understand your > >>> reply above, that _every possible_ context of use of should > >>> note that you shouldn't put constitutionally-unresolvable URNs > >>> there. > >> > >> My response, not Peter's (I have no idea whether we agree on the > >> details at this level or note): > >> > >> I agree with the above, > > > > Probably the clause "or URNs created within particular URN namespaces" > > is confusing. I don't want to forestall the use of URNs from some > > particular (perhaps future) URN namespace from being appropriate for us= e > > in individual URI protocol slots, but it's likely best to leave out suc= h > > future-proofing text at this time. > > > >> but there is another side of this, which > >> is that there should not be statements in docs that define URI > >> references that say, e.g., "every URI is usable in the context > >> of ". The statements in those places really need to > >> either be a little more equivocal or to confine themselves to > >> URIs where they know what they are talking about. > > > > Agreed. It might not be appropriate to put a 'data' or 'iax' or 'info' > > or 'tag' URI in the 'xml:base' attribute, and it's the responsbility of > > the XML-BASE spec to say what's appropriate there. >=20 > Would the following text be agreeable? >=20 > Because a URN is, syntactically, a URI under the "urn" scheme, in > theory a URN can be placed in any protocol slot that allows for a URI > (e.g., the 'href' and 'src' attributes in HTML, the element > in HTML, the 'xml:base' attribute in XML [XML-BASE], and the 'xmlns' > attribute in XML for XML namespace names [XML-NAMES]). However, this > does not imply that, semantically, it always makes sense in practice > to place a URN in a given URI protocol slot; in particular, because a > URN might not specify the location of a resource or even point > indirectly to one, it might not be appropriate to place a URN in a > URI protocol slot that points to a resource (e.g., the aforementioned > 'href' and 'src' attributes). Ultimately, guidelines regarding when > it is appropriate to use URIs under the "urn" scheme (or any other > scheme) are the responsibility of specifications for individual URI > protocol slots (e.g., the specification for the 'xml:base' attribute > in XML might recommend that it is inappropriate to use URNs in that > protocol slot). This specification cannot possibly anticipate all of > the relevant cases, and it is not the place of this specification to > legislate usage for individual protocol slots. Works for me. Best, Lars=20 From nobody Wed Mar 25 08:51:42 2015 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 00B7B1A879F for ; Wed, 25 Mar 2015 08:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] 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 y600j0LCclWP for ; Wed, 25 Mar 2015 08:51:39 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 43C3B1B2A86 for ; Wed, 25 Mar 2015 08:51:37 -0700 (PDT) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 986F58B125; Wed, 25 Mar 2015 16:51:36 +0100 (CET) X-AuditID: 0a453fe7-f79106d0000047dd-75-5512d988592b Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id 5F.B0.18397.889D2155; Wed, 25 Mar 2015 16:51:36 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Wed, 25 Mar 2015 16:51:36 +0100 From: "Svensson, Lars" To: Peter Saint-Andre - &yet , John C Klensin , "Henry S. Thompson" , "urn@ietf.org" Thread-Topic: [urn] Case normalization (CREF 6) Thread-Index: AQHQZoX/P8riijFtwE68Q1HdkbLCiZ0tWecg Date: Wed, 25 Mar 2015 15:51:35 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFFAC92381@dnbf-ex1.AD.DDB.DE> References: <5510DBBC.7060606@andyet.net> <5511EC02.4020209@andyet.net> In-Reply-To: <5511EC02.4020209@andyet.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.158] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12Ta0hTYRjHeXfO5nHtXcej295WxjxZH4rULMwPXSnJMiqiQfYhO7bTtprb 2NlMo8ASQQy6C7VuNoekdLGBlalUS+jCMjFIpbIrRVlpYEgR2Xl3Njv27Tn///P8nv/Dy6EI ZizBSNmdXt7j5BysSk2q85b+mFvdz5izetvTch/371fkVvX8VuU+ettJ5NZWDiuWkfldL54l 5AeDPxX5gffNyvynjYPEBnKLepGFd9hLeU/mkm1qWyS83h0hy0LDl4gKECZqQCKF6AUoFGkD Uq1H3QNXVTVATTH0PYBu3W8hpY8bAF0ceamsAQmUip6Nhmy4P4U+C1CTPw/XyXQG6vn0i5T0 TPTqzReRSYl1Nrp2fB0uSXomeh5Q4Q5Ir0Z1nbUJEjwA0LHPHQpsJIrw120D0SZAp6Lm5ifR mARtQKEPo0opJo2C7U9i8XXo07s/Md2E7vxpJaX+LDTUdT42Owc1XBgkpMVJ6OGp9+QRoPPL sH7ZiF824peN1AGyCWiFEuu8DM6SYbEUZ1j4EJBe5+NNcKhnZRjQFGA1MHKZMTNKrlQoLwmD 9ZSC1cHbEVHSFrss5TZOsBV5fA5eYFNgc68ow3G52OfYxU6Hc9RJZsYwrgo+wW3fbnf5hCKf xxEGiCLE0dYQHrVw5Xt4j0sChsFUimQN8Gjb/k0MbeW8/C6ed/OeuLuZolgED+CdSR7eypft sDu8cVucG8EOLXeigdJgAw5klBv/Z1JQiWGwltKIwe724WCCmysR7NYYOxkGMFsTV6PcVPg7 UeTq4+JE5iNQRL04MRZQMKTT5eSNBrgAg2ncbfM5x3Mb9fANjjdZZmC80QT3ubVmZopMn7jh M1gtPlcy7MBcjfi//cvLwEs476SYGI07DU7Ge3Qx7X/WWvGdU2CXS4uP93Je+fGHcRBNXI0d fxCL+rg4EWesAGm7I0tMD9Kr6RlXyvK+XbWXlnvb92a/GzEUrlqxeEehUDGcfSazs+duwZHT OQV9s5aPnHuZmrkwvbIBTrlzvXQ+6eetexrt9YO2Vi0bfBvMGWiE3/WtLcOPz53p6uhUVp+s rTNPnesc6v7aZNo4a6+uarQl27S1v7K+auea+kn8GEsKNm7ebMIjcH8BWNIeuJIEAAA= Archived-At: Subject: Re: [urn] Case normalization (CREF 6) 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, 25 Mar 2015 15:51:41 -0000 On Tuesday, March 24, 2015 11:58 PM, Peter wrote: [...] > >> I think that what you propose here is fine (since we're > >> talking about URIs), but as always in matters of > >> internationalization I prefer to be especially careful, so I > >> was hedging my bets in the email that you referenced. > > > > See above. If we are relying on "have to be expressed in ASCII" > > that is fine with me but I think the document needs to remind > > people of that at critical points. >=20 > Yes, I will look for some places in the document to say this loud and cle= ar. +1 /Lars From nobody Wed Mar 25 09:09:37 2015 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 E2B271A88B3 for ; Wed, 25 Mar 2015 09:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 MPegnB0g-6SE for ; Wed, 25 Mar 2015 09:09:26 -0700 (PDT) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A92A1B2A9D for ; Wed, 25 Mar 2015 09:07:57 -0700 (PDT) Received: by igcau2 with SMTP id au2so105426769igc.0 for ; Wed, 25 Mar 2015 09:07:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dKwef0TrUzQB5z+P1TfbfczY3536ZJ0JU9luVKleLuI=; b=YNGRv0svRLOOtuXEYmb5gEYWMQEPvoMA6xZhTSOwgRWMs0lza+iw4ml+QQj0m6fl3E LSvHDLsnT8VJ/Rem1c3Lng7KlfXHYx5Cv9FxVrL+JMHUnkFZCVQmbFwKzXZ8LgFlKHJi 2ht9+oL9qi6dkjLtCFetGJv3Bo5CuzKArQR/NAnmLkh6gHxM0TU6AbNqXHKAjlw85UHF TTnC70hpSYLbm63kJ/HI/y9n9ZVI5WAFQNcVtT7X/R/DwJIi9OPHg0WkgB4x1D8aI36Q V3ZydcpXUKUzJ1yTANYuVYMi91Jzum6BKejeY8cViRI++tN0+RXu+H5bsn3f9/l0xs8G 0rQw== X-Gm-Message-State: ALoCoQkCpx29BIF/YoBKNxprrZ8Q6icQC2ZnKioE9eMedjaPKWuohhmV9F5MXGW/4ssu6vzYTzfQ X-Received: by 10.43.14.199 with SMTP id pr7mr32800214icb.3.1427299677051; Wed, 25 Mar 2015 09:07:57 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id k4sm1803268igf.0.2015.03.25.09.07.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2015 09:07:56 -0700 (PDT) Message-ID: <5512DD5A.9060002@andyet.net> Date: Wed, 25 Mar 2015 10:07:54 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Svensson, Lars" , John C Klensin , "urn@ietf.org" References: <551197A8.90602@andyet.net> <359F73CA2C48E17B745369A5@JcK-HP8200.jck.com> <24637769D123E644A105A0AF0E1F92EFFAC8FD86@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFFAC8FD86@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Barry Leiba Subject: Re: [urn] URNbis working group session is postponed to a conference call within a few weeks 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, 25 Mar 2015 16:09:33 -0000 On 3/25/15 2:18 AM, Svensson, Lars wrote: > On Tuesday, March 24, 2015 7:49 PM, John wrote: > >> --On Tuesday, March 24, 2015 10:58 -0600 Peter Saint-Andre - >> &yet wrote: >> >>>> The document authors think this is wise because most of the >>>> key people will have trouble attending, even remotely, on >>>> Thursday, and because they think they can be better ready for >>>> a meeting if they have a chance to work out another revision >>>> of the documents first. The chairs (and I) agree. >>> >>> Yes, John and I are committed to submitting a revised I-D by >>> March 31. >> >> Note that this means that anyone who has comments, especially on >> the questions raised in the most recent 2141bis and on-list, >> should get them posted to the list as soon as possible if you >> have not done so already. Peter and I have not discussed >> specific cutoffs, but comments posted before this Friday (27 >> March) are a lot more likely to be discussed as needed and >> reflected in the document than ones that appear as we are >> finishing things up. > > I shall send my comments to the list either later today or tomorrow. Thank you, Lars - I appreciate your participation! Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Mar 25 09:24:16 2015 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 C695A1A894A for ; Wed, 25 Mar 2015 09:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.95 X-Spam-Level: X-Spam-Status: No, score=-5.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5] 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 1zY6LOzr2_Zp for ; Wed, 25 Mar 2015 09:24:12 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 397EB1A8930 for ; Wed, 25 Mar 2015 09:24:12 -0700 (PDT) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 910688B148 for ; Wed, 25 Mar 2015 17:24:11 +0100 (CET) X-AuditID: 0a453fe7-f79106d0000047dd-fb-5512e12bff44 Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id D2.D0.18397.B21E2155; Wed, 25 Mar 2015 17:24:11 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Wed, 25 Mar 2015 17:24:10 +0100 From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10 Thread-Index: AdBf5EXxmQCfXUbTSausW6Ov9qCjfgAbn+CAABcUiFAAOOI9AAFgPrqA Date: Wed, 25 Mar 2015 16:24:10 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFFAC923DC@dnbf-ex1.AD.DDB.DE> References: <24637769D123E644A105A0AF0E1F92EFFAC84913@dnbf-ex1.AD.DDB.DE> <55079325.1010300@andyet.net> <24637769D123E644A105A0AF0E1F92EFFAC85A6E@dnbf-ex1.AD.DDB.DE> <5509ABC6.2040707@andyet.net> In-Reply-To: <5509ABC6.2040707@andyet.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.158] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12Te0hTURzHPXverZ11vD52XDZzUZCWFhkURUZvIeg5CP+o7tptG023djdz QVCbUV2hMnqOoJf0GFQSkY8e5JJCMY2KpD8yTdOKShmG9MC6Z3fT6X8/Pr/7/Zzv2WGUlH6j 1FP2Ug/rLmUcRoVapl5V+HNObjdtmsvzmQtPBwYly8Da6upfkg2gWL3EwjrsZaw7f+kOte32 5w6lq2lz+clPfuUBULORBxSFUQF+8TaZByphTMcvO+8oeKCmaPQU4ODpCCALGtUCPNKQwQMl pUA5eMBGaCrKxo/7/Eoyp6Dl+HqgQiryFXgk4peI82pcwQ/KySxDM3B9V2vUCFERrnzaKBeP agbYf/h5NKAS9P2DlxVkBmgqrqlpj0qlSIfv9g3LxZ4IVz8UOUZp+EvPSIxPw09G6mXkWlI0 C99pyBej2fhUZbdSPDcZN5/vlZ0AacEEa3AsEUxIBBMSl4AsBLRciXVeHmPJs1jMeRb2LhB/ /v46cOzVyjBAFDBqYOst2kTLmTLOVxIG6ymJMQ2quwSkNTstPhvD2ba7vQ6WM6bCR50ChqPY 7HXsNhpgrjrZROtGKeflXPaddqeX2+51O8IAU1Ih+u49iVoY3z7W7RSFYTCFkhl1sOrBwS00 sjIedjfLulh3fLuVoowYziBVkt2slS3fZXd44msh106UKHETLZQNr5FC+sTFxE4SShUG6yiN UExF/JBzMSWc3Rpzp8ArHQLVxGnUOxX+VQne9Dgc72wBm/U6KCMyRL6weUtHu+rTYTepNDlh QZT6aXC/S2uiMxL4eOtXUCQ8UQqs+kDqCH+isY40rCWvMSkGoxUz4WRyTlqMTXStE942FbY5 teTCHsaTeOHjpIgmTmMXriQwPQ7H6/QHQOjKvdD3fTMDdv5Be5315hHVv85NZr9DMxgZbllU 0Kt55v3d9jWrWLPnW9XPQ4UD3Fr9xwWGq2eHdMNzKl83Ti/QdOPIhUBbz9+B4g1/qisudS1e sOYclfTDc2Pv0LZIE90QUqb6tEf5JLOhMWg9ZTgzvzej+X5WfUH9bGXS0MU9RhlnY+blSN0c 8x/AiJw4ZwQAAA== Archived-At: Subject: Re: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10 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, 25 Mar 2015 16:24:15 -0000 QWxsLA0KDQpTb3JyeSBmb3IgY2F1c2luZyBtdWNoIGNvbmZ1c2lvbiwgSSBzaG91bGQgbWFrZSBj bGVhciB0aGF0IHdoYXQgSSBpbnRlbmRlZCB0byBzYXkgaGVyZSBpcyBfbm90IHNwZWNpZmljYWxs eSBhYm91dCBET0lzXywgYnV0IGFib3V0IHRoZSAocHJvcG9zZWQpIHAtY29tcG9uZW50LCB0aGUg TlNTIGFuZCB1cm4gY29tcGFyaXNvbiAobXkgdXNlIG9mIERPSSB3YXMgb25seSB0byBpbGx1c3Ry YXRlIG15IHBvaW50IGFuZCBvYnZpb3VzbHkgd2FzIG5vdCBoZWxwZnVsKS4gU3BlY2lmaWNzIGJl bG93Og0KDQpPbiBXZWRuZXNkYXksIE1hcmNoIDE4LCAyMDE1IDU6NDYgUE0sIFBldGVyIHdyb3Rl Og0KDQo+IFRvOiBTdmVuc3NvbiwgTGFyczsgdXJuQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBb dXJuXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXVybmJpcy1yZmMyMTQxYmlzLXVybi0xMA0KPiAN Cj4gT24gMy8xNy8xNSA3OjE2IEFNLCBTdmVuc3NvbiwgTGFycyB3cm90ZToNCj4gPiBEZWFyIFBl dGVyLA0KPiA+DQo+ID4gT24gVHVlc2RheSwgTWFyY2ggMTcsIDIwMTUgMzozNiBBTSwgUGV0ZXIg U2FpbnQtQW5kcmUgd3JvdGU6DQo+ID4NClsuLi5dDQo+ID4+IE9uIDMvMTYvMTUgNjoyNSBBTSwg U3ZlbnNzb24sIExhcnMgd3JvdGU6DQpbLi4uXQ0KPiA+Pj4gMSkgwqczIFVSTiBzeW50YXg6IEkg aGF2ZSBzb21lIGlzc3VlcyB3aXRoIHRoZSB1c2Ugb2YgcC1jb21wb25lbnQNCj4gPj4+IHZzLiBw ZXJjZW50LWVuY29kaW5nIG9mICIvIi4NCj4gPj4NCj4gPj4gQWx0aG91Z2ggSSBkb24ndCBjbGFp bSB0byBmdWxseSB1bmRlcnN0YW5kIHRoZSBET0kgbnVtYmVyaW5nDQo+ID4+IHN5c3RlbSAod2l0 aCByZWdhcmQgdG8gVVJOcywgU2VjdGlvbiAyLjYuMyBvZiB0aGUgRE9JIEhhbmRib29rIGlzDQo+ ID4+IGVzcGVjaWFsbHkgY29uZnVzaW5nIHRvIG1lIGJlY2F1c2UgaXQgaW1wbGllcyB0aGF0IGlu IGEgVVJOIHRoZQ0KPiA+PiBzbGFzaCBjb3VsZCBiZSByZXBsYWNlZCBieSBhIGNvbG9uKSwgbGV0 J3MgdGFrZSB5b3VyIGV4YW1wbGUgYXQNCj4gPj4gZmFjZSB2YWx1ZS4NCj4gPj4NCj4gPj4+IElm IEkgY3JlYXRlIGEgKHN1Yi0pbmFtZXNwYWNlIGZvciBET0kgKHVybjpleGFtcGxlOmRvaSkgYW5k IHdhbnQNCj4gPj4+IHRvIGNyZWF0ZSBhbiBpZGVudGlmaWVyIGZvciB0aGUgRE9JICIxMC4xMDA3 LzEwOTI5MTc5XzY1IiwgSQ0KPiA+Pj4gY291bGQgY2hvb3NlIGJldHdlZW4gKDEpICJ1cm46ZXhh bXBsZTpkb2k6MTAuMTAwNy8xMDkyOTE3OV82NSINCj4gPj4+IGFuZCAoMikgInVybjpleGFtcGxl OmRvaToxMC4xMDA3JTJGMTA5MjkxNzlfNjUiLg0KPiA+Pg0KPiA+PiBJJ20gY3VyaW91cyB0byBo ZWFyIHlvdXIgcmVhc29uaW5nIGFib3V0IHdoeSB3ZSB3b3VsZCB1c2UgYQ0KPiA+PiBwLWNvbXBv bmVudCB0byByZXByZXNlbnQgdGhlIGlkZW50aWZpZXIgKERPSSBzdWZmaXgpLiBJIGRvbid0IHRo aW5rDQo+ID4+IGl0J3Mgd3JvbmcsIGJ1dCBJIHRoaW5rIGl0IHdvdWxkIGhlbHBmdWwgdG8gZXhw bGFpbiB5b3VyIHJlYXNvbmluZw0KPiA+PiBvbiB0aGUgbGlzdC4NCj4gPg0KPiA+IEkgY2hvb3Nl IHRvIHVzZSBhIHAtY29tcG9uZW50IGJlY2F1c2UgSSBndWVzcyB0aGF0IG1vc3QNCj4gPiAobm9u LXRlY2huaWNhbCkgdXNlcnMgd2lsbCBzaW1wbHkgY29weSB0aGUgRE9JIGZyb20gdGhlIHNvbWV3 aGVyZSwNCj4gPiBwdXQgYSAodXJuLWJhc2VkKSBwcmVmaXggaW4gZnJvbnQgb2YgaXQgYW5kIHRo aW5rIHRoZXkgYXJlIGRvbmUuDQo+IA0KPiBCdXQgbm9uLXRlY2huaWNhbCB1c2VycyBhcmVuJ3Qg Y3JlYXRpbmcgVVJOcy4NCg0KSSBmZWFyIHRoYXQgaW4gc29tZSBjYXNlcyB0aGV5IHdpbGwuIE9y Z2FuaXNhdGlvbnMgdGhhdCB3YW50IHRvIHByb21vdGUgdGhlIHVzZSBvZiBzcGVjaWZpYyBpZGVu dGlmaWVycyBvZnRlbiBtYXJrZXQgaXQgYXMgImp1c3QgdGFrZSAob3VyIGlkZW50aWZpZXIpIGFu ZCBwcmVmaXggaXQgd2l0aCAoc29tZSBwcmVmaXgpIGFuZCB5b3Ugd2lsbCBnZXQgYSBVUkkgdGhh dCB5b3UgY2FuIHVzZSAoaW4gc29tZSBhcHBsaWNhdGlvbiB0aGF0IGlzIGJlbmVmaWNpYWwgdG8g dGhlIG9yZ2FuaXNhdGlvbiBwcm9tb3RpbmcgdGhlIGlkZW50aWZpZXIpLiBET0kgY3VycmVudGx5 IGRvIHRoaXMgd2l0aCBodHRwOi8vZHguZG9pLm9yZy8gKyBET0kgaW4gb3JkZXIgdG8gZ2V0IGFu IGFjdGlvbmFibGUgaHR0cC1VUkkuIFdlIGFsc28gcHJvbW90ZSB1cm46aXNibiBieSBzYXlpbmcg InRha2UgeW91ciBpc2JuIChpbmNsdWRpbmcgZGFzaGVzKSBhbmQgcHV0ICd1cm46aXNibjonIGlu IGZyb250IG9mIGl0IGFuZCBpdCB3aWxsIGdpdmUgeW91IGEgVVJJIi4NCg0KPiA+IEkuDQo+ID4g ZS4gZ2l2ZW4gImRvaToxMC4xMDA3LzEwOTI5MTc5XzY1IiBhbmQgdGhlaXIga25vd2xlZGdlIHRo YXQgdGhlcmUgaXMNCj4gPiBhIHVybiBuYW1lc3BhY2UgInVybjpleGFtcGxlOmRvaSINCj4gDQo+ IEJ1dCBub24tdGVjaG5pY2FsIHVzZXJzIGRvbid0IGtub3cgYWJvdXQgVVJOcy4NCg0KSW4gbGli cmFyaWVzIGNvbmNlcm5lZCB3aXRoIGxvbmctdGVybSBwcmVzZXJ2YXRpb24gYW5kIGFjY2Vzcywg d2UgdHJ5IHRvIHRlYWNoIHRoZW0uDQoNCj4gPiB0aGV5IHdpbGwgY3JlYXRlDQo+ID4gInVybjpl eGFtcGxlOmRvaToxMC4xMDA3LzEwOTI5MTc5XzY1IiBieSBzaW1wbGUgc3RyaW5nIGNvbmNhdGVu YXRpb24uDQo+ID4gSXQgd2lsbCByZXF1aXJlIGEgc3Vic3RhbnRpYWwgYW1vdW50IG9mIGVkdWNh dGlvbiB0byBtYWtlIHBlb3BsZQ0KPiA+IHN1YnN0aXR1dGUgdGhlIHNsYXNoIGluIHRoZSBET0kg Zm9yIGEgY29sb24uDQo+IA0KPiBJJ2QgYXNzdW1lIHRoYXQgdGhlIEludGVybmF0aW9uYWwgRE9J IEZvdW5kYXRpb24gd291bGQgY3JlYXRlIHRoZXNlIFVSTnMuDQoNCkFuZCBvdGhlcnMgbWlnaHQg d2FudCB0byBmaWd1cmUgb3V0IHdoYXQgd291bGQgYmUgdGhlIFVSTiBmb3IgYSBnaXZlbiBpZGVu dGlmaWVyIChlLiBnLiBJU0JOIG9yIElTU04pLg0KDQo+IChBbmQgcmVtZW1iZXIgdGhpcyBpcyBq dXN0IGFuIGV4YW1wbGUgLSB3ZSBoYXZlIG5vIGlkZWEgaWYgdGhlIElERiBoYXMNCj4gYW55IHBs YW5zIHRvIHVzZSBVUk5zLiBCdXQgdGhlIHNhbWUgcmVhc29uaW5nIHdvdWxkIGFwcGx5IHRvIGFu eQ0KPiBzaW1pbGFybHkgc3RydWN0dXJlZCBpZGVudGlmaWVyIHN5c3RlbS4pDQo+IA0KPiA+PiBG dXJ0aGVyOiBhcmUgdGhlcmUgYWx0ZXJuYXRpdmUgcmVwcmVzZW50YXRpb25zPyBGb3IgZXhhbXBs ZSwgbWlnaHQNCj4gPj4gaXQgbWFrZSBzZW5zZSB0byByZXByZXNlbnQgdGhlIGNvbXBsZXRlIERP SSAocHJlZml4IGFuZCBzdWZmaXgpIGFzDQo+ID4+IGEgcC1jb21wb25lbnQ/IFN1Y2ggYXM6DQo+ ID4+DQo+ID4+IHVybjpleGFtcGxlOmRvaS8xMC4xMDA3LzEwOTI5MTc5XzY1DQo+ID4NCj4gPiBZ ZXMsIGZvciBET0lzIHRoYXQgd291bGQgYmUgYSBtdWNoIGJldHRlciBpZGVhLg0KPiANCj4gU28s IGlmIHRoZSBJREYgcmVnaXN0ZXJzIGEgVVJOIG5hbWVzcGFjZSwgd2UnZCBlbmNvdXJhZ2UgdGhl bSB0byBkbyB0aGUNCj4gcmlnaHQgdGhpbmcgcmVnYXJkaW5nIHRoZSBwLWNvbXBvbmVudC4NCj4g DQo+ID4gTXkgcG9pbnQgaXMsIGhvd2V2ZXIsIHRoYXQgd2hlbiBub24tdGVjaG5pY2FsIHVzZXJz IGNyZWF0ZSB1cm5zIGp1c3QNCj4gPiBhZGRpbmcgYSBwcmVmaXggdG8gYW4gZXhpc3RpbmcgaWRl bnRpZmllciwNCj4gDQo+IEkgcXVlc3Rpb24gbWFueSBhc3N1bXB0aW9ucyBpbiB0aGF0IHBhcnQg b2YgeW91ciBzZW50ZW5jZS4gOi0pDQo+IA0KPiA+IHdlIHNob3VsZCBtYWtlIHN1cmUgdGhhdA0K PiA+IHRoaW5ncyB3b3JrIGFzIGludHVpdGl2ZWx5IGFzIHBvc3NpYmxlLiBTaW5jZSAyMTQxYmlz IGFsbG93cyB0aGUgIi8iDQo+ID4gaW4gdGhlIHN5bnRheCwgYSBnZW5lcmljIFVSTiBwYXJzZXIg d2lsbCBhY2NlcHQgIg0KPiA+IHVybjpleGFtcGxlOmRvaToxMC4xMDA3LzEwOTI5MTc5XzY1IiAo b3IgYW55IG90aGVyIFVSTiBjcmVhdGVkIGZyb20NCj4gPiBhbiBpZGVudGlmaWVyIHdpdGggYSAi LyIgaW4gaXQpIGFzIGEgdmFsaWQgVVJOLiBJIHJlYWxpc2UgdGhhdCB0aGlzDQo+ID4gbWlnaHQg YWxzbyBiZSB0aGUgY2FzZSBmb3Igb3RoZXIgY2hhcmFjdGVycyB3aXRoIHNwZWNpYWwgbWVhbmlu ZywgYnV0DQo+ID4gSSBhbHNvIHRoaW5rIHRoYXQgdGhlICIvIiBjaGFyYWN0ZXIgd2lsbCBiZSBt b3JlIGNvbmZ1c2luZyB0bw0KPiA+IGltcGxlbWVudGVycyBhbmQgdXNlcnMgc2luY2UgaXQncyBt b3JlIGNvbW1vbmx5IHVzZWQgYXMgYSBkZWxpbWl0ZXINCj4gPiB0aGFuIGUuIGcuICJAIi4NCj4g DQo+IElmIHdlJ3JlIGdvaW5nIHRvIHJldXNlIFVSSSBzeW50YXgsIHRoZW4gIi8iIGlzIHdoYXQg d2UgaGF2ZSBhcyBhDQo+IGRlbGltaXRlciBiZXR3ZWVuIHRoZSBhdXRob3JpdHkgYW5kIHRoZSBw LWNvbXBvbmVudC4gQXJlIHlvdSBzdWdnZXN0aW5nDQo+IHRoYXQgd2UgZGl2ZXJnZSBmcm9tIFVS SSBzeW50YXg/DQo+IA0KPiA+Pj4gSW4gdGhlIHN5bnRheCBkZWZpbmVkIGJ5IDIxNDFiaXMsIHRo ZSBmaXJzdCBvbmUgdXNlcyBOU1MgKw0KPiA+Pj4gcC1jb21wb25lbnQsIHRoZSBzZWNvbmQgb25l IHB1dHMgdGhlIGNvbXBsZXRlIERPSSBpbiB0aGUgTlNTLg0KPiA+Pg0KPiA+PiBBcyBmYXIgYXMg SSB1bmRlcnN0YW5kIHRoaW5ncywgcHV0dGluZyB0aGUgY29tcGxldGUgRE9JIGluIHRoZQ0KPiA+ PiBwLWNvbXBvbmVudCBtYWtlcyB0aGUgbW9zdCBzZW5zZSAob3B0aW9uIDMpLg0KPiA+DQo+ID4g QWdyZWVkLg0KPiA+DQo+ID4+PiBUaGlzIGlzIHBvdGVudGlhbGx5IGNvbmZ1c2luZyBmb3IgY29u c3VtZXJzLCBzaW5jZSDCpzUgc2F5cyB0aGF0DQo+ID4+PiBbWyBbdXJuLWF3YXJlXSBhcHBsaWNh dGlvbnMgbWlnaHQgc3VwcG9ydCBkaXNwbGF5IG9mIFVSTnMgaW4gYQ0KPiA+Pj4gbW9yZSBodW1h bi1mcmllbmRseSBmb3JtIGFuZCBtaWdodCB1c2UgYSBjaGFyYWN0ZXIgc2V0IHRoYXQNCj4gPj4+ IGluY2x1ZGVzIGNoYXJhY3RlcnMgdGhhdCBhcmUgbm90IHBlcm1pdHRlZCBpbiBVUk4gc3ludGF4 IGFzDQo+ID4+PiBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbiAoZS5nLiwgd2hlbiBkaXNw bGF5aW5nIFVSTnMgdG8NCj4gPj4+IGh1bWFucywgc3VjaCBhcHBsaWNhdGlvbnMgbWlnaHQgcmVw bGFjZSBwZXJjZW50LWVuY29kZWQgc3RyaW5ncw0KPiA+Pj4gd2l0aCBjaGFyYWN0ZXJzIGZyb20g YW4gZXh0ZW5kZWQgY2hhcmFjdGVyIHJlcGVydG9pcmUgWy4uLl0pLiBdXQ0KPiA+Pg0KPiA+PiBJ IGFncmVlIHRoYXQgdXNpbmcgb3B0aW9uIDEgb3Igb3B0aW9uIDIgaXMgcG90ZW50aWFsbHkgY29u ZnVzaW5nLg0KPiA+Pg0KPiA+Pj4gVGhhdCBtZWFucyB0aGF0IGlmIEkgY2hvb3NlIG9wdGlvbiAo MikgKHB1dHRpbmcgdGhlIGNvbXBsZXRlIERPSQ0KPiA+Pj4gaW50byB0aGUgTlNTIHVzaW5nIHBl cmNlbnQtZW5jb2RpbmcpLCBhIGNvbmZvcm1pbmcgdXJuLWF3YXJlDQo+ID4+PiBhcHBsaWNhdGlv biBNVVNUIHNob3cgInVybjpleGFtcGxlOmRvaToxMC4xMDA3JTJGMTA5MjkxNzlfNjUiIGFuZA0K PiA+Pj4gTUFZIHNob3cgInVybjpleGFtcGxlOmRvaToxMC4xMDA3LzEwOTI5MTc5XzY1Ii4gVGhp cyBpcyBsaWtlbHkgdG8NCj4gPj4+IGJlIF92ZXJ5XyBjb25mdXNpbmcgdG8gc29tZSB1c2VycyBu b3QgYXdhcmUgb2YgdGhlIGRpZmZlcmVuY2UNCj4gPj4+IGJldHdlZW4gdGhlIHR3by4NCj4gPj4+ DQo+ID4+PiBJIHN1Z2dlc3QgdGhhdCB0aGUgcC1jb21wb25lbnQgaXMgaW5jb3Jwb3JhdGVkIGlu dG8gdGhlIE5TUzsgdGhpcw0KPiA+Pj4gaXMgbW9yZSBpbnR1aXRpdmUuDQo+ID4+DQo+ID4+IEVp dGhlciB0aGF0IG9yIGRvbid0IHNwbGl0IGFuIGlkZW50aWZpZXIgKGUuZy4sIGEgRE9JIG5hbWUp IGFjcm9zcw0KPiA+PiB0aGUgTlNTL3AtY29tcG9uZW50IGJvdW5kYXJ5Lg0KPiA+DQoNCltTa2lw cGluZyBzb21lIGRpc2N1c3Npb24gYWJvdXQgRE9JcyBhbmQgY29taW5nIHRvIHRoZSBwb2ludCBh Ym91dCB1cm4gY29tcGFyaXNvbiBhbmQgcC1jb21wb25lbnRdDQoNCj4gPiBSaWdodC4gTm9uZXRo ZWxlc3MgSSdkIGFyZ3VlIHRoYXQgaXQncyBtb3JlIGludHVpdGl2ZSB0aGF0IHRoZQ0KPiA+IHAt Y29tcG9uZW50IGlzIGluY29ycG9yYXRlZCBpbnRvIHRoZSBOU1MuIElmIHdlIHNheSB0aGF0IGEg VVJODQo+ID4gY29uc2lzdHMgb2Ygc2NoZW1hICsgTklEICsgTlNTICsgcC1jb21wb25lbnQgKCsg cS1jb21wb25lbnQgKw0KPiA+IGYtY29tcG9uZW50KSwgdGhpcyAoYXQgbGVhc3QgdG8gbWUpIGlu ZGljYXRlcyB0aGF0IHRoZSBwLWNvbXBvbmVudCBpcw0KPiA+IG5vdCBhIHJlYWwgcGFydCBvZiB0 aGUgbmFtZSwgYnV0IHNvbWV0aGluZyB0aGF0IGlzIGFkZGVkIHRvIGl0LiBXaGVuDQo+ID4gZGV0 ZXJtaW5pbmcgVVJOIGVxdWFsaXR5LCBob3dldmVyLCB0aGUgcC1jb21wb25lbnQgaXMgY29uc2lk ZXJlZC4gSXQNCj4gPiB3b3VsZCBiZSBtb3JlIGNvbnNpc3RlbnQgdG8gc2F5IHR3byBVUk5zIGFy ZSBlcXVpdmFsZW50IGlmZiBhbGwgcGFydHMNCj4gPiBvZiB0aGUgbmFtZSBhcmUgb2N0ZXQtYnkt b2N0ZXQgZXF1YWwgKG1vZHVsbyBub3JtYWxpc2F0aW9uKS4gVVJODQo+ID4gY29tcG9uZW50cyB0 aGF0IGFyZSBub3QgcGFydCBvZiB0aGUgbmFtZSAoaS4gZS4gcS1jb21wb25lbnQgYW5kDQo+ID4g Zi1jb21wb25lbnQpIGFyZSBub3QgY29uc2lkZXJlZCB3aGVuIGRldGVybWluaW5nIGVxdWFsaXR5 Lg0KDQpbUGV0ZXIgaGFkIGFuc3dlcmVkIHRvIHRoaXMgYnV0IGhpcyBhbnN3ZXIgaXMgbW9yZSBh Ym91dCB0aGUgc3ludGFjdGljIGFzcGVjdCBvZiB0aGUgcC1jb21wb25lbnQgYW5kIG5vdCBhYm91 dCBuYW1pbmcgYW5kIHVybiBjb21wYXJpc29uIHdoaWNoIGlzIHRoZSBwb2ludCBJJ20gZmFpbGlu ZyB0byBtYWtlLi4uXQ0KDQpJIHRyeSB0byByZWZvcm11bGF0ZSB3aGF0IGlzIG15IGNvbmNlcm46 DQoNClJpZ2h0IG5vdyB3ZSBoYXZlIHVybj1hc3NpZ25lZC1uYW1lICsgcC1jb21wb25lbnQgKCtx LWNvbXBvbmVudCArIGYtY29tcG9uZW50KSwgd2hlcmUgYXNzaWduZWQtbmFtZSA9ICd1cm4nICsg TklEICsgTlNTLiBUbyBtZSB0aGlzIGltcGxpZXMgdGhhdCBwLSwgcS0gYW5kIGYtY29tcG9uZW50 cyBhcmUgbm90IHBhcnQgb2YgdGhlIG5hbWUgYW5kIHRodXMgKG15IHJlYWRpbmcpIG5vdCByZWFs bHkgaWRlbnRpZnlpbmcgYW55dGhpbmcgKHNvcnQgb2Ygc2Vjb25kLWNsYXNzIGNpdGl6ZW5zKS4g VGhhdCBzZWVtcyBPSyBmb3IgcS0gYW5kIGYtY29tcG9uZW50cyBzaW5jZSB0aGV5IGFyZSBpZ25v cmVkIHdoZW4gd2UgZG8gdXJuIGNvbXBhcmlzb24uIEJ1dCB0byBtZSBpdCBzZWVtcyBjb3VudGVy LWludHVpdGl2ZSB0byBoYXZlIGEgcGFydCBvZiB0aGUgaWRlbnRpZmllciB0aGF0IGlzIG5vdCBy ZWxldmFudCBmb3IgdGhlIF9pZGVudGlmaWNhdGlvbl8gKG5vdCBwYXJ0IG9mIHRoZSBhc3NpZ25l ZCBuYW1lKSBidXQgbm9uZXRoZWxlc3MgbWF0dGVycyB3aGVuIGl0IGNvbWVzIHRvIF9jb21wYXJp c29uXy4gDQoNCkFtIEkgb3Zlci1pbnRlcnByZXRpbmcgdGhlIHVzZSBvZiAiYXNzaWduZWQtbmFt ZSIgdG8gbWVhbiB0aGF0IHRoZSByZXN0IG9mIHRoZSB1cm4gaXMgbm90IHBhcnQgb2YgdGhlIG5h bWUgYW5kIHRodXMgbm90IHBhcnQgb2YgdGhlIGlkZW50aWZpZXI/DQoNCkJlc3QsDQoNCkxhcnMN Cg== From nobody Wed Mar 25 18:42:47 2015 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 14DAD1A8986 for ; Wed, 25 Mar 2015 18:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 CztwinP7X3kH for ; Wed, 25 Mar 2015 18:42:44 -0700 (PDT) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0261A1A37 for ; Wed, 25 Mar 2015 18:42:44 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so36191647iec.2 for ; Wed, 25 Mar 2015 18:42:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=w7RIhuYFNl6Se1Nq1ZyWV5Dy3YzDKohT7rIjw6khktA=; b=eJyi9m/1s4o6y07GmUNCaMVhbuEgTHoj4md0H8nEiAEbZhyqSAOKmKSXIqkEzcLudW OKAXYkz2z9M2wQ0iznppjrGIKD4BLpuvFSx3aytFQY7weir9pVeG0NhFXwdwHaK6TBwt 3hPNE9zk9Xyty7ZCOzY7u6vjsvOE0Hge7hQyFiSe/47Xc3UcD1bufIJLokSwC0zVLqHs cIpVs6yom6vtkFHiqQJ/ONLmZywddS+l0xm8O+ObcoLfnnlL0wJSpp1nCizrXHDtJWwl WYfm6bd2vKOYgpqvg/n2JoVahXoTypOsPt/ijmD5Som+2wv73RmEwuNwc2n5xXt+g0jW VqJg== X-Gm-Message-State: ALoCoQlDcRRa2Gu88er+sEDyLEHlXyC/VCvgjuvpOVMM+B5+Ta3JHkjwtaUOgfeE8R0khFFSIqBx X-Received: by 10.107.3.164 with SMTP id e36mr17959663ioi.70.1427334163770; Wed, 25 Mar 2015 18:42:43 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id qd2sm11205920igc.22.2015.03.25.18.42.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2015 18:42:42 -0700 (PDT) Message-ID: <55136411.6060100@andyet.net> Date: Wed, 25 Mar 2015 19:42:41 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , "urn@ietf.org" References: <550102B3.2050308@andyet.net> In-Reply-To: <550102B3.2050308@andyet.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] URI interoperability considerations (CREF18) 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: Thu, 26 Mar 2015 01:42:46 -0000 On 3/11/15 9:06 PM, Peter Saint-Andre - &yet wrote: > Section 10.1 (which registers the 'urn' URI scheme) points to Section 5 > ("URI Conformance") regarding interoperability considerations with > regard to URIs. > > CREF18 suggests that more text is needed here, possibly along the lines > of what Juha posted on January 13: > > "If interoperability concerns arise during the registration of a URN > namespace due to e.g. syntax or scope of an identifier system, they > should be resolved in the namespace registration request." > > I hesitate about this slightly, because Section 10.1 is about > registration of the 'urn' scheme, not registration of URN namespaces. > However, I do see that particular NIDs might be defined in such a way > they introduce concerns about interoperability at the URI level. > > It seems to me that a better way to handle this would be to add another > section to the namespace registration template so that we can get any > such issues out in the open during the registration process. I propose the following text to describe what a registrant needs to provide in the (new) "Interoperability" section of the template: The "Interoperability" section MUST specify any potential issues related to interoperability. Examples include possible confusion with other URN namespaces or naming systems because of syntax (e.g., percent-encoding of certain characters) or scope (e.g., overlapping areas of interest). Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Mar 26 00:09:00 2015 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 9C7081ACDD1 for ; Thu, 26 Mar 2015 00:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 85tbPCqkHBKc for ; Thu, 26 Mar 2015 00:08:55 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0786.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::786]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99EC71A7002 for ; Thu, 26 Mar 2015 00:08:53 -0700 (PDT) Received: from AM3PR07MB369.eurprd07.prod.outlook.com (10.242.109.143) by AM3PR07MB371.eurprd07.prod.outlook.com (10.242.109.150) with Microsoft SMTP Server (TLS) id 15.1.118.21; Thu, 26 Mar 2015 07:05:28 +0000 Received: from AM3PR07MB369.eurprd07.prod.outlook.com ([10.242.109.143]) by AM3PR07MB369.eurprd07.prod.outlook.com ([10.242.109.143]) with mapi id 15.01.0118.022; Thu, 26 Mar 2015 07:05:28 +0000 From: "Hakala, Juha E" To: "Svensson, Lars" , "urn@ietf.org" Thread-Topic: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10 Thread-Index: AdBf5EXxmQCfXUbTSausW6Ov9qCjfgAbn+CAABcUiFAAOOI9AAFgPrqAAB53G7w= Date: Thu, 26 Mar 2015 07:05:28 +0000 Message-ID: <1427353527416.72968@helsinki.fi> References: <24637769D123E644A105A0AF0E1F92EFFAC84913@dnbf-ex1.AD.DDB.DE> <55079325.1010300@andyet.net> <24637769D123E644A105A0AF0E1F92EFFAC85A6E@dnbf-ex1.AD.DDB.DE> <5509ABC6.2040707@andyet.net>, <24637769D123E644A105A0AF0E1F92EFFAC923DC@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFFAC923DC@dnbf-ex1.AD.DDB.DE> Accept-Language: fi-FI, en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.214.71.180] authentication-results: dnb.de; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB371; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(479174004)(24454002)(77096005)(40100003)(2656002)(77156002)(66066001)(87936001)(92566002)(62966003)(76176999)(19580405001)(50986999)(15395725005)(54356999)(19580395003)(122556002)(2900100001)(15975445007)(102836002)(230783001)(117636001)(2501003)(86362001)(93886004)(74482002)(46102003)(36756003)(2950100001)(107886001)(229853001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB371; H:AM3PR07MB369.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:AM3PR07MB371; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB371; x-forefront-prvs: 0527DFA348 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2015 07:05:28.1561 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB371 Archived-At: Subject: Re: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10 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: Thu, 26 Mar 2015 07:08:58 -0000 Hello, Some comments below.=20 ________________________________________ L=E4hett=E4j=E4: urn k=E4ytt=E4j=E4n puolestaSvenss= on, Lars L=E4hetetty: 25. maaliskuuta 2015 18:24 Vastaanottaja: urn@ietf.org Aihe: Re: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10 All, Sorry for causing much confusion, I should make clear that what I intended = to say here is _not specifically about DOIs_, but about the (proposed) p-co= mponent, the NSS and urn comparison (my use of DOI was only to illustrate m= y point and obviously was not helpful). Specifics below: On Wednesday, March 18, 2015 5:46 PM, Peter wrote: > To: Svensson, Lars; urn@ietf.org > Subject: Re: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10 > > On 3/17/15 7:16 AM, Svensson, Lars wrote: > >> Although I don't claim to fully understand the DOI numbering > >> system (with regard to URNs, Section 2.6.3 of the DOI Handbook is > >> especially confusing to me because it implies that in a URN the > >> slash could be replaced by a colon), let's take your example at > >> face value. Slash may appear in two different roles in Handles and DOIs: as a separator= between prefix and suffix, and as a character within the identifier string= . These two cases should receive different treatment when DOIs are converte= d to URNs. That is why the DOI Handbook section 2.6.3 says that:=20 "To enable the use of DOIs in workflows that have already standardized on U= RNs, the DOI proxy servers understand the substitution of a colon in place = of the initial slash in a DOI name. DOI names may therefore be expressed as= URNs in the doi.org domain by writing, for example, the DOI name 10.123/45= 6 in the form http://doi.org/urn:doi:10.123:456. Note, however, that a DOI = suffix is allowed to contain other slashes, and where these occur they must= be percent-encoded rather than replaced with a colon: for example, the DOI= name 10.123/456ABC/zyz would become http://doi.org/urn:doi:10.123:456ABC%2= Fzyz, with the final slash character encoded as %2F. " IMO it is best not to divert from this representation, which makes sense to= me. However, the example is theoretical since the namespace DOI has not be= en registered for the time being and the DOI community does not seem to hav= e much interest to do so.=20 > But non-technical users aren't creating URNs. Incorrect. In Finland graduating students often publish their master's thes= is in the Web. If they do that, they are asked to create metadata for their= work. The template which assists them in the process retrieves a URN:NBN w= hich is used as the identifier for the thesis.=20 So with the help of tools provided by the national library non-technical us= ers are minting thousands of URNs annually.=20 > But non-technical users don't know about URNs. Students and researchers may not know what URN is, but the importance of pe= rsistent identifiers in general is gradually becoming more apparent due to = increased usage of PIDs. Large percentage of research articles published in= electronic format receive them, and the same applies for research data set= s. On the other hand, increasing link rot has an impact on what people thi= nk about so called cool URIs. =20 About the usage and role of persistent identifiers in science, see for inst= ance=20 http://www.pidconsortium.eu/ > > they will create > > "urn:example:doi:10.1007/10929179_65" by simple string concatenation. > > It will require a substantial amount of education to make people > > substitute the slash in the DOI for a colon. > > I'd assume that the International DOI Foundation would create these URNs. As far as I know, IDF is not involved with this kind of practical work. =20 > And others might want to figure out what would be the URN for a given ide= ntifier (e. g. ISBN or ISSN). As an aside, it may not be trivial to restore an identifier in its pristine= form from within DOI / Handle string. You cannot assume that the DOI suffi= x =3D URN NSS. For instance for ISBN the recommendation is to put the publi= sher part of the ISBN to the DOI suffix. So ISBN 951-0-18435-7 should be re= presented as DOI 10.9510/184357.=20 > (And remember this is just an example - we have no idea if the IDF has > any plans to use URNs. But the same reasoning would apply to any > similarly structured identifier system.) There are no plans to represent any other persistent identifiers as URNs (o= r vice versa). ISBN can be presented both as DOI and as URN, and that makes= sense because the ISBN would then be resolved in two different resolution = services (DOI resolver maintained by the publisher and URN resolver maintai= ned by the national library, for instance). But there is no reason to stack= persistent identifiers on top of one another so that the resulting combo-P= ID needs to be resolved twice (for instance, URN containing a DOI first in = the national library's URN resolver in order to find the publisher's DOI re= solver which would then retrieve the actual document).=20 > > >> Further: are there alternative representations? For example, might > >> it make sense to represent the complete DOI (prefix and suffix) as > >> a p-component? Such as: > >> > >> urn:example:doi/10.1007/10929179_65 > > > > Yes, for DOIs that would be a much better idea. The best idea is to stick to what the DOI Handbook says.=20 All the best, Juha > > So, if the IDF registers a URN namespace, we'd encourage them to do the > right thing regarding the p-component. > > > My point is, however, that when non-technical users create urns just > > adding a prefix to an existing identifier, > > I question many assumptions in that part of your sentence. :-) > > > we should make sure that > > things work as intuitively as possible. Since 2141bis allows the "/" > > in the syntax, a generic URN parser will accept " > > urn:example:doi:10.1007/10929179_65" (or any other URN created from > > an identifier with a "/" in it) as a valid URN. I realise that this > > might also be the case for other characters with special meaning, but > > I also think that the "/" character will be more confusing to > > implementers and users since it's more commonly used as a delimiter > > than e. g. "@". > > If we're going to reuse URI syntax, then "/" is what we have as a > delimiter between the authority and the p-component. Are you suggesting > that we diverge from URI syntax? > > >>> In the syntax defined by 2141bis, the first one uses NSS + > >>> p-component, the second one puts the complete DOI in the NSS. > >> > >> As far as I understand things, putting the complete DOI in the > >> p-component makes the most sense (option 3). > > > > Agreed. > > > >>> This is potentially confusing for consumers, since =A75 says that > >>> [[ [urn-aware] applications might support display of URNs in a > >>> more human-friendly form and might use a character set that > >>> includes characters that are not permitted in URN syntax as > >>> defined in this specification (e.g., when displaying URNs to > >>> humans, such applications might replace percent-encoded strings > >>> with characters from an extended character repertoire [...]). ]] > >> > >> I agree that using option 1 or option 2 is potentially confusing. > >> > >>> That means that if I choose option (2) (putting the complete DOI > >>> into the NSS using percent-encoding), a conforming urn-aware > >>> application MUST show "urn:example:doi:10.1007%2F10929179_65" and > >>> MAY show "urn:example:doi:10.1007/10929179_65". This is likely to > >>> be _very_ confusing to some users not aware of the difference > >>> between the two. > >>> > >>> I suggest that the p-component is incorporated into the NSS; this > >>> is more intuitive. > >> > >> Either that or don't split an identifier (e.g., a DOI name) across > >> the NSS/p-component boundary. > > [Skipping some discussion about DOIs and coming to the point about urn comp= arison and p-component] > > Right. Nonetheless I'd argue that it's more intuitive that the > > p-component is incorporated into the NSS. If we say that a URN > > consists of schema + NID + NSS + p-component (+ q-component + > > f-component), this (at least to me) indicates that the p-component is > > not a real part of the name, but something that is added to it. When > > determining URN equality, however, the p-component is considered. It > > would be more consistent to say two URNs are equivalent iff all parts > > of the name are octet-by-octet equal (modulo normalisation). URN > > components that are not part of the name (i. e. q-component and > > f-component) are not considered when determining equality. [Peter had answered to this but his answer is more about the syntactic aspe= ct of the p-component and not about naming and urn comparison which is the = point I'm failing to make...] I try to reformulate what is my concern: Right now we have urn=3Dassigned-name + p-component (+q-component + f-compo= nent), where assigned-name =3D 'urn' + NID + NSS. To me this implies that p= -, q- and f-components are not part of the name and thus (my reading) not r= eally identifying anything (sort of second-class citizens). That seems OK f= or q- and f-components since they are ignored when we do urn comparison. Bu= t to me it seems counter-intuitive to have a part of the identifier that is= not relevant for the _identification_ (not part of the assigned name) but = nonetheless matters when it comes to _comparison_. Am I over-interpreting the use of "assigned-name" to mean that the rest of = the urn is not part of the name and thus not part of the identifier? Best, Lars _______________________________________________ urn mailing list urn@ietf.org https://www.ietf.org/mailman/listinfo/urn From nobody Thu Mar 26 08:58:33 2015 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 63CC41A876F for ; Thu, 26 Mar 2015 08:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no 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 ihb3Zn5WKLn3 for ; Thu, 26 Mar 2015 08:58:27 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0CC81A87A0 for ; Thu, 26 Mar 2015 08:58:27 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 15C02208DD for ; Thu, 26 Mar 2015 11:58:24 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 26 Mar 2015 11:58:26 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:content-type:content-transfer-encoding; s=smtpout; bh=4n7pwtcmF0p40Be1a+hy1j7tczc=; b=ngergZlruJOU/tdjg MmZvpPT6qoeX6BDEN/Ebqq0WEtIcaa/DpYRkTmqr3WNy0heJcNetNZRRW4du/OwG p0vEa+cSnr9VSgCcUx7dRdv0+Hk5Qi8/ZLPGpKOfQ3FuGCdz5wH/5CdTK7iRNllL YUYj7t+buBOzKviYf/LjZbzGnE= X-Sasl-enc: fE5/o+2P/2oI6O56Y+ZrNeNne9zrcUdea20zR4u9Te0I 1427385506 Received: from [31.133.132.58] (unknown [31.133.132.58]) by mail.messagingengine.com (Postfix) with ESMTPA id 7036168015E; Thu, 26 Mar 2015 11:58:26 -0400 (EDT) Message-ID: <55142CA1.2000509@network-heretics.com> Date: Thu, 26 Mar 2015 11:58:25 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: urn@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] Keith's review of draft-ietf-urnbis-rfc2141bis-urn-10 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: Thu, 26 Mar 2015 15:58:30 -0000 General summary: This version of the document has several serious technical omissions and errors that should, according to RFC 2026 criteria, prevent its publication as a standards-track document until those omissions and errors are remedied. Some of these omissions and errors appear to result from failure to consider use of URNs for their primary intended purpose of being identifiers for network-accessible resources. It's fine to use URNs to name resources that aren't network-accessible, but the URN specifications should not be compromised in such a way as to impair their use to name network-accessible resources, and this document imposes several such compromises. There are other choices reflected in the document that I think are poor technical choices that should be remedied, though they fall short of being "technical omissions" in the RFC 2026 sense. The document also reflects, in at least one case, a failure to resolve an identified technical issue, which RFC 2026 requires be resolved. Details: Broadly speaking, the document has the following problems (in no particular order): 1. Use of p-component in URNs combined with use of relative URIs with URN as the base URI. If relative URIs are permitted to be used with URNs, this has the potential to harm persistence of URNs unless there are constraints on how NSSs are assigned. If an NSS under a particular NID has no internal structure, maintaining persistence for every URN assigned under that NID is relatively simple - just don't ever reassign an NID to a different resource. But if the NSS does have structure that reflects relationships between resources, and those resources can ever be updated in a way that causes those relationships to need to change, there's a good chance that some combinations of base URNs + relative URIs that formerly resolved to valid URNs, will no longer resolve to valid URNs, or will resolve to URNs that don't have the same meaning/purpose as before. Thus there will be a significant temptation to change the meanings of existing URNs, i.e. to rebind existing URNs to different resources than before. There are lots of ways that a namespace can make relative URIs safe to use with its URNs. For example, if none of the resources named by a namespace are machine-parseable, there's no issue. Or if the resources under a namespace are constrained to never change at all, there's no issue. Or if NSSs are of the form x/y such that x is never reused (every new resource gets a unique x, and y is just used to differentiate between parts or facets of that resource), there's no issue. The problem is trying to write a general rule that permits use of p-components in an NSS and permits use of relative URIs with those URNs, in such a way that doesn't break things and encourage URNs under that NSS to become non-persistent. Perhaps the easiest way to fix the problem is this: If a namespace assigns NSSs containing '/', it is responsible for ensuring that NSSs are assigned in such a way that relative URI references appearing in machine-readable resources named by its URNs are also persistent - and give examples of how this might be accomplished. (Of course, any resource can claim any URN as its base URI, and namespaces have no control over the behavior of resources that they don't name. We can't stop the authors of such resources from doing truly stupid things with relative URIs, but we can discourage use of relative URIs with URNs that weren't designed to be used that way.) IMO, this is a technical omission. 2. The document fails to specify which parts of a URN containing f-components or q-components must be persistent. For example, since URN x is required to be persistent, is x#y also required to be persistent? Similarly for x?y and x/y. Or do the persistence requirements only apply to some of these and not others? IIRC, the reason RFC 2141 doesn't permit '/', '?', or '#' in NSSs is that we couldn't figure out how to define or ensure persistence in these cases in a way that made sense across a wide variety of use cases. The current rfc2141bis document still fails to address these problems. At one level the problems with p-components, f-components, and q-components are the same problem - how to ensure persistence of a structured identifier for a resource that can be revised over time, including potentially in ways that change its internal structure and/or relationships with other resources. But at another level I suspect that these are subtly different problems. If we're going to use p-components, f-components, and q-components in ways that are even vaguely similar to their use in HTTP URLs then p-components are going to reflect structure between resources, f-components are going to reflect structure internal to the named resource, and q-components for ... something else (more on that later). (And if we're not going to use these components in those ways, why burden URNs with a syntax that is certain to confuse users?) IMO, this is a serious technical omission, one that is likely to undermine the fundamental URN property of persistence, and {f,p,q}-components shouldn't be permitted in URNs until this is settled. 3. Permitting each namespace to define its own rules for use of f-components, p-components, and q-components is problematic, at least as applied to resolvable URNs that refer to network-accessible and/or machine-parseable resources. One reason this is problematic is that it potentially forces client software to know about the details of each particular namespace, thus hindering interoperability and potentially limiting the useful life of a namespace even when resolution services continue to be available. Otherwise, the client won't know what to do with each particular kind of component. Does the f-component refer to an identifier internal to a resource that it downloads (as in an HTML document) or does the client need to interact with the service in some way to access that component? Does a q-component get sent as part of the request-URI in a GET request or what? Clients that access resources named by URNs over the network shouldn't have to have different wired-in behavior for different namespaces. (and no, the fact that URLs work this way is NOT a justification for propagating the same situation to URNs - URNs were, after all, partially intended to address such issues by decoupling resource names from the protocols used to access them.) In general I think the interpretation of a p-component, f-component, or q-component need to be more-or-less the same for all URNs. (To some degree this is already constrained by the decision to allow use of relative URIs with base URNs). I think the interpretation of these components needs to be exactly the same for all URNs that refer to network-accessible / machine-parseable resources. I think this is less critical for URNs that refer to fixed-media resources that aren't intended to be machine-parseable, though I still think it will be confusing to users if f-components, p-components, and/or q-components are used in ways that aren't more-or-less consistent with HTTP conventions. So one compromise might be to define different constraints on use of f-components, p-components, and q-components when used to name machine-parseable resources than when used to name resources that aren't intended to be machine-parseable. One potential way to resolve this issue might be to declare that the rules for use of these components can be different for machine-parseable resources than for resources not intended to be machine-parseable. Then the people who care a lot about using URNs with these components with non-parseable resources can define rules (perhaps very simple rules) that make sense to them, and the people who care a lot about using URNs with parseable resources can define rules that make sense in that environment. The rules for naming resources that can't be parsed anyway won't affect clients that need to interact with parseable resources. And if it's simple to define the rules for non-parseable resources, namespaces that only assign URNs to non-parseable resources could begin to use f-,p-,and/or q-components. This isn't such a huge departure from "namespaces get to choose the rules for interpreting these components with respect to URNs from their namespaces" - except that in doing so they should be expected to cite one of a small number of already-approved standards for such rules. (Note: "machine-parseable" might not be the right dividing line, but I think it's closer than say "resolvable" or "network-accessible". But there's definitely room for discussion here.) Another possible way to resolve this issue might be to define a universal URN resolution protocol that would allow a client to determine the meaning of f-, p-, and q-components in any particular URN. But I think that solution, while more general, is also more complex and will take much longer to settle on. IMO, this is a serious technical omission. 4. Constraining URNs to RFC 3986 conventions is problematic. One reason is that when using URNs to refer to network-accessible resources there is a need for more functions than those analogous to: references to internal structure (presumably f-component), references to external structure (presumably p-component), and access to the resource as a service (presumably q-component). In particular there seems to be a strong desire to be able to construct URIs containing URNs to query a resolution service that is implicitly determined by the URN itself - i.e. without having to embed the location of that service in the URI. Or to more simply state an example of the problem: given a URN that refers to a network-accessible resource, how to distinguish between queries sent to the resolver and queries sent to the resource itself? Another reason that RFC 3986 syntax convention is problematic is that it creates a conflict between (a) the use of q-components used to send a query or request another service of a network-accessible resource, and (b) the use of q-components for other purposes for non-accessible resources. It might be possible to work around the problem while still sticking to RFC 3986 syntax, perhaps by reserving some part of q-component keyword space for use by resolvers. But that would ideally be done without interfering with use of keywords used by existing HTTP-based services, since we'd like to be able to use URNs to provide stable names for such services. I started out thinking that this was only a poor technical choice, though perhaps a defensible one - but on reflection I think it borders on being a technical omission. And I realize we have AD direction to use RFC 3986, but that doesn't do anything to address the technical problems that this causes. 5. I suspect the way %-encoding is used is problematic for any case where human-supplied strings are converted to URNs, in that there are multiple valid ways to %-encode a name according to RFC 3986. One way to fix this is to require each particular namespace that maps its own names to URNs, and uses/permits %-encoded NSSs, to specify a distinguished %-encoding rule that produces repeatable results and is compatible with RFC 3986 decoding. 6. This document fails to acknowledge that even though the binding between a URN and the resource named by that URN cannot change over time, URNs do not preclude the resource content being revised. This a very important, though subtle, distinction. I trust this is noncontroversial, and easily fixed. (If it's controversial we have a huge problem.) 7. I'm somewhat sympathetic to the idea that IETF Consensus is not the right template for creating new namespaces, but Expert Review is even worse. I think we need widespread public review, and that our very experience in this working group is a good indicator of why - there is as yet no small collection of "experts" that really understands everything about what it takes to make URNs function well, especially when applied to network-accessible resources. I suspect that another part of the problem is that we've conflated IETF Consensus with RFC publication because the two are so often coupled. We shouldn't have to publish a new RFC every time a NSS format changes. I trust that discussion on this will continue. Nits: 1. Introduction, 2nd paragraph, first sentence. Omit the word "typically", or otherwise reword to avoid creating the impression that it's ok to use URNs as other than persistent, location-independent resource identifiers. 2. Section 3, paragraph following ABNF section: I would substitute "MAY" for "can". 3. Section 6, paragraph starting "With regard to global uniqueness": Just simply state that a single resource can have more than one URN assigned to it. It doesn't matter whether those URNs exist for different purposes. Also clarify that if there is no such thing as a distinguished or preferred URN for a resource that can be inferred from looking at the URNs. At least as far as the URN architecture is concerned, all URNs are equally valid. (If the resource wants to specify which of several URNs is the distinguished name for itself, that's a different matter.) From nobody Thu Mar 26 09:45:20 2015 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 146AF1A87F2 for ; Thu, 26 Mar 2015 09:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 XEP7tLDxJMTW for ; Thu, 26 Mar 2015 09:45:17 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15011A8851 for ; Thu, 26 Mar 2015 09:45:16 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YbAuB-000HHP-N1; Thu, 26 Mar 2015 12:45:15 -0400 Date: Thu, 26 Mar 2015 12:45:10 -0400 From: John C Klensin To: Keith Moore Message-ID: In-Reply-To: <55142CA1.2000509@network-heretics.com> References: <55142CA1.2000509@network-heretics.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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Keith's review of draft-ietf-urnbis-rfc2141bis-urn-10 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: Thu, 26 Mar 2015 16:45:19 -0000 --On Thursday, March 26, 2015 11:58 -0400 Keith Moore wrote: > General summary: > > This version of the document has several serious technical > omissions and errors that should, according to RFC 2026 > criteria, prevent its publication as a standards-track > document until those omissions and errors are remedied. Some > of these omissions and errors appear to result from failure to > consider use of URNs for their primary intended purpose of > being identifiers for network-accessible resources. It's > fine to use URNs to name resources that aren't > network-accessible, but the URN specifications should not be > compromised in such a way as to impair their use to name > network-accessible resources, and this document imposes > several such compromises. > > There are other choices reflected in the document that I think > are poor technical choices that should be remedied, though > they fall short of being "technical omissions" in the RFC 2026 > sense. > > The document also reflects, in at least one case, a failure to > resolve an identified technical issue, which RFC 2026 requires > be resolved. > > Details: >... (Elided because I will come back to them in subsequent notes) Keith, Not speaking for anyone but myself. I really appreciate your getting down to specifics. I have to get to another meeting but will respond in detail later. In the interim, I do want to suggest that several of these issues have been discussed in the WG before (in public and on-list, contrary to your implication last night) and the conclusion has been that you are in the rough (and, fwiw, in several cases I am with you in it). Let me take the most sweeping example as an example. I have believed for some time that 3986 (in at least some readings, which is another element of the problem) over-constrains URNs and, at least in retrospect, that 3986 should never have been approved (as anything, much less a full standard) until those issues --generally and with 2141 in particular-- were fully sorted out. That is precisely why, when it became clear that the WG was going to get so bogged down in those discussions that even some 2141-conformant URN namespaces might end up being considered noncomformant or invalid in one way or another, my first reaction was to separate URNs from 3986 entirely with the plan of getting URNs right as URNs and then, as necessary, going back and sorting out an update to 3986. That preference showed up on the (in retrospect) badly-named and hence inflammatory "URNs are not URIs" approach, document, and discussion. However, the WG --or at least those who were speaking up loudly-- thoroughly rejected that approach in Toronto and in subsequent mailing list discussions. We ended up with "syntax only, no semantics" as a sort of compromise, partially because arguments about breaking generic URI parsers seemed to stop with syntax. Even then, the "syntax only" position has dragged us back into relative resolution, and idea that I (and I gather you) would prefer to simply prohibit for use in the "urn:" scheme. However, if the WG and the community believe that "generic URI parsers" are an important issue and that, if one has a generic URI parser one must have relative resolution (and, based on input to the WG, I think we believe both), then... well, there we go down the slippery slope and it becomes more important to discuss how to work around those constraints than to complain about them as constraints. I haven't read it carefully enough, but I think your note makes a proposal about that to which (at least) I plan to pay careful attention. Or you, or someone else, could come up with a persuasive new argument to reopen the question of whether we should separate URNs from 3986 entirely. I'd be very concerned about the time that discussion would take and the number of people who would walk away in disgust if we started having it again, but, in case it isn't clear from the above, it is otherwise a discussion I would welcome _if_ there was a basis for it in issues we haven't already been over several times. best, john From nobody Thu Mar 26 10:07:08 2015 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 96DE61A87B0 for ; Thu, 26 Mar 2015 10:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 St9lBk8Sh30b for ; Thu, 26 Mar 2015 10:07:04 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD26F1A7D80 for ; Thu, 26 Mar 2015 10:07:03 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7EAC720B00 for ; Thu, 26 Mar 2015 13:07:00 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 26 Mar 2015 13:07:03 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id :cc:from:subject:date:to; s=smtpout; bh=/klxeRdPX2SGA/CYtSFL8VUM 35M=; b=GPFtrUG4OMei5m7yHQ8L6LqHlmM2Nf3VsxMqlNvD//mG3pclzoGcqlyE aJsTdEx5euqlMJfoOH15eHnfXGnvi48mVKgLR9OB18x7LUvubD82FJAWtDUaPbOD 7WOq6jb//Koa2gGowISOE4vzaty8naOq9UBNZKBcAKa0zJF4cmY= X-Sasl-enc: Q+mKCexr3FSeZLWY8iYmP/yeQOnf97474UlKMN7bxBNl 1427389622 Received: from [21.79.227.79] (unknown [66.87.99.79]) by mail.messagingengine.com (Postfix) with ESMTPA id 695DBC00013; Thu, 26 Mar 2015 13:07:02 -0400 (EDT) References: <55142CA1.2000509@network-heretics.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5FE5D998-3ADD-4E17-BD48-64995A914153@network-heretics.com> X-Mailer: iPhone Mail (12D508) From: Keith Moore Date: Thu, 26 Mar 2015 12:07:00 -0500 To: John C Klensin Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Keith's review of draft-ietf-urnbis-rfc2141bis-urn-10 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: Thu, 26 Mar 2015 17:07:06 -0000 Two things: 1. RFC 2026 imposes several requirements on standards track documents, amon= g which are that known design choices have been resolved and that there are n= o known technical omissions with respect to the requirements placed on the p= rotocol. These criteria are completely independent of the requirement for r= ough consensus, and nearly everything that I cited in my previous message is= an example of a clear failure to meet those criteria. So it shouldn't matt= er if a person pointing out technical omissions or failure to resolve import= ant issues is "in the rough". A WG cannot be the sole judge of the technica= l quality of its work. 2. The issues with 3986 were included mostly for completeness, because the p= roblems are still glaring and I think the use of 3986 syntax still borders o= n a technical omission. It's only when you ignore the use of URNs to name n= etwork accessible resources and insist on using 3986 syntax in a very differ= ent manner than it is used with http / html that it appears at all adequate f= or URNs. Sent from my iPhone > On Mar 26, 2015, at 11:45 AM, John C Klensin wrote: >=20 > --On Thursday, March 26, 2015 11:58 -0400 Keith Moore > wrote: >=20 >> General summary: >>=20 >> This version of the document has several serious technical >> omissions and errors that should, according to RFC 2026 >> criteria, prevent its publication as a standards-track >> document until those omissions and errors are remedied. Some >> of these omissions and errors appear to result from failure to >> consider use of URNs for their primary intended purpose of >> being identifiers for network-accessible resources. It's >> fine to use URNs to name resources that aren't >> network-accessible, but the URN specifications should not be >> compromised in such a way as to impair their use to name >> network-accessible resources, and this document imposes >> several such compromises. >>=20 >> There are other choices reflected in the document that I think >> are poor technical choices that should be remedied, though >> they fall short of being "technical omissions" in the RFC 2026 >> sense. >>=20 >> The document also reflects, in at least one case, a failure to >> resolve an identified technical issue, which RFC 2026 requires >> be resolved. >>=20 >> Details: >> ... >=20 > (Elided because I will come back to them in subsequent notes) >=20 > Keith, >=20 > Not speaking for anyone but myself. >=20 > I really appreciate your getting down to specifics. I have to > get to another meeting but will respond in detail later. In the > interim, I do want to suggest that several of these issues have > been discussed in the WG before (in public and on-list, contrary > to your implication last night) and the conclusion has been that > you are in the rough (and, fwiw, in several cases I am with you > in it). Let me take the most sweeping example as an example.=20 >=20 > I have believed for some time that 3986 (in at least some > readings, which is another element of the problem) > over-constrains URNs and, at least in retrospect, that 3986 > should never have been approved (as anything, much less a full > standard) until those issues --generally and with 2141 in > particular-- were fully sorted out. That is precisely why, when > it became clear that the WG was going to get so bogged down in > those discussions that even some 2141-conformant URN namespaces > might end up being considered noncomformant or invalid in one > way or another, my first reaction was to separate URNs from 3986 > entirely with the plan of getting URNs right as URNs and then, > as necessary, going back and sorting out an update to 3986. > That preference showed up on the (in retrospect) badly-named and > hence inflammatory "URNs are not URIs" approach, document, and > discussion. =20 >=20 > However, the WG --or at least those who were speaking up > loudly-- thoroughly rejected that approach in Toronto and in > subsequent mailing list discussions. We ended up with "syntax > only, no semantics" as a sort of compromise, partially because > arguments about breaking generic URI parsers seemed to stop with > syntax. Even then, the "syntax only" position has dragged us > back into relative resolution, and idea that I (and I gather > you) would prefer to simply prohibit for use in the "urn:" > scheme. However, if the WG and the community believe that > "generic URI parsers" are an important issue and that, if one > has a generic URI parser one must have relative resolution (and, > based on input to the WG, I think we believe both), then... > well, there we go down the slippery slope and it becomes more > important to discuss how to work around those constraints than > to complain about them as constraints. I haven't read it > carefully enough, but I think your note makes a proposal about > that to which (at least) I plan to pay careful attention. >=20 > Or you, or someone else, could come up with a persuasive new > argument to reopen the question of whether we should separate > URNs from 3986 entirely. I'd be very concerned about the time > that discussion would take and the number of people who would > walk away in disgust if we started having it again, but, in case > it isn't clear from the above, it is otherwise a discussion I > would welcome _if_ there was a basis for it in issues we haven't > already been over several times. >=20 > best, > john >=20 From nobody Thu Mar 26 10:16:35 2015 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 4A7BA1A88F1 for ; Thu, 26 Mar 2015 10:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 1oipZmUoP-2o for ; Thu, 26 Mar 2015 10:16:33 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AFC21A88EC for ; Thu, 26 Mar 2015 10:16:30 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so95149038wib.1 for ; Thu, 26 Mar 2015 10:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=GUNyKguwnAY/vEc3dN/sO29b4+oAS1LbKXhGpl2bxE4=; b=phCgBGqKoxPrwtib1Mk8j5tidIb25tWOYLBnrXV3A7bNuUvL4KgVKBQlhG9AhFvzYM xbKMfp638ARhGMrcZNmc1XIwhN41D/SUswD50G76NU0uyZq4I0sKe5KseM2M1vOKT3Af VyiQpE4kQZ9Y4hMUTY3McIqZary1vIZv8S+JDFhWbepJpIByNIR1noqemP8Rbx6SCuK6 tzHVfWWVszo0Nq6lcOLbQmdm96flvMKCLmyReWsOk0Jt/BdbzgyyHJmR5aMDPp2qufMm 7bP3lb+wriLa9IKxuCPgWeHKy/FWZmohG+Of0V7Cvwdodn8ERPi28Q0UdzaTqNMUtAjQ m8BA== X-Received: by 10.180.77.110 with SMTP id r14mr48501476wiw.89.1427390189313; Thu, 26 Mar 2015 10:16:29 -0700 (PDT) Received: from dhcp-8dbd.meeting.ietf.org ([2001:67c:370:136:45fd:36da:f636:cfd7]) by mx.google.com with ESMTPSA id cj9sm9236490wjc.42.2015.03.26.10.16.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 10:16:28 -0700 (PDT) Message-ID: <55143EEA.1060303@gmail.com> Date: Thu, 26 Mar 2015 12:16:26 -0500 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: urn@ietf.org References: <55142CA1.2000509@network-heretics.com> <5FE5D998-3ADD-4E17-BD48-64995A914153@network-heretics.com> In-Reply-To: <5FE5D998-3ADD-4E17-BD48-64995A914153@network-heretics.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Keith's review of draft-ietf-urnbis-rfc2141bis-urn-10 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: Thu, 26 Mar 2015 17:16:34 -0000 On 3/26/15 12:07 PM, Keith Moore wrote: > Two things: > > 1. RFC 2026 imposes several requirements on standards track > documents, among which are that known design choices have been > resolved and that there are no known technical omissions with respect > to the requirements placed on the protocol. These criteria are > completely independent of the requirement for rough consensus, and > nearly everything that I cited in my previous message is an example > of a clear failure to meet those criteria. So it shouldn't matter if > a person pointing out technical omissions or failure to resolve > important issues is "in the rough". A WG cannot be the sole judge of > the technical quality of its work. Of course, and this is why we have IESG review and IETF-wide last call. We can, however, conclude that we've gotten as far as we can go and that it's time to move the document along. My concern is that we not get stuck is a loop where someone keeps raising the same issue and others keep providing the same answer, and there's no progress or willingness to compromise. It's an unfortunate fact that very few IETF participants have the grace to be able to say "I don't agree but I can live with that" and sometimes it seems more common than not for disagreements to become blocking. In the absence of new information we're really unable to go back and revisit issues that have been closed. If there is new information, by all means, bring it forward. One thing that would be helpful to me would be to understand objections in terms of what the proposed text breaks, and I'd be grateful if objections can continue to be couched in those terms. In the meantime, we really can't revisit closed issues without a compelling reason, where "compelling" means it hasn't yet been considered or discussed. Melinda From nobody Thu Mar 26 10:34:57 2015 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 45AB71A8AF0 for ; Thu, 26 Mar 2015 10:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 BFysBgJxmd9r for ; Thu, 26 Mar 2015 10:34:54 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30351A8AB8 for ; Thu, 26 Mar 2015 10:34:54 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 777A82067E for ; Thu, 26 Mar 2015 13:34:51 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 26 Mar 2015 13:34:54 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=WCekrm11BHET6WYnyCaglC K+Prw=; b=qHe2MgCods5XIi4hlHS+VFmKRrnxezY/Inpp1VwTAEqnW0EC3HZDMm w8dWAYNUP++adqtiWPMN3I2BTKUFGKRyfR3MuCUstlSV9gECr7hVmhVG/BsQgx7b Nb32oF06YwppeMwnCZbfMJZ1JTmZxgGg3AHY0bTvvWIBC2oiPysTY= X-Sasl-enc: so+52XjcvxNZOkEQe1HlGO87Co1Yd5gmQdW6XK+giNJP 1427391294 Received: from [31.133.177.40] (unknown [31.133.177.40]) by mail.messagingengine.com (Postfix) with ESMTPA id E22F86801F7; Thu, 26 Mar 2015 13:34:53 -0400 (EDT) Message-ID: <5514433D.7010604@network-heretics.com> Date: Thu, 26 Mar 2015 13:34:53 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: urn@ietf.org References: <55142CA1.2000509@network-heretics.com> <5FE5D998-3ADD-4E17-BD48-64995A914153@network-heretics.com> <55143EEA.1060303@gmail.com> In-Reply-To: <55143EEA.1060303@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Keith's review of draft-ietf-urnbis-rfc2141bis-urn-10 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: Thu, 26 Mar 2015 17:34:56 -0000 On 03/26/2015 01:16 PM, Melinda Shore wrote: > On 3/26/15 12:07 PM, Keith Moore wrote: >> Two things: >> >> 1. RFC 2026 imposes several requirements on standards track >> documents, among which are that known design choices have been >> resolved and that there are no known technical omissions with respect >> to the requirements placed on the protocol. These criteria are >> completely independent of the requirement for rough consensus, and >> nearly everything that I cited in my previous message is an example >> of a clear failure to meet those criteria. So it shouldn't matter if >> a person pointing out technical omissions or failure to resolve >> important issues is "in the rough". A WG cannot be the sole judge of >> the technical quality of its work. > > Of course, and this is why we have IESG review and IETF-wide > last call. We can, however, conclude that we've gotten as far > as we can go and that it's time to move the document along. The WG can do that. From that perspective, I'm just making sure that I'm doing due diligence in informing the WG of the serious technical problems with the current document, so that when I raise the issues again at Last Call or subsequently to that, people can't say that I didn't raise the issues in WG discussion. > My concern is that we not get stuck is a loop where someone > keeps raising the same issue and others keep providing the same > answer, and there's no progress or willingness to compromise. That's a valid concern. Please note that these issues for the most part have been ignored in the past rather than the WG attempting to address them, and also that I did try to suggest compromises in my recent review. Also, when the consistent answer that I'm given whenever I raise objections is not technical, but rather, "we have to do what this narrow set of people want otherwise they'll take URNs to be standardized elsewhere", I think that actually creates a serious process problem. Nothing in 2026 says that we can standardize technically flawed documents just because of a threat from another standards body. Also, it's entirely possible that the reason that the WG is stuck in a loop is that it has failed to attract the attention of, or even alienated, the constituency that created URNs in the first place. I'm hoping that it's not too late to get some of those people to contribute their input. > It's an unfortunate fact that very few IETF participants have the > grace to be able to say "I don't agree but I can live with that" > and sometimes it seems more common than not for disagreements to > become blocking. I say that all the time. This, however, is not one of those cases. Several of us spent several years of our lives trying to get URNs defined. I personally don't want to see them made useless for most of the use cases for which they were intended, and I suspect I'm not the only one who feels that way. > > In the absence of new information we're really unable to go back > and revisit issues that have been closed. If there is new information, > by all means, bring it forward. > > One thing that would be helpful to me would be to understand > objections in terms of what the proposed text breaks, I didn't cite section by section because I don't think you can fix the problems I cited by simple changes to the text - or at least to the extent that you can do so, you first have to get agreement on the broad approach. Again, I did try to suggest ways of resolving the issues I raised. But if you're trying to suggest that it's out of scope to raise valid technical issues, I'll appeal that decision to IESG. Keith From nobody Thu Mar 26 20:04:01 2015 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 0D1D31A90B2 for ; Thu, 26 Mar 2015 20:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 tkVTpECGbJav for ; Thu, 26 Mar 2015 20:03:58 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31C631A909E for ; Thu, 26 Mar 2015 20:03:58 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so9482250igb.1 for ; Thu, 26 Mar 2015 20:03:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=P0IRG+pQQEa3CB3tg/spyTe/tZ6m1e4l2XhE2PFX5Vc=; b=mySX3Gi1aZ3UkCD9p27CBpRwZOAlhvzSD3B81SnYfRyu0tarpKJIYNuNVLKQ4zgIIw ryJr6Zs5bqzL1doOPq1urUoWVsk4k1LjOJcWGOoEWoBFJxyL32mFRMZe3u5KifjVjBR+ Qugp2rJPUFRtXv2OnPxQ33TiQOLGZNwKF6rr3114Hyqq3EUoMinki8nb5YVCvyLktMzx IMEEmFbhcy8XoOZgrnIDhLRqeJWTuqRqUTlqAactnT2/exZI2+NXocl3/bXbWshrHBlP sTA0sfXVk/Mx8Vm/g5pchU9Vioz+Vhali1iu1amYdDc2NvV2hLo5nZZtH/LEoi6iaVEz k3jg== X-Gm-Message-State: ALoCoQlALbplVWG6Bd6716lUwFUG0RvGbvd6XAr8t7g995n4u2y/sR7/74egs82lD4sDUj2ihS1C X-Received: by 10.107.11.226 with SMTP id 95mr15867286iol.5.1427425437517; Thu, 26 Mar 2015 20:03:57 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id lo1sm549696igb.1.2015.03.26.20.03.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 20:03:56 -0700 (PDT) Message-ID: <5514C89A.8090204@andyet.net> Date: Thu, 26 Mar 2015 21:03:54 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: <7248E8A902BB366E16773856@JcK-HP8200.jck.com> In-Reply-To: <7248E8A902BB366E16773856@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Expert reveiw and draft-ietf-urnbis-rfc2141bis-urn-09 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, 27 Mar 2015 03:04:00 -0000 On 3/4/15 8:16 AM, John C Klensin wrote: > We agreed some time ago that URN registrations for Formal > namespaces and their NIDs should be shifted from IETF Consensus > (see Section 4.3 of RFC 3406) to Expert Review and that Expert > Review should apply to Informal Namespaces as well. Although I don't recall a decision to use Expert Review for informal namespaces, I think it makes sense for both formal and informal namespaces to use the same procedure. (Recent discussion on the urn-nid@ietf.org list indicates that this is important.) > There has been some discussion in the WG (and the IETF more > generally) about issues with registration Expert Review, > especially for registrations that are expected to be reflected > in standards track documents. I'm not sure what the criteria are for saying that certain registrations are "expected to be reflected in standards track documents" (only within the Internet Standards Process?) whereas others are not. > Some of that discussion is hinted > at in draft-ietf-urnbis-ns-reg-transition, but it has not yet > been reflected in 2141bis. > > For those who have not followed the other discussion, one key > problem is that, if something is registered with particular > properties and specifications and then the authors want to > standardize the technology, the IETF is told that discussion of > design choices is out of order because the registration cannot > be changed. That is, I hope obviously, bad news. True. However, it seems to me that this can be handled by allowing versioning of registrations. > I think we are headed in the following direction, but want to > get confirmation (or corrections) from the WG before Peter and I > start struggling with draft text: > > (1) We want Expert Review, with the guidance that now appears in > Sections 7 and 9, for namespaces that are not intended to be > standardized in/by the IETF. > > (2) For namespaces intended for standardization, IETF Consensus > is necessary for registration although a preliminary expert > review may be helpful. > > (3) While namespaces that are essentially overlays on identifier > standards produced and managed by other standards bodies, the > Expert Review process is intended more as an advisory and > coordination on rather than one or acceptance or rejection and > some sort of "fast track" procedure (and/or even a different > review process) may be in order. I would hope we can explicitly > give the IESG some flexibility in those situations rather than > having to spell everything out in 2141bis. > > (4) For namespaces that do not fall into categories (2) or (3), > we have a strong preference for registration, even poor-quality > registrations that only assure uniqueness of NIDs, over a slow > and/or onerous registration approval process that encourages use > of names without registration. In my ignorance of the aforementioned criteria for expecting a registration to be reflected in a standards track document, I would suggest the following somewhat simplified set of principles: 1. The registration policy is always Expert Review. 2. It is preferred for each registration request to be accompanied by a stable specification. 3. If such a specification is on the standards track within the IETF, then the specification (but not the registration) requires IETF consensus. (It might be appropriate to register the namespace in a preliminary fashion before publication of the specification.) 4. Registrations can be modified by submitting a revised version of the completed template. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Mar 26 20:17:15 2015 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 23F071A6EFE for ; Thu, 26 Mar 2015 20:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 y8gf5mK7rsRr for ; Thu, 26 Mar 2015 20:17:11 -0700 (PDT) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B0F1A1BF6 for ; Thu, 26 Mar 2015 20:17:11 -0700 (PDT) Received: by igbud6 with SMTP id ud6so9809557igb.1 for ; Thu, 26 Mar 2015 20:17:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=13IIqQPq4tmsJ7dlnULednTyNbH4VBdvRG7b9gVWD+4=; b=bAzNBGTiyqzyVodZ9nUMViPy7QntiN3/fRggPrmnB+6wdV2zxzh2iHdVKujJvlECmp WKw/mGTRieoghdXI7HtGa4mIMhzoWqx8WInKgWc8wZe+vruVub7nAAKJfNppGvn79/qY QMhrl4fV0GTNTPe+IJWfNXW0wpARN1l/6QoiV9WJ6SdMll0bhBWIbf7nNWu94AT8tY7Y 3tBD/Kj6jqwGs+yTkGqowbj2a+KD5Fgtk4AYlv4j9zQXIjGlm9WpqLXcMVPh0UCOy0yH W2nCGb4HkEPY/0UA1dFYMdAcrNd/0ANwzdoeTqWmJCgilbq/A4dg10nSvirs6UPRuVMI xXJA== X-Gm-Message-State: ALoCoQlsfKG0lXRXdjFPCw0u0iRHriM2KjEZ7mVYj4jieSQzhGURdzjRSWsxV8fcTQBlhLQi56M2 X-Received: by 10.42.101.83 with SMTP id d19mr1080747ico.50.1427426230650; Thu, 26 Mar 2015 20:17:10 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id 17sm525576iol.39.2015.03.26.20.17.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 20:17:09 -0700 (PDT) Message-ID: <5514CBB3.6020607@andyet.net> Date: Thu, 26 Mar 2015 21:17:07 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Hakala, Juha E" , "Svensson, Lars" , "urn@ietf.org" References: <24637769D123E644A105A0AF0E1F92EFFAC84913@dnbf-ex1.AD.DDB.DE> <55079325.1010300@andyet.net> <24637769D123E644A105A0AF0E1F92EFFAC85A6E@dnbf-ex1.AD.DDB.DE> <5509ABC6.2040707@andyet.net>, <24637769D123E644A105A0AF0E1F92EFFAC923DC@dnbf-ex1.AD.DDB.DE> <1427353527416.72968@helsinki.fi> In-Reply-To: <1427353527416.72968@helsinki.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10 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, 27 Mar 2015 03:17:13 -0000 On 3/26/15 1:05 AM, Hakala, Juha E wrote: > Hello, > > Some comments below. > > ________________________________________ Lähettäjä: urn > käyttäjän puolestaSvensson, Lars > Lähetetty: 25. maaliskuuta 2015 18:24 > Vastaanottaja: urn@ietf.org Aihe: Re: [urn] Comments on > draft-ietf-urnbis-rfc2141bis-urn-10 > > All, > > Sorry for causing much confusion, I should make clear that what I > intended to say here is _not specifically about DOIs_, but about the > (proposed) p-component, the NSS and urn comparison (my use of DOI was > only to illustrate my point and obviously was not helpful). Specifics > below: > > On Wednesday, March 18, 2015 5:46 PM, Peter wrote: > >> To: Svensson, Lars; urn@ietf.org Subject: Re: [urn] Comments on >> draft-ietf-urnbis-rfc2141bis-urn-10 >> >> On 3/17/15 7:16 AM, Svensson, Lars wrote: > >>>> Although I don't claim to fully understand the DOI numbering >>>> system (with regard to URNs, Section 2.6.3 of the DOI Handbook >>>> is especially confusing to me because it implies that in a URN >>>> the slash could be replaced by a colon), let's take your >>>> example at face value. > > Slash may appear in two different roles in Handles and DOIs: as a > separator between prefix and suffix, and as a character within the > identifier string. These two cases should receive different treatment > when DOIs are converted to URNs. That is why the DOI Handbook section > 2.6.3 says that: > > "To enable the use of DOIs in workflows that have already > standardized on URNs, the DOI proxy servers understand the > substitution of a colon in place of the initial slash in a DOI name. > DOI names may therefore be expressed as URNs in the doi.org domain by > writing, for example, the DOI name 10.123/456 in the form > http://doi.org/urn:doi:10.123:456. Note, however, that a DOI suffix > is allowed to contain other slashes, and where these occur they must > be percent-encoded rather than replaced with a colon: for example, > the DOI name 10.123/456ABC/zyz would become > http://doi.org/urn:doi:10.123:456ABC%2Fzyz, with the final slash > character encoded as %2F." > > IMO it is best not to divert from this representation, which makes > sense to me. However, the example is theoretical since the namespace > DOI has not been registered for the time being and the DOI community > does not seem to have much interest to do so. I think it is best not to speculate about a URN namespace for DOI numbers. However, consider the hypothetical example of a hierarchical naming system in which the identifiers take the form of a series of numbers separated by the "/" character, such as "1/406/47452/2". If the naming authority for such identifiers were to use URNs, it seems natural to me if we place the existing identifiers in the p-component, resulting in URNs such as "urn:example/1/406/47452/2". Yes, the naming authority could differentiate among the "/" character as used in different places within the original identifier, but that seems a bit complicated. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Mar 26 20:27:33 2015 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 3EE2B1A90EC for ; Thu, 26 Mar 2015 20:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 xzS7OGH4CYvv for ; Thu, 26 Mar 2015 20:27:29 -0700 (PDT) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E1C1A1BF6 for ; Thu, 26 Mar 2015 20:27:29 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so69579752ied.1 for ; Thu, 26 Mar 2015 20:27:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=f2Ypijte4mRtMUNVwp9bAbHqvKN/BFm2gNQJQzNde/0=; b=f7W5Z79BnM6pk+uEHhO6EQkpPK/XMHG+E60f7kUbIns1bEVVFHBsNWq41H5HgCtyLD CI6Hww/+eI+WDUiHzH1UDHL2akcYcGkmAb3DYaY4mhY0c6zsB6W5Zf81unrnFxyaSgzB 5689RhPB0T9nx0K8Fmbh8gR5UmR9WaekbSS2G98sElwy2xyA7jZjQJDmPfOJgjaGd5gE wPgcc3+M9+1m2CEsYjexnmkNBREv1jXq0DG3viV1EwTYBcnRCv8JBX/cjLW5GT7Q6TX4 mspVvfP0kliXPF1nFDRfOmcdOe0BgShYZ5V+L2hKGGjwV04Oy9SakXvTrJHR+cNsh+8C tBcg== X-Gm-Message-State: ALoCoQn1NhlnOMHppcRDtf+bWnrnMH8aHnqo4UudRcR0DY0bHmeVIoqzY/asjGgPHfb3yrl76qTv X-Received: by 10.42.79.204 with SMTP id s12mr36404932ick.78.1427426849089; Thu, 26 Mar 2015 20:27:29 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id p2sm572295ioi.0.2015.03.26.20.27.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 20:27:28 -0700 (PDT) Message-ID: <5514CE1E.4010201@andyet.net> Date: Thu, 26 Mar 2015 21:27:26 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Svensson, Lars" , "urn@ietf.org" References: <24637769D123E644A105A0AF0E1F92EFFAC84913@dnbf-ex1.AD.DDB.DE> <55079325.1010300@andyet.net> <24637769D123E644A105A0AF0E1F92EFFAC85A6E@dnbf-ex1.AD.DDB.DE> <5509ABC6.2040707@andyet.net> <24637769D123E644A105A0AF0E1F92EFFAC923DC@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFFAC923DC@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10 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, 27 Mar 2015 03:27:31 -0000 On 3/25/15 10:24 AM, Svensson, Lars wrote: > I try to reformulate what is my concern: > > Right now we have urn=assigned-name + p-component (+q-component + > f-component), where assigned-name = 'urn' + NID + NSS. To me this > implies that p-, q- and f-components are not part of the name and > thus (my reading) not really identifying anything (sort of > second-class citizens). That seems OK for q- and f-components since > they are ignored when we do urn comparison. But to me it seems > counter-intuitive to have a part of the identifier that is not > relevant for the _identification_ (not part of the assigned name) but > nonetheless matters when it comes to _comparison_. > > Am I over-interpreting the use of "assigned-name" to mean that the > rest of the urn is not part of the name and thus not part of the > identifier? I think that you might be over-interpreting, because the specification currently says that the p-component shall be taken into account for purposes of determining URN equivalence. Thus "urn:example/1/2/3/" is not equivalent to "urn:example/4/5/6", whereas "urn:example:foo?123" is equivalent to "urn:example:foo?456" and "urn:example:foo#123" is equivalent to "urn:example:foo#456". So in practice the p-component matters in a way that the q-component and f-component do not. However, perhaps the term "assigned-urn" is confusing so I will see if I can find a better term. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Fri Mar 27 04:38:03 2015 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 923231ACD6E for ; Fri, 27 Mar 2015 04:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 Y4U0W1CRjC5a for ; Fri, 27 Mar 2015 04:37:59 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ED691ACD72 for ; Fri, 27 Mar 2015 04:37:58 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YbSaI-000ME6-FL; Fri, 27 Mar 2015 07:37:54 -0400 Date: Fri, 27 Mar 2015 07:37:49 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: In-Reply-To: <5514433D.7010604@network-heretics.com> References: <55142CA1.2000509@network-heretics.com> <5FE5D998-3ADD-4E17-BD48-64995A914153@network-heretics.com> <55143EEA.1060303@gmail.com> <5514433D.7010604@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Keith's review of draft-ietf-urnbis-rfc2141bis-urn-10 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, 27 Mar 2015 11:38:02 -0000 Keith, I want to respond to what I think are a few meta-issues -- the more specific ones are covered in separate notes which I'm working on but may not finish before the weekend. --On Thursday, March 26, 2015 13:34 -0400 Keith Moore wrote: > On 03/26/2015 01:16 PM, Melinda Shore wrote: >> On 3/26/15 12:07 PM, Keith Moore wrote: >... >> My concern is that we not get stuck is a loop where someone >> keeps raising the same issue and others keep providing the >> same answer, and there's no progress or willingness to >> compromise. >=20 > That's a valid concern. Please note that these issues for > the most part have been ignored in the past rather than the WG > attempting to address them, and also that I did try to suggest > compromises in my recent revie In some cases, I think you are confusing "didn't know what to do with your comments" or "disagreed with you", with "ignored". More specifics with the detailed response to your first note in this sequence. > Also, when the consistent answer that I'm given whenever I > raise objections is not technical, but rather, "we have to do > what this narrow set of people want otherwise they'll take > URNs to be standardized elsewhere", I think that actually > creates a serious process problem. Nothing in 2026 says that > we can standardize technically flawed documents just because > of a threat from another standards body. And no one has proposed standardizing anything technically flawed, at least unless the "flaws" are the result of balancing tradeoffs with other technical issues and concluding that the balance is against your preferred outcome. =20 On the issue of other communities and standards bodies, I've been louder about the issue, and the issue of trying to avoid a fork, than, I think, anyone else. There are several separate issues involved in that and my motivation for it: (i) I've have raised the potential for a fork -- either to a competing standard to to a community just doing whatever they like and ignoring the IETF-- several times, not in the interest of getting particular features but as a caution about continuing to go around in circles without making progress. It is worth noting in this regard that the working group is now over four years behind on what was supposed to be about a six month schedule (see https://tools.ietf.org/wg/urnbis/charters?item=3D./charter.d/char= ter.2011-02-02_2210,1.txt which is the earliest charter version I can find with milestones in it). =20 (ii) What actually happened here was that the folks from the other communities came to us, asking that extension work on URNs be done in the IETF. Their doing so was based on the beliefs that one standard was better than conflicting ones, that we had critical expertise, and that we could get the work done quickly and efficiently (something that the "IETF Last Call request on everything by April and July 2011" schedule reinforced). Various people from that community have been active on the WG's mailing list, have been authors or co-authors of documents and contributed text to others, and so on -- much more active than any of the original URN designers than anyone but Andy (although I don't know if you put him in that category or not or how you define that category). Their bringing the work to us are participating in our efforts should, IMO, be cited as an outstanding example of cooperation, not criticized for trying to explain to us what functionality they want and need.=D1=AA What = I think we owe them in return (both ethically and pragmatically) is to move forward expeditiously and to either adapt to their needs or explain why not and propose alternatives. We have done neither. Instead, we have spent most of four years on what must look from the outside like an extended family feud about the interpretation of, and relationships among, _our_ standards. That family feud has also involved several replays of "we don't need the 'urn' scheme at all (most recently PH-B's comments on the IETF list this week), an argument those other communities aren't interested in, partially because they believe they know what URNs are for and why they are important (and have millions of them deployed and in use in various namespaces) and believe that they have several centuries more experience with persistent, location-independent, identifiers than the IETF does. I think they have shown exceptional forbearance by sticking with us, but we are holding up their work and constraining choices by these long delays. The part of this that involves low participation in the WG by the original URN designers leads to... (iii) The IETF has been consistent about wanting change control over its standards. There is some pride of ownership in that, but it has been, at least IMO, largely to avoid accidental or deliberate forks and the confusion they cause. At the same time, most of us are aware, most of the time, that the Protocol Police are hard to find when needed and/or ineffective: the IETF has no way to require compliance and, if people want to ignore us and go their own way, even while using that same identifiers we have defined and used, there is little or nothing we can do to stop them. But, while the IETF has claimed (and, so far, kept) change control over URNs, that is _IETF_ change control. Contrary to an inference that could be made from your plenary remarks, our procedures and culture have never given special precedence to either the views of original authors or designers nor to people who have been active elsewhere in the IETF. For better or worse, those who participate actively in a WG tend to have more influence on it than those who either do not participate at all or who show up intermittently, complain, and then disappear again for an extended period. Sometimes that works out well, sometimes less so -- I'd like to believe that, if you, myself, and a few obvious others had been more consistently active when what became 3986 was being developed, we'd be having different discussions now. (iv) Partially because of those millions of deployed URN references (something the IETF should normally consider "running code"), the one choice the external communities have not given us is to say "freeze URNs to the technical specification content of RFC 2141; anyone who wants to do anything else needs to adopt a new scheme". Insofar as that position has merit (and you will recall that it was more or less proposed again as recently as the Toronto meeting), the IETF rejected it in the first charter for this WG. > Also, it's entirely possible that the reason that the WG is > stuck in a loop is that it has failed to attract the attention > of, or even alienated, the constituency that created URNs in > the first place. I'm hoping that it's not too late to get some > of those people to contribute their input. I'm not sure which constituency (and designers) you are referring to. Karen Sollins (RFC 2276, 1737, etc.) has not be active in the IETF for many years. Michael Mealing (author of the RFC 3401-3405 DDDS specs) has been gone almost as long as has Ryan Moats (author of 2141). Larry Masinter (co-author of 1737) has popped up periodically in WG meetings or on the list but mostly, AFAICT, to advocate for the interpretation and application of 3986 that you appear to detest. I'd certainly be happy to hear more from those people (and from you and Leslie), but I don't know how long the WG can reasonably be expected to wait. Again, the WG is now five years old. >> It's an unfortunate fact that very few IETF participants have >> the grace to be able to say "I don't agree but I can live >> with that" and sometimes it seems more common than not for >> disagreements to become blocking. >=20 > I say that all the time. This, however, is not one of those > cases. Several of us spent several years of our lives trying > to get URNs defined. I personally don't want to see them made > useless for most of the use cases for which they were > intended, and I suspect I'm not the only one who feels that > way. I appreciate your engaging in an actual discussion this time, but I just don't see "made useless for most of the use cases for which they were intended" in any of this. The WG has, IMO, been very clear about its intention that no URN or namespace definition that is valid under RFC 2141 will become invalid with whatever changes we are making. My sense is that principle is one of the things about which there is very broad consensus that includes just about all participants other than those who believe that URNs were a bad idea from the beginning and should be abolished. I'll address your relative reference and comparison issues in the response to details, but I don't think they change the = above. >... Now we (or at least I) face one of those nasty tradeoffs that, in the light of your comments, seems worth making explicit and public. I have limited time to spend on IETF issues and cannot devote even all of that time to URNs. Peter and I have committed to get -11 of 2141bis posted before Wednesday and to have it reflect issues that seem to have been resolved in WG mailing list discussions. I need to cross-check text that Peter has developed this week before we post. I'm going to prioritize that over finishing the point-by-point response to your detailed comments that I've been working on since shortly after you posted that note. The comments are _not_ being ignored, I'm just trying to make decisions about the most efficient overall way to proceed and I'm quite confident that, even if I were to respond to you immediately, there would be no way to reach enough of a WG conclusion about the issues to have the result reflected in an I-D next week ... especially so given your comments about the changes you believe are required implying major rewrites, not just adjustment to the text of a few sections. best, john From nobody Fri Mar 27 06:55:25 2015 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 1DF561ACE2F for ; Fri, 27 Mar 2015 06:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 Kw7XqBkr46KB for ; Fri, 27 Mar 2015 06:55:20 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A4E1ACDE6 for ; Fri, 27 Mar 2015 06:55:00 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YbUix-000Ma3-39; Fri, 27 Mar 2015 09:54:59 -0400 Date: Fri, 27 Mar 2015 09:54:54 -0400 From: John C Klensin To: Peter Saint-Andre - &yet , urn@ietf.org Message-ID: <023B0B823C38BCFB8ADE0063@JcK-HP8200.jck.com> In-Reply-To: <5514C89A.8090204@andyet.net> References: <7248E8A902BB366E16773856@JcK-HP8200.jck.com> <5514C89A.8090204@andyet.net> 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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Expert reveiw and draft-ietf-urnbis-rfc2141bis-urn-09 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, 27 Mar 2015 13:55:23 -0000 --On Thursday, March 26, 2015 21:03 -0600 Peter Saint-Andre - &yet wrote: > On 3/4/15 8:16 AM, John C Klensin wrote: >> We agreed some time ago that URN registrations for Formal >> namespaces and their NIDs should be shifted from IETF >> Consensus (see Section 4.3 of RFC 3406) to Expert Review and >> that Expert Review should apply to Informal Namespaces as >> well. > > Although I don't recall a decision to use Expert Review for > informal namespaces, I think it makes sense for both formal > and informal namespaces to use the same procedure. (Recent > discussion on the urn-nid@ietf.org list indicates that this is > important.) Ack. >> There has been some discussion in the WG (and the IETF more >> generally) about issues with registration Expert Review, >> especially for registrations that are expected to be reflected >> in standards track documents. > > I'm not sure what the criteria are for saying that certain > registrations are "expected to be reflected in standards track > documents" (only within the Internet Standards Process?) > whereas others are not. I think it is a matter of registrant intent. Someone who uses the Expert Review registration process to create an NID and bind it to a namespace definition should not then submit an I-D asking for standards-track status. More specifically, if such an I-D is submitted and, when IETF discussions starts, the registrant says "already registered, can't make technical changes", any RFC publication has to be an Informational spec that describes what is registered, not a standards-track document. I can imagine an exception in which the registrant (or someone else) comes back a few years later and says "this thing that was registered earlier has been widely deployed, has proven useful and to not cause any problems, please standardize", but that is a different situation -- and, because there would be little value added, one I'd expect to be exercised about as often as we move documents to full standard (or less often) whether the effort at that time was to process a new document or reclassify an existing one. >> Some of that discussion is hinted >> at in draft-ietf-urnbis-ns-reg-transition, but it has not yet >> been reflected in 2141bis. >> >> For those who have not followed the other discussion, one key >> problem is that, if something is registered with particular >> properties and specifications and then the authors want to >> standardize the technology, the IETF is told that discussion >> of design choices is out of order because the registration >> cannot be changed. That is, I hope obviously, bad news. > > True. However, it seems to me that this can be handled by > allowing versioning of registrations. Except that, if there is _any_ deployment in places that are hard to change, and the IETF decides that, e.g., what the registration describes as a duck is really a rabbit, a registration change is likely to cause interoperability problems. We could adopt some new rules that would encourage NIDs that look like "john.20150327a" and give special interpretations to the relationship between it and "john.20150327b" and "john.20150401" but I don't think we want to go there... and that registrants would probably not take advantage of it if we did. >> I think we are headed in the following direction, but want to >> get confirmation (or corrections) from the WG before Peter >> and I start struggling with draft text: >> >> (1) We want Expert Review, with the guidance that now appears >> in Sections 7 and 9, for namespaces that are not intended to >> be standardized in/by the IETF. >> >> (2) For namespaces intended for standardization, IETF >> Consensus is necessary for registration although a >> preliminary expert review may be helpful. >> >> (3) While namespaces that are essentially overlays on >> identifier standards produced and managed by other standards >> bodies, the Expert Review process is intended more as an >> advisory and coordination on rather than one or acceptance or >> rejection and some sort of "fast track" procedure (and/or >> even a different review process) may be in order. I would >> hope we can explicitly give the IESG some flexibility in >> those situations rather than having to spell everything out >> in 2141bis. >> >> (4) For namespaces that do not fall into categories (2) or >> (3), we have a strong preference for registration, even >> poor-quality registrations that only assure uniqueness of >> NIDs, over a slow and/or onerous registration approval >> process that encourages use of names without registration. > > In my ignorance of the aforementioned criteria for expecting a > registration to be reflected in a standards track document, I > would suggest the following somewhat simplified set of > principles: > > 1. The registration policy is always Expert Review. > > 2. It is preferred for each registration request to be > accompanied by a stable specification. > > 3. If such a specification is on the standards track within > the IETF, then the specification (but not the registration) > requires IETF consensus. (It might be appropriate to register > the namespace in a preliminary fashion before publication of > the specification.) I'm not sure I know what "register in a preliminary fashion" means. Again, the case I'm most concerned about is one with which we've got significant (bad) experience in other types of namespace registrations. It goes like: (i) Application is submitted for a registration using the template. (ii) Because the Expert Review and special mailing list typically consists of a small group of people talking with each other, a possibly-significant issue is not noticed and the application is registered. (iii) Applicant submits an I-D describing the registration and asking for publication and standards track status. (iv) For one reason or another, the IETF doesn't do a Last Call for an extended period. During that time, the I-D is updated several times to improve the description, but without making substantive changes. (v) The applicant community starts using the system or namespace as registered, achieving significant deployment. (vi) The IETF review process turns up technical deficiencies (or even just some improvements that might be made) that some people believe are significant. (vii) The applicant says "even if you are right, the name and namespace are registered and in use at this point, so cannot be changed". (viii) The IETF is then stuck and so is the applicant. Either we decide that standardization provides no marginal value and public the I-D as Informational (see, e.g., the recent publication approval for a DNS URI RRTYPE) or a standards track document is approved despite know technical deficiencies because the IESG decides those deficiencies are not sufficiently important to be blocking. Note that the above does not assume any malice or deliberate attempt to commit an end run of the standardization process (although I believe we have seen examples of that too). And that is the point. If someone is going to ask for standardization, the process needs to be more like: (i) Development of a first-draft I-D that contains the filled-in template in IANA Considerations, not just the template itself. (ii) Submission, registration discussion mailing list, and expert review of the I-D, resulting in a report and recommendation to the IETF, not registration. This review is likely to catch most serious problems early and presumably guarantees that someone takes a careful look at both template and specification. (iii) Submission of the I-D for IETF review and Last Call with the Expert Review report made available to the community and treated as a Shepherd report or supplement to one. (iv) Normal IETF processing, including possible changes to the I-D and template. (v) Registration as part of the usual approval and publication process. An assumption in the above distinction is that the IETF standardization process adds value in the review process. If it is just a stamp of approval and endorsement... well, a lot of us are wasting out time here. But, if the value is really in the standardization process itself, than someone who asks for standards track status probably wants the more extensive review even (or especially) if it changes the spec or template namespace definition. Now, it seems to me that reserving the name from when the process is started to when it concludes (successfully or not) would be helpful. But a name that goes into the conventional Expert Review and spends some time there is also de facto reserved during the process because the Expert would presumably reject an NID application (or encourage applicants to sort it out) if a registration request for the same NID is already being considered, so I don't see a need for a special procedure, much less IANA registration of any sort, to avoid the obvious bad case. > 4. Registrations can be modified by submitting a revised > version of the completed template. Same problem as above. If the namespace is established by registration (with or without a stable spec that might be an Informational RFC), then any stability or compatibility issues between older and newer versions are the responsibility of the registrant (the revised template rules in the draft requires that they explain what they are). But, if the namespace is specified in a standards-track document, a revision is an IETF concern and the registration should be modified only by an approved, standards-track, RFC or, for obvious errors, an IESG-approved erratum. john From nobody Fri Mar 27 09:34:58 2015 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 15ACD1AD0B6 for ; Fri, 27 Mar 2015 09:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 XLK8U6q7x2HE for ; Fri, 27 Mar 2015 09:34:56 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0064.outbound.protection.outlook.com [207.46.100.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD821ACEFB for ; Fri, 27 Mar 2015 09:34:55 -0700 (PDT) Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) with Microsoft SMTP Server (TLS) id 15.1.118.21; Fri, 27 Mar 2015 16:34:54 +0000 Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0118.022; Fri, 27 Mar 2015 16:34:54 +0000 From: Larry Masinter To: "urn@ietf.org" Thread-Topic: draft-ietf-urnbis-rfc2141bis-urn vs draft-ietf-appsawg-uri-scheme-reg and RFC1737 Thread-Index: AQHQaKv0JnNQyORu8kq8d1ZVPrVYQA== Date: Fri, 27 Mar 2015 16:34:53 +0000 Message-ID: <0D9E71DB-2B12-4AFE-A8BB-F586CDC24EC2@adobe.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150303 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.145.44] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1322; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(2351001)(2501003)(229853001)(2656002)(50986999)(15975445007)(54356999)(102836002)(110136001)(33656002)(106116001)(87936001)(92566002)(83506001)(230783001)(36756003)(46102003)(19580395003)(2900100001)(122556002)(66066001)(83716003)(82746002)(40100003)(62966003)(77156002)(86362001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1322; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR02MB1322; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB1322; x-forefront-prvs: 0528942FD8 Content-Type: text/plain; charset="utf-8" Content-ID: <72A396FB49D7C54A8DD7EB12A57EC6D6@namprd02.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2015 16:34:53.7394 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1322 Archived-At: Cc: "draft-ietf-appsawg-uri-scheme-reg@tools.ietf.org" Subject: [urn] draft-ietf-urnbis-rfc2141bis-urn vs draft-ietf-appsawg-uri-scheme-reg and RFC1737 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, 27 Mar 2015 16:34:58 -0000 ZHJhZnQtaWV0Zi1hcHBzYXdnLXVyaS1zY2hlbWUtcmVnIHJldmlzZXMgUkZDIDQzOTUsIGluY2x1 ZGluZw0KdGhlIHJlcXVpcmVtZW50cyBmb3IgcGVybWFuZW50IFVSSSBzY2hlbWVzLiBFeHBlY3Qg YSBuZXcgdmVyc2lvbg0KdmVyeSBzb29uLCBiYXNlZCBvbiBJRVRGIGxhc3QgY2FsbCBjb21tZW50 cywgSUFOQSByZXZpZXcsIGV0Yy4NCg0KSXQgaXMgY3VycmVudGx5IHNjaGVkdWxlZCBmb3IgSUVT RyB0ZWxlY2hhdCBBcHJpbCA4Lg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1hcHBzYXdnLXVyaS1zY2hlbWUtcmVnLw0KDQoNCklmIGFwcHJvdmVkLCB0aGUgcmVx dWlyZW1lbnRzIGZvciBwZXJtYW5lbnQgVVJJIHNjaGVtZXMgd2lsbA0KYXBwbHkgdG8gdGhlIOKA nHVybjrigJ0gc2NoZW1lLCBhbmQgZHJhZnQtaWV0Zi11cm5iaXMtcmZjMjE0MWJpcy11cm4uDQoN CkkgZG8gbm90IHRoaW5rIGRyYWZ0LWlldGYtdXJuYmlzLXJmYzIxNDFiaXMtdXJuIG1lZXRzIHRo ZSByZXF1aXJlbWVudHMNCmZvciBwZXJtYW5lbnQgVVJJIHNjaGVtZSByZWdpc3RyYXRpb25zLiBJ ZiB0aGUgVVJOQklTIHdvcmtpbmcgZ3JvdXANCnRoaW5rcyB0aGUgcmVxdWlyZW1lbnRzIGFyZSBp bmNvcnJlY3QsIG9yIHRoYXQgdGhpcyBpcyBhIHNwZWNpYWwNCmNhc2Ugd2hlcmUgU0hPVUxEIHJl cXVpcmVtZW50cyBkbyBub3QgYXBwbHksIHRoZW4gcGxlYXNlDQplaXRoZXIganVzdGlmeSBhbWVu ZG1lbnRzIHRvIHVyaS1zY2hlbWUtcmVnIG9yIHByb3ZpZGUgYWRlcXVhdGUNCmp1c3RpZmljYXRp b24gZm9yIHRob3NlIGV4Y2VwdGlvbnMuDQoNClRoZSByZXF1aXJlbWVudHMgSSBoYXZlIGluIG1p bmQgaW5jbHVkZSB0aGUgdXNlIG9mIOKAnC/igJwgaW4NCmEgVVJJIHNjaGVtZSB0aGF0IHdhcyDi gJxub3QgaW50ZW5kZWQgZm9yIHVzZSB3aXRoIHJlbGF0aXZlIFVSSXPigJ0sDQp0aGUgaGFuZGxp bmcgb2YgVW5pY29kZSBjaGFyYWN0ZXJzLCB0aGUgZGVmaW5pdGlvbiBvZiB0aGUNCnVzZSBvZiBm cmFnbWVudCBpZGVudGlmaWVycywgYW5kIHNlY3Rpb24gMy4zIFdlbGwtRGVmaW5lZA0KaW4gdGhl IHJlcXVpcmVtZW50IG9mIGJlaW5nIGNsZWFyIGFib3V0IGhvdyB0aGUg4oCcdXJuOuKAnSBzY2hl bWUNCmlzIGV4cGVjdGVkIHRvIGZ1bmN0aW9uLiBUaGlzIHJlcXVpcmVtZW50IGlzIHN0cm9uZ2Vy IHRoYW4NCnRoZSBSRkMgMjAyNiByZXF1aXJlbWVudC4NCg0KUkZDIDE3MzcgRnVuY3Rpb25hbCBS ZXF1aXJlbWVudHMNCg0KUkZDIDE3Mzcgd2FzIHRoZSBvcmlnaW5hbCBVUk4gd29ya2luZyBncm91 cCBjb25zZW5zdXMNCm9uIHJlcXVpcmVtZW50cyBmb3IgVVJOcy4gV2hpbGUgUkZDIDIxNDEgd2Fz IG5vdCBjb25zdHJhaW5lZA0KYnkgUkZDIDE3MzcsIGl0IGRvZXMgcHJvdmlkZSBzb21lIGp1c3Rp ZmljYXRpb24gZm9yIHRoZSBmZWF0dXJlcw0Kb2YgVVJOcyB0aGF0LCBpbiBteSBvcGluaW9uLCBy ZmMyMTQxYmlzLXVybiB3ZWFrZW5zLiBJZiB0aGVyZQ0KaXMgc29tZSBhZ3JlZW1lbnQgdGhhdCBS RkMgMTczNyByZXF1aXJlbWVudHMgYXJlIHJlbGV2YW50LA0KSeKAmWxsIHJldmlldyBvZiDigJx1 cm464oCdIGFzIGRlZmluZWQgaW4gcmZjMjE0MSB2cy4gcmZjMjE0MWJpcy11cm4gdG8NCmVuc3Vy ZSB0aGF0IHRoZSBvcmlnaW5hbCBVUk4gcmVxdWlyZW1lbnRzIGhhdmUgbm90IGJlZW4gDQppbmFk dmVydGVudGx5IG1pc3NlZCBpbiB0aGUgZWZmb3J0IHRvIHNhdGlzZnkgb3RoZXIgbW9yZQ0KY3Vy cmVudCByZXF1aXJlbWVudHMuDQoNCkxhcnJ5DQrigJQNCmh0dHA6Ly9sYXJyeS5tYXNpbnRlci5u ZXQNCg0K From nobody Fri Mar 27 09:37:50 2015 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 46FD91A1B77 for ; Fri, 27 Mar 2015 09:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 fMectYncC9gW for ; Fri, 27 Mar 2015 09:37:45 -0700 (PDT) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4A2C1A039D for ; Fri, 27 Mar 2015 09:37:41 -0700 (PDT) Received: by ignm3 with SMTP id m3so34976653ign.0 for ; Fri, 27 Mar 2015 09:37:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TN9pPrf0WDhm2rzSkiW8y2mIbFGG2Es6lPYP/+iM1co=; b=XdsnGaGYuO7mDMZUZb9KB7O0jQJ1smG9bDNshMO1HCThK/prXZ2llm0P7aafpOAoiS U4swGUBo/sX9EQpI6OLi7L5FiALcVgkdoNuvCJYBPgmo/Pg796fzbfaFFN7N4LtofkgM K+kfv8S4WOM6RirPbvNxfChwL1jgPelbNC6mZYDnTLrDmNX4RgRc2SYCWEKdLJ8YyxJ7 RPcslxPAXAYNGo5x1/TEGkaHUykcqvHx8dtp83CySu1GP1XPDnX/SbV4pgRw20Q9xarJ iglZ9vrXELInM30Ik2fffniJfmN5QUsk7PRi68UXladH1rwqojXlSmhxCh2tAv4vUvPP YWYQ== X-Gm-Message-State: ALoCoQl/QsxvqtOAUMjoEWN9A0PwEkz26v0aP5N0seUCFhIGQtyLurlifh+VcB/aNGc3FkjKz0bW X-Received: by 10.50.78.232 with SMTP id e8mr45918170igx.5.1427474261255; Fri, 27 Mar 2015 09:37:41 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id sd7sm1950632igb.20.2015.03.27.09.37.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Mar 2015 09:37:40 -0700 (PDT) Message-ID: <55158750.80200@andyet.net> Date: Fri, 27 Mar 2015 10:37:36 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: <7248E8A902BB366E16773856@JcK-HP8200.jck.com> <5514C89A.8090204@andyet.net> <023B0B823C38BCFB8ADE0063@JcK-HP8200.jck.com> In-Reply-To: <023B0B823C38BCFB8ADE0063@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Expert reveiw and draft-ietf-urnbis-rfc2141bis-urn-09 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, 27 Mar 2015 16:37:48 -0000 On 3/27/15 7:54 AM, John C Klensin wrote: > > > --On Thursday, March 26, 2015 21:03 -0600 Peter Saint-Andre - > &yet wrote: > >> On 3/4/15 8:16 AM, John C Klensin wrote: >>> We agreed some time ago that URN registrations for Formal >>> namespaces and their NIDs should be shifted from IETF >>> Consensus (see Section 4.3 of RFC 3406) to Expert Review and >>> that Expert Review should apply to Informal Namespaces as >>> well. >> >> Although I don't recall a decision to use Expert Review for >> informal namespaces, I think it makes sense for both formal >> and informal namespaces to use the same procedure. (Recent >> discussion on the urn-nid@ietf.org list indicates that this is >> important.) > > Ack. > >>> There has been some discussion in the WG (and the IETF more >>> generally) about issues with registration Expert Review, >>> especially for registrations that are expected to be reflected >>> in standards track documents. >> >> I'm not sure what the criteria are for saying that certain >> registrations are "expected to be reflected in standards track >> documents" (only within the Internet Standards Process?) >> whereas others are not. > > I think it is a matter of registrant intent. Someone who uses > the Expert Review registration process to create an NID and bind > it to a namespace definition should not then submit an I-D > asking for standards-track status. More specifically, if such > an I-D is submitted and, when IETF discussions starts, the > registrant says "already registered, can't make technical > changes", any RFC publication has to be an Informational spec > that describes what is registered, not a standards-track > document. I can imagine an exception in which the registrant > (or someone else) comes back a few years later and says "this > thing that was registered earlier has been widely deployed, has > proven useful and to not cause any problems, please > standardize", but that is a different situation -- and, because > there would be little value added, one I'd expect to be > exercised about as often as we move documents to full standard > (or less often) whether the effort at that time was to process a > new document or reclassify an existing one. OK, that helps. Most of the URN NID registrations to date have been processed in informational RFCs. I could see that continuing to some extent (since IMHO it's helpful to both registrants and reviewers if we write things up in the form of an I-D). I think part of the reason for this is that most of the registrations that I'm aware of have come from what we might loosely consider other SDOs - they're not defining standards track protocols (that just happen to be registering URN NIDs), but have their own standalone identifier space that might be used in some protocol. And even one those less common occasions where they are defining a standards track protocol, the URN namespace is not directly part of that protocol - the example I'm most familiar with is XMPP, where the protocol was defined in RFC 3920 (now RFC 6120) whereas the URNs are used for extensions to the core protocol (RFC 4854). >>> Some of that discussion is hinted >>> at in draft-ietf-urnbis-ns-reg-transition, but it has not yet >>> been reflected in 2141bis. >>> >>> For those who have not followed the other discussion, one key >>> problem is that, if something is registered with particular >>> properties and specifications and then the authors want to >>> standardize the technology, the IETF is told that discussion >>> of design choices is out of order because the registration >>> cannot be changed. That is, I hope obviously, bad news. >> >> True. However, it seems to me that this can be handled by >> allowing versioning of registrations. > > Except that, if there is _any_ deployment in places that are > hard to change, and the IETF decides that, e.g., what the > registration describes as a duck is really a rabbit, a > registration change is likely to cause interoperability > problems. We could adopt some new rules that would encourage > NIDs that look like "john.20150327a" and give special > interpretations to the relationship between it and > "john.20150327b" and "john.20150401" but I don't think we want > to go there... and that registrants would probably not take > advantage of it if we did. I'm trying to figure out how common these cases might be. And I don't think it would be the IETF who decides that a duck is really a rabbit, it would be the biological community who decides that they need to make some tweaks to the definitions of an existing identifier space, or more likely to the namespace registration. IMHO we don't want to discourage people from fixing things (say, the biologists decide that there are some security concerns and want to update the URN NID registration). In any case, the updated registration would also go through Expert Review so significant issues could be flagged at that point, no? >>> I think we are headed in the following direction, but want to >>> get confirmation (or corrections) from the WG before Peter >>> and I start struggling with draft text: >>> >>> (1) We want Expert Review, with the guidance that now appears >>> in Sections 7 and 9, for namespaces that are not intended to >>> be standardized in/by the IETF. >>> >>> (2) For namespaces intended for standardization, IETF >>> Consensus is necessary for registration although a >>> preliminary expert review may be helpful. >>> >>> (3) While namespaces that are essentially overlays on >>> identifier standards produced and managed by other standards >>> bodies, the Expert Review process is intended more as an >>> advisory and coordination on rather than one or acceptance or >>> rejection and some sort of "fast track" procedure (and/or >>> even a different review process) may be in order. I would >>> hope we can explicitly give the IESG some flexibility in >>> those situations rather than having to spell everything out >>> in 2141bis. >>> >>> (4) For namespaces that do not fall into categories (2) or >>> (3), we have a strong preference for registration, even >>> poor-quality registrations that only assure uniqueness of >>> NIDs, over a slow and/or onerous registration approval >>> process that encourages use of names without registration. >> >> In my ignorance of the aforementioned criteria for expecting a >> registration to be reflected in a standards track document, I >> would suggest the following somewhat simplified set of >> principles: >> >> 1. The registration policy is always Expert Review. >> >> 2. It is preferred for each registration request to be >> accompanied by a stable specification. >> >> 3. If such a specification is on the standards track within >> the IETF, then the specification (but not the registration) >> requires IETF consensus. (It might be appropriate to register >> the namespace in a preliminary fashion before publication of >> the specification.) > > I'm not sure I know what "register in a preliminary fashion" > means. I'd be fine without that - I thought you had suggested it in your original note. > Again, the case I'm most concerned about is one with > which we've got significant (bad) experience in other types of > namespace registrations. It goes like: > > (i) Application is submitted for a registration using > the template. > (ii) Because the Expert Review and special mailing list > typically consists of a small group of people talking > with each other, a possibly-significant issue is not > noticed and the application is registered. > (iii) Applicant submits an I-D describing the > registration and asking for publication and standards > track status. > (iv) For one reason or another, the IETF doesn't do a > Last Call for an extended period. During that time, the > I-D is updated several times to improve the description, > but without making substantive changes. > (v) The applicant community starts using the system or > namespace as registered, achieving significant > deployment. > (vi) The IETF review process turns up technical > deficiencies (or even just some improvements that might > be made) that some people believe are significant. > (vii) The applicant says "even if you are right, the > name and namespace are registered and in use at this > point, so cannot be changed". > (viii) The IETF is then stuck and so is the applicant. > Either we decide that standardization provides no > marginal value and public the I-D as Informational (see, > e.g., the recent publication approval for a DNS URI > RRTYPE) or a standards track document is approved > despite know technical deficiencies because the IESG > decides those deficiencies are not sufficiently > important to be blocking. > > Note that the above does not assume any malice or deliberate > attempt to commit an end run of the standardization process > (although I believe we have seen examples of that too). And > that is the point. If someone is going to ask for > standardization, the process needs to be more like: > > (i) Development of a first-draft I-D that contains the > filled-in template in IANA Considerations, not just the > template itself. > (ii) Submission, registration discussion mailing list, > and expert review of the I-D, resulting in a report and > recommendation to the IETF, not registration. This > review is likely to catch most serious problems early > and presumably guarantees that someone takes a careful > look at both template and specification. > (iii) Submission of the I-D for IETF review and Last > Call with the Expert Review report made available to the > community and treated as a Shepherd report or supplement > to one. > (iv) Normal IETF processing, including possible changes > to the I-D and template. > (v) Registration as part of the usual approval and > publication process. > > An assumption in the above distinction is that the IETF > standardization process adds value in the review process. If it > is just a stamp of approval and endorsement... well, a lot of us > are wasting out time here. But, if the value is really in the > standardization process itself, than someone who asks for > standards track status probably wants the more extensive review > even (or especially) if it changes the spec or template > namespace definition. > > Now, it seems to me that reserving the name from when the > process is started to when it concludes (successfully or not) > would be helpful. But a name that goes into the conventional > Expert Review and spends some time there is also de facto > reserved during the process because the Expert would presumably > reject an NID application (or encourage applicants to sort it > out) if a registration request for the same NID is already being > considered, so I don't see a need for a special procedure, much > less IANA registration of any sort, to avoid the obvious bad > case. Although I agree that we want to avoid the sorts of scenarios you've outlined, I tend to think that it's less likely with URN NID registrations (see above about most requests coming from other SDOs) than it is with things like URI schemes. However, building in some safeguards seems reasonable, as long as it doesn't unnecessarily complicate things for the vast majority of registrations. >> 4. Registrations can be modified by submitting a revised >> version of the completed template. > > Same problem as above. If the namespace is established by > registration (with or without a stable spec that might be an > Informational RFC), then any stability or compatibility issues > between older and newer versions are the responsibility of the > registrant (the revised template rules in the draft requires > that they explain what they are). But, if the namespace is > specified in a standards-track document, a revision is an IETF > concern and the registration should be modified only by an > approved, standards-track, RFC or, for obvious errors, an > IESG-approved erratum. Agreed. Peter From nobody Fri Mar 27 09:58:24 2015 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 EF0EC1A8713 for ; Fri, 27 Mar 2015 09:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 YLYOGxlrXVs4 for ; Fri, 27 Mar 2015 09:58:21 -0700 (PDT) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25581A87AA for ; Fri, 27 Mar 2015 09:58:10 -0700 (PDT) Received: by ierf6 with SMTP id f6so8305522ier.2 for ; Fri, 27 Mar 2015 09:58:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=G/YxMqoMzcmKlx+ZEyugW0btDm0ItDd9hKVces2/lXQ=; b=Is5F2oRvVfM/Z8gqUnFzAAz8mp/nYp6lgTC1xNMC1ISXgVABc6PQHNzet+LzwO7fT2 jvtNfJb4BJGrAYpPUvs0ykOvbuYxIvgaUQj5HEY0x1durnQHP2FWxPqkwTsU8R1uwW/c WUZX+ShN3UrWyPd6EOsZz6MbOPgFBxe0Hhcr6/aA0LPxL0rX5hcEVFYNgovH6StjPyhO WaAiDcu7lcdKr8VS0skcoH8ep+fOr8pXJ3fvG9nSbMv5FBZz4jT+HJU3VV9HhVGCWTOO Ki5tq97EnrEhtuHLRm+kN6rhdXrbKXz13nhPxTI54mie1SzRmI33EJ+MS+TuUP9cYCDR W0wQ== X-Gm-Message-State: ALoCoQlzmhTq5BFfWuWadrP+bQJJn07GC83Ja+83QysQNoN9ztCDqCfC/fon++x8jm8vboP6QOHk X-Received: by 10.107.169.35 with SMTP id s35mr30394307ioe.46.1427475490274; Fri, 27 Mar 2015 09:58:10 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id w3sm1999807igz.4.2015.03.27.09.58.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Mar 2015 09:58:09 -0700 (PDT) Message-ID: <55158C1D.1010404@andyet.net> Date: Fri, 27 Mar 2015 10:58:05 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Larry Masinter , "urn@ietf.org" References: <0D9E71DB-2B12-4AFE-A8BB-F586CDC24EC2@adobe.com> In-Reply-To: <0D9E71DB-2B12-4AFE-A8BB-F586CDC24EC2@adobe.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-appsawg-uri-scheme-reg@tools.ietf.org" Subject: Re: [urn] draft-ietf-urnbis-rfc2141bis-urn vs draft-ietf-appsawg-uri-scheme-reg and RFC1737 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, 27 Mar 2015 16:58:23 -0000 On 3/27/15 10:34 AM, Larry Masinter wrote: > draft-ietf-appsawg-uri-scheme-reg revises RFC 4395, including > the requirements for permanent URI schemes. Expect a new version > very soon, based on IETF last call comments, IANA review, etc. > > It is currently scheduled for IESG telechat April 8. > https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ I'm happy to see that work finishing up. > If approved, the requirements for permanent URI schemes will > apply to the “urn:†scheme, and draft-ietf-urnbis-rfc2141bis-urn. > > I do not think draft-ietf-urnbis-rfc2141bis-urn meets the requirements > for permanent URI scheme registrations. Because I at least haven't been tracking the 4395bis work, I haven't put effort into ensuring that 2141bis meets 4395bis requirements. > If the URNBIS working group > thinks the requirements are incorrect, or that this is a special > case where SHOULD requirements do not apply, then please > either justify amendments to uri-scheme-reg or provide adequate > justification for those exceptions. Until I have a chance to review 4395bis (it's been a long time since I looked at it), I won't have further comments. However, your summary below is helpful as a pointer to issues that might need attention. > The requirements I have in mind include the use of “/“ in > a URI scheme that was “not intended for use with relative URIsâ€, > the handling of Unicode characters, the definition of the > use of fragment identifiers, and section 3.3 Well-Defined > in the requirement of being clear about how the “urn:†scheme > is expected to function. This requirement is stronger than > the RFC 2026 requirement. > > RFC 1737 Functional Requirements > > RFC 1737 was the original URN working group consensus > on requirements for URNs. While RFC 2141 was not constrained > by RFC 1737, it does provide some justification for the features > of URNs that, in my opinion, rfc2141bis-urn weakens. If there > is some agreement that RFC 1737 requirements are relevant, > I’ll review of “urn:†as defined in rfc2141 vs. rfc2141bis-urn to > ensure that the original URN requirements have not been > inadvertently missed in the effort to satisfy other more > current requirements. That to me seems like a separate issue from the 4395bis conformance. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Fri Mar 27 22:20:15 2015 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 DCD3A1A1BC6 for ; Fri, 27 Mar 2015 22:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 h-5LNuyCd4_5 for ; Fri, 27 Mar 2015 22:20:12 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0094.outbound.protection.outlook.com [65.55.169.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC471A1BC8 for ; Fri, 27 Mar 2015 22:20:12 -0700 (PDT) Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1321.namprd02.prod.outlook.com (25.161.142.20) with Microsoft SMTP Server (TLS) id 15.1.118.21; Sat, 28 Mar 2015 05:20:09 +0000 Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0118.022; Sat, 28 Mar 2015 05:20:09 +0000 From: Larry Masinter To: Peter Saint-Andre - &yet , "urn@ietf.org" Thread-Topic: [urn] draft-ietf-urnbis-rfc2141bis-urn vs draft-ietf-appsawg-uri-scheme-reg and RFC1737 Thread-Index: AQHQaKv0JnNQyORu8kq8d1ZVPrVYQJ0wjQqAgAB7gAA= Date: Sat, 28 Mar 2015 05:20:08 +0000 Message-ID: References: <0D9E71DB-2B12-4AFE-A8BB-F586CDC24EC2@adobe.com> <55158C1D.1010404@andyet.net> In-Reply-To: <55158C1D.1010404@andyet.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150303 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [142.131.228.251] authentication-results: andyet.net; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1321; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(51704005)(106116001)(2656002)(87936001)(86362001)(83716003)(19580395003)(66066001)(33656002)(36756003)(122556002)(82746002)(77156002)(92566002)(62966003)(40100003)(2950100001)(2900100001)(50986999)(230783001)(83506001)(76176999)(46102003)(15975445007)(102836002)(2501003)(54356999)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1321; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR02MB1321; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB1321; x-forefront-prvs: 05299D545B Content-Type: text/plain; charset="utf-8" Content-ID: <4C08C8A4F8368347BFD4311F2B7D9F6D@namprd02.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2015 05:20:08.2241 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1321 Archived-At: Cc: "draft-ietf-appsawg-uri-scheme-reg@tools.ietf.org" Subject: Re: [urn] draft-ietf-urnbis-rfc2141bis-urn vs draft-ietf-appsawg-uri-scheme-reg and RFC1737 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: Sat, 28 Mar 2015 05:20:15 -0000 Pg0KPlVudGlsIEkgaGF2ZSBhIGNoYW5jZSB0byByZXZpZXcgNDM5NWJpcyAoaXQncyBiZWVuIGEg bG9uZyB0aW1lIHNpbmNlIEkgDQo+bG9va2VkIGF0IGl0KSwgSSB3b24ndCBoYXZlIGZ1cnRoZXIg Y29tbWVudHMuIEhvd2V2ZXIsIHlvdXIgc3VtbWFyeSANCj5iZWxvdyBpcyBoZWxwZnVsIGFzIGEg cG9pbnRlciB0byBpc3N1ZXMgdGhhdCBtaWdodCBuZWVkIGF0dGVudGlvbi4NCg0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXBwc2F3Zy11cmktc2NoZW1lLXJlZy0wNQ0K IHdhcyBqdXN0IHBvc3RlZCwgc28gbm93IEkgY2FuIHF1b3RlIGl0Lg0KDQpJIGhhdmUgdGhyZWUg aXNzdWVzIHdoaWNoIEkgdGhpbmsgYXJlIHNvbHZhYmxlIGFuZCBJ4oCZdmUgcHJvcG9zZWQgc29s dXRpb25zDQpmb3IgdGhlbSBhbGw6DQoNCj09PT09PT09PT09PQ0KDQoxLiBVc2Ugb2Yg4oCcL+KA nA0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hcHBzYXdnLXVyaS1z Y2hlbWUtcmVnLTA1I3NlY3Rpb24tMy4yDQoNCj4gU2NoZW1lcyB0aGF0IGFyZSBub3QgaW50ZW5k ZWQgZm9yIHVzZSB3aXRoIHJlbGF0aXZlIFVSSXMgU0hPVUxEIGF2b2lkDQo+IHVzZSBvZiB0aGUg Zm9yd2FyZCBzbGFzaCAiLyIgY2hhcmFjdGVyLCBpbiBvcmRlciB0byBhdm9pZCB1bmludGVuZGVk DQo+IHByb2Nlc3Npbmcgc3VjaCBhcyByZXNvbHV0aW9uIG9mICIuIiBhbmQgIi4uIiAoZG90LXNl Z21lbnRzKS4NCg0KDQpyZmMyMTQxIGRlZmluZWQgdGhlIHVybjogc2NoZW1lIGFzICJub3QgaW50 ZW5kZWQgZm9yIHVzZSB3aXRoIHJlbGF0aXZlDQpVUklzIiwgYW5kIDIxNDFiaXMgZG9lcyBub3Qg Y2hhbmdlIHRoaXMgaW50ZW50aW9uOw0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtdXJuYmlzLXJmYzIxNDFiaXMtdXJuLTEwI3NlY3Rpb24tNQ0KDQpzYXlzIGV4cGxpY2l0 bHkgIlVSTnMgYXJlIG5vdCBoaWVyYXJjaGljYWzigJ0uIGEgU0hPVUxEDQpyZXF1aXJlcyDigJx2 YWxpZCByZWFzb25z4oCdIHRvIGJlIGdpdmVuLCBidXQgSSBjYW4gZmluZCBub25lDQppbiAyMTQx YmlzLg0KDQpSZXNvbHV0aW9uOiBJIHRoaW5rIHRoaXMgY2FuIGJlIHNvbHZlZCBzaW1wbHkgYnkg c3VwcGx5aW5nDQphdCBsZWFzdCBvbmUgY29tcGVsbGluZyB1c2UgY2FzZSB3aGVyZSB0aGUgYWR2 YW50YWdlIG9mIHVzaW5nIOKAnC/igJwNCmluc3RlYWQgb2Ygc29tZSBvdGhlciBwdW5jdHVhdGlv biAobGlrZSA6IG9yIEAgb3IgISkgb3V0d2VpZ2hzDQp0aGUgcmlza3MsIGFuZCBlbnN1cmluZyBh bGwgVVJOIG5hbWVzcGFjZXMgdGhhdCBhbGxvdyAvIGFsc28NCmRvbuKAmXQgYWxsb3cg4oCYLuKA mSBvciDigJguLuKAmS4gIA0KDQoNCj09PT09PT09PT09PQ0KMi4gVXNlIG9mIOKAnCPigJ0NCg0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXBwc2F3Zy11cmktc2NoZW1l LXJlZy0wNSNzZWN0aW9uLTMNCg0KYWxzbyBzYXlzIChub3cgbW9yZSBleHBsaWNpdGx5KToNCg0K PiBGb3INCj4gZXhhbXBsZSwgdGhpcyBtZWFucyB0aGF0IGZyYWdtZW50IGlkZW50aWZpZXJzIGNh bm5vdCBiZSByZS11c2VkDQo+IG91dHNpZGUgdGhlIGdlbmVyaWMgc3ludGF4IHJlc3RyaWN0aW9u cywgYW5kIGZyYWdtZW50IGlkZW50aWZpZXJzIGFyZQ0KPiBub3Qgc2NoZW1lLXNwZWNpZmljLkEg c2NoZW1lIGRlZmluaXRpb24gbXVzdCBzcGVjaWZ5IHRoZSBzY2hlbWUNCj4gbmFtZSBhbmQgdGhl IHN5bnRheCBvZiB0aGUgc2NoZW1lLXNwZWNpZmljIHBhcnQsIHdoaWNoIGlzIGNsYXJpZmllZA0K PiBhcyBmb2xsb3dzOg0KPiBVUkkgPSBzY2hlbWUgIjoiIHNjaGVtZS1zcGVjaWZpYy1wYXJ0IFsg IiMiIGZyYWdtZW50IF0NCj4gc2NoZW1lLXNwZWNpZmljLXBhcnQgPSBoaWVyLXBhcnQgWyAiPyIg cXVlcnkgXQ0KDQpCdXQgMjE0MWJpcyBhdHRlbXB0cyB0byBkZWZpbmUgZnJhZ21lbnQgaWRlbnRp ZmllcnMgZm9yIHRoZSDigJx1cm464oCdIHNjaGVtZQ0Kc3BlY2lmaWNhbGx5IGluIFNlY3Rpb24g NSB3aGVyZSBpdCBzYXlzDQrigJzigKYgZi1jb21wb25lbnQgbmVlZCBub3QgYmUgc2VtYW50aWNh bGx5IGVxdWl2YWxlbnQgdG8gdGhlIFVSSSDigKYgDQpmcmFnbWVudCBjb21wb25lbnTigJ0gd2hp Y2ggc291bmRzIGxpa2UgaXQgaXMgdHJ5aW5nIHRvIG1ha2UgZnJhZ21lbnQNCg0KaWRlbnRpZmll cnMgZm9yIHVybiBVUklzIHNjaGVtZSBzcGVjaWZpYy4NCg0KSeKAmW0gbm90IHN1cmUgaG93IHRv IHJlc29sdmUgdGhpcywgYnV0IGhlcmUgYXJlIHR3byBwb3NzaWJsZSBwYXRoczoNCg0KSSBpbWFn aW5lZCBlYXJsaWVyIGludmVudGluZyBzb21lIGtpbmQgb2YgDQp2aXJ0dWFsIG1lZGlhIHR5cGUg Zm9yIGVhY2ggVVJOIG5hbWVzcGFjZSB0aGF0IHdhbnRlZA0Kc3BlY2lhbCBoYW5kbGluZyBmb3Ig Zi1jb21wb25lbnRzLCBidXQgaXTigJlzIGEgbG90IG9mIHRyb3VibGUNCmFuZCBhIHN1YnN0YW50 aWFsIGRlcGFydHVyZSBmcm9tICBSRkMgMjE0MSB3aGljaCBpcyBub3Qgd2VsbC1tb3RpdmF0ZWQN CnNpbmNlIG5vIHVzZSBjYXNlcyBhcmUgc3VwcGxpZWQuIA0KDQpBbiBhbHRlcm5hdGl2ZSB3b3Vs ZCBiZSB0byBjaGFuZ2UgdXJpLXNjaGVtZS1yZWcgKGFzIHdlbGwgYXMgMzk4NikNCnRvIEFMTE9X IHNjaGVtZS1zcGVjaWZpYyBmcmFnbWVudHMuIEkgZmluZCB0aGlzIG1vcmUgYXR0cmFjdGl2ZSwN CmJlY2F1c2UgdGhlcmUgQVJFIHNvbWUgdXNlIGNhc2VzIGZvciBzY2hlbWUtc3BlY2lmaWMgZnJh Z21lbnRzLA0KZS5nLiwgdGVtcG9yYWwgZnJhZ21lbnRzIG9mIHJlYWx0aW1lIFVSSXMuDQoNCj09 PT09PT09PT09PT09DQozLiBVcGRhdGUgb2YgZm9ybWFsIG5hbWVzcGFjZXMgd2l0aCDigJhFeHBl cnQgUmV2aWV34oCZDQoNCjIxNDFiaXMgcmVsYXhlcyB0aGUgcmVnaXN0cmF0aW9uIHBvbGljeSBm b3IgZm9ybWFsIG5hbWVzcGFjZXMgZnJvbSAiSUVURg0KICAgICAgIFJldmlldyIgdG8gIkV4cGVy dCBSZXZpZXfigJ0uIEluIHBhcnRpY3VsYXINCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtdXJuYmlzLXJmYzIxNDFiaXMtdXJuLTEwI3NlY3Rpb24tOC4xDQoNCnNheXMN Cj4gQSBmb3JtYWwgbmFtZXNwYWNlIHJlZ2lzdHJhdGlvbiBjYW4gYmUgcmV2aXNlZCBieSB1cGRh dGluZyB0aGUNCj4gcmVnaXN0cmF0aW9uIHRlbXBsYXRlLCBmb2xsb3dpbmcgdGhlIHNhbWUgc3Rl cHMgb3V0bGluZWQgYWJvdmUgZm9yDQo+IG5ldyByZWdpc3RyYXRpb25zLg0KDQoNClRoaXMgc2Vl bXMgdG8gYWxsb3cgZXhpc3RpbmcgbmFtZXNwYWNlIGRlZmluaXRpb25zIHdoaWNoDQp3ZW50IHRo cm91Z2ggSUVURiBhcHByb3ZhbCBhbmQgYXJlIGRlZmluZWQgYnkgSW5mb3JtYXRpb25hbA0KUkZD cyB0byBiZSB1cGRhdGVkIGJ5IEV4cGVydCBSZXZpZXcuDQoNCkJ1dCB1cmktc2NoZW1lLXJlZyBy ZXRhaW5zIHRoZSByZXF1aXJlbWVudCBpbiBzZWN0aW9uIDcNCg0KPiBSZWdpc3RyYXRpb25zIGNh biBiZSB1cGRhdGVkIGluIHRoZSByZWdpc3RyeSBieSB0aGUgc2FtZSBtZWNoYW5pc20gYXMNCj4g cmVxdWlyZWQgZm9yIGFuIGluaXRpYWwgcmVnaXN0cmF0aW9uLiAgSW4gY2FzZXMgd2hlcmUgdGhl IG9yaWdpbmFsDQo+IGRlZmluaXRpb24gb2YgdGhlIHNjaGVtZSBpcyBjb250YWluZWQgaW4gYW4g SUVTRy1hcHByb3ZlZCBkb2N1bWVudCwNCj4gdXBkYXRlIG9mIHRoZSBzcGVjaWZpY2F0aW9uIGFs c28gcmVxdWlyZXMgSUVTRyBhcHByb3ZhbA0KDQpJIHRoaW5rIGluIHRoZSBjYXNlIG9mIHVybjos IHRoZSBkZWZpbml0aW9uIG9mIHVybiBVUklzIGhhcw0KDQpiZWVuIGRlbGVnYXRlZCB0byBuYW1l c3BhY2UgZGVmaW5pdGlvbnMsIGJ1dCB0aGUg4oCcb3JpZ2luYWzigJ0NCmRlZmluaXRpb24gb2Yg dGhlIHNjaGVtZSBvdmVyYWxsIGlzIGN1cnJlbnRseSBpbiBhIHNldCBvZg0KSUVTRy1hcHByb3Zl ZCBkb2N1bWVudHMuIEkgc3VwcG9zZSB0aGUgSUVTRywgYnkgYXBwcm92aW5nDQoyMTQxYmlzLCB3 b3VsZCBiZSBhcHByb3ZpbmcgdGhlIGNoYW5nZS4gDQoNCkhvd2V2ZXIsIHRoZSBwcm9ibGVtIGlz IHRoYXQgaXQgbGVhdmVzIGEgcmFmdA0Kb2YgcHJldmlvdXNseSBJRVNHLWFwcHJvdmVkIFJGQ3Mg aW4gdGhlIFJGQyBzZXJpZXMNCm1hcmtlZCBhcyBJbmZvcm1hdGlvbmFsIHdoZW4gdGhleSBzaG91 bGQgYmUgSGlzdG9yaWMuDQoNClJlc29sdXRpb246IGNoYW5nZSAyMTQxYmlzIHNlY3Rpb24gNyB0 bw0Kbm90ZSB0aGF0IGluIHRoZSBjYXNlIG9mIHVwZGF0aW5nIHRoZSByZWdpc3RyeSBmb3IgYSBu YW1lc3BhY2UNCnRoYXQgd2FzIHByZXZpb3VzbHkgZGVmaW5lZCBieSBhbiBJbmZvcm1hdGlvbmFs IFJGQywNCnRoZSBJRVNHIHNob3VsZCBiZSBhc2tlZCBmaXJzdCBmb3IgYXBwcm92YWwgdG8gbWFy ayB0aGUNCnByZXZpb3VzIGRlZmluaXRpb24gUkZDIGFzIGhpc3RvcmljLg0KDQpMYXJyeQ0K4oCU DQpodHRwOi8vbGFycnkubWFzaW50ZXIubmV0DQoNCg0KDQoNCg0KDQoNCg0K From nobody Sat Mar 28 00:20:43 2015 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 34E361A1EFE for ; Sat, 28 Mar 2015 00:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no 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 nDlUmjtxFOTP for ; Sat, 28 Mar 2015 00:20:38 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4C31A1EFD for ; Sat, 28 Mar 2015 00:20:37 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4977120A41 for ; Sat, 28 Mar 2015 03:20:33 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Sat, 28 Mar 2015 03:20:36 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=rQuMgmD/3Bj/GmA 57yTWazS2SY0=; b=MZPhgbPfDUd8H0yqVvJ9DMaBo9kd68xFdDbiJ7a06hcpLoO Is42lDhWWge3BK8j2PMHd9Xbn0Mx32gr3KElHEwckJ4/UxMRdCef7ypi54nurIuK FEoweim6Zdjb3zuQBXo8aMUfiBI90PdHYiu5Oia33kQwnCjky6toQ976GdIQ= X-Sasl-enc: 7uH/ppJhYDrLQuPj5VR5q7NRYtdKRTyWCOGIY9qaDRfn 1427527235 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id CE64B680166; Sat, 28 Mar 2015 03:20:35 -0400 (EDT) Message-ID: <55165642.10509@network-heretics.com> Date: Sat, 28 Mar 2015 03:20:34 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: urn@ietf.org References: <0D9E71DB-2B12-4AFE-A8BB-F586CDC24EC2@adobe.com> <55158C1D.1010404@andyet.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] draft-ietf-urnbis-rfc2141bis-urn vs draft-ietf-appsawg-uri-scheme-reg and RFC1737 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: Sat, 28 Mar 2015 07:20:40 -0000 On 03/28/2015 01:20 AM, Larry Masinter wrote: >> Until I have a chance to review 4395bis (it's been a long time since I >> looked at it), I won't have further comments. However, your summary >> below is helpful as a pointer to issues that might need attention. > https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-05 > was just posted, so now I can quote it. > > I have three issues which I think are solvable and I’ve proposed solutions > for them all: > > ============ > > 1. Use of “/“ > > https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-05#section-3.2 > >> Schemes that are not intended for use with relative URIs SHOULD avoid >> use of the forward slash "/" character, in order to avoid unintended >> processing such as resolution of "." and ".." (dot-segments). > > rfc2141 defined the urn: scheme as "not intended for use with relative > URIs", and 2141bis does not change this intention; > https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-10#section-5 > > says explicitly "URNs are not hierarchicalâ€. a SHOULD > requires “valid reasons†to be given, but I can find none > in 2141bis. > > Resolution: I think this can be solved simply by supplying > at least one compelling use case where the advantage of using “/“ > instead of some other punctuation (like : or @ or !) outweighs > the risks, and ensuring all URN namespaces that allow / also > don’t allow ‘.’ or ‘..’. A use case would help, but that still doesn't address the problems that result with use of URNs and relative URIs in documents that change over time, so that those combinations of URNs and relative URIs become invalid, inaccessible, meaningless, or change meanings. Part of the problem may be that we're used to thinking of the result of a base URL and a relative URI as being another URL. But if a base URN is combined with a relative URI, the result looks like a URN but (absent some guarantees that aren't supplied in 2141bis) doesn't necessarily have the persistence properties of a URN. But even if this can somehow be finessed, I think the use of relative URIs with base URNs (when the latter refer to resources whose contents change over time) still creates a strong incentive to change the meanings of existing URNs. > > ============ > 2. Use of “#†> > https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-05#section-3 > > also says (now more explicitly): > >> For >> example, this means that fragment identifiers cannot be re-used >> outside the generic syntax restrictions, and fragment identifiers are >> not scheme-specific.A scheme definition must specify the scheme >> name and the syntax of the scheme-specific part, which is clarified >> as follows: >> URI = scheme ":" scheme-specific-part [ "#" fragment ] >> scheme-specific-part = hier-part [ "?" query ] > But 2141bis attempts to define fragment identifiers for the “urn:†scheme > specifically in Section 5 where it says > “… f-component need not be semantically equivalent to the URI … > fragment component†which sounds like it is trying to make fragment > > identifiers for urn URIs scheme specific. > > I’m not sure how to resolve this, but here are two possible paths: > > I imagined earlier inventing some kind of > virtual media type for each URN namespace that wanted > special handling for f-components, but it’s a lot of trouble > and a substantial departure from RFC 2141 which is not well-motivated > since no use cases are supplied. > > An alternative would be to change uri-scheme-reg (as well as 3986) > to ALLOW scheme-specific fragments. I find this more attractive, > because there ARE some use cases for scheme-specific fragments, > e.g., temporal fragments of realtime URIs. Good catch. I don't think this can be fixed without updating 3986. I'm personally sympathetic to the idea that fragments should be defined differently for URNs than for URLs. But this still begs the question of how to interpret fragments for URNs that resolve to URLs. If urn:X resolves to http:Y, should urn:X#z resolve to http:Y#z or what? I'm really uncomfortable with the notion that using a URN to name a resource that also has a URL means that you can't address a fragment of that resource, or that there are potentially different names for the same fragments of that resource. Keith From nobody Sat Mar 28 07:48:47 2015 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 9E0931A886F for ; Sat, 28 Mar 2015 07:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 enk9o6iq75Eh for ; Sat, 28 Mar 2015 07:48:45 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4AB1A8868 for ; Sat, 28 Mar 2015 07:48:44 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3C471204AA for ; Sat, 28 Mar 2015 10:48:41 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Sat, 28 Mar 2015 10:48:44 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=UAnKnNk1Slq8v+r/FjvU9IoKDi0=; b=HKib6 nxLjqPOP/SINASiVAb3e3jgoTWZITWmMjidcjpDf5jcV7XBlTk47dBdt4hM+FUk/ Qev2aLRkZCiKDs1mCtpTb9yYCpo41QaZrmE/ekMg570FdkK9W17hDw48vnM+BjOp pISJP9Pyp5dVeQ/8ZO8yUJaE1K6aYqrID+mmVo= X-Sasl-enc: KCgg46pPJz5Zms0n/saXe78KiisgAFPZ6jMV8QNNQuKF 1427554123 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id C6471C00015; Sat, 28 Mar 2015 10:48:43 -0400 (EDT) Message-ID: <5516BF4A.3040902@network-heretics.com> Date: Sat, 28 Mar 2015 10:48:42 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] another problem with 2141bis-10 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: Sat, 28 Mar 2015 14:48:45 -0000 I realized after I got home from Dallas that another problem with 2141bis is that it doesn't specify which parts of a URN that contains f-, p-, and/or q-components are significant for resolution and should be presented to a resolution service. If this varies from one namespace to another, it's going to make it much harder to build general-purpose resolution code. Keith From nobody Sat Mar 28 14:59:57 2015 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 170D51A9046 for ; Sat, 28 Mar 2015 14:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 iR5slEYJY9uR for ; Sat, 28 Mar 2015 14:59:52 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D4161A9041 for ; Sat, 28 Mar 2015 14:59:52 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 52C7720805 for ; Sat, 28 Mar 2015 17:59:48 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 28 Mar 2015 17:59:51 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=MEHVtaBVOsZT/TM vddRwWWSV7f0=; b=tZtkR+FRXhOzFB60zPLSVrAHqETmcZC7r+LckK73chaGO0H MzhkE4xOQ02MbWhj52A6xchyMuJnq3wIY01+L7CJfqEWyVrw/TheW4thwfD4jaEh TDUdQZtMolPAOEu4pBqfTQwBPAz1RbQdykr3Z2EKEo5dEaj68GebuJt63gkI= X-Sasl-enc: d0onogEXhfeiB7MGx9Z5pv89xsUDU+W8c7/LX1/h2pqG 1427579990 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id D5C61C00013; Sat, 28 Mar 2015 17:59:50 -0400 (EDT) Message-ID: <55172454.40502@network-heretics.com> Date: Sat, 28 Mar 2015 17:59:48 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: urn@ietf.org References: <55142CA1.2000509@network-heretics.com> <5FE5D998-3ADD-4E17-BD48-64995A914153@network-heretics.com> <55143EEA.1060303@gmail.com> <5514433D.7010604@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] Keith's review of draft-ietf-urnbis-rfc2141bis-urn-10 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: Sat, 28 Mar 2015 21:59:56 -0000 On 03/27/2015 07:37 AM, John C Klensin wrote: > Keith, > > I want to respond to what I think are a few meta-issues -- the > more specific ones are covered in separate notes which I'm > working on but may not finish before the weekend. > > --On Thursday, March 26, 2015 13:34 -0400 Keith Moore > wrote: > >> On 03/26/2015 01:16 PM, Melinda Shore wrote: >>> On 3/26/15 12:07 PM, Keith Moore wrote: >> ... >>> My concern is that we not get stuck is a loop where someone >>> keeps raising the same issue and others keep providing the >>> same answer, and there's no progress or willingness to >>> compromise. >> That's a valid concern. Please note that these issues for >> the most part have been ignored in the past rather than the WG >> attempting to address them, and also that I did try to suggest >> compromises in my recent revie > In some cases, I think you are confusing "didn't know what to do > with your comments" or "disagreed with you", with "ignored". There have definitely been cases when I didn't know what to do with others' comments also. Especially when they were insulting, or veiled personal attacks, or they indicated that the author didn't understand URNs, or at the very least that the author was coming from such a different frame of reference that it was unclear as to how to reconcile the differences. But for most of the issues I've raised, if there's actually been substantive discussion that came from people who actually understood the issues, I've missed it. Feel free to point out those occasions so I can go back and reread the mailing list discussion on the topic. But of course when I try to bring up an important issue and the feedback I get seems to indicate that the people who responded don't understand the issue, it doesn't make the issue any less important. > >> Also, when the consistent answer that I'm given whenever I >> raise objections is not technical, but rather, "we have to do >> what this narrow set of people want otherwise they'll take >> URNs to be standardized elsewhere", I think that actually >> creates a serious process problem. Nothing in 2026 says that >> we can standardize technically flawed documents just because >> of a threat from another standards body. > And no one has proposed standardizing anything technically > flawed, at least unless the "flaws" are the result of balancing > tradeoffs with other technical issues and concluding that the > balance is against your preferred outcome. > > On the issue of other communities and standards bodies, I've > been louder about the issue, and the issue of trying to avoid a > fork, than, I think, anyone else. There are several separate > issues involved in that and my motivation for it: > > (i) I've have raised the potential for a fork -- either to a > competing standard to to a community just doing whatever they > like and ignoring the IETF-- several times, not in the interest > of getting particular features but as a caution about continuing > to go around in circles without making progress. Perhaps that's because certain people's definitions of "progress" conflict with others. IMO, balkanazation of URN space is not progress, and neither is redefining URNs in such a way that it's infeasible to build a general-purpose resolution service (or that, because the resolution service has to special-case the handling of namespaces, certain namespaces get marginalized). > (ii) What actually happened here was that the folks from the > other communities came to us, asking that extension work on URNs > be done in the IETF. Their doing so was based on the beliefs > that one standard was better than conflicting ones, that we had > critical expertise, and that we could get the work done quickly > and efficiently (something that the "IETF Last Call request on > everything by April and July 2011" schedule reinforced). > Various people from that community have been active on the WG's > mailing list, have been authors or co-authors of documents and > contributed text to others, and so on -- much more active than > any of the original URN designers than anyone but Andy (although > I don't know if you put him in that category or not or how you > define that category). Their bringing the work to us are > participating in our efforts should, IMO, be cited as an > outstanding example of cooperation, not criticized for trying to > explain to us what functionality they want and need. Let me be clear that I don't fault people from other communities for trying to get URNs revised within IETF. I'm happy, even flattered, that they find URNs useful, and I want to find a way to let them continue to use URNs without getting in the way of other uses of URNs. But I think IETF has done a really lousy job of connecting those people with the constituencies that created URNs in the first place, and trying to help them find a common vocabulary and vision and to reconcile their differences. You can't accomplish that by just setting up a WG and and a mailing list and hoping that everything will be peachy. That kind of approach can work when everyone in the room has more-or-less the same investment and the same problem definition, but it doesn't work when you're trying to get people with vastly different views, business models, etc. to compromise. Neither consensus nor technical soundness is likely to result from that. (Of course, IETF has problems apart from that, including that the vast majority of the IETF participants really don't understand why URNs are useful at all, or why they need to be different than URLs. And of course there multiple constituencies who continue to be annoyed by URNs because URNs conflicted with their One True Design for either resource identifiers. The IETF consensus process really assumes that there aren't too many people trying to be disruptive - a problem we've been aware of for a very long time but have never figured out how to address because it's often difficult to distinguish someone being disruptive from someone who really does have deeper insight.) > Ѫ What I > think we owe them in return (both ethically and pragmatically) > is to move forward expeditiously and to either adapt to their > needs or explain why not and propose alternatives. We have done > neither. I've tried, on various occasions, to do that, and my recent list of issues was another attempt. > (iii) The IETF has been consistent about wanting change control > over its standards. There is some pride of ownership in that, > but it has been, at least IMO, largely to avoid accidental or > deliberate forks and the confusion they cause. At the same > time, most of us are aware, most of the time, that the Protocol > Police are hard to find when needed and/or ineffective: the IETF > has no way to require compliance and, if people want to ignore > us and go their own way, even while using that same identifiers > we have defined and used, there is little or nothing we can do > to stop them. But, while the IETF has claimed (and, so far, > kept) change control over URNs, that is _IETF_ change control. > Contrary to an inference that could be made from your plenary > remarks, our procedures and culture have never given special > precedence to either the views of original authors or designers > nor to people who have been active elsewhere in the IETF. I'm not sure exactly what I said that you're referring to. But I don't claim "special precedence" for myself or anyone else. I do claim that the people who were deeply involved in getting URNs standardized actually understand URNs, that they spent many years hashing out the delicate technical compromises that went in 2141 and other documents, and which 2141bis simply discards without addressing any of the problems that caused those compromises to be crafted, and that simply dismissing the views of any of those people (including myself) as either uninformed, irrelevant, or merely a difference of opinion is counterproductive at best, and perhaps even delusional. > For > better or worse, those who participate actively in a WG tend to > have more influence on it than those who either do not > participate at all or who show up intermittently, complain, and > then disappear again for an extended period. Sometimes that > works out well, sometimes less so -- I'd like to believe that, > if you, myself, and a few obvious others had been more > consistently active when what became 3986 was being developed, > we'd be having different discussions now. My recollection is that I tried, but 3986 was railroaded through. But it has been a disaster. We've already found it necessary to try to correct its redefinition of "URN", the syntax is problematic as I've pointed out elsewhere, and the point Larry raised about the way it defines fragments is also problematic. And if 3986 has misled URN implementors into thinking that it's okay to use / and ? and # with URNs, that's another huge set of problems that it has caused. > > (iv) Partially because of those millions of deployed URN > references (something the IETF should normally consider "running > code"), the one choice the external communities have not given > us is to say "freeze URNs to the technical specification content > of RFC 2141; anyone who wants to do anything else needs to adopt > a new scheme". Insofar as that position has merit (and you > will recall that it was more or less proposed again as recently > as the Toronto meeting), the IETF rejected it in the first > charter for this WG. I want to make very clear that I don't want to break any "running code" that conforms to 2141. I don't even want to break "running code" that doesn't conform to 2141. I don't want to invalidate any URNs that have already been minted. I just want URNs to continue to be useful as names for network-accessible resources, and to allow them to be resolved in a general way, with as few special-case exceptions for individual namespaces as possible. Whenever we face a situation where there's a significant body of "running code" that doesn't conform to our standards, it presents us with a dilemma, especially when that body of "running code" is contrary to good practice or impedes our ability to evolve the standard in a way that's technically sound and meets community needs. The only way that we can be useful is by building consensus, so we don't want to fragment the user or implementor community. And yet we're also here to try to promote technical soundness and improve the utility of the Internet, so when people insist on standardizing poor or variant practice, that's counterproductive to our goals. If there are namespaces that have been using f-components, p-components, and/or q-components, contrary to RFC 2141, I think we should document and bless them as special-case exceptions and continue to allow them to operate in that way. We should describe how each of those schemes uses those components, which parts are persistent, etc. But that doesn't compel us to standardize that syntax, or to standardize use of those components in such a way that code that processes URNs has to know about the specifics of each namespace. An implementor of a general-purpose resolution service or the client code for such a service can live with a small number of special-case exceptions. But permitting an arbitrary number of exceptions, or allowing every namespace to define its own behavior, really isn't a standard at all. It's precisely the sort of failure to resolve known design choices that 2026 forbids. >> Also, it's entirely possible that the reason that the WG is >> stuck in a loop is that it has failed to attract the attention >> of, or even alienated, the constituency that created URNs in >> the first place. I'm hoping that it's not too late to get some >> of those people to contribute their input. > I'm not sure which constituency (and designers) you are > referring to. Karen Sollins (RFC 2276, 1737, etc.) has not be > active in the IETF for many years. Michael Mealing (author of > the RFC 3401-3405 DDDS specs) has been gone almost as long as > has Ryan Moats (author of 2141). Larry Masinter (co-author of > 1737) has popped up periodically in WG meetings or on the list > but mostly, AFAICT, to advocate for the interpretation and > application of 3986 that you appear to detest. I'd certainly > be happy to hear more from those people (and from you and > Leslie), but I don't know how long the WG can reasonably be > expected to wait. Again, the WG is now five years old. Granted that it's been a long time, and old WGs often have trouble making any progress at all. The worst possible way for a WG to conclude is for everyone to be so tired that nobody is willing to expend the energy required to understand anyone else, and/or the participants are so fed up with one another that nobody wants to listen to anyone else who disagrees with him. And yet, I honestly believe that 2141bis has serious problems, and from the folks I talked to last week in Dallas, I'm pretty sure I'm not the only one who shares that opinion. So I'm trying to provide useful input, also trying to get others to do so. And I'd appreciate it if people wouldn't just dismiss it out of hand. > >>> It's an unfortunate fact that very few IETF participants have >>> the grace to be able to say "I don't agree but I can live >>> with that" and sometimes it seems more common than not for >>> disagreements to become blocking. >> I say that all the time. This, however, is not one of those >> cases. Several of us spent several years of our lives trying >> to get URNs defined. I personally don't want to see them made >> useless for most of the use cases for which they were >> intended, and I suspect I'm not the only one who feels that >> way. > I appreciate your engaging in an actual discussion this time, > but I just don't see "made useless for most of the use cases for > which they were intended" in any of this. That by itself is reason for concern. I don't think it's because I've failed to explain why this is the case. > The WG has, IMO, been > very clear about its intention that no URN or namespace > definition that is valid under RFC 2141 will become invalid with > whatever changes we are making. My sense is that principle is > one of the things about which there is very broad consensus that > includes just about all participants other than those who > believe that URNs were a bad idea from the beginning and should > be abolished. I agree with that also. I don't think any of the concerns that I mention are about 2141-conforming behavior; I think they're all about ways that 2141bis departs from 2141 without addressing the problems that result from such departures. In particular, 2141 disallowed fragments, paths, and queries for the very good reason that we didn't know how to do them in ways that preserved the persistence properties that we wanted for URNs. I don't think that we thought those problems were insurmountable, but we did think they'd need to be addressed explicitly, that it would take awhile to understand how to do that, and that we shouldn't block standardizing bare URNs until we got those problems addressed. > > I'll address your relative reference and comparison issues in > the response to details, but I don't think they change the above. > >> ... > Now we (or at least I) face one of those nasty tradeoffs that, > in the light of your comments, seems worth making explicit and > public. I have limited time to spend on IETF issues and cannot > devote even all of that time to URNs. Peter and I have > committed to get -11 of 2141bis posted before Wednesday and to > have it reflect issues that seem to have been resolved in WG > mailing list discussions. I need to cross-check text that Peter > has developed this week before we post. I'm going to > prioritize that over finishing the point-by-point response to > your detailed comments that I've been working on since shortly > after you posted that note. The comments are _not_ being > ignored, I'm just trying to make decisions about the most > efficient overall way to proceed and I'm quite confident that, > even if I were to respond to you immediately, there would be no > way to reach enough of a WG conclusion about the issues to have > the result reflected in an I-D next week ... especially so given > your comments about the changes you believe are required > implying major rewrites, not just adjustment to the text of a > few sections. That's fine, and I appreciate the heads up. Keith From nobody Sun Mar 29 11:19:05 2015 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 BEE2D1A6F87 for ; Sun, 29 Mar 2015 11:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 dsiEfzgtK665 for ; Sun, 29 Mar 2015 11:19:02 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00661A6F5D for ; Sun, 29 Mar 2015 11:19:01 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YcHnV-000EYQ-4c; Sun, 29 Mar 2015 14:18:57 -0400 Date: Sun, 29 Mar 2015 14:18:52 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: <9176873CA947DB9D9175A34F@JcK-HP8200.jck.com> In-Reply-To: <55172454.40502@network-heretics.com> References: <55142CA1.2000509@network-heretics.com> <5FE5D998-3ADD-4E17-BD48-64995A914153@network-heretics.com> <55143EEA.1060303@gmail.com> <5514433D.7010604@network-heretics.com> <55172454.40502@network-heretics.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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] General-purpose resolution service (was: Re: Keith's review of draft-ietf-urnbis-rfc2141bis-urn-10) 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: Sun, 29 Mar 2015 18:19:03 -0000 --On Saturday, March 28, 2015 17:59 -0400 Keith Moore wrote: >> (i) I've have raised the potential for a fork -- either to a >> competing standard to to a community just doing whatever they >> like and ignoring the IETF-- several times, not in the >> interest of getting particular features but as a caution >> about continuing to go around in circles without making >> progress. > > Perhaps that's because certain people's definitions of > "progress" conflict with others. IMO, balkanazation of URN > space is not progress, and neither is redefining URNs in such > a way that it's infeasible to build a general-purpose > resolution service (or that, because the resolution service > has to special-case the handling of namespaces, certain > namespaces get marginalized). I want to isolate this issue because it may be important. There are, for better or worse, some topics that, however important or interesting, are properly just not within the WG's scope. To start with one we probably agree about, there has been a recent discussion on the IETF list about getting rid of the "urn prefix". I think Phillip is wrong, so, apparently, do you, Peter, Dave Cridland, and others. I don't know whether all of us completely agree on the reasons. But, as far is the WG is concerned, the bottom line is that we aren't chartered to figure out whether URNs as an URI scheme were a good idea. At least as important, the ship has clearly sailed on the question: as someone pointed out on that list, even if the IETF were to somehow magically conclude tomorrow that URNs were a bad idea, reclassifying the scheme name as "a prefix" and then getting rid of it would cause more disruption than it could possibly be worth. It may or may not be relevant, but I also note that Phillip has an interpretation of generic URI syntax that, however much it appeals to some of us, is diametrically opposed to and inconsistent with any interpretation of 3986 as normative beyond a division between scheme name and whatever follows it. With that as preface, a good deal of the early thinking about URNs was closely tied notions of a single, general-purpose, resolution service and, in particular, to the one that became DDDS. From reading the DDDS specs, I assume that what at least some people had in mind was that one namespace would imply one NID and one instance of a resolver that could be found by interpreting "/urn:([^:]+)/\\1/i" and that there would be no exceptions to that convention. Whatever the merits of that idea, it was not a requirement in RFC 3406 (section 1 says: 'If "resolution" of any so-created URN identifiers is desired, a separate process of registration in a global NID directory, such as that provided by the DDDS system [RFC3401], is necessary.' ) and note "such as" rather than a requirement and the anticipation that "resolution" may not be necessary. Equally important, the idea of a single required resolution mechanism or database, or a restriction of URNs to online objects, was essentially dead as soon as RFC 2288 -- a document on which RFC 3406 and its predecessor RFC 2611 rely -- was published in 1998. If anything, it was even more obsolete as an assumption when we started using URNs that don't resolve at all such as the XMPP ones that have been referred to as "indicators" in discussions in this WG. If those changes and uses are what you are thinking of when you warn about balkanizing (sic) URNs, it seems to me it is much too late to be raising that issue. Perhaps sadly, that leaves the choice of resolution mechanisms, or even mechanisms for finding resolution mechanisms (however general or specific) to be sorted out on a per-namespace basis. The WG has discussed the best way to say that and deal with some of its consequences in 2141bis, but the actual decision dates to 2141 and earlier. It is possible that regrettable decisions were made along the line. I suggested in an earlier note that, in retrospect, it might have been wise to break URNs up into classes/ categories and use a different scheme for each so that, e.g., we would have had "ddds:" and "indicator:" schemes. But that wasn't done and reconsidering it, as well as designating an exclusive or even primary class of URN usage, isn't in scope for the WG as far as I can tell. Again, that ship has sailed and, IMO, complaining that this WG is doing bad things or ignoring key issues because it was not chartered to go back and revisit those very old issues (and has not done so)-- issues that have been settled by decade-old documents and common practices-- seems unreasonable to me. YMMD, but, if that is where we disagree, I hope we can at least be clear about it. best, john From nobody Sun Mar 29 11:41:01 2015 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 9A7341A7017 for ; Sun, 29 Mar 2015 11:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.29 X-Spam-Level: * X-Spam-Status: No, score=1.29 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 uZQc9OnpGms6 for ; Sun, 29 Mar 2015 11:40:57 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159B41A036B for ; Sun, 29 Mar 2015 11:40:57 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YcI8l-000Ent-VJ; Sun, 29 Mar 2015 14:40:55 -0400 Date: Sun, 29 Mar 2015 14:40:50 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: <85FB58DE07D859CA5E2E69EF@JcK-HP8200.jck.com> In-Reply-To: <55165642.10509@network-heretics.com> References: <0D9E71DB-2B12-4AFE-A8BB-F586CDC24EC2@adobe.com> <55158C1D.1010404@andyet.net> <55165642.10509@network-heretics.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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] Fragments and URN pass-through components (was: Re: draft-ietf-urnbis-rfc2141bis-urn vs draft-ietf-appsawg-uri-scheme-reg and RFC1737) 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: Sun, 29 Mar 2015 18:40:58 -0000 --On Saturday, March 28, 2015 03:20 -0400 Keith Moore wrote: >> An alternative would be to change uri-scheme-reg (as well as >> 3986) to ALLOW scheme-specific fragments. I find this more >> attractive, because there ARE some use cases for >> scheme-specific fragments, e.g., temporal fragments of >> realtime URIs. > > Good catch. I don't think this can be fixed without updating > 3986. Well... Variations on this have been raised and discussed, although with little response on the list. I hope you folks have been reading it and am disappointed this didn't come up earlier. First, the "syntax only" decision makes the binding that 3986 specifies between fragments and media types inapplicable to URNs and hence allows URN-scheme-specific fragments and fragment interpretation. I hope we don't need to revisit that issue. I agree that there is a more general issue and that it needs to be addressed in a revision or update of 3986, but that isn't a URNBIS WG problem. That leads to... > I'm personally sympathetic to the idea that fragments should > be defined differently for URNs than for URLs. But this > still begs the question of how to interpret fragments for URNs > that resolve to URLs. If urn:X resolves to http:Y, should > urn:X#z resolve to http:Y#z or what? I'm really > uncomfortable with the notion that using a URN to name a > resource that also has a URL means that you can't address a > fragment of that resource, or that there are potentially > different names for the same fragments of that resource. This is part of a more general problem that concerns me (and that, again, has been raised earlier). Let's examine URNs that resolve to one or more URLs and ignore other types of URNs for a moment. Can one plausibly assume that all of those URLs (or whatever resolves or executes them) will consider the same set of, e.g., queries or fragments to be plausible? If not, do we care and, in particular, does that violate whatever we think we mean by persistence? Note that "persistence" gets tricky in this case. If one assumes that the URN identifies a document, like the content of an RFC, that will [soon] be available in multiple forms and with multiple online locations/copies of each form, the URLs to which the URN might lead are not only not all equal but different members of the set point to those different instantiations of something the RFC Editor is required to believe are the same content and therefore the rest of us are too. It may be that invalidates the urn:ietf:rfc sub-namespace as insufficiently persistent the moment the alternate forms start being published but, if so, I see that as a problem for the RFC Editor and not this WG. If it does not invalidate the namespace completely, one interesting question (which has come up in the WG before) then becomes whether it would be legitimate to have a URN with a query component that looked essentially like: urn:ietf:rfc:9999?format=pdf (I note that is _not_ possible without a redefinition and registration of the "ietf" namespace and its "rfc" sub-namespace (or whatever one calls those) because 2141bis is quite specific that, if a registration doesn't explicitly legitimize q-components for a particular namespace, they are not permitted.) The important characteristic of the above is the "?format=pdf" really is qualifying information for the base URN, telling the URN "resolver" which URLs from the collection that would be possible without it to to return, and not a query to be applied to one or more of those URLs. Contrast it with urn:ietf:rfc:9999#Section3.1 or, if you prefer urn:ietf:rfc:9999?Section=3.1 Where the f- and q-components are almost certainly intended to be passed through to the URLs as fragments or queries. >From at least one perspective, distinctions between the object associated with an identifier and assorted metadata associated with either the object or the identifier are just special cases of the "instructions to the URN resolver" case. We don't have any lexical or other namespace-independent way to distinguish between the "instructions to the URN resolver" and "instructions to be passed through to the URL" cases. We've raised it on the list, with proposals to * Reserve q-components for local instructions and f-components for pass-through and vice versa * Create some special, scheme-wide (i.e., applying to all URN namespaces that allow the relevant components) syntax or keywords to separate the two cases. I don't believe that either of those notions, or anything else that has been proposed, has gotten nearly enough traction in the WG to justify a specification that would apply across the collection of namespaces. So we are left with a per-namespace situation that leaves notions of generic resolvers, even for the narrow range of cases in which URNs are known to resolve to URLs (or a selection from a family of URLs) in even more trouble. I, at least, would welcome suggestions. Lamenting the state we find ourselves in seems less helpful. best, john From nobody Sun Mar 29 13:12:51 2015 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 C5C7F1A88BD for ; Sun, 29 Mar 2015 13:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 BT7DEWmSDC7o for ; Sun, 29 Mar 2015 13:12:48 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844661A889D for ; Sun, 29 Mar 2015 13:12:48 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YcJZf-000FyN-DW for urn@ietf.org; Sun, 29 Mar 2015 16:12:47 -0400 Date: Sun, 29 Mar 2015 16:12:42 -0400 From: John C Klensin To: urn@ietf.org 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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] draft-ietf-urnbis-rfc2141bis-urn vs draft-ietf-appsawg-uri-scheme-reg 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: Sun, 29 Mar 2015 20:12:50 -0000 Hi. I've avoiding cross-posting, but this just-sent note seems relevant to this WG. People who want to discuss it would probably take it up on apps-discuss and/or with the IESG. Observation: The more steps we need to take along this path, the more I think it may be useful for this WG to reconsider the decision that turned "URNs are not URIs" into "syntax only" and possibly return to the former. Whatever the advantages or disadvantages of that approach, it would clearly take this WG out of arguments (or confine them to discussions about the needs of URNs in isolation) about relative URIs, applicability of various parts of 3986, and URI registration and other documents that are argued to have retroactive effect. john ---------- Forwarded Message ---------- Date: Sunday, March 29, 2015 16:05 -0400 From: John C Klensin To: Alexey Melnikov , Barry Leiba Cc: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt (reposting -- the IETF mail system apparently didn't like the "implicit" copy to apps-discuss) --On Sunday, March 29, 2015 15:05 +0100 Alexey Melnikov wrote: > On 27/03/2015 19:29, Barry Leiba wrote: >>> I will send email responses to the feedback received with >>> what we did. I may not get those out today though. But I >>> think the doc should be ready for the IESG telechat. >> Thanks. I've issued the ballot; I'll wait to change the >> state until I hear that your co-authors & shepherd are OK >> with it. > This is almost perfect :-). > > A couple of comments: > ... > Here is a real world example of a problem with this text. SIDR > WG decided to use rsync protocol, they needed to use rsync > URIs. rsync URIs are currently provisional, defined in an > Informational RFC. So this text is basically saying that > under the new rule the registration have to be upgraded to > Permanent, allowing the expert reviewer (no disrespect to > Graham or his future replacement) to be a person that blocks > consensus of a WG to use a particular technology. I find this > to be problematic. > > Do people agree that this is problematic? Yes. At the risk of tossing a spanner toward the works, one more issue that seems to me very significant: Larry Masinter has raised several issues in the URNBIS WG in which he claims that draft-ietf-appsawg-uri-scheme-reg constrains what that WG is proposing to do with URNs [1]. I also believe that some of his comments mix up registration of schemes (e.g., "urn:") with registrations of URN namespaces and NIDs I think those issues need to be considered in that WG. However, procedurally, it seems to me that either: (1) Existing registrations are existing registrations and any updates to them are grandfathered, i.e., whatever draft-ietf-appsawg-uri-scheme-reg says is not applicable to the original or updated registration of any URI scheme registered or deployed before it is approved and published. That obviously includes the revised URN registration contemplated by draft-ietf-urnbis-rfc2141bis-urn. (2) We have a mess on our hands in which not only do the mandates of different WGs overlap but in which an area WG that is not noted for very intense reviews can constrain and override the work of more topic-focused (and, therefore, presumably more expert on their own topics) WGs and other efforts. This is particularly problematic in the case of URIs, where parallel (and not entirely consistent) work is going on to further develop specific URI schemes (URNs being only one such example) and groups outside the IETF (including WHATWG and W3C groups) with coordination processes that are still being negotiated and in groups that are heavily dependent on URIs and URI handling (certainly including HTTPbis). If it is applicable to existing registrations and ongoing work in other WGs, this spec is even more problematic because it is heavily dependent on details of RFC 3986, a specification whose exact meaning, implications, and consequences continue to be debated and which is a candidate for preemption or replacement by those other bodies. I suggest that any IESG action on draft-ietf-appsawg-uri-scheme-reg be deferred until which of the above principles applies can be clarified (and clarified in the document) and, if the second option is chosen, that formal reviews and impact assessments be sought from all active WGs that are involved with or use URIs as well as from W3C. Sorry to be raising this so late in the process, but it never occurred to me that anyone would claim that draft-ietf-appsawg-uri-scheme-reg constrained other IETF WGs, standards-track updates to existing registrations that were made as the result of standards actions, etc. Since that claim has now been made, and made by one of the authors of the new draft who presumably understands the intent, a "wait a minute" response seems necessary. john [1] http://www.ietf.org/mail-archive/web/urn/current/msg02873.html ---------- End Forwarded Message ---------- From nobody Sun Mar 29 18:31:02 2015 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 130AB1A01F0 for ; Sun, 29 Mar 2015 18:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 mC5xLZLDhJOp for ; Sun, 29 Mar 2015 18:30:59 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4FF1A8A12 for ; Sun, 29 Mar 2015 18:28:43 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YcOVO-000JgL-5s; Sun, 29 Mar 2015 21:28:42 -0400 Date: Sun, 29 Mar 2015 21:28:37 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: <1779999A3ED5866D931302BB@JcK-HP8200.jck.com> In-Reply-To: <55142CA1.2000509@network-heretics.com> References: <55142CA1.2000509@network-heretics.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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] p-components versus relative URIs (was: Re: Keith's review of draft-ietf-urnbis-rfc2141bis-urn-10_ 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: Mon, 30 Mar 2015 01:31:01 -0000 Hi. As promised, I'm going to try to respond to your detailed review comments. In order to lower the odds that any of them fall through the cracks, I'm breaking them up into separate messages with different subject lines. I can't get to the issue tracker at present, but trust that we can get the new ones listed there soon as well. --On Thursday, March 26, 2015 11:58 -0400 Keith Moore wrote: >... > 1. Use of p-component in URNs combined with use of relative > URIs with URN as the base URI. > > If relative URIs are permitted to be used with URNs, this has > the potential to harm persistence of URNs unless there are > constraints on how NSSs are assigned. If an NSS under a > particular NID has no internal structure, maintaining > persistence for every URN assigned under that NID is > relatively simple - just don't ever reassign an NID to a > different resource. But if the NSS does have structure that > reflects relationships between resources, and those resources > can ever be updated in a way that causes those relationships > to need to change, there's a good chance that some > combinations of base URNs + relative URIs that formerly > resolved to valid URNs, will no longer resolve to valid URNs, > or will resolve to URNs that don't have the same > meaning/purpose as before. Thus there will be a significant > temptation to change the meanings of existing URNs, i.e. to > rebind existing URNs to different resources than before. I had been concerned about a different aspect of applying relative references to URNs, but, at least to the extent to which I understand the above, I share your concern as well. My instinct at the time of the "URNs are not URIs" draft and for a while thereafter had been to simply prohibit the use of any sort of relative resolution with URNs. As you presumably noticed, Graham argued strongly that any such ban would interfere with some things he needed to do with URIs (even though he didn't expect to use the "urn" scheme). There was no pushback on the list to the position he recommended that we take; in the absence of such pushback or feedback, I (and I assume Peter) concluded that it was appropriate to modify the documents as he suggested. > There are lots of ways that a namespace can make relative URIs > safe to use with its URNs. For example, if none of the > resources named by a namespace are machine-parseable, there's > no issue. I'm not sure I understand why the absence of machine-parseability helps with this, especially when, as mentioned in my last note and discussed extensively on-list over the last year or so, a given URN and namespace can be "resolved" to either a target object (maybe machine-parseable or not) or metadata about either the object or the entry in the namespace. > Or if the resources under a namespace are > constrained to never change at all, there's no issue. Or if > NSSs are of the form x/y such that x is never reused (every > new resource gets a unique x, and y is just used to > differentiate between parts or facets of that resource), > there's no issue. I think I understand what you are getting at and it makes sense to me if "parts or facets" can also provide information about the aspect of the resource being considered or retrieved. > The problem is trying to write a general rule that permits use > of p-components in an NSS and permits use of relative URIs > with those URNs, in such a way that doesn't break things and > encourage URNs under that NSS to become non-persistent. > Perhaps the easiest way to fix the problem is this: If a > namespace assigns NSSs containing '/', it is responsible for > ensuring that NSSs are assigned in such a way that relative > URI references appearing in machine-readable resources named > by its URNs are also persistent - and give examples of how > this might be accomplished. (Of course, any resource can claim > any URN as its base URI, and namespaces have no control over > the behavior of resources that they don't name. We can't stop > the authors of such resources from doing truly stupid things > with relative URIs, but we can discourage use of relative URIs > with URNs that weren't designed to be used that way.) Speaking for myself only, if you, Graham, and Larry (who had what I think is a slightly different suggestion) can agree on something that that does not disallow p-components if those make sense to whomever is defining a namespace, it is almost certain that I'll be able to live with it. It seems to me that we need a discussion among the three of you, ideally on-list but at least in the form of a conclusion, explanation, and suggested text. john From nobody Sun Mar 29 18:46:22 2015 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 92EE51A8A20 for ; Sun, 29 Mar 2015 18:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 aYquhnQyd4VB for ; Sun, 29 Mar 2015 18:46:20 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56741A8A1F for ; Sun, 29 Mar 2015 18:46:19 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YcOmR-000JhM-03; Sun, 29 Mar 2015 21:46:19 -0400 Date: Sun, 29 Mar 2015 21:46:13 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: <20AE30F476B62E93E436DF1B@JcK-HP8200.jck.com> In-Reply-To: <55142CA1.2000509@network-heretics.com> References: <55142CA1.2000509@network-heretics.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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] 3986 relationships (was: Re: Keith's review of draft-ietf-urnbis-rfc2141bis-urn-10) 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: Mon, 30 Mar 2015 01:46:21 -0000 Note that this issue is, I believe, somewhat redundant with one discussed in an earlier note. I've tried to refer to it when appropriate; please forgive remaining redundancy. --On Thursday, March 26, 2015 11:58 -0400 Keith Moore wrote: >... > 4. Constraining URNs to RFC 3986 conventions is problematic. > One reason is that when using URNs to refer to > network-accessible resources there is a need for more > functions than those analogous to: references to internal > structure (presumably f-component), references to external > structure (presumably p-component), and access to the resource > as a service (presumably q-component). Those presumptions are not clear to me and may not be shared. See my earlier discussion about interactions with a presumed URN resolver versus pass-through to URL results and then try to generalize it to URNs with different kinds of resolution mechanisms and targets/results (if you have any trouble at all picturing that for the general case, we are in the same boat and that is why I didn't expand on that example). > In particular there > seems to be a strong desire to be able to construct URIs > containing URNs to query a resolution service that is > implicitly determined by the URN itself - i.e. without having > to embed the location of that service in the URI. If I understand what you are saying, isn't that exactly what DDDS-connected NIDs and namespaces do? > Or to more > simply state an example of the problem: given a URN that > refers to a network-accessible resource, how to distinguish > between queries sent to the resolver and queries sent to the > resource itself? Modulo some possible issues with what you mean by "sent", see my earlier note with Subject starting "Fragments and URN pass-through components". It doesn't contain a solution, but does identify what I think is the same problem. On the other hand, as it points out, I've actually tried to start that discussion several times before and the WG has effectively rejected all solutions other than per-namespace rules. > Another reason that RFC 3986 syntax convention is problematic > is that it creates a conflict between (a) the use of > q-components used to send a query or request another service > of a network-accessible resource, and (b) the use of > q-components for other purposes for non-accessible resources. I don't think that conflict is created by 3986 although I do believe there is a problem that should be resolved more clearly than we have done it. As far as 3986 is concerned, I think its involvement in the issue ended with the "syntax only; no semantics" decision. > It might be possible to work around the problem while still > sticking to RFC 3986 syntax, perhaps by reserving some part of > q-component keyword space for use by resolvers. But that > would ideally be done without interfering with use of keywords > used by existing HTTP-based services, since we'd like to be > able to use URNs to provide stable names for such services. Yes. Suggested months and months ago. Got no traction. Happy to hear new suggestions or someone taking up the previous ideas. > I started out thinking that this was only a poor technical > choice, though perhaps a defensible one - but on reflection I > think it borders on being a technical omission. And I > realize we have AD direction to use RFC 3986, but that doesn't > do anything to address the technical problems that this causes. As I said, I think there is a problem in this area, but I don't think 3986 is much of it unless the "syntax only" decision is either ignored or repealed. john From nobody Sun Mar 29 19:17:12 2015 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 388D21A8AA2 for ; Sun, 29 Mar 2015 19:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 TYTXwi7K8qQk for ; Sun, 29 Mar 2015 19:17:08 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFE421A8A9E for ; Sun, 29 Mar 2015 19:17:07 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YcPGE-000JlW-QH; Sun, 29 Mar 2015 22:17:06 -0400 Date: Sun, 29 Mar 2015 22:17:01 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: <6830C3E0F7BCCF808BB0DF0C@JcK-HP8200.jck.com> In-Reply-To: <55142CA1.2000509@network-heretics.com> References: <55142CA1.2000509@network-heretics.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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] % encoding issues (wasL Re: Keith's review of draft-ietf-urnbis-rfc2141bis-urn-10) 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: Mon, 30 Mar 2015 02:17:11 -0000 --On Thursday, March 26, 2015 11:58 -0400 Keith Moore wrote: >... > 5. I suspect the way %-encoding is used is problematic for any > case where human-supplied strings are converted to URNs, in > that there are multiple valid ways to %-encode a name > according to RFC 3986. I'm not sure whether I can say anything useful about this. It is no secret that I believe the community made a serious mistake by not rethinking %-encoding when the Web started to make the transition between ISO 8859-1 (with the specific characteristics of one octet per character and no combining sequences) and Unicode. It is also no secret that I believe some much stronger statements about canonical forms should have made it into the IRI revision work before the IETF abandoned it and that I believe the community should have given very serious consideration to deprecating RFC 3987 when that revision effort collapsed rather than leaving that spec in an ambiguous limbo while other bodies were effectively encouraged to create more or less incompatible revisions. Given that, I sometimes also suspect that it would be entirely reasonable for any document that contains significant dependency on RFC 3987 (including draft-ietf-appsawg-uri-scheme-reg) to go into reference hold and sit there until there is a 3987bis on the standards track). That collection of opinions and beliefs and a few dollars will get me the proverbial overpriced cup of coffee. > One way to fix this is to require each particular namespace > that maps its own names to URNs, and uses/permits %-encoded > NSSs, to specify a distinguished %-encoding rule that produces > repeatable results and is compatible with RFC 3986 decoding. Another is do effectively the same thing by specifying that %-encodings are not touched (except for upper-casing) and that URNs that contain %-encodings in relevant components do not compare equal unless they are identical. 2141bis does that now. If you think it would be helpful to remind namespace designers or reviewers that not having more of a canonical form is likely to lead to false negatives, explain why and suggest text. However, fwiw, I think this is part of a more general URI problem that URNs should not be expected to solve. If you described it as a technical deficiency in 3986, I'd probably agree but still argue that trying to solve it for URNs only would be a mistake. john From nobody Sun Mar 29 19:22:31 2015 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 E99391A8AB2 for ; Sun, 29 Mar 2015 19:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 09zP7m0XhRvf for ; Sun, 29 Mar 2015 19:22:30 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0523F1A8AB1 for ; Sun, 29 Mar 2015 19:22:30 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YcPLR-000JnT-3c; Sun, 29 Mar 2015 22:22:29 -0400 Date: Sun, 29 Mar 2015 22:22:24 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: <476AFBAB55B3F69BF0CBB234@JcK-HP8200.jck.com> In-Reply-To: <55142CA1.2000509@network-heretics.com> References: <55142CA1.2000509@network-heretics.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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] URN to resource binding and resource stability (was: Re: Keith's review of draft-ietf-urnbis-rfc2141bis-urn-10) 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: Mon, 30 Mar 2015 02:22:31 -0000 --On Thursday, March 26, 2015 11:58 -0400 Keith Moore wrote: > 6. This document fails to acknowledge that even though the > binding between a URN and the resource named by that URN > cannot change over time, URNs do not preclude the resource > content being revised. This a very important, though subtle, > distinction. > > I trust this is noncontroversial, and easily fixed. (If it's > controversial we have a huge problem.) It isn't controversial with me, at least. Please suggest text and where to put it. I suggest, however, that it may be part of exactly what we mean by "persistent" and that, while the above seems clear, the term has been hugely controversial with some IETF participants arguing that the whole idea is a fiction. john From nobody Sun Mar 29 19:41:52 2015 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 9BA0D1A1A64 for ; Sun, 29 Mar 2015 19:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 UpCOIYg1zE2X for ; Sun, 29 Mar 2015 19:41:48 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75BEB1A1A59 for ; Sun, 29 Mar 2015 19:41:48 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YcPe3-000JoQ-Dl; Sun, 29 Mar 2015 22:41:43 -0400 Date: Sun, 29 Mar 2015 22:41:38 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: <587F32051FF797206A169FC6@JcK-HP8200.jck.com> In-Reply-To: <55142CA1.2000509@network-heretics.com> References: <55142CA1.2000509@network-heretics.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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] Namespace consensus and registrations (was: Re: Keith's review of draft-ietf-urnbis-rfc2141bis-urn-10) 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: Mon, 30 Mar 2015 02:41:50 -0000 --On Thursday, March 26, 2015 11:58 -0400 Keith Moore wrote: > 7. I'm somewhat sympathetic to the idea that IETF Consensus > is not the right template for creating new namespaces, but > Expert Review is even worse. I think we need widespread > public review, and that our very experience in this working > group is a good indicator of why - there is as yet no small > collection of "experts" that really understands everything > about what it takes to make URNs function well, especially > when applied to network-accessible resources. This issue has been discussed fairly extensively within the WG and consensus to make the change to Expert Review was reached, IIR, a couple of years ago. The counterargument to "Expert Review is even worse" is based on something we've seen played out many times with media types as the best-known example. If we create a registration procedure that is perceived of as onerous, the main effect is to encourage squatting (or whatever one chooses to call using unregistered names) and perhaps having some Wikipedia page over which the IETF has no control turn into the registry that people consult rather than having an IANA registry serve that role. In that situation, we also often end up with no useful documentation at all. So the model in 2141bis (somewhat revised for more clarity in -11 which we still expect to have posted Tuesday or earlier) not only defines the Expert Review process but makes it more consultative rather than judgmental to encourage documentation and registration. -11 also contains some text (also previously discussed in the WG and reflecting experience elsewhere in the IETF) to handle namespace specifications that are intended to become standards a little bit differently from those that are not. If it isn't right, I hope you will speak up quickly. But, as to the fundamental question of whether Expert Review is appropriate, I hope we don't need to reopen the issue unless you have some substantive new information or arguments and an alternate suggestion. > I suspect that another part of the problem is that we've > conflated IETF Consensus with RFC publication because the two > are so often coupled. We shouldn't have to publish a new RFC > every time a NSS format changes. The trend in a number of IETF activities that involve registration templates (including, fwiw, draft-ietf-appsawg-uri-scheme-reg as well as 2141bis) is to require approximately the same procedure for revising a template that was used to register it in the first place. I can see that would be overkill in some cases, but have no idea how to write a set of rules that would define those cases sufficiently well to allow a lighter-weight procedure in appropriate cases while requiring the heavier-weight one at other times and for other namespaces. If you have specific suggestions, please post them. In particular, would you propose to allow each namespace registration to specify the rules for updating it rather than having a scheme-wide rule based on the registration procedure itself. > I trust that discussion on this will continue. I'm sure it will if people stay engaged. best, john p.s. I'm running out of steam for the evening. Failure to get a note posted for some of the issues you raised is an indication that I haven't gotten to it yet, not that it is being ignored. From nobody Mon Mar 30 07:38:46 2015 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 00F3D1A1EEE for ; Mon, 30 Mar 2015 07:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 A3Z2INOfzi61 for ; Mon, 30 Mar 2015 07:38:36 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DBF91A1EEC for ; Mon, 30 Mar 2015 07:38:36 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Ycapl-000NEs-Ft; Mon, 30 Mar 2015 10:38:33 -0400 Date: Mon, 30 Mar 2015 10:38:28 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: <541C8F458AEB1EA37BAEFF2A@JcK-HP8200.jck.com> In-Reply-To: <5516BF4A.3040902@network-heretics.com> References: <5516BF4A.3040902@network-heretics.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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] another problem with 2141bis-10 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: Mon, 30 Mar 2015 14:38:45 -0000 --On Saturday, March 28, 2015 10:48 -0400 Keith Moore wrote: > I realized after I got home from Dallas that another problem > with 2141bis is that it doesn't specify which parts of a URN > that contains f-, p-, and/or q-components are significant for > resolution and should be presented to a resolution service. > If this varies from one namespace to another, it's going to > make it much harder to build general-purpose resolution code. Keith, I think we are getting to the stage where a much smaller actual list of issues are driving a larger set of manifestations, where the latter make the "problem" list look longer. No negative criticism intended because I think it is useful to understand the manifestations too, but I would urge everyone to try to keep the issues list as focused as possible. In addition, I refer to postings below that occurred after you sent the note cited above; it is only because it raises a different manifestation that I think it is worth responding to separately. In this case, unless I'm mistaken, the issue ultimately involves which components, or parts of components, are intended for the resolution process (when there is one) and which ones are expected to be passed through to the target (whose meaning may, again, vary). I discussed that in more general terms in a note posted yesterday with subject line containing "Fragments and URN pass-through components", http://www.ietf.org/mail-archive/web/urn/current/msg02878.html. As pointed out there, this is a relatively old issue that has been raised, in different forms, several times previously on the mailing list. DWIW, I think there is another possible response as far as the specific issue of "what should be passed to a resolution service" is concerned. We don't have enough of a specification of generic URI resolution services to either think about APIs or, IMO, even to think about the "what should be passed" question meaningfully. Part of that is discussed in more detail in another one of yesterday's notes (subject containing "General-purpose resolution service", http://www.ietf.org/mail-archive/web/urn/current/msg02877.html). The relationship between DDDS and DNS NAPTR records (and the associated regular expression) could be the foundation for such a specification except: (i) As that posting indicates, DDDS is one of many potential mechanisms for linking URN NIDs to resolution services, but it is not ubiquitous and we have no cross-namespace mechanism for identifying and invoking others. (ii) Even if DDDS were ubiquitous, its NAPTR regular expression mechanism did not anticipate information that is not clearly part of the NSS. I haven't studied it in nearly enough detail in recent years to have an opinion as to whether changes are needed and, if so, whether they are obvious or require significant thinking and work. That said, it is possible, at least in principle (but not with the present DDDS), to simply pass everything to a resolution service and then have that resolution service, after figuring out whatever it needs to figure out about the properties of the namespace, to pass back either specifically-designated pass-through elements or anything it doesn't recognize for passing through to the target. Most of that is extremely speculative. What is clear is that neither "review and revise DDDS" or a restriction equivalent to "do nothing that might require a DDDS update" is on the WG's charter. "Define a truly generic resolution service and mechanisms that behave well with URN namespaces that do not resolve at all" is not either [1]. As I have argued in earlier notes, in the absence of such a generic resolution service or at least the supporting infrastructure and data model for it, our only choice is pushing a lot of things down to per-namespace decisions. I'm not wild about that either, but the situation seems to be what it is... and the decisions, circumstances, and logic that have gotten us there are not the result of decisions taken by this WG. john [1] I have been wondering whether it would be possible to define a data representations and model that would exist at one level of abstraction above DDDS, really span the whole space of present and future URN namespaces. I would assume it would permit turning the answers to many of these questions (including "does it resolve at all" and "how does one distinguish between, e.g., content or metadata to which a URN might refer" as well as "how do I get to to something that can answer/resolve the question" into a table-driven exercise. But designing or discussing it is clearly not on the WG's agenda. Moreover, if is were powerful enough to be useful, it might raise a different version of some of your questions about undermining persistence by changing definitions out from under the URN string. From nobody Mon Mar 30 09:43:29 2015 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 2C2831A011D for ; Mon, 30 Mar 2015 09:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] 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 DCV4DWfiwzqJ for ; Mon, 30 Mar 2015 09:43:25 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7B11A70E1 for ; Mon, 30 Mar 2015 09:43:23 -0700 (PDT) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id D65E68AD1E; Mon, 30 Mar 2015 18:43:21 +0200 (CEST) X-AuditID: 0a453fe7-f79106d0000047dd-40-55197d29593a Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id 55.0B.18397.92D79155; Mon, 30 Mar 2015 18:43:21 +0200 (CEST) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Mon, 30 Mar 2015 18:43:20 +0200 From: "Svensson, Lars" To: Peter Saint-Andre - &yet , "urn@ietf.org" Thread-Topic: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10 Thread-Index: AdBf5EXxmQCfXUbTSausW6Ov9qCjfgAbn+CAABcUiFAAOOI9AAFgPrqAAEh9QgAAtIJeYA== Date: Mon, 30 Mar 2015 16:43:19 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFFAC95C26@dnbf-ex1.AD.DDB.DE> References: <24637769D123E644A105A0AF0E1F92EFFAC84913@dnbf-ex1.AD.DDB.DE> <55079325.1010300@andyet.net> <24637769D123E644A105A0AF0E1F92EFFAC85A6E@dnbf-ex1.AD.DDB.DE> <5509ABC6.2040707@andyet.net> <24637769D123E644A105A0AF0E1F92EFFAC923DC@dnbf-ex1.AD.DDB.DE> <5514CE1E.4010201@andyet.net> In-Reply-To: <5514CE1E.4010201@andyet.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.191] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12TfUgTYRzHeW6nd649ek63Pa4X22GQlrOiIiJ6DwxEhVqr/EPPdm3DqeNu k7SCykhSZgVFKAVGq7QQh0RmGtgQKXvRykStTF0kSpK9UVFE97Lp7L/ffb7P9/v7PjwcqVCP EHrSXuRiuSLGQUcqceWOTd9Tk48mmFYMtq1Y1z3WqVh3oXwa24ylP3vTT6R7vb+wbGy/coOF ddhLWC5tY57S9qPrJ3Be1xzytE7ix8BIfCWIIhG1GnV4PuDyrEW9w02RlUBJqqlOgCb6Ggj5 owWgdwNDWCUgyEgqBX2yiefjqUzUNRmQvHHUVnSj/KRC5tvQ3y8nMHneg268uk6IM04tQb2n L0WIM6R2ovGqieCuBgyNni2XhCghvmH6gTQDaiHy+XqkUAWlQ80ffkTIRSnkbZc5ojRoIvA3 yA2ocaheWEYK55NR07002WpA56tGCXlvLHpU8x4/CzS1Yam1s47aMEdtmKMO4DdBNF9oXWlk LEaLJd9oYZuB/BTjd0H1i+1+QJGAVkFXBTKpI5gSvrTQD7JIjNZAUJpgUkfnF1tKbQxvy+Xc Dpan42FnmYDhDM53OwroRbD6t+DXzVDezTvtB+zFbj7XzTn8AJEKwZrjEq0WprSM5YrlQD+Y T+K0Dp5rO75bTVkZF1vAsk6WC6l7SZJGsOKwYIzlWCt76KDd4QrJgu+JqFDhilTIAJf+EQrp w4X/O2FklB9kkCqh2FMxBfJOppC3W4PZcTDiiEBVISrlLoSrxVxtCM7N7Aa79DrYIFUST9jc RTNd9Vr4TLTGhAlipH4x5G7pTOqEMD43dRLsFJ4oDhqlOsIPNdtRDWNEOC8IpYoLYLq4RxNk /2dlCG8bDx/f1IkXdjGu8AsvE4uoQjR4YYMItSE4N05/DOzzJq71DRq3lQWmv61Jyps3FTnK bn8/7H98xqy4nfkw6cvb8byXfY3mW/VPcjszeppWpfSSVzx5f1oH2rO8Zv/n52xH6tUd6WPI c3msCn/6mrg2ak5ovpPc5g2callfA5RpdTWGi1Mdnvrj94di+n0/239xbVuW5xBro4mP2Ylf aZy3MStTFBzP/ANmSGkucwQAAA== Archived-At: Subject: Re: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10 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: Mon, 30 Mar 2015 16:43:27 -0000 UGV0ZXIsDQoNCk9uIEZyaWRheSwgTWFyY2ggMjcsIDIwMTUgNDoyNyBBTSwgUGV0ZXIgU2FpbnQt QW5kcmUgd3JvdGU6DQoNCj4gT24gMy8yNS8xNSAxMDoyNCBBTSwgU3ZlbnNzb24sIExhcnMgd3Jv dGU6DQo+IA0KPiA+IEkgdHJ5IHRvIHJlZm9ybXVsYXRlIHdoYXQgaXMgbXkgY29uY2VybjoNCj4g Pg0KPiA+IFJpZ2h0IG5vdyB3ZSBoYXZlIHVybj1hc3NpZ25lZC1uYW1lICsgcC1jb21wb25lbnQg KCtxLWNvbXBvbmVudCArDQo+ID4gZi1jb21wb25lbnQpLCB3aGVyZSBhc3NpZ25lZC1uYW1lID0g J3VybicgKyBOSUQgKyBOU1MuIFRvIG1lIHRoaXMNCj4gPiBpbXBsaWVzIHRoYXQgcC0sIHEtIGFu ZCBmLWNvbXBvbmVudHMgYXJlIG5vdCBwYXJ0IG9mIHRoZSBuYW1lIGFuZA0KPiA+IHRodXMgKG15 IHJlYWRpbmcpIG5vdCByZWFsbHkgaWRlbnRpZnlpbmcgYW55dGhpbmcgKHNvcnQgb2YNCj4gPiBz ZWNvbmQtY2xhc3MgY2l0aXplbnMpLiBUaGF0IHNlZW1zIE9LIGZvciBxLSBhbmQgZi1jb21wb25l bnRzIHNpbmNlDQo+ID4gdGhleSBhcmUgaWdub3JlZCB3aGVuIHdlIGRvIHVybiBjb21wYXJpc29u LiBCdXQgdG8gbWUgaXQgc2VlbXMNCj4gPiBjb3VudGVyLWludHVpdGl2ZSB0byBoYXZlIGEgcGFy dCBvZiB0aGUgaWRlbnRpZmllciB0aGF0IGlzIG5vdA0KPiA+IHJlbGV2YW50IGZvciB0aGUgX2lk ZW50aWZpY2F0aW9uXyAobm90IHBhcnQgb2YgdGhlIGFzc2lnbmVkIG5hbWUpIGJ1dA0KPiA+IG5v bmV0aGVsZXNzIG1hdHRlcnMgd2hlbiBpdCBjb21lcyB0byBfY29tcGFyaXNvbl8uDQo+ID4NCj4g PiBBbSBJIG92ZXItaW50ZXJwcmV0aW5nIHRoZSB1c2Ugb2YgImFzc2lnbmVkLW5hbWUiIHRvIG1l YW4gdGhhdCB0aGUNCj4gPiByZXN0IG9mIHRoZSB1cm4gaXMgbm90IHBhcnQgb2YgdGhlIG5hbWUg YW5kIHRodXMgbm90IHBhcnQgb2YgdGhlDQo+ID4gaWRlbnRpZmllcj8NCj4gDQo+IEkgdGhpbmsg dGhhdCB5b3UgbWlnaHQgYmUgb3Zlci1pbnRlcnByZXRpbmcsIGJlY2F1c2UgdGhlIHNwZWNpZmlj YXRpb24NCj4gY3VycmVudGx5IHNheXMgdGhhdCB0aGUgcC1jb21wb25lbnQgc2hhbGwgYmUgdGFr ZW4gaW50byBhY2NvdW50IGZvcg0KPiBwdXJwb3NlcyBvZiBkZXRlcm1pbmluZyBVUk4gZXF1aXZh bGVuY2UuDQo+IA0KPiBUaHVzICJ1cm46ZXhhbXBsZS8xLzIvMy8iIGlzIG5vdCBlcXVpdmFsZW50 IHRvICJ1cm46ZXhhbXBsZS80LzUvNiIsDQo+IHdoZXJlYXMgInVybjpleGFtcGxlOmZvbz8xMjMi IGlzIGVxdWl2YWxlbnQgdG8gInVybjpleGFtcGxlOmZvbz80NTYiIGFuZA0KPiAidXJuOmV4YW1w bGU6Zm9vIzEyMyIgaXMgZXF1aXZhbGVudCB0byAidXJuOmV4YW1wbGU6Zm9vIzQ1NiIuIFNvIGlu DQo+IHByYWN0aWNlIHRoZSBwLWNvbXBvbmVudCBtYXR0ZXJzIGluIGEgd2F5IHRoYXQgdGhlIHEt Y29tcG9uZW50IGFuZA0KPiBmLWNvbXBvbmVudCBkbyBub3QuDQo+IA0KPiBIb3dldmVyLCBwZXJo YXBzIHRoZSB0ZXJtICJhc3NpZ25lZC11cm4iIGlzIGNvbmZ1c2luZyBzbyBJIHdpbGwgc2VlIGlm IEkNCj4gY2FuIGZpbmQgYSBiZXR0ZXIgdGVybS4NCg0KWWVzIEkgc2VlLiBFdmVuIGlmIEkgcmVh bGlzZSB0aGF0IGl0IHN5bnRhY3RpY2FsbHkgbWFrZXMgbm8gZGlmZmVyZW5jZSwgaXQgc2VlbXMg bW9yZSBuYXR1cmFsIHRvIG1lIHRvIHNheSB0aGF0IHVybiBlcXVpdmFsZW5jZSBpcyBkZXRlcm1p bmVkIGJ5IGNvbXBhcmluZyB0aGUgYXNzaWduZWQtbmFtZSBwYXJ0IG9mIHRoZSB1cm4uIElmIGl0 J3Mgbm90IHBhcnQgb2YgdGhlIG5hbWUsIGl0IHNob3VsZCBub3QgYmUgcmVsZXZhbnQgZm9yIGVx dWFsaXR5LiBUaHVzIG15IHByb3Bvc2FsIHdvdWxkIGJlDQoNCm5hbWVzdHJpbmcgPSBhc3NpZ25l ZC1uYW1lIFtxLWNvbXBvbmVudF0gW2YtY29tcG9uZW50XQ0KYXNzaWduZWQtbmFtZSA9ICJ1cm46 IiBOSUQgIjoiIE5TUyBbcC1jb21wb25lbnRdDQpldGMuDQoNCkJlc3QsDQoNCkxhcnMNCg== From nobody Mon Mar 30 12:23:03 2015 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 16A6A1ACC7F for ; Mon, 30 Mar 2015 12:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 8YYmy9uG62Kc for ; Mon, 30 Mar 2015 12:23:00 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B651AC445 for ; Mon, 30 Mar 2015 12:23:00 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YcfGy-000Nxf-SO; Mon, 30 Mar 2015 15:22:56 -0400 Date: Mon, 30 Mar 2015 15:22:51 -0400 From: John C Klensin To: "Svensson, Lars" , Peter Saint-Andre - &yet , urn@ietf.org Message-ID: <4442EEA947F0A2535EE886EE@JcK-HP8200.jck.com> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFFAC95C26@dnbf-ex1.AD.DDB.DE> References: <24637769D123E644A105A0AF0E1F92EFFAC84913@dnbf-ex1.AD.DDB.DE> <55079325.1010300@andyet.net> <24637769D123E644A105A0AF0E1F92EFFAC85A6E@dnbf-ex1.AD.DDB.DE> <5509ABC6.2040707@andyet.net> <24637769D123E644A105A0AF0E1F92EFFAC923DC@dnbf-ex1.AD.DDB.DE> <5514CE1E.4010201@andyet.net> <24637769D123E644A105A0AF0E1F92EFFAC95C26@dnbf-ex1.AD.DDB.DE> 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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10 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: Mon, 30 Mar 2015 19:23:02 -0000 --On Monday, March 30, 2015 16:43 +0000 "Svensson, Lars" wrote: >> However, perhaps the term "assigned-urn" is confusing so I >> will see if I can find a better term. > > Yes I see. Even if I realise that it syntactically makes no > difference, it seems more natural to me to say that urn > equivalence is determined by comparing the assigned-name part > of the urn. If it's not part of the name, it should not be > relevant for equality. Thus my proposal would be > > namestring = assigned-name [q-component] [f-component] > assigned-name = "urn:" NID ":" NSS [p-component] This works for me. Since Peter has passed the pen back to me after doing most of the work on -11, I'll slip it into the draft until someone objects very soon. john From nobody Mon Mar 30 13:03:28 2015 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 E8FAB1A886D for ; Mon, 30 Mar 2015 13:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 9YzL8JepAx7t for ; Mon, 30 Mar 2015 13:03:25 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0FF01ACCEB for ; Mon, 30 Mar 2015 13:03:24 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Ycfu4-000O4Q-Da; Mon, 30 Mar 2015 16:03:20 -0400 Date: Mon, 30 Mar 2015 16:03:15 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: In-Reply-To: <55142CA1.2000509@network-heretics.com> References: <55142CA1.2000509@network-heretics.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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] Per-namespace rules about p-/q-/and f-components (was: Re: Keith's review of draft-ietf-urnbis-rfc2141bis-urn-10) 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: Mon, 30 Mar 2015 20:03:27 -0000 --On Thursday, March 26, 2015 11:58 -0400 Keith Moore wrote: > 3. Permitting each namespace to define its own rules for use > of f-components, p-components, and q-components is > problematic, at least as applied to resolvable URNs that refer > to network-accessible and/or machine-parseable resources. One > reason this is problematic is that it potentially forces > client software to know about the details of each particular > namespace, thus hindering interoperability and potentially > limiting the useful life of a namespace even when resolution > services continue to be available. Otherwise, the client won't > know what to do with each particular kind of component. Does > the f-component refer to an identifier internal to a resource > that it downloads (as in an HTML document) or does the client > need to interact with the service in some way to access that > component? Does a q-component get sent as part of the > request-URI in a GET request or what? Clients that access > resources named by URNs over the network shouldn't have to > have different wired-in behavior for different namespaces. > (and no, the fact that URLs work this way is NOT a > justification for propagating the same situation to URNs - > URNs were, after all, partially intended to address such > issues by decoupling resource names from the protocols used to > access them.) I've addressed much of this in other notes, or hope I have. To reprise part of it from a different perspective, unless we establish a resolution (or non-resolution) model that all namespaces follow, perhaps with plug-in parameters, some of what you are concerned about is an issue whether these new (to URNs) components are added in or not. If a client needs to understand a particular namespace in order to know if it is to be resolved or not and, if so, using what mechanisms and/or databases, then it seems to me that having scheme-wide rules for *-components, even if feasible, would not add much. Similar comments apply to "at least as applied to resolvable URNs that refer to network-accessible and/or machine-parseable resources": if one has to figure out whether a URN is one or those or not before applying some supposedly-generic set rules, then the value of those rules goes down significantly, at least assuming the components are allowed for other varieties of URNs. Paralleling an argument I made earlier, had folks chosen to have two (or more) separate schemes, one for that set of resolvable URNs and targets and others for other situations, we'd be having a different discussion today. But it seems to me that we started allowing the "urn:" scheme to be used for URNs that do not resolve to network-accessible or computer-processable (parseable or not) resources even before URNs got off the ground. > In general I think the interpretation of a p-component, > f-component, or q-component need to be more-or-less the same > for all URNs. (To some degree this is already constrained by > the decision to allow use of relative URIs with base URNs). > I think the interpretation of these components needs to be > exactly the same for all URNs that refer to network-accessible > / machine-parseable resources. I think this would be a worthwhile goal if it were feasible. I suggest that it is not and, as I suggested in an earlier note, that the ship sailed many years ago. > I think this is less critical for URNs that refer to > fixed-media resources that aren't intended to be > machine-parseable, though I still think it will be confusing > to users if f-components, p-components, and/or q-components > are used in ways that aren't more-or-less consistent with HTTP > conventions. So one compromise might be to define different > constraints on use of f-components, p-components, and > q-components when used to name machine-parseable resources > than when used to name resources that aren't intended to be > machine-parseable. Note too that one cannot distinguish "URN for fixed-media resource" from "URN for machine-parseable resource" even at the namespace level. As one obvious example, at least some publishers are assigning ISBNs to so-called eBooks. The result is that one could have urn:isbn:979-99-999-1234-x and urn:isbn:979-99-999-1345-x (where "x" is whatever the check digit turns out to be) And have one of them identify a book printed on paper and the other one a electronic publication. Because I don't think the commonality you want can be achieved for the reasons above, this is more of an aside than a suggestion, but one way to make users really crazy is to adopt a rule that seems to work almost all of the time but that sometimes don't. > One potential way to resolve this issue might be to declare > that the rules for use of these components can be different > for machine-parseable resources than for resources not > intended to be machine-parseable. Then the people who care a > lot about using URNs with these components with non-parseable > resources can define rules (perhaps very simple rules) that > make sense to them, and the people who care a lot about using > URNs with parseable resources can define rules that make sense > in that environment. The rules for naming resources that > can't be parsed anyway won't affect clients that need to > interact with parseable resources. And if it's simple to > define the rules for non-parseable resources, namespaces that > only assign URNs to non-parseable resources could begin to use > f-,p-,and/or q-components. This isn't such a huge departure > from "namespaces get to choose the rules for interpreting > these components with respect to URNs from their namespaces" - > except that in doing so they should be expected to cite one of > a small number of already-approved standards for such rules. See above. I just don't think this works without going to two (or more) separate schemes or an NID naming convention or reserved part of the NSS that makes the distinction. And I think it is too late for any of those options. > (Note: "machine-parseable" might not be the right dividing > line, but I think it's closer than say "resolvable" or > "network-accessible". But there's definitely room for > discussion here.) Indeed. And probably useful regardless of the outcome of the above. > Another possible way to resolve this issue might be to define > a universal URN resolution protocol that would allow a client > to determine the meaning of f-, p-, and q-components in any > particular URN. But I think that solution, while more > general, is also more complex and will take much longer to > settle on. One would want it to also be able to determine what "resolve" means and would resources were to be used to support it. See earlier "General-purpose resolution service" note (http://www.ietf.org/mail-archive/web/urn/current/msg02877.html) > IMO, this is a serious technical omission. Certainly it is a difficulty, especially if one's design religion prohibits handling these things on a per-namespace basis. But, as I have discussed earlier (and effectively repeat above vis-a-vis the "machine-parseable" or not distinction you are trying to make), the fundamental design decisions that got us to where were are were made well before this WG came into being. The WG is not chartered to revisit them, nor is doing so really feasible. So it seems to me that your argument that this is a "technical omission" is somewhat circular: you assert that a particular outcome is unacceptable, then claim that the WG has left out ways to avoid that outcome. From my point of view, that outcome, attractive or not, is inevitable given a collection of decisions made long ago so this is no omission and would not be an omission even if the remedies you propose were feasible. best, john From nobody Mon Mar 30 15:00:33 2015 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 3CEFE1A1A17 for ; Mon, 30 Mar 2015 15:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 kVCvhLhQaFjp for ; Mon, 30 Mar 2015 15:00:30 -0700 (PDT) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06A671A1A5A for ; Mon, 30 Mar 2015 15:00:29 -0700 (PDT) Received: by igcxg11 with SMTP id xg11so1866999igc.0 for ; Mon, 30 Mar 2015 15:00:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Tgr9AmjsnPzizuyuH4roR0x2LnpvRp2nBHWfZSXiD9c=; b=eL7DotLGjpbzWPKJNx318RSmDw+BZaGPdfYYma7n7ugnu5QJZvS+4URx0I25fsLFyd vQx7/lDmGTnyZ12gQzeVgU5p+/oQyiXZvcT90Tn9c2hT9FtntACSJD2SGTWEeQ127axh 4eeTtzZLu13yJmGHrZvj6u2iwQkZPrzfcBInuq1tf9Vg9B9s5+ie554+7p1e2LIq9+NV smtd3KKeGcz8bjgsYPjtqWeS+pWMyN79vfJ1zqkXKgxNxQ/9n29wlLQA36qp/KJH9g3o pLoK1hUzPTYvifAip3mTGWaT9fXEokPvBzEJoMMhK6oNtxiuojObxjh0DoRmFz6LchQz Qf7A== X-Gm-Message-State: ALoCoQn7T2irA9NGZAl7YHE1/NF3ulgdbQZQTNtZtJbMBhAYE1uP7+urxcC2LmQjOcDrl3tYHHKP MIME-Version: 1.0 X-Received: by 10.42.86.12 with SMTP id s12mr64095411icl.47.1427752829199; Mon, 30 Mar 2015 15:00:29 -0700 (PDT) Received: by 10.36.33.21 with HTTP; Mon, 30 Mar 2015 15:00:29 -0700 (PDT) X-Originating-IP: [2001:500:4:15:3022:53bf:3939:8f6a] In-Reply-To: References: <55142CA1.2000509@network-heretics.com> Date: Mon, 30 Mar 2015 18:00:29 -0400 Message-ID: From: Andrew Newton To: John C Klensin Content-Type: multipart/alternative; boundary=20cf3022404b363b290512889c85 Archived-At: Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] Per-namespace rules about p-/q-/and f-components (was: Re: Keith's review of draft-ietf-urnbis-rfc2141bis-urn-10) 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: Mon, 30 Mar 2015 22:00:32 -0000 --20cf3022404b363b290512889c85 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 30, 2015 at 4:03 PM, John C Klensin wrote: > But it seems to me that we > started allowing the "urn:" scheme to be used for URNs that do > not resolve to network-accessible or computer-processable > (parseable or not) resources even before URNs got off the ground. > This was the very first question that popped into my head when I started thinking about a universal/generic URN resolver. How is it suppose to know which ones are meant to be resolved to network resources and which are not? Beyond any theory of URNs or previous design concepts, what is the current state of URN resolvers? Are there generic ones? Googling around I found plenty of NBN-specific URN resolvers and some for OGC. But I found nothing that was generic. There are a couple of Firefox plugins but they list support for very specific NIDs (one even uses Google as a last resort). That's not to say that such things do not exist, but if they do are they actively maintained or actively used? -andy --20cf3022404b363b290512889c85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Mar 30, 2015 at 4:03 PM, John C Klensin <john-ietf@jck.com>= wrote:
But it seems to me that we
started allowing the "urn:" scheme to be used for URNs that do not resolve to network-accessible or computer-processable
(parseable or not) resources even before URNs got off the ground.

This was the very first question that popped into my hea= d when I started thinking about a universal/generic URN resolver. How is it= suppose to know which ones are meant to be resolved to network resources a= nd which are not?

Beyond any theory of URNs or previous design concepts, what is = the current state of URN resolvers? Are there generic ones? Googling around= I found plenty of NBN-specific URN resolvers and some for OGC. But I found= nothing that was generic. There are a couple of Firefox plugins but they l= ist support for very specific NIDs (one even uses Google as a last resort).=

That&= #39;s not to say that such things do not exist, but if they do are they act= ively maintained or actively used?

-andy
--20cf3022404b363b290512889c85-- From nobody Mon Mar 30 19:33:16 2015 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 06D7E1A89E9 for ; Mon, 30 Mar 2015 19:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7] 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 XZhx9_Jt6A6C for ; Mon, 30 Mar 2015 19:33:13 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449DB1A89BB for ; Mon, 30 Mar 2015 19:33:11 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 618ED20812 for ; Mon, 30 Mar 2015 22:33:07 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Mon, 30 Mar 2015 22:33:10 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=XzCSb22rJItxKhV hdmC4W/OyIBc=; b=SiEpF3YcGieBtyzRp6RoyJSfdtDWPsOiUvsU0fEw2KZoxRR 9Wo4mvlJhwWtph7dSs038VMu7l2ZrXHUDfJ0/4lYiqos4YGbBjNgu5tfTVywJgTw 38kSti59HnGpSPT/hZ5E30rMezK7KgA3EKTIKR0/FqAUAykkDL78xJXpWXr0= X-Sasl-enc: 0kI1XVwJjPA/0Pwi+PHsTG8NjjSQIrb3+AhRTV7iuUSu 1427769190 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id EC72768016E; Mon, 30 Mar 2015 22:33:09 -0400 (EDT) Message-ID: <551A075C.3050708@network-heretics.com> Date: Mon, 30 Mar 2015 22:33:00 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: <55142CA1.2000509@network-heretics.com> <6830C3E0F7BCCF808BB0DF0C@JcK-HP8200.jck.com> In-Reply-To: <6830C3E0F7BCCF808BB0DF0C@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] % encoding issues (wasL Re: Keith's review of draft-ietf-urnbis-rfc2141bis-urn-10) 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: Tue, 31 Mar 2015 02:33:15 -0000 Maybe I didn't express myself clearly, so I'll try an example or two: 1. Say that "frobs" are a kind of stable resource identifier that match the regexp [a-zA-Z0-9?#]+[~][a-zA-Z0-9?#]+ (in other words, a string consisting only of letters, digits, ? and #, followed by '~', followed by another string consisting only of letters, digits, ?, and #) Also say that there's a URN "frob" scheme that allows frobs to be expressed as URNs. And there are clients that accept raw "frobs" and translate them to "frob" URNs. I'm not exactly sure why, but I've observed that some %-encoders encode '~' as %7E, while others do not. So client A could encode "abcde#~wxyz" as "urn:frob:abcde%23%7Ewxyz" and client B could encode "abcde#~wxyz" as "urn:frob:abcde%23~wxyz" and these two would not be seen as equivalent under comparison rules. 2. Let's say that "gizmos" are another identifier type that have the syntax [0-9]+[.][0-9]+/[0-9a-z]+ . But the usage of "gizmos" are such that it's never appropriate to use them with relative URIs. So rather than leave the '/' unencoded, the '/' should be encoded as %2F when converting a gizmo to a URN. (end of examples) This is, IMO, a minor concern relative to the other problems I've cited, especially since few URN namespaces that are derived from existing identifiers will probably have the problem. But I think the fix is easy. Some URN namespaces that incorporate existing identifier schemes under the URN umbrella already need to define how to handle variant spellings of those names, e.g ISBN numbers that permit '-' characters. I'm just suggesting that a specific algorithm for %-encoding should probably be part of that namespace definition for any namespace that permits characters that are either forbidden or have special meaning in the URN context. As you point out, there are lots of problems with %-encoding in URIs completely apart from URNs. But I don't see that that justifies adding to the problems, and I think we can fairly easily avoid doing so. Keith On 03/29/2015 10:17 PM, John C Klensin wrote: > > --On Thursday, March 26, 2015 11:58 -0400 Keith Moore > wrote: > >> ... >> 5. I suspect the way %-encoding is used is problematic for any >> case where human-supplied strings are converted to URNs, in >> that there are multiple valid ways to %-encode a name >> according to RFC 3986. > I'm not sure whether I can say anything useful about this. It > is no secret that I believe the community made a serious mistake > by not rethinking %-encoding when the Web started to make the > transition between ISO 8859-1 (with the specific characteristics > of one octet per character and no combining sequences) and > Unicode. It is also no secret that I believe some much stronger > statements about canonical forms should have made it into the > IRI revision work before the IETF abandoned it and that I > believe the community should have given very serious > consideration to deprecating RFC 3987 when that revision effort > collapsed rather than leaving that spec in an ambiguous limbo > while other bodies were effectively encouraged to create more or > less incompatible revisions. Given that, I sometimes also > suspect that it would be entirely reasonable for any document > that contains significant dependency on RFC 3987 (including > draft-ietf-appsawg-uri-scheme-reg) to go into reference hold and > sit there until there is a 3987bis on the standards track). > > That collection of opinions and beliefs and a few dollars will > get me the proverbial overpriced cup of coffee. > >> One way to fix this is to require each particular namespace >> that maps its own names to URNs, and uses/permits %-encoded >> NSSs, to specify a distinguished %-encoding rule that produces >> repeatable results and is compatible with RFC 3986 decoding. > Another is do effectively the same thing by specifying that > %-encodings are not touched (except for upper-casing) and that > URNs that contain %-encodings in relevant components do not > compare equal unless they are identical. 2141bis does that > now. If you think it would be helpful to remind namespace > designers or reviewers that not having more of a canonical form > is likely to lead to false negatives, explain why and suggest > text. > > However, fwiw, I think this is part of a more general URI > problem that URNs should not be expected to solve. If you > described it as a technical deficiency in 3986, I'd probably > agree but still argue that trying to solve it for URNs only > would be a mistake. > > john > > From nobody Tue Mar 31 09:30:54 2015 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 41BD91A00BF for ; Tue, 31 Mar 2015 09:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 PPc_xY-7xokm for ; Tue, 31 Mar 2015 09:30:51 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BE991A0099 for ; Tue, 31 Mar 2015 09:30:51 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Ycz3v-0001YA-6z; Tue, 31 Mar 2015 12:30:47 -0400 Date: Tue, 31 Mar 2015 12:30:42 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: <4DA0D6F91638EF5809D3DD65@JcK-HP8200.jck.com> In-Reply-To: <551A075C.3050708@network-heretics.com> References: <55142CA1.2000509@network-heretics.com> <6830C3E0F7BCCF808BB0DF0C@JcK-HP8200.jck.com> <551A075C.3050708@network-heretics.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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] % encoding issues (wasL Re: Keith's review of draft-ietf-urnbis-rfc2141bis-urn-10) 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: Tue, 31 Mar 2015 16:30:53 -0000 Keith, However unintentionally (or undesirably), I think this gets tangled up with different models of how URIs are parsed and analyzed. I've heard each of the following suggested, usually with the implication that it is the One True Approach: (1) Canonicalize the URI string to the extent allowed by 3986, then do an octet-by-octet comparison, shrugging off false negatives. (2) Canonicalize as above, discard some components of the URI, and then proceed as in (1). (3) Parse out the scheme identifier, then pass everything, including comparison questions, off to action routines for that scheme. (4) For URNs, expect the action routines (I'm not going to say "resolver" because this really isn't about resolution) to pass things off to per-namespace action or comparison routines. (5) Some sequential combination of the above, with each operation in sequence returning "these match" for positives and passing things along to the next one for possible negatives. Unless we can resolve which of the above is really intended (a 3996bis issue, not a URN one), I don't see any way to normatively do what I think you are looking for. However, let me make a suggestion based on one of your comments. See if you think it would help or if I still don't understand what you are after. --On Monday, March 30, 2015 22:33 -0400 Keith Moore wrote: >... > I'm just suggesting that a specific algorithm > for %-encoding should probably be part of that namespace > definition for any namespace that permits characters that are > either forbidden or have special meaning in the URN context. Much as some of my instincts want to take us in that direction, I don't think we have discussed or accepted a goal that would turn namespace definitions into something a generic URN action routine (parser, resolver, or anything in between). Perhaps, if we did that, it would provide a mechanism for dealing with the "is this resolvable", "where to I find whatever is needed to resolve it", and/or "what parts of p-/q-/f-components belong to URN processing and what parts are intended to be passed through to the next steps and/or target resources" questions that have come up in other notes. However, it seems to me that Section 7.2 Bullet 4 of draft-ietf-urnbis-rfc2141bis-urn-10 (and Section 7.3.2 Bullet 4 of -11, which should be posted later today - I don't expect the numbering to change, but it might) already addresses this general issue although encoding examples are not called out. I also note that this is tied to the "equivalence rules, #8" entry in the tracker. Would it make you more comfortable if we added, e.g., "special encoding considerations, especially for URNs that contain embedded forms of other types of identifiers" to that list of examples? If we did that, would anyone who is concerned about interactions with generic URI parsers object or have significant concerns? Because I think that even if you like that change, we need to see if it causes concerns among those who are concerned about generic URI parsers and processing so it won't make it into -11 (except as a placeholder comment in the XML, which is already there). If useful discussion continues and it is useful, I think there should be time to spin a -12 before the scheduled interim meeting. best, john From nobody Tue Mar 31 09:52:34 2015 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 E7BB71A037F for ; Tue, 31 Mar 2015 09:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 dAsC-pT_MiFT for ; Tue, 31 Mar 2015 09:52:27 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 733CE1A037C for ; Tue, 31 Mar 2015 09:52:27 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YczOs-0001ik-I7; Tue, 31 Mar 2015 12:52:26 -0400 Date: Tue, 31 Mar 2015 12:52:21 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: <21AB78DB534184F02D06AA83@JcK-HP8200.jck.com> In-Reply-To: <55142CA1.2000509@network-heretics.com> References: <55142CA1.2000509@network-heretics.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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] Putative nits (was: Re: Keith's review of draft-ietf-urnbis-rfc2141bis-urn-10) 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: Tue, 31 Mar 2015 16:52:33 -0000 Keith, Interestingly, whether these are "nits" or not is itself an interesting question because each one seems to me to raise additional questions or issues. We certainly agree that none of them are (or should be) earthshaking or showstoppers. I/we have not incorporated changes for any of them into -11. I suggest that you and the rest of the WG have a look at the comments below to see if we can reach conclusions about what should be in -12. The numbering of subsections and summary titles below are intended to lower the odds of anything getting lost. --On Thursday, March 26, 2015 11:58 -0400 Keith Moore wrote: (1) "Typically" > 1. Introduction, 2nd paragraph, first sentence. Omit the > word "typically", or otherwise reword to avoid creating the > impression that it's ok to use URNs as other than persistent, > location-independent resource identifiers. My recollection is that we put "typically" in there to resolve other concerns and complaints. They _may_ have been about whether "persistent, location-independent resource identifier or abstract designator" actually covered all of the reasonable cases. Could others comment on this? Note that almost the same phrasing appears in the Abstract so, if it should be changed in the Introduction, it should presumably be changed there too. (2) "MAY" and "can" > 2. Section 3, paragraph following ABNF section: I would > substitute "MAY" for "can". After some list discussion (and, IIR, considerable confusion about what 3986 allowed), I chose "can" because this statement is a reminder about 3986-reality rather than a normative requirement (even a permissive one) imposed by this specification. If your reasoning is different, please explain. (3) "Global uniqueness" > 3. Section 6, paragraph starting "With regard to global > uniqueness": Just simply state that a single resource can > have more than one URN assigned to it. It doesn't matter > whether those URNs exist for different purposes. Also > clarify that if there is no such thing as a distinguished or > preferred URN for a resource that can be inferred from looking > at the URNs. At least as far as the URN architecture is > concerned, all URNs are equally valid. (If the resource > wants to specify which of several URNs is the distinguished > name for itself, that's a different matter.) This paragraph has been slightly rewritten in -11 to reflect Ted's comments. I'd like the WG to have a chance to look at this and compare it to the approach you recommend before making further changes. best, john From nobody Tue Mar 31 11:28:41 2015 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 320221A906A for ; Tue, 31 Mar 2015 11:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 vwzb6wV45qCE for ; Tue, 31 Mar 2015 11:28:28 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C5251A904D for ; Tue, 31 Mar 2015 11:28:28 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Yd0tk-0001zy-Hb; Tue, 31 Mar 2015 14:28:24 -0400 Date: Tue, 31 Mar 2015 14:28:19 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: In-Reply-To: <55142CA1.2000509@network-heretics.com> References: <55142CA1.2000509@network-heretics.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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] Persistence with f-components or p-components (was: Re: Keith's review of draft-ietf-urnbis-rfc2141bis-urn-10) 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: Tue, 31 Mar 2015 18:28:34 -0000 Keith (and others), I believe this is the last in my long series of initial responses to the "details" raised in your review. If anyone thinks there are separate issues I have missed, please identify them, ideally with subject lines that distinguish them from those already addressed. While I assume (and hope) that discussions will continue along each of these threads, I note that several of the issues appear to me to be more intertwined than the review suggested. I hope that we can now consolidate them as part of the resolution process, especially because some of them overlap with issues in the tracker or that were resolved years ago. --On Thursday, March 26, 2015 11:58 -0400 Keith Moore wrote: >... > 2. The document fails to specify which parts of a URN > containing f-components or q-components must be persistent. > For example, since URN x is required to be persistent, is x#y > also required to be persistent? Similarly for x?y and x/y. > Or do the persistence requirements only apply to some of these > and not others? See my comments below yours about the general issue of "persistence requirements". I'm quoting this entire section of your note because the original is now several days old and because it seems useful to focus on this issue. > IIRC, the reason RFC 2141 doesn't permit '/', '?', or '#' in > NSSs is that we couldn't figure out how to define or ensure > persistence in these cases in a way that made sense across a > wide variety of use cases. The current rfc2141bis document > still fails to address these problems. > > At one level the problems with p-components, f-components, and > q-components are the same problem - how to ensure persistence > of a structured identifier for a resource that can be revised > over time, including potentially in ways that change its > internal structure and/or relationships with other resources. > But at another level I suspect that these are subtly different > problems. If we're going to use p-components, f-components, > and q-components in ways that are even vaguely similar to > their use in HTTP URLs then p-components are going to reflect > structure between resources, f-components are going to reflect > structure internal to the named resource, and q-components for > ... something else (more on that later). (And if we're not > going to use these components in those ways, why burden URNs > with a syntax that is certain to confuse users?) > > IMO, this is a serious technical omission, one that is likely > to undermine the fundamental URN property of persistence, and > {f,p,q}-components shouldn't be permitted in URNs until this > is settled. I've commented on pieces of this issue earlier, but, if we have to reach consensus about precisely what "persistence" means and what its boundaries are, I think we are in big trouble with no way to get out of it. You obviously have a clear vision on what it means, clear enough to believe it is a "fundamental property" and that there are "persistence requirements". Others have made rather strong arguments that there is no such thing -- that everything passes eventually and that any assertions about persistence have to be made in a very specific content. Some of those arguments have included assertions that, in the long run, a DNS-dependent URL with appropriate precautions can be as "persistent" as any URN. I believe it is not an accident that RFC 2141 does not attempt to define "persistent". RFC 1737 does and says: "Persistence: It is intended that the lifetime of a URN be permanent. That is, the URN will be globally unique forever, and may well be used as a reference to a resource well beyond the lifetime of the resource it identifies or of any naming authority involved in the assignment of its name." but that definition does absolutely nothing to resolve the questions addressed in this note, nor does it provide any sort of bright line. I also note, partially addressing Larry's concerns, that the "any resource that might conceivably be available on the network" provision of the following statement would ban indicator-type URNs where there is no underlying "resource", much less one that is "available on the network". URNs have evolved a great deal since 1994 (including in part due to the collapse of the IIIA model and the disappearance of URCs, neither of which are, AFAICT, even mentioned in 3986) and all, or almost all, of the pivotal decisions in that evolution occurred before this WG came into being and are not within its scope to try to reverse even if that were desirable. I also note that Juha and others have told us that the way in which we use the term "identifier" is often inconsistent with the use of that term in communities that have far more specific definitions (and a few centuries more experience). As with "persistence", I think trying to draw exact lines will result in paralysis without any obvious path forward. The notion of persistence also gets tangled up with an old distinction and example. Consider three URNs: (i) One that references the current weather wherever I happen to be right now. (ii) One that references the current weather in Stockholm. (iii) One that references the weather in Stockholm as of 2015-03-31 17:00:00 UTC. At least according to my memory from well over a decade ago (two if one counts RFC 1737), each of these could be a valid URN. Each is persistent at the URN identifier level (but so is a URL whose domain name vanishes or is reassigned to a different owner). None of them are network location-dependent. Each is resolvable and resolvable in more than one way, although they impose different requirements on the external knowledge that must be available to the resolution mechanism. Only the third resolves to a constant result and, even then, the constancy/ persistency of that result is dependent on some notions of official statistics versus other sorts of measurements (and micro-geography) that might be equally or more useful or "accurate". None of these distinctions require moving beyond 2141. If 2141bis has issues with persistence, so does 2141. What is new with 2141bis and these various components is some design choices about whether, e.g., information or specifications belong as part of an extended NSS or in a {p,q,f}-component. If you imagine, as I think we did a decade ago, that the third example above might be written urn:weather:SE:stockholm:2015-03-31-17:00:00 then there is now a potential design decision that might have it written as urn:weather:SE:stockholm?date=2015-03-31-17:00:00 I think it would be really hard to argue that one of these (or other permutations of the information) is more or less persistent than the other, but I think it is hard to think about generic guidance especially because, while that choice might exist for the hypothetical "weather" NID and namespace, it doesn't exist for something like an ISBN whose NSS is effectively specified by other standards. It seems to me that we are getting close to a religious argument in which people behave as if features can be included or excluded or assigned particular properties by pronouncing the term "persistence" in appropriately pious tones. That seems to me to be bad news, especially if we are then going to have sectarian battles about the meaning of the term. I see two ways forward although I hope things are not quite this much of a dichotomy: (1) We accept persistence as a general goal and principle of URNs, clearly excluding things that are network-location-dependent. We consider as valid both pure indicators and things that represent a high level of abstraction and that can identify any of the members of a family of objects that are considered equivalent (at least within the definitions of the namespace). We also accept that, however clear those cases may be, there are _lots_ of gray areas. Design guidance about the choices implied by the example above would certainly be desirable but I don't think we are ready to provide it, much less reach consensus on it. I hope we can keep that work out of the critical path of the WG because I think we will fail if we try. I don't believe that approach will "undermine the fundamental URN property of persistence" because, while I respect the general principle of persistence, I think we were already well past the point that there was a "fundamental property" to be undermined... and well past it before this WG got started and proposed {p,q,f}-components. (2) We start down a path that, especially given the presence in the community of people who believe that "persistence" discussions are meaningless, leads to our either being stuck with 2141 or abandoning and deprecating URNs entirely except, perhaps, for a very narrow range of cases. Given that there are millions of deployed URNs and that many of them would probably not conform to whatever restricted rules were adopted to ensure persistent purity, I can't imagine that working out very well if only because the user community would probably ignore us. But I may be wrong. That could be easily demonstrated if there were a clear and concise definition of "persistence" that would be generally accepted (including surviving the objections of those who claim there is no such thing) and that would enable the distinctions you are seeking. If you have such a definition, please post it to the list. best, john From nobody Tue Mar 31 14:14:26 2015 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 8A5F31A87A2 for ; Tue, 31 Mar 2015 14:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 ZfCGiRaCa0ax for ; Tue, 31 Mar 2015 14:14:22 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628181A88D4 for ; Tue, 31 Mar 2015 14:14:14 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 8F2A9209DA for ; Tue, 31 Mar 2015 17:14:09 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 31 Mar 2015 17:14:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=CzHnRL20608PWYD f9z1VVq8hCy0=; b=ti7XY759H3hzRp0nvnvTmw5cotV4DGIKPtHTH+3l6kykotg spcfKTJdtfRFV2NitSBpcZFJHrMLBO/REVjtke/S+YnrQwnN1e+z2M8Fr0Z6YdPH iOqZkW3JQe5P3zlR4OKlQjk+rLQrnNGIqlcwPISomPGZv2xLMz81bB+LRCys= X-Sasl-enc: bbHosYVvARs+7vRSzdB+6J3SpVhju8C67fqvgaX/IHdR 1427836452 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 213BE680110; Tue, 31 Mar 2015 17:14:12 -0400 (EDT) Message-ID: <551B0E18.5020404@network-heretics.com> Date: Tue, 31 Mar 2015 17:14:00 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: <55142CA1.2000509@network-heretics.com> <476AFBAB55B3F69BF0CBB234@JcK-HP8200.jck.com> In-Reply-To: <476AFBAB55B3F69BF0CBB234@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] URN to resource binding and resource stability 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: Tue, 31 Mar 2015 21:14:24 -0000 On 03/29/2015 10:22 PM, John C Klensin wrote: > > --On Thursday, March 26, 2015 11:58 -0400 Keith Moore > wrote: > >> 6. This document fails to acknowledge that even though the >> binding between a URN and the resource named by that URN >> cannot change over time, URNs do not preclude the resource >> content being revised. This a very important, though subtle, >> distinction. >> >> I trust this is noncontroversial, and easily fixed. (If it's >> controversial we have a huge problem.) > It isn't controversial with me, at least. Please suggest text > and where to put it. will do. thanks. Keith From nobody Tue Mar 31 14:15:20 2015 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 E82711A87A2 for ; Tue, 31 Mar 2015 14:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 q-XoryEPsnxY for ; Tue, 31 Mar 2015 14:15:16 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 864061A8799 for ; Tue, 31 Mar 2015 14:15:16 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 88A0D2071F for ; Tue, 31 Mar 2015 17:15:12 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 31 Mar 2015 17:15:15 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=f1C7yBAR/g6ASye c8VamT1pD6nQ=; b=iFHtg6ig0IB1dntfB3Z3aCxWxaNiHUCPXmP3nB8bwJjc4s2 pMOSLRgp8PyTfxhfCevZdBG6+sBJCmuKkbDQuNIuJJnT3g1iYKhreZhN/lTYI5Gl WhYxHZ+6a8IueqOe9+L4zuaAlApDXSDBcSdznHz3HIzjHV/iexgoNC72nkZU= X-Sasl-enc: 5xfW9+ylTa/psUv8iO+0+fXeP3eukfLz8SjOLSv+K6S+ 1427836515 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 5A42A680100; Tue, 31 Mar 2015 17:15:15 -0400 (EDT) Message-ID: <551B0E58.3010709@network-heretics.com> Date: Tue, 31 Mar 2015 17:15:04 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: <55142CA1.2000509@network-heretics.com> <587F32051FF797206A169FC6@JcK-HP8200.jck.com> In-Reply-To: <587F32051FF797206A169FC6@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Namespace consensus and registrations 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: Tue, 31 Mar 2015 21:15:18 -0000 On 03/29/2015 10:41 PM, John C Klensin wrote: > > --On Thursday, March 26, 2015 11:58 -0400 Keith Moore > wrote: > >> 7. I'm somewhat sympathetic to the idea that IETF Consensus >> is not the right template for creating new namespaces, but >> Expert Review is even worse. I think we need widespread >> public review, and that our very experience in this working >> group is a good indicator of why - there is as yet no small >> collection of "experts" that really understands everything >> about what it takes to make URNs function well, especially >> when applied to network-accessible resources. > This issue has been discussed fairly extensively within the WG > and consensus to make the change to Expert Review was reached, > IIR, a couple of years ago. The counterargument to "Expert > Review is even worse" is based on something we've seen played > out many times with media types as the best-known example. If > we create a registration procedure that is perceived of as > onerous, the main effect is to encourage squatting (or whatever > one chooses to call using unregistered names) and perhaps having > some Wikipedia page over which the IETF has no control turn into > the registry that people consult rather than having an IANA > registry serve that role. In that situation, we also often end > up with no useful documentation at all. So the model in 2141bis > (somewhat revised for more clarity in -11 which we still expect > to have posted Tuesday or earlier) not only defines the Expert > Review process but makes it more consultative rather than > judgmental to encourage documentation and registration. Perhaps the simplest and clearest response that I can offer is that I don't care what the label is ("Expert Review" vs "IETF Consensus" or whatever), so much as I care that there be an opportunity for public review. If the process specified for "Expert Review" requires that there be public review, that the opportunity for review is advertised in IETF and other appropriate fora, and especially if we can somehow arrange that the "expert(s)" considering the results of that public review really do understand the subtleties of URNs (admitting that this is really difficult), I'm okay with that and think it's about the best that we can do. It's potentially even better than "IETF Consensus" because while that does require public review, nothing about the process for choosing Area Directors ensures that IESG will have URN expertise. So I'll be very interested to read -11's text on this subject. Keith From nobody Tue Mar 31 14:19:34 2015 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 9BA691A87BA for ; Tue, 31 Mar 2015 14:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.6 X-Spam-Level: * X-Spam-Status: No, score=1.6 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no 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 sEdJFj7E_bOw for ; Tue, 31 Mar 2015 14:19:28 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A19161A87A2 for ; Tue, 31 Mar 2015 14:19:28 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id DEC8820C30 for ; Tue, 31 Mar 2015 17:19:24 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 31 Mar 2015 17:19:28 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=H+BDdl6EIy54CJ89xdTrxnml7H0=; b=CTUQb Zmps900uvt/XVlSTi9/mx+v4bug2nNB5ACkfMU0AyGy7Ssvdu0UpDjPeUt7iUCHC bcc6JEd528WzDuqD4RKvQD4Vl9qWV1Id7yeNyuobUNlTVDB2EJOqPJVXu7tU7fSH c8j0O7qxLNgR5oFMltn+qa2oga3msjua9iRBJA= X-Sasl-enc: APU8OEh4OVzr+vLrO98Y1c63rCFvCbuqmzmJYOJF0pwp 1427836767 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 9814B680110; Tue, 31 Mar 2015 17:19:27 -0400 (EDT) Message-ID: <551B0F54.4060601@network-heretics.com> Date: Tue, 31 Mar 2015 17:19:16 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: <55142CA1.2000509@network-heretics.com> <5FE5D998-3ADD-4E17-BD48-64995A914153@network-heretics.com> <55143EEA.1060303@gmail.com> <5514433D.7010604@network-heretics.com> <55172454.40502@network-heretics.com> <9176873CA947DB9D9175A34F@JcK-HP8200.jck.com> In-Reply-To: <9176873CA947DB9D9175A34F@JcK-HP8200.jck.com> Content-Type: multipart/alternative; boundary="------------030905030808020405040101" Archived-At: Subject: Re: [urn] General-purpose resolution service 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: Tue, 31 Mar 2015 21:19:32 -0000 This is a multi-part message in MIME format. --------------030905030808020405040101 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 03/29/2015 02:18 PM, John C Klensin wrote: > > --On Saturday, March 28, 2015 17:59 -0400 Keith Moore > wrote: > >>> (i) I've have raised the potential for a fork -- either to a >>> competing standard to to a community just doing whatever they >>> like and ignoring the IETF-- several times, not in the >>> interest of getting particular features but as a caution >>> about continuing to go around in circles without making >>> progress. >> Perhaps that's because certain people's definitions of >> "progress" conflict with others. IMO, balkanazation of URN >> space is not progress, and neither is redefining URNs in such >> a way that it's infeasible to build a general-purpose >> resolution service (or that, because the resolution service >> has to special-case the handling of namespaces, certain >> namespaces get marginalized). 1. Ok, first let me clarify what I meant by "balkanization of URN space", because I clearly didn't express myself adequately there. What I meant was allowing the meaning/interpretation of f-, p-, and q-components of URNs to be potentially different for every different namespace - especially if it requires a client or resolution service that can handle multiple URN namespaces to have wired-in special-case handling for each URN namespace. (And to restate what I stated earlier, I think we can tolerate a small number of special-case exceptions if that's what we need for compatibility with existing practice.) 2. Let me also clarify my expectation about a "general-purpose resolution service" and the role of DDDS: Probably by 1995 or so, and certainly by the time that 2141 was published, most of us in the thick of the URN WG discussions understood that URNs could not be inherently tied to any specific resolution service, not even on a per-namespace basis. This was a direct result of the persistence requirement. Even if there's an authoritative resolution service for a namespace (or some subset of a namespace) when a particular URN from that namespace (or subset) is assigned, that resolution service might not continue to be maintained for as long as the URN is used. So a URN has to continue to be useful even when the original resolution service no longer exists. But just as it's reasonable to look up an ISBN in any library's catalog, it's also reasonable to expect that there might be one or more "alternative" resolution services or catalogs that are indexed by resources' URNs. DDDS was never intended to be "the" general-purpose resolution service in any sense. It was intended as a near-term solution of locating namespace-specific resolution services, as well as perhaps a demonstration that a distributed database of resolution services was possible, and that it wasn't necessary for a URN client to have special-case code to handle every namespace. Using DNS to advertise delegation of URN resolution was and is ugly, and we wouldn't have done that if we'd had a better alternative. But at the time DNS was really the only widely-deployed large-scale federated lookup service on the Internet. RFC 3404 itself states: The major principle behind the Knoxville framework is that the resolution system must be separate from the way names are assigned. This is in marked contrast to most URIs, which identify the host to contact and the protocol to use. [...] Separating the way names are resolved from the way they are constructed provides several benefits./*It allows multiple naming approaches and resolution approaches to compete, as it allows different protocols and resolvers to be used.* /[...]/ / */For the short term, the Domain Name System (DNS) is the obvious candidate for the resolution framework/*, since it is widely deployed and understood. (emphasis mine). So clearly DDDS wasn't intended to be a sole provider of URN resolution service delegation. It was, by its specification's own admission, considered only one of potentially several competing approaches, and perhaps only a short-term solution. Even if DDDS is never widely used for URN resolution purposes, general-purpose URN resolution services and general-purpose URN resolution code based on other mechanisms would still be useful. If one or more organizations wants to each build a URN database and a resolution service based on that database, that's a completely reasonable and desirable thing to do. If some such services have the capability of incorporating URN citation information from one or more namespaces' or countries' or publishers' catalogs, that is also reasonable and desirable. Also, it was never a requirement that every URN be resolvable, and it was generally understood since the early days of URN discussions that this could not be a requirement. (I recall that Ron Daniel argued quite convincingly, for instance, that there would be resources named with URNs whose very existence was secret, so a URN resolver couldn't even be expected to return a reliable indication of whether a particular URN were valid.) 3. In the hopes of clarifying further discussion, I offer the following definitions and goals: a) A general-purpose URN resolution service is a service which can potentially be queried for information about any URN, independent of namespace. Multiple, independent general-purpose URN resolution services can potentially coexist. Such a service might or might not be able to return information about that particular URN - there's no requirement that the service has a complete database of all URNs. Such a service might or might not be able to delegate that query to one or more other services, based on the URN's namespace ID and/or information within that URN's NSS, but there's no requirement that the service know how to delegate to a resolution service for every namespace or other subset of URN-space. b) A general-purpose URN resolution client is one that can consult one or more general-purpose URN resolution services in order to attempt to obtain desired information about a URN when applicable, such as its citation/catalog information, network locations, content of the resource, etc., and which is not inherently limited to use with URNs of specific namespaces. I claim that generic resolution services and generic clients are desirable and anticipated by the URN work. For example RFC 1727 section 5 states "It may also be the case that there are generic ones" (i.e. resolvers or location services) "... providing service for many resources of differing naming authorities". Indeed, a principal motivation for the URN work was to be able to resolve resource names in a generic fashion, even across potential changes in access protocols or lookup services. (and this is precisely why we wouldn't have tried to divide URNs up into schemes like "ddds:" or "indicator:" - we were deliberately not taking that approach because doing so would harm URN persistence.) RFC 2141 impedes neither of the above services [*]. But 2141bis -10 impedes both of them, if the interpretation of f-components, p-components, or q-components by either the service or the client needs to differ from one namespace to another. Note that it should *not* be expected that the resolution service is specific to a particular namespace, as there will be a need for resolution services that handle URNs from a variety of namespaces. (if not immediately, then eventually, as the authoritative services for some namespaces will inevitably disappear, and there will be a desire to provide lookup services for URNs in namespaces that never had authoritative services.) If, on the other hand, all namespaces delegate evaluation of these components to a resolution service, that solves the problem to some degree, but it then presents other problems: e.g. evaluation of relative URIs with respect to these URNs, the inability to address fragments in HTML documents named by URNs, the inability to send "queries" using the HTTP GET method to resources that accept them (at least using an ordinary HTML tag), some namespaces won't have resolution services (thus there's no way for a client to know how to interpret their components) and so on. [*] RFC 2141 section 7 does say that "Functional equivalence is determined by practice within a given namespace and managed by resolvers for that namespace." It may be the case that only an authoritative resolution service for a particular namespace can reliably determine functional equivalence for two URNs from that namespace, but generic URN resolution services are useful in other ways even if they cannot reliably determine functional equivalence. (Note also that two URNs can be functionally equivalent even if they are from different namespaces; there's no requirement that all URNs for a particular resource be from the same namespace.) > I want to isolate this issue because it may be important. > > There are, for better or worse, some topics that, however > important or interesting, are properly just not within the WG's > scope. To start with one we probably agree about, there has > been a recent discussion on the IETF list about getting rid of > the "urn prefix". I think Phillip is wrong, so, apparently, do > you, Peter, Dave Cridland, and others. I don't know whether all > of us completely agree on the reasons. But, as far is the WG is > concerned, the bottom line is that we aren't chartered to figure > out whether URNs as an URI scheme were a good idea. At least as > important, the ship has clearly sailed on the question: as > someone pointed out on that list, even if the IETF were to > somehow magically conclude tomorrow that URNs were a bad idea, > reclassifying the scheme name as "a prefix" and then getting rid > of it would cause more disruption than it could possibly be > worth. > > It may or may not be relevant, but I also note that Phillip has > an interpretation of generic URI syntax that, however much it > appeals to some of us, is diametrically opposed to and > inconsistent with any interpretation of 3986 as normative beyond > a division between scheme name and whatever follows it. > > With that as preface, a good deal of the early thinking about > URNs was closely tied notions of a single, general-purpose, > resolution service and, in particular, to the one that became > DDDS. From reading the DDDS specs, I assume that what at least > some people had in mind was that one namespace would imply one > NID and one instance of a resolver that could be found by > interpreting "/urn:([^:]+)/\\1/i" and that there would be no > exceptions to that convention. > > Whatever the merits of that idea, it was not a requirement in > RFC 3406 (section 1 says: > > 'If "resolution" of any so-created URN identifiers is > desired, a separate process of registration in a global > NID directory, such as that provided by the DDDS system > [RFC3401], is necessary.' > ) > > and note "such as" rather than a requirement and the > anticipation that "resolution" may not be necessary. > > Equally important, the idea of a single required resolution > mechanism or database, or a restriction of URNs to online > objects, was essentially dead as soon as RFC 2288 -- a document > on which RFC 3406 and its predecessor RFC 2611 rely -- was > published in 1998. If anything, it was even more obsolete as an > assumption when we started using URNs that don't resolve at all > such as the XMPP ones that have been referred to as "indicators" > in discussions in this WG. > > If those changes and uses are what you are thinking of when you > warn about balkanizing (sic) URNs, it seems to me it is much too > late to be raising that issue. > > Perhaps sadly, that leaves the choice of resolution mechanisms, > or even mechanisms for finding resolution mechanisms (however > general or specific) to be sorted out on a per-namespace basis. > The WG has discussed the best way to say that and deal with some > of its consequences in 2141bis, but the actual decision dates to > 2141 and earlier. > > It is possible that regrettable decisions were made along the > line. I suggested in an earlier note that, in retrospect, it > might have been wise to break URNs up into classes/ categories > and use a different scheme for each so that, e.g., we would have > had "ddds:" and "indicator:" schemes. But that wasn't done and > reconsidering it, as well as designating an exclusive or even > primary class of URN usage, isn't in scope for the WG as far as > I can tell. > > Again, that ship has sailed and, IMO, complaining that this WG > is doing bad things or ignoring key issues because it was not > chartered to go back and revisit those very old issues (and has > not done so)-- issues that have been settled by decade-old > documents and common practices-- seems unreasonable to me. > YMMD, but, if that is where we disagree, I hope we can at least > be clear about it. > > best, > john > --------------030905030808020405040101 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 03/29/2015 02:18 PM, John C Klensin wrote:

--On Saturday, March 28, 2015 17:59 -0400 Keith Moore
<moore@network-heretics.com> wrote:


(i) I've have raised the potential for a fork -- either to a
competing standard to to a community just doing whatever they
like and ignoring the IETF-- several times, not in the
interest of getting particular features but as a caution
about continuing to go around in circles without making
progress.

Perhaps that's because certain people's definitions of
"progress" conflict with others.  IMO, balkanazation of URN
space is not progress, and neither is redefining URNs in such
a way that it's infeasible to build a general-purpose
resolution service (or that, because the resolution service
has to special-case the handling of namespaces, certain
namespaces get marginalized).

1.  Ok, first let me clarify what I meant by "balkanization of URN space", because I clearly didn't express myself adequately there.    What I meant was allowing the meaning/interpretation of f-, p-, and q-components of URNs to be potentially different for every different namespace - especially if it requires a client or resolution service that can handle multiple URN namespaces to have wired-in special-case handling for each URN namespace.   (And to restate what I stated earlier, I think we can tolerate a small number of special-case exceptions if that's what we need for compatibility with existing practice.)

2.  Let me also clarify my expectation about a "general-purpose resolution service" and the role of DDDS:

Probably by 1995 or so, and certainly by the time that 2141 was published, most of us in the thick of the URN WG discussions understood that URNs could not be inherently tied to any specific resolution service, not even on a per-namespace basis.  This was a direct result of the persistence requirement.  Even if there's an authoritative resolution service for a namespace (or some subset of a namespace) when a particular URN from that namespace (or subset) is assigned, that resolution service might not continue to be maintained for as long as the URN is used.   So a URN has to continue to be useful even when the original resolution service no longer exists.   But just as it's reasonable to look up an ISBN in any library's catalog, it's also reasonable to expect that there might be one or more "alternative" resolution services or catalogs that are indexed by resources' URNs.

DDDS was never intended to be "the" general-purpose resolution service in any sense.   It was intended as a near-term solution of locating namespace-specific resolution services, as well as perhaps a demonstration that a distributed database of resolution services was possible, and that it wasn't necessary for a URN client to have special-case code to handle every namespace.   Using DNS to advertise delegation of URN resolution was and is ugly, and we wouldn't have done that if we'd had a better alternative.  But at the time DNS was really the only widely-deployed large-scale federated lookup service on the Internet.

RFC 3404 itself states:

   The major principle behind the Knoxville framework is
   that the resolution system must be separate from the way names are
   assigned.  This is in marked contrast to most URIs, which identify
   the host to contact and the protocol to use. [...]


   Separating the way names are resolved from the way they are
   constructed provides several benefits.  It allows multiple naming
   approaches and resolution approaches to compete, as it allows
   different protocols and resolvers to be used.

   [...]

   For the short term, the Domain Name System (DNS) is the obvious
   candidate for the resolution framework, since it is widely deployed
   and understood.

(emphasis mine).   So clearly DDDS wasn't intended to be a sole provider of URN resolution service delegation.  It was, by its specification's own admission, considered only one of potentially several competing approaches, and perhaps only a short-term solution.

Even if DDDS is never widely used for URN resolution purposes, general-purpose URN resolution services and general-purpose URN resolution code based on other mechanisms would still be useful.   If one or more organizations wants to each build a URN database and a resolution service based on that database, that's a completely reasonable and desirable thing to do.   If some such services have the capability of incorporating URN citation information from one or more namespaces' or countries' or publishers' catalogs, that is also reasonable and desirable.  

Also, it was never a requirement that every URN be resolvable, and it was generally understood since the early days of URN discussions that this could not be a requirement.   (I recall that Ron Daniel argued quite convincingly, for instance, that there would be resources named with URNs whose very existence was secret, so a URN resolver couldn't even be expected to return a reliable indication of whether a particular URN were valid.) 

3.   In the hopes of clarifying further discussion, I offer the following definitions and goals:

a) A general-purpose URN resolution service is a service which can potentially be queried for information about any URN, independent of namespace.   Multiple, independent general-purpose URN resolution services can potentially coexist.   Such a service might or might not be able to return information about that particular URN - there's no requirement that the service has a complete database of all URNs.   Such a service might or might not be able to delegate that query to one or more other services, based on the URN's namespace ID and/or information within that URN's NSS, but there's no requirement that the service know how to delegate to a resolution service for every namespace or other subset of URN-space.

b) A general-purpose URN resolution client is one that can consult one or more general-purpose URN resolution services in order to attempt to obtain desired information about a URN when applicable, such as its citation/catalog information, network locations, content of the resource, etc., and which is not inherently limited to use with URNs of specific namespaces.

I claim that generic resolution services and generic clients are desirable and anticipated by the URN work.   For example RFC 1727 section 5 states "It may also be the case that there are generic ones" (i.e. resolvers or location services) "... providing service for many resources of differing naming authorities".   Indeed, a principal motivation for the URN work was to be able to resolve resource names in a generic fashion, even across potential changes in access protocols or lookup services.   (and this is precisely why we wouldn't have tried to divide URNs up into schemes like "ddds:" or "indicator:" - we were deliberately not taking that approach because doing so would harm URN persistence.)

RFC 2141 impedes neither of the above services [*].  But 2141bis -10 impedes both of them, if the interpretation of f-components, p-components, or q-components by either the service or the client needs to differ from one namespace to another.   Note that it should *not* be expected that the resolution service is specific to a particular namespace, as there will be a need for resolution services that handle URNs from a variety of namespaces.  (if not immediately, then eventually, as the authoritative services for some namespaces will inevitably disappear, and there will be a desire to provide lookup services for URNs in namespaces that never had authoritative services.)

If, on the other hand, all namespaces delegate evaluation of these components to a resolution service, that solves the problem to some degree, but it then presents other problems: e.g. evaluation of relative URIs with respect to these URNs, the inability to address fragments in HTML documents named by URNs, the inability to send "queries" using the HTTP GET method to resources that accept them (at least using an ordinary HTML tag), some namespaces won't have resolution services (thus there's no way for a client to know how to interpret their components) and so on.

[*] RFC 2141 section 7 does say that "Functional equivalence is determined by practice within a given namespace and managed by resolvers for that namespace."   It may be the case that only an authoritative resolution service for a particular namespace can reliably determine functional equivalence for two URNs from that namespace, but generic URN resolution services are useful in other ways even if they cannot reliably determine functional equivalence.   (Note also that two URNs can be functionally equivalent even if they are from different namespaces; there's no requirement that all URNs for a particular resource be from the same namespace.) 

I want to isolate this issue because it may be important.

There are, for better or worse, some topics that, however
important or interesting, are properly just not within the WG's
scope.  To start with one we probably agree about, there has
been a recent discussion on the IETF list about getting rid of
the "urn prefix".  I think Phillip is wrong, so, apparently, do
you, Peter, Dave Cridland, and others.  I don't know whether all
of us completely agree on the reasons.  But, as far is the WG is
concerned, the bottom line is that we aren't chartered to figure
out whether URNs as an URI scheme were a good idea.  At least as
important, the ship has clearly sailed on the question: as
someone pointed out on that list, even if the IETF were to
somehow magically conclude tomorrow that URNs were a bad idea,
reclassifying the scheme name as "a prefix" and then getting rid
of it would cause more disruption than it could possibly be
worth.

It may or may not be relevant, but I also note that Phillip has
an interpretation of generic URI syntax that, however much it
appeals to some of us, is diametrically opposed to and
inconsistent with any interpretation of 3986 as normative beyond
a division between scheme name and whatever follows it.

With that as preface, a good deal of the early thinking about
URNs was closely tied notions of a single, general-purpose,
resolution service and, in particular, to the one that became
DDDS.  From reading the DDDS specs, I assume that what at least
some people had in mind was that one namespace would imply one
NID and one instance of a resolver that could be found by
interpreting  "/urn:([^:]+)/\\1/i" and that there would be no
exceptions to that convention.

Whatever the merits of that idea, it was not a requirement in
RFC 3406 (section 1 says:

	'If "resolution" of any so-created URN identifiers is
	desired, a separate process of registration in a global
	NID directory, such as that provided by the DDDS system
	[RFC3401], is necessary.'
)

and note "such as" rather than a requirement and the
anticipation that "resolution" may not be necessary.

Equally important, the idea of a single required resolution
mechanism or database, or a restriction of URNs to online
objects, was essentially dead as soon as RFC 2288 -- a document
on which RFC 3406 and its predecessor RFC 2611 rely --  was
published in 1998.  If anything, it was even more obsolete as an
assumption when we started using URNs that don't resolve at all
such as the XMPP ones that have been referred to as "indicators"
in discussions in this WG.   

If those changes and uses are what you are thinking of when you
warn about balkanizing (sic) URNs, it seems to me it is much too
late to be raising that issue.

Perhaps sadly, that leaves the choice of resolution mechanisms,
or even mechanisms for finding resolution mechanisms (however
general or specific) to be sorted out on a per-namespace basis.
The WG has discussed the best way to say that and deal with some
of its consequences in 2141bis, but the actual decision dates to
2141 and earlier.

It is possible that regrettable decisions were made along the
line.  I suggested in an earlier note that, in retrospect, it
might have been wise to break URNs up into classes/ categories
and use a different scheme for each so that, e.g., we would have
had "ddds:" and "indicator:" schemes.  But that wasn't done and
reconsidering it, as well as designating an exclusive or even
primary class of URN usage, isn't in scope for the WG as far as
I can tell.  

Again, that ship has sailed and, IMO, complaining that this WG
is doing bad things or ignoring key issues because it was not
chartered to go back and revisit those very old issues (and has
not done so)-- issues that have been settled by decade-old
documents and common practices--  seems unreasonable to me.
YMMD, but, if that is where we disagree, I hope we can at least
be clear about it.

best,
    john

--------------030905030808020405040101-- From nobody Tue Mar 31 14:43:03 2015 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 357201A1BFC for ; Tue, 31 Mar 2015 14:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.1 X-Spam-Level: * X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no 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 pGTKNNtbOJAZ for ; Tue, 31 Mar 2015 14:42:59 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DCFF1A0383 for ; Tue, 31 Mar 2015 14:42:58 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 67DD0209E0 for ; Tue, 31 Mar 2015 17:42:54 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 31 Mar 2015 17:42:57 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=S3ITh7QB16CAo1T JyjogS5D81dI=; b=UWn0E8c5GqX3PcQh2PtIwg1q6PCGueEsKY3U3V+h7wLuSGw jIdLGaUp27sX6lLgx2epjUYnObgcsgOVqygYBc7NfqDqRa8cVnR2hETB/kdhdCrV 1GsEnVD7kd5OADDjsm7ZBJPQODK34CX47O4RO0jjEIXGW2urt5hIbfZEUGlw= X-Sasl-enc: fBMP16T99r3Hg2Fvj0XPkRsWtN0TCugTOp3Y3bYpp1yS 1427838177 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id DB99E680170; Tue, 31 Mar 2015 17:42:56 -0400 (EDT) Message-ID: <551B14D5.2010207@network-heretics.com> Date: Tue, 31 Mar 2015 17:42:45 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: <55142CA1.2000509@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Per-namespace rules about p-/q-/and f-components 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: Tue, 31 Mar 2015 21:43:02 -0000 On 03/30/2015 04:03 PM, John C Klensin wrote: > > --On Thursday, March 26, 2015 11:58 -0400 Keith Moore > wrote: > >> 3. Permitting each namespace to define its own rules for use >> of f-components, p-components, and q-components is >> problematic, at least as applied to resolvable URNs that refer >> to network-accessible and/or machine-parseable resources. One >> reason this is problematic is that it potentially forces >> client software to know about the details of each particular >> namespace, thus hindering interoperability and potentially >> limiting the useful life of a namespace even when resolution >> services continue to be available. Otherwise, the client won't >> know what to do with each particular kind of component. Does >> the f-component refer to an identifier internal to a resource >> that it downloads (as in an HTML document) or does the client >> need to interact with the service in some way to access that >> component? Does a q-component get sent as part of the >> request-URI in a GET request or what? Clients that access >> resources named by URNs over the network shouldn't have to >> have different wired-in behavior for different namespaces. >> (and no, the fact that URLs work this way is NOT a >> justification for propagating the same situation to URNs - >> URNs were, after all, partially intended to address such >> issues by decoupling resource names from the protocols used to >> access them.) > I've addressed much of this in other notes, or hope I have. And I think I've responded in my other responses to your other notes, so I'll try to not be (too) redundant here. > To > reprise part of it from a different perspective, unless we > establish a resolution (or non-resolution) model that all > namespaces follow, perhaps with plug-in parameters, some of what > you are concerned about is an issue whether these new (to URNs) > components are added in or not. If a client needs to understand > a particular namespace in order to know if it is to be resolved > or not and, if so, using what mechanisms and/or databases, then > it seems to me that having scheme-wide rules for *-components, > even if feasible, would not add much. Agreed. But as I've argued elsewhere, having generic resolution services is both necessary for URNs to be viable as identifiers in the long term (since some namespaces or their resolution services are likely to be abandoned but we'd still like for those identifiers to be useful), and explicitly anticipated by the earlier URN work. If we're going to give up any possibility of general-purpose URN handling, at either the client or the resolution service level, that should be a very explicit decision and not just a consequence of other WG decisions made by people who might not understand the implications of those decisions. (And I really want to make sure that the original URN proponents are aware that the WG is contemplating such a decision, before IETF discards many years worth of effort invested in making URNs generally resolvable.) > Similar comments apply to > "at least as applied to resolvable URNs that refer to > network-accessible and/or machine-parseable resources": if one > has to figure out whether a URN is one or those or not before > applying some supposedly-generic set rules, then the value of > those rules goes down significantly, at least assuming the > components are allowed for other varieties of URNs. I think this is less of an issue. It will always be possible to compose URIs in ways that don't actually make sense - e.g. for an HTTP-based service that takes SQL commands as query parameters, some user can always supply an invalid SQL command, one which refers to a nonexistent table or column, etc. The problem with URN overloading of 3986 syntax is not so much that one has to know what the parameters need to be - that's necessary for URLs also - it's that either (a) there's no way at all to supply parameters that will be transmitted to or evaluated in the context of the resource, or (b) in order to supply such parameters, one needs to know not only what parameters work for that particular resource, but also how to encode them in a URN according to the rules for its namespace. In the case (b), if the only way that service is ever accessed is via a single URN (and never by a URL or a URN from a different namespace), maybe that's not such a big deal. But it still introduces the problem that the developer/maintainer of that resource has to deal with parameters using a different syntax and/or encoding than that supplied with the URN, which if nothing else makes it harder to document the usage of that resource. With namespace-specific rules for mapping from URN syntax to the input fed to the resource, the namespace is adding an extra layer of obfuscation. All of my experience tells me that such layers decrease usability and reliability. > Paralleling an argument I made earlier, had folks chosen to have > two (or more) separate schemes, one for that set of resolvable > URNs and targets and others for other situations, we'd be having > a different discussion today. Right, but the whole idea of URNs was not to tie them to any specific protocols, even resolution protocols. We didn't want to repeat the situation that existed with http and other URLs where the identifier and access protocols were inherently tied together, because the successful access protocols would clearly need to evolve over time, and some of them would fall into disuse (as indeed has happened). And for transition purposes if nothing else, it should be possible for multiple URN resolution protocols to coexist, even if there's overlap between the sets of URNs that they will provide answers for, without breaking any URN functionality. >> In general I think the interpretation of a p-component, >> f-component, or q-component need to be more-or-less the same >> for all URNs. (To some degree this is already constrained by >> the decision to allow use of relative URIs with base URNs). >> I think the interpretation of these components needs to be >> exactly the same for all URNs that refer to network-accessible >> / machine-parseable resources. > I think this would be a worthwhile goal if it were feasible. I > suggest that it is not and, as I suggested in an earlier note, > that the ship sailed many years ago. I don't agree that the ship has sailed, and I think this conclusion derives from some misunderstandings which I hope are cleared up here or in one of my other recent replies. Though if there is significant deployment of URNs which have used p-, q-, and/or f-components in violation of RFC 2141, we need to make some specific exceptions to accommodate them. (in other words, what I'm proposing is that rather than say "any namespace can do whatever it wishes with these components" we should instead say "these components are to be used in this way, but for the sake of backward compatibility the following pre-existing namespaces have alternate specifications for their use of these components") >> I think this is less critical for URNs that refer to >> fixed-media resources that aren't intended to be >> machine-parseable, though I still think it will be confusing >> to users if f-components, p-components, and/or q-components >> are used in ways that aren't more-or-less consistent with HTTP >> conventions. So one compromise might be to define different >> constraints on use of f-components, p-components, and >> q-components when used to name machine-parseable resources >> than when used to name resources that aren't intended to be >> machine-parseable. > Note too that one cannot distinguish "URN for fixed-media > resource" from "URN for machine-parseable resource" even at the > namespace level. As one obvious example, at least some > publishers are assigning ISBNs to so-called eBooks. The result > is that one could have > urn:isbn:979-99-999-1234-x > and > urn:isbn:979-99-999-1345-x > (where "x" is whatever the check digit turns out to be) > And have one of them identify a book printed on paper and the > other one a electronic publication. I have always assumed that that would eventually happen, despite strong statements to the contrary from some people who insisted (e.g.) that ISBNs would always refer only to print media. Of course, if it's not appropriate for a particular namespace to impose such a rule on the resources that it names, it shouldn't do so, and that way of avoiding the problem with {f,p,q}-components doesn't work for that namespace. It might not work for any namespace. It was just a suggestion for one possible way to resolve the issue. But I'd actually rather resolve the issue in a way that doesn't further constrain what any namespace can do with its names beyond the minimum requirements already imposed for URNs. > > Because I don't think the commonality you want can be achieved > for the reasons above, this is more of an aside than a > suggestion, but one way to make users really crazy is to adopt a > rule that seems to work almost all of the time but that > sometimes don't. indeed. > >> One potential way to resolve this issue might be to declare >> that the rules for use of these components can be different >> for machine-parseable resources than for resources not >> intended to be machine-parseable. Then the people who care a >> lot about using URNs with these components with non-parseable >> resources can define rules (perhaps very simple rules) that >> make sense to them, and the people who care a lot about using >> URNs with parseable resources can define rules that make sense >> in that environment. The rules for naming resources that >> can't be parsed anyway won't affect clients that need to >> interact with parseable resources. And if it's simple to >> define the rules for non-parseable resources, namespaces that >> only assign URNs to non-parseable resources could begin to use >> f-,p-,and/or q-components. This isn't such a huge departure >> from "namespaces get to choose the rules for interpreting >> these components with respect to URNs from their namespaces" - >> except that in doing so they should be expected to cite one of >> a small number of already-approved standards for such rules. > See above. I just don't think this works without going to two > (or more) separate schemes or an NID naming convention or > reserved part of the NSS that makes the distinction. And I > think it is too late for any of those options. Nor, for reasons cited above and elsewhere, would I suggest that approach. But the issue still needs to be resolved, even if it can't be resolved using my suggestion to have different rules for parsable and non-parsable resources. > >> (Note: "machine-parseable" might not be the right dividing >> line, but I think it's closer than say "resolvable" or >> "network-accessible". But there's definitely room for >> discussion here.) > Indeed. And probably useful regardless of the outcome of the > above. > >> Another possible way to resolve this issue might be to define >> a universal URN resolution protocol that would allow a client >> to determine the meaning of f-, p-, and q-components in any >> particular URN. But I think that solution, while more >> general, is also more complex and will take much longer to >> settle on. > One would want it to also be able to determine what "resolve" > means and would resources were to be used to support it. See > earlier "General-purpose resolution service" note > (http://www.ietf.org/mail-archive/web/urn/current/msg02877.html) > >> IMO, this is a serious technical omission. > Certainly it is a difficulty, especially if one's design > religion prohibits handling these things on a per-namespace > basis. But, as I have discussed earlier (and effectively repeat > above vis-a-vis the "machine-parseable" or not distinction you > are trying to make), the fundamental design decisions that got > us to where were are were made well before this WG came into > being. I don't think so. These problems, as far as I can tell, don't exist with 2141 URNs. They exist only as a consequence of the decisions made by this WG and/or nonstandard departures from 2141 syntax. > The WG is not chartered to revisit them, nor is doing so > really feasible. So it seems to me that your argument that this > is a "technical omission" is somewhat circular: you assert that > a particular outcome is unacceptable, then claim that the WG has > left out ways to avoid that outcome. From my point of view, > that outcome, attractive or not, is inevitable given a > collection of decisions made long ago so this is no omission and > would not be an omission even if the remedies you propose were > feasible. And as I've written elsewhere, URNs were always intended to work with general-purpose resolution. I would argue that this WG is not chartered to revisit that decision. But I also think that there's some widespread misunderstanding of "decisions made long ago" within this WG which is perhaps adding some confusion to the discussion. The compromises reflected in RFC 2141 are a lot more subtle and delicate than the text in that document reveals, because the document only specifies the syntax and not so much the reasons for those choices. (The same is true for many important standards. The specifications never capture the subtleties necessary to understand the design choices. But IETF would never let a WG modify the TCP protocol without making sure that people who really understood TCP were in the loop, nor would IETF let a WG modify the TLS protocol without making sure that TLS experts were in the loop.... and yet IETF seems to have made little or no effort to make sure that people who understand the reasons for URN design decisions were in the loop for this WG.) Keith p.s. Maybe an analogy would help. Having interpretation of {f,p,q}-components of URNs be on a per-namespace basis reminds me a lot of the situation with email addresses prior to the mid-1990s, when it was common to see an admixture of rfc822, bitnet, uucp, x.400, and decnet addresses in email messages, encoded in various ways, sometimes within the headers of the same email message, but certainly different ways of expressing addresses in correspondence. Though in principle every address that appeared in a message header should have been valid for the particular context in which it appeared, in practice even this wasn't the case. Instead of handling all email addresses in a uniform fashion, mail administrators who were trying to get their users' mail delivered had to employ all kinds of special-case rules and heuristics, e.g. deciding which parts of an address were more significant than others. (e.g. should a!b!c!user@example.com be forwarded to a via UUCP, thence to be and c, thence to user@example.com, or should the message be forwarded to example.com over SMTP and allow it to forward it to a via UUCP and so on?) It's not a perfect analogy, but my take is that every URN processor should be able to apply the same set of rules to URNs not only for separating them into components, but also for looking them up in databases, for finding resolution services, for processing relative URIs if those are allowed, for finding fragments, etc., and it should be possible to define one or more namespace-independent protocols for URN resolution. The last thing we need is the kind of second-guessing about URNs that we used to need to do for email addresses. From nobody Tue Mar 31 14:43:20 2015 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 21DEE1A0383 for ; Tue, 31 Mar 2015 14:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no 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 Bxw-5TsSN0Sb for ; Tue, 31 Mar 2015 14:43:10 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0E8B1A87E0 for ; Tue, 31 Mar 2015 14:43:10 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id F1EA920AD7 for ; Tue, 31 Mar 2015 17:43:06 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Tue, 31 Mar 2015 17:43:10 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=WTvJ4IVXeYhYqsayx2N7YsXuv1E=; b=PVBk9 cpAF18pTbgyz9wtJBqNfUC2AhrEzR1qnWvPMXUc6ME/Zv4+5o6knNgTvKAklOZqh HZDSx9jNHOT+lHqBQBJDznU1CnDkGexrPWLjU+O6NzIpXV2YIS1SJCHqdeaSSyQ0 RiEnq9VliOkG0b4GjzCEdTKKmIWDP8qicRqVFc= X-Sasl-enc: q6SDcK4A8jKFwTHh3ZcsrBxfHHKG/97zp+ICP8dnmLjh 1427838189 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id AB2CC68019B; Tue, 31 Mar 2015 17:43:09 -0400 (EDT) Message-ID: <551B14E2.8060000@network-heretics.com> Date: Tue, 31 Mar 2015 17:42:58 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: <55142CA1.2000509@network-heretics.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000003060609050903070403" Archived-At: Subject: Re: [urn] Persistence with f-components or p-components 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: Tue, 31 Mar 2015 21:43:17 -0000 This is a multi-part message in MIME format. --------------000003060609050903070403 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit John, Let's take a step back here. I'm not asking for this group or this document to revisit RFC 1737s definition of persistence. Nor do I think it is in scope for this working group (as defined by its charter) to do so, as that's tantamount to redefining URNs. I'm simply asking for one or two sentences to be added to rfc2141bis to clarify which of f-component, p-component, and q-component are relevant when considering persistence. RFC 2141 didn't need to address this issue because with RFC 2141 URNs, the entire URN was assigned, so the persistence property applied to the entire URN. The text I have in mind is something like: Only the [list of components] of the URN are required to meet the "persistence" property specified in RFC 1737. Individual namespaces may, however, impose more stringent requirements on use of [other components]. I just don't know what should be that list of components. I can, however, somewhat arbitrarily, suggest concrete text: Only the assigned-name and p-component of the URN are required to meet the "persistence" property specified in RFC 1737. Individual namespaces may, however, impose additional restrictions on the use of q-component and/or f-component. (and if a normative reference to RFC 1737 is a problem, just leave out "specified in RFC 1737". RFC 1737 would probably have been a BCP, had BCPs existed at the time.) Keith p.s. now if we really want to talk about why RFC 1737's definition of persistence is the correct one for URNs, and why nobody (from this planet, at least) has centuries of experience naming network-accessible resources that have the potential to change continuously, and why the fact that some people claim that other kinds of URIs can have similar persistence properties is irrelevant because we're only talking about URNs here, etc., etc., we can do that. But I think it's counterproductive to make any of those discussions block this document. On 03/31/2015 02:28 PM, John C Klensin wrote: > Keith (and others), > > I believe this is the last in my long series of initial > responses to the "details" raised in your review. If anyone > thinks there are separate issues I have missed, please identify > them, ideally with subject lines that distinguish them from > those already addressed. > > While I assume (and hope) that discussions will continue along > each of these threads, I note that several of the issues appear > to me to be more intertwined than the review suggested. I hope > that we can now consolidate them as part of the resolution > process, especially because some of them overlap with issues in > the tracker or that were resolved years ago. > > > --On Thursday, March 26, 2015 11:58 -0400 Keith Moore > wrote: > >> ... >> 2. The document fails to specify which parts of a URN >> containing f-components or q-components must be persistent. > >> For example, since URN x is required to be persistent, is x#y >> also required to be persistent? Similarly for x?y and x/y. >> Or do the persistence requirements only apply to some of these >> and not others? > See my comments below yours about the general issue of > "persistence requirements". I'm quoting this entire section of > your note because the original is now several days old and > because it seems useful to focus on this issue. > >> IIRC, the reason RFC 2141 doesn't permit '/', '?', or '#' in >> NSSs is that we couldn't figure out how to define or ensure >> persistence in these cases in a way that made sense across a >> wide variety of use cases. The current rfc2141bis document >> still fails to address these problems. >> >> At one level the problems with p-components, f-components, and >> q-components are the same problem - how to ensure persistence >> of a structured identifier for a resource that can be revised >> over time, including potentially in ways that change its >> internal structure and/or relationships with other resources. >> But at another level I suspect that these are subtly different >> problems. If we're going to use p-components, f-components, >> and q-components in ways that are even vaguely similar to >> their use in HTTP URLs then p-components are going to reflect >> structure between resources, f-components are going to reflect >> structure internal to the named resource, and q-components for >> ... something else (more on that later). (And if we're not >> going to use these components in those ways, why burden URNs >> with a syntax that is certain to confuse users?) >> >> IMO, this is a serious technical omission, one that is likely >> to undermine the fundamental URN property of persistence, and >> {f,p,q}-components shouldn't be permitted in URNs until this >> is settled. > I've commented on pieces of this issue earlier, but, if we have > to reach consensus about precisely what "persistence" means and > what its boundaries are, I think we are in big trouble with no > way to get out of it. You obviously have a clear vision on > what it means, clear enough to believe it is a "fundamental > property" and that there are "persistence requirements". Others > have made rather strong arguments that there is no such thing -- > that everything passes eventually and that any assertions about > persistence have to be made in a very specific content. Some of > those arguments have included assertions that, in the long run, > a DNS-dependent URL with appropriate precautions can be as > "persistent" as any URN. > > I believe it is not an accident that RFC 2141 does not attempt > to define "persistent". RFC 1737 does and says: > > "Persistence: It is intended that the lifetime of a URN > be permanent. That is, the URN will be globally unique > forever, and may well be used as a reference to a > resource well beyond the lifetime of the resource it > identifies or of any naming authority involved in the > assignment of its name." > > but that definition does absolutely nothing to resolve the > questions addressed in this note, nor does it provide any sort > of bright line. I also note, partially addressing Larry's > concerns, that the "any resource that might conceivably be > available on the network" provision of the following statement > would ban indicator-type URNs where there is no underlying > "resource", much less one that is "available on the network". > URNs have evolved a great deal since 1994 (including in part due > to the collapse of the IIIA model and the disappearance of URCs, > neither of which are, AFAICT, even mentioned in 3986) and all, > or almost all, of the pivotal decisions in that evolution > occurred before this WG came into being and are not within its > scope to try to reverse even if that were desirable. > > I also note that Juha and others have told us that the way in > which we use the term "identifier" is often inconsistent with > the use of that term in communities that have far more specific > definitions (and a few centuries more experience). As with > "persistence", I think trying to draw exact lines will result in > paralysis without any obvious path forward. > > The notion of persistence also gets tangled up with an old > distinction and example. Consider three URNs: > > (i) One that references the current weather wherever I > happen to be right now. > (ii) One that references the current weather in > Stockholm. > (iii) One that references the weather in Stockholm as of > 2015-03-31 17:00:00 UTC. > > At least according to my memory from well over a decade ago (two > if one counts RFC 1737), each of these could be a valid URN. > Each is persistent at the URN identifier level (but so is a URL > whose domain name vanishes or is reassigned to a different > owner). None of them are network location-dependent. Each is > resolvable and resolvable in more than one way, although they > impose different requirements on the external knowledge that > must be available to the resolution mechanism. Only the third > resolves to a constant result and, even then, the constancy/ > persistency of that result is dependent on some notions of > official statistics versus other sorts of measurements (and > micro-geography) that might be equally or more useful or > "accurate". > > None of these distinctions require moving beyond 2141. If > 2141bis has issues with persistence, so does 2141. What is new > with 2141bis and these various components is some design choices > about whether, e.g., information or specifications belong as > part of an extended NSS or in a {p,q,f}-component. If you > imagine, as I think we did a decade ago, that the third example > above might be written > > urn:weather:SE:stockholm:2015-03-31-17:00:00 > > then there is now a potential design decision that might have it > written as > > urn:weather:SE:stockholm?date=2015-03-31-17:00:00 > > I think it would be really hard to argue that one of these (or > other permutations of the information) is more or less > persistent than the other, but I think it is hard to think about > generic guidance especially because, while that choice might > exist for the hypothetical "weather" NID and namespace, it > doesn't exist for something like an ISBN whose NSS is > effectively specified by other standards. > > It seems to me that we are getting close to a religious argument > in which people behave as if features can be included or > excluded or assigned particular properties by pronouncing the > term "persistence" in appropriately pious tones. That seems to > me to be bad news, especially if we are then going to have > sectarian battles about the meaning of the term. > > I see two ways forward although I hope things are not quite this > much of a dichotomy: > > (1) We accept persistence as a general goal and principle of > URNs, clearly excluding things that are > network-location-dependent. We consider as valid both pure > indicators and things that represent a high level of abstraction > and that can identify any of the members of a family of objects > that are considered equivalent (at least within the definitions > of the namespace). We also accept that, however clear those > cases may be, there are _lots_ of gray areas. > > Design guidance about the choices implied by the example above > would certainly be desirable but I don't think we are ready to > provide it, much less reach consensus on it. I hope we can keep > that work out of the critical path of the WG because I think we > will fail if we try. > > I don't believe that approach will "undermine the fundamental > URN property of persistence" because, while I respect the > general principle of persistence, I think we were already well > past the point that there was a "fundamental property" to be > undermined... and well past it before this WG got started and > proposed {p,q,f}-components. > > (2) We start down a path that, especially given the presence in > the community of people who believe that "persistence" > discussions are meaningless, leads to our either being stuck > with 2141 or abandoning and deprecating URNs entirely except, > perhaps, for a very narrow range of cases. Given that there are > millions of deployed URNs and that many of them would probably > not conform to whatever restricted rules were adopted to ensure > persistent purity, I can't imagine that working out very well if > only because the user community would probably ignore us. > > But I may be wrong. That could be easily demonstrated if there > were a clear and concise definition of "persistence" that would > be generally accepted (including surviving the objections of > those who claim there is no such thing) and that would enable > the distinctions you are seeking. If you have such a > definition, please post it to the list. > > best, > john > > > > --------------000003060609050903070403 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
John,

Let's take a step back here.   I'm not asking for this group or this document to revisit RFC 1737s definition of persistence.   Nor do I think it is in scope for this working group (as defined by its charter) to do so, as that's tantamount to redefining URNs.  

I'm simply asking for one or two sentences to be added to rfc2141bis to clarify which of f-component, p-component, and q-component are relevant when considering persistence.   RFC 2141 didn't need to address this issue because with RFC 2141 URNs, the entire URN was assigned, so the persistence property applied to the entire URN.

The text I have in mind is something like:

Only the [list of components] of the URN are required to meet the "persistence" property specified in RFC 1737.   Individual namespaces may, however, impose more stringent requirements on use of [other components].

I just don't know what should be that list of components.  I can, however, somewhat arbitrarily, suggest concrete text:

Only the assigned-name and p-component of the URN are required to meet the "persistence" property specified in RFC 1737.   Individual namespaces may, however, impose additional restrictions on the use of q-component and/or f-component.

(and if a normative reference to RFC 1737 is a problem, just leave out "specified in RFC 1737".   RFC 1737 would probably have been a BCP, had BCPs existed at the time.)

Keith

p.s. now if we really want to talk about why RFC 1737's definition of persistence is the correct one for URNs, and why nobody (from this planet, at least) has centuries of experience naming network-accessible resources that have the potential to change continuously, and why the fact that some people claim that other kinds of URIs can have similar persistence properties is irrelevant because we're only talking about URNs here, etc., etc., we can do that.   But I think it's counterproductive to make any of those discussions block this document.


On 03/31/2015 02:28 PM, John C Klensin wrote:
Keith (and others),

I believe this is the last in my long series of initial
responses to the "details" raised in your review.  If anyone
thinks there are separate issues I have missed, please identify
them, ideally with subject lines that distinguish them from
those already addressed.

While I assume (and hope) that discussions will continue along
each of these threads, I note that several of the issues appear
to me to be more intertwined than the review suggested.  I hope
that we can now consolidate them as part of the resolution
process, especially because some of them overlap with issues in
the tracker or that were resolved years ago.


--On Thursday, March 26, 2015 11:58 -0400 Keith Moore
<moore@network-heretics.com> wrote:


...
2.  The document fails to specify which parts of a URN
containing f-components or q-components must be persistent.

 

For example, since URN x is required to be persistent, is x#y
also required to be persistent?   Similarly for x?y and x/y.
Or do the persistence requirements only apply to some of these
and not others?

See my comments below yours about the general issue of
"persistence requirements".  I'm quoting this entire section of
your note because the original is now several days old and
because it seems useful to focus on this issue.


IIRC, the reason RFC 2141 doesn't permit '/', '?', or '#' in
NSSs is that we couldn't figure out how to define or ensure
persistence in these cases in a way that made sense across a
wide variety of use cases.   The current rfc2141bis document
still fails to address these problems.

At one level the problems with p-components, f-components, and
q-components are the same problem - how to ensure persistence
of a structured identifier for a resource that can be revised
over time, including potentially in ways that change its
internal structure and/or relationships with other resources.
But at another level I suspect that these are subtly different
problems.   If we're going to use p-components, f-components,
and q-components in ways that are even vaguely similar to
their use in HTTP URLs then p-components are going to reflect
structure between resources, f-components are going to reflect
structure internal to the named resource, and q-components for
... something else (more on that later).   (And if we're not
going to use these components in those ways, why burden URNs
with a syntax that is certain to confuse users?)

IMO, this is a serious technical omission, one that is likely
to undermine the fundamental URN property of persistence, and
{f,p,q}-components shouldn't be permitted in URNs until this
is settled.

I've commented on pieces of this issue earlier, but, if we have
to reach consensus about precisely what "persistence" means and
what its boundaries are, I think we are in big trouble with no
way to get out of it.   You obviously have a clear vision on
what it means, clear enough to believe it is a "fundamental
property" and that there are "persistence requirements".  Others
have made rather strong arguments that there is no such thing --
that everything passes eventually and that any assertions about
persistence have to be made in a very specific content.  Some of
those arguments have included assertions that, in the long run,
a DNS-dependent URL with appropriate precautions can be as
"persistent" as any URN.

I believe it is not an accident that RFC 2141 does not attempt
to define "persistent".   RFC 1737 does and says:

	"Persistence: It is intended that the lifetime of a URN
	be permanent.  That is, the URN will be globally unique
	forever, and may well be used as a reference to a
	resource well beyond the lifetime of the resource it
	identifies or of any naming authority involved in the
	assignment of its name."

but that definition does absolutely nothing to resolve the
questions addressed in this note, nor does it provide any sort
of bright line.   I also note, partially addressing Larry's
concerns, that the "any resource that might conceivably be
available on the network" provision of the following statement
would ban indicator-type URNs where there is no underlying
"resource", much less one that is "available on the network".
URNs have evolved a great deal since 1994 (including in part due
to the collapse of the IIIA model and the disappearance of URCs,
neither of which are, AFAICT, even mentioned in 3986) and all,
or almost all, of the pivotal decisions in that evolution
occurred before this WG came into being and are not within its
scope to try to reverse even if that were desirable.

I also note that Juha and others have told us that the way in
which we use the term "identifier" is often inconsistent with
the use of that term in communities that have far more specific
definitions (and a few centuries more experience).  As with
"persistence", I think trying to draw exact lines will result in
paralysis without any obvious path forward.

The notion of persistence also gets tangled up with an old
distinction and example. Consider three URNs:

 (i) One that references the current weather wherever I
	happen to be right now.
 (ii) One that references the current weather in
	Stockholm.
 (iii) One that references the weather in Stockholm as of
	2015-03-31 17:00:00 UTC.

At least according to my memory from well over a decade ago (two
if one counts RFC 1737), each of these could be a valid URN.
Each is persistent at the URN identifier level (but so is a URL
whose domain name vanishes or is reassigned to a different
owner).  None of them are network location-dependent.  Each is
resolvable and resolvable in more than one way, although they
impose different requirements on the external knowledge that
must be available to the resolution mechanism.  Only the third
resolves to a constant result and, even then, the constancy/
persistency of that result is dependent on some notions of
official statistics versus other sorts of measurements (and
micro-geography) that might be equally or more useful or
"accurate".

None of these distinctions require moving beyond 2141.   If
2141bis has issues with persistence, so does 2141.  What is new
with 2141bis and these various components is some design choices
about whether, e.g., information or specifications belong as
part of an extended NSS or in a {p,q,f}-component.   If you
imagine, as I think we did a decade ago, that the third example
above might be written

    urn:weather:SE:stockholm:2015-03-31-17:00:00

then there is now a potential design decision that might have it
written as

    urn:weather:SE:stockholm?date=2015-03-31-17:00:00

I think it would be really hard to argue that one of these (or
other permutations of the information) is more or less
persistent than the other, but I think it is hard to think about
generic guidance especially because, while that choice might
exist for the hypothetical "weather" NID and namespace, it
doesn't exist for something like an ISBN whose NSS is
effectively specified by other standards.

It seems to me that we are getting close to a religious argument
in which people behave as if features can be included or
excluded or assigned particular properties by pronouncing the
term "persistence" in appropriately pious tones.  That seems to
me to be bad news, especially if we are then going to have
sectarian battles about the meaning of the term.  

I see two ways forward although I hope things are not quite this
much of a dichotomy:

(1) We accept persistence as a general goal and principle of
URNs, clearly excluding things that are
network-location-dependent.  We consider as valid both pure
indicators and things that represent a high level of abstraction
and that can identify any of the members of a family of objects
that are considered equivalent (at least within the definitions
of the namespace).  We also accept that, however clear those
cases may be, there are _lots_ of gray areas.

Design guidance about the choices implied by the example above
would certainly be desirable but I don't think we are ready to
provide it, much less reach consensus on it.  I hope we can keep
that work out of the critical path of the WG because I think we
will fail if we try.

I don't believe that approach will "undermine the fundamental
URN property of persistence" because, while I respect the
general principle of persistence, I think we were already well
past the point that there was a "fundamental property" to be
undermined... and well past it before this WG got started and
proposed {p,q,f}-components.

(2) We start down a path that, especially given the presence in
the community of people who believe that "persistence"
discussions are meaningless, leads to our either being stuck
with 2141 or abandoning and deprecating URNs entirely except,
perhaps, for a very narrow range of cases.  Given that there are
millions of deployed URNs and that many of them would probably
not conform to whatever restricted rules were adopted to ensure
persistent purity, I can't imagine that working out very well if
only because the user community would probably ignore us.

But I may be wrong.  That could be easily demonstrated if there
were a clear and concise definition of "persistence" that would
be generally accepted (including surviving the objections of
those who claim there is no such thing) and that would enable
the distinctions you are seeking.  If you have such a
definition, please post it to the list.

     best,
      john

--------------000003060609050903070403-- From nobody Tue Mar 31 14:51:48 2015 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 21BAD1AD0B7 for ; Tue, 31 Mar 2015 14:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Ax5_q5nutIxK for ; Tue, 31 Mar 2015 14:51:45 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A66C1AD0B6 for ; Tue, 31 Mar 2015 14:51:45 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 8F6F820B00 for ; Tue, 31 Mar 2015 17:51:41 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 31 Mar 2015 17:51:44 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=08o95gZemsWmRRbN2FBpTk92HGY=; b=Ak7tD b7sWoIukli529B61kukQkuopC5yOD49BlebtsVa9DLLIQN1w86q5CUyXTN7mNV06 kUgDvTqZCKOILmXaDZiffFFPQ/OV3JfWNFz7bM4rBNXPFFt5Ilwj0MSqlickdBLi fPmKNub7kB1OXyUX2GQ3mFUqTSm9vtOrRcimPY= X-Sasl-enc: OBtSDoNVYmCtVL9LNTOIqDhgPoztW0NSMIrZYYTveZsU 1427838704 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id F20B86801BF; Tue, 31 Mar 2015 17:51:43 -0400 (EDT) Message-ID: <551B16E4.3010502@network-heretics.com> Date: Tue, 31 Mar 2015 17:51:32 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Andrew Newton , John C Klensin References: <55142CA1.2000509@network-heretics.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020204050107090706010003" Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Per-namespace rules about p-/q-/and f-components 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: Tue, 31 Mar 2015 21:51:47 -0000 This is a multi-part message in MIME format. --------------020204050107090706010003 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 03/30/2015 06:00 PM, Andrew Newton wrote: > > On Mon, Mar 30, 2015 at 4:03 PM, John C Klensin > wrote: > > But it seems to me that we > started allowing the "urn:" scheme to be used for URNs that do > not resolve to network-accessible or computer-processable > (parseable or not) resources even before URNs got off the ground. > > > This was the very first question that popped into my head when I > started thinking about a universal/generic URN resolver. How is it > suppose to know which ones are meant to be resolved to network > resources and which are not? The client doesn't know this, necessarily. But the URN might have appeared in a context (say an HTML tag) for which the URN only make sense if the resource can be accessed, and the first step in doing that is to query a resolver. (Of course, if the named resource can't be accessed for whatever reason, it's more-or-less equivalent to a URL that can't be accessed for whatever reason.) If the resolver has information about the URN, it might be able to respond with information about how to access the resource over the network, or it might actually be able to provide such access by itself. But it might only know citation information for the URN, even if the resource is network-accessible, and that citation information might or not include information of network accessibility. Also, part of that citation information might be some sort of resource type indication, so presumably a book or sound recording or whatever that wasn't accessible over the network would have a different resource type than a web page or web server or whatever that can be accessed over the network. But there the line is a bit blurry, since it's completely reasonable to think in terms of accessing, say, a physical DVD over the network, say from a library's collection, even though it's a physical data storage medium. Keith --------------020204050107090706010003 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 03/30/2015 06:00 PM, Andrew Newton wrote:

On Mon, Mar 30, 2015 at 4:03 PM, John C Klensin <john-ietf@jck.com> wrote:
But it seems to me that we
started allowing the "urn:" scheme to be used for URNs that do
not resolve to network-accessible or computer-processable
(parseable or not) resources even before URNs got off the ground.

This was the very first question that popped into my head when I started thinking about a universal/generic URN resolver. How is it suppose to know which ones are meant to be resolved to network resources and which are not?

The client doesn't know this, necessarily.   But the URN might have appeared in a context (say an HTML tag) for which the URN only make sense if the resource can be accessed, and the first step in doing that is to query a resolver.   (Of course, if the named resource can't be accessed for whatever reason, it's more-or-less equivalent to a URL that can't be accessed for whatever reason.)

If the resolver has information about the URN, it might be able to respond with information about how to access the resource over the network, or it might actually be able to provide such access by itself.   But it might only know citation information for the URN, even if the resource is network-accessible, and that citation information might or not include information of network accessibility.  

Also, part of that citation information might be some sort of resource type indication, so presumably a book or sound recording or whatever that wasn't accessible over the network would have a different resource type than a web page or web server or whatever that can be accessed over the network.   But there the line is a bit blurry, since it's completely reasonable to think in terms of accessing, say, a physical DVD over the network, say from a library's collection, even though it's a physical data storage medium.

Keith
--------------020204050107090706010003-- From nobody Tue Mar 31 14:52:47 2015 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 464BC1A005F for ; Tue, 31 Mar 2015 14:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.901 X-Spam-Level: X-Spam-Status: No, score=0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no 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 uVR6SYvWzK0m for ; Tue, 31 Mar 2015 14:52:42 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2FD1A00D4 for ; Tue, 31 Mar 2015 14:52:42 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 0098420802 for ; Tue, 31 Mar 2015 17:52:38 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Tue, 31 Mar 2015 17:52:42 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=U0PXkK6kFMyMs2sbe7OFHh1CWxo=; b=N+iTk 7C8ACEsInAksiXCRGC4uGPQ/6WOYcppx8yJ9HhU2BbInngsEUMoqdrHjJkbCoTYb 0PoI7cPnP0DR3Yds2kOyW7uX35xRBokHrX3WwFN/Ytoe5U3NHZ+IJBcIR0tZjsnS flkDjI96M2QDQCkkKbfEudvWGpK/pD9DMoDThA= X-Sasl-enc: CGY/UmgFA5tRvNiGUDcTlItpzsico7udxcOCsYe5ctQJ 1427838761 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id B33C2680110; Tue, 31 Mar 2015 17:52:41 -0400 (EDT) Message-ID: <551B171E.2090309@network-heretics.com> Date: Tue, 31 Mar 2015 17:52:30 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: <0D9E71DB-2B12-4AFE-A8BB-F586CDC24EC2@adobe.com> <55158C1D.1010404@andyet.net> <55165642.10509@network-heretics.com> <85FB58DE07D859CA5E2E69EF@JcK-HP8200.jck.com> In-Reply-To: <85FB58DE07D859CA5E2E69EF@JcK-HP8200.jck.com> Content-Type: multipart/alternative; boundary="------------040408020006060309030504" Archived-At: Subject: Re: [urn] Fragments and URN pass-through components 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: Tue, 31 Mar 2015 21:52:46 -0000 This is a multi-part message in MIME format. --------------040408020006060309030504 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 03/29/2015 02:40 PM, John C Klensin wrote: > > --On Saturday, March 28, 2015 03:20 -0400 Keith Moore > wrote: > >>> An alternative would be to change uri-scheme-reg (as well as >>> 3986) to ALLOW scheme-specific fragments. I find this more >>> attractive, because there ARE some use cases for >>> scheme-specific fragments, e.g., temporal fragments of >>> realtime URIs. >> Good catch. I don't think this can be fixed without updating >> 3986. > Well... Variations on this have been raised and discussed, > although with little response on the list. I hope you folks > have been reading it and am disappointed this didn't come up > earlier. > > First, the "syntax only" decision makes the binding that 3986 > specifies between fragments and media types inapplicable to URNs > and hence allows URN-scheme-specific fragments and fragment > interpretation. I hope we don't need to revisit that issue. I suspect that we do, for reasons cited elsewhere, i.e. because this forces clients to have specific knowledge about every URN scheme in order to resolve URNs in a generic fashion. > I > agree that there is a more general issue and that it needs to be > addressed in a revision or update of 3986, but that isn't a > URNBIS WG problem. That leads to... > >> I'm personally sympathetic to the idea that fragments should >> be defined differently for URNs than for URLs. But this >> still begs the question of how to interpret fragments for URNs >> that resolve to URLs. If urn:X resolves to http:Y, should >> urn:X#z resolve to http:Y#z or what? I'm really >> uncomfortable with the notion that using a URN to name a >> resource that also has a URL means that you can't address a >> fragment of that resource, or that there are potentially >> different names for the same fragments of that resource. > This is part of a more general problem that concerns me (and > that, again, has been raised earlier). > > Let's examine URNs that resolve to one or more URLs and ignore > other types of URNs for a moment. Can one plausibly assume that > all of those URLs (or whatever resolves or executes them) will > consider the same set of, e.g., queries or fragments to be > plausible? If not, do we care and, in particular, does that > violate whatever we think we mean by persistence? I don't know that we can plausibly assume that. But I don't think it inherently violates persistence for a URN to resolve to more than one form of the same content, which might yet vary among one another in their interpretation of fragments or queries. [1] For instance urn:ietf:rfc:3986 might reasonably resolve to a text, an HTML, and a PDF version of the same document, but it might be the case that only the HTML document supports fragments, or that the fragment names in the HTML version don't match those in the PDF version. What I do think is reasonable is to declare that if a URN resolves to multiple forms of the same content that vary in fragment or query interpretation, that use of an f-component or q-component with such a URN is undefined. Or alternatively, if a URN resolves to multiple forms of the same content that vary in fragment or query interpretation, the effect of interpreting fragment or query information that are supplied with the URN (whatever the syntax) in terms of the actual resource is undefined, unless perhaps also supplied with the URN is some directive that constrains the choice of which form of the content to resolve to. (is that complicated enough?) (Note that this can happen even when not using URNs at all, since HTTP itself supports various forms of content negotiation. Even though TimBL once vigorously insisted to me that fragments and queries had to be invariant across content negotiation, that's clearly not likely to work across multiple content-types that have different notions of fragments, and/or require different access protocols that impose different constraints on queries. Anyway, if HTTP can't make fragments or queries invariant across content-negotiation, it's probably not reasonable to expect URNs or URN resolution to do so.) [1] What might violate persistence is for a URN that contains an f-component or q-component to resolve to different revision of the same resource at different times, such that the meaning of the base URN when combined with the f-component or q-component changed over time. This is why I want rfc2141bis to define whether each of f-, p-, and q-components affect persistence of the resulting identifier. Note that I think it's going to be very confusing to people to understand that for a string like "urn:foo:bar/zot?xyzzy#mumble" that the whole string isn't persistent but, say, the "urn:foo:bar/zot" portion (or maybe just the "urn:foo:bar" portion) is persistent. And I think it endangers the valuable property that exists with 2141-conforming URNs that an identifier beginning with "urn:" can be assumed to be persistent - since especially if URNs use rfc3986 syntax, people will consider the entire identifier as part of the URN - just like they're used to parsing HTTP URLs. But I also recognize that there's tremendous pressure to combine fragments and queries and path components with URNs, so I'm just asking that 2141bis define which portions of such URNs are supposed to be persistent. > > Note that "persistence" gets tricky in this case. If one > assumes that the URN identifies a document, like the content of > an RFC, that will [soon] be available in multiple forms and with > multiple online locations/copies of each form, the URLs to which > the URN might lead are not only not all equal but different > members of the set point to those different instantiations of > something the RFC Editor is required to believe are the same > content and therefore the rest of us are too. It may be that > invalidates the urn:ietf:rfc sub-namespace as insufficiently > persistent the moment the alternate forms start being published > but, if so, I see that as a problem for the RFC Editor and not > this WG. Right, but I don't think the URN concept of "persistence" was ever intended to apply to variations in content rendition of the same revision of a resource. It was certainly intended apply to variations between different versions of the resource, and to forbid reusing the same URN to apply to a "different" resource at a later time. > > If it does not invalidate the namespace completely, one > interesting question (which has come up in the WG before) then > becomes whether it would be legitimate to have a URN with a > query component that looked essentially like: > > urn:ietf:rfc:9999?format=pdf > > (I note that is _not_ possible without a redefinition and > registration of the "ietf" namespace and its "rfc" sub-namespace > (or whatever one calls those) because 2141bis is quite specific > that, if a registration doesn't explicitly legitimize > q-components for a particular namespace, they are not permitted.) > > The important characteristic of the above is the "?format=pdf" > really is qualifying information for the base URN, telling the > URN "resolver" which URLs from the collection that would be > possible without it to to return, and not a query to be applied > to one or more of those URLs. > > Contrast it with > > urn:ietf:rfc:9999#Section3.1 > or, if you prefer > urn:ietf:rfc:9999?Section=3.1 > > Where the f- and q-components are almost certainly intended to > be passed through to the URLs as fragments or queries. > > >From at least one perspective, distinctions between the object > associated with an identifier and assorted metadata associated > with either the object or the identifier are just special cases > of the "instructions to the URN resolver" case. > > We don't have any lexical or other namespace-independent way to > distinguish between the "instructions to the URN resolver" and > "instructions to be passed through to the URL" cases. We've > raised it on the list, with proposals to > > * Reserve q-components for local instructions and > f-components for pass-through and vice versa > > * Create some special, scheme-wide (i.e., applying to > all URN namespaces that allow the relevant components) > syntax or keywords to separate the two cases. > > I don't believe that either of those notions, or anything else > that has been proposed, has gotten nearly enough traction in the > WG to justify a specification that would apply across the > collection of namespaces. So we are left with a per-namespace > situation that leaves notions of generic resolvers, even for the > narrow range of cases in which URNs are known to resolve to URLs > (or a selection from a family of URLs) in even more trouble. > > I, at least, would welcome suggestions. Lamenting the state we > find ourselves in seems less helpful. Basically I don't think the document meets 2026 criteria for Proposed Standard without resolving these issues, that IESG should not approve it unless/until such issues are resolved, and that we're doing harm to URNs (and thus acting against what I assume all of us care about) if we don't resolve these issues. But to fix it, I think we "just" have to (a) define which of the f-, p-, and/or q-components of a URN are required to be persistent along with the base URN (Even if the answer is "none of the above", I think we still need to say that. And I think each of these components needs to be considered separately, as the answer might well be different for different components, particularly given the desire to support relative URIs in conjunction with base URNs), and (b) define some standard and namespace-independent means of indicating how to pass fragment and query to the resource for those cases in which the resource accepts them. It might be that we just need to reserve some subset of fragment names and query parameter names (say, all names beginning with "~") for fragments or queries to be evaluated in the context of the resource (after removing the "~"). And of course 2141bis needs to be fixed so that it doesn't preclude a general-purpose resolution protocol by permitting each new namespace to have different behavior for f-, p-, and q-components. An alternative to (b) might be to define a standardized general-purpose resolution protocol, so that there would be a standard way to determine the mapping of urn:foo:bar?x#y onto one or more URLs that mapped x and/or y to the URL when appropriate. But that solution has the possibly unfortunate side-effect of requiring resolution just in order to find out how to evaluate x in y in the context of a copy of the resource. In other words, it's not sufficient to have a copy of urn:foo:bar or urn:foo:bar?x already cached in order to find fragment y, you actually have to know what the mapping is too. Keith --------------040408020006060309030504 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 03/29/2015 02:40 PM, John C Klensin wrote:

--On Saturday, March 28, 2015 03:20 -0400 Keith Moore
<moore@network-heretics.com> wrote:


An alternative would be to change uri-scheme-reg (as well as
3986) to ALLOW scheme-specific fragments. I find this more
attractive, because there ARE some use cases for
scheme-specific fragments, e.g., temporal fragments of
realtime URIs.

Good catch.   I don't think this can be fixed without updating
3986.

Well...   Variations on this have been raised and discussed,
although with little response on the list.  I hope you folks
have been reading it and am disappointed this didn't come up
earlier.

First, the "syntax only" decision makes the binding that 3986
specifies between fragments and media types inapplicable to URNs
and hence allows URN-scheme-specific fragments and fragment
interpretation.  I hope we don't need to revisit that issue.

I suspect that we do, for reasons cited elsewhere, i.e. because this forces clients to have specific knowledge about every URN scheme in order to resolve URNs in a generic fashion.

 I
agree that there is a more general issue and that it needs to be
addressed in a revision or update of 3986, but that isn't a
URNBIS WG problem.  That leads to...


I'm personally sympathetic to the idea that fragments should
be defined differently for URNs than for URLs.   But this
still begs the question of how to interpret fragments for URNs
that resolve to URLs.   If urn:X resolves to http:Y, should
urn:X#z resolve to http:Y#z or what?   I'm really
uncomfortable with the notion that using a URN to name a
resource that also has a URL means that you can't address a
fragment of that resource, or that there are potentially
different names for the same fragments of that resource.

This is part of a more general problem that concerns me (and
that, again, has been raised earlier).

Let's examine URNs that resolve to one or more URLs and ignore
other types of URNs for a moment.  Can one plausibly assume that
all of those URLs (or whatever resolves or executes them) will
consider the same set of, e.g., queries or fragments to be
plausible?  If not, do we care and, in particular, does that
violate whatever we think we mean by persistence?

I don't know that we can plausibly assume that.  But I don't think it inherently violates persistence for a URN to resolve to more than one form of the same content, which might yet vary among one another in their interpretation of fragments or queries. [1]   For instance urn:ietf:rfc:3986 might reasonably resolve to a text, an HTML, and a PDF version of the same document, but it might be the case that only the HTML document supports fragments, or that the fragment names in the HTML version don't match those in the PDF version.  

What I do think is reasonable is to declare that if a URN resolves to multiple forms of the same content that vary in fragment or query interpretation, that use of an f-component or q-component with such a URN is undefined.   Or alternatively, if a URN resolves to multiple forms of the same content that vary in fragment or query interpretation, the effect of interpreting fragment or query information that are supplied with the URN (whatever the syntax) in terms of the actual resource is undefined, unless perhaps also supplied with the URN is some directive that constrains the choice of which form of the content to resolve to.   (is that complicated enough?)

(Note that this can happen even when not using URNs at all, since HTTP itself supports various forms of content negotiation.   Even though TimBL once vigorously insisted to me that fragments and queries had to be invariant across content negotiation, that's clearly not likely to work across multiple content-types that have different notions of fragments, and/or require different access protocols that impose different constraints on queries.    Anyway, if HTTP can't make fragments or queries invariant across content-negotiation, it's probably not reasonable to expect URNs or URN resolution to do so.)

[1] What might violate persistence is for a URN that contains an f-component or q-component to resolve to different revision of the same resource at different times, such that the meaning of the base URN when combined with the f-component or q-component changed over time.   This is why I want rfc2141bis to define whether each of f-, p-, and q-components affect persistence of the resulting identifier.   Note that I think it's going to be very confusing to people to understand that for a string like "urn:foo:bar/zot?xyzzy#mumble" that the whole string isn't persistent but, say, the "urn:foo:bar/zot" portion (or maybe just the "urn:foo:bar" portion) is persistent.    And I think it endangers the valuable property that exists with 2141-conforming URNs that an identifier beginning with "urn:" can be assumed to be persistent - since especially if URNs use rfc3986 syntax, people will consider the entire identifier as part of the URN -  just like they're used to parsing HTTP URLs.    But I also recognize that there's tremendous pressure to combine fragments and queries and path components with URNs, so I'm just asking that 2141bis define which portions of such URNs are supposed to be persistent.


Note that "persistence" gets tricky in this case.  If one
assumes that the URN identifies a document, like the content of
an RFC, that will [soon] be available in multiple forms and with
multiple online locations/copies of each form, the URLs to which
the URN might lead are not only not all equal but different
members of the set point to those different instantiations of
something the RFC Editor is required to believe are the same
content and therefore the rest of us are too.   It may be that
invalidates the urn:ietf:rfc sub-namespace as insufficiently
persistent the moment the alternate forms start being published
but, if so, I see that as a problem for the RFC Editor and not
this WG.

Right, but I don't think the URN concept of "persistence" was ever intended to apply to variations in content rendition of the same revision of a resource.   It was certainly intended  apply to variations between different versions of the resource, and to forbid reusing the same URN to apply to a "different" resource at a later time.


If it does not invalidate the namespace completely, one
interesting question (which has come up in the WG before) then
becomes whether it would be legitimate to have a URN with a
query component that looked essentially like:

   urn:ietf:rfc:9999?format=pdf

(I note that is _not_ possible without a redefinition and
registration of the "ietf" namespace and its "rfc" sub-namespace
(or whatever one calls those) because 2141bis is quite specific
that, if a registration doesn't explicitly legitimize
q-components for a particular namespace, they are not permitted.)

The important characteristic of the above is the "?format=pdf"
really is qualifying information for the base URN, telling the
URN "resolver" which  URLs from the collection that would be
possible without it to to return, and not a query to be applied
to one or more of those URLs.

Contrast it with 

   urn:ietf:rfc:9999#Section3.1
or, if you prefer
   urn:ietf:rfc:9999?Section=3.1

Where the f- and q-components are almost certainly intended to
be passed through to the URLs as fragments or queries.

>From at least one perspective, distinctions between the object
associated with an identifier and assorted metadata associated
with either the object or the identifier are just special cases
of the "instructions to the URN resolver" case.

We don't have any lexical or other namespace-independent way to
distinguish between the "instructions to the URN resolver" and
"instructions to be passed through to the URL" cases.  We've
raised it on the list, with proposals to 

	* Reserve q-components for local instructions and
	f-components for pass-through and vice versa
	
	* Create some special, scheme-wide (i.e., applying to
	all URN namespaces that allow the relevant components)
	syntax or keywords to separate the two cases.

I don't believe that either of those notions, or anything else
that has been proposed, has gotten nearly enough traction in the
WG to justify a specification that would apply across the
collection of namespaces.  So we are left with a per-namespace
situation that leaves notions of generic resolvers, even for the
narrow range of cases in which URNs are known to resolve to URLs
(or a selection from a family of URLs) in even more trouble.  

I, at least, would welcome suggestions.  Lamenting the state we
find ourselves in seems less helpful.

Basically I don't think the document meets 2026 criteria for Proposed Standard without resolving these issues, that IESG should not approve it unless/until such issues are resolved, and that we're doing harm to URNs (and thus acting against what I assume all of us care about) if we don't resolve these issues.

But to fix it, I think we "just" have to

(a) define which of the f-, p-, and/or q-components of a URN are required to be persistent along with the base URN
(Even if the answer is "none of the above", I think we still need to say that.   And I think each of these components needs to be considered separately, as the answer might well be different for different components, particularly given the desire to support relative URIs in conjunction with base URNs), and

(b) define some standard and namespace-independent means of indicating how to pass fragment and query to the resource for those cases in which the resource accepts them.  It might be that we just need to reserve some subset of fragment names and query parameter names (say, all names beginning with "~") for fragments or queries to be evaluated in the context of the resource (after removing the "~").    And of course 2141bis needs to be fixed so that it doesn't preclude a general-purpose resolution protocol by permitting each new namespace to have different behavior for f-, p-, and q-components.

An alternative to (b) might be to define a standardized general-purpose resolution protocol, so that there would be a standard way to determine the mapping of urn:foo:bar?x#y onto one or more URLs that mapped x and/or y to the URL when appropriate.   But that solution has the possibly unfortunate side-effect of requiring resolution just in order to find out how to evaluate x in y in the context of a copy of the resource.   In other words, it's not sufficient to have a copy of urn:foo:bar or urn:foo:bar?x already cached in order to find fragment y, you actually have to know what the mapping is too.

Keith
--------------040408020006060309030504-- From nobody Tue Mar 31 15:01:17 2015 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 002561AD0D1 for ; Tue, 31 Mar 2015 15:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 5mVknCARQqbo for ; Tue, 31 Mar 2015 15:01:14 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2E961AD0CA for ; Tue, 31 Mar 2015 15:01:13 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E757B20AA1 for ; Tue, 31 Mar 2015 18:01:09 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 31 Mar 2015 18:01:13 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=sOSX5HAtvtVNJUR NZdXZfGvPwHE=; b=FEqNxQYVHg5GAjeSSdjFr1b7SKHEptmRXVSzpcmXdYBq28i o94rJn3yPdpThpCF1JV8EOXJ401Fr5tp5rsyNOIKglrvEqYwgnOiBVhoX2kHzAP9 zaoGbUzoavADt1Ra3m1oeuer9wF8t0hyrnfhAXJoFV6TGXy75rBbViq3fVus= X-Sasl-enc: OWalXKA7eHc4fNV+wfRgjXVfukL+yOk6LG+TA1WR7JrI 1427839272 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id A5CFDC00013; Tue, 31 Mar 2015 18:01:12 -0400 (EDT) Message-ID: <551B191D.9020209@network-heretics.com> Date: Tue, 31 Mar 2015 18:01:01 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: <55142CA1.2000509@network-heretics.com> <1779999A3ED5866D931302BB@JcK-HP8200.jck.com> In-Reply-To: <1779999A3ED5866D931302BB@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] p-components versus relative URIs 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: Tue, 31 Mar 2015 22:01:16 -0000 On 03/29/2015 09:28 PM, John C Klensin wrote: > Hi. > > As promised, I'm going to try to respond to your detailed review > comments. In order to lower the odds that any of them fall > through the cracks, I'm breaking them up into separate messages > with different subject lines. I can't get to the issue tracker > at present, but trust that we can get the new ones listed there > soon as well. > > --On Thursday, March 26, 2015 11:58 -0400 Keith Moore > wrote: > >> ... >> 1. Use of p-component in URNs combined with use of relative >> URIs with URN as the base URI. >> >> If relative URIs are permitted to be used with URNs, this has >> the potential to harm persistence of URNs unless there are >> constraints on how NSSs are assigned. If an NSS under a >> particular NID has no internal structure, maintaining >> persistence for every URN assigned under that NID is >> relatively simple - just don't ever reassign an NID to a >> different resource. But if the NSS does have structure that >> reflects relationships between resources, and those resources >> can ever be updated in a way that causes those relationships >> to need to change, there's a good chance that some >> combinations of base URNs + relative URIs that formerly >> resolved to valid URNs, will no longer resolve to valid URNs, >> or will resolve to URNs that don't have the same >> meaning/purpose as before. Thus there will be a significant >> temptation to change the meanings of existing URNs, i.e. to >> rebind existing URNs to different resources than before. > I had been concerned about a different aspect of applying > relative references to URNs, but, at least to the extent to > which I understand the above, I share your concern as well. > My instinct at the time of the "URNs are not URIs" draft and for > a while thereafter had been to simply prohibit the use of any > sort of relative resolution with URNs. > > As you presumably noticed, Graham argued strongly that any such > ban would interfere with some things he needed to do with URIs > (even though he didn't expect to use the "urn" scheme). There > was no pushback on the list to the position he recommended that > we take; in the absence of such pushback or feedback, I (and I > assume Peter) concluded that it was appropriate to modify the > documents as he suggested. I sorry that I missed this argument. I'll try to find his messages on the topic. I do acknowledge that we probably want to be able to use URNs to refer to documents that contain relative URIs, and that those documents may have other URIs pointing to those documents for which the relative URIs make sense. I don't think that RFC 2141-style URNs have this issue, at least to this degree, not because they can't point to documents that contain relative URIs, but because they don't have paths, so any relative URI within the document resolves to something meaningless. But I do think that having paths in URNs, and the ability to combine relative URIs with base URNs, creates a number of technical issues that need to be sorted out before we publish a revision to rfc2141 that permits them. I'm not saying that they can't be addressed, only that we need to do so. >> There are lots of ways that a namespace can make relative URIs >> safe to use with its URNs. For example, if none of the >> resources named by a namespace are machine-parseable, there's >> no issue. > I'm not sure I understand why the absence of > machine-parseability helps with this, especially when, as > mentioned in my last note and discussed extensively on-list over > the last year or so, a given URN and namespace can be "resolved" > to either a target object (maybe machine-parseable or not) or > metadata about either the object or the entry in the namespace. I'm assuming, perhaps incorrectly, that the vast majority of use of relative URIs are in documents/resources that are named by their base URIs. So if the resource named by a base URN isn't machine-readable or can't contain relative URIs in the first place, having a p-component in that base URN doesn't seem to me to cause a significant problem. (It might be that I'm wrong about this, and that there are other reasons that problems that can result from this solution. I was just brainstorming to try to find a solution that didn't require p-components to be forbidden in URNs, and this seemed like a potential way out.) > >> Or if the resources under a namespace are >> constrained to never change at all, there's no issue. Or if >> NSSs are of the form x/y such that x is never reused (every >> new resource gets a unique x, and y is just used to >> differentiate between parts or facets of that resource), >> there's no issue. > I think I understand what you are getting at and it makes sense > to me if "parts or facets" can also provide information about > the aspect of the resource being considered or retrieved. In the example above I think I should have also have clarified that the resource named by x/y never gets updated in such a way that some combinations of x and a relative URI change meanings. It's very similar to the persistent fragment question: if urn:foo:bar is persistent, is urn:foo:bar#zot also persistent? Implicit in the design of URNs is the notion that people and software can assume that identifiers beginning with urn: are persistent, which is why there is language in RFC 2141 about whether something is "part of" a URN. (There were extensive discussions about whether a combination of a base URN and a modifier should be be considered persistent - if the modifier were "part of" the URN, then the entire URN would be required to be persistent, but if the modifier were not "part of" the URN, only the base URN would be required to be persistent.) However when considering a URN with p-components, the question is somewhat more subtle, because relative URIs are defined in terms of constructing a new URI from a base URI and a relative URI. So if you have a base URN urn:foo:x/y and relative URIs in the context of such a base URN are interpreted with the same algorithm as that used for base URLs, every reference to one of those relative URIs effectively creates a new URN that doesn't actually have to appear anywhere as a complete identifier. e.g. if the base URN is urn:foo:x/y and there are links in that document to "a", "b", and "c", this effectively creates URNs urn:foo:x/a, urn:foo:x/b, and urn:foo:x/c. > >> The problem is trying to write a general rule that permits use >> of p-components in an NSS and permits use of relative URIs >> with those URNs, in such a way that doesn't break things and >> encourage URNs under that NSS to become non-persistent. > >> Perhaps the easiest way to fix the problem is this: If a >> namespace assigns NSSs containing '/', it is responsible for >> ensuring that NSSs are assigned in such a way that relative >> URI references appearing in machine-readable resources named >> by its URNs are also persistent - and give examples of how >> this might be accomplished. (Of course, any resource can claim >> any URN as its base URI, and namespaces have no control over >> the behavior of resources that they don't name. We can't stop >> the authors of such resources from doing truly stupid things >> with relative URIs, but we can discourage use of relative URIs >> with URNs that weren't designed to be used that way.) > Speaking for myself only, if you, Graham, and Larry (who had > what I think is a slightly different suggestion) can agree on > something that that does not disallow p-components if those make > sense to whomever is defining a namespace, it is almost certain > that I'll be able to live with it. It seems to me that we need > a discussion among the three of you, ideally on-list but at > least in the form of a conclusion, explanation, and suggested > text. Good. I hope we can work this out. Keith From nobody Tue Mar 31 15:03:31 2015 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 3F20D1A00CF; Tue, 31 Mar 2015 15:03:29 -0700 (PDT) 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 mkWfLp9KxY38; Tue, 31 Mar 2015 15:03:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1899E1A00B7; Tue, 31 Mar 2015 15:03:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150331220326.24413.56486.idtracker@ietfa.amsl.com> Date: Tue, 31 Mar 2015 15:03:26 -0700 Archived-At: Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-11.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: Tue, 31 Mar 2015 22:03:29 -0000 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 Names (URNs) Authors : Peter Saint-Andre John C Klensin Filename : draft-ietf-urnbis-rfc2141bis-urn-11.txt Pages : 28 Date : 2015-03-31 Abstract: A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" scheme and a particular URN namespace, typically with the intent that the URN will be a persistent, location-independent resource identifier or abstract designator. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFC 2141 and RFC 3406. 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-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-11 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 nobody Tue Mar 31 15:11:31 2015 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 37FA81AD1FE for ; Tue, 31 Mar 2015 15:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 GJArHmeQ7mfm for ; Tue, 31 Mar 2015 15:11:29 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5CB1A9073 for ; Tue, 31 Mar 2015 15:11:29 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Yd4Nc-0002Wj-QN for urn@ietf.org; Tue, 31 Mar 2015 18:11:28 -0400 Date: Tue, 31 Mar 2015 18:11:23 -0400 From: John C Klensin To: urn@ietf.org 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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] draft-ietf-urnbis-rfc2141bis-urn-11 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: Tue, 31 Mar 2015 22:11:31 -0000 Hi. Consistent with our promise to get a new draft of 2141bis posted today, -11 just went into the posting queue. If we need a new version later in the week or early next week, that is possible. The change log at the end of the document is, I believe, fairly complete about substantive changes. This draft does _not_ include: * A substantive response to Larry's concerns about conflicts with draft-ietf-appsawg-uri-scheme-reg and RFC1737. There are also some procedural concerns with the claim of conflicts with the former that I'm raising (notes not yet completed) on the AppsAWG list (where I hope they can be resolved) and with the IESG. I'll try to post pointers here when they seem particularly important but hope we can keep the more substantive issues in this WG and those concerns separate. * Responses to the many issues raised by Keith that I believe are still open for discussion (and which I've so indicated in my notes over the last week). * Any sort of response to the notes/responses Keith has posted in the last hour or two. I haven't read those yet, much less had a chance to respond to them or, if there are issues we seem to be converging on enough to change the document(s), discuss them with Peter. john From nobody Tue Mar 31 15:19:19 2015 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 829DB1ACF03 for ; Tue, 31 Mar 2015 15:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no 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 tIbKC9zZDe45 for ; Tue, 31 Mar 2015 15:19:12 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14A001A92EA for ; Tue, 31 Mar 2015 15:19:12 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 445C220AF0 for ; Tue, 31 Mar 2015 18:19:08 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 31 Mar 2015 18:19:11 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=kZECLelbOEiKckYdkA3I/st81JE=; b=HYRUJ vLfe3PMjHb9k4gL2VyhbYUQGZbMtSBX9GgYBwFP7HS4XD+oSH3unmMoentFY2lnp YxN3H/SMuwAmU0weaHUdVHnSb6XrskJrjL00hHOkI4SgRSAx9bgA5vg9pcuIFVJu obsN+ngJ9qf9jui4hI0tLR0HS19z7SY+7E2wg0= X-Sasl-enc: lFxIBT2xpf+bgTJGsyA5JOxw2nST8caGmty6Y0m/2yE1 1427840351 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id CC5CDC0001C; Tue, 31 Mar 2015 18:19:10 -0400 (EDT) Message-ID: <551B1D53.6020206@network-heretics.com> Date: Tue, 31 Mar 2015 18:18:59 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: <55142CA1.2000509@network-heretics.com> <20AE30F476B62E93E436DF1B@JcK-HP8200.jck.com> In-Reply-To: <20AE30F476B62E93E436DF1B@JcK-HP8200.jck.com> Content-Type: multipart/alternative; boundary="------------020604030303060600070809" Archived-At: Subject: Re: [urn] 3986 relationships 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: Tue, 31 Mar 2015 22:19:17 -0000 This is a multi-part message in MIME format. --------------020604030303060600070809 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Regarding 3986 in general, I recognize that there's a conundrum here. As I understand things, the AD explicitly imposed 3986 syntax on this group. So I undertand that the group has a hard time recommending a different approach. Also, much of the group has long believed that 3986 is adequate, and maybe there's already some use of that syntax in deployed URNs, so there's a lot of inertia behind that syntax. So, regardless of what I personally believe, I'm not really trying to persuade you or the group that 3986 should be abandoned. I do, however, think that, having decided to use that syntax (or having had that syntax imposed on it), the group has to solve the problems that result from that decision before it can expect its document to be approved as a proposed standard. I continue to believe that the decision to use that syntax will result in a tremendous amount of harm and confusion, because it's using a syntax that people are accustomed to using with http and other URLs, but in very different ways - and perhaps even in ways that vary arbitrarily as far as users are concerned. But at least for the time being, that's irrelevant unless/until either IESG rejects the document (perhaps realizing that the result just creates too many problems) or an AD or IESG action gets overturned on appeal. So basically I think the immediate task before us is to clean up the messes created by RFC 3986 and the decision to allow {f,p,q}-components in URNs. On 03/29/2015 09:46 PM, John C Klensin wrote: > Note that this issue is, I believe, somewhat redundant with one > discussed in an earlier note. I've tried to refer to it when > appropriate; please forgive remaining redundancy. Yes, there is overlap, because these various AD and WG decisions interact and have cumulative effects. It's difficult to talk about these effects one at a time without introducing some redundancy, though splitting up the topics is probably still a good way to have the discussion. > > --On Thursday, March 26, 2015 11:58 -0400 Keith Moore > wrote: > >> ... >> 4. Constraining URNs to RFC 3986 conventions is problematic. >> One reason is that when using URNs to refer to >> network-accessible resources there is a need for more >> functions than those analogous to: references to internal >> structure (presumably f-component), references to external >> structure (presumably p-component), and access to the resource >> as a service (presumably q-component). > Those presumptions are not clear to me and may not be shared. > See my earlier discussion about interactions with a presumed URN > resolver versus pass-through to URL results and then try to > generalize it to URNs with different kinds of resolution > mechanisms and targets/results (if you have any trouble at all > picturing that for the general case, we are in the same boat and > that is why I didn't expand on that example). A small number of examples illustrate why it is problematic. 1. A URN from a namespace which uses f-components is associated with, and/or resolves to, either an HTML document or a service that produces an HTML document when it is accessed. That HTML document contains relative URIs that refer to fragments internal to, and identified within, that HTML document. * With the f-component used for some other purpose, there is no way to externally refer to those fragments. * Also, any relative URI references within that document will cause the document reader to construct identifiers that look like URNs contining the base URN + the fragment identifier, and those identifiers will likely leak in various ways (in the user interface, browser history, etc.) that at the very least cause user confusion about how URNs are used. (note that there's no assumption here that there's any intermediate URL that also refers to the document, though there might be.) 2. A URN from a namespace which uses p-components is associated with, and/or resolves to, either an HTML document or a service that produces an HTML document when it is accessed. That HTML document contains one or more relative URIs that contain "paths" that will, in the context of that HTML document, be evaluated relative to the URN used to access or obtain that document. Again, those relative URI references will leak in various ways that will likely cause confusion. 3. A URN from a namespace which uses q-components is associated with, and/or resolves to, either an HTML document or a service that produces an HTML document when it is accessed. That HTML document contains either one or more relative URIs that contain "queries" and/or one or more HTML forms which use the GET method. In order to submit the form, the client reading the HTML document will construct a URI from the base URN and the form parameters using RFC 3986 "query" syntax. 4. A URN is used to identify a service which is accessed using HTTP[S]. That service accepts query parameters using RFC3986 syntax. With the current 2141bis language, there is no way that a client, user, or document author can reliably construct a URI which is a composition of the URN used to identify the service and the query parameters. If that client, user, or document author happens to know how that particular namespace's resolver works, that person might be able to construct such a URI - but those assumptions fail with generic resolvers. 5. A URI or other string is constructed by adding one or more f-, p-, or q- components to a base URN, following RFC 3986 syntax. It's not clear from 2141bis -10 whether the resulting string is persistent or not, and this might vary on a per-namespace basis. 6. Users who are familiar with HTTP and other URLs will see '#', '/', and '?' in URNs and think they know what these mean, think they know how to manipulate them. (There's been a tremendous amount of misunderstanding about URNs, even within IETF, which has hampered the actual utility of URNs even by those who understand them.) (This is not an exhaustive list. Also, I used HTML documents in these examples because they're very familiar, but I doubt that HTML documents are the only documents that use 3986-style relative references.) > >> In particular there >> seems to be a strong desire to be able to construct URIs >> containing URNs to query a resolution service that is >> implicitly determined by the URN itself - i.e. without having >> to embed the location of that service in the URI. > If I understand what you are saying, isn't that exactly what > DDDS-connected NIDs and namespaces do? I must have left out some text here. I think I was trying to say that people in this WG seem to want to be able to compose base URNs and modifiers beginning with '/', '#', and/or '?' but without any kind of consistent meaning for those modifiers across resolution servers, and without even specifying which resolution server to use. (Perhaps there was an implicit assumption that there would never be a need for general-purpose resolution services independent of any particular namespace, and I emphatically don't believe that. I think that URNs need to be usable in queries to general-purpose resolution services even after a particular namespace has ceased to operate its own resolvers, so that it will be possible for libraries or other concerns to maintain databases about those URNs and the resources that they refer to, and for clients to potentially query those databases using those URNs without any particular database having to provide complete coverage for any particular URN namespace.) > >> Or to more >> simply state an example of the problem: given a URN that >> refers to a network-accessible resource, how to distinguish >> between queries sent to the resolver and queries sent to the >> resource itself? > Modulo some possible issues with what you mean by "sent", see my > earlier note with Subject starting "Fragments and URN > pass-through components". It doesn't contain a solution, but > does identify what I think is the same problem. On the other > hand, as it points out,/*I've actually tried to start that > discussion several times before and the WG has effectively > rejected all solutions other than per-namespace rules.*/ This makes me wonder whether some WG participants don't understand the IETF process. A WG generally gets a lot of latitude in deciding how a problem is to be addressed, but identified problems generally do have to be addressed. The insistence on 3986 syntax and use of f-, p-, and q- components introduces several problems that weren't present with 2141 syntax. The original URN WG elected to avoid those problems in the near term by reserving '#', '?' and '/', for future use. If URNBIS wants to define what those things mean, it's free to do so, but it has to address the resulting problems - and simply saying "each namespace can do as it likes" is not a solution because it effectively precludes namespace-independent use of URNs. It's almost as if many WG participants assume that URNs will never be used in any namespace-independent context - and if that's the case, why bother with the urn: prefix at all? Almost the only purpose of the urn: prefix is to enable some generalized handling of URNs across different namespaces. (Yes, it's also an indication that the following identifier is persistent, but that's also being diluted by use of 3986 syntax, as in example #5 above.) > >> Another reason that RFC 3986 syntax convention is problematic >> is that it creates a conflict between (a) the use of >> q-components used to send a query or request another service >> of a network-accessible resource, and (b) the use of >> q-components for other purposes for non-accessible resources. > I don't think that conflict is created by 3986 although I do > believe there is a problem that should be resolved more clearly > than we have done it. As far as 3986 is concerned, I think > its involvement in the issue ended with the "syntax only; no > semantics" decision. While I think something along the lines of "syntax only" is about as good a compromise as the WG can reach given the imposed mandate to use RFC 3986, there are too many ambiguities in the current spec. Whether we like it or not, those characters '#', '/', and '?' have meaning, partially from the decision to permit relative URIs to be used with URNs, partially from public mindshare. People want to use them with URNs because they do have meaning, even if they want to use them in ways that are at least somewhat inconsistent with their current meanings as applied to URLs. So while we might claim that this is a "syntax only" decision, we all know better. That's just a bit of political whitewashing. > >> It might be possible to work around the problem while still >> sticking to RFC 3986 syntax, perhaps by reserving some part of >> q-component keyword space for use by resolvers. But that >> would ideally be done without interfering with use of keywords >> used by existing HTTP-based services, since we'd like to be >> able to use URNs to provide stable names for such services. > Yes. Suggested months and months ago. Got no traction. Happy > to hear new suggestions or someone taking up the previous ideas. > >> I started out thinking that this was only a poor technical >> choice, though perhaps a defensible one - but on reflection I >> think it borders on being a technical omission. And I >> realize we have AD direction to use RFC 3986, but that doesn't >> do anything to address the technical problems that this causes. > As I said, I think there is a problem in this area, but I don't > think 3986 is much of it unless the "syntax only" decision is > either ignored or repealed. As I see it, use of 3986 syntax with URNs carries with it several kinds of baggage, as illustrated by the above examples. I can hardly expect the WG to countermand direct AD direction to use 3986 syntax. But I'm not sure that the supporters of this approach really understand how much of a rat's nest this creates. And while I think there are probably workarounds for around all of these problems, the net result is probably going to be really ugly and confusing. Still, the task before us is to try to make it as non-ugly and non-confusing as we can make it. (sort of like putting makeup on a pig) Keith --------------020604030303060600070809 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Regarding 3986 in general, I recognize that there's a conundrum here.   As I understand things, the AD explicitly imposed 3986 syntax on this group.   So I undertand that the group has a hard time recommending a different approach.   Also, much of the group has long believed that 3986 is adequate, and maybe there's already some use of that syntax in deployed URNs, so there's a lot of inertia behind that syntax.  

So, regardless of what I personally believe, I'm not really trying to persuade you or the group that 3986 should be abandoned.    I do, however, think that, having decided to use that syntax (or having had that syntax imposed on it), the group has to solve the problems that result from that decision before it can expect its document to be approved as a proposed standard.

I continue to believe that the decision to use that syntax will result in a tremendous amount of harm and confusion, because it's using a syntax that people are accustomed to using with http and other URLs, but in very different ways - and perhaps even in ways that vary arbitrarily as far as users are concerned.   But at least for the time being, that's irrelevant unless/until either IESG rejects the document (perhaps realizing that the result just creates too many problems) or an AD or IESG action gets overturned on appeal.  

So basically I think the immediate task before us is to clean up the messes created by RFC 3986 and the decision to allow {f,p,q}-components in URNs.

On 03/29/2015 09:46 PM, John C Klensin wrote:
Note that this issue is, I believe, somewhat redundant with one
discussed in an earlier note.  I've tried to refer to it when
appropriate; please forgive remaining redundancy.

Yes, there is overlap, because these various AD and WG decisions interact and have cumulative effects.  It's difficult to talk about these effects one at a time without introducing some redundancy, though splitting up the topics is probably still a good way to have the discussion.


--On Thursday, March 26, 2015 11:58 -0400 Keith Moore
<moore@network-heretics.com> wrote:


... 
4.  Constraining URNs to RFC 3986 conventions is problematic.
One reason is that when using URNs to refer to
network-accessible resources there is a need for more
functions than those analogous to: references to internal
structure (presumably f-component), references to external
structure (presumably p-component), and access to the resource
as a service (presumably q-component).

Those presumptions are not clear to me and may not be shared.
See my earlier discussion about interactions with a presumed URN
resolver versus pass-through to URL results and then try to
generalize it to URNs with different kinds of resolution
mechanisms and targets/results (if you have any trouble at all
picturing that for the general case, we are in the same boat and
that is why I didn't expand on that example).

A small number of examples illustrate why it is problematic.  

1. A URN from a namespace which uses f-components is associated with, and/or resolves to, either an HTML document or a service that produces an HTML document when it is accessed.   That HTML document contains relative URIs that refer to fragments internal to, and identified within, that HTML document. 
  • With the f-component used for some other purpose, there is no way to externally refer to those fragments.  
  • Also, any relative URI references within that document will cause the document reader to construct identifiers that look like URNs contining the base URN + the fragment identifier, and those identifiers will likely leak in various ways (in the user interface, browser history, etc.) that at the very least cause user confusion about how URNs are used.

(note that there's no assumption here that there's any intermediate URL that also refers to the document, though there might be.)

2. A URN from a namespace which uses p-components is associated with, and/or resolves to, either an HTML document or a service that produces an HTML document when it is accessed.   That HTML document contains one or more relative URIs that contain "paths" that will, in the context of that HTML document, be evaluated relative to the URN used to access or obtain that document.   Again, those relative URI references will leak in various ways that will likely cause confusion.

3. A URN from a namespace which uses q-components is associated with, and/or resolves to, either an HTML document or a service that produces an HTML document when it is accessed.   That HTML document contains either one or more relative URIs that contain "queries" and/or one or more HTML forms which use the GET method.   In order to submit the form, the client reading the HTML document will construct a URI from the base URN and the form parameters using RFC 3986 "query" syntax.

4. A URN is used to identify a service which is accessed using HTTP[S].   That service accepts query parameters using RFC3986 syntax.    With the current 2141bis language, there is no way that a client, user, or document author can reliably construct a URI which is a composition of the URN used to identify the service and the query parameters.   If that client, user, or document author happens to know how that particular namespace's resolver works, that person might be able to construct such a URI - but those assumptions fail with generic resolvers.

5. A URI or other string is constructed by adding one or more f-, p-, or q- components to a base URN, following RFC 3986 syntax.   It's not clear from 2141bis -10 whether the resulting string is persistent or not, and this might vary on a per-namespace basis.

6. Users who are familiar with HTTP and other URLs will see '#', '/', and '?' in URNs and think they know what these mean, think they know how to manipulate them.   (There's been a tremendous amount of misunderstanding about URNs, even within IETF, which has hampered the actual utility of URNs even by those who understand them.)

(This is not an exhaustive list.   Also, I used HTML documents in these examples because they're very familiar, but I doubt that HTML documents are the only documents that use 3986-style relative references.)



  In particular there
seems to be a strong desire to be able to construct URIs
containing URNs to query a resolution service that is
implicitly determined by the URN itself - i.e. without having
to embed the location of that service in the URI.

If I understand what you are saying, isn't that exactly what
DDDS-connected NIDs and namespaces do?

I must have left out some text here.  I think I was trying to say that people in this WG seem to want to be able to compose base URNs and modifiers beginning with '/', '#', and/or '?' but without any kind of consistent meaning for those modifiers across resolution servers, and without even specifying which resolution server to use.

(Perhaps there was an implicit assumption that there would never be a need for general-purpose resolution services independent of any particular namespace, and I emphatically don't believe that.   I think that URNs need to be usable in queries to general-purpose resolution services even after a particular namespace has ceased to operate its own resolvers, so that it will be possible for libraries or other concerns to maintain databases about those URNs and the resources that they refer to, and for clients to potentially query those databases using those URNs without any particular database having to provide complete coverage for any particular URN namespace.)



  Or to more
simply state an example of the problem: given a URN that
refers to a network-accessible resource, how to distinguish
between queries sent to the resolver and queries sent to the
resource itself?

Modulo some possible issues with what you mean by "sent", see my
earlier note with Subject starting "Fragments and URN
pass-through components".  It doesn't contain a solution, but
does identify what I think is the same problem.   On the other
hand, as it points out, I've actually tried to start that
discussion several times before and the WG has effectively
rejected all solutions other than per-namespace rules.

This makes me wonder whether some WG participants don't understand the IETF process.   A WG generally gets a lot of latitude in deciding how a problem is to be addressed, but identified problems generally do have to be addressed.   The insistence on 3986 syntax and use of f-, p-, and q- components introduces several problems that weren't present with 2141 syntax.   The original URN WG elected to avoid those problems in the near term by reserving '#', '?' and '/', for future use.   If URNBIS wants to define what those things mean, it's free to do so, but it has to address the resulting problems - and simply saying "each namespace can do as it likes" is not a solution because it effectively precludes namespace-independent use of URNs.  

It's almost as if many WG participants assume that URNs will never be used in any namespace-independent context - and if that's the case, why bother with the urn: prefix at all?   Almost the only purpose of the urn: prefix is to enable some generalized handling of URNs across different namespaces.   (Yes, it's also an indication that the following identifier is persistent, but that's also being diluted by use of 3986 syntax, as in example #5 above.)



Another reason that RFC 3986 syntax convention is problematic
is that it creates a conflict between (a) the use of
q-components used to send a query or request another service
of a network-accessible resource, and (b) the use of
q-components for other purposes for non-accessible resources.

I don't think that conflict is created by 3986 although I do
believe there is a problem that should be resolved more clearly
than we have done it.    As far as 3986 is concerned, I think
its involvement in the issue ended with the "syntax only; no
semantics" decision.

While I think something along the lines of "syntax only" is about as good a compromise as the WG can reach given the imposed mandate to use RFC 3986, there are too many ambiguities in the current spec.   Whether we like it or not, those characters '#', '/', and '?' have meaning, partially from the decision to permit relative URIs to be used with URNs, partially from public mindshare.    People want to use them with URNs because they do have meaning, even if they want to use them in ways that are at least somewhat inconsistent with their current meanings as applied to URLs.   So while we might claim that this is a "syntax only" decision, we all know better.  That's just a bit of political whitewashing.



It might be possible to work around the problem while still
sticking to RFC 3986 syntax, perhaps by reserving some part of
q-component keyword space for use by resolvers.   But that
would ideally be done without interfering with use of keywords
used by existing HTTP-based services, since we'd like to be
able to use URNs to provide stable names for such services.

Yes.  Suggested months and months ago.  Got no traction.  Happy
to hear new suggestions or someone taking up the previous ideas. 


I started out thinking that this was only a poor technical
choice, though perhaps a defensible one - but on reflection I
think it borders on being a technical omission.   And I
realize we have AD direction to use RFC 3986, but that doesn't
do anything to address the technical problems that this causes.

As I said, I think there is a problem in this area, but I don't
think 3986 is much of it unless the "syntax only" decision is
either ignored or repealed.

As I see it, use of 3986 syntax with URNs carries with it several kinds of baggage, as illustrated by the above examples.

I can hardly expect the WG to countermand direct AD direction to use 3986 syntax.   But I'm not sure that the supporters of this approach really understand how much of a rat's nest this creates.   And while I think there are probably workarounds for around all of these problems, the net result is probably going to be really ugly and confusing.

Still, the task before us is to try to make it as non-ugly and non-confusing as we can make it.
(sort of like putting makeup on a pig)

Keith

--------------020604030303060600070809--