Re: Making extensibility cheap

[James M Snell <[e-mail]>]

+1. Happy to see this finally being properly addressed.
On Jun 3, 2014 5:04 PM, "Martin Thomson" <[e-mail]> 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
>
>