W3C home > Mailing lists > Public > www-tag@w3.org > June 2005

Re: [schemeProtocols-49] Editor's draft of finding on schemeProtocols-49

From: Mark Baker <distobj@acm.org>
Date: Mon, 13 Jun 2005 15:59:16 -0400
To: noah_mendelsohn@us.ibm.com
Cc: www-tag@w3.org, Larry Masinter <LMM@acm.org>
Message-ID: <20050613195916.GC17315@markbaker.ca>

(uri@w3.org removed - I think they'd appreciate the notice of the draft,
but may not be as interested in the discussion)

A great start, Noah!  Some comments ...

The draft says;
> For schemes such as http and ftp, the association of a URI to a
> resource is defined in terms of the corresponding protocol. Thus, the
> resource identified by http://example.org/resource1 is by definition
> the one for which representations are returned (GET) or updated (PUT)
> when that URI is supplied as the HTTP Request-URI

I disagree.  I believe that the relationship between URIs and the
resources they identify is independent of URI scheme and protocol.  Your
examination into gateways seems to demonstrate this, as, for example, a
resource identified with an ftp URI is able to be interacted with
via an HTTP proxy in a manner indistinguishable from a black box POV,
from an http URI (see below).  Even a protocol as mismatched with HTTP
as TELNET, can be interacted with via the GET semantic, and is
indistinguishable from double-clicking on a hostname in your telnet/SSH
client (at least for the initial interaction that establishes the

I also think HTTP deserves some special attention in this finding due to
it being the only (so far) attempt at reifying, in a concrete protocol,
the aforementioned generic relationship between a URI and a resource.
IMO, that's why we always find it on the first hop of those gateway
examples, never the second.


Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com
Received on Monday, 13 June 2005 19:58:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:09 UTC