Re: [i81] Content Negotiation for media types

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/