IETF Logo Mail Archive

#148: Reasonable Assurances and H2C

Mark Nottingham <mnot@mnot.net> Sat, 20 February 2016 02:21 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4021A1B29 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 19 Feb 2016 18:21:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 j0uD1jVO3TP4 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 19 Feb 2016 18:21:21 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811581A0083 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 19 Feb 2016 18:21:21 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aWx6T-0008Ln-Ew for ietf-http-wg-dist@listhub.w3.org; Sat, 20 Feb 2016 02:17:01 +0000
Resent-Date: Sat, 20 Feb 2016 02:17:01 +0000
Resent-Message-Id: <E1aWx6T-0008Ln-Ew@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1aWx6L-0008Jn-Q6 for ietf-http-wg@listhub.w3.org; Sat, 20 Feb 2016 02:16:53 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by maggie.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1aWx65-0003Ts-PI for ietf-http-wg@w3.org; Sat, 20 Feb 2016 02:16:52 +0000
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0BAB622E200 for <ietf-http-wg@w3.org>; Fri, 19 Feb 2016 21:16:12 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAC4RtVCCExJNE0y8480vC1W56NP4XhzfvLs+ASh1Qy-UcDPBNw@mail.gmail.com>
Date: Sat, 20 Feb 2016 13:16:09 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C2145C5A-0255-43F9-A44A-F6C7974CDD4C@mnot.net>
References: <20160209074851.32332.24065.idtracker@ietfa.amsl.com> <20160209182822.C37A959F@welho-filter2.welho.com> <B7164F24-DDA1-4753-8A8B-04809B1965FF@mnot.net> <CAC4RtVCCExJNE0y8480vC1W56NP4XhzfvLs+ASh1Qy-UcDPBNw@mail.gmail.com>
To: HTTP WG <ietf-http-wg@w3.org>
X-Mailer: Apple Mail (2.3112)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-8.2
X-W3C-Hub-Spam-Report: AWL=1.359, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1aWx65-0003Ts-PI 48ab23f3d5d63474984f57ff7bc46e53
X-Original-To: ietf-http-wg@w3.org
Subject: #148: Reasonable Assurances and H2C
Archived-At: <http://www.w3.org/mid/C2145C5A-0255-43F9-A44A-F6C7974CDD4C@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31079
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

I've created
  https://github.com/httpwg/http-extensions/issues/148
to track this.

I think removing h2c from the examples and clarifying the example as Kari explained (1 and 2 in the issue) are not controversial (verging on editorial).

The remaining question (3 in the issue) is whether we should firm up the definition of "reasonable assurances" to require another way of achieving that to be documented in an RFC that updates this one.

Mike B has already supported this approach; what do others think? 


> On 11 Feb 2016, at 2:48 PM, Barry Leiba <barryleiba@computer.org> wrote:
> 
>> I think Barry is about to start IETF LC on this, so if that happens, we'll
>> just consider this LC feedback.
> 
> And so it was started, and so you should consider it.
> 
> Barry

--
Mark Nottingham   https://www.mnot.net/

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