RE: Negotiating extensions

With frame types being thin on the ground, I'd really hesitate to burn a frame type just to announce support.  But you're right -- if the same extension defines a state-changing and a non-state-changing frame, receiving the safe one is a reasonable signal that you're allowed to send the unsafe one, provided they're defined that way.

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Thursday, June 19, 2014 10:17 AM
To: Daniel Sommermann
Cc: Yutaka Hirano; Jeff Pinner; K.Morgan@iaea.org; HTTP Working Group; C.Brunhuber@iaea.org
Subject: Negotiating extensions

On 19 June 2014 09:17, Daniel Sommermann <dcsommer@fb.com> wrote:
> * A negotiated extension is active if
>     1) A SETTINGS frame with the extension setting enabled has been sent
>     2) A SETTINGS frame with the extension setting enabled has been received
>     3) A SETTINGS frame with the ack flag has been sent

(I think that you need to include "or received" on the last line to deal with the server side of this.  And it probably could be tightened a little better then, but the basic idea is right.)

That's how I might do an extension that required a positive signal from a peer.  However, there are other options that are equally valid, and I didn't really want to proscribe at this stage.

For instance, if I was doing the DNS hinting thing as an extension, the server might use a new frame type signal that it supports the extension, that might allow the client to start making queries regarding the state of the server cache, for example.  (I'm reaching here a little, but that's the nature of extensibility, sadly).

Received on Thursday, 19 June 2014 18:30:41 UTC