RE: updated findings on whenToUseGet

Hi Dan,

It seems to me that there are two sets of concerns tangled up in this one
and if possible it would be good to disentangle them:

	a) Visibility of resources (ie. identification by URI alone).
	b) Safe operations and safe methods - [distinction between operation
and method may needs some work.]

I like the up-front listing of important priniciples:

    i) All important resources should be identifiable by URI. 

   ii) Following references in the web is safe; i.e. agents do not incur
obligations by following links 

i) really is crisp and clear, and I think applies as a principle regardless
of whatever operation is being performed on a resource. The subordinate
sentence...

  "In particular using GET for safe operations 
  (read, query, view, ask, lookup, ...) on HTTP 
  resources makes them identifyable by URI, 
  while using POST does not." 

...seems misplaced and suggests to me that there is something else that
needs stating as crisply as i). How about:

    1) All important resources should be identifiable by URI. 

    2) Safe operations (read, query, view, ask, lookup, ...) should use safe

       access methods, eg HTTP GET in the case of the HTTP URI scheme.

    3) Following hypertext references on the Web is (should be?) safe; 
       ie. users (people/organisations/legal entities) do not incur 
       (unexpected?) obligations by following  hypertext links 
       [has this ever been tested in court? - ie. can we really 
        say "...do not incur obligations..."].

1) clearly relates to visibility. 2) Clearly relates to Safe operations and
methods. 3) is also more about safe operation/methods than identity. It may
be overly restricted, but I find the original "Following references in the
web is safe..." a little underspecified. URI references crop up all over the
place in XML content, as attribute values, as element content and what it
means "to follow" a reference will be conditioned by the context in which
the reference arises. It may be that what we want to say is:

	3') Users and user agents dereferencing an URI (reference?) with a 
          safe access methods (eg. HTTP GET) do not incur (unexpected?)
obligations. 
          [again same question about legals standing of such an assertion.]

I think it would also be useful to include some discussion of the pragmatics
of using protocol headers and request bodies to identify resources
(independent of access method) - and how to ameliorate the threat to
visibility either through the use of resource identifying URI references
carried in the body of a response or as header fields in the access
protocol, eg. Content-Locaction: in HTTP.

"There are sometimes pragmatic reasons when is necessary or appropriate to
use information in a request body to partially identify a requested
resource. For example, the requested resource is identifiable by a query
carried in the body of a request with complex structured parameters that are
awkward or inconvenient to serialise into URI (other examples...). In such
circumstances, a bookmarkable URI identity for the requested resource should
be made available, either within the resulting resource representation
itself, and/or by making use of facilities in the access protocol - such as
the HTTP Content-Location header. This will ameliorate the effect of the
referenced resource being identified initially by other means than solely by
URI."

This has again focussed solely on resource identification without regard to
the safety or otherwise of the requested operation.

The application examples at the end are useful in exposing the sort of
issues that can arise if the principles are ignored, but I'm wondering if
they add too much to the length of the finding and risk obscuring the
opinion/finding/judgement that is being articulated. I think the ideal would
be the crisp (1 or 2 sentence) statements of principle followed by some
brief do's and don't focussed on resource identification and the
relationship between safe 'operations' and safe 'methods'.

             |operation
             |
      method |safe             | unsafe
      -------+-----------------+-------------
        safe | Ideal           | 'Forbidden'
      -------+-----------------+-------------
      unsafe | Permissable     | Ideal
             | for pragmatic   |
             | reasons.        |

The application examples might be moved to a 'tutorial' annex to the
finding, so that the core of the finding remains compact.

Just my 2 cents.

Regards

Stuart

> -----Original Message-----
> From: Dan Connolly [mailto:connolly@w3.org]
> Sent: 17 May 2002 21:16
> To: www-tag@w3.org
> Subject: updated findings on whenToUseGet
> 
> 
> I updated the finding w.r.t. 5May discussion.
> 
> Chris, I still need some text from you about
> the I18N situation.
> 
>   http://www.w3.org/2001/tag/doc/get7
>   v1.12
> 
> --- ,get11.txt	Fri May 17 15:14:44 2002
> +++ ,get7.txt	Fri May 17 15:14:53 2002
> @@ -5,13 +5,21 @@
>  ref. issue whenToUseGet-7
>  
> 
> -DRAFT by Dan Connolly, for the TAG
> -$Revision: 1.11 $ of $Date: 2002/05/01 21:30:59 $ by 
> $Author: connolly $
> +DRAFT by Dan Connolly, for the TAG. in progress: update 
> w.r.t. 5May discussion
> +
> +
> +$Revision: 1.12 $ of $Date: 2002/05/17 20:06:35 $ by 
> $Author: connolly $
>  
> 
>  Two principles are central to the design of Web sites and 
> applications:
>  
>    * All important resources should be identifiable by URI.
> +   
> +    In particular
> +   
> +      + using GET for safe operations (read, query, view, 
> ask, lookup, ...) on
> +        HTTP resources makes them identifyable by URI, while 
> using POST does
> +        not
>    * Following references in the web is safe; i.e. agents do not incur
>      obligations by following links
>  
> @@ -96,7 +104,7 @@
>  links; only that the obligations must be accepted some other way than
>  requesting to follow a link.
>  
> -For confidential materials, a straightforward design is:
> +Obligations of confidentiality can be established 
> straightfowardly as follows:
>  
>   1. The client requests access to the materials
>   2. The server declines, with an "authorization required" 
> notice, and a link to
> @@ -132,7 +140,21 @@
>  for subsequent access to the same information, e.g., using 
> Content-Location, is
>  useful.
>  
> -Myths and transitional limitations
> +The case of large parameters to a safe operation is not 
> directly addressed by
> +HTTP as it is presently deployed. A QUERY or "safe POST" or 
> "GET with BODY"
> +method has been discussed (e.g. Dec 1996 IETF meeting) but 
> no consensus has
> +emerged.
> +
> +WebDAV (RFC 2518) uses a different HTTP method, PROPFIND 
> (section 8.1 PROPFIND
> +), for querying properties of resources; unfortunately, this 
> provides no URI
> +for the results of these queries..
> +
> +Myths, Bugs, and Ephemeral Limitations
> +
> +While Web application design must take into account the 
> limitations of
> +technology that is widely deployed at present, it should not 
> treat these as
> +architectural invariants. Some limitations are likely to 
> fade away as bugs are
> +fixed and the scope of interoperable specifications expands.
>  
>  Myth: search services won't index anything with a ? in the URI anyway
>      This was a heuristic to avoid infinite loops in some 
> search service
> @@ -144,8 +166,11 @@
>      generally at least 4000 characters, and they evolve as 
> the legitimate uses
>      of application developers evolve.
>  
> -Designers of HTML forms that accept non-western characters 
> have been challenged
> -by various implementation limitations and gaps in 
> specifications. For example:
> +Work to do
> +
> +[@@Chris, help here!] Designers of HTML forms that accept non-western
> +characters have been challenged by various implementation 
> limitations and gaps
> +in specifications. For example:
>  
>      The content type "application/x-www-form-urlencoded" is 
> inefficient for
>      sending large quantities of binary data or text 
> containing non-ASCII
> @@ -154,6 +179,26 @@
>  
>  We expect these limitations to be address in future 
> specifications (@@e.g.
>  XForms?) and deployed in due course.
> +
> +The use of HTTP for typical safe remote operations is not 
> addressed by SOAP
> +specifications as of this writing:
> +
> +    HTTP Method: POST (the use of other HTTP methods is 
> currently undefined in
> +    this binding).
> +   
> +    section 8.4.1.1.1 Requesting State of SOAP Version 1.2 
> Part 2: Adjuncts,
> +    W3C Working Draft 17 December 2001
> +   
> +Intitial investigations into requirements and a proposed 
> solution (SOAP HTTP
> +GET Binding Version 0.1, Orchard, May 2002) suggest this 
> limitation is
> +straightfoward to address; meanwhile, "the oft-quote stock 
> quote example" (
> +Overview section) is misleading, since it suggest that HTTP 
> POST is appropriate
> +for this safe operation.
> +
> +WSDL 1.1 provides a binding to HTTP GET, which makes it 
> possible to respect the
> +principle of using GET for safe operations, but to more 
> straightforwardly
> +represent safety, it should be a property of operations 
> themselves, not just a
> +feature of bindings.
>  
>  Acknowledgements
>  
> -- 
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> 
>

Received on Monday, 20 May 2002 06:50:41 UTC