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

Juha Hakala <juha.hakala@helsinki.fi> Wed, 21 December 2011 12:02 UTC

Return-Path: <juha.hakala@helsinki.fi>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E392521F8A56 for <urn@ietfa.amsl.com>; Wed, 21 Dec 2011 04:02:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vyQNArSmR6t for <urn@ietfa.amsl.com>; Wed, 21 Dec 2011 04:02:52 -0800 (PST)
Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1545121F8A57 for <urn@ietf.org>; Wed, 21 Dec 2011 04:02:46 -0800 (PST)
Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id pBLC2gF0006543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Dec 2011 14:02:43 +0200
Message-ID: <4EF1CAE2.7000900@helsinki.fi>
Date: Wed, 21 Dec 2011 14:02:42 +0200
From: Juha Hakala <juha.hakala@helsinki.fi>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <4E96C9EA.8070605@helsinki.fi> <4EEBBE82.3090004@stpeter.im>
In-Reply-To: <4EEBBE82.3090004@stpeter.im>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] Of RFC3187bis, RFC3188bis and namespace registrations in general
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Dec 2011 12:02:54 -0000

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 juha.hakala@helsinki.fi, tel +358 50 382 7678