rfc9412.original.xml   rfc9412.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-rfc version 1.6.19 (Ruby 3.1. 3) --> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.19 (Ruby 3.1. 3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-httpbis-origin-h3-03" category="std" consensus="true" tocInclude="true" so <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
rtRefs="true" symRefs="true" version="3"> -ietf-httpbis-origin-h3-03" number="9412" submissionType="IETF" category="std" c
onsensus="true" tocInclude="true" sortRefs="true" symRefs="true"
updates="" obsoletes="" xml:lang="en" version="3">
<!-- xml2rfc v2v3 conversion 3.15.3 --> <!-- xml2rfc v2v3 conversion 3.15.3 -->
<front> <front>
<title abbrev="ORIGIN in HTTP/3">The ORIGIN Extension in HTTP/3</title> <title abbrev="ORIGIN in HTTP/3">The ORIGIN Extension in HTTP/3</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-origin-h3-03"/> <seriesInfo name="RFC" value="9412"/>
<author initials="M." surname="Bishop" fullname="Mike Bishop"> <author initials="M." surname="Bishop" fullname="Mike Bishop">
<organization>Akamai</organization> <organization>Akamai</organization>
<address> <address>
<email>mbishop@evequefou.be</email> <email>mbishop@evequefou.be</email>
</address> </address>
</author> </author>
<date/> <date year="2023" month="June" />
<area>Applications and Real-Time</area>
<workgroup>HTTPbis</workgroup> <area>art</area>
<keyword>Internet-Draft</keyword> <workgroup>httpbis</workgroup>
<abstract> <abstract>
<t>The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but <t>The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but it
needs to be separately registered. This document describes the ORIGIN needs to be separately registered. This document describes the ORIGIN
frame for HTTP/3.</t> frame for HTTP/3.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="problems"> <section anchor="problems">
<name>Introduction</name> <name>Introduction</name>
<t>Existing RFCs define extensions to HTTP/2 <xref target="HTTP2"/> which <t>Existing RFCs define extensions to HTTP/2 <xref target="RFC9113"/> that
remain useful in remain useful in
HTTP/3. <xref section="A.2.3" sectionFormat="of" target="HTTP3"/> describes the HTTP/3. <xref section="A.2" sectionFormat="of" target="RFC9114"/> describes the
required updates for HTTP/2 required updates for HTTP/2
frames to be used with HTTP/3.</t> frames to be used with HTTP/3.</t>
<t><xref target="ORIGIN"/> defines the HTTP/2 ORIGIN frame, which indicate s what <t><xref target="RFC8336"/> defines the HTTP/2 ORIGIN frame, which indicat es what
origins are available on a given connection. It defines a single HTTP/2 frame origins are available on a given connection. It defines a single HTTP/2 frame
type.</t> type.</t>
<section anchor="notational-conventions"> <section anchor="notational-conventions">
<name>Notational Conventions</name> <name>Notational Conventions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
14>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>
<t>Frame diagrams in this document use the format defined in <xref secti <t>The frame diagram in this document uses the format defined in <xref s
on="1.3" sectionFormat="of" target="QUIC-TRANSPORT"/> to illustrate the order an ection="1.3" sectionFormat="of" target="RFC9000"/> to illustrate the order and s
d size of fields.</t> ize of fields.</t>
</section> </section>
</section> </section>
<section anchor="frame-origin"> <section anchor="frame-origin">
<name>The ORIGIN HTTP/3 Frame</name> <name>The ORIGIN HTTP/3 Frame</name>
<t>The ORIGIN HTTP/3 frame allows a server to indicate what origin(s) <t>The ORIGIN HTTP/3 frame allows a server to indicate what origin or orig
(<xref target="RFC6454"/>) the server would like the client to consider as membe ins
rs of the <xref target="RFC6454"/> the server would like the client to consider as one or
Origin Set (<xref section="2.3" sectionFormat="of" target="ORIGIN"/>) for the co more members of the
nnection within which it Origin Set (<xref section="2.3" sectionFormat="of" target="RFC8336"/>) for the c
onnection within which it
occurs.</t> occurs.</t>
<t>The semantics of the frame payload are identical to those of the HTTP/2 frame <t>The semantics of the frame payload are identical to those of the HTTP/2 frame
defined in <xref target="ORIGIN"/>. Where HTTP/2 reserves Stream 0 for frames re lated to the defined in <xref target="RFC8336"/>. Where HTTP/2 reserves stream 0 for frames r elated to the
state of the connection, HTTP/3 defines a pair of unidirectional streams called state of the connection, HTTP/3 defines a pair of unidirectional streams called
"control streams" for this purpose. Where <xref target="ORIGIN"/> indicates tha "control streams" for this purpose.</t>
t the ORIGIN
frame should be sent on Stream 0, this should be interpreted to mean the HTTP/3 <t>Where <xref target="RFC8336"/> indicates that the ORIGIN
control stream. The ORIGIN frame is sent from servers to clients on the frame is sent on stream 0, this should be interpreted to mean the HTTP/3
control stream: that is, the ORIGIN frame is sent from servers to clients on the
server's control stream.</t> server's control stream.</t>
<t>HTTP/3 does not define a Flags field in the generic frame layout. As no flags <t>HTTP/3 does not define a Flags field in the generic frame layout. As no flags
have been defined for the ORIGIN frame, this specification does not define a have been defined for the ORIGIN frame, this specification does not define a
mechanism for communicating such flags in HTTP/3.</t> mechanism for communicating such flags in HTTP/3.</t>
<section anchor="frame-layout"> <section anchor="frame-layout">
<name>Frame Layout</name> <name>Frame Layout</name>
<t>The ORIGIN frame has a nearly identical layout to that used in HTTP/2
, restated <t>The ORIGIN frame has a layout that is nearly identical to the layout
here for clarity. The ORIGIN frame type is 0xc (decimal 12) as in HTTP/2. The used in HTTP/2; the information is restated
here for clarity. The ORIGIN frame type is 0x0c (decimal 12), as in HTTP/2. The
payload contains zero or more instances of the Origin-Entry field.</t> payload contains zero or more instances of the Origin-Entry field.</t>
<figure> <figure>
<name>ORIGIN Frame Layout</name> <name>ORIGIN Frame Layout</name>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art"><![CDATA[
HTTP/3 Origin-Entry { HTTP/3 Origin-Entry {
Origin-Len (16), Origin-Len (16),
ASCII-Origin (..), ASCII-Origin (..),
} }
HTTP/3 ORIGIN Frame { HTTP/3 ORIGIN Frame {
skipping to change at line 106 skipping to change at line 119
<t>An <bcp14>OPTIONAL</bcp14> sequence of characters containing the ASCII serialization of an <t>An <bcp14>OPTIONAL</bcp14> sequence of characters containing the ASCII serialization of an
origin (<xref section="6.2" sectionFormat="comma" target="RFC6454"/>) that the s ender asserts this connection is origin (<xref section="6.2" sectionFormat="comma" target="RFC6454"/>) that the s ender asserts this connection is
or could be authoritative for.</t> or could be authoritative for.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="security"> <section anchor="security">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document introduces no new security considerations beyond those di scussed <t>This document introduces no new security considerations beyond those di scussed
in <xref target="ORIGIN"/> and <xref target="HTTP3"/>.</t> in <xref target="RFC8336"/> and <xref target="RFC9114"/>.</t>
</section> </section>
<section anchor="iana"> <section anchor="iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document registers a frame type in the "HTTP/3 Frame Type" <t>This document registers a frame type in the "HTTP/3 Frame Types"
registry (<xref target="HTTP3"/>).</t> registry defined by <xref target="RFC9114"/>, located at <eref target="https://w
<table anchor="iana-frame-table"> ww.iana.org/assignments/http3-parameters/" brackets="angle"/>.</t>
<name>Registered HTTP/3 Frame Types</name>
<thead> <dl spacing="compact"><dt>Value:</dt><dd>0x0c</dd>
<tr> <dt>Frame Type:</dt><dd>ORIGIN</dd>
<th align="left">Frame Type</th> <dt>Status:</dt><dd>permanent</dd>
<th align="center">Value</th> <dt>Reference:</dt><dd><xref target="frame-origin"/></dd>
<th align="left">Specification</th> <dt>Date:</dt><dd>2023-03-14</dd>
</tr> <dt>Change Controller:</dt><dd>IETF</dd>
</thead> <dt>Contact:</dt><dd>HTTP WG &lt;ietf-http-wg@w3.org&gt;</dd>
<tbody> </dl>
<tr>
<td align="left">ORIGIN</td>
<td align="center">0xc</td>
<td align="left">
<xref target="frame-origin"/></td>
</tr>
</tbody>
</table>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC9113" to="HTTP/2"/>
<displayreference target="RFC9114" to="HTTP/3"/>
<displayreference target="RFC8336" to="ORIGIN"/>
<displayreference target="RFC9000" to="QUIC-TRANSPORT"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="HTTP2">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<title>HTTP/2</title> 113.xml"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="T <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
homson"> 114.xml"/>
<organization/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</author> 336.xml"/>
<author fullname="C. Benfield" initials="C." role="editor" surname="
Benfield"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<organization/> 119.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<date month="June" year="2022"/> 174.xml"/>
<abstract>
<t>This specification describes an optimized expression of the sem
antics 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 excha
nges on the same connection.</t>
<t>This document obsoletes RFCs 7540 and 8740.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9113"/>
<seriesInfo name="DOI" value="10.17487/RFC9113"/>
</reference>
<reference anchor="HTTP3">
<front>
<title>HTTP/3</title>
<author fullname="M. Bishop" initials="M." role="editor" surname="Bi
shop">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract>
<t>The QUIC transport protocol has several features that are desir
able in a transport for HTTP, such as stream multiplexing, per-stream flow contr
ol, and low-latency connection establishment. This document describes a mapping
of HTTP semantics over QUIC. This document also identifies HTTP/2 features tha
t are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP
/3.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9114"/>
<seriesInfo name="DOI" value="10.17487/RFC9114"/>
</reference>
<reference anchor="ORIGIN">
<front>
<title>The ORIGIN HTTP/2 Frame</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/>
</author>
<author fullname="E. Nygren" initials="E." surname="Nygren">
<organization/>
</author>
<date month="March" year="2018"/>
<abstract>
<t>This document specifies the ORIGIN frame for HTTP/2, to indicat
e what origins are available on a given connection.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8336"/>
<seriesInfo name="DOI" value="10.17487/RFC8336"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<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 sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, 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</ti
tle>
<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 protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t 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>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="QUIC-TRANSPORT">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> 000.xml"/>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
yengar"> 454.xml"/>
<organization/>
</author>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson">
<organization/>
</author>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communic
ation, low-latency connection establishment, and network path migration. QUIC in
cludes security measures that ensure confidentiality, integrity, and availabilit
y in a range of deployment circumstances. Accompanying documents describe the i
ntegration of TLS for key negotiation, loss detection, and an exemplary congesti
on control algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="RFC6454">
<front>
<title>The Web Origin Concept</title>
<author fullname="A. Barth" initials="A." surname="Barth">
<organization/>
</author>
<date month="December" year="2011"/>
<abstract>
<t>This document defines the concept of an "origin", which is ofte
n used as the scope of authority or privilege by user agents. Typically, user a
gents isolate content retrieved from different origins to prevent malicious web
site operators from interfering with the operation of benign web sites. In addi
tion to outlining the principles that underlie the concept of origin, this docum
ent details how to determine the origin of a URI and how to serialize an origin
into a string. It also defines an HTTP header field, named "Origin", that indic
ates which origins are associated with an HTTP request. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6454"/>
<seriesInfo name="DOI" value="10.17487/RFC6454"/>
</reference>
</references> </references>
</references> </references>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA41X224byRF9768oUw+RAg7Di6JdE3ESriTHBHTxivQGi8Ui
aM40yYbmlu4eyTStfEu+JV+WU90zJMcUsEtA0LBYXddzqnqiKBJOu1SNab5W
dP8w/cf0jq4/O5VbXeSkc/own3/800jIxcKop3Gjsv8hKeJcZjCQGLl0kVZu
Ga2dKxfaRoXRK51H61HUh6J00NpeTebXLyLGl1VhNmOyLhFCl2ZMzlTWDfv9
t/2hkEbJMU3KMtVQRSiWZJ7Qg5JpNNeZEs+FeVyZoirHPhB4E49qA2kypmnu
lMmVi644JCGsw9l/ybTIEcBGWVHqMf3iirhLtjDOqKXF0ybjh1+FkJVbF2Ys
iCL8EXK1Y7rt0Q/arovSi0LGt/pRHUoLs5K5/uLjRfCPMpPa/6DwkI4pW3jd
v6sn9e9KLYuqt1BC5IXJcORJsUfOZTj2hx7eX74dDEa1cHQoPEfF8uXhuR8/
TS+j+cPkbvbx/mG+1+33+0KIKIpILqwzMkY5Djq9NEiEYCl0c0jaEmKTaboh
GYq/SBW5ou52lxaVE7lSiWXhQpFVpTRoJg4YtdIWlVdJD2iCJUCjylTuKFE2
NnqhcGjnW3zje9QLcWY6SVKU5YTbaIqkirmctD0pTYFYMvsixPVnONL5ilOE
G7XUuSLVoNbu4h3Sdusr+vJCz2sdrxEjWpFTZdWyStFZUfuG4kwFT5PesDei
YhnKjpPt6A3qo5EjVSUj2h5UL6TUVAY+EnrWbr3Pb7t9E5J/h8C/H40uvHWO
Ptiugz5sTrcOXOcJMwGKz2vpRGAWSGEUySegy/cJ0UtaARI5xUWeh4R6RFO3
cyPJonDpzpd3ItymVIjv5ITuCufxK1O6LHJY8uQLoAHBiBlmqXP7aTbvdMN/
urv3zw/XQOHD9RU/zz5Mbm52D6LWmH24/3RztX/an7y8v729vrsKhyGllkh0
bic/4xceAZ37j/Pp/d3kpsNDyLVwxtUIxdc8AkqjHHogrWhamPCZHy4//u+/
g3O0/A3aMBwM3qIN4cv3g+/OPVZUHrwVOYAdvqJBGwFSKGnYCjhCsSy1kymm
h7QEaj/ntAb+Uck//sKV+XVMf1nE5eD8r7WAE24Jm5q1hL5mx5Kjw6GIr4he
cbOrZkv+TaXb8U5+bn1v6n4gFOK9J3Gi5QoP9rgjIIFHdhhWNQp9F/aEG3i6
ifYIQxfQSZ2mFY8tF6wAe8r4vlj9RTFHl1qliWXoHi6wQDgKwW1PPMbrZfTS
mn+1YhhF6Gjx7BmizBP8sP+adZ50FCyc2jNxut3+DXC5OP8z4HLmY6sPPRdV
mlDKm4Glcaq5DDAFQlrtw7eUqWyhjOUEoCTuvV2aKUen+7LUUyhEyl540Hib
O2r78YKT9YjAWIjjynA55j6iTIK+ceOnTrOUm7SQiScLAmINkB0RYutZ1ei2
xkOrbW+aiHr0T0Z7o2qUL4GlGTaqzKjvA65HolGpZC56N4o3stu52ufTbRqy
n1al1IYVq1wnGLtxPZus92HBwDRViejABpbFTt6piwUolpUpkRemYIh2u23i
P5ipjtt7tJvAaG6m33JoIurdpNYNtvcKh/MGOWZK5vsyjkQ7PMRytIPZGjtZ
miKrseQXSQCQZee+cP6XP1j6xqIQTeUKpJMXDdVQwfepXNlAlMBPRSuVK6Pj
2nUqN0XlejThg7RkdbGWTwp5YZE0vW/Q115OoQylivWyvqgdRyAyFa9xMbKZ
NxIXWYZusjY2uK2AXO9zf6cMmyiw98YH98qlZS0ZHjmmMSb0HschmYAz6cIS
bgwPuwxShl4iPBZ8OKk02m1e6wlvRW5M/3NMpwlyzOBgMDxjCu9s8l1HiYZU
3BbJi/mLMgUGBmUF0yznK2isdkwMjI+u0cNNaA1y/g9/YDvWOpLGNR1t6W5x
s6sFN2jO6eDirAvRZHY5nUb1HDnt9SB82UGizqmehtCec16n+ozeIbV+zAZg
bIWbCoTdvYfgks1Rr9djkz5EscVdnV8a3nVapkOrOnA8ydsmNLcq9S6iRKU6
08wTQBcI6NGsgQ9unV1MsX0R3XMhwoQfC7FPeyxwu8YlDgN1BWh2aXARLXCO
SbhSpuE1w4uLHRx3uWVF7JTDusa64V9aZWvacCisPTWrD8TExR2N5D4C03yf
Zp7WATcOvQUmsZZp/TrAB2QuqN4hPOfr/dGlZuBf9IZhmdSzCPMg7AtYcjZQ
7WD2442HzUFUz6Dw3qKdfylgbPu1COsVA5yvc34B1a9T2xNb/+JX4uHS1vXF
2/MYFHumRnW3xWojC7UpsI3D5ki0jSsEm4j2nvALO1zEcZ32QU0nd5PjgLTM
5VEwzVsFQ+iQlmGSdVqrnoHdEeEEI3fn9Axev1L0zYcaER3/dqiFo3v7FD5f
6SeZVoofZq3x1/p8fd3rmP+Pf9trTa8De+SHET9st61rzctve/19uYLcvhFR
MO/CC2Cg+8PuDY+O6m6Z+GxiIeNH8X/Kd3R0WRAAAA==
</rfc> </rfc>
 End of changes. 20 change blocks. 
253 lines changed or deleted 89 lines changed or added

This html diff was produced by rfcdiff 1.48.