Re: Robert Wilton's No Objection on draft-ietf-httpbis-header-structure-18: (with COMMENT)

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2365D3A09C3 for <>; Wed, 20 May 2020 19:37:56 -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=YnOcztdW; dkim=pass (2048-bit key) header.b=F7mXqjZq
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XSwLgCY1s6G0 for <>; Wed, 20 May 2020 19:37:54 -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 52FBE3A09C1 for <>; Wed, 20 May 2020 19:37:53 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jbb2q-0004BM-PE for; Thu, 21 May 2020 02:34:52 +0000
Resent-Date: Thu, 21 May 2020 02:34:52 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jbb2p-0004AV-Mz for; Thu, 21 May 2020 02:34:51 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jbb2m-0006Rz-L8 for; Thu, 21 May 2020 02:34:51 +0000
Received: from compute4.internal (compute4.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 3EC881A9D; Wed, 20 May 2020 22:34:33 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute4.internal (MEProxy); Wed, 20 May 2020 22:34:33 -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=l ABB0Nhcbp6qyC1HhsXFkcP/aGWRBcXLijkrlbsxCXI=; b=YnOcztdW92vb+Q/mW 4RJqrg0CpsliOUePLhtukK5Qp0iDrTeyCJ7OjWXnammgfZUYPas7b/KaHeaRTCIG lngbrekcF6U0uGx54yrfi5hy13oqSASQPNkHI5r23s1HFd4efFxVDQrgG6fES7u/ 5Xkv1fe1VttiGY42CYzghDL6npP6MczsHgiq9vN1gxeulP0o/WYtK9C3pfsmtx4W u8tSIE9/GeXRerrUEzN8EU9ElazDb/4Nc1a7bY0u/nxPapbdF/6BJ3JqPJevE2I4 rfIp9cFWd08zJ0Xw+Nnx+qTnviFp7CxGrXoTeP4ZkPJFnEMoSnSDk+DgNnXrjq0o Scgkw==
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=lABB0Nhcbp6qyC1HhsXFkcP/aGWRBcXLijkrlbsxC XI=; b=F7mXqjZqUd4ke1+bO4Jvu/nbQjO9V8Ckr677nxGdxIVhRWIHtjq3A55gs LOKSufZ3W4ypl6pTqAR5DhQwZprVZy0INkjBoHMdqAkFy3zBXOH3ngZrr5sOtz0g PxcJJeK++JatSatvt0uRutnvauDLmFJxQt/HZV19uza0qyAC8rAPdBFN4AIHWVhz nmbVaBCP17rAUXYbR36FqmMcXSVnFEHgABaSlBwBmds/h+2ep8Rzi3Y+JU7ZVNb0 JsyO7pQIQ4x/MR+qosGNRR0D+Xpa7OBksnPBN4pshf5+5lRAITvfmIyjZQ0xcesS +k6UnYcBaLmGyk0U4u4NlLjfT8Byg==
X-ME-Sender: <xms:t-jFXkYtV6qUI5futVAQHKlyZRmSFHSHid91uyVv_IYz4FXM4YBhsw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddutddgheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpedvgfevudetieeuieefteeulefglefhteehlefhjefgkeefleehhfffheektdff tdenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhhthhtphhfihgvlhgushhinhhthh hoshgvthgvrhhmshhmohhrvggtohhmfhhorhhtrggslhgvrdgrshdpmhhnohhtrdhnvght necukfhppeduudelrddujedrudehkedrvdehudenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:t-jFXvZGSZK2J_i0jBGnHxgAaRQQfnWc6inci9MgDidsilXlqkTAEw> <xmx:t-jFXu-SHNWvj9sbZIC4fomXZn7Ykg6UjOPI7jY9JkIsBuMq6Drjfw> <xmx:t-jFXuq1ZGTyWOkLCe4Q0EeoU7QqRCdsC3NWaZ1d4PAY1B0BWo6b7Q> <xmx:uOjFXgBj3P-a7MaQPHpLGNzpOiNbRbvfGlZbcZYwfiRQwhkHro9UYA>
Received: from ( []) by (Postfix) with ESMTPA id B73333066461; Wed, 20 May 2020 22:34:29 -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:34:26 +1000
Cc: The IESG <>,,,, Tommy Pauly <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Robert Wilton <>
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_H4=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: 1jbb2m-0006Rz-L8 f2e6afd8fbd3a914395c8b0c735ce27c
Subject: Re: Robert Wilton's No Objection on draft-ietf-httpbis-header-structure-18: (with COMMENT)
Archived-At: <>
X-Mailing-List: <> archive/latest/37689
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Rob,

Thanks for the feedback. The commit mentioned below is <>.

> On 21 May 2020, at 12:16 am, Robert Wilton via Datatracker <> wrote:
> However, my main comment (which possibly could have been a discuss) questions
> how this is specified.  In my experience other specifications of encodings
> define exactly what the format the encoding must take, but leave it up to
> implementation to decide how to perform that encoding.  Whereas this document
> specifies the format in 3 ways: (i) as a prose description of the format, (ii)
> as an ABNF description of the format, (iii) as a pair of algorithms that
> construct or parse the format.  I would prefer for the ANBF to be definitive
> along with prose to describe/refine the ANBF as required.  For the algorithms,
> I would have preferred that they are held in the appendix as non-normative text
> that provides a description of one possible method of writing the serialization
> or parsing code.  The corner cases that the algorithm cover could be in the
> normative prose/ABNF description.  I appreciate that this would be a
> significant change to the document and hence will leave it to
> authors/responsible AD to decide whether to process or ignore this comment.

There's a fair bit of history here. HTTP headers have typically been defined using ABNF as you suggest. That has led to a number of interoperability (and often security) problems, because the vast majority people don't write ABNF-based parsers or serialisers; they manually interpret the ABNF, prose and examples and write a bespoke parser and serialiser. These issues are exacerbated by the relatively diffuse pool of new field authors (people mint HTTP headers outside the IETF on a regular basis, for a large variety of reasons), and by the even more diffuse pool of people who actually send headers (people writing .htaccess files in Apache, people writing PHP and CGI scripts, people sending a header in XmlHttpRequest or Fetch, etc.). 

All of this led us to try a different approach - specifying parsing and serialisation via pseudo-code. This is the way that the WHATWG writes their specifications (including HTML and Fetch), and it's arguably improved interoperability for Web developers -- which is also our audience -- considerably.

The ABNF is included mostly to make folks who are used to thinking of HTTP fields in those terms more comfortable. As we've seen during the IESG evaluation, that's led to some confusion, so the most recent changes have attempted to make the status of the ABNF more clear.

> A few other comments on particular sections that I noted:
> 1.2.  Notational Conventions
>   When parsing from HTTP fields, implementations MUST follow the
>   algorithms, but MAY vary in implementation so as the behaviors are
>   indistinguishable from specified behavior.
> I find that sentence slightly strange in that the first part of the sentence
> states that your MUST follow the algorithm, and the second part states that you
> don't have to follow the algorithm.  It might be more clear if this was worded
> differently.  E.g. MUST have behavior that is indistinguishable from that
> produced by the algorithm.

Thank you, that's good wording. See the commit.

> 3.1  Lists:
>   An empty List is denoted by not serializing the field at all.
> This was slightly unclear to me.  Does this mean that it isn't possible to
> distinguish between not providing the header and providing an empty list? 
> Possibly it might be worth clarifying this here, although I note that it does
> become clear what the expected behavior is later in the document.

This has been clarified as a result of other comments.

> 3.2.  Dictionaries
>   Dictionaries are ordered maps of name-value pairs, where the names
>   are short, textual strings
> "short, textual" => short textual"
> It might also be helpful to explicitly state what the ordering is (i.e. I
> presume that it is the order that they are listed in the request)

In the commit.

> 3.3.1 Integers
> Are "00" "01" "-0", "-01" all allowed?

They're all allowed in the serialisation, but aren't necessarily distinct in the data model. Do you (and others) think it's worth mentioning here?

> 3.3.6.  Booleans
> Should this cover the fact that if the boolean value is not present it is
> interpreted as true in a parameter or dictionary?  E.g. as per the description
> in the parameter and dictionaries sections?

That's a good clarification; in the commit.


Mark Nottingham