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

Erik Kline via Datatracker <> Mon, 18 May 2020 00:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3CDC3A092B for <>; Sun, 17 May 2020 17:23:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.749
X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[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=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EupdSlsm-w80 for <>; Sun, 17 May 2020 17:23:44 -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 37C163A092A for <>; Sun, 17 May 2020 17:23:43 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jaTW7-0000O6-17 for; Mon, 18 May 2020 00:20:27 +0000
Resent-Date: Mon, 18 May 2020 00:20:27 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jaTW6-0000NK-0g for; Mon, 18 May 2020 00:20:26 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jaTW4-0002EE-AF for; Mon, 18 May 2020 00:20:25 +0000
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 388563A0912; Sun, 17 May 2020 17:20:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Erik Kline via Datatracker <>
To: "The IESG" <>
Cc:,,, Tommy Pauly <>,
X-Test-IDTracker: no
X-IETF-IDTracker: 6.130.0
Auto-Submitted: auto-generated
Reply-To: Erik Kline <>
Message-ID: <>
Date: Sun, 17 May 2020 17:20:11 -0700
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FORGED_REPLYTO=2.095, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1jaTW4-0002EE-AF 378ccd9edb849e0a2227da611ae4ddb4
Subject: Erik Kline's No Objection on draft-ietf-httpbis-header-structure-18: (with COMMENT)
Archived-At: <>
X-Mailing-List: <> archive/latest/37643
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Erik Kline has entered the following ballot position for
draft-ietf-httpbis-header-structure-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Overall, several questions I had while reading the first time were answered,
either directly or implicitly, by text that followed.

[[ questions ]]

* 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?

  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?

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

* [ 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

[[ 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,