- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Wed, 22 May 2019 15:29:01 +0300 (EEST)
- To: HTTP Working Group <ietf-http-wg@w3.org>
- CC: Tommy Pauly <tpauly@apple.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>
> 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
Received on Wednesday, 22 May 2019 12:29:38 UTC