IETF Logo Mail Archive

Re: [quicwg/base-drafts] Clarify HTTP/2 setting parameter reservation (#3955)

Mike Bishop <notifications@github.com> Mon, 10 August 2020 18:15 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 A83EC3A0A3D for <quic-issues@ietfa.amsl.com>; Mon, 10 Aug 2020 11:15:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level:
X-Spam-Status: No, score=-1.697 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 rQbBESjhGYnF for <quic-issues@ietfa.amsl.com>; Mon, 10 Aug 2020 11:15:26 -0700 (PDT)
Received: from out-26.smtp.github.com (out-26.smtp.github.com [192.30.252.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80FBB3A09F8 for <quic-issues@ietf.org>; Mon, 10 Aug 2020 11:15:26 -0700 (PDT)
Received: from github-lowworker-292e294.va3-iad.github.net (github-lowworker-292e294.va3-iad.github.net [10.48.102.70]) by smtp.github.com (Postfix) with ESMTP id C638B5E0044 for <quic-issues@ietf.org>; Mon, 10 Aug 2020 11:15:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1597083325; bh=olw8RS9TPbL9/ZIa4TQ2NQNb6OWEAdstzDzx1VAD5JE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=gvSZEpxVZnf7DV6p5kSQuzhx3dTYfclBW+I+lKkSEnWBQcVvIwclMEHeFhFs9+ZVM 8t3I9mSLQPQreXDJP19z+OqDwk5xCsqiAxhhzWBEcngQYzMehi7StAB+rvrgB6iqxW 20mCTO3/LSrpgoiBNOnGSSzdQge6KZx15YR76gsc=
Date: Mon, 10 Aug 2020 11:15:25 -0700
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZELYQJ7B6FTPZS6TV5HVX33EVBNHHCPHGA74@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3955/c671509132@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3955@github.com>
References: <quicwg/base-drafts/pull/3955@github.com>
Subject: Re: [quicwg/base-drafts] Clarify HTTP/2 setting parameter reservation (#3955)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f318ebdb6adc_bca16f816434f"; 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/ruKl0yLf5Db-L0naUyuWPgDwp04>
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, 10 Aug 2020 18:15:28 -0000

@martinthomson, that goes back to the discussion we had around stream vs. connection errors.  @kazuho's point, if I can summarize briefly, is that an intermediary might directly copy some things from its connection to the client onto its connection to the server, or vice versa.  That led to the logic of using connection errors for things _definitely_ generated by your peer; settings are definitely generated by the peer, which argues for "MUST error," while frames might have come from upstream.

However, I note that we currently don't specify whether receiving a reserved frame type is a stream or a connection error, so I've opened #3991 for that.

-- 
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/3955#issuecomment-671509132

v2.23.0 | Report a Bug | By Email