Subject: [urn] Queries in URNs (was: AW: URN fragments)

From: "Svensson, Lars" <[email-masked]>
Date: Thu, 23 May 2013 12:47:40 +0000

All,

I revive this thread about queries in URNs again since we need a resolution on this in order to proceed with standardization in other (bibliographic) areas [1].

SHORT VERSION

I propose the following:

1) We do not allow queries in URNs, since they only make sense in the context of URN resolution services.
2) We defer the question of how to handle queries in resolution services to RFC2483bis.

If someone can give me a compelling case for the use of queries in URNs *outside* of URN resolution services, I'd be most happy to discuss that and to withdraw my proposal.

LONGER VERSION

Starting point was the question, if adding a query to a URN creates a new resource or not and if the query is part of the URN or not:

[Julian]
> > > It's up to the URN or NIS syntax to describe what the query part
> > > means, and how it applies to different namespaces. But in *general*,
> > > adding a query part to a URI changes the resource being identified.

Even if it doesn't change the resource, at least it identifies another (primary) resource (as opposed to fragment, where adding a fragment makes it a different identifier while still identifying the same primary resource).

[Juha]
> > You have to be careful with the word "identify" in the URN context.
> >
> >  From the URN point of view, the resource identified does not change
> > when a query is added, if queries are used to facilitate the services
> > specified in RFC 2483. All these services are related to one and only
> > one identified resource.  A user can request for instance the resource
> > itself, metadata about it, its current URL or URLs, and so forth. In
> > practice, HTTP URIs (locations) the URN resolves to and the things
> > that are being retrieved change, but the resource identified by the
> > (location
> > independent) URN does not.

[Lars]
> As to the question if the query is part of the urn or not, my reading of rfc
> 3986 §3.4 is that it _is_ part of the urn [[ The query component is indicated by
> the first question mark ("?") character and terminated by a number sign ("#")
> character or by the end of the URI.]] If the query component ends at the end
> of the URI, it must be part of it.

Question: Can we agree that the query part is part of the URI and thus part of the URN?

Then I went on to the question if we might need to distinguish between different kinds of queries when discussing URNs. I shall not repeat my example here; if you are interested, cf. [2]

My main point was that we need to distinguish between queries operating on the URN itself and queries relating to URN resolution services. If we allow queries on URNs (e. g. urn:example:12345?a=b), what happens when I send that URN to an http-baser resolution service? Do I need to percent-encode the URN's query in order not to get into conflict with potential queries specific to that service? Example:

If I send the URN urn:example:12345?a=b to the resolution service at http://example.com/resolver and want to add the query ?c=d, would I need to write http://example.com/resolver?urn:example:12345%3Fa=b?c=d ?

Having given this topic a fair amount of thought, I suggest the following:

1) We do not allow queries in URNs, since they only make sense in the context of URN resolution services.
2) We defer the question of how to handle queries in resolution services to RFC2483bis.

If someone can give me a compelling case for the use of queries in URNs *outside* of URN resolution services, I'd be most happy to discuss that and to withdraw my proposal.

[1] cf. a related mail by Juha on the BIBFRAME list: http://listserv.loc.gov/cgi-bin/wa?A2=ind1305&L=bibframe&T=0&P=31005
[2] http://www.ietf.org/mail-archive/web/urn/current/msg01887.html 

Thanks,

Lars

***Lesen. Hören. Wissen. Deutsche Nationalbibliothek***
***Reading. Listening. Understanding. German National Library***

-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek / Informationstechnik
http://www.dnb.de/
[email-masked]

---

From: [email-masked]
Date: Thu, 23 May 2013 18:45:51 +0300

Hello Lars,

Some comments below.

Quoting "Svensson, Lars" <[email-masked]>:

> All,
>
> I revive this thread about queries in URNs again since we need a  
> resolution on this in order to proceed with standardization in other  
> (bibliographic) areas [1].
>
> SHORT VERSION
>
> I propose the following:
>

It has been the intention from the beginning that with a query we can  
pass resolution related guidelines to the appropriate URN resolver.  
There could be other mechanisms for doing this, such as DDDS record.

URNs in general are useful only if there is a resolver that provides  
the services the users want.

> 2) We defer the question of how to handle queries in resolution  

I fail to see how we could first disallow the use of query in 2141bis,  
and then bring it back in 2483bis.
>
> If someone can give me a compelling case for the use of queries in  
> URNs *outside* of URN resolution services, I'd be most happy to  
> discuss that and to withdraw my proposal.

I don't have a compelling case for using URNs without URN resolution services.
>
> LONGER VERSION
>
> Starting point was the question, if adding a query to a URN creates  
> a new resource or not and if the query is part of the URN or not:
>
> [Julian]
> Even if it doesn't change the resource, at least it identifies  
> another (primary) resource (as opposed to fragment, where adding a  
> fragment makes it a different identifier while still identifying the  
> same primary resource).
>
> [Juha]

This is simple: query is part of URN, since otherwise we would not be  
compliant with RFC 3986.

The difficult question is whether we think that query (or fragment) is  
a part of the namespace specific string. In the URN system, it is the  
combination of NID and NSS that identifies things; other parts (the  
string "urn:" in the beginning and stuff that comes after NSS, if any)  
does not count in the identification.

I do not think query or fragment should be part of the NSS. There are  
various technical reasons for this, including the fact that fragment  
does not impact what is being retrieved by HTTP; it is just used by  
the browser to take the user to a given location within the document.

More important than the technical issues are the administrative ones,  
for me at least. From the URN assignment point of view, incorporating  
query and fragment into NSS would be a problem because then there  
would be many namespaces in which it would be a priori impossible to  
use them. Standard identifiers cannot be extended with something like  
fragment. If they are not part of the NSS, such limitations disappear,  
alongside many political issues. Anyone could add a fragment or query  
to any URN after the URN has been assigned by an authoritative body.  
If fragment were part of the identifier we would need to specify in  
namespace registrations who has the right to assign e.g. fragments,  
and when/how.

>
> Then I went on to the question if we might need to distinguish  
> between different kinds of queries when discussing URNs. I shall not  
> repeat my example here; if you are interested, cf. [2]
>
> My main point was that we need to distinguish between queries  
> operating on the URN itself and queries relating to URN resolution  
> services.

IMHO, all the services that have been discussed have been related to  
the resolution services. But I have a problem grasping the concept of  
query operating on the URN itself. If this is a simple mapping from  
one URN to another, such link should be established between metadata  
records, not in URNs using a query.

If we allow queries on URNs (e. g. urn:example:12345?a=b),
> what happens when I send that URN to an http-baser resolution  
> service? Do I need to percent-encode the URN's query in order not to  
> get into conflict with potential queries specific to that service?

The parameter driven encoding of queries that Alfred Hoenes was  
working on makes such conflicts unlikely, although not impossible.

Queries should of course always be sent to a resolver that can deal  
with them. If the resolver address is incorporated into the HTTP URI  
containing the URN and the query, it is not likely that the query will  
be misdirected any time soon.

As far as I am concerned, we should not specify resolution services  
which operate on the URN itself unless there is a compelling business  
case to do so.  So far, if I have for instance a URN for a printed  
book, and I want to find the URNs for digital versions of the book,  
this would be done by fetching metadata about the work, which should  
contain URNs of all the manifestations.

Juha

> Example:
>
> If I send the URN urn:example:12345?a=b to the resolution service at  
> http://example.com/resolver and want to add the query ?c=d, would I  
> need to write  
> http://example.com/resolver?urn:example:12345%3Fa=b?c=d ?
>
> If someone can give me a compelling case for the use of queries in  
> URNs *outside* of URN resolution services, I'd be most happy to  
> discuss that and to withdraw my proposal.
>
> [1] cf. a related mail by Juha on the BIBFRAME list:  
> http://listserv.loc.gov/cgi-bin/wa?A2=ind1305&L=bibframe&T=0&P=31005
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: "Svensson, Lars" <[email-masked]>
Date: Fri, 24 May 2013 07:34:03 +0000

Juha,

Thanks for your comments. My answers are inline.

> It has been the intention from the beginning that with a query we can pass
> resolution related guidelines to the appropriate URN resolver.

Here we definitely agree. My question is if the query, which is aimed at the resolver, should be part of the URN or not. Considered that URNs are identifiers, I think there could be consensus on what urn:example:123456 identifies, but what would urn:example:123456?service=i2l identify?

> URNs in general are useful only if there is a resolver that provides the
> services the users want.

Are they not useful as identifiers, even without resolver services? There will probably never be a resolver service for urn:uuid (and possibly not for many URN namespaces). The community agrees that they are useful as identifiers, that is why those namespaces exist.
 
> I fail to see how we could first disallow the use of query in 2141bis, and then
> bring it back in 2483bis.

My idea is that since the intention is to use queries to pass information (or parameters) to a resolution service, the query should be specified _for the resolution service_ and not for the URN. An example:

Given the URN urn:example:123456 and the resolution service http://example.com/resolver I can build the resolution request http://example.com/resolver/urn:example:123456 and the resolver would perform its default service. Now if I specifically want to invoke the i2l service I would build the request http://example.com/resolver/urn:example:123456?service=i2l .

This we can split into three parts:

http://example.com/resolver/
urn:example:123456
?service=i2l

The unclear point seems to be whether ?service=i2l should be seen as part of the URN or as something sent to the resolution service at http://example.com/resolver/

My view is that ?service=i2l is something sent to the resolution service and not part of the URN. Thus I can disallow query in RFC 2141bis and still specify its use in RFC 2483bis.

> I don't have a compelling case for using URNs without URN resolution

OK.

[skipping older discussion]
> compliant with RFC 3986

OK. Here we agree. I guess we also agree that the fragment is part of the URN, too, for the same reason.
 
> The difficult question is whether we think that query (or fragment) is a part
> of the namespace specific string. In the URN system, it is the combination of
> NID and NSS that identifies things; other parts (the string "urn:" in the
> beginning and stuff that comes after NSS, if any) does not count in the
> identification.
> 
> I do not think query or fragment should be part of the NSS. There are various
> technical reasons for this, including the fact that fragment does not impact
> what is being retrieved by HTTP; it is just used by the browser to take the
> user to a given location within the document.

My gut feeling is also that neither fragment nor query should be part of the NSS. Can you expand a bit on which technical reasons you have?

> More important than the technical issues are the administrative ones, for me
> at least. From the URN assignment point of view, incorporating query and
> fragment into NSS would be a problem because then there would be many
> namespaces in which it would be a priori impossible to use them. Standard
> identifiers cannot be extended with something like fragment. If they are not
> part of the NSS, such limitations disappear, alongside many political issues.
> Anyone could add a fragment or query to any URN after the URN has been
> assigned by an authoritative body.
> namespace registrations who has the right to assign e.g. fragments, and
> when/how.

OK. So we do not accept fragments (though I'd say that the technical reason -- uniform semantics for all representations for all future -- should be a reason good enough...).

> > Then I went on to the question if we might need to distinguish between
> > different kinds of queries when discussing URNs. I shall not repeat my
> > example here; if you are interested, cf. [2]
> >
> IMHO, all the services that have been discussed have been related to the
> resolution services. But I have a problem grasping the concept of query
> operating on the URN itself. If this is a simple mapping from one URN to
> another, such link should be established between metadata records, not in
> URNs using a query.

I have problems envisioning queries operating on URNs, too. The only I could come up with was the rather silly example with the integers.

> > what happens when I send that URN to an http-baser resolution service?
> > Do I need to percent-encode the URN's query in order not to get into
> > conflict with potential queries specific to that service?
> 
> The parameter driven encoding of queries that Alfred Hoenes was working	
> on makes such conflicts unlikely, although not impossible.
> 
> Queries should of course always be sent to a resolver that can deal with
> them. If the resolver address is incorporated into the HTTP URI containing
> the URN and the query, it is not likely that the query will be misdirected any
> time soon.

Yes, but we always talk about queries sent to a resolver, and not about queries that make sense for the URNs themselves. That is why I suggest that we do not allow queries in the URN syntax, but only discuss queries in the context of the resolution services.

> As far as I am concerned, we should not specify resolution services which
> operate on the URN itself unless there is a compelling business case to do so.
> So far, if I have for instance a URN for a printed book, and I want to find the
> URNs for digital versions of the book, this would be done by fetching
> metadata about the work, which should contain URNs of all the
> manifestations.

Yes. At the risk of repeating myself infinitely: If the query does not make sense without the resolver, we do not need it in RFC 2141bis.

Looking forward to comments referring to other namespaces than urn:isbn and urn:nbn.

Lars

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 May 2013 12:50:21 -0400

> If someone can give me a compelling case for the use of queries in URNs *outside* of URN resolution services, I'd be most happy to discuss that and to withdraw my proposal.
3) when a query is appended to the URN, the query is transmitted to the 
resource named by the URN.  It has no effect on resolution.

It's a really Bad Idea to make URL query syntax mean something different 
for URNs than it does for URLs.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 May 2013 12:54:22 -0400

> There could be other mechanisms for doing this, such as DDDS record.

Whose intention?  Which beginning?

> the services the users want.

Some people would argue that they have other uses, but that was the 
originally intended purpose of URNs.    However, there was never any 
consensus that said that "the services the users want" are to be 
specified as part of the URN itself.  The URN names the resource, not 
some attribute of the resource.

IMO, people are too invested in a web browser model where the user 
doesn't specify what he wants from a resource, he just clicks on it.  He 
has no choice about how to interact with that resource, other than to 
click or to not click.     URNs were never intended to be limited to 
that style of interaction.

Keith

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 May 2013 11:27:57 -0600

On 5/29/13 10:50 AM, Keith Moore wrote:
>> resolution on this in order to proceed with standardization in
>> other (bibliographic) areas [1].
>> 
>> SHORT VERSION
>> 
>> I propose the following:
>> 
>> 1) We do not allow queries in URNs, since they only make sense in
>> the context of URN resolution services. 2) We defer the question
>> of how to handle queries in resolution services to RFC2483bis.
>> 
>> If someone can give me a compelling case for the use of queries
>> in URNs *outside* of URN resolution services, I'd be most happy
>> to discuss that and to withdraw my proposal.
> 3) when a query is appended to the URN, the query is transmitted to
> the resource named by the URN.  It has no effect on resolution.

Keith, are you agreeing with (1) and (2) and adding (3), or proposing
(3) instead of (1) and (2)?

> It's a really Bad Idea to make URL query syntax mean something
> different for URNs than it does for URLs.

Personally I think allowing queries in URNs is a bad idea, but that
passing a URN as a parameter to a URN resolution service would be fine
(where the "URN-string" might be contained in the query component of,
say, an HTTP URI whose authority component is the resolution service).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 May 2013 13:51:48 -0400

On 05/29/2013 01:27 PM, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

I'm proposing (3) instead of (1) and (2).
> say, an HTTP URI whose authority component is the resolution service).

I don't think that it makes sense to have the resolution service 
interpret the query string at all.   If you do that then you block the 
ability of the resolved resource to accept query strings. Either that or 
you have to create some registry for query parameters so that the 
resolution service can tell which parameters belong to it and which 
belong to the resource.   That way lies madness, and it's too late to 
try to restrict what kinds of query parameters a resource can use.

So the solution: stop trying to overload the query string as a way to 
communicate preferences to the resolution service.

Keith

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 May 2013 12:25:22 -0600

On 5/29/13 11:51 AM, Keith Moore wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>>>> I revive this thread about queries in URNs again since we
>>>> need a resolution on this in order to proceed with
>>>> standardization in other (bibliographic) areas [1].
>>>> 
>>>> SHORT VERSION
>>>> 
>>>> I propose the following:
>>>> 
>>>> 1) We do not allow queries in URNs, since they only make
>>>> sense in the context of URN resolution services. 2) We defer
>>>> the question of how to handle queries in resolution services
>>>> to RFC2483bis.
>>>> 
>>>> If someone can give me a compelling case for the use of
>>>> queries in URNs *outside* of URN resolution services, I'd be
>>>> most happy to discuss that and to withdraw my proposal.
>>> 3) when a query is appended to the URN, the query is
>>> transmitted to the resource named by the URN.  It has no effect
>>> on resolution.
>> Keith, are you agreeing with (1) and (2) and adding (3), or
>> proposing (3) instead of (1) and (2)?
> 
>> Personally I think allowing queries in URNs is a bad idea, but
>> that passing a URN as a parameter to a URN resolution service
>> would be fine (where the "URN-string" might be contained in the
>> query component of, say, an HTTP URI whose authority component is
>> the resolution service).
> 
> interpret the query string at all.   If you do that then you block
> the ability of the resolved resource to accept query strings.
> Either that or you have to create some registry for query
> parameters so that the resolution service can tell which parameters
> belong to it and which belong to the resource.   That way lies
> madness, and it's too late to try to restrict what kinds of query
> parameters a resource can use.
> 
> So the solution: stop trying to overload the query string as a way
> to communicate preferences to the resolution service.

I have no opinions whatsoever on how best to interact with a
resolution service. If a service provider like resolver.example.com
wants to use https://resolver.example.com?input=stringified-urn then
that's fine with me.

Now, as to your proposal (3), are you suggesting that we allow query
components on URNs? What exactly does it mean for a query to be
transmitted to the resource named by the URN? What exactly is the
resource in, say, URN:ISBN:0-395-36341-1 (RFC 3187) or
urn:service:sos.fire (RFC 5031) or
urn:cablelabs:packetcable-example:ue:rst-sample (RFC 6289)? Perhaps
it's just my lack of imagination, but I'm having a hard time
visualizing how we would pass a query component to a bound book in a
library, to the name of an XML namespace, etc.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 May 2013 14:50:08 -0400

> Now, as to your proposal (3), are you suggesting that we allow query components on URNs? What exactly does it mean for a query to be transmitted to the resource named by the URN? What exactly is the resource in, say, URN:ISBN:0-395-36341-1(RFC 3187) or urn:service:sos.fire (RFC 5031) or urn:cablelabs:packetcable-example:ue:rst-sample (RFC 6289)? 

If any of those URNs resolves to a resource for which query strings have meaning (note that this can change over time), the URN with the query string appended means whatever it means to access that resource using that query string. 

Of course, query strings aren't meaningful for all resource types and not compatible with all access protocols.  To ask what a URN with a query string appended if the resource or access protocol don't support query strings is a bit like asking what an ftp: URL with a query string means.

Though it does occur to me that perhaps the presence of a query string should affect URN resolution in one way: it should perhaps indicate a preference to have the URN resolved to an instance of the resource and access protocol that are compatible with query strings.

Sent from my iPhone

On May 29, 2013, at 2:25 PM, Peter Saint-Andre <[email-masked]> wrote:

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJRpkgSAAoJEOoGpJErxa2pZQYQAKF/OFRJ9c1D98K0tfdUzdsx
> W9yCCEBYXvvORqcYcdv8T+5n/ZZXNix29G/CUKHqP6f9BNW2KgdamWkNMCIbzqT1
> QYdf99dYcmkvWo21U5UCbvg0dAvoMGnV83m5bi5DRqOM6oF77tFnKttVajUnmH/2
> QkPdbGXhoTqZ1ebIUbj1SOGgSJkF3s0XhEXVqEagSW1NRCjOBvlStzCV/gHehzCO
> hhALwucmrASXvG4ZH8TmlWX1vyWCRul1xuUFhAdWXmXTvqigdq+NhvF507V+/CO6
> I44NbC319D+wds/5YhFD70aaMEM9BqoTs1+pdYMR3jS7RUX+T8FKesS8rt4SkJs5
> h8DjMLNtdhn9qEQOixyGENd/lKIbwB+OAxGBziWI/XpGIdCTKYfr9+jp7F2hED6/
> jPJyb67fzATK2+GG0TEhmkrMzOYF8dMAawO2AWZXd0VCfEnsHbuIRaOOF3S0D/d1
> voFls33K0Q0HIR0dMnkdV+H8hlhfivJhzALDEIU5XmgiY+O+aKT0O06olB4NCNgp
> GtBOMZFBQ5L4ht6WUTRBhUsMuFPHdbcO8d0/IX3Rdnhj/kRR3PK1+MjrBO+V0cn+
> YvEpo0uYQVugT3xicjfratZ6V2FlHDc1P8rPygDho5QW7dQiFSSXyDt+BExMQWg6
> tdJpLTLb8Y3kjbRZ3Lun
> =5W1J
> -----END PGP SIGNATURE-----

---

From: Barry Leiba <[email-masked]>
Date: Fri, 31 May 2013 15:23:36 -0400

>>> other (bibliographic) areas [1].

I've been meaning to comment on this thread, with my AD hat *off*, for

> say, an HTTP URI whose authority component is the resolution service).

My thoughts:

(1) Queries and fragments are valid URI syntax, and URNs are URIs.  It
seems reasonable to syntactically allow them in URNs, if we can agree
on what they semantically mean.

(2) I see a very strong use case for fragments, and would strongly
support having fragments in the *name* (regardless of resolution).
For example, if a book has an ISBN URN such as this:

   urn:isbn:666-0-123-45678-9

...then it reasonable and useful to be able to refer to, say, Chapter
5 in that book this way:

   urn:isbn:666-0-123-45678-9#chapter=5

...or to Part 2:

   urn:isbn:666-0-123-45678-9#part=2

...or, if it's a play, to Act III, Scene 2:

   urn:isbn:666-0-123-45678-9#act=III;scene=2

Now, whether that should be done with a fragment (my preference) or a
query is up for argument, and forgive any clumsy syntax in the
examples above -- they're to get the point across, and I haven't
checked them.

(3) Other than as a substitute for fragment in (2) above, I don't see
a use case for a query part being part of the *name* of a thing.  That
said, it's entirely possible that there are things I haven't thought
of that could seriously benefit from it, and I'd probably prefer to
avoid ruling them out.

(4) Looking at Lars's example and PSA's response to it:

>> Say I create a URN for my mailbox: urn:example:mbox:lars which
>> resolves to [email-masked] . Then
>> urn:example:mbox:lars?subject=Hi%20there&body=Hello%20world would
>> resolve to [email-masked]?subject=Hi%20there&body=Hello%20world
>> (which is OK according to rfc 6068 [1])
>
> I'm confused by this example. Why do we have a URN for your mailbox when
> mailto:[email-masked] is already a perfectly acceptable URI? And can
> we even claim that it's possible to have a persistent,
> location-independent identifier for something as transient as a
> particular person's email inbox at a particular email service provider?

I would think that such a URN wouldn't be the same as the mailto: URI,
and wouldn't be a persistent name for a specific email box.  Rather,
I'd think that such a URN would be a name for "Lars Svensson's primary
mailbox", wherever that lives, and it seems like a reasonably useful
thing to me, actually.  Assuming the uniqueness of identifiers could
be dealt with, the idea would be that

   urn:example:mbox:lars

would *name* (not locate!) Lars Svensson's mailbox, and if it's given
to an "I want to send mail there" service it would be turned into
something like "mailto:[email-masked]" today, but might be
"mailto:[email-masked]" tomorrow.  But if it's given to an
"I want to access this mailbox" service, it might instead resolve to
an imap: URL, or to an http: URL for a webmail service.

Adding to that, the fragment could then get us to a folder within the
mail store:

   urn:example:mbox:lars#inbox
or
   urn:example:mbox:lars#ietf%20stuff

...and a query could do what Lars suggested, selecting messages with a
certain subject.  Though once we get beyond naming the mailbox /
folder, we're arguably out of the realm of *names*, so it's not clear
whether having the query makes sense or not.

Am I all wet here?  Or is there some dry land on which to have discussion?

Barry