Subject: [urn] About fragments and queries

From: "Hakala, Juha E" <[email-masked]>
Date: Mon, 20 Apr 2015 10:00:12 +0000

Hello Keith, 

Some comments to your clarification: 

1. Handling of URNs should be, to the extent reasonable, independent of namespace.

JH: + 1. 

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. 

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.

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. 

Juha
--

Juha Hakala

 Senior advisor
 The National Library of Finland
 Library Network Services 
 P.O.Box 26 (Teollisuuskatu 23)
 FIN-00014 Helsinki University

 Gsm: +358 50 3827678
 email: [email-masked]

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 20 Apr 2015 19:51:10 +0900

Hello Juha, others,

I'm taking this mail (which started a separate thread) to start to 
contribute again to the discussion.

> 1. Handling of URNs should be, to the extent reasonable, independent of namespace.

Agreed here, too.

> 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 res…

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.

> JH: + 1. Fragment in the URN resolution is a priori the same as it is in URL resolution.

Agreement, of course.

> 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 serv…

I'd reply somewhat differently here than Juha, but I'd guess the result 
would be the same regarding the spec.

Regards,   Martin.

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Apr 2015 09:51:50 -0400

On 04/20/2015 06:51 AM, "Martin J. Dürst" wrote:
>> 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.
>
> 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 "?".
>
> 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 
> definitely does not prescribe any specific way to do this, but leaves 
> it to schemes, and even if a scheme specifies something very clearly, 
> 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

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Apr 2015 19:30:41 -0400

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:

> "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:

> 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.)

> an open-ended business, I don't think it would be a good idea to be 

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