Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt

From: Juha Hakala <[email-masked]>
Date: Thu, 17 Nov 2011 12:18:21 +0200

Hello Alfred; all,

Below is my take on the open issues listed by Alfred, plus some 
additional comments.

Abstract

URN is a resource identifier; therefore the end of the last sentence of 
the first para could be changed into ... make available generic and 
persistent network-based resolution services for the identified 
resources (documents, artifacts and other objects, and metadata related 
to them).

Chapter 2

Statement "identifiers are never assigned to more than one resource" 
needs some tuning. Resources themselves may be static or dynamic (as 
pointed out in page 19). The identified resource may be a metadata 
record which describes a collection which contains a number of objects. 
The important thing is that the resolution process itself is clear; 
there must always be one and only one entity to resolve.

Suggested new formulation:

For the purposes of URNs, a "namespace" is a collection of uniquely 
assigned identifiers.  That is, the identifiers are never assigned to 
more than one resource. These resources may be stable (e.g. a doctoral 
dissertation) or dynamic (e.g. a continuously evolving web site of a 
periodical). When the identified resource is a metadata record, such 
record may describe several objects (such as two versions of a book) or 
a collection of objects. Once assigned, URNs are never re-assigned to a 
different resource.  A single resource, however, may have more than one 
URN assigned to it since the namespaces are not mutually exclusive.

Chapter 3.1 Experimental namespaces

After considering the issue, I am in favour of removing experimental 
namespaces. In 12 years, not a single experimental namespace has been 
registered. Nor do I foresee a need for them, as identifier systems 
which deserve a URN namespace should be relatively stable.

As an aside, we may need informal and experimental services. But these 
services (or mechanism for registering them) should not be described in 
rfc3406bis, but in rfc2483bis.

Chapter 3.3 Formal namespaces

It has been easy to register formal URN namespaces. In order to 
guarantee the reliability and persistence of the URN system, control 
should be tightened in the future, and rfc3406bis should provide tools 
for this.

Given the experiences from the last 12 years, the key factors here are 
scope (type of resources to be identified) and user community (who is 
entitled to assign identifiers in this namespace). Control is the key 
factor; the more clearly the scope and the user community are specified, 
the better. On the other hand, an identifier which covers everything and 
can be used by anybody should be treated with caution, due to overlap 
with all the other URN namespaces and total lack of control in the 
identifier assignment.

To illustrate the problem, we may compare urn:isbn and urn:uuid. ISBNs 
are assigned by large publishers and ISBN agencies for books. The system 
has been in operation for almost 40 years, and is deeply embedded into 
the book trade (which does not mean that everyone uses it correctly, or 
according to the same principles).

UUIDs can be assigned to everything (including books) by anyone. There 
is no control over this namespace; nobody knows how it is used and by 
whom. Some users may have utilized in a highly useful manner and this is 
to be hoped; once a namespace has been approved it can never be 
discontinued, unless it can be proven that zero URNs have been assigned 
(or remain resolvable).

It is not sufficient to give "some consideration as to the longevity and 
maintainability of the namespace" (see page 6). Careful consideration is 
called for.

As regards the three bullet points in page 7, I suggest the following 
changes:

-  the organization maintaining the URN Namespace should demonstrate
       stability and the ability to maintain the URN namespace for a long
       time, and/or it should be clear how the namespace can continue to
       be usable/useful if the organization ceases to be able to foster
       it;

    -  the organizations assigning URNs should demonstrate ability and 
competency in name assignment;
       this should improve the likelihood of persistence (e.g., to
       minimize the likelihood of conflicts);

- the organizations assigning URNs MUST follow the rules and regulations 
outlined in namespace registration reguests. They SHOULD always use the 
identifier which is the best match for the resource at hand (e.g. ISSN 
for serials). However, identifiers which do not have a registered URN 
namespace MUST NOT be expressed as URNs.

    -  the user organizations need to commit to not re-assign existing 
names. Old names MUST continue to be valid, even if the owners or assignees
       of those names are no longer members or customers of these
       organizations; this does not mean that there must be resolution of
       such names, but that they must not resolve the name to false or
       stale information, and that they must not be reassigned.

If the review process is made more strict, then more time than the 
current two weeks is needed. I suggest a review period of 8 weeks; this 
is still a very short time compared to the life time of namespaces 
(which should equal or exceed that of the URNs in that namespace).

4.4. Registration documents

After having written a few namespace registrations, I prefer keeping the 
namespace and community considerations separate. But it is necessary to 
clarify the differences between the two. My take on this is that we 
could rephrase thse aspects into technical and organisational 
considerations.

Technical (namespace) considerations are primarily technical and should 
outline the scope (types of resources to be identified), identifier 
assignment process, services needed (some of which may be non-existent 
by the time of registration), and the resolution process.

Organizational (community) considerations should clarify the background 
of the identifier used (formal standard or something else), its relation 
ot other identifier systems with or without URN namespace, and different 
aspects of the user community (who is allowed to assign these 
identifiers; who can use them for resolution; who maintains the 
resolution services). Something may also be said about the costs of 
maintaining the system.

IANA review should pay particular attention to the scope and user 
community (from the assignment point of view) issues. Standard 
identifier namespace registrations should always involve the maintenance 
agency of the standard in question.

4.4.4 IANA considerations

There are a lot of strings (in addition to "urn-" that must be reserved 
from IETF point of view, such as uri, urc, url, iana, ietf, iesg, and so 
on.

All known identifier acronyms should be reserved for those identifier 
systems.

Registration requests with intentionally misleading NIDs (e.g. NID 
UNESCO when the request has nothing to do with UNESCO) should be turned 
down.

Validation mechanism (page 20)

This section may still need some work.

First, it is possible to validate NSS if the identifier has a mechanism 
for it. For instance, when ISSN or ISBN is used as URN, it is possible 
to check that the namespace specific string is a valid ISBN or ISSN. In 
order to do this, the validator must be aware of the identifier syntax.

Second (and this is point 1 in the current version of the document), it 
is necessary to check the NID. There are a number of opportunities here. 
For instance, URN parsing may have revealed that the NSS is ISTC.  Even 
if the ISTC string were OK the URN would not be correct, since ISTC does 
not have a URN namespace (which may not prevent some people from using 
NID ISTC). We may also have valid NID (such as ISSN), but NSS that does 
not belong to this namespace; it can be either some other identifier 
(such as ISBN) or something unrecognizable. Such NID - NSS mismatch are 
fatal because they will prevent successfull resolution.

Third (point 2 in the current document) step is to check if the (valid) 
URN can be used for resolution. Many syntactically URNs will fail at 
this point; for instance, most URN:ISBNs are not functional yet. But 
this has nothing to do with the validity of those URNs; the problem is 
in the infrastructure. Thus this step is not part of the URN validation, 
but it can still be included as validation of the resolution process.

As regards elaboration of services: I am still working on RFC2483bis, 
but completing the first draft take at least a few weeks.

Alfred Hoenes wrote:
> [email-masked] wrote:
> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the Uniform Resource
>> Names, Revised Working Group of the IETF.
>>
>>   Title     : Uniform Resource Name (URN) Namespace Definition Mechanisms
>>   Author(s) : Alfred Hoenes
>>   Filename  : draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt
>>   Pages     : 29
>>   Date      : 2011-10-31
>>
>>   Uniform Resource Names (URNs) are intended to serve as persistent,
>>   location-independent, resource identifiers.  To structure and
>>   organize their usage, the URN syntax specifies a hierarchy that
>>   divides the set of possible URNs into "URN Namespaces" that can be
>>   individually defined and managed.  URN Namespaces in particular serve
>>   to map existing identifier systems into the URN system and thereby
>>   make available generic, network-based resolution services for the
>>   identified documents, artifacts, and other objects (and their
>>   metadata).
>>
>>   To actually leverage such synergetic advantage, URN Namespaces need
>>   to be specified in a comparable manner, and their Namespace
>>   Identifiers (NIDs) need to be registered with IANA, so that naming
>>   conflicts are avoided and implementers of services can follow a
>>   structured approach in support of various namespaces, guided by the
>>   registry to the related documents and the particularities of specific
>>   namespaces, as described in these namespace registration documents.
>>
>>   This document serves as a guideline for authors of URN Namespace
>>   definition and registration documents.  It describes the essential
>>   content of such documents and how they shall be structured to allow
>>   readers familar with the scheme to quickly assess the properties of a
>>   specific URN Namespace.  Further, this RFC describes the process to
>>   be followed to get a URN Namespace registered with IANA.
>>
>>   This document is a companion document to the revised URN Syntax
>>   specification, RFC 2141bis; it supersedes and replaces RFC 3406.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt
> 
> 
> [[ speaking as the draft author/editor ]]
> 
> This is mainly an editorial update, based on received review
> comments and a bit of on-list discussion.
> 
> Please see the newly amended Appendix D in the draft for the
> open issues that need on-list discussion, state your opinions,
> and provide replacement text snippets where deemed appropriate.
> 
> The delta information summary for this version inadvertently has
> been dropped during XML debugging; it will be restituted in the
> next draft version.
> 
> Best regards,
>   Alfred.
> 
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn
> 

-- 

  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