Re: [quicwg/base-drafts] How to reject a connection attempt (#3690)

Kazuho Oku <> Wed, 27 May 2020 05:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E6B93A0542 for <>; Tue, 26 May 2020 22:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Status: No, score=-1.697 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 aIdnFancaHKj for <>; Tue, 26 May 2020 22:35:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D26F03A00C0 for <>; Tue, 26 May 2020 22:35:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0F63B52110C for <>; Tue, 26 May 2020 22:35:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1590557718; bh=h7l6gbCVjXm/GjM3sObdH+Z8leH2W6ZMUzSITI1JFHc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=sMkUa8BxSu1PQNsdebzchdA9y9syuOLemUGJtb6O2UcqXGTmj0lzgmikZ1Kq3gKuF pU/TfztOM56s2nRjWEWVyCj+49uEKDdFP3alhf+bmjU8r5knhPELXTq3pEEqSqv3Io gLcXNOZsGvxuGSDmpA36N4lx/2o+mhkHa8QjS3JU=
Date: Tue, 26 May 2020 22:35:18 -0700
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3690/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] How to reject a connection attempt (#3690)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ecdfc16c35_5c773ff8e22cd95c81668c"; 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: Wed, 27 May 2020 05:35:21 -0000

I can see why this issue being classified as a design change, though at the same time, I think that #3694 was a good editorial change.

#3694 made things better。We now have an error code for server indicating that it rejected the connection even though nothing seemed to be wrong with the handshake. Without having CONNECTION_REFUSED_ERROR, a client had to guess if PROTOCOL_VIOLATION meant a problem in the handshake, or if it was simply a refusal.

>From now on, on this issue, I hope that we can concentrate on discussing if we want to have more than one error code indicating the specifics of connection refusals (e.g., SERVER_BUSY). Unsurprisingly, my position is that we cannot have specific codes due to the reasons laid out above.

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