Re: #307 (untangle Cache-Control ABNF)

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


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


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


>>> --- NEW ---
>>>   Note: the preferred syntax for this argument is "token".  For
>>>   compatibility with non-robust recipients, arguments SHOULD be sent
>>>   using the token syntax.
>>> --- NEW ---
>> 
>> 
>> Here and elsewhere, the quotes around the token are confusing, and the language is slightly revisionist (max-age, for example, has never been defined to use quotes).
>> 
>> Suggest replacing with:
>> 
>> Note: This cache-control directive uses the token form of the argument; e.g., 'max-age=5', not 'max-age="5". Senders SHOULD NOT use the quoted-string form.
> 
> I made that:
> 
>   Note: This directive uses the token form of the argument syntax;
>   e.g., 'max-age=5', not 'max-age="5"'.  Senders SHOULD NOT use the
>   quoted-string form.
> 
> And for the other (#field-name) case:
> 
>   Note: This directive uses the quoted-string form of the argument
>   syntax.  Senders SHOULD NOT use the token form (even if quoting
>   appears not to be needed for single-entry lists).


Looks good, thanks.


--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 13 June 2012 10:32:37 UTC