Draft: draft-ietf-rtcweb-jsep

Commentary: This PR covers the following : updated xrefs ok , removed comment ( issue 41 ) fixed xref and formatting of fmt , removed comment . issue 32 current text ok , removed comment . issue 22 It does not cover , issue 37 , despite the branch name , because that issue was actually closed with PR 
 41 ) [ rfced ] Section 5.3.2 : We found this RFC Editor Note on OLD : NEW : Please note that the " OLD " text does not match what we found in the provided draft ( i.e. , " [ RFC5245 ] , Section 4.3 . , paragraph 3 " versus " [ I - D.ietf - mmusic - ice - sip - sdp ] , Section 4.1 " ): Please review , and let us know if further changes are needed . ( As noted previously , " [ RFC8839 ] " and " [ RFC8840 ] " are the RFC numbers assigned for [ I - D.ietf - mmusic - ice - sip - sdp ] and [ I - D.ietf - mmusic - trickle - ice - sip ] , respectively . ) Currently : 
 Proposed text LGTM 
 I incorrectly mentioned this issue number when I created my branch and PR . This issue is technically still open ( the comments that need to be deleted are still there ) , and instead these edits fixed ( note the similarities in the titles of the issues ... ) . Sorry about that . 
 32 ) [ rfced ] Section 5.2.1 : We could not find any mention of " webrtc - datachannel " in Section 4.1 of RFC 8841 [ I - D.ietf - mmusic - sctp - sdp ] . Please confirm that this citation is correct and will be clear to readers . Original : The " fmt " value MUST be set to " webrtc- datachannel " as specified in [ I - D.ietf - mmusic - sctp - sdp ] , Section 4.1 . 
 It 's never really spelled out well in that document ; Section 4.5 is the only direct mention , but it 's as an example , which is suboptimal . any thoughts on this ? 
 Section 15.3 of draft - ietf - mmusic - sctp - sdp registers the " webrtc - datachannel " value with IANA . But , as you point out , there are no real procedures defined . draft - ietf - mmusic - data - channel - sdpneg also only uses the value in examples . 
 thoughts ? 
 draft - ietf - mmusic - data - channel - sdpneg seems to assume that draft - ietf - mmusic - sctp - sdp defines the usage of " webrtc - datachannel " . But , draft - ietf - mmusic - sctp - sdp can not have a generic procedure for that , since the spec could be used for other things too . I guess the solution would be to add a normative statement somewhere , saying that the m- line fmt value muts be " webrtc - datachannel " for data channels . The question is whether such statement should be in draft - ietf - mmusic - sctp - sdp or draft - ietf - mmusic - data - channel - sdpneg . 
 I think is correct ; and , given that it 's draft - ietf - mmusic - sctp - sdp that registers the value with IANA , I think that 's the document that should say as much ( e.g. , " The token ' webrtc - datachannel ' indicates the protocol defined in [ I - D.ietf - rtcweb - data - protocol ] " , either in section 4.4.2 or section 15.3 ) Christer -- can you work with and the RFC Editor to make sure this change makes it into draft - ietf - mmusic - sctp - sdp ? 
 I assume you meant " makes it into draft - ietf - mmusic - sctp - sdp " ? 
 Ah , right . Copied the wrong document name . Thanks -- it should go into draft - ietf - mmusic - sctp - sdp . 
 I have sent an e - mail where I suggest the following new text to Section 4.4.2 . : " When the SCTP association is used to realize a WebRTC data channel [ I - D.ietf - rtcweb - data - protocol ] , the < fmtparameter value is ' webrtc - datachannel ' . " Feel free to indicate your support , so people do n't think this is just  wanting past deadline additions :) 
 Thanks for doing this , will chime in on the list . 
 Looks like this one is now straightforward . I believe the new section to reference is 4.4.2 , but please double - check . 
 I 've double - checked the xref and RFC 8841 ( was draft - ietf - mmusic - sctp - sdp ) , Section 4.4.2 is correct . The formatting of " fmt " is < fmt , so the updated sentence is : 
 22 ) [ rfced ] Section 5.2.1 : We found this RFC Editor Note on OLD : NEW : Please note that the " OLD " text does not match what we found in the provided draft : We updated as follows . Is the " and [ RFC8445 ] , Section 10 " still applicable ? Currently : 
 I think we want An " a = ice - options " line with the " trickle " and " ice2 " options MUST be , as specified in [ I - D.ietf - ice - trickle ] , Section 3 and [ RFC8445 ] , Section 10 . 
 please close this issue once you consider it resolved . 
 Upon further reflection , while I think the current draft text ( the 3rd block of text above ) is correct , based on the note the proposed text ( 4th block ) may be preferred . as he wrote the note and can help disambiguate . 
 Well , it 's definitely not RFC 8440 section 3 , as that says nothing about SDP syntax or the trickle attribute . I think this is correct : An " a = ice - options " line with the " trickle " and " ice2 " options MUST be , as specified in [ RFC8840 ] , Section 4.1.1 and [ RFC8445 ] , Section 10 . ( Which is the final block above . ) I have to concede that I 've lost context for why the RFC Editor note was necessary in the first place , but it 's probably better to be more precise in any case . 
 we 're deciding between mmusic - trickle - sip - sdp , Section 4.1.1 , which says : and ice - trickle , Section 3 , which says : 
 Ah , sorry -- I missed that we were talking about two different documents . Given that the reference to trickle - ice - sip - sdp is both more indirect and unnecessarily involves a document about an only marginally related technology , I think the ice - trickle section 3 reference is cleaner . My vague recollection now is that ice - trickle used to rely on trickle - ice - sip - sdp for this behavior , and we reversed that dependency later in the cycle by moving the normative definition into ice - trickle . 
 I looked into this a bit more closely as part of some related JSEP issues and am now leaning toward keeping the trickle - sip - sdp reference ; JSEP already leans on this document for the definition of a = candidate , a = ice - ufrag , a = ice = pwd , etc , and as a similar signaling protocol topic I think a = ice - options should be handled the same way . 
 For the avoidance of doubt , I am suggesting use of the final block above : 
 I do n't feel strongly about it either way . I think the intention is clear , and implemetors will get it right regardless of which of the two citations you choose .
Paragraph (version A):
Lastly, if a data channel has been created, an "m=" section MUST be
generated for data.  The <media> field MUST be set to "application",
and the <proto> field MUST be set to "UDP/DTLS/SCTP" RFC8841.  The
"fmt" value MUST be set to "webrtc-datachannel" as specified in
RFC8841.
Paragraph (version B):
Lastly, if a data channel has been created, an "m=" section MUST be
generated for data.  The <media> field MUST be set to "application",
and the <proto> field MUST be set to "UDP/DTLS/SCTP" RFC8841.  The
<fmt> value MUST be set to "webrtc-datachannel" as specified in
RFC8841.