idnits 2.17.1 draft-ietf-mmusic-msrp-usage-data-channel-16.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-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 4, 2020) is 1443 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC J. Recio, Ed. 3 Internet-Draft Unaffiliated 4 Intended status: Standards Track C. Holmberg 5 Expires: November 5, 2020 Ericsson 6 May 4, 2020 8 MSRP over Data Channels 9 draft-ietf-mmusic-msrp-usage-data-channel-16 11 Abstract 13 This document specifies how the Message Session Relay Protocol (MSRP) 14 can be transported as a WebRTC data channel sub-protocol, using the 15 SDP offer/answer generic data channel negotiation framework to 16 establish such a channel. Two network configurations are supported: 17 connecting two MSRP over data channel endpoints; and a gateway 18 configuration, connecting an MSRP over data channel endpoint with an 19 MSRP over TCP or TLS endpoint. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 5, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. WebRTC Data Channel Considerations . . . . . . . . . . . . . 4 58 3.1. MSRP Data Channel . . . . . . . . . . . . . . . . . . . . 4 59 4. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. MSRP URI . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. msrp-scheme . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.3. Use of the dcmap Attribute . . . . . . . . . . . . . . . 5 63 4.4. Use of the dcsa Attribute . . . . . . . . . . . . . . . . 6 64 4.5. Use of the dcsa embedded setup Attribute . . . . . . . . 7 65 4.6. Session Closing . . . . . . . . . . . . . . . . . . . . . 7 66 4.7. Support for MSRP File Transfer Function . . . . . . . . . 7 67 4.8. Example SDP Negotiation . . . . . . . . . . . . . . . . . 8 68 5. MSRP Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 5.1. Session Mapping . . . . . . . . . . . . . . . . . . . . . 8 70 5.2. Session Opening . . . . . . . . . . . . . . . . . . . . . 9 71 5.3. Session Closing . . . . . . . . . . . . . . . . . . . . . 9 72 5.4. Data Framing . . . . . . . . . . . . . . . . . . . . . . 9 73 5.5. Data Sending and Reporting . . . . . . . . . . . . . . . 9 74 5.6. Support for MSRP File Transfer Function . . . . . . . . . 9 75 6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 10 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 7.1. Subprotocol Identifier MSRP . . . . . . . . . . . . . . . 10 78 7.2. setup Attribute . . . . . . . . . . . . . . . . . . . . . 11 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 81 10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data- 83 channel-15' . . . . . . . . . . . . . . . . . . . . . . 12 84 10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data- 85 channel-14' . . . . . . . . . . . . . . . . . . . . . . 12 86 10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data- 87 channel-13' . . . . . . . . . . . . . . . . . . . . . . 12 88 10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data- 89 channel-12' . . . . . . . . . . . . . . . . . . . . . . 12 90 10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data- 91 channel-11' . . . . . . . . . . . . . . . . . . . . . . 12 92 10.6. Changes against 'draft-ietf-mmusic-msrp-usage-data- 93 channel-10' . . . . . . . . . . . . . . . . . . . . . . 12 94 10.7. Changes against 'draft-ietf-mmusic-msrp-usage-data- 95 channel-09' . . . . . . . . . . . . . . . . . . . . . . 12 96 10.8. Changes against 'draft-ietf-mmusic-msrp-usage-data- 97 channel-08' . . . . . . . . . . . . . . . . . . . . . . 12 98 10.9. Changes against 'draft-ietf-mmusic-msrp-usage-data- 99 channel-07' . . . . . . . . . . . . . . . . . . . . . . 13 100 10.10. Changes against 'draft-ietf-mmusic-msrp-usage-data- 101 channel-06' . . . . . . . . . . . . . . . . . . . . . . 13 102 10.11. Changes against 'draft-ietf-mmusic-msrp-usage-data- 103 channel-05' . . . . . . . . . . . . . . . . . . . . . . 13 104 10.12. Changes against 'draft-ietf-mmusic-msrp-usage-data- 105 channel-04' . . . . . . . . . . . . . . . . . . . . . . 13 106 10.13. Changes against 'draft-ietf-mmusic-msrp-usage-data- 107 channel-03' . . . . . . . . . . . . . . . . . . . . . . 13 108 10.14. Changes against 'draft-ietf-mmusic-msrp-usage-data- 109 channel-02' . . . . . . . . . . . . . . . . . . . . . . 13 110 10.15. Changes against 'draft-ietf-mmusic-msrp-usage-data- 111 channel-01' . . . . . . . . . . . . . . . . . . . . . . 14 112 10.16. Changes against 'draft-ietf-mmusic-msrp-usage-data- 113 channel-00' . . . . . . . . . . . . . . . . . . . . . . 15 114 10.17. Changes against 'draft-ejzak-mmusic-msrp-usage-data- 115 channel-01' . . . . . . . . . . . . . . . . . . . . . . 16 116 10.18. Changes against '-00' . . . . . . . . . . . . . . . . . 16 117 11. Normative References . . . . . . . . . . . . . . . . . . . . 16 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 120 1. Introduction 122 The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for 123 transmitting a series of related instant messages in the context of a 124 session. In addition to instant messaging, MSRP can also be used for 125 image sharing or file transfer. MSRP is currently defined to work 126 over TCP and TLS connections, and over a WebSocket subprotocol 127 specified by [RFC7977]. 129 This document specifies the negotiation and transport of MSRP over a 130 WebRTC data channel [I-D.ietf-rtcweb-data-channel]. Negotiation is 131 carried out as specified in [I-D.ietf-mmusic-data-channel-sdpneg] and 132 MSRP is transported as a sub-protocol of a WebRTC data channel. 134 Defining MSRP as a data channel sub-protocol has many benefits: 136 o provides to applications a proven protocol enabling instant 137 messaging, file transfer, image sharing 139 o integrates those features with other RTCWeb voice, video and data 140 features 142 o leverages the SDP-based negotiation already defined for MSRP 143 o allows the interworking with MSRP endpoints running on a TCP or 144 TLS connection 146 Compared to WebSockets, which provide a message passing protocol to 147 applications with no direct access to TCP or TLS sockets, data 148 channels provide a low latency transport, leverage NAT-aware 149 connectivity and security features of WebRTC, and are increasingly 150 available not only in modern browsers but in other applications that 151 use WebRTC for media or other purposes, such as IoT or telemetry in 152 general, non-media data exchange, and so on. 154 Considering an MSRP endpoint as an MSRP application that uses a 155 WebRTC data channel, this document describes two configurations where 156 the other endpoint is respectively either another MSRP over data 157 channel endpoint (e.g., a WebRTC application) or an MSRP endpoint 158 using either TCP or TLS transport. 160 2. Conventions 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in [RFC2119]. 166 3. WebRTC Data Channel Considerations 168 3.1. MSRP Data Channel 170 In this document, an MSRP data channel is a data channel for which 171 the instantiated sub-protocol is "MSRP", and where the channel is 172 negotiated using the SDP-based external negotiation method defined in 173 [I-D.ietf-mmusic-data-channel-sdpneg]. 175 The following WebRTC data channel property values [I-D.ietf-rtcweb- 176 data-channel] apply to a MSRP data channel: 178 +--------------------------+---------------------------------+ 179 | Property | Value | 180 +--------------------------+---------------------------------+ 181 | Subprotocol Identifier | MSRP | 182 | Transmission reliability | reliable | 183 | Transmission order | in-order | 184 | Label | See Section 4.3 | 185 +--------------------------+---------------------------------+ 187 4. SDP Considerations 189 This section describes the SDP considerations which are specific to a 190 MSRP data channel 192 4.1. MSRP URI 194 This document extends the MSRP URI syntax [RFC4975] by defining the 195 new transport parameter value "dc": 197 transport /= "dc" / 1*ALPHANUM 198 ; Add "dc" to existing transports per [RFC4975] 200 MSRP design provides for new transport bindings, see Section 6 of 201 [RFC4975], MSRP implementations are expected to allow unrecognized 202 transports for which there is no need to establish a connection to 203 the resource described by the URI, as it's the case of data channels 204 (Section 4.4). 206 4.2. msrp-scheme 208 The msrp-scheme portion of the MSRP-URI that represents an MSRP data 209 channel endpoint (used in the SDP path attribute and in the MSRP 210 message headers) is always "msrps", which indicates that the MSRP 211 data channel is always secured using DTLS as described in 212 [I-D.ietf-rtcweb-data-channel]. 214 4.3. Use of the dcmap Attribute 216 An offerer and answerer MUST, in each offer and answer, include a 217 dcmap attribute line ([I-D.ietf-mmusic-data-channel-sdpneg]) within 218 the media description of the SCTP association for each MSRP data 219 channel session to be negotiated. 221 The attribute includes the following data channel parameters: 223 o "label=" labelstring 225 o "subprotocol=" "MSRP" 227 The labelstring is set by the MSRP application according to 228 [I-D.ietf-mmusic-data-channel-sdpneg]. 230 The offerer and answerer MUST NOT include the max-retr and the max- 231 time attribute parameters in the dcmap attribute. 233 The offerer and answerer MAY include the ordered attribute parameter 234 in the dcmap attribute. If included, the attribute parameter value 235 MUST be set to "true". 237 Below is an example of the dcmap attribute for an MSRP session to be 238 negotiated with stream-id=2 and label="chat": 240 a=dcmap:2 label="chat";subprotocol="MSRP" 242 4.4. Use of the dcsa Attribute 244 An offerer and answerer MUST, in each offer and answer, include a 245 dcsa attribute line ([I-D.ietf-mmusic-data-channel-sdpneg]) within 246 the media description for the SCTP association for each MSRP-specific 247 SDP attribute to be negotiated for each MSRP data channel being 248 negotiated. 250 An offerer and answerer MUST include a dcsa attribute for the 251 following MSRP-specific SDP attributes: 253 o defined in [RFC4975]: "path". 255 o defined in [RFC6714]: "msrp-cema". 257 o defined in [RFC6135]: "setup". See Section 4.5 259 It is considered a protocol error if one or more of the dcsa embedded 260 attributes listed above are not included in an offer or answer. 262 An offerer and answerer MAY include a dcsa attribute for the 263 following MSRP-specific SDP attributes, following the procedures 264 defined for each attributes: 266 o defined in [RFC4975]: "accept-types", "accept-wrapped-types" and 267 "max-size" 269 o defined in [RFC4566]: "sendonly", "recvonly", "inactive" and 270 "sendrecv" 272 o defined in [RFC5547]: all the parameters related to MSRP file 273 transfer. See Section 4.7. 275 A subsequent offer or answer MAY update the previously negotiated 276 MSRP subprotocol attributes while keeping the same subprotocol 277 a=dcmap description. The semantics for newly negotiated MSRP 278 subprotocol attributes are per [RFC4975]. 280 The path attribute SHALL NOT be used for transport negotiation. 282 4.5. Use of the dcsa embedded setup Attribute 284 As described in Section 4.4, the usage of a dsca embedded setup 285 attribute is mandated for MSRP sessions over data channels. It is 286 used to negotiate which MSRP session endpoint assumes the active role 287 as per Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975]. It 288 has no relationship with the DTLS connection establishment roles 289 [I-D.ietf-mmusic-sctp-sdp]. 291 The dcsa embedded setup attribute is of the form "a=dcsa:x 292 setup:", with x being the data channel's SCTP stream 293 identifier, so that such attribute is explicitly associated with an 294 MSRP session over a specific data channel. 296 4.6. Session Closing 298 The closure of an MSRP session MUST be signaled via an SDP offer/ 299 answer exchange which removes the "a=dcmap:" and "a=dcsa:" attribute 300 lines associated with the MSRP session from the associated DTLS/SCTP 301 based media description. This results in the associated data channel 302 being closed as well as per [I-D.ietf-mmusic-data-channel-sdpneg], 303 where the actual data channel closure procedure is typically 304 initiated by the SDP answerer right after having accepted the SDP 305 offer. 307 The port value for the "m" line SHOULD NOT be changed (e.g. to zero) 308 when closing an MSRP session (unless all data channels are being 309 closed and the SCTP association is no longer needed), since this 310 would close the SCTP association and impact all of the data channels. 311 In all cases in [RFC4975] where the procedure calls for setting the 312 port to zero for the MSRP "m" line in an SDP offer for TCP transport, 313 the SDP offerer of an MSRP session with data channel transport SHALL 314 remove the corresponding dcmap and dcsa attributes. 316 The SDP answerer must ensure that no dcmap or dcsa attributes are 317 present in the SDP answer if no corresponding attributes are present 318 in the received SDP offer. 320 4.7. Support for MSRP File Transfer Function 322 SDP attributes specified in [RFC5547] for a file transfer "m" line 323 are embedded as subprotocol-specific attributes using the syntax 324 defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 326 4.8. Example SDP Negotiation 328 The following is an example of an "m" line for data channels in an 329 SDP offer that includes the attributes needed to establish two MSRP 330 sessions: one for chat and one for file transfer. The example is 331 derived from a combination of examples in [RFC4975] and [RFC5547]. 333 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 334 c=IN IP4 198.51.100.79 335 a=max-message-size:100000 336 a=sctp-port:5000 337 a=setup:actpass 338 a=fingerprint:SHA-1 \ 339 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 340 a=tls-id:4a756565cddef001be82 341 a=dcmap:0 label="chat";subprotocol="MSRP" 342 a=dcsa:0 msrp-cema 343 a=dcsa:0 setup:active 344 a=dcsa:0 accept-types:message/cpim text/plain 345 a=dcsa:0 path:msrps://bob.example.com:54111/si438dsaodes;dc 346 a=dcmap:2 label="file transfer";subprotocol="MSRP" 347 a=dcsa:2 sendonly 348 a=dcsa:2 msrp-cema 349 a=dcsa:2 setup:active 350 a=dcsa:2 accept-types:message/cpim 351 a=dcsa:2 accept-wrapped-types:* 352 a=dcsa:2 path:msrps://bob.example.com:54111/jshA7we;dc 353 a=dcsa:2 file-selector:name:"picture1.jpg" \ 354 type:image/jpeg size:1463440 hash:sha-1:\ 355 FF:27:0D:81:14:F1:8A:C3:35:3B:36:64:2A:62:C9:3E:D3:6B:51:B4 356 a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep 357 a=dcsa:2 file-disposition:attachment 358 a=dcsa:2 file-date:creation:"Mon, 12 Jan 2018 15:01:31 +0800" 359 a=dcsa:2 file-icon:cid:id2@bob.example.com 360 a=dcsa:2 file-range:1-1463440 362 5. MSRP Considerations 364 This section describes the MSRP considerations specific to a MSRP 365 data channel. 367 5.1. Session Mapping 369 In this document, each MSRP session maps to one data channel exactly. 371 5.2. Session Opening 373 Section 4.5 describes how the active MSRP session endpoint role is 374 negotiated. The active MSRP session endpoint uses the data channel 375 established for this MSRP session by the generic data channel opening 376 procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 378 As soon as the WebRTC data channel is opened, the MSRP session is 379 actually opened by the active MSRP session endpoint. In order to do 380 this the active MSRP endpoint sends an MSRP SEND message (empty or 381 not) to the other MSRP endpoint. 383 5.3. Session Closing 385 The closure of an MSRP session MUST be signaled via SDP following the 386 requirements in Section 4.6 388 5.4. Data Framing 390 Each text-based MSRP message is sent on the corresponding SCTP stream 391 using standard MSRP framing and chunking procedures, as defined in 392 [RFC4975], with each MSRP chunk delivered in a single SCTP user 393 message. Therefore all sent MSRP chunks including the MSRP chunk 394 header MUST have lengths of less than or equal to the value of the 395 peer's "a=max-message-size" attribute, which is associated with the 396 data channel's SCTP association. 398 5.5. Data Sending and Reporting 400 Data sending and reporting procedures SHALL conform to [RFC4975]. 402 5.6. Support for MSRP File Transfer Function 404 [RFC5547] defines an end-to-end file transfer method based on MSRP 405 and the SDP offer/answer mechanism. This file transfer method is 406 also usable by MSRP endpoints using data channels, with the following 407 considerations: 409 o As an MSRP session maps to one data channel, a file transfer 410 session maps also to one data channel. 412 o SDP attributes are negotiated as specified in Section 4.7. 414 o Once the file transfer is complete, the same data channel MAY be 415 reused for another file transfer. 417 6. Gateway Considerations 419 This section describes the network configuration where one MSRP 420 endpoint uses a MSRP data channel as MSRP transport, the other MSRP 421 endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP 422 endpoints interwork via a gateway. 424 Specifically, a gateway can be configured to interwork an MSRP 425 session over a data channel with a peer that does not support data 426 channel transport in one of two ways. 428 In one model, the gateway performs as a MSRP B2BUA to interwork all 429 the procedures as necessary between the endpoints. No further 430 specification is needed for this model. 432 Alternately, the gateway can provide transport level interworking 433 between MSRP endpoints using different transport protocols. In 434 accordance with Section 4.4, path attributes SHALL NOT be used for 435 transport level interworking. 437 When the gateway performs transport level interworking between MSRP 438 endpoints, all of the procedures in Section 5 and Section 4 apply to 439 each peer, with the following additions: 441 o The gateway MUST use CEMA towards the non-data channel endpoint. 443 o If the non-data channel endpoint does not support CEMA, transport 444 level interworking mode is not possible, the gateway needs to act 445 as an MSRP B2BUA. 447 o The gateway MUST NOT modify the path attribute received from data 448 channel or from non-data channel endpoints. 450 o The gateway MUST NOT modify the setup value received from data 451 channel or from non-data channel endpoints. 453 o The endpoint establishing an MSRP session using data channel 454 transport SHALL NOT request inclusion of any relays, although it 455 MAY interoperate with a peer that signals the use of relays. 457 7. IANA Considerations 459 7.1. Subprotocol Identifier MSRP 461 NOTE to RFC Editor: Please replace "XXXX" with the number of this 462 RFC. 464 This document adds the subprotocol identifier "MSRP" to the 465 "WebSocket Subprotocol Name Registry" as follows: 467 +--------------------------+---------+ 468 | Subprotocol Identifier: | MSRP | 469 | Subprotocol Common Name: | MSRP | 470 | Subprotocol Definition: | RFCXXXX | 471 | Reference: | RFCXXXX | 472 +--------------------------+---------+ 474 7.2. setup Attribute 476 NOTE to RFC Editor: Please replace "XXXX" with the number of this 477 RFC. 479 This document modifies the usage of the SDP setup attribute, if this 480 attribute is embedded in a dcsa attribute and associated with an MSRP 481 session over a data channel. The modified usage is described in 482 Section 4.5. 484 Usage level "dcsa(MSRP)" should be added to the IANA registration of 485 the SDP setup attribute as follows: 487 +-----------------------+-------------------------------------------+ 488 | Contact name: | MMUSIC Chairs | 489 | Contact email: | mmusic-chairs@ietf.org | 490 | Attribute name: | setup | 491 | Usage level: | dcsa(MSRP) | 492 | Purpose: | Negotiate the active role of an MSRP | 493 | | session over a data channel as per | 494 | | Section 4.5 | 495 | Reference: | RFCXXXX | 496 +-----------------------+-------------------------------------------+ 498 8. Security Considerations 500 MSRP traffic over data channels is secured, including 501 confidentiality, integrity and source authentication, as specified by 502 [I-D.ietf-rtcweb-data-channel] 504 Note that discussion in [RFC4975] on MSRP message attribution to 505 remote identities applies to data channel transport. 507 9. Acknowledgments 509 The authors wish to acknowledge the borrowing of ideas from another 510 internet draft by Peter Dunkley and Gavin Llewellyn, and to thank 511 Flemming Andreasen, Christian Groves, Paul Kyzivat, Jonathan Lennox, 512 Uwe Rauschenbach, Albrecht Schwarz, and Keith Drage for their 513 invaluable comments. 515 Richard Ejzak, Keith Drage and Juergen Stoetzer-Bradler contributed 516 an earlier version, before the draft was re-adopted. 518 Maridi R. Makaraju (Raju) contributed valuable comments after the 519 draft was re-adopted. 521 10. CHANGE LOG 523 10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-15' 525 o More concise and clear introduction and section descriptions. 527 o Updates on author list, contributions and acknowledgements. 529 10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-14' 531 o Reorganization following t140-usage-data-channel structure. 533 10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-13' 535 o Clarify gateway procedures in accordance to mandatory use of CEMA. 537 10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-12' 539 o Make CEMA mandatory, clarify SDP procedures. 541 10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-11' 543 o Additional clarifications on cema and path attribute after mail 544 list feedback. 546 10.6. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-10' 548 o Corrections and clarifications on cema and path attributes after 549 mail list feedback. 551 10.7. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-09' 553 o Corrected area to ART. 555 10.8. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-08' 557 o Updated reference to 4566bis. 559 o Expanded motivation paragraphs in introduction. 561 10.9. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-07' 563 o Move security considerations after IANA considerations, following 564 RFC7322 suggested order. 566 o Update references to use xml.resource.org citation database. 568 o Reformat of the section discussing setup parameter 570 o Align examples with latest [I-D.ietf-mmusic-data-channel-sdpneg] 571 draft. 573 o Edit section 6 for clarity. 575 o Security requirements. 577 o Clarify comment on unrecognized transports and session opening. 579 o Update year, add editor. 581 10.10. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-06' 583 o Modification of Keith's address information. 585 10.11. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-05' 587 o Modification of Juergen's address information. 589 10.12. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-04' 591 o Addition of [I-D.ietf-mmusic-rfc4566bis] to list of normative 592 references. 594 o Addition of Section 7.2 as per section 8.2.4 of 595 [I-D.ietf-mmusic-rfc4566bis]. 597 10.13. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-03' 599 o Addition of IANA registration related Section 7.1. 601 10.14. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-02' 603 o Addition of "a=setup:actpass", "a=connection:new", 604 "a=fingerprint:..." and "a=dcsa:x setup=active" SDP attributes to 605 the SDP example in Section 4.8. 607 o Addition of [RFC4145] and [I-D.ietf-mmusic-sctp-sdp] to list of 608 normative references. 610 o Addition of new Section 4.5 describing how the active MSRP session 611 endpoint role is negotiated. 613 o Extension of first paragraph of session-opening with new first 614 sentence "Section 4.5 describes how the active MSRP session 615 endpoint role is negotiated.". 617 o First sentence of second paragraph in session-opening was "As soon 618 as this data channel is opened, the MSRP session is actually 619 opened by the active MSRP endpoint which sends an MSRP SEND 620 message (empty or not) to the other MSRP endpoint." Replacement 621 of this sentence with "As soon as this data channel is opened, the 622 MSRP session is actually opened by the active MSRP endpoint. In 623 order to do this the active MSRP endpoint sends an MSRP SEND 624 message (empty or not) to the other MSRP endpoint." 626 o Addition of setup attribute specific behavior descriptions of data 627 channel to TCP or TLS interworking gateways in Section 6. 629 10.15. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-01' 631 o In the abstract replacement of the first sentence "This document 632 specifies how the Message Session Relay Protocol (MSRP) can be 633 instantiated as a data channel sub-protocol, using the SDP offer/ 634 answer exchange-based external negotiation defined in 635 [I-D.ietf-mmusic-data-channel-sdpneg]" with "This document 636 specifies how the Message Session Relay Protocol (MSRP) can be 637 instantiated as a data channel sub-protocol, using the SDP offer/ 638 answer exchange-based generic data channel negotiation framework" 639 in order to remove the reference from the abstract text. 641 o Addition of following sentence to the second paragraph in 642 Section 1: "The MSRP protocol negotiation defined in this document 643 is based on the generic SDP offer/answer exchange based data 644 channel negotiation as specified in 645 [I-D.ietf-mmusic-data-channel-sdpneg]". 647 o In Section 3.1 replacement of sub-protocol identifier "msrp" with 648 "MSRP" in order to make this consistent with the formal 649 specification in Section 4.3. 651 o Throughout the text replacement of "shall" with "SHALL" etc where 652 appropriate as per [RFC2119]. 654 o In Section 4.3 replacement of sentence 'The max-retr, max-time and 655 ordered parameters shall not be used.' with 'Ordered and reliable 656 data channels MUST always be used, such that the "max-retr" and 657 "max-time" parameters SHALL NOT be used. If the "ordered" 658 parameter is used, then its value MUST be equal to "true".'. 660 o In Section 4.3 removal of "(on default SCTP port 5000)" from the 661 sentence preceding the example "a=dcmap" attribute line. 663 o In Section 4.4 first paragraph was "The SDP offer shall also 664 include a dcsa attribute line (defined in 665 [I-D.ietf-mmusic-data-channel-sdpneg]) within the media 666 description for the SCTP association for each MSRP-specific SDP 667 attribute to be negotiated for each MSRP data channel being 668 negotiated.". Replacement of this paragraph with "The SDP offer 669 SHALL also include within the media description for the SCTP 670 association a dcsa attribute line (defined in 671 [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP 672 attribute to be negotiated for each MSRP data channel being 673 negotiated.". 675 o Appended following sentence at the end of the first paragraph of 676 Section 5.4: "Therefore all sent MSRP chunks MUST have lengths of 677 less than or equal to the value of the peer's "a=max-message-size" 678 attribute, which is associated with the data channel's SCTP 679 association.". 681 o Addition of the previously missing colon to the "a=sctp-port" 682 attribute line in Section 4.8. 684 o In Section 5.3 replacement of the first paragraph "Closing of an 685 MSRP session is done using the generic data channel closing 686 procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]." with 687 'The closure of an MSRP session MUST be signaled via an SDP offer/ 688 answer exchange which removes the "a=dcmap:" and "a=dcsa:" 689 attribute lines associated with the MSRP session from the 690 associated DTLS/SCTP based media description. This results in the 691 associated data channel being closed as well as per 692 [I-D.ietf-mmusic-data-channel-sdpneg], where the actual data 693 channel closure procedure is typically initiated by the SDP 694 answerer right after having accepted the SDP offer.'. 696 10.16. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-00' 698 o Additional reference to [I-D.ietf-mmusic-data-channel-sdpneg] in 699 list of normative references. 701 o Replacement of previous document title "MSRP over SCTP/DTLS data 702 channels" with "MSRP over Data Channels" in order to align with 703 the terminology used in [I-D.ietf-mmusic-data-channel-sdpneg]. 705 o In "terminology", "WebRTC data channel" was defined as "A 706 bidirectional channel consisting of paired SCTP outbound and 707 inbound streams." Replacement of this definition with "Data 708 channel: A WebRTC data channel as specified in 709 [I-D.ietf-rtcweb-data-channel]", and consistent usage of either 710 "data channel" or "MSRP data channel" in the remainder of the 711 document." 713 o In the introduction replacement of references to 714 [I-D.ietf-rtcweb-data-protocol] with a reference to 715 [I-D.ietf-rtcweb-data-channel]. 717 o Consistent usage of '"m" line' in whole document as per [RFC4566]. 719 o In the gateway configuration section (Section 6) replacement of 720 the first sentence "This section describes the network 721 configuration where one endpoint runs MSRP over a WebRTC SCTP/DTLS 722 connection, the other MSRP endpoint runs MSRP over one or more 723 TLS/TCP connections, and the two endpoints interwork via an MSRP 724 gateway" with "This section describes the network configuration 725 where one MSRP endpoint uses data channels as MSRP transport, the 726 other MSRP endpoint uses TLS/TCP connections as MSRP transport, 727 and the two MSRP endpoints interwork via an MSRP gateway". 729 10.17. Changes against 'draft-ejzak-mmusic-msrp-usage-data-channel-01' 731 o Removed empty spaces after ";" in the examples' "a=dcmap" 732 attribute lines. 734 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 735 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 736 replaced with "a=max-message-size" attribute lines, as per draft- 737 ietf-mmusic-sctp-sdp-12. 739 10.18. Changes against '-00' 741 o Transport parameter change for MSRP to allow MSRP RFC transports. 743 o Clarification on SDP offer/answer and removing duplicated 744 procedures and refer them to draft-ejzak-mmusic-data-channel- 745 sdpneg-02. 747 11. Normative References 749 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 750 Requirement Levels", BCP 14, RFC 2119, 751 DOI 10.17487/RFC2119, March 1997, 752 . 754 [I-D.ietf-rtcweb-data-protocol] 755 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 756 Establishment Protocol", draft-ietf-rtcweb-data- 757 protocol-09 (work in progress), January 2015. 759 [I-D.ietf-rtcweb-data-channel] 760 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 761 Channels", draft-ietf-rtcweb-data-channel-13 (work in 762 progress), January 2015. 764 [I-D.ietf-mmusic-data-channel-sdpneg] 765 Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. 766 Even, "SDP-based Data Channel Negotiation", draft-ietf- 767 mmusic-data-channel-sdpneg-28 (work in progress), May 768 2019. 770 [I-D.ietf-mmusic-sctp-sdp] 771 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 772 "Session Description Protocol (SDP) Offer/Answer 773 Procedures For Stream Control Transmission Protocol (SCTP) 774 over Datagram Transport Layer Security (DTLS) Transport.", 775 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 776 2017. 778 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 779 the Session Description Protocol (SDP)", RFC 4145, 780 DOI 10.17487/RFC4145, September 2005, 781 . 783 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 784 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 785 July 2006, . 787 [I-D.ietf-mmusic-rfc4566bis] 788 Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 789 Session Description Protocol", draft-ietf-mmusic- 790 rfc4566bis-37 (work in progress), August 2019. 792 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 793 "The Message Session Relay Protocol (MSRP)", RFC 4975, 794 DOI 10.17487/RFC4975, September 2007, 795 . 797 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 798 and P. Kyzivat, "A Session Description Protocol (SDP) 799 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 800 DOI 10.17487/RFC5547, May 2009, 801 . 803 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 804 for the Message Session Relay Protocol (MSRP)", RFC 6135, 805 DOI 10.17487/RFC6135, February 2011, 806 . 808 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 809 Establishment for Media Anchoring (CEMA) for the Message 810 Session Relay Protocol (MSRP)", RFC 6714, 811 DOI 10.17487/RFC6714, August 2012, 812 . 814 [RFC7977] Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G., 815 and R. Ravindranath, "The WebSocket Protocol as a 816 Transport for the Message Session Relay Protocol (MSRP)", 817 RFC 7977, DOI 10.17487/RFC7977, September 2016, 818 . 820 Authors' Addresses 822 Jose M. Recio (editor) 823 Unaffiliated 825 Email: jose@ch3m4.com 827 Christer Holmberg 828 Ericsson 829 Hirsalantie 11 830 Jorvas 02420 831 Finland 833 Email: christer.holmberg@ericsson.com