Re: Strawman proposal for Representation header

I certainly don't have the HTTP expertise that others here have, but it 
seems there are a number of subtleties that we have to sort out.

First, let me say informally what I think is happening here, and then go 
as far as my limited HTTP and Web architecture insights will allow in 
trying to analyse details.

The big picture:  what we're proposing is a mechanism that's independent 
of any particular URI scheme or retrieval mechanism.  So, there's an 
interesting question of whether web architecture allows this (see below), 
but let's suspend disbelief for a moment and assume for a moment that it 
does.   What are the assumptions of this new mechanism and what 
capabilities does it provide?

Representation header assumptions:  (a) resources are named by 
URIs...seems safe since we're on the web (b) the resources in question 
have representations...also OK, I think--if your resource doesn't have 
representations, then don't use our header (c) the SOAP sender is going to 
determine at least one representation that will be available to any 
receiver of the SOAP message, I.e. because that particular representation 
is being carried with the message and (d) that we are providing a 
mechanism, not necessarily identified with HTTP GET and indeed applicable 
equally to non-HTTP resources that will allow a receiver to get at the 
representation.   I think we are also (f) hinting that such a 
representation could in certain circumstances be used as the content for 
an admittedly limited function RFC 2616 proxy cache.

Some of the discussion on this thread seems to leap rather quickly to 
issues relating to (f), and I'm not 100% convinced that's for the best.  I 
think we need to consider all of (a)-(f) together.

Above I asked whether a caching scheme that's independent of URI scheme is 
OK per web architecture.  Well the latest, not yet normative, web arch 
draft says [1]:

"Although many URI schemes are named after protocols, this does not imply 
that use of such a URI will result in access to the resource via the named 
protocol. Even when an agent uses a URI to retrieve a representation, that 
access might be through gateways, proxies, caches, and name resolution 
services that are independent of the protocol associated with the scheme 
name, and the resolution of some URIs may require the use of more than one 
protocol (e.g., both DNS and HTTP are typically used to access an "http" 
URI's origin server when a representation isn't found in a local cache)."

I read that as pretty clearly licensing a decoupling between URI scheme 
and retrieval mechanism.  My admittedly inexpert reading of the above is 
that we can, for our own limited purposes, propose a representation 
caching scheme that's independent of HTTP and its mechanisms.  If it also 
works well in support of HTTP-specific caching, so much the better.

Thus, I don't see that we necessarily have any responsibility to answer 
questions in the core design about cookies, servers, request/response MEPs 
or any such abstractions that remind of HTTP.  We are merely saying:  this 
message carries a representation that the sender (NOT necessarily some 
HTTP server!) warrrants is a useful representation of the named resource 
>>for purposes of processing this message<<.  If we can go further to 
describe useful special behavior that helps with implementation of HTTP 
GET and HTTP proxy caches in particular, so much the better.   I think 
it's OK if such HTTP support is limited to simple cases, as long as we 
correctly fail when presented with requests we can't handle.  My 
impression is that HTTP always allows you to fail a request.

Noah

[1] http://www.w3.org/2001/tag/2003/webarch-20031111/#dereference-uri

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------