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

From: "Hakala, Juha E" <[email-masked]>
Date: Thu, 8 Oct 2015 12:38:08 +0000

Hello, 

Some comments below. 

> -----Original Message-----
> From: Sean Leonard [mailto:[email-masked]]
> Sent: 25. syyskuuta 2015 2:29
> To: Hakala, Juha E <[email-masked]>
> Cc: Keith Moore <[email-masked]>; [email-masked]
> Subject: Re: [urn] q-components, r-components, and resource transmission:
> Section 3.3
> 
> 
> On Sep 24, 2015, at 6:55 AM, Hakala, Juha E <[email-masked]> wrote:
> 
> > 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.

This is my problem. I understand the syntax, but I can't approve what it implies. Let us assume that URLs

http://example.com
http://example.com/
http://example.com:/
http://example.com:80/

belong to some "authority" which is the current custodian of domain example.com. 

The whole naming system is standing on clay feet if naming authorities are assigned like this. Creating a URL does not, IMO, mean that a resource in that location has received a persistent name / identifier. And most people who create URLs probably agree, and do not even try tom keep them alive.   

Domain names do change hands, and organization may decide to change its domain name or acquire many domains. If domains are volatile, what is the persistence of naming system & authority built on top of them?  

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

Representing some of the real naming authorities whose naming privileges are based on e.g. ISO standards, I find it strange that "left-usb-hub" has, according to RFC 3986, naming privileges in the same way as for instance the ISBN International Centre. I do understand that naming of web resources is different from naming books, but IMO RFC 3986 has taken things too far. Keeping names (URNs) and locations (URLs) would have been OK, but merging these functions in URIs creates confusion (how do you know if URL was intended to name something by the authority, whatever organization it is / was) and will continue to do so.  

Best regards,

Juha

> 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: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Oct 2015 20:42:45 -0600

On 9/24/15 7:05 PM, Keith Moore wrote:
> On 09/24/2015 08:56 PM, Keith Moore wrote:
>> 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.
>
> 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, you have stated before on this list that a URN is primarily or 
effectively resolved into one or more URLs. How does that model map into 
your resource #1 and resource #2?

Concrete examples would be especially appreciated. :-)

Peter

---

From: Keith Moore <[email-masked]>
Date: Mon, 26 Oct 2015 23:30:29 -0400

On 10/26/2015 10:42 PM, Peter Saint-Andre wrote:
> effectively resolved into one or more URLs. How does that model map 
> into your resource #1 and resource #2?

1.  Forget about URNs for the moment.

Say you have a CGI program running on an HTTP server.   That program is 
a resource.  Call it resource #1.

Now say you submit a query to that CGI program (aka resource #1) and it 
returns a result document.   The result document is a separate resource 
from the CGI program.   Call that result document resource #2.

Say for the sake of example that the URL of resource #1 is 
"http://example.com/cgi-bin/foo.cgi" .
Say also that the query submitted to resource #1 is "?bar=zot"
One could then say that the URL of resource #2 is 
"http://example.com/cgi-bin/foo.cgi?bar=zot" .

The point is that resource #1 and resource #2 are distinct things, and 
it makes sense to be able to refer to them separately.

2.  Now back to URNs.

Say that the URN for resource #1 were "urn:example:foo" .   One could 
then combine that URN with a query "?bar=zot" and produce a string 
"urn:example:foo?bar=zot".   Requesting the resource associated with 
that string would result in resource #2 (the result document) being 
returned.

The URN for resource #1 has the persistence properties of URNs. The 
string used to access resource #2 *does not* have those properties, but 
it will probably still be called a URN because it begins with "urn:".   
(We could try to insist on a different name for such strings, but 
getting users to adopt whatever terminology we chose would be a 
tremendous feat of social engineering.)

I don't even like calling the combination of a base URN and a 
q-component and/or r-component and/or f-component a "name".   I prefer 
to think of it as a combination of a name and one or more modifiers.

3.  Now as to your question.

A query about a URN can be submitted to a resolution service.  This 
service can return zero or more URLs.   Depending on the query, such 
URLs might be (for instance):

(a) identical locations of the resource named by the URN, such that any 
of those locations should produce the same result
(b) locations of variants of the resource named by the URN that differ 
in some way (say, the same resource in different languages),
(c) URLs of resources related to the URN about which the query to the 
resolution service was issued (say, earlier or later revisions of the 
resource).
Other kinds of query results are also possible.

Again, the result obtained should depend on the kind of query issued to 
the resolution service.   A client shouldn't get back a list of resource 
variants, or a list of related resources, unless that's what it has 
asked for.   Or at least the different kinds of results need to be 
distinguished in a way that the client doesn't get confused about what 
it's getting.

In case (a), each of the URLs returned are for resource #1.   But if a 
query is then submitted to one of those URLs, the resource it returns is 
resource #2.   Since in this case all of the URLs for resource #1 are 
supposed to produce identical results, any of the result documents 
returned are for resource #2.

In case (b), the URLs returned might still be for resource #1, because 
the concept of URN doesn't require that all instances of the named 
resource be identical.   But to me it doesn't make sense to say that 
"resource #2" encompasses all of the possibilities that might get from 
transmitting "?bar=zot" to each of those URLs. Those results might be in 
different languages.  Or sending "?bar=zot" might only make sense to 
Klingon-language versions of those resource instances, while the other 
resource instances might simply return errors or garbage.
Similarly for case (c).

But the resource#1/resource#2 example wasn't intended to apply to all 
possible ways that a URN resolution service might return URLs. It was 
only intended to make a clear distinction between the resource that 
generates a result document and the result document itself.

Keith

---

From: Sean Leonard <[email-masked]>
Date: Mon, 26 Oct 2015 20:40:08 -0700

On 10/26/2015 8:30 PM, Keith Moore wrote:
> string used to access resource #2 *does not* have those properties, 
> but it will probably still be called a URN because it begins with 
> "urn:".   (We could try to insist on a different name for such 
> strings, but getting users to adopt whatever terminology we chose 
> would be a tremendous feat of social engineering.)
>

In posts around 1 - 1.5 years ago, I referred to these as:
1. URN, or Name
vs.
2. urn: URI

For #2, compare with "http: URI", "ldap: URI", "mid: URI", etc.

Last is particularly instructive. A Message-ID value is supposed to be 
globally unique. Assuming this exists in our fantasy land, it is clear 
that the Message-ID production (or, if you will, MID production) is 
different than the mid: URI. For one thing, a mid: URI can identify a 
MIME content part by Content-ID (CID).

As for a backronym, how about "Universally Resolvable Name", anyone?? ;-)

Sean

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Oct 2015 00:01:18 -0400

On 10/26/2015 11:40 PM, Sean Leonard wrote:
>> q-component and/or r-component and/or f-component a "name".   I 
>> prefer to think of it as a combination of a name and one or more 
>> modifiers.
>

Again, I think getting users to call the two of these different things 
would be a tremendous feat of social engineering.   The distinction you 
want to make seems particularly subtle and likely to be missed by users.

Though I'm sorely tempted to suggest the following proposal:

1. Define a new URI prefix for the combination of URN + one or more 
components.   I don't care (much) what the prefix is, but for the sake 
of example I'll call it "augmented URN" with the prefix "aurn:"   (or 
maybe "burn" for "broken URN", or "yarn" for "yet another resource name" 
or ...)

2. Leave URN syntax as it is in existing RFCs.   (without declaring 
whether 2141 or 3986 is boss)

3. Define a grammar for "aurn" URIs as being

AURN = "aurn:" urn-assigned-portion [ r-component ] [ q-component ] [ 
f-component ]

along with definitions of the roles of each of those components.

Then maybe we'd preserve a clear distinction between AURNs (or whatever 
we call them), which do not have persistence properties, and URNs (which 
do).   And we might also be able to avoid fights over different ideas 
about what URNs mean, or how they're expected to be used, because we 
wouldn't be changing the meaning of URNs (from whatever people think it 
is now, even though they don't agree).   And we might get to avoid 
rehashing old battles about whether URNs should exist, or whether 
they're URIs, or how they fit into the Grand Naming Architecture of the 
Web.   And we wouldn't be sullying URNs with modifiers that make them 
non-persistent.   We could also make it clear that not all URNs would be 
expected to be meaningful in AURNs without trying to make this property 
namespace-specific.

Keith

---

From: "Hakala, Juha E" <[email-masked]>
Date: Tue, 27 Oct 2015 11:20:20 +0000

Hello,

Usually it will be enough to have just r- or q-component in the URN string. That is, normally resolution related parameters are passed either to the URN resolver or to the target system, but not to both of them at the same time. If a user wants for instance metadata about the identified resource, the request can be made either with an r-component or with a q-component. In the former case the r-component specifies the requested resolution service, and it is up to the resolver to turn that into a URI that will be accepted by the target system. In the latter case, q-component must contain a string the target will be able to deal with without conversion by the URN resolver. So for a hypothetical ISTC (International Standard Text Code) A02-2009-000004BE-A there could be URN (provided that namespace ISTC has been registered):

URN:ISTC:A02-2009-000004BE-A

We can then add an r-component indicating that the user wants Dublin Core metadata about this work 

URN:ISTC:A02-2009-000004BE-A??s=I2C&p=DC

A URN resolver might map this URN into e.g.  

http://lx2.loc.gov:210/lcdb?version=1.1&operation=searchRetrieve&query=A02-2009-000004BE-A&recordSchema=dc

which is an SRU (http://www.loc.gov/standards/sru/index.html ) search to be sent to the SRU server in the Library of Congress (the search does not work since ISTC in the example is not real). Whenever protocol version or the address of the target system changes, the URN resolver URN to SRU mapping must be updated accordingly. But r-component will remain the same, and is therefore more persistent than the q-component. 

If the target system does not support a standard search protocol, proprietary search can be "hard-coded" into a q-component. But a simple use case such as "find metadata about the identified resource" should not require use of both components in the same time, no matter how the target system behaves. 

However, a user who knows the work identifier may want to retrieve a specific manifestation of the work - for instance, a PDF version - without knowing its identifier (in the worst case, the book may not have an identifier at all). Getting from works to manifestations may require slightly more complex communication between the URN resolver and the target system, and the use of both r and q components may be necessary.  

The URN to start the process could be something like 

URN:ISTC:A02-2009-000004BE-A??s=I2CS?s=I2R&p=PDF

That is, the first step is to retrieve all metadata about the work and its manifestations. Then, if there is a PDF version, its metadata should enable the target system to locate the document and deliver it (copyright allowing) to the user. Only the first part of the process (metadata retrieval) can be encoded as an SRU search and represented as an r-component. Although the user does not want the metadata it is important to retrieve it, not least because if the PDF version does not exist, the user needs to know what his options are. But if there is a PDF version, the role of the q-component is to finish the process. It provides the target system guidelines on how to deal with the metadata from the first step of the process.  

In these examples and also generally, neither r- nor q-component have a role in identification (which is what we have agreed on ages ago). It would be very confusing to say that the ISTC identifies anything else than the work itself. And although q- and r-components could be presented in any order, IMO it is more logical to express the r-component first. Some actions by the URN resolver (based on the r-component) may be required before the target system can carry on using the guidelines provided in the q-component. 

Best regards,

Juha

> From: urn [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
> Sent: 27. lokakuuta 2015 4:43
> To: Keith Moore <[email-masked]>; [email-masked]
> > "name" for resource #2, because resource #1 is really not constrained
> > to produce consistent output even when presented with the same
> Keith, you have stated before on this list that a URN is primarily or effectively
> resolved into one or more URLs. How does that model map into your resource
> #1 and resource #2?
> 
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 Oct 2015 07:27:28 -0600

> from the CGI program.   Call that result document resource #2.

Yes, that's the distinction I thought was in your mind. :-)

I wouldn't call a CGI program a resource - I think of it as a service.

But in any case, although it's interesting to have this discussion, I 
don't yet see that it has any impact on the text of 2141bis. If I'm 
missing a connection there, please enlighten me.

Peter

---

From: Sean Leonard <[email-masked]>
Date: Tue, 27 Oct 2015 07:14:56 -0700

> I wouldn't call a CGI program a resource - I think of it as a service.

We are participating in a standardization activity...at (most) levels, 
it is not important what things are called, as long as we have rough 
consensus that we all call it the same thing. Please.

With this said, I understand that "resource" in the sense promulgated by 
URI refers to the "thing" that the absolute-URI of RFC 3986 refers to, 
i.e., *including the q-component*, but *not the f-component*.

Can we just agree that when we say resource, we really are referring 
just to that part?

And while we are in an agreeing mood, also agree that the 
urn:NID:(p-component) is the persistent and durable thing, and the thing 
worth comparing for URN equality purposes, (and can return possibly a 
lot of different kinds of resources, depending on how it gets resolved), 
while urn:NID:(p-component)?(q / r-components) is the full absolute-URI 
syntax, and we agree that it's supposed to narrow down the kinds of 
resources being requested, possibly narrowing it down to one resource. 
(That way, the #(f-component) on the client actually stands a chance at 
being meaningful, i.e., as an identifier for a sub-resource associated 
with the media type of the dereferenced content.)

Sean

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Oct 2015 10:28:11 -0400

> I wouldn't call a CGI program a resource - I think of it as a service. 

A service is a kind of resource.  It's reasonable to give a service a 
resource name.

Keith

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Oct 2015 14:26:46 -0600

On 10/27/15 8:14 AM, Sean Leonard wrote:
> worth comparing for URN equality purposes,

The spec already says that. :-)

> (and can return possibly a

Ditto.

> with the media type of the dereferenced content.)

Is there text that needs to be added to the spec here?

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Oct 2015 14:27:43 -0600

> A service is a kind of resource.  It's reasonable to give a service a

Everything is a kind of resource, I suppose.

I'm trying to figure out if text needs to change based on this thread. 
So far I don't think so, but I might have missed something.

Peter

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Oct 2015 19:11:00 -0400

>> Can we just agree that when we say resource, we really are referring

Absolutely not.  The named resource DOES NOT include the q-component.

Part of the problem is that the binding between the URN + q-component 
and whatever is named by the combination of the URN and the q-component 
is not persistent.   The binding between the URN and the resource *is* 
persistent.

So  it is vitally important to keep that distinction clear.

Keith

p.s. I still haven't had time to review the latest version of the spec, 
but will do so early next week.

---

From: John C Klensin <[email-masked]>
Date: Wed, 28 Oct 2015 23:11:00 -0400

Juha,

For the record, I agree with all of what you have written below,
but (the first part of this applies to everyone, not just
Juha)...

(1) Like Peter, I don't see it leading to text that needs to be
changed in the document.  If changes are needed, please try to
identify what and where and, if at all possible, supply draft
text.

(2) Your ISTC example is, at least to me, clearly within the
range of things I think URNs have historically been about.  It
is still identifying an object, even though that object is a
somewhat abstracted one that can be (in your terminology)
manifested in different ways and/or exist and be delivered in
different formats.   However, I can look at the relationships
you describe in terms of r-component and q-component and devise
almost equally reasonable ways of organizing that information.
That suggests to me that those relationships had best be
per-namespace and that we should be very careful about what
advice 2141bis gives about them.   If we try to move beyond that
(and much beyond the language of -13), I think we are going to
need a comprehensive model of the relationships among elements
of the namespace, resolver location, resolver instructions, and
query elements... and that would predict to our not being able
to finished this work within finite time.

(3) I have much the same reaction to trying to expand
resource-object into active code (or "services") that returns
resource-objects that are, in turn, dereferenced into locators
that point to the objects themselves. If some special case of
that sequence works well as a URN namespace, so be it.  But, if
we have to go down the path of working out the nested
relationships and what information gets passed to what level
(and is opaque to all the other levels), that is the traditional
case for recursion and/or nesting of information.  Whatever else
it is good for, the URI design accommodates recursion and
nesting very poorly and I suggest that our trying to "fix" that
as part of URN work will just lead to a great deal of
frustration and little likelihood of a consensus result that
will also satisfy URI constraints (I can think of at least one
way to do it, but the WG has already rejected the framework that
would make it possible).

best,
    john

--On Tuesday, October 27, 2015 11:20 +0000 "Hakala, Juha E"
<[email-masked]> wrote:

> Hello,
> 
> Usually it will be enough to have just r- or q-component in
> the URN string. That is, normally resolution related
> parameters are passed either to the URN resolver or to the
> target system, but not to both of them at the same time. If a
> user wants for instance metadata about the identified
> resource, the request can be made either with an r-component
> or with a q-component. In the former case the r-component
> specifies the requested resolution service, and it is up to
> the resolver to turn that into a URI that will be accepted by
> the target system. In the latter case, q-component must
> contain a string the target will be able to deal with without
> conversion by the URN resolver. So for a hypothetical ISTC
> (International Standard Text Code) A02-2009-000004BE-A there
> could be URN (provided that namespace ISTC has been
> registered):
> 
> http://lx2.loc.gov:210/lcdb?version=1.1&operation=searchRetrie
> ve&query=A02-2009-000004BE-A&recordSchema=dc
> 
> which is an SRU (http://www.loc.gov/standards/sru/index.html )
> search to be sent to the SRU server in the Library of Congress
> (the search does not work since ISTC in the example is not
> real). Whenever protocol version or the address of the target
> system changes, the URN resolver URN to SRU mapping must be
> updated accordingly. But r-component will remain the same, and
> is therefore more persistent than the q-component. 
> 
> If the target system does not support a standard search
> protocol, proprietary search can be "hard-coded" into a
> q-component. But a simple use case such as "find metadata
> about the identified resource" should not require use of both
> components in the same time, no matter how the target system
> behaves. 
> 
> However, a user who knows the work identifier may want to
> retrieve a specific manifestation of the work - for instance,
> a PDF version - without knowing its identifier (in the worst
> case, the book may not have an identifier at all). Getting
> from works to manifestations may require slightly more complex
> communication between the URN resolver and the target system,
> and the use of both r and q components may be necessary.  
> 
> That is, the first step is to retrieve all metadata about the
> work and its manifestations. Then, if there is a PDF version,
> its metadata should enable the target system to locate the
> document and deliver it (copyright allowing) to the user. Only
> the first part of the process (metadata retrieval) can be
> encoded as an SRU search and represented as an r-component.
> Although the user does not want the metadata it is important
> to retrieve it, not least because if the PDF version does not
> exist, the user needs to know what his options are. But if
> there is a PDF version, the role of the q-component is to
> finish the process. It provides the target system guidelines
> on how to deal with the metadata from the first step of the
> process.  
> 
> In these examples and also generally, neither r- nor
> q-component have a role in identification (which is what we
> have agreed on ages ago). It would be very confusing to say
> that the ISTC identifies anything else than the work itself.
> And although q- and r-components could be presented in any
> order, IMO it is more logical to express the r-component
> first. Some actions by the URN resolver (based on the
> r-component) may be required before the target system can
> carry on using the guidelines provided in the q-component.

---

From: John C Klensin <[email-masked]>
Date: Wed, 28 Oct 2015 23:28:39 -0400

--On Tuesday, October 27, 2015 00:01 -0400 Keith Moore
<[email-masked]> wrote:

>...
>>> I don't even like calling the combination of a base URN and
>>> a  q-component and/or r-component and/or f-component a
>>> "name".   I  prefer to think of it as a combination of a
>>> name and one or more  modifiers.
>> 
> Again, I think getting users to call the two of these
> different things would be a tremendous feat of social
> engineering.   The distinction you want to make seems
> particularly subtle and likely to be missed by users.

Yep.

> 1. Define a new URI prefix for the combination of URN + one or
> more components.   I don't care (much) what the prefix is, but
> for the sake of example I'll call it "augmented URN" with the
> prefix "aurn:"   (or maybe "burn" for "broken URN", or "yarn"
> for "yet another resource name" or ...)
> 
> 2. Leave URN syntax as it is in existing RFCs.   (without
> declaring whether 2141 or 3986 is boss)
> 
>...
> Then maybe we'd preserve a clear distinction between AURNs (or
> whatever we call them), which do not have persistence
> properties, and URNs (which do).   And we might also be able
> to avoid fights over different ideas about what URNs mean, or
> how they're expected to be used, because we wouldn't be
> changing the meaning of URNs (from whatever people think it is
> now, even though they don't agree).   And we might get to
> avoid rehashing old battles about whether URNs should exist,
> or whether they're URIs, or how they fit into the Grand Naming
> Architecture of the Web.   And we wouldn't be sullying URNs
> with modifiers that make them non-persistent.   We could also
> make it clear that not all URNs would be expected to be
> meaningful in AURNs without trying to make this property
> namespace-specific.

I think it is likely far too late for at least two reasons.
First, unless we actually deprecate the "URN" scheme and figure
out how to enforce a "no more of them" rule, many (perhaps most)
namespace-definers who are not persuaded that there is a
difference and those looking to apply the new features to
existing namespaces will simply continue to use the "URN" scheme
name and expect it to behave... well, however they expect it to
behave.  The result would be that we would have three things:

 (i) AURNs, which would presumably conform to some new
	specification.
 (ii) URNs which conform to 2141 and/or 3986.
 (iii) URNs which look like the current 2141bis and/or
	the AURN spec, and/or some other notion of what should
	be going on.

Assume we maintained backward-compatibility, it would basically
be impossible to distinguish between (ii) and an instance of (i)
in which optional components were not present.  Maybe that would
make no difference, but, depending on the semantics defined for
(i), maybe it would.  More important, it would be impossible to
figure out what (iii) meant and, if no components were present,
whether the URN could safely be treated as equivalent to (ii).
<insert Protocol Police comment by reference>.

Second, this WG is not chartered to start inventing new schemes
and, given how rapidly and efficiently we have made progress and
the large number of people who have been actively and
consistently engaged, the IESG would probably have to be insane
to recharter it, or charter a new WG, to do that work,
especially since doing so would recreate the controversy about
the "...any other URI with the properties of a name" remark at
the end of the first paragraph of Section 1.1.3 of RFC 3986 and
all of the arguments about whether URNs are even needed or
useless.

So, interesting idea and one that has been proposed in one form
or another several times, but I think it is too late and
probably out of order (and a distraction from getting work done)
in the present discussion.

    john