- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 25 Jun 2014 13:00:51 -0700
- To: Patrick McManus <pmcmanus@mozilla.com>
- Cc: Jason Greene <jason.greene@redhat.com>, Nicholas Hurley <hurley@todesschaf.org>, Mark Nottingham <mnot@mnot.net>, "K.Morgan@iaea.org" <K.Morgan@iaea.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Willy Tarreau <w@1wt.eu>, Greg Wilkins <gregw@intalio.com>, IETF HTTP WG <ietf-http-wg@w3.org>, Martin Dürst <duerst@it.aoyama.ac.jp>
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.
Received on Wednesday, 25 June 2014 20:01:20 UTC