idnits 2.17.1 draft-ietf-mmusic-msrp-usage-data-channel-17.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4975]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The abstract seems to indicate that this document updates RFC4975, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 29, 2020) is 1428 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: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC J. Recio, Ed. 3 Internet-Draft Unaffiliated 4 Intended status: Standards Track C. Holmberg 5 Expires: November 30, 2020 Ericsson 6 May 29, 2020 8 MSRP over Data Channels 9 draft-ietf-mmusic-msrp-usage-data-channel-17 11 Abstract 13 This document specifies how the Message Session Relay Protocol (MSRP) 14 can be transported as a WebRTC data channel sub-protocol, using the 15 SDP offer/answer generic data channel negotiation framework to 16 establish such a channel. Two network configurations are supported: 17 connecting two MSRP over data channel endpoints; and a gateway 18 configuration, connecting an MSRP over data channel endpoint with an 19 MSRP over TCP or TLS endpoint. This document updates [RFC4975] 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 30, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. WebRTC Data Channel Considerations . . . . . . . . . . . . . 4 58 3.1. MSRP Data Channel . . . . . . . . . . . . . . . . . . . . 4 59 4. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. MSRP URI . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. msrp-scheme . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.3. Use of the dcmap Attribute . . . . . . . . . . . . . . . 5 63 4.4. Use of the dcsa Attribute . . . . . . . . . . . . . . . . 6 64 4.5. Use of the dcsa embedded setup Attribute . . . . . . . . 7 65 4.6. Session Closing . . . . . . . . . . . . . . . . . . . . . 7 66 4.7. Support for MSRP File Transfer Function . . . . . . . . . 7 67 4.8. Example SDP Negotiation . . . . . . . . . . . . . . . . . 8 68 5. MSRP Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 5.1. Session Mapping . . . . . . . . . . . . . . . . . . . . . 8 70 5.2. Session Opening . . . . . . . . . . . . . . . . . . . . . 9 71 5.3. Session Closing . . . . . . . . . . . . . . . . . . . . . 9 72 5.4. Data Framing . . . . . . . . . . . . . . . . . . . . . . 9 73 5.5. Data Sending, Receiving and Reporting . . . . . . . . . . 9 74 5.6. Support for MSRP File Transfer Function . . . . . . . . . 9 75 6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 10 76 7. Updates to RFC4975 . . . . . . . . . . . . . . . . . . . . . 10 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 9.1. msrps URI scheme . . . . . . . . . . . . . . . . . . . . 11 80 9.2. Subprotocol Identifier MSRP . . . . . . . . . . . . . . . 11 81 9.3. setup Attribute . . . . . . . . . . . . . . . . . . . . . 11 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 83 11. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 11.1. Changes against 'draft-ietf-mmusic-msrp-usage-data- 85 channel-16' . . . . . . . . . . . . . . . . . . . . . . 12 86 11.2. Changes against 'draft-ietf-mmusic-msrp-usage-data- 87 channel-15' . . . . . . . . . . . . . . . . . . . . . . 12 88 11.3. Changes against 'draft-ietf-mmusic-msrp-usage-data- 89 channel-14' . . . . . . . . . . . . . . . . . . . . . . 12 90 11.4. Changes against 'draft-ietf-mmusic-msrp-usage-data- 91 channel-13' . . . . . . . . . . . . . . . . . . . . . . 12 92 11.5. Changes against 'draft-ietf-mmusic-msrp-usage-data- 93 channel-12' . . . . . . . . . . . . . . . . . . . . . . 12 94 11.6. Changes against 'draft-ietf-mmusic-msrp-usage-data- 95 channel-11' . . . . . . . . . . . . . . . . . . . . . . 13 96 11.7. Changes against 'draft-ietf-mmusic-msrp-usage-data- 97 channel-10' . . . . . . . . . . . . . . . . . . . . . . 13 98 11.8. Changes against 'draft-ietf-mmusic-msrp-usage-data- 99 channel-09' . . . . . . . . . . . . . . . . . . . . . . 13 100 11.9. Changes against 'draft-ietf-mmusic-msrp-usage-data- 101 channel-08' . . . . . . . . . . . . . . . . . . . . . . 13 102 11.10. Changes against 'draft-ietf-mmusic-msrp-usage-data- 103 channel-07' . . . . . . . . . . . . . . . . . . . . . . 13 104 11.11. Changes against 'draft-ietf-mmusic-msrp-usage-data- 105 channel-06' . . . . . . . . . . . . . . . . . . . . . . 13 106 11.12. Changes against 'draft-ietf-mmusic-msrp-usage-data- 107 channel-05' . . . . . . . . . . . . . . . . . . . . . . 14 108 11.13. Changes against 'draft-ietf-mmusic-msrp-usage-data- 109 channel-04' . . . . . . . . . . . . . . . . . . . . . . 14 110 11.14. Changes against 'draft-ietf-mmusic-msrp-usage-data- 111 channel-03' . . . . . . . . . . . . . . . . . . . . . . 14 112 11.15. Changes against 'draft-ietf-mmusic-msrp-usage-data- 113 channel-02' . . . . . . . . . . . . . . . . . . . . . . 14 114 11.16. Changes against 'draft-ietf-mmusic-msrp-usage-data- 115 channel-01' . . . . . . . . . . . . . . . . . . . . . . 15 116 11.17. Changes against 'draft-ietf-mmusic-msrp-usage-data- 117 channel-00' . . . . . . . . . . . . . . . . . . . . . . 16 118 11.18. Changes against 'draft-ejzak-mmusic-msrp-usage-data- 119 channel-01' . . . . . . . . . . . . . . . . . . . . . . 17 120 11.19. Changes against '-00' . . . . . . . . . . . . . . . . . 17 121 12. Normative References . . . . . . . . . . . . . . . . . . . . 17 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 124 1. Introduction 126 The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for 127 transmitting a series of related instant messages in the context of a 128 session. In addition to instant messaging, MSRP can also be used for 129 image sharing or file transfer. MSRP was initially defined in 130 [RFC4975] to work over TCP and TLS connections, and over a WebSocket 131 subprotocol specified by [RFC7977]. 133 This document specifies the negotiation and transport of MSRP over a 134 WebRTC data channel [I-D.ietf-rtcweb-data-channel]. Negotiation is 135 carried out as specified in [I-D.ietf-mmusic-data-channel-sdpneg] and 136 MSRP is transported as a sub-protocol of a WebRTC data channel, 137 without the TCP and TLS layers. 139 Defining MSRP as a data channel sub-protocol has many benefits: 141 o provides to applications a proven protocol enabling instant 142 messaging, file transfer, image sharing 144 o integrates those features with other WebRTC voice, video and data 145 features 147 o leverages the SDP-based negotiation already defined for MSRP 149 o allows the interworking with MSRP endpoints running on a TCP or 150 TLS connection 152 Compared to WebSockets, which provide a message passing protocol to 153 applications with no direct access to TCP or TLS sockets, data 154 channels provide a low latency transport, leverage NAT-aware 155 connectivity and security features of WebRTC, and are increasingly 156 available not only in modern browsers but in other applications that 157 use WebRTC for media or other purposes, such as IoT or telemetry in 158 general, non-media data exchange, and so on. 160 Considering an MSRP endpoint as an MSRP application that uses a 161 WebRTC data channel, this document describes two configurations where 162 the other endpoint is respectively either another MSRP over data 163 channel endpoint (e.g., a WebRTC application) or an MSRP endpoint 164 using either TCP or TLS transport. 166 2. Conventions 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [RFC2119]. 172 3. WebRTC Data Channel Considerations 174 3.1. MSRP Data Channel 176 In this document, an MSRP data channel is a data channel for which 177 the instantiated sub-protocol is "MSRP", and where the channel is 178 negotiated using the SDP-based external negotiation method defined in 179 [I-D.ietf-mmusic-data-channel-sdpneg]. 181 The following WebRTC data channel property values 182 [I-D.ietf-rtcweb-data-channel] apply to a MSRP data channel: 184 +--------------------------+---------------------------------+ 185 | Property | Value | 186 +--------------------------+---------------------------------+ 187 | Subprotocol Identifier | msrp | 188 | Transmission reliability | reliable | 189 | Transmission order | in-order | 190 | Label | See Section 4.3 | 191 +--------------------------+---------------------------------+ 193 4. SDP Considerations 195 This section describes the SDP considerations which are specific to a 196 MSRP data channel 198 4.1. MSRP URI 200 This document extends the MSRP URI syntax [RFC4975] by defining the 201 new transport parameter value "dc": 203 transport /= "dc" 204 ; Add "dc" to existing transports per [RFC4975] 206 MSRP design provides for new transport bindings, see Section 6 of 207 [RFC4975], MSRP implementations are expected to allow unrecognized 208 transports for which there is no need to establish a connection to 209 the resource described by the URI, as it's the case of data channels 210 (Section 4.4). 212 4.2. msrp-scheme 214 The msrp-scheme portion of the MSRP-URI that represents an MSRP data 215 channel endpoint (used in the SDP path attribute and in the MSRP 216 message headers) is always "msrps", which indicates that the MSRP 217 data channel is always secured using DTLS as described in 218 [I-D.ietf-rtcweb-data-channel]. 220 4.3. Use of the dcmap Attribute 222 An offerer and answerer SHALL, in each offer and answer, include a 223 dcmap attribute line ([I-D.ietf-mmusic-data-channel-sdpneg]) within 224 the media description of the SCTP association for each MSRP data 225 channel session to be negotiated. 227 The attribute includes the following data channel parameters: 229 o "label=" labelstring 231 o "subprotocol=" "msrp" 233 The labelstring is set by the MSRP application according to 234 [I-D.ietf-mmusic-data-channel-sdpneg]. 236 The offerer and answerer SHALL NOT include the max-retr and the max- 237 time attribute parameters in the dcmap attribute. 239 The offerer and answerer MAY include the ordered attribute parameter 240 in the dcmap attribute. If included, the attribute parameter value 241 SHALL be set to "true". 243 Below is an example of the dcmap attribute for an MSRP session to be 244 negotiated with stream-id=2 and label="chat": 246 a=dcmap:2 label="chat";subprotocol="msrp" 248 4.4. Use of the dcsa Attribute 250 An offerer and answerer SHALL, in each offer and answer, include a 251 dcsa attribute line ([I-D.ietf-mmusic-data-channel-sdpneg]) within 252 the media description for the SCTP association for each MSRP-specific 253 SDP attribute to be negotiated for each MSRP data channel being 254 negotiated. 256 An offerer and answerer SHALL include a dcsa attribute for each of 257 the following MSRP-specific SDP attributes: 259 o defined in [RFC4975]: "path". 261 o defined in [RFC6714]: "msrp-cema". 263 o defined in [RFC6135]: "setup". See Section 4.5 265 It is considered a protocol error if one or more of the dcsa embedded 266 attributes listed above are not included in an offer or answer. 268 An offerer and answerer MAY include a dcsa attribute for any of the 269 following MSRP-specific SDP attributes, following the procedures 270 defined for each attributes: 272 o defined in [RFC4975]: "accept-types", "accept-wrapped-types" and 273 "max-size" 275 o defined in [RFC4566]: "sendonly", "recvonly", "inactive" and 276 "sendrecv" 278 o defined in [RFC5547]: all the parameters related to MSRP file 279 transfer. See Section 4.7. 281 A subsequent offer or answer MAY update the previously negotiated 282 MSRP subprotocol attributes while keeping the same subprotocol 283 a=dcmap description. The semantics for newly negotiated MSRP 284 subprotocol attributes are per [RFC4975]. 286 When MSRP messages are transported on a data channel, the "path" 287 attribute is not used for routing of the messages. The MSRP data 288 channel is established using the SDP offer/answer procedures defined 289 in [I-D.ietf-mmusic-data-channel-sdpneg], and the MSRP messages are 290 then transported on that data channel. This is different from legacy 291 MSRP [RFC4975] but similar to MSRP CEMA [RFC6714]. However, when an 292 endpoint receives an MSRP message over a data channel, it MUST still 293 perform the MSRP-URI comparison procedures defined in [RFC4975]. 295 4.5. Use of the dcsa embedded setup Attribute 297 As described in Section 4.4, the usage of a dsca embedded setup 298 attribute is mandated for MSRP sessions over data channels. It is 299 used to negotiate which MSRP session endpoint assumes the active role 300 as per Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975]. It 301 has no relationship with the DTLS connection establishment roles 302 [I-D.ietf-mmusic-sctp-sdp]. 304 The dcsa embedded setup attribute is of the form "a=dcsa:x 305 setup:", with x being the data channel's SCTP stream 306 identifier, so that such attribute is explicitly associated with an 307 MSRP session over a specific data channel. 309 4.6. Session Closing 311 An MSRP session is closed by closing the associated data channel, 312 following the procedures in [I-D.ietf-mmusic-data-channel-sdpneg]. 314 The port value for the "m=" line SHOULD NOT be changed (e.g. to zero) 315 when closing an MSRP session (unless all data channels are being 316 closed and the SCTP association is no longer needed), since this 317 would close the SCTP association and impact all of the data channels. 318 In all cases in [RFC4975] where the procedure calls for setting the 319 port to zero for the MSRP "m=" line in an SDP offer for TCP 320 transport, the SDP offerer of an MSRP session with data channel 321 transport SHALL remove the corresponding dcmap and dcsa attributes. 323 The SDP answerer must ensure that no dcmap or dcsa attributes are 324 present in the SDP answer if no corresponding attributes are present 325 in the received SDP offer. 327 4.7. Support for MSRP File Transfer Function 329 SDP attributes specified in [RFC5547] for a file transfer "m=" line 330 are embedded as subprotocol-specific attributes using the syntax 331 defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 333 4.8. Example SDP Negotiation 335 The following is an example of an "m=" line for data channels in an 336 SDP offer that includes the attributes needed to establish two MSRP 337 sessions: one for chat and one for file transfer. The example is 338 derived from a combination of examples in [RFC4975] and [RFC5547]. 340 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 341 c=IN IP4 198.51.100.79 342 a=max-message-size:100000 343 a=sctp-port:5000 344 a=setup:actpass 345 a=fingerprint:SHA-1 \ 346 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 347 a=tls-id:4a756565cddef001be82 348 a=dcmap:0 label="chat";subprotocol="msrp" 349 a=dcsa:0 msrp-cema 350 a=dcsa:0 setup:active 351 a=dcsa:0 accept-types:message/cpim text/plain 352 a=dcsa:0 path:msrps://198.51.100.79:54111/si438dsaodes;dc 353 a=dcmap:2 label="file transfer";subprotocol="msrp" 354 a=dcsa:2 sendonly 355 a=dcsa:2 msrp-cema 356 a=dcsa:2 setup:active 357 a=dcsa:2 accept-types:message/cpim 358 a=dcsa:2 accept-wrapped-types:* 359 a=dcsa:2 path:msrps://198.51.100.79:54111/jshA7we;dc 360 a=dcsa:2 file-selector:name:"picture1.jpg" \ 361 type:image/jpeg size:1463440 hash:sha-1:\ 362 FF:27:0D:81:14:F1:8A:C3:35:3B:36:64:2A:62:C9:3E:D3:6B:51:B4 363 a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep 364 a=dcsa:2 file-disposition:attachment 365 a=dcsa:2 file-date:creation:"Mon, 12 Jan 2018 15:01:31 +0800" 366 a=dcsa:2 file-icon:cid:id2@bob.example.com 367 a=dcsa:2 file-range:1-1463440 369 5. MSRP Considerations 371 The procedures specified in [RFC4975] apply except when this document 372 specifies otherwise. This section describes the MSRP considerations 373 specific to a MSRP data channel. 375 5.1. Session Mapping 377 In this document, each MSRP session maps to one data channel exactly. 379 5.2. Session Opening 381 Section 4.5 describes how the active MSRP session endpoint role is 382 negotiated. The active MSRP session endpoint uses the data channel 383 established for this MSRP session by the generic data channel opening 384 procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 386 As soon as the WebRTC data channel is opened, the MSRP session is 387 actually opened by the active MSRP session endpoint. In order to do 388 this the active MSRP endpoint sends an MSRP SEND message (empty or 389 not) to the other MSRP endpoint. 391 5.3. Session Closing 393 The closure of an MSRP session SHALL be signaled via SDP following 394 the requirements in Section 4.6 396 If the data channel used to transport the MSRP session fails and gets 397 torn down, the endpoints SHALL consider the MSRP session failed. An 398 MSRP endpoint MAY, based on local policy, try to negotiate a new MSRP 399 data channel. 401 5.4. Data Framing 403 Each text-based MSRP message is sent on the corresponding SCTP stream 404 using standard MSRP framing and chunking procedures, as defined in 405 [RFC4975], with each MSRP chunk delivered in a single SCTP user 406 message. Therefore all sent MSRP chunks including the MSRP chunk 407 header SHALL have lengths of less than or equal to the value of the 408 peer's "a=max-message-size" attribute, which is associated with the 409 data channel's SCTP association. 411 5.5. Data Sending, Receiving and Reporting 413 Data sending, receiving and reporting procedures SHALL conform to 414 [RFC4975]. 416 5.6. Support for MSRP File Transfer Function 418 [RFC5547] defines an end-to-end file transfer method based on MSRP 419 and the SDP offer/answer mechanism. This file transfer method is 420 also usable by MSRP endpoints using data channels, with the following 421 considerations: 423 o As an MSRP session maps to one data channel, a file transfer 424 session maps also to one data channel. 426 o SDP attributes are negotiated as specified in Section 4.7. 428 o Once the file transfer is complete, the same data channel MAY be 429 reused for another file transfer. 431 6. Gateway Considerations 433 This section describes the network configuration where one MSRP 434 endpoint uses a MSRP data channel as MSRP transport, the other MSRP 435 endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP 436 endpoints interwork via a 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 provide transport level interworking 447 between MSRP endpoints using different transport protocols. In 448 accordance with Section 4.4, path attributes SHALL NOT be used for 449 transport level interworking. 451 When the gateway performs transport level interworking between MSRP 452 endpoints, all of the procedures in Section 5 and Section 4 apply to 453 each peer, with the following additions: 455 o The gateway SHALL use CEMA towards the non-data channel endpoint. 457 o If the non-data channel endpoint does not support CEMA, transport 458 level interworking mode is not possible, the gateway needs to act 459 as an MSRP B2BUA. 461 o The gateway SHALL NOT modify the path attribute received from data 462 channel or from non-data channel endpoints. 464 o The gateway SHALL NOT modify the setup value received from data 465 channel or from non-data channel endpoints. 467 o The endpoint establishing an MSRP session using data channel 468 transport SHALL NOT request inclusion of any relays, although it 469 MAY interoperate with a peer that signals the use of relays. 471 7. Updates to RFC4975 473 This document updates [RFC4975], by allowing the usage of the "msrps" 474 scheme when the underlying connection is protected with DTLS. 476 8. Security Considerations 478 MSRP traffic over data channels is secured, including 479 confidentiality, integrity and source authentication, as specified by 480 [I-D.ietf-rtcweb-data-channel] 482 Note that discussion in [RFC4975] on MSRP message attribution to 483 remote identities applies to data channel transport. 485 9. IANA Considerations 487 9.1. msrps URI scheme 489 This document modifies the usage of the msrps URI scheme, registered 490 by [RFC4975], adding DTLS as a protected transport indicated by the 491 URI scheme. 493 9.2. Subprotocol Identifier MSRP 495 This document adds a reference to the subprotocol identifier "msrp" 496 in the "WebSocket Subprotocol Name Registry" 498 9.3. setup Attribute 500 NOTE to RFC Editor: Please replace "XXXX" with the number of this 501 RFC. 503 This document modifies the usage of the SDP setup attribute, if this 504 attribute is embedded in a dcsa attribute and associated with an MSRP 505 session over a data channel. The modified usage is described in 506 Section 4.5. 508 Usage level "dcsa(MSRP)" should be added to the IANA registration of 509 the SDP setup attribute as follows: 511 +-----------------------+-------------------------------------------+ 512 | Contact name: | IESG | 513 | Contact email: | iesg@ietf.org | 514 | Attribute name: | setup | 515 | Usage level: | dcsa(MSRP) | 516 | Purpose: | Negotiate the active role of an MSRP | 517 | | session over a data channel as per | 518 | | Section 4.5 | 519 | Reference: | RFCXXXX | 520 +-----------------------+-------------------------------------------+ 522 10. Acknowledgments 524 The authors wish to acknowledge the borrowing of ideas from another 525 internet draft by Peter Dunkley and Gavin Llewellyn, and to thank 526 Flemming Andreasen, Christian Groves, Paul Kyzivat, Jonathan Lennox, 527 Uwe Rauschenbach, Albrecht Schwarz, and Keith Drage for their 528 invaluable comments. 530 Richard Ejzak, Keith Drage and Juergen Stoetzer-Bradler contributed 531 an earlier version, before the draft was re-adopted. 533 Julien Maisonneuve helped with the re-adoption of the draft, and 534 Maridi R. Makaraju (Raju) contributed valuable comments after the 535 draft was re-adopted. 537 11. CHANGE LOG 539 11.1. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-16' 541 o WGLC review: draft updates RFC4975; clarify introduction; rewrite 542 wording on path and transport negotiation; session closing 543 clarifications; references cleanup. 545 o Editorial: consistent SHALL usage; reorder updates, security and 546 IANA sections for consistency; typos; acknowledgements. 548 11.2. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-15' 550 o More concise and clear introduction and section descriptions. 552 o Updates on author list, contributions and acknowledgements. 554 11.3. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-14' 556 o Reorganization following t140-usage-data-channel structure. 558 11.4. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-13' 560 o Clarify gateway procedures in accordance to mandatory use of CEMA. 562 11.5. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-12' 564 o Make CEMA mandatory, clarify SDP procedures. 566 11.6. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-11' 568 o Additional clarifications on cema and path attribute after mail 569 list feedback. 571 11.7. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-10' 573 o Corrections and clarifications on cema and path attributes after 574 mail list feedback. 576 11.8. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-09' 578 o Corrected area to ART. 580 11.9. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-08' 582 o Updated reference to 4566bis. 584 o Expanded motivation paragraphs in introduction. 586 11.10. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-07' 588 o Move security considerations after IANA considerations, following 589 RFC7322 suggested order. 591 o Update references to use xml.resource.org citation database. 593 o Reformat of the section discussing setup parameter 595 o Align examples with latest [I-D.ietf-mmusic-data-channel-sdpneg] 596 draft. 598 o Edit section 6 for clarity. 600 o Security requirements. 602 o Clarify comment on unrecognized transports and session opening. 604 o Update year, add editor. 606 11.11. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-06' 608 o Modification of Keith's address information. 610 11.12. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-05' 612 o Modification of Juergen's address information. 614 11.13. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-04' 616 o Addition of "I-D.ietf-mmusic-rfc4566bis"/> to list of normative 617 references. 619 o Addition of Section 9.3 as per section 8.2.4 of "I-D.ietf-mmusic- 620 rfc4566bis"/>. 622 11.14. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-03' 624 o Addition of IANA registration related Section 9.2. 626 11.15. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-02' 628 o Addition of "a=setup:actpass", "a=connection:new", 629 "a=fingerprint:..." and "a=dcsa:x setup=active" SDP attributes to 630 the SDP example in Section 4.8. 632 o Addition of "RFC4145" and [I-D.ietf-mmusic-sctp-sdp] to list of 633 normative references. 635 o Addition of new Section 4.5 describing how the active MSRP session 636 endpoint role is negotiated. 638 o Extension of first paragraph of session-opening with new first 639 sentence "Section 4.5 describes how the active MSRP session 640 endpoint role is negotiated.". 642 o First sentence of second paragraph in session-opening was "As soon 643 as this data channel is opened, the MSRP session is actually 644 opened by the active MSRP endpoint which sends an MSRP SEND 645 message (empty or not) to the other MSRP endpoint." Replacement 646 of this sentence with "As soon as this data channel is opened, the 647 MSRP session is actually opened by the active MSRP endpoint. In 648 order to do this the active MSRP endpoint sends an MSRP SEND 649 message (empty or not) to the other MSRP endpoint." 651 o Addition of setup attribute specific behavior descriptions of data 652 channel to TCP or TLS interworking gateways in Section 6. 654 11.16. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-01' 656 o In the abstract replacement of the first sentence "This document 657 specifies how the Message Session Relay Protocol (MSRP) can be 658 instantiated as a data channel sub-protocol, using the SDP offer/ 659 answer exchange-based external negotiation defined in 660 [I-D.ietf-mmusic-data-channel-sdpneg]" with "This document 661 specifies how the Message Session Relay Protocol (MSRP) can be 662 instantiated as a data channel sub-protocol, using the SDP offer/ 663 answer exchange-based generic data channel negotiation framework" 664 in order to remove the reference from the abstract text. 666 o Addition of following sentence to the second paragraph in 667 Section 1: "The MSRP protocol negotiation defined in this document 668 is based on the generic SDP offer/answer exchange based data 669 channel negotiation as specified in 670 [I-D.ietf-mmusic-data-channel-sdpneg]". 672 o In Section 3.1 replacement of sub-protocol identifier "msrp" with 673 "MSRP" in order to make this consistent with the formal 674 specification in Section 4.3. 676 o Throughout the text replacement of "shall" with "SHALL" etc where 677 appropriate as per [RFC2119]. 679 o In Section 4.3 replacement of sentence 'The max-retr, max-time and 680 ordered parameters shall not be used.' with 'Ordered and reliable 681 data channels MUST always be used, such that the "max-retr" and 682 "max-time" parameters SHALL NOT be used. If the "ordered" 683 parameter is used, then its value MUST be equal to "true".'. 685 o In Section 4.3 removal of "(on default SCTP port 5000)" from the 686 sentence preceding the example "a=dcmap" attribute line. 688 o In Section 4.4 first paragraph was "The SDP offer shall also 689 include a dcsa attribute line (defined in 690 [I-D.ietf-mmusic-data-channel-sdpneg]) within the media 691 description for the SCTP association for each MSRP-specific SDP 692 attribute to be negotiated for each MSRP data channel being 693 negotiated.". Replacement of this paragraph with "The SDP offer 694 SHALL also include within the media description for the SCTP 695 association a dcsa attribute line (defined in 696 [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP 697 attribute to be negotiated for each MSRP data channel being 698 negotiated.". 700 o Appended following sentence at the end of the first paragraph of 701 Section 5.4: "Therefore all sent MSRP chunks MUST have lengths of 702 less than or equal to the value of the peer's "a=max-message-size" 703 attribute, which is associated with the data channel's SCTP 704 association.". 706 o Addition of the previously missing colon to the "a=sctp-port" 707 attribute line in Section 4.8. 709 o In Section 5.3 replacement of the first paragraph "Closing of an 710 MSRP session is done using the generic data channel closing 711 procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]." with 712 'The closure of an MSRP session MUST be signaled via an SDP offer/ 713 answer exchange which removes the "a=dcmap:" and "a=dcsa:" 714 attribute lines associated with the MSRP session from the 715 associated DTLS/SCTP based media description. This results in the 716 associated data channel being closed as well as per 717 [I-D.ietf-mmusic-data-channel-sdpneg], where the actual data 718 channel closure procedure is typically initiated by the SDP 719 answerer right after having accepted the SDP offer.'. 721 11.17. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-00' 723 o Additional reference to [I-D.ietf-mmusic-data-channel-sdpneg] in 724 list of normative references. 726 o Replacement of previous document title "MSRP over SCTP/DTLS data 727 channels" with "MSRP over Data Channels" in order to align with 728 the terminology used in [I-D.ietf-mmusic-data-channel-sdpneg]. 730 o In "terminology", "WebRTC data channel" was defined as "A 731 bidirectional channel consisting of paired SCTP outbound and 732 inbound streams." Replacement of this definition with "Data 733 channel: A WebRTC data channel as specified in 734 [I-D.ietf-rtcweb-data-channel]", and consistent usage of either 735 "data channel" or "MSRP data channel" in the remainder of the 736 document." 738 o In the introduction replacement of references to 739 [I-D.ietf-rtcweb-data-protocol] with a reference to 740 [I-D.ietf-rtcweb-data-channel]. 742 o Consistent usage of '"m=" line' in whole document as per 743 [RFC4566]. 745 o In the gateway configuration section (Section 6) replacement of 746 the first sentence "This section describes the network 747 configuration where one endpoint runs MSRP over a WebRTC SCTP/DTLS 748 connection, the other MSRP endpoint runs MSRP over one or more 749 TLS/TCP connections, and the two endpoints interwork via an MSRP 750 gateway" with "This section describes the network configuration 751 where one MSRP endpoint uses data channels as MSRP transport, the 752 other MSRP endpoint uses TLS/TCP connections as MSRP transport, 753 and the two MSRP endpoints interwork via an MSRP gateway". 755 11.18. Changes against 'draft-ejzak-mmusic-msrp-usage-data-channel-01' 757 o Removed empty spaces after ";" in the examples' "a=dcmap" 758 attribute lines. 760 o In all examples, the "m=" line proto value "DTLS/SCTP" was 761 replaced with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines 762 were replaced with "a=max-message-size" attribute lines, as per 763 draft-ietf-mmusic-sctp-sdp-12. 765 11.19. Changes against '-00' 767 o Transport parameter change for MSRP to allow MSRP RFC transports. 769 o Clarification on SDP offer/answer and removing duplicated 770 procedures and refer them to draft-ejzak-mmusic-data-channel- 771 sdpneg-02. 773 12. Normative References 775 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 776 Requirement Levels", BCP 14, RFC 2119, 777 DOI 10.17487/RFC2119, March 1997, 778 . 780 [I-D.ietf-rtcweb-data-protocol] 781 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 782 Establishment Protocol", draft-ietf-rtcweb-data- 783 protocol-09 (work in progress), January 2015. 785 [I-D.ietf-rtcweb-data-channel] 786 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 787 Channels", draft-ietf-rtcweb-data-channel-13 (work in 788 progress), January 2015. 790 [I-D.ietf-mmusic-data-channel-sdpneg] 791 Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. 792 Even, "SDP-based Data Channel Negotiation", draft-ietf- 793 mmusic-data-channel-sdpneg-28 (work in progress), May 794 2019. 796 [I-D.ietf-mmusic-sctp-sdp] 797 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 798 "Session Description Protocol (SDP) Offer/Answer 799 Procedures For Stream Control Transmission Protocol (SCTP) 800 over Datagram Transport Layer Security (DTLS) Transport.", 801 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 802 2017. 804 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 805 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 806 July 2006, . 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 Jose M. Recio (editor) 839 Unaffiliated 841 Email: jose@ch3m4.com 842 Christer Holmberg 843 Ericsson 844 Hirsalantie 11 845 Jorvas 02420 846 Finland 848 Email: christer.holmberg@ericsson.com