jiebi/CodeConvo huggingface dataset:
Code change:
The first strikes "TLS" from encryption level The second removes misleading text about coalescing I'm suggesting that we replace it with explanatory language about encryption levels and packet number spaces. This context is now missing as a result of moving the referenced text to -transport.
Roman Danyliw said:
I'm going to suggest that the text I propose in addresses this first part of this. The higher/lower stuff seems like it could be better, but it's a lot of work to do carefully. I'm going to suggest that we could live with this, but I might leave this issue open and try to find a fix once other more pressing issues are dealt with.
NAME said:
This is really two comments, but I think we can dispense with both at the same time as the first is really trivial: The use of "TLS encryption level" is an unnecessary redundancy and inconsistent with other usage, so we can easily remove "TLS" there. The start of that paragraph is cruft. I'm going to suggest we only keep the last sentence, which was unquoted in this issue. But then I see that we are missing important context, so I'm going to suggest a little bit of text to replace it.
one suggestion, but lgtm

Related discussion:
text: QUIC carries TLS handshake data in CRYPTO frames, each of which consists of a contiguous block of handshake data identified by an offset and length.  Those frames are packaged into QUIC packets and <del> encrypted under the current TLS encryption level.  As with TLS over TCP, once TLS handshake data has been delivered to QUIC, it is QUIC's </del> <ins> encrypted under the current encryption level.  As with TLS over TCP, once TLS handshake data has been delivered to QUIC, it is QUIC's </ins> responsibility to deliver it reliably.  Each chunk of data that is produced by TLS is associated with the set of keys that TLS is currently using.  If QUIC needs to retransmit that data, it MUST use the same keys even if TLS has already updated to newer keys. <del> One important difference between TLS records (used with TCP) and QUIC CRYPTO frames is that in QUIC multiple frames may appear in the same QUIC packet as long as they are associated with the same packet number space.  For instance, an endpoint can bundle a Handshake message and an ACK for some Handshake data into the same packet. </del> <ins> Each encryption level corresponds to a packet number space.  The packet number space that is used determines the semantics of frames. </ins> Some frames are prohibited in different packet number spaces; see Section 12.5 of QUIC-TRANSPORT.
Code change:
Ben observed that this might be at odds with the definition of the interface. This is true, but the illustrative value of the current structure is valuable. More text on that might help.
NAME said:
I think that the multiple invocations is enough to call out. However, the retrieval of bytes to send after processing some data is not necessary. For reference, the is: This does not necessarily imply that you pull after every byte provided. As the bytes here are provided in a coalesced packet, it is reasonable to defer the "Get Handshake" call until all of the bytes arrive. I know that our stack does, though this is not uniformly true. to Handshake Complete? YES! Thanks. That's going to be awkward, as it involves QUIC-layer messages, but I think we can do that. (In a separate PR though.)

Related discussion:
text: exchange-summary shows the multiple packets that form a single "flight" of messages being processed individually, to show what <del> incoming messages trigger different actions.  New handshake messages are requested after incoming packets have been processed.  This process varies based on the structure of endpoint implementations and the order in which packets arrive; this is intended to illustrate the steps involved in a single handshake exchange. </del> <ins> incoming messages trigger different actions.  This shows multiple "Get Handshake" invocations to retrieve handshake messages at different encryption levels.  New handshake messages are requested after incoming packets have been processed. exchange-summary shows one possible structure for a simple handshake exchange.  The exact process varies based on the structure of endpoint implementations and the order in which packets arrive. Implementations could use a different number of operations or execute them in other orders. </ins> 4.2.
Code change:
NAME I'll leave that in your hands.
NAME said:
Seems reasonable. I took the opportunity to reword a little.
Perhaps this PR should also fix the text in 8.1 to simply state and point to 14.1 in -transport. That text is redundant.

Related discussion:
text: ClientHello message in their first Initial packet. The TLS implementation does not need to ensure that the ClientHello <del> is sufficiently large.  QUIC PADDING frames are added to increase the size of the packet as necessary. </del> <ins> is large enough to meet the requirements for QUIC packets.  QUIC PADDING frames are added to increase the size of the packet as necessary; see Section 14.1 of QUIC-TRANSPORT. </ins> 4.4.
Code change:
As agreed via mail.
NAME said:
Response provided via email.
This is probably something we need a consensus call on, even though it's a change only in theory.
Returning to an open state as the chairs directed in their plan.
Closing this now that the IESG have approved the document(s).
This gets the job done, with or without the suggested rewording.

Related discussion:
text: that supports this extension if the extension is received when the transport is not QUIC. <ins> Negotiating the quic_transport_parameters extension causes the EndOfEarlyData to be removed; see remove-eoed. </ins> 8.3. The TLS EndOfEarlyData message is not used with QUIC.  QUIC does not
Code change:
This makes it clearer that the notation is copied from v1, not defined there and normatively referenced. (Note, figures aren't normative anyway.)
Éric Vyncke said:
In my response to , I explain this. This ensures that the transport reference can remain informative.
Perhaps the intro needs to be reworded to indicate that it's using some of the same conventions as the transport document, which are reproduced below?
Éric Vyncke said:
Barry's point (captured in ) was that one or other might need to be normative. This is a different point, suggesting that this document concretely depends on the transport draft for terminology that has normative effect. Haven't checked, I don't think that is the case and the reference can remain informative. The reason for that being that all of the terminology used in this draft is also defined in this draft.
Any other bids?

Related discussion:
text: 4. <del> Packet diagrams in this document use a format defined in QUIC- TRANSPORT to illustrate the order and size of fields. </del> <ins> The format of packets is described using the notation defined in this section.  This notation is the same as that used in QUIC-TRANSPORT. </ins> Complex fields are named and then followed by a list of fields surrounded by a pair of matching braces.  Each field in this list is
Code change:
One possible resolution to ; all literals are zero-padded to full bytes.
IANA made the following observation while creating the H3 registries: While the IANA copy of the registry uses two digits throughout, the QUIC draft is similarly inconsistent about whether literal hex values have any leading zeros. Is it worth updating our hex literals to use full bytes (, , etc.) or synchonizing on some other format? We probably shouldn't synchronize on trimming, since IANA has already skewed the other way.
NAME did fix this or do we need to inform IANA also?
We should probably shoot IANA an e-mail to update the registries with leading zeroes where they hadn't already assumed them.
I'll let you do that. The only registries that are affected are in HTTP/3 and QPACK.
Fixed both in the registry and the documents.
Yeah, this is easy to understand. The tables must have been annoying.

Related discussion:
text: defined in Section 6 of TLS13. A TLS alert is converted into a QUIC connection error.  The <del> AlertDescription value is added to 0x100 to produce a QUIC error code from the range reserved for CRYPTO_ERROR.  The resulting value is sent in a QUIC CONNECTION_CLOSE frame of type 0x1c. </del> <ins> AlertDescription value is added to 0x0100 to produce a QUIC error code from the range reserved for CRYPTO_ERROR.  The resulting value is sent in a QUIC CONNECTION_CLOSE frame of type 0x1c. </ins> QUIC is only able to convey an alert level of "fatal".  In TLS 1.3, the only existing uses for the "warning" level are to signal
Code change:
One possible resolution to ; all literals are zero-padded to full bytes.
IANA made the following observation while creating the H3 registries: While the IANA copy of the registry uses two digits throughout, the QUIC draft is similarly inconsistent about whether literal hex values have any leading zeros. Is it worth updating our hex literals to use full bytes (, , etc.) or synchonizing on some other format? We probably shouldn't synchronize on trimming, since IANA has already skewed the other way.
NAME did fix this or do we need to inform IANA also?
We should probably shoot IANA an e-mail to update the registries with leading zeroes where they hadn't already assumed them.
I'll let you do that. The only registries that are affected are in HTTP/3 and QPACK.
Fixed both in the registry and the documents.
Yeah, this is easy to understand. The tables must have been annoying.

Related discussion:
text: QUIC permits the use of a generic code in place of a specific error code; see Section 11 of QUIC-TRANSPORT.  For TLS alerts, this includes replacing any alert with a generic alert, such as <del> handshake_failure (0x128 in QUIC).  Endpoints MAY use a generic error code to avoid possibly exposing confidential information. </del> <ins> handshake_failure (0x0128 in QUIC).  Endpoints MAY use a generic error code to avoid possibly exposing confidential information. </ins> 4.9.
Code change:
One possible resolution to ; all literals are zero-padded to full bytes.
IANA made the following observation while creating the H3 registries: While the IANA copy of the registry uses two digits throughout, the QUIC draft is similarly inconsistent about whether literal hex values have any leading zeros. Is it worth updating our hex literals to use full bytes (, , etc.) or synchonizing on some other format? We probably shouldn't synchronize on trimming, since IANA has already skewed the other way.
NAME did fix this or do we need to inform IANA also?
We should probably shoot IANA an e-mail to update the registries with leading zeroes where they hadn't already assumed them.
I'll let you do that. The only registries that are affected are in HTTP/3 and QPACK.
Fixed both in the registry and the documents.
Yeah, this is easy to understand. The tables must have been annoying.

Related discussion:
text: on KeyUpdate messages sent using 1-RTT encryption keys.  Endpoints MUST NOT send a TLS KeyUpdate message.  Endpoints MUST treat the receipt of a TLS KeyUpdate message as a connection error of type <del> 0x10a, equivalent to a fatal TLS alert of unexpected_message; see </del> <ins> 0x010a, equivalent to a fatal TLS alert of unexpected_message; see </ins> tls-errors. ex-key-update shows a key update process, where the initial set of
Code change:
One possible resolution to ; all literals are zero-padded to full bytes.
IANA made the following observation while creating the H3 registries: While the IANA copy of the registry uses two digits throughout, the QUIC draft is similarly inconsistent about whether literal hex values have any leading zeros. Is it worth updating our hex literals to use full bytes (, , etc.) or synchonizing on some other format? We probably shouldn't synchronize on trimming, since IANA has already skewed the other way.
NAME did fix this or do we need to inform IANA also?
We should probably shoot IANA an e-mail to update the registries with leading zeroes where they hadn't already assumed them.
I'll let you do that. The only registries that are affected are in HTTP/3 and QPACK.
Fixed both in the registry and the documents.
Yeah, this is easy to understand. The tables must have been annoying.

Related discussion:
text: When using ALPN, endpoints MUST immediately close a connection (see Section 10.2 of QUIC-TRANSPORT) with a no_application_protocol TLS <del> alert (QUIC error code 0x178; see tls-errors) if an application </del> <ins> alert (QUIC error code 0x0178; see tls-errors) if an application </ins> protocol is not negotiated.  While ALPN only specifies that servers <del> use this alert, QUIC clients MUST use error 0x178 to terminate a </del> <ins> use this alert, QUIC clients MUST use error 0x0178 to terminate a </ins> connection when ALPN negotiation fails. An application protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol compatible with the QUIC version that the client has selected.  The server MUST treat the inability to select a compatible application protocol as a <del> connection error of type 0x178 (no_application_protocol).  Similarly, a client MUST treat the selection of an incompatible application protocol by a server as a connection error of type 0x178. </del> <ins> connection error of type 0x0178 (no_application_protocol). Similarly, a client MUST treat the selection of an incompatible application protocol by a server as a connection error of type 0x0178. </ins> 8.2.
Code change:
One possible resolution to ; all literals are zero-padded to full bytes.
IANA made the following observation while creating the H3 registries: While the IANA copy of the registry uses two digits throughout, the QUIC draft is similarly inconsistent about whether literal hex values have any leading zeros. Is it worth updating our hex literals to use full bytes (, , etc.) or synchonizing on some other format? We probably shouldn't synchronize on trimming, since IANA has already skewed the other way.
NAME did fix this or do we need to inform IANA also?
We should probably shoot IANA an e-mail to update the registries with leading zeroes where they hadn't already assumed them.
I'll let you do that. The only registries that are affected are in HTTP/3 and QPACK.
Fixed both in the registry and the documents.
Yeah, this is easy to understand. The tables must have been annoying.

Related discussion:
text: MUST send the quic_transport_parameters extension; endpoints that receive ClientHello or EncryptedExtensions messages without the quic_transport_parameters extension MUST close the connection with an <del> error of type 0x16d (equivalent to a fatal TLS missing_extension </del> <ins> error of type 0x016d (equivalent to a fatal TLS missing_extension </ins> alert, see tls-errors). Transport parameters become available prior to the completion of the
Code change:
This one slipped the net.
Either way is fine by me. Just ship it already :PThanks, Martin!

Related discussion:
text: Contains additional ranges of packets that are alternately not acknowledged (Gap) and acknowledged (ACK Range); see ack-ranges. <del> The three ECN Counts; see ack-ecn-counts. </del> <ins> The three ECN counts; see ack-ecn-counts. </ins> 19.3.1.
Code change:
This one slipped the net.
Either way is fine by me. Just ship it already :PThanks, Martin!

Related discussion:
text: The ACK frame uses the least significant bit of the type value (that is, type 0x03) to indicate ECN feedback and report receipt of QUIC packets with associated ECN codepoints of ECT(0), ECT(1), or ECN-CE <del> in the packet's IP header.  ECN Counts are only present when the ACK </del> <ins> in the packet's IP header.  ECN counts are only present when the ACK </ins> frame type is 0x03. When present, there are three ECN counts, as shown in ecn-count- format. <del> The three ECN Counts are: </del> <ins> The ECN count fields are: </ins> A variable-length integer representing the total number of packets received with the ECT(0) codepoint in the packet number space of
Code change:
Removed one HTTP/2 reference which seems extraneous, and corrected the polarity of another. This by doing almost nothing; speak now if you think more is warranted.
RFC Editor says: But fair enough -- are we overdoing it?
Having looked at the references, they all seem reasonable with the possible exception of PUSH_PROMISE noting it behaves "as in HTTP/2." Most references to HTTP/2 occur either in the first two sections of the document or in the Appendix which specifically discusses the relationship between HTTP/2 and HTTP/3. removes that one extraneous reference. Other than than, I plan to make no further changes to address this feedback unless someone wants to provide a more concrete list of places where the comparison is unnecessary.
Marginal: Section 4.1.1 and 4.1.1.1 seems to have some egregious use of phrasing similar to "Like HTTP/2, ..." or "as in HTTP/2". You could possibly condense these to a sentence such as "Like HTTP/2, HTTP/3 has additional considerations related to use of characters in field names, the Connect header field, and pseudo-header fields". That could be inserted into to thefirst para of 4.1.1, or the second para (thus breaking the para so the next one starts with "Characters in field names").
Fixed in .

Related discussion:
text: "HTTP fields"; see Sections RFC9110 and RFC9110 of RFC9110.  For a listing of registered HTTP fields, see the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at <del> <https://www.iana.org/assignments/http-fields/>. </del> <ins> <https://www.iana.org/assignments/http-fields/>.  Like HTTP/2, HTTP/3 has additional considerations related to the use of characters in field names, the Connection header field, and pseudo-header fields. </ins> Field names are strings containing a subset of ASCII characters. Properties of HTTP field names and values are discussed in more <del> detail in RFC9110.  As in HTTP/2, characters in field names MUST be converted to lowercase prior to their encoding.  A request or response containing uppercase characters in field names MUST be treated as . </del> <ins> detail in RFC9110.  Characters in field names MUST be converted to lowercase prior to their encoding.  A request or response containing uppercase characters in field names MUST be treated as . </ins> <del> Like HTTP/2, HTTP/3 does not use the Connection header field to indicate connection-specific fields; in this protocol, connection- specific metadata is conveyed by other means.  An endpoint MUST NOT generate an HTTP/3 field section containing connection-specific fields; any message containing connection-specific fields MUST be treated as . </del> <ins> HTTP/3 does not use the Connection header field to indicate connection-specific fields; in this protocol, connection-specific metadata is conveyed by other means.  An endpoint MUST NOT generate an HTTP/3 field section containing connection-specific fields; any message containing connection-specific fields MUST be treated as . </ins> The only exception to this is the TE header field, which MAY be present in an HTTP/3 request header; when it is, it MUST NOT contain
Code change:
Removed one HTTP/2 reference which seems extraneous, and corrected the polarity of another. This by doing almost nothing; speak now if you think more is warranted.
RFC Editor says: But fair enough -- are we overdoing it?
Having looked at the references, they all seem reasonable with the possible exception of PUSH_PROMISE noting it behaves "as in HTTP/2." Most references to HTTP/2 occur either in the first two sections of the document or in the Appendix which specifically discusses the relationship between HTTP/2 and HTTP/3. removes that one extraneous reference. Other than than, I plan to make no further changes to address this feedback unless someone wants to provide a more concrete list of places where the comparison is unnecessary.
Marginal: Section 4.1.1 and 4.1.1.1 seems to have some egregious use of phrasing similar to "Like HTTP/2, ..." or "as in HTTP/2". You could possibly condense these to a sentence such as "Like HTTP/2, HTTP/3 has additional considerations related to use of characters in field names, the Connect header field, and pseudo-header fields". That could be inserted into to thefirst para of 4.1.1, or the second para (thus breaking the para so the next one starts with "Characters in field names").
Fixed in .

Related discussion:
text: 7.2.5. The frame (type=0x05) is used to carry a promised request header <del> section from server to client on a , as in HTTP/2. </del> <ins> section from server to client on a . </ins> The payload consists of:
Code change:
These track corrections I've asked the RFC Editor to make directly in their copy prior to publication. It appears that some http-core sections moved since the last time we did a full sweep of our references.

Related discussion:
text: The QUIC transport protocol (QUIC-TRANSPORT) is designed to support HTTP semantics, and its design subsumes many of the features of <del> HTTP/2 (RFC7540).  HTTP/2 uses HPACK (RFC7541) for compression of the header and trailer sections.  If HPACK were used for HTTP/3 (HTTP3), it would induce head-of-line blocking for field sections due to built-in assumptions of a total ordering across frames on all </del> <ins> HTTP/2 (RFC9113).  HTTP/2 uses HPACK (RFC7541) for compression of the header and trailer sections.  If HPACK were used for HTTP/3 (RFC9114), it would induce head-of-line blocking for field sections due to built-in assumptions of a total ordering across frames on all </ins> streams. QPACK reuses core concepts from HPACK, but is redesigned to allow
Code change:
These track corrections I've asked the RFC Editor to make directly in their copy prior to publication. It appears that some http-core sections moved since the last time we did a full sweep of our references.

Related discussion:
text: fields; this document uses "fields" for generality. A name-value pair sent as part of an HTTP field section.  See <del> Sections 6.3 and 6.5 of SEMANTICS. </del> <ins> Sections 6.3 and 6.5 of RFC9110. </ins> Data associated with a field name, composed from all field line values with that field name in that section, concatenated together
Code change:
These track corrections I've asked the RFC Editor to make directly in their copy prior to publication. It appears that some http-core sections moved since the last time we did a full sweep of our references.

Related discussion:
text: 8. This document makes multiple registrations in the registries defined <del> by HTTP3.  The allocations created by this document are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). </del> <ins> by RFC9114.  The allocations created by this document are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). </ins> 8.1. This document specifies two settings.  The entries in the following table are registered in the "HTTP/3 Settings" registry established in <del> HTTP3. </del> <ins> RFC9114. </ins> For formatting reasons, the setting names here are abbreviated by removing the 'SETTINGS_' prefix.
Code change:
These track corrections I've asked the RFC Editor to make directly in their copy prior to publication. It appears that some http-core sections moved since the last time we did a full sweep of our references.

Related discussion:
text: This document specifies two stream types.  The entries in the following table are registered in the "HTTP/3 Stream Types" registry <del> established in HTTP3. </del> <ins> established in RFC9114. </ins> 8.3. This document specifies three error codes.  The entries in the following table are registered in the "HTTP/3 Error Codes" registry <del> established in HTTP3. </del> <ins> established in RFC9114. </ins>