> The following came up in my AD review of
> draft-ietf-websec-strict-transport-sec, and Jeff suggested that I
> needed to take it to the list. So here it is.
>
> The ABNF in Section 6.1 has this:
>
> directive = token [ "=" ( token | quoted-string ) ]
>
> Below that, bullet 3 says this:
>
> 3. Directive names are case-insensitive.
>
> And in Section 6.1.1:
>
> The syntax of the max-age directive's value (after quoted-string
> unescaping, if necessary) is defined as:
>
> Nothing defines what a directive name or a directive's value is. You
> and I know they're what's on the left side of the equals sign and the
> right side, respectively. We can't assume, though, that people will
> figure out that the ABNF definition above turns into "name=value", and
> will thus know what those terms mean, completely unambiguously, for
> essentially all readers.
fyi/fwiw, the manner in which the ABNF is crafted was finalized in the thread,
with Julian Reschke, rooted here..
Re: [websec] STS ABNF, was: new rev: draft-ietf-websec-strict-transport-sec-04
https://www.ietf.org/mail-archive/web/websec/current/msg01114.html
> Nothing defines what a directive name or a directive's value is. You
> and I know they're what's on the left side of the equals sign and the
> right side, respectively. We can't assume, though, that people will
> figure out that the ABNF definition above turns into "name=value", and
> will thus know what those terms mean, completely unambiguously, for
> essentially all readers.
>
> Making the grammar like this will fix it:
>
> directive = directive-name [ "=" directive-value ]
> directive-name = token
> directive-value = token | quoted-string
>
> If there's a good reason not to make the ABNF change above, I'm happy
> to accept some other way of defining the terms, but I think they must
> be defined. I think doing it with the ABNF is the easiest and
> smoothest way.
I can see doing it as above, or even as a comment..
directive = token [ "=" ( token | quoted-string ) ]
; directive-name = directive-value
Julian apparently has some reasoning for trying not to put everything into the
ABNF (see the thread pointed to above). So I think it'd good if he weighed in
on this.
I do note that the ABNF in draft-ietf-httpbis-p2-semantics-19 for the "expect"
header field which Julian points at does explicitly define ABNF for expect-name
and expect-value, similarly to Barry's suggestion above.
thanks,
=JeffH
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
