idnits 2.17.1 draft-ietf-mmusic-msrp-usage-data-channel-10.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 (April 21, 2019) is 1832 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 (-28) exists of draft-ietf-mmusic-data-channel-sdpneg-25 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-37) exists of draft-ietf-mmusic-rfc4566bis-34 Summary: 1 error (**), 0 flaws (~~), 4 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 Unaffiliated 4 Intended status: Standards Track M. Makaraju 5 Expires: October 23, 2019 Nokia 6 J. Stoetzer-Bradler 7 R. Ejzak 8 J. Marcon 9 Unaffiliated 10 J. Recio, Ed. 11 CoSMo Software 12 April 21, 2019 14 MSRP over Data Channels 15 draft-ietf-mmusic-msrp-usage-data-channel-10 17 Abstract 19 This document specifies how the Message Session Relay Protocol (MSRP) 20 can be instantiated as a data channel sub-protocol, using the SDP 21 offer/answer exchange-based generic data channel negotiation 22 framework. Two network configurations are documented: a WebRTC end- 23 to-end configuration (connecting two MSRP over data channel 24 endpoints), and a gateway configuration (connecting an MSRP over data 25 channel endpoint with an MSRP over TCP or TLS endpoint). 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 23, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. MSRP Data Channel . . . . . . . . . . . . . . . . . . . . 5 66 4.2. Session Mapping . . . . . . . . . . . . . . . . . . . . . 5 67 4.3. MSRP URI . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.4. msrp-scheme . . . . . . . . . . . . . . . . . . . . . . . 5 69 5. End-to-End Configuration . . . . . . . . . . . . . . . . . . 5 70 5.1. Basic MSRP Support . . . . . . . . . . . . . . . . . . . 5 71 5.1.1. Session Negotiation . . . . . . . . . . . . . . . . . 6 72 5.1.1.1. Use of the dcmap Attribute . . . . . . . . . . . 6 73 5.1.1.2. Use of the dcsa Attribute . . . . . . . . . . . . 6 74 5.1.1.3. Use of the setup Attribute . . . . . . . . . . . 7 75 5.1.1.4. Example SDP Negotiation . . . . . . . . . . . . . 8 76 5.1.2. Session Opening . . . . . . . . . . . . . . . . . . . 8 77 5.1.3. Data Framing . . . . . . . . . . . . . . . . . . . . 9 78 5.1.4. Data Sending and Reporting . . . . . . . . . . . . . 9 79 5.1.5. Session Closing . . . . . . . . . . . . . . . . . . . 9 80 5.2. Support for MSRP File Transfer Function . . . . . . . . . 9 81 6. Gateway Configuration . . . . . . . . . . . . . . . . . . . . 10 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 7.1. Subprotocol Identifier MSRP . . . . . . . . . . . . . . . 11 84 7.2. setup Attribute . . . . . . . . . . . . . . . . . . . . . 11 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 87 10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data- 89 channel-09' . . . . . . . . . . . . . . . . . . . . . . 12 90 10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data- 91 channel-08' . . . . . . . . . . . . . . . . . . . . . . 12 92 10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data- 93 channel-07' . . . . . . . . . . . . . . . . . . . . . . 12 94 10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data- 95 channel-06' . . . . . . . . . . . . . . . . . . . . . . 13 96 10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data- 97 channel-05' . . . . . . . . . . . . . . . . . . . . . . 13 98 10.6. Changes against 'draft-ietf-mmusic-msrp-usage-data- 99 channel-04' . . . . . . . . . . . . . . . . . . . . . . 13 100 10.7. Changes against 'draft-ietf-mmusic-msrp-usage-data- 101 channel-03' . . . . . . . . . . . . . . . . . . . . . . 13 102 10.8. Changes against 'draft-ietf-mmusic-msrp-usage-data- 103 channel-02' . . . . . . . . . . . . . . . . . . . . . . 13 104 10.9. Changes against 'draft-ietf-mmusic-msrp-usage-data- 105 channel-01' . . . . . . . . . . . . . . . . . . . . . . 14 106 10.10. Changes against 'draft-ietf-mmusic-msrp-usage-data- 107 channel-00' . . . . . . . . . . . . . . . . . . . . . . 15 108 10.11. Changes against 'draft-ejzak-mmusic-msrp-usage-data- 109 channel-01' . . . . . . . . . . . . . . . . . . . . . . 16 110 10.12. Changes against '-00' . . . . . . . . . . . . . . . . . 16 111 11. Normative References . . . . . . . . . . . . . . . . . . . . 16 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 114 1. Introduction 116 The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for 117 transmitting a series of related instant messages in the context of a 118 session. In addition to instant messaging, MSRP can also be used for 119 image sharing or file transfer. MSRP is currently defined to work 120 over TCP and TLS connections, and a WebSocket subprotocol specified 121 by [RFC4975]. 123 This document defines the negotiation and transport of this MSRP 124 protocol over data channels, where a data channel is a bi-directional 125 communication channel running on top of SCTP/DTLS (as per 126 [I-D.ietf-rtcweb-data-channel]) and where MSRP is instantiated as a 127 sub-protocol of this data channel. The MSRP protocol negotiation 128 defined in this document is based on the generic SDP offer/answer 129 exchange based data channel negotiation as specified in 130 [I-D.ietf-mmusic-data-channel-sdpneg]. 132 Defining MSRP as a data channel sub-protocol has many benefits: 134 o provides to applications a proven protocol enabling instant 135 messaging, file transfer, image sharing 137 o integrates those features with other RTCWeb voice, video and data 138 features 140 o leverages the SDP-based negotiation already defined for MSRP 142 o allows the interworking with MSRP endpoints running on a TCP or 143 TLS connection 145 Compared to WebSockets, that provide a message passing protocol to 146 applications with no direct access to TCP or TLS sockets, data 147 channels provide a low latency transport, leverage NAT-aware 148 connectivity and security features of WebRTC, and are increasingly 149 available not only in modern browsers but in other applications that 150 use WebRTC for media or other purposes (IoT or telemetry in general, 151 non-media data exchange, etc). 153 Considering an MSRP endpoint being an MSRP application that uses data 154 channel from WebRTC specifications [I-D.ietf-rtcweb-data-channel], 155 this document describes two configurations where the other endpoint 156 is respectively either another MSRP over data channel endpoint (e.g., 157 a WebRTC application) or an MSRP endpoint using either TCP or TLS 158 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. Terminology 168 This document uses the following terms: 170 Data channel: A WebRTC data channel as specified in 171 [I-D.ietf-rtcweb-data-channel]. 173 MSRP data channel: A data channel specifically used to transport 174 the messages of one MSRP session. 176 External negotiation: Data channel negotiation based on out-of- 177 band or in-band mechanisms other than the Data Channel 178 Establishment Protocol specified in 179 [I-D.ietf-rtcweb-data-protocol]. 181 In-band: Transmission through the peer-to-peer SCTP association. 183 Out-of-band: Transmission through the call control signaling path, 184 e.g., using JSEP [I-D.ietf-rtcweb-jsep] and the SDP Offer/Answer 185 model [RFC3264]. 187 Peer: From the perspective of one of the agents in a session, its 188 peer is the other agent. Specifically, from the perspective of 189 the SDP offerer, the peer is the SDP answerer. From the 190 perspective of the SDP answerer, the peer is the SDP offerer. 192 4. Principles 194 4.1. MSRP Data Channel 196 In this document, an MSRP data channel is a data channel for which 197 the instantiated sub-protocol is "MSRP", and where the MSRP-related 198 negotiation is done as part of the SDP-based external negotiation 199 method defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 201 4.2. Session Mapping 203 In this design, the MSRP session maps to the SCTP association and the 204 "SCTP stream pair" assigned to the data channel, and each MSRP 205 session maps to one data channel exactly. 207 4.3. MSRP URI 209 This document extends the MSRP URI syntax [RFC4975] by defining the 210 new transport parameter value "dc": 212 transport /= "dc" / 1*ALPHANUM 213 ; Add "dc" to existing transports per [RFC4975] 215 MSRP design provides for new transport bindings, see Section 6 of 216 [RFC4975], MSRP implementations are expected to allow unrecognized 217 transports for which there is no need to establish a connection to 218 the resource described by the URI, as it's the case of data channels 219 (Section 5.1.2). 221 4.4. msrp-scheme 223 The msrp-scheme portion of the MSRP-URI that represents an MSRP data 224 channel endpoint (used in the SDP path attribute and in the MSRP 225 message headers) is always "msrps", which indicates that the MSRP 226 data channel is always secured using DTLS as described in 227 [I-D.ietf-rtcweb-data-channel]. 229 5. End-to-End Configuration 231 This section describes the network configuration where each MSRP 232 endpoint is running MSRP over a data channel. 234 5.1. Basic MSRP Support 235 5.1.1. Session Negotiation 237 5.1.1.1. Use of the dcmap Attribute 239 The SDP offer SHALL include a dcmap attribute line (defined in 240 [I-D.ietf-mmusic-data-channel-sdpneg]) within the media description 241 of the SCTP association for each MSRP data channel session to be 242 negotiated. 244 The attribute includes the following data channel parameters: 246 o "label=" labelstring 248 o "subprotocol=" "MSRP" 250 The labelstring is set by the MSRP application according to 251 [I-D.ietf-mmusic-data-channel-sdpneg]. Ordered and reliable data 252 channels MUST always be used, so that the "max-retr" and "max-time" 253 parameters SHALL NOT be used. If the "ordered" parameter is used, 254 then its value MUST be equal to "true". 256 Rest of the SDP offer/answer procedures are per 257 [I-D.ietf-mmusic-data-channel-sdpneg]. 259 The following is an example of the dcmap attribute for an MSRP 260 session to be negotiated with stream-id=2 and label="chat": 262 a=dcmap:2 label="chat";subprotocol="MSRP" 264 5.1.1.2. Use of the dcsa Attribute 266 The SDP offer SHALL also include within the media description for the 267 SCTP association, a dcsa attribute line (defined in 268 [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP 269 attribute to be negotiated for each MSRP data channel being 270 negotiated. 272 The MSRP-specific items that can be negotiated include at least all 273 of the following well-known attributes: 275 o defined in [RFC4975]: "path", "accept-types", "accept-wrapped- 276 types", "max-size" 278 o defined in [RFC4566]: "sendonly", "recvonly", "inactive", and 279 "sendrecv" 281 o defined in [RFC6135]: "setup" 282 o defined in [RFC6714]: "msrp-cema" 284 o defined in [RFC5547]: all the parameters related to MSRP file 285 transfer. See Section 5.2. 287 The msrp-cema attribute SHALL be assumed to be present for every MSRP 288 session using data channel transport, so the inclusion of the msrp- 289 cema attribute is OPTIONAL. This ensures that the data channel 290 transport for the MSRP session is established without using the path 291 attribute. 293 The SDP answer SHALL include zero or more corresponding dcsa 294 attribute lines for each negotiated MSRP session, according to the 295 MSRP-specific attribute negotiation rules in the corresponding 296 specifications. 298 A new SDP offer/answer MAY update the MSRP subprotocol attributes 299 while keeping the same subprotocol a=dcmap description. The 300 semantics for newly negotiated MSRP subprotocol attributes are per 301 [RFC4975]. 303 5.1.1.3. Use of the setup Attribute 305 A dsca embedded setup attribute, as defined in [RFC4145], MUST be 306 used for MSRP sessions over data channels. It is used to negotiate 307 which MSRP session endpoint assumes the active role as per 308 Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975]. It has no 309 relationship with the DTLS connection establishment roles. 311 The dcsa embedded setup attribute is of the form "a=dcsa:x 312 setup:", with x being the data channel's SCTP stream 313 identifier, so that such attribute is explicitly associated with an 314 MSRP session over a specific data channel. 316 It is considered an error if an MSRP over data channel description 317 does not contain a dcsa embedded setup attribute. 319 The SDP setup attribute can also be used in WebRTC data channel 320 related SDP media descriptions as a media level attribute, which is 321 associated with the corresponding UDP/DTLS/SCTP or TCP/DTLS/SCTP "m" 322 line. Such an "a=setup" attribute is used as specified in 323 [I-D.ietf-mmusic-sctp-sdp] in order to negotiate the establishment 324 roles of the DTLS connection and has no relationship with the MSRP 325 session. 327 5.1.1.4. Example SDP Negotiation 329 The following is an example of an "m" line for data channels in an 330 SDP offer that includes the attributes needed to establish two MSRP 331 sessions: one for chat and one for file transfer. The example is 332 derived from a combination of examples in [RFC4975] and [RFC5547]. 334 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 335 c=IN IP4 198.51.100.79 336 a=max-message-size:100000 337 a=sctp-port:5000 338 a=setup:actpass 339 a=fingerprint:SHA-1 \ 340 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 341 a=tls-id:4a756565cddef001be82 342 a=dcmap:0 label="chat";subprotocol="MSRP" 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 setup:active 349 a=dcsa:2 accept-types:message/cpim 350 a=dcsa:2 accept-wrapped-types:* 351 a=dcsa:2 path:msrps://bob.example.com:54111/jshA7we;dc 352 a=dcsa:2 file-selector:name:"picture1.jpg" \ 353 type:image/jpeg size:1463440 hash:sha-1:\ 354 FF:27:0D:81:14:F1:8A:C3:35:3B:36:64:2A:62:C9:3E:D3:6B:51:B4 355 a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep 356 a=dcsa:2 file-disposition:attachment 357 a=dcsa:2 file-date:creation:"Mon, 12 Jan 2018 15:01:31 +0800" 358 a=dcsa:2 file-icon:cid:id2@bob.example.com 359 a=dcsa:2 file-range:1-1463440 361 5.1.2. Session Opening 363 Section 5.1.1.3 describes how the active MSRP session endpoint role 364 is negotiated. The active MSRP session endpoint does not use the 365 path attribute to open a transport connection to its peer. Instead, 366 it uses the data channel established for this MSRP session by the 367 generic data channel opening procedure defined in 368 [I-D.ietf-mmusic-data-channel-sdpneg]. 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. The msrp-cema attribute is implicitly 374 associated with every MSRP session using data channel transport. 376 5.1.3. Data Framing 378 Each text-based MSRP message is sent on the corresponding SCTP stream 379 using standard MSRP framing and chunking procedures, as defined in 380 [RFC4975], with each MSRP chunk delivered in a single SCTP user 381 message. Therefore all sent MSRP chunks including the MSRP chunk 382 header MUST have lengths of less than or equal to the value of the 383 peer's "a=max-message-size" attribute, which is associated with the 384 data channel's SCTP association. 386 5.1.4. Data Sending and Reporting 388 Data sending and reporting procedures SHALL conform to RFC 4975. 390 5.1.5. Session Closing 392 The closure of an MSRP session MUST be signaled via an SDP offer/ 393 answer exchange which removes the "a=dcmap:" and "a=dcsa:" attribute 394 lines associated with the MSRP session from the associated DTLS/SCTP 395 based media description. This results in the associated data channel 396 being closed as well as per [I-D.ietf-mmusic-data-channel-sdpneg], 397 where the actual data channel closure procedure is typically 398 initiated by the SDP answerer right after having accepted the SDP 399 offer. 401 The port value for the "m" line SHOULD NOT be changed (e.g. to zero) 402 when closing an MSRP session (unless all data channels are being 403 closed and the SCTP association is no longer needed), since this 404 would close the SCTP association and impact all of the data channels. 405 In all cases in [RFC4975] where the procedure calls for setting the 406 port to zero for the MSRP "m" line in an SDP offer for TCP transport, 407 the SDP offerer of an MSRP session with data channel transport SHALL 408 remove the corresponding dcmap and dcsa attributes. 410 The SDP answerer must ensure that no dcmap or dcsa attributes are 411 present in the SDP answer if no corresponding attributes are present 412 in the received SDP offer. 414 5.2. Support for MSRP File Transfer Function 416 [RFC5547] defines an end-to-end file transfer method based on MSRP 417 and the SDP offer/answer mechanism. This file transfer method is 418 also usable by MSRP endpoints using data channels, with the following 419 considerations: 421 o As an MSRP session maps to one data channel, a file transfer 422 session maps also to one data channel. 424 o SDP attributes specified in [RFC5547] for a file transfer "m" line 425 are embedded as subprotocol-specific attributes using the syntax 426 defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 428 o Once the file transfer is complete, the same data channel MAY be 429 reused for another file transfer. 431 6. Gateway Configuration 433 This section describes the network configuration where one MSRP 434 endpoint uses data channels as MSRP transport, the other MSRP 435 endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP 436 endpoints interwork via an MSRP gateway. 438 Specifically, a gateway can be configured to interwork an MSRP 439 session over a data channel with a peer that does not support data 440 channel transport in one of two ways. 442 In one model, the gateway performs as a MSRP B2BUA to interwork all 443 the procedures as necessary between the endpoints. No further 444 specification is needed for this model. 446 Alternately, the gateway can use CEMA procedures to provide transport 447 level interworking between MSRP endpoints using different transport 448 protocols as follows. 450 When the gateway performs transport level interworking between MSRP 451 endpoints, all of the procedures in Section 5 apply to each peer, 452 with the following additions: 454 o The endpoint establishing an MSRP session using data channel 455 transport SHALL NOT request inclusion of any relays, although it 456 MAY interoperate with a peer that signals the use of relays. 458 o The gateway receiving an SDP offer that includes a request to 459 negotiate an MSRP session on a data channel can provide transport 460 level interworking by forwarding TCP or TLS transport parameters 461 in a new "m" line with the appropriate attributes within the 462 forwarded SDP offer. 464 * Especially, the gateway interworks the received MSRP over data 465 channel associated dcsa embedded setup attribute with the media 466 description level "a=setup" attribute of the MSRP over TCP or 467 TLS "m" line within its forwarded SDP offer. 469 o Similarly, a gateway receiving an SDP offer to negotiate an MSRP 470 session using TCP or TLS transport with an endpoint that only 471 supports data channel transport for MSRP can provide transport 472 level interworking by establishing a new data channel for the MSRP 473 session with the target endpoint. 475 * In this case the gateway interworks the received MSRP over TCP 476 or TLS associated "a=setup" attribute with the dcsa embedded 477 setup attribute of the generated MSRP over data channel 478 description. 480 7. IANA Considerations 482 7.1. Subprotocol Identifier MSRP 484 NOTE to RFC Editor: Please replace "XXXX" with the number of this 485 RFC. 487 This document adds the subprotocol identifier "MSRP" to the 488 "WebSocket Subprotocol Name Registry" as follows: 490 +--------------------------+---------+ 491 | Subprotocol Identifier: | MSRP | 492 | Subprotocol Common Name: | MSRP | 493 | Subprotocol Definition: | RFCXXXX | 494 | Reference: | RFCXXXX | 495 +--------------------------+---------+ 497 7.2. setup Attribute 499 NOTE to RFC Editor: Please replace "XXXX" with the number of this 500 RFC. 502 This document modifies the usage of the SDP setup attribute, if this 503 attribute is embedded in a dcsa attribute and associated with an MSRP 504 session over a data channel. The modified usage is described in 505 Section 5.1.1.3. 507 Usage level "dcsa(MSRP)" should be added to the IANA registration of 508 the SDP setup attribute as follows: 510 +-----------------------+-------------------------------------------+ 511 | Contact name: | MMUSIC Chairs | 512 | Contact email: | mmusic-chairs@ietf.org | 513 | Attribute name: | setup | 514 | Usage level: | dcsa(MSRP) | 515 | Purpose: | Negotiate the active role of an MSRP | 516 | | session over a data channel as per | 517 | | Section 5.1.1.3 | 518 | Reference: | RFCXXXX | 519 +-----------------------+-------------------------------------------+ 521 8. Security Considerations 523 MSRP traffic over data channels is secured, including 524 confidentiality, integrity and source authentication, as specified by 525 [I-D.ietf-rtcweb-data-channel] 527 Note that discussion in [RFC4975] on MSRP message attribution to 528 remote identities applies to data channel transport. 530 9. Acknowledgments 532 The authors wish to acknowledge the borrowing of ideas from another 533 internet draft by Peter Dunkley and Gavin Llewellyn, and to thank 534 Flemming Andreasen, Christian Groves, Christer Holmberg, Paul 535 Kyzivat, Jonathan Lennox, Uwe Rauschenbach, Albrecht Schwarz and 536 Keith Drage for their invaluable comments. 538 10. CHANGE LOG 540 10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-09' 542 o Corrected area to ART. 544 10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-08' 546 o Updated reference to 4566bis. 548 o Expanded motivation paragraphs in introduction. 550 10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-07' 552 o Move security considerations after IANA considerations, following 553 RFC7322 suggested order. 555 o Update references to use xml.resource.org citation database. 557 o Reformat of the section discussing setup parameter 559 o Align examples with latest [I-D.ietf-mmusic-data-channel-sdpneg] 560 draft. 562 o Edit section 6 for clarity. 564 o Security requirements. 566 o Clarify comment on unrecognized transports and session opening. 568 o Update year, add editor. 570 10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-06' 572 o Modification of Keith's address information. 574 10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-05' 576 o Modification of Juergen's address information. 578 10.6. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-04' 580 o Addition of [I-D.ietf-mmusic-rfc4566bis] to list of normative 581 references. 583 o Addition of Section 7.2 as per section 8.2.4 of 584 [I-D.ietf-mmusic-rfc4566bis]. 586 10.7. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-03' 588 o Addition of IANA registration related Section 7.1. 590 10.8. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-02' 592 o Addition of "a=setup:actpass", "a=connection:new", 593 "a=fingerprint:..." and "a=dcsa:x setup=active" SDP attributes to 594 the SDP example in Section 5.1.1.4. 596 o Addition of [RFC4145] and [I-D.ietf-mmusic-sctp-sdp] to list of 597 normative references. 599 o Addition of new Section 5.1.1.3 describing how the active MSRP 600 session endpoint role is negotiated. 602 o Extension of first paragraph of Section 5.1.2 with new first 603 sentence "Section 5.1.1.3 describes how the active MSRP session 604 endpoint role is negotiated.". 606 o First sentence of second paragraph in Section 5.1.2 was "As soon 607 as this data channel is opened, the MSRP session is actually 608 opened by the active MSRP endpoint which sends an MSRP SEND 609 message (empty or not) to the other MSRP endpoint." Replacement 610 of this sentence with "As soon as this data channel is opened, the 611 MSRP session is actually opened by the active MSRP endpoint. In 612 order to do this the active MSRP endpoint sends an MSRP SEND 613 message (empty or not) to the other MSRP endpoint." 615 o Addition of setup attribute specific behavior descriptions of data 616 channel to TCP or TLS interworking gateways in Section 6. 618 10.9. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-01' 620 o In the abstract replacement of the first sentence "This document 621 specifies how the Message Session Relay Protocol (MSRP) can be 622 instantiated as a data channel sub-protocol, using the SDP offer/ 623 answer exchange-based external negotiation defined in 624 [I-D.ietf-mmusic-data-channel-sdpneg]" with "This document 625 specifies how the Message Session Relay Protocol (MSRP) can be 626 instantiated as a data channel sub-protocol, using the SDP offer/ 627 answer exchange-based generic data channel negotiation framework" 628 in order to remove the reference from the abstract text. 630 o Addition of following sentence to the second paragraph in 631 Section 1: "The MSRP protocol negotiation defined in this document 632 is based on the generic SDP offer/answer exchange based data 633 channel negotiation as specified in 634 [I-D.ietf-mmusic-data-channel-sdpneg]". 636 o In Section 4.1 replacement of sub-protocol identifier "msrp" with 637 "MSRP" in order to make this consistent with the formal 638 specification in Section 5.1.1.1. 640 o Throughout the text replacement of "shall" with "SHALL" etc where 641 appropriate as per [RFC2119]. 643 o In Section 5.1.1.1 replacement of sentence 'The max-retr, max-time 644 and ordered parameters shall not be used.' with 'Ordered and 645 reliable data channels MUST always be used, such that the "max- 646 retr" and "max-time" parameters SHALL NOT be used. If the 647 "ordered" parameter is used, then its value MUST be equal to 648 "true".'. 650 o In Section 5.1.1.1 removal of "(on default SCTP port 5000)" from 651 the sentence preceding the example "a=dcmap" attribute line. 653 o In Section 5.1.1.2 first paragraph was "The SDP offer shall also 654 include a dcsa attribute line (defined in 655 [I-D.ietf-mmusic-data-channel-sdpneg]) within the media 656 description for the SCTP association for each MSRP-specific SDP 657 attribute to be negotiated for each MSRP data channel being 658 negotiated.". Replacement of this paragraph with "The SDP offer 659 SHALL also include within the media description for the SCTP 660 association a dcsa attribute line (defined in 661 [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP 662 attribute to be negotiated for each MSRP data channel being 663 negotiated.". 665 o Appended following sentence at the end of the first paragraph of 666 Section 5.1.3: "Therefore all sent MSRP chunks MUST have lengths 667 of less than or equal to the value of the peer's "a=max-message- 668 size" attribute, which is associated with the data channel's SCTP 669 association.". 671 o Addition of the previously missing colon to the "a=sctp-port" 672 attribute line in Section 5.1.1.4. 674 o In Section 5.1.5 replacement of the first paragraph "Closing of an 675 MSRP session is done using the generic data channel closing 676 procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]." with 677 'The closure of an MSRP session MUST be signaled via an SDP offer/ 678 answer exchange which removes the "a=dcmap:" and "a=dcsa:" 679 attribute lines associated with the MSRP session from the 680 associated DTLS/SCTP based media description. This results in the 681 associated data channel being closed as well as per 682 [I-D.ietf-mmusic-data-channel-sdpneg], where the actual data 683 channel closure procedure is typically initiated by the SDP 684 answerer right after having accepted the SDP offer.'. 686 10.10. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-00' 688 o Additional reference to [I-D.ietf-mmusic-data-channel-sdpneg] in 689 list of normative references. 691 o Replacement of previous document title "MSRP over SCTP/DTLS data 692 channels" with "MSRP over Data Channels" in order to align with 693 the terminology used in [I-D.ietf-mmusic-data-channel-sdpneg]. 695 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 696 channel consisting of paired SCTP outbound and inbound streams." 697 Replacement of this definition with "Data channel: A WebRTC data 698 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 699 consistent usage of either "data channel" or "MSRP data channel" 700 in the remainder of the document." 702 o In the introduction replacement of references to 703 [I-D.ietf-rtcweb-data-protocol] with a reference to 704 [I-D.ietf-rtcweb-data-channel]. 706 o Consistent usage of '"m" line' in whole document as per [RFC4566]. 708 o In the gateway configuration section (Section 6) replacement of 709 the first sentence "This section describes the network 710 configuration where one endpoint runs MSRP over a WebRTC SCTP/DTLS 711 connection, the other MSRP endpoint runs MSRP over one or more 712 TLS/TCP connections, and the two endpoints interwork via an MSRP 713 gateway" with "This section describes the network configuration 714 where one MSRP endpoint uses data channels as MSRP transport, the 715 other MSRP endpoint uses TLS/TCP connections as MSRP transport, 716 and the two MSRP endpoints interwork via an MSRP gateway". 718 10.11. Changes against 'draft-ejzak-mmusic-msrp-usage-data-channel-01' 720 o Removed empty spaces after ";" in the examples' "a=dcmap" 721 attribute lines. 723 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 724 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 725 replaced with "a=max-message-size" attribute lines, as per draft- 726 ietf-mmusic-sctp-sdp-12. 728 10.12. Changes against '-00' 730 o Transport parameter change for MSRP to allow MSRP RFC transports. 732 o Clarification on SDP offer/answer and removing duplicated 733 procedures and refer them to draft-ejzak-mmusic-data-channel- 734 sdpneg-02. 736 11. Normative References 738 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 739 Requirement Levels", BCP 14, RFC 2119, 740 DOI 10.17487/RFC2119, March 1997, 741 . 743 [I-D.ietf-rtcweb-jsep] 744 Uberti, J., Jennings, C., and E. Rescorla, "JavaScript 745 Session Establishment Protocol", draft-ietf-rtcweb-jsep-26 746 (work in progress), February 2019. 748 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 749 with Session Description Protocol (SDP)", RFC 3264, 750 DOI 10.17487/RFC3264, June 2002, 751 . 753 [I-D.ietf-rtcweb-data-protocol] 754 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 755 Establishment Protocol", draft-ietf-rtcweb-data- 756 protocol-09 (work in progress), January 2015. 758 [I-D.ietf-rtcweb-data-channel] 759 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 760 Channels", draft-ietf-rtcweb-data-channel-13 (work in 761 progress), January 2015. 763 [I-D.ietf-mmusic-data-channel-sdpneg] 764 Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. 765 Even, "SDP-based Data Channel Negotiation", draft-ietf- 766 mmusic-data-channel-sdpneg-25 (work in progress), March 767 2019. 769 [I-D.ietf-mmusic-sctp-sdp] 770 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 771 "Session Description Protocol (SDP) Offer/Answer 772 Procedures For Stream Control Transmission Protocol (SCTP) 773 over Datagram Transport Layer Security (DTLS) Transport.", 774 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 775 2017. 777 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 778 the Session Description Protocol (SDP)", RFC 4145, 779 DOI 10.17487/RFC4145, September 2005, 780 . 782 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 783 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 784 July 2006, . 786 [I-D.ietf-mmusic-rfc4566bis] 787 Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 788 Session Description Protocol", draft-ietf-mmusic- 789 rfc4566bis-34 (work in progress), March 2019. 791 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 792 "The Message Session Relay Protocol (MSRP)", RFC 4975, 793 DOI 10.17487/RFC4975, September 2007, 794 . 796 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 797 and P. Kyzivat, "A Session Description Protocol (SDP) 798 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 799 DOI 10.17487/RFC5547, May 2009, 800 . 802 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 803 for the Message Session Relay Protocol (MSRP)", RFC 6135, 804 DOI 10.17487/RFC6135, February 2011, 805 . 807 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 808 Establishment for Media Anchoring (CEMA) for the Message 809 Session Relay Protocol (MSRP)", RFC 6714, 810 DOI 10.17487/RFC6714, August 2012, 811 . 813 Authors' Addresses 815 Keith Drage (editor) 816 Unaffiliated 818 Email: drageke@ntlworld.com 820 Maridi R. Makaraju (Raju) 821 Nokia 822 2000 Lucent Lane 823 Naperville, Illinois 824 US 826 Email: Raju.Makaraju@nokia.com 828 Juergen Stoetzer-Bradler 829 Unaffiliated 831 Email: Juergen.S-B.ietf@email.de 833 Richard Ejzak 834 Unaffiliated 836 Email: richard.ejzak@gmail.com 838 Jerome Marcon 839 Unaffiliated 841 Jose M. Recio (editor) 842 CoSMo Software 844 Email: jose@ch3m4.com