From nobody Fri Dec 2 09:34:42 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 00EDD1295B7 for ; Fri, 2 Dec 2016 09:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-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 S1qEwaCMLCaM for ; Fri, 2 Dec 2016 09:34:38 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6812D128B38 for ; Fri, 2 Dec 2016 09:34:38 -0800 (PST) Received: from aither.local (unknown [98.245.40.52]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 29F0040327; Fri, 2 Dec 2016 10:35:33 -0700 (MST) To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , John C Klensin , urn@ietf.org References: <9CC33BE498E6996637FB5091@JcK-HP8200> From: Peter Saint-Andre Message-ID: Date: Fri, 2 Dec 2016 10:34:34 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] FWD: Last Call: (Advertising Digital Identification (Ad-ID) URN Namespace Definition) to Informational RFC 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, 02 Dec 2016 17:34:40 -0000 On 11/26/16 11:00 PM, Martin J. Dürst wrote: > Hello John, others, > > On 2016/11/24 18:01, John C Klensin wrote: >> URNBIS WG: FYI. This is worth looking at, and possibly >> commenting on, with regard to not only its content and >> definition quality but also to whether the new registration >> model would sufficiently identify and deal with any issues. >> >> In particular, >> >> (1) The new registration procedure would turn this over to >> Expert Review, largely eliminating the possibility that someone >> in the community who accidentally knows about and understands >> the subject matter would look at and review it. On the other >> hand, Expert Review can permit more intensive interaction and >> negotiating with the authors of a registration request and/or >> template than is normally part of the "throw it over the wall" >> character of IETF Last Call and approval. Is that the tradeoff >> we want? Would be worth the trouble to add an announcement to >> the IETF list and window for comments to the expert to the >> procedure (assuming the IESG would let us)? > > I think if this is the scenario we're concerned about, then submission > to an urn-related list (the easiest would be this list) when applying > for expert review, and conducting the expert review (mostly) on that > list, would be better than further cluttering the IETF list. A pointer on the IETF list seems OK, but I don't think it would add much value. Peter From nobody Fri Dec 2 11:17: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 D3208128B38 for ; Fri, 2 Dec 2016 11:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-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 jdOfqhn0UTOl for ; Fri, 2 Dec 2016 11:17:23 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BEA731295FC for ; Fri, 2 Dec 2016 11:17:23 -0800 (PST) Received: from aither.local (unknown [98.245.40.52]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DDFFE40390; Fri, 2 Dec 2016 12:18:19 -0700 (MST) To: "Henry S. Thompson" References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> From: Peter Saint-Andre Message-ID: <82f1c933-44ad-bc45-c0bd-8a1bef3b5afe@stpeter.im> Date: Fri, 2 Dec 2016 12:17:19 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Terminology issue: 'URL' 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, 02 Dec 2016 19:17:26 -0000 On 11/17/16 8:31 AM, Henry S. Thompson wrote: > TL;DR: Replace 'resolve to a URL' with 'resolve to a Locator' > throughout I have no deep objections to this. See below on a few points. > The current draft (correcly, IMO) defines 'URN' as "A name that is a > member of a URN namespace", that is, a name of the form urn:nid:... > > It doesn't list 'URL' as a term, but does say, towards the end of > section 1.2 *Terminology* > > this document uses the term Uniform Resource Locator (URL), rather > than the generic term Uniform Resource Identifier (URI), to refer to > locators; see also Section 1.1.3 of [RFC3986]. > > I think this either partakes of, or at least encourages, a confusion > between properties of URI schemes and properties of individual URIs, > thereby missing the key point of the referenced section of 3986: > > An individual scheme does not have to be classified as being just > one of "name" or "locator". Instances of URIs from any given scheme > may have the characteristics of names or locators or both... [1] > > That is, although many http: URIs are locators, some are names (and > some are both), and although all urn: URIs are names, some may be > locators as well. > > A URI is a locator if it can be dereferenced, if, for example "[there > are] services related to the identified resource, such as > ... delivering a document object from a convenient source" [2]. > That's not a property of the URI as such, but of its context of use > and the services available therefrom. As that quote indicates, some > URNs may have that property in some circumstances. > > On the other hand, just because a resolution service provides you with > an http: URI when invoked on a URN does not mean you are now on your > way to a document object, because that http: URI may itself be a name > and not a locator. > > So, I'd suggest that you add a new term to the term list in section > 1.2, as follows: > > Locator: A retrieval-enabled URI > > and use that term in most of the places where 'URL' is currently used. RFC 3986 §1.1.3 says: The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location"). And §1.2.2 says: When URIs are used within information retrieval systems to identify sources of information, the most common form of URI dereference is "retrieval": making use of a URI in order to retrieve a representation of its associated resource. I'm wondering if we want to use slightly more general terminology than your proposal of "a retrieval-enabled URI", because perhaps "access" is the more general term (cf. also in §1.2.2 "URI 'resolution' is the process of determining an access mechanism"). Also, do we want to define locators in terms of URIs, given that we don't define names in terms of URIs or URNs? Perhaps: Locator: an identifier that provides a means a locating a resource > The penultimate paragraph of section 1.2 would then need to read > something along these lines: > > This document uses the terms "resolution" and "resolver" in roughly > the sense in which they were used in the original discussion of > architectural principles for URNs [RFC2276], i.e., "resolution" is > the act of supplying services related to the identified resource, > such as translating the persistent URN into one or more current > Locators for the resource, delivering metadata about the resource > in an appropriate format, or even delivering a document object from > a convenient source without requiring further intermediaries. At > the time of this writing, resolution services are described in > [RFC2483]. > > Section 1.1.3 of [RFC3986] helpfully observes that "A URI can be > ... classified as a locator, a name, or both" and goes on to define > locators as URIs which "provide a means of locating the resource > [which they identify] by describing its primary access mechanism > (e.g., its network 'location')". This is what we mean by > 'retrieval-enabled' above, and we use the term 'Locator' to refer > to the class of individual URIs which have this property. Something along those lines, yet. > A few places where 'URL' is effectively used as shorthand for > "non-urn-scheme-URI' will require some more explicit rewriting, e.g. > > The URN r-component has no syntactic counterpart in URLs > > --> > > The URN r-component has no syntactic counterpart in any other URI > scheme that we are aware of Yes. > The overall point here is that RFCs are meant for the entire > community, and it's at best misleading for an RFC to redefine a widely > used term to have a meaning other than the one already in wide (and > documented) use. I do of course understand that there exists a > sub-community within which this distinct meaning is understood and > intended, but this spec can and should reach out more widely. So note > that I'm _not_ proposing that the spec should use 'URL' as defined in > 3986, but rather use 'URN' to mean urn:nid:..., as it does already, to > use 'URI' as the generic, and _not to use 'URL' at all_. I do agree that "locator" is better here, for sure. Peter From nobody Fri Dec 2 11:20:13 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 49BC11296DB for ; Fri, 2 Dec 2016 11:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-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 vjfyQAOZCU0v for ; Fri, 2 Dec 2016 11:20:11 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF13128B38 for ; Fri, 2 Dec 2016 11:20:11 -0800 (PST) Received: from aither.local (unknown [98.245.40.52]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 94F5A40390; Fri, 2 Dec 2016 12:21:07 -0700 (MST) To: "Henry S. Thompson" References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> <82f1c933-44ad-bc45-c0bd-8a1bef3b5afe@stpeter.im> From: Peter Saint-Andre Message-ID: Date: Fri, 2 Dec 2016 12:20:08 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <82f1c933-44ad-bc45-c0bd-8a1bef3b5afe@stpeter.im> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Terminology issue: 'URL' 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, 02 Dec 2016 19:20:12 -0000 On 12/2/16 12:17 PM, Peter Saint-Andre wrote: > Locator: an identifier that provides a means a locating a resource Sorry, I meant... Locator: an identifier that provides a means of accessing a resource My apologies for trying to do two things at once here... Peter From nobody Sat Dec 3 10:32: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 DD5271299A3 for ; Sat, 3 Dec 2016 10:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] 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 K4qJcQw0XF-R for ; Sat, 3 Dec 2016 10:32:02 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06DF51295A2 for ; Sat, 3 Dec 2016 10:32:01 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cDF6J-000D5z-TW; Sat, 03 Dec 2016 13:31:56 -0500 Date: Sat, 03 Dec 2016 13:31:50 -0500 From: John C Klensin To: Peter Saint-Andre , "Henry S. Thompson" Message-ID: In-Reply-To: <82f1c933-44ad-bc45-c0bd-8a1bef3b5afe@stpeter.im> References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> <82f1c933-44ad-bc45-c0bd-8a1bef3b5afe@stpeter.im> 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: Cc: urn@ietf.org Subject: Re: [urn] Terminology issue: 'URL' 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, 03 Dec 2016 18:32:04 -0000 Without thinking about it a lot, I think I am ok with these changes and think they probably improve things. However, it is worth keeping in mind that RFC 3986 is not completely clear about some of the distinctions we are now trying to make (even if a number of people read it the same way) and that at least one of its authors has a very negative attitude toward URNs. Especially since I think we have general agreement that this WG should not try to update or otherwise formally clarify 3986, I hope that future changes along these lines can be explicitly justified in terms of their importance to finishing our URN specs. john --On Friday, December 02, 2016 12:17 -0700 Peter Saint-Andre wrote: > On 11/17/16 8:31 AM, Henry S. Thompson wrote: >> TL;DR: Replace 'resolve to a URL' with 'resolve to a Locator' >> throughout >=20 > I have no deep objections to this. See below on a few points. >=20 >> The current draft (correcly, IMO) defines 'URN' as "A name >> that is a member of a URN namespace", that is, a name of the >> form urn:nid:... >>=20 >> It doesn't list 'URL' as a term, but does say, towards the >> end of section 1.2 *Terminology* >>=20 >> this document uses the term Uniform Resource Locator (URL), >> rather than the generic term Uniform Resource Identifier >> (URI), to refer to locators; see also Section 1.1.3 of >> [RFC3986]. >>=20 >> I think this either partakes of, or at least encourages, a >> confusion between properties of URI schemes and properties of >> individual URIs, thereby missing the key point of the >> referenced section of 3986: >>=20 >> An individual scheme does not have to be classified as >> being just one of "name" or "locator". Instances of URIs >> from any given scheme may have the characteristics of names >> or locators or both... [1] >>=20 >> That is, although many http: URIs are locators, some are >> names (and some are both), and although all urn: URIs are >> names, some may be locators as well. >>=20 >> A URI is a locator if it can be dereferenced, if, for example >> "[there are] services related to the identified resource, >> such as ... delivering a document object from a convenient >> source" [2]. That's not a property of the URI as such, but of >> its context of use and the services available therefrom. As >> that quote indicates, some URNs may have that property in >> some circumstances. >>=20 >> On the other hand, just because a resolution service provides >> you with an http: URI when invoked on a URN does not mean you >> are now on your way to a document object, because that http: >> URI may itself be a name and not a locator. >>=20 >> So, I'd suggest that you add a new term to the term list in >> section 1.2, as follows: >>=20 >> Locator: A retrieval-enabled URI >>=20 >> and use that term in most of the places where 'URL' is >> currently used. >=20 > RFC 3986 =C2=A71.1.3 says: >=20 > The > term "Uniform Resource Locator" (URL) refers to the subset > of URIs > that, in addition to identifying a resource, provide a > means of > locating the resource by describing its primary access > mechanism > (e.g., its network "location"). >=20 > And =C2=A71.2.2 says: >=20 > When URIs are used within information retrieval systems to > identify > sources of information, the most common form of URI > dereference is > "retrieval": making use of a URI in order to retrieve a > representation of its associated resource. >=20 > I'm wondering if we want to use slightly more general > terminology than your proposal of "a retrieval-enabled URI", > because perhaps "access" is the more general term (cf. also in > =C2=A71.2.2 "URI 'resolution' is the process of determining an > access mechanism"). >=20 > Also, do we want to define locators in terms of URIs, given > that we don't define names in terms of URIs or URNs? >=20 > Perhaps: >=20 > Locator: an identifier that provides a means a locating a > resource >=20 >> The penultimate paragraph of section 1.2 would then need to >> read something along these lines: >>=20 >> This document uses the terms "resolution" and "resolver" >> in roughly the sense in which they were used in the >> original discussion of architectural principles for URNs >> [RFC2276], i.e., "resolution" is the act of supplying >> services related to the identified resource, such as >> translating the persistent URN into one or more current >> Locators for the resource, delivering metadata about the >> resource in an appropriate format, or even delivering a >> document object from a convenient source without requiring >> further intermediaries. At the time of this writing, >> resolution services are described in [RFC2483]. >>=20 >> Section 1.1.3 of [RFC3986] helpfully observes that "A URI >> can be ... classified as a locator, a name, or both" and >> goes on to define locators as URIs which "provide a means >> of locating the resource [which they identify] by >> describing its primary access mechanism (e.g., its network >> 'location')". This is what we mean by 'retrieval-enabled' >> above, and we use the term 'Locator' to refer to the class >> of individual URIs which have this property. >=20 > Something along those lines, yet. >=20 >> A few places where 'URL' is effectively used as shorthand for >> "non-urn-scheme-URI' will require some more explicit >> rewriting, e.g. >>=20 >> The URN r-component has no syntactic counterpart in URLs >>=20 >> --> >>=20 >> The URN r-component has no syntactic counterpart in any >> other URI scheme that we are aware of >=20 > Yes. >=20 >> The overall point here is that RFCs are meant for the entire >> community, and it's at best misleading for an RFC to redefine >> a widely used term to have a meaning other than the one >> already in wide (and documented) use. I do of course >> understand that there exists a sub-community within which >> this distinct meaning is understood and intended, but this >> spec can and should reach out more widely. So note that I'm >> _not_ proposing that the spec should use 'URL' as defined in >> 3986, but rather use 'URN' to mean urn:nid:..., as it does >> already, to use 'URI' as the generic, and _not to use 'URL' >> at all_. >=20 > I do agree that "locator" is better here, for sure. >=20 > Peter >=20 >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Sun Dec 4 06:07: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 4B8BF12950A for ; Sun, 4 Dec 2016 06:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.896, 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 6g_WvEvzRc5X for ; Sun, 4 Dec 2016 06:07:33 -0800 (PST) Received: from loire.is.ed.ac.uk (loire.is.ed.ac.uk [129.215.16.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFDD129507 for ; Sun, 4 Dec 2016 06:07:32 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by loire.is.ed.ac.uk (8.14.7/8.14.6) with ESMTP id uB4E7UHW029937; Sun, 4 Dec 2016 14:07:31 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id uB4E7UNl005845; Sun, 4 Dec 2016 14:07:30 GMT 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 uB4E7UFp015688; Sun, 4 Dec 2016 14:07:30 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id uB4E7TiN015686; Sun, 4 Dec 2016 14:07:29 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Peter Saint-Andre References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> <82f1c933-44ad-bc45-c0bd-8a1bef3b5afe@stpeter.im> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Sun, 04 Dec 2016 14:07:29 +0000 In-Reply-To: <82f1c933-44ad-bc45-c0bd-8a1bef3b5afe@stpeter.im> (Peter Saint-Andre's message of "Fri\, 2 Dec 2016 12\:17\:19 -0700") 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=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Edinburgh-Scanned: at loire.is.ed.ac.uk with MIMEDefang 2.78, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.78 on 129.215.16.10 Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Terminology issue: 'URL' 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, 04 Dec 2016 14:07:36 -0000 Peter Saint-Andre writes: > I'm wondering if we want to use slightly more general terminology than > your proposal of "a retrieval-enabled URI", because perhaps "access" > is the more general term (cf. also in =A71.2.2 "URI 'resolution' is the > process of determining an access mechanism"). OK. > Also, do we want to define locators in terms of URIs, given that we > don't define names in terms of URIs or URNs? > Perhaps: > > Locator: an identifier that provides a means [of accessing] a resource OK. Thanks, and yes, John, I do think this "contributes to finishing our URN specs", because it will I hope forestall another round of argument. ht --=20 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 s= pam] From nobody Mon Dec 5 22:59: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 F1F2E120727 for ; Mon, 5 Dec 2016 22:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-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 gCw6HdLdWE5p for ; Mon, 5 Dec 2016 22:59:42 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0F44612007C for ; Mon, 5 Dec 2016 22:59:41 -0800 (PST) Received: from aither.local (unknown [173.228.45.99]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8757E400F8; Tue, 6 Dec 2016 00:00:52 -0700 (MST) To: "Henry S. Thompson" References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> From: Peter Saint-Andre Message-ID: Date: Mon, 5 Dec 2016 22:59:38 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Terminology -- 'resource' and 'abstract designator' 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, 06 Dec 2016 06:59:44 -0000 Hi Henry, thanks for the continued reviews and feedback. Comments inline. On 11/17/16 5:22 AM, Henry S. Thompson wrote: > There are two parts to this > > External: the current use of these terms is incompatible with the > 3986 > > Internal: The definitions and uses of 'abstract designator' are > inconsistent > > TL;DR: > > 1) 3986 distinguishes between 'resource' and 'representation', and so > should we; > > 2) The term 'abstract designator' should be dropped. > > Part 1 -- 3986 incompatibility > > URNs are URIs, that is, Uniform Resource Identifiers. Every URI > identifies something, as the name implies, and 3986 uses the term > 'resource' as the cover term for _anything_ that is identified by a > URI. It explicitly places _no_ constraint on what a URI can identify. > In other words, anything can be a resource: real, imaginary, abstract, > concrete, individual, set (finite or infinite), ... > > The current draft does not define the term 'resource'. It often uses > it in ways which are consistent with 3986's definition, for example in > phrases such as "resource identifier" (lower case in original), > "identified resource", "The kinds of resources identified by URNs" and > "persistent identification of resources". This longer exposition is > also pretty much compatible with 3986: > > URNs (either individually or entire URN namespaces as defined below) > that do not resolve to URLs at all or that resolve to metadata or > non-Internet objects are among URN use cases explicitly permitted by > this specification; each leaves the concept of "resolution" somewhat > more abstract and difficult than the simple case of resolution to a > URL. [1.1, 2nd para] > > But the current draft also uses 'resource' in many ways which are > clearly incompatible with 3986. 3986 is very careful to distinguish > between the resource _identified_ by a URI on the one hand, and > _representations_ of that resource and _metadata_ about it on the > other. The latter are much more concrete, and the kind of thing you > can get your hands on/interact with (see section 1.2.2 of 3986 [1]). > Some examples of where the current draft is incompatible with this > position: > > "A URN [may] be ... an abstract designator that is persistent but > that does not identify a resource" [Abstract, Introduction] > Per 3986, _all_ URIs identify something, which it calls a resource. Good catch. > "media type of those resources" [2.3.3, next-to-last para] > Per 3986, resources do not in general have media types, > _representations_, e.g. as returned in messages, have media types. > > I don't think this will be hard to fix -- there's already a > distinction between what is identified and the outcome of a resolution > attempt, as well as between resolution and retrieval, and the wording > around these just needs to be tightened up a bit, with the word > 'resource' used a bit less. Whether the idea behind 3986's word > 'representation' needs to be imported, along with the word, will I > think be an editorial decision to be made in the course of the > tightening-up effort. Yes, that all seems right. > Part 2 -- 'abstract designator' As a bit of background, I would say that we introduced the term 'abstract designator' to describe names that purely identify resources; that is, the intent is that such a name will never be resolved (i.e., there is no access mechanism associated with the name) and, more specifically, that at no time will it be possible to retrieve a representation of the identified resource. > Here are some examples of the use of this term which taken together > leave me confused as to what is meant: > > A URN [may] be ... an abstract designator that is persistent but > that does not identify a resource [Abstract, Introduction] As you pointed out, this is wrong: every URI identifies a resource. > If there are or will be resolution services available for a URN, > this document calls the URN a "resource identifier" in roughly the > sense that term is used in [RFC3986]. If there is no intention to > provide any resolution services, and the distinction is important, > this document calls the URN an "abstract designator". [1.2, near the > end] This suffers from the same problem you have pointed out regarding resource identification. > If the URN does not resolve to a URL (i.e., is an abstract > designator) or if it resolves directly to an object or a non-URL > resource designator [2.3.2, 3rd para] [note that this is the only > use of the phrase 'resource designator' in the draft] > > If the URN does not resolve to a URL (e.g., is an abstract > designator) [2.3.3, 2nd para] > > because a URN might not specify the location of a resource or even > point indirectly to one [4.1, 2nd para] > > (e.g., URNs within some URN namespaces are intended to act as > abstract designators and thus are not intended to be resolved) > [6.4.6 1st para] > > Clarified that there can be URNs that neither resolve to URLs nor > are abstract designators. [F.8., 6th bullet. I _think_ this refers > to the quote above from section 2.3.2] > > It is often argued that 3986 implies that there are two in-principle > possibilities for any URI (including URNs) as far as resolution is > concerned (where the possibility that resolution may involve more than > one step is assumed): > > 1) Resolution services are or could be provided, but the results of > resolution necessarily consist only of metadata about the > identified resource, that is, no _representation_ of that > resource is or could be available; I'd like to understand more about what 'metadata' means here. RFC 3986 says the following in Section 1.2.2: A "representation" is a sequence of octets, along with representation metadata describing those octets, that constitutes a record of the state of the resource at the time when the representation is generated. Here, 'metadata' mean metadata about the representation. If there is no representation, there can be no representation metadata. However, later in the same paragraph we find this: Depending on the protocols used to perform the retrieval, additional information might be supplied about the resource (resource metadata) and its relation to other resources. This might indicate that RFC 3986 envisions a distinction between representation metadata (metadata describing the octets, as in MIME, see Section 5.1.2) and resource metadata (metadata describing the resource itself - perhaps an example would be Dublin Core information about authors, publishers, licenses, and the like). However, even the notion of resource metadata here seems to be tied to retrieval. > 2) Resolution services are or could be provided, and the results of > resolution may in practice and could in principle include one or > more representations. > > However I think the above quotes from the current draft taken together > provide evidence that it considers there to be a > _threefold_ distinction, adding > > 3) No resolution services of any kind are provided or envisaged; Yes. > However the quotes also demonstrate that no consistent interpretation > for the term 'abstract designator', e.g. as (1) or (3) (or their union), > is possible. Impossible is a strong word. :-) I agree that the current text is not fully consistent with RFC 3986 (e.g., with regard to all URIs identifying resources), and perhaps is not internally consistent. That doesn't necessarily imply that no consistent intepretation of the term 'abstract designator' is possible. As noted, we coined this term to refer to precisely your (3). The examples that I personally had in mind were XML namespaces, such as "urn:ietf:params:xml:ns:xmpp-sasl" in RFC 6120. Although I suppose one could make the argument that a "representation" of an XML namespace could take the form of a W3 XML Schema or a RELAX NG schema, that seems like a stretch to me. An even more abstract example is feature advertisement of the kind we use in XMPP: (See http://xmpp.org/extensions/xep-0300.html for details.) I suppose you could say that the foregoing URN identifies a "resource" of supporting the specified hash function. Here it's even clearer to me that there is no representation and that no resolution is ever intended. The service names defined in RFC 5031 and RFC 7462 seem similar - they are just identifiers of features that an endpoint can support. > Although at first it may seem that the most likely intended meaning > for the term is (3), in fact I don't think this makes any sense. An > identifier about which _no_ information is provided is useless, or > rather, it makes no sense to make it available, as no-one when > encountering it will be able to make anything of it. Registering a > URN namespace must surely imply the intent of providing _some_ > information about the resources identified by URNs which use it, even > if that is only metadata to the effect that all interesting > information about such resources is available offline in such-and-such > a way. For the examples adduced above, the URNs most definitely have meaning, and that meaning is specified in the relevant protocol specification. Are you suggesting that the appropriate metadata here is a pointer to the specification in which the meaning of the URN is defined? > Or, more simply, the difference between (1) and (3) is surely a > contingent one, bearing in mind the timescales over which we expect > URNs to persist. It would be an odd namespace indeed for which the > defining documents mandated that no-one could ever implement a > resolution service providing useful metadata! Well, it seems to me that the arrow of meaning for such namespaces points in the other direction. To my mind, immersed as it is in the practicalities of deploying running code for communication systems, it would be an odd resolution service indeed that attempts to "resolve" urn:xmpp:hash-function-text-names:sha-256 to XEP-0300 or to "resolve" urn:alert:service:call-waiting to RFC 7462. Instead, these URNs are used as, well, abstract designators of potentially supported features in XMPP or SIP; i.e., XMPP or SIP user agents and servers know exactly what these URNs mean (because the software developers have read the relevant specifications), but I see no reason for some generic URN parser to resolve them. Not that anyone could stop them from implementing such resolution, but there's no good reason to do so as far as I can see. Call that "contingent" if you would like. > What I think is the key distinction being implicitly appealed to is > the _representability_ of resources in a namespace. The draft appears > to use the acronym 'URL' to _mean_ a URI which is (at least in > principle) resolvable to a representation. To your point in another thread, that would be "locator". > But I'd much prefer if the > difference between (2) vs (1) union (3) were _not_ equated with > "resolve(s) to a URL", because > > a) For 3986 and many users of URLs (understanding 'URL' to mean > 'non-URN URI'), many URLs identify resources for which no > representations are possible; > > b) There are perfectly good ways which are _not_ mediated by URLs at > all to access representations for resources. Agreeing to all of that, it still seems to me that abstract designators are useful and that the concept captures something that is different from your (1) and (2). > So in summary I'm arguing that the only non-contingent property worth > naming with 'abstract' or something like it is a property of > _resources_, not of URNs. As such it's not really relevant to this > specification. > > My most-preferred outcome: just remove the term 'abstract designator' > altogether, and only discuss briefly the contingent nature of > resolution, as sometimes yielding metadata, and sometimes (perhaps > indirectly) access to representations. I'm probably being obtuse, but I still don't see what the resource metadata is for urn:xmpp:hash-function-text-names:sha-256 or urn:alert:service:call-waiting. Is it all and only the specification in which the name is defined? Peter From nobody Wed Dec 7 01:09:16 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 7CEE8129519 for ; Wed, 7 Dec 2016 01:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 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_H2=-0.001, 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 7LUpq2jLiDkr for ; Wed, 7 Dec 2016 01:09:10 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0121.outbound.protection.outlook.com [104.47.2.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016C0127071 for ; Wed, 7 Dec 2016 01:09:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=M8UAaagTTT/zkGtzOY+NkFe7n/YVMxuWz67B4Oc19rI=; b=EvFjjMoFUtioGGTK8nILqHsrAPdOZJw1vJqMW16+TScIjW/MLqNY3KBUTLMLrx/2lHye/K03rqKgbQkrpFc0Xsexj/ISwO27k2FVk0LcyEmFN4NMC0mN20uSHpLdc64EvnrzE4LZdS86P/LhExXOTURBEFySBCwrZYrpOrvwOfk= Received: from HE1PR0701MB2603.eurprd07.prod.outlook.com (10.168.187.138) by HE1PR0701MB2601.eurprd07.prod.outlook.com (10.168.187.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Wed, 7 Dec 2016 09:09:06 +0000 Received: from HE1PR0701MB2603.eurprd07.prod.outlook.com ([10.168.187.138]) by HE1PR0701MB2603.eurprd07.prod.outlook.com ([10.168.187.138]) with mapi id 15.01.0771.008; Wed, 7 Dec 2016 09:09:06 +0000 From: "Hakala, Juha E" To: Peter Saint-Andre , "Henry S. Thompson" Thread-Topic: [urn] Terminology -- 'resource' and 'abstract designator' Thread-Index: AQHSQNWkB/nqqt+K1EWT6PS4OxGR26D6mvMAgAGekiA= Date: Wed, 7 Dec 2016 09:09:06 +0000 Message-ID: References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> In-Reply-To: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [128.214.71.222] x-ms-office365-filtering-correlation-id: f3785513-5ff8-4f2c-4361-08d41e80b2b3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0701MB2601; x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2601; 7:GG/9qL29GYrAaxqjgZoV2qFq4XAe5XM/5JSc8QBCNUEfMIeRrscdNORVVTsRrMSxvph0EgrPX9Zayp4CV/wGeB5er0B5DF7CRqSLxZmIANNzqloEt4+ODkqxIqsBX6pm1ULGQFJKV6KbbXEvzJQwBh67Q2D17VqE1Ge/uPfvD1h21YhcDO/6ieU1f0uYxmJgdaKuTirq+vd6mryUqLghmQhOP1AvVdWKth8WC+6dL5Tlu786snqSee4qPd/dA9h27Jf0265vKjGY/XO4cZL4qGt0WFMwfkGR5LET7Ppd8RZ3o8S+C7ogmGD2JqgAKOM4REhdGspl77yi4/Zi2BzrnO1kbmEt1TiOtQPyTrzApt10fnp7zzMDGVjp5MNGSm3EGxFIwEl5XrChDo8gql/HPZmFjGp6ogwOPz3D4R4e6XyhvFCYbSP18i4lAr9mmQBCY+rv5A4JoTwvdFc17wkH2g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(35073007944872)(181193635805523); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(6072148); SRVR:HE1PR0701MB2601; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2601; x-forefront-prvs: 01494FA7F7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(51914003)(199003)(24454002)(189002)(377454003)(13464003)(66066001)(8936002)(6506006)(39850400001)(5660300001)(39450400002)(50986999)(9686002)(68736007)(2950100002)(39410400001)(74482002)(38730400001)(15395725005)(4326007)(33656002)(229853002)(2906002)(102836003)(77096006)(189998001)(106356001)(5001770100001)(7696004)(105586002)(76176999)(106116001)(101416001)(6116002)(3846002)(54356999)(97736004)(7846002)(305945005)(2900100001)(7736002)(39840400001)(92566002)(3660700001)(8676002)(81166006)(81156014)(122556002)(76576001)(74316002)(3280700002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2601; H:HE1PR0701MB2603.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 07 Dec 2016 09:09:06.6640 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2601 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Terminology -- 'resource' and 'abstract designator' 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, 07 Dec 2016 09:09:14 -0000 Hello,=20 a few comments inline below.=20 > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Peter Saint-Andre > Sent: 6. joulukuuta 2016 9:00 > To: Henry S. Thompson > Cc: urn@ietf.org > Subject: Re: [urn] Terminology -- 'resource' and 'abstract designator' >=20 > Hi Henry, thanks for the continued reviews and feedback. Comments inline. >=20 > On 11/17/16 5:22 AM, Henry S. Thompson wrote: > > Part 1 -- 3986 incompatibility > > > > URNs are URIs, that is, Uniform Resource Identifiers. Every URI > > identifies something, as the name implies, and 3986 uses the term > > 'resource' as the cover term for _anything_ that is identified by a > > URI. It explicitly places _no_ constraint on what a URI can identify. > > In other words, anything can be a resource: real, imaginary, abstract, > > concrete, individual, set (finite or infinite), ... You say below that resources do not in general have media types. If that is= the case, then there is a constraint on what a URI can identify if identif= ication of representations (which do have a media type) is not covered in t= he URI syntax as well. More about this below. =20 Whatever general reservations I may have about RFC 3986, I have no problem = with using the RFC 3986 terminology in RFC2141bis. Communities using URNs w= ill in any case map the URN terminology from the URN syntax specification a= nd other IETF documents to whatever terms they are using internally. Such t= erminological mappings may be a bit awkward, but that should have no impact= on the URN usage within these domains.=20 Just to give you an example, library community does not use and will not us= e terms "resource" and "representation". We have works, expressions, manife= stations and items. I assume (for now) that "resource" covers the first thr= ee of these, and representation equals item. Works are immaterial (Hamlet, = the original text in English) and so are expressions which are for instance= translations of works. Manifestations are physical or digital embodiments = of works and expressions.=20 There are international standard identifiers for all of these resources. We= have also standard identifiers for metadata records describing these resou= rces, and it is fine with me to say that these metadata records are resourc= es as well. And there are standard identifiers for authors like Shakespeare= , and publishers (and all the other organizations out there). Calling these= natural and legal persons resources within this particular context is conf= using, but we can deal with it. There are also identifiers for subject head= ings (literature - Medieval - English) and place names (Stratford-Upon-Avon= ) and OK, we can think that they (and definitely metadata records describin= g them) are resources as well. One area where RFC 3986 is a bit restrictive is that we have standard ident= ifiers for representations as well. We can identify items, that is, individ= ual copies of a (printed) book. It is also possible and sometimes necessary= to give different persistent identifiers to, say, PDF version of Hamlet in= English, available from different sources (publisher, legal deposit collec= tion in the national library, open repository at the university, and so on)= . =20 So in order to be flexible enough for libraries, RFC 3986 and RFC2141bis sh= ould talk about both resource identifiers and representation identifiers. B= ut we can do without the latter in 2141bis. From our point of view the term= inology used in RFC 3986 (resources and representations) is far too simple,= but using it in URN context should not be a problem, as long as libraries = can still use their own, more fine grained terminology in namespace registr= ation requests. For instance, it would not be meaningful to say that ISBNs = are for book resources (in RFC 3986 sense), they are for manifestations of = books. =20 =20 > > > > The current draft does not define the term 'resource'. It often uses > > it in ways which are consistent with 3986's definition, for example in > > phrases such as "resource identifier" (lower case in original), > > "identified resource", "The kinds of resources identified by URNs" and > > "persistent identification of resources". This longer exposition is > > also pretty much compatible with 3986: > > > > URNs (either individually or entire URN namespaces as defined below) > > that do not resolve to URLs at all or that resolve to metadata or > > non-Internet objects are among URN use cases explicitly permitted by > > this specification; each leaves the concept of "resolution" somewhat > > more abstract and difficult than the simple case of resolution to a > > URL. [1.1, 2nd para] It is important to say that URN resolution may not always produce the ident= ified resource itself, but related resources such as bibliographic metadata= record describing the resource (or metadata record describing rights infor= mation about the resource). The result can be URL, but not a URL of the id= entified resource, but of something else. =20 > > But the current draft also uses 'resource' in many ways which are > > clearly incompatible with 3986. 3986 is very careful to distinguish > > between the resource _identified_ by a URI on the one hand, and > > _representations_ of that resource and _metadata_ about it on the > > other. The latter are much more concrete, and the kind of thing you > > can get your hands on/interact with (see section 1.2.2 of 3986 [1]). What exactly do you mean by "getting your hands on"? If we assume for a mom= ent that the PDF version of a book is a resource, then is a particular copy= of that book on e.g. the national library of Finland's legal deposit colle= ction a representation? And a back-up copy in a dark archive another one? O= ur PDF copy might have URN:NBN assigned by the library, while a publisher m= ight have a DOI for another representation of the same resource on the pub= lisher's server. So are these copies then different resources, or is RFC 39= 86 just plain wrong? =20 And if the PDF version of a book is a representation, how can we extend URN= scope to identification of not only representations, but also to copies of= those representations in different locations?=20 > > Some examples of where the current draft is incompatible with this > > position: > > > > "A URN [may] be ... an abstract designator that is persistent but > > that does not identify a resource" [Abstract, Introduction] > > Per 3986, _all_ URIs identify something, which it calls a resource. >=20 > Good catch. + 1, from RFC2141bis point of view.=20 > > "media type of those resources" [2.3.3, next-to-last para] > > Per 3986, resources do not in general have media types, > > _representations_, e.g. as returned in messages, have media types. Standard identifiers the library community has been using for decades ident= ify things that do have a media type, such as books in PDF, or audio in MP3= . Media type is important, since usually different representations (PDF, OD= F, HTML versions of a book) do get different identifiers.=20 The only resources (in the RFC 3986 sense) which the libraries deal with ar= e what we call works and expressions, which are immaterial and do not have = a media type. But since we deal more with manifestations it would be totall= y impossible for libraries to accept a specification which does not allow i= dentification of things which do have a media type. =20 > > I don't think this will be hard to fix -- there's already a > > distinction between what is identified and the outcome of a resolution > > attempt, as well as between resolution and retrieval, and the wording > > around these just needs to be tightened up a bit, with the word > > 'resource' used a bit less. Whether the idea behind 3986's word > > 'representation' needs to be imported, along with the word, will I > > think be an editorial decision to be made in the course of the > > tightening-up effort. >=20 > Yes, that all seems right. As far as I am concerned, RFC3986 does have some issues with resources and = representations which seem to become more apparent when we apply these term= s in the real world (at least as libraries see them). But my suggestion is = to not to dig too deep in possible problems in the URI syntax problems, jus= t assume that all is well, talk about resources only in the URN syntax spec= ification and let communities use whatever terms they are used to and ident= ify whatever they need to identify in their own namespaces.=20 =20 Best regards,=20 Juha=20 > > Part 2 -- 'abstract designator' >=20 > As a bit of background, I would say that we introduced the term 'abstract > designator' to describe names that purely identify resources; that is, th= e > intent is that such a name will never be resolved (i.e., there is no acce= ss > mechanism associated with the name) and, more specifically, that at no ti= me > will it be possible to retrieve a representation of the identified resour= ce. >=20 > > Here are some examples of the use of this term which taken together > > leave me confused as to what is meant: > > > > A URN [may] be ... an abstract designator that is persistent but > > that does not identify a resource [Abstract, Introduction] >=20 > As you pointed out, this is wrong: every URI identifies a resource. >=20 > > If there are or will be resolution services available for a URN, > > this document calls the URN a "resource identifier" in roughly the > > sense that term is used in [RFC3986]. If there is no intention to > > provide any resolution services, and the distinction is important, > > this document calls the URN an "abstract designator". [1.2, near the > > end] >=20 > This suffers from the same problem you have pointed out regarding resourc= e > identification. >=20 > > If the URN does not resolve to a URL (i.e., is an abstract > > designator) or if it resolves directly to an object or a non-URL > > resource designator [2.3.2, 3rd para] [note that this is the only > > use of the phrase 'resource designator' in the draft] > > > > If the URN does not resolve to a URL (e.g., is an abstract > > designator) [2.3.3, 2nd para] > > > > because a URN might not specify the location of a resource or even > > point indirectly to one [4.1, 2nd para] > > > > (e.g., URNs within some URN namespaces are intended to act as > > abstract designators and thus are not intended to be resolved) > > [6.4.6 1st para] > > > > Clarified that there can be URNs that neither resolve to URLs nor > > are abstract designators. [F.8., 6th bullet. I _think_ this refers > > to the quote above from section 2.3.2] > > > > It is often argued that 3986 implies that there are two in-principle > > possibilities for any URI (including URNs) as far as resolution is > > concerned (where the possibility that resolution may involve more than > > one step is assumed): > > > > 1) Resolution services are or could be provided, but the results of > > resolution necessarily consist only of metadata about the > > identified resource, that is, no _representation_ of that > > resource is or could be available; >=20 > I'd like to understand more about what 'metadata' means here. >=20 > RFC 3986 says the following in Section 1.2.2: >=20 > A "representation" is a > sequence of octets, along with representation metadata describing > those octets, that constitutes a record of the state of the resource > at the time when the representation is generated. >=20 > Here, 'metadata' mean metadata about the representation. If there is no > representation, there can be no representation metadata. >=20 > However, later in the same paragraph we find this: >=20 > Depending on the protocols used to perform the retrieval, > additional information might be supplied about the resource (resource > metadata) and its relation to other resources. >=20 > This might indicate that RFC 3986 envisions a distinction between > representation metadata (metadata describing the octets, as in MIME, see > Section 5.1.2) and resource metadata (metadata describing the resource > itself - perhaps an example would be Dublin Core information about author= s, > publishers, licenses, and the like). However, even the notion of resource > metadata here seems to be tied to retrieval. >=20 > > 2) Resolution services are or could be provided, and the results of > > resolution may in practice and could in principle include one or > > more representations. > > > > However I think the above quotes from the current draft taken together > > provide evidence that it considers there to be a _threefold_ > > distinction, adding > > > > 3) No resolution services of any kind are provided or envisaged; >=20 > Yes. >=20 > > However the quotes also demonstrate that no consistent interpretation > > for the term 'abstract designator', e.g. as (1) or (3) (or their > > union), is possible. >=20 > Impossible is a strong word. :-) >=20 > I agree that the current text is not fully consistent with RFC 3986 (e.g.= , with > regard to all URIs identifying resources), and perhaps is not internally > consistent. That doesn't necessarily imply that no consistent intepretati= on of > the term 'abstract designator' is possible. >=20 > As noted, we coined this term to refer to precisely your (3). >=20 > The examples that I personally had in mind were XML namespaces, such as > "urn:ietf:params:xml:ns:xmpp-sasl" in RFC 6120. Although I suppose one > could make the argument that a "representation" of an XML namespace > could take the form of a W3 XML Schema or a RELAX NG schema, that seems > like a stretch to me. >=20 > An even more abstract example is feature advertisement of the kind we use > in XMPP: >=20 > >=20 > (See http://xmpp.org/extensions/xep-0300.html for details.) >=20 > I suppose you could say that the foregoing URN identifies a "resource" > of supporting the specified hash function. Here it's even clearer to me t= hat > there is no representation and that no resolution is ever intended. >=20 > The service names defined in RFC 5031 and RFC 7462 seem similar - they ar= e > just identifiers of features that an endpoint can support. >=20 > > Although at first it may seem that the most likely intended meaning > > for the term is (3), in fact I don't think this makes any sense. An > > identifier about which _no_ information is provided is useless, or > > rather, it makes no sense to make it available, as no-one when > > encountering it will be able to make anything of it. Registering a > > URN namespace must surely imply the intent of providing _some_ > > information about the resources identified by URNs which use it, even > > if that is only metadata to the effect that all interesting > > information about such resources is available offline in such-and-such > > a way. >=20 > For the examples adduced above, the URNs most definitely have meaning, > and that meaning is specified in the relevant protocol specification. > Are you suggesting that the appropriate metadata here is a pointer to the > specification in which the meaning of the URN is defined? >=20 > > Or, more simply, the difference between (1) and (3) is surely a > > contingent one, bearing in mind the timescales over which we expect > > URNs to persist. It would be an odd namespace indeed for which the > > defining documents mandated that no-one could ever implement a > > resolution service providing useful metadata! >=20 > Well, it seems to me that the arrow of meaning for such namespaces points > in the other direction. To my mind, immersed as it is in the practicaliti= es of > deploying running code for communication systems, it would be an odd > resolution service indeed that attempts to "resolve" > urn:xmpp:hash-function-text-names:sha-256 to XEP-0300 or to "resolve" > urn:alert:service:call-waiting to RFC 7462. Instead, these URNs are used = as, > well, abstract designators of potentially supported features in XMPP or S= IP; > i.e., XMPP or SIP user agents and servers know exactly what these URNs > mean (because the software developers have read the relevant > specifications), but I see no reason for some generic URN parser to resol= ve > them. Not that anyone could stop them from implementing such resolution, > but there's no good reason to do so as far as I can see. > Call that "contingent" if you would like. >=20 > > What I think is the key distinction being implicitly appealed to is > > the _representability_ of resources in a namespace. The draft appears > > to use the acronym 'URL' to _mean_ a URI which is (at least in > > principle) resolvable to a representation. >=20 > To your point in another thread, that would be "locator". >=20 > > But I'd much prefer if the > > difference between (2) vs (1) union (3) were _not_ equated with > > "resolve(s) to a URL", because > > > > a) For 3986 and many users of URLs (understanding 'URL' to mean > > 'non-URN URI'), many URLs identify resources for which no > > representations are possible; > > > > b) There are perfectly good ways which are _not_ mediated by URLs at > > all to access representations for resources. >=20 > Agreeing to all of that, it still seems to me that abstract designators a= re useful > and that the concept captures something that is different from your (1) a= nd > (2). >=20 > > So in summary I'm arguing that the only non-contingent property worth > > naming with 'abstract' or something like it is a property of > > _resources_, not of URNs. As such it's not really relevant to this > > specification. > > > > My most-preferred outcome: just remove the term 'abstract designator' > > altogether, and only discuss briefly the contingent nature of > > resolution, as sometimes yielding metadata, and sometimes (perhaps > > indirectly) access to representations. >=20 > I'm probably being obtuse, but I still don't see what the resource metada= ta is > for urn:xmpp:hash-function-text-names:sha-256 or urn:alert:service:call- > waiting. Is it all and only the specification in which the name is define= d? >=20 > Peter >=20 >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Wed Dec 7 04:16:13 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 DCA4212987A for ; Wed, 7 Dec 2016 04:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, 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 P8wzVqWrYclR for ; Wed, 7 Dec 2016 04:16:07 -0800 (PST) Received: from loire.is.ed.ac.uk (loire.is.ed.ac.uk [129.215.16.10]) by ietfa.amsl.com (Postfix) with ESMTP id C44D0129527 for ; Wed, 7 Dec 2016 04:16:02 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by loire.is.ed.ac.uk (8.14.7/8.14.6) with ESMTP id uB7CFstS005904; Wed, 7 Dec 2016 12:15:55 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id uB7CFsRG018356; Wed, 7 Dec 2016 12:15:54 GMT 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 uB7CFrk8010774; Wed, 7 Dec 2016 12:15:53 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id uB7CFr2Q010773; Wed, 7 Dec 2016 12:15:53 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: "Hakala\, Juha E" References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 07 Dec 2016 12:15:53 +0000 In-Reply-To: (Juha E. Hakala's message of "Wed\, 7 Dec 2016 09\:09\:06 +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 loire.is.ed.ac.uk with MIMEDefang 2.78, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.78 on 129.215.16.10 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Terminology -- 'resource' and 'abstract designator' 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, 07 Dec 2016 12:16:11 -0000 [Prolog: I've been avoiding FRBR [1] terminology, with which I am familiar, because although as you say the information science community knows it very well, the web community does not. And there's an interesting intellectual discussion to be had about which of FRBR's 'manifestation' or 'item' is closer to 3986's 'representation', but I think we can bring urnbis to completion without engaging further with that question and the many interesting issues which surround it.] [Disclaimer: The above notwithstanding, and with respect, I don't think any of what follows actually impacts on the discussion of what, if anything, needs to change in urnbis -- for that, see my forthcoming reply to Peter.] Hakala, Juha E writes: > [Peter Saint-Andre wrote] >> a few comments inline below. > >> -----Original Message----- >> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Peter Saint-Andre >> Cc: urn@ietf.org >> Subject: Re: [urn] Terminology -- 'resource' and 'abstract designator' >> >> Hi Henry, thanks for the continued reviews and feedback. Comments inline. >> >> On 11/17/16 5:22 AM, Henry S. Thompson wrote: >> > Part 1 -- 3986 incompatibility >> > >> > URNs are URIs, that is, Uniform Resource Identifiers. Every URI >> > identifies something, as the name implies, and 3986 uses the term >> > 'resource' as the cover term for _anything_ that is identified by a >> > URI. It explicitly places _no_ constraint on what a URI can identify. >> > In other words, anything can be a resource: real, imaginary, abstract, >> > concrete, individual, set (finite or infinite), ... > > You say below that resources do not in general have media types. If > that is the case, then there is a constraint on what a URI can > identify if identification of representations (which do have a media > type) is not covered in the URI syntax as well. More about this below. You're right, of course -- 'in general' doesn't mean 'always'. It is however actually quite rare in practice for a representation as such to have a distinct URI: from the 3986 perspective a representation is what you get in a message, the outcome of a retrieval request for a URI for a resource that _has_ a representation. Even in the (apparently) simple case of, say, the particular online item corresponding to the PDF manifestation of the FRBR report [1] on some IFLA server somewhere, 3986 would call what [1] identifies a resource, more-or-less corresponding to the 2008 English expression of the work. The manifestation has what you might call a 'native' media type (application/pdf in this case), which is reproduced as representation metadata in any successful HTTP Response message in reply to an HTTP GET Request to that server for that URI. [Note: this does _not_ claim to be a definitive answer to the question of how to deploy FRBR in the case of web-hosted artefacts, see disclaimer above. I believe the point relevant to urnbis here is independent of exactly which FRBR-defined terms should be applied to which 3986-defined terms] Berners-Lee has used the term *information resource* (see AWWW [2]) for resources like this, that is, resources "all of [whose] essential characteristics can be conveyed in a message." There's nothing in 3986 or elsewhere to rule _out_ creating a URI for a resource which one might describe as "the particular byte-sequence conforming to the application/pdf media type and corresponding to the 2008 edition of the FRBR report which was transmitted from 178.18.86.42 to 129.215.25.32 beginning at 2016-12-07 11:26:55 GMT in response to a retrieval request for http://www.ifla.org/files/assets/cataloguing/frbr/frbr_2008.pdf". You could then make assertions about that particular representation as identified by such a URI (for example that it consisted of 1336355 bytes, was expressed using PDF-1.4, that it had not been compressed for transmission, that it took 2.1 seconds to be transmitted, etc.), some, but not (necessarily) all of which would also be true of the item on the server. But it _would_ (again quoting 3986) be "a record of the state of [that] resource at the time when [that] representation [was] generated". > Just to give you an example, library community does not use and will > not use terms "resource" and "representation". We have works, > expressions, manifestations and items. I assume (for now) that > "resource" covers the first three of these, and representation equals > item. Works are immaterial (Hamlet, the original text in English) and > so are expressions which are for instance translations of > works. Manifestations are physical or digital embodiments of works and > expressions. That's one possible version of the mapping, I agree, although not quite the same as what I outlined above. > One area where RFC 3986 is a bit restrictive is that we have standard > identifiers for representations as well. We can identify items, that > is, individual copies of a (printed) book. It is also possible and > sometimes necessary to give different persistent identifiers to, say, > PDF version of Hamlet in English, available from different sources > (publisher, legal deposit collection in the national library, open > repository at the university, and so on). As I hope is clear from the extended example above, no problem with that. It's just that 3986 doesn't call those things representations, they are resources too. > So in order to be flexible enough for libraries, RFC 3986 and > RFC2141bis should talk about both resource identifiers and > representation identifiers. Indeed, since they can all have URIs, they are all resources. > But we can do without the latter in 2141bis. From our point of view > the terminology used in RFC 3986 (resources and representations) is > far too simple, but using it in URN context should not be a problem, > as long as libraries can still use their own, more fine grained > terminology in namespace registration requests. For instance, it would > not be meaningful to say that ISBNs are for book resources (in RFC > 3986 sense), they are for manifestations of books. Just fine. >> > The current draft does not define the term 'resource'. It often uses >> > it in ways which are consistent with 3986's definition, for example in >> > phrases such as "resource identifier" (lower case in original), >> > "identified resource", "The kinds of resources identified by URNs" and >> > "persistent identification of resources". This longer exposition is >> > also pretty much compatible with 3986: >> > >> > URNs (either individually or entire URN namespaces as defined below) >> > that do not resolve to URLs at all or that resolve to metadata or >> > non-Internet objects are among URN use cases explicitly permitted by >> > this specification; each leaves the concept of "resolution" somewhat >> > more abstract and difficult than the simple case of resolution to a >> > URL. [1.1, 2nd para] > > It is important to say that URN resolution may not always produce the > identified resource itself, but related resources such as > bibliographic metadata record describing the resource (or metadata > record describing rights information about the resource). The result > can be URL, but not a URL of the identified resource, but of something > else. >From the 3986 perspective, _no_ resolution _ever_ produces the identified resource. Resolution by definition produces a representation. Whether it's a representation _of the (state of the) resource_, or of resource metadata, is a contingent question. Berners-Lee would say that the former (a representation of the resource) is _only_ possible for *information resources*. >> > But the current draft also uses 'resource' in many ways which are >> > clearly incompatible with 3986. 3986 is very careful to distinguish >> > between the resource _identified_ by a URI on the one hand, and >> > _representations_ of that resource and _metadata_ about it on the >> > other. The latter are much more concrete, and the kind of thing you >> > can get your hands on/interact with (see section 1.2.2 of 3986 [1]). > > What exactly do you mean by "getting your hands on"? If we assume for > a moment that the PDF version of a book is a resource, then is a > particular copy of that book on e.g. the national library of Finland's > legal deposit collection a representation? No, a resource. > And a back-up copy in a dark archive another one? No, a resource. > Our PDF copy might have URN:NBN assigned by the library, while a > publisher might have a DOI for another representation of the same > resource on the publisher's server. So are these copies then different > resources, or is RFC 3986 just plain wrong? Different resources. > And if the PDF version of a book is a representation, how can we > extend URN scope to identification of not only representations, but > also to copies of those representations in different locations? Not a representation, so not a problem. >> > "media type of those resources" [2.3.3, next-to-last para] >> > Per 3986, resources do not in general have media types, >> > _representations_, e.g. as returned in messages, have media types. > > Standard identifiers the library community has been using for decades > identify things that do have a media type, such as books in PDF, or > audio in MP3. Media type is important, since usually different > representations (PDF, ODF, HTML versions of a book) do get different > identifiers. Agreed, but not a problem, see above. > The only resources (in the RFC 3986 sense) which the libraries deal > with are what we call works and expressions, which are immaterial and > do not have a media type. But since we deal more with manifestations > it would be totally impossible for libraries to accept a specification > which does not allow identification of things which do have a media > type. Agreed, but not a problem, see above. >> > I don't think this will be hard to fix -- there's already a >> > distinction between what is identified and the outcome of a resolution >> > attempt, as well as between resolution and retrieval, and the wording >> > around these just needs to be tightened up a bit, with the word >> > 'resource' used a bit less. Whether the idea behind 3986's word >> > 'representation' needs to be imported, along with the word, will I >> > think be an editorial decision to be made in the course of the >> > tightening-up effort. >> >> Yes, that all seems right. > > As far as I am concerned, RFC3986 does have some issues with resources > and representations which seem to become more apparent when we apply > these terms in the real world (at least as libraries see them). Quite likely, but I hope the above has helped clarify that some of the problems you thought were there are not actually there. > But my suggestion is to not to dig too deep in possible problems in > the URI syntax problems, just assume that all is well, talk about > resources only in the URN syntax specification and let communities use > whatever terms they are used to and identify whatever they need to > identify in their own namespaces. Works for me. 3986's use of 'representation' is _very_ narrow, and doesn't correspond well to ordinary language use. As I said in the original ("whether ... 'representation' needs to be imported" ...), I don't assume it needs to appear in urnbis at all. Thanks for your detailed and thoughtful reply, ht [1] http://www.ifla.org/files/assets/cataloguing/frbr/frbr_2008.pdf [2] https://www.w3.org/TR/webarch/ -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Mon Dec 12 06:27:13 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 789AF129BE1 for ; Mon, 12 Dec 2016 06:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 TpWHcYVvvyCv for ; Mon, 12 Dec 2016 06:27:06 -0800 (PST) Received: from loire.is.ed.ac.uk (loire.is.ed.ac.uk [129.215.16.10]) by ietfa.amsl.com (Postfix) with ESMTP id 62C24129BE5 for ; Mon, 12 Dec 2016 06:27:03 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by loire.is.ed.ac.uk (8.14.7/8.14.6) with ESMTP id uBCER2rY013668; Mon, 12 Dec 2016 14:27:02 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id uBCER1p5020678; Mon, 12 Dec 2016 14:27:02 GMT 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 uBCER16g020296; Mon, 12 Dec 2016 14:27:01 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id uBCER0Vc020282; Mon, 12 Dec 2016 14:27:00 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Peter Saint-Andre References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 12 Dec 2016 14:27:00 +0000 In-Reply-To: (Peter Saint-Andre's message of "Mon\, 5 Dec 2016 22\:59\:38 -0800") 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 loire.is.ed.ac.uk with MIMEDefang 2.78, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.78 on 129.215.16.10 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Terminology -- 'resource' and 'abstract designator' 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: Mon, 12 Dec 2016 14:27:12 -0000 Peter Saint-Andre writes: >> Part 1 -- 3986 incompatibility >> ... > Yes, that all seems right. >> Part 2 -- 'abstract designator' > > As a bit of background, I would say that we introduced the term > 'abstract designator' to describe names that purely identify > resources; that is, the intent is that such a name will never be > resolved (i.e., there is no access mechanism associated with the name) > and, more specifically, that at no time will it be possible to > retrieve a representation of the identified resource. Understood. >> Here are some examples of the use of this term which taken together >> leave me confused as to what is meant: >> ... >> If the URN does not resolve to a URL (i.e., is an abstract >> designator) or if it resolves directly to an object or a non-URL >> resource designator [2.3.2, 3rd para] [note that this is the only >> use of the phrase 'resource designator' in the draft] >> >> If the URN does not resolve to a URL (e.g., is an abstract >> designator) [2.3.3, 2nd para] >> >> because a URN might not specify the location of a resource or even >> point indirectly to one [4.1, 2nd para] >> >> (e.g., URNs within some URN namespaces are intended to act as >> abstract designators and thus are not intended to be resolved) >> [6.4.6 1st para] >> >> Clarified that there can be URNs that neither resolve to URLs nor >> are abstract designators. [F.8., 6th bullet. I _think_ this refers >> to the quote above from section 2.3.2] >> >> It is often argued that 3986 implies that there are two in-principle >> possibilities for any URI (including URNs) as far as resolution is >> concerned (where the possibility that resolution may involve more than >> one step is assumed): >> >> 1) Resolution services are or could be provided, but the results of >> resolution necessarily consist only of metadata about the >> identified resource, that is, no _representation_ of that >> resource is or could be available; > > I'd like to understand more about what 'metadata' means here. > > RFC 3986 says the following in Section 1.2.2: > > A "representation" is a > sequence of octets, along with representation metadata describing > those octets, that constitutes a record of the state of the resource > at the time when the representation is generated. > > Here, 'metadata' mean metadata about the representation. If there is > no representation, there can be no representation metadata. Right -- as in my reply to Juha, this is an example of 3986's very _narrow_ use of 'representation'. And yes, 3986 is careful to distinguish between representation metadata, which will always be strictly defined by the protocol by which the representation is delivered, and resource metadata, which is unconstrained by 3986. > However, later in the same paragraph we find this: > > Depending on the protocols used to perform the retrieval, > additional information might be supplied about the resource (resource > metadata) and its relation to other resources. > > This might indicate that RFC 3986 envisions a distinction between > representation metadata (metadata describing the octets, as in MIME, > see Section 5.1.2) and also protocol-related information, such as cacheability, time-to-live, etc. > and resource metadata (metadata describing the resource itself Yes. > - perhaps an example would be Dublin Core information > about authors, publishers, licenses, and the like). For example, yes. But much further than that in the case of non-representable resources (non-information resources, to use Berners-Lee's term, see my reply to Juha) -- more on this below. > However, even the notion of resource metadata here seems to be tied to > retrieval. Yes, I _think_ the '_additional_ information might be _supplied_' [emphasis added] is a reference to on the one hand offers of other formats (MIME and/or translations), and on the other hand (where 'alternative' would be more accurate than 'additional') when no representation is supplied but other information is (again, see below). >> 2) Resolution services are or could be provided, and the results of >> resolution may in practice and could in principle include one or >> more representations. >> >> However I think the above quotes from the current draft taken together >> provide evidence that it considers there to be a >> _threefold_ distinction, adding >> >> 3) No resolution services of any kind are provided or envisaged; > > Yes. > >> However the quotes also demonstrate that no consistent interpretation >> for the term 'abstract designator', e.g. as (1) or (3) (or their union), >> is possible. > > Impossible is a strong word. :-) > > I agree that the current text is not fully consistent with RFC 3986 > (e.g., with regard to all URIs identifying resources), and perhaps is > not internally consistent. That doesn't necessarily imply that no > consistent intepretation of the term 'abstract designator' is possible. Indeed. > As noted, we coined this term to refer to precisely your (3). Right -- it's now clear that we disagree about the _possibility_ of such identifiers. > The examples that I personally had in mind were XML namespaces, such > as "urn:ietf:params:xml:ns:xmpp-sasl" in RFC 6120. Although I suppose > one could make the argument that a "representation" of an XML > namespace could take the form of a W3 XML Schema or a RELAX NG schema, > that seems like a stretch to me. Indeed. Stipulate that no representation is possible. XML namespaces are not, in Berners-Lee's terms, information resources. A brief *digression* is necessary before we proceed. In your reply to my other message, you preferred 'access' to 'retrieve', and I accepted that in my follow-up. I _assumed_ you preferred the more general term because you didn't want to distinguish in the relevant contexts between my cases (1) and (2) above, that is, that it counts as 'accessing' a resource if you can get resource metadata about it, even though you can't get a representation == 'retrieve'. Back to the namespace example, which proves empirically opportune. If you issue an HTTP GET request for the XML Schema namespace URI, that is, http://www.w3.org/2001/XMLSchema, or for the XML encryption namespace (http://www.w3.org/2009/xmlenc11), the response you get is not a representation _of_ the resource, rather it gives you information _about_ the resource: strictly speacking it represents a different resource which gives a bit of prose description and pointers to the relevant standards. That's a good example of resource metadata. > An even more abstract example is feature advertisement of the kind we > use in XMPP: > > > > (See http://xmpp.org/extensions/xep-0300.html for details.) > > I suppose you could say that the foregoing URN identifies a "resource" > of supporting the specified hash function. Here it's even clearer to > me that there is no representation and that no resolution is ever > intended. > > The service names defined in RFC 5031 and RFC 7462 seem similar - they > are just identifiers of features that an endpoint can support. I'm happy to stipulate that none of these identify information resources either: they all denote some documented point in some enumerated type. But that doesn't mean someone might not find it useful to provide a resolution service for those enumerated types which, as for the namespace examples above, provide human-readable resource metadata. >From which the next bit of my message follows, I hope: >> Although at first it may seem that the most likely intended meaning >> for the term is (3), in fact I don't think this makes any sense. An >> identifier about which _no_ information is provided is useless, or >> rather, it makes no sense to make it available, as no-one when >> encountering it will be able to make anything of it. Registering a >> URN namespace must surely imply the intent of providing _some_ >> information about the resources identified by URNs which use it, even >> if that is only metadata to the effect that all interesting >> information about such resources is available offline in such-and-such >> a way. > > For the examples adduced above, the URNs most definitely have meaning, > and that meaning is specified in the relevant protocol > specification. Are you suggesting that the appropriate metadata here > is a pointer to the specification in which the meaning of the URN is > defined? Precisely. >> Or, more simply, the difference between (1) and (3) is surely a >> contingent one, bearing in mind the timescales over which we expect >> URNs to persist. It would be an odd namespace indeed for which the >> defining documents mandated that no-one could ever implement a >> resolution service providing useful metadata! > > Well, it seems to me that the arrow of meaning for such namespaces > points in the other direction. To my mind, immersed as it is in the > practicalities of deploying running code for communication systems, it > would be an odd resolution service indeed that attempts to "resolve" > urn:xmpp:hash-function-text-names:sha-256 to XEP-0300 or to "resolve" > urn:alert:service:call-waiting to RFC 7462. Instead, these URNs are > used as, well, abstract designators of potentially supported features > in XMPP or SIP; i.e., XMPP or SIP user agents and servers know exactly > what these URNs mean (because the software developers have read the > relevant specifications), but I see no reason for some generic URN > parser to resolve them. Not that anyone could stop them from > implementing such resolution, but there's no good reason to do so as > far as I can see. Call that "contingent" if you would like. Reasonable persons might differ, I submit. There's a line of argument, expressed in the folkloric argument for why the Web works: "because you can write URIs on the side of a bus, follow your nose and view source" [1]. The "follow your nose" point is more formally worked through in the TAG finding "The Self-Describing Web" [2]. On this account, part of the practical value of using URNs instead of any other form of managed name is precisely that the overhead involved in supplying online access to useful information is low because some much of the necessary infrastructure is already in place. More controversially, there is the expectation/vision/hope/dream of the Semantic Web, that is, of _machine-interpretable_ metadata, where, for example, one might hope to find a set of axioms, expressed in RDF, which would actually support an automatic operationalisation of e.g. the various XEP-0300 hash functionalities. >> What I think is the key distinction being implicitly appealed to is >> the _representability_ of resources in a namespace. The draft appears >> to use the acronym 'URL' to _mean_ a URI which is (at least in >> principle) resolvable to a representation. > > To your point in another thread, that would be "locator". Well, no longer -- see the *digression* above -- that is what I meant originally, but in response to your suggestion I agreed to widening, shall we say, from "_retrieval_-enabled" to "_access_-enabled", where the former is restricted to representations but the latter extends to (resource) metadata. >> But I'd much prefer if the >> difference between (2) vs (1) union (3) were _not_ equated with >> "resolve(s) to a URL", because >> >> a) For 3986 and many users of URLs (understanding 'URL' to mean >> 'non-URN URI'), many URLs identify resources for which no >> representations are possible; >> >> b) There are perfectly good ways which are _not_ mediated by URLs at >> all to access representations for resources. > > Agreeing to all of that, it still seems to me that abstract > designators are useful and that the concept captures something that is > different from your (1) and (2). Given your examples and discussion that I'm replying to here, I think the point now is that I see no difference between what it turns our you mean by 'abstract designator' and my (1): identifiers of resources for which no representation (in the strict 3986 sense) is possible. That certainly fits with the _word_ 'abstract': of necessity although we can talk _about_ abstractions, even define them, they are not themselves the same as that talk or those definitions. >> So in summary I'm arguing that the only non-contingent property worth >> naming with 'abstract' or something like it is a property of >> _resources_, not of URNs. As such it's not really relevant to this >> specification. In the context of the foregoing I should acknowledge that if a URN namespace _by construction_ provides names only for abtract/imaginary/hypothetical entities, then all names in that namespace fall into my class (1). >> My most-preferred outcome: just remove the term 'abstract designator' >> altogether, and only discuss briefly the contingent nature of >> resolution, as sometimes yielding metadata, and sometimes (perhaps >> indirectly) access to representations. > > I'm probably being obtuse, but I still don't see what the resource > metadata is for urn:xmpp:hash-function-text-names:sha-256 or > urn:alert:service:call-waiting. Is it all and only the specification > in which the name is defined? I hope the above has clarified that it's not by any means that narrow. One last example. Consider the space of (registered) Media Types. They are certainly not representable as such, they definitely fall into the category of an enumerated type with externally-specified semantics. As such we might well think there _should_ be a URN namespace for them. Suppose there were, e.g. urn:ietf:mediatype:. If so, then it would be _very_ useful if resolution of urn:ietf:mediatype:application/xml would redirect to (the appropriate table row of) http://www.iana.org/assignments/media-types/media-types.xhtml, thus enabling a very useful instance of 'follow your nose'. ht [Those for whom the jargon phrase "http-range-14" rings a bell will know that I've glossed over the HTTP-level details of the representation vs. metadata point -- I don't believe the above discussion stands or falls on the resolution (or lack of it) of that issue] [1] http://www.ltg.ed.ac.uk/~ht/persistence.html [2] https://www.w3.org/2001/tag/doc/selfDescribingDocuments.html -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Mon Dec 12 20:06: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 44902129E75 for ; Mon, 12 Dec 2016 20:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-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 Ku5yAic4a1_y for ; Mon, 12 Dec 2016 20:06:36 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DEABB1297BE for ; Mon, 12 Dec 2016 20:06:34 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9892640332; Mon, 12 Dec 2016 21:08:14 -0700 (MST) To: "Henry S. Thompson" References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> From: Peter Saint-Andre Message-ID: <0f786908-3dcf-2c1c-ff64-14ab12228010@stpeter.im> Date: Mon, 12 Dec 2016 21:06:32 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Terminology -- 'resource' and 'abstract designator' 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, 13 Dec 2016 04:06:38 -0000 Henry, thanks for your enlightening message. I shall ponder these matters a bit further before replying in depth. One comment below. On 12/12/16 7:27 AM, Henry S. Thompson wrote: > One last example. Consider the space of (registered) Media Types. They > are certainly not representable as such, they definitely fall into the > category of an enumerated type with externally-specified semantics. > > As such we might well think there _should_ be a URN namespace for them. > Suppose there were, e.g. urn:ietf:mediatype:. If so, then it would be > _very_ useful if resolution of urn:ietf:mediatype:application/xml would > redirect to (the appropriate table row of) > http://www.iana.org/assignments/media-types/media-types.xhtml, thus > enabling a very useful instance of 'follow your nose'. In fact, a few years ago I started defining a URN namespace for IANA registry entries: https://www.ietf.org/archive/id/draft-saintandre-iana-urn-01.txt Although that work got lost in the shuffle during the recently-completed IANA transition, the fact that you mention IANA registry entries as an example of "enumerated types with externally-specified semantics" encourages me to think that we have a shared understanding of the entities under discussion here. More soon. Peter From nobody Wed Dec 14 20: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 8CD8F129F20 for ; Wed, 14 Dec 2016 20:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-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 PValfATmnJwO for ; Wed, 14 Dec 2016 20:04:52 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9F325129F0B for ; Wed, 14 Dec 2016 20:04:52 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 92137400F6; Wed, 14 Dec 2016 21:06:40 -0700 (MST) To: "Henry S. Thompson" References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> From: Peter Saint-Andre Message-ID: Date: Wed, 14 Dec 2016 21:04:50 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Terminology -- 'resource' and 'abstract designator' 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, 15 Dec 2016 04:04:55 -0000 Hi Henry & WG, After pondering this and your follow-up message, I have a few more comments and I would like to propose some textual changes. See inline. On 12/5/16 11:59 PM, Peter Saint-Andre wrote: > Hi Henry, thanks for the continued reviews and feedback. Comments inline. > > On 11/17/16 5:22 AM, Henry S. Thompson wrote: >> There are two parts to this >> >> External: the current use of these terms is incompatible with the >> 3986 >> >> Internal: The definitions and uses of 'abstract designator' are >> inconsistent >> >> TL;DR: >> >> 1) 3986 distinguishes between 'resource' and 'representation', and so >> should we; Agreed. >> 2) The term 'abstract designator' should be dropped. I now think this is the right thing to do. Specifically, this term wasn't doing any work for us because it was used sparingly to no great effect. Better to remove it and reduce the potential for confusion. >> Part 1 -- 3986 incompatibility >> >> URNs are URIs, that is, Uniform Resource Identifiers. Every URI >> identifies something, as the name implies, and 3986 uses the term >> 'resource' as the cover term for _anything_ that is identified by a >> URI. It explicitly places _no_ constraint on what a URI can identify. >> In other words, anything can be a resource: real, imaginary, abstract, >> concrete, individual, set (finite or infinite), ... >> >> The current draft does not define the term 'resource'. It often uses >> it in ways which are consistent with 3986's definition, for example in >> phrases such as "resource identifier" (lower case in original), >> "identified resource", "The kinds of resources identified by URNs" and >> "persistent identification of resources". This longer exposition is >> also pretty much compatible with 3986: >> >> URNs (either individually or entire URN namespaces as defined below) >> that do not resolve to URLs at all or that resolve to metadata or >> non-Internet objects are among URN use cases explicitly permitted by >> this specification; each leaves the concept of "resolution" somewhat >> more abstract and difficult than the simple case of resolution to a >> URL. [1.1, 2nd para] >> >> But the current draft also uses 'resource' in many ways which are >> clearly incompatible with 3986. 3986 is very careful to distinguish >> between the resource _identified_ by a URI on the one hand, and >> _representations_ of that resource and _metadata_ about it on the >> other. The latter are much more concrete, and the kind of thing you >> can get your hands on/interact with (see section 1.2.2 of 3986 [1]). >> Some examples of where the current draft is incompatible with this >> position: >> >> "A URN [may] be ... an abstract designator that is persistent but >> that does not identify a resource" [Abstract, Introduction] >> Per 3986, _all_ URIs identify something, which it calls a resource. > > Good catch. In both cases, I suggest that we remove the phrase "or in some cases an abstract designator that is persistent but that does not identify a resource". >> "media type of those resources" [2.3.3, next-to-last para] >> Per 3986, resources do not in general have media types, >> _representations_, e.g. as returned in messages, have media types. >> >> I don't think this will be hard to fix -- there's already a >> distinction between what is identified and the outcome of a resolution >> attempt, as well as between resolution and retrieval, and the wording >> around these just needs to be tightened up a bit, with the word >> 'resource' used a bit less. Whether the idea behind 3986's word >> 'representation' needs to be imported, along with the word, will I >> think be an editorial decision to be made in the course of the >> tightening-up effort. > > Yes, that all seems right. Here is proposed text... OLD The f-component is primarily intended to distinguish the constituent parts of resources named by URNs. Thus, for URNs that resolve to URLs of the named resources, the semantics of an f-component are defined by the media type of those resources, not by the URN namespace. NEW The f-component is primarily intended to distinguish the constituent parts of resources named by URNs. Thus, for URNs that resolve to locator URIs of the named resources, the semantics of an f-component are defined by the media type of the representations into which those locator URIs are dereferenced, not by the URN namespace. (See below for the paragraph where I introduce the unfamiliar term "locator URI".) >> Part 2 -- 'abstract designator' > > As a bit of background, I would say that we introduced the term > 'abstract designator' to describe names that purely identify resources; > that is, the intent is that such a name will never be resolved (i.e., > there is no access mechanism associated with the name) and, more > specifically, that at no time will it be possible to retrieve a > representation of the identified resource. > >> Here are some examples of the use of this term which taken together >> leave me confused as to what is meant: >> >> A URN [may] be ... an abstract designator that is persistent but >> that does not identify a resource [Abstract, Introduction] > > As you pointed out, this is wrong: every URI identifies a resource. Fixed (see above). >> If there are or will be resolution services available for a URN, >> this document calls the URN a "resource identifier" in roughly the >> sense that term is used in [RFC3986]. If there is no intention to >> provide any resolution services, and the distinction is important, >> this document calls the URN an "abstract designator". [1.2, near the >> end] > > This suffers from the same problem you have pointed out regarding > resource identification. My suggestion is to remove that paragraph in its entirety. >> If the URN does not resolve to a URL (i.e., is an abstract >> designator) or if it resolves directly to an object or a non-URL >> resource designator [2.3.2, 3rd para] [note that this is the only >> use of the phrase 'resource designator' in the draft] >> >> If the URN does not resolve to a URL (e.g., is an abstract >> designator) [2.3.3, 2nd para] >> >> because a URN might not specify the location of a resource or even >> point indirectly to one [4.1, 2nd para] >> >> (e.g., URNs within some URN namespaces are intended to act as >> abstract designators and thus are not intended to be resolved) >> [6.4.6 1st para] >> >> Clarified that there can be URNs that neither resolve to URLs nor >> are abstract designators. [F.8., 6th bullet. I _think_ this refers >> to the quote above from section 2.3.2] In line with your previous message on URL vs. locator, I suggest that we modify the terminology in those snippets. You can get a feeling for how I propose to change things by reading the following paragraph: OLD The URN q-component has the same syntax as the URI query component, but is introduced by "?=", not "?" alone. For URNs that may be resolved to a URL, the semantics of the q-component are identical to those for the query component of that URL. Thus URN resolvers returning a URL for a URN with a q-component do this by copying the q-component from the URN 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. An example of the copying operation appears below. NEW The URN q-component has the same syntax as the query component in URI schemes for locators, but is introduced by "?=", not "?" alone. For URNs that may be resolved to a locator URI, the semantics of the q-component are identical to those for the query component of that URI. Thus URN resolvers returning a locator URI for a URN with a q-component do this by copying the q-component from the URN to the query component of the locator URI. If the URN does not resolve to a locator URI, the interpretation of the q-component is undefined by this specification. An example of the copying operation appears below. >> It is often argued that 3986 implies that there are two in-principle >> possibilities for any URI (including URNs) as far as resolution is >> concerned (where the possibility that resolution may involve more than >> one step is assumed): >> >> 1) Resolution services are or could be provided, but the results of >> resolution necessarily consist only of metadata about the >> identified resource, that is, no _representation_ of that >> resource is or could be available; > > I'd like to understand more about what 'metadata' means here. > > RFC 3986 says the following in Section 1.2.2: > > A "representation" is a > sequence of octets, along with representation metadata describing > those octets, that constitutes a record of the state of the resource > at the time when the representation is generated. > > Here, 'metadata' mean metadata about the representation. If there is no > representation, there can be no representation metadata. > > However, later in the same paragraph we find this: > > Depending on the protocols used to perform the retrieval, > additional information might be supplied about the resource (resource > metadata) and its relation to other resources. > > This might indicate that RFC 3986 envisions a distinction between > representation metadata (metadata describing the octets, as in MIME, see > Section 5.1.2) and resource metadata (metadata describing the resource > itself - perhaps an example would be Dublin Core information about > authors, publishers, licenses, and the like). However, even the notion > of resource metadata here seems to be tied to retrieval. > >> 2) Resolution services are or could be provided, and the results of >> resolution may in practice and could in principle include one or >> more representations. >> >> However I think the above quotes from the current draft taken together >> provide evidence that it considers there to be a >> _threefold_ distinction, adding >> >> 3) No resolution services of any kind are provided or envisaged; > > Yes. Although I am not 100% sure that we still need category (3), I _think_ it remains useful. To (I hope) clarify these issues, I propose the following text change in Section 1.1: OLD Among these general issues, one that is specific to URNs is the fairly abstract topic of "resolution", discussed in Section 1.2, Section 2.3.1, and elsewhere below. It is possible to define the relationships quite precisely for a URN that resolves to a URL, where that URL in turn resolves to (or locates) a single target document or similar resource; however, that is only one special case (albeit an important one). URNs (either individually or entire URN namespaces as defined below) that do not resolve to URLs at all or that resolve to metadata or non-Internet objects are among URN use cases explicitly permitted by this specification; each leaves the concept of "resolution" somewhat more abstract and difficult than the simple case of resolution to a URL. NEW Among these general issues, one that is specific to URNs is the fairly difficult topic of "resolution", discussed in Section 1.2, Section 2.3.1, Section 6.4.6, and elsewhere below. By contrast, resolution is relatively straightforward for traditional Uniform Resource Locators (URLs), or at least for most URI schemes for locators, because resolution is used to determine an access mechanism which in turn is used to dereference the locator by (typically) retrieving a representation of the associated resource (see Section 1.2.2 of [RFC3986]). Consequently, it is possible to define the relevant relationships quite precisely for URNs that resolve to locators (such as URLs) which in turn are dereferenced to a representation (such as a target document); however, that is only one particular case, albeit an important one. This specification permits several other kinds of URNs, either individually or (as defined below) collectively for entire URN namespaces. In particular, some URNs might resolve to locators which in turn are dereferenced only to metadata about the resource, not to a representation of that resource; an example might be a URN namespace for cataloging of information resources. Furthermore, some URNs might not be intended to resolve to locators at all; examples might include URNs identifying XML namespace names (e.g., the 'dgiwg' URN namespace specified by [RFC6288]), URNs identifying application features that can be supported within a communications protocol (e.g., the 'alert' URN namespace specified by [RFC7462]), and URNs identifying enumerated types such as values in a registry (e.g., a URN namespace could be used to individually identify the values in all IANA registries, as provisionally proposed in [I-D.saintandre-iana-urn]). These types of URNs leave the concept of "resolution" somewhat more difficult than the straightforward case of resolution to a locator that is dereferenced to a representation. (On the distinction between names and locators, see Section 1.1.3 of [RFC3986]; on the distinction between representations and metadata, see Section 1.2.2 of [RFC3986].) As you can see, that text adds some examples and makes more careful distinctions, which I think are helpful (even absent the potentially confusing term "abstract designator"). Comments are welcome. Peter P.S. Please note that I have not yet talked with my co-author about these proposed changes, so all errors are mine. P.P.S. If you like source control, you can see the work-in-progress changes here: https://github.com/stpeter/urnbis/commits/master/draft-ietf-urnbis-rfc2141bis-urn.xml (naturally, these are only provisional, and I'd prefer to keep discussion on this list instead of at GitHub). From nobody Wed Dec 14 21:40: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 850DA128DF6 for ; Wed, 14 Dec 2016 21:40:22 -0800 (PST) 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 sagoW-i_cp54 for ; Wed, 14 Dec 2016 21:40:18 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30108.outbound.protection.outlook.com [40.107.3.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C3112944E for ; Wed, 14 Dec 2016 21:40:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/kwkirsEsixiNQ915TkaGpcHC6Ac2Jk7K61/pUOR9v0=; b=Ro7vGsNqlc/MJDJ4rlt7WiNx+sO1NV0Ba5DeWqZyLfbRraduct/IPG9QC17pkFWmVPA4z8m9pWX67gT58p2+n/7VnK9PWe0gUNAgfVn9Fye5krvjllUQajYm+HjuQZwqZ3fVXZt96sxgjU7aOvUr/0mGxKv7tsljJmtQskUwxxE= Received: from HE1PR0701MB2603.eurprd07.prod.outlook.com (10.168.187.138) by HE1PR0701MB2604.eurprd07.prod.outlook.com (10.168.187.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.5; Thu, 15 Dec 2016 05:40:14 +0000 Received: from HE1PR0701MB2603.eurprd07.prod.outlook.com ([10.168.187.138]) by HE1PR0701MB2603.eurprd07.prod.outlook.com ([10.168.187.138]) with mapi id 15.01.0789.009; Thu, 15 Dec 2016 05:40:15 +0000 From: "Hakala, Juha E" To: Peter Saint-Andre , "Henry S. Thompson" Thread-Topic: [urn] Terminology -- 'resource' and 'abstract designator' Thread-Index: AQHSQNWkB/nqqt+K1EWT6PS4OxGR26D6mvMAgA30JACAABJjYA== Date: Thu, 15 Dec 2016 05:40:14 +0000 Message-ID: References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> In-Reply-To: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [91.152.63.126] x-ms-office365-filtering-correlation-id: a5a9923d-412c-46a8-67fc-08d424acd87f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0701MB2604; x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2604; 7:Rf16RS9nNkUULZAYVGP0v+2Tf09cFmZnAEg2Qoc0WcxOxkpbERunjIvgTbcL1+WTocBNhCKcUUx9MAYAMIvf/XZoeAxjuAc7s3LZJXVONtH1qKz+YcDw4xYwvECKojOeunq9cN3eDahKIvzWznxM5BWRGzgoO0YJ5KaADm6TV3u5P4uQxoDG1E30iapZklADmydMz7/J+Ehqydy/WrJIotlJF9I7LaJbZo8xfYwuDiXGLIWV/xXEjge6e2uHcvYROPLwXGlrDKRs2KnwHspUN1YXCEIk0FpgbFGyBZ+igSbcgsl5JsUygnJw753CvLeUxxeGGUf8x+hWTBwGi7o/z087hsXcgKhHLozy5lsntMMxB3kdCY6LZrZoWtRPUWX7xcjpPeIx7ztZYHAa9IM/tWJgbfUClvXzykUodRPrW/TzM7TaO9m/h5tWaRl0lI81h5uj4uwyuoq+8l3CaBgi9w== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(35073007944872)(181193635805523); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558021)(6072148); SRVR:HE1PR0701MB2604; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2604; x-forefront-prvs: 0157DEB61B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(199003)(13464003)(24454002)(51914003)(377454003)(189002)(66066001)(2950100002)(102836003)(9686002)(122556002)(3846002)(77096006)(8676002)(101416001)(6436002)(6116002)(25786008)(74316002)(74482002)(8936002)(81166006)(3660700001)(93886004)(33656002)(76576001)(3280700002)(4326007)(2900100001)(38730400001)(7736002)(305945005)(50986999)(54356999)(97736004)(81156014)(5660300001)(86362001)(76176999)(6506006)(68736007)(229853002)(2906002)(7696004)(189998001)(106356001)(5001770100001)(92566002)(105586002)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2604; H:HE1PR0701MB2603.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 15 Dec 2016 05:40:14.8883 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2604 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Terminology -- 'resource' and 'abstract designator' 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, 15 Dec 2016 05:40:22 -0000 Hi Peter,=20 I approve the changes you have made, including the removal of abstract desi= gnator. I was never a great fan of that concept.=20 One point we need to make very clear is that the terms "resource" and "iden= tify" are used throughout RFC2141bis as specified in URI syntax, unless oth= erwise said. And that the RFC 3986 definitions of those terms may differ a = lot from those traditionally used in some domains which are involved with r= esource identification. Any librarian will have a problem with "every URI i= dentifies a resource" unless he knows how RFC 3986 defines these concepts (= and how people understand what RFC 3986 stipulations).=20 Henry has already clarified the meaning of resource in RFC 3986. As regards= identification, URI syntax says that=20 Our use of the terms "identify" and "identifying" refer to this purpose of distinguishing one resource from all other resources, regardless of how that purpose is accomplished (e.g., by name, address, or context). These terms should not be mistaken as an assumption that an identifier defines or embodies the identity of what is referenced, though that may be the case for some identifiers. And because of this, my email address identifies me according to RFC 3986. = Whether email addresses are good (note that the RFC 3986 definition does no= t require persistence) identifiers even from the liberal RFC 3986 point of = view is a different issue which does not need to be discussed here.=20 Juha=20 > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Peter Saint-Andre > Sent: 15. joulukuuta 2016 6:05 > To: Henry S. Thompson > Cc: urn@ietf.org > Subject: Re: [urn] Terminology -- 'resource' and 'abstract designator' >=20 > Hi Henry & WG, >=20 > After pondering this and your follow-up message, I have a few more > comments and I would like to propose some textual changes. See inline. >=20 > On 12/5/16 11:59 PM, Peter Saint-Andre wrote: > > Hi Henry, thanks for the continued reviews and feedback. Comments > inline. > > > > On 11/17/16 5:22 AM, Henry S. Thompson wrote: > >> There are two parts to this > >> > >> External: the current use of these terms is incompatible with the > >> 3986 > >> > >> Internal: The definitions and uses of 'abstract designator' are > >> inconsistent > >> > >> TL;DR: > >> > >> 1) 3986 distinguishes between 'resource' and 'representation', and so > >> should we; >=20 > Agreed. >=20 > >> 2) The term 'abstract designator' should be dropped. >=20 > I now think this is the right thing to do. Specifically, this term wasn't= doing any > work for us because it was used sparingly to no great effect. Better to > remove it and reduce the potential for confusion. >=20 > >> Part 1 -- 3986 incompatibility > >> > >> URNs are URIs, that is, Uniform Resource Identifiers. Every URI > >> identifies something, as the name implies, and 3986 uses the term > >> 'resource' as the cover term for _anything_ that is identified by a > >> URI. It explicitly places _no_ constraint on what a URI can identify. > >> In other words, anything can be a resource: real, imaginary, > >> abstract, concrete, individual, set (finite or infinite), ... > >> > >> The current draft does not define the term 'resource'. It often uses > >> it in ways which are consistent with 3986's definition, for example > >> in phrases such as "resource identifier" (lower case in original), > >> "identified resource", "The kinds of resources identified by URNs" > >> and "persistent identification of resources". This longer exposition > >> is also pretty much compatible with 3986: > >> > >> URNs (either individually or entire URN namespaces as defined below) > >> that do not resolve to URLs at all or that resolve to metadata or > >> non-Internet objects are among URN use cases explicitly permitted by > >> this specification; each leaves the concept of "resolution" somewhat > >> more abstract and difficult than the simple case of resolution to a > >> URL. [1.1, 2nd para] > >> > >> But the current draft also uses 'resource' in many ways which are > >> clearly incompatible with 3986. 3986 is very careful to distinguish > >> between the resource _identified_ by a URI on the one hand, and > >> _representations_ of that resource and _metadata_ about it on the > >> other. The latter are much more concrete, and the kind of thing you > >> can get your hands on/interact with (see section 1.2.2 of 3986 [1]). > >> Some examples of where the current draft is incompatible with this > >> position: > >> > >> "A URN [may] be ... an abstract designator that is persistent but > >> that does not identify a resource" [Abstract, Introduction] > >> Per 3986, _all_ URIs identify something, which it calls a resource. > > > > Good catch. >=20 > In both cases, I suggest that we remove the phrase "or in some cases an > abstract designator that is persistent but that does not identify a resou= rce". >=20 > >> "media type of those resources" [2.3.3, next-to-last para] > >> Per 3986, resources do not in general have media types, > >> _representations_, e.g. as returned in messages, have media types. > >> > >> I don't think this will be hard to fix -- there's already a > >> distinction between what is identified and the outcome of a > >> resolution attempt, as well as between resolution and retrieval, and > >> the wording around these just needs to be tightened up a bit, with > >> the word 'resource' used a bit less. Whether the idea behind 3986's > >> word 'representation' needs to be imported, along with the word, will > >> I think be an editorial decision to be made in the course of the > >> tightening-up effort. > > > > Yes, that all seems right. >=20 > Here is proposed text... >=20 > OLD > The f-component is primarily intended to distinguish the constituent > parts of resources named by URNs. Thus, for URNs that resolve to > URLs of the named resources, the semantics of an f-component are > defined by the media type of those resources, not by the URN > namespace. >=20 > NEW > The f-component is primarily intended to distinguish the constituent > parts of resources named by URNs. Thus, for URNs that resolve to > locator URIs of the named resources, the semantics of an f-component > are defined by the media type of the representations into which those > locator URIs are dereferenced, not by the URN namespace. >=20 > (See below for the paragraph where I introduce the unfamiliar term "locat= or > URI".) >=20 > >> Part 2 -- 'abstract designator' > > > > As a bit of background, I would say that we introduced the term > > 'abstract designator' to describe names that purely identify > > resources; that is, the intent is that such a name will never be > > resolved (i.e., there is no access mechanism associated with the name) > > and, more specifically, that at no time will it be possible to > > retrieve a representation of the identified resource. > > > >> Here are some examples of the use of this term which taken together > >> leave me confused as to what is meant: > >> > >> A URN [may] be ... an abstract designator that is persistent but > >> that does not identify a resource [Abstract, Introduction] > > > > As you pointed out, this is wrong: every URI identifies a resource. >=20 > Fixed (see above). >=20 > >> If there are or will be resolution services available for a URN, > >> this document calls the URN a "resource identifier" in roughly the > >> sense that term is used in [RFC3986]. If there is no intention to > >> provide any resolution services, and the distinction is important, > >> this document calls the URN an "abstract designator". [1.2, near the > >> end] > > > > This suffers from the same problem you have pointed out regarding > > resource identification. >=20 > My suggestion is to remove that paragraph in its entirety. >=20 > >> If the URN does not resolve to a URL (i.e., is an abstract > >> designator) or if it resolves directly to an object or a non-URL > >> resource designator [2.3.2, 3rd para] [note that this is the only > >> use of the phrase 'resource designator' in the draft] > >> > >> If the URN does not resolve to a URL (e.g., is an abstract > >> designator) [2.3.3, 2nd para] > >> > >> because a URN might not specify the location of a resource or even > >> point indirectly to one [4.1, 2nd para] > >> > >> (e.g., URNs within some URN namespaces are intended to act as > >> abstract designators and thus are not intended to be resolved) > >> [6.4.6 1st para] > >> > >> Clarified that there can be URNs that neither resolve to URLs nor > >> are abstract designators. [F.8., 6th bullet. I _think_ this refers > >> to the quote above from section 2.3.2] >=20 > In line with your previous message on URL vs. locator, I suggest that we > modify the terminology in those snippets. You can get a feeling for how I > propose to change things by reading the following paragraph: >=20 > OLD > The URN q-component has the same syntax as the URI query component, > but is introduced by "?=3D", not "?" alone. For URNs that may be > resolved to a URL, the semantics of the q-component are identical to > those for the query component of that URL. Thus URN resolvers > returning a URL for a URN with a q-component do this by copying the > q-component from the URN 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. An example of the copying > operation appears below. >=20 > NEW > The URN q-component has the same syntax as the query component in > URI > schemes for locators, but is introduced by "?=3D", not "?" alone. Fo= r > URNs that may be resolved to a locator URI, the semantics of the > q-component are identical to those for the query component of that > URI. Thus URN resolvers returning a locator URI for a URN with a > q-component do this by copying the q-component from the URN to the > query component of the locator URI. If the URN does not resolve to a > locator URI, the interpretation of the q-component is undefined by > this specification. An example of the copying operation appears > below. >=20 > >> It is often argued that 3986 implies that there are two in-principle > >> possibilities for any URI (including URNs) as far as resolution is > >> concerned (where the possibility that resolution may involve more > >> than one step is assumed): > >> > >> 1) Resolution services are or could be provided, but the results of > >> resolution necessarily consist only of metadata about the > >> identified resource, that is, no _representation_ of that > >> resource is or could be available; > > > > I'd like to understand more about what 'metadata' means here. > > > > RFC 3986 says the following in Section 1.2.2: > > > > A "representation" is a > > sequence of octets, along with representation metadata describing > > those octets, that constitutes a record of the state of the resource > > at the time when the representation is generated. > > > > Here, 'metadata' mean metadata about the representation. If there is > > no representation, there can be no representation metadata. > > > > However, later in the same paragraph we find this: > > > > Depending on the protocols used to perform the retrieval, > > additional information might be supplied about the resource (resourc= e > > metadata) and its relation to other resources. > > > > This might indicate that RFC 3986 envisions a distinction between > > representation metadata (metadata describing the octets, as in MIME, > > see Section 5.1.2) and resource metadata (metadata describing the > > resource itself - perhaps an example would be Dublin Core information > > about authors, publishers, licenses, and the like). However, even the > > notion of resource metadata here seems to be tied to retrieval. > > > >> 2) Resolution services are or could be provided, and the results of > >> resolution may in practice and could in principle include one or > >> more representations. > >> > >> However I think the above quotes from the current draft taken > >> together provide evidence that it considers there to be a _threefold_ > >> distinction, adding > >> > >> 3) No resolution services of any kind are provided or envisaged; > > > > Yes. >=20 > Although I am not 100% sure that we still need category (3), I _think_ it > remains useful. >=20 > To (I hope) clarify these issues, I propose the following text change in = Section > 1.1: >=20 > OLD > Among these general issues, one that is specific to URNs is the > fairly abstract topic of "resolution", discussed in Section 1.2, > Section 2.3.1, and elsewhere below. It is possible to define the > relationships quite precisely for a URN that resolves to a URL, where > that URL in turn resolves to (or locates) a single target document or > similar resource; however, that is only one special case (albeit an > important one). URNs (either individually or entire URN namespaces > as defined below) that do not resolve to URLs at all or that resolve > to metadata or non-Internet objects are among URN use cases > explicitly permitted by this specification; each leaves the concept > of "resolution" somewhat more abstract and difficult than the simple > case of resolution to a URL. >=20 > NEW > Among these general issues, one that is specific to URNs is the > fairly difficult topic of "resolution", discussed in Section 1.2, > Section 2.3.1, Section 6.4.6, and elsewhere below. By contrast, > resolution is relatively straightforward for traditional Uniform > Resource Locators (URLs), or at least for most URI schemes for > locators, because resolution is used to determine an access mechanism > which in turn is used to dereference the locator by (typically) > retrieving a representation of the associated resource (see > Section 1.2.2 of [RFC3986]). Consequently, it is possible to define > the relevant relationships quite precisely for URNs that resolve to > locators (such as URLs) which in turn are dereferenced to a > representation (such as a target document); however, that is only one > particular case, albeit an important one. This specification permits > several other kinds of URNs, either individually or (as defined > below) collectively for entire URN namespaces. In particular, some > URNs might resolve to locators which in turn are dereferenced only to > metadata about the resource, not to a representation of that > resource; an example might be a URN namespace for cataloging of > information resources. Furthermore, some URNs might not be intended > to resolve to locators at all; examples might include URNs > identifying XML namespace names (e.g., the 'dgiwg' URN namespace > specified by [RFC6288]), URNs identifying application features that > can be supported within a communications protocol (e.g., the 'alert' > URN namespace specified by [RFC7462]), and URNs identifying > enumerated types such as values in a registry (e.g., a URN namespace > could be used to individually identify the values in all IANA > registries, as provisionally proposed in [I-D.saintandre-iana-urn]). > These types of URNs leave the concept of "resolution" somewhat more > difficult than the straightforward case of resolution to a locator > that is dereferenced to a representation. (On the distinction > between names and locators, see Section 1.1.3 of [RFC3986]; on the > distinction between representations and metadata, see Section 1.2.2 > of [RFC3986].) >=20 > As you can see, that text adds some examples and makes more careful > distinctions, which I think are helpful (even absent the potentially conf= using > term "abstract designator"). >=20 > Comments are welcome. >=20 > Peter >=20 > P.S. Please note that I have not yet talked with my co-author about these > proposed changes, so all errors are mine. >=20 > P.P.S. If you like source control, you can see the work-in-progress chang= es > here: > https://github.com/stpeter/urnbis/commits/master/draft-ietf-urnbis- > rfc2141bis-urn.xml > (naturally, these are only provisional, and I'd prefer to keep discussion= on this > list instead of at GitHub). >=20 >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Thu Dec 15 00:56: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 60E2512954D for ; Thu, 15 Dec 2016 00:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 IarPbnGxu8Gf for ; Thu, 15 Dec 2016 00:56:01 -0800 (PST) Received: from seine.is.ed.ac.uk (seine.is.ed.ac.uk [129.215.17.202]) by ietfa.amsl.com (Postfix) with ESMTP id 48D0C129417 for ; Thu, 15 Dec 2016 00:56:00 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by seine.is.ed.ac.uk (8.14.7/8.14.6) with ESMTP id uBF8trS4023654; Thu, 15 Dec 2016 08:55:54 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id uBF8trvC013082; Thu, 15 Dec 2016 08:55:53 GMT 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 uBF8tqxR023518; Thu, 15 Dec 2016 08:55:52 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id uBF8tpPH023517; Thu, 15 Dec 2016 08:55:52 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: "Hakala\, Juha E" References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 15 Dec 2016 08:55:51 +0000 In-Reply-To: (Juha E. Hakala's message of "Thu\, 15 Dec 2016 05\:40\:14 +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 seine.is.ed.ac.uk with MIMEDefang 2.78, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.78 on 129.215.17.202 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Terminology -- 'resource' and 'abstract designator' 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, 15 Dec 2016 08:56:04 -0000 Hakala, Juha E writes: > I approve the changes you have made, including the removal of abstract > designator. I was never a great fan of that concept. And I'm happy with all those changes as well. > One point we need to make very clear is that the terms "resource" and > "identify" are used throughout RFC2141bis as specified in URI syntax, > unless otherwise said. And that the RFC 3986 definitions of those > terms may differ a lot from those traditionally used in some domains > which are involved with resource identification. Any librarian will > have a problem with "every URI identifies a resource" unless he knows > how RFC 3986 defines these concepts (and how people understand what > RFC 3986 stipulations). > > Henry has already clarified the meaning of resource in RFC 3986. As > regards identification, URI syntax says that > > Our use of the terms "identify" and "identifying" refer to this > purpose of distinguishing one resource from all other resources, > regardless of how that purpose is accomplished (e.g., by name, > address, or context). These terms should not be mistaken as an > assumption that an identifier defines or embodies the identity > of what is referenced, though that may be the case for some > identifiers. Quoting, paraphrasing and/or referencing this would be a sensible thing to do, I agree. 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 Dec 18 10:33: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 0EE43129546 for ; Sun, 18 Dec 2016 10:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-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 IQfgXya16mWD for ; Sun, 18 Dec 2016 10:33:33 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A5C6C1293FD for ; Sun, 18 Dec 2016 10:33:33 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C45234010C; Sun, 18 Dec 2016 11:35:36 -0700 (MST) To: "Henry S. Thompson" , "Hakala, Juha E" References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> From: Peter Saint-Andre Message-ID: Date: Sun, 18 Dec 2016 11:33:31 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Terminology -- 'resource' and 'abstract designator' 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, 18 Dec 2016 18:33:35 -0000 On 12/15/16 1:55 AM, Henry S. Thompson wrote: > Hakala, Juha E writes: > >> I approve the changes you have made, including the removal of abstract >> designator. I was never a great fan of that concept. > > And I'm happy with all those changes as well. Great! Thanks to you both for reviewing the proposed text. >> One point we need to make very clear is that the terms "resource" and >> "identify" are used throughout RFC2141bis as specified in URI syntax, >> unless otherwise said. And that the RFC 3986 definitions of those >> terms may differ a lot from those traditionally used in some domains >> which are involved with resource identification. Any librarian will >> have a problem with "every URI identifies a resource" unless he knows >> how RFC 3986 defines these concepts (and how people understand what >> RFC 3986 stipulations). >> >> Henry has already clarified the meaning of resource in RFC 3986. As >> regards identification, URI syntax says that >> >> Our use of the terms "identify" and "identifying" refer to this >> purpose of distinguishing one resource from all other resources, >> regardless of how that purpose is accomplished (e.g., by name, >> address, or context). These terms should not be mistaken as an >> assumption that an identifier defines or embodies the identity >> of what is referenced, though that may be the case for some >> identifiers. > > Quoting, paraphrasing and/or referencing this would be a sensible thing > to do, I agree. Pointing to it seems like the right thing to do. I suggest that we add the following sentence to Section 1.2: This document uses the terms "resource", "identifier", "identify", "dereference", "representation", and "metadata" as defined in the URI specification [RFC3986]. Peter From nobody Sun Dec 18 10:41: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 905F51294B0 for ; Sun, 18 Dec 2016 10:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 MQ4FiOj-qVfd for ; Sun, 18 Dec 2016 10:41:12 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00FB1293FD for ; Sun, 18 Dec 2016 10:41:11 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cIgOH-000AZt-Gc; Sun, 18 Dec 2016 13:40:57 -0500 Date: Sun, 18 Dec 2016 13:40:51 -0500 From: John C Klensin To: Peter Saint-Andre , "Henry S. Thompson" , "Hakala, Juha E" Message-ID: In-Reply-To: References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.70 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] Terminology -- 'resource' and 'abstract designator' 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, 18 Dec 2016 18:41:13 -0000 --On Sunday, December 18, 2016 11:33 -0700 Peter Saint-Andre wrote: >> Quoting, paraphrasing and/or referencing this would be a >> sensible thing to do, I agree. > > Pointing to it seems like the right thing to do. I suggest > that we add the following sentence to Section 1.2: > > This document uses the terms "resource", "identifier", > "identify", > "dereference", "representation", and "metadata" as defined > in the URI > specification [RFC3986]. I think the principle is correct. However, unless there is a great deal more consensus about what 3986 says and what the words mean than I'm seeing, please be very careful about this. More follows as soon as I get my desktop machine rebuilt (getting close). john From nobody Sun Dec 18 10:42: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 0A22A1294B0 for ; Sun, 18 Dec 2016 10:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-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 QGOafdFAHsPO for ; Sun, 18 Dec 2016 10:42:32 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 05E0B1293FD for ; Sun, 18 Dec 2016 10:42:32 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9CDCA4010C; Sun, 18 Dec 2016 11:44:35 -0700 (MST) To: John C Klensin , "Henry S. Thompson" , "Hakala, Juha E" References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> From: Peter Saint-Andre Message-ID: <514aa135-c18b-31e1-ded6-fded9686ca67@stpeter.im> Date: Sun, 18 Dec 2016 11:42:29 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Terminology -- 'resource' and 'abstract designator' 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, 18 Dec 2016 18:42:33 -0000 On 12/18/16 11:40 AM, John C Klensin wrote: > > > --On Sunday, December 18, 2016 11:33 -0700 Peter Saint-Andre > wrote: > >>> Quoting, paraphrasing and/or referencing this would be a >>> sensible thing to do, I agree. >> >> Pointing to it seems like the right thing to do. I suggest >> that we add the following sentence to Section 1.2: >> >> This document uses the terms "resource", "identifier", >> "identify", >> "dereference", "representation", and "metadata" as defined >> in the URI >> specification [RFC3986]. > > I think the principle is correct. However, unless there is a > great deal more consensus about what 3986 says and what the > words mean than I'm seeing, please be very careful about this. Yes, we have been careful about that with other terms: This document uses the terms "resolution" and "resolver" in roughly the sense in which they were used in the original discussion of architectural principles for URNs [RFC2276] We could provide similar text here. Peter From nobody Wed Dec 21 03:27: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 A0512129556 for ; Wed, 21 Dec 2016 03:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 ctnzvqR5CEvX for ; Wed, 21 Dec 2016 03:27:05 -0800 (PST) Received: from mail.dnb.de (prodfix-out0.dnb.de [193.175.100.144]) (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 0D36D129554 for ; Wed, 21 Dec 2016 03:27:04 -0800 (PST) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by mail.dnb.de (Postfix) with ESMTP id BF37347BC986; Wed, 21 Dec 2016 12:27:02 +0100 (CET) X-AuditID: 0a453fe7-159ff70000000f1b-8b-585a6703b656 Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id D0.74.03867.3076A585; Wed, 21 Dec 2016 12:27:02 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0224.002; Wed, 21 Dec 2016 12:26:58 +0100 From: "Svensson, Lars" To: Peter Saint-Andre Thread-Topic: [urn] Terminology -- 'resource' and 'abstract designator' Thread-Index: AQHSVohpMRXG3Sb6okuGuXmF0SM8/KESSMzA Date: Wed, 21 Dec 2016 11:26:57 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF010D2AA515@dnbf-ex1.AD.DDB.DE> References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.97] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILsWRmVeSWpSXmKPExsXC5Wr/VZctPSrCoHOqnMWxPf3MFlObPzA5 MHksWfKTyWPunhfMAUxRXDYpqTmZZalF+nYJXBk3uu+yFvRYVDS3fWdrYJyu3cXIwSEhYCJx 9Yx4FyMXh5DAYUaJU/sbmSGc7YwSH0+/YepiZOdgE9CSeJ/RxcjJIQJkXbrWxw5iMwsoSmy6 P4UJxBYWcJPYdOYeK0SNu8TtWYugbCOJud9fsIDYLAKqElcmdzGC2LwC3hIL9lxhg1h1gVFi 37W1YEWcAnYSHy8dBitiFJCV2LDhPDPEMnGJTc++gw2VEBCQWLIHIi4hICrx8vE/qLiCxJ4H 29gg6g0k3p+bD9WrLbFs4WtmiMWCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypGvuLcdEO9 xBS9lJQkvZTUTYyQuHi+g7HvksshRgEORiUe3ic2kRFCrIllxZW5hxj9OZiURHkn/QQK8SXl p1RmJBZnxBeV5qQWK4nwPkyKihDihQsnleZkK8nxSnkARcXhosWlxQWZyZn5pcXxpUU5hxgl OJiBWu1SQVpTEiurUovyIQYeYpTmYFES5325jyFCSCA9sSQ1OzW1ILUIJhvBwaEkwbsPpFGw KDU9tSItM6cEJg3UJwVyjQCyDNhBirzLgoASUsgS6G5i4uA8xOjDwQN02DGww4oLEnOLM9Oh Zgvz8sUBRXlgomBzZXnPugMFxWCCqGaeYgyWEuc9kwJyEkhFRmke3K1SYrxGheERQvxIEiAj pRR4VVoDIoQkkcRRTX3F6AmMImHe/SBH8gBzFMKNQrzyIEFuqCDYiTK8HKC4EIWKoZvlA4xb Ed6F3eEgD5ckliB7+I472MNQUaiHr0A8DBVENU6qgdFuRmbehvjP/Lxe0g/aTtbKhDFNN3iv 1Lj78J9T6w8Lqv/Osis/Yb6Nf9L2bxtDOGLXZq6ZcC5Pb1P42w6ts9+kDZ5kGV2Je/Rle05e dYuyPsvVmeUnigpTM56v0pn89JZWRdBV/yf186KzGp8s1ij71qq95p3BTCnuy4GpZevWOqUk cbXmvFZiKc5INNRiLipOBAChd0xVdAQAAA== Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Terminology -- 'resource' and 'abstract designator' 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, 21 Dec 2016 11:27:08 -0000 Peter, WG, On Thursday, December 15, 2016 5:05 AM, urn [mailto:urn-bounces@ietf.org] O= n Behalf Of Peter Saint-Andre wrote: > >> "A URN [may] be ... an abstract designator that is persistent but > >> that does not identify a resource" [Abstract, Introduction] > >> Per 3986, _all_ URIs identify something, which it calls a resource. > > > > Good catch. >=20 > In both cases, I suggest that we remove the phrase "or in some cases an > abstract designator that is persistent but that does not identify a > resource". This change is fine with me. [...] > Here is proposed text... >=20 > OLD > The f-component is primarily intended to distinguish the constituent > parts of resources named by URNs. Thus, for URNs that resolve to > URLs of the named resources, the semantics of an f-component are > defined by the media type of those resources, not by the URN > namespace. >=20 > NEW > The f-component is primarily intended to distinguish the constituent > parts of resources named by URNs. Thus, for URNs that resolve to > locator URIs of the named resources, the semantics of an f-component > are defined by the media type of the representations into which those > locator URIs are dereferenced, not by the URN namespace. >=20 This is fine with me, too. > >> Part 2 -- 'abstract designator' [...] =20 > OLD > The URN q-component has the same syntax as the URI query component, > but is introduced by "?=3D", not "?" alone. For URNs that may be > resolved to a URL, the semantics of the q-component are identical to > those for the query component of that URL. Thus URN resolvers > returning a URL for a URN with a q-component do this by copying the > q-component from the URN 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. An example of the copying > operation appears below. >=20 > NEW > The URN q-component has the same syntax as the query component in URI > schemes for locators, but is introduced by "?=3D", not "?" alone. Fo= r > URNs that may be resolved to a locator URI, the semantics of the > q-component are identical to those for the query component of that > URI. Thus URN resolvers returning a locator URI for a URN with a > q-component do this by copying the q-component from the URN to the > query component of the locator URI. If the URN does not resolve to a > locator URI, the interpretation of the q-component is undefined by > this specification. An example of the copying operation appears > below. > Here I don't quite agree with "The URN q-component has the same syntax as t= he query component in URI schemes for locators". That text implies that URI= schemes that are not for locators have a different query component syntax.= My suggestion would be to accept Peter's new version but keep the first se= ntence unchanged: [[ The URN q-component has the same syntax as the URI query component, but is = introduced by "?=3D", not "?" alone. For URNs that may be resolved to = a locator URI, the semantics of the q-component are identical to those for = the query component of that URI. Thus URN resolvers returning a locator UR= I for a URN with a q-component do this by copying the q-component from the = URN to the query component of the locator URI. If the URN does not resolve= to a locator URI, the interpretation of the q-component is undefined by th= is specification. An example of the copying operation appears below. ]] [...] > OLD > Among these general issues, one that is specific to URNs is the > fairly abstract topic of "resolution", discussed in Section 1.2, > Section 2.3.1, and elsewhere below. It is possible to define the > relationships quite precisely for a URN that resolves to a URL, where > that URL in turn resolves to (or locates) a single target document or > similar resource; however, that is only one special case (albeit an > important one). URNs (either individually or entire URN namespaces > as defined below) that do not resolve to URLs at all or that resolve > to metadata or non-Internet objects are among URN use cases > explicitly permitted by this specification; each leaves the concept > of "resolution" somewhat more abstract and difficult than the simple > case of resolution to a URL. >=20 > NEW > Among these general issues, one that is specific to URNs is the > fairly difficult topic of "resolution", discussed in Section 1.2, > Section 2.3.1, Section 6.4.6, and elsewhere below. By contrast, > resolution is relatively straightforward for traditional Uniform > Resource Locators (URLs), or at least for most URI schemes for > locators, because resolution is used to determine an access mechanism > which in turn is used to dereference the locator by (typically) > retrieving a representation of the associated resource (see > Section 1.2.2 of [RFC3986]). Consequently, it is possible to define > the relevant relationships quite precisely for URNs that resolve to > locators (such as URLs) which in turn are dereferenced to a > representation (such as a target document); however, that is only one > particular case, albeit an important one. This specification permits > several other kinds of URNs, either individually or (as defined > below) collectively for entire URN namespaces. In particular, some > URNs might resolve to locators which in turn are dereferenced only to > metadata about the resource, not to a representation of that > resource; an example might be a URN namespace for cataloging of > information resources. Furthermore, some URNs might not be intended > to resolve to locators at all; examples might include URNs > identifying XML namespace names (e.g., the 'dgiwg' URN namespace > specified by [RFC6288]), URNs identifying application features that > can be supported within a communications protocol (e.g., the 'alert' > URN namespace specified by [RFC7462]), and URNs identifying > enumerated types such as values in a registry (e.g., a URN namespace > could be used to individually identify the values in all IANA > registries, as provisionally proposed in [I-D.saintandre-iana-urn]). > These types of URNs leave the concept of "resolution" somewhat more > difficult than the straightforward case of resolution to a locator > that is dereferenced to a representation. (On the distinction > between names and locators, see Section 1.1.3 of [RFC3986]; on the > distinction between representations and metadata, see Section 1.2.2 > of [RFC3986].) >=20 > As you can see, that text adds some examples and makes more careful > distinctions, which I think are helpful (even absent the potentially > confusing term "abstract designator"). Yes, thank you! This is much clearer than before. Best, Lars=20 From nobody Wed Dec 21 03:33:35 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 C0D46129D53 for ; Wed, 21 Dec 2016 03:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 OxTe29m3o9I2 for ; Wed, 21 Dec 2016 03:33:32 -0800 (PST) Received: from mail.dnb.de (prodfix-out0.dnb.de [193.175.100.144]) (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 64410129565 for ; Wed, 21 Dec 2016 03:33:32 -0800 (PST) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by mail.dnb.de (Postfix) with ESMTP id 3C8E847BC986 for ; Wed, 21 Dec 2016 12:33:31 +0100 (CET) X-AuditID: 0a453fe7-159ff70000000f1b-a3-585a688a2090 Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id D4.74.03867.A886A585; Wed, 21 Dec 2016 12:33:30 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0224.002; Wed, 21 Dec 2016 12:33:30 +0100 From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: Relative references in 2141bis Thread-Index: AdJbfg2qp8WmQdJfSQOM3VhQKQz2rQ== Date: Wed, 21 Dec 2016 11:33:30 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF010D2AA528@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.97] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12TX0hTURzHO9vVHZfHzu7UnVaWW0YktSwSjKR/FBYKiaKuPbiu7bqNps57 t9AeRGYGzSgLI1xlaVqQWGZ/CYlYT40sqcAiKyVzrRd9CZFCu3d309nb736+5/u93989XCin +xVaaK92sVw149DHKynlgd2/N3ttJmPWmaYdOZeapmV7wMHu7llZITApcy2sw36C5bbsOqq0 TY95gLMf1vXMv5E1gjboBRASvJ2c/8R5gRLS+CUg1+575NLDE0DmOqbivEAB43EmmbJ5QQJM xjryfNKjEGc13kC++lrlEt9E/vyZB9JsIJfmmilxpvB68rq3LXwG4XxyITAiE2eA00h//9sw l2MNGZiciRNngjHpHpQ4wSkk9H0uwtPJ4NjjeLGyHG8k955tkaw60tYyrpDiVeRV+wTVCmhf TKpv0eGLcfhiHDcAdQck8VXWrQbGYrBYKgwWdgBInzb4FJx7t98PMAT6RDSRe8RIxzEn+Poq PzgMZfoUdHFWQEkVNZZ6G8PbzJzbwfL6ZDReYTLSaAFXuB3H9WuQ9qBANQuUd/NO+zF7jZs3 uzmHHxAoF6y7WNFqYepPslyNFOgHqyCl16DQ82VGGlsZF3ucZZ0sF1WNEOoJ+lgpGFUca2Xr Ku0OV1QWfFqxDY5VwoV06FaRIGhjhf87yWCCHxTARKHYfjEf8U6mirdbI9lqlFQu0MQoDeem oaE8AaZG4dLMACjWalCOGIbFEzZ39UJXbSraVltmpFfECGKkNh1lNBca6ZUxfGnqL3BIuCI1 OmsV6wg/yGJHGnHiy5ZHYLjiagTFu0iJsP+zCoS7TUadLWXiwi7GFbvwaF544QiNLPxBWjgC l8ZpG0HWo+xi0/brtzPWLe/M+jmia1fke97cLhn1fMim8nKHh3qag/vW/L3s+eZ05xSfblGX vGj4Yijs+rVzbG/pdMfnH3zjlWLqZm3X7quqoDNz9mEf3ekNzpjj89cWnSo9O0T1wsPl40Pv G76OBIadg+bUhJ0Phu+GygO2PqhSqkKv9RRvY7Zmyjme+QfxaiQ0QwQAAA== Archived-At: Subject: [urn] Relative references in 2141bis 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, 21 Dec 2016 11:33:34 -0000 QWxsLA0KDQpJbiB0aGUgbGlzdCBhcmNoaXZlIEkgc2F3IHRoYXQgdGhlcmUgaGFkIGJlZW4gYSBk aXNjdXNzaW9uIGFib3V0IHJlc29sdXRpb24gYW5kIHJlbGF0aXZlIHJlZmVyZW5jZXMuIEkgYW0g YWxsIGluIGZhdm91ciBvZiB5b3VyIHJlc29sdXRpb24gKG5vIHB1biBpbnRlbmRlZCkgdG8gc2F5 IHRoYXQgYW55dGhpbmcgZGVhbGluZyB3aXRoIGJhc2UgVVJJcywgcmVsYXRpdmUgcmVmZXJlbmNl cyBldGMuIGFyZSBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgc3BlY2lmaWNhdGlvbi4gSWYgSSByZW1l bWJlciBjb3JyZWN0bHksIHdlIHN0YXJ0ZWQgdG8gd2FsayBkb3duIHRoYXQgcGF0aCB3aGVuIHdl IGFkZGVkICIvIiB0byB0aGUgYWxsb3dlZCBjaGFyYWN0ZXJzIGluIHRoZSBOU1MgYW5kIHRodXMg Z290IHRoZSBwLWNvbXBvbmVudCB0aGF0IGNvdWxkIGdpdmUgdGhlIGltcHJlc3Npb24gb2YgYmVp bmcgYSBoaWVyYXJjaHkuDQoNCkJlc3QsDQoNCkxhcnMNCg0KKioqIExlc2VuLiBIw7ZyZW4uIFdp c3Nlbi4gRGV1dHNjaGUgTmF0aW9uYWxiaWJsaW90aGVrICoqKiANCi0tIA0KRHIuIExhcnMgRy4g U3ZlbnNzb24NCkRldXRzY2hlIE5hdGlvbmFsYmlibGlvdGhlaw0KSW5mb3JtYXRpb25zaW5mcmFz dHJ1a3R1cg0KQWRpY2tlc2FsbGVlIDENCjYwMzIyIEZyYW5rZnVydCBhbSBNYWluDQpUZWxlZm9u OiArNDkgNjkgMTUyNS0xNzUyDQpUZWxlZmF4OiArNDkgNjkgMTUyNS0xNzk5DQptYWlsdG86bC5z dmVuc3NvbkBkbmIuZGUgDQpodHRwOi8vd3d3LmRuYi5kZQ0KDQoNCg== From nobody Wed Dec 21 03:40:22 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 692EF129D5C for ; Wed, 21 Dec 2016 03:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 UDSi68zqYKBb for ; Wed, 21 Dec 2016 03:40:19 -0800 (PST) Received: from mail.dnb.de (prodfix-out0.dnb.de [193.175.100.144]) (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 1DBF6129D58 for ; Wed, 21 Dec 2016 03:40:19 -0800 (PST) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by mail.dnb.de (Postfix) with ESMTP id E491947BC986 for ; Wed, 21 Dec 2016 12:40:17 +0100 (CET) X-AuditID: 0a453fe7-171ff70000000f1b-c8-585a6a21f0d3 Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id E9.74.03867.12A6A585; Wed, 21 Dec 2016 12:40:17 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0224.002; Wed, 21 Dec 2016 12:40:16 +0100 From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: Different conceptual model compared to earlier specifications Thread-Index: AdJbfv+Y2kM8v9YXR0+mKfRqfhWFIQ== Date: Wed, 21 Dec 2016 11:40:15 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF010D2AA542@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.97] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALsWRmVeSWpSXmKPExsXC5Wr/VVcxKyrCYPEedYupzR+YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMe+Nf8EProqvF3axNzBe4epi5OSQEDCR6Ju8haWLkYtDSOAw o8SVw3NZIZztQM7XXiCHnYNNQEvifQZIvYiAosS+Z03sILawgJvEltVdTBBxb4lvJ84wQth6 Et8OHgezWQRUJWbd3cUMYvMC1czraGQDsRkFZCU2bDgPFmcWEJfY9Ow7K8Q9AhJL9kDEJQRE JV4+/gcVV5DY82AbUC8HUL2mxPpd+hCtihJTuh+yQ4wXlDg58wnLBEahWUimzkLomIWkYxaS jgWMLKsY+Ypz0w31ElP0UlKS9FJSNzFCgvb5Dsa+Sy6HGAU4GJV4eJ/YREYIsSaWFVfmHmL0 52BSEuWd9BMoxJeUn1KZkVicEV9UmpNarCTC+zApKkKIFy6cVJqTrSTHK+UBFBWHixaXFhdk JmfmlxbHlxblHGKU4GAGas3KAGlNSaysSi3Khxh4iFGag0VJnPflPoYIIYH0xJLU7NTUgtQi mGwEB4eSBO9VkEbBotT01Iq0zJwSmDRQnxTINQLIMmAHKfIuCwJKSCFLoLuJiYPzEKMPBw/Q YeFghxUXJOYWZ6ZDzRbmnQkS5YGJgs2V5T3rDhQUgwmimnmKMVhKnPcBSJsASEVGaR7crVJi vEaF4RFC/EgSICOlFHhVWgMihCSRxFFNfcXoCYwiYd7lYOcAMwjCjUK8B0GC3FBBsBNleDlA cSEKFUM3ywcYtyK8C7vDQR4uSSxB9vAdd7CHoaJQD1+BeBgqiGqcVAPjKmWxtJ/K4XP8/Hlv mdR5aVY++GfIwRSfdipeWduyY+ZivmtLd+pOzNv7yH6qYoRhfPt9mcbZVuvn6bfVz2ISfMuZ oqdb3yb1zePByUWHW7PyJ/pOzZ5Q+f5r1QJRc54tHxmema2yVJqp+L2FjenHnkl75K8+qNpR yW0UsM1X2U92tatfiasSS3FGoqEWc1FxIgCfqQ9jQwQAAA== Archived-At: Subject: [urn] Different conceptual model compared to earlier specifications 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, 21 Dec 2016 11:40:20 -0000 QWxsLA0KDQppbiBkcmFmdC1pZXRmLXVybmJpcy1yZmMyMTQxYmlzLXVybi0xOCB0aGUgZmluYWwg cGFyYWdyYXBoIG9mIHNlY3Rpb24gMSByZWFkczoNCg0KW1sNClN1bW1hcmllcyBvZiBjaGFuZ2Vz IGZyb20gUkZDIDIxNDEgYW5kIFJGQyAzNDA2IGFwcGVhciBpbiBBcHBlbmRpeCBCIGFuZCBBcHBl bmRpeCBDIHJlc3BlY3RpdmVseS4gVGhpcyBkb2N1bWVudCBvYnNvbGV0ZXMgYm90aCBbUkZDMjE0 MV0gYW5kIFtSRkMzNDA2XS4gV2hpbGUgaXQgZG9lcyBub3QgZXhwbGljaXRseSB1cGRhdGUgb3Ig cmVwbGFjZSBbUkZDMTczN10gb3IgW1JGQzIyNzFdLCB0aGUgcmVhZGVyIHdobyByZWZlcmVuY2Vz IHRob3NlIGRvY3VtZW50cyBzaG91bGQgYmUgYXdhcmUgdGhhdCB0aGUgY29uY2VwdHVhbCBtb2Rl bCBvZiBVUk5zIGluIHRoaXMgZG9jdW1lbnQgaXMgc2xpZ2h0bHkgZGlmZmVyZW50IGZyb20gdGhv c2Ugb2xkZXIgc3BlY2lmaWNhdGlvbnMuDQpdXQ0KDQpUaGlzIGxhc3QgcmVmZXJlbmNlIHRvIGEg ImNvbmNlcHR1YWwgbW9kZWwgW3RoYXQgaXNdIHNsaWdodGx5IGRpZmZlcmVudCIgbGVhdmVzIHRo ZSByZWFkZXIgaGFuZ2luZyBpbiBtaWQtYWlyIGFzIHRvIHRoZSBuYXR1cmUgb2YgdGhvc2UgY2hh bmdlcy4gSSB0aGluayBpdCB3b3VsZCBiZSBoZWxwZnVsIHRvIHN1cHBseSBhdCBsZWFzdCBvbmUg ZXhhbXBsZSBvZiBzdWNoIGEgZGlmZmVyZW5jZS4NCg0KQmVzdCwNCg0KTGFycw0KDQoqKiogTGVz ZW4uIEjDtnJlbi4gV2lzc2VuLiBEZXV0c2NoZSBOYXRpb25hbGJpYmxpb3RoZWsgKioqIA0KLS0g DQpEci4gTGFycyBHLiBTdmVuc3Nvbg0KRGV1dHNjaGUgTmF0aW9uYWxiaWJsaW90aGVrDQpJbmZv cm1hdGlvbnNpbmZyYXN0cnVrdHVyDQpBZGlja2VzYWxsZWUgMQ0KNjAzMjIgRnJhbmtmdXJ0IGFt IE1haW4NClRlbGVmb246ICs0OSA2OSAxNTI1LTE3NTINClRlbGVmYXg6ICs0OSA2OSAxNTI1LTE3 OTkNCm1haWx0bzpsLnN2ZW5zc29uQGRuYi5kZSANCmh0dHA6Ly93d3cuZG5iLmRlDQoNCg0K From nobody Wed Dec 21 03:56: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 A52411294B2 for ; Wed, 21 Dec 2016 03:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 oxK9PyRlDxIU for ; Wed, 21 Dec 2016 03:56:07 -0800 (PST) Received: from mail.dnb.de (prodfix-out0.dnb.de [193.175.100.144]) (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 3D1A4129452 for ; Wed, 21 Dec 2016 03:56:07 -0800 (PST) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by mail.dnb.de (Postfix) with ESMTP id 0D6F547BC988 for ; Wed, 21 Dec 2016 12:56:06 +0100 (CET) X-AuditID: 0a453fe7-159ff70000000f1b-0b-585a6dd5b7a7 Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id E3.84.03867.5DD6A585; Wed, 21 Dec 2016 12:56:05 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0224.002; Wed, 21 Dec 2016 12:56:05 +0100 From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: q-component: What happens if the URL resolved to already has a query component? Thread-Index: AdJbgTTymOJ4x03JS8udpQKCrSwSrA== Date: Wed, 21 Dec 2016 11:56:04 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF010D2AA566@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.97] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALsWRmVeSWpSXmKPExsXC5Wr/VfdqblSEwa8bRhZTmz8wOTB6LFny kymAMYrLJiU1J7MstUjfLoErY8qFGWwFc4QqDq1Ia2B8INjFyMkhIWAi8efJK+YuRi4OIYHD jBIfeq8wQjjbGSUuds4DyrBzsAloSbzPAKkXEVCU2PesiR3EFhaIkpjZdpoVIh4v8XLaVRYI W0/iatM6sBoWAVWJ9TM2MYHYvALeEhu/fWIDsRkFZCU2bDjPDGIzC4hLbHr2nRXiHgGJJXsg 4hICohIvH/+DiitI7HmwDaiXA6heU2L9Ln2IVkWJKd0P2SHGC0qcnPmEZQKj0CwkU2chdMxC 0jELSccCRpZVjHzFuemGeokpeikpSXopqZsYIUH7fAdj3yWXQ4wCHIxKPLxPbCIjhFgTy4or cw8x+nMwKYnyTvoJFOJLyk+pzEgszogvKs1JLVYS4X2YFBUhxAsXTirNyVaS45XyAIqKw0WL S4sLMpMz80uL40uLcg4xSnAwA7U+zQJpTUmsrEotyocYeIhRmoNFSZz35T6GCCGB9MSS1OzU 1ILUIphsBAeHkgSvfA5Qo2BRanpqRVpmTglMGqhPCuQaAWQZsIMUeZcFASWkkCXQ3cTEwXmI 0YeDB+iwvGyQw4oLEnOLM9OhZgvzzswAivLARMHmyvKedQcKisEEUc08xRgsJc67D2SYAEhF Rmke3K1SYrxGheERQvxIEiAjpRR4VVoDIoQkkcRRTX3F6AmMImHeyaBA4AFmEIQbhXi9QYLc UEGwE2V4OUBxIQoVQzfLBxi3IrwLu8NBHi5JLEH28B13sIeholAPX4F4GCqIapxUA6OjH9sW /owtOzsvT0g9/bn9xaYHJr8WJz2fOTvzyukAUTmztsiyIIZA/6VdPX+Fv2emzFi3avXKrecm hJsUn2eZl677aIVmrlSXlG4Bd0pBjMsXiYCb27SCMvpLrdc9X/T5zqpZvb+fuy7yKijVLvl3 fcmbo15MFntN5L58X+C/4ap/9JWGyWeUWIozEg21mIuKEwEtl15DQwQAAA== Archived-At: Subject: [urn] q-component: What happens if the URL resolved to already has a query component? 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, 21 Dec 2016 11:56:09 -0000 QWxsLA0KDQpUaGlzIG1pZ2h0IGJlIGRlYWx0IHdpdGggYWxyZWFkeSwgc28gcGxlYXNlIGJlYXIg d2l0aCBtZSBpZiBJIHJlcGVhdCBhbiBvbGQgZGlzY3Vzc2lvbi4uLg0KDQpJbiDCpzIuMy4yIHRo ZSBmb2xsb3dpbmcgaXMgc2FpZCBhYm91dCB0aGUgcS1jb21wb25lbnQgKG1vZHVsbyBQZXRlcidz IHByb3Bvc2VkIGNoYW5nZXMpOg0KDQpbWw0KVGhlIFVSTiBxLWNvbXBvbmVudCBoYXMgdGhlIHNh bWUgc3ludGF4IGFzIHRoZSBVUkkgcXVlcnkgY29tcG9uZW50LCBidXQgaXMgaW50cm9kdWNlZCBi eSAiPz0iLCBub3QgIj8iIGFsb25lLiBGb3IgVVJOcyB0aGF0IG1heSBiZSByZXNvbHZlZCB0byBh IFVSTCwgdGhlIHNlbWFudGljcyBvZiB0aGUgcS1jb21wb25lbnQgYXJlIGlkZW50aWNhbCB0byB0 aG9zZSBmb3IgdGhlIHF1ZXJ5IGNvbXBvbmVudCBvZiB0aGF0IFVSTC4gVGh1cyBVUk4gcmVzb2x2 ZXJzIHJldHVybmluZyBhIFVSTCBmb3IgYSBVUk4gd2l0aCBhIHEtY29tcG9uZW50IGRvIHRoaXMg YnkgY29weWluZyB0aGUgcS1jb21wb25lbnQgZnJvbSB0aGUgVVJOIHRvIHRoZSBxdWVyeSBjb21w b25lbnQgb2YgdGhlIFVSTC4gSXQgdGhlIFVSTiBkb2VzIG5vdCByZXNvbHZlIHRvIGEgVVJMLCB0 aGUgaW50ZXJwcmV0YXRpb24gb2YgdGhlIHEtY29tcG9uZW50IGlzIHVuZGVmaW5lZCBieSB0aGlz IHNwZWNpZmljYXRpb24uIEFuIGV4YW1wbGUgb2YgdGhlIGNvcHlpbmcgb3BlcmF0aW9uIGFwcGVh cnMgYmVsb3cuDQpdXQ0KDQpUaGlzIGxlYXZlcyB0aGUgcXVlc3Rpb24gb3Blbiwgd2hhdCB3aWxs IGhhcHBlbiBpZiBhIFVSTiB3aXRoIGEgcS1jb21wb25lbnQgcmVzb2x2ZXMgdG8gYSBVUkwgdGhh dCBhbHJlYWR5IGhhcyBhIHF1ZXJ5IGNvbXBvbmVudC4gTXkgdGFrZSBpcyB0aGF0IHRoYXQgY2Fz ZSBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiAyMTQxYmlzLCBidXQgSSB0aGluayB3ZSBzaG91bGQg YmUgZXhwbGljaXQgYWJvdXQgdGhhdCBhbmQgc3VnZ2VzdCB0aGF0IHdlIGFkZCBzb21lIHRleHQg YWxvbmcgdGhlIGZvbGxvd2luZyBsaW5lczoNCg0KW1sNCkl0IGlzIHBvc3NpYmxlIHRoYXQgYSBV Uk4gd2l0aCBhIHEtY29tcG9uZW50IHJlc29sdmUgdG8gYSBVUkwgdGhhdCBhbHJlYWR5IGhhcyBh IHF1ZXJ5IGNvbXBvbmVudC4gSW4gdGhhdCBjYXNlLCB0aGUgZmluYWwgVVJMIHdpbGwgZW5kIHVw IGhhdmluZyBhIHF1ZXJ5IGNvbXBvbmVudCBjb25zaXN0aW5nIG9mIHRoZSBVUkwncyBvcmlnaW5h bCBxdWVyeSBjb21wb25lbnQgYW5kIHRoZSBxLWNvbXBvbmVudCBmcm9tIHRoZSBVUk4uIElmIHRo ZSBuZXcgcXVlcnkgY29tcG9uZW50IG1ha2VzIHNlbnNlIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9m IHRoaXMgc3BlY2lmaWNhdGlvbi4NCl1dDQoNCkJlc3QsDQoNCkxhcnMNCg0KKioqIExlc2VuLiBI w7ZyZW4uIFdpc3Nlbi4gRGV1dHNjaGUgTmF0aW9uYWxiaWJsaW90aGVrICoqKiANCi0tIA0KRHIu IExhcnMgRy4gU3ZlbnNzb24NCkRldXRzY2hlIE5hdGlvbmFsYmlibGlvdGhlaw0KSW5mb3JtYXRp b25zaW5mcmFzdHJ1a3R1cg0KQWRpY2tlc2FsbGVlIDENCjYwMzIyIEZyYW5rZnVydCBhbSBNYWlu DQpUZWxlZm9uOiArNDkgNjkgMTUyNS0xNzUyDQpUZWxlZmF4OiArNDkgNjkgMTUyNS0xNzk5DQpt YWlsdG86bC5zdmVuc3NvbkBkbmIuZGUgDQpodHRwOi8vd3d3LmRuYi5kZQ0KDQoNCg== From nobody Wed Dec 21 04:02: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 5ECAB129570 for ; Wed, 21 Dec 2016 04:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 JbPtq87phHso for ; Wed, 21 Dec 2016 04:02:02 -0800 (PST) Received: from mail.dnb.de (prodfix-out0.dnb.de [193.175.100.144]) (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 1FBA2129508 for ; Wed, 21 Dec 2016 04:02:02 -0800 (PST) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by mail.dnb.de (Postfix) with ESMTP id EB2FF47BC986 for ; Wed, 21 Dec 2016 13:02:00 +0100 (CET) X-AuditID: 0a453fe7-171ff70000000f1b-39-585a6f380127 Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id CA.84.03867.83F6A585; Wed, 21 Dec 2016 13:02:00 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0224.002; Wed, 21 Dec 2016 13:02:00 +0100 From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: f-component Thread-Index: AdJbggicRH5xNrFnQOarj3UbAHSVHw== Date: Wed, 21 Dec 2016 12:01:59 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF010D2AA580@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.97] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12TfUhTURjGO9tVb2vHjtepx1tGDvsjwZVaUGIfkJGVkH3hstDu3M0t55z3 buIsRLMPmdEXmjkJzNQy+hhSGmImK5KEqEwJyUQpCkWyKBna573btOl/L7/3fR6e97wcUkrd DaBJvdHMckbGoPSXEbKtmyZj1uWlq1fXPopZV1X2VbIZJDc0TElSQbosUcsa9AUst2rjYZmu oeYmMH2Bhb/aHUQJ6II2sJDEaA1ubm2RiDWFngBc1bjLBmRC3Qbw/a5mqQ0EkP4oGk/oxBEF isSdn04EiHUwUuCx1jbCBkiBh+P3r/M9Iyr8w9UjFWsCrcDT/c8k4ghEO/GQnRQxQBHY4Xjp HpGiMNzyyeXnCYNwQ4eHYxSCRz/88fLluGO41V+0kaKV+F77Ko80EldWjLjDQBSEn9d8JC4A yu7jav+vsPso7D6KOkDcAoF8bnasitGqtFqNSsu2AM/Dfn4IzvUmOQEigVIOPyYeUFN+TAFv zXWCXaREGQIvTQkoUJOnteoYXpfJWQwsr1TAEU26moKzWGMx5CiXQTpZoGGzlLfwJn2WPs/C Z1o4gxNgUipID+aKUi1jLWK5PI+hEywhCWUYHO1coKZQNmNmc1jWxHIzXTVJKjEsNwrCII7N ZguP6A3mmbago8U0yLfjDhQJm/YIDdq3MT+ThFzoBCmkXAj21B2MNzG5vD7b6x0Ma3QClc9Q t28EfLFNgKEzcK5nD9hLh8Fk0QyJEzqLcTYrHQrj8tPU1GKfhmhJL4dRp1LVVLgPn+s6BrYL JwqGj0VfufA9/mek4HXxZRZ5oTviUkiKtwjxsvleKcJtFfBaRZq4sJkx+y48uM29sJd6F+7z LOyFc+3oErB6/++hfhWVcPTd+birF4eno2pz6HCbqn7LNxPu0ZT1OsYV9YeyNpz8+2Cs7m15 Z7NLVhQfcaUadxeUZBy5TDQVn+37ri5+87O9pL7stKZ77Y5XCSnQ2Hv7TtpgWeZxx74z64+N 7uZK4+QDlTfixzuTxwbSXJPIOvGjunQ8ozHJqiR4HRMbLeV45h/DASGTQQQAAA== Archived-At: Subject: [urn] f-component 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, 21 Dec 2016 12:02:03 -0000 QWxsLA0KDQppbiB2ZXJzaW9uLTE4LCB0aGUgcGVudWx0aW1hdGUgcGFyYWdyYXBoIG9mIMKnMi4z LjMgc2F5cyB0aGUgZm9sbG93aW5nIGFib3V0IHRoZSBzZW1hbnRpY3Mgb2YgdGhlIGYtY29tcG9u ZW50Og0KDQpbWw0KVGhlIGYtY29tcG9uZW50IGlzIHByaW1hcmlseSBpbnRlbmRlZCB0byBkaXN0 aW5ndWlzaCB0aGUgY29uc3RpdHVlbnQgcGFydHMgb2YgcmVzb3VyY2VzIG5hbWVkIGJ5IFVSTnMu IFRodXMsIGZvciBVUk5zIHRoYXQgcmVzb2x2ZSB0byBVUkxzIG9mIHRoZSBuYW1lZCByZXNvdXJj ZXMsIHRoZSBzZW1hbnRpY3Mgb2YgYW4gZi1jb21wb25lbnQgYXJlIGRlZmluZWQgYnkgdGhlIG1l ZGlhIHR5cGUgb2YgdGhvc2UgcmVzb3VyY2VzLCBub3QgYnkgdGhlIFVSTiBuYW1lc3BhY2UuDQpd XQ0KDQpUaGlzIGxlYXZlcyBvdXQgd2hhdCB0aGUgc2VtYW50aWNzIG9mIHRoZSBmLWNvbXBvbmVu dCBpcyBpZiB0aGUgVVJOIHJlc29sdmVyIGRvZXNuJ3QgcmVzb2x2ZSB0byBhIFVSTCBidXQgcmV0 dXJucyB0aGUgcmVzb3VyY2UgKGUuIGcuIGEgZG9jdW1lbnQpIGRpcmVjdGx5LCB3aXRob3V0IHJl ZGlyZWN0aW5nIHRoZSBhZ2VudCB0byBhbm90aGVyIGxvY2F0aW9uLiBJIHByb3Bvc2UgdGhlIGZv bGxvd2luZyBtaW5vciBlZGl0Og0KDQpbWw0KVGhlIGYtY29tcG9uZW50IGlzIHByaW1hcmlseSBp bnRlbmRlZCB0byBkaXN0aW5ndWlzaCB0aGUgY29uc3RpdHVlbnQgcGFydHMgb2YgcmVzb3VyY2Vz IG5hbWVkIGJ5IFVSTnMuIFRodXMsIGZvciBVUk5zIHRoYXQgcmVzb2x2ZSB0byBVUkxzIG9mIHRo ZSBuYW1lZCByZXNvdXJjZXMgb3Igd2hlcmUgdGhlIFVSTiByZXNvbHZlciByZXR1cm5zIHRoZSBy ZXNvdXJjZSBkaXJlY3RseSwgdGhlIHNlbWFudGljcyBvZiBhbiBmLWNvbXBvbmVudCBhcmUgZGVm aW5lZCBieSB0aGUgbWVkaWEgdHlwZSBvZiB0aG9zZSByZXNvdXJjZXMsIG5vdCBieSB0aGUgVVJO IG5hbWVzcGFjZS4NCl1dDQoNCkJlc3QsDQoNCkxhcnMNCg0KKioqIExlc2VuLiBIw7ZyZW4uIFdp c3Nlbi4gRGV1dHNjaGUgTmF0aW9uYWxiaWJsaW90aGVrICoqKiANCi0tIA0KRHIuIExhcnMgRy4g U3ZlbnNzb24NCkRldXRzY2hlIE5hdGlvbmFsYmlibGlvdGhlaw0KSW5mb3JtYXRpb25zaW5mcmFz dHJ1a3R1cg0KQWRpY2tlc2FsbGVlIDENCjYwMzIyIEZyYW5rZnVydCBhbSBNYWluDQpUZWxlZm9u OiArNDkgNjkgMTUyNS0xNzUyDQpUZWxlZmF4OiArNDkgNjkgMTUyNS0xNzk5DQptYWlsdG86bC5z dmVuc3NvbkBkbmIuZGUgDQpodHRwOi8vd3d3LmRuYi5kZQ0KDQoNCg== From nobody Wed Dec 21 04:04: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 5348B129D76 for ; Wed, 21 Dec 2016 04:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 c9V_CauEcl9e for ; Wed, 21 Dec 2016 04:04:29 -0800 (PST) Received: from mail.dnb.de (prodfix-out0.dnb.de [193.175.100.144]) (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 250FB1294C5 for ; Wed, 21 Dec 2016 04:04:29 -0800 (PST) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by mail.dnb.de (Postfix) with ESMTP id F0D0A47BC986 for ; Wed, 21 Dec 2016 13:04:27 +0100 (CET) X-AuditID: 0a453fe7-171ff70000000f1b-49-585a6fcbcde0 Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id FC.84.03867.BCF6A585; Wed, 21 Dec 2016 13:04:27 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0224.002; Wed, 21 Dec 2016 13:04:27 +0100 From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: r-component (Syntax of example URN) Thread-Index: AdJbglyM1HfmheviTIygZ18F6lv3Rg== Date: Wed, 21 Dec 2016 12:04:26 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF010D2AA593@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.97] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLsWRmVeSWpSXmKPExsXC5Wr/Vfd0flSEwZ3tBhZTmz8wOTB6LFny kymAMYrLJiU1J7MstUjfLoErY2Z/ScEy1op5P46zNTBOYe1i5OSQEDCReDStFcjm4hASOMwo sWfneRYIZzujRNvxbrYuRnYONgEtifcZIPUiAooS+541sYPYwgI6ElffXWaEiBtKHL3TzgZh 60lsXHaLBcRmEVCV+P53HZjNK+AtceHjXLBeRgFZiQ0bzjOD2MwC4hKbnn2HukdAYskeiLiE gKjEy8f/oOIKEnsebAOazwFUrymxfpc+RKuixJTuh+wQ4wUlTs58wjKBUWgWkqmzEDpmIemY haRjASPLKka+4tx0Q73EFL2UlCS9lNRNjJCgfb6Dse+SyyFGAQ5GJR7eJzaREUKsiWXFlbmH GP05mJREeSf9BArxJeWnVGYkFmfEF5XmpBYrifA+TIqKEOKFCyeV5mQryfFKeQBFxeGixaXF BZnJmfmlxfGlRTmHGCU4mIFao3NBWlMSK6tSi/IhBh5ilOZgURLnfbmPIUJIID2xJDU7NbUg tQgmG8HBoSTB25EH1ChYlJqeWpGWmVMCkwbqkwK5RgBZBuwgRd5lQUAJKWQJdDcxcXAeYvTh 4AE6rBxkPm9xQWJucWY61Gxh3pkZQFEemCjYXFnes+5AQTGYIKqZpxjjOQ68X/GUSYglLz8v VUqc1wPkYwGQ6ozSPLi7pcR4jQrDI4T4kSRAxksp8Kq0BkQISSKJo9rwitETGF3CvPUgB/MA MwvCvUK8i0GC3FBBsHNleDlA8SIKFUM3ywcYzyK8C7vDQZ4vSSxB9vwdd7DnoaJQz1+BeB4q iGqcVAOj+lNLQbP8N+nmR+cdqlaUmjq5T6WrhSlnTtpGY94P5Z1VSrrlDxtPnnzjc+z94l1C +ddknqrcf+k+Q7PchTfo5cZnu7Pya92vrnrO45Tt3dL8Xjq1c9a8LS7Ci+Uq9C+eP2i27Pu2 86fvXd+86LmQ7IEva/41aSrL2vj8vfuI3zd484dWw4CbSizFGYmGWsxFxYkAFQiRfU8EAAA= Archived-At: Subject: [urn] r-component (Syntax of example URN) 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, 21 Dec 2016 12:04:33 -0000 QWxsLA0KDQpJbiDCpzIuMy4xIG9mIHZlcnNpb24tMTgsIHRoZXJlIGlzIGFuIGV4YW1wbGUgVVJO Og0KDQp1cm46ZXhhbXBsZTpmb28tYmFyLWJhei1xdXg/K0NDUmVzb2x2ZTogY2M9dWsNCg0KSXMg aXQgaW50ZW50aW9uYWwgdGhhdCB0aGVyZSBpcyBhIGJsYW5rIGJldHdlZW4gIkNDUmVzb2x2ZToi IGFuZCAiY2M9dWsiPw0KDQpCZXN0LA0KDQpMYXJzDQoNCioqKiBMZXNlbi4gSMO2cmVuLiBXaXNz ZW4uIERldXRzY2hlIE5hdGlvbmFsYmlibGlvdGhlayAqKiogDQotLSANCkRyLiBMYXJzIEcuIFN2 ZW5zc29uDQpEZXV0c2NoZSBOYXRpb25hbGJpYmxpb3RoZWsNCkluZm9ybWF0aW9uc2luZnJhc3Ry dWt0dXINCkFkaWNrZXNhbGxlZSAxDQo2MDMyMiBGcmFua2Z1cnQgYW0gTWFpbg0KVGVsZWZvbjog KzQ5IDY5IDE1MjUtMTc1Mg0KVGVsZWZheDogKzQ5IDY5IDE1MjUtMTc5OQ0KbWFpbHRvOmwuc3Zl bnNzb25AZG5iLmRlIA0KaHR0cDovL3d3dy5kbmIuZGUNCg0KDQo= From nobody Wed Dec 21 04:07:50 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 C07CC12943A for ; Wed, 21 Dec 2016 04:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 1Sq3rRCz3Em2 for ; Wed, 21 Dec 2016 04:07:47 -0800 (PST) Received: from mail.dnb.de (prodfix-out0.dnb.de [193.175.100.144]) (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 24F8D129C2C for ; Wed, 21 Dec 2016 04:07:47 -0800 (PST) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by mail.dnb.de (Postfix) with ESMTP id CA5CA47BC986 for ; Wed, 21 Dec 2016 13:07:45 +0100 (CET) X-AuditID: 0a453fe7-159ff70000000f1b-58-585a7091e343 Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id FE.84.03867.1907A585; Wed, 21 Dec 2016 13:07:45 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0224.002; Wed, 21 Dec 2016 13:07:44 +0100 From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: URI browser? Thread-Index: AdJbgtX9QzQRN3e3RaW0IXqGpMhXTQ== Date: Wed, 21 Dec 2016 12:07:44 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF010D2AA5A8@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.97] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12TW0zTYBTH/bqyfUw+rQW2z3qJTI2X6ABjDIl4SxA04jVmVnzAjlW2MLbR rgQ0KFE0ZhqCqA8uPiBOVGKU6FQ0YGAaReMlERMViQFvBF/AoBBMRNt1wPDt9HfO/9//6Umh hm7WMdDh8vKCi3OatHpSv37Nr6WnPDlsSvvw3LSzR/qJtWBDIDBMbAM5+nQb73QU80Ly6r16 u7/3k9bTSZZ0+Np05eA56QOxEFPLcdVwi8YH9JCmHgLcc+00oT7cBXik9i3wAR3UUotxn12Z T6CS8INvh3VKHU8l4jbf8RiVM/jeUKVGrc34evntMCep+bitoZFQakRtwoH+aq1SA2oWbmh4 FZ7XUEZ889tQjJqHwoEmlWPZv/fzSITPwU1dd2QtlOcX4Rv3k1VpEj5zolun2k/DT899IasA 7Y9y9Y8r/FEKf5SiBpD1YIpYmJ9q5mxmm81qtvE3gfptexpB5euMEKAgMMWhL+m7WTqGKxZL C0NgKyRMiah6WEZTrG5bqZ0T7bmC5ORFUwLqtuawNBrDVslZYJqNmA0yNY5RURI9jjyHWxJz JcEZAhhqZOmeQkVq40r384JbNQyBGZA0GVHvg0ksTeVzXr6A5z28MNplITRh9MclC6cJfD5f ss/h9I62ZR2jpKGiO+FASahuh9xgohv/ZyJgbAhkwzg5WFDxR6KHKxQd+RHveFTnlmncKA37 zkIvsmRoGIUTPZ+BXNjSd+UrQZMut4tnjKhGMaaUabvkGsvNGNCyol0sPTWqodgzc9C8o9tY enoUn/iG72CjfK54dEvxjZP/lvG8NLqowMkRGI47E0HlLokR9r9XtnznBHThxC5leS/njV6+ Myu8fIRGln+jLh+BE+2YcnA1M8vSCVZMqjwXc8nwsaG+esHUMv7y5KYU4UJwT8aBvLWiJW1h z5bNdUMYav3eeX8za0e879hGIrBusLSj3dj66PFbS0laUfCQlN2cWdFqGCh5v/Jl8GXNAfMS InVg0HnySV5W/U7Lwdri36ii/cOP7cQq+ph0ZWf9+bL7XT+bTaRo51IXawSR+weMF0rrUAQA AA== Archived-At: Subject: [urn] URI browser? 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, 21 Dec 2016 12:07:49 -0000 QWxsLA0KDQpUaGUgdWx0aW1hdGUgcGFyYWdyYXBoIG9mIMKnNC40IGludHJvZHVjZXMgdGhlIHRl cm0gIlVSSSBicm93c2VyIi4gSXMgdGhhdCB0aGUgc2FtZSBhcyAiYW55IGFwcGxpY2F0aW9uIGRp c3BsYXlpbmcgVVJJcyI/DQoNClRoYW5rcywNCg0KTGFycw0KDQoqKiogTGVzZW4uIEjDtnJlbi4g V2lzc2VuLiBEZXV0c2NoZSBOYXRpb25hbGJpYmxpb3RoZWsgKioqIA0KLS0gDQpEci4gTGFycyBH LiBTdmVuc3Nvbg0KRGV1dHNjaGUgTmF0aW9uYWxiaWJsaW90aGVrDQpJbmZvcm1hdGlvbnNpbmZy YXN0cnVrdHVyDQpBZGlja2VzYWxsZWUgMQ0KNjAzMjIgRnJhbmtmdXJ0IGFtIE1haW4NClRlbGVm b246ICs0OSA2OSAxNTI1LTE3NTINClRlbGVmYXg6ICs0OSA2OSAxNTI1LTE3OTkNCm1haWx0bzps LnN2ZW5zc29uQGRuYi5kZSANCmh0dHA6Ly93d3cuZG5iLmRlDQoNCg0K From nobody Wed Dec 21 04:14: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 04464129C2C for ; Wed, 21 Dec 2016 04:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 agVbCm5xoItB for ; Wed, 21 Dec 2016 04:14:55 -0800 (PST) Received: from mail.dnb.de (prodfix-out0.dnb.de [193.175.100.144]) (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 D69A8129C02 for ; Wed, 21 Dec 2016 04:14:54 -0800 (PST) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by mail.dnb.de (Postfix) with ESMTP id AE19747BC988 for ; Wed, 21 Dec 2016 13:14:53 +0100 (CET) X-AuditID: 0a453fe7-171ff70000000f1b-76-585a723b3d79 Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id A3.94.03867.B327A585; Wed, 21 Dec 2016 13:14:53 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0224.002; Wed, 21 Dec 2016 13:14:50 +0100 From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: NID syntax Thread-Index: AdJbg9EIKtN90vU1Tce2Pmg/A0q59w== Date: Wed, 21 Dec 2016 12:14:50 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF010D2AA5C4@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.97] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12TW0zTUBzGPVtlh7mDtWPbcQJCow+SONBM4/0WDagoiz5Q0EQ7VrbFMWq7 GfDF+20aMhFDIGokIRqNxoUYQeWSVF9AUTMvRCFEokExGjVoDA9e2nXg4O3f33e+L9//nBRq qYjOCr3+ACf4WR+dpCf0G1b/nL9SKGFyT/SnLTl/5JtmDchvahrVOECJfoWL83n3cULOqt16 T+eRHwTfYah89bKLOAhqDSEAISbt+HldIAT0kCIfAPwlGtGpHy0An5WGNCGgg0lkNv7qCYFk mEpm4Y6hwzplNpJG3D/wTKdyjO/Wf9eosw0/OXM/xglyLu6J9gFlRuRm/KYjHJsBmY4jkada ZdaSFtw89GuqMmOSxE1tKsekCQ+/+xPnmbjt7Z0kpbKWnIdv3ctRrVm49vSgTo2fgbvq3xNh QDUkpDb8dzQkOBoSHJcBcR2kiOXuBTbWZXO5nDYX1wzUq/3QCqqj6yVAQkAb0PsVxQw1ld0n VpVLoBBqaBOqGZVRirPCVeVhRc8uIejjRDoVDTpLGAqNY2fQt4fOQNZ8mVrGqRgUeW+ptyIo 7goKPglgqJWtO8oVq4ut2s8JFWqgBGZBgrag4Y4pDEW62QC3h+N4ThhTGQhpjLp42ThD4Nxc ZZnXFxiTZZ9xr6yQiUqsUBa6sk0WrInC5E4amCyBAmiQi0lKChJ5tlz0uuPZRnSlQqaGMRrL TUc9eTI0j8GJmd1gu9WCxFgl5YQn6B/vajWjhXuLGGp6gqBEWjPRnGMOhpqZwCemfgIb5Scy os1KrkH+Qf53pNB35WamxWGsYhqCyluY4mxyVoH8tqmo8XSRsnCADSQu3J8XWzhO4wu/UBeO w4lx1oPgWvhce83xM7PN6x/3Li8Ww/zozm0HzppLK4tvLu52HG3/+3E480dewSZzu7j20paN r6VDu7devdfjsa+7QPTyhb+XnRR6O02S88LF7Pm/5txospeOFBH+nsbWsmVJgUfM55HoIr7a fxsufdLnyB0YqOs+3PLQr28UV2WETlXZc8I0IXrYBdlaQWT/AV0b/WBDBAAA Archived-At: Subject: [urn] NID syntax 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, 21 Dec 2016 12:14:56 -0000 QWxsLA0KDQpUaGUgc3ludGF4IGZvciBmb3JtYWwgVVJOIG5hbWVzcGFjZXMgZGVjbGFyZXM6DQoN CltbDQpbLi4uXQ0KNC4gSXQgTVVTVCBOT1Qgc3RhcnQgd2l0aCBBTFBIQSBBTFBIQSAiLSIsIGku IGUuIGFueSBzdHJpbmcgY29uc2lzdGluZyBvZiB0d28gbGV0dGVycyBmb2xsb3dlZCBieSBvbmUg aHlwaGVuIi4NCjUuIEl0IE1VU1QgTk9UIHN0YXJ0IHdpdGggdGhlIHN0cmluZyAieG4tLSIgb3Ig YW55IG90aGVyIHN0cmluZyBjb25zaXN0aW5nIG9mIHR3byBsZXR0ZXJzIGZvbGxvd2VkIGJ5IHR3 byBoeXBoZW5zLiBbLi4uXQ0KXV0NCg0KVG8gbWUgdGhpcyBmZWVscyByZWR1bmRhbnQuIElmIGl0 IG11c3Qgbm90IHN0YXJ0IHdpdGggQUxQSEEgQUxQSEEgIi0iLCAiYW55IG90aGVyIHN0cmluZyBj b25zaXN0aW5nIG9mIHR3byBsZXR0ZXJzIGZvbGxvd2VkIGJ5IHR3byBoeXBoZW5zIiBpcyBmb3Ji aWRkZW4gYWxyZWFkeS4gSSB0aGluayB3ZSBjb3VsZCBjb25mbGF0ZSB0aG9zZSB0d28gdG86DQoN CltbDQo0LiBJdCBNVVNUIE5PVCBzdGFydCB3aXRoIGFueSBzdHJpbmcgY29uc2lzdGluZyBvZiB0 d28gbGV0dGVycyBmb2xsb3dlZCBieSBvbmUgb3IgdHdvIGh5cGhlbnMuIFN1Y2ggc3RyaW5ncyBh cmUgcmVzZXJ2ZWQgZm9yIHBvdGVudGlhbCByZXByZXNlbnRhdGlvbiBvZiBETlMgQS1sYWJlbHMg YW5kIHNpbWlsYXIgc3RyaW5ncyBpbiB0aGUgZnV0dXJlIFtSRkM1ODkwXS4NCl1dDQoNCk9yIGFy ZSBBTFBIQSBBTFBIQSAiLSItU3RyaW5ncyByZXNlcnZlZCBmb3Igc29tZXRoaW5nIGVsc2U/IElm IHNvLCB0aGVuIHdlIHNob3VsZCBleHBsYWluIHdoeSB0aG9zZSBhcmUgZm9yYmlkZGVuLCB0b28u DQoNCkJlc3QsDQoNCkxhcnMNCg0KKioqIExlc2VuLiBIw7ZyZW4uIFdpc3Nlbi4gRGV1dHNjaGUg TmF0aW9uYWxiaWJsaW90aGVrICoqKiANCi0tIA0KRHIuIExhcnMgRy4gU3ZlbnNzb24NCkRldXRz Y2hlIE5hdGlvbmFsYmlibGlvdGhlaw0KSW5mb3JtYXRpb25zaW5mcmFzdHJ1a3R1cg0KQWRpY2tl c2FsbGVlIDENCjYwMzIyIEZyYW5rZnVydCBhbSBNYWluDQpUZWxlZm9uOiArNDkgNjkgMTUyNS0x NzUyDQpUZWxlZmF4OiArNDkgNjkgMTUyNS0xNzk5DQptYWlsdG86bC5zdmVuc3NvbkBkbmIuZGUg DQpodHRwOi8vd3d3LmRuYi5kZQ0KDQoNCg== From nobody Wed Dec 21 04:16:59 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 B2EAC1293E1 for ; Wed, 21 Dec 2016 04:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 VdymgqRQclQI for ; Wed, 21 Dec 2016 04:16:57 -0800 (PST) Received: from mail.dnb.de (prodfix-out0.dnb.de [193.175.100.144]) (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 91F19129455 for ; Wed, 21 Dec 2016 04:16:57 -0800 (PST) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by mail.dnb.de (Postfix) with ESMTP id 66F5E47BC988 for ; Wed, 21 Dec 2016 13:16:56 +0100 (CET) X-AuditID: 0a453fe7-171ff70000000f1b-84-585a72b897fa Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id 75.94.03867.8B27A585; Wed, 21 Dec 2016 13:16:56 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0224.002; Wed, 21 Dec 2016 13:16:55 +0100 From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: Informal URN Namespaces Thread-Index: AdJbhB41wlYwWXZoQ+q6KVTmxtzdKw== Date: Wed, 21 Dec 2016 12:16:54 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF010D2AA5DC@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.97] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12Te0hTURzHPducx+Wx652608rSq70kX1FQIj2g0MjIpHCppHft5oZzm/du okIx7AEpikZBCoWF2QvRLM1EzKY9TEURkRSDJLMUyQeEWGHdu02d/ve7n+/5fu/3dw8XiskW DyXUGcwMa6D1lFQmkR09+CusiU1WRY78RPtuXZ4RHQJxVVULogSQLIvRMHpdDsNGHEiXaTs7 rSKTVZo70/nG3Qqm3AsBhJjYgxsmYwqBDJJEO8ClfQ0ejoeXAP+79pB/8IBSIhRPawuBJ/Ql gnDreIGHMMuJQLzYMyh18K14cKRG7JjD8WPbuESYJTyvHHhvP4+I4/hVxxwQZkAE4Lq6Xvt5 MaHA9ePz7sKMCQJXtTg4JvzwxNdFJw/ELV8apUJlMbET1zZHOKxB+GbRqDPeB3eWj0lKAVnh klqx4qhwcVS4OCqB5Anw5rIyosJpTbhGow7XMPXA8Wm/N4GS/iM2QEBAeaGxmLMq0p3O4fKy bOAkFFF+6MYCj7zVRk2elua0aaxFz3CULxpVJ6tItIzVFn0mtRkp43iqWKachTPpzuuMFi7N wuptAEMxb03JEqwaOi+fYY2OQBvYCCWUAk20uqlIIoM2M5kMY2LYJVUFIYXR6Wze6MMyGUzu BZ3evCTzPrmgEK6KvVAQqk7kBaWrsLaTCHraQDz04ovZhBTEmegsTpfhzJajaiNPvZaoPTcA 9cTy0H8Jrs78CNJg2/SjbyJSYjAaGKUCcfZ6wmmtxbDcW+mPdmcnqcj1LoIQrwxEIVcTVOQG F776DZPgGH9dctQu5HrxP8tKXxLNmni4zgntdTchKNyLn5OtzYrn79kX3StKEpY302bX5Udi 7cs7qXP5AcfyTrg6TmkF9+WJw8/S2z6Xz4ZUKnJ7arsn29x+HzZS6O+O22Y69VxK5Lbtf6YK 6ketiqG3w3t3Reff6TdHz5U/3TLw41RrQId/lzqs7C7sLSl7QbqdqC56fcZKFza0XE8a4j4E B3666DvSXXOpT9Es671CDCc8eB78zjOG6yqeTygtntzf2JFKSTgtHRUqZjn6PzosoBJPBAAA Archived-At: Subject: [urn] Informal URN Namespaces 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, 21 Dec 2016 12:16:58 -0000 QWxsLA0KDQpBIG1pbm9yIGNoYW5nZSBwcm9wb3NhbCB0byB0aGUgc2VjdGlvbiBvbiBJbmZvcm1h bCBVUk4gTmFtZXNwYWNlcy4gVGhlIGZpcnN0IHBhcmFncmFwaCBvZiDCpzUuMiBlbmRzOiAiVGh1 cyB0aGUgc3ludGF4IG9mIGFuIGluZm9ybWFsIFVSTiBuYW1lc3BhY2UgaXM6Ii4gSSB0aGluayB0 aGlzIHNob3VsZCByZWFkICJUaHVzIHRoZSBzeW50YXggb2YgYW4gaW5mb3JtYWwgVVJOIG5hbWVz cGFjZSBpZGVudGlmaWVyIGlzOiIuDQoNCkJlc3QsDQoNCkxhcnMNCg0KKioqIExlc2VuLiBIw7Zy ZW4uIFdpc3Nlbi4gRGV1dHNjaGUgTmF0aW9uYWxiaWJsaW90aGVrICoqKiANCi0tIA0KRHIuIExh cnMgRy4gU3ZlbnNzb24NCkRldXRzY2hlIE5hdGlvbmFsYmlibGlvdGhlaw0KSW5mb3JtYXRpb25z aW5mcmFzdHJ1a3R1cg0KQWRpY2tlc2FsbGVlIDENCjYwMzIyIEZyYW5rZnVydCBhbSBNYWluDQpU ZWxlZm9uOiArNDkgNjkgMTUyNS0xNzUyDQpUZWxlZmF4OiArNDkgNjkgMTUyNS0xNzk5DQptYWls dG86bC5zdmVuc3NvbkBkbmIuZGUgDQpodHRwOi8vd3d3LmRuYi5kZQ0KDQoNCg== From nobody Wed Dec 21 04:32: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 1F8E71295D1 for ; Wed, 21 Dec 2016 04:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 43TF9KCu4RdT for ; Wed, 21 Dec 2016 04:32:48 -0800 (PST) Received: from mail.dnb.de (prodfix-out0.dnb.de [193.175.100.144]) (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 6BD3C1293E1 for ; Wed, 21 Dec 2016 04:32:48 -0800 (PST) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by mail.dnb.de (Postfix) with ESMTP id C45D347BC988 for ; Wed, 21 Dec 2016 13:32:46 +0100 (CET) X-AuditID: 0a453fe7-159ff70000000f1b-f6-585a766bf9eb Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id E7.A4.03867.B667A585; Wed, 21 Dec 2016 13:32:46 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0224.002; Wed, 21 Dec 2016 13:32:42 +0100 From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: Approval of version-18 of 2141bis Thread-Index: AdJbhlJOxtVyzwaqThKpzFrdlTpbYg== Date: Wed, 21 Dec 2016 12:32:41 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF010D2AA666@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.97] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALsWRmVeSWpSXmKPExsXC5Wr/VTevLCrC4OB8OYupzR+YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8ffDNraCLRwVq05fZGtgnMHRxcjJISFgIvH83hr2LkYuDiGB w4wSm26+ZoZwtjNKHD44GSjDzsEmoCXxPgOkXkRAUWLfsyZ2EFsYKPr0904WiLi+xLQ/i9i6 GDmAbD2J5jWKIGEWAVWJaf3/wcp5BbwlGq/MYAaxGQVkJTZsOA9mMwuIS2x69p0V4hwBiSV7 IOISAqISLx//g4orSOx5sA1sPLOApsT6XfoQrYoSU7ofQo0XlDg58wnLBEahWUimzkLomIWk YxaSjgWMLKsY+Ypz0w31ElP0UlKS9FJSNzFCgvb5Dsa+Sy6HGAU4GJV4eJ/YREYIsSaWFVfm HmL052BSEuWd9BMoxJeUn1KZkVicEV9UmpNarCTC+zApKkKIFy6cVJqTrSTHK+UBFBWHixaX FhdkJmfmlxbHlxblHGKU4GAGao3OBWlNSaysSi3Khxh4iFGag0VJnPflPoYIIYH0xJLU7NTU gtQimGwEB4eSBK96KVCjYFFqempFWmZOCUwaqE+4ECgjgCwDdpAi77IgoIQUsgS6m5g4OA8x +nDwAB3WDDKft7ggMbc4Mx1qtjDvsnygKA9MFGyuLO9Zd6CgGEwQ1cxTjMFS4rwOJSAngVRk lObB3SolxmtUGB4hxI8kATJSSoFXpTUgQkgSSRzV1FeMnsAoEub1BjmSB5hBEG4U4m0AWcYN FQQ7UYaXAxQXolAxdLN8gHErwruwOxzk4ZLEEmQP33EHexgqCvXwFYiHoYKoxkk1MC6WcejK +se+tdvh1Sv7v3Neb/kY+mDS8lvrMm9tiPm69sva1tl33QVCN/DfPfY+88CK5IzZwszT3JTe f1rFfWnTczHlmuld510F/6vccVhw9Tlzm61XU77Kw1uBa51teLhDbYreGc1kYnzd8/g/r3/D mwchCgxL1rzQlX1bXDGV9Zn+hpf958uVWIozEg21mIuKEwHYAg8gQwQAAA== Archived-At: Subject: [urn] Approval of version-18 of 2141bis 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, 21 Dec 2016 12:32:50 -0000 RGVhciBXRywNCg0KVGhpcyBpcyBqdXN0IGEgc2hvcnQgbm90ZSB0aGF0IEkgaGF2ZSByZXZpZXdl ZCB2ZXJzaW9uIDE4IG9mIFJGQyAyMTQxIGJpcy4gSSB0aGluayB0aGlzIHZlcnNpb24gaXMgcmVh ZHkgZm9yIGxhc3QgY2FsbCAobW9kdWxvIHRoZSBjaGFuZ2VzIGJlaW5nIHByb3Bvc2VkIGJ5IG90 aGVyIHBlb3BsZSB0aGFuIG1lKS4gSSB3YW50IHRvIGV4cHJlc3MgbXkgZ3JhdGl0dWRlIHRvIHRo ZSBlZGl0b3JzIGZvciB0aGVpciBoYXJkIHdvcmsgYW5kIHRvIGV2ZXJ5b25lIGVsc2Ugd2hvIGhh cyBjb250cmlidXRlZCB0byB0aGlzIGltcG9ydGFudCBzcGVjaWZpY2F0aW9uLg0KDQpJIGhhdmUg c2VudCBzb21lIHN1Z2dlc3Rpb25zIGZvciBjaGFuZ2VzIGlmIHRoZXJlIHN0aWxsIGlzIHRpbWUg dG8gY29uc2lkZXIgdGhlbS4gSWYgbm90LCBJIHN1cHBvcnQgdmVyc2lvbi0xOCBhcyBpcyAobW9k dWxvIG90aGVyIGNoYW5nZXMpLg0KDQpCZXN0LA0KDQpMYXJzDQoNCioqKiBMZXNlbi4gSMO2cmVu LiBXaXNzZW4uIERldXRzY2hlIE5hdGlvbmFsYmlibGlvdGhlayAqKiogDQotLSANCkRyLiBMYXJz IEcuIFN2ZW5zc29uDQpEZXV0c2NoZSBOYXRpb25hbGJpYmxpb3RoZWsNCkluZm9ybWF0aW9uc2lu ZnJhc3RydWt0dXINCkFkaWNrZXNhbGxlZSAxDQo2MDMyMiBGcmFua2Z1cnQgYW0gTWFpbg0KVGVs ZWZvbjogKzQ5IDY5IDE1MjUtMTc1Mg0KVGVsZWZheDogKzQ5IDY5IDE1MjUtMTc5OQ0KbWFpbHRv Omwuc3ZlbnNzb25AZG5iLmRlIA0KaHR0cDovL3d3dy5kbmIuZGUNCg0KDQo= From nobody Thu Dec 22 10:56: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 903A6129880 for ; Thu, 22 Dec 2016 10:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-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 IHO47HWKmYRt for ; Thu, 22 Dec 2016 10:56:26 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2B49A1294BD for ; Thu, 22 Dec 2016 10:56:26 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 61063400E0; Thu, 22 Dec 2016 11:58:46 -0700 (MST) To: "Svensson, Lars" References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> <24637769D123E644A105A0AF0E1F92EF010D2AA515@dnbf-ex1.AD.DDB.DE> From: Peter Saint-Andre Message-ID: <840c4bb0-7cd5-5a30-0390-6a6c49d8c515@stpeter.im> Date: Thu, 22 Dec 2016 11:56:23 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <24637769D123E644A105A0AF0E1F92EF010D2AA515@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Terminology -- 'resource' and 'abstract designator' 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, 22 Dec 2016 18:56:27 -0000 Hi Lars, thank you very much for your feedback. On 12/21/16 4:26 AM, Svensson, Lars wrote: > Peter, WG, > > On Thursday, December 15, 2016 5:05 AM, urn > [mailto:urn-bounces@ietf.org] On Behalf Of Peter Saint-Andre wrote: >>>> Part 2 -- 'abstract designator' > > [...] > >> OLD The URN q-component has the same syntax as the URI query >> component, but is introduced by "?=", not "?" alone. For URNs that >> may be resolved to a URL, the semantics of the q-component are >> identical to those for the query component of that URL. Thus URN >> resolvers returning a URL for a URN with a q-component do this by >> copying the q-component from the URN 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. An example of >> the copying operation appears below. >> >> NEW The URN q-component has the same syntax as the query component >> in URI schemes for locators, but is introduced by "?=", not "?" >> alone. For URNs that may be resolved to a locator URI, the >> semantics of the q-component are identical to those for the query >> component of that URI. Thus URN resolvers returning a locator URI >> for a URN with a q-component do this by copying the q-component >> from the URN to the query component of the locator URI. If the URN >> does not resolve to a locator URI, the interpretation of the >> q-component is undefined by this specification. An example of the >> copying operation appears below. >> > > Here I don't quite agree with "The URN q-component has the same > syntax as the query component in URI schemes for locators". That text > implies that URI schemes that are not for locators have a different > query component syntax. My suggestion would be to accept Peter's new > version but keep the first sentence unchanged: > > [[ The URN q-component has the same syntax as the URI query > component, but is introduced by "?=", not "?" alone. For URNs > that may be resolved to a locator URI, the semantics of the > q-component are identical to those for the query component of that > URI. Thus URN resolvers returning a locator URI for a URN with a > q-component do this by copying the q-component from the URN to the > query component of the locator URI. If the URN does not resolve to a > locator URI, the interpretation of the q-component is undefined by > this specification. An example of the copying operation appears > below. ]] [...] You are right - thanks for pointing out this problem. Peter From nobody Thu Dec 22 11:01: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 C5C701294FE for ; Thu, 22 Dec 2016 11:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-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 kh3lOl90n6Ij for ; Thu, 22 Dec 2016 11:01:34 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D6BEC129472 for ; Thu, 22 Dec 2016 11:01:34 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A82AD400E0; Thu, 22 Dec 2016 12:03:55 -0700 (MST) To: "Svensson, Lars" , "urn@ietf.org" References: <24637769D123E644A105A0AF0E1F92EF010D2AA666@dnbf-ex1.AD.DDB.DE> From: Peter Saint-Andre Message-ID: <82a851de-46a5-222e-e86f-88719d7d901e@stpeter.im> Date: Thu, 22 Dec 2016 12:01:33 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <24637769D123E644A105A0AF0E1F92EF010D2AA666@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Approval of version-18 of 2141bis 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, 22 Dec 2016 19:01:35 -0000 On 12/21/16 5:32 AM, Svensson, Lars wrote: > Dear WG, > > This is just a short note that I have reviewed version 18 of RFC 2141 > bis. I think this version is ready for last call (modulo the changes > being proposed by other people than me). I want to express my > gratitude to the editors for their hard work and to everyone else who > has contributed to this important specification. And thanks to you and everyone else who have provided feedback! > I have sent some suggestions for changes if there still is time to > consider them. If not, I support version-18 as is (modulo other > changes). We definitely have a bit of time to address the issues that you, Henry, and Juha have raised on the list. John and I are working to incorporate some changes as quickly as we can and plan to publish version -19 in the very near future. Peter From nobody Thu Dec 22 11:03: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 7BC9A1294FE for ; Thu, 22 Dec 2016 11:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-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 f7VGQfxH3aDx for ; Thu, 22 Dec 2016 11:03:01 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A0E28128B37 for ; Thu, 22 Dec 2016 11:03:01 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6C65A400E0; Thu, 22 Dec 2016 12:05:22 -0700 (MST) To: "Svensson, Lars" , "urn@ietf.org" References: <24637769D123E644A105A0AF0E1F92EF010D2AA5DC@dnbf-ex1.AD.DDB.DE> From: Peter Saint-Andre Message-ID: Date: Thu, 22 Dec 2016 12:02:59 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <24637769D123E644A105A0AF0E1F92EF010D2AA5DC@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] Informal URN Namespaces 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, 22 Dec 2016 19:03:02 -0000 On 12/21/16 5:16 AM, Svensson, Lars wrote: > All, > > A minor change proposal to the section on Informal URN Namespaces. > The first paragraph of §5.2 ends: "Thus the syntax of an informal URN > namespace is:". I think this should read "Thus the syntax of an > informal URN namespace identifier is:". Agreed! Peter From nobody Thu Dec 22 11:17:46 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 CA1D5129517 for ; Thu, 22 Dec 2016 11:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-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 VERGjiGltSnG for ; Thu, 22 Dec 2016 11:17:45 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 027231294CC for ; Thu, 22 Dec 2016 11:17:45 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B788F400E0; Thu, 22 Dec 2016 12:20:05 -0700 (MST) To: "Svensson, Lars" , "urn@ietf.org" References: <24637769D123E644A105A0AF0E1F92EF010D2AA580@dnbf-ex1.AD.DDB.DE> From: Peter Saint-Andre Message-ID: <7387d698-2bc4-6a1b-dd1d-cb12ad7d0c8f@stpeter.im> Date: Thu, 22 Dec 2016 12:17:43 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <24637769D123E644A105A0AF0E1F92EF010D2AA580@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] f-component 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, 22 Dec 2016 19:17:45 -0000 On 12/21/16 5:01 AM, Svensson, Lars wrote: > All, > > in version-18, the penultimate paragraph of §2.3.3 says the following > about the semantics of the f-component: > > [[ The f-component is primarily intended to distinguish the > constituent parts of resources named by URNs. Thus, for URNs that > resolve to URLs of the named resources, the semantics of an > f-component are defined by the media type of those resources, not by > the URN namespace. ]] > > This leaves out what the semantics of the f-component is if the URN > resolver doesn't resolve to a URL but returns the resource (e. g. a > document) directly, without redirecting the agent to another > location. I propose the following minor edit: > > [[ The f-component is primarily intended to distinguish the > constituent parts of resources named by URNs. Thus, for URNs that > resolve to URLs of the named resources or where the URN resolver > returns the resource directly, the semantics of an f-component are > defined by the media type of those resources, not by the URN > namespace. ]] I would like to think about this some more. In particular, I am not sure it's right to say that a URN resolver might "return a resource", because I believe that it would return (via dereferencing) either a representation of the resource or metadata about the resource, and I further believe the f-component applies only to representations and not to metadata (but I might be wrong about that). Thus perhaps this is more correct: The f-component is primarily intended to distinguish the constituent parts of a resource named by a URN. For a URN that resolves to one or more locators which can be dereferenced to a representation, or where the URN resolver directly returns a representation of the resource, the semantics of an f-component are defined by the media type of the representation, not by the URN namespace. Peter From nobody Thu Dec 22 11:24: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 C4161129664 for ; Thu, 22 Dec 2016 11:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-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 Sv24QQiqO6Aq for ; Thu, 22 Dec 2016 11:24:30 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D9E5E129550 for ; Thu, 22 Dec 2016 11:24:30 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8796F400E0; Thu, 22 Dec 2016 12:26:51 -0700 (MST) To: "Svensson, Lars" , "urn@ietf.org" References: <24637769D123E644A105A0AF0E1F92EF010D2AA5C4@dnbf-ex1.AD.DDB.DE> From: Peter Saint-Andre Message-ID: <4ab3f15d-c1e6-9015-ec19-996852b3e50e@stpeter.im> Date: Thu, 22 Dec 2016 12:24:29 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <24637769D123E644A105A0AF0E1F92EF010D2AA5C4@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] NID syntax 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, 22 Dec 2016 19:24:32 -0000 On 12/21/16 5:14 AM, Svensson, Lars wrote: > All, > > The syntax for formal URN namespaces declares: > > [[ > [...] > 4. It MUST NOT start with ALPHA ALPHA "-", i. e. any string consisting of two letters followed by one hyphen". > 5. It MUST NOT start with the string "xn--" or any other string consisting of two letters followed by two hyphens. [...] > ]] > > To me this feels redundant. If it must not start with ALPHA ALPHA "-", "any other string consisting of two letters followed by two hyphens" is forbidden already. I think we could conflate those two to: > > [[ > 4. It MUST NOT start with any string consisting of two letters followed by one or two hyphens. Such strings are reserved for potential representation of DNS A-labels and similar strings in the future [RFC5890]. > ]] > > Or are ALPHA ALPHA "-"-Strings reserved for something else? If so, then we should explain why those are forbidden, too. I think this is clearer (combining the relevant rules and the text that is currently shown after the bulleted list: 3. It MUST be more than two characters long and it MUST NOT start with ALPHA ALPHA "-", i.e., any string consisting of two letters followed by one hyphen; such strings are reserved for potential use as NIDs based on ISO alpha-2 country codes [ISO.3166-1] for eventual national registrations of URN namespaces (however, the definition and scoping of rules for allocation of responsibility for such country-code-based URN namespaces are beyond the scope of this document). Peter From nobody Thu Dec 22 11:24: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 D953D129880 for ; Thu, 22 Dec 2016 11:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-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 gNJ-0nIvdVTF for ; Thu, 22 Dec 2016 11:24:52 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8AE1293DA for ; Thu, 22 Dec 2016 11:24:52 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 260D2400E0; Thu, 22 Dec 2016 12:27:13 -0700 (MST) To: "Svensson, Lars" , "urn@ietf.org" References: <24637769D123E644A105A0AF0E1F92EF010D2AA5A8@dnbf-ex1.AD.DDB.DE> From: Peter Saint-Andre Message-ID: <30f89354-8e8f-f993-a415-fdf437b706b3@stpeter.im> Date: Thu, 22 Dec 2016 12:24:51 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <24637769D123E644A105A0AF0E1F92EF010D2AA5A8@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] URI browser? 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, 22 Dec 2016 19:24:53 -0000 On 12/21/16 5:07 AM, Svensson, Lars wrote: > All, > > The ultimate paragraph of §4.4 introduces the term "URI browser". Is that the same as "any application displaying URIs"? I like that better. Peter From nobody Thu Dec 22 12:28: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 556E312947D for ; Thu, 22 Dec 2016 12:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-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 jTL7UGNi5jZL for ; Thu, 22 Dec 2016 12:28:27 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFC7126D74 for ; Thu, 22 Dec 2016 12:28:27 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D78DB400E0; Thu, 22 Dec 2016 13:30:47 -0700 (MST) To: "Svensson, Lars" , "urn@ietf.org" References: <24637769D123E644A105A0AF0E1F92EF010D2AA593@dnbf-ex1.AD.DDB.DE> From: Peter Saint-Andre Message-ID: <2b3265ce-495c-db24-3941-3986894e1754@stpeter.im> Date: Thu, 22 Dec 2016 13:28:24 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <24637769D123E644A105A0AF0E1F92EF010D2AA593@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] r-component (Syntax of example URN) 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, 22 Dec 2016 20:28:28 -0000 On 12/21/16 5:04 AM, Svensson, Lars wrote: > All, > > In §2.3.1 of version-18, there is an example URN: > > urn:example:foo-bar-baz-qux?+CCResolve: cc=uk > > Is it intentional that there is a blank between "CCResolve:" and "cc=uk"? I think that is an error; thanks for catching it. Peter From nobody Thu Dec 22 12:29:08 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 C004D12953D for ; Thu, 22 Dec 2016 12:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-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 xutpYvkGa3hN for ; Thu, 22 Dec 2016 12:29:06 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 001A2126D74 for ; Thu, 22 Dec 2016 12:29:05 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 102A5400E0; Thu, 22 Dec 2016 13:31:26 -0700 (MST) To: "Svensson, Lars" , "urn@ietf.org" References: <24637769D123E644A105A0AF0E1F92EF010D2AA542@dnbf-ex1.AD.DDB.DE> From: Peter Saint-Andre Message-ID: <49b9bc6e-d31a-b490-ee81-348cdb3a5947@stpeter.im> Date: Thu, 22 Dec 2016 13:29:04 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <24637769D123E644A105A0AF0E1F92EF010D2AA542@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Different conceptual model compared to earlier specifications 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, 22 Dec 2016 20:29:06 -0000 On 12/21/16 4:40 AM, Svensson, Lars wrote: > All, > > in draft-ietf-urnbis-rfc2141bis-urn-18 the final paragraph of section 1 reads: > > [[ > Summaries of changes from RFC 2141 and RFC 3406 appear in Appendix B and Appendix C respectively. This document obsoletes both [RFC2141] and [RFC3406]. While it does not explicitly update or replace [RFC1737] or [RFC2271], the reader who references those documents should be aware that the conceptual model of URNs in this document is slightly different from those older specifications. > ]] > > This last reference to a "conceptual model [that is] slightly different" leaves the reader hanging in mid-air as to the nature of those changes. I think it would be helpful to supply at least one example of such a difference. I think I'll leave that for John. :-) Peter From nobody Thu Dec 22 12:42: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 182451295C0 for ; Thu, 22 Dec 2016 12:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-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 es2DYTRWS9O9 for ; Thu, 22 Dec 2016 12:42:50 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3234F129435 for ; Thu, 22 Dec 2016 12:42:50 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5C90E400E0; Thu, 22 Dec 2016 13:45:11 -0700 (MST) To: "Svensson, Lars" , "urn@ietf.org" References: <24637769D123E644A105A0AF0E1F92EF010D2AA566@dnbf-ex1.AD.DDB.DE> From: Peter Saint-Andre Message-ID: Date: Thu, 22 Dec 2016 13:42:48 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <24637769D123E644A105A0AF0E1F92EF010D2AA566@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] q-component: What happens if the URL resolved to already has a query component? 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, 22 Dec 2016 20:42:51 -0000 On 12/21/16 4:56 AM, Svensson, Lars wrote: > All, > > This might be dealt with already, so please bear with me if I repeat > an old discussion... > > In §2.3.2 the following is said about the q-component (modulo Peter's > proposed changes): > > [[ The URN q-component has the same syntax as the URI query > component, but is introduced by "?=", not "?" alone. For URNs that > may be resolved to a URL, the semantics of the q-component are > identical to those for the query component of that URL. Thus URN > resolvers returning a URL for a URN with a q-component do this by > copying the q-component from the URN to the query component of the > URL. It the URN does not resolve to a URL, the interpretation of the > q-component is undefined by this specification. An example of the > copying operation appears below. ]] > > This leaves the question open, what will happen if a URN with a > q-component resolves to a URL that already has a query component. Hmm. You are correct that we have not considered this case. > My > take is that that case is outside the scope of 2141bis, but I think > we should be explicit about that and suggest that we add some text > along the following lines: > > [[ It is possible that a URN with a q-component resolve to a URL that > already has a query component. In that case, the final URL will end > up having a query component consisting of the URL's original query > component and the q-component from the URN. If the new query > component makes sense is outside the scope of this specification. ]] One messy aspect of this approach is the potential for overlap of fields in the query component. To use an artificial example, what if the URL query component includes a credit card field named "cc" and then the URN resolver attempts to append "CCResolve:cc=uk"? Now we have two fields named "cc" in the URL query component. Untangling this mess could be a matter for the URL resolver, or we could stipulate that the URN resolver needs to return an error. Alternatively, we could state some other rule (e.g., remove the URL query component) or leave this all up to the implementation. I'll think about this further. Peter From nobody Thu Dec 22 13:51: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 93AE81279EB for ; Thu, 22 Dec 2016 13:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 I7FLCShV__ls for ; Thu, 22 Dec 2016 13:51:54 -0800 (PST) Received: from seine.is.ed.ac.uk (seine.is.ed.ac.uk [129.215.17.202]) by ietfa.amsl.com (Postfix) with ESMTP id EA6791295AE for ; Thu, 22 Dec 2016 13:51:53 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by seine.is.ed.ac.uk (8.14.7/8.14.6) with ESMTP id uBMLpo9C014554; Thu, 22 Dec 2016 21:51:50 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id uBMLpox5021670; Thu, 22 Dec 2016 21:51:50 GMT 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 uBMLporU030393; Thu, 22 Dec 2016 21:51:50 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id uBMLpnvZ030392; Thu, 22 Dec 2016 21:51:49 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Peter Saint-Andre References: <24637769D123E644A105A0AF0E1F92EF010D2AA580@dnbf-ex1.AD.DDB.DE> <7387d698-2bc4-6a1b-dd1d-cb12ad7d0c8f@stpeter.im> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 22 Dec 2016 21:51:49 +0000 In-Reply-To: <7387d698-2bc4-6a1b-dd1d-cb12ad7d0c8f@stpeter.im> (Peter Saint-Andre's message of "Thu\, 22 Dec 2016 12\:17\:43 -0700") 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 seine.is.ed.ac.uk with MIMEDefang 2.78, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.78 on 129.215.17.202 Archived-At: Cc: "urn@ietf.org" , "Svensson, Lars" Subject: Re: [urn] f-component 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, 22 Dec 2016 21:51:56 -0000 Peter Saint-Andre writes: > Thus perhaps this is more correct: > > The f-component is primarily intended to distinguish the constituent > parts of a resource named by a URN. For a URN that resolves to one > or more locators which can be dereferenced to a representation, or > where the URN resolver directly returns a representation of the > resource, the semantics of an f-component are defined by the media > type of the representation, not by the URN namespace. I haven't compared that to the existing, but it looks true to me. 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 Dec 22 14:33:04 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 0728412960F for ; Thu, 22 Dec 2016 14:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 jE7NG_nMlgfu for ; Thu, 22 Dec 2016 14:33:00 -0800 (PST) Received: from loire.is.ed.ac.uk (loire.is.ed.ac.uk [129.215.16.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0671295EA for ; Thu, 22 Dec 2016 14:33:00 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by loire.is.ed.ac.uk (8.14.7/8.14.6) with ESMTP id uBMMWwWq023581; Thu, 22 Dec 2016 22:32:58 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id uBMMWw4c022688; Thu, 22 Dec 2016 22:32:58 GMT 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 uBMMWwmS032168; Thu, 22 Dec 2016 22:32:58 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id uBMMWvQi032167; Thu, 22 Dec 2016 22:32:57 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Peter Saint-Andre References: <24637769D123E644A105A0AF0E1F92EF010D2AA566@dnbf-ex1.AD.DDB.DE> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 22 Dec 2016 22:32:57 +0000 In-Reply-To: (Peter Saint-Andre's message of "Thu\, 22 Dec 2016 13\:42\:48 -0700") 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 loire.is.ed.ac.uk with MIMEDefang 2.78, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.78 on 129.215.16.10 Archived-At: Cc: "urn@ietf.org" , "Svensson, Lars" Subject: Re: [urn] q-component: What happens if the URL resolved to already has a query component? 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, 22 Dec 2016 22:33:03 -0000 It occurs to me that this might be related to a previously unsolved problem: consider the case where an HTTP redirect specifies a fragment, but the URI that launched the request had a fragment as well. Answer: confusion/competing standards/recommendations/practices, AFAI can tell. See e.g. http://stackoverflow.com/questions/2286402/url-fragment-and-302-redirects Or, consider that various serverside tools provide for a range of possible actions wrt the original query string and the query string in the redirect target, with various default behaviours if one or the other or both are/are not present [1], [2]. Net result: we don't want to get into specifying that, IMO: different resolvers will behave differently, just as different webserver configurations today behave differently with fragments and query strings. ht [1] http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewriteflags [2] https://www.viget.com/articles/merging-query-strings-when-redirecting-in-rails -- 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 Dec 22 23:01: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 CEE8D129975 for ; Thu, 22 Dec 2016 23:01:24 -0800 (PST) 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 3PIZXXlZapWt for ; Thu, 22 Dec 2016 23:01:22 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20115.outbound.protection.outlook.com [40.107.2.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97CCD12996E for ; Thu, 22 Dec 2016 23:01:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vA6TW6csdkQkWZZudRXjrqVbQ/ozEi97Vf9P5v8gn4g=; b=hgCNLFQA7ZcHJJkoYUQbT4y0z6IA0TrrxwOAdbFUM+4TLWVaazmtdB88FxYcxI7KZStmIZpK61Ufjz0aPyp9JGlyAliBSxzI1pRqmbQeG5xRXQ1S0uczaKZKSZBc2hgROh1kvEK1u0AikkM0ieeXN0QkBAp0kXHLPzFrLd3Zncg= Received: from HE1PR0701MB2603.eurprd07.prod.outlook.com (10.168.187.138) by HE1PR0701MB2602.eurprd07.prod.outlook.com (10.168.187.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.5; Fri, 23 Dec 2016 07:01:17 +0000 Received: from HE1PR0701MB2603.eurprd07.prod.outlook.com ([10.168.187.138]) by HE1PR0701MB2603.eurprd07.prod.outlook.com ([10.168.187.138]) with mapi id 15.01.0803.013; Fri, 23 Dec 2016 07:01:17 +0000 From: "Hakala, Juha E" To: Peter Saint-Andre , "Svensson, Lars" , "urn@ietf.org" Thread-Topic: [urn] f-component Thread-Index: AdJbggicRH5xNrFnQOarj3UbAHSVHwBBgkeAABeS3xA= Date: Fri, 23 Dec 2016 07:01:17 +0000 Message-ID: References: <24637769D123E644A105A0AF0E1F92EF010D2AA580@dnbf-ex1.AD.DDB.DE> <7387d698-2bc4-6a1b-dd1d-cb12ad7d0c8f@stpeter.im> In-Reply-To: <7387d698-2bc4-6a1b-dd1d-cb12ad7d0c8f@stpeter.im> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [128.214.71.222] x-ms-office365-filtering-correlation-id: 74cf51bc-f8b2-43f1-f765-08d42b017e1d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0701MB2602; x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2602; 7:GkeXIHgk2VanNKWHmQe5rqIhW9QCccM4Ml4OBmzSgJZnRHXBybDwzPTqLP1rrr5xcoM8SyPiirgFAg1Z8BtvK14L8mqNEPP2aPEnLjSbNHrZATy7BoXtWOQYvSpCORkZxPBq4BjwFGzlr9QCbeISJtrpKHb2Koi0gHIu52ApJjspqYWb/HlihZ7P186dK3fnqXk/sNUVyxEjqUE4KOncSt9KWlcqFlFEtalmjG17rBpbiPIGnYo76avWNgGDJxKNXyhnALuPFl8SIQ/sX3fwT2SvzBoN1OtnR+VzbeMbVK67gdv16l1j/Me3rro/9d3m35G4QvNw+uKZvXtiymxQ4HhleRek73aMsgLZLgCl8uMIERH5UNwkEnsDxDfGhnc3Lda2XuhhijQi2/LDff0e2HgpdGKeY93I20JEVHy/Ueyr7BO89oWYVd/3QPJt/BRasM1+RtkAkxc+HMSrrMHzFw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:HE1PR0701MB2602; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2602; x-forefront-prvs: 016572D96D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(189002)(377454003)(199003)(24454002)(13464003)(68736007)(86362001)(31430400001)(2906002)(77096006)(92566002)(38730400001)(33656002)(76576001)(6506006)(107886002)(2900100001)(6436002)(189998001)(25786008)(122556002)(105586002)(106356001)(102836003)(6116002)(3846002)(5001770100001)(66066001)(229853002)(97736004)(9686002)(305945005)(76176999)(7736002)(7696004)(74316002)(81156014)(50986999)(8676002)(8936002)(2501003)(54356999)(3660700001)(5660300001)(2950100002)(74482002)(3280700002)(81166006)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2602; H:HE1PR0701MB2603.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2016 07:01:17.4685 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2602 Archived-At: Subject: Re: [urn] f-component 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, 23 Dec 2016 07:01:25 -0000 SGVsbG8sIA0KDQpDb21tZW50cyBpbmxpbmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IHVybiBbbWFpbHRvOnVybi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgUGV0ZXIgU2FpbnQtQW5kcmUNCj4gU2VudDogMjIuIGpvdWx1a3V1dGEgMjAxNiAyMToxOA0K PiBUbzogU3ZlbnNzb24sIExhcnMgPEwuU3ZlbnNzb25AZG5iLmRlPjsgdXJuQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBbdXJuXSBmLWNvbXBvbmVudA0KPiANCj4gT24gMTIvMjEvMTYgNTowMSBB TSwgU3ZlbnNzb24sIExhcnMgd3JvdGU6DQo+ID4gQWxsLA0KPiA+DQo+ID4gaW4gdmVyc2lvbi0x OCwgdGhlIHBlbnVsdGltYXRlIHBhcmFncmFwaCBvZiDCpzIuMy4zIHNheXMgdGhlIGZvbGxvd2lu Zw0KPiA+IGFib3V0IHRoZSBzZW1hbnRpY3Mgb2YgdGhlIGYtY29tcG9uZW50Og0KPiA+DQo+ID4g W1sgVGhlIGYtY29tcG9uZW50IGlzIHByaW1hcmlseSBpbnRlbmRlZCB0byBkaXN0aW5ndWlzaCB0 aGUNCj4gPiBjb25zdGl0dWVudCBwYXJ0cyBvZiByZXNvdXJjZXMgbmFtZWQgYnkgVVJOcy4gVGh1 cywgZm9yIFVSTnMgdGhhdA0KPiA+IHJlc29sdmUgdG8gVVJMcyBvZiB0aGUgbmFtZWQgcmVzb3Vy Y2VzLCB0aGUgc2VtYW50aWNzIG9mIGFuDQo+ID4gZi1jb21wb25lbnQgYXJlIGRlZmluZWQgYnkg dGhlIG1lZGlhIHR5cGUgb2YgdGhvc2UgcmVzb3VyY2VzLCBub3QgYnkNCj4gPiB0aGUgVVJOIG5h bWVzcGFjZS4gXV0NCj4gPg0KPiA+IFRoaXMgbGVhdmVzIG91dCB3aGF0IHRoZSBzZW1hbnRpY3Mg b2YgdGhlIGYtY29tcG9uZW50IGlzIGlmIHRoZSBVUk4NCj4gPiByZXNvbHZlciBkb2Vzbid0IHJl c29sdmUgdG8gYSBVUkwgYnV0IHJldHVybnMgdGhlIHJlc291cmNlIChlLiBnLiBhDQo+ID4gZG9j dW1lbnQpIGRpcmVjdGx5LCB3aXRob3V0IHJlZGlyZWN0aW5nIHRoZSBhZ2VudCB0byBhbm90aGVy IGxvY2F0aW9uLg0KPiA+IEkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIG1pbm9yIGVkaXQ6DQo+ID4N Cj4gPiBbWyBUaGUgZi1jb21wb25lbnQgaXMgcHJpbWFyaWx5IGludGVuZGVkIHRvIGRpc3Rpbmd1 aXNoIHRoZQ0KPiA+IGNvbnN0aXR1ZW50IHBhcnRzIG9mIHJlc291cmNlcyBuYW1lZCBieSBVUk5z LiBUaHVzLCBmb3IgVVJOcyB0aGF0DQo+ID4gcmVzb2x2ZSB0byBVUkxzIG9mIHRoZSBuYW1lZCBy ZXNvdXJjZXMgb3Igd2hlcmUgdGhlIFVSTiByZXNvbHZlcg0KPiA+IHJldHVybnMgdGhlIHJlc291 cmNlIGRpcmVjdGx5LCB0aGUgc2VtYW50aWNzIG9mIGFuIGYtY29tcG9uZW50IGFyZQ0KPiA+IGRl ZmluZWQgYnkgdGhlIG1lZGlhIHR5cGUgb2YgdGhvc2UgcmVzb3VyY2VzLCBub3QgYnkgdGhlIFVS Tg0KPiA+IG5hbWVzcGFjZS4gXV0NCj4gDQo+IEkgd291bGQgbGlrZSB0byB0aGluayBhYm91dCB0 aGlzIHNvbWUgbW9yZS4gSW4gcGFydGljdWxhciwgSSBhbSBub3Qgc3VyZSBpdCdzDQo+IHJpZ2h0 IHRvIHNheSB0aGF0IGEgVVJOIHJlc29sdmVyIG1pZ2h0ICJyZXR1cm4gYSByZXNvdXJjZSIsIGJl Y2F1c2UgSSBiZWxpZXZlDQo+IHRoYXQgaXQgd291bGQgcmV0dXJuICh2aWEgZGVyZWZlcmVuY2lu ZykgZWl0aGVyIGEgcmVwcmVzZW50YXRpb24gb2YgdGhlDQo+IHJlc291cmNlIG9yIG1ldGFkYXRh IGFib3V0IHRoZSByZXNvdXJjZSwgYW5kIEkgZnVydGhlciBiZWxpZXZlIHRoZSBmLQ0KPiBjb21w b25lbnQgYXBwbGllcyBvbmx5IHRvIHJlcHJlc2VudGF0aW9ucyBhbmQgbm90IHRvIG1ldGFkYXRh IChidXQgSSBtaWdodA0KPiBiZSB3cm9uZyBhYm91dCB0aGF0KS4NCg0KRi1jb21wb25lbnQgY2Fu IGJlIGFwcGxpZWQgdG8gdGhlIGlkZW50aWZpZWQgcmVzb3VyY2Ugb25seSwgbm90IHRvIG1ldGFk YXRhIGFib3V0IHRoZSByZXNvdXJjZSBvciBhbnkgb3RoZXIgc3Vycm9nYXRlIHRoZSByZXNvbHV0 aW9uIHByb2Nlc3MgbWF5IGNvbWUgdXAgd2l0aCwgc3VjaCBhcyBhIGxpc3Qgb2YgVVJMcyBmcm9t IHdoaWNoIHRoZSB1c2VyIG1heSBmaW5kIGFsdGVybmF0aXZlIHZlcnNpb25zIG9mIHRoZSByZXNv dXJjZSBpbiBkaWZmZXJlbnQgZmlsZSBmb3JtYXRzLCBvciBvbmUgb2YgdGhlc2UgYWx0ZXJuYXRp dmVzLiANCg0KUmVzb2x2ZXIgaXMgbm90IGF3YXJlIG9mIHRoZSBmLWNvbXBvbmVudCwgc28gaWYg dGhlIHJlc29sdXRpb24gcHJvY2VzcyBoYXMgYmVlbiBzZXQgdXAgaW4gc3VjaCBhIHdheSB0aGF0 IHRoZSBjbGllbnQgbWF5IGFsc28gZ2V0IGEgc3Vycm9nYXRlICBpbnN0ZWFkIG9mIHRoZSByZWFs IHRoaW5nLCB0aGUgY2xpZW50IG1heSByZWNlaXZlIGFuIGluZm9ybWF0aW9uIHJlc291cmNlIHRo ZSBmLWNvbXBvbmVudCBjYW5ub3QgYmUgYXBwbGllZCB0by4gSWYgc28sIHRoZSBjbGllbnQgYXBw bGljYXRpb24gd2lsbCBiZWhhdmUgYXMgdXN1YWwgKGxlYXZlcyB0aGUgdXNlciB0byB0aGUgYmVn aW5uaW5nIG9mIHRoZSByZXNvdXJjZSBpbnN0ZWFkIG9mIHRoZSBkZXNpcmVkIGxvY2F0aW9uKS4g SSBhbSBub3Qgc3VyZSBpZiB3ZSBuZWVkIHRvIG1lbnRpb24gdGhpcy4gDQoNCkYtY29tcG9uZW50 cyBjYW4gb25seSBiZSB1c2VkIGluIHRob3NlIG5hbWVzcGFjZXMgaW4gd2hpY2ggdGhlIFVSTnMg cGVyc2lzdGVudGx5IGlkZW50aWZ5IGluZGl2aWR1YWwgaW5mb3JtYXRpb24gcmVzb3VyY2VzIHN1 Y2ggYXMgZWxlY3Ryb25pYyBib29rcywgaWYgYW5kIHdoZW4gYXQgbGVhc3Qgc29tZSBvZiB0aGVz ZSByZXNvdXJjZXMgaGF2ZSBhcHBsaWNhYmxlIG1lZGlhIHR5cGVzLiBTbyBmLWNvbXBvbmVudCBj YW4gYmUgdXNlZCBpbiB1cm46aXNibiB3aGVuIHRoZSByZXNvdXJjZSBpcyBhbiBlbGVjdHJvbmlj IGJvb2sgaW4gYXBwcm9wcmlhdGUgZmlsZSBmb3JtYXQsIGJ1dCBpdCBpcyBub3QgYXBwbGljYWJs ZSBpbiB1cm46aXNzbi4gQnV0IGlmIHRoZSB1c2VyIGdldHMgYW4gSFRNTCB2ZXJzaW9uIG9mIGEg Ym9vayBpbnN0ZWFkIG9mIFBERiwgZi1jb21wb25lbnQgZG9lcyBub3Qgd29yay4gIA0KPiANCj4g VGh1cyBwZXJoYXBzIHRoaXMgaXMgbW9yZSBjb3JyZWN0Og0KPiANCj4gICAgIFRoZSBmLWNvbXBv bmVudCBpcyBwcmltYXJpbHkgaW50ZW5kZWQgdG8gZGlzdGluZ3Vpc2ggdGhlIGNvbnN0aXR1ZW50 DQo+ICAgICBwYXJ0cyBvZiBhIHJlc291cmNlIG5hbWVkIGJ5IGEgVVJOLiAgRm9yIGEgVVJOIHRo YXQgcmVzb2x2ZXMgdG8gb25lDQo+ICAgICBvciBtb3JlIGxvY2F0b3JzIHdoaWNoIGNhbiBiZSBk ZXJlZmVyZW5jZWQgdG8gYSByZXByZXNlbnRhdGlvbiwgb3INCj4gICAgIHdoZXJlIHRoZSBVUk4g cmVzb2x2ZXIgZGlyZWN0bHkgcmV0dXJucyBhIHJlcHJlc2VudGF0aW9uIG9mIHRoZQ0KPiAgICAg cmVzb3VyY2UsIHRoZSBzZW1hbnRpY3Mgb2YgYW4gZi1jb21wb25lbnQgYXJlIGRlZmluZWQgYnkg dGhlIG1lZGlhDQo+ICAgICB0eXBlIG9mIHRoZSByZXByZXNlbnRhdGlvbiwgbm90IGJ5IHRoZSBV Uk4gbmFtZXNwYWNlLg0KDQpUaGlzIGlzIGZpbmUgd2l0aCBtZSBvdGhlcndpc2UsIGJ1dCB3ZSBt aWdodCB3YW50IHRvIGRyb3AgIm5vdCBieSB0aGUgVVJOIG5hbWVzcGFjZSIuICANCg0KSnVoYQ0K DQo+IA0KPiBQZXRlcg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gdXJuIG1haWxpbmcgbGlzdA0KPiB1cm5AaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91cm4NCg== From nobody Fri Dec 23 00:25: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 3A4681299A2 for ; Fri, 23 Dec 2016 00:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 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_H2=-0.001, 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 D0rCncg56vKB for ; Fri, 23 Dec 2016 00:25:15 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10105.outbound.protection.outlook.com [40.107.1.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F971299A3 for ; Fri, 23 Dec 2016 00:25:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UZzo+44+IOLAHSKM4o1bbw2cSZuygLxX1jK6ep++Jtc=; b=rvptRc1fkAff4j6+I9yQzAREtDMzsoMaJrBiEIT+AVSb1MICcuDrgltma51I6f39vOS6lmC0Nq8r3vG22PDfiEUX5QiEQJl3pDTwF/t6t4aQwqTPjcsMVukMFOlHe0w2RRC25uIZeFaySdN4Qh0V+O1nR4SmbUTraARnzI4+3FM= Received: from HE1PR0701MB2603.eurprd07.prod.outlook.com (10.168.187.138) by HE1PR0701MB2604.eurprd07.prod.outlook.com (10.168.187.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.5; Fri, 23 Dec 2016 08:25:10 +0000 Received: from HE1PR0701MB2603.eurprd07.prod.outlook.com ([10.168.187.138]) by HE1PR0701MB2603.eurprd07.prod.outlook.com ([10.168.187.138]) with mapi id 15.01.0803.013; Fri, 23 Dec 2016 08:25:11 +0000 From: "Hakala, Juha E" To: Peter Saint-Andre , "Svensson, Lars" , "urn@ietf.org" Thread-Topic: [urn] q-component: What happens if the URL resolved to already has a query component? Thread-Index: AdJbgTTymOJ4x03JS8udpQKCrSwSrABEr+YAABdUDLA= Date: Fri, 23 Dec 2016 08:25:11 +0000 Message-ID: References: <24637769D123E644A105A0AF0E1F92EF010D2AA566@dnbf-ex1.AD.DDB.DE> In-Reply-To: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [128.214.71.222] x-ms-office365-filtering-correlation-id: 96601bfa-04d4-4d7a-3717-08d42b0d366c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0701MB2604; x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2604; 7:vAjMAbSeBxN+/siphSqUVgBVWShGNbVxrh/HWBHMTf0rTod28kT0KYywnEvsMv1bKk8FxVSwmmCOWUeQi9V9wm4rJVkvW8MXthXg18btXEeA1OjeFMTUtDw8+1Xqk++eZAMjB5JiVnpCwaSLXXf90mJSClPt9IzD7FNAYezG6j+HsndS2pcWmEX9m3YlJNQSzq1OKQBEUQeTdGkR+ErlcvmMDwt+vctkcfWnRDrmZyUrvyO3b727qh3zG2FqNOFSDYBtN0LaEm1k4g4PabAXw2acE1wUfCBnFnZ3rfLcfjVB8j2GW3V7XhA8Si0Tz+xcQ6VV1aBIXdCDrqUwavkd/4vnudQWprT8cYvutKx53aV75ff3idKHrP9jYilL3w+5CYl6Ryjpt65xrN1oDyDc1BtjEb3WzHFSvqmHEDfOVXCjfie8lUmC3Io4ixO7xsTlisO0eror/sT24hEHx190Jg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558021)(20161123560025)(6072148); SRVR:HE1PR0701MB2604; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2604; x-forefront-prvs: 016572D96D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(199003)(13464003)(24454002)(377454003)(189002)(2906002)(7736002)(2900100001)(305945005)(25786008)(38730400001)(3660700001)(33656002)(86362001)(97736004)(6506006)(92566002)(6436002)(5001770100001)(2501003)(74316002)(3280700002)(77096006)(68736007)(76576001)(107886002)(5660300001)(76176999)(54356999)(50986999)(102836003)(6116002)(2950100002)(229853002)(189998001)(101416001)(122556002)(3846002)(7696004)(66066001)(9686002)(31430400001)(106356001)(74482002)(8676002)(81166006)(8936002)(81156014)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2604; H:HE1PR0701MB2603.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2016 08:25:11.2022 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2604 Archived-At: Subject: Re: [urn] q-component: What happens if the URL resolved to already has a query component? 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, 23 Dec 2016 08:25:18 -0000 SGVsbG8sIA0KDQpDb21tZW50cyBpbmxpbmUgYmVsb3cuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IHVybiBbbWFpbHRvOnVybi1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgUGV0ZXIgU2FpbnQtQW5kcmUNCj4gU2VudDogMjIuIGpvdWx1a3V1dGEgMjAxNiAy Mjo0Mw0KPiBUbzogU3ZlbnNzb24sIExhcnMgPEwuU3ZlbnNzb25AZG5iLmRlPjsgdXJuQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbdXJuXSBxLWNvbXBvbmVudDogV2hhdCBoYXBwZW5zIGlmIHRo ZSBVUkwgcmVzb2x2ZWQgdG8NCj4gYWxyZWFkeSBoYXMgYSBxdWVyeSBjb21wb25lbnQ/DQo+IA0K PiBPbiAxMi8yMS8xNiA0OjU2IEFNLCBTdmVuc3NvbiwgTGFycyB3cm90ZToNCg0KDQo+ID4gLi4u IHdoYXQgd2lsbCBoYXBwZW4gaWYgYSBVUk4gd2l0aCBhDQo+ID4gcS1jb21wb25lbnQgcmVzb2x2 ZXMgdG8gYSBVUkwgdGhhdCBhbHJlYWR5IGhhcyBhIHF1ZXJ5IGNvbXBvbmVudC4NCj4gDQo+IEht bS4gWW91IGFyZSBjb3JyZWN0IHRoYXQgd2UgaGF2ZSBub3QgY29uc2lkZXJlZCB0aGlzIGNhc2Uu DQo+IA0KPiA+IE15DQo+ID4gdGFrZSBpcyB0aGF0IHRoYXQgY2FzZSBpcyBvdXRzaWRlIHRoZSBz Y29wZSBvZiAyMTQxYmlzLCBidXQgSSB0aGluayB3ZQ0KPiA+IHNob3VsZCBiZSBleHBsaWNpdCBh Ym91dCB0aGF0IGFuZCBzdWdnZXN0IHRoYXQgd2UgYWRkIHNvbWUgdGV4dCBhbG9uZw0KPiA+IHRo ZSBmb2xsb3dpbmcgbGluZXM6DQo+ID4NCj4gPiBbWyBJdCBpcyBwb3NzaWJsZSB0aGF0IGEgVVJO IHdpdGggYSBxLWNvbXBvbmVudCByZXNvbHZlIHRvIGEgVVJMIHRoYXQNCj4gPiBhbHJlYWR5IGhh cyBhIHF1ZXJ5IGNvbXBvbmVudC4gSW4gdGhhdCBjYXNlLCB0aGUgZmluYWwgVVJMIHdpbGwgZW5k IHVwDQo+ID4gaGF2aW5nIGEgcXVlcnkgY29tcG9uZW50IGNvbnNpc3Rpbmcgb2YgdGhlIFVSTCdz IG9yaWdpbmFsIHF1ZXJ5DQo+ID4gY29tcG9uZW50IGFuZCB0aGUgcS1jb21wb25lbnQgZnJvbSB0 aGUgVVJOLiBJZiB0aGUgbmV3IHF1ZXJ5DQo+IGNvbXBvbmVudA0KPiA+IG1ha2VzIHNlbnNlIGlz IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gXV0NCg0KV2UgbWlnaHQg YWxzbyBzYXkgdGhhdCBpZiBhIFVSTiB3aXRoIGEgcS1jb21wb25lbnQgcmVzb2x2ZXMgdG8gYSBV UkwgdGhhdCBhbHJlYWR5IGhhcyBhIHF1ZXJ5IGNvbXBvbmVudCwgdGhlIHEtY29tcG9uZW50IHNo YWxsIHJlcGxhY2UgdGhlIG9yaWdpbmFsIHF1ZXJ5IGNvbXBvbmVudCBpbiB0aGUgcmVzb2x1dGlv biBwcm9jZXNzLiBUaGVuIHRoZSByZXN1bHRpbmcgcXVlcnkgY29tcG9uZW50IHNob3VsZCBtYWtl IHNlbnNlLCBhbmQgcHJvZHVjZSB0aGUgcmVzdWx0IHRoZSBjbGllbnQgd2FudHMuIFRoZXJlIGlz IG5vIGd1YXJhbnRlZSB0aGF0IHRoZSBjb21iaW5lZCBxdWVyeSB3b3VsZCBkbyB0aGF0LiAgIA0K DQpJZiBhIHJlc29sdmVyIGhhcyBhIGRlZmF1bHQgcmVzb2x1dGlvbiBzZXJ2aWNlIGVzdGFibGlz aGVkIHdpdGggYSBxdWVyeSBjb21wb25lbnQsIGNsaWVudHMgc2hvdWxkIHN0aWxsIGJlIGFibGUg dG8gcmVxdWlyZSBvdGhlciBzZXJ2aWNlcyB3aGljaCBtYXkgYmUgc3VwcGxpZWQgYnkgb3RoZXIg cS1jb21wb25lbnRzLiBPdmVyd3JpdGluZyB0aGUgZGVmYXVsdCBxdWVyeSBjb21wb25lbnQgLSBp ZiB0aGVyZSBpcyBvbmUgLSB3aWxsIGZhY2lsaXRhdGUgdGhpcyBmdW5jdGlvbmFsaXR5LiBLZWVw aW5nIGJvdGggZXhpc3RpbmcgcXVlcnkgY29tcG9uZW50IGFuZCBpbmNvbWluZyBxLWNvbXBvbmVu dCBpbiB0aGUgZmluYWwgVVJMIGlzLCBpbiBteSBvcGluaW9uLCBhIGJhZCBjaG9pY2UgYmVjYXVz ZSBpdCBpcyBsaWtlbHkgdGhhdCB0aGUgcmVzdWx0aW5nIGNvbWJvLXF1ZXJ5IGRvZXMgbm90IG1h a2Ugc2Vuc2UgZWl0aGVyIHRvIHRoZSByZXNvdXJjZSBvciB0byB0aGUgc3lzdGVtIHN1cHBseWlu ZyB0aGUgcmVzb3VyY2UuIFJlc29sdmVycyBhcmUgbm90IHJlcXVpcmVkIHRvIGJlIGFibGUgdG8g cGFyc2UgcS1jb21wb25lbnRzLCBhbmQgdGhlcmVmb3JlIHdlIGNhbm5vdCB0cnVzdCB0aGVtIHRv IG1ha2Ugc2FuaXR5IGNoZWNrcy4gDQoNClNpbmNlIFVSTiByZXNvbHZlcnMgaGF2ZSBub3QgYmVl biBkZWFsaW5nIHdpdGggcS1jb21wb25lbnRzIHlldCwgdGhlcmUgYXJlIG5vIHJlc29sdmVycyBv dXQgdGhlcmUgYWxyZWFkeSBiZWhhdmluZyBpbiBzb21lIG90aGVyIHdheS4gDQogDQo+IE9uZSBt ZXNzeSBhc3BlY3Qgb2YgdGhpcyBhcHByb2FjaCBpcyB0aGUgcG90ZW50aWFsIGZvciBvdmVybGFw IG9mIGZpZWxkcyBpbiB0aGUNCj4gcXVlcnkgY29tcG9uZW50Lg0KPiANCj4gVG8gdXNlIGFuIGFy dGlmaWNpYWwgZXhhbXBsZSwgd2hhdCBpZiB0aGUgVVJMIHF1ZXJ5IGNvbXBvbmVudCBpbmNsdWRl cyBhDQo+IGNyZWRpdCBjYXJkIGZpZWxkIG5hbWVkICJjYyIgYW5kIHRoZW4gdGhlIFVSTiByZXNv bHZlciBhdHRlbXB0cyB0byBhcHBlbmQNCj4gIkNDUmVzb2x2ZTpjYz11ayI/IE5vdyB3ZSBoYXZl IHR3byBmaWVsZHMgbmFtZWQgImNjIiBpbiB0aGUgVVJMIHF1ZXJ5DQo+IGNvbXBvbmVudC4gVW50 YW5nbGluZyB0aGlzIG1lc3MgY291bGQgYmUgYSBtYXR0ZXIgZm9yIHRoZSBVUkwgcmVzb2x2ZXIs IG9yDQo+IHdlIGNvdWxkIHN0aXB1bGF0ZSB0aGF0IHRoZSBVUk4gcmVzb2x2ZXIgbmVlZHMgdG8g cmV0dXJuIGFuIGVycm9yLg0KPiBBbHRlcm5hdGl2ZWx5LCB3ZSBjb3VsZCBzdGF0ZSBzb21lIG90 aGVyIHJ1bGUgKGUuZy4sIHJlbW92ZSB0aGUgVVJMIHF1ZXJ5DQo+IGNvbXBvbmVudCkgb3IgbGVh dmUgdGhpcyBhbGwgdXAgdG8gdGhlIGltcGxlbWVudGF0aW9uLg0KDQpJIHdvdWxkIG5vdCB3YW50 IHRvIGxlYXZlIHRoaXMgaXNzdWUgb3BlbiBiZWNhdXNlIHRoZW4gd2UgZWl0aGVyIGdldCBxdWVz dGlvbnMgb2YgaG93IHRvIGltcGxlbWVudCB0aGlzIGZlYXR1cmUgY29ycmVjdGx5LCBvciBub24t aW50ZXJvcGVyYWJsZSByZXNvbHZlcnMuIA0KDQpKdWhhDQo+IA0KPiBJJ2xsIHRoaW5rIGFib3V0 IHRoaXMgZnVydGhlci4NCj4gDQo+IFBldGVyDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB1cm4gbWFpbGluZyBsaXN0DQo+IHVybkBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Vybg0K From nobody Fri Dec 23 00:31: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 874F2129473 for ; Fri, 23 Dec 2016 00:31:23 -0800 (PST) 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 SD3JQ_MsBGJT for ; Fri, 23 Dec 2016 00:31:22 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 79AA91296C2 for ; Fri, 23 Dec 2016 00:31:21 -0800 (PST) Received: from [192.168.178.20] ([93.217.95.27]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M4nYT-1cUL9z29S1-00yz9K; Fri, 23 Dec 2016 09:31:14 +0100 To: "Henry S. Thompson" , Peter Saint-Andre References: <24637769D123E644A105A0AF0E1F92EF010D2AA566@dnbf-ex1.AD.DDB.DE> From: Julian Reschke Message-ID: Date: Fri, 23 Dec 2016 09:31:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 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:/tiDg/FxkxFyko9Z0vhisaydw95v+jK6d1M4ACyQSbJATzhCJEW WsDMY60u1689MXAP6jmxSTDNjiamevtIQlByr3PHQ2XQJ8DDYezfGozhD2GwysRj1EV6cJ8 bdjquzECPvpg/j+Fsu0+qamOWIDQ8nx9ODfScMXA8WHsBchZrcIvV13Oe/ZGk4m6atvdhUl vneJRRI2+Aia9hYyYCKeA== X-UI-Out-Filterresults: notjunk:1;V01:K0:qHzC5U5XpDA=:x6Pg/1Gp+0Y6A/DUpIqQ8N T9nI8b0qvEOn+ybQ8FfQzzo04vn3Q7oyu19VTDJ29vZCvNvxx5J2bhFkiCeLtKyh1N+u77aWj SsUS7aslKnHJJ4tG6a82akQ90Jx6E7oVdnuSHJjaKUIgPY+RJw2DMpnHw4FGcAZdmyH8KRM4E mXnhLwuVfjjCmTfLQpMKZ6Odtcn9/ODrmNoXNKYzED+R9lBXTZPgeSHq3MdUWHT9SePVq8WEC xEszXkO2TGcKXVxJnk7bc5fvcHL3ShAv9YLp4GykgxT7Toh5+a5Z0i7PDVhgSxQWERVCB3Zxg 1WpPt8C0ARWJDUJ67bccGC74m0TOvXr6vsI+1Wln4xJXR40FfI3sJDr6cFdZKcoSDyHfOA31a GtSsxN6u4kPrrhFw6qa4dnhsW9N7Jga0keLSoEk+HWIdODFKtESBlu+DBd+jHUwzdzz3SmCly W09lNgIOXBFtoWoKaf1rW3MS0tCHum8voxkCDW+8eK7aocXg9YFMi+VEVWHvyeLgA2W5iIp1H 2dy5m6znEUsRPHcna4fApqeLHch5fYPHN1STGpYdAjT+mfEIIoJvVAkilMOiihWmX1PeuBXfQ uJud8eoBnjLlZBQs21mbyperiTkeYZjMlq17E2lzA0v/0gLXc7XO66gty4TXLDh5VekHpW2eB 6snvy4jlSIJ2ewcAEa2eD0qIWkJYKgtNDj9NdDX1+CUc4e0D0LfgZ/qzzKbHya5gq7NRhjOvv AvAeQ6A2kIAbHBER45rruQawKMDJeZcPxMrzp1CGpMafrClZQPntd1Yb8W1Y6uv/JuEoKB44n uT31JyQ Archived-At: Cc: "urn@ietf.org" , "Svensson, Lars" Subject: Re: [urn] q-component: What happens if the URL resolved to already has a query component? 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, 23 Dec 2016 08:31:23 -0000 On 2016-12-22 23:32, Henry S. Thompson wrote: > It occurs to me that this might be related to a previously unsolved > problem: consider the case where an HTTP redirect specifies a fragment, > but the URI that launched the request had a fragment as well. Answer: > confusion/competing standards/recommendations/practices, AFAI can tell. > See e.g. > > http://stackoverflow.com/questions/2286402/url-fragment-and-302-redirects > ... There's one standard, and I believe what it says is actually implemented by most UAs... Best regards, Julian From nobody Tue Dec 27 11:53:22 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 22DC31296E3 for ; Tue, 27 Dec 2016 11:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 U7bBmWanluJA for ; Tue, 27 Dec 2016 11:53:19 -0800 (PST) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5031129553 for ; Tue, 27 Dec 2016 11:53:19 -0800 (PST) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cLxny-000NGJ-Tq; Tue, 27 Dec 2016 14:53:02 -0500 Date: Tue, 27 Dec 2016 14:52:57 -0500 From: John C Klensin To: Julian Reschke , "Henry S. Thompson" , Peter Saint-Andre Message-ID: <3D5D1FE441F04FF4F9F1B33B@JcK-HP5.jck.com> In-Reply-To: References: <24637769D123E644A105A0AF0E1F92EF010D2AA566@dnbf-ex1.AD.DDB.DE> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Cc: urn@ietf.org, "Svensson, Lars" Subject: Re: [urn] q-component: What happens if the URL resolved to already has a query component? 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, 27 Dec 2016 19:53:21 -0000 --On Friday, December 23, 2016 9:31 AM +0100 Julian Reschke wrote: > On 2016-12-22 23:32, Henry S. Thompson wrote: >> It occurs to me that this might be related to a previously >> unsolved problem: consider the case where an HTTP redirect >> specifies a fragment, but the URI that launched the request >> had a fragment as well. Answer: confusion/competing >> standards/recommendations/practices, AFAI can tell. See e.g. >> >> http://stackoverflow.com/questions/2286402/url-fragment-and >> -302-redirects ... > > There's one standard, and I believe what it says is actually > implemented by most UAs... Julian, assuming the "one standard" part correct, do you believe that 2141bis needs a reference to it and, if so, what reference? Or, if you believe that this is not an issue, despite Henry's and Juha's concerns, could you explain a bit more about why? thanks and regards, john From nobody Tue Dec 27 14:34: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 6EF9512950C for ; Tue, 27 Dec 2016 14:34:31 -0800 (PST) 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 9zfZHWPF2T0l for ; Tue, 27 Dec 2016 14:34:30 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 A1B65129438 for ; Tue, 27 Dec 2016 14:34:29 -0800 (PST) Received: from [192.168.178.20] ([93.217.89.222]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LwJRe-1cbieW06es-0185GF; Tue, 27 Dec 2016 23:34:14 +0100 To: John C Klensin , "Henry S. Thompson" , Peter Saint-Andre References: <24637769D123E644A105A0AF0E1F92EF010D2AA566@dnbf-ex1.AD.DDB.DE> <3D5D1FE441F04FF4F9F1B33B@JcK-HP5.jck.com> From: Julian Reschke Message-ID: Date: Tue, 27 Dec 2016 23:34:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <3D5D1FE441F04FF4F9F1B33B@JcK-HP5.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:zp3cxJkkqAoMAXR2XX5L/VQGKYzhij8eWN/85mbbpb6lYU+v5HU 1iHScMAfUz9t+j4/Mkqa942GhuW65LrSnpM1RAaG0VH9bgCqRR29W8sxrsUp9JNd24JPJYL pHqqzllfPHtDn15lknejm4OXPsaLYrE2aL2hNe8nOsirwmpQTbCDXc+UN8tB9J0+Cwi4iGd 9VbQjdk9sxZi2dHw53z2A== X-UI-Out-Filterresults: notjunk:1;V01:K0:6uaT9hTn18M=:9JwlmE648S18yb8g13uxQ7 tv0+vjTqgT2El/sQ2yZYjlK0996+dOYzLDb0l2kTjf/o9kpluHBxYxl+1OOjFUQ5ViLs5jSsp d28JY3Vey4zJg3SduofZrAYlSYqCIQUUv1Urcv2JKfcN69FypFocq4pVlbHu09njPveQ7e+wX sWNmEjvc+hdwI47JILaioj+jfs/k9S53GSNVRusDqaGkCKY5azrBUX7HRHI5io5++Ji5+Ibmo LVemjTxBJ1WoU3QPkD68wdJ7wuFZgz2TCN00bsbJO0tOmbud3TKc0/yw2Pwe6U5xtgV3pl3dh zhKjGu65KmntXwYR21pIEUHhZ0RoSD6GY0ckRtxlyct5OsSml/Wqzst+fbsR6wvoKQ/bJQ1P8 KB54UJqqlwbUtdZczyguKXcmFz5Oiaot2XegLj4ACfmdE0PuDDN/x7+2ZW/KTI8vtDN8QTvPw lEQNwchCl60qPXgl2ldIMeUy95xiSr5grC6Dsyhxthks0sSh2NIkVfHn5oQ5w8HemPKYgYACT KAyto4SNvZ6d9BlWcQ8f4okQh12YhF1Xy3W/oatY7igOAMzIi6kgDWct14P8MxfE2BkqGvj7y 3zH6yCYDW6Tes4EysgsbAlB+vxpDmic2fUwKaLBJB5TOOlOoGmsLjODQTmaKORi0jB0OlsHV3 CBxppEgu5Iod5a1euGmUg+mVJONA0zbeKR+WbVcTMyVbYSgXeaUNffe3EpsW1DBbPtP76DYl6 ZZJaF1X2AhwmOZRgBluVjZmGhNd5GxziB0O9w5Jj4wZUMEo1ZeV1JgArz8bNzG38PnfZu2X2n SE6Ptsw Archived-At: Cc: urn@ietf.org, "Svensson, Lars" Subject: Re: [urn] q-component: What happens if the URL resolved to already has a query component? 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, 27 Dec 2016 22:34:31 -0000 On 2016-12-27 20:52, John C Klensin wrote: > > > --On Friday, December 23, 2016 9:31 AM +0100 Julian Reschke > wrote: > >> On 2016-12-22 23:32, Henry S. Thompson wrote: >>> It occurs to me that this might be related to a previously >>> unsolved problem: consider the case where an HTTP redirect >>> specifies a fragment, but the URI that launched the request >>> had a fragment as well. Answer: confusion/competing >>> standards/recommendations/practices, AFAI can tell. See e.g. >>> >>> http://stackoverflow.com/questions/2286402/url-fragment-and >>> -302-redirects ... >> >> There's one standard, and I believe what it says is actually >> implemented by most UAs... > > Julian, assuming the "one standard" part correct, do you believe > that 2141bis needs a reference to it and, if so, what reference? No, I don't think that the URN spec needs to talk about this, as it is about HTTP redirects. > ... Best regards, Julian From nobody Tue Dec 27 14:55:08 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 1044E12955B for ; Tue, 27 Dec 2016 14:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 RAjwoBUuC6eN for ; Tue, 27 Dec 2016 14:55:04 -0800 (PST) Received: from seine.is.ed.ac.uk (seine.is.ed.ac.uk [129.215.17.202]) by ietfa.amsl.com (Postfix) with ESMTP id 976A71293EE for ; Tue, 27 Dec 2016 14:55:04 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by seine.is.ed.ac.uk (8.14.7/8.14.6) with ESMTP id uBRMt0Q0023334; Tue, 27 Dec 2016 22:55:01 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id uBRMt0jk027416; Tue, 27 Dec 2016 22:55:00 GMT 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 uBRMt0rB021805; Tue, 27 Dec 2016 22:55:00 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id uBRMswJe021804; Tue, 27 Dec 2016 22:54:58 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Julian Reschke References: <24637769D123E644A105A0AF0E1F92EF010D2AA566@dnbf-ex1.AD.DDB.DE> <3D5D1FE441F04FF4F9F1B33B@JcK-HP5.jck.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 27 Dec 2016 22:54:58 +0000 In-Reply-To: (Julian Reschke's message of "Tue\, 27 Dec 2016 23\:34\:11 +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 seine.is.ed.ac.uk with MIMEDefang 2.78, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.78 on 129.215.17.202 Archived-At: Cc: urn@ietf.org, "Svensson, Lars" Subject: Re: [urn] q-component: What happens if the URL resolved to already has a query component? 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, 27 Dec 2016 22:55:07 -0000 Julian Reschke writes: > On 2016-12-27 20:52, John C Klensin wrote: >> >> Julian, assuming the "one standard" part correct, do you believe >> that 2141bis needs a reference to it and, if so, what reference? > > No, I don't think that the URN spec needs to talk about this, as it is > about HTTP redirects. There may or may not be a spec about the handling of query strings in various HTTP redirect cases. 2141bis doesn't _need_ to talk about that, but my point was that the case of q-components handling during URN resolution that Juha raised was in some ways parallel to the HTTP case, and the uncertain nature (IMO) of the situation wrt the HTTP case should be raise a 'caution' flag for 2141bis. My net: explicitly duck the issue: "This specification does not specify a required behaviour in the case of URN resolution to a locator when the original URN has a q-component and the locator has a query string. Different circumstance may require different approaches. Resolvers SHOULD document their strategy in such cases." 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 Dec 27 15:14:22 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 8807012947C for ; Tue, 27 Dec 2016 15:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 fknX6i_ZfBWU for ; Tue, 27 Dec 2016 15:14:19 -0800 (PST) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91BF1127735 for ; Tue, 27 Dec 2016 15:14:19 -0800 (PST) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cM0we-000Osp-OQ; Tue, 27 Dec 2016 18:14:12 -0500 Date: Tue, 27 Dec 2016 18:14:07 -0500 From: John C Klensin To: Peter Saint-Andre , "Svensson, Lars" Message-ID: In-Reply-To: <840c4bb0-7cd5-5a30-0390-6a6c49d8c515@stpeter.im> References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> <24637769D123E644A105A0AF0E1F92EF010D2AA515@dnbf-ex1.AD.DDB.DE> <840c4bb0-7cd5-5a30-0390-6a6c49d8c515@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Terminology -- 'resource' and 'abstract designator' 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, 27 Dec 2016 23:14:20 -0000 --On Thursday, December 22, 2016 11:56 AM -0700 Peter Saint-Andre wrote: > Hi Lars, thank you very much for your feedback. > On 12/21/16 4:26 AM, Svensson, Lars wrote: >... >> Here I don't quite agree with "The URN q-component has the >> same syntax as the query component in URI schemes for >> locators". That text implies that URI schemes that are not >> for locators have a different query component syntax. My >> suggestion would be to accept Peter's new version but keep >> the first sentence unchanged: >> >> [[ The URN q-component has the same syntax as the URI query >> component, but is introduced by "?=", not "?" alone. For >> URNs that may be resolved to a locator URI, the semantics of >> the q-component are identical to those for the query >> component of that URI. Thus URN resolvers returning a >> locator URI for a URN with a q-component do this by copying >> the q-component from the URN to the query component of the >> locator URI. If the URN does not resolve to a locator URI, >> the interpretation of the q-component is undefined by this >> specification. An example of the copying operation appears >> below. ]] [...] > You are right - thanks for pointing out this problem. As another small nit, I'm not sure where a "locator URI" is defined. The term certainly is not defined in 2141bis, nor does it appear in 3986. I'm ok with "locator" by itself (which does have origins in 3986 and that is defined in Section 1.1 of 2141bis), or "URI for a locator". I still don't fully understand why we have dropped "URL" in favor of "locator URI"s and similar unnatural constructions, but, if we are going to do so, "locator URI" is in need of a clear definition in Section 1.1. When I go back and reread Section 1.1.3 of RFC 3986, I think that any plausible definition takes us back to "URL" unless the intent is to get at the "both" case, but maybe I'm missing something. best, john From nobody Tue Dec 27 15: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 A9D9112947C for ; Tue, 27 Dec 2016 15:17:17 -0800 (PST) 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 v-8AwlhX6aUu for ; Tue, 27 Dec 2016 15:17:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 282ED127735 for ; Tue, 27 Dec 2016 15:17:16 -0800 (PST) Received: from [192.168.178.20] ([93.217.89.222]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MBFUT-1cEYKj2t5Z-00AEFJ; Wed, 28 Dec 2016 00:17:12 +0100 To: "Henry S. Thompson" References: <24637769D123E644A105A0AF0E1F92EF010D2AA566@dnbf-ex1.AD.DDB.DE> <3D5D1FE441F04FF4F9F1B33B@JcK-HP5.jck.com> From: Julian Reschke Message-ID: <8a614ba0-1cc2-7a5d-6bdc-4aaf7e1af976@gmx.de> Date: Wed, 28 Dec 2016 00:17:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 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:SD2OYPN6rD+XHY0iy9V8jB6Ras2VqgLoumUdNdssoA10PKH7i+k D48rXkFta0DSkDP4kG7lGtQ+hULdN0IrcWfqyCPkmDckTGFw9AqocFEixT0CV2jXpOVxh7Z E62xefMG9zFitvC1QnOeJqWG1fRzu79xRr6t4/O7FS4yTDHzfLKH8t1Fmk/P69jVBh+crrg SZMilhPhdlIwUQxlMZQCw== X-UI-Out-Filterresults: notjunk:1;V01:K0:xTdGZ3QIjLc=:8VlYMwyox4nusR7qoWD7cI 6FZUmDYsbAH4ARLSRkEoWE3Z9pkH82rSuOfqviliGA6GkEDYQIRWa7TwUwjc3BgjpY+Kh3LBW 3ifJOzbcKa++H8jrJmm6biRkbUmCFa1pzW9SerPOAs/hAOVprJO1BBrixpP0Fue+51fHINVgD NeStu4Ar3XsSqArJrvbpBqm1XP9XElfWbzcOQSYHGWQkVjxwLB9z1oDHGxm25GiNqv6yREUgL Nmx4EImNkIjwGnt0QAY0spukq/ZDkTbuWM01nVkYL49sA30iT6jzEFXM7B1+FAV3v8xtfcdU+ +0OCvFskyLqdhkMHZ73FLHUAqNxiIAIZNhWwSu00pCoLs/5uLVHrq+JbWW4yCEYFgEyl2tlvu KDUy+AsE5dkYpkB6eYQyl5T3jnwe5iGA92Wphc8e2h/ixX2FHbPeNZajj/ktfryZye64U7d/B skiIbW9Ux6K7UCjwSYBmwxF4vWAXG1H/VKo01VO8GHS1V+pztemBUHWTLT8gkXICsAPuVKp6y sxUVsKU8SQsntlAaFxblbkAUcYS/4Mh47eGBbZqq8ssPbRSIayZQM7PrglkC5qMw2YbEJR4Mi FB3ptQVhoyko/pwAsZqM33PQ15PGEuh81d+L+ShYA+ZX6WTABJC1yA9pCaS5ZJYJ5t1lkWfqE ii0i29M094Xu24Zvf4V9xV71114kxmWrpuUVIRVjUZI4LveJr4ZglMYaR59GxyEvZ6mzPv11O W6gWW2zNv9D9FjKYJiqGE3n9XsrK1xFH6U2rRkJ6U0Pt5aEZa+dWtpPhoj5OR87L4Gbel/7jH e24NcQ2 Archived-At: Cc: urn@ietf.org, "Svensson, Lars" Subject: Re: [urn] q-component: What happens if the URL resolved to already has a query component? 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, 27 Dec 2016 23:17:17 -0000 On 2016-12-27 23:54, Henry S. Thompson wrote: > Julian Reschke writes: > >> On 2016-12-27 20:52, John C Klensin wrote: >>> >>> Julian, assuming the "one standard" part correct, do you believe >>> that 2141bis needs a reference to it and, if so, what reference? >> >> No, I don't think that the URN spec needs to talk about this, as it is >> about HTTP redirects. > > There may or may not be a spec about the handling of query strings in > various HTTP redirect cases. 2141bis doesn't _need_ to talk about that, > but my point was that the case of q-components handling during URN > resolution that Juha raised was in some ways parallel to the HTTP case, > and the uncertain nature (IMO) of the situation wrt the HTTP case should > be raise a 'caution' flag for 2141bis. > ... How exactly is it "uncertain"? Do you believe there's something in RFC 7231 that needs to be fixed? Best regards, Julian From nobody Tue Dec 27 15:40: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 D1A80129771 for ; Tue, 27 Dec 2016 15:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 eZXUcTTREEVh for ; Tue, 27 Dec 2016 15:39:58 -0800 (PST) Received: from seine.is.ed.ac.uk (seine.is.ed.ac.uk [129.215.17.202]) by ietfa.amsl.com (Postfix) with ESMTP id A63D11293F9 for ; Tue, 27 Dec 2016 15:39:57 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by seine.is.ed.ac.uk (8.14.7/8.14.6) with ESMTP id uBRNdtOt029942; Tue, 27 Dec 2016 23:39:55 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id uBRNdtha028508; Tue, 27 Dec 2016 23:39:55 GMT 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 uBRNdtMG023584; Tue, 27 Dec 2016 23:39:55 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id uBRNdsSK023583; Tue, 27 Dec 2016 23:39:54 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Julian Reschke References: <24637769D123E644A105A0AF0E1F92EF010D2AA566@dnbf-ex1.AD.DDB.DE> <3D5D1FE441F04FF4F9F1B33B@JcK-HP5.jck.com> <8a614ba0-1cc2-7a5d-6bdc-4aaf7e1af976@gmx.de> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 27 Dec 2016 23:39:54 +0000 In-Reply-To: <8a614ba0-1cc2-7a5d-6bdc-4aaf7e1af976@gmx.de> (Julian Reschke's message of "Wed\, 28 Dec 2016 00\:17\:13 +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 seine.is.ed.ac.uk with MIMEDefang 2.78, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.78 on 129.215.17.202 Archived-At: Cc: urn@ietf.org, "Svensson, Lars" Subject: [urn] Off topic: 7321 and query strings 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, 27 Dec 2016 23:40:01 -0000 [Subject changed because this is no longer about 2141bis] Julian Reschke writes: > How exactly is [the HTTP redirection case when both original and > redirect target have query strings] "uncertain"? Do you believe > there's something in RFC 7231 that needs to be fixed? I don't see anything in 7231 at all about query string 'conflict' or merging or ... Where should I be looking? 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 Dec 27 16:20: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 62AB81294FF for ; Tue, 27 Dec 2016 16:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 rSM_V7CiL_5C for ; Tue, 27 Dec 2016 16:20:48 -0800 (PST) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94445126D74 for ; Tue, 27 Dec 2016 16:20:48 -0800 (PST) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cM1yw-000PU9-RV; Tue, 27 Dec 2016 19:20:38 -0500 Date: Tue, 27 Dec 2016 19:20:33 -0500 From: John C Klensin To: "Henry S. Thompson" , Julian Reschke Message-ID: In-Reply-To: References: <24637769D123E644A105A0AF0E1F92EF010D2AA566@dnbf-ex1.AD.DDB.DE> <3D5D1FE441F04FF4F9F1B33B@JcK-HP5.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 Archived-At: Cc: urn@ietf.org, "Svensson, Lars" Subject: Re: [urn] q-component: What happens if the URL resolved to already has a query component? 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, 28 Dec 2016 00:20:50 -0000 wfm. Text tentatively incorporated. thanks, john --On Tuesday, December 27, 2016 10:54 PM +0000 "Henry S. Thompson" wrote: > Julian Reschke writes: > >> On 2016-12-27 20:52, John C Klensin wrote: >>> >>> Julian, assuming the "one standard" part correct, do you >>> believe that 2141bis needs a reference to it and, if so, >>> what reference? >> >> No, I don't think that the URN spec needs to talk about this, >> as it is about HTTP redirects. > > There may or may not be a spec about the handling of query > strings in various HTTP redirect cases. 2141bis doesn't > _need_ to talk about that, but my point was that the case of > q-components handling during URN resolution that Juha raised > was in some ways parallel to the HTTP case, and the uncertain > nature (IMO) of the situation wrt the HTTP case should be > raise a 'caution' flag for 2141bis. > > My net: explicitly duck the issue: "This specification does > not specify a required behaviour in the case of URN resolution > to a locator when the original URN has a q-component and the > locator has a query string. Different circumstance may require > different approaches. Resolvers SHOULD document their > strategy in such cases." > > ht From nobody Tue Dec 27 16:31: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 B814E129450 for ; Tue, 27 Dec 2016 16:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Rc0hJ3QiYo1a for ; Tue, 27 Dec 2016 16:31:45 -0800 (PST) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95764129432 for ; Tue, 27 Dec 2016 16:31:45 -0800 (PST) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cM29e-000PZc-VI; Tue, 27 Dec 2016 19:31:42 -0500 Date: Tue, 27 Dec 2016 19:31:37 -0500 From: John C Klensin To: Peter Saint-Andre , "Svensson, Lars" Message-ID: <790A8878F75411ED9B8C17D4@JcK-HP5.jck.com> In-Reply-To: <4ab3f15d-c1e6-9015-ec19-996852b3e50e@stpeter.im> References: <24637769D123E644A105A0AF0E1F92EF010D2AA5C4@dnbf-ex1.AD.DDB.DE> <4ab3f15d-c1e6-9015-ec19-996852b3e50e@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Cc: urn@ietf.org Subject: Re: [urn] NID syntax 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, 28 Dec 2016 00:31:47 -0000 --On Thursday, December 22, 2016 12:24 PM -0700 Peter Saint-Andre wrote: > On 12/21/16 5:14 AM, Svensson, Lars wrote: >> All, >> >> The syntax for formal URN namespaces declares: >> >> [[ >> [...] >> 4. It MUST NOT start with ALPHA ALPHA "-", i. e. any string >> consisting of two letters followed by one hyphen". 5. It MUST >> NOT start with the string "xn--" or any other string >> consisting of two letters followed by two hyphens. [...] ]] >> >> To me this feels redundant. If it must not start with ALPHA >> ALPHA "-", "any other string consisting of two letters >> followed by two hyphens" is forbidden already. I think we >> could conflate those two to: >> >> [[ >> 4. It MUST NOT start with any string consisting of two >> letters followed by one or two hyphens. Such strings are >> reserved for potential representation of DNS A-labels and >> similar strings in the future [RFC5890]. ]] >> >> Or are ALPHA ALPHA "-"-Strings reserved for something else? >> If so, then we should explain why those are forbidden, too. > > I think this is clearer (combining the relevant rules and the > text that is currently shown after the bulleted list: > > 3. It MUST be more than two characters long and it > MUST NOT start with ALPHA ALPHA "-", i.e., any string > consisting of two letters followed by one hyphen; such > strings are reserved for potential use as NIDs based on > ISO alpha-2 country codes [ISO.3166-1] for eventual > national registrations of URN namespaces (however, the > definition and scoping of rules for allocation of > responsibility for such country-code-based URN > namespaces are beyond the scope of this document). That seems to me much better, but doesn't eliminate Lars's concern about redundancy. I've tentatively merged bullet 4 into bullet 3, making it clear that the latter is a special case, with an additional motivation, of the ' ALPHA ALPHA "-"' rule. john From nobody Tue Dec 27 16:49: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 98F1E129450 for ; Tue, 27 Dec 2016 16:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 1HDOXyuy89Za for ; Tue, 27 Dec 2016 16:49:25 -0800 (PST) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49CF1129432 for ; Tue, 27 Dec 2016 16:49:25 -0800 (PST) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cM2Qc-000Pes-PG; Tue, 27 Dec 2016 19:49:14 -0500 Date: Tue, 27 Dec 2016 19:49:09 -0500 From: John C Klensin To: "Hakala, Juha E" , Peter Saint-Andre , "Svensson, Lars" , urn@ietf.org Message-ID: In-Reply-To: References: <24637769D123E644A105A0AF0E1F92EF010D2AA580@dnbf-ex1.AD.DDB.DE> <7387d698-2bc4-6a1b-dd1d-cb12ad7d0c8f@stpeter.im> 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 Archived-At: Subject: Re: [urn] f-component 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, 28 Dec 2016 00:49:26 -0000 --On Friday, December 23, 2016 7:01 AM +0000 "Hakala, Juha E" wrote: > Hello,=20 >=20 > Comments inline.=20 >=20 >> -----Original Message----- >> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Peter >> Saint-Andre Sent: 22. joulukuuta 2016 21:18 >> To: Svensson, Lars ; urn@ietf.org >> Subject: Re: [urn] f-component >>=20 >> On 12/21/16 5:01 AM, Svensson, Lars wrote: >> > All, >> >=20 >> > in version-18, the penultimate paragraph of =C2=A72.3.3 = says >> > the following about the semantics of the f-component: >> >=20 >> > [[ The f-component is primarily intended to distinguish the >> > constituent parts of resources named by URNs. Thus, for >> > URNs that resolve to URLs of the named resources, the >> > semantics of an f-component are defined by the media type >> > of those resources, not by the URN namespace. ]] >> >=20 >> > This leaves out what the semantics of the f-component is if >> > the URN resolver doesn't resolve to a URL but returns the >> > resource (e. g. a document) directly, without redirecting >> > the agent to another location. I propose the following >> > minor edit: >> >=20 >> > [[ The f-component is primarily intended to distinguish the >> > constituent parts of resources named by URNs. Thus, for >> > URNs that resolve to URLs of the named resources or where >> > the URN resolver returns the resource directly, the >> > semantics of an f-component are defined by the media type >> > of those resources, not by the URN namespace. ]] >>=20 >> I would like to think about this some more. In particular, I >> am not sure it's right to say that a URN resolver might >> "return a resource", because I believe that it would return >> (via dereferencing) either a representation of the resource >> or metadata about the resource, and I further believe the f- >> component applies only to representations and not to metadata >> (but I might be wrong about that). >=20 > F-component can be applied to the identified resource only, > not to metadata about the resource or any other surrogate the > resolution process may come up with, such as a list of URLs > from which the user may find alternative versions of the > resource in different file formats, or one of these > alternatives.=20 >=20 > Resolver is not aware of the f-component, so if the resolution > process has been set up in such a way that the client may also > get a surrogate instead of the real thing, the client may > receive an information resource the f-component cannot be > applied to. If so, the client application will behave as usual > (leaves the user to the beginning of the resource instead of > the desired location). I am not sure if we need to mention > this.=20 >=20 > F-components can only be used in those namespaces in which the > URNs persistently identify individual information resources > such as electronic books, if and when at least some of these > resources have applicable media types. So f-component can be > used in urn:isbn when the resource is an electronic book in > appropriate file format, but it is not applicable in urn:issn. > But if the user gets an HTML version of a book instead of PDF, > f-component does not work. =20 >>=20 >> Thus perhaps this is more correct: >>=20 >> The f-component is primarily intended to distinguish the >> constituent parts of a resource named by a URN. For a >> URN that resolves to one or more locators which can be >> dereferenced to a representation, or where the URN >> resolver directly returns a representation of the >> resource, the semantics of an f-component are defined by >> the media type of the representation, not by the URN >> namespace. >=20 > This is fine with me otherwise, but we might want to drop "not > by the URN namespace". =20 Dropped. 3986 is very clear that it is bound to the media type of the representation and nothing else. Anything more we say here risks another argument about 3986 and scope. BTW, the first sentence of that paragraph is almost identical (but not quite) and certainly redundant with the first paragraph of 2.3.3 Suggestions welcome (the default is to just leave the redundancy). john From nobody Tue Dec 27 17:04: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 477F91294A5 for ; Tue, 27 Dec 2016 17:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 cdOcuonydVmv for ; Tue, 27 Dec 2016 17:04:08 -0800 (PST) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4040F12945B for ; Tue, 27 Dec 2016 17:04:08 -0800 (PST) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cM2ey-000PlO-C6; Tue, 27 Dec 2016 20:04:04 -0500 Date: Tue, 27 Dec 2016 20:03:59 -0500 From: John C Klensin To: Peter Saint-Andre , "Svensson, Lars" , urn@ietf.org Message-ID: In-Reply-To: <49b9bc6e-d31a-b490-ee81-348cdb3a5947@stpeter.im> References: <24637769D123E644A105A0AF0E1F92EF010D2AA542@dnbf-ex1.AD.DDB.DE> <49b9bc6e-d31a-b490-ee81-348cdb3a5947@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Subject: Re: [urn] Different conceptual model compared to earlier specifications 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, 28 Dec 2016 01:04:09 -0000 --On Thursday, December 22, 2016 1:29 PM -0700 Peter Saint-Andre wrote: >> This last reference to a "conceptual model [that is] slightly >> different" leaves the reader hanging in mid-air as to the >> nature of those changes. I think it would be helpful to >> supply at least one example of such a difference. > > I think I'll leave that for John. :-) Yeah, well... 3986 fans, please read all of the following before reacting. RFC 3986 is, IMO and given examples cited elsewhere (and a careful reading of the first few paragraphs of its introduction), mostly about locators, i.e., URLs, with a periodic nod to non-locator names (specifically of the "urn:" scheme persuasion). Its failure to treat URLs and URNs equally and to call out differences (whether it should have done so or not) and to be strictly conformant to 2141 has been a major source of debate and aggravation in this WG. >From that perspective, most of the discussions we have had about what identifiers are, whether or not things resolve, how to handle f-components when there are no media types, whether the term "resource" is clearly defined or just so much more hand waving about how broad the term can be, etc., etc., are all examples of those conceptual differences. The problem is that I don't think we want to say any of that in the document. I'm reluctant to say it even in this note. I continue to believe that we can finish 2141bis without challenging 3986 directly and that is what the WG has more or less told us to try to do. So, yes, I recognize that the comment calls for either examples or more explanation. I'm attempting a bit more explanation for -19 but imagine even it may be controversial. I don't know how to provide examples without directly challenging the legitimacy of 3986 and I really, really, don't want to do that at this point. best, john From nobody Wed Dec 28 00:57:46 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 3404B1295C4 for ; Wed, 28 Dec 2016 00:57:45 -0800 (PST) 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 V7a2GdveCbyT for ; Wed, 28 Dec 2016 00:57:43 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 3EFEE1295B1 for ; Wed, 28 Dec 2016 00:57:42 -0800 (PST) Received: from [192.168.178.20] ([93.217.105.61]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MIdTM-1cOLud1Diq-002ER9; Wed, 28 Dec 2016 09:57:39 +0100 To: "Henry S. Thompson" References: <24637769D123E644A105A0AF0E1F92EF010D2AA566@dnbf-ex1.AD.DDB.DE> <3D5D1FE441F04FF4F9F1B33B@JcK-HP5.jck.com> <8a614ba0-1cc2-7a5d-6bdc-4aaf7e1af976@gmx.de> From: Julian Reschke Message-ID: <555451de-f7ae-319a-21a5-d7fd577b1452@gmx.de> Date: Wed, 28 Dec 2016 09:57:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 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:lruFsgjS0sA6w3FADR9bB29xaixZKtjh3dgqCFIA/X2mu2pVBXg HxNkQfjzxelnz/Emw8Idf0YDRTHCLubAR64qsLeZ40u3/ublZzzLbZolDIXZoDdlkqX6x0G WHkdWItUhHwgcBXSpcyn2sRBSV7qd/bE9Aji+2ciLe4l/uOe+FvOzGFPYe1kT05fyZRs2KC rOOKkNu4cgq62dfq8ob9g== X-UI-Out-Filterresults: notjunk:1;V01:K0:q4thRvL3gEI=:OBaD9mTCvaY0DxWsjEEM2D 98IM8VRbO2M6OFaCXIVKfKRzFcLDMorqo9ZpKqw9GFWB+KvDdYCiMQvbZjLkXm4NsoQAjQ3hZ ea3B7pak3dc5qvCQs3QFI0z7FT6A8sFo/QuNNgPKwxmDBLkQDxWIPKl1vyO0e3R60UVxRMoQz tmo4xIp4GOF0db9bDqyWLw1zDSiK0eOAqGWkGD8R87UMkZnIJDhEgCT9nnFKZzgDhJIvJNeqe P8YzJNO0luhPjsYcE9Yl/ouq47FZuOXZK71Rvayf6tzsCBl55gB3TlLUHBeLhSxpiUF/Nt4F9 RAjX7hjHKrasbExiswpjx3c+MviqBup20hMd7ylWM2SxT6Djy0Z/Xm8F38MDQLX/e+XmCDlLH 1wVz0Ptn4ooB4a2pZK5BlLljJm3dEKn450w0e0mWfhJHAaKYVkBwFxs+34RLvz843ZorpYEaV fEkTrtrgo1BVRPXackDpGil9Cqv4DJLytjF9o740yMVcoYuEfxK1JmSCbbsqrVnQEAdcPOnTD n4Zi71HOW2vuYw0sHaz+ijlyNeBIXRCRTLSq/2gBYlj7ZTlz6arlLEcf75l54hdfvMo+P9jCK D68cRVRoGi3ffraU8OVE0Hqeip70m0XOVgQgIlCWvFNoEvN9ZCHQKCxz7VW6XhLQlKrpl8dpz vtTtkVrz5vutQMyuasoiLB5e5PPLXUE2Rt9/PftlTq7JCZeQUBvEqdTj16Kfl1Pmm5tNTFkCY cr3Bs894HrBkkfnTE0a6gRDUfOdus2NqE2/qb5fQJ7tOInq6Qv11Ni/Q7u8+PulsugtCpuN9U qIBHldn Archived-At: Cc: urn@ietf.org, "Svensson, Lars" Subject: Re: [urn] Off topic: 7321 and query strings 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, 28 Dec 2016 08:57:45 -0000 On 2016-12-28 00:39, Henry S. Thompson wrote: > [Subject changed because this is no longer about 2141bis] > > Julian Reschke writes: > >> How exactly is [the HTTP redirection case when both original and >> redirect target have query strings] "uncertain"? Do you believe >> there's something in RFC 7231 that needs to be fixed? > > I don't see anything in 7231 at all about query string 'conflict' or > merging or ... Where should I be looking? Ah, I misread. Thought this was solely about fragment identifiers. It doesn't say anything about merging query strings, because they aren't. It's not part of the reference resolution defined in RFC 3986. Are you aware of any user agents doing something like merging on redirects? Best regards, Julian From nobody Wed Dec 28 17:27:42 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 96C28129484 for ; Wed, 28 Dec 2016 17:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-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 GZt1Aa6_SvIh for ; Wed, 28 Dec 2016 17:27:39 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B2D80128B37 for ; Wed, 28 Dec 2016 17:27:39 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7C6C1400FA; Wed, 28 Dec 2016 18:30:26 -0700 (MST) To: John C Klensin , "Henry S. Thompson" , Julian Reschke References: <24637769D123E644A105A0AF0E1F92EF010D2AA566@dnbf-ex1.AD.DDB.DE> <3D5D1FE441F04FF4F9F1B33B@JcK-HP5.jck.com> From: Peter Saint-Andre Message-ID: Date: Wed, 28 Dec 2016 18:27:37 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: urn@ietf.org, "Svensson, Lars" Subject: Re: [urn] q-component: What happens if the URL resolved to already has a query component? 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, 29 Dec 2016 01:27:40 -0000 On 12/27/16 5:20 PM, John C Klensin wrote: > wfm. Text tentatively incorporated. WFM too. Peter From nobody Wed Dec 28 17:29: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 A4EA1129484 for ; Wed, 28 Dec 2016 17:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-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 cWaLJdDbESY6 for ; Wed, 28 Dec 2016 17:29:18 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B73FE128B37 for ; Wed, 28 Dec 2016 17:29:18 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0E937400FA; Wed, 28 Dec 2016 18:32:05 -0700 (MST) To: John C Klensin , "Svensson, Lars" References: <24637769D123E644A105A0AF0E1F92EF010D2AA5C4@dnbf-ex1.AD.DDB.DE> <4ab3f15d-c1e6-9015-ec19-996852b3e50e@stpeter.im> <790A8878F75411ED9B8C17D4@JcK-HP5.jck.com> From: Peter Saint-Andre Message-ID: <393dacd2-8ad6-fdcb-ac22-23579e4c33ea@stpeter.im> Date: Wed, 28 Dec 2016 18:29:17 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <790A8878F75411ED9B8C17D4@JcK-HP5.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] NID syntax 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, 29 Dec 2016 01:29:19 -0000 On 12/27/16 5:31 PM, John C Klensin wrote: > > > --On Thursday, December 22, 2016 12:24 PM -0700 Peter > Saint-Andre wrote: > >> On 12/21/16 5:14 AM, Svensson, Lars wrote: >>> All, >>> >>> The syntax for formal URN namespaces declares: >>> >>> [[ >>> [...] >>> 4. It MUST NOT start with ALPHA ALPHA "-", i. e. any string >>> consisting of two letters followed by one hyphen". 5. It MUST >>> NOT start with the string "xn--" or any other string >>> consisting of two letters followed by two hyphens. [...] ]] >>> >>> To me this feels redundant. If it must not start with ALPHA >>> ALPHA "-", "any other string consisting of two letters >>> followed by two hyphens" is forbidden already. I think we >>> could conflate those two to: >>> >>> [[ >>> 4. It MUST NOT start with any string consisting of two >>> letters followed by one or two hyphens. Such strings are >>> reserved for potential representation of DNS A-labels and >>> similar strings in the future [RFC5890]. ]] >>> >>> Or are ALPHA ALPHA "-"-Strings reserved for something else? >>> If so, then we should explain why those are forbidden, too. >> >> I think this is clearer (combining the relevant rules and the >> text that is currently shown after the bulleted list: >> >> 3. It MUST be more than two characters long and it >> MUST NOT start with ALPHA ALPHA "-", i.e., any string >> consisting of two letters followed by one hyphen; such >> strings are reserved for potential use as NIDs based on >> ISO alpha-2 country codes [ISO.3166-1] for eventual >> national registrations of URN namespaces (however, the >> definition and scoping of rules for allocation of >> responsibility for such country-code-based URN >> namespaces are beyond the scope of this document). > > That seems to me much better, but doesn't eliminate Lars's > concern about redundancy. I've tentatively merged bullet 4 into > bullet 3, making it clear that the latter is a special case, > with an additional motivation, of the ' ALPHA ALPHA "-"' rule. Thanks. I don't mind a bit of redundancy here given that there are different reasons for the two rules, but if you've been able to artfully merge the two bullet points then so much the better. Peter From nobody Wed Dec 28 17:33:47 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 7D49D129434 for ; Wed, 28 Dec 2016 17:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-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 LoU4WIr88Jsm for ; Wed, 28 Dec 2016 17:33:45 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 570E8128B37 for ; Wed, 28 Dec 2016 17:33:45 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9C640400FA; Wed, 28 Dec 2016 18:36:32 -0700 (MST) To: John C Klensin , "Hakala, Juha E" , "Svensson, Lars" , urn@ietf.org References: <24637769D123E644A105A0AF0E1F92EF010D2AA580@dnbf-ex1.AD.DDB.DE> <7387d698-2bc4-6a1b-dd1d-cb12ad7d0c8f@stpeter.im> From: Peter Saint-Andre Message-ID: <96cdd296-c9ad-b4f3-58c9-515b9e6fb782@stpeter.im> Date: Wed, 28 Dec 2016 18:33:43 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] f-component 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, 29 Dec 2016 01:33:46 -0000 On 12/27/16 5:49 PM, John C Klensin wrote: > > > --On Friday, December 23, 2016 7:01 AM +0000 "Hakala, Juha E" > wrote: > >> Hello, >> >> Comments inline. >> >>> -----Original Message----- >>> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Peter >>> Saint-Andre Sent: 22. joulukuuta 2016 21:18 >>> To: Svensson, Lars ; urn@ietf.org >>> Subject: Re: [urn] f-component >>> >>> On 12/21/16 5:01 AM, Svensson, Lars wrote: >>>> All, >>>> >>>> in version-18, the penultimate paragraph of §2.3.3 says >>>> the following about the semantics of the f-component: >>>> >>>> [[ The f-component is primarily intended to distinguish the >>>> constituent parts of resources named by URNs. Thus, for >>>> URNs that resolve to URLs of the named resources, the >>>> semantics of an f-component are defined by the media type >>>> of those resources, not by the URN namespace. ]] >>>> >>>> This leaves out what the semantics of the f-component is if >>>> the URN resolver doesn't resolve to a URL but returns the >>>> resource (e. g. a document) directly, without redirecting >>>> the agent to another location. I propose the following >>>> minor edit: >>>> >>>> [[ The f-component is primarily intended to distinguish the >>>> constituent parts of resources named by URNs. Thus, for >>>> URNs that resolve to URLs of the named resources or where >>>> the URN resolver returns the resource directly, the >>>> semantics of an f-component are defined by the media type >>>> of those resources, not by the URN namespace. ]] >>> >>> I would like to think about this some more. In particular, I >>> am not sure it's right to say that a URN resolver might >>> "return a resource", because I believe that it would return >>> (via dereferencing) either a representation of the resource >>> or metadata about the resource, and I further believe the f- >>> component applies only to representations and not to metadata >>> (but I might be wrong about that). >> >> F-component can be applied to the identified resource only, >> not to metadata about the resource or any other surrogate the >> resolution process may come up with, such as a list of URLs >> from which the user may find alternative versions of the >> resource in different file formats, or one of these >> alternatives. >> >> Resolver is not aware of the f-component, so if the resolution >> process has been set up in such a way that the client may also >> get a surrogate instead of the real thing, the client may >> receive an information resource the f-component cannot be >> applied to. If so, the client application will behave as usual >> (leaves the user to the beginning of the resource instead of >> the desired location). I am not sure if we need to mention >> this. >> >> F-components can only be used in those namespaces in which the >> URNs persistently identify individual information resources >> such as electronic books, if and when at least some of these >> resources have applicable media types. So f-component can be >> used in urn:isbn when the resource is an electronic book in >> appropriate file format, but it is not applicable in urn:issn. >> But if the user gets an HTML version of a book instead of PDF, >> f-component does not work. >>> >>> Thus perhaps this is more correct: >>> >>> The f-component is primarily intended to distinguish the >>> constituent parts of a resource named by a URN. For a >>> URN that resolves to one or more locators which can be >>> dereferenced to a representation, or where the URN >>> resolver directly returns a representation of the >>> resource, the semantics of an f-component are defined by >>> the media type of the representation, not by the URN >>> namespace. >> >> This is fine with me otherwise, but we might want to drop "not >> by the URN namespace". > > Dropped. 3986 is very clear that it is bound to the media type > of the representation and nothing else. Anything more we say > here risks another argument about 3986 and scope. +1 > BTW, the first sentence of that paragraph is almost identical > (but not quite) and certainly redundant with the first paragraph > of 2.3.3 Suggestions welcome (the default is to just leave > the redundancy). I think you and I can work that out as an editorial matter before we publish version -19 (I think it would be best to move the above-quoted paragraph to the start of Section 2.3.3 and harmonize the first sentences). Peter From nobody Wed Dec 28 17:37: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 8FE9B129434 for ; Wed, 28 Dec 2016 17:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-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 KiThDkH60PAd for ; Wed, 28 Dec 2016 17:37:17 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9F932128B37 for ; Wed, 28 Dec 2016 17:37:17 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E4375400FA; Wed, 28 Dec 2016 18:40:04 -0700 (MST) To: John C Klensin , "Svensson, Lars" References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> <24637769D123E644A105A0AF0E1F92EF010D2AA515@dnbf-ex1.AD.DDB.DE> <840c4bb0-7cd5-5a30-0390-6a6c49d8c515@stpeter.im> From: Peter Saint-Andre Message-ID: <50953849-a528-a918-b2e5-6bff1a9963f5@stpeter.im> Date: Wed, 28 Dec 2016 18:37:16 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Terminology -- 'resource' and 'abstract designator' 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, 29 Dec 2016 01:37:18 -0000 On 12/27/16 4:14 PM, John C Klensin wrote: > > > --On Thursday, December 22, 2016 11:56 AM -0700 Peter > Saint-Andre wrote: > >> Hi Lars, thank you very much for your feedback. > >> On 12/21/16 4:26 AM, Svensson, Lars wrote: >> ... >>> Here I don't quite agree with "The URN q-component has the >>> same syntax as the query component in URI schemes for >>> locators". That text implies that URI schemes that are not >>> for locators have a different query component syntax. My >>> suggestion would be to accept Peter's new version but keep >>> the first sentence unchanged: >>> >>> [[ The URN q-component has the same syntax as the URI query >>> component, but is introduced by "?=", not "?" alone. For >>> URNs that may be resolved to a locator URI, the semantics of >>> the q-component are identical to those for the query >>> component of that URI. Thus URN resolvers returning a >>> locator URI for a URN with a q-component do this by copying >>> the q-component from the URN to the query component of the >>> locator URI. If the URN does not resolve to a locator URI, >>> the interpretation of the q-component is undefined by this >>> specification. An example of the copying operation appears >>> below. ]] [...] > >> You are right - thanks for pointing out this problem. > > As another small nit, I'm not sure where a "locator URI" is > defined. The term certainly is not defined in 2141bis, nor does > it appear in 3986. I'm ok with "locator" by itself (which does > have origins in 3986 and that is defined in Section 1.1 of > 2141bis), or "URI for a locator". I still don't fully > understand why we have dropped "URL" in favor of "locator URI"s > and similar unnatural constructions, but, if we are going to do > so, "locator URI" is in need of a clear definition in Section > 1.1. When I go back and reread Section 1.1.3 of RFC 3986, I > think that any plausible definition takes us back to "URL" > unless the intent is to get at the "both" case, but maybe I'm > missing something. If we follow Henry's suggestion to use the term "locator" instead of "URL" in most instances, then we need a term to refer to locators that are identified by URIs, since there could be non-URI locators. This is why I coined the neologism "locator URI", which is the same as a "URI for a locator" but less wordy. I'm open to better suggestions! Peter From nobody Wed Dec 28 17:41: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 DC293129432 for ; Wed, 28 Dec 2016 17:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-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 RYg_UbaQIojX for ; Wed, 28 Dec 2016 17:41:35 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0746A128B37 for ; Wed, 28 Dec 2016 17:41:35 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 52FB6400FA; Wed, 28 Dec 2016 18:44:22 -0700 (MST) To: John C Klensin , "Svensson, Lars" , urn@ietf.org References: <24637769D123E644A105A0AF0E1F92EF010D2AA542@dnbf-ex1.AD.DDB.DE> <49b9bc6e-d31a-b490-ee81-348cdb3a5947@stpeter.im> From: Peter Saint-Andre Message-ID: Date: Wed, 28 Dec 2016 18:41:33 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 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] Different conceptual model compared to earlier specifications 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, 29 Dec 2016 01:41:36 -0000 On 12/27/16 6:03 PM, John C Klensin wrote: > > > --On Thursday, December 22, 2016 1:29 PM -0700 Peter Saint-Andre > wrote: > >>> This last reference to a "conceptual model [that is] slightly >>> different" leaves the reader hanging in mid-air as to the >>> nature of those changes. I think it would be helpful to >>> supply at least one example of such a difference. >> >> I think I'll leave that for John. :-) > > Yeah, well... > > 3986 fans, please read all of the following before reacting. > > RFC 3986 is, IMO and given examples cited elsewhere (and a > careful reading of the first few paragraphs of its > introduction), mostly about locators, i.e., URLs, with a > periodic nod to non-locator names (specifically of the "urn:" > scheme persuasion). Its failure to treat URLs and URNs equally > and to call out differences (whether it should have done so or > not) and to be strictly conformant to 2141 has been a major > source of debate and aggravation in this WG. > >>From that perspective, most of the discussions we have had about > what identifiers are, whether or not things resolve, how to > handle f-components when there are no media types, whether the > term "resource" is clearly defined or just so much more hand > waving about how broad the term can be, etc., etc., are all > examples of those conceptual differences. > > The problem is that I don't think we want to say any of that in > the document. I'm reluctant to say it even in this note. I > continue to believe that we can finish 2141bis without > challenging 3986 directly and that is what the WG has more or > less told us to try to do. So, yes, I recognize that the > comment calls for either examples or more explanation. I'm > attempting a bit more explanation for -19 but imagine even it > may be controversial. I don't know how to provide examples > without directly challenging the legitimacy of 3986 and I > really, really, don't want to do that at this point. Yes, I agree that this is the best route forward. Peter From nobody Thu Dec 29 12:38:16 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 5A1D2129421 for ; Thu, 29 Dec 2016 12:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 YkXaHd1MofsR for ; Thu, 29 Dec 2016 12:38:12 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74E612941A for ; Thu, 29 Dec 2016 12:38:12 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cMhSl-000EV9-Ji; Thu, 29 Dec 2016 15:38:11 -0500 Date: Thu, 29 Dec 2016 15:38:04 -0500 From: John C Klensin To: Peter Saint-Andre Message-ID: <640C05FD2F7EA3333707CC5A@PSB> 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.70 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: [urn] 2141bis - terminology, particularly about locators, names, and URNs 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, 29 Dec 2016 20:38:14 -0000 Hi. Peter and I are iterating on -10 and still expect it to be posted before the end of the week. I want to alert the WG to some proposed terminology changes. Requirements for these became clear in carefully checking through usage of terms in the draft. In no particular order: (1) "name" is used all over the place, both within the document, within 3986, and elsewhere to mean several different things and/or as a general term, often associated with a certain amount of handwaving. The definition in -18, which appears to assume that the only usage is that in 3986 1.1.3, which uses it as the name (sic) of one of the two categories of URI, the other one being "locator". "name" has been removed from the definition and replaced by a caution against assuming the term has any precise meaning. (ii) Removal of "URL" in favor of "locator" or related terminology didn't go as smoothly as I (and, I think, Peter) assumed it would when Henry suggested it. "locator URI" now appears in the Terminology section and some other corrections have been made for consistency, but, unless we believe that there is a non-trivial possibility that URLs will go out of use within the lifetime of 2141bis, we may be making a fine distinction that is more confusing than helpful. An alternate strategy, which I think people who care about this should consider (although I hope we don't need to do the work because it would be hard to avoid errors), is to use "URL" when we mean that and "non-URL locators" and "possibly non-URL locators" when we don't. (iii) -18 defined "URN" in a way that was not consistent with usage in the rest of the document and some other places (but that was closely related to the definition of "name" discussed above. The definition has been changed and a caution inserted about other definitions and definition-less usage. If any of the above bother people at a conceptual level, please say so. Otherwise, consider this an early warning of an area of -19 that deserves attention as well as some explanation of why I believe we need to move past the sort of overly-close reading that causes this sort of work and the resulting questions. best, john From nobody Fri Dec 30 07:31: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 68F1E1294BA for ; Fri, 30 Dec 2016 07:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 Be3K-u92vULE for ; Fri, 30 Dec 2016 07:31:10 -0800 (PST) Received: from seine.is.ed.ac.uk (seine.is.ed.ac.uk [129.215.17.202]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9FF127076 for ; Fri, 30 Dec 2016 07:31:09 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by seine.is.ed.ac.uk (8.14.7/8.14.6) with ESMTP id uBUFV7TZ001052; Fri, 30 Dec 2016 15:31:07 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id uBUFV62t026510; Fri, 30 Dec 2016 15:31:06 GMT 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 uBUFV54t010523; Fri, 30 Dec 2016 15:31:05 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id uBUFV4Ri010522; Fri, 30 Dec 2016 15:31:04 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: John C Klensin References: <640C05FD2F7EA3333707CC5A@PSB> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 30 Dec 2016 15:31:03 +0000 In-Reply-To: <640C05FD2F7EA3333707CC5A@PSB> (John C. Klensin's message of "Thu\, 29 Dec 2016 15\:38\:04 -0500") 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 seine.is.ed.ac.uk with MIMEDefang 2.78, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.78 on 129.215.17.202 Archived-At: Cc: urn@ietf.org Subject: Re: [urn] 2141bis - terminology, particularly about locators, names, and URNs 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, 30 Dec 2016 15:31:13 -0000 John C Klensin writes: > (1) "name" is used all over the place, both within the document, > within 3986, and elsewhere to mean several different things > and/or as a general term, often associated with a certain amount > of handwaving. The definition in -18, which appears to assume > that the only usage is that in 3986 1.1.3, which uses it as the > name (sic) of one of the two categories of URI, the other one > being "locator". "name" has been removed from the definition > and replaced by a caution against assuming the term has any > precise meaning. Good. > (ii) Removal of "URL" in favor of "locator" or related > terminology didn't go as smoothly as I (and, I think, Peter) > assumed it would when Henry suggested it. "locator URI" now > appears in the Terminology section and some other corrections > have been made for consistency, but, unless we believe that > there is a non-trivial possibility that URLs will go out of use > within the lifetime of 2141bis, we may be making a fine > distinction that is more confusing than helpful. An alternate > strategy, which I think people who care about this should > consider (although I hope we don't need to do the work because > it would be hard to avoid errors), is to use "URL" when we mean > that and "non-URL locators" and "possibly non-URL locators" when > we don't. I find the proposed use of "locator URI" quite natural: 3986 says that some URIs are locators and some are not (independently of their URI scheme), so it makes sense to talk about the ones that are as locator URIs. Juha, Lars and I all responsed positively to this aspect of Peter's message of 14 December. I'm not sure I see any specific reason in the para. above for changing my mind... ht [Perhaps the origin of your unease is reflected in what I think is a misunderstanding in yours of 27 December: > As another small nit, I'm not sure where a "locator URI" is defined. > The term certainly is not defined in 2141bis, nor does it appear in > 3986. I'm ok with "locator" by itself (which does have origins in > 3986 and that is defined in Section 1.1 of 2141bis), or "URI for a > locator". "URI for a locator" is a pretty rare and unlikely beast, at least as I unpack it, that is, as an identifier for an identifier. Would adding a very short definition in the terminology section, along the lines of Locator URI -- "[a URI] that, in addition to identifying a resource, provide[s] a means of locating the resource by describing its primary access mechanism (e.g., its network 'location')" [ref. 3986 1.1.3] > I still don't fully understand why we have dropped "URL" Primarily (IMO) because it confuses people -- common usage (3986 notwithstanding) thinks anything that looks like 'http://...' is always a 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 Fri Dec 30 09:09: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 3456F12946D for ; Fri, 30 Dec 2016 09:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 2zCNA8CWS7k8 for ; Fri, 30 Dec 2016 09:09:12 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5BA129406 for ; Fri, 30 Dec 2016 09:09:12 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cN0fz-000Gl3-N3; Fri, 30 Dec 2016 12:09:07 -0500 Date: Fri, 30 Dec 2016 12:09:01 -0500 From: John C Klensin To: "Henry S. Thompson" Message-ID: <0CC054BB3789AF6414FFEE8C@PSB> In-Reply-To: References: <640C05FD2F7EA3333707CC5A@PSB> 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.70 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] 2141bis - terminology, particularly about locators, names, and URNs 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, 30 Dec 2016 17:09:14 -0000 --On Friday, December 30, 2016 15:31 +0000 "Henry S. Thompson" wrote: >... >> (ii) Removal of "URL" in favor of "locator" or related >> terminology didn't go as smoothly as I (and, I think, Peter) >> assumed it would when Henry suggested it. "locator URI" now >> appears in the Terminology section and some other corrections >> have been made for consistency, but, unless we believe that >> there is a non-trivial possibility that URLs will go out of >> use within the lifetime of 2141bis, we may be making a fine >> distinction that is more confusing than helpful. An alternate >> strategy, which I think people who care about this should >> consider (although I hope we don't need to do the work because >> it would be hard to avoid errors), is to use "URL" when we >> mean that and "non-URL locators" and "possibly non-URL >> locators" when we don't. > I find the proposed use of "locator URI" quite natural: 3986 > says that some URIs are locators and some are not > (independently of their URI scheme), so it makes sense to talk > about the ones that are as locator URIs. Juha, Lars and I all > responsed positively to this aspect of Peter's message of 14 > December. I'm not sure I see any specific reason in the para. > above for changing my mind... >... > [Perhaps the origin of your unease is reflected in what I > think is a misunderstanding in yours of 27 December: > >> As another small nit, I'm not sure where a "locator URI" is >> defined. The term certainly is not defined in 2141bis, nor >> does it appear in 3986. I'm ok with "locator" by itself >> (which does have origins in 3986 and that is defined in >> Section 1.1 of 2141bis), or "URI for a locator". > > "URI for a locator" is a pretty rare and unlikely beast, at > least as I unpack it, that is, as an identifier for an > identifier. I wasn't confused (if that be the right term), until I went back and reread 3096 again, but that is exactly where the terminology gets tangled up. If you said "a locator-type URI", I wouldn't have have a problem. But "locator URI" sounds like a very specific term of art that is not, IMO, justified by any obvious reading of 3986. I note that we could be using "name URI" in lieu of URN, or at least the more general interpretation of "URN" as more than the "urn:' scheme, but we don't do that and, by removing "name" as a 2141bis definition, we remove what is, IMO, the last vestige of that concept from 2141bis. Again, I'm ok if "lcoator URI" is specifically defined somewhere; the objection is to expecting readers to figure out what it means and what its implications are. > Would adding a very short definition in the > terminology section, along the lines of > > Locator URI -- "[a URI] that, in addition to identifying a > resource, provide[s] a means of locating the resource by > describing its primary access mechanism (e.g., its network > 'location')" [ref. 3986 1.1.3] The following appears in the preliminary versions of -19 that have been going back and forth between Peter and myself: "Locator URI: A locator that is conformant to URI syntax and other rules of RFC 3986. That document, at Section 1.1.3, appears to identify all such locators as "URLs", but this document attempts to be agnostic on that issue." I don't see much reason to prefer one over the other but, in the interest of progress, am substituting yours. Anyone who has a strong preference for the earlier version (the one quoted directly above) should speak up, ideally in the next few hours before I post -19. >> I still don't fully understand why we have dropped "URL" > > Primarily (IMO) because it confuses people -- common usage > (3986 notwithstanding) thinks anything that looks like > 'http://...' is always a URL. Then, in retrospect, I would have preferred to define "URL" in 2141bis in a way that is completely consistent with 3986 and warn against alternate definitions and interpretations, at least within the scope of 2141bis and URNs. Again, just in retrospect -- I see the tradeoffs and don't propose to go back. best, john From nobody Fri Dec 30 09:57: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 47DFD129451 for ; Fri, 30 Dec 2016 09:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-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 B4UHebkVNnzV for ; Fri, 30 Dec 2016 09:57:30 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D2E77129407 for ; Fri, 30 Dec 2016 09:57:30 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6E5CC400E0; Fri, 30 Dec 2016 11:00:24 -0700 (MST) To: John C Klensin , "Henry S. Thompson" References: <640C05FD2F7EA3333707CC5A@PSB> <0CC054BB3789AF6414FFEE8C@PSB> From: Peter Saint-Andre Message-ID: <9a0b36ad-912e-75bb-3845-1c35d50682b2@stpeter.im> Date: Fri, 30 Dec 2016 10:57:27 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <0CC054BB3789AF6414FFEE8C@PSB> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] 2141bis - terminology, particularly about locators, names, and URNs 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, 30 Dec 2016 17:57:32 -0000 On 12/30/16 10:09 AM, John C Klensin wrote: > > > --On Friday, December 30, 2016 15:31 +0000 "Henry S. Thompson" > wrote: > >> ... >>> (ii) Removal of "URL" in favor of "locator" or related >>> terminology didn't go as smoothly as I (and, I think, Peter) >>> assumed it would when Henry suggested it. "locator URI" now >>> appears in the Terminology section and some other corrections >>> have been made for consistency, but, unless we believe that >>> there is a non-trivial possibility that URLs will go out of >>> use within the lifetime of 2141bis, we may be making a fine >>> distinction that is more confusing than helpful. An alternate >>> strategy, which I think people who care about this should >>> consider (although I hope we don't need to do the work because >>> it would be hard to avoid errors), is to use "URL" when we >>> mean that and "non-URL locators" and "possibly non-URL >>> locators" when we don't. > >> I find the proposed use of "locator URI" quite natural: 3986 >> says that some URIs are locators and some are not >> (independently of their URI scheme), so it makes sense to talk >> about the ones that are as locator URIs. Juha, Lars and I all >> responsed positively to this aspect of Peter's message of 14 >> December. I'm not sure I see any specific reason in the para. >> above for changing my mind... >> ... > >> [Perhaps the origin of your unease is reflected in what I >> think is a misunderstanding in yours of 27 December: >> >>> As another small nit, I'm not sure where a "locator URI" is >>> defined. The term certainly is not defined in 2141bis, nor >>> does it appear in 3986. I'm ok with "locator" by itself >>> (which does have origins in 3986 and that is defined in >>> Section 1.1 of 2141bis), or "URI for a locator". >> >> "URI for a locator" is a pretty rare and unlikely beast, at >> least as I unpack it, that is, as an identifier for an >> identifier. > > I wasn't confused (if that be the right term), until I went back > and reread 3096 again, but that is exactly where the terminology > gets tangled up. If you said "a locator-type URI", I wouldn't > have have a problem. But "locator URI" sounds like a very > specific term of art that is not, IMO, justified by any obvious > reading of 3986. I note that we could be using "name URI" in > lieu of URN, or at least the more general interpretation of > "URN" as more than the "urn:' scheme, but we don't do that and, > by removing "name" as a 2141bis definition, we remove what is, > IMO, the last vestige of that concept from 2141bis. Again, I'm > ok if "lcoator URI" is specifically defined somewhere; the > objection is to expecting readers to figure out what it means > and what its implications are. > >> Would adding a very short definition in the >> terminology section, along the lines of >> >> Locator URI -- "[a URI] that, in addition to identifying a >> resource, provide[s] a means of locating the resource by >> describing its primary access mechanism (e.g., its network >> 'location')" [ref. 3986 1.1.3] > > The following appears in the preliminary versions of -19 that > have been going back and forth between Peter and myself: > > "Locator URI: A locator that is conformant to URI syntax and > other rules of RFC 3986. That document, at Section 1.1.3, > appears to identify all such locators as "URLs", but this > document attempts to be agnostic on that issue." > > I don't see much reason to prefer one over the other but, in the > interest of progress, am substituting yours. Anyone who has a > strong preference for the earlier version (the one quoted > directly above) should speak up, ideally in the next few hours > before I post -19. I have a better idea: let's not define "locator URI" as a term of art. When we substituted "locator" for "URL" in most cases, there were a few places in the text where we talked about URI query components in relation to such locators. However, it doesn't make sense to talk about URI query components if the locator is not a URI, so when I provisionally modified the text I sought a less cumbersome phrase than "a URI for a locator", landing on "locator URI" as a proposed phrase (*not* a defined term of art). I now think that interim proposal was a mistake, and I would prefer that we use the phrase I started with ("a URI for a locator") to avoid confusion, even if it is somewhat ugly. Peter From nobody Fri Dec 30 10:15:18 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 80ED71294C5 for ; Fri, 30 Dec 2016 10:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 rkOzlswILN-L for ; Fri, 30 Dec 2016 10:15:15 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0E21294B0 for ; Fri, 30 Dec 2016 10:15:15 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cN1hu-000Gs2-UT; Fri, 30 Dec 2016 13:15:10 -0500 Date: Fri, 30 Dec 2016 13:15:04 -0500 From: John C Klensin To: Peter Saint-Andre , "Henry S. Thompson" Message-ID: <0C7D8DAC16B91A8BD088436C@PSB> In-Reply-To: <9a0b36ad-912e-75bb-3845-1c35d50682b2@stpeter.im> References: <640C05FD2F7EA3333707CC5A@PSB> <0CC054BB3789AF6414FFEE8C@PSB> <9a0b36ad-912e-75bb-3845-1c35d50682b2@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.70 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] 2141bis - terminology, particularly about locators, names, and URNs 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, 30 Dec 2016 18:15:16 -0000 --On Friday, December 30, 2016 10:57 -0700 Peter Saint-Andre wrote: > On 12/30/16 10:09 AM, John C Klensin wrote: >> >> >> --On Friday, December 30, 2016 15:31 +0000 "Henry S. Thompson" >> wrote: >> >>> ... >>>> (ii) Removal of "URL" in favor of "locator" or related >>>> terminology didn't go as smoothly as I (and, I think, Peter) >>>> assumed it would when Henry suggested it. "locator URI" now >>>> appears in the Terminology section and some other >>>> corrections have been made for consistency, but, unless we >>>> believe that there is a non-trivial possibility that URLs >>>> will go out of use within the lifetime of 2141bis, we may >>>> be making a fine distinction that is more confusing than >>>> helpful. An alternate strategy, which I think people who >>>> care about this should consider (although I hope we don't >>>> need to do the work because it would be hard to avoid >>>> errors), is to use "URL" when we mean that and "non-URL >>>> locators" and "possibly non-URL locators" when we don't. >> >>> I find the proposed use of "locator URI" quite natural: 3986 >>> says that some URIs are locators and some are not >>> (independently of their URI scheme), so it makes sense to >>> talk about the ones that are as locator URIs. Juha, Lars >>> and I all responsed positively to this aspect of Peter's >>> message of 14 December. I'm not sure I see any specific >>> reason in the para. above for changing my mind... >>> ... >> >>> [Perhaps the origin of your unease is reflected in what I >>> think is a misunderstanding in yours of 27 December: >>> >>>> As another small nit, I'm not sure where a "locator URI" is >>>> defined. The term certainly is not defined in 2141bis, nor >>>> does it appear in 3986. I'm ok with "locator" by itself >>>> (which does have origins in 3986 and that is defined in >>>> Section 1.1 of 2141bis), or "URI for a locator". >>> >>> "URI for a locator" is a pretty rare and unlikely beast, at >>> least as I unpack it, that is, as an identifier for an >>> identifier. >> >> I wasn't confused (if that be the right term), until I went >> back and reread 3096 again, but that is exactly where the >> terminology gets tangled up. If you said "a locator-type >> URI", I wouldn't have have a problem. But "locator URI" >> sounds like a very specific term of art that is not, IMO, >> justified by any obvious reading of 3986. I note that we >> could be using "name URI" in lieu of URN, or at least the >> more general interpretation of "URN" as more than the "urn:' >> scheme, but we don't do that and, by removing "name" as a >> 2141bis definition, we remove what is, IMO, the last vestige >> of that concept from 2141bis. Again, I'm ok if "lcoator >> URI" is specifically defined somewhere; the objection is to >> expecting readers to figure out what it means and what its >> implications are. >> >>> Would adding a very short definition in the >>> terminology section, along the lines of >>> >>> Locator URI -- "[a URI] that, in addition to identifying a >>> resource, provide[s] a means of locating the resource by >>> describing its primary access mechanism (e.g., its network >>> 'location')" [ref. 3986 1.1.3] >> >> The following appears in the preliminary versions of -19 that >> have been going back and forth between Peter and myself: >> >> "Locator URI: A locator that is conformant to URI syntax >> and other rules of RFC 3986. That document, at Section >> 1.1.3, appears to identify all such locators as "URLs", >> but this document attempts to be agnostic on that issue." >> >> I don't see much reason to prefer one over the other but, in >> the interest of progress, am substituting yours. Anyone who >> has a strong preference for the earlier version (the one >> quoted directly above) should speak up, ideally in the next >> few hours before I post -19. > > I have a better idea: let's not define "locator URI" as a term > of art. When we substituted "locator" for "URL" in most cases, > there were a few places in the text where we talked about URI > query components in relation to such locators. However, it > doesn't make sense to talk about URI query components if the > locator is not a URI, so when I provisionally modified the > text I sought a less cumbersome phrase than "a URI for a > locator", landing on "locator URI" as a proposed phrase (*not* > a defined term of art). I now think that interim proposal was > a mistake, and I would prefer that we use the phrase I started > with ("a URI for a locator") to avoid confusion, even if it is > somewhat ugly. Wfm, but I note Henry appears to not like "URI for a locator", or at least some variations on it. He apparently believes "locator URI" is obvious and a reference to the "locator" part of 3986 1.1.3; I don't and see it as acceptable only as a term of art. Again, part of my problem is that there are URIs that are not locators and not names (although not in 3986), URIs that are both locators and names, and, of course, locators (and names) that are not URIs. There are also things whose classifications require effort outside the scope of URNBIS: Juha, Lars, and their colleagues would tell us that Dewey Decimal Numbers are a classification system, perhaps not even a set of identifiers and definitely not a system with single centralized (or topically delegated) management. But there are probably more people in the world who think of them as locators than there are people who think that "URI" and "URL" are equivalent terms and/or that anything that "looks like" 'http:...' is inherently a URL. So how would you like to proceed? I'm partway through the draft of -19 I was going to touch up as needed and post today, but the only changes I've made so far are to substitute Henry's text for mine as discussed above and to start removing the CREFs we've used to discuss issues with each other. Do you want the pen back to fix the "locator URI" instances? If you do that, I'm probably going to run out of time to do/finish a final review and post today, but we could delay the posting schedule until tomorrow or Sunday. Or I could just post what we have with a note about fixing that later. While I think we can still get a draft posted this weekend, I'd really like the WG to consider how much effort this, and similar, efforts are worth relative to the value of getting finished. best, john From nobody Fri Dec 30 10:29: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 3D76F1293E9 for ; Fri, 30 Dec 2016 10:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-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 764x6pdaHBtc for ; Fri, 30 Dec 2016 10:29:01 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 16AB71294A9 for ; Fri, 30 Dec 2016 10:29:01 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 05647400E0; Fri, 30 Dec 2016 11:31:54 -0700 (MST) To: John C Klensin , "Henry S. Thompson" References: <640C05FD2F7EA3333707CC5A@PSB> <0CC054BB3789AF6414FFEE8C@PSB> <9a0b36ad-912e-75bb-3845-1c35d50682b2@stpeter.im> <0C7D8DAC16B91A8BD088436C@PSB> From: Peter Saint-Andre Message-ID: Date: Fri, 30 Dec 2016 11:28:56 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <0C7D8DAC16B91A8BD088436C@PSB> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] 2141bis - terminology, particularly about locators, names, and URNs 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, 30 Dec 2016 18:29:02 -0000 On 12/30/16 11:15 AM, John C Klensin wrote: > > > --On Friday, December 30, 2016 10:57 -0700 Peter Saint-Andre > wrote: > >> On 12/30/16 10:09 AM, John C Klensin wrote: >>> >>> >>> --On Friday, December 30, 2016 15:31 +0000 "Henry S. Thompson" >>> wrote: >>> >>>> ... >>>>> (ii) Removal of "URL" in favor of "locator" or related >>>>> terminology didn't go as smoothly as I (and, I think, Peter) >>>>> assumed it would when Henry suggested it. "locator URI" now >>>>> appears in the Terminology section and some other >>>>> corrections have been made for consistency, but, unless we >>>>> believe that there is a non-trivial possibility that URLs >>>>> will go out of use within the lifetime of 2141bis, we may >>>>> be making a fine distinction that is more confusing than >>>>> helpful. An alternate strategy, which I think people who >>>>> care about this should consider (although I hope we don't >>>>> need to do the work because it would be hard to avoid >>>>> errors), is to use "URL" when we mean that and "non-URL >>>>> locators" and "possibly non-URL locators" when we don't. >>> >>>> I find the proposed use of "locator URI" quite natural: 3986 >>>> says that some URIs are locators and some are not >>>> (independently of their URI scheme), so it makes sense to >>>> talk about the ones that are as locator URIs. Juha, Lars >>>> and I all responsed positively to this aspect of Peter's >>>> message of 14 December. I'm not sure I see any specific >>>> reason in the para. above for changing my mind... >>>> ... >>> >>>> [Perhaps the origin of your unease is reflected in what I >>>> think is a misunderstanding in yours of 27 December: >>>> >>>>> As another small nit, I'm not sure where a "locator URI" is >>>>> defined. The term certainly is not defined in 2141bis, nor >>>>> does it appear in 3986. I'm ok with "locator" by itself >>>>> (which does have origins in 3986 and that is defined in >>>>> Section 1.1 of 2141bis), or "URI for a locator". >>>> >>>> "URI for a locator" is a pretty rare and unlikely beast, at >>>> least as I unpack it, that is, as an identifier for an >>>> identifier. >>> >>> I wasn't confused (if that be the right term), until I went >>> back and reread 3096 again, but that is exactly where the >>> terminology gets tangled up. If you said "a locator-type >>> URI", I wouldn't have have a problem. But "locator URI" >>> sounds like a very specific term of art that is not, IMO, >>> justified by any obvious reading of 3986. I note that we >>> could be using "name URI" in lieu of URN, or at least the >>> more general interpretation of "URN" as more than the "urn:' >>> scheme, but we don't do that and, by removing "name" as a >>> 2141bis definition, we remove what is, IMO, the last vestige >>> of that concept from 2141bis. Again, I'm ok if "lcoator >>> URI" is specifically defined somewhere; the objection is to >>> expecting readers to figure out what it means and what its >>> implications are. >>> >>>> Would adding a very short definition in the >>>> terminology section, along the lines of >>>> >>>> Locator URI -- "[a URI] that, in addition to identifying a >>>> resource, provide[s] a means of locating the resource by >>>> describing its primary access mechanism (e.g., its network >>>> 'location')" [ref. 3986 1.1.3] >>> >>> The following appears in the preliminary versions of -19 that >>> have been going back and forth between Peter and myself: >>> >>> "Locator URI: A locator that is conformant to URI syntax >>> and other rules of RFC 3986. That document, at Section >>> 1.1.3, appears to identify all such locators as "URLs", >>> but this document attempts to be agnostic on that issue." >>> >>> I don't see much reason to prefer one over the other but, in >>> the interest of progress, am substituting yours. Anyone who >>> has a strong preference for the earlier version (the one >>> quoted directly above) should speak up, ideally in the next >>> few hours before I post -19. >> >> I have a better idea: let's not define "locator URI" as a term >> of art. When we substituted "locator" for "URL" in most cases, >> there were a few places in the text where we talked about URI >> query components in relation to such locators. However, it >> doesn't make sense to talk about URI query components if the >> locator is not a URI, so when I provisionally modified the >> text I sought a less cumbersome phrase than "a URI for a >> locator", landing on "locator URI" as a proposed phrase (*not* >> a defined term of art). I now think that interim proposal was >> a mistake, and I would prefer that we use the phrase I started >> with ("a URI for a locator") to avoid confusion, even if it is >> somewhat ugly. > > Wfm, but I note Henry appears to not like "URI for a locator", > or at least some variations on it. He apparently believes > "locator URI" is obvious and a reference to the "locator" part > of 3986 1.1.3; When it comes to URIs, nothing is obvious. ;-) > I don't and see it as acceptable only as a term > of art. I would prefer to avoid coining unneeded terminology and potentially causing more confusion that we already have in this space. That's why I'd prefer "URI for a locator" or "URI that is a locator". Henry, can you not live with one of those phrases? (cf RFC 7282, §2) > So how would you like to proceed? I'm partway through the draft > of -19 I was going to touch up as needed and post today, but the > only changes I've made so far are to substitute Henry's text for > mine as discussed above and to start removing the CREFs we've > used to discuss issues with each other. Do you want the pen > back to fix the "locator URI" instances? If you do that, I'm > probably going to run out of time to do/finish a final review > and post today, but we could delay the posting schedule until > tomorrow or Sunday. Or I could just post what we have with a > note about fixing that later. If you finish your work and send me the source file, I will make these few little fixes and post -19 later today or early tomorrow. > While I think we can still get a draft posted this weekend, I'd > really like the WG to consider how much effort this, and > similar, efforts are worth relative to the value of getting > finished. I would like us all to consider -19 as the version that undergoes working group last call so that ideally we can finish this work before the next IETF meeting in late March. Peter From nobody Fri Dec 30 11:36: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 3BBF21293D6 for ; Fri, 30 Dec 2016 11:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 QYvdbyQl0qQq for ; Fri, 30 Dec 2016 11:36:36 -0800 (PST) Received: from seine.is.ed.ac.uk (seine.is.ed.ac.uk [129.215.17.202]) by ietfa.amsl.com (Postfix) with ESMTP id DE315129483 for ; Fri, 30 Dec 2016 11:36:35 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by seine.is.ed.ac.uk (8.14.7/8.14.6) with ESMTP id uBUJaYLF015762; Fri, 30 Dec 2016 19:36:34 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id uBUJaYtc001189; Fri, 30 Dec 2016 19:36:34 GMT 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 uBUJaXWg020223; Fri, 30 Dec 2016 19:36:33 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id uBUJaWXL020222; Fri, 30 Dec 2016 19:36:32 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Peter Saint-Andre References: <640C05FD2F7EA3333707CC5A@PSB> <0CC054BB3789AF6414FFEE8C@PSB> <9a0b36ad-912e-75bb-3845-1c35d50682b2@stpeter.im> <0C7D8DAC16B91A8BD088436C@PSB> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 30 Dec 2016 19:36:32 +0000 In-Reply-To: (Peter Saint-Andre's message of "Fri\, 30 Dec 2016 11\:28\:56 -0700") 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=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Edinburgh-Scanned: at seine.is.ed.ac.uk with MIMEDefang 2.78, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.78 on 129.215.17.202 Archived-At: Cc: urn@ietf.org Subject: Re: [urn] 2141bis - terminology, particularly about locators, names, and URNs 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, 30 Dec 2016 19:36:38 -0000 Peter Saint-Andre writes: > I would prefer to avoid coining unneeded terminology and potentially > causing more confusion that we already have in this space. That's why > I'd prefer "URI for a locator" or "URI that is a locator". > > Henry, can you not live with one of those phrases? (cf RFC 7282, =A72) I can certainly live with "URI that is a locator". (I have to say that I'm still worried that you seem to think that those two quoted phrases mean the same thing -- "a URI for a locator" means, to me, a URI for (some identifier which is itself) a locator, but I _hope_ that worry doesn't matter if we agree on "URI that is a locator".) ht --=20 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 s= pam] From nobody Fri Dec 30 11:57: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 AF8BC1295DF for ; Fri, 30 Dec 2016 11:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-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 xEvk-ZgXmFwM for ; Fri, 30 Dec 2016 11:57:35 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A6B5C129483 for ; Fri, 30 Dec 2016 11:57:35 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 33C6C400E0; Fri, 30 Dec 2016 13:00:30 -0700 (MST) To: "Henry S. Thompson" References: <640C05FD2F7EA3333707CC5A@PSB> <0CC054BB3789AF6414FFEE8C@PSB> <9a0b36ad-912e-75bb-3845-1c35d50682b2@stpeter.im> <0C7D8DAC16B91A8BD088436C@PSB> From: Peter Saint-Andre Message-ID: Date: Fri, 30 Dec 2016 12:57:33 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] 2141bis - terminology, particularly about locators, names, and URNs 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, 30 Dec 2016 19:57:36 -0000 On 12/30/16 12:36 PM, Henry S. Thompson wrote: > Peter Saint-Andre writes: > >> I would prefer to avoid coining unneeded terminology and potentially >> causing more confusion that we already have in this space. That's why >> I'd prefer "URI for a locator" or "URI that is a locator". >> >> Henry, can you not live with one of those phrases? (cf RFC 7282, §2) > > I can certainly live with "URI that is a locator". That's my preferred phrase as well. > (I have to say that I'm still worried that you seem to think that those > two quoted phrases mean the same thing -- "a URI for a locator" means, > to me, a URI for (some identifier which is itself) a locator, but I > _hope_ that worry doesn't matter if we agree on "URI that is a > locator".) I had not picked up on the subtlety you've pointed out, but now that you've done so I agree even more strongly that it's best to use the phrase "URI that is a locator" (which is the phrasing in the working version I've sent to John; he now holds the pen and will be posting it in the next 24 hours or so). Peter From nobody Sat Dec 31 08:31: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 F07331294A0 for ; Sat, 31 Dec 2016 08:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 pWqLaLVgOL3Y for ; Sat, 31 Dec 2016 08:31:27 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F38129490 for ; Sat, 31 Dec 2016 08:31:27 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cNMZ4-000K5M-Lt for urn@ietf.org; Sat, 31 Dec 2016 11:31:26 -0500 Date: Sat, 31 Dec 2016 11:31:19 -0500 From: John C Klensin To: urn@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.70 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] draft-ietf-urnbis-rfc2141bis-urn-19 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, 31 Dec 2016 16:31:29 -0000 Hi. Ok, draft-ietf-urnbis-rfc2141bis-urn-19 has been posted. It incorporates the changes to the definition and use of "lcoator" discussed on this list over the last 48 hours as well as a number of editorial changes to improve clarity and readability. For example, there are now several more explicit inter-sectional cross-reference and some redundant text has been eliminate. In some case, the revisions make the text a bit more tedious, but we have concluded that a bit of tediousness is preferable to user confusion. There has also been a small change in tone wrt 3986. The existence of conceptual, and sometimes confusing, differences between 3986 -- a URL document with some URN aspects and inclusions [1] -- and 2141bis have been called out explicit. There are two reasons for this, neither of which is an attack on 3986: (i) to reduce opportunities for endless discussions about apparent, but small, differences in terminology between this specification and 3986, as discussed on this list over the last couple of weekss; (ii) to try to protect the URN definition against the apparent likelihood that, whether the decision is made in the marketplace or other SDOs, we seem to be in danger of ending up with at least three different, even if mostly consistent, specifications of URIs or subsets of them: 3986, the WHATWG URL definition effort, and statements in various W3C specs (notably related to HTML). It is possible that a similar comment should be made about the relationship between this document, its terminology, and other specifications (whether internal or external to the IETF). If that is true, please send references and recommended text to the list. For Section 4.3(2), Henry suggested slightly different text; I (and Peter) believe what is now present does the job and fits better with the surrounding sections. Anyone who believes otherwise and thinks the debate is wroth reopening should say so. Peter and I believe this draft is suitable for WGLC and that it would be appropriate for the co-Chairs and WG to take a "showstoppers and major issues only" position relative to further comments. We (and, as I understand it, Barry and alexey) would really like to get this tied up before the Chicago IETF. The only way I can see to accomplish that is to stop nit-picking about, e.g., minor issues of terminology. best, john [1] See the 2141bis text for details and references.. From nobody Sat Dec 31 08:36:49 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F391293EB; Sat, 31 Dec 2016 08:36:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148320220790.25827.4863187996297001200.idtracker@ietfa.amsl.com> Date: Sat, 31 Dec 2016 08:36:47 -0800 Archived-At: Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-19.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2016 16:36:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised of the IETF. Title : Uniform Resource Names (URNs) Authors : Peter Saint-Andre John C Klensin Filename : draft-ietf-urnbis-rfc2141bis-urn-19.txt Pages : 43 Date : 2016-12-31 Abstract: A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN- equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFC 2141 and RFC 3406. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/