Re: #307 (untangle Cache-Control ABNF)

On 14/06/2012, at 9:55 PM, Julian Reschke wrote:

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

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?

Cheers,

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

Received on Thursday, 14 June 2012 23:41:23 UTC