W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Negotiating extensions

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 19 Jun 2014 10:16:56 -0700
Message-ID: <CABkgnnWafZam7aetk0m22JK=UpX4tz4Gv=bN5Vyf=m+uTfkQTw@mail.gmail.com>
To: Daniel Sommermann <dcsommer@fb.com>
Cc: Yutaka Hirano <yhirano@google.com>, Jeff Pinner <jpinner@twitter.com>, "K.Morgan@iaea.org" <K.Morgan@iaea.org>, HTTP Working Group <ietf-http-wg@w3.org>, "C.Brunhuber@iaea.org" <C.Brunhuber@iaea.org>
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 17:17:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC