jiebi/CodeConvo huggingface dataset:
Change:
caches. Various HTTP versions have been used for media delivery.  HTTP/1.0, <del> HTTP/1.1 and HTTP/2 are carried over TCP, and TCP's transport behavior is described in reliable-behavior.  HTTP/3 is carried over QUIC, and QUIC's transport behavior is described in quic-behavior. </del> <ins> HTTP/1.1 and HTTP/2 are carried over TCP I-D.ietf-tcpm-rfc793bis, and TCP's transport behavior is described in reliable-behavior.  HTTP/3 is carried over QUIC, and QUIC's transport behavior is described in quic-behavior. </ins> Unreliable media delivery using RTP and other UDP-based protocols is also discussed in ultralow, unreliable-behavior, and hop-by-hop-

Discussion:
lgtm
From NAME
Done, except that 4960bis has now popped out as RFC9260. For these next two comments - our responses to reviews from NAME and NAME especially in dropping a lot of the archeology text about TCP, focusing on transport services, and working to make sure we are comparing apples to apples (2022 TCP to 2022 QUIC), have significantly improved the document throughout Section 6. The new discussion of "typically implemented in a kernel, although it doesn't have to be" and "typically implemented in userspace, although it doesn't have to be" is also intended to be more even-handed than the original text. I'm still following up on a couple of things with NAME and NAME but -11 will be significantly better, thanks to the review teams.
Change:
reliable transports such as TCP or TLS.  This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports.  It also formally updates RFC7641 for use with these <del> transports. </del> <ins> transports, and RFC 6455 to extend the well-known URI mechanism (RFC 5785) to the ws and wss URI schemes. </ins> 1.

Discussion:
Doesn't this need an IANA considerations section - URL
We are not creating a registry here; we are extending the semantics of the existing registry created by RFC 5875 to two existing URI schemes. No IANA action required. (We do have an IANA action for registering in that existing registry.)
I was thinking of something like this - URL
Yes -- URL
Doh. For some reason, I got hung up on needing a separate reference for RFC6455, but only the URI suffix is registered. I can appreciate that the lack of a separate draft could be confusing based on the layout of the registry - which will only reference coap-tcp-tls. Sorry for the noise.
: Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" URI, using a well-known URI in the "wss" scheme. However, "wss" is not defined to use well-known URIs, so this is an invalid use ...
Change:
Note that because the identifier in a pre-authorization request is the exact identifier to be included in the authorization object, pre- <del> authorization cannot be used to authorize issuance with wildcard DNS identifiers. </del> <ins> authorization cannot be used to authorize issuance of certificates containing wildcard domain names. </ins> Before processing the authorization request, the server SHOULD determine whether it is willing to issue certificates for the

Discussion:
badState should be orderNotReady Use "wildcard domain name" consistently instead of "wildcard prefix"
Thanks NAME :ballotboxwith_check:
Change:
The protocol must use normal HTTP semantics. The queries and responses must be able to be flexible enough to <del> express every normal DNS query. </del> <ins> express every DNS query that would normally be sent in DNS over UDP (including queries and responses that use DNS extensions, but not those that require multiple responses). </ins> The protocol must permit the addition of new formats for DNS queries and responses.

Discussion:
NAME my previous (deleted now) comment was in error in case you get a copy of that in email. sorry - git skillz failure on my part.
Change:
(see frame-push-promise).  A MAX_PUSH_ID frame cannot reduce the maximum Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than previously received MUST be treated as a connection error <del> of type HTTP_MALFORMED_FRAME. </del> <ins> of type HTTP_ID_ERROR. </ins> 7.2.9.

Discussion:
Implements suggestions from
Updated to replace HTTPLIMITEXCEEDED and HTTPPUSHIDERROR with the single error HTTPID_ERROR.
There are presently a few cases where the Push ID can be used incorrectly. The table shows current error codes, proposes replacing the HTTPDUPLICATEPUSH with an HTTPPUSHIDERROR code, and replaces use of HTTPMALFORMED frame. Note, on I suggested a slightly different solution to replace HTTPMALFORMED FRAME, but I think this is a better path.
To me it seems that having an error code for specific part of push (i.e. ID of push-related information being incorrect) a bit too detailed. I think it sticks out, because we do not have things like "IDERROR, STREAMIDERROR. Also, using PUSHIDERROR in some cases while using MALFORMEDFRAME in others seems confusing. I think we might want to consider doing either of the two: Use PUSHIDERROR (or a generic error code for push) for all the push-related errors. This makes sense if we consider push as an optional feature of HTTP/3 Introduce IDERROR that captures all the limit and ID errors.
Thanks NAME The proposal is a bit of a compromise, so I agree with some of the points that you make. I like your idea of replacing HTTPLIMITEXCEEDED with HTTPIDERROR. I think it solves the issue in the most general way and doesn't change the protocol mechanics. What follows is the response I made first, before coming to that agreement :) Right. The difference here is that H3 frames only reference the stream and placeholder ID spaces, they don't control them. So, if the peer references an ID that doesn't exist then respond with HTTPLIMITEXCEEDED. Multiple references to the same ID is a little different, its ok to reuse placeholder ID (as long as the above condition holds, and you create a semantically valid PRIORITY frame). The transport spec discusses reuse of stream IDs at that layer; in H3 we only use stream ID for PRIORITY and GOAWAY - this has similar restrictions. However, server push is a little different because it's ID space is managed by the MAXPUSHID frame. The three errors that use HTTPPUSHIDERROR are unique to push.

However, if we modified HTTPLIMITEXCEEDED to cover exceeding limits and incorrect ID usage (call it HTTPID_ERROR) I think that would work.
I updated the PR with the above, so that we can see what it looks like.
I'm not totally sold on this, but I'm having trouble articulating what it is that doesn't flow for me. I suspect that means I don't actually disagree, I just need some time to wrap my head around it.
We merged so I'm closing this as completed.
Change:
addresses on a single link.  In such cases, identification could be performed by subnet, such as the /64 to which the IP belongs. <ins> 3.4.3. The MAC address of a device is often used as an identifier in existing implementations.  This document does not discuss the use of MAC addresses within a captive portal system, but they can be used as an identifier type, subject to the criteria in id_recommended_props. </ins> 3.5. A Captive Portal API needs to present information to clients that is

Discussion:
We've had lots of people asking about the mac address as an identifier. Mention it, and point out that we won't give a deep discussion about it.
This one will likely be controversial. I wouldn't mind input from a few others.
Thanks for the reviews/suggestions.
The MAC address is such an obvious identifier, particularly since it's so widely used. We've have multiple questions about it during reviews. We should probably add some simple text pointing that out. E.g. "The MAC address of a device is often used as an identity in existing implementations. A discussion of it has been omitted for brevity, but the MAC address could be used subject to the criteria in section 3.2"
Change:
that automatically replies to challenges without participating in the creation of the initial authorization request. <del> 11.3. </del> <ins> 11.4. </ins> ACME provides certificate chains in the widely-used format known colloquially as PEM (though it may diverge from the actual Privacy

Discussion:
Thanks for the comments NAME I've updated the PR to address.
There has been list discussion on this PR and consensus is positive. I'm going to merge this now that NAME has addressed the feedback provided.
LGTM :rocket:
Change:
To protect the request, the JOSE header MUST contain the following additional parameters. <ins> The type header, value "gnap-binding+jwsd". </ins> The HTTP Method used to make this request, as an uppercase ASCII string.

Discussion:
Suggested changes for URL
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit 5602b657d1be7c2b17685269030092799ccb120f https://deploy-preview-226--gnap-core-protocol-editors-URL
This PR is now pending merge, linking with a new issue for verification (to check the value based on typ).
Key proof sections do not currently detail how to verify each method, including requirements for verifying fields, this needs to be added.
The idea is to minimize ways to reuse JWS objects . These attacks are sometimes referred as Swapping JWTs and Cross-JWT Confusion). See also discussion in URL
Change:
IANA is to add the following note to the TLS Exporter Label Registry: <ins> RFC5705 defines keying material exporters for TLS in terms of the TLS PRF.  I-D.ietf-tls-tls13 replaced the PRF with HKDF, thus requiring a new construction.  The exporter interface remains the same, however the value is computed different. </ins> IANA is to also to add a "Recommended" column to the TLS Exporter Label registry.  The table that follows has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future

Discussion:
I'm fairly sure that I sent these in already. Was there a regression? The current build has lines that are insanely long. This corrects that (and removes a warning caused by an open bracket).
I thought I fixed it, but I guess I'd missed it. I've got a fairly long rewrite that I hope to land early next that I think also addresses these.
Hoping that this is fixed via , which is pretty big set of editorial changes.
Change:
Verify the "lifetime" field: <del> When validating a downloaded KeyPackage, the current time MUST be within the "lifetime" range.  A KeyPackage that is expired or not yet valid MUST NOT be sent in an Add proposal. </del> <ins> When validating a LeafNode in a KeyPackage before sending an Add proposal, the current time MUST be within the "lifetime" range.  A KeyPackage containing a LeafNode that is expired or not yet valid MUST NOT be sent in an Add proposal. </ins> When receiving an Add or validating a tree, checking the "lifetime" is RECOMMENDED, if it is feasible in a given

Discussion:
This PR picks up changes from clarifying and cleaning up a few issues around LeafNode.
A big improvement in readability and correctness.
Change:
order to initialize the process of preparing a set of reports for aggregation.  It is structured as follows: <del> The message contains the PPM task ID, the aggregation job ID assigned by the leader, an opaque, VDAF-specific aggregation parameter, and the helper's report shares. </del> <ins> The message contains an opaque, VDAF-specific aggregation parameter and the helper's report shares. </ins> To construct an AggregateInitReq, the leader begins by picking a sequence of reports, all of which MUST pertain to the same PPM task

Discussion:
Minor changes/clarifications: Clarify how to handle empty Transition sequences Handle repeated nonces by aborting. While at it, this changes how the helper handles unrecognized nonces to be consistent with how the leader handles unrecognized nonces. Move task/job ID to top of AggregateReq
Change:
When an offerer sends an offer, in order to provide its identity assertion to the peer, it includes an 'identity' attribute in the offer.  In addition, the offerer includes one or more SDP <del> 'fingerprint' attributes.  The set of fingerprints MUST be the same as the set to which the identity assertion is bound. </del> <ins> 'fingerprint' attributes.  The 'identity' attribute MUST be bound to all the 'fingerprint' attributes in the session description. </ins> 5.1.2.

Discussion:
NAME I looked at the deletion issue and I don't think it's worth leaving it in as an exception, because you'd have to DTLS re-handshake anyway.
Change:
There are other classes of solutions in which the master secret is verified by verifying a certificate provided by the protected service.  These solutions offer more protection against a Man-In-The- <del> Middle attack by the fronting service. </del> <ins> Middle attack by the fronting service.  The downside is the the client will not verify the identity of the fronting service with risks discussed in {#frontingspoofing}, but solutions will have to mitigate this risks.  Overall, end-to-end TLS to the protected service is preferable. </ins> The fronting service could be pressured by adversaries.  By design, it could be forced to deny access to the protected service, or to

Discussion:
Two sets of comments from Mark O, received after WGLC. One is a reference to the acknowledgement section, in which he would rather not see his name spelled out. The other is about residual risks of fronting server spoofing when only the hidden service is verified in TLS.
Change:
protocol to create a signed token. Token challenge: A requirement for tokens sent from an origin to a <del> client, using the "WWW-Authenticate" HTTP header.  This challenge is bound to a specific token issuer and issuance protocol, and may be additionally bound to a specific context or origin name. </del> <ins> client, using the "WWW-Authenticate" HTTP header field.  This challenge is bound to a specific token issuer and issuance protocol, and may be additionally bound to a specific context or origin name. </ins> Token redemption: An action by which a client presents a token to <del> an origin, using the "Authorization" HTTP header. </del> <ins> an origin, using the "Authorization" HTTP header field. </ins> 2.

Discussion:
This one goes out to all the HTTP pedants out there =)
There's a few cases of rather than , which is puts you on HTTP's naughty list
Change:
ClientEncryptedCH.encrypted_ch.  This matching procedure should be done using one of the following two checks: <del> Compare ClientEncryptedCH.config_digest against digests of known </del> <ins> Compare ClientEncryptedCH.config_id against identifiers of known </ins> ECHConfig and choose the one that matches. Use trial decryption of ClientEncryptedCH.encrypted_ch with known ECHConfig and choose the one that succeeds. Some uses of ECH, such as local discovery mode, may omit the <del> ClientEncryptedCH.config_digest since it can be used as a tracking </del> <ins> ClientEncryptedCH.config_id since it can be used as a tracking </ins> vector.  In such cases, trial decryption should be used for matching ClientEncryptedCH to known ECHConfig.  Unless specified by the application using (D)TLS or externally configured on both sides,

Discussion:
Also, rename configdigest to configid to avoid confusion with cryptographic hash digests. cc NAME NAME NAME
It's bound by the size o the HPKE KDF output size, which is unlikely to be larger than 32B. Let's make this:
We should also add a requirement for the HPKE ciphersuite. E.g., 'Nh <= 2^8`.
(Careful with fenceposts: .) If config_digest is the output of a KDF, why could you not fix the length to something that is enough to avoid collisions (16 bytes seems ample for this) and not worry about Nh at all?
I think it makes sense to let the KDF dictate the security level, i.e., the collision probability of the config_digest.
I would argue that collision probability here doesn't contribute to security. If a config is misidentified, the result will be failure, not a reduction in security. A failure either because the group doesn't match or because peers end up disagreeing on keys.
True that it's an operational consideration rather than a security one. I still think it makes sense to let the length of be dictated by the KDF, since whether truncation is an operational risk depends on the KDF.
I assume here that a KDF is capable of producing uniform random bytes of arbitrary length, meaning that truncation isn't a factor. That's what is for, right?
That assumption holds if the input has sufficient entropy. Since the public key is public, there's no entropy from the point of view of an adversary who wants to distinguish the output from random.
(To be clear, I think truncating to something reasonable, like 16 bytes, is low risk. I would be fine with doing this.)
Change:
5.6.4.1. Once an IdP has generated an assertion, it is attached to the SDP <del> message.  This is done by adding a new identity attribute to the SDP. The sole contents of this value are a RFC4648 identity assertion. For example: </del> <ins> offer/answer message.  This is done by adding a new identity attribute to the SDP.  The sole contents of this value are a RFC4648 identity assertion.  For example: </ins> The identity attribute attests to all "a=fingerprint" attributes in the session description.  It is therefore a session-level attribute.

Discussion:
Just some tweaks to consistently use offer/answer exchange and to explain that the offer/answer includes the caller's/callee's assertion, respectively.
Change:
of their element or member values then.  Applied to other value types, it will select nothing. <del> Some examples: </del> <ins> 3.5.8.3. JSON document: Queries: </ins> 3.5.9.

Discussion:
Ref: URL
we need to discuss the descendant selector's behavior by including itself to the node list.
Yes. Let's do that in a PR for URL
yes ... it's illustratively shown, what a good thing inline examples are ...
Considering the following input: would evaluate to (in this case the values of the object): I would expect the descendant version: to evaluate to: Yet the example says: Considering the following pseudo logic: In the case of the would be an index wildcard selector. I would expect the descendant selector to (starting by selecting itself) walk through the json structure and select all the results by applying the child selector (dot-member-name, index-selector, index-wild-selector, or wildcard) on each traversed value. Am I misunderstanding something here or is this the intended behavior?
Thanks for raising this. When I was writing the example, I noticed that only a few implementations included the node itself. But the descendant selector semantics currently say: and so I included the "starting" node itself. This is why I included the following text in the commit message: The semantics section needs improving anyway to clarify the semantics of the various forms of the descendants selector. I agree with the semantics proposed above, providing there is a consensus for this in the WG.
In my understanding descendant selector simply extends the single-level operating of child selector , in that it further recursively operates on all other descendant levels. So I agree to Bram's traversal algorithm above. A node is not considered a descendant of itself. Obviously I have not been aware of this behavior.
Change:
6. <ins> NOTE: the URI scheme defintion in this section is provisional and subject to change, especially the name of the scheme. QuicTransport uses the "quic-transport" URI scheme for identifying QuicTransport servers. The syntax definition below uses Augmented Backus-Naur Form (ABNF) RFC5234.  The definitions of "host", "port", "path-abempty", "query" and "fragment" are adopted from RFC3986.  The syntax of a QuicTransport URI SHALL be: This document does not define any semantics to "path-abempty", "query" or "fragment" portions of the URI, nor does it delegate those to the host owners.  Any QuicTransport implementation MUST ignore those until a subsequent specification assigns semantics to those. The "host" component MUST NOT be empty.  If the "port" component is missing, the port SHALL be assumed to be 0. NOTE: this effectively requires the port number to be specified. This specification may include an actually usable default port number in the future. In order to connect to a QuicTransport server identified by a given URI, the user agent SHALL establish a QUIC connection to the specified "host" and "port" as described in connection.  It MUST immediately signal an error to the client if the port value is 0. 7. </ins> QuicTransport supports most of WebTransport features as described in properties. <del> 7. </del> <ins> 8. </ins> QuicTransport satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a secure framework

Discussion:
This defines a new URL scheme for QuicTransport, and clarifies the use of "https" for Http3Transport.
Change:
4.5.2. Following the initial key information exchange with the Key <del> Distributor, endpoints will be able to encrypt media end-to-end with their E2E Key(i), sending that E2E Key(i) to other endpoints encrypted with KEK, and will be able to encrypt and authenticate RTP packets using local HBH Key(j).  The procedures defined do not allow the Media Distributor to gain access to the KEK information, preventing it from gaining access to any endpoint's E2E key and subsequently decrypting media. The KEK (i.e., EKTKey) may need to change from time-to-time during </del> <ins> Distributor, an endpoints will be able to encrypt media end-to-end with an E2E key, sending that E2E key to other endpoints encrypted with the KEK, and will be able to encrypt and authenticate RTP packets using a HBH key.  The procedures defined do not allow the Media Distributor to gain access to the KEK information, preventing it from gaining access to any endpoint's E2E key and subsequently decrypting media. The KEK (i.e., EKT Key) may need to change from time-to-time during </ins> the life of a conference, such as when a new participant joins or leaves a conference.  Dictating if, when or how often a conference is to be re-keyed is outside the scope of this document, but this framework does accommodate re-keying during the life of a conference. <del> When a Key Distributor decides to rekey a conference, it transmits a </del> <ins> When a Key Distributor decides to re-key a conference, it transmits a </ins> specific message defined in PERC EKT [I-D.ietf-perc-srtp-ekt-diet] to each of the conference participants.  The endpoint MUST create a new SRTP master key and prepare to send that key inside a Full EKT Field

Discussion:
This is a first-draft at sections to help clarify key usage and packetization format.
Overall this looks like pretty good and I think much of what I don't like could be fixed simply by deleting two sub sections.
Impressive you were able to put "Overall this looks like pretty good" and "much of what I don't like" into the same sentence. :) OK, I'll remove the section(s) with the steps. It gets a bit into the weeds, though it might be useful to figure out how to replace this. The issue is I hear people getting confused over how to use the keys. That's why I thought that an informative section might help. A library hides all this, but if you're writing the library, you need to understand these steps. I'll leave this here until the weekend (or later this week), as I have other stuff to get done. But, I'll come back to it.
I just pushed a set of changes, squashing the changes into a single PR. Otherwise, the changes look to be even larger than they really are since I removed many additions from the first commit.
LGTM