Subject: [urn] Comments to the draft-ietf-urnbis-rfc3406bis-urn-ns-reg-00

From: Juha Hakala <[email-masked]>
Date: Thu, 23 Dec 2010 13:46:22 +0200

Hello all,

Please find below a few comments on RFC3406bis.

Experimental namespaces

RFC 3406 was published about eight years ago. Since then, as far as we 
know, no such namespaces have been announced. It is difficult to draw 
any firm conclusions from that, since some organizations may have been 
using these namespaces internally, without informing anybody.

Moreover, even if there had been no usage at all, in order to maintain 
backwards compatibility with RFC 3406 it is better not to drop these 
namespaces (as suggested in RFC3406bis) but to keep them in new 
specification as well.

Formal namespaces (chapter 3.3)

As the RFC3406bis states, the IETF community will be able to analyze a 
namespace registration document and find technical flaws which would 
impair or prevent persistent identification and perhaps even more 
importantly resolution of URNs belonging to the namespace.

The three aspects mentioned in this context mentioned at this point are 
however not technical. The first one (organization maintaining the URN 
namespace should demonstrate stability and the ability to to maintain 
the URN namespace) is an organizational and political issue. IETF 
experts will not be capable on analyzing this, except in a superficial 
manner. The second (demonstrate ability and competence in name 
assignment) is again an organizational issue and not a technical one. 
The third point (commit to not re-assign existing names) is deeply 
embedded in any proper identifier system and does not need to be 
mentioned here.

I suggest that the sentence preceding the aspects mentioned could read:

In addition to the technical aspects of the resolution, the following 
organisational aspects should be considered as well:

Practical experience and demonstrated competence in identifier 
assignment is important; it is hard to believe that an organisation 
starting from scratch the difficult business of assigning persistent 
identifiers could do even that properly. And preservation of digital 
resources and identifier-based links to them is harder than mere 
assigment of identifiers.

When organisational issues are evaluated, it is also important to check 
the mandate. For instance, the National Library of Finland might try to 
re-register the ISSN namespace, but only the ISSN International Centre 
has a proper mandate for this. Most ISO standard identifier systems have 
registration authorities (maintenance agencies) and these, and only 
these, should make the namespace registrations.

 From the technical point of view, it is important that the namespace 
registration request contains detailed enough description of how the 
URNs in this namespace are resolved. As a rule, URNs (and identifiers in 
general) can be divided into two categories, semantic and non-semantic 
(or "dumb"). The former contain a hint which tells the global resolver 
discovery service where to find an appropriate resolver. These hints can 
take many forms; in the NBN namespace the hint is given by the country 
code in the beginning of the NSS string, and in the ISBN is embedded in 
the identifier string, which specifies both the area (for instance, 951 
for Finland or 3 for Germany, Austria and German-speaking areas of 
Switzerland) and the publisher.

In contrast, non-semantic identifier is a string with no embedded 
meaning. ISSN is a well-known example of these identifiers, which can 
only be resolved in a single location; in this case, the ISSN database 
maintained by the ISSN International Centre.

IETF must check if a) the identifier is semantic or non-semantic, and b) 
how many resolution services are required. Dubious cases are 
non-semantic identifiers which require multiple resolution services.

Technical analysis may also encompass the evaluation of technical 
competence of the organisation than maintains the centralized resolution 
service. Such analysis is important especially if the namespace is 
popular and/or large (when measured with the number of identifiers 
assigned).

Formal namespaces (again, this time chapter 4.3)

Formal NID applications can be published either as informational or 
standards track RFCs. RFC3406bis could suggest that if the namespace 
belongs to a standard identifier such as ISBN or ISSN, the namespace 
registration should as a rule be a standards track RFC. On the other 
hand, namespaces belonging to non-standard identifiers should be 
informational RFCs.

Namespace considerations

More than one namespace may indeed serve the same functional purpose. 
For instance, books may have either ISBN or NBN, since ISBNs are usually 
not assigned retrospectively to books that were published before the 
ISBN system was established in 1970s.

While this overlap is usually benign and not as such any concern of the 
URN system, namespace registrations should however make clear what is 
the niche of the proposed identifier. If someone for instance invents a 
new in-house identifier for e-books and then applies for a URN namespace 
for it, namespace registration should make this overlap evident and IESG 
in turn may choose not to approve such a namespace, at least not as a 
formal one.

A namespace may have needs to go beyond what the URN system can deliver 
at any given moment. Such extra requirements may relate to services or 
syntax issues.

It is important to make the URN system more flexible as regards 
services; it might make sense to specify formal, informal and 
experimental services, of which only the formal and informal ones should 
be referred to in the namespace registration. The registration could / 
should also specify for instance the need for using <query> and 
<fragment>, with sufficient details on how these are to be utilised.

IANA considerations

It may make sense to reserve permanently not only "urn" but also "url", 
"uri" and "urc" in order to avoid confusion.

Community considerations

The I-D suggests merging namespace and community considerations. Given 
that it may be difficult to divide these considerations logically, I am 
in favour of such a change.

Best regards,

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