Re: [quicwg/base-drafts] Don't use bitmap frames to describe varint structures (#3115)

Lucas Pardue <> Mon, 28 October 2019 00:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E87D12004D for <>; Sun, 27 Oct 2019 17:05:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 68I6_TZ2x78n for <>; Sun, 27 Oct 2019 17:05:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 42A21120046 for <>; Sun, 27 Oct 2019 17:05:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 85D122C0B97 for <>; Sun, 27 Oct 2019 17:05:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1572221146; bh=FBXcF/3BhrQBhz3OgxINnz6qMZMABT5otN8qIVcPccI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Xomdkbv3lPpQgatUKvSbC8n5cFRzPWzdmiOYBZoGHbAg6n7Z6yeKBvwvyJZgDum5c nUUhEAqIWrn44amhB/QRZ6jAkkAinYuKHGLUpBuBer4Due0G6NdUIw2TgZNVLHhk3E uXuUufZvFdW/VjgysaXg/leMyBlhK/uFF95slxK4=
Date: Sun, 27 Oct 2019 17:05:46 -0700
From: Lucas Pardue <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3115/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Don't use bitmap frames to describe varint structures (#3115)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db630da76656_79cc3fc39cccd96421852c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: LPardue
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Oct 2019 00:05:49 -0000

As the person that created many of the HTTP/3 frame diagrams I apologise for raising your ire :)

As someone that mainly came into IETF via HTTP/2, my main motivation for diagramming the frames in HTTP/3 was for consistency when switching back and forth between drafts. For example, single variable frames are diagrammed in RFC 7540 so it did seem inconsistent to skip them (to @MikeBishop's point). I'd experienced several occasions (myself and others) where the lack of a diagram had led to some oversight when implementing the specification - even if that is not their intended purpose because they are duplicatory of text.

That said, I do see the point you are making. For instance, I opened to point out the problem with the diagram in section 6.2.2. I think the diagram is a problem but Mike closed it as no-one seemed to care at the time.

However, I'd like to highlight that RFC 7540 has, in part, the problem you are describing where fields of unknown length are represented by the `*` character.
    |Pad Length? (8)|
    |E|                 Stream Dependency? (31)                     |
    |  Weight? (8)  |
    |                   Header Block Fragment (*)                 ...
    |                           Padding (*)                       ...

                      Figure 7: HEADERS Frame Payload

Is your complaint about the QUIC specs caused by the top line of each diagram that show the 32-bit space, or do you think we got it wrong with H2 also?

FWIW I think there could be merit in defining a more structured syntax for Frames and Streams - especially as we look forward to new versions and extensions of QUIC because we should make it pretty straightforward for new contributors to pick up and go. However, I see a change at this stage being a bunch of editorial work.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: