Re: Benjamin Kaduk's Discuss on draft-ietf-httpbis-header-structure-18: (with DISCUSS and COMMENT)

Mark Nottingham <> Thu, 21 May 2020 02:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 141AA3A09D6 for <>; Wed, 20 May 2020 19:52:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=qyFqhlY2; dkim=pass (2048-bit key) header.b=yN0Gj8vM
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G2gpRGRjQRSw for <>; Wed, 20 May 2020 19:52:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 219DD3A09E4 for <>; Wed, 20 May 2020 19:52:53 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jbbJz-0008D3-3m for; Thu, 21 May 2020 02:52:35 +0000
Resent-Date: Thu, 21 May 2020 02:52:35 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jbbJy-0008CH-2n for; Thu, 21 May 2020 02:52:34 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jbbJw-0006n8-B8 for; Thu, 21 May 2020 02:52:33 +0000
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id A44D45C0042; Wed, 20 May 2020 22:52:21 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute4.internal (MEProxy); Wed, 20 May 2020 22:52:21 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=B bCcTzC12A9rbBIXGDI0G5YC6pAy0N91rLwTAtkK1w4=; b=qyFqhlY2phfxx1tUz SOJvcMLdLg3fZjcJW+Rt3Jvq2la0d5tdyXGIoRtShV625w4/VlxLODkMPml4h5W3 rz5vCXlmhuEUTeScsCr/EYqOPvNX2zI4lTN+CbBl1/nvioml07ErTOeqWhI3mvyE 86iTjs/umtPLRJt0PRyfvp+N5htW7k1yqut+WmwLx7UaVMvNhELlu964BVbNKSC3 v+/+aIa8vxRGlNTqqXs3aXrZm8bqW5WH3VqeARTh8Cc3vjmjBxUPObGqgS27Tegs RnGo7Njhc9SXBDX4QncbamW/xIGnwSYYWvSkZZnXgzmoyW/4YRJIGaJT+v9dAZDq OvZ/Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=BbCcTzC12A9rbBIXGDI0G5YC6pAy0N91rLwTAtkK1 w4=; b=yN0Gj8vM6XkR/92UFV9704a8cnwNzEwCC3cxfSJURJa/orz4REk2ksA2b 0sgsVWeapv8G/98VLdsf2MajTTodhdSZDFAzTJf1jUO3baSthyui1JDONPOQN/zU XbA41eM6bLTNtisjwDZl5Z8WTTBE1J9n2FedTbKh5/RwRcNs6KhljAcqmJ2XmWBG J+UwVfk0sgvLUdfsfNxaiqGKUB0Ezo6yC0E/16HvmbgOVOjsBtKvWo6mCI8LImv2 ov4YwsqCdw7c3q+V53sQJ7wQFwHPD9cKUGX1zqzFOjsic2fqO3NmYs+YLCy6V2Lz 2OBUtrff69DZ6Q97j6lv/qui3Uvrg==
X-ME-Sender: <xms:5ezFXrPmQWADSpYOXxdg-ZHSgI6WrVhP5V2qK3md0RukS9cg4Q4i7A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddutddgiedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeefheekffelheefjedtvdduleduvddtkedtkeelueeukeehteeufefhvddvkeei teenucffohhmrghinhepfiefrdhorhhgpdhmnhhothdrnhgvthenucfkphepudduledrud ejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:5ezFXl8oTmBfWn0qjlm0ZtmNdFfyzxkZpN0HIpDm6bEMF3sJjZar0A> <xmx:5ezFXqTigMq3vkGn93dcqmYSOYxW6OpKAxjbf417pkhdp2HHuGUU9w> <xmx:5ezFXvtDk3C4ZCXgi1F4Zgf5hhpHg2PjaLvuMQz3uavU-qKjCl_2cQ> <xmx:5ezFXkFk6_OBay6JrRvRvQsbUPtzpDT_aBi2VeWW9HIwsm1qgfKOXw>
Received: from ( []) by (Postfix) with ESMTPA id F1B5B328005D; Wed, 20 May 2020 22:52:18 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Thu, 21 May 2020 12:52:16 +1000
Cc: The IESG <>,,, HTTP Working Group <>, Tommy Pauly <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Benjamin Kaduk <>
X-Mailer: Apple Mail (2.3608.
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-9.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1jbbJw-0006n8-B8 7950ee85f15ea3364575227a59457ac3
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-httpbis-header-structure-18: (with DISCUSS and COMMENT)
Archived-At: <>
X-Mailing-List: <> archive/latest/37691
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On 21 May 2020, at 1:38 am, Benjamin Kaduk <> wrote:
>>>> I think the solution here is to change the last paragraph of Notational Conventions to:
>>>> """
>>>> For serialization to HTTP fields, the ABNF illustrates the expected wire representation with as much fidelity as possible, and the algorithms define the recommended way to produce them. Implementations MAY vary from the specified behavior so long as the output is still correctly handled by the parsing algorithm.
>>>> """
>>>> Does that work for you, Ben?
>>> This makes the parsing algorithms normative for both parsing and
>>> serialization, which alleviates the concerns about skew.
>>> I do agree with Julian that making the (minor!) change to the ABNF to
>>> remove that axis of skew seems worthwhile, though I do not think I can make
>>> that a Discuss point (given that I, like him, would prefer to keep the ABNF
>>> as-is over removing it entirely as you propose).
>> See latest commit.
> I see the update to make the parsing algorithm fully normative; is there
> also something on the empty-list ABNF front that I'm failing to find?

No. Making that change would be seen as encouraging sending of empty fields. 

>>>>> What's the motivation for "MUST omit values of boolean true" (in
>>>>> parameters and dictionaries)?  It seems to make the output rules more
>>>>> complicated without a significant gain in encoding size.
>>>> It allows some existing HTTP headers to be treated as structured for the purposes of serialisation.
>>> The downthread discussion also made the claim that this is due to a desire
>>> to have exactly one way to serialize.  But what's the good in having
>>> exactly one way to serialize if you don't enforce that at the receiver?
>>> (Compatibility with already-defined header fields, no doubt, but it does
>>> kind of undercut some of the stated goals of this document.)
>> Sorry, I lost state. Where did you get that impression?
> Julian said it at
> and
> I didn't see anyone jumping up to correct it.

That wasn't a motivation that we ever discussed, as I recall. I don't know why Julian asserts it here.

Mark Nottingham