<?xml version='1.0' encoding="US-ASCII"?>

<?rfc symrefs='yes'?> encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc toc='yes' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='no' ?>
<?rfc sortrefs='no' ?>
<?rfc strict='yes' ?> "rfc2629-xhtml.ent">

<rfc category='std'
     ipr='trust200902'
     number="XXXX" xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
     ipr="trust200902" number="8832" submissionType="IETF"
     consensus="yes"
> consensus="true"
     obsoletes="" updates="" xml:lang="en" symRefs="true" tocInclude="true"
     sortRefs="false" version="3" docName="draft-ietf-rtcweb-data-protocol-09">

  <!-- xml2rfc v2v3 conversion 2.30.0 -->
  <front>
    <title>WebRTC Data Channel Establishment Protocol</title>
    <seriesInfo name="RFC" value="8832"/>
    <author initials='R.' surname='Jesup' fullname='Randell Jesup'> initials="R." surname="Jesup" fullname="Randell Jesup">
      <organization>Mozilla</organization>
      <address>
        <postal>
      <street></street>
      <code></code>
      <city></city>
          <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'> 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'> initials="M." surname="Tüxen" fullname="Michael Tüxen">
      <organization abbrev='Muenster abbrev="Münster Univ. of Appl. Sciences'>
                Muenster 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>

    <date month="October" year="2018" />
<area>RAI</area>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->

<keyword>example</keyword> year="2020"/>
    <area>ART</area>

    <abstract>
      <t>The WebRTC framework specifies protocol support for direct interactive
rich communication using audio, video, and data between two peers' web browsers.
This document specifies a simple protocol for establishing symmetric
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>
    </abstract>
  </front>
  <middle>
    <section title='Introduction'> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Data Channel Establishment Protocol (DCEP) is designed to provide, in the
WebRTC data channel context <xref target='RFCYYYY'/>, target="RFC8831" format="default"/>,
a simple in-band method for opening symmetric data channels.
As discussed in <xref target='RFCYYYY'/>, target="RFC8831" format="default"/>, the protocol uses
the Stream Control Transmission Protocol (SCTP) <xref target='RFC4960'/> target="RFC4960" format="default"/>
encapsulated in the Datagram Transport Layer Security (DTLS) (described in
<xref target='RFC8261'/>). target="RFC8261" format="default"/>). This allows the DCEP to benefit from the
already standardized transport
and security features of SCTP and DTLS. DTLS 1.0 is defined in <xref target='RFC4347'/>, target="RFC4347" format="default"/>, and the
present latest version, DTLS 1.2, is defined in <xref target='RFC6347'/>. target="RFC6347" format="default"/>.
</t>
    </section>
    <section title='Conventions'> numbered="true" toc="default">
      <name>Conventions</name>
      <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
    "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 BCP?14 <xref target="RFC2119"/> target="RFC2119" format="default"/> <xref target="RFC8174"/> target="RFC8174" format="default"/>
    when, and only when, they appear in all capitals, as shown here.
      </t>
    </section>
    <section title='Terminology'> numbered="true" toc="default">
      <name>Terminology</name>
      <t>This document uses the following terms:
<list style='hanging'>
<t hangText='Association:'>
An
</t>

      <dl newline="false" spacing="normal">
        <dt>Association:</dt>
        <dd>An SCTP association.</t>
<t hangText='Stream:'> association.</dd>
        <dt>Stream:</dt>
        <dd>
A unidirectional stream of an SCTP association. It is uniquely identified
by an SCTP stream identifier (0-65534).
Note: The SCTP stream identifier 65535 is reserved due to SCTP INIT and
INIT-ACK chunks only allowing a maximum of 65535 Streams streams to be
negotiated (0-65534).</t>
<t hangText='stream identifier:'> (0-65534).</dd>
        <dt>Stream Identifier:</dt>
        <dd>
The SCTP stream identifier uniquely identifying a Stream.</t>
<t hangText='Data Channel:'> stream.</dd>
        <dt>Data Channel:</dt>
        <dd>
Two Streams streams with the same stream identifier, one in each direction,
which are managed together.</t>
</list></t> together.</dd>
      </dl>

    </section>
    <section title='Protocol Overview'> 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
consistent set of properties.</t>
      <t>The set of consistent properties includes:
<list style='symbols'>
<t>reliable
</t>
      <ul spacing="normal">
        <li>reliable or unreliable message transmission. In case of unreliable
   transmissions, the same level of unreliability is used.</t>
<t>in-order used.</li>
        <li>in-order or out-of-order message delivery.</t>
<t>the delivery.</li>
        <li>the priority of the data channel.</t>
<t>an channel.</li>
        <li>an optional label for the data channel.</t>
<t>an channel.</li>
        <li>an optional protocol for the data channel.</t>
<t>the Streams.</t>
</list></t> channel.</li>
        <li>the streams.</li>
      </ul>
      <t>This protocol uses a two-way handshake to open a data channel.
The handshake pairs one incoming and one outgoing Stream, stream, both having the
same stream identifier, into a single bidirectional data channel.
The peer that initiates opening a data channel selects a Stream
Identifier stream
identifier for which the corresponding incoming and outgoing Streams streams
are unused and sends a DATA_CHANNEL_OPEN message on the outgoing Stream. stream.
The peer responds with a DATA_CHANNEL_ACK message on its corresponding
outgoing Stream. stream. Then the data channel is open.
DCEP messages are sent on the same Stream stream as
the user messages belonging to the data channel.
The demultiplexing is based on the SCTP payload protocol identifier Payload Protocol Identifier (PPID),
since the Data Channel Establishment Protocol DCEP uses a specific PPID.</t>
<t>Note:
      <aside><t>Note: The opening side MAY <bcp14>MAY</bcp14> send user messages before the DATA_CHANNEL_ACK
is received.</t> received.</t></aside>
      <t>To avoid collisions where both sides try to open a data channel with
the same stream identifiers, each side MUST <bcp14>MUST</bcp14> use Streams streams with either even or
odd stream identifiers when sending a DATA_CHANNEL_OPEN message.
When using SCTP over DTLS <xref target='RFC8261'/>, target="RFC8261" format="default"/>,
the method used to determine which side uses odd or even is based on the
underlying DTLS connection role:
the side acting as the DTLS client MUST <bcp14>MUST</bcp14> use Streams streams with even
stream identifiers; the side acting as the DTLS server MUST <bcp14>MUST</bcp14> use Streams streams
with odd stream identifiers.</t>
<t>Note:
      <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
two data channels labeled "x" -- one on an even Stream stream pair, one on an odd pair.</t>
<!--[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:
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 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.
--> pair.</t></aside>

      <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
from the "WebSocket Subprotocol Name Registry" defined in <xref target='RFC6455'/>. target="RFC6455" format="default"/>.
The field may be useful for homogeneous applications that may create more than one
type of data channel.
Please note
Note that there is no attempt to ensure uniqueness for the protocol
field.</t>
    </section>
    <section title='Message Formats'
         anchor='msg_format'> anchor="msg_format" numbered="true" toc="default">
      <name>Message Formats</name>
      <t>Every DCEP message starts with a one-byte
field called "Message Type" that indicates the type of the message.
The corresponding values are managed by IANA
(see <xref target='iana_msg_type'/>).</t> target="iana_msg_type" format="default"/>).</t>
      <section title='DATA_CHANNEL_OPEN Message'
         anchor='open_msg_format'> anchor="open_msg_format" numbered="true" toc="default">
        <name>DATA_CHANNEL_OPEN Message</name>
        <t>This message is initially sent using the data channel on the Stream stream used
for user messages.</t>
<figure>
        <artwork align='center'> align="center" name="" type="" alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Message Type |  Channel Type |            Priority           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Reliability Parameter                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Label Length          |       Protocol Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               /
|                             Label                             |
/                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               /
|                            Protocol                           |
/                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style='hanging'>
<t hangText='Message
]]></artwork>
        <dl newline="true" spacing="normal">
          <dt>Message Type: 1 byte (unsigned integer)'>
<vspace blankLines='0'/> integer)</dt><dd>
<!-- [MT] Changed the formatting to have the type on the same line as the name -->
          <t>
This field holds the IANA-defined message type for the DATA_CHANNEL_OPEN
message. The value of this field is 0x03, as specified in
<xref target='iana_msg_type'/>.</t>
<t hangText='Channel target="iana_msg_type" format="default"/>.</t></dd>
          <dt>Channel Type: 1 byte (unsigned integer)'>
<vspace blankLines='0'/> integer)</dt><dd>
<!-- [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
values are managed by IANA (see <xref target='iana_channel_type'/>):
<list style='hanging'>
<t hangText='DATA_CHANNEL_RELIABLE (0x00):'> target="iana_channel_type" format="default"/>):
</t>
            <dl newline="false" spacing="normal">
              <dt>DATA_CHANNEL_RELIABLE (0x00):</dt>
              <dd>
The data channel provides a reliable in-order bidirectional communication.</t>
<t hangText='DATA_CHANNEL_RELIABLE_UNORDERED (0x80):'> communication.</dd>
              <dt>DATA_CHANNEL_RELIABLE_UNORDERED (0x80):</dt>
              <dd>
The data channel provides a reliable unordered bidirectional communication.</t>

<!--[rfced] The rest of this document refers to "partial reliable"
communication, but the following sentence uses "partially
reliable". Please let us know which wording, if any, should be changed.

ORIGINAL:
The Data Channel provides a partially reliable in-order bidirectional
communication.
-->
<t hangText='DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01):'> communication.</dd>

              <dt>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01):</dt>
              <dd>
The data channel provides a partially reliable in-order bidirectional
communication. User messages will not be retransmitted more times
than specified in the Reliability Parameter.</t>
<t hangText='DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81):'> Parameter.</dd>
              <dt>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81):</dt>
              <dd>
The data channel provides a partial partially reliable unordered bidirectional
communication. User messages will not be retransmitted more times
than specified in the Reliability Parameter.</t>
<t hangText='DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02):'> Parameter.</dd>
              <dt>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02):</dt>
              <dd>
The data channel provides a partial partially reliable in-order bidirectional
communication. User messages might not be transmitted or
retransmitted after a specified lifetime given in milliseconds in the
Reliability Parameter. This lifetime starts when providing the user
message to the protocol stack.</t>
<t hangText='DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82):'> stack.</dd>
              <dt>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82):</dt>
              <dd>
The data channel provides a partial partially reliable unordered bidirectional
communication. User messages might not be transmitted or
retransmitted after a specified lifetime given in milliseconds in the
Reliability Parameter. This lifetime starts when providing the user
message to the protocol stack.</t>
</list></t>
<t hangText='Priority: stack.</dd>
            </dl>
          </dd>
          <dt>Priority: 2 bytes (unsigned integer)'>
<vspace blankLines='0'/> 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
<xref target='RFCYYYY'/>.</t>
<t hangText='Reliability target="RFC8831" format="default"/>.</t></dd>
          <dt>Reliability Parameter: 4 bytes (unsigned integer)'>
<vspace blankLines='0'/> integer)</dt><dd>
<!-- [MT] Changed the formatting to have the type on the same line as the name -->
          <t>
For reliable data channels, this field MUST <bcp14>MUST</bcp14> be set to 0 on the sending side
and MUST <bcp14>MUST</bcp14> be ignored on the receiving side.
If a partial partially reliable data channel with a limited number of retransmissions is
used, this field specifies the number of retransmissions. If a partial partially
reliable data channel with a limited lifetime is used, this field specifies
the maximum lifetime in milliseconds. The following table summarizes this:</t>
</list></t>
<texttable>
<ttcol align='left'>Channel Type</ttcol>
<ttcol align='center'>Reliability Parameter</ttcol>
<c>DATA_CHANNEL_RELIABLE</c>                         <c>Ignored</c>
<c>DATA_CHANNEL_RELIABLE_UNORDERED</c>               <c>Ignored</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT</c>          <c>Number of RTX</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED</c><c>Number of RTX</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED</c>           <c>Lifetime in ms</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED</c> <c>Lifetime in ms</c>
</texttable>
<t><list style='hanging'>
<t hangText='Label this:</t></dd>
        </dl>
        <table align="center">
          <thead>
            <tr>
              <th align="left">Channel Type</th>
              <th align="center">Reliability Parameter</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">DATA_CHANNEL_RELIABLE</td>
              <td align="center">Ignored</td>
            </tr>
            <tr>
              <td align="left">DATA_CHANNEL_RELIABLE_UNORDERED</td>
              <td align="center">Ignored</td>
            </tr>
            <tr>
              <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</td>
              <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)'>
<vspace blankLines='0'/> 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>
<t hangText='Protocol bytes.</t></dd>
          <dt>Protocol Length: 2 bytes (unsigned integer)'>
<vspace blankLines='0'/> 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>
<t hangText='Label: bytes.</t></dd>
          <dt>Label: Variable Length (sequence of characters)'>
<vspace blankLines='0'/>
The name of characters)</dt><dd>
<!-- [MT] Changed the data channel 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
<xref target='RFC3629'/>. target="RFC3629" format="default"/>. This may be an empty string.</t>
<t hangText='Protocol: string.</t></dd>
          <dt>Protocol: Variable Length (sequence of characters)'>
<vspace blankLines='0'/> characters)</dt><dd>
<!-- [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 it is a non-empty string, it specifies a protocol registered in the
"WebSocket Subprotocol Name Registry" created in
<xref target='RFC6455'/>. target="RFC6455" format="default"/>. This string is UTF-8 encoded, as specified in
<xref target='RFC3629'/>.</t>
</list></t> target="RFC3629" format="default"/>.</t></dd>
        </dl>
      </section>
      <section title='DATA_CHANNEL_ACK Message'> numbered="true" toc="default">
        <name>DATA_CHANNEL_ACK Message</name>
        <t>This message is sent in response to a
DATA_CHANNEL_OPEN_RESPONSE message. It is sent on the Stream stream used for user
messages using the data channel.
Reception of this message tells the opener that the data channel setup
handshake is complete.</t>
<figure>
        <artwork align='center'> align="center" name="" type="" alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Message Type |
+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style='hanging'>
<t hangText='Message
]]></artwork>
        <dl newline="true" spacing="normal">
          <dt>Message Type: 1 byte (unsigned integer)'>
<vspace blankLines='0'/> integer)</dt><dd>
<!-- [MT] Changed the formatting to have the type on the same line as the name -->
          <t>
This field holds the IANA-defined message type for the DATA_CHANNEL_ACK
message. The value of this field is 0x02, as specified in
<xref target='iana_msg_type'/>.</t>
</list></t> target="iana_msg_type" format="default"/>.</t></dd>
        </dl>
      </section>
    </section>
    <section title='Procedures'> numbered="true" toc="default">
      <name>Procedures</name>
      <t>All DCEP messages MUST <bcp14>MUST</bcp14> be sent using ordered delivery and reliable
transmission. They MUST <bcp14>MUST</bcp14> be sent on the same outgoing Stream stream as the user messages
belonging to the corresponding data channel.
Multiplexing and demultiplexing is done by using the SCTP payload protocol
identifier (PPID). PPID.
Therefore, a DCEP message MUST <bcp14>MUST</bcp14> be sent with the
assigned PPID for the Data Channel Establishment Protocol
(see <xref target='iana_ppid'/>). target="iana_ppid" format="default"/>).
Other messages MUST NOT <bcp14>MUST NOT</bcp14> be sent using this PPID.</t>
      <t>The peer that initiates opening a data channel selects a stream identifier
for which the corresponding incoming and outgoing Streams streams are unused.
If the side is acting as the DTLS client, it MUST <bcp14>MUST</bcp14> choose an even stream identifier;
if the side is acting as the DTLS server, it MUST <bcp14>MUST</bcp14> choose an odd one. The initiating peer
fills in the parameters of the DATA_CHANNEL_OPEN message and sends it on
the chosen Stream.</t> stream.</t>
      <t>If a DATA_CHANNEL_OPEN message is received on an unused Stream, stream,
the stream identifier corresponds to the role of the peer, and
all parameters in the DATA_CHANNEL_OPEN message are valid,
then a corresponding DATA_CHANNEL_ACK message is sent on the Stream stream with the
same stream identifier as the one the DATA_CHANNEL_OPEN message was
received on.</t>
      <t>If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions above, the
receiver MUST <bcp14>MUST</bcp14> close the corresponding data channel using the procedure
described in <xref target='RFCYYYY'/> target="RFC8831" format="default"/> and MUST NOT <bcp14>MUST NOT</bcp14> send a DATA_CHANNEL_ACK
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, stream, there are
problems with parameters within the DATA_CHANNEL_OPEN
message, the odd/even rule is violated, or the DATA_CHANNEL_OPEN message itself
is not well formed. Therefore, receiving an SCTP Stream-reset stream-reset request for a Stream stream on which
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
setup procedure. After also successfully resetting the corresponding outgoing
Stream,
stream, which concludes the data channel closing initiated by the peer,
a new DATA_CHANNEL_OPEN message can be sent on the Stream.</t> stream.</t>
      <t>After the DATA_CHANNEL_OPEN message has been sent, the sender of that message
MAY
<bcp14>MAY</bcp14> start sending messages containing user data without
waiting for the reception of the corresponding DATA_CHANNEL_ACK message.
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
belonging to this data channel MUST <bcp14>MUST</bcp14> be sent ordered, no matter
whether the data channel is ordered or not.
After the DATA_CHANNEL_ACK or any other message has been received on the
data channel, messages containing user data MUST <bcp14>MUST</bcp14> be sent ordered on ordered
data channels and MUST <bcp14>MUST</bcp14> be sent unordered on unordered data channels.
Therefore, receiving a message containing user data on an unused Stream stream
indicates an error. In that case, the corresponding data channel MUST <bcp14>MUST</bcp14> be closed, as described
in <xref target='RFCYYYY'/>.</t> target="RFC8831" format="default"/>.</t>
    </section>
    <section title='Security Considerations'
         anchor='sec-security'> anchor="sec-security" numbered="true" toc="default">
      <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
DATA_CHANNEL_OPEN messages where these field fields have the maximum length of
65535 bytes. Error cases such as using inconsistent lengths of fields,
using unknown parameter values, or violating the odd/even rule must also be handled
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>
      <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.
Such a protocol suite is specified in
<xref target='RFC8261'/>.</t> target="RFC8261" format="default"/>.</t>
      <t>For general considerations, see <xref target='SECURITY'/> target="RFC8826" format="default"/> and
<xref target='SECURITY-ARCH'/>.</t> target="RFC8827" format="default"/>.</t>
    </section>
    <section title='IANA Considerations'> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is asked to update has updated the reference of an already existing SCTP PPID
assignment (<xref target='iana_ppid'/>) target="iana_ppid" format="default"/>) and create created a new
standalone registry with its own URL for the DCEP (<xref target='iana_dcep_registry'/>)
target="iana_dcep_registry" format="default"/>) containing two new
registration tables (Sections <xref format="counter" target='iana_msg_type'/> target="iana_msg_type"/>
and <xref format="counter" target='iana_channel_type'/>).</t> target="iana_channel_type"/>).</t>

      <section title='SCTP anchor="iana_ppid" numbered="true" toc="default">
        <name>SCTP Payload Protocol Identifier'
         anchor='iana_ppid'> Identifier</name>
        <t>This document uses one already registered an SCTP Payload Protocol
Identifier (PPID) named previously registered as "WebRTC Control".

<xref target='RFC4960'/> target="RFC4960" format="default"/> creates the registry
"SCTP Payload Protocol Identifiers", from Identifiers" registry, in which this identifier was assigned.
IANA is requested to update name of has updated the registry PPID name from "WebRTC Control" to "WebRTC DCEP" and update has
updated the reference of
this assignment to point to this document. The corresponding date should be has been
kept.</t>
        <t>Therefore, this assignment should be updated to read:</t>
<texttable>
<ttcol align='left'>Value</ttcol>
<ttcol align='left'>SCTP PPID</ttcol>
<ttcol align='left'>Reference</ttcol>
<ttcol align='left'>Date</ttcol>
<c>WebRTC DCEP</c> <c>50</c> <c>[RFCXXXX]</c> <c>2013-09-20</c>
</texttable> now appears as follows:</t>
        <table align="center">
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">SCTP PPID</th>
              <th align="left">Reference</th>
              <th align="left">Date</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">WebRTC DCEP</td>
              <td align="left">50</td>
              <td align="left">RFC 8832</td>
              <td align="left">2013-09-20</td>
            </tr>
          </tbody>
        </table>
      </section>

      <section title='New anchor="iana_dcep_registry" numbered="true" toc="default">
        <name>New Standalone Registry for the DCEP'
         anchor='iana_dcep_registry'> DCEP</name>
        <t>IANA is requested to create a new standalone registry (a.k.a. webpage) with
its own URL for has created the Data Channel Establishment Protocol (DCEP).
The title should be "Data Channel Establishment Protocol (DCEP) Parameters".
	Parameters" registry.  It will contain contains the two tables provided in Sections
	<xref format="counter" target='iana_msg_type'/> target="iana_msg_type"/>
and <xref format="counter" target='iana_channel_type'/>.</t> target="iana_channel_type"/>.</t>

        <section title='New anchor="iana_msg_type" numbered="true" toc="default">
          <name>New Message Type Registry'
         anchor ='iana_msg_type'> Registry</name>

          <t>IANA is requested to create a new registration table, has created the "Message Type Registry", Types" registry for the Data Channel Establishment Protocol (DCEP) DCEP to manage
	  the one-byte "Message Type" field in DCEP messages (see <xref target='msg_format'/>).
	  target="msg_format" format="default"/>). This registration table should be part
	  is a subregistry 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:
The assignment of new message types is done through an RFC Required
action, as defined in [RFC5226].

New:
The assignment of new message types is done through an RFC Required
action, as defined in [RFC8126].
-->
	  target="iana_dcep_registry" format="default"/>.</t>

          <t>The assignment of new message types is done through an RFC Required action,
as defined in <xref target='RFC8126'/>. target="RFC8126" format="default"/>.
Documentation of the new message type MUST types <bcp14>MUST</bcp14> contain the following information:
<list style="numbers">
<t>A
</t>
          <ol spacing="normal" type="1">
            <li>A name for the new message type;</t>
<t>A type.</li>

            <li>A detailed procedural description of the use of messages with the new how each message type is used with
	    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 DCEP.</li>
          </ol>
          <t>The following sentence, does "the document" refer to this
document?

Original:
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.

Perhaps:
Please note 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>

          <t>Note that the values 0x00 and 0x01 are reserved to avoid
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.
The value 0xff has been reserved for future extensibility.
The range of possible values is from 0x00 to 0xff.</t>
        </section>

        <section title='New anchor="iana_channel_type" numbered="true" toc="default">
          <name>New Channel Type Registry'
         anchor='iana_channel_type'> Registry</name>
          <t>IANA is requested to create a new registration table, has created the "Channel Type Registry", Types" registry
for the Data Channel Establishment Protocol DCEP to manage the one-byte
"Channel Type" field in DATA_CHANNEL_OPEN messages
(see <xref target='open_msg_format'/>). target="open_msg_format" format="default"/>).
This registration table should be part of is a subregistry within the registry described in
<xref target='iana_dcep_registry'/>.</t> target="iana_dcep_registry" format="default"/>.</t>
          <t>The assignment of new message types is done through an RFC Required action,
as defined in <xref target='RFC8126'/>. target="RFC8126" format="default"/>.
Documentation of the new Channel Type MUST Types <bcp14>MUST</bcp14> contain the following information:
<list style="numbers">
<t>A
</t>
          <ol spacing="normal" type="1">
            <li>A name for the new Channel Type;</t>
<t>A Type.</li>
            <li>A detailed procedural description of the user message handling for
data channels using this new Channel Type.</t>
</list>
Please note that if Type.</li>
          </ol>
          <t>
If new Channel Types support ordered and unordered message
delivery, the high-order bit MUST <bcp14>MUST</bcp14> be used to indicate whether
or not the message delivery is unordered or not.</t>
<t>Initially, the unordered.</t>
          <t>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>DATA_CHANNEL_RELIABLE</c>                          <c>0x00</c> <c>[RFCXXXX]</c>
<c>DATA_CHANNEL_RELIABLE_UNORDERED</c>                <c>0x80</c> <c>[RFCXXXX]</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT</c>           <c>0x01</c> <c>[RFCXXXX]</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED</c> <c>0x81</c> <c>[RFCXXXX]</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED</c>            <c>0x02</c> <c>[RFCXXXX]</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED</c>  <c>0x82</c> <c>[RFCXXXX]</c>
<c>Reserved</c>                                       <c>0x7f</c> <c>[RFCXXXX]</c>
<c>Reserved</c>                                       <c>0xff</c> <c>[RFCXXXX]</c>
<c>Unassigned</c>                                     <c>rest</c> <c>         </c>
</texttable>
<t>Please note that are the values initial 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">DATA_CHANNEL_RELIABLE</td>
                <td align="left">0x00</td>
                <td align="left">RFC 8832</td>
              </tr>
              <tr>
                <td align="left">DATA_CHANNEL_RELIABLE_UNORDERED</td>
                <td align="left">0x80</td>
                <td align="left">RFC 8832</td>
              </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.
The range of possible values is from 0x00 to 0xff.</t>
        </section>
      </section>
    </section>
  </middle>
  <back>
<references title='Normative References'>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.8174'?>
<?rfc include='reference.RFC.3629'?>
<?rfc include='reference.RFC.4347'?>
<?rfc include='reference.RFC.4960'?>
<?rfc include='reference.RFC.8126'?>
<?rfc include='reference.RFC.6347'?>
<?rfc include='reference.RFC.8261'?>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4347.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.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"/>

<!-- draft-ietf-rtcweb-data-channel (RFC 8831) -->
<reference anchor="RFCYYYY" target="https://www.rfc-editor.org/info/rfcYYYY"> anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8831">
<front>
<title>WebRTC Data Channels</title>
<author initials='R' surname='Jesup' fullname='Randell Jesup'> initials="R." surname="Jesup" fullname="Randell Jesup">
  <organization/>
</author>
<author initials='S' surname='Loreto' fullname='Salvatore Loreto'> initials="S." surname="Loreto" fullname="Salvatore Loreto">
  <organization/>
</author>
<author initials='M' surname='Tuexen' fullname='Michael Tuexen'> initials="M." surname="Tüxen" fullname="Michael Tüxen">
  <organization/>
</author>
<date month='October' year='2018'/> year='2020'/>
</front>
<seriesInfo name="RFC" value="YYYY"/> value="8831"/>
<seriesInfo name="DOI" value="10.17487/RFCYYYY"/> value="10.17487/RFC8831"/>
</reference>

      </references>

<references title='Informative References'>
<?rfc include='reference.RFC.6455'?>

<!-- draft-ietf-rtcweb-security-10 exists

      <references>
        <name>Informative References</name>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6455.xml"/>

 <!--draft-ietf-rtcweb-security: RFC 8826 -->
 <reference anchor='SECURITY'> anchor="RFC8826" target="https://www.rfc-editor.org/info/rfc8826">
 <front>
 <title>Security Considerations for WebRTC</title>
 <author initials='E' initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
   <organization/>
 </author>
 <date month='January' day='22' year='2018' /> month='October' year='2020'/>
 </front>
 <seriesInfo name='Work in Progress,' value='draft-ietf-rtcweb-security-10' /> name="RFC" value="8826"/>
 <seriesInfo name="DOI" value="10.17487/RFC8826"/>
 </reference>

<!-- draft-ietf-rtcweb-security-arch-15 exists

 <!--draft-ietf-rtcweb-security-arch: 8827 -->
 <reference anchor='SECURITY-ARCH'> anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8827">
 <front>
 <title>WebRTC Security Architecture</title>
 <author initials='E' initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
   <organization/>
 </author>
 <date month='July' day='17' year='2018' /> month='October' year='2020'/>
 </front>
 <seriesInfo name='Work in Progress,' value='draft-ietf-rtcweb-security-arch-15' /> name="RFC" value="8827"/>
 <seriesInfo name="DOI" value="10.17487/RFC8827"/>
 </reference>

      </references>
    </references>
    <section title='Acknowledgments' numbered="no"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors wish to thank
Harald Alvestrand,
Richard Barnes,
Adam Bergkvist,
Spencer Dawkins,
Barry Dingle,
Stefan Haekansson,
Cullen Jennings,
Paul Kyzivat,
Doug Leonard,
Alexey Melnikov,
Pete Resnick,
Irene Ruengeler,
Randall Stewart,
Peter Thatcher,
Martin Thompson,
Justin Uberti,
<contact fullname="Harald Alvestrand"/>,
<contact fullname="Richard Barnes"/>,
<contact fullname="Adam Bergkvist"/>,
<contact fullname="Spencer Dawkins"/>,
<contact fullname="Barry Dingle"/>,
<contact fullname="Stefan Haekansson"/>,
<contact fullname="Cullen Jennings"/>,
<contact fullname="Paul Kyzivat"/>,
<contact fullname="Doug Leonard"/>,
<contact fullname="Alexey Melnikov"/>,
<contact fullname="Pete Resnick"/>,
<contact fullname="Irene Rüngeler"/>,
<contact fullname="Randall Stewart"/>,
<contact fullname="Peter Thatcher"/>,
<contact fullname="Martin Thompson"/>,
<contact fullname="Justin Uberti"/>,
and many others for their invaluable comments.</t>
    </section>
  </back>
</rfc>