Subject: Frames that manipulate set-based peer state

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Jul 2016 11:01:30 +0200

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?

* subject to the REMOVE flag semantics

--
Mark Nottingham   https://www.mnot.net/

---

From: Martin Thomson <[email-masked]>
Date: Tue, 19 Jul 2016 11:22:39 +0200

> - 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 out…

or is it the LAST message and that the accumulated state represents
the entire set?

and *COMPLETE

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Jul 2016 11:27:26 +0200

> On 19 Jul 2016, at 11:22 AM, Martin Thomson <[email-masked]> wrote:
> 

I think we're talking about the difference between:

a) indicating that, as of time of generation, the frames sent represent a complete set, but that it might be added to later
b) indicating that the set is complete for the rest of the lifetime of the connection

Correct?

If so, (b) seems like the client is committing to never change the set after a certain point, with the only recourse being GOAWAY. I crafted (a) like it is because I think the intent is to avoid a recipient using the set when more are in flight towards it; of course, it doesn't completely avoid the race condition, it's more like a hint.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 19 Jul 2016 11:28:43 +0200

> b) indicating that the set is complete for the rest of the lifetime of the connection

No, I was trying to avoid the implication that the frame contains ALL
of the set.  I think that it is more useful to indicate that this is
the end of the series of frames.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Jul 2016 11:31:47 +0200

Ah - so you're just suggesting a change in name, not semantics?

> On 19 Jul 2016, at 11:28 AM, Martin Thomson <[email-masked]> wrote:
>

---

From: Patrick McManus <[email-masked]>
Date: Tue, 19 Jul 2016 11:38:17 +0200

alt-svc has a special case where it likes to have h1 header equivalency.
I'm not sure if that will be common or not.. [a] from mark's explanation
seems to be a reasonable map there.

question: what to do with the consensus wisdom on this topic (if there is
some).. potential rfc, or rather wiki material?

On Tue, Jul 19, 2016 at 11:28 AM, Martin Thomson <[email-masked]>
wrote:

> > a) indicating that, as of time of generation, the frames sent represent
> a complete set, but that it might be added to later

---

From: Martin Thomson <[email-masked]>
Date: Tue, 19 Jul 2016 11:43:43 +0200

> some).. potential rfc, or rather wiki material?

Implement that consensus a couple of times.  Try to remember to force
others to follow the same pattern.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 19 Jul 2016 11:43:02 +0200

> Ah - so you're just suggesting a change in name, not semantics?

Yeah, well, the semantics are unclear if you use the wrong name.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Jul 2016 11:45:44 +0200

+1

I'll put it on a wiki page so that we remember, and to allow martin to clarify if he so chooses.

> On 19 Jul 2016, at 11:43 AM, Martin Thomson <[email-masked]> wrote:
>

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 19 Jul 2016 19:00:24 +0900

> - 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 out…

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.

-- 
Kazuho Oku

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 19 Jul 2016 10:01:16 +0000

Would this proposal be applicable (retroactively) to any of the standard H2 frame types or is it limited to extension frames. 

I think I know the answer to this already. The question perhaps arises from the phrase "manipulate state on the other side of the connection", what is the scope of that?

Lucas
________________________________________
From: Mark Nottingham [[email-masked]]
Sent: 19 July 2016 10:01
To: HTTP Working Group
Subject: Frames that manipuvlate set-based peer state

Make sense?

If so, a straw-man:

Thoughts?

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 Jul 2016 11:34:48 +0200

It's a wiki:
  https://github.com/httpwg/wiki/wiki/SetManipulation

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 Jul 2016 13:52:46 +0200

It'd just be a convention for new frame types to adopt; not something that lives on its own.

> On 19 Jul 2016, at 12:01 PM, Lucas Pardue <[email-masked]> wrote:
>