idnits 2.17.1 draft-ietf-mmusic-msrp-usage-data-channel-09.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 12, 2018) is 2168 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-24 == Outdated reference: A later version (-28) exists of draft-ietf-mmusic-data-channel-sdpneg-17 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-37) exists of draft-ietf-mmusic-rfc4566bis-26 Summary: 1 error (**), 0 flaws (~~), 5 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: November 13, 2018 Nokia 6 J. Stoetzer-Bradler 7 R. Ejzak 8 J. Marcon 9 Unaffiliated 10 J. Recio, Ed. 11 CoSMo Software 12 May 12, 2018 14 MSRP over Data Channels 15 draft-ietf-mmusic-msrp-usage-data-channel-09 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 November 13, 2018. 44 Copyright Notice 46 Copyright (c) 2018 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-08' . . . . . . . . . . . . . . . . . . . . . . 12 90 10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data- 91 channel-07' . . . . . . . . . . . . . . . . . . . . . . 12 92 10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data- 93 channel-06' . . . . . . . . . . . . . . . . . . . . . . 13 94 10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data- 95 channel-05' . . . . . . . . . . . . . . . . . . . . . . 13 96 10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data- 97 channel-04' . . . . . . . . . . . . . . . . . . . . . . 13 98 10.6. Changes against 'draft-ietf-mmusic-msrp-usage-data- 99 channel-03' . . . . . . . . . . . . . . . . . . . . . . 13 100 10.7. Changes against 'draft-ietf-mmusic-msrp-usage-data- 101 channel-02' . . . . . . . . . . . . . . . . . . . . . . 13 102 10.8. Changes against 'draft-ietf-mmusic-msrp-usage-data- 103 channel-01' . . . . . . . . . . . . . . . . . . . . . . 14 104 10.9. Changes against 'draft-ietf-mmusic-msrp-usage-data- 105 channel-00' . . . . . . . . . . . . . . . . . . . . . . 15 106 10.10. Changes against 'draft-ejzak-mmusic-msrp-usage-data- 107 channel-01' . . . . . . . . . . . . . . . . . . . . . . 16 108 10.11. Changes against '-00' . . . . . . . . . . . . . . . . . 16 109 11. Normative References . . . . . . . . . . . . . . . . . . . . 16 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 112 1. Introduction 114 The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for 115 transmitting a series of related instant messages in the context of a 116 session. In addition to instant messaging, MSRP can also be used for 117 image sharing or file transfer. MSRP is currently defined to work 118 over TCP and TLS connections, and a WebSocket subprotocol specified 119 by [RFC4975]. 121 This document defines the negotiation and transport of this MSRP 122 protocol over data channels, where a data channel is a bi-directional 123 communication channel running on top of SCTP/DTLS (as per 124 [I-D.ietf-rtcweb-data-channel]) and where MSRP is instantiated as a 125 sub-protocol of this data channel. The MSRP protocol negotiation 126 defined in this document is based on the generic SDP offer/answer 127 exchange based data channel negotiation as specified in 128 [I-D.ietf-mmusic-data-channel-sdpneg]. 130 Defining MSRP as a data channel sub-protocol has many benefits: 132 o provides to applications a proven protocol enabling instant 133 messaging, file transfer, image sharing 135 o integrates those features with other RTCWeb voice, video and data 136 features 138 o leverages the SDP-based negotiation already defined for MSRP 140 o allows the interworking with MSRP endpoints running on a TCP or 141 TLS connection 143 Compared to WebSockets, that provide a message passing protocol to 144 applications with no direct access to TCP or TLS sockets, data 145 channels provide a low latency transport, leverage NAT-aware 146 connectivity and security features of WebRTC, and are increasingly 147 available not only in modern browsers but in other applications that 148 use WebRTC for media or other purposes (IoT or telemetry in general, 149 non-media data exchange, etc). 151 Considering an MSRP endpoint being an MSRP application that uses data 152 channel from WebRTC specifications [I-D.ietf-rtcweb-data-channel], 153 this document describes two configurations where the other endpoint 154 is respectively either another MSRP over data channel endpoint (e.g., 155 a WebRTC application) or an MSRP endpoint using either TCP or TLS 156 transport. 158 2. Conventions 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 3. Terminology 166 This document uses the following terms: 168 Data channel: A WebRTC data channel as specified in 169 [I-D.ietf-rtcweb-data-channel]. 171 MSRP data channel: A data channel specifically used to transport 172 the messages of one MSRP session. 174 External negotiation: Data channel negotiation based on out-of- 175 band or in-band mechanisms other than the Data Channel 176 Establishment Protocol specified in 177 [I-D.ietf-rtcweb-data-protocol]. 179 In-band: Transmission through the peer-to-peer SCTP association. 181 Out-of-band: Transmission through the call control signaling path, 182 e.g., using JSEP [I-D.ietf-rtcweb-jsep] and the SDP Offer/Answer 183 model [RFC3264]. 185 Peer: From the perspective of one of the agents in a session, its 186 peer is the other agent. Specifically, from the perspective of 187 the SDP offerer, the peer is the SDP answerer. From the 188 perspective of the SDP answerer, the peer is the SDP offerer. 190 4. Principles 192 4.1. MSRP Data Channel 194 In this document, an MSRP data channel is a data channel for which 195 the instantiated sub-protocol is "MSRP", and where the MSRP-related 196 negotiation is done as part of the SDP-based external negotiation 197 method defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 199 4.2. Session Mapping 201 In this design, the MSRP session maps to the SCTP association and the 202 "SCTP stream pair" assigned to the data channel, and each MSRP 203 session maps to one data channel exactly. 205 4.3. MSRP URI 207 This document extends the MSRP URI syntax [RFC4975] by defining the 208 new transport parameter value "dc": 210 transport /= "dc" / 1*ALPHANUM 211 ; Add "dc" to existing transports per [RFC4975] 213 MSRP design provides for new transport bindings, see Section 6 of 214 [RFC4975], MSRP implementations are expected to allow unrecognized 215 transports for which there is no need to establish a connection to 216 the resource described by the URI, as it's the case of data channels 217 (Section 5.1.2). 219 4.4. msrp-scheme 221 The msrp-scheme portion of the MSRP-URI that represents an MSRP data 222 channel endpoint (used in the SDP path attribute and in the MSRP 223 message headers) is always "msrps", which indicates that the MSRP 224 data channel is always secured using DTLS as described in 225 [I-D.ietf-rtcweb-data-channel]. 227 5. End-to-End Configuration 229 This section describes the network configuration where each MSRP 230 endpoint is running MSRP over a data channel. 232 5.1. Basic MSRP Support 233 5.1.1. Session Negotiation 235 5.1.1.1. Use of the dcmap Attribute 237 The SDP offer SHALL include a dcmap attribute line (defined in 238 [I-D.ietf-mmusic-data-channel-sdpneg]) within the media description 239 of the SCTP association for each MSRP data channel session to be 240 negotiated. 242 The attribute includes the following data channel parameters: 244 o "label=" labelstring 246 o "subprotocol=" "MSRP" 248 The labelstring is set by the MSRP application according to 249 [I-D.ietf-mmusic-data-channel-sdpneg]. Ordered and reliable data 250 channels MUST always be used, so that the "max-retr" and "max-time" 251 parameters SHALL NOT be used. If the "ordered" parameter is used, 252 then its value MUST be equal to "true". 254 Rest of the SDP offer/answer procedures are per 255 [I-D.ietf-mmusic-data-channel-sdpneg]. 257 The following is an example of the dcmap attribute for an MSRP 258 session to be negotiated with stream-id=2 and label="chat": 260 a=dcmap:2 label="chat";subprotocol="MSRP" 262 5.1.1.2. Use of the dcsa Attribute 264 The SDP offer SHALL also include within the media description for the 265 SCTP association, a dcsa attribute line (defined in 266 [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP 267 attribute to be negotiated for each MSRP data channel being 268 negotiated. 270 The MSRP-specific items that can be negotiated include at least all 271 of the following well-known attributes: 273 o defined in [RFC4975]: "path", "accept-types", "accept-wrapped- 274 types", "max-size" 276 o defined in [RFC4566]: "sendonly", "recvonly", "inactive", and 277 "sendrecv" 279 o defined in [RFC6135]: "setup" 280 o defined in [RFC6714]: "msrp-cema" 282 o defined in [RFC5547]: all the parameters related to MSRP file 283 transfer. See Section 5.2. 285 The msrp-cema attribute SHALL be assumed to be present for every MSRP 286 session using data channel transport, so the inclusion of the msrp- 287 cema attribute is OPTIONAL. This ensures that the data channel 288 transport for the MSRP session is established without using the path 289 attribute. 291 The SDP answer SHALL include zero or more corresponding dcsa 292 attribute lines for each negotiated MSRP session, according to the 293 MSRP-specific attribute negotiation rules in the corresponding 294 specifications. 296 A new SDP offer/answer MAY update the MSRP subprotocol attributes 297 while keeping the same subprotocol a=dcmap description. The 298 semantics for newly negotiated MSRP subprotocol attributes are per 299 [RFC4975]. 301 5.1.1.3. Use of the setup Attribute 303 A dsca embedded setup attribute, as defined in [RFC4145], MUST be 304 used for MSRP sessions over data channels. It is used to negotiate 305 which MSRP session endpoint assumes the active role as per 306 Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975]. It has no 307 relationship with the DTLS connection establishment roles. 309 The dcsa embedded setup attribute is of the form "a=dcsa:x 310 setup:", with x being the data channel's SCTP stream 311 identifier, so that such attribute is explicitly associated with an 312 MSRP session over a specific data channel. 314 It is considered an error if an MSRP over data channel description 315 does not contain a dcsa embedded setup attribute. 317 The SDP setup attribute can also be used in WebRTC data channel 318 related SDP media descriptions as a media level attribute, which is 319 associated with the corresponding UDP/DTLS/SCTP or TCP/DTLS/SCTP "m" 320 line. Such an "a=setup" attribute is used as specified in 321 [I-D.ietf-mmusic-sctp-sdp] in order to negotiate the establishment 322 roles of the DTLS connection and has no relationship with the MSRP 323 session. 325 5.1.1.4. Example SDP Negotiation 327 The following is an example of an "m" line for data channels in an 328 SDP offer that includes the attributes needed to establish two MSRP 329 sessions: one for chat and one for file transfer. The example is 330 derived from a combination of examples in [RFC4975] and [RFC5547]. 332 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 333 c=IN IP4 198.51.100.79 334 a=max-message-size:100000 335 a=sctp-port:5000 336 a=setup:actpass 337 a=fingerprint:SHA-1 \ 338 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 339 a=tls-id:4a756565cddef001be82 340 a=dcmap:0 label="chat";subprotocol="MSRP" 341 a=dcsa:0 setup:active 342 a=dcsa:0 accept-types:message/cpim text/plain 343 a=dcsa:0 path:msrps://bob.example.com:54111/si438dsaodes;dc 344 a=dcmap:2 label="file transfer";subprotocol="MSRP" 345 a=dcsa:2 sendonly 346 a=dcsa:2 setup:active 347 a=dcsa:2 accept-types:message/cpim 348 a=dcsa:2 accept-wrapped-types:* 349 a=dcsa:2 path:msrps://bob.example.com:54111/jshA7we;dc 350 a=dcsa:2 file-selector:name:"picture1.jpg" \ 351 type:image/jpeg size:1463440 hash:sha-1:\ 352 FF:27:0D:81:14:F1:8A:C3:35:3B:36:64:2A:62:C9:3E:D3:6B:51:B4 353 a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep 354 a=dcsa:2 file-disposition:attachment 355 a=dcsa:2 file-date:creation:"Mon, 12 Jan 2018 15:01:31 +0800" 356 a=dcsa:2 file-icon:cid:id2@bob.example.com 357 a=dcsa:2 file-range:1-1463440 359 5.1.2. Session Opening 361 Section 5.1.1.3 describes how the active MSRP session endpoint role 362 is negotiated. The active MSRP session endpoint does not use the 363 path attribute to open a transport connection to its peer. Instead, 364 it uses the data channel established for this MSRP session by the 365 generic data channel opening procedure defined in 366 [I-D.ietf-mmusic-data-channel-sdpneg]. 368 As soon as this data channel is opened, the MSRP session is actually 369 opened by the active MSRP session endpoint. In order to do this the 370 active MSRP endpoint sends an MSRP SEND message (empty or not) to the 371 other MSRP endpoint. The msrp-cema attribute is implicitly 372 associated with every MSRP session using data channel transport. 374 5.1.3. Data Framing 376 Each text-based MSRP message is sent on the corresponding SCTP stream 377 using standard MSRP framing and chunking procedures, as defined in 378 [RFC4975], with each MSRP chunk delivered in a single SCTP user 379 message. Therefore all sent MSRP chunks including the MSRP chunk 380 header MUST have lengths of less than or equal to the value of the 381 peer's "a=max-message-size" attribute, which is associated with the 382 data channel's SCTP association. 384 5.1.4. Data Sending and Reporting 386 Data sending and reporting procedures SHALL conform to RFC 4975. 388 5.1.5. Session Closing 390 The closure of an MSRP session MUST be signaled via an SDP offer/ 391 answer exchange which removes the "a=dcmap:" and "a=dcsa:" attribute 392 lines associated with the MSRP session from the associated DTLS/SCTP 393 based media description. This results in the associated data channel 394 being closed as well as per [I-D.ietf-mmusic-data-channel-sdpneg], 395 where the actual data channel closure procedure is typically 396 initiated by the SDP answerer right after having accepted the SDP 397 offer. 399 The port value for the "m" line SHOULD NOT be changed (e.g. to zero) 400 when closing an MSRP session (unless all data channels are being 401 closed and the SCTP association is no longer needed), since this 402 would close the SCTP association and impact all of the data channels. 403 In all cases in [RFC4975] where the procedure calls for setting the 404 port to zero for the MSRP "m" line in an SDP offer for TCP transport, 405 the SDP offerer of an MSRP session with data channel transport SHALL 406 remove the corresponding dcmap and dcsa attributes. 408 The SDP answerer must ensure that no dcmap or dcsa attributes are 409 present in the SDP answer if no corresponding attributes are present 410 in the received SDP offer. 412 5.2. Support for MSRP File Transfer Function 414 [RFC5547] defines an end-to-end file transfer method based on MSRP 415 and the SDP offer/answer mechanism. This file transfer method is 416 also usable by MSRP endpoints using data channels, with the following 417 considerations: 419 o As an MSRP session maps to one data channel, a file transfer 420 session maps also to one data channel. 422 o SDP attributes specified in [RFC5547] for a file transfer "m" line 423 are embedded as subprotocol-specific attributes using the syntax 424 defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 426 o Once the file transfer is complete, the same data channel MAY be 427 reused for another file transfer. 429 6. Gateway Configuration 431 This section describes the network configuration where one MSRP 432 endpoint uses data channels as MSRP transport, the other MSRP 433 endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP 434 endpoints interwork via an MSRP gateway. 436 Specifically, a gateway can be configured to interwork an MSRP 437 session over a data channel with a peer that does not support data 438 channel transport in one of two ways. 440 In one model, the gateway performs as a MSRP B2BUA to interwork all 441 the procedures as necessary between the endpoints. No further 442 specification is needed for this model. 444 Alternately, the gateway can use CEMA procedures to provide transport 445 level interworking between MSRP endpoints using different transport 446 protocols as follows. 448 When the gateway performs transport level interworking between MSRP 449 endpoints, all of the procedures in Section 5 apply to each peer, 450 with the following additions: 452 o The endpoint establishing an MSRP session using data channel 453 transport SHALL NOT request inclusion of any relays, although it 454 MAY interoperate with a peer that signals the use of relays. 456 o The gateway receiving an SDP offer that includes a request to 457 negotiate an MSRP session on a data channel can provide transport 458 level interworking by forwarding TCP or TLS transport parameters 459 in a new "m" line with the appropriate attributes within the 460 forwarded SDP offer. 462 * Especially, the gateway interworks the received MSRP over data 463 channel associated dcsa embedded setup attribute with the media 464 description level "a=setup" attribute of the MSRP over TCP or 465 TLS "m" line within its forwarded SDP offer. 467 o Similarly, a gateway receiving an SDP offer to negotiate an MSRP 468 session using TCP or TLS transport with an endpoint that only 469 supports data channel transport for MSRP can provide transport 470 level interworking by establishing a new data channel for the MSRP 471 session with the target endpoint. 473 * In this case the gateway interworks the received MSRP over TCP 474 or TLS associated "a=setup" attribute with the dcsa embedded 475 setup attribute of the generated MSRP over data channel 476 description. 478 7. IANA Considerations 480 7.1. Subprotocol Identifier MSRP 482 NOTE to RFC Editor: Please replace "XXXX" with the number of this 483 RFC. 485 This document adds the subprotocol identifier "MSRP" to the 486 "WebSocket Subprotocol Name Registry" as follows: 488 +--------------------------+---------+ 489 | Subprotocol Identifier: | MSRP | 490 | Subprotocol Common Name: | MSRP | 491 | Subprotocol Definition: | RFCXXXX | 492 | Reference: | RFCXXXX | 493 +--------------------------+---------+ 495 7.2. setup Attribute 497 NOTE to RFC Editor: Please replace "XXXX" with the number of this 498 RFC. 500 This document modifies the usage of the SDP setup attribute, if this 501 attribute is embedded in a dcsa attribute and associated with an MSRP 502 session over a data channel. The modified usage is described in 503 Section 5.1.1.3. 505 Usage level "dcsa(MSRP)" should be added to the IANA registration of 506 the SDP setup attribute as follows: 508 +-----------------------+-------------------------------------------+ 509 | Contact name: | MMUSIC Chairs | 510 | Contact email: | mmusic-chairs@ietf.org | 511 | Attribute name: | setup | 512 | Usage level: | dcsa(MSRP) | 513 | Purpose: | Negotiate the active role of an MSRP | 514 | | session over a data channel as per | 515 | | Section 5.1.1.3 | 516 | Reference: | RFCXXXX | 517 +-----------------------+-------------------------------------------+ 519 8. Security Considerations 521 MSRP traffic over data channels is secured, including 522 confidentiality, integrity and source authentication, as specified by 523 [I-D.ietf-rtcweb-data-channel] 525 Note that discussion in [RFC4975] on MSRP message attribution to 526 remote identities applies to data channel transport. 528 9. Acknowledgments 530 The authors wish to acknowledge the borrowing of ideas from another 531 internet draft by Peter Dunkley and Gavin Llewellyn, and to thank 532 Flemming Andreasen, Christian Groves, Christer Holmberg, Paul 533 Kyzivat, Jonathan Lennox, Uwe Rauschenbach, Albrecht Schwarz and 534 Keith Drage for their invaluable comments. 536 10. CHANGE LOG 538 10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-08' 540 o Updated reference to 4566bis. 542 o Expanded motivation paragraphs in introduction. 544 10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-07' 546 o Move security considerations after IANA considerations, following 547 RFC7322 suggested order. 549 o Update references to use xml.resource.org citation database. 551 o Reformat of the section discussing setup parameter 553 o Align examples with latest [I-D.ietf-mmusic-data-channel-sdpneg] 554 draft. 556 o Edit section 6 for clarity. 558 o Security requirements. 560 o Clarify comment on unrecognized transports and session opening. 562 o Update year, add editor. 564 10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-06' 566 o Modification of Keith's address information. 568 10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-05' 570 o Modification of Juergen's address information. 572 10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-04' 574 o Addition of [I-D.ietf-mmusic-rfc4566bis] to list of normative 575 references. 577 o Addition of Section 7.2 as per section 8.2.4 of 578 [I-D.ietf-mmusic-rfc4566bis]. 580 10.6. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-03' 582 o Addition of IANA registration related Section 7.1. 584 10.7. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-02' 586 o Addition of "a=setup:actpass", "a=connection:new", 587 "a=fingerprint:..." and "a=dcsa:x setup=active" SDP attributes to 588 the SDP example in Section 5.1.1.4. 590 o Addition of [RFC4145] and [I-D.ietf-mmusic-sctp-sdp] to list of 591 normative references. 593 o Addition of new Section 5.1.1.3 describing how the active MSRP 594 session endpoint role is negotiated. 596 o Extension of first paragraph of Section 5.1.2 with new first 597 sentence "Section 5.1.1.3 describes how the active MSRP session 598 endpoint role is negotiated.". 600 o First sentence of second paragraph in Section 5.1.2 was "As soon 601 as this data channel is opened, the MSRP session is actually 602 opened by the active MSRP endpoint which sends an MSRP SEND 603 message (empty or not) to the other MSRP endpoint." Replacement 604 of this sentence with "As soon as this data channel is opened, the 605 MSRP session is actually opened by the active MSRP endpoint. In 606 order to do this the active MSRP endpoint sends an MSRP SEND 607 message (empty or not) to the other MSRP endpoint." 609 o Addition of setup attribute specific behavior descriptions of data 610 channel to TCP or TLS interworking gateways in Section 6. 612 10.8. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-01' 614 o In the abstract replacement of the first sentence "This document 615 specifies how the Message Session Relay Protocol (MSRP) can be 616 instantiated as a data channel sub-protocol, using the SDP offer/ 617 answer exchange-based external negotiation defined in 618 [I-D.ietf-mmusic-data-channel-sdpneg]" with "This document 619 specifies how the Message Session Relay Protocol (MSRP) can be 620 instantiated as a data channel sub-protocol, using the SDP offer/ 621 answer exchange-based generic data channel negotiation framework" 622 in order to remove the reference from the abstract text. 624 o Addition of following sentence to the second paragraph in 625 Section 1: "The MSRP protocol negotiation defined in this document 626 is based on the generic SDP offer/answer exchange based data 627 channel negotiation as specified in 628 [I-D.ietf-mmusic-data-channel-sdpneg]". 630 o In Section 4.1 replacement of sub-protocol identifier "msrp" with 631 "MSRP" in order to make this consistent with the formal 632 specification in Section 5.1.1.1. 634 o Throughout the text replacement of "shall" with "SHALL" etc where 635 appropriate as per [RFC2119]. 637 o In Section 5.1.1.1 replacement of sentence 'The max-retr, max-time 638 and ordered parameters shall not be used.' with 'Ordered and 639 reliable data channels MUST always be used, such that the "max- 640 retr" and "max-time" parameters SHALL NOT be used. If the 641 "ordered" parameter is used, then its value MUST be equal to 642 "true".'. 644 o In Section 5.1.1.1 removal of "(on default SCTP port 5000)" from 645 the sentence preceding the example "a=dcmap" attribute line. 647 o In Section 5.1.1.2 first paragraph was "The SDP offer shall also 648 include a dcsa attribute line (defined in 649 [I-D.ietf-mmusic-data-channel-sdpneg]) within the media 650 description for the SCTP association for each MSRP-specific SDP 651 attribute to be negotiated for each MSRP data channel being 652 negotiated.". Replacement of this paragraph with "The SDP offer 653 SHALL also include within the media description for the SCTP 654 association a dcsa attribute line (defined in 655 [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP 656 attribute to be negotiated for each MSRP data channel being 657 negotiated.". 659 o Appended following sentence at the end of the first paragraph of 660 Section 5.1.3: "Therefore all sent MSRP chunks MUST have lengths 661 of less than or equal to the value of the peer's "a=max-message- 662 size" attribute, which is associated with the data channel's SCTP 663 association.". 665 o Addition of the previously missing colon to the "a=sctp-port" 666 attribute line in Section 5.1.1.4. 668 o In Section 5.1.5 replacement of the first paragraph "Closing of an 669 MSRP session is done using the generic data channel closing 670 procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]." with 671 'The closure of an MSRP session MUST be signaled via an SDP offer/ 672 answer exchange which removes the "a=dcmap:" and "a=dcsa:" 673 attribute lines associated with the MSRP session from the 674 associated DTLS/SCTP based media description. This results in the 675 associated data channel being closed as well as per 676 [I-D.ietf-mmusic-data-channel-sdpneg], where the actual data 677 channel closure procedure is typically initiated by the SDP 678 answerer right after having accepted the SDP offer.'. 680 10.9. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-00' 682 o Additional reference to [I-D.ietf-mmusic-data-channel-sdpneg] in 683 list of normative references. 685 o Replacement of previous document title "MSRP over SCTP/DTLS data 686 channels" with "MSRP over Data Channels" in order to align with 687 the terminology used in [I-D.ietf-mmusic-data-channel-sdpneg]. 689 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 690 channel consisting of paired SCTP outbound and inbound streams." 691 Replacement of this definition with "Data channel: A WebRTC data 692 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 693 consistent usage of either "data channel" or "MSRP data channel" 694 in the remainder of the document." 696 o In the introduction replacement of references to 697 [I-D.ietf-rtcweb-data-protocol] with a reference to 698 [I-D.ietf-rtcweb-data-channel]. 700 o Consistent usage of '"m" line' in whole document as per [RFC4566]. 702 o In the gateway configuration section (Section 6) replacement of 703 the first sentence "This section describes the network 704 configuration where one endpoint runs MSRP over a WebRTC SCTP/DTLS 705 connection, the other MSRP endpoint runs MSRP over one or more 706 TLS/TCP connections, and the two endpoints interwork via an MSRP 707 gateway" with "This section describes the network configuration 708 where one MSRP endpoint uses data channels as MSRP transport, the 709 other MSRP endpoint uses TLS/TCP connections as MSRP transport, 710 and the two MSRP endpoints interwork via an MSRP gateway". 712 10.10. Changes against 'draft-ejzak-mmusic-msrp-usage-data-channel-01' 714 o Removed empty spaces after ";" in the examples' "a=dcmap" 715 attribute lines. 717 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 718 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 719 replaced with "a=max-message-size" attribute lines, as per draft- 720 ietf-mmusic-sctp-sdp-12. 722 10.11. Changes against '-00' 724 o Transport parameter change for MSRP to allow MSRP RFC transports. 726 o Clarification on SDP offer/answer and removing duplicated 727 procedures and refer them to draft-ejzak-mmusic-data-channel- 728 sdpneg-02. 730 11. Normative References 732 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 733 Requirement Levels", BCP 14, RFC 2119, 734 DOI 10.17487/RFC2119, March 1997, 735 . 737 [I-D.ietf-rtcweb-jsep] 738 Uberti, J., Jennings, C., and E. Rescorla, "JavaScript 739 Session Establishment Protocol", draft-ietf-rtcweb-jsep-24 740 (work in progress), October 2017. 742 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 743 with Session Description Protocol (SDP)", RFC 3264, 744 DOI 10.17487/RFC3264, June 2002, 745 . 747 [I-D.ietf-rtcweb-data-protocol] 748 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 749 Establishment Protocol", draft-ietf-rtcweb-data- 750 protocol-09 (work in progress), January 2015. 752 [I-D.ietf-rtcweb-data-channel] 753 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 754 Channels", draft-ietf-rtcweb-data-channel-13 (work in 755 progress), January 2015. 757 [I-D.ietf-mmusic-data-channel-sdpneg] 758 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 759 Marcon, J., and R. Even, "SDP-based Data Channel 760 Negotiation", draft-ietf-mmusic-data-channel-sdpneg-17 761 (work in progress), April 2018. 763 [I-D.ietf-mmusic-sctp-sdp] 764 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 765 "Session Description Protocol (SDP) Offer/Answer 766 Procedures For Stream Control Transmission Protocol (SCTP) 767 over Datagram Transport Layer Security (DTLS) Transport.", 768 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 769 2017. 771 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 772 the Session Description Protocol (SDP)", RFC 4145, 773 DOI 10.17487/RFC4145, September 2005, 774 . 776 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 777 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 778 July 2006, . 780 [I-D.ietf-mmusic-rfc4566bis] 781 Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 782 Session Description Protocol", draft-ietf-mmusic- 783 rfc4566bis-26 (work in progress), May 2018. 785 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 786 "The Message Session Relay Protocol (MSRP)", RFC 4975, 787 DOI 10.17487/RFC4975, September 2007, 788 . 790 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 791 and P. Kyzivat, "A Session Description Protocol (SDP) 792 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 793 DOI 10.17487/RFC5547, May 2009, 794 . 796 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 797 for the Message Session Relay Protocol (MSRP)", RFC 6135, 798 DOI 10.17487/RFC6135, February 2011, 799 . 801 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 802 Establishment for Media Anchoring (CEMA) for the Message 803 Session Relay Protocol (MSRP)", RFC 6714, 804 DOI 10.17487/RFC6714, August 2012, 805 . 807 Authors' Addresses 809 Keith Drage (editor) 810 Unaffiliated 812 Email: drageke@ntlworld.com 814 Maridi R. Makaraju (Raju) 815 Nokia 816 2000 Lucent Lane 817 Naperville, Illinois 818 US 820 Email: Raju.Makaraju@nokia.com 822 Juergen Stoetzer-Bradler 823 Unaffiliated 825 Email: Juergen.S-B.ietf@email.de 827 Richard Ejzak 828 Unaffiliated 830 Email: richard.ejzak@gmail.com 832 Jerome Marcon 833 Unaffiliated 835 Jose M. Recio (editor) 836 CoSMo Software 838 Email: jose@ch3m4.com