<?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.37 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-pardue-httpbis-dont-be-clear-00" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <front>
    <title abbrev="Reserving clear">Reserving the clear ALPN Protocol ID</title>
    <seriesInfo name="Internet-Draft" value="draft-pardue-httpbis-dont-be-clear-00"/>
    <author initials="L." surname="Pardue" fullname="Lucas Pardue">
      <organization>Cloudflare</organization>
      <address>
        <email>lucaspardue.24.7@gmail.com</email>
      </address>
    </author>
    <author initials="A." surname="Ramine" fullname="Anthony Ramine">
      <organization>Cloudflare</organization>
      <address>
        <email>nox@nox.paris</email>
      </address>
    </author>
    <date year="2021" month="March" day="16"/>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>HTTP Alternative Services (Alt-Svc) are identified by a tuple of
Application-Protocol Layer Negotiation (ALPN) protocol identifier, a host and a
port. The wire format for Alt-Svc is defined in ABNF and encodes this tuple or
the keyword "clear", which has a special meaning. This memo reserves the ALPN
protocol identifier "clear" to reduce the chances of accidental aliasing with
the "clear" keyword.</t>
    </abstract>
    <note>
      <name>Note to Readers</name>
      <t><em>RFC EDITOR: please remove this section before publication</em></t>
      <t>Source code and issues list for this draft can be found at
<eref target="https://github.com/LPardue/draft-pardue-httpbis-dont-be-clear">https://github.com/LPardue/draft-pardue-httpbis-dont-be-clear</eref>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>HTTP Alternative Services (Alt-Svc) <xref target="ALTSVC" format="default"/> are identified by a
tuple of Application-Protocol Layer Negotiation (ALPN) <xref target="ALPN" format="default"/>
protocol identifier, a host and a port. The wire format for Alt-Svc is defined
in ABNF and encodes this tuple or the keyword "clear", which has a special
meaning. This memo reserves the ALPN protocol identifier "clear" to reduce the
chances of accidental aliasing with the "clear" keyword.</t>
      <section anchor="defs" 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>
    <section anchor="aliasing-and-avoidance" numbered="true" toc="default">
      <name>Aliasing and Avoidance</name>
      <t><xref target="ALTSVC" format="default"/> Section 3 defines the Alt-Svc header field using ABNF. It requires a
custom parser, which introduces a possibility for custom implementation errors.
The Alt-Svc header field value can either be the keyword "clear" - a special
value that invalidates cached alternative services, or a list of <tt>alt-value</tt>,
that includes an encoded ALPN protocol identifier <xref target="ALPN" format="default"/>. There is a chance
that someone unwittingly defines the ALPN protocol identifier "clear" for
genuine purposes but is unaware of the use of protocol identifiers in
Alternative Services. This could trigger Alt-Svc parser errors that might
lead to confusion between the keyword with the protocol identifier use. Since
the "clear" keyword has special meaning, confusion might lead to detrimental
effects.</t>
      <t>To prevent unintended aliasing, this document registers the "clear" ALPN
protocol identifier. It relates to no actual application-layer protocol,
effectively reserving the code point and preventing any unintended aliasing.</t>
    </section>
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Broken Alt-Svc header field parsers might confuse a "clear" keyword with a
"clear" ALPN protocol identifier. This could invalidate Alternative Service
cache state but a conformant client should fall back safely as described in
Section 2.4 of <xref target="ALTSVC" format="default"/>.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="registration-of-clear-identification-string" numbered="true" toc="default">
        <name>Registration of "clear" Identification String</name>
        <t>This document creates a new registration, "clear", in the "Application-Layer
Protocol Negotiation (ALPN) Protocol IDs" registry established in <xref target="ALPN" format="default"/>.</t>
        <t>The "clear" string is a reserved value that does not identify any protocol:</t>
        <dl>
          <dt>
Protocol:  </dt>
          <dd>
            <t>Reserved</t>
          </dd>
          <dt>
Identification Sequence:  </dt>
          <dd>
            <t>0x63 0x6C 0x65 0x61 0x72 ("clear")</t>
          </dd>
          <dt>
Specification:  </dt>
          <dd>
            <t>This document</t>
          </dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="ALTSVC">
        <front>
          <title>HTTP Alternative Services</title>
          <author fullname="M. Nottingham" initials="M." surname="Nottingham">
            <organization/>
          </author>
          <author fullname="P. McManus" initials="P." surname="McManus">
            <organization/>
          </author>
          <author fullname="J. Reschke" initials="J." surname="Reschke">
            <organization/>
          </author>
          <date month="April" year="2016"/>
          <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>
        <seriesInfo name="RFC" value="7838"/>
        <seriesInfo name="DOI" value="10.17487/RFC7838"/>
      </reference>
      <reference anchor="ALPN">
        <front>
          <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
          <author fullname="S. Friedl" initials="S." surname="Friedl">
            <organization/>
          </author>
          <author fullname="A. Popov" initials="A." surname="Popov">
            <organization/>
          </author>
          <author fullname="A. Langley" initials="A." surname="Langley">
            <organization/>
          </author>
          <author fullname="E. Stephan" initials="E." surname="Stephan">
            <organization/>
          </author>
          <date month="July" year="2014"/>
          <abstract>
            <t>This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7301"/>
        <seriesInfo name="DOI" value="10.17487/RFC7301"/>
      </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>
    </references>
    <section numbered="false" anchor="acks" toc="default">
      <name>Acknowledgments</name>
      <t>Your name here.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIALL8T2AAA5VX4W4TORD+76eYC38AZUNbuAOi40RoQVQKaa8JJ6HTCZxd
J2uxa+dsb0NU9V3uWe7J7ht7t00gHFCpm12vPTP+vm9mvFmWiaBDpYZ0obxy
l9osKZSK8kpJR6Px+YTOnQ02txWdngg5nzt1uT05ThSFzY2sYaVwchGylXRF
o7IyhNVc+6ywJmRzlcW52cGByGVQS+s2Q/KhEEKv3JCCa3w4Ojh4enAkPqrN
2rpiSKcmKGdUyE7YrhA+SFO8l5U18LVRXqz0kP5EeH3y1gWnFh53m5pv/hJC
NqG0bigoE4Q/bfyQxgM6j+HFoRT1uMml3x62bjmk48o2xaKSLo2pWupqSBXP
TRscHD0aPH6+5PFBbmux42c0oAtZa7PtZ2QQj9lsv/gfT8Z+eo7/AZxpL/CX
ZRnJuQ9O5sDi9Wx2TqOKAZJBXyqaMiW58nQXo9n0Mr9HsEi6UCbohVYFzTck
KTSrSpFdiNFqVWlQoa3Jbkgey41yNAE9QcdXsAYV3KNVN+PGnuvDWml9IJBC
UqzAwIBmUM9aw+/CuloG/qE2HtKeCrXA1gtgRKMXk1dxqTK5LRB3KDGhDc8J
lmErBOpF6fT6tC51XlIJtiT5lcq1rKhW0kCK7Brra1VbclGf0aSKKhZ7wu+s
UuAFRZOrJP1SGkbRLkjmeZwOJ7LS0rPg1zqUMbZudRvjIPFjbFDvJ3wJ9v2F
koVy4O7+xatjenlyOju7GBL2J72Cy9peqrRpr/KI9VwBLkWrZt4xc1+IqW0c
YmOMIlza+wbxVdondKOFmHiUS7aB0YYZCeJXTkE/fPBgiaibOav0wTjp/MG3
U/W3QSu6WhdFpYS4wwnpLKDi0L5PgldXP43Gs+kfx8+AweMnD59cX++Tpehk
ST8my2j+fBKNPzw4vL7ex/SuUOlHhCq+KVT6XqGK7xHqvjzbL1TxHUKl/UIV
d+7QsTWX7MAaH/d2wvvV6fnqDnbvr4WYpa0Rr/PUe/N2OsPe4i9NzuL9xcvf
355evDzh++nr0Xh8cyPaGdPXZ2/HJ7d3tyuPz968eTk5SYsxSjtDovdm9A5v
OLre2fns9GwyGve4ciTF27ypsYOoJiAD3WtuFyunAkQlvQBVudPzVG1eHJ//
+8/hIxYMtHJ0ePgUQkwPTw4fP8LDulQmebOm2rSPAHAj5GrF7RBWZFUhyVYa
SKPTgF1f2rWhUjnFuCJDRh3+bGh0aXXBLAlxdZXSAI6mbbY/bEXWst9qr4xF
g0B8VVATTbEAB3QawP7fDSQLxkSOdmlrQv56FnjSm27Tk2dA5t7rua502ERx
tyt0Dd0ycCmPlHPW+UGkem8Il7JqVKwsCorC8FztkzxlW0pPa0KJtNIGDwAh
IKZc5iVTs1UxfFsx+pxJMhU1CPoD5mTRyoe+aO3kVcPJx4HEPCy+njAM9vnk
+jpmORcbxiPlS7Lmba1wiKDGIE0CMAbhO2R8KxUBqFgq02AFyrUD1lg5bwK7
aoxcsyixD7bV+Hi7x5rHrsS++tmWiNw2ICA4vVyq2+KUKG+JSyDXelkGgcgK
zoTcmgWEE/tJWCtldvi6qQv7todYBzTVCacvSkesZ5+13f6WuxgGdWEUCpFH
oVVCLRYQPWQmZhaOFZce4MQJa4ooiZQ1/c9y26klFKGc36lkX+vobY5UUWyI
wFhUxtBwVdxqKlXsJd3yfhsb4IcG3O4pmFvuymqTOkcbd0ruzb7wB1wBkN6N
46RDifUIzsmuqvr2DSrrC2c/gpi9GZcI9i2cCV60/i/YiExKsY3KPlJ3xHSb
jvsat4gZilM5v2c1y+ieGyQwyCvNnKDksaUF18K5zD+SlwvGTnLTvK24oitz
R4NHrP/bAhg7EJ2OJqPPIIqN6SJSnkZ4Xbe903ZDiUWaQlxmyS1qWy+5U5F8
SUatW/UkU/3b3qxTQvS2TxrxgCFuzht7Thpb30G+15nekAJYOK35MrWZm8qT
mmcXvI/RpjrU9vyussYELiyCxtmxo20TFdaROcSnxY1/fM5Q9wWG8wmePkcG
TQIVUqWJB59+eciXY778zJdDXB4f0d02tntsYspJ3VlIC3eATedAZjv2uPyj
setKFUt+x8rGC5wXroamqecouMWzHuThVQ9Kf4fja/z+abvkf32n9yl0DgAA

-->

</rfc>
