Re: [quicwg/base-drafts] Clearer text for application errors (#3226)

Mike Bishop <> Tue, 12 November 2019 18:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5E8B12008A for <>; Tue, 12 Nov 2019 10:12:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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_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 P5gjtoyzRtMR for <>; Tue, 12 Nov 2019 10:12:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D981D12084D for <>; Tue, 12 Nov 2019 10:12:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 391361C03BF for <>; Tue, 12 Nov 2019 10:12:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1573582375; bh=eLcCrQ/2o/PlmM2gmzKrOlgr5Y/eqTvPfCwp2Qkz4iY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Xgr3hj8eG0ZwzufxO20YlctPr/h6GmsDrNMSDT+koQ8PB5h42WDfps5X4o/SYFPnX WYstCwoAmgS+BmBtLyOj6aLN0Q/EFUsPzwRBoQXU7EeAL8fhlBt89Sba9+BpySU2jd GnwzOcxC3h659IBRpjxVzTMPzPGEnQChsW3RHMyw=
Date: Tue, 12 Nov 2019 10:12:55 -0800
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3226/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Clearer text for application errors (#3226)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dcaf6272a70f_56073fae3e6cd96035584c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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: Tue, 12 Nov 2019 18:12:58 -0000

MikeBishop commented on this pull request.

> @@ -2720,17 +2720,19 @@ connection in a recoverable state, the endpoint can send a RESET_STREAM frame
 ({{frame-reset-stream}}) with an appropriate error code to terminate just the
 affected stream.
-RESET_STREAM MUST be instigated by the protocol using QUIC.  RESET_STREAM
-carries an application error code.  Only the application protocol is able to
+RESET_STREAM MUST be instigated by the application protocol that uses QUIC.

RESET_STREAM MUST only be instigated by the application protocol that uses QUIC.
@mikkelfj is right -- in isolation, this reads like a requirement on the application, not a restriction on everyone else.

>  cause a stream to be terminated.  A local instance of the application protocol
 uses a direct API call and a remote instance uses the STOP_SENDING frame, which
 triggers an automatic RESET_STREAM.
-Resetting a stream without knowledge of the application protocol could cause the
-protocol to enter an unrecoverable state.  Application protocols might require
-certain streams to be reliably delivered in order to guarantee consistent state
-between endpoints.  Application protocols SHOULD define rules for handling
-streams that are prematurely cancelled by either endpoint.
+Resetting a stream without the involvement of the application protocol could
+cause the application protocol to enter an unrecoverable state.  Application
+protocols might require certain streams to be reliably delivered in order to

It's the "critical stream" idea from HTTP/3 -- if you blow up a request stream, the HTTP connection is fine.  If you blow up a QPACK stream, the connection dies in flames.  Some streams are application-critical, and only the application knows which, so only the application can decide which streams to kill.  In a transport world, though, "reliably delivered" brings up different overtones.  Maybe "Resetting certain streams could disrupt the consistency of application-layer state between the endpoints."?

As to confusion, this is the rationale for the restriction in the previous paragraph.  Maybe putting the rationale first and following with "Therefore, RESET_STREAM MUST only be instigated...." would help?

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