Barry Leiba's Discuss on draft-ietf-quic-http-33: (with DISCUSS and COMMENT)

Barry Leiba via Datatracker <> Wed, 20 January 2021 05:32 UTC

Return-Path: <>
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 4AA1E3A0C7B; Tue, 19 Jan 2021 21:32:41 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <>
To: The IESG <>
Subject: Barry Leiba's Discuss on draft-ietf-quic-http-33: (with DISCUSS and COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <>
Message-ID: <>
Date: Tue, 19 Jan 2021 21:32:41 -0800
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Jan 2021 05:32:41 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-quic-http-33: 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:


Thanks, Mike, for the excellent editing work on a very clear and well written

In Section 4.1.1 I’m confused by the combination of the following two
paragraphs, and would like to discuss what I’m missing:

   Like HTTP/2, HTTP/3 does not use the Connection header field to
   indicate connection-specific fields; in this protocol, connection-
   specific metadata is conveyed by other means.  An endpoint MUST NOT
   generate an HTTP/3 field section containing connection-specific
   fields; any message containing connection-specific fields MUST be
   treated as malformed (Section 4.1.3).


   This means that an intermediary transforming an HTTP/1.x message to
   HTTP/3 will need to remove any fields nominated by the Connection
   field, along with the Connection field itself.  Such intermediaries
   SHOULD also remove other connection-specific fields, such as Keep-
   Alive, Proxy-Connection, Transfer-Encoding, and Upgrade, even if they
   are not nominated by the Connection field.

Given the MUST in the first, how can the second only be SHOULD?  Wouldn’t such
an intermediary, acting as the HTTP/3 client, be producing a malformed message
if it did not “remove other connection-specific fields”?


There are three instances of “URL” in the draft.  Make them “URI”, please.