jiebi/CodeConvo huggingface dataset:
Change:
that use the Capsule Protocol.  A receiver that observes a violation of these requirements MUST treat the HTTP message as malformed. <ins> When processing capsules, a receiver might tempted to accumulate the full length of the capsule value in the data stream before handling it.  This approach can consume flow control in underlying layers, which might lead to deadlocks if the capsule data exhausts the flow control window. </ins> 3.3. When an error occurs in processing the Capsule Protocol, the receiver

Discussion:
This adds a few statements through the text that explains that data streams are subject to any flow control provided by layers lower down. Wih that in mind, the potential for problem deadlocks should be clearer when we state it.
This is a non-blocking comment from AD review. I have no concerns if the authors choose to close it with no action. It might be worthwhile to discuss the interaction of stream flow control with capsule/datagram conversions. With other HTTP transactions, intermediaries can deliver whatever in-order bytes of the stream they have. When receiving capsules and emitting datagrams, if the stream flow control window is too small to accept the datagram size, there can be a deadlock. A sentence about this special case could avoid a silly implementer mistake.
I think this goes beyond just intermediaries. Instead it applies to any consumer of capsules where they might be tempted to try and buffer the capsule, in the data stream, in its entirety before processing or consuming it. That might be obvious as a "bad thing" for implementers that are already used to handling H2 or H3 frames. However, you identify that the DATAGRAM capsule is particularly tempting to buffer because it should be handled atomically. So I think it might help to briefly point out some deadlock considerations about flow window sizes in relation to capsule sizes, and processing / release of further window credits.
Adding a little bit of text to warn against such cases SGTM
Change:
these two mechanisms with TLS 1.3 RFC8446. These two mechanisms can be complementary.  A server could use <del> credentials for clients that support them, while using LURK to </del> <ins> credentials for clients that support them, while using KEYLESS to </ins> support legacy clients. It is possible to address the short-lived certificate concerns above <del> by automating certificate issuance, e.g., with ACME RFC8555.  In addition to requiring frequent operationally-critical interactions with an external party, this makes the server operator dependent on the CA's willingness to issue certificates with sufficiently short lifetimes.  It also fails to address the issues with algorithm support.  Nonetheless, existing automated issuance APIs like ACME may be useful for provisioning credentials within an operator network. </del> <ins> by automating certificate issuance, e.g., with Automated Certificate Managmeent Encvironment (ACME) RFC8555.  In addition to requiring frequent operationally-critical interactions with an external party, this makes the server operator dependent on the CA's willingness to issue certificates with sufficiently short lifetimes.  It also fails to address the issues with algorithm support.  Nonetheless, existing automated issuance APIs like ACME may be useful for provisioning credentials within an operator network. </ins> 3. While X.509 forbids end-entity certificates from being used as issuers for other certificates, it is perfectly fine to use them to issue other signed objects as long as the certificate contains the <del> digitalSignature KeyUsage (RFC 5280 section 4.2.1.3).  We define a new signed object format that would encode only the semantics that are needed for this application.  The credential has the following </del> <ins> digitalSignature KeyUsage (RFC5280 section 4.2.1.3).  We define a new signed object format that would encode only the semantics that are needed for this application.  The credential has the following </ins> structure: Relative time in seconds from the beginning of the delegation

Discussion:
Updating x690 version to match TLS1.2 (2015) Expanding acronyms (avoid genart) removed "!" from some refs (unneded) r/LURK/KEYLESS (completes derference from earlier PR).
Change:
structures are used for the plain text and for the different key management techniques. <del> One of the by products of using the same technique for encrypting and </del> <ins> One of the byproducts of using the same technique for encrypting and </ins> 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.

Discussion:
The majority of changes prior to the examples section are to address typos or what I saw as inconsistencies. I will admit I wasn't as diligent as I should have been on those, but I need to take another pass on the document. The examples were reformatted to minimize side scrolling -- and likely fit within the TXT representation.
Change:
The "a=rtcp-mux" line MUST only be added if present in the most recent answer. <ins> The "a=rtcp-mux-only" line MUST only be added if present in the most recent answer. </ins> The "a=rtcp-rsize" line MUST only be added if present in the most recent answer.

Discussion:
Line 2589: "I don't think this is quite right. I imagine this should probably echo the above, e.g. MUST only be added if present in the most recent answer."
So re-review this one and see if you are OK with it as is.
This seems fine.
JSEP should probably point at the draft and include the attribute on every (applicable) media section.
Agreed
Change:
a TBD threshold) and initiate the return routability check that proceeds as follows: <del> A cookie is placed in a return_routability_check message of type </del> <ins> A cookie is placed in a "return_routability_check" message of type </ins> path_challenge; The message is sent to the observed new address and a timeout T is started; The peer endpoint, after successfully verifying the received <del> return_routability_check message echoes the cookie value in a return_routability_check message of type path_response; </del> <ins> "return_routability_check" message echoes the cookie value in a "return_routability_check" message of type path_response; </ins> When the initiator receives and verifies the <del> return_routability_check message contains the sent cookie, it </del> <ins> "return_routability_check" message contains the sent cookie, it </ins> updates the peer address binding; If T expires, or the address confirmation fails, the peer address

Discussion:
Use a new extension type instead.
Yes, if tls-flags are not usable for DTLS 1.2, then go with this.
We'd like to use to negotiate RRC. At the moment, the document seems to be defined for (D)TLS 1.3 only, but the reason why the same scheme would not be applicable to 1.2 are not fully clear. For now (-01), optimistically, we are using it in a version agnostic fashion, hoping that eventually that will be the case. Achim has opened an . This issue is for tracking on the RRC side.
Change:
can use padding to reduce the effectiveness of traffic analysis. Padding is a capability provided by binary HTTP messages; see BINARY. <ins> If the encapsulation method described in this document is used to protect a different message type (see repurposing), that message format might need to include padding support. </ins> 6.3.

Discussion:
This adds a little structure to the section on encapsulation and tries to make the relationship between different media types more distinct. This builds on top of (which we are going to merge soon) because that hits all the same text and we have already effectively agreed to those changes. You can review to see what the substance of these changes are. Alternatively, just look at the top of the "HPKE Encapsulation" section (the other changes are unrelated).
I spent some time being confused because (content type) and (the hpke info tag) are so similar. Is it possible to align these two? Section 9, Repurposing the Encapsulation Format, mentions changing the hpke info for other protocols, so I suppose is re-using the content-type from the binary http draft at this layer, while the outer Content-Type is specific to this draft's application? I can see the logic there, but some clarifying text about the two being different would have been helpful.
We kept them separate because they refer to different things. The "message/ohttp-req" content type refers to the type of HTTP request sent from client to gateway, whereas the "message/bhttp request" content type refers to the type of content that's encapsulated to the gateway. We can probably improve this distinction in the text. Thanks for flagging this.
I did a little rewriting of some of the key framing text for another issue, does the following help at all? URL
The new references to the repurposing section in that commit are helpful. The extra wording you linked doesn't help much I think. It's confusing that the both encapsulates a and is called an 'encapsulated request/response'. So when you say, the word 'contains' is ambiguous: is it that the directly contains the binary HTTP message, or is that the HPKE AEAD contains the binary HTTP message? I understand it's the second one, but on first reading this kind of layer confusion was hard to keep track of. Maybe something about the media type containing the encrypted message along with the necessary parameters to convey the encapsulation would help?
I took a swing at this in . Am I getting closer?
Change:
party of the TLS connection at the application layer.  The application layer protocol used to send the authenticator SHOULD use TLS as its underlying transport to keep the certificate confidential. <ins> The application MAY use the existing TLS connection to transport the authenticator. </ins> An authenticator message can be constructed by either the client or the server given an established TLS connection, a certificate, and a

Discussion:
NAME are you happy with the adjusted text? I don't consider DTLS support to be a big change since the only thing we are relying on from TLS is the exporter interface.
I think that this is sneaking in a big change with the DTLS thing. I'll try to find the email...
Change:
the protocol provides.  For these reasons, RFC8030 does not define a mandatory system for authentication of application servers. <del> An unfortunate consequence of this design is that a push service is exposed to a greater risk of denial of service attack.  While requests from application servers can be indirectly attributed to user agents, this is not always efficient or even sufficient. </del> <ins> An unfortunate consequence of the design of RFC8030 is that a push service is exposed to a greater risk of denial of service attack. While requests from application servers can be indirectly attributed to user agents, this is not always efficient or even sufficient. </ins> Providing more information about the application server directly to a push service allows the push service to better distinguish between legitimate and bogus requests.

Discussion:
This looks a lot worse than it really is. Reflowing text causes massive diffs, which github somehow manages to make look like entirely new text.
Change:
service can strip off any such identity assertions, though it cannot forge new ones.  Note that all of the third-party security mechanisms available (whether X.509 certificates or a third-party IdP) rely on <del> the security of the third party--this is of course also true of your connection to the Web site itself.  Users who wish to assure </del> <ins> the security of the third party--this is of course also true of the user's connection to the Web site itself.  Users who wish to assure </ins> themselves of security against a malicious identity provider can only do so by verifying peer credentials directly, e.g., by checking the peer's fingerprint against a value delivered out of band.

Discussion:
In Section 7 I would suggest using Alice and Bob (or some other name) rather than "I" and "you/your." EMAIL is used there so the pronouns are mixed. Same comment for 9.1 -- I would suggest replacing "your" with "the user's."
Change:
Connection IDs), the short header exposes at most only a single Connection ID. <del> 8.1. </del> <ins> 9.1. </ins> QUIC supports a server-generated Connection ID, transmitted to the client during connection establishment (see Section 6.1 of QUIC).

Discussion:
addresses issue
I think the applicability draft may benefit from exploring connection migration strategies as described in: URL
Do we also need to say anything about use of 0-byte CID? See quicwg/base-drafts
The transport draft already says:
addressed by PR and one more sentence
I don’t see any text related to connection migration on that PR.
sorry wrong PR; should be and is already merged
good modulo typos
Change:
inclusion, log aggregation, event grouping and log file size reduction techniques. <ins> The qlog schema can be serialized in many ways (e.g., JSON, CBOR, protobuf, etc).  This document describes only how to employ JSON, its subset I-JSON, and its streamable derivative JSON-Text-Sequences. </ins> Feedback and discussion are welcome at https://github.com/quicwg/qlog [1].  Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document.

Discussion:
There's too much text here that doesn't aid the reader. Delete it to be clear that we're using JSON as the notational convention for examples. If this text was valuable, it should be somewhere else.
I still feel we should have a "forward reference" here, indicating that we also discuss I-JSON and Streaming JSON considerations in this document, rather than making it seem we only do "pure JSON" due to the examples. Put differently, something like this should still be mentioned in this location imo:
But the fact it can be serialized to I-JSON has nothing to do with notational conventions used in this document, because we don't use any I-JSON.
NAME I just pushed a commit with a proposal to split up the original text to keep only a minimal amount in "Notational Conventions" but keep the core message alive in the introduction (which seemed the most logical location for now). I added the "unless otherwise indicated", as there are some examples of JSON-SEQ near the end of the document that obviously don't use RFC8259 notation directly. Please review and if approved, merge :)
Change:
Examples and a sample decoding algorithm are shown in sample-varint. <ins> Values do not need to be encoded on the minimum number of bytes necessary, with the sole exception of the Frame Type field; see frames. </ins> Versions (versions), packet numbers sent in the header (packet- encoding), and the length of connection IDs in long header packets (long-header) are described using integers, but do not use this

Discussion:
With one exception.
Rob Wilton said:
The one case where non-optimal encodings are forbidden is URL Otherwise, there is no restriction. Yes, 3 can be encoded in 8 bytes. But it is worth noting. (I thought that we had.)
Change:
predicate being usable here), and subsets of the data can be taken and expressed. <del> Literals with properties behave similar to blank nodes (where their properties resemble statements from a blank node) - so similar that they are serialized precisely like that.  The difference is that properties are part of the literal's identity.  The structured model does not add structure to properties. </del> Forms are not special in the information model, but are merely statements around a blank node.  They can be special in serialization formats (which have more efficient notations for them), and are used

Discussion:
With direction on its way into a tag (discussion pending -- will it be a dedicated one or inside 38), the only use case we had for properties on literals is gone. I think the whole model is better if we remove them -- anything that can be expressed with properties can also be expressed with tags, but the latter are well defined and understood whereas the former are not. (What does it mean if two properties are on a literal and both are defined but their interaction is not? Tags are clearer there). PR is incomplete, needs a few more alterations.
Change:
already established via the Voucher, the pledge does a full TLS handshake against the local RA indicated by the voucher response. <ins> The returned voucher contains an attribute, "est-domain", defined in redirected below.  The pledge is directed to continue enrollment using the EST registrar found at that URI.  (XXX - how can it trust it?  I guess with pinned-domain-cert!) </ins> EXPLAIN APPLICABILITY.  NEEDS EXTENSTION to Voucher. 5. <del> [[ TODO ]] </del> <ins> An extension to the RFC8366 voucher is needed for the case where the client will be redirected to a local EST Registrar. 5.1. INSERT_TEXT_FROM_FILE ietf-redirected-voucher-tree.txt END 5.2. INSERT_TEXT_FROM_FILE ietf-redirected-voucher@DATE.yang END </ins> 6. <ins> TODO:MCR - Will need to add IETF YANG registration from templates. [[ TODO ]] 7. </ins> [[ TODO ]]

Discussion:
this added the YANG machinery and a basic extension to RFC8366 to add the est-domain attribute.
Looks good.
Change:
For finite field groups, a conventional Diffie-Hellman computation is performed.  The negotiated key (Z) is converted to a byte string by <del> encoding in big-endian and padded with zeros up to the size of the prime.  This byte string is used as the shared secret in the key </del> <ins> encoding in big-endian and left padded with zeros up to the size of the prime.  This byte string is used as the shared secret in the key </ins> schedule as specified above. Note that this construction differs from previous versions of TLS

Discussion:
NAME I did not: 1) add the "Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS " reference because it's already in the [JSS15] reference that's later in the sentence. 2) I also didn't made [AEAD-LIMITS] normative.
Change:
bytes. UDP datagrams MUST NOT be fragmented at the IP layer.  In IPv4 <del> (IPv4), the DF bit MUST be set to prevent fragmentation on the path. </del> <ins> (IPv4), the DF bit MUST be set if possible, to prevent fragmentation on the path. </ins> 14.1.

Discussion:
For example, OSX doesn't have an API to set this bit (allegedly this will change with Big Sur). Furthermore, not all implementations might have access to an API that allows them to set bits in the IP header. If I remember correctly, this is one of the reasons we made ECN optional.
I think you wanted to quote this part ({{!IPv4=RFC0791}}), the DF bit MUST be set to prevent fragmentation on the path. Would a proposal be to make the MUST a SHOULD and say "unless this is not supported by the underlying OS"?
Yes, that was a weird copy-paste error. If we say "unless this is not supported by the underlying OS or the programming language" we can probably even keep the MUST.
This is an editorial issue, since the intent of the MUST cannot be to require something that isn't possible.
This seems fine. What do you think of the short version?
Change:
stop using the corresponding connection IDs and retire them with RETIRE_CONNECTION_ID frames before adding the newly provided connection ID to the set of active connection IDs.  This ordering <del> allows an endpoint that has already supplied its peer with as many connection IDs as allowed by the active_connection_id_limit transport parameter to replace those connection IDs with new ones as necessary. Failure to cease using the connection IDs when requested can result in connection failures, as the issuing endpoint might be unable to </del> <ins> allows an endpoint to replace all active connection IDs without the possibility of a peer having no available connection IDs and without exceeding the limit the peer sets in the active_connection_id_limit transport parameter; see transport-parameter-definitions.  Failure to cease using the connection IDs when requested can result in connection failures, as the issuing endpoint might be unable to </ins> continue using the connection IDs with the active connection. 5.2.

Discussion:
We already had something here, but I think that it missed the central reason, which is the combination of: wanting to replace all connection IDs having used the limit from activeconnectionid_limit wanting to ensure that there is >= 1 available connection IDs left This phrasing isn't quite that explicit, but I think that it is clear enough.
It is not obvious from this, but the intent here is to allow NEWCONNECTIONID to exceed the limit from activeconnectionid_limit.
Nice wording, looks good!
Change:
Aggregators can control this cached lifetime with the Cache-Control header, as follows: <del> Clients SHOULD follow the usual HTTP caching RFC7234 semantics for </del> <ins> Clients SHOULD follow the usual HTTP caching RFC9111 semantics for </ins> key configurations. Note: Long cache lifetimes may result in clients using stale HPKE

Discussion:
I-D Nits complains of outdated reference for: ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) We should update tit.
Thanks!
Change:
flight of messages.  If the implementation has received one or more ACKs (see ack-msg) from the peer, then it SHOULD omit any messages or message fragments which have already been ACKed.  Once the messages <del> have been sent, the implementation then enters the FINISHED state if this is the last flight in the handshake.  Or, if the implementation expects to receive more messages, it sets a retransmit timer and then </del> <ins> have been sent, the implementation then sets a retransmit timer and </ins> enters the WAITING state. There are four ways to exit the WAITING state:

Discussion:
The previous version erroneously specified that implementations should transition from SENDING to FINISHED after sending the last flight in a handshake. Instead, they should transition to WAITING and only move to FINISHED upon receipt of ACKs for the entire last flight. This PR fixes the state machine diagram and text.
lgtm
Change:
4.1.1.2. <del> HTTP/3 uses QPACK field compression as described in QPACK, a variation of HPACK that allows the flexibility to avoid compression- induced head-of-line blocking.  See that document for additional details. </del> <ins> QPACK describes a variation of HPACK that gives an encoder some control over how much head-of-line blocking can be caused by compression.  This allows an encoder to balance compression efficiency with latency.  HTTP/3 uses QPACK to compress header and trailer sections, including the pseudo-header fields present in the header section. </ins> To allow for better compression efficiency, the "Cookie" field (RFC6265) MAY be split into separate field lines, each with one or

Discussion:
NAME said
NAME said
Honestly, this whole sentence is a bit awkward. I'll improve that.
NAME said
I have to say, this is a little odd. HTTP requires case insensitive comparison, but by calling it out here, the juxtaposition is weird. As we force lowercase, we could just strike: "that are compared in a case-insensitive fashion"
The first is a statement of fact about what SEMANTICS requires. However, I agree that we reduce confusion and lose nothing by making the statement less explicit. Interested parties can read SEMANTICS.
Yes, the proposed text addresses my comments. Thanks for the updates.