Re: #307 (untangle Cache-Control ABNF)

On 2012-06-13 12:32, Mark Nottingham wrote:
>
> On 13/06/2012, at 5:18 PM, Julian Reschke wrote:
>
>> On 2012-06-13 05:17, Mark Nottingham wrote:
>>>
>>> On 13/06/2012, at 6:57 AM, Julian Reschke wrote:
>>>>
>>>> --- NEW ---
>>>>    Cache directives are identified by a token, to be compared case-
>>>>    insensitively, and have an optional argument, that can use both token
>>>>    and quoted-string syntax.  For the directives defined below,
>>>>    recipients ought to accept both forms, even if one is documented to
>>>>    be preferred.  For any other directive, recipients MUST accept both
>>>>    forms.
>>>>
>>>>      Cache-Control   = 1#cache-directive
>>>>
>>>>      cache-directive = token [ "=" ( token / quoted-string ) ]
>>>>
>>>>    For the cache directives defined below, no argument is defined (nor
>>>>    allowed) otherwise stated otherwise.
>>>> --- NEW ---
>>>
>>> A few things:
>>>
>>> * You need to qualify the requirement so that it applies only to directives that take an argument
>>
>> Yes:
>>
>>    Cache directives are identified by a token, to be compared case-
>>    insensitively, and have an optional argument, that can use both token
>>    and quoted-string syntax.  For the directives defined below that
>>    define arguments, recipients ought to accept both forms, even if one
>>    is documented to be preferred.  For any other directive, recipients
>>    MUST accept both forms.
>
> You've managed to qualify it for those defined below, but not for "any other directive."

Indeed... How about:

    Cache directives are identified by a token, to be compared case-
    insensitively, and have an optional argument, that can use both token
    and quoted-string syntax.  For the directives defined below that
    define arguments, recipients ought to accept both forms, even if one
    is documented to be preferred.  For any directive not defined by this
    specification, recipients MUST accept both forms.

? 
(<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/307/307.4.diff>)

>>> * The MUST still seems fairly strong; I'd be more comfortable with a SHOULD
>>
>> The MUST is essential otherwise you can't deploy extension directives in a reliable way. What would be a reason not to do this? (recall the ABNF requires it, and always has)
>
> How so? If I define foo to have an unquoted numeric argument, what breaks? A generic parser can parse quoted and token, but that doesn't mean that all new directives need to allow both forms.

It means that you add new special cases to something that is already 
unnecessarily complex. Why would you want to do that?

>>> * Isn't the requirement more appropriate in 3.2.3 Cache Control Extensions?
>>
>> The requirement is about how to parse the header field; it's not specific to extensions. Even if you do not understand a single extension (and do not plan to), you still have to skip over them properly while parsing.
>
> I see. I understand what you're trying to do, but I think it's too easy to misread it as "all new directives must be defined to allow both forms", which is both unnecessary and not realistic. Some rewording might help, but I question whether it's really necessary to put requirements around this; as you say, reading the BNF should make it clear what a generic parser needs to do.

No, that's actually the *intent*. I believe it's both necessary *and* 
realistic.

Best regards, Julian

Received on Wednesday, 13 June 2012 10:56:15 UTC