Subject: Re: [urn] Names and operatiions on named objects

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 03 Dec 2013 20:06:47 -0700

I'm still working to fully understand this thread. In the meantime, I
have a few comments inline.

On 11/13/13 6:55 AM, Juha Hakala wrote:
> 
> On 8.11.2013 17:25, John C Klensin wrote:
>> --On Friday, 08 November, 2013 12:24 +0200 Juha Hakala
>> <[email-masked]> wrote:

<snip/>

>>> The URN resolver must know at least one resource which is
>>> capable of supplying the requested service. This service might
>>> be for instance a bibliographic database which supports SRU
>>> query. The resolver must know the search protocol, and it must
>>> be capable of transforming the URN + query into appropriate
>>> SRU search request.
>> This, along with the closely-related notion of just typing a URN
>> into a web browser where a URL might otherwise go, is what I
>> keep having trouble getting my head around. 

Me, too.

>> A [generic] "URL
>> resolver" works because a URL doesn't specify a location at all.
>> Instead, it specifies a method and data for that method.  As
>> such, a "URL resolver" isn't a resolver, it is what some
>> computer science disciplines would call a "method dispatcher".
> URNs are no different in that respect. Currently most URN resolvers are
> very simple, and HTTP URI with embedded URN is mapped into the URL which
> shows the current location of the resource in the Internet. 

That model makes sense to me.

> What we are looking forward to is a resolver which can support a wider
> set of resolution services, so that if a user wants metadata about the
> resource instead of the resource itself, then the URN resolver must a
> search request according to the SRU protocol, or, in John's terminology,
> method (SRU) and data (search request encoded as URL).

Juha, are people assuming that these future resolvers won't embed URNs
in HTTP URIs, but instead will represent all of the information (in
John's terms, the name and various attributes or parameters) into the
URN alone?

If so, why? What features of the next generation of resolvers lead
people to think that the current model (embed URN into HTTP URI) can't
do the job?

Peter

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

---

From: Juha Hakala <[email-masked]>
Date: Wed, 04 Dec 2013 13:29:44 +0200

Hello,

> have a few comments inline.

I'll try to answer the questions below. Sometimes one face to face 
meeting could be worth many emails; I don't think that there is that 
much disagreement between us, but it seems that I have not been able to 
explain clearly enough the expectations the libraries have. Not being a 
native English speaker doesn't help :-(.
>>> keep having trouble getting my head around.
The basic assumption here is that a) there is a limited number of 
resolvers which can deal with any namespace or part of that namespace 
and b) for any URN, there is just one resolver which will deal with it. 
There are namespaces which will only ever have a single resolver 
(example: ISSN namespace or any other namespace with "dumb" identifier) 
which can of course be mirrored. Some other namespaces must be split 
into component parts which will each have its own resolver. For 
instance, URN:NBN has Finnish part which is taken care of by 1-n 
resolvers dealing with URN:NBN:fi and its sub-divisions. In these 
hierarchical namespaces, the top level resolver can harvest all the 
mapping information from sub-ordinate resolvers. The library community 
has also made experiments with harvesting across national NBN namespaces.

When a resolver gets the plain vanilla URN (in e.g. form 
http://urn.fi/<URN>) it currently provides whatever service it can. 
Currently it is usually mapping from URN to single URL. A default 
service has never been specified, which IMO may become a problem in the 
future when there are more resolution services available, and different 
namespaces may have different preferences. Then a user who relies on 
multiple namespaces will get confused.

If the user does not want the default service and there is a choice 
between two or more services, there must be a way to indicate what he 
wants. Assuming that URI query is used, then the resolver has to know 
how to deal with it. URN - URL mapping is something that can be done 
internally within the resolver with the mapping table. These tables are 
currently very simple things which specify URNs and corresponding 
up-to-date URLs. In the future we'll have a lot more information aiding 
the resolution. For instance, if we have an URN belonging to the 
URN:NBN:FI -namespace, and the user wants bibliographic data about the 
identified resource. The resolver must know that for any URN belonging 
to that sub-namespace, if the resolution service requested is URC 
(bibliographic information about the resource) the URN + query has to be 
mapped into a query expressed in SRU protocol which is sent into the 
appropriate port in the Finnish national bibliography.

Each URN namespace (or sub-namespace) must specify how to supply the 
services supported within that namespace. This is not as complicated as 
it sounds, since we are dealing with limited number of sophisticated 
identifier systems and limited number of services. These services will 
vary over time, and the protocols used to supply them will change. The 
critical thing is that the URI query syntax remains the same once it has 
been fixed. Then, 100 years from now, if a user wants a citation of the 
resource (instead of the thing itself) she can still use the same URN 
and query, even though the underlying protocols and applications have 
changed many times over.
> That model makes sense to me.
This is what we currently have. But with URNs we can and we must go 
further.
> John's terms, the name and various attributes or parameters) into the
For the time being we definitely need HTTP URIs. And of course we can 
carry on using them, if the resolver discovery service does not emerge. 
However, if and when RDS is established, it has to be possible to "port" 
whatever we are doing into this new environment.
> people to think that the current model (embed URN into HTTP URI) can't
With the current system we must have resolvers in fixed locations such 
as http://urn.fi. Given the limited number of resolvers, this is not an 
impossible burden. The resolver URLs are very stable ("cool" URIs par 
excellence) and if they change, making DNS redirects for handful of 
addresses is not hard. But in the very long run, it would be better if 
we could use just plain URNs and leave the resolver tracking to RDS. 
Then there would be nothing protocol dependent in the name, and 
resolvers could be moved around as long as the RDS is able to keep track 
of them.

Juha

-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. +358 9 191 44293
  Mobile +358 50 3827678

---

From: Keith Moore <[email-masked]>
Date: Wed, 04 Dec 2013 11:47:05 -0500

> people to think that the current model (embed URN into HTTP URI) can't
Peter,

The original purpose of URNs was to serve as a location-independent
identifier for a resource that was potentially network-accessible.  
Yes, URNs can be used to name resources that aren't network-accessible
and never will be.   But URNs were created because we observed, very
early in the history of the web, that resource identifiers with embedded
"locations" (i.e. domain names) were almost inherently not indefinitely
"persistent".

So the idea of embedding URNs in HTTP URIs was never the intended way to
use URNs.  It was a hack to work around the fact that URNs weren't (yet)
supported by web browsers.   Embedding a URN in a HTTP URI results in a
URI that was assumed to be unlikely to be persistent.

However, I don't recall that the idea was ever that a URN should be able
to include "the various attributes and parameters" that would cause the
resulting identifier to be interpreted as an identifier for, say,  (some
of) the resource's metadata rather than the resource itself.

The above is a summary of my memory of the thinking (circa mid 1990s)
that went into the design of URNs and related services.    A number of
assumptions have changed a bit since then, but there still seems to be a
need (and demand) for identifiers which provide assurance of
"persistence" and are clearly distinguished from other identifiers for
which persistence is not assured.   (And there's still some reason to
doubt that URI with an embedded URN will be persistent indefinitely.)

---

In principle, a URI names a resource, and doesn't specify what you can
do with that named resource.  In principle, HTTP [+WebDAV] (for example)
supports a large number of "methods" which can operate on a resource,
and some other access protocols also support multiple methods.  But in
practice, the most common operation on a URI is "GET" - i.e. download
the contents of the resource.   Usually this is followed by some sort of
interpretation and/or presentation of the resource that is obvious from
the context in which the URI is being used.

GET is attractive, in part, because it requires no parameters other than
the URL itself.   Yes, there might be some content-negotiation that
affects the data that is obtained from a GET, but to the extent that it
happens, the additional information needed is obtained "by context".  
It's not part of the GET itself.   Think about the various contexts in
which URLs are used.  If the expected method is GET, the URL can be just
a parameter to something like an A or IMG tag.   But if the expected
method is almost anything else, the specification of how to interact
with that resource becomes a lot more complicated.   Instead of just
specifying a URL in a parameter, you typically have to write _code_ that
manages the interaction.   (For this reason, there's some pressure even
in the URL-only world to shoehorn additional information into GET.  It's
why you so often see URLs consisting of some base URL with a lot of
additional stuff tacked on the end, either as "form data" or as
additional components of the "path".)

Because GET is so popular and obviously useful, a lot of us think that
it should be possible to GET a resource named by a URN - at least, if
that resource is something for which GET makes sense:  it's
network-accessible, and it has content that can be downloaded without
additional explicit information being supplied.   For example, an HTML
document should someday be able to have  URNs in any of the contexts in
which GET is the implicit operation, with the reasonable expectation
that browsers will do the right thing, and all of the code necessary to
do the right thing will be embedded in the browser.    This may seem
like a dream, but it can work.   All it needs is for every namespace
(for which GET on its URNs potentially makes sense) to support a
standard resolution protocol and some number of resolution servers, and
for those resolution servers to be associated with that namespace in
DNS.  If the resolution protocol and servers support other functionality
beyond facilitating GET, so much the better.

(Or to state it from a different point-of-view:  I get the impression
that there is interest in resolution services for several different URN
namespaces.   In addition to whatever other functionality those
resolution services provide, I would like it if there were enough of a
common standard among these resolution services to facilitate
browser/client implementation of GET, for those URNs for which GET makes
sense. )

Of course GET isn't the only method that we'd like to be able to use
with resources named by URNs, but GET is the method that is the most
broadly applicable across the range of network-accessible resources and
access protocols.   If what you want to do instead with a particular URN
is, say, POST, you need to be able to find a resource location and
access protocol for that URN, for which POST is defined.

But with URNs, just as with URLs, chances are good that if you need to
facilitate interaction with a resource using some other method than GET,
you're going to be writing code to do that.   You're going to be writing
code because the interaction is no longer simple and one-step and/or
entirely determined by the URI and context: it may involve multiple
interactions with the resolution server, and your code may have to make
decisions after each interaction based on the data obtained.

So my conclusions are:

- We (IETF URN WG) should resume work toward a URN architecture and
infrastructure that facilitate GET on URNs, for those URNs for which it
makes sense.   This includes a standard resolution protocol with the
ability to support queries for resource locations (whatever else it
supports), and a means of registering resolution servers such that
browsers and other clients can find resolution servers for particular
namespaces.   If DNS works to do this, that's great, if it doesn't work,
pick something else.

- I haven't seen a need to be able to specify resolution parameters as
part of URNs, because I think that the vast majority of things that
aren't GET will require writing code anyway.   So (for example) if what
you want to do is obtain the output of querying a resolution service for
something or another, instead of having a link to something that
consists of URN + resolution parameters, you're probably going to need
to write some JavaScript or other code to actually interact with the
resolution service.

- Based on the above, I haven't seen a need to overload existing URI
query syntax to allow resolution parameters to be supplied with URNs.  
So when the query syntax is used with URNs, it can unambiguously mean a
query that is supplied to the resource named by the URN, rather than
parameters passed to the resolution server.   [*]

Keith

[*]  However, what any resolution server does with query parameters
passed to it, is its own business, unless/until that interface is
standardized.   So for example if there's a resolution service for URN
namespace "abc" that is located at URL abc.org, and it accepts queries
of the form

GET http://abc.org/resolver/urn%3Aabc%3Axyz?request=metadata

There's nothing wrong with that, because the "request=metadata" query is
part of the URL passed to the resolution service, and not part of the URN.

If a browser or other client were presented with a URN+query like
"urn:abc:xyz?foo=bar" it would first have to query the resolution
server, perhaps using a URL like:

GET http://abc.org/resolver/urn%3Aabc%3Axyz?request=locations

(note that foo=bar is omitted)

And then, having found one or more suitable locations, the client could
send the query over HTTP to a URL obtained from the resolution server:

GET http://example.com/location-of-resource?foo=bar