On Tue, May 19, 2020 at 09:20:57AM +1000, Mark Nottingham wrote: > > > > On 19 May 2020, at 7:23 am, Benjamin Kaduk <bkaduk@xxxxxxxxxx> wrote: > > > >>> You saw > >>> > >>> An empty List is denoted by not serializing the field at all. > >>> > >>> right? > >> > >> That's about serialization. > >> > >> 4.2.1 seems to parse an empty string into an empty list. > >> > >> AFAICT, that's in conflict with the ABNF. > > > > Thanks for clarifying. > > As per S 1.2 [1], the ABNF is not for parsing; it's for 'illustrat[ing] the range of acceptable wire representations.' > > The ABNF requires at least one member because sending an empty field value is not good practice; it's not something we encourage. > > > > FWIW I already have a comment staged about how we seem to make the > > ABNF normative for serialization but the prose normative for parsing, > > which seems like a weird mismatch that requires justification. > > ABNF isn't normative for serialisation; what led you to that conclusion? > > > > 1. https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#notational-conventions Well, we are very explicit that "when parsing [...], implementations MUST follow the algorithms. [...] If there is a disagreement between the parsing algorithms and the ABNF, the specified algorithms take precedence". We lack such strong language for the serialization process, and in fact say that "[i]mplementations MAY vary from the specified behavior so long as the output still matches the ABNF", with the algorithms merely being the "recommended way to produce them". To me, that implies that the ABNF is controlling, as any variance in serialization procedure is contingent on the output matching the ABNF. If that's not the intended reading, I suggest making the language more parallel to the parsing case. -Ben -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
