Original text:
cannot be used to identify QUIC as a protocol or to infer the behavior of future versions of QUIC. <del> sec-google-version provides non-normative guidance on the identification of QUIC version 1 packets compared to some pre- standard versions. </del> 2.1. QUIC packets may have either a long header or a short header.  The Note that proprietary QUIC versions, that have been deployed before standardization, might not set the first bit in a QUIC long header <del> packet to 1.  To parse these versions, example code is provided in the appendix (see sec-google-version).  However, it is expected that these versions will gradually disappear over time. </del>  When the version has been identified as QUIC version 1, the packet type needs to be verified as an Initial packet by checking that the integer as specified in Section 16 of QUIC-TRANSPORT. After decryption, the client's Initial packet can be parsed to detect <del> the CRYPTO frame that contains the TLS ClientHello, which then can be parsed similarly to TLS over TCP connections.  The client's Initial packet may contain other frames, so the first bytes of each frame need to be checked to identify the frame type, and if needed skip over it.  Note that the length of the frames is dependent on the </del>  frame type.  In QUIC version 1, the packet is expected to contain only CRYPTO frames and optionally PADDING frames.  PADDING frames, each consisting of a single zero byte, may occur before, after, or

Reviewer comments:
The mentions . This makes the assumption that INITIAL packets carry a single CRYPTO frame. That assumption might not always hold in modern browsers, so the text should clarify that any middlebox that wishes to extract the SNI MUST perform reconstruction of the crypto stream from one or more CRYPTO frames in one or more INITIAL packets. The current assumption might lead middlebox vendors to write deploy software that doesn't work if there are multiple CRYPTO frames. The section correctly states but that comes late in the section and doesn't detail what middlebox vendors should do about it. That section also contains another incorrect assumption: . There are other frame types that are legal in INITIAL packets and may be sent by browsers.
I think this is pretty similar to , though that one is a bit more broad. Thanks for noticing the statement about Initials only containing CRYPTO and PADDING, I missed that.
The text already says the following now: Not sure when exactly this got added but I assume this is sufficient to address this issue? NAME NAME ?
I don't think the new text fully addresses this issue. In the new text, this statement is incorrect: What about PING frames for example? Additionally, the client's first flight won't contain extension frames because the client has no way of knowing whether the server supports them so this statement is somewhat misleading: What are middleboxes supposed to do if they see an unknown frame type, we should provide guidance there. I think we should just tell middlebox implementors to refer to that section of RFC 9000 and expect to parse all frame types, and fail parsing if they see a frame type they don't recognize. And while we're at it, we should also mention that CRYPTO frames might be out of order.
I would expect ping frame in the initial... so that sentence might still be fine. I think there could actually be extension frame in the first flight, e.g. if information was cached about the support of the extension. In any case, can you maybe propose text NAME ?
Extension caching doesn't work for initials because the server can still reject 0-RTT at this point. How about this text:
was copy-pasted from and is no longer correct. In particular it assumes that the packet only contains PADDING frames and a single CRYPTO frame with offset 0. That assumption is not guaranteed to hold with modern browsers, so this text will do more harm than good when it becomes an immutable RFC. Since we also have , I'd suggest removing Appendix A entirely.
By the time this document is published, old(ie: Q043) versions of gQUIC that aren't compatible with the IETF QUIC invariants should be gone from the internet or very close, so I'd suggest removing any text specific to it. URL It's possible some new text on distinguishing IETF QUIC version 1 is still useful, since two sections reference this appendix.

Revised text:
cannot be used to identify QUIC as a protocol or to infer the behavior of future versions of QUIC.  2.1. QUIC packets may have either a long header or a short header.  The Note that proprietary QUIC versions, that have been deployed before standardization, might not set the first bit in a QUIC long header  <ins> packet to 1.  However, it is expected that these versions will gradually disappear over time. </ins> When the version has been identified as QUIC version 1, the packet type needs to be verified as an Initial packet by checking that the integer as specified in Section 16 of QUIC-TRANSPORT. After decryption, the client's Initial packet can be parsed to detect  <ins> the CRYPTO frame(s) that contains the TLS ClientHello, which then can be parsed similarly to TLS over TCP connections.  The client's Initial packet may contain other frames, so the first bytes of each frame need to be checked to identify the frame type, and if needed skip over it.  Note that the length of the frames is dependent on the </ins> frame type.  In QUIC version 1, the packet is expected to contain only CRYPTO frames and optionally PADDING frames.  PADDING frames, each consisting of a single zero byte, may occur before, after, or