Re: making up new header field syntax...

On Thu, Jun 29, 2017 at 1:18 PM, Julian Reschke <julian.reschke@gmx.de>
wrote:

> 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... :)
>>
>
> So do I, if only for the reason that we're not making progress on the
> other solution, and *not* using JFV seems to do actual harm right now...


I agree with you agreeing with me. :)


> Do you mean the reference to the `#rule`? That link points to RFC 7230, as
>> does the text, and https://tools.ietf.org/html/rfc7230#section-1.2
>> includes DQUOTE and ALPHA by reference to RFC 5234. Should we be pointing
>> to RFC 7230 for those as well?
>>
>
> I missed the reference in the comments part. Sorry. But no, this is *not*
> RFC5234-ABNF, so the introduction should be clearer on this. See, for
> instance, <https://www.greenbytes.de/tech/webdav/rfc7838.html#rfc.sect
> ion.1.1>.
>

I added some clarification along these lines in
https://github.com/w3c/webappsec-clear-site-data/commit/9f20dcc7580e241636c4787b6cf852a7e6258d63,
thanks!

>
>         c) things look like quoted-strings, but aren't quoted-strings
>>
>>
>> Would you be happier with something like `1#( quoted-string )`? I'd like
>>
>
> That would be better.


Done (also in
https://github.com/w3c/webappsec-clear-site-data/commit/9f20dcc7580e241636c4787b6cf852a7e6258d63),
thanks!


>         d) tokens not allowed
>>
>>
>> Can you clarify what you'd like to see?
>>
>
> As long as this is just a list of keywords, you could just use a list of
> tokens (example: <https://www.greenbytes.de/tec
> h/webdav/rfc7231.html#rfc.section.7.4.1>).
>
> If you need or anticipate the need of keywords that aren't tokens (for
> instance, because of whitespace), I'd use
>
>   token / quoted-string


Because I secretly expect to move back to JSON at some point in the future,
I'd prefer to require quoted-string, as that seems forward-compatible with
treating the header as a list of valid JSON objects. That is, `Header:
value, value, value` would explode in a JSON parser, while `Header:
"value", "value", "value"` would not.

-mike