Re: [quicwg/base-drafts] What can change in a different version (#55)

[Martin Thomson <[e-mail]>]

We need to remind ourselves of the goal here.  The goal is to ensure that a new version of this protocol - really any other protocol, because nothing says that you have to do QUIC or HTTP in the future - can be deployed alongside the version of the protocol that we define, probably on the same server address and port.

QUIC relies on out-of-band configuration.  For the HTTP usage, we assume that clients are going to try h2 first.  It could be that we decide that compatibility is a mugs game and that the Alt-Svc announcement will need to pick a new port number in order to use a new version.

To be clear, I think that's unlikely.  For one, I imagine that Google want to continue to use port 443 when they deploy the standardized protocol.  Having a migration path that retains the same port number is a smoother upgrade path.  The same arguments for moving to standard-QUIC from Google-QUIC likely apply to leaving standard-QUIC for the next thing.

>From what I understand, the initial packets on a flow need to include connection ID always.  The initial packets on a connection require the version.  That fixes the initial header pretty well.  I would suggest that after confirming that the protocol is understood by the other side, almost anything is possible.

-- 
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/55#issuecomment-267198353