Re: report: URN Architecture Meeting at University of Tennessee, Oct 30-31

Keith Moore (moore@cs.utk.edu)
Sat, 25 Nov 1995 13:58:01 -0500


Message-Id: <199511251858.NAA09348@wilma.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: "Roy T. Fielding" <fielding@avron.ics.uci.edu>
Cc: Keith Moore <moore@cs.utk.edu>, urn@mordred.gatech.edu, uri@bunyip.com
Subject: Re: report: URN Architecture Meeting at University of Tennessee, Oct 30-31 
In-Reply-To: Your message of "Sat, 25 Nov 1995 02:56:37 PST."
             <9511250256.aa07767@paris.ics.uci.edu> 
Date: Sat, 25 Nov 1995 13:58:01 -0500

I don't know how I can make this any clearer:

1. I (and others who were at Knoxville) have said, repeatedly, that
the client chooses how to resolve a URN.  (One of our oft-stated
design principles was "a client can and will do whatever it wants to".)

2. I have also said, repeatedly, that the URN syntax that we defined
is NOT tied to DNS, that other registries besides the DNS registry
are expected.  It is essential that the syntax does not imply DNS -- 
if for no other reason than to allow transitions to other registries 
in the long term.

3. URN: in the Knoxville proposal is NOT a "scheme".  URN: is a prefix 
that allows clients to identify URNs in text and to distinguish URNs 
from other kinds of URIs.  The Knoxville proposal doesn't have "schemes",
because -- to the extent a "scheme" dictates a resolution protocol --
the inclusion of a "scheme" impairs the longevity of the URN.


> > We certainly do not want to bind a resolution protocol with a naming
> > scheme, because in the long term, some of those protocols will fall
> > into disuse.  This is true even if the resolution protocol is only
> > strongly associated with a "scheme": If it turns out that clients
> > assume a particular resolution protocol when resolving URNs that use a
> > particular scheme, those clients will not be able to access those URNs
> > if the resolution methods change.
> 
> That is true of any URI.  If the client is designed correctly, the
> resolution protocol is defined at run-time as a binding from scheme
> name to some resolution protocol (it doesn't matter what resolution
> protocol, so long as it is one that the client has implemented).
> The argument that this makes the identifier dependent on the resolution
> scheme is just plain false, as proven by any HTTP proxy.

It's false only if everyone runs a proxy.  For everyone who doesn't run
a proxy (which as far as I can tell, includes most people who run native 
IP), a URL is tied to its protocol.  

Do you assume that everyone *should* run a proxy?  I don't.  I'd
far rather see the rules for how you look up a URN advertised by the 
owner of the resource, and optionally overriden by a client, than 
for reliable URN resolution to *depend* on people keeping their 
clients/proxys configured.  

(In email, routing using the DNS works quite well.  By contrast, 
special-case routing by an individual site's MTA appears to be the 
biggest reason for illigitimate delivery failures.)


> > (Essentially, exposing the "scheme" in the name may degrade long-term
> > persistence of the name in much the same way as using an ordinary
> > Internet domain name or a filename as part of a name degrades
> > long-term persistence -- if doing so encourages clients to make
> > assumptions about the name that are not likely to be valid in the long
> > term.)
> 
> If a client cannot make any assumptions about the name, then the scheme
> isn't valid in the short term, long term, or any term.  

I did not say the client could not make any assumptions about the name.

I said the client should not be encouraged to make any assumptions about 
how to resolve the name based on the "scheme".  Stated another way,
we should not design things so that clients (or proxies) will need to 
configure URN lookup on a per-scheme basis.


> If the client cannot
> decide for itself how to resolve a particular name, then the system is
> incapable of the growth and robustness necessary for global information
> systems.  The reason for both is because only the client is capable of
> knowing what resolution services are available to the user, the priority
> and desirability of those services, and the available backup services
> for any particular identifier scheme.

We agree, except that you're assuming the existance of a "scheme".


> All you have done is define a single scheme-uber-alles called "URN".
> That is not desirable, reduces flexibility and robustness, and standardizes
> mechanisms that have no implementation experience on a global scale.

URN: is not a scheme.  And you have failed to justify your other attacks.
In particular, you have not explained why any of the following is 
undesirable, inflexible, or non-robust:

  + a common prefix and NA space for all URNs
  + using domain names for that NA space (as long as it's possible
    to define new domain names that have better longevity properties 
    than existing domain names)
  + resolution services for URNs are advertised in one or more
    global registries. clients need not be configured to resolve
    URNs on a per-scheme basis; they can simply consult one or more
    of the registries to see which services/protocols are available. 
    (clients can special-case lookups for part of the name space
    if they want to; but the ability to resolve a URN doesn't depend
    on them doing so.)  
  + building one of those registries using DNS, so we can get quick
    deployment, and so that anyone on the Internet can use it.

(migration, btw, is handled for "chunks" of URN space by re-delegating 
the resolution for a chunk to some other resolution server(s), and 
for individual URNs by having the primary resolution service (the 
one listed in the registry) return a redirect to the real resolution 
server.)


> > We therefore need to put the binding between a URN and its resolution
> > protocol somewhere besides the URN -- in a network-accessible registry
> > that can accept *any* URN and return a list of services, service
> > locations, etc., that are valid for that URN.
> 
> If the client needs to examine a network accessible registry in order
> to resolve a name, then the URN you propose is not desirable.  The client
> must be capable of defining, without reference to *any* network, how
> the identifiers are to be resolved, and be able to resolve them even
> when they are not connected to the network.  This is trivial to do with
> the existing URI syntax -- your proposal would break it.

Nothing about our proposal requires the client to use the URN registries.
But if we were to design a scheme such that a client NEEDS "to define, 
without reference to any network, how identifiers are to be resolved", 
THAT would be undesirable.

As for being able to "resolve" a URN without being connected to the network...
I don't know what this means.  Either the client has access to the external 
services it needs to make use of a URN, or it doesn't.  If the client doesn't
have access to those services, the URN isn't very useful to the client
except for comparison with other URNs.


> It sounds to me like you have a great proposed system for URI resolution.
> However, if that system is dependent on ANY syntax other than "scheme:stuff",
> then it is not a universal (or even uniform) resolution service and is
> only applicable to URNs of a particular scheme name, which we might
> as well call
> 
>       dns:...
> 
> because any other name doesn't make it any less dependent on DNS.
> I am not opposed to defining a new scheme which is "better than any other".
> I am adamantly opposed to removing the choice of what "better" means from
> the client and handing it over to an IETF WG.

This is silly.  How could we possibly dictate the client's behavior?
How have we impaired the client by providing a network-accessible 
registry that provide the client one means by which to learn which 
resolution services it can choose from?  


> Using the scheme "URN:" would doom all other names to the same resolution
> strategy, which just isn't sufficient for my needs and certainly isn't
> sufficient for the World-Wide Web.

Nothing in the Knoxville proposal dictates what resolution strategy to use.


Keith