rfc9220.original.xml   rfc9220.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!-- draft submitted in xml v3 -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.25 (Ruby 3.0.3) --> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.25 (Ruby 3.0.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -ietf-httpbis-h3-websockets-04" category="std" consensus="true" tocInclude="true " sortRefs="true" symRefs="true" version="3"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="en" ipr="trust200902" docName="draft-ietf-httpbis-h3-websockets-04" number="9220" submissionType="IETF " category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="tru e" updates="" obsoletes="" version="3">
<!-- xml2rfc v2v3 conversion 3.12.1 --> <!-- xml2rfc v2v3 conversion 3.12.1 -->
<front> <front>
<title>Bootstrapping WebSockets with HTTP/3</title> <title>Bootstrapping WebSockets with HTTP/3</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-h3-websockets-04 "/> <seriesInfo name="RFC" value="9220"/>
<author initials="R." surname="Hamilton" fullname="Ryan Hamilton"> <author initials="R." surname="Hamilton" fullname="Ryan Hamilton">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<email>rch@google.com</email> <email>rch@google.com</email>
</address> </address>
</author> </author>
<date year="2022" month="February" day="08"/> <date year="2022" month="June"/>
<area>ART</area> <area>ART</area>
<workgroup>HTTP</workgroup> <workgroup>HTTP</workgroup>
<keyword>Internet-Draft</keyword> <keyword>extended connect</keyword>
<keyword>42</keyword>
<abstract> <abstract>
<t>The mechanism for running the WebSocket Protocol over a single stream <t>The mechanism for running the WebSocket Protocol over a single stream
of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP of an HTTP/2 connection is equally applicable to HTTP/3, but the
version-specific details need to be specified. This document describes HTTP-version-specific details need to be specified. This document describes
how the mechanism is adapted for HTTP/3.</t> how the mechanism is adapted for HTTP/3.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-httpbis-h3-websockets/"/>.
</t>
<t>
Discussion of this document takes place on the
HTTP Working Group mailing list (<eref target="mailto:ietf-http-wg@w3.or
g"/>),
which is archived at <eref target="https://lists.w3.org/Archives/Public/
ietf-http-wg/"/>.
Working Group information can be found at <eref target="https://httpwg.o
rg/"/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/httpwg/http-extensions/labels/h3-websoc
kets"/>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>"Bootstrapping WebSockets with HTTP/2" <xref target="RFC8441"/> defines <t>"<xref target="RFC8441" format="title"/>" <xref target="RFC8441" format
an extension ="default"/> defines an extension
to HTTP/2 <xref target="HTTP2"/> which is also useful in HTTP/3 <xref target="HT to HTTP/2 <xref target="HTTP2"/> that is also useful in HTTP/3 <xref target="HTT
TP3"/>. P3"/>.
This extension makes use of an HTTP/2 setting. <xref section="A.3" sectionForma t="of" target="HTTP3"/> This extension makes use of an HTTP/2 setting. <xref section="A.3" sectionForma t="of" target="HTTP3"/>
gives some guidance on what changes (if any) are appropriate when porting gives some guidance on what changes (if any) are appropriate when porting
settings from HTTP/2 to HTTP/3.</t> settings from HTTP/2 to HTTP/3.</t>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and are to be interpreted as described in BCP&nbsp;14
only when, they <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
appear in all capitals, as shown here.</t> when, they appear in all capitals, as shown here.</t>
</section> </section>
<section anchor="websockets-upgrade-over-http3"> <section anchor="websockets-upgrade-over-http3">
<name>Websockets Upgrade over HTTP/3</name> <name>WebSockets Upgrade over HTTP/3</name>
<t><xref target="RFC8441"/> defines a mechanism for running the WebSocket Protocol <t><xref target="RFC8441"/> defines a mechanism for running the WebSocket Protocol
<xref target="RFC6455"/> over a single stream of an HTTP/2 connection. It define s <xref target="RFC6455"/> over a single stream of an HTTP/2 connection. It define s
an Extended CONNECT method which specifies a new ":protocol" an Extended CONNECT method that specifies a new ":protocol"
pseudo-header field and new semantics for the ":path" and ":authority" pseudo-header field and new semantics for the ":path" and ":authority"
pseudo-header fields. It also defines a new HTTP/2 setting sent by a server to pseudo-header fields. It also defines a new HTTP/2 setting sent by a server to
allow the client to use Extended CONNECT.</t> allow the client to use Extended CONNECT.</t>
<t>The semantics of the pseudo-header fields and setting are identical to those <t>The semantics of the pseudo-header fields and setting are identical to those
in HTTP/2 as defined <xref target="RFC8441"/>. <xref section="A.3" sectionFormat ="of" target="HTTP3"/> requires that in HTTP/2 as defined in <xref target="RFC8441"/>. <xref section="A.3" sectionFor mat="of" target="HTTP3"/> requires that
HTTP/3 settings be registered separately for HTTP/3. The HTTP/3 settings be registered separately for HTTP/3. The
SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2.</t> SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2.</t>
<t>If a server advertises support for Extended CONNECT but receives an <t>If a server advertises support for Extended CONNECT but receives an
Extended CONNECT request with a ":protocol" value that is unknown or is Extended CONNECT request with a ":protocol" value that is unknown or is
not supported, the server <bcp14>SHOULD</bcp14> respond to the request with a 50 1 (Not not supported, the server <bcp14>SHOULD</bcp14> respond to the request with a 50 1 (Not
Implemented) status code (<xref section="15.6.2" sectionFormat="of" target="HTTP "/>). A server <bcp14>MAY</bcp14> Implemented) status code (<xref section="15.6.2" sectionFormat="of" target="HTTP "/>). A server <bcp14>MAY</bcp14>
provide more information via a Problem Details response <xref target="RFC7807"/> .</t> provide more information via a "problem details" response <xref target="RFC7807" />.</t>
<t>The HTTP/3 stream closure is also analogous to the TCP connection <t>The HTTP/3 stream closure is also analogous to the TCP connection
closure of <xref target="RFC6455"/>. Orderly TCP-level closures are represented as closure of <xref target="RFC6455"/>. Orderly TCP-level closures are represented as
a FIN bit on the stream (<xref section="4.2" sectionFormat="of" target="HTTP3"/> ). RST exceptions are a FIN bit on the stream (<xref section="4.4" sectionFormat="of" target="HTTP3"/> ). RST exceptions are
represented with a stream error (<xref section="8" sectionFormat="of" target="HT TP3"/>) of type represented with a stream error (<xref section="8" sectionFormat="of" target="HT TP3"/>) of type
H3_REQUEST_CANCELLED (<xref section="8.1" sectionFormat="of" target="HTTP3"/>).< /t> H3_REQUEST_CANCELLED (<xref section="8.1" sectionFormat="of" target="HTTP3"/>).< /t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document introduces no new security considerations beyond those <t>This document introduces no new security considerations beyond those
discussed in <xref target="RFC8441"/>.</t> discussed in <xref target="RFC8441"/>.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document registers a new setting in the "HTTP/3 Settings" <t>This document registers a new setting in the "HTTP/3 Settings"
registry (<xref section="11.2.2" sectionFormat="of" target="HTTP3"/>).</t> registry (<xref section="11.2.2" sectionFormat="of" target="HTTP3"/>).</t>
<dl> <dl spacing="compact">
<dt> <dt>
Value: </dt> Value: </dt>
<dd> <dd>
<t>0x08</t> <t>0x08</t>
</dd> </dd>
<dt> <dt>
Setting Name: </dt> Setting Name: </dt>
<dd> <dd>
<t>SETTINGS_ENABLE_CONNECT_PROTOCOL</t> <t>SETTINGS_ENABLE_CONNECT_PROTOCOL</t>
</dd> </dd>
skipping to change at line 119 skipping to change at line 110
<t>0</t> <t>0</t>
</dd> </dd>
<dt> <dt>
Status: </dt> Status: </dt>
<dd> <dd>
<t>permanent</t> <t>permanent</t>
</dd> </dd>
<dt> <dt>
Specification: </dt> Specification: </dt>
<dd> <dd>
<t>This Document</t> <t>This document</t>
</dd>
<dt>
Date: </dt>
<dd>
<t>[ date of publication ]</t>
</dd> </dd>
<dt> <dt>
Change Controller: </dt> Change Controller: </dt>
<dd> <dd>
<t>IETF</t> <t>IETF</t>
</dd> </dd>
<dt> <dt>
Contact: </dt> Contact: </dt>
<dd> <dd>
<t>HTTP Working Group (ietf-http-wg@w3.org)</t> <t>HTTP Working Group (ietf-http-wg@w3.org)</t>
</dd> </dd>
<dt>
Notes: </dt>
<dd>
<!-- -->
</dd>
</dl> </dl>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="HTTP3" to="HTTP/3"/>
<displayreference target="HTTP2" to="HTTP/2"/>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="HTTP3"> <!-- [HTTP/3] draft-ietf-quic-http (RFC 9114) -->
<reference anchor='HTTP3' target="https://www.rfc-editor.org/info/rfc9114"
>
<front> <front>
<title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title> <title>HTTP/3</title>
<author fullname="Mike Bishop" initials="M." surname="Bishop"> <author initials='M' surname='Bishop' fullname='Mike Bishop' role="edi
<organization>Akamai</organization> tor">
<organization />
</author> </author>
<date day="2" month="February" year="2021"/> <date year='2022' month='June' />
<abstract>
<t> The QUIC transport protocol has several features that are desi
rable
in a transport for HTTP, such as stream multiplexing, per-stream flow
control, and low-latency connection establishment. This document
describes a mapping of HTTP semantics over QUIC. This document also
identifies HTTP/2 features that are subsumed by QUIC, and describes
how HTTP/2 extensions can be ported to HTTP/3.
DO NOT DEPLOY THIS VERSION OF HTTP
DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC. This
version is still a work in progress. For trial deployments, please
use earlier versions.
Note to Readers
Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=quic.
Working Group information can be found at https://github.com/quicwg;
source code and issues list for this draft can be found at
https://github.com/quicwg/base-drafts/labels/-http.
</t>
</abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"/> <seriesInfo name="RFC" value="9114"/>
<seriesInfo name="DOI" value="10.17487/RFC9114"/>
</reference> </reference>
<reference anchor="HTTP2"> <!-- [HTTP/2] draft-ietf-httpbis-http2bis (RFC 9113) -->
<reference anchor='HTTP2' target="https://www.rfc-editor.org/info/rfc9113"
>
<front> <front>
<title>HTTP/2</title> <title>HTTP/2</title>
<author fullname="Martin Thomson" initials="M." surname="Thomson"> <author initials='M' surname='Thomson' fullname='Martin Thomson' role=
<organization>Mozilla</organization> "editor">
<organization />
</author> </author>
<author fullname="Cory Benfield" initials="C." surname="Benfield"> <author initials='C' surname='Benfield' fullname='Cory Benfield' role=
<organization>Apple Inc.</organization> "editor">
<organization />
</author> </author>
<date day="24" month="January" year="2022"/> <date year='2022' month='June' />
<abstract>
<t> This specification describes an optimized expression of the se
mantics
of the Hypertext Transfer Protocol (HTTP), referred to as HTTP
version 2 (HTTP/2). HTTP/2 enables a more efficient use of network
resources and a reduced latency by introducing field compression and
allowing multiple concurrent exchanges on the same connection.
This document obsoletes RFC 7540 and RFC 8740.
</t>
</abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-http2bis-07" <seriesInfo name="RFC" value="9113"/>
/> <seriesInfo name="DOI" value="10.17487/RFC9113"/>
</reference> </reference>
<reference anchor="HTTP"> <!-- [HTTP] draft-ietf-httpbis-semantics (RFC 9110) -->
<reference anchor='HTTP' target="https://www.rfc-editor.org/info/rfc9110">
<front> <front>
<title>HTTP Semantics</title> <title>HTTP Semantics</title>
<author fullname="Roy T. Fielding" initials="R. T." surname="Fielding" <author initials='R' surname='Fielding' fullname='Roy Fielding' role="
> editor">
<organization>Adobe</organization> <organization />
</author>
<author fullname="Mark Nottingham" initials="M." surname="Nottingham">
<organization>Fastly</organization>
</author>
<author fullname="Julian Reschke" initials="J." surname="Reschke">
<organization>greenbytes GmbH</organization>
</author>
<date day="12" month="September" year="2021"/>
<abstract>
<t> The Hypertext Transfer Protocol (HTTP) is a stateless applicat
ion-
level protocol for distributed, collaborative, hypertext information
systems. This document describes the overall architecture of HTTP,
establishes common terminology, and defines aspects of the protocol
that are shared by all versions. In this definition are core
protocol elements, extensibility mechanisms, and the "http" and
"https" Uniform Resource Identifier (URI) schemes.
This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC
7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions
of RFC 7230.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-semantics-19
"/>
</reference>
<reference anchor="RFC8441">
<front>
<title>Bootstrapping WebSockets with HTTP/2</title>
<author fullname="P. McManus" initials="P." surname="McManus">
<organization/>
</author>
<date month="September" year="2018"/>
<abstract>
<t>This document defines a mechanism for running the WebSocket Proto
col (RFC 6455) over a single stream of an HTTP/2 connection.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8441"/>
<seriesInfo name="DOI" value="10.17487/RFC8441"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title
>
<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization/>
</author>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to signi
fy the requirements in the specification. These words are often capitalized. Th
is document defines these words as they should be interpreted in IETF documents.
This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</titl
e>
<author fullname="B. Leiba" initials="B." surname="Leiba">
<organization/>
</author>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protocol
specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC6455">
<front>
<title>The WebSocket Protocol</title>
<author fullname="I. Fette" initials="I." surname="Fette">
<organization/>
</author>
<author fullname="A. Melnikov" initials="A." surname="Melnikov">
<organization/>
</author> </author>
<date month="December" year="2011"/> <author initials='M' surname='Nottingham' fullname='Mark Nottingham' r
<abstract> ole="editor">
<t>The WebSocket Protocol enables two-way communication between a cl <organization />
ient running untrusted code in a controlled environment to a remote host that ha
s opted-in to communications from that code. The security model used for this i
s the origin-based security model commonly used by web browsers. The protocol c
onsists of an opening handshake followed by basic message framing, layered over
TCP. The goal of this technology is to provide a mechanism for browser-based ap
plications that need two-way communication with servers that does not rely on op
ening multiple HTTP connections (e.g., using XMLHttpRequest or &lt;iframe&gt;s a
nd long polling). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6455"/>
<seriesInfo name="DOI" value="10.17487/RFC6455"/>
</reference>
<reference anchor="RFC7807">
<front>
<title>Problem Details for HTTP APIs</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/>
</author> </author>
<author fullname="E. Wilde" initials="E." surname="Wilde"> <author initials='J' surname='Reschke' fullname='Julian Reschke' role=
<organization/> "editor">
<organization />
</author> </author>
<date month="March" year="2016"/> <date year='2022' month='June' />
<abstract>
<t>This document defines a "problem detail" as a way to carry machin
e- readable details of errors in a HTTP response to avoid the need to define new
error response formats for HTTP APIs.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="7807"/> <seriesInfo name="STD" value="97"/>
<seriesInfo name="DOI" value="10.17487/RFC7807"/> <seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8441.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6455.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7807.xml"/>
</references> </references>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>This document had reviews and input from many contributors in the IETF HTTP <t>This document had reviews and input from many contributors in the IETF HTTP
and QUIC Working Groups, with substantive input from David Schinazi, Martin and QUIC Working Groups, with substantive input from <contact fullname="David Sc
Thomson, Lucas Pardue, Mike Bishop, Dragana Damjanovic, Mark Nottingham, and hinazi"/>, <contact fullname="Martin Thomson"/>, <contact fullname="Lucas Pardue
Julian Reschke.</t> "/>, <contact fullname="Mike Bishop"/>, <contact fullname="Dragana Damjanovic"/>
, <contact fullname="Mark Nottingham"/>, and <contact fullname="Julian Reschke"/
>.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAJaXAmIAA5VX4XIaORL+r6fQcn/iKw824Gwcam9rCSaxr2zwGXKprdSW
S8wI0DEjTSSNCevyu+yz7JPd15oZYGKn9u6PGUvdre6vuz+1oihiXvlU9nnr
nTHeeSvyXOkl/yTnUxOvpXd8o/yKX85mtye9FktMrEUG+cSKhY+U9Ito5X0+
Vy5a9aKNnLtSLTo9Y7Hwcmnsts+dTxhTue1zbwvnu6enb0+7TFgp+nxwN2Mb
Y9dLa4q8H05ia7nFUtLnV9pLq6WPLug89iB1IfuM80Nhzv02h0ufYIR8/0B7
WF0ZcpS8c/2TE/rdLNvGLk+wlwmV9vnO/Wiz/GXTo03sCRuv9nqpct61y82T
AbbUg3Qnt8U8VfHJoQEya2Vu9qpLIFfM27HJqtPDTyS/eqmdMtqdpGIuU3fS
QI6VapFyrpBRkIDJhoTzQif3IjUaAW4lFjJh/f2Xwnjp+lwblqs+/+xNfMyd
sd7KhcPXNqOP3xgThV8ZCxwj+Mx5mdG7rdD8UmQq9UaHdUQstPpdePja5x+M
WaYybMgSPoDxyzKsUoyMaWMzCD+EDFFqekhgdNE+qJUvhYpLwHpnlVD3mdCu
oPDbpY/TN5Xsd0UdXNJexS7qvEWl6cXeFcaiKOJiTsUde8ZmK8kzGa8Qmss4
BLkttKbC8djZFT6/tQYAmpSbB2m54A4iqUQpo2ozZhac4KK26PLYaC1jgokr
x+WXQqTplqOVUCNiDiVvqg465vPCh4NC6cIyFULkchmrhYp5Ij2gdVxLmZDW
HAeWezJp89kK5tGCRSa1h6yLrZoj/SuzCTb3YUFOJCL3sEIRloe3SygylSRI
JPsbdZc1SRE8Z+x/oYBuiz8+/nD3fnh+dtZ5eoIPC6WlIyx2Zc3qaLuQDRmG
4Gal4lVwK3WGF04uipSrCsFeJdh7emqzEOTOGDp1DftQ4A3InfQeXrY5VAd5
LnWivvJBu0dSlSk0EloVDZBJvixUInQMIxquCM8JqCV2Xymyuj1C10vKmDW5
VeAtSEnNczQPTmHVaY4vrMlqF3ZJBa4Ac2g06ImgJDgSfkHQqPB/WXQgNU6s
5njr5uN01jouf/l4Er7vRv/6eHU3uqDv6eXg+nr3wSqJ6eXk4/XF/muvOZzc
3IzGF6UyVnljibVuBr9ih7xqTW5nV5Px4LpF6PtGQREEZc0pot3cSqof4Vhd
aQnpvBve/vlH56yqg26n8xbprYqi8+Ys5Frq8jSj0Qflv6jPLQPAUliygg7h
sciVRz1AFmlCEWu+klYCzr9/JmR+6/Of5nHeOfu5WqCAG4s1Zo3FgNnzlWfK
JYgvLL1wzA7Nxvo3SDf9Hfza+L/G/WCRqubTjtX5x3xpRSJLvikri7GXu+3/
IrDKxo9nr1/Dxktsxr/DZm1+5etDGQRG1JUJymA4GY9HwxncwEWSVM1dExX5
p+WGt/p55UGL5U4WiYlWEgFaDqE0CQVCcjvuDrFQDNAUftUqC7Zf3lbKb180
44KTgVX28JDZJlHgFxU+31Lo0hIG3jAUYcWccapo3wdq4s8CbZcdvPcUgJHa
S/4Er+tTqaVUQrQQi5TMIxQnmdqBjcov3U4axNr+Pq1hyMAtahGnB5GxikB3
DIXutXKJoQWdRH7kwoLO0IYH9wAuEsmmo9nsavxhej8aD95dj+6rUO9v7yaz
yXByzR9EWkii7NOvp+f8VYLsZgji/Cj06y4EYHO12MMqEvz1yhHzFjkRaDj5
WenQPWhlLANHC82eCVCY0vny8hGH1VR5RuGTe4Vea+IOnKIchhBfHyyTQDu1
Z1VzA7nc6KRMhvz2mNenHf5qbDy7yvJUEi3K5AhtInzh0Bloz1ePj9Pqsu+8
bv/Y7ta5eXo6avNBfRr6n8HjB2SfZ4bKoB5KoPigBM5Cg2I4yHBTlJd+6Rnq
r6yEN+enb+hCDKVXp7ns1zg1rrByd58KjWFwaeBiFdVseHvQx6yWh6eHZNDm
E4vCRXFAPkrlg0xr0y6ULuZZfAYQ6B4Q/P3VmM+Vp2s0IFu6cwDJ2R6PXgDk
DrQtv8Yyr25GK9mh1Qr2ypC0Flk8MHd+aCx0HUZ9dtm7J+YfTWf3w8F4OLq+
Hl00tNqdhhNEtNgriETonnZIihW7q/nwDlTVSAQAtKnoqVKMG4potG0oo9DQ
iXJx4Vx5QzYaOcxZg/HgL86te7Zmr5pAVAl0q8r/tGrzFisV7LZRj5129xv8
Gfs3NUuf9UMbM1ZZ4GMa+rH6VzTAGAYZUaQ+mIB+aAX6J5coZw3nsVjNr+VT
AXshuIsqOJgABdHyZ57QbAUH8/CAKrsBL5JhGMcII8CfptKS9NVo9h5bWMPg
TgsUVfOZh/nt+RvuiLFxeAlB5acfMPFG0c/l6DsX8ZoSMoiJMlKZLMk/xx77
usjmxJj/aC3QUbL19G2CViJBkh6U3JQMr3QOBgvzIFAI1eExIxXeWFdnjQIo
B33SwKgybHqPySfUvyvm9KSj98qh3QsB9uBTPDm1+F0d8xtB0yj8MpkzGKmu
ixhEfCtsUkjsqrXk7xTmqPyY47mMt5uAiew/QoOF4qC+5gCG0r8SWZjQ2D+L
VOFmv8OEt1pj9PovamA0tRMQAAA=
</rfc> </rfc>
 End of changes. 37 change blocks. 
284 lines changed or deleted 83 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/