Draft: draft-ietf-quic-transport

Commentary: Fixes issue 
 Thanks for this . It 's a lot clearer this way . 
 restricts frame type varint encoding : The relevant sentence is : This means that the restriction may not apply to frames defined by QUIC extensions ( such as the frame in the   _ extension ) . Must each extension spell out its own frame type encoding rules ? It would be easier to change the transport draft to extend the minimal encoding restriction to not - as - yet - specified frames as well . 
 I read the first sentence as applying to all QUIC frame types , core or extensions . The examples confuse the matter by explicitly mentioning the core frames . Section 19.21 contains some guidance for extension frames , adding a pointer back to the encoding rules from would be a good editorial change . 
 The sentence I highlighted talks about frames in this document and then these frames , effectively overriding what the first sentence may imply . 
 yes I think we agree :) 
 I think we all agree that it can be made more explicit . The first sentence says that the rule for all frame types is that they be minimally encoded . Applying that principle to all frame types defined in this document means that they get one - byte encodings . We should clarify that it 's an application of the rule , not a limitation of it . 
 Why did we have this rule in the first place ? It just seems to complicate things in unexpected ways . 
 See . IIRC the rationale for using minimal varint encoding is that stacks that support only the standardized frames can live with a simpler dispatch scheme that takes one byte as an input ( regardless of the dispatch method being a table or a switch clause or whatever ) . While I do not have a strong opinion regarding that requirement , I 'd prefer not revisiting the discussion . 
 PR has been merged -- closing bug .
Paragraph (version A):
The Frame Type field uses a variable length integer encoding (see
integer-encoding) with one exception.  To ensure simple and efficient
implementations of frame parsing, a frame type MUST use the shortest
possible encoding.  Though a two-, four- or eight-byte encoding of
the frame types defined in this document is possible, the Frame Type
field for these frames is encoded on a single byte.  For instance,
though 0x4001 is a legitimate two-byte encoding for a variable-length
integer with a value of 1, PING frames are always encoded as a single
byte with the value 0x01.  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.
Paragraph (version B):
The Frame Type field uses a variable length integer encoding (see
integer-encoding) with one exception.  To ensure simple and efficient
implementations of frame parsing, a frame type MUST use the shortest
possible encoding.  For frame types defined in this document, this
means a single-byte encoding, even though it is possible to encode
these values as a two-, four- or eight-byte variable length integer.
For instance, though 0x4001 is a legitimate two-byte encoding for a
variable-length integer with a value of 1, PING frames are always
encoded as a single byte with the value 0x01.  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.