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

Mark Nottingham <> Mon, 18 May 2020 05:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 00DA63A082A for <>; Sun, 17 May 2020 22:52:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.849
X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[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=ip81gCTK; dkim=pass (2048-bit key) header.b=h8zChPzT
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XmiJRtonVHKu for <>; Sun, 17 May 2020 22:52:09 -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 B3F0F3A0829 for <>; Sun, 17 May 2020 22:52:09 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jaYef-00012u-1n for; Mon, 18 May 2020 05:49:37 +0000
Resent-Date: Mon, 18 May 2020 05:49:37 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jaYee-000102-2b for; Mon, 18 May 2020 05:49:36 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jaYec-0001ZM-1b for; Mon, 18 May 2020 05:49:35 +0000
Received: from compute4.internal (compute4.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id AF9B35B0E; Mon, 18 May 2020 01:49:19 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute4.internal (MEProxy); Mon, 18 May 2020 01:49:20 -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=g NVPtpDu2XQ9otddvDNzrZt5xEwarcFd2yNteYJ7Kv0=; b=ip81gCTKACjdZ+oEK 0VlXgA2xqGcYcK1x7atSZhnEqelR7YxYio0uuizp26z99GQPAx7bg41fCYoMzWPe ot/fEOTsTpa3IXSeDamCVZpz9CK9Q1nMEOllqyZ5zGvE9jWuQIzxh/8yx6ibQY9k 5L93q/TIWMiGxXKwhKGPSn+3b9uxOPQ3FjjwUSJ6VFoP1HWnQrtlGcpDhRpA9Brb BcJrcJxfZUyh9yPyI8fuLPjTSbFXoUYaql8XpY9ch9JrCiWEiJcSO1Vq2QALu4Id 5+5zsCOaVlnp5Yhlz+414JK+XohK7BKT8yZDCWioOOC86w9DufhGkmSizursMffP iMWrw==
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=gNVPtpDu2XQ9otddvDNzrZt5xEwarcFd2yNteYJ7K v0=; b=h8zChPzTcg7s5swc54+sC/3KuJrUk93WcADsKv4Uw9diGC1urL3QkyvIa ygU3mW5IBV63cXv/o6Lm0H318/dDeZLN15qbY4IUUkE0d21CiSWrN1LXGDl/m6uO gdMpqB3K3aKbvSjgNsCOHzK7TVdgIlZXBS10tEfm0J5gHRFb26b5UiTFkI0DQ1B0 Ps/AQDRdttEvxTiiq6EqIvRgmmsjGh4eEz5hDRSOs4mSlRhq7Z3Zk9H81gRNmV9C 1jSOJ/6isSkj6CnTotP5uIr2RiPuqh03eoXV6AYZUL13fmd1CVOJvh6iOnjC27PY 85HSO4+8ooMvcc48DJKYAg67dEgXQ==
X-ME-Sender: <xms:3SHCXnU1Y3nQCTdM-k_XqBaRwO8SCoIgi4QUzZPKv3I3pWo2wm1b1w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddtgedgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeefhfegfffgffduhfefieetieduudejgfehheduffdvfeekvedtffeifeevkedv ieenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhhthhtphifghdrohhrghdpmhhnoh htrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:3SHCXvn8FtdSGUJep0vcbPhYQ36JcnFIes8QMnwKoIf-MNl0HoAUKA> <xmx:3SHCXjbE_Va7rTIaDwkbbJT4PcwiL79laGmlLN8ODytrabQnuCtpTg> <xmx:3SHCXiV7AAOcW2mh055KSDVl_YFQueYPBkC94wFQ_wrfTzwt1z4W4g> <xmx:3yHCXksT1fi5SqiGas665u_c0XF1fjF115tIxIBVfaEyh4MgFxo7qg>
Received: from ( []) by (Postfix) with ESMTPA id 02919328005A; Mon, 18 May 2020 01:49:15 -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: Mon, 18 May 2020 15:49:09 +1000
Cc: The IESG <>,,,, Tommy Pauly <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Erik Kline <>
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.01, RCVD_IN_MSPIKE_WL=-0.01, 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: 1jaYec-0001ZM-1b aead7b09b20891059ee08f2a663b0167
Subject: Re: Erik Kline's No Objection on draft-ietf-httpbis-header-structure-18: (with COMMENT)
Archived-At: <>
X-Mailing-List: <> archive/latest/37645
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Erik,

Thanks for the feedback; responses below.

> On 18 May 2020, at 10:20 am, Erik Kline via Datatracker <> wrote:
> * It's documented as possible for field definitions to place constraints on
>  cardinality; what about constraints on order as well in certain situations?
>  This came to mind again when I got to section 3.2 and read that index-based
>  access was required for dictionaries.  Is it possible for a field definition
>  to place requirements on the order of things in a dictionary?

Yes (although I think this would be somewhat unusual). When I looked at the text to address this, I found that talking about cardinality of dictionary members and parameters didn't make sense, because they're required to be unique. So, see:

>  The phrase "ordered <thing>" appears repeatedly, and Appendix B has important
>  notes about order-preserving structures.  Did I perhaps miss some text early
>  on about this, or should/could this be highlighted in non-appendix text?

I'm struggling to find something to say; is "ordered" not clear enough? The text in the appendix was put there to make it more likely to be noticed. If you can suggest fitting text elsewhere, I'd be grateful. 

> * [ section 4.1.2 ]
>  Should items 3, 3.1, .. 5.2 be indented and renumbered under 2 after 2.1?

Already fixed in source; please confirm at <>.

> * [ section 4.1.8 ]
>  Just to confirm: does serializing an empty byte sequence result in ::?
>  (assuming a context where the entire structured field would not otherwise
>  have been left unserialized)
>  My reading of 4.2.7 is that :: would parse correctly as a 0-length byte
>  sequence.


> [[ random ]]
> * The named ABNF productions are all sh-*, which I assume is for "structured
>  header".  I assume it's too late at this point, but sf-* for "structured
>  field" seemed like a logical choice to me.  Not the least bit important,
>  though!

That's a good point; we forgot to convert these when we moved to more correct terminology. I don't think it's too late; updated in <>.


Mark Nottingham