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

#367: ABNF requirements for recipients [was: #307 untangle Cache-Control ABNF]

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 19 Jun 2012 17:40:42 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <A55793B2-973E-47F7-BC49-9BF20CBA2CB8@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>
I think the underlying issue here is that we don't explicitly require recipients to be able to parse ABNF-conformant messages, even though we require senders to generate them.

I've created <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/361> to track. One we figure that out, these details of #307 should become clear.

Cheers,


On 19/06/2012, at 4:11 PM, Julian Reschke wrote:

> 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
> 

--
Mark Nottingham   http://www.mnot.net/
Received on Tuesday, 19 June 2012 07:41:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 June 2012 07:41:26 GMT