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

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.

The Private Use area of only 256 values makes me a little nervous, given that a collision means authenticated packets will fail to parse properly.  I'd be more inclined to go straight to provisional registration as soon as someone wants to interop beyond their own clients.

If we feel we must have unstructured experiments, let *those* use a defined TLV format with a nice, long type field.

> @@ -1197,6 +1204,16 @@ ack_delay_exponent (0x0007):
   value is also used for ACK frames that are sent in Initial, Handshake, and
   Retry packets.  Values above 20 are invalid.
 
+extension_frames (0x0009):
+
+: A list of extension frame mappings, encoded using the ExtensionFrameMappings
+  struct.  That is, a 2 octet length field, followed by 1 or more repetitions of
+  a one octet frame type and a two octet identifiers.  Each entry defines a
+  mapping of frame type to the 16-bit extension frame types defined in
+  {{frame-extension}}.  Valid frame types MUST be from 0x80 to 0xff, other

Comma splice; either use a `;` or make these separate sentences.

> +The `extension_frames` transport parameter establishes a mapping from the 16-bit
+frame extension identifier to a frame type octet in the range from 0x80 to 0xff
+inclusive.  Each endpoint establishes their own preferred mapping; this
+determines the mapping for frames that they receive.  An endpoint translates the
+16-bit extension frame identifier into a frame type using the `extension_frames`
+transport parameter advertised by their peer.
+
+This design allows the same extension frame to use a different frame type in
+each direction.  It also allows for extension frames to be used in one direction
+only.
+
+An endpoint MUST NOT use extension frames in packets protected with handshake
+keys.  A client can use extension frames in 0-RTT based on the value of the
+server's transport parameters used in a previous connection.
+
+The definition of a extension frame identifier MUST include the format of the

an

> +determines the mapping for frames that they receive.  An endpoint translates the
+16-bit extension frame identifier into a frame type using the `extension_frames`
+transport parameter advertised by their peer.
+
+This design allows the same extension frame to use a different frame type in
+each direction.  It also allows for extension frames to be used in one direction
+only.
+
+An endpoint MUST NOT use extension frames in packets protected with handshake
+keys.  A client can use extension frames in 0-RTT based on the value of the
+server's transport parameters used in a previous connection.
+
+The definition of a extension frame identifier MUST include the format of the
+extension frame and its semantics.  QUIC frames are not length-delimited, so
+knowledge of the format of frames is necessary for decoding packets.  Each
+extension frame identifier definition MUST include the versions of QUIC that the

"identifier" is redundant.

-- 
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/1068#pullrequestreview-109909386