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

[Peter Saint-Andre <[e-mail]>]

<hat type='individual'/>

On 10/13/11 5:22 AM, Juha Hakala wrote:
> 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.

Are those the versions that were published here?

http://tools.ietf.org/html/draft-ietf-urnbis-rfc3187bis-isbn-urn-01

http://tools.ietf.org/html/draft-ietf-urnbis-rfc3188bis-nbn-urn-01

> 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. 

I think you are basing your conclusions on ISBN and NBN only. I think
it's fairly easy to write a decent namespace registration, but most of
them are used for the issuance of URNs for things like XML namespaces,
not for the kind of resources you care about. Furthermore, none of the
NID registrations I have shepherded as Area Director involve resolution,
which introduces further complexities.

> 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 think that makes sense in the context of NBNs and other such URNs.

> 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.

I'd welcome that discussion.

> 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.

I think that UUIDs are very much the outlier here. None of the other
namespaces are uncontrolled in the way that UUIDs are.

> 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.

All of the NID registrations that I have shepherded were informational.

> 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.

Please again refer to the discussion we had in September about UUIDs.
It's a hasty generalization to talk about UUID-like namespaces, because
we have only one.

> 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. 

What evidence do you have for saying that?

> Whether the
> level of control needs to be heightened is hard to say without making
> some kind of empirical check.

What exactly are you worried about? Perhaps if you could describe the
concerns you have with non-UUID namespaces, that would help us
understand what you are trying to accomplish by tightening control over
the issuance of NIDs.

Peter

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