IETF Logo Mail Archive

Re: [quicwg/base-drafts] Allow the Transport to Stop/Reset a Stream? (#3291)

Mike Bishop <notifications@github.com> Mon, 16 December 2019 22:13 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 3A3BD12093B for <quic-issues@ietfa.amsl.com>; Mon, 16 Dec 2019 14:13:53 -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 Qgj2ETmY6fxk for <quic-issues@ietfa.amsl.com>; Mon, 16 Dec 2019 14:13:51 -0800 (PST)
Received: from out-22.smtp.github.com (out-22.smtp.github.com [192.30.252.205]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97811120939 for <quic-issues@ietf.org>; Mon, 16 Dec 2019 14:13:51 -0800 (PST)
Date: Mon, 16 Dec 2019 14:13:50 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576534430; bh=8exQVylGlv6J45l+vgJrR2ghJnyZb3EGVBELiTZgssk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=1jFaSSTEEKtd4nXX2Ll6juxw4sIjiFPlPUfyyWeSAZF+VYmc3wwQzQXia2fAAte9X qOAAeAOPdWLBWlsvJ8pMF303M16/veSQHcI2T4krVR5W5GAo0900nUZzIOF6FG8dl4 BbglELdijexXMbD2wHdyLudJfHSCzaGw8y4BrBG0=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5ABPXCP7XGFIAT6654AU2B5EVBNHHB7WKXVY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3291/566268664@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3291@github.com>
References: <quicwg/base-drafts/issues/3291@github.com>
Subject: Re: [quicwg/base-drafts] Allow the Transport to Stop/Reset a Stream? (#3291)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df8019eaddf3_606b3fbf156cd96490242"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/ktT7j6g0ixD-DHXpFvR7tj7HX0U>
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: Mon, 16 Dec 2019 22:13:53 -0000

> The user should not be using a QUIC transport primitive to perform application behaviour. If they can't or don't want to shim it with an application mapping then this is a class of bug that will exist.

I'm not sure what you're suggesting here.  "The user" in this case is writing a client-server application that's talking over QUIC.  They're using a managed code base that gives them QUIC streams, just like it would give them a TCP stream.  What are you suggesting they should be doing instead?

I agree that this is kind of an awkward situation.  I think the best solution probably is passing an error code to the connection constructor, at least under the assumption that you need to abruptly close the stream rather than considering it simply to have ended.

-- 
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/3291#issuecomment-566268664

v2.26.15 | Report a Bug | By Email | System Status