Subject: Binary Messages

From: "Martin Thomson" <[email-masked]>
Date: Wed, 11 Aug 2021 10:19:52 +1000

Hey everyone,

I just submitted an updated proposal for a simple binary message format for HTTP.

https://datatracker.ietf.org/doc/html/draft-thomson-http-binary-message-01
Live editors copy: https://unicorn-wg.github.io/oblivious-http/draft-thomson-http-binary-message.html

We're forming a working group for doing oblivious HTTP and this is a dependency of that.  That group might be good for the crypto pieces, but this is pure HTTP magic.  I'd like to talk about adopting this work here.

Cheers,
Martin

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Aug 2021 12:42:57 +0200

> We're forming a working group for doing oblivious HTTP and this is a dependency of that.  That group might be good for the crypto pieces, but this is pure HTTP magic.  I'd like to talk about adopti…

Thanks for working on this, Martin.

So it seems that the design is something like "the simplest possible
binary format which will support HTTP's base semantics" (and yes, I
agree with that approach in principle).

Things that this will leave behind are:

- reason phrases (currently optional, only supported in HTTP/1.*)
- "middlers" (in case we ever get to them)
- pseudo header fields other than those defined in H2

This might be completely acceptable for the original use case, but maybe
should be revisited if we're looking for a replacement of application/http.

Best regards, Julian

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 27 Aug 2021 10:19:55 +1000

Hi Julian,

> agree with that approach in principle).

Thanks.

> - reason phrases (currently optional, only supported in HTTP/1.*)

This is deliberate.  We did that for h2 and h3.

> - "middlers" (in case we ever get to them)

This was a harder choice, but I think that it's the right call.  Supporting them complicates things a bit and I don't think we've established their utility just yet.  Happy to explore how they might be integrated, but I wouldn't want to add them here until we decide that all the live protocols need them.

> - pseudo header fields other than those defined in H2

(I thought about this, but I guess I neglected to write my conclusions down.)

s/other than those defined in H2/other than for control data/

This I think we can accommodate.  Other pseudo header fields can be added as if they were regular fields, using the same rules as h2.  That is, pseudo header fields go first.  Should that be documented?

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 Aug 2021 08:28:10 +0200

> This was a harder choice, but I think that it's the right call.  Supporting them complicates things a bit and I don't think we've established their utility just yet.  Happy to explore how they migh…

Which of course leads us to the question about how this format could in
theory be extended in the future in a backwards-compatible way.

> This I think we can accommodate.  Other pseudo header fields can be added as if they were regular fields, using the same rules as h2.  That is, pseudo header fields go first.  Should that be docume…

I guess so (although I'm not a fan of that extension point :-).

Best regards, Julian

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 30 Aug 2021 13:18:00 +1000

> theory be extended in the future in a backwards-compatible way.

I think that the most sensible approach is to give up on forward-compatibility and define a new format.  Given the likelihood that we uniformly define midlers (or midders or whatever[1]) across the live protocols, that seems like a fairly safe bet.  The alternative is to carry something that exists just on the off chance we'd need it later, which I think is a good way to guarantee that the extension point will be broken when we get around to needing it[2].

On the general topic of extensibility, adding fields is a well-trodden path that could get us a long way (see also below).

> I guess so (although I'm not a fan of that extension point :-).

I was similarly not a fan.  I'm now somewhat more accepting of it, given that pseudo-fields are where the protocol as a whole ended up going.

Conveniently, I already had text on that, so I think we're good:

Pseudo-fields that are defined by protocol extensions MAY be included.  Field lines containing pseudo-fields MUST precede other field lines; a message that contains a pseudo-field after any other field is invalid; see {{invalid}}.

[1] For some reason, "midders" and "Scabbers" (Ron Weasley's rat familiar from Harry Potter) are inextricably linked in my mind.
[2] See https://intarchboard.github.io/draft-use-it-or-lose-it/draft-iab-use-it-or-lose-it.html