Re: #307 (untangle Cache-Control ABNF)

On 13/06/2012, at 8:55 PM, Julian Reschke wrote:
>>> 
>>>   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>)

Still managing to avoid it. The last sentence needs to say something like:

"""
For any other directive that accepts an argument, recipients MUST accept both forms.
"""


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

What special cases? 

For example, if I define a new directive that takes an URL as its argument, I might decide to say that it should ONLY use the quoted form, because I know that people will mess it up if they use token. How does that make things more complex? Your generic parser works the same.


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


So, I didn't see what you're trying to do. However, above you say it's not specific to extensions, but as you say later, that's the effect (and intent).

I think it's going too far; in similar situations we haven't laid down such draconian rules.

E.g., we don't place ANY conformance requirements on new headers; it's all advice: <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#considerations.for.creating.header.fields>

Likewise for auth schemes: <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p7-auth.html#considerations.for.new.authentication.schemes>

We don't place any conformance requirements on media type parameters either: <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#media.types>; we only note that they can be transmitted in either form. Why not use similar language here?

What I'd really like, though, is to hear what someone else things, so this isn't just a back-and-forth between Julian and I. Anyone?

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

Received on Thursday, 14 June 2012 03:23:43 UTC