Re: New Version Notification for draft-bishop-http2-extension-frames-00.txt
James M Snell <jasnell@gmail.com> Sun, 10 November 2013 18:14 UTC
Return-Path: <ietf-http-wg-request@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 61CAE21F9E77 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 10 Nov 2013 10:14:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.462
X-Spam-Level:
X-Spam-Status: No, score=-10.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNOa7dx8KOgL for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 10 Nov 2013 10:14:22 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 22E9821E80CF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 10 Nov 2013 10:14:21 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1VfZV7-0000xI-36 for ietf-http-wg-dist@listhub.w3.org; Sun, 10 Nov 2013 18:12:45 +0000
Resent-Date: Sun, 10 Nov 2013 18:12:45 +0000
Resent-Message-Id: <E1VfZV7-0000xI-36@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1VfZUu-0000sd-D9 for ietf-http-wg@listhub.w3.org; Sun, 10 Nov 2013 18:12:32 +0000
Received: from mail-ob0-f178.google.com ([209.85.214.178]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1VfZUt-0003QN-Ip for ietf-http-wg@w3.org; Sun, 10 Nov 2013 18:12:32 +0000
Received: by mail-ob0-f178.google.com with SMTP id va2so3496836obc.9 for <ietf-http-wg@w3.org>; Sun, 10 Nov 2013 10:12:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=hf0O4TIWQWKmyKqpyK8DEOi3qWn75cIdm+pG5Hygw/w=; b=aTRIJ+/SAK2PfLFmL0od1hQ75pFpuJ24q1W93deJ1ikUuoMerhwJLtPCOSDfmWirbt ORTs900nMLLXEXnJD/A7AExMpfuB2hko6wzKKSIi1biWJrdFnOwVzGcGv3lCvuO7+TDI huFlyRYtcCYtUEdBDG+NEhJwgN2CgGagfE3LgfACifQvEHI+QHDmYF5Fx2rPxyiY31Eq LfeDARtzplVxS9Phsyxs499Qx+TDFnoe0Pio5WK923uTbdRicjVtJAxs+B2vk8JnddQ2 x4DBjRX0Hu3OxAHXox6LcGktLrcC1ETVhYFO7SJKgCehdzywKI3jYVQ4fiVNmC89E6ms F4bQ==
X-Received: by 10.182.71.82 with SMTP id s18mr21522254obu.9.1384107125348; Sun, 10 Nov 2013 10:12:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.124.137 with HTTP; Sun, 10 Nov 2013 10:11:45 -0800 (PST)
In-Reply-To: <33aa09afa0de40d3b7663343eef4903a@BY2PR03MB091.namprd03.prod.outlook.com>
References: <20131108191248.7092.81493.idtracker@ietfa.amsl.com> <22b40d443dcc474fb6a1ecd947e9fe9a@BY2PR03MB091.namprd03.prod.outlook.com> <CABP7Rbcp0EByWkjX=wZOREKfEwGN3hVm4gAe-bH2_dEpP5DpYg@mail.gmail.com> <CABP7Rbdv4QG-tBjyd5BR4-4OOzp-g9_NoTh-VOSg1Qw_18St7Q@mail.gmail.com> <33aa09afa0de40d3b7663343eef4903a@BY2PR03MB091.namprd03.prod.outlook.com>
From: James M Snell <jasnell@gmail.com>
Date: Sun, 10 Nov 2013 10:11:45 -0800
Message-ID: <CABP7Rbf29DCPnu_xuGbakGS43xGJd1ujtcJmLkY+jGBnm---gA@mail.gmail.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.214.178; envelope-from=jasnell@gmail.com; helo=mail-ob0-f178.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.713, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1VfZUt-0003QN-Ip 72209ae4d9a304e4067bb6d5ce46ec30
X-Original-To: ietf-http-wg@w3.org
Subject: Re: New Version Notification for draft-bishop-http2-extension-frames-00.txt
Archived-At: <http://www.w3.org/mid/CABP7Rbf29DCPnu_xuGbakGS43xGJd1ujtcJmLkY+jGBnm---gA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/20394
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>
On Fri, Nov 8, 2013 at 4:04 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote: > We discussed some of this at the Bellevue interim…. > > > > With regard to HbH vs. E2E: > > · End-to-end on stream zero isn’t possible, since there’s nowhere to > forward them > > · On-stream frames mix hop-by-hop and end-to-end > > In order to simplify the model, there was general consensus that we could > simplify this considerably by reducing it to two states: > > · Stream zero is hop-by-hop, and ignored if not understood > > · On-stream is end-to-end and may be dropped or forwarded > -1 on the "may be dropped". As I've mentioned before, silently dropping end-to-end frames could significantly impact the semantics of the stream data and could have very bad unintended side effects. The result is that end-to-end extension frames become impossible to rely upon. The better (and more reliable) option is to require that end-to-end frames are either passed through untouched or the stream is closed with an RST_STREAM if the endpoint does not intend to pass them along. > While I’m not inherently opposed to also allowing on-stream hop-by-hop > frames since the protocol has them, it does increase the handling complexity > some. > If the handling requirements are clearly articulated, there is no harm in allowing them. It would be clear: an unknown hop-by-hop frame on a stream could be dropped safely without changing the semantics of the end-to-end message. > > > With regard to your space partitioning idea, it doesn’t solve type > exhaustion. In fact, it exacerbates it since one type can be exhausted > while types still remain in the other half of the space. If we allow a mix > of E2E and HbH frames on-stream, I’d prefer a flag to the MSB approach. > I don't want to "solve" the type exhaustion because I'm not convinced that it's a problem in the long run. Keeping the extension space limited ought to discourage bad behavior. Using a flag is problematic for two reasons: (1) the flag value space is far more limited than the available type identifier space and (2) it would mean that a single frame type could be sent end-to-end OR hop-by-hop, potentially muddying the semantics significantly (an extension frame would need to clearly indicate what behavior is appropriate in either case). > > > The idea of having a private-use range for use during development followed > by registration and a shift to IANA-assigned values is an option, but given > that some of our numbers tend to broadly deploy things that are still under > active development, that complicates both the transition from the unassigned > to assigned versions and the ability of extensions to coexist. > Again, the limited value space ought to discourage bad behavior. - James > > > -----Original Message----- > From: James M Snell [mailto:jasnell@gmail.com] > Sent: Friday, November 8, 2013 12:13 PM > To: Mike Bishop > Cc: HTTP Working Group > Subject: Re: New Version Notification for > draft-bishop-http2-extension-frames-00.txt > > > > On Fri, Nov 8, 2013 at 12:06 PM, James M Snell <jasnell@gmail.com> wrote: > >> It's great to see work being done on the extension model but I'm not > >> convinced that the approach you suggest in this draft is the best way > >> forward. > >> > >> The approach that I would like to see is this: > >> > >> For Frames: > >> > >> 1. Clearly define the notion that some frames are *always* end-to-end, > >> while others are *always* hop-by-hop 2. Clearly differentiate these > >> types using the MSB of the frame type. > >> If the MSB is set, the frame is end-to-end 3. Specify that end-to-end > >> frames are *always* subject to flow control 4. Change the type of the > >> DATA frame to 0x80 5. Dedicate 10 frame types at the top of each range > >> (0xF5-FF and > >> 0x75-7F) as "private use" frame types that cannot be assigned by IANA. > >> 6. Require that end-to-end frames are only sent on open streams > >> (basically, whenever a DATA frame can be sent) > > > > Missed one: > > > > 7. Require that implementations ignore-but-forward unknown end-to-end > frames; while allowing them to ignore-and-drop unknown hop-by-hop frames... > with the option of signaling an error if they so choose. > > > > > >> > >> For Settings: > >> > >> Dedicate some portion of the possible range of settings as "private > >> use" that cannot be assigned by IANA > >> > >> - James > >> > >> On Fri, Nov 8, 2013 at 11:21 AM, Mike Bishop > >> <Michael.Bishop@microsoft.com> wrote: > >>> Since I was volunteered at the working group meeting to share this, > >>> here’s the current version of my draft. I will re-emphasize that > >>> this is strictly a strawman, and any suggestions on how to improve > >>> this are more than welcome. > >>> > >>> Sent from Windows Mail > >>> > >>> From: internet-drafts@ietf.org > >>> Sent: Friday, November 8, 2013 11:16 AM > >>> To: Mike Bishop > >>> > >>> > >>> A new version of I-D, draft-bishop-http2-extension-frames-00.txt > >>> has been successfully submitted by Mike Bishop and posted to the IETF > >>> repository. > >>> > >>> Filename: draft-bishop-http2-extension-frames > >>> Revision: 00 > >>> Title: Extension Frames in HTTP/2.0 > >>> Creation date: 2013-11-08 > >>> Group: Individual Submission > >>> Number of pages: 10 > >>> URL: > >>> http://www.ietf.org/internet-drafts/draft-bishop-http2-extension-fram > >>> es-00.txt > >>> Status: > >>> http://datatracker.ietf.org/doc/draft-bishop-http2-extension-frames > >>> Htmlized: > >>> http://tools.ietf.org/html/draft-bishop-http2-extension-frames-00 > >>> > >>> > >>> Abstract: > >>> This document describes a proposed modification to the HTTP/2.0 > >>> specification to better support the creation of extensions without > >>> the need to version the core protocol or invoke additional protocol > >>> identifiers. > >>> > >>> > >>> > >>> > >>> 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 > >>>
- New Version Notification for draft-bishop-http2-e… Mike Bishop
- Re: New Version Notification for draft-bishop-htt… James M Snell
- Re: New Version Notification for draft-bishop-htt… James M Snell
- Re: New Version Notification for draft-bishop-htt… Roberto Peon
- RE: New Version Notification for draft-bishop-htt… Mike Bishop
- Re: New Version Notification for draft-bishop-htt… James M Snell
- Re: New Version Notification for draft-bishop-htt… James M Snell
- Re: New Version Notification for draft-bishop-htt… Mike Bishop
- Re: New Version Notification for draft-bishop-htt… Nicolas Mailhot
- Re: New Version Notification for draft-bishop-htt… James M Snell
- Re: New Version Notification for draft-bishop-htt… Nicolas Mailhot