jiebi/CodeConvo huggingface dataset:
Change:
sdp, Section 5.1, and, if appropriate, an "a=max-message-size" line, as defined in I-D.ietf-mmusic-sctp-sdp, Section 6.1. <del> As discussed above, the following attributes are included only if the m= section is not bundled into another m= section: "a=ice-ufrag", "a=ice-pwd", "a=fingerprint", "a=dtls-id", and "a=setup". </del> <ins> As discussed above, the following attributes of category IDENTICAL or TRANSPORT are included only if the data m= section is not bundled into another m= section: "a=ice-ufrag" "a=ice-pwd" "a=fingerprint" "a=setup" "a=dtls-id" Note that if media m= sections are bundled into a data m= section, then certain TRANSPORT and IDENTICAL attributes may also appear in the data m= section even if they would otherwise only be appropriate for a media m= section (e.g., "a=rtcp-mux"). </ins> If "a=group" attributes with semantics of "BUNDLE" are offered, corresponding session-level "a=group" attributes MUST be added as

Discussion:
NAME PTAL at this. I realized the answer section also needed to be updated to match the new offer text, so I made some changes there which involved a bit of massaging of the text added in .
LGTM
Change:
When a client creates a QUIC connection, its goal is to use an application layer protocol.  Therefore, when considering which versions are compatible, clients will only consider versions that <del> support the intended application layer protocol. </del> <ins> support one of the intended application layer protocols.  For example, if the client's first flight advertises multiple Application Layer Protocol Negotiation (ALPN) RFC7301 tokens and multiple compatible versions, the server needs to ensure that the ALPN token that it selects can run over the QUIC version that it selects. </ins> 4.

Discussion:
Mix recommendations of NAME and NAME
LGTM
The document currently says: However, as we see with HTTP over TCP, clients routinely offer "h2", "http/1.1" and are content with either selection. Particularly if ALPN tokens map 1:1 to QUIC versions as specified in H3, the client's goal might be to use any of a collection of application-layer protocols. Perhaps tweak this to "...support one of the intended application layer protocols."? The first statement might or might not need to be expanded as well.
Perhaps we add a sentence after the ones you quoted along the lines of "For example, if the client's first flight advertises multiple ALPN tokens and multiple compatible versions, the server needs to ensure that the ALPN token that it selects can run over the QUIC version that it selects."
Change:
SETTINGS frames always apply to a connection, never a single stream. A SETTINGS frame MUST be sent as the first frame of each control stream (see control-streams) by each peer, and MUST NOT be sent <del> subsequently or on any other stream.  If an endpoint receives a SETTINGS frame on a different stream, the endpoint MUST respond with a connection error of type HTTP_WRONG_STREAM.  If an endpoint receives a second SETTINGS frame, the endpoint MUST respond with a connection error of type HTTP_UNEXPECTED_FRAME. </del> <ins> subsequently.  If an endpoint receives a second SETTINGS frame on the control stream, the endpoint MUST respond with a connection error of type HTTP_UNEXPECTED_FRAME. SETTINGS frames MUST NOT be sent on any steam other than the control stream.  If an endpoint receives a SETTINGS frame on a different stream, the endpoint MUST respond with a connection error of type HTTP_WRONG_STREAM. </ins> SETTINGS parameters are not negotiated; they describe characteristics of the sending peer, which can be used by the receiving peer.

Discussion:
by clearly splitting the two different error cases.
Moves existing text to be clearer, but doesn't change the stated requirements. Editorial, and fine by me.
It's unclear which error should be reported if an endpoint receives a second SETTINGS frame on any stream that's not a control stream. Perhaps this should be explicitly defined in the draft?
Hey NAME I initially thought this was an editorial problem so created as an attempt to clarify things. However, I think the question is more philosophical. To analyse it a bit, what you're asking is how to handle an error after the occurrence of a critical connection error. First, a SETTINGS frame on a wrong stream type, then another SETTINGS frame on a wrong stream. After the first critical error, all bets are off. I'd expect a lot implementations to just give up at that stage as the peer is likely to be misbehaving.
I agree its an edge case but I do think it'd be useful to exactly specify which of the two errors should be reported, especially when thinking of automated testing of HTTP/3 implementations.
I'm sympathetic to that but I fear this could be a slippery slope towards adding lots of text for issues that occur after a critical close event. PRIORITY frames fall into a similar bucket, along with many of the server push frames and their validation rules.
I think the real unclarity in the spec is that both can happen simultaneously. After receiving a proper SETTINGS frame on the control channel, receiving a SETTINGS frame on some other stream would be both a second SETTINGS frame and a SETTINGS frame on the wrong stream. clarifies this reasonable. Thanks, both of you!
Change:
could become blocked to the value of SETTINGS_QPACK_BLOCKED_STREAMS at all times.  If a decoder encounters more blocked streams than it promised to support, it MUST treat this as a connection error of type <del> HTTP_QPACK_DECOMPRESSION_FAILED. </del> <ins> QPACK_DECOMPRESSION_FAILED. </ins> Note that the decoder might not become blocked on every stream which risks becoming blocked.

Discussion:
I noticed that the QPACK error codes still started with the HTTPQPACK prefix, while the HTTP document has shifted to H3 as the prefix. I shortened the QPACK prefix to simply "QPACK", though "H3QPACK" could work, too. Along the way, I noticed that backticks were sometimes, but not always, used when referring to the error code names. We haven't been in the HTTP document, so I reconciled them to not. Again, this could go the opposite way. I also noticed that the settings are "SETTINGSQPACK" except in the IANA registration where they're simply "QPACK". I didn't touch those, but am open to feedback on whether that's worth trimming/reconciling.
NAME I don't need your approval, but I kind of do need NAME
Well, you did ask :)
NAME could you review and potentially merge?
Do it. You don't need my approval to do something that is so self-evidently a good idea.QPACK_ prefix WFM
Change:
that of any valid ECHConfig, which could include any ECHConfig that has been recently removed from active use. <del> The longest name of a backend server, if known.  If this value is not known it can be set to zero, in which case clients SHOULD use the inner ClientHello padding scheme described below.  That could happen if wildcard names are in use, or if names can be added or removed from the anonymity set during the lifetime of a particular ECH configuration. </del> <ins> The longest name of a backend server, if known.  If not known, this value can be set to zero.  It is used to compute padding (padding) and does not constrain server name lengths.  Names may exceed this length if, e.g., the server uses wildcard names or added new names to the anonymity set. </ins> The non-empty name of the client-facing server, i.e., the entity trusted to update the ECH configuration.  This is used to correct

Discussion:
While padding is "described below", it's pretty far away now. We also recommend the padding scheme whether or not the value is non-zero. The text about wildcard names also applies in both cases and seems to describe when the server name may exceed the max. This rephases things a bit.
Change:
transport services, while simplifying the application's role in parsing data. <del> 1.4. </del> <ins> 2.3. </ins> Sockets, for protocols like TCP, are generally limited to connecting to a single address over a single interface.  They also present a

Discussion:
Based on discussion with NAME rearrange things to put a proper document overview in the intro, and split out the API Model discussion into its own section outside of the introduction.
LGTM (modulo one nit)Thank you NAME to do this - really improves the structure.
Change:
The connection is reliable.  Messages include an authentication tag which protects them against modification. <del> Note: The TLS Record Protocol can operate in an insecure mode but is generally only used in this mode while another protocol is using the TLS Record Protocol as a transport for negotiating security parameters. </del> The TLS Record Protocol is used for encapsulation of various higher- level protocols.  One such encapsulated protocol, the TLS Handshake Protocol, allows the server and client to authenticate each other and

Discussion:
and arguably should never be used in that fashion. I know that this stuff badly needs a rewrite, but this is just egregious.
Change:
specified, and MUST NOT issue a certificate with contents other than those requested.  If the server requires the request to be modified in a certain way, it should indicate the required changes using an <del> appropriate error code and description. </del> <ins> appropriate error type and description. </ins> If the server is willing to issue the requested certificate, it responds with a 201 (Created) response.  The body of this response is

Discussion:
Usage of is slightly confusing when we are not using int-enumerated error codes. RFC 7807 also refers to the problem document error types as and the field is called so this seems to make the most sense.
Change:
of a flow pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc) in Linux (3.11 onwards). <del> 6.9. </del> <ins> 6.10. </ins> When bytes in flight is smaller than the congestion window and sending is not pacing limited, the congestion window is under-

Discussion:
Clarifies a few points and moves the initial window recommendation from the pseudocode to the text. I could take this a bit farther, but I'd like suggestions on what's currently missing in this PR.
LGTM
It starts like this: The next sections below roughly describe the behavior of different phases of congestion control. More concrete pseudo-code is only given in the Appendix later on but it's not linked from the original section. On first reading, I missed the Appendix and felt the text lacking for concrete enough explanations to implement the feature. The question is what to describe where and what the authoritative definitions should be. If you know the NewReno RFC by heart you can probably make the right inferences to figure out how everything should work in comparison but is that how it should be? An alternative (more convenient for the reader / skimmer) approach could be to mention NewReno only in passing and then provide a complete and self-contained description of the algorithms in the congestion control section directly, maybe even inlining the pseudo-code. If that is deemed to verbose and would bore readers that know enough about those algorithms already, it would be good to provide some guidance how to read the algorithm and what the assumptions are in the introductory paragraph about congestion control.
The intent is that the text is complete without reading the referenced RFCs or pseudocode, so I think this section needs more text and possibly some inlined pseudo-code.
Hi NAME I wrote which fixes some obvious errors I found, but I think more could be done. Can you take a look and tell me what other points you'd like added or moved up from the pseudocode?
Looks good! Thanks!
Change:
If the HelloRetryRequest message is used, the initial ClientHello and the HelloRetryRequest are included in the calculation of the <del> Transcript-Hash.  The computation of the message hash for the </del> <ins> transcript hash.  The computation of the message hash for the </ins> HelloRetryRequest is done according to the description in Section 4.4.1 of I-D.ietf-tls-tls13.

Discussion:
"Transcript-Hash" is the name of the function. I belive it would be more appropriate to use the "transcript hash" term here.
Change:
sequence of a specific transaction.  (Definition from RFC6891, Section 6.1.1) It is used by EDNS. <del> The domain name where a RR is found (RFC1034, Section 3.6).  Often appears in the term "owner name". </del> <ins> "The domain name where a RR is found" (Quoted from RFC1034, Section 3.6).  Often appears in the term "owner name". </ins> DNS documents, including the definitions here, often refer to the fields in the RDATA of an SOA resource record by field name.

Discussion:
I like the additional wording. I'll add it and take the question to the chairs to take to the WG.
Good catch on "DNS over TLS" -> "DNS over HTTPS". I didn't go with "DNS Queries over HTTPS" because it doesn't really describe the protocol.
Simple mistake: "DNS over TLS" should be "DNS over HTTPS" at line 1040. Or "DNS Queries over HTTPS" may be better because it is a draft name.If we're going to add class here, then I think (1) we need to go back to the WG and (2) we need to add something: "In practice, the class for nearly every query is IN. There are some queries for CH, but they are usually for the purposes of information about the server itself rather than for a different type of address" I wrote a doc some time ago attempting to deprecate class, because of the way it keeps popping up as though it is viable.
Change:
as the hostname is expected to be unique, the ICE agent SHOULD skip probing of the hostname. <del> If registering of the mDNS hostname fails, abort these steps.  The candidate is not exposed. </del> Store the mDNS hostname and its related IP address in the ICE agent for future reuse.

Discussion:
Fixes URL
An implementation should probably expose mDNS candidates to a page regardless of successful registration or mDNS support in the network.
Change:
%%% Key Exchange Messages <del> All versions of TLS allow extensions to optionally follow the compression_methods field as an extensions field.  TLS 1.3 ClientHellos will contain at least two extensions, "supported_versions" and either "key_share" or "pre_shared_key".  The presence of extensions can be detected by determining whether there are bytes following the compression_methods at the end of the ClientHello.  Note that this method of detecting optional data differs from the normal TLS method of having a variable-length field, but it is used for compatibility with TLS before extensions were defined.  TLS 1.3 servers will need to perform this check first and only attempt to negotiate TLS 1.3 if a "supported_version" extension is present. </del> In previous versions of TLS, this field was used for version negotiation and represented the highest version number supported by the client.  Experience has shown that many servers do not

Discussion:
This tweaks some text in ClientHello with regard to handling the extensions field. The two blocks of text on it in this section are merged together, dropping a little repeated information and putting it in one paragraph after definition of the relevant field instead of covering this in two places in the same section.
Change:
4.4. <del> In CoAP over TCP, Empty messages can always be sent and will be ignored.  This provides a basic keep-alive function that can refresh NAT bindings.  In contrast, Ping and Pong messages are a bidirectional exchange. </del> <ins> In CoAP over TCP, Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient (see also sec-ping).  This provides a basic keep-alive function that can refresh NAT bindings.  In contrast, Ping and Pong messages are a bidirectional exchange. </ins> Upon receipt of a Ping message, a single Pong message is returned with the identical token.  As with all Signaling messages, the

Discussion:
Consistent language for empty messages. Edits to Signaling section - including replacing Default Value in tables with Base Value for clarity.
Change:
"record_overflow" alert. <del> The AEAD encrypted form of TLSPlaintext.fragment. </del> <ins> The cleartext of TLSPlaintext.fragment. The actual content type of the record. The AEAD encrypted form of TLSPlaintext.fragment + TLSPlaintext.type, where "+" denotes concatenation. </ins> The length of the per-record nonce (iv_length) is set to max(8 bytes, N_MIN) for the AEAD algorithm (see RFC5116 Section 4).  An AEAD

Discussion:
This pull request has been updated to the current master
Consensus at meeting to merge this PR with updates and with the dummy type byte restored. NAME has action item to actually measure whether we can strip off the now fixed type, record.version bytes.
I've updated this with the expected changes: dummy external ContentType octet is restored, and URL is after fragment.content instead of the other way around (to make it easier to encrypt without having to shuffle buffers).
I agree with davegarrett's suggestion about field naming here, and have supplied a change implementing it.
TLSCiphertext.recordversion provides no useful information, encourages implementations to check it unnecessarily, and wastes two bytes per record. It should be removed entirely. This is effectively dependent on PR or similar changes. Filing this as a specific issue rather than just bringing it up in backwards compatibility discussion. Edited to add: Note that this value is called TLSCiphertext.version in TLS 1.2 and TLSCiphertext.recordversion as of TLS 1.3 draft 06. The TLSPlaintext equivalent of this version field cannot be removed as it is required for backwards compatibility, however it's only used with ClientHello at this point.
Defer pending measurements. Note that this fate shares with removing the cleartext content type
sgtm Amending issue title.
Mozilla is working on measurements.
Change:
exact same number as the offer. Lastly, while the exact media parameters are only known only after an <del> offer and an answer have been exchanged, it is possible for the offerer to receive media after they have sent an offer and before they have received an answer.  To properly process incoming media in this case, the offerer's media handler must be aware of the details of the offer before the answer arrives. </del> <ins> offer and an answer have been exchanged, the offerer may receive ICE checks, and possibly media (e.g., in the case of a re-offer after a connection has been established) before it receives an answer.  To properly process incoming media in this case, the offerer's media handler must be aware of the details of the offer before the answer arrives. </ins> Therefore, in order to handle session descriptions properly, the user agent needs:

Discussion:
Section 3.2 has a paragraph starting "Lastly, while the actual media parameters are only know after an offer..."; the entire contents of this paragraph appear to be actually false if both ICE and DTLS are in use. I know there's conversation underway on MMUSIC and the WebRTC mailing lists on this topic, but none of them have yet described a situation in which this paragraph is actually true. Please remove it or add a sequence diagram showing how it arises.
It may not be able to receive media (due to lack of DTLS fingerprint), but it can certainly receive ICE checks. We should clarify accordingly.
Change:
make use of a so called running hash, this is a design choice as running hashes are often not supported on constrained platforms. <ins> When parsing a received EDHOC message, implementations MUST terminate the protocol if the message does not comply with the CDDL for that message.  It is RECOMMENDED to terminate the protocol if the received EDHOC message is not deterministic CBOR. </ins> 9. 9.1.

Discussion:
It is stated that EDHOC uses deterministic CBOC, but EDHOC could still be non-deterministic if is allows a choice between e.g., bstr and int. Add that the encodig in EDHOC is deterministic. Add some considerations regarding decoding. In any cryptographic protocols the optimal for security is that the decoder raises a fatal error if the something in the encoding is enexpected. E.g. wrong order in map or two byte encoding of the integer 7. This is however not supported by CBOR implementations so it cannot be mandated. The security issues with a allowing decoder is that is gives options to an attacker. If the hash function has some weakness, An attacker can e.g. try all n! permutations of a map with n elements until they find a collision. This is not critical but it might be guidance that a decoder that only tolerated deterministic CBOR might have security benefits.
That would be interesting, notably as it was mentioned as an attack surface previously (). Bellow is an additional example of the kind of weird things that can go on when everything is not nice and deterministic. Consider an attacker that can only modify messages going from Rresponder R to Initiator I, but not send its own messages to R. Then, the identity of R should intuitively be anonymous. This could be the case of an attacker only sitting next to the device I, and who wants to know from whom I is receiving messages. The attacker wants to tests if some I is communicating with some fixed identity . This attacker may intercept the message2 encrypted part: . Now assume that there exists a second distinct encoding of , that we call . The attacker can then compute . Now, two options, either , in which case the message received by I is , which will successfully proceed. If , the processing of the message will fail. And thus, the attacker can learn if I is talking to or not. Remark that in both cases, the key exchange will fail at the next step as parties will disagree on .
Decoding considerations should consider deterministic CBOR, CDDL, and anything outside CBOR and CDDL.
The text about decoding should recommend to abort if encoding not deterministic.
"All EDHOC messages are deterministically encoded CBOR Sequences {{RFC8742}}." Do we need to clarify the meaning of "deterministically encoded CBOR Sequences"? Readers may be lead to believe it is defined in RFC8742.
Change:
11. Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders <del> Brandt, Matthieu Vial, Mohit Sethi, Sampo Ukkola, Linyi Tian, Chistian Amsuss, and Jan Newmarch have provided helpful comments, </del> <ins> Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen, Sampo Ukkola, Linyi Tian, and Jan Newmarch have provided helpful comments, </ins> discussions and ideas to improve and shape this document.  Zach would also like to thank his colleagues from the EU FP7 SENSEI project, where many of the resource directory concepts were originally

Discussion:
atomicity idempotency, Jim multiple query parameter, Fairhair deleted eps from group, Jim simple registration, hauke