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

[[e-mail]]

> From: Daniel LaLiberte <[e-mail]>
> 
> Simon (and others) made a point that was almost lost in the divergence
> into efficiency considerations.  The point is that there is a choice
> that *can* be made in how to resolve any URI (not just http URLs).
> Each client can make this choice and local or remote servers can help
> it make that choice.  The choice might be made on the basis of
> efficiency, security, reliability, or any number of other factors.

Then it is no longer a URL, it is a URN (or perhaps URI, depending
on how each is defined).

And all the "discovery" procedures you outlined come into play.

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.

I am in favor of URN-servers indicating the protocol of choice, but
this can be done when the URN returns a URL that has the
appropriate protocol prefix, i.e. http: or http-tp4:.

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

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


Joe
----------------------------------------------------------------------
Joe Touch - [e-mail]		    http://www.isi.edu/~touch/
ISI / Project Leader, ATOMIC-2, LSAM       http://www.isi.edu/atomic2/
USC / Research Assistant Prof.                http://www.isi.edu/lsam/