W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2007

Re: [i81] Content Negotiation for media types

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 20 Nov 2007 17:15:53 +1100
Message-Id: <E9819B31-5910-4E27-8AD5-D20F30973778@mnot.net>
Cc: Julian Reschke <julian.reschke@gmx.de>, LMM@acm.org, "'Javier Godoy'" <rjgodoy@hotmail.com>, ietf-http-wg@w3.org
To: Henrik Nordstrom <henrik@henriknordstrom.net>
It's interesting you bring the notion of conditional compliance up,  
since one of the charter goals is to "clarify conformance requirements."

Do people think that having a notion of conditional vs. full  
compliance is useful, as currently used in the spec? I've always been  
a little bit uncomfortable with overloading SHOULD, which RFC2119  
defines as

> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.

Using SHOULD to determine conformance levels takes flexibility away  
in a lot of cases; sometimes a SHOULD should be a SHOULD, without  
giving someone the stigma of "conditional conformance."

Cheers,



On 12/11/2007, at 11:50 PM, Henrik Nordstrom wrote:

> On mån, 2007-11-12 at 17:11 +1100, Mark Nottingham wrote:
>> Yes; I've hit this a few times. I think it revolves around the
>> interpretation of "acceptable". Consider:
>>
>> 1) Accept: text/html
>> 2) Accept: text/html;q=1, */*;q=0.1
>> 3) Accept: text/html;q=1, */*;q=0
>>
>> Many people read the spec as saying that #1 and #3 are equivalent. It
>> sounds like we're saying #1 and #2 are closer to the mark -- i.e.,
>> that the server can choose to send anything back, even if it's not
>> listed, as long as the client didn't explicitly say they didn't want
>> that to happen. This seems to be in the spirit of server-driven
>> negotiation;
>
> A conditionally compliant server/application can choose to ignore  
> Accept
> entirely and send anything back, but not a fully compliant
> implementation.
>
> Obeying to the limits set by the Accept header is a SHOULD level
> requirement in the definition of Accept. The slightly conflicting
> comment in the definition of 406 is just that, a comment. Doesn't say
> anything about compliance level of either implementation or which
> request headers the server may ignore, and I read that more as a
> reminder to client implementers that it's not a MUST level requirement
> for servers to obey to the limits set by Accept or any of the other
> Accept-* headers.
>
> But in practice most servers implementations is partially  
> conditionally
> compliant here, not always looking at the Accept header.
>
>
> The changes I see as appropriate here is to change the 406 comment to
> clarify that it's directed to client implementers and not servers.
> Suggested wording:
>
>       Note: HTTP/1.1 servers are in certain situations allowed to
>       return responses which are not acceptable according to the
>       accept headers sent in the request. Because of this User
>       agents are encouraged to inspect the headers of an incoming
>       response to determine if it is acceptable
>
> Or remove the comment entirely as it's not really about the 406  
> response
> as such..
>
> The paragraph immediately following the comment should also be  
> moved to
> a different place. It's not really about 406 but how clients should
> process responses in general. No suggestion at the moment.
>
> Regards
> Henrik


--
Mark Nottingham     http://www.mnot.net/
Received on Tuesday, 20 November 2007 06:19:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:23 GMT