idnits 2.17.1 draft-ietf-mmusic-msrp-usage-data-channel-13.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 (August 26, 2019) is 1698 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 K. Drage, Ed. 3 Internet-Draft M. Makaraju 4 Intended status: Standards Track J. Stoetzer-Bradler 5 Expires: February 27, 2020 R. Ejzak 6 J. Marcon 7 Unaffiliated 8 J. Recio, Ed. 9 August 26, 2019 11 MSRP over Data Channels 12 draft-ietf-mmusic-msrp-usage-data-channel-13 14 Abstract 16 This document specifies how the Message Session Relay Protocol (MSRP) 17 can be instantiated as a data channel sub-protocol, using the SDP 18 offer/answer exchange-based generic data channel negotiation 19 framework. Two network configurations are documented: a WebRTC end- 20 to-end configuration (connecting two MSRP over data channel 21 endpoints), and a gateway configuration (connecting an MSRP over data 22 channel endpoint with an MSRP over TCP or TLS endpoint). 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 27, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. MSRP Data Channel . . . . . . . . . . . . . . . . . . . . 5 63 4.2. Session Mapping . . . . . . . . . . . . . . . . . . . . . 5 64 4.3. MSRP URI . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.4. msrp-scheme . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. End-to-End Configuration . . . . . . . . . . . . . . . . . . 5 67 5.1. Basic MSRP Support . . . . . . . . . . . . . . . . . . . 6 68 5.1.1. SDP Considerations . . . . . . . . . . . . . . . . . 6 69 5.1.1.1. Use of the dcmap Attribute . . . . . . . . . . . 6 70 5.1.1.2. Use of the dcsa Attribute . . . . . . . . . . . . 6 71 5.1.1.3. Use of the dcsa embedded setup Attribute . . . . 7 72 5.1.1.4. Example SDP Negotiation . . . . . . . . . . . . . 7 73 5.1.2. Session Opening . . . . . . . . . . . . . . . . . . . 8 74 5.1.3. Data Framing . . . . . . . . . . . . . . . . . . . . 8 75 5.1.4. Data Sending and Reporting . . . . . . . . . . . . . 9 76 5.1.5. Session Closing . . . . . . . . . . . . . . . . . . . 9 77 5.2. Support for MSRP File Transfer Function . . . . . . . . . 9 78 6. Gateway Configuration . . . . . . . . . . . . . . . . . . . . 10 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 7.1. Subprotocol Identifier MSRP . . . . . . . . . . . . . . . 11 81 7.2. setup Attribute . . . . . . . . . . . . . . . . . . . . . 11 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 84 10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data- 86 channel-12' . . . . . . . . . . . . . . . . . . . . . . 12 87 10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data- 88 channel-11' . . . . . . . . . . . . . . . . . . . . . . 12 89 10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data- 90 channel-10' . . . . . . . . . . . . . . . . . . . . . . 12 91 10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data- 92 channel-09' . . . . . . . . . . . . . . . . . . . . . . 12 93 10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data- 94 channel-08' . . . . . . . . . . . . . . . . . . . . . . 12 95 10.6. Changes against 'draft-ietf-mmusic-msrp-usage-data- 96 channel-07' . . . . . . . . . . . . . . . . . . . . . . 12 98 10.7. Changes against 'draft-ietf-mmusic-msrp-usage-data- 99 channel-06' . . . . . . . . . . . . . . . . . . . . . . 13 100 10.8. Changes against 'draft-ietf-mmusic-msrp-usage-data- 101 channel-05' . . . . . . . . . . . . . . . . . . . . . . 13 102 10.9. Changes against 'draft-ietf-mmusic-msrp-usage-data- 103 channel-04' . . . . . . . . . . . . . . . . . . . . . . 13 104 10.10. Changes against 'draft-ietf-mmusic-msrp-usage-data- 105 channel-03' . . . . . . . . . . . . . . . . . . . . . . 13 106 10.11. Changes against 'draft-ietf-mmusic-msrp-usage-data- 107 channel-02' . . . . . . . . . . . . . . . . . . . . . . 13 108 10.12. Changes against 'draft-ietf-mmusic-msrp-usage-data- 109 channel-01' . . . . . . . . . . . . . . . . . . . . . . 14 110 10.13. Changes against 'draft-ietf-mmusic-msrp-usage-data- 111 channel-00' . . . . . . . . . . . . . . . . . . . . . . 15 112 10.14. Changes against 'draft-ejzak-mmusic-msrp-usage-data- 113 channel-01' . . . . . . . . . . . . . . . . . . . . . . 16 114 10.15. Changes against '-00' . . . . . . . . . . . . . . . . . 16 115 11. Normative References . . . . . . . . . . . . . . . . . . . . 16 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 118 1. Introduction 120 The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for 121 transmitting a series of related instant messages in the context of a 122 session. In addition to instant messaging, MSRP can also be used for 123 image sharing or file transfer. MSRP is currently defined to work 124 over TCP and TLS connections, and over a WebSocket subprotocol 125 specified by [RFC7977]. 127 This document defines the negotiation and transport of this MSRP 128 protocol over data channels, where a data channel is a bi-directional 129 communication channel running on top of SCTP/DTLS (as per 130 [I-D.ietf-rtcweb-data-channel]) and where MSRP is instantiated as a 131 sub-protocol of this data channel. The MSRP protocol negotiation 132 defined in this document is based on the generic SDP offer/answer 133 exchange based data channel negotiation as specified in 134 [I-D.ietf-mmusic-data-channel-sdpneg]. 136 Defining MSRP as a data channel sub-protocol has many benefits: 138 o provides to applications a proven protocol enabling instant 139 messaging, file transfer, image sharing 141 o integrates those features with other RTCWeb voice, video and data 142 features 144 o leverages the SDP-based negotiation already defined for MSRP 145 o allows the interworking with MSRP endpoints running on a TCP or 146 TLS connection 148 Compared to WebSockets, that provide a message passing protocol to 149 applications with no direct access to TCP or TLS sockets, data 150 channels provide a low latency transport, leverage NAT-aware 151 connectivity and security features of WebRTC, and are increasingly 152 available not only in modern browsers but in other applications that 153 use WebRTC for media or other purposes (IoT or telemetry in general, 154 non-media data exchange, etc). 156 Considering an MSRP endpoint being an MSRP application that uses data 157 channel from WebRTC specifications [I-D.ietf-rtcweb-data-channel], 158 this document describes two configurations where the other endpoint 159 is respectively either another MSRP over data channel endpoint (e.g., 160 a WebRTC application) or an MSRP endpoint using either TCP or TLS 161 transport. 163 2. Conventions 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. 169 3. Terminology 171 This document uses the following terms: 173 Data channel: A WebRTC data channel as specified in 174 [I-D.ietf-rtcweb-data-channel]. 176 MSRP data channel: A data channel specifically used to transport 177 the messages of one MSRP session. 179 External negotiation: Data channel negotiation based on out-of- 180 band or in-band mechanisms other than the Data Channel 181 Establishment Protocol specified in 182 [I-D.ietf-rtcweb-data-protocol]. 184 In-band: Transmission through the peer-to-peer SCTP association. 186 Out-of-band: Transmission through the call control signaling path, 187 e.g., using JSEP [I-D.ietf-rtcweb-jsep] and the SDP Offer/Answer 188 model [RFC3264]. 190 Peer: From the perspective of one of the agents in a session, its 191 peer is the other agent. Specifically, from the perspective of 192 the SDP offerer, the peer is the SDP answerer. From the 193 perspective of the SDP answerer, the peer is the SDP offerer. 195 4. Principles 197 4.1. MSRP Data Channel 199 In this document, an MSRP data channel is a data channel for which 200 the instantiated sub-protocol is "MSRP", and where the MSRP-related 201 negotiation is done as part of the SDP-based external negotiation 202 method defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 204 4.2. Session Mapping 206 In this design, the MSRP session maps to the SCTP association and the 207 "SCTP stream pair" assigned to the data channel, and each MSRP 208 session maps to one data channel exactly. 210 4.3. MSRP URI 212 This document extends the MSRP URI syntax [RFC4975] by defining the 213 new transport parameter value "dc": 215 transport /= "dc" / 1*ALPHANUM 216 ; Add "dc" to existing transports per [RFC4975] 218 MSRP design provides for new transport bindings, see Section 6 of 219 [RFC4975], MSRP implementations are expected to allow unrecognized 220 transports for which there is no need to establish a connection to 221 the resource described by the URI, as it's the case of data channels 222 (Section 5.1.2). 224 4.4. msrp-scheme 226 The msrp-scheme portion of the MSRP-URI that represents an MSRP data 227 channel endpoint (used in the SDP path attribute and in the MSRP 228 message headers) is always "msrps", which indicates that the MSRP 229 data channel is always secured using DTLS as described in 230 [I-D.ietf-rtcweb-data-channel]. 232 5. End-to-End Configuration 234 This section describes the network configuration where each MSRP 235 endpoint is running MSRP over a data channel. 237 5.1. Basic MSRP Support 239 5.1.1. SDP Considerations 241 The generic SDP considerations, including the SDP Offer/Answer 242 procedures, for negotiating a WebRTC data channel are defined in 243 [I-D.ietf-mmusic-data-channel-sdpneg]. This section defines the SDP 244 considerations that are specific to an MSRP data channel. 246 5.1.1.1. Use of the dcmap Attribute 248 An offerer and answerer MUST, in each offer and answer, include a 249 dcmap attribute line ([I-D.ietf-mmusic-data-channel-sdpneg]) within 250 the media description of the SCTP association for each MSRP data 251 channel session to be negotiated. 253 The attribute includes the following data channel parameters: 255 o "label=" labelstring 257 o "subprotocol=" "MSRP" 259 The labelstring is set by the MSRP application according to 260 [I-D.ietf-mmusic-data-channel-sdpneg]. 262 The offerer and answerer MUST NOT include the max-retr and the max- 263 time attribute parameters in the dcmap attribute. 265 The offerer and answerer MAY include the ordered attribute parameter 266 in the dcmap attribute. If included, the attribute parameter value 267 MUST be set to "true". 269 Below is an example of the dcmap attribute for an MSRP session to be 270 negotiated with stream-id=2 and label="chat": 272 a=dcmap:2 label="chat";subprotocol="MSRP" 274 5.1.1.2. Use of the dcsa Attribute 276 An offerer and answerer MUST, in each offer and answer, include a 277 dcsa attribute line ([I-D.ietf-mmusic-data-channel-sdpneg]) within 278 the media description for the SCTP association for each MSRP-specific 279 SDP attribute to be negotiated for each MSRP data channel being 280 negotiated. 282 An offerer and answerer MUST include a dcsa attribute for the 283 following MSRP-specific SDP attributes: 285 o defined in [RFC4975]: "path". 287 o defined in [RFC6714]: "msrp-cema". 289 o defined in [RFC6135]: "setup". See Section 5.1.1.3 291 It is considered a protocol error if one or more of the dcsa embedded 292 attributes listed above are not included in an offer or answer. 294 An offerer and answerer MAY include a dcsa attribute for the 295 following MSRP-specific SDP attributes, following the procedures 296 defined for each attributes: 298 o defined in [RFC4975]: "accept-types", "accept-wrapped-types" and 299 "max-size" 301 o defined in [RFC4566]: "sendonly", "recvonly", "inactive" and 302 "sendrecv" 304 o defined in [RFC5547]: all the parameters related to MSRP file 305 transfer. See Section 5.2. 307 A subsequent offer or answer MAY update the previously negotiated 308 MSRP subprotocol attributes while keeping the same subprotocol 309 a=dcmap description. The semantics for newly negotiated MSRP 310 subprotocol attributes are per [RFC4975]. 312 5.1.1.3. Use of the dcsa embedded setup Attribute 314 As described in Section 5.1.1.2, the usage of a dsca embedded setup 315 attribute is mandated for MSRP sessions over data channels. It is 316 used to negotiate which MSRP session endpoint assumes the active role 317 as per Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975]. It 318 has no relationship with the DTLS connection establishment roles 319 [I-D.ietf-mmusic-sctp-sdp]. 321 The dcsa embedded setup attribute is of the form "a=dcsa:x 322 setup:", with x being the data channel's SCTP stream 323 identifier, so that such attribute is explicitly associated with an 324 MSRP session over a specific data channel. 326 5.1.1.4. 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.1.2. Session Opening 364 Section 5.1.1.3 describes how the active MSRP session endpoint role 365 is negotiated. The active MSRP session endpoint uses the data 366 channel established for this MSRP session by the generic data channel 367 opening procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 368 The path attribute SHALL NOT be used for transport negotiation. 370 As soon as this data channel is opened, the MSRP session is actually 371 opened by the active MSRP session endpoint. In order to do this the 372 active MSRP endpoint sends an MSRP SEND message (empty or not) to the 373 other MSRP endpoint. 375 5.1.3. Data Framing 377 Each text-based MSRP message is sent on the corresponding SCTP stream 378 using standard MSRP framing and chunking procedures, as defined in 379 [RFC4975], with each MSRP chunk delivered in a single SCTP user 380 message. Therefore all sent MSRP chunks including the MSRP chunk 381 header MUST have lengths of less than or equal to the value of the 382 peer's "a=max-message-size" attribute, which is associated with the 383 data channel's SCTP association. 385 5.1.4. Data Sending and Reporting 387 Data sending and reporting procedures SHALL conform to RFC 4975. 389 5.1.5. Session Closing 391 The closure of an MSRP session MUST be signaled via an SDP offer/ 392 answer exchange which removes the "a=dcmap:" and "a=dcsa:" attribute 393 lines associated with the MSRP session from the associated DTLS/SCTP 394 based media description. This results in the associated data channel 395 being closed as well as per [I-D.ietf-mmusic-data-channel-sdpneg], 396 where the actual data channel closure procedure is typically 397 initiated by the SDP answerer right after having accepted the SDP 398 offer. 400 The port value for the "m" line SHOULD NOT be changed (e.g. to zero) 401 when closing an MSRP session (unless all data channels are being 402 closed and the SCTP association is no longer needed), since this 403 would close the SCTP association and impact all of the data channels. 404 In all cases in [RFC4975] where the procedure calls for setting the 405 port to zero for the MSRP "m" line in an SDP offer for TCP transport, 406 the SDP offerer of an MSRP session with data channel transport SHALL 407 remove the corresponding dcmap and dcsa attributes. 409 The SDP answerer must ensure that no dcmap or dcsa attributes are 410 present in the SDP answer if no corresponding attributes are present 411 in the received SDP offer. 413 5.2. Support for MSRP File Transfer Function 415 [RFC5547] defines an end-to-end file transfer method based on MSRP 416 and the SDP offer/answer mechanism. This file transfer method is 417 also usable by MSRP endpoints using data channels, with the following 418 considerations: 420 o As an MSRP session maps to one data channel, a file transfer 421 session maps also to one data channel. 423 o SDP attributes specified in [RFC5547] for a file transfer "m" line 424 are embedded as subprotocol-specific attributes using the syntax 425 defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 427 o Once the file transfer is complete, the same data channel MAY be 428 reused for another file transfer. 430 6. Gateway Configuration 432 This section describes the network configuration where one MSRP 433 endpoint uses data channels as MSRP transport, the other MSRP 434 endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP 435 endpoints interwork via an MSRP gateway. 437 Specifically, a gateway can be configured to interwork an MSRP 438 session over a data channel with a peer that does not support data 439 channel transport in one of two ways. 441 In one model, the gateway performs as a MSRP B2BUA to interwork all 442 the procedures as necessary between the endpoints. No further 443 specification is needed for this model. 445 Alternately, the gateway can use CEMA procedures to provide transport 446 level interworking between MSRP endpoints using different transport 447 protocols as follows. For example, if the gateway is implemented on 448 an Session Border Controller, it can use CEMA towards the inside 449 network, using a non-data channel transport; but the gateway can not 450 use CEMA towards endpoints using data channel transport. Path 451 attributes SHALL NOT be used for transport level interworking. 453 When the gateway performs transport level interworking between MSRP 454 endpoints, all of the procedures in Section 5 apply to each peer, 455 with the following additions: 457 o The endpoint establishing an MSRP session using data channel 458 transport SHALL NOT request inclusion of any relays, although it 459 MAY interoperate with a peer that signals the use of relays. 461 o The gateway receiving an SDP offer that includes a request to 462 negotiate an MSRP session on a data channel can provide transport 463 level interworking by forwarding TCP or TLS transport parameters 464 in a new "m" line with the appropriate attributes within the 465 forwarded SDP offer. 467 * Especially, the gateway interworks the received MSRP over data 468 channel associated dcsa embedded setup attribute with the media 469 description level "a=setup" attribute of the MSRP over TCP or 470 TLS "m" line within its forwarded SDP offer. 472 o Similarly, a gateway receiving an SDP offer to negotiate an MSRP 473 session using TCP or TLS transport with an endpoint that only 474 supports data channel transport for MSRP can provide transport 475 level interworking by establishing a new data channel for the MSRP 476 session with the target endpoint. 478 * In this case the gateway interworks the received MSRP over TCP 479 or TLS associated "a=setup" attribute with the dcsa embedded 480 setup attribute of the generated MSRP over data channel 481 description. 483 7. IANA Considerations 485 7.1. Subprotocol Identifier MSRP 487 NOTE to RFC Editor: Please replace "XXXX" with the number of this 488 RFC. 490 This document adds the subprotocol identifier "MSRP" to the 491 "WebSocket Subprotocol Name Registry" as follows: 493 +--------------------------+---------+ 494 | Subprotocol Identifier: | MSRP | 495 | Subprotocol Common Name: | MSRP | 496 | Subprotocol Definition: | RFCXXXX | 497 | Reference: | RFCXXXX | 498 +--------------------------+---------+ 500 7.2. setup Attribute 502 NOTE to RFC Editor: Please replace "XXXX" with the number of this 503 RFC. 505 This document modifies the usage of the SDP setup attribute, if this 506 attribute is embedded in a dcsa attribute and associated with an MSRP 507 session over a data channel. The modified usage is described in 508 Section 5.1.1.3. 510 Usage level "dcsa(MSRP)" should be added to the IANA registration of 511 the SDP setup attribute as follows: 513 +-----------------------+-------------------------------------------+ 514 | Contact name: | MMUSIC Chairs | 515 | Contact email: | mmusic-chairs@ietf.org | 516 | Attribute name: | setup | 517 | Usage level: | dcsa(MSRP) | 518 | Purpose: | Negotiate the active role of an MSRP | 519 | | session over a data channel as per | 520 | | Section 5.1.1.3 | 521 | Reference: | RFCXXXX | 522 +-----------------------+-------------------------------------------+ 524 8. Security Considerations 526 MSRP traffic over data channels is secured, including 527 confidentiality, integrity and source authentication, as specified by 528 [I-D.ietf-rtcweb-data-channel] 530 Note that discussion in [RFC4975] on MSRP message attribution to 531 remote identities applies to data channel transport. 533 9. Acknowledgments 535 The authors wish to acknowledge the borrowing of ideas from another 536 internet draft by Peter Dunkley and Gavin Llewellyn, and to thank 537 Flemming Andreasen, Christian Groves, Christer Holmberg, Paul 538 Kyzivat, Jonathan Lennox, Uwe Rauschenbach, Albrecht Schwarz and 539 Keith Drage for their invaluable comments. 541 10. CHANGE LOG 543 10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-12' 545 o Make CEMA mandatory, clarify SDP procedures. 547 10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-11' 549 o Additional clarifications on cema and path attribute after mail 550 list feedback. 552 10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-10' 554 o Corrections and clarifications on cema and path attributes after 555 mail list feedback. 557 10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-09' 559 o Corrected area to ART. 561 10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-08' 563 o Updated reference to 4566bis. 565 o Expanded motivation paragraphs in introduction. 567 10.6. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-07' 569 o Move security considerations after IANA considerations, following 570 RFC7322 suggested order. 572 o Update references to use xml.resource.org citation database. 574 o Reformat of the section discussing setup parameter 576 o Align examples with latest [I-D.ietf-mmusic-data-channel-sdpneg] 577 draft. 579 o Edit section 6 for clarity. 581 o Security requirements. 583 o Clarify comment on unrecognized transports and session opening. 585 o Update year, add editor. 587 10.7. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-06' 589 o Modification of Keith's address information. 591 10.8. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-05' 593 o Modification of Juergen's address information. 595 10.9. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-04' 597 o Addition of [I-D.ietf-mmusic-rfc4566bis] to list of normative 598 references. 600 o Addition of Section 7.2 as per section 8.2.4 of 601 [I-D.ietf-mmusic-rfc4566bis]. 603 10.10. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-03' 605 o Addition of IANA registration related Section 7.1. 607 10.11. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-02' 609 o Addition of "a=setup:actpass", "a=connection:new", 610 "a=fingerprint:..." and "a=dcsa:x setup=active" SDP attributes to 611 the SDP example in Section 5.1.1.4. 613 o Addition of [RFC4145] and [I-D.ietf-mmusic-sctp-sdp] to list of 614 normative references. 616 o Addition of new Section 5.1.1.3 describing how the active MSRP 617 session endpoint role is negotiated. 619 o Extension of first paragraph of Section 5.1.2 with new first 620 sentence "Section 5.1.1.3 describes how the active MSRP session 621 endpoint role is negotiated.". 623 o First sentence of second paragraph in Section 5.1.2 was "As soon 624 as this data channel is opened, the MSRP session is actually 625 opened by the active MSRP endpoint which sends an MSRP SEND 626 message (empty or not) to the other MSRP endpoint." Replacement 627 of this sentence with "As soon as this data channel is opened, the 628 MSRP session is actually opened by the active MSRP endpoint. In 629 order to do this the active MSRP endpoint sends an MSRP SEND 630 message (empty or not) to the other MSRP endpoint." 632 o Addition of setup attribute specific behavior descriptions of data 633 channel to TCP or TLS interworking gateways in Section 6. 635 10.12. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-01' 637 o In the abstract replacement of the first sentence "This document 638 specifies how the Message Session Relay Protocol (MSRP) can be 639 instantiated as a data channel sub-protocol, using the SDP offer/ 640 answer exchange-based external negotiation defined in 641 [I-D.ietf-mmusic-data-channel-sdpneg]" with "This document 642 specifies how the Message Session Relay Protocol (MSRP) can be 643 instantiated as a data channel sub-protocol, using the SDP offer/ 644 answer exchange-based generic data channel negotiation framework" 645 in order to remove the reference from the abstract text. 647 o Addition of following sentence to the second paragraph in 648 Section 1: "The MSRP protocol negotiation defined in this document 649 is based on the generic SDP offer/answer exchange based data 650 channel negotiation as specified in 651 [I-D.ietf-mmusic-data-channel-sdpneg]". 653 o In Section 4.1 replacement of sub-protocol identifier "msrp" with 654 "MSRP" in order to make this consistent with the formal 655 specification in Section 5.1.1.1. 657 o Throughout the text replacement of "shall" with "SHALL" etc where 658 appropriate as per [RFC2119]. 660 o In Section 5.1.1.1 replacement of sentence 'The max-retr, max-time 661 and ordered parameters shall not be used.' with 'Ordered and 662 reliable data channels MUST always be used, such that the "max- 663 retr" and "max-time" parameters SHALL NOT be used. If the 664 "ordered" parameter is used, then its value MUST be equal to 665 "true".'. 667 o In Section 5.1.1.1 removal of "(on default SCTP port 5000)" from 668 the sentence preceding the example "a=dcmap" attribute line. 670 o In Section 5.1.1.2 first paragraph was "The SDP offer shall also 671 include a dcsa attribute line (defined in 672 [I-D.ietf-mmusic-data-channel-sdpneg]) within the media 673 description for the SCTP association for each MSRP-specific SDP 674 attribute to be negotiated for each MSRP data channel being 675 negotiated.". Replacement of this paragraph with "The SDP offer 676 SHALL also include within the media description for the SCTP 677 association a dcsa attribute line (defined in 678 [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP 679 attribute to be negotiated for each MSRP data channel being 680 negotiated.". 682 o Appended following sentence at the end of the first paragraph of 683 Section 5.1.3: "Therefore all sent MSRP chunks MUST have lengths 684 of less than or equal to the value of the peer's "a=max-message- 685 size" attribute, which is associated with the data channel's SCTP 686 association.". 688 o Addition of the previously missing colon to the "a=sctp-port" 689 attribute line in Section 5.1.1.4. 691 o In Section 5.1.5 replacement of the first paragraph "Closing of an 692 MSRP session is done using the generic data channel closing 693 procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]." with 694 'The closure of an MSRP session MUST be signaled via an SDP offer/ 695 answer exchange which removes the "a=dcmap:" and "a=dcsa:" 696 attribute lines associated with the MSRP session from the 697 associated DTLS/SCTP based media description. This results in the 698 associated data channel being closed as well as per 699 [I-D.ietf-mmusic-data-channel-sdpneg], where the actual data 700 channel closure procedure is typically initiated by the SDP 701 answerer right after having accepted the SDP offer.'. 703 10.13. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-00' 705 o Additional reference to [I-D.ietf-mmusic-data-channel-sdpneg] in 706 list of normative references. 708 o Replacement of previous document title "MSRP over SCTP/DTLS data 709 channels" with "MSRP over Data Channels" in order to align with 710 the terminology used in [I-D.ietf-mmusic-data-channel-sdpneg]. 712 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 713 channel consisting of paired SCTP outbound and inbound streams." 714 Replacement of this definition with "Data channel: A WebRTC data 715 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 716 consistent usage of either "data channel" or "MSRP data channel" 717 in the remainder of the document." 719 o In the introduction replacement of references to 720 [I-D.ietf-rtcweb-data-protocol] with a reference to 721 [I-D.ietf-rtcweb-data-channel]. 723 o Consistent usage of '"m" line' in whole document as per [RFC4566]. 725 o In the gateway configuration section (Section 6) replacement of 726 the first sentence "This section describes the network 727 configuration where one endpoint runs MSRP over a WebRTC SCTP/DTLS 728 connection, the other MSRP endpoint runs MSRP over one or more 729 TLS/TCP connections, and the two endpoints interwork via an MSRP 730 gateway" with "This section describes the network configuration 731 where one MSRP endpoint uses data channels as MSRP transport, the 732 other MSRP endpoint uses TLS/TCP connections as MSRP transport, 733 and the two MSRP endpoints interwork via an MSRP gateway". 735 10.14. Changes against 'draft-ejzak-mmusic-msrp-usage-data-channel-01' 737 o Removed empty spaces after ";" in the examples' "a=dcmap" 738 attribute lines. 740 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 741 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 742 replaced with "a=max-message-size" attribute lines, as per draft- 743 ietf-mmusic-sctp-sdp-12. 745 10.15. Changes against '-00' 747 o Transport parameter change for MSRP to allow MSRP RFC transports. 749 o Clarification on SDP offer/answer and removing duplicated 750 procedures and refer them to draft-ejzak-mmusic-data-channel- 751 sdpneg-02. 753 11. Normative References 755 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 756 Requirement Levels", BCP 14, RFC 2119, 757 DOI 10.17487/RFC2119, March 1997, 758 . 760 [I-D.ietf-rtcweb-jsep] 761 Uberti, J., Jennings, C., and E. Rescorla, "JavaScript 762 Session Establishment Protocol", draft-ietf-rtcweb-jsep-26 763 (work in progress), February 2019. 765 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 766 with Session Description Protocol (SDP)", RFC 3264, 767 DOI 10.17487/RFC3264, June 2002, 768 . 770 [I-D.ietf-rtcweb-data-protocol] 771 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 772 Establishment Protocol", draft-ietf-rtcweb-data- 773 protocol-09 (work in progress), January 2015. 775 [I-D.ietf-rtcweb-data-channel] 776 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 777 Channels", draft-ietf-rtcweb-data-channel-13 (work in 778 progress), January 2015. 780 [I-D.ietf-mmusic-data-channel-sdpneg] 781 Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. 782 Even, "SDP-based Data Channel Negotiation", draft-ietf- 783 mmusic-data-channel-sdpneg-28 (work in progress), May 784 2019. 786 [I-D.ietf-mmusic-sctp-sdp] 787 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 788 "Session Description Protocol (SDP) Offer/Answer 789 Procedures For Stream Control Transmission Protocol (SCTP) 790 over Datagram Transport Layer Security (DTLS) Transport.", 791 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 792 2017. 794 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 795 the Session Description Protocol (SDP)", RFC 4145, 796 DOI 10.17487/RFC4145, September 2005, 797 . 799 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 800 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 801 July 2006, . 803 [I-D.ietf-mmusic-rfc4566bis] 804 Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 805 Session Description Protocol", draft-ietf-mmusic- 806 rfc4566bis-37 (work in progress), August 2019. 808 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 809 "The Message Session Relay Protocol (MSRP)", RFC 4975, 810 DOI 10.17487/RFC4975, September 2007, 811 . 813 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 814 and P. Kyzivat, "A Session Description Protocol (SDP) 815 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 816 DOI 10.17487/RFC5547, May 2009, 817 . 819 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 820 for the Message Session Relay Protocol (MSRP)", RFC 6135, 821 DOI 10.17487/RFC6135, February 2011, 822 . 824 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 825 Establishment for Media Anchoring (CEMA) for the Message 826 Session Relay Protocol (MSRP)", RFC 6714, 827 DOI 10.17487/RFC6714, August 2012, 828 . 830 [RFC7977] Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G., 831 and R. Ravindranath, "The WebSocket Protocol as a 832 Transport for the Message Session Relay Protocol (MSRP)", 833 RFC 7977, DOI 10.17487/RFC7977, September 2016, 834 . 836 Authors' Addresses 838 Keith Drage (editor) 839 Unaffiliated 841 Email: drageke@ntlworld.com 843 Maridi R. Makaraju (Raju) 844 Unaffiliated 846 Email: mmraju@gmail.com 848 Juergen Stoetzer-Bradler 849 Unaffiliated 851 Email: Juergen.S-B.ietf@email.de 852 Richard Ejzak 853 Unaffiliated 855 Email: richard.ejzak@gmail.com 857 Jerome Marcon 858 Unaffiliated 860 Jose M. Recio (editor) 862 Email: jose@ch3m4.com