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

[Julian Reschke <[e-mail]>]

On 19.05.2020 01:20, Mark Nottingham wrote:
>
>
>> On 19 May 2020, at 7:23 am, Benjamin Kaduk <[e-mail]> 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.
> ...

So the real inconsistency here is that sending an empty value is not ok
(forbidden?, not encouraged?), but an empty string is a valid parser input.

That is confusing; if that's really intended, it should be explained
somewhat more. AFAIC, it would be way easier just to align "what can be
in a field value" with "what the parser accepts as input".

> ...

I note that there is a test called "empty list" at
<https://github.com/httpwg/structured-header-tests/blob/master/list.json#L8>:

>     {
>       "name": "empty list",
>       "raw": [""],
>       "header_type": "list",
>       "expected": [],
>       "canonical": []
>     },

<https://github.com/httpwg/structured-header-tests/blob/master/README.md>
says:

> raw: An array of strings, each representing a header field value received

I understand that the tests are not part of the spec, but this seems to
support the case that empty field value should be accepted.

Best regards, Julian