Re: [schemeProtocols-49] New draft of proposed "URI Schemes and Web Protocols" Finding

On Nov 30, 2005, at 11:05 AM, Larry Masinter wrote:

> Well, let's try to get down to the issue rather than talk about
> the wording.
>
> I disagree, fairly profoundly, with "4.3.1 R7. Try any protocol
> for any resource", as stated. That's a Humpty-Dumpty rule, as if
> you were saying "In English, any word can mean whatever you want
> it to mean".

> I think the meaning of any URI that starts with "http://host/path"  
> must
> be "use the HTTP protocol to connect to 'host' and send it 'path'",
> because that's the definition of the "http" URI scheme.

No, not quite.  The definition is:

   "The semantics are that the identified resource is located at the
    server listening for TCP connections on that port of that host,
    and the Request-URI for the resource is abs_path."

Note carefully how that is phrased.  It has nothing to do with
*how* someone will access that resource.  It is a statement of how
the name is associated with a resource occupying that point in
the namespace.  It has a subtle implication, in that *if* you
do use the HTTP protocol to connect to 'host' and send it 'path',
then the response is authoritative for that resource, but that
is different from saying the "http" means "use HTTP".

A URI is a name.  An "http" URI is a name owned by an authority
that is delegated by means of DNS, IP, TCP:80, and the remaining
string of /path?query information.  The name does not change no
matter how many protocols are used in the process of accessing what
has been named by that authority, and there is absolutely no need
to use HTTP during that process.  The only requirement is that the
interaction be faithful to what has been authorized by that authority,
which is something that could be determined via HTTP, waka, OPES,
or any other mechanism authorized by that authority.  Such mechanisms
could be determined via client configurations, DNS lookups, TCP
interceptors, and any number of other as-yet-invented features.

Therefore, there is no required relationship between scheme names
and the protocols used to access those resources.  Access is a
*different* problem that starts with context, depends on configuration,
and is inherently late-binding in order to provide a greater degree
of evolvability than prior systems.  In that sense, the rest of
Larry's comments are spot-on.

The definitional relationship between scheme names and protocols
only exists within the name allocation process, and even then mostly
by accident.  "ftp" was invented because using "file" for both led
to ambiguity in the authority (i.e., is it defined by FTP/TCP:21 or
AFS/TCP:7000?).  "http" was used instead of "web" because the WWW
was intended to be inclusive of all of the existing IR systems, and
thus some other name had to be chosen.  Once the initial set of
schemes were described using mostly the names of Internet protocols,
many people just started assuming that a scheme implied access protocol.
The Web developers have known all along that access protocols are
selected based on scheme name lookup within a local configuration.

> Let me try to put my point in a different way: computer science
> is filled with "identifiers", and there are many kinds of identifiers
> in programming languages and data structures. Most identifiers are
> contextual -- they're interpreted in a context where the rules
> of the context give the way in which the identifier acquires its
> meaning.
>
> What is unique about the "Uniform Resource Identifier" is that
> it asserts that you can have an identifier which has a meaning
> that can be interpreted uniformly in a way that is independent
> of the context.
>
> By adding some finding that asserts that a URI's meaning is
> actually contextually dependent, that there are undefined
> out-of-band ways of discovering that "http://host/path" really
> means "use a peer-to-peer protocol" -- I think this weakens
> the value of the URI concept. Don't do it.

You are conflating two different things here (though that may be
just because the draft finding does so as well).  The uniform
meaning is obtained by how the name has been allocated, not by
the process used to access such a resource.  Access is not a
uniform process even for a single URI.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

Received on Thursday, 1 December 2005 01:09:47 UTC