IETF Logo Mail Archive

Re: [quicwg/base-drafts] Make transport parameter ID and length varint (#3294)

Marten Seemann <notifications@github.com> Wed, 11 December 2019 05:29 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8321200FD for <quic-issues@ietfa.amsl.com>; Tue, 10 Dec 2019 21:29:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 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_24=1.618, 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7JcMrdF-GlZ for <quic-issues@ietfa.amsl.com>; Tue, 10 Dec 2019 21:29:39 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C2212002F for <quic-issues@ietf.org>; Tue, 10 Dec 2019 21:29:39 -0800 (PST)
Received: from github-lowworker-2ef7ba1.ac4-iad.github.net (github-lowworker-2ef7ba1.ac4-iad.github.net [10.52.16.66]) by smtp.github.com (Postfix) with ESMTP id C11B7960508 for <quic-issues@ietf.org>; Tue, 10 Dec 2019 21:29:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576042178; bh=1/dPHIEoJ0q7X4lCC06yJ8caYYLh0Us+p8doNOdtpps=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=FgHLSdc58jISgA3++/1zR32f8AR/jDdRs373ZxSAQOdA+RZ5uvUoOxzy7EVheaaJ0 2bypYYl1Qqrddm33D7iA3sgaFArNMuwWDTc1Rf6Cj6SmDEocMGBDGt3CLYQ3Pm+E5K J4JoDA60bc9DGbZ5NKRtc6FoBSIwVpZa20fB3aJA=
Date: Tue, 10 Dec 2019 21:29:38 -0800
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3FHPZLBR6PDHI7TMF37WYUFEVBNHHB72WFIM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3294/564386387@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3294@github.com>
References: <quicwg/base-drafts/issues/3294@github.com>
Subject: Re: [quicwg/base-drafts] Make transport parameter ID and length varint (#3294)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df07ec2b2054_54d13fd1c06cd9601324d3"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/-cgcdjnsiyLJYuPweygnLDUp3uQ>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2019 05:29:41 -0000

>  If that is the case, maybe we should start by first going back to the TLS notation?

If I remember correctly, the main argument for giving up on the TLS notation was improved readability for people who are not familiar with TLS representation language. From the viewpoint of consistency in encoding, switching back to it would definitely be an improvement though.
That being said, I still don't understand why TLS should be involved with the encoding of a value that it never treats as anything other than an opaque blob.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3294#issuecomment-564386387

v2.23.0 | Report a Bug | By Email