Re: Frames that manipulate set-based peer state

2016-07-19 18:01 GMT+09:00 Mark Nottingham <mnot@mnot.net>:
> 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.
>
> Thoughts?

Sounds fine to me, except for the fact that the granularity of a set
in this text is defined as: "all state for that frame type".

IMO, the granularity should be up to each draft.

In case of the current cache-digest draft, COMPLETE flag marks
completion of either the set of fresh or stale responses.
It should not cover _all state for that frame type_, since we are
likely to see clients sending a complete digest of fresh responses,
but not sending any digest of stale resources.

> * subject to the REMOVE flag semantics
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
>



-- 
Kazuho Oku

Received on Tuesday, 19 July 2016 10:01:03 UTC