Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt

From: Juha Hakala <[email-masked]>
Date: Tue, 10 Jan 2012 08:22:37 +0200

Hello Martin,

I agree with you in many respects, but there are some differences of 
opinion as well. See below...

Martin J. Dürst wrote:
> Hello Juha,

> This means that there is a strong question as to how, and to what 
> degree, the classical library-based name-location distinction is still 
> relevant and useful. With that I don't want to say that it's useless, I 
> just want to say that however many years of "practical experience" you 
> can claim, that experience may or may not transfer to a world with 
> essentially different "physical" rules.

 From a library point of view, for instance the following features of 
networked resources seem to be in favour of separating identification 
from location:

1. There may be multiple copies of a single resource in different 
locations. However a resource should have one and only one identifier.

2. Over time, there may be different resources available from a single 
location.

3. A single resource may be moved from one location to the next.

4. A digital resource may disappear (leaving only e.g. a printed 
surrogate).

5. A single file can incorporate multiple resources that should be 
identified separately; a single resource can span over multiple files.

There has also been discussions about persistence (or the lack of it) of 
domain names, and the need of identifying abstract entities such as 
works (which may or may not have manifestations in the Web).

> Also, at least as far as content is digital text, search engines add 
> another dimension to this picture. If things move, search engines just 
> catch up. Especially for specialized content, we are definitely not yet 
> there yet, but for more general content, the fact that something gets a 
> different URI isn't the end of the world these days.

Search engines do catch up if the resource is not in a non-accessible 
silo. There seems to be an alarming trend that instead of making 
resources available in the (semantic) Web, some importand players are 
preferring to hide their data from the open Web.

For resources in silos, it remains to be seen if persistent identifiers 
will be able to provide access.

Moreover, any library has a significant amount of non-textual resources 
which for the time being are not well catered for by search engines. 
There are interesting (pilot) services for searching music or still 
images, but this is not yet mature technology.

> So up to the middle ages, we mostly had the situation that one would 
> hear by chance that a certain library had a certain work, and would 
> travel to that library and read the work inside that library (though 
> indeed not on the shelf) if one had that much leisure time.

It is a little bit ironic that for the Web content, most national 
libraries  that harvest the Web must rely on similar practice. According 
to the existing legal deposit & copyright acts the harvested documents 
cannot be made freely available; the users must come to the national 
library or other legal deposit libraries in the country, and use the 
material on dedicated workstations, which are a modern equivalent of the 
chain that attached the mediaeval books to the shelf so as to protect 
them against thieves.
> 
> In the "library age", one would go to the nearest public library, ask 
> e.g. "I want to read Tom Sawyer", got back a question whether one meant 
> Tom Sawyer by Mark Twain, and then got a "name" (or number) to write on 
> the order slip, or got directed to the relevant bookshelf (location). 
> And one would take the book home, and the library would record the 
> location of the copy in question as "with lender Foo".

As an aside, while there is a well functioning business model for 
scientific periodicals (which, once purchased can be freely used) there 
is as of yet not a fixed model for e-books. There could be a limited 
number of electronic items (allowing for instance two users to read an 
electronic item at the same time), or each lending operation may have a 
fixed cost, so that one really popular book might take the entire 
acquisitions budget in a short time.
> 
> In the digital age, we can type something into a search box, get the 
> content in no time, and never have to "give it back". At the same time, 
> several copies will have been created. Lots of 
> names/locations/identifiers (from metadata down to track numbers on a 
> hard disk) may be involved, but the overall thing may not easily fit an 
> old-style library name/location dichotomy anymore.

The process you describe above applies freely available materials and 
e.g. commercial scientific periodicals. But for other kind of resources 
such as e-books things may become more complex, legally and otherwise. 
As regards the content, an e-book in EPUB 3 format becomes a ZIP 
container that can and will hold many things (each one of which must be 
identified separately) in addition to the text of the book, and even the 
text should adapt itself to different viewers. For the libraries' 
traditional cataloguing principles these resources will pose interesting 
challenges.
> Regards,    Martin.

-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email [email-masked], tel +358 50 382 7678

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Jan 2012 10:30:12 +0100

On 2012-01-10 07:22, Juha Hakala wrote:
>> relevant and useful. With that I don't want to say that it's useless,
>> I just want to say that however many years of "practical experience"
>> you can claim, that experience may or may not transfer to a world with

CDNs show that HTTP URIs can be used to identify a single resource that 
can have multiple copies in different locations.

> ...

I still don't see what this has to do with "location" vs "naming". You 
can start with a locator and overload it as a name, or you can start 
with a name and overload it as locator.

The former has been done a lot with HTTP URIs, the latter is what you 
seem to try to do with URN resolution.

In the end, where's the difference?

> domain names, and the need of identifying abstract entities such as

If you don't use domain names, you'll need an alternate system to 
delegate responsibilities. Who's going to run it? Who's going to 
guarantee persistence of *that* system`?

> works (which may or may not have manifestations in the Web).

"A 303 response to a GET request indicates that the requested resource 
does not have a representation of its own that can be transferred by the 
server over HTTP. The Location URI indicates a resource that is 
descriptive of the target resource, such that the follow-on 
representation might be useful to recipients without implying that it 
adequately represents the target resource. Note that answers to the 
questions of what can be represented, what representations are adequate, 
and what might be a useful description are outside the scope of HTTP and 
thus entirely determined by the URI owner(s)." -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#rfc.section.7.3.4>

> ...

Best regards, Julian

---

From: Jonathan A Rees <[email-masked]>
Date: Tue, 10 Jan 2012 09:15:42 -0500

On Tue, Jan 10, 2012 at 4:30 AM, Julian Reschke <[email-masked]> wrote:

> I still don't see what this has to do with "location" vs "naming". You can
> start with a locator and overload it as a name, or you can start with a name
> and overload it as locator.
>
> The former has been done a lot with HTTP URIs, the latter is what you seem
> to try to do with URN resolution.
>

As I see it the significant difference between urn: and http: is that
the NID registry is administered by IETF through the RFC process, and
establishes NIDs permanently, while the domain name registries (other
than .arpa, .example, and .invalid) are administered by ICANN (with
delegation to TLDs and so on), and seem to always involve the threats
of expiration and steward corruption.

If the NID namespace were embedded in .arpa we could have a full equivalence:

urn:nid:path  == http://nid.urn.arpa/path

The latter could even be resolvable in the usual HTTP way, if someone
were to set up a network of servers that did URN resolution via DNS
and HTTP. (Obviously just best effort, as some legitimate URNs are
going to be unresolvable.)

> If you don't use domain names, you'll need an alternate system to delegate
> responsibilities. Who's going to run it? Who's going to guarantee
> persistence of *that* system`?

I think persistence and resolvability can and should be decoupled, and
treated as separate responsibilities.

Persistence is relative and to some extent subjective. I would say
that the RFC series is a pretty good bet for persistence, as are the
non-DNS registries such as media type, link relation, message header,
etc. So that is where I would set the bar - are the bindings of the
URIs in question (whether URN or HTTP) as persistent as the binding of
(say) media type name to media type?

To answer the question of responsibility for persistence, URN
persistence devolves to IETF, with the help of IANA, and with
delegation to the NID authorities. Persistence of the NID
registrations is enhanced by the existence of mirrors of the IETF RFC
series. If you trust the NID authorities and their technical
infrastructure and succession plans then URNs are as persistent as the
RFC series. Whether you do trust them or not is sort of up to you.

We don't have a persistence story like this for http: since domain
name registration (outside of .arpa) seems to always be vulnerable to
loss. No matter how much you trust an organization's ability to
maintain the registration over decades, there will always be a nagging
doubt, which is very annoying.

I too find the "naming" vs. "location" dichotomy not very compelling,
but I do find the renewal requirement vs. permanent NID registration
to be hard to gloss over. For me, expiration and corruption risks are
the real hole in the "Cool URIs" story.

Resolvability via DNS is a different story from persistence, and
indeed the business model for the party that would be responsible for
resolution is not clear to me. IETF and IANA absorb the cost for other
registries, but might balk at being asked to provide DNS support for
something like .urn.arpa. This for me is the hole in the "resolvable
persistent URI" idea. But I am not convinced yet that this is
insurmountable. We do have other persistent registries, so the
difficulty has to be one of scale, not of kind.

> "A 303 response to a GET request indicates that the requested resource does
> not have a representation of its own that can be transferred by the server
> over HTTP. The Location URI indicates a resource that is descriptive of the
> target resource, such that the follow-on representation might be useful to
> recipients without implying that it adequately represents the target
> resource. Note that answers to the questions of what can be represented,
> what representations are adequate, and what might be a useful description
> are outside the scope of HTTP and thus entirely determined by the URI
> owner(s)." --

+1

Best
Jonathan

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 Jan 2012 15:48:22 -0700

<hat type='individual'/>

This is off-topic. My apologies for the tangent...

> (say) media type name to media type?

I wonder whether it would be useful to define a URN namespace for IANA,
so that applications could persistently name individual entries in IANA
registries. As examples:

urn:iana:managesieve:capabilities:SASL

urn:iana:media-types:application:atom+xml

urn:iana:sdp-security-descriptions:crypto-suites:SEED_128_GCM_96

Last summer I wrote an Internet-Draft on this topic, but I never
submitted it. If you think this might have value, please ping me off-list.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 Jan 2012 15:52:10 -0700

<hat type='individual'/>

On 12/23/11 1:49 AM, Julian Reschke wrote:
> On 2011-12-23 09:14, Juha Hakala wrote:
>> ...
>> Is there a way to estimate how widely the UUID community is using
>> urn:uuids, and for what purposes?
>> ...
> 
> I think it's safe to say that it's used a lot if you need a globally
> unique URI that doesn't need to be resolvable.
> 
> And no, I don't think there's something like an "UUID community"...

Agreed.

>>> Do you want to force identifiers like these into different URI
>>> schemes? Why?
>>
>> To be honest, I would rather not see another URN namespace like uuid,
>> since most users of persistent identifier systems have service
>> expectations based on resolvability. And URN:UUIDs a priori will not
>> fulfill any of these expectations. But based on what Peter said earlier,
>> I suppose URN:UUID is and will be different from (all/most) other URN
>> namespaces in this respect.
> 
> We should keep that the important point in UR*N* * *naming*.
> 
> URNs *can* be (made) resolvable, and URLs *can* be (stable) names.
> 
> If this WG believes that urn:uuid is something that is kind of wrong
> then I think we have a problem :-)

We had a discussion about that last year, in which folks set me straight
regarding the UUID NID:

http://www.ietf.org/mail-archive/web/urn/current/msg01616.html

>>> Also, once you start to focus too much on resolution then you'll
>>> inevitably get people asking why you don't start with a scheme that
>>> already is resolvable in the first place. In the end, stability of
>>> URIs depends mainly on those who mint them, not on the actual notation.
>>
>> Yes, there is a broad agreement among the people who deal with long term
>> preservation of digital content that preservation is primarily an
>> organizational issue.
>>
>> The reason why resolution is important is that URN and other persistent
>> identifiers will only become popular if they can provide added value;
>> services which cool URIs etc. cannot support at all, or could only
>> support with difficulty. These services are often based on resolution.
> 
> I don't follow. Any kind of organization that can make name-based
> identifiers stable and resolvable *could* do that with HTTP URIs as
> well. It's not a technical problem but only one of organization.
> 
>> There are good reasons for keeping services and identification apart
>> (for instance, services are technology driven and will change over
>> time), which is why the URN community has tried to avoid conflicts here,
>> both in the existing URN RFCs and in the documents currently under
>> development.
> 
> Is this the "HTTP" may go way argument? Even if it does, you will still
> be able to write resolvers, just like what you're trying to do right now
> with URNs.

True.

In any case, what is the practical output of this discussion in terms of
specification text?

Peter

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

---

From: "Svensson, Lars" <[email-masked]>
Date: Thu, 12 Jan 2012 18:35:52 +0000

> of expiration and steward corruption.

[...]

+1

+1

Thanks, Jonathan. Excellent points!

All the best,

Lars
  **** Bitte beachten Sie die neue Internet- und E-Mail-Adresse. ****
  **** Please note my new internet- and email-address. ****

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