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

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. There are
still a world of possibilities about what might happen after you
do that, from a redirect to the retrieval of a value with content-type
which then directs you to do something else. However, the "meaning"
starts with "use the HTTP protocol", and there's no way that 
"http:" can mean anything else (without changing the definition
of the http scheme.)

Of course, someone who has information through some other route might
decide they can do something else (such as 'use a peer-to-peer
protocol') but this out-of-band transfer of information is crucial.

For example, multipart/related (RFC 2387) has this kind of
information that is not "in the URI" but "out of band", because
it tells you that within a particular context, some URIs should
be interpreted differently.

But your rule R7 doesn't have any such contextual restriction, and
so I think it makes no sense, as is. And if you have out-of-band
information about re-interpretation of URIs, then the context of
that out-of-band information should provide for the definition
of the rule, rather than having some disembodied rule (R7) giving
advice that isn't really operational: "http URIs usually mean
that you should use the HTTP protocol, except there may be some
circumstances where you might use some other protocol".

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. 

Larry

Received on Wednesday, 30 November 2005 19:05:04 UTC