| You are reading it correctly. This is a draft, and I presume Facebook's engineering team are confident that they have the resources (time/ money/ whatever) to stay reasonably up to date on any subsequent changes. Generally the way this work goes, at first things change pretty violently, maybe it goes from let's have a 1 byte version number, ASN.1 OIDs for everything and some JSON, to actually it's always the five bytes 'QUICK' then a four byte version number, we're doing CORS instead of JSON, and no OIDs now it's all URNs, in like two weeks of git pulls and mailing list posts. But after a while the drafts start to settle down. On some topics everybody is satisfied that there's a good argument for why we do this and not that, on others it's a coin toss and it's just easier not to change it than argue constantly. Do I like OIDs? Eh, they're better than URNs but I can live with either, so fine, have URNs if you insist. QUIC has largely settled down. Google's systems for example will tell you they speak draft 29 of QUIC. Do they? Well, more or less. Maybe it's sort of draft 32 really. But drafts 29 and 32 are pretty similar, and draft 32 is going to Last Call now, if nobody raises any issues it's done. Is it conceivable that somebody discovers a grave problem in QUIC and it has to be substantially revised? Yes. But it's not very likely. So it's easily possible that a draft 29 QUIC implementation like Google's (or Facebook's) will mostly interoperate with an actual QUIC standard next year after just some small tweaks to tell it this isn't a draft any more. Why wait? HTTP/3 is a bit more than just do HTTP on QUIC, and it's slightly less finished than QUIC is, but it's also pretty stable and there's less that might change anyway. Somebody has to try this stuff out, and at scale if we're to learn much more than "It might work" before it finishes that Last Call. Facebook, Google, Cloudflare, Mozilla, Netflix and so on are able to do that. |