<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.3 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc docmapping="yes"?>

<rfc ipr="trust200902" docName="draft-pardue-quic-http-unbound-server-push-01" category="info">

  <front>
    <title abbrev="USP for HTTP/QUIC">Unbound Server Push (USP) for HTTP/QUIC</title>

    <author initials="L." surname="Pardue" fullname="Lucas Pardue">
      <organization>BBC Research &amp; Development</organization>
      <address>
        <email>lucas.pardue@bbc.co.uk</email>
      </address>
    </author>

    <date />

    
    
    

    <abstract>


<t>This document defines an HTTP semantic extension, Unbound Server Push (USP),
which allows HTTP resources to be pushed without the need for a prior HTTP
request. HTTP/QUIC clients opt in to this feature via an HTTP/QUIC setting.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>HTTP server push is a feature of HTTP/2 <xref target="RFC7540"/> and HTTP/QUIC <xref target="QUIC-HTTP"/>
that allows a server to pre-emptively send HTTP resources to a client in
association with a previous client-initiated request. This binding to a request
object aligns with paradigms familiar to client and server implementations.
Unbound server push, in contrast, may provide benefits for use cases where
holding a request object open for long periods (long polling) is undesirable, or
where a request object does not exist (unidirectional flows). (The introduction
of unidirectional streams in the QUIC transport <xref target="QUIC-TRANSPORT"/> provides a
direct expression of this message exchange pattern.)</t>

<t>This document defines an HTTP/QUIC protocol extension that allows a server to
send one or more HTTP/QUIC <spanx style="verb">PUSH_PROMISE</spanx> frame on a new server-initiated
unidirectional stream type: the unbound promise stream
<xref target="unbound-promise-stream"/>. Endpoints opt in to the unbound server push feature
using a <spanx style="verb">SETTINGS</spanx> parameter (<xref target="enable-usp"/>) in accordance with Section 5.5 of
<xref target="RFC7540"/>. This is the only behavioural change to server push as described in
<xref target="QUIC-HTTP"/>. Unbound server push operates in addition to bound server push for
any HTTP/QUIC connection.</t>

<t>Unbound server push should be used with care. It may introduce complexities for
implementations, particularly intermediaries, and it can pose challenges for
presentation to the application above HTTP.</t>

<t>In deployments where multiple client connections are trunked by a reverse proxy
onto a single upstream connection, unbound server push is effectively a mechanism
for achieving application-level multicast to all downstream clients that have
enabled this feature.</t>

<t><list style='empty'>
  <t><spanx style="strong">Authors’ Note:</spanx> Unbound server push is proposed as an extension to
HTTP/QUIC in order to start a discussion on whether this feature should be
incorporated into the core HTTP/QUIC specification document.</t>
</list></t>

<section anchor="notational-conventions" title="Notational Conventions">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.</t>

</section>
</section>
<section anchor="unbound-promise-stream" title="The Unbound Promise Stream Type">

<t>An unbound promise stream is indicated by a stream type of “0xTBD”. Data on this
stream consists of one or more <spanx style="verb">PUSH_PROMISE</spanx> frames, sent in accordance with
<xref target="QUIC-HTTP"/>. Only servers can promise; if a server receives a client-initiated
unbound promise stream, this MUST be treated as a stream error of type
HTTP_WRONG_DIRECTION.</t>

</section>
<section anchor="enable-usp" title="The SETTINGS_ENABLE_UNBOUND_PUSH Parameter">

<t>This document adds a new HTTP/QUIC <spanx style="verb">SETTINGS</spanx> Parameter to those defined by
Section 7.3 of <xref target="QUIC-HTTP"/>.</t>

<t>The new parameter is <spanx style="verb">SETTINGS_ENABLE_UNBOUND_PUSH</spanx> (type = 0xTBD). This setting
can be used to enable unbound server push. The value of the parameter is an
integer that MUST be 0 or 1. Any value other than 0 or 1 MUST be treated as a
connection error of type <spanx style="verb">PROTOCOL_ERROR</spanx>.</t>

<t>The initial value is 0, which indicates that unbound server push is disabled by
default.</t>

</section>
<section anchor="usage-of-unbound-server-push" title="Usage of Unbound Server Push">

<t>Unbound server push changes only one aspect of HTTP/QUIC server push: the stream
type on which an HTTP/QUIC <spanx style="verb">PUSH_PROMISE</spanx> frame can be sent. It does not prevent
the conventional use of bound server push; both types MAY be used concurrently.
The Push ID number space is shared across both types. Unbound server push is
subject to the limits imposed by the HTTP/QUIC <spanx style="verb">MAX_PUSH_ID</spanx> frame.</t>

<t>An endpoint that receives the <spanx style="verb">SETTINGS_ENABLE_UNBOUND_PUSH</spanx> parameter set to a
value of 0 MUST only send an HTTP/QUIC <spanx style="verb">PUSH_PROMISE</spanx> frame on an appropriate
client-initiated bidirectional request stream. An endpoint that has set this
parameter to 0 and had it acknowledged MUST treat the reception of an HTTP/QUIC
<spanx style="verb">PUSH_PROMISE</spanx> frame on any other stream type as a connection error of type
<spanx style="verb">PROTOCOL_ERROR</spanx>.</t>

<t>A server that receives the <spanx style="verb">SETTINGS_ENABLE_UNBOUND_PUSH</spanx> parameter set to a value
of 1 MAY send an HTTP/QUIC <spanx style="verb">PUSH_PROMISE</spanx> frame on an unbound promise stream.</t>

<t>A client that has sent the <spanx style="verb">SETTINGS_ENABLE_UNBOUND_PUSH</spanx> parameter set to 1, and
received this parameter set to a value of 1, SHOULD be ready for a server to
send an HTTP/QUIC <spanx style="verb">PUSH_PROMISE</spanx> frame on unbound push streams at any time.</t>

</section>
<section anchor="rtt-considerations" title="0-RTT Considerations">
<t>Client 0-RTT is not affected by server push configuration. There are no
additional consideration to be made beyond those defined in <xref target="QUIC-HTTP"/>.</t>

</section>
<section anchor="handling-multiple-clients" title="Handling Multiple Clients">
<t>Unbound server push was discussed during the development of HTTP/2 <xref target="RFC7540"/>.
The assessment was that servers that handle multiple clients within the same
stack or context (such as an HTTP intermediary) may have a difficult time
routing promises to the correct client. The applicability of unbound server push
should be assessed and enabled where the risk of misdirected promises is
determined to be acceptable.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">
<t>There are no additional consideration beyond those presented in <xref target="QUIC-HTTP"/>.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<section anchor="registration-of-unbound-promise-stream-type" title="Registration of Unbound Promise Stream Type">
<t>This document establishes an entry for the HTTP/QUIC Stream Type registry that
is established by <xref target="QUIC-HTTP"/>.</t>

<t><list style="hanging">
  <t hangText='Stream Type:'>
  Unbound Promise Stream</t>
  <t hangText='Code:'>
  0xTBD</t>
  <t hangText='Specification:'>
  This document</t>
  <t hangText='Sender:'>
  Server</t>
</list></t>

</section>
<section anchor="registration-of-settingsenableunboundpush-parameter" title="Registration of SETTINGS_ENABLE_UNBOUND_PUSH Parameter">
<t>This document establishes an entry for the HTTP/QUIC Settings Registry that is
established by <xref target="QUIC-HTTP"/>.</t>

<t><list style="hanging">
  <t hangText='Name:'>
  <spanx style="verb">SETTINGS_ENABLE_UNBOUND_PUSH</spanx></t>
  <t hangText='Code:'>
  0xTBD</t>
  <t hangText='Specification:'>
  This document</t>
</list></t>

</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>

<reference anchor="QUIC-HTTP" >
  <front>
    <title>Hypertext Transfer Protocol (HTTP) over QUIC</title>
    <author initials="M." surname="Bishop" fullname="Mike Bishop" role="editor">
      <organization>Akamai</organization>
    </author>
    <date />
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-13"/>
</reference>
<reference anchor="QUIC-TRANSPORT" >
  <front>
    <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
    <author initials="J." surname="Iyengar" fullname="Jana Iyengar" role="editor">
      <organization>Fastly</organization>
    </author>
    <author initials="M." surname="Thomson" fullname="Martin Thomson" role="editor">
      <organization>Mozilla</organization>
    </author>
    <date />
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-quic-transport-13"/>
</reference>




<reference  anchor="RFC7540" target='https://www.rfc-editor.org/info/rfc7540'>
<front>
<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
<author initials='M.' surname='Belshe' fullname='M. Belshe'><organization /></author>
<author initials='R.' surname='Peon' fullname='R. Peon'><organization /></author>
<author initials='M.' surname='Thomson' fullname='M. Thomson' role='editor'><organization /></author>
<date year='2015' month='May' />
<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 perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.  It also introduces unsolicited push of representations from servers to clients.</t><t>This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.</t></abstract>
</front>
<seriesInfo name='RFC' value='7540'/>
<seriesInfo name='DOI' value='10.17487/RFC7540'/>
</reference>



<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<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" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<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>




    </references>



<section anchor="acknowledgements" title="Acknowledgements">
<t>The author would like to thank the following for review prior to publication:
Richard Bradbury.</t>

</section>


  </back>

<!-- ##markdown-source:
H4sIABH2OFsAA61Zf28jtxH9n5+C9QGtfbBU+5IgjYMWlX8k58C2XElGGxSF
Te1SEutdckNy7VMNf/e+IbmrlSzlkrRBisi7S3LmzZs3M2yv12Ne+UKe8Ds9
NbXO+VjaJ2n5be0WfP9ufHvAZ8byj5PJ7R//dnd5xsR0auUTvh/fbrzJTaZF
ia1yK2a+Vwmb17L3U62y3sL7qlfHE3ounNCrcELv6JjlwmPNy/lgcvHKMvwx
N3Z5wpWeGaYqe8K9rZ3/cHT0zdEHxpjzQuf3ojAaq5bSsUqd8H96kx1yZ6y3
cubwa1nGH7CpFFWl9PxfjInaL4w9YbzHOP5R2p3wqz6/DYaGR9H+qzoTrvvY
2PkJPz094yPppLDZgv+en8snWZiqlNqHb2QpVHHCC1rbj77/dTrN+pnp14+M
aWNL4dWTxPGc4OoRcCdhaYrA3sdlJa2XnzyfWKHdjMJgDVwzBd+nzw+4odjQ
8r2wcg07egBslXSEXdya80vtpdXS984pKk1wlPSzTmiOvwhftwCFf3rpvwmp
6z4/VW5hqvZxROtaPcrNNwGwwaMAJu0za8hJmStvLGtAmIwGN+Pb4WiyjgS9
wwb87vy2dyqczPl1XXhVFfITfotA06y2MgJVIe7/Nzx8s+MvAuWHPr9cSj0X
dgOVH4QWb14FWL4TzhfL7bDsAn6yMKUzehN5Yb3Sb16GU67Nf1RRiB3o93o9
LqYOvmaesclCOcqUmsjMczlTWjqgHHIbEJZCe5VxEFNqp4w+3C0Wh+x5oZAf
oijMs4sbWOlMbTNs6Q2fSk6Jjyg+K+Bae+4XkmuJB6QmgldWJVVhVv5US+f7
K43hWaFgo+Om8gCHNvRk/EwKT3R4UqKxO37vpAdE8350uVR5XkiIyDuigTV5
nXn4w1hyNDhD5nHsKdpdzSzu+IG/vPxu9N3Z1199efT6Gmi4Ounlpc3q11fm
F8I3IIhmZ1hbWdmTZUVCUCzxPG2xjpFIbsJDJpwzmRJkZkAsICSflKld+qqn
tPL4Agi2gIWITpXO4XvcMb1iZvpvmZFpaq5d3BFiJXI1LwGjKFWhRLA0mUBO
JvNVifwjigRrXJ81LOgAd0hRyQzABcsPeSmWMNc8qVwi8hrMQuwozrWTHEIJ
f58X0kq2MEWwtTWUJ0NNJXVYAcGfc+ijMrnj+/EvUxRYdEDRgh3IcyumhTxE
BrCw7dvtcoMjtfEgs8LT/VqrXFkZaCAKPqOAHfT5/gSkVF2KgAMb3yJ7pABo
REN8HUjQikdDh1bfwJcEBAjB4j4wArF0lFLEscDkEn+LucSrbCE0flTCk2D1
Dz6Tp5GFVVMv2mTlO6jIAvlQRYEWLw3AWu3ycHs3/nh/OxpeX44vHvjMQm7w
KZZr+Zy2WNGObQWGe1SzkwBNKvxkXKkQ+PgBe3lpOoL0ohdfvL72+YXOK6M2
M321VTdXU5qy2kUGPYwvJpPLm+/HD4HapQR+fP/lRWpiR6921evrAe0psszY
XOhMxkQYRxf4V/2vEA/WTfaUUviXrDAayTuVC0F5aOFyihWM7BqGJgLhzqya
IjeRy2sS0edb0ofoboFpYJXIodYhgpDNt16D5EIvu9potI4eQO62bY4SXRc5
SXDtkgAjCa1EDfMhVRvGIzcNJfsnnC9DwrKN5D8kaFEU6kLYIiyUtkR1EVRu
D4NqKI/NNZKUUn0BAqIWps2I9c1WTWTRpRUqi4/EFH1O8AyeXGqgWBVmWQbl
j4ldpnagkamV7yA53qNn1I/wcboMGgAIYAVo9mnJIE4kiEQWrK+rRNfVDodb
WYbQy9mMvgjSLZCpFHXlShYKV7ZQkGUi4MqRXkFNYjQWaueDFBcFcvhZN8em
ghayFISSLNI0XytsgOEv/P37QWhF3B/4jUGf8/79VgphFRwl2HNiIELQ0QKD
fVaMAcmQALEyoa+GbAmeK5fVSZM0oY3g2PUq2/IImymNHILihfqjdApmtq4n
rpKZmjXRbRQMTr17R66IJBxnRj/hOQWRxE7yR7nkz7DQ8b3ru/Fk7zD+l98M
w+/RBXYfXZzT7/HHwdVV+6P5YvxxeHeF9yz9Wq08G15fX9ycx8V4yjceXQ9+
3Is83hveTi6HN4OrvSj1yrFWgwPVQlMTMgC89hH1bt7z07Nbfvxlah4+HB9/
g2IQ//jT8ddfolsAyjoeFpQl/gkcl0QmDBxBDcCbTFTKi4ISzFEUnjWnbCAg
OeHV0OE2Ce04cmwCJeYv73aoLWMDvUOiiUvURGQhuiGXOuJONWvv6NPk9Hyv
z8+FF9wkfFYp5VBlHX3YLTTbygsNbbHl2ZTlTdkc6tA5EeFdVJho87dczVYF
DuVIIlNd20yt1attzh5GkgeCTUlBpEjBbL2W1sIHKtVwPzSN938fDW++vz8H
Dc+IJW0omhp0f3EzOL26uL+7OR3e3Zzfk+s0Wqay9PKuU5U2KzwKgEs1t1Ob
V9VttU1IOxLa2BRQrFhTzb7uf0Emr6MY84t2XpVIHP3wc2Y/8P0Q9j/zEPSD
VBNTi80oFE1pgT3Rr21S2g8APYmilrHtketGCM0om+ZBdqCKTUSOiEDHfT5A
1Uurkzbh5Phya/TYStrXIwgijoaT4dnw6v5iNBqOHhIskSlFOgQWHR3yONY0
yZD0ekedgIRGCUcUEBAB+Q+8uAudHQ7fMj5tr9ixr3BRFiiFBEmpbyeSNOO0
C2K/lfqrmKM6mb7WJm5t8FIAKQ1DR9D2yjRw0DVHVPZGowEQdfEw5Y3d3+IR
egsyAAk1+LHlBVZjbLfYoFj2A9ZhdLw857oup1jtKpEFyN0C2or4ZdY419lu
e9tEmlPHDj9VoEKVNGugbQmFENpFTzsIXA/+EVh9f3meAOgHJZSp84wRbmWE
Vn8mO1YkRkqEUs9akh9FZhrdTH2fDwf1QZoKAIq5JeFib+a96Vrf3Yw6MfyU
JxvOLISLppFGV13xOArFZyFC1yayR22ewd853buQ2SGbAgSER+XTwNL1ge32
YZnytFs6gqruyku2JS8H7eTyv4clJjaNdMeBnb8qINuLR7Aw9aIdrLX/TRYe
h2aAJS9TK7jLD0INC1KDM6UYiXyZblM2xr1f5GTrYZgZ0pRLMyQi6VUZ242j
3mgyoY7NYaS1cShgZxGA+E5F8RChaY4puCZtRs/UvI5LQ0mgeR3/04Y1kw9N
Vt0TUq9VinCdsDQ63yh76B4269w7/hFY0j1Be4fIo51uq+Q+C9f0wNgwr224
QlnQGe2F744boahoAgudC5/RXoENTbuSqAF73oww8TImXSY4hIJuurNHKmt0
n0K3wvuuzhappw+3Rp2xa3kQJjiaIEITP5vRcOZDwJg1NZXohrOOr9r0cA8R
LYh1OY0vU1Uov+Th2uMNSGw1SUZv06VsM7rEGS3ohXKPtAmOjVIl85UV1EkT
ocsQuxhbNH8QGNomxC5c85IhG0zr0oXvpMsaR9LQuYsll4ObweYpNJ+M5FzR
RWkjej/TY2+0b9Bi+KHcIl7S4JGNableibpNuo2HLQNRGI2c7R4hgTbN7qw9
YSc7bGPszOThfejbsKo7jtHzNbvxHlIhLb2IDcpWHH5Zg/sbIYktpWsOjXgQ
Xz6Dxw3di8PunxfcXw0I3R1PkYzEk8GqOoYLiZjzYTDHrEpZUdD/IRIyTOjH
4NnM0PUbZSD5Ste31HiHi266E66nRXv2CL2asDk/tSKf1hZd0n8Bzp68/qQb
AAA=

-->

</rfc>

