Re: Belated comments on OCLC's proposal

> My objection is that this scheme requires a choice between persistence and
> name space, i.e. if objects I produce are to have persistence then I need
> to register in the FLAT name-space. A hierarchical name-space, as used in
> our scheme (and others) allows us to have both.

Our name space supports both a hierarchical name space (DNS with FQDN or IP)
and a "flat" registered name space.  The primary focuses of the I-D are
services, unregistered name authorities and RPs not the 'flatness' of 
the name authority space.

The I-D is being changed to include a hierarchy delimiter in the name
authority ID.  It will be possible to extend the name space hierarchically
if necessary.


> >  > 3.1 "can be resolved by *a* name authority ID resolver"
> >  > If this is really "a" resolver, then how does the client determine which
> >  > one to use, if it should be worded "any" then we have to have a fully (not
> >  > partially) replicated Naming Authority Service.
> >
> >We are in agreement with the Handle folks that there needs to be a global
> >naming authority registry, so that a client can find out that:
> >
> >  N2L://OCLC/12345
> >
> >can be resolved by a machine named, say, urn.oclc.org:nnnn
> >
> >Again, we expect there to be many fewer NAs than DNS hosts, so such
> >mappings will be widely cached, and the global resolution service will
> >be invoked primarily to refresh caches.
> 
> This all depends on your assumptions about the size of the NA space. Please
> correct the document to make it clear that you are dependant on a single
> replicated Naming Authority Service. I believe this is enough to make this
> proposal unscalable.

Note that the NAs in our proposal are of two types: registered NAs and 
unregistered NAs.  The registered NAs are dependent on a single, 
replicated, cachable Naming Authority Registry.  This is the top level 
of the tree.  We are not depending on a single replicated Name Resolver.
The unregistered NAs are dependent on DNS.


> >  > 5.0 Resolution Paths
>
> >The general question we feel is addressed by optional RPs is as follows:
> >
> >  Is is ever desirable to have a URN resolve to different objects of the
> >  same type by a given service (different URLs, for example, or different
> >  versions of a URC)?   If the answer is yes, then it is useful to be able
> >to
> >  specify an optional resolution path, in order to specify a resolver that
> >  is:
> >     - closer
> >     - faster
> >     - cheaper
> >     - under local administrative, political, or budgetary control
> 
> This is what caching is all about, and removes the need for RP's.

It seems hard to believe that caching alone can determine which of two places 
can provide a copy of the same information "cheaper".


> > eg. 1 You need to show, in a document, that different places resolve
> >       the same URN differently (a very plausible event in, for example,
> >       a CERT advisory).  This can only be done by specifying
> >       different resolution paths for identical URNs.
> 
> A CERT advisory such as this is a textual document describing a breakdown in
> a system, since (under normal usage) URN's should be resolved the same way
> no matter where you start the process, then showing a URN resolving
> differently is purely an artifact of how you right your document. E.g.
> "CERT Advisory - the URN resolution cache at xyz.com is misresolving URNs
> to point to trojan.horses.com instead of their real home". I can't think of
> a real example where this is required.

We disagree that a URN should be resolved to the same instantiation
of an object or its metadata.  Different companies and organizations can 
and will resolve the same URN to differing instantiations.  This may
be a result of political, institutional, etc. requirements to deliver
a particular type (or screen other types) of information.
The URN system must, by design, facilitate this ability.  If
it does not then this ability will be achieved outside of the URN scheme.
 
If I am a user with a URN of LOC/1234 and OCLC charges $1.00 to resolve it to 
some URC, I want the ability to go to GNU and get a, perhaps less complete, 
URC for free.

Similarly, the URN NYSE/IBM can be resolved by various resolution servers.
Do you disagree that different companies can resolve this differently or
that one company may charge for a stock quote while another doesn't?

> But in this example, you are modifying a service not a URN. In this case
> you have specified a service and expected the client to know what protocols
> to use to talk to it. If I see the above identifier, I'm not going to know
> what protocol to talk to this service. If it is a new HTTP service which
> turns URN's into citations it would be better expressed as a URL for the
> search service, where the URN was a paramater of the search.

We are modifying what the URN should be resolved to (the info we are 
requesting) not the protocol that the information will be returned in.
We would still be using the same protocol.  There are many reasons why 
turning it into a URL is a bad idea.  The most obvious is that we then
impede persistence.


>  > 6.0 Fulfillment of Requirements

> >Persistence is promoted by the use of Registered URNs.  The usefulness of
> >having an informal path using the same syntax in no way impedes
> >persistence, and in fact, may result in a URN space marginally less
> >cluttered with ephemera that do not need persistent naming.
> 
> Of course it impedes it, these unregistered URNs are not persistent, and
> without having them name a substantial portion of documents the URN service
> won't scale. Its almost the same as saying we have a URN service which will
> only work if its only used for a small fraction of the total documents
> created.

Scalability aside (since it is discussed elsewhere) it does not impede 
persistence.  If one wants a persistent URN it is possible to have one.
Persistence is a function of the entire system not just the name scheme.


> >  > Scalability: NO - see comment on 1.0 IV
> >
> >There will be many fewer NAs than domain names... probably by several
> >orders of magnitude.  The Name Authority Registry can be widely cached,
> >providing fast, local lookup for resolution services.  We adopt Paul's
> >suggestion of a reserved character (#) to provide for expansion of the
> >hierarchy in the future if necessary.
> 
> I just don't believe this premise, every student at some time produces a
> document that is worthy of a persistant pointer.

Every student will not become a naming authority.  If it was the case that
every student that produced a paper had to become a registered naming 
authority and incur the cost of indefinitely provide resolution services 
of various types, the system would not be maintainable and would not be used.

What will realistically happen is that when a student produces a paper that 
is worthy of a persistent name, the name will be assigned by either the 
university, or department, of the particular student.  A publication that
is considered worthy of persistence (one that has been peer-reviewed, 
re-written, re-submitted, etc.) would probably be deposited in 
a publishers repository.  


The OCLC URI team

Keith Shafer  shafer@oclc.org
Eric Miller   emiller@oclc.org
Vince Tkac    tkac@oclc.org
Stu Weibel    weibel@oclc.org

Received on Wednesday, 21 June 1995 08:55:23 UTC