Re: Robert Wilton's No Objection on draft-ietf-quic-http-33: (with COMMENT)

Lucas Pardue <> Thu, 21 January 2021 14:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DF933A0EC0; Thu, 21 Jan 2021 06:36:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XV3cUYlEn7Rx; Thu, 21 Jan 2021 06:36:35 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2AB323A0E05; Thu, 21 Jan 2021 06:36:35 -0800 (PST)
Received: by with SMTP id ox12so2931740ejb.2; Thu, 21 Jan 2021 06:36:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LX9RCES11sf0xU1EREM9XACGqDMmsyW3sRJY2gWY/Qo=; b=hpaylKfOsIQdox6rsQkf8uqtrmETiDE/4Iq8TX+X52jVkOpcAJgriGeP/TFEw9AtFo QhBt/DyCpiGeg5UzW0gw07e79mqLQsi7/yg6VxGGO9YSUCC4PwRL3U9rITFo17o8Npr9 lHYz9oVE1RhF95Nv8kkNAjpgx0VR8Nmsw/unYOca3ZlHFwje/fVkX8NI5/wSzbNIDFKt cZXlvY1M67t2FV6FZcKIhkenwEeyaotjYJwGD0PPR6sM0Q6fKMAx9jX23LyxHCXQIQNg ctWzU1azLqK19JoR4VdZDnRRicanjqBQeF+xebRy5lhcvzAVeAgrbb+XiTcUDSDEz8U3 09+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LX9RCES11sf0xU1EREM9XACGqDMmsyW3sRJY2gWY/Qo=; b=SWn9RnFP7/vxlW9+nlIGRsuTLqK5TbNCX9aE/XIyJW0FNCF2fOAY9QEDAIeOMHXhKH t/dSE/l8KQzX0bo2AoA9in4g96/syB/sf8CjVJ0Xh6WowMLUx/qwLo9tMTrj6flCC9FO ZOudtXtnfCgulAzcizYCziD3qRHvcrx1i/YLTH2pMH0fkEAZkISGdlsyopjolSwPr8/5 bCeHsNpqjTA/WjDg5DzgCLNvbheeHEWJuCNCDNGJyD5E7WHjuBOsw7mrmn3zu+0U8cID Y6NQCn4MngthjD+O1T7nNODSVC+M4OGO7rIXFJUvGCPaKodKfJ5Zaa8/utbBkor0UlQ1 +V0A==
X-Gm-Message-State: AOAM533azwZUGOKA9BmtftlysDjUAPexzVeJz7V3T6E/eb6MrOlZSQEu Utwzdowm4KzL0qjMroBi3HPd+vqy5cNnCZGxz5M1YbG6Zg4=
X-Google-Smtp-Source: ABdhPJwFnP5AEDDK/cCqo9cEcphtI1CzmTKi6wjpNqAQl3bMnrm1+8LNANkwpRi1Fy7cT4wRQag9fxMoPsbKUuhRAj8=
X-Received: by 2002:a17:906:1d5a:: with SMTP id o26mr9518298ejh.301.1611239793732; Thu, 21 Jan 2021 06:36:33 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Thu, 21 Jan 2021 14:36:22 +0000
Message-ID: <>
Subject: Re: Robert Wilton's No Objection on draft-ietf-quic-http-33: (with COMMENT)
To: Robert Wilton <>
Cc: The IESG <>,, WG Chairs <>, QUIC WG <>
Content-Type: multipart/alternative; boundary="0000000000008db08705b969ffce"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
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: Thu, 21 Jan 2021 14:36:37 -0000

Hi Rob,

Thanks for the review. I've created GitHub issue(s) to track each comment
on the QUIC WG repository, see the URL(s) in line.

On Thu, Jan 21, 2021 at 1:24 PM Robert Wilton via Datatracker <> wrote:

> Robert Wilton has entered the following ballot position for
> draft-ietf-quic-http-33: 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:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Another well written document coming out of the QUIC WG, thank you for
> that.
> Some minor comments:
> 4.1.1.  Field Formatting and Compression
>    As in previous versions of HTTP, field names are strings containing a
>    subset of ASCII characters that are compared in a case-insensitive
>    fashion.  Properties of HTTP field names and values are discussed in
>    more detail in Section 5.1 of [SEMANTICS].  As in HTTP/2, characters
>    in field names MUST be converted to lowercase prior to their
>    encoding.  A request or response containing uppercase characters in
>    field names MUST be treated as malformed (Section 4.1.3).
> Why make the comparison case-insensitive given that the request MUST only
> use
> lowercase characters?  Presumably implementations will just do a regular
> case
> sensitive comparison?

>  Field Compression
> Given that section  states that "Pseudo-header fields are not HTTP
> fields.", it might be helpful to be explicit that pseudo-header fields are
> also
> compressed using QPACK.

> 6.1.  Bidirectional Streams
> So as to not unnecessarily limit
>    parallelism, at least 100 requests SHOULD be permitted at a time.
> Given that this section is about streams, perhaps better if the limit is
> stated
> in terms of streams, e.g., perhaps change "requests" to "request streams".

> 10.6.  Use of Compression
>    Implementations communicating on a secure channel MUST NOT compress
>    content that includes both confidential and attacker-controlled data
>    unless separate compression contexts are used for each source of
>    data.  Compression MUST NOT be used if the source of data cannot be
>    reliably determined.
> This wasn't entirely clear to me.  I presume (perhaps wrongly) that the
> issue
> is about the use of compression before the confidential data has been
> encrypted.  I.e., I would presume that compressing a stream of data that
> includes both encrypted and non encrypted data is okay?  Perhaps this
> could be
> clarified.

On behalf of QUIC WG Chairs