Re: [quicwg/base-drafts] Allow application CONNECTION_CLOSE everywhere (#3446)

Kazuho Oku <> Mon, 10 February 2020 09:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18D2F12008C for <>; Mon, 10 Feb 2020 01:23:49 -0800 (PST)
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 mHBB8SlVbHiP for <>; Mon, 10 Feb 2020 01:23:47 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 734111200B6 for <>; Mon, 10 Feb 2020 01:23:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C52F46A11B3 for <>; Mon, 10 Feb 2020 01:23:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1581326626; bh=vfcT6d1mnyrOANAExvP7d6Ot0m899Xsfsv8LNwVfKkU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=MloF4J00fSMQwl6SVcvC+QiuhbHEQddTaqpOafv34p+yUoAlOKk7Ym0xjoaR8Mi1v cmfqxP7NjDQPlv7rnzZlXXpSyH6hpC9EFeAQcysZkOPZqeJLjG5NiJmRjl2VLxbKyK 6OaalMsIJqN9gKMt3cdwtUoa/HRi3PLR5o9nPjRs=
Date: Mon, 10 Feb 2020 01:23:46 -0800
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3446/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Allow application CONNECTION_CLOSE everywhere (#3446)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e412122b6206_4cb53f899a6cd960245399"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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, 10 Feb 2020 09:23:49 -0000

I am not sure if that is the correct thing to do.

IIRC, the reason we have limited use of application CONNECTION_CLOSE to 1-RTT is because the error code is part of the application protocol, and because the role of QUIC as a transport protocol is to provide "encryption" to the application protocol. That's what we agreed late last year, see #3158.

The flip side of allowing application close to be sent using Initial packets is that every application protocol using QUIC would be required to specify the error codes that can be sent using Initial packets or not, because the error code sent using an Initial packet would be observable.

I would argue that *that* would be a complexity.

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