Re: [quicwg/base-drafts] Extension frames (#1473)

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



> +implementations of frame parsing, a frame type MUST use the shortest possible
+encoding.  Though a two-, four- or eight-octet encoding of the frame types
+defined in this document is possible, the Frame Type field for these frames are
+encoded on a single octet.  For instance, though 0x4007 is a legitimate
+two-octet encoding for a variable-length integer with a value of 7, PING frames
+are always encoded as a single octet with the value 0x07.
+
+## Extension Frames
+
+QUIC frames do not use a self-describing encoding.  An endpoint therefore needs
+to understand the syntax of all frame before it can successfully process a
+packet.  This allows for efficient encoding of frames, but it means that an
+endpoint cannot send a frame of a type that is unknown to its peer.
+
+An extension to QUIC that wishes to use a new type of frame MUST first ensure
+that a peer is able to understand the frame.  An endpoint can use a transport

There's always @larseggert's suggestion that BLOCKED et al. should be extensions.  That's been on hold while we wait for an extension mechanism to be defined, but it's a perfectly reasonable one.  Define a transport parameter `inform_if_blocked` and if that's set, the various BLOCKED frames are understood.

-- 
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/pull/1473#discussion_r198288379