Re: [Technical Errata Reported] RFC9114 (7238)

Lucas Pardue <lucaspardue.24.7@gmail.com> Fri, 04 November 2022 10:07 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 AF300C14F6EC for <quic@ietfa.amsl.com>; Fri, 4 Nov 2022 03:07:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Level:
X-Spam-Status: No, score=-1.855 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlUkwy7hhPhQ for <quic@ietfa.amsl.com>; Fri, 4 Nov 2022 03:07:16 -0700 (PDT)
Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED809C14CE44 for <quic@ietf.org>; Fri, 4 Nov 2022 03:07:16 -0700 (PDT)
Received: by mail-oi1-x22a.google.com with SMTP id y67so4702455oiy.1 for <quic@ietf.org>; Fri, 04 Nov 2022 03:07:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=btVMFBhFVtnM793onPUmMgxKKkPRnRf3g2m1gqbY5Ho=; b=ccFrvRU185EXYB6XjOU/VS7+oNDP9mFJSshlM57TrGkyZSQsWnpcC4CX2bFGnQ7Br4 haCSmr8++1GmjJpoGLPacwXRDCAwAJHiqKO0WlctWFcxjtH3V7mK4pSKT4N+srl0AhjR I7kbFcHXQ1x9xUFa2IOVHN8tjckRWOjAVQT/0DxHE1//7mvDxqNIPY72AIBgkUzRS7dx cSZsT3GKQd+/+3jsraUNxYU2o5wqAyQV2JLk12yUUQDM6AY8Aes6YuSJggbbrtfOsBwL dyrAWlJ1EmjsOCbRHP0qHqLj9Ptw8+HnCTXBWIMzbJX6Q1JSv+lnRI0o3esXiIv3Vs5G wgAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=btVMFBhFVtnM793onPUmMgxKKkPRnRf3g2m1gqbY5Ho=; b=TVvH2VKOQMP/fYY9Ixz5nkluk4KAsk7xdUwZOqc+YGHVklPm06inZAcss65dpIQ5td 8Zqqh3KafhQhEKzqhdQyY0MppEYYOWsgHAVV+wI0gGwPGnaXZn+G25De2q2PSbOne0P7 gnyJ4OwFEt9KCr4z2Rml8TVLXmvn3lvowv7Ypj+u+1FQkSU+kWgYuABm9nBshLEECKyl qXU9N+7kWorsuQyfdMQACfTuzx3G7fBjRCn0t6nYdnNV9JQlSsQaJr7uI5DwWcnWNm3C mqi7eoX2i6YjkXhmVHxCZZSEp+sEcUThFeu3A/bajvzQSPskGhpLL0seRNsQpQd2+PQT AYpw==
X-Gm-Message-State: ACrzQf1zMusWlctjR2uerPXGHufhTQBPsdjyF5YQEgSMjHmyoCRZqOW2 ed7SKWEED36aNWgz1oLFWLelwcE7q7PLswsSRfA=
X-Google-Smtp-Source: AMsMyM7sMRkgnS6jw+ppftuBfoYYMEHIvjn0GsXXyriYex/dIoPsPkH3GRCphOseedl4mIC6876MyKz/MGXxGVaoi0Q=
X-Received: by 2002:a05:6808:3007:b0:351:5ea9:83d1 with SMTP id ay7-20020a056808300700b003515ea983d1mr18002877oib.150.1667556435772; Fri, 04 Nov 2022 03:07:15 -0700 (PDT)
MIME-Version: 1.0
References: <20221104094914.0E3C755F68@rfcpa.amsl.com>
In-Reply-To: <20221104094914.0E3C755F68@rfcpa.amsl.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Fri, 04 Nov 2022 10:07:01 +0000
Message-ID: <CALGR9oYFOHdwkG1DF6KyPOcVDkk_ftMO8wTPCzOBAZnrK9hf9A@mail.gmail.com>
Subject: Re: [Technical Errata Reported] RFC9114 (7238)
To: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: Mike Bishop <mbishop@evequefou.be>, Martin Duke <martin.h.duke@gmail.com>, Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>, Matt Joras <matt.joras@gmail.com>, jai.forums2013@gmail.com, QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ff4a3005eca23c87"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/8E8kNJe1VGKEjotTl3IT2oZoGGo>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 04 Nov 2022 10:07:20 -0000

Hi,

Speaking as an individual, I think the current RFC text is correct. The
problem that is being described is where 1) a client sends a message
smaller than MAX_FIELD_SECTION_SIZE and might expect that to work but 2)
the server is an intermediary that needs to forward the message onto
another server that, for example,  has a smaller value for
MAX_FIELD_SECTION_SIZE preventing this.

In other words, even if the client plays by the rules of the first hop by
staying under the limit, there is no guarantee that other hops that the
client is not aware of won't reject the message.

Cheers
Lucas

On Fri, 4 Nov 2022, 09:49 RFC Errata System, <rfc-editor@rfc-editor.org>
wrote:

> The following errata report has been submitted for RFC9114,
> "HTTP/3".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7238
>
> --------------------------------------
> Type: Technical
> Reported by: Jaikiran Pai <jai.forums2013@gmail.com>
>
> Section: 4.2.2
>
> Original Text
> -------------
> Because this limit is applied separately by each implementation that
> processes the message, messages below this limit are not guaranteed
> to be accepted.
>
>
> Corrected Text
> --------------
> Because this limit is applied separately by each implementation that
> processes the message, messages above this limit are not guaranteed
> to be accepted.
>
>
> Notes
> -----
> The section 4.2.2 specifies header size constraints and notes that
> implementations can send a SETTINGS frame with a
> SETTINGS_MAX_FIELD_SECTION_SIZE identifier to set a limit on the maximum
> size of the message header. Since this a maximum size, the sentence that
> states that intermediaries aren't guaranteed to accept a message below this
> limit seems odd and I think it should instead say "above this limit".
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC9114 (draft-ietf-quic-http-34)
> --------------------------------------
> Title               : HTTP/3
> Publication Date    : June 2022
> Author(s)           : M. Bishop, Ed.
> Category            : PROPOSED STANDARD
> Source              : QUIC
> Area                : Transport
> Stream              : IETF
> Verifying Party     : IESG
>