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

Lucas Pardue <lucaspardue.24.7@gmail.com> Wed, 20 January 2021 16:26 UTC

Return-Path: <lucaspardue.24.7@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30B63A14D8; Wed, 20 Jan 2021 08:26:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6PzE4bHja7j; Wed, 20 Jan 2021 08:26:07 -0800 (PST)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E963A14D5; Wed, 20 Jan 2021 08:26:06 -0800 (PST)
Received: by mail-ej1-x62e.google.com with SMTP id ox12so10055150ejb.2; Wed, 20 Jan 2021 08:26:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kKDb7aWOYa7pVN9zyb9if6CK2UDLsPqP8g2V80vWHw4=; b=fc5XHwmYsfGh93JAlcDsNp5/UgI37G6MbRXezk5rvLg0Rkqqf7wMVf2kiaNhSm7OHT kdH/VFDUfCe7OkOxxjsAD3ASI9yBU+AYnjZufAJ0HVJBfVBSuHpvh5L2nuNCW9fFCN/g zQlEmTyzXCWwvo8vb255N7x/+bQrn0hNGYH8IG2l4dg7vgKVlm7eN2/Ldyd2ZOJsprhq vFqWu8RTJRdgbAM1iEOpeqDHtZMdRf56KX1A8QLxB/XCfJG1ueNoayNiueN43PuORRoM 2gWrVb4X1ja/+o1zHaNxV2P6C9bj0xb4wTLbY53zWPrDGITP+6KMMuWxQeRTi0s/hguK YkGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kKDb7aWOYa7pVN9zyb9if6CK2UDLsPqP8g2V80vWHw4=; b=ayxzuPn2FwZlUX7ONkwVI0cvEXQZxuY9Bc0z34InOmGicLanhcjm7jvyPbzA9notoS nwMFcv9niTDzrBIg+Ud0Xk6I6H8y3zIXqMa5z0e+sxpxK5rB0DRn7kiOkOOTjHNhW44l WY8GCzwn2yB+rRVlc+i72VkOTOKHahJrCS5YTEWANRrvMd1JaO4FUxo6qmAt56UZqhO+ 4PdMPOHNXyXE1rpk7lAwty6zqIAFEe9zP1692UJacKzRdhBZQZo5H/YVAxFfaJhC7+8e oTuoStZjIOUsmwCmmcEcTVrdzp+3fUdtssnpYUTLwlKtkIDrmTqcjIRMLX0yTb6/RfoI JBrA==
X-Gm-Message-State: AOAM531QDdV+T//47UGdxPWFBIfFHYF5BCLelyIvNhcgq9LT5XIvRFSj qcEiXet4sWJmND5SrH1sJ9sdXVZUk7QOX3nlN3Y=
X-Google-Smtp-Source: ABdhPJzWzCfneAemC4cHMH+yq1P+7vVQgVcv1SRKriUGod1npaV8S22j7unRKuQ8GfZzWwXGGJW57ha72+8VHJdwQc4=
X-Received: by 2002:a17:906:4a04:: with SMTP id w4mr6782036eju.46.1611159965116; Wed, 20 Jan 2021 08:26:05 -0800 (PST)
MIME-Version: 1.0
References: <161112076127.27785.14541735008066112220@ietfa.amsl.com>
In-Reply-To: <161112076127.27785.14541735008066112220@ietfa.amsl.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Wed, 20 Jan 2021 16:25:54 +0000
Message-ID: <CALGR9oY2v8NzomPKDB8XY4GeH-YLDXx56iv6BVg9xWqNSA0bkg@mail.gmail.com>
Subject: Re: Barry Leiba's Discuss on draft-ietf-quic-http-33: (with DISCUSS and COMMENT)
To: Barry Leiba <barryleiba@computer.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-quic-http@ietf.org, WG Chairs <quic-chairs@ietf.org>, QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000065ad9d05b957696c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/N0rC0HD59ViC_2YKcrnK5LY6qe0>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jan 2021 16:26:09 -0000

Hi Barry,

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 Wed, Jan 20, 2021 at 5:32 AM Barry Leiba via Datatracker <
noreply@ietf.org> wrote:

> 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-quic-http/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks, Mike, for the excellent editing work on a very clear and well
> written
> document.
>
> 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”?
>

https://github.com/quicwg/base-drafts/issues/4771


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

https://github.com/quicwg/base-drafts/issues/4772

Cheers
Lucas
On behalf of QUIC WG Chairs