cc @neild

As far as we're aware, no public ORIGIN Frame implementation exists.

If nothing supports ORIGIN frames, what would use this? Just Go clients talking to Go servers?

Supporting draft RFCs that nobody else implements isn't really a goal for the standard library.

@neild As far as we know there are no server implementations, but Firefox supports ORIGIN Frames, and has done for a while. I think @sudheesh001 's comment was in reference to server-side support.
Further, RFC 8336 is not a draft specification, but a full RFC.

So far as I can tell, the latest version of RFC 8336 is draft-ietf-httpbis-origin-frame-06. Maybe I'm missing something.

Firefox supporting ORIGIN frames is something, but if no servers or other browsers support them, I don't know how meaningful that is.

These are great questions. First on status and support, then importance.

RFC 8336 was published in 2018. It is a standard that has gained full IETF consensus (see the datatracker). This year, HTTP/3 was published as RFC 9114. The HTTP WG is expected to declare consensus on the definition of ORIGIN frame for HTTP/3 by the end of the year.

On the client-side Firefox already has full support. On the server-side, Cloudflare has a working implementation (see net/http2 and net/http changes), as described in this paper and is investigating its use on wider scale.

The main benefits of ORIGIN Frame are:

1. It improves client privacy, because fewer SNIs are leaked to the network, see Section 6.2.
2. It opens up scheduling opportunities at both endpoints that will not be violated by competing path characteristics, see Section 6.1.
3. It's much easier to implement / support coalescing on the server side without having to think about IP addresses (which creates risk of having to synchronise multiple systems and potentially means having to violate their SLAs), see Section 5.3.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

The HTTP WG is expected to declare consensus on the definition of ORIGIN frame for HTTP/3 by the end of the year.

It sounds like we should wait for this consensus on the definition of ORIGIN frames before we add support for them. Everything sounds a bit up in the air right now.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

Thanks for the update @rsc. While the HTTP/2 ORIGIN Frame is already a standard (RFC 8336), the draft proposal for HTTP/3 ORIGIN Frame expected to declare consensus by the HTTP WG leverages the existing standard and mentions that the semantics of the frame payload are identical to that of HTTP/2 ORIGIN Frame.

Where HTTP/2 reserves Stream 0 for frames related to the state of the connection, HTTP/3 defines a pair of unidirectional streams called "control streams" for this purpose.

The definition for ORIGIN Frames in this case continues to rely on the existing definition of ORIGIN Frames, I'd like to hear what the others think too.

No change in consensus, so declined.
— rsc for the proposal review group