From nobody Tue May 3 10:18:24 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF7012D585 for ; Tue, 3 May 2016 10:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 D9OzM2TswFI8 for ; Tue, 3 May 2016 10:18:20 -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 0AF8E12DCC7 for ; Tue, 3 May 2016 10:15:17 -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 u43HExUC003562 for ; Tue, 3 May 2016 18:15:04 +0100 (BST) 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 u43HEwrt024010 for ; Tue, 3 May 2016 18:14:58 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id u43HEwjN013319 for ; Tue, 3 May 2016 18:14:58 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id u43HEwsj013318; Tue, 3 May 2016 18:14:58 +0100 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: Tue, 03 May 2016 18:14:58 +0100 Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (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: Subject: [urn] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 17:18:23 -0000 Section 2 BNF This has probably been done to death, so wrt the "0*30(ldh)" in the NID production I merely register my general dismay at the inclusion of _any_ arbitrary numerical field widths in grammars such as this Section 2.3.1, para 1 (requested) service "The q-component is intended for passing parameters to either the named resource or a system that can supply the requested service, for interpretation by that resource or system." This is the first use of the word 'service' since section 1.1, which reads to me as only defining _resolution_ services, which are explicitly ruled out in this case by the immediately following parenthesis. Aside from the case of "services associated with the namespace" which occurs in 6.4.1 item 5, all other uses of the word 'service' in the spec either clearly (and usually explicitly) refer to resolution services, or are about non-URN-related services altogether. In contexts I'm familiar with, the 'Resource' in 'URI' covers anything and everything that might be identifiable, from the easy (what TimBL calls "information resources") to the ineffable (the weather in Oaxaca), the imaginery (unicorns) and the abstract (democracy), and certainly including services. So I'm unsure what the distinction is that you're trying to get at here. Particularly as in practice any actual response to the use of a URN comes from some system, so making a distinction between passing a parameter to a resource vs. to a service seems to me a distinction without a difference. The following, from 2.3.2: "(By contrast, passing parameters to the resources identified by a URN, or to applications that manage such resources, is handled by q-components as described in the previous section.)" is by contrast exactly what I would expect to see. Section 3.1 [also signalled earlier at 2.3.1 para 5] "For various purposes such as caching, it is often desirable to determine if two URNs are 'the same'." ... "If a q-component, r-component, or f-component (or any combination thereof) are included in a URN, they MUST be ignored for purposes of determining equivalence." These two seem in contradiction to one another, at least insofar as q- and probably r-components are concerned. Surely for caching purposes distinct q-components must mean inequality? Otherwise asking for my booking to Amsterdam might get me your booking for New York, if I made the request via a URN for a flight-booking service including surname and booking ID via q-parameters, sent to a service that does the q-conversion and URL-fetching itself. . . But I realise there's been a _very_ long discussion history about this issue, and thus it not be one you want to re-open. At the very least, however, I think you need to call out the downside wrt caching, in some kind of "your gun, your foot, your bullet" note. Section 4 [No issues, this is a good compromise wrt previous disputes, 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 Tue May 3 12:36:55 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E326612D5D6 for ; Tue, 3 May 2016 12:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 57JrosSO5Nqh for ; Tue, 3 May 2016 12:36:52 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 2629712D156 for ; Tue, 3 May 2016 12:36:52 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F136850A73 for ; Tue, 3 May 2016 15:36:50 -0400 (EDT) To: urn@ietf.org References: From: Sean Leonard Message-ID: <3e02d08d-9f0d-56af-5240-caecd7d01419@seantek.com> Date: Tue, 3 May 2016 12:36:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [urn] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 19:36:54 -0000 Hello, On 5/3/2016 10:14 AM, Henry S. Thompson wrote: > Section 2 BNF > > This has probably been done to death, so wrt the "0*30(ldh)" in the N= ID > production I merely register my general dismay at the inclusion of > _any_ arbitrary numerical field widths in grammars such as this I disagree with this on the premise stated, so -1. If there is a limit=20 on a field width, it should be expressed in the grammar however=20 possible. If the grammar is normative (and I ascribe to the view that=20 ABNF is fully normative), the grammar and the prose ought to be in exact = alignment. However, I agree with the premise that field widths should not be limited= =2E The limit of 30 characters for NID does not have much justification. If=20 someone wants to register=20 someextremelylongNIDbecausetheyfeellikeitandsoforth, who cares? It's not = a resource exhaustion issue. (Note: the limit of 32 characters is in RFC 2141. If that is the=20 justification--compatibility with prior spec--then I accept it, but that = should be mentioned in the text IMO.) > > Section 2.3.1, para 1 > > (requested) service > > "The q-component is intended for passing parameters to either the > named resource or a system that can supply the requested service, fo= r > interpretation by that resource or system." > > This is the first use of the word 'service' since section 1.1, which > reads to me as only defining _resolution_ services, which are > explicitly ruled out in this case by the immediately following > parenthesis. > > Aside from the case of "services associated with the namespace" which= > occurs in 6.4.1 item 5, all other uses of the word 'service' in the > spec either clearly (and usually explicitly) refer to resolution > services, or are about non-URN-related services altogether. > > In contexts I'm familiar with, the 'Resource' in 'URI' covers anythin= g > and everything that might be identifiable, from the easy (what TimBL > calls "information resources") to the ineffable (the weather in > Oaxaca), the imaginery (unicorns) and the abstract (democracy), and > certainly including services. So I'm unsure what the distinction is > that you're trying to get at here. Particularly as in practice any > actual response to the use of a URN comes from some system, so making= a > distinction between passing a parameter to a resource vs. to a servic= e > seems to me a distinction without a difference. > > The following, from 2.3.2: > > "(By contrast, passing parameters to the resources > identified by a URN, or to applications that manage such resources,= > is handled by q-components as described in the previous section.)" > > is by contrast exactly what I would expect to see. +1. The draft needs to take a strong stand on the definitions of=20 "service" and "resource" per Henry's comments above. I believe that=20 "resource" should mean exactly what RFC 3986 says, to avoid confusion=20 with that spec. However, this is in contrast to prior voices in this WG=20 that have tried to change what "resource" means in the URN context. I=20 would appreciate those voices speaking up, because this WG has been=20 dragging on with fewer and fewer participants, and Henry's feedback=20 shows exactly what happens when "resource" is not the same between IETF=20 documents. In particular: a URI without a fragment identifies some primary resource = (which RFC 3986 says is anything that can be identified by URI, so it's=20 pretty reflexive); with a fragment, it identifies some secondary=20 resource that is part of the primary resource, and is reachable with=20 knowledge of the media type of the primary resource(s). The actual=20 representation that is returned during the dereferencing operation, can=20 vary based on ambient conditions (network topology, servers online,=20 redirects, blah blah blah). Other things (such as web server, URN=20 resolvers, proxies, DNS servers, Tor, IP addresses, warp holes, blah=20 blah blah) are resources in the generic sense of the term, but *not*=20 resources in the way that RFC 3986 refers to resources. > > Section 3.1 [also signalled earlier at 2.3.1 para 5] > > "For various purposes such as caching, it is often desirable to > determine if two URNs are 'the same'." > > ... > > "If a q-component, r-component, or f-component (or any combination > thereof) are included in a URN, they MUST be ignored for purposes o= f > determining equivalence." > > These two seem in contradiction to one another, at least insofar as q- > and probably r-components are concerned. Surely for caching purposes > distinct q-components must mean inequality? +1, I agree. > Otherwise asking for my > booking to Amsterdam might get me your booking for New York, if I made > the request via a URN for a flight-booking service including surname an= d > booking ID via q-parameters, sent to a service that does the > q-conversion and URL-fetching itself. . . > =20 > But I realise there's been a _very_ long discussion history about this > issue, and thus it not be one you want to re-open. At the very least, > however, I think you need to call out the downside wrt caching, in > some kind of "your gun, your foot, your bullet" note. +1, I agree. That part "MUST be ignored for purposes of determining=20 equivalence", need to be something like: "MUST be ignored for purposes of determining name equivalence" or some=20 other magical term. The point is that urn:nid1:obj2 and=20 urn:nid1:OBJ2?foo#baz identify the same Uniform Named Thing (if nid1=20 namespace says case-insensitive), but they may well not return the same=20 representations when URI-dereferenced. "Equivalence" in URIs also=20 depends on what you mean by equivalence, i.e., how deep you are looking. = There are multiple kinds of equivalence. Sean > > Section 4 > > [No issues, this is a good compromise wrt previous disputes, IMO] > > ht From nobody Tue May 3 12:46:54 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0B112D7BC for ; Tue, 3 May 2016 12:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 uYNj8ZdmSodT for ; Tue, 3 May 2016 12:46:51 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 C8CC112D680 for ; Tue, 3 May 2016 12:46:50 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BE31D50A86 for ; Tue, 3 May 2016 15:46:49 -0400 (EDT) To: urn@ietf.org References: <3e02d08d-9f0d-56af-5240-caecd7d01419@seantek.com> From: Sean Leonard Message-ID: <0090920a-849b-09dc-b606-daa9dbd87446@seantek.com> Date: Tue, 3 May 2016 12:46:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <3e02d08d-9f0d-56af-5240-caecd7d01419@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [urn] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 19:46:52 -0000 On 5/3/2016 12:36 PM, Sean Leonard wrote: > >> Otherwise asking for my >> booking to Amsterdam might get me your booking for New York, if I made= >> the request via a URN for a flight-booking service including surname a= nd >> booking ID via q-parameters, sent to a service that does the >> q-conversion and URL-fetching itself. . . >> But I realise there's been a _very_ long discussion history about th= is >> issue, and thus it not be one you want to re-open. At the very least,= >> however, I think you need to call out the downside wrt caching, in >> some kind of "your gun, your foot, your bullet" note. > > +1, I agree. That part "MUST be ignored for purposes of determining=20 > equivalence", need to be something like: > "MUST be ignored for purposes of determining name equivalence" or some = > other magical term. The point is that urn:nid1:obj2 and=20 > urn:nid1:OBJ2?foo#baz identify the same Uniform Named Thing (if nid1=20 > namespace says case-insensitive), but they may well not return the=20 > same representations when URI-dereferenced. "Equivalence" in URIs also = > depends on what you mean by equivalence, i.e., how deep you are=20 > looking. There are multiple kinds of equivalence. Let me provide specific text. The term I shall use is "name the same thin= g". 3. Equivalence: URNs That Name the Same Thing 3.1. Procedure It is often desirable to determine if two URNs are "the same". The generic URI specification [RFC3986] is very flexible about equality comparisons, putting the focus on allowing false negatives and avoiding false positives. If comparisons are made in a scheme- independent way, i.e., as URI comparisons only, URNs that this section considers equal would be rejected. The discussion below applies when the URIs involved are known to be URNs. This "Name the Same Thing" procedure is a form of scheme-based normalization (Section 6.2.3 of [RFC3986]). Two URNs Name the Same Thing if their portions are octet- by-octet equal after applying case normalization (as specified in Section 6.2.2.1 of [RFC3986]) to the following constructs: 1. the URI scheme "urn", by conversion to lower case 2. the NID, by conversion to lower case [[ 3. any percent-encoded characters in the NSS (that is, all character= triplets that match the production found in Section 2.1 of the base URI specification [RFC3986]), by conversion to upper case for the digits A-F. Percent-encoded characters MUST NOT be decoded, i.e., percent- encoding normalization (as specified in Section 6.2.2.2 of [RFC3986])= MUST NOT be applied as part of the comparison process. ]] If a q-component, r-component, or f-component (or any combination thereof) are included in a URN, they MUST be ignored for purposes of determining whether to URNs Name the Same Thing. URN namespace definitions MAY include additional rules for equivalence, such as case-insensitivity of the NSS (or parts thereof). Such rules MUST always have the effect of eliminating some= of the false negatives obtained by the procedure above and MUST NOT result in treating two URNs as not equivalent if the procedure here says they are equivalent. For related considerations with regard to NID registration, see below. ** I disagree with the text in between [[ ]], because I believe that NSS is = in UTF-8; therefore, ill-formed UTF-8 sequences such as %FF cannot Name=20 the Same Thing, even if both urn: URIs have them. That issue, however,=20 is a different topic. Sean From nobody Tue May 3 15:06:10 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AA112D656 for ; Tue, 3 May 2016 15:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 2BHbDxn8d2EW for ; Tue, 3 May 2016 15:06:07 -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 1CCD912D18C for ; Tue, 3 May 2016 15:06:07 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1axiSD-000M9F-Hm; Tue, 03 May 2016 18:06:05 -0400 Date: Tue, 03 May 2016 18:06:00 -0400 From: John C Klensin To: Sean Leonard , urn@ietf.org Message-ID: <790A858BDF9234D27BA953CC@JcK-HP8200.jck.com> In-Reply-To: <3e02d08d-9f0d-56af-5240-caecd7d01419@seantek.com> References: <3e02d08d-9f0d-56af-5240-caecd7d01419@seantek.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.10 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] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 22:06:09 -0000 --On Tuesday, May 03, 2016 12:36 -0700 Sean Leonard wrote: >... > The limit of 30 characters for NID does not have much > justification. If someone wants to register > someextremelylongNIDbecausetheyfeellikeitandsoforth, who > cares? It's not a resource exhaustion issue. Actually, one of the things I learned when I was working with human factors psychologists in a prior life is that there is a reason, having to do with the ability of humans to distinguish between things (like strings) based on quick inspection. As an example, look quickly at someextremely1ongNIDbecausetheyfee11ikeitandsoforth and, pretending this isn't a test to which I've alerted you, tell me if the two supposed identifiers are the same. A truly random string or a hash, which might also have been used in your example, would be worse/harder because there would be no expectation of a concatenated set of words. Easy for computers but, insofar as we expect to rely on humans, bad for them. The Stevens limit seems or apply to reliable human recognition as well as short-term memory. > (Note: the limit of 32 characters is in RFC 2141. If that is > the justification--compatibility with prior spec--then I > accept it, but that should be mentioned in the text IMO.) Right now, 2141bis lists substantive differences from 2141. Are you also suggesting that it list everything that has not changed? Or, if there is a dividing line for those things that are unchanged from 2141 that should be called out, how would you define it? >... > +1. The draft needs to take a strong stand on the definitions > of "service" and "resource" per Henry's comments above. I > believe that "resource" should mean exactly what RFC 3986 > says, to avoid confusion with that spec. However, this is in > contrast to prior voices in this WG that have tried to change > what "resource" means in the URN context. I would appreciate > those voices speaking up, because this WG has been dragging on > with fewer and fewer participants, and Henry's feedback shows > exactly what happens when "resource" is not the same between > IETF documents. See my response to Henry but also note that what 3986 appears to say (and how he interprets it if I correctly understood his note) is that "resource" can refer to very nearly anything. Meaning exactly what 3986 says would require that 3986 be a great deal more specific than the entirely circular definition of 3986 which reads "This specification does not limit the scope of what might be a resource; rather, the term "resource" is used in a general sense for whatever might be identified by a URI." followed by some examples and general comments. > In particular: a URI without a fragment identifies some > primary resource (which RFC 3986 says is anything that can be > identified by URI, so it's pretty reflexive); with a fragment, > it identifies some secondary resource that is part of the > primary resource, and is reachable with knowledge of the media > type of the primary resource(s). The actual representation > that is returned during the dereferencing operation, can vary > based on ambient conditions (network topology, servers online, > redirects, blah blah blah). Other things (such as web server, > URN resolvers, proxies, DNS servers, Tor, IP addresses, warp > holes, blah blah blah) are resources in the generic sense of > the term, but *not* resources in the way that RFC 3986 refers > to resources. And the status of an abstract designator is still unclear. >... >> But I realise there's been a _very_ long discussion history >> about this issue, and thus it not be one you want to re-open. >> At the very least, however, I think you need to call out the >> downside wrt caching, in some kind of "your gun, your foot, >> your bullet" note. > > +1, I agree. That part "MUST be ignored for purposes of > determining equivalence", need to be something like: > "MUST be ignored for purposes of determining name equivalence" > or some other magical term. The point is that urn:nid1:obj2 > and urn:nid1:OBJ2?foo#baz identify the same Uniform Named > Thing (if nid1 namespace says case-insensitive), but they may > well not return the same representations when > URI-dereferenced. "Equivalence" in URIs also depends on what > you mean by equivalence, i.e., how deep you are looking. There > are multiple kinds of equivalence. Need advice from the WG Chairs on whether or not this topic should be reopened. I have no strong preference about what the spec should say other than that we not go around in circles about it for more months. best, john From nobody Tue May 3 15:07:17 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C83612D8A7 for ; Tue, 3 May 2016 15:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 jGdB0x8hnfT4 for ; Tue, 3 May 2016 15:07:15 -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 0E96812D524 for ; Tue, 3 May 2016 15:07:15 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1axiTJ-000M9O-Js; Tue, 03 May 2016 18:07:13 -0400 Date: Tue, 03 May 2016 18:07:08 -0400 From: John C Klensin To: "Henry S. Thompson" , urn@ietf.org Message-ID: <383E74C93A059E95C9B5A4E7@JcK-HP8200.jck.com> In-Reply-To: References: 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.10 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] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 22:07:16 -0000 --On Tuesday, May 03, 2016 18:14 +0100 "Henry S. Thompson" wrote: > Section 2 BNF > > This has probably been done to death, so wrt the "0*30(ldh)" > in the NID production I merely register my general dismay at > the inclusion of _any_ arbitrary numerical field widths in > grammars such as this That is not a "field width" in the usual sense. It is the name of the namespace. Names get placed in tables, etc., and having a nominal upper limit on their length helps a lot. FWIW, in my many years of (admittedly strange) experience, the only time I've seen human beings voluntarily select a 32 character identifier/name, much less a longer one, has been when they are trying to prove a point or be deliberately obscure. I don't see a need to support either of those uses, but perhaps others do. Note that there is no protocol-imposed limit on the actual data fields: NSS, q-component, r-component, or f-component. I would probably share you objection to a limit on them. > Section 2.3.1, para 1 > > (requested) service > > "The q-component is intended for passing parameters to either > the named resource or a system that can supply the requested > service, for interpretation by that resource or system." > > This is the first use of the word 'service' since section > 1.1, which reads to me as only defining _resolution_ > services, which are explicitly ruled out in this case by the > immediately following parenthesis. > > Aside from the case of "services associated with the > namespace" which occurs in 6.4.1 item 5, all other uses of > the word 'service' in the spec either clearly (and usually > explicitly) refer to resolution services, or are about > non-URN-related services altogether. > > In contexts I'm familiar with, the 'Resource' in 'URI' covers > anything and everything that might be identifiable, from the > easy (what TimBL calls "information resources") to the > ineffable (the weather in Oaxaca), the imaginery (unicorns) > and the abstract (democracy), and certainly including > services. So I'm unsure what the distinction is that you're > trying to get at here. Particularly as in practice any > actual response to the use of a URN comes from some system, > so making a distinction between passing a parameter to a > resource vs. to a service seems to me a distinction without a > difference. The addition went in because the use of "resource" seemed to set off arguments, particularly about whether abstract designators were actually required to designate something, such as a whatever-a-resource-is. Note that we do not, at least so far, have a restriction on q-components being associated with abstract designators. My reading of 3986 suggests that one cannot have a fragment with an abstract designator because fragments require no only that one retrieve and interpret a resource (or, more specifically, a "potentially retrieved representation"), but that the resource have a media type. If you think that distinction needs clarification, please suggest text. And, unless you can convince the WG that "service" should be dropped, I'm certainly open to other choices of wording. > The following, from 2.3.2: > > "(By contrast, passing parameters to the resources > identified by a URN, or to applications that manage such > resources, is handled by q-components as described in the > previous section.)" > > is by contrast exactly what I would expect to see. > > Section 3.1 [also signalled earlier at 2.3.1 para 5] > > "For various purposes such as caching, it is often desirable > to determine if two URNs are 'the same'." > > ... > > "If a q-component, r-component, or f-component (or any > combination thereof) are included in a URN, they MUST be > ignored for purposes of determining equivalence." > > These two seem in contradiction to one another, at least > insofar as q- and probably r-components are concerned. Surely > for caching purposes distinct q-components must mean > inequality? Otherwise asking for my booking to Amsterdam > might get me your booking for New York, if I made the request > via a URN for a flight-booking service including surname and > booking ID via q-parameters, sent to a service that does the > q-conversion and URL-fetching itself. . . > > But I realise there's been a _very_ long discussion history > about this issue, and thus it not be one you want to re-open. > At the very least, however, I think you need to call out the > downside wrt caching, in some kind of "your gun, your foot, > your bullet" note. Text would be welcome. Personally, I can argue either way for including (or excluding) q-components and/or r-components from equality comparisons, but, as you note, the WG has been around that loop several times. I'll leave it up to the WG Co-Chairs whether reopening it is reasonable. One way or the other please note that 2141bis inherits two equality-testing problem from 3986: until one understands the details of the resource (sic) and, in the URN case, the namespace, one cannot prove equality (or, for that matter, inequality). As far as I can tell, Section 6 of 3986 does not discuss the application of queries in comparisons even though it explicitly excludes fragments. One can only demonstrate that equality or inequality is not disproven. I recommend a careful reading of section 6, particularly 6.2, of 3986 to anyone who wants to venture into this swamp. > Section 4 > > [No issues, this is a good compromise wrt previous disputes, > IMO] thanks. best, john From nobody Tue May 3 17:45:33 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0943912D542 for ; Tue, 3 May 2016 17:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=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 A0dxt6kmJz_B for ; Tue, 3 May 2016 17:45:29 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 4FC6D12D68F for ; Tue, 3 May 2016 17:36:46 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5193F509B5 for ; Tue, 3 May 2016 20:36:44 -0400 (EDT) To: urn@ietf.org References: <3e02d08d-9f0d-56af-5240-caecd7d01419@seantek.com> <790A858BDF9234D27BA953CC@JcK-HP8200.jck.com> From: Sean Leonard Message-ID: <8fbeb327-a74d-7f31-7d37-483c507ef465@seantek.com> Date: Tue, 3 May 2016 17:36:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <790A858BDF9234D27BA953CC@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [urn] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 00:45:31 -0000 On 5/3/2016 3:06 PM, John C Klensin wrote: > > --On Tuesday, May 03, 2016 12:36 -0700 Sean Leonard > wrote: > >> ... >> The limit of 30 characters for NID does not have much >> justification. If someone wants to register >> someextremelylongNIDbecausetheyfeellikeitandsoforth, who >> cares? It's not a resource exhaustion issue. > Actually, one of the things I learned when I was working with > human factors psychologists in a prior life is that there is a > reason, having to do with the ability of humans to distinguish > between things (like strings) based on quick inspection. As > an example, look quickly at > someextremely1ongNIDbecausetheyfee11ikeitandsoforth and, > pretending this isn't a test to which I've alerted you, tell me > if the two supposed identifiers are the same. A truly random > string or a hash, which might also have been used in your > example, would be worse/harder because there would be no > expectation of a concatenated set of words. Easy for computers > but, insofar as we expect to rely on humans, bad for them. The > Stevens limit seems or apply to reliable human recognition as > well as short-term memory. > >> (Note: the limit of 32 characters is in RFC 2141. If that is >> the justification--compatibility with prior spec--then I >> accept it, but that should be mentioned in the text IMO.) > Right now, 2141bis lists substantive differences from 2141. Are > you also suggesting that it list everything that has not > changed? Or, if there is a dividing line for those things that > are unchanged from 2141 that should be called out, how would you > define it? I am calling this out specifically because it was called out by someone=20 else. It's not general advice. The problem with RFC 2141 in that regard, is simply that it doesn't say=20 anything about length limits in the prose. It's only in the ABNF. The=20 length limit is "material" in the sense that it's a part of the NID=20 definition. Therefore, I would modify the text to say: 2.1 . Namespace Identifier (NID) Namespace Identifiers (NIDs) are case insensitive, limited to 32 characters, and MUST NOT begin or end with a hyphen. You could also modify the text in 5.1 to say something, but I would=20 recommend putting the limitation in the prose in Section 2.1. Notably,=20 5.1 says quite a bit about NIDs but nothing about the length limit in=20 particular. I take it that 5.1 is a limit on *formal namespace=20 registrations*, not NIDs as a whole. Therefore, the NID is=20 syntactically valid and a URN parser is supposed to accept it; it just=20 can't be registered under the current rules. A URN parser ought to=20 reject a URN-like string that contains a really long NID, in contrast. Overall it's obvious that a NID is supposed to be compatible with the=20 DNS. Not sure if this should be called out more than it already is=20 (subpoint 5 in Section 5.1), but I assume that RFC 2141's length=20 limitation has at least something peripherally to do with that. [Note: going to deal with "resource" in another e-mail.] >> +1, I agree. That part "MUST be ignored for purposes of >> determining equivalence", need to be something like: >> "MUST be ignored for purposes of determining name equivalence" >> or some other magical term. The point is that urn:nid1:obj2 >> and urn:nid1:OBJ2?foo#baz identify the same Uniform Named >> Thing (if nid1 namespace says case-insensitive), but they may >> well not return the same representations when >> URI-dereferenced. "Equivalence" in URIs also depends on what >> you mean by equivalence, i.e., how deep you are looking. There >> are multiple kinds of equivalence. > Need advice from the WG Chairs on whether or not this topic > should be reopened. I have no strong preference about what the > spec should say other than that we not go around in circles > about it for more months. I have no problems with the current text in terms of how the comparison=20 procedurally operates. I do share Henry's concern about the cavalier use = of the term "equivalence". Make up a different term, fit the term into=20 the RFC 3986 framework, and stick with it. I have proposed a term=20 already: Name the Same Thing. (Not a joke.) It's concise and gets across = exactly what's going on. Sean From nobody Tue May 3 23:18:31 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D506312B05C for ; Tue, 3 May 2016 23:18:30 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 20uDXr7642BB for ; Tue, 3 May 2016 23:18:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF2312B042 for ; Tue, 3 May 2016 23:18:23 -0700 (PDT) Received: from [192.168.178.20] ([93.217.79.215]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MC3zg-1ap4hA3n60-008rJq; Wed, 04 May 2016 08:18:21 +0200 To: "Henry S. Thompson" , urn@ietf.org References: From: Julian Reschke Message-ID: Date: Wed, 4 May 2016 08:18:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:7CuGWyGjrarwGXhYulu86Bhn+uasM8aRQ6xY2iztpXSHuXlZxij JFNswC3xVUnpgUMuqnz2xLooXrQBzFrtuYdYvOLf4Wbh7rvXI09n6uUW0mtWN1rg9e9pge1 gdL0rwaZkAj9iHbLZiXKu2ZDXAtD99sQfdId2NeXExTf1C0GNn4KHErTTfC5kxtc1EsZRnX XxMLsCne5Xk6G0DwCG7yQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:MTXLeCYB5us=:EXu5DeKupexuuK9UrUcKM1 C515iSoCyvc4Xud0S2JPVY85q3xK//UWrwZ56eZ7jGNPH9xVZNs1y9dzmCSk4mkFxlIjldbHk qsiWOWsvv4H2s7OtkKmYvmoLY/VL/eyrkg3Z/b/QTQlUq5JGLferJv5GOW/0DwsfU3luQyWe+ nFO4NdFmkKIEXSJsOINI4KFcTSFWcR2u2aPKoVuGHxTVAlBAW1mJbsP5ab8INWR1+RNWZqpIv F4ZLaIxWUS4brJkFDTdLr1f/kBJq9nX3fK251+6UqC2gbU81t+9xsjQQB8WMTqOSPLU7uDQvk 41MWI0JCRF011Txrl/QdeTlmC47k0R/kDCJ+bIIGHGsU4sGPt3PbzEGLAzoMh0Hh+Rk9Qp3r6 DL9X76unE3LB68iVuq0VREFtfQ0gfpwETqjZtrDfqcud0BI084mgupPW3uqJ5kp+FU4rJDnjD XXn0HzNvEaFU2iPx73o/uKeiO34E3U20/TT3n+qteqCSGzPXWi/OV0IPODBbwaPz9irXcFCAZ R3alfk9JakbFHuZfu0w+AEGI6wD01iMEkpekECHKFkQBohYEscjemBzrOEVRfSQgb7gt6Vx43 mCTx068N6c8110jTs0EpY3iZ1x95U0tJSQIysXxnAyc8l5QbMLrw0TqRJb4qUekOkYCtyEsAQ lYeOzmvfz+AO7DjHK3bzi6gvCuO6GAp14Oq9dp1jIIf3e4G5tSmPJSdyZ+aGpxtlHkk0WtVfo eBrF2m9PupJ5D7f9U9MLHL0pBFfHTSl33I8aX1LzpQrrSsn/pMRkUQBq8YXffgdN/oQT9cuN+ pj2FivK Archived-At: Subject: Re: [urn] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 06:18:31 -0000 On 2016-05-03 19:14, Henry S. Thompson wrote: > ... > In contexts I'm familiar with, the 'Resource' in 'URI' covers anything > and everything that might be identifiable, from the easy (what TimBL > calls "information resources") to the ineffable (the weather in > Oaxaca), the imaginery (unicorns) and the abstract (democracy), and > certainly including services. So I'm unsure what the distinction is > that you're trying to get at here. Particularly as in practice any > actual response to the use of a URN comes from some system, so making a > distinction between passing a parameter to a resource vs. to a service > seems to me a distinction without a difference. > ... Actually, the abstract conflicts with that view as well: A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" scheme and a particular URN namespace, with the intent that the URN will be either a persistent, location-independent resource identifier or in some cases an abstract designator that is persistent but that does not identify a resource. So that implies that there are URNs that do not identify anything. I'm not sure what the point of this claim is; is there are concrete example of this class of URNs we could discuss? Best regards, Julian From nobody Tue May 3 23:47:20 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8F612D0AB for ; Tue, 3 May 2016 23:47:18 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 Xoz7b3VdlUzd for ; Tue, 3 May 2016 23:47:13 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 CB9F112B042 for ; Tue, 3 May 2016 23:47:12 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 47CCF509B5; Wed, 4 May 2016 02:47:10 -0400 (EDT) To: John C Klensin , urn@ietf.org References: <3e02d08d-9f0d-56af-5240-caecd7d01419@seantek.com> <790A858BDF9234D27BA953CC@JcK-HP8200.jck.com> From: Sean Leonard Message-ID: Date: Tue, 3 May 2016 23:47:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <790A858BDF9234D27BA953CC@JcK-HP8200.jck.com> Content-Type: multipart/alternative; boundary="------------3DAB2DC0274E0376CC235A4C" Archived-At: Subject: Re: [urn] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 06:47:18 -0000 This is a multi-part message in MIME format. --------------3DAB2DC0274E0376CC235A4C Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On "resources": On 5/3/2016 3:06 PM, John C Klensin wrote: >> +1. The draft needs to take a strong stand on the definitions >> of "service" and "resource" per Henry's comments above. I >> believe that "resource" should mean exactly what RFC 3986 >> says, to avoid confusion with that spec. However, this is in >> contrast to prior voices in this WG that have tried to change >> what "resource" means in the URN context. I would appreciate >> those voices speaking up, because this WG has been dragging on >> with fewer and fewer participants, and Henry's feedback shows >> exactly what happens when "resource" is not the same between >> IETF documents. > See my response to Henry but also note that what 3986 appears to > say (and how he interprets it if I correctly understood his > note) is that "resource" can refer to very nearly anything. > Meaning exactly what 3986 says would require that 3986 be a > great deal more specific than the entirely circular definition > of 3986 which reads "This specification does not limit the scope > of what might be a resource; rather, the term "resource" is used > in a general sense for whatever might be identified by a URI." > followed by some examples and general comments. "Resource" is not defined by what the thing is. It is defined by the=20 speaker's relationship to the thing, namely, to draw upon it. The Random House Dictionary says: resource: "a source of supply,=20 support, or aid, especially one that can be readily drawn upon when neede= d." The 3986 definition might sound a bit circular, *but* it is also=20 perfectly precise for our purposes. A resource is that which might be=20 identified by a URI. 3986 Section 3.5 further clarifies primary vs.=20 secondary resource. The stuff before # identifies a resource (also known = as absolute-URI). The dictionary definition is "source of supply...*that can be readily=20 drawn upon when needed*". I.e., a key function of URIs, as distinct from = other forms of identification, is that you can draw upon it (i.e.,=20 *dereference* it) when needed. URNs are not specific to any particular=20 location on the network...therefore the name part of URN is not=20 dependent on network topology/state. So, what's not a resource? For one thing, URN resolvers and other=20 network components that assist in the dereferencing process of a URI are = *not* resources (in the RFC 3986 sense). They are services. :80 (port 80) is some network element. It is a resource in the generic=20 sense, but not in the RFC 3986 sense when it appears in=20 . Similarly, example.com is also not a=20 resource in the RFC 3986 sense in this example. It is an identifier for=20 a server (service) that is used in the dereferencing process, that=20 ultimately gives resource(s) back when is=20 dereferenced. When people say that is a=20 resource, they mean that is the identifier=20 that a URI dereferencer can dereference to get that (named) resource(s). dns:example.com?claSS=3DIN;tYpE=3DA is an identifier for the example.com = DNS=20 IPv4 address records. The records are the resource(s). But when people=20 refer to "example.com" in the generic sense, they are probably not=20 referring to the IP address records specifically, but rather to the=20 (web) server(s) that are pointed to by the DNS IP address (and other)=20 records. Clear? > >> In particular: a URI without a fragment identifies some >> primary resource (which RFC 3986 says is anything that can be >> identified by URI, so it's pretty reflexive); with a fragment, >> it identifies some secondary resource that is part of the >> primary resource, and is reachable with knowledge of the media >> type of the primary resource(s). The actual representation >> that is returned during the dereferencing operation, can vary >> based on ambient conditions (network topology, servers online, >> redirects, blah blah blah). Other things (such as web server, >> URN resolvers, proxies, DNS servers, Tor, IP addresses, warp >> holes, blah blah blah) are resources in the generic sense of >> the term, but *not* resources in the way that RFC 3986 refers >> to resources. > And the status of an abstract designator is still unclear. The term "abstract designator" was introduced in draft-13, and was=20 useful at the time. I believe its utility has ended. My vote is to=20 remove the distinction from rfc2141bis. The reason is because all URNs can potentially get resolved (i.e.,=20 turned into resources by software processes), even if a namespace author = doesn't intend it. A namespace registrant can say: ok, I am creating and=20 there is this "abstract designator" . Then=20 someone, somewhere in the Universe, creates a URN resolver that accepts=20 and returns an image/jpeg of an angry Worf. Now is no longer so abstract. So the namespace=20 registrant gets upset: "hey, you weren't supposed to do that! You made=20 my namespace more useful! Stop!" That is silly. People will do what they = want. Practically, people want to use URNs to resolve to resources. Otherwise, = why would they be shoehorning abstract identifiers into URI protocol slot= s? Sean --------------3DAB2DC0274E0376CC235A4C Content-Type: multipart/related; boundary="------------7FD7DC945FCDA2EDCE6E7498" --------------7FD7DC945FCDA2EDCE6E7498 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On "resources":

On 5/3/2016 3:06 PM, John C Klensin wrote:
+1. The draft needs to take a strong stand on the definitions
of "service" and "resource" per Henry's comments above. I
believe that "resource" should mean exactly what RFC 3986
says, to avoid confusion with that spec. However, this is in
contrast to prior voices in this WG that have tried to change
what "resource" means in the URN context. I would appreciate
those voices speaking up, because this WG has been dragging on
with fewer and fewer participants, and Henry's feedback shows
exactly what happens when "resource" is not the same between
IETF documents.

See my response to Henry but also note that what 3986 appears to
say (and how he interprets it if I correctly understood his
note) is that "resource" can refer to very nearly anything.
Meaning exactly what 3986 says would require that 3986 be a
great deal more specific than the entirely circular definition
of 3986 which reads "This specification does not limit the scope
of what might be a resource; rather, the term "resource" is used
in a general sense for whatever might be identified by a URI."
followed by some examples and general comments.

"Resource" is not defined by what the thing is. It is defined by the speaker's relationship to the thing, namely, to draw upon it.

The Random House Dictionary says: resource: "a source of supply, support, or aid, especially one that can be readily drawn upon when needed."

The 3986 definition might sound a bit circular, *but* it is also perfectly precise for our purposes. A resource is that which might be identified by a URI. 3986 Section 3.5 further clarifies primary vs. secondary resource. The stuff before # identifies a resource (also known as absolute-URI).

The dictionary definition is "source of supply...*that can be readily drawn upon when needed*". I.e., a key function of URIs, as distinct from other forms of identification, is that you can draw upon it (i.e., *dereference* it) when needed. URNs are not specific to any particular location on the network...therefore the name part of URN is not dependent on network topology/state.

So, what's not a resource? For one thing, URN resolvers and other network components that assist in the dereferencing process of a URI are *not* resources (in the RFC 3986 sense). They are services.

:80 (port 80) is some network element. It is a resource in the generic sense, but not in the RFC 3986 sense when it appears in <http://example.com:80/foo>. Similarly, example.com is also not a resource in the RFC 3986 sense in this example. It is an identifier for a server (service) that is used in the dereferencing process, that ultimately gives resource(s) back when <http://example.com:80/foo> is dereferenced. When people say that <http://example.com:80/foo> is a resource, they mean that <http://example.com:80/foo> is the identifier that a URI dereferencer can dereference to get that (named) resource(s).

dns:example.com?claSS=IN;tYpE=A is an identifier for the example.com DNS IPv4 address records. The records are the resource(s). But when people refer to "example.com" in the generic sense, they are probably not referring to the IP address records specifically, but rather to the (web) server(s) that are pointed to by the DNS IP address (and other) records.

Clear?



In particular: a URI without a fragment identifies some
primary resource (which RFC 3986 says is anything that can be
identified by URI, so it's pretty reflexive); with a fragment,
it identifies some secondary resource that is part of the
primary resource, and is reachable with knowledge of the media
type of the primary resource(s). The actual representation
that is returned during the dereferencing operation, can vary
based on ambient conditions (network topology, servers online,
redirects, blah blah blah). Other things (such as web server,
URN resolvers, proxies, DNS servers, Tor, IP addresses, warp
holes, blah blah blah) are resources in the generic sense of
the term, but *not* resources in the way that RFC 3986 refers
to resources.

And the status of an abstract designator is still unclear.

The term "abstract designator" was introduced in draft-13, and was useful at the time. I believe its utility has ended. My vote is to remove the distinction from rfc2141bis.

The reason is because all URNs can potentially get resolved (i.e., turned into resources by software processes), even if a namespace author doesn't intend it.

A namespace registrant can say: ok, I am creating <urn:klingon> and there is this "abstract designator" <urn:klingon:Qu'vatlh>. Then someone, somewhere in the Universe, creates a URN resolver that accepts <urn:klingon:Qu'vatlh> and returns an image/jpeg of an angry Worf.

Now <urn:klingon:Qu'vatlh> is no longer so abstract. So the namespace registrant gets upset: "hey, you weren't supposed to do that! You made my namespace more useful! Stop!" That is silly. People will do what they want.

Practically, people want to use URNs to resolve to resources. Otherwise, why would they be shoehorning abstract identifiers into URI protocol slots?

Sean --------------7FD7DC945FCDA2EDCE6E7498 Content-Type: image/jpeg; name="ncdngpcmifeeeiid.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ncdngpcmifeeeiid.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD//gA7Q1JFQVRPUjogZ2QtanBlZyB2MS4wICh1c2luZyBJ SkcgSlBFRyB2NjIpLCBxdWFsaXR5ID0gOTAK/9sAQwADAgIDAgIDAwMDBAMDBAUIBQUEBAUK BwcGCAwKDAwLCgsLDQ4SEA0OEQ4LCxAWEBETFBUVFQwPFxgWFBgSFBUU/9sAQwEDBAQFBAUJ BQUJFA0LDRQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU FBQU/8IAEQgBLAI6AwEiAAIRAQMRAf/EABwAAAEFAQEBAAAAAAAAAAAAAAQCAwUGBwEACP/E ABkBAAMBAQEAAAAAAAAAAAAAAAABAgMEBf/aAAwDAQACEAMQAAAB3dx9WOYviUg11zqGUkIA dBDbGmn20ADltMWghrNxssBN5WkORD5dCBzBU0NygyIuNtDNTXxyWuyXI2RjIcSEcFqJ93pQ 4R8S0S0rkW011EXw8ODRc61yNM9gg65JZNoBAStyFlIagVTxtZiy4U/IGHIREueBQnMsTkPJ 6F3iISqARFStmsj0FiVNaBll6lf0GuzNSMIhdH1QuKXphKPw76coy85VRXDgSW2n2pGm3UAE 0QyS62QzFsTAMjzaMsOOYtYhjCskM8KB+OlISiMYfY7s+xkrETYIJ4Ny2pPmxlT+ZZXo+Y02 7TcQPp9YjT1kqyJLvTiLiTAxFqOyjJlaOzNUr1sgwD8CNcyBVf8AWpNDdoghW9IuvLWCzm5A QZzPc70qgNw8t1ZulBiUeFYL1OzMKXUyEObF2vqFfe6YK57oFScWatHoqSBEOhxDSGnEAK0+ 3ItLqJDC41zl1QSIfDGcZPltDOu503WbDVdp610Lpk2HlI3PQGPko/SUWSMIx1rlJOGYJMRs iXZm/dy1dWXLQ8jkb5irnb49iRxmiDvD2Gux0dm7JI5oxeWuv5S9i9WGy1cq+wsIjRGbZgX0 xZTONIZmEiD3riZ60qhxTAwuRkizrMLNM3Bm9ccRtz+77yCSxSy1CGCjFbcTMttuNiYS56mn nUQOJ8jKnOo6q8jrcthpMLZJihvUuhPCpyceVA508L52i15hf6ny9CKFtWSdMNFhOZbS8+ly XOHQ01LufzRuuLVCtTyXZuPTII+4VHWPCFIHXhifdGIR4LojByQ0Okiz0gf1HgN8hMJJ6nlw sv7qhgmSYFFjzAWoDzsHcyIcaRqvsry+GHOd8D54MitODFDMBT3kyhl5ihr3lglLjciW1toU prsV1rraoOIk4mpSSISxoV8WLMq9nrI25SMtorp82/Rvzbzb7Zi30L866tzkcRGtsuIcTLsZ mVW8Wo4b9Q/LRE7oEPJ+b0w2X7TkOuYSuqorSDWN8Wo2ZHqRZgWZhkPHdxOT8FLy5g2GktZq LdkJ68qymzR0uFgja31zHsdVvLz6WGfZqVt55+97hJUnHyJogclgIznfTPBChGm3UrQhK0sd RZH7dNYuFOg40kKX6MU02h1gkGRiWM7frVoq425mGMDWvnP6Q+e+bba/mv6VzbeMXlwb9Okt Q/pKic+9QmLJcs6XjH0l889PMBqmH6d5/RMZZNQTUaogRtxfX41GdJchsuvOQ0mJIhljFykX C3absj4qSTbK96fPD5Ve8+9TCGiZmJ0mISldU462gPs5pxEZ84pKk6RjpF6pYfaFFIcaiW2V +qfJ7yaQhbYTZVRF0mzV8FpnR/MyIbcbVslhmJjMPs5WVWLNWhsy0TIqtEotlkvP6puiaFB9 3Ng9jyc+dN0fotk5t5az01VLUqPc6f0c+AWnNYPDa5Rcfzpztd/wF8e11qowWHffrniuoXhp MDokLjpUGISJIOdqUhrj9OTFYhowP5R7P3c9bq+u1TeM2rdyrxUI71xWM8SW5+tut+zzUjra DJaGlVopCk0RLax4lPOIoc51MjbbjQBBSItSG2tqlxC0K22ltJjlx0gNtlxrOyq5Yq3LamoO SAy0Zs9y9OzF4H9E65/K4suTG3mpWBzu/RMLZrz1H59k8/uYeBsFa6c5hp3zqDbeRWJJzhs6 r0fOdQzrVY9mTUVXNteogU47hDW0SkBq1R8u3mse1jZ4chnTGs0LRhXeLs2+DTVw8kPoznvZ x1PEgTMQc4r773BwZDbJIj7LwuoU3LQy4yDQz4jQjbzNNDa20NNqbGJIR8ghlDrUaOwE96Kr sTZ8wtGR4ddbnfrf4t+ncrocFIZvGtxnaXas7vdgx2XJpMSZW+mGAXTdcn1OKWgcbYY8SLLW ZAJy01Cbl3ycz3UwhzyZaDPaXq2JuNn1j5t+g3GJ57s3zrqt0l6Tru+EIJZ3Ws3hNar6dAdt KIrUPNeiHm+JGRO16fnR5K4JtsBEkoGcSlCm1NAlpbQxgjBWmWyG2DNkNjFbLZTjpSJlAQ07 2NDwtGz/ADrO6TdaRtIMNOw1Au2Yb2X9S4aXdOXbJpeuS203FiKp82cI8PvkOQCa0W268W06 0KlPv00EnQjMtULVdGw4IPqkT5UnUWzxlRRfNs+fr3mFZT9V/Nesr+lMF3LTN/04xUggyLIq iDPwqdn6KtJ5LakPzleaVHx788EAYDyRxYqWFMjNgU0M2BCRGxmthtgU0Oht4ZjqcfKchhTV xy2Am/pDJc7sKdIjSQNAZl4UINDzFLnOkoJ5wEo12G6KaHikg+4y2KQRre44V8TI2/ErXk95 pPELbYvqPBYLTUYiXPlRhgH3jHNEl/Y3zVdq2KH0bOLO19DJgJmkI31bivR1gF1yrLngIuTc hG5djmKdIy9DEqRBTzIjZJkc7HUiUDetEJY4D/mFxSkRgAWBNHFbmRIMRBcYPHDkxopsHmWY 0qwsxHVVjBZtsVBUq+hOaelvlytKEgvzXAc811BbbPQ3/RvkpOVWamc5a95PbU3BT8Gm0pPh Oo55lpjWo5DktD9C/wByzbbcLoRsrVuTTU9j+XNH7+fZWsxvmucpwttlRANcIiPSzE1FtGhh EiSr5USyRGIk24kOyxOVKrta/B5s/nvdazSuXFvcqPhWdNZYCfYr7JT/ACIaCcaiGwlwBkA+ RHykj9zqkVNWpurkos1Ls7wUvktD3Pec4Hue8jqkdZ7qfA4lPg8610JaKTxP3O+FzvvB3nOh 1XPMP2XE9Sim6rIVrC2meFbwzcY1Cf3HL4TvN51RuqemZ0Ibjl4iKsgRfrHWFUHF8MjYIcxE 3GCSK06IHZantn2tX+oU4pBrN5gsEighHGw40RYAq/LjX5I0qQlqPHRK3JdWnQSoN8QnNyK9 GyqHaG4t8qLjtLgHFT88xS773g97ng7zngV73g9zyg531mRV/K4z3veD3edA3V8duaeh55pN Jm6JcwLLnofoNV3bn2yn6NhZTt4fnaQp0uqs48PA1F4sWZXpFvCYpeVvCswVlo4INlr6oyDO udS4sTbO01yZsGO+bNWyAvIdLCLLkqk2RKRb75CSO8c0homMui0MoAlYKQDZl4mAt0BUvdMs Nah+5ElsssC9LJ552/1+pryuppcV7we7zoe6okF/SkNtXLfwsLqGZdEo4pNLxLZK2JvFA1zP qaz/AHD59OZ0cU7THf8AfsxvGZa+R3z3qgB48nl3jYKz13fOav8Akeiyro00ZBRRRLHoSOXa BVqr2zfN2r8mkXXrcrRIuMEZz3KZBpJvTPzk3cKV0YkCc8E7N57ZRWIBcLcAwXWyneirBfG0 g4SA7IF51pDkjFPAYUP1N6Sh7NL5P1CZzsh4d9qvtWGzNZjZLgqSxTgxGbkbHX7HDy75t+1f i3phlCuazwoclUdbKpZOft1P51vdK15mJECRvL7KgbfF5vHMc+i6zLkRpNtOr161Q9ut36l6 Deeg5PZscyqQtmcN2a3babNTpHQmkC5UwzV5mWFB1rQN85R2TAmjso1QfpWCqlIucnCSrGFD AJjaXu8TSSrypGUWkmXTXXmmL40SiO7zzThIXAmXotxM6fBbilF9i07QQlMOSMTMom+VmZku 9qoljgm/iv7J+VNJpKFo6oeWw/NSZzD/ADejFSR2n1y1CQu/DG82Nu51IXyn9XfN0kkI+RpV firvBhVrnWczubJUZq0J5/ouaSLru2VjOZ00i1/OunZuKRest2jS7R8/WbKtOzO03XNUUzfl b5fP/iM4pXGsVgXQ4ytKXLNGWyXM26jzGdz9XRXwjK9bLtc4bybg6nvPdZ73vB73vIMKifJ3 WQoErLt0nVJ7OpCajD5ehUAS5SGl41W6Wj40MnePOJs5VWmoSei77B3nJvN9KzyQ5rsfzUh3 eVsWrfPZajXZ5qo1NCZGa0HoE8OlEVC655U1u4UYub0nN9BTJXk1bliywy0dcCsgR+hNapLv cv8AOeWpfQWJ1X2qI6Nygjw6g6hSJCJmKLVWkunz0VPrUaEdJNdBvFrtRahKvcpd9zwe75IL 9zqPe54OqT4FzcD1GkyuROS7dT+eo53nmruXVZTn3qtoq1qo0rLtXyfC7FJQFp5+0WwgI7PP 7aq/9U1nRMh+oUSf/8QAMhAAAQQBAgUDBAICAgIDAAAAAgABAwQFERIGEBMhMRQiMxUgMkEH IxYwJDRCQyU1QP/aAAgBAQABBQIRd1tWi0Wi2rRactOTo/LDq7t2Fkbd64aR6I/dLop+wNCz h6ZgTxOcUdUmkk/JfqfwaLy3mXwY6RIO7ydiZndd0+qpZGXHS5fMfVSAts0Rbq8795DZkc6M 3dWZiF+oZPoekYHpBVkkU0RQLrkoydhkNyfFy+x+xxv/AE5X/rlcCAWefIyUsNHTa/efQidh OY9RN3liFmrtEztsTAYrQ04kthLTm7LRP2Tp2Rt3DsT+G8u3uBtBUfukUvuPRT/gI6DN2Ak/ n9T+TRJvMniV/wCt5HZ4t5rozSyMXSkIdVPRnrwz9SJwr9aAhkBU884B6yOZWD937fXScdzx xLpNtYXZVp3AbR9oh9zH3kVA9H3sKnz8cEU2QtZFVMG7uE8VNt72DmrbhcdpbBdPTDc77YY5 XF1vBbhTO2rM67Ejh0WnN0/J0zIk3kG1l0R9hhbsyFt0+il90mitfiSdf+MvkkabzL2E+7V6 HqUWVxWFWUy0tyRiZwGbaY5Y5Qq5CKZnoRFEM5QlBho8jHYw1ispJp4iC7qvUCSDaZOwM5t7 WkQWNrSm5PHOwrrxsntC7AUjqHCZG6oOD2iUlWCnXkvFI7Hqhm2p5fbK7Lco5HY2Hqo8W4j0 i+wTcUBtKze1TBydOn5P5/ZJvMDe9T/iLaCoG5D7pXVktSJOn/GXySPy3mRnNNTjoVs5mJbZ bJJ1hKBgqMUJYqXHRtIdKaNoj2Dj8i9OfKYyveqYQv6pJyjJ79cy9BjrTnwqxKfhm5GjxN6N zpXXXpbiGheJR4PIzlW4GyEyr/x13p8GY6qjlxWJUufacSsyzFY71zfSSu24DFGRaEJk8EHa aLaq1vpNYzX9bTO7afZC6b3i3uF20d+bp2TsnTeYI9V03ZTd5NFL2jiHQC7DA3YuzEW4yTo3 0A0SPu4ecXX0l4lyUEy+nDHE5sSxMvStTw9KaXfpTB2YseFqrMDxLFZd6VqCIevZ8zP7tVHY kBFm7MSbimYXj4p1Q8UgyHitmTca7VJxxZJpeJ70qmy9iZQT75sBE3pZS/vlL+mX5Kk21iLc tGQ6MTuymEpHKMmKwKGItv2R+I37s/8AbJ+bp35Py/bpvPUIH9SS37jayKmNpHDbpYdmCOP2 Wn2RRPq0r6JzXmI0aJUourLxbm46kePplsN3dyFyKyDU6pytcdt4qIQN4nAjtYB5q2jTLhmY 5qmRiZlL+XjlZ8P43OKjl3J59EzpnQkpdFUfSfHVulh//KT45x/shbQmPubrVFM7Lq6Iz3KG LfMwBpp9kXgPP/um+R+Tp+X7fk/2vqpTdl9RMVbulKEReyV07oPjk8mtNXxtaOOtDVfO8RcQ O9NbWBQuzy1pfXZCnE8RaNIUUAPGFdjlz87UcLDDGLYTIjRv7BlGxGUUi1U46sXdEzoS2H5Y U8ujhN7pNSbHQudq0bQYjyjb2WvbMzuTxAROY6Lwi5dhR3mgX1Sbl+14USDy/wA0358y5E3u dft3+x07qZ+xeZX1QfHJyEtsJ2e7ys6hdiPMUzjeC0GMzXHVUGRjtTjpHFpBUcI5oxD3R6qp 7LnGcm6EaZmNeqPXqgJVM6DdZ1oibsTbZHUgKKRfogdQwbjGv2owf3Wb5zjH4Me1qLWeGv7i DYxjuTw6KQe5k0bTzu7sOr9P7P1CgT/LP+Sfkfl03d35Py15O6d1O/Yn7m+qH4j8Om+AteWO gKxbzAjAN0y9TxJ7uHS8C+gxNGqcrAFWBugWgDhrgx3OJ6A5DG428cU1yq0IU5ilHNVurAQ6 OtFZDSZm7GHt29xN2UDdVgqsyPUVVN40JatESfxZb+6Mtrk+5EOrG+0ZJlObkX6EVs+2FCi+ Sx5fk7IvLpk/J/sdO6ndEiQ/Cb9k3wu/fVcOysGR4r/+n9O5287XZ8ZLMURRmMqrxMM8EsTw z5uGm9nJ3LR8PQy+vaFunxBWfF5noDax9FihxuYPaNiPpnyuRO5hGQpwd10SdNVNVq5Amjfb 0nNmqkyD2jGfdi1Y6O8o8TqjxuikrjE1yXcpWToW1Xht5fZ4UHlkf5WU6ZEn88n5dEiZ4SRg 7LVO/KVEj8D8RMn8j8T/AJOsZYavc4gi9dhK/a7xm8cWOsHEZtO0D4qUreQzmOsUKNanISx+ KnmVfhvLwyYXKW5X/kMXLL8N3zvZGSf0qytgVe06vPRnXTZNGKZmQpvEJMxdQXThqooCI4MY 7i9Laoq7usjEMUFqYpkYqdtE7d3fu2rv0k/L9Kv5R+bPhMi8Om+yCTdFuVnR4TZOzkpWNmcn fkfhviJOh+Im9yEHYMce/H2IOkVyh/k2F4ow1OlJfrhHLXw7YkmAb2GaF4VX26YomsoYRFcc wlDksLAVFPce0FjJdCLaNsZac0LN3TASGInTQmvTkmhJNXJDVJDULUKxKKq6x2OGNMDIgHSz LsaxdZ2tP7yfVrBtoXuePumk6T+pf7avI1Y/Hkb9vsdQWhaP1QK5ZYmd1JI7FJK5NyJf+s+Q fgX5uoDd2wBuUOUxcNPI4SD064wxxRS4osc+YvG55ULsFNXr1a1HRKGydjp4uGlYazHxnR9T WqynDJVtDHBl7zSzDbOEaHFVqgcNrFZgZ5IK4z8RvGo+ILW6llgs1vR6xFfiB/qwM9jOtEL8 RWCcMvYIuGpJbWPt3I6YnlztlLPuhuBo8sT6zaKZnZ2XhaOa0T/ZV5SeLH4OnReRbV/2nToz cU87opnTyuikd06fk/n/ANZ8ovxk7F+42cYsbP0oOIqz2KmFc/R8ahrhLPc6cVo1jrBb4KsZ KOoeOvZ7LiNrHl/x+Ks7Wxav5WSa69mTqvL1WkPQTPV69rpqW0PTI2J49VTjEsXhS3Y/N4kL kc0JQna9zMKBlwdLup8WM4XaVrRx969CJBep6q1WcFKCIUPdCLstifm6rvoWql/Gx8bouW7R uTolKnZOyfk6fk/ln/rPlF4k/N/xIxDHBOw16tgunT2w3eIKhXcZYpxUb1Z7Lyv6/HlBnBuK jnQkfLRAMfD3tx/FdhsrlpItkb/KHteYtQcu/wC4Qd36W16bM51Q24WpN0KFOaQp+K9oFI3s EFo2nBhe7iymU8coyRT4i0MqjHcFmvo9ygE4WcWQKeLQq4tvIBXSdPyflX/NlN8c3xJ/c7v3 8unTokSJPydOnfk/5N8ZcovE3Yx7vKzvTt3HrlXyRg+NzpjfnlK1VvQ//Ivhob1iLhKF1Pg6 QW46UkMsdZ7dCtxFNSxNixvkkkY0z6kPgm7Ezi7eYvx2OTQ6wnIbDRklHp9UdM+4WqZ4wpKo ty4QfbNBJ1Q4wMq+ew84xPXtt0pr4kJSavPH1BvVdSevtKOPRbESbnAWhqb4Zfhd9EIbInQ+ E6dOi8En5OnTr9l+YfEfKNTfIzALWMj/AMWWw3Xs5NpY60oiuH5BixObIMfciuxytJfEjqWy YMXeDdkzjKtfOX1Vn2oicYYR1IA7bEUO9ij0eInVSdgexpveVpeHjuNNBrIMTE871KkgycS4 0ariXbhSVt2PLUf5Ei25ejc2PTncomjd2aP2kBaWK+qOumi0XRdPyflB3kUvwn3gjj6h2J+o Q93TrVOnRP2ck6fm/IvyD4S8qPzWqOSyU4OpZdFMW4XdRl7sHkGyfDvFoST2H6cT17DRKO5G 0Fe6UtizYns2b1limc3J5i3PXHazF3/b9lKGr7ewPqmPUZn2YTBC9syLcMYC0urs3FkrBw9c thTsYHKCBYuMqo/yJX3lKLhJw7Y9SEUDdIW0TQNKp8cymxy9F010i5arVO6r/Kj+H8oJ59GF nIh1Z+bp1K/bXm6dPyP8o/hPysfSO5Nk3nEM3kDvWdziUhPoXZ9y4Sy9XH4/KUmy8GSx5U5W l93yDh63bNZLZNJrKU25dJ2dh7hoKcn3se5+kRv6EyYKICzyU4nuZ2pFRxnEcVQoOJKusGbo SDkeI8ZUaTK2eJLPELw1s3HHViWAyEU9Pi+/bYrNXVYLdFahBjrtF2YOmvyaYGZp/a+9k7rV ap1B8jJ/jnuaB5UAaI/kTp3TunR+NHTi6cHTg6eJ10XdGDijf3RfFJ5hiKY8dGFStcEr1nL5 EbVmUQiIW1K1F0id05vpw9xbYxEuWu493tGxTUijikmyYwMcryTjI0YHOyKT3CxbRryEnatA nyMEakzEhIshObEZFy17QtBVpFlO0l2edsZgpLZQWq2Ms8SWfX5fLZBqz8PWNlzNY8MniTF5 FS2xLBWGmrlCzvIHZhRirYMtq157lA/9hzDG0ts5G2kaD+ty1d+/U1Wq1Tp+bkyck5MnNk0+ x5p96PXdF8UgusBFGdR54YYs/WKjJPvaKwwbXnk6djbPHy1Wqhi0aaTVxLfHtjjE3rIp4RTn 7vUSa14Z8hYtVJaU2j8u6789VqsYbdfJ5z0jY83hHCweqyFix6vL4K506VKVrFOwG2WPVjwl gq0ovuE21b9k3tnDv01qmdapmXUYEZ6qOuc4Umb0ci65CXUczeVPKuquqnlW93Tk615ujUBD vudOIY8tEpbxTwHlpK0s/ENqd34k9VBPJtKaYXYhZBoUMo9ORbVGIspdARSa835ABmK4F4ds jkMrhqORPj/FU68K1+6rL6ODXV92zFibwQtIXUYmmzXCef22ciLRXGlHdXtMKxGQG1Xkk0Qv 7ifRSj32MvVumuJrOq6zIT1UVTVRMzQ499ahOtVuTn33Jy5s6d1qtVqmHc8+TYSlyBuU1uSd usus6KRlKTiUdl4jkIRED1WGqQ38nOFmCVsI1gtHXfk7stWWq1T8onLXTRcJ8SQTzZzi2lgr HFE0NjJ8v3VjCcCbaXIjc3VKt9Qo2rH/AC27vHY2BT4i9C9qQ8rEEBg4WCEsNkHhljfqjt7J 4tV0lYpHE7xOniXcUEpihuysos2cDYzMRDC87Ousyc1v927vvWqd0Lryp8jBBPNmYgUuTnJN bkkUj7hObuE7ORybV19EU+5PKzsb7XjnWur07LVrNinGdKrJIV3MUIRqOyfRdl256rVMe19V QunQuXLkl6z9lR30MXE/sqXSptzw1WKWf1UT1jDaLvukgttCqPHNKrWg/kPHGePylfJj+lKz yI4HXpXdPU0Tw6Ih0U/mqBGZTEyayTON5er93qu4z7kZPEH1yruscSxxsOVsIZuqnLRFOimb cdjaUs+5nsOntb39QJLeCPboT6Lcoptqjk7YC0L2ZDGlLj7OizMHrHmiOCT7NOfbTl2T9lqh TSjAEkjyl/oqiUkuPgrUobGejZpMpopLBzOtVgc7PiLWLuBkqWxlrqtdE5si0dGKNl0OoWMh 0lshpKTIkWolLIbRyWrIONs2eYBtx7yFdVxGK07D64mRWkVpFP2676Ee13darVauty1VbHT2 laxMlcBInaxYO3JoVaarMNVW3HLNk6P06xqtf9D82LRO+v8AqjMhLA4k8iebrDLmbFV65KCF 5JBxMkhnQOJfxrlXIULACMgR7SRdl5Xo3JNAUT02ESlssRdXV30dHFuRxI67aZCn6cqxbJMn V2lK3tfsRDqi1TuiJbkTrcty3LVQ1pJ1XoRwI7bsuqZq0HSk1QiRLrn0akpsdX/mPkKI2lep S0Jf/wAsEoxPg8pJsLGtvz8XQndYGk9qcAerkq2Aa43D+NlxnEy+obk1jVNOnl7dRQyeyB2I 77PFWiRsLpx0TpyfUnZllDZ4GfVpGaek8WqMNS295PLp15fYRqji9Ht42OZFi7AvDRYFvYVK ZoNJR/Frce+PVRzFE+N9LlcC7++WRttOUhUBRZULWGkmhmgkrH/si4ftS437f2ywVmSlPLP0 iycVe7Z9LVF8DlK2KsesgytqtBJsrY4K591HOgsJrCK13Gzqq8z7KU2s+dttWIRcRC1Gcj/k SnmYGnuyEUsxm8MirnrT11Raimd9ZKsmytVhmIcXUAXhijWjakhbv+rMrsbFqt6YkRpz7Shs JBOURhMQvga9TK4K1CWJvtb6p1LkkD0o6tp/ohFHp9nn7qsHqJ8NQ9PwzPC8Ev2BAZqKhIb4 +vLVLiSd3jKRHLomNzLgvHDYvyS7L+q6jKOR1FudTH0ge6obOqpTaw1bIQSeqKeeSfe87PI8 DHFFZuCAlZaWI8RaaCdtWjQatSx/DEs1fI4Oem7RkyczjkmcieKxLE9a91m1d+QxObC+4Lo7 ZALQiZxcfaT6ktzsmBp0TOLiWi1WNy7i9+BntDMPSmkkqz+u9TMbGD2cLOMmRxnSncXb74YS mk4f4LqFXLphNxvhyp5FPyB9r+pJBakYuHsnII8T42NsVIe1O+qptrP/ABzB/wAbLzNDbs3o 6tKT+QrHUY44mK+rVqQwEy1gl0HHzf01pP75cMzQSyOIiTlbue2O4Um/h+2EWTWbwzdccQEb 48hqjXll0tdCSPJYw4pJvycHMSnCQXicVUublDtN65tAc8zBZyMomTuuo5Mzsn8ke5M6tB1g 5MoeocL6tI9NhevOAx2zn9PXsTPLIYZGlNSxrVMlgoili4csWXnwE8NmfDSwytw5DVt47gzE xQYalRqYEK01ua5Ziex/JASw4hFziBnXRAliMXaJqd972Jd9eVP5uA4tnD/8iTHWCxmpcvi3 GRnauZONbRTgzNJoBBPo+Kk3V6MRT3OJsiLy3J9qxDgVARaWvJenqvK2w8NlnyFaDFRb5ooK BwFLZB4tig6QyTwDPHnMaEMoxGxSHqUbbTNtDpXGIfUR65KVhjbwt3fVblqte4ntcx93KKUo juHIRxtL0W9skUMUWRp5KSuNY61utFROWWnOFSKW1NJWoWZbxM8iHZfv1bT34sRBHBlcPY+o W62JaeHjcY/8Zdu78nbRRv3Yu+LykmOnlz7/AORHCUb6Kn8vB46cP8WQwXwg4YjcZMXS3lDt ElZFyU8S0WEk1hrytiMZZvbWv2iXDmQ1ihdorJQi5ZLAxO2NwdqQ2L1b/ULGpjZpAzWbZnZs w1aN47j2MdXlDKYuSpI/vXopdI3rxFLtkOaYhU05Su/Zfp03h35tGegwGaOsQtyCR43rTFFI byuVaJ5Q2aorNaUrYNFJUiuVoDtNFY+udY5JHCavXq3ZKeRhqXb1wwstaB8XQisQ5OQq0xZR tt9+Un4xeQDs4drQv1q1S1k1DwgeyDg5xPFSzw46HC7kVcArSQ1ept1Rh2sD3lBkTLhWk9yf irJNauz39bVs3Opjsg9Ugkhyrm51SFyFp6kzQBMeRje/HkKNx7Rz4xr1escHVihuVI1FYJZE q8kE954XYJZ3ixJytDh4wisttd05duQRFK9bh23OrWB9LF12FPOZrcSa6Yh9kFh4ShfdJATj ZgGA3j6o1A6k4nOdpY236KrK8WVmwdh61LIsL3/o7QyYoHxjUbVjIYyGt6TI8VZGrk73Lyoy 0dj0Bm1XRGVsdfimrta2p8zXjfhyWK7UVmYIYS4RikJ3RGpYykT1XJzrbHDLQ8L4UZCna5Ad SSkY9eaniPS4yca9x5o4q2P4vYGgyLC8DyQZXM/1ZDE347cVOee7DkqbBGXUgn0vZVv8XkdP hBiTU44VPdigVnOkpDKUkzO708DNZVbAUAUNeCBpTAVNeiZ5sHIQSVZwH/QFs43hnjM3riFu SaWDIQ2hgCSCGlfjOr60qvSqVyDCYnGQyW7mRysH1HJ5Ovj1h+PWrY6xM88yEHLljWHr2MeE 0Yu0T0tvXqxnFZktyzlGPfgiX081q2FUWqS5CX0sK6TkhgRAzNObCrBblkWOO3j7jaz1wtRW 6505MNPDBdyFnH5ClJetU6cU+1cPXG2jUCW3mrg5DJVLUtKWDNWJbUUzTFjeG5bRU+HwiDIt XoQZfiisBW8tPYTm5iXPHSNHammJxrEUVRpbEkMjAIT3iFQW7Ukz/wBwZXHFQm/0jKQr6pJL F9Y9TEUtO/HjxqFDm6x2YYLk1KHLyT44ZIoqpZa6RNryAXMnoFVprGx75jnGCrJYeWTFAB2d 7ySRNuZi2NQsnXnk4ilksDaGKh/la3MyeRGeqnHubLPuwVxJYy/uVusFuGxCdSXEZt8c2YzP 1h9uqjM4F1nJ2QRSTlhuFnsPhsBWox3M7QxQ5j+Tlkc7aycjvqt612u6dOq7kErZFT34jx0U rjhohZ4fTihjECBvbdqBchlDpS/6tUz6Jn0WOyXoSLikbVL6uWSR5gNrvrz4chiKXiy0Lzv5 wv8A2LHvPJi0GRxs7zMcRQqlFqMVMYhsXCkXD+ClycvG8RfRI6s/T1ROidGplxPI75DVD2VC UpK+WrhLT5M63vIHh6daPWozbqEj1a2W4nyE6ntSzFudarVa8nftyrk7Jy7/AKrk74yt3g0W jak+xsplrES8/wCxvsCU2H7MTIQ3uJhZswsF/wBqu2s+Z/7uC/CIneCk/SgtyEceJqhat1as VOA2Yl0xX//EACcRAAICAgEEAgEFAQAAAAAAAAABAhEQITEDEiBBMFEEExQiMkJS/9oACAED AQE/Aa+BYZopD8EJ4ZQxLQ1lDEWby1juE8Pxie8vjwYo+2LboarDj7Rr2JP0xqX1lIpij9mv ReX4IfimhC5EtkssS+xuxa4wqOGSj7Ij4LZbO5jkxOvhQ8PytpjdvF0J2PSI7Fo4L+iCdWLj YlTGh5orNZvKH42LxZHkttIi6ENbG7R05ar6LHyMaKEihJjQ0xDfjHgeGIZQtMtFl4ZFbEtC +iN3RFW9kkoqyLTbojsbSYt6R+jN/wCWfoTf+T9t1P8AkX40/ofQdbJJRdEmkOV+S4H4ttCZ W8e8PgjaO1rk4kReyt2SZHUjuobshNwkpLlHU/Nn1FXAuv1I7TP3vU+x/ldT7H1py5Z3O3ZJ tuyxPF5jwPxa8PePRF0PqN8knbTIxdWjd0eyqbbG8pDfg+RrKeULgeFl+Cx6ODuEr0Rk4aO6 x7Y3Zy8NeTw9PCfguBs5KzRWKFl4UqLUkJjdLCostHcdzLO4bHvDWxxx3CwnRV+FlllmxFia 8EXR3Flsr0xqnXheExjRevChUWMfyPyu9sbt4fHiuRxJIaKWUz3hiQoKS0VRRRXinhr4L8Yj bYk5MfTkuUcYaEhLYo2dqFFF9srR1Erte/hQ9Ya+NYjSds77JM7RqhIS2XvRY23xhpySGqeK 87HvFJjXilQ1iCjzJij0Jqk2mSXY9l2PFjQhoitj2dN6ocfZGx/yy0L4mikUsvEavZ2pkm3r 6FyLkoob0R5GLTEtCjuy7FbKGjWHmjRrNi8nxiPIkjqQadlDYi2ykJpPEX6H/HQptj0iMtUN ovwS+BPCebobIxvb4Ol/ZDcYrY6aJclGyx4QzueE834Lwfwdw3eG/wCB0f7HVk+4juKHyxiP /8QAJxEAAgIBBAICAwADAQAAAAAAAAECESEDEBIxIEEyUQQiMBMUYXH/2gAIAQIBAT8B8K8N R4oX2LsTdim74oisC7Fu9uzHRGLi2NkasckjlY3RDskKLeTlGHWWKTllloi0+tq8Xt6NR5Ok LqxYyaauQtls5W6Q0krbE7GJ1hlyUnxY9ZL5oWrpvpip9MVfZPU049yR/saadRdj/Km/hEjz l8mcEV9CwhL3s9kPw9Eotuxp0hrA1g0Y9sXR7ETk/iiK4oeRDs7RF1KmPJwi3lD/AB4fQ/xY H+ppX0R0NOPUSccUiKF1tVi6L8H4soasUYtZQopLAuhJtjwQach427KNRq6+ibV2hO0J0yxi obSOfYkJ0hSTyJiTZwW6H4UUUNCPW0VTJdEYqMmPLGJ2VRqw9/Y7wReNk1QpEpKjkNoixNUN ZwQjjIl4IeyGIokinhlUVjaPbJdCdyyOl+xJqrG+PRycnQ7SXI1Ek2yEW0NNDY2OSHJMUqYp zbx0aPKeCMFHe/4oavZj62h2yWUSdOyNS0xrAyMV2T+P/T/Dz7Iw4qiWmpKmR0Ixecj0oNU0 P8aH0L8eH0LSgvRL8eMkqwacFBUivJeSZezH1tHtklZLTTRpLhFxG/sVMRmVJEVuxrZbRyqI israv4rwfR6E6bF+xxJvjkpSQ40JURWD1smMoZYhYkJ0J7YL3ezwXumWWWhnrZdCJR5KhRlB 0NYIxt5Et6ZTOJRxKHgjgsseTit2tuxlFM4nE4lI7Qoji78aKK2epVtZohNTjfhWzWBHK+tl tjZp7xFs9qfhRQ3TIvwvZadYRFcVXnqr9WzT1XIjKxMsvd9bR7GNtPJX8GisCdb1/KSvsjox j0YijkmWKxWN0N4HKizkxftHJF4ryS2a2Tsz6E/vzbS8GWSbaM/RBYHJIi+RJnYo/ZX0LjH5 bc4wtsjJNWi35WMoSplFtCkn4XRKV4Iu1ezv0NyRFplULCssUfsi/RMiyUqVkVxRrwbaaIz4 qmaqTdI0tPgu9097L8WNUW/stjkxt+ymzT6rZ9DcksEV7+x9DaUTkJ0R7JkUNKSobppMnq4p CjVcsofCLHJrrKO0WMW1lotmd6GetvQ8nXRp/LaXQ2xTtUNsjG8snVlJFv0NNoWBvim6s0p8 03JULRhf/pGsxXo1NNSfL2Ru+i2JNnHZtjsSLa8aGhprbpijZGKjkckjU+LNHlO/obcXgXRy dUjBQls8iP8Ag9mxCj73Y0MWy86s4oWNq/c1fgz8dfqan6zYhIlE/8QAPRAAAgECAwYEAwYF AwQDAAAAAQIAAxESITEEEBMiQVEgMmFxIzCBFDNCUmKRBUChscEkU+FDgqLRNHLw/9oACAEB AAY/AvSafyQG8AwtDbrLkfJv4CQNBc7w6NpFJGEgRYDD4MprM2nnMyYzzGWxGeYzzGMDB7xY bzXOYaQNpjrZv6zCmSy/WdoDeZRm3aTSaTQ/OG4nco3e8Ev8m24sBkNYQFMs9ZF6HOHBXR16 G+sLOtx3U3hHT2mPrL6gTBUGUuG35TTdc7rATPWE7rw5y56QAZmWQZGYq5+kw0lENzutPSCY esYdJrPMZ5p5preWImXyR4DL7vbcB8wsWCKuZJPSKQRtLnO40WMyVWwXuEExOth7amY3Deij tFp0qZpLfM3ijbKZ2gaYrZyo+xvxadr4eohBFxMamxnLze0symZjdraazMy27WazMzvPhpef dMFPUy9dr+kPDXTtDfLf77spnuZgfDlusZf5RO8bidxO63yAo1nH2rmb8NEH+8tiAX8i5ATl UmOuRrsvXpOC4BqPnnLh+bsZe2UONzeAhrNf959p2Y2b8SW0MZe0PWFa1KZEIZ8GrMrN7Gfd NeXKP+0+7b9p9237S3Cf9pc8nvAa20D6S7Bqp9ZYcFCOgzMP2emT6mc7RofB1mcvfdhE6+Ox h+SdwG8QwmGMfkHaKi/Bpi5v1nwyGqk6LOLtWbHRJZAUQZkzjHS2X+IjdKgx5dDGGRUnoIRi JB/CY91HHTP3hxHlPpBSc/DPfrGNLysNDDDu5XInnv7zmRTM6M+4lxQmVD+sslNFn3xHouU5 q9Q/901jMRG7XjRveW3Z7/TcANYMvGRD8nKZzEdwAmsyghMPjFyFXuZ9m2blY+awj7XUFiPL fqYLtizlv6SkB96Pit7SmL2ugsZhfUQFr3HWYb4G/vNoOHyoXBhVhYiGmzk1KeaQuvlMPzBM R1w3hhje+/LfnuE6eP6Q/O1mstLfIFSoQLnHb0ERHuUepzXj7LhwNjv6Yek1yHWDCfcmbQx0 ZMK+wi0XOQPIf8Szg5dRLhryncZ3lboSuAQs3NfK0pr+EGxlWk2mq94Qe/ydd15THrAP023G N4b7s5y6zXxj28Y+WPAd6/iuZTpBrBVw/vrNmYaIc5S2q92flAhWwvCq6kZmcdDZkYD6RCTm w0gBufXrDhUhe99Js6hzVds9MpRo6Z4rxiBmuZHpLm2InIxWwtyLYk6mYwDZu+8wjdeWO7Td nAw6RaZ8o3GN4ct2Ry+Svt47n55h3U1XuJ9qqDKmCbdzoICW5nOI+k/h5bNrDP6Q94bWlHZ7 3xvzQ7PW5SujdxFtznoQYbqZdrWtleM489PMGcBrG2XvBVXRT/SUR0cWMYkEMnTwX8Gszl99 9xhmkvuN4ZmflLB/KmHcg/NlH7XzlEH8ZGsTZ2K4hYLf2jU2sbQ8ucToT5feFuGDUAsxIjNh BboEMUKuR6CKHXGT66TB0IsZ2sf6RtmYjjWxLKGHzWteVAx1XFbwXAmYmk0mkv4M9999zLCH v4+3gWD5N8JtPKZp4h4Gh3UqhFwGlbh8xIutpQR9Fax/eLUJtnYWjWZve0NnlN7cqRNopOWW rkcA0ivgYm+rZRjUGFfw8POCom0heoxRaG10cDgefvC66CwlFScITK/pDRI8htlHS2LlsY2X W3g0mk08GYmm4C0BImm79UPgFvkr7wfJXLc192Uv42h3Frek4ZyZBn6ZRCDepczZcNTCQBce vWUtn2elYhbs98zBTQTY1JBepT4jZ6ekNHLHbK5vaEVFwsJcAXjBr5aTQRx+F8xDV64tI17Z Kc/aK7t8RoDTcYj6y7UyB36btJpNJpv1mu/GRnvOGG+cJl5lL7r+I7l94PkgHpNZYHcZbxmH dgv6yop6nOUquK1Pi5j0m02+7d8aCfarjA2VvWYtvYikBkR3jVqjrVpt5KijJhA9RytH8q/i lGvQOJjk1OBEGZi1TcYrDLrOU3A6wMBdwLCVaL3x3wrKRLAKC2ITCoyGUUDveAZVKf5XznFT /RV/xJ+Ay5df3hWilNfUi5nnv6GF6lIYxkbZRqiKWw6iZIZ93/WZUxeZECD4rRalVrmE1GAn Ly05h3HtCJaW3X8R3D38Pt4cvmNGgjP6iYwea9j+8PDAv1lJav3oXMRj+VhDFXiYaY6GW+mc 5LL7ShUPkbrKVEqaqKMR7XlBSVx4LnDpESsvFcjEFjV6fIT5bdJiLHEfWL36wA7szPvg/p2l xupOx5mqgWnEYea5nGo2FQajvCrjPeLQp2tAehW8tee8vaWEtvtLAeI7vr/LGNL95S7u2f0j gam0VG5wdc+kUBsSsMo9FNWIlZHHEsCFHrOGij6wk0kfCMRAMuOR9bQ0Khxph66qY1fic1Q+ Q9RLEgKhsvoNZXqBuTyr7Qjqf7eLMZS8w64srRUI+IK3+DKSEjEV0lnFhpKWFdV80+m4Rh0K Si6KWa+GywgjCV6b7wkay43ZzL5J3W/kzGlu8Qf7ZYn/APfSIFyNZBl1ziLU81yuEf0j1Xci xxKv+IDs5F3XEpMY4sVnIvKzcdqdQAZdIDU20qDqV7T/AEbVXw6tEyLYh0lbZqyhNpUXpFz6 6XlbZb4nqsRc9BpAueDqYW+kPvL+C00M9Zs9Xu9/6GbNfIFQQYrDvzQJhOJGyMZqbBio0676 f6gRMXW5Erj8JzgPQy992W7Lfp4c9xh3Fzqf5MwxmqPw1H9TNqF/MVCADSK9/iAC0cjKqXBH oAJmx4lxYzYwzai15/Eab5BqgKS/EAysc5g4pK9hAqrgp/3mKoAT0mzMQEbH/eNRc3wMVHoI Fvp4b7h6zP8AaXw5RD/s1s5s1K+eEWmEqS3edb2l3tY5i0TaKYsr5MPXdSPapb9xKw/LVYRH 6MgmAn2gF92ng0mnhz3N7T6S58olug/kzKlU0uIoNhGUp90eYrkEPSNbnIjYvvDnpuBJ0lJ2 YKy1bH0iGvqvLcSwW59ZfCPpB0iCnkL6y2LJNJtG0HV3yhMCjpDl6w2gENpcbwJUw3zdS0XH lh0i21EFhzQp+XMe0qVBYkMpHrnDTa+gYfWDC1jcGNjcOtZsauPWUH/SRPaBTrLTTdlMhNJ5 fG3tPpMC6TKEfyWFch1MqUtkYqqHA46C3W8emwwU/MR3NtYDTyIgRiST1hG4UtoqALWxMQfS 1or0iCMF7iFTmZa/lhAOmcxN5oaKeZ/MRLDyiWEHeek0mu4WBl8h7y71M595/wCUfZ6K8Z3F i3aBSlTEfaDFcMcrFYLuo9xaK/2gO/RaZvKWzeXZEa9hKYr01qUmpj6RbbPYWys2sGznPqAe kpUNqoBQGOCoMwwmO2UVukVl7TPflNPENxnDX993rD8zLwhVzJgOE5tYnvKlLZ2FHYke1aoe 9/8AiVKq0l+JV5v1QfEBJ0tCWBCgZm0H6hfPcBfTSUVZ8ezhrMnpGeoyviJtY9ITblvlA1Un MaQcA/i/aO2ucsd14LCX8ohx1LzkQkzJQJbiG3pM2vvWqxBqvmJknP3MwlzbsIDU5ElHZaPN UJsbdI+HMLZBFo0xlsoQP9ZRa/K4lVGUFlGJfQy3QQTDfMfLEzhGizIXgvOQw4tfmZbr238Y HE2KKlU8PmAAlWlSxFag4jW659YDhy/tEYLY4bf8xFDHI3lR8+Mv7Hw3bXcwOtsjFGLp3gOJ j6TlS8uBlNbRKNO9Sq5sqxqVamUqLkQfkhMALGHZ9m8+jP2m0bVfmRbA+piM/kQ4mJm2gaVi wH+JSztWpNleBgb3WOPXcpvkYCPk6zLWXJhYeUT31glwsLH5vNMTsAJhsbdzAFcYqz4BboOs qfZ6hS51E+K+Nh1OsqYkx16ihajn0hKnEhFrQLhC8uXpFVWDPa5tHxKStxpCu+51nnB9BMsv CxAJVc29N2yfxKoAlBTdb6mLtNfZRXqoNPzTZtp2ekmyueR6Cn+vyGrf9RuVP/cv1gX89S/7 D/mbPSB83xn/AMTHfmveI9M2pFFqP20znDzehUNg3rK47OYLRYM8xuz36b9ZrMpd4QIfcw/N 7ATJbi/WZHCOgHSHG5bDpu1ljM56dYozsesBdRy/1mCqxoqQcJX83SYc7obGNepgunEB6e27 WZnxlFNsYt7wz+G7GaTCuvJjvlEo1Q1Rz5gn4RGr7PW41CrzLc6engZG16GW7b/bdwVPxadS 49jKhXNQMA9tN3DuRfzHv6RMAuF0HafabFMfMZqbTWLzZGBr+HPdrNd2sKsL3jo55rk+A+Kw 1nCZs+p6SyDGe5l8eH2hxOZlrB7Rh3jL1G7OWOkOcwk8sw55ym5XHhNyDKv8ToVTZqnxqJHk HSLQwlkqGw7SnWpq1OtjK1E6e/yb3z3Utop+em2ISpXrNeo5ufDa2vWEHXw1MA5nXDft4Aav 7GGihBNshuNpzNaBaj8wli1vpMVFwd+Zvv1ms13Nae01me+3WYn5RCMdrekIoLdj+NozCs2f rMTa7yZcHWXEJvL9ZmLTWZHPf/aXyxD+sbZqjhaO0rw+fSPQrthqUrplofWNQqkG/MhbQGUW o7OErAYagTqYUqKUYag/I08dx5oWbU/JVQSIrO3Oe8dHHMDaXQZmcx3q6NyXzWU66G4Yb8/E 8bwHCM5mzfSYg1/QzEmTQjrDLektfdruOcPr4xhWy9zLhhUA7TEDhtnnMb2vFWoOUzaxUeqy YOUp+boZSru9rDC9QzBxFqqRiV16/wAxy6xX2ioz20W82gU1wqDaAHcq941ukylTYnOnMu7L dlvuJciVXOSqLmFsKzyjdpu8sDr5W1lujQVO+ssN3r8rIZd5c87esw3hucjPQ5jdkCYAlymj AwrT1IzXvHWpTpo9NCylzYZdJRr7MFUOnMF0UwJUtmLgjQ/ywOG5nESnkMvaY2fFUc30iLfc uUak+hMOVogTy9fbdr4RLStgFy74RbsM5nnOky3i8I67j3t8i2E3mOsPZZycjS2C/qJd8z2l t2esteeu7I5R9mWlRG20Qa19OIOv1ExqpSPxFsag8wzznIt75Fehi7B9mbjUlumE+a0pbTsm zvwmyYXvhMw1Fsfm7RtuH4NEA373+QcIJB1WceqSmPpOLxyB2tCeMx+kxtdxOJTBQ4srxFUY CVzJmMDnPXw677Tg0/vStj+kHcyakdZYaTOXhsLTmY7n3a57sdrg9jpPi1cBl7cT3MulNV+k vbflDaXvNZrNd3puDU+Rh1EyjbHVwio5uHK2Kt0+ksrAtTOY7GVnaqKLOvLlYAxuEzc68wB1 mz7HX2Rrm4Sqj2sexlU8amKyE/BvmR6fLSniCYja5i7HtHxKm14qK08Oh6GPTbVSVPh0molN 6+z3T/cXOUAv3Rzv67wO8opbkpDE0ROjJvFt17zWawQ1G0VSY9eqbsxvPSZak5QKTmNZzHWN TSmXdsgY1U0yLZmYhrDLDNm6TiVLIW0UzNeU6GHllwSsuw+s5Wy7SzZMN94QPMIfWW8ODqdI QcjuylNKlrjIE6EdjNqcCwK3XGcV/rLGndx30lJqZthQWIAzheq3BplbfCXJfWUAoxq5GCpa wbKAOvBe9mDZYhHOzYqmzjR2mnjVFFyTabKdq4n21qxy/Ctu8FbEFp0KxLXFukO1ov8ApdrP Ept4LmZZTzQCqMaX/DKm0URekbNb8p3r+82mv3IWbKcWEm8faHPKq3jYVGG+W4gTWZwZwRR0 M2vaGqGnRB+Gvcz3yiH8AimkLv6Qs6mUy+QIw/Xdjo2AbVb6TnrL7DOKKWzmpVOWNtIPtChS dLaQ06pFjGKEkdCRrM8jCVb/ALIA6YCOogYH2MwPk01joTyzENOs5d2e7LfxR5h5/wD3v0ji m5FsysTiG2IA3m0WcNgXECNDDeneqNL+WUglQfZyB8NG8plCvVY1mpHk4hyt2l6FOjsWdqlI v11uIlVHfamyDUrYSsqVyBRpH7vhnlnwRlbES5sB9ZwQVc2zMqIDjwC9xKFGvVNRqlrogsQC JV2mviqBOIyJfVR3lV6NClUqBec25mE2XatkC03KjFRxZp2MoU6l6f2r7y+mWU2SiWLKrcwI 06Dw5wCGpsdTnH/TP4p/ENmdcFVEIemehG8RD+ZyZsVVDmCY2z8QrlpDl4hKSLqTF2Wkfh0t feDt/mVn1bqJiSoVuPMfwxqddV2inqZdNI2z1GwV8NlfvL7VUd6nUFoz06fEpnXLyy2FUU/m gTaaxI6dIQuY6NMLQ3HP6dZyc0sy4TBY3BnW4gDjmEAtnLW+R6dZlpvDBip7wY3SplcFO0NS k2S+bPQReIDYgGUzQda4FMtd0uhy0tDTNNXRs1uM1PpFTaalYbUMWCy5MfWNsp+DVUXtVOEz blVF2sZDAVuFPeGi7GpTqZin0EwbU67IBSHD2kUvpaP9kIxnkSs/Ue0rbRsgvtdLCzpXcWPq JsuyhTTdauIlTlU7zgbKRQrKzh6NQ+dbZWErJtNMIXp8EEZYfSbNs22F3q0hixn9rTaUqnFU KgJ6nwiCCohzlbbMOBK4wug6gicwO/ZpSpsblCTGqIpsBnGzGsv4bdpV29vvX5KQ/wAws2bt p6mIvW97mVEcXVzb6zg1vK3SAEApawFoXpfCbW3ScQvwVU6wUdoUJttPMdnEahwMhyniGfff DPlt0mIY2fpAK1IX/NOG9TCfTrCGXM/i6wgC3Y94VKkt6S5OBf1Gc5aq3ppMaKE9BAbzmPgz 8HlM0l/NvNuuUBRsB0lmWxRf6QulUU8OZN9JT1ao3NnoZsuBOELjGamdvaPeqNpt5XTMSpXp u1AGxDXsGiutPG6+cOcSmbWatE1qZWy00yFP1EoDaDak6XVafnAM2mo3EFOgllKDmb3myu+A pwx93fk9/WN/FRVouQAKGeYY94u0rQxtVqAVhTOjd/aVKmI1aFTPFrh9IVf/AFlTZG/8jNoA pmkMZ5D03rvEB9JgpKWHU9Jzm7e8vxrSlsVL8GRfvAahzlSmosCpEb4x17zPeZlBSHU5nsJw aRA2egMCx+qKMN4jWNr6we94rCpZh21tKYxNVonL1mLBcaZypVo1fiagAZS/E/1dHmXOMalU bPtSDP1gUO9UHQRUrUcKnysekw16mXYaRtnRMbj8nWBawwN09YUruAP6wrSz/VbOXNz7zmGf eHqTGBFjfw2RST6S7Lwl7vMYfjW1AnKoE1M81phH7+Em2MEYSD2gCnCYlLaiUpjPlW7KIVd2 UjNSBrHNJBTRm+Il5w8TGmM7XyEI2kcPlASrTTz+82nhUx9q0FV8xb2i1NmRztaUQXpnIaai bdTVhs+2VM+IwuB3i1NlB4VYCmpAyZgM/wCs2XY6nDIqf/I5rlT0m2im9+AvxaDjr0Mc7MRR 2pKoqXGjXm2bUPiU9oXmpDzBhmYKuz0eC2fE9TfwZT1g1N4rEYgOkXg01pKMsI6QEmyz8RM4 yd7W6jc7VDYWhfFU5s9N2W7PcSpDbftYso/IveEtfPrO6HMGItUngE8wjYSqjo184hd2WnfU QvccMDFeYdpW6H8QnFpM9ajU0FtIa1PlPEzpnteVVyBBDD2nEooorKLNT7w48NKkTbuYwNUk 6rnrAyEqwiqAxX9PSXr1yf0JmZYJh9TmZcDPuZm1z6QhMhCzG5O63WAuRRT9UHEqGq0w0aYU egnMwhVeaPVpLfrhmJqTKvt8lTkcIIz7RRUGBL6joJswo1V2gs3IRp7GcbgjZXzuuHL9pX49 D7QjsGNzmvqIg2qqG2dxlwdR1zlSkzPS2cU7JWUc7e82WxVKe0+Sq7a9rza6VKvR26psxFTB a4pX1tG4V67l8WQjFCPtlhQ2hToR1zm17NTH2RqezcSjUDebraVk2pWqbSr8Wi/6vWPUIsXO LwLj8suqj3EK6ESzmwfOVzSOFVOSnQzX/idzHoX+8F/rLnNuixalc2p64Z5N2e/KMWOuYmB9 IUYZQ028vQxX2hMdMaiPRo0uNXtycFdDKmw1QVB79JZhcT7PfXNZxqlSnipZ2vrHqL5RyiCr RNmExmpww3mUaQDFiY/WB+Dl3qS1RsX6RkISxSksK0PiHvDzZekzPgU2znvOO3ewi1MQCtpa Yqjl/wD6z4FID1OcXETGVxkcp3pt5T8rJiOsw1i1Vh5HLaS1k2aqPxqPN6QPsZrNtYN2p1iL fSWoVRX/AIphypVMlU+82TaGq0nWnTC1AjeRu1pW4XlcBamWq3gDuFeq6mjwMmKW6x6l34uI 82qiJS4wr5Alx/bfYaw1n06bqfvGDdsoTNnapmoveZZEDO25e2sSunIVzAmINia+sTaKxCDA GM5afL0z8VIfjZr/AE3Cm59oUb6HtCjfQxlK3Vjfl1iXpBMHXqd1wSD6Q3JN/WdhLIpMDV3/ AO1YMFJVI6mHiVhcfhWFNjpgfqML1qrP9d1vCKgW9pZlIlKkmuplXPTSKpHSZCeu5qbj2PaM t72Nvm36x8dFdopVBZkfrOD9mp0ay5JVHb1j7Qy1NoK2UVNMNhKlgcTKRn4Lvm3QRNkTy082 99yZXzlNVHvKlhYGAKt7RqogHUwPWOmghVNIthZBm7ymlO+TAZReR9O2870T8KUltuvFJ1jM w5l0Pgz6brkXPrLWmNALjvGU1sKjouUOJyfknftEU+ngshC+w/kSoYqDqAdfDSsesq+qg/03 JGj+5jm5HtKl87RmXIiI5Y3lJH0Y52iU6SBEEzANp5R+0//EACgQAQACAgICAgICAwEBAQAA AAEAESExQVFhcRCBkaGxwdHh8CAw8f/aAAgBAQABPyEQQfJlzlPSWepib/EIaRhMzl/fwGGG plRG5kZQ6zmVD8D4CGkyKMuIREaRwfDAXwCG2SqYn0j8JTLiZaepjlN94lOMFRbK7gK64lkD BCiEgPnlhTlDtl662S8PhlNVEBHsJvZMmcTgsxPOWbKEmYhu3uYbrGiqeIwWZEcM7uBF+q5a 0tXdzeR5zL6Ad3GFF9sVg9oil3KXo13B92pqLuytYl3gs+Eszr2m2KgMV7n2jyWXKwK01KDM p2Q6v5TuU7edgfUtdJKifC4dwfB9ctbubTmaoYvrvMpHjUTDBbVVwIeRzmACjiYgvaVrxMjC 5dbTKzoi0KYtD8wbJa4PtC11UuIlQx4hA5rwcl6xNCzamCDWlEsqPRBWVaxrdB3EgWiCw+pb N2crscQntR8x7BRdkL3ODNUX1LsKrxL2mIpIuovHiAAuHiCagauICFi8SqG+4KlUojwCJUzq CsooNH9RIIUryxIwemXrdWoIfW6MzQPEXDOdQUabOZrig5YtBKhbhm+IFS6EeMZ6/iFH9kKt /wAxmDhywDplak+ZRXI6jRiFROMQYn6Rhy8Stmm2oIpQMEKFTMeJn8mDEsngR9oYbhFVIs5m GI37R5KzPmbzVHFUhuIEaacRfEBtrW/Pkj9STtG8YPEYgAzWXV4gUlbo48JlFpsL5gtYXoAQ 9hWLHvJlCHOyMeRtYjamhqKAnhKj0sGBKumNFgSvAeoPFeo9aNS3qreY+UMS0O8zeG+IQp9C OZEvBuUqbIFErSrkalSAiDBULwSgIUbuWxLH+I17TCA5FYvSnKh3HAAV3N1DM/6uG4GcZ+Hy z6mq56lkZB0ynH7nPw8PhVQZM84MHqDYmmalMwpaKyoeItDLh+WGvE8eNQS96QuNwcwUIMue ocRB2ZancYyFgLgxDjAb/j6jFC3isPRMgqt9QwLwBkbVNQoAZE39xYoWAbJm26iGITELCGKn FpVmA7GJa5vy6I5YbWfEyUC9MAC+aub7bw1CVFbsuOuKb5I3foZmUZ8IlS1fCNjXBcoPNoSC B5dS7zMFZXeQNEYq0QEAczro/Ev1zejEfhpCo9s3RiCF0FRlBfEp2QRMv2jMG03NLUe4risQ A8pnKhzBiBZsYj+WK7YYZUumaXUe2vjkzIsyc7g16h6S/wC245m4LP3BlYYrPOJUNXMx4nki xiuiZ4vOILblHia/c2ds0c/AFwQsoobFUfmo9zeHXm+7hbarBx77fEqmVYKxFcb1b54Q3kRA +3+eoaxsQ5D/ABHkYpX9xjBaEKQd9wMItY0Klkgat6dQg9W+R5+34ey7nPiOilxTC8eKlwdQ eMRa0Z6YRaP1FnR9RRR35hN5a2wdXxUgVfeqiNnSrtZyREB0Awl4F6Zj9hYSOo6wWTDeEFih IDVHcY0kKBumZYW9tEDlhhmJR3DFSOGVdouakwZZEmixiWLjxAPOoQAelwVJ6lQHE1WXmKux cZC3KM3Ez8alz7ZbwsbhYGSCnzFh6gbf7hDOJekiMKl4xHceMWpqFVVSW2HcxNZx2gn2tQZL 1/mEcDyOVSoTdbgknFliInQEOov51FRjNQQ5oBx5nkaEYNi+SUM5Dq+o83O4739QbNeovIJd G6lz+JqXo/MYUGXEbd0zIPmXYv7gI5zUAZ3DPYk5TNriND8RcZnKmXo1CqNQL6QITCAsK+BC eIzNncpowImcXAzH9zbNf/mChmYHubHqIgJlU55q5rB/5jiNVkxEOIhyr3FjJCHZEIsS9wh3 3CxAlWdxRUWHJEZrS9kAuoHtO6/MsDM2bDKfiVc1aowoAJhC+SlwRbV8YhDLLZzgmZVl8V5S iUfwIaEFtvcdCwiXmUfVO9rj+Id4Gqn8eYu2sMNmi/FRrkE26OT3CGSkZI02X4uGWWXuc7uY 3omwFx6HvNSmzczPWo2OgbJdsVdwgy7lWEsfzL+hgIO3Euo6gWecSwb8wQv5i0ePEVD13Fao ZvBuNV0vm48mUPQl2YlR3LjRgwg/Ihr6RqP7jNdzi5WHj4/pca6JcHPuXiImT4idJRjZ3Hoi 7lyy1LXjmcpUNqtRXcdCCU+38GJ5YbvTjP1A7VAWqBb/AGQV+QYINmfUJYqUE7bhxUSrH4Zj AdAx9pVlTGBV6jrHi7QZ19S7UukscVLrWMaRzAIU16jqLlOIKGn8cQ2QS3o6zB7CCK1jmXaN YlyOL0wD59Mqa2XKQSiAVRvHEuLLDeIjf6XHN47iSIOTuAYpoOMxKHcZNn6hAAZi1NSznUOx lW4/tzxKVA+Tb3P+ZgSmBb8NGDM3vKHF8RlI8S0X4wy2whnM2uLl4ZpuCe4V1MHwKooEWVx2 JlzE/XLOmYCy2i7lOMwGBxttD+yZVsQ7LiGo25UhE/NYx0FMrKwFrTiqf7hTJ6Us4PTMiYtp RM1neY6Mh2ybxMhoVOuYCzVyKo4z/iEKGYafLzThhJKRScph/MuJP0O/3Li2yoA+DiNCWHaW f2qMP/Eaoqu5k9PM86mqBXUFIGIpdxg2vm4Vmr8sI2aqU0n3OaJLp07mgxEudELCy4vcHBPt VzBVFM/5mcZhzPdxg3Dib/ufrTbzHL8WfwnFzSOJtiOv6nOZfM7RM8zAHE3ZajFRUr+AoNNM Q79SgDl1OupSIEJa3LVZaH0MwEjSBWxahGmUKwZP5gIOka5+4Crng49xMykKOXk/UFnDhPOI AE8bFlaitQ7cWwdYFI2cOo1o0CUcMazvtFd7Vbd2Xf8AFk6Wiec3/uJetIJvhz7zLXI3TRxZ cDK9RMjiuJb1cq7KqANK3dw0q5iciaeZlRBhKuYipXou5cDaUjJUqB5hOjbDycEPWgj5NS2r glolDp3LNmXy8S4bhaa+55I4gxzGlQZEGJt+YIMGYsTOKVmiptG/9ysCdqgXP4Yhag9RBeYH DFO47swzeomx4m3+JcGYLg16J0c3MKZVIJYgOajff6uEE2Pq7RLTy+iThwWPh5incGkNkv4M AeWZzLzW+mCKXo0/cWx3RQr83BSl5NX4xAQZYuJ1ACPTRK1TGPwuGsyiVhHTANV18B3+4qAC qE0gBFfcvKiXMIYGAMjzCmqe5zBDGTiUAKpicMy0WERJ/CImjEACWJEMaj5faCrgiVHAuIFU OSEOfxMhrPqFdvexiFCjhlGZzxPWbahzxGF/3Da+S2/MfG4CPKcmG8xxGOyAixipTzKwDWIF tQjIGZiom2Zm5kPieS5ScCtTB+Yuod75B4uFclGDtpBV2RK03QHcVQJGOJQYUy4N/bNdsyht gUXCZJceCEoAspsI0+JQebrDEEmOsMTWglLxcpRu7lEFLIdxC4UKHJ/zG8C0bYQ7iNYTbV4e GWEQelt83Mqzqhf5QLAFZ3tcSmD9o4z9rhS/2i80M5tfU5IGWX9Jeq8S8CXDASjSagsAEMlo lnzO4epWoYbAsJE1XLBpRd5gEtRwdzbZrUGx9XP+bjqHbGG84m0k/iQ37oxc/Aclcxoo5+H8 RZgL0ioP0mf4mZdynrrxBFse46iTYcbgZzQnO5Su+Jeu+Zi+ZSaRSjymv8TAw7hndMqSyiO1 v4/uKzYuDgYZGLa2f4TWE+WJ1fiLyUQg9Alc9yqbmrbiBiOuOAwxTBxLCnXEN7cQY6MJu/v9 fUA5QDmKQKrdacv1DRII5TF4+pmZVGeLagUFWGJkwHI0qOWwWhaeOoleeAss/wCdyWdQVsbx CQLhaO7mAOV0BnHMoSu7xMAFPMYx/aP6HwRsWeKZaw2h8EpuHC5Y6C/uYfdiXA2zIBgUggQw ZNDmUhQrmCxF5nr8Ezc4xHXmPMk/RT+aCcqmQJYPEZVGKmecdKMryptieZsJlx6m+dzasWHu DrOMvOZkXhgVPcEuS6zNIaET3f8AUDOOV1dmC6qlOdjj8QOOHkydfqMaNqx+JbAviC3L6JYX uiITLKQjFTQVVsVMLpWqhq+5mQk8DJp9Y/MrRNRpluvEuHoBxmswgcpo0+4hpIq+XMyPT+lX +oayw1DQvJqO6StJfECCnWKZh1hdxMs3e70wCi/BTY239RqJbpOLmEr4TT/MbCHVm5Y8VK28 r6lTVi9xE+KPu5c5rj3qV7wWVQGSM2s1DCNPiXdEh10ypsG7nKz6ghyNy/j9/C4/mK2btxCx NL4fzNnuKKiOBXbHD0sPjSadS1iRrzqBm5hHcwPMsuY4d5jvZiXjumsxMtxYzdQNjnMFHDJJ RV4Be7Z/ZDyyo8UxNkK0YYf1KL80E1xC0vF/cbLbJrjn0RJa2WquagJ3WFx3EMJtuLF8sLdB 13URbz6aHFv1YVO0hAjSUV3tjzklnAHf/dyn205h6urqf4EB0Mkd8pf0mYD2hmCvUuMBiRp9 xyLJzuCZy4HrUTIV2hJC01w5l1sxQ2wuQrMXLsCfTD/JILW8xeCKUUkFBbe5hiqj4XuABR3G Erl9ioLTmCe3U9MeINEVDFzHl6iYs318R1LALVh4cEDJ1GKpS5kNQ4+O7sj+fMXxDiXdxcLq O37jbJn1F+CJJ5lhBdpUcWsv3Bx4fWwD9QUlt0oez93+Jh2qXGH9KnTTGglo7EOG/wCI6bTA rhDDlpGW1JliQL5BVy0U4nDfb3KU92F6dFOZaipI3Uf0aSLQ0mDlnWTyljigQXAteB4I7OLg xjEAyOonV0alghgjfJTDAhjh5KIxvJhUtApC0779TNMSBkisFrXKCKVjUAa5Tcpl8H6phYtj MNUpCZhSvdhEC15IEANHExItj28uJfX11CUDd8RRMzANvcvCm3FS4sLKqCJifrzNPEI5YGpW CJWCvKP1+ZlHiPGPz8FKZs3qO34KbNS6pxLDqLdzmLJZGquOkcTPzzjSnFvAB3Ohd6Ubb+j9 y91b2d1lrxuZVXHaGPa3LRAqDJXP3qCTVAnC24joUKukyt1ySg15GCnUZ0Nwl3BhBxWftApc cNvqoOEU2fSWNWmlNjR/LEVa0tDlqK1225ngLi75ZkYc1qEuiaO4tMKing3DA8DtqVECxdmS CwLE7UjX7ZRYmwPiYKAujuCbs0t7GPxoWj83BHLoGv8AeBtMiU1DsQ/qCe3/AClxyTJP7JWu C6gZJJei2ZrF/Y0xhYe5QrURf0nlfLSXq8SomRDBiZwZEDpMrfMOo9UOZj+IuppFfmLHnuVf aXDc2Za4vuOpXMu9R57nXqatx5r6mJQNSgBqsl/4+5W3zbI1VTPUFY7N85dvlnGBW0orBFrO OYRiyuooG1ZQ9h6mRQbc3TLBCvlGrAVoVxEpBOLvmDQFVG3zmO107r/rJuSDR+o6VSse2Hm4 MvcOyFwmtBDyL8kMeZADkOCVKZvL1LBKVHdS6K+yPjqlBxeGV4jqkDJ4ZXGVZuOI5bCVmVg3 a4lEYpxo/hiNUcRwLiAolHGRjrr1Ao17g020Pp/3LOXluW2xxD4s1K2bhH6oCJGkWk5OovJs nxVIqaXzM8WHxn7E0mrkOHbe4CNmBRsfhfMvcU8vgq6zBS7v7i3FUeOYo4Y/r8ZwuGXUQ1AW ughms06yF6Fr9yuxaVNIt5izEDk2y3sLoW/7j8A1DLOiWfQFVKH5Z/EdycDfGpgsNNxwujTH cAqBCM7juQUo7+oaECp3B/cyIuHxGQPC0sMwMJbmjSmmWaAf3HWtQ2RHVo8QwDXsIHVEdxiw W/EI2VMK/wCE0zQNFKpt2w8ikasRyMjkLjwrW2pH+EKKnww6bjqc2X3K+hI4eN49TCapZKHc qqeys6Fx0bq7HRfZNx2QjhL5goWomeDcxqMRDRMTF9ymSPAT2VPacIoqkpVNaEZQYQKYLWMs NKxgc0/H8EwR/Uu0izjXwlTW1EE/0E3oygVzGJvuauqgHK6CU3i874X6vUwT/iWrKv0qDylF soChOjF+5WS1tqF8+Y69ZDLrEu+aAGxfcS4tSQUOpVcZJ3zL4MjzjF+T+oPyKiG7im9ynD4l ZdNkTLqW5bUFjLat4moGe4qLXjRLAtDzzGbJfUaCML3/AIlzjGFKLhdF1Wcyyi6YEZtl5bnF woO4BfkNpEzsrQ2oGX11XFKbNO2CuHr/ACQxPQnNb/dwHlUVumfw1CEvgPd6jxEumQLls8Np jqFXBmSFogCxEM6OoCZJbuev6m1LLIuI2/qarhlzcJKwLt9Mr1AL+0V0i+5jeuk0j5fBXmLE vOYudhPpQ9jRNqydrUGyjccVUFGAmZ4zGJQUGV4gE1oQ3VUfzcNjsC21wQ/kYPQ4ePEtOgsu 8+0LdCwNXdRuM3gwPaoKtUa/PMbWo4jl1BJtzxCN7Rg6lZeU5OJbas3Ykvi62aHMomw2oU5H mFkMtM2ALwah/VOO1j3Np6SMCyCownllpBhUMpQSXC8ESqlf6c8+ZbZmPLqH+YyyyLef8yww 312N/sRwtIB0vTA0CtrusyijTP3KqKZD0lw9QSE0rIJcqMxb3mU8zNlpLLBctAg7n2YrtPiF KAbeYcIFh9o20F06nEDqUgrGIQ1vzMnmLqoy2cyr/c2Liq3cfMTvMrcVRR2J4wNeYFTQLMFv UAqqC0bfuvzM0WAiWFVX4l8FlhUE02R6wmrNLIdDj8REG5J37gBOATl9/cHn073g+osTWOd5 lZNg4Y5gnQwy2+A6Jhpb5bqZ1Iy5bWFx1F6g3wEOF1b+YDKUJRbRpCZurDhHnURS6Adaw/cX xNuo3M/B8VRVeXZ3CkSqbVdxqXOnxAr4A081dPVF/cAAjZO7uGpdF4P+SVzb1WgtsOo9mgOf ctDHMtzshWCqkhmhjXdGDrqKp38IJbJbWpayAmG39olTNYaGvxCIoBxKB0H7mtfMbcxpczI9 7nsqXL6myW8xEcIvgjuWAtVwEdhjgrZBjxUCypSWdRs3cqrRtYKkw8vDH5y0mmYy27BexgyS Dk3cNLTVeHTOIcw6fpcaJscRj2dy6hrRvz9o8mJYKwPEa2j7YDTMk23CHbDUvpyIfavyRsFj WGUWhHFB4vbFkHf5A/4jKwZBe6HVR+C/KCVSLDhlxa7VcPggrgUHAQhVoKS7IH8VAxKnrn/6 gQDcF6R43INDxLMdXEZHUW22I9ssVgggUFxw6TmGZYSF/KI3TKBKyhkvwzwiLnSAmzKqqGBQ RvgzqKYKD7l8iZZYtJLTcdDueSPSLnDfwF4CqIaJwBg9Ra36gmFUcBCoIcrdu4LLwckoswfy l8+2ZYyQsxXmCqUsePbqUoscRSrWxfDGyEbFMtRuAmnEdioKNjlfULxQHKzuW503Ipqj9Shp WC21jlGGpfyMAQMibmd5iDFKzmo+BtnzFixZzZcwIj9kwKBzGHy2goFuXPwPmEqNQbNDBRDg cEJ7MVGToQmzBysBi4aMrLHD24So58MSLZk1XlmwWxtXiUI3qk0C0uHNwAsxJFR4TKP2iXlK WzzEO0FAz0JeL7M/iCJfYqUZ56/RLVgbcJR1WbeYd3cEQW5UjRU05NhY6tTWoBBCPEcG0TPm I8SNJCpyVifRcS7luOPiJgpdUniOptnTw6iWfp0KYvyMQzYRX1hNVcY7ErfBZSSsrHaeZr3s 6SLTGMrPxTM1wRUKyhVTF5hZ6gv8G3iGWW+BY9V7n5v4JcIMtwjsYyKirWbqIMHUrcS2Qc8R arl1c0XcFccR2eEh3Bn1PCQxbZXQ/cSamhTAXUTggmHQSppKTrMYNLBvZ4hQ23MsXG4vQHlU OKPKShxT6z1FK2DY8S+cVATcayxTHzLLFTOUYl8jzC52+ZZxImVZl7nLeJZDNxWS490fKWuL JU8ZKPAy7EcjdVbb4ikAwGsWnMp/KLbHDzcD4lsJY2cX1Fwo9qVjXO5SEP0YYyyrFi5nMHuW RT4fc4j6xNs/KdfL8kBLS2Kljg3hEofMaOQBmohLJRxARlUIMDeIWFrcSAhycd/AFA9y3bT4 mbWiF9LjX2lESZyCuordi0Lx3wlxaYDwTYA/E2DKXGbZxhIoIEodMr11MIjWHtEtyYgwePxH qxUXqJVk0F33OviYk5IU9dTFxH4nTF3agRVtsYITStGJtN0VLkBJBS8CzMgVYVeomHUpBDOC U6KOUNZJSzkFHYd41CjVL7Ju+oKdgZsHp/8Aj1/4N5jOJqP/AJTNN51CUi1qyxeGcZgg9xEL KXXXwesq4hDpaIjBsXqAE7WDBFxaosR1axnmpnDnqFkplubiNmCVqFqhAM7H9RtiMmcsLJzg wINzO1cKszV7iySyZuUGbRjMli/4hLdVqWXARQs2EK5XM7vEFLG9FsKwVOqi0f8A53GFAfRh jUUdmJkEH8JVB+AhwS/RMyaXcL3QSxS0ZIcWMBzo6lc/lOngv6IVUQ4TslqUJUoh3nuCKea9 hTSRmXhCSpab17JRhKPCub6PcvErsOE7/wDTB+SEMssHG2+Qqvr+Inwd9f8Agbe4oUBY43Ay KbF14lkUlbYulDRLPHKAI2XIwWb1H19HoRIF3PbPWKG5Ri9yjm5p/pLFqSuVs4YJZWkBZ0Ie Q/b/ABLRdVvxEmcC9XOw6SwcCuYitQRdxO3cb3KdMUEvUew4Bhs6YdvqjaVYkqgCZbPtKllt Vv7gUWVuH2oNpxC+4HSwt6mlQcQrVF5hYEMbZXrMyVcgPIeYQc3imMvZxB4loxKt3xLAmuQi PPRC2i9u+5i8RspwiQtAArmgrQ16hRcyFXCmIGPmgN5MURIh9bBcrTOWHG/jNf8AoDAucbua yOwwvSGtj1Tf4hSUceRqJNHxU0n5SlAvSx62o0PcE3A1af8A8QOe4AbgZxagh8L78n+49UCH 8M9PgXgVmAuKgxCtfwlC9IWXLJsJOULCJE2RdEuXmUFwkExuDCMJZ3HYJTBzESjScj6lOe0X mvU2yDZHhXuYTQYBluIWA7Vf1Cpfo8jKE5BzACjwzcO7BUELU5ah3Bwu4IwTnOajEF1AIVvH 42uBi9MaLSO5S4ydS6unqDKdQhdG698EFtBpHiWM5JQpa9xirNhS3LcHI8MaKu9tDmhz7i8e 0L5DzXcCrS1AVnW83uXtMWUJVUP5g1lAsVCj9RJtHYh2XuoFxqgA9P7jtKHzH4qVAzAi4xge 5XgMQWD17U5lpNhvFgF8BYTM/lDGW69xINfAVFx00EJJlfMJ6Iu119Q3ARHblPDMwN9RFa3L H0w4/ZL+2MCmo95LIHG825zlH0lgssiAGOCzeojMhzAR9pdmlqqcCdwfRwDPMepUwygQ9bKa 0eYBJqycos9toswZgwCwXhcxow0+HUrHSz0s8kWV3s2+pjCIGvpBAn5O/RljPju2/EvH1aiv +Ykpj5HiZWwWr+oGUFUYlWD0OIBtB/ZA8SDDHKbGXaB4tyS3MTcbZEgjmRBdMoazHHkeIB1u AG7/AMvgW4iyldajwQoOfUFoWit0a1OalcLEuvzUDGVk8vZK2QGTyNnDMiiJmj+HiNMkLhQ7 P8eSNrSC7u23cB45hKAArz3A9BjMT2xCAwKHApaHYdwrzsC091ENY6IhpvnxD4Q8DB7DK7qU 8iDmnJmYYCGArJ4QPuWAVcNjIV7cnqB/eYGgoPSETOZt8LGhjAAF5qCxwPD4Rl2zua7PGIjV hNzxAq8sfoiOA/H1AM3a2/EIrYZcl55gYJb3E+DqeQuEg2ZxMcZm6wvHmYCnVOect2unPa/1 GsF2fkC5bn3XU+MS61Su+SAbNmynJKWqkeGH3B0sxgL/AMRwGUi35Q5Qli+PATUE6NGu/Msi Nxb8X3Gx2Jh5JwBLHQ9+4FS9PMuUlj1MhNgjIDYwwYuq4o3J3zKxFsdrmLFENMxw1DlGT2Xk UOzqELK+riM5xCNJ02QnqMSoXGP44lriFAyTx0yzDKUNDzHiI1Is+wnIa8u0osyhQXaFw+Zu +4NK4F3HcZwW7Mv0MGtV5Rd1XBGFLVnAiTzhJSWcFGNty0ucxWDVANKu5phwNikha+R6h5K+ UzLXCw1OwbQa/wAGL542zSot4oYQEBqtF2fuUJ6+BLBZuBRVkW7K3+I0aiYXZct5KKYoH/Mr gjiWuHD1AKYsWE9QA4uZsRKuJ5FohKi9BNGjMFRlQJmGbeDuX2qpUiCq7dxctY0dpDBLRcJZ VqFYSjwuMTVKVyXz4gADYiq6jeV7XL/Eq1oi+R9TahC/aPD+pc4GYCjxRv3FQCy6MLq2b2q0 qkOEZkuB7xpjNZFFap3cdYls2I2qzYa8zz4mCy2HaFMHZVX1uWC9aFfZ3FSWFW2QorUy1WMD lxHlDcYo2lC8nwZcFxFijuoNWB2sXDA2GyXGPlaChLEYJJRs6yVGB7VTdTF1GEh0COw2/UHY 5yyw3+tMUCzGy3hrwR7ugqUFdrr0wVScjmvPOIl45ZIcNGKJgpdbFRp+tSiK2VE2mC9yqdmX Bah+nUS4VFk46FYhx5qK0oD6GWJrPsUQPCePMXdgQcjhXkeJtGytJeUmqqjxcDFi9xtx8DUR RzBhi2NnmxmkrPcIorD9Rt5acD7hAGm00gLE5xcAxwQbs/qE33ZIVB0T1DnyefcfQgFN4ij6 lXLM28YW/J+YYCr2L3W2c8cA4XaQWLyXxEDKVULiG0GS5lDC1Dlw+pZFzLueYusr0BxG9w1p sckoiIS0SkBLK08SwBMmvvCKvW9FPcqwNhGfK+5uI7rYP8xHxLEcHsjD0eRtAAI6VGZQG74j cKBHw8QuuBGOKzLKQeIlMtpXAuAhH8H6lohiwVUq/e1bN00Ayr7Rm4jtGY8tV8sRRXQ3FVDN CsP+iqqBbPDOIYDamDxbOGTtXGmnjLqUIQUeQO4eUwGFjj8dy9XxRUXyeXmVBxDQKLe+IhSs NwwPnUWwQ0DBHuKMW6aLtEOzEuK3xyhKDrmKxYYCVNnr+JRLYKh0A+v3MBOIvF5v8Y+GWovM awWwxfsRLMHANTKlRdL8Si1LHVoTthx5lGwnNExBDI9nn4NjePdk3un5IAJ4mrlANLFhaoKW 7iXyhfHbywIbWUO4uG09BlNa8DioVHBgteeLR+h36gBReS7ou7gBrsbz2Tj4XgybeQcsj9yw QYbpWa/mamr2qeP6Zb9Ehx01T0wstLG1Oq7lqQWJA9RkrVu1gwWO1W9uiDUSeVhFF9iBtHRA jJPzHKKtZdypBeARtfcvP4j/AGELRCVHbhchvbBZWcumOAWX4eIvI9rgR33Fl4nP/nitibtb GCcSjkgeTYFUXWX+IkKBr062hdSyUW808Z1LqgEbvwo8llxecp5ZSg8zJ48cI5DiXqczsJct 1D/axLy3l/7UMXIcsdn4IzwQGaCXbsJTOBXelPqseoDxFBotuLAVDBzPEZiWc3HwQGA3AiaA +amYYQB1d0y/9PASZrtxxChpUxL0ufSH+paWzRtlODwHEAApBGbqD5RLQS3LB5l+4aEmat46 hi+WlgRlmE48wUbTffD3GbOPNc1D5Nkp6rZTD2jFF5Dww3QUjUrhqvnmomuC1QjhYa6EeQJZ Ymu/DGyUmmvPudAIDJiNJsYj8QQipr/j3BhI5QhCUNXwS8COuBL8lwbgg1GrxKYWjvuWy3pm CgGqC7YfnTTj7i38kRFtuCtM+McmioKTSw8QWF5H9Ev/AOJYVDSnT3FAf0hfi9koiAmQ1Crd QsCMAKpV9QzZdMAvbDReIHwn1G14JUgMaFoX7dw1oCRgW1+j7Y2SYJdixeccypO4stzT1Gbg olWiB0BKDyuo5iiC11gcZchDC1TLMrIDXDUbJ2hdELgNvqHhimzzuUbNsc+48p9lFnqZYBnG Uuo5NvoajyD1KzEc+IK0dxK8RvhaHgf7f1Ofmcl+XfiAHlyHKCDSehO4ii02oPuZgdq29kHa svUpgpwqkl+U2VZhyUnYy/L7qiK8p1/ljLkBLP5l/ct9sQcUptYzoeHAnnXBVS6hicRCWQW/ BNRWphDgVqXFrRK1uIQluZatJY6KQ4U+prG00rbIDBEvkXcwmtWNNTb/AOD4YQh8LFij2RUB TsOZW7MM1Rsb4ZcIQZQDwOWuYIFejKAuzgi7QwcheIiV2y/ivw7STCPge3r9TBF3mZOOuhxK XIZRCw6TRq+ZVmHIEZujejk5ju2j/MDBexxHbZ3NsIWdYMHj3Mq1cDKAk8XPKEPW4lRrMKmB AEQ7Lf3MGNQGnxGPum50YQ2S4xMPMrx+CbhwRQ/NkwgBjUtQlhNzHjMHSb9zuPZFVLXLS7SJ WPxWDVxUYIaPNwmW8P8AJFZBdIGj3G60XcVK/cGybnJFtbm9/HMfk18c/Fw+XPxsV0Ae3y7+ MCk1LyXunwbe6b4hWJ/1u41AmuVQ3VNLjYAimJye8KZqZKuCmAoJXdYs+Hf/2gAMAwEAAgAD AAAAEO/vvvHrv1PtOP7f/wD7/wA9rK0/9/V+8s682GP1/wB/XfvO/Xrv7fvfv+/MysdaHecM NPRpF9sN7fze7/HOvOvffff/AK3bfvzfq4w7n/S5VRf/AM/V/wDab/v3PvfLXvveeYffvOMP 3PNfPFFHFz/v9bff+/uPLGd7r/8A+q+IDo76l5/6OTvvfxfXVjzz1P8A+/V/7b991/rayn1M 7qn/AN8MP+dntrL/ACx737v63777Rb/7+n8ZtO+xxB3nv6zTLx0+cxe/3/fbz77/AO+/29q/ fw2ItnouhAnv/fs+9mL/AP8A+W3zn75/7j233s3lZl75/f6pSjT7/Pq6z+3f/wC8vh+/3/8A +3+YO7/Zdk+ffDu//wDFn9l/33+r1/1Z7r/vv+63nXXlc3fe9+/z777s2U1777xnr/n23/8A ++9X/P2fs7y+++s5Iiqs6+efIe9pwf6vKxzG0Z98c8s+7P3+e+2au++u8e2QTMB+f/37N+27 r8k40+s3sv50s48w++q++++X8+WL0uc7x+1eEe12u/eeeOLtttO22ei3U+eF8n122J9ntl02 /wDu79neNHHtundY2ZX/ACMj7+qjqi3/AEzv5cN9m+ua/H86PL/u8/5arv1bpWbZn/KH19qF 1YeK2kJ71ea00leW+8qVbtxzOfu77U/e1073rwnZLRs002/s8+re66IemIgu45my+cPL/8QA IBEAAgICAwADAQAAAAAAAAAAAREwQBAgACFQMUFRYP/aAAgBAwEBPxCNKoAAAXuACIAQQBIA AGAeA3yCoAAAA/hgBgAACAAAAAQAABHxnAAIhAIIjMwdIggBAGgPADuAAIaAwgJsIQABaj4g aggDCAhAYxCIABtOA8CccAtgr4AAWAAAB2AAE4AHIJQEA0IAjAEwIAHSBAIfjh8MAAIgAQQy eoUBEBhIAOQAKqAdZMGGkBLxgBi4AACIAHbIgYAAB0iwYhMFsOQDAYAO2wfRVA2Qnph7DhsY hcJDn//EACARAAEEAgMAAwAAAAAAAAAAAAEAESBAEDAhMVBBcaH/2gAIAQIBAT8QpgBEAD4D cYEwFwBAINUQAgQQAMUoEXQjCCYAReCVABBAAAxgKAoYt4AHZAALaICCAgPiAG8hAABAAiAV gBRYADhtEgEFgGABAthJEAQGETACARBGAjMDEAcCh+jHIxoiGDBAMyMLAGYPuiRDGQAAQABA AIASAtR3AAGrMCBAAAAswAQAABtNYAHgAAAEQxpEYAXQgAAo+BBfBAJEABAIECgg5ecgiIgQ AAAOAIAApMZhZGOktAAQACgggMwdcwAUB79GGBoc5pAEFBQAAGAgg0AFAAAEFgAB52kAAAUS AkYAYEOPcICEnMQA7UQCDAP54AUEABdF8KcK/8QAKRAAAQMEAQMEAwEBAQAAAAAAAQAQESAh MDFBQGGBUXGR8KHB8bFQ4f/aAAgBAQABPxBhAJvvL3nQrOhPJuyln0p/x7FY1LgLAwbXqDIr BKx1SYjKSYlAADoMQIYAAggCACILGUHVk1ILQUiUAookFcXR0ICoADi3NALAiIByRAWAEgRq IAYBRCHgUqDIo9gRGJWwe6CZBOp+JhSQLCvHiiBQEWBAIpi/9ChpdHgRGRAAn2IABOYCAI4Q CsoIBdAjABIAgwKCQzU4AgAAaMAIAiIQUhShNzGgAkCISBFCRCAVWSBAkIVF+IJUxEZBCBAo aSFUNZ0bZOVNFfwMQ4BRPSd1mt0LGfRSv4NAAYEM/cNgaPCQAwIQECGCLggRACIiCGjRQACB gQELBQYQkgJEdOQRMCQEBWA5flgMOMSSYCBAEBBAFAAUgoFgYQQhJZAbrqIKP2F/iPjeLG55 yir4hg/YEwuvwTZYWBiwXXCgQK2BBCEBIIKPJgSALbRAGMDEUdCAOhQQZYAKtGSAAAJqGHQA wABEEoYdQCUIocGBhAjGIPOYhSRiIFhIBjEcFBqAAQAmhoN1BJHGIBZC74CkIygOZRO/FBVi 9S/BNOAuQcDpHgEDAMOAKk7W2MIAn2UoAHpgAgAMbYJDhSUESBDRIMWRgAB0wBkgYLgGBIHj yxEkZo1adw5jhGszDA4WCB8egACIEpQkjAwgCFMKxbQGnAEhfYFDMS/NH1qlqrXgZiyiQ3GG jLFTKUIcQSj/AIYRAQIHwhRs1KIjAYgEYhmgBRAAIAt0hCIgkgCAIERAMAGKgYJEZR0ASUBA VgoIAAEBDRgZjIVlMhgEgAEcICjhCiEIxT2RC9detLa38FbonVR6o9hw2UcYaCKhiWQQZ1Ha wDEJ/wCQSnWVEAo8wCqKCiMAiyDIdIALIcIFMA2BogBXRwVACjcEADHQIEEAMKGSAjGG3ACL AACoBkAcwDFDaYmoshAVUKWWs9tCvOePMl4se9SYnzzpFjsqAYcWCYiYagQDDjUQNMAADwEW AAwCkxQjhDRCGESNBYgHsgkB9cwggGmQBEgQkCNAZQGBlFAUBHFKokKgQnQ4AYIAEYBgY6Ak qAIAGkVfIrdJsjYlHBnZrmS4KvinGrcUvdwhbLBIDIbyA4A5lchaVMExHSxKwEAgVy0D6AAA mRwRBBBENAiJBiAXACAF1RAEJ0CAWs4bUkJRleiBlkDAQYDWDjBIZ6IIGAAADbtdSt+hMX+l E+uMqT1USFRBvnoG6fg1hsIRzHAljsAUsRkAzBDAEcbrRCNNgARQIlAARHDCj8UMYGAcAIDJ AYWA1HAABeDDdFQAAADgBtCICATIABAcBCiADCQCAK4SEhEYggURTBV3VLQEyX100+5Us2oK aWIpgxCASVZJHVyIKE5FyLh9AxQYN1AGCWQ9RABhBOEE1kAEmxJI0YBRAAPUhEQVDFEML5BA KwgAABAQMUgAKRBSUSGopwEYhQAJiQcCESQIJAnhlSgahJxrn2XG+GnenCpQo+yV+KwAnY+V VQEEScQgw/OiDBaiAA5U5gxTQAFSAgEe6BtggibPZAAkEIAEiABIABgBACwIAEgwBUsCAxjg AHIMAEHCKAMqqBAowLiCA6lQELKDggQAVFY3RJoworUAIEAIhf8Aqy5uM2K2UsZLodvuqSED oMy4Ayg3BSI4oCWXAf8ANrYUAVRBgwQAG9huQDDTyyxEFxQAD2SFMALQiguAAAgAgpgUNgqh AZpAtFTgB5sgDIgAUYAoKMIBIgAOKAkO2Wc4ZgnxDJxIgcEEAqwUkMHCbQABBpAQBAyABzBF KgJhBKC+kranh7zcjnpF3NdBQ6qu5IKmDNoh5S22LHAsSAEEQPBAPwEDNhgUAhYlWUaGAZIB EADC8Egc5MgAg0PTAQDgFANkILbgAABuIUAABDEEIMUgCpWgAjGUxuQCCgCgXwYgBsCDiAGm kUJEVCkARPMQMc17Fovd8KzgHZOAtqjoLQxioRBTpwq4pKqysCIlMABeQARoAISBALggoNg2 PDjAHxaQAKajApBQHNGAL2IAADoDLwIAI4hAOQRAQQFJIVRqCkCSQaCAzIIIUICG7GbQoggj EFAAJBhoCAahAhiTMZ6n+1SVGUkpzN/qgYBBHoxONPChwYPCjbGeigfs4XIYQZcFB0EkgXi7 CBHJAAf84LUBAi8kIvTIgASCILgGCdgaIA6qRpkAFJGCo9ZYWAT0AKA0AHAIZhaaWgQVQ0EM gxAIiFcEqFlhI+EAA9AQCCEglDCEBmQ5G2q978q1LEPuMiNKTQQ0wIYX6zUlWC/ZiThplnQX A3Cp5h4ABCvABSSAAV2FAAMhEMCZgEABkiAAwQAVOGBA0JEgBCBAaMsACdDEAAq65VhqIhiA GgEIgBsCABPBAiIQAAAaACMcpi9RV7BAgVKMAYAwAwUhGgLQACoAgJr9m049MTP0FAJQ08ME aUmEP/PC80MXmVQIAQ/5FLGIC0QACgAVoGIsAwg5GsILJCRAwQEEggGxBFsBAIIGAAIQBdFU fAIgiQlcJBgACEMQDwQqMAVlZB/AAFEBADoegC4wJA+QCBMEAAAII8gN/RZIDdTCERBIFExZ iW2DPKbkfQqG7Jc3RneUJQQ/knMACqVCBCkAHEIGAD0/mBRoMsEGJBAJIASQDNCcAwhAKIBQ CEIAhoCAogEQIYAKwcKBVzgAAkcAGBjjDxhuwCAl9ZjAFF5gJo+gwUCMgjw7MBPrBMkLIHBo BAEkH+gy/eKMbtcAAQgjQFoFW4obNzK6yeoXK4WmqgcTERAohZnJMAoU6CABmDIAACgwNgoA FAEE0CC5CASoSGAIIgAIAMAAgAQQlEADNEiCrEAxA4KASQBBIlOIJadqt5LOAI0Zk2xRBC+I EiYWhALYLAF1SA8hoACjCEpBsSaAKgNDg87BUmILBAcSFIEUMAdIqF7MKFoAIMGyzKgaA80I AEEEACMMQBS6aGHAAtTIAGwCLwKAllTpLMYqKAREVAgBADiRkcBD6QD3uBb2MIVNdUK6UlcN 0BAMokA4cQiAN5xwoBkIOuGFoQAIAAkAFgBAVQUFNzHJYiD2rNRAG4ABA6Qmg2Kuf9KAkKPA mRspKSFgcBNAAMHmWQgR0cMAAqtIMgBczQACCCQcQQEDAEGjhAICDwA1AFk1gjFkTAVHX0HA qmFAJpzFALJZkDWDQA0FJkjvwuK46mkmDBAAAYChSGICQJCRP5EcPAAN8EIS0GwAAGgBIeIs IUBTBBaKDwF1habQQS8fhB5nZd8zDsIIAGggwBkAADNISAgyIMgACkIaEAAG1ESgQRAFZS1I LALKJBwJyfYF2azlJoAwR2+RAP2wgSTbCgAaI78UjBAMSAjfhhEANQw88IAFZHY5CDWRgABK QIaaBCJBFACiBhBftOFSFIKASjMghUAAiwCoKwgHvVtTsnXm9GGKQJDksIhBBALAKETgSABA BpiJBJI4IgeRg7Y1ERrxBDe31AA0iGUvsXtcBgBznL40AQ5DsK2goOOAKBhwWxQhGGdAlCLL Sth8YlBBimwjCEAEEDhBBSQFGB7DIkxJMq5KdIh9EQARGSEYD+HigDjQBOAcMAJ0oAAEQVgK owEkAIqDBEjYQwYIIASRFAyFUAEkN5AGWHFI5rgAKjk2gRX8M6bwbKJx6e4KVoJJCE1eF93b Ze8LUYEJIOADBQEAIiUQLOogSASxg0jyxdDqMDpiB4dQSGkMRLik8GZAQYKEQCJEUkmBQUoE hijCeMYqViDFJjAEAhrEAAUHJAAtbQSCWoeAtwMCSslwsq/Whb9/FGBZV3hT2tDTAENhgGyB AAiC1SSIKYgERgITDqDC4FCFSkQJwGKhQEsnTCEQwAKQJAAMBAi0Hq6gwhpQUDKA/cFFjiRE EMaYNgsADkAAiAI4B4oBAXX/ADEA1MxEBrIsgtgNHs0V3+LnS9XEMCqQABokAAGAX6ILKACg BQIZgAPD4xhXoCobAhkgLhaQmFNBLyCoKqALAB4OSgEiIEghIFSsKkJIFYFEwEGwUkKYL8TS FCGALDCiSFJVDNCKqgAFRoYAAVOwFZ5AgA2mEoBOQhFnEKEFqXstqoqNIACdYDREhAMLC/Rm Gh0gI0fAILAAwgBlzBrlCS6iQBPCRgYahgIiZAyiA6GgFqEQVFMGQagcKuCHZDAhgaCJBCBV 0NEEoIdJgaTKXIohQkHoYQBnDYZ0A8eLAXYo4AQbWAKQHQAMngEAkUDdKIs78mg6hg61pRAB hABzNcLwFR1SEVKMSiMCYGPswiw0AWIED2l7/QxETAAFlsq2QBMIBEAMEAJYAUQDJgIDnQAk hoLoGFILkAhBBhTBJCwhGiEAHFJKKyDIliWBBhCrFUkIAEkg1KAioFAM4gDIJIgAC8FA/X3A AFIyqrAOAh7oIK6sAnMAAE3vCmy9yPdQmRIEIhdiQAJA5NQAAWoo4CBnNsK5KhCbhQBiGKQE FQuAQrgDYAAKRgEGA/LDH4zCAkthATSTSagLVxwCEgkAhEIQgwBCECCDIDECLgAAOw0bARCI SEVQAFBgQwlQAQEDDlZKABDZBhkBaAEguACUcIECh0iwUCnIBjCGETo4BAAjsgEDc0ZgCoAe S4AkILAAJLAJwEf5iAHgNGDLAIAAAKjAf/AEQA239AZlLOADvehkAGeJADRZjAQCZrNGAk0U IXwTgBkbUolDDJAhKAg3ZCA/NaEjKIDhVJBhMQCaYgAAzSME6AiclCCRABBUCDiowNbCQIIg AF6EKCDCRAAIBYjQ8AYQNiCiAwCFMSWIUTmxtQAADVQIAwKwOEAHUCAB0IgKBOo7gALv2YNs FzABeBRBGALYDoAbUxiAsOdAQAMb4ZgAAS9dsIMI5Uwg7h+xkB5jGICG+kCAySoCDE0NTEgh EEBAC6YoAMVA9TSmYBykAKAAPp2kskInOYGD0oskZhmA4IMIcBjpcICCIIBG4QPBGgSwgAxj AFWOAwByo4AGgDogAAJwEA0giKGUEgRQyEWgGAWYgCQFIYyEkrQXckioigEQgAgGvC28YgEA ATBBAAVggwKiABIaoB0JwEO9CCABfhDwdJjWABpSVN4IzXnAAaTTIABk6QgKSERwQCoazxAA eNYgABAW0EAAgwEDj7rY+xFsWEMGQAaIkUCIAYDRAAAgEsgDWoD5C7FQEpCi6hfSZ4hgHYCm KAXKYgQaIAoaFBgoQgwkeJJsAt6GGSgQPFOAjDSmwADcKIAIbgAeGVIbCFQJIEAJKFcgpy9B JmEIoQ0GDSEgIqUggQH1xcEBY0CGljAmASQjgDbrQABHhIOggsiRR6ABAELo5Ag0bIaCiGeG kC+joDCBo7KAANCVsAQSNhKEDtpCAdrQN1MkDaysqJFEAhJoIALAhAmoUbaKMDZgfMn94VFC DkAqX3gEGxAwBQQKlBCAgoit9YAiIwDYIICa/qG0ChADSMQgAicYDqsDANEhQAAQbObDoAAR 4DAABoQWQlqMIJB1IFhMAzBAAhABZAMiyEEVAWJldwjpjrAgQQAwEMAEZxACKTUDxRMghASE QAHtVZAIJhKSCC7LpgCGqQBLoDIJwyugAEj9SQQJAQAAJFqCACAAYgIAwrgoAB0J4iAQRfGD SiCFCamIihCSoCmcI6mIABIIDEAhgI6oIHeZIEIgwAQkaaGBSYgBeAAEmA91CiWHpMh4wYAY LAhAHFCDAIMHkSIAKAmgACBgQpABpiiABQhKjMiznTgqxcBIAO0FkBgSuEQBCgIgGBkI4AEY /hgWSSCAcdhNBAwshIAB0SA5MMBAjYwgigYiAS0sWCAcqWCwACAAtgMlSECENgDXjL/A/FYk mABr3AgCQdaRAKYIUAQnzIR1EIPULBDDwBBwggEITBwQi4AEaMQmAYgOiOrZFAgfkAI0ABIo ElGTBApBEECAKRZbLZbeFqFp/wCIrSG8wAqSjIABK8eCAAvAiANAIwKB7EcuAgl8pAG4THQA aQAAMALCG4BJACAgEyEAag0AB/KrBEEHks7bNq5dMaRrWBJAL+YgVuyKaGZlJl9d6kIwSzbE QIlkeWxHwGh8lq2IBf1lDegEhVJajmjMT+DEVJtASSnZzTknlRuVsO6OghsIdhSD8KLtCwok yJUBcCNsLsCelHAQfZKKhUYMH5I57g5ThQt0IizbEdFnCn2Ww9lwXCKAWX7lR0C6AR0tihCc 8kjbCAOFd5cyUKA2jCKVjktkpwDCQ68CBwjuEYPC3ZRztXTyQPwwekUvFN0v55f/2Q== --------------7FD7DC945FCDA2EDCE6E7498-- --------------3DAB2DC0274E0376CC235A4C-- From nobody Wed May 4 00:04:31 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49AB12D1A4 for ; Wed, 4 May 2016 00:04:29 -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_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 5YzGgBNQNpDJ for ; Wed, 4 May 2016 00:04:23 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 1DCF112D5D6 for ; Wed, 4 May 2016 00:04:23 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 37EB550A87 for ; Wed, 4 May 2016 03:04:22 -0400 (EDT) To: "urn@ietf.org" From: Sean Leonard Message-ID: <068db851-f0e8-0838-3916-4850e28f9e00@seantek.com> Date: Wed, 4 May 2016 00:04:25 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] Three small editorial nits in rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 07:04:29 -0000 Three small editorial nits in rfc2141bis-urn-16. (Cf. [RFC1738]) (page 2) has capital Cf. instead of cf. and two spaces instead of one space. I suspect a tool problem. but it's still a problem. Section 6.3, Item 2: "represenative(s)" -> "representatives" (I prefer you just use plural, but in any event, it's misspelled) Section 6.4.6: "handilng" -> "handling" Sean From nobody Wed May 4 00:17:24 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C1412D09B for ; Wed, 4 May 2016 00:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 oy7BE3IgJ6qu for ; Wed, 4 May 2016 00:17: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 A0FC612B038 for ; Wed, 4 May 2016 00:17:20 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1axr3f-000NbC-J6; Wed, 04 May 2016 03:17:19 -0400 Date: Wed, 04 May 2016 03:17:14 -0400 From: John C Klensin To: Sean Leonard , urn@ietf.org Message-ID: In-Reply-To: <068db851-f0e8-0838-3916-4850e28f9e00@seantek.com> References: <068db851-f0e8-0838-3916-4850e28f9e00@seantek.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.10 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] Three small editorial nits in rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 07:17:22 -0000 --On Wednesday, May 04, 2016 00:04 -0700 Sean Leonard wrote: > Three small editorial nits in rfc2141bis-urn-16. > > (Cf. [RFC1738]) (page 2) has capital Cf. instead of cf. and > two spaces instead of one space. I suspect a tool problem. but > it's still a problem. Style manuals differ on whether "cf." should or should not be capitalized in that context. Unless others feel really strongly about this, I'm inclined to leave it (and all similar things) for the RFC Editor to apply whatever stylistic rules they find appropriate. The two spaces are, indeed. a tools issue. Please take it to the XML2RFC list and/or, check the AUTH48 copy and remind the RFC Editor. > Section 6.3, Item 2: "represenative(s)" -> "representatives" > (I prefer you just use plural, but in any event, it's > misspelled) Fixed in -17 working draft.. > Section 6.4.6: "handilng" -> "handling" Already fixed in -17 working draft, presumably due to earlier or offlist comments. thanks, john From nobody Wed May 4 04:23:52 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB8012D51C for ; Wed, 4 May 2016 04:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 k1HVGH64QYNc for ; Wed, 4 May 2016 04:23:47 -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 A4BB112D1E8 for ; Wed, 4 May 2016 04:23:46 -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 u44BNVvT007803; Wed, 4 May 2016 12:23:31 +0100 (BST) 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 u44BNT0i002260; Wed, 4 May 2016 12:23:30 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id u44BNTfX011747; Wed, 4 May 2016 12:23:29 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id u44BNRvE011744; Wed, 4 May 2016 12:23:27 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: John C Klensin References: <3e02d08d-9f0d-56af-5240-caecd7d01419@seantek.com> <790A858BDF9234D27BA953CC@JcK-HP8200.jck.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 04 May 2016 12:23:27 +0100 In-Reply-To: <790A858BDF9234D27BA953CC@JcK-HP8200.jck.com> (John C. Klensin's message of "Tue\, 03 May 2016 18\:06\:00 -0400") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (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] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 11:23:50 -0000 John C Klensin writes: > --On Tuesday, May 03, 2016 12:36 -0700 Sean Leonard > wrote: > >>... >> The limit of 30 characters for NID does not have much >> justification. If someone wants to register >> someextremelylongNIDbecausetheyfeellikeitandsoforth, who >> cares? It's not a resource exhaustion issue. > > Actually, one of the things I learned when I was working with > human factors psychologists in a prior life is that there is a > reason . . . I guess my view is this kind of limit is the wrong response to that kind of issue. My preference is not to try too hard to protect people from themselves, particularly if doing so puts hard barriers in place which some unforeseen downstream users may have good reason to be frustrated by. I also note that it would be entirely appropriate for the Expert Reviewer to recommend reconsideration of egregiously unmemorable or difficult to distinguish NIDs in their reviews, and a _recommendation_ in favour of short and distinctive NIDs in the spec would be a good thing. But, I did classify this as minor, and I certainly won't lie down in the road over it. 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 Wed May 4 06:19:27 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F74012B046 for ; Wed, 4 May 2016 06:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 CpP8zvziMnw8 for ; Wed, 4 May 2016 06:19:24 -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 A6FD312B03D for ; Wed, 4 May 2016 06:19:22 -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 u44DJ6k5011266; Wed, 4 May 2016 14:19:11 +0100 (BST) 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 u44DJ6BN017315; Wed, 4 May 2016 14:19:06 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id u44DJ6Mv018649; Wed, 4 May 2016 14:19:06 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id u44DJ5Ed018648; Wed, 4 May 2016 14:19:05 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: John C Klensin References: <383E74C93A059E95C9B5A4E7@JcK-HP8200.jck.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 04 May 2016 14:19:05 +0100 In-Reply-To: <383E74C93A059E95C9B5A4E7@JcK-HP8200.jck.com> (John C. Klensin's message of "Tue\, 03 May 2016 18\:07\:08 -0400") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (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, Sean Leonard Subject: Re: [urn] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 13:19:27 -0000 John C Klensin writes: > --On Tuesday, May 03, 2016 18:14 +0100 "Henry S. Thompson" > wrote: >> ... >> Section 2.3.1, para 1 >> >> (requested) service >> >> "The q-component is intended for passing parameters to either >> the named resource or a system that can supply the requested >> service, for interpretation by that resource or system." >> >> This is the first use of the word 'service' since section 1.1, which >> reads to me as only defining _resolution_ services, which are >> explicitly ruled out in this case by the immediately following >> parenthesis. >> >> Aside from the case of "services associated with the namespace" which >> occurs in 6.4.1 item 5, all other uses of the word 'service' in the >> spec either clearly (and usually explicitly) refer to resolution >> services, or are about non-URN-related services altogether. >> >> In contexts I'm familiar with, the 'Resource' in 'URI' covers >> anything and everything that might be identifiable, from the easy >> (what TimBL calls "information resources") to the ineffable (the >> weather in Oaxaca), the imaginery (unicorns) and the abstract >> (democracy), and certainly including services. So I'm unsure what >> the distinction is that you're trying to get at here. Particularly >> as in practice any actual response to the use of a URN comes from >> some system, so making a distinction between passing a parameter to a >> resource vs. to a service seems to me a distinction without a >> difference. > > The addition went in because the use of "resource" seemed to set > off arguments, particularly about whether abstract designators > were actually required to designate something, such as a > whatever-a-resource-is. Note that we do not, at least so far, > have a restriction on q-components being associated with > abstract designators. My reading of 3986 suggests that one > cannot have a fragment with an abstract designator because > fragments require no only that one retrieve and interpret a > resource (or, more specifically, a "potentially retrieved > representation"), but that the resource have a media type. If > you think that distinction needs clarification, please suggest > text. And, unless you can convince the WG that "service" should > be dropped, I'm certainly open to other choices of wording. And John also wrote, on Tue, 03 May 2016 18:06:00 -0400 in reply to Sean > See my response to Henry but also note that what 3986 appears to say > (and how he interprets it if I correctly understood his note) is that > "resource" can refer to very nearly anything. Meaning exactly what > 3986 says would require that 3986 be a great deal more specific than > the entirely circular definition of 3986 which reads "This > specification does not limit the scope of what might be a resource; > rather, the term "resource" is used in a general sense for whatever > might be identified by a URI." followed by some examples and general > comments. I think there's a misunderstanding here about the word 'resource' as used in 3986 and other writings (e.g. the W3C TAG'S AWWW [1]). It cannot be understood as naming a pre-existing natural kind, some sub-category of all the possible categories, some node in a universal complete taxonomy. There is no set of tests which can be performed on some candidate for membership in the set of resources _in terms of properties local to said candidate_ which will determine whether or not it is in fact a resource. The point of the above-quoted definition from 3986 is to establish 'resource' as a convenience term of art, a shorthand for "that which is identified by [this/some] URI". In a previous century we would have used _identificandum_. The ordinary language word 'referent' is an illuminating non-technical parallel case: no examination of an object will allow you to tell whether it is a referent or not: truthfully labelling something a referent simply requires that some word or expression has been used to refer to it. (It's perhaps worth noting a further parallel: Contesting such a labelling requires appealing to the person who produced the referring word or expression: when you said such-and-such, what did you mean to refer to? And as far as 3986 is concerned, the same is true for URIs: the ultimate authority for questions about what is identified by a URI is, and can only be, the minter of that URI.) It follows, I think, that urnbis can use 'resource' in exactly the way it is used in 3986, referencing 3986 for that purpose in section 1.1. Indeed it _should_ do so, because otherwise it does what it accuses 3986 of doing, only more so, by using both 'resource' and 'service' without defining them, or explaining how to tell which of the two is identified by a URN. ht [1] https://www.w3.org/TR/webarch/ PS The fact that 3986 doesn't come particularly clean about how one might in principle answer questions of the form "What is identified by this URI" or "Can I use this URI to identify [...]" is arguably a bug. urnbis is in a particularly good position to fix this for URNs. Something to address such questions for URNs should, I suggest, be added to the list of requirements on namespace definers. -- 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 Wed May 4 06:42:51 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CE712D112 for ; Wed, 4 May 2016 06:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 leVOuPUeXInM for ; Wed, 4 May 2016 06:42:47 -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 D00C312D0F4 for ; Wed, 4 May 2016 06:42:46 -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 u44DgJcA024348; Wed, 4 May 2016 14:42:20 +0100 (BST) 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 u44DgJMh018622; Wed, 4 May 2016 14:42:19 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id u44DgJvC020101; Wed, 4 May 2016 14:42:19 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id u44DgJU0020100; Wed, 4 May 2016 14:42:19 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: John C Klensin References: <383E74C93A059E95C9B5A4E7@JcK-HP8200.jck.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 04 May 2016 14:42:19 +0100 In-Reply-To: <383E74C93A059E95C9B5A4E7@JcK-HP8200.jck.com> (John C. Klensin's message of "Tue\, 03 May 2016 18\:07\:08 -0400") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (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] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 13:42:50 -0000 John C Klensin writes: > My reading of 3986 suggests that one cannot have a fragment with an > abstract designator because fragments require no[t] only that one > retrieve and interpret a resource (or, more specifically, a > "potentially retrieved representation"), but that the resource have a > media type. If you think that distinction needs clarification, please > suggest text. A different reading is widely shared, and heavily relied on by a substantial part of the Semantic Web. Indeed I think 3986 explicitly contradicts what you say: "The semantics of a fragment identifier are defined by the set of representations that _might_ result from a retrieval action on the primary resource. The fragment's format and resolution is therefore dependent on the media type [RFC2046] of a _potentially_ retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. If _no such representation exists_, then the semantics of the fragment are considered unknown and are effectively unconstrained." [1], emphasis added Note further that 3986, for better or worse, is careful to distinguish representations from resources: resources are what a URI identifies, representations are what you can retrieve using a URI. They are not the same. Resources don't have media types, representations do. I read the above quote from 3986 as studiously _allowing_ precisely what I understand you to want, namely, that for abstract designators (that is, URNs for which no resolution service is provided or envisaged) the interpretation of a fragment identifier is unconstrained _by 3986_. Having said all that, I'm not sure this has any bearing on the point at issue, which was the 'resource'/'service' distinction. ht [1] https://tools.ietf.org/html/rfc3986#section-3.5 -- 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 Wed May 4 07:07:23 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5228612D67D for ; Wed, 4 May 2016 07:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 yV3dpR-NZqp5 for ; Wed, 4 May 2016 07:07:20 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 D38E512B060 for ; Wed, 4 May 2016 07:07:20 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F36D650A86 for ; Wed, 4 May 2016 10:07:19 -0400 (EDT) References: <383E74C93A059E95C9B5A4E7@JcK-HP8200.jck.com> To: urn@ietf.org From: Sean Leonard Message-ID: <2dc60ca4-131e-1bb0-1dbf-07db83766972@seantek.com> Date: Wed, 4 May 2016 07:07:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 14:07:22 -0000 On 5/4/2016 6:19 AM, Henry S. Thompson wrote: > [...] > (It's perhaps worth noting a further parallel: Contesting such a > labelling requires appealing to the person who produced the referring > word or expression: when you said such-and-such, what did you mean to > refer to? And as far as 3986 is concerned, the same is true for URIs: > the ultimate authority for questions about what is identified by a URI > is, and can only be, the minter of that URI.) > > It follows, I think, that urnbis can use 'resource' in exactly the way > it is used in 3986, referencing 3986 for that purpose in section 1.1. > > Indeed it _should_ do so, because otherwise it does what it accuses 3986 > of doing, only more so, by using both 'resource' and 'service' without > defining them, or explaining how to tell which of the two is identified > by a URN. +1. This. > PS The fact that 3986 doesn't come particularly clean about how one > might in principle answer questions of the form "What is identified by > this URI" or "Can I use this URI to identify [...]" is arguably a bug. > > urnbis is in a particularly good position to fix this for URNs. Yes. Sean From nobody Wed May 4 07:43:52 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F84512D501 for ; Wed, 4 May 2016 07:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 7QfozYpcWffd for ; Wed, 4 May 2016 07:43:45 -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 5C1AC12B032 for ; Wed, 4 May 2016 07:43:17 -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 u44Eh1Gi003026; Wed, 4 May 2016 15:43:06 +0100 (BST) 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 u44Eh18P021394; Wed, 4 May 2016 15:43:01 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id u44Eh0qv023828; Wed, 4 May 2016 15:43:00 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id u44Eh0Jv023827; Wed, 4 May 2016 15:43:00 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: John C Klensin References: <383E74C93A059E95C9B5A4E7@JcK-HP8200.jck.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 04 May 2016 15:43:00 +0100 In-Reply-To: <383E74C93A059E95C9B5A4E7@JcK-HP8200.jck.com> (John C. Klensin's message of "Tue\, 03 May 2016 18\:07\:08 -0400") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (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] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 14:43:49 -0000 John C Klensin writes: > --On Tuesday, May 03, 2016 18:14 +0100 "Henry S. Thompson" > wrote: >> ... >> Section 3.1 [also signalled earlier at 2.3.1 para 5] >> >> "For various purposes such as caching, it is often desirable >> to determine if two URNs are 'the same'." >> >> ... >> >> "If a q-component, r-component, or f-component (or any >> combination thereof) are included in a URN, they MUST be >> ignored for purposes of determining equivalence." >> >> These two seem in contradiction to one another, at least >> insofar as q- and probably r-components are concerned. Surely >> for caching purposes distinct q-components must mean >> inequality? Otherwise asking for my booking to Amsterdam >> might get me your booking for New York, if I made the request >> via a URN for a flight-booking service including surname and >> booking ID via q-parameters, sent to a service that does the >> q-conversion and URL-fetching itself. . . >> >> But I realise there's been a _very_ long discussion history >> about this issue, and thus it not be one you want to re-open. >> At the very least, however, I think you need to call out the >> downside wrt caching, in some kind of "your gun, your foot, >> your bullet" note. > Text would be welcome. Personally, I can argue either way for > including (or excluding) q-components and/or r-components from > equality comparisons, but, as you note, the WG has been around > that loop several times. I'll leave it up to the WG Co-Chairs > whether reopening it is reasonable. One way or the other please > note that 2141bis inherits two equality-testing problem from > 3986: until one understands the details of the resource (sic) > and, in the URN case, the namespace, one cannot prove equality > (or, for that matter, inequality). Indeed, and 3986 explicitly acknowledges the impossibility of such proof. It accordinly goes on to establish the goal of section 6.2 [2] as analysing the trade-off between false-negative rates (for string-based tests) and computational effort, on the basis that e.g. for caching it's false negatives that are wasteful, and therefore worth _some_ effort to avoid. Note further that 6.1 [1] includes a claim that the methods defined in 6.2 "strictly avoid... false positives", which I believe is in fact the case. > As far as I can tell, Section 6 of 3986 does not discuss the > application of queries in comparisons even though it explicitly > excludes fragments. The exclusion of fragments makes sense (in the stated context of (potential) retrieval), because e.g. HTTP mandates that frag-ids are stripped before GET requests are issued (consistent with their retrieved media-type dependence). I read the _absence_ of any _other_ exclusion as pretty definitively _including_ the query-string in the comparison, since we're talking about URI comparison, and the production for URI includes the query-string. And the desire to avoid false positives, per my example above, seems like a likely explanation for that. Also note the following: "The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to _identify a resource_ within the scope of the URI's scheme and naming authority (if any)." [3], emphasis added So queries are part of a URI's identification function, and it follows that syntax-distinct queries _may_ identify different URIs, so for the avoidance of false positives they must be included in any comparison. All of which leaves me perplexed as to why the WG has declined to treat the q-component as part of the identifying function of a URN, but, as you said, it's up to the co-chairs to re-open this if they choose. I note that _with respect to 3986_, the q-component _is_ a query (as is the r-component, if it comes first), and so any _generic_ URI processor will include it in its comparison algorithms. I'm not sure whether this is obliquely recognised by the following in the first para of 3.1: If comparisons are made in a scheme- independent way, i.e., as URI comparisons only, URNs that this specification considers equal would be rejected. That is, for my air-travel example, 3986-compliant web browsers that follow the example in 3986 and pick Syntax-Based Normalization [4] to determine link-colouring would _not_ colour a link to urn:example_airtix:booking?=surname=Thompson&id=xyzzy differently before/after a visit to urn:example_airtix:booking?=surname=Klensin&id=zyxxz, whereas per urnbis as it stands a urn:-aware tool, which chose Scheme-Based Normalization [5], _would_ do so. >> [Suggested edits] would be welcome Replace the existing final two sentences of para. 1 of section 3.1 (the one quoted above and the one following) with: If comparisons are made in a scheme-independent way, that is, using the Simple String Comparison or Syntax-Based Normalization steps on the Comparison Ladder defined in section 6.2 of [3986], URNs that this specification considers equal will compare as not equal. Although such an approach may be appropriate for generic URI-level processing, as for example when a browser checks its history to color link text or a cache is probed for a locally-available retrieval response, for URN-specific tasks such as [fill in some credible example here, I can't think of one], a stronger equality standard is desirable. Accordingly there follows below a specification of what [3986] calls Scheme-Based Normalization, which may be the preferred comparison approach when the URIs involved are known to be URNs. ht [1] https://tools.ietf.org/html/rfc3986#section-6.1 [2] https://tools.ietf.org/html/rfc3986#section-6.2 [3] https://tools.ietf.org/html/rfc3986#section-3.4 [4] https://tools.ietf.org/html/rfc3986#section--6.2.2 [5] https://tools.ietf.org/html/rfc3986#section--6.2.3 -- 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 Wed May 4 09:34:30 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F45312DAC8 for ; Wed, 4 May 2016 09:34:29 -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_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 Cp8t2us-JDrB for ; Wed, 4 May 2016 09:34:28 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 CDFCF12DAD9 for ; Wed, 4 May 2016 09:23:41 -0700 (PDT) Received: from [192.168.0.123] (unknown [66.14.164.195]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id EC05822E253 for ; Wed, 4 May 2016 12:23:34 -0400 (EDT) From: Sean Leonard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <74694317-F420-4867-A850-86153169DD70@seantek.com> Date: Wed, 4 May 2016 09:23:49 -0700 To: urn@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [urn] Review of rfc2141bis-16 and semantics-clarif-03, Part 1 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 16:34:29 -0000 I have reviewed draft-ietf-urnbis-rfc2141bis-urn-16 and = draft-ietf-urnbis-semantics-clarif-03. Here is concise feedback. (It is = intended to be my opinion, rather than a neutral summary. But my opinion = takes into account the other expressed opinions over the years in this = WG.) Stuff I hope we can agree on: Syntactically, a URN is a URI that has a =E2=80=9Curn=E2=80=9D scheme. = It has the URI=E2=80=99s path-rootless production only. It=E2=80=99s not = specific to any location on the network. It has a path (p-component), = query (q-component and r-component), and fragment (f-component). The fragment behaves the way it does with RFC 3986. When a urn: URI is = successfully dereferenced, everything up to # is taken, and a resource = representation (hopefully with some media type) is returned. Then a = client can deal with the fragment part. Since it=E2=80=99s possible that = a resource representation doesn=E2=80=99t exist, the fragment is = *unconstrained* (using Henry Thompson and RFC 3986=E2=80=99s terms), = rather than undefined. The path is the p-component and that includes the NID and the NSS. The = NSS can contain =E2=80=9C/=E2=80=9D; it cannot contain =E2=80=9C?=E2=80=9D= or =E2=80=9C#=E2=80=9D. The NSS is UTF-8 percent-encoded. The NID = (registration) says how the NSS is formatted and how names get generated = & assigned. This part is unique, persistent, etc. The query (r-component, q-component) is NOT part of the unique, = persistent, etc. guarantees. It=E2=80=99s *not* part of the =E2=80=9Cname=E2= =80=9D. It=E2=80=99s separate information that is sent to URN services = to help resolve and/or dereference the pieces into a resource. It can = contain =E2=80=9C?=E2=80=9D; it cannot contain =E2=80=9C#=E2=80=9D. Stuff inconsistent with these statements, needs to be removed from the = draft(s). Stuff that is expressed in more words than above, can be = simplified to the words above. *** Stuff that is controversial or that the WG is still struggling to = conclude: How much to specify how the query production (r-component, q-component) = works. This includes ABNF and syntactic issues. How much =E2=80=9Csemantically=E2=80=9D URNs are URIs. These will be covered in Part 2. Additionally: What =E2=80=9Cresources=E2=80=9D versus =E2=80=9Cservices=E2=80=9D are. = -- now has its own active thread =E2=80=9CEquivalence=E2=80=9D issues. -- also has its own active thread Sean= From nobody Wed May 4 09:37:14 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D089F12DB0F for ; Wed, 4 May 2016 09:37: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_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 HrNY0-1RSUT7 for ; Wed, 4 May 2016 09:37:12 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 4630812DC8C for ; Wed, 4 May 2016 09:26:41 -0700 (PDT) Received: from [192.168.0.123] (unknown [66.14.164.195]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1CDF322E253; Wed, 4 May 2016 12:26:39 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: <231532ef-e195-b73d-4a34-eb445bdd1900@gmx.de> Date: Wed, 4 May 2016 09:26:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <802EB6EE-14F6-4CA0-8D83-1B7BB4C86F74@seantek.com> References: <231532ef-e195-b73d-4a34-eb445bdd1900@gmx.de> To: Julian Reschke , "urn@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [urn] Feedback on draft-ietf-urnbis-semantics-clarif-03 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 16:37:14 -0000 Quick question on this feedback: > On Apr 27, 2016, at 8:02 AM, Julian Reschke = wrote: >=20 > Hi there, >=20 > I was asked off-list to review the current drafts, given my interest = in RFC 3986 in the past. >=20 [...] > Appendix A. Background on the URN - URI relationship >=20 > The Internet community now has many years of experience with both > name-type identifiers and location-based identifiers (or = "references" > for those who are sensitive to the term "identifier" such as many > members of the library and information science communities.. The >=20 > s/.././ >=20 > primary examples of these two categories are Uniform Resource Names > (URNs [RFC2141] [RFC2141bis]) and Uniform Resource Locators (URLs) > [RFC1738]). That experience leads to the conclusion that it is > impractical to constrain URNs to the high-level semantics of URLs. > The generic syntax for URIs [RFC3986] is adequately flexible to > accommodate the perceived needs of URNs, but the specific semantics > associated with the URI syntax definition -- what particular > constructions "mean" and how and where they are interpreted -- = appear > to not be. Generalization from URLs to generic Uniform Resource > Identifiers (URIs) [RFC3986], especially to name-based, high- > stability, long-persistence, identifiers such as many URNs, has > failed because the assumed similarities do not adequately extend to > all forms of URNs. Ultimately, locators, which typically depend on > particular accessing protocols and a specification relative to some > physical space or network topology, are simply different creatures > from long-persistence, location-independent, object identifiers. = The > syntax and semantic constraints that are appropriate for locators = are > either irrelevant to or interfere with the needs of resource names = as > a class. That was tolerable as long as the URN system didn't need > additional capabilities (over those specified in RFC 2141) but > experience since RFC 2141 was published has shown that they are, in > fact, needed. >=20 > I don't believe this appendix is way too vague to be helpful. I am confused by this sentence. Is that a typo? Are you saying that this = Appendix is too vague to be helpful, and therefore should be removed? Or = are you saying it is not too vague; it is helpful; therefore, keep it in = the draft? Sean From nobody Wed May 4 09:43:37 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C14812DA99 for ; Wed, 4 May 2016 09:43: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_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 23mtrOJEL14U for ; Wed, 4 May 2016 09:43:31 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 55B8112DAAF for ; Wed, 4 May 2016 09:32:41 -0700 (PDT) Received: from [192.168.0.123] (unknown [66.14.164.195]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2DC3E22E255; Wed, 4 May 2016 12:32:37 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: <790A858BDF9234D27BA953CC@JcK-HP8200.jck.com> Date: Wed, 4 May 2016 09:32:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3e02d08d-9f0d-56af-5240-caecd7d01419@seantek.com> <790A858BDF9234D27BA953CC@JcK-HP8200.jck.com> To: John C Klensin X-Mailer: Apple Mail (2.3124) Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 16:43:32 -0000 > On May 3, 2016, at 3:06 PM, John C Klensin wrote: >=20 >> ... >>> But I realise there's been a _very_ long discussion history >>> about this issue, and thus it not be one you want to re-open. >>> At the very least, however, I think you need to call out the >>> downside wrt caching, in some kind of "your gun, your foot, >>> your bullet" note. >>=20 >> +1, I agree. That part "MUST be ignored for purposes of >> determining equivalence", need to be something like: >> "MUST be ignored for purposes of determining name equivalence" >> or some other magical term. The point is that urn:nid1:obj2 >> and urn:nid1:OBJ2?foo#baz identify the same Uniform Named >> Thing (if nid1 namespace says case-insensitive), but they may >> well not return the same representations when >> URI-dereferenced. "Equivalence" in URIs also depends on what >> you mean by equivalence, i.e., how deep you are looking. There >> are multiple kinds of equivalence. >=20 > Need advice from the WG Chairs on whether or not this topic > should be reopened. I have no strong preference about what the > spec should say other than that we not go around in circles > about it for more months. Just call it something else. Other than naked =E2=80=9Cequivalence=E2=80=9D= . Calling it =E2=80=9Cequivalence=E2=80=9D without calling it something = else or adding some qualifier to say what kind of equivalence the = document is talking about, is confusing. Henry and I already independently pointed out that it is a kind of = Scheme-Based Normalization (see = ). Sean= From nobody Wed May 4 10:04:56 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4627312D9EC for ; Wed, 4 May 2016 10:04:47 -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_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 jxOF7R1oAbBL for ; Wed, 4 May 2016 10:04:45 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 045F812DA24 for ; Wed, 4 May 2016 10:01:11 -0700 (PDT) Received: from [192.168.0.123] (unknown [66.14.164.195]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AFB6822E259 for ; Wed, 4 May 2016 13:01:03 -0400 (EDT) From: Sean Leonard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <2B6D2EED-886B-47C8-BCAC-6E92A5827A38@seantek.com> Date: Wed, 4 May 2016 10:01:15 -0700 To: urn@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [urn] Review of rfc2141bis-16 and semantics-clarif-03, Part 2 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 17:04:47 -0000 Stuff that is controversial or that the WG is still struggling to = conclude: **** How much to specify how the query production (r-component, q-component) = works. This includes ABNF and syntactic issues. Distinguishing between r-component and q-component served an important = and commendable function during the development of this draft. It is no = longer useful. The struggles with q-component reflect that it=E2=80=99s impossible to = implement something useful with it. I therefore urge the group to drop = q-component entirely. Syntactically, =E2=80=9C?+=E2=80=9D and =E2=80=9C?=3D=E2=80=9D have been = proposed. These will not work. If q-component is based on another URI = scheme (which, inevitably, it will be), it *can* contain =E2=80=9C?+=E2=80= =9D and that will cause an URN parser to switch to r-component. It is = ambiguous and insecure. I have tried implementing it already. I don=E2=80=99t see what the obsession is with making the order of = r-component and q-component interchangeable. The only way to avoid this = parsing fiasco is to put r-component first, and to restrict r-component = so that it *never* can contain the escape sequence to q-component (e.g., = if a second =E2=80=9C?=E2=80=9D delimits q-component, make sure = r-component *never* contains =E2=80=9C?=E2=80=9D). Semantically, q-component makes no sense, especially when r-component is = around. If a URN resolver service (because it=E2=80=99s a service, not a = resource) is going to take a crack at the URI string, it can return = resource representation(s) itself, or in some hypothetical formulations, = can return URLs. In the former case, the q-component is ignored, so you = may as well not put it in, in the first place. In the latter case, you = don=E2=80=99t know what the URL is going to be when writing the URN, so = appending q-component arbitrarily to the end of whatever is returned, = isn=E2=80=99t going to make any sense. Maybe the URL already has a query = production; maybe not; maybe stuff gets double-specified. Make the RFC 3986 query production =3D=3D=3D r-component. The = =E2=80=9Cresolvers=E2=80=9D or =E2=80=9Cresolution services=E2=80=9D of = the URN gets to see the entire query production. Regarding the inner syntax and semantics of r-component: I have made my = case for a resolver operation identifier, a reg-name, and name/value = parameter pairs. resolverID got picked up (in mutilated form) in -15, = then dropped in -16. It is satisfactory to me to punt on further specifying r-component in = rfc2141bis in order to get this done, provided that a new Internet-Draft = be created that attempts to specify it. I can supply initial text. Juha = Hakala has expressed that specification is needed for development = projects in the library community. = **** How much =E2=80=9Csemantically=E2=80=9D URNs are URIs. URNs are URIs. RFC 3986 URIs can identify principles and abstract ideas. = A URI can point to a (potentially unbounded) family of resource = representations, or none at all. How the path and query components work = is scheme-specific. So, URN can say that the query production doesn=E2=80=99= t *name* the resource (the name for which, in the path production, is = persistent and unchanging); it just helps resolvers with returning = particular resources & representations. This is consistent with the URI = framework. Pontificating was useful for a time, but to get these drafts done, = pontification ought to be removed from rfc2141bis-16 and = semantics-clarif-03. This means dropping publishing semantics-clarif = entirely, and simplifying/clarifying rfc2141bis itself. **** Sean From nobody Wed May 4 10:41:00 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7F712D1E5 for ; Wed, 4 May 2016 10:40:59 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 UDaPdITdu9-v for ; Wed, 4 May 2016 10:40:57 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3468012D8F9 for ; Wed, 4 May 2016 10:40:53 -0700 (PDT) Received: from [192.168.178.20] ([93.217.79.215]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lmvlg-1badP22I9s-00h2tU; Wed, 04 May 2016 19:40:48 +0200 To: Sean Leonard , "urn@ietf.org" References: <231532ef-e195-b73d-4a34-eb445bdd1900@gmx.de> <802EB6EE-14F6-4CA0-8D83-1B7BB4C86F74@seantek.com> From: Julian Reschke Message-ID: Date: Wed, 4 May 2016 19:40:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <802EB6EE-14F6-4CA0-8D83-1B7BB4C86F74@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:AVK56FfO5HR3meqJVI/+tKXS4A1NEiBR2OaGvY9yxJJitH/PCrg y9BK24uqfiE4o4IZJ5+IqpWQHCCNzu3Kg2ljG7EdU6EOTwNyiGQICtTlm6x1Jt4nlRbqcua uUKqx5XUFDd/h8hHFX1i5ka4PuYXrf2v9yfNWUl96oTUEsoVnLiIaLaH/cipKIrDIAG2aFa u7SWW14J/o//qh4j/3ggA== X-UI-Out-Filterresults: notjunk:1;V01:K0:BvuytsuGmKM=:D/k5S7iabBih6u80Y3hVLw DFwbo/8bP8lyTIQFMpJe6rM63YDBSraG78VcH29HB90qNBV+c94Ula5dcX6kJJBN4jX5IxUFj NHPtyh/EHvwmTZxlTFJ22fLG1iBEJ33sUGifo/RpCgUJo/F2Us4/LhZ+A9iTieQF3abYgkdbj PU0pn52/E7tYWlzGhSbtCOBZOOf0t7pioMECM65zCxhmZZCQSh5caYfjdyX61CEZIl1vbmwW0 x6QtX3WRJBlmdsJ4cqRnG9ja5AbiPsaTquMP+/nMyVyN6O4bz2kz0oMHPpmKN9JSuBo7pjj/M VjFo8Pv4CbjdmyQNdE6FZ8hPHZLX4QAWba7L7SMnoSQ8W8zydkRvHSQmjFnU+o3PUVSCbuWcn XqhWlAZD3v4ky86/CH77tf3hK9574WZT4a2Q5UQTfMf6V0oQr22VBwjTBG1SalCq8h4XK3kEo MYYp1hA4ig6ZshIpktwC9MB5UUNgiiC5CucdSxaLUDsKwpEiQ6J3O4E0SRKhrYObTEtY4RQGU qwmC7k4ucJR+9it6+FJoK5ZcCKY4lbPulOFCZ37TX2JOGlpV7+empo6FbaigG6Wd5SMozgaGZ NIn6aFwV+zqShDsI6X2rGVFL4SHvgYO3pUeai+P928Zf7p18rGrUXXsCaCI7LRDjNmHQ6a+gc nQ1pgq0lCIER8qvtCCJj9E3Vz5cU+hoJcy/WaEhe9sduwBaGbhb3ZmvXocJTKes6jLTf0Pd+2 ZqHxtFVy1DndbhrcFfEd690gE6BuxVhtge3lND2wVdxFddbQKd4lf+bMB3OS8qsICv/CN+EFX tSV7Et1 Archived-At: Subject: Re: [urn] Feedback on draft-ietf-urnbis-semantics-clarif-03 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 17:41:00 -0000 On 2016-05-04 18:26, Sean Leonard wrote: > Quick question on this feedback: > >> On Apr 27, 2016, at 8:02 AM, Julian Reschke wrote: >> >> Hi there, >> >> I was asked off-list to review the current drafts, given my interest in RFC 3986 in the past. >> > [...] > >> Appendix A. Background on the URN - URI relationship >> >> The Internet community now has many years of experience with both >> name-type identifiers and location-based identifiers (or "references" >> for those who are sensitive to the term "identifier" such as many >> members of the library and information science communities.. The >> >> s/.././ >> >> primary examples of these two categories are Uniform Resource Names >> (URNs [RFC2141] [RFC2141bis]) and Uniform Resource Locators (URLs) >> [RFC1738]). That experience leads to the conclusion that it is >> impractical to constrain URNs to the high-level semantics of URLs. >> The generic syntax for URIs [RFC3986] is adequately flexible to >> accommodate the perceived needs of URNs, but the specific semantics >> associated with the URI syntax definition -- what particular >> constructions "mean" and how and where they are interpreted -- appear >> to not be. Generalization from URLs to generic Uniform Resource >> Identifiers (URIs) [RFC3986], especially to name-based, high- >> stability, long-persistence, identifiers such as many URNs, has >> failed because the assumed similarities do not adequately extend to >> all forms of URNs. Ultimately, locators, which typically depend on >> particular accessing protocols and a specification relative to some >> physical space or network topology, are simply different creatures >> from long-persistence, location-independent, object identifiers. The >> syntax and semantic constraints that are appropriate for locators are >> either irrelevant to or interfere with the needs of resource names as >> a class. That was tolerable as long as the URN system didn't need >> additional capabilities (over those specified in RFC 2141) but >> experience since RFC 2141 was published has shown that they are, in >> fact, needed. >> >> I don't believe this appendix is way too vague to be helpful. > > > I am confused by this sentence. Is that a typo? Are you saying that this Appendix is too vague to be helpful, and therefore should be removed? Or are you saying it is not too vague; it is helpful; therefore, keep it in the draft? Sorry. I *believe* it is too vague to be helpful. Best regards, Julian From nobody Thu May 5 04:26:14 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB5812D146 for ; Thu, 5 May 2016 04:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 XPPSk4qyM66i for ; Thu, 5 May 2016 04:26:10 -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 E381212B05A for ; Thu, 5 May 2016 04:26:09 -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 u45BQ1bF018593 for ; Thu, 5 May 2016 12:26:06 +0100 (BST) 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 u45BQ11Z005446 for ; Thu, 5 May 2016 12:26:01 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id u45BQ1kC001270 for ; Thu, 5 May 2016 12:26:01 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id u45BQ1Ba001269; Thu, 5 May 2016 12:26:01 +0100 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, 05 May 2016 12:26:01 +0100 Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (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: Subject: [urn] draft-ietf-urnbis-rfc2141bis-urn-16: q-component and resolution X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 11:26:12 -0000 Section 2.3.1, para 2 "If a URN resolves to a URL, the q-component from the URN is copied verbatim to the query component of the URL." "is copied"? By whom? Under what circumstances? Is this meant as a MUST or a SHOULD wrt conformant resolution services? Or advice to user agents that if they get a URL in response (with what response code?) to a resolution request for a (URN with a q-component), they should do such a copy? I suggest that either there needs to be rather more explanation here, or this sentence should just be removed. 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 May 5 04:48:32 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4940312D15E for ; Thu, 5 May 2016 04:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 RAO4c4u1F1EN for ; Thu, 5 May 2016 04:48:29 -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 06BA612D14C for ; Thu, 5 May 2016 04:48:28 -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 u45BmSwG002342 for ; Thu, 5 May 2016 12:48:28 +0100 (BST) 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 u45BmRnb006453 for ; Thu, 5 May 2016 12:48:27 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id u45BmRdg002728 for ; Thu, 5 May 2016 12:48:27 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id u45BmRhS002727; Thu, 5 May 2016 12:48:27 +0100 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, 05 May 2016 12:48:27 +0100 Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (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: Subject: [urn] draft-ietf-urnbis-rfc2141bis-urn-16: 'name' and 'namespace' X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 11:48:32 -0000 The words 'namespace' and 'name' are used throughout the spec in ways that for this reader at least appear to have different meanings at different points, sometimes to the point of apparent contradiction. Consider for example the following from section 2.2: "Depending on the rules governing a namespace, strings that are valid in an NSS associated with that namespace might contain characters that are not allowed by the "pchar" production referenced above (e.g., characters outside the ASCII range or, consistent with the restrictions in RFC 3986, the characters '/', '?', '#', '[', and ']'). While such a string might be a valid name, it is not a valid URN until it has been translated into a conformant NSS." Stripping out a lot of detail, this says "[there are] strings that are valid in an NSS [which render it not] a conformant NSS". While some readers will be familiar with the sense of these words which I think you are relying on, where e.g. 0-205-31342-6 is a name in the ISBN namespace, others will not be. I would strongly recommend that you adhere much more closely to, and document, something close to the pattern of usage in the following, from section 1: Some URN namespaces create names that exist only as URNs, whereas others create URNs out of names that already exist in other identifier systems That is, always use 'URN namespace' when you mean the thing assigned to an NID; 'identifier systems' when you mean other (usually pre-existing) kinds of managed collections of names; 'URN' when you mean a member of a URN namespace; 'NSS' when you mean the URN-namespace-specific part of a URN; 'name' _only_ when you mean a member of a non-URN identifier system. And make these definitions explicit in 1.2, and make it explicit that by 'URN namespace' you mean _only_ the set of URNs allowed by the rules governing that URN namespace (extension) or those rules themselves (intension), _not_ the corresponding names or management of any related non-URN namespace. It will be tedious, and occasionally lead to less concise statements, to make a pass over the document to do this, but the improvement in clarity will IMO be worth it. Give me the write token for a week, and I'll do it, if you like. -- 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 May 5 12:17:19 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175BB12D161 for ; Thu, 5 May 2016 12:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 e9eee6fez-tb for ; Thu, 5 May 2016 12:17:14 -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 8055712D129 for ; Thu, 5 May 2016 12:17:13 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ayOlq-000DXK-Lq; Thu, 05 May 2016 15:17:10 -0400 Date: Thu, 05 May 2016 15:17:05 -0400 From: John C Klensin To: "Hakala, Juha E" , urn@ietf.org Message-ID: <82871E546D6FB8DD942E99B7@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.10 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: jonathanmtclark@gmail.com Subject: Re: [urn] Request for review and comments draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 19:17:18 -0000 Disclaimer: everything I write in this note is a personal opinion, with no connection to my editor role(s) except where notes are explicitly identified as "Editor:"/ --On Monday, April 25, 2016 10:18 +0000 "Hakala, Juha E" wrote: > Hello John; all, > > Further comments below. > >> -----Original Message----- >> From: John C Klensin [mailto:john-ietf@jck.com] >> Sent: 21. huhtikuuta 2016 20:30 >> To: Hakala, Juha E ; urn@ietf.org >> Subject: RE: [urn] Request for review and comments >> draft-ietf-urnbis- rfc2141bis-urn-16 >> >> Juha, >> >> Thanks for the careful reading. A few comments inline below. >> >> --On Thursday, April 21, 2016 06:57 +0000 "Hakala, Juha E" >> wrote: >> >> > Hello John; all, >> > >> > this new version of rfc2141bis is an improvement, and I >> > believe we are getting closer to the goal of this process. >> > >> > I am fine with the decision to postpone work on >> > r-component, although that means further delay of some >> > development projects the library community has been talking >> > about. >> >> Speaking personally (not as editor), I'd like to understand >> those projects, particularly the needs they are trying to >> address, in more detail. That should, however, probably be >> off-list or delayed until we've gotten 2141bis and its >> relatives finished. > > In short, resolvers must be made a lot smarter. All PIDs are > facing the same problem. Future resolvers must offer more > options to the users instead of just supporting persistent > linking to the identified resource. Improvements in systems > with which libraries, publishers etc. are managing digital > resources both enable and require such improvements in > resolvers. Currently our (and for instance publishers') > applications are not too smart, but things will change in few > years' time, and URN syntax should be ready to accommodate > these new requirements when they materialize. This seems entirely reasonable, but it is hard to figure out how to design things to accommodate future needs in any detail (beyond leaving placeholders in syntax and documentation for future extensions) unless one has much more clear distinctions and understanding about what will be needed beyond "smarter" and "more options". In particular, it seems to me that trying to make those provisions based on your comments requires that we address the issue as to whether choices and functionality of resolvers should be under the control of those who manage the namespace (very much implied by 2141 and the was 2141bis is now written) and the ideas of Sean and others about specifying the resolver itself as part of URN syntax. That decision may (or might not, but I don't see a way to avoid it) get tied up with the traditional information science (and epistemological) question of authority. More broadly and referring back to some of my earlier comments, it is not obvious that trying to deal with all future functional requirements and offerings by loading them onto URNs or even URIs is the right answer. Just as we need an increasingly-powerful HTTP and HTTPS as well as the associated URLs, there may be places where offering the user additional options along the lines you outline may require protocol mechanisms above and beyond what can be (or should reasonably be attempted to be) accommodated in a URI of any sort. > For instance, when a future user locates a relevant document, > she should be able to easily retrieve rights metadata > (copyright owner, license terms etc.) related to the document. > It would be easy to list many other requirements and > functionalities which have to do with metadata (descriptive / > administrative / structural) about digital objects. Sure. But that, again, raises the authority issue as well as, at least IMO, making it clear that we don't fully understand the boundary between pseudo-queries and r-components. If the document were a classical web object rather than something for which we want a persistent (and perhaps a little bit more abstract) identifier, then something like: http://www.example.com/documentID?rights-metadata=copyright-owner would be entirely reasonable. I'd actually be surprised if similar applications and syntax were not in use in the world today. Things do get more complex when the document identifier is persistent and sufficiently abstract that one might need to look in different ways or places to find the document and the associated metadata, but I'm not sure we understand how to generalize that yet, much less how to turn it into a URN spec. The problem is further complicated the broader the range of objects, pseudo-objects, and abstract designators (whether all of them are "resources" or not) we expect to associate with URNs because the right answers for some may not be the right answers for all of them. >> > There are some minor issues in the text that should be >> > corrected. >> > >> > In 2.3.1 the draft says: >> > >> > "If a URN resolves to a URL, the q-component from the URN >> > is copied verbatim to the query component of the URL." >> > >> > However, we are no longer using URI query component syntax >> > and our added "=" may cause problems. It is probably better >> > to say something like: >> > >> > "If a URN resolves to a URL, the q-component from the URN >> > is copied to the query component of the URL without "=", so >> > that the query syntax matches URI query component." >> >> I actually checked that sentence when I rewrote things for the >> "?=" convention and I believe it is correct. The reason is >> that, in the ABNF (and I hope consistently in the text), the >> q-component is consistently the string without the introducer. > > OK. I missed that. But it might be a good idea to minimize the > chance that others make the same mistake. Rereading the subsequent sentence, which talked about q-components "beginning with" the "=" could obviously increase the risk of confusion. Editor: text changed for -17 (given an obvious assumption, see subsequent status note). >> For example, Section 2 of 2141bis-16 includes >> >> rq-components = ( "?=" q-component >> [ "?+" r-component ] ) / >> ( "?+" r-component >> [ "?=" q-component ] ) >> q-component = pchar *( pchar / "/" / "?" ) >> >> That is consistent with the way is defined in 3968, >> i.e., from Section 3 of that document: >> >> URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] >> >> So copying the q-component (which does not include the "?=") >> into the query (which does not contain the "?") actually is >> correct. I have doubts about whether "verbatim" is actually >> helpful, but that is another issue. >> >> If you and others think it would be helpful, it would be >> fairly easy to incorporate a sentence into the paragraph >> after the 2141bis syntax partially quoted above and/or after >> the "copied" >> sentence warning that "q-component", etc., refer to the >> string and do not contain the introducing delimiter. An even >> better solution might be to incorporate an example if someone >> wants to suggest one. > > Such sentence + an example would be useful. > > An example can be built by pre-using the example further down > in the text: > > urn:example:weather?=op=map&lat=39.56 > &lon=-104.85 > > could be resolved to something like > > https://weatherapp.org?op=map&lat=39.56 > &lon=-104.85 Editor: Done >> > In 2.3.3 there is a paragraph >> > >> > "Clients SHOULD NOT pass f-components to resolution >> > services unless those services also perform object >> > retrieval and interpretation functions." >> > >> > The purpose of this is to allow the resolution service to >> > act as a "client" which retrieves the entire identified >> > object, applies the fragment to it and sends the result to >> > the original client. IMO this would often give no added >> > value. If the only purpose of the fragment is to take the >> > user to a certain point within the document, there is no >> > way the resolver can do this on behalf of the client the >> > customer is using. So even if the fragment were included in >> > the URN, the resolver should just ignore it, and pass the >> > entire document to the client which then applies the >> > fragment to it. >> >> Actually, the reason for it was a little different and that >> is to not constrain implementation models. In one resolution >> model (using the URN-> URL case as the obvious example), the >> one I think you have in mind, the approach is >> >> client parses URN into pieces and >> client sends NID and NSS >> -> URN-resolution-service >> <- (resulting URL) >> -or- sends NSS >> -> NID-specific resolution-service >> <- (resulting URL) >> >> client adds whatever needs to be added to URL >> client -> URL-resolution-service >> <- (resulting resource/ object) >> client evaluates fragment, if any, against object >> client returns object, or object subset, to user >> >> The other model, which I think is worth preserving, is >> >> client does not parse URN but >> passes the whole thing >> -> URN processor >> <- (resulting resource / object and >> fragment ID >> client evaluates fragment, if any, against object >> clients returns object, object subset, or other >> result to user. >> >> There are several variations on those themes, but the basic >> difference in that, in the first model, the client has to >> break the URI into pieces and then manage the processing/ >> evaluation of the pieces. In the second, most of that is >> handed off to what looks to the client like a black box that >> emits a resource or, in extreme cases, conformation that the >> desired action has been completed. >> >> In addition to suggesting two different processing models, >> either of which might be implemented in libraries or the like >> for a broad range of URNs, the relationship between the two >> also suggests a distinction that 2141bis does not make. That >> specification now describes two types of URNs, those that >> resolve in some way (for some very broad definition of >> "resolve") and those that do not resolve at all, with the >> latter called "abstract designators". It is also possible to >> distinguish between namespaces of "objects" that are similar >> to documents and "objects" that are really actions to be >> performed. > > I cannot see any immediate use for utilizing identifiers for > actions like this, at least in library domain, but eventually > such approach may become relevant. I think this is more about how about how things are implemented than about any particular area of application. I could try to justify/ rationalize it further but let's just stick with the belief that invalidating an otherwise-reasonable implementation option by our choice of words does not seem wise. It may or may not be worth noting that, if anyone still believes in Object or Method-oriented programming with high level objects, the very same arguments that justify talking about generic URI parsers equally justify creating a generic URN method that is called upon to do _all_ URN processing and that might return either an object or some success or failure indication structure. >... >> > In 4.2 there is a somewhat challenging (at least for a >> > non-English speaker) sentence >> > >> > "In part because of the separation of URN semantics from >> > more general URI syntax >> > [I-D.ietf-urnbis-semantics-clarif], generic URI processors >> > need to 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." >>... >> What that admittedly-difficult sentence is trying to say is >> closer to: >> >> 'If one has a generic processor for URI, the rules of >> 3986 apply and must be followed. Only if the processor >> recognizes the "urn" scheme and understands the >> applicability of this specification as a result it is >> appropriate to try to apply its extended rules.' >> >> Put that way, the statement is very nearly tautologically >> trivial and should simply be dropped. But I think we added >> it to help define the "syntax only but, like other schemes, >> we get to further restrict and interpret the syntax" boundary >> between 2141bis and 3986. Suggestions welcome. > > I should not have used the term "identifier scheme". What I > was aiming at was that parsing a URN is a double challenge for > a generic URI processor. First, the processor must recognize > the "urn" scheme. And next, the processor must know how to > deal with identifier system (URN namespace). A parser capable > of resolving urn:isbn's may not know itself how to deal with > urn:issn's. In an ideal world equipped with resolver discovery > service, urn:isbn resolver would know how to find the urn:issn > resolver or any other urn namespace specific resolver out > there. For the time being, finding the right resolver (there > may be several for a single namespace) can be a challenge > unless the resolver location is embedded in the URI with the > URN. > Parsing URNs is to some extent namespace specific . Some > namespaces may not provide any services, some may have a whole > set of them. "Scheme-appropriate processing" seems to relate > to URNs in general. Recognizing that a string is a URN is the > necessary first step, but from practical point of view it is > more important to provide appropriate namespace specific > parsing of URNs. Indeed. That particular set of problems are at the core of the reasons why we went down the path of trying to separate URNs from (generic) URIs entirely. Doing so would allow a clear conceptual model in which a URN was a high-level and fairly abstract identifier with ways of talking about, not just objects or classes of objects but "metadata" about each. The WG (or at least those who showed up, some of them outraged, at a meeting or two) didn't like that idea, so we did the syntax-only approach instead, treating ourselves to the difficulties about what can and cannot done in a generic way, discussions of the True Meaning of URIs, and so on. If people really want to revisit issues and decisions that were apparently closed, perhaps we should come back to that one. >> > Chapter 5 specifies three constraints: uniqueness, >> > consistent assignment and assignment according to a common >> > definition. I would like to add fourth constraint, >> > persistence. It is already there between the lines (URN is >> > never reassigned to a different resource) but we could also >> > make the point that sometimes URNs may even outlive >> > identified resources. >> >> Send text. I can't remember whether it was an explicit >> decision or not, but persistence may have been omitted from >> Section 5 after it became necessary to add what is now >> Section 1.1 to reflect the fact that we couldn't really agree >> on a >> universally-applicable definition for persistence. Of >> course, we could simply insert a persistence constraint to >> Section 5 and point back to 1.1 for a [non-]definition. > > What about this formulation to replace the current requirement > 1 in chapter 5: > > The "uniqueness" and "persistence" constraints mean that once > assigned, an identifier within the namespace is never > altered and never reassigned to a different resource (for the > kind of "resource" identified by URNs assigned within > the namespace) even If the URN is found to have been issued in > error. This holds true even if the identifier itself is > deprecated or becomes obsolete. > > Note that I am not comfortable with "identifier within the > namespace is never assigned to more than one resource ". In > ISBN namespace, for instance, there are separate ISBNs for all > three parts of The Lord of the Rings, but there is also 4th > ISBN which covers all three parts. So ISBN namespace does not > meet the requirement "never assigned to more than one > resource", since in the ISBN namespace the concept of book is > complex and covers both multivolume works as single entity in > addition to each volume. Works for me. To others have comments before I put the editor hat on and put this in? >... >> > Finally, I am OK with the idea of having two kinds of URNs: >> > resource identifiers and abstract designators which do not >> > and will not support resolution services. But I find it >> > difficult to accept (as stated in Introduction) that these >> > abstract designators, although persistent, do not identify >> > a resource. >> > What is the purpose of a URN that does not identify >> > anything? It is definitely possible to identify something >> > without being resolvable. >> >> First of all, I agree that things are still a little bit >> confused (see discussion above). I am hoping that complete >> clarification is not in the critical path. > I don't think so. >> But the specific >> answer to your question is that we've got several situations >> (the XMPP one is the most-cited case) in which the presence >> or absence of a URN, or the presence of a URN with a >> particular set of values in the NSS, simply tells whatever >> (e.g., client) is interpreting it to take or not take some >> action or to behave in >> one way or not another. For some months, I referred to such >> URNs as "indicators" (sometimes prefixed by "pure" or >> "abstract") to distinguish them from "identifiers" in the >> sense that your comments above implied. There are some >> disadvantages to the "indicator" terminology. While I don't >> remember an explicit discussion of that terminology, Peter >> preferred "abstract designator", no one else seemed to >> object, and I didn't think it was worth arguing about. If >> you see a useful way to clarify that situation, please >> suggest it. > I cannot... but I can live with this situation. This part of > the spec may become a headache if and when it becomes > necessary to translate and explain "abstract designator" in > Finnish ;-). Or any number of other languages that do share many or most concepts with English. But difficulties in translating IETF technical specifications to other languages without loss of information are, unfortunately, nothing new. thanks, john From nobody Thu May 5 12:39:51 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D1612D79E for ; Thu, 5 May 2016 12:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 O2XK3VJ6xRy4 for ; Thu, 5 May 2016 12:39:49 -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 1D63A12D14B for ; Thu, 5 May 2016 12:39:49 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ayP7j-000Daw-58; Thu, 05 May 2016 15:39:47 -0400 Date: Thu, 05 May 2016 15:39:42 -0400 From: John C Klensin To: "Henry S. Thompson" , urn@ietf.org Message-ID: <2C60969953BC849FDA35733E@JcK-HP8200.jck.com> In-Reply-To: References: 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.10 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] q-component copied verbatim (was: Re: draft-ietf-urnbis-rfc2141bis-urn-16: q-component and resolution) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 19:39:50 -0000 --On Thursday, May 05, 2016 12:26 +0100 "Henry S. Thompson" wrote: > Section 2.3.1, para 2 > > "If a URN resolves to a URL, the q-component from the URN is > copied verbatim to the query component of the URL." > > "is copied"? By whom? Under what circumstances? Is this > meant as a MUST or a SHOULD wrt conformant resolution > services? Or advice to user agents that if they get a URL in > response (with what response code?) to a resolution request > for a (URN with a q-component), they should do such a copy? > > I suggest that either there needs to be rather more > explanation here, or this sentence should just be removed. Per earlier note, this material has been rewritten in -17. The rewrite also makes the prose clearly agree with the ABNF that the q-component does not include the (two-character) delimiter that introduces it nor any delimiters that terminate it. john From nobody Thu May 5 23:42:10 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAFF12D0E0 for ; Thu, 5 May 2016 23:42:08 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fqCcAkACDsBF for ; Thu, 5 May 2016 23:42:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E21612D0DE for ; Thu, 5 May 2016 23:42:06 -0700 (PDT) Received: from [192.168.178.20] ([93.217.107.95]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M7H2Y-1btP6L2rGo-00x3VL; Fri, 06 May 2016 08:41:55 +0200 To: John C Klensin , "Henry S. Thompson" , urn@ietf.org References: <2C60969953BC849FDA35733E@JcK-HP8200.jck.com> From: Julian Reschke Message-ID: <53928f62-3de9-567b-e8dc-444a5c66d477@gmx.de> Date: Fri, 6 May 2016 08:42:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <2C60969953BC849FDA35733E@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ZVagye1blCB4v+L/qACW0u1LjxIkLMJ3a7UuFryqUKuYZM1lt0l Wz4T5bIqwKXetFjyn6Q/oqr0S1ksxjJjpG8F6ri3pnlc4603Tf9LhRTGMSc2NVBMlDjRhEa YgFJh7d6MGr/wO6YAx7eajNjjT5/xiMaOLMqPnYhxqZEiuB1y0Bq7nGtHdqZ4aG4pOVV3s5 5LtcaQYwQZuhqihX2V64w== X-UI-Out-Filterresults: notjunk:1;V01:K0:Wbm6CaKWfRw=:0Kw3+Dw5Oz2Ek4e8nv3WhK TyGsyodrnATOVYcXh7xNH3iCN9wEQECQAbDPzzPYOP5BUc+5oZquaiJCcnVEgiNI6TzYfybcC nu0nthhQZ5Cc14GuKKEgmM0oVtkc0D9G0P2LrViIfW7nfBUKZfT+dAa6VMVrFkpBWFkggJ01v NregjjVRvrJLRb/80W7clC801/ayB+lPoYGz9jl71rf0LGyDxNOQPHBE01KMAGQgPiOqLoFnV ZGI5FucSmA9gMC5QxZiBWvMsPnairGQKPfcjFZuxv3/5UT8MhWZZqFCoX5EeWS9r6MjtzuLx5 zK7TTVi9+QVTXDepzqOEWbiP/c8YFwxBguF1DMr0aZVe26azfJjKc1/muMNfRMAqn8L71slHu YwEah4YnblVUbn8DAm30siBET1kJuntce3vVurTKimodZZn3wbYwyIuovwofMmL6PVfgNexBE vqQ8g6vXq2ZwHBJrfcA44JxvCf17wiJKYh8UkpDBJ8s5IB6qooCviPKfv/yQ5eNs3IlJkJYm0 uCk74HJUgb7NCBCcgBncT9FzbdWG71rP6894WmREuetVvONflg15vvcU7hyiBQKJ07E9Dff4d DN08l+BstyC3q9AyWnEM/hqp5uAznPTMCbij2RdcsCpMNepnWfDPeZnprY9LaSeGFBNc0Wtmm 597nys6thBpPYUWxVRMzk0+fYreOvuksjdsVqaEUfW8JX7WqUzhl/1N+sJVUTGwHvgj4n/zTT PwJWcv1JyCvqM2AbzevPTEXrDnDOVlPHtZvF+MaVrO1061r2x260HJVxQs9KItyHLWak1jXeo rw01vuj Archived-At: Subject: Re: [urn] q-component copied verbatim X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 06:42:09 -0000 On 2016-05-05 21:39, John C Klensin wrote: > ..., or this sentence should just be removed. > > Per earlier note, this material has been rewritten in -17. The > rewrite also makes the prose clearly agree with the ABNF that > the q-component does not include the (two-character) delimiter > that introduces it nor any delimiters that terminate it. > ... There's no -17 yet, as far as I can tell. Is there an editor's copy somewhere that we should look at? Best regards, Julian From nobody Fri May 6 05:58:11 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D5D12D16F for ; Fri, 6 May 2016 05:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996, T_HTML_ATTACH=0.01] autolearn=ham autolearn_force=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 mVB5RaYdPd39 for ; Fri, 6 May 2016 05:58:07 -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 C0D7E12D0AA for ; Fri, 6 May 2016 05:58:07 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ayfKT-000KFl-Vv; Fri, 06 May 2016 08:58:01 -0400 Date: Fri, 06 May 2016 08:57:56 -0400 From: John C Klensin To: Julian Reschke Message-ID: <2F02EA4EFFCD81CD6ADBB789@JcK-HP8200.jck.com> In-Reply-To: <53928f62-3de9-567b-e8dc-444a5c66d477@gmx.de> References: <2C60969953BC849FDA35733E@JcK-HP8200.jck.com> <53928f62-3de9-567b-e8dc-444a5c66d477@gmx.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========9C32DDBA5681ACA76F7C==========" X-SA-Exim-Connect-IP: 198.252.137.10 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] q-component copied verbatim X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 12:58:10 -0000 --==========9C32DDBA5681ACA76F7C========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline --On Friday, May 06, 2016 08:42 +0200 Julian Reschke wrote: > On 2016-05-05 21:39, John C Klensin wrote: >> ..., or this sentence should just be removed. >> >> Per earlier note, this material has been rewritten in -17. >> The rewrite also makes the prose clearly agree with the ABNF >> that the q-component does not include the (two-character) >> delimiter that introduces it nor any delimiters that >> terminate it. ... > > There's no -17 yet, as far as I can tell. Is there an editor's > copy somewhere that we should look at? There is not. My editor's copies contain assorted personal and placeholder notes, pointers to things I want Peter to cross-check, may not actually compile with XML2RFC, etc. Touching off potentially-heated discussions of text that is far from settled or consistent just does not seem to me to be a productive use of time, nor does having people make parallel comments on multiple versions. While a successful appeal to the WG Co-chairs will get any given next draft posted immediately, the time it would take to get it together does slow down progress on other proposed changes. However, since this material appears to be of particular interest, I took the 15 minutes required to verify the XML and prepare a text form of the relevant section. For those who want to look at it, it is attached, in Wdiff form from -16. Note that other sections that are in the process of being changed have not been included. Comments welcome (I'm particularly interested in whether "verbatim" contributes anything). best, john --==========9C32DDBA5681ACA76F7C========== Content-Type: text/html; charset=utf-8; name="wdiff-rfc2141bis-16-q-component-to--17b.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="wdiff-rfc2141bis-16-q-component-to--17b.html"; size=4700 wdiff = draft-ietf-urnbis-rfc2141bis-urn-16k.txt = draft-ietf-urnbis-rfc2141bis-urn-17b.txt 
URNBIS                                                    P. =
Saint-Andre
Internet-Draft                                                  =
Filament
Obsoletes: 2141, 3406 (if approved)                           J. =
Klensin
Intended status: Standards Track
April 16,            =
                 May =
5, 2016
Expires: October =
18,November =
6, 2016

                     Uniform Resource Names (URNs)
                  draft-ietf-urnbis-rfc2141bis-urn-16=

                  draft-ietf-urnbis-rfc2141bis-urn-17b

[...]

2.3.1.  q-component

   The q-component is intended for passing parameters to either =
the
   named resource or a system that can supply the requested =
service, for
   interpretation by that resource or system.  (By contrast, =
passing
   parameters to URN resolution services is handled by =
r-components as
   described in the next section.)

   The URN q-component has the same syntax as the URI query =
component,
   but is introduced by "?=3D", not the "?" alone.  If a URN =
resolves to a
   URL, the q-component from the URN is copied verbatim to the =
query
   component of the URL.  An =
example of the copying operation appears
   below.  If the URN does not resolve to a URL =
(i.e., is an abstract
   designator or resolves directly to an object or a non-URL =
resource
   designator), the interpretation of the q-component is =
undefined by
   this specification.  Thus, for URNs which may be resolved to =
a URL,
   the semantics of q-component are identical to those for =
queries to
   the resource located via that URL.

   For the sake of consistency with RFC 3986, neither the =
general syntax
   nor the semantics of q-components are defined by, or =
dependent on,
   the namespace of the URN.  In parallel with RFC 3896, =
specifics of
   syntax and semantics, e.g., which keywords or terms are =
meaningful,
   of course may depend on a particular namespace or even a =
particular
   resource.

   The sequence "?=3D" begins introduces the q-component.  The =
q-component ends =
with
   terminates when =
a "?+" sequence (which begins an r-component) or a
   "#" character (number sign, which begins an f-component). f-component) appears.  If
   neither of those appear, the q-component continues to the end =
of the
   URN.  Note the the q-component =
itself does not include the "?=3D"
   delimier or any terminating delimiter.  The =
characters slash ("/")
   and question mark ("?") may represent data within the =
q-component.
   Note that characters outside the ASCII range [RFC20] MUST be =
percent-encoded =
percent-
   encoded using the method defined in Section =
2.1 of the generic URI
   specification [RFC3986].

   As described in Section 3, the q-component SHALL NOT be taken =
into
   account when determining URN equivalence.

   Namespaces and associated information placement in syntax =
SHOULD be
   designed to avoid any need for a resolution service to =
consider the
   q-component.  Namespace-specific and more generic resolution =
systems
   MUST NOT require that q-component information be passed to =
them for
   processing.

   Consider the hypothetical example of passing parameters to an
   application that returns weather reports from different =
regions or
   for different time periods.  This could perhaps be =
accomplished by
   specifying latitude and longitude coordinates and datetimes =
in the
   URN's q-component, resulting in URNs such as the following.

      urn:example:weather?=3Dop=3Dmap&lat=3D39.56
         &lon=3D-104.85&datetime=3D1969-07-21T02:56:15Z

   If this example resolved to an =
HTTP URL, the result might look like:

      https://weatherapp.example?op=3Dmap&lat=3D39.56
         =
&lon=3D-104.85&datetime=3D1969-07-21T02:56:15Z

[...]
--==========9C32DDBA5681ACA76F7C==========-- From nobody Fri May 6 09:51:30 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BF812B032 for ; Fri, 6 May 2016 09:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 QtDOaXfiJ5PZ for ; Fri, 6 May 2016 09:51:26 -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 EF2C112D501 for ; Fri, 6 May 2016 09:51:25 -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 u46GpOhk019272; Fri, 6 May 2016 17:51:24 +0100 (BST) 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 u46GpNkl000348; Fri, 6 May 2016 17:51:23 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id u46GpNmp012597; Fri, 6 May 2016 17:51:23 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id u46GpMhl012596; Fri, 6 May 2016 17:51:22 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: John C Klensin References: <2C60969953BC849FDA35733E@JcK-HP8200.jck.com> <53928f62-3de9-567b-e8dc-444a5c66d477@gmx.de> <2F02EA4EFFCD81CD6ADBB789@JcK-HP8200.jck.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 06 May 2016 17:51:22 +0100 In-Reply-To: <2F02EA4EFFCD81CD6ADBB789@JcK-HP8200.jck.com> (John C. Klensin's message of "Fri\, 06 May 2016 08\:57\:56 -0400") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (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: Julian Reschke , urn@ietf.org Subject: Re: [urn] q-component copied verbatim X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 16:51:29 -0000 John C Klensin writes: > However, since this material appears to be of particular > interest, I took the 15 minutes required to verify the XML and > prepare a text form of the relevant section. For those who want > to look at it, it is attached, in Wdiff form from -16. Note > that other sections that are in the process of being changed > have not been included. Comments welcome (I'm particularly > interested in whether "verbatim" contributes anything). I don't have an opinion about 'verbatim'. None of the edits address my question, so I'll repeat it: "If a URN resolves to a URL, the q-component from the URN is copied verbatim to the query component of the URL." "is copied"? By whom? Under what circumstances? Is this meant as a MUST or a SHOULD wrt conformant resolution services? Or advice to user agents that if they get a URL in response (with what response code?) to a resolution request for a (URN with a q-component), they should do such a copy? I suggest that either there needs to be rather more explanation here, or this sentence should just be removed. 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 May 6 11:42:58 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057FA12D101 for ; Fri, 6 May 2016 11:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 MgU29O10WdsQ for ; Fri, 6 May 2016 11:42:55 -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 13EF312B049 for ; Fri, 6 May 2016 11:42:54 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ayki8-000L4y-GE; Fri, 06 May 2016 14:42:48 -0400 Date: Fri, 06 May 2016 14:42:43 -0400 From: John C Klensin To: "Henry S. Thompson" Message-ID: <7883335563DB29FFAF9BE5DB@JcK-HP8200.jck.com> In-Reply-To: References: <2C60969953BC849FDA35733E@JcK-HP8200.jck.com> <53928f62-3de9-567b-e8dc-444a5c66d477@gmx.de> <2F02EA4EFFCD81CD6ADBB789@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.10 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: Julian Reschke , urn@ietf.org Subject: Re: [urn] q-component copied verbatim X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 18:42:57 -0000 --On Friday, May 06, 2016 17:51 +0100 "Henry S. Thompson" wrote: > John C Klensin writes: > >> However, since this material appears to be of particular >> interest, I took the 15 minutes required to verify the XML and >> prepare a text form of the relevant section. For those who >> want to look at it, it is attached, in Wdiff form from -16. >> Note that other sections that are in the process of being >> changed have not been included. Comments welcome (I'm >> particularly interested in whether "verbatim" contributes >> anything). > > I don't have an opinion about 'verbatim'. > > None of the edits address my question, so I'll repeat it: Sorry. Didn't understand the question in the context of other comments about that text. > "If a URN resolves to a URL, the q-component from the URN is > copied verbatim to the query component of the URL." > > "is copied"? By whom? Under what circumstances? Is this > meant as a MUST or a SHOULD wrt conformant resolution > services? Or advice to user agents that if they get a URL in > response (with what response code?) to a resolution request > for a (URN with a q-component), they should do such a copy? > > I suggest that either there needs to be rather more > explanation here, or this sentence should just be removed. As a bit of history, we started the q-component discussion (in 2141bis -10 in March 2015 or earlier) with the sentence out. Versions of 2141bis through -12 (2015-06-13, esp Section 3.3.1) didn't say what to do with the q-component but instead indicated that its semantics might not be the same as those of a 3986 query and essentially left the question of what to do with it as per-namespace. -12 even included an example and discussion of passing q-component values to resolvers rather than resource objects (see below). Some WG participants insisted that interpretation and gross semantics of q-components not be per-namespace and others seemed to agree, so, for -13 (2015-09-14) the present text was included. There was, IIR, WG discussion of the text itself both before and after -13 was posted and the text continued unchanged through -15. The change in -16 was made in response to concerns about URNs that do not map to URLs, but, while the scope of the text was changed, the basic "is copied..." text is circa 14 months old. Now, I think Peter wrote those "is copied" words rather than my doing so, but remember that RFC 2119 says those MUST/ SHOULD/ etc., words are about interoperability, not about conformance (part of a long and, IMO, tedious, discussion on the IETF list). In this case, whether that exact ("verbatim") copying is an interoperability requirement (given narrow interpretations of that term) or not depends on the namespace and how the resolvers, if any, for that namespace work. Further, in this context at least, "SHOULD" would require an explanation of when not doing it is appropriate and either "SHOULD" or "MUST" probably would require, as you suggest, enough of a standardized, namespace-independent, URN processing model to be able to specify "by whom or what". So, while I understand your argument / position and have some sympathy for it, I'd like to hear from others in the WG about whether the change is worthwhile, whether it should be to SHOULD or MUST, and whether we are willing to spend the time and effort (and accept the restrictions on possible behavior) to nail the processing model down and, if we go for SHOULD, whether we are ready to spend the energy to discuss and settle on some wording about "when not". Especially given the history, I don't feel comfortable treating this as an editorial comment and just changing the text without either that input or instructions from the co-chairs. best, john From nobody Fri May 6 13:20:17 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE27412D52C for ; Fri, 6 May 2016 13:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 x24XOrSrw3ES for ; Fri, 6 May 2016 13:20:13 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 1AE0212D50A for ; Fri, 6 May 2016 13:20:13 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 29483509B5 for ; Fri, 6 May 2016 16:20:11 -0400 (EDT) To: urn@ietf.org References: <2C60969953BC849FDA35733E@JcK-HP8200.jck.com> <53928f62-3de9-567b-e8dc-444a5c66d477@gmx.de> <2F02EA4EFFCD81CD6ADBB789@JcK-HP8200.jck.com> From: Sean Leonard Message-ID: <8abad67b-a439-6168-ed46-1713fe32ba90@seantek.com> Date: Fri, 6 May 2016 13:19:34 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <2F02EA4EFFCD81CD6ADBB789@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] q-component copied verbatim X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 20:20:16 -0000 On 5/6/2016 5:57 AM, John C Klensin wrote: > > --On Friday, May 06, 2016 08:42 +0200 Julian Reschke > wrote: > >> On 2016-05-05 21:39, John C Klensin wrote: >>> ..., or this sentence should just be removed. >>> >>> Per earlier note, this material has been rewritten in -17. >>> The rewrite also makes the prose clearly agree with the ABNF >>> that the q-component does not include the (two-character) >>> delimiter that introduces it nor any delimiters that >>> terminate it. ... >> There's no -17 yet, as far as I can tell. Is there an editor's >> copy somewhere that we should look at? > There is not. My editor's copies contain assorted personal and > placeholder notes, pointers to things I want Peter to > cross-check, may not actually compile with XML2RFC, etc. > Touching off potentially-heated discussions of text that is far > from settled or consistent just does not seem to me to be a > productive use of time, nor does having people make parallel > comments on multiple versions. > > While a successful appeal to the WG Co-chairs will get any given > next draft posted immediately, the time it would take to get it > together does slow down progress on other proposed changes. > > However, since this material appears to be of particular > interest, I took the 15 minutes required to verify the XML and > prepare a text form of the relevant section. For those who want > to look at it, it is attached, in Wdiff form from -16. Note > that other sections that are in the process of being changed > have not been included. Comments welcome (I'm particularly > interested in whether "verbatim" contributes anything). Please provide an example URN that resolves to this HTTP URL: https://weatherapp.example?op=map&lat=39.56 &lon=-104.85&desc=Santa?+or+Claus &datetime=1969-07-21T02:56:15Z Sean From nobody Fri May 6 18:43:51 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D772712B061 for ; Fri, 6 May 2016 18:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 yCcAxnkBeIWw for ; Fri, 6 May 2016 18:43: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 1F78912D170 for ; Fri, 6 May 2016 18:43:47 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ayrHW-000M2t-B9; Fri, 06 May 2016 21:43:46 -0400 Date: Fri, 06 May 2016 21:43:41 -0400 From: John C Klensin To: Sean Leonard , urn@ietf.org Message-ID: In-Reply-To: <8abad67b-a439-6168-ed46-1713fe32ba90@seantek.com> References: <2C60969953BC849FDA35733E@JcK-HP8200.jck.com> <53928f62-3de9-567b-e8dc-444a5c66d477@gmx.de> <2F02EA4EFFCD81CD6ADBB789@JcK-HP8200.jck.com> <8abad67b-a439-6168-ed46-1713fe32ba90@seantek.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.10 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] q-component copied verbatim X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 01:43:50 -0000 --On Friday, May 06, 2016 13:19 -0700 Sean Leonard wrote: > Please provide an example URN that resolves to this HTTP URL: > > https://weatherapp.example?op=map&lat=39.56 > &lon=-104.85&desc=Santa?+or+Claus > &datetime=1969-07-21T02:56:15Z Please locate the text in 2141bis that requires that there be a URN corresponding to every URL. I am guessing that the developers of every sensible namespace from which URNs resolve to URLs will have at least some control over the way those URLs are constructed. As my physician says when I complain that some unreasonable activity causes pain and ask for a cure, "don't do that". If you are trying to make a point about quoting or escaping, remember that we tried to construct such text and were told by the 3986 community that it wasn't necessary and that all the rules were clear and worked. If you think there is a problem, convince them and tell us what to put in the document. Otherwise, again, if a particular URL construction causes pain, use a different construction. In particular with the example above, there would be no problem without the "?" following "Santa". That "?" doesn't really seem necessary to any realistic example I can construct, so I'd suggest that a better URL for a real case would be https://weatherapp.example?op=map&lat=39.56 &lon=-104.85&desc=Santa+or+Claus &datetime=1969-07-21T02:56:15Z and that is easily represented in a URN should one decide to do that. john From nobody Fri May 6 22:44:02 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976A512D189 for ; Fri, 6 May 2016 22:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 Rgk8Aj9XAxXs for ; Fri, 6 May 2016 22:43:59 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 549CC12B036 for ; Fri, 6 May 2016 22:43:59 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0360D509B6; Sat, 7 May 2016 01:43:55 -0400 (EDT) To: John C Klensin , urn@ietf.org References: <2C60969953BC849FDA35733E@JcK-HP8200.jck.com> <53928f62-3de9-567b-e8dc-444a5c66d477@gmx.de> <2F02EA4EFFCD81CD6ADBB789@JcK-HP8200.jck.com> <8abad67b-a439-6168-ed46-1713fe32ba90@seantek.com> From: Sean Leonard Message-ID: <22f6a3f3-c3a6-f03b-c366-a91acbe8c632@seantek.com> Date: Fri, 6 May 2016 22:43:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [urn] q-component copied verbatim X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 05:44:01 -0000 On 5/6/2016 6:43 PM, John C Klensin wrote: > > --On Friday, May 06, 2016 13:19 -0700 Sean Leonard > wrote: > >> Please provide an example URN that resolves to this HTTP URL: >> >> https://weatherapp.example?op=3Dmap&lat=3D39.56 >> &lon=3D-104.85&desc=3DSanta?+or+Claus >> &datetime=3D1969-07-21T02:56:15Z > Please locate the text in 2141bis that requires that there be a > URN corresponding to every URL. It does not exist; your point is irrelevant. The issue is that the=20 q-component is copied "verbatim" into the query component (appended?=20 prepended? randomly interspersed?) of the URL. In any event, the text=20 itself says that the so-called q-component is not part of the "URN" and=20 does not affect "URN equivalence". > I am guessing that the > developers of every sensible namespace from which URNs resolve > to URLs will have at least some control over the way those URLs > are constructed. This assumes that "developers of namespaces" get to dictate=20 unequivocally how URNs get put together, which is contradicted by the=20 text (Section 6.4.6), and by common sense. "URN resolvers"--not=20 namespace developers--do the conversion from URNs to URLs. > As my physician says when I complain that some > unreasonable activity causes pain and ask for a cure, "don't do > that". Yeah, don't use q-components: that's the unreasonable activity. Your=20 physician doesn't write software. Software does what it is programmed to = do, whether the designer understands it or not. > If you are trying to make a point about quoting or escaping, > remember that we tried to construct such text and were told by > the 3986 community that it wasn't necessary and that all the > rules were clear and worked. Cite the conversation and cite the section of the draft. I never heard=20 such a thing from the "3986 community". I don't even know who they are. The rules for %-encoding are "clear and worked", but you have to say=20 that you are doing them, under what circumstances, and why. In this=20 case, if your contention is that ? should be %-encoded, then it has to=20 be %-decoded when put into the URL--it can't be "copied verbatim". But=20 that means that ? (or ?+ or whatever) *always* have to be %-encoded,=20 which means that a q-component that contains ? (or ?+ or whatever) is=20 syntactically invalid, which is expressly contradicted by the ABNF. At present, the character sequence ?+ is potentially under the control=20 of an attacking party, and can't be represented in the output safely,=20 consistently, or deterministically. > If you think there is a problem, > convince them and tell us what to put in the document. Don't know who I'm talking to. See above for text. > Otherwise, again, if a particular URL construction causes pain, > use a different construction. In particular with the example > above, there would be no problem without the "?" following > "Santa". That "?" doesn't really seem necessary to any > realistic example I can construct, so I'd suggest that a better > URL for a real case would be > > https://weatherapp.example?op=3Dmap&lat=3D39.56 > &lon=3D-104.85&desc=3DSanta+or+Claus > &datetime=3D1969-07-21T02:56:15Z > > and that is easily represented in a URN should one decide to do > that. Wrong. Who gets to decide the parameters? Obviously, a *user* (in the=20 very broad sense of the term) is deciding the parameters. Who is=20 generating lat=3D39.56 and lon=3D-104.85? It's not some namespace designe= r=20 hiding behind a desk at some 30-acre office campus. It's software, and=20 it can be manipulated. A *user* can just as easily specify name=3Dfoo or = name=3Dbar or name=3DSanta?+Claus. And that is the point: you have an=20 in-band signaling problem, also known as a "phreaking" problem.=20 Everything past the ?+ is going to get (possibly) interpreted=20 incorrectly as r-component. Exploits of a Mom https://xkcd.com/327/ As written, Section 8 of draft-16 is materially deficient. Section 8=20 (Security and Privacy Considerations) needs to say: "?+ cannot safely be = represented in q-component. URN composing software must filter out such=20 sequences, which means that ?+ can never be part of the query of a URL=20 resolved from a URN." Sean From nobody Sat May 7 12:12:29 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57B112D0B6 for ; Sat, 7 May 2016 12:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 e7XsQI8pXqRr for ; Sat, 7 May 2016 12:12: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 2C6ED12D0A2 for ; Sat, 7 May 2016 12:12:26 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1az7eL-000Ohq-M3 for urn@ietf.org; Sat, 07 May 2016 15:12:25 -0400 Date: Sat, 07 May 2016 15:12:20 -0400 From: John C Klensin To: urn@ietf.org Message-ID: <3BFE2BFEB429A4405E016B7F@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.10 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] 2141bis: Personal observations X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 19:12:29 -0000 Hi. I've got a number of high-priority things going on in my life right now. I really don't have time for URNs and probably won't have time for at least a couple of months. I'd like to get this finished and so will try to continue to follow up comments about things I've said earlier and, when it seems clear what should be done, work on the documents. However, the situation, other priorities, and time pressures are making me a good deal less tolerant of suggestions that seem to me to reopen old issues or to change the scope of our work than I normally try to be. Consequently, if I snap at anyone or seem to respond rudely, I apologize in advance. I'm trying to simply not respond to things that would bring out those reactions (including especially topics on which I believe the co-chairs need to make a determination about closed issues), but that may result in unexpected silences. I apologize for those, but please do not take the silence for agreement with whatever has been said. If any of that makes it inappropriate for me to continue as editor, tell it to the co-chairs, noting that I've already suggested to them that I quit. I hope I can comment on a historical issue without starting an ultimately-pointless discussion. It has been clear to several clusters of people in the WG that the relationship between URNs and 3986 is not a smooth fit. For some, parts of that are proof that URNs are irrelevant or worse. For a subset of them, that is an indication that we should have scheme-per-namespace, i.e., that urn:example:... should be abandoned and instead mapped into example:... For others, 3986 imposes semantic and/or syntactic rules and limits that are incompatible with 2141 or URN concepts generally. Others abhor the distinction between "uniform resource names" and the urn scheme and whatever it may be taken as implying. And still others find 3986 very hard to read (especially in a URN context), the structure of that document (at least absent an external oral tradition) far too narrative and exploratory of options for a normative specification, the violations of ABNF and related norms with the "one of these must match, use it" language and the like, just too much to take in an IETF spec, much less a full standard. Those groups are obviously not disjoint although they are almost certainly separate from those who believe that 3986 is self-contained, comprehensive, precise, and clear. The differences among those various opinions and a desire to move forward with URNs are the reason we first tried to disconnect URNs from 3986 URIs entirely and then fell back to a "syntax only" model. However, those same differences -- and the rough edges around the "syntax only" model and 3986 terminology -- can also be used to "prove" that URNs involve impossible contradictions with URIs and are therefore themselves impossible (or just a terrible idea) and a dead end. Those issues even apply to 2141-style URNs although the new extensions make URNs a bigger target. Even if the intent is constructive, reopening issues about the URN-URI boundary, or even finding new variations on them, can have only one likely effect, which is killing off the effort to create a URN standard in the IETF that meets the needs of various communities who are convinced that they need a URN-style persistent identifier. I just hope everyone shares an understanding about where that leads: it will not stop communities who believe they need a persistent identifier model with a syntax that is generally based on the URI model from creating and using those identifiers. It won't even prevent them from labeling such identifiers with the "urn:" scheme name. They will just do what they thing necessary on a per-namespace basis, with low likelihood of consistency between namespaces and even less likelihood of close conformance to the niceties of the 2986 URI definition. Whether those URNs will interoperate with the web (or with other URIs) will depend on how much they deviate from the established reading of 3986, how established that reading really is, and how conservative things that have to interpret URIs are about what they expect. In some cases, the relevant communities may not even care. In others, they may be in a position to take advantage of an Internet that is increasingly politicized and economically sensitive in various areas to persuade implementers and vendors to interpret things their way -- such things have certainly happened before. I happen to prefer a single URN framework and standard, even if it is not as precise about every detail of implementation or conformance, or as fully-developed in some areas, as many of us (including myself) would prefer, to a situation in which everyone does their own thing with whatever guidance and interpretations they think appropriate. YMMD, but I hope we can at least agree that those are possible alternatives. best, john From nobody Sat May 7 12:31:27 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D30F12D0E6 for ; Sat, 7 May 2016 12:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 tgAbIU4b3_4h for ; Sat, 7 May 2016 12:31: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 C764512D0B9 for ; Sat, 7 May 2016 12:31:24 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1az7wh-000OkZ-La; Sat, 07 May 2016 15:31:23 -0400 Date: Sat, 07 May 2016 15:31:18 -0400 From: John C Klensin To: Sean Leonard , urn@ietf.org Message-ID: In-Reply-To: <22f6a3f3-c3a6-f03b-c366-a91acbe8c632@seantek.com> References: <2C60969953BC849FDA35733E@JcK-HP8200.jck.com> <53928f62-3de9-567b-e8dc-444a5c66d477@gmx.de> <2F02EA4EFFCD81CD6ADBB789@JcK-HP8200.jck.com> <8abad67b-a439-6168-ed46-1713fe32ba90@seantek.com> <22f6a3f3-c3a6-f03b-c366-a91acbe8c632@seantek.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.10 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] q-component copied verbatim X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 19:31:26 -0000 Sean, Reply inline. I've removed parts that don't seem to be leading in a constructive direction and, for the same reason, comments quite narrowly on some text. Others may, of course, have comments on them. It is probably worth reading through the "personal observations" note I just posted before reading this one. --On Friday, May 06, 2016 22:43 -0700 Sean Leonard wrote: >... > It does not exist; your point is irrelevant. The issue is that > the q-component is copied "verbatim" into the query component > (appended? prepended? randomly interspersed?) of the URL. In > any event, the text itself says that the so-called q-component > is not part of the "URN" and does not affect "URN = equivalence". I will look at the "not part of the URN" text. Independent of questions of equivalence (see other subthread) if q-components are not somehow part of the URN, then they are out of scope for 2141bis and we should be saying "here is the syntax, content undefined" as the text more or less did before we had the discussion about namespace independence I don't think we can go there without reopening the namespace independence question as well as the notion of discussing escaping in the text, but you are welcome to try to convince the WG Chairs otherwise. >> I am guessing that the >> developers of every sensible namespace from which URNs = resolve >> to URLs will have at least some control over the way those >> URLs are constructed. >=20 > This assumes that "developers of namespaces" get to dictate > unequivocally how URNs get put together, which is contradicted > by the text (Section 6.4.6), and by common sense. "URN > resolvers"--not namespace developers--do the conversion from > URNs to URLs. However, absent a standard for resolvers specified as part of the URN (see comments about what what is or is not part of a URN) as you suggested earlier, the choice of resolvers for a namespace is a function of the namespace definition. Certainly someone defining or registering a namespace could pick a resolver (or mechanism for finding one) that would not work well with the requirements of that namespace, but I don't see protecting people from their own stupidity as a design requirement. YMMD. >... >> If you are trying to make a point about quoting or escaping, >> remember that we tried to construct such text and were told = by >> the 3986 community that it wasn't necessary and that all the >> rules were clear and worked. > Cite the conversation and cite the section of the draft. I > never heard such a thing from the "3986 community". I don't > even know who they are. >=20 > The rules for %-encoding are "clear and worked", but you have > to say that you are doing them, under what circumstances, and > why. We tried doing that and were basically told that those rules were a property of RFC 3986 and we didn't need to try to address them. >... > At present, the character sequence ?+ is potentially under the > control of an attacking party, and can't be represented in the > output safely, consistently, or deterministically. I guess I'm less excited about that than you are because I see so many other things about URIs that are "under the control of an attacking party" that this one pales into insignificance. The most obvious (and perhaps most heavily exercised) involve a URI of http://www.mybank.com/ being written by an attacker (for selection by a user) as http://www.mybank.com.badguy.example/ or as http://www.m=D1=83bank.com/. We've developed all sorts of mechanisms to help defend against such attacks, and maybe the urn scheme, will need similar mechanisms, but we don't assume that the URI spec, or even the HTTP scheme spec, should bear all of the burden of defending against them, much less that a URI must be attack-proof. >... > As written, Section 8 of draft-16 is materially deficient. > Section 8 (Security and Privacy Considerations) needs to say: > "?+ cannot safely be represented in q-component. URN composing > software must filter out such sequences, which means that ?+ > can never be part of the query of a URL resolved from a URN." I'll let those who believe that the escaping mechanisms of 3986 are all that is necessary and sufficient to deal with this issue speak up (again) before trying to change the text (again). john From nobody Sun May 8 04:05:03 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEBA12D18F for ; Sun, 8 May 2016 04:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 hkfkebD_CIVF for ; Sun, 8 May 2016 04:04:59 -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 C6F8512D166 for ; Sun, 8 May 2016 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 u48B4eB7019479; Sun, 8 May 2016 12:04:40 +0100 (BST) 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 u48B4cRB004804; Sun, 8 May 2016 12:04:39 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id u48B4cxC024542; Sun, 8 May 2016 12:04:38 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id u48B4b33024541; Sun, 8 May 2016 12:04:37 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: John C Klensin References: <2C60969953BC849FDA35733E@JcK-HP8200.jck.com> <53928f62-3de9-567b-e8dc-444a5c66d477@gmx.de> <2F02EA4EFFCD81CD6ADBB789@JcK-HP8200.jck.com> <7883335563DB29FFAF9BE5DB@JcK-HP8200.jck.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Sun, 08 May 2016 12:04:37 +0100 In-Reply-To: <7883335563DB29FFAF9BE5DB@JcK-HP8200.jck.com> (John C. Klensin's message of "Fri\, 06 May 2016 14\:42\:43 -0400") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (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: Julian Reschke , urn@ietf.org Subject: Re: [urn] q-component copied verbatim X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2016 11:05:02 -0000 John C Klensin writes: > --On Friday, May 06, 2016 17:51 +0100 "Henry S. Thompson" > wrote: > >> John C Klensin writes: >> >> ... >> None of the edits address my question, so I'll repeat it: > > Sorry. Didn't understand the question in the context of other > comments about that text. > >> "If a URN resolves to a URL, the q-component from the URN is >> copied verbatim to the query component of the URL." >> >> "is copied"? By whom? Under what circumstances? Is this >> meant as a MUST or a SHOULD wrt conformant resolution >> services? Or advice to user agents that if they get a URL in >> response (with what response code?) to a resolution request >> for a (URN with a q-component), they should do such a copy? >> >> I suggest that either there needs to be rather more >> explanation here, or this sentence should just be removed. > > As a bit of history ... I agree that some material at a URN-generic level is appropriate here. > ['is' vs. 'MUST' vs. 'SHOULD'] Sorry to be difficult again, but my main concern was not the language, but the addressee: >> "is copied"? By whom? Under what circumstances? [directed at] >> conformant resolution services? Or advice to user agents that if >> they get a URL in response (with what response code?) to a resolution >> request for a (URN with a q-component), they should do such a copy? Stipulate we're talking about conformance, the question of "by whom" seems important, but not addressed. Would it work to simply treat this as a kind of in-principle example, by reordering the paragraph? That is, along the lines of The URN q-component has the same syntax as the URI query component, but is introduced by "?=", not the "?" alone. For URNs which may be resolved to a URL, the semantics of the q-component are identical to those for queries to the resource located via that URL. So URN resolvers returning a URL for a URN with a q-component do this by copying the q-component from the URN verbatim to the query component of the URL. If the URN does not resolve to a URL the interpretation of the q-component is undefined by this specification. [I've kept some wording I find awkward to minimise the difference with the existing text -- other things being equal I'd also prefer those for queries to the resource located via that URL ==> those for the query component of that URL ] 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 Sun May 8 08:21:38 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBA612D093 for ; Sun, 8 May 2016 08:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 xJrKgYpGYwDB for ; Sun, 8 May 2016 08:21:35 -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 2EB2512B034 for ; Sun, 8 May 2016 08:21:35 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1azQWP-0001OK-1A; Sun, 08 May 2016 11:21:29 -0400 Date: Sun, 08 May 2016 11:21:24 -0400 From: John C Klensin To: "Henry S. Thompson" Message-ID: <96CD7976C66DD563194A554B@JcK-HP8200.jck.com> In-Reply-To: References: <2C60969953BC849FDA35733E@JcK-HP8200.jck.com> <53928f62-3de9-567b-e8dc-444a5c66d477@gmx.de> <2F02EA4EFFCD81CD6ADBB789@JcK-HP8200.jck.com> <7883335563DB29FFAF9BE5DB@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.10 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: Julian Reschke , urn@ietf.org Subject: Re: [urn] q-component copied verbatim X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2016 15:21:36 -0000 --On Sunday, May 08, 2016 12:04 +0100 "Henry S. Thompson" wrote: >... > Would it work to simply treat this as a kind of in-principle > example, by reordering the paragraph? That is, along the > lines of > > The URN q-component has the same syntax as the URI query > component, but is introduced by "?=", not the "?" alone. > For URNs which may be resolved to a URL, the semantics of > the q-component are identical to those for queries to the > resource located via that URL. So URN resolvers returning > a URL for a URN with a q-component do this by copying the > q-component from the URN verbatim to the query component of > the URL. If the URN does not resolve to a URL the > interpretation of the q-component is undefined by this > specification. > > [I've kept some wording I find awkward to minimise the > difference with the existing text -- other things being equal > I'd also prefer > > those for queries to the resource located via that URL > ==> > those for the query component of that URL > > ] Wfm, including the latter. Would others please comment, especially if they have objections, before I change the text? john From nobody Tue May 10 21:54:05 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816EB12D0FE for ; Tue, 10 May 2016 21:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=helsinkifi.onmicrosoft.com 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 q5-cqEqlwkDG for ; Tue, 10 May 2016 21:54:01 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0102.outbound.protection.outlook.com [104.47.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92CA512D0AE for ; Tue, 10 May 2016 21:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AGv2jfYdZno6ZOb+QHH88NaY8fbYc3/bEi2GbMsP/BA=; b=NSxnRB2+cjYyxStq4c7y+zV6hGSRfkubdBL/Ujmauw1bjYwPmcDSUS9yDkkC8ClqwOH4wt0zvlBDs2fnC5perKKtFiMH21LbAP4dlQnQKBlwxGK6DhU+yeyrvIG/1g9nr0VEa/8GeDJyJerht6gUP18/w9rcj9/dS5oS+QeF074= Received: from VI1PR07MB1727.eurprd07.prod.outlook.com (10.166.143.23) by VI1PR07MB1725.eurprd07.prod.outlook.com (10.166.143.21) with Microsoft SMTP Server (TLS) id 15.1.492.11; Wed, 11 May 2016 04:53:57 +0000 Received: from VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) by VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) with mapi id 15.01.0492.016; Wed, 11 May 2016 04:53:57 +0000 From: "Hakala, Juha E" To: Sean Leonard , "urn@ietf.org" Thread-Topic: [urn] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16 Thread-Index: AQHRpV/TMIuyi+Lw+0euW+3gBdDQsZ+nxYQAgAD+/JCAAA1PgIAKSO8Q Date: Wed, 11 May 2016 04:53:57 +0000 Message-ID: References: <383E74C93A059E95C9B5A4E7@JcK-HP8200.jck.com> <2dc60ca4-131e-1bb0-1dbf-07db83766972@seantek.com> In-Reply-To: <2dc60ca4-131e-1bb0-1dbf-07db83766972@seantek.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: seantek.com; dkim=none (message not signed) header.d=none;seantek.com; dmarc=none action=none header.from=helsinki.fi; x-originating-ip: [210.48.175.44] x-ms-office365-filtering-correlation-id: 0cdcbd77-ee1c-48f9-60f9-08d3795842dc x-microsoft-exchange-diagnostics: 1; VI1PR07MB1725; 5:Ndf2+GdgfPcR6851yDqPEd3LSePTNWOYHlf2Ct9j6TRbndsoCOkSeb/cCbhFKnKx4eRaMxSE5t146/WDmTmWjXxrUGuKJgRAhlr8OCmoaBHZZkFA79HsRuwr86F5/xs28c6yKwIgrpcZ8j0ttKpobg==; 24:NtvJsGm8hwQ0axn/GxxXChdNNcLlekQbNp6rBVMz33soUcGlaz/FbdmmEUEuyzyrtOAuEbrgoOrTRIVc8VkFNt5yPV6u/qS7/g3kRNh5vW4=; 7:XXZncg1o/MEdIXElwPMEiNq+HPnnlyr/lXva7OxA6UIOD+8zHuh+jqhuOAH/EaFEwFkDhjQqMl5oTaQ94qDS+WhWzf2TGKH3CYdATAKzRCcp7QyKITSwBtHzhPdzB7OuBN5yQhnU6NtQUvfHTfdMusol/MRj871cFMCKk1WFN3t/H3F48mGEkvGQ4+PYN1Ix x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1725; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR07MB1725; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1725; x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(24454002)(2900100001)(33656002)(2950100001)(106116001)(93886004)(5002640100001)(1220700001)(15975445007)(87936001)(10400500002)(77096005)(586003)(66066001)(6116002)(92566002)(102836003)(3846002)(74316001)(76576001)(2501003)(50986999)(3280700002)(86362001)(5004730100002)(76176999)(54356999)(11100500001)(3660700001)(5001770100001)(5008740100001)(9686002)(74482002)(19580405001)(19580395003)(230783001)(2906002)(189998001)(122556002)(8936002)(81166006)(107886002)(5003600100002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1725; H:VI1PR07MB1727.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2016 04:53:57.2381 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1725 Archived-At: Subject: Re: [urn] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 04:54:04 -0000 Hello,=20 some comments below=20 > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Sean Leonard > Sent: 4. toukokuuta 2016 17:07 > To: urn@ietf.org > Subject: Re: [urn] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16 >=20 > On 5/4/2016 6:19 AM, Henry S. Thompson wrote: > > [...] > > (It's perhaps worth noting a further parallel: Contesting such a > > labelling requires appealing to the person who produced the referring > > word or expression: when you said such-and-such, what did you mean to > > refer to? And as far as 3986 is concerned, the same is true for URIs: > > the ultimate authority for questions about what is identified by a URI > > is, and can only be, the minter of that URI.) It is not this simple in the URN environment. Assignment of URNs is a manag= ed process, and the agency which is responsible of the namespace provides t= he rules for what can be identified by URNs in that namespace. So an organi= zation - for instance, a publisher - which mints a URN from urn:isbn namesp= ace is not an authority, but just applying its narrow mandate to identify i= ts own books. The authority is limited to saying that this urn:isbn identif= ies this book. And if the publisher makes a mistake - such as a typo in isb= n, or re-assignment of isbn that has already been used, etc. - the national= ISBN center will correct the problem.=20 Assignment of URIs is very seldom a managed process in any sense that commu= nities using persistent identifiers would use in the context.=20 =20 > > > > It follows, I think, that urnbis can use 'resource' in exactly the way > > it is used in 3986, referencing 3986 for that purpose in section 1.1. > > > > Indeed it _should_ do so, because otherwise it does what it accuses > > 3986 of doing, only more so, by using both 'resource' and 'service' > > without defining them, or explaining how to tell which of the two is > > identified by a URN. Each URN namespace has its own view of which resources can be identified. S= copes of namespaces will overlap, and some namespaces may have much broader= scopes than others, but namespace registrations and possibly some addition= al documentation will still describe what kind of resources are identifiabl= e. Since there are these descriptions of what identifiable resources are, I= MO URN syntax document does not need to give a generic definition of what a= resource is. On the other hand, we do not know the scopes of future namesp= aces, and therefore it would only be possible to give a very generic defini= tion, like URI 3986 does. =20 According to RFC 3986 resource can be anything, from - literally - zero to = infinity. I am not sure how useful that kind of "definition" is when we tal= k about resource identification in any proper sense of the word. Broad defi= nition creates an impression that assigning URIs to these resources cannot = even in principle be a managed process. According to RFC 3986 anyone can id= entify anything and somehow this does not result in a mess. In the light of= practical experience of e.g. URI longevity this seems optimistic.=20 > > PS The fact that 3986 doesn't come particularly clean about how one > > might in principle answer questions of the form "What is identified by > > this URI" or "Can I use this URI to identify [...]" is arguably a bug. It is not possible to always answer these questions unless URI assignment i= n its entirety is a well managed process, which it is not, either now or in= the future. I mean, it may be possible to manage URIs in small, controlled= environments such as W3C web server, but in the Web scale it seems to be i= mpossible to achieve sufficient control, in spite of efforts to provide gui= delines on how to create URIs and keep them alive.=20 =20 > > > > urnbis is in a particularly good position to fix this for URNs. Yes, provided that namespaces are properly managed. This does not need to b= e the case, if IETF approves namespace registrations which are not solid en= ough.=20 Best regards,=20 Juha >=20 > Yes. >=20 > Sean >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Thu May 12 19:22:02 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353DB12B027 for ; Thu, 12 May 2016 19:22:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=helsinkifi.onmicrosoft.com 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 AcvBF1ePbayG for ; Thu, 12 May 2016 19:21:57 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0765.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::765]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C50DC12B049 for ; Thu, 12 May 2016 19:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MOl5DZq4L8vsaiXGV6KRKyKx9vhw+TT/QVrmVh62cM4=; b=DtgWWgK+0bf2fExfv4GAPGGzGBpL/4rQPmjAXYXXrOFpY+443PVaMpa0IFnrU7Ufpt9F62BMxrk6DAbXgvK3z/Em3x2TIklcc+GNfDrpBQJsoIDKrAk1EZTQ1eJShwAmCSXvron7ByWFxRuzIKHkNz7vFbZX+dOLDaadbHevtYQ= Received: from VI1PR07MB1727.eurprd07.prod.outlook.com (10.166.143.23) by VI1PR07MB1727.eurprd07.prod.outlook.com (10.166.143.23) with Microsoft SMTP Server (TLS) id 15.1.497.12; Fri, 13 May 2016 02:21:36 +0000 Received: from VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) by VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) with mapi id 15.01.0497.014; Fri, 13 May 2016 02:21:36 +0000 From: "Hakala, Juha E" To: "Henry S. Thompson" , John C Klensin Thread-Topic: [urn] q-component copied verbatim Thread-Index: AQHRp2JyAYTIOuYWSkCFALWr4voQfp+r3wwAgABBsfWACgDdUA== Date: Fri, 13 May 2016 02:21:36 +0000 Message-ID: References: <2C60969953BC849FDA35733E@JcK-HP8200.jck.com> <53928f62-3de9-567b-e8dc-444a5c66d477@gmx.de> <2F02EA4EFFCD81CD6ADBB789@JcK-HP8200.jck.com> In-Reply-To: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: inf.ed.ac.uk; dkim=none (message not signed) header.d=none;inf.ed.ac.uk; dmarc=none action=none header.from=helsinki.fi; x-originating-ip: [203.97.82.22] x-ms-office365-filtering-correlation-id: 6693369f-fcad-4a43-4bbf-08d37ad54f77 x-microsoft-exchange-diagnostics: 1; VI1PR07MB1727; 5:ZdJohWgpVyU0bufQ+oOUDTn4ADTCVbZQtT7+EJX5quV3gLSICk7qzMTAPcTsIWfnVM7qyMRDAWmcIlBLNKTqUYBkpmnafcRvykfFplm8mrHfL28u558h2Nwy98rV33eT6Hxqv9Fxa7Djl7K+FJNR1A==; 24:rJkBMl933DOu2nBn2bEEIa2fRa2jprm2wNW+hlFEewIg++y37YMF5XnnS9P37a/J+O+IyFJwESwyZyZmw3Nk6nQswW1WASpwRH4/Uz/xg/k=; 7:80mzZ72o4is8AHM7S0rq6UA4kf9ne+wuxoJSBfSQdoj1yMN0Apq0CGW932MHLhcYumE0HhwTFGDDq1wjWZCI6fNGmMcbUAyNqKYMdfVMCsNrbLsmB2UCn2k8koqf2vKyqIGuRw2VhF2QHJBxXLGCJKG7SIWMnaxLwCSEg3YjddOgNY/tEV06/YPbGFb8DFyT x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1727; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:VI1PR07MB1727; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1727; x-forefront-prvs: 0941B96580 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(43544003)(252514010)(122556002)(77096005)(15198665003)(5002640100001)(76176999)(54356999)(8936002)(5004730100002)(106116001)(15395725005)(15975445007)(11100500001)(87936001)(189998001)(74316001)(9686002)(93886004)(586003)(6116002)(102836003)(10400500002)(5008740100001)(19580395003)(1220700001)(2950100001)(2900100001)(3846002)(19580405001)(92566002)(5001770100001)(81166006)(50986999)(5003600100002)(74482002)(3280700002)(2906002)(4326007)(3660700001)(8676002)(76576001)(86362001)(33656002)(7059030)(10090945008)(19477635001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1727; H:VI1PR07MB1727.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2016 02:21:36.3275 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1727 Archived-At: Cc: Julian Reschke , "urn@ietf.org" Subject: Re: [urn] q-component copied verbatim X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 02:22:01 -0000 Hello Henry; all,=20 comments below.=20 > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Henry S. Thompson > Sent: 6. toukokuuta 2016 19:51 > To: John C Klensin > Cc: Julian Reschke ; urn@ietf.org > Subject: Re: [urn] q-component copied verbatim > >=20 > None of the edits address my question, so I'll repeat it: >=20 > "If a URN resolves to a URL, the q-component from the URN is copied > verbatim to the query component of the URL." >=20 > "is copied"? By whom? Under what circumstances? Is this meant as a > MUST or a SHOULD wrt conformant resolution services? Or advice to user > agents that if they get a URL in response (with what response code?) to a > resolution request for a (URN with a q-component), they should do such a > copy? The q-component will usually be copied by a URN resolver when it maps the U= RN into one or more URLs.=20 An example below is of a use case in which a user wants Dublin Core metadat= a about the resource:=20 Original URN is URN:ISBN:0888543433 In the user interface of the client the user has at hand, the user ticks th= e relevant options: Dublin Core metadata, 1 to 10 records. The user does no= t need to know the target database(s) that will be able to respond; resolve= r will take care of that. =20 Behind the screens, the client produces a URN with an appropriate q compone= nt, which in this case is based on the SRU protocol that is widely supporte= d in library systems.=20 URN:ISBN:0888543433?=3Dversion=3D1.1&operation=3DsearchRetrieve&startRecord= =3D1&maximumRecords=3D10&recordSchema=3Ddc&query=3D0888543433=20 As there is no global resolver discovery service in place yet, this is expr= essed as HTTP URI, for instance=20 http://urn.fi/URN:ISBN:0888543433?=3Dversion=3D1.1&operation=3DsearchRetrie= ve&startRecord=3D1&maximumRecords=3D10&recordSchema=3Ddc&query=3D0888543433 The resolver creates a URL needed to pass the request to the SRU server in = the Bibsys database in Norway:=20 http://sru.bibsys.no/search/biblio?version=3D1.1&operation=3DsearchRetrieve= &startRecord=3D1&maximumRecords=3D10&recordSchema=3Ddc&query=3D0888543433 If Norway makes the decision to close the national union catalogue and repl= ace it with some other, possibly international system (similar change of th= e guards has just been done in New Zealand) the resolver is instructed to r= esolve the URN into a different URL. Query syntax, because it is standard b= ased, should not change.=20 Query syntax will change if and when SRU is updated. Then client applicatio= ns and resolvers need to modernized. ISBN of course does not change, and si= nce the URN + q-component does not identify the retrieved record / records,= these changes have no impact on that level. Bibliographic records, by the = way, are never identified with ISBN but other systems such as LCCN, Library= of Congress Catalog Number.=20 >=20 > I suggest that either there needs to be rather more explanation here, or = this > sentence should just be removed. I hope this helps. Removing the sentence would not be an improvement.=20 Juha >=20 > ht > -- > Henry S. Thompson, School of Informatics, University of Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-444= 0 > 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] >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Fri May 13 02:14:52 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C26F12D0E8 for ; Fri, 13 May 2016 02:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 KIpEKm3BqsY8 for ; Fri, 13 May 2016 02:14:47 -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 D999E12D0A9 for ; Fri, 13 May 2016 02:14:46 -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 u4D9ENZg013299; Fri, 13 May 2016 10:14:27 +0100 (BST) 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 u4D9EMvf018860; Fri, 13 May 2016 10:14:22 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id u4D9EMA6005012; Fri, 13 May 2016 10:14:22 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id u4D9EL8T005011; Fri, 13 May 2016 10:14:21 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: "Hakala\, Juha E" References: <2C60969953BC849FDA35733E@JcK-HP8200.jck.com> <53928f62-3de9-567b-e8dc-444a5c66d477@gmx.de> <2F02EA4EFFCD81CD6ADBB789@JcK-HP8200.jck.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 13 May 2016 10:14:21 +0100 In-Reply-To: (Juha E. Hakala's message of "Fri\, 13 May 2016 02\:21\:36 +0000") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (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: Julian Reschke , "urn@ietf.org" Subject: Re: [urn] q-component copied verbatim X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 09:14:50 -0000 Hakala, Juha E writes: > comments below. Thanks -- I did understand the intent, I just wasn't sure the prose adequately conveyed it. See my subsequent message in this thread for a proposed rewording, and then John's request for comment on _that_. 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 Sun May 15 01:37:24 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898D012D13D for ; Sun, 15 May 2016 01:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 5F1Sey3UffSW for ; Sun, 15 May 2016 01:37:21 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 944C812D148 for ; Sun, 15 May 2016 01:37:21 -0700 (PDT) Received: from [192.168.123.151] (unknown [75.83.2.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 88A2A509B8; Sun, 15 May 2016 04:37:17 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: Date: Sun, 15 May 2016 01:37:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8FB16EBB-71D8-4A90-8244-AFB4C7005AAA@seantek.com> References: <2C60969953BC849FDA35733E@JcK-HP8200.jck.com> <53928f62-3de9-567b-e8dc-444a5c66d477@gmx.de> <2F02EA4EFFCD81CD6ADBB789@JcK-HP8200.jck.com> To: "Hakala, Juha E" , "urn@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Julian Reschke Subject: Re: [urn] q-component copied verbatim X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 08:37:23 -0000 Thanks for the concrete example, Juha. > On May 12, 2016, at 7:21 PM, Hakala, Juha E = wrote: >=20 > Hello Henry; all,=20 >=20 > comments below.=20 >=20 >> -----Original Message----- >> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Henry S. = Thompson >> Sent: 6. toukokuuta 2016 19:51 >> To: John C Klensin >> Cc: Julian Reschke ; urn@ietf.org >> Subject: Re: [urn] q-component copied verbatim >>>=20 >> None of the edits address my question, so I'll repeat it: >>=20 >> "If a URN resolves to a URL, the q-component from the URN is copied >> verbatim to the query component of the URL." >>=20 >> "is copied"? By whom? Under what circumstances? Is this meant as a >> MUST or a SHOULD wrt conformant resolution services? Or advice to = user >> agents that if they get a URL in response (with what response code?) = to a >> resolution request for a (URN with a q-component), they should do = such a >> copy? >=20 > The q-component will usually be copied by a URN resolver when it maps = the URN into one or more URLs.=20 In your very useful example, you are saying that the URN resolver is = going to see the q-component, and put it in the resulting URL(s). But in prior discussions, a motivator for the q-component was = =E2=80=9Cprivacy=E2=80=9D, namely, that resolvers can see the = r-component but not the q-component. The implication was that URN client = applications would take the results of the resolver and do their own = merging on the client side. This example supports the premise that URN resolvers see the entire = query production (q-component and r-component), and are expected to = return complete URLs to a URN client, with the q-component folded into = the URLs. Consequently, we have a distinction without a difference = between q-component and r-component. They should be merged into one = (i.e., query =3D=3D=3D r-component). (This distinction is where Henry Thompson expresses his concern about = =E2=80=9Cis copied=E2=80=9D? By whom? Under what circumstances?) >=20 > An example below is of a use case in which a user wants Dublin Core = metadata about the resource:=20 >=20 > Original URN is URN:ISBN:0888543433 >=20 > In the user interface of the client the user has at hand, the user = ticks the relevant options: Dublin Core metadata, 1 to 10 records. The = user does not need to know the target database(s) that will be able to = respond; resolver will take care of that. =20 >=20 > Behind the screens, the client produces a URN with an appropriate q = component, which in this case is based on the SRU protocol that is = widely supported in library systems.=20 >=20 > = URN:ISBN:0888543433?=3Dversion=3D1.1&operation=3DsearchRetrieve&startRecor= d=3D1&maximumRecords=3D10&recordSchema=3Ddc&query=3D0888543433=20 >=20 > As there is no global resolver discovery service in place yet, this is = expressed as HTTP URI, for instance=20 >=20 > = http://urn.fi/URN:ISBN:0888543433?=3Dversion=3D1.1&operation=3DsearchRetri= eve&startRecord=3D1&maximumRecords=3D10&recordSchema=3Ddc&query=3D08885434= 33 >=20 > The resolver creates a URL needed to pass the request to the SRU = server in the Bibsys database in Norway:=20 >=20 > = http://sru.bibsys.no/search/biblio?version=3D1.1&operation=3DsearchRetriev= e&startRecord=3D1&maximumRecords=3D10&recordSchema=3Ddc&query=3D0888543433= >=20 > If Norway makes the decision to close the national union catalogue and = replace it with some other, possibly international system (similar = change of the guards has just been done in New Zealand) the resolver is = instructed to resolve the URN into a different URL. Query syntax, = because it is standard based, should not change.=20 >=20 > Query syntax will change if and when SRU is updated. Then client = applications and resolvers need to modernized. ISBN of course does not = change, and since the URN + q-component does not identify the retrieved = record / records, these changes have no impact on that level. = Bibliographic records, by the way, are never identified with ISBN but = other systems such as LCCN, Library of Congress Catalog Number.=20 Great example. In this formulation, urn:isbn:0888543433?=3Dversion=3D1.1&... is not annotated with any kind of information that identifies the query = format as SRU. This is a problem because, as you say, all other = components need to be changed if the syntax changes. It would be far more durable to have a formulation like: urn:isbn:0888543433?sru:version=3D1.1&operation=3DsearchRetrieve... I.e., the query component of the URN is structured so that it first = identifies the format of the rest of the query component, followed by a = delimiter (=E2=80=9C:=E2=80=9D), followed by arbitrary data. Then the = URN resolver can take the identifier (=E2=80=9Csru=E2=80=9D) and do the = right thing with it, or forward it to another component that knows what = to do with it, or ignore it, or reject it, etc. The example provided here is fine for HTTP/HTTPS URLs, but it fails on = everything else. Try copying the URN q-component =E2=80=9Cverbatim=E2=80=9D= into the following URI schemes: data ldap ftp gopher magnet ni mid mailto dns file news vnc ...and none of them work the way you want them to (except, perhaps, = Gopher, and that is a stretch because there are all of 70 servers left). Making the URN resolver map the query production to the resulting URL = provides much more flexibility and protocol independence. For example, = the URN resolver can break out the components (version, operation, = startRecord, etc.) and reassemble them into the scheme-specific string, = such as something like = . Regards, Sean >=20 >>=20 >> I suggest that either there needs to be rather more explanation here, = or this >> sentence should just be removed. >=20 > I hope this helps. Removing the sentence would not be an improvement.=20= >=20 > Juha >=20 >>=20 >> 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] >>=20 >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Sun May 15 04:57:51 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AE912D103 for ; Sun, 15 May 2016 04:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 0QN914JZQgQY for ; Sun, 15 May 2016 04:57: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 E0FB812B037 for ; Sun, 15 May 2016 04:57:47 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1b1ug1-000ITo-0H; Sun, 15 May 2016 07:57:41 -0400 Date: Sun, 15 May 2016 07:57:35 -0400 From: John C Klensin To: Sean Leonard , "Hakala, Juha E" , urn@ietf.org Message-ID: <97D4658A88D0D88E2CB054FC@JcK-HP8200.jck.com> In-Reply-To: <8FB16EBB-71D8-4A90-8244-AFB4C7005AAA@seantek.com> References: <2C60969953BC849FDA35733E@JcK-HP8200.jck.com> <53928f62-3de9-567b-e8dc-444a5c66d477@gmx.de> <2F02EA4EFFCD81CD6ADBB789@JcK-HP8200.jck.com> <8FB16EBB-71D8-4A90-8244-AFB4C7005AAA@seantek.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.10 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: Julian Reschke Subject: Re: [urn] q-component copied verbatim X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 11:57:50 -0000 --On Sunday, May 15, 2016 01:37 -0700 Sean Leonard wrote: >... > In your very useful example, you are saying that the URN > resolver is going to see the q-component, and put it in the > resulting URL(s). > > But in prior discussions, a motivator for the q-component was > "privacy", namely, that resolvers can see the r-component > but not the q-component. The implication was that URN client > applications would take the results of the resolver and do > their own merging on the client side. I don't recall that discussion, certainly not that a privacy claim of that sort was dominant in the q-component discussion. AFAICT, it is not reflected in 2141bis in any way, especially because I've tried to carefully guard against (over Juha's objections btw) turning the architectural description of the pieces and components associated into URNs for a requirement about a particular implementation model. > This example supports the premise that URN resolvers see the > entire query production (q-component and r-component), and are > expected to return complete URLs to a URN client, with the > q-component folded into the URLs. Consequently, we have a > distinction without a difference between q-component and > r-component. They should be merged into one (i.e., query === > r-component). No. There is still a difference. The WG has discussed it at great length. Just as we should not constrain that implementation model out of existence by the language of the spec, we should not require it. Put differently, Juha gave an example of a situation and implementation strategy. He did not claim it was the only possible one. >... >... > The example provided here is fine for HTTP/HTTPS URLs, but it > fails on everything else. Try copying the URN q-component > "verbatim" into the following URI schemes: > data > ldap > ftp First, the text says that the q-component relationships, including the "copied" sentence, applies only to URLs, so arbitrary URI schedules are not relevant here. If you are making a case that scope statement should really say "HTTP or HTTPPS URLs" and there is sympathy for that in the WG, the scope sentence is easily changed. However, it appears to me that, for URLs including at least most of those you have listed, the non-specific language in 3986 about what URI (really URL) processors (or "resources" are supposed to do with queries they don't understand would seem to cover the situations. >... > ...and none of them work the way you want them to (except, > perhaps, Gopher, and that is a stretch because there are all > of 70 servers left). I won't comment here on what I think a criterion of "there are only 70 servers, therefore the protocol or scheme doesn't count" would, if generalized, mean to the Internet. > Making the URN resolver map the query production to the > resulting URL provides much more flexibility and protocol > independence. For example, the URN resolver can break out the > components (version, operation, startRecord, etc.) and > reassemble them into the scheme-specific string, such as > something like > n=searchRetrieve>. Speaking personally, I've argued all along for allowing (but not requiring) that sort of implementation model. I believe that the WG decided rather firmly against it during the discussion of whether q-component handling was a function of the namespace (much less the namespace and specific component string or intermediate resource). AFAICT, the WG decided that q-component handling should be strictly a function of the URN scheme and Peter reflected that in 2141bis in the only way that reflected that WG discussion and made sense, i.e., by direct and uncritical copying. I am still not convinced that was the right decision, but, as long as we allow some implemention flexibility, don't see sufficient justification for reopening the question. If you do, please take it up with the co-chairs. john From nobody Sun May 15 05:48:29 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001FD12D19E for ; Sun, 15 May 2016 05:48:27 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 T5a6zBkZU5Cg for ; Sun, 15 May 2016 05:48:25 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CAF12D18D for ; Sun, 15 May 2016 05:48:24 -0700 (PDT) Received: from [192.168.178.20] ([93.217.89.50]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LwW8p-1bfHa50Ttv-018Iel for ; Sun, 15 May 2016 14:48:22 +0200 To: "urn@ietf.org" References: <231532ef-e195-b73d-4a34-eb445bdd1900@gmx.de> From: Julian Reschke Message-ID: Date: Sun, 15 May 2016 14:48:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <231532ef-e195-b73d-4a34-eb445bdd1900@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:lUSnJr8WQweDH3DoPM4q/LSRnftRpL3kMt1h2x5/mjP5mU7i5oj 9QtiUbgTh2OuYUbpBSXR71Qj+y7mWjGepsQw/K2nNBjcYfWI/e0vqgA/HPfGIWz4FCCtBGv E0exaUKLQXjACjSH+rFqt3F+5z5nGXCZp3glOngaYqOoOBeDt2EixEiMVWlBp0AU101WPOL J3T+mAF53dcKynDI3G7pQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:GXeHWO97TwU=:gw1n4mGA0w1Gz1pKerPzkG Yl83bORbEBdT43yxFnKyhoG7sgoDVCitOqKtIpQmjcbfeXp7Txk5WEFUvacDvpWzWhYsLrFoG dBzTZxzt+7vTaqSTm8+Ovbqgun35rGoybCU3nQ+syrVvxGOYGoAYixJNgU7MddWvyWebR/hyf xY1dJwjCNsuNRB5gS8icVEAugrwOwQaP7HU562Rk0CwqshBdR1f6r9JZiH1NLf7197xRchqSz qwMiTqWGuKiyjN+ThlexinQA969EGqGCOtG6csQCiWz9kQ59K33uliCfYD88f5HBRcu71rRNR R4yU6e6+jorKlbhYAPLuN3zXpo6JlZiBN8PUTNUjtlA5/FgNgJcd9WAV92pvafrOyE+JWJvC+ qMBITso5hOLB7to2XgHxG9E4UWZwqURV5dG633XvAB6QZY25DEpuisyfBD8FjjM/ADHqy3Xw9 FomnlHrhjnKvb/IgJIfGD4LRwQ814KVg+J4csbhfgQPRz4NVwqteeHUr1L1JxtX724p1YaOoC lGx1sXWyEM9Y2aSMm5sp5I8XxjRFcd8tCnFwcniFYGOL3GnTF4HMLfm2Q8XmYfKyas8+B66mU 2uCCkiLXEkiWMbL7lqXEus7UP68Je3Rhk9x5akBb2cWwHQdEEOPmub2igGNWq0W/C5LBeRmFk mbxvcYPLpKcPbjMSqiCf3avsCnPnkD/hDz+wZVWGZtip8QGgIaF+WWbl4p6MX/5FtzP0rPND9 Q4wJmQNKhy5Unj3dYnXzQ/arsehG207JkgMxyPlUoAlf3IgTe9CRxpkaOPEtThLUnXT6nNPj8 56v9b8z Archived-At: Subject: Re: [urn] Feedback on draft-ietf-urnbis-semantics-clarif-03 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 12:48:28 -0000 Hi there, I haven't seen any substantial feedback on what I wrote two weeks ago. Thus here's my attempt to rephrase this in order to get more people to think about it. On draft-ietf-urnbis-semantics-clarif-03: This currently updates RFC 3986. Of course we can do this, but RFC 3986 is a full standard, and thus this draft needs to be crystal clear about what exactly is being updated. I don't think it currently does that; it does some hand-waving with respect to what fragments and queries are (without saying exactly what's wrong in RFC 3986). It does *not* talk about changes to equivalence and relative resolution, although draft-ietf-urnbis-rfc2141bis-urn-16 seems to attempt to change them. Furthermore, it currently contains stuff that has nothing to do at all with the relation to RFC 3986, namely the introduction of new elements that are only relevant to the URN spec; these should be moved over to the other draft. On draft-ietf-urnbis-rfc2141bis-urn-16: This draft seems to rely on draft-ietf-urnbis-semantics-clarif-03, but does not reference it normatively. Furthermore, it appears to redefine relative resolution and equivalence. This is problematic in several ways: It's totally unclear what the intended effect of these redefinitions will be on existing code. Is existing, non-URN-specific code supposed to be changed? If yes, what's the strategy to make this happen? If no (thus it's for URN-specific code only), what's the point in attempting to change the generic framework defined in RFC 3986? Wouldn't it be much much simpler just to - define the new URN-scheme-specific equivalence as such (as described in ), and - define the URN-specific reference resolution as something URN-specific tools can do, but not to pretend that existing URI processors will implement this? Best regards, Julian On 2016-04-27 17:02, Julian Reschke wrote: > Hi there, > > I was asked off-list to review the current drafts, given my interest in > RFC 3986 in the past. > > I was first confused about 2141bis seemingly making changes to 3986, but > then realized that there's draft-ietf-urnbis-semantics-clarif-03 as > well. I believe 2141bis needs to *normatively* reference this one. > > That said, I appreciate that these two are separated, because it's > easier to understand what's going on with relation to 3986. However, the > separation may need more work; this document IMHO contains stuff that > should be in 2141bis, while there's stuff in 2141bis which would need to > be here. > > Other than that see below comments inline (sorry for the format). > > Best regards, Julian > > -- snip -- > > Uniform Resource Names (urnbis) J. Klensin > Internet-Draft February 5, 2016 > Updates: 3986 (if approved) > Intended status: Standards Track > Expires: August 8, 2016 > > > URN Semantics Clarification > draft-ietf-urnbis-semantics-clarif-03.txt > > 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 Information Science 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) in RFC 3986, updating that > > Lack of clarity: this is intended to be standards track document > updating a full internet standard. I don't think that what people > believe about that spec is relevant; we should be able to agree upon > what it says and what it doesn't say. > > document accordingly. The syntax of URNs is still constrained to > that of RFC 3986, so generic URI parsers are unaffected by this > change. > > ...that depends on whether resolution of a relative reference against a > base URI is part of what a URI parser does (do we have a definiton of > what a "URI parser" does?) > > > 1. Introduction > > The Generic URI Syntax specification [RFC3986] covers both locators > and names and mixtures of the two (See its Section 1.1.3) and > describes Uniform Resource Locators (URLs) -- first documented in the > IETF in RFC 1738 [RFC1738] -- as an embodiment of the locator concept > and Uniform Resource Names (URNs), specifically those using the "urn" > scheme [RFC2141], as an embodiment of the names that do not directly > provide for resource location. This specification is concerned only > about URNs of the variety described in RFC 2141 [RFC2141] and its > successors [RFC2141bis] (i.e., those that use the "urn" scheme). > URLs, other types of names, and any URI types that may not fall into > one of the above categories are out of its scope and unaffected by > it. > > I understand that historical context is useful, but do we really need > half a paragraph to say: "this is about URIs using the 'urn' scheme"? > > Experience with URNs since the publication of RFC 3986 has identified > several ways in which their inclusion under the 3986 scope has > hampered understanding, adoption, and especially extension > (specifically extensions of types that were anticipated, but not > defined, in RFC 2141). The need for extensions to the URN concept is > now being felt in some communities, especially those that include > libraries, museums, publishers, and other information scientists. > > In particular, the Generic URI Syntax specification goes beyond > syntax to specify the meaning and interpretation of various fields, > especially the "query" and "fragment" ones and the various syntax > forms and interpretations it allows for . This > > Agreed for "fragment", not sure about "query". Could you elaborate a bit? > > specification excludes URNs from those definitions of meaning and > interpretation so that RFC 3986 applies to their syntax only. The > meaning --and any more specific syntax rules-- for those fields for > URNs are now defined in a URN-specific document [RFC2141bis]. URNs > remain members of the URI family and parsers for generic URI syntax > are not affected by this specification although parsers that make > assumptions based on other URI schemes obviously might be. > > I don't get the last sentence. If a parser makes assumptions on *other* > schemes, how would it affect processing of "urn" URIs? > > Neither this specification nor the successor to RFC 2141 [RFC2141bis] > discusses DDDS [RFC3401] resolution or conversion to (and > interpretation of) URCs [RFC2483] or, with the exception of providing > some syntax to cover some specific cases, URN "resolution" more > generally. Any of those topics that do need to be addressed should > be covered in other documents. The document also does not discuss > alternatives to URNs, either those that might use a different scheme > name within the RFC 3986 URI framework or those that might use a > different framework entirely. In particular, some externally-defined > content or object identification systems could be represented either > by a URN namespace or through separate URI schemes. This > specification does not offer advice on that choice other than to > suggest that the two options not be confused (or both used in a way > that would be confusing). > > (matter of taste: I think that long text about what spec does *not* do > really distracts from what it is about; maybe it would be good to things > like this (and the text about URN's history) to an appendix?) > > This document updates RFC 3986 to make the distinction between syntax > and semantics clear for URNs and to isolate URNs from presumed URI > semantic requiremnts. It is important to note that some readers of > > s/requiremnts/requirements/ > > RFC 3986 are convinced that the separation is clear in that > specification and therefore that no changes to that document are > needed. For them, this specification is only a confirming > clarification. > > I understand that this is well-intended, but it is certainly very very > confusing. > > In the long term, as the expanded syntax and uses of URNs become > commonplace and RFC 3986 is updated, this specification is likely to > become of historical interest only, providing an extended rationale > for decisions made and adjustment of the boundary between URN > specifications and generic URI ones. > > ... > > 3. The role of queries and fragments in URNs > > Part of 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. For > example, RFC 3986 ties the interpretation of fragments to media > types. Since media type is a function of specific content, URNs that > are never resolved cannot have an associated media type, nor can URNs > that resolve to, for example, other URIs that may then not be > > FTR, RFC 3986 says: "If no such representation exists, then the > semantics of the fragment are considered unknown and are effectively > unconstrained. Fragment identifier semantics are independent of the URI > scheme and thus cannot be redefined by scheme specifications." > > resolved further. Similarly, while the RFC 3986 syntax for queries > (and fragments) may be entirely appropriate for URN use, terminology > like "Service Request" (see Appendix B of the predecessor "URNs are > not..." draft [ServiceRequests] for additional discussion) may be > more suitable to the URN context than "query" (if, indeed, the > portion of the URN that is syntactically equivalent to a URI query is > where those requests belong). > > RFC 3986: "The query component contains non-hierarchical data that, > along with data in the path component (Section 3.3), serves to identify > a resource within the scope of the URI's scheme and naming authority (if > any)." -- so what *exactly* does this specification try to change? Just > the name of the component?? > > 4. Changes to RFC 3986 > > This specification removes URN semantics from the scope of RFC 3896. > > s/3896/3986/ > > It makes no changes to the generic URI syntax. That syntax still > applies to URNs as well as to other URI types. Even as regard to > semantics, it has no practical effect for URNs defined in strict > conformance to the prior URN specification [RFC2141] or the > associated registration specification [RFC3406]. > > So what other effect *does* it have? > > In particular (but without altering RFC 3986 in any way), the generic > URI syntax for "queries" (strings starting with "?" and continuing to > the end of the URI or to a "#"), and for "fragments" (strings > starting with "#" and continuing to the end of the URI) is unchanged. > For URNs, additional syntax is introduced to divide the URI "query" > into two parts, referred to as "q-components" and "r-components". > > ...I'd argue that this URN-specific syntax shouldn't be discussed in > *this* specification. > > The syntax and general semantics of "fragments" (specified in RFC > 3986 as scheme-independent) are unchanged, but a somewhat liberal > interpretation may be needed in the context of URNs, so a fragment is > referred to as an "f-component" as a term of convenience to highlight > that distinction. [RFC2141bis]. > > From this paragraph it's entirely unclear what the actual change is. > > 5. Actions Occurring in Parallel with this Specification > > The basic URN syntax specification [RFC2141] was published well > before RFC 3986 and therefore does not depend on it. The successor > to that specification [RFC2141bis], fully spells out, or references > documents that spell out, the semantics and any required within-field > syntax of URNs. It uses great care about generic or implicit > reference to any URI specification and delegates further details to > specific namespaces. > > [[CREF1: Note in Draft: Perhaps this section can be dropped > entirely.]] > > Actually, no. > essentially updates . > This specification needs to be clear about that, because that is > actually the biggest change to RFC 3986, and it's not even mentioned here. > > So if there *was* agreement on that change (which is a separate, > complex, discussion), it really really would need to be mentioned here. > > > .... > > 8. IANA Considerations > > [[CREF2: RFC Editor: Please remove the first paragraph below before > publication.]] > > This memo is not believed to require any action on IANA's part. > > There is an existing (i.e. prior to the publication of this document) > registry for "Uniform Resource Identifier (URI) Schemes" that already > includes the "urn" scheme itself and a separate existing URN > Namespace registry. None of those registrations have any specific > dependencies on generic URI specifications. > > Actually, the second paragraph could go as well... > > 9. Security Considerations > > This specification changes the semantics of URNs to make them self- > contained (as specified in other documents), relying on the generic > URI syntax specification for syntax only. It should have no effect > on Internet security unless the use of a definition, syntax, and > semantics that are more clear reduces the potential for confusion and > consequent vulnerabilities. > > It seems that it's RFC 2142bis which defines these changes, no? > > 10.2. Informative References > > [DeterministicURI] > Mazahir, O., Thaler, D., and G. Montenegro, "Deterministic > URI Encoding", February 2014, draft-montenegro-httpbis-uri-encoding-00.txt>. > > This is an expired document, cited for historical context > only. > > This reference doesn't seem to be used. > > ... > > [URN-transition] > Klensin, J. and J. Hakala, "Uniform Resource Name (URN) > Namespace Registration Transition", Feburary 2016, > reg-transition/>. > > This reference doesn't seem to be used. > > > Appendix A. Background on the URN - URI relationship > > The Internet community now has many years of experience with both > name-type identifiers and location-based identifiers (or "references" > for those who are sensitive to the term "identifier" such as many > members of the library and information science communities.. The > > s/.././ > > primary examples of these two categories are Uniform Resource Names > (URNs [RFC2141] [RFC2141bis]) and Uniform Resource Locators (URLs) > [RFC1738]). That experience leads to the conclusion that it is > impractical to constrain URNs to the high-level semantics of URLs. > The generic syntax for URIs [RFC3986] is adequately flexible to > accommodate the perceived needs of URNs, but the specific semantics > associated with the URI syntax definition -- what particular > constructions "mean" and how and where they are interpreted -- appear > to not be. Generalization from URLs to generic Uniform Resource > Identifiers (URIs) [RFC3986], especially to name-based, high- > stability, long-persistence, identifiers such as many URNs, has > failed because the assumed similarities do not adequately extend to > all forms of URNs. Ultimately, locators, which typically depend on > particular accessing protocols and a specification relative to some > physical space or network topology, are simply different creatures > from long-persistence, location-independent, object identifiers. The > syntax and semantic constraints that are appropriate for locators are > either irrelevant to or interfere with the needs of resource names as > a class. That was tolerable as long as the URN system didn't need > additional capabilities (over those specified in RFC 2141) but > experience since RFC 2141 was published has shown that they are, in > fact, needed. > > I don't believe this appendix is way too vague to be helpful. > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > From nobody Sun May 15 08:44:15 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A43012D125 for ; Sun, 15 May 2016 08:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 c4E4i7r6eApa for ; Sun, 15 May 2016 08:44:11 -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 7E5CD12D0F6 for ; Sun, 15 May 2016 08:44:11 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1b1yDA-000JkI-Nr; Sun, 15 May 2016 11:44:08 -0400 Date: Sun, 15 May 2016 11:44:03 -0400 From: John C Klensin To: Julian Reschke , urn@ietf.org Message-ID: <1F5D414703BF94503600A5E3@JcK-HP8200.jck.com> In-Reply-To: References: <231532ef-e195-b73d-4a34-eb445bdd1900@gmx.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.10 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] Feedback on draft-ietf-urnbis-semantics-clarif-03 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 15:44:13 -0000 --On Sunday, May 15, 2016 14:48 +0200 Julian Reschke wrote: > Hi there, > > I haven't seen any substantial feedback on what I wrote two > weeks ago. Thus here's my attempt to rephrase this in order to > get more people to think about it. I have been waiting for the co-chairs to take a position on whether you are reopening an old topic and will continue to wait. The difference between this topic and those to which I have been responding (to at least a subset) is that, while I believe we discussed those others and move on, my recollection is that Andy made a formal consensus call and closed this one. If we start revisiting old topics without substantial new information, it very nearly guarantees that we will never get finished. Reluctantly and against my better judgment, but in the interests of saving time, a clarification below. > On draft-ietf-urnbis-semantics-clarif-03: > > This currently updates RFC 3986. Of course we can do this, but > RFC 3986 is a full standard, and thus this draft needs to be > crystal clear about what exactly is being updated. I don't > think it currently does that; it does some hand-waving with > respect to what fragments and queries are (without saying > exactly what's wrong in RFC 3986). It does *not* talk about > changes to equivalence and relative resolution, although > draft-ietf-urnbis-rfc2141bis-urn-16 seems to attempt to change > them. The update to 3986 is to remove URNs from the scope of URNs except with regard to URI syntax. 3986 says, effectively, that URNs are just like any other URIs; the "update" is that they they are not. The informal description of draft-ietf-urnbis-semantics-clarif as "syntax only" is consistent with that. That particular "syntax only" decision has some fairly sweeping implications, which were discussed at the time. In particular, it makes the definitions in 3986 --either whatever precise ones appear or whatever oral tradition they have accumulated in other forums -- irrelevant: they are not syntax. So one can argue, for example, that the way draft-ietf-urnbis-semantics-clarif uses the term "resource" or distinctions it attempts to make about it are undesirable, but one cannot appeal to inconsistency with 3986 to support that view. In addition, to the degree to which the WG has already closed out this issue, an argument about inappropriateness is presumably out of order unless it includes fundamentally new arguments. However, again, that requires a judgment by the co-chairs. Some of Juha's recent comments highlight another reason for making the "syntax only" distinction and drawing a hard line with it: the usage (I'm reluctant to say "definition") of the term "identifier" in 3986 is incompatible with the meaning and use of that term in the library and information sciences community. Making progress on URNs requires, at least IMO, not trying to resolve that incompatibility but does require that the terminology of 3986 not be treated as authoritative for URNs. As to what should be in which document, the status of draft-ietf-urnbis-semantics-clarif has, for a long time, been "decide whether to fold all or part of this into 2141bis when the WG has consensus about the substantive content of the latter". I've been reluctant to do a major merge because of concern about introducing mistakes in the process, but am happy to try to do whatever the WG actually wants. Finally, the "syntax only" separation is intended to remove the implication that URNs (at least of the "urn:" scheme, but that was deliberately left ambigious) are separate from all other URIs (if one believes that the language of 3986 creates a dichotomy, "all other URIs" == "URLs") and therefore that questions like "how does this affect URL processors?" have a uniform answer of "not at all, because even 3986 says that URNs are not URLs". best, john From nobody Tue May 17 08:38:48 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3382D12D9CF for ; Tue, 17 May 2016 08:38:47 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hxr-us.20150623.gappssmtp.com 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 z8ttwmZde2lr for ; Tue, 17 May 2016 08:38:44 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 310AA12D9CC for ; Tue, 17 May 2016 08:38:44 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id g17so37966526wme.1 for ; Tue, 17 May 2016 08:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/hY2FdC78Xn+lNnPhdQDMew4PzmWZ8wHWCintR4wHtI=; b=RqzOSnwLzkF9Egl9HUnwB/vqMm6dce4alDTYWurzou5EPQWzz+quHwrkI+Cbwafjm3 l59k8xRIK8fq6roFCuZHehAVXo5LkhphOEOf7fFBUGvAw/Skykum4BAFmaR3AtLWDdV1 pvSD0thnKxQ9k4sY33Db3rjDVP14djbQdT6rzV4u0fUlYIRiFDdL77YILcJToP8cHjGh 8Fu2qUI6eDytDelu55EbCKhaxZNlq1ABLHzxskKFIIA6UnPtXsQ8bIo8WJb06KHgZfwT 1wUiwI7J/5tIVv+87SGL169vM5V09SIGhFJKeHczWo3T5y+kV2GQJJUKehgE/X0g4IN+ uZCA== 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; bh=/hY2FdC78Xn+lNnPhdQDMew4PzmWZ8wHWCintR4wHtI=; b=mPNOy7gchqfp0E7shC5HH/GJftBCr4OjIwKN1FMN9sO4PcHoF7LVm4yQB+pVveraDA 21xmz8X0YCC2YVmtLiB8rnMhfAxjgP+uc8HpRHrVAErfxsiMaVqwSLJUaIBdUgNbKyp4 eH4YnBjv7Tg4XOm1rCosD7MxeFPKYpwx59CcL1bW3LyyID32zd/vQgNLA7My/OARss2o QhM//G+yVCmBROOTvms6E4bN/0wzFv+HLwOfoicu6gsvMkfyt3TqqmY7twW1xzaC6ZsG /7/piuuAFTeRGGHdafY39YHrE3xHd/+f02NJfrNNukfZoCI/xCisxUy6i5xA8IBmb+sd 0d+w== X-Gm-Message-State: AOPr4FVuUVFWWBSElKyUidevHGFLQYgdklmEnf7Dc3ahY2rQXP6tSQryTRve085q4cD7lX2TkIfsDMNfSqQ0oA== MIME-Version: 1.0 X-Received: by 10.28.218.21 with SMTP id r21mr25192260wmg.100.1463499522567; Tue, 17 May 2016 08:38:42 -0700 (PDT) Received: by 10.194.153.39 with HTTP; Tue, 17 May 2016 08:38:42 -0700 (PDT) X-Originating-IP: [192.149.252.11] In-Reply-To: <1F5D414703BF94503600A5E3@JcK-HP8200.jck.com> References: <231532ef-e195-b73d-4a34-eb445bdd1900@gmx.de> <1F5D414703BF94503600A5E3@JcK-HP8200.jck.com> Date: Tue, 17 May 2016 11:38:42 -0400 Message-ID: From: Andrew Newton To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Julian Reschke , "urn@ietf.org" Subject: Re: [urn] Feedback on draft-ietf-urnbis-semantics-clarif-03 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 15:38:47 -0000 On Sun, May 15, 2016 at 11:44 AM, John C Klensin wrote: > > > --On Sunday, May 15, 2016 14:48 +0200 Julian Reschke > wrote: > >> Hi there, >> >> I haven't seen any substantial feedback on what I wrote two >> weeks ago. Thus here's my attempt to rephrase this in order to >> get more people to think about it. > > I have been waiting for the co-chairs to take a position on > whether you are reopening an old topic and will continue to > wait. The difference between this topic and those to which I > have been responding (to at least a subset) is that, while I > believe we discussed those others and move on, my recollection > is that Andy made a formal consensus call and closed this one. > If we start revisiting old topics without substantial new > information, it very nearly guarantees that we will never get > finished. > > Reluctantly and against my better judgment, but in the interests > of saving time, a clarification below. > >> On draft-ietf-urnbis-semantics-clarif-03: >> >> This currently updates RFC 3986. Of course we can do this, but >> RFC 3986 is a full standard, and thus this draft needs to be >> crystal clear about what exactly is being updated. I don't >> think it currently does that; it does some hand-waving with >> respect to what fragments and queries are (without saying >> exactly what's wrong in RFC 3986). It does *not* talk about >> changes to equivalence and relative resolution, although >> draft-ietf-urnbis-rfc2141bis-urn-16 seems to attempt to change >> them. > > The update to 3986 is to remove URNs from the scope of URNs > except with regard to URI syntax. 3986 says, effectively, that > URNs are just like any other URIs; the "update" is that they > they are not. The informal description of > draft-ietf-urnbis-semantics-clarif as "syntax only" is > consistent with that. > > That particular "syntax only" decision has some fairly sweeping > implications, which were discussed at the time. In particular, > it makes the definitions in 3986 --either whatever precise ones > appear or whatever oral tradition they have accumulated in other > forums -- irrelevant: they are not syntax. So one can argue, > for example, that the way draft-ietf-urnbis-semantics-clarif > uses the term "resource" or distinctions it attempts to make > about it are undesirable, but one cannot appeal to inconsistency > with 3986 to support that view. In addition, to the degree to > which the WG has already closed out this issue, an argument > about inappropriateness is presumably out of order unless it > includes fundamentally new arguments. However, again, that > requires a judgment by the co-chairs. > Which hasn't changed. The group previously decided to go down the "syntax only" path. This has been discussed in documents and several working group sessions. And I don't think we should reopen the issue as it was a pivotal decision that has been a prerequisite for the progress made so far. > Some of Juha's recent comments highlight another reason for > making the "syntax only" distinction and drawing a hard line > with it: the usage (I'm reluctant to say "definition") of the > term "identifier" in 3986 is incompatible with the meaning and > use of that term in the library and information sciences > community. Making progress on URNs requires, at least IMO, not > trying to resolve that incompatibility but does require that the > terminology of 3986 not be treated as authoritative for URNs. > > As to what should be in which document, the status of > draft-ietf-urnbis-semantics-clarif has, for a long time, been > "decide whether to fold all or part of this into 2141bis when > the WG has consensus about the substantive content of the > latter". I've been reluctant to do a major merge because of > concern about introducing mistakes in the process, but am happy > to try to do whatever the WG actually wants. What content is in which document is up to the discretion of the document authors. Such things are often a very subjective judgement where no right answer exists. -andy From nobody Tue May 17 09:10:45 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD23412D6E9 for ; Tue, 17 May 2016 09:10: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 sB1CjBoGA75g for ; Tue, 17 May 2016 09:10:42 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC96B12D1AB for ; Tue, 17 May 2016 09:10:41 -0700 (PDT) Received: from [192.168.178.20] ([93.217.96.106]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MZOan-1bIs391k6f-00LBg7; Tue, 17 May 2016 18:10:30 +0200 To: Andrew Newton , John C Klensin References: <231532ef-e195-b73d-4a34-eb445bdd1900@gmx.de> <1F5D414703BF94503600A5E3@JcK-HP8200.jck.com> From: Julian Reschke Message-ID: <9dd1f7f1-843e-822b-a352-8b51d6f4192c@gmx.de> Date: Tue, 17 May 2016 18:10:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:9LHgL012bjmbQzwYz6JnBOWN0eOwgjABW8bBfB8NE/uO1xdbuDE YUOMTfqF7YZc/TgLFA0buZTogapQkfznjsURZO/7uY/Ioa64mjyFmwP3tf7349uTlrSPV+G TrhBK3MwwckdPDcuqzXsCoqGi1MleAqO2GWa4lIaIVIF9KreNx7B1PSW4RWvuCUQ8m/RgqX sIzIUwL22VNg61/ald8eg== X-UI-Out-Filterresults: notjunk:1;V01:K0:wVjEM1sWSes=:JouG6ufmy+EiKasiFthMj1 axTKrJ69J6xxksmwHA/F9KQm6RMqsOzQtDhkPxHrGaSraTAOYXVMi8ZAV//OMOCjfVDOKDE7j jlR7sgwLCvrM4lK62Q39Ayzyfqj6utCXN2UK4mvAoyNGgCoEZrqaqIjAb4948hgr3AwWVzlkB DSRw6ka7+3t6v6Oetd+QmyRgp98iEozyyTC/dqETNUUYr7cm2Pq3I6UrGwbsuiUqQXwmKjAoW xAlQnaKXIFBnk5ougTP5PPoML+QSj5f9Omopnc7H9tQlAh8owYHjzFTnf4oENzjgDe8o6DuOD i+CxlCW8dHr2TnrLD3g2rgMMmv19iTUBdSsrCkJ/bbvy4fueVXqfPrX1wqaEDk1z8gkpc7qdo VvX/eDbWJctlzdCZE8cOhBmdyZ/IRpHjGug2AWKeKxQ0MYqIfMvmbA3CAiIxvmK1CkYI5caJx GbBHRI1QKCXbcCdQzf4GPKbp7y4h+2lap6jv0q0w4LqM4mrnixRXKRdpVwNNb02ieThremnMR pvEokrhksTr5nBLIGD4xjusr/RlvmTWqHKwgRtz5KvtjjqnQNMAIDK2t6oJg7uff3ZMW0qJsT EcUxBCS+nclyJdQRTb1407kLDu7Gn3KFO7ZVC68oBGCp7v+/W3S+pu9W9GWQ5a2DBc0or2Ogr nNheS5nutvq2Xg9DekKBnXxGKFzizx6NOUtT1lJm6ZWe08QsXCmvEIynPGRcBo66TuKOYbWRv RWdGv9HmF4dbpiS07ZIkVWJ1rdLBAoprWXpEHXjmvCqtEu8muFm2xt5JiuCySg7r26iRBmh0l +nS1ILbWsTZbzuu1Xlc7rFeCJp8EA== Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Feedback on draft-ietf-urnbis-semantics-clarif-03 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 16:10:44 -0000 On 2016-05-17 17:38, Andrew Newton wrote: > ... >>> On draft-ietf-urnbis-semantics-clarif-03: >>> >>> This currently updates RFC 3986. Of course we can do this, but >>> RFC 3986 is a full standard, and thus this draft needs to be >>> crystal clear about what exactly is being updated. I don't >>> think it currently does that; it does some hand-waving with >>> respect to what fragments and queries are (without saying >>> exactly what's wrong in RFC 3986). It does *not* talk about >>> changes to equivalence and relative resolution, although >>> draft-ietf-urnbis-rfc2141bis-urn-16 seems to attempt to change >>> them. >> >> The update to 3986 is to remove URNs from the scope of URNs >> except with regard to URI syntax. 3986 says, effectively, that >> URNs are just like any other URIs; the "update" is that they >> they are not. The informal description of >> draft-ietf-urnbis-semantics-clarif as "syntax only" is >> consistent with that. >> >> That particular "syntax only" decision has some fairly sweeping >> implications, which were discussed at the time. In particular, >> it makes the definitions in 3986 --either whatever precise ones >> appear or whatever oral tradition they have accumulated in other >> forums -- irrelevant: they are not syntax. So one can argue, >> for example, that the way draft-ietf-urnbis-semantics-clarif >> uses the term "resource" or distinctions it attempts to make >> about it are undesirable, but one cannot appeal to inconsistency >> with 3986 to support that view. In addition, to the degree to >> which the WG has already closed out this issue, an argument >> about inappropriateness is presumably out of order unless it >> includes fundamentally new arguments. However, again, that >> requires a judgment by the co-chairs. >> > > Which hasn't changed. The group previously decided to go down the > "syntax only" path. This has been discussed in documents and several > working group sessions. And I don't think we should reopen the issue > as it was a pivotal decision that has been a prerequisite for the > progress made so far. > ... WG consensus isn't IETF consensus. If this WG wants to update a standards track document, it will have to be able to answer the questions that I asked. I hear from you and John: "RFC 3986 syntax, but not semantics", as if there was agreement about what parts of RFC 3986 are which (or is there?). So, once again, if we say "updates: 3986" we need to be able to explain *precisely* which parts of RFC 3986 are affected (and why, fwiw). > ... Best regards, Julian From nobody Thu May 19 05:49:57 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1685612DA36 for ; Thu, 19 May 2016 05:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=helsinkifi.onmicrosoft.com 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 oyBC-SRhj2sa for ; Thu, 19 May 2016 05:49:53 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0090.outbound.protection.outlook.com [104.47.0.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D5412DA3D for ; Thu, 19 May 2016 05:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QI7ohWRwhGjIUJgUDeGm/rgYee1f+hQRsqwQeqQ+vN0=; b=ksLf3THIEepdqqE4RN42DyQOHlkgy/VbIEym7TUphe9OlLP+epxhlTGDJVZySTAtRdIakSmPbzO7DAgT+bNwskL6ZaMs3P/4RUT0qiuC9ebxCTH4w1NAE7fkLYOGrjjvXkF/jHuCW6cXInjNoFQMImysVZcIJ/l3+QW9Wy23+rI= Received: from VI1PR07MB1727.eurprd07.prod.outlook.com (10.166.143.23) by VI1PR07MB1727.eurprd07.prod.outlook.com (10.166.143.23) with Microsoft SMTP Server (TLS) id 15.1.497.12; Thu, 19 May 2016 12:49:45 +0000 Received: from VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) by VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) with mapi id 15.01.0497.019; Thu, 19 May 2016 12:49:45 +0000 From: "Hakala, Juha E" To: "urn@ietf.org" Thread-Topic: URN and URI semantics Thread-Index: AdGxt0UUJjcRzsAeS3asaE5+WSnGkg== Date: Thu, 19 May 2016 12:49:44 +0000 Message-ID: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=helsinki.fi; x-originating-ip: [128.214.173.46] x-ms-office365-filtering-correlation-id: 41a4271c-740c-4c2e-a2ef-08d37fe40df1 x-microsoft-exchange-diagnostics: 1; VI1PR07MB1727; 5:vgUpufPEbzAAGWlp+aYpXLvNJp7OnLsW7ODVyYvNFBPZ5K7uuYALbV8dYe03+XshXXBQK9TS2VNganiAuRU1A9ZL0jFhrB/aDv2kE/94Heb9LdrnjA9MzqVuqCxkcqMHenpbe/owUoW826IL0jBNOg==; 24:W/RhCAt1LL5AzPNe+ruKOlW4Mz0DPdDStnZEHshwv75eKglBzrD+WsVzOS/fibozns51e0zOwh9DD6PgntX5xL4dnASKhhAWNLetUfjkAN8=; 7:A7cuXILkciAvz7p83nM54pIFvYf0RF+NAzVn8CYkCyC9o3vAZco2mp9WaePIYL1q2RoM8OjgDs9w7ITO9n10TugxENvV0D9ttd73o/TrDzwIC/dyhWem/ilU7SGgIBz0+pcTrLbyzPwRdFuz5UaMU+ClQi+dzE7wVpUvFQSY41pDIs5+mx6YN+RjYblKEz5E x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1727; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:VI1PR07MB1727; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1727; x-forefront-prvs: 094700CA91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(252514010)(102836003)(54356999)(122556002)(2900100001)(450100001)(189998001)(50986999)(3846002)(586003)(1220700001)(6116002)(110136002)(8936002)(2906002)(19580405001)(76576001)(107886002)(33656002)(5008740100001)(8676002)(1730700003)(3660700001)(81166006)(5003600100002)(66066001)(3480700004)(5002640100001)(19580395003)(3280700002)(2501003)(229853001)(10400500002)(9686002)(2351001)(11100500001)(74316001)(77096005)(5640700001)(5004730100002)(86362001)(92566002)(87936001)(74482002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1727; H:VI1PR07MB1727.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM 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: 19 May 2016 12:49:44.9770 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1727 Archived-At: Subject: [urn] URN and URI semantics X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 12:49:56 -0000 Hello,=20 Julian Reschke said_ "WG consensus isn't IETF consensus. If this WG wants to update a standards = track document, it will have to be able to answer the questions that I aske= d. I hear from you and John: "RFC 3986 syntax, but not semantics", as if there= was agreement about what parts of RFC 3986 are which (or is there?). So, once again, if we say "updates: 3986" we need to be able to explain *precisely* which parts of RFC 3986 are affected (and why, fwiw)." I provide a short description, from the point of view of the identifier com= munity, which parts of RFC 3986 are affected, and in which manner.=20 RFC 3986 says this about query in chapter 3.4: The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any). Chapter 3.5 says that: The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations. >From URN point of view, the idea that fragment and query always have a role= in identification is problematic both from semantics and syntax points of = view. When URI syntax is applied to a managed URN namespace in which the identifi= er syntax and scope are strictly controlled, difficulties will emerge. I sh= all use ISBN as an example, but the issues are not ISBN-specific.=20 According to URI syntax, urn:isbn: can be extended into urn:isbn:#fragment to identify some portion of the primary document. The namespace= specific string is #fragment since fragment must have a role in iden= tification.=20 This creates two problems. First, according to the ISBN standard, ISBN cons= ists of 13 digits, so "#" and fragment cannot be part of the ISBN string. S= o fragment-augmented ISBN must not use the ISBN namespace, but e.g. namespa= ce ISBN-frag. In order to use fragments or queries as required by the URI = syntax, some URN namespaces should therefore have two additional namespaces= , one for fragments and another for queries (say, isbn-frag and isbn-query = in addition to urn:isbn). Such namespace registrations do not exist and the= re are no plans to create them. It would be difficult to specify the scope = of such namespaces, especially for query since we do not know what kind of = queries will be used. =20 Second, ISBN cannot be used to identify portions of books, such as chapters= . There are other identifier standards such as BICI and DOI for this purpos= e. So fragment usage augments the scope of ISBN system in an unacceptable w= ay. Note that it is not possible to modify the ISBN standard in such a way = that fragments (or queries) could be used, first and foremost because after= this kind of change it would be very difficult to manage ISBN assignment i= n the same quality level as before.=20 The current version of the revised URN syntax says that fragment and query = have no role in identification. This means that for instance in urn:isbn:#f-component, the namespace specific string is only, and f-compo= nent, although part of the URN, has no role in identification. The fragment= only pinpoints a location within the resource identified by the ISBN. With= this simple change it is possible to avoid both URN namespace and identifi= er scope related problems described above. Generally, I think it is a bad idea to require that URI fragment and query = must have a role in identification, and the prose describing this practice = in RFC 3986 is not crystal clear. =20 As regards query, I am not sure what "resource within the scope of the URI'= s scheme" means. If the URI scheme is URN, potentially anything is within t= he scope and we need to do what rfc2141bis currently does. But if the schem= e is specified in the namespace level, then the scope of urn:isbn is define= d by the ISBN standard to be monographs only, and for instance urn:isbn:?q-component which "identifies" metadata record describing the book iden= tified by ISBN is definitely not within the scope and should not identify a= nything even according to the RFC 3986. Does the URI syntax allow that some= resources "identified" by query are outside the scope of the URI scheme. O= r, how to specify "within the scope" and "outside the scope" in this contex= t? This might well be one of those sections in RFC 3986 have been understoo= d in different ways by different people, which in a standard document is no= t a good thing. Be that as it may, if the scope is a priori everything that= queries may cover past, present and future - good luck with it. =20 >From URN point of view, the easiest solution would be to say in rfc3986bis = that no resources "identified" by query are within the scope of the URN sch= eme and therefore in the URN syntax q-component has no role in identificati= on unlike other URIs. Or, to formulate this less strictly, it is possible t= hat in some URN namespaces some resources "identified" by queries may be ou= t of the scope and therefore, to avoid any false positives, in URN syntax q= -component never identifies anything. =20 Fragments have their own general issues when used as "identifiers". It is n= on-trivial - at least to me - to see exactly what has been identified, sinc= e fragment isn't an identifier, but just a locator. Just to give you a simp= le example, my library has millions of digitized text documents which have = very detailed XML schemas. Without going to any technical details, we could= create the following URNs: urn:isbn:#chapter1 urn:isbn:#chapter1para1 urn:isbn:#chapter1para1line1 urn:isbn:#chapter1para1line1word1 urn:isbn:#chapter1para1line1word1letter1 According to the rfc2141bis, all these URNs are equivalent (they identify t= he same book, and only that), but they indicate different locations within = the first chapter of the identified book. Anyone could create these URNs on= ce the national library has established the base URN. This is not a mandate= problem since fragments have no role in identification.=20 According to RFC 3986, we would have something like=20 urn:isbn-frag:#chapter1 urn:isbn-frag:#chapter1para1 urn:isbn-frag:#chapter1para1line1 urn:isbn-frag:#chapter1para1line1word1 urn:isbn-frag:#chapter1para1line1word1letter1 and each URN would "identify" a different portion of the book, but it is no= t obvious what that portion is and how these fragment identifiers relate to= one another, or who would have the authority to mint these identifiers. Wh= en resolved, they would all take the user to the beginning of the actual te= xt. =20 All the best, =20 Juha -- Juha Hakala Senior advisor =A0The National Library of Finland Library Network Services=20 =A0P.O.Box 26 (Kaikukatu 4) FIN-00014 Helsinki University Gsm: +358 50 3827678 email: juha.hakala@helsinki.fi=20 From nobody Fri May 20 00:39:51 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB1112D6D6 for ; Fri, 20 May 2016 00:39: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8XR8w8oet7fC for ; Fri, 20 May 2016 00:39:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916FC12D6BD for ; Fri, 20 May 2016 00:39:47 -0700 (PDT) Received: from [192.168.178.20] ([93.217.122.126]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LvzF3-1be6FQ3549-017m5q; Fri, 20 May 2016 09:39:38 +0200 To: "Hakala, Juha E" , "urn@ietf.org" References: From: Julian Reschke Message-ID: <5050b843-cd5d-c423-004d-82674fa5c7ea@gmx.de> Date: Fri, 20 May 2016 09:39:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: base64 X-Provags-ID: V03:K0:Ni0j13ejqpk2/umsnAS0XPewetGMubzSouvxVX3t4bHdCT4n7yl 5JBjuQg7mt/3ZYlYVbSTSyCDw5RD6INlm9rMM0/W+Z70/69Reh55K93Oy/nRCLRU4Xwbx13 WmQ7V2Cwgxp0/EI3vdLpLfryga4Sos/6XjUGZJ8v9F/cNDsiH24Cb8o/zGUTMgKBTLe5smC kb5kXi7XYtrVDiVTSh0DQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:IPUlpBKY8UA=:wbGtACnDY/KhYcBJpk1cpf R1ScstylKmTiqiXz/QHOQbfXmoBQwFvi0Gxyp1IhmQ6+dhyaEeQJMMYzSf8+6EbyyFIJFC3GG 47k63NpO+0AV0z3BortIj3FaMZ0QkKaARTuR2ZOPzk8QEL2dHjPauMfoX6rLJnpcJ+olSD8rs +9HZPecJlvyIZn83+wh/YMuxRelCcG3BD6NokqqRWQllfm4OfNINAIHmmcze3szoFDIg/boUI yV4OYRlkedf1whoAItH7PLfoy1s4JEelvjdOeImmLcg+eBNrgxwH+Qjp1U9VjETotXCPwPlYk mJbPEO3kgUZ4bS/rA16weLMXmu0DBA2g/I8qHWHJW6pU2wm5NldhKz34Z9G1bLvVIZKbsWm3L iNeM95uPjX9XAyGjBe4mXI1uGrqA5ddeOdO32tuAbZga/xV5eDKQWgb6DJ0woedr+lpmndI8a 5J1rM1CDNhpF0Ur0962RYRx3FvKnOMC1Q/20bks8pKTsYshxwhu3NRcLdK1gTxU5MQhhTMuXF kWFH8sUEDJnuBfmtF3SXYKzLUEqhJc7laHSlo8aCyi90UH0wzIacEHsRCV8a1cIpcOF9vvqHM VWxHMzRi0003aplngxHU8xkL+Wi5AixpHVPGyPulabsVuU3Kn4pNCXHXXjM9GhTPBBa1FJu7l /oEWpzUvrwFEsUVOaPB9Bd+ss4ucjX5PyIfBhARTLEZ0BhJazdEaSr526++Xf+uYqPj6GC4xb mYvh2MxTnlQbo8Wr9mzQwusYta1Wq1onI4hbpHcf8SAXpmFhvOn5ly+rHTEcQFTVkAVpIGGLX jatNx0jr4cxh00U5B9IQr2FV6MCdg== Archived-At: Subject: Re: [urn] URN and URI semantics X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 07:39:50 -0000 SGkgSnVoYSwNCg0KdGhhbmtzIGEgbG90IGZvciB5b3VyIGZlZWRiYWNrOyB0aGlzIGlzIGV4 dHJlbWVseSBoZWxwZnVsIGluIHRoYXQgd2UgY2FuIA0KY29uc2lkZXIgYSBjb25jcmV0ZSBj b25jZXJuIGFuZCBhbmFseXplIGl0Lg0KDQpTZWUgbW9yZSBpbmxpbmUuDQoNCk9uIDIwMTYt MDUtMTkgMTQ6NDksIEhha2FsYSwgSnVoYSBFIHdyb3RlOg0KPiAgLi4uDQo+IEkgcHJvdmlk ZSBhIHNob3J0IGRlc2NyaXB0aW9uLCBmcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSBp ZGVudGlmaWVyIGNvbW11bml0eSwgd2hpY2ggcGFydHMgb2YgUkZDIDM5ODYgYXJlIGFmZmVj dGVkLCBhbmQgaW4gd2hpY2ggbWFubmVyLg0KPg0KPiBSRkMgMzk4NiBzYXlzIHRoaXMgYWJv dXQgcXVlcnkgaW4gY2hhcHRlciAzLjQ6DQo+DQo+IFRoZSBxdWVyeSBjb21wb25lbnQgY29u dGFpbnMgbm9uLWhpZXJhcmNoaWNhbCBkYXRhIHRoYXQsIGFsb25nIHdpdGgNCj4gICAgZGF0 YSBpbiB0aGUgcGF0aCBjb21wb25lbnQgKFNlY3Rpb24gMy4zKSwgc2VydmVzIHRvIGlkZW50 aWZ5IGENCj4gICAgcmVzb3VyY2Ugd2l0aGluIHRoZSBzY29wZSBvZiB0aGUgVVJJJ3Mgc2No ZW1lIGFuZCBuYW1pbmcgYXV0aG9yaXR5DQo+ICAgIChpZiBhbnkpLg0KPg0KPiBDaGFwdGVy IDMuNSBzYXlzIHRoYXQ6DQo+DQo+IFRoZSBmcmFnbWVudCBpZGVudGlmaWVyIGNvbXBvbmVu dCBvZiBhIFVSSSBhbGxvd3MgaW5kaXJlY3QNCj4gICAgaWRlbnRpZmljYXRpb24gb2YgYSBz ZWNvbmRhcnkgcmVzb3VyY2UgYnkgcmVmZXJlbmNlIHRvIGEgcHJpbWFyeQ0KPiAgICByZXNv dXJjZSBhbmQgYWRkaXRpb25hbCBpZGVudGlmeWluZyBpbmZvcm1hdGlvbi4gIFRoZSBpZGVu dGlmaWVkDQo+ICAgIHNlY29uZGFyeSByZXNvdXJjZSBtYXkgYmUgc29tZSBwb3J0aW9uIG9y IHN1YnNldCBvZiB0aGUgcHJpbWFyeQ0KPiAgICByZXNvdXJjZSwgc29tZSB2aWV3IG9uIHJl cHJlc2VudGF0aW9ucyBvZiB0aGUgcHJpbWFyeSByZXNvdXJjZSwgb3INCj4gICAgc29tZSBv dGhlciByZXNvdXJjZSBkZWZpbmVkIG9yIGRlc2NyaWJlZCBieSB0aG9zZSByZXByZXNlbnRh dGlvbnMuDQo+DQo+PkZyb20gVVJOIHBvaW50IG9mIHZpZXcsIHRoZSBpZGVhIHRoYXQgZnJh Z21lbnQgYW5kIHF1ZXJ5IGFsd2F5cyBoYXZlIGEgcm9sZSBpbiBpZGVudGlmaWNhdGlvbiBp cyBwcm9ibGVtYXRpYyBib3RoIGZyb20gc2VtYW50aWNzIGFuZCBzeW50YXggcG9pbnRzIG9m IHZpZXcuDQoNCkl0J3Mgbm90IG9wdGltYWwgdG8gZGlzY3VzcyBxdWVyeSBhbmQgZnJhZ21l bnQgdG9nZXRoZXIuDQoNClRoZSBxdWVyeSBpcyBwYXJ0IG9mIG9mIHRoZSBhYnNvbHV0ZS1V UkkgQUJORiBwcm9kdWN0aW9uIA0KKDxodHRwczovL2dyZWVuYnl0ZXMuZGUvdGVjaC93ZWJk YXYvcmZjMzk4Ni5odG1sI2Fic29sdXRlLXVyaT4pLiAgV2hhdCANCnRoZSBhYnNvbHV0ZS1V UkkgY29udGFpbnMgaXMgdW5kZXIgZnVsbCBjb250cm9sIG9mIHRoZSBVUkkgc2NoZW1lLiBT byANCml0J3MgdXAgdG8gdGhlIGRlZmluaXRpb24gb2YgdGhlICJVUk4iIFVSSSBzY2hlbWUg dG8gZGVmaW5lIHdoZXRoZXIgDQpxdWVyaWVzIGFyZSBhbGxvd2VkLCBhbmQgaWYgdGhleSBh cmUsIHdoYXQgdGhleSBtZWFuIChvciBvZiBjb3Vyc2UgaXQgDQpjYW4gYmUgZGVsZWdhdGVk IHRvIHRoZSBVUk4gbmFtZXNwYWNlIGRlZmluaXRpb25zKS4NCg0KQWxzbywganVzdCBiZWNh dXNlIFJGQyAzOTg2IHNheXMgdGhhdCB0aGUgcXVlcnkgcGxheXMgYSByb2xlIGluIHRoZSAN CmRlZmluaXRpb24gKmluIGdlbmVyYWwqIGRvZXNuJ3QgbWVhbiBpdCBoYXMgdG8gZm9yIGEg cGFydGljdWxhciBzY2hlbWUuDQoNCkZyYWdtZW50IGlzIGEgZGlmZmVyZW50IGNhc2U7IFJG QyAzOTg2IGFsc28gc2F5czoNCg0KIlRoZSBzZW1hbnRpY3Mgb2YgYSBmcmFnbWVudCBpZGVu dGlmaWVyIGFyZSBkZWZpbmVkIGJ5IHRoZSBzZXQgb2YgDQpyZXByZXNlbnRhdGlvbnMgdGhh dCBtaWdodCByZXN1bHQgZnJvbSBhIHJldHJpZXZhbCBhY3Rpb24gb24gdGhlIHByaW1hcnkg DQpyZXNvdXJjZS4gVGhlIGZyYWdtZW50J3MgZm9ybWF0IGFuZCByZXNvbHV0aW9uIGlzIHRo ZXJlZm9yZSBkZXBlbmRlbnQgb24gDQp0aGUgbWVkaWEgdHlwZSBbUkZDMjA0Nl0gb2YgYSBw b3RlbnRpYWxseSByZXRyaWV2ZWQgcmVwcmVzZW50YXRpb24sIGV2ZW4gDQp0aG91Z2ggc3Vj aCBhIHJldHJpZXZhbCBpcyBvbmx5IHBlcmZvcm1lZCBpZiB0aGUgVVJJIGlzIGRlcmVmZXJl bmNlZC4gSWYgDQpubyBzdWNoIHJlcHJlc2VudGF0aW9uIGV4aXN0cywgdGhlbiB0aGUgc2Vt YW50aWNzIG9mIHRoZSBmcmFnbWVudCBhcmUgDQpjb25zaWRlcmVkIHVua25vd24gYW5kIGFy ZSBlZmZlY3RpdmVseSB1bmNvbnN0cmFpbmVkLiBGcmFnbWVudCANCmlkZW50aWZpZXIgc2Vt YW50aWNzIGFyZSBpbmRlcGVuZGVudCBvZiB0aGUgVVJJIHNjaGVtZSBhbmQgdGh1cyBjYW5u b3QgDQpiZSByZWRlZmluZWQgYnkgc2NoZW1lIHNwZWNpZmljYXRpb25zLiIgLS0gDQo8aHR0 cHM6Ly9ncmVlbmJ5dGVzLmRlL3RlY2gvd2ViZGF2L3JmYzM5ODYuaHRtbCNyZmMuc2VjdGlv bi4zLjUucC4xPg0KDQpTbyBmb3IgYSBVUk4gdGhpcyBsZWF2ZXMgdGhlIGRvb3Igd2lkZSBv cGVuOyBub3RlICJJZiBubyBzdWNoIA0KcmVwcmVzZW50YXRpb24gZXhpc3RzLCB0aGVuIHRo ZSBzZW1hbnRpY3Mgb2YgdGhlIGZyYWdtZW50IGFyZSBjb25zaWRlcmVkIA0KdW5rbm93biBh bmQgYXJlIGVmZmVjdGl2ZWx5IHVuY29uc3RyYWluZWQuDQoNCj4gV2hlbiBVUkkgc3ludGF4 IGlzIGFwcGxpZWQgdG8gYSBtYW5hZ2VkIFVSTiBuYW1lc3BhY2UgaW4gd2hpY2ggdGhlIGlk ZW50aWZpZXIgc3ludGF4IGFuZCBzY29wZSBhcmUgc3RyaWN0bHkgY29udHJvbGxlZCwgZGlm ZmljdWx0aWVzIHdpbGwgZW1lcmdlLiBJIHNoYWxsIHVzZSBJU0JOIGFzIGFuIGV4YW1wbGUs IGJ1dCB0aGUgaXNzdWVzIGFyZSBub3QgSVNCTi1zcGVjaWZpYy4NCj4NCj4gQWNjb3JkaW5n IHRvIFVSSSBzeW50YXgsIHVybjppc2JuOjxpc2JuPiBjYW4gYmUgZXh0ZW5kZWQgaW50byB1 cm46aXNibjo8aXNibj4jZnJhZ21lbnQgdG8gaWRlbnRpZnkgc29tZSBwb3J0aW9uIG9mIHRo ZSBwcmltYXJ5IGRvY3VtZW50LiBUaGUgbmFtZXNwYWNlIHNwZWNpZmljIHN0cmluZyBpcyA8 aXNibj4jZnJhZ21lbnQgc2luY2UgZnJhZ21lbnQgbXVzdCBoYXZlIGEgcm9sZSBpbiBpZGVu dGlmaWNhdGlvbi4NCj4NCj4gVGhpcyBjcmVhdGVzIHR3byBwcm9ibGVtcy4gRmlyc3QsIGFj Y29yZGluZyB0byB0aGUgSVNCTiBzdGFuZGFyZCwgSVNCTiBjb25zaXN0cyBvZiAxMyBkaWdp dHMsIHNvICIjIiBhbmQgZnJhZ21lbnQgY2Fubm90IGJlIHBhcnQgb2YgdGhlIElTQk4gc3Ry aW5nLiBTbyBmcmFnbWVudC1hdWdtZW50ZWQgSVNCTiBtdXN0IG5vdCB1c2UgdGhlIElTQk4g bmFtZXNwYWNlLCBidXQgZS5nLiBuYW1lc3BhY2UgSVNCTi1mcmFnLiAgSW4gb3JkZXIgdG8g dXNlIGZyYWdtZW50cyBvciBxdWVyaWVzIGFzIHJlcXVpcmVkIGJ5IHRoZSBVUkkgc3ludGF4 LCBzb21lIFVSTiBuYW1lc3BhY2VzIHNob3VsZCB0aGVyZWZvcmUgaGF2ZSB0d28gYWRkaXRp b25hbCBuYW1lc3BhY2VzLCBvbmUgZm9yIGZyYWdtZW50cyBhbmQgYW5vdGhlciBmb3IgcXVl cmllcyAoc2F5LCBpc2JuLWZyYWcgYW5kIGlzYm4tcXVlcnkgaW4gYWRkaXRpb24gdG8gdXJu OmlzYm4pLiBTdWNoIG5hbWVzcGFjZSByZWdpc3RyYXRpb25zIGRvIG5vdCBleGlzdCBhbmQg dGhlcmUgYXJlIG5vIHBsYW5zIHRvIGNyZWF0ZSB0aGVtLiBJdCB3b3VsZCBiZSBkaWZmaWN1 bHQgdG8gc3BlY2lmeSB0aGUgc2NvcGUgb2Ygc3VjaCBuYW1lc3BhY2VzLCBlc3BlY2lhbGx5 IGZvciBxdWVyeSBzaW5jZSB3ZSBkbyBub3Qga25vdyB3aGF0IGtpbmQgb2YgcXVlcmllcyB3 aWxsIGJlIHVzZWQuDQoNCkhtLCBuby4gVGhlIGZyYWdtZW50IGlzIG5vdCBwYXJ0IG9mIHRo ZSBhYnNvbHV0ZS1VUkkgZGVmaW5pdGlvbiwgc28gYnkgDQpkZWZpbml0aW9uIGl0IGlzIG5v dCBwYXJ0IG9mIHRoZSBVUk4ncyBuYW1lc3BhY2Utc3BlY2lmaWMgc3RyaW5nLg0KDQo+IFNl Y29uZCwgSVNCTiBjYW5ub3QgYmUgdXNlZCB0byBpZGVudGlmeSBwb3J0aW9ucyBvZiBib29r cywgc3VjaCBhcyBjaGFwdGVycy4gVGhlcmUgYXJlIG90aGVyIGlkZW50aWZpZXIgc3RhbmRh cmRzIHN1Y2ggYXMgQklDSSBhbmQgRE9JIGZvciB0aGlzIHB1cnBvc2UuIFNvIGZyYWdtZW50 IHVzYWdlIGF1Z21lbnRzIHRoZSBzY29wZSBvZiBJU0JOIHN5c3RlbSBpbiBhbiB1bmFjY2Vw dGFibGUgd2F5LiBOb3RlIHRoYXQgaXQgaXMgbm90IHBvc3NpYmxlIHRvIG1vZGlmeSB0aGUg SVNCTiBzdGFuZGFyZCBpbiBzdWNoIGEgd2F5IHRoYXQgZnJhZ21lbnRzIChvciBxdWVyaWVz KSBjb3VsZCBiZSB1c2VkLCBmaXJzdCBhbmQgZm9yZW1vc3QgYmVjYXVzZSBhZnRlciB0aGlz IGtpbmQgb2YgY2hhbmdlIGl0IHdvdWxkIGJlIHZlcnkgZGlmZmljdWx0IHRvIG1hbmFnZSBJ U0JOIGFzc2lnbm1lbnQgaW4gdGhlIHNhbWUgcXVhbGl0eSBsZXZlbCBhcyBiZWZvcmUuDQoN Ck9LLCBJIGFncmVlIHRoYXQgdXNpbmcgZnJhZ21lbnQgaWRlbnRpZmllcnMgd2l0aCBJU0JO IFVSTnMgZG9lc24ndCBtYWtlIA0Kc2Vuc2UuIFNvIHRoZSBjaG9pY2UgaXMgYmV0d2VlbiBt YWtpbmcgdGhlbSBpbGxlZ2FsL2ludmFsaWQgKGVzc2VudGlhbGx5IA0Kc2F5aW5nICJkb24n dCBkbyB0aGF0Iikgb3IgbGVhdmluZyB0aGVpciBtZWFuaW5nIHVuZGVmaW5lZCAoYXMgcGVy IA0KY3VycmVudCBSRkMgMzk4NikuIERvZXMgdGhlIGRpZmZlcmVuY2UgcmVhbGx5IG1hdHRl cj8NCg0KPiBUaGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSByZXZpc2VkIFVSTiBzeW50YXgg c2F5cyB0aGF0IGZyYWdtZW50IGFuZCBxdWVyeSBoYXZlIG5vIHJvbGUgaW4gaWRlbnRpZmlj YXRpb24uIFRoaXMgbWVhbnMgdGhhdCBmb3IgaW5zdGFuY2UgaW4gdXJuOmlzYm46PGlzYm4+ I2YtY29tcG9uZW50LCB0aGUgbmFtZXNwYWNlIHNwZWNpZmljIHN0cmluZyBpcyA8aXNibj4g b25seSwgYW5kIGYtY29tcG9uZW50LCBhbHRob3VnaCBwYXJ0IG9mIHRoZSBVUk4sIGhhcyBu byByb2xlIGluIGlkZW50aWZpY2F0aW9uLiBUaGUgZnJhZ21lbnQgb25seSBwaW5wb2ludHMg YSBsb2NhdGlvbiB3aXRoaW4gdGhlIHJlc291cmNlIGlkZW50aWZpZWQgYnkgdGhlIElTQk4u IFdpdGggdGhpcyBzaW1wbGUgY2hhbmdlIGl0IGlzIHBvc3NpYmxlIHRvIGF2b2lkIGJvdGgg VVJOIG5hbWVzcGFjZSBhbmQgaWRlbnRpZmllciBzY29wZSByZWxhdGVkIHByb2JsZW1zIGRl c2NyaWJlZCBhYm92ZS4NCg0KVGhpcyBpcyBwZXJmZWN0bHkgb2sgYW5kIGRvZXMgbm90IHJl cXVpcmUgYW55IGNoYW5nZSB0byBSRkMgMzk4Ni4gVGhlIA0KZnJhZ21lbnQgaXNuJ3QgcGFy dCBvZiBhYnNvbHV0ZS1VUkkgYW55d2F5LiBXaXRoIHJlc3BlY3QgdG8gdGhlIHF1ZXJ5IA0K Y29tcG9uZW50OiB3aGF0IGl0IG1lYW5zIGFuZCBob3cgKG9yIHdoZXRoZXIpIGl0IGFmZmVj dHMgcmVzb3VyY2UgDQppZGVudGlmaWNhdGlvbiBpcyB1bmRlciB0aGUgY29udHJvbCBvZiB0 aGUgVVJJIHNjaGVtZSBkZWZpbml0aW9uIGFueXdheS4NCg0KPiBHZW5lcmFsbHksIEkgdGhp bmsgaXQgaXMgYSBiYWQgaWRlYSB0byByZXF1aXJlIHRoYXQgVVJJIGZyYWdtZW50IGFuZCBx dWVyeSBtdXN0IGhhdmUgYSByb2xlIGluIGlkZW50aWZpY2F0aW9uLCBhbmQgdGhlIHByb3Nl IGRlc2NyaWJpbmcgdGhpcyBwcmFjdGljZSBpbiBSRkMgMzk4NiBpcyBub3QgY3J5c3RhbCBj bGVhci4NCg0KUkZDIDM5ODYgZG9lcyBub3QgKnJlcXVpcmUqIGFueXRoaW5nIGFib3V0IHRo ZSBxdWVyeSBjb21wb25lbnQgZm9yIA0KcGFydGljdWxhciBVUkkgc2NoZW1lcy4gSXQganVz dCBzYXlzIHRoYXQgaW4gKmdlbmVyYWwqLCBpdCBkb2VzIHBsYXkgYSANCnJvbGUgaW4gaWRl bnRpZmljYXRpb24uIFRoZSAiVVJOIiBVUkkgc2NoZW1lIGRlZmluaXRpb24gY2FuIGVhc2ls eSBzYXkgDQoiYnV0IGl0IGRvZXNuJ3QgaW4gb3VyIGNhc2UiLg0KDQpXaXRoIHJlc3BlY3Qg dG8gZnJhZ21lbnRzOiBSRkMgMzk4NiBzYXlzIHRoYXQgdGhlIHByaW1hcnkgcmVzb3VyY2Ug aXMgDQppZGVudGlmaWVkIGJ5IHdoYXQncyBpbiB0aGUgYWJzb2x1dGUtVVJJLCBhbmQgdGhl IG1lYW5pbmcgb2YgdGhlIA0KZnJhZ21lbnQgZWl0aGVyIGRlcGVuZHMgb24gdGhlIG1lZGlh IHR5cGUgb2YgdGhlIGFzc29jaWF0ZWQgDQpyZXByZXNlbnRhdGlvbiwgb3IsIGluIGFic2Vu Y2Ugb2YgYSByZXByZXNlbnRhdGlvbiwgaXMgdW5jb25zdHJhaW5lZC4NCg0KPiBBcyByZWdh cmRzIHF1ZXJ5LCBJIGFtIG5vdCBzdXJlIHdoYXQgInJlc291cmNlIHdpdGhpbiB0aGUgc2Nv cGUgb2YgdGhlIFVSSSdzIHNjaGVtZSIgbWVhbnMuIElmIHRoZSBVUkkgc2NoZW1lIGlzIFVS TiwgcG90ZW50aWFsbHkgYW55dGhpbmcgaXMgd2l0aGluIHRoZSBzY29wZSBhbmQgd2UgbmVl ZCB0byBkbyB3aGF0IHJmYzIxNDFiaXMgY3VycmVudGx5IGRvZXMuIEJ1dCBpZiB0aGUgc2No ZW1lIGlzIHNwZWNpZmllZCBpbiB0aGUgbmFtZXNwYWNlIGxldmVsLCB0aGVuIHRoZSBzY29w ZSBvZiB1cm46aXNibiBpcyBkZWZpbmVkIGJ5IHRoZSBJU0JOIHN0YW5kYXJkIHRvIGJlIG1v bm9ncmFwaHMgb25seSwgYW5kIGZvciBpbnN0YW5jZSB1cm46aXNibjo8aXNibj4/cS1jb21w b25lbnQgd2hpY2ggImlkZW50aWZpZXMiIG1ldGFkYXRhIHJlY29yZCBkZXNjcmliaW5nIHRo ZSBib29rIGlkZW50aWZpZWQgYnkgSVNCTiBpcyBkZWZpbml0ZWx5IG5vdCB3aXRoaW4gdGhl IHNjb3BlIGFuZCBzaG91bGQgbm90IGlkZW50aWZ5IGFueXRoaW5nIGV2ZW4gYWNjb3JkaW5n IHRvIHRoZSBSRkMgMzk4Ni4gRG9lcyB0aGUgVVJJIHN5bnRheCBhbGxvdyB0aGF0IHNvbWUg cmVzb3VyY2VzICJpZGVudGlmaWVkIiBieSBxdWVyeSBhcmUgb3V0c2lkZSB0aGUgc2NvcGUg b2YgdGhlIFVSSSBzY2hlbWUuIE9yLCBob3cgdG8gc3BlY2lmeSAid2l0aGluIHRoZSBzY29w ZSIgYW5kICJvdXRzaWRlIHRoZSBzY29wZSIgaW4gdGhpcyBjb250ZXh0PyBUaGlzIG1pZ2h0 IHdlbGwgYmUgb25lIG9mIHRob3NlIHNlY3Rpb25zIGluIFJGQyAzOTg2IGhhdmUgYmVlbiB1 bmRlcnN0b29kIGluIGRpZmZlcmVudCB3YXlzIGJ5IGRpZmZlcmVudCBwZW9wbGUsIHdoaWNo IGluIGEgc3RhbmRhcmQgZG9jdW1lbnQgaXMgbm90IGEgZ29vZCB0aGluZy4gQmUgdGhhdCBh cyBpdCBtYXksIGlmIHRoZSBzY29wZSBpcyBhIHByaW9yaSBldmVyeXRoaW5nIHRoYXQgcXVl cmllcyBtYXkgY292ZXIgcGFzdCwgcHJlc2VudCBhbmQgZnV0dXJlIC0gZ29vZCBsdWNrIHdp dGggaXQuDQoNCkl0IG1lYW5zICJyZXNvdXJjZSBpZGVudGlmaWFibGUgYnkgdGhlIFVSSSBz Y2hlbWUiLiBNYXliZSB5b3UncmUgdHJ5aW5nIA0KdG8gcmVhZCBtb3JlIGludG8gdGhpcyBz dGF0ZW1lbnQgdGhhbiB0aGVyZSBpcy4NCg0KPj5Gcm9tIFVSTiBwb2ludCBvZiB2aWV3LCB0 aGUgZWFzaWVzdCBzb2x1dGlvbiB3b3VsZCBiZSB0byBzYXkgaW4gcmZjMzk4NmJpcyB0aGF0 IG5vIHJlc291cmNlcyAiaWRlbnRpZmllZCIgYnkgcXVlcnkgYXJlIHdpdGhpbiB0aGUgc2Nv cGUgb2YgdGhlIFVSTiBzY2hlbWUgYW5kIHRoZXJlZm9yZSBpbiB0aGUgVVJOIHN5bnRheCBx LWNvbXBvbmVudCBoYXMgbm8gcm9sZSBpbiBpZGVudGlmaWNhdGlvbiB1bmxpa2Ugb3RoZXIg VVJJcy4gT3IsIHRvIGZvcm11bGF0ZSB0aGlzIGxlc3Mgc3RyaWN0bHksIGl0IGlzIHBvc3Np YmxlIHRoYXQgaW4gc29tZSBVUk4gbmFtZXNwYWNlcyBzb21lIHJlc291cmNlcyAiaWRlbnRp ZmllZCIgYnkgcXVlcmllcyBtYXkgYmUgb3V0IG9mIHRoZSBzY29wZSBhbmQgdGhlcmVmb3Jl LCB0byBhdm9pZCBhbnkgZmFsc2UgcG9zaXRpdmVzLCBpbiBVUk4gc3ludGF4IHEtY29tcG9u ZW50IG5ldmVyIGlkZW50aWZpZXMgYW55dGhpbmcuDQoNClRoYXQncyB1bmRlciBjb250cm9s IG9mIHRoZSBVUk4gc2NoZW1lIGRlZmluaXRpb24uIElmIHlvdSB3YW50IGRvIGRlZmluZSAN CnRoYXQsIHlvdSBjYW4uDQoNCj4gRnJhZ21lbnRzIGhhdmUgdGhlaXIgb3duIGdlbmVyYWwg aXNzdWVzIHdoZW4gdXNlZCBhcyAiaWRlbnRpZmllcnMiLiBJdCBpcyBub24tdHJpdmlhbCAt IGF0IGxlYXN0IHRvIG1lIC0gdG8gc2VlIGV4YWN0bHkgd2hhdCBoYXMgYmVlbiBpZGVudGlm aWVkLCBzaW5jZSBmcmFnbWVudCBpc24ndCBhbiBpZGVudGlmaWVyLCBidXQganVzdCBhIGxv Y2F0b3IuIEp1c3QgdG8gZ2l2ZSB5b3UgYSBzaW1wbGUgZXhhbXBsZSwgbXkgbGlicmFyeSBo YXMgbWlsbGlvbnMgb2YgZGlnaXRpemVkIHRleHQgZG9jdW1lbnRzIHdoaWNoIGhhdmUgdmVy eSBkZXRhaWxlZCBYTUwgc2NoZW1hcy4gV2l0aG91dCBnb2luZyB0byBhbnkgdGVjaG5pY2Fs IGRldGFpbHMsIHdlIGNvdWxkIGNyZWF0ZSB0aGUgZm9sbG93aW5nIFVSTnM6DQoNCkhvdyBk byB5b3UgY29tZSB0byB0aGUgY29uY2x1c2lvbiB0aGF0IGZyYWdtZW50IGFyZSBsb2NhdG9y cywgbm90IA0KaWRlbnRpZmllcnMsIGFuZCB3aGF0J3MgdGhlIGRpZmZlcmVuY2UgaW4gcHJh Y3RpY2U/DQoNCj4gdXJuOmlzYm46PGlzYm4+I2NoYXB0ZXIxDQo+IHVybjppc2JuOjxpc2Ju PiNjaGFwdGVyMXBhcmExDQo+IHVybjppc2JuOjxpc2JuPiNjaGFwdGVyMXBhcmExbGluZTEN Cj4gdXJuOmlzYm46PGlzYm4+I2NoYXB0ZXIxcGFyYTFsaW5lMXdvcmQxDQo+IHVybjppc2Ju Ojxpc2JuPiNjaGFwdGVyMXBhcmExbGluZTF3b3JkMWxldHRlcjENCj4NCj4gQWNjb3JkaW5n IHRvIHRoZSByZmMyMTQxYmlzLCBhbGwgdGhlc2UgVVJOcyBhcmUgZXF1aXZhbGVudCAodGhl eSBpZGVudGlmeSB0aGUgc2FtZSBib29rLCBhbmQgb25seSB0aGF0KSwgYnV0IHRoZXkgaW5k aWNhdGUgZGlmZmVyZW50IGxvY2F0aW9ucyB3aXRoaW4gdGhlIGZpcnN0IGNoYXB0ZXIgb2Yg dGhlIGlkZW50aWZpZWQgYm9vay4gQW55b25lIGNvdWxkIGNyZWF0ZSB0aGVzZSBVUk5zIG9u Y2UgdGhlIG5hdGlvbmFsIGxpYnJhcnkgaGFzIGVzdGFibGlzaGVkIHRoZSBiYXNlIFVSTi4g VGhpcyBpcyBub3QgYSBtYW5kYXRlIHByb2JsZW0gc2luY2UgZnJhZ21lbnRzIGhhdmUgbm8g cm9sZSBpbiBpZGVudGlmaWNhdGlvbi4NCg0KV293LCB0aGV5IGFyZSAqZXF1aXZhbGVudCos IGJ1dCBpbmRpY2F0ZSAqZGlmZmVyZW50KiBsb2NhdGlvbnM/IFRoYXQncyANCklNSE8gYSB2 ZXJ5IHZlcnkgc3VycHJpc2luZyBkZWZpbml0aW9uIG9mIGVxdWl2YWxlbmNlLiBJdCBwcm9i YWJseSB3b3VsZCANCmJlIGdvb2QgdG8gdXNlIGEgbW9yZSBzcGVjaWZpYyB0ZXJtLg0KDQo+ IEFjY29yZGluZyB0byBSRkMgMzk4Niwgd2Ugd291bGQgaGF2ZSBzb21ldGhpbmcgbGlrZQ0K Pg0KPiB1cm46aXNibi1mcmFnOjxpc2JuPiNjaGFwdGVyMQ0KPiB1cm46aXNibi1mcmFnOjxp c2JuPiNjaGFwdGVyMXBhcmExDQo+IHVybjppc2JuLWZyYWc6PGlzYm4+I2NoYXB0ZXIxcGFy YTFsaW5lMQ0KPiB1cm46aXNibi1mcmFnOjxpc2JuPiNjaGFwdGVyMXBhcmExbGluZTF3b3Jk MQ0KPiB1cm46aXNibi1mcmFnOjxpc2JuPiNjaGFwdGVyMXBhcmExbGluZTF3b3JkMWxldHRl cjENCg0KVGhlc2Ugc2VlbSB0byBiZSBpZGVudGljYWwgdG8gdGhlIGZpcnN0IHNldCBvZiBl eGFtcGxlcywgZXhjZXB0IGZvciB0aGUgDQpkaWZmZXJpbmcgbmFtZXNwYWNlIG5hbWUuLi4N Cg0KPiBhbmQgZWFjaCBVUk4gd291bGQgImlkZW50aWZ5IiBhIGRpZmZlcmVudCBwb3J0aW9u IG9mIHRoZSBib29rLCBidXQgaXQgaXMgbm90IG9idmlvdXMgd2hhdCB0aGF0IHBvcnRpb24g aXMgYW5kIGhvdyB0aGVzZSBmcmFnbWVudCBpZGVudGlmaWVycyByZWxhdGUgdG8gb25lIGFu b3RoZXIsIG9yIHdobyB3b3VsZCBoYXZlIHRoZSBhdXRob3JpdHkgdG8gbWludCB0aGVzZSBp ZGVudGlmaWVycy4gV2hlbiByZXNvbHZlZCwgdGhleSB3b3VsZCBhbGwgdGFrZSB0aGUgdXNl ciB0byB0aGUgYmVnaW5uaW5nIG9mIHRoZSBhY3R1YWwgdGV4dC4NCg0KSSBmaW5kIHRoaXMg dmVyeSB2ZXJ5IGNvbmZ1c2luZy4gSW4gdGhlIGZpcnN0IGNhc2UgdGhlIFVSSSBpZGVudGlm aWVzIGEgDQpib29rIGFuZCBhbHNvIGluZGljYXRlcyBhIGxvY2F0aW9uIHdpdGhpbiB0aGUg Ym9vay4gSW4gdGhlIHNlY29uZCBjYXNlLCANCnRoZSBVUkkgaWRlbnRpZmllcyBhIGxvY2F0 aW9uIHdpdGhpbiBhIGJvb2suDQoNCkJvdGggdXNlIGV4YWN0bHkgdGhlIHNhbWUgc3ludGF4 IGV4Y2VwdCBmb3IgdGhlIFVSTiBuYW1lc3BhY2UgbmFtZS4gV2hhdCANCmRvIHlvdSBiYXNl IHRoZSBkaXN0aW5jdGlvbiBvbiwgYW5kIHdobyBpcyBzdXBwb3NlZCB0byB1bmRlcnN0YW5k IHRoYXQ/DQoNCiA+IC4uLg0KDQpCZXN0IHJlZ2FyZHMsIEp1bGlhbg0K From nobody Fri May 20 05:57:44 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE2912D1E8 for ; Fri, 20 May 2016 05:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=helsinkifi.onmicrosoft.com 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 9RAPjhLZ6Fze for ; Fri, 20 May 2016 05:57:40 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0111.outbound.protection.outlook.com [104.47.2.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 AEF5F12D0C9 for ; Fri, 20 May 2016 05:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2sBpHK86affYTm2b3uNtHL7gAWQOwB06VhKI4ioCcgk=; b=YG44t6HcYdVH2UJE7+MgVXZBE2VywseFDg3ApvSX38cwOJzERgaK1Y+3GoKsQrqoCTv2nORHtJvz9DU0teunFS8roOF2UgG2D7r5qLkaLe338P7ycG9NpAgA/V/SO0fpt5vnSu/5nAe9vWs01JyxuAKvjO7JX4KSMXTVtNooMwg= Received: from VI1PR07MB1727.eurprd07.prod.outlook.com (10.166.143.23) by VI1PR07MB1726.eurprd07.prod.outlook.com (10.166.143.22) with Microsoft SMTP Server (TLS) id 15.1.497.12; Fri, 20 May 2016 12:57:37 +0000 Received: from VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) by VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) with mapi id 15.01.0497.019; Fri, 20 May 2016 12:57:37 +0000 From: "Hakala, Juha E" To: Julian Reschke , "urn@ietf.org" Thread-Topic: [urn] URN and URI semantics Thread-Index: AdGxt0UUJjcRzsAeS3asaE5+WSnGkgAs3WsAAAieVDA= Date: Fri, 20 May 2016 12:57:37 +0000 Message-ID: References: <5050b843-cd5d-c423-004d-82674fa5c7ea@gmx.de> In-Reply-To: <5050b843-cd5d-c423-004d-82674fa5c7ea@gmx.de> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.de; dkim=none (message not signed) header.d=none;gmx.de; dmarc=none action=none header.from=helsinki.fi; x-originating-ip: [128.214.71.222] x-ms-office365-filtering-correlation-id: 855e9c5b-eadf-4daf-1535-08d380ae51e2 x-microsoft-exchange-diagnostics: 1; VI1PR07MB1726; 5:80G5HHFhyZxROSWp4jYp6PdudvUSPOZEs8FBHDhahi6ThlciASE40R4oAHEWIkIPjEhk98h+79b8pucdzMoiIso3wwk4e/scSs29RftGWGAmN8nr94FE8TxAOpRXIq38QQgrbj5QRwMQ95nzuZpCtg==; 24:WWMFDgX7TIQUUeIT53tEyPC/gxdUgYtQMeVJmkSoqD6xD95ktr2uFk01XAUmy4IYfQ1BZqGYp8UmQfaY6h8VHcnaLBabQ1uYqu+cDRWq3qQ=; 7:TZ1VwqQfbadhV+xtMF32DZgPkHLGP4nDynRcpK4B8v5Nnt4B2olBszDljiP4o6nsRB5oTr6lrInpDGF0o0Hr4AIuq2OMfQjAGLTRijr0ilb0i1UmVynAf79srb0ADqT0lShp5EDUOkDXA4bSje9m/Q9lMRlNcvIdAa+eTqtgkgwBDhBxkeGGyZkVDURvv4kn x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1726; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR07MB1726; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1726; x-forefront-prvs: 09480768F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(54094003)(11100500001)(15975445007)(2900100001)(92566002)(77096005)(2950100001)(74482002)(19580395003)(5002640100001)(74316001)(8936002)(6116002)(8676002)(19580405001)(81166006)(5004730100002)(122556002)(5008740100001)(66066001)(9686002)(31430400001)(2501003)(3280700002)(33656002)(3660700001)(345774005)(86362001)(189998001)(5003600100002)(5001770100001)(76576001)(107886002)(50986999)(2906002)(54356999)(10400500002)(102836003)(76176999)(1220700001)(586003)(3846002)(8666003)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1726; H:VI1PR07MB1727.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2016 12:57:37.4245 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1726 Archived-At: Subject: Re: [urn] URN and URI semantics X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 12:57:44 -0000 Hello Julian,=20 Thank you for the feedback. I hope we are getting closer to sufficient alig= nment of our views. Some comments below.=20 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: 20. toukokuuta 2016 10:39 > To: Hakala, Juha E ; urn@ietf.org > Subject: Re: [urn] URN and URI semantics >=20 > Hi Juha, >=20 >=20 > The query is part of of the absolute-URI ABNF production > (). What > the absolute-URI contains is under full control of the URI scheme. So it'= s up > to the definition of the "URN" URI scheme to define whether queries are > allowed, and if they are, what they mean (or of course it can be delegate= d to > the URN namespace definitions). In the URN syntax context, we don't want to prevent a priori the usage of r= /q/f-components. The only exception to this are namespaces were fragments a= re out of scope since nothing tangible is identified, or namespaces which h= ave no intention to support resolution services. These exceptions can be cl= arified in the namespace registration requests.=20 Even if e.g. the usage of q-component is not possible when the identifier i= s minted, it may become relevant later when the technical infrastructure wi= thin which URNs are used becomes more mature. Note that for every URN, over= time there could be literally hundreds of different q-components, facilita= ting various kinds of service requests.=20 So from absolute-URI point of view, we need to allow queries (q-components)= . The one thing we cannot allow is that they would actually have a role in = identification.=20 > Also, just because RFC 3986 says that the query plays a role in the defin= ition > *in general* doesn't mean it has to for a particular scheme. >=20 > Fragment is a different case; RFC 3986 also says: >=20 > "The semantics of a fragment identifier are defined by the set of > representations that might result from a retrieval action on the primary > resource. The fragment's format and resolution is therefore dependent on > the media type [RFC2046] of a potentially retrieved representation, even > though such a retrieval is only performed if the URI is dereferenced. If = no > such representation exists, then the semantics of the fragment are > considered unknown and are effectively unconstrained. Fragment identifier > semantics are independent of the URI scheme and thus cannot be redefined > by scheme specifications." -- > >=20 > So for a URN this leaves the door wide open; note "If no such representat= ion > exists, then the semantics of the fragment are considered unknown and are > effectively unconstrained. The problem URN has with this starts from the very concept of "fragment ide= ntifier". URN considers fragment as something that pinpoints a location wit= hin the document identified by URN. Therefore f-component, unlike fragment,= does not identify anything. =20 >=20 > > When URI syntax is applied to a managed URN namespace in which the > identifier syntax and scope are strictly controlled, difficulties will em= erge. I > shall use ISBN as an example, but the issues are not ISBN-specific. > > > > According to URI syntax, urn:isbn: can be extended into > urn:isbn:#fragment to identify some portion of the primary document= . > The namespace specific string is #fragment since fragment must have > a role in identification. > > > > This creates two problems. First, according to the ISBN standard, ISBN > consists of 13 digits, so "#" and fragment cannot be part of the ISBN str= ing. > So fragment-augmented ISBN must not use the ISBN namespace, but e.g. > namespace ISBN-frag. In order to use fragments or queries as required by > the URI syntax, some URN namespaces should therefore have two > additional namespaces, one for fragments and another for queries (say, > isbn-frag and isbn-query in addition to urn:isbn). Such namespace > registrations do not exist and there are no plans to create them. It woul= d be > difficult to specify the scope of such namespaces, especially for query s= ince > we do not know what kind of queries will be used. >=20 > Hm, no. The fragment is not part of the absolute-URI definition, so by > definition it is not part of the URN's namespace-specific string. Do you mean that since fragment is not part of the NSS, it does not identif= y anything in the URN context? Would URI syntax nevertheless mean that sinc= e fragment is part of the URI (though not part of the NSS) it will still id= entify something in the URI sense of the term, which in this case would be = very different from the URN meaning of the term? If so, we are definitely b= etter off using the term f-component which does not identify anything even = as a part of URI.=20 Having both URN identification (in which fragment is ignored) and URI synta= x identification (where fragment counts) incorporated in the same URN would= be confusing. We must be very clear on which parts of the URN string have = a role in identification and which principles are being applied.=20 =20 > > Second, ISBN cannot be used to identify portions of books, such as > chapters. There are other identifier standards such as BICI and DOI for t= his > purpose. So fragment usage augments the scope of ISBN system in an > unacceptable way. Note that it is not possible to modify the ISBN standar= d > in such a way that fragments (or queries) could be used, first and foremo= st > because after this kind of change it would be very difficult to manage IS= BN > assignment in the same quality level as before. >=20 > OK, I agree that using fragment identifiers with ISBN URNs doesn't make > sense. So the choice is between making them illegal/invalid (essentially > saying "don't do that") or leaving their meaning undefined (as per curren= t > RFC 3986). Does the difference really matter? Yes. We want to allow their usage, without giving them a role in identifica= tion. An obvious use case is a researcher who wants to cite an e-book. If t= he book happens to have an urn:isbn and media type supporting fragments, it= is easy to make a HTTP URI into the exact location wanted. But we have to = explicitly allow this in the syntax, and explain that this does not mean th= at the researcher is creating an identifier (in the URN sense of the word) = for that particular location in the book.=20 > > The current version of the revised URN syntax says that fragment and > query have no role in identification. This means that for instance in > urn:isbn:#f-component, the namespace specific string is only= , > and f-component, although part of the URN, has no role in identification. > The fragment only pinpoints a location within the resource identified by = the > ISBN. With this simple change it is possible to avoid both URN namespace > and identifier scope related problems described above. >=20 > This is perfectly ok and does not require any change to RFC 3986. The > fragment isn't part of absolute-URI anyway. With respect to the query > component: what it means and how (or whether) it affects resource > identification is under the control of the URI scheme definition anyway. OK.=20 >=20 > > Generally, I think it is a bad idea to require that URI fragment and qu= ery > must have a role in identification, and the prose describing this practic= e in > RFC 3986 is not crystal clear. >=20 > RFC 3986 does not *require* anything about the query component for > particular URI schemes. It just says that in *general*, it does play a ro= le in > identification. The "URN" URI scheme definition can easily say "but it > doesn't in our case". That "in general" has been a problem. I have not known that we could just s= ay in the URN syntax that in the URN context query does not identify anythi= ng, and based on past discussions I wonder if some followers of this list m= ight disagree. Therefore, even if you were correct, in order to avoid any p= ossibility of confusion and misinterpretations I prefer the current approac= h in rfc2141bis which makes the difference between URIs and URNs clear alre= ady in the syntax. =20 > With respect to fragments: RFC 3986 says that the primary resource is > identified by what's in the absolute-URI, and the meaning of the fragment > either depends on the media type of the associated representation, or, in > absence of a representation, is unconstrained. >=20 > > As regards query, I am not sure what "resource within the scope of the > URI's scheme" means. If the URI scheme is URN, potentially anything is > within the scope and we need to do what rfc2141bis currently does. But if > the scheme is specified in the namespace level, then the scope of urn:isb= n is > defined by the ISBN standard to be monographs only, and for instance > urn:isbn:?q-component which "identifies" metadata record describing > the book identified by ISBN is definitely not within the scope and should= not > identify anything even according to the RFC 3986. Does the URI syntax all= ow > that some resources "identified" by query are outside the scope of the UR= I > scheme. Or, how to specify "within the scope" and "outside the scope" in > this context? This might well be one of those sections in RFC 3986 have > been understood in different ways by different people, which in a standar= d > document is not a good thing. Be that as it may, if the scope is a priori > everything that queries may cover past, present and future - good luck wi= th > it. >=20 > It means "resource identifiable by the URI scheme". Maybe you're trying t= o > read more into this statement than there is. Perhaps so, but since the definition of resource in chapter 1.1 of RFC 3986= covers everything, the assumption of the URI syntax is that nothing is out= side the scope of combined URI schemes. This enables everything to be part = of the semantic web, but it also makes the management of identifiers diffic= ult.=20 > >>From URN point of view, the easiest solution would be to say in > rfc3986bis that no resources "identified" by query are within the scope o= f > the URN scheme and therefore in the URN syntax q-component has no role > in identification unlike other URIs. Or, to formulate this less strictly,= it is > possible that in some URN namespaces some resources "identified" by > queries may be out of the scope and therefore, to avoid any false positiv= es, > in URN syntax q-component never identifies anything. >=20 > That's under control of the URN scheme definition. If you want do define > that, you can. >=20 > > Fragments have their own general issues when used as "identifiers". It = is > non-trivial - at least to me - to see exactly what has been identified, s= ince > fragment isn't an identifier, but just a locator. Just to give you a simp= le > example, my library has millions of digitized text documents which have v= ery > detailed XML schemas. Without going to any technical details, we could > create the following URNs: >=20 > How do you come to the conclusion that fragment are locators, not > identifiers, and what's the difference in practice? >=20 > > urn:isbn:#chapter1 > > urn:isbn:#chapter1para1 > > urn:isbn:#chapter1para1line1 > > urn:isbn:#chapter1para1line1word1 > > urn:isbn:#chapter1para1line1word1letter1 > > > > According to the rfc2141bis, all these URNs are equivalent (they identi= fy > the same book, and only that), but they indicate different locations with= in > the first chapter of the identified book. Anyone could create these URNs > once the national library has established the base URN. This is not a > mandate problem since fragments have no role in identification. >=20 > Wow, they are *equivalent*, but indicate *different* locations? That's > IMHO a very very surprising definition of equivalence. It probably would = be > good to use a more specific term. Equivalence in this case means that all the URNs above identify the same bo= ok because NSS in each case is the same ISBN. =20 Fragments in these examples cover different portions of the text. From URI = syntax point of view, they would not identify the same thing. However, had = I used f-component, it would have been clear that these f-components do not= identify anything, neither under URN syntax nor URI syntax. =20 > > According to RFC 3986, we would have something like > > > > urn:isbn-frag:#chapter1 > > urn:isbn-frag:#chapter1para1 > > urn:isbn-frag:#chapter1para1line1 > > urn:isbn-frag:#chapter1para1line1word1 > > urn:isbn-frag:#chapter1para1line1word1letter1 >=20 > These seem to be identical to the first set of examples, except for the > differing namespace name... Yes, but they identify a location (the beginning of the text) or a portion = of the text or both, depending on what urn-frag namespace specification say= s. >=20 > > and each URN would "identify" a different portion of the book, but it i= s not > obvious what that portion is and how these fragment identifiers relate to > one another, or who would have the authority to mint these identifiers. > When resolved, they would all take the user to the beginning of the actua= l > text. >=20 > I find this very very confusing. In the first case the URI identifies a b= ook and > also indicates a location within the book. In the second case, the URI > identifies a location within a book. .. or a portion of a book. Without having the namespace registration reques= t at hand, we would not be sure which.=20 >=20 > Both use exactly the same syntax except for the URN namespace name. > What do you base the distinction on, and who is supposed to understand > that? Sorry, I made a mistake in this example. The ISBN namespace examples should= be using the q-component instead of URI query.=20 URN namespaces are important. It is possible to have two URNs with identica= l namespace specific strings but different namespace IDs. These URNs would = identify different resources and they would be resolved differently. No hum= an needs to understand this, it is up to URN resolvers to deal with the sit= uation.=20 In this rather theoretical example, resolvers for urn:isbn and urn:isbn-fra= q might produce similar results. But from identification point of view thes= e namespaces are very different. urn:isbn only identifies books, urn:isbn-f= rag only locations within / portions of books. There is no overlap between = these namespaces, and both of them would be managed, although probably by d= ifferent kinds of organizations. =20 All the best, =20 Juha PS. I shall be on holiday next week and do not intend to read my work email= .=20 >=20 > > ... >=20 > Best regards, Julian From nobody Fri May 20 07:54:31 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0A812D1C9 for ; Fri, 20 May 2016 07:54: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 CIlhT0BRiG4v for ; Fri, 20 May 2016 07:54:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B1012D181 for ; Fri, 20 May 2016 07:54:27 -0700 (PDT) Received: from [192.168.1.123] ([5.10.171.186]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M3u86-1buE4u1xac-00rUDp; Fri, 20 May 2016 16:54:18 +0200 To: "Hakala, Juha E" , "urn@ietf.org" References: <5050b843-cd5d-c423-004d-82674fa5c7ea@gmx.de> From: Julian Reschke Message-ID: Date: Fri, 20 May 2016 16:54:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:8pYtg8ymzljjnmikOCzwDdajEROKzjvD5S2XiK1j9ywvFjns3NR TlMbCW5GLt/h8Zd5VCQbHWh/tPF6flrO1AKUeHb4BXQxh5u+XBsw5WL+6ssrzyjiI+kdzYk dn4hAShwrj82d8ckp90w2yHB0KRNMkOB/5tEwhdzOj8HxQuyvePV4NFdSV8m7qzV+vU7oTx 2F64cOOeRMKaxP2sCuvoA== X-UI-Out-Filterresults: notjunk:1;V01:K0:jVJ/dULun1Q=:hrm2ipBHu5BXBiN/DLAFFR 2J8a4c+wBCjxj+46lNzJ+xW1B6sOkKei1Z8AdcRAT4dCg1WOCb1z5KNM7AO9bIhzRfIy3aH6P sAykKoQEcdbJD0sKS9oQJVqod9Zf+R59oIpAHiK+43vCjqPEWCtJEZfZjvwJqFAfhip6ffrwZ RT4XUid03PAG1n2t1oh3+M+LBeqZDMoEQ9q4hxxHvoGdj9YL1in0PrpGVUrJdB6/eVQPgtoRh QhWJ6PJJJtN41BgiKQrUfI4FlY1zmzLQY/UCmE3Fpn3bAd3z0fWMtPvW7siiK2C+eHDruM37R I7swbquodl0V4DJUSM2tzVpfhV/AzQsN9nnS1VSvPoKGJSWxr0yy8duhqWDH5IU74eIJ4JZSm NBIDPF15hTYG6oO39zv3FcVTJJmECATW6hDtSqOYeHX6lPTwQvWyK8nIzCdbKN+vG7o7k0JLF CYA1Honm6FfWHRJMQFfsvha4B+2duJXHBeEOMFEugrduq0zint9YDp98pOMWA/XuSE3Dl46lk qoK6p84sLVtX0u6PDhRjI6l6wUhPKGNxyJSEAT62mpHLLnIqEHHpHrUZKfFkTDakQZm5PdbRm 9t+TdFeworCBjhscvS23gBvxSBnKKdDakrEL8XcUSpAjNekns4Y5a1bBd4Vxa0tlQT0h+0jO2 FVG9nbmtClqbcgwWBQigBIw9I0miYxVrY7hikZg6Z2aCMWKesUIY9gTkvX27mwDj3Q/2f01KP hMUER58Lqh70qpS1Y676epAzNDCXPiVczv6vBZpLXTBlEJGPU9fPihbn5I/Hr7dHA0DSNL24C fIHKRkk Archived-At: Subject: Re: [urn] URN and URI semantics X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 14:54:31 -0000 On 2016-05-20 14:57, Hakala, Juha E wrote: > Hello Julian, > > Thank you for the feedback. I hope we are getting closer to sufficient alignment of our views. Some comments below. > >> -----Original Message----- >> From: Julian Reschke [mailto:julian.reschke@gmx.de] >> Sent: 20. toukokuuta 2016 10:39 >> To: Hakala, Juha E ; urn@ietf.org >> Subject: Re: [urn] URN and URI semantics >> >> Hi Juha, >> >> >> The query is part of of the absolute-URI ABNF production >> (). What >> the absolute-URI contains is under full control of the URI scheme. So it's up >> to the definition of the "URN" URI scheme to define whether queries are >> allowed, and if they are, what they mean (or of course it can be delegated to >> the URN namespace definitions). > > In the URN syntax context, we don't want to prevent a priori the usage of r/q/f-components. The only exception to this are namespaces were fragments are out of scope since nothing tangible is identified, or namespaces which have no intention to support resolution services. These exceptions can be clarified in the namespace registration requests. I continue to focus on the relation between URNs and RFC 3986. From RFC 3986's point of view, it doesn't matter at all how you name this stuff, as long as it doesn't conflict with RFC 3986. Looking at the urnbis grammar: > > namestring = assigned-name > [ rq-components ] > [ "#" f-component ] > assigned-name = "urn" ":" NID ":" NSS > NID = (alphanum) 0*30(ldh) (alphanum) > ldh = alphanum / "-" > NSS = pchar *(pchar / "/") > rq-components = ( "?=" q-component > [ "?+" r-component ] ) / > ( "?+" r-component > [ "?=" q-component ] ) > q-component = pchar *( pchar / "/" / "?" ) > r-component = pchar *( pchar / "/" / "?" ) > f-component = fragment I note that f-component is only referenced in "namestring", and that term occurs only once in the whole spec. It *looks* that it intends to make the fragment part of the NSS (right?), which would violate the RFC 3986 *syntax*. You can't have an unescaped "#" in an absolute-URI. > Even if e.g. the usage of q-component is not possible when the identifier is minted, it may become relevant later when the technical infrastructure within which URNs are used becomes more mature. Note that for every URN, over time there could be literally hundreds of different q-components, facilitating various kinds of service requests. This is not a problem. It's totally up to the definition of the URI scheme. > So from absolute-URI point of view, we need to allow queries (q-components). The one thing we cannot allow is that they would actually have a role in identification. Again, the URI scheme definition can define how URIs in *that* scheme identify things, which implies that parts of the URI do not. (I personally find that idea very strange, but then, I'm currently not focusing on that). > ... >> So for a URN this leaves the door wide open; note "If no such representation >> exists, then the semantics of the fragment are considered unknown and are >> effectively unconstrained. > > The problem URN has with this starts from the very concept of "fragment identifier". URN considers fragment as something that pinpoints a location within the document identified by URN. Therefore f-component, unlike fragment, does not identify anything. That doesn't make any sense to me. How can something "pinpoint a location" but not "identify"? That being said it sounds like you're looking for something that isn't a fragment identifier. If this is that case, create a new syntactical, URN-specific component that can not be confused with a URI fragment identifier.This rules out introducing it with "#". > ... >> Hm, no. The fragment is not part of the absolute-URI definition, so by >> definition it is not part of the URN's namespace-specific string. > > Do you mean that since fragment is not part of the NSS, it does not identify anything in the URN context? Would URI syntax nevertheless mean that since fragment is part of the URI (though not part of the NSS) it will still identify something in the URI sense of the term, which in this case would be very different from the URN meaning of the term? If so, we are definitely better off using the term f-component which does not identify anything even as a part of URI. A literal "#" can not appear in the NSS, thus the NSS can't contain a fragment identifier in the sense of RFC 3986. You can *append* a fragment identifier to a URN: URI, but that means it's still falls under what RFC 3986 says about it. (This discussion shows why it's essential that it's clear what exactly the URN specs try to "update" in RFC 3986) > Having both URN identification (in which fragment is ignored) and URI syntax identification (where fragment counts) incorporated in the same URN would be confusing. We must be very clear on which parts of the URN string have a role in identification and which principles are being applied. I'm still not convinced that there's a problem here. Do http://example.net/#foo and http://example.net/#bar identify the same resource? No (or not necessarily). Do the absolute-URI parts of these URIs identify the same primary resource? Yes. Is this really so different from your problem space? > ... > > Yes. We want to allow their usage, without giving them a role in identification. An obvious use case is a researcher who wants to cite an e-book. If the book happens to have an urn:isbn and media type supporting fragments, it is easy to make a HTTP URI into the exact location wanted. But we have to explicitly allow this in the syntax, and explain that this does not mean that the researcher is creating an identifier (in the URN sense of the word) for that particular location in the book. As the fragment identifier by definition isn't part of the namespace-specific string, how is that a problem? (Apart from the urnbis spec grammar getting this wrong?) > ... >> RFC 3986 does not *require* anything about the query component for >> particular URI schemes. It just says that in *general*, it does play a role in >> identification. The "URN" URI scheme definition can easily say "but it >> doesn't in our case". > > That "in general" has been a problem. I have not known that we could just say in the URN syntax that in the URN context query does not identify anything, and based on past discussions I wonder if some followers of this list might disagree. Therefore, even if you were correct, in order to avoid any possibility of confusion and misinterpretations I prefer the current approach in rfc2141bis which makes the difference between URIs and URNs clear already in the syntax. No, it's really not a problem. URI schemes vary on normalization thus on what identifies different things. See all of . >> ... >> It means "resource identifiable by the URI scheme". Maybe you're trying to >> read more into this statement than there is. > > Perhaps so, but since the definition of resource in chapter 1.1 of RFC 3986 covers everything, the assumption of the URI syntax is that nothing is outside the scope of combined URI schemes. This enables everything to be part of the semantic web, but it also makes the management of identifiers difficult. That maybe true, but what's the concrete conclusion with respect to URNs? Just because RFC 3986 says that a URI essentially can identify anything doesn't mean the same things needs to be true for URI in the URN scheme. > ... >> How do you come to the conclusion that fragment are locators, not >> identifiers, and what's the difference in practice? >> >>> urn:isbn:#chapter1 >>> urn:isbn:#chapter1para1 >>> urn:isbn:#chapter1para1line1 >>> urn:isbn:#chapter1para1line1word1 >>> urn:isbn:#chapter1para1line1word1letter1 >>> >>> According to the rfc2141bis, all these URNs are equivalent (they identify >> the same book, and only that), but they indicate different locations within >> the first chapter of the identified book. Anyone could create these URNs >> once the national library has established the base URN. This is not a >> mandate problem since fragments have no role in identification. >> >> Wow, they are *equivalent*, but indicate *different* locations? That's >> IMHO a very very surprising definition of equivalence. It probably would be >> good to use a more specific term. > > Equivalence in this case means that all the URNs above identify the same book because NSS in each case is the same ISBN. Let's use "URN-quivalent" instead of "equivalent" for a moment. So you want that two URIs are "URN-equivalent" when their absolute-URI parts identify the same primary resource. You can define this sort of equivalence (as any URI scheme can have it's own scheme-specifc equivalence rules). I just don't find that type of equivalence definition very useful (because it's very counter-intuitive). > Fragments in these examples cover different portions of the text. From URI syntax point of view, they would not identify the same thing. However, had I used f-component, it would have been clear that these f-components do not identify anything, neither under URN syntax nor URI syntax. You lost me. What's the difference if you had used f-components instead of fragments? What would these URIs look like? >>> According to RFC 3986, we would have something like >>> >>> urn:isbn-frag:#chapter1 >>> urn:isbn-frag:#chapter1para1 >>> urn:isbn-frag:#chapter1para1line1 >>> urn:isbn-frag:#chapter1para1line1word1 >>> urn:isbn-frag:#chapter1para1line1word1letter1 >> >> These seem to be identical to the first set of examples, except for the >> differing namespace name... > > Yes, but they identify a location (the beginning of the text) or a portion of the text or both, depending on what urn-frag namespace specification says. >> >>> and each URN would "identify" a different portion of the book, but it is not >> obvious what that portion is and how these fragment identifiers relate to >> one another, or who would have the authority to mint these identifiers. >> When resolved, they would all take the user to the beginning of the actual >> text. >> >> I find this very very confusing. In the first case the URI identifies a book and >> also indicates a location within the book. In the second case, the URI >> identifies a location within a book. > > .. or a portion of a book. Without having the namespace registration request at hand, we would not be sure which. >> >> Both use exactly the same syntax except for the URN namespace name. >> What do you base the distinction on, and who is supposed to understand >> that? > > Sorry, I made a mistake in this example. The ISBN namespace examples should be using the q-component instead of URI query. OK, can we please re-do the examples, and the re-start the discussion? > URN namespaces are important. It is possible to have two URNs with identical namespace specific strings but different namespace IDs. These URNs would identify different resources and they would be resolved differently. No human needs to understand this, it is up to URN resolvers to deal with the situation. Yes. I don't believe anybody disagrees with that. > ... Best regards, Julian From nobody Fri May 20 08:25:30 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BB112D9F9 for ; Fri, 20 May 2016 08:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=unavailable autolearn_force=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 TZGKR8VljRty for ; Fri, 20 May 2016 08:25:26 -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 1B67112D1E6 for ; Fri, 20 May 2016 08:18:20 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1b3mBq-0008j7-LW; Fri, 20 May 2016 11:18:14 -0400 Date: Fri, 20 May 2016 11:18:09 -0400 From: John C Klensin To: Julian Reschke Message-ID: In-Reply-To: References: <5050b843-cd5d-c423-004d-82674fa5c7ea@gmx.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.10 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] URN and URI semantics X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 15:25:28 -0000 Julian, I'm still trying to wait for instructions from the co-Chairs before getting drawn into this thread, but one substantive clarification below... --On Friday, May 20, 2016 16:54 +0200 Julian Reschke wrote: >... > Looking at the urnbis grammar: > >> >> namestring = assigned-name >> [ rq-components ] >> [ "#" f-component ] >> assigned-name = "urn" ":" NID ":" NSS >> NID = (alphanum) 0*30(ldh) (alphanum) >> ldh = alphanum / "-" >> NSS = pchar *(pchar / "/") >> rq-components = ( "?=" q-component >> [ "?+" r-component ] ) / >> ( "?+" r-component >> [ "?=" q-component ] ) >> q-component = pchar *( pchar / "/" / "?" ) >> r-component = pchar *( pchar / "/" / "?" ) >> f-component = fragment > > I note that f-component is only referenced in "namestring", > and that term occurs only once in the whole spec. Yes, that was our interpretation of what the WG told us to do when we were told quite forcefully (IIR, by a 3986 co-author) that fragment was strictly a matter of the definition in 3986 and that 2141bis should not say anything about it. If 3986 is now to be read the way you suggest such that, (approximately) because URNs do not resolve directly to an object with a media type, they can and should be defined by the scheme and maybe on a per-namespace basis, I think we can find some old text to put back in. Speaking personally (but as the person holding the pen at the moment) I really don't care which option is chosen, only that we do not keep going around in circles about it. > It *looks* that it intends to make the fragment part of the > NSS (right?), which would violate the RFC 3986 *syntax*. You > can't have an unescaped "#" in an absolute-URI. How do you reach that conclusion? I see namestring = assigned-name [ rq-components ] [ "#" f-component ] The NSS is part of (see syntax quoted above) and f-component (and therefore "fragment") hangs off the end of the namestring, following "#". If that is not compatible with the 3986 syntax (especially the syntax that conforms to RFC 2234/ 4234/ 5234), I need help in understanding why. >... best, john From nobody Fri May 20 08:39:06 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AEC12DA39 for ; Fri, 20 May 2016 08:39:04 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 e2F449h8osQI for ; Fri, 20 May 2016 08:39:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0035012DA27 for ; Fri, 20 May 2016 08:38:58 -0700 (PDT) Received: from [192.168.1.123] ([5.10.171.186]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lm6IP-1bcq920brN-00Zfql; Fri, 20 May 2016 17:38:41 +0200 To: John C Klensin References: <5050b843-cd5d-c423-004d-82674fa5c7ea@gmx.de> From: Julian Reschke Message-ID: <9d3de851-5297-6eae-1aa5-ed92a3c2c7fe@gmx.de> Date: Fri, 20 May 2016 17:38:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:KNLB2Z8j5C9UmzAkr9Qx5A8RnpsAGbNtefv5z9xuzr/yRm34yxo tlZssnNjfxAb4MwiD0CAkiZvTNqOOtqNB49wmK6qqpB8sFzESQfeS8rUI2ha2A4pUmtTSCO L16HPArkpuHgjXYcVgaT33S/zpyaG2pxvrZDMI4gTlKgZHbTnXNs7ZPgGtMbef60lAJnx3G e1ovWIE/n15labGzPQyxQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:RPjMULK1hfk=:OPL/S2XQjtmbPtIPED6YgE wIeEGZVgPamrWtnxAGB23/dttIekB8totLA3ametD38PctkQrM85krYfuzX6zcd4s5GlB7S8i A9Al+7eUqZV+xzEqffPtte0YocV1yYJwrf/bqrJaPCyQZhjysY81kHDVExsmnNJ+SoM8zLApP qLrf/YtipUE8brhyxrNfbVBIbMDHLPpzzJzAt49tigmBq1d/v+k5QEt65XPjCtejyNK4AK6rv Fdg8sFRqe0WAQEIfruv1BT6UGEl7FXOain7wptXkgccv5jo6wqy6eLIa/YxxtoZj7PI/7auuy hSXrX7jlZjSKupLO4MgzBguX3gxXK78ZtWjhwslSxa+vz7NVbhy+A4EjdLG3eJ72p48srU0aj 5ebIULWVcbQx1/jiUzKAIkwJ0/xfkq/GieCXlK5gKMpYEz0U4euVXMchZI5tbdbrXH/fHYlyj Hxyjej2Nqk4FrRq0DnhZxoyKmtvLRZcKk9YPqAU9dF0KiGIn5KdbhDekEsbQEbAfssi8bEmgg UftSZ6E0gQCPvANWCafcKMoAyb6vpM7TaPQ3zDn3bFCUGevbarHmrFiwVSS6qZ5PVMlOqG7Tv mEs6AyyXM02FqKk9BVYMwftlXNbHoA8lMVeug7r3ZBn3x7a/287Iev4aekWviaOihshf+lS/a EII4X6ZQi+6QXDecZupBgMI4h7V6N7vBISlPGRFJjtJR4udlLUAT6x77Y+x4ik60OIXBM07cR ieiTEVBFLfdpv8WlgG+rMeKnLl4rOtIm05rQxnl3rpr8yYIs0OLzFNd0Ngvpr1Kb6edcgYbUo mSBDEYEISvNDeKchSBvZuToymRmww== Archived-At: Cc: urn@ietf.org Subject: Re: [urn] URN and URI semantics X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 15:39:04 -0000 On 2016-05-20 17:18, John C Klensin wrote: > Julian, > > I'm still trying to wait for instructions from the co-Chairs > before getting drawn into this thread, but one substantive > clarification below... > > --On Friday, May 20, 2016 16:54 +0200 Julian Reschke > wrote: > >> ... >> Looking at the urnbis grammar: >> >>> >>> namestring = assigned-name >>> [ rq-components ] >>> [ "#" f-component ] >>> assigned-name = "urn" ":" NID ":" NSS >>> NID = (alphanum) 0*30(ldh) (alphanum) >>> ldh = alphanum / "-" >>> NSS = pchar *(pchar / "/") >>> rq-components = ( "?=" q-component >>> [ "?+" r-component ] ) / >>> ( "?+" r-component >>> [ "?=" q-component ] ) >>> q-component = pchar *( pchar / "/" / "?" ) >>> r-component = pchar *( pchar / "/" / "?" ) >>> f-component = fragment >> >> I note that f-component is only referenced in "namestring", >> and that term occurs only once in the whole spec. > > Yes, that was our interpretation of what the WG told us to do > when we were told quite forcefully (IIR, by a 3986 co-author) > that fragment was strictly a matter of the definition in 3986 > and that 2141bis should not say anything about it. If 3986 is But then why *does* it say something about fragments? > now to be read the way you suggest such that, (approximately) > because URNs do not resolve directly to an object with a media > type, they can and should be defined by the scheme and maybe on > a per-namespace basis, I think we can find some old text to put > back in. Speaking personally (but as the person holding the When say "they", are you referring to fragments? In which case: no, that's not what I meant. I was just trying to understand what the grammar says, ans was confused by the way it's currently defined. > pen at the moment) I really don't care which option is chosen, > only that we do not keep going around in circles about it. > >> It *looks* that it intends to make the fragment part of the >> NSS (right?), which would violate the RFC 3986 *syntax*. You >> can't have an unescaped "#" in an absolute-URI. > > How do you reach that conclusion? I see > > namestring = assigned-name > [ rq-components ] > [ "#" f-component ] > > The NSS is part of (see syntax quoted above) and > f-component (and therefore "fragment") hangs off the end of the > namestring, following "#". Ah, ok. So what *is* a namestring then? It now sounds it is a RFC 3986 URI ("URI" ABNF production) in the "urn" URI scheme. In which case the spec should say so (and "namestring" is really a confusing term). > If that is not compatible with the 3986 syntax (especially the > syntax that conforms to RFC 2234/ 4234/ 5234), I need help in > understanding why. Best regards, Julian From nobody Fri May 27 18:18:06 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E05012D696 for ; Fri, 27 May 2016 18:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.783 X-Spam-Level: **** X-Spam-Status: No, score=4.783 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SBL_CSS=3.335] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 INOFEQZSJV_i for ; Fri, 27 May 2016 18:18:03 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (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 5677912D5A7 for ; Fri, 27 May 2016 18:18:03 -0700 (PDT) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by comcast with SMTP id 6Sr7bbZ2f7xvb6St8blZTM; Sat, 28 May 2016 01:18:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1464398282; bh=Zj0aEQm0tTpsIlevsUiJ1T/0Ej9dsoTs4S8iZh9NQm0=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=umVAOx7wuPWTz6paU9msz1GQpvNxjbY4LrbOxKflOVFxNzvJaHDdCcE625XRw3fj4 rpNnWhooY7wK39W4Za89IIkSLV2HbaumZD7wRkTaMIzffJViTaEgb8Q903Xv1uyICG daM3RECaDK7Y+nzuC+FDSYhJWlP9TUWBXe94NmpKgEkkNwPUMUtni9NKPVntOECJQY VHq4IYJQxSZ1VuGOW50lTV1qJpGnfPvXkJ0x5pGrCn8bFTqXnj6BaMxrQPeB8ARyMF EEkn/rVIeHYKevyNKpPRy6cGQYzRJGXZUp2tYINHNGs4QdouRtZUEMQoz++w9Eb2Xy gpdKHHz8d7Jow== Received: from wqof.org ([5.154.17.61]) by resomta-po-12v.sys.comcast.net with comcast id zdEo1s00U1K3M1x01dFQJJ; Sat, 28 May 2016 01:15:57 +0000 From: URN-NID To: "Jarrett Wold" , "urn-nid" , "urn-nid" , "urn" , "Ulises Parra" Date: Sat, 28 May 2016 04:15:15 +0300 Message-ID: <000031709947$55b9bd46$7d115dad$@mallorn.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_5A0ABA94.471278E8" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdG1P1oygBi/FTG/7pcAez9wmZ7jMg== Content-Language: en-us Archived-At: Subject: [urn] wowsome X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2016 01:18:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_5A0ABA94.471278E8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hey, Have you heard about that really wowsome stuff? You won't regret, believe me, read more here Sincerely yours, URN-NID ------=_NextPart_000_0001_5A0ABA94.471278E8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<= span lang=3DEN-US>Hey,

 

Have you heard about that really wowsome stuff? You won't = regret, believe me, read more here http://shutankulti.muttsandnutters.com/aejyr=

&nb= sp;

Sincerely = yours, URN-NID

------=_NextPart_000_0001_5A0ABA94.471278E8-- From nobody Sat May 28 07:42:23 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419BB12B022 for ; Sat, 28 May 2016 07:42: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_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 F-CXNcwJi2QU for ; Sat, 28 May 2016 07:42:21 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 CF95112B00F for ; Sat, 28 May 2016 07:42:20 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 06E6F50A86; Sat, 28 May 2016 10:42:18 -0400 (EDT) To: "urn@ietf.org" References: <231532ef-e195-b73d-4a34-eb445bdd1900@gmx.de> <1F5D414703BF94503600A5E3@JcK-HP8200.jck.com> <9dd1f7f1-843e-822b-a352-8b51d6f4192c@gmx.de> From: Sean Leonard Message-ID: <0626757a-430e-4c25-07e0-efd04e92c377@seantek.com> Date: Sat, 28 May 2016 07:41:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <9dd1f7f1-843e-822b-a352-8b51d6f4192c@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Julian Reschke Subject: [urn] Summary of WG decisions Re: Feedback on draft-ietf-urnbis-semantics-clarif-03 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2016 14:42:22 -0000 On 5/17/2016 9:10 AM, Julian Reschke wrote: > On 2016-05-17 17:38, Andrew Newton wrote: >> >> Which hasn't changed. The group previously decided to go down the >> "syntax only" path. This has been discussed in documents and several >> working group sessions. And I don't think we should reopen the issue >> as it was a pivotal decision that has been a prerequisite for the >> progress made so far. >> ... > > WG consensus isn't IETF consensus. If this WG wants to update a=20 > standards track document, it will have to be able to answer the=20 > questions that I asked. > > I hear from you and John: "RFC 3986 syntax, but not semantics", as if=20 > there was agreement about what parts of RFC 3986 are which (or is=20 > there?). > > So, once again, if we say "updates: 3986" we need to be able to=20 > explain *precisely* which parts of RFC 3986 are affected (and why, fwiw= ). I agree with Julian that these sorts of questions need to be answered. Given the low & declining engagement on this list, we need a place to=20 record WG decisions that newcomers or people who only have a time budget = to participate occasionally, can get up to speed and (re-)engaged. The=20 document(s) itself/themselves have not been a useful guide to the=20 proceedings of this WG. I strongly advocate that we use some new tools to track and record WG=20 decisions that the co-chairs and ADs have declared to be the rough=20 consensus (or going-forward) positions. Specifically, I recommend that=20 we use the IETF urnbis wiki. I have already created a basic wiki page=20 for this purpose: https://tools.ietf.org/wg/urnbis/trac/wiki/WGDecisions We have some people saying "oh, the WG decided that, I'm not going to=20 re-open that issue", when there is material technical disagreement about = whether some decision is doable, or there is historical disagreement=20 about what decision was actually made. Two examples: (1) I recall specifically that this WG decided that URN syntax shall=20 conform to RFC 3986 URI syntax. (I cannot find a specific e-mail=20 reference for it.) That much I can work with. There is material=20 disagreement about whether, and to what extent, URN "semantics" either=20 need to--or must not--conform to RFC 3986 URI "semantics". I have=20 searched and can find no record of decision on this point. A lot of=20 recent objections / elliptical decisions on things like "what is a=20 resource?" and so on, have been fueled because people are throwing up=20 arguments about what has been decided, when the semantics issue has=20 (apparently) not been decided. My take on this, is that URN syntax =3D=3D=3D URI syntax. Whether and to = what=20 extent URN semantics =3D=3D URI semantics, is not a decided WG issue.=20 Therefore saying "oh, the WG decided syntax but not semantics" is=20 inaccurate. Actually the semantics issue has been misunderstood. RFC 3986 pretty=20 much says that a "resource" is anything that can be identified by a URI, = so it's a circular definition. If you can name it, you can claim it. The = end. An RFC 3986 "representation", in contrast, is an actual concrete=20 computable thing, and could be (for example) a content with a media=20 type. This really is a debate about nomenclature in the documents. This=20 WG can repurpose the term "resource" in a URN to mean something other=20 than RFC 3986, but it's confusing if we are not updating RFC 3986. (I do recall specifically that a chair or AD stepped in a couple of=20 years back and declared updates to RFC 3986 to be out of scope of this=20 WG. I cannot find the reference.) (2) RFC 2141 says that NSS is UTF-8 encoded. RFC 5198 (NETUNICODE) says=20 that updated stuff SHOULD use Unicode/UTF-8. This WG is technically=20 constrained to follow UTF-8 percent-encoding for NSS, and SHOULD nail=20 down UTF-8 for the other parts in its purview (i.e., the query=20 production). I do not believe that this WG finally made a decision on=20 the point; however, the predecessor WG obviously made a decision, so we=20 should consider that pretty weighty in terms of what to follow, clearly=20 decide if there is a need to deviate, and be done with it. I have set up the wiki so that existing participants and newcomers alike = can adhere to the decisions made, with documented evidence. I hope that=20 we can use this tool, or a similar tool like it. Regards, Sean From nobody Tue May 31 06:31:40 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2059212D515 for ; Tue, 31 May 2016 06:31:39 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hxr-us.20150623.gappssmtp.com 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 c-4508ZcFIXO for ; Tue, 31 May 2016 06:31:37 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 EF5F412D1DC for ; Tue, 31 May 2016 06:31:36 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id n129so132134915wmn.1 for ; Tue, 31 May 2016 06:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=zqSU7HCULAlBJ6dwc8WSeP/Sat96jwvCpaB/ST84jlc=; b=cjgd0CqDNbG8pnlGLf+MP1aafs+c6F4CREmdUPnpTdO5dF3gIJveGOsbJwwu5G1pm7 X/71O+Sr3nHwqIzI9OzX49FvRjbkyW97jiPQdSFl7H/3Xe74cCgKAqTMaSv4iprRrGkX +wPcOUmXNVlEwqZCNP1GgiMc4DUrvSdyO7zJaI/lu/IHjSQHgZe+T+cj0Vyb/4PowhLM gh5NEObMQJY1YPqbNxX/WgBkYhd80PoLwNZ3lBbgBVWbn3pQWprN3oz/D1yGH5brSBil rh0MgZ74Lcyxqtf8XM7vpDf+fE60GtyCP0KhflDqw2iXz00xEL5h6N8/JubWUVTxiGjH P5Qw== 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; bh=zqSU7HCULAlBJ6dwc8WSeP/Sat96jwvCpaB/ST84jlc=; b=BVP/zUnXFM0JPTIisiDZOU8OlNZvX10FeLo9tDMuyWgXtbQUnrEavOmyMAEeNG7+xi tchoNQTUPTiTfJXtmWDzDf8Upq7lFKQbIswItjWZTiE1EA3i3O81mce4SLS64XAhoiIo OxcRDSDQ+ZZ5vtbnPXC1mSXamgxXc1Ix4B55fhXN96nsGaxE/Rxn8D4ugOeZePKlYfos Cy1bEiegJGoi62khJGuaSjoWqZm1thkJ+S5tAjyOwwUqYsD6IyyvZHBsgo3OEn1oJ8NK vL3CYJL2pHBJqd/MhghDPe0ba8htQ33uib/QKL5SnpVoL+SSackxDcglsYFNAe/7bXHl 1oew== X-Gm-Message-State: ALyK8tJWSAf6DTU3FRyqCu7aweN6tOfEKqozGV/b2JE0T9KlK1KFU4FirfRMgJ3Xn6xf7+7MnCeAV4BHro6xLQ== MIME-Version: 1.0 X-Received: by 10.28.14.19 with SMTP id 19mr3466652wmo.11.1464701495426; Tue, 31 May 2016 06:31:35 -0700 (PDT) Received: by 10.194.153.39 with HTTP; Tue, 31 May 2016 06:31:35 -0700 (PDT) X-Originating-IP: [192.149.252.11] In-Reply-To: <0626757a-430e-4c25-07e0-efd04e92c377@seantek.com> References: <231532ef-e195-b73d-4a34-eb445bdd1900@gmx.de> <1F5D414703BF94503600A5E3@JcK-HP8200.jck.com> <9dd1f7f1-843e-822b-a352-8b51d6f4192c@gmx.de> <0626757a-430e-4c25-07e0-efd04e92c377@seantek.com> Date: Tue, 31 May 2016 15:31:35 +0200 Message-ID: From: Andrew Newton To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Julian Reschke , "urn@ietf.org" Subject: Re: [urn] Summary of WG decisions Re: Feedback on draft-ietf-urnbis-semantics-clarif-03 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 13:31:39 -0000 Let me address a couple of points with one message: On Sat, May 28, 2016 at 4:41 PM, Sean Leonard wrote: > On 5/17/2016 9:10 AM, Julian Reschke wrote: >> So, once again, if we say "updates: 3986" we need to be able to explain >> *precisely* which parts of RFC 3986 are affected (and why, fwiw). Just for my sanity, I reread draft-ietf-urnbis-semantics-clarif-03.txt. It seems to me that this draft does exactly the thing you have requested. If you have found an issue with this draft in the context of updating 3986 (or any other issue), can you please start a separate thread so we may address the issue? > Two examples: > (1) I recall specifically that this WG decided that URN syntax shall conform > to RFC 3986 URI syntax. (I cannot find a specific e-mail reference for it.) > That much I can work with. There is material disagreement about whether, and > to what extent, URN "semantics" either need to--or must not--conform to RFC > 3986 URI "semantics". I have searched and can find no record of decision on > this point. A lot of recent objections / elliptical decisions on things like > "what is a resource?" and so on, have been fueled because people are > throwing up arguments about what has been decided, when the semantics issue > has (apparently) not been decided. Again, see the draft mentioned above. And note that it is a working group document. > (I do recall specifically that a chair or AD stepped in a couple of years > back and declared updates to RFC 3986 to be out of scope of this WG. I > cannot find the reference.) I think it was stated at one of our few wg meetings. But to clarify, we are not re-writing 3986 and tackling that entire URI space. That is very out-of-scope. -andy From nobody Tue May 31 06:40:00 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9685312D18D for ; Tue, 31 May 2016 06:39:59 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 G14B3brOuRX4 for ; Tue, 31 May 2016 06:39:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667B012D1CD for ; Tue, 31 May 2016 06:39:54 -0700 (PDT) Received: from [192.168.178.20] ([93.217.80.42]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M936L-1bD0IM1LWX-00CSn4; Tue, 31 May 2016 15:39:35 +0200 To: Andrew Newton , Sean Leonard References: <231532ef-e195-b73d-4a34-eb445bdd1900@gmx.de> <1F5D414703BF94503600A5E3@JcK-HP8200.jck.com> <9dd1f7f1-843e-822b-a352-8b51d6f4192c@gmx.de> <0626757a-430e-4c25-07e0-efd04e92c377@seantek.com> From: Julian Reschke Message-ID: Date: Tue, 31 May 2016 15:39:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:5y4LHuUEjhxp6nxtCjAbPT7VpaXcb30WfuxSLsTf13pjqBaKtp3 Ph97ZkBI+iIVTKJXe6UAuRSvo4aXRQw5Xqkk1LzYYeX6UMWelbtF6IwTOYn/FFxD+U0DIi4 ppMxAG4sClS3mQAe98XUORZv/JYMtwinUQ/VxQGPiyUs0BFzVaKR9nN8gK77iOJiA1XtYdK Sz6H1z3t33F3nH1lPJLUA== X-UI-Out-Filterresults: notjunk:1;V01:K0:DzfTEg15gOg=:bEG7s5YHQ/Tg/8xP9Agbb8 R/a0Q1Xsh/B24VHuOzK2P0LjMTpbAvVPa49hSOTFclUR8cz9cH2fKFNJSfdVAOLwV1Mqsc6g9 U6IOcBfHxlSkAdf0kgiVaMoM4PEYEGM7VYWiEb0RT/3aXKtfOpjr7/sY9noMiOE4ukkYRwrr0 TkOs7if7yiaLlA/jYxBNFBFSGVv16R0K/1dCp85mBz0ilOmXGcoLWT+Kyyln+4rQ2hmGJRhrH bv5Ewe9N39iu9rXuWles426xbACrJIm+hKmpvxjfz98jEFNqk8OC/O8LKEMZB8mIyMNTI+LLV FLdW2w7higQPFlJmE8wqN3OXZO66Rrdxt/9My+S66TVrusgUFPGX9IIkqic1pWjo/J/bHtOBn Ew8FOpodGjKCGQAZywnVLq0pvAm/Z3w4WihOSyqpFSq9DEb/+AqFsNqwQ7+IN9VreF3d53pz+ ZhuTSuC+n94C85h+rdOO/4bG60NSVNTmfYxg4lU3Moboke/Su06P92vm/61GkQtY4Y21GtF62 PZuJyjFo+x7C3pYEjnMQK1WXIQl+YVjtbW0TyWe1gvqAwfoYpA+V4l0lvjHf9GycU5M/oKe58 vN5mBS0ptnwdbXseVfKraZBMpn17j41foDdaMv/QXpAMkOl1QG1ufYd3kbsk+pR+wqA11KeEs KV3lLuHIPZ/GE+eukarQq8kJXw5/Rn/NtlCCTDyvYCsmerLYkhjxB+SO3M6DRO9kHZSp92D9E xugwL1oMrpTwIxSoXhx1KrrnAvt0RYfqDwO/g7c0xwHLxovyf6b/w8eHq3dKBmOwURiD2qAhe jRBEESK Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Summary of WG decisions Re: Feedback on draft-ietf-urnbis-semantics-clarif-03 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 13:39:59 -0000 On 2016-05-31 15:31, Andrew Newton wrote: > Let me address a couple of points with one message: > > On Sat, May 28, 2016 at 4:41 PM, Sean Leonard wrote: >> On 5/17/2016 9:10 AM, Julian Reschke wrote: >>> So, once again, if we say "updates: 3986" we need to be able to explain >>> *precisely* which parts of RFC 3986 are affected (and why, fwiw). > > Just for my sanity, I reread > draft-ietf-urnbis-semantics-clarif-03.txt. It seems to me that this > draft does exactly the thing you have requested. > ... It might *intend* to do it, but (a) it's very unclear what the actual change is, (b) whether it is needed, and (c) whether that it tries to change actually is consistent with what the URN spec attempts to do. Best regards, Julian From nobody Tue May 31 07:04:21 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BFF12D537 for ; Tue, 31 May 2016 07:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 s_Xl2af8SeFw for ; Tue, 31 May 2016 07:04:15 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 7F9DE12D513 for ; Tue, 31 May 2016 07:04:15 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 43AF750AB4 for ; Tue, 31 May 2016 10:04:13 -0400 (EDT) To: "urn@ietf.org" From: Sean Leonard Message-ID: <4ebb152c-362a-beed-42be-1062dbf6a6e7@seantek.com> Date: Tue, 31 May 2016 07:03:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] draft-ietf-urnbis-semantics-clarif-03 typos X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 14:04:20 -0000 Typos in draft-ietf-urnbis-semantics-clarif-03: Section 1: requiremnts -> requirements Section 4: RFC 3896 -> RFC 3986. Sean From nobody Tue May 31 07:33:55 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58B512D7C5 for ; Tue, 31 May 2016 07:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 RG5Kp4_sEkga for ; Tue, 31 May 2016 07:33:50 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 70B8C12D7BF for ; Tue, 31 May 2016 07:33:50 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7194C50A85 for ; Tue, 31 May 2016 10:33:49 -0400 (EDT) To: "urn@ietf.org" From: Sean Leonard Message-ID: <2c9b4833-2893-f40a-de06-0f55c8ff468e@seantek.com> Date: Tue, 31 May 2016 07:32:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] Thread about urnbis-semantics-clarif-03 in the context of updating 3986 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 14:33:53 -0000 This is a thread about urnbis-semantics-clarif-03 in the context of updating RFC 3986, as requested. draft-ietf-urnbis-semantics-clarif-03 originally started out as (John's) polemic against using the URI framework ("syntax and high-level semantics of URLs" -- see draft-ietf-urnbis-urns-are-not-uris-00 Section 1) for URNs. That draft has a Section 3, which states: This specification removes URNs from the scope ofRFC 3896 . It makes no changes for URI types that remain within that scope. ** That verbal formulation (including the typo...) has survived through the drafts into Section 4 of draft-ietf-urnbis-semantics-clarif-03. Other stuff that purports to get updated: stuff about queries; stuff about fragments; and...that's about it. Oh, it also says stuff about how RFC 3401 and RFC 2483 apply but don't apply and we aren't talking about them. ****** Overall, the problems that need to be addressed are: draft-ietf-urnbis-semantics-clarif-03 doesn't actually *do anything*. I view it as a lot of hot air...either that hot air gets into 2141bis, or blow it away. I see nothing implementable here in Internet software or protocols. clarif-03 purports to "update 3986" but it doesn't really update 3986. Actually what it's doing is it's passive-aggressively declaring that URNs (i.e., 2141bis) are adopting some of RFC 3986 but not the whole thing, without really understanding what RFC 3986 actually says. That is an update to 2141bis, not to RFC 3986. If this WG really wants to say that, then 2141bis should simply say "a generic URI processor can parse URNs syntactically as urn: URI schemes". Specific paragraph in clarif-03: This document updatesRFC 3986 to make the distinction between syntax and semantics clear for URNs and to isolate URNs from presumed URI semantic requiremnts. It is important to note that some readers of RFC 3986 are convinced that the separation is clear in that specification and therefore that no changes to that document are needed. For them, this specification is only a confirming clarification. (again, a typo) The two key issues are that clarif-03 doesn't do either of the critical things that it purports to do: "This document updates RFC 3986 to make the distinction between syntax and semantics clear for URNs" ...actually it doesn't really clarify any distinction between syntax and semantics. "isolate URNs from presumed URI semantic requirements" The keyword here is "presumed". If you read RFC 3986, you basically see that there are very few presumed semantic requirements. Those requirements should not be presumed--they need to be spelled out, if you're going to change them. Julian just re-posted his April 27 message, with quotations from the specs. As pointed out, URIs don't have semantic requirements in the ways that clarif-03 worries about. This is focusing on the query and fragment productions. Specifically, RFC 3986 says: "If no such representation [a content, including a media type] exists, then the semantics of the fragment are considered unknown and are effectively unconstrained. Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications." Okay...that is true...but obviously the absolute-URI (excluding the fragment) defines what the fragment is doing, because the absolute-URI defines the primary resource and directly influences the retrievable representations. If I say: http://foo.com/bar#baz ldap://foo.com/bar#baz data:text/plain,bar#baz Obviously, #baz means something really different in these cases because http, ldap, and data are going to return very different primary representations (if they are even capable of returning anything at all). There are very large classes of URIs that are not intended for retrieving Internet content (data with a media type and parameters). The absolute-URI (including the scheme and path) DEFINES (not "redefines") the primary resource, the primary resource defines the scope and quality of representations, and therefore, secondary resources. So...when 2141bis says something about fragment, /including saying nothing at all/, it is not in conflict with RFC 3986. Sean From nobody Tue May 31 08:48:36 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2F612D0C8 for ; Tue, 31 May 2016 08:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 uxvjQjq_98Fa for ; Tue, 31 May 2016 08:48:33 -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 9A0D212B05C for ; Tue, 31 May 2016 08:48:33 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1b7lu8-0009yw-T6; Tue, 31 May 2016 11:48:28 -0400 Date: Tue, 31 May 2016 11:48:23 -0400 From: John C Klensin To: Julian Reschke , Andrew Newton Message-ID: <49F8F126DD3A54640049E2F9@JcK-HP8200.jck.com> In-Reply-To: References: <231532ef-e195-b73d-4a34-eb445bdd1900@gmx.de> <1F5D414703BF94503600A5E3@JcK-HP8200.jck.com> <9dd1f7f1-843e-822b-a352-8b51d6f4192c@gmx.de> <0626757a-430e-4c25-07e0-efd04e92c377@seantek.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.10 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] Summary of WG decisions Re: Feedback on draft-ietf-urnbis-semantics-clarif-03 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 15:48:35 -0000 --On Tuesday, May 31, 2016 15:39 +0200 Julian Reschke wrote: > On 2016-05-31 15:31, Andrew Newton wrote: >... >> Just for my sanity, I reread >> draft-ietf-urnbis-semantics-clarif-03.txt. It seems to me >> that this draft does exactly the thing you have requested. >> ... > > It might *intend* to do it, but (a) it's very unclear what the > actual change is, (b) whether it is needed, and (c) whether > that it tries to change actually is consistent with what the > URN spec attempts to do. Julian (and Andrew), Just so you know (and to repeat what I've at least hinted at), I've been looking at draft-ietf-urnbis-semantics-clarif since Julian's first posting on the issue to see if I could find thing that could reasonably be improved. I've found several [1] and put new text into a working draft for -04 but have not posted it pending input and direction from the co-Chairs [2]. I don't believe those changes will satisfy Julian's concerns. The reasons are connected to why I've been looking for instructions from the co-chairs and summarized in Andy's note. >From my point of view, this document updates 3986 _for URNs only_, it is not an attempt at a general update (that should have been quite clear from the first sentence of Section 4; -04 will be even more clear on the subject). In principle, we could do a paragraph by paragraph review of what portions of 3986 are affected by that, but it would be a lot of work, it would make this document longer and more complicated, and I don't believe that anyone would read it except for the purpose of finding things to quibble and pick nits about. I see that as potentially a huge source of further delay and not particularly useful; if you disagree, please work with Andy to convince the WG. Similar comments apply to "whether it is needed". Before the decisions that led, first to the "URNs are not URIs" proposal and then to this document, the WG spent seemingly-endless months bogged down in discussions about whether a particular mechanism or usage was consistent with, or permitted by, 3986. For each case, some people argued that it was, others argued with equal passion, that it was not. We were not converging on subjects that were arguably outside the WG's scope, such as whether 3986 needed work or was clear enough. While there are technical arguments having to do with differing layering abstractions that I believe justify the separation, my impression of the WG's conclusion was that we simply needed to separate ourselves from those arguments if we were to make progress. So, if the question is "whether this is needed to make URN work proceed" the answer is that the WG decided "yes" and Section 2 of draft-ietf-urnbis-semantics-clarif (at least -02 and later) is intended to say that. If the question were, instead, "can the WG prove to the satisfaction of all readers and interpreters of 3986 than it is impossible to develop a functional URN model that meets the needs of the communities the WG has identified without some separation from 3986", that answer to that question is probably "no", or at least "no within the level of energy that exists", but I hope the WG doesn't need to do that. best, john p.s. Sean, the two typos that you spotted were repaired in the working draft for -04 in February or earlier. I don't remember whether someone pointed them out to me (on or off list) or whether I just spotted them and fixed them. Unless directed otherwise by WG Chairs, I generally don't post new drafts just to fix obviously typographic and other trivial editorial errors. But thanks for spotting them again and having me go back and confirm the repairs. [1] Not a surprise. I don't think I've ever looked, months or years later, at a document I had finished or put aside for a while and not found areas of possible improvement. [2] I believe I did say on-list that I was going to wait. From nobody Tue May 31 10:11:26 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4905A12D63A for ; Tue, 31 May 2016 10:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 pPCxqxw51OHu for ; Tue, 31 May 2016 10:11:18 -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 7A6B812D520 for ; Tue, 31 May 2016 10:11:18 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1b7nCE-000AW1-Kh; Tue, 31 May 2016 13:11:14 -0400 Date: Tue, 31 May 2016 13:11:09 -0400 From: John C Klensin To: Sean Leonard Message-ID: In-Reply-To: <2c9b4833-2893-f40a-de06-0f55c8ff468e@seantek.com> References: <2c9b4833-2893-f40a-de06-0f55c8ff468e@seantek.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.10 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] Thread about urnbis-semantics-clarif-03 in the context of updating 3986 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 17:11:25 -0000 Just one reminder on this subject... The WG has always (or more or less always) considered urnbis-semantics-clarif as primarily a working document for its own convenience in developing 2141bis and anything else relevant. We've agreed (I think several times) to defer the question of whether to actually publish it as an RFC until we were winding up our work (that might be now -- now my call). If the WG concludes that it is no longer needed (or, in retrospect, never was), I'd be the first one to applaud and take it out of my queue. That "maybe we will publish and maybe we won't" approach has almost certainly resulted in a more casual attitude toward precise text than would have been the case for a draft that was clearly going to be standards-track or RFC-publication-track. The assumption, perhaps unrealistic or wrong in retrospect, has been that, if the WG decided to publish it or its offspring as an RFC, we would go over it and clean details up at that point. The approach also dictated at least two other sets of decisions that have been raised (again) recently: (1) The reference to it from 2141bis is Informative, not Normative. If 2141bis is not constructed well enough to justify that distinction, it is a problem with it (2141bis) and suggestions about text are welcome. (2) There is some, perhaps a good deal, of text in urnbis-semantics-clarif that is intended to convey the general sense that the WG isn't sure (and doesn't have clear consensus) whether there is are issues between 2141bis (etc.?) and 3986 or not; if there are conflicts, read this document and 2141bis as authoritative for URNs and not 3986; if there are not, you can ignore this document. Section 2, which, as Sean points out, was carried forward largely unchanged from the "URNs are not URIs" document (see below), attempts to cover that point. In rereading it, it occurs to me that an entirely different approach could be taken, which would be to say just that, i.e., to start from "Some people in the community think there is a conflict between these URN specs and 3986. Others disagree. If readers find apparent conflicts, especially in the scheme-specific syntax for URNs, then 2141bis should be treated as authoritative for URNs independent of what they believe 3986 says." Such a statement, I'd hope with better wording, could easily be incorporated into 2141bis and this whole "semantics versus syntax" discussion and all of the baggage associated with it discarded. Or, if someone thinks a separate document is needed, replacing urnbis-semantics-clarif, as far as I'm concerned, please have at it. Finally, not because I'm particularly attached to either document, but because it might be important, one clarification: the "URNs are not URIs" proposal came about after some fairly extensive discussions within the WG about both the apparent substantive issues involved and about how to change the WG discussion focus back to URNs and away from seemingly-interminable discussions about the relationship between URNs and whatever people thought 3986 said, a set of discussions that also included examination of places where 3986 appeared to change or constrain 2141 and/or 3406 without explicitly discussing or updating those documents, leaving all three in an ambiguous state. I no longer remember how much of those discussions were on the mailing list, in formal meetings, and in sequences of small group conversations, but note that draft-ietf-urnbis-urns-are-not-uris really was a WG document for which I drew the short straw to assemble and edit -- fwiw, the original idea was not mine although I think the syntax split one might have been. At a subsequent meeting, the WG decided on the narrower approach that draft-ietf-urnbis-semantics-clarif attempts to capture. I drew that short straw too and, being lazy (and, IIR, on instructions from that meeting), reused as much text as I thought feasible. I hope that the "URNs are not URIs" approach is part of our past and we can concentrate on moving forward, but it was a WG document, did have some level of consensus (although obviously not enough) and I don't think dismissing it as "John's polemic" is at all helpful. That earlier approach could become relevant again in one particular situation that I hope won't arise. The in-meeting conclusion and subsequent list discussion that discarded "URNs are not URIs" in favor of the syntax-semantics separation was, I believe, ultimately tentative and experimental wrt the question of whether the latter separation could be made to work. If the WG were to conclude that a distinction is needed and the syntax-semantics separation is not feasible in practice, unless we simply decided to abandon URNs, the result would presumably be a return to the "URNs are not URIs" approach. That approach would require updating 3896 as well, but only to the extent of removing the example at the end of Section 1.1.2, modifying the example in Section 3, and modifying the discussion in 1.1.3 to remove the discussion of URNs and maybe non-locator names. One of the attractions of that updating relationship was that there was never any question of its documentary effect on 3986 (unlike the current discussion about the much finer distinction of the "semantics-clarif" approach). best, john From nobody Tue May 31 10:26:34 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6494212D0C2 for ; Tue, 31 May 2016 10:26:32 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hxr-us.20150623.gappssmtp.com 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 dHpWi2JaUgM9 for ; Tue, 31 May 2016 10:26:30 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 3947D12D869 for ; Tue, 31 May 2016 10:26:30 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id n129so117605046wmn.1 for ; Tue, 31 May 2016 10:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=r/Zty8zu7GSSi6Hgg4PgREG7NikmsK/RvNjRaYsAbX4=; b=lNXTJi+3VWcSRzqccr3kzHBBSs0M8fDU2V7oTKIJqd3uR1Nm9+KEsLMFaRZje7bq1s lK/7TCMOE5kL8COm4Qhi2nNbhnCsXDbMBFfYU9RBm+LIe45y7B1nuCO32PuLEBTyX2Nn zW4SATlvybHfn5pLdd9LB8HRYkKskOPR02yCtlu71qdKStQtbGgT8dE4eKBWhsrHpdPd FGx9eDaDGIVLL8a32o85Z6khynzvXFfnA5+N8NpFSDyrmV2wVMCYprZTNY1kdQ8h5HnQ qn5voh41ZGTvIOQWQREOfy0z32mIRm1CRlaYT439YdBdRJOP/vxCN6s3parawCxenEfl VFFQ== 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; bh=r/Zty8zu7GSSi6Hgg4PgREG7NikmsK/RvNjRaYsAbX4=; b=Gaprj8N+K9ifpxlgtypPtBWPmYkCQkHCeNA0zkyBBKceUxzUCXGVW07ED51XtwTZi2 tqsVhEl1hSoUX/Zvi7AK8A967G5vdXXr0G11pFkhJLxnv4v8WT/NrxrzDGUIztuxblmx c3/yJ1ZPEUQlCXSgrhk898LeCutsFjh9qAeCjS4xMV3qSkxjqtmgR/Ax9NvTQ0lsJCbO +UI4yUUATV7y6JIOaB0CpYSrzuPay8IBe9Gb4V4F5m30tli6GLcYI28HacWzqZGd4q8o xRQCPPJRew9zTgXkLDfDhAqOCM+KBHY4nUoEFTu2KRCLDr+yn5BVSj57HLe73cDO8x2Q V76w== X-Gm-Message-State: ALyK8tKWbgLtv5NZExnS4nUZFRvCYvvl+We3pX2Drm7uSfvFId0WiEiPj2Vuahu3e/9NM3WzSjdsAv4LdIFYQw== MIME-Version: 1.0 X-Received: by 10.194.192.10 with SMTP id hc10mr32596870wjc.71.1464715588615; Tue, 31 May 2016 10:26:28 -0700 (PDT) Received: by 10.194.153.39 with HTTP; Tue, 31 May 2016 10:26:28 -0700 (PDT) X-Originating-IP: [192.149.252.11] In-Reply-To: <49F8F126DD3A54640049E2F9@JcK-HP8200.jck.com> References: <231532ef-e195-b73d-4a34-eb445bdd1900@gmx.de> <1F5D414703BF94503600A5E3@JcK-HP8200.jck.com> <9dd1f7f1-843e-822b-a352-8b51d6f4192c@gmx.de> <0626757a-430e-4c25-07e0-efd04e92c377@seantek.com> <49F8F126DD3A54640049E2F9@JcK-HP8200.jck.com> Date: Tue, 31 May 2016 19:26:28 +0200 Message-ID: From: Andrew Newton To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Julian Reschke , "urn@ietf.org" Subject: Re: [urn] Summary of WG decisions Re: Feedback on draft-ietf-urnbis-semantics-clarif-03 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 17:26:32 -0000 On Tue, May 31, 2016 at 5:48 PM, John C Klensin wrote: > > > Just so you know (and to repeat what I've at least hinted at), > I've been looking at draft-ietf-urnbis-semantics-clarif since > Julian's first posting on the issue to see if I could find thing > that could reasonably be improved. I've found several [1] and > put new text into a working draft for -04 but have not posted it > pending input and direction from the co-Chairs [2]. > Yes, please publish it. > I don't believe those changes will satisfy Julian's concerns. > The reasons are connected to why I've been looking for > instructions from the co-chairs and summarized in Andy's note. > >From my point of view, this document updates 3986 _for URNs > only_, it is not an attempt at a general update (that should > have been quite clear from the first sentence of Section 4; -04 > will be even more clear on the subject). In principle, we could > do a paragraph by paragraph review of what portions of 3986 are > affected by that, but it would be a lot of work, it would make > this document longer and more complicated, and I don't believe > that anyone would read it except for the purpose of finding > things to quibble and pick nits about. I see that as > potentially a huge source of further delay and not particularly > useful; if you disagree, please work with Andy to convince the > WG. Agreed. > > Similar comments apply to "whether it is needed". Before the > decisions that led, first to the "URNs are not URIs" proposal > and then to this document, the WG spent seemingly-endless months > bogged down in discussions about whether a particular mechanism > or usage was consistent with, or permitted by, 3986. For each > case, some people argued that it was, others argued with equal > passion, that it was not. We were not converging on subjects > that were arguably outside the WG's scope, such as whether 3986 > needed work or was clear enough. While there are technical > arguments having to do with differing layering abstractions that > I believe justify the separation, my impression of the WG's > conclusion was that we simply needed to separate ourselves from > those arguments if we were to make progress. So, if the > question is "whether this is needed to make URN work proceed" > the answer is that the WG decided "yes" and Section 2 of > draft-ietf-urnbis-semantics-clarif (at least -02 and later) is > intended to say that. If the question were, instead, "can the > WG prove to the satisfaction of all readers and interpreters of > 3986 than it is impossible to develop a functional URN model > that meets the needs of the communities the WG has identified > without some separation from 3986", that answer to that question > is probably "no", or at least "no within the level of energy > that exists", but I hope the WG doesn't need to do that. > Again, agreed. -andy From nobody Tue May 31 10:48:17 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3638B12D560 for ; Tue, 31 May 2016 10:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 IZdlpbHnJFg1 for ; Tue, 31 May 2016 10:48:14 -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 86B2A12D553 for ; Tue, 31 May 2016 10:48:14 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1b7nly-000Ahr-VY; Tue, 31 May 2016 13:48:10 -0400 Date: Tue, 31 May 2016 13:48:05 -0400 From: John C Klensin To: Andrew Newton Message-ID: <998468579B1CEBE51923FCE5@JcK-HP8200.jck.com> In-Reply-To: References: <231532ef-e195-b73d-4a34-eb445bdd1900@gmx.de> <1F5D414703BF94503600A5E3@JcK-HP8200.jck.com> <9dd1f7f1-843e-822b-a352-8b51d6f4192c@gmx.de> <0626757a-430e-4c25-07e0-efd04e92c377@seantek.com> <49F8F126DD3A54640049E2F9@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.10 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: Julian Reschke , urn@ietf.org Subject: Re: [urn] Summary of WG decisions Re: Feedback on draft-ietf-urnbis-semantics-clarif-03 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 17:48:16 -0000 --On Tuesday, May 31, 2016 19:26 +0200 Andrew Newton wrote: > On Tue, May 31, 2016 at 5:48 PM, John C Klensin > wrote: >> >> >> Just so you know (and to repeat what I've at least hinted at), >> I've been looking at draft-ietf-urnbis-semantics-clarif since >> Julian's first posting on the issue to see if I could find >> thing that could reasonably be improved. I've found several >> [1] and put new text into a working draft for -04 but have >> not posted it pending input and direction from the co-Chairs >> [2]. >> > > Yes, please publish it. Ok. As I have warned in other contexts, this is a very bad week for me, starting later this afternoon. I'll try to find time to get it together and posted, but it might not be until the end of the weekend. thanks. john From nobody Tue May 31 11:02:11 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122CE12D1A8 for ; Tue, 31 May 2016 11:02:09 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hxr-us.20150623.gappssmtp.com 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 vvqxDAsVn-NH for ; Tue, 31 May 2016 11:02:07 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 6126212D18E for ; Tue, 31 May 2016 11:02:06 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id n129so118763404wmn.1 for ; Tue, 31 May 2016 11:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=c4a2fXebGWeoKVUEgPC0QDtpKS8OLgF48FEV05KipPU=; b=JCl8yUP4tNlhQnZYoqdjnM/XpF1xNuhjSdNK3aCJXxHRO2Wilr590dAijBq2FwEF1I lxM1HkpB/RScXPRw3cR4IE/jkRYNWk51kFxt2fV5zO5bLWQA8wjLsdXZPhpyQMZ3Adnu gYw1SWQL+2cdjobUWf/rwt+cBOTsY1HqD5ClPftXj5miLZPK2n1xgGCII7uWuw55x0II OywauasR1r1JzTk0WrPxSiocIxL+np//dEGwae6OzZBW30GKXu4d9rf3ypbClH09+qsb N4D/T9ZuON21ZHPJ+2XQlBs9VpyrkQZMD5JvlxEAa0HDuEhm91LwvlcvQb9aI56v8jza l3Ug== 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; bh=c4a2fXebGWeoKVUEgPC0QDtpKS8OLgF48FEV05KipPU=; b=HhHZjASkjnr1seKNkBo+ND8LK4yKPCmOsHalmt9DUOIftP4KYzFyx/pdEYQcn0VE4x OwMGraSlIeHpCLPvS7MNLQY6Ug58xdL5RFoM98SMOT7MyFPSHMD/2oBzpn2yFs/R6tdq FtMhY5NAztTGCKASKPXPG4ZsmiQ7tr+Y7D9QvHva7OkbpY6lTx6Ry2rhPbJGTY/sL2Hd jTJpv2yInPMGdGgZW82B64rzCAUXSf7Dp1SMa8zUBGO2fYT7Q4GMJae6HCx88oPyo+l7 ifSSW4d86cIgWy2ZNn+I3Goj94VKYX0gHjU732hpjKjI8D2BX4JI/1kYh2oAtSIKTIti 3zXA== X-Gm-Message-State: ALyK8tLW+bgY/oP+DE1051yauoi8Y+4EUaNjSB6ADZS5hAjwcDqZuIzvqvBYDR1UtyZJQH5gIuUvKq9AwkoZQA== MIME-Version: 1.0 X-Received: by 10.194.141.144 with SMTP id ro16mr36271629wjb.40.1464717724744; Tue, 31 May 2016 11:02:04 -0700 (PDT) Received: by 10.194.153.39 with HTTP; Tue, 31 May 2016 11:02:04 -0700 (PDT) X-Originating-IP: [192.149.252.11] In-Reply-To: <2c9b4833-2893-f40a-de06-0f55c8ff468e@seantek.com> References: <2c9b4833-2893-f40a-de06-0f55c8ff468e@seantek.com> Date: Tue, 31 May 2016 20:02:04 +0200 Message-ID: From: Andrew Newton To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Thread about urnbis-semantics-clarif-03 in the context of updating 3986 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 18:02:09 -0000 On Tue, May 31, 2016 at 4:32 PM, Sean Leonard wrote: > This is a thread about urnbis-semantics-clarif-03 in the context of updating > RFC 3986, as requested. > > draft-ietf-urnbis-semantics-clarif-03 originally started out as (John's) > polemic against using the URI framework ("syntax and high-level semantics of > URLs" -- see draft-ietf-urnbis-urns-are-not-uris-00 Section 1) for URNs. > That draft has a Section 3, which states: The definition of "polemic" is: a strong verbal or written attack on someone or something. The key words being "strong" and "attack" which connote discourse not becoming of the IETF. I believe this is a mischaracterization of both John and his work. Let's try to avoid such words in the future. > That verbal formulation (including the typo...) has survived through the > drafts into Section 4 of draft-ietf-urnbis-semantics-clarif-03. > > Other stuff that purports to get updated: stuff about queries; stuff about > fragments; and...that's about it. Oh, it also says stuff about how RFC 3401 > and RFC 2483 apply but don't apply and we aren't talking about them. The references to 2483 and 3401 are in regard to scope of the changes and seem completely appropriate. > > ****** > > Overall, the problems that need to be addressed are: > > draft-ietf-urnbis-semantics-clarif-03 doesn't actually *do anything*. I view > it as a lot of hot air...either that hot air gets into 2141bis, or blow it > away. I see nothing implementable here in Internet software or protocols. "hot air"... again, let's dial it down. > Julian just re-posted his April 27 message, with quotations from the specs. > As pointed out, URIs don't have semantic requirements in the ways that > clarif-03 worries about. This is focusing on the query and fragment > productions. Specifically, RFC 3986 says: > > "If no such representation [a content, including a media type] exists, then > the semantics of the fragment are considered unknown and are effectively > unconstrained. Fragment identifier semantics are independent of the URI > scheme and thus cannot be redefined by scheme specifications." The entirety of that paragraph is: The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. The fragment's format and resolution is therefore dependent on the media type [RFC2046] of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. If no such representation exists, then the semantics of the fragment are considered unknown and are effectively unconstrained. Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications. As I recall, the issue was that fragments could not be defined by a URN namespace thus causing the basis for separation of syntax from semantics. -andy From nobody Tue May 31 12:22:09 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF6312D7E9 for ; Tue, 31 May 2016 12:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 ULSydwalPWfB for ; Tue, 31 May 2016 12:22:07 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 E686312D7EE for ; Tue, 31 May 2016 12:22:06 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BA5ED509B6; Tue, 31 May 2016 15:22:05 -0400 (EDT) To: Andrew Newton References: <2c9b4833-2893-f40a-de06-0f55c8ff468e@seantek.com> From: Sean Leonard Message-ID: <087583fc-0523-d28e-53ba-a864bc4a4c82@seantek.com> Date: Tue, 31 May 2016 12:20:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Thread about urnbis-semantics-clarif-03 in the context of updating 3986 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 19:22:08 -0000 On 5/31/2016 11:02 AM, Andrew Newton wrote: > On Tue, May 31, 2016 at 4:32 PM, Sean Leonard wr= ote: >> This is a thread about urnbis-semantics-clarif-03 in the context of up= dating >> RFC 3986, as requested. >> >> draft-ietf-urnbis-semantics-clarif-03 originally started out as (John'= s) >> polemic against using the URI framework ("syntax and high-level semant= ics of >> URLs" -- see draft-ietf-urnbis-urns-are-not-uris-00 Section 1) for URN= s. >> That draft has a Section 3, which states: > The definition of "polemic" is: a strong verbal or written attack on > someone or something. > The key words being "strong" and "attack" which connote discourse not > becoming of the IETF. I believe this is a mischaracterization of both > John and his work. Let's try to avoid such words in the future. John has been doing good work and the work is appreciated. When I wrote the term "polemic", it is because "Names are Not Locators=20 and URNs are Not URIs" (the title, and the document, see, e.g., section=20 1, draft-ietf-urnbis-urns-are-not-uris-00) *are* strong written attacks=20 on something: namely, on the seemingly antagonistic relationship between = URNs and URIs (specifically URN is attacking URI because it wants to=20 secede from the URI country and set up its own republic of URN). There=20 is nothing wrong in John's writing or in the characterization of it. Far = from it--we need more strong opinions so we can clearly say "okay, we're = going to go this way", or "no, we discussed it, we have decided we are=20 not going to go that way". > >> That verbal formulation (including the typo...) has survived through t= he >> drafts into Section 4 of draft-ietf-urnbis-semantics-clarif-03. >> >> Other stuff that purports to get updated: stuff about queries; stuff a= bout >> fragments; and...that's about it. Oh, it also says stuff about how RFC= 3401 >> and RFC 2483 apply but don't apply and we aren't talking about them. > The references to 2483 and 3401 are in regard to scope of the changes > and seem completely appropriate. > >> ****** >> >> Overall, the problems that need to be addressed are: >> >> draft-ietf-urnbis-semantics-clarif-03 doesn't actually *do anything*. = I view >> it as a lot of hot air...either that hot air gets into 2141bis, or blo= w it >> away. I see nothing implementable here in Internet software or protoco= ls. > "hot air"... again, let's dial it down. There is genuine frustration among implementers that this URN work has=20 taken too long and is far too nebulous. Polemics etc. are fine for=20 generating and stirring debate (the original urns-are-not-uris). But we=20 seem to be continuing to have debates without resolutions... What matters is that people write software that interoperates with other = software. There is no grand theory of URIs or what have you, apart from=20 the fact that two people write software a particular way that uses some=20 sequence of characters to do similar things. Whether urn:isbn:1234=20 identifies a book, pages in a book, some stream of bits, or abstract=20 notions of fair play and substantial justice, *does not matter*, as long = as we agree on them. URIs can do anything, or nothing, that we want them = to as software engineers. Ditto for URNs. Maybe this is a process issue. It's hard for me (and not to raise=20 others' hands, but I think Julian is raising this point too) to see how=20 RFC 3986 is getting updated, when RFC 3986 is not really getting=20 updated, you're just creating a urn: string that only "partially" adopts = RFC 3986 things. Maybe it's just better in rfc2141bis to say that URNs=20 are syntactically URIs (whatever verbal formulation you want), and where = they differ, to point out *in rfc2141bis* those specific differences. No = "Updates: RFC3986" necessary in the header. And hopefully, the need for=20 the clarif document will be obviated. Regards, Sean From nobody Tue May 31 12:22:56 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A603E12D7F1 for ; Tue, 31 May 2016 12:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 5I8_pq5tGOXe for ; Tue, 31 May 2016 12:22:53 -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 DD90C12D7E9 for ; Tue, 31 May 2016 12:22:52 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1b7pFa-000BFo-JA; Tue, 31 May 2016 15:22:50 -0400 Date: Tue, 31 May 2016 15:22:45 -0400 From: John C Klensin To: Andrew Newton , Sean Leonard Message-ID: In-Reply-To: References: <2c9b4833-2893-f40a-de06-0f55c8ff468e@seantek.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.10 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] Thread about urnbis-semantics-clarif-03 in the context of updating 3986 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 19:22:55 -0000 Andy, Thanks. Let me try to shed some additional light on part of this by posting some of the analysis I've been resisting... --On Tuesday, May 31, 2016 20:02 +0200 Andrew Newton wrote: Julian's quote from 3986... >> "If no such representation [a content, including a media >> type] exists, then the semantics of the fragment are >> considered unknown and are effectively unconstrained. >> Fragment identifier semantics are independent of the URI >> scheme and thus cannot be redefined by scheme specifications." > The entirety of that paragraph is: > > The semantics of a fragment identifier are defined by the > set of representations that might result from a retrieval > action on the primary resource. The fragment's format and > resolution is therefore dependent on the media type > [RFC2046] of a potentially retrieved representation, even > though such a retrieval is only performed if the URI is > dereferenced. If no such representation exists, then the > semantics of the fragment are considered unknown and are > effectively unconstrained. Fragment identifier semantics > are independent of the URI scheme and thus cannot be > redefined by scheme specifications. The first problem with the above is that, unless somehow knows which sentences are relevant and which ones are not, it can be read as self-contradictory, at least for things that are not classical URLs or similar to them. Sentence 2 ("The fragment's format...") says that the format and resolution of the fragment are dependent on the media type, even though..." If the paragraph stopped there, a reasonable person might conclude that fragments are invalid unless a retrieval is performed and the URI dereferenced (not even clear what that combination allows or prohibits, but let's skip that). Fortunately, the text then goes on to say "...unknown and effectively unconstrained", which is fine, except that, if "such representation" refers to the "retrieved representation" obtained when a URI is "dereferenced". That term is used in 1.2.2 as part of the definition of "URI 'resolution'" and then defined as the use of an access mechanism that is determined as part of "resolution". Skipping over that bit of circularity, we have more or less the "3986 does not constrain URN fragments at all, so anything 2141bis says would be true or not-true" (not quite a fair characterization, but bear with me). However, then one gets to the next sentence, which has been quoted to the WG several times (and, IIR, had a large influence on the present state of 2141bis). It says that fragment semantics are scheme-independent and schemes cannot redefine them. That would seem to contradict "unknown and ... effectively unconstrained". Now the good news is that, as Julian has pointed out, the web community knows what that means and (at least for URLs) has a consistent understanding of it, consistent enough to ignore the issues that some of us who are relative outsiders consider convoluted and possibly self-referential or recursively referential. The bad news is that, for non-locator URIs, the WG's choices were to simply ignore 3986 language that seemed unclear or inappropriate, to devise a trick that would permit work on URNs to go forward without having to try to completely analyze and fix 3968, or to try to do that analysis and repair job. The latter was clearly out of scope for the WG (and, for the WG, impossible in practice). Early discussions made it clear that the WG would not be allowed to get away with the former. That left us with the second option, which we've tried to apply in a couple of different ways and which, as I suggested earlier, if far more about separating the URN discussions from debates about what 3986 means for non-locators than it is about fixing or updating 3986. If the IETF had a significantly broader vocabulary than "updates", we might well use it, but it doesn't. > As I recall, the issue was that fragments could not be defined > by a URN namespace thus causing the basis for separation of > syntax from semantics. Yes, but I would have said "it wasn't clear whether fragments could be defined by a URN namespace or not and we needed to avoid spending further time on that debate" rather than your more definitive "could not be defined". The latter would be false if one ignored the last sentence quoted above and focused on "unknown and ... effectively unconstrained". The other qualification is that fragments were not believed to be the only case -- we were concerned about issues with queries (with or without their division into q- and r-components) and the possibility of issues that no one had yet identified with, e.g., statements about resolution and resources, that might come back and bite us later. Taking a really narrow view rather than the over-broad "syntax, no semantics" and trying to identify and make exceptions to the specific language that was problematic to URNs would have required an extensive search and analysis for which I believe there was general WG agreement was unneeded, undesirable, and ultimately out of scope. I hope we can avoid being dragged backwards into the analysis we explicitly decided to avoid and had hoped we could avoid the partial analysis of fragments, resolution, access methods, and dereferencing above. best, john