- From: Matthew Kerwin <matthew@kerwin.net.au>
- Date: Thu, 2 May 2019 17:34:24 +1000
- To: Mark Nottingham <mnot@mnot.net>
- Cc: "Julian F. Reschke" <julian.reschke@gmx.de>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>
On Thu, 2 May 2019 at 16:38, Mark Nottingham <mnot@mnot.net> wrote: > > On 2 May 2019, at 4:24 pm, Julian Reschke <julian.reschke@gmx.de> wrote: > > > > In > > <https://greenbytes.de/tech/webdav/draft-ietf-httpbis-header-structure-10.html#specify>, > > we currently say: > > > > "Specify the header field’s allowed syntax for values, in terms of the > > types described in Section 3, along with their associated semantics. > > Syntax definitions are encouraged to use the ABNF rules beginning with > > “sh-“ defined in this specification." > > > > Does this mean, that a definition like > > > > MyField = [ sh-list ] > > > > is an acceptable use of the syntax? (see > > <https://github.com/httpwg/http-extensions/issues/781#issue-426418064>). > > I think it's a *possible* use of the syntax; however, you'd need to accompany it with some prose that directed the parser what to do when SH parsing fails on an empty value. SH pretty strongly steers people away form doing that, so if by "acceptable" you mean "recommended", I think no. > By that reasoning, the only "recommended" use of the syntax is all-or-nothing. Or rather, you oughtn't use an optional sh-foo unless its presence is clearly signalled by something else, which you can use to avoid invoking the generic SH parser in the first place. (Lest you have to deal with the fallout from whatever "fail parsing" actually does) > > Happy to clarify the text you quote above to make that more clear (we probably need to take another pass at the author recommendations anyway). > Definitely warranted, I think. Cheers -- Matthew Kerwin https://matthew.kerwin.net.au/
Received on Thursday, 2 May 2019 07:35:02 UTC