jiebi/CodeConvo huggingface dataset:
Change:
The only type of identifier defined by this specification is a fully- qualified domain name (type: "dns").  The value of the identifier <del> MUST be the ASCII representation of the domain name.  Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization requests. </del> <ins> MUST be the ASCII representation of the domain name.  If a domain name contains Unicode characters it MUST be encoded using the rules defined in RFC3492.  Servers MUST verify any identifier values that begin with the ASCII Compatible Encoding prefix "xn-" as defined in RFC5890 are properly encoded.  Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization requests. </ins> 6.2.

Discussion:
requires IDNs be encoded in this way in order to be stored in the X509 certificate dNSNames field. Compliance with this RFC is one of the requirements of the CABForum which CAs are expected to adhere to. We already require domain names transmitted via ACME to use the ASCII encoding, this just formalizes how IDNs should be converted.
Change:
8.2. <del> This document updates the "Token Type" Registry with the following values. </del> <ins> This document updates the "Token Type" Registry from AUTHSCHEME, Section 5.2 with the following values. </ins> 8.3.

Discussion:
There's and . I'm guessing these should be collapsed to just one.
table 2 says: -- | -- and Section 8.1 says: What is the Token Type registry and what are the constraints on values in the registry? It's implied that values should be integers but JSON numbers are quite flexible, so would it be valid for me to register e.g. a negative integer. If the "Token Type" registry already exists, I'm not able to find it and a link would be useful. If it doesn't exist and this document wishes to create it, then more work is needed to establish that registry and it's procedures.
We're missing a link to the HTTP auth document, where the registry is defined. Good catch!
Change:
If User Equipment supports the Captive Portal API, it MUST validate the API server's TLS certificate (see RFC2818).  An Enforcement <del> device SHOULD allow access to any services that User Equipment could </del> <ins> Device SHOULD allow access to any services that User Equipment could </ins> need to contact to perform certificate validation, such as OCSP responders, CRLs, and NTP servers; see Section 4.1 of I-D.ietf- capport-api for more information.  If certificate validation fails,

Discussion:
We were using "Captive Portal Enforcement", "Captive Portal Enforcement Device" and "Enforcement Device", with varying capitilisation, inconsistently throughout the document. Address that by defining the component as "Captive Portal Enforcement Device", and using that term in section headings, and "Enforcement Device" everywhere else. Fixes issue
Looks good to me
Used in different ways: Captive Portal Enforcement, enforcement device, etc.
I think keeping it shorter is likely better. ? Caps to make it clear it's a first class component in the architecture?
Change:
data inside an HTTP connection.  While HTTP datagrams are associated with HTTP requests, they are not part of message content; instead, they are intended for use by HTTP extensions (such as the CONNECT <del> method), and are compatible with all versions of HTTP.  When the underlying transport protocol supports unreliable delivery (such as when the QUIC DATAGRAM extension is available in HTTP/3), they can use that capability. </del> <ins> method), and are compatible with all versions of HTTP. When HTTP is running over a transport protocol that supports unreliable delivery (such as when the QUIC DATAGRAM extension is available to HTTP/3), HTTP Datagrams can use that capability. </ins> This document also describes the HTTP Capsule Protocol in capsule, to <del> allow conveyance of HTTP Datagrams when the QUIC DATAGRAM frame is unavailable or undesirable, such as when earlier versions of HTTP are in use. </del> <ins> allow conveyance of HTTP Datagrams using reliable delivery.  This addresses HTTP/3 cases where use of the QUIC DATAGRAM frame is unavailable or undesirable, or where the transport protocol only provides reliable delivery, such as with HTTP/1 or HTTP/2 over TCP. </ins> 1.1.

Discussion:
Section 1. "When the underlying transport protocol supports unreliable delivery (such as when the QUIC DATAGRAM extension is available in HTTP/3), they can use that capability." "This document also describes the HTTP Capsule Protocol in Section 3, to allow conveyance of HTTP Datagrams when the QUIC DATAGRAM frame is unavailable or undesirable, such as when earlier versions of HTTP are in use." To me there is a bit of mismatch between these two sentences and what HTTP/3 is prior to this extension. The first indicate that datagram support is a capability of the underlying transport for the HTTP version but then link it hard to HTTP/3. While the HTTP/3 support is dependent on this extension in addition to a QUIC stack having Datagram support. While the second takes it as a property of the HTTP version, where it is assumed that earlier version can't support this, i.e. those that are defined to use TCP only. Technically a HTTP/3 endpoint with a QUIC stack without datagram support can use capsules and this document does not require an endpoint to support QUIC datagram. And the second statement should likely use a statement saying like … unavailable or undesirable, such as when TCP is used as transport protocol as with HTTP/1.x and HTTP/2.
Fair point, HTTP 1 and 2 don't strictly require TCP either. I think we can tweak these opening paragraphs a little to be more consistent and clear.
SGTM
Looks great modulo one tweak
Change:
than the server's advertised idle timeout, and SHOULD do so if approaching the idle timeout. <del> HTTP clients are expected to use QUIC PING frames to keep connections open while there are responses outstanding for requests or server pushes.  If the client is not expecting a response from the server, allowing an idle connection to time out is preferred over expending effort maintaining a connection that might not be needed.  A gateway MAY use PING to maintain connections in anticipation of need rather than incur the latency cost of connection establishment to servers. Servers SHOULD NOT use PING frames to keep a connection open. </del> <ins> HTTP clients are expected to request that the transport keep connections open while there are responses outstanding for requests or server pushes, as described in Section 19.2 of QUIC-TRANSPORT.  If the client is not expecting a response from the server, allowing an idle connection to time out is preferred over expending effort maintaining a connection that might not be needed.  A gateway MAY maintain connections in anticipation of need rather than incur the latency cost of connection establishment to servers.  Servers SHOULD NOT actively keep connections open. </ins> 6.2.

Discussion:
The transport Draft states: This guidance was added to the HTTP Draft in , but was subsequently removed.
I guess that something to discuss in the applicability draft as well
Looks like made this text more generic, leaving the specifics of how to keep a connection alive (e.g. with PING frames) to the transport implementation. The text in question is now in Section 5.1: It's possible the transport draft needs a similar generalization, to recommend implementations expose a way for the application layer to control whether an connection is idle.
Actually there is a section on "Session resumption versus Keep-alive" in the applicability draft already. Do we need to say more? Is that needed in the transport draft as well?
In , the direction of the discussion is that PING frames are an application-layer concept that won't necessarily be directly under the application-layer's control. The HTTP draft currently says: This should be reworded in terms of requesting the transport stack to keep the connection from idling out, rather than directly discussing PING frames.
Or maybe we just need to kinds of PING?
Gah! Not more types of PING please!
KEEPTHECARRUNNING frame (ID=0xAF)
Change:
to ECHConfig, as follows: If decryption fails, the server MUST abort the connection with a <del> "decrypt_error" alert.  Otherwise, the server scans ClientHelloInner for an "outer_extension" extension and substitutes its value with the values in ClientHelloOuter and validates the ClientHelloInner digest, as described in outer-extensions. </del> <ins> "decrypt_error" alert.  Otherwise, the server reconstructs ClientHelloInner from EncodedClientHelloInner, as described in outer- extensions. </ins> Upon determining the true SNI, the client-facing server then either serves the connection directly (if in Shared Mode), in which case it

Discussion:
Along the way, I've made two additional tweaks: Renamed outerextension to outerextensions, now that it contains multiple extensions. One of the diagrams even already referred to "outerextensions" because I didn't realize it was called "outerextension".Clarified in compression process and ClientHelloInner construction rules that the to-be-compressed extensions must be consecutive. Hopefully that helps with .
NAME FYI. I'm hoping this will help clarify why the ordering thing isn't actually a big deal.
I've updated the PR to include text to disambiguate the serialization. It's ambiguous whether the encoding includes the 4-byte (12-byte in DTLS) header from the Handshake structure or is just the body, from the ClientHello structure. I've picked the smaller one. This also saves having to answer, in DTLS, what happens when the inner sequence number is wrong.
There are two ClientHelloInners, the actual one used in the handshake, and the encoded one with outerextensions substituted in. Both are described as ClientHelloInner, but this makes it slightly ambiguous which goes into, say, the handshake transcript. (It's late now, so I'll leave this as an issue without a PR. If we don't end up resolving this separately, I'll probably fix this as part of . If we decide to implicitly copy over legacysession_id, the encryption payload becomes less and less defensibly an actual ClientHelloInner.)
In my own implementation, I've been referring to the plaintext payload as CompressedClientHelloInner. Which is terrible, but unambiguous.
Works for me. I was thinking EncodedClientHelloInner because it's shorter and still works even if you choose not to compress anything. (A no-op encoding is still an encoding.)
+1 to EncodedClientHelloInner, given that compression is optional. NAME if you have time, could you whip up a PR?
Change:
that the physical-layer knows what coding scheme to use.  Following the taxonomy document RFC8406, channel and link codings are gathered in the PHY layer coding and are out of the scope of this document. <ins> This document considers FEC as coding mechanisms above the network layer only. </ins> fig:existing_network presents the status of the reliability schemes deployment in satellite systems.

Discussion:
John Border: Forward Error Correction (FEC) coding below the network layer takes us a long way. At the same time, I think network coding has a lot to offer re reducing retransmission delay when the FEC coding is not enough. I do see that the referenced taxonomy document includes Forward Erasure Correction. This “FEC” is described as an application layer technique. The overlapping use of “FEC” is unfortunate for those of who work down at the lower layers. In any case, it is not always clear which “FEC” the document is referring to.
I understand that there is some confusion on the usage of the accronym. We have clarified in the document that "Following the taxonomy document [RFC8406], channel and link codings are gathered in the PHY layer coding and are out of the scope of this document." We have added in PR that this document considers FEC above the network layer.
Change:
2.1.1. <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. </del> <ins> Implementations of HTTP/3 that are willing to receive HTTP Datagrams can indicate that to their peer by sending the H3_DATAGRAM SETTINGS parameter with a value of 1. </ins> The value of the H3_DATAGRAM SETTINGS parameter MUST be either 0 or <del> 1.  A value of 0 indicates that HTTP Datagrams are not supported.  If the H3_DATAGRAM SETTINGS parameter is received with a value that is neither 0 or 1, the receiver MUST terminate the connection with error H3_SETTINGS_ERROR. </del> <ins> 1.  A value of 0 indicates that the implementation is not willing to receive HTTP Datagrams.  If the H3_DATAGRAM SETTINGS parameter is received with a value that is neither 0 or 1, the receiver MUST terminate the connection with error H3_SETTINGS_ERROR. </ins> QUIC DATAGRAM frames MUST NOT be sent until the H3_DATAGRAM SETTINGS parameter has been both sent and received with a value of 1.

Discussion:
The current text talks about "supporting" HTTP/3 datagrams. It seems we could tighten this up to be more about the willingness to receive datagrams a la URL
SGTM
Change:
The client MAY use this PSK for future handshakes by including the ticket value in the "pre_shared_key" extension in its ClientHello <del> (pre-shared-key-extension).  Servers MAY send multiple tickets on a single connection, either immediately after each other or after </del> <ins> (pre-shared-key-extension).  Resumption MAY be done while the original connection is still open.  Servers MAY send multiple tickets on a single connection, either immediately after each other or after </ins> specific events (see client-tracking).  For instance, the server might send a new ticket after post-handshake authentication in order to encapsulate the additional client authentication state.  Multiple

Discussion:
Resumption before the initial connection is closed does not seem to be forbidden but RFC 8446 does not really give any answers. Oxford dictionary defines resumption as "the action of beginning something again after a pause or interruption." but I think "resumption" should just be seen as a slightly misleading name for the mechanism. RFC 8446 makes it clear that a connection can result in several tickets and that these tickets can be used in parallel with each other. My assumption would be that the tickets can also be used in parallel with the initial connection. If that is the case it would be good to state this. If not, it would be good to state that as well. The question came up in RFC6083bis where the suggestion is to set up parallel connections. I made a PR with the assumption that it’s allowed. I don’t see any reasons to forbid it, but I might miss something.
I concur that resumption should be permitted once the initial connection is established. I would prefer not to change the name, just because it's historically confusing not to.
Rich asked about SNI, but there are other values for extensions that might be included in a resumption handshake to cover the possibility that the session cannot be resumed. We should probably talk about that a little in the draft, maybe even throw a few "MUST" or "SHOULD" statements at it.
Resumption replaced by PSK so this is generally OBE.
Change:
the primary and RTX SSRCs. If FEC is supported for this media type, another "a=ssrc" line <del> with the FEC SSRC, and an "a=ssrc-group" line, as specified in RFC5576, section 4.2, with semantics set to "FEC" and including the primary and FEC SSRCs. </del> <ins> with the FEC SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR" and including the primary and FEC SSRCs, as specified in RFC5956, section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. </ins> [OPEN ISSUE: Handling of a=imageattr]

Discussion:
This looks basically good. I see one missing reference and some places where I think the text might read better. Feel free to ignore my advice on the text, but you should probably fix the reference
PTAL
LGTM
Depends on resolution of FEC on mailing list
This will be dealt with in a future rev.
Justin, where are we here? Should I unmark this discuss?
Unmark as discuss since we need a proposal to discuss first (which I have the action for)
Action to write draft here listing FEC mechanisms that are MTI
Draft completed; now we just need JSEP to refer to uberti-rtcweb-fec.
Change:
informative. The field is a non-empty List of Items.  Each item is a quota-policy. <ins> Two quota policies MUST NOT be associated with the same quota units value. </ins> This field can convey the time window associated with the expiring- limit, as shown in this example: These examples show multiple policies being returned: <ins> An example of invalid header field value with two policies associated with the same quota units: </ins> This field cannot appear in a trailer section. 3.3.

Discussion:
clarify that quota policies are unique in policy.
If server defines two policies, e.g. and the response header contains, How do I know if I can make 2 more requests, or download 2 more bytes? Is having multiple policies with different quota units not allowed?
Good catch! The list items MUST be unique. I will specify this for now. WDYT about switching Policy to a Dictionary? This requires some tweak though e.g. prefixing the units with . cc: NAME
I'd use a short name for the policy, so that it could be referred to separately; e.g.,
Change:
encoding both the content and the keys using the various key management techniques, is a requirement that all of the key management techniques use an Authenticated Encryption (AE) algorithm. <del> When encrypting the plain text, it is normal to use an Authenticated Encryption with Additional Data (AEAD) algorithm.  For key management, either AE or AEAD algorithms can be used.  See AE-algo for more details about the different types of algorithms. The structure has two maps where data about the content can be placed.  The data placed here is also the data which is used to control how the decryption is to be done for this object.  When data is placed in these two structures, it is extremely poor practice to have data which is applicable to a different level.  For example, the unprotected field at the level of a key management decryption should not contain information either about how to interpret the plain text (i.e. content type) or how to convert the cipher text back to plain text (i.e. the kid for the recipient). </del> <ins> (For the purpose of this document we use a slightly loose definition of AE algorithms.)  When encrypting the plain text, it is normal to use an Authenticated Encryption with Additional Data (AEAD) algorithm.  For key management, either AE or AEAD algorithms can be used.  See AE-algo for more details about the different types of algorithms. The CDDL grammar structure for encryption is: </ins> Description of the fields:

Discussion:
Add new tables to the end of the document about parameters which talk about types and possible column for integer indexes in the future
Change:
Handshake structure's four byte header.  The "zeros" field MUST be all zeroes. <del> The client then MAY substitute extensions which it knows will be duplicated in ClientHelloOuter.  To do so, the client removes and replaces extensions from EncodedClientHelloInner with a single "ech_outer_extensions" extension.  Removed extensions MUST be ordered consecutively in ClientHelloInner.  The list of outer extensions, OuterExtensions, includes those which were removed from EncodedClientHelloInner, in the order in which they were removed. </del> <ins> Repeating large extensions, such as "key_share" with post-quantum algorithms, between ClientHelloInner and ClientHelloOuter can lead to excessive size.  To reduce the size impact, the client MAY substitute extensions which it knows will be duplicated in ClientHelloOuter.  It does so by removing and replacing extensions from EncodedClientHelloInner with a single "ech_outer_extensions" extension, defined as follows: OuterExtensions contains the removed ExtensionType values.  Each value references the matching extension in ClientHelloOuter.  The values MUST be ordered contiguously in ClientHelloInner, and the "ech_outer_extensions" extension MUST be inserted in the corresponding position in EncodedClientHelloInner.  Additionally, the extensions MUST appear in ClientHelloOuter in the same relative order.  However, there is no requirement that they be contiguous. For example, OuterExtensions may contain extensions A, B, C, while ClientHelloOuter contains extensions A, D, B, C, E, F. The "ech_outer_extensions" extension can only be included in EncodedClientHelloInner, and MUST NOT appear in either ClientHelloOuter or ClientHelloInner. </ins> Finally, the client pads the message by setting the "zeros" field to a byte string whose contents are all zeros and whose length is the

Discussion:
Inspired by NAME . We can go further and just completely define EncodedClientHelloInner first.
Change:
5.4. <del> A Retry or Version Negotiation packet causes a client to send another Initial packet, effectively restarting the connection process and resetting congestion control and loss recovery state, including resetting any pending timers.  Either packet indicates that the Initial was received but not processed.  Neither packet can be treated as an acknowledgment for the Initial. The client MAY however compute an RTT estimate to the server as the time period from when the first Initial was sent to when a Retry or a </del> <ins> A Retry packet causes a client to send another Initial packet, effectively restarting the connection process.  A Retry packet indicates that the Initial was received, but not processed.  A Retry packet MUST NOT be treated as an acknowledgment. Clients that receive a Retry packet reset congestion control and loss recovery state, including resetting any pending timers.  Other connection state, in particular cryptographic handshake messages, is retained; see Section 17.2.5 of QUIC-TRANSPORT. The client MAY compute an RTT estimate to the server as the time period from when the first Initial was sent to when a Retry or a </ins> Version Negotiation packet is received.  The client MAY use this <del> value to seed the RTT estimator for a subsequent connection attempt to the server. </del> <ins> value in place of its default for the initial RTT estimate. </ins> 5.5.

Discussion:
This section was well out of date. Also, this covers what needs to be retained across this transition better. Basically, the only thing that needs to go is the congestion and loss recovery state. The rest can stay; in fact, the crypto handshake has to stay.
Follow-up to . As NAME suggests, we might want to add text to the transport draft that enumerates what is reset: all state except for connection IDs, packet numbers and, optionally, an RTT measurement.
Thanks, nice update!
Change:
additional offer/answer exchanges. Regarding ICE RFC8445, JSEP decouples the ICE state machine from the <del> overall signaling state machine, as the ICE state machine must remain in the JSEP implementation, because only the implementation has the </del> <ins> overall signaling state machine.  The ICE state machine must remain in the JSEP implementation because only the implementation has the </ins> necessary knowledge of candidates and other transport information. Performing this separation provides additional flexibility in protocols that decouple session descriptions from transport.  For

Discussion:
This includes Removing my postal address. Mozilla closed that office. small editorial changes Removing bogus whitespace.
NAME PTAL
NAME I think I've got your changes and we are ready to land?
LGTM