jiebi/TextFlow huggingface dataset:
Original text:
If present, a single "a=dtls-id" line is parsed as specified in I- D.ietf-mmusic-dtls-sdp Section 5, and the dtls-id value is stored.  Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored.

Reviewer comments:
I fixed the grammar and added some text about "subsequent verification"
Also see URL
What's the issue?
Someone thought we should talk about how to parse SDP with more than one identity line and handle that. I did not look, we may already have whatever we need in the draft but I just opened this so we would at least go check.
JSEP practice is just to put in placeholders and link to the defining draft, so we should punt the actual semantics in security-arch.
See email to rtcweb from Stefan Håkansson subject "Identity in the SDP"
Sayeth Stefan: >[2] URL

Revised text:
If present, a single "a=dtls-id" line is parsed as specified in I- D.ietf-mmusic-dtls-sdp Section 5, and the dtls-id value is stored. <ins> Any "a=identity" lines are parsed and the identity values stored for subsequent verification, as specified I-D.ietf-rtcweb- security-arch, Section 5. </ins> Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored.
Original text:
appropriate).  Note that when considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used.  This is required regardless of whether the receiver supports performing <del> receive-side rotation (e.g., through CVO), as it significantly simplifies the matching logic. </del>  For the purposes of resolution negotiation, only size limits are considered.  Any other values, e.g. picture or sample aspect ratio,

Reviewer comments:
Note that the use of CVO in webrtc is described in URL
NAME feel free to rewrite however and merge. I just wanted to get the xref in.
We mention it in the imageattr section. This is required regardless of whether the receiver supports performing receive-side rotation (e.g., through CVO), as it significantly simplifies the matching logic.
NAME , can you look into this? Not WGLC2 blocking.
will do - I seem to recall it is a 3GPP ref but will try and track down.

Revised text:
appropriate).  Note that when considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used.  This is required regardless of whether the receiver supports performing  <ins> receive-side rotation (e.g., through CVO TS26.114), as it significantly simplifies the matching logic. </ins> For the purposes of resolution negotiation, only size limits are considered.  Any other values, e.g. picture or sample aspect ratio,
Original text:
mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription() API. <del> When the call is accepted, the callee uses the createAnswer() API to generate an appropriate answer, applies it using setLocalDescription(), and sends the answer back to the initiator over the signaling channel.  When the offerer gets that answer, it installs it using setRemoteDescription(), and initial setup is complete.  This process can be repeated for additional offer/answer exchanges. </del>  Regarding ICE RFC5245, JSEP decouples the ICE state machine from the overall signaling state machine, as the ICE state machine must remain

Reviewer comments:
I was reading this draft and noticed a couple of minor wording issues that made the text not as clear as it could be. I don't believe the changes are controversial, or change the intention of the draft.
These changes look good - I agree the rewrite of the offer/answer paragraph is a nice improvement.
Looks fine to me

Revised text:
mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription() API.  <ins> To complete the offer/answer exchange, the remote party uses the createAnswer() API to generate an appropriate answer, applies it using the setLocalDescription() API, and sends the answer back to the initiator over the signaling channel.  When the initiator gets that answer, it installs it using the setRemoteDescription() API, and initial setup is complete.  This process can be repeated for additional offer/answer exchanges. </ins> Regarding ICE RFC5245, JSEP decouples the ICE state machine from the overall signaling state machine, as the ICE state machine must remain
Original text:
The basic operations that the applications can have the media engine do are: <del> Start exchanging media to a given remote peer, but keep all the </del>  resources reserved in the offer. Start exchanging media with a given remote peer, and free any

Reviewer comments:
I was reading this draft and noticed a couple of minor wording issues that made the text not as clear as it could be. I don't believe the changes are controversial, or change the intention of the draft.
These changes look good - I agree the rewrite of the offer/answer paragraph is a nice improvement.
Looks fine to me

Revised text:
The basic operations that the applications can have the media engine do are:  <ins> Start exchanging media with a given remote peer, but keep all the </ins> resources reserved in the offer. Start exchanging media with a given remote peer, and free any
Original text:
4.1.4. Session description objects (RTCSessionDescription) may be of type <del> "offer", "pranswer", and "answer".  These types provide information as to how the description parameter should be parsed, and how the media state should be changed. </del>  "offer" indicates that a description should be parsed as an offer; said description may include many possible media configurations.  A

Reviewer comments:
I was reading this draft and noticed a couple of minor wording issues that made the text not as clear as it could be. I don't believe the changes are controversial, or change the intention of the draft.
These changes look good - I agree the rewrite of the offer/answer paragraph is a nice improvement.
Looks fine to me

Revised text:
4.1.4. Session description objects (RTCSessionDescription) may be of type  <ins> "offer", "pranswer", or "answer".  These types provide information as to how the description parameter should be parsed, and how the media state should be changed. </ins> "offer" indicates that a description should be parsed as an offer; said description may include many possible media configurations.  A
Original text:
This API changes the local media state; among other things, it sets up local resources for sending and encoding media. <del> If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final), </del>  and the media directions are compatible, and media are available to send, this will result in the starting of media transmission.

Reviewer comments:
I was reading this draft and noticed a couple of minor wording issues that made the text not as clear as it could be. I don't believe the changes are controversial, or change the intention of the draft.
These changes look good - I agree the rewrite of the offer/answer paragraph is a nice improvement.
Looks fine to me

Revised text:
This API changes the local media state; among other things, it sets up local resources for sending and encoding media.  <ins> If setLocalDescription was previously called with an offer, and setRemoteDescription is called with an answer (provisional or final), </ins> and the media directions are compatible, and media are available to send, this will result in the starting of media transmission.
Original text:
"a=rid" lines. Each m= section is also checked to ensure prohibited features are <del> not used.  If this is a local description, the "ice-lite" attribute MUST NOT be specified. </del>  If the RTP/RTCP multiplexing policy is "require", each m= section MUST contain an "a=rtcp-mux" attribute.  If an "m=" section

Reviewer comments:
Page 62 has a bullet ending "If this is a local description, the 'ice-lite' attribute MUST NOT be specified." This sentence is leftover from before SDP munging was prohibited and should be removed.

Revised text:
"a=rid" lines. Each m= section is also checked to ensure prohibited features are  <ins> not used. </ins> If the RTP/RTCP multiplexing policy is "require", each m= section MUST contain an "a=rtcp-mux" attribute.  If an "m=" section
Original text:
have to keep pace with the changes to SDP, at least until the time that this new encoding eclipsed SDP in popularity. <del> However, to simplify Javascript processing, and provide for future flexibility, the SDP syntax is encapsulated within a SessionDescription object, which can be constructed from SDP, and be serialized out to SDP.  If future specifications agree on a JSON format for session descriptions, we could easily enable this object to generate and consume that JSON. Other methods may be added to SessionDescription in the future to simplify handling of SessionDescriptions from Javascript.  In the meantime, Javascript libraries can be used to perform these manipulations. Note that most applications should be able to treat the </del>  SessionDescriptions produced and consumed by these various API calls as opaque blobs; that is, the application will not need to read or change them.

Reviewer comments:
Section 3.3, paragraph 3 is an example of text that should have been removed with SDP munging. Please remove it.
Munging remote SDP is still allowed, but I agree that we don't need to get into the mechanics of how to do it. Agree this para should be removed, and the last para reworked accordingly.

Revised text:
have to keep pace with the changes to SDP, at least until the time that this new encoding eclipsed SDP in popularity.  <ins> However, to provide for future flexibility, the SDP syntax is encapsulated within a SessionDescription object, which can be constructed from SDP, and be serialized out to SDP.  If future specifications agree on a JSON format for session descriptions, we could easily enable this object to generate and consume that JSON. As detailed below, most applications should be able to treat the </ins> SessionDescriptions produced and consumed by these various API calls as opaque blobs; that is, the application will not need to read or change them.
Original text:
If the m= section proto value indicates use of RTP: <del> If there is no RtpTransceiver associated with this m= section (which will only happen when applying an offer), find one and associate it with this m= section according to the following steps: </del>  Find the RtpTransceiver that corresponds to this m= section, using the mapping between transceivers and m= section

Reviewer comments:
Fixes URL
See comment in
Alright, try this version
Section 5.8 contains the sentence: "If there is no RtpTransceiver associated with this m= section (which will only happen when applying an offer)..." -- it is grammatically ambiguous whether this says that the absence of an RtpTranceiver can only happen with an offer, or if the presence of an RtpTranceiver can only happen with an offer. Suggest rephrasing as: "If applying an offer and there is no RtpTransceiver associated with this m= section, find one..."
NAME can you take a look at this?
I'm not sold on this approach, since it then invites the question, what should one do if this condition happens when applying an answer? My suggestion would be to still call this out explicitly, but try to avoid the ambiguity noted above by changing the parenthetical to its own sentence at the end of the paragraph, e.g. "Note that this situation will only occur when applying an offer."
I changed it to that.
LGTM

Revised text:
If the m= section proto value indicates use of RTP:  <ins> If there is no RtpTransceiver associated with this m= section, find one and associate it with this m= section according to the following steps.  Note that this situation will only occur when applying an offer. </ins> Find the RtpTransceiver that corresponds to this m= section, using the mapping between transceivers and m= section
Original text:
use the "a=imageattr" SDP attribute RFC6236 to indicate what video frame sizes it is capable of receiving.  A receiver may have hard limits on what its video decoder can process, or it may have some <del> maximum set by policy. </del>  Note that certain codecs support transmission of samples with aspect ratios other than 1.0 (i.e., non-square pixels).  JSEP

Reviewer comments:
Section 3.6.2 would ideally include a disclaimer, like we have for many other features, indicating that -- despite normative statements in this section -- the remote side might not honor imageattr because of legacy behavior, and that implementations MUST be prepared to handle such situations.
Sure. This should probably go into 3.6 or 3.6.1, since those govern sent imageattr attribs.
LGTM

Revised text:
use the "a=imageattr" SDP attribute RFC6236 to indicate what video frame sizes it is capable of receiving.  A receiver may have hard limits on what its video decoder can process, or it may have some  <ins> maximum set by policy.  By specifying these limits in an "a=imageattr" attribute, JSEP endpoints can attempt to ensure that the remote sender transmits video at an acceptable resolution. However, when communicating with a non-JSEP endpoint that does not understand this attribute, any signaled limits may be exceeded, and the JSEP implementation MUST handle this gracefully, e.g., by discarding the video. </ins> Note that certain codecs support transmission of samples with aspect ratios other than 1.0 (i.e., non-square pixels).  JSEP
Original text:
hardware decoder capababilities, local policy) to determine the absolute minimum and maximum sizes it can receive.  If there are no known local limits, the "a=imageattr" attribute SHOULD be omitted.  Otherwise, an "a=imageattr" attribute is created with "recv" direction, and the resulting resolution space formed from the aforementioned intersection is used to specify its minimum and <del> maximum x= and y= values.  If the intersection is the null set, i.e., the degenerate case of no permitted resolutions, this MUST be represented by x=0 and y=0 values. </del>  The rules here express a single set of preferences, and therefore, the "a=imageattr" q= value is not important.  It SHOULD be set to

Reviewer comments:
This seems like a normative change. I'm not saying I'm against this, but what's the rationale?
Adam's argument in , which I found to be convincing.

Revised text:
hardware decoder capababilities, local policy) to determine the absolute minimum and maximum sizes it can receive.  If there are no known local limits, the "a=imageattr" attribute SHOULD be omitted. <ins> If these local limits preclude receiving any video, i.e., the degenerate case of no permitted resolutions, the "a=imageattr" attribute MUST be omitted, and the m= section MUST be marked as sendonly/inactive, as appropriate. </ins> Otherwise, an "a=imageattr" attribute is created with "recv" direction, and the resulting resolution space formed from the aforementioned intersection is used to specify its minimum and  <ins> maximum x= and y= values. </ins> The rules here express a single set of preferences, and therefore, the "a=imageattr" q= value is not important.  It SHOULD be set to
Original text:
by allowing receipt of arbitrarily small resolutions, perhaps via fallback to a software decoder. <del> In the special case of a maximum resolution of [0, 0], as described above, the sender MUST NOT transmit the encoding. </del> 3.7. JSEP supports simulcast transmission of a MediaStreamTrack, where

Reviewer comments:
This seems like a normative change. I'm not saying I'm against this, but what's the rationale?
Adam's argument in , which I found to be convincing.

Revised text:
by allowing receipt of arbitrarily small resolutions, perhaps via fallback to a software decoder.  3.7. JSEP supports simulcast transmission of a MediaStreamTrack, where
Original text:
guarantee that applications do so.  The JSEP implementation MUST be prepared for the JS to pass in bogus data instead. <del> Conversely, the application programmer MUST recognize that the JS </del>  does not have complete control of endpoint behavior.  One case that bears particular mention is that editing ICE candidates out of the SDP or suppressing trickled candidates does not have the expected

Reviewer comments:
In the last paragraph of section 8 at "programmer MUST recognize". That is not an appropriate use of 2119. I suggest "needs to be aware" instead of "MUST recognize".
This seems right

Revised text:
guarantee that applications do so.  The JSEP implementation MUST be prepared for the JS to pass in bogus data instead.  <ins> Conversely, the application programmer needs to be aware that the JS </ins> does not have complete control of endpoint behavior.  One case that bears particular mention is that editing ICE candidates out of the SDP or suppressing trickled candidates does not have the expected
Original text:
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 <del> directly.  This was rejected based on a feeling that requiring </del>  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

Reviewer comments:
Section 1.2 second paragraph - "This was rejected based on a feeling". Can you write something that speaks to consensus here? "Based on a feeling" isn't quite right. Maybe "using the argument"?
Sure.
LGTM

Revised text:
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  <ins> directly.  This was rejected based on the argument that requiring </ins> 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
Original text:
of codecs sent to a remote party indicates what the local side is willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send. <del> However, not all parameters follow this rule; for example, the fingerprints RFC8122 sent to a remote party are calculated based on the local certificate(s) offered; the remote party MUST either accept these parameters or reject them altogether, with no option to choose different values. </del>  In addition, various RFCs put different conditions on the format of offers versus answers.  For example, an offer may propose an

Reviewer comments:
Second paragraph of 3.2, last sentence: at "these parameters or reject them" - "these" and "them" have ambiguous antecedents. It's not clear if you are trying to point to the parameters that don't follow the earlier stated rule, or all parameters. The sentence is complex. Splitting it up and finding a way to avoid the need for the semicolon will likely make it easier to say what you mean.
I agree that this is messy. Editorial.
LGTMLG with comment

Revised text:
of codecs sent to a remote party indicates what the local side is willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send.  <ins> However, not all parameters follow this rule; some parameters are declarative and the remote side MUST either accept them or reject 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. </ins> In addition, various RFCs put different conditions on the format of offers versus answers.  For example, an offer may propose an
Original text:
header extension defined in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 11.  An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2. An "a=sendrecv" line, as specified in RFC3264, Section 5.1.

Reviewer comments:
lgtm
I think the dummy candidates should be v4 not v6 as many things just don't do v6 but other than that looks reasonable. You don't really need to specify the address at all the the lines when you don't know the port can just look like a=rtcp:9 With no IP address or family
NAME The IP6 vs IP4 is described in URL, so this isn't a JSEP thing. Given that this is part of the trickle spec, and only trickle endpoints will get these candidates, I don't see any problem. As to whether a=rtcp can just have the port, consider the case where RTP candidates have been gathered, but no RTCP candidates have yet been gathered. In that case, we certainly need to have the full a=rtcp:9 IP6 ::, so I think it makes sense to include it in all cases where RTCP candidates have not yet been gathered.
I don't care much about this so fine if not change is made. I agree it is a trickle-ice draft issue. However, when I read that, it seems that it would be fine with "a=rtcp:9" with no address. It seems the reason we used 9 was to provide something that stuff that did not implement trickle ICE would not barf on. I have no tested but an address of "IP6 ::" seems like something that has high odds of stuff barfing on. Anyways, no big deal with me one way or the other. On Sep 12, 2014, at 7:49 PM, Justin Uberti EMAIL wrote:
Only trickle endpoints will even receive an offer with these dummy addresses and ports, so compatibility with old non-trickle stuff is not an issue. LMK if you have any further concerns, otherwise I will merge later today.
I concur that we should merge this. , Justin Uberti EMAIL wrote:
On Sep 18, 2014, at 9:34 AM, Justin Uberti EMAIL wrote: ah - my bad - makes sense Merge it !

Revised text:
header extension defined in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 11. <ins> An "a=rtcp" line, as specified in RFC3605, Section 2.1, containing the dummy value "9 IN IP6 ::", because no candidates have yet been gathered. </ins> An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2. An "a=sendrecv" line, as specified in RFC3264, Section 5.1.