Just skimming through the doc (it has version 1 in it!) Sec. 12.4 Frames and Frame Types
regarding rule of shortest encoding form of frame type: "This rule applies to all current and future QUIC frame types. An endpoint MAY treat the receipt of a frame type that uses a longer encoding than necessary as a connection error of type PROTOCOL_VIOLATION.” I do appreciate shortest encoding form here, but how can QUIC v1 decide how future frames are encoded without placing that rule in invariants? Does it refer to extensions, or to future QUIC versions? Mikkel On 14 December 2020 at 00.33.57, Martin Thomson ([email protected]) wrote: And I forgot the other thing. The latest update only includes the base protocol. Magnus is taking the documents in two phases and the first includes only -invariants, -transport, -tls, and -recovery. There are a few changes to the http-core documents that we want to get the HTTP draft aligned with. We've been promised an update to that this week and so we've delayed -http and -qpack for a couple of days. On Mon, Dec 14, 2020, at 10:29, Martin Thomson wrote: > Just to keep everyone here in the loop, this is the version we're going > to give to the IESG. > > It is final in every way, except for the little bit I've quoted here: > > On Mon, Dec 14, 2020, at 10:23, [email protected] wrote: > > DO NOT DEPLOY THIS VERSION OF QUIC > > > > DO NOT DEPLOY THIS VERSION OF QUIC UNTIL IT IS IN AN RFC. This > > verion is still a work in progress. For trial deployments, please > > use earlier versions. > > (And yeah, I can see the typo *now*.) > > In any case, please respect this request. I doubt that the IESG will > ask for disruptive changes (or that we'll tolerate them), but we want > to reserve the option of doing so. > >
