idnits 2.17.1 draft-ietf-mmusic-msrp-usage-data-channel-24.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (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 (August 18, 2020) is 1347 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) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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: February 19, 2021 August 18, 2020 8 MSRP over Data Channels 9 draft-ietf-mmusic-msrp-usage-data-channel-24 11 Abstract 13 This document specifies how a Web Real-Time Communication (WebRTC) 14 data channel can be used as a transport mechanism for the Message 15 Session Relay Protocol (MSRP) and how the Session Description 16 Protocol (SDP) offer/answer mechanism can be used to negotiate such a 17 data channel, referred to as an MSRP data channel. Two network 18 configurations are supported: connecting two MSRP data channel 19 endpoints; and a gateway configuration, connecting an MSRP data 20 channel endpoint with an MSRP over TCP or TLS endpoint. This 21 document updates RFC4975. This document updates RFC4975. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 19, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. WebRTC Data Channel Considerations . . . . . . . . . . . . . 4 60 3.1. MSRP Data Channel . . . . . . . . . . . . . . . . . . . . 4 61 4. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. MSRP URI . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.2. msrp-scheme . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.3. Use of the dcmap Attribute . . . . . . . . . . . . . . . 5 65 4.4. Use of the dcsa Attribute . . . . . . . . . . . . . . . . 5 66 4.5. Use of the dcsa embedded setup Attribute . . . . . . . . 6 67 4.6. Session Closing . . . . . . . . . . . . . . . . . . . . . 7 68 4.7. Support for MSRP File Transfer Function . . . . . . . . . 7 69 4.8. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 5. MSRP Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 5.1. Session Mapping . . . . . . . . . . . . . . . . . . . . . 9 72 5.2. Session Opening . . . . . . . . . . . . . . . . . . . . . 9 73 5.3. Session Closing . . . . . . . . . . . . . . . . . . . . . 9 74 5.4. Data Framing . . . . . . . . . . . . . . . . . . . . . . 9 75 5.5. Data Sending, Receiving and Reporting . . . . . . . . . . 9 76 5.6. Support for MSRP File Transfer Function . . . . . . . . . 10 77 6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 10 78 7. Updates to RFC4975 . . . . . . . . . . . . . . . . . . . . . 11 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 9.1. msrps URI scheme . . . . . . . . . . . . . . . . . . . . 11 82 9.2. Subprotocol Identifier MSRP . . . . . . . . . . . . . . . 12 83 9.3. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 12 84 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 87 11.2. Informative References . . . . . . . . . . . . . . . . . 20 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 90 1. Introduction 92 The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for 93 transmitting a series of related instant messages in the context of a 94 session. In addition to instant messaging, MSRP can also be used for 95 image sharing or file transfer. MSRP was initially defined in 97 [RFC4975] to work over TCP and TLS connections, and over a WebSocket 98 subprotocol specified by [RFC7977]. 100 This document specifies how a Web Real-Time Communication (WebRTC) 101 data channel [I-D.ietf-rtcweb-data-channel] can be used as a 102 transport mechanism for MSRP, without the TCP and TLS layers, and how 103 the Session Description Protocol (SDP) offer/answer mechanism for 104 data channels [I-D.ietf-mmusic-data-channel-sdpneg] can be used to 105 negotiate such a data channel. 107 In this document, an MSRP data channel refers to a WebRTC data 108 channel for which the instantiated subprotocol is "msrp" and where 109 the data channel is negotiated using the SDP offer/answer mechanism 110 [I-D.ietf-mmusic-data-channel-sdpneg]. 112 Defining MSRP as a data channel subprotocol has many benefits: 114 o provides to applications a proven protocol enabling instant 115 messaging, file transfer, image sharing 117 o integrates those features with other WebRTC voice, video and data 118 features 120 o leverages the SDP-based negotiation already defined for MSRP 122 o allows the interworking with MSRP endpoints running on a TCP or 123 TLS connection 125 Compared to WebSockets, which provide a message passing protocol to 126 applications with no direct access to TCP or TLS sockets, data 127 channels provide a low latency transport, leverage NAT-aware 128 connectivity and security features of WebRTC. 130 Considering an MSRP endpoint as an MSRP application that uses a 131 WebRTC data channel, this document describes two configurations where 132 the other endpoint is respectively either another MSRP over data 133 channel endpoint (e.g., a WebRTC application) or an MSRP endpoint 134 using either TCP or TLS transport. 136 This document updates [RFC4975] as described in Section 7. 138 2. Conventions 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119][RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 3. WebRTC Data Channel Considerations 148 3.1. MSRP Data Channel 150 The following WebRTC data channel property values 151 [I-D.ietf-rtcweb-data-channel] apply to an MSRP data channel: 153 +--------------------------+------------------+ 154 | Property | Value | 155 +--------------------------+------------------+ 156 | Subprotocol Identifier | msrp | 157 | Transmission reliability | reliable | 158 | Transmission order | in-order | 159 | Label | See Section 4.3 | 160 +--------------------------+------------------+ 162 4. SDP Considerations 164 The generic SDP considerations, including the SDP offer/answer 165 procedures [RFC3264], for negotiating a WebRTC data channel are 166 defined in [I-D.ietf-mmusic-data-channel-sdpneg]. This section, and 167 its subsections, define the SDP considerations that are specific to 168 an MSRP data channel, identified by the 'subprotocol' attribute 169 parameter, with a "msrp" parameter value, in the 'dcmap' attribute. 171 4.1. MSRP URI 173 This document extends the MSRP URI syntax [RFC4975] by defining the 174 new transport parameter value "dc" (an abbreviation of data channel): 176 transport /= "dc" 177 ; Add "dc" to existing transports per Section 9 of [RFC4975] 179 MSRP design provides for new transport bindings (see Section 6 of 180 [RFC4975]). MSRP implementations are expected to allow unrecognized 181 transports for which there is no need to establish a connection to 182 the resource described by the URI, as it's the case of data channels 183 (Section 4.4). 185 4.2. msrp-scheme 187 The msrp-scheme portion of the MSRP-URI that represents an MSRP data 188 channel endpoint (used in the SDP path attribute and in the MSRP 189 message headers) is always "msrps", which indicates that the MSRP 190 data channel is always secured using DTLS as described in 191 [I-D.ietf-rtcweb-data-channel]. 193 4.3. Use of the dcmap Attribute 195 An offerer and answerer SHALL, in each offer and answer, include a 196 'dcmap' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the SDP 197 media description (m= section) [RFC4566] describing the SCTP 198 association [RFC4960] used to realize the MSRP data channel. 200 The attribute includes the following data channel parameters: 202 o "label=" labelstring 204 o "subprotocol=" "msrp" 206 The labelstring is set by the MSRP application according to 207 [I-D.ietf-mmusic-data-channel-sdpneg]. 209 The offerer and answerer SHALL NOT include the 'max-retr' and the 210 'max-time' attribute parameters in the 'dcmap' attribute. 212 The offerer and answerer MAY include the 'ordered' attribute 213 parameter in the 'dcmap' attribute. If included, the attribute 214 parameter value SHALL be set to "true". 216 Below is an example of a 'dcmap' attribute for an MSRP session to be 217 negotiated with stream-id=2 and label="chat": 219 a=dcmap:2 label="chat";subprotocol="msrp" 221 4.4. Use of the dcsa Attribute 223 An offerer and answerer can, in each offer and answer, include one or 224 more 'dcsa' attributes [I-D.ietf-mmusic-data-channel-sdpneg] in the 225 m= section describing the SCTP association used to realize the MSPR 226 data channel. An SDP attribute included in a 'dcsa' attribute is 227 referred to as a dcsa embedded attribute. 229 If an offerer or answerer receives a 'dcsa' attribute that contains 230 an SDP attribute which usage has not been defined for an MSRP data 231 channel, the offerer or answerer should ignore the 'dcsa' attribute, 232 following the rules in Section 6.7 of 233 [I-D.ietf-mmusic-data-channel-sdpneg]. 235 An offerer and answerer SHALL include a 'dcsa' attribute for each of 236 the following MSRP-specific SDP attributes: 238 o defined in [RFC4975]: "path". 240 o defined in [RFC6714]: "msrp-cema". 242 o defined in [RFC6135]: "setup". See Section 4.5 244 It is considered a protocol error if one or more of the dcsa embedded 245 attributes listed above are not included in an offer or answer. 247 An offerer and answerer MAY include a 'dcsa' attribute for any of the 248 following MSRP-specific SDP attributes, following the procedures 249 defined for each attribute: 251 o defined in [RFC4975]: "accept-types", "accept-wrapped-types" and 252 "max-size" 254 o defined in [RFC4566]: "sendonly", "recvonly", "inactive" and 255 "sendrecv" 257 o defined in [RFC5547]: all the parameters related to MSRP file 258 transfer. See Section 4.7. 260 A subsequent offer or answer MAY update the previously negotiated 261 MSRP subprotocol attributes while keeping the 'dcmap' attribute 262 associated with the MSRP data channel unchanged. The semantics for 263 newly negotiated MSRP subprotocol attributes are per [RFC4975]. 265 When MSRP messages are transported on a data channel, the 'path' 266 attribute is not used for routing of the messages. The MSRP data 267 channel is established using the SDP offer/answer procedures defined 268 in [I-D.ietf-mmusic-data-channel-sdpneg], and the MSRP messages are 269 then transported on that data channel. This is different from legacy 270 MSRP [RFC4975] but similar to MSRP CEMA [RFC6714]. Because of this, 271 a dcsa embedded 'msrp-cema' attribute is mandated for MSRP sessions 272 over data channels. However, when an endpoint receives an MSRP 273 message over a data channel, it MUST still perform the MSRP-URI 274 comparison procedures defined in [RFC4975]. 276 4.5. Use of the dcsa embedded setup Attribute 278 As described in Section 4.4, the usage of a dsca embedded 'setup' 279 attribute is mandated for MSRP sessions over data channels. It is 280 used to negotiate which MSRP session endpoint assumes the active role 281 as per Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975]. It 282 has no relationship with the DTLS connection establishment roles 283 [I-D.ietf-mmusic-sctp-sdp]. 285 The dcsa embedded setup attribute is of the form "a=dcsa:x 286 setup:", with x being the data channel's SCTP stream 287 identifier, so that such attribute is explicitly associated with an 288 MSRP session over a specific data channel. 290 4.6. Session Closing 292 An MSRP session is closed by closing the associated data channel, 293 following the procedures in [I-D.ietf-mmusic-data-channel-sdpneg]. 295 The port value for the "m=" line SHOULD NOT be changed (e.g. to zero) 296 when closing an MSRP session (unless all data channels are being 297 closed and the SCTP association is no longer needed), since this 298 would close the SCTP association and impact all of the data channels. 299 In all cases in [RFC4975] where the procedure calls for setting the 300 port to zero for the MSRP "m=" line in an SDP offer for TCP 301 transport, the SDP offerer of an MSRP session with data channel 302 transport SHALL remove the corresponding dcmap and dcsa attributes. 304 4.7. Support for MSRP File Transfer Function 306 SDP attributes specified in [RFC5547] for a file transfer "m=" line 307 are embedded as subprotocol-specific attributes using the syntax 308 defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 310 4.8. Example 312 Below is an example of an offer and an answer that include the 313 attributes needed to establish two MSRP sessions: one for chat and 314 one for file transfer. The example is derived from a combination of 315 examples in [RFC4975] and [RFC5547]. 317 Offer: 319 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 320 c=IN IP6 2001:db8::3 321 a=max-message-size:100000 322 a=sctp-port:5000 323 a=setup:actpass 324 a=fingerprint:SHA-256 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:\ 325 82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD 326 a=tls-id:4a756565cddef001be82 327 a=dcmap:0 label="chat";subprotocol="msrp" 328 a=dcsa:0 msrp-cema 329 a=dcsa:0 setup:active 330 a=dcsa:0 accept-types:message/cpim text/plain 331 a=dcsa:0 path:msrps://2001:db8::3:54111/si438dsaodes;dc 332 a=dcmap:2 label="file transfer";subprotocol="msrp" 333 a=dcsa:2 sendonly 334 a=dcsa:2 msrp-cema 335 a=dcsa:2 setup:active 336 a=dcsa:2 accept-types:message/cpim 337 a=dcsa:2 accept-wrapped-types:* 338 a=dcsa:2 path:msrps://2001:db8::3:54111/jshA7we;dc 339 a=dcsa:2 file-selector:name:"picture1.jpg" type:image/jpeg \ 340 size:1463440 hash:sha-256:7C:DF:3E:5D:49:6B:19:E5:12:AB:4A:AD: \ 341 4A:B1:3F:82:3E:3B:54:12:02:5D:18:DF:49:6B:19:E5:7C:AB:B9:AD 342 a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep 343 a=dcsa:2 file-disposition:attachment 344 a=dcsa:2 file-date:creation:"Tue, 11 Aug 2020 19:05:30 +0200" 345 a=dcsa:2 file-icon:cid:id2@bob.example.com 346 a=dcsa:2 file-range:1-1463440 348 Answer: 350 m=application 51444 UDP/DTLS/SCTP webrtc-datachannel 351 c=IN IP6 IP6 2001:db8::1 352 a=max-message-size:100000 353 a=sctp-port:6000 354 a=setup:passive 355 a=fingerprint:SHA-256 5D:02:3E:AD:49:6B:19:E5:7C:AB:4A:AD:B9:B1: \ 356 3F:82:18:3B:54:DF:12:6B:3E:5D:49:DF:19:E5:7C:AB:4A:5D 357 a=tls-id:65cd4a7565debe82f100 358 a=dcmap:0 label="chat";subprotocol="msrp" 359 a=dcsa:0 msrp-cema 360 a=dcsa:0 setup:passive 361 a=dcsa:0 accept-types:message/cpim text/plain 362 a=dcsa:0 path:msrps://2001:db8::1:51444/di551fsaodes;dc 363 a=dcmap:2 label="file transfer";subprotocol="msrp" 364 a=dcsa:2 recvonly 365 a=dcsa:2 msrp-cema 366 a=dcsa:2 setup:passive 367 a=dcsa:2 accept-types:message/cpim 368 a=dcsa:2 accept-wrapped-types:* 369 a=dcsa:2 path:msrps://2001:db8::1:51444/jksh7Bwc;dc 370 a=dcsa:2 file-selector:name:"picture1.jpg" type:image/jpeg \ 371 size:1463440 372 a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep 373 a=dcsa:2 file-range:1-1463440 375 Note that due to RFC formatting conventions, this document splits SDP 376 across lines whose content would exceed 72 characters. A backslash 377 character marks where this line folding has taken place. This 378 backslash and its trailing CRLF and whitespace would not appear in 379 actual SDP content. 381 5. MSRP Considerations 383 The procedures specified in [RFC4975] apply except when this document 384 specifies otherwise. This section describes the MSRP considerations 385 specific to an MSRP data channel. 387 5.1. Session Mapping 389 In this document, each MSRP session maps to one data channel exactly. 391 5.2. Session Opening 393 Section 4.5 describes how the active MSRP session endpoint role is 394 negotiated. The active MSRP session endpoint uses the data channel 395 established for this MSRP session by the generic data channel opening 396 procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 398 As soon as the WebRTC data channel is opened, the MSRP session is 399 actually opened by the active MSRP session endpoint. In order to do 400 this the active MSRP endpoint sends an MSRP SEND message (empty or 401 not) to the peer (passive) MSRP endpoint. 403 5.3. Session Closing 405 The closure of an MSRP session SHALL be signaled via SDP following 406 the requirements in Section 4.6 408 If the data channel used to transport the MSRP session fails and gets 409 torn down, the endpoints SHALL consider the MSRP session failed. An 410 MSRP endpoint MAY, based on local policy, try to negotiate a new MSRP 411 data channel. 413 5.4. Data Framing 415 Each text-based MSRP message is sent on the corresponding data 416 channel using standard MSRP framing and chunking procedures, as 417 defined in [RFC4975], with each MSRP chunk delivered in a single SCTP 418 user message. Therefore all sent MSRP chunks SHALL have lengths of 419 less than or equal to the value of the peer's "max-message-size" 420 attribute [I-D.ietf-mmusic-sctp-sdp] associated with the SCTP 421 association. 423 5.5. Data Sending, Receiving and Reporting 425 Data sending, receiving and reporting procedures SHALL conform to 426 [RFC4975]. 428 5.6. Support for MSRP File Transfer Function 430 [RFC5547] defines an end-to-end file transfer method based on MSRP 431 and the SDP offer/answer mechanism. This file transfer method is 432 also usable by MSRP endpoints using data channels, with the following 433 considerations: 435 o As an MSRP session maps to one data channel, a file transfer 436 session maps also to one data channel. 438 o SDP attributes are negotiated as specified in Section 4.7. 440 o Once the file transfer is complete, the same data channel MAY be 441 reused for another file transfer. 443 6. Gateway Considerations 445 This section describes the network configuration where one MSRP 446 endpoint uses an MSRP data channel as MSRP transport, the other MSRP 447 endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP 448 endpoints interwork via a gateway. 450 Specifically, a gateway can be configured to interwork an MSRP 451 session over a data channel with a peer that does not support data 452 channel transport in one of two ways. 454 In one model, the gateway performs as an MSRP Back-to-Back User Agent 455 (B2BUA) to interwork all the procedures as necessary between the 456 endpoints. No further specification is needed for this model. 458 Alternately, the gateway can provide transport level interworking 459 between MSRP endpoints using different transport protocols. In 460 accordance with Section 4.4, path attributes SHALL NOT be used for 461 transport level interworking. 463 When the gateway performs transport level interworking between MSRP 464 endpoints, all of the procedures in Section 5 and Section 4 apply to 465 each peer, with the following additions: 467 o The gateway SHALL use the MSRP CEMA mechanism [RFC6714] towards 468 the non-data channel endpoint. 470 o If the non-data channel endpoint does not support MSRP CEMA, 471 transport level interworking mode is not possible, the gateway 472 needs to act as an MSRP B2BUA. 474 o The gateway SHALL NOT modify the path attribute received from data 475 channel or from non-data channel endpoints. 477 o The gateway SHALL NOT modify the setup value received from data 478 channel or from non-data channel endpoints. 480 o The endpoint establishing an MSRP session using data channel 481 transport SHALL NOT request inclusion of any relays, although it 482 MAY interoperate with a peer that signals the use of relays. 484 7. Updates to RFC4975 486 This document updates [RFC4975], by allowing the usage of the "msrps" 487 scheme when the underlying connection is protected with DTLS. 489 8. Security Considerations 491 MSRP traffic over data channels is secured, including 492 confidentiality, integrity and source authentication, as specified by 493 by [I-D.ietf-rtcweb-data-channel]. However, [RFC4975] allows 494 transport of MSRP traffic over non-secured TCP connections, and does 495 not provide a mechanism to guarantee usage of TLS end-to-end. As 496 described in [RFC4975], even if TLS is used between some hops TCP 497 might still be used between other hops. Operators need to ensure 498 that proper policies are established in order to ensure that the MSRP 499 traffic is protected between endpoints. 501 [RFC5547] specifies security considerations related to the usage of 502 MSRP for file transfer. 504 [RFC7092] specifies security considerations related to B2BUAs. 506 Note that discussion in Section 14.5 of [RFC4975] on MSRP message 507 attribution to remote identities applies to data channel transport. 509 If the Session Initiation Protocol (SIP) [RFC3261] is used to 510 implement the offer/answer transactions for establishing the MSRP 511 data channel, the SIP security considerations specified in [RFC3261] 512 apply. 514 9. IANA Considerations 516 NOTE to RFC Editor: Please replace all instances of all instances of 517 RFCXXXX with the number of this RFC. 519 9.1. msrps URI scheme 521 This document modifies the usage of the msrps URI scheme, registered 522 by [RFC4975], adding DTLS as a protected transport indicated by the 523 URI scheme. 525 A reference to RFCXXXX is added to the URI scheme "msrps" in the 526 Uniform Resource Identifier (URI) Schemes Registry. 528 9.2. Subprotocol Identifier MSRP 530 A reference to RFCXXXX is added to the subprotocol identifier "msrp" 531 in the "WebSocket Subprotocol Name Registry" 533 9.3. SDP Attributes 535 This document modifies the usage of a set of SDP attributes, if any 536 of those attributes is included in an SDP 'dsca' attribute associated 537 with an MSRP data channel. The modified usage of the SDP 'setup' 538 attribute is described in Section 4.5. The usage of the other SDP 539 attributes is described in Section 4.4. 541 o "path" 543 o "msrp-cema" 545 o "accept-types" 547 o "accept-wrapped-types" 549 o "max-size" 551 o "sendonly" 553 o "recvonly" 555 o "inactive" 557 o "sendrecv" 559 o "file-selector" 561 o "file-transfer-id" 563 o "file-disposition" 565 o "file-date" 567 o "file-icon" 569 o "file-range" 570 The usage level "dcsa(msrp)" is added to the registration of the SDP 571 'setup' attribute in the Session Description Protocol (SDP) 572 Parameters "att-field" sub-registry as follows: 574 +-----------------------+-------------------------------------------+ 575 | Contact name: | IESG | 576 | Contact email: | iesg@ietf.org | 577 | Attribute name: | setup | 578 | Usage level: | dcsa(msrp) | 579 | Purpose: | Negotiate the active role of an MSRP | 580 | | session over a data channel as per | 581 | | Section 4.5 | 582 | Reference: | RFCXXXX | 583 +-----------------------+-------------------------------------------+ 585 The usage level "dcsa(msrp)" is added to the registration of the SDP 586 'path' attribute in the Session Description Protocol (SDP) Parameters 587 "att-field" sub-registry as follows: 589 +-----------------------+-------------------------------------------+ 590 | Contact name: | IESG | 591 | Contact email: | iesg@ietf.org | 592 | Attribute name: | path | 593 | Usage level: | dcsa(msrp) | 594 | Purpose: | Indicate an endpoint, but not used for | 595 | | routing, as described in Section 4.4 | 596 | Reference: | RFCXXXX | 597 +-----------------------+-------------------------------------------+ 599 The usage level "dcsa(msrp)" is added to the registration of the SDP 600 'msrp-cema' attribute in the Session Description Protocol (SDP) 601 Parameters "att-field" sub-registry as follows: 603 +-----------------------+-------------------------------------------+ 604 | Contact name: | IESG | 605 | Contact email: | iesg@ietf.org | 606 | Attribute name: | msrp-cema | 607 | Usage level: | dcsa(msrp) | 608 | Purpose: | Indicate that the routing of MSRP | 609 | | messages transported on a data channel is | 610 | | more similar to the MSRP CEMA mechanism | 611 | | than the legacy MSRP routing mechanism. | 612 | Reference: | RFCXXXX | 613 +-----------------------+-------------------------------------------+ 615 The usage level "dcsa(msrp)" is added to the registration of the SDP 616 'accept-types' attribute in the Session Description Protocol (SDP) 617 Parameters "att-field" sub-registry as follows: 619 +-----------------------+-------------------------------------------+ 620 | Contact name: | IESG | 621 | Contact email: | iesg@ietf.org | 622 | Attribute name: | accept-types | 623 | Usage level: | dcsa(msrp) | 624 | Purpose: | Contain the list of media types that the | 625 | | endpoint is willing to receive. | 626 | Reference: | RFCXXXX | 627 +-----------------------+-------------------------------------------+ 629 The usage level "dcsa(msrp)" is added to the registration of the SDP 630 'accept-wrapped-types' attribute in the Session Description Protocol 631 (SDP) Parameters "att-field" sub-registry as follows: 633 +-----------------------+-------------------------------------------+ 634 | Contact name: | IESG | 635 | Contact email: | iesg@ietf.org | 636 | Attribute name: | accept-wrapped-types | 637 | Usage level: | dcsa(msrp) | 638 | Purpose: | Contain the list of media types that the | 639 | | endpoint is willing to receive in an MSRP | 640 | | message with multipart content. | 641 | Reference: | RFCXXXX | 642 +-----------------------+-------------------------------------------+ 644 The usage level "dcsa(msrp)" is added to the registration of the SDP 645 'max-size' attribute in the Session Description Protocol (SDP) 646 Parameters "att-field" sub-registry as follows: 648 +-----------------------+-------------------------------------------+ 649 | Contact name: | IESG | 650 | Contact email: | iesg@ietf.org | 651 | Attribute name: | max-size | 652 | Usage level: | dcsa(msrp) | 653 | Purpose: | Indicate the largest message an MSRP | 654 | | endpoint wishes to accept. | 655 | Reference: | RFCXXXX | 656 +-----------------------+-------------------------------------------+ 658 The usage level "dcsa(msrp)" is added to the registration of the SDP 659 'sendonly' attribute in the Session Description Protocol (SDP) 660 Parameters "att-field" sub-registry as follows: 662 +-----------------------+-------------------------------------------+ 663 | Contact name: | IESG | 664 | Contact email: | iesg@ietf.org | 665 | Attribute name: | sendonly | 666 | Usage level: | dcsa(msrp) | 667 | Purpose: | Negotiate the direction of the media flow | 668 | | on an MSRP data channel. | 669 | Reference: | RFCXXXX | 670 +-----------------------+-------------------------------------------+ 672 The usage level "dcsa(msrp)" is added to the registration of the SDP 673 'recvonly' attribute in the Session Description Protocol (SDP) 674 Parameters "att-field" sub-registry as follows: 676 +-----------------------+-------------------------------------------+ 677 | Contact name: | IESG | 678 | Contact email: | iesg@ietf.org | 679 | Attribute name: | recvonly | 680 | Usage level: | dcsa(msrp) | 681 | Purpose: | Negotiate the direction of the media flow | 682 | | on an MSRP data channel. | 683 | Reference: | RFCXXXX | 684 +-----------------------+-------------------------------------------+ 686 The usage level "dcsa(msrp)" is added to the registration of the SDP 687 'inactive' attribute in the Session Description Protocol (SDP) 688 Parameters "att-field" sub-registry as follows: 690 +-----------------------+-------------------------------------------+ 691 | Contact name: | IESG | 692 | Contact email: | iesg@ietf.org | 693 | Attribute name: | inactive | 694 | Usage level: | dcsa(msrp) | 695 | Purpose: | Negotiate the direction of the media flow | 696 | | on an MSRP data channel. | 697 | Reference: | RFCXXXX | 698 +-----------------------+-------------------------------------------+ 700 The usage level "dcsa(msrp)" is added to the registration of the SDP 701 'sendrecv' attribute in the Session Description Protocol (SDP) 702 Parameters "att-field" sub-registry as follows: 704 +-----------------------+-------------------------------------------+ 705 | Contact name: | IESG | 706 | Contact email: | iesg@ietf.org | 707 | Attribute name: | sendrecv | 708 | Usage level: | dcsa(msrp) | 709 | Purpose: | Negotiate the direction of the media flow | 710 | | on an MSRP data channel. | 711 | Reference: | RFCXXXX | 712 +-----------------------+-------------------------------------------+ 714 The usage level "dcsa(msrp)" is added to the registration of the SDP 715 'file-selector' attribute in the Session Description Protocol (SDP) 716 Parameters "att-field" sub-registry as follows: 718 +-----------------------+-------------------------------------------+ 719 | Contact name: | IESG | 720 | Contact email: | iesg@ietf.org | 721 | Attribute name: | file-selector | 722 | Usage level: | dcsa(msrp) | 723 | Purpose: | Indicate a file in an MSRP file transfer | 724 | | negotiation. | 725 | Reference: | RFCXXXX | 726 +-----------------------+-------------------------------------------+ 728 The usage level "dcsa(msrp)" is added to the registration of the SDP 729 'file-transfer-id' attribute in the Session Description Protocol 730 (SDP) Parameters "att-field" sub-registry as follows: 732 +-----------------------+-------------------------------------------+ 733 | Contact name: | IESG | 734 | Contact email: | iesg@ietf.org | 735 | Attribute name: | file-transfer-id | 736 | Usage level: | dcsa(msrp) | 737 | Purpose: | Indicate a unique identifier of the file | 738 | | transfer operation in an MSRP file | 739 | | transfer negotiation. | 740 | Reference: | RFCXXXX | 741 +-----------------------+-------------------------------------------+ 743 The usage level "dcsa(msrp)" is added to the registration of the SDP 744 'file-disposition' attribute in the Session Description Protocol 745 (SDP) Parameters "att-field" sub-registry as follows: 747 +-----------------------+-------------------------------------------+ 748 | Contact name: | IESG | 749 | Contact email: | iesg@ietf.org | 750 | Attribute name: | file-disposition | 751 | Usage level: | dcsa(msrp) | 752 | Purpose: | Provide a suggestion to the other | 753 | | endpoint about the intended disposition | 754 | | of the file in an MSRP file transfer | 755 | | negotiation. | 756 | Reference: | RFCXXXX | 757 +-----------------------+-------------------------------------------+ 759 The usage level "dcsa(msrp)" is added to the registration of the SDP 760 'file-date' attribute in the Session Description Protocol (SDP) 761 Parameters "att-field" sub-registry as follows: 763 +-----------------------+-------------------------------------------+ 764 | Contact name: | IESG | 765 | Contact email: | iesg@ietf.org | 766 | Attribute name: | file-date | 767 | Usage level: | dcsa(msrp) | 768 | Purpose: | Indicate one or more dates related to the | 769 | | file in an MSRP file transfer | 770 | | negotiation. | 771 | Reference: | RFCXXXX | 772 +-----------------------+-------------------------------------------+ 774 The usage level "dcsa(msrp)" is added to the registration of the SDP 775 'file-icon' attribute in the Session Description Protocol (SDP) 776 Parameters "att-field" sub-registry as follows: 778 +-----------------------+-------------------------------------------+ 779 | Contact name: | IESG | 780 | Contact email: | iesg@ietf.org | 781 | Attribute name: | file-icon | 782 | Usage level: | dcsa(msrp) | 783 | Purpose: | Contain a pointer to a small preview icon | 784 | | representing the contents of the file in | 785 | | an MSRP file transfer negotiation. | 786 | Reference: | RFCXXXX | 787 +-----------------------+-------------------------------------------+ 789 The usage level "dcsa(msrp)" is added to the registration of the SDP 790 'file-range' attribute in the Session Description Protocol (SDP) 791 Parameters "att-field" sub-registry as follows: 793 +-----------------------+-------------------------------------------+ 794 | Contact name: | IESG | 795 | Contact email: | iesg@ietf.org | 796 | Attribute name: | file-range | 797 | Usage level: | dcsa(msrp) | 798 | Purpose: | Contain the range of transferred octets | 799 | | of the file in an MSRP file transfer | 800 | | negotiation. | 801 | Reference: | RFCXXXX | 802 +-----------------------+-------------------------------------------+ 804 10. Acknowledgments 806 The authors wish to acknowledge the borrowing of ideas from another 807 internet draft by Peter Dunkley and Gavin Llewellyn, and to thank 808 Flemming Andreasen, Christian Groves, Paul Kyzivat, Jonathan Lennox, 809 Uwe Rauschenbach, Albrecht Schwarz, and Keith Drage for their 810 invaluable comments. 812 Richard Ejzak, Keith Drage and Juergen Stoetzer-Bradler contributed 813 an earlier version, before the draft was re-adopted. 815 Julien Maisonneuve helped with the re-adoption of the draft, and 816 Maridi R. Makaraju (Raju) contributed valuable comments after the 817 draft was re-adopted. 819 11. References 821 11.1. Normative References 823 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 824 Requirement Levels", BCP 14, RFC 2119, 825 DOI 10.17487/RFC2119, March 1997, 826 . 828 [I-D.ietf-rtcweb-data-channel] 829 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 830 Channels", draft-ietf-rtcweb-data-channel-13 (work in 831 progress), January 2015. 833 [I-D.ietf-mmusic-data-channel-sdpneg] 834 Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. 835 Even, "SDP-based Data Channel Negotiation", draft-ietf- 836 mmusic-data-channel-sdpneg-28 (work in progress), May 837 2019. 839 [I-D.ietf-mmusic-sctp-sdp] 840 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 841 "Session Description Protocol (SDP) Offer/Answer 842 Procedures For Stream Control Transmission Protocol (SCTP) 843 over Datagram Transport Layer Security (DTLS) Transport.", 844 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 845 2017. 847 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 848 with Session Description Protocol (SDP)", RFC 3264, 849 DOI 10.17487/RFC3264, June 2002, 850 . 852 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 853 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 854 July 2006, . 856 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 857 RFC 4960, DOI 10.17487/RFC4960, September 2007, 858 . 860 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 861 "The Message Session Relay Protocol (MSRP)", RFC 4975, 862 DOI 10.17487/RFC4975, September 2007, 863 . 865 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 866 and P. Kyzivat, "A Session Description Protocol (SDP) 867 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 868 DOI 10.17487/RFC5547, May 2009, 869 . 871 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 872 for the Message Session Relay Protocol (MSRP)", RFC 6135, 873 DOI 10.17487/RFC6135, February 2011, 874 . 876 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 877 Establishment for Media Anchoring (CEMA) for the Message 878 Session Relay Protocol (MSRP)", RFC 6714, 879 DOI 10.17487/RFC6714, August 2012, 880 . 882 [RFC7977] Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G., 883 and R. Ravindranath, "The WebSocket Protocol as a 884 Transport for the Message Session Relay Protocol (MSRP)", 885 RFC 7977, DOI 10.17487/RFC7977, September 2016, 886 . 888 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 889 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 890 May 2017, . 892 11.2. Informative References 894 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 895 A., Peterson, J., Sparks, R., Handley, M., and E. 896 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 897 DOI 10.17487/RFC3261, June 2002, 898 . 900 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 901 Initiation Protocol (SIP) Back-to-Back User Agents", 902 RFC 7092, DOI 10.17487/RFC7092, December 2013, 903 . 905 Authors' Addresses 907 Jose M. Recio (editor) 908 Unaffiliated 910 Email: jose@ch3m4.com 912 Christer Holmberg 913 Ericsson 914 Hirsalantie 11 915 Jorvas 02420 916 Finland 918 Email: christer.holmberg@ericsson.com