jiebi/CodeConvo huggingface dataset:
Change:
version_information <del> permanent (if this document is approved) </del> <ins> provisional </ins> This document <ins> When this document is approved, it will request permanent allocation of a codepoint in the 0-63 range to replace the provisional codepoint described above. </ins> 12.2. This document registers a new value in the QUIC Transport Error Codes

Discussion:
I just saw a provisional registration for the 0xff73db value (from the current draft). This contains a note suggesting that the value might become permanent. Given how crucial version negotiation could be, I think we should seriously consider taking a codepoint from the 0-63 range.
Agreed, that was the intent but it wasn't clear from the draft. I wrote in to make it clearer.
Change:
As described in sec.ice-candidate-trickling, JSEP implementations always provide candidates to the application individually, consistent with what is needed for Trickle ICE.  However, applications can use <del> the canTrickleIce property to determine whether their peer can actually do Trickle ICE, i.e., whether it is safe to send an initial offer or answer followed later by candidates as they are gathered. As "true" is the only value that definitively indicates remote Trickle ICE support, an application which compares canTrickleIce against "true" will by default attempt Half Trickle on initial offers and Full Trickle on subsequent interactions with a Trickle ICE- compatible agent. </del> <ins> the canTrickleIceCandidates property to determine whether their peer can actually do Trickle ICE, i.e., whether it is safe to send an initial offer or answer followed later by candidates as they are gathered.  As "true" is the only value that definitively indicates remote Trickle ICE support, an application which compares canTrickleIceCandidates against "true" will by default attempt Half Trickle on initial offers and Full Trickle on subsequent interactions with a Trickle ICE-compatible agent. </ins> 4.1.10.

Discussion:
It has a new name.
Overall this LG, although having thought about it a bit more, .canTrickleIce seems like a not-fully-formed clause. .canTrickleIceCandidates seems like it might match better to addIceCandidate().
LGTM. NAME NAME LMK if you have any issues with this
The diff is incomprehensible due to the all the gratuitous whitespace changes. I'll make a diff I can review at some point and see if I can figure it out.
LGTM
I will manually merge this.
Change:
encrypted_client_hello(0xff08), with "TLS 1.3" column values being set to "CH, EE", and "Recommended" column being set to "Yes". <del> outer_extension(0xff04), with the "TLS 1.3" column values being set to "CH", and "Recommended" column being set to "Yes". </del> <ins> outer_extensions(0xff04), with the "TLS 1.3" column values being set to "", and "Recommended" column being set to "Yes". </ins> 11.2.

Discussion:
Along the way, I've made two additional tweaks: Renamed outerextension to outerextensions, now that it contains multiple extensions. One of the diagrams even already referred to "outerextensions" because I didn't realize it was called "outerextension".Clarified in compression process and ClientHelloInner construction rules that the to-be-compressed extensions must be consecutive. Hopefully that helps with .
NAME FYI. I'm hoping this will help clarify why the ordering thing isn't actually a big deal.
I've updated the PR to include text to disambiguate the serialization. It's ambiguous whether the encoding includes the 4-byte (12-byte in DTLS) header from the Handshake structure or is just the body, from the ClientHello structure. I've picked the smaller one. This also saves having to answer, in DTLS, what happens when the inner sequence number is wrong.
There are two ClientHelloInners, the actual one used in the handshake, and the encoded one with outerextensions substituted in. Both are described as ClientHelloInner, but this makes it slightly ambiguous which goes into, say, the handshake transcript. (It's late now, so I'll leave this as an issue without a PR. If we don't end up resolving this separately, I'll probably fix this as part of . If we decide to implicitly copy over legacysession_id, the encryption payload becomes less and less defensibly an actual ClientHelloInner.)
In my own implementation, I've been referring to the plaintext payload as CompressedClientHelloInner. Which is terrible, but unambiguous.
Works for me. I was thinking EncodedClientHelloInner because it's shorter and still works even if you choose not to compress anything. (A no-op encoding is still an encoding.)
+1 to EncodedClientHelloInner, given that compression is optional. NAME if you have time, could you whip up a PR?
Change:
also support the imposition and disposition of the required DetNet encapsulation.  These are functionally similar to pseudowire (PW) Terminating Provider Edge (T-PE) nodes which use MPLS-TE LSPs.  In <del> this example they understand and support IEEE 802.1 TSN and are able to map TSN Streams into DetNet flows.  The specific of this operation are discussed later in this document. </del> <ins> this example TSN Streams are simple applicaions over DetNet flows. The specific of this operation are discussed later in this document. </ins> In this example, edge nodes provide a service proxy function that "associates" the DetNet flows and native flows (i.e., TSN Streams) at <del> the edge of the DetNet domain.  This ensures that the DN Flow is properly served at the Edge node (and inside the domain). </del> <ins> the edge of the DetNet domain.  TSN streams are treated as App-flows for DetNet.  The whole DetNet domain behaves as a TSN relay node for the TSN streams.  The service proxy behaves as a port of that TSN relay node. </ins> fig_8021_detnet illustrates how DetNet can provide services for IEEE 802.1 TSN end systems, CE1 and CE2, over a DetNet enabled MPLS

Discussion:
Work In progress - Wanted to get the figure changes out for review. Need to check if the overly wording is complete. There was a lot of inter working text - I have commented out.
Change:
The signed contents of Internet-Drafts are primarily intended to be consumed by human.  To be more precise, contents are intended to be shown to human in a printable or displayable form by means of <del> services or software, rather than processed by machines.  To validate the digital signature which is signed to contents intended to be consumed by human, implementations MAY perform the steps below as a certificate validation: </del> <ins> services or software, rather than processed by machines.  The digital signature on the contents is to indicate to the recipient of the contents that the content has not changed since it was signed by the identity indicated as the subject of the certificate.  To validate the digital signature which is signed on contents intended to be consumed by humans, implementations MAY perform the steps below during certificate validation: </ins> The implementation MAY examine the Extended Key Usage value(s):

Discussion:
This PR contains corrections to more accurate expression. This PR does not contains modification related to backwards compatibility and interoperability.
Thanks Sean I approved all above modifications.
Change:
running in the browser. A commonly imagined model of deployment is the one depicted below. <ins> In the figure below JS is Javascript. </ins> On this drawing, the critical part to note is that the media path ("low path") goes directly between the browsers, so it has to be

Discussion:
This deals with some of Meral's GEN-ART comments.
I can see putting it back, but we should be consistent there were two e.g. and two for examples. My matchy-matchy tendencies getting to me.
:-) I can flip it in the other direction. Sometimes I show off my English skills, othertimes I want to write simple English. Trapped by my own filters .... the review ended up in my gen-art inbox, which I stopped reading years ago when I left the gen-art team....
No worries. I would go with whatever the RFC editor is going to end up doing, but to be honest I don’t know which they’d prefer. spt
Change:
can directly compare it to its own clock and timestamps. The Verifier can check whether the Evidence is fresh when appraising <del> it at time(RG) by checking "time(RG) - time(EG) < Threshold", where the Verifier's threshold is large enough to account for the maximum permitted clock skew between the Verifier and the Attester. </del> <ins> it at time(RG_v) by checking "time(RG_v) - time(EG_a) < Threshold", where the Verifier's threshold is large enough to account for the maximum permitted clock skew between the Verifier and the Attester. </ins> <del> If time(VG) is also included in the Evidence along with the claim </del> <ins> If time(VG_a) is also included in the Evidence along with the claim </ins> value generated at that time, and the Verifier decides that it can <del> trust the time(VG) value, the Verifier can also determine whether the claim value is recent by checking "time(RG) - time(VG) < Threshold", again where the threshold is large enough to account for the maximum permitted clock skew between the Verifier and the Attester. </del> <ins> trust the time(VG_a) value, the Verifier can also determine whether the claim value is recent by checking "time(RG_v) - time(VG_a) < Threshold", again where the threshold is large enough to account for the maximum permitted clock skew between the Verifier and the Attester. </ins> The Relying Party can check whether the Attestation Result is fresh <del> when appraising it at time(RA) by checking "time(RA) - time(RG) < Threshold", where the Relying Party's threshold is large enough to </del> <ins> when appraising it at time(RA_r) by checking "time(RA_r) - time(RG_v) < Threshold", where the Relying Party's threshold is large enough to </ins> account for the maximum permitted clock skew between the Relying Party and the Verifier.  The result might then be used for some time (e.g., throughout the lifetime of a connection established at <del> time(RA)).  The Relying Party must be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain fresh enough.  Thus, it might allow use (at time(OP)) as long as "time(OP) - time(RG) < Threshold".  However, if the Attestation Result contains an expiry time time(RX) then it could explicitly check "time(OP) < time(RX)". </del> <ins> time(RA_r)).  The Relying Party must be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain fresh enough.  Thus, it might allow use (at time(OP_r)) as long as "time(OP_r) - time(RG_v) < Threshold". However, if the Attestation Result contains an expiry time time(RX_v) then it could explicitly check "time(OP_r) < time(RX_v)". </ins> 15.2.

Discussion:
This pull request puts _X on all time points. Please review for accuracy.
I am neutral/okay with consistently adding suffixes to every event label
Change:
new parameters and sends a reject message back to the offerer.  Now, the offerer, and possibly the answerer as well, needs to return to a "stable" state and the previous local/remote description.  To support <del> this, we introduce the concept of "rollback", which discards any proposed changes to the session, returning the state machine to the "stable" state.  A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or setRemoteDescription. </del> <ins> this, this specification introduces the concept of "rollback", which discards any proposed changes to the session, returning the state machine to the "stable" state.  A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or setRemoteDescription. </ins> 4.1.11.

Discussion:
Explain more about use of max-bundle by implementations Explain sess-id limits Remove use of "we" throughout
Change:
This use-case is mostly relevant for when mobile users are considered or when the chosen band induce a required physical-layer coding that may change over time (Q/V bands, Ka band, etc.).  Depending on the <del> use-case (e.g. very high frequency bands, mobile users) or depending on the deployment use-cases (e.g. performance of the network between </del> <ins> use-case (e.g., very high frequency bands, mobile users) or depending on the deployment use-cases (e.g., performance of the network between </ins> each individual block), the relevance of adding coding techniques is different.

Discussion:
Introduction physical-layer reliability mechanisms -- hyphenate adjectival terms style: e.g. should be in a clause separated by commas, not brackets. 500 ms one-way delivery delay (or path -- i.e. not propagation)
Intro must do the same, clarifying also it's not a standard, and give an estimation of the support it collected during discussion within the group. For instance (taken from rfc 8406): This document is the product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not a standard. .
I think PR solves the issue.
Change:
3. <del> The model of real-time support for browser-based applications does not assume that the browser will contain all the functions that need to be performed in order to have a function such as a telephone or a video conferencing unit; the vision is that the browser will have the functions that are needed for a Web application, working in conjunction with its backend servers, to implement these functions. </del> <ins> For browser-based applications, the model for real-time support does not assume that the browser will contain all the functions needed for an application such as a telephone or a video conference.  The vision is that the browser will have the functions needed for a Web application, working in conjunction with its backend servers, to implement these functions. </ins> This means that two vital interfaces need specification: The protocols that browsers use to talk to each other, without any

Discussion:
Please double check this, but it did say "functions for ... function such as" so I changed the second function to application.
Ben had the following comment: 3, first paragraph: This is also convoluted and hard to parse.
Change:
The SenML Stream is represented as a sensml tag that contains a series of senml tags for each SenML Record.  The SenML Fields are represents as XML attributes.  The following table shows the mapping <del> of the SenML labels to the attribute names and types used in the XML senml tags. </del> <ins> of the SenML labels, which are used for the attribute name, to the attribute types used in the XML senml tags. </ins> The RelaxNG schema for the XML is:

Discussion:
From EMAIL - aug 31 Hello Ari, I'm just putting the finishing touches on an IETF draft to introduce the base time offset attribute that we discussed in Berlin. One thing I noticed was that the IANA considerations section (11.2) that describes the SenML label registry mentions the need to define the label name, label, json type and xml type for the new attribute. However the SenML draft also defines the CBOR representation and EXI representation. I assume updates to these will also be needed in order to register a new SenML label? For the XML representation the IANA text mentions the need to define the XML type. However section 7 "XML representation" includes the RelaxNG compact schema. Does this also need to be updated? and if so how? Should the entire schema be listed or should a new schema be defined using an "include" construct? The schema in the SenML draft doesn't have a name (e.g. URL) so I'm not sure how this would be done? The other issue is that the current compact RelaxSchema enforces ordering of the labels. If I define a new bto attribute I take it that bto should be associated with the base attributes and come after bver and before the regular attributes. I'm not familiar enough with RelaxNG to detail that without re-including the entire schema. It also leads to the question of what happens with ordering if someone else defines another base attribute. Should bto or the other attribute take precedence after bver? I think the syntax and draft needs to take this into account. The EXI representation clause 8 in the SenML draft includes an XSD generated from the RelaxNG. Would the generation of the complete schema be required for the addition of an new attribute? There seems to be similar issues to the RelaxNG schema. For CBOR there's also the CDDL specification in section 10. I'm not that familiar with CDDL but it seems to define an extension mechanism that group the base and regular attributes. There's no text associated with this section as to the need to define extensions and whether the defining the JSON label and type is enough for the CDDL. It seems to me that the schemes need to be updated to include some extension points to enable new attributes to be added without having to update the schemas.

Also given that we have to define these various different representations I wonder if the registry should instead be called the SenML attribute registry? The reasoning is that the registry would have to include not only JSON labels but the CBOR mapping key etc. Regards, Christian
Change:
information to the timestamp. This document does not address extensions to the format where the <del> semantic result no longer is a fixed timestamp that is referenced to </del> <ins> semantic result is no longer a fixed timestamp that is referenced to </ins> a (past or future) UTC time.  For instance, it does not address: Future time given as a local time in some specified time zone,

Discussion:
Replace "DST" and "daylight savings time" with "daylight saving time" Replace "timezone" with "time zone" Properly capitalize "Unicode Consortium" Improve phrasing
If you don't have time to work further on this very useful PR, I could merge it and fix these three nits.
Please don't add material to this one. We went the opposite direction in the last interim, so I'm about to remove some of this text.
OK, I pushed a commit just before your last comment but will withhold any further changes.
Sorry for the unsmooth handling of this PR. I now cherry-picked from this PR. Can I ask you to rebase to main and see what remaining parts you want to pursue?
My last message was too close to the holidays. Do you want to rebase this PR? Or do you think it is essentially covered by my cherry-picking?
Thanks for the ping, NAME Almost everything was covered by the cherry-picking, but a few things remain. I have rebased the PR to include only those.
Change:
i.e., when the data derived from the Message has been passed down or through the underlying Protocol Stack and is no longer the responsibility of the implementation of this interface.  The exact <del> disposition of the Message when the Sent Event occurs is specific to the implementation and the constraints on the Protocol Stacks implied by the Connection's Transport Properties.  The Sent Event contains an implementation-specific reference to the Message to which it applies. </del> <ins> disposition of the Message (i.e., whether it has actually been transmitted, moved into a buffer on the network interface, moved into a kernel buffer, and so on) when the Sent Event occurs is implementation-specific.  The Sent Event contains an implementation- specific reference to the Message to which it applies. </ins> Sent Events allow an application to obtain an understanding of the amount of buffering it creates.  That is, if an application calls the

Discussion:
quickly adding this to fix NAME nits before -01 submission
Text: Internally, the transport system will first exclude all protocols and paths that match a Prohibit, then only keep candidates that match a Require, then sort candidates according to Preferred properties, and then use Avoided properties as a tiebreaker. does not read correct for me... I understand excluding prohibit, but the action on require seems wrong. I expected to remove candidates with prohibit and remove candidates that do NOT have require. What is written is different. —- I would prefer a para break before: The Rendezvous() Action causes the to show the change of topic. — Refs needed: SIP or WebRTC — maximum Message size should this be capitalised? What is maxlen? The same value? Of different? —- I could not finally understand what is intended by this text; The exact disposition of the Message when the Sent Event occurs is specific to the implementation and the constraints on the Protocol Stacks implied by the Connection's Transport Properties.
Change:
2.5. <del> In the case of a Client DISCONNECT, due to the Clean Session flag, the Broker deletes all session state but MUST keep the retained messages.  By setting a RETAIN flag in a PUBLISH message, the </del> <ins> In the case of a Client DISCONNECT, due to the Clean Start flag (or Clean Session flag with MQTT v3.1.1), the Broker deletes all session state but MUST keep the retained messages and token expiry information.  By setting a RETAIN flag in a PUBLISH message, the </ins> publisher indicates to the Broker that it should store the most <del> recent message for the associated topic.  Hence, the new subscribers can receive the last sent message from the publisher of that particular topic without waiting for the next PUBLISH message.  The Broker MUST continue publishing the retained messages as long as the associated tokens are valid. </del> <ins> recent message for the associated topic.  Hence, new subscribers can receive the most recent message from the publisher of that particular topic without waiting for the next PUBLISH message.  The Broker MUST continue publishing each retained message until the token for that message has expired, or another RETAIN message is published on the associated topic. </ins> In case of disconnections due to network errors or server disconnection due to a protocol error (which includes authorization

Discussion:
I believe this " if you're happy with it now we're (assumed) targetting MQTT v5.0 we should refer to Clean Start acknowledge that RETAINed messages could be made irrelevant by further publishes
yes, that's much better, thanks! (see e46a8d)
Section 2.5 - The last sentence in the first paragraph could be state more clearly. Specifically there would appear to be some ambiguity on who the associated tokens are attached to. "messages as long as the publisher token for that message remains valid." Might be better.
Better working might to "the retailed message until the token for that message has expired," That avoids the question if all of the tokens have expired or just the one with the message.
Change:
higher value.  By default, this value is Infinite.  The caller is also able to reset the value to Infinite at any point. <del> A ListenError occurs either when the Properties and Security </del> <ins> A EstablishmentError occurs either when the Properties and Security </ins> Parameters of the Preconnection cannot be fulfilled for listening or cannot be reconciled with the Local Endpoint (and/or Remote Endpoint, if specified), when the Local Endpoint (or Remote Endpoint, if

Discussion:
No need to have a different type of Event for initiate, listen and rendezvous.
On a PreConnection, an application uses EITHER Initiate OR Listen OR Rendezvous. Therefore, it seems unnecessary to distinguish between three types of errors. Shouldn't we have a general per-PreConnection "UnfulfilledError" instead of the InitiateError + ListenError + RendezvousError, just to shorten things a bit? An application needs more details (reasons), but it gets them as a parameter anyway when the new "UnfulfilledError" would occur.