Re: making up new header field syntax...

On 2017-06-29 12:56, Mike West wrote:
> On Sun, Jun 25, 2017 at 1:57 PM, Julian Reschke < 
> <>> wrote:
>     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.
> ...

It was intended to get us back to work on this :-)

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

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

Saw that. See 

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

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, 

>         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 expert.

You are right, sorry. Must have imagined some sub structure in the 
fields that isn't there right now.

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

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

As long as this is just a list of keywords, you could just use a list of 
tokens (example: 

If you need or anticipate the need of keywords that aren't tokens (for 
instance, because of whitespace), I'd use

   token / quoted-string

>     e) ABNF invalid ("|" instead of "/" -
>     <
>     <>>)
> My mistake. Perhaps we should wire Bikeshed up to an ABNF validator. 
> Added a note to to that 
> effect.

Best regards, Julian

Received on Thursday, 29 June 2017 11:19:28 UTC