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

Nick Harper <> Mon, 28 October 2019 21:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FDF6120096 for <>; Mon, 28 Oct 2019 14:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 qyR63ds6JNXf for <>; Mon, 28 Oct 2019 14:31:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0806D12008A for <>; Mon, 28 Oct 2019 14:31:44 -0700 (PDT)
Date: Mon, 28 Oct 2019 14:31:41 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1572298302; bh=0a2cIgoOJAEDQp/E7gemv2y5tE/8lQzs4o8r9l74veQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=QE1o0Pw4QCtNcLN4EhpeD4jS41kuCXaJdNBWT+b1jWzUaXgVgFxENBda/4hJl76zv 7DR9etWzOAaTp+zd7aPvrfc7UkVsDQDx9KeuTVxYu+CRNhheMbkwS+m3C0hlzgoos4 RAGX8/f5vAfghTav64K7rYtEiDauTbKzuCT6iqZw=
From: Nick Harper <>
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_5db75e3dea729_7b463fe925ecd968860f9"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nharper
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 21:31:45 -0000

Continuing from my example above, instead of `blob[length-pn_len] payload;`, perhaps that could be `Packet[length-pn_len] payload;`. (Now clarifying some of the syntax I'm making up or copying from TLS: `Type[len] name;` means that the field named `name` has `len` bytes and is of type `Type`.)

Then a StreamFrame might be defined as something like the following:

struct {
  varint stream_id;
  optional varint offset;
  optional varint length;
  blob[length] data;
} StreamFrame : Frame;

struct {
  varint frame_type;
  Frame frame;
} GenericFrame;

struct Packet {
  repeated GenericFrame frames;

Note that I'm basically making things up right now, although this is an interesting exercise in what features a description language would need for QUIC packet format.

I think the transport draft would need to stop at having a `blob[length] data` as the contents of a StreamFrame, and the application (H3) could pick up writing similar definitions.

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