idnits 2.17.1 draft-ietf-mmusic-msrp-usage-data-channel-21.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC4975, updated by this document, for RFC5378 checks: 2003-05-23) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2020) is 1360 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 3 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 Updates: 4975 (if approved) C. Holmberg 5 Intended status: Standards Track Ericsson 6 Expires: January 8, 2021 July 7, 2020 8 MSRP over Data Channels 9 draft-ietf-mmusic-msrp-usage-data-channel-21 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 January 8, 2021. 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 . . . . . . . . . 8 67 4.8. Example SDP Negotiation . . . . . . . . . . . . . . . . . 8 68 5. MSRP Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 5.1. Session Mapping . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . 11 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. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 11 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 83 11. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 11.1. Changes against 'draft-ietf-mmusic-msrp-usage-data- 85 channel-18' . . . . . . . . . . . . . . . . . . . . . . 18 86 11.2. Changes against 'draft-ietf-mmusic-msrp-usage-data- 87 channel-17' . . . . . . . . . . . . . . . . . . . . . . 18 88 11.3. Changes against 'draft-ietf-mmusic-msrp-usage-data- 89 channel-16' . . . . . . . . . . . . . . . . . . . . . . 18 90 11.4. Changes against 'draft-ietf-mmusic-msrp-usage-data- 91 channel-15' . . . . . . . . . . . . . . . . . . . . . . 18 92 11.5. Changes against 'draft-ietf-mmusic-msrp-usage-data- 93 channel-14' . . . . . . . . . . . . . . . . . . . . . . 18 94 11.6. Changes against 'draft-ietf-mmusic-msrp-usage-data- 95 channel-13' . . . . . . . . . . . . . . . . . . . . . . 18 96 11.7. Changes against 'draft-ietf-mmusic-msrp-usage-data- 97 channel-12' . . . . . . . . . . . . . . . . . . . . . . 19 98 11.8. Changes against 'draft-ietf-mmusic-msrp-usage-data- 99 channel-11' . . . . . . . . . . . . . . . . . . . . . . 19 100 11.9. Changes against 'draft-ietf-mmusic-msrp-usage-data- 101 channel-10' . . . . . . . . . . . . . . . . . . . . . . 19 102 11.10. Changes against 'draft-ietf-mmusic-msrp-usage-data- 103 channel-09' . . . . . . . . . . . . . . . . . . . . . . 19 104 11.11. Changes against 'draft-ietf-mmusic-msrp-usage-data- 105 channel-08' . . . . . . . . . . . . . . . . . . . . . . 19 106 11.12. Changes against 'draft-ietf-mmusic-msrp-usage-data- 107 channel-07' . . . . . . . . . . . . . . . . . . . . . . 19 108 11.13. Changes against 'draft-ietf-mmusic-msrp-usage-data- 109 channel-06' . . . . . . . . . . . . . . . . . . . . . . 20 110 11.14. Changes against 'draft-ietf-mmusic-msrp-usage-data- 111 channel-05' . . . . . . . . . . . . . . . . . . . . . . 20 112 11.15. Changes against 'draft-ietf-mmusic-msrp-usage-data- 113 channel-04' . . . . . . . . . . . . . . . . . . . . . . 20 114 11.16. Changes against 'draft-ietf-mmusic-msrp-usage-data- 115 channel-03' . . . . . . . . . . . . . . . . . . . . . . 20 116 11.17. Changes against 'draft-ietf-mmusic-msrp-usage-data- 117 channel-02' . . . . . . . . . . . . . . . . . . . . . . 20 118 11.18. Changes against 'draft-ietf-mmusic-msrp-usage-data- 119 channel-01' . . . . . . . . . . . . . . . . . . . . . . 21 120 11.19. Changes against 'draft-ietf-mmusic-msrp-usage-data- 121 channel-00' . . . . . . . . . . . . . . . . . . . . . . 22 122 11.20. Changes against 'draft-ejzak-mmusic-msrp-usage-data- 123 channel-01' . . . . . . . . . . . . . . . . . . . . . . 23 124 11.21. Changes against '-00' . . . . . . . . . . . . . . . . . 23 125 12. Normative References . . . . . . . . . . . . . . . . . . . . 23 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 128 1. Introduction 130 The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for 131 transmitting a series of related instant messages in the context of a 132 session. In addition to instant messaging, MSRP can also be used for 133 image sharing or file transfer. MSRP was initially defined in 134 [RFC4975] to work over TCP and TLS connections, and over a WebSocket 135 subprotocol specified by [RFC7977]. 137 This document specifies the negotiation and transport of MSRP over a 138 WebRTC data channel [I-D.ietf-rtcweb-data-channel]. Negotiation is 139 carried out as specified in [I-D.ietf-mmusic-data-channel-sdpneg] and 140 MSRP is transported as a sub-protocol of a WebRTC data channel, 141 without the TCP and TLS layers. 143 Defining MSRP as a data channel sub-protocol has many benefits: 145 o provides to applications a proven protocol enabling instant 146 messaging, file transfer, image sharing 148 o integrates those features with other WebRTC voice, video and data 149 features 151 o leverages the SDP-based negotiation already defined for MSRP 153 o allows the interworking with MSRP endpoints running on a TCP or 154 TLS connection 156 Compared to WebSockets, which provide a message passing protocol to 157 applications with no direct access to TCP or TLS sockets, data 158 channels provide a low latency transport, leverage NAT-aware 159 connectivity and security features of WebRTC, and are increasingly 160 available not only in modern browsers but in other applications that 161 use WebRTC for media or other purposes, such as IoT or telemetry in 162 general, non-media data exchange, and so on. 164 Considering an MSRP endpoint as an MSRP application that uses a 165 WebRTC data channel, this document describes two configurations where 166 the other endpoint is respectively either another MSRP over data 167 channel endpoint (e.g., a WebRTC application) or an MSRP endpoint 168 using either TCP or TLS transport. 170 This document updates [RFC4975] as described in Section 7. 172 2. Conventions 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and 176 "OPTIONAL" in this document are to be interpreted asdescribed in BCP 177 14 [RFC2119][RFC8174] when, and only when, they appear in all 178 capitals, as shown here. 180 3. WebRTC Data Channel Considerations 182 3.1. MSRP Data Channel 184 In this document, an MSRP data channel is a data channel for which 185 the instantiated sub-protocol is "msrp", and where the channel is 186 negotiated using the SDP-based external negotiation method defined in 187 [I-D.ietf-mmusic-data-channel-sdpneg]. 189 The following WebRTC data channel property values 190 [I-D.ietf-rtcweb-data-channel] apply to an MSRP data channel: 192 +--------------------------+------------------+ 193 | Property | Value | 194 +--------------------------+------------------+ 195 | Subprotocol Identifier | msrp | 196 | Transmission reliability | reliable | 197 | Transmission order | in-order | 198 | Label | See Section 4.3 | 199 +--------------------------+------------------+ 201 4. SDP Considerations 203 This section describes the SDP considerations which are specific to 204 an MSRP data channel 206 4.1. MSRP URI 208 This document extends the MSRP URI syntax [RFC4975] by defining the 209 new transport parameter value "dc": 211 transport /= "dc" 212 ; Add "dc" to existing transports per [RFC4975] 214 MSRP design provides for new transport bindings (see Section 6 of 215 [RFC4975]). MSRP implementations are expected to allow unrecognized 216 transports for which there is no need to establish a connection to 217 the resource described by the URI, as it's the case of data channels 218 (Section 4.4). 220 4.2. msrp-scheme 222 The msrp-scheme portion of the MSRP-URI that represents an MSRP data 223 channel endpoint (used in the SDP path attribute and in the MSRP 224 message headers) is always "msrps", which indicates that the MSRP 225 data channel is always secured using DTLS as described in 226 [I-D.ietf-rtcweb-data-channel]. 228 4.3. Use of the dcmap Attribute 230 An offerer and answerer SHALL, in each offer and answer, include a 231 dcmap attribute line ([I-D.ietf-mmusic-data-channel-sdpneg]) within 232 the media description of the SCTP association for each MSRP data 233 channel session to be negotiated. 235 The attribute includes the following data channel parameters: 237 o "label=" labelstring 239 o "subprotocol=" "msrp" 240 The labelstring is set by the MSRP application according to 241 [I-D.ietf-mmusic-data-channel-sdpneg]. 243 The offerer and answerer SHALL NOT include the max-retr and the max- 244 time attribute parameters in the dcmap attribute. 246 The offerer and answerer MAY include the ordered attribute parameter 247 in the dcmap attribute. If included, the attribute parameter value 248 SHALL be set to "true". 250 Below is an example of the dcmap attribute for an MSRP session to be 251 negotiated with stream-id=2 and label="chat": 253 a=dcmap:2 label="chat";subprotocol="msrp" 255 4.4. Use of the dcsa Attribute 257 An offerer and answerer SHALL, in each offer and answer, include a 258 dcsa attribute line ([I-D.ietf-mmusic-data-channel-sdpneg]) within 259 the media description for the SCTP association for each MSRP-specific 260 SDP attribute to be negotiated for each MSRP data channel being 261 negotiated. 263 An offerer and answerer SHALL include a dcsa attribute for each of 264 the following MSRP-specific SDP attributes: 266 o defined in [RFC4975]: "path". 268 o defined in [RFC6714]: "msrp-cema". 270 o defined in [RFC6135]: "setup". See Section 4.5 272 It is considered a protocol error if one or more of the dcsa embedded 273 attributes listed above are not included in an offer or answer. 275 An offerer and answerer MAY include a dcsa attribute for any of the 276 following MSRP-specific SDP attributes, following the procedures 277 defined for each attributes: 279 o defined in [RFC4975]: "accept-types", "accept-wrapped-types" and 280 "max-size" 282 o defined in [RFC4566]: "sendonly", "recvonly", "inactive" and 283 "sendrecv" 285 o defined in [RFC5547]: all the parameters related to MSRP file 286 transfer. See Section 4.7. 288 A subsequent offer or answer MAY update the previously negotiated 289 MSRP subprotocol attributes while keeping the same subprotocol 290 a=dcmap description. The semantics for newly negotiated MSRP 291 subprotocol attributes are per [RFC4975]. 293 When MSRP messages are transported on a data channel, the "path" 294 attribute is not used for routing of the messages. The MSRP data 295 channel is established using the SDP offer/answer procedures defined 296 in [I-D.ietf-mmusic-data-channel-sdpneg], and the MSRP messages are 297 then transported on that data channel. This is different from legacy 298 MSRP [RFC4975] but similar to MSRP CEMA [RFC6714]. However, when an 299 endpoint receives an MSRP message over a data channel, it MUST still 300 perform the MSRP-URI comparison procedures defined in [RFC4975]. 302 4.5. Use of the dcsa embedded setup Attribute 304 As described in Section 4.4, the usage of a dsca embedded setup 305 attribute is mandated for MSRP sessions over data channels. It is 306 used to negotiate which MSRP session endpoint assumes the active role 307 as per Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975]. It 308 has no relationship with the DTLS connection establishment roles 309 [I-D.ietf-mmusic-sctp-sdp]. 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 4.6. Session Closing 318 An MSRP session is closed by closing the associated data channel, 319 following the procedures in [I-D.ietf-mmusic-data-channel-sdpneg]. 321 The port value for the "m=" line SHOULD NOT be changed (e.g. to zero) 322 when closing an MSRP session (unless all data channels are being 323 closed and the SCTP association is no longer needed), since this 324 would close the SCTP association and impact all of the data channels. 325 In all cases in [RFC4975] where the procedure calls for setting the 326 port to zero for the MSRP "m=" line in an SDP offer for TCP 327 transport, the SDP offerer of an MSRP session with data channel 328 transport SHALL remove the corresponding dcmap and dcsa attributes. 330 The SDP answerer must ensure that no dcmap or dcsa attributes are 331 present in the SDP answer if no corresponding attributes are present 332 in the received SDP offer. 334 4.7. Support for MSRP File Transfer Function 336 SDP attributes specified in [RFC5547] for a file transfer "m=" line 337 are embedded as subprotocol-specific attributes using the syntax 338 defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 340 4.8. Example SDP Negotiation 342 The following is an example of an "m=" line for data channels in an 343 SDP offer that includes the attributes needed to establish two MSRP 344 sessions: one for chat and one for file transfer. The example is 345 derived from a combination of examples in [RFC4975] and [RFC5547]. 347 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 348 c=IN IP4 198.51.100.79 349 a=max-message-size:100000 350 a=sctp-port:5000 351 a=setup:actpass 352 a=fingerprint:SHA-1 \ 353 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 354 a=tls-id:4a756565cddef001be82 355 a=dcmap:0 label="chat";subprotocol="msrp" 356 a=dcsa:0 msrp-cema 357 a=dcsa:0 setup:active 358 a=dcsa:0 accept-types:message/cpim text/plain 359 a=dcsa:0 path:msrps://198.51.100.79:54111/si438dsaodes;dc 360 a=dcmap:2 label="file transfer";subprotocol="msrp" 361 a=dcsa:2 sendonly 362 a=dcsa:2 msrp-cema 363 a=dcsa:2 setup:active 364 a=dcsa:2 accept-types:message/cpim 365 a=dcsa:2 accept-wrapped-types:* 366 a=dcsa:2 path:msrps://198.51.100.79:54111/jshA7we;dc 367 a=dcsa:2 file-selector:name:"picture1.jpg" \ 368 type:image/jpeg size:1463440 hash:sha-1:\ 369 FF:27:0D:81:14:F1:8A:C3:35:3B:36:64:2A:62:C9:3E:D3:6B:51:B4 370 a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep 371 a=dcsa:2 file-disposition:attachment 372 a=dcsa:2 file-date:creation:"Mon, 12 Jan 2018 15:01:31 +0800" 373 a=dcsa:2 file-icon:cid:id2@bob.example.com 374 a=dcsa:2 file-range:1-1463440 376 5. MSRP Considerations 378 The procedures specified in [RFC4975] apply except when this document 379 specifies otherwise. This section describes the MSRP considerations 380 specific to an MSRP data channel. 382 5.1. Session Mapping 384 In this document, each MSRP session maps to one data channel exactly. 386 5.2. Session Opening 388 Section 4.5 describes how the active MSRP session endpoint role is 389 negotiated. The active MSRP session endpoint uses the data channel 390 established for this MSRP session by the generic data channel opening 391 procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 393 As soon as the WebRTC data channel is opened, the MSRP session is 394 actually opened by the active MSRP session endpoint. In order to do 395 this the active MSRP endpoint sends an MSRP SEND message (empty or 396 not) to the other MSRP endpoint. 398 5.3. Session Closing 400 The closure of an MSRP session SHALL be signaled via SDP following 401 the requirements in Section 4.6 403 If the data channel used to transport the MSRP session fails and gets 404 torn down, the endpoints SHALL consider the MSRP session failed. An 405 MSRP endpoint MAY, based on local policy, try to negotiate a new MSRP 406 data channel. 408 5.4. Data Framing 410 Each text-based MSRP message is sent on the corresponding SCTP stream 411 using standard MSRP framing and chunking procedures, as defined in 412 [RFC4975], with each MSRP chunk delivered in a single SCTP user 413 message. Therefore all sent MSRP chunks including the MSRP chunk 414 header SHALL have lengths of less than or equal to the value of the 415 peer's "a=max-message-size" attribute, which is associated with the 416 data channel's SCTP association. 418 5.5. Data Sending, Receiving and Reporting 420 Data sending, receiving and reporting procedures SHALL conform to 421 [RFC4975]. 423 5.6. Support for MSRP File Transfer Function 425 [RFC5547] defines an end-to-end file transfer method based on MSRP 426 and the SDP offer/answer mechanism. This file transfer method is 427 also usable by MSRP endpoints using data channels, with the following 428 considerations: 430 o As an MSRP session maps to one data channel, a file transfer 431 session maps also to one data channel. 433 o SDP attributes are negotiated as specified in Section 4.7. 435 o Once the file transfer is complete, the same data channel MAY be 436 reused for another file transfer. 438 6. Gateway Considerations 440 This section describes the network configuration where one MSRP 441 endpoint uses an MSRP data channel as MSRP transport, the other MSRP 442 endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP 443 endpoints interwork via a gateway. 445 Specifically, a gateway can be configured to interwork an MSRP 446 session over a data channel with a peer that does not support data 447 channel transport in one of two ways. 449 In one model, the gateway performs as an MSRP B2BUA to interwork all 450 the procedures as necessary between the endpoints. No further 451 specification is needed for this model. 453 Alternately, the gateway can provide transport level interworking 454 between MSRP endpoints using different transport protocols. In 455 accordance with Section 4.4, path attributes SHALL NOT be used for 456 transport level interworking. 458 When the gateway performs transport level interworking between MSRP 459 endpoints, all of the procedures in Section 5 and Section 4 apply to 460 each peer, with the following additions: 462 o The gateway SHALL use CEMA towards the non-data channel endpoint. 464 o If the non-data channel endpoint does not support CEMA, transport 465 level interworking mode is not possible, the gateway needs to act 466 as an MSRP B2BUA. 468 o The gateway SHALL NOT modify the path attribute received from data 469 channel or from non-data channel endpoints. 471 o The gateway SHALL NOT modify the setup value received from data 472 channel or from non-data channel endpoints. 474 o The endpoint establishing an MSRP session using data channel 475 transport SHALL NOT request inclusion of any relays, although it 476 MAY interoperate with a peer that signals the use of relays. 478 7. Updates to RFC4975 480 This document updates [RFC4975], by allowing the usage of the "msrps" 481 scheme when the underlying connection is protected with DTLS. 483 8. Security Considerations 485 MSRP traffic over data channels is secured, including 486 confidentiality, integrity and source authentication, as specified by 487 [I-D.ietf-rtcweb-data-channel] 489 Note that discussion in [RFC4975] on MSRP message attribution to 490 remote identities applies to data channel transport. 492 9. IANA Considerations 494 NOTE to RFC Editor: Please replace all instances of all instances of 495 RFCXXXX with the number of this RFC. 497 9.1. msrps URI scheme 499 This document modifies the usage of the msrps URI scheme, registered 500 by [RFC4975], adding DTLS as a protected transport indicated by the 501 URI scheme. 503 A reference to RFCXXXX is added to the URI scheme "msrps" in the 504 Uniform Resource Identifier (URI) Schemes Registry. 506 9.2. Subprotocol Identifier MSRP 508 A reference to this document is added to the subprotocol identifier 509 "msrp" in the "WebSocket Subprotocol Name Registry" 511 9.3. SDP Attributes 513 This document modifies the usage of a set of SDP attributes, if any 514 of those attributes is included in an SDP 'dsca' attribute associated 515 with an MSRP data channel. The modified usage of the SDP 'setup' 516 attribute is described in Section 4.5. The usage of the other SDP 517 attributes is described in Section 4.4. 519 o "path" 521 o "msrp-cema" 523 o "accept-types" 525 o "accept-wrapped-types" 526 o "max-size" 528 o "sendonly" 530 o "recvonly" 532 o "inactive" 534 o "sendrecv" 536 o "file-selector" 538 o "file-transfer-id" 540 o "file-disposition" 542 o "file-date" 544 o "file-icon" 546 o "file-range" 548 The usage level "dcsa(msrp)" is added to the registration of the SDP 549 'setup' attribute in the Session Description Protocol (SDP) 550 Parameters "att-field" sub-registry as follows: 552 +-----------------------+-------------------------------------------+ 553 | Contact name: | IESG | 554 | Contact email: | iesg@ietf.org | 555 | Attribute name: | setup | 556 | Usage level: | dcsa(msrp) | 557 | Purpose: | Negotiate the active role of an MSRP | 558 | | session over a data channel as per | 559 | | Section 4.5 | 560 | Reference: | RFCXXXX | 561 +-----------------------+-------------------------------------------+ 563 The usage level "dcsa(msrp)" is added to the registration of the SDP 564 'path' attribute in the Session Description Protocol (SDP) Parameters 565 "att-field" sub-registry as follows: 567 +-----------------------+-------------------------------------------+ 568 | Contact name: | IESG | 569 | Contact email: | iesg@ietf.org | 570 | Attribute name: | path | 571 | Usage level: | dcsa(msrp) | 572 | Purpose: | Indicate an endpoint, but not used for | 573 | | routing, as described in Section 4.4 | 574 | Reference: | RFCXXXX | 575 +-----------------------+-------------------------------------------+ 577 The usage level "dcsa(msrp)" is added to the registration of the SDP 578 'msrp-cema' attribute in the Session Description Protocol (SDP) 579 Parameters "att-field" sub-registry as follows: 581 +-----------------------+-------------------------------------------+ 582 | Contact name: | IESG | 583 | Contact email: | iesg@ietf.org | 584 | Attribute name: | msrp-cema | 585 | Usage level: | dcsa(msrp) | 586 | Purpose: | Indicate that the routing of MSRP | 587 | | messages transported on a data channel is | 588 | | more similar to the MSRP CEMA mechanism | 589 | | than the legacy MSRP routing mechanism. | 590 | Reference: | RFCXXXX | 591 +-----------------------+-------------------------------------------+ 593 The usage level "dcsa(msrp)" is added to the registration of the SDP 594 'accept-types' attribute in the Session Description Protocol (SDP) 595 Parameters "att-field" sub-registry as follows: 597 +-----------------------+-------------------------------------------+ 598 | Contact name: | IESG | 599 | Contact email: | iesg@ietf.org | 600 | Attribute name: | accept-types | 601 | Usage level: | dcsa(msrp) | 602 | Purpose: | Contain the list of media types that the | 603 | | endpoint is willing to receive. | 604 | Reference: | RFCXXXX | 605 +-----------------------+-------------------------------------------+ 607 The usage level "dcsa(msrp)" is added to the registration of the SDP 608 'accept-wrapped-types' attribute in the Session Description Protocol 609 (SDP) Parameters "att-field" sub-registry as follows: 611 +-----------------------+-------------------------------------------+ 612 | Contact name: | IESG | 613 | Contact email: | iesg@ietf.org | 614 | Attribute name: | accept-wrapped-types | 615 | Usage level: | dcsa(msrp) | 616 | Purpose: | Contain the list of media types that the | 617 | | endpoint is willing to receive in an MSRP | 618 | | message with multipart content. | 619 | Reference: | RFCXXXX | 620 +-----------------------+-------------------------------------------+ 622 The usage level "dcsa(msrp)" is added to the registration of the SDP 623 'max-size' attribute in the Session Description Protocol (SDP) 624 Parameters "att-field" sub-registry as follows: 626 +-----------------------+-------------------------------------------+ 627 | Contact name: | IESG | 628 | Contact email: | iesg@ietf.org | 629 | Attribute name: | max-size | 630 | Usage level: | dcsa(msrp) | 631 | Purpose: | Indicate the largest message an MSRP | 632 | | endpoint wishes to accept. | 633 | Reference: | RFCXXXX | 634 +-----------------------+-------------------------------------------+ 636 The usage level "dcsa(msrp)" is added to the registration of the SDP 637 'sendonly' attribute in the Session Description Protocol (SDP) 638 Parameters "att-field" sub-registry as follows: 640 +-----------------------+-------------------------------------------+ 641 | Contact name: | IESG | 642 | Contact email: | iesg@ietf.org | 643 | Attribute name: | sendonly | 644 | Usage level: | dcsa(msrp) | 645 | Purpose: | Negotiate the direction of the media flow | 646 | | on an MSRP data channel. | 647 | Reference: | RFCXXXX | 648 +-----------------------+-------------------------------------------+ 650 The usage level "dcsa(msrp)" is added to the registration of the SDP 651 'recvonly' attribute in the Session Description Protocol (SDP) 652 Parameters "att-field" sub-registry as follows: 654 +-----------------------+-------------------------------------------+ 655 | Contact name: | IESG | 656 | Contact email: | iesg@ietf.org | 657 | Attribute name: | recvonly | 658 | Usage level: | dcsa(msrp) | 659 | Purpose: | Negotiate the direction of the media flow | 660 | | on an MSRP data channel. | 661 | Reference: | RFCXXXX | 662 +-----------------------+-------------------------------------------+ 664 The usage level "dcsa(msrp)" is added to the registration of the SDP 665 'inactive' attribute in the Session Description Protocol (SDP) 666 Parameters "att-field" sub-registry as follows: 668 +-----------------------+-------------------------------------------+ 669 | Contact name: | IESG | 670 | Contact email: | iesg@ietf.org | 671 | Attribute name: | inactive | 672 | Usage level: | dcsa(msrp) | 673 | Purpose: | Negotiate the direction of the media flow | 674 | | on an MSRP data channel. | 675 | Reference: | RFCXXXX | 676 +-----------------------+-------------------------------------------+ 678 The usage level "dcsa(msrp)" is added to the registration of the SDP 679 'sendrecv' attribute in the Session Description Protocol (SDP) 680 Parameters "att-field" sub-registry as follows: 682 +-----------------------+-------------------------------------------+ 683 | Contact name: | IESG | 684 | Contact email: | iesg@ietf.org | 685 | Attribute name: | sendrecv | 686 | Usage level: | dcsa(msrp) | 687 | Purpose: | Negotiate the direction of the media flow | 688 | | on an MSRP data channel. | 689 | Reference: | RFCXXXX | 690 +-----------------------+-------------------------------------------+ 692 The usage level "dcsa(msrp)" is added to the registration of the SDP 693 'file-selector' attribute in the Session Description Protocol (SDP) 694 Parameters "att-field" sub-registry as follows: 696 +-----------------------+-------------------------------------------+ 697 | Contact name: | IESG | 698 | Contact email: | iesg@ietf.org | 699 | Attribute name: | file-selector | 700 | Usage level: | dcsa(msrp) | 701 | Purpose: | Indicate a file in an MSRP file transfer | 702 | | negotiation. | 703 | Reference: | RFCXXXX | 704 +-----------------------+-------------------------------------------+ 706 The usage level "dcsa(msrp)" is added to the registration of the SDP 707 'file-transfer-id' attribute in the Session Description Protocol 708 (SDP) Parameters "att-field" sub-registry as follows: 710 +-----------------------+-------------------------------------------+ 711 | Contact name: | IESG | 712 | Contact email: | iesg@ietf.org | 713 | Attribute name: | file-transfer-id | 714 | Usage level: | dcsa(msrp) | 715 | Purpose: | Indicate a unique identifier of the file | 716 | | transfer operation in an MSRP file | 717 | | transfer negotiation. | 718 | Reference: | RFCXXXX | 719 +-----------------------+-------------------------------------------+ 721 The usage level "dcsa(msrp)" is added to the registration of the SDP 722 'file-disposition' attribute in the Session Description Protocol 723 (SDP) Parameters "att-field" sub-registry as follows: 725 +-----------------------+-------------------------------------------+ 726 | Contact name: | IESG | 727 | Contact email: | iesg@ietf.org | 728 | Attribute name: | file-disposition | 729 | Usage level: | dcsa(msrp) | 730 | Purpose: | Provide a suggestion to the other | 731 | | endpoint about the intended disposition | 732 | | of the file in an MSRP file transfer | 733 | | negotiation. | 734 | Reference: | RFCXXXX | 735 +-----------------------+-------------------------------------------+ 737 The usage level "dcsa(msrp)" is added to the registration of the SDP 738 'file-date' attribute in the Session Description Protocol (SDP) 739 Parameters "att-field" sub-registry as follows: 741 +-----------------------+-------------------------------------------+ 742 | Contact name: | IESG | 743 | Contact email: | iesg@ietf.org | 744 | Attribute name: | file-date | 745 | Usage level: | dcsa(msrp) | 746 | Purpose: | Indicate a date related to the file in an | 747 | | MSRP file transfer negotiation. | 748 | Reference: | RFCXXXX | 749 +-----------------------+-------------------------------------------+ 751 The usage level "dcsa(msrp)" is added to the registration of the SDP 752 'file-icon' attribute in the Session Description Protocol (SDP) 753 Parameters "att-field" sub-registry as follows: 755 +-----------------------+-------------------------------------------+ 756 | Contact name: | IESG | 757 | Contact email: | iesg@ietf.org | 758 | Attribute name: | file-icon | 759 | Usage level: | dcsa(msrp) | 760 | Purpose: | Contain a pointer to a small preview icon | 761 | | representing the contents of the file in | 762 | | an MSRP file transfer negotiation. | 763 | Reference: | RFCXXXX | 764 +-----------------------+-------------------------------------------+ 766 The usage level "dcsa(msrp)" is added to the registration of the SDP 767 'file-range' attribute in the Session Description Protocol (SDP) 768 Parameters "att-field" sub-registry as follows: 770 +-----------------------+-------------------------------------------+ 771 | Contact name: | IESG | 772 | Contact email: | iesg@ietf.org | 773 | Attribute name: | file-range | 774 | Usage level: | dcsa(msrp) | 775 | Purpose: | Contain the range of transferred octets | 776 | | of the file in an MSRP file transfer | 777 | | negotiation. | 778 | Reference: | RFCXXXX | 779 +-----------------------+-------------------------------------------+ 781 10. Acknowledgments 783 The authors wish to acknowledge the borrowing of ideas from another 784 internet draft by Peter Dunkley and Gavin Llewellyn, and to thank 785 Flemming Andreasen, Christian Groves, Paul Kyzivat, Jonathan Lennox, 786 Uwe Rauschenbach, Albrecht Schwarz, and Keith Drage for their 787 invaluable comments. 789 Richard Ejzak, Keith Drage and Juergen Stoetzer-Bradler contributed 790 an earlier version, before the draft was re-adopted. 792 Julien Maisonneuve helped with the re-adoption of the draft, and 793 Maridi R. Makaraju (Raju) contributed valuable comments after the 794 draft was re-adopted. 796 11. CHANGE LOG 798 11.1. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-18' 800 o Fix error in purpose of dcsa(marp) entry for 'path' attribute. 802 11.2. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-17' 804 o Shepherd's review: update to the file header, remove reference in 805 abstract, mention update on introduction, reorder and complete 806 IANA considerations. 808 o Editorial: a MSRP -> an MSRP; MSRP -> msrp for consistency; typos. 810 11.3. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-16' 812 o WGLC review: draft updates RFC4975; clarify introduction; rewrite 813 wording on path and transport negotiation; session closing 814 clarifications; references cleanup. 816 o Editorial: consistent SHALL usage; reorder updates, security and 817 IANA sections for consistency; typos; acknowledgements. 819 11.4. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-15' 821 o More concise and clear introduction and section descriptions. 823 o Updates on author list, contributions and acknowledgements. 825 11.5. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-14' 827 o Reorganization following t140-usage-data-channel structure. 829 11.6. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-13' 831 o Clarify gateway procedures in accordance to mandatory use of CEMA. 833 11.7. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-12' 835 o Make CEMA mandatory, clarify SDP procedures. 837 11.8. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-11' 839 o Additional clarifications on cema and path attribute after mail 840 list feedback. 842 11.9. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-10' 844 o Corrections and clarifications on cema and path attributes after 845 mail list feedback. 847 11.10. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-09' 849 o Corrected area to ART. 851 11.11. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-08' 853 o Updated reference to 4566bis. 855 o Expanded motivation paragraphs in introduction. 857 11.12. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-07' 859 o Move security considerations after IANA considerations, following 860 RFC7322 suggested order. 862 o Update references to use xml.resource.org citation database. 864 o Reformat of the section discussing setup parameter 866 o Align examples with latest [I-D.ietf-mmusic-data-channel-sdpneg] 867 draft. 869 o Edit section 6 for clarity. 871 o Security requirements. 873 o Clarify comment on unrecognized transports and session opening. 875 o Update year, add editor. 877 11.13. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-06' 879 o Modification of Keith's address information. 881 11.14. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-05' 883 o Modification of Juergen's address information. 885 11.15. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-04' 887 o Addition of "I-D.ietf-mmusic-rfc4566bis"/> to list of normative 888 references. 890 o Addition of IANA considerations for setup attribute as per section 891 8.2.4 of "I-D.ietf-mmusic-rfc4566bis"/>. 893 11.16. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-03' 895 o Addition of IANA registration related Section 9.2. 897 11.17. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-02' 899 o Addition of "a=setup:actpass", "a=connection:new", 900 "a=fingerprint:..." and "a=dcsa:x setup=active" SDP attributes to 901 the SDP example in Section 4.8. 903 o Addition of "RFC4145" and [I-D.ietf-mmusic-sctp-sdp] to list of 904 normative references. 906 o Addition of new Section 4.5 describing how the active MSRP session 907 endpoint role is negotiated. 909 o Extension of first paragraph of session-opening with new first 910 sentence "Section 4.5 describes how the active MSRP session 911 endpoint role is negotiated.". 913 o First sentence of second paragraph in session-opening was "As soon 914 as this data channel is opened, the MSRP session is actually 915 opened by the active MSRP endpoint which sends an MSRP SEND 916 message (empty or not) to the other MSRP endpoint." Replacement 917 of this sentence with "As soon as this data channel is opened, the 918 MSRP session is actually opened by the active MSRP endpoint. In 919 order to do this the active MSRP endpoint sends an MSRP SEND 920 message (empty or not) to the other MSRP endpoint." 922 o Addition of setup attribute specific behavior descriptions of data 923 channel to TCP or TLS interworking gateways in Section 6. 925 11.18. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-01' 927 o In the abstract replacement of the first sentence "This document 928 specifies how the Message Session Relay Protocol (MSRP) can be 929 instantiated as a data channel sub-protocol, using the SDP offer/ 930 answer exchange-based external negotiation defined in 931 [I-D.ietf-mmusic-data-channel-sdpneg]" with "This document 932 specifies how the Message Session Relay Protocol (MSRP) can be 933 instantiated as a data channel sub-protocol, using the SDP offer/ 934 answer exchange-based generic data channel negotiation framework" 935 in order to remove the reference from the abstract text. 937 o Addition of following sentence to the second paragraph in 938 Section 1: "The MSRP protocol negotiation defined in this document 939 is based on the generic SDP offer/answer exchange based data 940 channel negotiation as specified in 941 [I-D.ietf-mmusic-data-channel-sdpneg]". 943 o In Section 3.1 replacement of sub-protocol identifier "msrp" with 944 "MSRP" in order to make this consistent with the formal 945 specification in Section 4.3. 947 o Throughout the text replacement of "shall" with "SHALL" etc where 948 appropriate as per [RFC2119]. 950 o In Section 4.3 replacement of sentence 'The max-retr, max-time and 951 ordered parameters shall not be used.' with 'Ordered and reliable 952 data channels MUST always be used, such that the "max-retr" and 953 "max-time" parameters SHALL NOT be used. If the "ordered" 954 parameter is used, then its value MUST be equal to "true".'. 956 o In Section 4.3 removal of "(on default SCTP port 5000)" from the 957 sentence preceding the example "a=dcmap" attribute line. 959 o In Section 4.4 first paragraph was "The SDP offer shall also 960 include a dcsa attribute line (defined in 961 [I-D.ietf-mmusic-data-channel-sdpneg]) within the media 962 description for the SCTP association for each MSRP-specific SDP 963 attribute to be negotiated for each MSRP data channel being 964 negotiated.". Replacement of this paragraph with "The SDP offer 965 SHALL also include within the media description for the SCTP 966 association a dcsa attribute line (defined in 967 [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP 968 attribute to be negotiated for each MSRP data channel being 969 negotiated.". 971 o Appended following sentence at the end of the first paragraph of 972 Section 5.4: "Therefore all sent MSRP chunks MUST have lengths of 973 less than or equal to the value of the peer's "a=max-message-size" 974 attribute, which is associated with the data channel's SCTP 975 association.". 977 o Addition of the previously missing colon to the "a=sctp-port" 978 attribute line in Section 4.8. 980 o In Section 5.3 replacement of the first paragraph "Closing of an 981 MSRP session is done using the generic data channel closing 982 procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]." with 983 'The closure of an MSRP session MUST be signaled via an SDP offer/ 984 answer exchange which removes the "a=dcmap:" and "a=dcsa:" 985 attribute lines associated with the MSRP session from the 986 associated DTLS/SCTP based media description. This results in the 987 associated data channel being closed as well as per 988 [I-D.ietf-mmusic-data-channel-sdpneg], where the actual data 989 channel closure procedure is typically initiated by the SDP 990 answerer right after having accepted the SDP offer.'. 992 11.19. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-00' 994 o Additional reference to [I-D.ietf-mmusic-data-channel-sdpneg] in 995 list of normative references. 997 o Replacement of previous document title "MSRP over SCTP/DTLS data 998 channels" with "MSRP over Data Channels" in order to align with 999 the terminology used in [I-D.ietf-mmusic-data-channel-sdpneg]. 1001 o In "terminology", "WebRTC data channel" was defined as "A 1002 bidirectional channel consisting of paired SCTP outbound and 1003 inbound streams." Replacement of this definition with "Data 1004 channel: A WebRTC data channel as specified in 1005 [I-D.ietf-rtcweb-data-channel]", and consistent usage of either 1006 "data channel" or "MSRP data channel" in the remainder of the 1007 document." 1009 o In the introduction replacement of references to 1010 [I-D.ietf-rtcweb-data-protocol] with a reference to 1011 [I-D.ietf-rtcweb-data-channel]. 1013 o Consistent usage of '"m=" line' in whole document as per 1014 [RFC4566]. 1016 o In the gateway configuration section (Section 6) replacement of 1017 the first sentence "This section describes the network 1018 configuration where one endpoint runs MSRP over a WebRTC SCTP/DTLS 1019 connection, the other MSRP endpoint runs MSRP over one or more 1020 TLS/TCP connections, and the two endpoints interwork via an MSRP 1021 gateway" with "This section describes the network configuration 1022 where one MSRP endpoint uses data channels as MSRP transport, the 1023 other MSRP endpoint uses TLS/TCP connections as MSRP transport, 1024 and the two MSRP endpoints interwork via an MSRP gateway". 1026 11.20. Changes against 'draft-ejzak-mmusic-msrp-usage-data-channel-01' 1028 o Removed empty spaces after ";" in the examples' "a=dcmap" 1029 attribute lines. 1031 o In all examples, the "m=" line proto value "DTLS/SCTP" was 1032 replaced with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines 1033 were replaced with "a=max-message-size" attribute lines, as per 1034 draft-ietf-mmusic-sctp-sdp-12. 1036 11.21. Changes against '-00' 1038 o Transport parameter change for MSRP to allow MSRP RFC transports. 1040 o Clarification on SDP offer/answer and removing duplicated 1041 procedures and refer them to draft-ejzak-mmusic-data-channel- 1042 sdpneg-02. 1044 12. Normative References 1046 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1047 Requirement Levels", BCP 14, RFC 2119, 1048 DOI 10.17487/RFC2119, March 1997, 1049 . 1051 [I-D.ietf-rtcweb-data-protocol] 1052 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 1053 Establishment Protocol", draft-ietf-rtcweb-data- 1054 protocol-09 (work in progress), January 2015. 1056 [I-D.ietf-rtcweb-data-channel] 1057 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1058 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1059 progress), January 2015. 1061 [I-D.ietf-mmusic-data-channel-sdpneg] 1062 Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. 1063 Even, "SDP-based Data Channel Negotiation", draft-ietf- 1064 mmusic-data-channel-sdpneg-28 (work in progress), May 1065 2019. 1067 [I-D.ietf-mmusic-sctp-sdp] 1068 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 1069 "Session Description Protocol (SDP) Offer/Answer 1070 Procedures For Stream Control Transmission Protocol (SCTP) 1071 over Datagram Transport Layer Security (DTLS) Transport.", 1072 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 1073 2017. 1075 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1076 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1077 July 2006, . 1079 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 1080 "The Message Session Relay Protocol (MSRP)", RFC 4975, 1081 DOI 10.17487/RFC4975, September 2007, 1082 . 1084 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 1085 and P. Kyzivat, "A Session Description Protocol (SDP) 1086 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 1087 DOI 10.17487/RFC5547, May 2009, 1088 . 1090 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 1091 for the Message Session Relay Protocol (MSRP)", RFC 6135, 1092 DOI 10.17487/RFC6135, February 2011, 1093 . 1095 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 1096 Establishment for Media Anchoring (CEMA) for the Message 1097 Session Relay Protocol (MSRP)", RFC 6714, 1098 DOI 10.17487/RFC6714, August 2012, 1099 . 1101 [RFC7977] Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G., 1102 and R. Ravindranath, "The WebSocket Protocol as a 1103 Transport for the Message Session Relay Protocol (MSRP)", 1104 RFC 7977, DOI 10.17487/RFC7977, September 2016, 1105 . 1107 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1108 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1109 May 2017, . 1111 Authors' Addresses 1113 Jose M. Recio (editor) 1114 Unaffiliated 1116 Email: jose@ch3m4.com 1118 Christer Holmberg 1119 Ericsson 1120 Hirsalantie 11 1121 Jorvas 02420 1122 Finland 1124 Email: christer.holmberg@ericsson.com