comments on draft-ietf-uri-urn-resolution-01.txt

(I said, privately):
> This document doesn't sufficiently separate out the syntax of the
> proposed URNs, the semantics of the parts of them from the proposed
> resolution methods.

and Stu Weibel replied:
> Others have suggested that our proposal should be broken up into a services
> proposal and a URN proposal.  We think this a good idea, but had to choose
> between restructuring the entire work and doing a minor rewrite and getting
> it our before Stockholm.  

but we want to converge on the URN proposal while letting the various
resolution services be 'experimental'.

I said:
> It leaves completely unresolved the mechanisms for assignment of
> 'short, simple names'; 

And Stu replied:
> The assignment of short, simple names for naming authorities is exactly
> analogous to assignment of DNS domains.  It assumes the existence of a
> Naming Authority Registry, yes, but how specific does this need to be?

The mechanisms for name assignment are critical. In particular, it is
important to know whether the Naming Authority Registry is to be
administered by IAFA, by some other mechanism, and how it will deal
with name request conflicts, trademark disputes and the like.

I said:

> for the naming authorities that are named by
> their FQDN, it doesn't deal with the case of FQDNs changing, migrating
> organizations, disappearing.

and Stu replied:

> This is true.  People who want persistent names will have a Registered
> Naming Authority assign a URN, and this will be the primary mode of URN
> assignment and maintenance.

> There is a good deal of confusion (we believe) about this point.  We
> are not proposing that unregistered naming will be a dominant component
> of a URN scheme, but we assert that it is nonetheless an important
> capability, allowing as it does, the use of a standard syntax in
> informal or experimental ways that obviates the cost or administrative
> burden of the formal registration.  If the FQDN goes away, or the 
> administrative unit goes away, then so be it... the stuff is gone.  That's
> the price of informality.  The URN requirement for  persistence is met in 
> the use of a registered service... that does not mean that an unregistered 
> service should be prohibited.

I understand this but am uncomfortable with it, since it seems like it
makes the registration of Naming Authorities even more critical.

I said:

> The memo doesn't deal with the administrative or access control issues
> having to do with document migration.

and Stu replied:

> True enough.  No one else does either, as nearly as I can tell.  I
> believe the answer to this lies in the formalization of what the CNRI
> folks refer to as their Repository Access Protocol (RAP)... think of it
> as SCCS for documents.  Every change in document content or location
> for an object in such a repository will trigger a corresponding change
> in the URC associated with that object.  The RAP will include
> management of permissions and such.

> Clearly, the details of such a protocol are not yet worked out, but it
> seems clear to me that the model is reasonable.  Should implementation
> of the URN be held in abeyance until all such details are resolved?  If
> there is doubt about the possibility of such a scheme working, then
> perhaps yes.  If it seems clear that a workable system can be
> implemented , then I think we can proceed cautiously (I point to the
> existence of existing naming authority resolution systems [library
> catalogs] as evidence).

I'm not asking that all of the details of authoritization for changing
the name authority be worked out, but there have to be credible
scenarios for naming authorities splitting, migration of named
documents from one authority to another either singly or en masse, and
either with or without the cooperation or at least lack of protest
from the original source.

Received on Saturday, 8 July 1995 05:05:05 UTC