MMUSIC J.Internet Engineering Task Force (IETF) JM. Recio, Ed.Internet-DraftRequest for Comments: 8873 Unaffiliated Updates: 4975(if approved)C. HolmbergIntended status:Category: Standards Track EricssonExpires: February 19,ISSN: 2070-1721 January 2021August 18, 2020 MSRPMessage Session Relay Protocol (MSRP) over Data Channelsdraft-ietf-mmusic-msrp-usage-data-channel-24Abstract This document specifies how a Web Real-Time Communication (WebRTC) data channel can be used as a transport mechanism for the Message Session Relay Protocol (MSRP) and how the Session Description Protocol (SDP) offer/answer mechanism can be used to negotiate such a data channel, referred to as an MSRP data channel. Two network configurations are supported:connectingthe connection of two MSRP data channel endpoints; and a gateway configuration,connectingwhich connects an MSRP data channel endpoint with an MSRPoverendpoint that uses either TCP orTLS endpoint. This document updates RFC4975.TLS. This document updatesRFC4975.RFC 4975. Status of This Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status ofsix monthsthis document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 19, 2021.https://www.rfc-editor.org/info/rfc8873. Copyright Notice Copyright (c)20202021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 22. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . 33. WebRTC Data Channel Considerations. . . . . . . . . . . . . 43.1. MSRP Data Channel. . . . . . . . . . . . . . . . . . . . 44. SDP Considerations. . . . . . . . . . . . . . . . . . . . . 44.1. MSRP URI. . . . . . . . . . . . . . . . . . . . . . . . 44.2. MSRP URI msrp-scheme. . . . . . . . . . . . . . . . . . . . . . . 44.3. Use of thedcmap'dcmap' Attribute. . . . . . . . . . . . . . . 54.4. Use of thedcsa'dcsa' Attribute. . . . . . . . . . . . . . . . 54.5. Use of thedcsa embedded setupDCSA-Embedded 'setup' Attribute. . . . . . . . 64.6. Session Closing. . . . . . . . . . . . . . . . . . . . . 74.7. Support for MSRP File Transfer Function. . . . . . . . . 74.8. Example. . . . . . . . . . . . . . . . . . . . . . . . . 75. MSRP Considerations. . . . . . . . . . . . . . . . . . . . . 95.1. Session Mapping. . . . . . . . . . . . . . . . . . . . . 95.2. Session Opening. . . . . . . . . . . . . . . . . . . . . 95.3. Session Closing. . . . . . . . . . . . . . . . . . . . . 95.4. Data Framing. . . . . . . . . . . . . . . . . . . . . . 95.5. Data Sending,ReceivingReceiving, and Reporting. . . . . . . . . . 95.6. Support for MSRP File Transfer Function. . . . . . . . . 106. Gateway Considerations. . . . . . . . . . . . . . . . . . . 107. Updates toRFC4975 . . . . . . . . . . . . . . . . . . . . . 11RFC 4975 8. Security Considerations. . . . . . . . . . . . . . . . . . . 119. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 119.1.msrps"msrps" URI scheme. . . . . . . . . . . . . . . . . . . . 119.2. Subprotocol IdentifierMSRP . . . . . . . . . . . . . . . 12"msrp" 9.3. SDP Attributes. . . . . . . . . . . . . . . . . . . . . 1210.Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 11.References. . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1.10.1. Normative References. . . . . . . . . . . . . . . . . . 18 11.2.10.2. Informative References. . . . . . . . . . . . . . . . . 20Acknowledgments Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . 201. Introduction The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for transmitting a series of related instant messages in the context of a session. In addition to instant messaging, MSRP can also be used for image sharing or file transfer. MSRP was initially defined in [RFC4975] to work over TCP and TLS connections, and over a WebSocket subprotocol specified by [RFC7977]. This document specifies how a Web Real-Time Communication (WebRTC) data channel[I-D.ietf-rtcweb-data-channel][RFC8831] can be used as a transport mechanism forMSRP,MSRP without the TCP and TLS layers, and how the Session Description Protocol (SDP) offer/answer mechanism for data channels[I-D.ietf-mmusic-data-channel-sdpneg][RFC8864] can be used to negotiate such a data channel. In this document, an MSRP data channel refers to a WebRTC data channel for which the instantiated subprotocol is "msrp" andwherethe data channel is negotiated using the SDP offer/answer mechanism[I-D.ietf-mmusic-data-channel-sdpneg].[RFC8864]. Defining MSRP as a data channel subprotocol has many benefits:o* provides to applications a proven protocol enabling instant messaging, file transfer, image sharingo* integrates those features with other WebRTC voice,videovideo, and data featureso* leverages the SDP-based negotiation already defined for MSRPo* allows the interworking with MSRP endpoints running on a TCP or TLS connection Compared toWebSockets,the WebSocket protocol, whichprovideprovides amessage passingmessage-passing protocol to applications with no direct access to TCP or TLS sockets, data channels provide alow latency transport,low-latency transport and leverage NAT-aware connectivity and the security features of WebRTC.ConsideringThis document defines an MSRP data channel endpoint as an MSRP application that uses a WebRTC datachannel, thischannel for MSRP transport. This document describestwoconfigurationswhere the otherfor connecting such endpointis respectively eitherto another MSRPoverdata channelendpoint (e.g., a WebRTC application)endpoint, or to an MSRP endpointusingthat uses either TCP or TLS transport. This document updates [RFC4975] as described in Section 7. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174][RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. WebRTC Data Channel Considerations 3.1. MSRP Data Channel The following WebRTC data channel property values[I-D.ietf-rtcweb-data-channel][RFC8831] apply to an MSRP data channel:+--------------------------+------------------++==========================+=================+ | Property | Value |+--------------------------+------------------++==========================+=================+ | Subprotocol Identifier | msrp | +--------------------------+-----------------+ | Transmission reliability | reliable | +--------------------------+-----------------+ | Transmission order | in-order | +--------------------------+-----------------+ | Label | See Section 4.3 |+--------------------------+------------------++--------------------------+-----------------+ Table 1 4. SDP Considerations The generic SDP considerations, including the SDP offer/answer procedures [RFC3264], for negotiating a WebRTC data channel are defined in[I-D.ietf-mmusic-data-channel-sdpneg].[RFC8864]. Thissection,section and itssubsections,subsections define the SDP considerations that are specific to an MSRP data channel, identified by the'subprotocol'"subprotocol" attribute parameter, withaan "msrp" parametervalue,value in the 'dcmap' attribute. 4.1. MSRP URI This document extends the MSRP URI syntax [RFC4975] by defining the new transport parameter value "dc" (an abbreviation of data channel): transport /= "dc" ; Add "dc" to existing transports per Section 9 of [RFC4975] MSRP design provides for new transport bindings (see Section 6 of [RFC4975]). MSRP implementations are expected to allow unrecognized transports for which there is no need to establish a connection to the resource described by the URI, asit'sis the case of data channels (Section 4.4). 4.2. MSRP URI msrp-scheme The msrp-scheme portion of theMSRP-URIMSRP URI that represents an MSRP data channel endpoint (used in the SDPpath'path' attribute and in the MSRP message headers) is always "msrps", which indicates that the MSRP data channel is always secured using DTLS as described in[I-D.ietf-rtcweb-data-channel].[RFC8831]. 4.3. Use of thedcmap'dcmap' Attribute An offerer and answerer SHALL, in each offer and answer, include a 'dcmap' attribute[I-D.ietf-mmusic-data-channel-sdpneg][RFC8864] in the SDP media description(m=("m=" section) [RFC4566] describing the SCTP association [RFC4960] used to realize the MSRP data channel. The attribute includes the following data channel parameters:o* "label=" labelstringo* "subprotocol=" "msrp" The labelstring is set by the MSRP application according to[I-D.ietf-mmusic-data-channel-sdpneg].[RFC8864]. The offerer and answerer SHALL NOT include the'max-retr'"max-retr" and the'max-time'"max-time" attribute parameters in the 'dcmap' attribute. The offerer and answerer MAY include the'ordered'"ordered" attribute parameter in the 'dcmap' attribute. If included, the attribute parameter value SHALL be set to "true". Below is an example of a 'dcmap' attribute for an MSRP session to be negotiated withstream-id=2the "dcmap-stream-id" parameter set to 2 andlabel="chat":the "label" parameter set to "chat": a=dcmap:2 label="chat";subprotocol="msrp" 4.4. Use of thedcsa'dcsa' Attribute An offerer and answerer can, in each offer and answer, include one or more'dcsa'data channel subprotocol attributes[I-D.ietf-mmusic-data-channel-sdpneg]('dcsa' attributes) [RFC8864] in them="m=" section describing the SCTP association used to realize theMSPRMSRP data channel. An SDP attribute included in a 'dcsa' attribute is referred to as adcsa embeddedDCSA-embedded attribute. If an offerer or answerer receives a 'dcsa' attribute that contains an SDP attribute for which usage has not been defined for an MSRP data channel, the offerer or answerer should ignore the 'dcsa' attribute, following the rules in Section 6.7 of[I-D.ietf-mmusic-data-channel-sdpneg].[RFC8864]. An offerer and answerer SHALL include a 'dcsa' attribute for each of the following MSRP-specific SDP attributes:o* defined in [RFC4975]:"path". o'path'. * defined in [RFC6714]:"msrp-cema". o'msrp-cema'. * defined in [RFC6135]:"setup".'setup'. See Section4.54.5. It is considered a protocol error if one or more of thedcsa embeddedDCSA-embedded attributes listed above are not included in an offer or answer. An offerer and answerer MAY include a 'dcsa' attribute for any of the following MSRP-specific SDP attributes, following the procedures defined for each attribute:o* defined in [RFC4975]:"accept-types", "accept-wrapped-types"'accept-types', 'accept-wrapped-types', and"max-size" o'max-size'. * defined in [RFC4566]:"sendonly", "recvonly", "inactive"'sendonly', 'recvonly', 'inactive', and"sendrecv" o'sendrecv'. * defined in [RFC5547]: all the parameters related to MSRP file transfer. See Section 4.7. A subsequent offer or answer MAY update the previously negotiated MSRP subprotocol attributes while keeping the 'dcmap' attribute associated with the MSRP data channel unchanged. The semantics for newly negotiated MSRP subprotocol attributes are per [RFC4975]. When MSRP messages are transported on a data channel, the 'path' attribute is not used for the routing of the messages. The MSRP data channel is established using the SDP offer/answer procedures defined in[I-D.ietf-mmusic-data-channel-sdpneg],[RFC8864], and the MSRP messages are then transported on that data channel. This is different from legacy MSRP [RFC4975] but similar to MSRPCEMAConnection Establishment for Media Anchoring (MSRP CEMA) [RFC6714]. Because of this, adcsa embeddedDCSA-embedded 'msrp-cema' attribute is mandated for MSRP sessions over data channels. However, when an endpoint receives an MSRP message over a data channel, it MUST still perform theMSRP-URIMSRP URI comparison procedures defined in [RFC4975]. 4.5. Use of thedcsa embedded setupDCSA-Embedded 'setup' Attribute As described in Section 4.4, the usage of adsca embeddedDCSA-embedded 'setup' attribute is mandated for MSRP sessions over data channels. It is used to negotiate which MSRPsessiondata channel endpoint assumes the active role as per Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975]. It has no relationship with the DTLS connection establishment roles[I-D.ietf-mmusic-sctp-sdp].[RFC8841]. Thedcsa embedded setupDCSA-embedded 'setup' attribute is of the form "a=dcsa:x setup:<role>", with x being the data channel's SCTP stream identifier, so thatsuchthe 'setup' attribute is explicitly associated with an MSRP session over a specific data channel. 4.6. Session Closing An MSRP session is closed by closing the associated datachannel,channel following the procedures in[I-D.ietf-mmusic-data-channel-sdpneg].[RFC8864]. The port value for the "m=" line SHOULD NOT be changed(e.g.(e.g., to zero) when closing an MSRP session (unless all data channels are being closed and the SCTP association is no longerneeded),needed) since this would close the SCTP association and impact all of the data channels. In all cases in [RFC4975] where the procedure calls for setting the port to zeroforin the MSRP "m=" line in an SDP offer for TCP transport, the SDP offerer of an MSRP session with data channel transport SHALL remove the correspondingdcmap'dcmap' anddcsa'dcsa' attributes. 4.7. Support for MSRP File Transfer Function SDP attributes specified in [RFC5547] for a file transfer "m=" line are embedded as subprotocol-specific attributes using the syntax defined in[I-D.ietf-mmusic-data-channel-sdpneg].[RFC8864]. 4.8. Example Below is an example of an offer and an answer that include the attributes needed to establish two MSRP sessions: one for chat and one for file transfer. The example is derived from a combination of examples in [RFC4975] and [RFC5547]. Offer: m=application 54111 UDP/DTLS/SCTP webrtc-datachannel c=IN IP6 2001:db8::3 a=max-message-size:100000 a=sctp-port:5000 a=setup:actpass a=fingerprint:SHA-25612:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:\ 82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:\ 3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD a=tls-id:4a756565cddef001be82 a=dcmap:0 label="chat";subprotocol="msrp" a=dcsa:0 msrp-cema a=dcsa:0 setup:active a=dcsa:0 accept-types:message/cpim text/plain a=dcsa:0 path:msrps://2001:db8::3:54111/si438dsaodes;dc a=dcmap:2 label="file transfer";subprotocol="msrp" a=dcsa:2 sendonly a=dcsa:2 msrp-cema a=dcsa:2 setup:active a=dcsa:2 accept-types:message/cpim a=dcsa:2 accept-wrapped-types:* a=dcsa:2 path:msrps://2001:db8::3:54111/jshA7we;dc a=dcsa:2 file-selector:name:"picture1.jpg" type:image/jpeg \ size:1463440hash:sha-256:7C:DF:3E:5D:49:6B:19:E5:12:AB:4A:AD: \hash:sha-256:7C:DF:3E:5D:49:6B:19:E5:12:AB:4A:AD:\ 4A:B1:3F:82:3E:3B:54:12:02:5D:18:DF:49:6B:19:E5:7C:AB:B9:AD a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep a=dcsa:2 file-disposition:attachment a=dcsa:2 file-date:creation:"Tue, 11 Aug 2020 19:05:30 +0200" a=dcsa:2 file-icon:cid:id2@bob.example.com a=dcsa:2 file-range:1-1463440 Answer: m=application 51444 UDP/DTLS/SCTP webrtc-datachannel c=IN IP6 IP6 2001:db8::1 a=max-message-size:100000 a=sctp-port:6000 a=setup:passive a=fingerprint:SHA-2565D:02:3E:AD:49:6B:19:E5:7C:AB:4A:AD:B9:B1: \ 3F:82:18:3B:54:DF:12:6B:3E:5D:49:DF:19:E5:7C:AB:4A:5D5D:02:3E:AD:49:6B:19:E5:7C:AB:4A:AD:B9:\ B1:3F:82:18:3B:54:DF:12:6B:3E:5D:49:DF:19:E5:7C:AB:4A:5D a=tls-id:65cd4a7565debe82f100 a=dcmap:0 label="chat";subprotocol="msrp" a=dcsa:0 msrp-cema a=dcsa:0 setup:passive a=dcsa:0 accept-types:message/cpim text/plain a=dcsa:0 path:msrps://2001:db8::1:51444/di551fsaodes;dc a=dcmap:2 label="file transfer";subprotocol="msrp" a=dcsa:2 recvonly a=dcsa:2 msrp-cema a=dcsa:2 setup:passive a=dcsa:2 accept-types:message/cpim a=dcsa:2 accept-wrapped-types:* a=dcsa:2 path:msrps://2001:db8::1:51444/jksh7Bwc;dc a=dcsa:2 file-selector:name:"picture1.jpg" type:image/jpeg \ size:1463440 a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep a=dcsa:2 file-range:1-1463440 Note that due to RFC formatting conventions, this document splits SDPacross lines whosecontentwould exceedthat exceeds 72characters. A backslash character marks wherecharacters across lines, marking this line foldinghas taken place.with a backslash character. This backslash and its trailing CRLF and whitespace would not appear in actual SDP content. 5. MSRP Considerations The procedures specified in [RFC4975] apply except when this document specifies otherwise. This section describes the MSRP considerations specific to an MSRP data channel. 5.1. Session Mapping In this document, each MSRP session maps to one data channel exactly. 5.2. Session Opening Section 4.5 describes how the active MSRPsessiondata channel endpoint role is negotiated. The active MSRPsessiondata channel endpoint uses the data channel established for this MSRP session by the generic data channel opening procedure defined in[I-D.ietf-mmusic-data-channel-sdpneg].[RFC8864]. As soon as the WebRTC data channel is opened, the MSRP session is actually opened by the active MSRPsessiondata channel endpoint. In order to dothisthis, the active MSRP data channel endpoint sends an MSRP SEND message (empty or not) to the peer (passive) MSRP data channel endpoint. 5.3. Session Closing The closure of an MSRP session SHALL be signaled via SDP following the requirements in Section4.64.6. If the data channel used to transport the MSRP session fails andgetsis torn down, the MSRP data channel endpoints SHALL consider the MSRP session failed. An MSRP data channel endpoint MAY, based on local policy, try to negotiate a new MSRP data channel. 5.4. Data Framing Each text-based MSRP message is sent on the corresponding data channel using standard MSRP framing and chunking procedures, as defined in [RFC4975], with each MSRP chunk delivered in a single SCTP user message. Therefore all sent MSRP chunks SHALL have lengths of less than or equal to the value of the peer's"max-message-size"'max-message-size' attribute[I-D.ietf-mmusic-sctp-sdp][RFC8841] associated with the SCTP association. 5.5. Data Sending,ReceivingReceiving, and Reporting Data sending,receivingreceiving, and reporting procedures SHALL conform to [RFC4975]. 5.6. Support for MSRP File Transfer Function [RFC5547] defines an end-to-end file transfer method based on MSRP and the SDP offer/answer mechanism. This file transfer method is also usable by MSRPendpoints usingdatachannels,channel endpoints with the following considerations:o* As an MSRP session maps to one data channel, a file transfer session maps also to one data channel.o* SDP attributes are negotiated as specified in Section 4.7.o* Once the file transfer is complete, the same data channel MAY be reused for another file transfer. 6. Gateway Considerations This section describes the network configuration where one MSRP endpoint uses an MSRP data channel as MSRP transport, the other MSRP endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP endpoints interwork via a gateway. Specifically, a gateway can be configured to interwork an MSRP session over a data channel with a peer that does not support data channel transport in one of two ways. In one model, the gateway performs as an MSRP Back-to-Back User Agent (B2BUA) to interwork all the procedures as necessary between the endpoints. No further specification is needed for this model. Alternately, the gateway can providetransport leveltransport-level interworking between MSRP endpoints using different transport protocols. In accordance with Section 4.4,path'path' attributes SHALL NOT be used fortransport leveltransport-level interworking. When the gateway performstransport leveltransport-level interworking between MSRP endpoints, all of the procedures in Section54 and Section45 apply to each peer, with the following additions:o* The gateway SHALL use the MSRP CEMA mechanism [RFC6714] towards the non-data channel endpoint.o* If the non-data channel endpoint does not support MSRP CEMA,transport leveltransport-level interworking mode is not possible, and the gateway needs to act as an MSRP B2BUA.o* The gateway SHALL NOT modify thepath'path' attribute received from data channel or from non-data channel endpoints.o* The gateway SHALL NOT modify thesetup'setup' value received from data channel or from non-data channel endpoints.o* The endpoint establishing an MSRP session using data channel transport SHALL NOT request inclusion of any relays, although it MAY interoperate with a peer that signals the use of relays. 7. Updates toRFC4975RFC 4975 This document updates[RFC4975],[RFC4975] by allowing the usage of the "msrps" scheme when the underlying connection is protected with DTLS. 8. Security Considerations MSRP traffic over datachannels is secured,channels, including confidentiality,integrityintegrity, and source authentication, is secured as specified byby [I-D.ietf-rtcweb-data-channel].[RFC8831]. However, [RFC4975] allows transport of MSRP traffic overnon-securednonsecured TCPconnections,connections and does not provide a mechanism to guarantee usage of TLSend-to-end.end to end. As described in [RFC4975], even if TLS is used between somehopshops, TCP might still be used between other hops. Operators need toensure thatestablish proper policiesare establishedin order to ensure that the MSRP traffic is protected between endpoints. [RFC5547] specifies security considerations related to the usage of MSRP for file transfer. [RFC7092] specifies security considerations related to B2BUAs. Note that the discussion in Section 14.5 of [RFC4975] on MSRP message attribution to remote identities applies to data channel transport. If the Session Initiation Protocol (SIP) [RFC3261] is used to implement the offer/answer transactions for establishing the MSRP data channel, the SIP security considerations specified in [RFC3261] apply. 9. IANA ConsiderationsNOTE to RFC Editor: Please replace all instances of all instances of RFCXXXX with the number of this RFC.9.1.msrps"msrps" URI scheme This document modifies the usage of themsrps"msrps" URI scheme, registered by [RFC4975], by adding DTLS as a protected transport indicated by the URI scheme. A reference toRFCXXXX isRFC 8873 has been added to the URI scheme "msrps" in theUniform"Uniform Resource Identifier (URI)Schemes Registry.Schemes" registry. 9.2. Subprotocol IdentifierMSRP"msrp" A reference toRFCXXXX isRFC 8873 has been added to the subprotocol identifier "msrp" in the "WebSocket Subprotocol NameRegistry"Registry". 9.3. SDP Attributes This document modifies the usage of a set of SDPattributes,attributes if any of those attributes is included in an SDP'dsca''dcsa' attribute associated with an MSRP data channel. The modified usage of the SDP 'setup' attribute is described in Section 4.5. The usage of the other SDP attributes is described in Section 4.4.o "path" o "msrp-cema" o "accept-types" o "accept-wrapped-types" o "max-size" o "sendonly" o "recvonly" o "inactive" o "sendrecv" o "file-selector" o "file-transfer-id" o "file-disposition" o "file-date" o "file-icon" o "file-range"* 'accept-types' * 'accept-wrapped-types' * 'file-date' * 'file-disposition' * 'file-icon' * 'file-range' * 'file-selector' * 'file-transfer-id' * 'inactive' * 'max-size' * 'msrp-cema' * 'path' * 'recvonly' * 'sendonly' * 'sendrecv' The usage level"dcsa(msrp)" is"dcsa (msrp)" has been added to the registration of the SDP'setup''accept-types' attribute in the Session Description Protocol (SDP) Parameters "att-field"sub-registrysubregistry as follows:+-----------------------+-------------------------------------------+ |Contact name:|IESG| |Contact email:|iesg@ietf.org| |Attribute name:| setup | |accept-types Usage level:| dcsa(msrp) | |dcsa (msrp) Purpose:| NegotiateContain theactive rolelist ofan MSRP | | | session over a data channel as per | | | Section 4.5 | |media types that the endpoint is willing to receive. Reference:| RFCXXXX | +-----------------------+-------------------------------------------+RFC 8873 The usage level"dcsa(msrp)" is"dcsa (msrp)" has been added to the registration of the SDP'path''accept-wrapped-types' attribute in the Session Description Protocol (SDP) Parameters "att-field"sub-registrysubregistry as follows:+-----------------------+-------------------------------------------+ |Contact name:|IESG| |Contact email:|iesg@ietf.org| |Attribute name:| path | |accept-wrapped-types Usage level:| dcsa(msrp) | |dcsa (msrp) Purpose:| Indicate an endpoint, but not used for | | | routing, as described in Section 4.4 | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(msrp)" is added toContain theregistrationlist ofthe SDP 'msrp-cema'media types that the endpoint is willing to receive in an MSRP message with multipart content. Reference: RFC 8873 The usage level "dcsa (msrp)" has been added to the registration of the SDP 'file-date' attribute in the Session Description Protocol (SDP) Parameters "att-field"sub-registrysubregistry as follows:+-----------------------+-------------------------------------------+ |Contact name:|IESG| |Contact email:|iesg@ietf.org| |Attribute name:| msrp-cema | |file-date Usage level:| dcsa(msrp) | |dcsa (msrp) Purpose:|Indicatethat the routing of MSRP | | | messages transported on a data channel is | | |one or moresimilardates related to the file in an MSRPCEMA mechanism | | | than the legacy MSRP routing mechanism. | |file transfer negotiation. Reference:| RFCXXXX | +-----------------------+-------------------------------------------+RFC 8873 The usage level"dcsa(msrp)" is"dcsa (msrp)" has been added to the registration of the SDP'accept-types''file-disposition' attribute in the Session Description Protocol (SDP) Parameters "att-field"sub-registrysubregistry as follows:+-----------------------+-------------------------------------------+ |Contact name:|IESG| |Contact email:|iesg@ietf.org| |Attribute name:| accept-types | |file-disposition Usage level:| dcsa(msrp) | |dcsa (msrp) Purpose:| ContainProvide a suggestion to thelistother endpoint about the intended disposition ofmedia types thatthe| | | endpoint is willing to receive. | |file in an MSRP file transfer negotiation. Reference:| RFCXXXX | +-----------------------+-------------------------------------------+RFC 8873 The usage level"dcsa(msrp)" is"dcsa (msrp)" has been added to the registration of the SDP'accept-wrapped-types''file-icon' attribute in the Session Description Protocol (SDP) Parameters "att-field"sub-registrysubregistry as follows:+-----------------------+-------------------------------------------+ |Contact name:|IESG| |Contact email:|iesg@ietf.org| |Attribute name:| accept-wrapped-types | |file-icon Usage level:| dcsa(msrp) | |dcsa (msrp) Purpose:|Contain a pointer to a small preview icon representing thelistcontents ofmedia types thatthe| | | endpoint is willing to receivefile in an MSRP| | | message with multipart content. | |file transfer negotiation. Reference:| RFCXXXX | +-----------------------+-------------------------------------------+RFC 8873 The usage level"dcsa(msrp)" is"dcsa (msrp)" has been added to the registration of the SDP'max-size''file-range' attribute in the Session Description Protocol (SDP) Parameters "att-field"sub-registrysubregistry as follows:+-----------------------+-------------------------------------------+ |Contact name:|IESG| |Contact email:|iesg@ietf.org| |Attribute name:| max-size | |file-range Usage level:| dcsa(msrp) | |dcsa (msrp) Purpose:| IndicateContain thelargest messagerange of transferred octets of the file in an MSRP| | | endpoint wishes to accept. | |file transfer negotiation. Reference:| RFCXXXX | +-----------------------+-------------------------------------------+RFC 8873 The usage level"dcsa(msrp)" is"dcsa (msrp)" has been added to the registration of the SDP'sendonly''file-selector' attribute in the Session Description Protocol (SDP) Parameters "att-field"sub-registrysubregistry as follows:+-----------------------+-------------------------------------------+ |Contact name:|IESG| |Contact email:|iesg@ietf.org| |Attribute name:| sendonly | |file-selector Usage level:| dcsa(msrp) | |dcsa (msrp) Purpose:| Negotiate the direction of the media flow | | | onIndicate a file in an MSRPdata channel. | |file transfer negotiation. Reference:| RFCXXXX | +-----------------------+-------------------------------------------+RFC 8873 The usage level"dcsa(msrp)" is"dcsa (msrp)" has been added to the registration of the SDP'recvonly''file-transfer-id' attribute in the Session Description Protocol (SDP) Parameters "att-field"sub-registrysubregistry as follows:+-----------------------+-------------------------------------------+ |Contact name:|IESG| |Contact email:|iesg@ietf.org| |Attribute name:| recvonly | |file-transfer-id Usage level:| dcsa(msrp) | |dcsa (msrp) Purpose:| Negotiate the directionIndicate a unique identifier of themedia flow | | | onfile transfer operation in an MSRPdata channel. | |file transfer negotiation. Reference:| RFCXXXX | +-----------------------+-------------------------------------------+RFC 8873 The usage level"dcsa(msrp)" is"dcsa (msrp)" has been added to the registration of the SDP 'inactive' attribute in the Session Description Protocol (SDP) Parameters "att-field"sub-registrysubregistry as follows:+-----------------------+-------------------------------------------+ |Contact name:|IESG| |Contact email:|iesg@ietf.org| |Attribute name:|inactive| |Usage level:| dcsa(msrp) | |dcsa (msrp) Purpose:|Negotiate the direction of the media flow| | |on an MSRP data channel.| |Reference:| RFCXXXX | +-----------------------+-------------------------------------------+RFC 8873 The usage level"dcsa(msrp)" is"dcsa (msrp)" has been added to the registration of the SDP'sendrecv''max-size' attribute in the Session Description Protocol (SDP) Parameters "att-field"sub-registrysubregistry as follows:+-----------------------+-------------------------------------------+ |Contact name:|IESG| |Contact email:|iesg@ietf.org| |Attribute name:| sendrecv | |max-size Usage level:| dcsa(msrp) | |dcsa (msrp) Purpose:| Negotiate the direction ofIndicate themedia flow | | | onlargest message an MSRPdata channel. | |endpoint wishes to accept. Reference:| RFCXXXX | +-----------------------+-------------------------------------------+RFC 8873 The usage level"dcsa(msrp)" is"dcsa (msrp)" has been added to the registration of the SDP'file-selector''msrp-cema' attribute in the Session Description Protocol (SDP) Parameters "att-field"sub-registrysubregistry as follows:+-----------------------+-------------------------------------------+ |Contact name:|IESG| |Contact email:|iesg@ietf.org| |Attribute name:| file-selector | |msrp-cema Usage level:| dcsa(msrp) | |dcsa (msrp) Purpose:|Indicate that the routing of MSRP messages transported on afile in andata channel is more similar to the MSRPfile transfer | | | negotiation. | |CEMA mechanism than the legacy MSRP routing mechanism. Reference:| RFCXXXX | +-----------------------+-------------------------------------------+RFC 8873 The usage level"dcsa(msrp)" is"dcsa (msrp)" has been added to the registration of the SDP'file-transfer-id''path' attribute in the Session Description Protocol (SDP) Parameters "att-field"sub-registrysubregistry as follows:+-----------------------+-------------------------------------------+ |Contact name:|IESG| |Contact email:|iesg@ietf.org| |Attribute name:| file-transfer-id | |path Usage level:| dcsa(msrp) | |dcsa (msrp) Purpose:|Indicatea unique identifier of the file | | | transfer operation inanMSRP file | | | transfer negotiation. | |endpoint, but not used for routing, as described in Section 4.4. Reference:| RFCXXXX | +-----------------------+-------------------------------------------+RFC 8873 The usage level"dcsa(msrp)" is"dcsa (msrp)" has been added to the registration of the SDP'file-disposition''recvonly' attribute in the Session Description Protocol (SDP) Parameters "att-field"sub-registrysubregistry as follows:+-----------------------+-------------------------------------------+ |Contact name:|IESG| |Contact email:|iesg@ietf.org| |Attribute name:| file-disposition | |recvonly Usage level:| dcsa(msrp) | |dcsa (msrp) Purpose:| Provide a suggestion to the other | | | endpoint aboutNegotiate theintended disposition | | |direction of thefile inmedia flow on an MSRPfile transfer | | | negotiation. | |data channel. Reference:| RFCXXXX | +-----------------------+-------------------------------------------+RFC 8873 The usage level"dcsa(msrp)" is"dcsa (msrp)" has been added to the registration of the SDP'file-date''sendonly' attribute in the Session Description Protocol (SDP) Parameters "att-field"sub-registrysubregistry as follows:+-----------------------+-------------------------------------------+ |Contact name:|IESG| |Contact email:|iesg@ietf.org| |Attribute name:| file-date | | Usage level: | dcsa(msrp) | | Purpose: | Indicate one or more dates related to the | | | file in an MSRP file transfer | | | negotiation. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(msrp)" is added to the registration of the SDP 'file-icon' attribute in the Session Description Protocol (SDP) Parameters "att-field" sub-registry as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | file-icon | |sendonly Usage level:| dcsa(msrp) | |dcsa (msrp) Purpose:| Contain a pointer to a small preview icon | | | representingNegotiate thecontentsdirection of thefile in | | |media flow on an MSRPfile transfer negotiation. | |data channel. Reference:| RFCXXXX | +-----------------------+-------------------------------------------+RFC 8873 The usage level"dcsa(msrp)" is"dcsa (msrp)" has been added to the registration of the SDP'file-range''setup' attribute in theSession Description Protocol (SDP) Parameters"att-field"sub-registrysubregistry as follows:+-----------------------+-------------------------------------------+ |Contact name:|IESG| |Contact email:|iesg@ietf.org| |Attribute name:| file-range | |setup Usage level:| dcsa(msrp) | |dcsa (msrp) Purpose:| ContainNegotiate therange of transferred octets | | |active role ofthe file inan MSRPfile transfer | | | negotiation. | |session over a data channel as per Section 4.5. Reference:| RFCXXXX | +-----------------------+-------------------------------------------+ 10. Acknowledgments The authors wish to acknowledge the borrowing of ideas from another internet draft by Peter Dunkley and Gavin Llewellyn, and to thank Flemming Andreasen, Christian Groves, Paul Kyzivat, Jonathan Lennox, Uwe Rauschenbach, Albrecht Schwarz, and Keith Drage for their invaluable comments. Richard Ejzak, Keith Drage and Juergen Stoetzer-Bradler contributed an earlier version, before the draft was re-adopted. Julien Maisonneuve helped withRFC 8873 The usage level "dcsa (msrp)" has been added to there-adoptionregistration of thedraft, and Maridi R. Makaraju (Raju) contributed valuable comments afterSDP 'sendrecv' attribute in thedraft was re-adopted. 11.Session Description Protocol (SDP) Parameters "att-field" subregistry as follows: Contact name: IESG Contact email: iesg@ietf.org Attribute name: sendrecv Usage level: dcsa (msrp) Purpose: Negotiate the direction of the media flow on an MSRP data channel. Reference: RFC 8873 10. References11.1.10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.[I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-13 (work in progress), January 2015. [I-D.ietf-mmusic-data-channel-sdpneg] Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. Even, "SDP-based Data Channel Negotiation", draft-ietf- mmusic-data-channel-sdpneg-28 (work in progress), May 2019. [I-D.ietf-mmusic-sctp-sdp] Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, "Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport.", draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 2017.[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>. [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>. [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, <https://www.rfc-editor.org/info/rfc4975>. [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., and P. Kyzivat, "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", RFC 5547, DOI 10.17487/RFC5547, May 2009, <https://www.rfc-editor.org/info/rfc5547>. [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model for the Message Session Relay Protocol (MSRP)", RFC 6135, DOI 10.17487/RFC6135, February 2011, <https://www.rfc-editor.org/info/rfc6135>. [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)", RFC 6714, DOI 10.17487/RFC6714, August 2012, <https://www.rfc-editor.org/info/rfc6714>. [RFC7977] Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G., and R. Ravindranath, "The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)", RFC 7977, DOI 10.17487/RFC7977, September 2016, <https://www.rfc-editor.org/info/rfc7977>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.11.2.[RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, <https://www.rfc-editor.org/info/rfc8831>. [RFC8841] Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, "Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport", RFC 8841, DOI 10.17487/RFC8841, January 2021, <https://www.rfc-editor.org/info/rfc8841>. [RFC8864] Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. Even, Ed., "Negotiation Data Channels Using the Session Description Protocol (SDP)", RFC 8864, DOI 10.17487/RFC8864, January 2021, <https://www.rfc-editor.org/info/rfc8864>. 10.2. Informative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>. [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013, <https://www.rfc-editor.org/info/rfc7092>. Acknowledgments The authors wish to acknowledge the borrowing of ideas from another Internet-Draft by Peter Dunkley and Gavin Llewellyn, and to thank Flemming Andreasen, Christian Groves, Paul Kyzivat, Jonathan Lennox, Uwe Rauschenbach, Albrecht Schwarz, and Keith Drage for their invaluable comments. Richard Ejzak, Keith Drage, and Juergen Stoetzer-Bradler contributed to an earlier draft version of this document before the draft was readopted. Julien Maisonneuve helped with the readoption of this document, and Maridi R. Makaraju (Raju) contributed valuable comments after the document was readopted. Authors' Addresses Jose M. Recio (editor) Unaffiliated Email: jose@ch3m4.com Christer Holmberg Ericsson Hirsalantie 11 FI-02420 Jorvas02420Finland Email: christer.holmberg@ericsson.com