Re: Working Group Last Call: Structured Headers for HTTP

[Julian Reschke <[e-mail]>]

On 25.02.2020 01:34, Mark Nottingham wrote:
> ...
>> Or just "Structured Field Values for HTTP".
>
> That's better, and I think I can live with it -- as long as we establish that "Structured Headers" is an alias for it (and still use that in-spec, as it's in a number of places). Make sense?

WFM.

>>>> 2. use of "URL" comes as as surprise here, maybe just say "field value"
>>>
>>> The intent is to ignore the individual URL, not the entire field value.
>>
>> Ack. But the mix of "URI-reference" and "URL" is just confusing.
>
> Fixed in https://github.com/httpwg/http-extensions/commit/86968ad5

Thanks.

>>>> In Section 3.2:
>>>>
>>>>> Members whose value is Boolean true MUST omit that value when serialised, unless it has parameters. For example, here both “b” and “c” are true, but “c”’s value is serialised because it has parameters:
>>>>>
>>>>> Example-DictHeader: a=?0, b, c=?1; foo=bar
>>>>
>>>> I guess this is needed in order to avoid ambiguities, but this outcome
>>>> is really a bit strange. Is there a summary of how we got to that
>>>> special case somewhere (github issue?)
>>>
>>> https://github.com/httpwg/http-extensions/issues/992
>>
>> Hm, that refers to existing field values, which the spec says are out of
>> scope.
>
> Yes - but future specs may build upon that capability.
>
>> That said, I *do* agree that the value-less variant is nice for flags;
>> my question is why we ended up with special-casing this in parameters,
>> and also why we don't allow serialising with "true" value outside
>> parameters.
>
> The bug has the history; basically there are a number of already-defined headers that have value-less parameters that previously failed parsing as SH. *If* we want to try to back-port them in the future, accommodating that seems important.

I understand that. What trips me up is that we we have to different
cases: one in which the shorter notation MUST be used, one in which it
MUST NOT be used. Am I the only one who thinks that this is sub-optimal?

In a perfect world, the serialization should not depend on the context
it appears in. I understand that this is a trade-off, but it would be
good to see more context about how we got there, and whether
alternatives were discussed.


>>>> In Section 3.3:
>>>>
>>>>> An item is can be a integer (Section 3.3.1), decimal (Section 3.3.2), string (Section 3.3.3), token (Section 3.3.4), byte sequence (Section 3.3.5), or Boolean (Section 3.3.6).
>>>>
>>>> Please be consistent in upper/lowercasing...
>>>
>>> Boolean refers to a person's name; lowercasing it would be equivalent to saying that your review is reschkean, not Reschkean. Or are you suggesting we uppercase all of them (which might be reasonable, given the next comment)?
>>
>> In that case I'd suggest uppercasing for consistency.
>
> This ended up being more intrusive; once I looked at the whole spec with this in mind, a number of changes were necessary. Please review:
>    https://github.com/httpwg/http-extensions/commit/4a18a87802d778
>

Looks good to me.

> ...

Best regards, Julian