Resent-Date: Tue, 25 Feb 2020 08:07:12 +0000
Resent-Message-Id: <E1j6VFI-0005p5-PD@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>
 <5b050bce-4740-4d48-60d5-3ee5678326a9@gmx.de>
 <F9777B9B-2D5E-4A29-A6D4-F6273437057D@mnot.net>
 <25ce5f62-a7a0-d60f-bb3b-ccdfc39ab44e@gmx.de>
 <D8146003-4572-494F-9C9F-A45D534BAE8C@mnot.net>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <0cb3a4c7-55e3-26ad-639c-405a50fe68f7@gmx.de>
Date: Tue, 25 Feb 2020 09:06:45 +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: <D8146003-4572-494F-9C9F-A45D534BAE8C@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.19;
 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/0cb3a4c7-55e3-26ad-639c-405a50fe68f7@gmx.de>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

On 25.02.2020 07:13, Mark Nottingham wrote:
>
>
>> On 25 Feb 2020, at 5:08 pm, Julian Reschke <julian.reschke@gmx.de> wrot=
e:
>>
>> 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.
>
> If you're referring to the case of a Boolean as a Dictionary value (and =
it would be good if you confirmed that this is what you had in mind; if yo=
u're talking about Booleans wherever they might appear, I don't know how t=
hat would work), it was considered, but IIRC it would have required a subs=
tantially more complicated parsing algorithm, because of cases like this:

Yes.

> Example-Field: ;param=3Don-default-boolean
>
> Parameter values are comparatively simpler, because they can't have any =
further substructure.

I don't quite get the example. In the spec I see:

   Example-DictHeader: a=3D?0, b, c=3D?1; foo=3Dbar

If this would be instead:

   Example-DictHeader: a=3D?0, b, c; foo=3Dbar

...what would break?

Best regards, Julian

PS: I'm tempted to propose "!a" instead of "a=3D?0" :-)