Date: Tue, 10 Dec 2019 06:33:48 -0800
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+AFTOJKYBTRLIXBFHLVV2XTF37TPUZEVBNHHB72M6BM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3293/review/329878258@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3293@github.com>
References: <quicwg/base-drafts/pull/3293@github.com>
Subject: Re: [quicwg/base-drafts] CONNECTION_CLOSE in Handshake too (#3293)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5defaccc38449_54393fb93facd9641217f3";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/DWoBCdGSqkDhHPRqHESh3aPir6s>


----==_mimepart_5defaccc38449_54393fb93facd9641217f3
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

ianswett commented on this pull request.



> @@ -2481,12 +2481,15 @@ have 1-RTT keys, so the endpoint SHOULD send CONNECTION_CLOSE frames in a
 Handshake packet.  If the endpoint does not have Handshake keys, it SHOULD send
 CONNECTION_CLOSE frames in an Initial packet.
 
-A client will always know whether the server has Handshake keys
-(see {{discard-initial}}), but it is possible that a server does not know
-whether the client has Handshake keys.  Under these circumstances, a server
-SHOULD send a CONNECTION_CLOSE frame in both Handshake and Initial packets
-to ensure that at least one of them is processable by the client.  These
-packets can be coalesced into a single UDP datagram (see {{packet-coalesce}}).
+A client will always know whether the server has Handshake keys (see
+{{discard-initial}}), but it is possible that a server does not know whether the
+client has Handshake keys.  Under these circumstances, a server SHOULD send a
+CONNECTION_CLOSE frame in both Handshake and Initial packets to ensure that at
+least one of them is processable by the client.  Similarly, a peer might be

This last ambiguity is only really a problem on the client side, because the client doesn't discard Handshake keys until after the server has already discarded them(so it couldn't send a close in Handshake anyway).

-- 
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/pull/3293#pullrequestreview-329878258
----==_mimepart_5defaccc38449_54393fb93facd9641217f3
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p><b>@ianswett</b> commented on this pull request.</p>

<hr>

<p>In <a href="https://github.com/quicwg/base-drafts/pull/3293#discussion_r356070094">draft-ietf-quic-transport.md</a>:</p>
<pre style='color:#555'>&gt; @@ -2481,12 +2481,15 @@ have 1-RTT keys, so the endpoint SHOULD send CONNECTION_CLOSE frames in a
 Handshake packet.  If the endpoint does not have Handshake keys, it SHOULD send
 CONNECTION_CLOSE frames in an Initial packet.
 
-A client will always know whether the server has Handshake keys
-(see {{discard-initial}}), but it is possible that a server does not know
-whether the client has Handshake keys.  Under these circumstances, a server
-SHOULD send a CONNECTION_CLOSE frame in both Handshake and Initial packets
-to ensure that at least one of them is processable by the client.  These
-packets can be coalesced into a single UDP datagram (see {{packet-coalesce}}).
+A client will always know whether the server has Handshake keys (see
+{{discard-initial}}), but it is possible that a server does not know whether the
+client has Handshake keys.  Under these circumstances, a server SHOULD send a
+CONNECTION_CLOSE frame in both Handshake and Initial packets to ensure that at
+least one of them is processable by the client.  Similarly, a peer might be
</pre>
<p>This last ambiguity is only really a problem on the client side, because the client doesn't discard Handshake keys until after the server has already discarded them(so it couldn't send a close in Handshake anyway).</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/quicwg/base-drafts/pull/3293?email_source=notifications&amp;email_token=AFTOJK6U6K5GICGZBBBGRGTQX6SEZA5CNFSM4JYUWZU2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCOUYV4Q#pullrequestreview-329878258">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AFTOJK6MKL3QACZ5C5JOZU3QX6SEZANCNFSM4JYUWZUQ">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AFTOJK7LU2TZ4AN3UMV3463QX6SEZA5CNFSM4JYUWZU2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCOUYV4Q.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/pull/3293?email_source=notifications\u0026email_token=AFTOJK6U6K5GICGZBBBGRGTQX6SEZA5CNFSM4JYUWZU2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCOUYV4Q#pullrequestreview-329878258",
"url": "https://github.com/quicwg/base-drafts/pull/3293?email_source=notifications\u0026email_token=AFTOJK6U6K5GICGZBBBGRGTQX6SEZA5CNFSM4JYUWZU2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCOUYV4Q#pullrequestreview-329878258",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
----==_mimepart_5defaccc38449_54393fb93facd9641217f3--