Subject: [urn] query component in URNs

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Feb 2013 21:49:14 -0700

In the interest of moving forward with rfc2141bis and with my document
editor hat on, I've been reviewing list discussions and earlier
document versions so that we can be clear about open issues.

Because the fragment identifier issue is quite large and has received
a lot of discussion, I've decided to focus first on the issue of query
components in URNs.

Juha Hakala mentioned the topic in late 2010:

https://www.ietf.org/mail-archive/web/urn/current/msg01485.html

"From the PersID point of view, both <query> and <fragment> are
vitally important. We support the idea of reserving <query> for the
transfer of service parameters as a part of the resolution process."

In March 2011, Juha again mentioned query components:

https://www.ietf.org/mail-archive/web/urn/current/msg01507.html

"As regards the URN syntax, the key issue - at least from my point of
view - that should be discussed more widely is the usage of <fragment>
and <query> in the way suggested in RFC2141bis. The reason why it is
vital to make firm decisions concerning these features is that there
are projects that intend to use both of them, and must have explicit
permission and guidelines for doing that."

Martin Duerst pointed out that nothing is really stopping us from
allowing query components:

https://www.ietf.org/mail-archive/web/urn/current/msg01510.html

"That's quite different from the query part; if the urn spec wants to
allow a "?" and some following stuff, it can do so, and it can put on
the syntactic restrictions (as long as they are within the bounds of
the URI spec) and semantic restrictions the WG deems appropriate."

Although I don't claim to fully understand the proposed use of query
components in URNs, it appears to be something that could be supported
in, say, an HTTP-based resolution service. Thus a URN of
urn:isbn:978-951-1-25645-8 could be resolved over HTTP:

http://resolver.example.com/urn:isbn:978-951-1-25645-8?param=value

However, that would not necessitate adding query components to URNs
themselves. This appears to be consistent with something that Juha
sent in August of 2011:

https://www.ietf.org/mail-archive/web/urn/current/msg01574.html

"The reason why URN:ISBN namespace does not allow fragments has to do
with ISBN syntax. This is OK:

http://urn.fi/URN:ISBN:978-952-10-7060-0

but I am not allowed to add anything to the namespace specific string
even if the media type in which this book is published would allow
that. Of course, adding <query> would be OK since it would not be part
of the identifier. "

And:

https://www.ietf.org/mail-archive/web/urn/current/msg01582.html

"According to the RFC2141bis, fragment ID - if we allow its use in the
URN syntax - will be part of the identifier. An identifier which
consists of and ISBN and a fragment no longer identifies the book as a
whole but a component part of it. Whereas ISBN with <query> still
identifies the book as a whole; the role of the <query> is to specify
the resolution service the user wants."

The issue arose again in December of 2011:

https://www.ietf.org/mail-archive/web/urn/current/msg01665.html

"No, I was just emphasizing the point that if we piggyback service
parameters in <query> they will not be part of the URN itself.
Whenever there are fundamental changes in technology, the URN itself
remains the same, but the service parameters may be encoded differently."

Confusingly (at least to me), in March of 2012 Juha made the following
statement:

https://www.ietf.org/mail-archive/web/urn/current/msg01735.html

"As an aside, rfc3187bis is still out of date in the sense that it
assumes (erroneously) that the <fragment> is part of the NSS. If this
were so, you could not use <fragment> in the ISBN namespace since the
ISBN standard does not allow the users to add anything to the ISBN
string. But a construct where ISBN forms the NSS and <fragment> and
<query> may be added to it, gives us free hands. I shall revise the
I-D in this respect in the near future. Such revision requires also
discussions with the International ISBN Agency, since via <fragment>
usage URN:ISBN gains functionality which is not available in the ISBN
itself. "

Notwithstanding that statement, Section 2.3 of
draft-ietf-urnbis-rfc2141bis-urn-03 contained the following text:

   The <query> part MUST NOT be present in any *assigned* URN.  A
   <query> part can only be added to an assigned URN and appear in a URI
   *reference* [RFC3986] to a URN that is intended to be used with URN
   resolution services, and, in the spirit of the general specification
   of this part in RFC 3986, its purpose is restricted to indicate the
   requested URN resolution service and particular service aspects of
   the intended resolution response, e.g., the kind of metadata or
   content sought that are bound to a given object identified by the
   basic, assigned URN.

I draw two conclusions:

1. A query component would not be needed to provide a persistent,
location-independent identifer for, say, an ISBN resource like
978-951-1-25645-8.

2. Aside from a possibly ambiguous statement from Juha, no one has
proposed that we modify the URN syntax to allow query components in URNs.

Unless someone objects, I shall consider this issue closed.

Peter

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

---

From: Keith Moore <[email-masked]>
Date: Sat, 23 Feb 2013 22:58:11 -0500

On 02/20/2013 11:49 PM, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

Why should query semantics for URNs be different than for other URIs?
i.e. Why isn't a query on a URN semantically equivalent to the same 
query on the underlying resource?

Similarly, why isn't a fragment on a URN semantically equivalent to the 
same fragment of the underlying resource?
(granted, fragments are problematic for any kind of resource that can 
map to different formats with different ways of specifying fragments, 
but that's no worse for URNs than for any other kind of URI for which 
content-negotiation comes into play)

I don't think it makes sense to overload URN query and fragment 
semantics to mean different things than they mean for other URIs.

Keith

---

From: Juha Hakala <[email-masked]>
Date: Mon, 25 Feb 2013 11:18:57 +0200

Hello,

> Why should query semantics for URNs be different than for other URIs?

Query semantics for URN will be richer than for other URIs due to extra 
functionality supported by resolution services. Queries specific to the 
URN will be processed by the appropriate URN resolution service, which 
will not pass them on as such. Instead they will be mapped to the form 
supported by the appropriate target system.

For instance, if the requested service is I2C (URI to URC), the 
resolution service would map the URN into a search statement encoded as 
HTTP URI. The exact syntax of the search will depend on search / 
retrieval protocol used.

Let us assume that a user wants metadata related to a book he's 
interested in. The client he's using would assemble a URN in the format 
URN:ISBN:<ISBN-number> plus a query indicating that the user wants 
resource description in Dublin Core format. Choosing the OPAC of the 
Library of Congress OPAC as the target, the URN resolver would map the 
URN sent by the client system into a HTTP URI like this:

http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=dc.identifier 
<ISBN-number>&maximumRecords=1&recordSchema=dc

For any recent book in English there are literally hundreds of 
relatively complex HTTP URIs (targeting various library OPACs, union 
catalogues etc.) which could produce the same result. But from the 
user's point of view, the syntactically simple URN and complex HTTP URIs 
it can be mapped to are semantically equivalent.

Please note that the HTTP URI above is based on the SRU protocol 
(http://www.loc.gov/standards/sru/), which became an OASIS standard a 
couple of weeks back. Many library systems support (also) other query 
protocols which encode the queries as HTTP URIs (while some protocols, 
like Z39.50, do not). But although reasonably stable, these query URIs 
are not intended to be "cool" (whatever that means) and keeping them 
cool would be a real pain in the neck. However, in URN resolvers it 
should be possible to keep track on changing database addresses, 
protocols & protocol versions, etc. Therefore URN query may provide the 
library community a means of providing persistent links to resources, in 
spite of our ever evolving service infrastructure in which it would be 
very hard or impossible to keep the URIs "cool".

Specifying in the URN-related RFCs a subset of queries which will be 
processed by the URN resolvers should not prevent the usage of other 
kind of queries which the resolution service will just pass on to the 
appropriate target system (as a part of appropriate HTTP URI).

> Similarly, why isn't a fragment on a URN semantically equivalent to 
> the same fragment of the underlying resource?

Unless I have missed something, fragment on a URN is semantically 
equivalent to the fragment of the underlying resource. Fragment on a URN 
only specifies a location within the identified resource; it does not 
identify any part of that resource.

Best regards,

Juha

> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503)
  FIN-00014 Helsinki University
  tel +358 9 191 44293

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Feb 2013 09:40:57 -0500

On 02/25/2013 04:18 AM, Juha Hakala wrote:
> Query semantics for URN will be richer than for other URIs due to 
> extra functionality supported by resolution services. Queries specific 
> to the URN will be processed by the appropriate URN resolution 
> service, which will not pass them on as such. Instead they will be 
> mapped to the form supported by the appropriate target system.

Uh, no.   The entire space of URI queries is specific to the target system.

In general, any resource (not just those named by URNs) is potentially 
able to have different services requested from it. That the URI syntax 
doesn't support a way to ask for each service is perhaps unfortunate, 
but for better or worse, that's the way it was designed.   Making the 
URI syntax work differently for URNs than the way it works for other 
resource names is not a good idea.

Keith