<?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.3.8 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc docindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-pardue-alt-svc-ext-unsupported-00" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.46.0 -->
  <front>
    <title abbrev="Alt-Svc Extension Unsupported">HTTP Alternative Services That Do Not Support Desired Extensions</title>
    <seriesInfo name="Internet-Draft" value="draft-pardue-alt-svc-ext-unsupported-00"/>
    <author initials="L." surname="Pardue" fullname="Lucas Pardue">
      <organization>Cloudflare</organization>
      <address>
        <email>lucaspardue.24.7@gmail.com</email>
      </address>
    </author>
    <date year="2020" month="July" day="13"/>
    <area>Applications and Real-Time</area>
    <workgroup>HTTP</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This document describes an error case when an HTTP Alternative Service does not
support the extension points of the original connection. It defines an error
code that can be used by endpoints to signal the encounter.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
  ALT Working Group mailing list (alt@ietf.org),
  which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/alt/">https://mailarchive.ietf.org/arch/browse/alt/</eref>.</t>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/LPardue/draft-pardue-alt-svc-ext-unsupported">https://github.com/LPardue/draft-pardue-alt-svc-ext-unsupported</eref>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>HTTP/2 (<xref target="HTTP2" format="default"/>) and HTTP/3 (<xref target="HTTP3" format="default"/>) provide
several extension points, only some of which require negotiation before use. For
any HTTP connection that is actively using extensions, it is possible that the
server might advertise an Alternative Service (<xref target="ALT-SVC" format="default"/>) that
contains no indication of whether the current extension points are supported by
indicated server. A client has to proactively engage with the Alternative in
order to determine what extension points it supports, which will often require
the client to establish a new transport-layer connection and HTTP handshake. The
client might determine that the Alternative does not support the same extensions
as the current connection and decide to close the connection. For an extension
that is negotiated via SETTINGS frames, the client might be able to detect the
lack of extensions early in the lifecycle. For other forms of extension, the
problem might not be detectable until later on, for instance when extension
frame exchanges fail.</t>
      <t>The guidance in <xref target="ALT-SVC" format="default"/> has lead to clients that are robust to different
types of failures. Following a "make-before-break" approach avoids active
transfers being interupted by an opportunistic change in connection. As such,
testing an Alternative and finding that its extension points are incompatible is
unlikely to be a hard failure cases. However, Alt-Svc is the primary method of
switching between HTTP/2 and HTTP/3 and there is a possibility that extensions
offered in one version of a connection are not provided in another. It is also
feasible that support for extension points are not unilaterally deployed across
a fleet of servers, whether in the same organization domain or not. A client
might encounter problems with the Alternative due to permanent error or
transient erro due to synchronization or coordination issues between the origin
and the Alternative.</t>
      <t>Advertising Alternative Services has quite a low barrier and does require up
front coordination, meaning it is quite easy for an origin administrator to
configure things that are logically invalid. Alternatives can detect problems
and take action; <xref target="ALT-SVC" format="default"/> defines status 421 Misdirected Request that allows
the Alternative to signal such a problem.  However, there is are cases where
clients will be misdirected to Alternatives that cannot satisfy the extension
expectations of the client. A server that detects this issue can either close
the connection or degrade into a mode that does not use the extension.</t>
      <t>This document defines an error code for HTTP/2 and HTTP/3 that can be sent by an
endpoint when closing streams or connections due to a failure with extenstion
expectations. This clearly disambiguates the failure case from other types, i.e.
general protocol error, which can allow the peer to take more specific meaures,
such as identifying configuration errors.</t>
    </section>
    <section anchor="conventions-and-definitions" numbered="true" toc="default">
      <name>Conventions and Definitions</name>
      <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&nbsp;14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they
appear in all capitals, as shown here.</t>
    </section>
    <section anchor="detecting-and-signalling" numbered="true" toc="default">
      <name>Detecting and Signalling</name>
      <t>HTTP/2 and HTTP/3 endpoints might use various means to detect that a desired
extension is not supported on the connection, no specific measures are
prescribed by this document.</t>
      <t>When an endpoint detects that a desired extension is unsupported it MAY
terminate a stream or a connection with the error code EXTENSION_UNSUPPORTED or
H3_EXTENSION_UNSUPPORTED.</t>
    </section>
    <section anchor="http2-error-code" numbered="true" toc="default">
      <name>HTTP/2 Error Code</name>
      <t>EXTENSION_UNSUPPORTED (0xf10): The endpoint detected that its peer wants to
use an extension that is not locally supported, or the peer does not support an
extension that is desired.</t>
    </section>
    <section anchor="http3-error-code" numbered="true" toc="default">
      <name>HTTP/3 Error Code</name>
      <t>H3_EXTENSION_UNSUPPORTED (0x1f10): The endpoint detected that its peer wants to
use an extension that is not locally supported, or the peer does not support an
extension that is desired.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>None, probably.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This specification registers the following entry in the HTTP/2 Error Code registry
established by <xref target="HTTP2" format="default"/>:</t>
      <dl newline="false" spacing="normal">
        <dt>Name:</dt>
        <dd>
  EXTENSION_UNSUPPORTED</dd>
        <dt>Code:</dt>
        <dd>
  0xf10</dd>
        <dt>Description:</dt>
        <dd>
  Extension unsupported</dd>
        <dt>Specification:</dt>
        <dd>
  This document</dd>
      </dl>
      <t>This specification registers the following entry in the HTTP/3 Error Code registry
established by <xref target="HTTP3" format="default"/>:</t>
      <dl newline="false" spacing="normal">
        <dt>Name:</dt>
        <dd>
  EXTENSION_UNSUPPORTED</dd>
        <dt>Code:</dt>
        <dd>
  0x1f10</dd>
        <dt>Description:</dt>
        <dd>
  Extension unsupported</dd>
        <dt>Specification:</dt>
        <dd>
  This document</dd>
      </dl>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="HTTP2" target="https://www.rfc-editor.org/info/rfc7540">
          <front>
            <title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7540"/>
            <seriesInfo name="RFC" value="7540"/>
            <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>
        </reference>
        <reference anchor="HTTP3" target="http://www.ietf.org/internet-drafts/draft-ietf-quic-http-29.txt">
          <front>
            <title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-29"/>
            <author initials="M" surname="Bishop" fullname="Mike Bishop">
              <organization/>
            </author>
            <date month="June" day="9" year="2020"/>
            <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>
        </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>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="BCP" value="14"/>
            <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>
        </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>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="BCP" value="14"/>
            <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>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="ALT-SVC" target="https://www.rfc-editor.org/info/rfc7838">
          <front>
            <title>HTTP Alternative Services</title>
            <seriesInfo name="DOI" value="10.17487/RFC7838"/>
            <seriesInfo name="RFC" value="7838"/>
            <author initials="M." surname="Nottingham" fullname="M. Nottingham">
              <organization/>
            </author>
            <author initials="P." surname="McManus" fullname="P. McManus">
              <organization/>
            </author>
            <author initials="J." surname="Reschke" fullname="J. Reschke">
              <organization/>
            </author>
            <date year="2016" month="April"/>
            <abstract>
              <t>This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.</t>
            </abstract>
          </front>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t>Patrick McManus, Mike Bishop and Ryan Hamilton shared some opinions on the error
cases of Alt-Svc, in various channels, that have been incorporated into this
document.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIABhUDF8AA81Y224juRF951dwnZddQK34MsHMKhgkWtubMeBbLDkXBMGC
6qYkwi2yQ7KlUQz/S74lX5ZTxb7J9gIJkof4xa3uZrEu55wqdpZlIppY6on8
Mp/fy2kZtbcqmq2WM+23JtdBztcqygsnb12Us7qqnMdPHYzXhbz8GrUNxtkg
1GLh9XYij2Akm23z/pl8tCGt08WRKFxu1QY7Fl4tY1YpX9Q6U1gUtnmmv8as
7l/Pjo9FrqJeOb+fyBALIUzlJzL6OsTT4+Pvj0+F8lpN5LSqSoNXyRepbCEf
tCqzudlosXP+aeVdXaUoxZPe41YxkVeWwtUxuyBXhAgRC39SpbNwb6+DqMxE
/iW6fCThtbGFtnEkAzzzehlwtd80F9GbHI9yt6lUc7HBy3hkbGms/qsQqo5r
5ydCZkLiz9gwkddjec/x862Ulus6V2F42/mVsubvHNpEnpeuLpYlguaHeqNM
OZElLUqpHJ9+GH/87Yruj+GGENb5DZd0guTZ5eBXlmVSLeA8fBZivjaB4qzJ
c1nokHuz0JRMqb13XmILLXdrbenWz+EFFrDGuiiaIsq41lJ3WKicQV6kW/J9
583KWFUiYdbqnEIcyyvafYms9XuL3BUaK4DEHPcWWtYB8FvspbZFYzI6GcyK
jPGONnc11Xec4tyYoii1EL+gqntX1LyZEBTHL0/lt8/P39Dl6eeHH88//urD
8cvLdwwjfn7WPT/7fJVdjI2Oy+xvtcmzdYwVvVp5tzWFFkFvtYcLrwMeSWfL
PbCz0RT7bm3ytfQaNryWFviOhguM0FAhDm8sf0Tgyu5TrvsMpTygWCgbMg+z
dTB21e9JsOMXKheCWZRN5pAW+OfhILKxWkepClxHg6oip+/VElH/Zno9z2Z/
OOe8fDr7RMGSNVTERgUUo9YAc9FwLwWnsZXnMuS19wSnNwAAgGVHcxRSNDbw
I/k4llOZl4YWrxVXFznuItZ2pVZAo4lr3mfovbEC9CYHHICE+xtgCV6pd9xA
nhovkLRUlZ0pS4SBF9sCCY4k+QKbGjqxKE1YS4XS7SBGygYykZVqj20HlWoR
hBBsEdbqCVWdowyNsVSG3se2TAfhtISSQ0IFaMWg4IIyNEj3KxcKnRvij0MU
Luj06oBxABpTrbUnWoS1yERVtkbJ2eV8fnX7u5lceuyPjA0Sk2IBMxUDLqU+
T6grVf5EyOgdllp5lNFYNlGapc73eZkwLx3Dh5QqHKzi/QRggB02zYaUGGya
NuOtwXpTyhJOwxLWwA6pLbQ9b+Srj5PjwO8c9VkhzUtSTZJCLVe1KXgJfHx+
bljw8sJgLLUqUjYp9JDqRoiGa2hMHL1ZLjXVQsR9pTkOMl57HSjIsnQ74qyS
RxugIku0z9BC1dORVBVjHQDbOlO0RBcMNFgNiJgWG9K3ukoEogI6BkhtTYgm
lyko8n9Y62kAkPL1SETgmF045D7hZUlkxKMEAwT4Ln2N5X4XWWFMEDVa3ROR
E+ETDpAqX7RRc/dA6F/cjiRyJNsxwSTkVt5slN/LDbTDFUiXCCB3viY3Fjru
tE49B1o9kGW6JLBolsNG70xp4j75PmCI43oUlA70dwkfQqNX6oAupMfAVCPo
/L6yjEjuTLRPGZxYajWQ1paahLV3c0UmURdGpSqRo0JXpdvDvso9vBZKLkut
I/mT9I/1KAlpwxLm/HAagDSgzSMGT/Z7wRSJGl0LlA1lwvt6iaGB5RUipCyL
Nbd7NB8GnGlvtS+Gvc3X3nVe0GjgoLjGpt8mhFqHrmp9nxdNuYa7g23Tpg1R
qd+dQIlyEOJImAJv5EJ5b7RP0kbq2DbSugKjHetf788ImELKiC9cvmQJ5dtz
uYg27B3aIUTY0DgUHTUPanFLsyLwRsLhgOelW6FZlaxgW1WaYjz0PPCQ0uhf
m/sUPLjObHb21weq0g48kKlYB/nh9ETemFAgqJzo/YAANQkLO0DiEcTrMvbz
D/Gb2JB2HsuedD1XWkYSyHzbkEJqfiDvZrA5DB8E145h3JNwLyz3h0Oe0F8r
UuM0jDejXtqBQNrMIGwmJYlswikGDudOGwY+dytx2K0IboVeeVWQAsE3JTfd
cNj1yrrpcp1P47cD7uGIKXnEJES8lZnh4BloMcutaGfP1FXIWUIZAKQVda7h
JBBa8qhOEJmLyb/4Omk0JcBZdERuk4UB9xeAIuQjyeVQVdGN3aZpmtxsMP6N
QayVtjyLAgc4w7gyxdmOORQOIynJr07zEgN0QxNogDdmiTYC9lDXGokEK5SJ
zkFmuadgW4ok5vMGAanGmH3u7Jbea89jF5Rvw79Tg8UxTNI5LMijm8fZ/GiU
/svbO75+uPz949XD5QVdz75Mr6+7C9G8Mfty93h90V/1K8/vbm4uby/SYtyV
B7fE0c30z3hCXh3d3c+v7m6n10dJZYcIIY6kVsaNtvKa2KCCaM9G3Bx+OL//
5z9OPoDN32BEPj05+R50Tj8+nXz8gB+EjrQbnwHSTyR9L9DnUWBuMaBdrioT
0VxGlOSwdjsriZspnRdMlNSvCzljouNkuepOMAO49mei1AiIDFvljYOykBaG
g/GMFIWOe3SgF33zMgdDpybnX82NIxr9hzAJhBNKG2a0LkWL/WFaEc4fmzNk
x59eBYbOyANnBl8FSMhRQpHGZsV9IbGOSHfQzruGN+D45Z/ml7czVP2nx9vZ
4/393cP88oLa3Zezn959NqYCNGm+ZDvnsCPE+4a+Pf66PDn+bkKD/usQSU3b
mYopt1Pp6CrqdArrQ+5GcBShdKnZdBkYUaAdb9+cEEib3hhqstoHc3YQzM8F
T/Gc/J8HhIhmGmcfmvugOwEKlRQJUnOLaW/EvRCng316+Wp6O33zIituC+ek
Z16vMA/QwM2a203tgLHvDi9vgNEs83vRnRQTD56f+RPDy8sEbtHHHjF5H4xC
kB16zFgS4oLpVPEnIFrU5WLACiFmQ+fpvYOO919GePbvR3j2n0V48j8Mkb/1
LHDcpDJP8yfrdqUuVvwxTjxPbL1Z0Cng89ESQquPXoS4V/Tx7kne5DfK1hDf
Gxxi5A8IyVXpQ+KePnepjSkjvMEhnqQpfcip0NF4xLG9xog0VmHqaU449A2w
k186k1ld8tFZ0ZcNDG4LmpLpMOURJZ+1ea4h1RS9av4LP5yHA6wVAAA=

-->

</rfc>
