jiebi/CodeConvo huggingface dataset:
Change:
lgtm with justin's comments.
Ping on this
overall this LG for consistency with the surrounding text, I would change the usage of "[XXXX] (see Section 3)" to "[XXXX], Section 3"

Discussion:
An "a=sendrecv" line, as specified in RFC3264, Section 5.1. For each supported codec, "a=rtpmap" and "a=fmtp" lines, as <del> specified in RFC4566, Section 6.  For audio, the codecs specified in I-D.ietf-rtcweb-audio, Section 3, MUST be be supported. </del> <ins> specified in RFC4566, Section 6.  The REQUIRED audio and video codecs to support are specified in I-D.ietf-rtcweb-audio (see Section 3) and I-D.ietf-rtcweb-video (see Section 5). </ins> If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the

For each supported codec that is present in the offer, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and <del> RFC3264, Section 6.1.  For audio, the codecs specified in I- D.ietf-rtcweb-audio, Section 3, MUST be supported.  Note that for simplicity, the answerer MAY use different payload types for codecs than the offerer, as it is not prohibited by Section 6.1. </del> <ins> RFC3264, Section 6.1.  The REQUIRED audio and video codecs to support are specified in I-D.ietf-rtcweb-audio (see Section 3) and I-D.ietf-rtcweb-video (see Section 5).  Note that for simplicity, the answerer MAY use different payload types for codecs than the offerer, as it is not prohibited by Section 6.1. </ins> If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the
Change:
clarified TLS fingerprints, removed comments, issue 7
7) [rfced] Section 3.2: We do not see any mention of DTLS in RFC 8122; we only see "TLS." Will this citation be clear to readers? Original: An example of such a parameter is the DTLS fingerprints [RFC8122], which are calculated based on the local certificate(s) offered, and are not subject to negotiation. Possibly: An example of such a parameter is the TLS fingerprints [RFC8122] as used in the context of DTLS [RFC6347]; these fingerprints are calculated based on the local certificate(s) offered and are not subject to negotiation.
Comment is correct, suggestion seems reasonable.
NAME please close this issue once you consider it resolved.

Discussion:
the remote side supports, specifies what the remote side should send. However, not all parameters follow this rule; some parameters are declarative, and the remote side MUST either accept them or reject <del> them altogether.  An example of such a parameter is the DTLS fingerprints RFC8122, which are calculated based on the local certificate(s) offered and are not subject to negotiation. </del> <ins> them altogether.  An example of such a parameter is the TLS fingerprints RFC8122 as used in the context of DTLS RFC6347; these fingerprints are calculated based on the local certificate(s) offered and are not subject to negotiation. </ins> In addition, various RFCs put different conditions on the format of offers versus answers.  For example, an offer may propose an
Change:
use 'prepares to gather' instead of 'goes to gather', removed comments, issue 9
9) [rfced] We suggest clarifying "goes to gather" - perhaps "gathers", "starts to gather", "prepares to gather", etc. "goes to gather" may be confusing for some readers. Original: When setLocalDescription is eventually called, and the JSEP implementation goes to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool.
'prepares to gather' seems like the right choice.
NAME please close this issue once you consider it resolved.

Discussion:
setup. When setLocalDescription is eventually called and the JSEP <del> implementation goes to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool.  If there are candidates in the pool, they SHOULD be handed to the </del> <ins> implementation prepares to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool. If there are candidates in the pool, they SHOULD be handed to the </ins> application immediately via the ICE candidate event.  If the pool becomes depleted, either because a larger-than-expected number of ICE components are used or because the pool has not had enough time to
Change:
used suggestion 2, deleted comments, issue 12
12) [rfced] Section 4.1.8.1: We had trouble with this sentence. If neither suggestion below is correct, please clarify. Original: While this could also be done with a "sendonly" pranswer, followed by a "sendrecv" answer, the initial pranswer leaves the offer-answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer, if followed by a "sendrecv" answer the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer followed by a "sendrecv" answer, the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time.
suggestion seems right

Discussion:
actually accepts the call, the application can plug in the real MediaStreamTrack and create a new "sendrecv" offer to update the previous offer/answer pair and start bidirectional media flow.  While <del> this could also be done with a "sendonly" pranswer, followed by a </del> <ins> this could also be done with a "sendonly" pranswer followed by a </ins> "sendrecv" answer, the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time.
Change:
NAME NAME PTAL
This LGTM. Have you run it through a parser? If not, I'm going to give that a shot.
Addressed all comments, save the parser. PTAL.
LGTM. Fluffy?
LGTM - I did not really have time to review it but again, looks close enough I'd like to see it merged into the draft and that will make it easier to fix any nits.

Discussion:
This section shows a typical example of a session between two browsers setting up an audio channel and a data channel.  Trickle ICE <del> is used in full trickle mode with a policy of max-bundle-and-rtcpmux </del> <ins> is used in full trickle mode with a policy of max-bundle-and-rtcp-mux </ins> and a single TURN server.  Later, two video flows, one for the presenter and one for screen sharing, are added to the session.  This example shows Alice's browser initiating the session to Bob's

The SDP for |answer-B1| looks like: <del> The SDP for |offer-B2| looks like: </del> <ins> The SDP for |candidate-B4| looks like: </ins> <del> The SDP for |answer-B2| looks like: </del> <ins> The SDP for |candidate-B5| looks like: The SDP for |candidate-B6| looks like: The SDP for |offer-B2| looks like: (note the increment of the version number in the o= line, and the c= and a=rtcp lines, which indicate the local candidate that was selected) The SDP for |answer-B2| looks like: (note the use of setup:passive to maintain the existing DTLS roles, and the use of a=recvonly to indicate that the video streams are one-way) </ins> 8.
Change:
Updated a few sentences in Section 1 regarding XMPP and SIP libraries and the API surface. Removed comments. issue 5 and issue 6.
6) [rfced] Section 1.2: We had trouble parsing this sentence. If the suggested text is not correct, please clarify "as well as creating ..." Original (the previous sentence is included for context): A second approach that was considered but not chosen was to decouple the management of the media control objects from session descriptions, instead offering APIs that would control each component directly. This was rejected based on the argument that requiring exposure of this level of complexity to the application programmer would not be beneficial; it would result in an API where even a simple example would require a significant amount of code to orchestrate all the needed interactions, as well as creating a large API surface that needed to be agreed upon and documented. Suggested: This was rejected based on the argument that requiring exposure of this level of complexity to the application programmer would not be beneficial; it would (1) result in an API where even a simple example would require a significant amount of code to orchestrate all the needed interactions and (2) create a large API surface that needed to be agreed upon and documented.
This mostly LGTM, but the final sentence reads a bit oddly now - perhaps

Discussion:
said library would implement a given signaling protocol along with its state machine and serialization code, presenting a higher-level call-oriented interface to the application developer.  For example, <del> libraries exist to adapt the JSEP API into an API suitable for a SIP interface or an Extensible Messaging and Presence Protocol (XMPP) interface RFC6120.  Thus, JSEP provides greater control for the experienced developer without forcing any additional complexity on the novice developer. </del> <ins> libraries exist to provide implementations of the SIP RFC3261 and Extensible Messaging and Presence Protocol (XMPP) RFC6120 signaling protocols atop the JSEP API.  Thus, JSEP provides greater control for the experienced developer without forcing any additional complexity on the novice developer. </ins> 1.2.

descriptions, instead offering APIs that would control each component directly.  This was rejected based on the argument that requiring exposure of this level of complexity to the application programmer <del> would not be beneficial; it would result in an API where even a </del> <ins> would not be beneficial; it would (1) result in an API where even a </ins> simple example would require a significant amount of code to <del> orchestrate all the needed interactions, as well as creating a large API surface that needed to be agreed upon and documented.  In </del> <ins> orchestrate all the needed interactions and (2) create a large API surface that would need to be agreed upon and documented.  In </ins> addition, these API points could be called in any order, resulting in a more complex set of interactions with the media subsystem than the JSEP approach, which specifies how session descriptions are to be
Change:
clarified that there are four conditions, removed comment. issue 14
14) [rfced] Sections 4.1.9 and 4.1.10: We had trouble following the purpose of all of the "and"s in these sentences. Are four conditions set in these sentences, or fewer? Original: If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final), and the media directions are compatible, and media is available to send, this will result in the starting of media transmission. ... If setLocalDescription was previously called with an offer, and setRemoteDescription is called with an answer (provisional or final), and the media directions are compatible, and media is available to send, this will result in the starting of media transmission. Possibly: If (1) setRemoteDescription was previously called with an offer, (2) setLocalDescription is called with an answer (provisional or final), (3) the media directions are compatible, and (4) media is available to send, media transmission can start. ... If (1) setLocalDescription was previously called with an offer, (2) setRemoteDescription is called with an answer (provisional or final), (3) the media directions are compatible, and (4) media is available to send, media transmission can start.
need to keep 'this will result in the starting of media transmission'
There are 4 conditions that have to be satisfied, as noted.

Discussion:
begin gathering candidates for each transport, using ones from the candidate pool if available. <del> If setRemoteDescription was previously called with an offer, and </del> <ins> If (1) setRemoteDescription was previously called with an offer, (2) </ins> setLocalDescription is called with an answer (provisional or final), <del> and the media directions are compatible, and media is available to send, this will result in the starting of media transmission. </del> <ins> (3) the media directions are compatible, and (4) media is available to send, this will result in the starting of media transmission. </ins> 4.1.10.

This API changes the local media state; among other things, it sets up local resources for sending and encoding media. <del> If setLocalDescription was previously called with an offer, and </del> <ins> If (1) setLocalDescription was previously called with an offer, (2) </ins> setRemoteDescription is called with an answer (provisional or final), <del> and the media directions are compatible, and media is available to send, this will result in the starting of media transmission. </del> <ins> (3) the media directions are compatible, and (4) media is available to send, this will result in the starting of media transmission. </ins> 4.1.11.
Change:
The following changes have been made: changed to "set to zero" from "set to 0", removed comment. formatted media-field subfields consistently, removed comment.

fmt value / "fmt" value Justin: Would we also do media, port, and proto? This one needs more discusison.
RFC 4566 (SDP) was inconsistent in the formatting of fmt (, "fmt"), proto ("proto", ), and port (port, ). For the most part, media was just formatted media. RFC 8866 (SDP), which obsoletes RFC 4566, consistently formats these "m=" line subfields as , , , and . This document uses the following formats: fmt (3 instances) vs (2 instances) proto (7 instances) vs (5 instances) port (31) vs (0 instances) -- most are not referring specifically to the subfield, though I suggest using angle brackets (but not formatting -- I was just working around GitHub's markdown with that) for these terms when discussing "m=" line subfields.
SGTM, let's align with 8866 usage when an instance of these words refers specifically to a m= line subfield.
set to zero / set to 0 >(May we use the latter, because of '"dummy" port value of 9' in Sections 5.2.1 and 5.3.1?) Justin: What's the IETF style guide say on this sort of thing? 'zero' looks more natural to me, and matches RFC 3264's usage of 'zero'.
From our style guide: "In general text, we follow the CMOS guidance that numbers under 10 are written out and those above are represented using digits. However, if a value is followed by a unit of measure (e.g., 8 bytes, 3 octets), it should be in digit form regardless of value." There is one instance of "set to 0" in this document vs four instances of "set to zero". I can change that one instance to match the other four.
LGTM

Discussion:
For each offered "m=" section, if any of the following conditions are true, the corresponding "m=" section in the answer MUST be marked as <del> rejected by setting the port in the "m=" line to zero, as indicated </del> <ins> rejected by setting the <port> in the "m=" line to zero, as indicated </ins> in RFC3264, and further processing for this "m=" section can be skipped:

the specific order and with the specific syntax defined in RFC4566. The "m=" line itself MUST be parsed as described in RFC4566, and the <del> media, port, proto, and fmt values stored. </del> <ins> <media>, <port>, <proto>, and <fmt> values stored. </ins> Following the "m=" line, specific processing MUST be applied for the following non-attribute lines:

Specific processing MUST also be applied for the following attribute lines: <del> If the "m=" proto value indicates use of RTP, as described in </del> <ins> If the "m=" <proto> value indicates use of RTP, as described in </ins> sec.profile-names above, the following attribute lines MUST be processed: <del> Otherwise, if the "m=" proto value indicates use of SCTP, the </del> <ins> Otherwise, if the "m=" <proto> value indicates use of SCTP, the </ins> following attribute lines MUST be processed: Other attributes that are not relevant to JSEP may also be present,
Change:
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.

Discussion:
4.1.9. <del> The canTrickleIce property indicates whether the remote side supports receiving trickled candidates.  There are three potential values: </del> <ins> The canTrickleIceCandidates property indicates whether the remote side supports receiving trickled candidates.  There are three potential values: </ins> No SDP has been received from the other side, so it is not known if it can handle trickle.  This is the initial value before

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.
Change:
Has there been any consideration of allowing a URI Template for the parameter? A particular use case would be for a collection resource that includes links from each item in the collection. If the media type supports fragments, then the item link could be templatized to point from specific locations in the representation. If we had a collection of books represented as an object with an array, and the instance media type allowed JSON Pointers: As an example of links between the full book resource and another resource, so as not to have to fetch the entire book resource if it is not needed, an author link template could be something like this (ignoring the likelihood of multiple authors): I was looking at this I-D in comparison to the (currently tabled) JSON Hyper-Schema project, and I think that anchor templates are the most notable relevant Hyper-Schema feature that is not present here. I would love to be able to use a revived Hyper-Schema as a bridge between a link-template header field and JSON-compatible data.

Discussion:
Likewise, the requirements for parameters on templated links are the same as those for a Link header field. <ins> However, the "anchor" parameter MAY contain a URI Template.  For example: Here, the link to the author for a particular book in a list of books can be found by following the link template. </ins> This specification defines additional semantics for the "var-base" parameter on templated links; see below.
Change:
"interpolate" feels very odd. Other choices would be "expanding" or "substituting". I am not picky about the exact choice, but the current terminology seems odd.
The URI Template RFC uses 'expand', so that seems most appropriate.

Discussion:
For example: indicates that a resource with the relation type <del> "https://example.org/rel/user" can be found by interpolating the </del> <ins> "https://example.org/rel/user" can be found by expanding the </ins> "username" variable into the template given. The target for the link (as defined in WEB-LINKING) is the result of

For example: indicates that a resource with the relation type <del> "https://example.org/rel/widget" can be found by interpolating the </del> <ins> "https://example.org/rel/widget" can be found by expanding the </ins> "https://example.org/vars/widget_id" variable into the template given.
Change:
Sec 11.4 recommends either separating mistrustful servers by IP, or assigning them different config rotation bits. The text is not adequate. Separating by IP address undermines the privacy value of ECHO & DoH (see the MAPRG IETF 110 talk) Any sub-IP routing has to be SNI-switched; if ECHO is operating, the load balancer must be a "client-facing server" in the ECHO architecture (draft-ietf-tls-esni Sec 3.1). Doing SNI switching as an ECHO server and then just encoding the result in the config rotation bits leaks the information they're trying to conceal. It might be worth it to fix up the "arbitrary algorithm" text to consider possible SNI switching. As we migrate towards ECHO and DoH, maybe the best we can do is give all tenants on an IP the same config and try to obscure their co-tenancy as much as possible.

Discussion:
To avoid this, the configuration agent SHOULD issue QUIC-LB configurations to mutually distrustful servers that have different <del> keys for encryption algorithms.  The load balancers can distinguish these configurations by external IP address, or by assigning different values to the config rotation bits (config-rotation).  Note that either solution has a privacy impact; see multiple-configs. These techniques are not necessary for the plaintext algorithm, as it does not attempt to conceal the server ID. </del> <ins> keys for encryption algorithms.  In many cases, the load balancers can distinguish these configurations by external IP address. However, assigning multiple entities to an IP address is complimentary with concealing DNS requests (e.g., DoH RFC8484) and the TLS Server Name Indicator (SNI) (I-D.ietf-tls-esni) to obscure the ultimate destination of traffic.  While the load balancer's fallback algorithm (fallback-algorithm) can use the SNI to make a routing decision on the first packet, there are three ways to route subsequent packets: all co-tenants can use the same QUIC-LB configuration, leaking the server mapping to each other as described above; co-tenants can be issued one of up to three configurations distinguished by the config rotation bits (config-rotation), exposing information about the target domain to the entire network; or tenants can use 4-tuple routing in their CIDs (in which case they SHOULD disable migration in their connections), which neutralizes the value of QUIC-LB but preserves privacy. When configuring QUIC-LB, administrators must evaluate the privacy tradeoff considering the relative value of each of these properties, given the trust model between tenants, the presence of methods to obscure the domain name, and value of address migration in the tenant use cases. As the plaintext algorithm makes no attempt to conceal the server mapping, these deployments SHOULD simply use a common configuration. </ins> 11.5.