Subject: [urn] Revision of URI resolution services

From: Juha Hakala <[email-masked]>
Date: Mon, 14 Mar 2011 11:47:12 +0200

Hello all,

Revision of RFC 2483 (URI resolution services necessary for URN 
resolution) is not included in the charter of URNBIS WG at the moment. 
The purpose of this message is to explain why the revision of this 
(experimental) RFC might be a good idea. Comments are welcome!

Best regards,

Juha Hakala

------------------

Revision of URI resolution services

Many operations can be performed on a URI. For URNs, services that can 
be provided have been specified in experimental RFC 2483. These services 
are:

I2L 	URI to URL
I2Ls 	URI to URLs
I2R	URI to resource
I2Rs	URI to resources
I2C	URI to URC, metadata about the resource)
I2Cs	URI to URCs
I2N	URI to URN
I2Ns	URI to URNs
I=I	Is URI equal to URI)

This list represents the very best understanding and the expertise the 
URN community (including myself as a lurker) had in late 90s. Since 
then, the technological environment in which persistent identifiers are 
or can be used has changed drastically. Long term preservation systems 
such as Tessella’s Safety Deposit Box and Ex Libris’ Rosetta are among 
the key applications that require persistent identification of archived 
resources and resource-related metadata. Compared with "traditional" 
digital asset management systems, they require a extended set of 
resolution services.

On the other hand, various persistent identifier systems such as ARK, 
DOI, Handle alongside URN) have been in production since late 90s, and 
millions of PIDs have been assigned. Our understanding of technical 
issues and solutions related to the resolution of persistent identifiers 
has increased. There is no agreement, though: some persistent 
identifiers enable services not included in RFC 2483; for instance, with 
ARK it is possible to make a permanence policy request concerning the 
identified resource.

A few URN-related conclusions can be drawn from the developments of the 
last decade:

1. The services listed in RFC 2483 are no longer sufficient

2. Given the continuous technical change, it is unlikely that anyone can 
produce a list of resolution services that would remain valid for long

3. Therefore the mechanism for specifying new URN resolution services 
should be flexible, and allow services on different levels of maturity 
or applicability

These conclusions apply to basically every persistent identifier system.

As regards the URN system, the following recommendations can be made:

1. Add revision of RFC 2483 to the charter of URNBIS WG (once the WG has 
completed its current tasks)

2. Instead of trying to update the list of URN resolution services in 
RFC 2483, the WG should produce RFC 2483bis which defines a mechanism 
for specification of formal, informal and experimental URI resolution 
services. An IANA registry, similar to the registry for URN namespaces, 
is one option.

3. Using the mechanism outlined in RFC2483bis,the URNBIS working group 
and (later) URN implementers should create an extended set of resolution 
services based on & compliant with those listed in RFC 2483.

4. Propose and agree upon a mechanism for the long term maintenance of 
the service list

5. Establish a mechanism via which the information about new or changed 
services is communicated to the organisations / people maintaining other 
persistent identifier systems.

URN-related projects such as PersID have identified potential new 
resolution services; some of them can be vital to the success of these 
initiatives. If these novel services are implemented in the project 
level only without broader recognition there may be a danger that the 
co-ordination of the URN system will suffer.
-- 

  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: "Bengt Neiss" <[email-masked]>
Date: Thu, 24 Mar 2011 13:45:07 +0100

Hello all,

I think that it would be very good if the charter could be extended to include revision of RFC 2483.

There are several organizations (well, national libraries mostly) that I am aware of that have started to develop or have plans to develop new software for their resolution services.
At the current state I think the risk is quite substantial that the development of new resolution services (without a revised RFC) might create future interoperability problems.

Best regards,

Bengt Neiss

---------------------------------------------------------
Bengt Neiss
Kungl. Biblioteket / National Library of Sweden
Phone: +46 (0)10 709 35 41

-----Ursprungligt meddelande-----
Från: [email-masked] [mailto:[email-masked]] För Juha Hakala
Skickat: den 14 mars 2011 10:47
Till: [email-masked]
Kopia: Cordewener, Bas; Tommi Jauhiainen; Esa-Pekka Keskitalo
Ämne: [urn] Revision of URI resolution services

Hello all,

Best regards,

Juha Hakala

------------------

Many operations can be performed on a URI. For URNs, services that can be provided have been specified in experimental RFC 2483. These services
are:

I2L 	URI to URL
I2Ls 	URI to URLs
I2R	URI to resource
I2Rs	URI to resources

This list represents the very best understanding and the expertise the URN community (including myself as a lurker) had in late 90s. Since then, the technological environment in which persistent identifiers are or can be used has changed drastically. Long term preservation systems such as Tessella’s Safety Deposit Box and Ex Libris’ Rosetta are among the key applications that require persistent identification of archived resources and resource-related metadata. Compared with "traditional" 
digital asset management systems, they require a extended set of resolution services.

On the other hand, various persistent identifier systems such as ARK, DOI, Handle alongside URN) have been in production since late 90s, and millions of PIDs have been assigned. Our understanding of technical issues and solutions related to the resolution of persistent identifiers has increased. There is no agreement, though: some persistent identifiers enable services not included in RFC 2483; for instance, with ARK it is possible to make a permanence policy request concerning the identified resource.

A few URN-related conclusions can be drawn from the developments of the last decade:

2. Given the continuous technical change, it is unlikely that anyone can produce a list of resolution services that would remain valid for long

3. Therefore the mechanism for specifying new URN resolution services should be flexible, and allow services on different levels of maturity or applicability

1. Add revision of RFC 2483 to the charter of URNBIS WG (once the WG has completed its current tasks)

2. Instead of trying to update the list of URN resolution services in RFC 2483, the WG should produce RFC 2483bis which defines a mechanism for specification of formal, informal and experimental URI resolution services. An IANA registry, similar to the registry for URN namespaces, is one option.

3. Using the mechanism outlined in RFC2483bis,the URNBIS working group and (later) URN implementers should create an extended set of resolution services based on & compliant with those listed in RFC 2483.

4. Propose and agree upon a mechanism for the long term maintenance of the service list

5. Establish a mechanism via which the information about new or changed services is communicated to the organisations / people maintaining other persistent identifier systems.

URN-related projects such as PersID have identified potential new resolution services; some of them can be vital to the success of these initiatives. If these novel services are implemented in the project level only without broader recognition there may be a danger that the co-ordination of the URN system will suffer.
-- 

  Juha Hakala

  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 _______________________________________________
urn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/urn

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Mar 2011 12:06:47 -0600

<hat type='AD'/>

> (experimental) RFC might be a good idea. Comments are welcome!

The Working Group's contract with the IESG (a.k.a. "the charter") was
expressly negotiated based on the assumption that the URNBIS WG would
finish its work on revising RFC 2141 and RFC 3406 before moving on to
the more complicated and contentious topic of URN resolution. Let's
focus on the work described in the current charter. If folks really want
to start working on URN resolution, they should put some of their energy
into 2141bis and 3406bis (e.g., by providing document reviews or logging
issues in the tracker) so that we can finish those deliverables and then
talk about rechartering the WG to include work on resolution.

Peter

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