IETF Logo Mail Archive

draft-misell-quic-bdp-token is asking for codepoints

Martin Thomson <mt@lowentropy.net> Sun, 21 January 2024 22:51 UTC

Return-Path: <mt@lowentropy.net>
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 357A0C14F5F8 for <quic@ietfa.amsl.com>; Sun, 21 Jan 2024 14:51:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.805
X-Spam-Level:
X-Spam-Status: No, score=-2.805 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b="tAfu3JrI"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="iRFuBbX1"
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 pAhBi5Amp9UV for <quic@ietfa.amsl.com>; Sun, 21 Jan 2024 14:51:20 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 52C18C14F5EF for <quic@ietf.org>; Sun, 21 Jan 2024 14:51:20 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 511695C005E; Sun, 21 Jan 2024 17:51:19 -0500 (EST)
Received: from imap41 ([10.202.2.91]) by compute6.internal (MEProxy); Sun, 21 Jan 2024 17:51:19 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:subject:subject:to :to; s=fm1; t=1705877479; x=1705963879; bh=BMrBAISpZAWPRXn9Zx0Zx qRgtqgrFaseobaz2Zco5FI=; b=tAfu3JrIy+PJnsji7vMP3zGgT1gVQWEJ6M/1s O9uSWaoe1NBv3Gr+LJbUNco963qNTudINnJZpL8exvimOCjcgfubX1MDRrF8y8II WOY5SNEPIaCwbMqNwYT/YWewF7px6dvXV1kwZ0Ode52weu7c5xd3sMUQONp5Vf3Z XzMiHQ4xb54iWVNUt1yKvgr45LPbfZUebVdUkSwYOQ77+Js3A12Hlfp8cebARjeP ZaBNEBLZlSZiYwcc6QXIt7n3EIPam5oYseKPoJOWkumgL5zE4wlqaMZZjEhJoIXf e6V2WgpvnbABH3NNjHqIiQgiyQuDfoATpC/sHH1Conoc+OTxg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1705877479; x=1705963879; bh=BMrBAISpZAWPRXn9Zx0ZxqRgtqgrFaseoba z2Zco5FI=; b=iRFuBbX117QC7kd+4B21KX23LkoPavmKX63WiBZrpuItfE3h0Yp rfKnHboETa9vB3PF1w592cL1I5p1ojC2GojAv7831aY8xhF8bHJ80N/KwIeQgXEd qcAZtJuxFpKWggJY7sb2Q+R0p+AZiylAfv6zS4f5C2WzttjeOIb9xv0k9wVT5/Rv tUlg9kQAMFD/j3n4I/iP/XhdY8oNNmsXlxyznMZGgMK8wyWRqQYp1zyVI/4yQ0Xn MIPPRFytt0FToAolDsSaPx2ihVYZ5E/KQpLPlV/jvYb6ebzUuToxGL9neg7X/p+Y I4kHj9GulwLBu/dUO8fhmejwwMpMqKVQ2vA==
X-ME-Sender: <xms:5p-tZYiRbkUS76finIw6a2VpP90IPHj4tbrRH6hSV8UVkGEJacP82A> <xme:5p-tZRBDKkhZtxYTNRB2gcWSgB9ytwLlsQslmx-HwARyUMGHbGboHMFDMlr_7x3TM CVpwL_Qg_DoQKH_9As>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdekhedgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne goufhorhhtvggutfgvtghiphdvucdlgedtmdenucfjughrpefofgggkfffhffvvefutges thdtredtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtse hlohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhephfdtudeiiedvlefg teehkeegtdegteeigeeiieetheegveegvefhffehheevjeeknecuffhomhgrihhnpehivg htfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:5p-tZQFGX1yO-gHz1wqK0eZ_noKk8b1-MDJKHWKxBK7rjOiUaLRuIg> <xmx:5p-tZZQgRZmUD0XYli_LdqF5mk4TKFJSTzBPMlLtcLKWr9J515Xw2A> <xmx:5p-tZVybZ_p0SNUzd1kfBuoMZq_2LP7R1FdJh2WUKhXjKVIekBexVQ> <xmx:55-tZQ848PXgR7j2OVNwzcG1oHdSCUeTw_9W3BFRZ2lYUf2yfYKKuQ>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 957FA2340080; Sun, 21 Jan 2024 17:51:18 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1374-gc37f3abe3d-fm-20240102.001-gc37f3abe
MIME-Version: 1.0
Message-Id: <5661fdad-0f42-4aad-9765-dcbd5767ed43@betaapp.fastmail.com>
Date: Mon, 22 Jan 2024 09:50:58 +1100
From: Martin Thomson <mt@lowentropy.net>
To: quic@ietf.org, q@as207970.net, q@magicalcodewit.ch
Cc: Janardhan Iyengar <jri@fastly.com>, Ian Swett <ianswett@google.com>
Subject: draft-misell-quic-bdp-token is asking for codepoints
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/FRWhcVtFaHHhSaN9p6Jbq9cELTI>
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: Sun, 21 Jan 2024 22:51:25 -0000

https://datatracker.ietf.org/doc/html/draft-misell-quic-bdp-token

IANA has received a formal request related to this draft.  As far as I can tell, this is a different spelling of draft-kuhn-quic-bdpframe-extension, just with real code points specified.  The value chosen takes two bytes to encode, which is fine.

The draft is reasonably clear about how it operates.  It differs from draft-kuhn-quic-bdpframe-extension in that it uses NEW_TOKEN to communicate.  I don't see why implementations that operated this way couldn't interoperate.  That is, as far as interoperation is concretely necessary in this case, which is to say "not really".

As an expert on the registry, I've been asked to review this registration.  The fact that I think this is a bad idea is not a sufficient reason to reject the registration.  So I plan to let IANA know to go ahead.

Before I do, I'm inviting Q and the working group to discuss this idea.

Cheers,
Martin

v2.23.0 | Report a Bug | By Email