Magnus Westerlund's Discuss on draft-ietf-httpbis-header-structure-18: (with DISCUSS and COMMENT)

Magnus Westerlund via Datatracker <> Wed, 20 May 2020 16:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD85E3A0C26 for <>; Wed, 20 May 2020 09:17:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 v5z1XNhhlD3n for <>; Wed, 20 May 2020 09:17:03 -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 0137C3A0C54 for <>; Wed, 20 May 2020 09:17:02 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jbRMV-0002yF-Bh for; Wed, 20 May 2020 16:14:31 +0000
Resent-Date: Wed, 20 May 2020 16:14:31 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jbRMU-0002xT-EV for; Wed, 20 May 2020 16:14:30 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jbRMS-0002uf-GM for; Wed, 20 May 2020 16:14:30 +0000
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id E45F83A0BD2; Wed, 20 May 2020 09:14:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Magnus Westerlund via Datatracker <>
To: "The IESG" <>
Cc:,,, Tommy Pauly <>,
X-Test-IDTracker: no
X-IETF-IDTracker: 7.0.0
Auto-Submitted: auto-generated
Reply-To: Magnus Westerlund <>
Message-ID: <>
Date: Wed, 20 May 2020 09:14:16 -0700
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, 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: 1jbRMS-0002uf-GM 4c8058c0723e608d0108254c4bfeaab3
Subject: Magnus Westerlund's Discuss on draft-ietf-httpbis-header-structure-18: (with DISCUSS and COMMENT)
Archived-At: <>
X-Mailing-List: <> archive/latest/37681
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Magnus Westerlund has entered the following ballot position for
draft-ietf-httpbis-header-structure-18: Discuss

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:


A. Section 3.1:

   The ABNF for Lists in HTTP fields is:

   sh-list       = list-member *( *SP "," *SP list-member )
   list-member   = sh-item / inner-list

   Each member is separated by a comma and optional whitespace.

To me there is a clarity issue that could lead to interoperability issues.
Namely the difference in the meaning of whitespace between RFC 7230 and this
document. Structured headers appear to not allow the HTAB that RFC7230 allows.
And that is fine, but I would expect this to be more clearly discussed. If the
intention was to allow for HTAB you need to use WSP rather than SP in above


1. Section 2, page 8:
     42. Foo-Example Header

   The Foo-Example HTTP header field conveys information about how
   much Foo the message has.

   Foo-Example is a Item Structured Header [RFCxxxx]. Its value MUST be
   an Integer (Section Y.Y of [RFCxxxx]). Its ABNF is:

     Foo-Example = sh-integer

   Its value indicates the amount of Foo in the message, and MUST
   be between 0 and 10, inclusive; other values MUST cause
   the entire header field to be ignored.

   The following parameters are defined:
   * A Parameter whose name is "foourl", and whose value is a String
     (Section Y.Y of [RFCxxxx]), conveying the Foo URL
     for the message. See below for processing requirements.

   "foourl" contains a URI-reference (Section 4.1 of [RFC3986]). If
   its value is not a valid URI-reference, the entire header field
   MUST be ignored. If its value is a relative reference (Section 4.2
   of [RFC3986]), it MUST be resolved (Section 5 of [RFC3986]) before
   being used.

   For example:

     Foo-Example: 2; foourl=""

To me this example indicates several unclarities in this specification.

First there is a lack of discussion of the definition of the field-name and
clearly identify it. In the above example it is only implicit identified. I
would propose that this example has an additional paragraph that explicitly
defined the Structure header name as discussed in the paragraph above this

Per RFC 7230 Section 3.2 a header field is the complete structure of field-name
":" OWS field-value OWS. However looking at this example it appears that
structured header field only define the field-value. Wouldn't it be better to
be explicit about these two components although I understand that field-name is
a constant. This is also evident in what appears to be a grammatical error in
the above paragraph:

   Foo-Example is a Item Structured Header [RFCxxxx]. Its value MUST be
   an Integer (Section Y.Y of [RFCxxxx]). Its ABNF is:

The second "Its" would to me indicate Foo-Example a Item Structured Header, not
the header value (field-value in ABNF) which is defined. I would suggest
changing the second Its to "The Structured header value ABNF is:"