Re: New Version Notification for draft-bishop-http2-extension-frames-00.txt
James M Snell <jasnell@gmail.com> Sun, 10 November 2013 19:22 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 518A021E80D8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 10 Nov 2013 11:22:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.467
X-Spam-Level:
X-Spam-Status: No, score=-10.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 IWLhQ6DlfX1X for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 10 Nov 2013 11:22:25 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id D46EF11E8108 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 10 Nov 2013 11:22:24 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1VfaYv-000481-UI for ietf-http-wg-dist@listhub.w3.org; Sun, 10 Nov 2013 19:20:45 +0000
Resent-Date: Sun, 10 Nov 2013 19:20:45 +0000
Resent-Message-Id: <E1VfaYv-000481-UI@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 1VfaYm-00045e-ER for ietf-http-wg@listhub.w3.org; Sun, 10 Nov 2013 19:20:36 +0000
Received: from mail-ob0-f169.google.com ([209.85.214.169]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1VfaYl-00057D-5i for ietf-http-wg@w3.org; Sun, 10 Nov 2013 19:20:36 +0000
Received: by mail-ob0-f169.google.com with SMTP id wn1so2899140obc.14 for <ietf-http-wg@w3.org>; Sun, 10 Nov 2013 11:20:09 -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=DSpcDhQKh4MPigDjPs6g2qR7DZPpctIpxREAjG+VOEo=; b=ZiOAY1l/jS3H5F28/nJHpyTgbApQ9lTR/7xt0SVDEjKMbciMbUgF6Eknc9ZhhhXwkQ B4NzKPSUtbc5gIUR6BRp9F9tw56+g9Byccic2J8NgJmh6YM55D669bVy6QA96aLL2Vt/ xUluKKvUxN3dVq3/7dkj4M5vBu2SWGQd2bpyNU65BzLmokzFOnfbDXVWBGpBTYfR/8nb 2pbdH2aFmzgZG9LWSm8mSzMOpbBDbV5gGxB2sJwUKlb5j2a75sKFxGnCCSY6fGUfl5rV yvGnamjm2VS4LttF+TOZEgLbb4/RUDZroJKAX1eJjGD/QGT69wr40cazltnHTiEof8u5 CPKw==
X-Received: by 10.60.76.72 with SMTP id i8mr21521491oew.11.1384111208806; Sun, 10 Nov 2013 11:20:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.124.137 with HTTP; Sun, 10 Nov 2013 11:19:48 -0800 (PST)
In-Reply-To: <22b40d443dcc474fb6a1ecd947e9fe9a@BY2PR03MB091.namprd03.prod.outlook.com>
References: <20131108191248.7092.81493.idtracker@ietfa.amsl.com> <22b40d443dcc474fb6a1ecd947e9fe9a@BY2PR03MB091.namprd03.prod.outlook.com>
From: James M Snell <jasnell@gmail.com>
Date: Sun, 10 Nov 2013 11:19:48 -0800
Message-ID: <CABP7RbccXRp3ux4-b1U8k_JFSS=6++C2kZ0ZgKMoLNg9xr8-Jw@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.169; envelope-from=jasnell@gmail.com; helo=mail-ob0-f169.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.707, 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 1VfaYl-00057D-5i 02f0e6116d665dbb36868a46ef86645a
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/CABP7RbccXRp3ux4-b1U8k_JFSS=6++C2kZ0ZgKMoLNg9xr8-Jw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/20395
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>
A few additional specific comments: 1. re: BASE_SPECIFICATION_ONLY ... this is currently underspecified in the draft. Let's suppose my client establishes a stream that "travels" through two intermediate hops on it's way to the server. The path determined dynamically by the intermediaries. The first intermediary allows end-to-end extension frames to pass through, but the second intermediary does not and sends BASE_SPECIFICATION_ONLY. What should the first intermediary do if it receives extension frames from the client? Obviously, it cannot send those but there is nothing in the draft that describes exactly how the intermediary ought to handle it. a. Should it just silently drop any extension frames it receives from the client without notification. The problem being, of course, that the client would have no idea that it's complete message is not getting through b. Should it update it's settings with the client and say BASE_SPECIFICATION_ONLY, while silently dropping any extension frames it may have already received? The problem with this, of course, is that it terminates that clients ability to send extension frames through that first intermediary to any other endpoint that might not have the BASE_SPECIFICATION_ONLY requirement. c. Should it RST_STREAM the stream with the client letting it know that the extension frames could be passed on? (IMHO, (c) is obviously the best choice) 2. re: Flow control ... are end-to-end extension frames subject to flow control, and if not, why not? 3. Strongly feel that the use of Private enterprise numbers as a namespacing mechanism for extensions is going to encourage abuse and non-standardization of protocol extensions. Specifically, it allows specific vendors the ability to define, deploy and maintain their own proprietary protocol extensions without any pressure whatsoever to take things through standardization. IMHO, that's fairly dangerous. Having a limited extension space with very clear processing requirements is a significantly better option. 4. A compromise approach here would be to utilize both of the approaches suggested by myself and Mike's draft. Specifically: a. Segment the existing frame type space into end-to-end and hop-by-hop as I have suggested, b. Define that hop-by-hop frames MUST either be passed through untouched or RST_STREAM returned, c. Define that *all* hop-by-hop frames are subject to flow-control, d. Define that extension end-to-end frames MUST NOT change session state and can be silently dropped. e. Define a new INFO frame type that can always be silently dropped. The structure of the INFO frame would essentially be the same as Mike suggests in his draft. The INFO frame would be hop-by-hop, with the intermediary having the ability to decide whether or not to forward those on (like we currently do with PUSH_PROMISE). This would be a much more robust and reliable approach. - 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-frames-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