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

Re: #307 (untangle Cache-Control ABNF)

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 19 Jun 2012 11:41:54 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <86A2AE19-CA9A-43C6-AC11-89AC5F96D999@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>

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?



--
Mark Nottingham   http://www.mnot.net/
Received on Tuesday, 19 June 2012 01:42:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 June 2012 01:42:49 GMT