RE: Representation consistency and content negotiation

I think you may have read too much into "scope".

Content negotiation as it was originally conceived -- that a document might reasonably be represented in HTML or PDF or Word, or that an image might be available in JPEG and JPEG2000 and PNG, and that you would use content negotiation to distinguish between them, by listing all desirable formats in "Accept" headers -- that didn't work out very well.  Using content negotiation in conjunction with content attributes, capabilities, characteristics and preferences (such as with CCPP) didn't work out very well either. The current text in the HTTP specification currently makes it sounds like that kind of content negotiation is desirable, widespread, and it's primary function. I believe it is useful to change the HTTP specification to match the reality: in reality, there are limited circumstances where using HTTP content negotiation makes sense.

I don't think or plan to enumerate those circumstances, or restrict HTTP content negotiation to only be "valid" or "allowed" in a limited set of circumstances, but I do think it is useful to attempt to characterize those situations where it is useful. This should in no way discourage anyone from continuing to pursue additional applications!

The guidelines I'm thinking of are ones where 

(a) there are in fact reasonable alternative representations of the same resource which can be described readily by available HTTP request headers (e.g., Accept or Accept-Charset or Accept-Language)
(b) there is an expectation of the overlap of set of content types or characteristics desired and acceptable with the set of content types available (so that the 'default' behavior will interoperate, and content negotiation is only required for improved operability rather than basic interoperability)
...

and give some examples of where HTTP content negotiation based on Accept-* headers has been successful.

Larry

Received on Tuesday, 13 January 2009 23:20:29 UTC