rfc8832xml2.original.xml   rfc8832.xml 
<?xml version='1.0' encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc symrefs='yes'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc toc='yes' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='no' ?>
<?rfc sortrefs='no' ?>
<?rfc strict='yes' ?>
<rfc category='std'
ipr='trust200902'
number="XXXX"
submissionType="IETF"
consensus="yes"
>
<front>
<title>WebRTC Data Channel Establishment Protocol</title>
<author initials='R.' surname='Jesup' fullname='Randell Jesup'>
<organization>Mozilla</organization>
<address>
<postal>
<street></street>
<code></code>
<city></city>
<country>United States of America</country>
</postal>
<email>randell-ietf@jesup.org</email>
</address>
</author>
<author initials='S.' surname='Loreto' fullname='Salvatore Loreto'>
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>salvatore.loreto@ericsson.com</email>
</address>
</author>
<author initials='M.' surname='Tuexen' fullname='Michael Tuexen'>
<organization abbrev='Muenster Univ. of Appl. Sciences'>
Muenster University of Applied Sciences</organization>
<address>
<postal>
<street>Stegerwaldstrasse 39</street>
<code>48565</code>
<city> Steinfurt</city>
<country>Germany</country>
</postal>
<email>tuexen@fh-muenster.de</email>
</address>
</author>
<date month="October" year="2018" /> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
<area>RAI</area> ipr="trust200902" number="8832" submissionType="IETF" consensus="true"
obsoletes="" updates="" xml:lang="en" symRefs="true" tocInclude="true"
sortRefs="false" version="3" docName="draft-ietf-rtcweb-data-protocol-09">
<!-- [rfced] Please insert any keywords (beyond those that appear in <!-- xml2rfc v2v3 conversion 2.30.0 -->
the title) for use on https://www.rfc-editor.org/search. <front>
<title>WebRTC Data Channel Establishment Protocol</title>
<seriesInfo name="RFC" value="8832"/>
<author initials="R." surname="Jesup" fullname="Randell Jesup">
<organization>Mozilla</organization>
<address>
<postal>
<street/>
<code/>
<city/>
<country>United States of America</country>
</postal>
<email>randell-ietf@jesup.org</email>
</address>
</author>
<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>salvatore.loreto@ericsson.com</email>
</address>
</author>
<author initials="M." surname="Tüxen" fullname="Michael Tüxen">
<organization abbrev="Münster Univ. of Appl. Sciences">
Münster University of Applied Sciences</organization>
<address>
<postal>
<street>Stegerwaldstrasse 39</street>
<code>48565</code>
<city> Steinfurt</city>
<country>Germany</country>
</postal>
<email>tuexen@fh-muenster.de</email>
</address>
</author>
<keyword>example</keyword> <date month="October" year="2020"/>
<area>ART</area>
<abstract> <abstract>
<t>The WebRTC framework specifies protocol support for direct interactive <t>The WebRTC framework specifies protocol support for direct interactive
rich communication using audio, video, and data between two peers' web browsers. rich communication using audio, video, and data between two peers' web browsers.
This document specifies a simple protocol for establishing symmetric This document specifies a simple protocol for establishing symmetric
data channels between the peers. It uses a two-way handshake and allows data channels between the peers. It uses a two-way handshake and allows
sending of user data without waiting for the handshake to complete.</t> sending of user data without waiting for the handshake to complete.</t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section numbered="true" toc="default">
<section title='Introduction'> <name>Introduction</name>
<t>The Data Channel Establishment Protocol (DCEP) is designed to provide, in the <t>The Data Channel Establishment Protocol (DCEP) is designed to provide,
WebRTC data channel context <xref target='RFCYYYY'/>, in the
WebRTC data channel context <xref target="RFC8831" format="default"/>,
a simple in-band method for opening symmetric data channels. a simple in-band method for opening symmetric data channels.
As discussed in <xref target='RFCYYYY'/>, the protocol uses As discussed in <xref target="RFC8831" format="default"/>, the protocol uses
the Stream Control Transmission Protocol (SCTP) <xref target='RFC4960'/> the Stream Control Transmission Protocol (SCTP) <xref target="RFC4960" format="d
encapsulated in the Datagram Transport Layer Security (DTLS) (described in efault"/>
<xref target='RFC8261'/>). This allows the DCEP to benefit from the encapsulated in Datagram Transport Layer Security (DTLS) (described in
<xref target="RFC8261" format="default"/>). This allows DCEP to benefit from the
already standardized transport already standardized transport
and security features of SCTP and DTLS. DTLS 1.0 is defined in <xref target='RFC and security features of SCTP and DTLS. DTLS 1.0 is defined in <xref target="RFC
4347'/>, and the 4347" format="default"/>, and the
present latest version, DTLS 1.2, is defined in <xref target='RFC6347'/>. present latest version, DTLS 1.2, is defined in <xref target="RFC6347" format="d
efault"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title='Conventions'> <name>Conventions</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"MAY", and "OPTIONAL" in this document are to be interpreted as NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> 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"/> <xref target="
RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown here. when, and only when, they appear in all capitals, as shown here.
</t> </t>
</section>
</section> <section numbered="true" toc="default">
<name>Terminology</name>
<t>This document uses the following terms:
</t>
<section title='Terminology'> <dl newline="false" spacing="normal">
<t>This document uses the following terms: <dt>Association:</dt>
<list style='hanging'> <dd>An SCTP association.</dd>
<t hangText='Association:'> <dt>Stream:</dt>
An SCTP association.</t> <dd>
<t hangText='Stream:'>
A unidirectional stream of an SCTP association. It is uniquely identified A unidirectional stream of an SCTP association. It is uniquely identified
by an SCTP stream identifier (0-65534). by an SCTP stream identifier (0-65534).
Note: The SCTP stream identifier 65535 is reserved due to SCTP INIT and Note: The SCTP stream identifier 65535 is reserved due to SCTP INIT and
INIT-ACK chunks only allowing a maximum of 65535 Streams to be INIT-ACK chunks only allowing a maximum of 65535 streams to be
negotiated (0-65534).</t> negotiated (0-65534).</dd>
<t hangText='stream identifier:'> <dt>Stream Identifier:</dt>
The SCTP stream identifier uniquely identifying a Stream.</t> <dd>
<t hangText='Data Channel:'> The SCTP stream identifier uniquely identifying a stream.</dd>
Two Streams with the same stream identifier, one in each direction, <dt>Data Channel:</dt>
which are managed together.</t> <dd>
</list></t> Two streams with the same stream identifier, one in each direction,
</section> which are managed together.</dd>
</dl>
<section title='Protocol Overview'> </section>
<t>The Data Channel Establishment Protocol is a simple, low-overhead way <section numbered="true" toc="default">
<name>Protocol Overview</name>
<t>The Data Channel Establishment Protocol is a simple, low-overhead way
to establish bidirectional data channels over an SCTP association with a to establish bidirectional data channels over an SCTP association with a
consistent set of properties.</t> consistent set of properties.</t>
<t>The set of consistent properties includes: <t>The set of consistent properties includes:
<list style='symbols'> </t>
<t>reliable or unreliable message transmission. In case of unreliable <ul spacing="normal">
transmissions, the same level of unreliability is used.</t> <li>reliable or unreliable message transmission. In case of unreliable
<t>in-order or out-of-order message delivery.</t> transmissions, the same level of unreliability is used.</li>
<t>the priority of the data channel.</t> <li>in-order or out-of-order message delivery.</li>
<t>an optional label for the data channel.</t> <li>the priority of the data channel.</li>
<t>an optional protocol for the data channel.</t> <li>an optional label for the data channel.</li>
<t>the Streams.</t> <li>an optional protocol for the data channel.</li>
</list></t> <li>the streams.</li>
<t>This protocol uses a two-way handshake to open a data channel. </ul>
The handshake pairs one incoming and one outgoing Stream, both having the <t>This protocol uses a two-way handshake to open a data channel.
The handshake pairs one incoming and one outgoing stream, both having the
same stream identifier, into a single bidirectional data channel. same stream identifier, into a single bidirectional data channel.
The peer that initiates opening a data channel selects a Stream The peer that initiates opening a data channel selects a stream
Identifier for which the corresponding incoming and outgoing Streams identifier for which the corresponding incoming and outgoing streams
are unused and sends a DATA_CHANNEL_OPEN message on the outgoing Stream. are unused and sends a DATA_CHANNEL_OPEN message on the outgoing stream.
The peer responds with a DATA_CHANNEL_ACK message on its corresponding The peer responds with a DATA_CHANNEL_ACK message on its corresponding
outgoing Stream. Then the data channel is open. outgoing stream. Then the data channel is open.
DCEP messages are sent on the same Stream as DCEP messages are sent on the same stream as
the user messages belonging to the data channel. the user messages belonging to the data channel.
The demultiplexing is based on the SCTP payload protocol identifier (PPID), The demultiplexing is based on the SCTP Payload Protocol Identifier (PPID),
since the Data Channel Establishment Protocol uses a specific PPID.</t> since DCEP uses a specific PPID.</t>
<t>Note: The opening side MAY send user messages before the DATA_CHANNEL_ACK <aside><t>Note: The opening side <bcp14>MAY</bcp14> send user messages bef
is received.</t> ore the DATA_CHANNEL_ACK
<t>To avoid collisions where both sides try to open a data channel with is received.</t></aside>
the same stream identifiers, each side MUST use Streams with either even or <t>To avoid collisions where both sides try to open a data channel with
the same stream identifiers, each side <bcp14>MUST</bcp14> use streams with eith
er even or
odd stream identifiers when sending a DATA_CHANNEL_OPEN message. odd stream identifiers when sending a DATA_CHANNEL_OPEN message.
When using SCTP over DTLS <xref target='RFC8261'/>, When using SCTP over DTLS <xref target="RFC8261" format="default"/>,
the method used to determine which side uses odd or even is based on the the method used to determine which side uses odd or even is based on the
underlying DTLS connection role: underlying DTLS connection role:
the side acting as the DTLS client MUST use Streams with even the side acting as the DTLS client <bcp14>MUST</bcp14> use streams with even
stream identifiers; the side acting as the DTLS server MUST use Streams stream identifiers; the side acting as the DTLS server <bcp14>MUST</bcp14> use s
treams
with odd stream identifiers.</t> with odd stream identifiers.</t>
<t>Note: There is no attempt to ensure uniqueness for the label; <aside><t>Note: There is no attempt to ensure uniqueness for the label;
if both sides open a data channel labeled "x" at the same time, there will be if both sides open a data channel labeled "x" at the same time, there will be
two data channels labeled "x" -- one on an even Stream pair, one on an odd pair. two data channels labeled "x" -- one on an even stream pair, one on an odd pair.
</t> </t></aside>
<!--[rfced] FYI, we changed the following sentence for clarity; please check
that it still conveys the intended meaning.
Original:
The protocol field is to ease cross-application interoperation
("federation") by identifying the user data being passed with an
IANA-registered string ('WebSocket Subprotocol Name Registry' defined
in [RFC6455]), and may be useful for homogeneous applications which
may create more than one type of Data Channel.
New: <t>The purpose of the protocol field is to ease cross-application interope
The purpose of the protocol field is to ease cross-application ration ("federation")
interoperation ("federation") by identifying the user data being
passed by means of an IANA-registered string from the "WebSocket
Subprotocol Name Registry" defined in [RFC6455]. The field may be
useful for homogeneous applications that may create more than one
type of data channel.
<t>The purpose of the protocol field is to ease cross-application interoperation
("federation")
by identifying the user data being passed by means of an IANA-registered string by identifying the user data being passed by means of an IANA-registered string
from the "WebSocket Subprotocol Name Registry" defined in <xref target='RFC6455' />. from the "WebSocket Subprotocol Name Registry" defined in <xref target="RFC6455" format="default"/>.
The field may be useful for homogeneous applications that may create more than o ne The field may be useful for homogeneous applications that may create more than o ne
type of data channel. type of data channel.
Please note that there is no attempt to ensure uniqueness for the protocol Note that there is no attempt to ensure uniqueness for the protocol
field.</t> field.</t>
</section> </section>
<section anchor="msg_format" numbered="true" toc="default">
<section title='Message Formats' <name>Message Formats</name>
anchor='msg_format'> <t>Every DCEP message starts with a one-byte
<t>Every DCEP message starts with a one-byte
field called "Message Type" that indicates the type of the message. field called "Message Type" that indicates the type of the message.
The corresponding values are managed by IANA The corresponding values are managed by IANA
(see <xref target='iana_msg_type'/>).</t> (see <xref target="iana_msg_type" format="default"/>).</t>
<section anchor="open_msg_format" numbered="true" toc="default">
<section title='DATA_CHANNEL_OPEN Message' <name>DATA_CHANNEL_OPEN Message</name>
anchor='open_msg_format'> <t>This message is initially sent using the data channel on the stream u
<t>This message is initially sent using the data channel on the Stream used sed
for user messages.</t> for user messages.</t>
<figure> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align='center'>
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Channel Type | Priority | | Message Type | Channel Type | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reliability Parameter | | Reliability Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Length | Protocol Length | | Label Length | Protocol Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ / \ /
| Label | | Label |
/ \ / \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ / \ /
| Protocol | | Protocol |
/ \ / \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
</figure> <dl newline="true" spacing="normal">
<t><list style='hanging'> <dt>Message Type: 1 byte (unsigned integer)</dt><dd>
<t hangText='Message Type: 1 byte (unsigned integer)'> <!-- [MT] Changed the formatting to have the type on the same line as the name -
<vspace blankLines='0'/> ->
<t>
This field holds the IANA-defined message type for the DATA_CHANNEL_OPEN This field holds the IANA-defined message type for the DATA_CHANNEL_OPEN
message. The value of this field is 0x03, as specified in message. The value of this field is 0x03, as specified in
<xref target='iana_msg_type'/>.</t> <xref target="iana_msg_type" format="default"/>.</t></dd>
<t hangText='Channel Type: 1 byte (unsigned integer)'> <dt>Channel Type: 1 byte (unsigned integer)</dt><dd>
<vspace blankLines='0'/> <!-- [MT] Changed the formatting to have the type on the same line as the name -
->
<t>
This field specifies the type of data channel to be opened. The This field specifies the type of data channel to be opened. The
values are managed by IANA (see <xref target='iana_channel_type'/>): values are managed by IANA (see <xref target="iana_channel_type" format="default
<list style='hanging'> "/>):
<t hangText='DATA_CHANNEL_RELIABLE (0x00):'> </t>
The data channel provides a reliable in-order bidirectional communication.</t> <dl newline="false" spacing="normal">
<t hangText='DATA_CHANNEL_RELIABLE_UNORDERED (0x80):'> <dt>DATA_CHANNEL_RELIABLE (0x00):</dt>
The data channel provides a reliable unordered bidirectional communication.</t> <dd>
The data channel provides a reliable in-order bidirectional communication.</dd>
<!--[rfced] The rest of this document refers to "partial reliable" <dt>DATA_CHANNEL_RELIABLE_UNORDERED (0x80):</dt>
communication, but the following sentence uses "partially <dd>
reliable". Please let us know which wording, if any, should be changed. The data channel provides a reliable unordered bidirectional communication.</dd>
ORIGINAL: <dt>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01):</dt>
The Data Channel provides a partially reliable in-order bidirectional <dd>
communication.
<t hangText='DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01):'>
The data channel provides a partially reliable in-order bidirectional The data channel provides a partially reliable in-order bidirectional
communication. User messages will not be retransmitted more times communication. User messages will not be retransmitted more times
than specified in the Reliability Parameter.</t> than specified in the Reliability Parameter.</dd>
<t hangText='DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81):'> <dt>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81):</dt>
The data channel provides a partial reliable unordered bidirectional <dd>
The data channel provides a partially reliable unordered bidirectional
communication. User messages will not be retransmitted more times communication. User messages will not be retransmitted more times
than specified in the Reliability Parameter.</t> than specified in the Reliability Parameter.</dd>
<t hangText='DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02):'> <dt>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02):</dt>
The data channel provides a partial reliable in-order bidirectional <dd>
The data channel provides a partially reliable in-order bidirectional
communication. User messages might not be transmitted or communication. User messages might not be transmitted or
retransmitted after a specified lifetime given in milliseconds in the retransmitted after a specified lifetime given in milliseconds in the
Reliability Parameter. This lifetime starts when providing the user Reliability Parameter. This lifetime starts when providing the user
message to the protocol stack.</t> message to the protocol stack.</dd>
<t hangText='DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82):'> <dt>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82):</dt>
The data channel provides a partial reliable unordered bidirectional <dd>
The data channel provides a partially reliable unordered bidirectional
communication. User messages might not be transmitted or communication. User messages might not be transmitted or
retransmitted after a specified lifetime given in milliseconds in the retransmitted after a specified lifetime given in milliseconds in the
Reliability Parameter. This lifetime starts when providing the user Reliability Parameter. This lifetime starts when providing the user
message to the protocol stack.</t> message to the protocol stack.</dd>
</list></t> </dl>
<t hangText='Priority: 2 bytes (unsigned integer)'> </dd>
<vspace blankLines='0'/> <dt>Priority: 2 bytes (unsigned integer)</dt><dd>
<!-- [MT] Changed the formatting to have the type on the same line as the name -
->
<t>
The priority of the data channel, as described in The priority of the data channel, as described in
<xref target='RFCYYYY'/>.</t> <xref target="RFC8831" format="default"/>.</t></dd>
<t hangText='Reliability Parameter: 4 bytes (unsigned integer)'> <dt>Reliability Parameter: 4 bytes (unsigned integer)</dt><dd>
<vspace blankLines='0'/> <!-- [MT] Changed the formatting to have the type on the same line as the name -
For reliable data channels, this field MUST be set to 0 on the sending side ->
and MUST be ignored on the receiving side. <t>
If a partial reliable data channel with a limited number of retransmissions is For reliable data channels, this field <bcp14>MUST</bcp14> be set to 0 on the se
used, this field specifies the number of retransmissions. If a partial nding side
and <bcp14>MUST</bcp14> be ignored on the receiving side.
If a partially reliable data channel with a limited number of retransmissions is
used, this field specifies the number of retransmissions. If a partially
reliable data channel with a limited lifetime is used, this field specifies reliable data channel with a limited lifetime is used, this field specifies
the maximum lifetime in milliseconds. The following table summarizes this:</t> the maximum lifetime in milliseconds. The following table summarizes this:</t></
</list></t> dd>
<texttable> </dl>
<ttcol align='left'>Channel Type</ttcol> <table align="center">
<ttcol align='center'>Reliability Parameter</ttcol> <thead>
<c>DATA_CHANNEL_RELIABLE</c> <c>Ignored</c> <tr>
<c>DATA_CHANNEL_RELIABLE_UNORDERED</c> <c>Ignored</c> <th align="left">Channel Type</th>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT</c> <c>Number of RTX</c> <th align="center">Reliability Parameter</th>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED</c><c>Number of RTX</c> </tr>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED</c> <c>Lifetime in ms</c> </thead>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED</c> <c>Lifetime in ms</c> <tbody>
</texttable> <tr>
<t><list style='hanging'> <td align="left">DATA_CHANNEL_RELIABLE</td>
<t hangText='Label Length: 2 bytes (unsigned integer)'> <td align="center">Ignored</td>
<vspace blankLines='0'/> </tr>
The length of the label field in bytes.</t> <tr>
<t hangText='Protocol Length: 2 bytes (unsigned integer)'> <td align="left">DATA_CHANNEL_RELIABLE_UNORDERED</td>
<vspace blankLines='0'/> <td align="center">Ignored</td>
The length of the protocol field in bytes.</t> </tr>
<t hangText='Label: Variable Length (sequence of characters)'> <tr>
<vspace blankLines='0'/> <td align="left">DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT</td>
<td align="center">Number of RTX</td>
</tr>
<tr>
<td align="left">DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED</t
d>
<td align="center">Number of RTX</td>
</tr>
<tr>
<td align="left">DATA_CHANNEL_PARTIAL_RELIABLE_TIMED</td>
<td align="center">Lifetime in ms</td>
</tr>
<tr>
<td align="left">DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED</td
>
<td align="center">Lifetime in ms</td>
</tr>
</tbody>
</table>
<dl newline="true" spacing="normal">
<dt>Label Length: 2 bytes (unsigned integer)</dt><dd>
<!-- [MT] Changed the formatting to have the type on the same line as the name -
->
<t>
The length of the label field in bytes.</t></dd>
<dt>Protocol Length: 2 bytes (unsigned integer)</dt><dd>
<!-- [MT] Changed the formatting to have the type on the same line as the name -
->
<t>
The length of the protocol field in bytes.</t></dd>
<dt>Label: Variable Length (sequence of characters)</dt><dd>
<!-- [MT] Changed the formatting to have the type on the same line as the name -
->
<t>
The name of the data channel as a UTF-8-encoded string, as specified in The name of the data channel as a UTF-8-encoded string, as specified in
<xref target='RFC3629'/>. This may be an empty string.</t> <xref target="RFC3629" format="default"/>. This may be an empty string.</t></dd>
<t hangText='Protocol: Variable Length (sequence of characters)'> <dt>Protocol: Variable Length (sequence of characters)</dt><dd>
<vspace blankLines='0'/> <!-- [MT] Changed the formatting to have the type on the same line as the name -
->
<t>
If this is an empty string, the protocol is unspecified. If this is an empty string, the protocol is unspecified.
If it is a non-empty string, it specifies a protocol registered in the If it is a non-empty string, it specifies a protocol registered in the
"WebSocket Subprotocol Name Registry" created in "WebSocket Subprotocol Name Registry" created in
<xref target='RFC6455'/>. This string is UTF-8 encoded, as specified in <xref target="RFC6455" format="default"/>. This string is UTF-8 encoded, as spec
<xref target='RFC3629'/>.</t> ified in
</list></t> <xref target="RFC3629" format="default"/>.</t></dd>
</section> </dl>
</section>
<section title='DATA_CHANNEL_ACK Message'> <section numbered="true" toc="default">
<t>This message is sent in response to a <name>DATA_CHANNEL_ACK Message</name>
DATA_CHANNEL_OPEN_RESPONSE message. It is sent on the Stream used for user <t>This message is sent in response to a
DATA_CHANNEL_OPEN_RESPONSE message. It is sent on the stream used for user
messages using the data channel. messages using the data channel.
Reception of this message tells the opener that the data channel setup Reception of this message tells the opener that the data channel setup
handshake is complete.</t> handshake is complete.</t>
<figure> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align='center'>
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | | Message Type |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
</figure> <dl newline="true" spacing="normal">
<t><list style='hanging'> <dt>Message Type: 1 byte (unsigned integer)</dt><dd>
<t hangText='Message Type: 1 byte (unsigned integer)'> <!-- [MT] Changed the formatting to have the type on the same line as the name -
<vspace blankLines='0'/> ->
<t>
This field holds the IANA-defined message type for the DATA_CHANNEL_ACK This field holds the IANA-defined message type for the DATA_CHANNEL_ACK
message. The value of this field is 0x02, as specified in message. The value of this field is 0x02, as specified in
<xref target='iana_msg_type'/>.</t> <xref target="iana_msg_type" format="default"/>.</t></dd>
</list></t> </dl>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title='Procedures'> <name>Procedures</name>
<t>All DCEP messages MUST be sent using ordered delivery and reliable <t>All DCEP messages <bcp14>MUST</bcp14> be sent using ordered delivery an
transmission. They MUST be sent on the same outgoing Stream as the user messages d reliable
transmission. They <bcp14>MUST</bcp14> be sent on the same outgoing stream as th
e user messages
belonging to the corresponding data channel. belonging to the corresponding data channel.
Multiplexing and demultiplexing is done by using the SCTP payload protocol Multiplexing and demultiplexing is done by using the SCTP PPID.
identifier (PPID). Therefore, a DCEP message <bcp14>MUST</bcp14> be sent with the
Therefore, a DCEP message MUST be sent with the
assigned PPID for the Data Channel Establishment Protocol assigned PPID for the Data Channel Establishment Protocol
(see <xref target='iana_ppid'/>). (see <xref target="iana_ppid" format="default"/>).
Other messages MUST NOT be sent using this PPID.</t> Other messages <bcp14>MUST NOT</bcp14> be sent using this PPID.</t>
<t>The peer that initiates opening a data channel selects a stream identifier <t>The peer that initiates opening a data channel selects a stream identif
for which the corresponding incoming and outgoing Streams are unused. ier
If the side is the DTLS client, it MUST choose an even stream identifier; for which the corresponding incoming and outgoing streams are unused.
if the side is the DTLS server, it MUST choose an odd one. The initiating peer If the side is acting as the DTLS client, it <bcp14>MUST</bcp14> choose an even
stream identifier;
if the side is acting as the DTLS server, it <bcp14>MUST</bcp14> choose an odd o
ne. The initiating peer
fills in the parameters of the DATA_CHANNEL_OPEN message and sends it on fills in the parameters of the DATA_CHANNEL_OPEN message and sends it on
the chosen Stream.</t> the chosen stream.</t>
<t>If a DATA_CHANNEL_OPEN message is received on an unused Stream, <t>If a DATA_CHANNEL_OPEN message is received on an unused stream,
the stream identifier corresponds to the role of the peer, and the stream identifier corresponds to the role of the peer, and
all parameters in the DATA_CHANNEL_OPEN message are valid, all parameters in the DATA_CHANNEL_OPEN message are valid,
then a corresponding DATA_CHANNEL_ACK message is sent on the Stream with the then a corresponding DATA_CHANNEL_ACK message is sent on the stream with the
same stream identifier as the one the DATA_CHANNEL_OPEN message was same stream identifier as the one the DATA_CHANNEL_OPEN message was
received on.</t> received on.</t>
<t>If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions above, the <t>If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions above,
receiver MUST close the corresponding data channel using the procedure the
described in <xref target='RFCYYYY'/> and MUST NOT send a DATA_CHANNEL_ACK receiver <bcp14>MUST</bcp14> close the corresponding data channel using the proc
edure
described in <xref target="RFC8831" format="default"/> and <bcp14>MUST NOT</bcp1
4> send a DATA_CHANNEL_ACK
message in response to the received message. This might occur if, for example, message in response to the received message. This might occur if, for example,
a DATA_CHANNEL_OPEN message is received on an already used Stream, there are a DATA_CHANNEL_OPEN message is received on an already used stream, there are
problems with parameters within the DATA_CHANNEL_OPEN problems with parameters within the DATA_CHANNEL_OPEN
message, the odd/even rule is violated, or the DATA_CHANNEL_OPEN message itself message, the odd/even rule is violated, or the DATA_CHANNEL_OPEN message itself
is not well formed. Therefore, receiving an SCTP Stream-reset request for a Stre am on which is not well formed. Therefore, receiving an SCTP stream-reset request for a stre am on which
no DATA_CHANNEL_ACK message has been received indicates to the sender of the no DATA_CHANNEL_ACK message has been received indicates to the sender of the
corresponding DATA_CHANNEL_OPEN message the failure of the data channel corresponding DATA_CHANNEL_OPEN message the failure of the data channel
setup procedure. After also successfully resetting the corresponding outgoing setup procedure. After also successfully resetting the corresponding outgoing
Stream, which concludes the data channel closing initiated by the peer, stream, which concludes the data channel closing initiated by the peer,
a new DATA_CHANNEL_OPEN message can be sent on the Stream.</t> a new DATA_CHANNEL_OPEN message can be sent on the stream.</t>
<t>After the DATA_CHANNEL_OPEN message has been sent, the sender of that m
<t>After the DATA_CHANNEL_OPEN message has been sent, the sender of that message essage
MAY start sending messages containing user data without <bcp14>MAY</bcp14> start sending messages containing user data without
waiting for the reception of the corresponding DATA_CHANNEL_ACK message. waiting for the reception of the corresponding DATA_CHANNEL_ACK message.
However, before the DATA_CHANNEL_ACK message or any other message has been However, before the DATA_CHANNEL_ACK message or any other message has been
received on a data channel, all other messages containing user data and received on a data channel, all other messages containing user data and
belonging to this data channel MUST be sent ordered, no matter whether the belonging to this data channel <bcp14>MUST</bcp14> be sent ordered, no matter
data channel is ordered or not. whether the data channel is ordered or not.
After the DATA_CHANNEL_ACK or any other message has been received on the After the DATA_CHANNEL_ACK or any other message has been received on the
data channel, messages containing user data MUST be sent ordered on ordered data channel, messages containing user data <bcp14>MUST</bcp14> be sent ordered
data channels and MUST be sent unordered on unordered data channels. on ordered
Therefore, receiving a message containing user data on an unused Stream data channels and <bcp14>MUST</bcp14> be sent unordered on unordered data channe
indicates an error. In that case, the corresponding data channel MUST be closed, ls.
as described Therefore, receiving a message containing user data on an unused stream
in <xref target='RFCYYYY'/>.</t> indicates an error. In that case, the corresponding data channel <bcp14>MUST</bc
</section> p14> be closed, as described
in <xref target="RFC8831" format="default"/>.</t>
<section title='Security Considerations' </section>
anchor='sec-security'> <section anchor="sec-security" numbered="true" toc="default">
<t>The DATA_CHANNEL_OPEN message contains two variable-length fields: <name>Security Considerations</name>
<t>The DATA_CHANNEL_OPEN message contains two variable-length fields:
the protocol and the label. A receiver must be prepared to receive the protocol and the label. A receiver must be prepared to receive
DATA_CHANNEL_OPEN messages where these field have the maximum length of DATA_CHANNEL_OPEN messages where these fields have the maximum length of
65535 bytes. Error cases such as using inconsistent lengths of fields, 65535 bytes. Error cases such as using inconsistent lengths of fields,
using unknown parameter values, or violating the odd/even rule must also be hand led using unknown parameter values, or violating the odd/even rule must also be hand led
by closing the corresponding data channel. An end point must also be prepared by closing the corresponding data channel. An end point must also be prepared
for the peer to open the maximum number of data channels.</t> for the peer to open the maximum number of data channels.</t>
<t>This protocol does not provide privacy, integrity, or authentication. <t>This protocol does not provide privacy, integrity, or authentication.
It needs to be used as part of a protocol suite that contains all these things. It needs to be used as part of a protocol suite that contains all these things.
Such a protocol suite is specified in Such a protocol suite is specified in
<xref target='RFC8261'/>.</t> <xref target="RFC8261" format="default"/>.</t>
<t>For general considerations, see <xref target='SECURITY'/> and <t>For general considerations, see <xref target="RFC8826" format="default"
<xref target='SECURITY-ARCH'/>.</t> /> and
</section> <xref target="RFC8827" format="default"/>.</t>
</section>
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<t>IANA has updated the reference of an already existing SCTP PPID
assignment (<xref target="iana_ppid" format="default"/>) and created a new
standalone registry with its own URL for DCEP (<xref
target="iana_dcep_registry" format="default"/>) containing two new
registration tables (Sections <xref format="counter" target="iana_msg_type"/>
and <xref format="counter" target="iana_channel_type"/>).</t>
<section title='IANA Considerations'> <section anchor="iana_ppid" numbered="true" toc="default">
<t>IANA is asked to update the reference of an already existing SCTP PPID <name>SCTP Payload Protocol Identifier</name>
assignment (<xref target='iana_ppid'/>) and create a new standalone registry <t>This document uses an SCTP Payload Protocol
with its own URL for the DCEP (<xref target='iana_dcep_registry'/>) containing Identifier (PPID) previously registered as "WebRTC Control".
two new registration tables (Sections <xref format="counter" target='iana_msg_ty
pe'/> and
<xref format="counter" target='iana_channel_type'/>).</t>
<section title='SCTP Payload Protocol Identifier' <xref target="RFC4960" format="default"/> creates the
anchor='iana_ppid'> "SCTP Payload Protocol Identifiers" registry, in which this identifier was assig
<t>This document uses one already registered SCTP Payload Protocol ned.
Identifier (PPID) named "WebRTC Control". IANA has updated the PPID name from "WebRTC Control" to "WebRTC DCEP" and has
<xref target='RFC4960'/> creates the registry updated the reference to point to this document. The corresponding date has been
"SCTP Payload Protocol Identifiers", from which this identifier was assigned.
IANA is requested to update name of the registry and update the reference of
this assignment to point to this document. The corresponding date should be
kept.</t> kept.</t>
<t>Therefore, this assignment should be updated to read:</t> <t>Therefore, this assignment now appears as follows:</t>
<texttable> <table align="center">
<ttcol align='left'>Value</ttcol> <thead>
<ttcol align='left'>SCTP PPID</ttcol> <tr>
<ttcol align='left'>Reference</ttcol> <th align="left">Value</th>
<ttcol align='left'>Date</ttcol> <th align="left">SCTP PPID</th>
<c>WebRTC DCEP</c> <c>50</c> <c>[RFCXXXX]</c> <c>2013-09-20</c> <th align="left">Reference</th>
</texttable> <th align="left">Date</th>
</section> </tr>
</thead>
<section title='New Standalone Registry for the DCEP' <tbody>
anchor='iana_dcep_registry'> <tr>
<t>IANA is requested to create a new standalone registry (a.k.a. webpage) with <td align="left">WebRTC DCEP</td>
its own URL for the Data Channel Establishment Protocol (DCEP). <td align="left">50</td>
The title should be "Data Channel Establishment Protocol (DCEP) Parameters". <td align="left">RFC 8832</td>
It will contain the two tables provided in Sections <xref format="counter" targe <td align="left">2013-09-20</td>
t='iana_msg_type'/> </tr>
and <xref format="counter" target='iana_channel_type'/>.</t> </tbody>
</table>
</section>
<section title='New Message Type Registry' <section anchor="iana_dcep_registry" numbered="true" toc="default">
anchor ='iana_msg_type'> <name>New Standalone Registry for DCEP</name>
<t>IANA is requested to create a new registration table, "Message Type Registry" <t>IANA has created the "Data Channel Establishment Protocol (DCEP)
, Parameters" registry. It contains the two tables provided in Sections
for the Data Channel Establishment Protocol (DCEP) to manage the one-byte <xref format="counter" target="iana_msg_type"/>
"Message Type" field in DCEP messages (see <xref target='msg_format'/>). and <xref format="counter" target="iana_channel_type"/>.</t>
This registration table should be part of the registry described in
<xref target='iana_dcep_registry'/>.</t>
<!-- [rfced] The following RFC has been obsoleted. We have updated this
reference as follows. Please let us know any objections.
Original: <section anchor="iana_msg_type" numbered="true" toc="default">
The assignment of new message types is done through an RFC Required <name>New Message Type Registry</name>
action, as defined in [RFC5226].
New: <t>IANA has created the "Message Types" registry for DCEP to manage
The assignment of new message types is done through an RFC Required the one-byte "Message Type" field in DCEP messages (see <xref
action, as defined in [RFC8126]. target="msg_format" format="default"/>). This registration table
<t>The assignment of new message types is done through an RFC Required action, is a subregistry of the registry described in <xref
as defined in <xref target='RFC8126'/>. target="iana_dcep_registry" format="default"/>.</t>
Documentation of the new message type MUST contain the following information:
<list style="numbers">
<t>A name for the new message type;</t>
<t>A detailed procedural description of the use of messages with the new type
within the operation of the Data Channel Establishment Protocol.</t>
</list></t>
<t>Initially, the following values need to be registered:</t>
<texttable>
<ttcol align='left'>Name</ttcol>
<ttcol align='left'>Type</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>Reserved</c> <c>0x00 </c> <c>[RFCXXXX]</c>
<c>Reserved</c> <c>0x01 </c> <c>[RFCXXXX]</c>
<c>DATA_CHANNEL_ACK</c> <c>0x02 </c> <c>[RFCXXXX]</c>
<c>DATA_CHANNEL_OPEN</c> <c>0x03 </c> <c>[RFCXXXX]</c>
<c>Unassigned</c> <c>0x04-0xfe</c> <c> </c>
<c>Reserved</c> <c>0xff </c> <c>[RFCXXXX]</c>
</texttable>
<!--[rfced] In the following sentence, does "the document" refer to this <t>The assignment of new message types is done through an RFC Required
document? action,
as defined in <xref target="RFC8126" format="default"/>.
Documentation of new message types <bcp14>MUST</bcp14> contain the following inf
ormation:
</t>
<ol spacing="normal" type="1">
<li>A name for the new message type.</li>
Original: <li>A detailed procedural description of how each message type is us
Please note that the values 0x00 and 0x01 are reserved to avoid ed with
interoperability problems, since they have been used in earlier within DCEP.</li>
versions of the document. </ol>
<t>The following are the inital registrations:</t>
<table align="center">
<thead>
<tr>
<th align="left">Name</th>
<th align="left">Type</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">Reserved</td>
<td align="left">0x00 </td>
<td align="left">RFC 8832</td>
</tr>
<tr>
<td align="left">Reserved</td>
<td align="left">0x01 </td>
<td align="left">RFC 8832</td>
</tr>
<tr>
<td align="left">DATA_CHANNEL_ACK</td>
<td align="left">0x02 </td>
<td align="left">RFC 8832</td>
</tr>
<tr>
<td align="left">DATA_CHANNEL_OPEN</td>
<td align="left">0x03 </td>
<td align="left">RFC 8832</td>
</tr>
<tr>
<td align="left">Unassigned</td>
<td align="left">0x04-0xfe</td>
<td align="left"> </td>
</tr>
<tr>
<td align="left">Reserved</td>
<td align="left">0xff </td>
<td align="left">RFC 8832</td>
</tr>
</tbody>
</table>
Perhaps: <t>Note that values 0x00 and 0x01 are reserved to avoid
Please note that the values 0x00 and 0x01 are reserved to avoid interoperability problems, since they have been used in draft versions
interoperability problems, since they have been used in draft
versions of this document.
<t>Please note that the values 0x00 and 0x01 are reserved to avoid
interoperability problems, since they have been used in earlier versions
of the document. of the document.
The value 0xff has been reserved for future extensibility. The value 0xff has been reserved for future extensibility.
The range of possible values is from 0x00 to 0xff.</t> The range of possible values is from 0x00 to 0xff.</t>
</section> </section>
<section title='New Channel Type Registry' <section anchor="iana_channel_type" numbered="true" toc="default">
anchor='iana_channel_type'> <name>New Channel Type Registry</name>
<t>IANA is requested to create a new registration table, "Channel Type Registry" <t>IANA has created the "Channel Types" registry
, for DCEP to manage the one-byte
for the Data Channel Establishment Protocol to manage the one-byte
"Channel Type" field in DATA_CHANNEL_OPEN messages "Channel Type" field in DATA_CHANNEL_OPEN messages
(see <xref target='open_msg_format'/>). (see <xref target="open_msg_format" format="default"/>).
This registration table should be part of the registry described in This registration table is a subregistry within the registry described in
<xref target='iana_dcep_registry'/>.</t> <xref target="iana_dcep_registry" format="default"/>.</t>
<t>The assignment of new message types is done through an RFC Required action, <t>The assignment of new message types is done through an RFC Required
as defined in <xref target='RFC8126'/>. action,
Documentation of the new Channel Type MUST contain the following information: as defined in <xref target="RFC8126" format="default"/>.
<list style="numbers"> Documentation of new Channel Types <bcp14>MUST</bcp14> contain the following inf
<t>A name for the new Channel Type;</t> ormation:
<t>A detailed procedural description of the user message handling for </t>
data channels using this new Channel Type.</t> <ol spacing="normal" type="1">
</list> <li>A name for the new Channel Type.</li>
Please note that if new Channel Types support ordered and unordered message <li>A detailed procedural description of the user message handling f
delivery, the high-order bit MUST be used to indicate whether the message or
delivery is unordered or not.</t> data channels using this new Channel Type.</li>
<t>Initially, the following values need to be registered:</t> </ol>
<texttable> <t>
<ttcol align='left'>Name</ttcol> If new Channel Types support ordered and unordered message
<ttcol align='left'>Type</ttcol> delivery, the high-order bit <bcp14>MUST</bcp14> be used to indicate whether
<ttcol align='left'>Reference</ttcol> or not the message delivery is unordered.</t>
<c>DATA_CHANNEL_RELIABLE</c> <c>0x00</c> <c>[RFCXXXX]</ <t>The following are the initial registrations:</t>
c> <table align="center">
<c>DATA_CHANNEL_RELIABLE_UNORDERED</c> <c>0x80</c> <c>[RFCXXXX]</ <thead>
c> <tr>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT</c> <c>0x01</c> <c>[RFCXXXX]</ <th align="left">Name</th>
c> <th align="left">Type</th>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED</c> <c>0x81</c> <c>[RFCXXXX]</ <th align="left">Reference</th>
c> </tr>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED</c> <c>0x02</c> <c>[RFCXXXX]</ </thead>
c> <tbody>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED</c> <c>0x82</c> <c>[RFCXXXX]</ <tr>
c> <td align="left">DATA_CHANNEL_RELIABLE</td>
<c>Reserved</c> <c>0x7f</c> <c>[RFCXXXX]</ <td align="left">0x00</td>
c> <td align="left">RFC 8832</td>
<c>Reserved</c> <c>0xff</c> <c>[RFCXXXX]</ </tr>
c> <tr>
<c>Unassigned</c> <c>rest</c> <c> </ <td align="left">DATA_CHANNEL_RELIABLE_UNORDERED</td>
c> <td align="left">0x80</td>
</texttable> <td align="left">RFC 8832</td>
<t>Please note that the values 0x7f and 0xff have been reserved for future </tr>
<tr>
<td align="left">DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT</td>
<td align="left">0x01</td>
<td align="left">RFC 8832</td>
</tr>
<tr>
<td align="left">DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED<
/td>
<td align="left">0x81</td>
<td align="left">RFC 8832</td>
</tr>
<tr>
<td align="left">DATA_CHANNEL_PARTIAL_RELIABLE_TIMED</td>
<td align="left">0x02</td>
<td align="left">RFC 8832</td>
</tr>
<tr>
<td align="left">DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED</
td>
<td align="left">0x82</td>
<td align="left">RFC 8832</td>
</tr>
<tr>
<td align="left">Reserved</td>
<td align="left">0x7f</td>
<td align="left">RFC 8832</td>
</tr>
<tr>
<td align="left">Reserved</td>
<td align="left">0xff</td>
<td align="left">RFC 8832</td>
</tr>
<tr>
<td align="left">Unassigned</td>
<td align="left">rest</td>
<td align="left"> </td>
</tr>
</tbody>
</table>
<t>Values 0x7f and 0xff have been reserved for future
extensibility. extensibility.
The range of possible values is from 0x00 to 0xff.</t> The range of possible values is from 0x00 to 0xff.</t>
</section> </section>
</section> </section>
</section> </section>
</middle>
</middle> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<back> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<references title='Normative References'> xml"/>
<?rfc include='reference.RFC.2119'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
<?rfc include='reference.RFC.8174'?> xml"/>
<?rfc include='reference.RFC.3629'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3629.
<?rfc include='reference.RFC.4347'?> xml"/>
<?rfc include='reference.RFC.4960'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4347.
<?rfc include='reference.RFC.8126'?> xml"/>
<?rfc include='reference.RFC.6347'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.
<?rfc include='reference.RFC.8261'?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8261.
xml"/>
<reference anchor="RFCYYYY" target="https://www.rfc-editor.org/info/rfcYYYY"> <!-- draft-ietf-rtcweb-data-channel (RFC 8831) -->
<reference anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8831">
<front> <front>
<title>WebRTC Data Channels</title> <title>WebRTC Data Channels</title>
<author initials='R' surname='Jesup' fullname='Randell Jesup'> <author initials="R." surname="Jesup" fullname="Randell Jesup">
<organization/> <organization/>
</author> </author>
<author initials='S' surname='Loreto' fullname='Salvatore Loreto'> <author initials="S." surname="Loreto" fullname="Salvatore Loreto">
<organization/> <organization/>
</author> </author>
<author initials='M' surname='Tuexen' fullname='Michael Tuexen'> <author initials="M." surname="Tüxen" fullname="Michael Tüxen">
<organization/> <organization/>
</author> </author>
<date month='October' year='2018'/> <date month='October' year='2020'/>
</front>
<seriesInfo name="RFC" value="YYYY"/>
<seriesInfo name="DOI" value="10.17487/RFCYYYY"/>
</reference>
</references>
<references title='Informative References'>
<?rfc include='reference.RFC.6455'?>
<!-- draft-ietf-rtcweb-security-10 exists -->
<reference anchor='SECURITY'>
<front>
<title>Security Considerations for WebRTC</title>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization />
</author>
<date month='January' day='22' year='2018' />
</front> </front>
<seriesInfo name="RFC" value="8831"/>
<seriesInfo name='Work in Progress,' value='draft-ietf-rtcweb-security-10' /> <seriesInfo name="DOI" value="10.17487/RFC8831"/>
</reference> </reference>
<!-- draft-ietf-rtcweb-security-arch-15 exists --> </references>
<reference anchor='SECURITY-ARCH'>
<front>
<title>WebRTC Security Architecture</title>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization />
</author>
<date month='July' day='17' year='2018' /> <references>
<name>Informative References</name>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6455. xml"/>
<seriesInfo name='Work in Progress,' value='draft-ietf-rtcweb-security-arch-15' <!--draft-ietf-rtcweb-security: RFC 8826 -->
/> <reference anchor="RFC8826" target="https://www.rfc-editor.org/info/rfc8826">
<front>
<title>Security Considerations for WebRTC</title>
<author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
<organization/>
</author>
<date month='October' year='2020'/>
</front>
<seriesInfo name="RFC" value="8826"/>
<seriesInfo name="DOI" value="10.17487/RFC8826"/>
</reference>
</reference> <!--draft-ietf-rtcweb-security-arch: 8827 -->
<reference anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8827">
<front>
<title>WebRTC Security Architecture</title>
<author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
<organization/>
</author>
<date month='October' year='2020'/>
</front>
<seriesInfo name="RFC" value="8827"/>
<seriesInfo name="DOI" value="10.17487/RFC8827"/>
</reference>
</references> </references>
<section title='Acknowledgments' numbered="no"> </references>
<t>The authors wish to thank <section numbered="false" toc="default">
Harald Alvestrand, <name>Acknowledgements</name>
Richard Barnes, <t>The authors wish to thank
Adam Bergkvist, <contact fullname="Harald Alvestrand"/>,
Spencer Dawkins, <contact fullname="Richard Barnes"/>,
Barry Dingle, <contact fullname="Adam Bergkvist"/>,
Stefan Haekansson, <contact fullname="Spencer Dawkins"/>,
Cullen Jennings, <contact fullname="Barry Dingle"/>,
Paul Kyzivat, <contact fullname="Stefan Haekansson"/>,
Doug Leonard, <contact fullname="Cullen Jennings"/>,
Alexey Melnikov, <contact fullname="Paul Kyzivat"/>,
Pete Resnick, <contact fullname="Doug Leonard"/>,
Irene Ruengeler, <contact fullname="Alexey Melnikov"/>,
Randall Stewart, <contact fullname="Pete Resnick"/>,
Peter Thatcher, <contact fullname="Irene Rüngeler"/>,
Martin Thompson, <contact fullname="Randall Stewart"/>,
Justin Uberti, <contact fullname="Peter Thatcher"/>,
<contact fullname="Martin Thompson"/>,
<contact fullname="Justin Uberti"/>,
and many others for their invaluable comments.</t> and many others for their invaluable comments.</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 82 change blocks. 
502 lines changed or deleted 611 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/