RFC 8873

Message Session Relay Protocol (MSRP) over Data Channels

📅 published January 2021, from ietf

RFC 8873: Message Session Relay Protocol (MSRP) over Data Channels 🎀

bestie, this one is the spec for running MSRP chats over a WebRTC data channel 💬✨ It's written by JM. Recio, Ed. (Unaffiliated) and C. Holmberg (Ericsson). It's a Standards Track document, dated January 2021, ISSN 2070-1721, and it updates RFC 4975 🌸

Abstract

okay so this doc explains two things 💖 First, how a WebRTC data channel can carry MSRP as its transport. Second, how the SDP offer/answer mechanism can negotiate that channel, which the doc calls an MSRP data channel 🦋 It supports two network setups: two MSRP data channel endpoints connecting directly, and a gateway that links an MSRP data channel endpoint to a normal MSRP endpoint running over TCP or TLS 🧚 It also updates RFC 4975 🌈

Status of This Memo

this is an Internet Standards Track document 💅

it's a product of the Internet Engineering Task Force (IETF) 👑 It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 🫶 If you want more on Internet Standards, check Section 2 of RFC 7841 📚

info about the current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc8873 🔥

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. ©️💜

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they stood on the publication date 🎀 Read them carefully, because they spell out your rights and restrictions for this document 🙈 Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⚠️

Table of Contents

   1.  Introduction
   2.  Conventions
   3.  WebRTC Data Channel Considerations
     3.1.  MSRP Data Channel
   4.  SDP Considerations
     4.1.  MSRP URI
     4.2.  MSRP URI msrp-scheme
     4.3.  Use of the 'dcmap' Attribute
     4.4.  Use of the 'dcsa' Attribute
     4.5.  Use of the DCSA-Embedded 'setup' Attribute
     4.6.  Session Closing
     4.7.  Support for MSRP File Transfer Function
     4.8.  Example
   5.  MSRP Considerations
     5.1.  Session Mapping
     5.2.  Session Opening
     5.3.  Session Closing
     5.4.  Data Framing
     5.5.  Data Sending, Receiving, and Reporting
     5.6.  Support for MSRP File Transfer Function
   6.  Gateway Considerations
   7.  Updates to RFC 4975
   8.  Security Considerations
   9.  IANA Considerations
     9.1.  "msrps" URI scheme
     9.2.  Subprotocol Identifier "msrp"
     9.3.  SDP Attributes
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction ✨

okay so MSRP ([RFC4975]) is a protocol for sending a bunch of related instant messages inside one session 💬 Besides instant messaging, you can also use it for image sharing or file transfer 📸 It was first defined in [RFC4975] to run over TCP and TLS connections, and over a WebSocket subprotocol specified by [RFC7977] 🧚

this doc says how a Web Real-Time Communication (WebRTC) data channel ([RFC8831]) can be the transport for MSRP without needing the TCP and TLS layers 🦋 It also covers how the Session Description Protocol (SDP) offer/answer mechanism for data channels ([RFC8864]) can negotiate that channel 🫶

in this doc, an MSRP data channel is a WebRTC data channel where the instantiated subprotocol is msrp, and it's negotiated with the SDP offer/answer mechanism ([RFC8864]) 💖

defining MSRP as a data channel subprotocol is super worth it, bestie 🌈 Here's why:

  • it gives apps a proven protocol for instant messaging, file transfer, and image sharing 💅
  • it plays nicely with the other WebRTC voice, video, and data features 🎀
  • it reuses the SDP-based negotiation that MSRP already has 🌸
  • it lets you talk to MSRP endpoints running over TCP or TLS 🔥

the WebSocket protocol gives apps message passing but no direct access to TCP or TLS sockets 🙈 Data channels, on the other hand, give you a low-latency transport, plus NAT-aware connectivity and the security features of WebRTC ⚡ it's giving main character energy 👑

this doc defines an MSRP data channel endpoint as an MSRP app that uses a WebRTC data channel for MSRP transport 🧚 It describes setups for connecting one of these endpoints to another MSRP data channel endpoint, or to an MSRP endpoint 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] when, and only when, they appear in all capitals, as shown here.

3. WebRTC Data Channel Considerations 🌸

3.1. MSRP Data Channel 🦋

these WebRTC data channel property values ([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 for negotiating a WebRTC data channel, including the SDP offer/answer procedures ([RFC3264]), are defined in [RFC8864] 💖 This section and its subsections cover the SDP considerations that are specific to an MSRP data channel 🎀 You can spot those by the "subprotocol" attribute parameter, with the "msrp" parameter value in the 'dcmap' attribute ✨

4.1. MSRP URI 🔥

this doc extends the MSRP URI syntax ([RFC4975]) by adding a new transport parameter value, "dc", which is short for data channel 💜

       transport  /= "dc"
       ; Add "dc" to existing transports per Section 9 of [RFC4975]

MSRP is designed to support new transport bindings (see Section 6 of [RFC4975]) 🌈 MSRP implementations are expected to allow unrecognized transports when there's no need to set up a connection to the resource the URI describes, which is the case for data channels (Section 4.4) 🫶

4.2. MSRP URI msrp-scheme 🌸

the msrp-scheme part of the MSRP URI that stands for an MSRP data channel endpoint (used in the SDP 'path' attribute and in the MSRP message headers) is always msrps 💅 That tells you the MSRP data channel is always secured using DTLS, as described in [RFC8831] 🔐

4.3. Use of the 'dcmap' Attribute 💖

okay so an offerer and answerer SHALL, in each offer and answer, include a 'dcmap' attribute ([RFC8864]) in the SDP media description ("m=" section) ([RFC4566]) that describes the SCTP association ([RFC4960]) used to realize the MSRP data channel 🎀

the attribute includes these data channel parameters:

  • "label=" labelstring
  • "subprotocol=" "msrp"

the MSRP application sets the labelstring according to [RFC8864] ✨

the offerer and answerer SHALL NOT include the "max-retr" and "max-time" attribute parameters in the 'dcmap' attribute 🙈

the offerer and answerer MAY include the "ordered" attribute parameter in the 'dcmap' attribute 🦋 If they do, the attribute parameter value SHALL be set to "true" 💜

here's an example 'dcmap' attribute for an MSRP session, with the "dcmap-stream-id" parameter set to 2 and the "label" parameter set to "chat" 🍓

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

4.4. Use of the 'dcsa' Attribute 🧚

an offerer and answerer can, in each offer and answer, include one or more data channel subprotocol attributes ('dcsa' attributes) ([RFC8864]) in the "m=" section that describes the SCTP association used to realize the MSRP data channel 🌈 An SDP attribute carried inside a 'dcsa' attribute is called a DCSA-embedded attribute 💅

if an offerer or answerer gets a 'dcsa' attribute that holds an SDP attribute with no defined usage for an MSRP data channel, the offerer or answerer should ignore the 'dcsa' attribute, following the rules in Section 6.7 of [RFC8864] 🌸

an offerer and answerer SHALL include a 'dcsa' attribute for each of these MSRP-specific SDP attributes 💖

  • defined in [RFC4975]: 'path'.
  • defined in [RFC6714]: 'msrp-cema'.
  • defined in [RFC6135]: 'setup'. See Section 4.5.

leaving out one or more of the DCSA-embedded attributes above, in an offer or answer, is considered a protocol error ⚠️

an offerer and answerer MAY include a 'dcsa' attribute for any of these MSRP-specific SDP attributes, following the procedures defined for each attribute 🎀

  • defined in [RFC4975]: 'accept-types', 'accept-wrapped-types', and 'max-size'.
  • defined in [RFC4566]: 'sendonly', 'recvonly', 'inactive', and 'sendrecv'.
  • defined in [RFC5547]: all the parameters related to MSRP file transfer. See Section 4.7.

a later offer or answer MAY update the previously negotiated MSRP subprotocol attributes, while keeping the 'dcmap' attribute for the MSRP data channel unchanged ✨ Semantics for newly negotiated MSRP subprotocol attributes follow [RFC4975] 🔥

when MSRP messages travel over a data channel, the 'path' attribute isn't used to route them 🙈 The MSRP data channel is set up with the SDP offer/answer procedures in [RFC8864], and then the MSRP messages ride that channel 🦋 This is different from legacy MSRP ([RFC4975]), but it's similar to MSRP Connection Establishment for Media Anchoring (MSRP CEMA) ([RFC6714]) 🌈 Because of that, a DCSA-embedded 'msrp-cema' attribute is mandated for MSRP sessions over data channels 💜 Even so, when an endpoint gets an MSRP message over a data channel, it MUST still perform the MSRP URI comparison procedures defined in [RFC4975] 🫶

4.5. Use of the DCSA-Embedded 'setup' Attribute 💜

as we covered in Section 4.4, a DCSA-embedded 'setup' attribute is mandated for MSRP sessions over data channels 🌸 It's used to negotiate which MSRP data channel endpoint takes the active role, per Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975] 🧚 It has no relationship with the DTLS connection establishment roles ([RFC8841]) 💅

the DCSA-embedded 'setup' attribute looks like a=dcsa:x setup:<role>, where x is the data channel's SCTP stream identifier 🎀 That ties the 'setup' attribute explicitly to an MSRP session on one specific data channel ✨

4.6. Session Closing 🚪

Okay so closing an MSRP session works by closing its data channel, following the procedures in [RFC8864] 🫶

The port value for the m= line SHOULD NOT be changed (e.g., to zero) when closing an MSRP session 💅 (unless all data channels are being closed and the SCTP association is no longer needed), because that would close the SCTP association and wreck every data channel riding on it 😭 In every case where [RFC4975] tells you to set the port to zero in the MSRP m= line of an SDP offer for TCP transport, the SDP offerer of an MSRP session with data channel transport SHALL remove the corresponding dcmap and dcsa attributes ✨

4.7. Support for MSRP File Transfer Function 📁

SDP attributes specified in [RFC5547] for a file transfer m= line get embedded as subprotocol-specific attributes, using the syntax defined in [RFC8864] 🧚

4.8. Example 🎀

Here's a juicy example of an offer and an answer carrying the attributes needed to set up two MSRP sessions: one for chat and one for file transfer 💬📎 It's built from a mix 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
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:\
   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
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

Quick heads-up 👀 Because of RFC formatting conventions, this document splits SDP content that runs past 72 characters across multiple lines, and marks that line folding with a backslash character. That backslash, plus its trailing CRLF and whitespace, would not actually show up in real SDP content 🙈

5. MSRP Considerations 💖

The procedures in [RFC4975] apply, except where this document says otherwise. This section covers the MSRP considerations that are specific to an MSRP data channel 🦋

5.1. Session Mapping 🗺️

Here's the rule: each MSRP session maps to one data channel exactly. One-to-one, no sharing 💅

5.2. Session Opening 🌸

Section 4.5 describes how the active MSRP data channel endpoint role gets negotiated. The active MSRP data channel endpoint uses the data channel established for this MSRP session by the generic data channel opening procedure defined in [RFC8864] ✨

As soon as the WebRTC data channel is opened, the MSRP session is actually opened by the active MSRP data channel endpoint. To do this, the active 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.

If the data channel used to transport the MSRP session fails and gets 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. Fresh start, bestie 🔁

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]. Each MSRP chunk gets 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 attribute [RFC8841] associated with the SCTP association 📏

5.5. Data Sending, Receiving, and Reporting 📬

Data sending, receiving, and reporting procedures SHALL conform to [RFC4975]. Rules are rules 💅

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 data channel endpoints, with the following considerations:

  • As an MSRP session maps to one data channel, a file transfer session also maps to one data channel 🎀
  • SDP attributes are negotiated as specified in Section 4.7 🤝
  • 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 its MSRP transport, the other MSRP endpoint uses TLS/TCP connections as its 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 the first model, the gateway acts 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 💁

Or, alternatively, the gateway can provide transport-level interworking between MSRP endpoints that use different transport protocols. In accordance with Section 4.4, path attributes SHALL NOT be used for transport-level interworking 🚫

When the gateway performs transport-level interworking between MSRP endpoints, all of the procedures in Section 4 and Section 5 apply to each peer, with the following additions:

  • The gateway SHALL use the MSRP CEMA mechanism [RFC6714] towards the non-data channel endpoint.
  • If the non-data channel endpoint does not support MSRP CEMA, transport-level interworking mode is not possible, and the gateway needs to act as an MSRP B2BUA.
  • The gateway SHALL NOT modify the path attribute received from data channel or from non-data channel endpoints.
  • The gateway SHALL NOT modify the setup value received from data channel or from non-data channel endpoints.
  • 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 RFC 4975 🔄

This document updates [RFC4975] by allowing the usage of the "msrps" scheme when the underlying connection is protected with DTLS 🔐

8. Security Considerations 🚨

⚠️ Please read this one carefully, bestie. It's the serious bit.

MSRP traffic over data channels, including confidentiality, integrity, and source authentication, is secured as specified by [RFC8831]. However, [RFC4975] allows transport of MSRP traffic over nonsecured TCP connections, and it does not provide a mechanism to guarantee usage of TLS end to end. As described in [RFC4975], even if TLS is used between some hops, TCP might still be used between other hops. Operators need to establish proper policies 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 🗂️

9.1. "msrps" URI scheme 🔗

This document modifies the usage of the "msrps" URI scheme, registered by [RFC4975], by adding DTLS as a protected transport indicated by the URI scheme 🔒

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

9.2. Subprotocol Identifier "msrp" 🏷️

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

9.3. SDP Attributes ✨

okay so this part is all about SDP attributes 💅 If one of these shows up inside an SDP dcsa attribute tied to an MSRP data channel, its usage gets tweaked a little by this document. The setup attribute has its own modified rules in Section 4.5, and the rest of the crew is covered in Section 4.4. 🦋

Here's the full lineup:

  • 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

Next up, we're adding the usage level "dcsa (msrp)" to each of these attributes' registrations in the Session Description Protocol (SDP) Parameters registry. Here they are, one by one 🌸

For accept-types, the usage level "dcsa (msrp)" goes into the "att-field" subregistry of the Session Description Protocol (SDP) Parameters registry:

Contact name:     IESG
Contact email:    iesg@ietf.org
Attribute name:   accept-types
Usage level:      dcsa (msrp)
Purpose:          Contain the list of media types that the endpoint
                  is willing to receive.
Reference:        RFC 8873

For accept-wrapped-types, same vibe, different purpose 🎀

Contact name:     IESG
Contact email:    iesg@ietf.org
Attribute name:   accept-wrapped-types
Usage level:      dcsa (msrp)
Purpose:          Contain the list of media types that the endpoint
                  is willing to receive in an MSRP message with
                  multipart content.
Reference:        RFC 8873

For file-date:

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:        RFC 8873

For file-disposition ✨

Contact name:     IESG
Contact email:    iesg@ietf.org
Attribute name:   file-disposition
Usage level:      dcsa (msrp)
Purpose:          Provide a suggestion to the other endpoint about
                  the intended disposition of the file in an MSRP
                  file transfer negotiation.
Reference:        RFC 8873

For file-icon, which is basically a tiny preview pic of the file 🌈

Contact name:     IESG
Contact email:    iesg@ietf.org
Attribute name:   file-icon
Usage level:      dcsa (msrp)
Purpose:          Contain a pointer to a small preview icon
                  representing the contents of the file in an MSRP
                  file transfer negotiation.
Reference:        RFC 8873

For file-range:

Contact name:     IESG
Contact email:    iesg@ietf.org
Attribute name:   file-range
Usage level:      dcsa (msrp)
Purpose:          Contain the range of transferred octets of the file
                  in an MSRP file transfer negotiation.
Reference:        RFC 8873

For file-selector:

Contact name:     IESG
Contact email:    iesg@ietf.org
Attribute name:   file-selector
Usage level:      dcsa (msrp)
Purpose:          Indicate a file in an MSRP file transfer
                  negotiation.
Reference:        RFC 8873

For file-transfer-id, the unique ID for the transfer 🦋

Contact name:     IESG
Contact email:    iesg@ietf.org
Attribute name:   file-transfer-id
Usage level:      dcsa (msrp)
Purpose:          Indicate a unique identifier of the file transfer
                  operation in an MSRP file transfer negotiation.
Reference:        RFC 8873

For inactive, which negotiates the direction of the media flow on an MSRP data channel 💜

Contact name:     IESG
Contact email:    iesg@ietf.org
Attribute name:   inactive
Usage level:      dcsa (msrp)
Purpose:          Negotiate the direction of the media flow on an
                  MSRP data channel.
Reference:        RFC 8873

For max-size, the biggest message an endpoint is down to receive 🍓

Contact name:     IESG
Contact email:    iesg@ietf.org
Attribute name:   max-size
Usage level:      dcsa (msrp)
Purpose:          Indicate the largest message an MSRP endpoint
                  wishes to accept.
Reference:        RFC 8873

For msrp-cema, which signals that routing is more like the MSRP CEMA mechanism than the legacy MSRP routing 🧚

Contact name:     IESG
Contact email:    iesg@ietf.org
Attribute name:   msrp-cema
Usage level:      dcsa (msrp)
Purpose:          Indicate that the routing of MSRP messages
                  transported on a data channel is more similar to
                  the MSRP CEMA mechanism than the legacy MSRP
                  routing mechanism.
Reference:        RFC 8873

For path. Heads up, this one identifies an endpoint but is NOT used for routing, see Section 4.4 🙈

Contact name:     IESG
Contact email:    iesg@ietf.org
Attribute name:   path
Usage level:      dcsa (msrp)
Purpose:          Indicate an endpoint, but not used for routing, as
                  described in Section 4.4.
Reference:        RFC 8873

For recvonly, the direction thing again ⭐

Contact name:     IESG
Contact email:    iesg@ietf.org
Attribute name:   recvonly
Usage level:      dcsa (msrp)
Purpose:          Negotiate the direction of the media flow on an
                  MSRP data channel.
Reference:        RFC 8873

For sendonly:

Contact name:     IESG
Contact email:    iesg@ietf.org
Attribute name:   sendonly
Usage level:      dcsa (msrp)
Purpose:          Negotiate the direction of the media flow on an
                  MSRP data channel.
Reference:        RFC 8873

For setup, this one's a little different. It goes in the "att-field" subregistry (no "Session Description Protocol (SDP) Parameters" in the name this time), and it handles the active role of the MSRP session over a data channel, as per Section 4.5 👑

Contact name:     IESG
Contact email:    iesg@ietf.org
Attribute name:   setup
Usage level:      dcsa (msrp)
Purpose:          Negotiate the active role of an MSRP session over a
                  data channel as per Section 4.5.
Reference:        RFC 8873

And last but not least, sendrecv, the both-ways one 🔥

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. References ✨

10.1. Normative References

Bestie, these are the references this spec leans on. Each one is listed in full below 📚

10.2. Informative References 📚

Okay, bestie, these are the extra reads that aren't required but are lowkey essential for understanding the vibe. 🧚

Acknowledgments ✨

The authors gave a big shoutout to Peter Dunkley and Gavin Llewellyn for the ideas they borrowed from another Internet-Draft, and they thanked 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 Jorvas
Finland

Email: christer.holmberg@ericsson.com
📦 where this page comes from