jiebi/TextFlow huggingface dataset:
Original text:
1.3. <del> When [RFC8829] was published, an inconsistency regarding BUNDLE RFC8843 operation was identified concerning both the specification text as well as implementation behavior.  The former concern was addressed via an update to RFC8843.  For the latter concern, it was observed that some implementations implemented the "max-bundle" bundle policy by assuming that bundling had already been negotiated, rather than marking "m=" sections as bundle-only as indicated by RFC8829.  In order to prevent unexpected changes to applications relying on the pre-standard behavior, the decision was made to deprecate the use of "max-bundle" and instead introduce a new "must- bundle" policy that, when selected, provides the correct behavior. </del>  2. MUST contain all "m=" sections that were previously bundled, as long as they are still alive, as well as any new "m=" sections.  "a=group:LS" attributes are generated in the same way as for initial offers, with the additional stipulation that any lip sync groups that were present in the most recent answer MUST continue to exist and

Reviewer comments:
This includes the changes requested at IETF 111 (summarized in URL), which are: modified text in S 1.3 (requested by NAME to spell out that "must-bundle" is the behavior formerly known as "max-bundle" added brief discussion of interaction of BUNDLE and TPCC (requested by NAME
FYI NAME
LGTM.
Should we add a reference to rfc8843bis? The rest looks good.
LGTMLGTM

Revised text:
1.3.  <ins> When RFC8829 was published, inconsistencies regarding BUNDLE RFC8843 operation were identified with regard to both the specification text as well as implementation behavior.  The former concern was addressed via an update to RFC8843.  For the latter concern, it was observed that some implementations implemented the "max-bundle" bundle policy defined in RFC8829 by assuming that bundling had already been negotiated, rather than marking "m=" sections as bundle-only as indicated by the specification.  In order to prevent unexpected changes to applications relying on the pre-standard behavior, the decision was made to deprecate "max-bundle" and instead introduce an identically defined "must-bundle" policy that, when selected, provides the behavior originally specified by RFC8829. </ins> 2. MUST contain all "m=" sections that were previously bundled, as long as they are still alive, as well as any new "m=" sections. <ins> Note that if bundling has been negotiated, unbundling is no longer possible, and media sections will not be marked as bundle-only.  This is by design, but could cause issues in the rare case of sending a subsequent offer as an initial offer to a non-bundle-aware endpoint via Third Party Call Control (3PCC). </ins> "a=group:LS" attributes are generated in the same way as for initial offers, with the additional stipulation that any lip sync groups that were present in the most recent answer MUST continue to exist and
Original text:
3.1. JSEP does not specify a particular signaling model or state machine, <del> other than the generic need to exchange SDP media descriptions in the </del>  fashion described by RFC3264 (offer/answer) in order for both sides of the session to know how to conduct the session.  JSEP provides mechanisms to create offers and answers, as well as to apply them to Changes MUST NOT be silently ignored. <del> The following elements of the SDP media description MUST NOT be changed between the createOffer and the setLocalDescription (or between the createAnswer and the setLocalDescription), since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </del>  The number, type and port number of m= lines.

Reviewer comments:
LGTM!
JSEP on two occasions says "SDP media description" where it seems "SDP session description" or similar would be more appropriate. "media description" seem to reference m-lines rather than the full SDP in other documents (4566, 3264).
agree - see if that pull request fixes it
to my understanding it does fix it!

Revised text:
3.1. JSEP does not specify a particular signaling model or state machine,  <ins> other than the generic need to exchange session descriptions in the </ins> fashion described by RFC3264 (offer/answer) in order for both sides of the session to know how to conduct the session.  JSEP provides mechanisms to create offers and answers, as well as to apply them to Changes MUST NOT be silently ignored.  <ins> The following elements of the session description MUST NOT be changed between the createOffer and the setLocalDescription (or between the createAnswer and the setLocalDescription), since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </ins> The number, type and port number of m= lines.
Original text:
the offer-answer exchange should be considered complete, and any resources (decoders, candidates) that are no longer needed can be released.  A description used as an "answer" may be applied as a <del> response to a "offer", or an update to a previously sent "pranswer". </del>  The only difference between a provisional and final answer is that the final answer results in the freeing of any unused resources that 4.1.5. The setLocalDescription method instructs the PeerConnection to apply <del> the supplied SDP blob as its local configuration.  The type field indicates whether the blob should be processed as an offer, provisional answer, or final answer; offers and answers are checked differently, using the various rules that exist for each SDP line. </del>  This API changes the local media state; among other things, it sets up local resources for receiving and decoding media.  In order to 4.1.6. The setRemoteDescription method instructs the PeerConnection to apply <del> the supplied SDP blob as the desired remote configuration.  As in setLocalDescription, the type field of the indicates how the blob should be processed. </del>  This API changes the local media state; among other things, it sets up local resources for sending and encoding media.

Reviewer comments:
lgtm
need to be to "an" like in line 854?? URL
Fixed by
The word Blob is missing? URL

Revised text:
the offer-answer exchange should be considered complete, and any resources (decoders, candidates) that are no longer needed can be released.  A description used as an "answer" may be applied as a  <ins> response to an "offer", or an update to a previously sent "pranswer". </ins> The only difference between a provisional and final answer is that the final answer results in the freeing of any unused resources that 4.1.5. The setLocalDescription method instructs the PeerConnection to apply  <ins> the supplied session description as its local configuration.  The type field indicates whether the description should be processed as an offer, provisional answer, or final answer; offers and answers are checked differently, using the various rules that exist for each SDP line. </ins> This API changes the local media state; among other things, it sets up local resources for receiving and decoding media.  In order to 4.1.6. The setRemoteDescription method instructs the PeerConnection to apply  <ins> the supplied session description as the desired remote configuration. As in setLocalDescription, the type field of the description indicates how it should be processed. </ins> This API changes the local media state; among other things, it sets up local resources for sending and encoding media.
Original text:
offer "a=rtcp-mux", thus allowing for compatibility with either multiplexing or non-multiplexing endpoints. <del> The browser will only gather RTP candidates.  [[OPEN ISSUE: how should the answerer behave.  https://github.com/rtcweb-wg/jsep/ issues/114]] This halves the number of candidates that the offerer needs to gather. </del>  4.1.2.

Reviewer comments:
...14
LGTM
Cullen thinks it should accept and non-mux. EKR and Justin currently believe it should reject the offer.
Original text: when acting as answerer will reject any m= section that does not provide an "a=rtcp-mux" attribute.
LGTM at IETF 92
open issue in text to be removed

Revised text:
offer "a=rtcp-mux", thus allowing for compatibility with either multiplexing or non-multiplexing endpoints.  <ins> The browser will only gather RTP candidates.  This halves the number of candidates that the offerer needs to gather.  When acting as answerer, the browser will reject any m= section that does not provide an "a=rtcp-mux" attribute. </ins> 4.1.2.
Original text:
MediaStreamTrack.  For the answerer, these mandatory constraints can be applied to the remote MediaStreamTracks that are created by a setRemoteDescription call, and will affect the output of the ensuing <del> createAnswer call.  For the offerer, since it does not know about any remote MediaStreamTracks until it receives theanswer, this implies that it can only set these constraints after the initial offer-answer exchange is complete, and as a result, a new offer-answer is needed to communicate them. </del>  The resulting resolution space formed by intersecting the decoder hard limits with any mandatory constraints will be used as the x= and

Reviewer comments:
LGTM - I think that makes it clear what can and can not work.
lgtm

Revised text:
MediaStreamTrack.  For the answerer, these mandatory constraints can be applied to the remote MediaStreamTracks that are created by a setRemoteDescription call, and will affect the output of the ensuing  <ins> createAnswer call.  Any constraints set after setLocalDescription is used to set the answer will result in a new offer-answer exchange. For the offerer, because it does not know about any remote MediaStreamTracks until it receives the answer, the offer can only reflect decoder hard limits.  If the offerer wishes to set mandatory constraints on video resolution, it must do so after receiving the answer and the result will be a new offer-answer to communicate them. </ins> The resulting resolution space formed by intersecting the decoder hard limits with any mandatory constraints will be used as the x= and
Original text:
maximum supported frame sizes out of all codecs included above, as specified in RFC4566, Section 6. <del> If this m= section is for video media, an "a=imageattr" line, as specified in sec.imageattr. </del>  For each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate

Reviewer comments:
LGTM
G. Section 5.2.1: This section contains the following: Each m= section MUST include the following attribute lines: o If this m= section is for video media, an "a=imageattr" line, as specified in Section 3.6. But, Section 3.6 does not mandate that a=imageattr always is included. Thus the text must be modified to allow the selective inclusion of the attribute based on what needs to be said.
Agreed; although 3.6 allows it to be omitted, we should update the text in 5.2.1 to avoid confusion.

Revised text:
maximum supported frame sizes out of all codecs included above, as specified in RFC4566, Section 6.  <ins> If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in sec.imageattr. </ins> For each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate
Original text:
"RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]" Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no <del> effect; support for DTLS-SRTP is determined by the presence of the "a=fingerprint" attribute.  Note that lack of an "a=fingerprint" attribute will lead to negotiation failure. </del>  The use of AVPF or AVP simply controls the timing rules used for RTCP feedback.  If AVPF is provided, or an "a=rtcp-fb" attribute An "a=ice-options" line, with the "trickle" option, as specified in I-D.ietf-mmusic-trickle-ice, Section 4. <del> An "a=fingerprint" line, as specified in RFC4572, Section 5; the algorithm used for the fingerprint MUST match that used in the certificate signature. </del>  An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5. options" line, with the "trickle" option, as specified in I- D.ietf-mmusic-trickle-ice, Section 4. <del> An "a=fingerprint" line, as specified in RFC4572, Section 5; the algorithm used for the fingerprint MUST match that used in the certificate signature. </del>  An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.

Reviewer comments:
LGTM
lgtm
In URL 'certificates' is a set, and the PeerConnection selects which certificate to use. The SDP should have one 'a=fingerprint' line per certificate, and that is not reflected in the JSEP draft AFAICU.
Prague: One a=fingerprint line per cert, but we can go down to a single cert one DTLS has been established. The DTLS cert has to match one of the supplied a=fingerprints. (NAME correct as necessary)
PR added for allowing multiples. Processing rules go in the TBD applying section

Revised text:
"RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]" Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no  <ins> effect; support for DTLS-SRTP is determined by the presence of one or more "a=fingerprint" attribute.  Note that lack of an "a=fingerprint" attribute will lead to negotiation failure. </ins> The use of AVPF or AVP simply controls the timing rules used for RTCP feedback.  If AVPF is provided, or an "a=rtcp-fb" attribute An "a=ice-options" line, with the "trickle" option, as specified in I-D.ietf-mmusic-trickle-ice, Section 4.  <ins> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. </ins> An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5. options" line, with the "trickle" option, as specified in I- D.ietf-mmusic-trickle-ice, Section 4.  <ins> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. </ins> An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.
Original text:
in the attribute, and transmit it untouched if so.  If the original resolution is too large for the attribute criteria, the sender SHOULD apply downscaling to the output of the MediaStreamTrack in order to <del> satisfy the criteria.  In rare cases, where a receiver requires a minimum resolution which is greater than the native resolution of the video, the sender SHOULD apply upscaling in order to provide that resolution.  The sender SHOULD NOT apply upscaling in any other cases. If there is no appropriate scaling mechanism that allows the received criteria to be satisfied, the sender MUST NOT transmit the track. </del>  In the special case of receiving a maximum resolution of [0, 0], as described above, the sender MUST NOT transmit the track.

Reviewer comments:
LGTM with the change indicated above.
I rearranged the text a bit to make the policy concept more clear. PTAL.
LGTM
LGTM
For example, some decoders may have min limits, expressed in imageattr. By default, upscaling can be used for this, but there should be some control to turn this off (e.g. don't want to send "HD" video that is just upscaled to HD)
Thoughts on if default should be upscale is allowed or not allowed ?
Generally it seems like a bad practice so I would default to not.

Revised text:
in the attribute, and transmit it untouched if so.  If the original resolution is too large for the attribute criteria, the sender SHOULD apply downscaling to the output of the MediaStreamTrack in order to  <ins> satisfy the criteria. If the receiver requires a minimum resolution which is greater than the native resolution of the video, upscaling is needed, but this may not be appropriate in all cases.  To address this concern, the application can set an upscaling policy for each sent track.  For this case, if upscaling is permitted by policy, the sender SHOULD apply upscaling in order to provide the desired resolution. Otherwise, the sender MUST NOT apply upscaling.  The sender SHOULD NOT upscale in other cases, even if the policy permits it. If there is no appropriate and permitted scaling mechanism that allows the received criteria to be satisfied, the sender MUST NOT transmit the track. </ins> In the special case of receiving a maximum resolution of [0, 0], as described above, the sender MUST NOT transmit the track.
Original text:
BUNDLEd must use unique ICE credentials and candidates.  Each m= section MUST include the following: <del> If present in the offer, an "a=mid" line, as specified in RFC5888, Section 9.1.  The "mid" value MUST match that specified in the offer. </del>  An "a=rtcp" line, as specified in RFC3605, Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet

Reviewer comments:
It goes something like and so on. But it is not clear if the answer can contain an line if there was none in the offer.
Quoth RFC 5888: Mid Value in Answers The "mid" attribute is an identifier for a particular media stream. Therefore, the "mid" value in the offer MUST be the same as the "mid" value in the answer. Besides, subsequent offers (e.g., in a re-INVITE) SHOULD use the same "mid" value for the already existing media streams. So the answer seems to be "no"
Given the quote from 5888, is it fair to conclude that URL should be resolved with "null" for the mid property on the transceiver if there has been no mid in the SDP? .mid was just an example, the same text is present for e.g. rtcp-mux, ice-option:trickle, rtcp-size.

Revised text:
BUNDLEd must use unique ICE credentials and candidates.  Each m= section MUST include the following:  <ins> If and only if present in the offer, an "a=mid" line, as specified in RFC5888, Section 9.1.  The "mid" value MUST match that specified in the offer. </ins> An "a=rtcp" line, as specified in RFC3605, Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet
Original text:
little location information as possible (note that these choices come with corresponding operational costs).  To accomplish this, the browser MUST allow the application to restrict which ICE candidates <del> are used in a session.  In addition, administrators may also wish to control the set of ICE candidates, and so the browser SHOULD also allow control via local policy, with the most restrictive policy prevailing. </del>  There may also be cases where the application wants to change which types of candidates are used while the session is active.  A prime the application deploys its relay servers, this could obfuscate location to a metro or possibly even global level. <del> Although it can be overridden by local policy, the default ICE candidate policy MUST be set to allow all candidates, as this minimizes use of application STUN/TURN server resources. </del>  If a size is specified for the ICE candidate pool, this indicates the number of ICE components to pre-gather candidates for.  Because pre-

Reviewer comments:
Not sure if this is done but what is there LGTM
Yes, I think this is complete.
LGTM
URL talks about browser local policy. It should make this more concrete by referring to URL as the source of this policy.
Do you see it as normatively depending on that or more just "useful implementor advice can be found in ..."
I guess it depends on what we think the purpose of the ip-handling draft is. If we think all browsers should implement this, then it should be a normative dependency. I'll make a PR as such and we can debate the details there.
I think if it is something all browser need to implement, then we probably just want to move the normative text into this draft.
I think there is enough text that it warrants being in its own document.

Revised text:
little location information as possible (note that these choices come with corresponding operational costs).  To accomplish this, the browser MUST allow the application to restrict which ICE candidates  <ins> are used in a session.  Note that this filtering is applied on top of any restrictions the browser chooses to enforce regarding which IP addresses are permitted for the application, as discussed in I- D.shieh-rtcweb-ip-handling. </ins> There may also be cases where the application wants to change which types of candidates are used while the session is active.  A prime the application deploys its relay servers, this could obfuscate location to a metro or possibly even global level.  <ins> The default ICE candidate policy MUST be set to allow all candidates, as this is generally the desired policy, and also typically reduces use of application TURN server resources significantly. </ins> If a size is specified for the ICE candidate pool, this indicates the number of ICE components to pre-gather candidates for.  Because pre-
Original text:
If an ICE candidate policy is specified, it functions as described in sec.ice-candidate-policy, causing the browser to only surface the <del> permitted candidates to the application, and only use those candidates for connectivity checks.  The set of available policies is as follows: </del>  <del> All candidates will be gathered and used. Candidates with private IP addresses [RFC1918] will be filtered out.  This prevents exposure of internal network details, at the cost of requiring relay usage even for intranet calls, if the NAT does not allow hairpinning as described in [RFC4787], section 6. </del>  the application deploys its relay servers, this could obfuscate location to a metro or possibly even global level. <del> The default ICE candidate policy MUST be set to allow all candidates, as this is generally the desired policy, and also typically reduces use of application TURN server resources significantly. </del>  If a size is specified for the ICE candidate pool, this indicates the number of ICE components to pre-gather candidates for.  Because pre-

Reviewer comments:
LGTM
lgtm
From URL "public" is probably something the browser should control, not the application. "none" was previously removed, but apparently Firefox has implemented it.
Keep in mind that anything less than all means that mobile apps will work better than browser apps. Public tries to just reveal what is already revealed simply by browsing the web with no webrtc.
Right, but that's what "all" does when the browser is configured as recommended by draft-rtcweb-shieh-ip-handling. It's not clear why a "public" mode also needs to exist; the point of this draft is to protect the user from the application, so we can't really give the app the ability to choose whether it wants non-public addresses. I think the real remaining question is whether "none" is worth keeping.
I think the motivation for "none" was a lot stronger when we had automatic gathering prior to setLD() in some situations. Now, it seems like you can just get the same effect by deferring setLD(). I agree that "public" is silly.

Revised text:
If an ICE candidate policy is specified, it functions as described in sec.ice-candidate-policy, causing the browser to only surface the  <ins> permitted candidates (including any internal browser filtering) to the application, and only use those candidates for connectivity checks.  The set of available policies is as follows: </ins>  <ins> All candidates permitted by browser policy will be gathered and used. </ins> the application deploys its relay servers, this could obfuscate location to a metro or possibly even global level.  <ins> The default ICE candidate policy MUST be set to "all" as this is generally the desired policy, and also typically reduces use of application TURN server resources significantly. </ins> If a size is specified for the ICE candidate pool, this indicates the number of ICE components to pre-gather candidates for.  Because pre-