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

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 UTC