HTTP-31: Forward compatibility in QUIC

[gloinul]

Section 3.3:

"The use of other QUIC transport versions with HTTP/3 MAY be defined by future specifications."

I find an interesting contrast with TLS here. While for TLS usage in QUIC has a rather small set of rules for what future TLS version needs to provide to be compatible with QUIC, the same is not done to other QUIC versions. Wouldn't it be better to define what QUIC mechanism that HTTP/3 is dependent on and state that any future QUIC version that provides those mechanism can support this HTTP/3 mapping on QUIC? What was the reasons for not providing forward compatibility for QUIC?

[LPardue]

This text originates as an outcome of #3117. @MikeBishop presented slides at IETF 106 https://github.com/quicwg/wg-materials/blob/master/ietf106/ALPN.pdf and minutes are at https://github.com/quicwg/wg-materials/blob/master/ietf106/minutes.md#quicv2-for-http3

[MikeBishop]

@gloinul, that would have been my personal preference as well. However, that was not the consensus of the working group. In order to do that, we would need to ensure that we had a concrete description of all transport functionality that HTTP/3 relies on and a deterministic way to decide whether a particular version of QUIC met those requirements. Because we haven't ironed out version negotiation yet, it's difficult to make concrete statements about how ALPN and version negotiation will interact here.

"HTTP/3 == QUIC v1" is the conservative answer, and can either be updated or new ALPN tokens defined when we have multiple QUIC versions to talk about.

[gloinul]

Okay, lets close this issue as this is based on pre-existing WG consensus. I think the IETF 106 discussion was a bit too focused on the identification rather on the potential. I think this will result a need to open and redefine this aspect quite soon. It also creates an uncertainty for any non-standard QUIC versions what they require to support HTTP/3.

[LPardue]

One way to look at this is all H3 needs is multiple reliable and ordered bytestreams that can be opened by either side.

Mike spent effort to minimise QUIC specific terms through the document. Which should ease future attempts to port H3 should anyone want that.

The other complication in all this is how HTTP feature selection works compared to selection of QUIC versions or extensions. https://tools.ietf.org/html/draft-pardue-alt-svc-ext-unsupported-00 is one example. I don't think we're done here in the long term but I do think anything we tried to do would be detrimental or unprovable in the short term.

[LPardue]

At Magnus' request, I'm closing this with no action required.