wdiff rfc9412.original.xml rfc9412.xml

<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!-- draft submitted in xml v3 -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!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) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-httpbis-origin-h3-03" number="9412" submissionType="IETF" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true"
updates="" obsoletes="" xml:lang="en" version="3">

  <!-- xml2rfc v2v3 conversion 3.15.3 -->
  <front>
    <title abbrev="ORIGIN in HTTP/3">The ORIGIN Extension in HTTP/3</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-origin-h3-03"/> name="RFC" value="9412"/>
    <author initials="M." surname="Bishop" fullname="Mike Bishop">
      <organization>Akamai</organization>
      <address>
        <email>mbishop@evequefou.be</email>
      </address>
    </author>
    <date/>
    <area>Applications and Real-Time</area>
    <workgroup>HTTPbis</workgroup>
    <keyword>Internet-Draft</keyword>
    <date year="2023" month="June" />

    <area>art</area>
    <workgroup>httpbis</workgroup>
    <abstract>
      <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
frame for HTTP/3.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="problems">
      <name>Introduction</name>
      <t>Existing RFCs define extensions to HTTP/2 <xref target="HTTP2"/> which target="RFC9113"/> that remain useful in
HTTP/3. <xref section="A.2.3" section="A.2" sectionFormat="of" target="HTTP3"/> target="RFC9114"/> describes the required updates for HTTP/2
frames to be used with HTTP/3.</t>
      <t><xref target="ORIGIN"/> target="RFC8336"/> defines the HTTP/2 ORIGIN frame, which indicates what
origins are available on a given connection.  It defines a single HTTP/2 frame
type.</t>
      <section anchor="notational-conventions">
        <name>Notational Conventions</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
        "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
        "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
        "<bcp14>SHOULD NOT</bcp14>",
        "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
        "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
        are to be interpreted as described in BCP 14 BCP&nbsp;14
        <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>
        <t>Frame diagrams
        <t>The frame diagram in this document use uses the format defined in <xref section="1.3" sectionFormat="of" target="QUIC-TRANSPORT"/> target="RFC9000"/> to illustrate the order and size of fields.</t>
      </section>
    </section>
    <section anchor="frame-origin">
      <name>The ORIGIN HTTP/3 Frame</name>
      <t>The ORIGIN HTTP/3 frame allows a server to indicate what origin(s)
(<xref target="RFC6454"/>) origin or origins
<xref target="RFC6454"/> the server would like the client to consider as one or more members of the
Origin Set (<xref section="2.3" sectionFormat="of" target="ORIGIN"/>) target="RFC8336"/>) for the connection within which it
occurs.</t>
      <t>The semantics of the frame payload are identical to those of the HTTP/2 frame
defined in <xref target="ORIGIN"/>. target="RFC8336"/>. Where HTTP/2 reserves Stream stream 0 for frames related to the
state of the connection, HTTP/3 defines a pair of unidirectional streams called
"control streams" for this purpose.  Where purpose.</t>

<t>Where <xref target="ORIGIN"/> target="RFC8336"/> indicates that the ORIGIN
frame should be is sent on Stream stream 0, this should be interpreted to mean the HTTP/3
control stream.  The stream: that is, the ORIGIN frame is sent from servers to clients on the
server's control stream.</t>
      <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
mechanism for communicating such flags in HTTP/3.</t>
      <section anchor="frame-layout">
        <name>Frame Layout</name>

        <t>The ORIGIN frame has a layout that is nearly identical layout to that the layout used in HTTP/2, HTTP/2; the information is restated
here for clarity.  The ORIGIN frame type is 0xc 0x0c (decimal 12) 12), as in HTTP/2. The
payload contains zero or more instances of the Origin-Entry field.</t>
        <figure>
          <name>ORIGIN Frame Layout</name>
          <artwork type="ascii-art"><![CDATA[
HTTP/3 Origin-Entry {
  Origin-Len (16),
  ASCII-Origin (..),
}

HTTP/3 ORIGIN Frame {
  Type (i) = 0x0c,
  Length (i),
  Origin-Entry (..) ...,
}
]]></artwork>
        </figure>
        <t>An Origin-Entry is a length-delimited string. Specifically, it contains two
fields:</t>
        <dl>
          <dt>Origin-Len:</dt>
          <dd>
            <t>An unsigned, 16-bit integer indicating the length, in octets, of
the ASCII-Origin field.</t>
          </dd>
          <dt>ASCII-Origin:</dt>
          <dd>
            <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 sender asserts this connection is
or could be authoritative for.</t>
          </dd>
        </dl>
      </section>
    </section>
    <section anchor="security">
      <name>Security Considerations</name>
      <t>This document introduces no new security considerations beyond those discussed
in <xref target="ORIGIN"/> target="RFC8336"/> and <xref target="HTTP3"/>.</t> target="RFC9114"/>.</t>
    </section>
    <section anchor="iana">

      <name>IANA Considerations</name>
      <t>This document registers a frame type in the "HTTP/3 Frame Type" Types"
registry (<xref target="HTTP3"/>).</t>
      <table anchor="iana-frame-table">
        <name>Registered HTTP/3 Frame Types</name>
        <thead>
          <tr>
            <th align="left">Frame Type</th>
            <th align="center">Value</th>
            <th align="left">Specification</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">ORIGIN</td>
            <td align="center">0xc</td>
            <td align="left"> defined by <xref target="frame-origin"/></td>
          </tr>
        </tbody>
      </table> target="RFC9114"/>, located at <eref target="https://www.iana.org/assignments/http3-parameters/" brackets="angle"/>.</t>

<dl spacing="compact"><dt>Value:</dt><dd>0x0c</dd>
<dt>Frame Type:</dt><dd>ORIGIN</dd>
<dt>Status:</dt><dd>permanent</dd>
<dt>Reference:</dt><dd><xref target="frame-origin"/></dd>
<dt>Date:</dt><dd>2023-03-14</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Contact:</dt><dd>HTTP WG &lt;ietf-http-wg@w3.org&gt;</dd>
</dl>
    </section>
  </middle>
  <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>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="HTTP2">
          <front>
            <title>HTTP/2</title>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
              <organization/>
            </author>
            <author fullname="C. Benfield" initials="C." role="editor" surname="Benfield">
              <organization/>
            </author>
            <date month="June" year="2022"/>
            <abstract>
              <t>This specification describes an optimized expression of the semantics 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.</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="Bishop">
              <organization/>
            </author>
            <date month="June" year="2022"/>
            <abstract>
              <t>The QUIC transport protocol has several features that are desirable 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.</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 indicate 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</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 signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  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</title>
            <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>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9113.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9114.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8336.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="QUIC-TRANSPORT">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar">
              <organization/>
            </author>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
              <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 communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion 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 often used as the scope of authority or privilege by user agents.  Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites.  In addition to outlining the principles that underlie the concept of origin, this document 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 indicates 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>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6454.xml"/>

      </references>
    </references>
  </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>