<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced. 
    An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc ipr="trust200902" docName="draft-lassey-priority-setting-00" category="std">

  <front>
    <title>Declaring Support for HTTP/2 Priorities</title>

    <author initials="B." surname="Lassey" fullname="Brad Lassey">
      <organization>Google</organization>
      <address>
        <email>lassey@chromium.org</email>
      </address>
    </author>
    <author initials="L." surname="Pardue" fullname="Lucas Pardue">
      <organization>Cloudflare</organization>
      <address>
        <email>lucaspardue.24.7@gmail.com</email>
      </address>
    </author>

    <date year="2019" month="July" day="25"/>

    <area>Applications and Real-Time</area>
    <workgroup>HTTP</workgroup>
    <keyword>priority</keyword>
    <keyword>setting</keyword>
    <abstract>
      <t>HTTP/2 provides a prioritization scheme but experience has shown that implementation support varies.  This document defines an HTTP/2 setting that endpoints can use as an affirmative signal to indicate their support for HTTP/2 Priorities.</t>
    </abstract>

  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>The HTTP/2 specification defines a priority scheme in  <xref target="RFC7540"/>, Section 5.3, which some implementers have opted not to fully support. The lack of signalling about the status of the implementation has encouraged some servers to use heuristics in order to detect when the clients they are connected to do not support priorities as defined and take steps to compensate for that. The intent of this draft is to provide and affirmative signalling mechanism for each client to communicate whether or not it supports and will use the priority scheme as defined in  <xref target="RFC7540"/>, Section 5.3.</t>
    </section>
    <section anchor="terminology" title="Terminology">
      <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 anchor="parameter" title="The SETTINGS_ENABLE_HTTP2_PRIORITIES SETTINGS Parameter">
      <t>This document adds a new SETTINGS parameter to those defined by
      <xref target="RFC7540"/>, Section 6.5.2.</t>
      <t>The new parameter name is SETTINGS_ENABLE_HTTP2_PRIORITIES.  The
      value of the parameter MUST be 0 or 1 to indicate not supporting or supporting HTTP/2 priorities respectively. If either side sends the parameter with a value of 0, clients SHOULD NOT send priority frames and servers SHOULD NOT make any assumptions based on the presence or lack thereof of priority frames. If both sides send the parameter with a value of 1, then both parties MAY use HTTP/2 priorities as they see fit. A sender MUST NOT send the parameter   with the value of 0 after previously sending a value of 1. If a client or server does not send the setting, the peer SHOULD NOT make any assumptions about its support for HTTP/2 priorities.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <section anchor="setting" title="A New HTTP/2 Setting">

	<t>This document registers an entry in the "HTTP/2 Settings" registry that was established by Section 11.3 of <xref target="RFC7540"/>.</t>
	
	<t>Name: SETTINGS_ENABLE_HTTP2_PRIORITIES</t>
	
	<t>Code: 0xTBD</t>
	
	<t>Initial Value: 1</t>
	
	<t>Specification: This document</t>
	
      </section>
    </section>
  </middle>
  <back>
    <references title='Normative References'>
<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>

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

    </references>
  </back>
</rfc>
