IETF Logo Mail Archive

Re: [quicwg/base-drafts] Remap STOPPING to something other than zero (#1804)

Kazuho Oku <notifications@github.com> Wed, 26 September 2018 15:52 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 9EBAA130ED7 for <quic-issues@ietfa.amsl.com>; Wed, 26 Sep 2018 08:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.456
X-Spam-Level:
X-Spam-Status: No, score=-8.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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_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 vJYIiw8jqJhN for <quic-issues@ietfa.amsl.com>; Wed, 26 Sep 2018 08:52:20 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FB3D130F7E for <quic-issues@ietf.org>; Wed, 26 Sep 2018 08:52:19 -0700 (PDT)
Date: Wed, 26 Sep 2018 08:52:18 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1537977138; bh=m4iUTuDDtFqmZ0lUmFsbq61s/R9GGR/rARH2u5H09Gs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=1dtF8bWs/30/d3bjOeFeJuB8yWhHMKsEwanEYgTakrO8nCmpenqWGfOnFkvBOQJvo anpRPm3xmUcGdsLX3EW3YT4ghU3vh9jKC3v7t/oMo1KbKFAjAsnJCpigi7TOLkbCJ6 tZqymbDlslpwHLxx+1gZrn4ir0sVXHCmzzKCfZiQ=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab72eba425323f181d18ec4ad87f1efa82c762dc2392cf0000000117c36d3292a169ce15b0cecf@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1804/424764689@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1804@github.com>
References: <quicwg/base-drafts/issues/1804@github.com>
Subject: Re: [quicwg/base-drafts] Remap STOPPING to something other than zero (#1804)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5babab32c41e1_4133f9e322d45b43482e"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/N4_oH9Y_OnUCFNZUlmfPcd-ghh0>
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: Wed, 26 Sep 2018 15:52:28 -0000

@nibanks Am I correct in assuming that you are *only* opposed to defining in the transport draft that the app_error_code of zero means NO_ERROR, and *not* opposed to changing `STOPPING` to some value other than zero?

IMO we can certainly leave the former up to each application protocol.

However the latter needs to be defined in the transport spec. due to the fact being that `STOP_SENDING` is an transport feature. We need to define an error code that indicates that a stream has been reset due to that frame being received. And considering the fact that HQ is going to have a NO_ERROR code, it is better to leave zero for NO_ERROR (note also that HTTP/2 defines NO_ERROR as zero).

-- 
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/1804#issuecomment-424764689

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