Re: URI-protocol mapping

Daniel LaLiberte (
Sat, 22 Feb 1997 00:10:57 -0600 (CST)

From: Daniel LaLiberte <>
Date: Sat, 22 Feb 1997 00:10:57 -0600 (CST)
Message-Id: <>
To: "Ron Daniel Jr." <>
Subject: Re: URI-protocol mapping
In-Reply-To: <>

Ron Daniel, Jr. writes:
 > The URN stuff has been developed to allow the same identifiers to be
 > resolved using a variety of resolution systems. Further, while we define
 > at least one way to resolve them (NAPTR), we purposfully say that this
 > is not the ONLY way to do it and we purposfully do not say how one
 > discovers all the ways to do it.

I'm all for designing in more flexibility.

 > We do not specify *the* "protocol
 > discovery protocol" you mention above.

But NAPTR *is* a protocol discovery protocol.  That fact seems to be
missed by many people.  But it is not the *only* such protocol that
could be used, you argue, and I agree.  

There are several possible futures:

 0. NAPTR dies because of deployment problems of some kind.

 1. NAPTR flies when the major browsers get hard-wired to use it,
    and simultaneously, content providers risk using the URNs.

 2. NAPTR and one or two other protocols get deployed.

 3. Several protocols get deployed, not necessarily NAPTR.

Future 0 would be sad, unless something better takes its place.

Future 1 will be a struggle to achieve without some luck to get the
deployment formula right.    Deployment is hard!!

Futures 2 and 3 seem relatively unlikely.  Once future 1 is achieved, 
why should we go to the effort of deploying more protocols?

So with only one protocol associated with "URN:" identifiers, it
doesn't matter whether you (and I too!) argue that other protocols
COULD, technically, be used.  NAPTR becomes the defacto standard

The best thing that could happen is for someone to develop a mechanism
whereby it becomes easy and safe to deploy code that uses new
protocols.  This would allow future 3 to come about.  But ironically,
this could also be the death of URNs.  Here is how:

With many protocols associated with URNs, and each protocol associated
with some remote protocol discovery service, not all services will
support the full URN name space (there will be billions of names,
millions of resolvers).  Therefore, URN resolution becomes a guessing
game to find the resolver, which makes resolution less efficient, but
not impossible.  With too many choices, how do you choose?
By market pressures, the choices will tend to be reduced to just a few
that still have competitive advantage, but then some parts of the name
space could be dropped entirely as a result, thus losing the all
important persistence of URNs.

After we reach this point of chaos, to make URNs continue to be
useful, we will need yet another service that maps parts of the URN
space to the appropriate protocol discovery services that know about
those parts.  Note that we have just introduced yet another level of
indirection.  Or we could layer another name space on top of URNs,
just as people think of URNs as a name space layered over URLs.

In other words, one protocol is enough if we do it right.
If we make the one protocol flexibile and extensible, it can live longer.
All protocols eventually die.

 > At 10:16 AM 2/21/97 -0600, Daniel LaLiberte wrote:
 > >Consider all the ways I listed for how URLs can, in fact, be resolved
 > >that make them context dependent and relative.  What is wrong with any
 > >of them?
 > Nothing, unless you want to comply with the existing standards.

Here is an abbreviated version of my list of possible ways to discover the
semantics of a URI.  Only item 4 is possibly non-compliant.  The rest
are actually done and in compliance as far as I know.

1. Look up the URI in an in-memory cache.  

2. Look up the URI in local or remote cache services. 

3. Look up the URI in a local table that maps a prefix of the URI to
   some protocol or process. 

4. If the URI has a DNS component, lookup the domain name for a
   protocol/service mapping.
5. Ask the named service (discovered by any of the above) to resolve the
   URI and learn that some other service or protocol should be used.

6. Get a redirection to another URI or a collection of alternative URIs.

You described another way in which URLs may be considered at least
partly non-location specific, and it is not one I usually think of
because it is relatively weak.  That is, the DNS name in a URL may be
mapped to multiple IP numbers at possibly different locations.
Several aspects of the semantics of a URL could be different depending
on which IP number is actually used.  (Consider sessions for one.)
I'll admit that semantic differences at this level would tend to break
many applications that depend on equivalent semantics.

So, to summarize, I argued that URNs need a protocol too, and will
tend to be bound by practice to one protocol.  I also argued that URLs
are not so tightly bound to the one protocol everyone associates with

Daniel LaLiberte (
National Center for Supercomputing Applications