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

Keith said:
> While we clearly need to be able to grandfather other naming systems
> into URNs, this does not imply that we need an explicit field for a
> naming "scheme" within URNs.  Schemes in URNs may even be undesirable.
> In particular:
> 
> 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.

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

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.

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

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.

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.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Saturday, 25 November 1995 05:58:55 UTC