jiebi/CodeConvo huggingface dataset:
Code change:
Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).

Related discussion:
text: using SIP for signaling, if one offer is sent and is then canceled using a SIP CANCEL, another offer can be generated even though no answer was received for the first offer.  To support this, the JSEP <del> media layer can provide an offer via the createOffer() method whenever the JavaScript application needs one for the signaling.  The answerer can send back zero or more provisional answers and then finally end the offer/answer exchange by sending a final answer.  The state machine for this is as follows: </del> <ins> media layer can provide an offer via the createOffer method whenever the JavaScript application needs one for the signaling.  The answerer can send back zero or more provisional answers and then finally end the offer/answer exchange by sending a final answer.  The state machine for this is as follows: </ins> Aside from these state transitions, there is no other difference between the handling of provisional ("pranswer") and final ("answer")
Code change:
Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).

Related discussion:
text: in RFC5888.  addTrack attempts to minimize the number of transceivers as follows: if the PeerConnection is in the "have-remote-offer" state, the track will be attached to the first compatible transceiver <del> that was created by the most recent call to setRemoteDescription() and does not have a local track.  Otherwise, a new transceiver will be created, as described in sec.addTransceiver. </del> <ins> that was created by the most recent call to setRemoteDescription and does not have a local track.  Otherwise, a new transceiver will be created, as described in sec.addTransceiver. </ins> 4.1.3.
Code change:
Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).

Related discussion:
text: "offer" indicates that a description should be parsed as an offer; said description may include many possible media configurations.  A description used as an "offer" may be applied any time the <del> PeerConnection is in a stable state or applied as an update to a </del> <ins> PeerConnection is in a "stable" state or applied as an update to a </ins> previously supplied but unanswered "offer". "pranswer" indicates that a description should be parsed as an
Code change:
Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).

Related discussion:
text: voicemail). "rollback" is a special session description type implying that the <del> state machine should be rolled back to the previous stable state, as described in sec.rollback.  The contents MUST be empty. </del> <ins> state machine should be rolled back to the previous "stable" state, as described in sec.rollback.  The contents MUST be empty. </ins> 4.1.8.1.
Code change:
Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).

Related discussion:
text: after setRemoteDescription, decides it does not want to accept the 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 <del> stable state and the previous local/remote description.  To support </del> <ins> "stable" state and the previous local/remote description.  To support </ins> this, we introduce the concept of "rollback", which discards any proposed changes to the session, returning the state machine to the <del> stable state.  A rollback is performed by supplying a session </del> <ins> "stable" state.  A rollback is performed by supplying a session </ins> description of type "rollback" with empty contents to either setLocalDescription or setRemoteDescription.
Code change:
Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).

Related discussion:
text: 5.2.3.1. <del> If the "IceRestart" option is specified, with a value of "true", the </del> <ins> If the IceRestart option is specified, with a value of "true", the </ins> offer MUST indicate an ICE restart by generating new ICE ufrag and pwd attributes, as specified in RFC8839.  If this option is specified on an initial offer, it has no effect (since a new ICE ufrag and pwd
Code change:
Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).

Related discussion:
text: A rollback may be performed if the PeerConnection is in any state except for "stable".  This means that both offers and provisional answers can be rolled back.  Rollback can only be used to cancel <del> proposed changes; there is no support for rolling back from a stable state to a previous stable state.  If a rollback is attempted in the "stable" state, processing MUST stop and an error MUST be returned. Note that this implies that once the answerer has performed setLocalDescription with its answer, this cannot be rolled back. </del> <ins> proposed changes; there is no support for rolling back from a "stable" state to a previous "stable" state.  If a rollback is attempted in the "stable" state, processing MUST stop and an error MUST be returned.  Note that this implies that once the answerer has performed setLocalDescription with its answer, this cannot be rolled back. </ins> The effect of rollback MUST be the same regardless of whether setLocalDescription or setRemoteDescription is called.
Code change:
Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).

Related discussion:
text: the threat model of RFC3552 applies.  In particular, JavaScript can call the API in any order and with any inputs, including malicious ones.  This is particularly relevant when we consider the SDP that is <del> passed to setLocalDescription().  While correct API usage requires that the application pass in SDP that was derived from createOffer() or createAnswer(), there is no guarantee that applications do so. The JSEP implementation MUST be prepared for the JavaScript to pass in bogus data instead. </del> <ins> passed to setLocalDescription.  While correct API usage requires that the application pass in SDP that was derived from createOffer or createAnswer, there is no guarantee that applications do so.  The JSEP implementation MUST be prepared for the JavaScript to pass in bogus data instead. </ins> Conversely, the application programmer needs to be aware that the JavaScript does not have complete control of endpoint behavior.  One
Code change:
Emerging best practice is to use for new headers, so that parsing is well-defined. Arguments for sticking with a -like syntax: Consistence with (IMO a very poor justification) Reuse of parsers / other software (it's not well-defined, tho) ???
We could also talk about creating a SF version of (maybe ?).
Matching SF and headers would be appealing.
In the meantime (or maybe before ;) -- URL

Related discussion:
text: BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> This document uses the Augmented BNF defined in HTTP to specify valid protocol elements.  Additionally, it uses the modified "parameter" rule from RFC5987 and the "URI-Template" rule from URI-TEMPLATE. </del> <ins> This specification uses the following terms from STRUCTURED-FIELDS: List, String, Parameter. </ins> 2. <del> The Link-Template header field provides a means for serialising one or more links into HTTP message metadata.  It is semantically equivalent to the Link header field defined in WEB-LINKING, except that it uses URI Templates URI-TEMPLATE to convey the structure of links. </del> <ins> The Link-Template header field is a Structured Field STRUCTURED- FIELDS that serializes one or more links into HTTP message metadata. It is semantically equivalent to the Link header field defined in WEB-LINKING, except that it uses URI Templates URI-TEMPLATE to convey the structure of links. Its value is a List of Strings.  Each String is a URI Template, and Parameters on it carry associated metadata. </ins> For example:
Code change:
Emerging best practice is to use for new headers, so that parsing is well-defined. Arguments for sticking with a -like syntax: Consistence with (IMO a very poor justification) Reuse of parsers / other software (it's not well-defined, tho) ???
We could also talk about creating a SF version of (maybe ?).
Matching SF and headers would be appealing.
In the meantime (or maybe before ;) -- URL

Related discussion:
text: Parameters on a templated-link have identical semantics to those of a Link header field.  This includes (but is not limited to) the use of the "rel" parameter to convey the relation type, the "anchor" <del> parameter to modify the context IRI, and so on. </del> <ins> parameter to modify the context IRI, and so on.  Parameter values MUST be Strings. </ins> Likewise, the requirements for parameters on templated-links are the <del> same as those for a Link header field; in particular, the "rel" parameter MUST NOT appear more than once, and if it does, the templated-link MUST be ignored by parsers. </del> <ins> same as those for a Link header field. </ins> This specification defines additional semantics for the "var-base" parameter on templated-links; see below.
Code change:
and .
In light of , NAME concerns about the framework, and NAME declining interest in implementing, I think it's time to simply eliminate this from the document.
Thanks for all the hard work, but sorry to be the cause of it.
Fixed by
How does a dynamic framework survive an HA handover? It would seem to lose all the SID allocations and break all connections.

Related discussion:
text: Load balancers SHOULD drop short header packets with unroutable DCIDs. <del> The routing of long headers with unroutable DCIDs depends on the server ID allocation strategy, described in sid-allocation.  However, the load balancer MUST NOT drop these packets, with one exception. </del> <ins> When forwarding a packet with a long header and unroutable DCID, load balancers MUST use a fallback algorithm as specified in fallback- algorithm. </ins> Load balancers MAY drop packets with long headers and unroutable DCIDs if and only if it knows that the encoded QUIC version does not
Code change:
and .
In light of , NAME concerns about the framework, and NAME declining interest in implementing, I think it's time to simply eliminate this from the document.
Thanks for all the hard work, but sorry to be the cause of it.
Fixed by
How does a dynamic framework survive an HA handover? It would seem to lose all the SID allocations and break all connections.

Related discussion:
text: 4.3. <del> For any given configuration, the configuration agent must specify if server IDs will be statically or dynamically allocated.  Load Balancer configurations with statically allocated server IDs explicitly include a mapping of server IDs to forwarding addresses. The corresponding server configurations contain one or more unique server IDs. </del> <ins> Load Balancer configurations include a mapping of server IDs to forwarding addresses.  The corresponding server configurations contain one or more unique server IDs. </ins> <del> A dynamically allocated configuration does not have a pre-defined assignment, reducing configuration complexity.  However, it places limits on the maximum server ID length and requires more state at the load balancer.  In certain edge cases, it can force parts of the system to fail over to 5-tuple routing for a short time. In either case, the configuration agent chooses a server ID length for each configuration that MUST be at least one octet.  For Static Allocation, the maximum length depends on the algorithm.  For dynamic allocation, the maximum length is 7 octets. </del> <ins> The configuration agent chooses a server ID length for each configuration that MUST be at least one octet. </ins> A QUIC-LB configuration MAY significantly over-provision the server ID space (i.e., provide far more codepoints than there are servers) to increase the probability that a randomly generated Destination Connection ID is unroutable. <ins> The configuration agent SHOULD provide a means for servers to express the number of server IDs it can usefully employ, because a single routing address actually corresponds to multiple server entities (see lb-chains). </ins> Conceptually, each configuration has its own set of server ID allocations, though two static configurations with identical server ID lengths MAY use a common allocation between them.