Resent-Date: Mon, 24 Feb 2020 09:24:12 +0000
Resent-Message-Id: <E1j69yG-000461-V6@lyra.w3.org>
To: Mark Nottingham <mnot@mnot.net>
Cc: Tommy Pauly <tpauly@apple.com>, HTTP Working Group <ietf-http-wg@w3.org>
References: <C295C393-9602-4D41-9071-30629605E349@apple.com>
 <1a733857-e621-2ace-ad9a-1e3d872acf25@gmx.de>
 <3B46D138-971F-4602-8E54-4EE903EA5F24@mnot.net>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <5b050bce-4740-4d48-60d5-3ee5678326a9@gmx.de>
Date: Mon, 24 Feb 2020 10:23:46 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <3B46D138-971F-4602-8E54-4EE903EA5F24@mnot.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=212.227.15.18;
 envelope-from=julian.reschke@gmx.de; helo=mout.gmx.net
Subject: Re: Working Group Last Call: Structured Headers for HTTP
Archived-At: 
 <https://www.w3.org/mid/5b050bce-4740-4d48-60d5-3ee5678326a9@gmx.de>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

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 though=
ts?

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     =3D ";" *SP param-name [ "=3D" 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 serialis=
ed, unless it has parameters. For example, here both =E2=80=9Cb=E2=80=9D a=
nd =E2=80=9Cc=E2=80=9D are true, but =E2=80=9Cc=E2=80=9D=E2=80=99s value i=
s serialised because it has parameters:
>>>
>>> Example-DictHeader: a=3D?0, b, c=3D?1; foo=3Dbar
>>
>> 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 suggestin=
g we uppercase all of them (which might be reasonable, given the next comm=
ent)?

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 I=
nteger component has at most 12 digits; the fractional component has at mo=
st three digits.
>>
>> Same here.
>
> Uppercase is used to refer to the SH-type; lowercase is referring to mat=
hematical concepts.

"Integer component" vs "fractional component".

 > ...

Best regards and thanks for the changes so far,

Julian