Draft: draft-ietf-rtcweb-jsep

Commentary: Several small updates : Issue 15 : local media state , local resources correct , removed comment . - Issue 16 : updated wording to use ' calling this method ' , removed comments , - Issue 17 : changed stopTransceiver to stop , removed comments , - Issue 18 : changed ' directional attribute ' to ' direction attribute ' , removed comments , 
 LGTM once lands 
 18 ) [ rfced ] Section 4.2.5 : We see " direction attribute " but not " directional attribute " in RFC 3264 . Will this text be clear to readers ? ( We ask because we also see " A direction attribute , determined by applying the rules regarding the offered direction specified in [ RFC3264 ] , Section 6.1 " in Section 5.3.1 of this document . ) Original : More specifically , it indicates the [ RFC3264 ] directional attribute of the associated m= section in the last applied answer ( including provisional answers ) , with " send " and " recv " directions reversed if it was a remote answer . 
 This should indeed be , as that 's the terminology used by 3264 . 
 please close this issue once you consider it resolved . 
 17 ) [ rfced ] Section 4.2.2 : Will " stopTransceiver " be clear to readers ? We could not find this string elsewhere in this document , anywhere else in this cluster of documents , in any published RFC , or in google searches . Original : The stopped property indicates whether the transceiver has been stopped , either by a call to stopTransceiver or by applying an answer that rejects the associated m= section . 
 This should be , rather than . 
 please close this issue once you consider it resolved . 
 16 ) [ rfced ] Section 4.1.16 : Should " The effects of this method call " be " The effects of calling this method , " and should " This call " be " Calling this method " ? Original : The effects of this method call depend on when it is invoked , and differ depending on which specific parameters are changed : ... This call may result in a change to the state of the ICE Agent . 
 SGTM 
 please close this issue once you consider it resolved . 
 15 ) [ rfced ] Section 4.1.10 : Please confirm that " local media state " and " local resources " ( as opposed to remote ) are correct in the context of setRemoteDescription . ( We ask because we see identical wording in Section 4.1.9 ( " setLocalDescription " ) . ) Original : This API changes the local media state ; among other things , it sets up local resources for sending and encoding media . 
 yes , this is correct 
 please close this issue once you consider it resolved . 
 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 can not 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 can not 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 can not send an updated offer during this time . 
 suggestion seems right
Paragraph (version A):
This call may result in a change to the state of the ICE agent.
Paragraph (version B):
Calling this method may result in a change to the state of the ICE
agent.
Paragraph (version A):
The stopped property indicates whether the transceiver has been
stopped, either by a call to stopTransceiver or by applying an answer
that rejects the associated "m=" section.  In either of these cases,
it is set to "true" and otherwise will be set to "false".
Paragraph (version B):
The stopped property indicates whether the transceiver has been
stopped, either by a call to stop or by applying an answer that
rejects the associated "m=" section.  In either of these cases, it is
set to "true" and otherwise will be set to "false".
Paragraph (version A):
The setDirection method sets the direction of a transceiver, which
affects the direction property of the associated "m=" section on
future calls to createOffer and createAnswer.  The permitted values
for direction are "recvonly", "sendrecv", "sendonly", and "inactive",
mirroring the identically named directional attributes defined in
RFC4566.
Paragraph (version B):
The setDirection method sets the direction of a transceiver, which
affects the direction property of the associated "m=" section on
future calls to createOffer and createAnswer.  The permitted values
for direction are "recvonly", "sendrecv", "sendonly", and "inactive",
mirroring the identically named direction attributes defined in
RFC4566.
Paragraph (version A):
The currentDirection property indicates the last negotiated direction
for the transceiver's associated "m=" section.  More specifically, it
indicates the directional attribute RFC3264 of the associated "m="
section in the last applied answer (including provisional answers),
with "send" and "recv" directions reversed if it was a remote answer.
For example, if the directional attribute for the associated "m="
section in a remote answer is "recvonly", currentDirection is set to
"sendonly".
Paragraph (version B):
The currentDirection property indicates the last negotiated direction
for the transceiver's associated "m=" section.  More specifically, it
indicates the direction attribute RFC3264 of the associated "m="
section in the last applied answer (including provisional answers),
with "send" and "recv" directions reversed if it was a remote answer.
For example, if the direction attribute for the associated "m="
section in a remote answer is "recvonly", currentDirection is set to
"sendonly".