jiebi/CodeConvo huggingface dataset:
Change:
format and assigned semantics of any fields in the frame. The initial contents of this registry are tabulated in frame-types. <del> Note that the registry does not include the "Packets" column from frame-types. </del> <ins> Note that the registry does not include the "Pkts" and "Spec" columns from frame-types. </ins> 22.4.

Discussion:
After considering this a little more it seems helpful to bring some of the special handling rules up into the summary. We don't really give up-front treatment of ack-eliciting, probing, and other important distinctions, so an extra column seemed useful. A table of this size just fits in the text format.
I had almost exactly those changes in a previous version. It was a near thing.
That is super helpful, and is the direction I was hoping for!
In Section Frame Types and Formats, there is a very useful summary of frame types by packet type. As a person with a CC and transport protocol interest, it would be really nice to have had a summary table of key properties that included whether each frame type is ack-eliciting; whether transmission is controlled by flow-control; and whether transmission is controlled by congestion-control. Is there any chance we can add an extra column say to this table?
The problem with the table is that it is already essentially the full width available to us. That makes the addition of more information quite difficult. The rules for most of these are simple enough that I'm not sure that the table is the best way to present it. That is: ack-eliciting: all except ACK, PADDING congestion-controlled: all except ACK flow controlled: only STREAM
I wouldn't want to mess-up the table format to include the info. However, it would be really nice to have the info in a compact way close to the table somehow so that readers quickly confirm this. Would a note below the table possibly work, saying just this?
Change:
above keying material. By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation <del> without having to extract the Master Secret, ClientHello.random, and </del> <ins> without having to extract the Main Secret, ClientHello.random, and </ins> ServerHello.random in a non-standard way. 2.4.

Discussion:
TLS WG has decided to change terminology in TLS 1.2 and TLS 1.3. The draft is already WG adopted. I suggest we make this change in EAP-TLS 1.3 as well.
Looks good to me
Change:
association identifiers and applications must arrange to multiplex between associations.  With UDP, the host/port number is used to look up the appropriate security association for incoming records. <del> However, the CID extension defined in DTLS-CID adds an association identifier to DTLS records. </del> <ins> However, the CID extension defined in I-D.ietf-tls-dtls-connection-id adds an association identifier to DTLS records. </ins> Some transports, such as DCCP RFC4340, provide their own sequence numbers.  When carried over those transports, both the DTLS and the

Discussion:
I-D.ietf-tls-dtls-connection-id became a normative reference Removed duplicate reference to I-D.ietf-tls-dtls-connection-id.
Change:
The JWS MUST NOT have the value "none" in its "alg" field <ins> The JWS MUST NOT have a MAC-based algorithm in its "alg" field </ins> The JWS Protected Header MUST include the following fields: "alg"

Discussion:
Also: Forbid the use of MAC-based JWS algorithms (in case this wasn't obvious) Sort error codes alphabetically
The server needs to support whatever the client sends. We should have an error code for this, and a way for the server to specify what algorithms it does support in the error message.
Change:
Abstract <del> While WebRTC has been very sucessful in a wide range of scenarios, </del> <ins> While WebRTC has been very successful in a wide range of scenarios, </ins> its adoption in the broadcasting/streaming industry is lagging behind.  Currently there is no standard protocol (like SIP or RTSP) designed for ingesting media into a streaming service using WebRTC

Discussion:
If you find them useful, here are some spelling fixes. The ' PATH ' spelling is confusing, I think it should be ' PATCH ' Also the draft URL points to and older draft. I have been very inspired by WHIP, thank you for giving it to the community.
Change:
arbitrary number of session tickets to clients, at their discretion, upon connection establishment.  Clients store and use tickets when resuming future connections.  This document describes a mechanism by <del> which clients may specify the desired number of tickets needed for </del> <ins> which clients can specify the desired number of tickets needed for </ins> future connections.  This extension aims to provide a means for servers to determine the number of tickets to generate in order to reduce ticket waste, while simultaneously priming clients for future

Discussion:
If they don't enforce a limit, clients can cause them to do a lot of work.
Fixed by .
Approved pending
Change:
The combination of an IP address and transport protocol (such as UDP or TCP) port. <del> When ICE is used to setup multimedia sessions, the data is transported using some protocol.  Media data is usually transported over RTP, and a media data stream composes of a stream of RTP packets.  Data session refers to data packets that are exchanged between the peer on the path created and tested with ICE. </del> <ins> When ICE is used to setup data sessions, the data is transported using some protocol.  Media is usually transported over RTP, composed of a stream of RTP packets.  Data session refers to data packets that are exchanged between the peer on the path created and tested with ICE. </ins> A transport address that is a potential point of contact for receipt of data.  Candidates also have properties -- their type

Discussion:
Fix spelling: Replace “fulfil” with “fulfill” Fix grammar: “agent sets the state…is set to Completed“ with “agent sets the state…to Completed” Make consistent with recent changes: Replace “candidate is equal to the transport address” with “candidate has the transport address” Replace “multimedia session” with “data session” Replace “media data stream” with “RTP/RTCP data stream” or just “data stream” Replace “media data” with “data”
Change:
response-interact.  [[ See issue #89 [34] ]] For example, if the request is successful in causing the AS to issue <del> access tokens and release subject claims, the response could look like this: </del> <ins> access tokens and release opaque subject claims, the response could look like this: </ins> With this example, the client instance can not make an additional continuation request because a "continue" field is not included.

Discussion:
Replaces most examples by on email, as discussed in and
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit 36777fd4186ad5d5f3d9e64c1120277ab52806d2 https://deploy-preview-228--gnap-core-protocol-editors-URL
Requesting User Information: Editor's Note: What we're really saying here is that "even if the AS gives you an email address to identify the user, that isn't a claim that this is a valid email address for that current user, so don't try to email them." In order to get a workable email address, or anything that you can use to contact them, you'd need a full identity protocol and not just this. Also, subject identifiers are asserted by the AS and therefore naturally scoped to the AS. Would changing the name to "assubids" or "localsubids" help convey that point?
Perhaps the example in this section should not include asking for the email here if we want to encourage asking for the email claim from OpenID instead.
NAME that's actually the core point of this issue: there's a semantic difference between asking for "tell me who the current user is, and I know them by an email address identifier" vs. "tell me the email address of the current user so that I can email them". The subject identifiers are the former, OpenID and other identity protocols would give you the latter.
See also .
It would be better to use examples that are not related to emails, to avoid confusion. I believe an "as_uid" (unique identifier local to the AS) could be best as an example that conveys the message.
Yaron: "Subject identifiers requested by the RC serve only to identify the RO in the context of the AS and can't be used as communication channels by the RC" - this sounds a bit naive, people will do that anyway. So why is this a useful statement? (And similarly in 3.4) Justin: This inclusion is based roughly off of a similar constraint in OIDC around subject identifiers: URL I agree that people will do dumb things anyway, but that’s why we need to spell out why it’s dumb here.

Yaron: I haven't looked at the OpenID text, but at least here, we do not_ explain why using the email address to send email is a bad idea, we just say that it is. I think we should give a rationale.
There are many reasons why we don't want emails ("should not use email"). No assurance it's unique (ex: EMAIL) No idea on email policy (could be transfered to someone else) Ties to a delivery method (which shouldn't be our goal here) Also not using email facilitates the distinction with what OIDC/authentication mechanisms provide (more an internal argument for the specification text itself). Might also want to push forward privacy enhancing mechanisms.
Change:
usage, Section 5.2.  Any header extensions that require encryption MUST be specified as indicated in RFC6904, Section 4. <del> For each supported RTCP feedback mechanism, an "a=rtcp-fb" mechanism, as specified in RFC4585, Section 4.2.  The list of RTCP feedback mechanisms that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1. </del> <ins> For each supported RTCP feedback mechanism, an "a=rtcp-fb" line, as specified in RFC4585, Section 4.2.  The list of RTCP feedback mechanisms that SHOULD/MUST be supported is specified in I-D.ietf- rtcweb-rtp-usage, Section 5.1. </ins> If the RtpTransceiver has a sendrecv or sendonly direction:

Discussion:
Page 51, bullet starting "For each supported RTCP feedback...": replace "an 'a=rtcp-fb' mechanism" with "an 'a=rtcp-fb' line".
Section Initial Answers Text is For each supported RTCP feedback mechanism that is present in the offer, an "a=rtcp-fb" mechanism, as specified in [RFC4585], Section 4.2. The list of RTCP feedback mechanisms that SHOULD/ MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. Fix trivial typo
Page 38, second-to-last bullet refers to "an 'a=rtcp-fb' mechanism" where it should say "an 'a=rtcp-fb' line".
Agreed
Change:
Connection Termination: The security protocol may be instructed to tear down its connection and session information.  This is needed <del> by some protocols to prevent application data truncation attacks. </del> <ins> by some protocols, e.g., to prevent application data truncation attacks in which an attacker terminates an underlying insecure connection-oriented protocol to terminate the session. </ins> TLS

Discussion:
Add half a sentence to Connection Termination to address , which complained that this part ignores layering. I guess IKEv2 is the only protocol there that is not at the same layer as TCP or above. So maybe for IKEv2, the Connection Termination interface prevents a different attack (at least I didn't find anything on data truncation for IKEv2), but I think that's okay. Data truncation is just an example and we don't need to enumerate all possible attacks.
Looks good!
Comment from Ekr's review of -10: S 5.3. o Connection Termination: The security protocol may be instructed to tear down its connection and session information. This is needed by some protocols to prevent application data truncation attacks. This seems like kind of a confusing section, I think partly because it ignores layering. The way I think of this is that we have an existing family of insecure protocols that have their own termination mechanisms (e.g., TCP FIN/RST). A security protocol that is under such a protocol (e.g., IPsec) doesn't need a secure termination mechanism because (a) the existing termination mechanism become secure and (b) it can just stop transmitting. By contrast, a security protocol that is above (TLS) or at the level of such a protocol (QUIC, tcpcrypt) needs its own secure termination mechanism, lest it be at the mercy of the transport.
Change:
The GOAWAY frame applies to the connection, not a specific stream.  A client MUST treat a GOAWAY frame on a stream other than the control <del> stream as a connection error (errors) of type HTTP_UNEXPECTED_FRAME. </del> <ins> stream as a connection error (errors) of type HTTP_WRONG_STREAM. </ins> See connection-shutdown for more information on the use of the GOAWAY frame.

Discussion:
I'm pretty sure the intent of URL was correct but the wrong error was changed in the draft. This pr makes the change that I think was intended in URL
Just a note. If this is the right answer and the PR lands, then will need to replace the new instance of HTTPMALFORMEDFRAME with something, e.g. HTTPINVALIDGOAWAY or something
Yeah, that crossed my mind. :-) YAEC!
In , NAME correctly observed that I messed up , but he closed his PR and I'm not able to reopen it without more git wizardry than I'm interested in practicing today. Easier just to fix it in my own branch.
Change:
This section defines the extension point as well as four function extensions that use this extension point.  While these mechanisms are designed to use the extension point, they are an integral part of the <del> JSONPath specification and are mandatory to implement. </del> <ins> JSONPath specification and are expected to be implemented like any other integral part of this specification. </ins> A function extension defines a registered name (see iana-fnex) that can be applied to a sequence of zero or more arguments, producing a

Discussion:
Fix a right margin incursion, as well.
I'm commenting on the editor's draft. Section 2.6 says, of len(), count(), match(), and search(), that “they are an integral part of the JSONPath specification and are mandatory to implement.” My intuition is that this is not consistent with the WG charter. I think we're supposed to be specifying the GCD of JSONPath implementations, not enriching the language. The actual words of the charter are “based on the common semantics and other aspects of existing implementations”. Do len(), count(), match(), and search() qualify?
Most implications support regexps in filters, so we need to support those somehow. A function extension seems like the neatest solution.
Most implementations also support length in some way, usually , which we've decided against.
Guilty as charged. In that sentence I tried to express that, although the four functions make use of an extension point, they are not extensions of the base standard, as are none of the other features defined in the document. We don't define compliance, but we do fan the expectation that a JSONPath implementation will not leave out a feature that seems inconvenient to implement (say, descendants segments). If you have better wording, we could take that.
In all implementations there is some degree or level of compliance with the specification. No matter what the wording is in the specification the implementations will stand as they are and users will evaluate them based on how well or how compliant it is with the spec but more importantly how useful they are to them. In my implementation for go I have not yet implemented functions but do support regex with a . As this specification solidifies I'll also support the changes but in the interest of not breaking existing code that uses the OjG package I'll keep the original implementation as well.
NAME that's expected from most implementers, including myself. However, also as one of the editors, I would hope that implementors default to spec compliant behavior, offering other functionality behind options that the user must explicitly set. This is fairly common for spec implementations and what I will be doing if I decide to support extra-spec functionality.
I may not put it as eloquently as you do but I agree 100%. I hope I can contribute at some point.
Change:
The following API calls can be used to configure a Preconnection before calling Initiate(): <del> "RemoteSpecifier.WithMulticastGroupIPv4(GroupAddress) RemoteSpecifier.WithMulticastGroupIPv6(GroupAddress) RemoteSpecifier.WithPort(PortNumber) RemoteSpecifier.WithTTL(TTL) " </del> Calling Listen() on a Preconnection with a multicast group specified on the Remote Endpoint will join the multicast group to receive messages.  This Listener will create one Connection for each Remote

Discussion:
Review the use of and markdown in the API document, and make it consistent.
A fantastic PR! The best ever!
Change:
or configuration parameters.  The CoAP iPATCH, PATCH, and FETCH methods enable accessing and updating parts of a resource or multiple resources with one request.  This document defines new media types <del> for the CoAP iPATCH, and FETCH methods for resources represented with the SenML data model. </del> <ins> for the CoAP iPATCH, PATCH, and FETCH methods for resources represented with the SenML data model. </ins> 1.

Discussion:
using "(i)PATCH" to refer to both PATCH methods Clarified defaulting rules Clarified name resolving rules Clarified use of "resource" Added note that application of Patch Packs is idempotent Removed "more details in RFC-AAA" from media type encoding considerations (there are no more details actually)
Change:
is no data available to send.  An endpoint MAY send up to two full- sized datagrams containing ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single lost datagram or <del> transmit data from multiple packet number spaces. </del> <ins> transmit data from multiple packet number spaces.  All probe packets sent on a PTO MUST be ack-eliciting. </ins> In addition to sending data in the packet number space for which the timer expired, the sender SHOULD send ack-eliciting packets from

Discussion:
When writing , I found some of the text organization to be odd, so this moves it some.
Change:
Section 22.1.1 of QUIC-TRANSPORT. The initial allocations in these registries created in this document <del> are all assigned permanent status and list as contact both the IETF and the HTTP working group (ietf-http-wg@w3.org). </del> <ins> are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). </ins> 11.2.1.

Discussion:
At NAME suggestion this adds a "change controller" field to registries and splits between a change controller (IETF) and contact (QUIC WG). Not really sure if this is worth a design label...
Section 22.1.1: It is quite common that one may want to separate who has the change control over an registration entry vs who is the contact. Change control can often be assigned to an organization rather than an individual while a contact information may be an individual or a specific contact address for the organization. Contact information has a tendency to get stale, and in many case the contact if a person may no longer represent the organization that made the registration. Thus, my suggestion would be to add a separation between contact and change controller. In fact just for the registration in the Transport doc it makes sense to make the change controller "IETF" and have the contact be "QUIC WG".
This also applies to permanent registrations in Section 22.1.4
NAME does the PR address your issue?
Change looks good and implements what I proposed.
Labeling as "editorial" based on
Change:
handshake_failure (0x128 in QUIC).  Endpoints MAY use a generic error code to avoid possibly exposing confidential information. <del> 4.11. </del> <ins> 4.9. </ins> After QUIC moves to a new encryption level, packet protection keys for previous encryption levels can be discarded.  This occurs several

Discussion:
This adds a short introductory section to the three sections that deal with 0-RTT. That might help contextualize and help contain the spaghetti structure that this section seems to have.
Thanks Nick. I took it in a slightly different direction, but I think that I captured this.
One high-order bit: Using 0-RTT as a noun doesn't sound right, though we do use it informally in that sense. My suggestion use of "The 0-RTT handshake delay feature" or "0-RTT delay before sending application data" as appropriate.This change looks good.
Change:
An HTTP origin advertises the availability of an equivalent HTTP/3 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 <del> ALTSVC frame (ALTSVC), using the ALPN token defined in connection- establishment. </del> <ins> ALTSVC frame (ALTSVC), using the Application Layer Protocol Negotiation (ALPN) RFC7301 token defined in connection-establishment. </ins> For example, an origin could indicate in an HTTP response that HTTP/3 was available on UDP port 50781 at the same hostname by including the

Discussion:
Actually, as 3.1 is "to bre removed before publication", the expansion and ref should be in 3.2.1.
Change:
these missing blocks is as follows: The token to use for the response SHOULD be the token that was used <del> in the highest block number received payload.  Note that the use of any received token would work, but providing the one used in the highest received block number will aid any troubleshooting.  The client will use the token to match the request to find what Request- Tag value is currently being used. </del> <ins> in the highest block number received so far with the same Request-Tag value.  Note that the use of any received token with the same Request-Tag would work, but providing the one used in the highest received block number will aid any troubleshooting.  The client will use the token to determine what is the previously sent request to obtain the Request-Tag value to be used. </ins> If the size of the 4.08 (Request Entity Incomplete) response packet is larger than that defined by Section 4.6 RFC7252, then the number

Discussion:
The draft describes this all as "just working through a proxy" -- original block-wise does not, and I'd like to hear how this is hoping to get away without the options being proxy-unsafe. Is there any point at all in using block-by-block proxying for these use cases? Unless a proxy is sitting right inside the link under attack, and unless the bodies get huge, it may be way easier for this to be purely hop-by-hop. Proxies would reassemble the full bodies and, for the next hop, just decide what works best there (be it regular block-wise, Block34 or BERT). (If there's a point in allowing block-by-block forwarding, we can talk it through and work through the initial ideas that will come up like "We use large enough Request-Tag values so they are unique", "how large does that need to be", "why do we end up having a Request-Tag in every request now" and "why do we not want that", but my gut feeling is we won't need to go there.)
Change:
byte of the compressed value (key) to have a value other than 0x30, since every X.509 certificate starts with this byte. <ins> This element can be used to compress both client and server certificates.  However, in most deployments where client certificates are used, it would be inefficient to encode all client certificates into a single profile.  Instead, deployments can define a unique profile for each client, distinguished by the profile ID.  Note that the profile ID is sent in cleartext, so this strategy has significant privacy implications. </ins> 2.1.2. Some cTLS template elements imply that certain vectors (as defined in

Discussion:
NAME Ping. This is the last thing blocking a refreshed cTLS draft.
Just missed this. LGTM