Re: Working Group Last Call: Structured Headers for HTTP

On 24.02.2020 00:55, Mark Nottingham 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".

>> In the example spec text:
>>
>>> "fooUrl" contains a URI-reference (Section 4.1 of
>>> [RFC3986], Section 4.1). If its value is not a valid URI-reference,
>>> that URL MUST be ignored. If its value is a relative reference
>>> (Section 4.2 of [RFC3986]), it MUST be resolved (Section 5 of
>>> [RFC3986]) before being used.
>>
>> 1. remove ", Section 4.1"
>
> Done.
>
>> 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.

> ... >> In Section 3.1.2:
>>
>> ABNF:
>>
>> parameter     = ";" *SP param-name [ "=" param-value ]
>>
>> Prose:
>>
>> "...parameters are separated from their item or inner-list and each
>> other by semicolons."
>>
>> So there's an unfortunate mismatch between the ABNF production
>> "parameter" (which already includes the ";") and the use of "parameter"
>> in the prose. Maybe worth addressing in the ABNF.
>
> Please take a look at
>    https://github.com/httpwg/http-extensions/commit/b4b8f4a73

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

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.

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

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

 > ...

Best regards and thanks for the changes so far,

Julian

Received on Monday, 24 February 2020 09:24:06 UTC