Re: #540: "jumbo" frames

On Jun 25, 2014, at 3:00 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 25 June 2014 12:30, Patrick McManus <pmcmanus@mozilla.com> wrote:
>> I don't think that's the case at all. un-acked extensions are limited that
>> way because you can't change the semantics of the protocol.. but once you
>> ack something you can do anything you like - including changing framing to
>> look like websockets via use one of the R bits (as an example). Go bootstrap
>> h3 that way if you feel so inclined to write an extension like that.
>> 
>> but maybe I have that wrong -(our extension text is brand new afterall) and
>> extensions are meant to preclude such hackery which seems odd - given they
>> are essentially a hackery escape hatch that already acknowledges the ability
>> to change semantics of existing elements. If that's true there is always the
>> alpn method of proving this can work - because I really don't think it can
>> work and leave h2 responsive.
> 
> You have it right.  Once you get mutual agreement to use an extension,
> that extension only needs to worry about the synchronization point at
> which you change anything and everything.  Here's a basic strawman:
> 
> New setting X, 0 = off (initial), 1 = on.  Once a setting has been set
> to "on" on both sides and been acknowledged, you can enable the use of
> the reserved bits, exactly as PHK has described.  If a peer uses the
> extension prior to both acknowledging the settings and sending their
> own setting enabling the setting, you are entitled to treat that as an
> error.

That wasn’t clear to me in the text, thank you for clarifying the intention.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Wednesday, 25 June 2014 20:31:50 UTC