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

[Peter Saint-Andre <[e-mail]>]

<hat type='individual'/>

On 11/17/11 3:18 AM, Juha Hakala wrote:
> 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).

See the message I just sent about 2141bis. I think this claim is not
exactly uncontroversial.

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

Proposed text is always good, so thanks for sending it.

I don't know if we need to explicitly make a distinction here between
data records/resources and metadata records/resources. Isn't that a
matter for particular namespace definitions?

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

I think that makes sense.

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

Why?

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.

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

Do you have evidence that any existing namespaces are being used in such
an uncontrolled manner?

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

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

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.

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

> 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

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?

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"?

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.

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

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

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

Why?

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

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

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

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

That seems sensible.

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

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