Re: Empty lists in Structured Headers (#781)

[Kari Hurtta <[e-mail]>]

> A. Leave the document as is, not defining empty header values for SH
>    (as requested by the editors). As noted on the list, this can allow
>    future revisions to add support.
> B. Define empty header values for SH (as the issue requests).
> C. Do not allow empty header values for SH, but add formal text to the
>   document explaining how to handle empty values.

I can't select any of these.


I think that empty
   sh-list

and similarly
   sh-listlist
   sh-dictionary
   sh-param-list

make sense.

After all also string and binary value can be empty.

   sh-string = DQUOTE *(chr) DQUOTE
   sh-binary = "*" *(base64) "*"

so why not other types also, where some number of elements.
So zero elements looks logical.

This results empty http header field, but there is also precedents
as noted on issue.

When header is empty, parser can not determine that
is that sh-list, sh-listlist, sh-dictionary or sh-param-list
with zero elements.

If one of these are expected for given header field, then
this is not problem.

Logically empty values for
   sh-integer
   sh-float
   sh-token

does not make lot of sense.  So I not have very fan
for null token (value ?N suggested) if it apply
for sh-integer, sh-float or sh-token.

I think there on some cases there is C what is closest.

For some B is closest (allow empty header field value
when expected syntax naturally leads zero elements on 
that case). If several syntax is allowed (ie there is
alternatives), then it using specification need specify
how to process ambiguity.

/ Kari Hurtta