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

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

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 2 Dec 2005 21:28:42 -0500
To: Larry Masinter <LMM@acm.org>
Cc: www-tag@w3.org
Message-ID: <OF55C14388.F92765C8-ON852570CC.0009FBA6-852570CC.000D9D77@lotus.com>
Larry Masinter writes:

> 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".
>  [...]
> 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.
>  [...]
> But your rule R7 doesn't have any such contextual restriction, 
> and so I think it makes no sense, as is. 

I do understand your concern, but I think my finding offers just the 
necessary context in rule R2 [1], which requires that:

"A server MUST serve resources faithfully. Regardless of the protocol 
used, the server is responsible for ensuring that the correct resource is 
accessed, that operations are correctly implemented according to the 
specifications for the protocol, and thus that the correct resource state 
is either retrieved or updated."

I'm not trying to imply that it's in all cases a good idea for a user 
agent to access resources using a random or otherwise silly protocol, but 
I'm claiming that the architecture in no case prohibits them trying should 
they wish to, and crucially, that the rules provided make it safe to do 
so.  Consider a resource in an arbitrary scheme "x" 
(x://example/org/resource) and attempt to access it with seemingly 
unrelated protocol RANDOM.  R2 requires that one of two things will 

A. If the server reports back success using the mechanisms of protocol 
RANDOM then per R2 you have indeed succeeded in retrieving information 
from or updating the state of that resource.  The server MUST NOT report 
success unless it has accessed the intended resource and succeeded in the 
requested manipulation.


B. The server MUST fail the interaction, in which case no harm is done 
except for some wasted effort.

This doesn't seem Humpty Dumpty to me at all;  it's two complementary 
rules that work together to establish some very useful guarantees.   You 
can try any protocol for any resource, and it worst you will get a 
reliable indication that nothing has been done.  That makes it safe to 
try, which is what rule R7 [2] says:

"A user agent MAY to attempt to access any resource using any protocol. 
Insofar as networks are free from misconfiguration and tampering, any 
response received is by definition authoritative, regardless of whether 
the scheme is one traditionally associated with the protocol."

With those rules in place, the finding then acknowledges that as a 
guideline [3], one should whenever practical deploy with the protocol(s) 
associated with a scheme (HTTP 1.0 and HTTP 1.1 in the case of the http 
protocol, FTP for ftp), as is traditional.  That in turn justifies 
suggesting that the default behavior of user agents indeed be to select a 
protocol based on the scheme, when there is such an association [4].

I won't be surprised if the above line of reasoning doesn't completely 
convince you, as we clearly start this discussion some distance apart.  I 
don't think that what I'm proposing has the Humpty Dumpty weakness you 
ascribe to it.  I think I've suggested rules that are quite strong in 
their guarantees that either the system works or an error is reported.  I 
believe that these capture the general case of what's happening on the Web 
today, but I'll be curious to see what my fellow experts on the TAG think 
when we discuss this at our F2F on Monday.  Obviously there will be lots 
more discussion, with you and others, before anything gets set down in the 
form of a finding.  Thank you as always for taking the trouble to comment.



Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
Received on Saturday, 3 December 2005 02:29:27 UTC

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