Re: #307 (untangle Cache-Control ABNF)

On 2012-06-19 03:41, Mark Nottingham wrote:
>
> On 18/06/2012, at 2:20 AM, Julian Reschke wrote:
>
>> On 2012-06-15 01:40, Mark Nottingham wrote:
>>> ...
>>> I *think* the only point of disagreement here is whether this (i.e., how to parse "non-core" cc directives) is advisory ("ought to...") or a conformance requirement ("MUST...").
>>>
>>> I can't find anywhere else in our specs where we place conformance requirements on being able to parse multiple paths in the ABNF. Can you?
>>> ...
>>
>> (I'm not totally sure what you mean by "multiple paths" here, but I'll assume we're still talking about the quoted-string/token choice).
>>
>> I would argue it's implicit in how the ABNF defined.
>>
>> When the ABNF indicates that an extension parameter or directive uses
>>
>>   quoted-string / token
>>
>> then, yes, this means recipients MUST support both.
>
> Julian -
>
> I'm not disputing that. What I've been trying to ask, in so many ways, is why THIS case differs from all of the other cases.
>
> I.e., AFAICT, we rely on the ABNF in every similar case, without making an explicit requirement with RFC2119 language. Why is it necessary to have the ABNF *and* an explicit requirement here?

The difference is that Cache-Control *does* have special cases for 
historical reasons, whereas I think that is not the case for other headers.

Best regards, Julian

Received on Tuesday, 19 June 2012 06:12:04 UTC