Frames that manipulate set-based peer state

As discussed in Berlin on Monday, it seems like a pattern of defining frame types that manipulate state on the other side of the connection is emerging.

For example, we have a few issues on the ORIGIN frame about this, CACHE_DIGEST has moved towards having multiple digests being valid for a given connection. If we adopt something to carry certificates in HTTP/2, there's an obvious need there too.

I don't think we're talking about inventing actual protocol infrastructure for manipulating sets of connection data in HTTP/2; that seems too heavyweight. Instead, the focus should be on defining common conventions, so that developers (and administrators, where necessary) don't have to re-learn slightly different concepts for each mechanism.

Make sense?

If so, a straw-man:

For a given FOO_FRAME type, each FOO_FRAME received adds* to the set of data specific to that frame type (e.g., adding type payload as a single value to the set, or adding a number of values; this is frame type-specific). The processing and use of the set data is (of course) frame type specific as well (e.g., wildcard handling).

There are a number of flags possible:

- CLEAR indicates that all state for that frame type (regardless of any subclassifications, etc.) must be discarded before processing the contents of the frame it occurs upon.
- REMOVE indicates that the member(s) carried in the payload must be removed from the set, if present; if not present, it/they have no effect.
- COMPETE indicates that the frame that carries it represents the complete, current state of the set at the time of sending, to help receiving implementations understand whether more frames are outstanding.


* subject to the REMOVE flag semantics

Mark Nottingham

Received on Tuesday, 19 July 2016 09:02:11 UTC