Making extensibility cheap
Martin Thomson <martin.thomson@gmail.com> Wed, 04 June 2014 00:03 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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60AC1A03AB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 3 Jun 2014 17:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.653
X-Spam-Level:
X-Spam-Status: No, score=-7.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 iz9n5AA-Uw31 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 3 Jun 2014 17:03:39 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A3B1A00C9 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 3 Jun 2014 17:03:39 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Wrydi-0008Oa-SD for ietf-http-wg-dist@listhub.w3.org; Wed, 04 Jun 2014 00:01:10 +0000
Resent-Date: Wed, 04 Jun 2014 00:01:10 +0000
Resent-Message-Id: <E1Wrydi-0008Oa-SD@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1WrydW-0008NG-0O for ietf-http-wg@listhub.w3.org; Wed, 04 Jun 2014 00:00:58 +0000
Received: from mail-wi0-f172.google.com ([209.85.212.172]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1WrydV-0003tF-4t for ietf-http-wg@w3.org; Wed, 04 Jun 2014 00:00:57 +0000
Received: by mail-wi0-f172.google.com with SMTP id hi2so7396178wib.11 for <ietf-http-wg@w3.org>; Tue, 03 Jun 2014 17:00:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=bv0K1P/hP22tMn/BZjOW3sUlNfQON38/FmEf5tFhy3c=; b=oDTbfHPNfS01i6Y3QcSF3a5avno+9Kigxwe6IJGaeLEJRkstH24DzVy/JssCfBxYxq f0EnzFXRg4id0lQqS2x194Ww5h8IxtnTozxcy6B5N2OokibDRMKns44RCXOOlqA0ZsXB w4VWQ0j7Cg4JJ7S+XwNJS0iZrtNfkCXxo7rGiYj1+/oZy+lmBPOHCD3HeRKwfwfmsnuj 1TuUeZKZJXf6MHN0ojlDIgVyLN2G9zs6S/96sKkdjj25YTAM38qcGXX/DzpMy0NPWe11 68dysE8eHnDdIDimBeA1183L06Ifb7tNFxOLN1IkoavV5+J0TyQ4TkJO6+Wj9pfGB9U6 3AUQ==
MIME-Version: 1.0
X-Received: by 10.180.72.243 with SMTP id g19mr37347961wiv.44.1401840030349; Tue, 03 Jun 2014 17:00:30 -0700 (PDT)
Received: by 10.194.51.134 with HTTP; Tue, 3 Jun 2014 17:00:30 -0700 (PDT)
Date: Tue, 03 Jun 2014 17:00:30 -0700
Message-ID: <CABkgnnU1zUg0G-bfvzO1vTtVH22evSn1Kw-AQnwvWQqtmnesQA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=209.85.212.172; envelope-from=martin.thomson@gmail.com; helo=mail-wi0-f172.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.724, 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 1WrydV-0003tF-4t d86114487ba17fdf56bed87ab32c620c
X-Original-To: ietf-http-wg@w3.org
Subject: Making extensibility cheap
Archived-At: <http://www.w3.org/mid/CABkgnnU1zUg0G-bfvzO1vTtVH22evSn1Kw-AQnwvWQqtmnesQA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/24075
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 been somewhat convinced by Mike Bishop's arguments for restoring extensibility[1]. What I find hard to swallow is the associated cost. I think that Mike's proposal could be trimmed further. So I'm going to take up the challenge. Here's what I think we absolutely need: 1. A way to negotiate the use of hop-by-hop extensions. 2. A way to carry end-to-end extensions. 3. Extensibility for settings, frames and error codes. To that end, here's my proposed reduction, which I think is largely keeping with the spirit of Mike's draft: Extensibility As Mike suggests, we can open a few IANA registries for business. That's text we can restore from old drafts. Easy. I agree that we need more space for settings than 8 bits, but I'm going to be aggressive and suggest that 16 bits is enough. We can reserve some portion of that space for mucking around (a quarter is what I'd suggest, but I don't care). End-to-end Here I'm going to suggest something far more limited than what Mike does. I think that we can get away with an end-to-end, flow controlled, ordered frame. A new frame type, modelled on Mike's should work here. The new frame type would include a 32-bit extension ID, for which we can open a registry; we could piggyback on the PEN registry (private enterprise number); or, we could recommend random selection. Again, I care not about these details and will go with what people seem to like most. We could do something more with optional flow control, optional end-to-end and optional ordering, but I think that is altogether too much optionality. I'm aware that forcing flow control here might be controversial, but I think that if we require intermediaries to forward this - and I think we have to - this is the only good option. Negotiation I think that this doesn't need a new "EXTENSIONS" frame, I think that we can use settings. Each peer can set a setting to indicate that they support feature X and if both support the feature, then the state-affecting components of that feature can be activated. Otherwise, all error codes map to INTERNAL_ERROR (or some new error code we define that has equivalent semantics, i.e., none); all unknown frame types are dropped; and all settings are ignored. Note that this is important. Unless you negotiate, only the special "EXTENSION" frame will traverse intermediaries. Advice Column Mike's draft offers good guidance for extension designers. I think we need to crib some of that text. Suggesting that an extension deal with translating to and from HTTP/1.1, or dealing with peers that don't support the extension is motherhood and apple pie. More important though is establishing the parameters for extension. Much of the above will need to reside in this section. I am going to try to turn out some proposed text for this on the plane tomorrow, in case this is what we decide to pursue. --Martin [1] in draft-bishop-http2-extension-frames
- Making extensibility cheap Martin Thomson
- Re: Making extensibility cheap James M Snell
- Re: Making extensibility cheap Tatsuhiro Tsujikawa
- Re: Making extensibility cheap Daniel Sommermann
- Re: Making extensibility cheap Matthew Kerwin
- Re: Making extensibility cheap Mike Bishop
- Re: Making extensibility cheap Mike Bishop
- Re: Making extensibility cheap Greg Wilkins
- Re: Making extensibility cheap Amos Jeffries
- Re: Making extensibility cheap Amos Jeffries
- Re: Making extensibility cheap Daniel Sommermann
- Re: Making extensibility cheap Tatsuhiro Tsujikawa
- Re: Making extensibility cheap Martin Thomson
- Re: Making extensibility cheap Greg Wilkins