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

[Andy Newton <[e-mail]>]

Juha (and the WG),

One of the problems I see with these discussions is that these threads intertwine noted issues with the documents and larger architectural or philosophical issues. That can get confusing.

I would like to ask you, as a document editor, and the working group if we should use the issue tracker for dealing with document issues so that they do not get lost in the larger debates. Comments?

As for the larger issues, we can discuss them and after there is consensus on how to move forward with addressing those issues will be able to knock them out through documents.

What say you?

-andy

On Dec 21, 2011, at 7:02 AM, Juha Hakala wrote:

> Hello Peter; all,
> 
> Please see some responses to your questions below. (Sorry, this message is quite long.)
> 
> Peter Saint-Andre wrote:
>> <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
> 
> Yes.
> 
> While preparing these I-Ds (and 2141bis & 3406bis) for publication, Alfred did specify some issues which should be resolved. I have provided my own views, but there hasn't been other comments. It might have been helpful to split that discussion into separate topics. At least there would then have been more traffic on the list ;-).
> 
>>> 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.
> 
> With "decent" (thorough or complete might have been a more accurate term) I mean a registration which specifies the scope and syntax of the identifier (namespace specific string), provides an overview of identifier assignment process, describes the URNs resolution process and explains why these URNs are persistent.
> 
> In a well established namespace (such as e.g. ISBN) many of these things are settled in the identifier standard & well established identifier assignment process. It is possible to write a complete and concise description, which is easy to evaluate. Any identifier standard which gives the organizations a lot of room for improvisation would require a lot of additional rules in the namespace registration, if the aim were to bring all the namespaces to approximately same level. Most likely this is unrealistic, given that there are already e.g. namespace registrations which do not specify resolution processes.
> 
>>> 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.
> 
> Fine. I'll write more about this later.
> 
> My gut feeling is that in order to reduce uncertainties as regards the scope of the URN system as a whole and the nature of individual namespaces, the WG might produce a BCP which tries to provide the big picture. Another thing that should be discussed is the relation of URN to other persistent identifiers, both politically and technically (for instance: is IETF going to endorse other persistent identifiers such as XXX; is it possible to express XXXs as URNs). Choosing a persistent identifier systems is a long term commitment, and I am not sure if the implications are yet fully understood.
> 
> The implementers do expect that IETF will continue to endorse and develop URN system in the foreseeable future. The first step on this road is the current revision process. I do admit that the list has not been active, but there are at least two reasons for this: first, the work under way (according to the charter) is non-controversial from the point of view of the users, and second, the group of URN implementers is relatively small, and not all of them participate in the process. Most implementers of URN and other persistent identifiers are organisations which preserve digital resources for long term (decades, centuries), and given that the average life time of a web page is about 50-100 days (see http://blogs.loc.gov/digitalpreservation/2011/11/the-average-lifespan-of-a-webpage/) only a fraction of the Internet users are in a position where cool URIs are not cool at all.
> 
>>> 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.
> 
> OK. I have not analyzed all the existing 40+ namespace registrations, but I did read the one for UUID and did have some concerns about it. It is good to know that other namespaces are more restrained.
>>> 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.
> 
> Seems to me that the current practice can continue unchanged, except that namespace registrations for proper standards could be elevated to the standard track if the community wants that. Whether IETF should then introduce some additional requirements as regards the quality of the namespace registration is a different matter.
> 
>>> 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?
> 
> If strict quality criteria were applied, then organisations assigning URNs should be able to prove that they are able to preserve the identified resources for long term, and to maintain the resolution services as well. I suppose it is not realistic to require that IETF makes any assessments on the applicants of informal namespaces. At least some kind of checks could be added to when the namespace registration goes on standard track. Since persistence of a resource (and resolution service) is primarily an organizational issue, IETF should not ignore this issue.
> 
> It should be noted that the main difference between Handles and DOIs (the main competitors URN has in the PID "market") is organizational: every DOI is also a Handle, but there is a level of control with DOIs which is absent from most Handles.
>>> 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.
> 
> I am concerned that if IETF does not pay more attention to organizational issues related to the identifier assignment (and e.g. enable a two-tiered system in some ways similar to DOI / Handle based on ranking of namespaces) then over time URNs will not be as reliable as they should be. More trustworthy than URLs for sure, but URNs will not remain actionable for decades and centuries if anybody out there can get a permission to assign them and establish resolution services.
> 
> All the best,
> 
> Juha
>> Peter
>> --
>> Peter Saint-Andre
>> https://stpeter.im/
> 
> -- 
> 
> 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]
> _______________________________________________
> urn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/urn