Subject: [quicwg/base-drafts] Disconnect version number from draft number (#3062)

From: David Schinazi <[email-masked]>
Date: Mon, 23 Sep 2019 16:53:27 -0700

As the documents are becoming more mature, the amount of protocol-level changes is going down. Would it make sense to start disconnecting the protocol versions ([ALPN](https://tools.ietf.org/html/draft-ietf-quic-http-23#section-3.1) `h3-23`, [transport version](https://tools.ietf.org/html/draft-ietf-quic-transport-23#section-15) `0xff000017`) from the draft numbers (i.e. `draft-ietf-quic-http-23`, `draft-ietf-quic-transport-23`)?

This correlation caused a few headaches in the final stages of TLS 1.3 standardization, it would be nice not to repeat that here.

(This was discussed a while back, and is not my idea, but is now the right time?)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3062

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 23 Sep 2019 17:16:36 -0700

I'm sympathetic to the point that is being made here but I don't know how solvable it is. 

HTTP/3 has been quite independent of QUIC version for a while, so its been funny watching if move in lock step with transport.

On the one hand, there are implications to changing the alt-svc identifier, which makes migration a little annoying. But on the other hand we just made a breaking changes between h3-22 and h3-23. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3062#issuecomment-534334209

---

From: David Schinazi <[email-masked]>
Date: Mon, 23 Sep 2019 18:21:00 -0700

The idea would be to update the protocol version in a new draft if any breaking change was made, but not when only editorial changes were made.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3062#issuecomment-534346698

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 23 Sep 2019 18:30:14 -0700

That makes sense. For HTTP/3 we'd need to rephrase https://tools.ietf.org/html/draft-ietf-quic-http-23#section-3.1 slightly (but that is not a huge problem because the section will be deleted in the final version anyway). In the interest of sanity, I might suggest that the HTTP/3 identifier simply reflects the wireprotocol version, and is explicitly tied to it. For example, if we were to freeze on 0xff000017, then the ALPN becomes `h3-ff000017` (give or take some prettifying). This would sidestep the discussion takign place on #3061 but with the possible cost of duplication.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3062#issuecomment-534348485

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 23 Sep 2019 19:08:02 -0700

@LPardue I'm not sure it sidesteps. Instead, I think it might turn out as a practical way of testing the "quic" attribute of Alt-Svc.

Wire versions of the transport and the application protocol would not change in the same versions. Consider the case where http-24 remains wire-compatible with -23 (hence ALPN=h3-23), while the transport-24 making breaking changes.

In such case, to avoid the use of VN, the server _is_ going to send `Alt-Svc: h3-23=":443"; quic="ff000018"`.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3062#issuecomment-534356557

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 23 Sep 2019 19:35:22 -0700

My proposal was imperfect but I was attempting to avoid having to maintain some out of band matrix somewhere that lists what draft versions of H3 are compatible with what draft versions of QUIC, and also avoid gaps in the H3 apln identifier space.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3062#issuecomment-534362380

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 23 Sep 2019 19:43:31 -0700

@LPardue Yeah I think I get that.

My point is that if we are say that the ALPN identifier changes only when the HTTP/3 draft makes a wire-incompatible change, a single HTTP/3 draft could match to multiple versions of QUIC transport drafts (that are incompatible with each other), and therefore that the "quic" parameter would be useful.

If we are going to update the ALPN identifier when either of the HTTP/3 draft or the transport draft changes, then there would be no benefit in sending the "quic" parameter.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3062#issuecomment-534363980

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 23 Sep 2019 20:00:00 -0700

I have a concern about how the quic parameter would relate to Alt-Svc caching in practice, especially on a rolling upgrade.  But I'm not sure my concern is found or the proposal helps. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3062#issuecomment-534367130