rfc8850xml2.original.xml   rfc8850.xml 
<?xml version="1.0" encoding="iso-8859-1"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
category="exp" docName="draft-ietf-clue-datachannel-18" number="8850"
obsoletes="" updates="" submissionType="IETF" consensus="true" xml:lang="en
" tocInclude="true" sortRefs="false" version="3">
<!-- xml2rfc v2v3 conversion 2.38.1 -->
<front>
<title abbrev="CLUE Data Channel">Controlling Multiple Streams for
Telepresence (CLUE) Protocol&nbsp;Data&nbsp;Channel</title>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!-- [rfced] Please note that the title of this document has been
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC updated as follows:
.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">
]> Original:
CLUE Protocol data channel
<?rfc toc="yes" ?> Currently:
<?rfc compact="yes" ?> Controlling Multiple Streams for Telepresence (CLUE)
<?rfc subcompact="yes" ?> Protocol Data Channel
<?rfc sortrefs="no" ?>
<?rfc strict="yes" ?>
<rfc ipr="trust200902" category="exp" docName="draft-ietf-clue-datachannel-18" o Please let us know if any corrections are needed. -->
bsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="CLUE data channel">
CLUE Protocol data channel
</title>
<author initials="C.H." surname="Holmberg" fullname="Christer Hol
mberg">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>christer.holmberg@ericsson.com</email>
</address>
</author>
<date year="2019" /> <seriesInfo name="RFC" value="8850"/>
<area>Transport</area> <author initials="C." surname="Holmberg" fullname="Christer Holmberg">
<workgroup>CLUE Working Group</workgroup> <organization>Ericsson</organization>
<keyword>SIP</keyword> <address>
<keyword>SDP</keyword> <postal>
<keyword>DTLS</keyword> <street>Hirsalantie 11</street>
<keyword>SCTP</keyword> <code>02420</code>
<keyword>DATA</keyword> <city>Jorvas</city>
<keyword>CHANNEL</keyword> <country>Finland</country>
<keyword>DCEP</keyword> </postal>
<keyword>DATA_CHANNEL_OPEN</keyword> <email>christer.holmberg@ericsson.com</email>
<keyword>DATA_CHANNEL_ACK</keyword> </address>
<keyword>PPID</keyword> </author>
<keyword>TELEPRESENCE</keyword> <date month="June" year="2020"/>
<keyword>RTCWEB</keyword>
<keyword>WEBRTC</keyword>
<abstract>
<t>
This document defines how to use the WebRTC data
channel
mechanism to realize a data channel, referred to
as a CLUE data channel, for transporting CLUE pro
tocol
messages between two CLUE entities.
</t>
</abstract>
</front>
<middle> <keyword>SIP</keyword>
<section title="Introduction" toc="default"> <keyword>SDP</keyword>
<t> <keyword>DTLS</keyword>
This document defines how to use the WebRTC data <keyword>SCTP</keyword>
channel <keyword>DATA</keyword>
mechanism <xref target="I-D.ietf-rtcweb-data-chan <keyword>CHANNEL</keyword>
nel" <keyword>DCEP</keyword>
pageno="false" format="default" /> to realize a <keyword>DATA_CHANNEL_OPEN</keyword>
data channel, referred to as a CLUE data channel, <keyword>DATA_CHANNEL_ACK</keyword>
for <keyword>PPID</keyword>
transporting CLUE protocol <xref target="I-D.ietf <keyword>TELEPRESENCE</keyword>
-clue-protocol" <keyword>RTCWEB</keyword>
pageno="false" format="default" /> messages betwe <keyword>WEBRTC</keyword>
en two CLUE entities. <abstract>
</t> <t>
<t> This document defines how to use the WebRTC data channel
The document defines how to describe the SCTPoDTL mechanism to realize a data channel, referred to
S association as a Controlling Multiple Streams for Telepresence (CLUE) data channel,
<xref target="RFC8261" pageno="false" format="def for transporting CLUE protocol
ault" /> used to messages between two CLUE entities.
</t>
</abstract>
</front>
<middle>
<section toc="default" numbered="true">
<name>Introduction</name>
<t>
This document defines how to use the WebRTC data channel
mechanism <xref target="RFC8831" format="default"/> to realize a
data channel, referred to as a Controlling Multiple Streams for
Telepresence (CLUE) data channel, for
transporting CLUE protocol messages <xref target="RFC8847" format="defau
lt"/> between two CLUE entities.
</t>
<!-- [rfced] It is likely that draft-ietf-mmusic-rfc4566bis will move
to AUTH48 state shortly after this document. Do you want to hold this
document to reference 4566bis instead of RFC 4566?
-->
<t>
This document also defines how to describe the SCTPoDTLS association
<xref target="RFC8261" format="default"/> (also referred to as
"SCTP over DTLS" in this document) used to
realize the CLUE data channel using the Session Description Prot ocol (SDP) realize the CLUE data channel using the Session Description Prot ocol (SDP)
<xref target="RFC4566" pageno="false" format="default" />, and d <xref target="RFC4566" format="default"/> and defines usage of t
efines usage of the he
SDP-based "SCTP over DTLS" data channel negotiati SDP-based "SCTP over DTLS" data channel negotiation mechanism
on mechanism <xref target="RFC8864" format="default"/>. ("SCTP" stands for "Stream
<xref target="I-D.ietf-mmusic-data-channel-sdpneg Control Transmission Protocol".) This includes SCTP
" considerations specific to a CLUE data channel, the SDP media
pageno="false" format="default" />. This includes description ("m=" line) values, and usage of SDP attributes specific
SCTP to a CLUE data channel.
considerations specific to a CLUE data channel, t </t>
he SDP Media <t>
Description ("m=" line) values, and usage of SDP Details and procedures associated with the CLUE protocol, and the
attributes specific SDP Offer/Answer procedures <xref target="RFC3264" format="default"/>
to a CLUE data channel. for negotiating usage of a CLUE data channel, are outside
</t> the scope of this document.
<t> </t>
Details and procedures associated with the CLUE p
rotocol, and the
SDP Offer/Answer <xref target="RFC3264" pageno="f
alse" format="default" />
procedures for negotiating usage of a CLUE data c
hannel, are outside
the scope of this document.
</t>
<t>
NOTE: The usage of the Data Channel Establishment
Protocol (DCEP)
<xref target="I-D.ietf-rtcweb-data-protocol" page
no="false" format="default" />
for establishing a CLUE data channel is outside t
he scope of this document.
</t>
</section>
<section title="Conventions" toc="default">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "S
HALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMME
NDED",
"MAY", and "OPTIONAL" in this document are to be interpre
ted as
described in BCP 14 <xref target="RFC2119"></xref> <xref
target="RFC8174"></xref>
when, and only when, they appear in all capitals, as show
n here.
</t>
<t>
SCTPoDTLS association refers to an SCTP associati
on carried
over an DTLS connection <xref target="RFC8261" pa
geno="false" format="default" />.
</t>
<t>
WebRTC data channel refers to a pair of SCTP stre
ams over a
SCTPoDTLS association that is used to transport n
on-media
data between two entities, as defined in <xref ta
rget="I-D.ietf-rtcweb-data-channel"
pageno="false" format="default" />.
</t>
<t>
CLUE data channel refers to a WebRTC data channel
<xref
target="I-D.ietf-rtcweb-data-channel" pageno="fal
se"
format="default" /> realization, with a specific
set of
SCTP characteristics, with the purpose of transpo
rting CLUE
protocol <xref target="I-D.ietf-clue-protocol" pa
geno="false"
format="default" /> messages between two CLUE ent
ities.
</t>
<t>
CLUE entity refers to a SIP User Agent (UA) <xref
target="RFC3261"
pageno="false" format="default" /> that supports
the CLUE data channel
and the CLUE protocol.
</t>
<t>
CLUE session refers to a SIP session <xref target
="RFC3261"
pageno="false" format="default" /> between two SI
P UAs, where a
CLUE data channel, associated with the SIP sessio
n, has been
established between the SIP UAs.
</t>
<t>
SCTP stream is defined in <xref target="RFC4960"
pageno="false"
format="default" /> as a unidirectional logical c
hannel
established from one to another associated SCTP e
ndpoint,
within which all user messages are delivered in s
equence except
for those submitted to the unordered delivery ser
vice.
</t>
<t>
SCTP identifier is defined in <xref target="RFC49
60" pageno="false"
format="default" /> as an unsigned integer, which
identifies an SCTP stream.
</t>
</section>
<section anchor="section.dtls" title="CLUE data channel" toc="def <aside><t>NOTE: The usage of the Data Channel Establishment Protocol (DC
ault"> EP)
<section anchor="section.cdc.gen" title="General" toc="de <xref target="RFC8832" format="default"/>
fault"> for establishing a CLUE data channel is outside the scope of this docume
<t> nt.</t></aside>
This section describes the realization of </section>
a CLUE data channel, <section toc="default" numbered="true">
using the WebRTC data channel mechanism. <name>Conventions</name>
This includes a set of SCTP characteristi <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
cs specific to a "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
CLUE data channel, the values of the "m=" "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
line describing "<bcp14>SHOULD NOT</bcp14>",
the SCTPoDTLS association associated with "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
the WebRTC "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
data channel, and the usage of the SDP-ba to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
sed "SCTP <xref target="RFC8174"/> when, and only when, they appear in all capitals,
over DTLS" data channel negotiation mecha as shown here.</t>
nism for creating the
CLUE data channel.
</t>
<t>
As described in <xref target="I-D.ietf-rt
cweb-data-channel"
pageno="false" format="default" />, the S
CTP streams realizing
a WebRTC data channel must be associated
with the same SCTP association.
In addition, both SCTP streams realizing
the WebRTC data channel must
use the same SCTP stream identifier value
. These rules also apply to
a CLUE data channel.
</t>
<t>
Within a given CLUE session, a CLUE entit
y MUST use a single CLUE
data channel for transport of all CLUE me
ssages towards its peer.
</t>
</section>
<section anchor="section.cdc.sctp" title="SCTP Considerat <dl newline="true" spacing="normal">
ions" toc="default"> <dt>SCTPoDTLS association</dt>
<section anchor="section.cdc.sctp.gen" title="Gen <dd>Refers to an SCTP association carried over a DTLS connection <xref
eral" toc="default"> target="RFC8261" format="default"/>.</dd>
<t> </dl>
As described in <xref target="I-D <dl newline="true" spacing="normal">
.ietf-rtcweb-data-channel" <dt>WebRTC data channel</dt>
pageno="false" format="default" / <dd>Refers to a pair of SCTP streams over an
>, different SCTP options SCTPoDTLS association that is used to transport non-media
(e.g., regarding ordered delivery data between two entities, as defined in <xref
), can be used for a target="RFC8831" format="default"/>.</dd>
data channel. This section descri </dl>
bes the SCTP options <dl newline="true" spacing="normal">
used for a CLUE data channel. <xr <dt>CLUE data channel</dt>
ef target="section.oa" pageno="false" <dd>Refers to a WebRTC data channel realization <xref target="RFC8831" forma
format="default" /> describes how t="default"/>, with a specific set of
SCTP options are signaled using SDP. SCTP characteristics, with the purpose of transporting CLUE
</t> protocol messages <xref target="RFC8847" format="default"/> between two CLUE ent
<t> ities.</dd>
NOTE: While SCTP allows SCTP opti </dl>
ons to be applied per SCTP message, <dl newline="true" spacing="normal">
<xref target="I-D.ietf-rtcweb-dat <dt>CLUE entity</dt>
a-channel" pageno="false" format="default" /> <dd>Refers to a SIP User Agent (UA) <xref target="RFC3261" format="default"/
mandates that, for a given data c > that supports the CLUE data channel
hannel, the same SCTP options are applied and the CLUE protocol.</dd>
to each SCTP message associated w </dl>
ith that data channel. <dl newline="true" spacing="normal">
</t> <dt>CLUE session</dt>
</section> <dd>Refers to a SIP session <xref target="RFC3261" format="default"/> betwee
<section anchor="section.cdc.sctp.ppid" title="SC n two SIP UAs, where a
TP Payload Protocol Identifier (PPID)" toc="default"> CLUE data channel, associated with the SIP session, has been
<t> established between the SIP UAs.</dd>
A CLUE entity MUST use the PPID v </dl>
alue 51 when sending a CLUE message <dl newline="true" spacing="normal">
on a CLUE data channel. <dt>SCTP stream</dt>
</t> <dd>Defined in <xref target="RFC4960" format="default"/> as a unidirectional
<t> logical channel
NOTE: As described in <xref targe established from one to another associated SCTP endpoint,
t="I-D.ietf-rtcweb-data-channel" within which all user messages are delivered in sequence except
pageno="false" format="default" / for those submitted to the unordered delivery service.
>, the PPID value 51 indicates that
the SCTP message contains data en
coded in a UTF-8 format. The PPID
value 51 does not indicate which
application protocol the SCTP message
is associated with, only the form
at in which the data is encoded.
</t>
</section>
<section anchor="section.cdc.sctp.reliability" ti
tle="Reliability" toc="default">
<t>
The usage of SCTP for the CLUE da
ta channel ensures reliable transport of
CLUE protocol <xref target="I-D.i
etf-clue-protocol" pageno="false" format="default" />
messages.
</t>
<t>
<xref target="I-D.ietf-rtcweb-dat
a-channel" pageno="false" format="default" />
requires the support of the parti
al reliability extension defined in <xref target="RFC3758"
pageno="false" format="default" /
> and the limited retransmission policy defined in
<xref target="RFC7496" pageno="fa
lse" format="default" />. A CLUE entity MUST NOT use
these extensions, as messages are
required to always be sent reliably. A CLUE entity MUST
terminate the session if it detec
ts that the peer entity uses any of the extensions.
</t>
</section>
<section anchor="section.cdc.sctp.order" title="O
rder" toc="default">
<t>
A CLUE entity MUST use the ordere
d delivery SCTP service, as
described in <xref target="RFC496
0" pageno="false" format="default" />,
for the CLUE data channel.
</t>
</section>
<section anchor="section.cdc.sctp.streamreset" ti
tle="Stream Reset" toc="default">
<t>
A CLUE entity MUST support the st
ream reset extension defined in <xref target="RFC6525"
pageno="false" format="default" /
>.
</t>
<t>
As defined in <xref target="I-D.i
etf-rtcweb-data-channel" pageno="false" format="default" />,
the dynamic address reconfigurati
on extension ('Supported Extensions Parameter' parameter)
defined in <xref target="RFC5061"
pageno="false" format="default" /> must be used to signal the
support of the stream reset extension defined in <xref target="RFC65
25" pageno="false"
format="default" />. Other featur
es of <xref target="RFC5061" pageno="false" format="default" />
MUST NOT be used for CLUE data channels.
</t>
</section>
<section anchor="section.cdc.sctp.multihome" titl
e="SCTP Multihoming" toc="default">
<t>
SCTP multi-homing is not supporte
d for SCTPoDTLS associations, and can therefore
not be used for a CLUE data chann
el.
</t>
</section>
<section anchor="section.cdcp.proc.close" title="
Closing the CLUE data channel" toc="default">
<t>
As described in <xref target="I-D
.ietf-rtcweb-data-channel" pageno="false"
format="default" />, to close a d
ata channel, an entity sends an SCTP reset
message <xref target="RFC6525" pa
geno="false" format="default" /> on its outgoing
SCTP stream associated with the d
ata channel. When the remote peer receives the reset
message, it also sends (unless al
ready sent) a reset message on its outgoing SCTP
stream associated with the data c
hannel. The SCTPoDTLS association, and other data channels
established on the same associati
on, are not affected by the SCTP reset messages.
</t>
</section>
</section>
<section anchor="section.oa" title="SDP Considerations" t <!-- [rfced] Section 2: Does "from one to another associated SCTP
oc="default"> endpoint" mean "from one associated SCTP endpoint to another,"
<section anchor="section.oa.gen" title="General" "from one SCTP endpoint to another associated SCTP endpoint," or
toc="default"> something else?
<t>
This section defines how to const
ruct the SDP Media Description
("m=" line) for describing the SC
TPoDTLS association used to realize
a CLUE data channel. The section
also defines how to use the
SDP-based "SCTP over DTLS" data
channel negotiation mechanism
<xref target="I-D.ietf-mmusic-dat
a-channel-sdpneg" /> for establishing
a CLUE data channel on the SCTPoD
TLS association.
</t>
<t>
NOTE: Other protocols than SDP fo
r negotiating usage of an SCTPoDTLS
association for realizing a CLUE
data channel are outside the scope
of this specification.
</t>
<t>
<xref target="I-D.ietf-clue-signa
ling" pageno="false" format="default" />
describes the SDP Offer/Answer pr
ocedures for negotiating a CLUE session,
including the CLUE controlled med
ia streams and the CLUE data channel.
</t>
<section anchor="section.oa.mediadesc" ti
tle="SDP Media Description Fields" toc="default">
<t>
<xref target="I-D.ietf-mmusic
-sctp-sdp" pageno="false" format="default" /> defines how
to set the values of an "
m=" line describing an SCTPoDTLS association. As defined in
<xref target="I-D.ietf-mm
usic-sctp-sdp" pageno="false" format="default" />, for a
CLUE data channel the val
ues are set as following:
</t>
<texttable anchor="table_SDP_medi
adesc" title='SDP "proto" field values'>
<ttcol align='center'>med
ia</ttcol>
<ttcol align='center'>por
t</ttcol>
<ttcol align='center'>pro
to</ttcol>
<ttcol align='center'>fmt
</ttcol>
<c>"application"</c>
<c>UDP port value</c>
<c>"UDP/DTLS/SCTP"</c>
<c>"webrtc-datachannel"</
c>
<c>"application"</c>
<c>TCP port value</c>
<c>"TCP/DTLS/SCTP"</c>
<c>"webrtc-datachannel"</
c>
</texttable>
<t>
CLUE entities SHOULD NOT
transport the SCTPoDTLS association used to
realize the CLUE data cha
nnel over TCP (using the "TCP/DTLS/SCTP"
proto value), unless it i
s known that UDP/DTLS/SCTP will not work
(for instance, when the I
nteractive Connectivity Establishment
(ICE) mechanism <xref for
mat="default" pageno="false" target="RFC8445"/>
is used and the ICE proce
dures determine that TCP transport is required).
</t>
</section>
<section anchor="section.oa.sctpport" tit
le="SDP sctp-port Attribute" toc="default">
<t>
As defined in <xref targe
t="I-D.ietf-mmusic-sctp-sdp" pageno="false" format="default"/>,
the SDP sctp-port attribu
te value is set to the SCTP port of the SCTPoDTLS association. A
CLUE entity can choose an
y valid SCTP port value <xref target="I-D.ietf-mmusic-sctp-sdp"
pageno="false" format="de
fault"/>.
</t>
</section>
</section>
<section anchor="section.oa.dcmap" title="SDP dcm
ap Attribute" toc="default">
<t>
The values of the SDP dcmap attri
bute <xref target="I-D.ietf-mmusic-data-channel-sdpneg"
pageno="false" format="default" /
>, associated with the "m=" line describing the SCTPoDTLS
association used to realize the W
ebRTC data channel, are set as following:
</t>
<texttable anchor="table_SDP_dcmap" title
='SDP dcmap attribute values'>
<ttcol align='center'>stream-id</
ttcol>
<ttcol align='center'>sub-protoco
l</ttcol>
<ttcol align='center'>label</ttco
l>
<ttcol align='center'>ordered</tt
col>
<ttcol align='center'>max-retr</t
tcol>
<ttcol align='center'>max-time</t
tcol>
<c>Value of the SCTP stream used
to realize the CLUE data channel</c>
<c>"CLUE"</c>
<c>Appli-cation specific</c>
<c>"true"</c>
<c>N/A</c>
<c>N/A</c>
</texttable>
<t>
NOTE: As CLUE entities are requir
ed to use ordered SCTP message delivery,
with full reliability, according
to the procedures in
<xref target="I-D.ietf-mmusic-dat
a-channel-sdpneg" pageno="false"
format="default" /> the max-retr
and max-time attribute parameters
are not used when negotiating CLU
E data channels.
</t>
</section>
<section anchor="section.oa.dcsa" title="SDP dcsa
Attribute" toc="default">
<t>
The SDP dcsa attribute <xref targ
et="I-D.ietf-mmusic-data-channel-sdpneg" pageno="false"
format="default" /> is not used w
hen establishing a CLUE data channel.
</t>
</section>
<section anchor="section.oa.example" title="Examp Original:
le" toc="default"> SCTP stream is defined in [RFC4960] as a unidirectional logical
<t> channel established from one to another associated SCTP endpoint,
The example in <xref target="figu within which all user messages are delivered in sequence except for
re_SDP_example" pageno="false" format="default" /> shows those submitted to the unordered delivery service. -->
an SDP media description for a CL
UE data channel. Examples of complete SDP examples can be found
in <xref target="I-D.ietf-clue-si
gnaling" pageno="false" format="default" />.
</t>
<figure anchor="figure_SDP_example" title
="SDP Media Description for a CLUE data channel">
<artwork><![CDATA[
m=application 54111 UDP/DTLS/SCTP webrtc-datachannel </dd>
a=sctp-port: 5000 </dl>
a=dcmap:2 subprotocol="CLUE";ordered=true <dl newline="true" spacing="normal">
<dt>SCTP stream identifier</dt>
<dd>Defined in <xref target="RFC4960" format="default"/> as an unsigned
integer. Identifies an SCTP stream.</dd>
</dl>
</section>
<section anchor="section.dtls" toc="default" numbered="true">
<name>CLUE Data Channel</name>
<section anchor="section.cdc.gen" toc="default" numbered="true">
<name>General</name>
<t>
This section describes the realization of a CLUE data channel,
using the WebRTC data channel mechanism.
This includes a set of SCTP characteristics specific to a
CLUE data channel, the values of the "m=" line describing
the SCTPoDTLS association associated with the WebRTC
data channel, and the usage of the SDP-based "SCTP
over DTLS" data channel negotiation mechanism for creating the
CLUE data channel.
</t>
<t>
As described in <xref target="RFC8831" format="default"/>, the SCTP stre
ams realizing
a WebRTC data channel must be associated with the same SCTP association.
In addition, both SCTP streams realizing the WebRTC data channel must
use the same SCTP stream identifier value. These rules also apply to
a CLUE data channel.
</t>
<t>
Within a given CLUE session, a CLUE entity <bcp14>MUST</bcp14> use a sin
gle CLUE
data channel for transport of all CLUE messages towards its peer.
</t>
</section>
<section anchor="section.cdc.sctp" toc="default" numbered="true">
<name>SCTP Considerations</name>
<section anchor="section.cdc.sctp.gen" toc="default" numbered="true">
<name>General</name>
<t>
As described in <xref target="RFC8831" format="default"/>, diffe
rent SCTP options
(e.g., regarding ordered delivery) can be used for a
data channel. This section describes the SCTP options
used for a CLUE data channel. <xref target="section.oa" format="
default"/> describes how SCTP options are signaled using SDP.
</t>
<aside><t>
NOTE: While SCTP allows SCTP options to be applied per SCTP mess
age,
<xref target="RFC8831" format="default"/>
mandates that, for a given data channel, the same SCTP options b
e applied
to each SCTP message associated with that data channel.
]]></artwork> <!-- [rfced] Section 3.2.1: We could not find this requirement in
</figure> [I-D.ietf-rtcweb-data-channel], which is now [RFC8831].
</section> Please verify that the text is correct.
</section>
</section>
<section anchor="section.sec" title="Security Considerations"> Original:
NOTE: While SCTP allows SCTP options to be applied per SCTP message,
[I-D.ietf-rtcweb-data-channel] mandates that, for a given data
channel, the same SCTP options are applied to each SCTP message
associated with that data channel. -->
</t></aside>
</section>
<section anchor="section.cdc.sctp.ppid" toc="default" numbered="true">
<name>SCTP Payload Protocol Identifier (PPID)</name>
<t>
A CLUE entity <bcp14>MUST</bcp14> use the PPID value 51 when sen
ding a CLUE message
on a CLUE data channel.
</t>
<aside><t>
NOTE: As described in <xref target="RFC8831" format="default"
/>, the PPID value 51 indicates that
the SCTP message contains data encoded in UTF-8 format. The PPID
value 51 does not indicate which application protocol the SCTP m
essage
is associated with -- only the format in which the data is encod
ed.
</t></aside>
</section>
<section anchor="section.cdc.sctp.reliability" toc="default" numbered="t
rue">
<name>Reliability</name>
<t>
The usage of SCTP for the CLUE data channel ensures reliable tra
nsport of
CLUE protocol messages <xref target="RFC8847" format="default"/>
.</t>
<t>
<xref target="RFC8831" format="default"/>
requires the support of the partial reliability extension defined
in <xref target="RFC3758" format="default"/> and the limited retransmission pol
icy defined in
<xref target="RFC7496" format="default"/>. A CLUE entity <bcp14>M
UST NOT</bcp14> use
these extensions, as messages are required to always be sent rel
iably. A CLUE entity <bcp14>MUST</bcp14>
terminate the session if it detects that the peer entity uses an
y of the extensions.
</t>
</section>
<section anchor="section.cdc.sctp.order" toc="default" numbered="true">
<name>Order</name>
<t>
A CLUE entity <bcp14>MUST</bcp14> use the ordered delivery SCTP
service, as
described in <xref target="RFC4960" format="default"/>,
for the CLUE data channel.
</t>
</section>
<section anchor="section.cdc.sctp.streamreset" toc="default" numbered="t
rue">
<name>Stream Reset</name>
<t>
A CLUE entity <bcp14>MUST</bcp14> support the stream reset exten
sion defined in <xref target="RFC6525" format="default"/>.
</t>
<t>
Per <xref target="RFC8831" format="default"/>,
the dynamic address reconfiguration extension parameter ('Suppor
ted Extensions Parameter')
defined in <xref target="RFC5061" format="default"/> must be use
d to signal the
support of the stream reset extension defined in <xref
target="RFC6525" format="default"/>.
<!-- [rfced] Section 3.2.5: We see that
[I-D.ietf-rtcweb-data-channel] uses "MUST" regarding support for
the stream reset extension. Should "must" be "MUST" here as well?
If yes, we will request AD approval of the update.
Original:
As defined in [I-D.ietf-rtcweb-data-channel], the dynamic address
reconfiguration extension ('Supported Extensions Parameter'
parameter) defined in [RFC5061] must be used to signal the support of
the stream reset extension defined in [RFC6525].
From [RFC8831]:
o The dynamic address reconfiguration extension defined in [RFC5061]
MUST be used to signal the support of the stream reset extension
defined in [RFC6525].
Possibly:
Per [RFC8831], the dynamic address reconfiguration extension
parameter ('Supported Extensions Parameter') defined in [RFC5061]
MUST be used to signal the support of the stream reset extension
defined in [RFC6525]. -->
Other features defined in <xref target="RFC5061" format="default"/>
<bcp14>MUST NOT</bcp14> be used for CLUE data channels.
</t>
</section>
<section anchor="section.cdc.sctp.multihome" toc="default" numbered="tru
e">
<name>SCTP Multihoming</name>
<t>
SCTP multihoming is not supported for SCTPoDTLS associations
and therefore cannot be used for a CLUE data channel.
</t>
</section>
<section anchor="section.cdcp.proc.close" toc="default" numbered="true">
<name>Closing the CLUE Data Channel</name>
<t>
As described in <xref target="RFC8831" format="default"/>, to cl
ose a data channel, an entity sends an SCTP reset
message <xref target="RFC6525" format="default"/> on its outgoin
g
SCTP stream associated with the data channel. When the remote pe
er receives the reset
message, it also sends (unless already sent) a reset message on
its outgoing SCTP
stream associated with the data channel. The SCTPoDTLS associati
on, and other data channels
established on the same association, are not affected by the SCT
P reset messages.
</t>
</section>
</section>
<section anchor="section.oa" toc="default" numbered="true">
<name>SDP Considerations</name>
<section anchor="section.oa.gen" toc="default" numbered="true">
<name>General</name>
<t>This section defines how to (1) construct the SDP media description
("m=" line) for describing the SCTPoDTLS association used to realize
a CLUE data channel and (2)&nbsp;use the
SDP-based "SCTP over DTLS" data channel negotiation mechanism
<xref target="RFC8864" format="default"/> for establishing
a CLUE data channel on the SCTPoDTLS association.</t>
<aside><t>
NOTE: Protocols other than SDP for negotiating usage of an SCTPo
DTLS
association for realizing a CLUE data channel are outside the sc
ope
of this specification.
</t></aside>
<t>
<xref target="RFC8848" format="default"/>
describes the SDP Offer/Answer procedures for negotiating a CLUE
session,
including the CLUE-controlled media streams and the CLUE data ch
annel.
</t>
<section anchor="section.oa.mediadesc" toc="default" numbered="true">
<name>SDP Media Description Fields</name>
<t>
<xref target="RFC8841" format="default"/> defines how
to set the values of an "m=" line describing an SCTPoDTLS associ
ation. As defined in
<xref target="RFC8841" format="default"/>, for a
CLUE data channel the values are set as follows:
</t>
<table anchor="table_SDP_mediadesc" align="center">
<name>SDP "proto" Field Values</name>
<thead>
<tr>
<th align="center">media</th>
<th align="center">port</th>
<th align="center">proto</th>
<th align="center">fmt</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">"application"</td>
<td align="center">UDP port value</td>
<td align="center">"UDP/DTLS/SCTP"</td>
<td align="center">"webrtc-datachannel"</td>
</tr>
<tr>
<td align="center">"application"</td>
<td align="center">TCP port value</td>
<td align="center">"TCP/DTLS/SCTP"</td>
<td align="center">"webrtc-datachannel"</td>
</tr>
</tbody>
</table>
<t>
CLUE entities <bcp14>SHOULD NOT</bcp14> transport the SCTPoDTLS
association used to
realize the CLUE data channel over TCP (using the "TCP/DTLS/SCTP
"
proto value), unless it is known that UDP/DTLS/SCTP will not wor
k
(for instance, when the Interactive Connectivity Establishment
(ICE) mechanism <xref format="default" target="RFC8445"/>
is used and the ICE procedures determine that TCP transport is r
equired).
</t>
</section>
<section anchor="section.oa.sctpport" toc="default" numbered="true">
<name>SDP sctp-port Attribute</name>
<t> <t>
As defined in <xref target="RFC8841" format="default"/>,
the SDP sctp-port attribute value is set to the SCTP port of the
SCTPoDTLS association. A
CLUE entity can choose any valid SCTP port value <xref target="R
FC8841" format="default"/>.
</t>
</section>
</section>
<section anchor="section.oa.dcmap" toc="default" numbered="true">
<name>SDP dcmap Attribute</name>
<t>
The values of the SDP dcmap attribute <xref target="RFC8864" for
mat="default"/>, associated with the "m=" line describing the SCTPoDTLS
association used to realize the WebRTC data channel, are set as
follows:
</t>
<table anchor="table_SDP_dcmap" align="center">
<name>SDP dcmap Attribute Values</name>
<thead>
<tr>
<th align="center">stream-id</th>
<th align="center">subprotocol</th>
<th align="center">label</th>
<th align="center">ordered</th>
<th align="center">max-retr</th>
<th align="center">max-time</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">Value of the SCTP stream used to realize the
CLUE data channel</td>
<td align="center">"CLUE"</td>
<td align="center">Application specific</td>
<td align="center">"true"</td>
<td align="center">N/A</td>
<td align="center">N/A</td>
</tr>
</tbody>
</table>
<aside><t>
NOTE: As CLUE entities are required to use ordered SCTP message
delivery,
with full reliability, according to the procedures in
<xref target="RFC8864" format="default"/> the max-retr and max-t
ime attribute parameters
are not used when negotiating CLUE data channels.
</t></aside>
</section>
<section anchor="section.oa.dcsa" toc="default" numbered="true">
<name>SDP dcsa Attribute</name>
<t>
The SDP dcsa attribute <xref target="RFC8864" format="default"/>
is not used when establishing a CLUE data channel.
</t>
</section>
<section anchor="section.oa.example" toc="default" numbered="true">
<name>Example</name>
<t>
The example in <xref target="figure_SDP_example" format="default
"/> shows
an SDP media description for a CLUE data channel. Complete SDP e
xamples can be found
in <xref target="RFC8848" format="default"/>.
</t>
<figure anchor="figure_SDP_example">
<name>SDP Media Description for a CLUE Data Channel</name>
<sourcecode name="sdp-1" type="sdp"><![CDATA[
m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
a=sctp-port: 5000
a=dcmap:2 subprotocol="CLUE";ordered=true]]></sourcecode> </figure>
</section>
</section>
</section>
<!-- [rfced] We found the following note in the (now removed)
Change Log:
o - NOTE: Comment regarding the Security Considerations is still
pending.
Was this item addressed? -->
<section anchor="section.sec" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
This specification relies on the security properties of the WebR TC data channel described in This specification relies on the security properties of the WebR TC data channel described in
<xref target="I-D.ietf-rtcweb-data-channel" pageno="false" forma t="default" />, including <xref target="RFC8831" format="default"/>, including
reliance on DTLS. Since CLUE sessions are established using SIP/ SDP, protecting the data reliance on DTLS. Since CLUE sessions are established using SIP/ SDP, protecting the data
channel against message modification and recovery requires the u se of SIP authentication channel against message modification and recovery requires the u se of SIP authentication
and authorization mechanisms described in <xref target="RFC3261" pageno="false" format="default" /> and authorization mechanisms described in <xref target="RFC3261" format="default"/>
for session establishment prior to establishing the data channel . for session establishment prior to establishing the data channel .
</t> </t>
</section> </section>
<section anchor="section.iana" title="IANA Considerations"> <section anchor="section.iana" numbered="true" toc="default">
<section anchor="section.iana.dc" title="New WebRTC data <name>IANA Considerations</name>
channel Protocol Value"> <section anchor="section.iana.dc" numbered="true" toc="default">
<t> <name>New WebRTC Data Channel Protocol Value</name>
[RFC EDITOR NOTE: Please replace RFC-XXXX <t>
with the RFC number of this document.] This document adds the 'CLUE' value to the "WebSocket Subprotocol Name R
</t> egistry"
<t> as follows:
This document adds the 'CLUE' value to th </t>
e "WebSocket Subprotocol Name Registry"
as follows:
</t>
<figure>
<artwork align="left"><![CDATA[
Subprotocl Identifier: CLUE <table anchor="clue-reg">
Subprotocol Common Name: CLUE <name>Registration of 'CLUE' Value</name>
Subprotocol Definition: RFC-XXXX <tbody>
Reference: RFC-XXXX <tr>
<td>Subprotocol Identifier</td>
<td>CLUE</td>
</tr>
<tr>
<td>Subprotocol Common Name</td>
<td>CLUE</td>
</tr>
<tr>
<td>Subprotocol Definition</td>
<td>RFC 8850</td>
</tr>
<tr>
<td>Reference</td>
<td>RFC 8850</td>
</tr>
</tbody>
</table>
</section>
</section>
</middle>
<back>
]]></artwork> <!-- [rfced] References: We see that "sortrefs" in the original
</figure> approved document was set to "no"; however, with the exception of
</section> the draft listings, the references were originally displayed in
</section> alphanumeric order. Would you like the references to be sorted in
<section title="Acknowledgments"> this RFC? -->
<t>
Thanks to Paul Kyzivat, Christian Groves and Mark <references>
Duckworth for comments <name>References</name>
on the document. <references>
</t> <name>Normative References</name>
</section> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<section title="Change Log"> xml"/>
<t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.
[RFC EDITOR NOTE: Please remove this section when xml"/>
publishing] <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264.
</t> xml"/>
<t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4566.
Changes from draft-ietf-clue-datachannel-17 xml"/>
<list style="symbols"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.
<t> xml"/>
Editorial changes to Tables based on TSV-ART review. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5061.
</t> xml"/>
</list> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6525.
</t> xml"/>
<t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7496.
Changes from draft-ietf-clue-datachannel-16 xml"/>
<list style="symbols"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
<t> xml"/>
Category changed to Experimental. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8261.
</t> xml"/>
</list>
</t> <!-- draft-ietf-mmusic-sctp-sdp (RFC 8841) -->
<t> <reference anchor="RFC8841" target="https://www.rfc-editor.org/info/rfc8
Changes from draft-ietf-clue-datachannel-15 841">
<list style="symbols"> <front>
<t> <title>Session Description Protocol (SDP) Offer/Answer Procedures
Updates based on IESG review by Roman Danyliw. for Stream Control Transmission Protocol (SCTP) over Datagram
</t> Transport Layer Security (DTLS) Transport</title>
<t> <seriesInfo name="RFC" value="8841"/>
Make CLUE references Informative, as they <seriesInfo name="DOI" value="10.17487/RFC8841"/>
are going to be published as <author initials="C" surname="Holmberg" fullname="Christer Holmberg"
Experimental RFCs. >
</t> <organization/>
</list> </author>
</t> <author initials="R.S." surname="Shpount" fullname="Roman Shpount">
<t> <organization/>
Changes from draft-ietf-clue-datachannel-14 </author>
<list style="symbols"> <author initials="S" surname="Loreto" fullname="Salvatore Loreto">
<t> <organization/>
ICE reference update. </author>
</t> <author initials="G" surname="Camarillo" fullname="Gonzalo Camarillo
<t> ">
Reference draft versions updates. <organization/>
</t> </author>
</list> <date month="June" year="2020"/>
</t> </front>
<t> </reference>
Changes from draft-ietf-clue-datachannel-13
<list style="symbols"> <!-- draft-ietf-rtcweb-data-channel (RFC 8831) -->
<t> <reference anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc88
Editorial changes based on Gen-ART review from Brian Carpent 31">
er. <front>
</t> <title>WebRTC Data Channels</title>
</list> <seriesInfo name="RFC" value="8831"/>
</t> <seriesInfo name="DOI" value="10.17487/RFC8831"/>
<t> <author initials="R" surname="Jesup" fullname="Randell Jesup">
Changes from draft-ietf-clue-datachannel-12 <organization/>
<list style="symbols"> </author>
<t> <author initials="S" surname="Loreto" fullname="Salvatore Loreto">
Changes based on AD comments from Alissa Cooper (https://www.ietf. <organization/>
org/mail-archive/web/clue/current/msg04911.html): </author>
</t> <author initials="M" surname="Tüxen" fullname="Michael Tüxen">
<t> <organization/>
- DCEP reference removed from s </author>
ecurity considerations. <date month="June" year="2020"/>
</t> </front>
<t> </reference>
- Editorial fixes.
</t> <!-- draft-ietf-mmusic-data-channel-sdpneg (RFC 8864) -->
<t> <reference anchor="RFC8864" target="https://www.rfc-editor.org/info/rfc886
- NOTE: Comment regarding the S 4">
ecurity Considerations is still pending. <front>
</t> <title>Data Channel Negotiation Based on the Session Description
</list> Protocol (SDP)</title>
</t> <seriesInfo name="RFC" value="8864"/>
<t> <seriesInfo name="DOI" value="10.17487/RFC8864"/>
Changes from draft-ietf-clue-datachannel-11 <author fullname="Keith Drage" initials="K. E." surname="Drage">
<list style="symbols"> <organization>Unaffiliated</organization>
<t> </author>
Changes based on WGLC comments from Juergen Stoetzer-Bra <author fullname="Raju Makaraju" initials="M. R." surname="Makaraju">
dler and Christian groves: <organization>Nokia</organization>
</t> </author>
<t> <author fullname="Richard Ejzak" initials="R.P." surname="Ejzak">
- Reference updates. <organization>Unaffiliated</organization>
</t> </author>
<t> <author fullname="Jerome Marcon" initials="J.M." surname="Marcon">
- 'Reference' added to IANA registration data. <organization>Unaffiliated</organization>
</t> </author>
</list> <author fullname="Roni Even" initials="R. E." surname="Even" role="edi
</t> tor">
<t> <organization>Huawei</organization>
Changes from draft-ietf-clue-datachannel-10 </author>
<list style="symbols"> <date month="June" year="2020"/>
<t> </front>
Security Considerations modified and enhanced, based on </reference>
comments </references>
provided by Alissa Cooper. <references>
</t> <name>Informative References</name>
</list> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3758.
</t> xml"/>
<t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8445.
Changes from draft-ietf-clue-datachannel-09 xml"/>
<list style="symbols">
<t>Reference updates:</t> <!-- draft-ietf-rtcweb-data-protocol (RFC 8832) -->
<t> - draft-ietf-tsvwg-sctp-prpolicies published as RFC 7496 <reference anchor="RFC8832" target="https://www.rfc-editor.org/info/rfc8
</t> 832">
<t> - Reference update of draft versions</t> <front>
</list> <title>WebRTC Data Channel Establishment Protocol</title>
</t> <seriesInfo name="RFC" value="8832"/>
<t> <seriesInfo name="DOI" value="10.17487/RFC8832"/>
Changes from draft-ietf-clue-datachannel-08 <author initials="R" surname="Jesup" fullname="Randell Jesup">
<list style="symbols"> <organization/>
<t>Changes based on WGLC comments from Da </author>
niel Burnett:</t> <author initials="S" surname="Loreto" fullname="Salvatore Loreto">
<t>- Editorial corrections.</t> <organization/>
<t>Changes based on WGLC comments from Pa </author>
ul Kyzivat:</t> <author initials="M" surname="Tüxen" fullname="Michael Tüxen">
<t>- Editorial corrections.</t> <organization/>
</list> </author>
</t> <date month="June" year="2020"/>
<t> </front>
Changes from draft-ietf-clue-datachannel-07 </reference>
<list style="symbols">
<t>Changes based on WGLC comments from Ch <!-- draft-ietf-clue-protocol (RFC 8847) -->
ristian Groves:</t> <reference anchor="RFC8847" target="https://www.rfc-editor.org/info/rfc8
<t>- IANA considerations for dcmap attrib 847">
ute removed.</t> <front>
<t>- Explicit clarification that the dcma <title>Protocol for Controlling Multiple Streams for Telepresence (C
p attribute max-time LUE)</title>
and max-retr parameters are not <seriesInfo name="RFC" value="8847"/>
used with ordered/reliable <seriesInfo name="DOI" value="10.17487/RFC8847"/>
transmission of SCTP messages.</ <author fullname="Roberta Presta" initials="R." surname="Presta">
t> <organization>University of Napoli</organization>
<t>- Indication that TCP transport should </author>
only be used if ICE is used, <author fullname="Simon Pietro Romano" initials="S P." surname="Roma
and if usage of TCP is required by I no">
CE.</t> <organization>University of Napoli</organization>
<t>- Informative reference to ICE added.< </author>
/t> <date month="June" year="2020"/>
<t>- Editorial corrections.</t> </front>
<t>Changes based on WGLC comments from Ma </reference>
rk Duckworth:</t>
<t>- Make it more clear that the rules re <!-- draft-ietf-clue-signaling (RFC 8848) -->
garding usage of partial <!-- Sent email 1/27/2020 re. "Hanton"; s/b Hansen? -->
reliability and ordered reliability <reference anchor="RFC8848" target="https://www.rfc-editor.org/info/rfc8
apply to CLUE data channels.</t> 848">
<t>Changes based on WGLC comments from Pa <front>
ul Kyzivat:</t> <title>Session Signaling for Controlling Multiple Streams for Telepr
<t>- Clarify that same SCTP options are a esence (CLUE)</title>
pplied to each SCTP message <seriesInfo name="RFC" value="8848"/>
associated with a given data channel <seriesInfo name="DOI" value="10.17487/RFC8848"/>
.</t> <author fullname="Robert Hanton" initials="R." surname="Hanton">
<t>- Switched location of sections 3.2 an <organization>Cisco</organization>
d 3.3.</t> </author>
<t>- PPID table removed. Not needed, sinc <author fullname="Paul Kyzivat" initials="P." surname="Kyzivat">
e only one value is used.</t> </author>
<t>- Editorial corrections.</t> <author fullname="Lennard Xiao" initials="L." surname="Xiao">
</list> <organization>Huawei</organization>
</t> </author>
<t> <author fullname="Christian Groves" initials="C." surname="Groves">
Changes from draft-ietf-clue-datachannel-06 <organization>Huawei</organization>
<list style="symbols"> </author>
<t>Usage of DCEP removed.</t> <date month="June" year="2020"/>
</list> </front>
</t> </reference>
<t> </references>
Changes from draft-ietf-clue-datachannel-05 </references>
<list style="symbols"> <section numbered="false" toc="default">
<t>"DTLS/SCTP" split into "UDP/DTLS/SCTP" <name>Acknowledgements</name>
and "TCP/DTLS/SCTP".</t> <t>
<t>Removed note regarding optionality of Thanks to <contact fullname="Paul Kyzivat"/>,
including the SDP <contact fullname="Christian Groves"/>, and
sctp-port attribute.</t> <contact fullname="Mark Duckworth"/> for comments
<t>Added defintion of 'SCTPoDTLS associat on this document.
ion' to the </t>
Conventions.</t> </section>
<t>Reference to RFC 4566 (SDP) added.</t> </back>
</list>
</t>
<t>
Changes from draft-ietf-clue-datachannel-04
<list style="symbols">
<t>Defines DCEP and external SDP negotiat
ion as two separate mechanisms
for negotiating a CLUE data channel.</t>
<t>Updates based on technical changes in
referenced specifications.</t>
<t>Reference to draft-ietf-mmusic-sctp-sd
p added.</t>
</list>
</t>
<t>
Changes from draft-ietf-clue-datachannel-03
<list style="symbols">
<t>IANA considerations added.</t>
<t>Editorial changes based on comments fr
om Christian Groves.</t>
</list>
</t>
<t>
Changes from draft-ietf-clue-datachannel-02
<list style="symbols">
<t>SDP "m=" line example fixed.</t>
<t>OPEN ISSUE #1 closed.</t>
<t>- It was agreed (IETF#91) to use draft
-ejzak-mmusic-data-channel-sdpneg,
as it was adopted as a WG item in
MMUSIC.
</t>
<t>- Details for draft-ejzak-mmusic-data-
channel-sdpneg usage added.</t>
<t>SDP Offer/Answer procedures removed, a
s they will be defined in the CLUE protocol draft.</t>
<t>References updated.</t>
</list>
</t>
<t>
Changes from draft-ietf-clue-datachannel-01
<list style="symbols">
<t>Support of interleaving "MUST"->"SHOUL
D".</t>
<t>Example updated.</t>
<t>Reference update.</t>
</list>
</t>
<t>
Changes from draft-ietf-clue-datachannel-00
<list style="symbols">
<t>SDP Offer/Answer procedures structures
according to RFC 3264.</t>
<t>Reference update.</t>
</list>
</t>
<t>
Changes from draft-holmberg-clue-datachannel-04
<list style="symbols">
<t>Draft submitted as draft-ietf-clue-dat
a-channel-00.</t>
<t>Editorial nits fixed.</t>
<t>Changes based on comments from Paul Ky
zivat (http://www.ietf.org/mail-archive/web/clue/current/msg03559.html).</t>
<t>- Proto value fixed.</t>
<t>- Explicit text that the partial relia
bility and limited retransmission
policies MUST NOT be used.</t>
<t>- Added open issue on whether the DCEP
'protocol' field value for CLUE
should contain a version number.<
/t>
<t>- Removed paragraph saying that an off
erer must not insert more than
one "m=" line describing an SCTPo
DTLS association to be used to
realize a CLUE data channel, as t
he draft already states that
only one CLUE data channel per CL
UE session shall be opened.</t>
<t>- Added reference to draft-ietf-rtcweb
-data-protocol regarding details
on reseting SCTP streams.</t>
<t>- Added text saying that the value of
the DCEP 'channel type' MUST
be DATA_CHANNEL_RELIABLE.</t>
<t>- Clarified that DCEP must be supporte
d, and used in the absence of another
mechanism for opening a CLUE data
channel.</t>
</list>
</t>
<t>
Changes from draft-holmberg-clue-datachannel-03
<list style="symbols">
<t>Procedures updated, based on WG agreem
ent (IETF#89) to
use DCEP for the CLUE data channe
l.</t>
<t>Procedures updated, based on WG agreem
ent (IETF#89) that
offerer is responsible for sendin
g DCEP DATA_CHANNEL_OPEN.</t>
<t>Editorial changes, and alignments caus
ed by
changes in referenced specificati
ons.</t>
</list>
</t>
<t>
Changes from draft-holmberg-clue-datachannel-02
<list style="symbols">
<t>PPID value for CLUE messages added</t>
<t>References updated</t>
</list>
</t>
<t>
Changes from draft-holmberg-clue-datachannel-01
<list style="symbols">
<t>More text added</t>
</list>
</t>
<t>
Changes from draft-holmberg-clue-datachannel-00
<list style="symbols">
<t>Editorial corrections based on comment
s from Paul K</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.3264"?>
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.RFC.4960"?>
<?rfc include="reference.RFC.5061"?>
<?rfc include="reference.RFC.6525"?>
<?rfc include="reference.RFC.7496"?>
<?rfc include="reference.RFC.8174"?>
<?rfc include="reference.RFC.8261"?>
<reference anchor="I-D.ietf-mmusic-sctp-sdp">
<front>
<title abbrev="The SCTP protocol identifi
er for SDP">
Stream Control Transmission Proto
col (SCTP)-Based Media
Transport in the Session Descript
ion Protocol (SDP)
</title>
<author initials="C." surname="Holmberg"
fullname="Christer Holmberg">
<organization>Ericsson</organizat
ion>
</author>
<author initials="S." surname="Loreto" fu
llname="Salvatore Loreto">
<organization>Ericsson</organizat
ion>
</author>
<author initials="G." surname="Camarillo"
fullname="Gonzalo Camarillo">
<organization>Ericsson</organizat
ion>
</author>
<date day="20" month="April" year="2017"
/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ie
tf-mmusic-sctp-sdp-26.txt" />
</reference>
<reference anchor="I-D.ietf-rtcweb-data-channel">
<front>
<title abbrev="WebRTC data channels">
WebRTC data channels
</title>
<author fullname="Randell Jesup" initials
="R.J" surname="Jesup">
<organization>WorldGate Communica
tions</organization>
</author>
<author fullname="Salvatore Loreto" initi
als="S.L" surname="Loreto">
<organization>Ericsson</organizat
ion>
</author>
<author fullname="Michael Tuexen" initial
s="M.T" surname="Tuexen">
<organization>Muenster University
of Applied Sciences</organization>
</author>
<date day="4" month="January" year="2015"
/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ie
tf-rtcweb-data-channel-13.txt" />
</reference>
<reference anchor="I-D.ietf-mmusic-data-channel-sdpneg">
<front>
<title abbrev="SDP-based 'SCTP over DTLS'
data channel negotiation">
SDP-based "SCTP over DTLS" data c
hannel negotiation
</title>
<author fullname="Keith Drage" initials="
K.D" surname="Drage">
<organization>Alcatel-Lucent</org
anization>
</author>
<author fullname="Raju Makaraju" initials
="R.M" surname="Makaraju">
<organization>Alcatel-Lucent</org
anization>
</author>
<author fullname="Juergen Stoetzer-Bradle
r" initials="J.S" surname="Stoetzer-Bradler">
<organization>Alcatel-Lucent</org
anization>
</author>
<author fullname="Richard Ejzak" initials
="R.E" surname="Ejzak">
<organization>Unaffiliated</organ
ization>
</author>
<author fullname="Jerome Marcon" initials
="J.M" surname="Marcon">
<organization>Unaffiliated</organ
ization>
</author>
<date day="23" month="April" year="2019"
/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ie
tf-mmusic-data-channel-sdpneg-26.txt" />
</reference>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3758"?>
<?rfc include="reference.RFC.8445"?>
<reference anchor="I-D.ietf-rtcweb-data-protocol">
<front>
<title abbrev="WebRTC data channel Establ
ishment Protocol">
WebRTC data channel Establishment
Protocol
</title>
<author fullname="Randell Jesup" initials
="R.J" surname="Jesup">
<organization>WorldGate Communica
tions</organization>
</author>
<author fullname="Salvatore Loreto" initi
als="S.L" surname="Loreto">
<organization>Ericsson</organizat
ion>
</author>
<author fullname="Michael Tuexen" initial
s="M.T" surname="Tuexen">
<organization>Muenster University
of Applied Sciences</organization>
</author>
<date day="4" month="January" year="2015"
/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ie
tf-rtcweb-data-protocol-09.txt" />
</reference>
<reference anchor="I-D.ietf-clue-
protocol">
<front>
<title abbrev="CLUE protocol">
CLUE protocol
</title>
<author fullname="Roberta Presta" initial
s="R.P" surname="Presta">
<organization>University of Napol
i</organization>
</author>
<author fullname="Simon Pietro Romano" in
itials="S P.R" surname="Romano">
<organization>University of Napol
i</organization>
</author>
<date day="21" month="September" year="20
18" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ie
tf-clue-protocol-17.txt" />
</reference>
<reference anchor="I-D.ietf-clue-signaling">
<front>
<title abbrev="CLUE signaling">
CLUE Signaling
</title>
<author fullname="Paul Kyzivat" initials=
"P.K" surname="Kyzivat">
</author>
<author fullname="Lennard Xiao" initials=
"L.X" surname="Xiao">
<organization>Huawei</organizatio
n>
</author>
<author fullname="Christian Groves" initi
als="C.G" surname="Groves">
<organization>Huawei</organizatio
n>
</author>
<author fullname="Robert Hansen" initials
="S P.R" surname="Romano">
<organization>Cisco</organization
>
</author>
<date day="22" month="October" year="2018
" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ie
tf-clue-signaling-14.txt" />
</reference>
</references>
</back>
</rfc> </rfc>
 End of changes. 21 change blocks. 
1065 lines changed or deleted 721 lines changed or added

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