Re: URI-protocol mapping (was Re: How to add new "protocols" ?)

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
Thu, 20 Feb 1997 11:22:40 -0600 (CST)


From: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
Date: Thu, 20 Feb 1997 11:22:40 -0600 (CST)
Message-Id: <199702201722.LAA01130@void.ncsa.uiuc.edu>
To: touch@isi.edu
Cc: uri@bunyip.com
Subject: Re: URI-protocol mapping (was Re: How to add new "protocols" ?)
In-Reply-To: <199702201654.AA04237@ash.isi.edu>

touch@isi.edu writes:
 > > From: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
 > > 
 > > ... The point is that there is a choice
 > > that *can* be made in how to resolve any URI (not just http URLs).
 > 
 > Then it is no longer a URL, it is a URN (or perhaps URI, depending
 > on how each is defined).

You can say it that way, but I was including http URLs, so you could
equivalently say that URLs and URNs are indistinguishable from this
perspective.

 > However, it adding that 2-level binding to URLs removes any notion
 > of the base, static case which has proven so useful in bootstrapping
 > the Web protocols.

It doesn't.  In a chain of URI redirections, the last URI should be
used as the base if the document itself (or its container) does not
specify the base.  This is a clarification of the relative URL spec.
Roy concurs.

 > > To be blunt, the strong binding of "http" URLs to the HTTP protocol
 > > is an illusion.  It is merely an association.  It can only be that.
 > > What makes it *appear* to be a strong binding is that for the most
 > > part HTTP over TCP is, in fact, used. 
 > 
 > The spec is not an illusion on this point. It is very clear on
 > how http: URLs are interpreted.

Specs can be in error by missing current practice, or as current
practice changes.  Web clients do, in fact, now use some of the
discovery mechanisms I listed.  There is nothing stopping them from
using more.

*If* a client finally gets to the point of talking to the named HTTP
server to resolve an http URL, then, of course, it should use HTTP
according to the HTTP spec, otherwise the server might not understand
it.  Part of that protocol could change the protocol used, but that is
secondary to my point.

 > > Here is a more generalized list of possible ways to discover the
 > > semantics of a URI, starting local to the client and moving out
 > > to remote services.
 > 
 > See - you're using URI here. That's fine. It's not a URL.

URI includes URL.  The possible ways I listed to discover the
semantics of a URI could apply equally to URLs and URNs, unless you
want to restrict them.  But there is no need to restrict them.

dan