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 Application-Layer Protocol Negotiation (ALPN) for Web Real-Time
ebRTC) Communication (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> <street>331 E Evelyn Street</street>
<city>Mountain View</city> <city>Mountain View</city>
<region>CA</region> <region>CA</region>
<code>94041</code> <code>94041</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>martin.thomson@gmail.com</email> <email>martin.thomson@gmail.com</email>
</address> </address>
</author> </author>
<date month="May" 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>
<!-- [rfced] WebRTC was marked as common at the end of 2019. Do you want
the expansion to remain in this document, or do you want to remove it
(including the title)?
If WebRTC is expanded, may we remove "communications" from instances of "WebRTC
communications", as 'C' in WebRTC already stands for "communications"? For
example
Original:
The "webrtc" label identifies regular WebRTC communications: a DTLS
session that is..."
Perhaps:
The "webrtc" label identifies regular WebRTC: a DTLS
session that is...
-->
<abstract> <abstract>
<t> <t>
This document specifies two Application Layer Protocol Negotiation (ALPN ) labels for use This document specifies two Application-Layer Protocol Negotiation (ALPN ) labels for use
with Web Real-Time Communications (WebRTC). The "webrtc" label identifi es regular WebRTC with Web Real-Time Communications (WebRTC). The "webrtc" label identifi es regular WebRTC
communications: a DTLS session that is used establish keys for Secure Re communications: a DTLS session that is used to establish keys for the Se
al-time Transport cure Real-time Transport
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 Communications (We
bRTC)</xref> uses bRTC)</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>
<dd>
The DTLS session is used for confidential WebRTC communications, whe re peers agree to The DTLS session is used for confidential WebRTC communications, whe re peers agree to
maintain the confidentiality of the media, as described in <xref maintain the confidentiality of the media, as described in <xref tar
target="confidentiality"/>. The confidentiality protections ensure t get="confidentiality" format="default"/>. The confidentiality protections ensure
hat media is 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> <!-- [rfced] FYI: We updated the expansion for the acronym ICE from
"Interactive Communication Establishment" to "Interactive Connectivity
Establishment" per RFCs 5245 and 8445.
Original:
WebRTC requires the use of Interactive
Communication Establishment (ICE) [RFC5245] to establish the UDP
flow, but this is not covered by the identifier.
-->
<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 communications entail is inclu
ded in <xref ded in <xref target="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 (see <xref tar
target="http://www.w3.org/TR/2012/CR-html5-20121217/browsers.html#origin get="HTML5" relative="#origin" section="5.3" format="default"/>). These protect
">Section 5.3</eref> ions ensure that media is protected from
of <xref target="HTML5"/>). These protections ensure that media is prot applications, which are not able to read or modify the contents of a pro
ected from tected flow
applications. Applications are not able to read or modify the contents of media. Media that is produced from a session using the <tt>c-webrtc<
of a protected flow /tt> identifier <bcp14>MUST</bcp14> only be displayed to users.
of media. Media that is produced from a session using the <spanx
style="verb">c-webrtc</spanx> identifier MUST 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>
<dt>Identification Sequence:</dt>
<dd>0x77 0x65 0x62 0x72 0x74 0x63 ("webrtc")</dd>
<dt>Specification:</dt>
<dd>RFC 8833 (this document)</dd>
</dl>
</dd>
<dt>c-webrtc:</dt>
<dd>
<t>
The <tt>c-webrtc</tt> label identifies WebRTC
communications with a promise to protect media confidentiality: communications with a promise to protect media confidentiality:
<list style="hanging">
<t hangText="Protocol:">Confidential WebRTC Media and Data</t>
<t hangText="Identification Sequence:">0x63 0x2d 0x77 0x65 0x62 0x
72 0x74 0x63
("c-webrtc")</t>
<t hangText="Specification:">This document (RFCXXXX)</t>
</list>
</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"?> <author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.576 <organization/>
4.xml"?> </author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.730 <date month='May' year='2020'/>
1.xml"?> </front>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie <seriesInfo name="RFC" value="8827"/>
tf-rtcweb-security-arch.xml"?> <seriesInfo name="DOI" value="10.17487/RFC8827"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie </reference>
tf-rtcweb-data-channel.xml"?>
</references> <!-- draft-ietf-rtcweb-data-channel: 8831 -->
<reference anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8831">
<front>
<title>WebRTC Data Channels</title>
<author initials="R." surname="Jesup" fullname="Randell Jesup">
<organization/>
</author>
<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
<organization/>
</author>
<author initials="M." surname="Tüxen" fullname="Michael Tüxen">
<organization/>
</author>
<date month='May' year='2020'/>
</front>
<seriesInfo name="RFC" value="8831"/>
<seriesInfo name="DOI" value="10.17487/RFC8831"/>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.4960.xml"/>
<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>
<author initials="H." surname="Alvestrand" fullname="Harald T. Alvestrand">
<organization />
</author>
<date month="May" year="2020" />
</front>
<seriesInfo name="RFC" value="8825" />
<seriesInfo name="DOI" value="10.17487/RFC8825"/>
</reference>
<!-- draft-ietf-rtcweb-transports-17: 8835 -->
<reference anchor="RFC8835" target="https://www.rfc-editor.org/info/rfc8835">
<front>
<title>Transports for WebRTC</title>
<author initials="H." surname="Alvestrand" fullname="Harald Alvestrand">
<organization />
</author>
<date month="May" year="2020" />
</front>
<seriesInfo name="RFC" value="8835" />
<seriesInfo name="DOI" value="10.17487/RFC8835"/>
</reference>
<!-- [rfced] It seems that this reference has a new version. See
https://www.w3.org/TR/html5/. Would you like to reference this new
version? Note that the section reference in the text may need to be
updated if the reference entry is updated; the text currently refers to
"Section 5.3 of [HTML5]". Let us know the appropriate section to
reference. Perhaps either Section 6.2 or 6.4 of [HTML5.2]?
Original
[HTML5] Berjon, R., Leithead, T., Doyle Navara, E., O'Connor, E.,
and S. Pfeiffer, "HTML 5", CR CR-html5-20121217, August
2010, <http://www.w3.org/TR/2012/CR-html5-20121217/>.
Perhaps
[HTML5.2] Faulkner, S., Eicholz, A., Leithead, T., Danilo, A., and
S. Moon, "HTML 5.2", W3C Recommendation REC-html52-20171214,
December 2017, <https://www.w3.org/TR/html5/
-->
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.496
0.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.524
5.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie
tf-rtcweb-overview.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie
tf-rtcweb-transports.xml"?>
<reference anchor="HTML5" target="http://www.w3.org/TR/2012/CR-html5-20121 217/"> <reference anchor="HTML5" target="http://www.w3.org/TR/2012/CR-html5-20121 217/">
<front> <front>
<title> <title>
HTML 5 HTML 5
</title> </title>
<author initials="R." surname="Berjon" fullname="Robin Berjon"/> <seriesInfo name="W3C Candidate Recommendation" value="CR-html5-2012
<author initials="T." surname="Leithead" fullname="Travis Leithead"/> 1217"/>
<author initials="E." surname="Doyle Navara" fullname="Erika Doyle Nav <author initials="R." surname="Berjon" fullname="Robin Berjon"/>
ara"/> <author initials="T." surname="Leithead" fullname="Travis Leithead"/
<author initials="E." surname="O'Connor" fullname="Edward O'Connor"/> >
<author initials="S." surname="Pfeiffer" fullname="Silvia Pfeiffer"/> <author initials="E." surname="Doyle Navara" fullname="Erika Doyle N
<date year="2010" month="August"/> avara"/>
</front> <author initials="E." surname="O'Connor" fullname="Edward O'Connor"/
<seriesInfo name="CR" value="CR-html5-20121217"/> >
</reference> <author initials="S." surname="Pfeiffer" fullname="Silvia Pfeiffer"/
>
<date year="2010" month="August"/>
</front>
</reference>
</references>
</references> </references>
</back> </back>
</rfc> </rfc>
 End of changes. 55 change blocks. 
197 lines changed or deleted 297 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/