W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: #307 (untangle Cache-Control ABNF)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 19 Jun 2012 08:11:32 +0200
Message-ID: <4FE01814.1050807@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 June 2012 06:12:14 GMT