rfc8873xml2.original.xml   rfc8873.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc, <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. --><!ENTI
TY DATAREQ SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf
-rtcweb-data-channel.xml">
<!ENTITY DCSDPNEG SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I
-D.ietf-mmusic-data-channel-sdpneg.xml">
<!ENTITY SDPSCTP SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-
D.ietf-mmusic-sctp-sdp.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3261.xml">
<!ENTITY RFC3264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3264.xml">
<!ENTITY RFC4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4566.xml">
<!ENTITY RFC4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4960.xml">
<!ENTITY RFC4975 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4975.xml">
<!ENTITY RFC5547 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5547.xml">
<!ENTITY RFC6135 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6135.xml">
<!ENTITY RFC6714 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6714.xml">
<!ENTITY RFC7092 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7092.xml">
<!ENTITY RFC7977 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7977.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="no" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-mmusic-msrp-usage-data-channel-24" ipr="
trust200902" updates="4975">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
docName="draft-ietf-mmusic-msrp-usage-data-channel-24"
number="8873"
ipr="trust200902"
updates="4975"
obsoletes=""
submissionType="IETF"
category="std"
consensus="true"
xml:lang="en"
tocInclude="true"
tocDepth="4"
symRefs="true"
sortRefs="true"
version="3">
<front> <!-- xml2rfc v2v3 conversion 3.2.1 -->
<!-- The abbreviated title is used in the page header - it is only necessary i
f the
full title is longer than 39 characters -->
<front>
<title abbrev="MSRP over Data Channels"> <title abbrev="MSRP over Data Channels">
MSRP over Data Channels Message Session Relay Protocol (MSRP) over Data Channels
</title> </title>
<seriesInfo name="RFC" value="8873"/>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author initials="J. M." surname="Recio" fullname="Jose M. Recio" role="editor
">
<organization>Unaffiliated</organization>
<address>
<email>jose@ch3m4.com
</email>
</address>
</author>
<author initials="C." surname="Holmberg" fullname="Christer Holmberg">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<city>Jorvas 02420</city>
<region/>
<country>Finland</country>
</postal>
<email>christer.holmberg@ericsson.com</email>
</address>
</author>
<date year="2020"/>
<!-- If the month and year are both specified and are the current ones,
xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc wi
ll fill
in the current day and month for you. If the year is not the current one, it
is
necessary to specify at least a month (xml2rfc assumes day="1" if not specifi
ed for
the purpose of calculating the expiry date). With drafts it is normally suff
icient
to specify just the year. -->
<!-- Meta-data Declarations --> <author initials="JM." surname="Recio" fullname="Jose M. Recio" role="editor">
<organization>Unaffiliated</organization>
<address>
<email>jose@ch3m4.com</email>
</address>
</author>
<author initials="C." surname="Holmberg" fullname="Christer Holmberg">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<city>Jorvas</city>
<code> 02420</code>
<country>Finland</country>
</postal>
<email>christer.holmberg@ericsson.com</email>
</address>
</author>
<date year="2021" month="January" />
<area>ART</area> <area>ART</area>
<workgroup>MMUSIC</workgroup>
<workgroup>MMUSIC</workgroup> <keyword>webrtc</keyword>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>
<t>
This document specifies how a Web Real-Time Communication (WebRTC) 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) 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 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 conf igurations are supported: such a data channel, referred to as an MSRP data channel. Two network conf igurations are supported:
connecting two MSRP data channel endpoints; and a gateway configuration, c the connection of two MSRP data channel endpoints; and a gateway configura
onnecting an MSRP data channel tion, which connects an MSRP data channel
endpoint with an MSRP over TCP or TLS endpoint. This document updates RFC4 endpoint with an MSRP endpoint that uses either TCP or TLS. This document
975. This document updates RFC4975. updates RFC 4975.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="introduction">
<t>
The Message Session Relay Protocol (MSRP) <xref target="RFC4975"/> is a pr
otocol for transmitting a series
of related instant messages in the context of a session. In addition to in
stant messaging, MSRP can also be
used for image sharing or file transfer. MSRP was initially defined in <xr
ef target="RFC4975"/> to work over
TCP and TLS connections, and over a WebSocket subprotocol specified by <xr
ef target="RFC7977"/>.
</t>
<t>
This document specifies how a Web Real-Time Communication (WebRTC)
data channel <xref target="I-D.ietf-rtcweb-data-channel"/> can be used as
a transport mechanism for MSRP,
without the TCP and TLS layers, and how the Session Description Protocol (
SDP) offer/answer
mechanism for data channels <xref target="I-D.ietf-mmusic-data-channel-sdp
neg"/> can be used
to negotiate such a data channel.
</t>
<t>
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
<xref target="I-D.ietf-mmusic-data-channel-sdpneg"/>.
</t>
<t>Defining MSRP as a data channel subprotocol has many benefits:
<list style="symbols">
<t>provides to applications a proven protocol enabling instant messaging
, file transfer, image sharing</t>
<t>integrates those features with other WebRTC voice, video and data fea
tures</t>
<t>leverages the SDP-based negotiation already defined for MSRP</t>
<t>allows the interworking with MSRP endpoints running on a TCP or TLS c
onnection</t>
</list>
</t>
<t>
Compared to WebSockets, which provide a message passing protocol to applic
ations with no direct access to
TCP or TLS sockets, data channels provide a low latency transport, leverag
e NAT-aware connectivity and
security features of WebRTC.
</t>
<t>
Considering an MSRP endpoint as an MSRP application that uses a WebRTC dat
a channel, this document describes
two configurations where the other endpoint is respectively either another
MSRP over data channel endpoint
(e.g., a WebRTC application) or an MSRP endpoint using either TCP or TLS t
ransport.
</t>
<t>
This document updates <xref target="RFC4975"/> as described in <xref targe
t="updates-to-rfc4975"/>.
</t>
</section>
<section title="Conventions">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOUL
D", "SHOULD NOT", "RECOMMENDED",
"NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interp
reted as described in BCP 14
<xref target="RFC2119"/><xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.
</t>
</section>
<section title="WebRTC Data Channel Considerations">
<section title="MSRP Data Channel" anchor="msrp-data-channel">
<t>The following WebRTC data channel property values <xref target="I-D.ietf-
rtcweb-data-channel"/> apply to an MSRP data channel:</t>
<texttable title="">
<ttcol align="left">Property</ttcol>
<ttcol align="left">Value</ttcol>
<c>Subprotocol Identifier</c>
<c>msrp</c>
<c>Transmission reliability</c>
<c>reliable</c>
<c>Transmission order</c>
<c>in-order</c>
<c>Label</c>
<c>See
<xref target="use-of-dcmap-attribute"/>
</c>
</texttable>
</section>
</section>
<section title="SDP Considerations" anchor="sdp-cons">
<t>The generic SDP considerations, including the SDP offer/answer
procedures <xref target="RFC3264"/>, for negotiating a WebRTC data chann
el are
defined in <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/>. This se
ction,
and its subsections, define the SDP considerations that are specific to
an MSRP data channel,
identified by the 'subprotocol' attribute parameter, with a "msrp" param
eter value,
in the 'dcmap' attribute.</t>
<section title="MSRP URI">
<t>This document extends the MSRP URI syntax <xref target="RFC4975"/> by d
efining the new transport parameter value "dc" (an abbreviation of data channel)
:</t>
<figure align="left" title="">
<artwork align="left"><![CDATA[
transport /= "dc"
; Add "dc" to existing transports per Section 9 of [RFC4975] ]]></artwork>
</figure>
<t>MSRP design provides for new transport bindings (see Section 6 of <xref
target="RFC4975"/>). MSRP implementations are expected to allow unrecognized tr
ansports for which there is no need to establish a connection to the resource de
scribed by the URI, as it's the case of data channels (<xref target="use-of-dcsa
-attribute"/>).</t>
</section>
<section title="msrp-scheme">
<t>The msrp-scheme portion of the MSRP-URI that represents an MSRP data ch
annel endpoint (used in the SDP 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 <xref target="I-D.ietf-rtcweb-data-channel"/>.</t>
</section>
<section title="Use of the dcmap Attribute" anchor="use-of-dcmap-attribute"
>
<t>An offerer and answerer SHALL, in each offer and answer, include a 'dcm
ap' attribute <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/> in the SDP me
dia description (m= section) <xref target="RFC4566"/> describing the SCTP associ
ation <xref target="RFC4960"/> used to realize the MSRP data channel.</t>
<t>The attribute includes the following data channel parameters:
<list style="symbols">
<t>"label=" labelstring</t>
<t>"subprotocol=" "msrp"</t>
</list>
</t>
<t>The labelstring is set by the MSRP application according to <xref targe
t="I-D.ietf-mmusic-data-channel-sdpneg"/>.</t>
<t>The offerer and answerer SHALL NOT include the 'max-retr' and the 'max-
time' attribute parameters in the 'dcmap' attribute.</t>
<t>The offerer and answerer MAY include the 'ordered' attribute parameter
in the 'dcmap' attribute. If included, the attribute parameter value SHALL be se
t to "true".</t>
<t>Below is an example of a 'dcmap' attribute for an MSRP session to be ne
gotiated with stream-id=2 and label="chat":</t>
<figure align="left" title="">
<artwork align="left"><![CDATA[
a=dcmap:2 label="chat";subprotocol="msrp"
]]></artwork>
</figure>
</section>
<section title="Use of the dcsa Attribute" anchor="use-of-dcsa-attribute">
<t>
An offerer and answerer can, in each offer and answer, include one or
more 'dcsa' attributes <xref target="I-D.ietf-mmusic-data-channel-sdpneg
"/> in
the m= section describing the SCTP association used to realize the
MSPR data channel. An SDP attribute included in a 'dcsa' attribute is re
ferred
to as a dcsa embedded attribute.
</t> </t>
</abstract>
</front>
<middle>
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t> <t>
If an offerer or answerer receives a 'dcsa' attribute that contains The Message Session Relay Protocol (MSRP) <xref target="RFC4975" format="d
an SDP attribute which usage has not been defined for an MSRP data efault"/> is a protocol for transmitting a series
channel, the offerer or answerer should ignore the 'dcsa' attribute, of related instant messages in the context of a session. In addition to in
following the rules in Section 6.7 of <xref target="I-D.ietf-mmusic-data stant messaging, MSRP can also be
-channel-sdpneg"/>. used for image sharing or file transfer. MSRP was initially defined in <xr
ef target="RFC4975" format="default"/> to work over
TCP and TLS connections, and over a WebSocket subprotocol specified by <xr
ef target="RFC7977" format="default"/>.
</t> </t>
<t> <t>
An offerer and answerer SHALL include a 'dcsa' attribute for each of the This document specifies how a Web Real-Time Communication (WebRTC)
following MSRP-specific SDP attributes: data channel <xref target="RFC8831" format="default"/> can be used as a tr
<list style="symbols"> ansport mechanism for MSRP
<t>defined in <xref target="RFC4975"/>: "path".</t> without the TCP and TLS layers, and how the Session Description Protocol (
<t>defined in <xref target="RFC6714"/>: "msrp-cema".</t> SDP) offer/answer
<t>defined in <xref target="RFC6135"/>: "setup". See <xref target="use-o mechanism for data channels <xref target="RFC8864" format="default"/> can
f-setup-attribute"/></t> be used
</list> to negotiate such a data channel.
</t> </t>
<t> <t>
It is considered a protocol error if one or more of the dcsa embedded at In this document, an MSRP data channel refers to a WebRTC data
tributes listed above are not included in an offer or answer. channel for which the instantiated subprotocol is "msrp" and
the data channel is negotiated using the SDP offer/answer mechanism
<xref target="RFC8864" format="default"/>.
</t> </t>
<t>Defining MSRP as a data channel subprotocol has many benefits:
<t>An offerer and answerer MAY include a 'dcsa' attribute for any of the f
ollowing MSRP-specific SDP attributes, following the procedures defined for each
attribute:
<list style="symbols">
<t>defined in <xref target="RFC4975"/>: "accept-types", "accept-wrapped-
types" and "max-size"</t>
<t>defined in <xref target="RFC4566"/>: "sendonly", "recvonly", "inactiv
e" and "sendrecv"</t>
<t>defined in <xref target="RFC5547"/>: all the parameters related to MS
RP file transfer. See <xref target="file_transfer_sdp"/>.</t>
</list>
</t> </t>
<ul spacing="normal">
<li>provides to applications a proven protocol enabling instant messagin
g, file transfer, image sharing</li>
<li>integrates those features with other WebRTC voice, video, and data f
eatures</li>
<li>leverages the SDP-based negotiation already defined for MSRP</li>
<li>allows the interworking with MSRP endpoints running on a TCP or TLS
connection</li>
</ul>
<t> <t>
A subsequent offer or answer MAY update the previously negotiated MSRP s Compared to the WebSocket protocol, which provides a message-passing proto
ubprotocol attributes col to applications with no direct access to
while keeping the 'dcmap' attribute associated with the MSRP data channe TCP or TLS sockets, data channels provide a low-latency transport and leve
l unchanged. The semantics rage NAT-aware connectivity and
for newly negotiated MSRP subprotocol attributes are per <xref target="R the security features of WebRTC.
FC4975"/>.
</t> </t>
<t> <t>
When MSRP messages are transported on a data channel, the 'path' attribu This document defines an MSRP data channel endpoint as an MSRP application th
te is not used for routing at
of the messages. The MSRP data channel is established using the SDP offe uses a WebRTC data channel for MSRP transport. This document describes
r/answer procedures defined configurations for connecting such endpoint to another MSRP data channel endp
in <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/>, and the MSRP me oint,
ssages are then transported or to an MSRP endpoint that uses either TCP or TLS transport.
on that data channel. This is different from legacy MSRP <xref target="R
FC4975"/> but similar to
MSRP CEMA <xref target="RFC6714"/>. Because of this, a dcsa embedded 'ms
rp-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 comparison proce
dures defined in
<xref target="RFC4975"/>.
</t> </t>
</section>
<section title="Use of the dcsa embedded setup Attribute" anchor="use-of-se
tup-attribute">
<t> <t>
As described in <xref target="use-of-dcsa-attribute"/>, the usage of a d This document updates <xref target="RFC4975" format="default"/> as describ
sca embedded 'setup' attribute is mandated for MSRP sessions over data channels. ed in <xref target="updates-to-rfc4975" format="default"/>.
It is used to negotiate which MSRP session endpoint assumes the active r
ole as per Section 4.2.2 of <xref target="RFC6135"/> and
Section 5.4 of <xref target="RFC4975"/>. It has no relationship with the
DTLS connection establishment roles <xref target="I-D.ietf-mmusic-sctp-sdp"/>.
</t> </t>
</section>
<section numbered="true" toc="default">
<name>Conventions</name>
<t> <t>
The dcsa embedded setup attribute is of the form "a=dcsa:x setup:&lt;rol The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
e&gt;", with x being the data channel's SCTP stream identifier, so that "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
such attribute is explicitly associated with an MSRP session over a spec "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
ific data channel. "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
interpreted as described in BCP 14 <xref target="RFC2119" format="default"/> <xr
ef
target="RFC8174" format="default"/> when, and only when, they appear in all capi
tals, as
shown here.
</t> </t>
</section>
<section title="Session Closing" anchor="session-closing-sdp">
<t>An MSRP session is closed by closing the associated data channel, follow
ing the procedures in <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/>.</t>
<t>The port value for the "m=" line SHOULD NOT be changed (e.g. to zero) wh
en closing an MSRP session (unless all data channels are being closed and the SC
TP association is no longer needed), since this would close the SCTP association
and impact all of the data channels. In all cases in <xref target="RFC4975"/> w
here the procedure calls for setting the port to zero for the MSRP "m=" line in
an SDP offer for TCP transport, the SDP offerer of an MSRP session with data cha
nnel transport SHALL remove the corresponding dcmap and dcsa attributes.</t>
</section> </section>
<section numbered="true" toc="default">
<name>WebRTC Data Channel Considerations</name>
<section anchor="msrp-data-channel" numbered="true" toc="default">
<name>MSRP Data Channel</name>
<t>The following WebRTC data channel property values
<xref target="RFC8831" format="default"/> apply to an MSRP data channel:</t>
<table align="center">
<thead>
<tr>
<th align="left">Property</th>
<th align="left">Value</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">Subprotocol Identifier</td>
<td align="left">msrp</td>
</tr>
<tr>
<td align="left">Transmission reliability</td>
<td align="left">reliable</td>
</tr>
<tr>
<td align="left">Transmission order</td>
<td align="left">in-order</td>
</tr>
<tr>
<td align="left">Label</td>
<td align="left">See
<xref target="use-of-dcmap-attribute" format="default"/>
</td>
</tr>
</tbody>
</table>
</section>
</section>
<section anchor="sdp-cons" numbered="true" toc="default">
<name>SDP Considerations</name>
<t>The generic SDP considerations, including the SDP offer/answer
procedures <xref target="RFC3264" format="default"/>, for negotiating a
WebRTC data channel are
defined in <xref target="RFC8864" format="default"/>. This section
and its subsections define the SDP considerations that are specific to a
n MSRP data channel,
identified by the "subprotocol" attribute parameter, with an "msrp" para
meter value
in the 'dcmap' attribute.</t>
<section numbered="true" toc="default">
<name>MSRP URI</name>
<t>This document extends the MSRP URI syntax <xref target="RFC4975" form
at="default"/> by defining the new transport parameter value "dc" (an abbreviati
on of data channel):</t>
<section title="Support for MSRP File Transfer Function" anchor="file_trans <sourcecode type="abnf"><![CDATA[
fer_sdp"> transport /= "dc"
<t>SDP attributes specified in <xref target="RFC5547"/> for a file transf ; Add "dc" to existing transports per Section 9 of [RFC4975] ]]>
er "m=" line are embedded as subprotocol-specific attributes using the syntax de </sourcecode>
fined in <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/>.</t>
</section>
<section title="Example" anchor="example-sdp-negotiation"> <t>MSRP design provides for new transport bindings (see <xref target="RF
C4975" section="6" sectionFormat="of"/>).
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 is the case of data channels (<xref target="use-of-dcsa-attribute" format="de
fault"/>).</t>
</section>
<section numbered="true" toc="default">
<name>MSRP URI msrp-scheme</name>
<t>The msrp-scheme portion of the MSRP URI that represents an MSRP data
channel endpoint (used in the SDP 'path' attribute and in the MSRP message heade
rs) is always "msrps", which indicates that the MSRP data channel is always secu
red using DTLS as described in <xref target="RFC8831" format="default"/>.</t>
</section>
<section anchor="use-of-dcmap-attribute" numbered="true" toc="default">
<name>Use of the 'dcmap' Attribute</name>
<t>An offerer and answerer <bcp14>SHALL</bcp14>, in each offer and answe
r,
include a 'dcmap' attribute <xref target="RFC8864" format="default"/> in the SDP
media description ("m=" section) <xref target="RFC4566" format="default"/> descr
ibing the SCTP association <xref target="RFC4960" format="default"/> used to rea
lize the MSRP data channel.</t>
<t>The attribute includes the following data channel parameters:
</t>
<ul spacing="normal">
<li>"label=" labelstring</li>
<li>"subprotocol=" "msrp"</li>
</ul>
<t>The labelstring is set by the MSRP application according to <xref tar
get="RFC8864" format="default"/>.</t>
<t>The offerer and answerer <bcp14>SHALL NOT</bcp14> include the
"max-retr" and the "max-time" attribute parameters in the 'dcmap' attribute.</t>
<t>The offerer and answerer <bcp14>MAY</bcp14> include the "ordered" att
ribute parameter in the 'dcmap' attribute. If included, the attribute parameter
value <bcp14>SHALL</bcp14> be set to "true".</t>
<t>Below is an example of a 'dcmap' attribute for an MSRP session to be
negotiated with the "dcmap-stream-id" parameter set to 2 and the "label" paramet
er set to "chat":</t>
<t>Below is an example of an offer and an answer that include the attribut <sourcecode type="sdp"><![CDATA[
es needed to establish two MSRP sessions: one for chat and one for file transfer a=dcmap:2 label="chat";subprotocol="msrp"
. The example is derived from a combination of examples in <xref target="RFC4975 ]]></sourcecode>
"/> and <xref target="RFC5547"/>.</t>
<figure align="left" title=""> </section>
<artwork align="left"><![CDATA[ <section anchor="use-of-dcsa-attribute" numbered="true" toc="default">
Offer: <name>Use of the 'dcsa' Attribute</name>
<t>
An offerer and answerer can, in each offer and answer, include one or
more data channel subprotocol attributes ('dcsa' attributes) <xref targe
t="RFC8864" format="default"/> in
the "m=" section describing the SCTP association used to realize the
MSRP data channel. An SDP attribute included in a 'dcsa' attribute is re
ferred
to as a DCSA-embedded attribute.
</t>
<t>
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 <xref target="RFC8864" section="6.7" sectionForma
t="of"/>.
</t>
<t>
An offerer and answerer <bcp14>SHALL</bcp14> include a 'dcsa' attribute
for each of the following MSRP-specific SDP attributes:
</t>
<ul spacing="normal">
<li>defined in <xref target="RFC4975" format="default"/>: 'path'.</li>
<li>defined in <xref target="RFC6714" format="default"/>: 'msrp-cema'.
</li>
<li>defined in <xref target="RFC6135" format="default"/>: 'setup'.
See <xref target="use-of-setup-attribute" format="default"/>.</li>
</ul>
<t>
It is considered a protocol error if one or more of the DCSA-embedded at
tributes listed above are not included in an offer or answer.
</t>
<t>An offerer and answerer <bcp14>MAY</bcp14> include a 'dcsa' attribute
for any of the following MSRP-specific SDP attributes, following the procedures
defined for each attribute:
</t>
<ul spacing="normal">
<li>defined in <xref target="RFC4975" format="default"/>: 'accept-type
s', 'accept-wrapped-types', and 'max-size'.</li>
<li>defined in <xref target="RFC4566" format="default"/>: 'sendonly',
'recvonly', 'inactive', and 'sendrecv'.</li>
<li>defined in <xref target="RFC5547" format="default"/>: all the para
meters related to MSRP file transfer. See <xref target="file_transfer_sdp" forma
t="default"/>.</li>
</ul>
<t>
A subsequent offer or answer <bcp14>MAY</bcp14> update the previously ne
gotiated MSRP subprotocol attributes
while keeping the 'dcmap' attribute associated with the MSRP data channe
l unchanged. The semantics
for newly negotiated MSRP subprotocol attributes are per <xref target="R
FC4975" format="default"/>.
</t>
<t>
When MSRP messages are transported on a data channel, the 'path' attribu
te is not used for the routing
of the messages. The MSRP data channel is established using the SDP offe
r/answer procedures defined
in <xref target="RFC8864" format="default"/>, and the MSRP messages are
then transported
on that data channel. This is different from legacy MSRP <xref target="R
FC4975" format="default"/> but similar to
MSRP Connection Establishment for Media Anchoring (MSRP CEMA) <xref tar
get="RFC6714" format="default"/>.
Because of this, a 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 <bcp14>MUST</bcp14> still perform the MSRP URI c
omparison procedures defined in
<xref target="RFC4975" format="default"/>.
</t>
</section>
<section anchor="use-of-setup-attribute" numbered="true" toc="default">
<name>Use of the DCSA-Embedded 'setup' Attribute</name>
<t>
As described in <xref target="use-of-dcsa-attribute" format="default"/>,
the usage of a
DCSA-embedded 'setup' attribute is mandated for MSRP sessions over data channels
.
It is used to negotiate which MSRP data channel endpoint assumes the act
ive role as per
<xref target="RFC6135" section="4.2.2" sectionFormat="of"/> and
<xref target="RFC4975" section="5.4" sectionFormat="of"/>. It has no rel
ationship with the DTLS connection establishment roles <xref target="RFC8841" fo
rmat="default"/>.
</t>
<t>
The DCSA-embedded 'setup' attribute is of the form
"a=dcsa:x setup:&lt;role&gt;", with x being the data channel's SCTP stre
am identifier, so that
the 'setup' attribute is explicitly associated with an MSRP session over
a specific data channel.
</t>
</section>
<section anchor="session-closing-sdp" numbered="true" toc="default">
<name>Session Closing</name>
<t>An MSRP session is closed by closing the associated data channel
following the procedures in <xref target="RFC8864" format="default"/>.</t>
<t>The port value for the "m=" line <bcp14>SHOULD NOT</bcp14>
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)
since this would close the SCTP association and impact all of the data channels.
In all cases in <xref target="RFC4975" format="default"/> where the procedure
calls for setting the port to zero in the MSRP "m=" line in an SDP offer
for TCP transport, the SDP offerer of an MSRP session with data channel transpor
t
<bcp14>SHALL</bcp14> remove the corresponding 'dcmap' and 'dcsa' attributes.</t>
</section>
<section anchor="file_transfer_sdp" numbered="true" toc="default">
<name>Support for MSRP File Transfer Function</name>
<t>SDP attributes specified in <xref target="RFC5547" format="default"/>
for a file transfer "m=" line are embedded as subprotocol-specific attributes u
sing the syntax defined in <xref target="RFC8864" format="default"/>.</t>
</section>
<section anchor="example-sdp-negotiation" numbered="true" toc="default">
<name>Example</name>
<t>Below is an example of an offer and an answer that include the attrib
utes needed to establish two MSRP sessions: one for chat and one for file transf
er. The example is derived from a combination of examples in <xref target="RFC49
75" format="default"/> and <xref target="RFC5547" format="default"/>.</t>
<t>Offer:</t>
<sourcecode type="sdp"><![CDATA[
m=application 54111 UDP/DTLS/SCTP webrtc-datachannel m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
a=max-message-size:100000 a=max-message-size:100000
a=sctp-port:5000 a=sctp-port:5000
a=setup:actpass a=setup:actpass
a=fingerprint:SHA-256 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:\ a=fingerprint:SHA-256 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:\
82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD 3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD
a=tls-id:4a756565cddef001be82 a=tls-id:4a756565cddef001be82
a=dcmap:0 label="chat";subprotocol="msrp" a=dcmap:0 label="chat";subprotocol="msrp"
a=dcsa:0 msrp-cema a=dcsa:0 msrp-cema
a=dcsa:0 setup:active a=dcsa:0 setup:active
a=dcsa:0 accept-types:message/cpim text/plain a=dcsa:0 accept-types:message/cpim text/plain
a=dcsa:0 path:msrps://2001:db8::3:54111/si438dsaodes;dc a=dcsa:0 path:msrps://2001:db8::3:54111/si438dsaodes;dc
a=dcmap:2 label="file transfer";subprotocol="msrp" a=dcmap:2 label="file transfer";subprotocol="msrp"
a=dcsa:2 sendonly a=dcsa:2 sendonly
a=dcsa:2 msrp-cema a=dcsa:2 msrp-cema
a=dcsa:2 setup:active a=dcsa:2 setup:active
a=dcsa:2 accept-types:message/cpim a=dcsa:2 accept-types:message/cpim
a=dcsa:2 accept-wrapped-types:* a=dcsa:2 accept-wrapped-types:*
a=dcsa:2 path:msrps://2001:db8::3:54111/jshA7we;dc a=dcsa:2 path:msrps://2001:db8::3:54111/jshA7we;dc
a=dcsa:2 file-selector:name:"picture1.jpg" type:image/jpeg \ 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: \ 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 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-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep
a=dcsa:2 file-disposition:attachment a=dcsa:2 file-disposition:attachment
a=dcsa:2 file-date:creation:"Tue, 11 Aug 2020 19:05:30 +0200" 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-icon:cid:id2@bob.example.com
a=dcsa:2 file-range:1-1463440 a=dcsa:2 file-range:1-1463440
Answer: ]]></sourcecode>
<t>Answer:</t>
<sourcecode type="sdp"><![CDATA[
m=application 51444 UDP/DTLS/SCTP webrtc-datachannel m=application 51444 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 IP6 2001:db8::1 c=IN IP6 IP6 2001:db8::1
a=max-message-size:100000 a=max-message-size:100000
a=sctp-port:6000 a=sctp-port:6000
a=setup:passive a=setup:passive
a=fingerprint:SHA-256 5D:02:3E:AD:49:6B:19:E5:7C:AB:4A:AD:B9:B1: \ a=fingerprint:SHA-256 5D:02:3E:AD:49:6B:19:E5:7C:AB:4A:AD:B9:\
3F:82:18:3B:54:DF:12:6B:3E:5D:49:DF:19:E5:7C:AB:4A:5D B1:3F:82:18:3B:54:DF:12:6B:3E:5D:49:DF:19:E5:7C:AB:4A:5D
a=tls-id:65cd4a7565debe82f100 a=tls-id:65cd4a7565debe82f100
a=dcmap:0 label="chat";subprotocol="msrp" a=dcmap:0 label="chat";subprotocol="msrp"
a=dcsa:0 msrp-cema a=dcsa:0 msrp-cema
a=dcsa:0 setup:passive a=dcsa:0 setup:passive
a=dcsa:0 accept-types:message/cpim text/plain a=dcsa:0 accept-types:message/cpim text/plain
a=dcsa:0 path:msrps://2001:db8::1:51444/di551fsaodes;dc a=dcsa:0 path:msrps://2001:db8::1:51444/di551fsaodes;dc
a=dcmap:2 label="file transfer";subprotocol="msrp" a=dcmap:2 label="file transfer";subprotocol="msrp"
a=dcsa:2 recvonly a=dcsa:2 recvonly
a=dcsa:2 msrp-cema a=dcsa:2 msrp-cema
a=dcsa:2 setup:passive a=dcsa:2 setup:passive
a=dcsa:2 accept-types:message/cpim a=dcsa:2 accept-types:message/cpim
a=dcsa:2 accept-wrapped-types:* a=dcsa:2 accept-wrapped-types:*
a=dcsa:2 path:msrps://2001:db8::1:51444/jksh7Bwc;dc a=dcsa:2 path:msrps://2001:db8::1:51444/jksh7Bwc;dc
a=dcsa:2 file-selector:name:"picture1.jpg" type:image/jpeg \ a=dcsa:2 file-selector:name:"picture1.jpg" type:image/jpeg \
size:1463440 size:1463440
a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep
a=dcsa:2 file-range:1-1463440 a=dcsa:2 file-range:1-1463440
]]></artwork> ]]></sourcecode>
</figure>
<t>
Note that due to RFC formatting conventions, this document splits SDP ac
ross lines whose
content would exceed 72 characters. A backslash character marks where th
is line folding
has taken place. This backslash and its trailing CRLF and whitespace wou
ld not appear
in actual SDP content.
</t>
</section>
</section>
<section title="MSRP Considerations" anchor="msrp-cons">
<t>The procedures specified in <xref target="RFC4975"/> apply except when thi <t>
s document specifies otherwise. This section describes the MSRP considerations s Note that due to RFC formatting conventions, this document splits
pecific to an MSRP data channel.</t> SDP content that exceeds 72 characters across lines, marking this
<section title="Session Mapping"> line folding with a backslash character. This backslash and its
<t>In this document, each MSRP session maps to one data channel exactly.</ trailing CRLF and whitespace would not appear in actual SDP content.
t> </t>
</section> </section>
<section title="Session Opening" anchor="session-opening-msrp">
<t><xref target="use-of-setup-attribute"/> describes how the active MSRP se
ssion endpoint role is negotiated. The active MSRP session endpoint uses the dat
a channel established for this MSRP session by the generic data channel opening
procedure defined in <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/>.</t>
<t>As soon as the WebRTC data channel is opened, the MSRP session is actual
ly opened by the active MSRP session endpoint. In order to do this the active MS
RP endpoint sends an MSRP SEND message (empty or not) to the peer (passive) MSRP
endpoint.</t>
</section> </section>
<section title="Session Closing" anchor="session-closing"> <section anchor="msrp-cons" numbered="true" toc="default">
<t>The closure of an MSRP session SHALL be signaled via SDP following the r <name>MSRP Considerations</name>
equirements in <xref target="session-closing-sdp"/></t> <t>The procedures specified in <xref target="RFC4975" format="default"/> a
<t>If the data channel used to transport the MSRP session fails and gets to pply except when this document specifies otherwise. This section describes the M
rn down, the endpoints SHALL consider the MSRP session failed. An MSRP endpoint SRP considerations specific to an MSRP data channel.</t>
MAY, based on local policy, try to negotiate a new MSRP data channel.</t> <section numbered="true" toc="default">
<name>Session Mapping</name>
<t>In this document, each MSRP session maps to one data channel exactly.
</t>
</section>
<section anchor="session-opening-msrp" numbered="true" toc="default">
<name>Session Opening</name>
<t><xref target="use-of-setup-attribute" format="default"/> describes ho
w the active MSRP data channel endpoint role is 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 <xref target="RFC8864" format
="default"/>.</t>
<t>As soon as the WebRTC data channel is opened, the MSRP session is act
ually opened by the active MSRP data channel endpoint.
In order to do this, the active MSRP data channel endpoint sends an MSRP SEND me
ssage (empty or not) to the peer (passive) MSRP data channel endpoint.</t>
</section>
<section anchor="session-closing" numbered="true" toc="default">
<name>Session Closing</name>
<t>The closure of an MSRP session <bcp14>SHALL</bcp14> be signaled via
SDP following the requirements in <xref target="session-closing-sdp" format="def
ault"/>.</t>
<t>If the data channel used to transport the MSRP session fails and is t
orn down, the MSRP data channel endpoints <bcp14>SHALL</bcp14> consider the MSRP
session failed. An MSRP data channel endpoint <bcp14>MAY</bcp14>, based on loca
l policy, try to negotiate a new MSRP data channel.</t>
</section>
<section anchor="data-framing" numbered="true" toc="default">
<name>Data Framing</name>
<t>Each text-based MSRP message is sent on the corresponding data channe
l using standard MSRP framing and chunking procedures, as defined in <xref targe
t="RFC4975" format="default"/>, with each MSRP chunk delivered in a single SCTP
user message. Therefore all sent MSRP chunks <bcp14>SHALL</bcp14> have lengths o
f less than or equal to the value of the peer's 'max-message-size' attribute <xr
ef target="RFC8841" format="default"/> associated with the SCTP association.</t>
</section>
<section numbered="true" toc="default">
<name>Data Sending, Receiving, and Reporting</name>
<t>Data sending, receiving, and reporting procedures <bcp14>SHALL</bcp14
> conform to <xref target="RFC4975" format="default"/>.</t>
</section>
<section anchor="file_transfer_msrp" numbered="true" toc="default">
<name>Support for MSRP File Transfer Function</name>
<t><xref target="RFC5547" format="default"/> 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:
</t>
<ul spacing="normal">
<li>As an MSRP session maps to one data channel, a file transfer sessi
on maps also to one data channel.</li>
<li>SDP attributes are negotiated as specified in <xref target="file_t
ransfer_sdp" format="default"/>.</li>
<li>Once the file transfer is complete, the same data channel <bcp14>M
AY</bcp14> be reused for another file transfer.</li>
</ul>
</section>
</section> </section>
<section title="Data Framing" anchor="data-framing"> <section anchor="gateway-cons" numbered="true" toc="default">
<t>Each text-based MSRP message is sent on the corresponding data channel u <name>Gateway Considerations</name>
sing standard MSRP framing and chunking procedures, as defined in <xref target=" <t>This section describes the network configuration where one MSRP endpoin
RFC4975"/>, with each MSRP chunk delivered in a single SCTP user message. Theref t uses an MSRP data channel as MSRP transport, the other MSRP endpoint uses TLS/
ore all sent MSRP chunks SHALL have lengths of less than or equal to the value o TCP connections as MSRP transport, and the two MSRP endpoints interwork via a ga
f the peer's "max-message-size" attribute <xref target="I-D.ietf-mmusic-sctp-sdp teway.</t>
"/> associated with the SCTP association.</t> <t>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.</t>
<t>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 f
urther specification is needed for this model.</t>
<t>Alternately, the gateway can provide transport-level interworking betwe
en MSRP endpoints using different transport protocols. In accordance with <xref
target="use-of-dcsa-attribute" format="default"/>,
'path' attributes <bcp14>SHALL NOT</bcp14> be used for transport-level interwork
ing.</t>
<t>When the gateway performs transport-level interworking between
MSRP endpoints, all of the procedures in <xref target="sdp-cons" format="default
"/> and
<xref target="msrp-cons" format="default"/> apply to each peer, with the followi
ng additions:
</t>
<ul spacing="normal">
<li>The gateway <bcp14>SHALL</bcp14> use the MSRP CEMA mechanism <xref t
arget="RFC6714" format="default"/> towards the non-data channel endpoint.</li>
<li>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.</li>
<li>The gateway <bcp14>SHALL NOT</bcp14> modify the 'path' attribute rec
eived from data channel or from non-data channel endpoints.</li>
<li>The gateway <bcp14>SHALL NOT</bcp14> modify the 'setup' value
received from data channel or from non-data channel endpoints.</li>
<li>The endpoint establishing an MSRP session using data channel transpo
rt <bcp14>SHALL NOT</bcp14> request inclusion of any relays, although it <bcp14>
MAY</bcp14> interoperate with a peer that signals the use of relays.</li>
</ul>
</section> </section>
<section title="Data Sending, Receiving and Reporting"> <section anchor="updates-to-rfc4975" numbered="true" toc="default">
<t>Data sending, receiving and reporting procedures SHALL conform to <xref <name>Updates to RFC 4975</name>
target="RFC4975"/>.</t> <t>This document updates <xref target="RFC4975" format="default"/>
by allowing the usage of the "msrps" scheme when the underlying connection is pr
otected with DTLS.</t>
</section> </section>
<section title="Support for MSRP File Transfer Function" anchor="file_transf <section anchor="Security" numbered="true" toc="default">
er_msrp"> <name>Security Considerations</name>
<t><xref target="RFC5547"/> defines an end-to-end file transfer method base <t>MSRP traffic over data channels, including confidentiality, integrity,
d on MSRP and the SDP offer/answer mechanism. This file transfer method is also and source authentication,
usable by MSRP endpoints using data channels, with the following considerations: is secured as specified by <xref target="RFC8831" format="default"/>.
<list style="symbols"> However, <xref target="RFC4975" format="default"/> allows transport of
<t>As an MSRP session maps to one data channel, a file transfer session m MSRP traffic over nonsecured TCP connections and does not provide a mechanism to
aps also to one data channel.</t> guarantee usage of TLS end to end.
<t>SDP attributes are negotiated as specified in <xref target="file_trans As described in <xref target="RFC4975" format="default"/>, even if TLS is
fer_sdp"/>.</t> used between some hops,
<t>Once the file transfer is complete, the same data channel MAY be reuse TCP might still be used between other hops.
d for another file transfer.</t> Operators need to establish proper policies
</list> in order to ensure that the MSRP traffic is protected between endpoints.</t>
</t> <t><xref target="RFC5547" format="default"/> specifies security considerat
ions related to the usage of MSRP for file transfer.</t>
<t><xref target="RFC7092" format="default"/> specifies security considerat
ions related to B2BUAs.</t>
<t>Note that the discussion in <xref target="RFC4975" section="14.5" secti
onFormat="of"/> on MSRP message attribution to remote identities applies to data
channel transport.</t>
<t>If the Session Initiation Protocol (SIP) <xref target="RFC3261" format=
"default"/> is used to implement the offer/answer transactions for establishing
the MSRP data channel, the SIP security considerations specified in <xref target
="RFC3261" format="default"/> apply.</t>
</section> </section>
</section> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section title="Gateway Considerations" anchor="gateway-cons"> <section anchor="IANA-reg-msrps" numbered="true" toc="default">
<name>"msrps" URI scheme</name>
<t>This section describes the network configuration where one MSRP endpoint u <t>This document modifies the usage of the "msrps" URI scheme,
ses an MSRP data channel as MSRP transport, the other MSRP endpoint uses TLS/TCP registered by <xref target="RFC4975" format="default"/>,
connections as MSRP transport, and the two MSRP endpoints interwork via a gatew by adding DTLS as a protected transport indicated by the URI scheme.</t>
ay.</t> <t>A reference to RFC 8873 has been added to the URI scheme "msrps"
in the "Uniform Resource Identifier (URI) Schemes" registry.</t>
<t>Specifically, a gateway can be configured to interwork an MSRP session ove </section>
r a data channel with a peer that does not support data channel transport in one <section anchor="IANA-reg-MSRP" numbered="true" toc="default">
of two ways.</t> <name>Subprotocol Identifier "msrp"</name>
<t>A reference to RFC 8873 has been added to the subprotocol identifier
<t>In one model, the gateway performs as an MSRP Back-to-Back User Agent (B2B "msrp" in the "WebSocket Subprotocol Name Registry".</t>
UA) to interwork all the procedures as necessary between the endpoints. No furt </section>
her specification is needed for this model.</t> <section anchor="IANA-reg-other-sdp" numbered="true" toc="default">
<name>SDP Attributes</name>
<t>Alternately, the gateway can provide transport level interworking between <t>
MSRP endpoints using different transport protocols. In accordance with <xref tar This document modifies the usage of a set of SDP attributes if any of thos
get="use-of-dcsa-attribute"/>, path attributes SHALL NOT be used for transport l e
evel interworking.</t> attributes is included in an SDP 'dcsa' attribute associated with an
MSRP data channel. The modified usage of the SDP 'setup' attribute is
<t>When the gateway performs transport level interworking between MSRP endpoi described in <xref target="use-of-setup-attribute" format="default"/>. The
nts, all of the procedures in <xref target="msrp-cons"/> and <xref target="sdp-c usage of the other
ons"/> apply to each peer, with the following additions: SDP attributes is described in <xref target="use-of-dcsa-attribute" format
="default"/>.
<list style="symbols"> </t>
<t>The gateway SHALL use the MSRP CEMA mechanism <xref target="RFC6714"/> t <ul spacing="normal">
owards the non-data channel endpoint.</t> <li>'accept-types'</li>
<t>If the non-data channel endpoint does not support MSRP CEMA, transport l <li>'accept-wrapped-types'</li>
evel interworking mode is not possible, the gateway needs to act as an MSRP B2BU <li>'file-date'</li>
A.</t> <li>'file-disposition'</li>
<t>The gateway SHALL NOT modify the path attribute received from data chann <li>'file-icon'</li>
el or from non-data channel endpoints.</t> <li>'file-range'</li>
<t>The gateway SHALL NOT modify the setup value received from data channel <li>'file-selector'</li>
or from non-data channel endpoints.</t> <li>'file-transfer-id'</li>
<t>The endpoint establishing an MSRP session using data channel transport S <li>'inactive'</li>
HALL NOT request inclusion of any relays, although it MAY interoperate with a pe <li>'max-size'</li>
er that signals the use of relays.</t> <li>'msrp-cema'</li>
</list> <li>'path'</li>
<li>'recvonly'</li>
</t> <li>'sendonly'</li>
<li>'sendrecv'</li>
</section> </ul>
<section title="Updates to RFC4975" anchor="updates-to-rfc4975">
<t>This document updates <xref target="RFC4975"/>, by allowing the usage of
the "msrps" scheme when the underlying connection is protected with DTLS.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>MSRP traffic over data channels is secured, including confidentiality, int
egrity and source authentication, as specified by by <xref target="I-D.ietf-rtcw
eb-data-channel"/>.
However, <xref target="RFC4975"/> allows transport of MSRP traffic over no
n-secured TCP connections, and does not provide a mechanism to guarantee usage o
f TLS end-to-end.
As described in <xref target="RFC4975"/>, even if TLS is used between some
hops TCP might still be used between other hops.
Operators need to ensure that proper policies are established in order to
ensure that the MSRP traffic is protected between endpoints.</t>
<t><xref target="RFC5547"/> specifies security considerations related to the
usage of MSRP for file transfer.</t>
<t><xref target="RFC7092"/> specifies security considerations related to B2BU <t>The usage level "dcsa (msrp)" has been added to the registration of t
As.</t> he SDP
'accept-types' attribute in the Session Description Protocol (SDP) Parameters "a
tt-field" subregistry as follows:</t>
<dl spacing="compact" indent="18">
<t>Note that discussion in Section 14.5 of <xref target="RFC4975"/> on MSRP m <dt>Contact name:</dt>
essage attribution to remote identities applies to data channel transport.</t> <dd>IESG</dd>
<t>If the Session Initiation Protocol (SIP) <xref target="RFC3261"/> is used <dt>Contact email:</dt>
to implement the offer/answer transactions for establishing the MSRP data channe <dd>iesg@ietf.org</dd>
l, the SIP security considerations specified in <xref target="RFC3261"/> apply.<
/t>
</section> <dt>Attribute name:</dt>
<dd>accept-types</dd>
<section anchor="IANA" title="IANA Considerations"> <dt>Usage level:</dt>
<t>NOTE to RFC Editor: Please replace all instances of all instances of RFCXX <dd>dcsa (msrp)</dd>
XX with the number of this RFC.</t>
<section title="msrps URI scheme" anchor="IANA-reg-msrps"> <dt>Purpose:</dt>
<t>This document modifies the usage of the msrps URI scheme, registered by <dd>Contain the list of media types that the endpoint is willing t
<xref target="RFC4975"/>, adding DTLS as a protected transport indicated by the o receive.</dd>
URI scheme.</t>
<t>A reference to RFCXXXX is added to the URI scheme "msrps" in the Uniform
Resource Identifier (URI) Schemes Registry.</t>
</section>
<section title="Subprotocol Identifier MSRP" anchor="IANA-reg-MSRP"> <dt>Reference:</dt>
<dd>RFC 8873</dd>
<t>A reference to RFCXXXX is added to the subprotocol identifier "msrp" in t he "WebSocket Subprotocol Name Registry"</t> </dl>
</section> <t>The usage level "dcsa (msrp)" has been added to the registration of t
he SDP
'accept-wrapped-types' attribute in the Session Description Protocol (SDP) Param
eters "att-field" subregistry as follows:</t>
<dl spacing="compact" indent="18">
<section title="SDP Attributes" anchor="IANA-reg-other-sdp"> <dt>Contact name:</dt>
<dd>IESG</dd>
<t> <dt>Contact email:</dt>
This document modifies the usage of a set of SDP attributes, if any of tho <dd>iesg@ietf.org</dd>
se
attributes is included in an SDP 'dsca' attribute associated with an
MSRP data channel. The modified usage of the SDP 'setup' attribute is
described in <xref target="use-of-setup-attribute"/>. The usage of the oth
er
SDP attributes is described in <xref target="use-of-dcsa-attribute"/>.
</t>
<t>
<list style="symbols">
<t>"path"</t>
<t>"msrp-cema"</t>
<t>"accept-types"</t>
<t>"accept-wrapped-types"</t>
<t>"max-size"</t>
<t>"sendonly"</t>
<t>"recvonly"</t>
<t>"inactive"</t>
<t>"sendrecv"</t>
<t>"file-selector"</t>
<t>"file-transfer-id"</t>
<t>"file-disposition"</t>
<t>"file-date"</t>
<t>"file-icon"</t>
<t>"file-range"</t>
</list>
</t>
<t>The usage level "dcsa(msrp)" is added to the registration of the SDP 'se <dt>Attribute name:</dt>
tup' attribute in the Session Description Protocol (SDP) Parameters "att-field" <dd>accept-wrapped-types</dd>
sub-registry as follows:</t>
<texttable title=""> <dt>Usage level:</dt>
<ttcol align="left" width="35%"/> <dd>dcsa (msrp)</dd>
<ttcol align="left" width="65%"/>
<c>Contact name:</c> <dt>Purpose:</dt>
<c>IESG</c> <dd>Contain the list of media types that the endpoint is willing t
o receive in an MSRP message with multipart content.</dd>
<c>Contact email:</c> <dt>Reference:</dt>
<c>iesg@ietf.org</c> <dd>RFC 8873</dd>
<c>Attribute name:</c> </dl>
<c>setup</c>
<c>Usage level:</c> <t>The usage level "dcsa (msrp)" has been added to the registration of t
<c>dcsa(msrp)</c> he SDP
'file-date' attribute in the Session Description Protocol (SDP) Parameters "att-
field" subregistry as follows:</t>
<dl spacing="compact" indent="18">
<c>Purpose:</c> <dt>Contact name:</dt>
<c>Negotiate the active role of an MSRP session over a data channel as pe <dd>IESG</dd>
r
<xref target="use-of-setup-attribute"/>
</c>
<c>Reference:</c> <dt>Contact email:</dt>
<c>RFCXXXX</c> <dd>iesg@ietf.org</dd>
</texttable>
<t>The usage level "dcsa(msrp)" is added to the registration of the SDP 'pa <dt>Attribute name:</dt>
th' attribute in the Session Description Protocol (SDP) Parameters "att-field" s <dd>file-date</dd>
ub-registry as follows:</t>
<texttable title=""> <dt>Usage level:</dt>
<ttcol align="left" width="35%"/> <dd>dcsa (msrp)</dd>
<ttcol align="left" width="65%"/>
<c>Contact name:</c> <dt>Purpose:</dt>
<c>IESG</c> <dd>Indicate one or more dates related to the file in an MSRP file
transfer negotiation.</dd>
<c>Contact email:</c> <dt>Reference:</dt>
<c>iesg@ietf.org</c> <dd>RFC 8873</dd>
<c>Attribute name:</c> </dl>
<c>path</c>
<c>Usage level:</c> <t>The usage level "dcsa (msrp)" has been added to the registrati
<c>dcsa(msrp)</c> on of the SDP
'file-disposition' attribute in the Session Description Protocol (SDP) Parameter
s "att-field" subregistry as follows:</t>
<dl spacing="compact" indent="18">
<c>Purpose:</c> <dt>Contact name:</dt>
<c>Indicate an endpoint, but not used for routing, as described in <xref <dd>IESG</dd>
target="use-of-dcsa-attribute"/></c>
<c>Reference:</c>
<c>RFCXXXX</c>
</texttable>
<t>The usage level "dcsa(msrp)" is added to the registration of the SDP 'ms <dt>Contact email:</dt>
rp-cema' attribute in the Session Description Protocol (SDP) Parameters "att-fie <dd>iesg@ietf.org</dd>
ld" sub-registry as follows:</t>
<texttable title=""> <dt>Attribute name:</dt>
<ttcol align="left" width="35%"/> <dd>file-disposition</dd>
<ttcol align="left" width="65%"/>
<c>Contact name:</c> <dt>Usage level:</dt>
<c>IESG</c> <dd>dcsa (msrp)</dd>
<c>Contact email:</c> <dt>Purpose:</dt>
<c>iesg@ietf.org</c> <dd>Provide a suggestion to the other endpoint about the intended
disposition of the file in an MSRP file transfer negotiation.</dd>
<c>Attribute name:</c> <dt>Reference:</dt>
<c>msrp-cema</c> <dd>RFC 8873</dd>
<c>Usage level:</c> </dl>
<c>dcsa(msrp)</c>
<c>Purpose:</c> <t>The usage level "dcsa (msrp)" has been added to the registration of t
<c>Indicate that the routing of MSRP messages transported on a data chann he SDP
el is more similar to the MSRP CEMA mechanism than the legacy MSRP routing mecha 'file-icon' attribute in the Session Description Protocol (SDP) Parameters "att-
nism.</c> field" subregistry as follows:</t>
<dl spacing="compact" indent="18">
<c>Reference:</c> <dt>Contact name:</dt>
<c>RFCXXXX</c> <dd>IESG</dd>
</texttable>
<t>The usage level "dcsa(msrp)" is added to the registration of the SDP 'ac <dt>Contact email:</dt>
cept-types' attribute in the Session Description Protocol (SDP) Parameters "att- <dd>iesg@ietf.org</dd>
field" sub-registry as follows:</t>
<texttable title=""> <dt>Attribute name:</dt>
<ttcol align="left" width="35%"/> <dd>file-icon</dd>
<ttcol align="left" width="65%"/>
<c>Contact name:</c> <dt>Usage level:</dt>
<c>IESG</c> <dd>dcsa (msrp)</dd>
<c>Contact email:</c> <dt>Purpose:</dt>
<c>iesg@ietf.org</c> <dd>Contain a pointer to a small preview icon representing the con
tents of the file in an MSRP file transfer negotiation.</dd>
<c>Attribute name:</c> <dt>Reference:</dt>
<c>accept-types</c> <dd>RFC 8873</dd>
<c>Usage level:</c> </dl>
<c>dcsa(msrp)</c>
<c>Purpose:</c> <t>The usage level "dcsa (msrp)" has been added to the registration of t
<c>Contain the list of media types that the endpoint is willing to receiv he SDP
e.</c> 'file-range' attribute in the Session Description Protocol (SDP) Parameters "att
-field" subregistry as follows:</t>
<dl spacing="compact" indent="18">
<c>Reference:</c> <dt>Contact name:</dt>
<c>RFCXXXX</c> <dd>IESG</dd>
</texttable>
<t>The usage level "dcsa(msrp)" is added to the registration of the SDP 'ac <dt>Contact email:</dt>
cept-wrapped-types' attribute in the Session Description Protocol (SDP) Paramete <dd>iesg@ietf.org</dd>
rs "att-field" sub-registry as follows:</t>
<texttable title=""> <dt>Attribute name:</dt>
<ttcol align="left" width="35%"/> <dd>file-range</dd>
<ttcol align="left" width="65%"/>
<c>Contact name:</c> <dt>Usage level:</dt>
<c>IESG</c> <dd>dcsa (msrp)</dd>
<c>Contact email:</c> <dt>Purpose:</dt>
<c>iesg@ietf.org</c> <dd>Contain the range of transferred octets of the file in an MSRP
file transfer negotiation.</dd>
<c>Attribute name:</c> <dt>Reference:</dt>
<c>accept-wrapped-types</c> <dd>RFC 8873</dd>
<c>Usage level:</c> </dl>
<c>dcsa(msrp)</c>
<c>Purpose:</c> <t>The usage level "dcsa (msrp)" has been added to the registration of t
<c>Contain the list of media types that the endpoint is willing to receiv he SDP
e in an MSRP message with multipart content.</c> 'file-selector' attribute in the Session Description Protocol (SDP) Parameters "
att-field" subregistry as follows:</t>
<dl spacing="compact" indent="18">
<c>Reference:</c> <dt>Contact name:</dt>
<c>RFCXXXX</c> <dd>IESG</dd>
</texttable>
<t>The usage level "dcsa(msrp)" is added to the registration of the SDP 'ma <dt>Contact email:</dt>
x-size' attribute in the Session Description Protocol (SDP) Parameters "att-fiel <dd>iesg@ietf.org</dd>
d" sub-registry as follows:</t>
<texttable title=""> <dt>Attribute name:</dt>
<ttcol align="left" width="35%"/> <dd>file-selector</dd>
<ttcol align="left" width="65%"/>
<c>Contact name:</c> <dt>Usage level:</dt>
<c>IESG</c> <dd>dcsa (msrp)</dd>
<c>Contact email:</c> <dt>Purpose:</dt>
<c>iesg@ietf.org</c> <dd>Indicate a file in an MSRP file transfer negotiation.</dd>
<c>Attribute name:</c> <dt>Reference:</dt>
<c>max-size</c> <dd>RFC 8873</dd>
<c>Usage level:</c> </dl>
<c>dcsa(msrp)</c>
<c>Purpose:</c> <t>The usage level "dcsa (msrp)" has been added to the registration of t
<c>Indicate the largest message an MSRP endpoint wishes to accept.</c> he SDP
'file-transfer-id' attribute in the Session Description Protocol (SDP) Parameter
s "att-field" subregistry as follows:</t>
<dl spacing="compact" indent="18">
<c>Reference:</c> <dt>Contact name:</dt>
<c>RFCXXXX</c> <dd>IESG</dd>
</texttable>
<t>The usage level "dcsa(msrp)" is added to the registration of the SDP 'se <dt>Contact email:</dt>
ndonly' attribute in the Session Description Protocol (SDP) Parameters "att-fiel <dd>iesg@ietf.org</dd>
d" sub-registry as follows:</t>
<texttable title=""> <dt>Attribute name:</dt>
<ttcol align="left" width="35%"/> <dd>file-transfer-id</dd>
<ttcol align="left" width="65%"/>
<c>Contact name:</c> <dt>Usage level:</dt>
<c>IESG</c> <dd>dcsa (msrp)</dd>
<c>Contact email:</c> <dt>Purpose:</dt>
<c>iesg@ietf.org</c> <dd>Indicate a unique identifier of the file transfer operation in
an MSRP file transfer negotiation.</dd>
<c>Attribute name:</c> <dt>Reference:</dt>
<c>sendonly</c> <dd>RFC 8873</dd>
<c>Usage level:</c> </dl>
<c>dcsa(msrp)</c>
<c>Purpose:</c> <t>The usage level "dcsa (msrp)" has been added to the registration of t
<c>Negotiate the direction of the media flow on an MSRP data channel.</c> he SDP
'inactive' attribute in the Session Description Protocol (SDP) Parameters "att-f
ield" subregistry as follows:</t>
<dl spacing="compact" indent="18">
<c>Reference:</c> <dt>Contact name:</dt>
<c>RFCXXXX</c> <dd>IESG</dd>
</texttable>
<t>The usage level "dcsa(msrp)" is added to the registration of the SDP 're <dt>Contact email:</dt>
cvonly' attribute in the Session Description Protocol (SDP) Parameters "att-fiel <dd>iesg@ietf.org</dd>
d" sub-registry as follows:</t>
<texttable title=""> <dt>Attribute name:</dt>
<ttcol align="left" width="35%"/> <dd>inactive</dd>
<ttcol align="left" width="65%"/>
<c>Contact name:</c> <dt>Usage level:</dt>
<c>IESG</c> <dd>dcsa (msrp)</dd>
<c>Contact email:</c> <dt>Purpose:</dt>
<c>iesg@ietf.org</c> <dd>Negotiate the direction of the media flow on an MSRP data chan
nel.</dd>
<c>Attribute name:</c> <dt>Reference:</dt>
<c>recvonly</c> <dd>RFC 8873</dd>
<c>Usage level:</c> </dl>
<c>dcsa(msrp)</c>
<c>Purpose:</c> <t>The usage level "dcsa (msrp)" has been added to the registration of t
<c>Negotiate the direction of the media flow on an MSRP data channel.</c> he SDP
'max-size' attribute in the Session Description Protocol (SDP) Parameters "att-f
ield" subregistry as follows:</t>
<dl spacing="compact" indent="18">
<c>Reference:</c> <dt>Contact name:</dt>
<c>RFCXXXX</c> <dd>IESG</dd>
</texttable>
<t>The usage level "dcsa(msrp)" is added to the registration of the SDP 'in <dt>Contact email:</dt>
active' attribute in the Session Description Protocol (SDP) Parameters "att-fiel <dd>iesg@ietf.org</dd>
d" sub-registry as follows:</t>
<texttable title=""> <dt>Attribute name:</dt>
<ttcol align="left" width="35%"/> <dd>max-size</dd>
<ttcol align="left" width="65%"/>
<c>Contact name:</c> <dt>Usage level:</dt>
<c>IESG</c> <dd>dcsa (msrp)</dd>
<c>Contact email:</c> <dt>Purpose:</dt>
<c>iesg@ietf.org</c> <dd>Indicate the largest message an MSRP endpoint wishes to accept
.</dd>
<c>Attribute name:</c> <dt>Reference:</dt>
<c>inactive</c> <dd>RFC 8873</dd>
<c>Usage level:</c> </dl>
<c>dcsa(msrp)</c>
<c>Purpose:</c> <t>The usage level "dcsa (msrp)" has been added to the registration of t
<c>Negotiate the direction of the media flow on an MSRP data channel.</c> he SDP
'msrp-cema' attribute in the Session Description Protocol (SDP) Parameters "att-
field" subregistry as follows:</t>
<dl spacing="compact" indent="18">
<c>Reference:</c> <dt>Contact name:</dt>
<c>RFCXXXX</c> <dd>IESG</dd>
</texttable>
<t>The usage level "dcsa(msrp)" is added to the registration of the SDP 'se <dt>Contact email:</dt>
ndrecv' attribute in the Session Description Protocol (SDP) Parameters "att-fiel <dd>iesg@ietf.org</dd>
d" sub-registry as follows:</t>
<texttable title=""> <dt>Attribute name:</dt>
<ttcol align="left" width="35%"/> <dd>msrp-cema</dd>
<ttcol align="left" width="65%"/>
<c>Contact name:</c> <dt>Usage level:</dt>
<c>IESG</c> <dd>dcsa (msrp)</dd>
<c>Contact email:</c> <dt>Purpose:</dt>
<c>iesg@ietf.org</c> <dd>Indicate that the routing of MSRP messages transported on a da
ta channel is more similar to the MSRP CEMA mechanism than the legacy MSRP routi
ng mechanism.</dd>
<c>Attribute name:</c> <dt>Reference:</dt>
<c>sendrecv</c> <dd>RFC 8873</dd>
<c>Usage level:</c> </dl>
<c>dcsa(msrp)</c>
<c>Purpose:</c> <t>The usage level "dcsa (msrp)" has been added to the registration of t
<c>Negotiate the direction of the media flow on an MSRP data channel.</c> he SDP
'path' attribute in the Session Description Protocol (SDP) Parameters "att-field
" subregistry as follows:</t>
<dl spacing="compact" indent="18">
<c>Reference:</c> <dt>Contact name:</dt>
<c>RFCXXXX</c> <dd>IESG</dd>
</texttable>
<t>The usage level "dcsa(msrp)" is added to the registration of the SDP 'fil <dt>Contact email:</dt>
e-selector' attribute in the Session Description Protocol (SDP) Parameters "att- <dd>iesg@ietf.org</dd>
field" sub-registry as follows:</t>
<texttable title="">
<ttcol align="left" width="35%"/>
<ttcol align="left" width="65%"/>
<c>Contact name:</c> <dt>Attribute name:</dt>
<c>IESG</c> <dd>path</dd>
<c>Contact email:</c> <dt>Usage level:</dt>
<c>iesg@ietf.org</c> <dd>dcsa (msrp)</dd>
<c>Attribute name:</c> <dt>Purpose:</dt>
<c>file-selector</c> <dd>Indicate an endpoint, but not used for routing, as described i
n
<xref target="use-of-dcsa-attribute" format="default"/>.</dd>
<c>Usage level:</c> <dt>Reference:</dt>
<c>dcsa(msrp)</c> <dd>RFC 8873</dd>
<c>Purpose:</c> </dl>
<c>Indicate a file in an MSRP file transfer negotiation.</c>
<c>Reference:</c> <t>The usage level "dcsa (msrp)" has been added to the registration of t
<c>RFCXXXX</c> he SDP
</texttable> 'recvonly' attribute in the Session Description Protocol (SDP) Parameters "att-f
ield" subregistry as follows:</t>
<dl spacing="compact" indent="18">
<t>The usage level "dcsa(msrp)" is added to the registration of the SDP 'fil <dt>Contact name:</dt>
e-transfer-id' attribute in the Session Description Protocol (SDP) Parameters "a <dd>IESG</dd>
tt-field" sub-registry as follows:</t>
<texttable title="">
<ttcol align="left" width="35%"/>
<ttcol align="left" width="65%"/>
<c>Contact name:</c> <dt>Contact email:</dt>
<c>IESG</c> <dd>iesg@ietf.org</dd>
<c>Contact email:</c> <dt>Attribute name:</dt>
<c>iesg@ietf.org</c> <dd>recvonly</dd>
<c>Attribute name:</c> <dt>Usage level:</dt>
<c>file-transfer-id</c> <dd>dcsa (msrp)</dd>
<c>Usage level:</c> <dt>Purpose:</dt>
<c>dcsa(msrp)</c> <dd>Negotiate the direction of the media flow on an MSRP data chan
nel.</dd>
<c>Purpose:</c> <dt>Reference:</dt>
<c>Indicate a unique identifier of the file transfer operation in an MSRP <dd>RFC 8873</dd>
file transfer negotiation.</c>
<c>Reference:</c> </dl>
<c>RFCXXXX</c>
</texttable>
<t>The usage level "dcsa(msrp)" is added to the registration of the SDP 'fil <t>The usage level "dcsa (msrp)" has been added to the registration of t
e-disposition' attribute in the Session Description Protocol (SDP) Parameters "a he SDP
tt-field" sub-registry as follows:</t> 'sendonly' attribute in the Session Description Protocol (SDP) Parameters "att-f
<texttable title=""> ield" subregistry as follows:</t>
<ttcol align="left" width="35%"/> <dl spacing="compact" indent="18">
<ttcol align="left" width="65%"/>
<c>Contact name:</c> <dt>Contact name:</dt>
<c>IESG</c> <dd>IESG</dd>
<c>Contact email:</c> <dt>Contact email:</dt>
<c>iesg@ietf.org</c> <dd>iesg@ietf.org</dd>
<c>Attribute name:</c> <dt>Attribute name:</dt>
<c>file-disposition</c> <dd>sendonly</dd>
<c>Usage level:</c> <dt>Usage level:</dt>
<c>dcsa(msrp)</c> <dd>dcsa (msrp)</dd>
<c>Purpose:</c> <dt>Purpose:</dt>
<c>Provide a suggestion to the other endpoint about the intended disposit <dd>Negotiate the direction of the media flow on an MSRP data chan
ion of the file in an MSRP file transfer negotiation.</c> nel.</dd>
<c>Reference:</c> <dt>Reference:</dt>
<c>RFCXXXX</c> <dd>RFC 8873</dd>
</texttable>
<t>The usage level "dcsa(msrp)" is added to the registration of the SDP 'fil </dl>
e-date' attribute in the Session Description Protocol (SDP) Parameters "att-fiel
d" sub-registry as follows:</t>
<texttable title="">
<ttcol align="left" width="35%"/>
<ttcol align="left" width="65%"/>
<c>Contact name:</c> <t>The usage level "dcsa (msrp)" has been added to the registration of t
<c>IESG</c> he SDP
'setup' attribute in the "att-field" subregistry as follows:</t>
<c>Contact email:</c> <dl spacing="compact" indent="18">
<c>iesg@ietf.org</c>
<c>Attribute name:</c> <dt>Contact name:</dt>
<c>file-date</c> <dd>IESG</dd>
<c>Usage level:</c> <dt>Contact email:</dt>
<c>dcsa(msrp)</c> <dd>iesg@ietf.org</dd>
<c>Purpose:</c> <dt>Attribute name:</dt>
<c>Indicate one or more dates related to the file in an MSRP file transfe <dd>setup</dd>
r negotiation.</c>
<c>Reference:</c> <dt>Usage level:</dt>
<c>RFCXXXX</c> <dd>dcsa (msrp)</dd>
</texttable>
<t>The usage level "dcsa(msrp)" is added to the registration of the SDP 'fil <dt>Purpose:</dt>
e-icon' attribute in the Session Description Protocol (SDP) Parameters "att-fiel <dd>Negotiate the active role of an MSRP session over a data chann
d" sub-registry as follows:</t> el as per
<texttable title=""> <xref target="use-of-setup-attribute" format="default"/>.
<ttcol align="left" width="35%"/> </dd>
<ttcol align="left" width="65%"/>
<c>Contact name:</c> <dt>Reference:</dt>
<c>IESG</c> <dd>RFC 8873</dd>
<c>Contact email:</c> </dl>
<c>iesg@ietf.org</c>
<c>Attribute name:</c> <t>The usage level "dcsa (msrp)" has been added to the registration of t
<c>file-icon</c> he SDP
'sendrecv' attribute in the Session Description Protocol (SDP) Parameters "att-f
ield" subregistry as follows:</t>
<dl spacing="compact" indent="18">
<c>Usage level:</c> <dt>Contact name:</dt>
<c>dcsa(msrp)</c> <dd>IESG</dd>
<c>Purpose:</c> <dt>Contact email:</dt>
<c>Contain a pointer to a small preview icon representing the contents of <dd>iesg@ietf.org</dd>
the file in an MSRP file transfer negotiation.</c>
<c>Reference:</c> <dt>Attribute name:</dt>
<c>RFCXXXX</c> <dd>sendrecv</dd>
</texttable>
<t>The usage level "dcsa(msrp)" is added to the registration of the SDP 'fil <dt>Usage level:</dt>
e-range' attribute in the Session Description Protocol (SDP) Parameters "att-fie <dd>dcsa (msrp)</dd>
ld" sub-registry as follows:</t>
<texttable title="">
<ttcol align="left" width="35%"/>
<ttcol align="left" width="65%"/>
<c>Contact name:</c> <dt>Purpose:</dt>
<c>IESG</c> <dd>Negotiate the direction of the media flow on an MSRP data chan
nel.</dd>
<c>Contact email:</c> <dt>Reference:</dt>
<c>iesg@ietf.org</c> <dd>RFC 8873</dd>
<c>Attribute name:</c> </dl>
<c>file-range</c> </section>
</section>
</middle>
<c>Usage level:</c> <back>
<c>dcsa(msrp)</c>
<c>Purpose:</c> <references>
<c>Contain the range of transferred octets of the file in an MSRP file tr <name>References</name>
ansfer negotiation.</c> <references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<c>Reference:</c> <reference anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8831">
<c>RFCXXXX</c> <front>
</texttable> <title>WebRTC Data Channels</title>
<author initials="R" surname="Jesup" fullname="Randell Jesup">
<organization/>
</author>
<author initials="S" surname="Loreto" fullname="Salvatore Loreto">
<organization/>
</author>
<author initials="M" surname="Tüxen" fullname="Michael Tüxen">
<organization/>
</author>
<date month='January' year='2021'/>
</front>
<seriesInfo name="RFC" value="8831"/>
<seriesInfo name="DOI" value="10.17487/RFC8831"/>
</reference>
</section> <reference anchor="RFC8864" target="https://www.rfc-editor.org/info/rfc8864">
</section> <front>
<title>Negotiation Data Channels Using the Session Description
Protocol (SDP)</title>
<author fullname="Keith Drage" initials="K." surname="Drage">
<organization>Unaffiliated</organization>
</author>
<author fullname="Raju Makaraju" initials="M." surname="Makaraju">
<organization>Nokia</organization>
</author>
<author fullname="Richard Ejzak" initials="R." surname="Ejzak">
<organization>Unaffiliated</organization>
</author>
<author fullname="Jerome Marcon" initials="J." surname="Marcon">
<organization>Unaffiliated</organization>
</author>
<author fullname="Roni Even" initials="R." surname="Even" role="editor">
<organization>Huawei</organization>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8864"/>
<seriesInfo name="DOI" value="10.17487/RFC8864"/>
</reference>
<section title="Acknowledgments"> <reference anchor="RFC8841" target="https://www.rfc-editor.org/info/rfc8841">
<t>The authors wish to acknowledge the borrowing of ideas from another intern
et draft by Peter Dunkley and Gavin Llewellyn, and to thank Flemming Andreasen,
Christian Groves, Paul Kyzivat, Jonathan Lennox, Uwe Rauschenbach, Albrecht Schw
arz, and Keith Drage for their invaluable comments.</t>
<t>Richard Ejzak, Keith Drage and Juergen Stoetzer-Bradler contributed an ear
lier version, before the draft was re-adopted.</t>
<t>Julien Maisonneuve helped with the re-adoption of the draft, and Maridi R
. Makaraju (Raju) contributed valuable comments after the draft was re-adopted.<
/t>
</section>
</middle> <front>
<title>Session Description Protocol (SDP) Offer/Answer Procedures for
Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer
Security (DTLS) Transport</title>
<!-- *****BACK MATTER ***** --> <author initials="C." surname="Holmberg" fullname="Christer Holmberg">
<organization />
</author>
<back> <author initials="R." surname="Shpount" fullname="Roman Shpount">
<!-- References split into informative and normative --> <organization />
</author>
<!-- There are 2 ways to insert reference entries from the citation libraries: <author initials="S." surname="Loreto" fullname="Salvatore Loreto">
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as <organization />
shown) </author>
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?
> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements. <author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
If you use the PI option, xml2rfc will, by default, try to find included files <organization />
in the same </author>
directory as the including file. You can also define the XML_LIBRARY environme
nt variable
with a value containing a set of directories to search. These can be either i
n the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References"> <date month="January" year="2021" />
</front>
<seriesInfo name="RFC" value="8841" />
<seriesInfo name="DOI" value="10.17487/RFC8841"/>
&RFC2119; </reference>
&DATAREQ;
&DCSDPNEG;
&SDPSCTP;
&RFC3264;
&RFC4566;
&RFC4960;
&RFC4975;
&RFC5547;
&RFC6135;
&RFC6714;
&RFC7977;
&RFC8174;
</references> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<references title="Informative References"> FC.3264.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4566.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4960.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4975.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5547.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6135.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6714.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7977.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3261.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7092.xml"/>
</references>
</references>
&RFC3261; <section numbered="false" toc="default">
&RFC7092; <name>Acknowledgments</name>
</references> <t>The authors wish to acknowledge the borrowing of ideas from
another Internet-Draft by <contact fullname="Peter Dunkley"/> and
<contact fullname="Gavin Llewellyn"/>, and to thank
<contact fullname="Flemming Andreasen"/>, <contact fullname="Christian Gro
ves"/>,
<contact fullname="Paul Kyzivat"/>, <contact fullname="Jonathan Lennox"/>,
<contact fullname="Uwe Rauschenbach"/>, <contact fullname="Albrecht Schwar
z"/>, and
<contact fullname="Keith Drage"/> for their invaluable comments.</t>
<t><contact fullname="Richard Ejzak"/>, <contact fullname="Keith Drage"/>, an
d
<contact fullname="Juergen Stoetzer-Bradler"/> contributed to an earlier d
raft version
of this document before the draft was readopted.</t>
<t><contact fullname="Julien Maisonneuve"/> helped with the readoption of thi
s document, and
<contact fullname="Maridi R. Makaraju (Raju)"/> contributed valuable comme
nts
after the document was readopted.</t>
</back> </section>
</back>
</rfc> </rfc>
 End of changes. 186 change blocks. 
959 lines changed or deleted 951 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/