RE: [i81] Content Negotiation for media types

Clearly "deprecate" was hyperbole. (I can say that since I raised the issue
in the first place.) However, Accept headers have a limited domain of
applicability, e.g., when the client has a limited repertoire of types that
it is actually willing to accept, and this is generally not true on 
typical desktop web browsers (maybe some phones might have such a limitation).

The point about changing the 406 requirement so that it matches reality
should also be added to the issue.





-----Original Message-----
From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org] On Behalf Of Javier Godoy
Sent: Saturday, November 03, 2007 1:48 PM
To: ietf-http-wg@w3.org
Subject: [i81] Content Negotiation for media types


Though I do not have enough authority as for involving in this issue (after
several gurus have supported the opossite resolution to this issue), I would
like to share my point of view about it.

I agree that listing all supported MIME types in each request makes no sense
now-a-days, at least for fully-featured web-browsers (where the 'active
content' approach fits better, or where there is a user interface and the
preferred variant may be choosed before the request is submitted).  From the
server side, I recall that some programming API (such as Java Servlets 2.5)
do not provide an easy handling of the Accept-* header (they left up to the
programmer the parsing of alternatively accepted tokens and sorting them
according to the related q values), thus encouraging Accept to be ignored.

However, I think that an Accept header may still be useful in other contexts
such as web services, where no active-content may be deployed and where the
client is also a process running without human supervision. For instance,
suppose there is a web-service that provides information as XML
(application/xml) conforming an implementation-specific schema, then the
service is enhanced for providing the same information as RDF
(application/rdf+xml), while keeping the XML variant for compatibility
issues. Of course, these services may negotiate the content in a
non-standard way, but I think it is better to keep this feature standardized
(just for using it when it is meaningful).

Therefore, instead of deprecating Accept (which is a too drastic decision),
it might be regarded as OPTIONAL (on the server-side) because "one vendor
may choose to include the item because a particular marketplace requires it
or because the vendor feels that it enhances the product while another
vendor may omit the same item." (RFC 2119). This rewording conforms the
currenct implementation practice, and I think it is enough for "make it
clear to people reading the spec that it doesn't really work that way in
practice".

Furthermore, if the Accept header is not removed from the revised HTTP
specification, the requierment level of a 406 response when the "Accept"
header can not be satisfied (currently it is a "SHOULD" as per section 14.1)
must be replaced by "MAY" since clients are prepared for receiving content
whose type was not included in the Accept header, and if the server does not
support negotiation based on content-type, they usually ignore the Accept
header (i.e they behave as if Accept: */* were specified, instead of
replying with a 406 status code). In this situation, the "valid reasons in
particular circumstances" (RFC 2119) are too common, then it fits better as
a "vendor decision".

Regards

Javier Godoy

Received on Sunday, 4 November 2007 06:31:09 UTC