From nobody Wed Apr 1 06:19:16 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5661B1A9087; Wed, 1 Apr 2015 06:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrOTygzX_h1i; Wed, 1 Apr 2015 06:19:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A899E1A8AC0; Wed, 1 Apr 2015 06:19:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150401131911.13352.44593.idtracker@ietfa.amsl.com> Date: Wed, 01 Apr 2015 06:19:11 -0700 Archived-At: Cc: urn@ietf.org Subject: [urn] URNBIS Working Group Virtual Interim Meeting, April 17, 2015 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Reply-To: urn@ietf.org List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 13:19:13 -0000 The Uniform Resource Names, Revised (urnbis) working group will be having a virtual interim meeting on Friday, April 17, at 16:00 UTC (9 a.m. PDT, noon EDT, 18:00 CET) for two hours. We will discuss the open issues in the 2141-bis draft, with the goal of closing those issues and moving the document towards working group last call. Participation is open to everyone, and call-in details with be posted to the working group mailing list shortly before the meeting. From nobody Wed Apr 1 12:33:00 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBCD1A886B for ; Wed, 1 Apr 2015 12:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTzKYB9fIEFx for ; Wed, 1 Apr 2015 12:32:55 -0700 (PDT) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A681A1A7C for ; Wed, 1 Apr 2015 12:32:55 -0700 (PDT) Received: by iebmp1 with SMTP id mp1so45015902ieb.0 for ; Wed, 01 Apr 2015 12:32:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iK2LVGsoF7ZKf/R7lchpfZWnAtVa36dSUMgVSm5p39Q=; b=VGa+8lqRvQN+d13aAhpVe3bz9q12dln08R4WAMkKBaVdqgcAXX2SVwzrccPHvbiJXd +ukuvMgZVs+KYHAfSP+giKwS/wJqz6pznYyskTNvPcvTkHWFPPuUJDEeUQ5K/7uOtGFH 2Idssx2bD5kz6Gaq8KQSjSAhcSAtmj3C82yReKxMLmBPFFhlR1jBlsXQScKuE836lu7N e5CjJaaa3sROZI8cNutRKgtlGo6hi4O0FyTkL4K2pa5gm5p48q/wuGB3Hfe7aWqHDS/M GZyAN9tmCI5tG0LXLkPTTWOP/tAwDHHuvFWu0u5SStc8FDI03fKZZLP0yhtaW2Nio1vH AHvA== X-Gm-Message-State: ALoCoQkM8x3E0FZNb75P1n/nzRKvv/siytL742Hsy6UsQzrX26dIEMwbiAf/MWmnwtD/ZgMUxvoS MIME-Version: 1.0 X-Received: by 10.107.46.155 with SMTP id u27mr65224448iou.87.1427916774682; Wed, 01 Apr 2015 12:32:54 -0700 (PDT) Received: by 10.36.38.205 with HTTP; Wed, 1 Apr 2015 12:32:53 -0700 (PDT) X-Originating-IP: [2001:500:4:15:6098:55d1:da0e:6c0d] In-Reply-To: <551B1D53.6020206@network-heretics.com> References: <55142CA1.2000509@network-heretics.com> <20AE30F476B62E93E436DF1B@JcK-HP8200.jck.com> <551B1D53.6020206@network-heretics.com> Date: Wed, 1 Apr 2015 15:32:53 -0400 Message-ID: From: Andrew Newton To: Keith Moore Content-Type: multipart/alternative; boundary=001a113ac5b61fd4fc0512aec83d Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] 3986 relationships X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 19:32:59 -0000 --001a113ac5b61fd4fc0512aec83d Content-Type: text/plain; charset=UTF-8 On Tue, Mar 31, 2015 at 6:18 PM, Keith Moore wrote: > Regarding 3986 in general, I recognize that there's a conundrum here. > As I understand things, the AD explicitly imposed 3986 syntax on this > group. So I undertand that the group has a hard time recommending a > different approach. Also, much of the group has long believed that 3986 > is adequate, and maybe there's already some use of that syntax in deployed > URNs, so there's a lot of inertia behind that syntax. > > There was a proposal before the working group to complete separate URNs from 3986, and it was the working group decision to adhere to 3986 syntax but to let go of 3986 semantics. Many pointed out that in today's world, URNs do appear in places where URIs are expected (XML namespace specifications are a great example). > So, regardless of what I personally believe, I'm not really trying to > persuade you or the group that 3986 should be abandoned. I do, however, > think that, having decided to use that syntax (or having had that syntax > imposed on it), the group has to solve the problems that result from that > decision before it can expect its document to be approved as a proposed > standard. > > I continue to believe that the decision to use that syntax will result in > a tremendous amount of harm and confusion, because it's using a syntax that > people are accustomed to using with http and other URLs, but in very > different ways - and perhaps even in ways that vary arbitrarily as far as > users are concerned. But at least for the time being, that's irrelevant > unless/until either IESG rejects the document (perhaps realizing that the > result just creates too many problems) or an AD or IESG action gets > overturned on appeal. > > How do we quantify that type of harm? Especially against the knowledge that we will break many things currently in use today if we do not adhere to 3986 syntax? > So basically I think the immediate task before us is to clean up the > messes created by RFC 3986 and the decision to allow {f,p,q}-components in > URNs. > > On 03/29/2015 09:46 PM, John C Klensin wrote: > > Note that this issue is, I believe, somewhat redundant with one > discussed in an earlier note. I've tried to refer to it when > appropriate; please forgive remaining redundancy. > > > Yes, there is overlap, because these various AD and WG decisions interact > and have cumulative effects. It's difficult to talk about these effects > one at a time without introducing some redundancy, though splitting up the > topics is probably still a good way to have the discussion. > > --On Thursday, March 26, 2015 11:58 -0400 Keith Moore wrote: > > > ... > 4. Constraining URNs to RFC 3986 conventions is problematic. > One reason is that when using URNs to refer to > network-accessible resources there is a need for more > functions than those analogous to: references to internal > structure (presumably f-component), references to external > structure (presumably p-component), and access to the resource > as a service (presumably q-component). > > Those presumptions are not clear to me and may not be shared. > See my earlier discussion about interactions with a presumed URN > resolver versus pass-through to URL results and then try to > generalize it to URNs with different kinds of resolution > mechanisms and targets/results (if you have any trouble at all > picturing that for the general case, we are in the same boat and > that is why I didn't expand on that example). > > > A small number of examples illustrate why it is problematic. > > 1. A URN from a namespace which uses f-components is associated with, > and/or resolves to, either an HTML document or a service that produces an > HTML document when it is accessed. That HTML document contains relative > URIs that refer to fragments internal to, and identified within, that HTML > document. > > - With the f-component used for some other purpose, there is no way to > externally refer to those fragments. > - Also, any relative URI references within that document will cause > the document reader to construct identifiers that look like URNs contining > the base URN + the fragment identifier, and those identifiers will likely > leak in various ways (in the user interface, browser history, etc.) that at > the very least cause user confusion about how URNs are used. > > > (note that there's no assumption here that there's any intermediate URL > that also refers to the document, though there might be.) > > 2. A URN from a namespace which uses p-components is associated with, > and/or resolves to, either an HTML document or a service that produces an > HTML document when it is accessed. That HTML document contains one or > more relative URIs that contain "paths" that will, in the context of that > HTML document, be evaluated relative to the URN used to access or obtain > that document. Again, those relative URI references will leak in various > ways that will likely cause confusion. > > 3. A URN from a namespace which uses q-components is associated with, > and/or resolves to, either an HTML document or a service that produces an > HTML document when it is accessed. That HTML document contains either one > or more relative URIs that contain "queries" and/or one or more HTML forms > which use the GET method. In order to submit the form, the client reading > the HTML document will construct a URI from the base URN and the form > parameters using RFC 3986 "query" syntax. > > In a previous discussion on this list, relative resolution of URNs was discussed. As it stands today, relative resolution with regards to URNs is problematic at best. If your assertions are correct, this confusion would only break something that is already broken. > 4. A URN is used to identify a service which is accessed using HTTP[S]. > That service accepts query parameters using RFC3986 syntax. With the > current 2141bis language, there is no way that a client, user, or document > author can reliably construct a URI which is a composition of the URN used > to identify the service and the query parameters. If that client, user, > or document author happens to know how that particular namespace's resolver > works, that person might be able to construct such a URI - but those > assumptions fail with generic resolvers. > I guess we have not discussed the issue of generic URN resolvers (or if we have, its been done at an abstract level). Maybe this working group should explicitly discuss if considerations for generic URN resolvers are relevant. In my message from the other day, I noted that I could not find any implementations of a generic URN resolver. Given that, do you believe we have an obligation to continue with requirements for such software? > > 5. A URI or other string is constructed by adding one or more f-, p-, or > q- components to a base URN, following RFC 3986 syntax. It's not clear > from 2141bis -10 whether the resulting string is persistent or not, and > this might vary on a per-namespace basis. > > I agree. We need to discuss this. > 6. Users who are familiar with HTTP and other URLs will see '#', '/', and > '?' in URNs and think they know what these mean, think they know how to > manipulate them. (There's been a tremendous amount of misunderstanding > about URNs, even within IETF, which has hampered the actual utility of URNs > even by those who understand them.) > What types of users are you referencing? End users? Programmers? Protocol specifiers? This is just my opinion, but I would guess that end users have no idea what these different components mean or do and they never will. My experience with URI libraries tells me that programmers will also be in the dark for sometime to come*. And we know that protocol authors have asked for these changes. -andy * Aside: I know the IETF says it does not do APIs, but a URI/URN reference API would probably have been a good thing. The state of URI libraries is a mess, whereas the APIs for sockets are in much better shape and are very similar from one language to another. --001a113ac5b61fd4fc0512aec83d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 31, 2015 at 6:18 PM, Keith Moore <moore@network-h= eretics.com> wrote:
=20 =20 =20
Regarding 3986 in general, I recognize that there's a conundrum here.=C2=A0=C2=A0 As I understand things= , the AD explicitly imposed 3986 syntax on this group.=C2=A0=C2=A0 So I undert= and that the group has a hard time recommending a different approach.=C2=A0=C2=A0 Also, much of the group has long believed that = 3986 is adequate, and maybe there's already some use of that syntax in deployed URNs, so there's a lot of inertia behind that syntax.=C2= =A0=C2=A0


There was a proposal= before the working group to complete separate URNs from 3986, and it was t= he working group decision to adhere to 3986 syntax but to let go of 3986 se= mantics. Many pointed out that in today's world, URNs do appear in plac= es where URIs are expected (XML namespace specifications are a great exampl= e).
=C2=A0
So, regardless of what I personally believe, I'm not really tryin= g to persuade you or the group that 3986 should be abandoned.=C2=A0=C2= =A0=C2=A0 I do, however, think that, having decided to use that syntax (or having had that syntax imposed on it), the group has to solve the problems that result from that decision before it can expect its document to be approved as a proposed standard.

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


How do we quantify t= hat type of harm? Especially against the knowledge that we will break many = things currently in use today if we do not adhere to 3986 syntax?
=C2=A0
So basically I think the immediate task before us is to clean up the messes created by RFC 3986 and the decision to allow {f,p,q}-components in URNs.

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

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

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


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

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

A small number of examples illustrate why it is problematic.=C2=A0=C2= =A0

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

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

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

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


In a previous discussion on = this list, relative resolution of URNs was discussed. As it stands today, r= elative resolution with regards to URNs is problematic at best. If your ass= ertions are correct, this confusion would only break something that is alre= ady broken.
=C2=A0
4. A URN is used to identify a service which is accessed using HTTP[S].=C2=A0=C2=A0 That service accepts query parameters using RFC398= 6 syntax.=C2=A0=C2=A0=C2=A0 With the current 2141bis language, there is n= o way that a client, user, or document author can reliably construct a URI which is a composition of the URN used to identify the service and the query parameters.=C2=A0=C2=A0 If that client, user, or document author = happens to know how that particular namespace's resolver works, that person might be able to construct such a URI - but those assumptions fail with generic resolvers.

I gue= ss we have not discussed the issue of generic URN resolvers (or if we have,= its been done at an abstract level). Maybe this working group should expli= citly discuss if considerations for generic URN resolvers are relevant. In = my message from the other day, I noted that I could not find any implementa= tions of a generic URN resolver. Given that, do you believe we have an obli= gation to continue with requirements for such software?
=C2=A0

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


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

=C2=A0What types of users are you referen= cing? End users? Programmers? Protocol specifiers? This is just my opinion,= but I would guess that end users have no idea what these different compone= nts mean or do and they never will. My experience with URI libraries tells = me that programmers will also be in the dark for sometime to come*. And we = know that protocol authors have asked for these changes.

-andy

* Aside: I know the IETF says it does= not do APIs, but a URI/URN reference API would probably have been a good t= hing. The state of URI libraries is a mess, whereas the APIs for sockets ar= e in much better shape and are very similar from one language to another.
--001a113ac5b61fd4fc0512aec83d-- From nobody Wed Apr 1 14:50:13 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599BD1A8707 for ; Wed, 1 Apr 2015 14:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d85kS1Zq0qQf for ; Wed, 1 Apr 2015 14:50:00 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5EF41A870F for ; Wed, 1 Apr 2015 14:50:00 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C414620A10 for ; Wed, 1 Apr 2015 17:49:56 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Wed, 01 Apr 2015 17:50:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=+bqb5zVK9hcLfrLy41BbwHjz4iI=; b=afO3r UvdXZihGHKR70wB8eDc3lzt091snL8oyRPeczUF3wk/hruGEs+eZNmjThTzDbtoJ Kfrs4ND1rWfpYAdEw4F2jQXD5358dQNrY3VRyHzt73wuw/6LM89RUnU7Oy/fPNQO lH0DaEZMCq70AgK+Bsu1Y6ahrB0dHn785lZI+8= X-Sasl-enc: 6QugAJncQjWZDsbp3CoqmizYYtOuntHWYMdr/yBhPGUg 1427924999 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 91C6868015F; Wed, 1 Apr 2015 17:49:59 -0400 (EDT) Message-ID: <551C67F9.9070904@network-heretics.com> Date: Wed, 01 Apr 2015 17:49:45 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: urn@ietf.org References: <55142CA1.2000509@network-heretics.com> <20AE30F476B62E93E436DF1B@JcK-HP8200.jck.com> <551B1D53.6020206@network-heretics.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020904010902080609060304" Archived-At: Subject: Re: [urn] 3986 relationships X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 21:50:11 -0000 This is a multi-part message in MIME format. --------------020904010902080609060304 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 04/01/2015 03:32 PM, Andrew Newton wrote: > > > On Tue, Mar 31, 2015 at 6:18 PM, Keith Moore > > wrote: > > Regarding 3986 in general, I recognize that there's a conundrum > here. As I understand things, the AD explicitly imposed 3986 > syntax on this group. So I undertand that the group has a hard > time recommending a different approach. Also, much of the group > has long believed that 3986 is adequate, and maybe there's already > some use of that syntax in deployed URNs, so there's a lot of > inertia behind that syntax. > > > There was a proposal before the working group to complete separate > URNs from 3986, and it was the working group decision to adhere to > 3986 syntax but to let go of 3986 semantics. Many pointed out that in > today's world, URNs do appear in places where URIs are expected (XML > namespace specifications are a great example). Yes they do. But IMO, the harm presently done is minimal for the following reasons: (a) With RFC 2141 syntax (no use of '/', '?', or '#') there are many fewer ways for the URN to fail than with rfc2141bis URNs. (b) If an existing use of the URN broke things immediately, the URN would be replaced with a different kind of URI, so it's reasonable to assume that if a particular way of using a URN causes immediate, obvious, and consistent breakage, people will learn to not use them in that way. (c) Many of these are cases, like XML namespaces, where all that is really required is a unique string that has to be formatted as a URI. The URI is probably not even parsed, the resource is not accessed. The most that is done is that the URI compared for equivalence against other URIs. Also, 3986 syntax was deliberately a superset of 2141 syntax, so code written to parse URIs according to 3986 shouldn't fail with RFC 2141 URNs. That shouldn't be taken as any indication that use of f-components, p-components, and/or q-components with URNs won't break things. If this WG can't even agree on how to interpret those components in a consistent fashion, existing code is highly unlikely to interpret them reasonably. To put it another way, URNs that include any of these new components won't do anything useful with existing code no matter what syntax is used, so from the interoperability standpoint there's little benefit in overloading 3986 syntax. But I also believe that it's possible to define some profile of 3986 syntax that will permit "traditional" references to fragments and paths and use of queries, as well as perhaps some similar facilities that make more sense with URNs (if we could manage to define them), as well as the ability to communicate requests and parameters to resolvers. I just think that the result is either going to be *really* ugly and confusing to users, or significantly less functional than URLs. So it's not a technical problem so much as a usability problem and a question of whether something that's so ugly will actually be able to be reliably used in practice. > So, regardless of what I personally believe, I'm not really trying > to persuade you or the group that 3986 should be abandoned. I > do, however, think that, having decided to use that syntax (or > having had that syntax imposed on it), the group has to solve the > problems that result from that decision before it can expect its > document to be approved as a proposed standard. > > I continue to believe that the decision to use that syntax will > result in a tremendous amount of harm and confusion, because it's > using a syntax that people are accustomed to using with http and > other URLs, but in very different ways - and perhaps even in ways > that vary arbitrarily as far as users are concerned. But at > least for the time being, that's irrelevant unless/until either > IESG rejects the document (perhaps realizing that the result just > creates too many problems) or an AD or IESG action gets overturned > on appeal. > > > How do we quantify that type of harm? Especially against the knowledge > that we will break many things currently in use today if we do not > adhere to 3986 syntax? See above - introduction of new components to URNs is going to break things no matter what syntax is used, *especially when those components aren't even interpreted consistently from one URN to another*. But I agree that it's difficult to quantify that type of harm. > So basically I think the immediate task before us is to clean up > the messes created by RFC 3986 and the decision to allow > {f,p,q}-components in URNs. > > On 03/29/2015 09:46 PM, John C Klensin wrote: >> Note that this issue is, I believe, somewhat redundant with one >> discussed in an earlier note. I've tried to refer to it when >> appropriate; please forgive remaining redundancy. > > Yes, there is overlap, because these various AD and WG decisions > interact and have cumulative effects. It's difficult to talk > about these effects one at a time without introducing some > redundancy, though splitting up the topics is probably still a > good way to have the discussion. > >> --On Thursday, March 26, 2015 11:58 -0400 Keith Moore >> wrote: >> >>> ... >>> 4. Constraining URNs to RFC 3986 conventions is problematic. >>> One reason is that when using URNs to refer to >>> network-accessible resources there is a need for more >>> functions than those analogous to: references to internal >>> structure (presumably f-component), references to external >>> structure (presumably p-component), and access to the resource >>> as a service (presumably q-component). >> Those presumptions are not clear to me and may not be shared. >> See my earlier discussion about interactions with a presumed URN >> resolver versus pass-through to URL results and then try to >> generalize it to URNs with different kinds of resolution >> mechanisms and targets/results (if you have any trouble at all >> picturing that for the general case, we are in the same boat and >> that is why I didn't expand on that example). > > A small number of examples illustrate why it is problematic. > > 1. A URN from a namespace which uses f-components is associated > with, and/or resolves to, either an HTML document or a service > that produces an HTML document when it is accessed. That HTML > document contains relative URIs that refer to fragments internal > to, and identified within, that HTML document. > > * With the f-component used for some other purpose, there is no > way to externally refer to those fragments. > * Also, any relative URI references within that document will > cause the document reader to construct identifiers that look > like URNs contining the base URN + the fragment identifier, > and those identifiers will likely leak in various ways (in the > user interface, browser history, etc.) that at the very least > cause user confusion about how URNs are used. > > > (note that there's no assumption here that there's any > intermediate URL that also refers to the document, though there > might be.) > > 2. A URN from a namespace which uses p-components is associated > with, and/or resolves to, either an HTML document or a service > that produces an HTML document when it is accessed. That HTML > document contains one or more relative URIs that contain "paths" > that will, in the context of that HTML document, be evaluated > relative to the URN used to access or obtain that document. Again, > those relative URI references will leak in various ways that will > likely cause confusion. > > 3. A URN from a namespace which uses q-components is associated > with, and/or resolves to, either an HTML document or a service > that produces an HTML document when it is accessed. That HTML > document contains either one or more relative URIs that contain > "queries" and/or one or more HTML forms which use the GET > method. In order to submit the form, the client reading the HTML > document will construct a URI from the base URN and the form > parameters using RFC 3986 "query" syntax. > > > In a previous discussion on this list, relative resolution of URNs was > discussed. As it stands today, relative resolution with regards to > URNs is problematic at best. If your assertions are correct, this > confusion would only break something that is already broken. I haven't tried to do the entire case analysis of what happens when you try to resolve relative URIs with reference to base URNs of either the 2141 or 2141bis sort. It would probably be instructive to do so. (For instance, I now find myself wondering, what if a resource that's referred to by both URN N and URL L contains a link to a relative URI "?x"? The interpretation with respect to base URI L is well-understood - it means send "x" as a query to the resource. But if we apply 3986 rules for relative URI processing and 2141bis rules for interpretation of the result, it potentially means something entirely different, and the meaning is namespace-specific. Similarly for references to relative URI "#y".) In the meantime, I suspect that use of any relative URI with a RFC 2141 base URN either produces a reference to a fragment in the same resource in which it appears, and/or a query of the same resource in which it appears. (it could also refer to a fragment of the query result). If the relative URI only affects the "path", at most it's replacing the base URN's NSS with the text from the relative URI. Assuming anybody's actually relying on this (which I doubt), it's not going to break persistence - it's just a shorthand way of referring to another URN within the same namespace. But once you try to apply relative URIs to URNs with p-components, you then build an expectation into the resources named with those URNs, and using those relative URIs, that the URNs within that particular namespace are assigned according to some structure in which the p-components form a hierarchy, and not only the entire URN but also every enclosing subtree of that URN's "path" is persistent. That's fine if a particular namespace wants to assume that burden, but failure to do that breaks URN persistence. > 4. A URN is used to identify a service which is accessed using > HTTP[S]. That service accepts query parameters using RFC3986 > syntax. With the current 2141bis language, there is no way that > a client, user, or document author can reliably construct a URI > which is a composition of the URN used to identify the service and > the query parameters. If that client, user, or document author > happens to know how that particular namespace's resolver works, > that person might be able to construct such a URI - but those > assumptions fail with generic resolvers. > > > I guess we have not discussed the issue of generic URN resolvers (or > if we have, its been done at an abstract level). Maybe this working > group should explicitly discuss if considerations for generic URN > resolvers are relevant. In my message from the other day, I noted that > I could not find any implementations of a generic URN resolver. Given > that, do you believe we have an obligation to continue with > requirements for such software? I certainly believe personally that that work needs to be done, and over the past few days I've been thinking (once again) about how to do it. I've considered writing up a draft specification for it, just in case it's useful to this WG as a proof-of-concept. (one thing I've recently realized is that conditions today are MUCH more amenable to developing and deploying such a service than they were in the late 1990s) Whether this particular WG should try to define requirements or write a specification for such a service is a question for IESG, since it's not in the current WG's charter. (Of course if this WG doesn't want to take on that work, IESG is unlikely to ask it to do so.) > > 5. A URI or other string is constructed by adding one or more f-, > p-, or q- components to a base URN, following RFC 3986 syntax. > It's not clear from 2141bis -10 whether the resulting string is > persistent or not, and this might vary on a per-namespace basis. > > > I agree. We need to discuss this. > > 6. Users who are familiar with HTTP and other URLs will see '#', > '/', and '?' in URNs and think they know what these mean, think > they know how to manipulate them. (There's been a tremendous > amount of misunderstanding about URNs, even within IETF, which has > hampered the actual utility of URNs even by those who understand > them.) > > > What types of users are you referencing? End users? Programmers? > Protocol specifiers? This is just my opinion, but I would guess that > end users have no idea what these different components mean or do and > they never will. My experience with URI libraries tells me that > programmers will also be in the dark for sometime to come*. And we > know that protocol authors have asked for these changes. I never cease to be amazed at just how much a great many "ordinary" people know about subjects like HTML, CSS, URLs, JavaScript, SQL, PHP, and so on. (Though I don't know why this surprises me - many people who aren't mechanics know a decent amount about, say, automobiles and engines, and the web is as much a part of most of our lives as driving is.) I suspect that at least some of those "ordinary" people also will want to know how to use URNs, including how they interact with fragments and queries and relative URIs, especially if URNs can make the internal or external links in their web pages more reliable. IMO, our goal should be to make URNs so predictable, and so obviously useful, that browser vendors will want to include support for them in their products. And given that there aren't that many different browser codebases in widespread use, this shouldn't be a terribly daunting task. > > -andy > > * Aside: I know the IETF says it does not do APIs, but a URI/URN > reference API would probably have been a good thing. The state of URI > libraries is a mess, whereas the APIs for sockets are in much better > shape and are very similar from one language to another. agreed. Keith --------------020904010902080609060304 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 04/01/2015 03:32 PM, Andrew Newton wrote:


On Tue, Mar 31, 2015 at 6:18 PM, Keith Moore <moore@network-heretics.com> wrote:
Regarding 3986 in general, I recognize that there's a conundrum here. As I understand things, the AD explicitly imposed 3986 syntax on this group. So I undertand that the group has a hard time recommending a different approach. Also, much of the group has long believed that 3986 is adequate, and maybe there's already some use of that syntax in deployed URNs, so there's a lot of inertia behind that syntax.


There was a proposal before the working group to complete separate URNs from 3986, and it was the working group decision to adhere to 3986 syntax but to let go of 3986 semantics. Many pointed out that in today's world, URNs do appear in places where URIs are expected (XML namespace specifications are a great example).

Yes they do. But IMO, the harm presently done is minimal for the following reasons: (a) With RFC 2141 syntax (no use of '/', '?', or '#') there are many fewer ways for the URN to fail than with rfc2141bis URNs. (b) If an existing use of the URN broke things immediately, the URN would be replaced with a different kind of URI, so it's reasonable to assume that if a particular way of using a URN causes immediate, obvious, and consistent breakage, people will learn to not use them in that way. (c) Many of these are cases, like XML namespaces, where all that is really required is a unique string that has to be formatted as a URI. The URI is probably not even parsed, the resource is not accessed. The most that is done is that the URI compared for equivalence against other URIs.

Also, 3986 syntax was deliberately a superset of 2141 syntax, so code written to parse URIs according to 3986 shouldn't fail with RFC 2141 URNs. That shouldn't be taken as any indication that use of f-components, p-components, and/or q-components with URNs won't break things. If this WG can't even agree on how to interpret those components in a consistent fashion, existing code is highly unlikely to interpret them reasonably. To put it another way, URNs that include any of these new components won't do anything useful with existing code no matter what syntax is used, so from the interoperability standpoint there's little benefit in overloading 3986 syntax.

But I also believe that it's possible to define some profile of 3986 syntax that will permit "traditional" references to fragments and paths and use of queries, as well as perhaps some similar facilities that make more sense with URNs (if we could manage to define them), as well as the ability to communicate requests and parameters to resolvers. I just think that the result is either going to be *really* ugly and confusing to users, or significantly less functional than URLs. So it's not a technical problem so much as a usability problem and a question of whether something that's so ugly will actually be able to be reliably used in practice.

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

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


How do we quantify that type of harm? Especially against the knowledge that we will break many things currently in use today if we do not adhere to 3986 syntax?

See above - introduction of new components to URNs is going to break things no matter what syntax is used, *especially when those components aren't even interpreted consistently from one URN to another*.

But I agree that it's difficult to quantify that type of harm.

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

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

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

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


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

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

A small number of examples illustrate why it is problematic.

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

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

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

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


In a previous discussion on this list, relative resolution of URNs was discussed. As it stands today, relative resolution with regards to URNs is problematic at best. If your assertions are correct, this confusion would only break something that is already broken.

I haven't tried to do the entire case analysis of what happens when you try to resolve relative URIs with reference to base URNs of either the 2141 or 2141bis sort. It would probably be instructive to do so.

(For instance, I now find myself wondering, what if a resource that's referred to by both URN N and URL L contains a link to a relative URI "?x"? The interpretation with respect to base URI L is well-understood - it means send "x" as a query to the resource. But if we apply 3986 rules for relative URI processing and 2141bis rules for interpretation of the result, it potentially means something entirely different, and the meaning is namespace-specific. Similarly for references to relative URI "#y".)

In the meantime, I suspect that use of any relative URI with a RFC 2141 base URN either produces a reference to a fragment in the same resource in which it appears, and/or a query of the same resource in which it appears. (it could also refer to a fragment of the query result). If the relative URI only affects the "path", at most it's replacing the base URN's NSS with the text from the relative URI. Assuming anybody's actually relying on this (which I doubt), it's not going to break persistence - it's just a shorthand way of referring to another URN within the same namespace. But once you try to apply relative URIs to URNs with p-components, you then build an expectation into the resources named with those URNs, and using those relative URIs, that the URNs within that particular namespace are assigned according to some structure in which the p-components form a hierarchy, and not only the entire URN but also every enclosing subtree of that URN's "path" is persistent. That's fine if a particular namespace wants to assume that burden, but failure to do that breaks URN persistence.

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

I guess we have not discussed the issue of generic URN resolvers (or if we have, its been done at an abstract level). Maybe this working group should explicitly discuss if considerations for generic URN resolvers are relevant. In my message from the other day, I noted that I could not find any implementations of a generic URN resolver. Given that, do you believe we have an obligation to continue with requirements for such software?

I certainly believe personally that that work needs to be done, and over the past few days I've been thinking (once again) about how to do it. I've considered writing up a draft specification for it, just in case it's useful to this WG as a proof-of-concept. (one thing I've recently realized is that conditions today are MUCH more amenable to developing and deploying such a service than they were in the late 1990s)

Whether this particular WG should try to define requirements or write a specification for such a service is a question for IESG, since it's not in the current WG's charter. (Of course if this WG doesn't want to take on that work, IESG is unlikely to ask it to do so.)


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


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

What types of users are you referencing? End users? Programmers? Protocol specifiers? This is just my opinion, but I would guess that end users have no idea what these different components mean or do and they never will. My experience with URI libraries tells me that programmers will also be in the dark for sometime to come*. And we know that protocol authors have asked for these changes.

I never cease to be amazed at just how much a great many "ordinary" people know about subjects like HTML, CSS, URLs, JavaScript, SQL, PHP, and so on. (Though I don't know why this surprises me - many people who aren't mechanics know a decent amount about, say, automobiles and engines, and the web is as much a part of most of our lives as driving is.)

I suspect that at least some of those "ordinary" people also will want to know how to use URNs, including how they interact with fragments and queries and relative URIs, especially if URNs can make the internal or external links in their web pages more reliable.

IMO, our goal should be to make URNs so predictable, and so obviously useful, that browser vendors will want to include support for them in their products. And given that there aren't that many different browser codebases in widespread use, this shouldn't be a terribly daunting task.


-andy

* Aside: I know the IETF says it does not do APIs, but a URI/URN reference API would probably have been a good thing. The state of URI libraries is a mess, whereas the APIs for sockets are in much better shape and are very similar from one language to another.

agreed.

Keith

--------------020904010902080609060304-- From nobody Wed Apr 1 16:40:51 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A831ACD37 for ; Wed, 1 Apr 2015 16:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hz9H0_KOQAAZ for ; Wed, 1 Apr 2015 16:40:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0684.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::684]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1A81ACD35 for ; Wed, 1 Apr 2015 16:40:44 -0700 (PDT) Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 1 Apr 2015 23:40:25 +0000 Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0118.022; Wed, 1 Apr 2015 23:40:25 +0000 From: Larry Masinter To: "URN@IETF.ORG" Thread-Topic: use of fragment identifiers: issues are same for urn and all urls Thread-Index: AQHQbNU5QCJVzYbUqEWyvmZSFMzt6w== Date: Wed, 1 Apr 2015 23:40:24 +0000 Message-ID: <4D184BB8-7E88-4284-9C5D-298E8C2753E3@adobe.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150303 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [64.250.248.171] authentication-results: IETF.ORG; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1322; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(15975445007)(87936001)(50986999)(99286002)(2656002)(2351001)(106116001)(107886001)(92566002)(54356999)(19580395003)(2900100001)(122556002)(450100001)(82746002)(33656002)(83716003)(86362001)(1720100001)(102836002)(77156002)(2501003)(40100003)(36756003)(66066001)(46102003)(229853001)(62966003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1322; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR02MB1322; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB1322; x-forefront-prvs: 053315510E Content-Type: text/plain; charset="utf-8" Content-ID: <209F684FBABB48419C6D6B501ACC9D52@namprd02.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2015 23:40:24.7492 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1322 Archived-At: Subject: [urn] use of fragment identifiers: issues are same for urn and all urls X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 23:40:50 -0000 Rm9yIGEgZnJhZ21lbnQgaWRlbnRpZmllciB0byBiZSB1c2VmdWwsIHRoZXJlIG5lZWRzIHRvIGJl IHNvbWUgcHJvbWlzZS4NClVzaW5nIGEgZnJhZ21lbnQgaWRlbnRpZmllciB3aXRoIGFueSBVUkkg KHVybjogb3Igc29tZSBvdGhlciBzY2hlbWUpIGlzIGRvbmUgbG9vc2VseSBiZXN0LWVmZm9ydDsg aWYgeW91IHdhbnQgYSBVUkkgd2l0aCBmcmFnbWVudCB0byB3b3JrIG92ZXIgdGltZSwgeW91IG5l ZWQgdGhlIGV4cGVjdGF0aW9uIHRoYXQgZnJhZ21lbnQgaWRlbnRpZmllcnMgd29u4oCZdCBjaGFu Z2UuDQoNClRoZSBVUkwgYW5kIFVSTg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvYmNwMTE1 ICBhbmQgdXJuOmlldGY6YmNwOjExNQ0KDQphcmUgYm90aCBub3QgZ29vZCBVUklzIHRvIHB1dCBh ICNzZWN0aW9uLTMgZnJhZ21lbnQgb24sIGJlY2F1c2Ugd2hlbiBhbiB1cGRhdGUgdG8gQkNQIDEx NSBpcyBtYWRlLCBTZWN0aW9uIDMgbWlnaHQgYmUgYSB0b3RhbGx5IGRpZmZlcmVudCB0b3BpYy4N Cg0KDQpUaGUgVVJMIGFuZCBVUk4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0Mzk1 IGFuZCB1cm46aWV0ZjpyZmM6NDM5NQ0KDQpzaG91bGQgYm90aCBiZSBnb29kIGZvciBhICNzZWN0 aW9uLTMgZnJhZ21lbnQuIFRoZSBsYXR0ZXIgYmVjYXVzZSB0aGVyZSBpcyBhIGNyZWRpYmxlIHBv bGljeSBvZiBub3QgbWVzc2luZyB3aXRoICBSRkNzIG9uY2UgdGhleeKAmXJlIHB1Ymxpc2hlZCwg YW5kIHNlY3Rpb24gbnVtYmVycyB3aWxsIHJlbWFpbiBldmVuIGlmIFJGQ3MgYXJlIHJlcHVibGlz aGVkIGluIGRpZmZlcmVudCBmb3JtYXRzLg0KDQpJIHRoaW5rIGJlaW5nIGNhcmVmdWwgaW4gdGhp cyBraW5kIG9mIGNvbW1pdG1lbnQgbmVlZHMgdG8gYmUgcGFydCBvZiBuYW1lc3BhY2UgYXV0aG9y aXR5IHJlY29nbml0aW9uIHdoZW4gY29uc2lkZXJpbmcgYXBwbGljYWJpbGl0eSBhbmQgbG9uZ2V2 aXR5IG9mIGZyYWdtZW50IGlkZW50aWZpZXJzLg0KDQoNCg0KTGFycnkNCuKAlA0KaHR0cDovL2xh cnJ5Lm1hc2ludGVyLm5ldA0KDQoNCg0KDQoNCg== From nobody Wed Apr 1 19:22:00 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A407B1A1B28 for ; Wed, 1 Apr 2015 19:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8PwHnX4SRr0 for ; Wed, 1 Apr 2015 19:21:57 -0700 (PDT) Received: from APAC01-SG1-obe.outbound.protection.outlook.com (mail-sg1hn0124.outbound.protection.outlook.com [134.170.132.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FE601A1A97 for ; Wed, 1 Apr 2015 19:21:57 -0700 (PDT) Received: from [133.2.210.64] (133.2.210.64) by OS1PR01MB0133.jpnprd01.prod.outlook.com (25.161.228.149) with Microsoft SMTP Server (TLS) id 15.1.125.19; Thu, 2 Apr 2015 02:21:54 +0000 Message-ID: <551CA7BB.70308@it.aoyama.ac.jp> Date: Thu, 2 Apr 2015 11:21:47 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Larry Masinter , "URN@IETF.ORG" References: <4D184BB8-7E88-4284-9C5D-298E8C2753E3@adobe.com> In-Reply-To: <4D184BB8-7E88-4284-9C5D-298E8C2753E3@adobe.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS1PR01CA0009.jpnprd01.prod.outlook.com (25.161.225.147) To OS1PR01MB0133.jpnprd01.prod.outlook.com (25.161.228.149) Authentication-Results: IETF.ORG; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS1PR01MB0133; X-Microsoft-Antispam-PRVS: X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(6049001)(24454002)(51704005)(479174004)(47776003)(86362001)(66066001)(50466002)(110136001)(85202003)(65956001)(46102003)(74482002)(42186005)(33656002)(23676002)(65816999)(107886001)(85182001)(2950100001)(76176999)(19580395003)(50986999)(19580405001)(54356999)(83506001)(16601075003)(122386002)(64126003)(15975445007)(87976001)(2501003)(587094005)(62966003)(77156002)(1720100001)(92566002)(40100003)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS1PR01MB0133; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5005006)(5002010); SRVR:OS1PR01MB0133; BCL:0; PCL:0; RULEID:; SRVR:OS1PR01MB0133; X-Forefront-PRVS: 0534947130 X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Apr 2015 02:21:54.8140 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS1PR01MB0133 Archived-At: Subject: Re: [urn] use of fragment identifiers: issues are same for urn and all urls X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 02:21:59 -0000 I fully agree with Larry. I think it has been explained earlier on this list, but in the case of an URI (incl. URN) potentially being resolved to multiple formats (e.g. HTML and PDF,...), the considerations apply across formats. If there are some formats that don't handle fragment identifiers, then that's best seen as part of the "best effort" that Larry mentions below. Regards, Martin. On 2015/04/02 08:40, Larry Masinter wrote: > For a fragment identifier to be useful, there needs to be some promise. > Using a fragment identifier with any URI (urn: or some other scheme) is done loosely best-effort; if you want a URI with fragment to work over time, you need the expectation that fragment identifiers won’t change. > > The URL and URN > http://tools.ietf.org/html/bcp115 and urn:ietf:bcp:115 > > are both not good URIs to put a #section-3 fragment on, because when an update to BCP 115 is made, Section 3 might be a totally different topic. > > > The URL and URN > https://tools.ietf.org/html/rfc4395 and urn:ietf:rfc:4395 > > should both be good for a #section-3 fragment. The latter because there is a credible policy of not messing with RFCs once they’re published, and section numbers will remain even if RFCs are republished in different formats. > > I think being careful in this kind of commitment needs to be part of namespace authority recognition when considering applicability and longevity of fragment identifiers. > > > > Larry > — > http://larry.masinter.net > > > > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > From nobody Wed Apr 1 20:15:03 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AC31B29BB for ; Wed, 1 Apr 2015 20:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4A3Rut57D1_r for ; Wed, 1 Apr 2015 20:15:00 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB6BA1B29B7 for ; Wed, 1 Apr 2015 20:14:59 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D9EE6203E3 for ; Wed, 1 Apr 2015 23:14:55 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 01 Apr 2015 23:14:59 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=4TRCEIAnL1iKwh4 Pw5irrC1KVbw=; b=noHLWA8CCZ4h5nGlOLOaU401a0SWhNUByalM9UkWiSLRryk mIYMbGbo+1E01q1eZkyE/Kugo5FynmhJzaTbsXIAZqfP+4fsx33mk2M3YVMDD/DJ UNg2Xe4b4aT51/Q4RvyH0zAJSsYIBekQC9PO4VMV4bpOSZfzZP3nxpwyVZPg= X-Sasl-enc: /9GPbXDErX8Pni9bS+eUJ46bDJE23d/kjQlevxx8w03T 1427944498 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id CF1336800DE; Wed, 1 Apr 2015 23:14:58 -0400 (EDT) Message-ID: <551CB423.7070205@network-heretics.com> Date: Wed, 01 Apr 2015 23:14:43 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: urn@ietf.org References: <4D184BB8-7E88-4284-9C5D-298E8C2753E3@adobe.com> In-Reply-To: <4D184BB8-7E88-4284-9C5D-298E8C2753E3@adobe.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] use of fragment identifiers: issues are same for urn and all urls X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 03:15:01 -0000 On 04/01/2015 07:40 PM, Larry Masinter wrote: > For a fragment identifier to be useful, there needs to be some promise. > Using a fragment identifier with any URI (urn: or some other scheme) is done loosely best-effort; if you want a URI with fragment to work over time, you need the expectation that fragment identifiers won’t change. agree. > The URL and URN > http://tools.ietf.org/html/bcp115 and urn:ietf:bcp:115 > > are both not good URIs to put a #section-3 fragment on, because when an update to BCP 115 is made, Section 3 might be a totally different topic. agree. > The URL and URN > https://tools.ietf.org/html/rfc4395 and urn:ietf:rfc:4395 > > should both be good for a #section-3 fragment. The latter because there is a credible policy of not messing with RFCs once they’re published, and section numbers will remain even if RFCs are republished in different formats. agree. > I think being careful in this kind of commitment needs to be part of namespace authority recognition when considering applicability and longevity of fragment identifiers. either that or we explicitly declare that a URN including a fragment identifier is not required to be persistent, even though the base URN is required to be persistent. (or as some people phrase it, the fragment identifier is not "part of" the URN.) So I think it comes down to which is more burdensome: a) a prohibition on assigning a URN to any document that includes internal fragment identifiers that aren't stable b) not having URN + fragment identifier be persistent ? (or if it's on a per-namespace basis then the default case must be that the URN + fragment identifier can't be assumed to be persistent without specific knowledge of the namespace. but if an individual namespace wants to impose this additional constraint on the URNs that it assigns, it is free to do so.) Keith From nobody Wed Apr 1 20:26:34 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852901AD324 for ; Wed, 1 Apr 2015 20:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dk6Yn8gvKOhL for ; Wed, 1 Apr 2015 20:26:31 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623C71A1BC8 for ; Wed, 1 Apr 2015 20:26:31 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id E67A8209B7 for ; Wed, 1 Apr 2015 23:26:24 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 01 Apr 2015 23:26:28 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=uS+d8IHJTYtZG16 8M+11yFiEIQ8=; b=ce1I/zqDEKDY39LTwmPNlt1hWzJPWKcFBviyoiMbRhQkDwm 8/HjRzZIOBuZCKPj3dgh6g9laGVg8j/Zw+AVVBibyGAr1qT8yWAEKd+ex2Kcsjur DGLgwCvTUatWg5LTz7EMNcyRm65UlqswX/w4Rph1/LpgjH8faHMJZIU/+sEM= X-Sasl-enc: tTA0Q3NRZQZSp+ZQZCnR3DJMqN9xEcTCACpJSToZDHI7 1427945187 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 9EA03680158; Wed, 1 Apr 2015 23:26:27 -0400 (EDT) Message-ID: <551CB6D4.4040801@network-heretics.com> Date: Wed, 01 Apr 2015 23:26:12 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: urn@ietf.org References: <4D184BB8-7E88-4284-9C5D-298E8C2753E3@adobe.com> In-Reply-To: <4D184BB8-7E88-4284-9C5D-298E8C2753E3@adobe.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] use of fragment identifiers: issues are same for urn and all urls X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 03:26:33 -0000 I just realized that there's one more issue here: > The URL and URN > http://tools.ietf.org/html/bcp115 and urn:ietf:bcp:115 > > are both not good URIs to put a #section-3 fragment on, because when an update to BCP 115 is made, Section 3 might be a totally different topic. > > > The URL and URN > https://tools.ietf.org/html/rfc4395 and urn:ietf:rfc:4395 > > should both be good for a #section-3 fragment. The latter because there is a credible policy of not messing with RFCs once they’re published, and section numbers will remain even if RFCs are republished in different formats. > I think being careful in this kind of commitment needs to be part of namespace authority recognition when considering applicability and longevity of fragment identifiers. The problem is, for some period of time: a) Both of the above URNs refer to the same document b) At least one version of the document may contain fragments c) The ietf namespace doesn't control whether fragments get added to its URNs . Anyone can compose a URI consisting of urn:ietf:bcp:115 and a fragment identifier from rfc 4395, and it will work in the near term. So if IETF wants to make its (URN + fragment identifier) combinations persistent, it has two choices: a) don't assign BCP URNs b) don't put fragment identifiers in any version of its documents Neither choice seems very attractive. Keith From nobody Thu Apr 2 00:12:52 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416F61B2B8A for ; Thu, 2 Apr 2015 00:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUTFJT4LqJWN for ; Thu, 2 Apr 2015 00:12:36 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0AED1B2B6A for ; Thu, 2 Apr 2015 00:12:35 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YdZIj-000EPE-LF; Thu, 02 Apr 2015 03:12:29 -0400 Date: Thu, 02 Apr 2015 03:12:24 -0400 From: John C Klensin To: Andrew Newton , Keith Moore Message-ID: In-Reply-To: References: <55142CA1.2000509@network-heretics.com> <20AE30F476B62E93E436DF1B@JcK-HP8200.jck.com> <551B1D53.6020206@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] 3986 relationships X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 07:12:39 -0000 --On Wednesday, April 01, 2015 15:32 -0400 Andrew Newton wrote: > On Tue, Mar 31, 2015 at 6:18 PM, Keith Moore > wrote: > >> Regarding 3986 in general, I recognize that there's a >> conundrum here. As I understand things, the AD explicitly >> imposed 3986 syntax on this group. I don't think the AD is to blame. In some sense, the community did that when RFC 2396 was approved and it did not remove URNs from 3986 when it replaced 2396. >> So I undertand that the >> group has a hard time recommending a different approach. >> Also, much of the group has long believed that 3986 is >> adequate, and maybe there's already some use of that syntax >> in deployed URNs, so there's a lot of inertia behind that >> syntax. I'm not sure I understand what the above is intended to tell us. As far as I can tell, anything that conforms to the syntax of RFC 2141 conforms to that of 3986. Probably even most of the semantics are ok too. Issues arise only one when starts expanding syntax beyond 2141, even if it is done in ways that 2141 clearly anticipated (although, as you point out, didn't do... whether because people couldn't agree on parts of the issues or for other reasons). > There was a proposal before the working group to complete > separate URNs from 3986, and it was the working group decision > to adhere to 3986 syntax but to let go of 3986 semantics. Many > pointed out that in today's world, URNs do appear in places > where URIs are expected (XML namespace specifications are a > great example). >> So, regardless of what I personally believe, I'm not really >> trying to persuade you or the group that 3986 should be >> abandoned. I do, however, think that, having decided to >> use that syntax (or having had that syntax imposed on it), >> the group has to solve the problems that result from that >> decision before it can expect its document to be approved as >> a proposed standard. I certainly agree with that. However, if the WG sticks to its "adhere to 3986 syntax but avoid getting entangled with 3986 actual or implied semantics and arguments about them" position, I think those problems are actually quite few. They include issues with %-escapes and canonicalization for characters that 3986 does not allow to appear in non-encoded form (either generally, as in non-ASCII characters, or in specific contexts, such as some delimiters). For canonicalization (including normalization) we could in principle decide to do something scheme-wide or could push the problem down to the NID and namespace, but I agree that we need to decide. Similarly, I see no way to avoid deciding what to do about relative resolution but possible decisions could, I believe, lie anywhere in the range from "trying to do relative references with URNs will cause pain so don't do that" to "if you don't want relative references as specified in 3986, don't allow a '/' character (and hence a p-component) in the obvious place in a URN". >> I continue to believe that the decision to use that syntax >> will result in a tremendous amount of harm and confusion, >> because it's using a syntax that people are accustomed to >> using with http and other URLs, but in very different ways - >> and perhaps even in ways that vary arbitrarily as far as >> users are concerned. I actually agree with that. You and Larry probably remember that I expressed some concerns about creating a family of URIs and declaring that URNs were part of it in the first half of the 1990s. I would have preferred at that point that "name"-type things be distinguishable in basic syntax from "locator"-type things such that they could evolve separately and so that any protocol or context that wanted to support both would need to do explicitly rather than as an accident of similar syntax. I was obviously in the rough. I think you were on the winning side. But the discussions of the last few years, especially those associated with trying to minimize collateral damage from 3996, have convinced me I was probably right. That is _extremely_ scant comfort because the only way I can imagine getting to that point would be to essentially abandon URNs, develop some other scheme and non-URI syntax, and try to persuade those responsible for protocols that use both to provide for the new syntax. Even if I were convinced that was the right thing to do (and I'm not), I think the odds of the community accepting it are extremely low... just about zero. >> But at least for the time being, >> that's irrelevant unless/until either IESG rejects the >> document (perhaps realizing that the result just creates too >> many problems) or an AD or IESG action gets overturned on >> appeal. > How do we quantify that type of harm? Especially against the > knowledge that we will break many things currently in use > today if we do not adhere to 3986 syntax? I agree with Andy's question but let me ask a different one. Suppose the WG continues on its current path and reaches (probably very rough) consensus on something that appears to be syntax-conformant to 3986 and still meets the claimed needs of various communities for extended capabilities in URNs. Suppose that consensus solution is rejected or (ignoring a small detail of the appeals model) overturned as you suggest above. What do you see happening after that? What would you like to see happen? My guess is that the IESG would throw up its collective hands in despair and frustration and give up (not unlike the way it gave up on IRIs). The people whose needs are met by 2141 would continue to conform and point to 2141. The people who believe they need extended functionality and syntax beyond what 2141 allows conclude that the IETF, having given up, can't constrain their work any longer and essentially go off and do their thing, using strings that start in "urn:", followed by things that look like 2141-compatible NID and NSS strings, followed by some decorations that might or might not look like 3986 URI components. Some of them might gather together and figure out common ways to proceed, but that wouldn't be the IETF's problem (and certainly not under IETF control) whether they ended up with one such common way or with different communities and different approaches. Oh, and because the registration procedure for formal NIDs would remain IETF Consensus (as specified in RFC 3406) and these same arguments, plus arguments about 2141-conformance, would almost certainly break out any time someone tried to get a formal NID assigned that used enhanced (beyond 2141) capabilities or syntax, few of those would be registered and we'd almost inevitably end up with either a registry in Wikipedia or the like (but not IANA) or conflicts in which the same string was used as an NID to refer to different namespaces. Now, perhaps there are people in the WG who consider the above scenario a good outcome. If so, I wish they would speak up because, if that position represents WG consensus, we could save ourselves, the community, and the IESG a lot of energy by just giving up now and letting things take their course. Or perhaps you see plausible scenarios that avoid that one. If you do, please share. >> So basically I think the immediate task before us is to clean >> up the messes created by RFC 3986 and the decision to allow >> {f,p,q}-components in URNs. Should I take that to mean that you are, ultimately, just opposed to allowing those additional syntax elements in URNs and believe that we should stick to the syntax allowed by 2141, changing things that it reserved for future extension to permanent prohibitions? If so, that should be a relatively easy issue on which to ask the co-chairs to initiate a consensus call so we can at least focus future discussions and, if appropriate, stop struggling with a number of very problematic and complex specification tradeoffs and text. >> On 03/29/2015 09:46 PM, John C Klensin wrote: >... >> --On Thursday, March 26, 2015 11:58 -0400 Keith >> Moore >> wrote: >> >> >> ... >> 3. A URN from a namespace which uses q-components is >> associated with, and/or resolves to, either an HTML document >> or a service that produces an HTML document when it is >> accessed. That HTML document contains either one or more >> relative URIs that contain "queries" and/or one or more HTML >> forms which use the GET method. In order to submit the >> form, the client reading the HTML document will construct a >> URI from the base URN and the form parameters using RFC 3986 >> "query" syntax. >> > In a previous discussion on this list, relative resolution of > URNs was discussed. As it stands today, relative resolution > with regards to URNs is problematic at best. If your > assertions are correct, this confusion would only break > something that is already broken. See comment about relative resolution and the need to decide _something_ (which, to add to that list, could be to prohibit both p-components and relative anything, scheme-wide). The text in 2141bis-11 largely reflected Graham's comments and insistence on URN support for relative resolution but did so in the absence of comments from anyone else. The text is the best we could do given comments on the list -- I don't consider the issue closed until the co-chairs tell me/us it is. >> 4. A URN is used to identify a service which is accessed >> using HTTP[S]. That service accepts query parameters using >> RFC3986 syntax. With the current 2141bis language, there >> is no way that a client, user, or document author can >> reliably construct a URI which is a composition of the URN >> used to identify the service and the query parameters. If >> that client, user, or document author happens to know how >> that particular namespace's resolver works, that person might >> be able to construct such a URI - but those assumptions fail >> with generic resolvers. > I guess we have not discussed the issue of generic URN > resolvers (or if we have, its been done at an abstract level). > Maybe this working group should explicitly discuss if > considerations for generic URN resolvers are relevant. In my > message from the other day, I noted that I could not find any > implementations of a generic URN resolver. Given that, do you > believe we have an obligation to continue with requirements > for such software? Personal hypothesis: the community's cumulative set of decisions to have URNs that never resolve, URNs that resolve to URLs (possibly with a range of choice/selector functions), URNs that resolve to other sorts of things in the category Keith calls machine-parseable, URNs that resolve to other sorts of online or on-net objects if there are such things, and URNs that resolve only to physical (non-computer/ non-electronic) objects was the end of generic URN resolvers that actually do anything. I imagine that one could construct a sort of stub resolver that would look up NIDs and associated information and then pass the entire URN off to some appropriate place or one that would look up NIDs, determine a category from the above list, and pass the URN off to the handler for that category. I don't see either of those stubs as having much value, but others may reasonably disagree. If we do believe those functions are important and likely to be supported in libraries, etc., we'd better put some serious effort into ensuring that the right tables of information exist and are available online and that registering an NID gets them appropriately and reliably populated. >> 5. A URI or other string is constructed by adding one or more >> f-, p-, or q- components to a base URN, following RFC 3986 >> syntax. It's not clear from 2141bis -10 whether the >> resulting string is persistent or not, and this might vary on >> a per-namespace basis. >> > I agree. We need to discuss this. See my previous comment on how much we can usefully pin down "persistence" at this stage. I still think we need to discuss it, but parts of that discussion are going to be quite difficult unless I'm wrong and we really can define what we are talking about. >> 6. Users who are familiar with HTTP and other URLs will see >> '#', '/', and '?' in URNs and think they know what these >> mean, think they know how to manipulate them. (There's been >> a tremendous amount of misunderstanding about URNs, even >> within IETF, which has hampered the actual utility of URNs >> even by those who understand them.) > > What types of users are you referencing? End users? > Programmers? Protocol specifiers? This is just my opinion, but > I would guess that end users have no idea what these different > components mean or do and they never will. My experience with > URI libraries tells me that programmers will also be in the > dark for sometime to come*. And we know that protocol authors > have asked for these changes. I certainly agree with the above, especially the part about what end users know. I would add that almost every end user who thought he or she understood URIs (or even http URLs) and who proceeded to try to construct one URL from another by stripping, e.g., parts of the query or path and got a nasty and incomprehensible error message has learned, perhaps too well, not to mess with such things. > * Aside: I know the IETF says it does not do APIs, but a > URI/URN reference API would probably have been a good thing. > The state of URI libraries is a mess, whereas the APIs for > sockets are in much better shape and are very similar from one > language to another. I almost agree, but I think that attempts to build and implement such APIs or even a reference implementation, especially for the "generic URI" case, would mostly have exposed the difficulties with treating 3986 as an implementation specification. Independent of any other issues, it is full of "you can do zero or more of the following long list of things" statements. Unless it contains enough flags and indicators to make it nearly useless as an API, any implementation of such statements is ultimately a profile, not an implementation of the spec. best, john From nobody Thu Apr 2 01:57:31 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7881B2C0C for ; Thu, 2 Apr 2015 01:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.61 X-Spam-Level: X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNo41C0EC735 for ; Thu, 2 Apr 2015 01:57:28 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01C051B2C0A for ; Thu, 2 Apr 2015 01:57:27 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YdawF-000EcE-Ei; Thu, 02 Apr 2015 04:57:23 -0400 Date: Thu, 02 Apr 2015 04:57:18 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: <1FBC4E55C8B2CEE1B2CB9D3F@JcK-HP8200.jck.com> In-Reply-To: <551C67F9.9070904@network-heretics.com> References: <55142CA1.2000509@network-heretics.com> <20AE30F476B62E93E436DF1B@JcK-HP8200.jck.com> <551B1D53.6020206@network-heretics.com> <551C67F9.9070904@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] 3986 relationships X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 08:57:30 -0000 --On Wednesday, April 01, 2015 17:49 -0400 Keith Moore wrote: >> How do we quantify that type of harm? Especially against the >> knowledge that we will break many things currently in use >> today if we do not adhere to 3986 syntax? > > See above - introduction of new components to URNs is going to > break things no matter what syntax is used, *especially when > those components aren't even interpreted consistently from one > URN to another*. I think you are wandering in and out of URI-world in a way that I'm having trouble forming a good picture about. Probably my fault, but... This also goes to one of my difficulties with the design philosophy of 3986 and its predecessors although I try to accept them on their own terms. In the environment in which I learned about human-computer interface design, when a user told a computer system to do something, she was assumed to have a reasonable expectation that either the instruction would work or there would be a comprehensible explanation of why not. Having systems simply and silently discard anything they didn't understand or want to deal with was considered, not merely "broken" but seriously bad design. But 3986 doesn't work that way. To save someone having to explain it to me, one of the reasons for its not doing so is that the URI-interpreting routines may have no way to communicate with the user, making reliable delivery of a clear error or warning message impossible. From the standpoint of what I was taught in my youth, such statements are just symptoms of more fundamental bad system design, on a par with the sudden appearance of blue screens with "you lose" displayed in small letters on them. To use an illustration from one of Larry's notes, if one specifies a fragment (sic) with a a "mailto:" URI, nothing useful is going to happen. Neither 3986 nor 4395bis impose requirements for what the mailto handler/processor does with that fragment: because there is, in general, no media type associated with the resource, it can't use the thing, but those specs are indifferent to whether the fragment is silently discarded, an warning message is produced somehow and the email message opened and sent anyway, or an error message produced and the email system not involved at all. 4395bis doesn't even provide a place in the relevant templates, etc., for the scheme definition to announce how it handles (or expected mail interfaces to handle) such things. We could push Larry's example a bit an contemplate a forwarded or other message with multiple body parts and a fragment identifying one of the body parts. Certainly MIME messages and body parts have media types -- they were the environment for which what are now called media types were intended. Similarly, one could imagine a straightforward HTTP URL with a fragment identifier that might just have nothing to do with the relevant media type and content. Again, it is up to the local interpreter that deals with the retrieved file what to do with a non-matching or irrelevant media type: warning, error message, or silently discarding the fragment identifier. The scheme description for the "http" scheme does not impose a requirement and, more important, 4395bis and its predecessors don't require it to do so. My opinion about this behavior is largely irrelevant: it is how things work. And, to the extent to which users understand what is going on at all, they understand that, if a fragment (and I am going to talk about fragments, complete with 3986 semantics, in this example) is specified and doesn't match (for whatever reason) or do what they expected (for whatever reason), they may not get much information and may indeed have to guess what happened to the fragment from whatever behavior they observe. Now, coming back to URNs, suppose we have a namespace with NID "examplefrob". And suppose someone writes: urn:examplefrob:tom#foot Now, if that were interpreted by a namespace-sensitive routine and it knew that the "examplefrob" NID and namespace was purely 2141-conformant, the URN above would be a syntax error that it might report. If, instead, the URN processor ("generic resolver") were strictly 2141-conformant, the above would also be a syntax error _even if the examplefrob NID and namespace had a meaningful interpretation of fragments. So the first issue is that the user can't tell the difference between the two cases and the second is that, as with many other kinds of extensions, a user who tried to process a new extension through a legacy system that is hostile to extensions is probably going to be unhappy. A third case would be a URN processor that is loosely conformant to 2141 that would look at the syntax, say "no fragments allowed here" to itself, and silently discard "#foot", processing only the NID and NSS. Again, no information to the user. Now, if those cases are consistent with your definition of "broken", then I think I understand what you are concerned about, except (i) that definition makes it impossible to extend URNs at all and (ii) it is broken behavior with which most URI users have become tolerant (because they have no choice). Now this gets more interesting for the URN case if one posits urn:examplefrob:harry#foot Same NID as above but the fragment ID is valid for the "tom" case but not for the "harry" one because Harry has no feet. We can quibble about whether tom and harry should have the same media type but there is no possible URI requirement that their media types be different (at this point, you and I could have a conversation about media type parameters and their relationship to the situation, but let's skip that). Again, as far as the user is concerned, the fragment identifier is going to work sometimes and not others, what happens when it doesn't is not really a function of either the scheme or the namespace, and some perfectly legitimate versions of "not work" are going to be indistinguishable from "fragment never accepted" or "old processor". Moreover, if the user has only the "harry" URI above, she is likely to have no way to distinguish between "fragments are never permitted for scheme 'uri'", "fragments are never permitted for namespace 'examplefrob'", "the fragment 'foot' doesn't match or doesn't apply to NSS = 'harry' in the 'examplefrob' namespace", and "legacy URN processor/ generic resolver". For completeness, one might also have a different namespace that never allows fragments. Again, the user can't distinguish among the several different cases. It is pretty easy for me to argue that set of scenarios are equivalent to "broken" but the brokenness is in the fundamental URI design, not anything special to the URN case. For any user who has accepted (or just gotten used to) the operational implications, this range of URN examples are just no different from the assorted traditional URL cases. So I don't understand what is likely to be seen as broken or damaged here in practice that isn't already present in how URIs work Even the distinctions between "allowed or prohibited by scheme" and "allowed or prohibited by namespace" are likely to be invisible to the user. best, john From nobody Thu Apr 2 11:32:27 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305A51A0389 for ; Thu, 2 Apr 2015 11:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKHrcf-l73fn for ; Thu, 2 Apr 2015 11:32:20 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 215681A0266 for ; Thu, 2 Apr 2015 11:32:20 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3DCE0209EB for ; Thu, 2 Apr 2015 14:32:15 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 02 Apr 2015 14:32:18 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=gZTtepykE0MrsuvA8F22IjiQWoQ=; b=fb5c+ 6b9qfM5DHH+YXJV8J1d7lKYrQXOIRbbNIPMODVzRPPGrfdaOYaMIrPiVJFnPjZuY qgCY26W+Z3PnXpKePorkXPonioHuaqkFgG/hGrVVzbByLdchctI4XwKhBqTbX3rz OvqdWGQibwd3nP7TGiy/eRl+WekhipYUOs1Oqk= X-Sasl-enc: +2UndnCqwL1oYNuf4gNad0IQMo5MTsZlXiJAYWqsaNZb 1427999538 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id BDD24C00013; Thu, 2 Apr 2015 14:32:17 -0400 (EDT) Message-ID: <551D8B21.9020001@network-heretics.com> Date: Thu, 02 Apr 2015 14:32:01 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John C Klensin , Andrew Newton References: <55142CA1.2000509@network-heretics.com> <20AE30F476B62E93E436DF1B@JcK-HP8200.jck.com> <551B1D53.6020206@network-heretics.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020207000104070306010808" Archived-At: Cc: urn@ietf.org Subject: Re: [urn] 3986 relationships X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 18:32:26 -0000 This is a multi-part message in MIME format. --------------020207000104070306010808 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 04/02/2015 03:12 AM, John C Klensin wrote: > > --On Wednesday, April 01, 2015 15:32 -0400 Andrew Newton > wrote: > >> On Tue, Mar 31, 2015 at 6:18 PM, Keith Moore >> wrote: >> >>> Regarding 3986 in general, I recognize that there's a >>> conundrum here. As I understand things, the AD explicitly >>> imposed 3986 syntax on this group. > I don't think the AD is to blame. In some sense, the community > did that when RFC 2396 was approved and it did not remove URNs > from 3986 when it replaced 2396. I'd rather not think in terms of "blame". But I think that most of us understand, at some level, that 3986 is broken with respect to URNs (though we may not agree on the degree of brokenness or the specific ways in which it's broken). Absent AD direction, this WG could expect to have a fairly free hand in correcting that brokenness, since one Proposed Standard can update another. With the AD dictating a particular direction, that's a tad more difficult. >>> So, regardless of what I personally believe, I'm not really >>> trying to persuade you or the group that 3986 should be >>> abandoned. I do, however, think that, having decided to >>> use that syntax (or having had that syntax imposed on it), >>> the group has to solve the problems that result from that >>> decision before it can expect its document to be approved as >>> a proposed standard. > I certainly agree with that. However, if the WG sticks to its > "adhere to 3986 syntax but avoid getting entangled with 3986 > actual or implied semantics and arguments about them" position, > I think those problems are actually quite few. I think the number of problems that you end up with depends a great deal on how you address those problems. Some solutions leave more loose ends than others. > They include > issues with %-escapes and canonicalization for characters that > 3986 does not allow to appear in non-encoded form (either > generally, as in non-ASCII characters, or in specific contexts, > such as some delimiters). For canonicalization (including > normalization) we could in principle decide to do something > scheme-wide or could push the problem down to the NID and > namespace, but I agree that we need to decide. yes. > Similarly, I see > no way to avoid deciding what to do about relative resolution > but possible decisions could, I believe, lie anywhere in the > range from "trying to do relative references with URNs will > cause pain so don't do that" to "if you don't want relative > references as specified in 3986, don't allow a '/' character > (and hence a p-component) in the obvious place in a URN". I think it's a bit thornier than that, because relative URIs affect not only paths but also fragments and queries. > >>> I continue to believe that the decision to use that syntax >>> will result in a tremendous amount of harm and confusion, >>> because it's using a syntax that people are accustomed to >>> using with http and other URLs, but in very different ways - >>> and perhaps even in ways that vary arbitrarily as far as >>> users are concerned. > I actually agree with that. You and Larry probably remember > that I expressed some concerns about creating a family of URIs > and declaring that URNs were part of it in the first half of the > 1990s. I think most of us working to define URNs wanted them to be usable in most of the contexts that URLs were usable in, which implied at least some commonality in syntax between the two. In my mind, it would have been sufficient to say that the syntax for URN and URL prefixes was the same, and the set of characters allowed in each is the same, so that a parser could always tell where the URN/URL was terminated. (in those days, people cared a lot about being able to distinguish URNs/URLs from surrounding text, and of course this is still useful.) The parts of 3986 that seems dubious to me are: trying to shoehorn URNs into the HTTP URL syntax (thus limiting the types of modifiers that could be applied to URNs to the set that could be applied to HTTP URLs, even though URNs need at least one additional type of modifier), effectively imposing the HTML notion of fragments on all URIs, and imposing the HTML notion of relative URLs on all URIs. (Though in some sense the last bit of damage was already done as soon as HTML and its notion of relative references were widely adopted.) > I would have preferred at that point that "name"-type > things be distinguishable in basic syntax from "locator"-type > things such that they could evolve separately and so that any > protocol or context that wanted to support both would need to do > explicitly rather than as an accident of similar syntax. I was > obviously in the rough. I think you were on the winning side. > But the discussions of the last few years, especially those > associated with trying to minimize collateral damage from 3996, > have convinced me I was probably right. That is _extremely_ > scant comfort because the only way I can imagine getting to that > point would be to essentially abandon URNs, develop some other > scheme and non-URI syntax, and try to persuade those responsible > for protocols that use both to provide for the new syntax. > Even if I were convinced that was the right thing to do (and I'm > not), I think the odds of the community accepting it are > extremely low... just about zero. I think that even if we did that, we'd end up with many of the same problems. We'd still want these new identifiers to be usable in some of the contexts that URLs are usable in. We'd still want them to be compatible with HTML documents and their relative references. > >>> But at least for the time being, >>> that's irrelevant unless/until either IESG rejects the >>> document (perhaps realizing that the result just creates too >>> many problems) or an AD or IESG action gets overturned on >>> appeal. >> How do we quantify that type of harm? Especially against the >> knowledge that we will break many things currently in use >> today if we do not adhere to 3986 syntax? > I agree with Andy's question but let me ask a different one. > Suppose the WG continues on its current path and reaches > (probably very rough) consensus on something that appears to be > syntax-conformant to 3986 and still meets the claimed needs of > various communities for extended capabilities in URNs. Suppose > that consensus solution is rejected or (ignoring a small detail > of the appeals model) overturned as you suggest above. What do > you see happening after that? What would you like to see > happen? > > My guess is that the IESG would throw up its collective hands in > despair and frustration and give up (not unlike the way it gave > up on IRIs). My guess is similar to yours, though I'm not sure whether IESG or the WG does that first. The only way I see a different result is if the WG really does manage to figure out a sound solution to these problems so that it can go to IESG and say: "We now thoroughly understand what we need to do, please let us do it. " Earlier this morning I was thinking that the problem was that the majority of people in IETF don't understand the value of curated name spaces, and that a large constituency (mostly outside of IETF) that does understand that, doesn't necessarily understand network protocols and the web and all of the various ways that URIs interact with them. Problem is, URNs really do need to be worked out by people who have a good understanding of both, or at least with input from both sets of people. And while I think it hasn't done such a good job so far of getting both sets of people in the same "room" (real or virtual) and getting them to understand each other, IETF probably is still the best place for that to happen. At least I don't know of a better place. >>> So basically I think the immediate task before us is to clean >>> up the messes created by RFC 3986 and the decision to allow >>> {f,p,q}-components in URNs. > Should I take that to mean that you are, ultimately, just > opposed to allowing those additional syntax elements in URNs and > believe that we should stick to the syntax allowed by 2141, > changing things that it reserved for future extension to > permanent prohibitions? If so, that should be a relatively easy > issue on which to ask the co-chairs to initiate a consensus call > so we can at least focus future discussions and, if appropriate, > stop struggling with a number of very problematic and complex > specification tradeoffs and text. No, that's not my position at all. Ultimately what I want is to make it feasible to build general-purpose resolution services, to be able to write software that resolves URNs in a general manner (without having to wire-in namespace-specific dependencies that potentially change every time a new namespace is created), to be able to use URNs to refer to network-accessible resources in HTML and other documents where URLs are used (including compatibility with relative references and the ability to bundle URNs with queries and/or fragments), and for browsers and other clients to be able to support URNs wherever that makes sense. My only purposes in raising the "these problems didn't exist in 2141" points is to illustrate that the changes introduced in 2141bis really have created additional problems that need to be addressed, and to point out how 3986 constrains how we can address those already-difficult problems. >> I guess we have not discussed the issue of generic URN >> resolvers (or if we have, its been done at an abstract level). >> Maybe this working group should explicitly discuss if >> considerations for generic URN resolvers are relevant. In my >> message from the other day, I noted that I could not find any >> implementations of a generic URN resolver. Given that, do you >> believe we have an obligation to continue with requirements >> for such software? > Personal hypothesis: the community's cumulative set of decisions > to have URNs that never resolve, URNs that resolve to URLs > (possibly with a range of choice/selector functions), URNs that > resolve to other sorts of things in the category Keith calls > machine-parseable, URNs that resolve to other sorts of online or > on-net objects if there are such things, and URNs that resolve > only to physical (non-computer/ non-electronic) objects was the > end of generic URN resolvers that actually do anything. I don't think so. I think all that's required to have a generic URN resolver is to be able to do a database query for a URN. Basically that means being able to parse a URN, canonicalize it (if that's needed), and separate the components of the URN that aren't significant for resolution from those that are. That database can then do one or more of the following with the significant portion: * say it doesn't know anything about that particular URN * list other services that might provide information about URNs with that particular namespace (or some narrower set) * return bibliographic citation information for the resource associated with that URN * return locations at which the named resource may be accessed and/or from which its contents may be retrieved * refer the client to other versions of the resource associated with that URN, or resources related to that URN * provide access to the resource and/or the content of the resource (when applicable) One of the places at which we get into trouble with 3986 is that we'd really like to bundle together with the URN some information about which of the above results we want, and any other parameters that go with that request, and 3986 doesn't give us any way to do that without overloading syntax that is used for other purposes (including the relative references that are also described in 3986). > I > imagine that one could construct a sort of stub resolver that > would look up NIDs and associated information and then pass the > entire URN off to some appropriate place or one that would look > up NIDs, determine a category from the above list, and pass the > URN off to the handler for that category. I don't see either > of those stubs as having much value, but others may reasonably > disagree. If we do believe those functions are important and > likely to be supported in libraries, etc., we'd better put some > serious effort into ensuring that the right tables of > information exist and are available online and that registering > an NID gets them appropriately and reliably populated. While I'd love to see those tables compiled and made available, I don't think the resolution architecture should insist that any particular NID be limited to any of the above categories. And I think that the less that URN handling software needs to be driven by externally-maintained tables, the better. > > >>> 5. A URI or other string is constructed by adding one or more >>> f-, p-, or q- components to a base URN, following RFC 3986 >>> syntax. It's not clear from 2141bis -10 whether the >>> resulting string is persistent or not, and this might vary on >>> a per-namespace basis. >>> >> I agree. We need to discuss this. > See my previous comment on how much we can usefully pin down > "persistence" at this stage. I still think we need to discuss > it, but parts of that discussion are going to be quite difficult > unless I'm wrong and we really can define what we are talking > about. I think RFC 1737 is adequate. As far as I can tell, the problem with discussing URN persistence is that lots of people come into the discussion with preconceptions based on the analogous concept that they've adopted in their own communities, or the specific problem that they want to solve. URN persistence is deliberately a weak and vague notion of persistence, precisely because of the desire to be able to use URNs to name a wide variety of resources, whether or not network-accessible, whether or not implemented in code, whether or not based on data that can change over time (even continuously in some cases). Other communities have adopted definitions and rules for identifier assignment that suit their own purposes, and they may have decades or even centuries invested in those definitions and rules. As far as I can tell, that doesn't create a conflict with RFC 1737. RFC 1737 sets a minimum requirement; it doesn't prevent individual URN namespaces from imposing more stringent requirements. > >>> 6. Users who are familiar with HTTP and other URLs will see >>> '#', '/', and '?' in URNs and think they know what these >>> mean, think they know how to manipulate them. (There's been >>> a tremendous amount of misunderstanding about URNs, even >>> within IETF, which has hampered the actual utility of URNs >>> even by those who understand them.) >> What types of users are you referencing? End users? >> Programmers? Protocol specifiers? This is just my opinion, but >> I would guess that end users have no idea what these different >> components mean or do and they never will. My experience with >> URI libraries tells me that programmers will also be in the >> dark for sometime to come*. And we know that protocol authors >> have asked for these changes. > I certainly agree with the above, especially the part about what > end users know. I would add that almost every end user who > thought he or she understood URIs (or even http URLs) and who > proceeded to try to construct one URL from another by stripping, > e.g., parts of the query or path and got a nasty and > incomprehensible error message has learned, perhaps too well, > not to mess with such things. But they've also learned how to mess with such things, i.e. what works and what doesn't. > >> * Aside: I know the IETF says it does not do APIs, but a >> URI/URN reference API would probably have been a good thing. >> The state of URI libraries is a mess, whereas the APIs for >> sockets are in much better shape and are very similar from one >> language to another. > I almost agree, but I think that attempts to build and implement > such APIs or even a reference implementation, especially for the > "generic URI" case, would mostly have exposed the difficulties > with treating 3986 as an implementation specification. Well, sure, there's no problem with any protocol specification until you actually try to use it. :) But that's what we do in IETF - we make protocol specifications with the expectation that they'll be used. > Independent of any other issues, it is full of "you can do zero > or more of the following long list of things" statements. > Unless it contains enough flags and indicators to make it nearly > useless as an API, any implementation of such statements is > ultimately a profile, not an implementation of the spec. Only if we go down the path of permitting namespaces to use URN components in arbitrary ways. And that's precisely why we should NOT do that, and to the extent we permit individual namespaces to vary from uniform behavior, we should make them a finite list of well-documented exceptions, not to be propagated to future namespaces. Keith --------------020207000104070306010808 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 04/02/2015 03:12 AM, John C Klensin wrote:

--On Wednesday, April 01, 2015 15:32 -0400 Andrew Newton
<andy@hxr.us> wrote:


On Tue, Mar 31, 2015 at 6:18 PM, Keith Moore
<moore@network-heretics.com> wrote:


 Regarding 3986 in general, I recognize that there's a
 conundrum here. As I understand things, the AD explicitly
imposed 3986 syntax on this group.

I don't think the AD is to blame.   In some sense, the community
did that when RFC 2396 was approved and it did not remove URNs
from 3986 when it replaced 2396.

I'd rather not think in terms of "blame". But I think that most of us understand, at some level, that 3986 is broken with respect to URNs (though we may not agree on the degree of brokenness or the specific ways in which it's broken). Absent AD direction, this WG could expect to have a fairly free hand in correcting that brokenness, since one Proposed Standard can update another. With the AD dictating a particular direction, that's a tad more difficult.

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

I certainly agree with that.  However, if the WG sticks to its
"adhere to 3986 syntax but avoid getting entangled with 3986
actual or implied semantics and arguments about them" position,
I think those problems are actually quite few.
I think the number of problems that you end up with depends a great deal on how you address those problems. Some solutions leave more loose ends than others. 

   They include
issues with %-escapes and canonicalization for characters that
3986 does not allow to appear in non-encoded form (either
generally, as in non-ASCII characters, or in specific contexts,
such as some delimiters).  For canonicalization (including
normalization) we could in principle decide to do something
scheme-wide or could push the problem down to the NID and
namespace, but I agree that we need to decide.
yes.

Similarly, I see
no way to avoid deciding what to do about relative resolution
but possible decisions could, I believe, lie anywhere in the
range from "trying to do relative references with URNs will
cause pain so don't do that" to "if you don't want relative
references as specified in 3986, don't allow a '/' character
(and hence a p-component) in the obvious place in a URN".

I think it's a bit thornier than that, because relative URIs affect not only paths but also fragments and queries. 



I continue to believe that the decision to use that syntax
will result in a tremendous amount of harm and confusion,
because it's using a syntax that people are accustomed to
using with http and other URLs, but in very different ways -
and perhaps even in ways that vary arbitrarily as far as
users are concerned.

I actually agree with that.  You and Larry probably remember
that I expressed some concerns about creating a family of URIs
and declaring that URNs were part of it in the first half of the
1990s.

I think most of us working to define URNs wanted them to be usable in most of the contexts that URLs were usable in, which implied at least some commonality in syntax between the two. In my mind, it would have been sufficient to say that the syntax for URN and URL prefixes was the same, and the set of characters allowed in each is the same, so that a parser could always tell where the URN/URL was terminated. (in those days, people cared a lot about being able to distinguish URNs/URLs from surrounding text, and of course this is still useful.)

The parts of 3986 that seems dubious to me are: trying to shoehorn URNs into the HTTP URL syntax (thus limiting the types of modifiers that could be applied to URNs to the set that could be applied to HTTP URLs, even though URNs need at least one additional type of modifier), effectively imposing the HTML notion of fragments on all URIs, and imposing the HTML notion of relative URLs on all URIs. (Though in some sense the last bit of damage was already done as soon as HTML and its notion of relative references were widely adopted.)

I would have preferred at that point that "name"-type
things be distinguishable in basic syntax from "locator"-type
things such that they could evolve separately and so that any
protocol or context that wanted to support both would need to do
explicitly rather than as an accident of similar syntax.  I was
obviously in the rough.  I think you were on the winning side.
But the discussions of the last few years, especially those
associated with trying to minimize collateral damage from 3996,
have convinced me I was probably right. That is _extremely_
scant comfort because the only way I can imagine getting to that
point would be to essentially abandon URNs, develop some other
scheme and non-URI syntax, and try to persuade those responsible
for protocols that use both to provide for the new syntax.
Even if I were convinced that was the right thing to do (and I'm
not), I think the odds of the community accepting it are
extremely low... just about zero.

I think that even if we did that, we'd end up with many of the same problems. We'd still want these new identifiers to be usable in some of the contexts that URLs are usable in. We'd still want them to be compatible with HTML documents and their relative references. 



  But at least for the time being,
that's irrelevant unless/until either IESG rejects the
document (perhaps realizing that the result just creates too
many problems) or an AD or IESG action gets overturned on
appeal.


      

        
How do we quantify that type of harm? Especially against the
knowledge that we will break many things currently in use
today if we do not adhere to 3986 syntax?


      

      
I agree with Andy's question but let me ask a different one.
Suppose the WG continues on its current path and reaches
(probably very rough) consensus on something that appears to be
syntax-conformant to 3986 and still meets the claimed needs of
various communities for extended capabilities in URNs.  Suppose
that consensus solution is rejected or (ignoring a small detail
of the appeals model) overturned as you suggest above.   What do
you see happening after that?  What would you like to see
happen?    

My guess is that the IESG would throw up its collective hands in
despair and frustration and give up (not unlike the way it gave
up on IRIs).  

    

    

    My guess is similar to yours, though I'm not sure whether IESG or
    the WG does that first. The only way I see a different result is
    if the WG really does manage to figure out a sound solution to these
    problems so that it can go to IESG and say: "We now thoroughly
    understand what we need to do, please let us do it. "

    

    Earlier this morning I was thinking that the problem was that the
    majority of people in IETF don't understand the value of curated
    name spaces, and that a large constituency (mostly outside of IETF)
    that does understand that, doesn't necessarily understand network
    protocols and the web and all of the various ways that URIs interact
    with them. Problem is, URNs really do need to be worked out by
    people who have a good understanding of both, or at least with input
    from both sets of people. And while I think it hasn't done such a
    good job so far of getting both sets of people in the same "room"
    (real or virtual) and getting them to understand each other, IETF
    probably is still the best place for that to happen. At least I
    don't know of a better place.

    

    

      

        

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


        

      

      
Should I take that to mean that you are, ultimately, just
opposed to allowing those additional syntax elements in URNs and
believe that we should stick to the syntax allowed by 2141,
changing things that it reserved for future extension to
permanent prohibitions? If so, that should be a relatively easy
issue on which to ask the co-chairs to initiate a consensus call
so we can at least focus future discussions and, if appropriate,
stop struggling with a number of very problematic and complex
specification tradeoffs and text.

    

    

    No, that's not my position at all. Ultimately what I want is to
    make it feasible to build general-purpose resolution services, to be
    able to write software that resolves URNs in a general manner
    (without having to wire-in namespace-specific dependencies that
    potentially change every time a new namespace is created), to be
    able to use URNs to refer to network-accessible resources in HTML
    and other documents where URLs are used (including compatibility
    with relative references and the ability to bundle URNs with queries
    and/or fragments), and for browsers and other clients to be able to
    support URNs wherever that makes sense.

    

    My only purposes in raising the "these problems didn't exist in
    2141" points is to illustrate that the changes introduced in 2141bis
    really have created additional problems that need to be addressed,
    and to point out how 3986 constrains how we can address those
    already-difficult problems.

    

    

      

        
I guess we have not discussed the issue of generic URN
resolvers (or if we have, its been done at an abstract level).
Maybe this working group should explicitly discuss if
considerations for generic URN resolvers are relevant. In my
message from the other day, I noted that I could not find any
implementations of a generic URN resolver. Given that, do you
believe we have an obligation to continue with requirements
for such software?


      

      
Personal hypothesis: the community's cumulative set of decisions
to have URNs that never resolve, URNs that resolve to URLs
(possibly with a range of choice/selector functions), URNs that
resolve to other sorts of things in the category Keith calls
machine-parseable, URNs that resolve to other sorts of online or
on-net objects if there are such things, and URNs that resolve
only to physical (non-computer/ non-electronic) objects was the
end of generic URN resolvers that actually do anything.   

    

    

    I don't think so. I think all that's required to have a generic
    URN resolver is to be able to do a database query for a URN.
    Basically that means being able to parse a URN, canonicalize it (if
    that's needed), and separate the components of the URN that aren't
    significant for resolution from those that are. That database can
    then do one or more of the following with the significant portion:

    
    
      
  • say it doesn't know anything about that particular URN
    • 
      
  • list other services that might provide information about URNs
        with that particular namespace (or some narrower set)
    
      
    • 
      
  • return bibliographic citation information for the resource
        associated with that URN
    • 
      
  • return locations at which the named resource may be accessed
        and/or from which its contents may be retrieved
    
      
    • 
      
  • refer the client to other versions of the resource associated
        with that URN, or resources related to that URN
    
      
    • 
      
  • provide access to the resource and/or the content of the
        resource (when applicable)
    
      
    • 
    

    One of the places at which we get into trouble with 3986 is that
    we'd really like to bundle together with the URN some information
    about which of the above results we want, and any other parameters
    that go with that request, and 3986 doesn't give us any way to do
    that without overloading syntax that is used for other purposes
    (including the relative references that are also described in
    3986). 

    

    

      
I
imagine that one could construct a sort of stub resolver that
would look up NIDs and associated information and then pass the
entire URN off to some appropriate place or one that would look
up NIDs, determine a category from the above list, and pass the
URN off to the handler for that category.   I don't see either
of those stubs as having much value, but others may reasonably
disagree.  If we do believe those functions are important and
likely to be supported in libraries, etc., we'd better put some
serious effort into ensuring that the right tables of
information exist and are available online and that registering
an NID gets them appropriately and reliably populated.

    

    

    While I'd love to see those tables compiled and made available, I
    don't think the resolution architecture should insist that any
    particular NID be limited to any of the above categories. And I
    think that the less that URN handling software needs to be driven by
    externally-maintained tables, the better.

    

    

      

 


      

        

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



        

        
I agree. We need to discuss this.


      

      
See my previous comment on how much we can usefully pin down
"persistence" at this stage.  I still think we need to discuss
it, but parts of that discussion are going to be quite difficult
unless I'm wrong and we really can define what we are talking
about.

    

    

    I think RFC 1737 is adequate. 

    

    As far as I can tell, the problem with discussing URN persistence is
    that lots of people come into the discussion with preconceptions
    based on the analogous concept that they've adopted in their own
    communities, or the specific problem that they want to solve. URN
    persistence is deliberately a weak and vague notion of persistence,
    precisely because of the desire to be able to use URNs to name a
    wide variety of resources, whether or not network-accessible,
    whether or not implemented in code, whether or not based on data
    that can change over time (even continuously in some cases). Other
    communities have adopted definitions and rules for identifier
    assignment that suit their own purposes, and they may have decades
    or even centuries invested in those definitions and rules. As far
    as I can tell, that doesn't create a conflict with RFC 1737. RFC
    1737 sets a minimum requirement; it doesn't prevent individual URN
    namespaces from imposing more stringent requirements.

    

    

      



      

        

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


        

        
 What types of users are you referencing? End users?
Programmers? Protocol specifiers? This is just my opinion, but
I would guess that end users have no idea what these different
components mean or do and they never will. My experience with
URI libraries tells me that programmers will also be in the
dark for sometime to come*. And we know that protocol authors
have asked for these changes.


      

      
I certainly agree with the above, especially the part about what
end users know.   I would add that almost every end user who
thought he or she understood URIs (or even http URLs) and who
proceeded to try to construct one URL from another by stripping,
e.g., parts of the query or path and got a nasty and
incomprehensible error message has learned, perhaps too well,
not to mess with such things.

    

    

    But they've also learned how to mess with such things, i.e. what
    works and what doesn't.

    

    

      



      

        
* Aside: I know the IETF says it does not do APIs, but a
URI/URN reference API would probably have been a good thing.
The state of URI libraries is a mess, whereas the APIs for
sockets are in much better shape and are very similar from one
language to another.


      

      
I almost agree, but I think that attempts to build and implement
such APIs or even a reference implementation, especially for the
"generic URI" case, would mostly have exposed the difficulties
with treating 3986 as an implementation specification.

    

    

    Well, sure, there's no problem with any protocol specification until
    you actually try to use it. :)

    But that's what we do in IETF - we make protocol specifications with
    the expectation that they'll be used.

    

    

      
Independent of any other issues, it is full of "you can do zero
or more of the following long list of things" statements.
Unless it contains enough flags and indicators to make it nearly
useless as an API, any implementation of such statements is
ultimately a profile, not an implementation of the spec.  


    

    Only if we go down the path of permitting namespaces to use URN
    components in arbitrary ways. And that's precisely why we should
    NOT do that, and to the extent we permit individual namespaces to
    vary from uniform behavior, we should make them a finite list of
    well-documented exceptions, not to be propagated to future
    namespaces.

    

    Keith

    

    

  


--------------020207000104070306010808--


From nobody Fri Apr  3 10:30:10 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426711ACE39 for ; Fri,  3 Apr 2015 10:30:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.401
X-Spam-Level: 
X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVx3QCtZrY0e for ; Fri,  3 Apr 2015 10:30:02 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A951ACE38 for ; Fri,  3 Apr 2015 10:30:00 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 2F52520572 for ; Fri,  3 Apr 2015 13:29:54 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Fri, 03 Apr 2015 13:29:58 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=BNSfY9YeJdelID1zv9Czg2zj9WE=; b=EkNvX ng6856GsP5UzZRCjgTG+Nl25phbwqFyFVdA9i70uHbgntQs1/ZMViB7OEcXNM6/Y 73hlhooXKYJWeY5GCay7Z8++RIlpbWDcvetb7LB+R8F6/ocxvgQ1WQHLRU3I+SvJ NCO5qs+ldDQoma2GeNdEHW48sUE0EUfR189jVs=
X-Sasl-enc: AYgQFW1GJ1RawLAGCZad766cJ+AFmseFt5Ne7P5FhTBs 1428082197
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 2A15268009F; Fri,  3 Apr 2015 13:29:57 -0400 (EDT)
Message-ID: <551ECE01.5030702@network-heretics.com>
Date: Fri, 03 Apr 2015 13:29:37 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: urn@ietf.org
References: <55142CA1.2000509@network-heretics.com> <20AE30F476B62E93E436DF1B@JcK-HP8200.jck.com> <551B1D53.6020206@network-heretics.com>  <551C67F9.9070904@network-heretics.com> <1FBC4E55C8B2CEE1B2CB9D3F@JcK-HP8200.jck.com>
In-Reply-To: <1FBC4E55C8B2CEE1B2CB9D3F@JcK-HP8200.jck.com>
Content-Type: multipart/alternative; boundary="------------090709040200080200070702"
Archived-At: 
Subject: Re: [urn] 3986 relationships
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Apr 2015 17:30:09 -0000

This is a multi-part message in MIME format.
--------------090709040200080200070702
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Ok, without trying to respond to this paragraph-by-paragraph:

One challenge we face in designing Internet protocols is arranging that 
the errors get reported to the people who are in the best position to 
fix them.   Sadly, lots of widely-deployed, successful protocols do a 
poor job at this, and the web is no exception.  But I don't fault 
browser vendors for failing to display an error message every time a web 
page contains what is essentially a mis-spelled URI, because the user is 
almost certainly not in a position to do anything useful with that 
information.  So in general, clients are going to do the best they 
can.   If the URI refers to a resource that can be displayed, they'll 
display it, even if the URI specifies a fragment that cannot be found.  
Of course, if the URI refers to a nonexistent resource, an error message 
is the most reasonable action for a browser.   Or if the URI contains a 
query that causes the service to respond with an error message, 
reporting that error message to the user is also reasonable for the 
browser to do.

URNs introduce the potential for new ways of being malformed but many of 
those kinds of errors, are essentially mis-spellings.   I don't think we 
can prevent people from mis-spelling URNs, and I suspect that browsers 
and other clients will generally do reasonable things for these cases, 
just as with URLs.   (There are of course web content verifiers that may 
try to detect and report such errors, which is appropriate as those have 
the specific goal of informing the content creator/maintainer about 
errors in the content.)   But in general: the maxim "garbage in, garbage 
out" applies, and absent some security or serious interoperational 
concern, we probably shouldn't get too worried about trying to specify 
what the output garbage looks like for malformed input.

Here are examples of the kinds of errors which I am more concerned about:

1. Inconsistent behavior (when given a correct URN) from one 
URN-supporting client to the next

Examples:

  * If clients need to know specific details about each namespace (e.g.
    how {f,p,q}-components are interpreted) in order to process URNs for
    that namespace, and those details are subject to change over time,
    it's reasonable to expect that there will be namespaces for which
    client A knows how to deal "properly" but client B does not.   So
    client A will interpret urn:example:foo/bar?zot#mumble in one way
    (because it knows the specifics for interpretation of URN
    "example"), and client B will interpret the same URN a different way
    (because it does not know those specifics).   As a concrete example,
    perhaps client A will know that for the "example" namespace,
    f-components are interpreted by presenting them to a resolver that
    is specific to the example namespace, and that resolver will then
    either return the content corresponding to that f-component or a
    link to such content.   But B, not knowing that "example" URNs need
    special treatment, may consult a generic resolver, may not include
    the f-component in its query to that resolver, may try to process
    the f-component as if the URN were an ordinary URL, etc.

  * Similarly, if a resolver has to know specific details about each
    namespace to function (like whether f-components are significant for
    resolution) it's somewhat more difficult to build generic resolvers
    that can interface to databases of information that span multiple
    URN namespaces.


2. Inconsistent behavior between when a resource is referred to via a 
valid URN, versus referred to by a valid URL that points to the same 
resource

Examples:

  * If a resource contains a relative reference, say to a different path
    or query or fragment than the original URI that led to the resource,
    and that reference is used, the way 3986 is specified, evaluating
    that relative reference results in a new URI that replaces
    components of the base URI with components derived from the base URI
    and the relative reference.  If, say, the resource contains a link 
    to "#foo", then "#foo" will replace any fragment (if the base URI
    was a URL) or f-component (if it was a URN).   Now, if
    interpretation of f-components in the new URN is different than
    interpretation of fragments in the new URL, dereferencing "#foo"
    will produce different results in the two cases /even when #foo is
    valid//and both of the derived URIs are valid/.   Similarly for
    relative references that affect p- or q-components.
  * A client might have two different potential ways to present a
    resource named by a URN: (1) request the resource content from a
    resolution service, (2) request a URL for the same resource content
    from a resolution service, then request the resource content using
    that URL.   For reasons illustrated above, the effect of
    dereferencing "#foo" could be different depending on which of (1) or
    (2) is used.
  * A user reading a document obtained using a URN might wish to
    "bookmark" that document or specific information within that
    document.   It's hard to say exactly what the user interface should
    be in this case, but especially when the user wishes to bookmark a
    specific portion of that document, it would make sense for the
    client to associate that bookmark with a URI that is associated with
    that specific version and rendition of the document - as opposed to
    a version- or rendition-independent URI.   Again, if the meanings of
    {f,p,q}-components can change from one URI of the same resource to
    another, this might defeat the ability to do reliable bookmarking,
    as the URI chosen by the client as a version-specific URI, might be
    different than the one originally used.

3. Behavior associated with a valid URN, that yet changes over time - 
perhaps because client handling of that URN's namespace changed (the 
namespace changed its behavior to support {f,p,q}-components, or the 
client started supporting that behavior), or perhaps because the method 
of resolution of that URN changed (say from resolving via an 
intermediate URL to resolving directly to the content)

The whole point of URNs is to facilitate stable references.   If someone 
creates some content with links to URNs and those links work with a 
properly functioning client when the content is created, those links 
should continue to work as long as resolution services are available.   
So behavior of a particular namespace with respect to URN components 
shouldn't be allowed to change, nor should behavior change depending on 
the specific way that a resource is resolved (assuming that the RFC 1737 
persistence rule is followed).

Of course there will be buggy clients, and hopefully also fixes to buggy 
clients, which will change behavior over time.   And the user interface 
in a particular client might also change, especially as the 
understanding of how to best interface to URNs and the resources named 
by them evolves.   But if the specifications don't facilitate stable 
references, so that properly-written clients can't produce consistent 
behavior over time, we're the ones who will have failed.

Keith


On 04/02/2015 04:57 AM, John C Klensin wrote:
>
> --On Wednesday, April 01, 2015 17:49 -0400 Keith Moore
>  wrote:
>
>>> How do we quantify that type of harm? Especially against the
>>> knowledge  that we will break many things currently in use
>>> today if we do not  adhere to 3986 syntax?
>> See above - introduction of new components to URNs is going to
>> break things no matter what syntax is used, *especially when
>> those components aren't even interpreted consistently from one
>> URN to another*.
> I think you are wandering in and out of URI-world in a way that
> I'm having trouble forming a good picture about.  Probably my
> fault, but...
>
> This also goes to one of my difficulties with the design
> philosophy of 3986 and its predecessors although I try to accept
> them on their own terms.   In the environment in which I learned
> about human-computer interface design, when a user told a
> computer system to do something, she was assumed to have a
> reasonable expectation that either the instruction would work or
> there would be a comprehensible explanation of why not.   Having
> systems simply and silently discard anything they didn't
> understand or want to deal with was considered, not merely
> "broken" but seriously bad design.
>
> But 3986 doesn't work that way.  To save someone having to
> explain it to me, one of the reasons for its not doing so is
> that the URI-interpreting routines may have no way to
> communicate with the user, making reliable delivery of a clear
> error or warning message impossible.  From the standpoint of
> what I was taught in my youth, such statements are just symptoms
> of more fundamental bad system design, on a par with the sudden
> appearance of blue screens with "you lose" displayed in small
> letters on them.
>
> To use an illustration from one of Larry's notes, if one
> specifies a fragment (sic) with a a "mailto:" URI, nothing
> useful is going to happen.  Neither 3986 nor 4395bis impose
> requirements for what the mailto handler/processor does with
> that fragment: because there is, in general, no media type
> associated with the resource, it can't use the thing, but those
> specs are indifferent to whether the fragment is silently
> discarded, an warning message is produced somehow and the email
> message opened and sent anyway, or an error message produced and
> the email system not involved at all.  4395bis doesn't even
> provide a place in the relevant templates, etc., for the scheme
> definition to announce how it handles (or expected mail
> interfaces to handle) such things.
>
> We could push Larry's example a bit an contemplate a forwarded
> or other message with multiple body parts and a fragment
> identifying one of the body parts.  Certainly MIME messages and
> body parts have media types -- they were the environment for
> which what are now called media types were intended.
>
> Similarly, one could imagine a straightforward HTTP URL with a
> fragment identifier that might just have nothing to do with the
> relevant media type and content.   Again, it is up to the local
> interpreter that deals with the retrieved file what to do with a
> non-matching or irrelevant media type: warning, error message,
> or silently discarding the fragment identifier.  The scheme
> description for the "http" scheme does not impose a requirement
> and, more important, 4395bis and its predecessors don't require
> it to do so.
>
> My opinion about this behavior is largely irrelevant: it is how
> things work.   And, to the extent to which users understand what
> is going on at all, they understand that, if a fragment (and I
> am going to talk about fragments, complete with 3986 semantics,
> in this example) is specified and doesn't match (for whatever
> reason) or do what they expected (for whatever reason), they may
> not get much information and may indeed have to guess what
> happened to the fragment from whatever behavior they observe.
>
> Now, coming back to URNs, suppose we have a namespace with NID
> "examplefrob".  And suppose someone writes:
>
>     urn:examplefrob:tom#foot
>
> Now, if that were interpreted by a namespace-sensitive routine
> and it knew that the "examplefrob" NID and namespace was purely
> 2141-conformant, the URN above would be a syntax error that it
> might report.   If, instead, the URN processor ("generic
> resolver") were strictly 2141-conformant, the above would also
> be a syntax error _even if the examplefrob NID and namespace had
> a meaningful interpretation of fragments.  So the first issue is
> that the user can't tell the difference between the two cases
> and the second is that, as with many other kinds of extensions,
> a user who tried to process a new extension through a legacy
> system that is hostile to extensions is probably going to be
> unhappy.
>
> A third case would be a URN processor that is loosely conformant
> to 2141 that would look at the syntax, say "no fragments allowed
> here" to itself, and silently discard "#foot", processing only
> the NID and NSS.  Again, no information to the user.
>
> Now, if those cases are consistent with your definition of
> "broken", then I think I understand what you are concerned
> about, except (i) that definition makes it impossible to extend
> URNs at all and (ii) it is broken behavior with which most URI
> users have become tolerant (because they have no choice).
>
> Now this gets more interesting for the URN case if one posits
>    urn:examplefrob:harry#foot
>
> Same NID as above but the fragment ID is valid for the "tom"
> case but not for the "harry" one because Harry has no feet.  We
> can quibble about whether tom and harry should have the same
> media type but there is no possible URI requirement that their
> media types be different (at this point, you and I could have a
> conversation about media type parameters and their relationship
> to the situation, but let's skip that).  Again, as far as the
> user is concerned, the fragment identifier is going to work
> sometimes and not others, what happens when it doesn't is not
> really a function of either the scheme or the namespace, and
> some perfectly legitimate versions of "not work" are going to be
> indistinguishable from "fragment never accepted" or "old
> processor".  Moreover, if the user has only the "harry" URI
> above, she is likely to have no way to distinguish between
> "fragments are never permitted for scheme 'uri'", "fragments are
> never permitted for namespace 'examplefrob'", "the fragment
> 'foot' doesn't match or doesn't apply to NSS = 'harry' in the
> 'examplefrob' namespace", and "legacy URN processor/ generic
> resolver".
>
> For completeness, one might also have a different namespace that
> never allows fragments.  Again, the user can't distinguish among
> the several different cases.
>
> It is pretty easy for me to argue that set of scenarios are
> equivalent to "broken" but the brokenness is in the fundamental
> URI design, not anything special to the URN case.  For any user
> who has accepted (or just gotten used to) the operational
> implications, this range of URN examples are just no different
> from the assorted traditional URL cases.  So I don't understand
> what is likely to be seen as broken or damaged here in practice
> that isn't already present in how URIs work  Even the
> distinctions between "allowed or prohibited by scheme" and
> "allowed or prohibited by namespace" are likely to be invisible
> to the user.
>
>      best,
>       john
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn


--------------090709040200080200070702
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Ok, without trying to respond to this
      paragraph-by-paragraph:

      

      One challenge we face in designing Internet protocols is arranging
      that the errors get reported to the people who are in the best
      position to fix them. Sadly, lots of widely-deployed, successful
      protocols do a poor job at this, and the web is no exception. But
      I don't fault browser vendors for failing to display an error
      message every time a web page contains what is essentially a
      mis-spelled URI, because the user is almost certainly not in a
      position to do anything useful with that information. So in
      general, clients are going to do the best they can. If the URI
      refers to a resource that can be displayed, they'll display it,
      even if the URI specifies a fragment that cannot be found. Of
      course, if the URI refers to a nonexistent resource, an error
      message is the most reasonable action for a browser. Or if the
      URI contains a query that causes the service to respond with an
      error message, reporting that error message to the user is also
      reasonable for the browser to do.

      

      URNs introduce the potential for new ways of being malformed but
      many of those kinds of errors, are essentially mis-spellings. I
      don't think we can prevent people from mis-spelling URNs, and I
      suspect that browsers and other clients will generally do
      reasonable things for these cases, just as with URLs. (There are
      of course web content verifiers that may try to detect and report
      such errors, which is appropriate as those have the specific goal
      of informing the content creator/maintainer about errors in the
      content.) But in general: the maxim "garbage in, garbage out"
      applies, and absent some security or serious interoperational
      concern, we probably shouldn't get too worried about trying to
      specify what the output garbage looks like for malformed input.

      

      Here are examples of the kinds of errors which I am more concerned
      about:

      

      1. Inconsistent behavior (when given a correct URN) from one
      URN-supporting client to the next

      

      Examples:

      

      
    
        
  • If clients need to know specific details about each
          namespace (e.g. how {f,p,q}-components are interpreted) in
          order to process URNs for that namespace, and those details
          are subject to change over time, it's reasonable to expect
          that there will be namespaces for which client A knows how to
          deal "properly" but client B does not. So client A will
          interpret urn:example:foo/bar?zot#mumble in one way (because
          it knows the specifics for interpretation of URN "example"),
          and client B will interpret the same URN a different way
          (because it does not know those specifics). As a concrete
          example, perhaps client A will know that for the "example"
          namespace, f-components are interpreted by presenting them to
          a resolver that is specific to the example namespace, and that
          resolver will then either return the content corresponding to
          that f-component or a link to such content. But B, not
          knowing that "example" URNs need special treatment, may
          consult a generic resolver, may not include the f-component in
          its query to that resolver, may try to process the f-component
          as if the URN were an ordinary URL, etc.
    
          
    
        
    • 
        
  • Similarly, if a resolver has to know specific details about
          each namespace to function (like whether f-components are
          significant for resolution) it's somewhat more difficult to
          build generic resolvers that can interface to databases of
          information that span multiple URN namespaces. 
    
        
    • 
      

      

      2. Inconsistent behavior between when a resource is referred to
      via a valid URN, versus referred to by a valid URL that points to
      the same resource

      

      Examples:

      
    
        
  • If a resource contains a relative reference, say to a
          different path or query or fragment than the original URI that
          led to the resource, and that reference is used, the way 3986
          is specified, evaluating that relative reference results in a
          new URI that replaces components of the base URI with
          components derived from the base URI and the relative
          reference. If, say, the resource contains a link to "#foo",
          then "#foo" will replace any fragment (if the base URI was a
          URL) or f-component (if it was a URN). Now, if
          interpretation of f-components in the new URN is different
          than interpretation of fragments in the new URL, dereferencing
          "#foo" will produce different results in the two cases even
            when #foo is valid and both of the derived URIs are
            valid. Similarly for relative references that affect
          p- or q-components.
    • 
        
  • A client might have two different potential ways to present
          a resource named by a URN: (1) request the resource content
          from a resolution service, (2) request a URL for the same
          resource content from a resolution service, then request the
          resource content using that URL. For reasons illustrated
          above, the effect of dereferencing "#foo" could be different
          depending on which of (1) or (2) is used.
    • 
        
  • A user reading a document obtained using a URN might wish to
          "bookmark" that document or specific information within that
          document. It's hard to say exactly what the user interface
          should be in this case, but especially when the user wishes to
          bookmark a specific portion of that document, it would make
          sense for the client to associate that bookmark with a URI
          that is associated with that specific version and rendition of
          the document - as opposed to a version- or
          rendition-independent URI. Again, if the meanings of
          {f,p,q}-components can change from one URI of the same
          resource to another, this might defeat the ability to do
          reliable bookmarking, as the URI chosen by the client as a
          version-specific URI, might be different than the one
          originally used.
    
        
    • 
      

      3. Behavior associated with a valid URN, that yet changes over
      time - perhaps because client handling of that URN's namespace
      changed (the namespace changed its behavior to support
      {f,p,q}-components, or the client started supporting that
      behavior), or perhaps because the method of resolution of that URN
      changed (say from resolving via an intermediate URL to resolving
      directly to the content)

      

      The whole point of URNs is to facilitate stable references. If
      someone creates some content with links to URNs and those links
      work with a properly functioning client when the content is
      created, those links should continue to work as long as resolution
      services are available. So behavior of a particular namespace
      with respect to URN components shouldn't be allowed to change, nor
      should behavior change depending on the specific way that a
      resource is resolved (assuming that the RFC 1737 persistence rule
      is followed).

      

      Of course there will be buggy clients, and hopefully also fixes to
      buggy clients, which will change behavior over time. And the
      user interface in a particular client might also change,
      especially as the understanding of how to best interface to URNs
      and the resources named by them evolves. But if the
      specifications don't facilitate stable references, so that
      properly-written clients can't produce consistent behavior over
      time, we're the ones who will have failed.

      

      Keith

      

      

      On 04/02/2015 04:57 AM, John C Klensin wrote:

    

    

      

--On Wednesday, April 01, 2015 17:49 -0400 Keith Moore
<moore@network-heretics.com> wrote:



      

        

          
How do we quantify that type of harm? Especially against the
knowledge  that we will break many things currently in use
today if we do not  adhere to 3986 syntax?


        

        
See above - introduction of new components to URNs is going to
break things no matter what syntax is used, *especially when
those components aren't even interpreted consistently from one
URN to another*.


      

      
I think you are wandering in and out of URI-world in a way that
I'm having trouble forming a good picture about.  Probably my
fault, but...

This also goes to one of my difficulties with the design
philosophy of 3986 and its predecessors although I try to accept
them on their own terms.   In the environment in which I learned
about human-computer interface design, when a user told a
computer system to do something, she was assumed to have a
reasonable expectation that either the instruction would work or
there would be a comprehensible explanation of why not.   Having
systems simply and silently discard anything they didn't
understand or want to deal with was considered, not merely
"broken" but seriously bad design.

But 3986 doesn't work that way.  To save someone having to
explain it to me, one of the reasons for its not doing so is
that the URI-interpreting routines may have no way to
communicate with the user, making reliable delivery of a clear
error or warning message impossible.  From the standpoint of
what I was taught in my youth, such statements are just symptoms
of more fundamental bad system design, on a par with the sudden
appearance of blue screens with "you lose" displayed in small
letters on them.

To use an illustration from one of Larry's notes, if one
specifies a fragment (sic) with a a "mailto:" URI, nothing
useful is going to happen.  Neither 3986 nor 4395bis impose
requirements for what the mailto handler/processor does with
that fragment: because there is, in general, no media type
associated with the resource, it can't use the thing, but those
specs are indifferent to whether the fragment is silently
discarded, an warning message is produced somehow and the email
message opened and sent anyway, or an error message produced and
the email system not involved at all.  4395bis doesn't even
provide a place in the relevant templates, etc., for the scheme
definition to announce how it handles (or expected mail
interfaces to handle) such things.

We could push Larry's example a bit an contemplate a forwarded
or other message with multiple body parts and a fragment
identifying one of the body parts.  Certainly MIME messages and
body parts have media types -- they were the environment for
which what are now called media types were intended.

Similarly, one could imagine a straightforward HTTP URL with a
fragment identifier that might just have nothing to do with the
relevant media type and content.   Again, it is up to the local
interpreter that deals with the retrieved file what to do with a
non-matching or irrelevant media type: warning, error message,
or silently discarding the fragment identifier.  The scheme
description for the "http" scheme does not impose a requirement
and, more important, 4395bis and its predecessors don't require
it to do so.

My opinion about this behavior is largely irrelevant: it is how
things work.   And, to the extent to which users understand what
is going on at all, they understand that, if a fragment (and I
am going to talk about fragments, complete with 3986 semantics,
in this example) is specified and doesn't match (for whatever
reason) or do what they expected (for whatever reason), they may
not get much information and may indeed have to guess what
happened to the fragment from whatever behavior they observe.  

Now, coming back to URNs, suppose we have a namespace with NID
"examplefrob".  And suppose someone writes:

   urn:examplefrob:tom#foot

Now, if that were interpreted by a namespace-sensitive routine
and it knew that the "examplefrob" NID and namespace was purely
2141-conformant, the URN above would be a syntax error that it
might report.   If, instead, the URN processor ("generic
resolver") were strictly 2141-conformant, the above would also
be a syntax error _even if the examplefrob NID and namespace had
a meaningful interpretation of fragments.  So the first issue is
that the user can't tell the difference between the two cases
and the second is that, as with many other kinds of extensions,
a user who tried to process a new extension through a legacy
system that is hostile to extensions is probably going to be
unhappy.

A third case would be a URN processor that is loosely conformant
to 2141 that would look at the syntax, say "no fragments allowed
here" to itself, and silently discard "#foot", processing only
the NID and NSS.  Again, no information to the user. 

Now, if those cases are consistent with your definition of
"broken", then I think I understand what you are concerned
about, except (i) that definition makes it impossible to extend
URNs at all and (ii) it is broken behavior with which most URI
users have become tolerant (because they have no choice).  

Now this gets more interesting for the URN case if one posits
  urn:examplefrob:harry#foot

Same NID as above but the fragment ID is valid for the "tom"
case but not for the "harry" one because Harry has no feet.  We
can quibble about whether tom and harry should have the same
media type but there is no possible URI requirement that their
media types be different (at this point, you and I could have a
conversation about media type parameters and their relationship
to the situation, but let's skip that).  Again, as far as the
user is concerned, the fragment identifier is going to work
sometimes and not others, what happens when it doesn't is not
really a function of either the scheme or the namespace, and
some perfectly legitimate versions of "not work" are going to be
indistinguishable from "fragment never accepted" or "old
processor".  Moreover, if the user has only the "harry" URI
above, she is likely to have no way to distinguish between
"fragments are never permitted for scheme 'uri'", "fragments are
never permitted for namespace 'examplefrob'", "the fragment
'foot' doesn't match or doesn't apply to NSS = 'harry' in the
'examplefrob' namespace", and "legacy URN processor/ generic
resolver".

For completeness, one might also have a different namespace that
never allows fragments.  Again, the user can't distinguish among
the several different cases.

It is pretty easy for me to argue that set of scenarios are
equivalent to "broken" but the brokenness is in the fundamental
URI design, not anything special to the URN case.  For any user
who has accepted (or just gotten used to) the operational
implications, this range of URN examples are just no different
from the assorted traditional URL cases.  So I don't understand
what is likely to be seen as broken or damaged here in practice
that isn't already present in how URIs work  Even the
distinctions between "allowed or prohibited by scheme" and
"allowed or prohibited by namespace" are likely to be invisible
to the user.

    best,
     john

_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn


    

    

  


--------------090709040200080200070702--


From nobody Fri Apr  3 12:49:58 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024241A017D for ; Fri,  3 Apr 2015 12:49:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.21
X-Spam-Level: 
X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AztfPqTVDcLJ for ; Fri,  3 Apr 2015 12:49:54 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC86D1A0266 for ; Fri,  3 Apr 2015 12:49:52 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Ye7bE-0000fA-1W for urn@ietf.org; Fri, 03 Apr 2015 15:49:52 -0400
Date: Fri, 03 Apr 2015 15:49:47 -0400
From: John C Klensin 
To: urn@ietf.org
Message-ID: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Subject: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Apr 2015 19:49:57 -0000

ABSTRACT /SUMMARY for this rather long note:

p-components seem to a focus of controversy, possibly blocking
other work and general progress in the WG.  This note tries to
summarize and analyze the controversy, asks if p-components are
important enough that we need to resolve that controversy, and
proposes an alternative if they are not.

Other other circumstances, I might just have written this note
and proposal as an I-D, but it is really just an exploration,
not a proposal.




Hi.

Several comments in the last couple of weeks have raised issues
with what are called p-components in 2141bis.  Most, but not
all, of those notes have focused particularly on interactions
with hierarchy and relative resolution.

In the interest of getting done, I want to see if the WG can
reexamine p-components rather than trying to dissect 3986 and
its implications in this area.  This note will do some
examination of 3986 interactions, but please bear with me.

Assumption: I am taking the applicability of 3986 syntax but
not semantics (as discussed in Andy's consensus call and
draft-ietf-urnbis-semantics-clarif, although that document is
still open to textual improvements) and the need to expand
allowable URN syntax beyond those of RFC 2141 (and 3046) as
given.  If there is anyone following the URN list who sees the
discussions about hierarchy, relative resolution, or
applicability of their interpretation of 3986 rules (with or
without draft-ietf-appsawg-uri-scheme-reg) as a way to kill
either 2141bis or URNs generally by a death of a thousand cuts,
this note will probably not be helpful to them.


THE ISSUES: 

Those who have spoken up about issues involving p-components
(or the use of "/" in URNs) should check this to be sure I
haven't mischaracterized their positions (and correct me if I
have), but I believe the main concerns, as presented by others
and with which I generally do not agree, are:

(Issue 1): Despite the "no 3986 semantics" rule, we really
cannot have a path or any use of a "/" in any URI, URNs
included, without making that URI hierarchical.  From that
perspective, we can't say "URNs are not hierarchical", which
2141bis-11 does say [1], and allow "/".  Other than relative
resolution issues, it is not clear whether this issue has any
practical impact or is [just] an argument that the "not
hierarchical" paragraph is self-contradictory and should be
rewritten somehow.

(Issue 2): The generic URI parsers [2] will apply relative
resolution processing if a "/" is seen, or perhaps even if it
is not.  So such processing is inevitable, cannot be opted out
of by URNs, and will cause serious damage to URNs if we try.

(Issue 3): Relative resolution is very important to some other
URIs, current and permanent or planned.  If URNs impose
restrictions on relative resolution operatons, even
restrictions that apply only to URNs, it will be damaging to
those other URIs.

(Issue 4): Because URNs are non-hierarchical and relative
resolution would cause problems or meaningless results, URNs
should not allow "/" unless the particular namespace actually
is hierarchical and relative resolution is appropriate.

(Issue 5): It is not possible to decide that a URI scheme does
not support relative resolution.  All URIs have to support such
resolution.  

(Issue 6): Because it is not possible for a scheme to disallow
relative resolution, URNs cannot make support for them a
per-namespace issue either.


PRELIMINARY ANALYSIS:

There are some contradictions in the list above that don't
make it easier to form a complete picture, much less figure out
which arguments are valid or not.  Issues 1, 5, 6, and probably
4 are really about semantics so, unless it really is impossible
to separate the actual syntax restrictions in 3986 from its
semantic ones [3], their relevancy is questionable.

The overall issue appears to be further complicated by an
apparent (but not explicitly written down anywhere that I've
found) principle for URIs, which is that meaningless
constructions are ok.  So, as discussed in earlier notes in the
context of fragments, if a URI is associated with a resource
and a fragment is specified that makes no sense for the
resource, whatever processor is dealing with the URI and/or the
resource is free to just discard it rather than letting it
interfere with other operations.  For the particular case of
"/" and despite the restriction in 2141, nothing prevents
someone from writing "urn:some-NID:some-NSS/garbage" today and
using it in some URI context.  It would presumably be
meaningless and different namespace-specific action routines
would deal with it in different ways, but AFAICT, no one has
shown evidence of horrible damage, whether to generic URI
parsers, the nature of URNs, or otherwise.  Similarly, 3986
makes it quite clear that false negatives are ok and so on.

At ;east for some people, that principle (and the absence of
general damage when it is applied) do not appear to apply where
URNs are involved.  When we tried to propose a note in 2141bis
that would have said, effectively, 

   "Relative resolution as described in RFC 3986 is likely to
   be meaningless for URNs.  Parsers and processors that are
   aware they are dealing with URIs with the
   'urn:' scheme SHOULD NOT attempt to process relative
   references.  However, if that processing is performed,
   perhaps by a generic system that is not aware of particular
   schemes, and results in meaningless results, the relevant
   system should be prepared to just move on."

For the particular case of the "urn:" scheme, we get
repetitions of one or more of the issues about.

I don't know what to do with the other issues, especially
because of the difficulties with claims about generic URI
parsers (see note [2] below).  So let's come back to the
issue.


WHY WOULD WE WANT A p-COMPONENT?

URNs are very much tied up with the principle of "persistence"
(or even "permanence".  Many of us believe we know,
intuititively, what persistence of an identifier means, but we
have been unsuccessful in proposing, much less agreeing on, a
definition that is sufficiently precise to discriminate among
boundary or edge cases [4].  For URNs (perhaps more so than
URIs generally) careful and accurate matching and being clear
about what compnents of the string are considered stable/
persistent has seemed to be especially important.  Neither
f-components (which those who want to think of them as 3986
fragments believe are inherently bound to target objects and
not the URI) and q-components (which, as Keith and others,
including myself, have pointed out, raise questions of
relationship between instructions to the URN processor and
instructions to/about targets) are problematic from both
persistence and comparison purposes.  2141bis has explicitly
excluded both from equality comparisons for just those reasons.

For those namespaces that need additional qualification (beyond
the traditional NSS) that still participates in equality
checking, that has so far left p-components as the only logical
option.  Perhaps there is some other syntax that would do the
job --a hypothetical X-component -- but, so far, no one has
proposed one and the logic of 3986 is such that I think we can
expect any such syntax proposal to produce cries of pain about
generic URI parsers and related topics.

If we have p-components anyway, there are also advantages to
actual or potential namespaces that use the "/" character in
their identifying strings.  Of course, we could simply declare
the separation of NSS from p-components to be an artifact of
3986 semantics and solve the identifying string problem by
allowing the "/" in the NSS, but doing so would not help with
either the "generic URI parser" or relative resolution issue,
nor would it help those who look at a "/" in something that
appears to be a URI and see "hierarchy" (probably in large
letters).


A ROTTEN, BUT POSSIBLY DESIRABLE, CHOICE

The theoretical argument for p-components is above.  I think we
also need to remember that opening 2141 (and at least
implicitly 3406) to allow additinoal syntax has been incredibly
painful and that, after 2141bis is complete and approved,
opening or revising it to allow yet more syntax is likely to be
even more painful.  That may be a good argument for adding
p-components now, even if doing so creates some pain, just to
have it over with.

However, the above theorizing aside, I have not seen any real
demand for p-components on the mailing list.  If there is such
demand, I hope that those who have current needs will come
forward and explain them.  But, if there is not and
p-components are likely to be a source of blocking
controversies, another option would be to modify 2141bis to
reserve the syntax but prohibit registration (and, to the
extent we have the power, use) of URNs containing them until
and unless future documents appear that address the issues.

Because I'm very concerned about the "death of a thousand cuts"
mentioned above, I would hope that the WG would insist that
anyone arguing for getting p-components out of the current
disucssion by pushing them into the future would assure us that
they would not turn around and raise other supposedly-blocking
issues, but I recognize that there is ultimately no way to
prevent that behavior other than by assurance of good faith.

Were we to decide to push p-components aside, the WG should
decide whether it would be desirable to have an informational
appendix or separate informational document that records what
we believe the issues are and why we reached the decisions we
did as a starting point for future work.  This note might be a
good starting point.  Had we had a supplmental document for
2141 that identified the issues and reasons additional syntax
was deferred, it might have saved us a year or three in the
current efforts (and/or had a restrictive impact on 3986).
But, if we translated the controversies about the implications
of p-components into difficulty getting consensus about such an
explanation, perhaps it would just be better to bequeath the
issues to the future.

best,
    john


             -------------------------

NOTES

[1] draft-ietf-urnbis-rfc2141bis-urn-11, Section 5, 
  paragraph 2.

(2] "Generic URI parsers" are problematic in another way that
  should be kept in mind.  They have been invoked frequently in
  these (URN) and other discussions about URIs, but it seems to
  me that, each time someone tries to pin down exactly what
  they do and how libraries compare, the answers are wildly
  different, with some systems that are considered to be such
  parsers by their authors or advocates doing little other than
  separate the scheme name from the rest of the URI, others
  trying very hard to interpret and implement every aspect of
  3986 including its deep semantics (because 3986 includes many
  options, two different good-faith implementations of that
  variety may not behave the same way), and still others
  essentially assuming that every URI behaves like an HTTP URL
  and that everything else is either invalid or deviant.  Some
  tests on web browsers appear to be consistent with the latter
  point of view and are being documented as normative by
  WHATWG.  To the extent to which the later is the actual
  working definition of "generic URI parser", they are never
  going to work well with URNs.

{3} I have heard a few people suggest that it actually is
  impossible, but I haven't seen such comments on the list or
  otherwise in public.  If it is not possible, it seems to me
  that two or three years of list discussion suggests that we
  are faced with a choice between abandoning all ideas of
  extending URNs beyond 2141 and going back to the "URNs are
  not URIs" model.

[4] There have also been some claims that the concept is
  meaningless or impossible in practice, but I'll leave that 
  discussion for other notes.


From nobody Fri Apr  3 16:47:22 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B10C1A871D for ; Fri,  3 Apr 2015 16:47:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.6
X-Spam-Level: 
X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQ-KKQdshWsv for ; Fri,  3 Apr 2015 16:47:17 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6564D1A87A2 for ; Fri,  3 Apr 2015 16:47:17 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 191AE20745 for ; Fri,  3 Apr 2015 19:47:13 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 03 Apr 2015 19:47:16 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=qwGlFmxzojDreh/ YqH4LYEaNQpo=; b=Ad1aQqrCnNDxnzsq3fSmmp2VqijBYcTB/0bKd/q8bcr5n8I n6ucLvjZyNVXvz58XmnomMyDHPLwn4NEt7vjnmEbLqaSMq2VZzX/IanRxxA+zb0q qk4zMi1MiAOafk7BzWGei97ZmKQUJt4w/tzl1N4B0CVmf4+U+hQr/Hg39QSg=
X-Sasl-enc: W8YWeGWUOFP9DEigKHtLoj6tJdsnirAVuca+xjOJ3uxC 1428104836
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 28E626800D3; Fri,  3 Apr 2015 19:47:16 -0400 (EDT)
Message-ID: <551F266E.4000507@network-heretics.com>
Date: Fri, 03 Apr 2015 19:46:54 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: urn@ietf.org
References: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com>
In-Reply-To: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Apr 2015 23:47:21 -0000

On 04/03/2015 03:49 PM, John C Klensin wrote:
> ABSTRACT /SUMMARY for this rather long note:
>
> p-components seem to a focus of controversy, possibly blocking
> other work and general progress in the WG.  This note tries to
> summarize and analyze the controversy, asks if p-components are
> important enough that we need to resolve that controversy, and
> proposes an alternative if they are not.
>
> Other other circumstances, I might just have written this note
> and proposal as an I-D, but it is really just an exploration,
> not a proposal.
>
> 
>
>
> Hi.
>
> Several comments in the last couple of weeks have raised issues
> with what are called p-components in 2141bis.  Most, but not
> all, of those notes have focused particularly on interactions
> with hierarchy and relative resolution.
>
> In the interest of getting done, I want to see if the WG can
> reexamine p-components rather than trying to dissect 3986 and
> its implications in this area.  This note will do some
> examination of 3986 interactions, but please bear with me.
>
> Assumption: I am taking the applicability of 3986 syntax but
> not semantics (as discussed in Andy's consensus call and
> draft-ietf-urnbis-semantics-clarif, although that document is
> still open to textual improvements) and the need to expand
> allowable URN syntax beyond those of RFC 2141 (and 3046) as
> given.  If there is anyone following the URN list who sees the
> discussions about hierarchy, relative resolution, or
> applicability of their interpretation of 3986 rules (with or
> without draft-ietf-appsawg-uri-scheme-reg) as a way to kill
> either 2141bis or URNs generally by a death of a thousand cuts,
> this note will probably not be helpful to them.
>
>
> THE ISSUES:
>
> Those who have spoken up about issues involving p-components
> (or the use of "/" in URNs) should check this to be sure I
> haven't mischaracterized their positions (and correct me if I
> have), but I believe the main concerns, as presented by others
> and with which I generally do not agree, are:
>
> (Issue 1): Despite the "no 3986 semantics" rule, we really
> cannot have a path or any use of a "/" in any URI, URNs
> included, without making that URI hierarchical.
mostly concur.

IMO, for any URN whose NSS contains a '/'  that is
(a) assigned to a resource that will never contain any path-relative 
references, AND
(b) will never be used as a Base URI in any other resource named by that 
namespace that contains path-relative references,
it is reasonably safe to ignore the "hierarchy" in that URN.

>   From that
> perspective, we can't say "URNs are not hierarchical", which
> 2141bis-11 does say [1], and allow "/".  Other than relative
> resolution issues, it is not clear whether this issue has any
> practical impact or is [just] an argument that the "not
> hierarchical" paragraph is self-contradictory and should be
> rewritten somehow.

also concur.   (Though all of the hierarchy issues of which I'm aware 
have to do with relative references.)

> (Issue 2): The generic URI parsers [2] will apply relative
> resolution processing if a "/" is seen, or perhaps even if it
> is not.  So such processing is inevitable, cannot be opted out
> of by URNs, and will cause serious damage to URNs if we try.
mostly concur.

An alternative approach might be to construct rules that require things 
that resolve URNs to resources containing path-relative references, to 
do so via an intermediate URL, and/or specify a Base URL in the 
resource, so that all path-relative references are evaluated relative to 
that URL.   But I suspect that it is much more difficult for the 
namespace than to impose a discipline on how its URNs are resolved, than 
to impose a discipline on the resources to which the namespace assigns 
NSSs that contain '/'.

> (Issue 3): Relative resolution is very important to some other
> URIs, current and permanent or planned.  If URNs impose
> restrictions on relative resolution operatons, even
> restrictions that apply only to URNs, it will be damaging to
> those other URIs.

At the very least, it will result in various inconsistencies in how 
relative references contained within a resource are evaluated, depending 
on whether the resource was accessed via a URN or URL. And it's easy to 
imagine how that inconsistency could become a tussle.  Relative URI 
references are seen as valuable because they continue to work properly 
even when a collection of resources is moved, copied, gets a new domain 
name, etc.   Breaking relative URI references for the sake of not 
permitting hierarchy in URNs seems shortsighted.

> (Issue 4): Because URNs are non-hierarchical and relative
> resolution would cause problems or meaningless results, URNs
> should not allow "/" unless the particular namespace actually
> is hierarchical and relative resolution is appropriate.

I would add "...or is inconsequential for the resource so named"  or 
some such (and define what that means).

> (Issue 5): It is not possible to decide that a URI scheme does
> not support relative resolution.  All URIs have to support such
> resolution.

concur.

> (Issue 6): Because it is not possible for a scheme to disallow
> relative resolution, URNs cannot make support for them a
> per-namespace issue either.

concur.   However namespaces MAY impose constraints on NSS assignment 
that make path-relative references a non-issue for them.

> PRELIMINARY ANALYSIS:
>
> There are some contradictions in the list above that don't
> make it easier to form a complete picture, much less figure out
> which arguments are valid or not.  Issues 1, 5, 6, and probably
> 4 are really about semantics so, unless it really is impossible
> to separate the actual syntax restrictions in 3986 from its
> semantic ones [3], their relevancy is questionable.
>
> The overall issue appears to be further complicated by an
> apparent (but not explicitly written down anywhere that I've
> found) principle for URIs, which is that meaningless
> constructions are ok.  So, as discussed in earlier notes in the
> context of fragments, if a URI is associated with a resource
> and a fragment is specified that makes no sense for the
> resource, whatever processor is dealing with the URI and/or the
> resource is free to just discard it rather than letting it
> interfere with other operations.  For the particular case of
> "/" and despite the restriction in 2141, nothing prevents
> someone from writing "urn:some-NID:some-NSS/garbage" today and
> using it in some URI context.  It would presumably be
> meaningless and different namespace-specific action routines
> would deal with it in different ways, but AFAICT, no one has
> shown evidence of horrible damage, whether to generic URI
> parsers, the nature of URNs, or otherwise.  Similarly, 3986
> makes it quite clear that false negatives are ok and so on.
>
> At ;east for some people, that principle (and the absence of
> general damage when it is applied) do not appear to apply where
> URNs are involved.  When we tried to propose a note in 2141bis
> that would have said, effectively,
>
>     "Relative resolution as described in RFC 3986 is likely to
>     be meaningless for URNs.  Parsers and processors that are
>     aware they are dealing with URIs with the
>     'urn:' scheme SHOULD NOT attempt to process relative
>     references.  However, if that processing is performed,
>     perhaps by a generic system that is not aware of particular
>     schemes, and results in meaningless results, the relevant
>     system should be prepared to just move on."
>
> For the particular case of the "urn:" scheme, we get
> repetitions of one or more of the issues about.

I don't think it's useful or desirable to break, or declare 
"meaningless", all use of path-relative references with all URNs. I 
think there will be a need to assign URNs to documents that contain 
path-relative references while still permitting those documents to be 
accessed via URLs, and those path-relative references need to work 
consistently no matter how the documents are accessed.

>
> I don't know what to do with the other issues, especially
> because of the difficulties with claims about generic URI
> parsers (see note [2] below).  So let's come back to the
> issue.
>
>
> WHY WOULD WE WANT A p-COMPONENT?
>
> URNs are very much tied up with the principle of "persistence"
> (or even "permanence".  Many of us believe we know,
> intuititively, what persistence of an identifier means, but we
> have been unsuccessful in proposing, much less agreeing on, a
> definition that is sufficiently precise to discriminate among
> boundary or edge cases [4].  For URNs (perhaps more so than
> URIs generally) careful and accurate matching and being clear
> about what compnents of the string are considered stable/
> persistent has seemed to be especially important.  Neither
> f-components (which those who want to think of them as 3986
> fragments believe are inherently bound to target objects and
> not the URI) and q-components (which, as Keith and others,
> including myself, have pointed out, raise questions of
> relationship between instructions to the URN processor and
> instructions to/about targets) are problematic from both
> persistence and comparison purposes.  2141bis has explicitly
> excluded both from equality comparisons for just those reasons.

Aside: as I've implied earlier, I'm not sure that merely excluding those 
components from equivalence comparisons is sufficient to make it clear 
which parts of the URN are persistent and which are not.     But maybe 
that's an uncontroversial change to the text.

Also f- and q-components can also be affected by relative URIs. And 
though this might not impair the affected URNs' persistence, relative 
URIs affecting f- and/or q-components can still result in inconsistent 
behavior depending on how a resource was accessed, and that 
inconsistency can also harm URLs.

>
> For those namespaces that need additional qualification (beyond
> the traditional NSS) that still participates in equality
> checking, that has so far left p-components as the only logical
> option.  Perhaps there is some other syntax that would do the
> job --a hypothetical X-component -- but, so far, no one has
> proposed one and the logic of 3986 is such that I think we can
> expect any such syntax proposal to produce cries of pain about
> generic URI parsers and related topics.
>
> If we have p-components anyway, there are also advantages to
> actual or potential namespaces that use the "/" character in
> their identifying strings.  Of course, we could simply declare
> the separation of NSS from p-components to be an artifact of
> 3986 semantics and solve the identifying string problem by
> allowing the "/" in the NSS, but doing so would not help with
> either the "generic URI parser" or relative resolution issue,
> nor would it help those who look at a "/" in something that
> appears to be a URI and see "hierarchy" (probably in large
> letters).
>
>
> A ROTTEN, BUT POSSIBLY DESIRABLE, CHOICE
>
> The theoretical argument for p-components is above.  I think we
> also need to remember that opening 2141 (and at least
> implicitly 3406) to allow additinoal syntax has been incredibly
> painful and that, after 2141bis is complete and approved,
> opening or revising it to allow yet more syntax is likely to be
> even more painful.  That may be a good argument for adding
> p-components now, even if doing so creates some pain, just to
> have it over with.
>
> However, the above theorizing aside, I have not seen any real
> demand for p-components on the mailing list.  If there is such
> demand, I hope that those who have current needs will come
> forward and explain them.  But, if there is not and
> p-components are likely to be a source of blocking
> controversies, another option would be to modify 2141bis to
> reserve the syntax but prohibit registration (and, to the
> extent we have the power, use) of URNs containing them until
> and unless future documents appear that address the issues.

I would prefer it if we can agree on some limitations on namespaces that 
use '/' in NSSs that will render path-relative references either useful 
or "mostly harmless" (depending on the particular discipline chose by 
that namespace).   As I stated above, I think we're going to want to be 
able to use URNs to refer to resources that contain path-relative 
references without breaking those references.   We should certainly be 
able to use URNs to name HTML documents, for instance.

(And I don't want the community to have to wait another 20 years or so 
before trying once again to sort this out.)

> Because I'm very concerned about the "death of a thousand cuts"
> mentioned above, I would hope that the WG would insist that
> anyone arguing for getting p-components out of the current
> disucssion by pushing them into the future would assure us that
> they would not turn around and raise other supposedly-blocking
> issues, but I recognize that there is ultimately no way to
> prevent that behavior other than by assurance of good faith.
>
> Were we to decide to push p-components aside, the WG should
> decide whether it would be desirable to have an informational
> appendix or separate informational document that records what
> we believe the issues are and why we reached the decisions we
> did as a starting point for future work.  This note might be a
> good starting point.  Had we had a supplmental document for
> 2141 that identified the issues and reasons additional syntax
> was deferred, it might have saved us a year or three in the
> current efforts (and/or had a restrictive impact on 3986).
> But, if we translated the controversies about the implications
> of p-components into difficulty getting consensus about such an
> explanation, perhaps it would just be better to bequeath the
> issues to the future.
>
> best,
>      john
>
>
>               -------------------------
>
> NOTES
>
> [1] draft-ietf-urnbis-rfc2141bis-urn-11, Section 5,
>    paragraph 2.
>
> (2] "Generic URI parsers" are problematic in another way that
>    should be kept in mind.  They have been invoked frequently in
>    these (URN) and other discussions about URIs, but it seems to
>    me that, each time someone tries to pin down exactly what
>    they do and how libraries compare, the answers are wildly
>    different, with some systems that are considered to be such
>    parsers by their authors or advocates doing little other than
>    separate the scheme name from the rest of the URI, others
>    trying very hard to interpret and implement every aspect of
>    3986 including its deep semantics (because 3986 includes many
>    options, two different good-faith implementations of that
>    variety may not behave the same way), and still others
>    essentially assuming that every URI behaves like an HTTP URL
>    and that everything else is either invalid or deviant.  Some
>    tests on web browsers appear to be consistent with the latter
>    point of view and are being documented as normative by
>    WHATWG.  To the extent to which the later is the actual
>    working definition of "generic URI parser", they are never
>    going to work well with URNs.
>
> {3} I have heard a few people suggest that it actually is
>    impossible, but I haven't seen such comments on the list or
>    otherwise in public.  If it is not possible, it seems to me
>    that two or three years of list discussion suggests that we
>    are faced with a choice between abandoning all ideas of
>    extending URNs beyond 2141 and going back to the "URNs are
>    not URIs" model.
>
> [4] There have also been some claims that the concept is
>    meaningless or impossible in practice, but I'll leave that
>    discussion for other notes.
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn


From nobody Sat Apr  4 10:36:56 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485741A00BE for ; Sat,  4 Apr 2015 10:36:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuzpW8VG3lhn for ; Sat,  4 Apr 2015 10:36:53 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0645.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::645]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A754A1A00A7 for ; Sat,  4 Apr 2015 10:36:52 -0700 (PDT)
Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1324.namprd02.prod.outlook.com (25.161.142.23) with Microsoft SMTP Server (TLS) id 15.1.118.21; Sat, 4 Apr 2015 17:36:31 +0000
Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0118.029; Sat, 4 Apr 2015 17:36:31 +0000
From: Larry Masinter 
To: Keith Moore , "urn@ietf.org" 
Thread-Topic: [urn] use of fragment identifiers: issues are same for urn and all urls
Thread-Index: AQHQbNU5QCJVzYbUqEWyvmZSFMzt6505D94AgAOc4QA=
Date: Sat, 4 Apr 2015 17:36:30 +0000
Message-ID: 
References: <4D184BB8-7E88-4284-9C5D-298E8C2753E3@adobe.com> <551CB6D4.4040801@network-heretics.com>
In-Reply-To: <551CB6D4.4040801@network-heretics.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/15.8.0.150303
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [50.184.24.49]
authentication-results: network-heretics.com; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1324;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(51704005)(87936001)(2656002)(99286002)(66066001)(102836002)(15975445007)(92566002)(36756003)(2900100001)(1720100001)(2950100001)(46102003)(83716003)(2501003)(122556002)(50986999)(54356999)(40100003)(76176999)(82746002)(107886001)(83506001)(86362001)(77156002)(62966003)(33656002)(106116001)(19580395003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1324; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR02MB1324; BCL:0; PCL:0; RULEID:;  SRVR:DM2PR02MB1324; 
x-forefront-prvs: 0536638EAC
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2015 17:36:30.9420 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1324
Archived-At: 
Subject: Re: [urn] use of fragment identifiers: issues are same for urn and all urls
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 04 Apr 2015 17:36:55 -0000

DQo+PiBUaGUgVVJMIGFuZCBVUk4NCj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2JjcDEx
NSAgIGFuZCB1cm46aWV0ZjpiY3A6MTE1DQo+Pg0KPj4gYXJlIGJvdGggbm90IGdvb2QgVVJJcyB0
byBwdXQgYSAjc2VjdGlvbi0zIGZyYWdtZW50IG9uLCBiZWNhdXNlIHdoZW4gYW4gdXBkYXRlIHRv
IEJDUCAxMTUgaXMgbWFkZSwgU2VjdGlvbiAzIG1pZ2h0IGJlIGEgdG90YWxseSBkaWZmZXJlbnQg
dG9waWMuDQo+Pg0KPj4NCj4+IFRoZSBVUkwgYW5kIFVSTg0KPj4gaHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL3JmYzQzOTUgIGFuZCB1cm46aWV0ZjpyZmM6NDM5NQ0KPj4NCj4+IHNob3VsZCBi
b3RoIGJlIGdvb2QgZm9yIGEgI3NlY3Rpb24tMyBmcmFnbWVudC4gVGhlIGxhdHRlciBiZWNhdXNl
IHRoZXJlIGlzIGEgY3JlZGlibGUgcG9saWN5IG9mIG5vdCBtZXNzaW5nIHdpdGggIFJGQ3Mgb25j
ZSB0aGV54oCZcmUgcHVibGlzaGVkLCBhbmQgc2VjdGlvbiBudW1iZXJzIHdpbGwgcmVtYWluIGV2
ZW4gaWYgUkZDcyBhcmUgcmVwdWJsaXNoZWQgaW4gZGlmZmVyZW50IGZvcm1hdHMuDQo+PiBJIHRo
aW5rIGJlaW5nIGNhcmVmdWwgaW4gdGhpcyBraW5kIG9mIGNvbW1pdG1lbnQgbmVlZHMgdG8gYmUg
cGFydCBvZiBuYW1lc3BhY2UgYXV0aG9yaXR5IHJlY29nbml0aW9uIHdoZW4gY29uc2lkZXJpbmcg
YXBwbGljYWJpbGl0eSBhbmQgbG9uZ2V2aXR5IG9mIGZyYWdtZW50IGlkZW50aWZpZXJzLg0KPg0K
PlRoZSBwcm9ibGVtIGlzLCBmb3Igc29tZSBwZXJpb2Qgb2YgdGltZToNCj5hKSBCb3RoIG9mIHRo
ZSBhYm92ZSBVUk5zIHJlZmVyIHRvIHRoZSBzYW1lIGRvY3VtZW50DQo+YikgQXQgbGVhc3Qgb25l
IHZlcnNpb24gb2YgdGhlIGRvY3VtZW50IG1heSBjb250YWluIGZyYWdtZW50cw0KPmMpIFRoZSBp
ZXRmIG5hbWVzcGFjZSBkb2Vzbid0IGNvbnRyb2wgd2hldGhlciBmcmFnbWVudHMgZ2V0IGFkZGVk
IHRvIGl0cyANCj5VUk5zIC4gQW55b25lIGNhbiBjb21wb3NlIGEgVVJJIGNvbnNpc3Rpbmcgb2Yg
dXJuOmlldGY6YmNwOjExNSBhbmQgYSANCj5mcmFnbWVudCBpZGVudGlmaWVyIGZyb20gcmZjIDQz
OTUsIGFuZCBpdCB3aWxsIHdvcmsgaW4gdGhlIG5lYXIgdGVybS4NCj4NCj5TbyBpZiBJRVRGIHdh
bnRzIHRvIG1ha2UgaXRzIChVUk4gKyBmcmFnbWVudCBpZGVudGlmaWVyKSBjb21iaW5hdGlvbnMg
DQo+cGVyc2lzdGVudCwgaXQgaGFzIHR3byBjaG9pY2VzOg0KPmEpIGRvbid0IGFzc2lnbiBCQ1Ag
VVJOcw0KPmIpIGRvbid0IHB1dCBmcmFnbWVudCBpZGVudGlmaWVycyBpbiBhbnkgdmVyc2lvbiBv
ZiBpdHMgZG9jdW1lbnRzDQo+DQoNCg0KdGhlcmXigJlzIGFub3RoZXIgY2hvaWNlOg0KDQpVUk4g
cmVzb2x1dGlvbiBvZiB1cm46aWV0ZjpiY3A6MzUgKEJDUCAxMTUgd2FzIGFzc2lnbmVkIGluIGVy
cm9yLCBSRkMgNDM5NSBpcyBib3RoIEJDUCAzNSBhbmQgMTE1KSBkb2VzbuKAmXQgaGF2ZSB0byBy
ZXNvbHZlIHRvIGEgZG9jdW1lbnQuIEl0IGNvdWxkIHJlc29sdmUgdG8gYSBsYW5kaW5nIHBhZ2Ug
d2l0aCBtZXRhZGF0YSwgd2hpY2ggaGFuZGxlZCBmcmFnbWVudHMgbGlrZSAjc2VjdGlvbi0zIHdp
dGggc2NyaXB0aW5nLiAgDQoNClVSTnMgYXJlIHVzZWZ1bCB3aXRob3V0IHJlc29sdXRpb24gb3Ig
bmV0d29yayBhY2Nlc3NpYmlsaXR5IG9mIHRoZSDigJxyZXNvdXJjZSIg4oCUIGl0IGxldHMgeW91
IGRlZmluZSBhIHByb3RvY29sIHNsb3Qgd2hpY2ggdGFrZXMgRUlUSEVSIGEgVVJMIG9yIFVSTi4g
Tm8gcmVzb2x1dGlvbiBwZXIgc2UgaXMgbmVlZGVkLiANCg0K


From nobody Sat Apr  4 11:42:52 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C05F1A020A for ; Sat,  4 Apr 2015 11:42:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufa73BsAq_1X for ; Sat,  4 Apr 2015 11:42:49 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0076.outbound.protection.outlook.com [65.55.169.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978B91A01EA for ; Sat,  4 Apr 2015 11:42:49 -0700 (PDT)
Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1323.namprd02.prod.outlook.com (25.161.142.22) with Microsoft SMTP Server (TLS) id 15.1.118.21; Sat, 4 Apr 2015 18:42:47 +0000
Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0118.029; Sat, 4 Apr 2015 18:42:47 +0000
From: Larry Masinter 
To: John C Klensin , Keith Moore , "urn@ietf.org" 
Thread-Topic: [urn] 3986 relationships - Fragment identifiers
Thread-Index: AQHQbwckvCpvK2yaIka/cVNE7Ke9TQ==
Date: Sat, 4 Apr 2015 18:42:46 +0000
Message-ID: <5E507C17-1F0B-42C6-9560-4632E2738EDB@adobe.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/15.8.0.150303
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [50.184.24.49]
authentication-results: jck.com; dkim=none (message not signed) header.d=none; 
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1323;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(15975445007)(102836002)(2501003)(62966003)(77156002)(36756003)(2900100001)(54356999)(50986999)(66066001)(33656002)(87936001)(2656002)(83506001)(82746002)(40100003)(46102003)(122556002)(83716003)(99286002)(107886001)(92566002)(106116001)(19580395003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1323; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR02MB1323; BCL:0; PCL:0; RULEID:;  SRVR:DM2PR02MB1323; 
x-forefront-prvs: 0536638EAC
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2015 18:42:46.9206 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1323
Archived-At: 
Subject: Re: [urn] 3986 relationships - Fragment identifiers
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 04 Apr 2015 18:42:51 -0000

UGxlYXNlIHJldmlldyBodHRwOi8vd3d3LnczLm9yZy9UUi9mcmFnaWQtYmVzdC1wcmFjdGljZXMv
DQrigJxCZXN0IFByYWN0aWNlcyBmb3IgRnJhZ21lbnQgSWRlbnRpZmllcnMgYW5kIE1lZGlhIFR5
cGUgRGVmaW5pdGlvbnPigJ0uDQoNCkl0IGdpdmVzIGFkdmljZSBiYXNlZCBvbiBhbiBhcmNoaXRl
Y3R1cmFsIHBlcnNwZWN0aXZlIG9mIGhvdyB0aGUgd2ViIHdvcmtzOyBpdCBzb3VuZHMgbGlrZSB5
b3UgdGhpbmsgdGhlIGFyY2hpdGVjdHVyZSBpcyDigJxicm9rZW4iLCBhbmQgbm90IGp1c3QgdGhl
IGRvY3VtZW50cyB0aGF0IGRlc2NyaWJlIGl0LiBUaGF04oCZcyBhIG1vcmUgc2VyaW91cyBkaXNj
b25uZWN0Lg0KDQoNCkxhcnJ5DQrigJQNCmh0dHA6Ly9sYXJyeS5tYXNpbnRlci5uZXQNCg0K


From nobody Sat Apr  4 16:16:39 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF841A01C6 for ; Sat,  4 Apr 2015 16:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwoDqiTkL8rP for ; Sat,  4 Apr 2015 16:16:37 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 132BA1A0217 for ; Sat,  4 Apr 2015 16:16:37 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9D552207A3 for ; Sat,  4 Apr 2015 19:16:32 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Sat, 04 Apr 2015 19:16:36 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=KKFvC19bUcIv4Fh U2PKceKL1tBo=; b=WpX/NFCSu+jd/lhpEzAH31GOVVsk7fPr6MVtVxEpc49/UM/ +iFhVJf4CbHfyOaHsXG2osXfwZsSwYRnuBzmw92ewormoRjFkvi/a+tW4CeU0ECh bK3KAVb+fOQsVFOz2B4YhwKYJthe2m6hMI4GrAFpCBELuoNVsJJP0yO/+iyU=
X-Sasl-enc: yCJTCoTqaS+S7PwzkYgxoipCwrrBKtYQ9Irj0gOi6hMn 1428189396
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id BB9BA6800BB; Sat,  4 Apr 2015 19:16:35 -0400 (EDT)
Message-ID: <552070BC.1010201@network-heretics.com>
Date: Sat, 04 Apr 2015 19:16:12 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Larry Masinter , John C Klensin ,  "urn@ietf.org" 
References: <5E507C17-1F0B-42C6-9560-4632E2738EDB@adobe.com>
In-Reply-To: <5E507C17-1F0B-42C6-9560-4632E2738EDB@adobe.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [urn] 3986 relationships - Fragment identifiers
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 04 Apr 2015 23:16:39 -0000

On 04/04/2015 02:42 PM, Larry Masinter wrote:
> Please review http://www.w3.org/TR/fragid-best-practices/
> “Best Practices for Fragment Identifiers and Media Type Definitions”.
>
> It gives advice based on an architectural perspective of how the web works; it sounds like you think the architecture is “broken", and not just the documents that describe it. That’s a more serious disconnect.

In a nutshell, what I think about fragments with respect to 
content-negotiation is this: if as a content developer you want to 
generate several equivalent versions of the same resource, and that 
resource has something analogous to fragments, and you can somehow 
arrange that the named fragments for each of those equivalent versions 
has the same content, you benefit from doing so because URIs containing 
fragment names will be meaningful even across HTTP-style 
content-negotiation.

However, there are lots of reasons why you might not be able to do that, 
or why you might not want to make the other compromises that that 
requires.  Some of these reasons are due to limitations in the ways that 
"fragments" are defined for one media type or another that might make 
them unsuitable for particular purposes.  Other reasons are due to the 
somewhat-arbitrary division, inherited from the HTML world, between 
portions of a file (fragments) and relationships between files that 
together comprise the same resource (paths).  One thing that I've 
noticed is that the same document is often mapped into files differently 
for HTML vs some other representation (say PDF) because of presumed 
differences in how each content-type is typically presented to users.

Ideally, URNs should not impose restrictions on what kinds of resources 
can be named, or restrictions on what kinds of resources should be able 
to be declared equivalent to one another for content-negotiation 
purposes, or restrictions on how a resource should be mapped into 
individual files.    We want URNs to be usable for a very long time - 
centuries even.   From this perspective, saddling URNs with conventions 
inherited from "the web" seems shortsighted.

Keith


From nobody Mon Apr  6 07:56:37 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7331A8946 for ; Mon,  6 Apr 2015 07:56:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.744
X-Spam-Level: *
X-Spam-Status: No, score=1.744 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwza7JyMF3sZ for ; Mon,  6 Apr 2015 07:56:34 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3BE61A8969 for ; Mon,  6 Apr 2015 07:56:30 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Yf8Rs-000Cgp-1S; Mon, 06 Apr 2015 10:56:24 -0400
Date: Mon, 06 Apr 2015 10:56:19 -0400
From: John C Klensin 
To: Larry Masinter 
Message-ID: 
In-Reply-To: <5E507C17-1F0B-42C6-9560-4632E2738EDB@adobe.com>
References: <5E507C17-1F0B-42C6-9560-4632E2738EDB@adobe.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Cc: urn@ietf.org, Keith Moore 
Subject: Re: [urn] 3986 relationships - Fragment identifiers
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Apr 2015 14:56:36 -0000

--On Saturday, April 04, 2015 18:42 +0000 Larry Masinter
 wrote:

> Please review http://www.w3.org/TR/fragid-best-practices/
> "Best Practices for Fragment Identifiers and Media Type
> Definitions".
> 
> It gives advice based on an architectural perspective of how
> the web works; it sounds like you think the architecture is
> "broken", and not just the documents that describe it.
> That's a more serious disconnect.

Larry, 

Two observations about that document.  The first is, in some
respects, just procedural but a symptom of one of the problems
we are having in carrying on a conversation about this subject.
The second is more fundamental.

(1) This is a "working draft" not anything resembling even an
approved, consensus, W3C recommendation.  As such, it has, as I
understand it, little more official status than an
Internet-Draft.  It is also not normatively referenced (or even
informatively referenced) by 3986, so I suggest that it is a
view of things the IETF has never accepted (or even, as far as I
can remember, formally reviewed).  It is also an October 2012
document, 7 1/2 years after 3986 (and the earliest version I can
find is 26 July that year).   I note too that RFC 7320, which is
at least later than 3986, doesn't reference it either.

While I think I understand the point you are trying to make
(which goes to (2) below), we are in a situation in which, at
the time publication was approved, 3986 was claimed to not
change or constrain either 2141 or URN evolution, and now we are
having serious disagreements that some of us are hearing as "you
can't do that in a URN because 3986 won't let you".  In that
context, your citing this document now as advice we should be
following is another, even more retroactive, version of the same
issue of finding a later statement and applying it.


(2) One of the problems we face in trying to evolve URNs to meet
the demonstrated needs of a broader community is that there is a
collection of people who believe that URNs, as a concept, are
unnecessary or even illegitimate.   It is very difficult to
discuss URN evolution with them (especially a subset of that
group) because, from their perspective, it would be better to
deprecate 2141 than to discuss additional syntax (whether
path-like, query-like, or fragment-like).  For the most extreme
members of that group, picking off these extensions (by any
means available) one at a time would yield a desirable outcome,
especially if it caused those who depend on even 2141-style URNs
or the kinds of URNs anticipated by RFC 1737 to lose interest in
URNs and move on.  With a few very prominent exceptions (at
least some of them in the W3C leadership), I no longer know who
those people are.  Some people may be in that group some days
and not on others.   I don't know if the recent thread on the
IETF list about getting rid of the "useless" urn "prefix" is
part of that movement or independent.   You have said enough
things on this general subject that seem contradictory from my
perspective that I don't know whether you are sliding in the
direction of that camp.

Even some of those who are more moderate, whose view might be
characterized as "I think URNs are useless for anything I'm
interested in, but am willing to tolerate them as long as they
don't interfere with anything I might be thinking about doing"
are a problem in this regard because their positions tend,
inevitably, to be be essentially negative turf-defending rather
than constructive suggestions as to how we can move forward
given the needs that have been expressed.

To further complicate things, there are people in the extended
community who take "persistence", and even "permanence"
sufficiently seriously that they see URNs as the only piece of
the URI puzzle that is important in the long term.  They see
most locators, especially those closely linked to access
protocols like HTTP, as inherently transitory (and more so if
linked to domain names for server hosts).  Members if that
community have even suggested, based on solid histories of
reasoning, history, and precedent, that most (or all) HTTP URLs
are not even properly called "identifiers".

I don't know how to get un-stuck from this situation, but I do
wish that we could, at least for the purpose of WG discussions,
assume the legitimacy of URNs and URNs with expanded
capabilities and then concentrate on perceived requirements
associated with URNs and exploration of ways to meet those
requirements, rather than moving off into essentially
philosophical debates about the meaning of URIs (or things that
are claimed to be identifiers more generally) and the "best
practices" models that result if one accepts one position  or
another in that philosophical debate as axiomatic.

best,
    john




From nobody Mon Apr  6 08:46:02 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DC51A8A60 for ; Mon,  6 Apr 2015 08:46:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.245
X-Spam-Level: *
X-Spam-Status: No, score=1.245 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta1gWQrXz7Bc for ; Mon,  6 Apr 2015 08:45:59 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582EC1A8A58 for ; Mon,  6 Apr 2015 08:45:59 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Yf9Dp-000CqT-Md; Mon, 06 Apr 2015 11:45:57 -0400
Date: Mon, 06 Apr 2015 11:45:52 -0400
From: John C Klensin 
To: Larry Masinter , URN@IETF.ORG
Message-ID: <77B3E485D5B40FC86350C7A5@JcK-HP8200.jck.com>
In-Reply-To: <4D184BB8-7E88-4284-9C5D-298E8C2753E3@adobe.com>
References: <4D184BB8-7E88-4284-9C5D-298E8C2753E3@adobe.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Subject: Re: [urn] use of fragment identifiers: issues are same for urn and all	urls
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Apr 2015 15:46:01 -0000

A few comments on this thread beyond those issues that Keith and
Martin have addressed...

--On Wednesday, April 01, 2015 23:40 +0000 Larry Masinter
 wrote:

> For a fragment identifier to be useful, there needs to be some
> promise. Using a fragment identifier with any URI (urn: or
> some other scheme) is done loosely best-effort; if you want a
> URI with fragment to work over time, you need the expectation
> that fragment identifiers won't change.
> 
> The URL and URN
> http://tools.ietf.org/html/bcp115  and urn:ietf:bcp:115
> 
> are both not good URIs to put a #section-3 fragment on,
> because when an update to BCP 115 is made, Section 3 might be
> a totally different topic.

A similar comment would apply to 

  http://www.w3.org/TR/fragid-best-practices/#Section-2

would it not?  The URL does not point t0 a single object, but to
a collection of versions, and there is no guarantee that another
version will have the same section numbering.   There is
therefore a case to be made that 

   http://www.w3.org/TR/fragid-best-practices/#Terminology

is better, but, while it is more likely to be stable across
versions than a section number, there are no guarantees about
that either.

And document names sometimes change.  For example, if some
future version of that document were renamed and at 
 
   http://www.w3.org/TR/fragment-best-practices/#Terminology

one could argue that the fragment ID is more stable than the
path.

One could also imagine

    urn:w3c:fragid-best-practices

but it wouldn't add much either substantively or semantically,
with or without a fragment identifier.   

>...
> I think being careful in this kind of commitment needs to be
> part of namespace authority recognition when considering
> applicability and longevity of fragment identifiers.

Sure, but that is where your "expectation" and Martin's "best
efforts" comments come in.  If, given the issues above one can
legitimately write

   http://www.w3.org/TR/fragid-best-practices/#Terminology
and/or
   http://www.w3.org/TR/fragid-best-practices/#Section-2

then it seems to me that it is impossible to claim that 
   http://www.w3.org/TR/fragid-best-practices/#Section-99

is a syntax error.  Whatever handles the object just has to be
prepared to cope with it, just as users need to understand that
the fragment identifiers might identify different material than
what they intended.

Now, if what you are looking for is a statement that, if a
namespace allows fragment (or f-component) with a URN, then the
namespace designers or registrants better be very clear about
what happens to it (and where it is evaluated) and that users
may need to be aware that bad specifications of fragments will
not yield predictable behavior even if the fragments are,
themselves, reasonably stable across whatever the URN might
refer to, I'd be happy with that.  Please send text.

But, if you are looking for guarantees of fragment reliability
or stability that are much stronger than the ones in the
examples above, I think we would have to go into an excursion
about the types of objects that URNs (that resolve to objects or
other identifiers) can point to.  That one is going to be hard
for multiple reasons, especially for network-based resources.
Even for the numbered RFC example, I note that the RFC Editor
had a struggle for years to prevent references to particular
pages in an RFC (rather than section numbers) and that I still
see such references floating around.

   best,
    john


From nobody Mon Apr  6 09:23:59 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CA31A8AFB for ; Mon,  6 Apr 2015 09:23:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.145
X-Spam-Level: 
X-Spam-Status: No, score=-0.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9lGYmUn60d8 for ; Mon,  6 Apr 2015 09:23:41 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581DA1A8912 for ; Mon,  6 Apr 2015 09:23:41 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CBE9C205B6 for ; Mon,  6 Apr 2015 12:23:36 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 06 Apr 2015 12:23:40 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=osAV5NN2f0Hw4e+ n4NCZOb8MGss=; b=azGS7VBmKopLTaB9eIkxk5b4aEQW0o2tSNTIYu9tHmwxthn XsDJN7Y6X0p2RHegF33mkRSXIHSo4nrrwfTeT7MREjLkqYi/H4Ik1uQV+MmtSQ2D 9lB9f9etpSkyk8yDlVRSnWprqf93F+CuKrc53NHNA35MUSRpwGRyg+2TLd/8=
X-Sasl-enc: uaZ042+pbAeVRKPIhf1/s3M5JF+lAv7wJ7Ot70PnNezc 1428337420
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 3A88C680201; Mon,  6 Apr 2015 12:23:40 -0400 (EDT)
Message-ID: <5522B2F0.5080103@network-heretics.com>
Date: Mon, 06 Apr 2015 12:23:12 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: urn@ietf.org
References: <4D184BB8-7E88-4284-9C5D-298E8C2753E3@adobe.com> <77B3E485D5B40FC86350C7A5@JcK-HP8200.jck.com>
In-Reply-To: <77B3E485D5B40FC86350C7A5@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] use of fragment identifiers: issues are same for urn and all	urls
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Apr 2015 16:23:43 -0000

I think we just need to declare whether URNs that contain f-components 
are persistent, or if only the "assigned" portion of the URN is 
persistent.   To me it does not look like an easy choice.  We'd like to 
be able to have reliable identifiers for portions of a resource, but 
expecting f-components to also be persistent places considerable 
restrictions on what URNs can be assigned to.

One way to look at the question is that since fragment IDs exist 
independent of URNs, and aren't expected to be persistent in ordinary 
use, insisting that the combination of URN and fragment ID be persistent 
is simply unreasonable.   But that's presuming that f-components map 
directly to fragment IDs.

A similar problem exists for paths, for similar reasons.   If in the 
middle of a document there's a link of the form
Terminology and a URN is assigned to that 
document, and we expect path-relative references to affect the URN, then 
the namespace or content-maintainer needs to make sure that that path 
always is associated with the Terminology section... something that 
content management systems might not be equipped to do.


On 04/06/2015 11:45 AM, John C Klensin wrote:
> A few comments on this thread beyond those issues that Keith and
> Martin have addressed...
>
> --On Wednesday, April 01, 2015 23:40 +0000 Larry Masinter
>  wrote:
>
>> For a fragment identifier to be useful, there needs to be some
>> promise. Using a fragment identifier with any URI (urn: or
>> some other scheme) is done loosely best-effort; if you want a
>> URI with fragment to work over time, you need the expectation
>> that fragment identifiers won't change.
>>
>> The URL and URN
>> http://tools.ietf.org/html/bcp115  and urn:ietf:bcp:115
>>
>> are both not good URIs to put a #section-3 fragment on,
>> because when an update to BCP 115 is made, Section 3 might be
>> a totally different topic.
> A similar comment would apply to
>
>    http://www.w3.org/TR/fragid-best-practices/#Section-2
>
> would it not?  The URL does not point t0 a single object, but to
> a collection of versions, and there is no guarantee that another
> version will have the same section numbering.   There is
> therefore a case to be made that
>
>     http://www.w3.org/TR/fragid-best-practices/#Terminology
>
> is better, but, while it is more likely to be stable across
> versions than a section number, there are no guarantees about
> that either.
>
> And document names sometimes change.  For example, if some
> future version of that document were renamed and at
>   
>     http://www.w3.org/TR/fragment-best-practices/#Terminology
>
> one could argue that the fragment ID is more stable than the
> path.
>
> One could also imagine
>
>      urn:w3c:fragid-best-practices
>
> but it wouldn't add much either substantively or semantically,
> with or without a fragment identifier.
>
>> ...
>> I think being careful in this kind of commitment needs to be
>> part of namespace authority recognition when considering
>> applicability and longevity of fragment identifiers.
> Sure, but that is where your "expectation" and Martin's "best
> efforts" comments come in.  If, given the issues above one can
> legitimately write
>
>     http://www.w3.org/TR/fragid-best-practices/#Terminology
> and/or
>     http://www.w3.org/TR/fragid-best-practices/#Section-2
>
> then it seems to me that it is impossible to claim that
>     http://www.w3.org/TR/fragid-best-practices/#Section-99
>
> is a syntax error.  Whatever handles the object just has to be
> prepared to cope with it, just as users need to understand that
> the fragment identifiers might identify different material than
> what they intended.
>
> Now, if what you are looking for is a statement that, if a
> namespace allows fragment (or f-component) with a URN, then the
> namespace designers or registrants better be very clear about
> what happens to it (and where it is evaluated) and that users
> may need to be aware that bad specifications of fragments will
> not yield predictable behavior even if the fragments are,
> themselves, reasonably stable across whatever the URN might
> refer to, I'd be happy with that.  Please send text.
>
> But, if you are looking for guarantees of fragment reliability
> or stability that are much stronger than the ones in the
> examples above, I think we would have to go into an excursion
> about the types of objects that URNs (that resolve to objects or
> other identifiers) can point to.  That one is going to be hard
> for multiple reasons, especially for network-based resources.
> Even for the numbered RFC example, I note that the RFC Editor
> had a struggle for years to prevent references to particular
> pages in an RFC (rather than section numbers) and that I still
> see such references floating around.
>
>     best,
>      john
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn


From nobody Tue Apr  7 14:29:14 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D761A9051 for ; Tue,  7 Apr 2015 14:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.078
X-Spam-Level: 
X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2k82hNzdvpN for ; Tue,  7 Apr 2015 14:29:11 -0700 (PDT)
Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18DC81A90BA for ; Tue,  7 Apr 2015 14:29:11 -0700 (PDT)
Received: by iedfl3 with SMTP id fl3so66407224ied.1 for ; Tue, 07 Apr 2015 14:29:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=FPWzzBQcIvqQ1Kwr+tuDPnySpiKFP/QwUzsrv2UuEg0=; b=GG3b5Dyd0sLE4seYYhl0HmwHRCLXDGVFPDSLt2DsVFQ5PFpE+G0o26lS6U9yBAVUCN yN3dahJwaX9yqRMO2bNMxMDCiO6VNHszJwxACqbt1KxDs8AX6ZOSpgMiPA2exJEiHcAq 6LtLXA/xxhi1BgTFmBgESlWzJF4PA+gS9r0jLpZ7uLW1l7fKoNx2slCoPauppi88AyJj GbaY+fFUeKhOPIkybwEXbAePXcmJCka3NGz6RqQMLAzedLE1v5iTJexslcRn/qar7j9R /uM9qHH7uAhXLCQXNuQdz6Nk8FheizUvubyr2sw63YmAs9QneBrDWQEgTDQLhUDMYzei 6Ieg==
X-Gm-Message-State: ALoCoQn99Wce+ozBArJg03AXgjj8OZqvDj1mkHG5OHWJ+M6BMbuzi77dSlMt4zx0kQO7d2yoIhx6
MIME-Version: 1.0
X-Received: by 10.50.111.115 with SMTP id ih19mr6890823igb.47.1428442150378; Tue, 07 Apr 2015 14:29:10 -0700 (PDT)
Received: by 10.36.38.205 with HTTP; Tue, 7 Apr 2015 14:29:10 -0700 (PDT)
X-Originating-IP: [192.149.252.11]
Date: Tue, 7 Apr 2015 17:29:10 -0400
Message-ID: 
From: Andrew Newton 
To: "urn@ietf.org" 
Content-Type: multipart/alternative; boundary=089e013d0df8f4b7df0513291a5c
Archived-At: 
Subject: [urn] Considerations for Relative Resolution of URNs
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 21:29:12 -0000

--089e013d0df8f4b7df0513291a5c
Content-Type: text/plain; charset=UTF-8

All,

There has been discussion on this list lately about p-components and
f-components. Some of those discussions center around the ability for
parsers to perform relative resolution on URNs. Past threads on this topic
have shown that relative resolution of other URI schemes can yield unusable
results and relative resolution of URNs can yield non-sensical answers.

Given that relative resolution of URNs is a thorn causing somewhat of a
limp to our forward progress, my inclination is to instruct the document
authors to pull it out. But first I'd like to hear from the group. If you
feel relative resolution of URNs is to remain a consideration, please tell
us why.

-andy, co-chair

--089e013d0df8f4b7df0513291a5c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


All,

There has been discussion on this =
list lately about p-components and f-components. Some of those discussions =
center around the ability for parsers to perform relative resolution on URN=
s. Past threads on this topic have shown that relative resolution of other =
URI schemes can yield unusable results and relative resolution of URNs can =
yield non-sensical answers.

Given that relative re=
solution of URNs is a thorn causing somewhat of a limp to our forward progr=
ess, my inclination is to instruct the document authors to pull it out. But=
 first I'd like to hear from the group. If you feel relative resolution=
 of URNs is to remain a consideration, please tell us why.

-andy, co-chair


--089e013d0df8f4b7df0513291a5c--


From nobody Tue Apr  7 14:41:05 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329E11A912F for ; Tue,  7 Apr 2015 14:41:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duEu0aZJAHmJ for ; Tue,  7 Apr 2015 14:41:02 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5463B1A9127 for ; Tue,  7 Apr 2015 14:41:02 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id D7F6820DF5 for ; Tue,  7 Apr 2015 17:40:56 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 07 Apr 2015 17:41:00 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=FxBsFvxjclSWulE Quxz78ND6xTk=; b=ZQkpqXqN+XxQfnyL/iez5jtJEwfl4nwbrw+CoSxKWcPW6dm z6xA+jR5pZDXK42V12kX/6XuYUOv5IR+Rjf9U1hEntoHc/WHzcXstDDNcV+G8osp nyiH4Nh1WdRKVKCiZQNqabz3aW6ETbic8keOauifo06N3+ElWlMbL9JPDj2Q=
X-Sasl-enc: b2h2OIo5/y7WXfpKTNlBJZzEj6AWa/07fFOqdLiQ+Xo5 1428442860
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 3FEC0C00013; Tue,  7 Apr 2015 17:41:00 -0400 (EDT)
Message-ID: <55244ECD.9010001@network-heretics.com>
Date: Tue, 07 Apr 2015 17:40:29 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: urn@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Considerations for Relative Resolution of URNs
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 21:41:04 -0000

On 04/07/2015 05:29 PM, Andrew Newton wrote:
> All,
>
> There has been discussion on this list lately about p-components and 
> f-components. Some of those discussions center around the ability for 
> parsers to perform relative resolution on URNs. Past threads on this 
> topic have shown that relative resolution of other URI schemes can 
> yield unusable results and relative resolution of URNs can yield 
> non-sensical answers.
>
> Given that relative resolution of URNs is a thorn causing somewhat of 
> a limp to our forward progress, my inclination is to instruct the 
> document authors to pull it out. But first I'd like to hear from the 
> group. If you feel relative resolution of URNs is to remain a 
> consideration, please tell us why.
>

Pulling this out looks like ignoring the problem, and I don't think 
ignoring the problem will help.   I suspect it introduces more "known 
technical omissions" that RFC 2026 forbids.

I haven't come to the point where I can make a proposal yet, but I have 
been looking into different options, e.g.:

a) Handle relative references with respect to URNs just as 3986 
specifies, and document the various
constraints on NSS assignment, path component persistence, etc., that 
this implies; or

b) Require that resolution of web content (i.e. content that uses 
3986-style URIs and relative references) be through an intermediate URI, 
(e.g. an http URL) which is treated as a base URI, and that all relative 
references are evaluated relative to that intermediate URI rather than 
the URN.    (This leaves URNs relatively unconstrained and avoids 
burdening them with "web baggage", but still leaves open the question of 
how {f,p,q}-components of a URN are interpreted.)

Keith


From nobody Tue Apr  7 20:41:27 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C7C1B2C8D for ; Tue,  7 Apr 2015 20:41:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.598
X-Spam-Level: *
X-Spam-Status: No, score=1.598 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXGml1VG80ln for ; Tue,  7 Apr 2015 20:41:21 -0700 (PDT)
Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B81151B2C8C for ; Tue,  7 Apr 2015 20:41:21 -0700 (PDT)
Received: by paboj16 with SMTP id oj16so100635521pab.0 for ; Tue, 07 Apr 2015 20:41:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4k8VNpx2Wk9hjR5Sp80p2ZVN2nxVusu3x9aFPeFyE6U=; b=ixtwC/36UMEwXXZwbZU56WZjvahrilI1/u1EVCYo73zGzbqVfrcZ+IEkQnLrpUPYMz 2kp8tJ0hV29y8Q9f/rSSLsgPhNNM2GQwmXg2rJuJXtmJhAVOeyycmAnefBVpCF19PoEW lCL62+cBR7QtnHKj2Rh1DCYQrUXgioDrMZkSqOuKVG9p420VjXuGe27leKPa2obRao/V V7kjp1RHYTG/VAZwb8jvf3SGxPYFbVWTj7pp8fXyKWSnS2YaD+qWD70kngxQlxU6623r Yb6fnbZYYDipFeTlO8Fc3oFL0Mx433nwtEs2zLYrsPajqgQtUYtDRgpw/80smNAh9Zfx RhbA==
X-Gm-Message-State: ALoCoQk7/YHcWUreDhOHRePxYsItkio0UcEnI1vh603pucyQMZgGq5bElPyzGIvZswwIHSs8/hE4
X-Received: by 10.70.90.16 with SMTP id bs16mr42247630pdb.76.1428464481375; Tue, 07 Apr 2015 20:41:21 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id jd5sm9368397pbd.35.2015.04.07.20.41.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2015 20:41:20 -0700 (PDT)
Message-ID: <5524A35E.4030100@andyet.net>
Date: Tue, 07 Apr 2015 21:41:18 -0600
From: Peter Saint-Andre - &yet 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Keith Moore ,  John C Klensin , urn@ietf.org
References: <55142CA1.2000509@network-heretics.com>  <5FE5D998-3ADD-4E17-BD48-64995A914153@network-heretics.com> <55143EEA.1060303@gmail.com> <5514433D.7010604@network-heretics.com>  <55172454.40502@network-heretics.com> <9176873CA947DB9D9175A34F@JcK-HP8200.jck.com> <551B0F54.4060601@network-heretics.com>
In-Reply-To: <551B0F54.4060601@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] General-purpose resolution service
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 03:41:23 -0000

On 3/31/15 3:19 PM, Keith Moore wrote:



> 3.   In the hopes of clarifying further discussion, I offer the
> following definitions and goals:
>
> a) A general-purpose URN resolution service is a service which can
> potentially be queried for information about any URN, independent of
> namespace.   Multiple, independent general-purpose URN resolution
> services can potentially coexist.   Such a service might or might not be
> able to return information about that particular URN - there's no
> requirement that the service has a complete database of all URNs.   Such
> a service might or might not be able to delegate that query to one or
> more other services, based on the URN's namespace ID and/or information
> within that URN's NSS, but there's no requirement that the service know
> how to delegate to a resolution service for every namespace or other
> subset of URN-space.
>
> b) A general-purpose URN resolution client is one that can consult one
> or more general-purpose URN resolution services in order to attempt to
> obtain desired information about a URN when applicable, such as its
> citation/catalog information, network locations, content of the
> resource, etc., and which is not inherently limited to use with URNs of
> specific namespaces.
>
> I claim that generic resolution services and generic clients are
> desirable and anticipated by the URN work.

I respectfully suggest that, if there were demand for generic URN 
resolution services and generic URN clients, a supply of such software 
would have emerged sometime in the last 20 years (RFC 1737 was published 
in late 1994). As far as I know, that supply has not been forthcoming. 
What rational basis do we have for thinking that the next 20+ years will 
be any different?

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

And yet that motivation turns out not to have been shared widely enough 
for people to produce running code. In the absence of running code, we 
are left with theories and hypotheses and opinions, not engineering.

> RFC 2141 impedes neither of the above services [*].

Despite the lack of impediments, no software has been produced. We might 
take that as a sign that the issue doesn't matter in practice.

> But 2141bis -10
> impedes both of them, if the interpretation of f-components,
> p-components, or q-components by either the service or the client needs
> to differ from one namespace to another.   Note that it should *not* be
> expected that the resolution service is specific to a particular
> namespace, as there will be a need for resolution services that handle
> URNs from a variety of namespaces.  (if not immediately, then
> eventually, as the authoritative services for some namespaces will
> inevitably disappear, and there will be a desire to provide lookup
> services for URNs in namespaces that never had authoritative services.)
>
> If, on the other hand, all namespaces delegate evaluation of these
> components to a resolution service, that solves the problem to some
> degree, but it then presents other problems: e.g. evaluation of relative
> URIs with respect to these URNs, the inability to address fragments in
> HTML documents named by URNs, the inability to send "queries" using the
> HTTP GET method to resources that accept them (at least using an
> ordinary HTML tag), some namespaces won't have resolution services (thus
> there's no way for a client to know how to interpret their components)
> and so on.
>
> [*] RFC 2141 section 7 does say that "Functional equivalence is
> determined by practice within a given namespace and managed by resolvers
> for that namespace."   It may be the case that only an authoritative
> resolution service for a particular namespace can reliably determine
> functional equivalence for two URNs from that namespace, but generic URN
> resolution services are useful in other ways even if they cannot
> reliably determine functional equivalence.   (Note also that two URNs
> can be functionally equivalent even if they are from different
> namespaces; there's no requirement that all URNs for a particular
> resource be from the same namespace.)

Here again, to state that "generic URN resolutions services are useful" 
is entirely chimerical. We might as well be asking biologists to tell us 
what is true of unicorns.

I'm not saying that the points you raise are not interesting or 
important, but I am saying that they don't seem to me to make any 
difference with respect to the engineering decisions before us.

However, as always, I freely admit that I might be missing something.

Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Tue Apr  7 21:53:43 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7251B349A for ; Tue,  7 Apr 2015 21:53:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.553
X-Spam-Level: 
X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ie4h-HI6Jh2 for ; Tue,  7 Apr 2015 21:53:38 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0069.outbound.protection.outlook.com [207.46.100.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C81FF1B3059 for ; Tue,  7 Apr 2015 21:53:38 -0700 (PDT)
Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1324.namprd02.prod.outlook.com (25.161.142.23) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 8 Apr 2015 04:53:36 +0000
Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0118.029; Wed, 8 Apr 2015 04:53:36 +0000
From: Larry Masinter 
To: John C Klensin 
Thread-Topic: [urn] 3986 relationships - Fragment identifiers
Thread-Index: AQHQbwckvCpvK2yaIka/cVNE7Ke9TZ1AFZ+AgAIG54A=
Date: Wed, 8 Apr 2015 04:53:35 +0000
Message-ID: <9CC60D30-731C-42DE-89A3-EC1CA47BA3E3@adobe.com>
References: <5E507C17-1F0B-42C6-9560-4632E2738EDB@adobe.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/15.8.0.150303
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [50.184.24.49]
authentication-results: jck.com; dkim=none (message not signed) header.d=none; 
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1324;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(479174004)(377454003)(62966003)(33656002)(40100003)(76176999)(110136001)(50986999)(86362001)(82746002)(83506001)(106116001)(19580395003)(16601075003)(19580405001)(83716003)(99286002)(77156002)(87936001)(2656002)(2900100001)(46102003)(66066001)(2950100001)(587094005)(15975445007)(122556002)(102836002)(54356999)(92566002)(36756003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1324; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR02MB1324; BCL:0; PCL:0; RULEID:;  SRVR:DM2PR02MB1324; 
x-forefront-prvs: 0540846A1D
Content-Type: text/plain; charset="utf-8"
Content-ID: <76CC86972278EB439D910DDD3800759F@namprd02.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 04:53:35.5956 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1324
Archived-At: 
Cc: "urn@ietf.org" , Keith Moore 
Subject: Re: [urn] 3986 relationships - Fragment identifiers
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 04:53:40 -0000

UHJvY2VkdXJhbDoNCg0KTGV04oCZcyB3b3JrIHRvZ2V0aGVyIHRvIG1ha2UgdGhlIGJlc3Qgc3Rh
bmRhcmRzIGZvciB0aGUgZW50aXJlDQpJbnRlcm5ldCBjb21tdW5pdHksIGFuZCB1c2UgcHJvY2Vz
cyBhcyBhIHdheSBvZiBhY2NvbXBsaXNoaW5nDQp0aGF0IHdpdGggc3VmZmljaWVudCByZXZpZXcg
dGhhdCB3ZeKAmXZlIGFjdHVhbGx5IGFjY29tcGxpc2hlZA0KdGhlIGdvYWwuIFllcywgaXTigJlz
IGJhZCB3aGVuIHBlb3BsZSBmb3JrIHdpdGhvdXQgcmVuYW1pbmcuDQpJRVRGIFVSTiB2cy4gSUZM
QSBVUk4gd291bGQgYmUgdWdseSwgbGlrZSB3aXRoIFVSTHMgdnMuIElSSXMNCmFuZCBKU09OIGFu
ZCBIVE1MNS4gTGV0cyBhdm9pZCBhIFVSTiBmb3JrLCBpZiB3ZSBjYW4uDQoNCg0KDQpPbiDigJxC
ZXN0IFByYWN0aWNlcyBmb3IgRnJhZ21lbnQgSWRlbnRpZmllcnPigJ06DQoNCkkgY2l0ZWQgaHR0
cDovL3d3dy53My5vcmcvVFIvZnJhZ2lkLWJlc3QtcHJhY3RpY2VzLw0KDQpiZWNhdXNlIEkgdGhv
dWdodCBpdCB3YXMgdGhvdWdodGZ1bCBhbmQgYSBnb29kIHJlYWQgYW5kIEkgd2FudGVkIHRvDQp1
c2Ugc29tZSBvZiBpdOKAmXMgaW5zaWdodHMgaW4gYSBjb252ZXJzYXRpb24gYWJvdXQgdGhlIHRl
Y2hub2xvZ3kNCnRoZSBVUk4gd29ya2luZyBncm91cCBpcyBjaGFydGVyZWQgdG8gcmVzcGVjaWZ5
Lg0KDQpJdHMgc3RhdHVzIHNob3VsZG7igJl0IG1hdHRlci4gSWYgeW91IHJlYWQgaXQgYW5kIHlv
dSBnZXQgbm8gDQppbnNpZ2h0cyBhcyB0byB3aHkgZi1jb21wb25lbnRzIGluIFVSTnMgbWlnaHQg
YmUgYSBiYWQNCmlkZWEsIEkgYXBvbG9naXplLCBhbmQgSeKAmWxsIHRyeSBoYXJkZXIgdG8gZXhw
bGFpbi4NCkJ1dCBJIHRoaW5rIGxldHRpbmcgZi1jb21wb25lbnRzIGJlIGRlZmluZWQgaW4gVVJO
DQpuYW1lc3BhY2VzIGlzIGEgYmFkIGlkZWEgZm9yIFVSTnMuIE5vdCBiZWNhdXNlIG9mDQphbnkg
cHJlY2VkZW50IG9yIG5vcm1hdGl2ZSByZXF1aXJlbWVudCwgb3IgYmVjYXVzZSANCm9mIHdoYXQg
Mzk4NiBzYXlzIG9yIG1lYW5zLCBidXQgYmVjYXVzZSBvZg0KZnJhZ21lbnQgaWRlbnRpZmllcnMg
YW5kIGhvdyB0aGV5IGRvIChvciBkb27igJl0KSANCmFjdHVhbGx5IHdvcmsuDQoNCkxhcnJ5DQri
gJQNCmh0dHA6Ly9sYXJyeS5tYXNpbnRlci5uZXQNCg0KDQoNCg0KDQoNCk9uIDQvNi8xNSwgNzo1
NiBBTSwgIkpvaG4gQyBLbGVuc2luIiA8am9obi1pZXRmQGpjay5jb20+IHdyb3RlOg0KDQo+DQo+
DQo+LS1PbiBTYXR1cmRheSwgQXByaWwgMDQsIDIwMTUgMTg6NDIgKzAwMDAgTGFycnkgTWFzaW50
ZXINCj48bWFzaW50ZXJAYWRvYmUuY29tPiB3cm90ZToNCj4NCj4+IFBsZWFzZSByZXZpZXcgaHR0
cDovL3d3dy53My5vcmcvVFIvZnJhZ2lkLWJlc3QtcHJhY3RpY2VzLw0KPj4gIkJlc3QgUHJhY3Rp
Y2VzIGZvciBGcmFnbWVudCBJZGVudGlmaWVycyBhbmQgTWVkaWEgVHlwZQ0KPj4gRGVmaW5pdGlv
bnMiLg0KPj4gDQo+PiBJdCBnaXZlcyBhZHZpY2UgYmFzZWQgb24gYW4gYXJjaGl0ZWN0dXJhbCBw
ZXJzcGVjdGl2ZSBvZiBob3cNCj4+IHRoZSB3ZWIgd29ya3M7IGl0IHNvdW5kcyBsaWtlIHlvdSB0
aGluayB0aGUgYXJjaGl0ZWN0dXJlIGlzDQo+PiAiYnJva2VuIiwgYW5kIG5vdCBqdXN0IHRoZSBk
b2N1bWVudHMgdGhhdCBkZXNjcmliZSBpdC4NCj4+IFRoYXQncyBhIG1vcmUgc2VyaW91cyBkaXNj
b25uZWN0Lg0KPg0KPkxhcnJ5LCANCj4NCj5Ud28gb2JzZXJ2YXRpb25zIGFib3V0IHRoYXQgZG9j
dW1lbnQuICBUaGUgZmlyc3QgaXMsIGluIHNvbWUNCj5yZXNwZWN0cywganVzdCBwcm9jZWR1cmFs
IGJ1dCBhIHN5bXB0b20gb2Ygb25lIG9mIHRoZSBwcm9ibGVtcw0KPndlIGFyZSBoYXZpbmcgaW4g
Y2Fycnlpbmcgb24gYSBjb252ZXJzYXRpb24gYWJvdXQgdGhpcyBzdWJqZWN0Lg0KPlRoZSBzZWNv
bmQgaXMgbW9yZSBmdW5kYW1lbnRhbC4NCj4NCj4oMSkgVGhpcyBpcyBhICJ3b3JraW5nIGRyYWZ0
IiBub3QgYW55dGhpbmcgcmVzZW1ibGluZyBldmVuIGFuDQo+YXBwcm92ZWQsIGNvbnNlbnN1cywg
VzNDIHJlY29tbWVuZGF0aW9uLiAgQXMgc3VjaCwgaXQgaGFzLCBhcyBJDQo+dW5kZXJzdGFuZCBp
dCwgbGl0dGxlIG1vcmUgb2ZmaWNpYWwgc3RhdHVzIHRoYW4gYW4NCj5JbnRlcm5ldC1EcmFmdC4g
IEl0IGlzIGFsc28gbm90IG5vcm1hdGl2ZWx5IHJlZmVyZW5jZWQgKG9yIGV2ZW4NCj5pbmZvcm1h
dGl2ZWx5IHJlZmVyZW5jZWQpIGJ5IDM5ODYsIHNvIEkgc3VnZ2VzdCB0aGF0IGl0IGlzIGENCj52
aWV3IG9mIHRoaW5ncyB0aGUgSUVURiBoYXMgbmV2ZXIgYWNjZXB0ZWQgKG9yIGV2ZW4sIGFzIGZh
ciBhcyBJDQo+Y2FuIHJlbWVtYmVyLCBmb3JtYWxseSByZXZpZXdlZCkuICBJdCBpcyBhbHNvIGFu
IE9jdG9iZXIgMjAxMg0KPmRvY3VtZW50LCA3IDEvMiB5ZWFycyBhZnRlciAzOTg2IChhbmQgdGhl
IGVhcmxpZXN0IHZlcnNpb24gSSBjYW4NCj5maW5kIGlzIDI2IEp1bHkgdGhhdCB5ZWFyKS4gICBJ
IG5vdGUgdG9vIHRoYXQgUkZDIDczMjAsIHdoaWNoIGlzDQo+YXQgbGVhc3QgbGF0ZXIgdGhhbiAz
OTg2LCBkb2Vzbid0IHJlZmVyZW5jZSBpdCBlaXRoZXIuDQo+DQo+V2hpbGUgSSB0aGluayBJIHVu
ZGVyc3RhbmQgdGhlIHBvaW50IHlvdSBhcmUgdHJ5aW5nIHRvIG1ha2UNCj4od2hpY2ggZ29lcyB0
byAoMikgYmVsb3cpLCB3ZSBhcmUgaW4gYSBzaXR1YXRpb24gaW4gd2hpY2gsIGF0DQo+dGhlIHRp
bWUgcHVibGljYXRpb24gd2FzIGFwcHJvdmVkLCAzOTg2IHdhcyBjbGFpbWVkIHRvIG5vdA0KPmNo
YW5nZSBvciBjb25zdHJhaW4gZWl0aGVyIDIxNDEgb3IgVVJOIGV2b2x1dGlvbiwgYW5kIG5vdyB3
ZSBhcmUNCj5oYXZpbmcgc2VyaW91cyBkaXNhZ3JlZW1lbnRzIHRoYXQgc29tZSBvZiB1cyBhcmUg
aGVhcmluZyBhcyAieW91DQo+Y2FuJ3QgZG8gdGhhdCBpbiBhIFVSTiBiZWNhdXNlIDM5ODYgd29u
J3QgbGV0IHlvdSIuICBJbiB0aGF0DQo+Y29udGV4dCwgeW91ciBjaXRpbmcgdGhpcyBkb2N1bWVu
dCBub3cgYXMgYWR2aWNlIHdlIHNob3VsZCBiZQ0KPmZvbGxvd2luZyBpcyBhbm90aGVyLCBldmVu
IG1vcmUgcmV0cm9hY3RpdmUsIHZlcnNpb24gb2YgdGhlIHNhbWUNCj5pc3N1ZSBvZiBmaW5kaW5n
IGEgbGF0ZXIgc3RhdGVtZW50IGFuZCBhcHBseWluZyBpdC4NCj4NCj4NCj4oMikgT25lIG9mIHRo
ZSBwcm9ibGVtcyB3ZSBmYWNlIGluIHRyeWluZyB0byBldm9sdmUgVVJOcyB0byBtZWV0DQo+dGhl
IGRlbW9uc3RyYXRlZCBuZWVkcyBvZiBhIGJyb2FkZXIgY29tbXVuaXR5IGlzIHRoYXQgdGhlcmUg
aXMgYQ0KPmNvbGxlY3Rpb24gb2YgcGVvcGxlIHdobyBiZWxpZXZlIHRoYXQgVVJOcywgYXMgYSBj
b25jZXB0LCBhcmUNCj51bm5lY2Vzc2FyeSBvciBldmVuIGlsbGVnaXRpbWF0ZS4gICBJdCBpcyB2
ZXJ5IGRpZmZpY3VsdCB0bw0KPmRpc2N1c3MgVVJOIGV2b2x1dGlvbiB3aXRoIHRoZW0gKGVzcGVj
aWFsbHkgYSBzdWJzZXQgb2YgdGhhdA0KPmdyb3VwKSBiZWNhdXNlLCBmcm9tIHRoZWlyIHBlcnNw
ZWN0aXZlLCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8NCj5kZXByZWNhdGUgMjE0MSB0aGFuIHRvIGRp
c2N1c3MgYWRkaXRpb25hbCBzeW50YXggKHdoZXRoZXINCj5wYXRoLWxpa2UsIHF1ZXJ5LWxpa2Us
IG9yIGZyYWdtZW50LWxpa2UpLiAgRm9yIHRoZSBtb3N0IGV4dHJlbWUNCj5tZW1iZXJzIG9mIHRo
YXQgZ3JvdXAsIHBpY2tpbmcgb2ZmIHRoZXNlIGV4dGVuc2lvbnMgKGJ5IGFueQ0KPm1lYW5zIGF2
YWlsYWJsZSkgb25lIGF0IGEgdGltZSB3b3VsZCB5aWVsZCBhIGRlc2lyYWJsZSBvdXRjb21lLA0K
PmVzcGVjaWFsbHkgaWYgaXQgY2F1c2VkIHRob3NlIHdobyBkZXBlbmQgb24gZXZlbiAyMTQxLXN0
eWxlIFVSTnMNCj5vciB0aGUga2luZHMgb2YgVVJOcyBhbnRpY2lwYXRlZCBieSBSRkMgMTczNyB0
byBsb3NlIGludGVyZXN0IGluDQo+VVJOcyBhbmQgbW92ZSBvbi4gIFdpdGggYSBmZXcgdmVyeSBw
cm9taW5lbnQgZXhjZXB0aW9ucyAoYXQNCj5sZWFzdCBzb21lIG9mIHRoZW0gaW4gdGhlIFczQyBs
ZWFkZXJzaGlwKSwgSSBubyBsb25nZXIga25vdyB3aG8NCj50aG9zZSBwZW9wbGUgYXJlLiAgU29t
ZSBwZW9wbGUgbWF5IGJlIGluIHRoYXQgZ3JvdXAgc29tZSBkYXlzDQo+YW5kIG5vdCBvbiBvdGhl
cnMuICAgSSBkb24ndCBrbm93IGlmIHRoZSByZWNlbnQgdGhyZWFkIG9uIHRoZQ0KPklFVEYgbGlz
dCBhYm91dCBnZXR0aW5nIHJpZCBvZiB0aGUgInVzZWxlc3MiIHVybiAicHJlZml4IiBpcw0KPnBh
cnQgb2YgdGhhdCBtb3ZlbWVudCBvciBpbmRlcGVuZGVudC4gICBZb3UgaGF2ZSBzYWlkIGVub3Vn
aA0KPnRoaW5ncyBvbiB0aGlzIGdlbmVyYWwgc3ViamVjdCB0aGF0IHNlZW0gY29udHJhZGljdG9y
eSBmcm9tIG15DQo+cGVyc3BlY3RpdmUgdGhhdCBJIGRvbid0IGtub3cgd2hldGhlciB5b3UgYXJl
IHNsaWRpbmcgaW4gdGhlDQo+ZGlyZWN0aW9uIG9mIHRoYXQgY2FtcC4NCj4NCj5FdmVuIHNvbWUg
b2YgdGhvc2Ugd2hvIGFyZSBtb3JlIG1vZGVyYXRlLCB3aG9zZSB2aWV3IG1pZ2h0IGJlDQo+Y2hh
cmFjdGVyaXplZCBhcyAiSSB0aGluayBVUk5zIGFyZSB1c2VsZXNzIGZvciBhbnl0aGluZyBJJ20N
Cj5pbnRlcmVzdGVkIGluLCBidXQgYW0gd2lsbGluZyB0byB0b2xlcmF0ZSB0aGVtIGFzIGxvbmcg
YXMgdGhleQ0KPmRvbid0IGludGVyZmVyZSB3aXRoIGFueXRoaW5nIEkgbWlnaHQgYmUgdGhpbmtp
bmcgYWJvdXQgZG9pbmciDQo+YXJlIGEgcHJvYmxlbSBpbiB0aGlzIHJlZ2FyZCBiZWNhdXNlIHRo
ZWlyIHBvc2l0aW9ucyB0ZW5kLA0KPmluZXZpdGFibHksIHRvIGJlIGJlIGVzc2VudGlhbGx5IG5l
Z2F0aXZlIHR1cmYtZGVmZW5kaW5nIHJhdGhlcg0KPnRoYW4gY29uc3RydWN0aXZlIHN1Z2dlc3Rp
b25zIGFzIHRvIGhvdyB3ZSBjYW4gbW92ZSBmb3J3YXJkDQo+Z2l2ZW4gdGhlIG5lZWRzIHRoYXQg
aGF2ZSBiZWVuIGV4cHJlc3NlZC4NCj4NCj5UbyBmdXJ0aGVyIGNvbXBsaWNhdGUgdGhpbmdzLCB0
aGVyZSBhcmUgcGVvcGxlIGluIHRoZSBleHRlbmRlZA0KPmNvbW11bml0eSB3aG8gdGFrZSAicGVy
c2lzdGVuY2UiLCBhbmQgZXZlbiAicGVybWFuZW5jZSINCj5zdWZmaWNpZW50bHkgc2VyaW91c2x5
IHRoYXQgdGhleSBzZWUgVVJOcyBhcyB0aGUgb25seSBwaWVjZSBvZg0KPnRoZSBVUkkgcHV6emxl
IHRoYXQgaXMgaW1wb3J0YW50IGluIHRoZSBsb25nIHRlcm0uICBUaGV5IHNlZQ0KPm1vc3QgbG9j
YXRvcnMsIGVzcGVjaWFsbHkgdGhvc2UgY2xvc2VseSBsaW5rZWQgdG8gYWNjZXNzDQo+cHJvdG9j
b2xzIGxpa2UgSFRUUCwgYXMgaW5oZXJlbnRseSB0cmFuc2l0b3J5IChhbmQgbW9yZSBzbyBpZg0K
PmxpbmtlZCB0byBkb21haW4gbmFtZXMgZm9yIHNlcnZlciBob3N0cykuICBNZW1iZXJzIGlmIHRo
YXQNCj5jb21tdW5pdHkgaGF2ZSBldmVuIHN1Z2dlc3RlZCwgYmFzZWQgb24gc29saWQgaGlzdG9y
aWVzIG9mDQo+cmVhc29uaW5nLCBoaXN0b3J5LCBhbmQgcHJlY2VkZW50LCB0aGF0IG1vc3QgKG9y
IGFsbCkgSFRUUCBVUkxzDQo+YXJlIG5vdCBldmVuIHByb3Blcmx5IGNhbGxlZCAiaWRlbnRpZmll
cnMiLg0KPg0KPkkgZG9uJ3Qga25vdyBob3cgdG8gZ2V0IHVuLXN0dWNrIGZyb20gdGhpcyBzaXR1
YXRpb24sIGJ1dCBJIGRvDQo+d2lzaCB0aGF0IHdlIGNvdWxkLCBhdCBsZWFzdCBmb3IgdGhlIHB1
cnBvc2Ugb2YgV0cgZGlzY3Vzc2lvbnMsDQo+YXNzdW1lIHRoZSBsZWdpdGltYWN5IG9mIFVSTnMg
YW5kIFVSTnMgd2l0aCBleHBhbmRlZA0KPmNhcGFiaWxpdGllcyBhbmQgdGhlbiBjb25jZW50cmF0
ZSBvbiBwZXJjZWl2ZWQgcmVxdWlyZW1lbnRzDQo+YXNzb2NpYXRlZCB3aXRoIFVSTnMgYW5kIGV4
cGxvcmF0aW9uIG9mIHdheXMgdG8gbWVldCB0aG9zZQ0KPnJlcXVpcmVtZW50cywgcmF0aGVyIHRo
YW4gbW92aW5nIG9mZiBpbnRvIGVzc2VudGlhbGx5DQo+cGhpbG9zb3BoaWNhbCBkZWJhdGVzIGFi
b3V0IHRoZSBtZWFuaW5nIG9mIFVSSXMgKG9yIHRoaW5ncyB0aGF0DQo+YXJlIGNsYWltZWQgdG8g
YmUgaWRlbnRpZmllcnMgbW9yZSBnZW5lcmFsbHkpIGFuZCB0aGUgImJlc3QNCj5wcmFjdGljZXMi
IG1vZGVscyB0aGF0IHJlc3VsdCBpZiBvbmUgYWNjZXB0cyBvbmUgcG9zaXRpb24gIG9yDQo+YW5v
dGhlciBpbiB0aGF0IHBoaWxvc29waGljYWwgZGViYXRlIGFzIGF4aW9tYXRpYy4NCj4NCj5iZXN0
LA0KPiAgICBqb2huDQo+DQo+DQo+DQo=


From nobody Tue Apr  7 22:22:49 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266F91B3D18 for ; Tue,  7 Apr 2015 22:22:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eB2xvCyUFk3e for ; Tue,  7 Apr 2015 22:22:46 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495D61B3D16 for ; Tue,  7 Apr 2015 22:22:46 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A6EDD20DC3 for ; Wed,  8 Apr 2015 01:22:41 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 08 Apr 2015 01:22:45 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=p1o3H0xq/4sg0Vn eYMKBhwN8G4A=; b=RxN3ozrs/bhULAK2Ly/hOxT0PwbTsqXIId0G7vIcBlXw77M Yf0f8r0ENJkrK/sgf/JlEGTZEzuA+duonHFC0vB9TPwYwvslOETgGRoYJTIa1iDf bczLqlK1u/DnKYJdlddGoHQausfBxh6+JHlDaLxsHvWiQP26VeLkhjrV7iuk=
X-Sasl-enc: 84gqMj8mvzzG5RuoostyV0J8AJkJey10WpHFMDTrXNkF 1428470565
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 10C45680125; Wed,  8 Apr 2015 01:22:45 -0400 (EDT)
Message-ID: <5524BB05.7020807@network-heretics.com>
Date: Wed, 08 Apr 2015 01:22:13 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Larry Masinter ,  John C Klensin 
References: <5E507C17-1F0B-42C6-9560-4632E2738EDB@adobe.com>  <9CC60D30-731C-42DE-89A3-EC1CA47BA3E3@adobe.com>
In-Reply-To: <9CC60D30-731C-42DE-89A3-EC1CA47BA3E3@adobe.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "urn@ietf.org" 
Subject: Re: [urn] 3986 relationships - Fragment identifiers
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 05:22:48 -0000

On 04/08/2015 12:53 AM, Larry Masinter wrote:
> Procedural:
>
> Let’s work together to make the best standards for the entire
> Internet community, and use process as a way of accomplishing
> that with sufficient review that we’ve actually accomplished
> the goal. Yes, it’s bad when people fork without renaming.
> IETF URN vs. IFLA URN would be ugly, like with URLs vs. IRIs
> and JSON and HTML5. Lets avoid a URN fork, if we can.
>
>
>
> On “Best Practices for Fragment Identifiers”:
>
> I cited http://www.w3.org/TR/fragid-best-practices/
>
> because I thought it was thoughtful and a good read and I wanted to
> use some of it’s insights in a conversation about the technology
> the URN working group is chartered to respecify.
>
> Its status shouldn’t matter. If you read it and you get no
> insights as to why f-components in URNs might be a bad
> idea, I apologize, and I’ll try harder to explain.
> But I think letting f-components be defined in URN
> namespaces is a bad idea for URNs. Not because of
> any precedent or normative requirement, or because
> of what 3986 says or means, but because of
> fragment identifiers and how they do (or don’t)
> actually work.
>
I can see how it would be useful to have a facility to allow reference 
to a "bookmark" or a "region" of a resource named by a URN.   But I 
think if we're going to have something akin to fragments associated with 
URNs, they probably shouldn't be the same fragments that are used with 
HTTP URLs or that appear in e.g. HTML documents.    The latter haven't 
been designed to be persistent, as they're too tied to notions of "file" 
or the granularity of whatever is returned in response to an HTTP GET.   
Instead, perhaps resources should be allowed to declare a mapping from 
URN "regions" to whatever markers are used internal to the resource.

Keith


From nobody Tue Apr  7 22:41:03 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F171B3D79 for ; Tue,  7 Apr 2015 22:41:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dK_P0QFmeHGW for ; Tue,  7 Apr 2015 22:41:00 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0671.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::671]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 318321B3D7A for ; Tue,  7 Apr 2015 22:41:00 -0700 (PDT)
Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 8 Apr 2015 05:40:40 +0000
Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0118.029; Wed, 8 Apr 2015 05:40:40 +0000
From: Larry Masinter 
To: John C Klensin , "URN@IETF.ORG" 
Thread-Topic: [urn] use of fragment identifiers: issues are same for urn and all urls
Thread-Index: AQHQcb6MRECJ0g7b0ke/7IKaYUz2pw==
Date: Wed, 8 Apr 2015 05:40:40 +0000
Message-ID: <084864CB-5775-42A4-9A35-E1957FB5A811@adobe.com>
References: <4D184BB8-7E88-4284-9C5D-298E8C2753E3@adobe.com> <77B3E485D5B40FC86350C7A5@JcK-HP8200.jck.com>
In-Reply-To: <77B3E485D5B40FC86350C7A5@JcK-HP8200.jck.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/15.8.0.150303
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [50.184.24.49]
authentication-results: jck.com; dkim=none (message not signed) header.d=none; 
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1322;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(106116001)(54356999)(82746002)(77156002)(76176999)(122556002)(2950100001)(62966003)(2900100001)(50986999)(102836002)(110136001)(83716003)(92566002)(83506001)(15975445007)(86362001)(33656002)(107886001)(40100003)(46102003)(2501003)(99286002)(66066001)(19580395003)(36756003)(87936001)(2656002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1322; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR02MB1322; BCL:0; PCL:0; RULEID:;  SRVR:DM2PR02MB1322; 
x-forefront-prvs: 0540846A1D
Content-Type: text/plain; charset="utf-8"
Content-ID: <197E5F2DD3F3464095589264ADCB77B0@namprd02.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 05:40:40.5543 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1322
Archived-At: 
Subject: Re: [urn] use of fragment identifiers: issues are same for urn and all urls
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 05:41:02 -0000

DQo+Tm93LCBpZiB3aGF0IHlvdSBhcmUgbG9va2luZyBmb3IgaXMgYSBzdGF0ZW1lbnQgdGhhdCwg
aWYgYQ0KPm5hbWVzcGFjZSBhbGxvd3MgZnJhZ21lbnQgKG9yIGYtY29tcG9uZW50KSB3aXRoIGEg
VVJOLCB0aGVuIHRoZQ0KPm5hbWVzcGFjZSBkZXNpZ25lcnMgb3IgcmVnaXN0cmFudHMgYmV0dGVy
IGJlIHZlcnkgY2xlYXIgYWJvdXQNCj53aGF0IGhhcHBlbnMgdG8gaXQgKGFuZCB3aGVyZSBpdCBp
cyBldmFsdWF0ZWQpIGFuZCB0aGF0IHVzZXJzDQo+bWF5IG5lZWQgdG8gYmUgYXdhcmUgdGhhdCBi
YWQgc3BlY2lmaWNhdGlvbnMgb2YgZnJhZ21lbnRzIHdpbGwNCj5ub3QgeWllbGQgcHJlZGljdGFi
bGUgYmVoYXZpb3IgZXZlbiBpZiB0aGUgZnJhZ21lbnRzIGFyZSwNCj50aGVtc2VsdmVzLCByZWFz
b25hYmx5IHN0YWJsZSBhY3Jvc3Mgd2hhdGV2ZXIgdGhlIFVSTiBtaWdodA0KPnJlZmVyIHRvLCBJ
J2QgYmUgaGFwcHkgd2l0aCB0aGF0LiAgUGxlYXNlIHNlbmQgdGV4dC4NCg0KDQo+QnV0LCBpZiB5
b3UgYXJlIGxvb2tpbmcgZm9yIGd1YXJhbnRlZXMgb2YgZnJhZ21lbnQgcmVsaWFiaWxpdHkNCj5v
ciBzdGFiaWxpdHkgdGhhdCBhcmUgbXVjaCBzdHJvbmdlciB0aGFuIHRoZSBvbmVzIGluIHRoZQ0K
PmV4YW1wbGVzIGFib3ZlLCBJIHRoaW5rIHdlIHdvdWxkIGhhdmUgdG8gZ28gaW50byBhbiBleGN1
cnNpb24NCj5hYm91dCB0aGUgdHlwZXMgb2Ygb2JqZWN0cyB0aGF0IFVSTnMgKHRoYXQgcmVzb2x2
ZSB0byBvYmplY3RzIG9yDQo+b3RoZXIgaWRlbnRpZmllcnMpIGNhbiBwb2ludCB0by4gIFRoYXQg
b25lIGlzIGdvaW5nIHRvIGJlIGhhcmQNCj5mb3IgbXVsdGlwbGUgcmVhc29ucywgZXNwZWNpYWxs
eSBmb3IgbmV0d29yay1iYXNlZCByZXNvdXJjZXMuDQo+RXZlbiBmb3IgdGhlIG51bWJlcmVkIFJG
QyBleGFtcGxlLCBJIG5vdGUgdGhhdCB0aGUgUkZDIEVkaXRvcg0KPmhhZCBhIHN0cnVnZ2xlIGZv
ciB5ZWFycyB0byBwcmV2ZW50IHJlZmVyZW5jZXMgdG8gcGFydGljdWxhcg0KPnBhZ2VzIGluIGFu
IFJGQyAocmF0aGVyIHRoYW4gc2VjdGlvbiBudW1iZXJzKSBhbmQgdGhhdCBJIHN0aWxsDQo+c2Vl
IHN1Y2ggcmVmZXJlbmNlcyBmbG9hdGluZyBhcm91bmQuDQoNCg0KDQpJIGRvbuKAmXQgdGhpbmsg
bmFtZXNwYWNlIGRlc2lnbmVycyBvciByZWdpc3RyYW50cyBDQU4gYmUNCuKAnGNsZWFyIiBhYm91
dCB3aGF0IGhhcHBlbnMgdG8gaXQgYW5kIHdoZXJlIGl0IGlzIGFwcGxpZWQNCijigJxldmFsdWF0
ZWTigJ0pIGJlY2F1c2UgdGhleSBoYXZlIGxpdHRsZSBjb250cm9sIG92ZXINCnRob3NlIHRoaW5n
cy4NCg0KSGVyZSBpcyBzb21lIHRleHQ6DQogICBOYW1lc3BhY2UgZGVzaWduZXJzIGFuZCByZWdp
c3RyYW50cyBtaWdodCBkZXNpcmUgdG8gZGVmaW5lDQogICBzeW50YXggYW5kIHNlbWFudGljcyBm
b3IgZi1jb21wb25lbnRzLCBob3dldmVyLCBpbiBwcmFjdGljZSwNCiAgIFVSSS9JUkkvVVJMIHBy
b2Nlc3NpbmcgdHlwaWNhbGx5IHNwbGl0cyB0aGUgZi1jb21wb25lbnQgb2ZmDQogICBiZWZvcmUg
ZXZlbiBsb29raW5nIGF0IHRoZSBzY2hlbWUsIGFuZCB0aGVuIG9ubHkgYXBwbHkNCiAgIGZyYWdt
ZW50IHByb2Nlc3NpbmcgYWZ0ZXIgdGhlIFVSTCBoYXMgYmVlbiByZXNvbHZlZCB0bw0KICAgdHlw
ZWQgY29udGVudC4gVGhlcmUgaXMgbm8gcGxhY2UgaW4gdGhlIGRhdGEgZmxvdyBmb3INCiAgIGEg
bmFtZXNwYWNlIGF1dGhvcml0eSB0byBpbnRlcmplY3QgYW55IHByb2Nlc3NpbmcgdG8NCiAgIGVu
c3VyZSBsb25nZXZpdHkgb2YgbWVhbmluZywgdG8gYWxsb3cgaW5kaXZpZHVhbCBVUk4NCiAgIG5h
bWVzcGFjZXMgdG8gaGF2ZSBhIG5hbWVzcGFjZS1zcGVjaWZpYyBpbnRlcnByZXRhdGlvbi4NCiAg
IEFueSBuYW1lc3BhY2UgZGVzaWduZXIgb3IgcmVnaXN0cmFudCBhdHRlbXB0aW5nIHRvIGRlZmlu
ZQ0KICAgZi1jb21wb25lbnQgaGFuZGxpbmcgZm9yIFVSTnMgb2YgdGhlaXIgbmFtZXNwYWNlIE1V
U1QgDQogICBzcGVjaWZ5IGluIEludGVyb3BlcmFiaWxpdHkgQ29uc2lkZXJhdGlvbnMgaG93IGFu
eQ0KICAgbmFtZXNwYWNlLXNwZWNpZmljIGJlaGF2aW9yIGlzIHRyaWdnZXJlZC4NCg0KDQpJ4oCZ
bSBzdXJlIHlvdSBjYW4gZG8gYmV0dGVyLCBidXQgcGVyaGFwcyB5b3UgZ2V0IHRoZSBnaXN0Lg0K
DQpMYXJyeQ0K4oCUDQpodHRwOi8vbGFycnkubWFzaW50ZXIubmV0DQoNCg==


From nobody Tue Apr  7 22:52:48 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523BC1A00C7 for ; Tue,  7 Apr 2015 22:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.4
X-Spam-Level: **
X-Spam-Status: No, score=2.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRvRlyNK-nYP for ; Tue,  7 Apr 2015 22:52:45 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885E51A00C3 for ; Tue,  7 Apr 2015 22:52:45 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id F0D2420DD1 for ; Wed,  8 Apr 2015 01:52:40 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Wed, 08 Apr 2015 01:52:44 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=WU9X7C1bYHcAYI0 1uHo10+L2e+0=; b=okJEfoPvICdAJxRtON0KdYKAF7dwx2wl0azt9MHzQ5mnLZ2 jhYA8kO7UWWd0ughEPCxluhzsQu7CWLKDRBspmiRG87a8T1kssDnarpcK4bCxcl4 PwXey3wAAULGn6xybTboNibWg7NIQMgtGtMwSsr+RPK9rD46vvVTRtuNIzOU=
X-Sasl-enc: U4VxSx8fhGveg8CahpS4H9lwcHKHj1/HTzaajfWm3D/o 1428472364
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 42F9A680085; Wed,  8 Apr 2015 01:52:44 -0400 (EDT)
Message-ID: <5524C20C.3090008@network-heretics.com>
Date: Wed, 08 Apr 2015 01:52:12 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Peter Saint-Andre - &yet ,  John C Klensin , urn@ietf.org
References: <55142CA1.2000509@network-heretics.com>  <5FE5D998-3ADD-4E17-BD48-64995A914153@network-heretics.com> <55143EEA.1060303@gmail.com> <5514433D.7010604@network-heretics.com>  <55172454.40502@network-heretics.com> <9176873CA947DB9D9175A34F@JcK-HP8200.jck.com> <551B0F54.4060601@network-heretics.com> <5524A35E.4030100@andyet.net>
In-Reply-To: <5524A35E.4030100@andyet.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] General-purpose resolution service
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 05:52:47 -0000

Peter,

URNs are intended to be usable for centuries.   We've only been defining 
them for around 20 years, and most of that usage has been within 
specific communities using specific namespaces.   It seems very 
premature to declare the concept of general-purpose resolution services 
useless, or unneeded, based on existing software deployments.  It seems 
especially shortsighted to extend URNs in such a way as to preclude such 
services, or impose substantial barriers to their being created.

I was perhaps the first person to produce a web browser that could deal 
with URNs, and certainly one of the first to write a URN resolution 
service (with multiple service locations), both circa 1994.  At the 
time, those were extremely challenging things to do.   I couldn't buy 
servers in racks with network service, certainly not at commodity 
prices.   Hardware was relatively expensive and had very modest 
capability compared to today. Networks were much slower then than now: a 
1.5Mb/s T1 line was considered good connectivity then.   I had to rely 
on the good graces of other friends in academia to host remote servers 
and didn't have any administrative control over them.   There were also 
substantial challenges with implementation.   I tried three or four 
indexed file libraries and never found one that didn't either corrupt 
its files or leak core.   IN 1994, I was lucky enough to have an open 
source browser in Mosaic that I could modify to support a URN user 
interface and back-end.   But once Netscape became the popular browser 
there was no good way to support URN resolution in the browser for many 
years.  And there was really no library support above the level of BSD 
sockets with which to implement network protocols.   etc., etc.

These days, browsers have hooks to support additional URI protocols.   
Good libraries exist for node, python and several other languages to 
provide all of the network access, parsing, database support, JSON 
formatting, etc. that you could possibly need.    You can put together a 
decent server in a few hours. Reliable real and virtual servers are 
available in minutes, at commodity prices, with good network 
connectivity and good management.    So is cloud storage.

Defining such a service might still take a bit of thought to get the 
definition (close to) right, and collecting enough data for a usable 
general-purpose service might be tricky (others might know about 
citation database availability).   Setting up a sustainable revenue 
stream to keep such services running indefinitely might also be 
tricky.   But at least implementation of either the resolution services 
or client libraries shouldn't be much of a barrier these days.

It seems to me, for instance, that every library should be able to have 
a general-purpose service to allow its holdings to be queried by URN, 
even though the names might not all be from the same namespace.   
Similarly for every online book seller and its offerings, and every 
publisher.   What does that seem too you at all bizarre or unrealistic, 
or anything other than obviously useful?

Keith

On 04/07/2015 11:41 PM, Peter Saint-Andre - &yet wrote:
> On 3/31/15 3:19 PM, Keith Moore wrote:
>
> 
>
>> 3.   In the hopes of clarifying further discussion, I offer the
>> following definitions and goals:
>>
>> a) A general-purpose URN resolution service is a service which can
>> potentially be queried for information about any URN, independent of
>> namespace.   Multiple, independent general-purpose URN resolution
>> services can potentially coexist.   Such a service might or might not be
>> able to return information about that particular URN - there's no
>> requirement that the service has a complete database of all URNs.   Such
>> a service might or might not be able to delegate that query to one or
>> more other services, based on the URN's namespace ID and/or information
>> within that URN's NSS, but there's no requirement that the service know
>> how to delegate to a resolution service for every namespace or other
>> subset of URN-space.
>>
>> b) A general-purpose URN resolution client is one that can consult one
>> or more general-purpose URN resolution services in order to attempt to
>> obtain desired information about a URN when applicable, such as its
>> citation/catalog information, network locations, content of the
>> resource, etc., and which is not inherently limited to use with URNs of
>> specific namespaces.
>>
>> I claim that generic resolution services and generic clients are
>> desirable and anticipated by the URN work.
>
> I respectfully suggest that, if there were demand for generic URN 
> resolution services and generic URN clients, a supply of such software 
> would have emerged sometime in the last 20 years (RFC 1737 was 
> published in late 1994). As far as I know, that supply has not been 
> forthcoming. What rational basis do we have for thinking that the next 
> 20+ years will be any different?
>
>> For example RFC 1727
>> section 5 states "It may also be the case that there are generic ones"
>> (i.e. resolvers or location services) "... providing service for many
>> resources of differing naming authorities".   Indeed, a principal
>> motivation for the URN work was to be able to resolve resource names in
>> a generic fashion, even across potential changes in access protocols or
>> lookup services.   (and this is precisely why we wouldn't have tried to
>> divide URNs up into schemes like "ddds:" or "indicator:" - we were
>> deliberately not taking that approach because doing so would harm URN
>> persistence.)
>
> And yet that motivation turns out not to have been shared widely 
> enough for people to produce running code. In the absence of running 
> code, we are left with theories and hypotheses and opinions, not 
> engineering.
>
>> RFC 2141 impedes neither of the above services [*].
>
> Despite the lack of impediments, no software has been produced. We 
> might take that as a sign that the issue doesn't matter in practice.
>
>> But 2141bis -10
>> impedes both of them, if the interpretation of f-components,
>> p-components, or q-components by either the service or the client needs
>> to differ from one namespace to another.   Note that it should *not* be
>> expected that the resolution service is specific to a particular
>> namespace, as there will be a need for resolution services that handle
>> URNs from a variety of namespaces.  (if not immediately, then
>> eventually, as the authoritative services for some namespaces will
>> inevitably disappear, and there will be a desire to provide lookup
>> services for URNs in namespaces that never had authoritative services.)
>>
>> If, on the other hand, all namespaces delegate evaluation of these
>> components to a resolution service, that solves the problem to some
>> degree, but it then presents other problems: e.g. evaluation of relative
>> URIs with respect to these URNs, the inability to address fragments in
>> HTML documents named by URNs, the inability to send "queries" using the
>> HTTP GET method to resources that accept them (at least using an
>> ordinary HTML tag), some namespaces won't have resolution services (thus
>> there's no way for a client to know how to interpret their components)
>> and so on.
>>
>> [*] RFC 2141 section 7 does say that "Functional equivalence is
>> determined by practice within a given namespace and managed by resolvers
>> for that namespace."   It may be the case that only an authoritative
>> resolution service for a particular namespace can reliably determine
>> functional equivalence for two URNs from that namespace, but generic URN
>> resolution services are useful in other ways even if they cannot
>> reliably determine functional equivalence.   (Note also that two URNs
>> can be functionally equivalent even if they are from different
>> namespaces; there's no requirement that all URNs for a particular
>> resource be from the same namespace.)
>
> Here again, to state that "generic URN resolutions services are 
> useful" is entirely chimerical. We might as well be asking biologists 
> to tell us what is true of unicorns.
>
> I'm not saying that the points you raise are not interesting or 
> important, but I am saying that they don't seem to me to make any 
> difference with respect to the engineering decisions before us.
>
> However, as always, I freely admit that I might be missing something.
>
> Peter
>


From nobody Wed Apr  8 09:19:31 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E9B1B33C8 for ; Wed,  8 Apr 2015 09:19:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-8AYUBu1D1J for ; Wed,  8 Apr 2015 09:19:28 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4645B1B33AD for ; Wed,  8 Apr 2015 09:19:22 -0700 (PDT)
Received: by wgbdm7 with SMTP id dm7so93787796wgb.1 for ; Wed, 08 Apr 2015 09:19:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kWdXYmxp8SKxMaPnYigLdD5iZjdKeYJ/MrnXSIDKk0U=; b=XqPG997udkR4IfLQ8lwnyzLdfaGRqq47c8iLRgIZnnZXIRk5IOGviLpPDdd16gTlKY aeMmF3tOL4B/pGhtlD7fX2D4BBUWBg2slmv4nIFxNK/1SFh8krfTJiE4IEuF1Vqu7S7w V0s3kwXlMaqtq2Qr0RFpCOp0dORxIKcBLx0O/+r78uzKQvK3O3XmItsHUEwm4OgRzpBu HMr2NfiGK87MFqO66jkXF37XiG9RNLFC0yPEk1UyLd2d7aJqnqLd/rD/ZyZTXjLataiP xuiCDTyomoa3dD/BqB3+3SxRCtvXGT88Mj15q0wpPYipf2qKMpNJXE1Hy/uBlxSafQEE n5WQ==
X-Gm-Message-State: ALoCoQmWy5dk9XKJijRBO8xCN0rT0sDzbBRDTOLpyq6+kvazVJQhsdaKcHx/xUAB6M1LBOhjJBdC
MIME-Version: 1.0
X-Received: by 10.180.78.135 with SMTP id b7mr15539460wix.65.1428509961006; Wed, 08 Apr 2015 09:19:21 -0700 (PDT)
Received: by 10.195.18.66 with HTTP; Wed, 8 Apr 2015 09:19:20 -0700 (PDT)
X-Originating-IP: [192.149.252.11]
In-Reply-To: <55244ECD.9010001@network-heretics.com>
References:  <55244ECD.9010001@network-heretics.com>
Date: Wed, 8 Apr 2015 12:19:20 -0400
Message-ID: 
From: Andrew Newton 
To: Keith Moore 
Content-Type: multipart/alternative; boundary=90e6ba475eebc8c543051338e413
Archived-At: 
Cc: "urn@ietf.org" 
Subject: Re: [urn] Considerations for Relative Resolution of URNs
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 16:19:30 -0000

--90e6ba475eebc8c543051338e413
Content-Type: text/plain; charset=UTF-8

On Tue, Apr 7, 2015 at 5:40 PM, Keith Moore 
wrote:

>
> Pulling this out looks like ignoring the problem, and I don't think
> ignoring the problem will help.   I suspect it introduces more "known
> technical omissions" that RFC 2026 forbids.
>

This would not be an omission. It would be a deliberate re-evaluation of
design criteria.


> I haven't come to the point where I can make a proposal yet, but I have
> been looking into different options, e.g.:
>
> a) Handle relative references with respect to URNs just as 3986 specifies,
> and document the various
> constraints on NSS assignment, path component persistence, etc., that this
> implies; or
>

If I understand you correctly, this would require us to define relative
resolution of fragments, queries, and paths against all URNs. That is one
option.

I suppose another option is allow each namespace to define relative
resolution.

Either case is better than what we have today, which is a completely
undefined process.


> b) Require that resolution of web content (i.e. content that uses
> 3986-style URIs and relative references) be through an intermediate URI,
> (e.g. an http URL) which is treated as a base URI, and that all relative
> references are evaluated relative to that intermediate URI rather than the
> URN.    (This leaves URNs relatively unconstrained and avoids burdening
> them with "web baggage", but still leaves open the question of how
> {f,p,q}-components of a URN are interpreted.)
>

An example would be helpful. However, this appears to mean that URN
relative resolution is dependent on the implied URI scheme of the relative
reference or is application context specific.

If we can come to some agreement on how to deal with relative resolution,
that would be good. However, allowing the topic to continue to cause
conflicts is not acceptable.

-andy

--90e6ba475eebc8c543051338e413
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, Apr 7, 2015 at 5:40 PM, Keith Moore <moore@network-he=
retics.com> wrote:


Pulling this out looks like ignoring the problem, and I don't think ign=
oring the problem will help.=C2=A0 =C2=A0I suspect it introduces more "=
;known technical omissions" that RFC 2026 forbids.

This would not be an omission. It would be a deliberate re=
-evaluation of design criteria.=C2=A0
=C2=A0

I haven't come to the point where I can make a proposal yet, but I have=
 been looking into different options, e.g.:



a) Handle relative references with respect to URNs just as 3986 specifies, =
and document the various

constraints on NSS assignment, path component persistence, etc., that this =
implies; or

If I understand you correct=
ly, this would require us to define relative resolution of fragments, queri=
es, and paths against all URNs. That is one option.

I suppose another option is allow each namespace to define relative resol=
ution.

Either case is better than what we have tod=
ay, which is a completely undefined process.=C2=A0
=C2=A0

b) Require that resolution of web content (i.e. content that uses 3986-styl=
e URIs and relative references) be through an intermediate URI, (e.g. an ht=
tp URL) which is treated as a base URI, and that all relative references ar=
e evaluated relative to that intermediate URI rather than the URN.=C2=A0 =
=C2=A0 (This leaves URNs relatively unconstrained and avoids burdening them=
 with "web baggage", but still leaves open the question of how {f=
,p,q}-components of a URN are interpreted.)

=

An example would be helpful. However, this appears to mean that URN re=
lative resolution is dependent on the implied URI scheme of the relative re=
ference or is application context specific.

If we =
can come to some agreement on how to deal with relative resolution, that wo=
uld be good. However, allowing the topic to continue to cause conflicts is =
not acceptable.

-andy


--90e6ba475eebc8c543051338e413--


From nobody Wed Apr  8 09:31:25 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95851B33E1 for ; Wed,  8 Apr 2015 09:31:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhx-nGDXUsHA for ; Wed,  8 Apr 2015 09:31:22 -0700 (PDT)
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 622461B33E8 for ; Wed,  8 Apr 2015 09:30:59 -0700 (PDT)
Received: by wgbdm7 with SMTP id dm7so94118765wgb.1 for ; Wed, 08 Apr 2015 09:30:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GRaX0co9iLejlu4VdwQoFPUhqjtSvY9pUvDY4dIs3VI=; b=Jyqkv1e4y6lYAcczfJVAYIqaNati3RfX9jSOWCeR0hTwBtOlEczG8G39fC1C/MgwyR W3tm28XAZrEsc3edR2KuFT5+0e3K47gycb9pqltGWQfd2vGTdDg7qfNFREGbs+rMjgCm K8SctBvI6pGAAxWt7Y7uMqCFIL1lcgtPAbqgq0slusv7DoI7K6iK0/lvtQM7uGYANz6C 3qysUjQm0IuV8T+71h/jjFbxeE3jO4Vfdy/2WJ6iYakRrWEMg2EYTgj1pTBRTfrCLT0I Mds8u7kb21q/oTXV61SweSvTqziqTlN17auiGnbq9T68wre+xL+krEuYdI4Yxlt7/x4B y18A==
X-Gm-Message-State: ALoCoQm1Rbcp7oFkp6ZuqzaoXrdXCS9seYrvZ+mXDRaXzJtP5AycvzO+xY1Pza4S1juMHrxfLtfo
MIME-Version: 1.0
X-Received: by 10.180.10.102 with SMTP id h6mr15292523wib.37.1428510658017; Wed, 08 Apr 2015 09:30:58 -0700 (PDT)
Received: by 10.195.18.66 with HTTP; Wed, 8 Apr 2015 09:30:57 -0700 (PDT)
X-Originating-IP: [192.149.252.11]
In-Reply-To: <5524C20C.3090008@network-heretics.com>
References: <55142CA1.2000509@network-heretics.com>  <5FE5D998-3ADD-4E17-BD48-64995A914153@network-heretics.com> <55143EEA.1060303@gmail.com> <5514433D.7010604@network-heretics.com>  <55172454.40502@network-heretics.com> <9176873CA947DB9D9175A34F@JcK-HP8200.jck.com> <551B0F54.4060601@network-heretics.com> <5524A35E.4030100@andyet.net> <5524C20C.3090008@network-heretics.com>
Date: Wed, 8 Apr 2015 12:30:57 -0400
Message-ID: 
From: Andrew Newton 
To: Keith Moore 
Content-Type: multipart/alternative; boundary=001a11c2597c544fef0513390e4e
Archived-At: 
Cc: "urn@ietf.org" , Peter Saint-Andre - &yet 
Subject: Re: [urn] General-purpose resolution service
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 16:31:23 -0000

--001a11c2597c544fef0513390e4e
Content-Type: text/plain; charset=UTF-8

Asking about keeping a generic URN parser as design criteria was next up on
my list, but I suppose Peter beat me to it. :)

On Wed, Apr 8, 2015 at 1:52 AM, Keith Moore 
wrote:

>
> These days, browsers have hooks to support additional URI protocols.
>  Good libraries exist for node, python and several other languages to
> provide all of the network access, parsing, database support, JSON
> formatting, etc. that you could possibly need.    You can put together a
> decent server in a few hours. Reliable real and virtual servers are
> available in minutes, at commodity prices, with good network connectivity
> and good management.    So is cloud storage.
>

While such resources were not easily obtainable 20 years ago, they were 10
years ago. In that timeframe we have not seen generic URN services or
applications.

We need to allow uses of URNs from large URN-using communities as has been
requested vs. the desire for implementations that have had 20 years to
materialize but have not. While no person can predict the future, I would
guess the broader IETF community would favor changes to meet modern issues
over unrealized design criteria from 20 years ago.

-andy

--001a11c2597c544fef0513390e4e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Asking about keeping a generic URN parser as design criter=
ia was next up on my list, but I suppose Peter beat me to it. :)

On Wed, Apr 8, 2015 at 1=
:52 AM, Keith Moore <moore@network-heretics.com> wr=
ote:


These days, browsers have hooks to support additional URI protocols.=C2=A0 =
=C2=A0Good libraries exist for node, python and several other languages to =
provide all of the network access, parsing, database support, JSON formatti=
ng, etc. that you could possibly need.=C2=A0 =C2=A0 You can put together a =
decent server in a few hours. Reliable real and virtual servers are availab=
le in minutes, at commodity prices, with good network connectivity and good=
 management.=C2=A0 =C2=A0 So is cloud storage.

While such resources were not easily obtainable 20 years ago, they =
were 10 years ago. In that timeframe we have not seen generic URN services =
or applications.

We need to allow uses of URNs fro=
m large URN-using communities as has been requested vs. the desire for impl=
ementations that have had 20 years to materialize but have not. While no pe=
rson can predict the future, I would guess the broader IETF community would=
 favor changes to meet modern issues over unrealized design criteria from 2=
0 years ago.

-andy


--001a11c2597c544fef0513390e4e--


From nobody Wed Apr  8 09:36:06 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5F91B3398 for ; Wed,  8 Apr 2015 09:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jNG0pzKMDw9 for ; Wed,  8 Apr 2015 09:36:02 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61B71B2AFD for ; Wed,  8 Apr 2015 09:36:02 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 112F3209C3 for ; Wed,  8 Apr 2015 12:35:58 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 08 Apr 2015 12:36:02 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=CfIlvJ8pfruA+Kt2f4WXWK2zgSM=; b=hctaI 0bxZkt3Uaz0yMI6jnMEBf+ap+t2k3jOwS8DXtuItGS025gFwbepzAT4MlEBIFvrw ylFCxsvr0Ec907iLSSuFC94vzV1GtNDhF0lF3WzBxPTfu+lLz5E1NEOiqMaZ+U4E 6GszESGOY8WdKCY05SsW3Tf35AZr5dlLOXsMts=
X-Sasl-enc: B1Dk9g3341GoTIXr1kRslp1RhnUVr/qNI1A5f/Kk3ZGO 1428510961
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 82DF4C00017; Wed,  8 Apr 2015 12:36:01 -0400 (EDT)
Message-ID: <552558CF.3030006@network-heretics.com>
Date: Wed, 08 Apr 2015 12:35:27 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Andrew Newton 
References: 	<55244ECD.9010001@network-heretics.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030506010508000901050309"
Archived-At: 
Cc: "urn@ietf.org" 
Subject: Re: [urn] Considerations for Relative Resolution of URNs
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 16:36:05 -0000

This is a multi-part message in MIME format.
--------------030506010508000901050309
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 04/08/2015 12:19 PM, Andrew Newton wrote:
>
>
> On Tue, Apr 7, 2015 at 5:40 PM, Keith Moore 
> > wrote:
>
>
>     Pulling this out looks like ignoring the problem, and I don't
>     think ignoring the problem will help.   I suspect it introduces
>     more "known technical omissions" that RFC 2026 forbids.
>
>
> This would not be an omission. It would be a deliberate re-evaluation 
> of design criteria.

I disagree.   Again, I don't think this group is chartered to redefine URNs.

>     I haven't come to the point where I can make a proposal yet, but I
>     have been looking into different options, e.g.:
>
>     a) Handle relative references with respect to URNs just as 3986
>     specifies, and document the various
>     constraints on NSS assignment, path component persistence, etc.,
>     that this implies; or
>
>
> If I understand you correctly, this would require us to define 
> relative resolution of fragments, queries, and paths against all URNs. 
> That is one option.

Right.   Of course, 3986 already do this, and it defines relative 
references to URIs purely as a matter of syntax, so the "only syntax" 
choice already leads down this path.   If a URN is permitted to be a 
base URI, and URNs are parsed according to 3986, we effectively have 
relative resolution of fragments, queries, and paths with respect to URNs.

>
> I suppose another option is allow each namespace to define relative 
> resolution.

Right.   Though that would impair generic handling of URNs by both 
clients and resolution services.

>
> Either case is better than what we have today, which is a completely 
> undefined process.
>
>     b) Require that resolution of web content (i.e. content that uses
>     3986-style URIs and relative references) be through an
>     intermediate URI, (e.g. an http URL) which is treated as a base
>     URI, and that all relative references are evaluated relative to
>     that intermediate URI rather than the URN.    (This leaves URNs
>     relatively unconstrained and avoids burdening them with "web
>     baggage", but still leaves open the question of how
>     {f,p,q}-components of a URN are interpreted.)
>
>
> An example would be helpful. However, this appears to mean that URN 
> relative resolution is dependent on the implied URI scheme of the 
> relative reference or is application context specific.

Yes.   One way to think of it is that URNs aren't specific to "the web", 
they're from a larger domain.   (which is arguably true, since URNs also 
name printed matter, sound recordings, etc.)   But when you use a URN to 
name something that's in "the web", you have to map from that URN to a 
"web" identifier, so that the conventions for evaluating relative 
references to "web" identifiers work within "the web".

Note that there appear to be other options besides just a and b above - 
there are at least subdivisions of either (as you pointed out with a) 
and there are combinations of the two.   I'm still trying to sort out 
the bounds of the options that appear to me to be worth considering (not 
that I'm the arbiter of such things, but putting too many options on the 
table also hinders discussion, so I might as well try to winnow them 
down a bit)

>
> If we can come to some agreement on how to deal with relative 
> resolution, that would be good. However, allowing the topic to 
> continue to cause conflicts is not acceptable.

It's not the topic that's causing conflicts.   The conflicts are 
(mostly) created by the goals of URNs and the language in RFC 3986 that 
forces URL syntax and relative name resolution onto URNs.    If we 
weren't constrained by 3986 syntax, the discussion, and presumably 
resolution of any conflicts, would be much easier.

More generally, we can't address technical problems by ignoring them or 
refusing to discuss them.

Keith


--------------030506010508000901050309
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 04/08/2015 12:19 PM, Andrew Newton
      wrote:

    

    

      


        


          
On Tue, Apr 7, 2015 at 5:40 PM, Keith
            Moore <moore@network-heretics.com>
            wrote:

            

              

                


                

              

              Pulling this out looks like ignoring the problem, and I
              don't think ignoring the problem will help.   I suspect it
              introduces more "known technical omissions" that RFC 2026
              forbids.

            

            


            

            
This would not be an omission. It would be a deliberate
              re-evaluation of design criteria. 

            

          

        

      

    

    

    I disagree.   Again, I don't think this group is chartered to
    redefine URNs.

    

    

      

        

          

            
 

            

              I haven't come to the point where I can make a proposal
              yet, but I have been looking into different options, e.g.:

              

              a) Handle relative references with respect to URNs just as
              3986 specifies, and document the various

              constraints on NSS assignment, path component persistence,
              etc., that this implies; or

            

            


            

            
If I understand you correctly, this would require us to
              define relative resolution of fragments, queries, and
              paths against all URNs. That is one option.

          

        

      

    

    

    Right.   Of course, 3986 already do this, and it defines relative
    references to URIs purely as a matter of syntax, so the "only
    syntax" choice already leads down this path.   If a URN is permitted
    to be a base URI, and URNs are parsed according to 3986, we
    effectively have relative resolution of fragments, queries, and
    paths with respect to URNs.

    

    

      

        

          

            


            

            
I suppose another option is allow each namespace to
              define relative resolution.

          

        

      

    

    

    Right.   Though that would impair generic handling of URNs by both
    clients and resolution services.

    

    

      

        

          

            


            

            
Either case is better than what we have today, which is
              a completely undefined process. 

            
 

            

              b) Require that resolution of web content (i.e. content
              that uses 3986-style URIs and relative references) be
              through an intermediate URI, (e.g. an http URL) which is
              treated as a base URI, and that all relative references
              are evaluated relative to that intermediate URI rather
              than the URN.    (This leaves URNs relatively
              unconstrained and avoids burdening them with "web
              baggage", but still leaves open the question of how
              {f,p,q}-components of a URN are interpreted.)

            

            


            

            
An example would be helpful. However, this appears to
              mean that URN relative resolution is dependent on the
              implied URI scheme of the relative reference or is
              application context specific.

          

        

      

    

    

    Yes.   One way to think of it is that URNs aren't specific to "the
    web", they're from a larger domain.   (which is arguably true, since
    URNs also name printed matter, sound recordings, etc.)   But when
    you use a URN to name something that's in "the web", you have to map
    from that URN to a "web" identifier, so that the conventions for
    evaluating relative references to "web" identifiers work within "the
    web".

    

    Note that there appear to be other options besides just a and b
    above - there are at least subdivisions of either (as you pointed
    out with a) and there are combinations of the two.   I'm still
    trying to sort out the bounds of the options that appear to me to be
    worth considering (not that I'm the arbiter of such things, but
    putting too many options on the table also hinders discussion, so I
    might as well try to winnow them down a bit)

    

    

      

        

          

            


            

            
If we can come to some agreement on how to deal with
              relative resolution, that would be good. However, allowing
              the topic to continue to cause conflicts is not
              acceptable.

          

        

      

    

    

    It's not the topic that's causing conflicts.   The conflicts are
    (mostly) created by the goals of URNs and the language in RFC 3986
    that forces URL syntax and relative name resolution onto URNs.    If
    we weren't constrained by 3986 syntax, the discussion, and
    presumably resolution of any conflicts, would be much easier.

    

    More generally, we can't address technical problems by ignoring them
    or refusing to discuss them. 

    

    Keith

    

  


--------------030506010508000901050309--


From nobody Wed Apr  8 09:46:15 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419FC1B3429 for ; Wed,  8 Apr 2015 09:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkth0mr0SHmK for ; Wed,  8 Apr 2015 09:46:12 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA3E1B341E for ; Wed,  8 Apr 2015 09:46:12 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2FC3520B7E for ; Wed,  8 Apr 2015 12:46:08 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Wed, 08 Apr 2015 12:46:12 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=UDvoahTd4eI2WuvfsfJwz09Do54=; b=nqi3K LT++IaMNsW81C4pI8JmJpIoMPxw/Sq0+JsIvJBiBfmN4/2JwAdY/g6BZktByYraJ DXl85hUX1Lk1GQKd3bzT/vHahHW8WIqIfQlAirfm6CtIh+nrmB6Qm/kn1miAgonV LspRvme8hgfOFvcKmlRN5T95x30E3NFW/psvEo=
X-Sasl-enc: Ho+5xdj+Ajab2e/jAEZnhVL06h5qfuV5aES5ArQf1m85 1428511571
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 36AA2680085; Wed,  8 Apr 2015 12:46:11 -0400 (EDT)
Message-ID: <55255B32.80903@network-heretics.com>
Date: Wed, 08 Apr 2015 12:45:38 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Andrew Newton 
References: <55142CA1.2000509@network-heretics.com>		<5FE5D998-3ADD-4E17-BD48-64995A914153@network-heretics.com>	<55143EEA.1060303@gmail.com>	<5514433D.7010604@network-heretics.com>		<55172454.40502@network-heretics.com>	<9176873CA947DB9D9175A34F@JcK-HP8200.jck.com>	<551B0F54.4060601@network-heretics.com>	<5524A35E.4030100@andyet.net>	<5524C20C.3090008@network-heretics.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020705060104010608020206"
Archived-At: 
Cc: "urn@ietf.org" , Peter Saint-Andre - &yet 
Subject: Re: [urn] General-purpose resolution service
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 16:46:14 -0000

This is a multi-part message in MIME format.
--------------020705060104010608020206
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 04/08/2015 12:30 PM, Andrew Newton wrote:
> Asking about keeping a generic URN parser as design criteria was next 
> up on my list, but I suppose Peter beat me to it. :)
>
> On Wed, Apr 8, 2015 at 1:52 AM, Keith Moore 
> > wrote:
>
>
>     These days, browsers have hooks to support additional URI
>     protocols.   Good libraries exist for node, python and several
>     other languages to provide all of the network access, parsing,
>     database support, JSON formatting, etc. that you could possibly
>     need.    You can put together a decent server in a few hours.
>     Reliable real and virtual servers are available in minutes, at
>     commodity prices, with good network connectivity and good
>     management.    So is cloud storage.
>
>
> While such resources were not easily obtainable 20 years ago, they 
> were 10 years ago. In that timeframe we have not seen generic URN 
> services or applications.

Again, you're not likely to see them until there's substantial use of 
URNs within multiple namespaces.   Deployment of something like URNs 
naturally takes place on a different time scale than deployment of, say, 
the web, which had immediate benefit to users even when it was small.    
And again, without some ability to generically process URNs, there's 
almost no value at all in having a URN URI scheme.

I also note that the URN resolution servers that I've discovered appear 
to be generic in some sense, in that they prompt for URNs rather than 
say ISBN URNs or NBN URNs.      So I don't think what we're seeing in 
this group's discussion is that actual users of URNs don't see the value 
in generic handling of URNs, but rather, that such actual users are 
under-represented in this discussion.

> We need to allow uses of URNs from large URN-using communities as has 
> been requested vs. the desire for implementations that have had 20 
> years to materialize but have not. While no person can predict the 
> future, I would guess the broader IETF community would favor changes 
> to meet modern issues over unrealized design criteria from 20 years ago.

This isn't a case of a conflict between modern issues vs. unrealized 
design criteria.

Keith


--------------020705060104010608020206
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 04/08/2015 12:30 PM, Andrew Newton
      wrote:

    

    

      
Asking about keeping a generic URN parser as design
        criteria was next up on my list, but I suppose Peter beat me to
        it. :)

        


          
On Wed, Apr 8, 2015 at 1:52 AM, Keith
            Moore <moore@network-heretics.com>
            wrote:

            


              These days, browsers have hooks to support additional URI
              protocols.   Good libraries exist for node, python and
              several other languages to provide all of the network
              access, parsing, database support, JSON formatting, etc.
              that you could possibly need.    You can put together a
              decent server in a few hours. Reliable real and virtual
              servers are available in minutes, at commodity prices,
              with good network connectivity and good management.    So
              is cloud storage.

            

            


            

            
While such resources were not easily obtainable 20
              years ago, they were 10 years ago. In that timeframe we
              have not seen generic URN services or applications.

          

        

      

    

    

    Again, you're not likely to see them until there's substantial use
    of URNs within multiple namespaces.   Deployment of something like
    URNs naturally takes place on a different time scale than deployment
    of, say, the web, which had immediate benefit to users even when it
    was small.    And again, without some ability to generically process
    URNs, there's almost no value at all in having a URN URI scheme.

    

    I also note that the URN resolution servers that I've discovered
    appear to be generic in some sense, in that they prompt for URNs
    rather than say ISBN URNs or NBN URNs.      So I don't think what
    we're seeing in this group's discussion is that actual users of URNs
    don't see the value in generic handling of URNs, but rather, that
    such actual users are under-represented in this discussion.

    

    

      

        

          

            
We need to allow uses of URNs from large URN-using
              communities as has been requested vs. the desire for
              implementations that have had 20 years to materialize but
              have not. While no person can predict the future, I would
              guess the broader IETF community would favor changes to
              meet modern issues over unrealized design criteria from 20
              years ago.

          

        

      

    

    

    This isn't a case of a conflict between modern issues vs. unrealized
    design criteria.   

    

    Keith

    

  


--------------020705060104010608020206--


From nobody Thu Apr  9 13:36:06 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D991B320A for ; Thu,  9 Apr 2015 13:36:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZsn6f5BAeDa for ; Thu,  9 Apr 2015 13:36:03 -0700 (PDT)
Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 806921A88F1 for ; Thu,  9 Apr 2015 13:36:03 -0700 (PDT)
Received: by pdea3 with SMTP id a3so164726919pde.3 for ; Thu, 09 Apr 2015 13:36:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=JGQL4qG9EcVM+/eRBub6jp3CJBI/8coWCeKobgNk4+o=; b=F2WCcmx2PyCu28xPIpmgfwOgXb7WunlKRakwweR5vbQ4HO7t5ppUHa3VZYkI8yVDtz PSxKJKeGDdtdHT2+Kxk8Wm2WfzNu51qgNuKWc+JwgDIDfx67TKI5pYW1z54YTfwZv1y3 QmUn4IFJOlCWHftyPJwZQB/aNZMNdg/AymCM4Q8qFuSftDkt5jEbVcq9IjY3w6k+71+F 3fMD5IJBSHc4zMdjaYQVtkmSkzmHbXDLnPH+erwM4ms5IYfd3v8KiguBxwDtm1o4dyMT wlRLGoLF1nbDY96HHprIUnX+UQePJOKuWaByUfmpWsQw2wcRds8z3PtLOs9w8rBQ41A/ 3Fbg==
X-Received: by 10.70.96.65 with SMTP id dq1mr40728307pdb.79.1428611763216; Thu, 09 Apr 2015 13:36:03 -0700 (PDT)
Received: from spandex.local (124-pm34.nwc.acsalaska.net. [209.112.159.124]) by mx.google.com with ESMTPSA id bz3sm15632102pab.2.2015.04.09.13.36.02 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Apr 2015 13:36:02 -0700 (PDT)
Message-ID: <5526E2B1.7080307@gmail.com>
Date: Thu, 09 Apr 2015 12:36:01 -0800
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: urn@ietf.org
References: <5E507C17-1F0B-42C6-9560-4632E2738EDB@adobe.com>  <9CC60D30-731C-42DE-89A3-EC1CA47BA3E3@adobe.com> <5524BB05.7020807@network-heretics.com>
In-Reply-To: <5524BB05.7020807@network-heretics.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] 3986 relationships - Fragment identifiers
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 20:36:05 -0000

I'm a little concerned that the discussion has become as
contentious as it is, with so little comment from other
working group participants.  We really need to hear from
others in addition to the draft authors, Keith, and Larry.
We'll discuss this in the interim next Friday but I'm
hopeful we can make progress on this before then.

Thanks,

Melinda


From nobody Thu Apr  9 20:29:35 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9777B1AC3DC for ; Thu,  9 Apr 2015 20:29:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4QgJpiu-u_d for ; Thu,  9 Apr 2015 20:29:32 -0700 (PDT)
Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE6D1AC3D5 for ; Thu,  9 Apr 2015 20:29:32 -0700 (PDT)
Received: by ignm3 with SMTP id m3so7185801ign.0 for ; Thu, 09 Apr 2015 20:29:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9Do5qJKU+pVJ9CxPTAGy7vlvgaC44jSRZ2zbFvB31Dc=; b=eXkje6g1YIpkMVhkSO7kHvoPst9CnadG+jRZqHvbFvd0wMsA1mS3XTWqYf9HZ4G1cC Wu0Op1EnUv8jCSChiucdX/GoEwLx51Df6f+YsRKOzVu0JKc+0HMX7gRFjlkv4yObS49x lReCPfQ4Mmi0s4wEIbsRaxn/a4/yh8K5LXJA1RzILU1oXJ3AeRuXjQFEXgqtMzVb7bri AsuplteNFP9aIJZgmDiT5kdqhK3K58/QdxXJhUFXQjwV6DdAcsr+9CSritHSftAuhiOR MK342COJNpmbDDXgejxcIvTzPf3TiZ/mHt6ZyYlqTELafkRr3dwyFXk4x5nXnmSBbCGY X5vg==
X-Gm-Message-State: ALoCoQnWxcUKSzuMtchb22/ixEdzvajYXq0apstzWpwewETGC9jy+uevxj/RI+QZ5x3cab2/FY1j
X-Received: by 10.43.60.14 with SMTP id wq14mr880555icb.60.1428636571585; Thu, 09 Apr 2015 20:29:31 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id t41sm524419ioe.5.2015.04.09.20.29.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 20:29:31 -0700 (PDT)
Message-ID: <55274399.9050600@andyet.net>
Date: Thu, 09 Apr 2015 21:29:29 -0600
From: Peter Saint-Andre - &yet 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: John C Klensin ,  Keith Moore , urn@ietf.org
References: <55142CA1.2000509@network-heretics.com> <21AB78DB534184F02D06AA83@JcK-HP8200.jck.com>
In-Reply-To: <21AB78DB534184F02D06AA83@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Putative nits
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Apr 2015 03:29:34 -0000

On 3/31/15 10:52 AM, John C Klensin wrote:
> Keith,
>
> Interestingly, whether these are "nits" or not is itself an
> interesting question because each one seems to me to raise
> additional questions or issues.  We certainly agree that none of
> them are (or should be) earthshaking or showstoppers.  I/we have
> not incorporated changes for any of them into -11.  I suggest
> that you and the rest of the WG have a look at the comments
> below to see if we can reach conclusions about what should be in
> -12.  The numbering of subsections and summary titles below are
> intended to lower the odds of anything getting lost.
>
> --On Thursday, March 26, 2015 11:58 -0400 Keith Moore
>  wrote:
>
> (1) "Typically"
>
>> 1. Introduction, 2nd paragraph, first sentence.   Omit the
>> word "typically", or otherwise reword to avoid creating the
>> impression that it's ok to use URNs as other than persistent,
>> location-independent resource identifiers.
>
> My recollection is that we put "typically" in there to resolve
> other concerns and complaints.  They _may_ have been about
> whether "persistent, location-independent resource identifier or
> abstract designator" actually covered all of the reasonable
> cases.

That is my recollection - we were not sure that "resource identifier or 
abstract designator" was all-encompassing.

>  Could others comment on this?  Note that almost the
> same phrasing appears in the Abstract so, if it should be
> changed in the Introduction, it should presumably be changed
> there too.
>
> (2) "MAY" and "can"
>
>> 2. Section 3, paragraph following ABNF section: I would
>> substitute "MAY" for "can".
>
> After some list discussion (and, IIR, considerable confusion
> about what 3986 allowed), I chose "can" because this statement
> is a reminder about 3986-reality rather than a normative
> requirement (even a permissive one) imposed by this
> specification.    If your reasoning is different, please explain.
>
> (3) "Global uniqueness"
>
>> 3. Section 6, paragraph starting "With regard to global
>> uniqueness":    Just simply state that a single resource can
>> have more than one URN assigned to it.   It doesn't matter
>> whether those URNs exist for different purposes.

That is one example of why more than one URN might be assigned to the 
same resource. I suggest:

OLD
    However, a single resource can have
    more than one URN assigned to it for different purposes (for example,
    if a book were published in a monograph series, it could have both an
    ISBN [RFC3187] and an ISSN [RFC3044] assigned to it, resulting in two
    URNs referring to the same book).

NEW
    However, a single resource can have
    more than one URN assigned to it (e.g.,
    if a book were published in a monograph series, it could have both an
    ISBN [RFC3187] and an ISSN [RFC3044] assigned to it, resulting in two
    URNs referring to the same book).

>> Also
>> clarify that if there is no such thing as a distinguished or
>> preferred URN for a resource that can be inferred from looking
>> at the URNs.

That seems correct to me.

>> At least as far as the URN architecture is
>> concerned, all URNs are equally valid.   (If the resource
>> wants to specify which of several URNs is the distinguished
>> name for itself, that's a different matter.)
>
> This paragraph has been slightly rewritten in -11 to reflect
> Ted's comments.  I'd like the WG to have a chance to look at
> this and compare it to the approach you recommend before making
> further changes.

I think some slight rewording can address these issues.

Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Thu Apr  9 20:38:51 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE87B1AC408 for ; Thu,  9 Apr 2015 20:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtQCRYYxWum8 for ; Thu,  9 Apr 2015 20:38:47 -0700 (PDT)
Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFF31AC400 for ; Thu,  9 Apr 2015 20:38:47 -0700 (PDT)
Received: by igblo3 with SMTP id lo3so8265485igb.0 for ; Thu, 09 Apr 2015 20:38:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6MxuwWiXJAY3r2LhqKyCnl9qiPNhO3CLv+VzPkadBN0=; b=jYpZ/qzdUVmRZUH2JErIObcYm7FymSLPQk7L/ZyabIeeFfKwCjNH016BuNeionPL0h 6NZOq1Ld3TUiMWV76NHDHY0OitwpECDPTIin9OemHFUAfmuRzglvC6Hi3y/D0pxVQEkS 1DGoGLVEERCEZKfL4tMcWYN3V4pbcq0fiPqF7hZWpfA4xustJEsY+GXAOE/xCzSL6tXG 1D0J92jTVdPh7H5dHk8AGEU7BohFmDtrefwx554c+VYpCC5tWSC+tGJJN5JqbsyNPYdF uXSjJEZQyRwvOkQqMH0MKsYdQUQtxr2S/LrsqutqYGPKaPtEMXY6t+X70rN3Y2Fjntcb U0lA==
X-Gm-Message-State: ALoCoQnlbHjDozg6xo42i1nP6/+Alzc9Osrdn9nYhKUbTF/jVQP1BARh/BB0AhNlpyf6vieJtRm+
X-Received: by 10.50.79.195 with SMTP id l3mr13817512igx.30.1428637127062; Thu, 09 Apr 2015 20:38:47 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id ys3sm764088igb.4.2015.04.09.20.38.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 20:38:46 -0700 (PDT)
Message-ID: <552745C4.2030607@andyet.net>
Date: Thu, 09 Apr 2015 21:38:44 -0600
From: Peter Saint-Andre - &yet 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Keith Moore , Andrew Newton 
References: <55142CA1.2000509@network-heretics.com>		<5FE5D998-3ADD-4E17-BD48-64995A914153@network-heretics.com>	<55143EEA.1060303@gmail.com>	<5514433D.7010604@network-heretics.com>		<55172454.40502@network-heretics.com>	<9176873CA947DB9D9175A34F@JcK-HP8200.jck.com>	<551B0F54.4060601@network-heretics.com>	<5524A35E.4030100@andyet.net>	<5524C20C.3090008@network-heretics.com>  <55255B32.80903@network-heretics.com>
In-Reply-To: <55255B32.80903@network-heretics.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "urn@ietf.org" 
Subject: Re: [urn] General-purpose resolution service
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Apr 2015 03:38:50 -0000

On 4/8/15 10:45 AM, Keith Moore wrote:
> On 04/08/2015 12:30 PM, Andrew Newton wrote:
>> Asking about keeping a generic URN parser as design criteria was next
>> up on my list, but I suppose Peter beat me to it. :)
>>
>> On Wed, Apr 8, 2015 at 1:52 AM, Keith Moore
>> > wrote:
>>
>>
>>     These days, browsers have hooks to support additional URI
>>     protocols.   Good libraries exist for node, python and several
>>     other languages to provide all of the network access, parsing,
>>     database support, JSON formatting, etc. that you could possibly
>>     need.    You can put together a decent server in a few hours.
>>     Reliable real and virtual servers are available in minutes, at
>>     commodity prices, with good network connectivity and good
>>     management.    So is cloud storage.
>>
>>
>> While such resources were not easily obtainable 20 years ago, they
>> were 10 years ago. In that timeframe we have not seen generic URN
>> services or applications.
>
> Again, you're not likely to see them until there's substantial use of
> URNs within multiple namespaces.

As I understand it, there are millions of URNs assigned for ISBNs, 
ISSNs, and NBNs. I would call that substantial use.

> Deployment of something like URNs
> naturally takes place on a different time scale than deployment of, say,
> the web, which had immediate benefit to users even when it was small.
> And again, without some ability to generically process URNs, there's
> almost no value at all in having a URN URI scheme.

That might be - it might have made more sense to establish separate URI 
schemes for ISBN, ISSN, NBN, etc. But that ship has sailed. There is 
definitely value in all those assigned URNs, even if we didn't really 
(in retrospect) need to have a separate URI scheme for URNs.

> I also note that the URN resolution servers that I've discovered appear
> to be generic in some sense, in that they prompt for URNs rather than
> say ISBN URNs or NBN URNs.

Resolution for URNs from some namespaces might be appropriate (ISBNs, 
ISSNs, and NBNs seem to fit the bill). But the list of registered 
namespaces is much broader:

http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

It seems to me that URNs from many of those namespaces might never need 
to be resolved, in part because they function as "abstract designators" 
or indicators.

> So I don't think what we're seeing in
> this group's discussion is that actual users of URNs don't see the value
> in generic handling of URNs, but rather, that such actual users are
> under-represented in this discussion.

Again, that might be. But unfortunately many constituencies are 
under-represented here because so few people are participating. (I 
haven't seen anyone on this list talking about the needs of all the SDOs 
or near-SDOs that have registered URN namespaces, for example.)

Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Thu Apr  9 20:50:22 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACCA1ACCE0 for ; Thu,  9 Apr 2015 20:50:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.301
X-Spam-Level: 
X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keRe-wzOG3uy for ; Thu,  9 Apr 2015 20:50:19 -0700 (PDT)
Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1C51ACCDA for ; Thu,  9 Apr 2015 20:50:19 -0700 (PDT)
Received: by iebrs15 with SMTP id rs15so8258592ieb.3 for ; Thu, 09 Apr 2015 20:50:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qt/TIfM9yMKIA1+U6IqxNjCxzXd8DHGW7sF9dP3wlNU=; b=BVTv+cUC7V0MxaUC5/wS1D06TpJHcYjtvtBNzXVGs7KKJEM4wtETXKhbFVRFqWH0YM PlJuH8kqWFxb6ZefHNdw5+pklwgWwejUMmugXJ8KG4IBZcVmFsJXQ9ieG65wdM+yZYpJ BvzgeslYtseFxSdvGvAwsGKIUUxiITsjFVnX2qrvyVR4HxW47TicYZ5r3gSonszIEXhu pn43n5dfFDnpoDZQp0mfbuHdnl6l83hLiIKr3EWgNrXXhVHOpEKN7Y+jL7yiqwnFek2T wJToYjTc4/AJBLmxaRpIMWI8NURSmO7upw/6u1wIDF/g2en9iLNcn6KeVtwOBGXeIOe0 Rxsw==
X-Gm-Message-State: ALoCoQmNYqW4T/06xTtQqxh6y2CBaa9Q+jK7q7lRlbjpLFT5NFjc/+AaUNOSLoqWFmrvSYfJZDLo
X-Received: by 10.42.151.4 with SMTP id c4mr907244icw.77.1428637819008; Thu, 09 Apr 2015 20:50:19 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id d63sm533166ioe.34.2015.04.09.20.50.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 20:50:18 -0700 (PDT)
Message-ID: <55274878.60302@andyet.net>
Date: Thu, 09 Apr 2015 21:50:16 -0600
From: Peter Saint-Andre - &yet 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Keith Moore ,  John C Klensin , urn@ietf.org
References: <55142CA1.2000509@network-heretics.com>  <551B14E2.8060000@network-heretics.com>
In-Reply-To: <551B14E2.8060000@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Persistence with f-components or p-components
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Apr 2015 03:50:21 -0000

On 3/31/15 3:42 PM, Keith Moore wrote:
> John,
>
> Let's take a step back here.   I'm not asking for this group or this
> document to revisit RFC 1737s definition of persistence. Nor do I think
> it is in scope for this working group (as defined by its charter) to do
> so, as that's tantamount to redefining URNs.
>
> I'm simply asking for one or two sentences to be added to rfc2141bis to
> clarify which of f-component, p-component, and q-component are relevant
> when considering persistence.   RFC 2141 didn't need to address this
> issue because with RFC 2141 URNs, the entire URN was assigned, so the
> persistence property applied to the entire URN.
>
> The text I have in mind is something like:
>
> Only the [list of components] of the URN are required to meet the
> "persistence" property specified in RFC 1737.   Individual namespaces
> may, however, impose more stringent requirements on use of [other
> components].
>
> I just don't know what should be that list of components.  I can,
> however, somewhat arbitrarily, suggest concrete text:
>
> Only the assigned-name and p-component of the URN are required to meet
> the "persistence" property specified in RFC 1737.   Individual
> namespaces may, however, impose additional restrictions on the use of
> q-component and/or f-component.
>
> (and if a normative reference to RFC 1737 is a problem, just leave out
> "specified in RFC 1737".   RFC 1737 would probably have been a BCP, had
> BCPs existed at the time.)

I think the persistence rule falls out from equivalence rule. If we say 
that only the assigned-name and the p-component are taken into account 
for purposes of determining equivalence, then I think we would say that 
only the assigned-name and p-component are required to meet the 
persistence property.

Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Thu Apr  9 21:00:24 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B7B1ACD03 for ; Thu,  9 Apr 2015 21:00:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.3
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x2deyQD7vJf for ; Thu,  9 Apr 2015 21:00:22 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8A6D1ACD04 for ; Thu,  9 Apr 2015 21:00:21 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 2E847208F5 for ; Fri, 10 Apr 2015 00:00:16 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 10 Apr 2015 00:00:20 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=L5xPLkEJpN/MqEf KdTxr88PsosU=; b=KKXDl7CLMWntHL4SsqFEi9yVw9QmFu+/gXvn/BsfGCPRtba bDIASfGy7rLPwOzPl/hbzNfNz2AyCEZenGPa1d2AiJvdfvny2q89dH5lFpLq0xuF TRh558DdJ8uV0C1bEVKj4p/+Zut4MST4Zpk9TpXOgeqw3bUwobf9cl5wFh+U=
X-Sasl-enc: nY2eZSDbEn8jRGmlRfokGnogwUJoJNROxAJul3fhQtzh 1428638419
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id CC292C00011; Fri, 10 Apr 2015 00:00:19 -0400 (EDT)
Message-ID: <55274AD1.7060900@network-heretics.com>
Date: Fri, 10 Apr 2015 00:00:17 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <55142CA1.2000509@network-heretics.com>		<5FE5D998-3ADD-4E17-BD48-64995A914153@network-heretics.com>	<55143EEA.1060303@gmail.com>	<5514433D.7010604@network-heretics.com>		<55172454.40502@network-heretics.com>	<9176873CA947DB9D9175A34F@JcK-HP8200.jck.com>	<551B0F54.4060601@network-heretics.com>	<5524A35E.4030100@andyet.net>	<5524C20C.3090008@network-heretics.com>  <55255B32.80903@network-heretics.com> <552745C4.2030607@andyet.net>
In-Reply-To: <552745C4.2030607@andyet.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] General-purpose resolution service
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Apr 2015 04:00:24 -0000

On 04/09/2015 11:38 PM, Peter Saint-Andre - &yet wrote:
> On 4/8/15 10:45 AM, Keith Moore wrote:
>> On 04/08/2015 12:30 PM, Andrew Newton wrote:
>>> Asking about keeping a generic URN parser as design criteria was next
>>> up on my list, but I suppose Peter beat me to it. :)
>>>
>>> On Wed, Apr 8, 2015 at 1:52 AM, Keith Moore
>>> > wrote:
>>>
>>>
>>>     These days, browsers have hooks to support additional URI
>>>     protocols.   Good libraries exist for node, python and several
>>>     other languages to provide all of the network access, parsing,
>>>     database support, JSON formatting, etc. that you could possibly
>>>     need.    You can put together a decent server in a few hours.
>>>     Reliable real and virtual servers are available in minutes, at
>>>     commodity prices, with good network connectivity and good
>>>     management.    So is cloud storage.
>>>
>>>
>>> While such resources were not easily obtainable 20 years ago, they
>>> were 10 years ago. In that timeframe we have not seen generic URN
>>> services or applications.
>>
>> Again, you're not likely to see them until there's substantial use of
>> URNs within multiple namespaces.
>
> As I understand it, there are millions of URNs assigned for ISBNs, 
> ISSNs, and NBNs. I would call that substantial use.

I should perhaps have been clearer about what I meant by "substantial 
use".   But I expect that by now there are some resolution services that 
accept URNs from any of these namespaces, and perhaps some other 
namespaces, without requiring the client to know particulars of each 
namespace and to process different namespaces differently.    And it 
actually appears that some such services exist.   Most of what I'm 
saying is that it should continue to be possible to have such services, 
not only for RFC 2141 URNs but also for URNs with an extended syntax.   
Having namespace-specific interpretation of f-, q- ,or p-components 
potentially threatens this property and makes it harder to build generic 
resolvers and generic client code.

Frankly, I don't understand why this isn't obviously important to 
everyone here, or what the disconnect is.

>
>> Deployment of something like URNs
>> naturally takes place on a different time scale than deployment of, say,
>> the web, which had immediate benefit to users even when it was small.
>> And again, without some ability to generically process URNs, there's
>> almost no value at all in having a URN URI scheme.
>
> That might be - it might have made more sense to establish separate 
> URI schemes for ISBN, ISSN, NBN, etc. But that ship has sailed. There 
> is definitely value in all those assigned URNs, even if we didn't 
> really (in retrospect) need to have a separate URI scheme for URNs.

I never argued that there shouldn't be a separate URI scheme for URNs.  
What I said was that extending URNs to have namespace-specific 
interpretation of fragments, paths, and/or queries defeats the purpose 
of having a URN scheme in the first place.  I assume that the purpose of 
the URNBIS group is not to defeat the purpose of having a URN scheme.  
It's not my purpose either.   If we're going to extend URN syntax, I 
want us to do it in such a way that it can work well.

>
>> I also note that the URN resolution servers that I've discovered appear
>> to be generic in some sense, in that they prompt for URNs rather than
>> say ISBN URNs or NBN URNs.
>
> Resolution for URNs from some namespaces might be appropriate (ISBNs, 
> ISSNs, and NBNs seem to fit the bill). But the list of registered 
> namespaces is much broader:
>
> http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
>
> It seems to me that URNs from many of those namespaces might never 
> need to be resolved, in part because they function as "abstract 
> designators" or indicators.

I don't disagree with that, and nothing that I'm asking for contradicts 
that.   There's no requirement that every URN be listed in some resolver 
somewhere.  There will always be URNs for which one cannot obtain any 
information from any existing source.   This is understood.

When I say "generic resolver" I don't expect that any such resolver will 
have information for every URN, or even that there will be a resolver 
for every namespace.   What I mean is that it should be possible to 
write client and server software that can potentially process any URN 
(and say, query a database for it and/or provide access to its content, 
when applicable and when the content is available) without that software 
having to know specifics of that particular URN or namespace.    You 
shouldn't need to have to write separate client code for each namespace, 
or separate server code for each namespace.   This is the very purpose 
of protocol standards, and protocol standardization is what we are 
supposed to be doing here.

>
>> So I don't think what we're seeing in
>> this group's discussion is that actual users of URNs don't see the value
>> in generic handling of URNs, but rather, that such actual users are
>> under-represented in this discussion.
>
> Again, that might be. But unfortunately many constituencies are 
> under-represented here because so few people are participating. (I 
> haven't seen anyone on this list talking about the needs of all the 
> SDOs or near-SDOs that have registered URN namespaces, for example.)

Agreed, this is a big problem.

Keith


From nobody Mon Apr 13 12:22:51 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C33E1B31FA for ; Mon, 13 Apr 2015 12:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.589
X-Spam-Level: *
X-Spam-Status: No, score=1.589 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IICVei7txaVZ for ; Mon, 13 Apr 2015 12:22:49 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969651B31DF for ; Mon, 13 Apr 2015 12:22:49 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YhjwR-000KJq-KJ; Mon, 13 Apr 2015 15:22:43 -0400
Date: Mon, 13 Apr 2015 15:22:38 -0400
From: John C Klensin 
To: Peter Saint-Andre - &yet , Keith Moore , urn@ietf.org
Message-ID: <86ABD668F4D250D365774EFF@JcK-HP8200.jck.com>
In-Reply-To: <55274878.60302@andyet.net>
References: <55142CA1.2000509@network-heretics.com>  <551B14E2.8060000@network-heretics.com> <55274878.60302@andyet.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Subject: Re: [urn] Persistence with f-components or p-components
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Apr 2015 19:22:50 -0000

--On Thursday, April 09, 2015 21:50 -0600 Peter Saint-Andre -
&yet  wrote:

> On 3/31/15 3:42 PM, Keith Moore wrote:
>> John,
>> 
>> Let's take a step back here.   I'm not asking for this group
>> or this document to revisit RFC 1737s definition of
>> persistence. Nor do I think it is in scope for this working
>> group (as defined by its charter) to do so, as that's
>> tantamount to redefining URNs.
>> 
>> I'm simply asking for one or two sentences to be added to
>> rfc2141bis to clarify which of f-component, p-component, and
>> q-component are relevant when considering persistence.   RFC
>> 2141 didn't need to address this issue because with RFC 2141
>> URNs, the entire URN was assigned, so the persistence
>> property applied to the entire URN.
>> 
>> The text I have in mind is something like:
>> 
>> Only the [list of components] of the URN are required to meet
>> the "persistence" property specified in RFC 1737.
>> Individual namespaces may, however, impose more stringent
>> requirements on use of [other components].
>> 
>> I just don't know what should be that list of components.  I
>> can, however, somewhat arbitrarily, suggest concrete text:
>> 
>> Only the assigned-name and p-component of the URN are
>> required to meet the "persistence" property specified in RFC
>> 1737.   Individual namespaces may, however, impose additional
>> restrictions on the use of q-component and/or f-component.
>> 
>> (and if a normative reference to RFC 1737 is a problem, just
>> leave out "specified in RFC 1737".   RFC 1737 would probably
>> have been a BCP, had BCPs existed at the time.)
> 
> I think the persistence rule falls out from equivalence rule.
> If we say that only the assigned-name and the p-component are
> taken into account for purposes of determining equivalence,
> then I think we would say that only the assigned-name and
> p-component are required to meet the persistence property.

FWIW, that is consistent with the assumption I've been making.
I've been concentrating on equivalence, but I believe the
definition of persistence in 1737, whose key phrase appears to
be "globally unique forever" (the other provisions cannot be
enforced except as a matter of intent) comes down to an
equivalence assertion about to what it is globally unique.

    john




From nobody Mon Apr 13 12:34:53 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB581B3284 for ; Mon, 13 Apr 2015 12:34:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level: 
X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQgYQA2OkdX4 for ; Mon, 13 Apr 2015 12:34:51 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D66A1B3285 for ; Mon, 13 Apr 2015 12:34:51 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Yhk89-000KKZ-2v; Mon, 13 Apr 2015 15:34:49 -0400
Date: Mon, 13 Apr 2015 15:34:44 -0400
From: John C Klensin 
To: Peter Saint-Andre - &yet , Keith Moore , urn@ietf.org
Message-ID: 
In-Reply-To: <55274399.9050600@andyet.net>
References: <55142CA1.2000509@network-heretics.com> <21AB78DB534184F02D06AA83@JcK-HP8200.jck.com> <55274399.9050600@andyet.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Subject: Re: [urn] Putative nits
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Apr 2015 19:34:52 -0000

--On Thursday, April 09, 2015 21:29 -0600 Peter Saint-Andre -
&yet  wrote:

>>> 3. Section 6, paragraph starting "With regard to global
>>> uniqueness":    Just simply state that a single resource can
>>> have more than one URN assigned to it.   It doesn't matter
>>> whether those URNs exist for different purposes.
> 
> That is one example of why more than one URN might be assigned
> to the same resource. I suggest:
> 
> OLD
>     However, a single resource can have
>     more than one URN assigned to it for different purposes
> (for example,
>     if a book were published in a monograph series, it could
> have both an
>     ISBN [RFC3187] and an ISSN [RFC3044] assigned to it,
> resulting in two
>     URNs referring to the same book).
> 
> NEW
>     However, a single resource can have
>     more than one URN assigned to it (e.g.,
>     if a book were published in a monograph series, it could
> have both an
>     ISBN [RFC3187] and an ISSN [RFC3044] assigned to it,
> resulting in two
>     URNs referring to the same book).

Wfm.  Note, however, that draft-ietf-urnbis-ns-reg-transition
obsoletes 3044 and 3187 so we may want to either find other
examples or say something like "URNs based on ISBN [] and ISSN
[]" and then reference the ISO specifications.

>...
>>> At least as far as the URN architecture is
>>> concerned, all URNs are equally valid.   (If the resource
>>> wants to specify which of several URNs is the distinguished
>>> name for itself, that's a different matter.)
>> 
>> This paragraph has been slightly rewritten in -11 to reflect
>> Ted's comments.  I'd like the WG to have a chance to look at
>> this and compare it to the approach you recommend before
>> making further changes.
> 
> I think some slight rewording can address these issues.

Agreed.  This adds to the importance of other people speaking
up, ideally before Friday's interim meeting, rather than having
a discussion among Keith, Peter, and myself.

    john




From nobody Mon Apr 13 13:11:15 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA831A1B71 for ; Mon, 13 Apr 2015 13:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level: 
X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJKnTC4zK_bv for ; Mon, 13 Apr 2015 13:11:05 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988A51A1B6E for ; Mon, 13 Apr 2015 13:11:05 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YhkhC-000KP5-17 for urn@ietf.org; Mon, 13 Apr 2015 16:11:02 -0400
Date: Mon, 13 Apr 2015 16:10:56 -0400
From: John C Klensin 
To: urn@ietf.org
Message-ID: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Subject: [urn] Why bother with f-components (fragments) and/or p-components ?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Apr 2015 20:11:10 -0000

Hi.

Those who have been following the apps-discuss list and the Apps
Area WG has seen a long, difficult, and sometimes unpleasant
thread about what a URN specification (or any other
specification for a particular URI scheme) is allowed to say
about fragments.  The discussion appears to extend to whether
fragments can be disallowed at all by a scheme (if they cannot,
2141 has problems quite independent of what we might do), to
whether a scheme can constrain fragment syntax in any way, and
to whether scheme-specific or namespace-specific restrictions or
semantic [1] rules are allowed.

Similar issues arise with p-components.   If a p-component
(i.e., introduced by a "/", at least before a q-component or
f-component) appears in a URN, it is claimed to be impossible
[2] to avoid relative resolution, something that might cause
havoc or other damage with URNs.

An obvious question is why we don't just disallow one or both
and move on.

For me, the answer is tied up with the question I've been asking
about the difference between instructions or qualifiers that are
part of the URN (see below) and instructions or qualifiers that
are intended to be passed to whatever the URN points to or
resolves to.   If no one else sees that as an issue, or believes
that we can reasonable handle it on a per-namespace basis (that
fragment discussion definitely would complicate handling those
on a per-namespace basis), please explain why and I'd drop this.
If others are concerned and believe we should handle that issue
using syntax, then I believe we need to consider three cases.
(I don't see any alternative to distinguishing by syntax if we
aren't going to make the distinction per-namespace, but maybe
I'm missing something):

I'm going to use the term "qualifier" below to identify things
that are not inherently part of the NSS (using the syntax in
2141bis-11) but that are part of the .

 Case 1: The qualifier is part of the URN to the extent
	that it is included in comparisons and affects
	persistence.  As part of the URN, it is expected to
	affect or provide information to a URN processor or
	resolver.
	
 Case 2: The qualifier is part of the URN in the sense
	that if affects or provides information to a URN
	processor or resolver, but does not participate in
	equality comparisons.    Information about locale (so a
	URN resolver could find the most convenient object or a
	pointer to it) would presumably fall into this category.
	I think distinctions between object and various types of
	metadata would too, but could be talked out of that.
	
 Case 3: The qualifier is not part of the URN but
	contains information or specifications that should be
	passed on to the URN's target if that is meaningful.
	The qualifier is probably not meaningful if there is no
	resolution and no target.

The WG hasn't seemed to be interested in forcing q-components
into a name-value form or other scheme-wide syntax.  It has
seemed still less interested in reserved some specific keywords
for use in that syntax.  But, it we don't do that, we seem to
have three significant cases and three components types.  The
implications seem obvious, at least to me.  If they are, then we
need to sort p-components and f-components out, rather than
getting rid of them.

If anyone sees problems with the analysis above or considers one
or more of the cases uninteresting, it would be helpful (at
least for me) to hear about it.

    john

 


[1] At least by my definition of "semantics".

[2] I am not disputing that claim, I just have problems with
"impossible".


From nobody Tue Apr 14 00:48:55 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07EC31B34EE for ; Tue, 14 Apr 2015 00:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.998
X-Spam-Level: 
X-Spam-Status: No, score=0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, MANGLED_OFF=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyKD-yn6_o1h for ; Tue, 14 Apr 2015 00:48:53 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997681B34EC for ; Tue, 14 Apr 2015 00:48:51 -0700 (PDT)
Received: from AM3PR07MB369.eurprd07.prod.outlook.com (10.242.109.143) by AM3PR07MB371.eurprd07.prod.outlook.com (10.242.109.150) with Microsoft SMTP Server (TLS) id 15.1.136.25; Tue, 14 Apr 2015 07:36:38 +0000
Received: from AM3PR07MB369.eurprd07.prod.outlook.com ([10.242.109.143]) by AM3PR07MB369.eurprd07.prod.outlook.com ([10.242.109.143]) with mapi id 15.01.0136.014; Tue, 14 Apr 2015 07:36:38 +0000
From: "Hakala, Juha E" 
To: John C Klensin , Peter Saint-Andre - &yet , Keith Moore , "urn@ietf.org" 
Thread-Topic: [urn] Persistence with f-components or p-components
Thread-Index: AQHQa/u6pu05WpdgnUCEvmLpUS92nZ1FqvEAgAW7fwCAAMHVgA==
Date: Tue, 14 Apr 2015 07:36:38 +0000
Message-ID: 
References: <55142CA1.2000509@network-heretics.com>  <551B14E2.8060000@network-heretics.com> <55274878.60302@andyet.net> <86ABD668F4D250D365774EFF@JcK-HP8200.jck.com>
In-Reply-To: <86ABD668F4D250D365774EFF@JcK-HP8200.jck.com>
Accept-Language: fi-FI, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: jck.com; dkim=none (message not signed) header.d=none; 
x-originating-ip: [128.214.71.180]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB371;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(51704005)(377454003)(479174004)(62966003)(92566002)(74482002)(87936001)(2656002)(66066001)(122556002)(2950100001)(2900100001)(40100003)(4001410100001)(77156002)(107886001)(54356999)(106116001)(33656002)(74316001)(76176999)(86362001)(50986999)(102836002)(15975445007)(77096005)(46102003)(19580395003)(19580405001)(93886004)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB371; H:AM3PR07MB369.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:AM3PR07MB371; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB371; 
x-forefront-prvs: 054642504A
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: 14 Apr 2015 07:36:38.6675 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB371
Archived-At: 
Subject: Re: [urn] Persistence with f-components or p-components
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Apr 2015 07:48:55 -0000

Hello,

Some comments below.

> -----Original Message-----
> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of John C Klensin
> Sent: 13. huhtikuuta 2015 22:23
> To: Peter Saint-Andre - &yet; Keith Moore; urn@ietf.org
> Subject: Re: [urn] Persistence with f-components or p-components
>=20
>=20
>=20
> --On Thursday, April 09, 2015 21:50 -0600 Peter Saint-Andre - &yet
>  wrote:
>=20
> > On 3/31/15 3:42 PM, Keith Moore wrote:
> >> John,
> >>



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

It is a good idea to provide more information about this.

> >>
> >> The text I have in mind is something like:
> >>
> >> Only the [list of components] of the URN are required to meet the
> >> "persistence" property specified in RFC 1737.
> >> Individual namespaces may, however, impose more stringent
> >> requirements on use of [other components].

This should do, although a more detailed discussion about this could be pro=
vided.=20

> >>
> >> I just don't know what should be that list of components.  I can,
> >> however, somewhat arbitrarily, suggest concrete text:
> >>
> >> Only the assigned-name and p-component of the URN are required to
> >> meet the "persistence" property specified in RFC
> >> 1737.   Individual namespaces may, however, impose additional
> >> restrictions on the use of q-component and/or f-component.

+ 1

=20

> > I think the persistence rule falls out from equivalence rule.

Equivalence is one way of deciding what should be persistent, and perhaps s=
ufficient for RFC 2141bis.=20

It is also possible to look at this from administrative point of view. Only=
 the assigned name such as ISBN has (or should have) solid administrative b=
asis. When users later add for instance f-components to URN:ISBNs in order =
to cite locations within e-books, they do that "at their own risk", even th=
ough an f-component added to a URN which identifies a single manifestation =
of a resource (such as a PDF version of a book) is likely to be more persis=
tent than fragment added to a URL.

It would be awkward to require persistence of q-components, since resolutio=
n services available and whatever is being supplied will change over time. =
For instance, if a q-component requests metadata about a resource, the meta=
data record retrieved may change from one day to the next, and even the def=
ault metadata format supplied may change (from e.g. MARC 21 to Dublin Core)=
.=20
=20
> > If we say that only the assigned-name and the p-component are taken
> > into account for purposes of determining equivalence, then I think we
> > would say that only the assigned-name and p-component are required to
> > meet the persistence property.

OK for me, but it might be a good idea to say that currently (most) standar=
d identifiers out there do not allow usage of p-component, and it is necess=
ary to investigate whether adding it would be useful.=20

Juha

> FWIW, that is consistent with the assumption I've been making.
> I've been concentrating on equivalence, but I believe the definition of
> persistence in 1737, whose key phrase appears to be "globally unique
> forever" (the other provisions cannot be enforced except as a matter of
> intent) comes down to an equivalence assertion about to what it is global=
ly
> unique.
>=20
>     john
>=20
>=20
>=20
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn


From nobody Tue Apr 14 03:43:47 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917441A8896 for ; Tue, 14 Apr 2015 03:43:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6poWMpnZ-PB5 for ; Tue, 14 Apr 2015 03:43:43 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0751.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::751]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262591A8893 for ; Tue, 14 Apr 2015 03:43:42 -0700 (PDT)
Received: from AM3PR07MB369.eurprd07.prod.outlook.com (10.242.109.143) by AM3PR07MB372.eurprd07.prod.outlook.com (10.242.109.152) with Microsoft SMTP Server (TLS) id 15.1.136.25; Tue, 14 Apr 2015 10:40:14 +0000
Received: from AM3PR07MB369.eurprd07.prod.outlook.com ([10.242.109.143]) by AM3PR07MB369.eurprd07.prod.outlook.com ([10.242.109.143]) with mapi id 15.01.0136.014; Tue, 14 Apr 2015 10:40:14 +0000
From: "Hakala, Juha E" 
To: Keith Moore , "urn@ietf.org" 
Thread-Topic: [urn] use of fragment identifiers: issues are same for urn and all urls
Thread-Index: AQHQbPTZevF8oOJ2zE6j6bkKY55W7p1MX7zg
Date: Tue, 14 Apr 2015 10:40:14 +0000
Message-ID: 
References: <4D184BB8-7E88-4284-9C5D-298E8C2753E3@adobe.com> <551CB6D4.4040801@network-heretics.com>
In-Reply-To: <551CB6D4.4040801@network-heretics.com>
Accept-Language: fi-FI, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: network-heretics.com; dkim=none (message not signed) header.d=none;
x-originating-ip: [128.214.71.180]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB372;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(54356999)(50986999)(76176999)(77156002)(107886001)(19580395003)(74316001)(62966003)(19580405001)(1720100001)(74482002)(46102003)(66066001)(4001410100001)(33656002)(15975445007)(106116001)(2656002)(2950100001)(76576001)(87936001)(92566002)(40100003)(77096005)(102836002)(122556002)(2900100001)(86362001)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB372; H:AM3PR07MB369.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:AM3PR07MB372; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB372; 
x-forefront-prvs: 054642504A
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: helsinki.fi
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2015 10:40:14.0562 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB372
Archived-At: 
Subject: Re: [urn] use of fragment identifiers: issues are same for urn and all urls
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Apr 2015 10:43:45 -0000

SGVsbG8sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdXJuIFttYWls
dG86dXJuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLZWl0aCBNb29yZQ0KPiBTZW50
OiAyLiBodWh0aWt1dXRhIDIwMTUgNjoyNg0KPiBUbzogdXJuQGlldGYub3JnDQo+IFN1YmplY3Q6
IFJlOiBbdXJuXSB1c2Ugb2YgZnJhZ21lbnQgaWRlbnRpZmllcnM6IGlzc3VlcyBhcmUgc2FtZSBm
b3IgdXJuIGFuZCBhbGwNCj4gdXJscw0KPiANCj4gSSBqdXN0IHJlYWxpemVkIHRoYXQgdGhlcmUn
cyBvbmUgbW9yZSBpc3N1ZSBoZXJlOg0KPiA+IFRoZSBVUkwgYW5kIFVSTg0KPiA+IGh0dHA6Ly90
b29scy5pZXRmLm9yZy9odG1sL2JjcDExNSAgIGFuZCB1cm46aWV0ZjpiY3A6MTE1DQo+ID4NCj4g
PiBhcmUgYm90aCBub3QgZ29vZCBVUklzIHRvIHB1dCBhICNzZWN0aW9uLTMgZnJhZ21lbnQgb24s
IGJlY2F1c2Ugd2hlbiBhbg0KPiB1cGRhdGUgdG8gQkNQIDExNSBpcyBtYWRlLCBTZWN0aW9uIDMg
bWlnaHQgYmUgYSB0b3RhbGx5IGRpZmZlcmVudCB0b3BpYy4NCg0KVGhlIHByb2JsZW0gaGVyZSBp
cyBub3QgdGhlIHVzZSBvZiBmcmFnbWVudCBhcyBzdWNoLCBidXQgbmFtaW5nIHBvbGljeSB1c2Vk
IGluIHVybjppZXRmIG5hbWVzcGFjZS4gDQoNCkl0IGlzIE9LIHRvIGhhdmUgYW4gaWRlbnRpZmll
ciB3aGljaCBjb3ZlcnMgYWxsIHBhc3QgYW5kIGZ1dHVyZSB2ZXJzaW9ucyBvZiBCQ1AgMTE1LiBT
dWNoIG5hbWVzcGFjZSB3aWxsIG9mIGNvdXJzZSBub3QgcHJvdmlkZSByZWxpYWJsZSBiYXNpcyBm
b3IgZnJhZ21lbnQgdXNhZ2UsIGJ1dCBpdCBjYW4gYmUgdXNlZCB0byBmaW5kIGFsbCB2ZXJzaW9u
cyBvZiB0aGUgZG9jdW1lbnQgKGFuZCBwZXJoYXBzIGFsc28gcmVsYXRlZCBkb2N1bWVudHMsIGlm
IHRoZXkgYXJlIGludGVybGlua2VkIGluIG1ldGFkYXRhIHJlY29yZHMpLiBCdXQgdGhlcmUgc2hv
dWxkIGFsc28gYmUgYSBVUk4gKGZyb20gYW5vdGhlciBuYW1lc3BhY2UpIGZvciBlYWNoIHZlcnNp
b24sIHNvIHRoYXQgcGVvcGxlIHdobyBuZWVkIHRvIHJlZmVyIHRvIGEgcGFydGljdWxhciB2ZXJz
aW9uIG9mIEJDUCAxMTUgY2FuIGRvIHRoYXQsIGFuZCBhbHNvIGNpdGUgIGZvciBpbnN0YW5jZSBz
ZWN0aW9uIDMuIEN1cnJlbnRseSwgaWYgSSB3YW50IHRvIHByb3ZpZGUgYSBsaW5rIHRvIHRoZSB2
ZXJzaW9uIHdoaWNoIHdhcyB2YWxpZCBpbiBNYXJjaCAyMDE1IEkgY2FuIHVzZSB0aGlzIFVSSSAN
Cg0KaHR0cHM6Ly93ZWIuYXJjaGl2ZS5vcmcvd2ViLzIwMTUwMzI0MDAyMTEzL2h0dHA6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2JjcDExNQ0KDQpidXQgaXQgd291bGQgbW9yZSBjb252ZW5pZW50IHRv
IGhhdmUgYSB2ZXJzaW9uIHNwZWNpZmljIFVSTiB3aGljaCByZXNvbHZlcyB0byB0aGlzIFVSTCBp
biB0aGUgSW50ZXJuZXQgQXJjaGl2ZSAob3Igb3RoZXIgcGxhY2VzIGZyb20gd2hpY2ggdGhlIGFw
cHJvcHJpYXRlIHZlcnNpb24gY2FuIGJlIGZvdW5kKS4gIA0KDQo+ID4NCj4gPg0KPiA+IFRoZSBV
UkwgYW5kIFVSTg0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0Mzk1ICBhbmQg
dXJuOmlldGY6cmZjOjQzOTUNCj4gPg0KPiA+IHNob3VsZCBib3RoIGJlIGdvb2QgZm9yIGEgI3Nl
Y3Rpb24tMyBmcmFnbWVudC4gVGhlIGxhdHRlciBiZWNhdXNlIHRoZXJlIGlzDQo+IGEgY3JlZGli
bGUgcG9saWN5IG9mIG5vdCBtZXNzaW5nIHdpdGggIFJGQ3Mgb25jZSB0aGV54oCZcmUgcHVibGlz
aGVkLCBhbmQNCj4gc2VjdGlvbiBudW1iZXJzIHdpbGwgcmVtYWluIGV2ZW4gaWYgUkZDcyBhcmUg
cmVwdWJsaXNoZWQgaW4gZGlmZmVyZW50IGZvcm1hdHMuDQo+ID4gSSB0aGluayBiZWluZyBjYXJl
ZnVsIGluIHRoaXMga2luZCBvZiBjb21taXRtZW50IG5lZWRzIHRvIGJlIHBhcnQgb2YNCj4gbmFt
ZXNwYWNlIGF1dGhvcml0eSByZWNvZ25pdGlvbiB3aGVuIGNvbnNpZGVyaW5nIGFwcGxpY2FiaWxp
dHkgYW5kDQo+IGxvbmdldml0eSBvZiBmcmFnbWVudCBpZGVudGlmaWVycy4NCg0KSXQgc2hvdWxk
IG5vdCBiZSBoYXJkIHRvIGFsbG9jYXRlIGlkZW50aWZpZXJzIGZvciBJRVRGIGRvY3VtZW50cyBp
biBzdWNoIGEgd2F5IHRoYXQgdGhlIHVzZXJzIHdpbGwgZmluZCB3aGF0IHRoZXkgd2FudC4gDQoN
Cj4gVGhlIHByb2JsZW0gaXMsIGZvciBzb21lIHBlcmlvZCBvZiB0aW1lOg0KPiBhKSBCb3RoIG9m
IHRoZSBhYm92ZSBVUk5zIHJlZmVyIHRvIHRoZSBzYW1lIGRvY3VtZW50DQo+IGIpIEF0IGxlYXN0
IG9uZSB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCBtYXkgY29udGFpbiBmcmFnbWVudHMNCj4gYykg
VGhlIGlldGYgbmFtZXNwYWNlIGRvZXNuJ3QgY29udHJvbCB3aGV0aGVyIGZyYWdtZW50cyBnZXQg
YWRkZWQgdG8gaXRzDQo+IFVSTnMgLiBBbnlvbmUgY2FuIGNvbXBvc2UgYSBVUkkgY29uc2lzdGlu
ZyBvZiB1cm46aWV0ZjpiY3A6MTE1IGFuZCBhDQo+IGZyYWdtZW50IGlkZW50aWZpZXIgZnJvbSBy
ZmMgNDM5NSwgYW5kIGl0IHdpbGwgd29yayBpbiB0aGUgbmVhciB0ZXJtLg0KPiANCj4gU28gaWYg
SUVURiB3YW50cyB0byBtYWtlIGl0cyAoVVJOICsgZnJhZ21lbnQgaWRlbnRpZmllcikgY29tYmlu
YXRpb25zDQo+IHBlcnNpc3RlbnQsIGl0IGhhcyB0d28gY2hvaWNlczoNCj4gYSkgZG9uJ3QgYXNz
aWduIEJDUCBVUk5zDQo+IGIpIGRvbid0IHB1dCBmcmFnbWVudCBpZGVudGlmaWVycyBpbiBhbnkg
dmVyc2lvbiBvZiBpdHMgZG9jdW1lbnRzDQo+IA0KPiBOZWl0aGVyIGNob2ljZSBzZWVtcyB2ZXJ5
IGF0dHJhY3RpdmUuDQoNClRoZSBiZXN0IGNob2ljZSBpcyB0byBwbGFuIGlkZW50aWZpZXIgdXNh
Z2Ugc28gdGhhdCBhbGwgdGhlIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnRzIGNhbiBiZSBtZXQuIEkg
YW0gc3VyZSBJRVRGIGhhcyBzb2x2ZWQgaGFyZGVyIHByb2JsZW1zIHRoYW4gdGhpcy4gQnV0IGlm
IG5vdGhpbmcgZWxzZSBoZWxwcywgYXNrIGEgbGlicmFyaWFuIDstKS4NCg0KSnVoYQ0KPiANCj4g
S2VpdGgNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQo+IHVybiBtYWlsaW5nIGxpc3QNCj4gdXJuQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vdXJuDQo=


From nobody Tue Apr 14 08:36:31 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CF41B2CE4 for ; Tue, 14 Apr 2015 08:36:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.29
X-Spam-Level: 
X-Spam-Status: No, score=0.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFenZStB3MZK for ; Tue, 14 Apr 2015 08:36:28 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69BE11B2D10 for ; Tue, 14 Apr 2015 08:35:45 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Yi2sE-0000Vo-MD; Tue, 14 Apr 2015 11:35:38 -0400
Date: Tue, 14 Apr 2015 11:35:33 -0400
From: John C Klensin 
To: "Hakala, Juha E" 
Message-ID: 
In-Reply-To: 
References: <55142CA1.2000509@network-heretics.com>  <551B14E2.8060000@network-heretics.com> <55274878.60302@andyet.net> <86ABD668F4D250D365774EFF@JcK-HP8200.jck.com> 
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Cc: urn@ietf.org, Keith Moore , Peter Saint-Andre - &yet 
Subject: Re: [urn] Persistence with f-components or p-components
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Apr 2015 15:36:29 -0000

--On Tuesday, April 14, 2015 07:36 +0000 "Hakala, Juha E"
 wrote:

>...
>> >> I'm simply asking for one or two sentences to be added to
>> >> rfc2141bis to clarify which of f-component, p-component,
>> >> and q-component are relevant when considering persistence.
>> >> RFC 2141 didn't need to address this issue because with
>> >> RFC 2141 URNs, the entire URN was assigned, so the
>> >> persistence property applied to the entire URN.
> 
> It is a good idea to provide more information about this.
> 
>> >> 
>> >> The text I have in mind is something like:
>> >> 
>> >> Only the [list of components] of the URN are required to
>> >> meet the "persistence" property specified in RFC 1737.
>> >> Individual namespaces may, however, impose more stringent
>> >> requirements on use of [other components].
> 
> This should do, although a more detailed discussion about this
> could be provided. 

Proposal, given changes already incorporated in -11 of 2141bis.
If the WG decides to undo those changes, something more drastic
will be needed.

	(i) Rename the present Section 4 to "Equivalence and
	Persistence of URNs".
	
	(ii) Add a new subsection 4.2, incrementing the number
	for the current 4.2 to 4.3, titled "URN Persistence"
	that reads:
	
	For consistency with the "persistence" property
	[RFC1737] and as a logical consequence of the
	equivalence procedure described immediately above, only
	the  (see Section 3 above) are
	necessarily treated as persistent.  Individual
	namespaces may, however, impose more stringent
	requirements on the use of q-components or f-components.

I'm not sure whether the final sentence above is needed or not
or whether, if we include it, it will touch off another battle
about what we are allowed to say about fragments.  It can,
obviously, be easily removed if it is more trouble than it is
worth.   Alternate phrasing and/or nit-picking welcome, but the
above ties persistence explicitly and strongly to URN
equivalence as Peter and I have suggested elsewhere. 

Is something like that sufficient for us to move on? Vis-a-vis a
more detailed discussion, I don't know quite what to say, so, if
more is needed, please send either text or a detailed outline
(or ask Melinda and Andy to put it on Friday's agenda).

>...
>> Individual namespaces may, however, impose
>> >> additional restrictions on the use of q-component and/or
>> >> f-component.
> 
> + 1

Incorporated into the above suggestion, but see the comment
there.

>...
>> > I think the persistence rule falls out from equivalence
>> > rule.
> 
> Equivalence is one way of deciding what should be persistent,
> and perhaps sufficient for RFC 2141bis. 
> 
> It is also possible to look at this from administrative point
> of view. Only the assigned name such as ISBN has (or should
> have) solid administrative basis. When users later add for
> instance f-components to URN:ISBNs in order to cite locations
> within e-books, they do that "at their own risk", even though
> an f-component added to a URN which identifies a single
> manifestation of a resource (such as a PDF version of a book)
> is likely to be more persistent than fragment added to a URL.

That "administrative" explanation is the reason I've sort of
resisted making explicit statements about persistence in 2141bis
or elsewhere.   Clearly it would be possible to explain
persistence on that basis.  IMO, it would be more satisfactory
in some ways.  However, I don't believe that it would be
consistent with what RFC 1737 has to say.  I've got other issues
with that document, most of which come down to "we've learned
some things in 20 years", but really don't want to reopen if if
that can be avoided.
 
> It would be awkward to require persistence of q-components,
> since resolution services available and whatever is being
> supplied will change over time. For instance, if a q-component
> requests metadata about a resource, the metadata record
> retrieved may change from one day to the next, and even the
> default metadata format supplied may change (from e.g. MARC 21
> to Dublin Core).   

Yes.

>> > If we say that only the assigned-name and the p-component
>> > are taken into account for purposes of determining
>> > equivalence, then I think we would say that only the
>> > assigned-name and p-component are required to meet the
>> > persistence property.
> 
> OK for me, but it might be a good idea to say that currently
> (most) standard identifiers out there do not allow usage of
> p-component, and it is necessary to investigate whether adding
> it would be useful. 

Today, no standard identifier allows usage of any of p-, q-, or
f-component (although the "fragment" discussion may interact
with the latter) because such usage violates RFC 2141
restrictions.  Especially for established namespaces (and again
modulo the "fragement" issues), none of these qualifying
decorations should be added unless they are useful.  At least
without more clarity about which components serve which roles in
URN processing, evaluation, and/or resolution, p- and
f-components are, IMO, more likely to be problematic than
f-components (that has been said in the WG in various forms for
two years now).   How much of that do you think we need to say
explicitly?

best,
   john



From nobody Tue Apr 14 08:49:01 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532E01B2D58 for ; Tue, 14 Apr 2015 08:49:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.61
X-Spam-Level: 
X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6A7oMaEU6mZc for ; Tue, 14 Apr 2015 08:48:58 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD1C61B2D56 for ; Tue, 14 Apr 2015 08:48:58 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Yi355-0000Xs-Fv; Tue, 14 Apr 2015 11:48:55 -0400
Date: Tue, 14 Apr 2015 11:48:50 -0400
From: John C Klensin 
To: "Hakala, Juha E" , Keith Moore , urn@ietf.org
Message-ID: 
In-Reply-To: 
References: <4D184BB8-7E88-4284-9C5D-298E8C2753E3@adobe.com> <551CB6D4.4040801@network-heretics.com> 
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Subject: Re: [urn] use of fragment identifiers: issues are same for urn and all urls
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Apr 2015 15:49:00 -0000

--On Tuesday, April 14, 2015 10:40 +0000 "Hakala, Juha E"
 wrote:

>> I just realized that there's one more issue here:
>> > The URL and URN
>> > http://tools.ietf.org/html/bcp115   and urn:ietf:bcp:115
>> > 
>> > are both not good URIs to put a #section-3 fragment on,
>> > because when an
>> update to BCP 115 is made, Section 3 might be a totally
>> different topic.
> 
> The problem here is not the use of fragment as such, but
> naming policy used in urn:ietf namespace. 
> 
> It is OK to have an identifier which covers all past and
> future versions of BCP 115. Such namespace will of course not
> provide reliable basis for fragment usage, but it can be used
> to find all versions of the document (and perhaps also related
> documents, if they are interlinked in metadata records). But
> there should also be a URN (from another namespace) for each
> version, so that people who need to refer to a particular
> version of BCP 115 can do that, and also cite  for instance
> section 3. Currently, if I want to provide a link to the
> version which was valid in March 2015 I can use this URI 
> 
> https://web.archive.org/web/20150324002113/http://tools.ietf.o
> rg/html/bcp115
> 
> but it would more convenient to have a version specific URN
> which resolves to this URL in the Internet Archive (or other
> places from which the appropriate version can be found). 

Of course, we have such an identifier today.  It is 

   urn:ietf:rfc:3999

(assuming a relatively persistent binding between a BCP number
that doesn't identify anything and an RFC number that doesn't
either).  But, for example,
   urn:ietf:bcp:102
refers to an object that may change over time and
   urn:ietf:rfc:4052

refers to the version in effect today.  As with other examples,
fragments applied to the latter are much more likely to be
useful and to match what was intended than fragments that are
applied to the former.

I think one could make persistence arguments that urn:ietf:bcp
should not be allowed at all, but that is an administrative,
registration, and policy matter, not an 2141bis (or 2141 or even
1737) one.  It also involves the same long-standing and much
discussed examples about a URN for the local weather at the
present time.  We aren't going to solve those problems on a
philosophical level even though some conventions and a good
understanding of what is going on will eliminate the practical
issues.

best,
   john


From nobody Tue Apr 14 09:00:48 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E458C1B2DA7 for ; Tue, 14 Apr 2015 09:00:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gd3_5F_-WLWE for ; Tue, 14 Apr 2015 09:00:45 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7A81B2D79 for ; Tue, 14 Apr 2015 08:59:36 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 05DD82100C for ; Tue, 14 Apr 2015 11:59:36 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Tue, 14 Apr 2015 11:59:36 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=NcgS2kiYkcIVaIl UmcWnKXweF2M=; b=Qk5l2u4WiKj/dyedQi0AXh9lOuDl3zwlLFStLtNRUFcmzpu 9iyGCdyokT0BQNl4p5gIEIvzLpGlTshoRVeYwkLfHZkv42wMefCNVnyN7LWJWgll aBnoOv/LmYPDTzHxnvSWQHdUet6Y6lGBsiqDKOwKbMIg0Kb5G0aDFdMkeEBg=
X-Sasl-enc: KwkwFYYzPrwajRhrDzIU7vUGciuhh/o8T4Y3+AQGDsDP 1429027175
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 7891E6800F1; Tue, 14 Apr 2015 11:59:35 -0400 (EDT)
Message-ID: <552D3958.9040900@network-heretics.com>
Date: Tue, 14 Apr 2015 11:59:20 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: John C Klensin ,  "Hakala, Juha E" 
References: <55142CA1.2000509@network-heretics.com>  <551B14E2.8060000@network-heretics.com> <55274878.60302@andyet.net> <86ABD668F4D250D365774EFF@JcK-HP8200.jck.com>  
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: urn@ietf.org, Peter Saint-Andre - &yet 
Subject: Re: [urn] Persistence with f-components or p-components
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Apr 2015 16:00:47 -0000

On 04/14/2015 11:35 AM, John C Klensin wrote:
> Proposal, given changes already incorporated in -11 of 2141bis.
> If the WG decides to undo those changes, something more drastic
> will be needed.
>
> 	(i) Rename the present Section 4 to "Equivalence and
> 	Persistence of URNs".
> 	
> 	(ii) Add a new subsection 4.2, incrementing the number
> 	for the current 4.2 to 4.3, titled "URN Persistence"
> 	that reads:
> 	
> 	For consistency with the "persistence" property
> 	[RFC1737] and as a logical consequence of the
> 	equivalence procedure described immediately above, only
> 	the  (see Section 3 above) are
> 	necessarily treated as persistent.  Individual
> 	namespaces may, however, impose more stringent
> 	requirements on the use of q-components or f-components.

Absent the last sentence, I'm tentatively ok with this.   If we're going 
to permit bundling of URNs and "fragments" (in the sense that they 
currently exist) it seems safer to not require that the combination be 
persistent.

I'm not sure about the last sentence because I remain concerned about 
having interpretation of any of these components be specified on a 
per-namespace basis.    Also, if neither f-components nor q-components 
are part of the "assigned" portion of the URN, I'm not sure what a 
namespace has to say about them.

Keith


From nobody Tue Apr 14 09:07:51 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4FD1B2DB2 for ; Tue, 14 Apr 2015 09:07:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdOX4LRfKg2V for ; Tue, 14 Apr 2015 09:07:45 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ABE61B2E2A for ; Tue, 14 Apr 2015 09:05:21 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 16DB520533 for ; Tue, 14 Apr 2015 12:05:19 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 14 Apr 2015 12:05:20 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=182rRjfVWhpSX4t XNNBNKI1MiFM=; b=pUOso+gTDdGCwnc+N6clxQVF8JJ+J8hbRr8nu4W77Lyxma5 HvGwQGVF+72aKXeDercKUXpkTd5beH1Ckjg0sk9xKfLYdiIyUxx11//RyNAXmk3h VWxyoqSQklV9aNdo5T9K3NR9i/MbotHiEISGTTzi4kfuIpuIbXhKUCjLeVTw=
X-Sasl-enc: rgTebpztQh+16hl9+Ywe3ldA6uG8CEslrFspfI/qnmL6 1429027519
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 83DE7C00015; Tue, 14 Apr 2015 12:05:19 -0400 (EDT)
Message-ID: <552D3AB0.4060006@network-heretics.com>
Date: Tue, 14 Apr 2015 12:05:04 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com>
In-Reply-To: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Apr 2015 16:07:50 -0000

On 04/13/2015 04:10 PM, John C Klensin wrote:
> Hi.
>
> Those who have been following the apps-discuss list and the Apps
> Area WG has seen a long, difficult, and sometimes unpleasant
> thread about what a URN specification (or any other
> specification for a particular URI scheme) is allowed to say
> about fragments.  The discussion appears to extend to whether
> fragments can be disallowed at all by a scheme (if they cannot,
> 2141 has problems quite independent of what we might do), to
> whether a scheme can constrain fragment syntax in any way, and
> to whether scheme-specific or namespace-specific restrictions or
> semantic [1] rules are allowed.
>
> Similar issues arise with p-components.   If a p-component
> (i.e., introduced by a "/", at least before a q-component or
> f-component) appears in a URN, it is claimed to be impossible
> [2] to avoid relative resolution, something that might cause
> havoc or other damage with URNs.
>
> An obvious question is why we don't just disallow one or both
> and move on.
>
> For me, the answer is tied up with the question I've been asking
> about the difference between instructions or qualifiers that are
> part of the URN (see below) and instructions or qualifiers that
> are intended to be passed to whatever the URN points to or
> resolves to.   If no one else sees that as an issue, or believes
> that we can reasonable handle it on a per-namespace basis (that
> fragment discussion definitely would complicate handling those
> on a per-namespace basis), please explain why and I'd drop this.
> If others are concerned and believe we should handle that issue
> using syntax, then I believe we need to consider three cases.
> (I don't see any alternative to distinguishing by syntax if we
> aren't going to make the distinction per-namespace, but maybe
> I'm missing something):
>
> I'm going to use the term "qualifier" below to identify things
> that are not inherently part of the NSS (using the syntax in
> 2141bis-11) but that are part of the .
>
>   Case 1: The qualifier is part of the URN to the extent
> 	that it is included in comparisons and affects
> 	persistence.  As part of the URN, it is expected to
> 	affect or provide information to a URN processor or
> 	resolver.
> 	
>   Case 2: The qualifier is part of the URN in the sense
> 	that if affects or provides information to a URN
> 	processor or resolver, but does not participate in
> 	equality comparisons.    Information about locale (so a
> 	URN resolver could find the most convenient object or a
> 	pointer to it) would presumably fall into this category.
> 	I think distinctions between object and various types of
> 	metadata would too, but could be talked out of that.
> 	
>   Case 3: The qualifier is not part of the URN but
> 	contains information or specifications that should be
> 	passed on to the URN's target if that is meaningful.
> 	The qualifier is probably not meaningful if there is no
> 	resolution and no target.

I think there are actually four categories of "qualifier":

1. Qualifiers that potentially represent portions of resources, and/or 
relationships with other resources named with URNs, that should be 
included in comparisons and considered relevant for persistence.

2. Qualifiers that identify portions of resources that should not be 
included in comparisons or when considering persistence.

3. Qualifiers that are transmitted to resources (when applicable) for 
interpretation by the resources.   These should not be included in 
comparisons or when considering persistence.

4. Qualifiers that affect resolution of the URN, and which should be 
transmitted to the resolution service if one is used, either to request 
a specific kind of resolution service, or to narrow down between 
multiple versions and/or representations of the content.

So even without considering 3986 relative reference issues, it's a bit 
difficult to shoehorn 4 kinds of qualifiers into the three kinds of 
modifiers available in 3986 syntax.

There are at least two additional sets of considerations that further 
complicate things:

a) if 3986-style relative references in a resource are interpreted 
relative to URNs, that constrains how f-components, p-components, and 
q-components can be used - particularly when the same resources are also 
reachable via ordinary URLs that already assign meanings to these 
qualifiers.

b) there is considerable mindshare around what '#', '/', and '?' mean 
when they appear in URIs, based on widespread experience with HTTP[S] 
URLs, and it will be confusing if URNs adopt meanings for these that 
conflict with those used in HTTP[S].

Keith


From nobody Tue Apr 14 11:06:30 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302CB1A1B65 for ; Tue, 14 Apr 2015 11:06:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXkq6hcnjsuz for ; Tue, 14 Apr 2015 11:06:25 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A7271A1ABC for ; Tue, 14 Apr 2015 11:06:25 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Yi5E5-0000ti-F0; Tue, 14 Apr 2015 14:06:21 -0400
Date: Tue, 14 Apr 2015 14:06:16 -0400
From: John C Klensin 
To: Keith Moore , urn@ietf.org
Message-ID: 
In-Reply-To: <552D3AB0.4060006@network-heretics.com>
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Apr 2015 18:06:28 -0000

Keith,

This is very helpful.  I was trying to keep the count to three
precisely because what was obviously available in syntax.  I
interpret that narrowly and, e.g., assume that "role" implies
"semantics" unless it is an absolute lexical property.  As a
specific example, it is a statement about syntax to say that "#"
has a role, which is to delimit and denote the beginning of a
syntax element called a .  Statements about how
 is used or applied or about the relationship between
the syntax element specified in a production as  and
the English word "fragment" are all semantics.

More inline and below.

--On Tuesday, April 14, 2015 12:05 -0400 Keith Moore
 wrote:

> I think there are actually four categories of "qualifier":
> 
> 1. Qualifiers that potentially represent portions of
> resources, and/or relationships with other resources named
> with URNs, that should be included in comparisons and
> considered relevant for persistence.
> 
> 2. Qualifiers that identify portions of resources that should
> not be included in comparisons or when considering persistence.
> 
> 3. Qualifiers that are transmitted to resources (when
> applicable) for interpretation by the resources.   These
> should not be included in comparisons or when considering
> persistence.
> 
> 4. Qualifiers that affect resolution of the URN, and which
> should be transmitted to the resolution service if one is
> used, either to request a specific kind of resolution service,
> or to narrow down between multiple versions and/or
> representations of the content.
> 
> So even without considering 3986 relative reference issues,
> it's a bit difficult to shoehorn 4 kinds of qualifiers into
> the three kinds of modifiers available in 3986 syntax.

However, as far as I can tell, there have only been four types
of suggestions on the WG list.  If you (or others) know of, or
have, others, this would be a good time to speak up.  In no
particular order:

(i) Force things into three categories of qualifiers and bind
each category to a "component" type, using as close a match to
the 3986 (and HTTP) assumptions about how those components are
used as feasible.

(ii) Declare everything to be per-namespace that doesn't
actually violate the 3986 syntax constraints (again, using
"syntax" narrowly) and move on.  I think I understand your
concerns about that and share at least some of them.

(iii) Forget p-components and f-components as posing the most
issues for generic URI processing and user expectations and
impose urn-scheme-specific conventions on q-components to allow
distinguishing among my three cases or your four.  There are a
number of possible ways to subdivide the q-component that way.
The two most obvious, both of which we have discussed on the
list, involving forcing name value pairs with some reserved
keywords and using some delimiters in very specific ways.  One
obvious bit of bad news about this approach is that, if anything
in your first category is allowed outside the NSS (as defined in
2141bis-11) then it will be necessary to parse and subdivide the
q-component in order to make an equivalence (or persistence)
determination.

(iv) Give it up and stick with 2141, i.e., urn namestrings
consist only of "urn:" plus NID plus NSS; no p-, q-, or
f-components; and a prohibition on any of "/", "?", or "#"
appearing within the NSS except in %-encoded form.  In part
because such things are in use already, we can be quite
confident that, whether the result was a conflicting standard or
not, the IETF's advise on that subject would be ignored or
explicitly contradicted.

Again, do you see other options and, if not, which one do you
consider the least bad?


> There are at least two additional sets of considerations that
> further complicate things:
> 
> a) if 3986-style relative references in a resource are
> interpreted relative to URNs, that constrains how
> f-components, p-components, and q-components can be used -
> particularly when the same resources are also reachable via
> ordinary URLs that already assign meanings to these qualifiers.

Only if there is an established mapping relationship between a
URN and some URL type, such as the frequently-cited relationship
between, e.g.,
    urn:ietf:rfc:1373    and
    https://datatracker.ietf.org/doc/rfc1737/
The latter, interestingly, points to a metadata page, not the
document-resource.  If the relationship were to 
    http://www.rfc-editor.org/rfc/rfc1737.txt       or
    ftp://ftp.rfc-editor.org/in-notes/rfc1737.txt
it would identify the document.

See below.

> b) there is considerable mindshare around what '#', '/', and
> '?' mean when they appear in URIs, based on widespread
> experience with HTTP[S] URLs, and it will be confusing if URNs
> adopt meanings for these that conflict with those used in
> HTTP[S].

I think we can go one of two ways here.  One is to say "URNs are
not URLs, much less HTTP[s] URLs" and that, for a lot of the
purposes for which the distinction is useful, our long-ago
decisions to have a unified syntax and theory of URIs still
requires that, for many URN purposes (including some of those
contemplated in 1737 and the discussions surrounding it), users
are going to need to be familiar with the difference.  The other
is to say "URNs really are URLs, just a different shorthand form
from relative references.  The latter actually allows a
universal resolver in the form of something that would maintain
a per-NID that provides rules (perhaps in regex form) for
getting from any given NID-NSS combination to a corresponding
URL, presumably with any qualifying information just passed into
the URL.  I don't see a third choice.  Do you?

 Many of these discussions are convincing me that we
made a fundamentally incorrect design decision when we decided
that URLs and URNs were just too subspecies of a fundamental
"URI" concepts and that they should share the same syntax and
maybe most semantics.  In retrospect, we would have been better
off, especially from human interface design perspectives, had we
made the two sufficiently different in naming and/or syntax that
the immediate user inference would be "these are two different
things" rather than "these things are nearly the same and I can
extrapolate from what I know about one to the other one".  It
would also mean that an application design would need to decide
whether to accept URLs, URNs, or both and that discussions about
putting URNs into URL (or URI) slots would have a lot of
characteristics in common with pounding square pegs into round
holes.  I see no way to go back and change things at this point,
but many of these discussions, the difficulties that are being
identified, and the proposed solutions are feeling more and more
like creating ever more complex epicycles around a URL-centered
universe.


   john





From nobody Tue Apr 14 19:50:29 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA971B29D9 for ; Tue, 14 Apr 2015 19:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJjSbTSXffm7 for ; Tue, 14 Apr 2015 19:50:25 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72FD61AD357 for ; Tue, 14 Apr 2015 19:50:25 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9C75220C16 for ; Tue, 14 Apr 2015 22:50:24 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Tue, 14 Apr 2015 22:50:24 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=00+eDwouGn0Uwds Jse1lrpsg6eA=; b=a6Fz/WXUO+qe4QsfSZzvtVDUdp7iODQR91z4IuwYPECfUDL Mw46PaWkjVXha8y8qR6M/WvSJbrTpYfHuskMWuFYLOcyYfr3lRraosG+mD02gXRX PiqglujRUiqpbqeCdWIyPl2quzj37tLcKB8FNeVE1JV+sVPUXcxgrtlsuxds=
X-Sasl-enc: XrYBf5zr+jg/AJuTHy9SelwZUdulAZFwzoG8mY7wTfkl 1429066224
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id DEAC66800F1; Tue, 14 Apr 2015 22:50:23 -0400 (EDT)
Message-ID: <552DD1DF.5010906@network-heretics.com>
Date: Tue, 14 Apr 2015 22:50:07 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Apr 2015 02:50:28 -0000

On 04/14/2015 02:06 PM, John C Klensin wrote:
>
> --On Tuesday, April 14, 2015 12:05 -0400 Keith Moore
>  wrote:
>
>> I think there are actually four categories of "qualifier":
>>
>> 1. Qualifiers that potentially represent portions of
>> resources, and/or relationships with other resources named
>> with URNs, that should be included in comparisons and
>> considered relevant for persistence.
>>
>> 2. Qualifiers that identify portions of resources that should
>> not be included in comparisons or when considering persistence.
>>
>> 3. Qualifiers that are transmitted to resources (when
>> applicable) for interpretation by the resources.   These
>> should not be included in comparisons or when considering
>> persistence.
>>
>> 4. Qualifiers that affect resolution of the URN, and which
>> should be transmitted to the resolution service if one is
>> used, either to request a specific kind of resolution service,
>> or to narrow down between multiple versions and/or
>> representations of the content.
>>
>> So even without considering 3986 relative reference issues,
>> it's a bit difficult to shoehorn 4 kinds of qualifiers into
>> the three kinds of modifiers available in 3986 syntax.
> However, as far as I can tell, there have only been four types
> of suggestions on the WG list.  If you (or others) know of, or
> have, others, this would be a good time to speak up.  In no
> particular order:
>
> (i) Force things into three categories of qualifiers and bind
> each category to a "component" type, using as close a match to
> the 3986 (and HTTP) assumptions about how those components are
> used as feasible.
>
> (ii) Declare everything to be per-namespace that doesn't
> actually violate the 3986 syntax constraints (again, using
> "syntax" narrowly) and move on.  I think I understand your
> concerns about that and share at least some of them.
>
> (iii) Forget p-components and f-components as posing the most
> issues for generic URI processing and user expectations and
> impose urn-scheme-specific conventions on q-components to allow
> distinguishing among my three cases or your four.  There are a
> number of possible ways to subdivide the q-component that way.
> The two most obvious, both of which we have discussed on the
> list, involving forcing name value pairs with some reserved
> keywords and using some delimiters in very specific ways.  One
> obvious bit of bad news about this approach is that, if anything
> in your first category is allowed outside the NSS (as defined in
> 2141bis-11) then it will be necessary to parse and subdivide the
> q-component in order to make an equivalence (or persistence)
> determination.
>
> (iv) Give it up and stick with 2141, i.e., urn namestrings
> consist only of "urn:" plus NID plus NSS; no p-, q-, or
> f-components; and a prohibition on any of "/", "?", or "#"
> appearing within the NSS except in %-encoded form.  In part
> because such things are in use already, we can be quite
> confident that, whether the result was a conflicting standard or
> not, the IETF's advise on that subject would be ignored or
> explicitly contradicted.
>
> Again, do you see other options and, if not, which one do you
> consider the least bad?

I'm looking into a variant of (iii) in which a q-component (while still 
adhering to 3986 syntax) can itself be parsed into a portion which 
affects resolution and a portion which can get transmitted to the 
resource for interpretation by the resource.   f-components can still be 
used to refer to fragments of resource content.    Whether p-components 
can be used depends in part on other factors.   (If they are used by a 
namespace then the namespace has to impose certain constraints in 
resources with NSSs that have p-components, and I think those 
constraints might be tricky to define even if they are easy for some 
namespaces to conform to).

>
>
>> There are at least two additional sets of considerations that
>> further complicate things:
>>
>> a) if 3986-style relative references in a resource are
>> interpreted relative to URNs, that constrains how
>> f-components, p-components, and q-components can be used -
>> particularly when the same resources are also reachable via
>> ordinary URLs that already assign meanings to these qualifiers.
> Only if there is an established mapping relationship between a
> URN and some URL type, such as the frequently-cited relationship
> between, e.g.,
>      urn:ietf:rfc:1373    and
>      https://datatracker.ietf.org/doc/rfc1737/
> The latter, interestingly, points to a metadata page, not the
> document-resource.  If the relationship were to
>      http://www.rfc-editor.org/rfc/rfc1737.txt       or
>      ftp://ftp.rfc-editor.org/in-notes/rfc1737.txt
> it would identify the document.

I think the two good options for handling of relative references are:

(a) permit relative references to base URNs, but impose constraints on 
URNs that contain p-components
(b) don't permit relative references to base URNs - if a URN is used to 
access content that contains relative references, a base URL must either 
appear in the content itself or be obtained during the resolution 
process.   Then '/'s could appear in URNs, but there's no significance 
to them.   (aside: I think it would be nice if DOIs could map cleanly 
into URN space without %-encoding.)

I'm leaning to the latter at the moment, because ultimately I think it 
is cleaner to avoid having 3986 rules for relative references be used to 
manipulate URNs.  You really don't want URNs (at least the assigned 
portions of URNs) to have any more exposed structure than absolutely 
necessary.   Except for being able to recognize them as URNs by their 
prefixes, and to identify the namespace (for purposes of finding a 
resolution service), most software should be able to treat URNs as 
opaque tokens.

Option (b) provides a "established mapping relationship":   Some of the 
metadata for a particular URN could specify which URL(s) at which the 
named resource's content can be accessed (when applicable), and the 
URL(s) chosen should be actually point to the content rather than a 
metadata page.   The "established mapping relationship" would be 
provided by the resolution services.

It's possible to consider a hybrid between (a) and (b): path-relative 
references can appear in URNs that contain p-components as long as those 
namespaces adhere to certain constraints.   But I think this would 
mostly serve to make URN behavior more confusing.

>
> See below.
>
>> b) there is considerable mindshare around what '#', '/', and
>> '?' mean when they appear in URIs, based on widespread
>> experience with HTTP[S] URLs, and it will be confusing if URNs
>> adopt meanings for these that conflict with those used in
>> HTTP[S].
> I think we can go one of two ways here.  One is to say "URNs are
> not URLs, much less HTTP[s] URLs" and that, for a lot of the
> purposes for which the distinction is useful, our long-ago
> decisions to have a unified syntax and theory of URIs still
> requires that, for many URN purposes (including some of those
> contemplated in 1737 and the discussions surrounding it), users
> are going to need to be familiar with the difference.  The other
> is to say "URNs really are URLs, just a different shorthand form
> from relative references.  The latter actually allows a
> universal resolver in the form of something that would maintain
> a per-NID that provides rules (perhaps in regex form) for
> getting from any given NID-NSS combination to a corresponding
> URL, presumably with any qualifying information just passed into
> the URL.  I don't see a third choice.  Do you?

IMO: URNs are not URLs.   By design, URNs have never been URLs. The 
reason that the term URI was defined was to have a name for a context in 
which both URLs and URNs could potentially appear. Yes, users of URNs 
(i.e. at least those users that put URNs into content or otherwise 
compose URNs with qualifiers) are expected to be familiar with the 
differences, which is precisely why a common urn: prefix is used as an 
umbrella or superclass for multiple namespaces - it's to provide a 
visible indication that this kind of URI, whatever its namespace, is 
different than a URL, and operates under somewhat different rules.   If 
every URN-like object had its own unique URI prefix, users would have to 
be able to recognize each kind of URN-like object and be aware of the 
differences not only between those objects and URLs, but between the 
different kinds of URN-like objects.   That, I suspect, would make most 
of those URN-like objects less viable as long-term identifiers.

(And yet, people who insist on the world being flat can insist that 
indeed they're all URLs, define a few terms in slightly different ways, 
use slightly different language, and end up with a mostly 
self-consistent view.   From a certain perspective, neither view is 
"right", and it's just a battle over language.   But of course language 
affects perception, and part of the reason for the lingering dispute is 
a desire from multiple parties to dictate how these names are 
perceived.  And that's unfortunate, because the lingering conflict over 
the language is generally confusing to those who aren't immersed in this 
world.)

>
>  Many of these discussions are convincing me that we
> made a fundamentally incorrect design decision when we decided
> that URLs and URNs were just too subspecies of a fundamental
> "URI" concepts and that they should share the same syntax and
> maybe most semantics.

I don't see those two decisions as having been inherently coupled. IMO, 
the URI concept is extremely useful.   But the only syntax features that 
URNs and URLs needed to have in common was (1) for URNs to have a scheme 
prefix that looked like a URL prefix and could be distinguished from 
other URL prefixes, and (2) for the two kinds of URIs to be composed 
from the same set of permissible characters, so that a scanner that was 
attempting to extract a URI from surrounding text would know when to 
terminate that scan - when it had found the last character of the URI.

But I recognize that there's a huge amount of momentum, mindshare, 
political investment, etc. around 3986 syntax for URNs, and that maybe 
it's not worth trying to find the political capital needed to revise 
3986 if we can somehow provide what URNs need within that framework.   
And I think the answer to whether we can do that is "maybe".

Keith


From nobody Tue Apr 14 20:10:02 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039A21B2A88 for ; Tue, 14 Apr 2015 20:10:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHOGuLPDdbbI for ; Tue, 14 Apr 2015 20:09:59 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08FA1B2A99 for ; Tue, 14 Apr 2015 20:09:35 -0700 (PDT)
Received: by pacyx8 with SMTP id yx8so34148437pac.1 for ; Tue, 14 Apr 2015 20:09:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=jqYhsjf7fOu9034mM/XqF2PAhGm7cjFiQOWnY3JLC8U=; b=T+lkOqO+AEdpVeHfp2QsfvLQG5IT6FRWVdvG+2F6tPjmfSXbLmsasJftOHzNpo/wR5 JON86wql5TAKHEZPUH6WkaOqwrMZSeytK9klCafkeWkXtWqcG5cZr6a2bQk3IP4LtwxM sjya3UndMVKWez9mw1nhiNJLIzgczz2+zm6RvwHS3QKvLHrRVvdnK1iZKnZeApC6akxx EOwBT2aCRAvffPkqCIkEyg7RmlwCIQtRh/ivzNsGl1IHSF+sGPtKY63pU/ek8nIrLCq/ MD0E6cdNFd81XECssojH/JxcqhAJTYyp0lirrhBdh/QtSBQZBLBZBZRBdI/a37sED9hL DgbA==
X-Received: by 10.68.241.9 with SMTP id we9mr2122282pbc.59.1429067375544; Tue, 14 Apr 2015 20:09:35 -0700 (PDT)
Received: from spandex.local (209-193-10-164-rb3.nwc.dsl.dynamic.acsalaska.net. [209.193.10.164]) by mx.google.com with ESMTPSA id nn6sm2446212pdb.79.2015.04.14.20.09.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Apr 2015 20:09:34 -0700 (PDT)
Message-ID: <552DD66C.1000208@gmail.com>
Date: Tue, 14 Apr 2015 19:09:32 -0800
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "urn@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Barry Leiba 
Subject: [urn] urnbis virtual interim details
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Apr 2015 03:10:01 -0000

urnbis Virtual Interim
Friday, April 17 2015
16:00 - 18:00 UTC (9am-11am PDT, 12pm-2pm EDT, 18:00-20:00 CET)

Dail-in: 866-316-3380 763-488-8408
Conf code: 7032279870

Agenda:

2141 status update
Open issues walkthrough

The goal is to come to closure on some of the issues that have
been difficult to resolve on the mailing list and set a baseline
for consensus calls on the mailing list.

Talk with you then!


From nobody Tue Apr 14 22:57:20 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4D21B30E3 for ; Tue, 14 Apr 2015 22:57:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.55
X-Spam-Level: 
X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vX0tJcLQKTTz for ; Tue, 14 Apr 2015 22:57:17 -0700 (PDT)
Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 308401B3031 for ; Tue, 14 Apr 2015 22:57:16 -0700 (PDT)
Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 642A68AE2E; Wed, 15 Apr 2015 07:57:15 +0200 (CEST)
X-AuditID: 0a453fe7-f79106d0000047dd-ce-552dfdbb33ea
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.1C.18397.BBDFD255; Wed, 15 Apr 2015 07:57:15 +0200 (CEST)
Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Wed, 15 Apr 2015 07:57:14 +0200
From: "Svensson, Lars" 
To: Melinda Shore , "urn@ietf.org" 
Thread-Topic: [urn] urnbis virtual interim details
Thread-Index: AQHQdymratGxIOy0kkqUILLLQS2mu51Nk0jQ
Date: Wed, 15 Apr 2015 05:57:13 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EFFAC99B59@dnbf-ex1.AD.DDB.DE>
References: <552DD66C.1000208@gmail.com>
In-Reply-To: <552DD66C.1000208@gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.69.216]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA12Te0hTYRjG+84508/lV59HN79WRo2ulqZWIHQxosLELkJGBWXHdtyWc9Od LTQKtMsCozBKqtG9UdFtJkrWCmIZYdgqKfIPM7pgaJgihAlanctmx/5793vf53mf93wM0mwV NECr3cU77ZzNGKVltKuzfqYERlLy05oPo8zg1TZNpsfjZTJrD/ZTK+jsQzeP0dkPvB+is32+ IWojvU271MTbrHt454LlO7WWwYEfoLSdKv/0souuBMepahADCV5EbnT4GKXWk9ed/qhqoIUs bgak8vx1jfLjPiCDJ2uiq0E0jMLJpM8izSfgHNL48CQt1TSeSwKNF+Q6HqeTpwcC0cpMBvH2 HRmtXzd1yDWDZ5K75z6KGSBEeC0537hawiyeQ3ru1slxYkRL79FWjVQDnETq6l6FVyWS+q5B jRIZE98jhROsI91ffmskS4KnE8/XOGU8jfSFLoal88i1y9/lGuE40nL2K1MD9F6Vq1cl8aok XpXkEmBugglCiTk9lTOlmkyFqSa+Hijv860JHG9bFQQYAmMscl1MyWc13B6hoiQINkDKqENJ vSKaUOgwVVg4wVLgdNt4wZiAhodFjEZxodtWbJyKpj6Zn88mjlLBLZRad1kdbqHA7bQFAYG0 KF0oS01cxV7e6VAMg2AyZIyJ6ESgahOLzZyLL+b5Ut4Z6W6B0EjQQ0kY5+TNfHmR1eaKtEXd /kGxg9UdOdB0lCEFMqgb/2eiYEwQ5MJYMVjGiBRMKOVKBKs57B2PyqStsREq+yahZslXH4Fj PV+AAthx6s8VimXsDjtvSERAMsbStMVtH81t0Cvfa6KqIdkbpiFDybx8dpKKj93QA9aKzxWP lsjRxH/cv7ws2ifB8WEox52CPkl7dGH2v1eu+M4J6HmefLyLc6mP78yTjw/T8PHvJaiPwLF2 hkowvvaXp/dG6rTuA1UjRcK6VaGM7ctbGdKM/LtH8ja/6Vw/bqXvcdnnqvZ7uqyKcZOZ2Lea mBzrjpXvkpoKa0P7uhY/3hZ6kjXjWcst/9Cjjf6c3BP07asd/QNU2eyt5YG+ZQMN24caZg3X 6E77q9tDR/WH13y5c2bYY2H8qOUWZXYYGcHCpSfTToH7CwCfDxOUBAAA
Archived-At: 
Cc: Barry Leiba 
Subject: Re: [urn] urnbis virtual interim details
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Apr 2015 05:57:19 -0000

Dear Melinda,

> urnbis Virtual Interim
> Friday, April 17 2015
> 16:00 - 18:00 UTC (9am-11am PDT, 12pm-2pm EDT, 18:00-20:00 CET)
>=20
> Dail-in: 866-316-3380 763-488-8408
> Conf code: 7032279870

Just to be sure: Are those dial-in numbers US numbers, i. e. we should use =
country prefix +1 before dialing them?

Best,

Lars=20


From nobody Tue Apr 14 23:00:35 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9CB1B314F for ; Tue, 14 Apr 2015 23:00:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yw_M0MWLxZkc for ; Tue, 14 Apr 2015 23:00:33 -0700 (PDT)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1EE91B3151 for ; Tue, 14 Apr 2015 23:00:32 -0700 (PDT)
Received: by iedfl3 with SMTP id fl3so37303635ied.1 for ; Tue, 14 Apr 2015 23:00:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+W29tBEFQ2DSDtD9F5ntBruzyC/GJ0oiD6HkpdbBQDI=; b=UecBL3+8sspRExXycEn6O1/REiM+Fx8UwHK33lTojoe2yJsOtrrLvIw/bvkwOHskam sSZzDgLg08PS4Bu0kH2fvFliDizW/i99CDARHwgwK8nAeZtSBnFOA0JTOb2fwGRqONtU O/fleEil9HA5Bbd4kUMCyNxgCPqW4UdSAx0nf21TSI1fTgfxZIgG+7pdt1YRkcRRHYw0 4Wmn6dCchMkxUQTIfs6p/tNz+xnM8OZ75qcLFUaWAB0NrdRvGRoS59CkCv5ARKApqV57 cqlJPhw6kJuU14eKf+jxvK6HveIEw8J7+dYumKBIYsP+DEg0ZEPzfU0jQAvcFZ+B0RuG Hxlg==
MIME-Version: 1.0
X-Received: by 10.42.167.8 with SMTP id q8mr30083959icy.94.1429077631918; Tue, 14 Apr 2015 23:00:31 -0700 (PDT)
Received: by 10.43.69.203 with HTTP; Tue, 14 Apr 2015 23:00:31 -0700 (PDT)
Received: by 10.43.69.203 with HTTP; Tue, 14 Apr 2015 23:00:31 -0700 (PDT)
In-Reply-To: <24637769D123E644A105A0AF0E1F92EFFAC99B59@dnbf-ex1.AD.DDB.DE>
References: <552DD66C.1000208@gmail.com> <24637769D123E644A105A0AF0E1F92EFFAC99B59@dnbf-ex1.AD.DDB.DE>
Date: Tue, 14 Apr 2015 22:00:31 -0800
Message-ID: 
From: Melinda Shore 
To: Lars Svensson 
Content-Type: multipart/alternative; boundary=90e6ba6e83c49b7c140513bd10f9
Archived-At: 
Cc: urn@ietf.org, Barry Leiba 
Subject: Re: [urn] urnbis virtual interim details
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Apr 2015 06:00:34 -0000

--90e6ba6e83c49b7c140513bd10f9
Content-Type: text/plain; charset=UTF-8

Yes - apologies for not making that clear.  Those are US numbers.
On Apr 14, 2015 9:57 PM, "Svensson, Lars"  wrote:

> Dear Melinda,
>
> > urnbis Virtual Interim
> > Friday, April 17 2015
> > 16:00 - 18:00 UTC (9am-11am PDT, 12pm-2pm EDT, 18:00-20:00 CET)
> >
> > Dail-in: 866-316-3380 763-488-8408
> > Conf code: 7032279870
>
> Just to be sure: Are those dial-in numbers US numbers, i. e. we should use
> country prefix +1 before dialing them?
>
> Best,
>
> Lars
>

--90e6ba6e83c49b7c140513bd10f9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Yes - apologies for not making that clear.=C2=A0 Those are U=
S numbers. 


On Apr 14, 2015 9:57 PM, "Svensson, Lars&qu=
ot; <L.Svensson@dnb.de> wrot=
e:
Dear Melinda,



> urnbis Virtual Interim

> Friday, April 17 2015

> 16:00 - 18:00 UTC (9am-11am PDT, 12pm-2pm EDT, 18:00-20:00 CET)

>

> Dail-in: 866-316-3380 763-488-8408

> Conf code: 7032279870



Just to be sure: Are those dial-in numbers US numbers, i. e. we should use =
country prefix +1 before dialing them?



Best,



Lars




--90e6ba6e83c49b7c140513bd10f9--


From nobody Wed Apr 15 05:35:01 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BC11A8ADC for ; Wed, 15 Apr 2015 05:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1pkrS7iDWhZ for ; Wed, 15 Apr 2015 05:34:57 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0901A8AE0 for ; Wed, 15 Apr 2015 05:34:57 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YiMWu-00045D-5t; Wed, 15 Apr 2015 08:34:56 -0400
Date: Wed, 15 Apr 2015 08:34:51 -0400
From: John C Klensin 
To: Keith Moore , urn@ietf.org
Message-ID: <1FE872FDB2711861046EE49F@JcK-HP8200.jck.com>
In-Reply-To: <552DD1DF.5010906@network-heretics.com>
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com>  <552DD1DF.5010906@network-heretics.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Apr 2015 12:34:59 -0000

Keith,

Very briefly, first because I have no more cycles available
today and second because I'd like to hear from others but (and
trimming a lot because people should read your original
message).   I hope your note and these comments on it will
stimulate conversation on the list or on Friday's call.

Inline.

--On Tuesday, April 14, 2015 22:50 -0400 Keith Moore
 wrote:

>...
>> (iii) Forget p-components and f-components as posing the most
>> issues for generic URI processing and user expectations and
>> impose urn-scheme-specific conventions on q-components to
>> allow distinguishing among my three cases or your four.
>...

> I'm looking into a variant of (iii) in which a q-component
> (while still adhering to 3986 syntax) can itself be parsed
> into a portion which affects resolution and a portion which
> can get transmitted to the resource for interpretation by the
> resource.   f-components can still be used to refer to
> fragments of resource content.    Whether p-components can be
> used depends in part on other factors.   (If they are used by
>...

Fwiw, that would work for me if the details can be worked out.
My recollection is that something slightly similar was proposed
a couple of years ago and the WG wasn't enthused but perhaps now
that the other options are more clear the answer will be
different and less ambiguous.

>...
> I think the two good options for handling of relative
> references are:
>...
> (b) don't permit relative references to base URNs - if a URN
> is used to access content that contains relative references, a
> base URL must either appear in the content itself or be
> obtained during the resolution process.   Then '/'s could
> appear in URNs, but there's no significance to them.   (aside:
> I think it would be nice if DOIs could map cleanly into URN
> space without %-encoding.)
> 
> I'm leaning to the latter at the moment, because ultimately I
> think it is cleaner to avoid having 3986 rules for relative
> references be used to manipulate URNs.

That is consistent with my instinct if we can sort the details
out.

>...

>...
>> I think we can go one of two ways here.  One is to say "URNs
>> are not URLs, much less HTTP[s] URLs" and that, for a lot of
>> the purposes for which the distinction is useful, our long-ago
>> decisions to have a unified syntax and theory of URIs still
>> requires that, for many URN purposes (including some of those
>> contemplated in 1737 and the discussions surrounding it),
>> users are going to need to be familiar with the difference.
>> The other is to say "URNs really are URLs, just a different
>> shorthand form from relative references.  The latter actually
>> allows a universal resolver in the form of something that
>> would maintain a per-NID that provides rules (perhaps in
>> regex form) for getting from any given NID-NSS combination to
>> a corresponding URL, presumably with any qualifying
>> information just passed into the URL.  I don't see a third
>> choice.  Do you?
> 
> IMO: URNs are not URLs.   By design, URNs have never been
> URLs. The reason that the term URI was defined was to have a
> name for a context in which both URLs and URNs could
> potentially appear.

I understood all of that.  The difficulty is that, to a very
considerable degree, while 3986 mentions URNs, it is becoming
more and more obvious (at least to me) that it was designed
around a great many URL assumptions without making adequate
allowances for the ways in which URNs ought to be different.
The "URNs are not URIs" terminology was wrong (as well as
inflammatory), but the underlying idea that URNs are distinct
from URLs and that a lot of 3986, despite its title is about
URLs and not URNs may still be correct.  I continue to hope that
the syntax vs. semantics distinction will be sufficient to let
URN work progress but, if one reads some of the comments on the
Apps-Discuss list, that distinction is either being dismissed or
attempts are made to cover it over (see my comments there about
the use of the term "role").

I have to admit that I've always had trouble with 3986 and the
way it and its predecessors are written -- my model of design,
parsing structure, and modularization is sufficiently different
that I've been inclined to give the authors of 3986 the benefit
of the doubt rather than going through the document and trying
to translate it into my frame of reference.  However, when I've
tried to do the latter in the last year, what I've encountered
is many problems and inconsistencies.  I continue to hope those
can be kept out of the URN debates, but they are, for me, fairly
intrusive.

> Yes, users of URNs (i.e. at least those
> users that put URNs into content or otherwise compose URNs
> with qualifiers) are expected to be familiar with the
> differences, which is precisely why a common urn: prefix is
> used as an umbrella or superclass for multiple namespaces -
> it's to provide a visible indication that this kind of URI,
> whatever its namespace, is different than a URL, and operates
> under somewhat different rules.

In that sense, our difficulty with the URN - URI relationship is
that a few people are quite forcefully telling us that URNs
really don't get to be different from URLs, particularly wrt
different rules.

>...
> (And yet, people who insist on the world being flat can insist
> that indeed they're all URLs, define a few terms in slightly
> different ways, use slightly different language, and end up
> with a mostly self-consistent view.

Yes, I think that is what we have been seeing.  I think the WG
is going to need to be quite forceful to get past that, rather
than having it drive us around in circles.

>...
> But I recognize that there's a huge amount of momentum,
> mindshare, political investment, etc. around 3986 syntax for
> URNs, and that maybe it's not worth trying to find the
> political capital needed to revise 3986 if we can somehow
> provide what URNs need within that framework.   And I think
> the answer to whether we can do that is "maybe".

Yes.  And I think that is the core of the issue.  From my point
of view, there are no URN issues that we cannot work out in a
reasonable way, paying as much attention to 3986 as is feasible
given the needs of URNs (but no more), as long as we don't get
paralyzed by "this has to be more like a URL because there are a
lot of URLs" assertions and requirements.

    john


From nobody Wed Apr 15 06:50:44 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6C31B351C for ; Wed, 15 Apr 2015 06:50:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpohPz9epekY for ; Wed, 15 Apr 2015 06:50:39 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E401B351B for ; Wed, 15 Apr 2015 06:50:38 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 28F5520E9E for ; Wed, 15 Apr 2015 09:50:38 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 15 Apr 2015 09:50:38 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=1FQ8/YGggQR0RlV sNvH9jHs5bRQ=; b=SxE5+uxQvTg0PQyNzfEhffbCIupQqggirJqUcFwjSuvRZsV V3kMMagmIKBK0YORi3S6zGIpaUteu6Nwaeys7lDpkZbYHr/1vfQ46vk+CaKSdNxQ QB5rDyEy+nWgp2zgT9l/bhMK1Ss/YSlijXVU6XwZDYtXwe4ppVRcyre2N+Vs=
X-Sasl-enc: m7Po8tuCkib5F6WRlmTDhCa8oUe43u0Gr2Aehq2TsBsV 1429105837
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id C24E76801BE; Wed, 15 Apr 2015 09:50:37 -0400 (EDT)
Message-ID: <552E6C9C.6080604@network-heretics.com>
Date: Wed, 15 Apr 2015 09:50:20 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com>  <552DD1DF.5010906@network-heretics.com> <1FE872FDB2711861046EE49F@JcK-HP8200.jck.com>
In-Reply-To: <1FE872FDB2711861046EE49F@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Apr 2015 13:50:40 -0000

On 04/15/2015 08:34 AM, John C Klensin wrote:
>> IMO: URNs are not URLs.   By design, URNs have never been
>> URLs. The reason that the term URI was defined was to have a
>> name for a context in which both URLs and URNs could
>> potentially appear.
> I understood all of that.  The difficulty is that, to a very
> considerable degree, while 3986 mentions URNs, it is becoming
> more and more obvious (at least to me) that it was designed
> around a great many URL assumptions without making adequate
> allowances for the ways in which URNs ought to be different.

I certainly agree.

> The "URNs are not URIs" terminology was wrong (as well as
> inflammatory), but the underlying idea that URNs are distinct
> from URLs and that a lot of 3986, despite its title is about
> URLs and not URNs may still be correct.  I continue to hope that
> the syntax vs. semantics distinction will be sufficient to let
> URN work progress but, if one reads some of the comments on the
> Apps-Discuss list, that distinction is either being dismissed or
> attempts are made to cover it over (see my comments there about
> the use of the term "role").

I haven't had the cycles to follow apps-discuss lately, but might find 
some time after today.
>> Yes, users of URNs (i.e. at least those
>> users that put URNs into content or otherwise compose URNs
>> with qualifiers) are expected to be familiar with the
>> differences, which is precisely why a common urn: prefix is
>> used as an umbrella or superclass for multiple namespaces -
>> it's to provide a visible indication that this kind of URI,
>> whatever its namespace, is different than a URL, and operates
>> under somewhat different rules.
> In that sense, our difficulty with the URN - URI relationship is
> that a few people are quite forcefully telling us that URNs
> really don't get to be different from URLs, particularly wrt
> different rules.

I'm not sure who those "few people" are.   But we're not supposed to 
have kings in IETF, and we're supposed to make decisions based on 
technical soundness rather than wishful thinking.

Keith


From nobody Wed Apr 15 10:42:58 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438121B3647 for ; Wed, 15 Apr 2015 10:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XoPB_LjpAxL for ; Wed, 15 Apr 2015 10:42:55 -0700 (PDT)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1361B3645 for ; Wed, 15 Apr 2015 10:42:55 -0700 (PDT)
Received: by pabsx10 with SMTP id sx10so58283027pab.3 for ; Wed, 15 Apr 2015 10:42:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=4eNJXI3CcYoyxIN5wJFBjSRqn4kLlmXdVJMTdSsZ+2M=; b=vBBATOL2+DuatVfc+XK/F6kV6S/uI6/WNpSjefDYCDB8MDShw59W/UTUSTv22UfbvO EV68d/4JEOqG1oN5yokacKWC/yPpH/s9y4Kkk12y6HNnFIieaVCiH45q84A9AOMri5r8 lJJ0bes6gvLcR/xyMVwRKTqyPl+wX+08yYugTMV3a6CG1ai04APc7W/NEAmkzdCBmPKJ I9ZYnXNOFaZqfj4gPSDrwPcyIQeeGIlK8DU54yKkiXsAH2eRvh8MXJz+zxLcJUcO9XMs sAvnKiugaTbCHIeTylMF+UpKgPOeglOdbQ7jZ7AQx1NYX3T1hxsNgd/0wQwVguXeTU+4 O0gg==
X-Received: by 10.70.127.138 with SMTP id ng10mr48440651pdb.111.1429119775466;  Wed, 15 Apr 2015 10:42:55 -0700 (PDT)
Received: from spandex.local (216-67-7-27-rb2.fai.dsl.dynamic.acsalaska.net. [216.67.7.27]) by mx.google.com with ESMTPSA id kl10sm4736965pbd.15.2015.04.15.10.42.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Apr 2015 10:42:54 -0700 (PDT)
Message-ID: <552EA31D.1090402@gmail.com>
Date: Wed, 15 Apr 2015 09:42:53 -0800
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "urn@ietf.org" , Barry Leiba 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [urn] Updated virtual interim details
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Apr 2015 17:42:57 -0000

This is an update to information on Friday's virtual
interim.  We will be using Webex rather than the
conference bridge previously announced, and will have
global call-in numbers (see URL provided below), as
well as the ability to record the session.

Agenda:

2141 status update
Open issues walkthrough

The goal is to come to closure on some of the issues that have
been difficult to resolve on the mailing list and set a baseline
for consensus calls on the mailing list.

Talk with you then!


urnbis Virtual Interim
Friday, April 17 2015
16:00 - 18:00 UTC (9am-11am PDT, 12pm-2pm EDT, 18:00-20:00 CET)


Join WebEx meeting:
https://ietf.webex.com/ietf/j.php?MTID=ma161311ff6c7053901744d309821301f
Meeting number: 645 547 018
Meeting password: 1234

Join by phone
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 645 547 018

Global call-in numbers:
https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=302217342&tollFree=1

IMPORTANT NOTICE: Please note that this WebEx service allows audio and
other information sent during the session to be recorded, which may be
discoverable in a legal matter. By joining this session, you
automatically consent to such recordings. If you do not consent to
being recorded, discuss your concerns with the host or do not join the
session.


From nobody Wed Apr 15 18:51:48 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12C71B29D6 for ; Wed, 15 Apr 2015 18:51:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG-UdWkEZn4z for ; Wed, 15 Apr 2015 18:51:44 -0700 (PDT)
Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BACA1B29D4 for ; Wed, 15 Apr 2015 18:51:44 -0700 (PDT)
Received: by iget9 with SMTP id t9so913328ige.1 for ; Wed, 15 Apr 2015 18:51:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/Z2UMN7bGz+O/O8HdbPfxM3y2m4SyGdjR2RUbW5PjKA=; b=BjwdxcxpSX0JM3uc4b7Ua9Wr7NXvP18hjzc+qlcVPFF1dU2VsCi464tMGmo1LwdPfJ l616CTLYI3qOwo8Mq0kt5yHqyNZk7a9Widw3ruQuUSGdwrugWVRV1aTWqiCI+WcOChVd t9TnhCe4+GE1uO/adsQo+9LB2oq9bssxK/mM8OtJwElRvfnMdUMiwKjFh96xAS2GxOMH CR1ujfH49gIXeDgWnFMv1xhelBsYX6croEoY4SEz3p11Mgr6hIjsL2804mpE9YYApuuQ Qs/FoITWjlEf2b9gxJWUyAYh+y6+SHx5rTLXJuXo3tnUtPKRNotQAksBMkr//B1HK8ry Q6OA==
X-Gm-Message-State: ALoCoQlOD/Dw/zjSqzF5rlSqHh/6ae8HQGc+aMl9WkJwwOzHZFK0UIo/jNfAl9swYnvh0D5HyMCI
X-Received: by 10.50.29.40 with SMTP id g8mr2293037igh.41.1429149103744; Wed, 15 Apr 2015 18:51:43 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id e4sm4276377igx.7.2015.04.15.18.51.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2015 18:51:42 -0700 (PDT)
Message-ID: <552F15AD.2050405@andyet.net>
Date: Wed, 15 Apr 2015 19:51:41 -0600
From: Peter Saint-Andre - &yet 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Keith Moore , urn@ietf.org
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com>
In-Reply-To: <552D3AB0.4060006@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Apr 2015 01:51:46 -0000

Hi Keith, I concur with John that this is very helpful input to the 
discussion. Comments inline.

On 4/14/15 10:05 AM, Keith Moore wrote:
> On 04/13/2015 04:10 PM, John C Klensin wrote:
>> Hi.
>>
>> Those who have been following the apps-discuss list and the Apps
>> Area WG has seen a long, difficult, and sometimes unpleasant
>> thread about what a URN specification (or any other
>> specification for a particular URI scheme) is allowed to say
>> about fragments.  The discussion appears to extend to whether
>> fragments can be disallowed at all by a scheme (if they cannot,
>> 2141 has problems quite independent of what we might do), to
>> whether a scheme can constrain fragment syntax in any way, and
>> to whether scheme-specific or namespace-specific restrictions or
>> semantic [1] rules are allowed.
>>
>> Similar issues arise with p-components.   If a p-component
>> (i.e., introduced by a "/", at least before a q-component or
>> f-component) appears in a URN, it is claimed to be impossible
>> [2] to avoid relative resolution, something that might cause
>> havoc or other damage with URNs.
>>
>> An obvious question is why we don't just disallow one or both
>> and move on.
>>
>> For me, the answer is tied up with the question I've been asking
>> about the difference between instructions or qualifiers that are
>> part of the URN (see below) and instructions or qualifiers that
>> are intended to be passed to whatever the URN points to or
>> resolves to.   If no one else sees that as an issue, or believes
>> that we can reasonable handle it on a per-namespace basis (that
>> fragment discussion definitely would complicate handling those
>> on a per-namespace basis), please explain why and I'd drop this.
>> If others are concerned and believe we should handle that issue
>> using syntax, then I believe we need to consider three cases.
>> (I don't see any alternative to distinguishing by syntax if we
>> aren't going to make the distinction per-namespace, but maybe
>> I'm missing something):
>>
>> I'm going to use the term "qualifier" below to identify things
>> that are not inherently part of the NSS (using the syntax in
>> 2141bis-11) but that are part of the .
>>
>>   Case 1: The qualifier is part of the URN to the extent
>>     that it is included in comparisons and affects
>>     persistence.  As part of the URN, it is expected to
>>     affect or provide information to a URN processor or
>>     resolver.
>>
>>   Case 2: The qualifier is part of the URN in the sense
>>     that if affects or provides information to a URN
>>     processor or resolver, but does not participate in
>>     equality comparisons.    Information about locale (so a
>>     URN resolver could find the most convenient object or a
>>     pointer to it) would presumably fall into this category.
>>     I think distinctions between object and various types of
>>     metadata would too, but could be talked out of that.
>>
>>   Case 3: The qualifier is not part of the URN but
>>     contains information or specifications that should be
>>     passed on to the URN's target if that is meaningful.
>>     The qualifier is probably not meaningful if there is no
>>     resolution and no target.
>
> I think there are actually four categories of "qualifier":

I would love to see examples of each of these, by the way.

> 1. Qualifiers that potentially represent portions of resources, and/or
> relationships with other resources named with URNs, that should be
> included in comparisons and considered relevant for persistence.

I would especially like to see examples of #1, because I am not sure 
that they exist.

> 2. Qualifiers that identify portions of resources that should not be
> included in comparisons or when considering persistence.
>
> 3. Qualifiers that are transmitted to resources (when applicable) for
> interpretation by the resources.   These should not be included in
> comparisons or when considering persistence.
>
> 4. Qualifiers that affect resolution of the URN, and which should be
> transmitted to the resolution service if one is used, either to request
> a specific kind of resolution service, or to narrow down between
> multiple versions and/or representations of the content.

I continue to struggle with two things (or perhaps misconceptions in my 
own mind) about our discussions:

(a) Not all URNs need to be or can be resolved, and it seems to me that 
even URNs that can be resolved are primarily used to identify resources 
and not to resolve resources (which is why we have URLs, after all).

(b) We don't know enough about the running code of modern, actual URN 
resolution services to helpfully specify what kind of syntax they might 
require.

Regarding (a), we have (i) a large number of URN namespaces that are 
used by other SDOs or quasi-SDOs to assign identifiers for uses like XML 
namespaces. I strongly encourage the WG participants to spend some time 
looking through the list of formal namespaces:

http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

As far as I can see, most of the URNs that are assigned in those 
namespaces aren't intended to be resolved at all. They are, in the 
perhaps less than perfect terminology of 2141bis, "abstract 
designators". In these cases, there is simply no need to worry about 
qualifiers 3 & 4.

We also have (ii) a few URN namespaces (albeit namespaces with a huge 
number of assigned URNs) where resolution is at least possible. These 
are namespaces such as those for ISBNs, ISSNs, and NBNs. However, even 
here I think (perhaps without sufficient basis) that these URNs are 
assigned primarily for the purpose of identification ("this URN 
identifies that work") and not for the purpose of resolution ("this URN 
enables you to find a copy of that work on a shelf in this building").

When I combine the (to me) secondary importance of resolution for URNs 
with the fact that we don't know much about the running code of URN 
resolution services, I find myself at a loss to define the syntax, and 
certainly the semantics, of qualifiers 3 & 4 with any degree of 
precision. That is why I think 2141bis needs to be somewhat general 
about the syntax of those qualifiers (other than making sure that syntax 
is consistent with the URI syntax).

As an example, we might need to wait until we know a lot more about 
modern URN resolution systems before we can define name-value pairs for 
q-components.

And, to be clear, for the limited purposes of 2141bis I think that is 
fine. As I see it, the alternative is that this WG would postpone its 
delivery of updates to RFC 2141 much longer than it already has, with 
very little to show for that further delay and a great risk of failure 
or fragmentation.

Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Wed Apr 15 19:19:31 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506B51B2A9E for ; Wed, 15 Apr 2015 19:19:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgvXTSnd1-zg for ; Wed, 15 Apr 2015 19:19:18 -0700 (PDT)
Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE521B2A9F for ; Wed, 15 Apr 2015 19:19:18 -0700 (PDT)
Received: by iget9 with SMTP id t9so1213683ige.1 for ; Wed, 15 Apr 2015 19:19:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=R7T1Q6q8zhECOvBo+GbgC3bw87eswYDa0zyH9mg8Qo4=; b=Wxw9u/9+lb64FrARfI9iEpLZOdWC0fyKW8Lo6W902vB0Zwa5x7GXOanZ2z27oSdc3Z 3YpZijH/ym06Y0BoH3xjhwIoaLSynOr+XHSuIuD7tUHb+qglz8LUy4gitvBC5ddZJz6J MX9TdZRKdytMYfYxaz6ZC6/ov3daYWCM6rvDExlpbx80g7azfSCO4bAlHmUUO+f/j1qN D+1U8mdOhxxRnxkBOyr6Yyy/aPlBzqhTR6/+PQO/2jZGWrw39w7BwgBgIi2ByCUdWoZv 7pI2QyR8l66gjbmE0e8QKcLjTdzQi0tmqyDcDRmpkh6CMC3RVOnknfpJJpQwZzLF8qEI yHWQ==
X-Gm-Message-State: ALoCoQnqfGTfR7ff6zd421uLxKDNG3o53hNbfrSS7S22tDUneelXnGe1xOxz82lIS55Ow2QTOBBE
X-Received: by 10.107.39.72 with SMTP id n69mr39226089ion.8.1429150758054; Wed, 15 Apr 2015 19:19:18 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id n7sm10568265iga.13.2015.04.15.19.19.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2015 19:19:17 -0700 (PDT)
Message-ID: <552F1C24.6040006@andyet.net>
Date: Wed, 15 Apr 2015 20:19:16 -0600
From: Peter Saint-Andre - &yet 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Keith Moore , urn@ietf.org
References: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com> <551F266E.4000507@network-heretics.com>
In-Reply-To: <551F266E.4000507@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Apr 2015 02:19:23 -0000

On 4/3/15 5:46 PM, Keith Moore wrote:
> On 04/03/2015 03:49 PM, John C Klensin wrote:



>> A ROTTEN, BUT POSSIBLY DESIRABLE, CHOICE
>>
>> The theoretical argument for p-components is above.  I think we
>> also need to remember that opening 2141 (and at least
>> implicitly 3406) to allow additinoal syntax has been incredibly
>> painful and that, after 2141bis is complete and approved,
>> opening or revising it to allow yet more syntax is likely to be
>> even more painful.  That may be a good argument for adding
>> p-components now, even if doing so creates some pain, just to
>> have it over with.
>>
>> However, the above theorizing aside, I have not seen any real
>> demand for p-components on the mailing list.  If there is such
>> demand, I hope that those who have current needs will come
>> forward and explain them.  But, if there is not and
>> p-components are likely to be a source of blocking
>> controversies, another option would be to modify 2141bis to
>> reserve the syntax but prohibit registration (and, to the
>> extent we have the power, use) of URNs containing them until
>> and unless future documents appear that address the issues.
>
> I would prefer it if we can agree on some limitations on namespaces that
> use '/' in NSSs that will render path-relative references either useful
> or "mostly harmless" (depending on the particular discipline chose by
> that namespace).   As I stated above, I think we're going to want to be
> able to use URNs to refer to resources that contain path-relative
> references without breaking those references.   We should certainly be
> able to use URNs to name HTML documents, for instance.

Keith, would you mind clarifying that last sentence?

Here's why I ask. To my mind, we should certainly be able to use URNs to 
name documents (if by document we mean a created work, not any 
particular copy of that created work). Such a work might be an 
electronic document that could be constructed using any of a number of 
particular technologies: SGML, XML, HTML, EPUB, MS Word, PDF, markdown, 
TeX, LaTeX, you name it. Although I agree that we should certainly be 
able to use URNs to name electronic documents, I don't see why HTML is 
special here (I'm not saying you think it's special, BTW). Would you 
also agree that we should certainly be able to use URNs to name PDF 
documents or MS Word documents or EPUB documents?

Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Wed Apr 15 20:02:13 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C191B2CFE for ; Wed, 15 Apr 2015 20:02:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HX39BgN1JtqZ for ; Wed, 15 Apr 2015 20:02:10 -0700 (PDT)
Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA8B1B2CF6 for ; Wed, 15 Apr 2015 20:02:09 -0700 (PDT)
Received: by iedfl3 with SMTP id fl3so47872047ied.1 for ; Wed, 15 Apr 2015 20:02:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HQQDup11sDl2YJPYPzuFGSGOALE2uFvZ+2x6YQ6pH+U=; b=d7UbbEXg9ieRkXoR+/OKjdG/k5oz/Ubo1V2oyoI4ix5QKBbtgzIKcNGm/G46fr0XgK ZPCn+4WmGnK+CyjqEXDyvFYRVcVRWHvEYNk/WA4wnXoznOIuY57YJyOIcO2BLZyOmMdS vzThFzR8+6MPXZlSY1UyQmbl4owJUf8yZxSLgQaUKOT2jdz8yxaZdnCKb424GkNMDn6k zCr4QiKT9h7Jb6WhRmeO/4oRAY9MNNlzjmRufAzgINkm/djkoYRKRLAricJfgT3+4e2+ InNyRBsuJNwGjhi++V448JVBuD9q/P78B974EfaZu+msQVSi0ZNjZKa8jk7LclGyy5Mp Bc/w==
X-Gm-Message-State: ALoCoQk1djY9BT80WbM2JP8eR4MOe2l0/6d9h78QuTnJCyz71BSRGEbX9U9boUx1pLSyi0gQTby8
X-Received: by 10.50.147.10 with SMTP id tg10mr2646831igb.36.1429153329126; Wed, 15 Apr 2015 20:02:09 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id m191sm3678339ioe.23.2015.04.15.20.02.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2015 20:02:08 -0700 (PDT)
Message-ID: <552F262E.1040602@andyet.net>
Date: Wed, 15 Apr 2015 21:02:06 -0600
From: Peter Saint-Andre - &yet 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Keith Moore ,  John C Klensin , urn@ietf.org
References: <55142CA1.2000509@network-heretics.com> <587F32051FF797206A169FC6@JcK-HP8200.jck.com> <551B0E58.3010709@network-heretics.com>
In-Reply-To: <551B0E58.3010709@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Namespace consensus and registrations
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Apr 2015 03:02:11 -0000

On 3/31/15 3:15 PM, Keith Moore wrote:
> On 03/29/2015 10:41 PM, John C Klensin wrote:
>>
>> --On Thursday, March 26, 2015 11:58 -0400 Keith Moore
>>  wrote:
>>
>>> 7.  I'm somewhat sympathetic to the idea that IETF Consensus
>>> is not the right template for creating new namespaces, but
>>> Expert Review is even worse.   I think we need widespread
>>> public review, and that our very experience in this working
>>> group is a good indicator of why - there is as yet no small
>>> collection of "experts" that really understands everything
>>> about what it takes to make URNs function well, especially
>>> when applied to network-accessible resources.
>> This issue has been discussed fairly extensively within the WG
>> and consensus to make the change to Expert Review was reached,
>> IIR, a couple of years ago.  The counterargument to "Expert
>> Review is even worse" is based on something we've seen played
>> out many times with media types as the best-known example.  If
>> we create a registration procedure that is perceived of as
>> onerous, the main effect is to encourage squatting (or whatever
>> one chooses to call using unregistered names) and perhaps having
>> some Wikipedia page over which the IETF has no control turn into
>> the registry that people consult rather than having an IANA
>> registry serve that role.  In that situation, we also often end
>> up with no useful documentation at all.  So the model in 2141bis
>> (somewhat revised for more clarity in -11 which we still expect
>> to have posted Tuesday or earlier) not only defines the Expert
>> Review process but makes it more consultative rather than
>> judgmental to encourage documentation and registration.
>
> Perhaps the simplest and clearest response that I can offer is that I
> don't care what the label is ("Expert Review" vs "IETF Consensus" or
> whatever), so much as I care that there be an opportunity for public
> review.   If the process specified for "Expert Review" requires that
> there be public review, that the opportunity for review is advertised in
> IETF and other appropriate fora, and especially if we can somehow
> arrange that the "expert(s)" considering the results of that public
> review really do understand the subtleties of URNs (admitting that this
> is really difficult), I'm okay with that and think it's about the best
> that we can do. It's potentially even better than "IETF Consensus"
> because while that does require public review, nothing about the process
> for choosing Area Directors ensures that IESG will have URN expertise.
>
> So I'll be very interested to read -11's text on this subject.

Even before version -11, 2141bis (and before that 3406) stipulated that 
discussion was to occur on the urn-nid@ietf.org list. I would prefer 
that we deprecate the urn-nid list and have discussion on this list, but 
in any case, yes, public review is very much part of the process.

Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Wed Apr 15 23:59:15 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA131ACDF6 for ; Wed, 15 Apr 2015 23:59:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egEcUj7s3wBl for ; Wed, 15 Apr 2015 23:59:11 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0767.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::767]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D351B2A19 for ; Wed, 15 Apr 2015 23:59:09 -0700 (PDT)
Received: from AM3PR07MB369.eurprd07.prod.outlook.com (10.242.109.143) by AM3PR07MB372.eurprd07.prod.outlook.com (10.242.109.152) with Microsoft SMTP Server (TLS) id 15.1.136.25; Thu, 16 Apr 2015 06:57:21 +0000
Received: from AM3PR07MB369.eurprd07.prod.outlook.com ([10.242.109.143]) by AM3PR07MB369.eurprd07.prod.outlook.com ([10.242.109.143]) with mapi id 15.01.0136.026; Thu, 16 Apr 2015 06:57:21 +0000
From: "Hakala, Juha E" 
To: Keith Moore , "urn@ietf.org" 
Thread-Topic: [urn] Why bother with f-components (fragments) and/or p-components ?
Thread-Index: AQHQdiYG+DGCxjglskK7MurrBWs+2J1MrT0AgAAh3QCAAJJdgIAAo1+AgAAVFwCAAPohgA==
Date: Thu, 16 Apr 2015 06:57:21 +0000
Message-ID: 
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com>  <552DD1DF.5010906@network-heretics.com> <1FE872FDB2711861046EE49F@JcK-HP8200.jck.com> <552E6C9C.6080604@network-heretics.com>
In-Reply-To: <552E6C9C.6080604@network-heretics.com>
Accept-Language: fi-FI, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: network-heretics.com; dkim=none (message not signed) header.d=none;
x-originating-ip: [128.214.71.180]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB372;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(24454002)(479174004)(377454003)(13464003)(74316001)(106116001)(102836002)(15975445007)(74482002)(46102003)(77096005)(54356999)(76176999)(50986999)(93886004)(77156002)(4001410100001)(2656002)(33656002)(92566002)(2900100001)(2950100001)(107886001)(19580395003)(19580405001)(2501003)(66066001)(87936001)(62966003)(76576001)(40100003)(122556002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB372; H:AM3PR07MB369.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:AM3PR07MB372; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB372; 
x-forefront-prvs: 0548586081
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: 16 Apr 2015 06:57:21.4881 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB372
Archived-At: 
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Apr 2015 06:59:14 -0000

Hello,

> -----Original Message-----
> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Keith Moore
> Sent: 15. huhtikuuta 2015 16:50
> To: urn@ietf.org
> Subject: Re: [urn] Why bother with f-components (fragments) and/or p-
> components ?
>=20
> On 04/15/2015 08:34 AM, John C Klensin wrote:
> >> IMO: URNs are not URLs.   By design, URNs have never been
> >> URLs. The reason that the term URI was defined was to have a name for
> >> a context in which both URLs and URNs could potentially appear.
> > I understood all of that.  The difficulty is that, to a very
> > considerable degree, while 3986 mentions URNs, it is becoming more and
> > more obvious (at least to me) that it was designed around a great many
> > URL assumptions without making adequate allowances for the ways in
> > which URNs ought to be different.
>=20
> I certainly agree.

+ 1.=20

>From identifier community point of view, URNs - in order to be useful for u=
s - must accommodate existing standard identifier systems, but there is no =
such need for URLs since they are just locators, not names (identifiers).

This means - for instance - that in URNs fragment and query cannot have a r=
ole in identification, since that would change the scope of  many existing =
standard identifiers beyond recognition. All of a sudden ISBNs could be use=
d to identify (physical) fragments of ebooks, or even - with query - biblio=
graphic records describing books. Moreover, anyone would be able to assign =
ISBNs for book fragments at any time, which would make the administration o=
f the system complicated.

Whenever URI syntax seems to intervene with the existing identifier assignm=
ent practices URNBIS is putting a cart in front of a horse. It is the URN s=
yntax which should be adapted, not existing identifier assignment practices=
.  =20

Libraries, publishers and other organizations in the book trade have tradit=
ionally separated location and identification because it is practical to do=
 so. And we have carried on with this practice also in the Internet - scien=
tific publishers and research libraries are among major users of persistent=
 identifiers such as URN and DOI. It is unfortunate that URI mixes location=
 with naming since that gives some people an opportunity to claim that URLs=
 can in theory be just as persistent than URNs. In practice, that is not th=
e case. A thorough research article published last December indicates that =
URLs are simply not cool enough (see http://dx.doi.org/10.1371/journal.pone=
.0115253). My conclusion from this is that something else (both technically=
 and from administrative point of view) should be used to identify resource=
s which should be preserved indefinitely such as (scientific) publications.=
 But I am also sure that these research results will have no impact on the =
actions of cool URI supporters.    =20
=20
> > The "URNs are not URIs" terminology was wrong (as well as
> > inflammatory), but the underlying idea that URNs are distinct from
> > URLs and that a lot of 3986, despite its title is about URLs and not
> > URNs may still be correct.  I continue to hope that the syntax vs.
> > semantics distinction will be sufficient to let URN work progress but,
> > if one reads some of the comments on the Apps-Discuss list, that
> > distinction is either being dismissed or attempts are made to cover it
> > over (see my comments there about the use of the term "role").

Those who dismiss the difference between URLs and URNs should check why mos=
t organizations responsible of long term preservation of digital resources =
are using persistent identifiers. It is of course possible that we are all =
wrong ;-). =20

> I haven't had the cycles to follow apps-discuss lately, but might find so=
me
> time after today.
> >> Yes, users of URNs (i.e. at least those users that put URNs into
> >> content or otherwise compose URNs with qualifiers) are expected to be
> >> familiar with the differences, which is precisely why a common urn:
> >> prefix is used as an umbrella or superclass for multiple namespaces -
> >> it's to provide a visible indication that this kind of URI, whatever
> >> its namespace, is different than a URL, and operates under somewhat
> >> different rules.
> > In that sense, our difficulty with the URN - URI relationship is that
> > a few people are quite forcefully telling us that URNs really don't
> > get to be different from URLs, particularly wrt different rules.
>=20
> I'm not sure who those "few people" are.   But we're not supposed to
> have kings in IETF, and we're supposed to make decisions based on technic=
al
> soundness rather than wishful thinking.

I am not sure who these "few people" are either. But keep in mind that ther=
e are organizations - most of which not involved with IETF - which have ass=
igned tens of millions URNs already and will assign hundreds of millions of=
 them in the future. We expect URNBIS/IETF to deliver results which will en=
able us to enhance our existing URN-based services. =20

And I wish this technical soundness -criteria were applied to the so called=
 cool URIs as well. If they are not working in practice, what is IETF going=
 to do?

Juha

>=20
> Keith
>=20
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn


From nobody Thu Apr 16 00:18:41 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AF51B2B22 for ; Thu, 16 Apr 2015 00:18:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.618
X-Spam-Level: 
X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhPD__mgAXFI for ; Thu, 16 Apr 2015 00:18:34 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AADEF1B2B20 for ; Thu, 16 Apr 2015 00:18:33 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id ED36A207EF for ; Thu, 16 Apr 2015 03:18:32 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 16 Apr 2015 03:18:32 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=b/z2hMyTaq85/fHjjmDFpSB6t6k=; b=Mx1kH rUU7ZTWToF5JF4FIzOzrJcdb9i015cxPNr3wS+JaKWR4r13xgE78mdpSKMcjqcv8 zFnHatTRg4s7ZZevJbfcpyniu3IginV3y7PvEoi1W6/8UuEPtv2Aaoq0vMr6GuTv TMnWR+jbaCNvJzhLbMyoZeUmWCrbSEcUApmgn4=
X-Sasl-enc: rlbmM4QzgGO/VMGXVnrc4dtu5Id/LZYhlzc5iEnSAE21 1429168712
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 1AE94C00017; Thu, 16 Apr 2015 03:18:32 -0400 (EDT)
Message-ID: <552F6234.4080509@network-heretics.com>
Date: Thu, 16 Apr 2015 03:18:12 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Peter Saint-Andre - &yet , urn@ietf.org
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com> <552F15AD.2050405@andyet.net>
In-Reply-To: <552F15AD.2050405@andyet.net>
Content-Type: multipart/alternative; boundary="------------050806000006080402030303"
Archived-At: 
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Apr 2015 07:18:40 -0000

This is a multi-part message in MIME format.
--------------050806000006080402030303
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 04/15/2015 09:51 PM, Peter Saint-Andre - &yet wrote:
> Hi Keith, I concur with John that this is very helpful input to the 
> discussion. Comments inline.
>
> On 4/14/15 10:05 AM, Keith Moore wrote:
>> On 04/13/2015 04:10 PM, John C Klensin wrote:
>>> Hi.
>>>
>>> Those who have been following the apps-discuss list and the Apps
>>> Area WG has seen a long, difficult, and sometimes unpleasant
>>> thread about what a URN specification (or any other
>>> specification for a particular URI scheme) is allowed to say
>>> about fragments.  The discussion appears to extend to whether
>>> fragments can be disallowed at all by a scheme (if they cannot,
>>> 2141 has problems quite independent of what we might do), to
>>> whether a scheme can constrain fragment syntax in any way, and
>>> to whether scheme-specific or namespace-specific restrictions or
>>> semantic [1] rules are allowed.
>>>
>>> Similar issues arise with p-components.   If a p-component
>>> (i.e., introduced by a "/", at least before a q-component or
>>> f-component) appears in a URN, it is claimed to be impossible
>>> [2] to avoid relative resolution, something that might cause
>>> havoc or other damage with URNs.
>>>
>>> An obvious question is why we don't just disallow one or both
>>> and move on.
>>>
>>> For me, the answer is tied up with the question I've been asking
>>> about the difference between instructions or qualifiers that are
>>> part of the URN (see below) and instructions or qualifiers that
>>> are intended to be passed to whatever the URN points to or
>>> resolves to.   If no one else sees that as an issue, or believes
>>> that we can reasonable handle it on a per-namespace basis (that
>>> fragment discussion definitely would complicate handling those
>>> on a per-namespace basis), please explain why and I'd drop this.
>>> If others are concerned and believe we should handle that issue
>>> using syntax, then I believe we need to consider three cases.
>>> (I don't see any alternative to distinguishing by syntax if we
>>> aren't going to make the distinction per-namespace, but maybe
>>> I'm missing something):
>>>
>>> I'm going to use the term "qualifier" below to identify things
>>> that are not inherently part of the NSS (using the syntax in
>>> 2141bis-11) but that are part of the .
>>>
>>>   Case 1: The qualifier is part of the URN to the extent
>>>     that it is included in comparisons and affects
>>>     persistence.  As part of the URN, it is expected to
>>>     affect or provide information to a URN processor or
>>>     resolver.
>>>
>>>   Case 2: The qualifier is part of the URN in the sense
>>>     that if affects or provides information to a URN
>>>     processor or resolver, but does not participate in
>>>     equality comparisons.    Information about locale (so a
>>>     URN resolver could find the most convenient object or a
>>>     pointer to it) would presumably fall into this category.
>>>     I think distinctions between object and various types of
>>>     metadata would too, but could be talked out of that.
>>>
>>>   Case 3: The qualifier is not part of the URN but
>>>     contains information or specifications that should be
>>>     passed on to the URN's target if that is meaningful.
>>>     The qualifier is probably not meaningful if there is no
>>>     resolution and no target.
>>
>> I think there are actually four categories of "qualifier":
>
> I would love to see examples of each of these, by the way.
>
>> 1. Qualifiers that potentially represent portions of resources, and/or
>> relationships with other resources named with URNs, that should be
>> included in comparisons and considered relevant for persistence.
>
> I would especially like to see examples of #1, because I am not sure 
> that they exist.

When I first wrote up that list, I wasn't sure about #1 myself.   I 
almost stated that #1 wasn't very useful, then I realized that that type 
of qualifier probably is needed after all, or at least that it wasn't 
safe to say that they're not needed.

One reason for having such a qualifier is this: you'd really like to be 
able to have persistent references to portions of a resource. Fragments, 
as currently defined and implemented, don't serve that purpose.   (I 
could explain why but it would be a long side discussion, so will leave 
it to a separate message if the explanation is needed).   So 
*urn:example:/a* might refer to the entirety of a resource and 
*urn:example:/a/b* might refer to a portion of that resource, and 
*urn:example:/a/b/c* refer to a (presumably) still smaller portion - and 
all of these URNs would be managed by the namespace and expected to 
remain persistent over time (including their relationships to one 
another, if any of them used relative references).

>> 2. Qualifiers that identify portions of resources that should not be
>> included in comparisons or when considering persistence.

I think this ends up being the fragments to which we're already 
accustomed.   IMO, the ability to specify a fragment of a URN-named 
resource is still useful, it's just that the combination of a URN and a 
fragment name (or if you prefer, f-component) no longer has any 
assurance of persistence.   So *urn:example:a* has an assurance of 
persistence but *urn:example:a#b* does not.   I think this will confuse 
people for a while, because they'll have to learn to mentally parse URNs 
differently than URLs.   But overall this might be the best path 
forward.   It would be difficult for us to exclude use of fragments with 
URNs, or to define fragment behave differently with URNs than with URLs, 
without breaking relative references.

So I am thinking that the meaning of the fragment should still be the 
same for both URNs and URLs.   Ideally if *urn:example:a* resolves to 
*http://example.com/b*, and c is a valid fragment of that resource, then 
*urn:example:a#c* and *http://example.com/b#c *should refer to the same 
portion of that resource's content.   The alternative of letting 
fragments work differently for URNs vs. URLs strikes me as /very/ 
unlikely to work well, especially if 3986-style relative reference 
processing can be applied to URNs.
>>
>> 3. Qualifiers that are transmitted to resources (when applicable) for
>> interpretation by the resources.   These should not be included in
>> comparisons or when considering persistence.

This is analogous to query strings in HTTP.   IMO it's vital to let URNs 
be able to bundle the name of the base resource with some input to be 
transmitted to the resource.   So similar to fragments, I think that if 
*urn:example:a* resolves to *http://example.com/b*, then 
*urn:example:a?c* should ultimately result in a GET of 
*http://example.com/b?c* .   Again, *urn:example:a* is persistent while 
*urn:example:a?c* has no assurance of persistence.
>>
>> 4. Qualifiers that affect resolution of the URN, and which should be
>> transmitted to the resolution service if one is used, either to request
>> a specific kind of resolution service, or to narrow down between
>> multiple versions and/or representations of the content.

For the sake of an example of how this might be used, let's say that 
such a qualifier must begin with "??", that it appears before 
q-component, and the value of that qualifier is not allowed to contain 
"?" without it being %-encoded.  I'll tentatively call this an 
"r-component" ("r" for resolution)

  * *urn:example:a* would refer to the resource without specifying what
    to do with the URN.  If such a URN appeared in a link in a resource
    being viewed in a browser, and a user clicked on that link, the
    browser might try to present the content to the user.   Or failing
    that, it might simply try to get a description of the resource and
    display that.   If OTOH, such a URN appeared in an IMG tag the
    browser might give up if it couldn't get the content - presumably
    the description of the resource isn't an image.
  * *urn:example:a??request=content* would tell the resolution service
    (and perhaps also the client) that the reference was specifically
    intended to be for the resource's content, and not to locations, or
    any kind of description or metadata of the resource
  * *urn:example:a??request=metadata;format=dc-rdf *might request that
    the resolution service return a description of the resource in RDF
    format and the Dublin Core schema.
  * *urn:example:a??request=locations* could request locations of the
    resource
  * *urn:example:a??request=content;version=first* could request the
    earliest version of the resource

Basically these qualifiers would serve as a kind of query to the 
resolution service (as opposed to a query to be sent to the resource).  
It's like searching for a resource in a library's catalog and specifying 
some details that narrow the results along with the query.

As far as I can tell, this kind of capability is vitally important, 
because almost every time I see any functionality of a resolution 
service described, there's at least one or two examples of how one might 
include such queries with a URN.   IMO, if URNs don't provide a standard 
way to do it, URN resolution services will overload "?" and the result 
will be that (a) you can't specify a URN that includes a query to be 
sent to the resource itself (at least not in any uniform way) and (b) 
different schemes will behave differently and it will be difficult to 
write clients that treat Uniform Resource Names in any kind of uniform 
fashion.

Of course the above are just examples of what could be done, rather than 
a well thought-out proposal.   I would also suggest that namespaces 
should be able to define their own requests and parameters independently 
of others.   So for the "ietf" namespace, IETF should be able to support 
things like *
urn:ietf:rfc:XXXX??request=ietf.version-history;option=include-I-Ds
*
>
> I continue to struggle with two things (or perhaps misconceptions in 
> my own mind) about our discussions:
>
> (a) Not all URNs need to be or can be resolved, and it seems to me 
> that even URNs that can be resolved are primarily used to identify 
> resources and not to resolve resources (which is why we have URLs, 
> after all).
>
> (b) We don't know enough about the running code of modern, actual URN 
> resolution services to helpfully specify what kind of syntax they 
> might require.
>
> Regarding (a), we have (i) a large number of URN namespaces that are 
> used by other SDOs or quasi-SDOs to assign identifiers for uses like 
> XML namespaces. I strongly encourage the WG participants to spend some 
> time looking through the list of formal namespaces:
>
> http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
>
> As far as I can see, most of the URNs that are assigned in those 
> namespaces aren't intended to be resolved at all. They are, in the 
> perhaps less than perfect terminology of 2141bis, "abstract 
> designators". In these cases, there is simply no need to worry about 
> qualifiers 3 & 4.

There's been a lot of misunderstanding and misuse of URNs.   URNs were 
intended to name resources, not to merely be unique strings. I don't 
mind if people sometimes use URNs as merely unique strings, as I don't 
think it does much harm - except that some people have gotten the idea 
that this is the primary purpose of URNs.  It's not.  I don't even 
recall that particular use case even being mentioned through years of 
discussions about URNs in the mid-1990s.   To the extent URNs are usable 
in this way, it's a corner-case, an unintended consequence, not the 
general or typical case.

More generally, statements about how URNs "should be" that are based on 
observations of current namespaces or currently-observed usage of URNs 
strike me as about as valid as statements about how IPv6 should be, 
based on currently-observed usage of IPv6.   URNs, like IPv6, have been 
around for ~20 years, were designed to be usable for a very long time, 
but are really just starting to be used.   What we're seeing now with 
URNs (just like what we saw with IPv6 until recently) is still mostly 
due to early adopters, and shouldn't be considered as any indication of 
what will be typical of future use.   The communities that are most 
interested in using URNs properly are conservative by their very nature.

> We also have (ii) a few URN namespaces (albeit namespaces with a huge 
> number of assigned URNs) where resolution is at least possible. These 
> are namespaces such as those for ISBNs, ISSNs, and NBNs. However, even 
> here I think (perhaps without sufficient basis) that these URNs are 
> assigned primarily for the purpose of identification ("this URN 
> identifies that work") and not for the purpose of resolution ("this 
> URN enables you to find a copy of that work on a shelf in this 
> building").

See above.   Of course ISBNs and ISSNs were in wide use long before URNs 
were standardized, and all of these numbers were "grandfathered" as 
URNs, so it's not at all surprising that there are huge numbers of 
these.   Again, their use should not be taken as a prescription for how 
URNs will, or should, be "typically" used in the future.

Of course - the primary purpose of a URN *is* to identify a resource.   
But if you encounter a reference to a URN on a computer that's attached 
to the Internet (or even an isolated, private network), then it's quite 
likely you will find it useful to not merely be able to identify that 
resource, but also to query for information about that resource, and/or 
try to access the resource or obtain its content.   You won't always be 
able to do these things for any of a large number of reasons, e.g. the 
URN isn't known to any of the resolution services you consult; the URN 
refers to a resource that isn't amenable to network access or isn't 
online; you don't have permission to access it, etc.   But just because 
such services won't always be available is no reason to cripple URNs in 
such a way as to make it more difficult to provide those services.

URNs were always intended to be able to support resolution.   Back to 
the IPv6 analogy, saying that URNs supporting resolution is of secondary 
importance is about like saying that the ability IPv6 to access hosts 
not on the IPv4 Internet is of secondary importance, because hardly 
anyone is doing that at the moment.   (of course that's really not true 
but many haven't noticed yet)

>
> When I combine the (to me) secondary importance of resolution for URNs 
> with the fact that we don't know much about the running code of URN 
> resolution services, I find myself at a loss to define the syntax, and 
> certainly the semantics, of qualifiers 3 & 4 with any degree of 
> precision. That is why I think 2141bis needs to be somewhat general 
> about the syntax of those qualifiers (other than making sure that 
> syntax is consistent with the URI syntax).

I don't think we need (or want) a huge amount of precision.   In 
particular I don't think we should try to define a complete vocabulary 
for requests to resolution services and their parameters, and would 
actually prefer to see that work done outside of IETF. What I'd like to 
see is:

  * a small modification to the 2414bis grammar for URNs, to permit
    "r-components" in addition to f-, p- and q-components. (I think we
    can do this without breaking 3986 parsers, and with low risk of
    conflict with existing use of query strings.)
  * a grammar for r-component that allows multiple parameter names and
    associated values within that r-component to be specified to
    resolution services
  * an IANA registry for parameter names and/or associated values, with
    expert review required to add new ones, and each namespace having
    its own reserved prefix that it can do with as it wishes
  * a very minimal initial set of parameters, probably just defining
    "request" and "format" with an IANA registry for the names
    associated each, and 3 or 4 very basic requests.

I'm thinking this should be around 2-3 pages added to 2141bis, and I'm 
willing to draft text.


>
> As an example, we might need to wait until we know a lot more about 
> modern URN resolution systems before we can define name-value pairs 
> for q-components.

IMO, rather than wait, we should let people who are building URN 
resolution systems define that vocabulary.   IETF's role should be to 
try to get the underlying protocol right, and  to make sure that URNs (+ 
3986 rules) don't inhibit resolution or uniform handling, and don't 
cause breakage when used with resources also named by URLs.   IETF's 
role should not be to try to discover for itself how to design a query 
language for a resource cataloging system.

>
> And, to be clear, for the limited purposes of 2141bis I think that is 
> fine. As I see it, the alternative is that this WG would postpone its 
> delivery of updates to RFC 2141 much longer than it already has, with 
> very little to show for that further delay and a great risk of failure 
> or fragmentation.

I think that the risk of failure or fragmentation is actually much 
greater if we fail to specify how to distinguish between each of the 4 
types of qualifiers in a uniform way.

Or to put it a different way, there are two ways to get 
failure/fragmentation:   One is for us to delay so long that each 
namespace or community goes off and does things its own way, and the 
other is for us to fail to specify things completely or correctly enough 
so that each namespace or community is forced to do things its own way.

Keith


--------------050806000006080402030303
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 04/15/2015 09:51 PM, Peter
      Saint-Andre - &yet wrote:

    

    
Hi
      Keith, I concur with John that this is very helpful input to the
      discussion. Comments inline.
      

      

      On 4/14/15 10:05 AM, Keith Moore wrote:
      

      
On 04/13/2015 04:10 PM, John C Klensin
        wrote:
        

        
Hi.
          

          

          Those who have been following the apps-discuss list and the
          Apps
          

          Area WG has seen a long, difficult, and sometimes unpleasant
          

          thread about what a URN specification (or any other
          

          specification for a particular URI scheme) is allowed to say
          

          about fragments. The discussion appears to extend to whether
          

          fragments can be disallowed at all by a scheme (if they
          cannot,
          

          2141 has problems quite independent of what we might do), to
          

          whether a scheme can constrain fragment syntax in any way, and
          

          to whether scheme-specific or namespace-specific restrictions
          or
          

          semantic [1] rules are allowed.
          

          

          Similar issues arise with p-components. If a p-component
          

          (i.e., introduced by a "/", at least before a q-component or
          

          f-component) appears in a URN, it is claimed to be impossible
          

          [2] to avoid relative resolution, something that might cause
          

          havoc or other damage with URNs.
          

          

          An obvious question is why we don't just disallow one or both
          

          and move on.
          

          

          For me, the answer is tied up with the question I've been
          asking
          

          about the difference between instructions or qualifiers that
          are
          

          part of the URN (see below) and instructions or qualifiers
          that
          

          are intended to be passed to whatever the URN points to or
          

          resolves to. If no one else sees that as an issue, or
          believes
          

          that we can reasonable handle it on a per-namespace basis
          (that
          

          fragment discussion definitely would complicate handling those
          

          on a per-namespace basis), please explain why and I'd drop
          this.
          

          If others are concerned and believe we should handle that
          issue
          

          using syntax, then I believe we need to consider three cases.
          

          (I don't see any alternative to distinguishing by syntax if we
          

          aren't going to make the distinction per-namespace, but maybe
          

          I'm missing something):
          

          

          I'm going to use the term "qualifier" below to identify things
          

          that are not inherently part of the NSS (using the syntax in
          

          2141bis-11) but that are part of the <namestring>.
          

          

           Case 1: The qualifier is part of the URN to the extent
          

           that it is included in comparisons and affects
          

           persistence. As part of the URN, it is expected to
          

           affect or provide information to a URN processor or
          

           resolver.
          

          

           Case 2: The qualifier is part of the URN in the sense
          

           that if affects or provides information to a URN
          

           processor or resolver, but does not participate in
          

           equality comparisons. Information about locale (so a
          

           URN resolver could find the most convenient object or a
          

           pointer to it) would presumably fall into this category.
          

           I think distinctions between object and various types of
          

           metadata would too, but could be talked out of that.
          

          

           Case 3: The qualifier is not part of the URN but
          

           contains information or specifications that should be
          

           passed on to the URN's target if that is meaningful.
          

           The qualifier is probably not meaningful if there is no
          

           resolution and no target.
          

        

        

        I think there are actually four categories of "qualifier":
        

      

      

      I would love to see examples of each of these, by the way.
      

      

      
1. Qualifiers that potentially represent
        portions of resources, and/or
        

        relationships with other resources named with URNs, that should
        be
        

        included in comparisons and considered relevant for persistence.
        

      

      

      I would especially like to see examples of #1, because I am not
      sure that they exist.
      

    

    

    When I first wrote up that list, I wasn't sure about #1 myself. I
    almost stated that #1 wasn't very useful, then I realized that that
    type of qualifier probably is needed after all, or at least that it
    wasn't safe to say that they're not needed. 

    

    One reason for having such a qualifier is this: you'd really like to
    be able to have persistent references to portions of a resource.
    Fragments, as currently defined and implemented, don't serve that
    purpose. (I could explain why but it would be a long side
    discussion, so will leave it to a separate message if the
    explanation is needed). So urn:example:/a might refer to the entirety
    of a resource and urn:example:/a/b
    might refer to a portion of that resource, and urn:example:/a/b/c
    refer to a (presumably) still smaller portion - and all of these
    URNs would be managed by the namespace and expected to remain
    persistent over time (including their relationships to one another,
    if any of them used relative references).

    

    

      
2. Qualifiers that identify portions of
        resources that should not be
        

        included in comparisons or when considering persistence.
        

      

    

    

    I think this ends up being the fragments to which we're already
    accustomed. IMO, the ability to specify a fragment of a URN-named
    resource is still useful, it's just that the combination of a URN
    and a fragment name (or if you prefer, f-component) no longer has
    any assurance of persistence. So urn:example:a has an assurance of
    persistence but urn:example:a#b
    does not. I think this will confuse people for a while, because
    they'll have to learn to mentally parse URNs differently than
    URLs. But overall this might be the best path forward. It would
    be difficult for us to exclude use of fragments with URNs, or to
    define fragment behave differently with URNs than with URLs, without
    breaking relative references.

    

    So I am thinking that the meaning of the fragment should still be
    the same for both URNs and URLs. Ideally if urn:example:a
    resolves to http://example.com/b,
    and c is a valid fragment of that resource, then urn:example:a#c
    and http://example.com/b#c
      should refer to the same portion of that resource's
    content. The alternative of letting fragments work differently for
    URNs vs. URLs strikes me as very unlikely to work well,
    especially if 3986-style relative reference processing can be
    applied to URNs.

    

      

        

        3. Qualifiers that are transmitted to resources (when
        applicable) for
        

        interpretation by the resources. These should not be included
        in
        

        comparisons or when considering persistence.
        

      

    

    

    This is analogous to query strings in HTTP. IMO it's vital to let
    URNs be able to bundle the name of the base resource with some input
    to be transmitted to the resource. So similar to fragments, I
    think that if urn:example:a
    resolves to http://example.com/b,
    then urn:example:a?c
    should ultimately result in a GET of http://example.com/b?c . Again,
    urn:example:a
    is persistent while urn:example:a?c
    has no assurance of persistence.

    

      

        

        4. Qualifiers that affect resolution of the URN, and which
        should be
        

        transmitted to the resolution service if one is used, either to
        request
        

        a specific kind of resolution service, or to narrow down between
        

        multiple versions and/or representations of the content.

    

    

    For the sake of an example of how this might be used, let's say that
    such a qualifier must begin with "??", that it appears before
    q-component, and the value of that qualifier is not allowed to
    contain "?" without it being %-encoded. I'll tentatively call this
    an "r-component" ("r" for resolution)

    

    
    
      
  • urn:example:a
        would refer to the resource without specifying what to do with
        the URN. If such a URN appeared in a link in a resource being
        viewed in a browser, and a user clicked on that link, the
        browser might try to present the content to the user. Or
        failing that, it might simply try to get a description of the
        resource and display that. If OTOH, such a URN appeared in an
        IMG tag the browser might give up if it couldn't get the content
        - presumably the description of the resource isn't an image.
    • 
      
  • urn:example:a??request=content
        would tell the resolution service (and perhaps also the client)
        that the reference was specifically intended to be for the
        resource's content, and not to locations, or any kind of
        description or metadata of the resource
    • 
      
  • urn:example:a??request=metadata;format=dc-rdf
          might request that the resolution service return a
        description of the resource in RDF format and the Dublin Core
        schema.
    • 
      
  • urn:example:a??request=locations
        could request locations of the resource
    • 
      
  • urn:example:a??request=content;version=first
        could request the earliest version of the resource
    • 
    

    
Basically these qualifiers would serve as a kind of query to the
      resolution service (as opposed to a query to be sent to the
      resource). It's like searching for a resource in a library's
      catalog and specifying some details that narrow the results along
      with the query.

    

    
As far as I can tell, this kind of capability is vitally
      important, because almost every time I see any functionality of a
      resolution service described, there's at least one or two examples
      of how one might include such queries with a URN. IMO, if URNs
      don't provide a standard way to do it, URN resolution services
      will overload "?" and the result will be that (a) you can't
      specify a URN that includes a query to be sent to the resource
      itself (at least not in any uniform way) and (b) different schemes
      will behave differently and it will be difficult to write clients
      that treat Uniform Resource Names in any kind of uniform fashion.

    

    Of course the above are just examples of what could be done, rather
    than a well thought-out proposal. I would also suggest that
    namespaces should be able to define their own requests and
    parameters independently of others. So for the "ietf" namespace,
    IETF should be able to support things like 

urn:ietf:rfc:XXXX??request=ietf.version-history;option=include-I-Ds

      

    

      

      I continue to struggle with two things (or perhaps misconceptions
      in my own mind) about our discussions:
      

      

      (a) Not all URNs need to be or can be resolved, and it seems to me
      that even URNs that can be resolved are primarily used to identify
      resources and not to resolve resources (which is why we have URLs,
      after all).
      

      

      (b) We don't know enough about the running code of modern, actual
      URN resolution services to helpfully specify what kind of syntax
      they might require.
      

      

      Regarding (a), we have (i) a large number of URN namespaces that
      are used by other SDOs or quasi-SDOs to assign identifiers for
      uses like XML namespaces. I strongly encourage the WG participants
      to spend some time looking through the list of formal namespaces:
      

      

http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
      

      

      As far as I can see, most of the URNs that are assigned in those
      namespaces aren't intended to be resolved at all. They are, in the
      perhaps less than perfect terminology of 2141bis, "abstract
      designators". In these cases, there is simply no need to worry
      about qualifiers 3 & 4.
      

    

    

    There's been a lot of misunderstanding and misuse of URNs. URNs
    were intended to name resources, not to merely be unique strings.
    I don't mind if people sometimes use URNs as merely unique strings,
    as I don't think it does much harm - except that some people have
    gotten the idea that this is the primary purpose of URNs. It's
    not. I don't even recall that particular use case even being
    mentioned through years of discussions about URNs in the
    mid-1990s. To the extent URNs are usable in this way, it's a
    corner-case, an unintended consequence, not the general or typical
    case.

    

    More generally, statements about how URNs "should be" that are based
    on observations of current namespaces or currently-observed usage of
    URNs strike me as about as valid as statements about how IPv6 should
    be, based on currently-observed usage of IPv6. URNs, like IPv6,
    have been around for ~20 years, were designed to be usable for a
    very long time, but are really just starting to be used. What
    we're seeing now with URNs (just like what we saw with IPv6 until
    recently) is still mostly due to early adopters, and shouldn't be
    considered as any indication of what will be typical of future
    use. The communities that are most interested in using URNs
    properly are conservative by their very nature.

    

    

      We also have (ii) a few URN namespaces (albeit namespaces with a
      huge number of assigned URNs) where resolution is at least
      possible. These are namespaces such as those for ISBNs, ISSNs, and
      NBNs. However, even here I think (perhaps without sufficient
      basis) that these URNs are assigned primarily for the purpose of
      identification ("this URN identifies that work") and not for the
      purpose of resolution ("this URN enables you to find a copy of
      that work on a shelf in this building").
      

    

    

    See above. Of course ISBNs and ISSNs were in wide use long before
    URNs were standardized, and all of these numbers were
    "grandfathered" as URNs, so it's not at all surprising that there
    are huge numbers of these. Again, their use should not be taken as
    a prescription for how URNs will, or should, be "typically" used in
    the future.

    

    Of course - the primary purpose of a URN *is* to identify a
    resource. But if you encounter a reference to a URN on a computer
    that's attached to the Internet (or even an isolated, private
    network), then it's quite likely you will find it useful to not
    merely be able to identify that resource, but also to query for
    information about that resource, and/or try to access the resource
    or obtain its content. You won't always be able to do these things
    for any of a large number of reasons, e.g. the URN isn't known to
    any of the resolution services you consult; the URN refers to a
    resource that isn't amenable to network access or isn't online; you
    don't have permission to access it, etc. But just because such
    services won't always be available is no reason to cripple URNs in
    such a way as to make it more difficult to provide those services.
    

    

    URNs were always intended to be able to support resolution. Back
    to the IPv6 analogy, saying that URNs supporting resolution is of
    secondary importance is about like saying that the ability IPv6 to
    access hosts not on the IPv4 Internet is of secondary importance,
    because hardly anyone is doing that at the moment. (of course
    that's really not true but many haven't noticed yet)

    

    

      

      When I combine the (to me) secondary importance of resolution for
      URNs with the fact that we don't know much about the running code
      of URN resolution services, I find myself at a loss to define the
      syntax, and certainly the semantics, of qualifiers 3 & 4 with
      any degree of precision. That is why I think 2141bis needs to be
      somewhat general about the syntax of those qualifiers (other than
      making sure that syntax is consistent with the URI syntax).
      

    

    

    I don't think we need (or want) a huge amount of precision. In
    particular I don't think we should try to define a complete
    vocabulary for requests to resolution services and their parameters,
    and would actually prefer to see that work done outside of IETF.
    What I'd like to see is:

    

    
    
      
  • a small modification to the 2414bis grammar for URNs, to
        permit "r-components" in addition to f-, p- and q-components.
        (I think we can do this without breaking 3986 parsers, and with
        low risk of conflict with existing use of query strings.)
    
      
    • 
      
  • a grammar for r-component that allows multiple parameter names
        and associated values within that r-component to be specified to
        resolution services
    • 
      
  • an IANA registry for parameter names and/or associated values,
        with expert review required to add new ones, and each namespace
        having its own reserved prefix that it can do with as it wishes
    
      
    • 
      
  • a very minimal initial set of parameters, probably just
        defining "request" and "format" with an IANA registry for the
        names associated each, and 3 or 4 very basic requests.
    
      
    • 
    

    
I'm thinking this should be around 2-3 pages added to 2141bis,
      and I'm willing to draft text. 

    

    

    

      

      As an example, we might need to wait until we know a lot more
      about modern URN resolution systems before we can define
      name-value pairs for q-components.
      

    

    

    IMO, rather than wait, we should let people who are building URN
    resolution systems define that vocabulary. IETF's role should be
    to try to get the underlying protocol right, and to make sure that
    URNs (+ 3986 rules) don't inhibit resolution or uniform handling,
    and don't cause breakage when used with resources also named by
    URLs.  IETF's role should not be to try to discover for itself how
    to design a query language for a resource cataloging system. 

    

    

      

      And, to be clear, for the limited purposes of 2141bis I think that
      is fine. As I see it, the alternative is that this WG would
      postpone its delivery of updates to RFC 2141 much longer than it
      already has, with very little to show for that further delay and a
      great risk of failure or fragmentation.
      

    

    

    I think that the risk of failure or fragmentation is actually much
    greater if we fail to specify how to distinguish between each of the
    4 types of qualifiers in a uniform way. 

    

    Or to put it a different way, there are two ways to get
    failure/fragmentation: One is for us to delay so long that each
    namespace or community goes off and does things its own way, and the
    other is for us to fail to specify things completely or correctly
    enough so that each namespace or community is forced to do things
    its own way.

    

    Keith

    

  


--------------050806000006080402030303--


From nobody Thu Apr 16 05:29:16 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306281B3120 for ; Thu, 16 Apr 2015 05:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTeKsdeQFuG7 for ; Thu, 16 Apr 2015 05:29:13 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8824B1B311D for ; Thu, 16 Apr 2015 05:29:13 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E64EC20BFE for ; Thu, 16 Apr 2015 08:29:12 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 16 Apr 2015 08:29:12 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ND5xTuREByi3oPv GyKTpvbqTKhg=; b=ePNOW+ACgvYM7QiahcCcic/4pBe8svwcTfDlJ+O9APzUc4d 04oN76v6kJgdT502sr5FUY1giARr/JOcZHMHNymvln7dpN77X0WvF5ta3O9i08kC HkW/rjAUoIlNgAJ3BOvG69c38hmDPYVubc1K1qFwUXZBAWCSE1cGk25fgzRQ=
X-Sasl-enc: RaHfoXWkyNZ6GzaV0XfdtbSbrv3PowWHbBOshDYXs1Tn 1429187352
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 861346800F9; Thu, 16 Apr 2015 08:29:12 -0400 (EDT)
Message-ID: <552FAB04.1040205@network-heretics.com>
Date: Thu, 16 Apr 2015 08:28:52 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <55142CA1.2000509@network-heretics.com> <587F32051FF797206A169FC6@JcK-HP8200.jck.com> <551B0E58.3010709@network-heretics.com> <552F262E.1040602@andyet.net>
In-Reply-To: <552F262E.1040602@andyet.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Namespace consensus and registrations
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Apr 2015 12:29:15 -0000

On 04/15/2015 11:02 PM, Peter Saint-Andre - &yet wrote:
>> Perhaps the simplest and clearest response that I can offer is that I
>> don't care what the label is ("Expert Review" vs "IETF Consensus" or
>> whatever), so much as I care that there be an opportunity for public
>> review.   If the process specified for "Expert Review" requires that
>> there be public review, that the opportunity for review is advertised in
>> IETF and other appropriate fora, and especially if we can somehow
>> arrange that the "expert(s)" considering the results of that public
>> review really do understand the subtleties of URNs (admitting that this
>> is really difficult), I'm okay with that and think it's about the best
>> that we can do. It's potentially even better than "IETF Consensus"
>> because while that does require public review, nothing about the process
>> for choosing Area Directors ensures that IESG will have URN expertise.
>>
>> So I'll be very interested to read -11's text on this subject.
>
> Even before version -11, 2141bis (and before that 3406) stipulated 
> that discussion was to occur on the urn-nid@ietf.org list. I would 
> prefer that we deprecate the urn-nid list and have discussion on this 
> list, but in any case, yes, public review is very much part of the 
> process.

Given the apparently small number of active participants on this list, 
I'm not sure that's the best way to ensure wide review among the 
communities who would be most concerned with maintaining URN sanity.   I 
realize that having narrowly-focused but yet mostly-unmoderated mailing 
lists that can occasionally blow up is the IETF Way, but there might be 
some parties who would just like to get something similar to Last Call 
announcements for URN namespaces without having to subject themselves to 
arbitrary amounts of email traffic.  Even within IETF, there seems to be 
a set of people who are interested in and knowledgeable about URNs who 
don't participate on this list.

Maybe there could be two lists, urn-announce and urn-discuss? (perhaps 
this list could serve the latter role)   urn-announce traffic could be 
forwarded to urn-discuss, but not vice versa?   Any announcements of 
proposed URN changes could be sent to urn-announce but would request 
that responses be sent directly to the expert(s) evaluating the proposal 
rather than as replies to the urn-announce list.

(Also, the comment period should last long enough that any organization 
that cares would have time to discuss things within its membership and 
form its own opinion, which probably means a comment period should last 
considerably longer than a month.)

Keith


From nobody Thu Apr 16 06:30:41 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1CA1ACE4B for ; Thu, 16 Apr 2015 06:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mxtRX9evcbe for ; Thu, 16 Apr 2015 06:30:36 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3F31ACE3B for ; Thu, 16 Apr 2015 06:30:36 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D87AF2104E for ; Thu, 16 Apr 2015 09:30:35 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 16 Apr 2015 09:30:35 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=VxOCHgm6Fwio7zp9A3K2dsx0M8s=; b=D9EIn IdxR5HJiDGfu7FvY5rknsNyaXbXGi2Cx6ltSrVqvVN7ZLry9rv2vUEuiuocdWibR qXK1GHbsrY6mvyZWvDsMHvxsRFhPOyXMkobxnOMqfRpBHWUmY3u+n+Gx50qJWGc9 RqlM2BJPGqPlSymeK5BndHX5VBRgqkCCnparDQ=
X-Sasl-enc: Mh0mATmPv0TIItgv4aStDtYiR2rTVO+VOJqrubsOCjZq 1429191035
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 7B5AB6800B9; Thu, 16 Apr 2015 09:30:35 -0400 (EDT)
Message-ID: <552FB967.9080606@network-heretics.com>
Date: Thu, 16 Apr 2015 09:30:15 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com> <551F266E.4000507@network-heretics.com> <552F1C24.6040006@andyet.net>
In-Reply-To: <552F1C24.6040006@andyet.net>
Content-Type: multipart/alternative; boundary="------------060902030109000204020409"
Archived-At: 
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Apr 2015 13:30:39 -0000

This is a multi-part message in MIME format.
--------------060902030109000204020409
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 04/15/2015 10:19 PM, Peter Saint-Andre - &yet wrote:
>> I would prefer it if we can agree on some limitations on namespaces that
>> use '/' in NSSs that will render path-relative references either useful
>> or "mostly harmless" (depending on the particular discipline chose by
>> that namespace).   As I stated above, I think we're going to want to be
>> able to use URNs to refer to resources that contain path-relative
>> references without breaking those references.   We should certainly be
>> able to use URNs to name HTML documents, for instance.
>
> Keith, would you mind clarifying that last sentence?
>
> Here's why I ask. To my mind, we should certainly be able to use URNs 
> to name documents (if by document we mean a created work, not any 
> particular copy of that created work). Such a work might be an 
> electronic document that could be constructed using any of a number of 
> particular technologies: SGML, XML, HTML, EPUB, MS Word, PDF, 
> markdown, TeX, LaTeX, you name it. Although I agree that we should 
> certainly be able to use URNs to name electronic documents, I don't 
> see why HTML is special here (I'm not saying you think it's special, 
> BTW). Would you also agree that we should certainly be able to use 
> URNs to name PDF documents or MS Word documents or EPUB documents?

I absolutely agree that we should be able to use URNs to name any of the 
above kinds of resources.   The reason I cited HTML as an example above 
is because (a) it's presumably familiar to most list readers, and (b) 
HTML is a kind of resource that potentially uses path-relative references.

For example, if there are one or more URNs that refer to a document that 
contains a link to "../../foo", the behavior of that link when the 
document is accessed via any of those URNs should be reasonable, 
well-defined, and namespace-independent.  Ideally, the defined behavior 
of that link should be consistent with the behavior when the same 
document is referred to by a URL that contains a path.

(Though I realize that such links can behave inconsistently even with 
multiple URLs point to such a document   So I suppose the most that can 
be asked is that it be possible for path-relative links in documents to 
/be able to/ work as well when referred to by URNs as they can work when 
referred to by URLs.)

Keith


--------------060902030109000204020409
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 04/15/2015 10:19 PM, Peter
      Saint-Andre - &yet wrote:

    

    

      
I would prefer it
        if we can agree on some limitations on namespaces that
        

        use '/' in NSSs that will render path-relative references either
        useful
        

        or "mostly harmless" (depending on the particular discipline
        chose by
        

        that namespace). As I stated above, I think we're going to
        want to be
        

        able to use URNs to refer to resources that contain
        path-relative
        

        references without breaking those references. We should
        certainly be
        

        able to use URNs to name HTML documents, for instance.
        

      

      

      Keith, would you mind clarifying that last sentence?
      

      

      Here's why I ask. To my mind, we should certainly be able to use
      URNs to name documents (if by document we mean a created work, not
      any particular copy of that created work). Such a work might be an
      electronic document that could be constructed using any of a
      number of particular technologies: SGML, XML, HTML, EPUB, MS Word,
      PDF, markdown, TeX, LaTeX, you name it. Although I agree that we
      should certainly be able to use URNs to name electronic documents,
      I don't see why HTML is special here (I'm not saying you think
      it's special, BTW). Would you also agree that we should certainly
      be able to use URNs to name PDF documents or MS Word documents or
      EPUB documents?
      

    

    

    I absolutely agree that we should be able to use URNs to name any of
    the above kinds of resources. The reason I cited HTML as an
    example above is because (a) it's presumably familiar to most list
    readers, and (b) HTML is a kind of resource that potentially uses
    path-relative references.

    

    For example, if there are one or more URNs that refer to a document
    that contains a link to "../../foo", the behavior of that link when
    the document is accessed via any of those URNs should be reasonable,
    well-defined, and namespace-independent. Ideally, the defined
    behavior of that link should be consistent with the behavior when
    the same document is referred to by a URL that contains a path. 

    

    (Though I realize that such links can behave inconsistently even
    with multiple URLs point to such a document So I suppose the most
    that can be asked is that it be possible for path-relative links in
    documents to be able to work as well when referred to by
    URNs as they can work when referred to by URLs.)

    

    Keith

    

  


--------------060902030109000204020409--


From nobody Thu Apr 16 23:10:47 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7911ACE85 for ; Thu, 16 Apr 2015 23:10:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHcm1II4gnlS for ; Thu, 16 Apr 2015 23:10:39 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D788B1ACEA9 for ; Thu, 16 Apr 2015 23:10:37 -0700 (PDT)
Received: from AM3PR07MB369.eurprd07.prod.outlook.com (10.242.109.143) by AM3PR07MB371.eurprd07.prod.outlook.com (10.242.109.150) with Microsoft SMTP Server (TLS) id 15.1.136.25; Fri, 17 Apr 2015 06:10:20 +0000
Received: from AM3PR07MB369.eurprd07.prod.outlook.com ([10.242.109.143]) by AM3PR07MB369.eurprd07.prod.outlook.com ([10.242.109.143]) with mapi id 15.01.0136.026; Fri, 17 Apr 2015 06:10:20 +0000
From: "Hakala, Juha E" 
To: Keith Moore , "urn@ietf.org" 
Thread-Topic: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
Thread-Index: AQHQbkdq6P5r65B0EEyEivJbQdoLhp079F4AgBMGjACAALt4gIAA+TTw
Date: Fri, 17 Apr 2015 06:10:20 +0000
Message-ID: 
References: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com> <551F266E.4000507@network-heretics.com> <552F1C24.6040006@andyet.net> <552FB967.9080606@network-heretics.com>
In-Reply-To: <552FB967.9080606@network-heretics.com>
Accept-Language: fi-FI, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: network-heretics.com; dkim=none (message not signed) header.d=none;
x-originating-ip: [128.214.71.180]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB371;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(24454002)(377454003)(479174004)(2501003)(19300405004)(102836002)(93886004)(76576001)(19580405001)(122556002)(77096005)(86362001)(4001410100001)(2900100001)(40100003)(19580395003)(87936001)(16236675004)(2656002)(107886001)(74316001)(50986999)(106116001)(19625215002)(33656002)(19617315012)(74482002)(76176999)(77156002)(92566002)(15975445007)(2950100001)(62966003)(54356999)(66066001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB371; H:AM3PR07MB369.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:AM3PR07MB371; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB371; 
x-forefront-prvs: 0549E6FD50
Content-Type: multipart/alternative; boundary="_000_AM3PR07MB369409F3766FFBEA275A7DEFAE30AM3PR07MB369eurprd_"
MIME-Version: 1.0
X-OriginatorOrg: helsinki.fi
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2015 06:10:20.5310 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB371
Archived-At: 
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Apr 2015 06:10:46 -0000

--_000_AM3PR07MB369409F3766FFBEA275A7DEFAE30AM3PR07MB369eurprd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,

Library community has well established practices for how to use identifiers=
. URNBIS could use these practices as the starting point, extend them if ne=
eded and alter them only when there is a good reason to do so. As a result =
URNBIS should have a more unified understanding of what kind of functionali=
ty needs to be supported now, and what can be postponed for the time being.

There are already international standard identifiers for:


-          Works, which are immaterial entities (such as The Tragicall Hist=
orie of Hamlet, Prince of Denmarke)


-          Expressions, which are translations and other versions of these =
works (such as a Finnish translation of Hamlet or a cartoon version of the =
original English text)


-          Manifestations, which are physical embodiments of works & expres=
sions. Physical may mean hand-held (printed) or electronic (PDF, EPUB3, etc=
.).


-          Public identities, which are not the same as persons;  George Or=
well is a public identity but the person behind it was Eric Blair. Public i=
dentity can also belong to a legal entity (Rolling Stones or IETF) or a fig=
ment of author's imagination (such as Winnie the Pooh).

Item (or copy) identifiers are work in progress. ISO TC 46/SC 9 is currentl=
y developing International Standard Item Identifier, with which it will be =
possible to identify particular items, such as the copy of Diophantus' Arit=
hmetica containing some interesting comments by Pierre de Fermat.

The underlying data model which binds all these bibliographic and other ent=
ities together is FRBR (http://en.wikipedia.org/wiki/Functional_Requirement=
s_for_Bibliographic_Records). While it is important that we can identify th=
ings uniquely and persistently, the real aim is more ambitious: to create l=
inked data. Libraries will - via collective effort, and in cooperation with=
 museums and archives - interconnect related works such as the original Ham=
let and Laurence Olivier's 1948 movie (or to be more precise, metadata reco=
rds describing these works in our catalogues), works and their expressions,=
 works / expressions and their manifestations, and manifestations and their=
 items.

This kind of functionality is not widely available in library systems yet, =
but there are some systems which provide already a glimpse of what the futu=
re will look like. OCLC's WorldCat is my favourite; see for instance the se=
arch results for Gone with the wind:

http://www.worldcat.org/search?q=3Dgone+with+the+wind%2C+by+margaret+mitche=
ll&qt=3Dowc_search

In order to provide a solid basis for decentralized creation of linked data=
 we need persistent identifiers from works to items (and metadata formats w=
hich enable us to specify the different roles these identifiers will have; =
in a work metadata record manifestation identifier acts as a link and vice =
versa). URN qualifiers will not be needed for identification, but it is nec=
essary to use q-component for e.g. enabling the users to request metadata f=
or a work with the q-component. They will then be able to see that there ar=
e related works and expressions (and take a closer look at them).  F-compon=
ent will not be relevant for us, but users will be able to cite documents w=
ith them and manifestation identifiers. I can't see any need for the p-comp=
onent for the time being.

Rich data models such as FRBR are a must in digital archives, since eventua=
lly they will contain several manifestations of most archived digital resou=
rces, if migration is the preferred preservation method. A user may initial=
ly find an outdated version of a document; in such situation it is importan=
t to find out that there are more modern versions available (and also that =
these versions will not have exactly the same look and feel than the origin=
al).

The scope of the URN system as a whole cannot be defined meaningfully since=
 each new namespace (and changes in identifier systems which already have a=
 namespace) alters the situation. At the moment URN does not specifically t=
arget e.g. public identities, but if a namespace is registered for Internat=
ional Standard Name Identifier, the problem is solved. As far as I am conce=
rned, URNs can be used to identify resources (whatever they are), just like=
 DOI is already being used to identify all sorts of objects (in DOI, it is =
the identifier itself which is digital, the identified object does not need=
 to be).

Juha


From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Keith Moore
Sent: 16. huhtikuuta 2015 16:30
To: urn@ietf.org
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relat=
ive references)

On 04/15/2015 10:19 PM, Peter Saint-Andre - &yet wrote:
I would prefer it if we can agree on some limitations on namespaces that
use '/' in NSSs that will render path-relative references either useful
or "mostly harmless" (depending on the particular discipline chose by
that namespace).   As I stated above, I think we're going to want to be
able to use URNs to refer to resources that contain path-relative
references without breaking those references.   We should certainly be
able to use URNs to name HTML documents, for instance.

Keith, would you mind clarifying that last sentence?

Here's why I ask. To my mind, we should certainly be able to use URNs to na=
me documents (if by document we mean a created work, not any particular cop=
y of that created work). Such a work might be an electronic document that c=
ould be constructed using any of a number of particular technologies: SGML,=
 XML, HTML, EPUB, MS Word, PDF, markdown, TeX, LaTeX, you name it. Although=
 I agree that we should certainly be able to use URNs to name electronic do=
cuments, I don't see why HTML is special here (I'm not saying you think it'=
s special, BTW). Would you also agree that we should certainly be able to u=
se URNs to name PDF documents or MS Word documents or EPUB documents?

I absolutely agree that we should be able to use URNs to name any of the ab=
ove kinds of resources.   The reason I cited HTML as an example above is be=
cause (a) it's presumably familiar to most list readers, and (b) HTML is a =
kind of resource that potentially uses path-relative references.

For example, if there are one or more URNs that refer to a document that co=
ntains a link to "../../foo", the behavior of that link when the document i=
s accessed via any of those URNs should be reasonable, well-defined, and na=
mespace-independent.  Ideally, the defined behavior of that link should be =
consistent with the behavior when the same document is referred to by a URL=
 that contains a path.

(Though I realize that such links can behave inconsistently even with multi=
ple URLs point to such a document   So I suppose the most that can be asked=
 is that it be possible for path-relative links in documents to be able to =
work as well when referred to by URNs as they can work when referred to by =
URLs.)

Keith

--_000_AM3PR07MB369409F3766FFBEA275A7DEFAE30AM3PR07MB369eurprd_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hello,<=
/p>

 <=
/p>

Library co=
mmunity has well established practices for how to use identifiers. URNBIS c=
ould use these practices as the starting point, extend them
 if needed and alter them only when there is a good reason to do so. As a r=
esult URNBIS should have a more unified understanding of what kind of funct=
ionality needs to be supported now, and what can be postponed for the time =
being.  


 =
;


There are =
already international standard identifiers for:


 =
;


-         
Wo=
rks, which are immaterial entities (such as The Tragicall Historie of Hamle=
t, Prince of Denmarke)


 =
;


-         
Ex=
pressions, which are translations and other versions of these works (such a=
s a Finnish translation of Hamlet or a cartoon version of
 the original English text)


 =
;


-         
Ma=
nifestations, which are physical embodiments of works & expressions. Ph=
ysical may mean hand-held (printed) or electronic (PDF, EPUB3,
 etc.).


 =
;


-         
Pu=
blic identities, which are not the same as persons;  George Orwell is =
a public identity but the person behind it was Eric Blair. Public
 identity can also belong to a legal entity (Rolling Stones or IETF) or a f=
igment of author’s imagination (such as Winnie the Pooh).  =



 =
;


Item (or c=
opy) identifiers are work in progress. ISO TC 46/SC 9 is currently developi=
ng International Standard Item Identifier, with which it will
 be possible to identify particular items, such as the copy of Diophantus&#=
8217; Arithmetica containing some interesting comments by Pierre de Fermat.



 =
;


The underl=
ying data model which binds all these bibliographic and other entities toge=
ther is FRBR (http://en.wikipedia.org/wiki/Functional_Requi=
rements_for_Bibliographic_Records).
 While it is important that we can identify things uniquely and persistentl=
y, the real aim is more ambitious: to create linked data. Libraries will &#=
8211; via collective effort, and in cooperation with museums and archives -=
 interconnect related works such as the
 original Hamlet and Laurence Olivier’s 1948 movie (or to be more pre=
cise, metadata records describing these works in our catalogues), works and=
 their expressions, works / expressions and their manifestations, and manif=
estations and their items.


 =
;


This kind =
of functionality is not widely available in library systems yet, but there =
are some systems which provide already a glimpse of what the
 future will look like. OCLC’s WorldCat is my favourite; see for inst=
ance the search results for Gone with the wind:



 =
;


http://www=
.worldcat.org/search?q=3Dgone+with+the+wind%2C+by+marga=
ret+mitchell&qt=3Dowc_search


 =
;


In order t=
o provide a solid basis for decentralized creation of linked data we need p=
ersistent identifiers from works to items (and metadata formats
 which enable us to specify the different roles these identifiers will have=
; in a work metadata record manifestation identifier acts as a link and vic=
e versa). URN qualifiers will not be needed for identification, but it is n=
ecessary to use q-component for
 e.g. enabling the users to request metadata for a work with the q-componen=
t. They will then be able to see that there are related works and expressio=
ns (and take a closer look at them).  F-component will not be relevant=
 for us, but users will be able to cite
 documents with them and manifestation identifiers. I can’t see any n=
eed for the p-component for the time being.



 =
;


Rich data =
models such as FRBR are a must in digital archives, since eventually they w=
ill contain several manifestations of most archived digital
 resources, if migration is the preferred preservation method. A user may i=
nitially find an outdated version of a document; in such situation it is im=
portant to find out that there are more modern versions available (and also=
 that these versions will not have
 exactly the same look and feel than the original). 


 =
;


The scope =
of the URN system as a whole cannot be defined meaningfully since each new =
namespace (and changes in identifier systems which already
 have a namespace) alters the situation. At the moment URN does not specifi=
cally target e.g. public identities, but if a namespace is registered for I=
nternational Standard Name Identifier, the problem is solved. As far as I a=
m concerned, URNs can be used to
 identify resources (whatever they are), just like DOI is already being use=
d to identify all sorts of objects (in DOI, it is the identifier itself whi=
ch is digital, the identified object does not need to be).   &nbs=
p; 


 =
;


Juha  =
; 


 =
;


 








From:=
 urn [mailto:urn-bou=
nces@ietf.org]
On Behalf Of Keith Moore

Sent: 16. huhtikuuta 2015 16:30

To: urn@ietf.org

Subject: Re: [urn] Re-examining p-components (and "/", hie=
rarchy, and relative references)






 




On 04/15/2015 10:19 PM, Peter Saint-Andre - &yet=
 wrote:








I would prefer it if we can agree on some limitation=
s on namespaces that


use '/' in NSSs that will render path-relative references either useful 
or "mostly harmless" (depending on the particular discipline chos=
e by 

that namespace).   As I stated above, I think we're going to want=
 to be 

able to use URNs to refer to resources that contain path-relative 

references without breaking those references.   We should certain=
ly be 

able to use URNs to name HTML documents, for instance. 






Keith, would you mind clarifying that last sentence? 



Here's why I ask. To my mind, we should certainly be able to use URNs to na=
me documents (if by document we mean a created work, not any particular cop=
y of that created work). Such a work might be an electronic document that c=
ould be constructed using any of
 a number of particular technologies: SGML, XML, HTML, EPUB, MS Word, PDF, =
markdown, TeX, LaTeX, you name it. Although I agree that we should certainl=
y be able to use URNs to name electronic documents, I don't see why HTML is=
 special here (I'm not saying you
 think it's special, BTW). Would you also agree that we should certainly be=
 able to use URNs to name PDF documents or MS Word documents or EPUB docume=
nts?





=


I absolutely agree that we should be able to use URNs to name any of the ab=
ove kinds of resources.  
The reason I cited HTML as an example above is because (a) it's pres=
umably familiar to most list readers, and (b) HTML is a kind of resource th=
at potentially uses path-relative references.



For example, if there are one or more URNs that refer to a document that co=
ntains a link to "../../foo", the behavior of that link when the =
document is accessed via any of those URNs should be reasonable, well-defin=
ed, and namespace-independent.  Ideally, the
 defined behavior of that link should be consistent with the behavior when =
the same document is referred to by a URL that contains a path. 




(Though I realize that such links can behave inconsistently even with multi=
ple URLs point to such a document   So I suppose the most that ca=
n be asked is that it be possible for path-relative links in documents to
be able to work as well when referred to by URNs as they can work wh=
en referred to by URLs.)



Keith








--_000_AM3PR07MB369409F3766FFBEA275A7DEFAE30AM3PR07MB369eurprd_--


From nobody Fri Apr 17 06:29:25 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920301B2C6B for ; Fri, 17 Apr 2015 06:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwAG-5hfQ1JP for ; Fri, 17 Apr 2015 06:29:18 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F44A1B2C6A for ; Fri, 17 Apr 2015 06:29:18 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id EAF5220B4A for ; Fri, 17 Apr 2015 09:29:17 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 17 Apr 2015 09:29:17 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=Lpx7u63IRkfDwz1jxYXgUkh9mEw=; b=TmWDo Tveg/jnpR+UIKguOBBBpGiKm3uqxPia6RY/gIlhRD27gvvXUywS0cHuEPID8jyxn l8K/rxJIkBGpzLqv6VyN393ed5QnDEX63w+sTLIs0INZDetBxCCJaeksltZdGviG QZxP7/m+JdC9EVbn3UbLhbRgNAhL5q58+mj87k=
X-Sasl-enc: dHIuKXXiCgeXe08jjqKhbNDT2gR6Bjy6lIRkmFAwWnHW 1429277357
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 61DA5C0001D; Fri, 17 Apr 2015 09:29:17 -0400 (EDT)
Message-ID: <55310A96.8080900@network-heretics.com>
Date: Fri, 17 Apr 2015 09:28:54 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Hakala, Juha E" , "urn@ietf.org" 
References: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com> <551F266E.4000507@network-heretics.com> <552F1C24.6040006@andyet.net> <552FB967.9080606@network-heretics.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080301050808050600080402"
Archived-At: 
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Apr 2015 13:29:23 -0000

This is a multi-part message in MIME format.
--------------080301050808050600080402
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Juha,

This all sounds marvelous and I look forward to the day when this is in 
place.

My main questions are with how this system of identifiers and 
relationships interfaces to the world of network-accessible resources, 
which may be interactive and/or have their own rich set of internal 
links to one another.

Also, I'm primarily a network protocols person.   So whenever I look at 
something like this I ask myself how it will be implemented in network 
protocols, and whether those protocols will be organized in such a way 
as facilitate the use of those identifiers and relationships, or hinder 
such use.   One way that the network protocols can hinder such use is by 
not permitting URNs to be handled in a uniform way.   So if every 
different URN namespace has different rules for how software needs to 
request resolution (like which components to include), or if q-component 
works differently for different URN namespaces, or relative references 
work differently for different URN namespaces, any of those things could 
hinder use.

Since there are already numerous resources that are referred to using 
URLs and which accept queries, I would like it to be possible to name 
those resources (or at least some of those resources) with URNs without 
losing the ability to send queries to those resources.   So given the 
large amount of mindshare around using ? to introduce queries to those 
resources, to me it makes more sense to use URN q-component for that 
purpose also, and to define a different component to enable requests for 
things like metadata.

Also, I don't like RFC 3986's treatment of URNs at all.  But perhaps 
unfortunately, there's a large amount of mindshare around using not only 
3986 syntax for URNs but also its rules for relative references with 
URNs.   And part of what that means to me is that if we use 3986 syntax 
for URN components that weren't permitted in 2141, it's going to be 
difficult for URNs to avoid being hampered by 3986's rules for relative 
references and by the expectations in the web world for what those 
components mean.

So I think URNBIS needs to strong and technically sound statement about 
how to resolve the conflict between the needs of URNs, and this large 
amount of mindshare.  And URNBIS needs to do so in a way that both 
preserves the ability of the library community to further its goals, and 
also preserves the ability of network-accessible resources to accept 
queries, have relative references, allow identified subsets of the 
results to be referenced, and so forth.   To my understanding, figuring 
out how to resolve this conflict is the primary problem that is 
currently before us.

Keith

On 04/17/2015 02:10 AM, Hakala, Juha E wrote:
>
> Hello,
>
> Library community has well established practices for how to use 
> identifiers. URNBIS could use these practices as the starting point, 
> extend them if needed and alter them only when there is a good reason 
> to do so. As a result URNBIS should have a more unified understanding 
> of what kind of functionality needs to be supported now, and what can 
> be postponed for the time being.
>
> There are already international standard identifiers for:
>
> -Works, which are immaterial entities (such as The Tragicall Historie 
> of Hamlet, Prince of Denmarke)
>
> -Expressions, which are translations and other versions of these works 
> (such as a Finnish translation of Hamlet or a cartoon version of the 
> original English text)
>
> -Manifestations, which are physical embodiments of works & 
> expressions. Physical may mean hand-held (printed) or electronic (PDF, 
> EPUB3, etc.).
>
> -Public identities, which are not the same as persons;  George Orwell 
> is a public identity but the person behind it was Eric Blair. Public 
> identity can also belong to a legal entity (Rolling Stones or IETF) or 
> a figment of authors imagination (such as Winnie the Pooh).
>
> Item (or copy) identifiers are work in progress. ISO TC 46/SC 9 is 
> currently developing International Standard Item Identifier, with 
> which it will be possible to identify particular items, such as the 
> copy of Diophantus Arithmetica containing some interesting comments 
> by Pierre de Fermat.
>
> The underlying data model which binds all these bibliographic and 
> other entities together is FRBR 
> (http://en.wikipedia.org/wiki/Functional_Requirements_for_Bibliographic_Records). 
> While it is important that we can identify things uniquely and 
> persistently, the real aim is more ambitious: to create linked data. 
> Libraries will  via collective effort, and in cooperation with 
> museums and archives - interconnect related works such as the original 
> Hamlet and Laurence Oliviers 1948 movie (or to be more precise, 
> metadata records describing these works in our catalogues), works and 
> their expressions, works / expressions and their manifestations, and 
> manifestations and their items.
>
> This kind of functionality is not widely available in library systems 
> yet, but there are some systems which provide already a glimpse of 
> what the future will look like. OCLCs WorldCat is my favourite; see 
> for instance the search results for Gone with the wind:
>
> http://www.worldcat.org/search?q=gone+with+the+wind%2C+by+margaret+mitchell&qt=owc_search
>
> In order to provide a solid basis for decentralized creation of linked 
> data we need persistent identifiers from works to items (and metadata 
> formats which enable us to specify the different roles these 
> identifiers will have; in a work metadata record manifestation 
> identifier acts as a link and vice versa). URN qualifiers will not be 
> needed for identification, but it is necessary to use q-component for 
> e.g. enabling the users to request metadata for a work with the 
> q-component. They will then be able to see that there are related 
> works and expressions (and take a closer look at them).  F-component 
> will not be relevant for us, but users will be able to cite documents 
> with them and manifestation identifiers. I cant see any need for the 
> p-component for the time being.
>
> Rich data models such as FRBR are a must in digital archives, since 
> eventually they will contain several manifestations of most archived 
> digital resources, if migration is the preferred preservation method. 
> A user may initially find an outdated version of a document; in such 
> situation it is important to find out that there are more modern 
> versions available (and also that these versions will not have exactly 
> the same look and feel than the original).
>
> The scope of the URN system as a whole cannot be defined meaningfully 
> since each new namespace (and changes in identifier systems which 
> already have a namespace) alters the situation. At the moment URN does 
> not specifically target e.g. public identities, but if a namespace is 
> registered for International Standard Name Identifier, the problem is 
> solved. As far as I am concerned, URNs can be used to identify 
> resources (whatever they are), just like DOI is already being used to 
> identify all sorts of objects (in DOI, it is the identifier itself 
> which is digital, the identified object does not need to be).
>
> Juha
>
> *From:*urn [mailto:urn-bounces@ietf.org] *On Behalf Of *Keith Moore
> *Sent:* 16. huhtikuuta 2015 16:30
> *To:* urn@ietf.org
> *Subject:* Re: [urn] Re-examining p-components (and "/", hierarchy, 
> and relative references)
>
> On 04/15/2015 10:19 PM, Peter Saint-Andre - &yet wrote:
>
>         I would prefer it if we can agree on some limitations on
>         namespaces that
>         use '/' in NSSs that will render path-relative references
>         either useful
>         or "mostly harmless" (depending on the particular discipline
>         chose by
>         that namespace).   As I stated above, I think we're going to
>         want to be
>         able to use URNs to refer to resources that contain path-relative
>         references without breaking those references.   We should
>         certainly be
>         able to use URNs to name HTML documents, for instance.
>
>
>     Keith, would you mind clarifying that last sentence?
>
>     Here's why I ask. To my mind, we should certainly be able to use
>     URNs to name documents (if by document we mean a created work, not
>     any particular copy of that created work). Such a work might be an
>     electronic document that could be constructed using any of a
>     number of particular technologies: SGML, XML, HTML, EPUB, MS Word,
>     PDF, markdown, TeX, LaTeX, you name it. Although I agree that we
>     should certainly be able to use URNs to name electronic documents,
>     I don't see why HTML is special here (I'm not saying you think
>     it's special, BTW). Would you also agree that we should certainly
>     be able to use URNs to name PDF documents or MS Word documents or
>     EPUB documents?
>
>
> I absolutely agree that we should be able to use URNs to name any of 
> the above kinds of resources. The reason I cited HTML as an example 
> above is because (a) it's presumably familiar to most list readers, 
> and (b) HTML is a kind of resource that potentially uses path-relative 
> references.
>
> For example, if there are one or more URNs that refer to a document 
> that contains a link to "../../foo", the behavior of that link when 
> the document is accessed via any of those URNs should be reasonable, 
> well-defined, and namespace-independent.  Ideally, the defined 
> behavior of that link should be consistent with the behavior when the 
> same document is referred to by a URL that contains a path.
>
> (Though I realize that such links can behave inconsistently even with 
> multiple URLs point to such a document   So I suppose the most that 
> can be asked is that it be possible for path-relative links in 
> documents to /be able to/ work as well when referred to by URNs as 
> they can work when referred to by URLs.)
>
> Keith
>


--------------080301050808050600080402
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Juha,

      

      This all sounds marvelous and I look forward to the day when this
      is in place. 

      

      My main questions are with how this system of identifiers and
      relationships interfaces to the world of network-accessible
      resources, which may be interactive and/or have their own rich set
      of internal links to one another.

      

      Also, I'm primarily a network protocols person. So whenever I
      look at something like this I ask myself how it will be
      implemented in network protocols, and whether those protocols will
      be organized in such a way as facilitate the use of those
      identifiers and relationships, or hinder such use. One way that
      the network protocols can hinder such use is by not permitting
      URNs to be handled in a uniform way. So if every different URN
      namespace has different rules for how software needs to request
      resolution (like which components to include), or if q-component
      works differently for different URN namespaces, or relative
      references work differently for different URN namespaces, any of
      those things could hinder use.

      

      Since there are already numerous resources that are referred to
      using URLs and which accept queries, I would like it to be
      possible to name those resources (or at least some of those
      resources) with URNs without losing the ability to send queries to
      those resources. So given the large amount of mindshare around
      using ? to introduce queries to those resources, to me it makes
      more sense to use URN q-component for that purpose also, and to
      define a different component to enable requests for things like
      metadata.

      

      Also, I don't like RFC 3986's treatment of URNs at all. But
      perhaps unfortunately, there's a large amount of mindshare around
      using not only 3986 syntax for URNs but also its rules for
      relative references with URNs. And part of what that means to me
      is that if we use 3986 syntax for URN components that weren't
      permitted in 2141, it's going to be difficult for URNs to avoid
      being hampered by 3986's rules for relative references and by the
      expectations in the web world for what those components mean.

      

      So I think URNBIS needs to strong and technically sound statement
      about how to resolve the conflict between the needs of URNs, and
      this large amount of mindshare. And URNBIS needs to do so in a
      way that both preserves the ability of the library community to
      further its goals, and also preserves the ability of
      network-accessible resources to accept queries, have relative
      references, allow identified subsets of the results to be
      referenced, and so forth. To my understanding, figuring out how
      to resolve this conflict is the primary problem that is currently
      before us. 

      

      Keith

      

      On 04/17/2015 02:10 AM, Hakala, Juha E wrote:

    

    

      
      
      
      

        
Hello,

        

        
Library community has well established
            practices for how to use identifiers. URNBIS could use these
            practices as the starting point, extend them if needed and
            alter them only when there is a good reason to do so. As a
            result URNBIS should have a more unified understanding of
            what kind of functionality needs to be supported now, and
            what can be postponed for the time being. 

        

        
There are already international standard
            identifiers for:

        

        
-
              Works, which are immaterial entities (such as
            The Tragicall Historie of Hamlet, Prince of Denmarke)

        

        
-
              Expressions, which are translations and other
            versions of these works (such as a Finnish translation of
            Hamlet or a cartoon version of the original English text)

        

        
-
              Manifestations, which are physical embodiments
            of works & expressions. Physical may mean hand-held
            (printed) or electronic (PDF, EPUB3, etc.).

        

        
-
              Public identities, which are not the same as
            persons; George Orwell is a public identity but the person
            behind it was Eric Blair. Public identity can also belong to
            a legal entity (Rolling Stones or IETF) or a figment of
            authors imagination (such as Winnie the Pooh). 

        

        
Item (or copy) identifiers are work in
            progress. ISO TC 46/SC 9 is currently developing
            International Standard Item Identifier, with which it will
            be possible to identify particular items, such as the copy
            of Diophantus Arithmetica containing some interesting
            comments by Pierre de Fermat.
            

        

        
The underlying data model which binds all these
            bibliographic and other entities together is FRBR (http://en.wikipedia.org/wiki/Functional_Requirements_for_Bibliographic_Records).

            While it is important that we can identify things uniquely
            and persistently, the real aim is more ambitious: to create
            linked data. Libraries will  via collective effort, and in
            cooperation with museums and archives - interconnect related
            works such as the original Hamlet and Laurence Oliviers
            1948 movie (or to be more precise, metadata records
            describing these works in our catalogues), works and their
            expressions, works / expressions and their manifestations,
            and manifestations and their items.

        

        
This kind of functionality is not widely
            available in library systems yet, but there are some systems
            which provide already a glimpse of what the future will look
            like. OCLCs WorldCat is my favourite; see for instance the
            search results for Gone with the wind:
            

        

        
http://www.worldcat.org/search?q=gone+with+the+wind%2C+by+margaret+mitchell&qt=owc_search

        

        
In order to provide a solid basis for
            decentralized creation of linked data we need persistent
            identifiers from works to items (and metadata formats which
            enable us to specify the different roles these identifiers
            will have; in a work metadata record manifestation
            identifier acts as a link and vice versa). URN qualifiers
            will not be needed for identification, but it is necessary
            to use q-component for e.g. enabling the users to request
            metadata for a work with the q-component. They will then be
            able to see that there are related works and expressions
            (and take a closer look at them). F-component will not be
            relevant for us, but users will be able to cite documents
            with them and manifestation identifiers. I cant see any
            need for the p-component for the time being.
            

        

        
Rich data models such as FRBR are a must in
            digital archives, since eventually they will contain several
            manifestations of most archived digital resources, if
            migration is the preferred preservation method. A user may
            initially find an outdated version of a document; in such
            situation it is important to find out that there are more
            modern versions available (and also that these versions will
            not have exactly the same look and feel than the original).
            

        

        
The scope of the URN system as a whole cannot
            be defined meaningfully since each new namespace (and
            changes in identifier systems which already have a
            namespace) alters the situation. At the moment URN does not
            specifically target e.g. public identities, but if a
            namespace is registered for International Standard Name
            Identifier, the problem is solved. As far as I am concerned,
            URNs can be used to identify resources (whatever they are),
            just like DOI is already being used to identify all sorts of
            objects (in DOI, it is the identifier itself which is
            digital, the identified object does not need to be). 

        

        
Juha 

        

        

        

          

            

              
From: urn [mailto:urn-bounces@ietf.org]
                  On Behalf Of Keith Moore

                  Sent: 16. huhtikuuta 2015 16:30

                  To: urn@ietf.org

                  Subject: Re: [urn] Re-examining p-components
                  (and "/", hierarchy, and relative references)

            

          

          

          

            
On 04/15/2015 10:19 PM, Peter
              Saint-Andre - &yet wrote:

          

          

            

              
I would prefer it if we can agree on
                some limitations on namespaces that
                

                use '/' in NSSs that will render path-relative
                references either useful 

                or "mostly harmless" (depending on the particular
                discipline chose by 

                that namespace). As I stated above, I think we're
                going to want to be 

                able to use URNs to refer to resources that contain
                path-relative 

                references without breaking those references. We
                should certainly be 

                able to use URNs to name HTML documents, for instance. 

            

            


              Keith, would you mind clarifying that last sentence? 

              

              Here's why I ask. To my mind, we should certainly be able
              to use URNs to name documents (if by document we mean a
              created work, not any particular copy of that created
              work). Such a work might be an electronic document that
              could be constructed using any of a number of particular
              technologies: SGML, XML, HTML, EPUB, MS Word, PDF,
              markdown, TeX, LaTeX, you name it. Although I agree that
              we should certainly be able to use URNs to name electronic
              documents, I don't see why HTML is special here (I'm not
              saying you think it's special, BTW). Would you also agree
              that we should certainly be able to use URNs to name PDF
              documents or MS Word documents or EPUB documents?
              

          

          


              I absolutely agree that we should be able to use URNs to
              name any of the above kinds of resources.
            The reason I cited HTML as an example above is
            because (a) it's presumably familiar to most list readers,
            and (b) HTML is a kind of resource that potentially uses
            path-relative references.

            

            For example, if there are one or more URNs that refer to a
            document that contains a link to "../../foo", the behavior
            of that link when the document is accessed via any of those
            URNs should be reasonable, well-defined, and
            namespace-independent. Ideally, the defined behavior of
            that link should be consistent with the behavior when the
            same document is referred to by a URL that contains a path.
            

            

            (Though I realize that such links can behave inconsistently
            even with multiple URLs point to such a document So I
            suppose the most that can be asked is that it be possible
            for path-relative links in documents to
            be able to work as well when referred to by URNs as
            they can work when referred to by URLs.)

            

            Keith

        

      

    

    

  


--------------080301050808050600080402--


From nobody Fri Apr 17 06:55:58 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963271B2CF8 for ; Fri, 17 Apr 2015 06:55:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.651
X-Spam-Level: 
X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAMVgv-pgjxf for ; Fri, 17 Apr 2015 06:55:52 -0700 (PDT)
Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id B15CE1A8AAD for ; Fri, 17 Apr 2015 06:55:51 -0700 (PDT)
Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 6135A8ACD7; Fri, 17 Apr 2015 15:55:50 +0200 (CEST)
X-AuditID: 0a453fe7-f79106d0000047dd-82-553110e61c15
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 7C.64.18397.6E011355; Fri, 17 Apr 2015 15:55:50 +0200 (CEST)
Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Fri, 17 Apr 2015 15:55:49 +0200
From: "Svensson, Lars" 
To: Keith Moore , Peter Saint-Andre - &yet , "urn@ietf.org" 
Thread-Topic: [urn] Why bother with f-components (fragments) and/or p-components ?
Thread-Index: AQHQd+fiZM1It5ed8EC8emonkTktYJ1PGacAgAIW9wA=
Date: Fri, 17 Apr 2015 13:55:49 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EFFAC9BB7A@dnbf-ex1.AD.DDB.DE>
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com> <552F15AD.2050405@andyet.net> <552F6234.4080509@network-heretics.com>
In-Reply-To: <552F6234.4080509@network-heretics.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.69.228]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA12Ta0hTYRjHe3c2d5x77XVu7m3dbFlE4WVQMSrKosgrBalIhHZsp200p5yz WfopuzcqMrNySGpIhZLFippYX9bosmpFH6SgJNMW3aiskK503p3Njn17zu95/v/n//ByaErz Rmmg7U4XyzkZhzFBJVetWfEtM4JMpTn+ADQf+xZOMIdeBilzy+5PslwqL/xsQJnX1fVdlnfs Ttl6aqNqmYV12OtYLnv5ZpWt1dusqN23acfeD22yneBzvgfQNEYL8UBzpgckCmUafjR4McED VLQGBQEee/1ALn5cA3jw/FGZByjpBDQff7SReS1qwJGmFgWxSUUbcO8rs4hL8N2xEUqsl+Ce wx4lqeVoDj5yeUBBaojycfuHRqXo3gPwr+EzgDQShTgvfvqjYoCm40uXHkZrCumxLzKmEHMi 3HVd5Bjp8JvhPzE+C5+4fV8mzufgj+H2mHYBPtv5jhIXp+C7rSPyo0Dnldh6JRKvROKVSDqA vBsk89VWUxZjybJYqrIsrA+Ib/LaD448Xh0AiAZGNWxjc0o1CqaOr68OgHW0zKiDJ9WmUk1y VY2l3sbwtkrO7WB5oxaeggKG47jK7dhmnAEb/YJeP055N19r32KvcfOVbs4RAJimBCl9VRiC Fqa+geVqRMMAmErLjXrY1N9YokFWxsVuY9lalot3y2naiOGuycLOFI61sju22h2ueFvQPSEh kbQTDTQLzugTdhmkjf8zyejEACii1UIwPSI38bVMNW+3xrxT4TKyVR2nUd/pkCeHpsXhRM8Q 2GDQwwNEhsiEze0cz2pIgwUk0mRJg1ga0uGe6uxSzRQJn+j6FuQLT5QKg8kkjvBn/cuogXay LCkGoxGnwf0koi7G/vcqEt5WC91kBPIuxiU9+AKh6jiNHXxOPDgGJ9oZdoLt1hIu+0fTo1O4 ou/rpozPxb5g7sCNJdRYcV/hJMfw7UXfhwq7D/oOOUebnYmH71yZtFS9tfxAxr3QocjmLzd7 Gl3M4ivh96F3/U87uoca5j4/ea/zKnereJV2be/pit/nvP7RguLcmb2Xj2elU2URbdlzXcvs UexKmvdppft6r/KBUc7bGNN8iuOZvy2oHYl8BAAA
Archived-At: 
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Apr 2015 13:55:56 -0000

On Thursday, April 16, 2015 9:18 AM, Keith Moore wrote:

> Those who have been following the apps-discuss list and the Apps
> Area WG has seen a long, difficult, and sometimes unpleasant
> thread about what a URN specification (or any other
> specification for a particular URI scheme) is allowed to say
> about fragments.=A0 The discussion appears to extend to whether
> fragments can be disallowed at all by a scheme (if they cannot,
> 2141 has problems quite independent of what we might do), to
> whether a scheme can constrain fragment syntax in any way, and
> to whether scheme-specific or namespace-specific restrictions or
> semantic [1] rules are allowed.
>=20
> Similar issues arise with p-components.=A0=A0 If a p-component
> (i.e., introduced by a "/", at least before a q-component or
> f-component) appears in a URN, it is claimed to be impossible
> [2] to avoid relative resolution, something that might cause
> havoc or other damage with URNs.
>=20
> An obvious question is why we don't just disallow one or both
> and move on.
>=20
> For me, the answer is tied up with the question I've been asking
> about the difference between instructions or qualifiers that are
> part of the URN (see below) and instructions or qualifiers that
> are intended to be passed to whatever the URN points to or
> resolves to.=A0=A0 If no one else sees that as an issue, or believes
> that we can reasonable handle it on a per-namespace basis (that
> fragment discussion definitely would complicate handling those
> on a per-namespace basis), please explain why and I'd drop this.

I see it as an issue and i vaguely remember that I suggested that we only s=
hould discuss queries (or q-components...) in the context of urn resolution=
 services. So yes, we're on the same page here.



> 1. Qualifiers that potentially represent portions of resources, and/or
> relationships with other resources named with URNs, that should be
> included in comparisons and considered relevant for persistence.
>=20
> I would especially like to see examples of #1, because I am not sure that=
 they
> exist.
>=20
> When I first wrote up that list, I wasn't sure about #1 myself.=A0=A0 I a=
lmost stated
> that #1 wasn't very useful, then I realized that that type of qualifier p=
robably is
> needed after all, or at least that it wasn't safe to say that they're not=
 needed.
>=20
> One reason for having such a qualifier is this: you'd really like to be a=
ble to
> have persistent references to portions of a resource.=A0=A0=A0 Fragments,=
 as currently
> defined and implemented, don't serve that purpose.=A0=A0 (I could explain=
 why but it
> would be a long side discussion, so will leave it to a separate message i=
f the
> explanation is needed).=A0=A0 So urn:example:/a might refer to the entire=
ty of a
> resource and urn:example:/a/b might refer to a portion of that resource, =
and
> urn:example:/a/b/c refer to a (presumably) still smaller portion - and al=
l of
> these URNs would be managed by the namespace and expected to remain
> persistent over time (including their relationships to one another, if an=
y of
> them used relative references).

This is what many in the science community wish for since it would allow th=
em to cite parts of resources persistently (e. g. parts of a zip archive).

However, I do see that this is not very likely to work with URNs.
=20
> 2. Qualifiers that identify portions of resources that should not be
> included in comparisons or when considering persistence.
>=20
> I think this ends up being the fragments to which we're already
> accustomed.=A0=A0 IMO, the ability to specify a fragment of a URN-named r=
esource
> is still useful, it's just that the combination of a URN and a fragment n=
ame (or if
> you prefer, f-component) no longer has any assurance of persistence.=A0=
=A0 So
> urn:example:a has an assurance of persistence but urn:example:a#b does
> not.=A0=A0 I think this will confuse people for a while, because they'll =
have to learn to
> mentally parse URNs differently than URLs.=A0=A0 But overall this might b=
e the best
> path forward.=A0=A0 It would be difficult for us to exclude use of fragme=
nts with
> URNs, or to define fragment behave differently with URNs than with URLs,
> without breaking relative references.
>=20
> So I am thinking that the meaning of the fragment should still be the sam=
e for
> both URNs and URLs.=A0=A0 Ideally if urn:example:a resolves to
> http://example.com/b, and c is a valid fragment of that resource, then
> urn:example:a#c and http://example.com/b#c should refer to the same porti=
on
> of that resource's content.=A0=A0 The alternative of letting fragments wo=
rk
> differently for URNs vs. URLs strikes me as very unlikely to work well, e=
specially
> if 3986-style relative reference processing can be applied to URNs.

+1. There is already now a risk that a fragment identifiers points to a pla=
ce in the resource that doesn't exist anymore or that will not exist in fut=
ure. As long as the f-components are not required to be persistent, that is=
 not a problem.
=20
> 3. Qualifiers that are transmitted to resources (when applicable) for
> interpretation by the resources.=A0=A0 These should not be included in
> comparisons or when considering persistence.
>=20
> This is analogous to query strings in HTTP.=A0=A0 IMO it's vital to let U=
RNs be able to
> bundle the name of the base resource with some input to be transmitted to=
 the
> resource.=A0=A0 So similar to fragments, I think that if urn:example:a re=
solves to
> http://example.com/b, then urn:example:a?c should ultimately result in a =
GET
> of http://example.com/b?c .=A0=A0 Again, urn:example:a is persistent whil=
e
> urn:example:a?c has no assurance of persistence.

+1
=20
> 4. Qualifiers that affect resolution of the URN, and which should be
> transmitted to the resolution service if one is used, either to request
> a specific kind of resolution service, or to narrow down between
> multiple versions and/or representations of the content.
>=20
> For the sake of an example of how this might be used, let's say that such=
 a
> qualifier must begin with "??", that it appears before q-component, and t=
he
> value of that qualifier is not allowed to contain "?" without it being %-
> encoded.=A0 I'll tentatively call this an "r-component" ("r" for resoluti=
on)
> =95 urn:example:a would refer to the resource without specifying what to =
do with
> the URN.=A0 If such a URN appeared in a link in a resource being viewed i=
n a
> browser, and a user clicked on that link, the browser might try to presen=
t the
> content to the user.=A0=A0 Or failing that, it might simply try to get a =
description of
> the resource and display that.=A0=A0 If OTOH, such a URN appeared in an I=
MG tag
> the browser might give up if it couldn't get the content - presumably the
> description of the resource isn't an image.
> =95 urn:example:a??request=3Dcontent would tell the resolution service (a=
nd
> perhaps also the client) that the reference was specifically intended to =
be for
> the resource's content, and not to locations, or any kind of description =
or
> metadata of the resource
> =95 urn:example:a??request=3Dmetadata;format=3Ddc-rdf might request that =
the
> resolution service return a description of the resource in RDF format and=
 the
> Dublin Core schema.
> =95 urn:example:a??request=3Dlocations could request locations of the res=
ource
> =95 urn:example:a??request=3Dcontent;version=3Dfirst could request the ea=
rliest
> version of the resource
> Basically these qualifiers would serve as a kind of query to the resoluti=
on
> service (as opposed to a query to be sent to the resource).=A0 It's like =
searching
> for a resource in a library's catalog and specifying some details that na=
rrow the
> results along with the query.
> As far as I can tell, this kind of capability is vitally important, becau=
se almost
> every time I see any functionality of a resolution service described, the=
re's at
> least one or two examples of how one might include such queries with a
> URN.=A0=A0 IMO, if URNs don't provide a standard way to do it, URN resolu=
tion
> services will overload "?" and the result will be that (a) you can't spec=
ify a URN
> that includes a query to be sent to the resource itself (at least not in =
any
> uniform way) and (b) different schemes will behave differently and it wil=
l be
> difficult to write clients that treat Uniform Resource Names in any kind =
of
> uniform fashion.
> Of course the above are just examples of what could be done, rather than =
a
> well thought-out proposal.=A0=A0 I would also suggest that namespaces sho=
uld be
> able to define their own requests and parameters independently of others.=
=A0=A0 So
> for the "ietf" namespace, IETF should be able to support things like
> urn:ietf:rfc:XXXX??request=3Dietf.version-history;option=3Dinclude-I-Ds

This is nice. I was always concerned that the proposed use of q-components =
in 2141bis would conflate queries to the identified resources and queries s=
ent to the resolution service, but this seems to solve it.
>=20
> I continue to struggle with two things (or perhaps misconceptions in my o=
wn
> mind) about our discussions:
>=20
> (a) Not all URNs need to be or can be resolved, and it seems to me that e=
ven
> URNs that can be resolved are primarily used to identify resources and no=
t to
> resolve resources (which is why we have URLs, after all).

Yes, I agree with others that the primary goal is identification. My take i=
s that resolvers are mainly there to help the user find a place where to ge=
t the resource, not to provide the resource itself.

> (b) We don't know enough about the running code of modern, actual URN
> resolution services to helpfully specify what kind of syntax they might r=
equire.

The code of the resolver we use at the DNB is available on SourceForge [1],=
 if that is of any help.

[1] http://sourceforge.net/projects/metaresolver/?source=3Ddirectory

> Regarding (a), we have (i) a large number of URN namespaces that are used=
 by
> other SDOs or quasi-SDOs to assign identifiers for uses like XML namespac=
es. I
> strongly encourage the WG participants to spend some time looking through
> the list of formal namespaces:
>=20
> http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
>=20
> As far as I can see, most of the URNs that are assigned in those namespac=
es
> aren't intended to be resolved at all. They are, in the perhaps less than=
 perfect
> terminology of 2141bis, "abstract designators". In these cases, there is =
simply
> no need to worry about qualifiers 3 & 4.
>=20
> There's been a lot of misunderstanding and misuse of URNs.=A0=A0 URNs wer=
e
> intended to name resources, not to merely be unique strings.=A0=A0 I don'=
t mind if
> people sometimes use URNs as merely unique strings, as I don't think it d=
oes
> much harm - except that some people have gotten the idea that this is the
> primary purpose of URNs.=A0 It's not.=A0 I don't even recall that particu=
lar use case
> even being mentioned through years of discussions about URNs in the mid-
> 1990s.=A0=A0 To the extent URNs are usable in this way, it's a corner-cas=
e, an
> unintended consequence, not the general or typical case.

Hmm, so you say that while it's OK to have a name for a resource that isn't=
 there, this is not how it was supposed to be? Like it's OK to produce URLs=
 like http://example.bla/foo that don't resolve to anything.

Best,

Lars


From nobody Fri Apr 17 07:12:11 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9FE1ACE3B for ; Fri, 17 Apr 2015 07:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hBqoGL1TILO for ; Fri, 17 Apr 2015 07:12:09 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52481B29AC for ; Fri, 17 Apr 2015 07:12:08 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 61EE420A91 for ; Fri, 17 Apr 2015 10:12:08 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 17 Apr 2015 10:12:08 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=yE9xgfKQCluX1+v P0fPiXleBnps=; b=h4LuJ6xoWrPfSC/fg4hGjQUpMVsZH7KoDa3rz6ASi9Qwa8F gUpVTV6717X+oglt0GB7p1qi6gfXGakK5KENYtq0rJgGtW3siofdsdP1NOZvGk1c KdhGrbox4iFzR1fSQWfiZHn1HPQWvQxPH+FNoFpIdNZpMhuNKnrAQSBeIH2g=
X-Sasl-enc: rzJtVoWSv361d9DtGIYA3SiaX4gpynmuvxy3/RUhSnag 1429279928
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 0D2CDC00011; Fri, 17 Apr 2015 10:12:07 -0400 (EDT)
Message-ID: <553114A0.3010506@network-heretics.com>
Date: Fri, 17 Apr 2015 10:11:44 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com> <552F15AD.2050405@andyet.net> <552F6234.4080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFFAC9BB7A@dnbf-ex1.AD.DDB.DE>
In-Reply-To: <24637769D123E644A105A0AF0E1F92EFFAC9BB7A@dnbf-ex1.AD.DDB.DE>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Apr 2015 14:12:10 -0000

On 04/17/2015 09:55 AM, Svensson, Lars wrote:
>> There's been a lot of misunderstanding and misuse of URNs.   URNs were
>> >intended to name resources, not to merely be unique strings.   I don't mind if
>> >people sometimes use URNs as merely unique strings, as I don't think it does
>> >much harm - except that some people have gotten the idea that this is the
>> >primary purpose of URNs.  It's not.  I don't even recall that particular use case
>> >even being mentioned through years of discussions about URNs in the mid-
>> >1990s.   To the extent URNs are usable in this way, it's a corner-case, an
>> >unintended consequence, not the general or typical case.
> Hmm, so you say that while it's OK to have a name for a resource that isn't there, this is not how it was supposed to be?

I think Peter was referring to URNs that don't even name resources, but 
just exist to be unique identifiers that are distinguishable from other 
unique identifiers.   And my opinion is that it's OK to have them but 
that's not the purpose for which URNs were created, and that use case 
shouldn't be used as an argument against making URNs more generally useful.

Keith



From nobody Fri Apr 17 07:14:23 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DB11B2D3C for ; Fri, 17 Apr 2015 07:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuIdgJ5SpCTl for ; Fri, 17 Apr 2015 07:14:20 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0986A1B2BEE for ; Fri, 17 Apr 2015 07:14:20 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Yj722-0000Om-7B; Fri, 17 Apr 2015 10:14:10 -0400
Date: Fri, 17 Apr 2015 09:00:42 -0400
From: John C Klensin 
To: "Hakala, Juha E" 
Message-ID: <16723D36B4A99A8D6A09F9E0@7AD4D3FB4841A5E367CCF211>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Cc: urn@ietf.org, Keith Moore 
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Apr 2015 14:14:21 -0000

--On Friday, April 17, 2015 06:10 +0000 "Hakala, Juha E"
 wrote:

>...
> Library community has well established practices for how to
> use identifiers. URNBIS could use these practices as the
> starting point, extend them if needed and alter them only when
> there is a good reason to do so. As a result URNBIS should
> have a more unified understanding of what kind of
> functionality needs to be supported now, and what can be
> postponed for the time being.
>...

Juha,

While I found your note very helpful, I need to identify a
difficulty with the above suggestion.  While I think we may be
able to defer working out the details of semantics for
additional cases, I believe we will get only one shot at syntax
that is reserved in 2141.  In particular, if either reserved
query keywords or Keith's idea about special syntax (such as
"??") embedded in q-components are needed, or if p-components or
f-components [1]need to be handled in some special way by a
parser that is specifically aware of the URN scheme but not
particular namespaces, I don't see any way to postpone decisions
about that syntax.

There is also at least a potential issue with other communities
and their needs and practices.

So I think we need to be a little bit careful about what we can
postpone or assume that we can postpone.

best,
   john

[1] I take no position in this note about whether the WG or
2141bis can take any position at all about f-components.





From nobody Fri Apr 17 08:42:56 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB0F1B2E74 for ; Fri, 17 Apr 2015 08:42:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNar3lA_G0fx for ; Fri, 17 Apr 2015 08:42:52 -0700 (PDT)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3BA1B2E79 for ; Fri, 17 Apr 2015 08:42:40 -0700 (PDT)
Received: by paboj16 with SMTP id oj16so129040532pab.0 for ; Fri, 17 Apr 2015 08:42:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=BDEkLG7buvOX4kfj69PsieUgowAzr05VdtAPKBkl4SI=; b=MKbF+a0bZHuH2QwbIRxW/hfENtvmEm5xBT4wzoMIJgThdl8kBXQwbtWtWZzU5F2EfN RHcATuzojFgsmVn+UQRbSMyL+rpmwh30Jm0CcOg+2XiabEEDiRdnB1CnMY+vZjlsTt/t hedsARXf0aOY9tVxljXKbZsHkVxyaByJPSIKic31lq9nmV1s++kFIMXJH9w9/ipkdBvZ D/JX1AFlfLVFN/A1XvxR3RTI+I5xOFiIU6HWcgJzF6SA3zbmOwTbfhw6VGTia3I84Z+/ UoEPSlRjm1ScMFy5I5uFqGU9uIz8wh7B5hL7BKNVaqi5RKHtKgeZuIgpOSiOZPmk+BKF rQhA==
X-Received: by 10.66.120.69 with SMTP id la5mr6710684pab.66.1429285360255; Fri, 17 Apr 2015 08:42:40 -0700 (PDT)
Received: from spandex.local (216-67-122-202.dynamic.cdma.acsalaska.net. [216.67.122.202]) by mx.google.com with ESMTPSA id bs4sm10510336pbc.3.2015.04.17.08.42.37 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Apr 2015 08:42:38 -0700 (PDT)
Message-ID: <553129EC.1090507@gmail.com>
Date: Fri, 17 Apr 2015 07:42:36 -0800
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "urn@ietf.org" 
References: <552EA31D.1090402@gmail.com>
In-Reply-To: <552EA31D.1090402@gmail.com>
X-Forwarded-Message-Id: <552EA31D.1090402@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [urn] Fwd: Updated virtual interim details
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Apr 2015 15:42:53 -0000

Reminder about the virtual interim, starting in about 15
minutes.

Melinda


-------- Forwarded Message --------
Subject: Updated virtual interim details
Date: Wed, 15 Apr 2015 09:42:53 -0800
From: Melinda Shore 
To: urn@ietf.org , Barry Leiba 
CC: Andrew Newton 

This is an update to information on Friday's virtual
interim.  We will be using Webex rather than the
conference bridge previously announced, and will have
global call-in numbers (see URL provided below), as
well as the ability to record the session.

Agenda:

2141 status update
Open issues walkthrough

The goal is to come to closure on some of the issues that have
been difficult to resolve on the mailing list and set a baseline
for consensus calls on the mailing list.

Talk with you then!


urnbis Virtual Interim
Friday, April 17 2015
16:00 - 18:00 UTC (9am-11am PDT, 12pm-2pm EDT, 18:00-20:00 CET)


Join WebEx meeting:
https://ietf.webex.com/ietf/j.php?MTID=ma161311ff6c7053901744d309821301f
Meeting number: 645 547 018
Meeting password: 1234

Join by phone
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 645 547 018

Global call-in numbers:
https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=302217342&tollFree=1

IMPORTANT NOTICE: Please note that this WebEx service allows audio and
other information sent during the session to be recorded, which may be
discoverable in a legal matter. By joining this session, you
automatically consent to such recordings. If you do not consent to
being recorded, discuss your concerns with the host or do not join the
session.



From nobody Fri Apr 17 09:01:29 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8CFF1A007F for ; Fri, 17 Apr 2015 09:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1-FrkzFETod for ; Fri, 17 Apr 2015 09:01:25 -0700 (PDT)
Received: from zoidberg.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE051A00D4 for ; Fri, 17 Apr 2015 09:01:17 -0700 (PDT)
Received: from aran.int.lexiconix.com (pool-108-44-246-138.clppva.fios.verizon.net [108.44.246.138]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by zoidberg.ecotroph.net (Postfix) with ESMTP id 80416A0747; Fri, 17 Apr 2015 12:01:15 -0400 (EDT)
Message-ID: <55312E47.6050309@thinkingcat.com>
Date: Fri, 17 Apr 2015 12:01:11 -0400
From: "Leslie Daigle (ThinkingCat)" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: John C Klensin , "Svensson, Lars" ,  Peter Saint-Andre - &yet , urn@ietf.org
References: <24637769D123E644A105A0AF0E1F92EFFAC84913@dnbf-ex1.AD.DDB.DE> <55079325.1010300@andyet.net> <24637769D123E644A105A0AF0E1F92EFFAC85A6E@dnbf-ex1.AD.DDB.DE> <5509ABC6.2040707@andyet.net> <24637769D123E644A105A0AF0E1F92EFFAC923DC@dnbf-ex1.AD.DDB.DE> <5514CE1E.4010201@andyet.net> <24637769D123E644A105A0AF0E1F92EFFAC95C26@dnbf-ex1.AD.DDB.DE> <4442EEA947F0A2535EE886EE@JcK-HP8200.jck.com>
In-Reply-To: <4442EEA947F0A2535EE886EE@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Apr 2015 16:01:27 -0000

Coming back to this -- I do think that resolves a major issue in the 
document.  Re-reading the March 31 document this morning, it struck me 
that it doesn't define what an NSS is.

There is verbiage about what an NSS is not. [1]  In the example 
discussed, the NSS is "".

In RFC2141, the NSS *is* the identifier.  It must be unique and
persistent in its identification of a resource.   Which is a bit
ridiculous for "".  If the document was updated as proposed here, I 
would think it would be appropriate to have guidance about 
"assigned-name" being the identifier alluded to in:


 > A URN namespace is a collection of identifiers that obey three
 > constraints.  Such a namespace is (1) unique, (2) assigned in a
 > consistent way, and (3) assigned according to a common definition.

Largely, my personal opinion is that it's a mess to allow both NSS-only 
and NSS+p-component namespaces, but more on that in the next note.

Leslie.
[1] In fact, the document as a whole seems to be written as a set of 
contrasts from the documents it obsoletes; is it kosher to have 
normative dependencies on the documents you're obsoleting?

On 3/30/15 3:22 PM, John C Klensin wrote:
>
>
> --On Monday, March 30, 2015 16:43 +0000 "Svensson, Lars"
>  wrote:
>
>>> However, perhaps the term "assigned-urn" is confusing so I
>>> will see if I can find a better term.
>>
>> Yes I see. Even if I realise that it syntactically makes no
>> difference, it seems more natural to me to say that urn
>> equivalence is determined by comparing the assigned-name part
>> of the urn. If it's not part of the name, it should not be
>> relevant for equality. Thus my proposal would be
>>
>> namestring = assigned-name [q-component] [f-component]
>> assigned-name = "urn:" NID ":" NSS [p-component]
>
> This works for me.  Since Peter has passed the pen back to me
> after doing most of the work on -11, I'll slip it into the draft
> until someone objects very soon.
>
>      john
>
>
>
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
ldaigle@thinkingcat.com
-------------------------------------------------------------------


From nobody Fri Apr 17 09:01:37 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC0C1A00E8 for ; Fri, 17 Apr 2015 09:01:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level: 
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRy_IcouY5Ww for ; Fri, 17 Apr 2015 09:01:27 -0700 (PDT)
Received: from zoidberg.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A09A61A007C for ; Fri, 17 Apr 2015 09:01:27 -0700 (PDT)
Received: from aran.int.lexiconix.com (pool-108-44-246-138.clppva.fios.verizon.net [108.44.246.138]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by zoidberg.ecotroph.net (Postfix) with ESMTP id 72979A1899; Fri, 17 Apr 2015 12:01:26 -0400 (EDT)
Message-ID: <55312E53.2010605@thinkingcat.com>
Date: Fri, 17 Apr 2015 12:01:23 -0400
From: "Leslie Daigle (ThinkingCat)" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: John C Klensin , urn@ietf.org
References: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com>
In-Reply-To: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Apr 2015 16:01:31 -0000

I think this is a rational, if hypothetical, reason for p-components, 
and my requirement would be for the document to be clear about the use:

> For those namespaces that need additional qualification (beyond
> the traditional NSS) that still participates in equality
> checking, that has so far left p-components as the only logical
> option.  Perhaps there is some other syntax that would do the
> job --a hypothetical X-component -- but, so far, no one has
> proposed one and the logic of 3986 is such that I think we can
> expect any such syntax proposal to produce cries of pain about
> generic URI parsers and related topics.


IMO, that can be achieved by being clear about what the NSS is, assert 
that relative URNs are not expected/permitted, and attest that "/" 
should not be used in a URN simply because one is importing a namespace 
that happens to use them and it's a matter of syntactic convenience not 
to escape them with %-encoding.

Leslie.

On 4/3/15 3:49 PM, John C Klensin wrote:
> ABSTRACT /SUMMARY for this rather long note:
>
> p-components seem to a focus of controversy, possibly blocking
> other work and general progress in the WG.  This note tries to
> summarize and analyze the controversy, asks if p-components are
> important enough that we need to resolve that controversy, and
> proposes an alternative if they are not.
>
> Other other circumstances, I might just have written this note
> and proposal as an I-D, but it is really just an exploration,
> not a proposal.
>
> 
>
>
> Hi.
>
> Several comments in the last couple of weeks have raised issues
> with what are called p-components in 2141bis.  Most, but not
> all, of those notes have focused particularly on interactions
> with hierarchy and relative resolution.
>
> In the interest of getting done, I want to see if the WG can
> reexamine p-components rather than trying to dissect 3986 and
> its implications in this area.  This note will do some
> examination of 3986 interactions, but please bear with me.
>
> Assumption: I am taking the applicability of 3986 syntax but
> not semantics (as discussed in Andy's consensus call and
> draft-ietf-urnbis-semantics-clarif, although that document is
> still open to textual improvements) and the need to expand
> allowable URN syntax beyond those of RFC 2141 (and 3046) as
> given.  If there is anyone following the URN list who sees the
> discussions about hierarchy, relative resolution, or
> applicability of their interpretation of 3986 rules (with or
> without draft-ietf-appsawg-uri-scheme-reg) as a way to kill
> either 2141bis or URNs generally by a death of a thousand cuts,
> this note will probably not be helpful to them.
>
>
> THE ISSUES:
>
> Those who have spoken up about issues involving p-components
> (or the use of "/" in URNs) should check this to be sure I
> haven't mischaracterized their positions (and correct me if I
> have), but I believe the main concerns, as presented by others
> and with which I generally do not agree, are:
>
> (Issue 1): Despite the "no 3986 semantics" rule, we really
> cannot have a path or any use of a "/" in any URI, URNs
> included, without making that URI hierarchical.  From that
> perspective, we can't say "URNs are not hierarchical", which
> 2141bis-11 does say [1], and allow "/".  Other than relative
> resolution issues, it is not clear whether this issue has any
> practical impact or is [just] an argument that the "not
> hierarchical" paragraph is self-contradictory and should be
> rewritten somehow.
>
> (Issue 2): The generic URI parsers [2] will apply relative
> resolution processing if a "/" is seen, or perhaps even if it
> is not.  So such processing is inevitable, cannot be opted out
> of by URNs, and will cause serious damage to URNs if we try.
>
> (Issue 3): Relative resolution is very important to some other
> URIs, current and permanent or planned.  If URNs impose
> restrictions on relative resolution operatons, even
> restrictions that apply only to URNs, it will be damaging to
> those other URIs.
>
> (Issue 4): Because URNs are non-hierarchical and relative
> resolution would cause problems or meaningless results, URNs
> should not allow "/" unless the particular namespace actually
> is hierarchical and relative resolution is appropriate.
>
> (Issue 5): It is not possible to decide that a URI scheme does
> not support relative resolution.  All URIs have to support such
> resolution.
>
> (Issue 6): Because it is not possible for a scheme to disallow
> relative resolution, URNs cannot make support for them a
> per-namespace issue either.
>
>
> PRELIMINARY ANALYSIS:
>
> There are some contradictions in the list above that don't
> make it easier to form a complete picture, much less figure out
> which arguments are valid or not.  Issues 1, 5, 6, and probably
> 4 are really about semantics so, unless it really is impossible
> to separate the actual syntax restrictions in 3986 from its
> semantic ones [3], their relevancy is questionable.
>
> The overall issue appears to be further complicated by an
> apparent (but not explicitly written down anywhere that I've
> found) principle for URIs, which is that meaningless
> constructions are ok.  So, as discussed in earlier notes in the
> context of fragments, if a URI is associated with a resource
> and a fragment is specified that makes no sense for the
> resource, whatever processor is dealing with the URI and/or the
> resource is free to just discard it rather than letting it
> interfere with other operations.  For the particular case of
> "/" and despite the restriction in 2141, nothing prevents
> someone from writing "urn:some-NID:some-NSS/garbage" today and
> using it in some URI context.  It would presumably be
> meaningless and different namespace-specific action routines
> would deal with it in different ways, but AFAICT, no one has
> shown evidence of horrible damage, whether to generic URI
> parsers, the nature of URNs, or otherwise.  Similarly, 3986
> makes it quite clear that false negatives are ok and so on.
>
> At ;east for some people, that principle (and the absence of
> general damage when it is applied) do not appear to apply where
> URNs are involved.  When we tried to propose a note in 2141bis
> that would have said, effectively,
>
>     "Relative resolution as described in RFC 3986 is likely to
>     be meaningless for URNs.  Parsers and processors that are
>     aware they are dealing with URIs with the
>     'urn:' scheme SHOULD NOT attempt to process relative
>     references.  However, if that processing is performed,
>     perhaps by a generic system that is not aware of particular
>     schemes, and results in meaningless results, the relevant
>     system should be prepared to just move on."
>
> For the particular case of the "urn:" scheme, we get
> repetitions of one or more of the issues about.
>
> I don't know what to do with the other issues, especially
> because of the difficulties with claims about generic URI
> parsers (see note [2] below).  So let's come back to the
> issue.
>
>
> WHY WOULD WE WANT A p-COMPONENT?
>
> URNs are very much tied up with the principle of "persistence"
> (or even "permanence".  Many of us believe we know,
> intuititively, what persistence of an identifier means, but we
> have been unsuccessful in proposing, much less agreeing on, a
> definition that is sufficiently precise to discriminate among
> boundary or edge cases [4].  For URNs (perhaps more so than
> URIs generally) careful and accurate matching and being clear
> about what compnents of the string are considered stable/
> persistent has seemed to be especially important.  Neither
> f-components (which those who want to think of them as 3986
> fragments believe are inherently bound to target objects and
> not the URI) and q-components (which, as Keith and others,
> including myself, have pointed out, raise questions of
> relationship between instructions to the URN processor and
> instructions to/about targets) are problematic from both
> persistence and comparison purposes.  2141bis has explicitly
> excluded both from equality comparisons for just those reasons.
>
> For those namespaces that need additional qualification (beyond
> the traditional NSS) that still participates in equality
> checking, that has so far left p-components as the only logical
> option.  Perhaps there is some other syntax that would do the
> job --a hypothetical X-component -- but, so far, no one has
> proposed one and the logic of 3986 is such that I think we can
> expect any such syntax proposal to produce cries of pain about
> generic URI parsers and related topics.
>
> If we have p-components anyway, there are also advantages to
> actual or potential namespaces that use the "/" character in
> their identifying strings.  Of course, we could simply declare
> the separation of NSS from p-components to be an artifact of
> 3986 semantics and solve the identifying string problem by
> allowing the "/" in the NSS, but doing so would not help with
> either the "generic URI parser" or relative resolution issue,
> nor would it help those who look at a "/" in something that
> appears to be a URI and see "hierarchy" (probably in large
> letters).
>
>
> A ROTTEN, BUT POSSIBLY DESIRABLE, CHOICE
>
> The theoretical argument for p-components is above.  I think we
> also need to remember that opening 2141 (and at least
> implicitly 3406) to allow additinoal syntax has been incredibly
> painful and that, after 2141bis is complete and approved,
> opening or revising it to allow yet more syntax is likely to be
> even more painful.  That may be a good argument for adding
> p-components now, even if doing so creates some pain, just to
> have it over with.
>
> However, the above theorizing aside, I have not seen any real
> demand for p-components on the mailing list.  If there is such
> demand, I hope that those who have current needs will come
> forward and explain them.  But, if there is not and
> p-components are likely to be a source of blocking
> controversies, another option would be to modify 2141bis to
> reserve the syntax but prohibit registration (and, to the
> extent we have the power, use) of URNs containing them until
> and unless future documents appear that address the issues.
>
> Because I'm very concerned about the "death of a thousand cuts"
> mentioned above, I would hope that the WG would insist that
> anyone arguing for getting p-components out of the current
> disucssion by pushing them into the future would assure us that
> they would not turn around and raise other supposedly-blocking
> issues, but I recognize that there is ultimately no way to
> prevent that behavior other than by assurance of good faith.
>
> Were we to decide to push p-components aside, the WG should
> decide whether it would be desirable to have an informational
> appendix or separate informational document that records what
> we believe the issues are and why we reached the decisions we
> did as a starting point for future work.  This note might be a
> good starting point.  Had we had a supplmental document for
> 2141 that identified the issues and reasons additional syntax
> was deferred, it might have saved us a year or three in the
> current efforts (and/or had a restrictive impact on 3986).
> But, if we translated the controversies about the implications
> of p-components into difficulty getting consensus about such an
> explanation, perhaps it would just be better to bequeath the
> issues to the future.
>
> best,
>      john
>
>
>               -------------------------
>
> NOTES
>
> [1] draft-ietf-urnbis-rfc2141bis-urn-11, Section 5,
>    paragraph 2.
>
> (2] "Generic URI parsers" are problematic in another way that
>    should be kept in mind.  They have been invoked frequently in
>    these (URN) and other discussions about URIs, but it seems to
>    me that, each time someone tries to pin down exactly what
>    they do and how libraries compare, the answers are wildly
>    different, with some systems that are considered to be such
>    parsers by their authors or advocates doing little other than
>    separate the scheme name from the rest of the URI, others
>    trying very hard to interpret and implement every aspect of
>    3986 including its deep semantics (because 3986 includes many
>    options, two different good-faith implementations of that
>    variety may not behave the same way), and still others
>    essentially assuming that every URI behaves like an HTTP URL
>    and that everything else is either invalid or deviant.  Some
>    tests on web browsers appear to be consistent with the latter
>    point of view and are being documented as normative by
>    WHATWG.  To the extent to which the later is the actual
>    working definition of "generic URI parser", they are never
>    going to work well with URNs.
>
> {3} I have heard a few people suggest that it actually is
>    impossible, but I haven't seen such comments on the list or
>    otherwise in public.  If it is not possible, it seems to me
>    that two or three years of list discussion suggests that we
>    are faced with a choice between abandoning all ideas of
>    extending URNs beyond 2141 and going back to the "URNs are
>    not URIs" model.
>
> [4] There have also been some claims that the concept is
>    meaningless or impossible in practice, but I'll leave that
>    discussion for other notes.
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
ldaigle@thinkingcat.com
-------------------------------------------------------------------


From nobody Fri Apr 17 09:06:32 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4171A0174 for ; Fri, 17 Apr 2015 09:06:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1tLSoXRw3F9 for ; Fri, 17 Apr 2015 09:06:29 -0700 (PDT)
Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FC91A00AE for ; Fri, 17 Apr 2015 09:06:28 -0700 (PDT)
Received: by iecrt8 with SMTP id rt8so63244484iec.0 for ; Fri, 17 Apr 2015 09:06:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OjxfIXGkrMiR1S13P6HW5qMcX8+eSzm+/yr0o3ij6wg=; b=iMcVegEHHIkSOXFZw9Z6d5+RqH0nrag5Opm68OOgpowfL6sxCzI8bcvfM4RlihwmGN i2Tokn92hQwL+POVv2TDTcCkIKewnWxEMVLdKQDy8t3CbXu9lRo2RNEAt5/SWLGQd0BR 8hJ+SWO+oG2MYbAmtAXTmW9AlmFLqGcxX2XLXbAUwZW5fDpDci3R+tbRe8wfS8qfgXdR jRxEVC8BBKs+v0Ow5b3ZYF5lTUpEa6T7js/z2V7aF6Czrmihbv0HFUQQDo6HDXTSvnuz GElpccGHusfkgdf56/UfjhpNNr+2HAfuZl2vL91U0LxB9NeqHYh9vUWLClfdnLlap73k xwXQ==
X-Gm-Message-State: ALoCoQmwU/2jmiZeUzoyQ8scyXZF2XtZx5e1D2IS2z+eLAptiliMEt0eTSIHbu0Tbl/vpOHDX6+C
X-Received: by 10.50.25.225 with SMTP id f1mr3813301igg.29.1429286788305; Fri, 17 Apr 2015 09:06:28 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id qr1sm1421133igb.18.2015.04.17.09.06.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Apr 2015 09:06:27 -0700 (PDT)
Message-ID: <55312F81.70609@andyet.net>
Date: Fri, 17 Apr 2015 10:06:25 -0600
From: Peter Saint-Andre - &yet 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Melinda Shore ,  "urn@ietf.org" 
References: <552EA31D.1090402@gmail.com> <553129EC.1090507@gmail.com>
In-Reply-To: <553129EC.1090507@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Fwd: Updated virtual interim details
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Apr 2015 16:06:30 -0000

Where is the etherpad?

I went here but I see no activity:

https://tools.ietf.org/wg/urnbis/minutes



On 4/17/15 9:42 AM, Melinda Shore wrote:
> Reminder about the virtual interim, starting in about 15
> minutes.
>
> Melinda
>
>
> -------- Forwarded Message --------
> Subject: Updated virtual interim details
> Date: Wed, 15 Apr 2015 09:42:53 -0800
> From: Melinda Shore 
> To: urn@ietf.org , Barry Leiba 
> CC: Andrew Newton 
>
> This is an update to information on Friday's virtual
> interim.  We will be using Webex rather than the
> conference bridge previously announced, and will have
> global call-in numbers (see URL provided below), as
> well as the ability to record the session.
>
> Agenda:
>
> 2141 status update
> Open issues walkthrough
>
> The goal is to come to closure on some of the issues that have
> been difficult to resolve on the mailing list and set a baseline
> for consensus calls on the mailing list.
>
> Talk with you then!
>
>
> urnbis Virtual Interim
> Friday, April 17 2015
> 16:00 - 18:00 UTC (9am-11am PDT, 12pm-2pm EDT, 18:00-20:00 CET)
>
>
> Join WebEx meeting:
> https://ietf.webex.com/ietf/j.php?MTID=ma161311ff6c7053901744d309821301f
> Meeting number: 645 547 018
> Meeting password: 1234
>
> Join by phone
> 1-877-668-4493 Call-in toll free number (US/Canada)
> 1-650-479-3208 Call-in toll number (US/Canada)
> Access code: 645 547 018
>
> Global call-in numbers:
> https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=302217342&tollFree=1
>
> IMPORTANT NOTICE: Please note that this WebEx service allows audio and
> other information sent during the session to be recorded, which may be
> discoverable in a legal matter. By joining this session, you
> automatically consent to such recordings. If you do not consent to
> being recorded, discuss your concerns with the host or do not join the
> session.
>
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>


-- 
Peter Saint-Andre
https://andyet.com/


From nobody Fri Apr 17 09:07:12 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044791A00E0 for ; Fri, 17 Apr 2015 09:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7CIPGu6-WYo for ; Fri, 17 Apr 2015 09:07:09 -0700 (PDT)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB771A1A51 for ; Fri, 17 Apr 2015 09:07:00 -0700 (PDT)
Received: by pabtp1 with SMTP id tp1so129563228pab.2 for ; Fri, 17 Apr 2015 09:07:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=2nLwoQlVOOle3GCM9ovbJ0mG0pQTugRkj492TP2yzdY=; b=uK58xOMSZxWcXq9Ua17kF+5oWFTfSOIaNKApywnU/n5QrMxJC88jk6idhQixibKdi+ qv3fpjjMHa8p9ZyHbkF0lScYYwr5Mo+xSIcGjHdNtjWGT9g6qBJn76pXHM7RBlMx2ZZy onS/zM+mw6bcNIRGsbsJJm01d6KiJGjTTbZsj1U1FkrA7336YfN1ECVnUtALJE7Sf+D0 1V5qYiX5PwTMDFUXrfXemP/BnNRHUY+Lc5iU7JNT25n+EFBtNXakcGYZSv3VAp5U2tyL F9J1g6YgerIFPLCYrUOyipiKEEj2/KqUX4J251ENsTyayCfJT87e4+sUwVgqXHwafQ+8 nZfg==
X-Received: by 10.70.93.69 with SMTP id cs5mr6612255pdb.165.1429286819927; Fri, 17 Apr 2015 09:06:59 -0700 (PDT)
Received: from spandex.local (216-67-122-202.dynamic.cdma.acsalaska.net. [216.67.122.202]) by mx.google.com with ESMTPSA id zi10sm10607264pab.35.2015.04.17.09.06.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Apr 2015 09:06:59 -0700 (PDT)
Message-ID: <55312FA1.4010806@gmail.com>
Date: Fri, 17 Apr 2015 08:06:57 -0800
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Peter Saint-Andre - &yet , "urn@ietf.org" 
References: <552EA31D.1090402@gmail.com> <553129EC.1090507@gmail.com> <55312F81.70609@andyet.net>
In-Reply-To: <55312F81.70609@andyet.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Fwd: Updated virtual interim details
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Apr 2015 16:07:11 -0000

http://etherpad.tools.ietf.org:9000/p/notes-urnbis-virtualinterim-20150417?useMonospaceFont=true


From nobody Fri Apr 17 09:17:34 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824FD1A1A75 for ; Fri, 17 Apr 2015 09:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.55
X-Spam-Level: 
X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBTTaOSr3SV0 for ; Fri, 17 Apr 2015 09:17:29 -0700 (PDT)
Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 034F61A1A5A for ; Fri, 17 Apr 2015 09:17:29 -0700 (PDT)
Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 098AC8AD84; Fri, 17 Apr 2015 18:17:28 +0200 (CEST)
X-AuditID: 0a453fe7-f79106d0000047dd-f8-55313217dce3
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 4C.C4.18397.71231355; Fri, 17 Apr 2015 18:17:27 +0200 (CEST)
Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Fri, 17 Apr 2015 18:17:27 +0200
From: "Svensson, Lars" 
To: Melinda Shore , "urn@ietf.org" 
Thread-Topic: [urn] Fwd: Updated virtual interim details
Thread-Index: AQHQeSUtX8J/mWS/jkyelsFSINVVZp1RYYew
Date: Fri, 17 Apr 2015 16:17:26 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EFFAC9BDF8@dnbf-ex1.AD.DDB.DE>
References: <552EA31D.1090402@gmail.com> <553129EC.1090507@gmail.com>
In-Reply-To: <553129EC.1090507@gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.69.228]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA12TbUhTURjHO9udO1seO143d5ppOipQSV1FGkX2ISGlF7MW0Ze6tpsbbSq7 m6lBpZWRWRn2OopeWEZKZoJmJRIjsiwsiiKkjMqM6oMViGU5umd3s2vfnvt7nv///J9zuFDJ DqiN0F7s5l3FnMMUoWW0Odkjcw3zzJaMpteLsmpqvEzWib3fFMsUK25536hX+Hy/FPmKTdol Vt5hL+Nd6Uu3aG2dLQGmdEhXfqondQ84Hl0LNJDgBeTtyBlGqmPJ04HrEbVAC1l8D5DTA+eU 0sdNQAZ/fFLXAjWMwClk2EbndTiPtN9uEEcgjMGZpOmPRsJZpP/uO0aq55Hqm30qWjN4NvF2 9AA6jnAuedmSRjGLc0igp15Naw1OJpcG2oM1wPGktfWJktZKbCBtQ6MqKSUmvi6JE6wnnz8E QjyJnOx5rJDmM8hw3/mQNpU0XvwarBGOJg/PDDL1QO+V2XplEq9M4pVJLgCmCUQJziJzGmdN s1oL06x8G5Ae4lMnOPJsuR9gCEyR6CyfYWFVXJlQ4fSDNVBh0iPGbLawUYUl1gobJ9g2uzwO XjDpUPVcEaMJXOhxbDcloKpOUW+YoIJHKLVvtZd4hM0el8MPCFSKUtghDiErV1HJu0okQz+I g4zJgI7dqVrP4iLOzW/n+VLeFe5uhNBEUHOGeGa0iy/iy7fZHe5wW9TtShc7WN4JBkpCCbfE s4zyxv+ZFFDjBythpBisi/ojoZRzCvaikHcMQpRGhmnQNx4JdNHYMJzs2QvWGQ2Io/eG6YTN UzyR1RiL8mikabIGtTQmon3OdAs7XcYnu34BueITxaDLwTji7/QvI4uSKZwagsGIM9ABGlEf Yv97rRTfVoc8dAQJbs4tX/gapZFhGlr4irRwCE62M+4BtrqfQ6u8ZdP3928pSSCjB9v9ektD /6zxG6s/3q85XNA8s6GqID8hLk6T8sS3qKrpxVigzgp7R9PZ8SkLuwNrc59HOa/eG3yZHT8/ uXJG1O9Hmbe/Jx55WNPd8OC95U6qb4dqZ3f0hjZdXeOhulWKbH6x6tWm+7vnFOR1nB870HVU 1WpiBBtnTlG6BO4vXBg273EEAAA=
Archived-At: 
Subject: Re: [urn] Fwd: Updated virtual interim details
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Apr 2015 16:17:31 -0000

I'm having problems joining webex, shall be with you asap...

*** Lesen. H=F6ren. Wissen. Deutsche Nationalbibliothek ***=20
--=20
Dr. Lars G. Svensson
Deutsche Nationalbibliothek
Informationsinfrastruktur und Bestanderhaltung
Adickesallee 1
D-60322 Frankfurt am Main
Telefon: +49-69-1525-1752
Telefax: +49-69-1525-1799
mailto:l.svensson@dnb.de=20
http://www.dnb.de


> -----Original Message-----
> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Melinda Shore
> Sent: Friday, April 17, 2015 5:43 PM
> To: urn@ietf.org
> Subject: [urn] Fwd: Updated virtual interim details
>=20
> Reminder about the virtual interim, starting in about 15
> minutes.
>=20
> Melinda
>=20
>=20
> -------- Forwarded Message --------
> Subject: Updated virtual interim details
> Date: Wed, 15 Apr 2015 09:42:53 -0800
> From: Melinda Shore 
> To: urn@ietf.org , Barry Leiba 
> CC: Andrew Newton 
>=20
> This is an update to information on Friday's virtual
> interim.  We will be using Webex rather than the
> conference bridge previously announced, and will have
> global call-in numbers (see URL provided below), as
> well as the ability to record the session.
>=20
> Agenda:
>=20
> 2141 status update
> Open issues walkthrough
>=20
> The goal is to come to closure on some of the issues that have
> been difficult to resolve on the mailing list and set a baseline
> for consensus calls on the mailing list.
>=20
> Talk with you then!
>=20
>=20
> urnbis Virtual Interim
> Friday, April 17 2015
> 16:00 - 18:00 UTC (9am-11am PDT, 12pm-2pm EDT, 18:00-20:00 CET)
>=20
>=20
> Join WebEx meeting:
> https://ietf.webex.com/ietf/j.php?MTID=3Dma161311ff6c7053901744d309821301
> f
> Meeting number: 645 547 018
> Meeting password: 1234
>=20
> Join by phone
> 1-877-668-4493 Call-in toll free number (US/Canada)
> 1-650-479-3208 Call-in toll number (US/Canada)
> Access code: 645 547 018
>=20
> Global call-in numbers:
> https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&E
> D=3D302217342&tollFree=3D1
>=20
> IMPORTANT NOTICE: Please note that this WebEx service allows audio and
> other information sent during the session to be recorded, which may be
> discoverable in a legal matter. By joining this session, you
> automatically consent to such recordings. If you do not consent to
> being recorded, discuss your concerns with the host or do not join the
> session.
>=20
>=20
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn


From nobody Fri Apr 17 10:09:27 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217F61A8939 for ; Fri, 17 Apr 2015 10:09:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1
X-Spam-Level: *
X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  J_CHICKENPOX_35=0.6, MANGLED_OFF=2.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRav-tqKXVYi for ; Fri, 17 Apr 2015 10:09:24 -0700 (PDT)
Received: from zoidberg.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49C91A8915 for ; Fri, 17 Apr 2015 10:09:23 -0700 (PDT)
Received: from aran.int.lexiconix.com (pool-108-44-246-138.clppva.fios.verizon.net [108.44.246.138]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by zoidberg.ecotroph.net (Postfix) with ESMTP id 34AF6A03F1; Fri, 17 Apr 2015 13:09:21 -0400 (EDT)
Message-ID: <55313E3C.90508@thinkingcat.com>
Date: Fri, 17 Apr 2015 13:09:16 -0400
From: "Leslie Daigle (ThinkingCat)" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: John C Klensin ,  "Hakala, Juha E" 
References: <55142CA1.2000509@network-heretics.com>  <551B14E2.8060000@network-heretics.com> <55274878.60302@andyet.net> <86ABD668F4D250D365774EFF@JcK-HP8200.jck.com>  
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: urn@ietf.org, Keith Moore , Peter Saint-Andre - &yet 
Subject: Re: [urn] Persistence with f-components or p-components
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Apr 2015 17:09:26 -0000

Thanks for the nudge to this thread, which largely addresses my earlier 
comments about clarity in the document.

I do still feel that some words saying that "/" should be used iff one 
understands that one is intruducing p-components, and not as a simple 
syntactic conversion from existing namespaces.

(And, I do think the last sentence that you questioned is important).

Leslie.

On 4/14/15 11:35 AM, John C Klensin wrote:
>
>
> --On Tuesday, April 14, 2015 07:36 +0000 "Hakala, Juha E"
>  wrote:
>
>> ...
>>>>> I'm simply asking for one or two sentences to be added to
>>>>> rfc2141bis to clarify which of f-component, p-component,
>>>>> and q-component are relevant when considering persistence.
>>>>> RFC 2141 didn't need to address this issue because with
>>>>> RFC 2141 URNs, the entire URN was assigned, so the
>>>>> persistence property applied to the entire URN.
>>
>> It is a good idea to provide more information about this.
>>
>>>>>
>>>>> The text I have in mind is something like:
>>>>>
>>>>> Only the [list of components] of the URN are required to
>>>>> meet the "persistence" property specified in RFC 1737.
>>>>> Individual namespaces may, however, impose more stringent
>>>>> requirements on use of [other components].
>>
>> This should do, although a more detailed discussion about this
>> could be provided.
>
> Proposal, given changes already incorporated in -11 of 2141bis.
> If the WG decides to undo those changes, something more drastic
> will be needed.
>
> 	(i) Rename the present Section 4 to "Equivalence and
> 	Persistence of URNs".
> 	
> 	(ii) Add a new subsection 4.2, incrementing the number
> 	for the current 4.2 to 4.3, titled "URN Persistence"
> 	that reads:
> 	
> 	For consistency with the "persistence" property
> 	[RFC1737] and as a logical consequence of the
> 	equivalence procedure described immediately above, only
> 	the  (see Section 3 above) are
> 	necessarily treated as persistent.  Individual
> 	namespaces may, however, impose more stringent
> 	requirements on the use of q-components or f-components.
>
> I'm not sure whether the final sentence above is needed or not
> or whether, if we include it, it will touch off another battle
> about what we are allowed to say about fragments.  It can,
> obviously, be easily removed if it is more trouble than it is
> worth.   Alternate phrasing and/or nit-picking welcome, but the
> above ties persistence explicitly and strongly to URN
> equivalence as Peter and I have suggested elsewhere.
>
> Is something like that sufficient for us to move on? Vis-a-vis a
> more detailed discussion, I don't know quite what to say, so, if
> more is needed, please send either text or a detailed outline
> (or ask Melinda and Andy to put it on Friday's agenda).
>
>> ...
>>> Individual namespaces may, however, impose
>>>>> additional restrictions on the use of q-component and/or
>>>>> f-component.
>>
>> + 1
>
> Incorporated into the above suggestion, but see the comment
> there.
>
>> ...
>>>> I think the persistence rule falls out from equivalence
>>>> rule.
>>
>> Equivalence is one way of deciding what should be persistent,
>> and perhaps sufficient for RFC 2141bis.
>>
>> It is also possible to look at this from administrative point
>> of view. Only the assigned name such as ISBN has (or should
>> have) solid administrative basis. When users later add for
>> instance f-components to URN:ISBNs in order to cite locations
>> within e-books, they do that "at their own risk", even though
>> an f-component added to a URN which identifies a single
>> manifestation of a resource (such as a PDF version of a book)
>> is likely to be more persistent than fragment added to a URL.
>
> That "administrative" explanation is the reason I've sort of
> resisted making explicit statements about persistence in 2141bis
> or elsewhere.   Clearly it would be possible to explain
> persistence on that basis.  IMO, it would be more satisfactory
> in some ways.  However, I don't believe that it would be
> consistent with what RFC 1737 has to say.  I've got other issues
> with that document, most of which come down to "we've learned
> some things in 20 years", but really don't want to reopen if if
> that can be avoided.
>
>> It would be awkward to require persistence of q-components,
>> since resolution services available and whatever is being
>> supplied will change over time. For instance, if a q-component
>> requests metadata about a resource, the metadata record
>> retrieved may change from one day to the next, and even the
>> default metadata format supplied may change (from e.g. MARC 21
>> to Dublin Core).
>
> Yes.
>
>>>> If we say that only the assigned-name and the p-component
>>>> are taken into account for purposes of determining
>>>> equivalence, then I think we would say that only the
>>>> assigned-name and p-component are required to meet the
>>>> persistence property.
>>
>> OK for me, but it might be a good idea to say that currently
>> (most) standard identifiers out there do not allow usage of
>> p-component, and it is necessary to investigate whether adding
>> it would be useful.
>
> Today, no standard identifier allows usage of any of p-, q-, or
> f-component (although the "fragment" discussion may interact
> with the latter) because such usage violates RFC 2141
> restrictions.  Especially for established namespaces (and again
> modulo the "fragement" issues), none of these qualifying
> decorations should be added unless they are useful.  At least
> without more clarity about which components serve which roles in
> URN processing, evaluation, and/or resolution, p- and
> f-components are, IMO, more likely to be problematic than
> f-components (that has been said in the WG in various forms for
> two years now).   How much of that do you think we need to say
> explicitly?
>
> best,
>     john
>
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
ldaigle@thinkingcat.com
-------------------------------------------------------------------


From nobody Fri Apr 17 11:29:04 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C631B2EF2 for ; Fri, 17 Apr 2015 11:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGEqHcH5vQq1 for ; Fri, 17 Apr 2015 11:29:01 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A37F1B2EF1 for ; Fri, 17 Apr 2015 11:29:01 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YjB0e-0000rg-3q for urn@ietf.org; Fri, 17 Apr 2015 14:29:00 -0400
Date: Fri, 17 Apr 2015 14:28:53 -0400
From: John C Klensin 
To: urn@ietf.org
Message-ID: <8AEAB125F8F87EC748B12990@JcK-HP8200.jck.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Subject: [urn] The persistence paragraph
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Apr 2015 18:29:03 -0000

Hi.  There was some confusion on the phone about the proposed
persistence paragraph for 2141bis-12.  While it was posted to
the list, it embedded in a much longer note and discussion.
So, for everyone's convenience, here is is again:

> 	(i) Rename the present Section 4 to "Equivalence and
> 	Persistence of URNs".
> 	
> 	(ii) Add a new subsection 4.2, incrementing the number
> 	for the current 4.2 to 4.3, titled "URN Persistence"
> 	that reads:
> 	
> 	For consistency with the "persistence" property
> 	[RFC1737] and as a logical consequence of the
> 	equivalence procedure described immediately above, only
> 	the  (see Section 3 above) are
> 	necessarily treated as persistent.  Individual
> 	namespaces may, however, impose more stringent
> 	requirements on the use of q-components or f-components.

The final sentence may or may not be needed -- that is one of
those relatively minor issues.  Someone, probably Keith, asked
for it and Leslie said in a note earlier today that it was worth
keeping, so anyone who disagrees should speak up.  Even more
important, anyone who thinks the whole paragraph is wrong or
doesn't solve the problem should speak up soon and vigorously.

    john


From nobody Fri Apr 17 14:27:08 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C368D1B2F14 for ; Fri, 17 Apr 2015 14:27:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4hkv7dV4lSa for ; Fri, 17 Apr 2015 14:27:03 -0700 (PDT)
Received: from zoidberg.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF5F1B2CE0 for ; Fri, 17 Apr 2015 14:27:03 -0700 (PDT)
Received: from cashmere.int.lexiconix.com (pool-108-44-246-138.clppva.fios.verizon.net [108.44.246.138]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by zoidberg.ecotroph.net (Postfix) with ESMTP id 6ABD6A0F6C; Fri, 17 Apr 2015 17:27:01 -0400 (EDT)
Message-ID: <55317AA4.70105@thinkingcat.com>
Date: Fri, 17 Apr 2015 17:27:00 -0400
From: "Leslie Daigle (ThinkingCat)" 
Organization: ThinkingCat Enterprises
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Keith Moore ,  Peter Saint-Andre - &yet , urn@ietf.org
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com> <552F15AD.2050405@andyet.net> <552F6234.4080509@network-heretics.com>
In-Reply-To: <552F6234.4080509@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Apr 2015 21:27:07 -0000

Hi,

Thinking through the r-component idea a bit...   I think your 
argumentation for r-components is pretty compelling, especially as we 
work to make clear why f-components don't fit that particular bill. 
However, I am more than a little concerned about getting too complex and 
bolting stuff on at this point.

I won't argue that DDDS has been used for just about everything *except* 
providing the standard for URN resolution, but in working it out we I'm 
sure you recall we did did actually talk through "resolution services" 
(for ease of reference for anyone who missed it -- 
https://tools.ietf.org/html/rfc2483).

Again, not quite what you are describing now (I read you to be thinking 
more about parameters one would send, not services one would request), 
but perhaps enough to illustrate that there is a whole farm of things 
one might wish to consider if one stops and thinks about using URNs in 
action.

I think pursuing r-components as part of this document would slow this 
one down a fair bit.

Is there a way to leave enough of a hook in the syntax to pursue 
r-component as a separate document?  (BTW...  does "??" actually fly 
with URI syntax, or wouldn't the 2nd "?" be part of the q-component?).

Leslie.


On 4/16/15 3:18 AM, Keith Moore wrote:
> On 04/15/2015 09:51 PM, Peter Saint-Andre - &yet wrote:
>> Hi Keith, I concur with John that this is very helpful input to the
>> discussion. Comments inline.
>>
>> On 4/14/15 10:05 AM, Keith Moore wrote:
>>> On 04/13/2015 04:10 PM, John C Klensin wrote:
>>>> Hi.
>>>>
>>>> Those who have been following the apps-discuss list and the Apps
>>>> Area WG has seen a long, difficult, and sometimes unpleasant
>>>> thread about what a URN specification (or any other
>>>> specification for a particular URI scheme) is allowed to say
>>>> about fragments.  The discussion appears to extend to whether
>>>> fragments can be disallowed at all by a scheme (if they cannot,
>>>> 2141 has problems quite independent of what we might do), to
>>>> whether a scheme can constrain fragment syntax in any way, and
>>>> to whether scheme-specific or namespace-specific restrictions or
>>>> semantic [1] rules are allowed.
>>>>
>>>> Similar issues arise with p-components.   If a p-component
>>>> (i.e., introduced by a "/", at least before a q-component or
>>>> f-component) appears in a URN, it is claimed to be impossible
>>>> [2] to avoid relative resolution, something that might cause
>>>> havoc or other damage with URNs.
>>>>
>>>> An obvious question is why we don't just disallow one or both
>>>> and move on.
>>>>
>>>> For me, the answer is tied up with the question I've been asking
>>>> about the difference between instructions or qualifiers that are
>>>> part of the URN (see below) and instructions or qualifiers that
>>>> are intended to be passed to whatever the URN points to or
>>>> resolves to.   If no one else sees that as an issue, or believes
>>>> that we can reasonable handle it on a per-namespace basis (that
>>>> fragment discussion definitely would complicate handling those
>>>> on a per-namespace basis), please explain why and I'd drop this.
>>>> If others are concerned and believe we should handle that issue
>>>> using syntax, then I believe we need to consider three cases.
>>>> (I don't see any alternative to distinguishing by syntax if we
>>>> aren't going to make the distinction per-namespace, but maybe
>>>> I'm missing something):
>>>>
>>>> I'm going to use the term "qualifier" below to identify things
>>>> that are not inherently part of the NSS (using the syntax in
>>>> 2141bis-11) but that are part of the .
>>>>
>>>>   Case 1: The qualifier is part of the URN to the extent
>>>>     that it is included in comparisons and affects
>>>>     persistence.  As part of the URN, it is expected to
>>>>     affect or provide information to a URN processor or
>>>>     resolver.
>>>>
>>>>   Case 2: The qualifier is part of the URN in the sense
>>>>     that if affects or provides information to a URN
>>>>     processor or resolver, but does not participate in
>>>>     equality comparisons.    Information about locale (so a
>>>>     URN resolver could find the most convenient object or a
>>>>     pointer to it) would presumably fall into this category.
>>>>     I think distinctions between object and various types of
>>>>     metadata would too, but could be talked out of that.
>>>>
>>>>   Case 3: The qualifier is not part of the URN but
>>>>     contains information or specifications that should be
>>>>     passed on to the URN's target if that is meaningful.
>>>>     The qualifier is probably not meaningful if there is no
>>>>     resolution and no target.
>>>
>>> I think there are actually four categories of "qualifier":
>>
>> I would love to see examples of each of these, by the way.
>>
>>> 1. Qualifiers that potentially represent portions of resources, and/or
>>> relationships with other resources named with URNs, that should be
>>> included in comparisons and considered relevant for persistence.
>>
>> I would especially like to see examples of #1, because I am not sure
>> that they exist.
>
> When I first wrote up that list, I wasn't sure about #1 myself.   I
> almost stated that #1 wasn't very useful, then I realized that that type
> of qualifier probably is needed after all, or at least that it wasn't
> safe to say that they're not needed.
>
> One reason for having such a qualifier is this: you'd really like to be
> able to have persistent references to portions of a resource. Fragments,
> as currently defined and implemented, don't serve that purpose.   (I
> could explain why but it would be a long side discussion, so will leave
> it to a separate message if the explanation is needed).   So
> *urn:example:/a* might refer to the entirety of a resource and
> *urn:example:/a/b* might refer to a portion of that resource, and
> *urn:example:/a/b/c* refer to a (presumably) still smaller portion - and
> all of these URNs would be managed by the namespace and expected to
> remain persistent over time (including their relationships to one
> another, if any of them used relative references).
>
>>> 2. Qualifiers that identify portions of resources that should not be
>>> included in comparisons or when considering persistence.
>
> I think this ends up being the fragments to which we're already
> accustomed.   IMO, the ability to specify a fragment of a URN-named
> resource is still useful, it's just that the combination of a URN and a
> fragment name (or if you prefer, f-component) no longer has any
> assurance of persistence.   So *urn:example:a* has an assurance of
> persistence but *urn:example:a#b* does not.   I think this will confuse
> people for a while, because they'll have to learn to mentally parse URNs
> differently than URLs.   But overall this might be the best path
> forward.   It would be difficult for us to exclude use of fragments with
> URNs, or to define fragment behave differently with URNs than with URLs,
> without breaking relative references.
>
> So I am thinking that the meaning of the fragment should still be the
> same for both URNs and URLs.   Ideally if *urn:example:a* resolves to
> *http://example.com/b*, and c is a valid fragment of that resource, then
> *urn:example:a#c* and *http://example.com/b#c *should refer to the same
> portion of that resource's content.   The alternative of letting
> fragments work differently for URNs vs. URLs strikes me as /very/
> unlikely to work well, especially if 3986-style relative reference
> processing can be applied to URNs.
>>>
>>> 3. Qualifiers that are transmitted to resources (when applicable) for
>>> interpretation by the resources.   These should not be included in
>>> comparisons or when considering persistence.
>
> This is analogous to query strings in HTTP.   IMO it's vital to let URNs
> be able to bundle the name of the base resource with some input to be
> transmitted to the resource.   So similar to fragments, I think that if
> *urn:example:a* resolves to *http://example.com/b*, then
> *urn:example:a?c* should ultimately result in a GET of
> *http://example.com/b?c* .   Again, *urn:example:a* is persistent while
> *urn:example:a?c* has no assurance of persistence.
>>>
>>> 4. Qualifiers that affect resolution of the URN, and which should be
>>> transmitted to the resolution service if one is used, either to request
>>> a specific kind of resolution service, or to narrow down between
>>> multiple versions and/or representations of the content.
>
> For the sake of an example of how this might be used, let's say that
> such a qualifier must begin with "??", that it appears before
> q-component, and the value of that qualifier is not allowed to contain
> "?" without it being %-encoded.  I'll tentatively call this an
> "r-component" ("r" for resolution)
>
>   * *urn:example:a* would refer to the resource without specifying what
>     to do with the URN.  If such a URN appeared in a link in a resource
>     being viewed in a browser, and a user clicked on that link, the
>     browser might try to present the content to the user.   Or failing
>     that, it might simply try to get a description of the resource and
>     display that.   If OTOH, such a URN appeared in an IMG tag the
>     browser might give up if it couldn't get the content - presumably
>     the description of the resource isn't an image.
>   * *urn:example:a??request=content* would tell the resolution service
>     (and perhaps also the client) that the reference was specifically
>     intended to be for the resource's content, and not to locations, or
>     any kind of description or metadata of the resource
>   * *urn:example:a??request=metadata;format=dc-rdf *might request that
>     the resolution service return a description of the resource in RDF
>     format and the Dublin Core schema.
>   * *urn:example:a??request=locations* could request locations of the
>     resource
>   * *urn:example:a??request=content;version=first* could request the
>     earliest version of the resource
>
> Basically these qualifiers would serve as a kind of query to the
> resolution service (as opposed to a query to be sent to the resource).
> It's like searching for a resource in a library's catalog and specifying
> some details that narrow the results along with the query.
>
> As far as I can tell, this kind of capability is vitally important,
> because almost every time I see any functionality of a resolution
> service described, there's at least one or two examples of how one might
> include such queries with a URN.   IMO, if URNs don't provide a standard
> way to do it, URN resolution services will overload "?" and the result
> will be that (a) you can't specify a URN that includes a query to be
> sent to the resource itself (at least not in any uniform way) and (b)
> different schemes will behave differently and it will be difficult to
> write clients that treat Uniform Resource Names in any kind of uniform
> fashion.
>
> Of course the above are just examples of what could be done, rather than
> a well thought-out proposal.   I would also suggest that namespaces
> should be able to define their own requests and parameters independently
> of others.   So for the "ietf" namespace, IETF should be able to support
> things like *
> urn:ietf:rfc:XXXX??request=ietf.version-history;option=include-I-Ds
> *
>>
>> I continue to struggle with two things (or perhaps misconceptions in
>> my own mind) about our discussions:
>>
>> (a) Not all URNs need to be or can be resolved, and it seems to me
>> that even URNs that can be resolved are primarily used to identify
>> resources and not to resolve resources (which is why we have URLs,
>> after all).
>>
>> (b) We don't know enough about the running code of modern, actual URN
>> resolution services to helpfully specify what kind of syntax they
>> might require.
>>
>> Regarding (a), we have (i) a large number of URN namespaces that are
>> used by other SDOs or quasi-SDOs to assign identifiers for uses like
>> XML namespaces. I strongly encourage the WG participants to spend some
>> time looking through the list of formal namespaces:
>>
>> http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
>>
>> As far as I can see, most of the URNs that are assigned in those
>> namespaces aren't intended to be resolved at all. They are, in the
>> perhaps less than perfect terminology of 2141bis, "abstract
>> designators". In these cases, there is simply no need to worry about
>> qualifiers 3 & 4.
>
> There's been a lot of misunderstanding and misuse of URNs.   URNs were
> intended to name resources, not to merely be unique strings. I don't
> mind if people sometimes use URNs as merely unique strings, as I don't
> think it does much harm - except that some people have gotten the idea
> that this is the primary purpose of URNs.  It's not.  I don't even
> recall that particular use case even being mentioned through years of
> discussions about URNs in the mid-1990s.   To the extent URNs are usable
> in this way, it's a corner-case, an unintended consequence, not the
> general or typical case.
>
> More generally, statements about how URNs "should be" that are based on
> observations of current namespaces or currently-observed usage of URNs
> strike me as about as valid as statements about how IPv6 should be,
> based on currently-observed usage of IPv6.   URNs, like IPv6, have been
> around for ~20 years, were designed to be usable for a very long time,
> but are really just starting to be used.   What we're seeing now with
> URNs (just like what we saw with IPv6 until recently) is still mostly
> due to early adopters, and shouldn't be considered as any indication of
> what will be typical of future use.   The communities that are most
> interested in using URNs properly are conservative by their very nature.
>
>> We also have (ii) a few URN namespaces (albeit namespaces with a huge
>> number of assigned URNs) where resolution is at least possible. These
>> are namespaces such as those for ISBNs, ISSNs, and NBNs. However, even
>> here I think (perhaps without sufficient basis) that these URNs are
>> assigned primarily for the purpose of identification ("this URN
>> identifies that work") and not for the purpose of resolution ("this
>> URN enables you to find a copy of that work on a shelf in this
>> building").
>
> See above.   Of course ISBNs and ISSNs were in wide use long before URNs
> were standardized, and all of these numbers were "grandfathered" as
> URNs, so it's not at all surprising that there are huge numbers of
> these.   Again, their use should not be taken as a prescription for how
> URNs will, or should, be "typically" used in the future.
>
> Of course - the primary purpose of a URN *is* to identify a resource.
> But if you encounter a reference to a URN on a computer that's attached
> to the Internet (or even an isolated, private network), then it's quite
> likely you will find it useful to not merely be able to identify that
> resource, but also to query for information about that resource, and/or
> try to access the resource or obtain its content.   You won't always be
> able to do these things for any of a large number of reasons, e.g. the
> URN isn't known to any of the resolution services you consult; the URN
> refers to a resource that isn't amenable to network access or isn't
> online; you don't have permission to access it, etc.   But just because
> such services won't always be available is no reason to cripple URNs in
> such a way as to make it more difficult to provide those services.
>
> URNs were always intended to be able to support resolution.   Back to
> the IPv6 analogy, saying that URNs supporting resolution is of secondary
> importance is about like saying that the ability IPv6 to access hosts
> not on the IPv4 Internet is of secondary importance, because hardly
> anyone is doing that at the moment.   (of course that's really not true
> but many haven't noticed yet)
>
>>
>> When I combine the (to me) secondary importance of resolution for URNs
>> with the fact that we don't know much about the running code of URN
>> resolution services, I find myself at a loss to define the syntax, and
>> certainly the semantics, of qualifiers 3 & 4 with any degree of
>> precision. That is why I think 2141bis needs to be somewhat general
>> about the syntax of those qualifiers (other than making sure that
>> syntax is consistent with the URI syntax).
>
> I don't think we need (or want) a huge amount of precision.   In
> particular I don't think we should try to define a complete vocabulary
> for requests to resolution services and their parameters, and would
> actually prefer to see that work done outside of IETF. What I'd like to
> see is:
>
>   * a small modification to the 2414bis grammar for URNs, to permit
>     "r-components" in addition to f-, p- and q-components. (I think we
>     can do this without breaking 3986 parsers, and with low risk of
>     conflict with existing use of query strings.)
>   * a grammar for r-component that allows multiple parameter names and
>     associated values within that r-component to be specified to
>     resolution services
>   * an IANA registry for parameter names and/or associated values, with
>     expert review required to add new ones, and each namespace having
>     its own reserved prefix that it can do with as it wishes
>   * a very minimal initial set of parameters, probably just defining
>     "request" and "format" with an IANA registry for the names
>     associated each, and 3 or 4 very basic requests.
>
> I'm thinking this should be around 2-3 pages added to 2141bis, and I'm
> willing to draft text.
>
>
>>
>> As an example, we might need to wait until we know a lot more about
>> modern URN resolution systems before we can define name-value pairs
>> for q-components.
>
> IMO, rather than wait, we should let people who are building URN
> resolution systems define that vocabulary.   IETF's role should be to
> try to get the underlying protocol right, and  to make sure that URNs (+
> 3986 rules) don't inhibit resolution or uniform handling, and don't
> cause breakage when used with resources also named by URLs.   IETF's
> role should not be to try to discover for itself how to design a query
> language for a resource cataloging system.
>
>>
>> And, to be clear, for the limited purposes of 2141bis I think that is
>> fine. As I see it, the alternative is that this WG would postpone its
>> delivery of updates to RFC 2141 much longer than it already has, with
>> very little to show for that further delay and a great risk of failure
>> or fragmentation.
>
> I think that the risk of failure or fragmentation is actually much
> greater if we fail to specify how to distinguish between each of the 4
> types of qualifiers in a uniform way.
>
> Or to put it a different way, there are two ways to get
> failure/fragmentation:   One is for us to delay so long that each
> namespace or community goes off and does things its own way, and the
> other is for us to fail to specify things completely or correctly enough
> so that each namespace or community is forced to do things its own way.
>
> Keith
>
>
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
ldaigle@thinkingcat.com
-------------------------------------------------------------------


From nobody Fri Apr 17 16:14:12 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274AE1B30DA for ; Fri, 17 Apr 2015 16:14:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpkNAMGLqqlz for ; Fri, 17 Apr 2015 16:14:09 -0700 (PDT)
Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E32371B30D8 for ; Fri, 17 Apr 2015 16:14:08 -0700 (PDT)
Received: by pdbqa5 with SMTP id qa5so142056981pdb.1 for ; Fri, 17 Apr 2015 16:14:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=728grZQqs/YdyYSmJzJbzQcf7fJv319zsoT4BA/9dcc=; b=VWz+ySueYq8z1LGFbXk3Sv1lBDH4GG5y/mFrX/ibuFisoM8/x7Ng3MfbtL/JXLZ3ol BYM4ABxqLuwBG1Sk+a0NiqIBWw76kP6FmxCwEm72ypAV4JdCHXbka3moNUE57HWnmCz4 29C3LkOWPUNTQkyu2BlkIyhQ4iLWneCG1i1zTqjRkNifvu/S/wGpnkRujbMF0bIDyLkm 7ATcd+iU0XyaUs1V6VnfuqnImGDIy2gIQ/azmcszBhqNKN6au+oZMOm3KO6dqd36THQz YyULy5kwF4DPyDfTAP2go2f9XtVO3tcOo6mBKLttFzscauAc/ynq8gp/i5C9o9jNwRs9 BLvQ==
X-Received: by 10.68.110.3 with SMTP id hw3mr9195650pbb.128.1429312447709; Fri, 17 Apr 2015 16:14:07 -0700 (PDT)
Received: from spandex.local (216-67-122-202.dynamic.cdma.acsalaska.net. [216.67.122.202]) by mx.google.com with ESMTPSA id h12sm11125254pdk.77.2015.04.17.16.14.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Apr 2015 16:14:07 -0700 (PDT)
Message-ID: <553193BD.1060002@gmail.com>
Date: Fri, 17 Apr 2015 15:14:05 -0800
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "urn@ietf.org" 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [urn] Virtual interim notes and recording
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Apr 2015 23:14:10 -0000

Many thanks to those participating in today's interim.  The
minutes from the session have been uploaded to the IETF
proceedings:
https://www.ietf.org/proceedings/interim/2015/04/17/urnbis/minutes/minutes-interim-2015-urnbis-1

The audio recording is available for streaming online here:
https://ietf.webex.com/ietf/ldr.php?RCID=be009930f7e8e6b5d3067f59bac5992c

and for download here:
https://ietf.webex.com/ietf/lsr.php?RCID=428366b007c21d9feef07914e0ca34ff

Melinda


From nobody Fri Apr 17 16:24:45 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7F91B30DD for ; Fri, 17 Apr 2015 16:24:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjCmloP5RK-T for ; Fri, 17 Apr 2015 16:24:41 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9471B30E0 for ; Fri, 17 Apr 2015 16:24:41 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 920662075E for ; Fri, 17 Apr 2015 19:24:40 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 17 Apr 2015 19:24:40 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=OR1IdkERijTMh23 XufFytfSYy80=; b=BHzOjGJ4K7N4a51lj+AhqAQCeqMLAlR7/OOxuh3t6VEJwJC CJztv0dXNrmgIiiIGRjnvuqzQshhh14HzXO1L7e7jFWsmWdUC/nqtoOHMioWl94i UjT6VP7bfp81UUUTHe6fp9Yt9HywJyDKbISG2w+K2zxBcchqQ0AU6YjfIAUo=
X-Sasl-enc: NJSMt0Wkw5NM+014zeYMGGi4zV5IE6jdubkVpAc7bF7x 1429313080
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 3D927C00013; Fri, 17 Apr 2015 19:24:40 -0400 (EDT)
Message-ID: <5531961F.4010207@network-heretics.com>
Date: Fri, 17 Apr 2015 19:24:15 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <8AEAB125F8F87EC748B12990@JcK-HP8200.jck.com>
In-Reply-To: <8AEAB125F8F87EC748B12990@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] The persistence paragraph
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Apr 2015 23:24:42 -0000

On 04/17/2015 02:28 PM, John C Klensin wrote:
> Hi.  There was some confusion on the phone about the proposed
> persistence paragraph for 2141bis-12.  While it was posted to
> the list, it embedded in a much longer note and discussion.
> So, for everyone's convenience, here is is again:
>
>> 	(i) Rename the present Section 4 to "Equivalence and
>> 	Persistence of URNs".
>> 	
>> 	(ii) Add a new subsection 4.2, incrementing the number
>> 	for the current 4.2 to 4.3, titled "URN Persistence"
>> 	that reads:
>> 	
>> 	For consistency with the "persistence" property
>> 	[RFC1737] and as a logical consequence of the
>> 	equivalence procedure described immediately above, only
>> 	the  (see Section 3 above) are
>> 	necessarily treated as persistent.  Individual
>> 	namespaces may, however, impose more stringent
>> 	requirements on the use of q-components or f-components.
> The final sentence may or may not be needed -- that is one of
> those relatively minor issues.  Someone, probably Keith, asked
> for it and Leslie said in a note earlier today that it was worth
> keeping, so anyone who disagrees should speak up.  Even more
> important, anyone who thinks the whole paragraph is wrong or
> doesn't solve the problem should speak up soon and vigorously.

I don't recall asking for the final sentence.  If I did, I no longer 
think it's a good idea based on what seems to be the emerging consensus.

Assuming relative references are to be evaluated with respect to a URL 
that is obtained during resolution or specified in the resource itself,  
I think that implies that the f-component and q-component are not within 
the purview of the namespace, except to the extent that a namespace can 
choose to not assign URNs to resources for which fragments and/or 
queries are meaningful.

More generally, I think only the assigned-name portion of the URN is 
really under control of the namespace.

Keith


From nobody Fri Apr 17 16:37:04 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D7A1B30F3 for ; Fri, 17 Apr 2015 16:37:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_TCoZEM0ivy for ; Fri, 17 Apr 2015 16:37:00 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B401B30F2 for ; Fri, 17 Apr 2015 16:36:55 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2FBAE209A9 for ; Fri, 17 Apr 2015 19:36:55 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 17 Apr 2015 19:36:55 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=tx7VBR48x1RrcS7JOwS1mIWQcDU=; b=EHHwt +ZSjMG+Kj/M0i7Z/fNmIYOzz36zXhQExXEUu3zZ6bYYlvx8LDPKopN8lDKg2WdmL TbLgvmE4JLrSE9VMpb26rso4XYMMpkQnCiwa9Xb14cFmptZXf5ZV/dUJbg7rb/0W TOtPEzZOaNHzWbQqlrfzbgkDF9klK24o2suVmM=
X-Sasl-enc: rvetFPsPYdyeLVuztU5EBXG4Or4XCb8tfy3qyiCaASh4 1429313814
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id D2252C00015; Fri, 17 Apr 2015 19:36:54 -0400 (EDT)
Message-ID: <553198FE.8020602@network-heretics.com>
Date: Fri, 17 Apr 2015 19:36:30 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com> <55312E53.2010605@thinkingcat.com>
In-Reply-To: <55312E53.2010605@thinkingcat.com>
Content-Type: multipart/alternative; boundary="------------080909010404070602090305"
Archived-At: 
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Apr 2015 23:37:01 -0000

This is a multi-part message in MIME format.
--------------080909010404070602090305
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 04/17/2015 12:01 PM, Leslie Daigle (ThinkingCat) wrote:
> IMO, that can be achieved by being clear about what the NSS is, assert 
> that relative URNs are not expected/permitted, and attest that "/" 
> should not be used in a URN simply because one is importing a 
> namespace that happens to use them and it's a matter of syntactic 
> convenience not to escape them with %-encoding. 

If relative references are never evaluated with respect to URNs, but 
only with respect to URLs that contain paths, I don't think we need to 
constrain p-components of URNs to be paths, or to mandate any 
relationship between the p-components and the resources named (e.g. 
*urn:example://a/b* and *urn:example://a/c* need have no relationship to 
one another), or define what they mean at all.   The only constraints we 
need to impose on them are those dictated by the desire to be 
syntax-compatible with RFC 3986.   A namespace could use p-components 
however it wished, as long as the rules for comparison for the sake of 
determining equivalence weren't broken.

So the only issue I would have with importing a namespace that happens 
to use "/" in the assigned portion of its names would be if the 
resulting syntax violated the 3986 grammar.

So for instance, if a namespace assigned names of the form a/b/c, it 
wouldn't do for it to advertise URNs of the form *urn:namespace:a/b/c* 
.   It would instead have to be *urn:namespace://a/b/c* .

Keith


--------------080909010404070602090305
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 04/17/2015 12:01 PM, Leslie Daigle
      (ThinkingCat) wrote:

    

    
IMO,
      that can be achieved by being clear about what the NSS is, assert
      that relative URNs are not expected/permitted, and attest that "/"
      should not be used in a URN simply because one is importing a
      namespace that happens to use them and it's a matter of syntactic
      convenience not to escape them with %-encoding.
    

    

    If relative references are never evaluated with respect to URNs, but
    only with respect to URLs that contain paths, I don't think we need
    to constrain p-components of URNs to be paths, or to mandate any
    relationship between the p-components and the resources named (e.g.
    urn:example://a/b
    and urn:example://a/c
    need have no relationship to one another), or define what they mean
    at all.  The only constraints we need to impose on them are those
    dictated by the desire to be syntax-compatible with RFC 3986.  A
    namespace could use p-components however it wished, as long as the
    rules for comparison for the sake of determining equivalence weren't
    broken.

    

    So the only issue I would have with importing a namespace that
    happens to use "/" in the assigned portion of its names would be if
    the resulting syntax violated the 3986 grammar.

    

    So for instance, if a namespace assigned names of the form a/b/c, it
    wouldn't do for it to advertise URNs of the form urn:namespace:a/b/c
    . It would instead have to be urn:namespace://a/b/c .

    

    Keith

    

  


--------------080909010404070602090305--


From nobody Fri Apr 17 17:06:10 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F901B3107 for ; Fri, 17 Apr 2015 17:06:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stxfSp4wwAQ9 for ; Fri, 17 Apr 2015 17:06:07 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29EBE1B2FB0 for ; Fri, 17 Apr 2015 17:06:07 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7FCDC20A4E for ; Fri, 17 Apr 2015 20:06:06 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 17 Apr 2015 20:06:06 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=oDCuikh3rNRaPKgHqwFu7LQntRY=; b=dc3X6 xiCiLWQzXS4h52MnBOaWVypSWTSpsBwzZHhmhAhaEENtk/dWrRykRDFqB4RvVB1J YmEZ1G1r/7RzbOeB1L02R4+SfNjo/X6sJpcYY/xyWHbDud8qTvsNgK7uyJe/CdeJ FNS6ljaTnNBRRgpaNvpiva9jKAX4fGaKCfSmyM=
X-Sasl-enc: Hmghhln4A1c/7Ts/SFb5WMapI+EY0tz45dh25cfGI9zy 1429315566
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 1DDEC680194; Fri, 17 Apr 2015 20:06:06 -0400 (EDT)
Message-ID: <55319FD5.1070404@network-heretics.com>
Date: Fri, 17 Apr 2015 20:05:41 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com> <552F15AD.2050405@andyet.net> <552F6234.4080509@network-heretics.com> <55317AA4.70105@thinkingcat.com>
In-Reply-To: <55317AA4.70105@thinkingcat.com>
Content-Type: multipart/alternative; boundary="------------070200050606010607070101"
Archived-At: 
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Apr 2015 00:06:09 -0000

This is a multi-part message in MIME format.
--------------070200050606010607070101
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 04/17/2015 05:27 PM, Leslie Daigle (ThinkingCat) wrote:
> Hi,
>
> Thinking through the r-component idea a bit...   I think your 
> argumentation for r-components is pretty compelling, especially as we 
> work to make clear why f-components don't fit that particular bill. 
> However, I am more than a little concerned about getting too complex 
> and bolting stuff on at this point.
>
> I won't argue that DDDS has been used for just about everything 
> *except* providing the standard for URN resolution, but in working it 
> out we I'm sure you recall we did did actually talk through 
> "resolution services" (for ease of reference for anyone who missed it 
> -- https://tools.ietf.org/html/rfc2483).
>
> Again, not quite what you are describing now (I read you to be 
> thinking more about parameters one would send, not services one would 
> request), but perhaps enough to illustrate that there is a whole farm 
> of things one might wish to consider if one stops and thinks about 
> using URNs in action.
>
> I think pursuing r-components as part of this document would slow this 
> one down a fair bit.
>
> Is there a way to leave enough of a hook in the syntax to pursue 
> r-component as a separate document?  (BTW...  does "??" actually fly 
> with URI syntax, or wouldn't the 2nd "?" be part of the q-component?).

"Leaving [just] enough of a hook" is exactly what I want to do in this 
document.  I think that means:  (a) define the syntax for URNs including 
that of r-components, (b) explain the role of r-components in URN 
resolution, and (c) set up an IANA registry of r-component names and 
values.   Maybe also (d) explain how this is syntax compatible with 
3986.  I think that's about enough for 2141bis.

(I'm thinking that I should suggest explicit text for this if for no 
other reason than that that exercise will give us a good idea of just 
how much would need to be added to 3986.)

Separate from 2141bis, I'm thinking I might like to write up an 
Experimental or Informational document defining a simple URN resolution 
service and a client API for such a service.   (perhaps cribbing a bit 
from RFC 2483).   This simple service would define a minimal set of 
simple requests and the parameters for such requests.   The main purpose 
in doing so would be to serve as a proof-of-concept and to encourage 
further development in this area by the library community.

And yes, the 2nd "?" would be part of the q-component if this were 
parsed according to 3986.   Given a URN

*urn:example:something??a=b;c=d?mumble*

a 3986-style parser would return

{
    "scheme": "urn",
    "path": "example:something",
    "query": "??a=b;c=d?mumble"
}.

However, it doesn't violate 3986 syntax, because "?" is explicitly 
permitted within .  (See RFC 3986, section 3.4, top of page 24)

My take on this is that an ordinary URL parser shouldn't cause 
catastrophic failure (like causing the program to crash) with something 
that conforms to 3986 syntax.   Of course, most existing programs don't 
try to do URN resolution anyway, so their inability to parse URNs 
exactly like I'm proposing for 2141bis won't really do them much harm.   
By contrast, programs that support URN resolution in the future can 
parse them according to the 2141bis grammar, which would yield a result 
like:

{
    "scheme": "urn",
    "namespace": "example",
    "nss": "something",
    "r-component": { "a": "b", "c": "d" },
    "q-component": "mumble"
}



--------------070200050606010607070101
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 04/17/2015 05:27 PM, Leslie Daigle
      (ThinkingCat) wrote:

    

    
Hi,
      

      

      Thinking through the r-component idea a bit... I think your
      argumentation for r-components is pretty compelling, especially as
      we work to make clear why f-components don't fit that particular
      bill. However, I am more than a little concerned about getting too
      complex and bolting stuff on at this point.
      

      

      I won't argue that DDDS has been used for just about everything
      *except* providing the standard for URN resolution, but in working
      it out we I'm sure you recall we did did actually talk through
      "resolution services" (for ease of reference for anyone who missed
      it -- https://tools.ietf.org/html/rfc2483).
      

      

      Again, not quite what you are describing now (I read you to be
      thinking more about parameters one would send, not services one
      would request), but perhaps enough to illustrate that there is a
      whole farm of things one might wish to consider if one stops and
      thinks about using URNs in action.
      

      

      I think pursuing r-components as part of this document would slow
      this one down a fair bit.
      

      

      Is there a way to leave enough of a hook in the syntax to pursue
      r-component as a separate document? (BTW... does "??" actually
      fly with URI syntax, or wouldn't the 2nd "?" be part of the
      q-component?).
      

    

    

    "Leaving [just] enough of a hook" is exactly what I want to do in
    this document. I think that means: (a) define the syntax for URNs
    including that of r-components, (b) explain the role of r-components
    in URN resolution, and (c) set up an IANA registry of r-component
    names and values.  Maybe also (d) explain how this is syntax
    compatible with 3986. I think that's about enough for 2141bis.

    

    (I'm thinking that I should suggest explicit text for this if for no
    other reason than that that exercise will give us a good idea of
    just how much would need to be added to 3986.)

    

    Separate from 2141bis, I'm thinking I might like to write up an
    Experimental or Informational document defining a simple URN
    resolution service and a client API for such a service. (perhaps
    cribbing a bit from RFC 2483).  This simple service would define a
    minimal set of simple requests and the parameters for such
    requests. The main purpose in doing so would be to serve as a
    proof-of-concept and to encourage further development in this area
    by the library community.

    

    And yes, the 2nd "?" would be part of the q-component if this were
    parsed according to 3986. Given a URN 

    

    urn:example:something??a=b;c=d?mumble

    

    a 3986-style parser would return 

    

    { 

     "scheme": "urn", 

     "path": "example:something", 

     "query": "??a=b;c=d?mumble" 

    }. 

    

    However, it doesn't violate 3986 syntax, because "?" is explicitly
    permitted within <query>. (See RFC 3986, section 3.4, top of
    page 24)

    

    My take on this is that an ordinary URL parser shouldn't cause
    catastrophic failure (like causing the program to crash) with
    something that conforms to 3986 syntax. Of course, most existing
    programs don't try to do URN resolution anyway, so their inability
    to parse URNs exactly like I'm proposing for 2141bis won't really do
    them much harm. By contrast, programs that support URN resolution
    in the future can parse them according to the 2141bis grammar, which
    would yield a result like:

    

    { 

     "scheme": "urn", 

     "namespace": "example", 

     "nss": "something", 

     "r-component": { "a": "b", "c": "d" }, 

     "q-component": "mumble" 

    }

    

    

  


--------------070200050606010607070101--


From nobody Fri Apr 17 17:24:44 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DFD1B311D for ; Fri, 17 Apr 2015 17:24:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXzfDtFmi5W5 for ; Fri, 17 Apr 2015 17:24:41 -0700 (PDT)
Received: from zoidberg.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E781B3119 for ; Fri, 17 Apr 2015 17:24:40 -0700 (PDT)
Received: from cashmere.int.lexiconix.com (pool-108-44-246-138.clppva.fios.verizon.net [108.44.246.138]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by zoidberg.ecotroph.net (Postfix) with ESMTP id 349D4A16CA; Fri, 17 Apr 2015 20:24:39 -0400 (EDT)
Message-ID: <5531A445.1020307@thinkingcat.com>
Date: Fri, 17 Apr 2015 20:24:37 -0400
From: "Leslie Daigle (ThinkingCat)" 
Organization: ThinkingCat Enterprises
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Keith Moore , urn@ietf.org
References: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com> <55312E53.2010605@thinkingcat.com> <553198FE.8020602@network-heretics.com>
In-Reply-To: <553198FE.8020602@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Apr 2015 00:24:43 -0000

Bear in mind that the text you are quoting was written before today's 
discussion.

I could take a half-step back from it on this side of the interim.

However, I think the likelihood of new namespace minters grokking this:

 > So for instance, if a namespace assigned names of the form a/b/c, it
 > wouldn't do for it to advertise URNs of the form *urn:namespace:a/b/c*
 > .   It would instead have to be *urn:namespace://a/b/c* .

is slim to none.

I (still) believe the document should be clear that using p-components 
requires thought and care.

Leslie.

On 4/17/15 7:36 PM, Keith Moore wrote:
> On 04/17/2015 12:01 PM, Leslie Daigle (ThinkingCat) wrote:
>> IMO, that can be achieved by being clear about what the NSS is, assert
>> that relative URNs are not expected/permitted, and attest that "/"
>> should not be used in a URN simply because one is importing a
>> namespace that happens to use them and it's a matter of syntactic
>> convenience not to escape them with %-encoding.
>
> If relative references are never evaluated with respect to URNs, but
> only with respect to URLs that contain paths, I don't think we need to
> constrain p-components of URNs to be paths, or to mandate any
> relationship between the p-components and the resources named (e.g.
> *urn:example://a/b* and *urn:example://a/c* need have no relationship to
> one another), or define what they mean at all.   The only constraints we
> need to impose on them are those dictated by the desire to be
> syntax-compatible with RFC 3986.   A namespace could use p-components
> however it wished, as long as the rules for comparison for the sake of
> determining equivalence weren't broken.
>
> So the only issue I would have with importing a namespace that happens
> to use "/" in the assigned portion of its names would be if the
> resulting syntax violated the 3986 grammar.
>
> So for instance, if a namespace assigned names of the form a/b/c, it
> wouldn't do for it to advertise URNs of the form *urn:namespace:a/b/c*
> .   It would instead have to be *urn:namespace://a/b/c* .
>
> Keith
>
>
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
ldaigle@thinkingcat.com
-------------------------------------------------------------------


From nobody Fri Apr 17 17:24:53 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4491B3122 for ; Fri, 17 Apr 2015 17:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VliCA3ZqpNNj for ; Fri, 17 Apr 2015 17:24:43 -0700 (PDT)
Received: from zoidberg.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4E21B3119 for ; Fri, 17 Apr 2015 17:24:43 -0700 (PDT)
Received: from cashmere.int.lexiconix.com (pool-108-44-246-138.clppva.fios.verizon.net [108.44.246.138]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by zoidberg.ecotroph.net (Postfix) with ESMTP id C8606A1FC5; Fri, 17 Apr 2015 20:24:41 -0400 (EDT)
Message-ID: <5531A449.9000300@thinkingcat.com>
Date: Fri, 17 Apr 2015 20:24:41 -0400
From: "Leslie Daigle (ThinkingCat)" 
Organization: ThinkingCat Enterprises
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Keith Moore , urn@ietf.org
References: <8AEAB125F8F87EC748B12990@JcK-HP8200.jck.com> <5531961F.4010207@network-heretics.com>
In-Reply-To: <5531961F.4010207@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] The persistence paragraph
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Apr 2015 00:24:45 -0000

This gets filed under "I want to see the whole document before I feel 
it's clear in my mind."

Leslie.

On 4/17/15 7:24 PM, Keith Moore wrote:
> On 04/17/2015 02:28 PM, John C Klensin wrote:
>> Hi.  There was some confusion on the phone about the proposed
>> persistence paragraph for 2141bis-12.  While it was posted to
>> the list, it embedded in a much longer note and discussion.
>> So, for everyone's convenience, here is is again:
>>
>>>     (i) Rename the present Section 4 to "Equivalence and
>>>     Persistence of URNs".
>>>
>>>     (ii) Add a new subsection 4.2, incrementing the number
>>>     for the current 4.2 to 4.3, titled "URN Persistence"
>>>     that reads:
>>>
>>>     For consistency with the "persistence" property
>>>     [RFC1737] and as a logical consequence of the
>>>     equivalence procedure described immediately above, only
>>>     the  (see Section 3 above) are
>>>     necessarily treated as persistent.  Individual
>>>     namespaces may, however, impose more stringent
>>>     requirements on the use of q-components or f-components.
>> The final sentence may or may not be needed -- that is one of
>> those relatively minor issues.  Someone, probably Keith, asked
>> for it and Leslie said in a note earlier today that it was worth
>> keeping, so anyone who disagrees should speak up.  Even more
>> important, anyone who thinks the whole paragraph is wrong or
>> doesn't solve the problem should speak up soon and vigorously.
>
> I don't recall asking for the final sentence.  If I did, I no longer
> think it's a good idea based on what seems to be the emerging consensus.
>
> Assuming relative references are to be evaluated with respect to a URL
> that is obtained during resolution or specified in the resource itself,
> I think that implies that the f-component and q-component are not within
> the purview of the namespace, except to the extent that a namespace can
> choose to not assign URNs to resources for which fragments and/or
> queries are meaningful.
>
> More generally, I think only the assigned-name portion of the URN is
> really under control of the namespace.
>
> Keith
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
ldaigle@thinkingcat.com
-------------------------------------------------------------------


From nobody Fri Apr 17 17:27:10 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AADFB1A008B for ; Fri, 17 Apr 2015 17:27:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDodVSxdv94b for ; Fri, 17 Apr 2015 17:27:07 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2981A0074 for ; Fri, 17 Apr 2015 17:27:07 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7C58820A13 for ; Fri, 17 Apr 2015 20:27:06 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Fri, 17 Apr 2015 20:27:06 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=pWbR9zAGRrbZQ6N9V0LEv+wjDN4=; b=nVYFh tp5abd/UsOyqN6FCMshOQUgolCip1DSP4H6P4v7ZuJotrulXP6oTaJ9g3WerCVGe ryvlOQo+odsImkGBQiRS+kBiyeBOWc/G3kJqfAg0Fyz5oSWKkafFgrDdq/jrACab KHoQxlOgy+l7oaDP05MFKMrUbXt2DNE0Eb/Xvw=
X-Sasl-enc: xAAYJiy3KPD2g6tVmMfjYWpoE9pTh2dZdDz2jbLmL5c8 1429316826
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 2934968019B; Fri, 17 Apr 2015 20:27:06 -0400 (EDT)
Message-ID: <5531A4C1.5010806@network-heretics.com>
Date: Fri, 17 Apr 2015 20:26:41 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com> <55312E53.2010605@thinkingcat.com> <553198FE.8020602@network-heretics.com> <5531A445.1020307@thinkingcat.com>
In-Reply-To: <5531A445.1020307@thinkingcat.com>
Content-Type: multipart/alternative; boundary="------------060609080200030900080708"
Archived-At: 
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Apr 2015 00:27:08 -0000

This is a multi-part message in MIME format.
--------------060609080200030900080708
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 04/17/2015 08:24 PM, Leslie Daigle (ThinkingCat) wrote:
>
> Bear in mind that the text you are quoting was written before today's 
> discussion.
>
> I could take a half-step back from it on this side of the interim.
>
> However, I think the likelihood of new namespace minters grokking this:
>
> > So for instance, if a namespace assigned names of the form a/b/c, it
> > wouldn't do for it to advertise URNs of the form *urn:namespace:a/b/c*
> > .   It would instead have to be *urn:namespace://a/b/c* .
>
> is slim to none.

Should 2141bis explicitly point that out?

> I (still) believe the document should be clear that using p-components 
> requires thought and care.

Other than conforming to syntax, what thought and care is required?

(I don't inherently disagree with you; I just don't immediately see what 
other concerns remain about p-components if they don't affect how 
relative references are evaluated.)

Keith


--------------060609080200030900080708
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 04/17/2015 08:24 PM, Leslie Daigle
      (ThinkingCat) wrote:

    

    


      Bear in mind that the text you are quoting was written before
      today's discussion.
      

      

      I could take a half-step back from it on this side of the interim.
      

      

      However, I think the likelihood of new namespace minters grokking
      this:
      

      

      > So for instance, if a namespace assigned names of the form
      a/b/c, it
      

      > wouldn't do for it to advertise URNs of the form *urn:namespace:a/b/c*
      

      > . It would instead have to be *urn:namespace://a/b/c* .
      

      

      is slim to none.
      

    

    

    Should 2141bis explicitly point that out?

    

    

      I (still) believe the document should be clear that using
      p-components requires thought and care.
      

    

    

    Other than conforming to syntax, what thought and care is required?

    

    (I don't inherently disagree with you; I just don't immediately see
    what other concerns remain about p-components if they don't affect
    how relative references are evaluated.)

    

    Keith

    

  


--------------060609080200030900080708--


From nobody Fri Apr 17 18:54:12 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8241A1ABC for ; Fri, 17 Apr 2015 18:54:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ribs0wkaVVvd for ; Fri, 17 Apr 2015 18:54:07 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F771A1ADB for ; Fri, 17 Apr 2015 18:54:07 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YjHxJ-0006FY-VC; Fri, 17 Apr 2015 21:54:01 -0400
Date: Fri, 17 Apr 2015 21:53:54 -0400
From: John C Klensin 
To: Keith Moore , urn@ietf.org
Message-ID: <2330DED70C04EF9694D3FFCC@JcK-HP8200.jck.com>
In-Reply-To: <5531961F.4010207@network-heretics.com>
References: <8AEAB125F8F87EC748B12990@JcK-HP8200.jck.com> <5531961F.4010207@network-heretics.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Subject: Re: [urn] The persistence paragraph
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Apr 2015 01:54:10 -0000

--On Friday, April 17, 2015 19:24 -0400 Keith Moore
 wrote:

> On 04/17/2015 02:28 PM, John C Klensin wrote:
>> Hi.  There was some confusion on the phone about the proposed
>> persistence paragraph for 2141bis-12.  While it was posted to
>> the list, it embedded in a much longer note and discussion.
>> So, for everyone's convenience, here is is again:
>> 
>>> 	(i) Rename the present Section 4 to "Equivalence and
>>> 	Persistence of URNs".
>>> 	
>>> 	(ii) Add a new subsection 4.2, incrementing the number
>>> 	for the current 4.2 to 4.3, titled "URN Persistence"
>>> 	that reads:
>>> 	
>>> 	For consistency with the "persistence" property
>>> 	[RFC1737] and as a logical consequence of the
>>> 	equivalence procedure described immediately above, only
>>> 	the  (see Section 3 above) are
>>> 	necessarily treated as persistent.  Individual
>>> 	namespaces may, however, impose more stringent
>>> 	requirements on the use of q-components or f-components.
>> The final sentence may or may not be needed -- that is one of
>> those relatively minor issues.  Someone, probably Keith, asked
>> for it and Leslie said in a note earlier today that it was
>> worth keeping, so anyone who disagrees should speak up.  Even
>> more important, anyone who thinks the whole paragraph is
>> wrong or doesn't solve the problem should speak up soon and
>> vigorously.
> 
> I don't recall asking for the final sentence.  If I did, I no
> longer think it's a good idea based on what seems to be the
> emerging consensus.

Ok.  We still have an open question about that, which I will
note.

> Assuming relative references are to be evaluated with respect
> to a URL that is obtained during resolution or specified in
> the resource itself,  I think that implies that the
> f-component and q-component are not within the purview of the
> namespace, except to the extent that a namespace can choose to
> not assign URNs to resources for which fragments and/or
> queries are meaningful.
> 
> More generally, I think only the assigned-name portion of the
> URN is really under control of the namespace.

Keith, I'm having trouble mapping "under control of the
namespace" to my view of the world.  With the assumption that
this is at least as likely to be misunderstanding as
disagreement, I think it is quite natural for a namespace
definition to say " this
namespace identifies, the following types of q-components are
natural to them, others are not and will be ignored (or
trashed)".  Equally so, I think it is meaningful for a namespace
definition to say "no q-components tolerated here" -- if it is
not, then I wonder what we mean when we say things like "if the
namespace definition does not explicitly permit q-components,
they are invalid".  

Now, "invalid" doesn't mean someone cannot type one.  As was
pointed out on the call, someone can type any sort of nonsense
one can imagine and the fact that it is valid syntax doesn't
mean it has a reasonable interpretation.  It is easy to
construct examples of that for HTTP UPLs -- nothing special
about the URN scheme, much less a namespace.

So, can you explain what "under control of the namespace" means?

thanks,
    john




From nobody Fri Apr 17 19:52:30 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3421A883A for ; Fri, 17 Apr 2015 19:52:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HruUYEbrmbnn for ; Fri, 17 Apr 2015 19:52:25 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031F01A87EF for ; Fri, 17 Apr 2015 19:52:24 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5F63C2091E for ; Fri, 17 Apr 2015 22:52:24 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 17 Apr 2015 22:52:24 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=l5/PjcNuXwOclGR9hzeO8GtC1iE=; b=o65/R DiDcq92lkD+u4JSAlx3Y2Y0+5ypAoEzobB5M2qvO/UuVUx8BUG5w6ctsgrqp6M3K mnoOjgiPm5L5cLCyZudK3rH7Kd4WN8N+i2DjIKbbt96msMOKrwSb3/4DGJIKXv5e 2Hz1gEkVIjRjf9WHzyba9pJq3IpSfiSCPIClQk=
X-Sasl-enc: mlfRsp3tAZvsPE4IP9C3AUuckmGmtC1VRcVH8rqVrbmd 1429325544
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id E1A40C00013; Fri, 17 Apr 2015 22:52:23 -0400 (EDT)
Message-ID: <5531C6CF.6040609@network-heretics.com>
Date: Fri, 17 Apr 2015 22:51:59 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <8AEAB125F8F87EC748B12990@JcK-HP8200.jck.com> <5531961F.4010207@network-heretics.com> <2330DED70C04EF9694D3FFCC@JcK-HP8200.jck.com>
In-Reply-To: <2330DED70C04EF9694D3FFCC@JcK-HP8200.jck.com>
Content-Type: multipart/alternative; boundary="------------020406030006060405080504"
Archived-At: 
Subject: Re: [urn] The persistence paragraph
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Apr 2015 02:52:29 -0000

This is a multi-part message in MIME format.
--------------020406030006060405080504
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 04/17/2015 09:53 PM, John C Klensin wrote:
>
> --On Friday, April 17, 2015 19:24 -0400 Keith Moore
>  wrote:
>
>> On 04/17/2015 02:28 PM, John C Klensin wrote:
>>> Hi.  There was some confusion on the phone about the proposed
>>> persistence paragraph for 2141bis-12.  While it was posted to
>>> the list, it embedded in a much longer note and discussion.
>>> So, for everyone's convenience, here is is again:
>>>
>>>> 	(i) Rename the present Section 4 to "Equivalence and
>>>> 	Persistence of URNs".
>>>> 	
>>>> 	(ii) Add a new subsection 4.2, incrementing the number
>>>> 	for the current 4.2 to 4.3, titled "URN Persistence"
>>>> 	that reads:
>>>> 	
>>>> 	For consistency with the "persistence" property
>>>> 	[RFC1737] and as a logical consequence of the
>>>> 	equivalence procedure described immediately above, only
>>>> 	the  (see Section 3 above) are
>>>> 	necessarily treated as persistent.  Individual
>>>> 	namespaces may, however, impose more stringent
>>>> 	requirements on the use of q-components or f-components.
>>> The final sentence may or may not be needed -- that is one of
>>> those relatively minor issues.  Someone, probably Keith, asked
>>> for it and Leslie said in a note earlier today that it was
>>> worth keeping, so anyone who disagrees should speak up.  Even
>>> more important, anyone who thinks the whole paragraph is
>>> wrong or doesn't solve the problem should speak up soon and
>>> vigorously.
>> I don't recall asking for the final sentence.  If I did, I no
>> longer think it's a good idea based on what seems to be the
>> emerging consensus.
> Ok.  We still have an open question about that, which I will
> note.
>
>> Assuming relative references are to be evaluated with respect
>> to a URL that is obtained during resolution or specified in
>> the resource itself,  I think that implies that the
>> f-component and q-component are not within the purview of the
>> namespace, except to the extent that a namespace can choose to
>> not assign URNs to resources for which fragments and/or
>> queries are meaningful.
>>
>> More generally, I think only the assigned-name portion of the
>> URN is really under control of the namespace.
> Keith, I'm having trouble mapping "under control of the
> namespace" to my view of the world.  With the assumption that
> this is at least as likely to be misunderstanding as
> disagreement, I think it is quite natural for a namespace
> definition to say " this
> namespace identifies, the following types of q-components are
> natural to them, others are not and will be ignored (or
> trashed)".  Equally so, I think it is meaningful for a namespace
> definition to say "no q-components tolerated here" -- if it is
> not, then I wonder what we mean when we say things like "if the
> namespace definition does not explicitly permit q-components,
> they are invalid".
>
> Now, "invalid" doesn't mean someone cannot type one.  As was
> pointed out on the call, someone can type any sort of nonsense
> one can imagine and the fact that it is valid syntax doesn't
> mean it has a reasonable interpretation.  It is easy to
> construct examples of that for HTTP UPLs -- nothing special
> about the URN scheme, much less a namespace.
>
> So, can you explain what "under control of the namespace" means?

Let me try to describe it in another way:

1. Handling of URNs should be, to the extent reasonable, independent of 
namespace.
2. So when a client of some kind encounters a URN of the form:
*urn:example:foo?bar*
the client's behavior should invariably be to find the resource named by 
*urn:example:foo* and try to transmit "bar" to it (if the protocol via 
which *urn:example:foo* is accessed permits that)
3. Similarly, when a client of some kind encounters a URN of the form:
*urn:example:foo#zot*
the client's behavior should invariably be to try to obtain the content 
named by *urn:example:foo*, and having done that, try to find the 
fragment within named zot (if the client understands the content-type of 
that content, the content-type supports fragments and there is a 
fragment named zot)

So given the above rules, whether namespace example "permits" 
q-components and/or f-components is kind of irrelevant.  In practice, IF 
the name resolves to a resource that accepts queries, the q-component 
will be used as a query, and IF the name resolves to a resource that has 
fragments, the f-component will be interpreted as a fragment name.

A namespace can of course choose what it assigns names to.  So a 
particular namespace could create a policy that says "we won't assign 
names to anything that accepts queries".   However, it's not clear that 
a particular namespace can actually say "we won't assign names to 
anything that contains fragments" and make that stick, because a number 
of fragment types have been defined in such a way that doesn't require 
the content to actually specify those fragments.   For instance, someone 
could standardize a convention that a fragment of the form 
/page-[0-9ivxlcdm]+/ refers to a numbered page in a book, and someone 
could implement software that interpreted such fragments with respect to 
PDF or any other format representing page-oriented content, and in 
practice referencing an ISBN containing an f-component matching that 
regular expression would cause that page to be displayed - even if the 
ISBN namespace refused to assign ISBNs to any resources with explicit 
fragment markers.

Now, we could write rules 2 and 3 above in slightly different ways, and 
get slightly different results.   For instance, we could say IF a URN 
resolves to a URL, then you interpret any q-component of that URN as a 
query to be passed to that URL, and any f-component of that URN as the 
name of a fragment to be attached to that URL.   So if *urn:example:foo* 
resolves to *http://example.com/xyzzy* then *urn:example:foo?bar#zot* is 
interpreted as *http://example.com/xyzzy?bar#zot* .   That keeps 
interpretation of q-components and f-components for resources that 
resolve to URLs consistent with the interpretation of queries and 
fragments for those URLs, and preserves the ability to specify queries 
and fragments with URNs that resolve to URLs.  But it doesn't say 
anything about how q-components and f-components are evaluated for 
resources that don't resolve to URLs.

But I think the latter rules (by themselves) are slightly problematic, 
for two reasons.  One is that it's conceivable that there are multiple 
ways to resolve a resource, some involving URLs and some not.   (e.g. 
you could ask the resolution service for a URL, or you could ask it for 
the resource content directly). Ideally you shouldn't get inconsistent 
behavior with the same content depending on how the URN is resolved.   
The other reason is that the way a resource is resolved could reasonably 
change over time.   So one day it might only be available as physical 
media, and at some later time it might have been scanned and be 
accessible over the Internet.   Ok, maybe this isn't actually a problem, 
except for a namespace that doesn't want to permit fragments to be used 
with its URNs.

It might be important here to emphasize that as a matter of the URN 
architecture, resolution isn't under control of the namespace. The 
namespace can supply a resolution service if it wishes to do so, and it 
might well be a good one.   But we expect resolution services to evolve 
over time for various reasons, and we expect that multiple parties might 
wish to provide resolution services also for various reasons, and 
central points-of-control are quite reasonably regarded as threats to 
information dissemination.   So URNs were designed to not be dependent 
on any particular resolution service.    A client might reasonably query 
several different resolution services in order to try to find 
information about a resource or how to access it.

Keith



--------------020406030006060405080504
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 04/17/2015 09:53 PM, John C Klensin
      wrote:

    

    

      

--On Friday, April 17, 2015 19:24 -0400 Keith Moore
<moore@network-heretics.com> wrote:



      

        
On 04/17/2015 02:28 PM, John C Klensin wrote:


        

          
Hi.  There was some confusion on the phone about the proposed
persistence paragraph for 2141bis-12.  While it was posted to
the list, it embedded in a much longer note and discussion.
So, for everyone's convenience, here is is again:



          

            
	(i) Rename the present Section 4 to "Equivalence and
	Persistence of URNs".
	
	(ii) Add a new subsection 4.2, incrementing the number
	for the current 4.2 to 4.3, titled "URN Persistence"
	that reads:
	
	For consistency with the "persistence" property
	[RFC1737] and as a logical consequence of the
	equivalence procedure described immediately above, only
	the <assigned-name> (see Section 3 above) are
	necessarily treated as persistent.  Individual
	namespaces may, however, impose more stringent
	requirements on the use of q-components or f-components.


          

          
The final sentence may or may not be needed -- that is one of
those relatively minor issues.  Someone, probably Keith, asked
for it and Leslie said in a note earlier today that it was
worth keeping, so anyone who disagrees should speak up.  Even
more important, anyone who thinks the whole paragraph is
wrong or doesn't solve the problem should speak up soon and
vigorously.


        

        
I don't recall asking for the final sentence.  If I did, I no
longer think it's a good idea based on what seems to be the
emerging consensus.


      

      
Ok.  We still have an open question about that, which I will
note.



      

        
Assuming relative references are to be evaluated with respect
to a URL that is obtained during resolution or specified in
the resource itself,  I think that implies that the
f-component and q-component are not within the purview of the
namespace, except to the extent that a namespace can choose to
not assign URNs to resources for which fragments and/or
queries are meaningful.

More generally, I think only the assigned-name portion of the
URN is really under control of the namespace.


      

      
Keith, I'm having trouble mapping "under control of the
namespace" to my view of the world.  With the assumption that
this is at least as likely to be misunderstanding as
disagreement, I think it is quite natural for a namespace
definition to say "<whatever-things-or-abstractions> this
namespace identifies, the following types of q-components are
natural to them, others are not and will be ignored (or
trashed)".  Equally so, I think it is meaningful for a namespace
definition to say "no q-components tolerated here" -- if it is
not, then I wonder what we mean when we say things like "if the
namespace definition does not explicitly permit q-components,
they are invalid".  

Now, "invalid" doesn't mean someone cannot type one.  As was
pointed out on the call, someone can type any sort of nonsense
one can imagine and the fact that it is valid syntax doesn't
mean it has a reasonable interpretation.  It is easy to
construct examples of that for HTTP UPLs -- nothing special
about the URN scheme, much less a namespace.

So, can you explain what "under control of the namespace" means?


    

    

    Let me try to describe it in another way:

    

    1. Handling of URNs should be, to the extent reasonable, independent
    of namespace.

    2. So when a client of some kind encounters a URN of the form: 

    urn:example:foo?bar

    the client's behavior should invariably be to find the resource
    named by urn:example:foo
    and try to transmit "bar" to it (if the protocol via which urn:example:foo
    is accessed permits that)

    3. Similarly, when a client of some kind encounters a URN of the
    form:

    urn:example:foo#zot

    the client's behavior should invariably be to try to obtain the
    content named by urn:example:foo,
    and having done that, try to find the fragment within named zot (if
    the client understands the content-type of that content, the
    content-type supports fragments and there is a fragment named zot)

    

    So given the above rules, whether namespace example "permits"
    q-components and/or f-components is kind of irrelevant. In
    practice, IF the name resolves to a resource that accepts queries,
    the q-component will be used as a query, and IF the name resolves to
    a resource that has fragments, the f-component will be interpreted
    as a fragment name.

    

    A namespace can of course choose what it assigns names to. So a
    particular namespace could create a policy that says "we won't
    assign names to anything that accepts queries". However, it's not
    clear that a particular namespace can actually say "we won't assign
    names to anything that contains fragments" and make that stick,
    because a number of fragment types have been defined in such a way
    that doesn't require the content to actually specify those
    fragments. For instance, someone could standardize a convention
    that a fragment of the form /page-[0-9ivxlcdm]+/ refers to a
    numbered page in a book, and someone could implement software that
    interpreted such fragments with respect to PDF or any other format
    representing page-oriented content, and in practice referencing an
    ISBN containing an f-component matching that regular expression
    would cause that page to be displayed - even if the ISBN namespace
    refused to assign ISBNs to any resources with explicit fragment
    markers.

    

    Now, we could write rules 2 and 3 above in slightly different ways,
    and get slightly different results. For instance, we could say IF
    a URN resolves to a URL, then you interpret any q-component of that
    URN as a query to be passed to that URL, and any f-component of that
    URN as the name of a fragment to be attached to that URL. So if urn:example:foo
    resolves to http://example.com/xyzzy
    then urn:example:foo?bar#zot
    is interpreted as http://example.com/xyzzy?bar#zot
    . That keeps interpretation of q-components and f-components for
    resources that resolve to URLs consistent with the interpretation of
    queries and fragments for those URLs, and preserves the ability to
    specify queries and fragments with URNs that resolve to URLs. But
    it doesn't say anything about how q-components and f-components are
    evaluated for resources that don't resolve to URLs. 

    

    But I think the latter rules (by themselves) are slightly
    problematic, for two reasons. One is that it's conceivable that
    there are multiple ways to resolve a resource, some involving URLs
    and some not. (e.g. you could ask the resolution service for a
    URL, or you could ask it for the resource content directly).
    Ideally you shouldn't get inconsistent behavior with the same
    content depending on how the URN is resolved. The other reason is
    that the way a resource is resolved could reasonably change over
    time. So one day it might only be available as physical media, and
    at some later time it might have been scanned and be accessible over
    the Internet. Ok, maybe this isn't actually a problem, except for
    a namespace that doesn't want to permit fragments to be used with
    its URNs. 

    

    It might be important here to emphasize that as a matter of the URN
    architecture, resolution isn't under control of the namespace.
    The namespace can supply a resolution service if it wishes to do so,
    and it might well be a good one. But we expect resolution services
    to evolve over time for various reasons, and we expect that multiple
    parties might wish to provide resolution services also for various
    reasons, and central points-of-control are quite reasonably regarded
    as threats to information dissemination. So URNs were designed to
    not be dependent on any particular resolution service. A client
    might reasonably query several different resolution services in
    order to try to find information about a resource or how to access
    it.

    

    Keith

    

    

  


--------------020406030006060405080504--


From nobody Fri Apr 17 19:59:10 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C39A1A8843 for ; Fri, 17 Apr 2015 19:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIMrIfcnNYtF for ; Fri, 17 Apr 2015 19:59:08 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109421A8840 for ; Fri, 17 Apr 2015 19:59:08 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YjIyF-00078o-1F; Fri, 17 Apr 2015 22:59:03 -0400
Date: Fri, 17 Apr 2015 22:58:55 -0400
From: John C Klensin 
To: Keith Moore , urn@ietf.org
Message-ID: 
In-Reply-To: <55319FD5.1070404@network-heretics.com>
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com> <552F15AD.2050405@andyet.net> <552F6234.4080509@network-heretics.com> <55317AA4.70105@thinkingcat.com> <55319FD5.1070404@network-heretics.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Apr 2015 02:59:09 -0000

--On Friday, April 17, 2015 20:05 -0400 Keith Moore
 wrote:

> *urn:example:something??a=b;c=d?mumble*
> 
> a 3986-style parser would return
> 
> {
>     "scheme": "urn",
>     "path": "example:something",
>     "query": "??a=b;c=d?mumble"
> }.

Actually, 

	{
	    "scheme": "urn",
	    "path": "example:something",
	    "query": "?a=b;c=d?mumble"
	}
	
because 3986 says

   absolute-URI  = scheme ":" hier-part [ "?" query ]

and not, e.g.,

   absolute-URI  = scheme ":" hier-part [ query ]
   query = "?" query-component

Right?

>...
> By contrast, programs that support URN resolution in the
> future can parse them according to the 2141bis grammar, which
> would yield a result like:
> 
> {
>     "scheme": "urn",
>     "namespace": "example",
>     "nss": "something",
>     "r-component": { "a": "b", "c": "d" },
>     "q-component": "mumble"
> }

Yes, AFAICT.

    john


From nobody Fri Apr 17 20:07:29 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBA01A8883 for ; Fri, 17 Apr 2015 20:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bcj_UeHaA3d7 for ; Fri, 17 Apr 2015 20:07:26 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA4C1A8891 for ; Fri, 17 Apr 2015 20:07:26 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 18A06207A7 for ; Fri, 17 Apr 2015 23:07:26 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 17 Apr 2015 23:07:26 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=B0PPQRF4d1vHYR4 OO+QjOmM4cHc=; b=LL8vkBJ1QAyyKQIxTb41TUlNQJn1rgG9dmRMUgxA7DOntdw mnCURPzgZ799DF2LMzrR1h6XufGE0ypa0HNMZm4nJGYyWcvsRbI2TyDJ1omvFJA/ BY4aM3f79UNya/Pyx1NcgGgxGqnSQ79x5b7iABJttaP3Tz+dZ/T9onJDPuL0=
X-Sasl-enc: pbCmYNfME6iv5jiUdtt4e9WOCZU8UAM9Rm21eCTf9ewS 1429326445
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id A082B6800D8; Fri, 17 Apr 2015 23:07:25 -0400 (EDT)
Message-ID: <5531CA54.5050304@network-heretics.com>
Date: Fri, 17 Apr 2015 23:07:00 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: John C Klensin , urn@ietf.org
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com> <552F15AD.2050405@andyet.net> <552F6234.4080509@network-heretics.com> <55317AA4.70105@thinkingcat.com> <55319FD5.1070404@network-heretics.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Apr 2015 03:07:27 -0000

On 04/17/2015 10:58 PM, John C Klensin wrote:
>
> --On Friday, April 17, 2015 20:05 -0400 Keith Moore
>  wrote:
>
>> *urn:example:something??a=b;c=d?mumble*
>>
>> a 3986-style parser would return
>>
>> {
>>      "scheme": "urn",
>>      "path": "example:something",
>>      "query": "??a=b;c=d?mumble"
>> }.
> Actually,
>
> 	{
> 	    "scheme": "urn",
> 	    "path": "example:something",
> 	    "query": "?a=b;c=d?mumble"
> 	}
> 	
> because 3986 says
>
>     absolute-URI  = scheme ":" hier-part [ "?" query ]
>
> and not, e.g.,
>
>     absolute-URI  = scheme ":" hier-part [ query ]
>     query = "?" query-component
>
> Right?

Correct.   I realized that after I sent the message.

Keith


From nobody Mon Apr 20 03:23:21 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840391B29EC for ; Mon, 20 Apr 2015 03:23:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Level: 
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXkq81CNhoW9 for ; Mon, 20 Apr 2015 03:23:18 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0741B29E7 for ; Mon, 20 Apr 2015 03:23:16 -0700 (PDT)
Received: from AM3PR07MB369.eurprd07.prod.outlook.com (10.242.109.143) by AM3PR07MB369.eurprd07.prod.outlook.com (10.242.109.143) with Microsoft SMTP Server (TLS) id 15.1.136.25; Mon, 20 Apr 2015 10:00:12 +0000
Received: from AM3PR07MB369.eurprd07.prod.outlook.com ([10.242.109.143]) by AM3PR07MB369.eurprd07.prod.outlook.com ([10.242.109.143]) with mapi id 15.01.0136.026; Mon, 20 Apr 2015 10:00:12 +0000
From: "Hakala, Juha E" 
To: "urn@ietf.org" 
Thread-Topic: About fragments and queries
Thread-Index: AdB7UKuKsEOaVS0/ShONuT24Ypn+Ug==
Date: Mon, 20 Apr 2015 10:00:12 +0000
Message-ID: 
Accept-Language: fi-FI, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-originating-ip: [128.214.71.180]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB369;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(252514010)(2900100001)(122556002)(46102003)(19580405001)(74316001)(54356999)(33656002)(50986999)(87936001)(2351001)(107886001)(92566002)(110136001)(19580395003)(66066001)(229853001)(450100001)(2656002)(40100003)(77156002)(76576001)(77096005)(102836002)(74482002)(2501003)(62966003)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB369; H:AM3PR07MB369.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:AM3PR07MB369; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB369; 
x-forefront-prvs: 05529C6FDB
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: helsinki.fi
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2015 10:00:12.2825 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB369
Archived-At: 
Subject: [urn] About fragments and queries
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Apr 2015 10:23:20 -0000

Hello Keith,=20

Some comments to your clarification:=20

1. Handling of URNs should be, to the extent reasonable, independent of nam=
espace.

JH: + 1.=20

2. So when a client of some kind encounters a URN of the form:=20
urn:example:foo?bar
the client's behavior should invariably be to find the resource named by ur=
n:example:foo and try to transmit "bar" to it (if the protocol via which ur=
n:example:foo is accessed permits that)

JH: There are resolution services which do not require that the identified =
resource itself is found. For instance, if, ?bar is a request to retrieve d=
escriptive metadata about the resource, URN resolver does not need to locat=
e the resource itself, but it must know how an appropriate metadata record =
(records) can be retrieved.=20

3. Similarly, when a client of some kind encounters a URN of the form:
urn:example:foo#zot
the client's behavior should invariably be to try to obtain the content nam=
ed by urn:example:foo, and having done that, try to find the fragment withi=
n named zot (if the client understands the content-type of that content, th=
e content-type supports fragments and there is a fragment named zot)

JH: + 1. Fragment in the URN resolution is a priori the same as it is in UR=
L resolution.

So given the above rules, whether namespace example "permits" q-components =
and/or f-components is kind of irrelevant.  In practice, IF the name resolv=
es to a resource that accepts queries, the q-component will be used as a qu=
ery, and IF the name resolves to a resource that has fragments, the f-compo=
nent will be interpreted as a fragment name.

JH:  For me, the question is not whether the resource itself accepts querie=
s, but whether the applications with which the resource is managed do accep=
t them.  Many of them will, and the set of services supported will grow whe=
n digital asset management systems get smarter.=20

Juha
--

Juha Hakala

 Senior advisor
=A0The National Library of Finland
 Library Network Services=20
=A0P.O.Box 26 (Teollisuuskatu 23)
 FIN-00014 Helsinki University

 Gsm: +358 50 3827678
 email: juha.hakala@helsinki.fi=20



From nobody Mon Apr 20 03:51:21 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE901B2A3C for ; Mon, 20 Apr 2015 03:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ES_SsU-p44lf for ; Mon, 20 Apr 2015 03:51:18 -0700 (PDT)
Received: from APAC01-SG1-obe.outbound.protection.outlook.com (mail-sg1on0141.outbound.protection.outlook.com [134.170.132.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C889A1B2A30 for ; Mon, 20 Apr 2015 03:51:17 -0700 (PDT)
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;
Received: from [133.2.210.64] (133.2.210.64) by OS2PR01MB0140.jpnprd01.prod.outlook.com (0.161.77.148) with Microsoft SMTP Server (TLS) id 15.1.136.25; Mon, 20 Apr 2015 10:51:14 +0000
Message-ID: <5534DA1E.4020707@it.aoyama.ac.jp>
Date: Mon, 20 Apr 2015 19:51:10 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Hakala, Juha E" , "urn@ietf.org" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [133.2.210.64]
X-ClientProxiedBy: TY1PR01CA0033.jpnprd01.prod.outlook.com (25.164.162.143) To OS2PR01MB0140.jpnprd01.prod.outlook.com (25.161.77.148)
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR01MB0140;
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6049001)(6009001)(479174004)(24454002)(51704005)(87976001)(65806001)(65956001)(66066001)(19580395003)(23676002)(59896002)(15975445007)(83506001)(64126003)(62966003)(80316001)(85202003)(77156002)(47776003)(122386002)(4001350100001)(92566002)(15974865002)(33656002)(74482002)(76176999)(50466002)(2950100001)(46102003)(107886001)(42186005)(85182001)(65816999)(2501003)(54356999)(40100003)(86362001)(5001770100001)(87266999)(50986999)(3940600001)(16940595002); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0140; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5002010)(5005006);  SRVR:OS2PR01MB0140; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0140; 
X-Forefront-PRVS: 05529C6FDB
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2015 10:51:14.6635 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0140
Archived-At: 
Subject: Re: [urn] About fragments and queries
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Apr 2015 10:51:21 -0000

Hello Juha, others,

I'm taking this mail (which started a separate thread) to start to 
contribute again to the discussion.

On 2015/04/20 19:00, Hakala, Juha E wrote:
> Hello Keith,
>
> Some comments to your clarification:
>
> 1. Handling of URNs should be, to the extent reasonable, independent of namespace.
>
> JH: + 1.

Agreed here, too.

> 2. So when a client of some kind encounters a URN of the form:
> urn:example:foo?bar
> the client's behavior should invariably be to find the resource named by urn:example:foo and try to transmit "bar" to it (if the protocol via which urn:example:foo is accessed permits that)
>
> JH: There are resolution services which do not require that the identified resource itself is found. For instance, if, ?bar is a request to retrieve descriptive metadata about the resource, URN resolver does not need to locate the resource itself, but it must know how an appropriate metadata record (records) can be retrieved.

I'd tend to side with Juha here. I'd note that the prototypical 
resolution service (not for URNs, but for everything else), namely HTTP, 
does NOT find the resource before the "?" and send it the query part 
after the "?".

E.g. for http://www.google.com/search?as_sitesearch=ietf.org&q=urn, it
does NOT find the resource named "http://www.google.com/search" and try 
to transmit "as_sitesearch=ietf.org&q=urn" to it, but it finds 
"www.google.com" and sends "/search?as_sitesearch=ietf.org&q=urn" to it.

[For the purpose of this example, we can ignore the fact that we get 
redirected from http to https, and in my case from www.google.com to 
www.google.co.jp.]

And for proxies, the whole URI is sent in one go. And the URI spec 
definitely does not prescribe any specific way to do this, but leaves it 
to schemes, and even if a scheme specifies something very clearly, 
resolution infrastructure between the user and the data may still do 
something different. Also, because for URNs, resolution services are an 
open-ended business, I don't think it would be a good idea to be that 
specific.

> 3. Similarly, when a client of some kind encounters a URN of the form:
> urn:example:foo#zot
> the client's behavior should invariably be to try to obtain the content named by urn:example:foo, and having done that, try to find the fragment within named zot (if the client understands the content-type of that content, the content-type supports fragments and there is a fragment named zot)
>
> JH: + 1. Fragment in the URN resolution is a priori the same as it is in URL resolution.

Agreement, of course.

> So given the above rules, whether namespace example "permits" q-components and/or f-components is kind of irrelevant.  In practice, IF the name resolves to a resource that accepts queries, the q-component will be used as a query, and IF the name resolves to a resource that has fragments, the f-component will be interpreted as a fragment name.
>
> JH:  For me, the question is not whether the resource itself accepts queries, but whether the applications with which the resource is managed do accept them.  Many of them will, and the set of services supported will grow when digital asset management systems get smarter.

I'd reply somewhat differently here than Juha, but I'd guess the result 
would be the same regarding the spec.

Regards,   Martin.


From nobody Mon Apr 20 06:12:56 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFC51B2B30 for ; Mon, 20 Apr 2015 06:12:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.599
X-Spam-Level: 
X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JNojorplHp9 for ; Mon, 20 Apr 2015 06:12:45 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::740]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4403B1B2B2E for ; Mon, 20 Apr 2015 06:12:42 -0700 (PDT)
Received: from AM3PR07MB369.eurprd07.prod.outlook.com (10.242.109.143) by AM3PR07MB372.eurprd07.prod.outlook.com (10.242.109.152) with Microsoft SMTP Server (TLS) id 15.1.136.25; Mon, 20 Apr 2015 12:38:41 +0000
Received: from AM3PR07MB369.eurprd07.prod.outlook.com ([10.242.109.143]) by AM3PR07MB369.eurprd07.prod.outlook.com ([10.242.109.143]) with mapi id 15.01.0136.026; Mon, 20 Apr 2015 12:38:42 +0000
From: "Hakala, Juha E" 
To: Keith Moore , "urn@ietf.org" 
Thread-Topic: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
Thread-Index: AQHQbkdq6P5r65B0EEyEivJbQdoLhp079F4AgBMGjACAALt4gIAA+TTwgACYwQCABJaCwA==
Date: Mon, 20 Apr 2015 12:38:41 +0000
Message-ID: 
References: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com> <551F266E.4000507@network-heretics.com> <552F1C24.6040006@andyet.net> <552FB967.9080606@network-heretics.com>  <55310A96.8080900@network-heretics.com>
In-Reply-To: <55310A96.8080900@network-heretics.com>
Accept-Language: fi-FI, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: network-heretics.com; dkim=none (message not signed) header.d=none;
x-originating-ip: [128.214.71.180]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB372;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(279900001)(24454002)(51414003)(501614002)(479174004)(377454003)(19625305001)(77156002)(15975445007)(19625215002)(76176999)(54356999)(93886004)(5001770100001)(50986999)(106116001)(16236675004)(107886001)(19580405001)(19580395003)(2501003)(87936001)(66066001)(46102003)(62966003)(33656002)(102836002)(77096005)(74482002)(19300405004)(92566002)(2900100001)(19617315012)(74316001)(2950100001)(40100003)(122556002)(2656002)(86362001)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB372; H:AM3PR07MB369.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:AM3PR07MB372; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB372; 
x-forefront-prvs: 05529C6FDB
Content-Type: multipart/alternative; boundary="_000_AM3PR07MB369DADD3C8619C80B08FCE6FAE00AM3PR07MB369eurprd_"
MIME-Version: 1.0
X-OriginatorOrg: helsinki.fi
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2015 12:38:41.9196 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB372
Archived-At: 
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Apr 2015 13:12:54 -0000

--_000_AM3PR07MB369DADD3C8619C80B08FCE6FAE00AM3PR07MB369eurprd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello Keith,

Libraries etc. are already creating all sorts of links, for instance betwee=
n metadata records describing different manifestations of resources (like p=
rinted and electronic versions of books) and resources and their component =
parts (like CD and tracks in it). A problem with this is that the identifie=
rs used for this may not be globally unique. If database internal IDs have =
been used for linking, their usefulness may be limited when the bibliograph=
ic data is shared in the Web. Moving from present situation to something th=
at is palatable in Semantic Web may be non-trivial. The sooner we use persi=
stent identifiers in all resource linking, the better.

Dynamic resources (ones which change all the time) are an interesting  chal=
lenge. Traditional identifiers do not cope with them too well; granularity =
is an issue. For instance, ISSN can only be used to identify all versions o=
f an entire web site. And ISBN community would soon run out of numbers if t=
here were a lot of versions of each book. However, new identifier systems s=
uch as Handle/DOI and URN:NBN and some other URN namespaces allow - in theo=
ry - any level of granularity. In order to identify all versions of a Web p=
age one can use e.g. National Bibliography Numbers based on MD5 or some oth=
er check sum. The identifier assignment processes must of course be fully a=
utomated; for instance the National Library of Finland has minted tens of m=
illions of URN:NBNs to page images of digitized manuscripts, monographs, jo=
urnals, newspapers etc.  There are also identifiers for OCR-converted texts=
 - and images within them - to enable so called deep linking.

Regarding resolution and q-components: once we have updated RFC2141 and - I=
 hope - agreed that q-component is allowed, the aim is to update RFC 2483. =
The new version of that RFC will  specify a mechanism with which the URN us=
ers can register new URN resolution services and service parameters. Parame=
ter usage is important for e.g. services like URI to URC, since there are m=
any different things a user may ask for: basic bibliographic description of=
 a resource, its rights related information (what am I entitled to do with =
this resource), technical metadata (what application can be used to render =
this resource) or preservation metadata (how does the look and feel of this=
 migrated version of the resource differ from previous versions).

There are definitely cases when URL + query can  be replaced by more persis=
tent URN + query. Instead of making deep (and short-lived) links like this

http://z3950.loc.gov:7090/voyager?version=3D1.1&operation=3DsearchRetrieve&=
query=3D[ISBN]

it would be better to let the URN resolver to map URN:ISBN + query for reso=
urce metadata into a URI-based database search. When search protocols and d=
atabase applications change, URN resolution table of the appropriate URN re=
solver can be modified so that the URN is mapped to the current search synt=
ax.

Depending on the namespace, for instance URI to URC service may or may not =
be supported, and even if it is, different metadata formats may be relevant=
. Library systems will be able to supply MARC 21, archival information syst=
ems will support EAD, museum systems LIDO, and all of these systems may be =
able to deliver Dublin Core records as common denominator. This will requir=
e shared (between clients and URN resolvers) understanding on URN query syn=
tax, and "smart" URN resolvers which know how to deal with these resolution=
 requests. Network protocols themselves should not be affected by this.

Namespaces I am familiar will not be able to accommodate p-component. There=
 may be other namespaces which will find it useful.

I don't know how relative references could be used in productive manner in =
this context.

Juha


From: Keith Moore [mailto:moore@network-heretics.com]
Sent: 17. huhtikuuta 2015 16:29
To: Hakala, Juha E; urn@ietf.org
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relat=
ive references)

Juha,

This all sounds marvelous and I look forward to the day when this is in pla=
ce.

My main questions are with how this system of identifiers and relationships=
 interfaces to the world of network-accessible resources, which may be inte=
ractive and/or have their own rich set of internal links to one another.

Also, I'm primarily a network protocols person.   So whenever I look at som=
ething like this I ask myself how it will be implemented in network protoco=
ls, and whether those protocols will be organized in such a way as facilita=
te the use of those identifiers and relationships, or hinder such use.   On=
e way that the network protocols can hinder such use is by not permitting U=
RNs to be handled in a uniform way.   So if every different URN namespace h=
as different rules for how software needs to request resolution (like which=
 components to include), or if q-component works differently for different =
URN namespaces, or relative references work differently for different URN n=
amespaces, any of those things could hinder use.

Since there are already numerous resources that are referred to using URLs =
and which accept queries, I would like it to be possible to name those reso=
urces (or at least some of those resources) with URNs without losing the ab=
ility to send queries to those resources.   So given the large amount of mi=
ndshare around using ? to introduce queries to those resources, to me it ma=
kes more sense to use URN q-component for that purpose also, and to define =
a different component to enable requests for things like metadata.

Also, I don't like RFC 3986's treatment of URNs at all.  But perhaps unfort=
unately, there's a large amount of mindshare around using not only 3986 syn=
tax for URNs but also its rules for relative references with URNs.   And pa=
rt of what that means to me is that if we use 3986 syntax for URN component=
s that weren't permitted in 2141, it's going to be difficult for URNs to av=
oid being hampered by 3986's rules for relative references and by the expec=
tations in the web world for what those components mean.

So I think URNBIS needs to strong and technically sound statement about how=
 to resolve the conflict between the needs of URNs, and this large amount o=
f mindshare.  And URNBIS needs to do so in a way that both preserves the ab=
ility of the library community to further its goals, and also preserves the=
 ability of network-accessible resources to accept queries, have relative r=
eferences, allow identified subsets of the results to be referenced, and so=
 forth.   To my understanding, figuring out how to resolve this conflict is=
 the primary problem that is currently before us.

Keith

On 04/17/2015 02:10 AM, Hakala, Juha E wrote:
Hello,

Library community has well established practices for how to use identifiers=
. URNBIS could use these practices as the starting point, extend them if ne=
eded and alter them only when there is a good reason to do so. As a result =
URNBIS should have a more unified understanding of what kind of functionali=
ty needs to be supported now, and what can be postponed for the time being.

There are already international standard identifiers for:


-          Works, which are immaterial entities (such as The Tragicall Hist=
orie of Hamlet, Prince of Denmarke)


-          Expressions, which are translations and other versions of these =
works (such as a Finnish translation of Hamlet or a cartoon version of the =
original English text)


-          Manifestations, which are physical embodiments of works & expres=
sions. Physical may mean hand-held (printed) or electronic (PDF, EPUB3, etc=
.).


-          Public identities, which are not the same as persons;  George Or=
well is a public identity but the person behind it was Eric Blair. Public i=
dentity can also belong to a legal entity (Rolling Stones or IETF) or a fig=
ment of author's imagination (such as Winnie the Pooh).

Item (or copy) identifiers are work in progress. ISO TC 46/SC 9 is currentl=
y developing International Standard Item Identifier, with which it will be =
possible to identify particular items, such as the copy of Diophantus' Arit=
hmetica containing some interesting comments by Pierre de Fermat.

The underlying data model which binds all these bibliographic and other ent=
ities together is FRBR (http://en.wikipedia.org/wiki/Functional_Requirement=
s_for_Bibliographic_Records). While it is important that we can identify th=
ings uniquely and persistently, the real aim is more ambitious: to create l=
inked data. Libraries will - via collective effort, and in cooperation with=
 museums and archives - interconnect related works such as the original Ham=
let and Laurence Olivier's 1948 movie (or to be more precise, metadata reco=
rds describing these works in our catalogues), works and their expressions,=
 works / expressions and their manifestations, and manifestations and their=
 items.

This kind of functionality is not widely available in library systems yet, =
but there are some systems which provide already a glimpse of what the futu=
re will look like. OCLC's WorldCat is my favourite; see for instance the se=
arch results for Gone with the wind:

http://www.worldcat.org/search?q=3Dgone+with+the+wind%2C+by+margaret+mitche=
ll&qt=3Dowc_search

In order to provide a solid basis for decentralized creation of linked data=
 we need persistent identifiers from works to items (and metadata formats w=
hich enable us to specify the different roles these identifiers will have; =
in a work metadata record manifestation identifier acts as a link and vice =
versa). URN qualifiers will not be needed for identification, but it is nec=
essary to use q-component for e.g. enabling the users to request metadata f=
or a work with the q-component. They will then be able to see that there ar=
e related works and expressions (and take a closer look at them).  F-compon=
ent will not be relevant for us, but users will be able to cite documents w=
ith them and manifestation identifiers. I can't see any need for the p-comp=
onent for the time being.

Rich data models such as FRBR are a must in digital archives, since eventua=
lly they will contain several manifestations of most archived digital resou=
rces, if migration is the preferred preservation method. A user may initial=
ly find an outdated version of a document; in such situation it is importan=
t to find out that there are more modern versions available (and also that =
these versions will not have exactly the same look and feel than the origin=
al).

The scope of the URN system as a whole cannot be defined meaningfully since=
 each new namespace (and changes in identifier systems which already have a=
 namespace) alters the situation. At the moment URN does not specifically t=
arget e.g. public identities, but if a namespace is registered for Internat=
ional Standard Name Identifier, the problem is solved. As far as I am conce=
rned, URNs can be used to identify resources (whatever they are), just like=
 DOI is already being used to identify all sorts of objects (in DOI, it is =
the identifier itself which is digital, the identified object does not need=
 to be).

Juha


From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Keith Moore
Sent: 16. huhtikuuta 2015 16:30
To: urn@ietf.org
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relat=
ive references)

On 04/15/2015 10:19 PM, Peter Saint-Andre - &yet wrote:
I would prefer it if we can agree on some limitations on namespaces that
use '/' in NSSs that will render path-relative references either useful
or "mostly harmless" (depending on the particular discipline chose by
that namespace).   As I stated above, I think we're going to want to be
able to use URNs to refer to resources that contain path-relative
references without breaking those references.   We should certainly be
able to use URNs to name HTML documents, for instance.

Keith, would you mind clarifying that last sentence?

Here's why I ask. To my mind, we should certainly be able to use URNs to na=
me documents (if by document we mean a created work, not any particular cop=
y of that created work). Such a work might be an electronic document that c=
ould be constructed using any of a number of particular technologies: SGML,=
 XML, HTML, EPUB, MS Word, PDF, markdown, TeX, LaTeX, you name it. Although=
 I agree that we should certainly be able to use URNs to name electronic do=
cuments, I don't see why HTML is special here (I'm not saying you think it'=
s special, BTW). Would you also agree that we should certainly be able to u=
se URNs to name PDF documents or MS Word documents or EPUB documents?

I absolutely agree that we should be able to use URNs to name any of the ab=
ove kinds of resources.   The reason I cited HTML as an example above is be=
cause (a) it's presumably familiar to most list readers, and (b) HTML is a =
kind of resource that potentially uses path-relative references.

For example, if there are one or more URNs that refer to a document that co=
ntains a link to "../../foo", the behavior of that link when the document i=
s accessed via any of those URNs should be reasonable, well-defined, and na=
mespace-independent.  Ideally, the defined behavior of that link should be =
consistent with the behavior when the same document is referred to by a URL=
 that contains a path.

(Though I realize that such links can behave inconsistently even with multi=
ple URLs point to such a document   So I suppose the most that can be asked=
 is that it be possible for path-relative links in documents to be able to =
work as well when referred to by URNs as they can work when referred to by =
URLs.)

Keith


--_000_AM3PR07MB369DADD3C8619C80B08FCE6FAE00AM3PR07MB369eurprd_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hello Keith,



 <=
/p>

Libraries =
etc. are already creating all sorts of links, for instance between metadata=
 records describing different manifestations of resources
 (like printed and electronic versions of books) and resources and their co=
mponent parts (like CD and tracks in it). A problem with this is that the i=
dentifiers used for this may not be globally unique. If database internal I=
Ds have been used for linking, their
 usefulness may be limited when the bibliographic data is shared in the Web=
. Moving from present situation to something that is palatable in Semantic =
Web may be non-trivial. The sooner we use persistent identifiers in all res=
ource linking, the better.  


 =
;


Dynamic re=
sources (ones which change all the time) are an interesting  challenge=
. Traditional identifiers do not cope with them too well; granularity
 is an issue. For instance, ISSN can only be used to identify all versions =
of an entire web site. And ISBN community would soon run out of numbers if =
there were a lot of versions of each book. However, new identifier systems =
such as Handle/DOI and URN:NBN and
 some other URN namespaces allow – in theory - any level of granulari=
ty. In order to identify all versions of a Web page one can use e.g. Nation=
al Bibliography Numbers based on MD5 or some other check sum. The identifie=
r assignment processes must of course
 be fully automated; for instance the National Library of Finland has minte=
d tens of millions of URN:NBNs to page images of digitized manuscripts, mon=
ographs, journals, newspapers etc.  There are also identifiers for OCR=
-converted texts – and images within
 them – to enable so called deep linking. 


 =
;


Regarding =
resolution and q-components: once we have updated RFC2141 and – I hop=
e – agreed that q-component is allowed, the aim is to update RFC
 2483. The new version of that RFC will  specify a mechanism with whic=
h the URN users can register new URN resolution services and service parame=
ters. Parameter usage is important for e.g. services like URI to URC, since=
 there are many different things a user
 may ask for: basic bibliographic description of a resource, its rights rel=
ated information (what am I entitled to do with this resource), technical m=
etadata (what application can be used to render this resource) or preservat=
ion metadata (how does the look
 and feel of this migrated version of the resource differ from previous ver=
sions).



 =
;


There are =
definitely cases when URL + query can  be replaced by more persist=
ent URN + query. Instead of making deep (and short-lived) links like
 this


 =
;


http://z3950.loc.gov:7090/voyag=
er?version=3D1.1&operation=3DsearchRetrieve&query=3D[ISBN]


 =
;


it would b=
e better to let the URN resolver to map URN:ISBN + query for resource m=
etadata into a URI-based database search. When search protocols
 and database applications change, URN resolution table of the appropriate =
URN resolver can be modified so that the URN is mapped to the current searc=
h syntax.  


 =
;


Depending =
on the namespace, for instance URI to URC service may or may not be support=
ed, and even if it is, different metadata formats may be relevant.
 Library systems will be able to supply MARC 21, archival information syste=
ms will support EAD, museum systems LIDO, and all of these systems may be a=
ble to deliver Dublin Core records as common denominator. This will require=
 shared (between clients and URN
 resolvers) understanding on URN query syntax, and “smart” URN =
resolvers which know how to deal with these resolution requests. Network pr=
otocols themselves should not be affected by this.  =



 =
;


Namespaces=
 I am familiar will not be able to accommodate p-component. There may be ot=
her namespaces which will find it useful.  


 =
;


I don̵=
7;t know how relative references could be used in productive manner in this=
 context.



 =
;


Juha



 &nbs=
p;


 








From:=
 Keith Moore [mailto=
:moore@network-heretics.com]


Sent: 17. huhtikuuta 2015 16:29

To: Hakala, Juha E; urn@ietf.org

Subject: Re: [urn] Re-examining p-components (and "/", hie=
rarchy, and relative references)






 




Juha,



This all sounds marvelous and I look forward to the day when this is in pla=
ce.   



My main questions are with how this system of identifiers and relationships=
 interfaces to the world of network-accessible resources, which may be inte=
ractive and/or have their own rich set of internal links to one another.


Also, I'm primarily a network protocols person.   So whenever I l=
ook at something like this I ask myself how it will be implemented in netwo=
rk protocols, and whether those protocols will be organized in such a way a=
s facilitate the use of those identifiers
 and relationships, or hinder such use.   One way that the networ=
k protocols can hinder such use is by not permitting URNs to be handled in =
a uniform way.   So if every different URN namespace has differen=
t rules for how software needs to request resolution
 (like which components to include), or if q-component works differently fo=
r different URN namespaces, or relative references work differently for dif=
ferent URN namespaces, any of those things could hinder use.



Since there are already numerous resources that are referred to using URLs =
and which accept queries, I would like it to be possible to name those reso=
urces (or at least some of those resources) with URNs without losing the ab=
ility to send queries to those resources.  
 So given the large amount of mindshare around using ? to introduce queries=
 to those resources, to me it makes more sense to use URN q-component for t=
hat purpose also, and to define a different component to enable requests fo=
r things like metadata.



Also, I don't like RFC 3986's treatment of URNs at all.  But perhaps u=
nfortunately, there's a large amount of mindshare around using not only 398=
6 syntax for URNs but also its rules for relative references with URNs.&nbs=
p;  And part of what that means to me is that
 if we use 3986 syntax for URN components that weren't permitted in 2141, i=
t's going to be difficult for URNs to avoid being hampered by 3986's rules =
for relative references and by the expectations in the web world for what t=
hose components mean.



So I think URNBIS needs to strong and technically sound statement about how=
 to resolve the conflict between the needs of URNs, and this large amount o=
f mindshare.  And URNBIS needs to do so in a way that both preserves t=
he ability of the library community to
 further its goals, and also preserves the ability of network-accessible re=
sources to accept queries, have relative references, allow identified subse=
ts of the results to be referenced, and so forth.   To my underst=
anding, figuring out how to resolve this conflict
 is the primary problem that is currently before us.   



Keith



On 04/17/2015 02:10 AM, Hakala, Juha E wrote:






Hello,<=
/p>

 <=
/p>

Library co=
mmunity has well established practices for how to use identifiers. URNBIS c=
ould use these practices as the starting point, extend them
 if needed and alter them only when there is a good reason to do so. As a r=
esult URNBIS should have a more unified understanding of what kind of funct=
ionality needs to be supported now, and what can be postponed for the time =
being.  


 


There are =
already international standard identifiers for:


 


-      =
   
Wo=
rks, which are immaterial entities (such as The Tragicall Historie of Hamle=
t, Prince of Denmarke)


 


-      =
   
Ex=
pressions, which are translations and other versions of these works (such a=
s a Finnish translation of Hamlet or a cartoon version of
 the original English text)


 


-      =
   
Ma=
nifestations, which are physical embodiments of works & expressions. Ph=
ysical may mean hand-held (printed) or electronic (PDF, EPUB3,
 etc.).


 


-      =
   
Pu=
blic identities, which are not the same as persons;  George Orwell is =
a public identity but the person behind it was Eric Blair. Public
 identity can also belong to a legal entity (Rolling Stones or IETF) or a f=
igment of author’s imagination (such as Winnie the Pooh).  


 


Item (or c=
opy) identifiers are work in progress. ISO TC 46/SC 9 is currently developi=
ng International Standard Item Identifier, with which it will
 be possible to identify particular items, such as the copy of Diophantus&#=
8217; Arithmetica containing some interesting comments by Pierre de Fermat.



 


The underl=
ying data model which binds all these bibliographic and other entities toge=
ther is FRBR (http://en.wikipedia.org/wiki/Functional_Requi=
rements_for_Bibliographic_Records).
 While it is important that we can identify things uniquely and persistentl=
y, the real aim is more ambitious: to create linked data. Libraries will &#=
8211; via collective effort, and in cooperation with museums and archives -=
 interconnect related works such as the
 original Hamlet and Laurence Olivier’s 1948 movie (or to be more pre=
cise, metadata records describing these works in our catalogues), works and=
 their expressions, works / expressions and their manifestations, and manif=
estations and their items.


 


This kind =
of functionality is not widely available in library systems yet, but there =
are some systems which provide already a glimpse of what the
 future will look like. OCLC’s WorldCat is my favourite; see for inst=
ance the search results for Gone with the wind:



 


http://www.worldcat.org/se=
arch?q=3Dgone+with+the+wind%2C+by+margaret+mitchell=
&qt=3Dowc_search


 


In order t=
o provide a solid basis for decentralized creation of linked data we need p=
ersistent identifiers from works to items (and metadata formats
 which enable us to specify the different roles these identifiers will have=
; in a work metadata record manifestation identifier acts as a link and vic=
e versa). URN qualifiers will not be needed for identification, but it is n=
ecessary to use q-component for
 e.g. enabling the users to request metadata for a work with the q-componen=
t. They will then be able to see that there are related works and expressio=
ns (and take a closer look at them).  F-component will not be relevant=
 for us, but users will be able to cite
 documents with them and manifestation identifiers. I can’t see any n=
eed for the p-component for the time being.



 


Rich data =
models such as FRBR are a must in digital archives, since eventually they w=
ill contain several manifestations of most archived digital
 resources, if migration is the preferred preservation method. A user may i=
nitially find an outdated version of a document; in such situation it is im=
portant to find out that there are more modern versions available (and also=
 that these versions will not have
 exactly the same look and feel than the original). 


 


The scope =
of the URN system as a whole cannot be defined meaningfully since each new =
namespace (and changes in identifier systems which already
 have a namespace) alters the situation. At the moment URN does not specifi=
cally target e.g. public identities, but if a namespace is registered for I=
nternational Standard Name Identifier, the problem is solved. As far as I a=
m concerned, URNs can be used to
 identify resources (whatever they are), just like DOI is already being use=
d to identify all sorts of objects (in DOI, it is the identifier itself whi=
ch is digital, the identified object does not need to be).   &nbs=
p; 


 


Juha  =
; 


 


 








From:=
 urn [mailto:urn-bounces@ietf.org]
On Behalf Of Keith Moore

Sent: 16. huhtikuuta 2015 16:30

To: urn@ietf.org

Subject: Re: [urn] Re-examining p-components (and "/", hie=
rarchy, and relative references)






 




On 04/15/2015 10:19 PM, Peter Saint-Andre - &yet=
 wrote:








I would prefer it if we can agree on some limitation=
s on namespaces that


use '/' in NSSs that will render path-relative references either useful 
or "mostly harmless" (depending on the particular discipline chos=
e by 

that namespace).   As I stated above, I think we're going to want=
 to be 

able to use URNs to refer to resources that contain path-relative 

references without breaking those references.   We should certain=
ly be 

able to use URNs to name HTML documents, for instance. 






Keith, would you mind clarifying that last sentence? 



Here's why I ask. To my mind, we should certainly be able to use URNs to na=
me documents (if by document we mean a created work, not any particular cop=
y of that created work). Such a work might be an electronic document that c=
ould be constructed using any of
 a number of particular technologies: SGML, XML, HTML, EPUB, MS Word, PDF, =
markdown, TeX, LaTeX, you name it. Although I agree that we should certainl=
y be able to use URNs to name electronic documents, I don't see why HTML is=
 special here (I'm not saying you
 think it's special, BTW). Would you also agree that we should certainly be=
 able to use URNs to name PDF documents or MS Word documents or EPUB docume=
nts?





=


I absolutely agree that we should be able to use URNs to name any of the ab=
ove kinds of resources.  
The reason I cited HTML as an example above is because (a) it's pres=
umably familiar to most list readers, and (b) HTML is a kind of resource th=
at potentially uses path-relative references.



For example, if there are one or more URNs that refer to a document that co=
ntains a link to "../../foo", the behavior of that link when the =
document is accessed via any of those URNs should be reasonable, well-defin=
ed, and namespace-independent.  Ideally, the
 defined behavior of that link should be consistent with the behavior when =
the same document is referred to by a URL that contains a path. 




(Though I realize that such links can behave inconsistently even with multi=
ple URLs point to such a document   So I suppose the most that ca=
n be asked is that it be possible for path-relative links in documents to
be able to work as well when referred to by URNs as they can work wh=
en referred to by URLs.)



Keith






 








--_000_AM3PR07MB369DADD3C8619C80B08FCE6FAE00AM3PR07MB369eurprd_--


From nobody Mon Apr 20 06:52:27 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AF01A002C for ; Mon, 20 Apr 2015 06:52:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZpJzjtj0pfD for ; Mon, 20 Apr 2015 06:52:23 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462651B2BB2 for ; Mon, 20 Apr 2015 06:52:22 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B6D0B2009E for ; Mon, 20 Apr 2015 09:52:21 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 20 Apr 2015 09:52:21 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=5uLQFpzLd6GUcKTX1r+IESZHFnw=; b=kDSkH K2CVPpHroGObdOMjo90GxOpheouS9F/mAzsGJTECmIqYaz5g91YItGy6SOdEk1He /+QC/gp9fsqbC1HnmeOXK4uRI1a2krx/11Mgbe4REDNJh4p0nVQiS09Gh+/SBD2b ZWMgJa9AlVY17BKj9Oy/qJ50sD862zPBAduNTk=
X-Sasl-enc: +ZUi9uhFHbZwE1oQIDKK6gMvm2jhfidwQp8tAMWK04eM 1429537941
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 4A6F3680103; Mon, 20 Apr 2015 09:52:21 -0400 (EDT)
Message-ID: <55350476.8050708@network-heretics.com>
Date: Mon, 20 Apr 2015 09:51:50 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References:  <5534DA1E.4020707@it.aoyama.ac.jp>
In-Reply-To: <5534DA1E.4020707@it.aoyama.ac.jp>
Content-Type: multipart/alternative; boundary="------------020902070905020005010304"
Archived-At: 
Subject: Re: [urn] About fragments and queries
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Apr 2015 13:52:26 -0000

This is a multi-part message in MIME format.
--------------020902070905020005010304
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

On 04/20/2015 06:51 AM, "Martin J. Drst" wrote:
>
>> 2. So when a client of some kind encounters a URN of the form:
>> urn:example:foo?bar
>> the client's behavior should invariably be to find the resource named 
>> by urn:example:foo and try to transmit "bar" to it (if the protocol 
>> via which urn:example:foo is accessed permits that)
>>
>> JH: There are resolution services which do not require that the 
>> identified resource itself is found. For instance, if, ?bar is a 
>> request to retrieve descriptive metadata about the resource, URN 
>> resolver does not need to locate the resource itself, but it must 
>> know how an appropriate metadata record (records) can be retrieved.
>
> I'd tend to side with Juha here. I'd note that the prototypical 
> resolution service (not for URNs, but for everything else), namely 
> HTTP, does NOT find the resource before the "?" and send it the query 
> part after the "?".
>
> E.g. for http://www.google.com/search?as_sitesearch=ietf.org&q=urn, it
> does NOT find the resource named "http://www.google.com/search" and 
> try to transmit "as_sitesearch=ietf.org&q=urn" to it, but it finds 
> "www.google.com" and sends "/search?as_sitesearch=ietf.org&q=urn" to it.
>
> [For the purpose of this example, we can ignore the fact that we get 
> redirected from http to https, and in my case from www.google.com to 
> www.google.co.jp.]
>
> And for proxies, the whole URI is sent in one go. And the URI spec 
> definitely does not prescribe any specific way to do this, but leaves 
> it to schemes, and even if a scheme specifies something very clearly, 
> resolution infrastructure between the user and the data may still do 
> something different. Also, because for URNs, resolution services are 
> an open-ended business, I don't think it would be a good idea to be 
> that specific.

I should probably be more explicit and state that in these discussions 
I'm often concerned with a particular kind of use case: that in which 
the URN is used in a way in which the right thing for the client to do 
is to try to obtain the content associated with the URN, and/or to 
obtain the result from sending a query to the resource named by the 
URN.   That's certainly not the only use case for URNs, and probably 
won't even be the most common way that URNs are used.   But that use 
case significantly motivated the creation of URNs, and I think it's 
still an important one.

For that use case it's important that it be possible to transmit 
"queries" to the actual resources.   So what we need is some consistent 
syntax with which a URN of a resource, and a query to be sent to that 
resource, can be bundled together.

We also, separately, need a consistent syntax with which a URN of a 
resource can be bundled with a request to a resolution service.

If we try to use the same kind of URN "qualifier" for both kinds of 
queries/requests, this will cause problems.

There is more than one way to solve this problem, to create a uniform 
syntax so that either or both kinds of query (to the resource, or to the 
resolution service) can be attached to a URN, and so that the two kinds 
can be distinguished from one another. I'm proposing a syntax like this:

urn:example:nss??resolution-service-query?resource-query#fragment

Again, this is just a proposal, it's not the only way that the problem 
could be solved.  The things I like about this solution are: (a) it's 
compatible with RFC 3986 syntax, and (b) it preserves the meaning of "?" 
that it has with most URLs, and which is widely understood.

Note that this syntax says nothing about the protocol used to 
communicate the URN and the resolution-service-query to the resolution 
service.   But it would be very reasonable for a resolution service to 
have a protocol like:  do an HTTP "GET" of the base URL of the 
resolution service, followed by "/", followed by the assigned-part of 
the URN, followed by "?", followed by the resolution-service-query.   So 
if a URN like the one above were encountered by a client, the URL for 
the query to be sent to the resolution service would look like:

http://example.com/resolution-service/urn:example.nss?resolution-service-query 


Having obtained the result from that GET, the client might then obtain a 
URL for the resource to which it could transmit resource-query.   For 
instance, if the URL for the resource returned were 
http://x.example.com/y the client would then request:

http://x.example.com/y?resource-query

And the client would then evaluate the returned content to identify the 
portion of the resource corresponding to fragment.

(I hope the colors aren't distracting; they're just my attempt to make 
it easier to see how the different parts of the URN would be used).

Note that if we want consistent interpretation of q-components and 
f-components across different namespaces, and across different 
resolution services, we don't want the entire URN to be transmitted to 
resolution services.  We should only transmit the "assigned portion" of 
the URN along with any query intended for the resolution service.   That 
way, the resolution service can't change how q-component and f-component 
are interpreted in the context of the actual resource.

However, if the purpose of the URN request is not to ultimately access 
the resource content or interact with the resource, but rather to obtain 
metadata about the resource, it's possible that fragment would be 
interpreted differently.   So in the case of:

urn:example:nss??request=content?resource-query#fragment

fragment would be evaluated according to the result returned from 
sending resource-query to the resource,

but in the case of

urn:example:nss??request=metadata?resource-query#fragment

fragment might be evaluated with respect to the metadata returned from 
the resolution service.
(and resource-query would presumably not be relevant)



>
>> So given the above rules, whether namespace example "permits" 
>> q-components and/or f-components is kind of irrelevant.  In practice, 
>> IF the name resolves to a resource that accepts queries, the 
>> q-component will be used as a query, and IF the name resolves to a 
>> resource that has fragments, the f-component will be interpreted as a 
>> fragment name.
>>
>> JH:  For me, the question is not whether the resource itself accepts 
>> queries, but whether the applications with which the resource is 
>> managed do accept them.  Many of them will, and the set of services 
>> supported will grow when digital asset management systems get smarter.
>
> I'd reply somewhat differently here than Juha, but I'd guess the 
> result would be the same regarding the spec.

I think it helps to make a clear distinction between queries sent to the 
resource, and queries sent to resolution services.   It helps to make 
this distinction clear not only in the URN itself, but also in discussions.

I certainly agree that the capabilities of resolution services will 
expand over time, so it's important that the language used to specify 
resolution service queries be extensible.

Keith


--------------020902070905020005010304
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 04/20/2015 06:51 AM, "Martin J.
      Drst" wrote:

    

    


      
2. So when a client of some kind
        encounters a URN of the form:
        

        urn:example:foo?bar
        

        the client's behavior should invariably be to find the resource
        named by urn:example:foo and try to transmit "bar" to it (if the
        protocol via which urn:example:foo is accessed permits that)
        

        

        JH: There are resolution services which do not require that the
        identified resource itself is found. For instance, if, ?bar is a
        request to retrieve descriptive metadata about the resource, URN
        resolver does not need to locate the resource itself, but it
        must know how an appropriate metadata record (records) can be
        retrieved.
        

      

      

      I'd tend to side with Juha here. I'd note that the prototypical
      resolution service (not for URNs, but for everything else), namely
      HTTP, does NOT find the resource before the "?" and send it the
      query part after the "?".
      

      

      E.g. for
      http://www.google.com/search?as_sitesearch=ietf.org&q=urn, it
      

      does NOT find the resource named "http://www.google.com/search"
      and try to transmit "as_sitesearch=ietf.org&q=urn" to it, but
      it finds "www.google.com" and sends
      "/search?as_sitesearch=ietf.org&q=urn" to it.
      

      

      [For the purpose of this example, we can ignore the fact that we
      get redirected from http to https, and in my case from
      www.google.com to www.google.co.jp.]
      

      

      And for proxies, the whole URI is sent in one go. And the URI spec
      definitely does not prescribe any specific way to do this, but
      leaves it to schemes, and even if a scheme specifies something
      very clearly, resolution infrastructure between the user and the
      data may still do something different. Also, because for URNs,
      resolution services are an open-ended business, I don't think it
      would be a good idea to be that specific.
      

    

    

    I should probably be more explicit and state that in these
    discussions I'm often concerned with a particular kind of use case:
    that in which the URN is used in a way in which the right thing for
    the client to do is to try to obtain the content associated with the
    URN, and/or to obtain the result from sending a query to the
    resource named by the URN. That's certainly not the only use case
    for URNs, and probably won't even be the most common way that URNs
    are used.  But that use case significantly motivated the creation
    of URNs, and I think it's still an important one. 

    

    For that use case it's important that it be possible to transmit
    "queries" to the actual resources. So what we need is some
    consistent syntax with which a URN of a resource, and a query to be
    sent to that resource, can be bundled together.

    

    We also, separately, need a consistent syntax with which a URN of a
    resource can be bundled with a request to a resolution service.

    

    If we try to use the same kind of URN "qualifier" for both kinds of
    queries/requests, this will cause problems. 

    

    There is more than one way to solve this problem, to create a
    uniform syntax so that either or both kinds of query (to the
    resource, or to the resolution service) can be attached to a URN,
    and so that the two kinds can be distinguished from one another.
    I'm proposing a syntax like this:

    

    urn:example:nss??resolution-service-query?resource-query#fragment

    

    Again, this is just a proposal, it's not the only way that the
    problem could be solved. The things I like about this solution are:
    (a) it's compatible with RFC 3986 syntax, and (b) it preserves the
    meaning of "?" that it has with most URLs, and which is widely
    understood.

    

    Note that this syntax says nothing about the protocol used to
    communicate the URN and the resolution-service-query to the
    resolution service. But it would be very reasonable for a
    resolution service to have a protocol like: do an HTTP "GET" of the
    base URL of the resolution service, followed by "/", followed by the
    assigned-part of the URN, followed by "?", followed by the
    resolution-service-query. So if a URN like the one above were
    encountered by a client, the URL for the query to be sent to the
    resolution service would look like:

    

    http://example.com/resolution-service/urn:example.nss?resolution-service-query 

    

    Having obtained the result from that GET, the client might then
    obtain a URL for the resource to which it could transmit resource-query. For instance, if the URL
    for the resource returned were http://x.example.com/y the client
    would then request:

    

    http://x.example.com/y?resource-query

    

    And the client would then evaluate the returned content to identify
    the portion of the resource corresponding to fragment.

    

    (I hope the colors aren't distracting; they're just my attempt to
    make it easier to see how the different parts of the URN would be
    used).

    

    Note that if we want consistent interpretation of q-components and
    f-components across different namespaces, and across different
    resolution services, we don't want the entire URN to be transmitted
    to resolution services. We should only transmit the "assigned
    portion" of the URN along with any query intended for the resolution
    service. That way, the resolution service can't change how
    q-component and f-component are interpreted in the context of the
    actual resource.

    

    However, if the purpose of the URN request is not to ultimately
    access the resource content or interact with the resource, but
    rather to obtain metadata about the resource, it's possible that
    fragment would be interpreted differently. So in the case of:

    

    urn:example:nss??request=content?resource-query#fragment

    

    fragment would be evaluated according to the result returned from
    sending resource-query to the resource,

    

    but in the case of

    

    urn:example:nss??request=metadata?resource-query#fragment

      

      fragment
          might be evaluated with respect to the metadata returned from
          the resolution service.

          (and resource-query would
          presumably not be relevant)

      

      

    

    

      

      
So given the above rules, whether
        namespace example "permits" q-components and/or f-components is
        kind of irrelevant. In practice, IF the name resolves to a
        resource that accepts queries, the q-component will be used as a
        query, and IF the name resolves to a resource that has
        fragments, the f-component will be interpreted as a fragment
        name.
        

        

        JH: For me, the question is not whether the resource itself
        accepts queries, but whether the applications with which the
        resource is managed do accept them. Many of them will, and the
        set of services supported will grow when digital asset
        management systems get smarter.
        

      

      

      I'd reply somewhat differently here than Juha, but I'd guess the
      result would be the same regarding the spec.
      

    

    

    I think it helps to make a clear distinction between queries sent to
    the resource, and queries sent to resolution services. It helps to
    make this distinction clear not only in the URN itself, but also in
    discussions. 

    

    I certainly agree that the capabilities of resolution services will
    expand over time, so it's important that the language used to
    specify resolution service queries be extensible.

    

    Keith

    

  


--------------020902070905020005010304--


From nobody Mon Apr 20 16:31:20 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0871B34B5 for ; Mon, 20 Apr 2015 16:31:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkoHhXXp8Bo0 for ; Mon, 20 Apr 2015 16:31:15 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909C11B34B9 for ; Mon, 20 Apr 2015 16:31:15 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id C77FD20805 for ; Mon, 20 Apr 2015 19:31:13 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 20 Apr 2015 19:31:13 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=ePkt1e5Pbk5zbhovP0r1lNU+8aI=; b=FMyeI xW5iBUKLsmnVngZqBHBPEEjQnOZiRNSmcwu55qH69O8WB3X2sxEyB2uVAsFDUglB DAMxyyo/Qnf3R/pP1juxAOjl1/iEYY5y3HMbnoRHbjbMudp9exBhwYD7WQOqhNuz nM1ULLQQafE7maNKWYo6GacsjlAFfsURutxKIw=
X-Sasl-enc: enq1vTjsV+b97b5+mV7/InYyH6TZiy58/6CYhBuhrrVZ 1429572673
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 54D43680085; Mon, 20 Apr 2015 19:31:13 -0400 (EDT)
Message-ID: <55358C21.3000203@network-heretics.com>
Date: Mon, 20 Apr 2015 19:30:41 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References:  <5534DA1E.4020707@it.aoyama.ac.jp>
In-Reply-To: <5534DA1E.4020707@it.aoyama.ac.jp>
Content-Type: multipart/alternative; boundary="------------090402080909040409060003"
Archived-At: 
Subject: Re: [urn] About fragments and queries
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Apr 2015 23:31:19 -0000

This is a multi-part message in MIME format.
--------------090402080909040409060003
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

I realized that I had misread something that Martin wrote the first 
couple of times I read it, so I'd like to respond again in the hopes 
that it will clarify things a bit more:

On 04/20/2015 06:51 AM, "Martin J. Drst" wrote:
> 2. So when a client of some kind encounters a URN of the form:
>> urn:example:foo?bar
>> the client's behavior should invariably be to find the resource named 
>> by urn:example:foo and try to transmit "bar" to it (if the protocol 
>> via which urn:example:foo is accessed permits that)
>>
>> JH: There are resolution services which do not require that the 
>> identified resource itself is found. For instance, if, ?bar is a 
>> request to retrieve descriptive metadata about the resource, URN 
>> resolver does not need to locate the resource itself, but it must 
>> know how an appropriate metadata record (records) can be retrieved.
>
> I'd tend to side with Juha here. I'd note that the prototypical 
> resolution service (not for URNs, but for everything else), namely 
> HTTP, does NOT find the resource before the "?" and send it the query 
> part after the "?".
>
> E.g. for http://www.google.com/search?as_sitesearch=ietf.org&q=urn, it
> does NOT find the resource named "http://www.google.com/search" and 
> try to transmit "as_sitesearch=ietf.org&q=urn" to it, but it finds 
> "www.google.com" and sends "/search?as_sitesearch=ietf.org&q=urn" to it.

Correct.  Though I think this is just a difference between the 
conceptual model and the implementation.  Conceptually, the resource in 
http://www.google.com/search?as_sitesearch=ietf.org&q=urn is 
http://www.google.com/search, and the query is 
as_sitesearch=ietf.org&q=urn.   Conceptually what you're doing is 
sending the query to the resource and getting back a response from the 
resource.

But as you point out, the implementation is that a TCP connection gets 
opened to www.google.com port 80 and the client sends

GET /search?as_sitesearch=ietf.org&q=urn HTTP/1.1
Host: www.google.com

(and then may follow redirects from there before it actually gets a 
response)

Since (at least as far as we can tell from the client end) the same 
server responds to all requests sent to www.google.com, that server code 
is in practice free to interpret the request string any way it wants.   
It doesn't have to treat /a/b and /a/c as separate resources, and it's 
actually fairly common for servers to send anything beginning with a 
certain path prefix to code that (in theory) implements all of the 
conceptual resources beginning with that prefix.   And of course, in 
practice, the code that implements everything starting with a particular 
prefix can do whatever it wants to do.   There are no protocol police to 
force it to follow the conceptual model of web resource names.

I'm not quite sure what the above has to do with URNs or URN resolution, 
but I'll take a stab at clarifying what I wrote before:

When I wrote:
> 2. So when a client of some kind encounters a URN of the form:
> urn:example:foo?bar
> the client's behavior should invariably be to find the resource named 
> by urn:example:foo and try to transmit "bar" to it (if the protocol 
> via which urn:example:foo is accessed permits that)
I was referring to the conceptual model, not the implementation. If I 
were being more precise, I might have said:

    So when a client of some kind encounters a URN of the form:
    urn:example:foo?bar
    the client's behavior should be to find a URL for the resource named
    by urn:example:foo and transmit the query "bar" to it.


Or I might have instead said:

    So when a client of some kind encounteres a URN of the form:
    urn:example:foo?bar
    the client's behavior should be to find a URL for the resource named
    by urn:example:foo and append the query "?bar" to that URL, then get
    the content resulting from that combined URL.


(at the moment, I'm not entirely sure which of the two alternatives is 
better.   each has its appeal.)

> And for proxies, the whole URI is sent in one go. And the URI spec 
> definitely does not prescribe any specific way to do this, but leaves 
> it to schemes, and even if a scheme specifies something very clearly, 
> resolution infrastructure between the user and the data may still do 
> something different. Also, because for URNs, resolution services are 
> an open-ended business, I don't think it would be a good idea to be 
> that specific.

Well, "urn" is a scheme.   But I would consider it a Bad Idea to 
legislate a single resolution mechanism for URNs, because resolution 
mechanisms need to be able to evolve over time, without changing the 
meanings of those URNs.  So URNs should not be seen as inherently tied 
to any resolution mechanism.

But I do think that the interpretation of "?" and "#" with respect to a 
URN should be consistent for all URNs, regardless of namespace or which 
resolution mechanism is used.  Which implies that the "query" and 
"fragment" (or "q-component" and "f-component") that appear in a URN 
should not be transmitted to URN resolution services.

However, a resolution service can still be layered on top of HTTP and a 
request URL sent to such a service can still contain a query component - 
it just shouldn't be the q-component of the URN. That's why I want a 
syntax for URNs that clearly separates "resolution service query" from 
"resource query".   The resolution service query should be sent to the 
resolution service, and the resource query should (conceptually) be sent 
to the resource.

Anyway, I hope that makes my position clearer.

Keith


--------------090402080909040409060003
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
I realized that I had misread something
      that Martin wrote the first couple of times I read it, so I'd like
      to respond again in the hopes that it will clarify things a bit
      more:

      

      On 04/20/2015 06:51 AM, "Martin J. Drst" wrote:

    

    
2.
      So when a client of some kind encounters a URN of the form:
      

      
urn:example:foo?bar
        

        the client's behavior should invariably be to find the resource
        named by urn:example:foo and try to transmit "bar" to it (if the
        protocol via which urn:example:foo is accessed permits that)
        

        

        JH: There are resolution services which do not require that the
        identified resource itself is found. For instance, if, ?bar is a
        request to retrieve descriptive metadata about the resource, URN
        resolver does not need to locate the resource itself, but it
        must know how an appropriate metadata record (records) can be
        retrieved.
        

      

      

      I'd tend to side with Juha here. I'd note that the prototypical
      resolution service (not for URNs, but for everything else), namely
      HTTP, does NOT find the resource before the "?" and send it the
      query part after the "?".
      

      

      E.g. for
      http://www.google.com/search?as_sitesearch=ietf.org&q=urn, it
      

      does NOT find the resource named "http://www.google.com/search"
      and try to transmit "as_sitesearch=ietf.org&q=urn" to it, but
      it finds "www.google.com" and sends
      "/search?as_sitesearch=ietf.org&q=urn" to it.
      

    

    

    Correct. Though I think this is just a difference between the
    conceptual model and the implementation. Conceptually, the resource
    in http://www.google.com/search?as_sitesearch=ietf.org&q=urn is
    http://www.google.com/search, and the query is
    as_sitesearch=ietf.org&q=urn. Conceptually what you're doing
    is sending the query to the resource and getting back a response
    from the resource.

    

    But as you point out, the implementation is that a TCP connection
    gets opened to www.google.com port 80 and the client sends 

    

    GET /search?as_sitesearch=ietf.org&q=urn HTTP/1.1

    Host: www.google.com

    

    (and then may follow redirects from there before it actually gets a
    response)

    

    Since (at least as far as we can tell from the client end) the same
    server responds to all requests sent to www.google.com, that server
    code is in practice free to interpret the request string any way it
    wants. It doesn't have to treat /a/b and /a/c as separate
    resources, and it's actually fairly common for servers to send
    anything beginning with a certain path prefix to code that (in
    theory) implements all of the conceptual resources beginning with
    that prefix. And of course, in practice, the code that implements
    everything starting with a particular prefix can do whatever it
    wants to do. There are no protocol police to force it to follow
    the conceptual model of web resource names.

    

    I'm not quite sure what the above has to do with URNs or URN
    resolution, but I'll take a stab at clarifying what I wrote before:

    

    When I wrote:

    
2. So when a client of some kind encounters
      a URN of the form:
      

      urn:example:foo?bar
      

      the client's behavior should invariably be to find the resource
      named by urn:example:foo and try to transmit "bar" to it (if the
      protocol via which urn:example:foo is accessed permits that)
      

    

    I was referring to the conceptual model, not the implementation.
    If I were being more precise, I might have said:

    

    
So when a client of some kind encounters a URN of the
      form:

      urn:example:foo?bar

      the client's behavior should be to find a URL for the resource
      named by urn:example:foo and transmit the query "bar" to it.

    

    

    Or I might have instead said:

    

    
So when a client of some kind encounteres a URN of the
      form:

      urn:example:foo?bar

      the client's behavior should be to find a URL for the resource
      named by urn:example:foo and append the query "?bar" to that URL,
      then get the content resulting from that combined URL.

    

    

    (at the moment, I'm not entirely sure which of the two alternatives
    is better. each has its appeal.)

    

    
And
      for proxies, the whole URI is sent in one go. And the URI spec
      definitely does not prescribe any specific way to do this, but
      leaves it to schemes, and even if a scheme specifies something
      very clearly, resolution infrastructure between the user and the
      data may still do something different. Also, because for URNs,
      resolution services are an open-ended business, I don't think it
      would be a good idea to be that specific.
      

    

    

    Well, "urn" is a scheme. But I would consider it a Bad Idea to
    legislate a single resolution mechanism for URNs, because resolution
    mechanisms need to be able to evolve over time, without changing the
    meanings of those URNs. So URNs should not be seen as inherently
    tied to any resolution mechanism.

    

    But I do think that the interpretation of "?" and "#" with respect
    to a URN should be consistent for all URNs, regardless of namespace
    or which resolution mechanism is used. Which implies that the
    "query" and "fragment" (or "q-component" and "f-component") that
    appear in a URN should not be transmitted to URN resolution
    services.

    

    However, a resolution service can still be layered on top of HTTP
    and a request URL sent to such a service can still contain a query
    component - it just shouldn't be the q-component of the URN.
    That's why I want a syntax for URNs that clearly separates
    "resolution service query" from "resource query". The resolution
    service query should be sent to the resolution service, and the
    resource query should (conceptually) be sent to the resource.

    

    Anyway, I hope that makes my position clearer.

    

    Keith

    

  


--------------090402080909040409060003--


From nobody Tue Apr 21 09:33:50 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4E81AD255 for ; Tue, 21 Apr 2015 09:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.443
X-Spam-Level: 
X-Spam-Status: No, score=0.443 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGsdKiVIUdZX for ; Tue, 21 Apr 2015 09:33:47 -0700 (PDT)
Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 646B81AD277 for ; Tue, 21 Apr 2015 09:33:01 -0700 (PDT)
Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id B08D73B8079; Tue, 21 Apr 2015 09:33:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= thinkingcat.com; bh=hQrHA9GkA/qqff3UPCxkv0wqrc4=; b=Q1WT4k9ZIEJk 5fa9saU3dGB+zhvr9rDpvns3QqST0+ibyis0fUuIdbMRI6apxUp2zc6F1fy3+A3f Y1NmFV3ADzSz5xwDQF3QAF5GOFlUIbxxlsWNke2EV96RpGlZhO5ZHfnb40OfDCQn n/JNJMUR7HJRMSNAXyKXJbUzctoyfaA=
Received: from aran-w.int.lexiconix.com (pool-108-44-246-138.clppva.fios.verizon.net [108.44.246.138]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id E78A33B809A; Tue, 21 Apr 2015 09:32:59 -0700 (PDT)
Message-ID: <55367BBA.3020807@thinkingcat.com>
Date: Tue, 21 Apr 2015 12:32:58 -0400
From: "Leslie Daigle (ThinkingCat)" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com> <552F15AD.2050405@andyet.net> <552F6234.4080509@network-heretics.com> <55317AA4.70105@thinkingcat.com> <55319FD5.1070404@network-heretics.com>
In-Reply-To: <55319FD5.1070404@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Apr 2015 16:33:49 -0000

[Apologies for delayed/lost e-mail -- mail server issues. ]

In-line...

On 4/17/15 8:05 PM, Keith Moore wrote:
> On 04/17/2015 05:27 PM, Leslie Daigle (ThinkingCat) wrote:
>> Hi,
>>
>> Thinking through the r-component idea a bit...   I think your
>> argumentation for r-components is pretty compelling, especially as we
>> work to make clear why f-components don't fit that particular bill.
>> However, I am more than a little concerned about getting too complex
>> and bolting stuff on at this point.
>>
>> I won't argue that DDDS has been used for just about everything
>> *except* providing the standard for URN resolution, but in working it
>> out we I'm sure you recall we did did actually talk through
>> "resolution services" (for ease of reference for anyone who missed it
>> -- https://tools.ietf.org/html/rfc2483).
>>
>> Again, not quite what you are describing now (I read you to be
>> thinking more about parameters one would send, not services one would
>> request), but perhaps enough to illustrate that there is a whole farm
>> of things one might wish to consider if one stops and thinks about
>> using URNs in action.
>>
>> I think pursuing r-components as part of this document would slow this
>> one down a fair bit.
>>
>> Is there a way to leave enough of a hook in the syntax to pursue
>> r-component as a separate document?  (BTW...  does "??" actually fly
>> with URI syntax, or wouldn't the 2nd "?" be part of the q-component?).
>
> "Leaving [just] enough of a hook" is exactly what I want to do in this
> document.  I think that means:  (a) define the syntax for URNs including
> that of r-components, (b) explain the role of r-components in URN
> resolution, and (c) set up an IANA registry of r-component names and
> values.   Maybe also (d) explain how this is syntax compatible with
> 3986.  I think that's about enough for 2141bis.
>

I think that's considerably more than a hook, it's in danger of being a 
fishing expedition.

I might support (a) and (b), (d) is a requirement, but (c) is a real 
reach unless or until there's  (electronic) ink on (digital) paper for 
where to go with this idea, as a general idea, with consensus support.

Otherwise -- it's one person's great idea, and if you don't happen to 
finish writing it down, someone else will come along in a decade and 
fill it in very differently than anything you might ever have thought of 
(or that we, collectively, might have agreed to).


Leslie.

> (I'm thinking that I should suggest explicit text for this if for no
> other reason than that that exercise will give us a good idea of just
> how much would need to be added to 3986.)
>
> Separate from 2141bis, I'm thinking I might like to write up an
> Experimental or Informational document defining a simple URN resolution
> service and a client API for such a service.   (perhaps cribbing a bit
> from RFC 2483).   This simple service would define a minimal set of
> simple requests and the parameters for such requests.   The main purpose
> in doing so would be to serve as a proof-of-concept and to encourage
> further development in this area by the library community.
>
> And yes, the 2nd "?" would be part of the q-component if this were
> parsed according to 3986.   Given a URN
>
> *urn:example:something??a=b;c=d?mumble*
>
> a 3986-style parser would return
>
> {
>     "scheme": "urn",
>     "path": "example:something",
>     "query": "??a=b;c=d?mumble"
> }.
>
> However, it doesn't violate 3986 syntax, because "?" is explicitly
> permitted within .  (See RFC 3986, section 3.4, top of page 24)
>
> My take on this is that an ordinary URL parser shouldn't cause
> catastrophic failure (like causing the program to crash) with something
> that conforms to 3986 syntax.   Of course, most existing programs don't
> try to do URN resolution anyway, so their inability to parse URNs
> exactly like I'm proposing for 2141bis won't really do them much harm.
> By contrast, programs that support URN resolution in the future can
> parse them according to the 2141bis grammar, which would yield a result
> like:
>
> {
>     "scheme": "urn",
>     "namespace": "example",
>     "nss": "something",
>     "r-component": { "a": "b", "c": "d" },
>     "q-component": "mumble"
> }
>
>
>
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
ldaigle@thinkingcat.com
-------------------------------------------------------------------


From nobody Tue Apr 21 14:21:13 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E401B2B7D for ; Tue, 21 Apr 2015 14:21:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level: 
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hC9hvy96aEeD for ; Tue, 21 Apr 2015 14:21:02 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40D81B2B96 for ; Tue, 21 Apr 2015 14:20:29 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 510F3207E6 for ; Tue, 21 Apr 2015 17:20:29 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 21 Apr 2015 17:20:29 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=MKnZkDYVFzdcCn9 VVNXf4y805mw=; b=ck+tpEIWhv+mZfxVIZTHXDNazQKCCt9AA7SEcFE1W4g6xuH SV4dQWVStn8tRp82t0jX9jVff1TztNZYbhXPJdddq4sxDt4z4R0SIY2NbZ5lJEKK JQ1ERRRg3DAUnYbImt1xpSchHvUOqBjchk6mwnfCkTORsgtuYDNYU+fkLnZE=
X-Sasl-enc: edAar4ubvuKY7C8WpiwftGcZhTpl7+ygLIpD5bNipdDm 1429651229
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id EB988C0001C; Tue, 21 Apr 2015 17:20:28 -0400 (EDT)
Message-ID: <5536BEF9.4060603@network-heretics.com>
Date: Tue, 21 Apr 2015 17:19:53 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com> <552F15AD.2050405@andyet.net> <552F6234.4080509@network-heretics.com> <55317AA4.70105@thinkingcat.com> <55319FD5.1070404@network-heretics.com> <55367BBA.3020807@thinkingcat.com>
In-Reply-To: <55367BBA.3020807@thinkingcat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Apr 2015 21:21:08 -0000

On 04/21/2015 12:32 PM, Leslie Daigle (ThinkingCat) wrote:
>
> [Apologies for delayed/lost e-mail -- mail server issues. ]
>
> In-line...
>
> On 4/17/15 8:05 PM, Keith Moore wrote:
>> On 04/17/2015 05:27 PM, Leslie Daigle (ThinkingCat) wrote:
>>> Hi,
>>>
>>> Thinking through the r-component idea a bit...   I think your
>>> argumentation for r-components is pretty compelling, especially as we
>>> work to make clear why f-components don't fit that particular bill.
>>> However, I am more than a little concerned about getting too complex
>>> and bolting stuff on at this point.
>>>
>>> I won't argue that DDDS has been used for just about everything
>>> *except* providing the standard for URN resolution, but in working it
>>> out we I'm sure you recall we did did actually talk through
>>> "resolution services" (for ease of reference for anyone who missed it
>>> -- https://tools.ietf.org/html/rfc2483).
>>>
>>> Again, not quite what you are describing now (I read you to be
>>> thinking more about parameters one would send, not services one would
>>> request), but perhaps enough to illustrate that there is a whole farm
>>> of things one might wish to consider if one stops and thinks about
>>> using URNs in action.
>>>
>>> I think pursuing r-components as part of this document would slow this
>>> one down a fair bit.
>>>
>>> Is there a way to leave enough of a hook in the syntax to pursue
>>> r-component as a separate document?  (BTW...  does "??" actually fly
>>> with URI syntax, or wouldn't the 2nd "?" be part of the q-component?).
>>
>> "Leaving [just] enough of a hook" is exactly what I want to do in this
>> document.  I think that means:  (a) define the syntax for URNs including
>> that of r-components, (b) explain the role of r-components in URN
>> resolution, and (c) set up an IANA registry of r-component names and
>> values.   Maybe also (d) explain how this is syntax compatible with
>> 3986.  I think that's about enough for 2141bis.
>>
>
> I think that's considerably more than a hook, it's in danger of being 
> a fishing expedition.
>
> I might support (a) and (b), (d) is a requirement, but (c) is a real 
> reach unless or until there's  (electronic) ink on (digital) paper for 
> where to go with this idea, as a general idea, with consensus support.
>
> Otherwise -- it's one person's great idea, and if you don't happen to 
> finish writing it down, someone else will come along in a decade and 
> fill it in very differently than anything you might ever have thought 
> of (or that we, collectively, might have agreed to).

It's reasonable to want to look at actual text.   And we've certainly 
seen a lot of examples of people coming along in a decade and filling in 
things very differently than originally conceived, in this space.

Of course it's not the registry which is difficult to set up, it's the 
rules for what can go in the registry.

Keith


From nobody Wed Apr 22 23:03:30 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA751A8846 for ; Wed, 22 Apr 2015 23:03:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.6
X-Spam-Level: *
X-Spam-Status: No, score=1.6 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eZeMHYUPMd6 for ; Wed, 22 Apr 2015 23:03:22 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2751A8849 for ; Wed, 22 Apr 2015 23:02:58 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 9312F2097C for ; Thu, 23 Apr 2015 02:02:57 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 23 Apr 2015 02:02:57 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=bu /lvN47R/nWm8QVbyCnDbCxgNw=; b=pq9Jy/XiVnrvkfiyZl1xLJzCzJsuHkXn5a Qdrd6EXN+WpIdBUdebl6K3tgMYWgJRWY40H8wW35OrRwhfj9PV+fpGsKKJMtMGlW aSrcLO5cbkzt2rf6v49ufvanw3wJeMpLxhZy+wpLgm8tR3z6wDe8nHp47FZZSvNB nL32NNRH8=
X-Sasl-enc: YqbxFBuX/MTKEYzg8M6mRBYNPElxh0Ekpgn33FshKOyy 1429768977
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id ECF51C00016; Thu, 23 Apr 2015 02:02:56 -0400 (EDT)
Message-ID: <55388B0E.3080806@network-heretics.com>
Date: Thu, 23 Apr 2015 02:02:54 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "urn@ietf.org" 
Content-Type: multipart/alternative; boundary="------------010400040901040802030304"
Archived-At: 
Subject: [urn] suggested text changes for -12 on p-components, f- and q-components in URN resolution, and relative references
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Apr 2015 06:03:29 -0000

This is a multi-part message in MIME format.
--------------010400040901040802030304
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Here are my suggestions for changes to draft-ietf-urnbis-rfc2141bis-11 
based on last Friday's conference call.

I will try to also suggest text for r-components in a separate message, 
hopefully sometime tomorrow.  If I don't get it out by tomorrow it will 
be early next week.


I. p-components

If we have consensus that (a) relative references in resources named by 
URNs are always evaluated with respect to a base URI that is not a URN, 
and (b) there's no special need for URNs to be able to contain "paths", 
then we have several choices:

(a) Disallow p-components in the 2141bis grammar, OR
(b) Allow p-components in the 2141bis grammar, but reserve them for 
future use.   basically this means that parsers would recognize 
p-components, and p-components would be transmitted to resolution 
services, but namespaces shouldn't assign names containing p-components 
until a standards-track document explains how to do so, OR
(c) Permit "/" in NSS arbitrarily without giving any special 
significance to them.

Any of these seem workable but I lean toward either (a) or (c) - maybe a 
bit more toward (c) because I suspect there are namespaces that assign 
names containing "/" which could more easily be URN namespaces if "/" 
did not need to be %-encoded.

(I don't think that (c) breaks RFC 3986 compatibility because that 
"path" component of a URN (according to the 3986 grammar) never begins 
with "/" because a namespace never begins with a "/".   The 
namespace:NSS portion of a URN always matches "path-rootless", and 
"path-rootless" can containing an arbitrary number of "/"s in a row 
because "segment" is defined to be zero or more "pchar"s.   See RFC 3986 
mostly section 3.3)

Since there are three choices, I'm supplying three sets of changes, 
color-coded to hopefully minimize confusion as one scrolls back and 
forth through the message.   Pick only one :)   Note that in all cases 
the new text is shorter than the old; I take that as a favorable sign.

Option (a): Disallow p-components in the 2141bis grammar

Section 3

OLD:

       namestring    = assigned-name
                       [ q-component ]
                       [ f-component ]
       assigned-name = "urn" ":" NID ":" NSS [ p-component ]
       NID           = (alphanum) 0*30(ldh) (alphanum)
       ldh           = alphanum / "-"
       NSS           = 1*(pchar)
       p-component   = "/" path-absolute
       q-component   = "?" query
       f-component   = "#" fragment

    Note that "/" can be used without percent-encoding inside
    p-components and that "?" can be used without percent-encoding inside
    q-components and f-components.

NEW:

       namestring    = assigned-name
                       [ q-component ]
                       [ f-component ]
       assigned-name = "urn" ":" NID ":" NSS
       NID           = (alphanum) 0*30(ldh) (alphanum)
       ldh           = alphanum / "-"
       NSS           = 1*(pchar)
       q-component   = "?" query
       f-component   = "#" fragment

    Note that "?" can be used without percent-encoding inside
    q-components and f-components.

Section 3.3

OLD

3.3.  p-component, q-component, and f-component

    The p-component, q-component, and f-component are optional components
    that follow the assigned-name.  In terms of URI syntax these
    components are essentially equivalent to the URI "path-absolute",
    "query", and "fragment" constructions, respectively. However, the
    URN p-component, q-component, and f-component need not be
    semantically equivalent to the URI path component, query component,
    and fragment component; therefore they are called by different names
    in this specification.

    Unless specifically defined for a particular namespace after
    publication of this document, use of these components is disallowed,
    thereby maintaining strict backward compatibility with namespaces
    defined in accordance with [RFC2141] and registered in accordance
    with [RFC3406].

    This specification does not define the semantics of the p-component,
    q-component, and f-component for URNs in general. Instead,
    additional specifications might establish these matters for URN-
    related services (such as URN resolution) or for individual URN
    namespaces (e.g., to handle extended information about the resource
    identified by a URN).  For example, it is possible that the
    q-component might be used in requests to URN resolution services, or
    that the f-component might be used to distinguish the integral parts
    of resources named by URNs in particular namespaces (say, the
    chapters of a book).  However, defining such usage is the
    responsibility of specifications for URN resolution services,
    namespace registration requests and specifications for individual
    namespaces, and other appropriate documentation (such as policy
    documents governing the management of a given URN namespace).

    As general guidance that might not apply to all cases, it would be
    inappropriate for namespaces that do not intend to support resolution
    services to allow q-components.  Namespaces that deal with digital
    manifestations might be able to support f-components. At the time of
    writing, no general guidance can be provided for use of p-components.

NEW

3.3.  q-component and f-component

    The q-component and f-component are optional componentsthat follow
    the assigned-name.  In terms of URI syntax thesecomponents are
    essentially equivalent to the URI"query", and "fragment"
    constructions, respectively.  However, thesemantics of the URN
    q-component and f-component are subtly different than the semantics
    of the generic URI equivalents, therefore they are called by
    different namesin this specification.

    Note: URN syntax provides no equivalent to the "path" component of
    a generic URI.

    See section [TBD.A] for a description on how the URN q-component
    and f-component affect resolution of a URN, and section [TBD.B] for
    how relative references are evaluated with respect to a URN.


Section 3.3.1 (delete)

Section 4.1

OLD:

    If a p-component is included in a URN, it MUST be identical
    (including case sensitivity) in the strings being compared.

NEW: (delete this paragraph)

Section 4.2

(delete examples using "/" in NSS, whether or not percent-encoded)

Section 7.3.2

OLD:

    3.  If p-components, q-components, and/or f-components are allowed
        for the namespace, a discussion of how they are used.


NEW: (delete this paragraph. use or handling of f-components and 
q-components should not be namespace-specific)


Option (b):  Allow p-components in the 2141bis grammar, but reserve them 
for future use.

OLD:

3.3.  p-component, q-component, and f-component

    The p-component, q-component, and f-component are optional components
    that follow the assigned-name.  In terms of URI syntax these
    components are essentially equivalent to the URI "path-absolute",
    "query", and "fragment" constructions, respectively. However, the
    URN p-component, q-component, and f-component need not be
    semantically equivalent to the URI path component, query component,
    and fragment component; therefore they are called by different names
    in this specification.

    Unless specifically defined for a particular namespace after
    publication of this document, use of these components is disallowed,
    thereby maintaining strict backward compatibility with namespaces
    defined in accordance with [RFC2141] and registered in accordance
    with [RFC3406].

    This specification does not define the semantics of the p-component,
    q-component, and f-component for URNs in general. Instead,
    additional specifications might establish these matters for URN-
    related services (such as URN resolution) or for individual URN
    namespaces (e.g., to handle extended information about the resource
    identified by a URN).  For example, it is possible that the
    q-component might be used in requests to URN resolution services, or
    that the f-component might be used to distinguish the integral parts
    of resources named by URNs in particular namespaces (say, the
    chapters of a book).  However, defining such usage is the
    responsibility of specifications for URN resolution services,
    namespace registration requests and specifications for individual
    namespaces, and other appropriate documentation (such as policy
    documents governing the management of a given URN namespace).

    As general guidance that might not apply to all cases, it would be
    inappropriate for namespaces that do not intend to support resolution
    services to allow q-components.  Namespaces that deal with digital
    manifestations might be able to support f-components. At the time of
    writing, no general guidance can be provided for use of p-components.

NEW:

3.3.  p-component, q-component, and f-component

    The p-component, q-component, and f-component are optional components
    that follow the assigned-name.  In terms of URI syntax these
    components are essentially equivalent to the URI "path-absolute",
    "query", and "fragment" constructions, respectively. However, the
    URN p-component, q-component, and f-component are not
    semantically equivalent to the URI path component, query component,
    and fragment component; therefore they are called by different names
    in this specification.

See section [TBD.A] for a description on how the URN q-component
    and f-component affect resolution of a URN, and section [TBD.B] for
    how relative references are evaluated with respect to a URN.

    p-components are reserved for future use.  Implementations which
    recognize URNs MUST parse URNs according to the grammar described in
    this document, and MUST include the entire assigned portion of a URN
    (including any p-component) to a resolution service. However,
    namespaces MUST NOT assign URNs containing p-components. This
    restriction on use of p-components may be relaxed in a later 
specification.

section 3.3.1:

OLD

3.3.1.  p-component

    The only formal restriction placed upon a p-component by this
    specification is that the syntax SHALL adhere to the "path-absolute"
    rule from [RFC3986].  The specification for a particular namespace or
    URN-related service MAY define further syntax restrictions within the
    p-component.  (For example, a namespace specification might define a
    character such as "~" or "@" as a delimiter inside p-components
    assigned within that namespace.)  Note that characters outside the
    ASCII range [RFC20] MUST be percent-encoded using the method defined
    in Section 2.1 of the generic URI specification [RFC3986].

    Consider the hypothetical example of a hierarchical naming system in
    which the identifiers take the form of a series of numbers separated
    by the "/" character, such as "1/406/47452/2".  If the naming
    authority for such identifiers were to use URNs, it would be natural
    to place the existing identifiers in the p-component, resulting in
    URNs such as "urn:example/1/406/47452/2" (using the "example" URN
    namespace [RFC6963] instead of a registered NID).

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

NEW

[[Note:  Maybe I misunderstand, but I think the -11 text is incorrect in 
syntax even if we don't change the semantics of p-components at all.   
As I read 3986, the URI "path" corresponds to the URN namespace:NSS, so 
the "path" never begins with "/" and can never correspond to 
"path-absolute".   (Yes, we can reuse that production from the 3986 
grammar if we want to do so, but I see no reason to do so.)   And the 
example given in the next paragraph is also incorrect, because there 
would need to be a ":" after the namespace "example".]]

3.3.1.  p-component

    p-component is reserved for future use.  Namespaces MUST NOT assign
    URNs with p-components.  A future specification may permit
    p-components while possibly imposing other constraints on their use.

    However, software that recognizes URNs MUST parse URNs (including
    p-components) according to the grammar in this document, and MUST
    present the entire "assigned-name" portion of a URN to a resolution
    service when resolving the URN.

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

Section 7.3.2:

OLD

    3.  If p-components, q-components, and/or f-components are allowed
        for the namespace, a discussion of how they are used.

NEW:  (delete this.  use or interpretation of f- and q-components should 
not be namespace-specific)


Option (c): Permit "/" in NSS arbitrarily without giving any special 
significance to them.

Section 3:

OLD

       namestring    = assigned-name
                       [ q-component ]
                       [ f-component ]
       assigned-name = "urn" ":" NID ":" NSS [ p-component ]
       NID           = (alphanum) 0*30(ldh) (alphanum)
       ldh           = alphanum / "-"
       NSS           = 1*(pchar)
       p-component   = "/" path-absolute
       q-component   = "?" query
       f-component   = "#" fragment

    Note that "/" can be used without percent-encoding inside
    p-components and that "?" can be used without percent-encoding inside
    q-components and f-components.

NEW

       namestring    = assigned-name
                       [ q-component ]
                       [ f-component ]
       assigned-name = "urn" ":" NID ":" NSS
       NID           = (alphanum) 0*30(ldh) (alphanum)
       ldh           = alphanum / "-"
       NSS           = 1*(pchar / "/")
       q-component   = "?" query
       f-component   = "#" fragment

    Note that "?" can be used without percent-encoding inside
    q-components and f-components.

Section 3.3

OLD

3.3.  p-component, q-component, and f-component

    The p-component, q-component, and f-component are optional components
    that follow the assigned-name.  In terms of URI syntax these
    components are essentially equivalent to the URI "path-absolute",
    "query", and "fragment" constructions, respectively. However, the
    URN p-component, q-component, and f-component need not be
    semantically equivalent to the URI path component, query component,
    and fragment component; therefore they are called by different names
    in this specification.

    Unless specifically defined for a particular namespace after
    publication of this document, use of these components is disallowed,
    thereby maintaining strict backward compatibility with namespaces
    defined in accordance with [RFC2141] and registered in accordance
    with [RFC3406].

    This specification does not define the semantics of the p-component,
    q-component, and f-component for URNs in general. Instead,
    additional specifications might establish these matters for URN-
    related services (such as URN resolution) or for individual URN
    namespaces (e.g., to handle extended information about the resource
    identified by a URN).  For example, it is possible that the
    q-component might be used in requests to URN resolution services, or
    that the f-component might be used to distinguish the integral parts
    of resources named by URNs in particular namespaces (say, the
    chapters of a book).  However, defining such usage is the
    responsibility of specifications for URN resolution services,
    namespace registration requests and specifications for individual
    namespaces, and other appropriate documentation (such as policy
    documents governing the management of a given URN namespace).

    As general guidance that might not apply to all cases, it would be
    inappropriate for namespaces that do not intend to support resolution
    services to allow q-components.  Namespaces that deal with digital
    manifestations might be able to support f-components. At the time of
    writing, no general guidance can be provided for use of p-components.

NEW

3.3.  q-component and f-component

    The q-component and f-component are optional components
    that follow the assigned-name.  In terms of URI syntax these
    components are essentially equivalent to the URI
    "query", and "fragment" constructions, respectively. However, the
    URN  q-component, and f-component are not quite
    semantically equivalent to the URI query component
    and fragment component; therefore they are called by different names
    in this specification.

See section [TBD.A] for a description on how the URN q-component
    and f-component affect resolution of a URN, and section [TBD.B] for
    how relative references are evaluated with respect to a URN.

Section 3.3.1 (delete this section)

Section 4.1

OLD

    If a p-component is included in a URN, it MUST be identical
    (including case sensitivity) in the strings being compared.

NEW (delete this paragraph)

Section 4.2

(delete examples containing p-components and text referring to p-components)

Section 7.3.2

OLD

    3.  If p-components, q-components, and/or f-components are allowed
        for the namespace, a discussion of how they are used.

NEW (delete this item; f- and q-components should not be namespace-specific)


II. URN resolution

Notes:

1. My first cut at this said that a client MUST NOT include a 
q-component or f-component in a URN sent in a request to a resolution 
service.  Then I realized that a resolution service might in some 
circumstances provide access to resource content (say by caching it), or 
act as a proxy to a resource, in which circumstances interpreting the 
q-component might be appropriate.   So now the client MUST NOT include 
q-component or f-component unless it's requesting that the resolution 
service provide access to the resource itself, and the resolution 
service is supposed to ignore the q-component except when it needs to 
send it as a query to the resource, and to ignore the f-component.   But 
this bothers me somewhat, and I'd like for the rules to be simpler while 
still maintaining a layer separation between the resolution service and 
the resources which it names.   The simplest solution is probably to say 
that resolution services never provide access to resource content, only 
to locations and metadata.  However, it's long been expected that 
resolution services could provide access to resource content.

2. Lars Svensson pointed out to me in private mail that a resolution 
service could potentially return a URL with query and/or fragment, so 
this text takes a position on how to interpret such a URL when the 
original URN also had an q-component and/or f-component.   I thought it 
made more sense to ignore those components from the original URN in that 
case.   There are other positions that could be taken, e.g. that 
resolution services should not be permitted to return URLs with queries 
and/or fragments, but I actually think it can be reasonable for them to 
do so.


(new section.  note: text in brackets/italics about r-components should 
only be included if r-component proposal is adopted)

TBD.A. Use of f- and q-components in URN resolution

Since a URN, by design, does not contain either explicitly or implicitly 
the name or address of a network service which can be used to access the 
resource named by the URN, an application wishing to access that 
resource must somehow discover one or more "resolution services" which 
can, given the URN, either provide the resource content directly, or 
provide information to the application to enable it to access the resource.

Though f- and q-components may appear in a URN, they are not assigned or 
managed by the URN namespace, but instead evaluated in the context of 
the named resource.   Specifically, an f-component of a URN refers to a 
"fragment" of the resource named by the URN, and a q-component of a URN 
is used to specify a "query" to be evaluated by the resource named by 
the URN.   This convention ensures consistent use of these components 
across all URN namespaces, and preserves the ability to reference 
"fragments" of resources named by URNs that have fragments, and to 
specify "queries" with resources named by URNs that support queries.   
In order to preserve this ability, f-components and q-components MUST 
NOT be transmitted to a URN resolution service except when that service 
is being requested to provide direct access (or access via proxy) to the 
resource itself.   For all other requests, the client MUST transmit only 
the "assigned-part" of a URN /[ along with any r-component//, if 
specified ]/ to the URN resolution service.

A resolution service processing a request for a URN MUST ignore any 
f-component or q-component of that URN unless the request is to provide 
direct access (or access via proxy) to the named resource.   If the 
request is to provide access to the named resource (as opposed to, say, 
resource locations or resource metadata), the resolution service MUST 
ignore the f-component of the URN and SHOULD (if possible) process the 
q-component as if it were a query transmitted to the resource, returning 
the resource's response to that query.  If the resolution service cannot 
provide the requested access to the resource, but instead returns 
resource locations, the f-component and q-component of the request URN 
MUST be ignored in determining these locations, and MUST NOT be included 
as fragment and query (respectively) in the returned locations.

These rules are intended to impose a layer separation between the URN 
resolution service and the content, and to discourage the URN resolution 
service from returning different results depending on the presence of f- 
and/or q-components in the request.

If the resource named by a URN that contains an f- and/or q-component is 
accessed via an intermediate URI (other than a URN) obtained from a 
resolution service, and that intermediate URI contains neither a 
fragment nor a query, the q-component (if present) is appended to the 
intermediate URI as a query, and the f-component (if present) is 
appended to the intermediate URI as a fragment (in that order).  The 
resulting URI is then processed according to RFC 3986.

Example: If the URN urn:example:foo?bar#zot appears in a link, the 
client application might transmit the assigned-part of that URN 
(urn:example:foo) to a resolution service with a request for resource 
locations.   The resolution service might then return the intermediate 
URI http://example.com/whatnot/xyzzy as one of those locations.   The 
client would then append ?bar#zot to that intermediate URI producing 
http://example.com/whatnot/xyzzy?bar#zot .   This URI would then be 
processed per normal RFC 3986 rules.

A resolution service MAY return an intermediate URI which contains a 
fragment and/or a query.   If the intermediate URI contains a fragment 
or a query, any f- or q-component from the URN is ignored.   (This 
situation is basically no different than anyone composing a URI from a 
base URI plus a fragment and/or query without being aware of what 
fragments and/or queries are valid in the context of the named 
resource.   Any user or document author may combine URIs with arbitrary 
queries and/or fragments, but that doesn't mean that the results will do 
what the user or author intended.)

Example: If the URN urn:example:foo?bar#zot appeared in a link, a 
resolution service might be requested to return locations of the URN 
urn:example:foo .  If such a service returned an intermediate URI 
http://example.com/whatnot/xyzzy?abcde , neither the q-component ?bar 
nor the f-component #zot would be appended to the intermediate URI 
before processing it.

If the content of a resource named by a URN containing an f-component is 
obtained directly from a resolution service, the f-component SHOULD be 
treated as a "fragment" and evaluated with respect to that content, just 
as if the content had been obtained from any other service.

III. Relative References

(new section)

TBD.B. URNs and Relative References

RFC 3986 section 5.2 describes an algorithm for converting a URI 
reference that might be relative to a given base URI into "parsed 
components" of the target of that reference, which can then be 
recomposed per RFC 3986 section 5.3 into a target URI. If this algorithm 
were applied directly to URNs, it would pragmatically have the effect of 
imposing additional constraints on the naming of URNs containing 
p-components, in order that relative references contained in the 
resources named by those URNs would not break.  Alternatively, resources 
named with URNs could be forbidden to contain relative references.   
Neither of those alternatives seems attractive.   In addition, if the 
same resources are accessible by both URN and URL, it is desirable to 
permit relative references to work correctly in either case.

Therefore a relative reference SHOULD NOT be evaluated with respect to a 
URN.   Instead, a relative reference SHOULD be evaluated with respect to 
either

(a) a BASE URI (other than a URN) declared by the resource itself, OR
(b) a BASE URI (other than a URN) obtained through the URN resolution 
process, OR
(c) the URL of the resource as obtained through the URN resolution process

(Case (b) permits the resolution process to explicitly supply a BASE URI 
if the resource content is supplied directly by the resolution service 
rather than via an intermediate "location" URI.)

If no such BASE URI exists, use of a relative reference with respect to 
a URN is an error.

Resolution services SHOULD ensure that a BASE URI is supplied any time 
they provide resource content directly to a client.





--------------010400040901040802030304
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    Here are my suggestions for changes to
    draft-ietf-urnbis-rfc2141bis-11 based on last Friday's conference
    call.

    

    I will try to also suggest text for r-components in a separate
    message, hopefully sometime tomorrow.  If I don't get it out by
    tomorrow it will be early next week.

    

    

    I. p-components

    

    If we have consensus that (a) relative references in resources named
    by URNs are always evaluated with respect to a base URI that is not
    a URN, and (b) there's no special need for URNs to be able to
    contain "paths", then we have several choices:

    

    (a) Disallow p-components in the 2141bis grammar, OR

    (b) Allow p-components in the 2141bis grammar, but reserve them for
    future use.   basically this means that parsers would recognize
    p-components, and p-components would be transmitted to resolution
    services, but namespaces shouldn't assign names containing
    p-components until a standards-track document explains how to do so,
    OR

    (c) Permit "/" in NSS arbitrarily without giving any special
    significance to them.  

    

    Any of these seem workable but I lean toward either (a) or (c) -
    maybe a bit more toward (c) because I suspect there are namespaces
    that assign names containing "/" which could more easily be URN
    namespaces if "/" did not need to be %-encoded.

    

    (I don't think that (c) breaks RFC 3986 compatibility because that
    "path" component of a URN (according to the 3986 grammar) never
    begins with "/" because a namespace never begins with a "/".   The
    namespace:NSS portion of a URN always matches "path-rootless", and
    "path-rootless" can containing an arbitrary number of "/"s in a row
    because "segment" is defined to be zero or more "pchar"s.   See RFC
    3986 mostly section 3.3)

    

    Since there are three choices, I'm supplying three sets of changes,
    color-coded to hopefully minimize confusion as one scrolls back and
    forth through the message.   Pick only one :)   Note that in all
    cases the new text is shorter than the old; I take that as a
    favorable sign.

    

    Option (a): Disallow p-components in the
      2141bis grammar

    

    Section 3

      

      OLD:

      

            namestring    = assigned-name

                            [ q-component ]

                            [ f-component ]

            assigned-name = "urn" ":" NID ":" NSS [ p-component
        ]

            NID           = (alphanum) 0*30(ldh) (alphanum)

            ldh           = alphanum / "-"

            NSS           = 1*(pchar)

            p-component   = "/" path-absolute

            q-component   = "?" query

            f-component   = "#" fragment

      

         Note that "/" can be used without percent-encoding inside

         p-components and that "?" can be used without
        percent-encoding inside

         q-components and f-components.

      

      NEW:

      

            namestring    = assigned-name

                            [ q-component ]

                            [ f-component ]

            assigned-name = "urn" ":" NID ":" NSS

            NID           = (alphanum) 0*30(ldh) (alphanum)

            ldh           = alphanum / "-"

            NSS           = 1*(pchar)

            q-component   = "?" query

            f-component   = "#" fragment

      

         Note that "?" can be used without
        percent-encoding inside

         q-components and f-components.

      

      Section 3.3

      

      OLD

      

      3.3.  p-component, q-component, and f-component

      

         The p-component, q-component, and f-component are
        optional components

         that follow the assigned-name.  In terms of URI syntax
        these

         components are essentially equivalent to the URI
        "path-absolute",

         "query", and "fragment" constructions, respectively. 
        However, the

         URN p-component, q-component, and f-component need not
        be

         semantically equivalent to the URI path component,
        query component,

         and fragment component; therefore they are called by
        different names

         in this specification.

      

         Unless specifically defined for a particular namespace
        after

         publication of this document, use of these components
        is disallowed,

         thereby maintaining strict backward compatibility with
        namespaces

         defined in accordance with [RFC2141] and registered in
        accordance

         with [RFC3406].

      

         This specification does not define the semantics of
        the p-component,

         q-component, and f-component for URNs in general. 
        Instead,

         additional specifications might establish these
        matters for URN-

         related services (such as URN resolution) or for
        individual URN

         namespaces (e.g., to handle extended information about
        the resource

         identified by a URN).  For example, it is possible
        that the

         q-component might be used in requests to URN
        resolution services, or

         that the f-component might be used to distinguish the
        integral parts

         of resources named by URNs in particular namespaces
        (say, the

         chapters of a book).  However, defining such usage is
        the

         responsibility of specifications for URN resolution
        services,

         namespace registration requests and specifications for
        individual

         namespaces, and other appropriate documentation (such
        as policy

         documents governing the management of a given URN
        namespace).

      

         As general guidance that might not apply to all cases,
        it would be

         inappropriate for namespaces that do not intend to
        support resolution

         services to allow q-components.  Namespaces that deal
        with digital

         manifestations might be able to support f-components. 
        At the time of

         writing, no general guidance can be provided for use
        of p-components.

      

      NEW

      

      3.3.  q-component and f-component

      

         The q-component and f-component are optional
        components that follow 

           the assigned-name.  In terms of URI syntax these
        components are 

           essentially equivalent to the URI "query", and
        "fragment" 

           constructions, respectively.  However, the semantics
        of the URN 

           q-component and f-component are subtly different than the
        semantics 

           of the generic URI equivalents, therefore they are
        called by 

           different names in this specification.   

        

           Note: URN syntax provides no equivalent to the "path"
        component of 

           a generic URI.

        

         See section [TBD.A] for a description on how the URN
        q-component 

           and f-component affect resolution of a URN, and section
        [TBD.B] for

           how relative references are evaluated with respect to a URN.

        

         

      Section 3.3.1 (delete)

      

      Section 4.1

      

      OLD:

      

       If a p-component is included in
        a URN, it MUST be identical

         (including case sensitivity) in the strings being
        compared.

      

      NEW: (delete this paragraph)

      

      Section 4.2

      

      (delete examples using "/" in NSS, whether or not percent-encoded)

      

      Section 7.3.2

      

      OLD:

      

       3.  If p-components,
        q-components, and/or f-components are allowed

             for the namespace, a discussion of how they are
        used.

      

      

      NEW: (delete this paragraph.  
      use or handling of f-components and q-components should not be
      namespace-specific)

    

    

    Option (b):  Allow p-components in the 2141bis
      grammar, but reserve them for future use. 

      

      OLD:

      

    3.3.  p-component, q-component, and
        f-component

      

         The p-component, q-component, and f-component are
        optional components

         that follow the assigned-name.  In terms of URI syntax
        these

         components are essentially equivalent to the URI
        "path-absolute",

         "query", and "fragment" constructions, respectively. 
        However, the

         URN p-component, q-component, and f-component need not
        be

         semantically equivalent to the URI path component,
        query component,

         and fragment component; therefore they are called by
        different names

         in this specification.

      

         Unless specifically defined for a particular namespace
        after

         publication of this document, use of these components
        is disallowed,

         thereby maintaining strict backward compatibility with
        namespaces

         defined in accordance with [RFC2141] and registered in
        accordance

         with [RFC3406].

      

         This specification does not define the semantics of
        the p-component,

         q-component, and f-component for URNs in general. 
        Instead,

         additional specifications might establish these
        matters for URN-

         related services (such as URN resolution) or for
        individual URN

         namespaces (e.g., to handle extended information about
        the resource

         identified by a URN).  For example, it is possible
        that the

         q-component might be used in requests to URN
        resolution services, or

         that the f-component might be used to distinguish the
        integral parts

         of resources named by URNs in particular namespaces
        (say, the

         chapters of a book).  However, defining such usage is
        the

         responsibility of specifications for URN resolution
        services,

         namespace registration requests and specifications for
        individual

         namespaces, and other appropriate documentation (such
        as policy

         documents governing the management of a given URN
        namespace).

      

         As general guidance that might not apply to all cases,
        it would be

         inappropriate for namespaces that do not intend to
        support resolution

         services to allow q-components.  Namespaces that deal
        with digital

         manifestations might be able to support f-components. 
        At the time of

         writing, no general guidance can be provided for use
        of p-components.

      

      NEW:

      

      3.3.  p-component, q-component, and f-component

      

         The p-component, q-component, and f-component are
        optional components

         that follow the assigned-name.  In terms of URI syntax
        these

         components are essentially equivalent to the URI
        "path-absolute",

         "query", and "fragment" constructions, respectively. 
        However, the

         URN p-component, q-component, and f-component are not

         semantically equivalent to the URI path component,
        query component,

         and fragment component; therefore they are called by
        different names

         in this specification.

      

         See section [TBD.A] for a description on how
        the URN q-component 

           and f-component affect resolution of a URN, and section
        [TBD.B] for

           how relative references are evaluated with respect to a URN.

        

           p-components are reserved for future use.  Implementations
        which 

           recognize URNs MUST parse URNs according to the grammar
        described in 

           this document, and MUST include the entire assigned portion
        of a URN

           (including any p-component) to a resolution service.  
        However, 

           namespaces MUST NOT assign URNs containing p-components.  
        This

           restriction on use of p-components may be relaxed in a later
        specification.

      

      section 3.3.1:

      

      OLD

      

    3.3.1.  p-component

      

         The only formal restriction placed upon a p-component
        by this

         specification is that the syntax SHALL adhere to the
        "path-absolute"

         rule from [RFC3986].  The specification for a
        particular namespace or

         URN-related service MAY define further syntax
        restrictions within the

         p-component.  (For example, a namespace specification
        might define a

         character such as "~" or "@" as a delimiter inside
        p-components

         assigned within that namespace.)  Note that characters
        outside the

         ASCII range [RFC20] MUST be percent-encoded using the
        method defined

         in Section 2.1 of the generic URI specification
        [RFC3986].

      

         Consider the hypothetical example of a hierarchical
        naming system in

         which the identifiers take the form of a series of
        numbers separated

         by the "/" character, such as "1/406/47452/2".  If the
        naming

         authority for such identifiers were to use URNs, it
        would be natural

         to place the existing identifiers in the p-component,
        resulting in

         URNs such as "urn:example/1/406/47452/2" (using the
        "example" URN

         namespace [RFC6963] instead of a registered NID).

      

         As described under Section 4, the p-component SHALL be
        taken into

         account when determining URN equivalence.

      

      NEW

      

      [[Note:  Maybe I misunderstand, but I think the -11 text is
      incorrect in syntax even if we don't change the semantics of
      p-components at all.   As I read 3986, the URI "path" corresponds
      to the URN namespace:NSS, so the "path" never begins with "/" and
      can never correspond to "path-absolute".   (Yes, we can reuse that
      production from the 3986 grammar if we want to do so, but I see no
      reason to do so.)   And the example given in the next paragraph is
      also incorrect, because there would need to be a ":" after the
      namespace "example".]]

      

    3.3.1.  p-component

      

         p-component is reserved for future use.
          Namespaces MUST NOT assign

         URNs with p-components.  A future specification may
        permit

           p-components while possibly imposing other constraints on
        their use.

      

         However, software that recognizes URNs MUST parse URNs
        (including

           p-components) according to the grammar in this document, and
        MUST

           present the entire "assigned-name" portion of a URN to a resolution

           service when resolving the URN.

        

           As described under Section 4, the p-component SHALL be taken
        into

         account when determining URN equivalence.

    

      Section 7.3.2:

      

      OLD

      

       3.  If p-components,
        q-components, and/or f-components are allowed

             for the namespace, a discussion of how they are
        used.

      

      NEW:  (delete this.  use or interpretation of f- and q-components
      should not be namespace-specific)

      

      

      Option (c):   Permit "/" in NSS arbitrarily without giving any
      special significance to them.  

      

      Section 3:

      

      OLD

      

            namestring    = assigned-name

                            [ q-component ]

                            [ f-component ]

            assigned-name = "urn" ":" NID ":" NSS [ p-component
        ]

            NID           = (alphanum) 0*30(ldh) (alphanum)

            ldh           = alphanum / "-"

            NSS           = 1*(pchar)

            p-component   = "/" path-absolute

            q-component   = "?" query

            f-component   = "#" fragment

      

         Note that "/" can be used without percent-encoding
        inside

         p-components and that "?" can be used without
        percent-encoding inside

         q-components and f-components.

      

      NEW

      

            namestring    = assigned-name

                            [ q-component ]

                            [ f-component ]

            assigned-name = "urn" ":" NID ":" NSS

            NID           = (alphanum) 0*30(ldh) (alphanum)

            ldh           = alphanum / "-"

            NSS           = 1*(pchar / "/")

            q-component   = "?" query

            f-component   = "#" fragment

      

         Note that "?" can be used without
        percent-encoding inside

         q-components and f-components.

    

    Section 3.3

      

      OLD

    

      3.3.  p-component, q-component, and f-component

      

         The p-component, q-component, and f-component are
        optional components

         that follow the assigned-name.  In terms of URI syntax
        these

         components are essentially equivalent to the URI
        "path-absolute",

         "query", and "fragment" constructions, respectively. 
        However, the

         URN p-component, q-component, and f-component need not
        be

         semantically equivalent to the URI path component,
        query component,

         and fragment component; therefore they are called by
        different names

         in this specification.

      

         Unless specifically defined for a particular namespace
        after

         publication of this document, use of these components
        is disallowed,

         thereby maintaining strict backward compatibility with
        namespaces

         defined in accordance with [RFC2141] and registered in
        accordance

         with [RFC3406].

      

         This specification does not define the semantics of
        the p-component,

         q-component, and f-component for URNs in general. 
        Instead,

         additional specifications might establish these
        matters for URN-

         related services (such as URN resolution) or for
        individual URN

         namespaces (e.g., to handle extended information about
        the resource

         identified by a URN).  For example, it is possible
        that the

         q-component might be used in requests to URN
        resolution services, or

         that the f-component might be used to distinguish the
        integral parts

         of resources named by URNs in particular namespaces
        (say, the

         chapters of a book).  However, defining such usage is
        the

         responsibility of specifications for URN resolution
        services,

         namespace registration requests and specifications for
        individual

         namespaces, and other appropriate documentation (such
        as policy

         documents governing the management of a given URN
        namespace).

      

         As general guidance that might not apply to all cases,
        it would be

         inappropriate for namespaces that do not intend to
        support resolution

         services to allow q-components.  Namespaces that deal
        with digital

         manifestations might be able to support f-components. 
        At the time of

         writing, no general guidance can be provided for use
        of p-components.

      

      NEW

      

    3.3.  q-component and f-component

      

         The q-component and f-component are optional
        components

         that follow the assigned-name.  In terms of URI syntax
        these

         components are essentially equivalent to the URI 

         "query", and "fragment" constructions, respectively. 
        However, the

         URN  q-component, and f-component are not quite

         semantically equivalent to the URI query component

         and fragment component; therefore they are called by
        different names

         in this specification.

      

         See section [TBD.A] for a description on
          how the URN q-component 

             and f-component affect resolution of a URN, and section
          [TBD.B] for

             how relative references are evaluated with respect to a
          URN.

        

      Section 3.3.1 (delete this section)

      

      Section 4.1

      

      OLD

      

         If a p-component is included in a URN, it MUST be identical

         (including case sensitivity) in the strings being
        compared.

      

      NEW (delete this paragraph)

      

      Section 4.2

      

      (delete examples containing p-components and text referring to
      p-components)

      

      Section 7.3.2

      

      OLD

      

         3.  If p-components, q-components, and/or f-components are
        allowed

             for the namespace, a discussion of how they are
        used.

      

      NEW (delete this item; f- and q-components should not be
      namespace-specific)

    

    

    II. URN resolution 

    

    Notes: 

    

    1. My first cut at this said that a client MUST NOT include a
    q-component or f-component in a URN sent in a request to a
    resolution service.  Then I realized that a resolution service might
    in some circumstances provide access to resource content (say by
    caching it), or act as a proxy to a resource, in which circumstances
    interpreting the q-component might be appropriate.   So now the
    client MUST NOT include q-component or f-component unless it's
    requesting that the resolution service provide access to the
    resource itself, and the resolution service is supposed to ignore
    the q-component except when it needs to send it as a query to the
    resource, and to ignore the f-component.   But this bothers me
    somewhat, and I'd like for the rules to be simpler while still
    maintaining a layer separation between the resolution service and
    the resources which it names.   The simplest solution is probably to
    say that resolution services never provide access to resource
    content, only to locations and metadata.  However, it's long been
    expected that resolution services could provide access to resource
    content.

    

    2. Lars Svensson pointed out to me in private mail that a resolution
    service could potentially return a URL with query and/or fragment,
    so this text takes a position on how to interpret such a URL when
    the original URN also had an q-component and/or f-component.   I
    thought it made more sense to ignore those components from the
    original URN in that case.   There are other positions that could be
    taken, e.g. that resolution services should not be permitted to
    return URLs with queries and/or fragments, but I actually think it
    can be reasonable for them to do so.

    

    

    (new section.  note: text in brackets/italics about r-components
    should only be included if r-component proposal is adopted)

    

    TBD.A. Use of f- and q-components in URN resolution

      

      Since a URN, by design, does not contain either explicitly or
      implicitly the name or address of a network service which can be
      used to access the resource named by the URN, an application
      wishing to access that resource must somehow discover one or more
      "resolution services" which can, given the URN, either provide the
      resource content directly, or provide information to the
      application to enable it to access the resource.

      

      Though f- and q-components may appear in a URN, they are not
      assigned or managed by the URN namespace, but instead evaluated in
      the context of the named resource.   Specifically, an f-component
      of a URN refers to a "fragment" of the resource named by the URN,
      and a q-component of a URN is used to specify a "query" to be
      evaluated by the resource named by the URN.   This convention
      ensures consistent use of these components across all URN
      namespaces, and preserves the ability to reference "fragments" of
      resources named by URNs that have fragments, and to specify
      "queries" with resources named by URNs that support queries.   In
      order to preserve this ability, f-components and q-components MUST
      NOT be transmitted to a URN resolution service except when that
      service is being requested to provide direct access (or access via
      proxy) to the resource itself.   For all other requests, the
      client MUST transmit only the "assigned-part" of a URN [ along
        with any r-component, if specified ] to the URN
      resolution service.  

      

      A resolution service processing a request for a URN MUST ignore
      any f-component or q-component of that URN unless the request is
      to provide direct access (or access via proxy) to the named
      resource.   If the request is to provide access to the named
      resource (as opposed to, say, resource locations or resource
      metadata), the resolution service MUST ignore the f-component of
      the URN and SHOULD (if possible) process the q-component as if it
      were a query transmitted to the resource, returning the resource's
      response to that query.  If the resolution service cannot provide
      the requested access to the resource, but instead returns resource
      locations, the f-component and q-component of the request URN MUST
      be ignored in determining these locations, and MUST NOT be
      included as fragment and query (respectively) in the returned
      locations.

      

      These rules are intended to impose a layer separation between the
      URN resolution service and the content, and to discourage the URN
      resolution service from returning different results depending on
      the presence of f- and/or q-components in the request.   

      

      If the resource named by a URN that contains an f- and/or
      q-component is accessed via an intermediate URI (other than a URN)
      obtained from a resolution service, and that intermediate URI
      contains neither a fragment nor a query, the q-component (if
      present) is appended to the intermediate URI as a query, and the
      f-component (if present) is appended to the intermediate URI as a
      fragment (in that order).  The resulting URI is then processed
      according to RFC 3986.

      

      Example: If the URN urn:example:foo?bar#zot appears in a link, the
      client application might transmit the assigned-part of that URN
      (urn:example:foo) to a resolution service with a request for
      resource locations.   The resolution service might then return the
      intermediate URI http://example.com/whatnot/xyzzy as one of those
      locations.   The client would then append ?bar#zot to that
      intermediate URI producing
      http://example.com/whatnot/xyzzy?bar#zot .   This URI would then
      be processed per normal RFC 3986 rules.

      

    A resolution service MAY return an intermediate URI
        which contains a fragment and/or a query.   If the intermediate
        URI contains a fragment or a query, any f- or q-component from
        the URN is ignored.   (This situation is basically no different
        than anyone composing a URI from a base URI plus a fragment
        and/or query without being aware of what fragments and/or
        queries are valid in the context of the named resource.   Any
        user or document author may combine URIs with arbitrary queries
        and/or fragments, but that doesn't mean that the results will do
        what the user or author intended.)

        

      Example: If the URN urn:example:foo?bar#zot appeared in a
      link, a resolution service might be requested to return locations
      of the URN urn:example:foo .  If such a service returned an
      intermediate URI http://example.com/whatnot/xyzzy?abcde , neither
      the q-component ?bar nor the f-component #zot would be appended to
      the intermediate URI before processing it.

      

      If the content of a resource named by a URN containing an
      f-component is obtained directly from a resolution service, the
      f-component SHOULD be treated as a "fragment" and evaluated with
      respect to that content, just as if the content had been obtained
      from any other service.

    

    III. Relative References

    

    (new section)

    

    TBD.B. URNs and Relative References

    

    RFC 3986 section 5.2 describes an algorithm for converting
      a URI reference that might be relative to a given base URI into
      "parsed components" of the target of that reference, which can
      then be recomposed per RFC 3986 section 5.3 into a target URI.  
      If this algorithm were applied directly to URNs, it would
      pragmatically have the effect of imposing additional constraints
      on the naming of URNs containing p-components, in order that
      relative references contained in the resources named by those URNs
      would not break.  Alternatively, resources named with URNs could
      be forbidden to contain relative references.   Neither of those
      alternatives seems attractive.   In addition, if the same
      resources are accessible by both URN and URL, it is desirable to
      permit relative references to work correctly in either case. 

    

    Therefore a relative reference SHOULD NOT be evaluated with
      respect to a URN.   Instead, a relative reference SHOULD be
      evaluated with respect to either

      

      (a) a BASE URI (other than a URN) declared by the resource itself,
      OR

      (b) a BASE URI (other than a URN) obtained through the URN
      resolution process, OR

      (c) the URL of the resource as obtained through the URN resolution
      process

      

      (Case (b) permits the resolution process to explicitly supply a
      BASE URI if the resource content is supplied directly by the
      resolution service rather than via an intermediate "location" URI.)

      

      If no such BASE URI exists, use of a relative reference with
      respect to a URN is an error. 

      

      Resolution services SHOULD ensure that a BASE URI is supplied any
      time they provide resource content directly to a client.

      

      

      

      

    
  


--------------010400040901040802030304--


From nobody Thu Apr 23 08:21:46 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F461A8A0B for ; Thu, 23 Apr 2015 08:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.544
X-Spam-Level: ***
X-Spam-Status: No, score=3.544 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, MANGLED_OFF=2.3, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSOes8pJNhIn for ; Thu, 23 Apr 2015 08:21:39 -0700 (PDT)
Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB111A8A73 for ; Thu, 23 Apr 2015 08:21:39 -0700 (PDT)
Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id B5D5C6B0087; Thu, 23 Apr 2015 08:21:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= thinkingcat.com; bh=AQB6jShex6UBalRZ1sLK1iE4uKs=; b=FDfDwFKENrjT z6eWlgu/h0TjgeQE0Ra5yB8Nu+PxfWl+BHE9qvr5X2Vcdqx+tGL94wiiizdAntwI 7WpvcxNOX/EJ0y3aNfpm8zbDyKUNRKlzqAjuvMa2u2HIdnVulU1FmwjRGS/sxfuX VPymzp31VEWLZLPOb7AesP6pagGTceE=
Received: from aran-w.int.lexiconix.com (pool-108-44-246-138.clppva.fios.verizon.net [108.44.246.138]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id B7EEA6B0082; Thu, 23 Apr 2015 08:21:37 -0700 (PDT)
Message-ID: <55390E00.8000401@thinkingcat.com>
Date: Thu, 23 Apr 2015 11:21:36 -0400
From: "Leslie Daigle (ThinkingCat)" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Keith Moore ,  "urn@ietf.org" 
References: <55388B0E.3080806@network-heretics.com>
In-Reply-To: <55388B0E.3080806@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [urn] "/" Re:  suggested text changes for -12 on p-components, f- and q-components in URN resolution, and relative references
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Apr 2015 15:21:44 -0000

Hi,

Tackling one issue at a time :^)  -- I went back and re-read RFC3986 per 
your point about "path-rootless", and came to the same conclusion.   I'm 
not a (URI-)parser, though, so I wouldn't object to hearing confirmation 
from someone who does deal in non-URN URI parsing for a living...

Given that, I'd favour "c" as well -- allow "/" with no special 
significance imbued.

Leslie.

On 4/23/15 2:02 AM, Keith Moore wrote:
> Here are my suggestions for changes to draft-ietf-urnbis-rfc2141bis-11
> based on last Friday's conference call.
>
> I will try to also suggest text for r-components in a separate message,
> hopefully sometime tomorrow.  If I don't get it out by tomorrow it will
> be early next week.
>
>
> I. p-components
>
> If we have consensus that (a) relative references in resources named by
> URNs are always evaluated with respect to a base URI that is not a URN,
> and (b) there's no special need for URNs to be able to contain "paths",
> then we have several choices:
>
> (a) Disallow p-components in the 2141bis grammar, OR
> (b) Allow p-components in the 2141bis grammar, but reserve them for
> future use.   basically this means that parsers would recognize
> p-components, and p-components would be transmitted to resolution
> services, but namespaces shouldn't assign names containing p-components
> until a standards-track document explains how to do so, OR
> (c) Permit "/" in NSS arbitrarily without giving any special
> significance to them.
>
> Any of these seem workable but I lean toward either (a) or (c) - maybe a
> bit more toward (c) because I suspect there are namespaces that assign
> names containing "/" which could more easily be URN namespaces if "/"
> did not need to be %-encoded.
>
> (I don't think that (c) breaks RFC 3986 compatibility because that
> "path" component of a URN (according to the 3986 grammar) never begins
> with "/" because a namespace never begins with a "/".   The
> namespace:NSS portion of a URN always matches "path-rootless", and
> "path-rootless" can containing an arbitrary number of "/"s in a row
> because "segment" is defined to be zero or more "pchar"s.   See RFC 3986
> mostly section 3.3)
>
> Since there are three choices, I'm supplying three sets of changes,
> color-coded to hopefully minimize confusion as one scrolls back and
> forth through the message.   Pick only one :)   Note that in all cases
> the new text is shorter than the old; I take that as a favorable sign.
>
> Option (a): Disallow p-components in the 2141bis grammar
>
> Section 3
>
> OLD:
>
>        namestring    = assigned-name
>                        [ q-component ]
>                        [ f-component ]
>        assigned-name = "urn" ":" NID ":" NSS [ p-component ]
>        NID           = (alphanum) 0*30(ldh) (alphanum)
>        ldh           = alphanum / "-"
>        NSS           = 1*(pchar)
>        p-component   = "/" path-absolute
>        q-component   = "?" query
>        f-component   = "#" fragment
>
>     Note that "/" can be used without percent-encoding inside
>     p-components and that "?" can be used without percent-encoding inside
>     q-components and f-components.
>
> NEW:
>
>        namestring    = assigned-name
>                        [ q-component ]
>                        [ f-component ]
>        assigned-name = "urn" ":" NID ":" NSS
>        NID           = (alphanum) 0*30(ldh) (alphanum)
>        ldh           = alphanum / "-"
>        NSS           = 1*(pchar)
>        q-component   = "?" query
>        f-component   = "#" fragment
>
>     Note that "?" can be used without percent-encoding inside
>     q-components and f-components.
>
> Section 3.3
>
> OLD
>
> 3.3.  p-component, q-component, and f-component
>
>     The p-component, q-component, and f-component are optional components
>     that follow the assigned-name.  In terms of URI syntax these
>     components are essentially equivalent to the URI "path-absolute",
>     "query", and "fragment" constructions, respectively. However, the
>     URN p-component, q-component, and f-component need not be
>     semantically equivalent to the URI path component, query component,
>     and fragment component; therefore they are called by different names
>     in this specification.
>
>     Unless specifically defined for a particular namespace after
>     publication of this document, use of these components is disallowed,
>     thereby maintaining strict backward compatibility with namespaces
>     defined in accordance with [RFC2141] and registered in accordance
>     with [RFC3406].
>
>     This specification does not define the semantics of the p-component,
>     q-component, and f-component for URNs in general. Instead,
>     additional specifications might establish these matters for URN-
>     related services (such as URN resolution) or for individual URN
>     namespaces (e.g., to handle extended information about the resource
>     identified by a URN).  For example, it is possible that the
>     q-component might be used in requests to URN resolution services, or
>     that the f-component might be used to distinguish the integral parts
>     of resources named by URNs in particular namespaces (say, the
>     chapters of a book).  However, defining such usage is the
>     responsibility of specifications for URN resolution services,
>     namespace registration requests and specifications for individual
>     namespaces, and other appropriate documentation (such as policy
>     documents governing the management of a given URN namespace).
>
>     As general guidance that might not apply to all cases, it would be
>     inappropriate for namespaces that do not intend to support resolution
>     services to allow q-components.  Namespaces that deal with digital
>     manifestations might be able to support f-components. At the time of
>     writing, no general guidance can be provided for use of p-components.
>
> NEW
>
> 3.3.  q-component and f-component
>
>     The q-component and f-component are optional componentsthat follow
>     the assigned-name.  In terms of URI syntax thesecomponents are
>     essentially equivalent to the URI"query", and "fragment"
>     constructions, respectively.  However, thesemantics of the URN
>     q-component and f-component are subtly different than the semantics
>     of the generic URI equivalents, therefore they are called by
>     different namesin this specification.
>
>     Note: URN syntax provides no equivalent to the "path" component of
>     a generic URI.
>
>     See section [TBD.A] for a description on how the URN q-component
>     and f-component affect resolution of a URN, and section [TBD.B] for
>     how relative references are evaluated with respect to a URN.
>
>
> Section 3.3.1 (delete)
>
> Section 4.1
>
> OLD:
>
>     If a p-component is included in a URN, it MUST be identical
>     (including case sensitivity) in the strings being compared.
>
> NEW: (delete this paragraph)
>
> Section 4.2
>
> (delete examples using "/" in NSS, whether or not percent-encoded)
>
> Section 7.3.2
>
> OLD:
>
>     3.  If p-components, q-components, and/or f-components are allowed
>         for the namespace, a discussion of how they are used.
>
>
> NEW: (delete this paragraph. use or handling of f-components and
> q-components should not be namespace-specific)
>
>
> Option (b):  Allow p-components in the 2141bis grammar, but reserve them
> for future use.
>
> OLD:
>
> 3.3.  p-component, q-component, and f-component
>
>     The p-component, q-component, and f-component are optional components
>     that follow the assigned-name.  In terms of URI syntax these
>     components are essentially equivalent to the URI "path-absolute",
>     "query", and "fragment" constructions, respectively. However, the
>     URN p-component, q-component, and f-component need not be
>     semantically equivalent to the URI path component, query component,
>     and fragment component; therefore they are called by different names
>     in this specification.
>
>     Unless specifically defined for a particular namespace after
>     publication of this document, use of these components is disallowed,
>     thereby maintaining strict backward compatibility with namespaces
>     defined in accordance with [RFC2141] and registered in accordance
>     with [RFC3406].
>
>     This specification does not define the semantics of the p-component,
>     q-component, and f-component for URNs in general. Instead,
>     additional specifications might establish these matters for URN-
>     related services (such as URN resolution) or for individual URN
>     namespaces (e.g., to handle extended information about the resource
>     identified by a URN).  For example, it is possible that the
>     q-component might be used in requests to URN resolution services, or
>     that the f-component might be used to distinguish the integral parts
>     of resources named by URNs in particular namespaces (say, the
>     chapters of a book).  However, defining such usage is the
>     responsibility of specifications for URN resolution services,
>     namespace registration requests and specifications for individual
>     namespaces, and other appropriate documentation (such as policy
>     documents governing the management of a given URN namespace).
>
>     As general guidance that might not apply to all cases, it would be
>     inappropriate for namespaces that do not intend to support resolution
>     services to allow q-components.  Namespaces that deal with digital
>     manifestations might be able to support f-components. At the time of
>     writing, no general guidance can be provided for use of p-components.
>
> NEW:
>
> 3.3.  p-component, q-component, and f-component
>
>     The p-component, q-component, and f-component are optional components
>     that follow the assigned-name.  In terms of URI syntax these
>     components are essentially equivalent to the URI "path-absolute",
>     "query", and "fragment" constructions, respectively. However, the
>     URN p-component, q-component, and f-component are not
>     semantically equivalent to the URI path component, query component,
>     and fragment component; therefore they are called by different names
>     in this specification.
>
> See section [TBD.A] for a description on how the URN q-component
>     and f-component affect resolution of a URN, and section [TBD.B] for
>     how relative references are evaluated with respect to a URN.
>
>     p-components are reserved for future use.  Implementations which
>     recognize URNs MUST parse URNs according to the grammar described in
>     this document, and MUST include the entire assigned portion of a URN
>     (including any p-component) to a resolution service. However,
>     namespaces MUST NOT assign URNs containing p-components. This
>     restriction on use of p-components may be relaxed in a later
> specification.
>
> section 3.3.1:
>
> OLD
>
> 3.3.1.  p-component
>
>     The only formal restriction placed upon a p-component by this
>     specification is that the syntax SHALL adhere to the "path-absolute"
>     rule from [RFC3986].  The specification for a particular namespace or
>     URN-related service MAY define further syntax restrictions within the
>     p-component.  (For example, a namespace specification might define a
>     character such as "~" or "@" as a delimiter inside p-components
>     assigned within that namespace.)  Note that characters outside the
>     ASCII range [RFC20] MUST be percent-encoded using the method defined
>     in Section 2.1 of the generic URI specification [RFC3986].
>
>     Consider the hypothetical example of a hierarchical naming system in
>     which the identifiers take the form of a series of numbers separated
>     by the "/" character, such as "1/406/47452/2".  If the naming
>     authority for such identifiers were to use URNs, it would be natural
>     to place the existing identifiers in the p-component, resulting in
>     URNs such as "urn:example/1/406/47452/2" (using the "example" URN
>     namespace [RFC6963] instead of a registered NID).
>
>     As described under Section 4, the p-component SHALL be taken into
>     account when determining URN equivalence.
>
> NEW
>
> [[Note:  Maybe I misunderstand, but I think the -11 text is incorrect in
> syntax even if we don't change the semantics of p-components at all.
> As I read 3986, the URI "path" corresponds to the URN namespace:NSS, so
> the "path" never begins with "/" and can never correspond to
> "path-absolute".   (Yes, we can reuse that production from the 3986
> grammar if we want to do so, but I see no reason to do so.)   And the
> example given in the next paragraph is also incorrect, because there
> would need to be a ":" after the namespace "example".]]
>
> 3.3.1.  p-component
>
>     p-component is reserved for future use.  Namespaces MUST NOT assign
>     URNs with p-components.  A future specification may permit
>     p-components while possibly imposing other constraints on their use.
>
>     However, software that recognizes URNs MUST parse URNs (including
>     p-components) according to the grammar in this document, and MUST
>     present the entire "assigned-name" portion of a URN to a resolution
>     service when resolving the URN.
>
>     As described under Section 4, the p-component SHALL be taken into
>     account when determining URN equivalence.
>
> Section 7.3.2:
>
> OLD
>
>     3.  If p-components, q-components, and/or f-components are allowed
>         for the namespace, a discussion of how they are used.
>
> NEW:  (delete this.  use or interpretation of f- and q-components should
> not be namespace-specific)
>
>
> Option (c): Permit "/" in NSS arbitrarily without giving any special
> significance to them.
>
> Section 3:
>
> OLD
>
>        namestring    = assigned-name
>                        [ q-component ]
>                        [ f-component ]
>        assigned-name = "urn" ":" NID ":" NSS [ p-component ]
>        NID           = (alphanum) 0*30(ldh) (alphanum)
>        ldh           = alphanum / "-"
>        NSS           = 1*(pchar)
>        p-component   = "/" path-absolute
>        q-component   = "?" query
>        f-component   = "#" fragment
>
>     Note that "/" can be used without percent-encoding inside
>     p-components and that "?" can be used without percent-encoding inside
>     q-components and f-components.
>
> NEW
>
>        namestring    = assigned-name
>                        [ q-component ]
>                        [ f-component ]
>        assigned-name = "urn" ":" NID ":" NSS
>        NID           = (alphanum) 0*30(ldh) (alphanum)
>        ldh           = alphanum / "-"
>        NSS           = 1*(pchar / "/")
>        q-component   = "?" query
>        f-component   = "#" fragment
>
>     Note that "?" can be used without percent-encoding inside
>     q-components and f-components.
>
> Section 3.3
>
> OLD
>
> 3.3.  p-component, q-component, and f-component
>
>     The p-component, q-component, and f-component are optional components
>     that follow the assigned-name.  In terms of URI syntax these
>     components are essentially equivalent to the URI "path-absolute",
>     "query", and "fragment" constructions, respectively. However, the
>     URN p-component, q-component, and f-component need not be
>     semantically equivalent to the URI path component, query component,
>     and fragment component; therefore they are called by different names
>     in this specification.
>
>     Unless specifically defined for a particular namespace after
>     publication of this document, use of these components is disallowed,
>     thereby maintaining strict backward compatibility with namespaces
>     defined in accordance with [RFC2141] and registered in accordance
>     with [RFC3406].
>
>     This specification does not define the semantics of the p-component,
>     q-component, and f-component for URNs in general. Instead,
>     additional specifications might establish these matters for URN-
>     related services (such as URN resolution) or for individual URN
>     namespaces (e.g., to handle extended information about the resource
>     identified by a URN).  For example, it is possible that the
>     q-component might be used in requests to URN resolution services, or
>     that the f-component might be used to distinguish the integral parts
>     of resources named by URNs in particular namespaces (say, the
>     chapters of a book).  However, defining such usage is the
>     responsibility of specifications for URN resolution services,
>     namespace registration requests and specifications for individual
>     namespaces, and other appropriate documentation (such as policy
>     documents governing the management of a given URN namespace).
>
>     As general guidance that might not apply to all cases, it would be
>     inappropriate for namespaces that do not intend to support resolution
>     services to allow q-components.  Namespaces that deal with digital
>     manifestations might be able to support f-components. At the time of
>     writing, no general guidance can be provided for use of p-components.
>
> NEW
>
> 3.3.  q-component and f-component
>
>     The q-component and f-component are optional components
>     that follow the assigned-name.  In terms of URI syntax these
>     components are essentially equivalent to the URI
>     "query", and "fragment" constructions, respectively. However, the
>     URN  q-component, and f-component are not quite
>     semantically equivalent to the URI query component
>     and fragment component; therefore they are called by different names
>     in this specification.
>
> See section [TBD.A] for a description on how the URN q-component
>     and f-component affect resolution of a URN, and section [TBD.B] for
>     how relative references are evaluated with respect to a URN.
>
> Section 3.3.1 (delete this section)
>
> Section 4.1
>
> OLD
>
>     If a p-component is included in a URN, it MUST be identical
>     (including case sensitivity) in the strings being compared.
>
> NEW (delete this paragraph)
>
> Section 4.2
>
> (delete examples containing p-components and text referring to p-components)
>
> Section 7.3.2
>
> OLD
>
>     3.  If p-components, q-components, and/or f-components are allowed
>         for the namespace, a discussion of how they are used.
>
> NEW (delete this item; f- and q-components should not be namespace-specific)
>
>
> II. URN resolution
>
> Notes:
>
> 1. My first cut at this said that a client MUST NOT include a
> q-component or f-component in a URN sent in a request to a resolution
> service.  Then I realized that a resolution service might in some
> circumstances provide access to resource content (say by caching it), or
> act as a proxy to a resource, in which circumstances interpreting the
> q-component might be appropriate.   So now the client MUST NOT include
> q-component or f-component unless it's requesting that the resolution
> service provide access to the resource itself, and the resolution
> service is supposed to ignore the q-component except when it needs to
> send it as a query to the resource, and to ignore the f-component.   But
> this bothers me somewhat, and I'd like for the rules to be simpler while
> still maintaining a layer separation between the resolution service and
> the resources which it names.   The simplest solution is probably to say
> that resolution services never provide access to resource content, only
> to locations and metadata.  However, it's long been expected that
> resolution services could provide access to resource content.
>
> 2. Lars Svensson pointed out to me in private mail that a resolution
> service could potentially return a URL with query and/or fragment, so
> this text takes a position on how to interpret such a URL when the
> original URN also had an q-component and/or f-component.   I thought it
> made more sense to ignore those components from the original URN in that
> case.   There are other positions that could be taken, e.g. that
> resolution services should not be permitted to return URLs with queries
> and/or fragments, but I actually think it can be reasonable for them to
> do so.
>
>
> (new section.  note: text in brackets/italics about r-components should
> only be included if r-component proposal is adopted)
>
> TBD.A. Use of f- and q-components in URN resolution
>
> Since a URN, by design, does not contain either explicitly or implicitly
> the name or address of a network service which can be used to access the
> resource named by the URN, an application wishing to access that
> resource must somehow discover one or more "resolution services" which
> can, given the URN, either provide the resource content directly, or
> provide information to the application to enable it to access the resource.
>
> Though f- and q-components may appear in a URN, they are not assigned or
> managed by the URN namespace, but instead evaluated in the context of
> the named resource.   Specifically, an f-component of a URN refers to a
> "fragment" of the resource named by the URN, and a q-component of a URN
> is used to specify a "query" to be evaluated by the resource named by
> the URN.   This convention ensures consistent use of these components
> across all URN namespaces, and preserves the ability to reference
> "fragments" of resources named by URNs that have fragments, and to
> specify "queries" with resources named by URNs that support queries.
> In order to preserve this ability, f-components and q-components MUST
> NOT be transmitted to a URN resolution service except when that service
> is being requested to provide direct access (or access via proxy) to the
> resource itself.   For all other requests, the client MUST transmit only
> the "assigned-part" of a URN /[ along with any r-component//, if
> specified ]/ to the URN resolution service.
>
> A resolution service processing a request for a URN MUST ignore any
> f-component or q-component of that URN unless the request is to provide
> direct access (or access via proxy) to the named resource.   If the
> request is to provide access to the named resource (as opposed to, say,
> resource locations or resource metadata), the resolution service MUST
> ignore the f-component of the URN and SHOULD (if possible) process the
> q-component as if it were a query transmitted to the resource, returning
> the resource's response to that query.  If the resolution service cannot
> provide the requested access to the resource, but instead returns
> resource locations, the f-component and q-component of the request URN
> MUST be ignored in determining these locations, and MUST NOT be included
> as fragment and query (respectively) in the returned locations.
>
> These rules are intended to impose a layer separation between the URN
> resolution service and the content, and to discourage the URN resolution
> service from returning different results depending on the presence of f-
> and/or q-components in the request.
>
> If the resource named by a URN that contains an f- and/or q-component is
> accessed via an intermediate URI (other than a URN) obtained from a
> resolution service, and that intermediate URI contains neither a
> fragment nor a query, the q-component (if present) is appended to the
> intermediate URI as a query, and the f-component (if present) is
> appended to the intermediate URI as a fragment (in that order).  The
> resulting URI is then processed according to RFC 3986.
>
> Example: If the URN urn:example:foo?bar#zot appears in a link, the
> client application might transmit the assigned-part of that URN
> (urn:example:foo) to a resolution service with a request for resource
> locations.   The resolution service might then return the intermediate
> URI http://example.com/whatnot/xyzzy as one of those locations.   The
> client would then append ?bar#zot to that intermediate URI producing
> http://example.com/whatnot/xyzzy?bar#zot .   This URI would then be
> processed per normal RFC 3986 rules.
>
> A resolution service MAY return an intermediate URI which contains a
> fragment and/or a query.   If the intermediate URI contains a fragment
> or a query, any f- or q-component from the URN is ignored.   (This
> situation is basically no different than anyone composing a URI from a
> base URI plus a fragment and/or query without being aware of what
> fragments and/or queries are valid in the context of the named
> resource.   Any user or document author may combine URIs with arbitrary
> queries and/or fragments, but that doesn't mean that the results will do
> what the user or author intended.)
>
> Example: If the URN urn:example:foo?bar#zot appeared in a link, a
> resolution service might be requested to return locations of the URN
> urn:example:foo .  If such a service returned an intermediate URI
> http://example.com/whatnot/xyzzy?abcde , neither the q-component ?bar
> nor the f-component #zot would be appended to the intermediate URI
> before processing it.
>
> If the content of a resource named by a URN containing an f-component is
> obtained directly from a resolution service, the f-component SHOULD be
> treated as a "fragment" and evaluated with respect to that content, just
> as if the content had been obtained from any other service.
>
> III. Relative References
>
> (new section)
>
> TBD.B. URNs and Relative References
>
> RFC 3986 section 5.2 describes an algorithm for converting a URI
> reference that might be relative to a given base URI into "parsed
> components" of the target of that reference, which can then be
> recomposed per RFC 3986 section 5.3 into a target URI. If this algorithm
> were applied directly to URNs, it would pragmatically have the effect of
> imposing additional constraints on the naming of URNs containing
> p-components, in order that relative references contained in the
> resources named by those URNs would not break.  Alternatively, resources
> named with URNs could be forbidden to contain relative references.
> Neither of those alternatives seems attractive.   In addition, if the
> same resources are accessible by both URN and URL, it is desirable to
> permit relative references to work correctly in either case.
>
> Therefore a relative reference SHOULD NOT be evaluated with respect to a
> URN.   Instead, a relative reference SHOULD be evaluated with respect to
> either
>
> (a) a BASE URI (other than a URN) declared by the resource itself, OR
> (b) a BASE URI (other than a URN) obtained through the URN resolution
> process, OR
> (c) the URL of the resource as obtained through the URN resolution process
>
> (Case (b) permits the resolution process to explicitly supply a BASE URI
> if the resource content is supplied directly by the resolution service
> rather than via an intermediate "location" URI.)
>
> If no such BASE URI exists, use of a relative reference with respect to
> a URN is an error.
>
> Resolution services SHOULD ensure that a BASE URI is supplied any time
> they provide resource content directly to a client.
>
>
>
>
>
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
ldaigle@thinkingcat.com
-------------------------------------------------------------------


From nobody Thu Apr 23 21:54:08 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CAD1B2C5E for ; Thu, 23 Apr 2015 21:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Level: 
X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWhweVwbiRuz for ; Thu, 23 Apr 2015 21:54:02 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375A41B2C97 for ; Thu, 23 Apr 2015 21:53:27 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id A757B208F3 for ; Fri, 24 Apr 2015 00:53:26 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Fri, 24 Apr 2015 00:53:26 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=1A BNpLVk0uZGoFpVOyLhX7I+uhA=; b=l0wzMWws6sB0G3zt1iLemR9vpfyaQY6JXM YdmibjYeJ3CrU/0o39Vg179//+m5bWlz+rZBjd7/wvaCKQFMbS3vOjdCrb6c7rTG H/jAhP6bmsy9pB4DmoG65eNKKXFuXU2JNQDGzozlJCbiqH5rLPJeGjesicgmI4Cw KJHNrJUwk=
X-Sasl-enc: fdsmIUKeOehfO95z6zbedebC+zlJ+Rq/Xr1knJ0Mc0YY 1429851206
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 3260168023C; Fri, 24 Apr 2015 00:53:26 -0400 (EDT)
Message-ID: <5539CC41.4050204@network-heretics.com>
Date: Fri, 24 Apr 2015 00:53:21 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "urn@ietf.org" 
Content-Type: multipart/alternative; boundary="------------070801040100070700090507"
Archived-At: 
Subject: [urn] suggested text for r-components
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Apr 2015 04:54:07 -0000

This is a multi-part message in MIME format.
--------------070801040100070700090507
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Okay, here's a first stab at text for r-components.   This isn't 
complete; in particular the IANA section needs more prose.

I am also sensitive to the concern Leslie expressed - i.e. that if I 
don't happen to finish writing it down, someone will come along and 
interpret it completely differently than was intended. (Or perhaps more 
likely, if I am unable to specify this succinctly and yet with 
sufficient clarity and detail.)   This is currently missing both some 
clarity and some detail, but it will be sometime next week before I can 
look at it again.

---

The basic idea is that an r-component consists of a request followed by 
one or more constraints.   The request is something like U2R (access an 
instance of the named resource), U2L (request locations of the named 
resource), or U2C (request metadata about the named resource).  (I'm not 
particularly fond of those names, and would be happy with other names, 
but there is some history behind these names.)

In each case, evaluating the request should produce a set of results.   
In the U2R case that set would be a set of resource instances (even 
though only one of them could be ultimately used).   In the U2L case it 
would be a set of resource locations.  In the U2C case it would be a set 
of resource descriptions. (The result set for any of these requests can, 
of course, be the null set.)

In any of these cases the items in the set may vary along certain 
dimensions.  For instance, a resource may exist in multiple revisions.  
It may have versions in multiple languages.  It may be available in 
different media types, e.g. HTML and PDF.  In the U2C case there may be 
MARC records, Dublin Core metadata sets, etc.   The constraints exist to 
narrow the result set.  Examples of constraints might be things like 
"order by revision-date descending" or "limit to a maximum of 10 
results" or "include only resource instances with content-types in [ 
application/pdf, text/html ]" or "include only resource descriptions in 
the set [ dublin-core ]" or "revision dates between 2001-1-1 and 
2002-12-31".

Constraints can be forwarded to URN resolution services to let the 
filtering be done by the service; additional filtering may be done by 
the client.  If a client or a resolution service doesn't know how to 
implement a constraint, that constraint may be ignored.  (even though 
this may produce a result set that contains members that don't satisfy 
all of the constraints.)

Both the set of requests and the set of results are extensible via an 
IANA registry for each.   I would like to define the initial requests as 
U2R, U2L, and U2C (perhaps by other names).   My current thinking is to 
not define any constraints in this document, and leave constraint 
definitions for other documents.   I expect that there will be a need 
for both additional requests and a wide variety of constraints, though I 
hope we can identify a minimal core set for each that clients and 
resolution services can reasonably implement.

--

One thing I realized is that r-components probably should not be 
evaluated entirely by the resolution service, because the client 
application may have a role in satisfying the request.   For instance 
the request (U2R) may be to access the actual resource named by the URN, 
but the resolution service might not provide such access.  So in that 
event the client needs to request locations from the resolution service, 
pick one, and access the resource via that location.

Another thing I realized is that resolution services will naturally 
differ in which requests and constraints that they support, and it's 
necessary for client software to be able to combine results from 
different services in spite of this.   So whatever constraints are 
implemented by a resolution service are essentially optimizations to 
reduce server load and network traffic.   So my original thinking about 
r-components was that they're parameters to be transmitted to resolution 
services, now I think that they're more like search constraints 
implemented on clients.

--

Anyway, here's a start at some text.

These changes are relative to draft-ietf-urnbis-rfc2141bis-urn-11, not 
to any other set of proposed changes.

Section 3

OLD:

       namestring    = assigned-name
                       [ q-component ]
                       [ f-component ]
       assigned-name = "urn" ":" NID ":" NSS [ p-component ]
       NID           = (alphanum) 0*30(ldh) (alphanum)
       ldh           = alphanum / "-"
       NSS           = 1*(pchar)
       p-component   = "/" path-absolute
       q-component   = "?" query
       f-component   = "#" fragment

NEW:

       namestring = assigned-name
                       [ r-component ]
                       [ q-component ]
                       [ f-component ]
       assigned-name = "urn" ":" NID ":" NSS [ p-component ]
       NID           = (alphanum) 0*30(ldh) (alphanum)
       ldh           = alphanum / "-"
       NSS           = 1*(pchar)
       p-component   = "/" path-absolute
       q-component   = "?" query
       f-component   = "#" fragment
       r-component   = "??" request *(";" constraint)
       request       = 1*(unreserved)
       constraint    = name 0*1("=" value)
       name          = alpha *(alphanum / ".") alphanum
       value         = *( unreserved / pct-encoded
                        / "!" / "$" / "&" / "'" / "(" / ")"
                        / "*" / "+" / "," / "=" / ":" / "@"
                        / "/" )


(somewhere later in section 3)

This grammar is syntax-compatible with the URI grammar in RFC 3986; 
however, it parses the
URN differently than the RFC 3986 grammar.   An RFC 3986 parser will 
parse the combination
of any "r-component" and/or "q-component" as a single "query".


New section TBD.C:


TBD.C.  r-component

    In contrast to f-component (which specifies a fragment of the named 
resource), and
    q-component (which specifies a query to be sent to the named 
resource), the optional
    r-component specifies a default "use" of the URN.  Broadly speaking, 
"use"s that have
    been identified as desirable fall into one of three categories: 
requests to access
    the resource, requests to obtain one or more locations of the 
resource, and requests
    for information about the resource ("metadata").  The request may be 
followed by
    zero or more parameters which are interpreted as modifiers to the 
request.   For
    instance, the parameters might specify: revision or range of 
revisions, language
    or set of languages, acceptable media types, or a preference to have 
the results
    reported according to a particular schema and/or representation.   
These parameters
    generally have the effect of narrowing the set of responses or 
potential responses
    to a request.

    More than one parameter with the same name MAY appear in an 
r-component.

    Implementation of requests and interpretation of parameters is the 
job of URN-aware
    client applications.  However, it is anticipated that URN resolution 
services will
    provide support for frequently used requests that appear in 
r-components, and may
    also interpret some of the parameters associated with r-components.

    A URN-aware client application MAY ignore r-component requests 
and/or parameters
    when they specify a behavior that is not appropriate for the context 
in which the
    URN appears.  A client application MAY also permit a URN which 
contains an
    r-component to be used for a different purpose than that specified 
in the r-component.
    For example, if a URN appears in a "link" in a document, and the 
request in the URN's
    r-component specifies that the resource should be accessed directly, 
clicking on the
    link might cause the URN's target content to be displayed. However, 
the client
    application might also allow the user to request other behaviors 
(say, via a
    pull-down menu) such as to display the available locations and/or 
metadata associated
    with the URN.

    If a URN does not include an r-component, the default use of the URN 
is determined
    by the client application and possibly by the context in which the 
URN appears.

    A client application MAY interpret an r-component's request and 
attempt to implement
    the specified default use independent of any resolution service.   
For example,
    if the request in a r-component specifies that the resource should 
be accessed,
    a client application MAY obtain a location of that resource from a 
resolution
    service and then arrange access to the resource via that location.

    The set of requests is defined by an IANA registry. The set of 
parameter names is
    defined by a separate IANA registry. Parameter names beginning with a
    IANA-registered URN namespace ID followed by "." are reserved for 
definition by
    that namespace.  This permits each namespace to define additional 
parameters
    which may be specific to its namespace or to the kinds of resources 
to which
    it assigns URNs.

    r-components are not considered significant for the purpose of 
comparing URNs
    for equivalence.


New section 8.3:

8.3.   Registration of URN r-component request names

        r-component requests are intended for broad categories of 
requests for
        URN processing that could reasonably be fulfilled by resolution 
services,
        and/or by clients capable of processing URNs.

        The set of request names that are prefixed by a registered URN 
namespace
        followed by "." is reserved for definition by that namespace.   
A namespace
        MAY register such names with IANA but is not required to do so.  
Registration
        of additional request names not prefixed by a registered URN 
namespace
        requires IETF consensus.

        IANA is hereby requested to register the following URN 
r-component request
        names:

        Request-name: "U2R"
        Purpose:  This is used to request access to the named resource.

        Request-name: "U2L"
        Purpose:  This is used to request zero or more locations of the 
named resource.

        Request-name: "U2C"
        Purpose:  This is used to request information about the named 
resource (metadata).

8.4.   Registration of URN r-component parameter names

        *** to be written ***




--------------070801040100070700090507
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    Okay, here's a first
        stab at text for r-components.   This isn't complete; in
        particular the IANA section needs more prose.   

        

        I am also sensitive to the concern Leslie expressed - i.e. that
        if I don't happen to finish writing it down, someone will come
        along and interpret it completely differently than was
        intended.   (Or
            perhaps more likely, if I am unable to specify this
            succinctly and yet with sufficient clarity and detail.)   This
            is currently missing both some clarity and some detail, but
            it will be sometime next week before I can look at it again.

            

            ---

            

            The basic idea is that an r-component consists of a request
            followed by one or more constraints.   The request is
            something like U2R (access an instance of the named
            resource), U2L (request locations of the named resource), or
            U2C (request metadata about the named resource).  (I'm not
            particularly fond of those names, and would be happy with
            other names, but there is some history behind these names.)

            

            In each case, evaluating the request should produce a set of
            results.   In the U2R case that set would be a set of
            resource instances (even though only one of them could be
            ultimately used).   In the U2L case it would be a set of
            resource locations.  In the U2C case it would be a set of
            resource descriptions.    (The result set
                    for any of these requests can, of course, be the
                    null set.)

                    

                  In any of these cases the
            items in the set may vary along certain dimensions.  For
            instance, a resource may exist in multiple revisions.  It
            may have versions in multiple languages.  It may be
            available in different media types, e.g. HTML and PDF.  In
            the U2C case there may be MARC records, Dublin Core metadata
            sets, etc.   The constraints exist to narrow the result
            set.  Examples of constraints might be things like "order by
            revision-date descending" or "limit to a maximum of 10
            results" or "include only resource instances with
            content-types in [ application/pdf, text/html ]" or "include
            only resource descriptions in the set [ dublin-core ]" or
            "revision dates between 2001-1-1 and 2002-12-31".

            

            Constraints can be forwarded to URN resolution services to
            let the filtering be done by the service; additional
            filtering may be done by the client.  If a client or a
            resolution service doesn't know how to implement a
            constraint, that constraint may be ignored.  (even though
            this may produce a result set that contains members that
            don't satisfy all of the constraints.)

            

            Both the set of requests and the set of results are
            extensible via an IANA registry for each.   I would like to
            define the initial requests as U2R, U2L, and U2C (perhaps by
            other names).   My current thinking is to not define any
            constraints in this document, and leave constraint
            definitions for other documents.   I expect that there will
            be a need for both additional requests and a wide variety of
            constraints, though I hope we can identify a minimal core
            set for each that clients and resolution services can
            reasonably implement.

            

            --

            

            One thing I realized is that r-components probably should
            not be evaluated entirely by the resolution service, because
            the client application may have a role in satisfying the
            request.   For instance the request (U2R) may be to access
            the actual resource named by the URN, but the resolution
            service might not provide such access.  So in that event the
            client needs to request locations from the resolution
            service, pick one, and access the resource via that
            location.

            

            Another thing I realized is that resolution services will
            naturally differ in which requests and constraints that they
            support, and it's necessary for client software to be able
            to combine results from different services in spite of
            this.   So whatever constraints are implemented by a
            resolution service are essentially optimizations to reduce
            server load and network traffic.   So my original thinking
            about r-components was that they're parameters to be
            transmitted to resolution services, now I think that they're
            more like search constraints implemented on clients.

            

            --

            

            Anyway, here's a start at some text.

          

        These changes are relative to draft-ietf-urnbis-rfc2141bis-urn-11,
        not to any other set of proposed changes.

        

        Section 3

          

        OLD:

          

                namestring    = assigned-name

                              [ q-component ]

                              [ f-component ]

              assigned-name = "urn" ":" NID ":" NSS [
          p-component ]

              NID           = (alphanum) 0*30(ldh) (alphanum)

              ldh           = alphanum / "-"

              NSS           = 1*(pchar)

              p-component   = "/" path-absolute

              q-component   = "?" query

              f-component   = "#" fragment

      

        NEW:

      

          namestring   
          = assigned-name

                                [ r-component ]

                               [ q-component ]

                              [ f-component ]

              assigned-name = "urn" ":" NID ":" NSS [
          p-component ]

              NID           = (alphanum) 0*30(ldh) (alphanum)

              ldh           = alphanum / "-"

              NSS           = 1*(pchar)

              p-component   = "/" path-absolute

              q-component   = "?" query

               f-component   = "#" fragment

            r-component   = "??" request *(";" constraint)

            request       = 1*(unreserved)

            constraint    = name 0*1("=" value)

            name          = alpha *(alphanum / ".") alphanum

            value         = *( unreserved / pct-encoded 

                             / "!" / "$" / "&" / "'" / "(" / ")" 

                             / "*" / "+" / "," / "=" / ":" / "@"

                             / "/" )

      

    

    (somewhere later in section 3)

      

      This grammar is syntax-compatible with the URI grammar in RFC
      3986; however, it parses the 

      URN differently than the RFC 3986 grammar.   An RFC 3986 parser
      will parse the combination

      of any "r-component" and/or "q-component" as a single "query".

      

      

    New section TBD.C:

      

      

      TBD.C.  r-component

      

         In contrast to f-component (which specifies a fragment of the
      named resource), and

         q-component (which specifies a query to be sent to the named
      resource), the optional 

         r-component specifies a default "use" of the URN.  Broadly
      speaking, "use"s that have 

         been identified as desirable fall into one of three categories:
      requests to access 

         the resource, requests to obtain one or more locations of the
      resource, and requests

         for information about the resource ("metadata").  The request
      may be followed by 

         zero or more parameters which are interpreted as modifiers to
      the request.   For 

         instance, the parameters might specify: revision or range of
      revisions, language 

         or set of languages, acceptable media types, or a preference to
      have the results 

         reported according to a particular schema and/or
      representation.   These parameters

         generally have the effect of narrowing the set of responses or
      potential responses

         to a request.

      

         More than one parameter with the same name MAY appear in an
      r-component. 

      

         Implementation of requests and interpretation of parameters is
      the job of URN-aware

         client applications.  However, it is anticipated that URN
      resolution services will

         provide support for frequently used requests that appear in
      r-components, and may 

         also interpret some of the parameters associated with
      r-components.  

      

         A URN-aware client application MAY ignore r-component requests
      and/or parameters

         when they specify a behavior that is not appropriate for the
      context in which the

         URN appears.  A client application MAY also permit a URN which
      contains an 

         r-component to be used for a different purpose than that
      specified in the r-component.

         For example, if a URN appears in a "link" in a document, and
      the request in the URN's 

         r-component specifies that the resource should be accessed
      directly, clicking on the 

         link might cause the URN's target content to be displayed. 
      However, the client 

         application might also allow the user to request other
      behaviors (say, via a 

         pull-down menu) such as to display the available locations
      and/or metadata associated

         with the URN.

      

         If a URN does not include an r-component, the default use of
      the URN is determined

         by the client application and possibly by the context in which
      the URN appears.

      

         A client application MAY interpret an r-component's request and
      attempt to implement 

         the specified default use independent of any resolution
      service.   For example,

         if the request in a r-component specifies that the resource
      should be accessed,

         a client application MAY obtain a location of that resource
      from a resolution   

         service and then arrange access to the resource via that
      location. 

      

         The set of requests is defined by an IANA registry.  The
        set of parameter names is

           defined by a separate IANA registry.  Parameter
        names beginning with a 

           IANA-registered URN namespace ID followed by "." are reserved
        for definition by

           that namespace.  This permits each namespace to define
        additional parameters 

           which may be specific to its namespace or to the kinds of
        resources to which 

           it assigns URNs.

    

         r-components are not considered significant for the purpose of
      comparing URNs

         for equivalence.

      

      

      New section 8.3:

      

      8.3.   Registration of URN r-component request names

      

             r-component requests are intended for broad categories of
      requests for

             URN processing that could reasonably be fulfilled by
      resolution services,

             and/or by clients capable of processing URNs.

      

             The set of request names that are prefixed by a registered
      URN namespace 

             followed by "." is reserved for definition by that
      namespace.   A namespace

             MAY register such names with IANA but is not required to do
      so.  Registration 

             of additional request names not prefixed by a registered
      URN namespace

             requires IETF consensus.

      

             IANA is hereby requested to register the following URN
      r-component request

             names:

      

             Request-name: "U2R"

             Purpose:  This is used to request access to the named
      resource.

      

             Request-name: "U2L"

             Purpose:  This is used to request zero or more locations of
      the named resource.

      

             Request-name: "U2C"

             Purpose:  This is used to request information about the
      named resource (metadata).   

      

      8.4.   Registration of URN r-component parameter names

      

           *** to be written ***

      

      

         

     
  


--------------070801040100070700090507--


From nobody Thu Apr 23 23:07:26 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C281B2E10 for ; Thu, 23 Apr 2015 23:07:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.998
X-Spam-Level: 
X-Spam-Status: No, score=0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, MANGLED_OFF=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id musmOE3W73kr for ; Thu, 23 Apr 2015 23:07:19 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE1B1B2E0E for ; Thu, 23 Apr 2015 23:07:06 -0700 (PDT)
Received: from AM3PR07MB369.eurprd07.prod.outlook.com (10.242.109.143) by AM3PR07MB370.eurprd07.prod.outlook.com (10.242.109.144) with Microsoft SMTP Server (TLS) id 15.1.148.16; Fri, 24 Apr 2015 05:49:23 +0000
Received: from AM3PR07MB369.eurprd07.prod.outlook.com ([10.242.109.143]) by AM3PR07MB369.eurprd07.prod.outlook.com ([10.242.109.143]) with mapi id 15.01.0148.008; Fri, 24 Apr 2015 05:49:23 +0000
From: "Hakala, Juha E" 
To: "Leslie Daigle (ThinkingCat)" , Keith Moore , "urn@ietf.org" 
Thread-Topic: [urn] "/" Re:  suggested text changes for -12 on p-components, f- and q-components in URN resolution, and relative references
Thread-Index: AQHQfdk+I/C4I2NF10WnULmz9bCbHp1bokKg
Date: Fri, 24 Apr 2015 05:49:23 +0000
Message-ID: 
References: <55388B0E.3080806@network-heretics.com> <55390E00.8000401@thinkingcat.com>
In-Reply-To: <55390E00.8000401@thinkingcat.com>
Accept-Language: fi-FI, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: thinkingcat.com; dkim=none (message not signed) header.d=none;
x-originating-ip: [128.214.71.180]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB370;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(479174004)(377454003)(13464003)(51704005)(62966003)(2950100001)(77096005)(66066001)(19621145004)(86362001)(2656002)(87936001)(1720100001)(54356999)(107886001)(76176999)(76576001)(77156002)(50986999)(106116001)(5001770100001)(2900100001)(102836002)(92566002)(561944003)(15975445007)(74482002)(19580405001)(122556002)(40100003)(46102003)(19580395003)(33656002)(19300405004)(19273905006)(15395725005)(2501003)(562404015)(559001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB370; H:AM3PR07MB369.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006)(3002001); SRVR:AM3PR07MB370; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB370; 
x-forefront-prvs: 05568D1FF7
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: 24 Apr 2015 05:49:23.1689 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB370
Archived-At: 
Subject: Re: [urn] "/" Re:  suggested text changes for -12 on p-components, f- and q-components in URN resolution, and relative references
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Apr 2015 06:07:24 -0000

Hello,=20

> -----Original Message-----
> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Leslie Daigle
> (ThinkingCat)
> Sent: 23. huhtikuuta 2015 18:22
> To: Keith Moore; urn@ietf.org
> Subject: [urn] "/" Re: suggested text changes for -12 on p-components, f-
> and q-components in URN resolution, and relative references
>=20
> Hi,
>=20
> Tackling one issue at a time :^)  -- I went back and re-read RFC3986 per
> your point about "path-rootless", and came to the same conclusion.   I'm
> not a (URI-)parser, though, so I wouldn't object to hearing confirmation =
from
> someone who does deal in non-URN URI parsing for a living...
>=20
> Given that, I'd favour "c" as well -- allow "/" with no special significa=
nce
> imbued.

"C" is my favourite option as well. Colleagues who are responsible of the n=
ational library's URN services informed me that "/" has been used often in =
(other organization's) internal identifiers which they wish to use as URN:N=
BNs. So avoiding the "/" is not an option. However, if "/" has been used in=
 an identifier, it does not have any special (RFC 3986-based) significance.=
  =20

Percent encoding the character in NSS would bring no added value to the URN=
:NBN resolution.   =20

Juha=20
>=20
> Leslie.
>=20
> On 4/23/15 2:02 AM, Keith Moore wrote:
> > Here are my suggestions for changes to draft-ietf-urnbis-rfc2141bis-11
> > based on last Friday's conference call.
> >
> > I will try to also suggest text for r-components in a separate
> > message, hopefully sometime tomorrow.  If I don't get it out by
> > tomorrow it will be early next week.
> >
> >
> > I. p-components
> >
> > If we have consensus that (a) relative references in resources named
> > by URNs are always evaluated with respect to a base URI that is not a
> > URN, and (b) there's no special need for URNs to be able to contain
> > "paths", then we have several choices:
> >
> > (a) Disallow p-components in the 2141bis grammar, OR
> > (b) Allow p-components in the 2141bis grammar, but reserve them for
> > future use.   basically this means that parsers would recognize
> > p-components, and p-components would be transmitted to resolution
> > services, but namespaces shouldn't assign names containing
> > p-components until a standards-track document explains how to do so,
> > OR
> > (c) Permit "/" in NSS arbitrarily without giving any special
> > significance to them.
> >
> > Any of these seem workable but I lean toward either (a) or (c) - maybe
> > a bit more toward (c) because I suspect there are namespaces that
> > assign names containing "/" which could more easily be URN namespaces i=
f
> "/"
> > did not need to be %-encoded.
> >
> > (I don't think that (c) breaks RFC 3986 compatibility because that
> > "path" component of a URN (according to the 3986 grammar) never begins
> > with "/" because a namespace never begins with a "/".   The
> > namespace:NSS portion of a URN always matches "path-rootless", and
> > "path-rootless" can containing an arbitrary number of "/"s in a row
> > because "segment" is defined to be zero or more "pchar"s.   See RFC 398=
6
> > mostly section 3.3)
> >
> > Since there are three choices, I'm supplying three sets of changes,
> > color-coded to hopefully minimize confusion as one scrolls back and
> > forth through the message.   Pick only one :)   Note that in all cases
> > the new text is shorter than the old; I take that as a favorable sign.
> >
> > Option (a): Disallow p-components in the 2141bis grammar
> >
> > Section 3
> >
> > OLD:
> >
> >        namestring    =3D assigned-name
> >                        [ q-component ]
> >                        [ f-component ]
> >        assigned-name =3D "urn" ":" NID ":" NSS [ p-component ]
> >        NID           =3D (alphanum) 0*30(ldh) (alphanum)
> >        ldh           =3D alphanum / "-"
> >        NSS           =3D 1*(pchar)
> >        p-component   =3D "/" path-absolute
> >        q-component   =3D "?" query
> >        f-component   =3D "#" fragment
> >
> >     Note that "/" can be used without percent-encoding inside
> >     p-components and that "?" can be used without percent-encoding insi=
de
> >     q-components and f-components.
> >
> > NEW:
> >
> >        namestring    =3D assigned-name
> >                        [ q-component ]
> >                        [ f-component ]
> >        assigned-name =3D "urn" ":" NID ":" NSS
> >        NID           =3D (alphanum) 0*30(ldh) (alphanum)
> >        ldh           =3D alphanum / "-"
> >        NSS           =3D 1*(pchar)
> >        q-component   =3D "?" query
> >        f-component   =3D "#" fragment
> >
> >     Note that "?" can be used without percent-encoding inside
> >     q-components and f-components.
> >
> > Section 3.3
> >
> > OLD
> >
> > 3.3.  p-component, q-component, and f-component
> >
> >     The p-component, q-component, and f-component are optional
> components
> >     that follow the assigned-name.  In terms of URI syntax these
> >     components are essentially equivalent to the URI "path-absolute",
> >     "query", and "fragment" constructions, respectively. However, the
> >     URN p-component, q-component, and f-component need not be
> >     semantically equivalent to the URI path component, query component,
> >     and fragment component; therefore they are called by different name=
s
> >     in this specification.
> >
> >     Unless specifically defined for a particular namespace after
> >     publication of this document, use of these components is disallowed=
,
> >     thereby maintaining strict backward compatibility with namespaces
> >     defined in accordance with [RFC2141] and registered in accordance
> >     with [RFC3406].
> >
> >     This specification does not define the semantics of the p-component=
,
> >     q-component, and f-component for URNs in general. Instead,
> >     additional specifications might establish these matters for URN-
> >     related services (such as URN resolution) or for individual URN
> >     namespaces (e.g., to handle extended information about the resource
> >     identified by a URN).  For example, it is possible that the
> >     q-component might be used in requests to URN resolution services, o=
r
> >     that the f-component might be used to distinguish the integral part=
s
> >     of resources named by URNs in particular namespaces (say, the
> >     chapters of a book).  However, defining such usage is the
> >     responsibility of specifications for URN resolution services,
> >     namespace registration requests and specifications for individual
> >     namespaces, and other appropriate documentation (such as policy
> >     documents governing the management of a given URN namespace).
> >
> >     As general guidance that might not apply to all cases, it would be
> >     inappropriate for namespaces that do not intend to support resoluti=
on
> >     services to allow q-components.  Namespaces that deal with digital
> >     manifestations might be able to support f-components. At the time o=
f
> >     writing, no general guidance can be provided for use of p-component=
s.
> >
> > NEW
> >
> > 3.3.  q-component and f-component
> >
> >     The q-component and f-component are optional componentsthat follow
> >     the assigned-name.  In terms of URI syntax thesecomponents are
> >     essentially equivalent to the URI"query", and "fragment"
> >     constructions, respectively.  However, thesemantics of the URN
> >     q-component and f-component are subtly different than the semantics
> >     of the generic URI equivalents, therefore they are called by
> >     different namesin this specification.
> >
> >     Note: URN syntax provides no equivalent to the "path" component of
> >     a generic URI.
> >
> >     See section [TBD.A] for a description on how the URN q-component
> >     and f-component affect resolution of a URN, and section [TBD.B] for
> >     how relative references are evaluated with respect to a URN.
> >
> >
> > Section 3.3.1 (delete)
> >
> > Section 4.1
> >
> > OLD:
> >
> >     If a p-component is included in a URN, it MUST be identical
> >     (including case sensitivity) in the strings being compared.
> >
> > NEW: (delete this paragraph)
> >
> > Section 4.2
> >
> > (delete examples using "/" in NSS, whether or not percent-encoded)
> >
> > Section 7.3.2
> >
> > OLD:
> >
> >     3.  If p-components, q-components, and/or f-components are allowed
> >         for the namespace, a discussion of how they are used.
> >
> >
> > NEW: (delete this paragraph. use or handling of f-components and
> > q-components should not be namespace-specific)
> >
> >
> > Option (b):  Allow p-components in the 2141bis grammar, but reserve
> > them for future use.
> >
> > OLD:
> >
> > 3.3.  p-component, q-component, and f-component
> >
> >     The p-component, q-component, and f-component are optional
> components
> >     that follow the assigned-name.  In terms of URI syntax these
> >     components are essentially equivalent to the URI "path-absolute",
> >     "query", and "fragment" constructions, respectively. However, the
> >     URN p-component, q-component, and f-component need not be
> >     semantically equivalent to the URI path component, query component,
> >     and fragment component; therefore they are called by different name=
s
> >     in this specification.
> >
> >     Unless specifically defined for a particular namespace after
> >     publication of this document, use of these components is disallowed=
,
> >     thereby maintaining strict backward compatibility with namespaces
> >     defined in accordance with [RFC2141] and registered in accordance
> >     with [RFC3406].
> >
> >     This specification does not define the semantics of the p-component=
,
> >     q-component, and f-component for URNs in general. Instead,
> >     additional specifications might establish these matters for URN-
> >     related services (such as URN resolution) or for individual URN
> >     namespaces (e.g., to handle extended information about the resource
> >     identified by a URN).  For example, it is possible that the
> >     q-component might be used in requests to URN resolution services, o=
r
> >     that the f-component might be used to distinguish the integral part=
s
> >     of resources named by URNs in particular namespaces (say, the
> >     chapters of a book).  However, defining such usage is the
> >     responsibility of specifications for URN resolution services,
> >     namespace registration requests and specifications for individual
> >     namespaces, and other appropriate documentation (such as policy
> >     documents governing the management of a given URN namespace).
> >
> >     As general guidance that might not apply to all cases, it would be
> >     inappropriate for namespaces that do not intend to support resoluti=
on
> >     services to allow q-components.  Namespaces that deal with digital
> >     manifestations might be able to support f-components. At the time o=
f
> >     writing, no general guidance can be provided for use of p-component=
s.
> >
> > NEW:
> >
> > 3.3.  p-component, q-component, and f-component
> >
> >     The p-component, q-component, and f-component are optional
> components
> >     that follow the assigned-name.  In terms of URI syntax these
> >     components are essentially equivalent to the URI "path-absolute",
> >     "query", and "fragment" constructions, respectively. However, the
> >     URN p-component, q-component, and f-component are not
> >     semantically equivalent to the URI path component, query component,
> >     and fragment component; therefore they are called by different name=
s
> >     in this specification.
> >
> > See section [TBD.A] for a description on how the URN q-component
> >     and f-component affect resolution of a URN, and section [TBD.B] for
> >     how relative references are evaluated with respect to a URN.
> >
> >     p-components are reserved for future use.  Implementations which
> >     recognize URNs MUST parse URNs according to the grammar described i=
n
> >     this document, and MUST include the entire assigned portion of a UR=
N
> >     (including any p-component) to a resolution service. However,
> >     namespaces MUST NOT assign URNs containing p-components. This
> >     restriction on use of p-components may be relaxed in a later
> > specification.
> >
> > section 3.3.1:
> >
> > OLD
> >
> > 3.3.1.  p-component
> >
> >     The only formal restriction placed upon a p-component by this
> >     specification is that the syntax SHALL adhere to the "path-absolute=
"
> >     rule from [RFC3986].  The specification for a particular namespace =
or
> >     URN-related service MAY define further syntax restrictions within t=
he
> >     p-component.  (For example, a namespace specification might define =
a
> >     character such as "~" or "@" as a delimiter inside p-components
> >     assigned within that namespace.)  Note that characters outside the
> >     ASCII range [RFC20] MUST be percent-encoded using the method
> defined
> >     in Section 2.1 of the generic URI specification [RFC3986].
> >
> >     Consider the hypothetical example of a hierarchical naming system i=
n
> >     which the identifiers take the form of a series of numbers separate=
d
> >     by the "/" character, such as "1/406/47452/2".  If the naming
> >     authority for such identifiers were to use URNs, it would be natura=
l
> >     to place the existing identifiers in the p-component, resulting in
> >     URNs such as "urn:example/1/406/47452/2" (using the "example" URN
> >     namespace [RFC6963] instead of a registered NID).
> >
> >     As described under Section 4, the p-component SHALL be taken into
> >     account when determining URN equivalence.
> >
> > NEW
> >
> > [[Note:  Maybe I misunderstand, but I think the -11 text is incorrect
> > in syntax even if we don't change the semantics of p-components at all.
> > As I read 3986, the URI "path" corresponds to the URN namespace:NSS,
> > so the "path" never begins with "/" and can never correspond to
> > "path-absolute".   (Yes, we can reuse that production from the 3986
> > grammar if we want to do so, but I see no reason to do so.)   And the
> > example given in the next paragraph is also incorrect, because there
> > would need to be a ":" after the namespace "example".]]
> >
> > 3.3.1.  p-component
> >
> >     p-component is reserved for future use.  Namespaces MUST NOT assign
> >     URNs with p-components.  A future specification may permit
> >     p-components while possibly imposing other constraints on their use=
.
> >
> >     However, software that recognizes URNs MUST parse URNs (including
> >     p-components) according to the grammar in this document, and MUST
> >     present the entire "assigned-name" portion of a URN to a resolution
> >     service when resolving the URN.
> >
> >     As described under Section 4, the p-component SHALL be taken into
> >     account when determining URN equivalence.
> >
> > Section 7.3.2:
> >
> > OLD
> >
> >     3.  If p-components, q-components, and/or f-components are allowed
> >         for the namespace, a discussion of how they are used.
> >
> > NEW:  (delete this.  use or interpretation of f- and q-components
> > should not be namespace-specific)
> >
> >
> > Option (c): Permit "/" in NSS arbitrarily without giving any special
> > significance to them.
> >
> > Section 3:
> >
> > OLD
> >
> >        namestring    =3D assigned-name
> >                        [ q-component ]
> >                        [ f-component ]
> >        assigned-name =3D "urn" ":" NID ":" NSS [ p-component ]
> >        NID           =3D (alphanum) 0*30(ldh) (alphanum)
> >        ldh           =3D alphanum / "-"
> >        NSS           =3D 1*(pchar)
> >        p-component   =3D "/" path-absolute
> >        q-component   =3D "?" query
> >        f-component   =3D "#" fragment
> >
> >     Note that "/" can be used without percent-encoding inside
> >     p-components and that "?" can be used without percent-encoding insi=
de
> >     q-components and f-components.
> >
> > NEW
> >
> >        namestring    =3D assigned-name
> >                        [ q-component ]
> >                        [ f-component ]
> >        assigned-name =3D "urn" ":" NID ":" NSS
> >        NID           =3D (alphanum) 0*30(ldh) (alphanum)
> >        ldh           =3D alphanum / "-"
> >        NSS           =3D 1*(pchar / "/")
> >        q-component   =3D "?" query
> >        f-component   =3D "#" fragment
> >
> >     Note that "?" can be used without percent-encoding inside
> >     q-components and f-components.
> >
> > Section 3.3
> >
> > OLD
> >
> > 3.3.  p-component, q-component, and f-component
> >
> >     The p-component, q-component, and f-component are optional
> components
> >     that follow the assigned-name.  In terms of URI syntax these
> >     components are essentially equivalent to the URI "path-absolute",
> >     "query", and "fragment" constructions, respectively. However, the
> >     URN p-component, q-component, and f-component need not be
> >     semantically equivalent to the URI path component, query component,
> >     and fragment component; therefore they are called by different name=
s
> >     in this specification.
> >
> >     Unless specifically defined for a particular namespace after
> >     publication of this document, use of these components is disallowed=
,
> >     thereby maintaining strict backward compatibility with namespaces
> >     defined in accordance with [RFC2141] and registered in accordance
> >     with [RFC3406].
> >
> >     This specification does not define the semantics of the p-component=
,
> >     q-component, and f-component for URNs in general. Instead,
> >     additional specifications might establish these matters for URN-
> >     related services (such as URN resolution) or for individual URN
> >     namespaces (e.g., to handle extended information about the resource
> >     identified by a URN).  For example, it is possible that the
> >     q-component might be used in requests to URN resolution services, o=
r
> >     that the f-component might be used to distinguish the integral part=
s
> >     of resources named by URNs in particular namespaces (say, the
> >     chapters of a book).  However, defining such usage is the
> >     responsibility of specifications for URN resolution services,
> >     namespace registration requests and specifications for individual
> >     namespaces, and other appropriate documentation (such as policy
> >     documents governing the management of a given URN namespace).
> >
> >     As general guidance that might not apply to all cases, it would be
> >     inappropriate for namespaces that do not intend to support resoluti=
on
> >     services to allow q-components.  Namespaces that deal with digital
> >     manifestations might be able to support f-components. At the time o=
f
> >     writing, no general guidance can be provided for use of p-component=
s.
> >
> > NEW
> >
> > 3.3.  q-component and f-component
> >
> >     The q-component and f-component are optional components
> >     that follow the assigned-name.  In terms of URI syntax these
> >     components are essentially equivalent to the URI
> >     "query", and "fragment" constructions, respectively. However, the
> >     URN  q-component, and f-component are not quite
> >     semantically equivalent to the URI query component
> >     and fragment component; therefore they are called by different name=
s
> >     in this specification.
> >
> > See section [TBD.A] for a description on how the URN q-component
> >     and f-component affect resolution of a URN, and section [TBD.B] for
> >     how relative references are evaluated with respect to a URN.
> >
> > Section 3.3.1 (delete this section)
> >
> > Section 4.1
> >
> > OLD
> >
> >     If a p-component is included in a URN, it MUST be identical
> >     (including case sensitivity) in the strings being compared.
> >
> > NEW (delete this paragraph)
> >
> > Section 4.2
> >
> > (delete examples containing p-components and text referring to
> > p-components)
> >
> > Section 7.3.2
> >
> > OLD
> >
> >     3.  If p-components, q-components, and/or f-components are allowed
> >         for the namespace, a discussion of how they are used.
> >
> > NEW (delete this item; f- and q-components should not be
> > namespace-specific)
> >
> >
> > II. URN resolution
> >
> > Notes:
> >
> > 1. My first cut at this said that a client MUST NOT include a
> > q-component or f-component in a URN sent in a request to a resolution
> > service.  Then I realized that a resolution service might in some
> > circumstances provide access to resource content (say by caching it),
> > or act as a proxy to a resource, in which circumstances interpreting th=
e
> > q-component might be appropriate.   So now the client MUST NOT include
> > q-component or f-component unless it's requesting that the resolution
> > service provide access to the resource itself, and the resolution
> > service is supposed to ignore the q-component except when it needs to
> > send it as a query to the resource, and to ignore the f-component.   Bu=
t
> > this bothers me somewhat, and I'd like for the rules to be simpler
> > while still maintaining a layer separation between the resolution servi=
ce
> and
> > the resources which it names.   The simplest solution is probably to sa=
y
> > that resolution services never provide access to resource content,
> > only to locations and metadata.  However, it's long been expected that
> > resolution services could provide access to resource content.
> >
> > 2. Lars Svensson pointed out to me in private mail that a resolution
> > service could potentially return a URL with query and/or fragment, so
> > this text takes a position on how to interpret such a URL when the
> > original URN also had an q-component and/or f-component.   I thought it
> > made more sense to ignore those components from the original URN in
> that
> > case.   There are other positions that could be taken, e.g. that
> > resolution services should not be permitted to return URLs with
> > queries and/or fragments, but I actually think it can be reasonable
> > for them to do so.
> >
> >
> > (new section.  note: text in brackets/italics about r-components
> > should only be included if r-component proposal is adopted)
> >
> > TBD.A. Use of f- and q-components in URN resolution
> >
> > Since a URN, by design, does not contain either explicitly or
> > implicitly the name or address of a network service which can be used
> > to access the resource named by the URN, an application wishing to
> > access that resource must somehow discover one or more "resolution
> > services" which can, given the URN, either provide the resource
> > content directly, or provide information to the application to enable i=
t to
> access the resource.
> >
> > Though f- and q-components may appear in a URN, they are not assigned
> > or managed by the URN namespace, but instead evaluated in the context
> of
> > the named resource.   Specifically, an f-component of a URN refers to a
> > "fragment" of the resource named by the URN, and a q-component of a
> > URN is used to specify a "query" to be evaluated by the resource named =
by
> > the URN.   This convention ensures consistent use of these components
> > across all URN namespaces, and preserves the ability to reference
> > "fragments" of resources named by URNs that have fragments, and to
> > specify "queries" with resources named by URNs that support queries.
> > In order to preserve this ability, f-components and q-components MUST
> > NOT be transmitted to a URN resolution service except when that
> > service is being requested to provide direct access (or access via prox=
y) to
> the
> > resource itself.   For all other requests, the client MUST transmit onl=
y
> > the "assigned-part" of a URN /[ along with any r-component//, if
> > specified ]/ to the URN resolution service.
> >
> > A resolution service processing a request for a URN MUST ignore any
> > f-component or q-component of that URN unless the request is to provide
> > direct access (or access via proxy) to the named resource.   If the
> > request is to provide access to the named resource (as opposed to,
> > say, resource locations or resource metadata), the resolution service
> > MUST ignore the f-component of the URN and SHOULD (if possible)
> > process the q-component as if it were a query transmitted to the
> > resource, returning the resource's response to that query.  If the
> > resolution service cannot provide the requested access to the
> > resource, but instead returns resource locations, the f-component and
> > q-component of the request URN MUST be ignored in determining these
> > locations, and MUST NOT be included as fragment and query (respectively=
)
> in the returned locations.
> >
> > These rules are intended to impose a layer separation between the URN
> > resolution service and the content, and to discourage the URN
> > resolution service from returning different results depending on the
> > presence of f- and/or q-components in the request.
> >
> > If the resource named by a URN that contains an f- and/or q-component
> > is accessed via an intermediate URI (other than a URN) obtained from a
> > resolution service, and that intermediate URI contains neither a
> > fragment nor a query, the q-component (if present) is appended to the
> > intermediate URI as a query, and the f-component (if present) is
> > appended to the intermediate URI as a fragment (in that order).  The
> > resulting URI is then processed according to RFC 3986.
> >
> > Example: If the URN urn:example:foo?bar#zot appears in a link, the
> > client application might transmit the assigned-part of that URN
> > (urn:example:foo) to a resolution service with a request for resource
> > locations.   The resolution service might then return the intermediate
> > URI http://example.com/whatnot/xyzzy as one of those locations.   The
> > client would then append ?bar#zot to that intermediate URI producing
> > http://example.com/whatnot/xyzzy?bar#zot .   This URI would then be
> > processed per normal RFC 3986 rules.
> >
> > A resolution service MAY return an intermediate URI which contains a
> > fragment and/or a query.   If the intermediate URI contains a fragment
> > or a query, any f- or q-component from the URN is ignored.   (This
> > situation is basically no different than anyone composing a URI from a
> > base URI plus a fragment and/or query without being aware of what
> > fragments and/or queries are valid in the context of the named
> > resource.   Any user or document author may combine URIs with arbitrary
> > queries and/or fragments, but that doesn't mean that the results will
> > do what the user or author intended.)
> >
> > Example: If the URN urn:example:foo?bar#zot appeared in a link, a
> > resolution service might be requested to return locations of the URN
> > urn:example:foo .  If such a service returned an intermediate URI
> > http://example.com/whatnot/xyzzy?abcde , neither the q-
> component ?bar
> > nor the f-component #zot would be appended to the intermediate URI
> > before processing it.
> >
> > If the content of a resource named by a URN containing an f-component
> > is obtained directly from a resolution service, the f-component SHOULD
> > be treated as a "fragment" and evaluated with respect to that content,
> > just as if the content had been obtained from any other service.
> >
> > III. Relative References
> >
> > (new section)
> >
> > TBD.B. URNs and Relative References
> >
> > RFC 3986 section 5.2 describes an algorithm for converting a URI
> > reference that might be relative to a given base URI into "parsed
> > components" of the target of that reference, which can then be
> > recomposed per RFC 3986 section 5.3 into a target URI. If this
> > algorithm were applied directly to URNs, it would pragmatically have
> > the effect of imposing additional constraints on the naming of URNs
> > containing p-components, in order that relative references contained
> > in the resources named by those URNs would not break.  Alternatively,
> > resources named with URNs could be forbidden to contain relative
> references.
> > Neither of those alternatives seems attractive.   In addition, if the
> > same resources are accessible by both URN and URL, it is desirable to
> > permit relative references to work correctly in either case.
> >
> > Therefore a relative reference SHOULD NOT be evaluated with respect to =
a
> > URN.   Instead, a relative reference SHOULD be evaluated with respect t=
o
> > either
> >
> > (a) a BASE URI (other than a URN) declared by the resource itself, OR
> > (b) a BASE URI (other than a URN) obtained through the URN resolution
> > process, OR
> > (c) the URL of the resource as obtained through the URN resolution
> > process
> >
> > (Case (b) permits the resolution process to explicitly supply a BASE
> > URI if the resource content is supplied directly by the resolution
> > service rather than via an intermediate "location" URI.)
> >
> > If no such BASE URI exists, use of a relative reference with respect
> > to a URN is an error.
> >
> > Resolution services SHOULD ensure that a BASE URI is supplied any time
> > they provide resource content directly to a client.
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > urn mailing list
> > urn@ietf.org
> > https://www.ietf.org/mailman/listinfo/urn
> >
>=20
> --
>=20
> -------------------------------------------------------------------
> Leslie Daigle
> Principal, ThinkingCat Enterprises
> ldaigle@thinkingcat.com
> -------------------------------------------------------------------
>=20
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn


From nobody Fri Apr 24 03:04:58 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4841E1A1BC9 for ; Fri, 24 Apr 2015 03:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.051
X-Spam-Level: 
X-Spam-Status: No, score=-4.051 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1svrjrvuJM95 for ; Fri, 24 Apr 2015 03:04:54 -0700 (PDT)
Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 367831A1BC3 for ; Fri, 24 Apr 2015 03:04:52 -0700 (PDT)
Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id A33038ADFC for ; Fri, 24 Apr 2015 12:04:51 +0200 (CEST)
X-AuditID: 0a453fe7-f79106d0000047dd-71-553a15436444
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 71.16.18397.3451A355; Fri, 24 Apr 2015 12:04:51 +0200 (CEST)
Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Fri, 24 Apr 2015 12:04:51 +0200
From: "Svensson, Lars" 
To: "urn@ietf.org" 
Thread-Topic: [urn] "/" Re:  suggested text changes for -12 on p-components, f- and q-components in URN resolution, and relative references
Thread-Index: AQHQfdk4Ut/azroRdUa+8r12phUNpp1bh5uAgABmu5A=
Date: Fri, 24 Apr 2015 10:04:50 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EF010CF4FC6A@dnbf-ex1.AD.DDB.DE>
References: <55388B0E.3080806@network-heretics.com> <55390E00.8000401@thinkingcat.com> 
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.243]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLsWRmVeSWpSXmKPExsXC5Wr/VddZ1CrU4OxRZYupzR+YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcfbWV7aCFo6KSc3fmRoYF7F1MXJySAiYSHyaf4kFwhaTuHBv PVhcSOAIo8TxJRpdjFxA9nZGic4DT5m7GNk52AS0JN5ngJSICChK7HvWxA5SIizQwyhx91IP K4gjItDLKLG0+zILRJWVxPrLC4BsDg4WAVWJae8iQMK8At4SV9cfZYKYv5JR4k73YWaQBKdA tMTcKWeYQGxGAVmJDRvOg8WZBcQlNj37zgpxqIDEkj0QcQkBUYmXj/9BxRUlunbMZIWoN5B4 f24+VK+2xLKFr5khFgtKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxj5inPTDfUSU/RSUpL0 UlI3MUKi4PkOxr5LLocYBTgYlXh4ZRZYhgqxJpYVV+YeYvTnYFIS5d0kbBUqxJeUn1KZkVic EV9UmpNarCTC+wQkzAsXTirNyVaS49241CJUSBwuWlxaXJCZnJlfWhxfWpRziFGCgxmoNVEI pDUlsbIqtSgfYuAhRmkOFiVx3om7G0OEBNITS1KzU1MLUotgshEcHEoSvNkgOwWLUtNTK9Iy c0pg0kB99iAjBZBlwA5S5J0LcpAUsgS6m5g4OA8x+nDwAB12Deyn4oLE3OLMdKjZwrz/QGbz wETB5sryzlwGNFcMJohq5inGYClx3pkgwwRAKjJK8+BulRLjPQbSyo8kATJSSoFX7YdZqJAk kjiqqa8YPYFRJMz7DGQuDzAjIdwoxKsNEuSGCoKdKMN7EGSPKFQM3SwfYNyK8M4EhQ5vcUli CbKH/4JEeWCiUA//WAr2MFQQ1TipBsYllyWn2HkxTPx2Snp1h+GxwhYv0xtfdpXtuvt8a+oF vdTJJ2xZ98ke/tcY1H7rh3zOg8KjNoUR5gtsD3/wcXeY+4vpqZaPo37ca2OHr3tPim9cG7i0 7lf15duBIbEZLZ9edJxM+rplrtIuj3y7eI0vojrHvY7dYlrQ+ePD77e1EpvNj5x5u9ZIiaU4 I9FQi7moOBEABYlM+msEAAA=
Archived-At: 
Subject: Re: [urn] "/" Re:  suggested text changes for -12 on p-components, f- and q-components in URN resolution, and relative references
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Apr 2015 10:04:56 -0000

All,

> > Tackling one issue at a time :^)  -- I went back and re-read RFC3986 pe=
r
> > your point about "path-rootless", and came to the same conclusion.   I'=
m
> > not a (URI-)parser, though, so I wouldn't object to hearing confirmatio=
n from
> > someone who does deal in non-URN URI parsing for a living...
> >
> > Given that, I'd favour "c" as well -- allow "/" with no special signifi=
cance
> > imbued.
>=20
> "C" is my favourite option as well. Colleagues who are responsible of the
> national library's URN services informed me that "/" has been used often =
in
> (other organization's) internal identifiers which they wish to use as URN=
:NBNs.
> So avoiding the "/" is not an option. However, if "/" has been used in an
> identifier, it does not have any special (RFC 3986-based) significance.
>=20
> Percent encoding the character in NSS would bring no added value to the
> URN:NBN resolution.

+1

I shall get back with comments on resolution and relative references.

Best,

Lars


From nobody Fri Apr 24 07:37:30 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583651A1B82 for ; Fri, 24 Apr 2015 07:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oK-zTuONpg3 for ; Fri, 24 Apr 2015 07:37:22 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862521A0122 for ; Fri, 24 Apr 2015 07:37:17 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id EEF1F20EB4 for ; Fri, 24 Apr 2015 10:37:15 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Fri, 24 Apr 2015 10:37:15 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=wWdXl2UF9D+H6/MMW7cQXAydkm4=; b=jpha1 jlGFFuOtftM1lFGTOICm0rNzsmqJn1+ZgExs+fhsa/W+j7DZ9FaFLwmiqZ/MXzvc 1e2zvHu3W9jF2nRgQsmlfJAeLu14s4w7RkV7CU4aqxvhjhQDUxV2k43gs+096Fj0 by67iM798yqIRcN42bLvdU51Bk7aVAJZMMv+Jc=
X-Sasl-enc: 2vEemdcfaWzyNN6IQFlE8ZuyXOcoGJs3WsEewL+Mmd0h 1429886235
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 656856800DB; Fri, 24 Apr 2015 10:37:15 -0400 (EDT)
Message-ID: <553A5515.80505@network-heretics.com>
Date: Fri, 24 Apr 2015 10:37:09 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "urn@ietf.org" 
References: <5539CC41.4050204@network-heretics.com>
In-Reply-To: <5539CC41.4050204@network-heretics.com>
Content-Type: multipart/alternative; boundary="------------000708090308090204070604"
Archived-At: 
Subject: Re: [urn] suggested text for r-components
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Apr 2015 14:37:27 -0000

This is a multi-part message in MIME format.
--------------000708090308090204070604
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

The "suggested text for r-components" message I sent earlier was 
somewhat hurried and incomplete because I am leaving town for a few days 
and wanted to get something out the door before leaving.   But I woke up 
this morning and realized two things:

1. I had started out saying that r-components are needed to communicate 
parameters to resolution services and ended up saying they're for 
interpretation by clients.   I think these are both true, but I don't 
think I've adequately captured the relationship between the client's 
role and the resolution service's role.

2. I had started out saying that "constraints" are name = value pairs.   
At the last minute before sending the message I changed the grammar to 
make the "= value" part optional.   Because I think that there's likely 
to be a lot of potential variation in the kinds of constraints that 
resolution services implement, I think the name should actually specify 
the type of constraint (something akin to the computer language in which 
the constraint is being expressed) rather than, say, the name of the 
attribute that's being constrained.

Note:  I imagine that people will want to express constraints in a 
language that reflects the characters available in a URI according to 
RFC 3986.   So for instance while we might like to be able to express 
relational constraints, we don't have "<" and ">" available.   So we 
might end up using something like FORTRAN's notation - .lt. for less 
than, .gt. for greater than, and so on.


On 04/24/2015 12:53 AM, Keith Moore wrote:
> Okay, here's a first stab at text for r-components.   This isn't 
> complete; in particular the IANA section needs more prose.
>
> I am also sensitive to the concern Leslie expressed - i.e. that if I 
> don't happen to finish writing it down, someone will come along and 
> interpret it completely differently than was intended. (Or perhaps 
> more likely, if I am unable to specify this succinctly and yet with 
> sufficient clarity and detail.) This is currently missing both some 
> clarity and some detail, but it will be sometime next week before I 
> can look at it again.
>
> ---
>
> The basic idea is that an r-component consists of a request followed 
> by one or more constraints.   The request is something like U2R 
> (access an instance of the named resource), U2L (request locations of 
> the named resource), or U2C (request metadata about the named 
> resource).  (I'm not particularly fond of those names, and would be 
> happy with other names, but there is some history behind these names.)
>
> In each case, evaluating the request should produce a set of 
> results.   In the U2R case that set would be a set of resource 
> instances (even though only one of them could be ultimately used).   
> In the U2L case it would be a set of resource locations.  In the U2C 
> case it would be a set of resource descriptions. (The result set for 
> any of these requests can, of course, be the null set.)
>
> In any of these cases the items in the set may vary along certain 
> dimensions. For instance, a resource may exist in multiple revisions. 
> It may have versions in multiple languages.  It may be available in 
> different media types, e.g. HTML and PDF.  In the U2C case there may 
> be MARC records, Dublin Core metadata sets, etc.   The constraints 
> exist to narrow the result set.  Examples of constraints might be 
> things like "order by revision-date descending" or "limit to a maximum 
> of 10 results" or "include only resource instances with content-types 
> in [ application/pdf, text/html ]" or "include only resource 
> descriptions in the set [ dublin-core ]" or "revision dates between 
> 2001-1-1 and 2002-12-31".
>
> Constraints can be forwarded to URN resolution services to let the 
> filtering be done by the service; additional filtering may be done by 
> the client.  If a client or a resolution service doesn't know how to 
> implement a constraint, that constraint may be ignored.  (even though 
> this may produce a result set that contains members that don't satisfy 
> all of the constraints.)
>
> Both the set of requests and the set of results are extensible via an 
> IANA registry for each.   I would like to define the initial requests 
> as U2R, U2L, and U2C (perhaps by other names).   My current thinking 
> is to not define any constraints in this document, and leave 
> constraint definitions for other documents.   I expect that there will 
> be a need for both additional requests and a wide variety of 
> constraints, though I hope we can identify a minimal core set for each 
> that clients and resolution services can reasonably implement.
>
> --
>
> One thing I realized is that r-components probably should not be 
> evaluated entirely by the resolution service, because the client 
> application may have a role in satisfying the request.   For instance 
> the request (U2R) may be to access the actual resource named by the 
> URN, but the resolution service might not provide such access.  So in 
> that event the client needs to request locations from the resolution 
> service, pick one, and access the resource via that location.
>
> Another thing I realized is that resolution services will naturally 
> differ in which requests and constraints that they support, and it's 
> necessary for client software to be able to combine results from 
> different services in spite of this.   So whatever constraints are 
> implemented by a resolution service are essentially optimizations to 
> reduce server load and network traffic.   So my original thinking 
> about r-components was that they're parameters to be transmitted to 
> resolution services, now I think that they're more like search 
> constraints implemented on clients.
>
> --
>
> Anyway, here's a start at some text.
>
> These changes are relative to draft-ietf-urnbis-rfc2141bis-urn-11, not 
> to any other set of proposed changes.
>
> Section 3
>
> OLD:
>
>       namestring    = assigned-name
>                       [ q-component ]
>                       [ f-component ]
>       assigned-name = "urn" ":" NID ":" NSS [ p-component ]
>       NID           = (alphanum) 0*30(ldh) (alphanum)
>       ldh           = alphanum / "-"
>       NSS           = 1*(pchar)
>       p-component   = "/" path-absolute
>       q-component   = "?" query
>       f-component   = "#" fragment
>
> NEW:
>
> namestring    = assigned-name
>                       [ r-component ]
>                       [ q-component ]
>                       [ f-component ]
>       assigned-name = "urn" ":" NID ":" NSS [ p-component ]
>       NID           = (alphanum) 0*30(ldh) (alphanum)
>       ldh           = alphanum / "-"
>       NSS           = 1*(pchar)
>       p-component   = "/" path-absolute
>       q-component   = "?" query
>       f-component   = "#" fragment
>       r-component   = "??" request *(";" constraint)
>       request       = 1*(unreserved)
>       constraint    = name 0*1("=" value)
>       name          = alpha *(alphanum / ".") alphanum
>       value         = *( unreserved / pct-encoded
>                        / "!" / "$" / "&" / "'" / "(" / ")"
>                        / "*" / "+" / "," / "=" / ":" / "@"
>                        / "/" )
>
>
> (somewhere later in section 3)
>
> This grammar is syntax-compatible with the URI grammar in RFC 3986; 
> however, it parses the
> URN differently than the RFC 3986 grammar.   An RFC 3986 parser will 
> parse the combination
> of any "r-component" and/or "q-component" as a single "query".
>
>
> New section TBD.C:
>
>
> TBD.C.  r-component
>
>    In contrast to f-component (which specifies a fragment of the named 
> resource), and
>    q-component (which specifies a query to be sent to the named 
> resource), the optional
>    r-component specifies a default "use" of the URN.  Broadly 
> speaking, "use"s that have
>    been identified as desirable fall into one of three categories: 
> requests to access
>    the resource, requests to obtain one or more locations of the 
> resource, and requests
>    for information about the resource ("metadata").  The request may 
> be followed by
>    zero or more parameters which are interpreted as modifiers to the 
> request.   For
>    instance, the parameters might specify: revision or range of 
> revisions, language
>    or set of languages, acceptable media types, or a preference to 
> have the results
>    reported according to a particular schema and/or representation.   
> These parameters
>    generally have the effect of narrowing the set of responses or 
> potential responses
>    to a request.
>
>    More than one parameter with the same name MAY appear in an 
> r-component.
>
>    Implementation of requests and interpretation of parameters is the 
> job of URN-aware
>    client applications.  However, it is anticipated that URN 
> resolution services will
>    provide support for frequently used requests that appear in 
> r-components, and may
>    also interpret some of the parameters associated with r-components.
>
>    A URN-aware client application MAY ignore r-component requests 
> and/or parameters
>    when they specify a behavior that is not appropriate for the 
> context in which the
>    URN appears.  A client application MAY also permit a URN which 
> contains an
>    r-component to be used for a different purpose than that specified 
> in the r-component.
>    For example, if a URN appears in a "link" in a document, and the 
> request in the URN's
>    r-component specifies that the resource should be accessed 
> directly, clicking on the
>    link might cause the URN's target content to be displayed. However, 
> the client
>    application might also allow the user to request other behaviors 
> (say, via a
>    pull-down menu) such as to display the available locations and/or 
> metadata associated
>    with the URN.
>
>    If a URN does not include an r-component, the default use of the 
> URN is determined
>    by the client application and possibly by the context in which the 
> URN appears.
>
>    A client application MAY interpret an r-component's request and 
> attempt to implement
>    the specified default use independent of any resolution service.   
> For example,
>    if the request in a r-component specifies that the resource should 
> be accessed,
>    a client application MAY obtain a location of that resource from a 
> resolution
>    service and then arrange access to the resource via that location.
>
>    The set of requests is defined by an IANA registry. The set of 
> parameter names is
>    defined by a separate IANA registry. Parameter names beginning with a
>    IANA-registered URN namespace ID followed by "." are reserved for 
> definition by
>    that namespace.  This permits each namespace to define additional 
> parameters
>    which may be specific to its namespace or to the kinds of resources 
> to which
>    it assigns URNs.
>
>    r-components are not considered significant for the purpose of 
> comparing URNs
>    for equivalence.
>
>
> New section 8.3:
>
> 8.3.   Registration of URN r-component request names
>
>        r-component requests are intended for broad categories of 
> requests for
>        URN processing that could reasonably be fulfilled by resolution 
> services,
>        and/or by clients capable of processing URNs.
>
>        The set of request names that are prefixed by a registered URN 
> namespace
>        followed by "." is reserved for definition by that namespace.   
> A namespace
>        MAY register such names with IANA but is not required to do 
> so.  Registration
>        of additional request names not prefixed by a registered URN 
> namespace
>        requires IETF consensus.
>
>        IANA is hereby requested to register the following URN 
> r-component request
>        names:
>
>        Request-name: "U2R"
>        Purpose:  This is used to request access to the named resource.
>
>        Request-name: "U2L"
>        Purpose:  This is used to request zero or more locations of the 
> named resource.
>
>        Request-name: "U2C"
>        Purpose:  This is used to request information about the named 
> resource (metadata).
>
> 8.4.   Registration of URN r-component parameter names
>
>        *** to be written ***
>
>
>


--------------000708090308090204070604
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
The "suggested text for r-components"
      message I sent earlier was somewhat hurried and incomplete because
      I am leaving town for a few days and wanted to get something out
      the door before leaving.   But I woke up this morning and realized
      two things:

      

      1. I had started out saying that r-components are needed to
      communicate parameters to resolution services and ended up saying
      they're for interpretation by clients.   I think these are both
      true, but I don't think I've adequately captured the relationship
      between the client's role and the resolution service's role.

      

      2. I had started out saying that "constraints" are name = value
      pairs.   At the last minute before sending the message I changed
      the grammar to make the "= value" part optional.   Because I think
      that there's likely to be a lot of potential variation in the
      kinds of constraints that resolution services implement, I think
      the name should actually specify the type of constraint (something
      akin to the computer language in which the constraint is being
      expressed) rather than, say, the name of the attribute that's
      being constrained. 

      

      Note:  I imagine that people will want to express constraints in a
      language that reflects the characters available in a URI according
      to RFC 3986.   So for instance while we might like to be able to
      express relational constraints, we don't have "<" and ">"
      available.   So we might end up using something like FORTRAN's
      notation - .lt. for less than, .gt. for greater than, and so on.

      

      

      On 04/24/2015 12:53 AM, Keith Moore wrote:

    

    

      
      Okay, here's a first
          stab at text for r-components.   This isn't complete; in
          particular the IANA section needs more prose.   

          

          I am also sensitive to the concern Leslie expressed - i.e.
          that if I don't happen to finish writing it down, someone will
          come along and interpret it completely differently than was
          intended.   (Or

              perhaps more likely, if I am unable to specify this
              succinctly and yet with sufficient clarity and detail.)  
              This is currently missing both some clarity and some
              detail, but it will be sometime next week before I can
              look at it again.

              

              ---

              

              The basic idea is that an r-component consists of a
              request followed by one or more constraints.   The request
              is something like U2R (access an instance of the named
              resource), U2L (request locations of the named resource),
              or U2C (request metadata about the named resource).  (I'm
              not particularly fond of those names, and would be happy
              with other names, but there is some history behind these
              names.)

              

              In each case, evaluating the request should produce a set
              of results.   In the U2R case that set would be a set of
              resource instances (even though only one of them could be
              ultimately used).   In the U2L case it would be a set of
              resource locations.  In the U2C case it would be a set of
              resource descriptions.    (The result set for any of these
                      requests can, of course, be the null set.)

                      

                    In any of these cases
              the items in the set may vary along certain dimensions. 
              For instance, a resource may exist in multiple revisions. 
              It may have versions in multiple languages.  It may be
              available in different media types, e.g. HTML and PDF.  In
              the U2C case there may be MARC records, Dublin Core
              metadata sets, etc.   The constraints exist to narrow the
              result set.  Examples of constraints might be things like
              "order by revision-date descending" or "limit to a maximum
              of 10 results" or "include only resource instances with
              content-types in [ application/pdf, text/html ]" or
              "include only resource descriptions in the set [
              dublin-core ]" or "revision dates between 2001-1-1 and
              2002-12-31".

              

              Constraints can be forwarded to URN resolution services to
              let the filtering be done by the service; additional
              filtering may be done by the client.  If a client or a
              resolution service doesn't know how to implement a
              constraint, that constraint may be ignored.  (even though
              this may produce a result set that contains members that
              don't satisfy all of the constraints.)

              

              Both the set of requests and the set of results are
              extensible via an IANA registry for each.   I would like
              to define the initial requests as U2R, U2L, and U2C
              (perhaps by other names).   My current thinking is to not
              define any constraints in this document, and leave
              constraint definitions for other documents.   I expect
              that there will be a need for both additional requests and
              a wide variety of constraints, though I hope we can
              identify a minimal core set for each that clients and
              resolution services can reasonably implement.

              

              --

              

              One thing I realized is that r-components probably should
              not be evaluated entirely by the resolution service,
              because the client application may have a role in
              satisfying the request.   For instance the request (U2R)
              may be to access the actual resource named by the URN, but
              the resolution service might not provide such access.  So
              in that event the client needs to request locations from
              the resolution service, pick one, and access the resource
              via that location.

              

              Another thing I realized is that resolution services will
              naturally differ in which requests and constraints that
              they support, and it's necessary for client software to be
              able to combine results from different services in spite
              of this.   So whatever constraints are implemented by a
              resolution service are essentially optimizations to reduce
              server load and network traffic.   So my original thinking
              about r-components was that they're parameters to be
              transmitted to resolution services, now I think that
              they're more like search constraints implemented on
              clients.

              

              --

              

              Anyway, here's a start at some text.

            

          These changes are relative to
          draft-ietf-urnbis-rfc2141bis-urn-11, not to any other set of
          proposed changes.

          

          Section 3

            

          OLD:

            

                  namestring    = assigned-name

                                [ q-component ]

                                [ f-component ]

                assigned-name = "urn" ":" NID ":" NSS [
            p-component ]

                NID           = (alphanum) 0*30(ldh) (alphanum)

                ldh           = alphanum / "-"

                NSS           = 1*(pchar)

                p-component   = "/" path-absolute

                q-component   = "?" query

                f-component   = "#" fragment

        

          NEW:

        

           
            namestring    = assigned-name

                                  [ r-component ]

                                 [ q-component ]

                                [ f-component ]

                assigned-name = "urn" ":" NID ":" NSS [
            p-component ]

                NID           = (alphanum) 0*30(ldh) (alphanum)

                ldh           = alphanum / "-"

                NSS           = 1*(pchar)

                p-component   = "/" path-absolute

                q-component   = "?" query

                 f-component   = "#" fragment

              r-component   = "??" request *(";" constraint)

              request       = 1*(unreserved)

              constraint    = name 0*1("=" value)

              name          = alpha *(alphanum / ".") alphanum

              value         = *( unreserved / pct-encoded 

                               / "!" / "$" / "&" / "'" / "(" / ")" 

                               / "*" / "+" / "," / "=" / ":" / "@"

                               / "/" )

        

      

      (somewhere later in section 3)

        

        This grammar is syntax-compatible with the URI grammar in RFC
        3986; however, it parses the 

        URN differently than the RFC 3986 grammar.   An RFC 3986 parser
        will parse the combination

        of any "r-component" and/or "q-component" as a single "query".

        

        

      New section TBD.C:

        

        

        TBD.C.  r-component

        

           In contrast to f-component (which specifies a fragment of the
        named resource), and

           q-component (which specifies a query to be sent to the named
        resource), the optional 

           r-component specifies a default "use" of the URN.  Broadly
        speaking, "use"s that have 

           been identified as desirable fall into one of three
        categories: requests to access 

           the resource, requests to obtain one or more locations of the
        resource, and requests

           for information about the resource ("metadata").  The request
        may be followed by 

           zero or more parameters which are interpreted as modifiers to
        the request.   For 

           instance, the parameters might specify: revision or range of
        revisions, language 

           or set of languages, acceptable media types, or a preference
        to have the results 

           reported according to a particular schema and/or
        representation.   These parameters

           generally have the effect of narrowing the set of responses
        or potential responses

           to a request.

        

           More than one parameter with the same name MAY appear in an
        r-component. 

        

           Implementation of requests and interpretation of parameters
        is the job of URN-aware

           client applications.  However, it is anticipated that URN
        resolution services will

           provide support for frequently used requests that appear in
        r-components, and may 

           also interpret some of the parameters associated with
        r-components.  

        

           A URN-aware client application MAY ignore r-component
        requests and/or parameters

           when they specify a behavior that is not appropriate for the
        context in which the

           URN appears.  A client application MAY also permit a URN
        which contains an 

           r-component to be used for a different purpose than that
        specified in the r-component.

           For example, if a URN appears in a "link" in a document, and
        the request in the URN's 

           r-component specifies that the resource should be accessed
        directly, clicking on the 

           link might cause the URN's target content to be displayed. 
        However, the client 

           application might also allow the user to request other
        behaviors (say, via a 

           pull-down menu) such as to display the available locations
        and/or metadata associated

           with the URN.

        

           If a URN does not include an r-component, the default use of
        the URN is determined

           by the client application and possibly by the context in
        which the URN appears.

        

           A client application MAY interpret an r-component's request
        and attempt to implement 

           the specified default use independent of any resolution
        service.   For example,

           if the request in a r-component specifies that the resource
        should be accessed,

           a client application MAY obtain a location of that resource
        from a resolution   

           service and then arrange access to the resource via that
        location. 

        

           The set of requests is defined by an IANA registry.  The

          set of parameter names is

             defined by a separate IANA registry.  Parameter

          names beginning with a 

             IANA-registered URN namespace ID followed by "." are
          reserved for definition by

             that namespace.  This permits each namespace to define
          additional parameters 

             which may be specific to its namespace or to the kinds of
          resources to which 

             it assigns URNs.

      

           r-components are not considered significant for the purpose
        of comparing URNs

           for equivalence.

        

        

        New section 8.3:

        

        8.3.   Registration of URN r-component request names

        

               r-component requests are intended for broad categories of
        requests for

               URN processing that could reasonably be fulfilled by
        resolution services,

               and/or by clients capable of processing URNs.

        

               The set of request names that are prefixed by a
        registered URN namespace 

               followed by "." is reserved for definition by that
        namespace.   A namespace

               MAY register such names with IANA but is not required to
        do so.  Registration 

               of additional request names not prefixed by a registered
        URN namespace

               requires IETF consensus.

        

               IANA is hereby requested to register the following URN
        r-component request

               names:

        

               Request-name: "U2R"

               Purpose:  This is used to request access to the named
        resource.

        

               Request-name: "U2L"

               Purpose:  This is used to request zero or more locations
        of the named resource.

        

               Request-name: "U2C"

               Purpose:  This is used to request information about the
        named resource (metadata).   

        

        8.4.   Registration of URN r-component parameter names

        

             *** to be written ***

        

        

           

        

    

  


--------------000708090308090204070604--


From nobody Fri Apr 24 09:58:26 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAC21B378A for ; Fri, 24 Apr 2015 09:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.544
X-Spam-Level: ***
X-Spam-Status: No, score=3.544 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, MANGLED_OFF=2.3, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNufCoHh2EEd for ; Fri, 24 Apr 2015 09:58:20 -0700 (PDT)
Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB941B378C for ; Fri, 24 Apr 2015 09:58:20 -0700 (PDT)
Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id B24E82005E806; Fri, 24 Apr 2015 09:58:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= thinkingcat.com; bh=ilpIMYCp0GKarY9ZWhBd1jfFgDQ=; b=FFNpc07kncC6 qeTapteM725IWc+tyBxuD1aQZzfsAyEcPLfw0n4L4aF/DAk8Jw5Epb1mMHihp/WG cVBuey6FPgLswtWSf4Qx1fy3N6lAnKhxqePDbW/cfs/BLDOfP6+HRHNxuGUiiU+w JBPrhRyQMq2r4SmFllzQjQLDtRpfZi4=
Received: from aran-w.int.lexiconix.com (pool-108-44-246-138.clppva.fios.verizon.net [108.44.246.138]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id A77682005E804; Fri, 24 Apr 2015 09:58:18 -0700 (PDT)
Message-ID: <553A7629.8050403@thinkingcat.com>
Date: Fri, 24 Apr 2015 12:58:17 -0400
From: "Leslie Daigle (ThinkingCat)" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <55388B0E.3080806@network-heretics.com>
In-Reply-To: <55388B0E.3080806@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [urn] III Relative references Re: suggested text changes for -12 on p-components, f- and q-components in URN resolution, and relative references
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Apr 2015 16:58:25 -0000

I think the proposed section on Relative References works (modulo
removal of discussion of p-components, if that's how the consensus rolls).

Proposed approach:

KEITH:
> RFC 3986 section 5.2 describes an algorithm for converting a URI
> reference that might be relative to a given base URI into "parsed
> components" of the target of that reference, which can then be
> recomposed per RFC 3986 section 5.3 into a target URI. If this
> algorithm were applied directly to URNs, it would pragmatically have
> the effect of imposing additional constraints on the naming of URNs
> containing p-components, in order that relative references contained
> in the resources named by those URNs would not break.  Alternatively,
> resources named with URNs could be forbidden to contain relative
> references.   Neither of those alternatives seems attractive.





ALTERNATIVELY:
RFC 3986 section 5.2 describes an algorithm for converting a URI
reference that might be relative to a given base URI into "parsed
components" of the target of that reference, which can then be
recomposed per RFC 3986 section 5.3 into a target URI.   This algorithm
cannot be applied directly to URNs because their syntax does not support
the necessary path components.  The notion of a "persistent",
"permanent" identifier (URN) does not reconcile easily with relative
referencing.  However, resources named with URNs may contain relative
references that do not apply to the URN itself.



Leslie.

On 4/23/15 2:02 AM, Keith Moore wrote:
> Here are my suggestions for changes to
> draft-ietf-urnbis-rfc2141bis-11 based on last Friday's conference
> call.
>
> I will try to also suggest text for r-components in a separate
> message, hopefully sometime tomorrow.  If I don't get it out by
> tomorrow it will be early next week.
>
>
> I. p-components
>
> If we have consensus that (a) relative references in resources named
>  by URNs are always evaluated with respect to a base URI that is not
> a URN, and (b) there's no special need for URNs to be able to contain
> "paths", then we have several choices:
>
> (a) Disallow p-components in the 2141bis grammar, OR (b) Allow
> p-components in the 2141bis grammar, but reserve them for future use.
> basically this means that parsers would recognize p-components, and
> p-components would be transmitted to resolution services, but
> namespaces shouldn't assign names containing p-components until a
> standards-track document explains how to do so, OR (c) Permit "/" in
>  NSS arbitrarily without giving any special significance to them.
>
> Any of these seem workable but I lean toward either (a) or (c) -
> maybe a bit more toward (c) because I suspect there are namespaces
> that assign names containing "/" which could more easily be URN
> namespaces if "/" did not need to be %-encoded.
>
> (I don't think that (c) breaks RFC 3986 compatibility because that
> "path" component of a URN (according to the 3986 grammar) never
> begins with "/" because a namespace never begins with a "/".   The
> namespace:NSS portion of a URN always matches "path-rootless", and
> "path-rootless" can containing an arbitrary number of "/"s in a row
> because "segment" is defined to be zero or more "pchar"s.   See RFC
> 3986 mostly section 3.3)
>
> Since there are three choices, I'm supplying three sets of changes,
> color-coded to hopefully minimize confusion as one scrolls back and
> forth through the message.   Pick only one :)   Note that in all
> cases the new text is shorter than the old; I take that as a
> favorable sign.
>
> Option (a): Disallow p-components in the 2141bis grammar
>
> Section 3
>
> OLD:
>
> namestring    = assigned-name [ q-component ] [ f-component ]
> assigned-name = "urn" ":" NID ":" NSS [ p-component ] NID =
> (alphanum) 0*30(ldh) (alphanum) ldh           = alphanum / "-" NSS =
> 1*(pchar) p-component   = "/" path-absolute q-component   = "?" query
> f-component   = "#" fragment
>
> Note that "/" can be used without percent-encoding inside
> p-components and that "?" can be used without percent-encoding
> inside q-components and f-components.
>
> NEW:
>
> namestring    = assigned-name [ q-component ] [ f-component ]
> assigned-name = "urn" ":" NID ":" NSS NID           = (alphanum)
> 0*30(ldh) (alphanum) ldh           = alphanum / "-" NSS           =
> 1*(pchar) q-component   = "?" query f-component   = "#" fragment
>
> Note that "?" can be used without percent-encoding inside
> q-components and f-components.
>
> Section 3.3
>
> OLD
>
> 3.3.  p-component, q-component, and f-component
>
> The p-component, q-component, and f-component are optional
> components that follow the assigned-name.  In terms of URI syntax
> these components are essentially equivalent to the URI
> "path-absolute", "query", and "fragment" constructions, respectively.
> However, the URN p-component, q-component, and f-component need not
> be semantically equivalent to the URI path component, query
> component, and fragment component; therefore they are called by
> different names in this specification.
>
> Unless specifically defined for a particular namespace after
> publication of this document, use of these components is disallowed,
> thereby maintaining strict backward compatibility with namespaces
> defined in accordance with [RFC2141] and registered in accordance
> with [RFC3406].
>
> This specification does not define the semantics of the p-component,
> q-component, and f-component for URNs in general. Instead, additional
> specifications might establish these matters for URN- related
> services (such as URN resolution) or for individual URN namespaces
> (e.g., to handle extended information about the resource identified
> by a URN).  For example, it is possible that the q-component might be
> used in requests to URN resolution services, or that the f-component
> might be used to distinguish the integral parts of resources named by
> URNs in particular namespaces (say, the chapters of a book). However,
> defining such usage is the responsibility of specifications for URN
> resolution services, namespace registration requests and
> specifications for individual namespaces, and other appropriate
> documentation (such as policy documents governing the management of a
> given URN namespace).
>
> As general guidance that might not apply to all cases, it would be
> inappropriate for namespaces that do not intend to support
> resolution services to allow q-components.  Namespaces that deal with
> digital manifestations might be able to support f-components. At the
> time of writing, no general guidance can be provided for use of
> p-components.
>
> NEW
>
> 3.3.  q-component and f-component
>
> The q-component and f-component are optional componentsthat follow
> the assigned-name.  In terms of URI syntax thesecomponents are
> essentially equivalent to the URI"query", and "fragment"
> constructions, respectively.  However, thesemantics of the URN
> q-component and f-component are subtly different than the semantics
> of the generic URI equivalents, therefore they are called by
> different namesin this specification.
>
> Note: URN syntax provides no equivalent to the "path" component of a
>  generic URI.
>
> See section [TBD.A] for a description on how the URN q-component and
>  f-component affect resolution of a URN, and section [TBD.B] for how
>  relative references are evaluated with respect to a URN.
>
>
> Section 3.3.1 (delete)
>
> Section 4.1
>
> OLD:
>
> If a p-component is included in a URN, it MUST be identical
> (including case sensitivity) in the strings being compared.
>
> NEW: (delete this paragraph)
>
> Section 4.2
>
> (delete examples using "/" in NSS, whether or not percent-encoded)
>
> Section 7.3.2
>
> OLD:
>
> 3.  If p-components, q-components, and/or f-components are allowed
> for the namespace, a discussion of how they are used.
>
>
> NEW: (delete this paragraph. use or handling of f-components and
> q-components should not be namespace-specific)
>
>
> Option (b):  Allow p-components in the 2141bis grammar, but reserve
> them for future use.
>
> OLD:
>
> 3.3.  p-component, q-component, and f-component
>
> The p-component, q-component, and f-component are optional
> components that follow the assigned-name.  In terms of URI syntax
> these components are essentially equivalent to the URI
> "path-absolute", "query", and "fragment" constructions, respectively.
> However, the URN p-component, q-component, and f-component need not
> be semantically equivalent to the URI path component, query
> component, and fragment component; therefore they are called by
> different names in this specification.
>
> Unless specifically defined for a particular namespace after
> publication of this document, use of these components is disallowed,
> thereby maintaining strict backward compatibility with namespaces
> defined in accordance with [RFC2141] and registered in accordance
> with [RFC3406].
>
> This specification does not define the semantics of the p-component,
> q-component, and f-component for URNs in general. Instead, additional
> specifications might establish these matters for URN- related
> services (such as URN resolution) or for individual URN namespaces
> (e.g., to handle extended information about the resource identified
> by a URN).  For example, it is possible that the q-component might be
> used in requests to URN resolution services, or that the f-component
> might be used to distinguish the integral parts of resources named by
> URNs in particular namespaces (say, the chapters of a book). However,
> defining such usage is the responsibility of specifications for URN
> resolution services, namespace registration requests and
> specifications for individual namespaces, and other appropriate
> documentation (such as policy documents governing the management of a
> given URN namespace).
>
> As general guidance that might not apply to all cases, it would be
> inappropriate for namespaces that do not intend to support
> resolution services to allow q-components.  Namespaces that deal with
> digital manifestations might be able to support f-components. At the
> time of writing, no general guidance can be provided for use of
> p-components.
>
> NEW:
>
> 3.3.  p-component, q-component, and f-component
>
> The p-component, q-component, and f-component are optional
> components that follow the assigned-name.  In terms of URI syntax
> these components are essentially equivalent to the URI
> "path-absolute", "query", and "fragment" constructions, respectively.
> However, the URN p-component, q-component, and f-component are not
> semantically equivalent to the URI path component, query component,
> and fragment component; therefore they are called by different names
> in this specification.
>
> See section [TBD.A] for a description on how the URN q-component and
>  f-component affect resolution of a URN, and section [TBD.B] for how
>  relative references are evaluated with respect to a URN.
>
> p-components are reserved for future use.  Implementations which
> recognize URNs MUST parse URNs according to the grammar described in
> this document, and MUST include the entire assigned portion of a URN
> (including any p-component) to a resolution service. However,
> namespaces MUST NOT assign URNs containing p-components. This
> restriction on use of p-components may be relaxed in a later
> specification.
>
> section 3.3.1:
>
> OLD
>
> 3.3.1.  p-component
>
> The only formal restriction placed upon a p-component by this
> specification is that the syntax SHALL adhere to the "path-absolute"
> rule from [RFC3986].  The specification for a particular namespace or
> URN-related service MAY define further syntax restrictions within the
> p-component.  (For example, a namespace specification might define a
> character such as "~" or "@" as a delimiter inside p-components
> assigned within that namespace.)  Note that characters outside the
> ASCII range [RFC20] MUST be percent-encoded using the method defined
> in Section 2.1 of the generic URI specification [RFC3986].
>
> Consider the hypothetical example of a hierarchical naming system in
> which the identifiers take the form of a series of numbers separated
> by the "/" character, such as "1/406/47452/2".  If the naming
> authority for such identifiers were to use URNs, it would be natural
> to place the existing identifiers in the p-component, resulting in
> URNs such as "urn:example/1/406/47452/2" (using the "example" URN
> namespace [RFC6963] instead of a registered NID).
>
> As described under Section 4, the p-component SHALL be taken into
> account when determining URN equivalence.
>
> NEW
>
> [[Note:  Maybe I misunderstand, but I think the -11 text is incorrect
> in syntax even if we don't change the semantics of p-components at
> all. As I read 3986, the URI "path" corresponds to the URN
> namespace:NSS, so the "path" never begins with "/" and can never
> correspond to "path-absolute".   (Yes, we can reuse that production
> from the 3986 grammar if we want to do so, but I see no reason to do
> so.)   And the example given in the next paragraph is also incorrect,
> because there would need to be a ":" after the namespace
> "example".]]
>
> 3.3.1.  p-component
>
> p-component is reserved for future use.  Namespaces MUST NOT assign
> URNs with p-components.  A future specification may permit
> p-components while possibly imposing other constraints on their use.
>
> However, software that recognizes URNs MUST parse URNs (including
> p-components) according to the grammar in this document, and MUST
> present the entire "assigned-name" portion of a URN to a resolution
> service when resolving the URN.
>
> As described under Section 4, the p-component SHALL be taken into
> account when determining URN equivalence.
>
> Section 7.3.2:
>
> OLD
>
> 3.  If p-components, q-components, and/or f-components are allowed
> for the namespace, a discussion of how they are used.
>
> NEW:  (delete this.  use or interpretation of f- and q-components
> should not be namespace-specific)
>
>
> Option (c): Permit "/" in NSS arbitrarily without giving any special
>  significance to them.
>
> Section 3:
>
> OLD
>
> namestring    = assigned-name [ q-component ] [ f-component ]
> assigned-name = "urn" ":" NID ":" NSS [ p-component ] NID =
> (alphanum) 0*30(ldh) (alphanum) ldh           = alphanum / "-" NSS =
> 1*(pchar) p-component   = "/" path-absolute q-component   = "?" query
> f-component   = "#" fragment
>
> Note that "/" can be used without percent-encoding inside
> p-components and that "?" can be used without percent-encoding
> inside q-components and f-components.
>
> NEW
>
> namestring    = assigned-name [ q-component ] [ f-component ]
> assigned-name = "urn" ":" NID ":" NSS NID           = (alphanum)
> 0*30(ldh) (alphanum) ldh           = alphanum / "-" NSS           =
> 1*(pchar / "/") q-component   = "?" query f-component   = "#"
> fragment
>
> Note that "?" can be used without percent-encoding inside
> q-components and f-components.
>
> Section 3.3
>
> OLD
>
> 3.3.  p-component, q-component, and f-component
>
> The p-component, q-component, and f-component are optional
> components that follow the assigned-name.  In terms of URI syntax
> these components are essentially equivalent to the URI
> "path-absolute", "query", and "fragment" constructions, respectively.
> However, the URN p-component, q-component, and f-component need not
> be semantically equivalent to the URI path component, query
> component, and fragment component; therefore they are called by
> different names in this specification.
>
> Unless specifically defined for a particular namespace after
> publication of this document, use of these components is disallowed,
> thereby maintaining strict backward compatibility with namespaces
> defined in accordance with [RFC2141] and registered in accordance
> with [RFC3406].
>
> This specification does not define the semantics of the p-component,
> q-component, and f-component for URNs in general. Instead, additional
> specifications might establish these matters for URN- related
> services (such as URN resolution) or for individual URN namespaces
> (e.g., to handle extended information about the resource identified
> by a URN).  For example, it is possible that the q-component might be
> used in requests to URN resolution services, or that the f-component
> might be used to distinguish the integral parts of resources named by
> URNs in particular namespaces (say, the chapters of a book). However,
> defining such usage is the responsibility of specifications for URN
> resolution services, namespace registration requests and
> specifications for individual namespaces, and other appropriate
> documentation (such as policy documents governing the management of a
> given URN namespace).
>
> As general guidance that might not apply to all cases, it would be
> inappropriate for namespaces that do not intend to support
> resolution services to allow q-components.  Namespaces that deal with
> digital manifestations might be able to support f-components. At the
> time of writing, no general guidance can be provided for use of
> p-components.
>
> NEW
>
> 3.3.  q-component and f-component
>
> The q-component and f-component are optional components that follow
> the assigned-name.  In terms of URI syntax these components are
> essentially equivalent to the URI "query", and "fragment"
> constructions, respectively. However, the URN  q-component, and
> f-component are not quite semantically equivalent to the URI query
> component and fragment component; therefore they are called by
> different names in this specification.
>
> See section [TBD.A] for a description on how the URN q-component and
>  f-component affect resolution of a URN, and section [TBD.B] for how
>  relative references are evaluated with respect to a URN.
>
> Section 3.3.1 (delete this section)
>
> Section 4.1
>
> OLD
>
> If a p-component is included in a URN, it MUST be identical
> (including case sensitivity) in the strings being compared.
>
> NEW (delete this paragraph)
>
> Section 4.2
>
> (delete examples containing p-components and text referring to
> p-components)
>
> Section 7.3.2
>
> OLD
>
> 3.  If p-components, q-components, and/or f-components are allowed
> for the namespace, a discussion of how they are used.
>
> NEW (delete this item; f- and q-components should not be
> namespace-specific)
>
>
> II. URN resolution
>
> Notes:
>
> 1. My first cut at this said that a client MUST NOT include a
> q-component or f-component in a URN sent in a request to a resolution
> service.  Then I realized that a resolution service might in some
> circumstances provide access to resource content (say by caching it),
> or act as a proxy to a resource, in which circumstances interpreting
> the q-component might be appropriate.   So now the client MUST NOT
> include q-component or f-component unless it's requesting that the
> resolution service provide access to the resource itself, and the
> resolution service is supposed to ignore the q-component except when
> it needs to send it as a query to the resource, and to ignore the
> f-component.   But this bothers me somewhat, and I'd like for the
> rules to be simpler while still maintaining a layer separation
> between the resolution service and the resources which it names. The
> simplest solution is probably to say that resolution services never
> provide access to resource content, only to locations and metadata.
> However, it's long been expected that resolution services could
> provide access to resource content.
>
> 2. Lars Svensson pointed out to me in private mail that a resolution
>  service could potentially return a URL with query and/or fragment,
> so this text takes a position on how to interpret such a URL when the
>  original URN also had an q-component and/or f-component.   I thought
>  it made more sense to ignore those components from the original URN
>  in that case.   There are other positions that could be taken, e.g.
>  that resolution services should not be permitted to return URLs with
>  queries and/or fragments, but I actually think it can be reasonable
>  for them to do so.
>
>
> (new section.  note: text in brackets/italics about r-components
> should only be included if r-component proposal is adopted)
>
> TBD.A. Use of f- and q-components in URN resolution
>
> Since a URN, by design, does not contain either explicitly or
> implicitly the name or address of a network service which can be used
> to access the resource named by the URN, an application wishing to
> access that resource must somehow discover one or more "resolution
> services" which can, given the URN, either provide the resource
> content directly, or provide information to the application to enable
> it to access the resource.
>
> Though f- and q-components may appear in a URN, they are not assigned
> or managed by the URN namespace, but instead evaluated in the context
> of the named resource.   Specifically, an f-component of a URN refers
> to a "fragment" of the resource named by the URN, and a q-component
> of a URN is used to specify a "query" to be evaluated by the resource
> named by the URN.   This convention ensures consistent use of these
> components across all URN namespaces, and preserves the ability to
> reference "fragments" of resources named by URNs that have fragments,
> and to specify "queries" with resources named by URNs that support
> queries. In order to preserve this ability, f-components and
> q-components MUST NOT be transmitted to a URN resolution service
> except when that service is being requested to provide direct access
>  (or access via proxy) to the resource itself.   For all other
> requests, the client MUST transmit only the "assigned-part" of a URN
>  /[ along with any r-component//, if specified ]/ to the URN
> resolution service.
>
> A resolution service processing a request for a URN MUST ignore any
> f-component or q-component of that URN unless the request is to
> provide direct access (or access via proxy) to the named resource.
> If the request is to provide access to the named resource (as opposed
>  to, say, resource locations or resource metadata), the resolution
> service MUST ignore the f-component of the URN and SHOULD (if
> possible) process the q-component as if it were a query transmitted
> to the resource, returning the resource's response to that query. If
> the resolution service cannot provide the requested access to the
> resource, but instead returns resource locations, the f-component and
> q-component of the request URN MUST be ignored in determining these
> locations, and MUST NOT be included as fragment and query
> (respectively) in the returned locations.
>
> These rules are intended to impose a layer separation between the URN
> resolution service and the content, and to discourage the URN
> resolution service from returning different results depending on the
>  presence of f- and/or q-components in the request.
>
> If the resource named by a URN that contains an f- and/or q-component
> is accessed via an intermediate URI (other than a URN) obtained from
> a resolution service, and that intermediate URI contains neither a
> fragment nor a query, the q-component (if present) is appended to the
> intermediate URI as a query, and the f-component (if present) is
> appended to the intermediate URI as a fragment (in that order).  The
> resulting URI is then processed according to RFC 3986.
>
> Example: If the URN urn:example:foo?bar#zot appears in a link, the
> client application might transmit the assigned-part of that URN
> (urn:example:foo) to a resolution service with a request for resource
> locations.   The resolution service might then return the
> intermediate URI http://example.com/whatnot/xyzzy as one of those
> locations.   The client would then append ?bar#zot to that
> intermediate URI producing http://example.com/whatnot/xyzzy?bar#zot .
> This URI would then be processed per normal RFC 3986 rules.
>
> A resolution service MAY return an intermediate URI which contains a
>  fragment and/or a query.   If the intermediate URI contains a
> fragment or a query, any f- or q-component from the URN is ignored.
> (This situation is basically no different than anyone composing a URI
> from a base URI plus a fragment and/or query without being aware of
> what fragments and/or queries are valid in the context of the named
> resource.   Any user or document author may combine URIs with
> arbitrary queries and/or fragments, but that doesn't mean that the
> results will do what the user or author intended.)
>
> Example: If the URN urn:example:foo?bar#zot appeared in a link, a
> resolution service might be requested to return locations of the URN
>  urn:example:foo .  If such a service returned an intermediate URI
> http://example.com/whatnot/xyzzy?abcde , neither the q-component ?bar
> nor the f-component #zot would be appended to the intermediate URI
> before processing it.
>
> If the content of a resource named by a URN containing an f-component
> is obtained directly from a resolution service, the f-component
> SHOULD be treated as a "fragment" and evaluated with respect to that
> content, just as if the content had been obtained from any other
> service.
>
> III. Relative References
>
> (new section)
>
> TBD.B. URNs and Relative References
>
> RFC 3986 section 5.2 describes an algorithm for converting a URI
> reference that might be relative to a given base URI into "parsed
> components" of the target of that reference, which can then be
> recomposed per RFC 3986 section 5.3 into a target URI. If this
> algorithm were applied directly to URNs, it would pragmatically have
>  the effect of imposing additional constraints on the naming of URNs
>  containing p-components, in order that relative references contained
>  in the resources named by those URNs would not break. Alternatively,
> resources named with URNs could be forbidden to contain relative
> references. Neither of those alternatives seems attractive.   In
> addition, if the same resources are accessible by both URN and URL,
> it is desirable to permit relative references to work correctly in
> either case.
>
> Therefore a relative reference SHOULD NOT be evaluated with respect
> to a URN.   Instead, a relative reference SHOULD be evaluated with
> respect to either
>
> (a) a BASE URI (other than a URN) declared by the resource itself,
> OR (b) a BASE URI (other than a URN) obtained through the URN
> resolution process, OR (c) the URL of the resource as obtained
> through the URN resolution process
>
> (Case (b) permits the resolution process to explicitly supply a BASE
>  URI if the resource content is supplied directly by the resolution
> service rather than via an intermediate "location" URI.)
>
> If no such BASE URI exists, use of a relative reference with respect
>  to a URN is an error.
>
> Resolution services SHOULD ensure that a BASE URI is supplied any
> time they provide resource content directly to a client.
>
>
>
>
>
>
> _______________________________________________ urn mailing list
> urn@ietf.org https://www.ietf.org/mailman/listinfo/urn
>

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
ldaigle@thinkingcat.com
-------------------------------------------------------------------


From nobody Tue Apr 28 07:59:32 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314311A6F13 for ; Tue, 28 Apr 2015 07:59:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.244
X-Spam-Level: **
X-Spam-Status: No, score=2.244 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, MANGLED_OFF=2.3, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TAsHU1AQWJv for ; Tue, 28 Apr 2015 07:59:26 -0700 (PDT)
Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0458E1A6EF4 for ; Tue, 28 Apr 2015 07:59:21 -0700 (PDT)
Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 9A9352004F324; Tue, 28 Apr 2015 07:59:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= thinkingcat.com; bh=KYKYbtWjBf4acEeQlXN1BrNt4gE=; b=ca8IplzBV/B8 x6dVYklkk2P7EhLtcQ8ovVl9FjsIrdVpcLiSBdlSEMwYumM8EA8HcZU6B2IPl3z9 /TZaJBF/+20eBAOsAR0kBxL8WLicEnLDYMa2pHwVoy0WOAuLGZ8DS5crhIVjtFCl g5AeT5vHy75d2CsX4n/qTKIiFq/tLXQ=
Received: from aran-w.int.lexiconix.com (pool-108-44-246-138.clppva.fios.verizon.net [108.44.246.138]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPSA id 279D12004F323; Tue, 28 Apr 2015 07:59:17 -0700 (PDT)
Message-ID: <553FA044.2000206@thinkingcat.com>
Date: Tue, 28 Apr 2015 10:59:16 -0400
From: "Leslie Daigle (ThinkingCat)" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Keith Moore ,  "urn@ietf.org" 
References: <55388B0E.3080806@network-heretics.com>
In-Reply-To: <55388B0E.3080806@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [urn] II -- fragments and queries Re: suggested text changes for -12 on p-components, f- and q-components in URN resolution, and relative references
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Apr 2015 14:59:31 -0000

I've been chewing on the proposed f-component and q-component text.  I 
think we need to be clear(er) about the overall concept:  how do 
fragments and queries fit with instance-independent naming of resources? 
   I think it was, indeed, progress to focus on their use as applied to 
resolution to content (via URN or URL), but I don't think the concept of 
composing parts is quite captured in the proposed text.  It reads as a 
bunch of complex rules, from which people might (or might not) derive a 
shared concept.

Example:  If I have a URN for a particular article, that could resolve 
to a URL or a URL for a book with a fragment ID for the article's 
position within the book.   Suppose the f-component on the URN is for a 
particular section of the article.  By the rules outlined below, that 
resolves correctly IFF the resolution process goes for content or gets a 
URL that is undecorated by fragments.

Leslie.

On 4/23/15 2:02 AM, Keith Moore wrote:
> Here are my suggestions for changes to draft-ietf-urnbis-rfc2141bis-11
> based on last Friday's conference call.
>
> I will try to also suggest text for r-components in a separate message,
> hopefully sometime tomorrow.  If I don't get it out by tomorrow it will
> be early next week.
>
>
> I. p-components
>
> If we have consensus that (a) relative references in resources named by
> URNs are always evaluated with respect to a base URI that is not a URN,
> and (b) there's no special need for URNs to be able to contain "paths",
> then we have several choices:
>
> (a) Disallow p-components in the 2141bis grammar, OR
> (b) Allow p-components in the 2141bis grammar, but reserve them for
> future use.   basically this means that parsers would recognize
> p-components, and p-components would be transmitted to resolution
> services, but namespaces shouldn't assign names containing p-components
> until a standards-track document explains how to do so, OR
> (c) Permit "/" in NSS arbitrarily without giving any special
> significance to them.
>
> Any of these seem workable but I lean toward either (a) or (c) - maybe a
> bit more toward (c) because I suspect there are namespaces that assign
> names containing "/" which could more easily be URN namespaces if "/"
> did not need to be %-encoded.
>
> (I don't think that (c) breaks RFC 3986 compatibility because that
> "path" component of a URN (according to the 3986 grammar) never begins
> with "/" because a namespace never begins with a "/".   The
> namespace:NSS portion of a URN always matches "path-rootless", and
> "path-rootless" can containing an arbitrary number of "/"s in a row
> because "segment" is defined to be zero or more "pchar"s.   See RFC 3986
> mostly section 3.3)
>
> Since there are three choices, I'm supplying three sets of changes,
> color-coded to hopefully minimize confusion as one scrolls back and
> forth through the message.   Pick only one :)   Note that in all cases
> the new text is shorter than the old; I take that as a favorable sign.
>
> Option (a): Disallow p-components in the 2141bis grammar
>
> Section 3
>
> OLD:
>
>        namestring    = assigned-name
>                        [ q-component ]
>                        [ f-component ]
>        assigned-name = "urn" ":" NID ":" NSS [ p-component ]
>        NID           = (alphanum) 0*30(ldh) (alphanum)
>        ldh           = alphanum / "-"
>        NSS           = 1*(pchar)
>        p-component   = "/" path-absolute
>        q-component   = "?" query
>        f-component   = "#" fragment
>
>     Note that "/" can be used without percent-encoding inside
>     p-components and that "?" can be used without percent-encoding inside
>     q-components and f-components.
>
> NEW:
>
>        namestring    = assigned-name
>                        [ q-component ]
>                        [ f-component ]
>        assigned-name = "urn" ":" NID ":" NSS
>        NID           = (alphanum) 0*30(ldh) (alphanum)
>        ldh           = alphanum / "-"
>        NSS           = 1*(pchar)
>        q-component   = "?" query
>        f-component   = "#" fragment
>
>     Note that "?" can be used without percent-encoding inside
>     q-components and f-components.
>
> Section 3.3
>
> OLD
>
> 3.3.  p-component, q-component, and f-component
>
>     The p-component, q-component, and f-component are optional components
>     that follow the assigned-name.  In terms of URI syntax these
>     components are essentially equivalent to the URI "path-absolute",
>     "query", and "fragment" constructions, respectively. However, the
>     URN p-component, q-component, and f-component need not be
>     semantically equivalent to the URI path component, query component,
>     and fragment component; therefore they are called by different names
>     in this specification.
>
>     Unless specifically defined for a particular namespace after
>     publication of this document, use of these components is disallowed,
>     thereby maintaining strict backward compatibility with namespaces
>     defined in accordance with [RFC2141] and registered in accordance
>     with [RFC3406].
>
>     This specification does not define the semantics of the p-component,
>     q-component, and f-component for URNs in general. Instead,
>     additional specifications might establish these matters for URN-
>     related services (such as URN resolution) or for individual URN
>     namespaces (e.g., to handle extended information about the resource
>     identified by a URN).  For example, it is possible that the
>     q-component might be used in requests to URN resolution services, or
>     that the f-component might be used to distinguish the integral parts
>     of resources named by URNs in particular namespaces (say, the
>     chapters of a book).  However, defining such usage is the
>     responsibility of specifications for URN resolution services,
>     namespace registration requests and specifications for individual
>     namespaces, and other appropriate documentation (such as policy
>     documents governing the management of a given URN namespace).
>
>     As general guidance that might not apply to all cases, it would be
>     inappropriate for namespaces that do not intend to support resolution
>     services to allow q-components.  Namespaces that deal with digital
>     manifestations might be able to support f-components. At the time of
>     writing, no general guidance can be provided for use of p-components.
>
> NEW
>
> 3.3.  q-component and f-component
>
>     The q-component and f-component are optional componentsthat follow
>     the assigned-name.  In terms of URI syntax thesecomponents are
>     essentially equivalent to the URI"query", and "fragment"
>     constructions, respectively.  However, thesemantics of the URN
>     q-component and f-component are subtly different than the semantics
>     of the generic URI equivalents, therefore they are called by
>     different namesin this specification.
>
>     Note: URN syntax provides no equivalent to the "path" component of
>     a generic URI.
>
>     See section [TBD.A] for a description on how the URN q-component
>     and f-component affect resolution of a URN, and section [TBD.B] for
>     how relative references are evaluated with respect to a URN.
>
>
> Section 3.3.1 (delete)
>
> Section 4.1
>
> OLD:
>
>     If a p-component is included in a URN, it MUST be identical
>     (including case sensitivity) in the strings being compared.
>
> NEW: (delete this paragraph)
>
> Section 4.2
>
> (delete examples using "/" in NSS, whether or not percent-encoded)
>
> Section 7.3.2
>
> OLD:
>
>     3.  If p-components, q-components, and/or f-components are allowed
>         for the namespace, a discussion of how they are used.
>
>
> NEW: (delete this paragraph. use or handling of f-components and
> q-components should not be namespace-specific)
>
>
> Option (b):  Allow p-components in the 2141bis grammar, but reserve them
> for future use.
>
> OLD:
>
> 3.3.  p-component, q-component, and f-component
>
>     The p-component, q-component, and f-component are optional components
>     that follow the assigned-name.  In terms of URI syntax these
>     components are essentially equivalent to the URI "path-absolute",
>     "query", and "fragment" constructions, respectively. However, the
>     URN p-component, q-component, and f-component need not be
>     semantically equivalent to the URI path component, query component,
>     and fragment component; therefore they are called by different names
>     in this specification.
>
>     Unless specifically defined for a particular namespace after
>     publication of this document, use of these components is disallowed,
>     thereby maintaining strict backward compatibility with namespaces
>     defined in accordance with [RFC2141] and registered in accordance
>     with [RFC3406].
>
>     This specification does not define the semantics of the p-component,
>     q-component, and f-component for URNs in general. Instead,
>     additional specifications might establish these matters for URN-
>     related services (such as URN resolution) or for individual URN
>     namespaces (e.g., to handle extended information about the resource
>     identified by a URN).  For example, it is possible that the
>     q-component might be used in requests to URN resolution services, or
>     that the f-component might be used to distinguish the integral parts
>     of resources named by URNs in particular namespaces (say, the
>     chapters of a book).  However, defining such usage is the
>     responsibility of specifications for URN resolution services,
>     namespace registration requests and specifications for individual
>     namespaces, and other appropriate documentation (such as policy
>     documents governing the management of a given URN namespace).
>
>     As general guidance that might not apply to all cases, it would be
>     inappropriate for namespaces that do not intend to support resolution
>     services to allow q-components.  Namespaces that deal with digital
>     manifestations might be able to support f-components. At the time of
>     writing, no general guidance can be provided for use of p-components.
>
> NEW:
>
> 3.3.  p-component, q-component, and f-component
>
>     The p-component, q-component, and f-component are optional components
>     that follow the assigned-name.  In terms of URI syntax these
>     components are essentially equivalent to the URI "path-absolute",
>     "query", and "fragment" constructions, respectively. However, the
>     URN p-component, q-component, and f-component are not
>     semantically equivalent to the URI path component, query component,
>     and fragment component; therefore they are called by different names
>     in this specification.
>
> See section [TBD.A] for a description on how the URN q-component
>     and f-component affect resolution of a URN, and section [TBD.B] for
>     how relative references are evaluated with respect to a URN.
>
>     p-components are reserved for future use.  Implementations which
>     recognize URNs MUST parse URNs according to the grammar described in
>     this document, and MUST include the entire assigned portion of a URN
>     (including any p-component) to a resolution service. However,
>     namespaces MUST NOT assign URNs containing p-components. This
>     restriction on use of p-components may be relaxed in a later
> specification.
>
> section 3.3.1:
>
> OLD
>
> 3.3.1.  p-component
>
>     The only formal restriction placed upon a p-component by this
>     specification is that the syntax SHALL adhere to the "path-absolute"
>     rule from [RFC3986].  The specification for a particular namespace or
>     URN-related service MAY define further syntax restrictions within the
>     p-component.  (For example, a namespace specification might define a
>     character such as "~" or "@" as a delimiter inside p-components
>     assigned within that namespace.)  Note that characters outside the
>     ASCII range [RFC20] MUST be percent-encoded using the method defined
>     in Section 2.1 of the generic URI specification [RFC3986].
>
>     Consider the hypothetical example of a hierarchical naming system in
>     which the identifiers take the form of a series of numbers separated
>     by the "/" character, such as "1/406/47452/2".  If the naming
>     authority for such identifiers were to use URNs, it would be natural
>     to place the existing identifiers in the p-component, resulting in
>     URNs such as "urn:example/1/406/47452/2" (using the "example" URN
>     namespace [RFC6963] instead of a registered NID).
>
>     As described under Section 4, the p-component SHALL be taken into
>     account when determining URN equivalence.
>
> NEW
>
> [[Note:  Maybe I misunderstand, but I think the -11 text is incorrect in
> syntax even if we don't change the semantics of p-components at all.
> As I read 3986, the URI "path" corresponds to the URN namespace:NSS, so
> the "path" never begins with "/" and can never correspond to
> "path-absolute".   (Yes, we can reuse that production from the 3986
> grammar if we want to do so, but I see no reason to do so.)   And the
> example given in the next paragraph is also incorrect, because there
> would need to be a ":" after the namespace "example".]]
>
> 3.3.1.  p-component
>
>     p-component is reserved for future use.  Namespaces MUST NOT assign
>     URNs with p-components.  A future specification may permit
>     p-components while possibly imposing other constraints on their use.
>
>     However, software that recognizes URNs MUST parse URNs (including
>     p-components) according to the grammar in this document, and MUST
>     present the entire "assigned-name" portion of a URN to a resolution
>     service when resolving the URN.
>
>     As described under Section 4, the p-component SHALL be taken into
>     account when determining URN equivalence.
>
> Section 7.3.2:
>
> OLD
>
>     3.  If p-components, q-components, and/or f-components are allowed
>         for the namespace, a discussion of how they are used.
>
> NEW:  (delete this.  use or interpretation of f- and q-components should
> not be namespace-specific)
>
>
> Option (c): Permit "/" in NSS arbitrarily without giving any special
> significance to them.
>
> Section 3:
>
> OLD
>
>        namestring    = assigned-name
>                        [ q-component ]
>                        [ f-component ]
>        assigned-name = "urn" ":" NID ":" NSS [ p-component ]
>        NID           = (alphanum) 0*30(ldh) (alphanum)
>        ldh           = alphanum / "-"
>        NSS           = 1*(pchar)
>        p-component   = "/" path-absolute
>        q-component   = "?" query
>        f-component   = "#" fragment
>
>     Note that "/" can be used without percent-encoding inside
>     p-components and that "?" can be used without percent-encoding inside
>     q-components and f-components.
>
> NEW
>
>        namestring    = assigned-name
>                        [ q-component ]
>                        [ f-component ]
>        assigned-name = "urn" ":" NID ":" NSS
>        NID           = (alphanum) 0*30(ldh) (alphanum)
>        ldh           = alphanum / "-"
>        NSS           = 1*(pchar / "/")
>        q-component   = "?" query
>        f-component   = "#" fragment
>
>     Note that "?" can be used without percent-encoding inside
>     q-components and f-components.
>
> Section 3.3
>
> OLD
>
> 3.3.  p-component, q-component, and f-component
>
>     The p-component, q-component, and f-component are optional components
>     that follow the assigned-name.  In terms of URI syntax these
>     components are essentially equivalent to the URI "path-absolute",
>     "query", and "fragment" constructions, respectively. However, the
>     URN p-component, q-component, and f-component need not be
>     semantically equivalent to the URI path component, query component,
>     and fragment component; therefore they are called by different names
>     in this specification.
>
>     Unless specifically defined for a particular namespace after
>     publication of this document, use of these components is disallowed,
>     thereby maintaining strict backward compatibility with namespaces
>     defined in accordance with [RFC2141] and registered in accordance
>     with [RFC3406].
>
>     This specification does not define the semantics of the p-component,
>     q-component, and f-component for URNs in general. Instead,
>     additional specifications might establish these matters for URN-
>     related services (such as URN resolution) or for individual URN
>     namespaces (e.g., to handle extended information about the resource
>     identified by a URN).  For example, it is possible that the
>     q-component might be used in requests to URN resolution services, or
>     that the f-component might be used to distinguish the integral parts
>     of resources named by URNs in particular namespaces (say, the
>     chapters of a book).  However, defining such usage is the
>     responsibility of specifications for URN resolution services,
>     namespace registration requests and specifications for individual
>     namespaces, and other appropriate documentation (such as policy
>     documents governing the management of a given URN namespace).
>
>     As general guidance that might not apply to all cases, it would be
>     inappropriate for namespaces that do not intend to support resolution
>     services to allow q-components.  Namespaces that deal with digital
>     manifestations might be able to support f-components. At the time of
>     writing, no general guidance can be provided for use of p-components.
>
> NEW
>
> 3.3.  q-component and f-component
>
>     The q-component and f-component are optional components
>     that follow the assigned-name.  In terms of URI syntax these
>     components are essentially equivalent to the URI
>     "query", and "fragment" constructions, respectively. However, the
>     URN  q-component, and f-component are not quite
>     semantically equivalent to the URI query component
>     and fragment component; therefore they are called by different names
>     in this specification.
>
> See section [TBD.A] for a description on how the URN q-component
>     and f-component affect resolution of a URN, and section [TBD.B] for
>     how relative references are evaluated with respect to a URN.
>
> Section 3.3.1 (delete this section)
>
> Section 4.1
>
> OLD
>
>     If a p-component is included in a URN, it MUST be identical
>     (including case sensitivity) in the strings being compared.
>
> NEW (delete this paragraph)
>
> Section 4.2
>
> (delete examples containing p-components and text referring to p-components)
>
> Section 7.3.2
>
> OLD
>
>     3.  If p-components, q-components, and/or f-components are allowed
>         for the namespace, a discussion of how they are used.
>
> NEW (delete this item; f- and q-components should not be namespace-specific)
>
>
> II. URN resolution
>
> Notes:
>
> 1. My first cut at this said that a client MUST NOT include a
> q-component or f-component in a URN sent in a request to a resolution
> service.  Then I realized that a resolution service might in some
> circumstances provide access to resource content (say by caching it), or
> act as a proxy to a resource, in which circumstances interpreting the
> q-component might be appropriate.   So now the client MUST NOT include
> q-component or f-component unless it's requesting that the resolution
> service provide access to the resource itself, and the resolution
> service is supposed to ignore the q-component except when it needs to
> send it as a query to the resource, and to ignore the f-component.   But
> this bothers me somewhat, and I'd like for the rules to be simpler while
> still maintaining a layer separation between the resolution service and
> the resources which it names.   The simplest solution is probably to say
> that resolution services never provide access to resource content, only
> to locations and metadata.  However, it's long been expected that
> resolution services could provide access to resource content.
>
> 2. Lars Svensson pointed out to me in private mail that a resolution
> service could potentially return a URL with query and/or fragment, so
> this text takes a position on how to interpret such a URL when the
> original URN also had an q-component and/or f-component.   I thought it
> made more sense to ignore those components from the original URN in that
> case.   There are other positions that could be taken, e.g. that
> resolution services should not be permitted to return URLs with queries
> and/or fragments, but I actually think it can be reasonable for them to
> do so.
>
>
> (new section.  note: text in brackets/italics about r-components should
> only be included if r-component proposal is adopted)
>
> TBD.A. Use of f- and q-components in URN resolution
>
> Since a URN, by design, does not contain either explicitly or implicitly
> the name or address of a network service which can be used to access the
> resource named by the URN, an application wishing to access that
> resource must somehow discover one or more "resolution services" which
> can, given the URN, either provide the resource content directly, or
> provide information to the application to enable it to access the resource.
>
> Though f- and q-components may appear in a URN, they are not assigned or
> managed by the URN namespace, but instead evaluated in the context of
> the named resource.   Specifically, an f-component of a URN refers to a
> "fragment" of the resource named by the URN, and a q-component of a URN
> is used to specify a "query" to be evaluated by the resource named by
> the URN.   This convention ensures consistent use of these components
> across all URN namespaces, and preserves the ability to reference
> "fragments" of resources named by URNs that have fragments, and to
> specify "queries" with resources named by URNs that support queries.
> In order to preserve this ability, f-components and q-components MUST
> NOT be transmitted to a URN resolution service except when that service
> is being requested to provide direct access (or access via proxy) to the
> resource itself.   For all other requests, the client MUST transmit only
> the "assigned-part" of a URN /[ along with any r-component//, if
> specified ]/ to the URN resolution service.
>
> A resolution service processing a request for a URN MUST ignore any
> f-component or q-component of that URN unless the request is to provide
> direct access (or access via proxy) to the named resource.   If the
> request is to provide access to the named resource (as opposed to, say,
> resource locations or resource metadata), the resolution service MUST
> ignore the f-component of the URN and SHOULD (if possible) process the
> q-component as if it were a query transmitted to the resource, returning
> the resource's response to that query.  If the resolution service cannot
> provide the requested access to the resource, but instead returns
> resource locations, the f-component and q-component of the request URN
> MUST be ignored in determining these locations, and MUST NOT be included
> as fragment and query (respectively) in the returned locations.
>
> These rules are intended to impose a layer separation between the URN
> resolution service and the content, and to discourage the URN resolution
> service from returning different results depending on the presence of f-
> and/or q-components in the request.
>
> If the resource named by a URN that contains an f- and/or q-component is
> accessed via an intermediate URI (other than a URN) obtained from a
> resolution service, and that intermediate URI contains neither a
> fragment nor a query, the q-component (if present) is appended to the
> intermediate URI as a query, and the f-component (if present) is
> appended to the intermediate URI as a fragment (in that order).  The
> resulting URI is then processed according to RFC 3986.
>
> Example: If the URN urn:example:foo?bar#zot appears in a link, the
> client application might transmit the assigned-part of that URN
> (urn:example:foo) to a resolution service with a request for resource
> locations.   The resolution service might then return the intermediate
> URI http://example.com/whatnot/xyzzy as one of those locations.   The
> client would then append ?bar#zot to that intermediate URI producing
> http://example.com/whatnot/xyzzy?bar#zot .   This URI would then be
> processed per normal RFC 3986 rules.
>
> A resolution service MAY return an intermediate URI which contains a
> fragment and/or a query.   If the intermediate URI contains a fragment
> or a query, any f- or q-component from the URN is ignored.   (This
> situation is basically no different than anyone composing a URI from a
> base URI plus a fragment and/or query without being aware of what
> fragments and/or queries are valid in the context of the named
> resource.   Any user or document author may combine URIs with arbitrary
> queries and/or fragments, but that doesn't mean that the results will do
> what the user or author intended.)
>
> Example: If the URN urn:example:foo?bar#zot appeared in a link, a
> resolution service might be requested to return locations of the URN
> urn:example:foo .  If such a service returned an intermediate URI
> http://example.com/whatnot/xyzzy?abcde , neither the q-component ?bar
> nor the f-component #zot would be appended to the intermediate URI
> before processing it.
>
> If the content of a resource named by a URN containing an f-component is
> obtained directly from a resolution service, the f-component SHOULD be
> treated as a "fragment" and evaluated with respect to that content, just
> as if the content had been obtained from any other service.
>
> III. Relative References
>
> (new section)
>
> TBD.B. URNs and Relative References
>
> RFC 3986 section 5.2 describes an algorithm for converting a URI
> reference that might be relative to a given base URI into "parsed
> components" of the target of that reference, which can then be
> recomposed per RFC 3986 section 5.3 into a target URI. If this algorithm
> were applied directly to URNs, it would pragmatically have the effect of
> imposing additional constraints on the naming of URNs containing
> p-components, in order that relative references contained in the
> resources named by those URNs would not break.  Alternatively, resources
> named with URNs could be forbidden to contain relative references.
> Neither of those alternatives seems attractive.   In addition, if the
> same resources are accessible by both URN and URL, it is desirable to
> permit relative references to work correctly in either case.
>
> Therefore a relative reference SHOULD NOT be evaluated with respect to a
> URN.   Instead, a relative reference SHOULD be evaluated with respect to
> either
>
> (a) a BASE URI (other than a URN) declared by the resource itself, OR
> (b) a BASE URI (other than a URN) obtained through the URN resolution
> process, OR
> (c) the URL of the resource as obtained through the URN resolution process
>
> (Case (b) permits the resolution process to explicitly supply a BASE URI
> if the resource content is supplied directly by the resolution service
> rather than via an intermediate "location" URI.)
>
> If no such BASE URI exists, use of a relative reference with respect to
> a URN is an error.
>
> Resolution services SHOULD ensure that a BASE URI is supplied any time
> they provide resource content directly to a client.
>
>
>
>
>
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
ldaigle@thinkingcat.com
-------------------------------------------------------------------


From nobody Tue Apr 28 22:41:37 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2215C1ACD0C for ; Tue, 28 Apr 2015 22:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Level: 
X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJn2w1wwuhuz for ; Tue, 28 Apr 2015 22:41:35 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A3481ACD55 for ; Tue, 28 Apr 2015 22:41:35 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8A20420926 for ; Wed, 29 Apr 2015 01:41:34 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Wed, 29 Apr 2015 01:41:34 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=fzAF0irGa/r8RXHDXkC6bx65k/c=; b=lmILh P1XJwyOs05INk2dz2j4mWPxWWTUQiC+oZ9N0oXyn0RPs9XmYr4LIWCOuJMH4TgVY 5EnMJi8uOVVlX1bWp2mWhp+JRW3S8SF57E10iX5SIo5ityGexpw0kPAELxxLjKLo RXim2EfMv7I5A/tpMHyZ+p15ZktxWnFS8XTbAo=
X-Sasl-enc: 5/nR5p6PzRkcvNOxefnaPwNtU4Vt5ZnLAHYejuHbQJYV 1430286094
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 150436800C5; Wed, 29 Apr 2015 01:41:33 -0400 (EDT)
Message-ID: <55406F0D.2000702@network-heretics.com>
Date: Wed, 29 Apr 2015 01:41:33 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <55388B0E.3080806@network-heretics.com> <553FA044.2000206@thinkingcat.com>
In-Reply-To: <553FA044.2000206@thinkingcat.com>
Content-Type: multipart/alternative; boundary="------------060200070201060709030308"
Archived-At: 
Subject: Re: [urn] II -- fragments and queries Re: suggested text changes for -12 on p-components, f- and q-components in URN resolution, and relative references
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Apr 2015 05:41:37 -0000

This is a multi-part message in MIME format.
--------------060200070201060709030308
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 04/28/2015 10:59 AM, Leslie Daigle (ThinkingCat) wrote:
>
> I've been chewing on the proposed f-component and q-component text.  I 
> think we need to be clear(er) about the overall concept: how do 
> fragments and queries fit with instance-independent naming of 
> resources?   I think it was, indeed, progress to focus on their use as 
> applied to resolution to content (via URN or URL), but I don't think 
> the concept of composing parts is quite captured in the proposed 
> text.  It reads as a bunch of complex rules, from which people might 
> (or might not) derive a shared concept.

I agree that the text I proposed could use some more work.

>
> Example:  If I have a URN for a particular article, that could resolve 
> to a URL or a URL for a book with a fragment ID for the article's 
> position within the book. 

I assume you meant "...that could resolve to a URL /for just that 
article/ or a URL for a book with a fragment ID for the article's 
position within the book"?

> Suppose the f-component on the URN is for a particular section of the 
> article.  By the rules outlined below, that resolves correctly IFF the 
> resolution process goes for content or gets a URL that is undecorated 
> by fragments.

Basically I don't think anything useful is likely to happen if both the 
URN has an f-component, and the URN resolves to a URL that has a 
fragment ID.   Nor do I see a sensible way to try to combine the 
f-component from the URN and the fragment ID from the URL.  I think 
that's a case that's very similar to adding a fragment ID to a URL that 
names a resource that doesn't have that fragment.   (In general, just 
because someone adds a fragment to a URI doesn't mean it's going to make 
any sense in relation to that resource's content.)   But it made more 
sense to me to have the behavior in that case be defined rather than 
undefined, and it made more sense to me to give priority to the fragment 
ID obtained during resolution than anything else I could think of.

(One idea I briefly considered and then soundly rejected was to pass the 
f-component to the URN resolution service and let the resolution service 
determine the mapping to URL, which might then contain a query and/or 
fragment.   Basically I think it's a very Bad Idea to have to depend on 
resolution services knowing the internal structure of resources in order 
to use those resources or references to those resources.   Resources 
should be able to be self-contained and usable, independent of URNs and 
URN resolution services; and the URN resolution service shouldn't be 
able to affect interpretation of references internal to a resource.)

Keith

p.s. Note also that there exist fragment definitions for some kinds of 
content that don't require the content to be "decorated" by fragments.   
e.g. the clipping rectangle for an image (with dimensions in pixels).  I 
don't know how widely implemented these kinds of fragments are, but 
apparently there are definitions for several such kinds of fragments.


--------------060200070201060709030308
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 04/28/2015 10:59 AM, Leslie Daigle
      (ThinkingCat) wrote:

    

    

      

      I've been chewing on the proposed f-component and q-component
      text. I think we need to be clear(er) about the overall concept:
      how do fragments and queries fit with instance-independent naming
      of resources?  I think it was, indeed, progress to focus on their
      use as applied to resolution to content (via URN or URL), but I
      don't think the concept of composing parts is quite captured in
      the proposed text. It reads as a bunch of complex rules, from
      which people might (or might not) derive a shared concept.
      

    

    

    I agree that the text I proposed could use some more work. 

    

    

      

      Example: If I have a URN for a particular article, that could
      resolve to a URL or a URL for a book with a fragment ID for the
      article's position within the book. 

    

    I assume you meant "...that could resolve to a URL for just that
      article or a URL for a book with a fragment ID for the
    article's position within the book"?

    

    
Suppose
      the f-component on the URN is for a particular section of the
      article. By the rules outlined below, that resolves correctly IFF
      the resolution process goes for content or gets a URL that is
      undecorated by fragments.
      

    

    

    Basically I don't think anything useful is likely to happen if both
    the URN has an f-component, and the URN resolves to a URL that has a
    fragment ID.  Nor do I see a sensible way to try to combine the
    f-component from the URN and the fragment ID from the URL. I think
    that's a case that's very similar to adding a fragment ID to a URL
    that names a resource that doesn't have that fragment. (In
    general, just because someone adds a fragment to a URI doesn't mean
    it's going to make any sense in relation to that resource's
    content.)  But it made more sense to me to have the behavior in
    that case be defined rather than undefined, and it made more sense
    to me to give priority to the fragment ID obtained during resolution
    than anything else I could think of.

    

    (One idea I briefly considered and then soundly rejected was to pass
    the f-component to the URN resolution service and let the resolution
    service determine the mapping to URL, which might then contain a
    query and/or fragment. Basically I think it's a very Bad Idea to
    have to depend on resolution services knowing the internal structure
    of resources in order to use those resources or references to those
    resources. Resources should be able to be self-contained and
    usable, independent of URNs and URN resolution services; and the URN
    resolution service shouldn't be able to affect interpretation of
    references internal to a resource.)

    

    Keith

    

    p.s. Note also that there exist fragment definitions for some kinds
    of content that don't require the content to be "decorated" by
    fragments. e.g. the clipping rectangle for an image (with
    dimensions in pixels). I don't know how widely implemented these
    kinds of fragments are, but apparently there are definitions for
    several such kinds of fragments.

    

  


--------------060200070201060709030308--


From nobody Wed Apr 29 18:25:32 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEF61A901C for ; Wed, 29 Apr 2015 18:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0H8Ea1BgZMID for ; Wed, 29 Apr 2015 18:25:29 -0700 (PDT)
Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1F21A900A for ; Wed, 29 Apr 2015 18:25:29 -0700 (PDT)
Received: by iedfl3 with SMTP id fl3so63429809ied.1 for ; Wed, 29 Apr 2015 18:25:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wVoWWkFdoKRznx9ldj8jA5Zj0qSHx5hgiIQ0kACrpKo=; b=mRGonTVqsqwgR2Qpd7tiFgzxlFC+4HYJ8V+c3ctq9xZ3wmcQRy0QmY3DEeox4OxJsu AvgvfYvsKr+Hj0zvzLiY8lChzhvuvQ/GCXsFPNy5Y6wiK7fpDxTIoiVfkZE6/VmzllSD euGuZmkxetYlnxzVnpGaRUe38gswsEwtfz/T5/PKzosVfo1qxu514pSZ+8iH7UczldOl 63jJNOQIE0LNHOE9EHFMItpj5bJHDrcEuCaNUk8hDMZ12wf4/03Gkc0ZN7ALK0N9mTB7 4mGkPc6CqNtblZIdYUiCsnVSMmkVHdayUCsPNoYdxJeS+0ZqgDEgo9h5D1tAk/Lw31Vx j6aw==
X-Gm-Message-State: ALoCoQnNn7w3dMjk+LV7BurszeMMD/MGSL1EL/JpOYVUnhw5l+31kJgnlu99631le3bB4S8BJyXa
X-Received: by 10.107.155.81 with SMTP id d78mr2400294ioe.29.1430357128843; Wed, 29 Apr 2015 18:25:28 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id fl10sm278867igb.1.2015.04.29.18.25.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 18:25:28 -0700 (PDT)
Message-ID: <55418486.7020001@andyet.net>
Date: Wed, 29 Apr 2015 19:25:26 -0600
From: Peter Saint-Andre - &yet 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Svensson, Lars" , "urn@ietf.org" 
References: <55388B0E.3080806@network-heretics.com> <55390E00.8000401@thinkingcat.com>  <24637769D123E644A105A0AF0E1F92EF010CF4FC6A@dnbf-ex1.AD.DDB.DE>
In-Reply-To: <24637769D123E644A105A0AF0E1F92EF010CF4FC6A@dnbf-ex1.AD.DDB.DE>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] "/" Re:  suggested text changes for -12 on p-components, f- and q-components in URN resolution, and relative references
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 01:25:31 -0000

On 4/24/15 4:04 AM, Svensson, Lars wrote:
> All,
>
>>> Tackling one issue at a time :^)  -- I went back and re-read RFC3986 per
>>> your point about "path-rootless", and came to the same conclusion.   I'm
>>> not a (URI-)parser, though, so I wouldn't object to hearing confirmation from
>>> someone who does deal in non-URN URI parsing for a living...
>>>
>>> Given that, I'd favour "c" as well -- allow "/" with no special significance
>>> imbued.
>>
>> "C" is my favourite option as well. Colleagues who are responsible of the
>> national library's URN services informed me that "/" has been used often in
>> (other organization's) internal identifiers which they wish to use as URN:NBNs.
>> So avoiding the "/" is not an option. However, if "/" has been used in an
>> identifier, it does not have any special (RFC 3986-based) significance.
>>
>> Percent encoding the character in NSS would bring no added value to the
>> URN:NBN resolution.
>
> +1

In general I think this is fine, and I agree with Keith that it's a good 
sign if we've been able to significantly simplify the text. As far as I 
can see, Keith's proposed text removes the term "p-component" entirely; 
again this is fine, but now that the NSS itself is allowed to contain 
what we've been calling a p-component, I think we should include some 
text explicitly noting this change from RFC 2141 and providing some 
guidance to those who define URN namespaces.

Here is proposed text:

    This document modifies the syntax of the NSS by allowing the "/"
    character.  The primary intent is that the assigned name can
    encapsulate existing identifiers that contain the "/" character.  In
    URNs, the "/" character does not have any special significance (in
    particular, inclusion of the "/" character in the NSS does not imply
    that the URN is "hierarchical", even though the encapsulated
    identifier might be).

    For instance, consider the hypothetical example of a hierarchical
    naming system in which the identifiers take the form of a series of
    numbers separated by the "/" character, such as "1/406/47452/2".  If
    the naming authority for such identifiers were to use URNs, it would
    be natural to place the existing identifiers in the NSS, resulting
    in URNs such as "urn:example/1/406/47452/2" (using the "example" URN
    namespace [RFC6963]).

Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Wed Apr 29 18:29:36 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD5D1A9023 for ; Wed, 29 Apr 2015 18:29:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knTTdUZkOuWm for ; Wed, 29 Apr 2015 18:29:33 -0700 (PDT)
Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525541A901F for ; Wed, 29 Apr 2015 18:29:33 -0700 (PDT)
Received: by igbhj9 with SMTP id hj9so759233igb.1 for ; Wed, 29 Apr 2015 18:29:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SaWwls309Ufxw0fDn4dfLtCuMg2psErak62mPYXvFTc=; b=hJmOpbhCdZylnDwj2lQMvHWWIcIQpopOIwQhJUddwDH8fkDkDcB5rcig666n2fPvcg 5v7KTsOxD90Rw6z6X4ng+DykMBbKVchntLf0G/oFz+XmSVUjYqLz0WegZW2KWhyulXSD 01OaQwG0DHMHDyhbLOfUyHgF7MRF/uZXTmf9ePBSGJqbdhKi98LPoVlfyRSYF1KKI+Ev Orfy2WXbX3fUgw1pOPxf3mTRMv2G3aT9T9plAE1SycEL8czsdUZd+ufky0NjSZ2lO+E6 OReOGmekXTIMLlhsd+zfE7oaUTwacvYfpCb0yAh6Ek7Bp9fTQAOgCkegF6CTWCHKaNAp ZOQw==
X-Gm-Message-State: ALoCoQlbSyjZYmVw7b9r3dM4wqtKQstVeo6LWyDXpCjWcaKwWFu/weskUzwCOeRhKc8piApGZhET
X-Received: by 10.43.60.14 with SMTP id wq14mr6742435icb.60.1430357372599; Wed, 29 Apr 2015 18:29:32 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id hx3sm78125igb.5.2015.04.29.18.29.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 18:29:32 -0700 (PDT)
Message-ID: <55418579.3060709@andyet.net>
Date: Wed, 29 Apr 2015 19:29:29 -0600
From: Peter Saint-Andre - &yet 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Leslie Daigle (ThinkingCat)" ,  urn@ietf.org
References: <55388B0E.3080806@network-heretics.com> <553A7629.8050403@thinkingcat.com>
In-Reply-To: <553A7629.8050403@thinkingcat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] III Relative references Re: suggested text changes for -12 on p-components, f- and q-components in URN resolution, and relative references
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 01:29:35 -0000

On 4/24/15 10:58 AM, Leslie Daigle (ThinkingCat) wrote:
>
> I think the proposed section on Relative References works (modulo
> removal of discussion of p-components, if that's how the consensus rolls).
>
> Proposed approach:
>
> KEITH:
>> RFC 3986 section 5.2 describes an algorithm for converting a URI
>> reference that might be relative to a given base URI into "parsed
>> components" of the target of that reference, which can then be
>> recomposed per RFC 3986 section 5.3 into a target URI. If this
>> algorithm were applied directly to URNs, it would pragmatically have
>> the effect of imposing additional constraints on the naming of URNs
>> containing p-components, in order that relative references contained
>> in the resources named by those URNs would not break.  Alternatively,
>> resources named with URNs could be forbidden to contain relative
>> references.   Neither of those alternatives seems attractive.
>
> ALTERNATIVELY:
> RFC 3986 section 5.2 describes an algorithm for converting a URI
> reference that might be relative to a given base URI into "parsed
> components" of the target of that reference, which can then be
> recomposed per RFC 3986 section 5.3 into a target URI.   This algorithm
> cannot be applied directly to URNs because their syntax does not support
> the necessary path components.  The notion of a "persistent",
> "permanent" identifier (URN) does not reconcile easily with relative
> referencing.  However, resources named with URNs may contain relative
> references that do not apply to the URN itself.

Leslie's text looks reasonable to me. However, I suppose one could 
quibble that allowing "/" in the NSS effectively mean that URNs can 
indeed "support the necessary path components" - which is why I think 
it's important to include some text describing the role of "/" in the 
NSS (see the other message I just sent).

Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Wed Apr 29 18:47:11 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03701A906F for ; Wed, 29 Apr 2015 18:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kq-F6gFjQ9PW for ; Wed, 29 Apr 2015 18:47:09 -0700 (PDT)
Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 215D81A906B for ; Wed, 29 Apr 2015 18:47:09 -0700 (PDT)
Received: by igblo3 with SMTP id lo3so1034172igb.0 for ; Wed, 29 Apr 2015 18:47:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4t84dhpkmzXFPhYfBarqcJgV2xGpqSaakmylcrH0vgA=; b=li/758moMZ1mREViweiIpOmFpSX87ZGhS5BEDLR5WzS/5pi0P+e6BR7MBhM2dMlwvC slCe+MfC03jDrdBzRgqEu2RJ8l+V+Qxf4O85c+E5b47w2FCBr4Umczubja6fNnU/oUdX cRjwxQPSoJ+30SIcQnAogA9uRxeBdPyK0jt49dL6ORRHU3M2GJ5p51FwLSbaEtU81fq+ QOFwxXB50B/FQkdIt2tmLxBX+Op3G2wgEXLJ+R9ILVmiSHBPaa2sLw8lSd4jEK8Czubq omkeQf+V7zY7pkiq8zF8WaR2ktYQE2TsO5ysuJMZUa2Eep2MC2ziAa1DIsykTguxW5l3 QQrQ==
X-Gm-Message-State: ALoCoQl/918+nx1fkzTlas9aGgbYQ74NEin+tjQLdvxEVlmJLG95glidXKqTkbLVvRWMm4pdg6IJ
X-Received: by 10.107.30.10 with SMTP id e10mr2548278ioe.72.1430358428565; Wed, 29 Apr 2015 18:47:08 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id d8sm91561igl.19.2015.04.29.18.47.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 18:47:08 -0700 (PDT)
Message-ID: <5541899A.6030106@andyet.net>
Date: Wed, 29 Apr 2015 19:47:06 -0600
From: Peter Saint-Andre - &yet 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Keith Moore 
References: <5539CC41.4050204@network-heretics.com>
In-Reply-To: <5539CC41.4050204@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "urn@ietf.org" 
Subject: Re: [urn] suggested text for r-components
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 01:47:10 -0000

On 4/23/15 10:53 PM, Keith Moore wrote:

> The basic idea is that an r-component consists of a request followed by
> one or more constraints.   The request is something like U2R (access an
> instance of the named resource), U2L (request locations of the named
> resource), or U2C (request metadata about the named resource).  (I'm not
> particularly fond of those names, and would be happy with other names,
> but there is some history behind these names.)

Overall I'm still feeling queasy about r-components. It's a large change 
to the spec and I feel that it's strongly tied to resolution. I am 
wondering whether later on (i.e., when and if someone writes a spec that 
updates or obsoletes RFC 2276) we can define r-components as a 
convention used in relation to URN resolution. Because r-components are 
allowed by q-component syntax, this seems feasible. And because they 
represent a significant and untried addition to URNs, this seems 
desirable (at least to me).

Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Wed Apr 29 18:50:28 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171E61A906B for ; Wed, 29 Apr 2015 18:50:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlOueFFRprxS for ; Wed, 29 Apr 2015 18:50:23 -0700 (PDT)
Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0A51A9053 for ; Wed, 29 Apr 2015 18:50:22 -0700 (PDT)
Received: by igblo3 with SMTP id lo3so1082695igb.0 for ; Wed, 29 Apr 2015 18:50:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=fsqc4CSJH+f3xxsuN0PH4j3G3PVBs6kiWETYQW/Y0pE=; b=WS/rfQa9fdYRpLZpmaIyXIDEYOvW2KCREK1YOg1omvXZpfxhPW6/ZrHqwIW7CflJ/c yHkciPckp/adPFQTTVCXSueYfGdvQcTzhnJElpeOkFcKEAFzVLlC3Gh/HCwI6RLUbxg0 qy6FGPPqp+nNn1fphVH94SO0mMUM7bAx7kI+ESEXg72RQWMNHmB1aN7oiaV6K/bPX78x sIpsr91Crf+HMfsP8biCw3wmjvYEBtRY7fmNhEaQnZOnS2evUZSDopmHocJQ0racpRCq L69LAhWrsvB2UZoaS75s57UEimUEv/5Hkgogo1sW0EfDuj2UIM4kFCy4YNAeT70CdslH mPVQ==
X-Gm-Message-State: ALoCoQmfAa5CVadBb2A2ADxT49qwmkS1vA9g29UxX/DDug/AKmI0iDK2MVTzy6ADsYQHirX1/knr
X-Received: by 10.107.17.29 with SMTP id z29mr2507923ioi.69.1430358622461; Wed, 29 Apr 2015 18:50:22 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id w33sm592284ioi.17.2015.04.29.18.50.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 18:50:21 -0700 (PDT)
Message-ID: <55418A5B.9000600@andyet.net>
Date: Wed, 29 Apr 2015 19:50:19 -0600
From: Peter Saint-Andre - &yet 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "urn@ietf.org" 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [urn] schedule for -12
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 01:50:25 -0000

Given the many significant discussions that have emerged on the list 
since the interim meeting (many thanks to Keith, Leslie, and everyone 
else!), I think it is best to reach some agreement on proposed text 
before John and I publish version -12 of the syntax spec. We had planned 
to do that a few days ago at the latest, but it will take us more time 
to absorb the points raised and address them in the spec.

Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Wed Apr 29 21:42:50 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4E01AC3C8 for ; Wed, 29 Apr 2015 21:42:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GABvk7Mnwak0 for ; Wed, 29 Apr 2015 21:42:47 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9B0E1AC3C1 for ; Wed, 29 Apr 2015 21:42:46 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1D49A20830 for ; Thu, 30 Apr 2015 00:42:46 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 30 Apr 2015 00:42:46 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=rYDIDH4cMjBnp2J 6EKiFKNndK/E=; b=CMjN22v7c2A5Gt3EKB//+p2fKprIbE7YsNXYJnIamTvItIf 1YfmMaDzrFHGb+MijP64iIoYKIiPBgiidf0LSo7h2A6asTr8CurgC+0XtAo1N65e IegvYV6xGqR5m4lPafr8Cx/SOXrf4Ir56TFmVegHiOkOAnJmf7UxN1wGP/aI=
X-Sasl-enc: 2fasphOIPG+a+fQ2TayUJbH6obzFCXU/6wj6L9BYWTVU 1430368965
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id A37BC680205; Thu, 30 Apr 2015 00:42:45 -0400 (EDT)
Message-ID: <5541B2C2.4060308@network-heretics.com>
Date: Thu, 30 Apr 2015 00:42:42 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Peter Saint-Andre - &yet 
References: <5539CC41.4050204@network-heretics.com> <5541899A.6030106@andyet.net>
In-Reply-To: <5541899A.6030106@andyet.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "urn@ietf.org" 
Subject: Re: [urn] suggested text for r-components
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 04:42:48 -0000

On 04/29/2015 09:47 PM, Peter Saint-Andre - &yet wrote:
>
> Overall I'm still feeling queasy about r-components. It's a large 
> change to the spec and I feel that it's strongly tied to resolution. I 
> am wondering whether later on (i.e., when and if someone writes a spec 
> that updates or obsoletes RFC 2276) we can define r-components as a 
> convention used in relation to URN resolution. Because r-components 
> are allowed by q-component syntax, this seems feasible. And because 
> they represent a significant and untried addition to URNs, this seems 
> desirable (at least to me). 

Of course r-components are strongly tied to resolution, since their 
intended purpose is to affect resolution.  :-)

The essential thing to establish now, IMO, is the separation between a 
query that's passed to a resource and a query that's passed to a 
resolution service (even if part of the logic of that service is 
implemented in the client).    If we don't do that now, code will be 
written that passes everything after the first "?" to the resource as a 
query, and that will make it much more difficult to implement resolution 
services later without breaking things.

However what might work is to define a syntax for r-components in 
2141bis and declare that they're reserved for future use by an IETF 
standard.   And I think we should go ahead and try to define a standard 
framework for resolution, but maybe that doesn't have to be a blocking 
item for 2141bis.

Keith


From nobody Wed Apr 29 21:50:53 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56A51ACC8F for ; Wed, 29 Apr 2015 21:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-lp9xlOe48g for ; Wed, 29 Apr 2015 21:50:50 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 666391AC3C8 for ; Wed, 29 Apr 2015 21:50:50 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CF69E20C82 for ; Thu, 30 Apr 2015 00:50:49 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 30 Apr 2015 00:50:49 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=It7uQJ/HUnS7td3 6YKyX3b9g10k=; b=OYLOUOGZ0RpQnr17GwCpkd+/zO/jEHqLvmrwyWc19/GWeGk r+ywI0nYh+WRzl9PB9iey4IcEC3DGRBtw8g57B/p1mtKNCLF2lSI7Lmf/rXGi+Sg HOyU5BTzLydQ9gz5chEJr7e4Dax8NFtjRUXAUEiL+Cq8hx+RotZaMznDEVF0=
X-Sasl-enc: uvJ6xj5iwvzGZXtrEbFpEjhmny8HyPNU4pGRqmcQgsXu 1430369449
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 6BE33C00017; Thu, 30 Apr 2015 00:50:49 -0400 (EDT)
Message-ID: <5541B4A5.40803@network-heretics.com>
Date: Thu, 30 Apr 2015 00:50:45 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <55388B0E.3080806@network-heretics.com> <55390E00.8000401@thinkingcat.com>  <24637769D123E644A105A0AF0E1F92EF010CF4FC6A@dnbf-ex1.AD.DDB.DE> <55418486.7020001@andyet.net>
In-Reply-To: <55418486.7020001@andyet.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [urn] "/" Re:  suggested text changes for -12 on p-components, f- and q-components in URN resolution, and relative references
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 04:50:51 -0000

On 04/29/2015 09:25 PM, Peter Saint-Andre - &yet wrote:
>>
>>>> Tackling one issue at a time :^)  -- I went back and re-read 
>>>> RFC3986 per
>>>> your point about "path-rootless", and came to the same 
>>>> conclusion.   I'm
>>>> not a (URI-)parser, though, so I wouldn't object to hearing 
>>>> confirmation from
>>>> someone who does deal in non-URN URI parsing for a living...
>>>>
>>>> Given that, I'd favour "c" as well -- allow "/" with no special 
>>>> significance
>>>> imbued.
>>>
>>> "C" is my favourite option as well. Colleagues who are responsible 
>>> of the
>>> national library's URN services informed me that "/" has been used 
>>> often in
>>> (other organization's) internal identifiers which they wish to use 
>>> as URN:NBNs.
>>> So avoiding the "/" is not an option. However, if "/" has been used 
>>> in an
>>> identifier, it does not have any special (RFC 3986-based) significance.
>>>
>>> Percent encoding the character in NSS would bring no added value to the
>>> URN:NBN resolution.
>>
>> +1
>
> In general I think this is fine, and I agree with Keith that it's a 
> good sign if we've been able to significantly simplify the text. As 
> far as I can see, Keith's proposed text removes the term "p-component" 
> entirely; again this is fine, but now that the NSS itself is allowed 
> to contain what we've been calling a p-component, I think we should 
> include some text explicitly noting this change from RFC 2141 and 
> providing some guidance to those who define URN namespaces.
>
> Here is proposed text:
>
>    This document modifies the syntax of the NSS by allowing the "/"
>    character.  The primary intent is that the assigned name can
>    encapsulate existing identifiers that contain the "/" character.  In
>    URNs, the "/" character does not have any special significance (in
>    particular, inclusion of the "/" character in the NSS does not imply
>    that the URN is "hierarchical", even though the encapsulated
>    identifier might be).
>
>    For instance, consider the hypothetical example of a hierarchical
>    naming system in which the identifiers take the form of a series of
>    numbers separated by the "/" character, such as "1/406/47452/2".  If
>    the naming authority for such identifiers were to use URNs, it would
>    be natural to place the existing identifiers in the NSS, resulting
>    in URNs such as "urn:example/1/406/47452/2" (using the "example" URN
>    namespace [RFC6963]). 

This is fine with me except that the example URN would still need a ":" 
after the namespace identifier,
e.g. urn:example:1/406/47452/2

Another thing that might be worth saying in the text is that the 
extension of 2141 syntax to permit "/" in NSS doesn't change the NSS 
syntax associated with any existing namespace.   However if an existing 
namespace wants to start assigning URNs with "/"s in them, it can update 
its registration to make it clear that they are permitted.

(one possible wrinkle:  if any existing namespace has "native" names 
that include "/" but those currently require percent-encoding, those 
namespace should still require percent-encoding for "/"s.   If "/"s in 
those namespaces appear without percent-encoding the comparison for 
equivalence will break.)

Keith


From nobody Thu Apr 30 13:01:41 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED7B1A020D for ; Thu, 30 Apr 2015 13:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.456
X-Spam-Level: 
X-Spam-Status: No, score=-1.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kIZ_q_Ck4ui for ; Thu, 30 Apr 2015 13:01:38 -0700 (PDT)
Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AB8991A0178 for ; Thu, 30 Apr 2015 13:01:38 -0700 (PDT)
Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 6796C27BC073; Thu, 30 Apr 2015 13:01:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h= message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s= thinkingcat.com; bh=n9P1FHvJTOJds6pO9ceubl2eIkQ=; b=DmGp+WnBMlgx nEuelKG7OkNXafeWqvL7JpnAYYNKLKFBrjTzp1u/3TN7z6XZjNZJUuto35fDm/KZ QuNwPlmG0s9w4mA4UvRZUo0/Fu2LYPztMIFfkQEuHXE88soXht84qJxkF8yVwS+h E7RqG0bLcDh8vu6dCkVec5ptiTWNK9A=
Received: from aran-w.int.lexiconix.com (pool-108-44-246-138.clppva.fios.verizon.net [108.44.246.138]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id 2039A27BC069; Thu, 30 Apr 2015 13:01:35 -0700 (PDT)
Message-ID: <55428A1D.9080306@thinkingcat.com>
Date: Thu, 30 Apr 2015 16:01:33 -0400
From: "Leslie Daigle (ThinkingCat)" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Keith Moore ,  Peter Saint-Andre - &yet 
References: <5539CC41.4050204@network-heretics.com> <5541899A.6030106@andyet.net> <5541B2C2.4060308@network-heretics.com>
In-Reply-To: <5541B2C2.4060308@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "urn@ietf.org" 
Subject: Re: [urn] suggested text for r-components
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 20:01:39 -0000

Below...

On 4/30/15 12:42 AM, Keith Moore wrote:
> On 04/29/2015 09:47 PM, Peter Saint-Andre - &yet wrote:
>>
>> Overall I'm still feeling queasy about r-components. It's a large
>> change to the spec and I feel that it's strongly tied to resolution. I
>> am wondering whether later on (i.e., when and if someone writes a spec
>> that updates or obsoletes RFC 2276) we can define r-components as a
>> convention used in relation to URN resolution. Because r-components
>> are allowed by q-component syntax, this seems feasible. And because
>> they represent a significant and untried addition to URNs, this seems
>> desirable (at least to me).
>
> Of course r-components are strongly tied to resolution, since their
> intended purpose is to affect resolution.  :-)
>
> The essential thing to establish now, IMO, is the separation between a
> query that's passed to a resource and a query that's passed to a
> resolution service (even if part of the logic of that service is
> implemented in the client).    If we don't do that now, code will be
> written that passes everything after the first "?" to the resource as a
> query, and that will make it much more difficult to implement resolution
> services later without breaking things.
>

I think this:

> However what might work is to define a syntax for r-components in
> 2141bis and declare that they're reserved for future use by an IETF
> standard.   And I think we should go ahead and try to define a standard
> framework for resolution, but maybe that doesn't have to be a blocking
> item for 2141bis.

is the sort of thing I was thinking of when I said leaving a "hook".

Leslie.

>
> Keith
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn


From nobody Thu Apr 30 22:23:51 2015
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB96F1B3066 for ; Thu, 30 Apr 2015 22:23:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrLcVOPX1hYT for ; Thu, 30 Apr 2015 22:23:47 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D261B3065 for ; Thu, 30 Apr 2015 22:23:46 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5C4B720CEA for ; Fri,  1 May 2015 01:23:45 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 01 May 2015 01:23:45 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Is AjxM3lvPRF9jBwNkDUgTR/f1s=; b=NRRaHXae76Qix8JuAuYPeWy6Hwo38MprwT N/jphrW8HXKBMXR0SrBb1T+H4aiaE1UHyjA/Xm/pvVg6rwtB9s5lvT3nxSsmxj7o 06diYdpUarKbEN6Bx/KyVxIUySlTaxoCpfNOdHk8zStl8jt3oG2bQ0HelhYce0QC USH3sU0nU=
X-Sasl-enc: TI2+dXfegW5UowVQ9UnuBwGdxTT4q3L02gAdwhoXmU3j 1430457825
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id E55EFC00015; Fri,  1 May 2015 01:23:44 -0400 (EDT)
Message-ID: <55430DDE.5070104@network-heretics.com>
Date: Fri, 01 May 2015 01:23:42 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "urn@ietf.org" 
Content-Type: multipart/alternative; boundary="------------020608030809060903020505"
Archived-At: 
Subject: [urn] suggested change for -12 of rfc2141bis  section 7.3.6
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 May 2015 05:23:50 -0000

This is a multi-part message in MIME format.
--------------020608030809060903020505
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

For reference, the current (-11) text of section 7.3.6:

7.3.6.  Resolution

    The "Resolution" section MUST specify whether resolution mechanisms
    are supported or anticipated for URNs assigned within the namespace,
    and if so SHOULD specify or reference the rules governing those
    mechanisms.

    In particular, if resolution is anticipated and resolver registration
    of some kind is required, for example via a Resolution Discovery
    System [RFC2276], this section SHOULD list the requirements for
    becoming a recognized resolver of URNs in the relevant namespace.

I believe this section needs work for multiple reasons:

  * resolution is, fundamentally, not a per-namespace operation. A
    namespace can support a resolution service for URNs that it assigns
    if it chooses to do so (and it will likely have high quality
    information), but any other party can also provide a service to look
    up URNs from any namespace.   Tying resolution services to any
    specific party degrades the persistence of URNs, because a URN
    should remain valid and potentially resolvable even if its namespace
    (or the organization operating it) ceases to exist, or even if its
    namespace imposes barriers to use of its resolution services.
  * Rules for resolution should not be namespace-specific, because this
    discourages general-purpose resolution services.   (A namespace can
    of course recommend specific resolution services and/or specific
    protocols for use with those services, but this section is worded as
    if resolution itself were some sort of fundamentally
    namespace-specific operation)

Here's a stab at alternate text:

7.3.6. Resolution

    The "Resolution" section is optional.  If included, it SHOULD 
specify whether the namespace intends to operate or recommend any 
resolution services for URNs using that namespace.   In addition, if the 
namespace intends to implement registration for publicly-advertised 
resolution services (for example using a system like that described in 
[RFC2276]) the Resolution section SHOULD list the requirements for being 
publicly-advertised using that mechanism.

Note: The above is not intended to restrict URN resolution to services 
provided by or recommended by the namespace operator. In principle, any 
party may operate a resolution service for any set of URNs.


--------------020608030809060903020505
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    For reference, the current (-11) text of section 7.3.6:

    

    7.3.6.  Resolution

    

       The "Resolution" section MUST specify whether resolution
      mechanisms

       are supported or anticipated for URNs assigned within
      the namespace,

       and if so SHOULD specify or reference the rules
      governing those

       mechanisms.

    

       In particular, if resolution is anticipated and resolver
      registration

       of some kind is required, for example via a Resolution
      Discovery

       System [RFC2276], this section SHOULD list the
      requirements for

       becoming a recognized resolver of URNs in the relevant
      namespace.

    

    I believe this section needs work for multiple reasons:

    
    
      
  • resolution is, fundamentally, not a per-namespace operation. 
        A namespace can support a resolution service for URNs that it
        assigns if it chooses to do so (and it will likely have high
        quality information), but any other party can also provide a
        service to look up URNs from any namespace.   Tying resolution
        services to any specific party degrades the persistence of URNs,
        because a URN should remain valid and potentially resolvable
        even if its namespace (or the organization operating it) ceases
        to exist, or even if its namespace imposes barriers to use of
        its resolution services.
    
      
    • 
      
  • Rules for resolution should not be namespace-specific, because
        this discourages general-purpose resolution services.   (A
        namespace can of course recommend specific resolution services
        and/or specific protocols for use with those services, but this
        section is worded as if resolution itself were some sort of
        fundamentally namespace-specific operation)
    
      
    • 
    

    
Here's a stab at alternate text:

    

    
7.3.6. Resolution

      

    
   The "Resolution" section is optional.  If included, it
        SHOULD specify whether the namespace intends to operate or
        recommend any resolution services for URNs using that
        namespace.   In addition, if the namespace intends to implement
        registration for publicly-advertised resolution services (for
        example using a system like that described in [RFC2276]) the
        Resolution section SHOULD list the requirements for being
        publicly-advertised using that mechanism.

      

    
Note: The above is not intended to restrict URN resolution to
        services provided by or recommended by the namespace operator. 
        In principle, any party may operate a resolution service for any
        set of URNs.

      

    

  


--------------020608030809060903020505--