rfc8833xml2.original.xml		rfc8833.xml
	<?xml version="1.0"?>		<?xml version='1.0' encoding='utf-8'?>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>		<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
	<?rfc strict="yes" ?>
	<?rfc toc="yes"?>
	<?rfc tocdepth="4"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes" ?>
	<?rfc compact="yes" ?>
	<?rfc subcompact="no" ?>
	<rfc category="std" ipr="trust200902" docName="draft-ietf-rtcweb-alpn-04">		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8833"
			docName="draft-ietf-rtcweb-alpn-04" category="std"
			submissionType="IETF" consensus="yes" ipr="trust200902" obsoletes=""
			updates="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true"
			sortRefs="true" version="3">
			<!-- xml2rfc v2v3 conversion 2.44.0 -->
	<front>		<front>
	<title abbrev="ALPN for WebRTC">		<title abbrev="ALPN for WebRTC">
	Application Layer Protocol Negotiation for Web Real-Time Communications (W ebRTC)		Application-Layer Protocol Negotiation (ALPN) for WebRTC
	</title>		</title>
			<seriesInfo name="RFC" value="8833"/>
	<author initials="M." surname="Thomson" fullname="Martin Thomson">		<author initials="M." surname="Thomson" fullname="Martin Thomson">
	<organization>Mozilla</organization>		<organization>Mozilla</organization>
	<address>		<address>
	<postal>		<postal/>
	<street>331 E Evelyn Street</street>
	<city>Mountain View</city>
	<region>CA</region>
	<code>94041</code>
	<country>US</country>
	</postal>
	<email>martin.thomson@gmail.com</email>		<email>martin.thomson@gmail.com</email>
	</address>		</address>
	</author>		</author>
			<date month="June" year="2020"/>
	<date year="2016"/>		<area>ART</area>
	<area>RAI</area>
	<workgroup>RTCWEB</workgroup>		<workgroup>RTCWEB</workgroup>
	<keyword>Internet-Draft</keyword>
	<keyword>ALPN</keyword>		<keyword>ALPN</keyword>
	<keyword>Protocol</keyword>		<keyword>Protocol</keyword>
	<keyword>Identifier</keyword>		<keyword>Identifier</keyword>
	<abstract>		<abstract>
	<t>		<t>
	This document specifies two Application Layer Protocol Negotiation (ALPN		This document specifies two Application-Layer Protocol Negotiation (ALPN
	) labels for use		) labels for use
	with Web Real-Time Communications (WebRTC). The "webrtc" label identifi		with Web Real-Time Communication (WebRTC). The "webrtc" label identifie
	es regular WebRTC		s regular WebRTC:
	communications: a DTLS session that is used establish keys for Secure Re		a DTLS session that is used to establish keys for the Secure Real-time T
	al-time Transport		ransport
	Protocol (SRTP) or to establish data channels using SCTP over DTLS. The		Protocol (SRTP) or to establish data channels using the Stream Control
	"c-webrtc" label		Transmission Protocol (SCTP) over DTLS. The "c-webrtc" label
	describes the same protocol, but the peers also agree to maintain the co nfidentiality of the		describes the same protocol, but the peers also agree to maintain the co nfidentiality of the
	media by not sharing it with other applications.		media by not sharing it with other applications.
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
			<section anchor="intro" numbered="true" toc="default">
	<section anchor="intro" title="Introduction">		<name>Introduction</name>
	<t>		<t>
	<xref target="I-D.ietf-rtcweb-overview">Web Real-Time Communications (We		<xref target="RFC8825" format="default">Web Real-Time Communication (Web
	bRTC)</xref> uses		RTC)</xref> uses
	<xref target="RFC6347">Datagram Transport Layer Security (DTLS)</xref> t		<xref target="RFC6347" format="default">Datagram Transport Layer Securit
	o secure all		y (DTLS)</xref> to secure all
	peer-to-peer communications.		peer-to-peer communications.
	</t>		</t>
	<t>		<t>
	Identifying WebRTC protocol usage with <xref target="RFC7301">Applicatio n Layer Protocol		Identifying WebRTC protocol usage with <xref target="RFC7301" format="de fault">Application-Layer Protocol
	Negotiation (ALPN)</xref> enables an endpoint to positively identify Web RTC uses and		Negotiation (ALPN)</xref> enables an endpoint to positively identify Web RTC uses and
	distinguish them from other DTLS uses.		distinguish them from other DTLS uses.
	</t>		</t>
	<t>		<t>
	Different WebRTC uses can be advertised and behavior can be constrained to what is		Different WebRTC uses can be advertised and behavior can be constrained to what is
	appropriate to a given use. In particular, this allows for the identifi cation of sessions		appropriate to a given use. In particular, this allows for the identifi cation of sessions
	that require confidentiality protection from the application that manage s the signaling for		that require confidentiality protection from the application that manage s the signaling for
	the session.		the session.
	</t>		</t>
			<section anchor="terminology" numbered="true" toc="default">
	<section title="Conventions and Terminology" anchor="terminology">		<name>Conventions</name>
	<t>		<t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "S		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	HOULD", "SHOULD		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	document are to be		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	interpreted as described in <xref target="RFC2119"/>.		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
			be interpreted as
			described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="
			RFC8174" format="default"/>
			when, and only when, they appear in all capitals, as shown here.
	</t>		</t>
	</section>		</section>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="ALPN Labels for WebRTC">		<name>ALPN Labels for WebRTC</name>
	<t>		<t>
	The following identifiers are defined for use in ALPN:		The following identifiers are defined for use in ALPN:
	<list style="hanging">		</t>
	<t hangText="webrtc:">		<dl newline="false" spacing="normal">
	The DTLS session is used to establish keys for Secure Real-time Tran		<dt>webrtc:</dt>
	sport Protocol		<dd>
	(SRTP) - known as DTLS-SRTP - as described in <xref target="RFC5764"		The DTLS session is used to establish keys for the Secure Real-time
	/>. The DTLS record		Transport Protocol
	layer is used for <xref target="I-D.ietf-rtcweb-data-channel">WebRTC		(SRTP) -- known as DTLS-SRTP -- as described in <xref target="RFC576
	data		4" format="default"/>. The DTLS record
			layer is used for <xref target="RFC8831" format="default">WebRTC dat
			a
	channels</xref>.		channels</xref>.
	</t>		</dd>
	<t hangText="c-webrtc:">		<dt>c-webrtc:</dt>
	The DTLS session is used for confidential WebRTC communications, whe		<dd>
	re peers agree to		The DTLS session is used for confidential WebRTC, where peers agree
	maintain the confidentiality of the media, as described in <xref		to
	target="confidentiality"/>. The confidentiality protections ensure t		maintain the confidentiality of the media, as described in <xref tar
	hat media is		get="confidentiality" format="default"/>. The confidentiality protections ensure
			that media is
	protected from other applications, but the confidentiality protectio ns do not extend to		protected from other applications, but the confidentiality protectio ns do not extend to
	messages on data channels.		messages on data channels.
	</t>		</dd>
	</list>		</dl>
	</t>
	<t>		<t>
	Both identifiers describe the same basic protocol: a DTLS session that i s used to provide		Both identifiers describe the same basic protocol: a DTLS session that i s used to provide
	keys for an SRTP session in combination with WebRTC data channels. Eith er SRTP or data		keys for an SRTP session in combination with WebRTC data channels. Eith er SRTP or data
	channels could be absent. The data channels send <xref target="RFC4960" >Stream Control		channels could be absent. The data channels send the <xref target="RFC4 960" format="default">Stream Control
	Transmission Protocol (SCTP)</xref> over the DTLS record layer, which ca n be multiplexed		Transmission Protocol (SCTP)</xref> over the DTLS record layer, which ca n be multiplexed
	with SRTP on the same UDP flow. WebRTC requires the use of <xref		with SRTP on the same UDP flow. WebRTC requires the use of <xref target
	target="RFC5245">Interactive Communication Establishment (ICE)</xref> to		="RFC8445" format="default">Interactive Connectivity Establishment (ICE)</xref>
	establish the UDP		to establish UDP
	flow, but this is not covered by the identifier.		flow, but this is not covered by the identifier.
	</t>		</t>
	<t>		<t>
	A more thorough definition of what WebRTC communications entail is inclu		A more thorough definition of what WebRTC entails is included in <xref t
	ded in <xref		arget="RFC8835" format="default"/>.
	target="I-D.ietf-rtcweb-transports"/>.
	</t>		</t>
	<t>		<t>
	There is no functional difference between the identifiers except that an endpoint		There is no functional difference between the identifiers except that an endpoint
	negotiating <spanx style="verb">c-webrtc</spanx> makes a promise to pres erve the		negotiating <tt>c-webrtc</tt> makes a promise to preserve the
	confidentiality of the media it receives.		confidentiality of the media it receives.
	</t>		</t>
	<t>		<t>
	A peer that is not aware of whether it needs to request confidentiality can use either		A peer that is not aware of whether it needs to request confidentiality can use either
	identifier. A peer in the client role MUST offer both identifiers if it		identifier. A peer in the client role <bcp14>MUST</bcp14> offer both id
	is not aware of a		entifiers if it is not aware of a
	need for confidentiality. A peer in the server role SHOULD select <spanx		need for confidentiality. A peer in the server role <bcp14>SHOULD</bcp14
	style="verb">webrtc</spanx> if it does not prefer either.		> select <tt>webrtc</tt> if it does not prefer either.
	</t>		</t>
	<t>		<t>
	An endpoint that requires media confidentiality might negotiate a sessio n with a peer that		An endpoint that requires media confidentiality might negotiate a sessio n with a peer that
	does not support this specification. Endpoint MUST abort a session if i		does not support this specification. An endpoint <bcp14>MUST</bcp14> ab
	t requires		ort a session if it requires
	confidentiality but does not successfully negotiate <spanx style="verb">		confidentiality but does not successfully negotiate <tt>c-webrtc</tt>.
	c-webrtc</spanx>. A		A
	peer that is willing to accept <spanx style="verb">webrtc</spanx> SHOULD		peer that is willing to accept <tt>webrtc</tt> <bcp14>SHOULD</bcp14> ass
	assume that a peer		ume that a peer
	that does not support this specification has negotiated <spanx style="ve		that does not support this specification has negotiated <tt>webrtc</tt>
	rb">webrtc</spanx>		unless signaling provides other information; however, a peer <bcp14>MUST
	unless signaling provides other information; however, a peer MUST NOT as		NOT</bcp14> assume that <tt>c-webrtc</tt> has been negotiated unless explicitly
	sume that <spanx		negotiated.
	style="verb">c-webrtc</spanx> has been negotiated unless explicitly nego
	tiated.
	</t>		</t>
	</section>		</section>
			<section anchor="confidentiality" numbered="true" toc="default">
	<section title="Media Confidentiality" anchor="confidentiality">		<name>Media Confidentiality</name>
	<t>		<t>
	Private communications in WebRTC depend on separating control (i.e., sig naling) capabilities		Private communications in WebRTC depend on separating control (i.e., sig naling) capabilities
	and access to media <xref target="I-D.ietf-rtcweb-security-arch"/>. In this way, an		and access to media <xref target="RFC8827" format="default"/>. In this way, an
	application can establish a session that is end-to-end confidential, whe re the ends in		application can establish a session that is end-to-end confidential, whe re the ends in
	question are user agents (or browsers) and not the signaling application . This allows an		question are user agents (or browsers) and not the signaling application . This allows an
	application to manage signaling for a session, without having access to the media that is		application to manage signaling for a session without having access to t he media that is
	exchanged in the session.		exchanged in the session.
	</t>		</t>
	<t>		<t>
	Without some form of indication that is securely bound to the session, a WebRTC endpoint is		Without some form of indication that is securely bound to the session, a WebRTC endpoint is
	unable to properly distinguish between a session that requires this conf identiality		unable to properly distinguish between a session that requires this conf identiality
	protection and one that does not. The ALPN identifier provides that sig nal.		protection and one that does not. The ALPN identifier provides that sig nal.
	</t>		</t>
	<t>		<t>
	A browser is required to enforce this confidentiality protection using i solation controls		A browser is required to enforce this confidentiality protection using i solation controls
	similar to those used in content cross-origin protections (see <eref		similar to those used in content cross-origin protections
	target="http://www.w3.org/TR/2012/CR-html5-20121217/browsers.html#origin		<!-- (see <xref
	">Section 5.3</eref>		target="HTML5" relative="#origin" section="5.3"
	of <xref target="HTML5"/>). These protections ensure that media is prot		format="default"/>). -->
	ected from		(see the "Origin" section of <xref target="HTML5"/>).
	applications. Applications are not able to read or modify the contents		These protections ensure that media is protected from
	of a protected flow		applications, which are not able to read or modify the contents of a pro
	of media. Media that is produced from a session using the <spanx		tected flow
	style="verb">c-webrtc</spanx> identifier MUST only be displayed to users		of media. Media that is produced from a session using the <tt>c-webrtc<
	.		/tt> identifier <bcp14>MUST</bcp14> only be displayed to users.
	</t>		</t>
	<t>		<t>
	The promise to apply confidentiality protections do not apply to data th at is sent using		The promise to apply confidentiality protections do not apply to data th at is sent using
	data channels. Confidential data depends on having both data sources an d consumers that are		data channels. Confidential data depends on having both data sources an d consumers that are
	exclusively browser- or user-based. No mechanisms currently exist to ta ke advantage of data		exclusively browser or user based. No mechanisms currently exist to tak e advantage of data
	confidentiality, though some use cases suggest that this could be useful , for example,		confidentiality, though some use cases suggest that this could be useful , for example,
	confidential peer-to-peer file transfer. Alternative labels might be pr		confidential peer-to-peer file transfer. Alternative labels might be
	ovided in future to		provided in the future to support these use cases.
	support these use cases.
	</t>		</t>
	<t>		<t>
	This mechanism explicitly does not define a specific authentication meth od; a WebRTC		This mechanism explicitly does not define a specific authentication meth od; a WebRTC
	endpoint that accepts a session with this ALPN identifier MUST respect c onfidentiality no		endpoint that accepts a session with this ALPN identifier <bcp14>MUST</b cp14> respect confidentiality no
	matter what identity is attributed to a peer.		matter what identity is attributed to a peer.
	</t>		</t>
	<t>		<t>
	RTP middleboxes and entities that forward media or data cannot promise t o maintain		RTP middleboxes and entities that forward media or data cannot promise t o maintain
	confidentiality. Any entity that forwards content, or records content f or later access by		confidentiality. Any entity that forwards content, or records content f or later access by
	entities other than the authenticated peer, MUST NOT offer or accept a s		entities other than the authenticated peer, <bcp14>MUST NOT</bcp14> offe
	ession with the		r or accept a session with the
	<spanx style="verb">c-webrtc</spanx> identifier.		<tt>c-webrtc</tt> identifier.
	</t>		</t>
	</section>		</section>
			<section anchor="security" numbered="true" toc="default">
	<section anchor="security" title="Security Considerations">		<name>Security Considerations</name>
	<t>		<t>
	Confidential communications depends on more than just an agreement from browsers.		Confidential communications depend on more than just an agreement from b rowsers.
	</t>		</t>
	<t>		<t>
	Information is not confidential if it is displayed to those other than t		Information is not confidential if it is displayed to others than for wh
	o whom it is		om it is
	intended. <xref target="I-D.ietf-rtcweb-security-arch">Peer authenticat		intended. <xref target="RFC8827" format="default">Peer authentication</
	ion</xref> is		xref> is
	necessary to ensure that data is only sent to the intended peer.		necessary to ensure that data is only sent to the intended peer.
	</t>		</t>
	<t>		<t>
	This is not a digital rights management mechanism. A user is not preven		This is not a digital rights management mechanism. A user is not prevent
	ted from using other		ed from using other
	mechanisms to record or forward media. This means that (for example) sc		mechanisms to record or forward media. This means that (for example) sc
	reen recording		reen-recording
	devices, tape recorders, portable cameras, or a cunning arrangement of m irrors could		devices, tape recorders, portable cameras, or a cunning arrangement of m irrors could
	variously be used to record or redistribute media once delivered. Simil arly, if media is		variously be used to record or redistribute media once delivered. Simil arly, if media is
	visible or audible (or otherwise accessible) to others in the vicinity, there are no		visible or audible (or otherwise accessible) to others in the vicinity, there are no
	technical measures that protect the confidentiality of that media.		technical measures that protect the confidentiality of that media.
	</t>		</t>
	<t>		<t>
	The only guarantee provided by this mechanism and the browser that imple ments it is that the		The only guarantee provided by this mechanism and the browser that imple ments it is that the
	media was delivered to the user that was authenticated. Individual user s will still need to		media was delivered to the user that was authenticated. Individual user s will still need to
	make a judgment about how their peer intends to respect the confidential ity of any		make a judgment about how their peer intends to respect the confidential ity of any
	information provided.		information provided.
	</t>		</t>
	<t>		<t>
	On a shared computing platform like a browser, other entities with acces s to that platform		On a shared computing platform like a browser, other entities with acces s to that platform
	(i.e., web applications), might be able to access information that would		(i.e., web applications) might be able to access information that would
	compromise the		compromise the
	confidentiality of communications. Implementations MAY choose to limit		confidentiality of communications. Implementations <bcp14>MAY</bcp14> c
	concurrent access to		hoose to limit concurrent access to
	input devices during confidential communications sessions.		input devices during confidential communications sessions.
	</t>		</t>
	<t>		<t>
	For instance, another application that is able to access a microphone mi ght be able to		For instance, another application that is able to access a microphone mi ght be able to
	sample confidential audio that is playing through speakers. This is tru e even if acoustic		sample confidential audio that is playing through speakers. This is tru e even if acoustic
	echo cancellation, which attempts to prevent this from happening, is use d. Similarly, an		echo cancellation, which attempts to prevent this from happening, is use d. Similarly, an
	application with access to a video camera might be able to use reflectio ns to obtain all or		application with access to a video camera might be able to use reflectio ns to obtain all or
	part of a confidential video stream.		part of a confidential video stream.
	</t>		</t>
	</section>		</section>
			<section anchor="iana" numbered="true" toc="default">
	<section anchor="iana" title="IANA Considerations">		<name>IANA Considerations</name>
	<t>		<t>
	The following two entries are added to the "Application Layer Protocol N		The following two entries have been added to the "TLS Application-Layer
	egotiation (ALPN)		Protocol Negotiation (ALPN) Protocol IDs" registry established by
	Protocol IDs" registry established by <xref target="RFC7301"/>:		<xref target="RFC7301" format="default"/>:
	<list style="hanging">		</t>
	<t hangText="webrtc:">		<dl newline="true" spacing="normal">
	<vspace blankLines="1"/>		<dt>webrtc:</dt>
	The <spanx style="verb">webrtc</spanx> label identifies mixed media		<dd>
	and data		<t>
			The <tt>webrtc</tt> label identifies mixed media and data
	communications using SRTP and data channels:		communications using SRTP and data channels:
	<list style="hanging">
	<t hangText="Protocol:">WebRTC Media and Data</t>
	<t hangText="Identification Sequence:">0x77 0x65 0x62 0x72 0x74 0x
	63 ("webrtc")</t>
	<t hangText="Specification:">This document (RFCXXXX)</t>
	</list>
	</t>		</t>
	<t hangText="c-webrtc:">		<dl newline="false" spacing="normal">
	<vspace blankLines="1"/>		<dt>Protocol:</dt>
	The <spanx style="verb">c-webrtc</spanx> label identifies WebRTC		<dd>WebRTC Media and Data</dd>
	communications with a promise to protect media confidentiality:		<dt>Identification Sequence:</dt>
	<list style="hanging">		<dd>0x77 0x65 0x62 0x72 0x74 0x63 ("webrtc")</dd>
	<t hangText="Protocol:">Confidential WebRTC Media and Data</t>		<dt>Specification:</dt>
	<t hangText="Identification Sequence:">0x63 0x2d 0x77 0x65 0x62 0x		<dd>RFC 8833 (this document)</dd>
	72 0x74 0x63		</dl>
	("c-webrtc")</t>		</dd>
	<t hangText="Specification:">This document (RFCXXXX)</t>		<dt>c-webrtc:</dt>
	</list>		<dd>
			<t>
			The <tt>c-webrtc</tt> label identifies WebRTC
			with a promise to protect media confidentiality:
	</t>		</t>
	</list>		<dl newline="false" spacing="normal">
	</t>		<dt>Protocol:</dt>
			<dd>Confidential WebRTC Media and Data</dd>
			<dt>Identification Sequence:</dt>
			<dd>0x63 0x2d 0x77 0x65 0x62 0x72 0x74 0x63
			("c-webrtc")</dd>
			<dt>Specification:</dt>
			<dd>RFC 8833 (this document)</dd>
			</dl>
			</dd>
			</dl>
	</section>		</section>
	<!--
	<appendix title="Change Log">
	<t>[[The RFC Editor is requested to remove this section at publication.]
	]</t>
	<t>Changes since -0-1:
	<list style="symbols">
	<t>Document created.</t>
	</list>
	</t>
	</appendix>
	-->
	</middle>		</middle>
	<back>		<back>
			<references>
			<name>References</name>
			<references>
			<name>Normative References</name>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.2119.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.8174.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.6347.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.5764.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
			ence.RFC.7301.xml"/>
	<references title="Normative References">		<!--draft-ietf-rtcweb-security-arch: 8827 -->
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.211		<reference anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8827">
	9.xml"?>		<front>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.634		<title>WebRTC Security Architecture</title>
	7.xml"?>		<seriesInfo name="RFC" value="8827"/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.576		<seriesInfo name="DOI" value="10.17487/RFC8827"/>
	4.xml"?>		<author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.730		<organization/>
	1.xml"?>		</author>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie		<date month='June' year='2020'/>
	tf-rtcweb-security-arch.xml"?>		</front>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie		</reference>
	tf-rtcweb-data-channel.xml"?>
	</references>
	<references title="Informative References">		<!-- draft-ietf-rtcweb-data-channel: 8831 -->
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.496		<reference anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8831">
	0.xml"?>		<front>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.524		<title>WebRTC Data Channels</title>
	5.xml"?>		<seriesInfo name="RFC" value="8831"/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie		<seriesInfo name="DOI" value="10.17487/RFC8831"/>
	tf-rtcweb-overview.xml"?>		<author initials="R." surname="Jesup" fullname="Randell Jesup">
	<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie		<organization/>
	tf-rtcweb-transports.xml"?>		</author>
	<reference anchor="HTML5" target="http://www.w3.org/TR/2012/CR-html5-20121		<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
	217/">		<organization/>
	<front>		</author>
	<title>		<author initials="M." surname="Tüxen" fullname="Michael Tüxen">
	HTML 5		<organization/>
	</title>		</author>
	<author initials="R." surname="Berjon" fullname="Robin Berjon"/>		<date month='June' year='2020'/>
	<author initials="T." surname="Leithead" fullname="Travis Leithead"/>		</front>
	<author initials="E." surname="Doyle Navara" fullname="Erika Doyle Nav		</reference>
	ara"/>
	<author initials="E." surname="O'Connor" fullname="Edward O'Connor"/>		</references>
	<author initials="S." surname="Pfeiffer" fullname="Silvia Pfeiffer"/>		<references>
	<date year="2010" month="August"/>		<name>Informative References</name>
	</front>		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	<seriesInfo name="CR" value="CR-html5-20121217"/>		FC.4960.xml"/>
	</reference>		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
			FC.8445.xml"/>
			<!-- draft-ietf-rtcweb-overview: RFC 8825 -->
			<reference anchor="RFC8825" target="https://www.rfc-editor.org/info/rfc8825">
			<front>
			<title>Overview: Real-Time Protocols for Browser-Based Applications</title>
			<seriesInfo name="RFC" value="8825" />
			<seriesInfo name="DOI" value="10.17487/RFC8825"/>
			<author initials="H." surname="Alvestrand" fullname="Harald T. Alvestrand">
			<organization />
			</author>
			<date month="June" year="2020" />
			</front>
			</reference>
			<!-- draft-ietf-rtcweb-transports-17: 8835 -->
			<reference anchor="RFC8835" target="https://www.rfc-editor.org/info/rfc8835">
			<front>
			<title>Transports for WebRTC</title>
			<seriesInfo name="RFC" value="8835" />
			<seriesInfo name="DOI" value="10.17487/RFC8835"/>
			<author initials="H." surname="Alvestrand" fullname="Harald Alvestrand">
			<organization />
			</author>
			<date month="June" year="2020" />
			</front>
			</reference>
			<reference anchor="HTML5" target="https://html.spec.whatwg.org/#origin">
			<front>
			<title>HTML - Living Standard</title>
			<author>
			<organization>WHATWG</organization>
			</author>
			<date month="June" year="2020" />
			</front>
			<refcontent>Section 7.5</refcontent>
			</reference>
			</references>
	</references>		</references>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 48 change blocks.
	211 lines changed or deleted		245 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/