wdiff rfc8873.alt-original rfc8873.txt



MMUSIC                                                     J.

Internet Engineering Task Force (IETF)                    JM. Recio, Ed.
Internet-Draft
Request for Comments: 8873                                  Unaffiliated
Updates: 4975 (if approved)                                                C. Holmberg
Intended status:
Category: Standards Track                                       Ericsson
Expires: February 19,
ISSN: 2070-1721                                             January 2021                               August 18, 2020

                        MSRP

        Message Session Relay Protocol (MSRP) over Data Channels
              draft-ietf-mmusic-msrp-usage-data-channel-24

Abstract

   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: connecting the connection of two MSRP data channel
   endpoints; and a gateway configuration, connecting which connects an MSRP data
   channel endpoint with an MSRP over endpoint that uses either TCP or TLS endpoint.  This
   document updates RFC4975. TLS.
   This document updates RFC4975. RFC 4975.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an 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 list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication 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 of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   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) 2020 2021 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  WebRTC Data Channel Considerations  . . . . . . . . . . . . .   4
     3.1.  MSRP Data Channel . . . . . . . . . . . . . . . . . . . .   4
   4.  SDP Considerations  . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  MSRP URI  . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  MSRP URI msrp-scheme . . . . . . . . . . . . . . . . . . . . . . .   4
     4.3.  Use of the dcmap 'dcmap' Attribute  . . . . . . . . . . . . . . .   5
     4.4.  Use of the dcsa 'dcsa' Attribute . . . . . . . . . . . . . . . .   5
     4.5.  Use of the dcsa embedded setup DCSA-Embedded 'setup' Attribute  . . . . . . . .   6
     4.6.  Session Closing . . . . . . . . . . . . . . . . . . . . .   7
     4.7.  Support for MSRP File Transfer Function . . . . . . . . .   7
     4.8.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  MSRP Considerations . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Session Mapping . . . . . . . . . . . . . . . . . . . . .   9
     5.2.  Session Opening . . . . . . . . . . . . . . . . . . . . .   9
     5.3.  Session Closing . . . . . . . . . . . . . . . . . . . . .   9
     5.4.  Data Framing  . . . . . . . . . . . . . . . . . . . . . .   9
     5.5.  Data Sending, Receiving Receiving, and Reporting . . . . . . . . . .   9
     5.6.  Support for MSRP File Transfer Function . . . . . . . . .  10
   6.  Gateway Considerations  . . . . . . . . . . . . . . . . . . .  10
   7.  Updates to RFC4975  . . . . . . . . . . . . . . . . . . . . .  11 RFC 4975
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  msrps  "msrps" URI scheme  . . . . . . . . . . . . . . . . . . . .  11
     9.2.  Subprotocol Identifier MSRP . . . . . . . . . . . . . . .  12 "msrp"
     9.3.  SDP Attributes  . . . . . . . . . . . . . . . . . . . . .  12
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  18
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     11.1.
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  18
     11.2.
     10.2.  Informative References . . . . . . . . . . . . . . . . .  20
   Acknowledgments
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1.  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 for MSRP, 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" and where the 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 sharing

   o

   *  integrates those features with other WebRTC voice, video video, and data
      features

   o

   *  leverages the SDP-based negotiation already defined for MSRP

   o

   *  allows the interworking with MSRP endpoints running on a TCP or
      TLS connection

   Compared to WebSockets, the WebSocket protocol, which provide provides a message passing message-passing
   protocol to applications with no direct access to TCP or TLS sockets,
   data channels provide a low latency transport, low-latency transport and leverage NAT-aware
   connectivity and the security features of WebRTC.

   Considering

   This document defines an MSRP data channel endpoint as an MSRP
   application that uses a WebRTC data channel, this channel for MSRP transport.  This
   document describes two configurations where
   the other for connecting such endpoint is respectively either to
   another MSRP over data channel endpoint (e.g., a WebRTC application) endpoint, or to an MSRP endpoint
   using that 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].  This section, section and its subsections, subsections define the
   SDP considerations that are specific to an MSRP data channel,
   identified by the 'subprotocol' "subprotocol" attribute parameter, with a an "msrp"
   parameter value, 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, as it's is the case of data channels
   (Section 4.4).

4.2.  MSRP URI msrp-scheme

   The msrp-scheme portion of the MSRP-URI MSRP URI that represents an MSRP data
   channel endpoint (used in the SDP path '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 the dcmap '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=" labelstring

   o

   *  "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 with stream-id=2 the "dcmap-stream-id" parameter set to 2 and label="chat": the
   "label" parameter set to "chat":

   a=dcmap:2 label="chat";subprotocol="msrp"

4.4.  Use of the dcsa '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 the
   m= "m=" section describing the SCTP association used to
   realize the MSPR MSRP data channel.  An SDP attribute included in a 'dcsa'
   attribute is referred to as a dcsa embedded DCSA-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 Section 4.5 4.5.

   It is considered a protocol error if one or more of the dcsa embedded DCSA-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
   MSRP CEMA Connection Establishment for Media Anchoring (MSRP CEMA)
   [RFC6714].  Because of this, a dcsa embedded DCSA-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 the MSRP-URI MSRP URI comparison procedures defined in [RFC4975].

4.5.  Use of the dcsa embedded setup DCSA-Embedded 'setup' Attribute

   As described in Section 4.4, the usage of a dsca embedded DCSA-embedded 'setup'
   attribute is mandated for MSRP sessions over data channels.  It is
   used to negotiate which MSRP session data 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].

   The dcsa embedded setup DCSA-embedded 'setup' attribute is of the form "a=dcsa:x
   setup:<role>", with x being the data channel's SCTP stream
   identifier, so that such the '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 data channel, 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 longer needed), 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 zero for in 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 corresponding dcmap 'dcmap' and dcsa '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-256 12: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 12: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:1463440 hash: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-256 5D: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 5D: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 SDP
   across lines whose
   content would exceed that exceeds 72 characters.  A backslash
   character marks where characters across lines, marking this line
   folding has 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 MSRP session data channel endpoint role
   is negotiated.  The active MSRP session data 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 MSRP session data channel endpoint.  In order
   to do
   this this, 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 Section 4.6 4.6.

   If the data channel used to transport the MSRP session fails and gets is
   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, Receiving Receiving, and Reporting

   Data sending, receiving receiving, 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 MSRP endpoints using data channels, 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 provide transport level transport-level interworking
   between MSRP endpoints using different transport protocols.  In
   accordance with Section 4.4, path 'path' attributes SHALL NOT be used for
   transport level
   transport-level interworking.

   When the gateway performs transport level transport-level interworking between MSRP
   endpoints, all of the procedures in Section 5 4 and Section 4 5 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 level
      transport-level interworking mode is not possible, and the gateway
      needs to act as an MSRP B2BUA.

   o

   *  The gateway SHALL NOT modify the path 'path' attribute received from
      data channel or from non-data channel endpoints.

   o

   *  The gateway SHALL NOT modify the setup '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 to RFC4975 RFC 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 data channels is secured, channels, including confidentiality, integrity
   integrity, and source authentication, is secured as specified by
   by [I-D.ietf-rtcweb-data-channel].
   [RFC8831].  However, [RFC4975] allows transport of MSRP traffic over non-secured
   nonsecured TCP connections, connections and does not provide a mechanism to
   guarantee usage of TLS end-to-end. end to end.  As described in [RFC4975], even
   if TLS is used between some hops hops, TCP might still be used between
   other hops.  Operators need to ensure
   that establish proper policies are established in 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 Considerations

   NOTE 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 the msrps "msrps" URI scheme,
   registered by [RFC4975], by adding DTLS as a protected transport
   indicated by the URI scheme.

   A reference to RFCXXXX is RFC 8873 has been added to the URI scheme "msrps" in
   the
   Uniform "Uniform Resource Identifier (URI) Schemes Registry. Schemes" registry.

9.2.  Subprotocol Identifier MSRP "msrp"

   A reference to RFCXXXX is RFC 8873 has been added to the subprotocol identifier
   "msrp" in the "WebSocket Subprotocol Name Registry" Registry".

9.3.  SDP Attributes

   This document modifies the usage of a set of SDP attributes, 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.

   *  'path'

   *  'msrp-cema'

   *  'accept-types'

   *  'accept-wrapped-types'

   *  'max-size'

   *  'sendonly'  'file-date'

   *  'recvonly'  'file-disposition'

   *  'inactive'  'file-icon'

   *  'sendrecv'  'file-range'

   *  'file-selector'

   *  'file-transfer-id'

   *  'file-disposition'  'inactive'

   *  'file-date'  'max-size'

   *  'file-icon'  'msrp-cema'

   *  'file-range'  '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-registry subregistry as follows:

   Contact name:     IESG                                      |
   Contact email:    iesg@ietf.org                             |
   Attribute name:         setup                                     |   accept-types
   Usage level:            dcsa(msrp)                                |      dcsa (msrp)
   Purpose:                Negotiate          Contain the active role list of an 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-registry subregistry 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 to          Contain the registration list of 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
   'msrp-cema' 'file-date' attribute in the Session Description Protocol
   (SDP) Parameters "att-field" sub-registry subregistry as follows:

   Contact name:     IESG                                      |
   Contact email:    iesg@ietf.org                             |
   Attribute name:         msrp-cema                                 |   file-date
   Usage level:            dcsa(msrp)                                |      dcsa (msrp)
   Purpose:          Indicate that the routing of MSRP         |
                             messages transported on a data channel is | one or more similar dates related to the file in
                     an MSRP CEMA 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-registry subregistry as follows:

   Contact name:     IESG                                      |
   Contact email:    iesg@ietf.org                             |
   Attribute name:         accept-types                              |   file-disposition
   Usage level:            dcsa(msrp)                                |      dcsa (msrp)
   Purpose:                Contain          Provide a suggestion to the list other endpoint about
                     the intended disposition of media types that the  |
                             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-registry subregistry 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 the list contents of media types that the  |
                             endpoint is willing to receive file 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-registry subregistry as follows:

   Contact name:     IESG                                      |
   Contact email:    iesg@ietf.org                             |
   Attribute name:         max-size                                  |   file-range
   Usage level:            dcsa(msrp)                                |      dcsa (msrp)
   Purpose:                Indicate          Contain the largest message range 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-registry subregistry 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 |
                             on          Indicate a file in an MSRP data 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-registry subregistry 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 direction          Indicate a unique identifier of the media flow |
                             on file transfer
                     operation in an MSRP data 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-registry subregistry 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-registry subregistry 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 of          Indicate the media flow |
                             on largest message an MSRP data 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-registry subregistry 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 a file in an data channel is more similar to
                     the MSRP file 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-registry subregistry as follows:

   Contact name:     IESG                                      |
   Contact email:    iesg@ietf.org                             |
   Attribute name:         file-transfer-id                          |   path
   Usage level:            dcsa(msrp)                                |      dcsa (msrp)
   Purpose:          Indicate a unique identifier of the file  |
                             transfer operation in an MSRP 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-registry subregistry 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 about          Negotiate the intended disposition   | direction of the file in media flow on an
                     MSRP file 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-registry subregistry as follows:

   Contact name:     IESG                                      |
   Contact email:    iesg@ietf.org                             |
   Attribute name:         file-date                                 |   sendonly
   Usage level:            dcsa(msrp)                                |      dcsa (msrp)
   Purpose:                Indicate one or more dates related to          Negotiate the |
                             file in direction of the media flow on an
                     MSRP file 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-icon' 'setup' attribute in the Session Description Protocol (SDP)
   Parameters "att-field" sub-registry subregistry as follows:

   Contact name:     IESG                                      |
   Contact email:    iesg@ietf.org                             |
   Attribute name:         file-icon                                 |   setup
   Usage level:            dcsa(msrp)                                |      dcsa (msrp)
   Purpose:                Contain a pointer to a small preview icon |
                             representing          Negotiate the contents active role of the file in  | an MSRP file transfer negotiation.        | session over a
                     data channel as per Section 4.5.
   Reference:              RFCXXXX                                   |        RFC 8873

   The usage level "dcsa(msrp)" is "dcsa (msrp)" has been added to the registration of
   the SDP
   'file-range' 'sendrecv' attribute in the Session Description Protocol
   (SDP) Parameters "att-field" sub-registry subregistry as follows:

   Contact name:     IESG                                      |
   Contact email:    iesg@ietf.org                             |
   Attribute name:         file-range                                |   sendrecv
   Usage level:            dcsa(msrp)                                |      dcsa (msrp)
   Purpose:                Contain          Negotiate the range of transferred octets   | direction of the file in media flow on an
                     MSRP file transfer      |
                             negotiation.                              | data channel.
   Reference:              RFCXXXX                                   |

11.        RFC 8873

10.  References

11.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>.

10.

Acknowledgments

   The authors wish to acknowledge the borrowing of ideas from another
   internet draft
   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 Drage, and Juergen Stoetzer-Bradler contributed
   to an earlier version, draft version of this document before the draft was re-adopted.
   readopted.

   Julien Maisonneuve helped with the re-adoption readoption of the draft, this document, and
   Maridi R. Makaraju (Raju) contributed valuable comments after the
   draft
   document was re-adopted. readopted.

Authors' Addresses

   Jose M. Recio (editor)
   Unaffiliated

   Email: jose@ch3m4.com

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   FI-02420 Jorvas 02420
   Finland

   Email: christer.holmberg@ericsson.com