Re: [quicwg/base-drafts] Ambiguous wording about error codes in HTTP/3 (#3276)

Mike Bishop <notifications@github.com> Mon, 16 December 2019 16:01 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 003BC120020 for <quic-issues@ietfa.amsl.com>; Mon, 16 Dec 2019 08:01:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Level:
X-Spam-Status: No, score=-6.596 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_28=1.404, 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 hKq7Hj_tSpQU for <quic-issues@ietfa.amsl.com>; Mon, 16 Dec 2019 08:01:15 -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 482FA12006D for <quic-issues@ietf.org>; Mon, 16 Dec 2019 08:01:15 -0800 (PST)
Received: from github-lowworker-943b171.ac4-iad.github.net (github-lowworker-943b171.ac4-iad.github.net [10.52.22.59]) by smtp.github.com (Postfix) with ESMTP id 27E51A006F for <quic-issues@ietf.org>; Mon, 16 Dec 2019 08:01:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576512073; bh=MRDwo90mWBjB3YbYIM78PpXgTfsg5KtdmRV1f0hLu50=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=dkBIki1j1xL7hAl0g4jlv0sxEHXQwWAfthNDzhECjyf/csYRrUcK+RpzD/jwKbXCa BzzoM+DHu/ffcnQTm31szf8UMtf1+YSDYU0uXhWvk02FWxyLu6e9Rul1KYNmxj6neR 8D/PX+i5muROevvOLLjqXiRXqszdDYS7lOcp1BJI=
Date: Mon, 16 Dec 2019 08:01:13 -0800
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2WRYQVTTM5IPRB6XV4ATOMTEVBNHHB7DNHSM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3276/566123868@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3276@github.com>
References: <quicwg/base-drafts/issues/3276@github.com>
Subject: Re: [quicwg/base-drafts] Ambiguous wording about error codes in HTTP/3 (#3276)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df7aa4916c83_20123fd3cc2cd96063220"; 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/HhdxaQs5cg6tb9ffM5D7fy-5zcA>
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 16:01:17 -0000

1a/1b are two sides of the same coin.  Because error codes are extensible, a future document might define a new error code, or might prescribe the use of an existing error code in a new circumstance.  Therefore, the takeaway should be:

- An error code the recipient knows in an situation where they expect it has understood semantics that the recipient can act on.
- An unknown error code, or an error code in an unexpected situation, has semantics which the recipient does not understand and cannot act on.

The statement here is that the second case is not a violation of the protocol by the peer; you know the stream (or connection) is closing even if you don't understand why.  The admonition is to respond to the closure itself, not the unknown semantics of why it was closed.

While I agree that both versions of the second case follow from Section 9, I think it's useful to mention them in the context of error handling as well.  We've seen recently with HTTP/2 what happens when the possibility of extension values isn't mentioned/considered in the description of how the base-protocol pieces are to be handled.

-- 
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/3276#issuecomment-566123868