Separate handshakes, or unified handshake?

[kixelated]

A few issues have cropped up because we support QUIC and WebTransport with a unified SETUP handshake.

• 232 was closed because there's a desire to use ALPN for native QUIC, however no such functionality exists in WebTransport.

• 135 added a path to the SETUP message, mirroring WebTransport because no such functionality exists in QUIC.

• 242 incurs an additional half RTT delay with native QUIC because the client sends the SETUP message first.

Do we separate the QUIC and WebTransport handshakes, or continue to combine them into the same mechanism?

[kixelated]

I think we have a separate handshakes for QUIC and WebTransport that better utilize the underlying transport.

• QUIC could leverage ALPN.
• WebTransport could leverage the CONNECT request.
• WebTransport could leverage session pooling.

However, I do want to avoid differences after the connection is established.

[afrind]

Chairs: it looks like webtransport is going to have an ALPN like mechanism. Is that sufficient to unify the handshakes across QUIC and WebTrans?