idnits 2.17.1 draft-ietf-mmusic-msrp-usage-data-channel-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2016) is 2746 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-16 == Outdated reference: A later version (-28) exists of draft-ietf-mmusic-data-channel-sdpneg-10 == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-18 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-37) exists of draft-ietf-mmusic-rfc4566bis-17 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC K. Drage, Ed. 3 Internet-Draft M. Makaraju 4 Intended status: Standards Track Nokia 5 Expires: April 22, 2017 J. Stoetzer-Bradler 7 R. Ejzak 8 J. Marcon 9 Unaffiliated 10 October 19, 2016 12 MSRP over Data Channels 13 draft-ietf-mmusic-msrp-usage-data-channel-06 15 Abstract 17 This document specifies how the Message Session Relay Protocol (MSRP) 18 can be instantiated as a data channel sub-protocol, using the SDP 19 offer/answer exchange-based generic data channel negotiation 20 framework. Two network configurations are documented: a WebRTC end- 21 to-end configuration (connecting two MSRP over data channel 22 endpoints), and a gateway configuration (connecting an MSRP over data 23 channel endpoint with an MSRP over TCP endpoint). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 22, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. MSRP Data Channel . . . . . . . . . . . . . . . . . . . . 4 64 4.2. Session Mapping . . . . . . . . . . . . . . . . . . . . . 4 65 4.3. MSRP URI . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.4. msrp-scheme . . . . . . . . . . . . . . . . . . . . . . . 5 67 5. End-to-End Configuration . . . . . . . . . . . . . . . . . . 5 68 5.1. Basic MSRP Support . . . . . . . . . . . . . . . . . . . 5 69 5.1.1. Session Negotiation . . . . . . . . . . . . . . . . . 5 70 5.1.1.1. Use of the dcmap Attribute . . . . . . . . . . . 5 71 5.1.1.2. Use of the dcsa Attribute . . . . . . . . . . . . 6 72 5.1.1.3. Use of the setup Attribute . . . . . . . . . . . 6 73 5.1.1.4. Example SDP Negotiation . . . . . . . . . . . . . 7 74 5.1.2. Session Opening . . . . . . . . . . . . . . . . . . . 8 75 5.1.3. Data Framing . . . . . . . . . . . . . . . . . . . . 8 76 5.1.4. Data Sending and Reporting . . . . . . . . . . . . . 9 77 5.1.5. Session Closing . . . . . . . . . . . . . . . . . . . 9 78 5.2. Support for MSRP File Transfer Function . . . . . . . . . 9 79 6. Gateway Configuration . . . . . . . . . . . . . . . . . . . . 10 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 8.1. Subprotocol Identifier MSRP . . . . . . . . . . . . . . . 11 83 8.2. setup Attribute . . . . . . . . . . . . . . . . . . . . . 11 84 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 85 10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data- 87 channel-05' . . . . . . . . . . . . . . . . . . . . . . 12 88 10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data- 89 channel-04' . . . . . . . . . . . . . . . . . . . . . . 12 90 10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data- 91 channel-03' . . . . . . . . . . . . . . . . . . . . . . 12 92 10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data- 93 channel-02' . . . . . . . . . . . . . . . . . . . . . . 12 94 10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data- 95 channel-01' . . . . . . . . . . . . . . . . . . . . . . 13 96 10.6. Changes against 'draft-ietf-mmusic-msrp-usage-data- 97 channel-00' . . . . . . . . . . . . . . . . . . . . . . 14 98 10.7. Changes against 'draft-ejzak-mmusic-msrp-usage-data- 99 channel-01' . . . . . . . . . . . . . . . . . . . . . . 15 100 10.8. Changes against '-00' . . . . . . . . . . . . . . . . . 15 101 11. Normative References . . . . . . . . . . . . . . . . . . . . 15 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 104 1. Introduction 106 The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for 107 transmitting a series of related instant messages in the context of a 108 session. In addition to instant messaging, MSRP can also be used for 109 image sharing or file transfer. MSRP is currently defined to work 110 over TCP and TLS connections. 112 This document defines the negotiation and transport of this MSRP 113 protocol over data channels, where a data channel is a bi-directional 114 communication channel running on top of SCTP/DTLS (as per 115 [I-D.ietf-rtcweb-data-channel]) and where MSRP is instantiated as a 116 sub-protocol of this data channel. The MSRP protocol negotiation 117 defined in this document is based on the generic SDP offer/answer 118 exchange based data channel negotiation as specified in 119 [I-D.ietf-mmusic-data-channel-sdpneg]. 121 Defining MSRP as a data channel sub-protocol has many benefits: 123 o provides to applications a proven protocol enabling instant 124 messaging, file transfer, image sharing 126 o integrates those features with other RTCWeb voice, video and data 127 features 129 o leverages the SDP-based negotiation already defined for MSRP 131 o allows the interworking with MSRP endpoints running on a TCP or 132 TLS connection 134 Considering an MSRP endpoint being an MSRP application that uses data 135 channel from WebRTC specifications [I-D.ietf-rtcweb-data-channel], 136 this document describes two configurations where the other endpoint 137 is respectively either another MSRP over data channel endpoint (e.g., 138 a WebRTC application) or an MSRP endpoint using either TCP or TLS 139 transport. 141 2. Conventions 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 3. Terminology 149 This document uses the following terms: 151 Data channel: A WebRTC data channel as specified in 152 [I-D.ietf-rtcweb-data-channel]. 154 MSRP data channel: A data channel specifically used to transport 155 the messages of one MSRP session. 157 External negotiation: Data channel negotiation based on out-of- 158 band or in-band mechanisms other than the Data Channel 159 Establishment Protocol specified in 160 [I-D.ietf-rtcweb-data-protocol]. 162 In-band: Transmission through the peer-to-peer SCTP association. 164 Out-of-band: Transmission through the call control signaling path, 165 e.g., using JSEP [I-D.ietf-rtcweb-jsep] and the SDP Offer/Answer 166 model [RFC3264]. 168 Peer: From the perspective of one of the agents in a session, its 169 peer is the other agent. Specifically, from the perspective of 170 the SDP offerer, the peer is the SDP answerer. From the 171 perspective of the SDP answerer, the peer is the SDP offerer. 173 4. Principles 175 4.1. MSRP Data Channel 177 In this document, an MSRP data channel is a data channel for which 178 the instantiated sub-protocol is "MSRP", and where the MSRP-related 179 negotiation is done as part of the SDP-based external negotiation 180 method defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 182 4.2. Session Mapping 184 In this design, the MSRP session maps to the SCTP association and the 185 "SCTP stream pair" assigned to the data channel, and each MSRP 186 session maps to one data channel exactly. 188 4.3. MSRP URI 190 This document extends the MSRP URI syntax [RFC4975] by defining the 191 new transport parameter value "dc": 193 transport /= "dc" / 1*ALPHANUM 194 ; Add "dc" to existing transports per [RFC4975] 196 4.4. msrp-scheme 198 The msrp-scheme portion of the MSRP-URI that represents an MSRP data 199 channel endpoint (used in the SDP path attribute and in the MSRP 200 message headers) is always "msrps", which indicates that the MSRP 201 data channel is always secured using DTLS. 203 5. End-to-End Configuration 205 This section describes the network configuration where each MSRP 206 endpoint is running MSRP over a data channel. 208 5.1. Basic MSRP Support 210 5.1.1. Session Negotiation 212 5.1.1.1. Use of the dcmap Attribute 214 The SDP offer SHALL include a dcmap attribute line (defined in 215 [I-D.ietf-mmusic-data-channel-sdpneg]), within the media description 216 for the SCTP association for each MSRP data channel session to be 217 negotiated. 219 The attribute includes the following data channel parameters: 221 o "label=" labelstring 223 o "subprotocol=" "MSRP" 225 The labelstring is set by the MSRP application according to 226 [I-D.ietf-mmusic-data-channel-sdpneg]. Ordered and reliable data 227 channels MUST always be used, such that the "max-retr" and "max-time" 228 parameters SHALL NOT be used. If the "ordered" parameter is used, 229 then its value MUST be equal to "true". 231 Rest of the SDP offer/answer procedures are per 232 [I-D.ietf-mmusic-data-channel-sdpneg]. 234 The following is an example of the dcmap attribute for an MSRP 235 session to be negotiated with stream=2 and label="chat": 237 a=dcmap:2 label="chat";subprotocol="MSRP" 239 5.1.1.2. Use of the dcsa Attribute 241 The SDP offer SHALL also include within the media description for the 242 SCTP association a dcsa attribute line (defined in 243 [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP 244 attribute to be negotiated for each MSRP data channel being 245 negotiated. 247 The MSRP-specific items that can be negotiated include at least all 248 of the following well-known attributes: 250 o defined in [RFC4975]: "path", "accept-types", "accept-wrapped- 251 types", "max-size" 253 o defined in [RFC4566]: "sendonly", "recvonly", "inactive", and 254 "sendrecv" 256 o defined in [RFC6135]: "setup" 258 o defined in [RFC6714]: "msrp-cema" 260 o defined in [RFC5547]: all the parameters related to MSRP file 261 transfer. See Section 5.2. 263 The msrp-cema attribute SHALL be assumed to be present for every MSRP 264 session using data channel transport, so the inclusion of the msrp- 265 cema attribute is OPTIONAL. This ensures that the data channel 266 transport for the MSRP session is established without using the path 267 attribute. 269 The SDP answer SHALL include zero or more corresponding dcsa 270 attribute lines for each negotiated MSRP session, according to the 271 MSRP-specific attribute negotiation rules in the corresponding 272 specifications. 274 A new SDP offer/answer MAY update the MSRP subprotocol attributes 275 while keeping the same subprotocol a=dcmap description. The 276 semantics for newly negotiated MSRP subprotocol attributes are per 277 [RFC4975]. 279 5.1.1.3. Use of the setup Attribute 281 The SDP setup attribute, as introduced in [RFC4145], can be used in 282 WebRTC data channel related SDP media descriptions as a media level 283 attribute, which is associated with the corresponding UDP/DTLS/SCTP 284 or TCP/DTLS/SCTP "m" line. In this case the setup attribute is of 285 the form "a=setup:", where assumes values as defined in 286 [RFC4145]. Such a setup attribute is used as specified in 287 [I-D.ietf-mmusic-sctp-sdp] in order to negotiate the establishment 288 roles of the DTLS connection. If an MSRP session is negotiated over 289 a data channel, then such an "a=setup" attribute has no relationship 290 with the MSRP session. 292 Additionally, the setup attribute can be embedded in a dcsa attribute 293 and hence can explicitly be associated with an MSRP session over a 294 specific data channel. In such a case it is of the form "a=dcsa:x 295 setup:", with x being the data channel's SCTP stream 296 identifier. Such a dcsa embedded setup attribute has no relationship 297 with the DTLS connection establishment roles. 299 A dcsa embedded setup attribute MUST be used for MSRP sessions over 300 data channels. 302 The dcsa embedded setup attribute in an MSRP over data channel 303 description is used to negotiate, which MSRP session endpoint assumes 304 the active role as per Section 4.2.2 of [RFC6135] and Section 5.4 of 305 [RFC4975]. 307 It is considered an error if an MSRP over data channel description 308 does not contain a dcsa embedded setup attribute. 310 5.1.1.4. Example SDP Negotiation 312 The following is an example of an "m" line for data channels in an 313 SDP offer that includes the attributes needed to establish two MSRP 314 sessions: one for chat and one for file transfer. The example is 315 derived from a combination of examples in [RFC4975] and [RFC5547]. 317 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 318 c=IN IP4 79.97.215.79 319 a=max-message-size:100000 320 a=sctp-port:5000 321 a=setup:actpass 322 a=connection:new 323 a=fingerprint:SHA-256 \ 324 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 325 a=dcmap:0 label="chat";subprotocol="MSRP" 326 a=dcsa:0 setup:active 327 a=dcsa:0 accept-types:message/cpim text/plain 328 a=dcsa:0 path:msrps://bob.example.com:54111/si438dsaodes;dc 329 a=dcmap:2 label="file transfer";subprotocol="MSRP" 330 a=dcsa:2 sendonly 331 a=dcsa:2 setup:active 332 a=dcsa:2 accept-types:message/cpim 333 a=dcsa:2 accept-wrapped-types:* 334 a=dcsa:2 path:msrps://bob.example.com:54111/jshA7we;dc 335 a=dcsa:2 file-selector:name:"My cool picture.jpg" \ 336 type:image/jpeg size:32349 hash:sha-1: \ 337 72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E 338 a=dcsa:2 file-transfer-id:vBnG916bdberum2fFEABR1FR3ExZMUrd 339 a=dcsa:2 file-disposition:attachment 340 a=dcsa:2 file-date:creation:"Mon, 15 May 2006 15:01:31 +0300" 341 a=dcsa:2 file-icon:cid:id2@bob.example.com 342 a=dcsa:2 file-range:1-32349 344 5.1.2. Session Opening 346 Section 5.1.1.3 describes how the active MSRP session endpoint role 347 is negotiated. The active MSRP session endpoint does not use the 348 path attribute to open a transport connection to its peer. Instead, 349 it uses the data channel established for this MSRP session by the 350 generic data channel opening procedure defined in 351 [I-D.ietf-mmusic-data-channel-sdpneg]. 353 As soon as this data channel is opened, the MSRP session is actually 354 opened by the active MSRP session endpoint. In order to do this the 355 active MSRP endpoint sends an MSRP SEND message (empty or not) to the 356 other MSRP endpoint. The msrp-cema attribute is implicitly 357 associated with every MSRP session using data channel transport. 359 5.1.3. Data Framing 361 Each text-based MSRP message is sent on the corresponding SCTP stream 362 using standard MSRP framing and chunking procedures, as defined in 363 [RFC4975], with each MSRP chunk delivered in a single SCTP user 364 message. Therefore all sent MSRP chunks including the MSRP chunk 365 header MUST have lengths of less than or equal to the value of the 366 peer's "a=max-message-size" attribute, which is associated with the 367 data channel's SCTP association. 369 5.1.4. Data Sending and Reporting 371 Data sending and reporting procedures SHALL conform to RFC 4975. 373 5.1.5. Session Closing 375 The closure of an MSRP session MUST be signaled via an SDP offer/ 376 answer exchange which removes the "a=dcmap:" and "a=dcsa:" attribute 377 lines associated with the MSRP session from the associated DTLS/SCTP 378 based media description. This results in the associated data channel 379 being closed as well as per [I-D.ietf-mmusic-data-channel-sdpneg], 380 where the actual data channel closure procedure is typically 381 initiated by the SDP answerer right after having accepted the SDP 382 offer. 384 The port value for the "m" line SHOULD NOT be changed (e.g. to zero) 385 when closing an MSRP session (unless all data channels are being 386 closed and the SCTP association is no longer needed), since this 387 would close the SCTP association and impact all of the data channels. 388 In all cases in [RFC4975] where the procedure calls for setting the 389 port to zero for the MSRP "m" line in an SDP offer for TCP transport, 390 the SDP offerer of an MSRP session with data channel transport SHALL 391 remove the corresponding dcmap and dcsa attributes. 393 The SDP answerer must ensure that no dcmap or dcsa attributes are 394 present in the SDP answer if no corresponding attributes are present 395 in the received SDP offer. 397 5.2. Support for MSRP File Transfer Function 399 [RFC5547] defines an end-to-end file transfer method based on MSRP 400 and the SDP offer/answer mechanism. This file transfer method is 401 also usable by MSRP endpoints using data channels, with the following 402 considerations: 404 o As an MSRP session maps to one data channel, a file transfer 405 session maps also to one data channel. 407 o SDP attributes specified in [RFC5547] for a file transfer "m" line 408 are embedded as subprotocol-specific attributes using the syntax 409 defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 411 o Once the file transfer is complete, the same data channel MAY be 412 reused for another file transfer. 414 6. Gateway Configuration 416 This section describes the network configuration where one MSRP 417 endpoint uses data channels as MSRP transport, the other MSRP 418 endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP 419 endpoints interwork via an MSRP gateway. 421 Specifically, a gateway can be configured to interwork an MSRP 422 session over a data channel with a peer that does not support data 423 channel transport in one of two ways. In one model, the gateway 424 performs as a MSRP B2BUA to interwork all the procedures as necessary 425 between the endpoints. No further specification is needed for this 426 model. 428 Alternately, the gateway can use CEMA procedures to provide transport 429 level interworking between MSRP endpoints using different transport 430 protocols as follows. 432 When the gateway performs transport level interworking between MSRP 433 endpoints, all of the procedures in Section 5 apply to each peer, 434 with the following additions: 436 o The endpoint establishing an MSRP session using data channel 437 transport SHALL NOT request inclusion of any relays, although it 438 MAY interoperate with a peer that signals the use of relays. 440 o The gateway receiving an SDP offer that includes a request to 441 negotiate an MSRP session on a data channel can provide transport 442 level interworking in the same manner as a CEMA SBC by forwarding 443 TCP or TLS transport parameters in a new "m" line with the 444 appropriate attributes within the forwarded SDP offer. 446 * Especially, the gateway interworks the received MSRP over data 447 channel associated dcsa embedded setup attribute with the media 448 description level "a=setup" attribute of the MSRP over TCP or 449 TLS "m" line within its forwarded SDP offer. 451 o Similarly, a gateway receiving an SDP offer to negotiate an MSRP 452 session using TCP or TLS transport with an endpoint that only 453 supports data channel transport for MSRP can provide transport 454 level interworking in the same manner as a CEMA SBC by 455 establishing a new data channel for the MSRP session with the 456 target endpoint. 458 * In this case the gateway interworks the received MSRP over TCP 459 or TLS associated "a=setup" attribute with the dcsa embedded 460 setup attribute of the generated MSRP over data channel 461 description. 463 7. Security Considerations 465 To be completed. 467 8. IANA Considerations 469 8.1. Subprotocol Identifier MSRP 471 NOTE to RFC Editor: Please replace "XXXX" with the number of this 472 RFC. 474 This document adds the subprotocol identifier "MSRP" to the 475 "WebSocket Subprotocol Name Registry" as follows: 477 +--------------------------+---------+ 478 | Subprotocol Identifier: | MSRP | 479 | Subprotocol Common Name: | MSRP | 480 | Subprotocol Definition: | RFCXXXX | 481 | Reference: | RFCXXXX | 482 +--------------------------+---------+ 484 8.2. setup Attribute 486 NOTE to RFC Editor: Please replace "XXXX" with the number of this 487 RFC. 489 This document modifies the usage of the SDP setup attribute, if this 490 attribute is embedded in a dcsa attribute and associated with an MSRP 491 session over a data channel. The modified usage is described in 492 Section 5.1.1.3. 494 Usage level "dcsa(MSRP)" should be added to the IANA registration of 495 the SDP setup attribute as follows: 497 +-----------------------+-------------------------------------------+ 498 | Contact name: | MMUSIC Chairs | 499 | Contact email: | mmusic-chairs@ietf.org | 500 | Attribute name: | setup | 501 | Usage level: | dcsa(MSRP) | 502 | Purpose: | Negotiate the active role of an MSRP | 503 | | session over a data channel as per | 504 | | Section 5.1.1.3 | 505 | Reference: | RFCXXXX | 506 +-----------------------+-------------------------------------------+ 508 9. Acknowledgments 510 The authors wish to acknowledge the borrowing of ideas from another 511 internet draft by Peter Dunkley and Gavin Llewellyn, and to thank 512 Flemming Andreasen, Christian Groves, Christer Holmberg, Paul 513 Kyzivat, Jonathan Lennox, Uwe Rauschenbach, Albrecht Schwarz and 514 Keith Drage for their invaluable comments. 516 10. CHANGE LOG 518 10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-05' 520 o Modification of Juergen's address information. 522 10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-04' 524 o Addition of [I-D.ietf-mmusic-rfc4566bis] to list of normative 525 references. 527 o Addition of Section 8.2 as per section 8.2.4 of 528 [I-D.ietf-mmusic-rfc4566bis]. 530 10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-03' 532 o Addition of IANA registration related Section 8.1. 534 10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-02' 536 o Addition of "a=setup:actpass", "a=connection:new", 537 "a=fingerprint:..." and "a=dcsa:x setup=active" SDP attributes to 538 the SDP example in Section 5.1.1.4. 540 o Addition of [RFC4145] and [I-D.ietf-mmusic-sctp-sdp] to list of 541 normative references. 543 o Addition of new Section 5.1.1.3 describing how the active MSRP 544 session endpoint role is negotiated. 546 o Extension of first paragraph of Section 5.1.2 with new first 547 sentence "Section 5.1.1.3 describes how the active MSRP session 548 endpoint role is negotiated.". 550 o First sentence of second paragraph in Section 5.1.2 was "As soon 551 as this data channel is opened, the MSRP session is actually 552 opened by the active MSRP endpoint which sends an MSRP SEND 553 message (empty or not) to the other MSRP endpoint." Replacement 554 of this sentence with "As soon as this data channel is opened, the 555 MSRP session is actually opened by the active MSRP endpoint. In 556 order to do this the active MSRP endpoint sends an MSRP SEND 557 message (empty or not) to the other MSRP endpoint." 559 o Addition of setup attribute specific behavior descriptions of data 560 channel to TCP or TLS interworking gateways in Section 6. 562 10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-01' 564 o In the abstract replacement of the first sentence "This document 565 specifies how the Message Session Relay Protocol (MSRP) can be 566 instantiated as a data channel sub-protocol, using the SDP offer/ 567 answer exchange-based external negotiation defined in 568 [I-D.ietf-mmusic-data-channel-sdpneg]" with "This document 569 specifies how the Message Session Relay Protocol (MSRP) can be 570 instantiated as a data channel sub-protocol, using the SDP offer/ 571 answer exchange-based generic data channel negotiation framework" 572 in order to remove the reference from the abstract text. 574 o Addition of following sentence to the second paragraph in 575 Section 1: "The MSRP protocol negotiation defined in this document 576 is based on the generic SDP offer/answer exchange based data 577 channel negotiation as specified in 578 [I-D.ietf-mmusic-data-channel-sdpneg]". 580 o In Section 4.1 replacement of sub-protocol identifier "msrp" with 581 "MSRP" in order to make this consistent with the formal 582 specification in Section 5.1.1.1. 584 o Throughout the text replacement of "shall" with "SHALL" etc where 585 appropriate as per [RFC2119]. 587 o In Section 5.1.1.1 replacement of sentence 'The max-retr, max-time 588 and ordered parameters shall not be used.' with 'Ordered and 589 reliable data channels MUST always be used, such that the "max- 590 retr" and "max-time" parameters SHALL NOT be used. If the 591 "ordered" parameter is used, then its value MUST be equal to 592 "true".'. 594 o In Section 5.1.1.1 removal of "(on default SCTP port 5000)" from 595 the sentence preceding the example "a=dcmap" attribute line. 597 o In Section 5.1.1.2 first paragraph was "The SDP offer shall also 598 include a dcsa attribute line (defined in 599 [I-D.ietf-mmusic-data-channel-sdpneg]) within the media 600 description for the SCTP association for each MSRP-specific SDP 601 attribute to be negotiated for each MSRP data channel being 602 negotiated.". Replacement of this paragraph with "The SDP offer 603 SHALL also include within the media description for the SCTP 604 association a dcsa attribute line (defined in 605 [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP 606 attribute to be negotiated for each MSRP data channel being 607 negotiated.". 609 o Appended following sentence at the end of the first paragraph of 610 Section 5.1.3: "Therefore all sent MSRP chunks MUST have lengths 611 of less than or equal to the value of the peer's "a=max-message- 612 size" attribute, which is associated with the data channel's SCTP 613 association.". 615 o Addition of the previously missing colon to the "a=sctp-port" 616 attribute line in Section 5.1.1.4. 618 o In Section 5.1.5 replacement of the first paragraph "Closing of an 619 MSRP session is done using the generic data channel closing 620 procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]." with 621 'The closure of an MSRP session MUST be signaled via an SDP offer/ 622 answer exchange which removes the "a=dcmap:" and "a=dcsa:" 623 attribute lines associated with the MSRP session from the 624 associated DTLS/SCTP based media description. This results in the 625 associated data channel being closed as well as per 626 [I-D.ietf-mmusic-data-channel-sdpneg], where the actual data 627 channel closure procedure is typically initiated by the SDP 628 answerer right after having accepted the SDP offer.'. 630 10.6. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-00' 632 o Additional reference to [I-D.ietf-mmusic-data-channel-sdpneg] in 633 list of normative references. 635 o Replacement of previous document title "MSRP over SCTP/DTLS data 636 channels" with "MSRP over Data Channels" in order to align with 637 the terminology used in [I-D.ietf-mmusic-data-channel-sdpneg]. 639 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 640 channel consisting of paired SCTP outbound and inbound streams." 641 Replacement of this definition with "Data channel: A WebRTC data 642 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 643 consistent usage of either "data channel" or "MSRP data channel" 644 in the remainder of the document." 646 o In the introduction replacement of references to 647 [I-D.ietf-rtcweb-data-protocol] with a reference to 648 [I-D.ietf-rtcweb-data-channel]. 650 o Consistent usage of '"m" line' in whole document as per [RFC4566]. 652 o In the gateway configuration section (Section 6) replacement of 653 the first sentence "This section describes the network 654 configuration where one endpoint runs MSRP over a WebRTC SCTP/DTLS 655 connection, the other MSRP endpoint runs MSRP over one or more 656 TLS/TCP connections, and the two endpoints interwork via an MSRP 657 gateway" with "This section describes the network configuration 658 where one MSRP endpoint uses data channels as MSRP transport, the 659 other MSRP endpoint uses TLS/TCP connections as MSRP transport, 660 and the two MSRP endpoints interwork via an MSRP gateway". 662 10.7. Changes against 'draft-ejzak-mmusic-msrp-usage-data-channel-01' 664 o Removed empty spaces after ";" in the examples' "a=dcmap" 665 attribute lines. 667 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 668 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 669 replaced with "a=max-message-size" attribute lines, as per draft- 670 ietf-mmusic-sctp-sdp-12. 672 10.8. Changes against '-00' 674 o Transport parameter change for MSRP to allow MSRP RFC transports. 676 o Clarification on SDP offer/answer and removing duplicated 677 procedures and refer them to draft-ejzak-mmusic-data-channel- 678 sdpneg-02. 680 11. Normative References 682 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 683 Requirement Levels", BCP 14, RFC 2119, 684 DOI 10.17487/RFC2119, March 1997, 685 . 687 [I-D.ietf-rtcweb-jsep] 688 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 689 Session Establishment Protocol", draft-ietf-rtcweb-jsep-16 690 (work in progress), September 2016. 692 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 693 with Session Description Protocol (SDP)", RFC 3264, 694 DOI 10.17487/RFC3264, June 2002, 695 . 697 [I-D.ietf-rtcweb-data-protocol] 698 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 699 Establishment Protocol", draft-ietf-rtcweb-data- 700 protocol-09 (work in progress), January 2015. 702 [I-D.ietf-rtcweb-data-channel] 703 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 704 Channels", draft-ietf-rtcweb-data-channel-13 (work in 705 progress), January 2015. 707 [I-D.ietf-mmusic-data-channel-sdpneg] 708 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 709 and (. (Unknown), "SDP-based Data Channel Negotiation", 710 draft-ietf-mmusic-data-channel-sdpneg-10 (work in 711 progress), September 2016. 713 [I-D.ietf-mmusic-sctp-sdp] 714 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 715 "Session Description Protocol (SDP) Offer/Answer 716 Procedures For Stream Control Transmission Protocol (SCTP) 717 over Datagram Transport Layer Security (DTLS) Transport.", 718 draft-ietf-mmusic-sctp-sdp-18 (work in progress), October 719 2016. 721 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 722 the Session Description Protocol (SDP)", RFC 4145, 723 DOI 10.17487/RFC4145, September 2005, 724 . 726 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 727 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 728 July 2006, . 730 [I-D.ietf-mmusic-rfc4566bis] 731 Handley, M., Jacobson, V., Perkins, C., and A. Begen, 732 "SDP: Session Description Protocol", draft-ietf-mmusic- 733 rfc4566bis-17 (work in progress), June 2016. 735 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 736 "The Message Session Relay Protocol (MSRP)", RFC 4975, 737 DOI 10.17487/RFC4975, September 2007, 738 . 740 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 741 and P. Kyzivat, "A Session Description Protocol (SDP) 742 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 743 DOI 10.17487/RFC5547, May 2009, 744 . 746 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 747 for the Message Session Relay Protocol (MSRP)", RFC 6135, 748 DOI 10.17487/RFC6135, February 2011, 749 . 751 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 752 Establishment for Media Anchoring (CEMA) for the Message 753 Session Relay Protocol (MSRP)", RFC 6714, 754 DOI 10.17487/RFC6714, August 2012, 755 . 757 Authors' Addresses 759 Keith Drage (editor) 760 Nokia 761 Quadrant, Stonehill Green, Westlea 762 Swindon 763 UK 765 Email: Keith.Drage@nokia.com 767 Maridi R. Makaraju (Raju) 768 Nokia 769 2000 Lucent Lane 770 Naperville, Illinois 771 US 773 Email: Raju.Makaraju@nokia.com 775 Juergen Stoetzer-Bradler 777 Email: Juergen.S-B.ietf@email.de 779 Richard Ejzak 780 Unaffiliated 782 Email: richard.ejzak@gmail.com 784 Jerome Marcon 785 Unaffiliated