Re: I-D Action: draft-ietf-quic-transport-33.txt

[Mikkel Fahnøe Jørgensen <[e-mail]>]

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 ([e-mail]) 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, [e-mail] 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.
>
>