Subject: [urn] q-components, r-components, and resource transmission: Section 3.3

From: Sean Leonard <[email-masked]>
Date: Wed, 23 Sep 2015 16:23:59 -0700

URNies:

Section 3.3 says "The q-component is intended for parameters to be 
transmitted to the named resource and interpreted by that resource." At 
the same time, it is also written that when a URN resolves to a URL, the 
q-component gets copies verbatim to the query portion of the URL. But 
RFC 3986 says that query "serves to identify a resource within the scope 
of the URI's scheme and naming authority (if any)." My concern is that 
the RFC 3986 query really is a non-hierarchical directive (along with 
the hierarchical path directive) addressed to the naming authority or 
*service* (i.e., web server, in the case of 
http://www.amazon.com/get_some_book_info ) to *return* a resource; it's 
not a directive addressed to the resource itself. Clearly the semantics 
of "resource" in draft-ietf-urnbis-rfc2141bis-urn-13 and RFC 3986 are a 
bit different, but it's something to consider.

Is it more accurate to state that a "URN will be a persistent, 
location-independent identifier of a resource or a class of resources 
that share the same designation" (Section 1)? I wrote that based on a) 
the Wikipedia definition of "identifier" combined with Section 1.1 of 
RFC 3986.

Generally speaking, it seems that fragments/f-components are actually 
directed to "the resource".

Sean

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 24 Sep 2015 16:49:49 +0900

On 2015/09/24 08:23, Sean Leonard wrote:
> not a directive addressed to the resource itself.

 From an outside view, this is correct. The whole path/query stuff gets 
sent to the server, and the server sends something back. And each 
different query is treated as a different resource, e.g. by proxies.

So I think it would be better to reword 3.3 to say "The q-component is 
intended for parameters that are part of resource identification, to be 
transmitted together with the other parts of the named resource."
(or something similar)

 From a server-internal view, it is very often the case that queries are 
implemented as code, and it is very often the case that this code is 
different for each different p-component. But that doesn't need to be 
the case, there is server software that puts identifiers for individual 
items into the path, which means that the software component is the same 
for a lot of different paths with the same few identical initial 
components. And of course, there are other ways of dealing with things, 
some more practical on some architectures and frameworks than others.

> Clearly the semantics

As proposed above, I think it could easily be aligned.

Regards,   Martin.

> directed to "the resource".

RFC 3986 explicitly says that fragments identify subresources. But 
saying that they are "directed to the resource" can lead to 
misundestandings. They are not actually sent to a server, but resolved 
locally after a representation of the resource is received.

Regards,   Martin.

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Sep 2015 09:28:53 -0400

On 09/24/2015 03:49 AM, Martin J. Dürst wrote:
> intended for parameters that are part of resource identification, to 
> be transmitted together with the other parts of the named resource." 

I don't think "part of resource identification" is a good way to 
describe it because r-components can also be part of resource 
identification.  We need to make a clear distinction between parameters 
that are transmitted to the service that provides the resource, and 
parameters that influence the resolution process. Also, the q-components 
aren't "transmitted together with the other parts of the named 
resource"; they're not even necessarily transmitted together with the 
other parts of the URL (HTTP works that way but that's not true for 
other protocols in general).

I need to look more at the 3986 language.   But 3986 is simply wrong 
about so many things, that it certainly wouldn't surprise me if it were 
completely wrong about how it characterizes queries also.

Keith

---

From: "Hakala, Juha E" <[email-masked]>
Date: Thu, 24 Sep 2015 13:55:59 +0000

Hello, 

"part of resource identification" should be avoided since neither q-component nor r-component have anything to do with identification in the URN context. So saying that they are part of resource identification (which is what RFC 3986 says about query) would create confusion. 

I am happy with the current formulation of 3.3. 

As regards 3986 language: what the RFC says about query in chapter 3.4 is IMO one of the most opaque sections of the text. For instance: 

The query component contains non-hierarchical data that, along with
data in the path component (Section 3.3), serves to identify a
resource within the scope of the URI's scheme and naming authority
(if any).

I do not know where this naming authority comes from, how users are supposed to be able to see it, and why some URIs may not have any if all URIs are a priori supposed to identify something. 

Juha

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of Keith Moore
> Sent: 24. syyskuuta 2015 15:29
> To: [email-masked]
> Subject: Re: [urn] q-components, r-components, and resource transmission:
> Section 3.3
> 
> I don't think "part of resource identification" is a good way to describe it
> because r-components can also be part of resource identification.  We need
> to make a clear distinction between parameters that are transmitted to the
> service that provides the resource, and parameters that influence the
> resolution process. Also, the q-components aren't "transmitted together
> with the other parts of the named resource"; they're not even necessarily
> transmitted together with the other parts of the URL (HTTP works that way
> but that's not true for other protocols in general).
> 
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: Sean Leonard <[email-masked]>
Date: Thu, 24 Sep 2015 17:24:26 -0700

On Sep 24, 2015, at 12:49 AM, Martin J. Dürst <[email-masked]> wrote:

> From an outside view, this is correct. The whole path/query stuff gets sent to the server, and the server sends something back. And each different query is treated as a different resource, e.g. by proxies.
> 
> So I think it would be better to reword 3.3 to say "The q-component is intended for parameters that are part of resource identification, to be transmitted together with the other parts of the named resource."
> (or something similar)
> 
> From a server-internal view, it is very often the case that queries are implemented as code, and it is very often the case that this code is different for each different p-component. But that doesn't need to be the case, there is server software that puts identifiers for individual items into the path, which means that the software component is the same for a lot of different paths with the same few identical initial components. And of course, there are other ways of dealing with things, some more practical on some architectures and frameworks than others.

(Nods head)

> As proposed above, I think it could easily be aligned.

OK

> RFC 3986 explicitly says that fragments identify subresources. But saying that they are "directed to the resource" can lead to misundestandings. They are not actually sent to a server, but resolved locally after a representation of the resource is received.

Yes, I agree. I am aware of what RFC 3986 says.

To clarify my initial comment, I was contrasting q-components with f-components for Section 3.3. Section 3.3 currently says “The q-component is intended for parameters to be transmitted to the named resource and interpreted by that resource.” (Which is addressed above.) I believe we are in agreement that q-components are part of resource identification. In contrast, f-componetns identify subresources after the main (representation of the) resource is received. In that sense, f-components “address” (“speak to”) the main resource. (For example, once a webpage is downloaded, either the web browser or some JavaScript on the webpage can interpret the fragment part and scroll to some part of the webpage.) That is all.

Regards,

Sean

---

From: Sean Leonard <[email-masked]>
Date: Thu, 24 Sep 2015 17:28:56 -0700

> I do not know where this naming authority comes from, how users are supposed to be able to see it, and why some URIs may not have any if all URIs are a priori supposed to identify something. 

I believe that the term “authority” in RFC 3986 refers to:
      authority   = [ userinfo "@" ] host [ ":" port ]

I.e., some server on the network.

In a broader sense, it can be any abstract or concrete naming authority, including a reserved keyword such as “left-usb-hub”. See Section 3.2 of RFC 3986.

When there is no naming authority, the URI scheme itself serves as the authority. For example, the data URI (RFC 3987) does not depend on the network at all; the entirety of the data is crammed into the URI.

Sean

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Sep 2015 20:56:34 -0400

On 09/24/2015 08:24 PM, Sean Leonard wrote:
>   I believe we are in agreement that q-components are part of resource identification.
This is simply not the case.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Sep 2015 21:05:52 -0400

> This is simply not the case.

In the case of a URL query or a URN q-component, I think the confusion 
results because there are actually two resources:

1) The resource that produces the response.
2) If there are no errors resulting from the request to the resource, 
the response is also a resource, separate from resource #1.

The base URL or the assigned portion of the URN names resource #1.    
But it's debatable whether either the entire URL nor the entire URN is a 
"name" for resource #2, because resource #1 is really not constrained to 
produce consistent output even when presented with the same 
query/q-component.   (Such a resource might however be expected to 
generate correct HTTP response headers to defeat caching.)

At least for URNs I don't think we want to treat the entire URN + 
components as a "name" for resource #2, because even if it is properly 
termed a "name" it doesn't have the persistence properties of URNs and 
calling it a name seems likely to create confusion.

Keith

---

From: Sean Leonard <[email-masked]>
Date: Thu, 24 Sep 2015 21:47:44 -0700

On 9/24/2015 6:05 PM, Keith Moore wrote:
> But it's debatable whether either the entire URL nor the entire URN is 
> a "name" for resource #2, because resource #1 is really not 
> constrained to produce consistent output even when presented with the 
> same query/q-component.   (Such a resource might however be expected 
> to generate correct HTTP response headers to defeat caching.)
>

Keith, I find myself agreeing with you, and also being confused because 
I cannot agree with you and disagree with you at the same time. The 
issue here seems to be that "resource" is a very broad term, and RFC 
3986's definition is at variance from what urnbis is trying to express.

Your first resource #1 seems more like the (naming) authority in RFC 
3986 terms. Effectively this sounds like the web server or the Internet 
infrastructure more broadly--whatever machinery is producing a response 
that gets you to #2. Resource #1 could possibly also be the URN 
resolver, which is also part of the machinery that is producing a response.

I would surmise that the entire URN (NID + NSS) + components is not *the 
name*, because it lacks the persistence properties of URNs. The uniform 
resource "Name" part is just the NID + NSS parts, not the other components.

Regards,

Sean

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 25 Sep 2015 14:20:11 +0900

On 2015/09/24 22:28, Keith Moore wrote:
> identification.

In my understanding, the r-components just help a resolver find the 
resource, or some metadata about the resource (which of course in turn 
also can be seen as a resource), but don't actually say anything about 
the (primary) resource.

> We need to make a clear distinction between parameters

But that's how it would work for URNs, or not?

> completely wrong about how it characterizes queries also.

Could we please, as agreed earlier, refrain from such general statements 
without any supporting information? Thanks!

Regards,   Martin.

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 Sep 2015 03:35:26 -0400

On 09/25/2015 12:47 AM, Sean Leonard wrote:
>> In the case of a URL query or a URN q-component, I think the 
>> confusion results because there are actually two resources:
>>
>> But it's debatable whether either the entire URL nor the entire URN 
>> is a "name" for resource #2, because resource #1 is really not 
>> components as a "name" for resource #2, because even if it is 
>> properly termed a "name" it doesn't have the persistence properties 
>> of URNs and calling it a name seems likely to create confusion.
>
> Keith, I find myself agreeing with you, and also being confused 
> because I cannot agree with you and disagree with you at the same time. 

:)  As far as I can tell, that sort of thing happens all the time.

> The issue here seems to be that "resource" is a very broad term, and 
> RFC 3986's definition is at variance from what urnbis is trying to 
> express.
>
> 3986 terms. Effectively this sounds like the web server or the 
> Internet infrastructure more broadly--whatever machinery is producing 
> a response that gets you to #2.

at least where URNs are concerned, resource name #1 specifically names 
whatever it is that produces instances of resource #2 (presumably some 
combination of code+data, but it could be something else, like a 
physical machine), but it doesn't include the internet infrastructure - 
IP routers, DNS, etc - or the content-neutral part of the web server.   
another example of the same resource could exist, with the same name, 
but independent of the Internet (say on a storage medium), or on a 
private network that was completely disconnected from the Internet.

> Resource #1 could possibly also be the URN resolver, which is also 
> part of the machinery that is producing a response.

no.   It's very important that there be a clean separation between URN 
resolvers (of which there can be an arbitrary number) and the named 
resources themselves.   For example, we do not want resolvers to be 
central points at which resource access can be monitored or controlled.

>
> I would surmise that the entire URN (NID + NSS) + components is not 
> *the name*, because it lacks the persistence properties of URNs. The 
> uniform resource "Name" part is just the NID + NSS parts, not the 
> other components.

agree about that.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 Sep 2015 03:42:18 -0400

> also can be seen as a resource), but don't actually say anything about 

One potential way to use r-components is to narrow a selection between 
multiple representations of a resource, and of course each of those 
representations is itself a resource.

> But that's how it would work for URNs, or not?

No.  URNs don't impose that constraint on the access protocol. (though 
to some degree this depends on what is meant by "transmitted together" - 
while it might be the case that a client has to pass both the location 
URL and the q-component/query to the resource, because the resource 
can't be expected to produce the correct result without having both of 
those pieces of information, nothing says that this has to be done by 
concatenating them together the way HTTP does.)

Keith