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

[Juha Hakala <[e-mail]>]

Hello Peter,

Again a few comments below.

Peter Saint-Andre wrote:
> <hat type='individual'/>

>> 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, 
> 
> Why?

The three most popular persistent identifier systems in existence at the 
moment are Handle, DOI and URN.

Technically speaking, DOIs are Handles. The key difference between the 
two is the level of control; while Handle usage policy is liberal and 
nobody knows have many Handles have been assigned, DOI is centrally 
co-ordinated system where the level of control is high. And there is a 
good chance that DOIs will live longer than normal Handles.

With URN, all namespaces are currently equal, and the reader has no 
simple means of estimating the relative trustworthiness of the URNs 
belonging to different namespaces. But there are ways in which we can 
introduce a simple mechanism with which to indicate that some namespaces 
may be more reliable.

For instance, 3406bis might say that if a namespace does not specify the 
e.g. organisational background and if there is no description of the 
resolution mechanism (or if these descriptions are vague), then the 
registration request may be approved, but the RFC will be only 
informational. On the other hand, if all the essential data is provided, 
the registration could be elevated to standards track (perhaps iff the 
namespace is based on a proper standard). The registration request 
should then contain a question of whether the registrants want a 
standard status to the registration or not.

URN system would still differ significantly from DOI/Handle, since 
instead of a sharp dichotomy, we would have all kinds of shades of grey. 
  Some namespaces such as issn (which will use a single resolution 
service maintained by the ISSN international centre) will be very 
reliable, whereas some other standard track namespaces will be slightly 
less so.

> I would not describe the registration process as overly loose. Quite a
> bit of attention is paid to registration requests on the urn-nid list.

I may have been misled by paying too much attention to UUID. I suppose 
the archive of the urn-nid is accessible so that the URNBIS folks can 
see what has been going on.

>> 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.
> 
> Do you have evidence that any existing namespaces are being used in such
> an uncontrolled manner?

No, and it would be difficult to obtain it. There can be at least three 
kinds of problems: dysfunctional URNs which are not capable of providing 
any services, lack of resolver infrastructure, and lack of URN 
assignment. It is not and it will not be easy to spot these, manually or 
otherwise.

Having said this, it is not hard to find URNs from UUID namespace using 
Google. But trying to resolve

urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

is impossible since I don't know the address of the resolution service.

> The UUID namespace is different from the rest. See the thread we had on
> this list back in September, starting here:
> 
> http://www.ietf.org/mail-archive/web/urn/current/msg01612.html

OK.

> You wouldn't use the UUID namespace if you had another namespace to use.
> If publishers are using that namespace instead of the ISBN namespace,
> then that is their fault.

For libraries, NBN is the fall back mechanism when other systems such as 
ISBN cannot be used. I can see the point of UUID namespace from this 
point of view (as the system level fall back namespace). I still have a 
problem grasping how such an abstract namespace would work in practice, 
but that may be a solely personal issue :-).
> 
>> 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.
> 
> Are you proposing that we change "some" to "careful"? That seems fine to
> me, since careful consideration is already given.

Yes.

>> As regards the three bullet points in page 7, I suggest the following
>> changes:
> 
> Those changes are hard to track. Please in the future provide such
> changes via the following convention:
> 
> OLD
>    lorem ipsum foo bar baz qux
> 
> NEW
>    some new text here

OK.
> 
> So:
> 
> OLD
>> -  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;
> 
> NEW
>>    -  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);
> 
> That doesn't seem like an improvement to me. You've removed the notion
> of organizational stability and added competency. How do you judge
> competency? What if the organization hasn't issued URNs before? And are
> we really worried about incompetent namespace administrators?

I withdraw the suggestion, except that the competency in identifier/name 
assignment should be added to the old text.
> 
> Furthermore, persistence considerations are already contained elsewhere
> in the document.
> 
> I realize that your text is in fact closer to RFC 3406 (rather than
> 3406bis), so perhaps the WG might have consensus to keep what's in the
> current RFC. But please note that those bullet points are included as
> the types of things that people might consider.
> 
> OLD
>> - 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.
> 
> NEW
>>    -  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.
> 
> Why "user organizations"?

It has a different scope: although there will be just one organisation 
which assigns the URN, there will be many more in the foreseeable future 
using the URN to provide services, and they may be tempted to reassign 
URNs at some point.

> And again resolution is creeping in here. That isn't a necessary aspect
> of URNs and shouldn't be a core consideration in the assignment of
> namespaces.

OK.

>> 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).
> 
> 2 weeks has proven to be sufficient, in my experience on the urn-nid list.

OK; if we allow some registrations to become standards track documents, 
that may (I guess) mean stricter control for those namespaces.
> 
>> 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.
> 
> I agree that registrants are often confused about what needs to go in
> the community considerations section.
> 
>> 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). 
> 
> That's a good list of considerations. I might add a few more once I have
> time to think about my experience with namespace registrations.

OK.

>> Something may also be said about the costs of
>> maintaining the system.
> 
> Why?

Costs of the system and the funding mechanism may have an impact on the 
longevity of the service. I might trust more on a service which is 
relatively cheap and funded from the state budget, than on a system 
which is expensive and dependent on private donations.

>> Registration requests with intentionally misleading NIDs (e.g. NID
>> UNESCO when the request has nothing to do with UNESCO) should be turned
>> down.
> 
> Do you think those restrictions need to be formalized? IMHO coming up
> with a complete list of reserved strings is fruitless -- better to leave
> this up to the judgment of the reviwers / document sponsor (typically an
> AD).

There is no way we could produce a complete list, but we should mention 
the principle of not approving misappropriate NIDs in the RFC so as to 
diminish the risk that somebody who has nothing to do with UN tries to 
register e.g. the namespace identifier "UNESCO".
> 
>> 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. 
> 
> I think validation applies to a URN, not the NSS.

We can and should validate NSS (whenever possible) as a part of the URN 
validation process. Generally, such validation can be carried out when 
the identifier contains a check sum. Quite a few of them do, and they 
tend to be very useful.

>> As regards elaboration of services: I am still working on RFC2483bis,
>> but completing the first draft take at least a few weeks.
> 
> Have you had a chance to work on that yet?

Alas, not yet. But I'll restart the drafting tomorrow, 23rd of December, 
and will concentrate on it on 27th and 28th. That may not be sufficient 
to complete the text, and I will face some technical problems in getting 
the XML coding right.

Juha
> 
> Peter
> 
>> Alfred Hoenes wrote:
>>> [e-mail] 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
>>> [e-mail]
>>> 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 [e-mail], tel [phone]