W3C home > Mailing lists > Public > www-tag@w3.org > April 2002

RE: draft findings on Unsafe Methods (whenToUseGet-7)

From: Bullard, Claude L (Len) <clbullar@ingr.com>
Date: Tue, 16 Apr 2002 15:46:42 -0500
Message-ID: <2C61CCE8A870D211A523080009B94E4306FEEB8B@HQ5>
To: "'Paul Prescod'" <paul@prescod.net>
Cc: www-tag@w3.org
Please clarify what information can be hidden behind 
SOAP endpoints that the information owner should expose 
to web interfaces and the tools mentioned and why? 

Since it is unreasonable to assume all digital  
information is required to be web accessible, I  
assume there is a way to define that information is "on the 
web" or that it is "off the web".  Then I would 
have to assume "unsafe methods" can violate that 
boundary or change "on the web" information in 
a way unacceptable to the information owner even 
if discoverable via auditing.  

It seems clear that SOAP/RPC can 
enable information to be "off the Web" but 
"on the Internet" and that this can be "unsafe" 
or only as safe as the interface owner can make it 
and that this contract is individually made.  The 
HTTP contract can be safer, but again, given 
tunneling and use of methods with side effects,  
the contract is still individual.  Further, 
given common practices, that isn't likely to 
change soon if ever.  So the web is possibly unsafe 
until the correspondents agree to safety 
measures and verify these.  This is similar to a 
concept of operations agreement with a 
certification clause that can reference the 
document DC is drafting for HTTP, and would 
require something similar if SOAP/RPC is used.

Use of the tools is a different issue.  Yes, 
they are useful.  No, one can't require their 
use to be "on the web".  One can require safe 
operations insofar as that can be specified and 
verified and this can be done for any architecture 
including one that uses SOAP/RPC.  It is harder 
and yes, at that point, the leverage of the 
REST architecture and the tools come into play.

len


From: Paul Prescod [mailto:paul@prescod.net]

> On the matter of hidden resources I have some sympathies (but not
> solutions). It seems that caching and bookmarking are the things that
> suffer, as noted by others [1]. 

Please consider this issue of "bookmarking" more closely. Bookmarking is
the least of the issues. It is linking *in all of its forms*. I'm
talking about XInclude, XLink, XPath, RSS, XHTML, XSLT, RDF, WebLogs and
Topic Maps. These are *powerful* information combination and relation
tools. But they cannot be used with information hidden behind SOAP
endpoints. I would say that any service that denies its users the use of
these tools is somewhat broken.
Received on Tuesday, 16 April 2002 16:47:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:06 GMT