Re: empty lists?, was: Last Call: <draft-ietf-httpbis-header-structure-18.txt> (Structured Field Values for HTTP) to Proposed Standard

On Tue, May 19, 2020 at 09:20:57AM +1000, Mark Nottingham wrote:
> 
> 
> > On 19 May 2020, at 7:23 am, Benjamin Kaduk <bkaduk@akamai.com> 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

Received on Monday, 18 May 2020 23:35:36 UTC