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

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 16 Dec 2011 14:56:18 -0700

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

---

From: SM <[email-masked]>
Date: Sat, 17 Dec 2011 02:07:31 -0800

>I'd welcome that discussion.

Seven messages were posted to this mailing list since November 
1.  Two of the messages were about a workshop.  Three of them were 
from Peter Saint-Andre as an individual.

According to the working group charter, the milestone for 
rfc3187bis-isbn-urn and rfc3188bis-nbn-urn was February 2011.  On 
October 3, the Responsible AD commented on the working group progress 
[1].  This working group was formed on November 23, 2011.  It has not 
been able to produce an RFC in over a year.

Is it premature to ask for a consensus call on closing this working group? :-)

Regards,
-sm

P.S. I understand the work is important.  However, if there isn't any 
discussion about the drafts, it denotes a lack of interest in getting 
the drafts published as RFCs.

1. http://www.ietf.org/mail-archive/web/urn/current/msg01626.html

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Dec 2011 10:55:27 -0700

<hat type='AD'/>

On 12/17/11 3:07 AM, SM wrote:
> Seven messages were posted to this mailing list since November 1.  Two
> of the messages were about a workshop.  Three of them were from Peter
> Saint-Andre as an individual.

SM, although I too am concerned about the lack of involvement, the
choice of November 1 as the cutoff date for your measurements is a bit
misleading, because there was a flurry of activity (at least from Juha
and Alfred) in October. However, the lack of activity since then is not
encouraging.

Peter

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

---

From: Juha Hakala <[email-masked]>
Date: Wed, 21 Dec 2011 14:02:42 +0200

Hello Peter; all,

Please see some responses to your questions below. (Sorry, this message 
is quite long.)

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

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

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

> 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.
> understand what you are trying to accomplish by tightening control over

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

-- 

  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: Andy Newton <[email-masked]>
Date: Wed, 21 Dec 2011 09:28:48 -0500

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Dec 2011 09:53:07 -0700

<hat type='AD'/>

On 12/21/11 7:28 AM, Andy Newton wrote:
> 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

Andy, I think that would indeed be helpful. Although the more
"philosophical" issues are interesting and important, we also need to
focus the discussion down to specific text proposals to be incorporated
into the specificuations under consideration. Using the issue tracker
might help move us in that direction.

Peter

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

---

From: SM <[email-masked]>
Date: Wed, 21 Dec 2011 10:08:37 -0800

Hi Peter,
>misleading, because there was a flurry of activity (at least from Juha

I agree that the choice of the cutoff date for the measurement is 
misleading.  It helps to have somebody else (e.g. as you did in this 
case) discuss about the comments and drafts to catch mistakes.

Regards,
-sm

---

From: Juha Hakala <[email-masked]>
Date: Thu, 22 Dec 2011 14:04:21 +0200

Hello,

Issue tracker has been actively (and I think productively) used in the 
IRI group. So I am in favour of this suggestion, in principle.

In practice isolating and formulating the issues can be complicated to 
those of us (including myself) who have no first hand experience of such 
working method. Perhaps IETF veterans could extract a few tangible 
issues from the discussions we've had on the list of late. Moreover, I 
would rather not formulate the issues myself since IETF folks may have 
more objective view on problems that still need to be solved.

There are cases in which the document level (small) issues and 
architectural principles we have discussed are intertwined. For 
instance, if we agree that URNs can be applied to works, then we should 
also outline a model of how works and their manifestations are connected 
to one another, and derive some conclusions as regards what kind of 
impact this model may have to URN services.

Of course we could also start the discussion from the top, agree on a 
model and then start deriving practical conclusions from there. But this 
approach would require more faith than the bottom - top -one.

Juha

-- 

  Juha Hakala