Re: #307 (untangle Cache-Control ABNF)

On 2012-06-14 12:54, Mark Nottingham wrote:
> ...
>>> 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.
>>> """
>>
>> I believe that all new directives should not only be parseable with a generic parser, but also that senders can *rely* on them being parsed that way; see James' explanation.
>
> And that's fine; I'm just wondering why we're encouraging this with a MUST, where we haven't done so anywhere else, AFAICT.

I agree that we should be consistent about this in the spec 
independently of the header field. *Are* we currently inconistent?

> ...
>>> Likewise for auth schemes: <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p7-auth.html#considerations.for.new.authentication.schemes>
>>
>> That is incorrect. We've had these requirements all the time based on the ABNF.
>
> Yes, but we haven't surfaced them as conformance requirements for auth schemes like we are here. Why is this different?
> ...

I don't think it's different.

The header field definition needs to define how to parse the header 
field, including future extensions. Extensions can constrain 
parameter/argument values *after* parsing (like: *DIGIT), but shouldn't 
constrain the base syntax (for the reasons we have discussed many many 
times).

The reason why we're discussing this here is that we need to 
special-case the existing cache control directives for now, thus we also 
have text that tries to clarify that the situation is different for any 
other directive. Maybe that's where the disconnect comes from?

>>> 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?
>>
>> It says:
>>
>>> The type/subtype MAY be followed by parameters in the form of attribute/value pairs.
>>>
>>>   parameter      = attribute "=" value
>>>   attribute      = token
>>>   value          = word
>>>
>>> The type, subtype, and parameter attribute names are case-insensitive. Parameter values might or might not be case-sensitive, depending on the semantics of the parameter name. The presence or absence of a parameter might be significant to the processing of a media-type, depending on its definition within the media type registry.
>>>
>>> A parameter value that matches the token production can be transmitted as either a token or within a quoted-string. The quoted and unquoted values are equivalent.
>>
>> So I don't see any language here that would allow a parameter to restrict the serialization within the header field.
>
>
> I think what I'm most concerned about here is that (in all of these cases, not just CC directives), we're requiring people to read between the lines. If we want to assure interoperability, we need to spell it out, e.g.,:

+1

> """
> Receivers of Cache-Control directives ought to be able to parse all three forms of directive (without a value, with a token value, and with a quoted-string value) for all directives.
> """

I'd prefer this to be a MUST for any directive not defined in HTTPbis.

> And, separately in the cache control extensions section:

A few minutes earlier, I opened the new ticket #360 for this...

> """
> New cache control extension directives are encouraged to:
>     - Define whether or not they allow or require a parameter
>     - If they do accept a parameter, allow it to occur in either token or quoted-string form (restricting to one form requires sending libraries to special-case the directive)
>     - If they do accept a parameter, define how a directive without one should be interpreted
>     - If they do not accept a parameter, define how a parameter with one should be interpreted
>     - If they do accept a parameter, define how multiple occurrences should be handled
> """

Indeed. Or alternatively, we could add additional constraints, see 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2012AprJun/0668.html>.

Best regards, Julian

Received on Thursday, 14 June 2012 11:56:03 UTC