Re: Making extensibility cheap

+1. Overall this reduction and the direction of the original proposal 
are looking great.

Martin, to just use SETTINGS to negotiate, are you implying that the 
extension takes effect for all frames sent after the SETTINGS-ack, as 
long as both the previously sent SETTINGS and the received SETTINGS 
contain the extension?

I am curious to first see some use cases for end-to-end extensions though.

I agree with the original proposal that ALTSVC and DATA gzip compression 
would be good candidates to move to extensions.

On 06/03/2014 08:00 PM, Martin Thomson 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 03:32:23 UTC