Re: Working Group Last Call: Structured Headers for HTTP

[Mark Nottingham <[e-mail]>]

> On 24 Feb 2020, at 8:23 pm, Julian Reschke <[e-mail]> wrote:

>>> That said, the title probably should also change from "Structured
>>> Headers for HTTP" to something like "Structured Field Values for HTTP
>>> Headers and Trailers".
>> 
>> I'm not against that, although it's quite wordy. Anyone else have thoughts?
> 
> 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?


>>> 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


>>> 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.


>>> 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


>>> In Section 3.3.2:
>>> 
>>>> Decimals are numbers with an integer and a fractional component. The Integer component has at most 12 digits; the fractional component has at most three digits.
>>> 
>>> Same here.
>> 
>> Uppercase is used to refer to the SH-type; lowercase is referring to mathematical concepts.
> 
> "Integer component" vs "fractional component".

Fixed.

Thanks again,


--
Mark Nottingham   https://www.mnot.net/