[urn] Of RFC3187bis, RFC3188bis and namespace registrations in general

[Juha Hakala <[e-mail]>]

Hello,

I have written updated versions of

* draft-ietf-urnbis-rfc3187bis-isbn-urn
* draft-ietf-urnbis-rfc3188bis-nbn-urn

Some editorial help will be needed to publish them as Internet drafts; 
what I have now is two XML texts that need to be polished/converted to 
I-Ds. But I can send them either to the list (if that is OK) or anybody 
who is interested to review them.

Since these texts rely on unpublished new version of rfc2141bis that 
myself and Alfred Hoenes have been working on, I'd rather wait until the 
next version of rfc2141bis has been made available before publishing 
them as I-Ds. But the WG is, like Peter pointed out in his message a 
week ago, behind schedule. And as the fact that we have been working on 
new versions of the I-Ds has not been made clear in the messages sent to 
the list, it is easy to get an impression that nothing much is happening 
in this particular WG. So if need be I am prepared to make some 
shortcuts here.

Some comments concerning these namespace registrations and namespace 
registration process in general.

I have taken into account the discussions on the list, especially as 
regards <fragment>. For ISBN this was trivial, since ISBN standard does 
not allow <fragment> usage. For NBN this was more complicated; there are 
three different ways in which fragments can be dealt with within that 
namespace.

And this serves as an introduction to the first generic point, which is 
that the difficulty of writing a (decent) namespace registration has an 
inverse relation to the level of establishment the namespace has. ISBN 
is based on an international standard and it has been in production 
almost 40 years. It is easy to write a namespace registration to it, 
provided that the standard is not heavily modified and assignment 
practices do not change. No such changes are imminent in the case of ISBN.

It is more difficult to supply an accurate NBN namespace registration. 
We have fairly good idea of who uses URN:NBN and for what purposes, but 
still the scope is not self evident. Unlike the previous versions, the 
I-D I completed today explicitly allows NBN assignment to works (things 
that only exist in Plato's world of ideas, such as "Hamlet"). These 
URN:NBNs will be resolved to work level metadata, which should include 
links to manifestations of the work. ISBNs can not be assigned to works; 
there is another identifier (ISTC) for that purpose.

If you dislike the extension of the URN coverage to works, please 
discuss this topic on the list. For me, works may play a central role in 
the URN resolution since they are persistent (they are abstract entities 
that never change) whereas manifestations of digital resources are 
technology dependent and will not live long. But work level metadata is 
the bedrock to which we will be able to link all manifestations (and 
related works such as translations) related to a single work.

I can't recall if the scope of the URN system as a whole has ever been 
formally specified. This issue is a bit complicated since the scope of 
the URN is the sum of all scopes of the identifiers that have a URN 
namespace. It only takes one very large namespace such as UUID to cover 
almost everything. But it might still be useful to discuss this topic, 
in order to see if there is a consensus among the list subscribers.

Going back to NBN after this diversion, lots of things that are dictated 
by the base standard in the ISBN namespace, had to be written into the 
NBN namespace registration in order to make sure the users have an 
accurate enough idea of how to utilize URN:NBNs.

There are also namespaces where there seems to be very little control, 
that is, basically anyone can use them to identify anything at any time. 
At least for a librarian like myself identifier assignment should not be 
organised like this. UUID has been mentioned before as an example of 
namespace which may require (local) control mechanisms beyond the 
namespace registration to function well. These URNs may fulfill the 
basic syntactic requirement of being globally unique, but beyond that 
these namespaces cannot guarantee much, although there may be islands of 
reliable resolution within them.

As far as I am concerned, when a namespace registration is based on an 
international identifier standard such as ISBN, the RFC can / should be 
put on standard track. I am less certain what to do with NBN-like 
semi-established namespace registrations. At least IETF should take a 
good look at the communities behind them.

I am not sure (without checking e.g. how URN:UUIDs work in practice) if 
UUID-like namespaces are really useful. I doubt if the identified 
resources themselves, or anything meaningful their URNs might resolve 
to, will be in existence for long (from the national library point of 
view, meaning several decades or even centuries). In the worst case 
there may eventually be many low-quality namespaces where most URNs will 
not live much longer than URLs or cool URIs. Such namespaces might 
eventually undermine the value of the URN system as a whole.

I suppose that all this boils down to the question of control. Up to now 
IETF has operated on the basis of trust; as namespace registrations are 
informal RFCs they have not been (I suppose) scrutinized. Whether the 
level of control needs to be heightened is hard to say without making 
some kind of empirical check.

Best regards,

Juha
-- 

  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 [e-mail], tel [phone]