Re: QUICWG Temporary IANA Registry

Dmitri Tikhonov <> Wed, 03 February 2021 13:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C76AF3A09B9 for <>; Wed, 3 Feb 2021 05:36:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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 kBIVTTYthlRW for <>; Wed, 3 Feb 2021 05:36:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::f30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8486A3A09B5 for <>; Wed, 3 Feb 2021 05:36:12 -0800 (PST)
Received: by with SMTP id ew18so11621178qvb.4 for <>; Wed, 03 Feb 2021 05:36:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=3QvI0EVC83VsqmigtjiZSQtcT5Klm9wxSpvPAx7Pch0=; b=xRiJjn9YzILiRMYwgn7yeabNQx2cYfIpSRv+Y1NmNj7mTnuq22qUdsm6aVhOJcy66I xIgYh472kmJ0PYQRx0rErg4UvzWpO1ul8O6l2XICr1rAMzHXSQHggnqXl0wiD7E1A15n rlfWCRM7/wkRkkaC3sC9Y24OpDpZmkkYXXM4Wdd48dYzzGHgBRYlerkSDyLgZpRNm5ho FrIYzvKglnkv4kTc+DxeDzFlz/LcblurQdq/l56AiXg2WfXhV27F63mwcnUQQIhGPgiX 1RsCFVZxvU4djBS3KV0Vp+2RXv0tedWaUkx3syyrGw6IbNOoixBiahxsJczijL/co+/P M1+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=3QvI0EVC83VsqmigtjiZSQtcT5Klm9wxSpvPAx7Pch0=; b=l9s/7qNLC4m05tL/5GivnmwVqR9XpHvFa5hQ6nYeKoMnU20+/SOkPxKz4OK/ni7xfy HyDEVXZVc/F/fFYKS256YN9idWwR+QmES9vIsehCf1TJmwruubQig7wW/JWXrZ70/sju +i1/VRVuAmHIVcBIZzK58LMuHsRKphyYZisZgmQFQ9yElvzU4Y6Pc12Ca8aqNRXIfONR dFCHnOJ3knhZqu9e43+NLkO/knJQGnzQP8FM0xjZ52n+GDK/s4egJiD4gZBSIcjy+6T1 P5ZxO3Ap3qyiErmFE7UQNc3mypeKiVcC3X6ZR+iRf7DYwdx1R1TYWVfppyxtLCc18dYy 99LQ==
X-Gm-Message-State: AOAM533HgN+8jcx7+lsPbDi5JJsg691u0vn4O6/eZ+4fJWzUdUPzMopz bZ8rgi4M/dEKLUn3w8Y5ygPA0w==
X-Google-Smtp-Source: ABdhPJyf4Y0mKTzviEkNhFTZojGPIu/5eGk3f5/q4viGT8U/6R7K9xTEedWj2InW2U0Yw5pxrz8Pkg==
X-Received: by 2002:a0c:be15:: with SMTP id k21mr2948698qvg.8.1612359371637; Wed, 03 Feb 2021 05:36:11 -0800 (PST)
Received: from okhta ( []) by with ESMTPSA id r44sm466493qtb.28.2021. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Feb 2021 05:36:10 -0800 (PST)
Date: Wed, 3 Feb 2021 08:36:04 -0500
From: Dmitri Tikhonov <>
To: Samuel Hurst <>
Subject: Re: QUICWG Temporary IANA Registry
Message-ID: <20210203133604.GA801221@okhta>
Mail-Followup-To: Samuel Hurst <>, IETF QUIC WG <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
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: Wed, 03 Feb 2021 13:36:14 -0000

Hi Sam,

On Wed, Feb 03, 2021 at 10:21:28AM +0000, Samuel Hurst wrote:
> I have a question with regards to the Temporary IANA Registry page
> hosted on the QUICWG GitHub wiki [1]. Is this page free for anyone to
> edit to add to, or only for drafts that have adoption? I'm working on a
> draft to add a new H3 frame type, and I'd like to make sure that I don't
> end up using a frame type code that someone else ends up using as well.

Yes: go ahead and add to it.

> A related question, but is there any restriction on what values an
> experimental extension may choose? I'm currently running on the
> assumption that it's not one listed in the temporary registry [1], a
> code point in the HTTP/2 registry [2], not part of the standards-action
> range 0x00-0x3f or one of the "MUST NOT be assigned" code points in the
> range of `0x1f * N + 0x21` as detailed by quic-http [3]. To that end,
> I'm currently thinking of using 0xD0F, would that be fine?

Yes, this value is fine.  (If you expect your extention to evolve and
the frame format to change, one approach is to use a different value
in your initial drafts, e.g 0xFF...D0F, while targeting 0xD0F to be
the final value.)  In any case, do add it to the list to call dibs.

  - Dmitri.