W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Making extensibility cheap

From: James M Snell <jasnell@gmail.com>
Date: Tue, 3 Jun 2014 17:34:24 -0700
Message-ID: <CABP7RbfETyGdT8hQK=Tf1D5Lak4QgOzKT8jNnSarhovJ9hA43w@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
+1. Happy to see this finally being properly addressed.
On Jun 3, 2014 5:04 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:

> 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
Received on Wednesday, 4 June 2014 00:34:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC