- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 19 Jun 2012 11:41:54 +1000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 18/06/2012, at 2:20 AM, Julian Reschke wrote:
> On 2012-06-15 01:40, Mark Nottingham wrote:
>> ...
>> 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?
>> ...
>
> (I'm not totally sure what you mean by "multiple paths" here, but I'll assume we're still talking about the quoted-string/token choice).
>
> I would argue it's implicit in how the ABNF defined.
>
> When the ABNF indicates that an extension parameter or directive uses
>
> quoted-string / token
>
> then, yes, this means recipients MUST support both.
Julian -
I'm not disputing that. What I've been trying to ask, in so many ways, is why THIS case differs from all of the other cases.
I.e., AFAICT, we rely on the ABNF in every similar case, without making an explicit requirement with RFC2119 language. Why is it necessary to have the ABNF *and* an explicit requirement here?
--
Mark Nottingham http://www.mnot.net/
Received on Tuesday, 19 June 2012 01:42:23 UTC