Re: making up new header field syntax...

On Sun, Jun 25, 2017 at 1:57 PM, Julian Reschke <>

> On 2017-06-25 13:52, Julian Reschke wrote:
>> Here's a recent example I found (when looking for uses of JFV):
Hey Julian! Thanks for pointing out these mistakes! I'd encourage you to
file bugs against the spec next time; I'm more likely to see them on GitHub
than here.

I originally planned for this header to use JFV, and have backed away from
it because of the ongoing discussions in this group about what the Syntax
of the Future(tm) should look like. That said, I do anticipate needing some
more structure in the values in the fairly near future (`"cookies"` is not
nearly granular enough for most use cases, as it turns out). Personally, I
still believe JSON is a reasonable fit for that kind of structure... :)

On that note, is another example you
might be interested in skimming through.

> <>:
>> The Clear-Site-Data HTTP response header field sends a signal to the user
>>> agent that it ought to remove all data of a certain set of types. The
>>> header is represented by the following ABNF [RFC5234]:
>>> Clear-Site-Data = 1#( DQUOTE ( data-type | extension-type ) DQUOTE )
>>> data-type = "cache" | "cookies" | "storage" | "executionContexts"
>>> extension-type = 1*( ALPHA | "-")
>>> ; #rule is defined in Section 7 of RFC 7230.
>>> ; DQUOTE and ALPHA are defined in Appendix B.1 of RFC 5234.
>> Issues:
>> a) the list rule is defined in RFC 7230, not RFC 5234
Do you mean the reference to the `#rule`? That link points to RFC 7230, as
does the text, and includes
DQUOTE and ALPHA by reference to RFC 5234. Should we be pointing to RFC
7230 for those as well?

> b) the syntax doesn't allow whitespace, but the examples use it
I think `1#whatever` allows whitespace. That's my reading of, but I'm (obviously!) not an

c) things look like quoted-strings, but aren't quoted-strings
Would you be happier with something like `1#( quoted-string )`? I'd like to
specify the legal values so I can link to them later in the spec, but I
suppose that doesn't need to be done in the ABNF.

d) tokens not allowed
Can you clarify what you'd like to see?

> e) ABNF invalid ("|" instead of "/" - <
> ?v=LbK-g8tKnoc>)

My mistake. Perhaps we should wire Bikeshed up to an ABNF validator. Added
a note to to that effect.


Received on Thursday, 29 June 2017 10:57:05 UTC