rfc8832xml2.original.xml		rfc8832.xml
	<?xml version='1.0' encoding="US-ASCII"?>		<?xml version='1.0' encoding='utf-8'?>
			<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
	<?rfc symrefs='yes'?>		nsus="true" docName="draft-ietf-rtcweb-data-protocol-09" indexInclude="true" ipr
	<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>		="trust200902" number="8832" prepTime="2021-01-16T21:37:59" scripts="Common,Lati
	<?rfc toc='yes' ?>		n" sortRefs="false" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude
	<?rfc compact='yes' ?>		="true" xml:lang="en">
	<?rfc subcompact='no' ?>		<link href="https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol-0
	<?rfc sortrefs='no' ?>		9" rel="prev"/>
	<?rfc strict='yes' ?>		<link href="https://dx.doi.org/10.17487/rfc8832" rel="alternate"/>
			<link href="urn:issn:2070-1721" rel="alternate"/>
	<rfc category='std'		<front>
	ipr='trust200902'		<title>WebRTC Data Channel Establishment Protocol</title>
	number="XXXX"		<seriesInfo name="RFC" value="8832" stream="IETF"/>
	submissionType="IETF"		<author initials="R." surname="Jesup" fullname="Randell Jesup">
	consensus="yes"		<organization showOnFrontPage="true">Mozilla</organization>
	>		<address>
	<front>		<postal>
	<title>WebRTC Data Channel Establishment Protocol</title>		<street/>
			<code/>
	<author initials='R.' surname='Jesup' fullname='Randell Jesup'>		<city/>
	<organization>Mozilla</organization>		<country>United States of America</country>
	<address>		</postal>
	<postal>		<email>randell-ietf@jesup.org</email>
	<street></street>		</address>
	<code></code>		</author>
	<city></city>		<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
	<country>United States of America</country>		<organization showOnFrontPage="true">Ericsson</organization>
	</postal>		<address>
	<email>randell-ietf@jesup.org</email>		<postal>
	</address>		<street>Hirsalantie 11</street>
	</author>		<code>02420</code>
			<city>Jorvas</city>
	<author initials='S.' surname='Loreto' fullname='Salvatore Loreto'>		<country>Finland</country>
	<organization>Ericsson</organization>		</postal>
	<address>		<email>salvatore.loreto@ericsson.com</email>
	<postal>		</address>
	<street>Hirsalantie 11</street>		</author>
	<code>02420</code>		<author initials="M." surname="Tüxen" fullname="Michael Tüxen">
	<city>Jorvas</city>		<organization abbrev="Münster Univ. of Appl. Sciences" showOnFrontPage="tr
	<country>Finland</country>		ue">Münster University of Applied Sciences</organization>
	</postal>		<address>
	<email>salvatore.loreto@ericsson.com</email>		<postal>
	</address>		<street>Stegerwaldstrasse 39</street>
	</author>		<code>48565</code>
			<city> Steinfurt</city>
	<author initials='M.' surname='Tuexen' fullname='Michael Tuexen'>		<country>Germany</country>
	<organization abbrev='Muenster Univ. of Appl. Sciences'>		</postal>
	Muenster University of Applied Sciences</organization>		<email>tuexen@fh-muenster.de</email>
	<address>		</address>
	<postal>		</author>
	<street>Stegerwaldstrasse 39</street>		<date month="01" year="2021"/>
	<code>48565</code>		<abstract pn="section-abstract">
	<city> Steinfurt</city>		<t indent="0" pn="section-abstract-1">The WebRTC framework specifies proto
	<country>Germany</country>		col support for direct interactive
	</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>
	<abstract>
	<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>		<boilerplate>
			<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
	<middle>		"exclude" pn="section-boilerplate.1">
	<section title='Introduction'>		<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
	<t>The Data Channel Establishment Protocol (DCEP) is designed to provide, in the		>
	WebRTC data channel context <xref target='RFCYYYY'/>,		<t indent="0" pn="section-boilerplate.1-1">
			This is an Internet Standards Track document.
			</t>
			<t indent="0" pn="section-boilerplate.1-2">
			This document is a product of the Internet Engineering Task Force
			(IETF). It represents the consensus of the IETF community. It has
			received public review and has been approved for publication by
			the Internet Engineering Steering Group (IESG). Further
			information on Internet Standards is available in Section 2 of
			RFC 7841.
			</t>
			<t indent="0" pn="section-boilerplate.1-3">
			Information about the current status of this document, any
			errata, and how to provide feedback on it may be obtained at
			<eref target="https://www.rfc-editor.org/info/rfc8832" brackets="non
			e"/>.
			</t>
			</section>
			<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
			ude" pn="section-boilerplate.2">
			<name slugifiedName="name-copyright-notice">Copyright Notice</name>
			<t indent="0" pn="section-boilerplate.2-1">
			Copyright (c) 2021 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			</t>
			<t indent="0" pn="section-boilerplate.2-2">
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(<eref target="https://trustee.ietf.org/license-info" brackets="none
			"/>) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with
			respect to this document. Code Components extracted from this
			document must include Simplified BSD License text as described in
			Section 4.e of the Trust Legal Provisions and are provided without
			warranty as described in the Simplified BSD License.
			</t>
			</section>
			</boilerplate>
			<toc>
			<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
			n="section-toc.1">
			<name slugifiedName="name-table-of-contents">Table of Contents</name>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
			c.1-1">
			<li pn="section-toc.1-1.1">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
			ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
			derivedContent="" format="title" sectionFormat="of" target="name-introduction">
			Introduction</xref></t>
			</li>
			<li pn="section-toc.1-1.2">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
			ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
			derivedContent="" format="title" sectionFormat="of" target="name-conventions">C
			onventions</xref></t>
			</li>
			<li pn="section-toc.1-1.3">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref der
			ivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref
			derivedContent="" format="title" sectionFormat="of" target="name-terminology">T
			erminology</xref></t>
			</li>
			<li pn="section-toc.1-1.4">
			<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
			at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-protocol-overview">Protocol Overvi
			ew</xref></t>
			</li>
			<li pn="section-toc.1-1.5">
			<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
			at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-message-formats">Message Formats</
			xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.5.2">
			<li pn="section-toc.1-1.5.2.1">
			<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
			"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-data_channel_open-mess
			age">DATA_CHANNEL_OPEN Message</xref></t>
			</li>
			<li pn="section-toc.1-1.5.2.2">
			<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
			"5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-data_channel_ack-messa
			ge">DATA_CHANNEL_ACK Message</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.6">
			<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
			at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-procedures">Procedures</xref></t>
			</li>
			<li pn="section-toc.1-1.7">
			<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
			at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-security-considerations">Security
			Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.8">
			<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
			at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
			ations</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.8.2">
			<li pn="section-toc.1-1.8.2.1">
			<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
			"8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-sctp-payload-protocol-
			ident">SCTP Payload Protocol Identifier</xref></t>
			</li>
			<li pn="section-toc.1-1.8.2.2">
			<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
			"8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-new-standalone-registr
			y-for">New Standalone Registry for DCEP</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
			ction-toc.1-1.8.2.2.2">
			<li pn="section-toc.1-1.8.2.2.2.1">
			<t indent="0" pn="section-toc.1-1.8.2.2.2.1.1"><xref derived
			Content="8.2.1" format="counter" sectionFormat="of" target="section-8.2.1"/>.  <
			xref derivedContent="" format="title" sectionFormat="of" target="name-new-messag
			e-type-registry">New Message Type Registry</xref></t>
			</li>
			<li pn="section-toc.1-1.8.2.2.2.2">
			<t indent="0" pn="section-toc.1-1.8.2.2.2.2.1"><xref derived
			Content="8.2.2" format="counter" sectionFormat="of" target="section-8.2.2"/>.  <
			xref derivedContent="" format="title" sectionFormat="of" target="name-new-channe
			l-type-registry">New Channel Type Registry</xref></t>
			</li>
			</ul>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.9">
			<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
			at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-references">References</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.9.2">
			<li pn="section-toc.1-1.9.2.1">
			<t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent=
			"9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-normative-references">
			Normative References</xref></t>
			</li>
			<li pn="section-toc.1-1.9.2.2">
			<t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent=
			"9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-informative-references
			">Informative References</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.10">
			<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" form
			at="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="
			" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme
			nts</xref></t>
			</li>
			<li pn="section-toc.1-1.11">
			<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" form
			at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
			" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
			resses</xref></t>
			</li>
			</ul>
			</section>
			</toc>
			</front>
			<middle>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-1">
			<name slugifiedName="name-introduction">Introduction</name>
			<t indent="0" pn="section-1-1">The Data Channel Establishment Protocol (DC
			EP) is designed to provide, in the
			WebRTC data channel context <xref target="RFC8831" format="default" sectionForma
			t="of" derivedContent="RFC8831"/>,
	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" sectionFormat="of" deriv
	the Stream Control Transmission Protocol (SCTP) <xref target='RFC4960'/>		edContent="RFC8831"/>, the protocol uses
	encapsulated in the Datagram Transport Layer Security (DTLS) (described in		the Stream Control Transmission Protocol (SCTP) <xref target="RFC4960" format="d
	<xref target='RFC8261'/>). This allows the DCEP to benefit from the		efault" sectionFormat="of" derivedContent="RFC4960"/>
			encapsulated in Datagram Transport Layer Security (DTLS) (described in
			<xref target="RFC8261" format="default" sectionFormat="of" derivedContent="RFC82
			61"/>). 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.
	4347'/>, and the		DTLS 1.0 is defined in <xref target="RFC4347" format="default" sectionFormat="of
	present latest version, DTLS 1.2, is defined in <xref target='RFC6347'/>.		" derivedContent="RFC4347"/>; the present
	</t>		latest version, DTLS 1.2, is defined in <xref target="RFC6347" format="default"
	</section>		sectionFormat="of" derivedContent="RFC6347"/>; and
			an upcoming version, DTLS 1.3, is defined in <xref target="I-D.ietf-tls-dtls13"
	<section title='Conventions'>		format="default" sectionFormat="of" derivedContent="TLS-DTLS13"/>.</t>
	<t>		</section>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		<section numbered="true" toc="include" removeInRFC="false" pn="section-2">
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",		<name slugifiedName="name-conventions">Conventions</name>
	"MAY", and "OPTIONAL" in this document are to be interpreted as		<t indent="0" pn="section-2-1">
	described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
			IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
			D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
			OT 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" sectionFormat="o
			f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
			mat="of" derivedContent="RFC8174"/>
	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="include" removeInRFC="false" pn="section-3">
			<name slugifiedName="name-terminology">Terminology</name>
	<section title='Terminology'>		<t indent="0" pn="section-3-1">This document uses the following terms:
	<t>This document uses the following terms:		</t>
	<list style='hanging'>		<dl newline="false" spacing="normal" indent="3" pn="section-3-2">
	<t hangText='Association:'>		<dt pn="section-3-2.1">Association:</dt>
	An SCTP association.</t>		<dd pn="section-3-2.2">An SCTP association.</dd>
	<t hangText='Stream:'>		<dt pn="section-3-2.3">Stream:</dt>
			<dd pn="section-3-2.4">
	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 pn="section-3-2.5">Stream Identifier:</dt>
	The SCTP stream identifier uniquely identifying a Stream.</t>		<dd pn="section-3-2.6">
	<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 pn="section-3-2.7">Data Channel:</dt>
	which are managed together.</t>		<dd pn="section-3-2.8">
	</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="include" removeInRFC="false" pn="section-4">
			<name slugifiedName="name-protocol-overview">Protocol Overview</name>
			<t indent="0" pn="section-4-1">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 indent="0" pn="section-4-2">The set of consistent properties includes:
	<list style='symbols'>		</t>
	<t>reliable or unreliable message transmission. In case of unreliable		<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-3
	transmissions, the same level of unreliability is used.</t>		">
	<t>in-order or out-of-order message delivery.</t>		<li pn="section-4-3.1">reliable or unreliable message transmission. In c
	<t>the priority of the data channel.</t>		ase of unreliable
	<t>an optional label for the data channel.</t>		transmissions, the same level of unreliability is used.</li>
	<t>an optional protocol for the data channel.</t>		<li pn="section-4-3.2">in-order or out-of-order message delivery.</li>
	<t>the Streams.</t>		<li pn="section-4-3.3">the priority of the data channel.</li>
	</list></t>		<li pn="section-4-3.4">an optional label for the data channel.</li>
	<t>This protocol uses a two-way handshake to open a data channel.		<li pn="section-4-3.5">an optional protocol for the data channel.</li>
	The handshake pairs one incoming and one outgoing Stream, both having the		<li pn="section-4-3.6">the streams.</li>
			</ul>
			<t indent="0" pn="section-4-4">This protocol uses a two-way handshake to o
			pen 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 pn="section-4-5">
			<t indent="0" pn="section-4-5.1">Note: The opening side <bcp14>MAY</bcp1
			4> send user messages before the DATA_CHANNEL_ACK
	is received.</t>		is received.</t>
	<t>To avoid collisions where both sides try to open a data channel with		</aside>
	the same stream identifiers, each side MUST use Streams with either even or		<t indent="0" pn="section-4-6">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" sectionFormat= "of" derivedContent="RFC8261"/>,
	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 pn="section-4-7">
			<t indent="0" pn="section-4-7.1">Note: There is no attempt to ensure uni
			queness 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>
	<!--[rfced] FYI, we changed the following sentence for clarity; please check		</aside>
	that it still conveys the intended meaning.		<t indent="0" pn="section-4-8">The purpose of the protocol field is to eas
			e cross-application interoperation ("federation")
	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.
	<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" sectionFormat="of" derivedContent="RFC6455"/>.
	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="include" removeInRFC="fals
	<section title='Message Formats'		e" pn="section-5">
	anchor='msg_format'>		<name slugifiedName="name-message-formats">Message Formats</name>
	<t>Every DCEP message starts with a one-byte		<t indent="0" pn="section-5-1">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" sectionFormat="of" derivedCon
			tent="Section 8.2.1"/>).</t>
	<section title='DATA_CHANNEL_OPEN Message'		<section anchor="open_msg_format" numbered="true" toc="include" removeInRF
	anchor='open_msg_format'>		C="false" pn="section-5.1">
	<t>This message is initially sent using the data channel on the Stream used		<name slugifiedName="name-data_channel_open-message">DATA_CHANNEL_OPEN M
			essage</name>
			<t indent="0" pn="section-5.1-1">This message is initially sent using th
			e data channel on the stream used
	for user messages.</t>		for user messages.</t>
	<figure>		<artwork align="center" name="" type="" alt="" pn="section-5.1-2">
	<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>		<dl newline="true" spacing="normal" indent="3" pn="section-5.1-3">
	</figure>		<dt pn="section-5.1-3.1">Message Type: 1 byte (unsigned integer)</dt>
	<t><list style='hanging'>		<dd pn="section-5.1-3.2">
	<t hangText='Message Type: 1 byte (unsigned integer)'>		<t indent="0" pn="section-5.1-3.2.1">
	<vspace blankLines='0'/>
	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" sectionFormat="of" derivedContent=
	<t hangText='Channel Type: 1 byte (unsigned integer)'>		"Section 8.2.1"/>.</t>
	<vspace blankLines='0'/>		</dd>
			<dt pn="section-5.1-3.3">Channel Type: 1 byte (unsigned integer)</dt>
			<dd pn="section-5.1-3.4">
			<t indent="0" pn="section-5.1-3.4.1">
	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'>		" sectionFormat="of" derivedContent="Section 8.2.2"/>):
	<t hangText='DATA_CHANNEL_RELIABLE (0x00):'>		</t>
	The data channel provides a reliable in-order bidirectional communication.</t>		<dl newline="false" spacing="normal" indent="3" pn="section-5.1-3.4.
	<t hangText='DATA_CHANNEL_RELIABLE_UNORDERED (0x80):'>		2">
	The data channel provides a reliable unordered bidirectional communication.</t>		<dt pn="section-5.1-3.4.2.1">DATA_CHANNEL_RELIABLE (0x00):</dt>
			<dd pn="section-5.1-3.4.2.2">
	<!--[rfced] The rest of this document refers to "partial reliable"		The data channel provides a reliable in-order bidirectional communication.</dd>
	communication, but the following sentence uses "partially		<dt pn="section-5.1-3.4.2.3">DATA_CHANNEL_RELIABLE_UNORDERED (0x80
	reliable". Please let us know which wording, if any, should be changed.		):</dt>
			<dd pn="section-5.1-3.4.2.4">
	ORIGINAL:		The data channel provides a reliable unordered bidirectional communication.</dd>
	The Data Channel provides a partially reliable in-order bidirectional		<dt pn="section-5.1-3.4.2.5">DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT
	communication.		(0x01):</dt>
	<t hangText='DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01):'>		<dd pn="section-5.1-3.4.2.6">
	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 pn="section-5.1-3.4.2.7">DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_
	The data channel provides a partial reliable unordered bidirectional		UNORDERED (0x81):</dt>
			<dd pn="section-5.1-3.4.2.8">
			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 pn="section-5.1-3.4.2.9">DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (
	The data channel provides a partial reliable in-order bidirectional		0x02):</dt>
			<dd pn="section-5.1-3.4.2.10">
			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 pn="section-5.1-3.4.2.11">DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_
	The data channel provides a partial reliable unordered bidirectional		UNORDERED (0x82):</dt>
			<dd pn="section-5.1-3.4.2.12">
			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 pn="section-5.1-3.5">Priority: 2 bytes (unsigned integer)</dt>
			<dd pn="section-5.1-3.6">
			<t indent="0" pn="section-5.1-3.6.1">
	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" sectionFormat="of" derivedContent="RFC88
	<t hangText='Reliability Parameter: 4 bytes (unsigned integer)'>		31"/>.</t>
	<vspace blankLines='0'/>		</dd>
	For reliable data channels, this field MUST be set to 0 on the sending side		<dt pn="section-5.1-3.7">Reliability Parameter: 4 bytes (unsigned inte
	and MUST be ignored on the receiving side.		ger)</dt>
	If a partial reliable data channel with a limited number of retransmissions is		<dd pn="section-5.1-3.8">
	used, this field specifies the number of retransmissions. If a partial		<t indent="0" pn="section-5.1-3.8.1">
			For reliable data channels, this field <bcp14>MUST</bcp14> be set to 0 on the se
			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" pn="table-1">
	<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" colspan="1" rowspan="1">Channel Type</th>
	<c>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT</c> <c>Number of RTX</c>		<th align="center" colspan="1" rowspan="1">Reliability Parameter</
	<c>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED</c><c>Number of RTX</c>		th>
	<c>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED</c> <c>Lifetime in ms</c>		</tr>
	<c>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED</c> <c>Lifetime in ms</c>		</thead>
	</texttable>		<tbody>
	<t><list style='hanging'>		<tr>
	<t hangText='Label Length: 2 bytes (unsigned integer)'>		<td align="left" colspan="1" rowspan="1">DATA_CHANNEL_RELIABLE</td
	<vspace blankLines='0'/>		>
			<td align="center" colspan="1" rowspan="1">Ignored</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">DATA_CHANNEL_RELIABLE_UNO
			RDERED</td>
			<td align="center" colspan="1" rowspan="1">Ignored</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">DATA_CHANNEL_PARTIAL_RELI
			ABLE_REXMIT</td>
			<td align="center" colspan="1" rowspan="1">Number of RTX</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">DATA_CHANNEL_PARTIAL_RELI
			ABLE_REXMIT_UNORDERED</td>
			<td align="center" colspan="1" rowspan="1">Number of RTX</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">DATA_CHANNEL_PARTIAL_RELI
			ABLE_TIMED</td>
			<td align="center" colspan="1" rowspan="1">Lifetime in ms</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">DATA_CHANNEL_PARTIAL_RELI
			ABLE_TIMED_UNORDERED</td>
			<td align="center" colspan="1" rowspan="1">Lifetime in ms</td>
			</tr>
			</tbody>
			</table>
			<dl newline="true" spacing="normal" indent="3" pn="section-5.1-5">
			<dt pn="section-5.1-5.1">Label Length: 2 bytes (unsigned integer)</dt>
			<dd pn="section-5.1-5.2">
			<t indent="0" pn="section-5.1-5.2.1">
	The length of the label field in bytes.</t>		The length of the label field in bytes.</t>
	<t hangText='Protocol Length: 2 bytes (unsigned integer)'>		</dd>
	<vspace blankLines='0'/>		<dt pn="section-5.1-5.3">Protocol Length: 2 bytes (unsigned integer)</
			dt>
			<dd pn="section-5.1-5.4">
			<t indent="0" pn="section-5.1-5.4.1">
	The length of the protocol field in bytes.</t>		The length of the protocol field in bytes.</t>
	<t hangText='Label: Variable Length (sequence of characters)'>		</dd>
	<vspace blankLines='0'/>		<dt pn="section-5.1-5.5">Label: Variable Length (sequence of character
			s)</dt>
			<dd pn="section-5.1-5.6">
			<t indent="0" pn="section-5.1-5.6.1">
	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" sectionFormat="of" derivedContent="RFC36
	<t hangText='Protocol: Variable Length (sequence of characters)'>		29"/>. This may be an empty string.</t>
	<vspace blankLines='0'/>		</dd>
			<dt pn="section-5.1-5.7">Protocol: Variable Length (sequence of charac
			ters)</dt>
			<dd pn="section-5.1-5.8">
			<t indent="0" pn="section-5.1-5.8.1">
	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" sectionFormat="of" derivedContent="RFC64
	<xref target='RFC3629'/>.</t>		55"/>. This string is UTF-8 encoded, as specified in
	</list></t>		<xref target="RFC3629" format="default" sectionFormat="of" derivedContent="RFC36
	</section>		29"/>.</t>
			</dd>
	<section title='DATA_CHANNEL_ACK Message'>		</dl>
	<t>This message is sent in response to a		</section>
	DATA_CHANNEL_OPEN_RESPONSE message. It is sent on the Stream used for user		<section numbered="true" toc="include" removeInRFC="false" pn="section-5.2
			">
			<name slugifiedName="name-data_channel_ack-message">DATA_CHANNEL_ACK Mes
			sage</name>
			<t indent="0" pn="section-5.2-1">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="" pn="section-5.2-2">
	<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>		<dl newline="true" spacing="normal" indent="3" pn="section-5.2-3">
	</figure>		<dt pn="section-5.2-3.1">Message Type: 1 byte (unsigned integer)</dt>
	<t><list style='hanging'>		<dd pn="section-5.2-3.2">
	<t hangText='Message Type: 1 byte (unsigned integer)'>		<t indent="0" pn="section-5.2-3.2.1">
	<vspace blankLines='0'/>
	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" sectionFormat="of" derivedContent=
	</list></t>		"Section 8.2.1"/>.</t>
	</section>		</dd>
	</section>		</dl>
			</section>
	<section title='Procedures'>		</section>
	<t>All DCEP messages MUST be sent using ordered delivery and reliable		<section numbered="true" toc="include" removeInRFC="false" pn="section-6">
	transmission. They MUST be sent on the same outgoing Stream as the user messages		<name slugifiedName="name-procedures">Procedures</name>
			<t indent="0" pn="section-6-1">All DCEP messages <bcp14>MUST</bcp14> be se
			nt using ordered delivery and 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" sectionFormat="of" derivedContent
	Other messages MUST NOT be sent using this PPID.</t>		="Section 8.1"/>).
	<t>The peer that initiates opening a data channel selects a stream identifier		Other messages <bcp14>MUST NOT</bcp14> be sent using this PPID.</t>
	for which the corresponding incoming and outgoing Streams are unused.		<t indent="0" pn="section-6-2">The peer that initiates opening a data chan
	If the side is the DTLS client, it MUST choose an even stream identifier;		nel selects a stream identifier
	if the side is the DTLS server, it MUST choose an odd one. The initiating peer		for which the corresponding incoming and outgoing streams are unused.
			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 indent="0" pn="section-6-3">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 indent="0" pn="section-6-4">If the DATA_CHANNEL_OPEN message doesn't sa
	receiver MUST close the corresponding data channel using the procedure		tisfy the conditions above, 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" sectionFormat="of" derivedC
			ontent="RFC8831"/> and <bcp14>MUST NOT</bcp14> 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 indent="0" pn="section-6-5">After the DATA_CHANNEL_OPEN message has bee
	<t>After the DATA_CHANNEL_OPEN message has been sent, the sender of that message		n sent, the sender of that message
	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" sectionFormat="of" derivedContent="RF
	<section title='Security Considerations'		C8831"/>.</t>
	anchor='sec-security'>		</section>
	<t>The DATA_CHANNEL_OPEN message contains two variable-length fields:		<section anchor="sec-security" numbered="true" toc="include" removeInRFC="fa
			lse" pn="section-7">
			<name slugifiedName="name-security-considerations">Security Considerations
			</name>
			<t indent="0" pn="section-7-1">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 indent="0" pn="section-7-2">This protocol does not provide privacy, int egrity, 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" sectionFormat="of" derivedContent="RFC82
	<t>For general considerations, see <xref target='SECURITY'/> and		61"/>.</t>
	<xref target='SECURITY-ARCH'/>.</t>		<t indent="0" pn="section-7-3">For general considerations, see <xref targe
	</section>		t="RFC8826" format="default" sectionFormat="of" derivedContent="RFC8826"/> and
			<xref target="RFC8827" format="default" sectionFormat="of" derivedContent="RFC88
	<section title='IANA Considerations'>		27"/>.</t>
	<t>IANA is asked to update the reference of an already existing SCTP PPID		</section>
	assignment (<xref target='iana_ppid'/>) and create a new standalone registry		<section numbered="true" toc="include" removeInRFC="false" pn="section-8">
	with its own URL for the DCEP (<xref target='iana_dcep_registry'/>) containing		<name slugifiedName="name-iana-considerations">IANA Considerations</name>
	two new registration tables (Sections <xref format="counter" target='iana_msg_ty		<t indent="0" pn="section-8-1">IANA has updated the reference of an alread
	pe'/> and		y existing SCTP PPID
	<xref format="counter" target='iana_channel_type'/>).</t>		assignment (<xref target="iana_ppid" format="default" sectionFormat="of" derived
			Content="Section 8.1"/>) and created a new
			standalone registry with its own URL for DCEP (<xref target="iana_dcep_registry"
			format="default" sectionFormat="of" derivedContent="Section 8.2"/>) containing
			two new
			registration tables (Sections <xref format="counter" target="iana_msg_type" sect
			ionFormat="of" derivedContent="8.2.1"/>
			and <xref format="counter" target="iana_channel_type" sectionFormat="of" derived
			Content="8.2.2"/>).</t>
			<section anchor="iana_ppid" numbered="true" toc="include" removeInRFC="fal
			se" pn="section-8.1">
			<name slugifiedName="name-sctp-payload-protocol-ident">SCTP Payload Prot
			ocol Identifier</name>
			<t indent="0" pn="section-8.1-1">This document uses an SCTP Payload Prot
			ocol
			Identifier (PPID) previously registered as "WebRTC Control".
	<section title='SCTP Payload Protocol Identifier'		<xref target="RFC4960" format="default" sectionFormat="of" derivedContent="RFC49
	anchor='iana_ppid'>		60"/> created the
	<t>This document uses one already registered SCTP Payload Protocol		"SCTP Payload Protocol Identifiers" registry, in which this identifier was assig
	Identifier (PPID) named "WebRTC Control".		ned.
	<xref target='RFC4960'/> creates the registry		IANA has updated the PPID name from "WebRTC Control" to "WebRTC DCEP" and has
	"SCTP Payload Protocol Identifiers", from which this identifier was assigned.		updated the reference to point to this document. The corresponding date has been
	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 indent="0" pn="section-8.1-2">Therefore, this assignment now appears
	<texttable>		as follows:</t>
	<ttcol align='left'>Value</ttcol>		<table align="center" pn="table-2">
	<ttcol align='left'>SCTP PPID</ttcol>		<thead>
	<ttcol align='left'>Reference</ttcol>		<tr>
	<ttcol align='left'>Date</ttcol>		<th align="left" colspan="1" rowspan="1">Value</th>
	<c>WebRTC DCEP</c> <c>50</c> <c>[RFCXXXX]</c> <c>2013-09-20</c>		<th align="left" colspan="1" rowspan="1">SCTP PPID</th>
	</texttable>		<th align="left" colspan="1" rowspan="1">Reference</th>
	</section>		<th align="left" colspan="1" rowspan="1">Date</th>
			</tr>
	<section title='New Standalone Registry for the DCEP'		</thead>
	anchor='iana_dcep_registry'>		<tbody>
	<t>IANA is requested to create a new standalone registry (a.k.a. webpage) with		<tr>
	its own URL for the Data Channel Establishment Protocol (DCEP).		<td align="left" colspan="1" rowspan="1">WebRTC DCEP</td>
	The title should be "Data Channel Establishment Protocol (DCEP) Parameters".		<td align="left" colspan="1" rowspan="1">50</td>
	It will contain the two tables provided in Sections <xref format="counter" targe		<td align="left" colspan="1" rowspan="1">RFC 8832</td>
	t='iana_msg_type'/>		<td align="left" colspan="1" rowspan="1">2013-09-20</td>
	and <xref format="counter" target='iana_channel_type'/>.</t>		</tr>
			</tbody>
	<section title='New Message Type Registry'		</table>
	anchor ='iana_msg_type'>		</section>
	<t>IANA is requested to create a new registration table, "Message Type Registry"		<section anchor="iana_dcep_registry" numbered="true" toc="include" removeI
	,		nRFC="false" pn="section-8.2">
	for the Data Channel Establishment Protocol (DCEP) to manage the one-byte		<name slugifiedName="name-new-standalone-registry-for">New Standalone Re
	"Message Type" field in DCEP messages (see <xref target='msg_format'/>).		gistry for DCEP</name>
	This registration table should be part of the registry described in		<t indent="0" pn="section-8.2-1">IANA has created the "Data Channel Esta
	<xref target='iana_dcep_registry'/>.</t>		blishment Protocol (DCEP)
	<!-- [rfced] The following RFC has been obsoleted. We have updated this		Parameters" registry. It contains the two tables provided in Sections
	reference as follows. Please let us know any objections.		<xref format="counter" target="iana_msg_type" sectionFormat="of" derivedC
			ontent="8.2.1"/>
	Original:		and <xref format="counter" target="iana_channel_type" sectionFormat="of" derived
	The assignment of new message types is done through an RFC Required		Content="8.2.2"/>.</t>
	action, as defined in [RFC5226].		<section anchor="iana_msg_type" numbered="true" toc="include" removeInRF
			C="false" pn="section-8.2.1">
	New:		<name slugifiedName="name-new-message-type-registry">New Message Type
	The assignment of new message types is done through an RFC Required		Registry</name>
	action, as defined in [RFC8126].		<t indent="0" pn="section-8.2.1-1">IANA has created the "Message Types
	<t>The assignment of new message types is done through an RFC Required action,		" registry for DCEP to manage
	as defined in <xref target='RFC8126'/>.		the one-byte "Message Type" field in DCEP messages (see <xref target="m
	Documentation of the new message type MUST contain the following information:		sg_format" format="default" sectionFormat="of" derivedContent="Section 5"/>). Th
	<list style="numbers">		is registration table
	<t>A name for the new message type;</t>		is a subregistry of the registry described in <xref target="iana_dcep_r
	<t>A detailed procedural description of the use of messages with the new type		egistry" format="default" sectionFormat="of" derivedContent="Section 8.2"/>.</t>
	within the operation of the Data Channel Establishment Protocol.</t>		<t indent="0" pn="section-8.2.1-2">The assignment of new message types
	</list></t>		is done through an RFC Required action,
	<t>Initially, the following values need to be registered:</t>		as defined in <xref target="RFC8126" format="default" sectionFormat="of" derived
	<texttable>		Content="RFC8126"/>.
	<ttcol align='left'>Name</ttcol>		Documentation of new message types <bcp14>MUST</bcp14> contain the following inf
	<ttcol align='left'>Type</ttcol>		ormation:
	<ttcol align='left'>Reference</ttcol>		</t>
	<c>Reserved</c> <c>0x00 </c> <c>[RFCXXXX]</c>		<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-
	<c>Reserved</c> <c>0x01 </c> <c>[RFCXXXX]</c>		8.2.1-3">
	<c>DATA_CHANNEL_ACK</c> <c>0x02 </c> <c>[RFCXXXX]</c>		<li pn="section-8.2.1-3.1" derivedCounter="1.">A name for the new me
	<c>DATA_CHANNEL_OPEN</c> <c>0x03 </c> <c>[RFCXXXX]</c>		ssage type.</li>
	<c>Unassigned</c> <c>0x04-0xfe</c> <c> </c>		<li pn="section-8.2.1-3.2" derivedCounter="2.">A detailed procedural
	<c>Reserved</c> <c>0xff </c> <c>[RFCXXXX]</c>		description of how each message type is used with
	</texttable>		within DCEP.</li>
			</ol>
	<!--[rfced] In the following sentence, does "the document" refer to this		<t indent="0" pn="section-8.2.1-4">The following are the initial regis
	document?		trations:</t>
			<table align="center" pn="table-3">
	Original:		<thead>
	Please note that the values 0x00 and 0x01 are reserved to avoid		<tr>
	interoperability problems, since they have been used in earlier		<th align="left" colspan="1" rowspan="1">Name</th>
	versions of the document.		<th align="left" colspan="1" rowspan="1">Type</th>
			<th align="left" colspan="1" rowspan="1">Reference</th>
	Perhaps:		</tr>
	Please note that the values 0x00 and 0x01 are reserved to avoid		</thead>
	interoperability problems, since they have been used in draft		<tbody>
	versions of this document.		<tr>
	<t>Please note that the values 0x00 and 0x01 are reserved to avoid		<td align="left" colspan="1" rowspan="1">Reserved</td>
	interoperability problems, since they have been used in earlier versions		<td align="left" colspan="1" rowspan="1">0x00 </td>
			<td align="left" colspan="1" rowspan="1">RFC 8832</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">Reserved</td>
			<td align="left" colspan="1" rowspan="1">0x01 </td>
			<td align="left" colspan="1" rowspan="1">RFC 8832</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">DATA_CHANNEL_ACK</td>
			<td align="left" colspan="1" rowspan="1">0x02 </td>
			<td align="left" colspan="1" rowspan="1">RFC 8832</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">DATA_CHANNEL_OPEN</td>
			<td align="left" colspan="1" rowspan="1">0x03 </td>
			<td align="left" colspan="1" rowspan="1">RFC 8832</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">Unassigned</td>
			<td align="left" colspan="1" rowspan="1">0x04-0xfe</td>
			<td align="left" colspan="1" rowspan="1"> </td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">Reserved</td>
			<td align="left" colspan="1" rowspan="1">0xff </td>
			<td align="left" colspan="1" rowspan="1">RFC 8832</td>
			</tr>
			</tbody>
			</table>
			<t indent="0" pn="section-8.2.1-6">Note that values 0x00 and 0x01 are
			reserved to avoid
			interoperability problems, since they have been used in draft 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 anchor="iana_channel_type" numbered="true" toc="include" remove
	<section title='New Channel Type Registry'		InRFC="false" pn="section-8.2.2">
	anchor='iana_channel_type'>		<name slugifiedName="name-new-channel-type-registry">New Channel Type
	<t>IANA is requested to create a new registration table, "Channel Type Registry"		Registry</name>
	,		<t indent="0" pn="section-8.2.2-1">IANA has created the "Channel Types
	for the Data Channel Establishment Protocol to manage the one-byte		" registry
			for DCEP 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" sectionFormat="of" derivedC
	This registration table should be part of the registry described in		ontent="Section 5.1"/>).
	<xref target='iana_dcep_registry'/>.</t>		This registration table is a subregistry within the registry described in
	<t>The assignment of new message types is done through an RFC Required action,		<xref target="iana_dcep_registry" format="default" sectionFormat="of" derivedCon
	as defined in <xref target='RFC8126'/>.		tent="Section 8.2"/>.</t>
	Documentation of the new Channel Type MUST contain the following information:		<t indent="0" pn="section-8.2.2-2">The assignment of new message types
	<list style="numbers">		is done through an RFC Required action,
	<t>A name for the new Channel Type;</t>		as defined in <xref target="RFC8126" format="default" sectionFormat="of" derived
	<t>A detailed procedural description of the user message handling for		Content="RFC8126"/>.
	data channels using this new Channel Type.</t>		Documentation of new Channel Types <bcp14>MUST</bcp14> contain the following inf
	</list>		ormation:
	Please note that if new Channel Types support ordered and unordered message		</t>
	delivery, the high-order bit MUST be used to indicate whether the message		<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-
	delivery is unordered or not.</t>		8.2.2-3">
	<t>Initially, the following values need to be registered:</t>		<li pn="section-8.2.2-3.1" derivedCounter="1.">A name for the new Ch
	<texttable>		annel Type.</li>
	<ttcol align='left'>Name</ttcol>		<li pn="section-8.2.2-3.2" derivedCounter="2.">A detailed procedural
	<ttcol align='left'>Type</ttcol>		description of the user message handling for
	<ttcol align='left'>Reference</ttcol>		data channels using this new Channel Type.</li>
	<c>DATA_CHANNEL_RELIABLE</c> <c>0x00</c> <c>[RFCXXXX]</		</ol>
	c>		<t indent="0" pn="section-8.2.2-4">
	<c>DATA_CHANNEL_RELIABLE_UNORDERED</c> <c>0x80</c> <c>[RFCXXXX]</		If new Channel Types support ordered and unordered message
	c>		delivery, the high-order bit <bcp14>MUST</bcp14> be used to indicate whether
	<c>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT</c> <c>0x01</c> <c>[RFCXXXX]</		or not the message delivery is unordered.</t>
	c>		<t indent="0" pn="section-8.2.2-5">The following are the initial regis
	<c>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED</c> <c>0x81</c> <c>[RFCXXXX]</		trations:</t>
	c>		<table align="center" pn="table-4">
	<c>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED</c> <c>0x02</c> <c>[RFCXXXX]</		<thead>
	c>		<tr>
	<c>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED</c> <c>0x82</c> <c>[RFCXXXX]</		<th align="left" colspan="1" rowspan="1">Name</th>
	c>		<th align="left" colspan="1" rowspan="1">Type</th>
	<c>Reserved</c> <c>0x7f</c> <c>[RFCXXXX]</		<th align="left" colspan="1" rowspan="1">Reference</th>
	c>		</tr>
	<c>Reserved</c> <c>0xff</c> <c>[RFCXXXX]</		</thead>
	c>		<tbody>
	<c>Unassigned</c> <c>rest</c> <c> </		<tr>
	c>		<td align="left" colspan="1" rowspan="1">DATA_CHANNEL_RELIABLE</
	</texttable>		td>
	<t>Please note that the values 0x7f and 0xff have been reserved for future		<td align="left" colspan="1" rowspan="1">0x00</td>
			<td align="left" colspan="1" rowspan="1">RFC 8832</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">DATA_CHANNEL_RELIABLE_U
			NORDERED</td>
			<td align="left" colspan="1" rowspan="1">0x80</td>
			<td align="left" colspan="1" rowspan="1">RFC 8832</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">DATA_CHANNEL_PARTIAL_RE
			LIABLE_REXMIT</td>
			<td align="left" colspan="1" rowspan="1">0x01</td>
			<td align="left" colspan="1" rowspan="1">RFC 8832</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">DATA_CHANNEL_PARTIAL_RE
			LIABLE_REXMIT_UNORDERED</td>
			<td align="left" colspan="1" rowspan="1">0x81</td>
			<td align="left" colspan="1" rowspan="1">RFC 8832</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">DATA_CHANNEL_PARTIAL_RE
			LIABLE_TIMED</td>
			<td align="left" colspan="1" rowspan="1">0x02</td>
			<td align="left" colspan="1" rowspan="1">RFC 8832</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">DATA_CHANNEL_PARTIAL_RE
			LIABLE_TIMED_UNORDERED</td>
			<td align="left" colspan="1" rowspan="1">0x82</td>
			<td align="left" colspan="1" rowspan="1">RFC 8832</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">Reserved</td>
			<td align="left" colspan="1" rowspan="1">0x7f</td>
			<td align="left" colspan="1" rowspan="1">RFC 8832</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">Reserved</td>
			<td align="left" colspan="1" rowspan="1">0xff</td>
			<td align="left" colspan="1" rowspan="1">RFC 8832</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">Unassigned</td>
			<td align="left" colspan="1" rowspan="1">rest</td>
			<td align="left" colspan="1" rowspan="1"> </td>
			</tr>
			</tbody>
			</table>
			<t indent="0" pn="section-8.2.2-7">Values 0x7f and 0xff have been rese
			rved 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>
			<displayreference target="I-D.ietf-tls-dtls13" to="TLS-DTLS13"/>
	<back>		<references pn="section-9">
	<references title='Normative References'>		<name slugifiedName="name-references">References</name>
	<?rfc include='reference.RFC.2119'?>		<references pn="section-9.1">
	<?rfc include='reference.RFC.8174'?>		<name slugifiedName="name-normative-references">Normative References</na
	<?rfc include='reference.RFC.3629'?>		me>
	<?rfc include='reference.RFC.4347'?>		<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	<?rfc include='reference.RFC.4960'?>		119" quoteTitle="true" derivedAnchor="RFC2119">
	<?rfc include='reference.RFC.8126'?>		<front>
	<?rfc include='reference.RFC.6347'?>		<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	<?rfc include='reference.RFC.8261'?>		le>
			<author initials="S." surname="Bradner" fullname="S. Bradner">
	<reference anchor="RFCYYYY" target="https://www.rfc-editor.org/info/rfcYYYY">		<organization showOnFrontPage="true"/>
	<front>		</author>
	<title>WebRTC Data Channels</title>		<date year="1997" month="March"/>
	<author initials='R' surname='Jesup' fullname='Randell Jesup'>		<abstract>
	<organization/>		<t indent="0">In many standards track documents several words are
	</author>		used to signify the requirements in the specification. These words are often ca
	<author initials='S' surname='Loreto' fullname='Salvatore Loreto'>		pitalized. This document defines these words as they should be interpreted in IE
	<organization/>		TF documents. This document specifies an Internet Best Current Practices for th
	</author>		e Internet Community, and requests discussion and suggestions for improvements.<
	<author initials='M' surname='Tuexen' fullname='Michael Tuexen'>		/t>
	<organization/>		</abstract>
	</author>		</front>
	<date month='October' year='2018'/>		<seriesInfo name="BCP" value="14"/>
	</front>		<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="RFC" value="YYYY"/>		<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	<seriesInfo name="DOI" value="10.17487/RFCYYYY"/>		</reference>
	</reference>		<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
			174" quoteTitle="true" derivedAnchor="RFC8174">
	</references>		<front>
			<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	<references title='Informative References'>		tle>
	<?rfc include='reference.RFC.6455'?>		<author initials="B." surname="Leiba" fullname="B. Leiba">
			<organization showOnFrontPage="true"/>
	<!-- draft-ietf-rtcweb-security-10 exists -->		</author>
	<reference anchor='SECURITY'>		<date year="2017" month="May"/>
	<front>		<abstract>
	<title>Security Considerations for WebRTC</title>		<t indent="0">RFC 2119 specifies common key words that may be used
	<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>		in protocol specifications. This document aims to reduce the ambiguity by cla
	<organization />		rifying that only UPPERCASE usage of the key words have the defined special mea
	</author>		nings.</t>
			</abstract>
	<date month='January' day='22' year='2018' />		</front>
			<seriesInfo name="BCP" value="14"/>
	</front>		<seriesInfo name="RFC" value="8174"/>
			<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	<seriesInfo name='Work in Progress,' value='draft-ietf-rtcweb-security-10' />		</reference>
			<reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3
	</reference>		629" quoteTitle="true" derivedAnchor="RFC3629">
			<front>
	<!-- draft-ietf-rtcweb-security-arch-15 exists -->		<title>UTF-8, a transformation format of ISO 10646</title>
	<reference anchor='SECURITY-ARCH'>		<author initials="F." surname="Yergeau" fullname="F. Yergeau">
	<front>		<organization showOnFrontPage="true"/>
	<title>WebRTC Security Architecture</title>		</author>
			<date year="2003" month="November"/>
	<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>		<abstract>
	<organization />		<t indent="0">ISO/IEC 10646-1 defines a large character set called
	</author>		the Universal Character Set (UCS) which encompasses most of the world's writing
			systems. The originally proposed encodings of the UCS, however, were not compa
	<date month='July' day='17' year='2018' />		tible with many current applications and protocols, and this has led to the deve
			lopment of UTF-8, the object of this memo. UTF-8 has the characteristic of pres
	</front>		erving the full US-ASCII range, providing compatibility with file systems, parse
			rs and other software that rely on US-ASCII values but are transparent to other
	<seriesInfo name='Work in Progress,' value='draft-ietf-rtcweb-security-arch-15'		values. This memo obsoletes and replaces RFC 2279.</t>
	/>		</abstract>
			</front>
			<seriesInfo name="STD" value="63"/>
			<seriesInfo name="RFC" value="3629"/>
			<seriesInfo name="DOI" value="10.17487/RFC3629"/>
			</reference>
			<reference anchor="RFC4960" target="https://www.rfc-editor.org/info/rfc4
			960" quoteTitle="true" derivedAnchor="RFC4960">
			<front>
			<title>Stream Control Transmission Protocol</title>
			<author initials="R." surname="Stewart" fullname="R. Stewart" role="
			editor">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2007" month="September"/>
			<abstract>
			<t indent="0">This document obsoletes RFC 2960 and RFC 3309. It d
			escribes the Stream Control Transmission Protocol (SCTP). SCTP is designed to t
			ransport Public Switched Telephone Network (PSTN) signaling messages over IP net
			works, but is capable of broader applications.</t>
			<t indent="0">SCTP is a reliable transport protocol operating on t
			op of a connectionless packet network such as IP. It offers the following servi
			ces to its users:</t>
			<t indent="0">-- acknowledged error-free non-duplicated transfer
			of user data,</t>
			<t indent="0">-- data fragmentation to conform to discovered path
			MTU size,</t>
			<t indent="0">-- sequenced delivery of user messages within multi
			ple streams, with an option for order-of-arrival delivery of individual user mes
			sages,</t>
			<t indent="0">-- optional bundling of multiple user messages into
			a single SCTP packet, and</t>
			<t indent="0">-- network-level fault tolerance through supporting
			of multi-homing at either or both ends of an association.</t>
			<t indent="0"> The design of SCTP includes appropriate congestion
			avoidance behavior and resistance to flooding and masquerade attacks. [STANDARD
			S-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4960"/>
			<seriesInfo name="DOI" value="10.17487/RFC4960"/>
			</reference>
			<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
			126" quoteTitle="true" derivedAnchor="RFC8126">
			<front>
			<title>Guidelines for Writing an IANA Considerations Section in RFCs
			</title>
			<author initials="M." surname="Cotton" fullname="M. Cotton">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="B." surname="Leiba" fullname="B. Leiba">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="T." surname="Narten" fullname="T. Narten">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2017" month="June"/>
			<abstract>
			<t indent="0">Many protocols make use of points of extensibility t
			hat use constants to identify various protocol parameters. To ensure that the v
			alues in these fields do not have conflicting uses and to promote interoperabili
			ty, their allocations are often coordinated by a central record keeper. For IET
			F protocols, that role is filled by the Internet Assigned Numbers Authority (IAN
			A).</t>
			<t indent="0">To make assignments in a given registry prudently, g
			uidance describing the conditions under which new values should be assigned, as
			well as when and how modifications to existing values can be made, is needed. T
			his document defines a framework for the documentation of these guidelines by sp
			ecification authors, in order to assure that the provided guidance for the IANA
			Considerations is clear and addresses the various issues that are likely in the
			operation of a registry.</t>
			<t indent="0">This is the third edition of this document; it obsol
			etes RFC 5226.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="26"/>
			<seriesInfo name="RFC" value="8126"/>
			<seriesInfo name="DOI" value="10.17487/RFC8126"/>
			</reference>
			<reference anchor="RFC8261" target="https://www.rfc-editor.org/info/rfc8
			261" quoteTitle="true" derivedAnchor="RFC8261">
			<front>
			<title>Datagram Transport Layer Security (DTLS) Encapsulation of SCT
			P Packets</title>
			<author initials="M." surname="Tuexen" fullname="M. Tuexen">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R." surname="Stewart" fullname="R. Stewart">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R." surname="Jesup" fullname="R. Jesup">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="S." surname="Loreto" fullname="S. Loreto">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2017" month="November"/>
			<abstract>
			<t indent="0">The Stream Control Transmission Protocol (SCTP) is a
			transport protocol originally defined to run on top of the network protocols IP
			v4 or IPv6. This document specifies how SCTP can be used on top of the Datagram
			Transport Layer Security (DTLS) protocol. Using the encapsulation method descr
			ibed in this document, SCTP is unaware of the protocols being used below DTLS; h
			ence, explicit IP addresses cannot be used in the SCTP control chunks. As a con
			sequence, the SCTP associations carried over DTLS can only be single-homed.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="8261"/>
			<seriesInfo name="DOI" value="10.17487/RFC8261"/>
			</reference>
			<reference anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8
			831" quoteTitle="true" derivedAnchor="RFC8831">
			<front>
			<title>WebRTC Data Channels</title>
			<author initials="R" surname="Jesup" fullname="Randell Jesup">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="S" surname="Loreto" fullname="Salvatore Loreto">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="M" surname="Tüxen" fullname="Michael Tüxen">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8831"/>
			<seriesInfo name="DOI" value="10.17487/RFC8831"/>
			</reference>
			</references>
			<references pn="section-9.2">
			<name slugifiedName="name-informative-references">Informative References
			</name>
			<reference anchor="RFC4347" target="https://www.rfc-editor.org/info/rfc4
			347" quoteTitle="true" derivedAnchor="RFC4347">
			<front>
			<title>Datagram Transport Layer Security</title>
			<author initials="E." surname="Rescorla" fullname="E. Rescorla">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="N." surname="Modadugu" fullname="N. Modadugu">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2006" month="April"/>
			<abstract>
			<t indent="0">This document specifies Version 1.0 of the Datagram
			Transport Layer Security (DTLS) protocol. The DTLS protocol provides communicat
			ions privacy for datagram protocols. The protocol allows client/server applicat
			ions to communicate in a way that is designed to prevent eavesdropping, tamperin
			g, or message forgery. The DTLS protocol is based on the Transport Layer Securi
			ty (TLS) protocol and provides equivalent security guarantees. Datagram semanti
			cs of the underlying transport are preserved by the DTLS protocol. [STANDARDS-T
			RACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4347"/>
			<seriesInfo name="DOI" value="10.17487/RFC4347"/>
			</reference>
			<reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6
			347" quoteTitle="true" derivedAnchor="RFC6347">
			<front>
			<title>Datagram Transport Layer Security Version 1.2</title>
			<author initials="E." surname="Rescorla" fullname="E. Rescorla">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="N." surname="Modadugu" fullname="N. Modadugu">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2012" month="January"/>
			<abstract>
			<t indent="0">This document specifies version 1.2 of the Datagram
			Transport Layer Security (DTLS) protocol. The DTLS protocol provides communicat
			ions privacy for datagram protocols. The protocol allows client/server applicat
			ions to communicate in a way that is designed to prevent eavesdropping, tamperin
			g, or message forgery. The DTLS protocol is based on the Transport Layer Securi
			ty (TLS) protocol and provides equivalent security guarantees. Datagram semanti
			cs of the underlying transport are preserved by the DTLS protocol. This documen
			t updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="6347"/>
			<seriesInfo name="DOI" value="10.17487/RFC6347"/>
			</reference>
			<reference anchor="RFC6455" target="https://www.rfc-editor.org/info/rfc6
			455" quoteTitle="true" derivedAnchor="RFC6455">
			<front>
			<title>The WebSocket Protocol</title>
			<author initials="I." surname="Fette" fullname="I. Fette">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="A." surname="Melnikov" fullname="A. Melnikov">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2011" month="December"/>
			<abstract>
			<t indent="0">The WebSocket Protocol enables two-way communication
			between a client running untrusted code in a controlled environment to a remote
			host that has opted-in to communications from that code. The security model us
			ed for this is the origin-based security model commonly used by web browsers. T
			he protocol consists of an opening handshake followed by basic message framing,
			layered over TCP. The goal of this technology is to provide a mechanism for bro
			wser-based applications that need two-way communication with servers that does n
			ot rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or &lt;
			iframe&gt;s and long polling). [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="6455"/>
			<seriesInfo name="DOI" value="10.17487/RFC6455"/>
			</reference>
			<reference anchor="RFC8826" target="https://www.rfc-editor.org/info/rfc8
			826" quoteTitle="true" derivedAnchor="RFC8826">
			<front>
			<title>Security Considerations for WebRTC</title>
			<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8826"/>
			<seriesInfo name="DOI" value="10.17487/RFC8826"/>
			</reference>
			<reference anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8
			827" quoteTitle="true" derivedAnchor="RFC8827">
			<front>
			<title>WebRTC Security Architecture</title>
			<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8827"/>
			<seriesInfo name="DOI" value="10.17487/RFC8827"/>
			</reference>
			<reference anchor="I-D.ietf-tls-dtls13" quoteTitle="true" target="https:
			//tools.ietf.org/html/draft-ietf-tls-dtls13-39" derivedAnchor="TLS-DTLS13">
			<front>
			<title>The Datagram Transport Layer Security (DTLS) Protocol Version
			1.3</title>
			<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
			<organization showOnFrontPage="true">RTFM, Inc.</organization>
			</author>
			<author initials="H." surname="Tschofenig" fullname="Hannes Tschofen
			ig">
			<organization showOnFrontPage="true">Arm Limited</organization>
			</author>
			<author initials="N." surname="Modadugu" fullname="Nagendra Modadugu
			">
			<organization showOnFrontPage="true">Google, Inc.</organization>
			</author>
			<date month="November" day="2" year="2020"/>
			<abstract>
			<t indent="0"> This document specifies Version 1.3 of the Datagr
			am Transport Layer
			Security (DTLS) protocol. DTLS 1.3 allows client/server applications
			to communicate over the Internet in a way that is designed to prevent
			eavesdropping, tampering, and message forgery.
	</reference>		The DTLS 1.3 protocol is intentionally based on the Transport Layer
			Security (TLS) 1.3 protocol and provides equivalent security
			guarantees with the exception of order protection/non-replayability.
			Datagram semantics of the underlying transport are preserved by the
			DTLS protocol.
	</references>		</t>
	<section title='Acknowledgments' numbered="no">		</abstract>
	<t>The authors wish to thank		</front>
	Harald Alvestrand,		<seriesInfo name="Internet-Draft" value="draft-ietf-tls-dtls13-39"/>
	Richard Barnes,		<format type="TXT" target="https://www.ietf.org/internet-drafts/draft-
	Adam Bergkvist,		ietf-tls-dtls13-39.txt"/>
	Spencer Dawkins,		<refcontent>Work in Progress</refcontent>
	Barry Dingle,		</reference>
	Stefan Haekansson,		</references>
	Cullen Jennings,		</references>
	Paul Kyzivat,		<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
	Doug Leonard,		ndix.a">
	Alexey Melnikov,		<name slugifiedName="name-acknowledgements">Acknowledgements</name>
	Pete Resnick,		<t indent="0" pn="section-appendix.a-1">The authors wish to thank
	Irene Ruengeler,		<contact fullname="Harald Alvestrand"/>,
	Randall Stewart,		<contact fullname="Richard Barnes"/>,
	Peter Thatcher,		<contact fullname="Adam Bergkvist"/>,
	Martin Thompson,		<contact fullname="Spencer Dawkins"/>,
	Justin Uberti,		<contact fullname="Barry Dingle"/>,
			<contact fullname="Stefan Håkansson"/>,
			<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 Thomson"/>,
			<contact fullname="Justin Uberti"/>,
	and many others for their invaluable comments.</t>		and many others for their invaluable comments.</t>
	</section>		</section>
	</back>		<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
			="include" pn="section-appendix.b">
			<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
			<author initials="R." surname="Jesup" fullname="Randell Jesup">
			<organization showOnFrontPage="true">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 showOnFrontPage="true">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" showOnFrontPage="
			true">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>
			</section>
			</back>
	</rfc>		</rfc>
End of changes. 57 change blocks.
	533 lines changed or deleted		1193 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/