FW: New Version Notification for draft-bishop-httpbis-extended-settings-00.txt

Mike Bishop <Michael.Bishop@microsoft.com> Mon, 13 June 2016 20:01 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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D6312D99C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 13 Jun 2016 13:01:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.447
X-Spam-Level:
X-Spam-Status: No, score=-8.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-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=microsoft.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 flF66G3LYVzl for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 13 Jun 2016 13:01:41 -0700 (PDT)
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 5496E12D60F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 13 Jun 2016 13:01:40 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bCXzH-000773-5E for ietf-http-wg-dist@listhub.w3.org; Mon, 13 Jun 2016 19:57:31 +0000
Resent-Date: Mon, 13 Jun 2016 19:57:31 +0000
Resent-Message-Id: <E1bCXzH-000773-5E@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 <Michael.Bishop@microsoft.com>) id 1bCXz6-00075r-6G for ietf-http-wg@listhub.w3.org; Mon, 13 Jun 2016 19:57:20 +0000
Received: from mail-bn1bon0148.outbound.protection.outlook.com ([157.56.111.148] helo=na01-bn1-obe.outbound.protection.outlook.com) by maggie.w3.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <Michael.Bishop@microsoft.com>) id 1bCXz4-0002h1-B4 for ietf-http-wg@w3.org; Mon, 13 Jun 2016 19:57:19 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IZmtXvxZdi2+nwsBo9X650T2vUan/qKw21cWWJjh6qQ=; b=Ox2Vm+6+FdCtFEn7T74dQbB4f3CCK6DiKVEwKqij8cOwYAPUQMZLtkSTzZYCfhOcJas0iiVZniZinRVAq7c7yu6i5PAw7v/2lMx+Eo8DPAGsVUht9bWHebkwKrN0kqqaAkcOyZMfKHWeKEpOxTtQA+CNoWkW60TUbeOvz9iKSoQ=
Received: from BL2PR03MB1905.namprd03.prod.outlook.com (10.164.115.25) by BL2PR03MB1908.namprd03.prod.outlook.com (10.164.115.28) with Microsoft SMTP Server (TLS) id 15.1.501.3; Mon, 13 Jun 2016 19:56:51 +0000
Received: from BL2PR03MB1905.namprd03.prod.outlook.com ([10.164.115.25]) by BL2PR03MB1905.namprd03.prod.outlook.com ([10.164.115.25]) with mapi id 15.01.0492.024; Mon, 13 Jun 2016 19:56:51 +0000
From: Mike Bishop <Michael.Bishop@microsoft.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Thread-Topic: New Version Notification for draft-bishop-httpbis-extended-settings-00.txt
Thread-Index: AQHRxauhJROLNbS/KUalU4gT/ExvBZ/nzR1w
Date: Mon, 13 Jun 2016 19:56:51 +0000
Message-ID: <BL2PR03MB1905852D993AF0E68FA1C80087530@BL2PR03MB1905.namprd03.prod.outlook.com>
References: <20160613194147.6928.68990.idtracker@ietfa.amsl.com>
In-Reply-To: <20160613194147.6928.68990.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com;
x-originating-ip: [2001:4898:80e8::390]
x-ms-office365-filtering-correlation-id: b7c430c3-46e5-474a-636f-08d393c4dcb4
x-microsoft-exchange-diagnostics: 1; BL2PR03MB1908; 5:3bH8bzf4JQewSDdWI4PmXzlIOe/Fs9CMAYj86snuTbr3kFks9mfhP4/keTqv/cMqZj24bQaThd7c7ISkv5ycJXkjB4xiUkvFoP9haj36J5gdbKfrY6pJ5zBmYwClOSxmT/M4X5XrTuZF3ZEk0l3MlQ==; 24:FNWlO786jZTwCtrzUr30DEx/tdiqaeflo9EQH0hu83lQXu7KyJcd4f8O/HeyCdKvNLt/nEmTx/6aeVkd8DpYgil5GIKg7jZK0ERkjLMdHn8=; 7:sJphtr+TggTEOoE/nwl+SOUzS89mDIyzGlwQ+y0QdVmCOxCtUhGM4wx0IgCsYH+VRMAg9VnRvqQ+pGoBCpKs+sjx1/21vBXpRy6W3a9VK405XItaWgu9TsyFJs71O8acZlRhC6O9+7w2BCg1qozMp+2mxtjWVldlAU6gKsHkRdTN4ZDCgif9jdcfHna8LAeHivjzq2Q+7WuD+XrIYu912MAJKVa+6pXKEVu+DXRfiPA=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB1908;
x-microsoft-antispam-prvs: <BL2PR03MB1908CA76EE0F90DD7D9D241F87530@BL2PR03MB1908.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BL2PR03MB1908; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB1908;
x-forefront-prvs: 0972DEC1D9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(377424004)(377454003)(13464003)(2950100001)(105586002)(6116002)(97736004)(5005710100001)(99286002)(15975445007)(2900100001)(450100001)(102836003)(86362001)(19580395003)(586003)(230783001)(5003600100002)(110136002)(10090500001)(10290500002)(5002640100001)(19580405001)(101416001)(86612001)(106116001)(68736007)(92566002)(5008740100001)(76176999)(74316001)(54356999)(10400500002)(77096005)(76576001)(81156014)(33656002)(122556002)(8936002)(2906002)(3660700001)(106356001)(189998001)(8990500004)(50986999)(3280700002)(107886002)(87936001)(81166006)(5004730100002)(15650500001)(8676002)(11100500001)(9686002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB1908; H:BL2PR03MB1905.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2016 19:56:51.4585 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB1908
Received-SPF: pass client-ip=157.56.111.148; envelope-from=Michael.Bishop@microsoft.com; helo=na01-bn1-obe.outbound.protection.outlook.com
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: AWL=-2.441, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: maggie.w3.org 1bCXz4-0002h1-B4 6bf55c85725abba3d5a1922658addef2
X-Original-To: ietf-http-wg@w3.org
Subject: FW: New Version Notification for draft-bishop-httpbis-extended-settings-00.txt
Archived-At: <http://www.w3.org/mid/BL2PR03MB1905852D993AF0E68FA1C80087530@BL2PR03MB1905.namprd03.prod.outlook.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31728
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>

During our internal conversations about the certificates draft, the question that keeps coming up is why we can't just reuse the existing IANA registries for signing methods and such instead of defining a custom bitmask of supported algorithms.  It would make new crypto developments not require a document at the HTTP layer, it would make it easier to share parsing code between layers (and thus put maintenance in the hands of people who specialize in security code), and just generally looks cleaner than a bitmap.

But SETTINGS carries 32 bits per setting.  To do that, we'd have to add one more frame to the certificates draft (say, a CERTIFICATE_SETTINGS).  Or we need a SETTINGS frame that doesn't tie us to 32 bits, which seems strictly better as it can be reused in the future.  This draft defines the second option as an EXTENDED_SETTINGS frame, borrowing a lot from the RFC 7540 SETTINGS text.  (The ACK methodology is a little bit different, in that it allows the sender to choose whether an ACK is needed, and allows the recipient to declare understood/not-understood in the response.)

Feedback welcome, particularly around whether this would have utility for other folks. This is currently on a separate branch in the same repo as the certificate draft.

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: Monday, June 13, 2016 12:42 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Subject: New Version Notification for draft-bishop-httpbis-extended-settings-00.txt


A new version of I-D, draft-bishop-httpbis-extended-settings-00.txt
has been successfully submitted by Mike Bishop and posted to the IETF repository.

Name:		draft-bishop-httpbis-extended-settings
Revision:	00
Title:		HTTP/2 Extended SETTINGS Extension
Document date:	2016-06-13
Group:		Individual Submission
Pages:		8
URL:            https://www.ietf.org/internet-drafts/draft-bishop-httpbis-extended-settings-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bishop-httpbis-extended-settings/
Htmlized:       https://tools.ietf.org/html/draft-bishop-httpbis-extended-settings-00


Abstract:
   HTTP/2 defines the SETTINGS frame to contain a single 32-bit value
   per setting.  While this is sufficient to convey everything used in
   the core HTTP/2 specification, some protocols will require more
   complex values, such as arrays of code-points or strings.

   For such protocols, this extension defines a parallel to the SETTINGS
   frame, EXTENDED_SETTINGS, where the value of a setting is not a
   32-bit value, but a variable-length opaque data blob whose
   interpretation is subject entirely to the definition of the protocol
   using it.

                                                                                  


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat