jiebi/CodeConvo huggingface dataset:
Code change:
When reviewing the latest editors copy, the document structure leaps out at a bit odd by jumping from section 3 to section 5. That indicates to me these concepts are linked and also independent of the capsule protocol. So here I propose a minor restructure by moving the H3_DATAGRAM setting stuff to be a subsection of the HTTP/3 datagram format. This makes all the top-layer sections loosely coupled, which is nicer in my opinion.

Related discussion:
text: if they define semantics for such HTTP Datagrams and negotiate mutual support. <ins> 3.1. Implementations of HTTP/3 that support HTTP Datagrams can indicate that to their peer by sending the H3_DATAGRAM SETTINGS parameter with a value of 1.  The value of the H3_DATAGRAM SETTINGS parameter MUST be either 0 or 1.  A value of 0 indicates that HTTP Datagrams are not supported.  An endpoint that receives the H3_DATAGRAM SETTINGS parameter with a value that is neither 0 or 1 MUST terminate the connection with error H3_SETTINGS_ERROR. Endpoints MUST NOT send QUIC DATAGRAM frames until they have both sent and received the H3_DATAGRAM SETTINGS parameter with a value of 1. When clients use 0-RTT, they MAY store the value of the server's H3_DATAGRAM SETTINGS parameter.  Doing so allows the client to send QUIC DATAGRAM frames in 0-RTT packets.  When servers decide to accept 0-RTT data, they MUST send a H3_DATAGRAM SETTINGS parameter greater than or equal to the value they sent to the client in the connection where they sent them the NewSessionTicket message.  If a client stores the value of the H3_DATAGRAM SETTINGS parameter with their 0-RTT state, they MUST validate that the new value of the H3_DATAGRAM SETTINGS parameter sent by the server in the handshake is greater than or equal to the stored value; if not, the client MUST terminate the connection with error H3_SETTINGS_ERROR.  In all cases, the maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1. It is RECOMMENDED that implementations that support receiving HTTP Datagrams using QUIC always send the H3_DATAGRAM SETTINGS parameter with a value of 1, even if the application does not intend to use HTTP Datagrams.  This helps to avoid "sticking out"; see security. 3.1.1. [[RFC editor: please remove this section before publication.]] Some revisions of this draft specification use a different value (the Identifier field of a Setting in the HTTP/3 SETTINGS frame) for the H3_DATAGRAM Settings Parameter.  This allows new draft revisions to make incompatible changes.  Multiple draft versions MAY be supported by either endpoint in a connection.  Such endpoints MUST send multiple values for H3_DATAGRAM.  Once an endpoint has sent and received SETTINGS, it MUST compute the intersection of the values it has sent and received, and then it MUST select and use the most recent draft version from the intersection set.  This ensures that both endpoints negotiate the same draft version. </ins> 4. This specification introduces the Capsule Protocol.  The Capsule
Code change:
When reviewing the latest editors copy, the document structure leaps out at a bit odd by jumping from section 3 to section 5. That indicates to me these concepts are linked and also independent of the capsule protocol. So here I propose a minor restructure by moving the H3_DATAGRAM setting stuff to be a subsection of the HTTP/3 datagram format. This makes all the top-layer sections loosely coupled, which is nicer in my opinion.

Related discussion:
text: 5. <del> Implementations of HTTP/3 that support HTTP Datagrams can indicate that to their peer by sending the H3_DATAGRAM SETTINGS parameter with a value of 1.  The value of the H3_DATAGRAM SETTINGS parameter MUST be either 0 or 1.  A value of 0 indicates that HTTP Datagrams are not supported.  An endpoint that receives the H3_DATAGRAM SETTINGS parameter with a value that is neither 0 or 1 MUST terminate the connection with error H3_SETTINGS_ERROR. Endpoints MUST NOT send QUIC DATAGRAM frames until they have both sent and received the H3_DATAGRAM SETTINGS parameter with a value of 1. When clients use 0-RTT, they MAY store the value of the server's H3_DATAGRAM SETTINGS parameter.  Doing so allows the client to send QUIC DATAGRAM frames in 0-RTT packets.  When servers decide to accept 0-RTT data, they MUST send a H3_DATAGRAM SETTINGS parameter greater than or equal to the value they sent to the client in the connection where they sent them the NewSessionTicket message.  If a client stores the value of the H3_DATAGRAM SETTINGS parameter with their 0-RTT state, they MUST validate that the new value of the H3_DATAGRAM SETTINGS parameter sent by the server in the handshake is greater than or equal to the stored value; if not, the client MUST terminate the connection with error H3_SETTINGS_ERROR.  In all cases, the maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1. It is RECOMMENDED that implementations that support receiving HTTP Datagrams using QUIC always send the H3_DATAGRAM SETTINGS parameter with a value of 1, even if the application does not intend to use HTTP Datagrams.  This helps to avoid "sticking out"; see security. 5.1. [[RFC editor: please remove this section before publication.]] Some revisions of this draft specification use a different value (the Identifier field of a Setting in the HTTP/3 SETTINGS frame) for the H3_DATAGRAM Settings Parameter.  This allows new draft revisions to make incompatible changes.  Multiple draft versions MAY be supported by either endpoint in a connection.  Such endpoints MUST send multiple values for H3_DATAGRAM.  Once an endpoint has sent and received SETTINGS, it MUST compute the intersection of the values it has sent and received, and then it MUST select and use the most recent draft version from the intersection set.  This ensures that both endpoints negotiate the same draft version. 6. </del> Data streams (see capsule-protocol) can be prioritized using any means suited to stream or request prioritization.  For example, see Section 11 of PRIORITY.
Code change:
When reviewing the latest editors copy, the document structure leaps out at a bit odd by jumping from section 3 to section 5. That indicates to me these concepts are linked and also independent of the capsule protocol. So here I propose a minor restructure by moving the H3_DATAGRAM setting stuff to be a subsection of the HTTP/3 datagram format. This makes all the top-layer sections loosely coupled, which is nicer in my opinion.

Related discussion:
text: define signaling to allow endpoints to communicate their prioritization preferences. <del> 7. </del> <ins> 6. </ins> Since transmitting HTTP Datagrams using QUIC DATAGRAM frames requires sending an HTTP/3 Settings parameter, it "sticks out".  In other
Code change:
When reviewing the latest editors copy, the document structure leaps out at a bit odd by jumping from section 3 to section 5. That indicates to me these concepts are linked and also independent of the capsule protocol. So here I propose a minor restructure by moving the H3_DATAGRAM setting stuff to be a subsection of the HTTP/3 datagram format. This makes all the top-layer sections loosely coupled, which is nicer in my opinion.

Related discussion:
text: Tokens, it is not accessible from Web Platform APIs (such as those commonly accessed via JavaScript in web browsers). <del> 8. </del> <ins> 7. </ins> <del> 8.1. </del> <ins> 7.1. </ins> This document will request IANA to register the following entry in the "HTTP/3 Settings" registry:
Code change:
When reviewing the latest editors copy, the document structure leaps out at a bit odd by jumping from section 3 to section 5. That indicates to me these concepts are linked and also independent of the capsule protocol. So here I propose a minor restructure by moving the H3_DATAGRAM setting stuff to be a subsection of the HTTP/3 datagram format. This makes all the top-layer sections loosely coupled, which is nicer in my opinion.

Related discussion:
text: HTTP_WG; HTTP working group; ietf-http-wg@w3.org <del> 8.2. </del> <ins> 7.2. </ins> This document will request IANA to register the following entry in the "HTTP/3 Error Codes" registry:
Code change:
When reviewing the latest editors copy, the document structure leaps out at a bit odd by jumping from section 3 to section 5. That indicates to me these concepts are linked and also independent of the capsule protocol. So here I propose a minor restructure by moving the H3_DATAGRAM setting stuff to be a subsection of the HTTP/3 datagram format. This makes all the top-layer sections loosely coupled, which is nicer in my opinion.

Related discussion:
text: HTTP_WG; HTTP working group; ietf-http-wg@w3.org <del> 8.3. </del> <ins> 7.3. </ins> This document will request IANA to register the following entry in the "HTTP Field Name" registry:
Code change:
When reviewing the latest editors copy, the document structure leaps out at a bit odd by jumping from section 3 to section 5. That indicates to me these concepts are linked and also independent of the capsule protocol. So here I propose a minor restructure by moving the H3_DATAGRAM setting stuff to be a subsection of the HTTP/3 datagram format. This makes all the top-layer sections loosely coupled, which is nicer in my opinion.

Related discussion:
text: None <del> 8.4. </del> <ins> 7.4. </ins> This document establishes a registry for HTTP capsule type codes. The "HTTP Capsule Types" registry governs a 62-bit space.
Code change:
The draft currently states: However in PR , NAME points out that this "state" is not well defined. I agree, we should fix it. Thinking about this more, I don't think we need the concept of related state. We can instead just say that received datagrams MUST be silently dropped if the stream receive side is closed.
I agree with removing the concept of state is better. I don't want to be overly nitty and the proposed sentence is better but there also nothing like "the stream receive side", as there can be multiple streams (open and closed), that's why I proposed Or if we don't want state, then it would be:
That's not quite right: there cannot be multiple streams, as datagrams are strongly associated with a client-initiated bidirectional stream. I'd phrase the paragraph as: open. If a datagram is received after the receive side of the corresponding stream is closed, the received datagrams MUST be silently dropped.
That works. Thanks!
This answer is necessary because QUIC doesn't guarantee ordering, but is this necessarily true indefinitely? But can I regard a datagram that arrives an hour after the stream closes as an error?
If you keep track of QUIC packet numbers, you can see that the peer closed the stream before it sent the datagram which means they violated a MUST. You're welcome to error if you detect that, but I don't think we should mandate this level of tracking.
I'm not sure that that is a good strategy given how some deployments manage their packet numbers. I'm talking about maybe running a really long timer.
That introduces a way for an attacker to cause connection closure by delaying a specific packet. What problem are you trying to solve?
Good point. I thought that we did similar in a few places in QUIC. As you say, it's possible to enforce, but tricky. The concern I'd have is that this effectively forbids enforcement, but maybe that's OK.

Related discussion:
text: connection error of type H3_DATAGRAM_ERROR. HTTP/3 Datagrams MUST NOT be sent unless the corresponding stream's <del> send side is open.  Once the receive side of a stream is closed, incoming datagrams for this stream are no longer expected so related state can be released.  State MAY be kept for a short time to account for reordering.  Once the state is released, the received associated datagrams MUST be silently dropped. </del> <ins> send side is open.  If a datagram is received after the corresponding stream's receive side is closed, the received datagrams MUST be silently dropped. </ins> If an HTTP/3 datagram is received and its Quarter Stream ID maps to a stream that has not yet been created, the receiver SHALL either drop
Code change:
Written in response to
From in reference to the text in this PR: Issues ietf-wg-masque/draft-ietf-masque-connect-udp-listen (+0/-2/0) 2 issues closed: Improve document title URL [editorial] Should "connect-udp-listen" be registered as "Connect-UDP-Listen"? URL ietf-wg-masque/draft-ietf-masque-quic-proxy (+0/-0/2) 1 issues received 2 new comments: Virtual connection IDs in multi-hop settings (2 by DavidSchinazi, mirjak) URL Pull requests ietf-wg-masque/draft-ietf-masque-connect-udp-listen (+2/-2/1) 2 pull requests submitted: Update Listener to bind (by asingh-g) URL update connect-udp-listen to use H1 style (by asingh-g) URL 1 pull requests received 1 new comments: Compress away IP and Port using Context IDs (1 by asingh-g) URL 2 pull requests merged: Update Listener to bind ( URL update connect-udp-listen to use H1 style, URL ietf-wg-masque/draft-ietf-masque-quic-proxy (+0/-0/3) 1 pull requests received 3 new comments: Proxy-Chosen Virtual Client Connection ID (3 by DavidSchinazi, ehaydenr) URL Repositories tracked by this digest: URL URL URL URL URL URL URL
Roman Danyliw has entered the following ballot position for draft-ietf-masque-h3-datagram-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Thank you to David Mandelberg for the SECDIR review. ** Section 4. Consider adding the following clarification: NEW HTTP Datagrams and the Capsule Protocol are building blocks for HTTP extensions to define new behaviors or features and do not constitute an independent protocol. Any extension adopting them will need to perform an appropriate security analysis which considers the impact of these features in the context of a complete protocol.

Related discussion:
text: Tokens, it is not accessible from Web Platform APIs (such as those commonly accessed via JavaScript in web browsers). <ins> Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol need to perform a security analysis that considers the impact of HTTP Datagrams and Capsules in the context of their protocol. </ins> 5. 5.1.
Code change:
NAME points out that in order to correctly forward DATAGRAMs between transports where the QUIC DATAGRAM frame isn't always available, intermediaries need the ability to parse some capsules.
CAPSULE was easier to understand when it was fully opaque. When should I choose to define a semi-opaque CAPSULE vs defining a new frame? Aren't both constructs effectively hop-by-hop?
NAME you're the one who asked for this :-) The benefit of a semi-opaque capsule is that it allows defining new capsules without having to update every single intermediary in the chain, because intermediaries forward all unknown capsules.

Related discussion:
text: CAPSULE is an HTTP/3 Frame (as opposed to a QUIC frame) which SHALL only be sent in client-initiated bidirectional streams. <del> Intermediaries MUST forward all received CAPSULE frames in their unmodified entirety on the same stream where it would forward DATA frames.  Intermediaries MUST NOT send any CAPSULE frames other than the ones it is forwarding.  Intermediaries respect the order of CAPSULE frames: if an intermediary receives two CAPSULE frames in a given order, it MUST forward them in the same order. </del> <ins> Intermediaries forward received CAPSULE frames on the same stream where it would forward DATA frames.  Each Capsule Type determines whether it is opaque or transparent to intermediaries: opaque capsules are forwarded unmodified while transparent ones can be parsed, added, or removed by intermediaries. </ins> This specification of CAPSULE currently uses HTTP/3 frame type 0xffcab5.  If this document is approved, a lower number will be
Code change:
NAME points out that in order to correctly forward DATAGRAMs between transports where the QUIC DATAGRAM frame isn't always available, intermediaries need the ability to parse some capsules.
CAPSULE was easier to understand when it was fully opaque. When should I choose to define a semi-opaque CAPSULE vs defining a new frame? Aren't both constructs effectively hop-by-hop?
NAME you're the one who asked for this :-) The benefit of a semi-opaque capsule is that it allows defining new capsules without having to update every single intermediary in the chain, because intermediaries forward all unknown capsules.

Related discussion:
text: Data whose semantics depends on the Capsule Type. <ins> Unless otherwise specified, all Capsule Types are defined as opaque to intermediaries.  Intermediaries MUST forward all received opaque CAPSULE frames in their unmodified entirety.  Intermediaries MUST NOT send any opaque CAPSULE frames other than the ones it is forwarding. All Capsule Types defined in this document are opaque, with the exception of the DATAGRAM Capsule, see datagram-capsule.  Definitions of new Capsule Types MAY specify that the newly introduced type is transparent.  Intermediaries MUST treat unknown Capsule Types as opaque. Intermediaries respect the order of opaque CAPSULE frames: if an intermediary receives two opaque CAPSULE frames in a given order, it MUST forward them in the same order. </ins> Endpoints which receive a Capsule with an unknown Capsule Type MUST <del> silently drop that Capsule.  Intermediaries MUST forward Capsules, even if they do not know the Capsule Type or cannot parse the Capsule Data. </del> <ins> silently drop that Capsule. Receipt of a CAPSULE HTTP/3 Frame on a stream that is not a client- initiated bidirectional stream MUST be treated as a connection error of type H3_FRAME_UNEXPECTED. </ins> 4.1.
Code change:
NAME points out that in order to correctly forward DATAGRAMs between transports where the QUIC DATAGRAM frame isn't always available, intermediaries need the ability to parse some capsules.
CAPSULE was easier to understand when it was fully opaque. When should I choose to define a semi-opaque CAPSULE vs defining a new frame? Aren't both constructs effectively hop-by-hop?
NAME you're the one who asked for this :-) The benefit of a semi-opaque capsule is that it allows defining new capsules without having to update every single intermediary in the chain, because intermediaries forward all unknown capsules.

Related discussion:
text: how to process them from format also apply to HTTP/3 datagrams sent and received using the DATAGRAM capsule. <ins> The DATAGRAM Capsule is transparent to intermediaries, meaning that intermediaries MAY parse it and send DATAGRAM Capsules that they did not receive.  This allows an intermediary to reencode HTTP/3 Datagrams as it forwards them: in other words, an intermediary MAY send a DATAGRAM Capsule to forward an HTTP/3 Datagram which was received in a QUIC DATAGRAM frame, and vice versa. Note that while DATAGRAM capsules are sent on a stream, intermediaries can reencode HTTP/3 datagrams into QUIC DATAGRAM frames over the next hop, and those could be dropped.  Because of this, applications have to always consider HTTP/3 datagrams to be unreliable, even if they were initially sent in a capsule. </ins> 5. In order to facilitate extensibility of contexts, the
Code change:
Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.

Related discussion:
text: Endpoints which receive a Capsule with an unknown Capsule Type MUST silently drop that Capsule. <del> Receipt of a CAPSULE HTTP/3 Frame on a stream that is not a client- initiated bidirectional stream MUST be treated as a connection error of type H3_FRAME_UNEXPECTED. CAPSULE frames MUST NOT be sent on a stream before at least one HEADERS frame has been sent on that stream.  This removes the need to buffer capsules when the endpoint needs information from headers to determine how to react to the capsule.  If a CAPSULE frame is received on a stream before a HEADERS frame, the receiver MUST treat this as a connection error of type H3_FRAME_UNEXPECTED. </del> <ins> 4.4. </ins> <del> 4.1. </del> <ins> 4.4.1. </ins> The REGISTER_DATAGRAM_CONTEXT capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer of the
Code change:
Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.

Related discussion:
text: client MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. <del> 4.2. </del> <ins> 4.4.2. </ins> The REGISTER_DATAGRAM_NO_CONTEXT capsule (see iana-types for the value of the capsule type) allows a client to inform the server that
Code change:
Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.

Related discussion:
text: of contexts, and they MAY do so in a way which is opaque to intermediaries. <del> 4.3. </del> <ins> 4.4.3. </ins> The CLOSE_DATAGRAM_CONTEXT capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer that it will
Code change:
Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.

Related discussion:
text: extension, the endpoint MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. <del> 4.4. </del> <ins> 4.4.4. </ins> The DATAGRAM capsule (see iana-types for the value of the capsule type) allows an endpoint to send a datagram frame over an HTTP
Code change:
Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.

Related discussion:
text: 8. <del> We can provide DATAGRAM support in HTTP/2 by defining the CAPSULE frame in HTTP/2. We can provide DATAGRAM support in HTTP/1.x by defining its data stream format to a sequence of length-value capsules. TODO: Refactor this document and add definitions for HTTP/1.x and HTTP/2. 9. </del> Since this feature requires sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a server supports this feature.  Implementations that support this
Code change:
Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.

Related discussion:
text: the fact that there are applications using HTTP/3 datagrams enabled on this endpoint. <del> 10. 10.1. This document will request IANA to register the following entry in the "HTTP/3 Frames" registry: </del> <ins> 9. </ins> <del> 10.2. </del> <ins> 9.1. </ins> This document will request IANA to register the following entry in the "HTTP/3 Settings" registry: <del> 10.3. </del> <ins> 9.2. </ins> This document establishes a registry for HTTP capsule type codes. The "HTTP Capsule Types" registry governs a 62-bit space.
Code change:
Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.

Related discussion:
text: A name or label for the capsule type. <del> The value of the Capsule Type field (see capsule-frame) is a 62bit integer. </del> <ins> The value of the Capsule Type field (see capsule-protocol) is a 62bit integer. </ins> An optional reference to a specification for the type.  This field MAY be empty.