jiebi/TextFlow huggingface dataset:
Original text:
The second SDP line MUST be an "o=" line, as specified in RFC4566, Section 5.2.  The value of the <username> field SHOULD be "-". <del> RFC3264 requires that the <sess-id> be representable as a 64-bit signed integer.  It is RECOMMENDED that the <sess-id> be generated as a 64-bit quantity with the high bit being sent to zero and the remaining 63 bits being cryptographically random.  The value of the <nettype> <addrtype> <unicast-address> tuple SHOULD be set to a non-meaningful address, such as IN IP4 0.0.0.0, to prevent leaking the local address in this field.  As mentioned in RFC4566, the entire o= line needs to be unique, but selecting a random number for <sess-id> is sufficient to accomplish this. </del>  The third SDP line MUST be a "s=" line, as specified in RFC4566, Section 5.3; to match the "o=" line, a single dash SHOULD be used

Reviewer comments:
Not sure this is correct yet. Have a read of text in bugs.
The fourth sentence of the second bullet of section 5.2.1 is confusing. (It starts "It is RECOMMENDED that the ".) RFC3265 requires the initial sess-id high-order bit to be zero. As written, this can be read to say that setting that bit to zero is only RECOMMENDED, and that it's possible to have sess-ids that are something other than 64 bits. You mean to say "Do what 3265 says to do and make the lower 63 bits random". Here's one possible replacement for the sentence: "RFC 3265 requires that the high-order bit of the initial be zero. It is RECOMMENDED that the remaining 63 bits be initially set to a cryptographically random value."
Yes, this is a reasonable change.
The text from 3264 is The numeric value of the session id and version in the o line MUST be representable with a 64 bit signed integer. The initial value of the version MUST be less than (262)-1, to avoid rollovers. My read of this is the two high order bits need to be zero
Is there some other SDP formatting that requires this number to be positive ?
LGTM

Revised text:
The second SDP line MUST be an "o=" line, as specified in RFC4566, Section 5.2.  The value of the <username> field SHOULD be "-".  <ins> The sess-id MUST be representable by a 64-bit signed integer, and the initial value MUST be less than (2**62)-1, as required by RFC3264.  It is RECOMMENDED that the sess-id be constructed by generating a 64-bit quantity with the two highest bits being set to zero and the remaining 62 bits being cryptographically random. The value of the <nettype> <addrtype> <unicast-address> tuple SHOULD be set to a non-meaningful address, such as IN IP4 0.0.0.0, to prevent leaking the local address in this field.  As mentioned in RFC4566, the entire o= line needs to be unique, but selecting a random number for <sess-id> is sufficient to accomplish this. </ins> The third SDP line MUST be a "s=" line, as specified in RFC4566, Section 5.3; to match the "o=" line, a single dash SHOULD be used
Original text:
used instead. When creating an IceCandidate object, JSEP implementations MUST <del> populate all of these fields. </del>  3.5.3.

Reviewer comments:
Last paragraph of 3.5.2.1 - "all of these fields" is ambiguous. Please state precisely which fields you mean.
Yeah, OK.

Revised text:
used instead. When creating an IceCandidate object, JSEP implementations MUST  <ins> populate each of the candidate, ufrag, m= section index, and MID fields.  Implementations MUST also be prepared to receive objects with some fields missing, as mentioned above. </ins> 3.5.3.
Original text:
protocol, and perform the reverse conversion on the messages it receives from the other side. <del> One way to mitigate this is to provide a JavaScript library that hides this complexity from the developer; 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, libraries exist to adapt the JSEP API into an API suitable for a SIP or XMPP.  Thus, JSEP provides greater control for the experienced developer without forcing any additional complexity on the novice developer. </del>  1.2.

Reviewer comments:
Last paragraph on page 5 - first sentence: at "One way to mitigate this" - "this" has an unclear antecedent. Did you mean "One way to reduce the complexity of the application's responsibilities"?
Agreed. Editorial

Revised text:
protocol, and perform the reverse conversion on the messages it receives from the other side.  <ins> One way to make life easier for the application is to provide a JavaScript library that hides this complexity from the developer; 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, libraries exist to adapt the JSEP API into an API suitable for a SIP or XMPP.  Thus, JSEP provides greater control for the experienced developer without forcing any additional complexity on the novice developer. </ins> 1.2.
Original text:
encoding, the limits from the attribute are then compared to the encoder resolution.  Only the specific limits mentioned below are considered; any other values, such as picture aspect ratio, MUST <del> be ignored.  Note that when considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used for the checks.  This is required regardless of whether the receiver </del>  supports performing receive-side rotation (e.g., through CVO TS26.114), as it significantly simplifies the matching logic.

Reviewer comments:
The first full bullet on page 18 has a sentence that starts "Note that when considering". Please change that to simply "When considering". As written, there is an implication that this is a consequence of something specified somewhere else.
Yes, this seems rihgt.
To help find it, the whole sentence is is Note that when considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used for the checks. This is required regardless of whether the receiver supports performing receive-side rotation (e.g., through CVO [TS26.114]), as it significantly simplifies the matching logic.

Revised text:
encoding, the limits from the attribute are then compared to the encoder resolution.  Only the specific limits mentioned below are considered; any other values, such as picture aspect ratio, MUST  <ins> be ignored.  When considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used for the checks.  This is required regardless of whether the receiver </ins> supports performing receive-side rotation (e.g., through CVO TS26.114), as it significantly simplifies the matching logic.
Original text:
Note that re-offers by JSEP implementations MUST use the correct profile strings even if the initial offer/answer exchange used an <del> (incorrect) older profile string. </del>  5.2.

Reviewer comments:
The last paragraph of 5.1 needs more context. Why woudn't you expect the re-offer to fail, given that you already know the peer is using the older profile strings? It's not clear from the email list and proceedings how the document ended up with this particular text.
Consensus on editor's call is that this is correct. Rationale is that a new offer would have failed in any case, so why complicate things.
LGTM

Revised text:
Note that re-offers by JSEP implementations MUST use the correct profile strings even if the initial offer/answer exchange used an  <ins> (incorrect) older profile string.  This simplifies JSEP behavior, with minimal downside, as any remote endpoint that fails to handle such a re-offer will also fail to handle a JSEP endpoint's initial offer. </ins> 5.2.
Original text:
resolution is 1280x720, and the attribute specified a maximum of 640x480, the expected output resolution would be 640x360.  If downscaling cannot be applied, the encoding MUST NOT be <del> transmitted, and an error SHOULD be surfaced to the application. </del>  If the encoder resolution is less than the minimum size permitted by the attribute, the encoding MUST NOT be transmitted, and an <del> error SHOULD be surfaced to the application; the encoder MUST NOT </del>  apply upscaling.  JSEP implementations SHOULD avoid this situation by allowing receipt of arbitrarily small resolutions, perhaps via fallback to a software decoder. phase.  If an ICE gathering phase has already started or completed, the 'needs-ice-restart' bit will be set.  Either way, changes to the policy have no effect on the candidate pool, <del> because pooled candidates are not surfaced to the application until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. </del>  The ICE candidate pool size MUST NOT be changed after applying a local description.  If a local description has not yet been

Reviewer comments:
The verb "surfaced" appears three times in the document without support or definition. Can you replace them with simpler language?
I don't see a reason to change this. It seems like relatively straightforward langauge.
I don't care. FWIW ... I asked a few developers what surfaced in an API meant and it did not seem a common term they used but given context they all read it the way we mean in spec..
The first two, which are about errors, will be changed to "raised" The last one, which is about candidates will be changed to "made available"
LGTM

Revised text:
resolution is 1280x720, and the attribute specified a maximum of 640x480, the expected output resolution would be 640x360.  If downscaling cannot be applied, the encoding MUST NOT be  <ins> transmitted, and an error SHOULD be raised to the application. </ins> If the encoder resolution is less than the minimum size permitted by the attribute, the encoding MUST NOT be transmitted, and an  <ins> error SHOULD be raised to the application; the encoder MUST NOT </ins> apply upscaling.  JSEP implementations SHOULD avoid this situation by allowing receipt of arbitrarily small resolutions, perhaps via fallback to a software decoder. phase.  If an ICE gathering phase has already started or completed, the 'needs-ice-restart' bit will be set.  Either way, changes to the policy have no effect on the candidate pool,  <ins> because pooled candidates are not made available to the application until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. </ins> The ICE candidate pool size MUST NOT be changed after applying a local description.  If a local description has not yet been
Original text:
Calling this method may do things such as generating new ICE credentials, but does not trigger candidate gathering or cause a media state change.  Specifically, the answer is not applied, and <del> does not become the pending local description, until </del>  setLocalDescription is called. 4.1.8.

Reviewer comments:
In 4.1.7 (create Answer) why would calling setLocalDescription cause the answer to be a pending local description. I think it's the full on local description at that point, not a pending one?
Yes, this is an error in the text.
LGTM

Revised text:
Calling this method may do things such as generating new ICE credentials, but does not trigger candidate gathering or cause a media state change.  Specifically, the answer is not applied, and  <ins> does not become the current local description, until </ins> setLocalDescription is called. 4.1.8.
Original text:
allows the signaling to set up a separate media flow for each peer that it wishes to exchange media with.  In JSEP, this offer used in the UPDATE would be formed by simply creating a new PeerConnection <del> and making sure that the same local media streams have been added into this new PeerConnection.  Then the new PeerConnection object would produce a SDP offer that could be used by the signaling to perform the UPDATE strategy discussed in RFC3960. </del>  As a result of sharing the media streams, the application will end up with N parallel PeerConnection sessions, each with a local and remote

Reviewer comments:
Build error looks like travis bustage
PeerConnection is used first at the next to last paragraph of section 3. Please add a reference at that point.
Yes.
Does Robert mean a ref to Section 4, or a ref to the W3C doc? We do have a ref to the W3C doc in Section 1.
That is why I concluded to S 4 (distinguishing between PC and RTCPC)
LGTM

Revised text:
allows the signaling to set up a separate media flow for each peer that it wishes to exchange media with.  In JSEP, this offer used in the UPDATE would be formed by simply creating a new PeerConnection  <ins> (see sec.peerconnection) and making sure that the same local media streams have been added into this new PeerConnection.  Then the new PeerConnection object would produce a SDP offer that could be used by the signaling to perform the UPDATE strategy discussed in RFC3960. </ins> As a result of sharing the media streams, the application will end up with N parallel PeerConnection sessions, each with a local and remote
Original text:
The addTrack method adds a MediaStreamTrack to the PeerConnection, using the MediaStream argument to associate the track with other tracks in the same MediaStream, so that they can be added to the same <del> "LS" group when creating an offer or answer. 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 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>  4.1.3.

Reviewer comments:
NAME PTAL at the reformulation I added.
"LS" (lipsync) is first used at 4.1.2, with no context for what it is. Please add a reference.
OK

Revised text:
The addTrack method adds a MediaStreamTrack to the PeerConnection, using the MediaStream argument to associate the track with other tracks in the same MediaStream, so that they can be added to the same  <ins> "LS" group when creating an offer or answer, thus allowing these tracks to be synchronized when played out, as described in RFC5888, Section 7.  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 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.
Original text:
5.1.2. For media m= sections, JSEP implementations MUST support the <del> "UDP/TLS/RTP/SAVPF" profile specified in RFC7850, and MUST indicate </del>  this profile for each media m= line they produce in an offer.  For data m= sections, implementations MUST support the "UDP/DTLS/SCTP" profile and MUST indicate this profile for each data m= line they <del> produce in an offer.  Because ICE can select either UDP RFC5245 or TCP RFC6544 transport depending on network conditions, this advertisement is consistent with ICE eventually selecting either either UDP or TCP. </del>  Unfortunately, in an attempt at compatibility, some endpoints generate other profile strings even when they mean to support one of

Reviewer comments:
Slightly more than minor maybe: The first paragraph of 5.1.2 has at least a reference error. UDP/TLS/RTP/SAVPF is not specified in RFC7850. It's in RFC5764. Assuming that this is only a reference error, then the last sentence seems like a stray. It doesn't seem to be in the right context ("this advertisement" doesn't cast back to the discussion of the two profiles above it, which are both UDP only). Please clarify the sentence, giving it the right context, or remove it.
This text is correct. The point is we are saying "advertise UDP but we can do TCP or UDP". We can try to rewrite.
LGTM

Revised text:
5.1.2. For media m= sections, JSEP implementations MUST support the  <ins> "UDP/TLS/RTP/SAVPF" profile specified in RFC5764, and MUST indicate </ins> this profile for each media m= line they produce in an offer.  For data m= sections, implementations MUST support the "UDP/DTLS/SCTP" profile and MUST indicate this profile for each data m= line they  <ins> produce in an offer.  Although these profiles are formally associated with UDP, ICE can select either UDP RFC5245 or TCP RFC6544 transport depending on network conditions, even when advertising a UDP profile. </ins> Unfortunately, in an attempt at compatibility, some endpoints generate other profile strings even when they mean to support one of
Original text:
resources. Calling this method may do things such as generating new ICE <del> credentials, but does not result in candidate gathering, or cause media to start or stop flowing.  Specifically, the offer is not applied, and does not become the pending local description, until setLocalDescription is called. </del>  4.1.7. description should reflect the current state of the system. Calling this method may do things such as generating new ICE <del> credentials, but does not trigger candidate gathering or cause a media state change.  Specifically, the answer is not applied, and does not become the current local description, until setLocalDescription is called. </del>  4.1.8.

Reviewer comments:
Odd edge: The description createAnswer (in 4.1.7) leaves open the possibility that the application could call createAnswer twice (back-to-back with no intervening calls to other APIs) with different values in the options parameter. Is this ok? If not, should there be language that says not to do that somewhere?
This is explicitly OK, and the state machine makes it clear.
Not sure we need to say anything here, though, given the state machine.
NAME I forgot to mark this invalid but I think it may be.
Discussed with team and plan is to amend the paras that talk about cO/cA not changing media state to also mention that they don't change signaling state.
LGTM

Revised text:
resources. Calling this method may do things such as generating new ICE  <ins> credentials, but does not change the PeerConnection state, trigger candidate gathering, or cause media to start or stop flowing. Specifically, the offer is not applied, and does not become the pending local description, until setLocalDescription is called. </ins> 4.1.7. description should reflect the current state of the system. Calling this method may do things such as generating new ICE  <ins> credentials, but does not change the PeerConnection state, trigger candidate gathering, or or cause a media state change.  Specifically, the answer is not applied, and does not become the current local description, until setLocalDescription is called. </ins> 4.1.8.
Original text:
answerer, who first calls setRemoteDescription(sdp [offer]) and then later setLocalDescription(sdp [answer]).  JSEP also allows for an answer to be treated as provisional by the application.  Provisional answers provide a way for an answerer to communicate initial session parameters back to the offerer, in order

Reviewer comments:
NAME PTAL
The concept of a "pending local description" is used in sections 3.5.1, , and 4.1.7 but isn't really explained until much later in the document. Please provide forward references, or move a description of what a pending description is earlier in the document.
Yah, this does seem like it needs a fix. Probably something about this in S 3.2.
The second paragraph of section 5.4 is confusing. A slight restructuring of the sentences would remove much of the potential confusion, I think. I suggest replacing the first sentence (which is very complex) with this: "After calling setLocalDescription, the application MAY modify the SDP to reduce the capabilities in the offer before sending it to the far side, as long as it remains a valid SDP offer and specifies a subset of what was in the original offer. Likewise, an application that has received an offer from a peer MAY modify the received SDP, subject to those same constraints, before calling setRemoteDescription."
LGTMLG with nits

Revised text:
answerer, who first calls setRemoteDescription(sdp [offer]) and then later setLocalDescription(sdp [answer]). <ins> During the offer/answer exchange, the outstanding offer is considered to be "pending" at the offerer and the answerer, as it may either be accepted or rejected.  If this is a re-offer, each side will also have "current" local and remote descriptions, which reflect the result of the last offer/answer exchange.  Sections sec.pendingLocalDescription, sec.pendingRemoteDescription, sec.currentLocalDescription, and sec.currentRemoteDescription, provide more detail on pending and current descriptions. </ins> JSEP also allows for an answer to be treated as provisional by the application.  Provisional answers provide a way for an answerer to communicate initial session parameters back to the offerer, in order
Original text:
the SDP is needed, the aforementioned createOffer/createAnswer options or RtpTransceiver APIs MUST be used. <del> Note that the application MAY modify the SDP to reduce the capabilities in the offer it sends to the far side (post- setLocalDescription) or the offer that it installs from the far side (pre-setRemoteDescription), as long as it remains a valid SDP offer and specifies a subset of what was in the original offer.  This is safe because the answer is not permitted to expand capabilities, and therefore will just respond to what is present in the offer. The application SHOULD NOT modify the SDP in the answer it transmits, as the answer contains the negotiated capabilities, and this can cause the two sides to have different ideas about what exactly was negotiated. </del>  As always, the application is solely responsible for what it sends to the other party, and all incoming SDP will be processed by the JSEP

Reviewer comments:
But also clarify that this can be used to modify an offer OR answer, as long as it remains a legal JSEP o/a.
The second paragraph of section 5.4 is confusing. A slight restructuring of the sentences would remove much of the potential confusion, I think. I suggest replacing the first sentence (which is very complex) with this: "After calling setLocalDescription, the application MAY modify the SDP to reduce the capabilities in the offer before sending it to the far side, as long as it remains a valid SDP offer and specifies a subset of what was in the original offer. Likewise, an application that has received an offer from a peer MAY modify the received SDP, subject to those same constraints, before calling setRemoteDescription."
lgtm

Revised text:
the SDP is needed, the aforementioned createOffer/createAnswer options or RtpTransceiver APIs MUST be used.  <ins> After calling setLocalDescription with an offer or answer, the application MAY modify the SDP to reduce its capabilities before sending it to the far side, as long as it follows the rules above that define a valid JSEP offer or answer.  Likewise, an application that has received an offer or answer from a peer MAY modify the received SDP, subject to the same constraints, before calling setRemoteDescription. </ins> As always, the application is solely responsible for what it sends to the other party, and all incoming SDP will be processed by the JSEP