<?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.28 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-httpbis-proxy-status-03" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <front>
    <title abbrev="Proxy-Status">The Proxy-Status HTTP Response Header Field</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-proxy-status-03"/>
    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
      <organization>Fastly</organization>
      <address>
        <postal>
          <city>Prahran</city>
          <region>VIC</region>
          <country>Australia</country>
        </postal>
        <email>mnot@mnot.net</email>
        <uri>https://www.mnot.net/</uri>
      </address>
    </author>
    <author initials="P." surname="Sikora" fullname="Piotr Sikora">
      <organization>Google</organization>
      <address>
        <email>piotrsikora@google.com</email>
      </address>
    </author>
    <date/>
    <area>Applications and Real-Time</area>
    <workgroup>HTTP</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This document defines the Proxy-Status HTTP field to convey the details of intermediary response handling, including generated errors.</t>
    </abstract>
    <note>
      <name>Note to Readers</name>
      <t><em>RFC EDITOR: please remove this section before publication</em></t>
      <t>Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at <eref target="https://lists.w3.org/Archives/Public/ietf-http-wg/">https://lists.w3.org/Archives/Public/ietf-http-wg/</eref>.</t>
      <t>Working Group information can be found at <eref target="https://httpwg.org/">https://httpwg.org/</eref>; source code and issues list for this draft can be found at <eref target="https://github.com/httpwg/http-extensions/labels/proxy-status">https://github.com/httpwg/http-extensions/labels/proxy-status</eref>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>HTTP intermediaries -- including both forward proxies and gateways (also known as "reverse proxies") -- have become an increasingly significant part of HTTP deployments. In particular, reverse proxies and Content Delivery Networks (CDNs) form part of the critical infrastructure of many Web sites.</t>
      <t>Typically, HTTP intermediaries forward requests towards the origin server and then forward their responses back to clients. However, if an error occurs before a response is obtained from upstream, the response is often generated by the intermediary itself.</t>
      <t>HTTP accommodates these types of errors with a few status codes; for example, 502 Bad Gateway and 504 Gateway Timeout. However, experience has shown that more information is necessary to aid debugging and communicate what's happened to the client. Additionally, intermediaries sometimes want to convey additional information about their handling of a response, even if they did not generate it.</t>
      <t>To enable these uses, <xref target="header" format="default"/> defines a new HTTP response field to allow intermediaries to convey details of their handling of a response, <xref target="params" format="default"/> enumerates the kind of information that can be conveyed, and <xref target="error-types" format="default"/> defines a set of error types for use when a proxy encounters an issue when obtaining a response for the request.</t>
      <section anchor="notational-conventions" numbered="true" toc="default">
        <name>Notational Conventions</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 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they appear in all capitals, as shown here.</t>
        <t>This specification uses Structured Fields <xref target="I-D.ietf-httpbis-header-structure" format="default"/> to specify syntax and parsing. The terms sf-list, sf-item, sf-string, sf-token, sf-integer and key refer to the structured types defined therein.</t>
        <t>Note that in this specification, "proxy" is used to indicate both forward and reverse proxies, otherwise known as gateways. "Next hop" indicates the connection in the direction leading to the origin server for the request.</t>
      </section>
    </section>
    <section anchor="header" numbered="true" toc="default">
      <name>The Proxy-Status HTTP Field</name>
      <t>The Proxy-Status HTTP response field allows an intermediary to convey additional information about its handling of a response and its associated request.</t>
      <t>It is a List <xref section="3.1" sectionFormat="comma" target="I-D.ietf-httpbis-header-structure" format="default"/>:</t>
      <artwork type="abnf" name="" align="left" alt=""><![CDATA[
Proxy-Status   = sf-list
]]></artwork>
      <t>Each member of the list represents an intermediary that has handled the response. The first member of the list represents the intermediary closest to the origin server, and the last member of the list represents the intermediary closest to the user agent.</t>
      <t>For example:</t>
      <artwork type="http-message" name="" align="left" alt=""><![CDATA[
Proxy-Status: FooProxy, ExampleCDN
]]></artwork>
      <t>indicates that this response was handled first by FooProxy and then ExampleCDN.</t>
      <t>Intermediaries determine when it is appropriate to add the Proxy-Status field to a response. Some might decide to append to it to all responses, whereas others might only do so when specifically configured to, or when the request contains a header that activates a debugging mode.</t>
      <t>Each member of the list identifies the intermediary that inserted the value, and MUST have a type of either sf-string or sf-token. Depending on the deployment, this might be a product or service name (e.g., ExampleProxy or "Example CDN"), a hostname ("proxy-3.example.com"), an IP address, or a generated string.</t>
      <t>Parameters on each member convey additional information about that intermediary's handling of the response and its associated request; see <xref target="params" format="default"/>. While all of these parameters are OPTIONAL, intermediaries are encouraged to provide as much information as possible (but see <xref target="security" format="default"/> for security considerations in doing so).</t>
      <t>When adding a value to the Proxy-Status field, intermediaries SHOULD preserve the existing members of the field, to allow debugging of the entire chain of intermediaries handling the request.</t>
      <t>Proxy-Status MAY be sent in HTTP trailers. For example, if an intermediary is streaming a response and the upstream connection suddenly terminates, Proxy-Status can only be appended to the trailers of the outgoing message, since the headers have already been sent. As with all trailers, it might be silently discarded along the path to the user agent, so this SHOULD NOT be done unless it is not possible to send it in headers, and an intermediary MUST NOT send Proxy-Status as a trailer field unless it has also sent a corresponding Proxy-Status header field in the same message, so that the trailer value's ordering relative to other intermediaries is preserved.</t>
      <t>Origin servers MUST NOT generate the Proxy-Status field.</t>
      <section anchor="params" numbered="true" toc="default">
        <name>Proxy-Status Parameters</name>
        <t>This section lists parameters that can be used on the members of the Proxy-Status field. Unrecognised parameters SHOULD be ignored.</t>
        <section anchor="error" numbered="true" toc="default">
          <name>error</name>
          <t>The <tt>error</tt> parameter's value is an sf-token that is a Proxy Error Type. When present, it indicates that the proxy encountered an issue when obtaining a response.</t>
          <t>Unless a Proxy Error Type specifies otherwise, the presences of error often, but not always, indicates that response was generated by the proxy, not the origin server or any other upstream server. For example, a proxy might attempt to correct an error, or part of a response might be forwarded before the error is encountered.</t>
          <t><xref target="error-types" format="default"/> lists the Proxy Error Types defined in this document; new ones can be defined using the procedure outlined in <xref target="register-error" format="default"/>.</t>
          <t>For example:</t>
          <artwork type="http-message" name="" align="left" alt=""><![CDATA[
HTTP/1.1 504 Gateway Timeout
Proxy-Status: SomeCDN; error=connection_timeout
]]></artwork>
          <t>indicates that this 504 response was generated by SomeCDN, due to a connection timeout when going forward.</t>
          <t>Or:</t>
          <artwork type="http-message" name="" align="left" alt=""><![CDATA[
HTTP/1.1 429 Too Many Requests
Proxy-Status: SomeReverseProxy; error=http_request_error
]]></artwork>
          <t>indicates that this 429 Too Many Requests response was generated by the intermediary, not the origin.</t>
          <t>When sending the error parameter, the most specific Proxy Error Type SHOULD be sent, provided that it accurately represents the error condition. If an appropriate Proxy Error Type is not defined, there are a number of generic error types (e.g., proxy_internal_error, http_protocol_error) that can be used. If they are not suitable, consider registering a new Proxy Error Type (see <xref target="register-error" format="default"/>).</t>
          <t>Each Proxy Error Type has a Recommended HTTP Status Code. When generating a HTTP response containing <tt>error</tt>, its HTTP status code SHOULD be set to the Recommended HTTP Status Code. However, there may be circumstances (e.g., for backwards compatibility with previous behaviours, a status code has already been sent) when another status code might be used.</t>
          <t>Proxy Error Types can also define any number of extra parameters for use with that type. Their use, like all parameters, is optional. As a result, if an extra parameter is used with a Proxy Error Type for which it is not defined, it will be ignored.</t>
        </section>
        <section anchor="next-hop" numbered="true" toc="default">
          <name>next-hop</name>
          <t>The <tt>next-hop</tt> parameter's value is an sf-string or sf-token that identifies the intermediary or origin server selected (and used, if contacted) for this response. It might be a hostname, IP address, or alias.</t>
          <t>For example:</t>
          <artwork type="http-message" name="" align="left" alt=""><![CDATA[
Proxy-Status: cdn.example.org; next-hop=backend.example.org
]]></artwork>
        </section>
        <section anchor="next-protocol" numbered="true" toc="default">
          <name>next-protocol</name>
          <t>The <tt>next-protocol</tt> parameter's value indicates the ALPN protocol identifier <xref target="RFC7301" format="default"/> used by the intermediary to connect to the next hop. This is only applicable when that connection was actually established.</t>
          <t>The value MUST be either an sf-token or sf-binary. If the protocol identifier is able to be expressed as an sf-token using UTF-8 encoding, that form MUST be used.</t>
          <t>For example:</t>
          <artwork type="http-message" name="" align="left" alt=""><![CDATA[
Proxy-Status: "proxy.example.org"; next-protocol=h2
]]></artwork>
        </section>
      </section>
      <section anchor="received-status" numbered="true" toc="default">
        <name>received-status</name>
        <t>The <tt>received-status</tt> parameter's value indicates the HTTP status code that the intermediary received from the next hop server.</t>
        <t>The value MUST be an sf-integer.</t>
        <t>For example:</t>
        <artwork type="http-message" name="" align="left" alt=""><![CDATA[
Proxy-Status: ExampleProxy; received-status=200
]]></artwork>
        <section anchor="details" numbered="true" toc="default">
          <name>details</name>
          <t>The <tt>details</tt> parameter's value is an sf-string containing additional information not captured anywhere else. This can include implementation-specific or deployment-specific information.</t>
          <t>For example:</t>
          <artwork type="http-message" name="" align="left" alt=""><![CDATA[
Proxy-Status: ExampleProxy; error="http_protocol_error";
              details="Malformed response header - space before colon"
]]></artwork>
        </section>
      </section>
      <section anchor="register-param" numbered="true" toc="default">
        <name>Defining New Proxy-Status Parameters</name>
        <t>New Proxy-Status Parameters can be defined by registering them in the HTTP Proxy-Status Parameters registry.</t>
        <t>Registration requests are reviewed and approved by a Designated Expert, as per <xref section="4.5" sectionFormat="comma" target="RFC8126" format="default"/>. A specification document is appreciated, but not required.</t>
        <t>The Expert(s) should consider the following factors when evaluating requests:</t>
        <ul spacing="normal">
          <li>Community feedback</li>
          <li>If the value is sufficiently well-defined</li>
          <li>Generic parameters are preferred over vendor-specific, application-specific or deployment-specific values. If a generic value cannot be agreed upon in the community, the parameter's name should be correspondingly specific (e.g., with a prefix that identifies the vendor, application or deployment).</li>
          <li>Parameter names should not conflict with registered extra parameters in the Proxy Error Type Registry.</li>
        </ul>
        <t>Registration requests should use the following template:</t>
        <ul spacing="normal">
          <li>Name: [a name for the Proxy-Status Parameter that matches key]</li>
          <li>Description: [a description of the parameter semantics and value]</li>
          <li>Reference: [to a specification defining this parameter]</li>
        </ul>
        <t>See the registry at <eref target="https://iana.org/assignments/http-proxy-status">https://iana.org/assignments/http-proxy-status</eref> for details on where to send registration requests.</t>
      </section>
      <section anchor="error-types" numbered="true" toc="default">
        <name>Proxy Error Types</name>
        <t>This section lists the Proxy Error Types defined by this document. See <xref target="register-error" format="default"/> for information about defining new Proxy Error Types.</t>
        <section anchor="dns-timeout" numbered="true" toc="default">
          <name>DNS Timeout</name>
          <ul spacing="normal">
            <li>Name: dns_timeout</li>
            <li>Description: The intermediary encountered a timeout when trying to find an IP address for the next hop hostname.</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code: 504</li>
          </ul>
        </section>
        <section anchor="dns-error" numbered="true" toc="default">
          <name>DNS Error</name>
          <ul spacing="normal">
            <li>Name: dns_error</li>
            <li>Description: The intermediary encountered a DNS error when trying to find an IP address for the next hop hostname.</li>
            <li>
              <t>Extra Parameters:
              </t>
              <ul spacing="normal">
                <li>rcode: A sf-string conveying the DNS RCODE that indicates the error type. See <xref section="3" sectionFormat="comma" target="RFC8499" format="default"/>.</li>
              </ul>
            </li>
            <li>Recommended HTTP status code: 502</li>
          </ul>
        </section>
        <section anchor="destination-not-found" numbered="true" toc="default">
          <name>Destination Not Found</name>
          <ul spacing="normal">
            <li>Name: destination_not_found</li>
            <li>Description: The intermediary cannot determine the appropriate next hop to use for this request; for example, it may not be configured. Note that this error is specific to gateways, which typically require specific configuration to identify the "backend" server; forward proxies use in-band information to identify the origin server.</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code: 500</li>
          </ul>
        </section>
        <section anchor="destination-unavailable" numbered="true" toc="default">
          <name>Destination Unavailable</name>
          <ul spacing="normal">
            <li>Name: destination_unavailable</li>
            <li>Description: The intermediary considers the next hop to be unavailable; e.g., recent attempts to communicate with it may have failed, or a health check may indicate that it is down.</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code: 503</li>
          </ul>
        </section>
        <section anchor="destination-ip-prohibited" numbered="true" toc="default">
          <name>Destination IP Prohibited</name>
          <ul spacing="normal">
            <li>Name: destination_ip_prohibited</li>
            <li>Description: The intermediary is configured to prohibit connections to the next hop IP address.</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code: 502</li>
          </ul>
        </section>
        <section anchor="destination-ip-unroutable" numbered="true" toc="default">
          <name>Destination IP Unroutable</name>
          <ul spacing="normal">
            <li>Name: destination_ip_unroutable</li>
            <li>Description: The intermediary cannot find a route to the next hop IP address.</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code: 502</li>
          </ul>
        </section>
        <section anchor="connection-refused" numbered="true" toc="default">
          <name>Connection Refused</name>
          <ul spacing="normal">
            <li>Name: connection_refused</li>
            <li>Description: The intermediary's connection to the next hop was refused.</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code: 502</li>
          </ul>
        </section>
        <section anchor="connection-terminated" numbered="true" toc="default">
          <name>Connection Terminated</name>
          <ul spacing="normal">
            <li>Name: connection_terminated</li>
            <li>Description: The intermediary's connection to the next hop was closed before complete response was received.</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code: 502</li>
            <li>Notes: Responses with this error type might not have been generated by the intermediary.</li>
          </ul>
        </section>
        <section anchor="connection-timeout" numbered="true" toc="default">
          <name>Connection Timeout</name>
          <ul spacing="normal">
            <li>Name: connection_timeout</li>
            <li>Description: The intermediary's attempt to open a connection to the next hop timed out.</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code: 504</li>
          </ul>
        </section>
        <section anchor="connection-read-timeout" numbered="true" toc="default">
          <name>Connection Read Timeout</name>
          <ul spacing="normal">
            <li>Name: connection_read_timeout</li>
            <li>Description: The intermediary was expecting data on a connection (e.g., part of a response), but did not receive any new data in a configured time limit.</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code: 504</li>
            <li>Notes: Responses with this error type might not have been generated by the intermediary.</li>
          </ul>
        </section>
        <section anchor="connection-write-timeout" numbered="true" toc="default">
          <name>Connection Write Timeout</name>
          <ul spacing="normal">
            <li>Name: connection_write_timeout</li>
            <li>Description: The intermediary was attempting to write data to a connection, but was not able to (e.g., because its buffers were full).</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code: 504</li>
            <li>Notes: Responses with this error type might not have been generated by the intermediary.</li>
          </ul>
        </section>
        <section anchor="connection-limit-reached" numbered="true" toc="default">
          <name>Connection Limit Reached</name>
          <ul spacing="normal">
            <li>Name: connection_limit_reached</li>
            <li>Description: The intermediary is configured to limit the number of connections it has to the next hop, and that limit has been passed.</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code: 503</li>
          </ul>
        </section>
        <section anchor="tls-protocol-error" numbered="true" toc="default">
          <name>TLS Protocol Error</name>
          <ul spacing="normal">
            <li>Name: tls_protocol_error</li>
            <li>Description: The intermediary encountered a TLS error when communicating with the next hop, either during handshake or afterwards.</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code: 502</li>
            <li>Notes: Responses with this error type might not have been generated by the intermediary.</li>
          </ul>
          <t>Note that additional information about the error can be recorded in the details parameter (as is the case for all errors).</t>
        </section>
        <section anchor="tls-certificate-error" numbered="true" toc="default">
          <name>TLS Certificate Error</name>
          <ul spacing="normal">
            <li>Name: tls_certificate_error</li>
            <li>Description: The intermediary encountered an error when verifying the certificate presented by the next hop.</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code: 502</li>
          </ul>
          <t>Note that additional information about the error can be recorded in the details parameter (as is the case for all errors).</t>
        </section>
        <section anchor="tls-alert-received" numbered="true" toc="default">
          <name>TLS Alert Received</name>
          <ul spacing="normal">
            <li>Name: tls_alert_received</li>
            <li>Description: The intermediary received a TLS alert from the next hop.</li>
            <li>
              <t>Extra Parameters:
              </t>
              <ul spacing="normal">
                <li>alert-message: an sf-token containing the applicable description string from the TLS Alerts registry.</li>
              </ul>
            </li>
            <li>Recommended HTTP status code: 502</li>
            <li>Notes: Responses with this error type might not have been generated by the intermediary.</li>
          </ul>
        </section>
        <section anchor="http-request-error" numbered="true" toc="default">
          <name>HTTP Request Error</name>
          <ul spacing="normal">
            <li>Name: http_request_error</li>
            <li>Description: The intermediary is generating a client (4xx) response on the origin's behalf. Applicable status codes include (but are not limited to) 400, 403, 405, 406, 408, 411, 413, 414, 415, 416, 417, 429.</li>
            <li>
              <t>Extra Parameters:
              </t>
              <ul spacing="normal">
                <li>status-code: an sf-integer containing the generated status code.</li>
                <li>status-phrase: an sf-string containing the generated status phrase.</li>
              </ul>
            </li>
            <li>Recommended HTTP status code: The applicable 4xx status code</li>
            <li>Notes: This type helps distinguish between responses generated by intermediaries from those generated by the origin.</li>
          </ul>
        </section>
        <section anchor="http-request-denied" numbered="true" toc="default">
          <name>HTTP Request Denied</name>
          <ul spacing="normal">
            <li>Name: http_request_denied</li>
            <li>Description: The intermediary rejected the HTTP request based on its configuration and/or policy settings. The request wasn't forwarded to the next hop.</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code: 403</li>
          </ul>
        </section>
        <section anchor="http-incomplete-response" numbered="true" toc="default">
          <name>HTTP Incomplete Response</name>
          <ul spacing="normal">
            <li>Name: http_response_incomplete</li>
            <li>Description: The intermediary received an incomplete response to the request from the next hop.</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code: 502</li>
            <li>Notes: Responses with this error type might not have been generated by the intermediary.</li>
          </ul>
        </section>
        <section anchor="http-response-header-section-too-large" numbered="true" toc="default">
          <name>HTTP Response Header Section Too Large</name>
          <ul spacing="normal">
            <li>Name: http_response_header_section_size</li>
            <li>Description: The intermediary received a response to the request whose header section was considered too large.</li>
            <li>
              <t>Extra Parameters:
              </t>
              <ul spacing="normal">
                <li>header-section-size: an sf-integer indicating how large the headers received were. Note that they might not be complete; i.e., the intermediary may have discarded or refused additional data.</li>
              </ul>
            </li>
            <li>Recommended HTTP status code: 502</li>
            <li>Notes: Responses with this error type might not have been generated by the intermediary.</li>
          </ul>
        </section>
        <section anchor="http-response-header-too-large" numbered="true" toc="default">
          <name>HTTP Response Header Too Large</name>
          <ul spacing="normal">
            <li>Name: http_response_header_size</li>
            <li>Description: The intermediary received a response to the request containing an individual header line that was considered too large.</li>
            <li>
              <t>Extra Parameters:
              </t>
              <ul spacing="normal">
                <li>header-name: an sf-string indicating the name of the header that triggered the error.</li>
                <li>header-size: an sf-integer indicating the size of the header that triggered the error.</li>
              </ul>
            </li>
            <li>Recommended HTTP status code: 502</li>
            <li>Notes: Responses with this error type might not have been generated by the intermediary.</li>
          </ul>
        </section>
        <section anchor="http-response-body-too-large" numbered="true" toc="default">
          <name>HTTP Response Body Too Large</name>
          <ul spacing="normal">
            <li>Name: http_response_body_size</li>
            <li>Description: The intermediary received a response to the request whose body was considered too large.</li>
            <li>
              <t>Extra Parameters:
              </t>
              <ul spacing="normal">
                <li>body-size: an sf-integer indicating how large the body received was. Note that it may not have been complete; i.e., the intermediary may have discarded or refused additional data.</li>
              </ul>
            </li>
            <li>Recommended HTTP status code: 502</li>
            <li>Notes: Responses with this error type might not have been generated by the intermediary.</li>
          </ul>
        </section>
        <section anchor="http-response-trailer-section-too-large" numbered="true" toc="default">
          <name>HTTP Response Trailer Section Too Large</name>
          <ul spacing="normal">
            <li>Name: http_response_trailer_section_size</li>
            <li>Description: The intermediary received a response to the request whose trailer section was considered too large.</li>
            <li>
              <t>Extra Parameters:
              </t>
              <ul spacing="normal">
                <li>trailer-section-size: an sf-integer indicating how large the trailers received were. Note that they might not be complete; i.e., the intermediary may have discarded or refused additional data.</li>
              </ul>
            </li>
            <li>Recommended HTTP status code: 502</li>
            <li>Notes: Responses with this error type might not have been generated by the intermediary.</li>
          </ul>
        </section>
        <section anchor="http-response-trailer-too-large" numbered="true" toc="default">
          <name>HTTP Response Trailer Too Large</name>
          <ul spacing="normal">
            <li>Name: http_response_trailer_size</li>
            <li>Description: The intermediary received a response to the request containing an individual trailer line that was considered too large.</li>
            <li>
              <t>Extra Parameters:
              </t>
              <ul spacing="normal">
                <li>trailer-name: an sf-string indicating the name of the trailer that triggered the error.</li>
                <li>trailer-size: an sf-integer indicating the size of the trailer that triggered the error.</li>
              </ul>
            </li>
            <li>Recommended HTTP status code: 502</li>
            <li>Notes: Responses with this error type might not have been generated by the intermediary.</li>
          </ul>
        </section>
        <section anchor="http-response-transfer-coding-error" numbered="true" toc="default">
          <name>HTTP Response Transfer-Coding Error</name>
          <ul spacing="normal">
            <li>Name: http_response_transfer_coding</li>
            <li>Description: The intermediary encountered an error decoding the transfer-coding of the response.</li>
            <li>
              <t>Extra Parameters:
              </t>
              <ul spacing="normal">
                <li>coding: an sf-token containing the specific coding that caused the error.</li>
              </ul>
            </li>
            <li>Recommended HTTP status code: 502</li>
            <li>Notes: Responses with this error type might not have been generated by the intermediary.</li>
          </ul>
        </section>
        <section anchor="http-response-content-coding-error" numbered="true" toc="default">
          <name>HTTP Response Content-Coding Error</name>
          <ul spacing="normal">
            <li>Name: http_response_content_coding</li>
            <li>Description: The intermediary encountered an error decoding the content-coding of the response.</li>
            <li>
              <t>Extra Parameters:
              </t>
              <ul spacing="normal">
                <li>coding: an sf-token containing the specific coding that caused the error.</li>
              </ul>
            </li>
            <li>Recommended HTTP status code: 502</li>
            <li>Notes: Responses with this error type might not have been generated by the intermediary.</li>
          </ul>
        </section>
        <section anchor="http-response-timeout" numbered="true" toc="default">
          <name>HTTP Response Timeout</name>
          <ul spacing="normal">
            <li>Name: http_response_timeout</li>
            <li>Description: The intermediary reached a configured time limit waiting for the complete response.</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code: 504</li>
            <li>Notes: Responses with this error type might not have been generated by the intermediary.</li>
          </ul>
        </section>
        <section anchor="http-upgrade-failed" numbered="true" toc="default">
          <name>HTTP Upgrade Failed</name>
          <ul spacing="normal">
            <li>Name: http_upgrade_failed</li>
            <li>Description: The HTTP Upgrade between the intermediary and the next hop failed.</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code: 502</li>
          </ul>
        </section>
        <section anchor="http-protocol-error" numbered="true" toc="default">
          <name>HTTP Protocol Error</name>
          <ul spacing="normal">
            <li>Name: http_protocol_error</li>
            <li>Description: The intermediary encountered a HTTP protocol error when communicating with the next hop. This error should only be used when a more specific one is not defined.</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code: 502</li>
            <li>Notes: Responses with this error type might not have been generated by the intermediary.</li>
          </ul>
          <t>Note that additional information about the error can be recorded in the details parameter (as is the case for all errors).</t>
        </section>
        <section anchor="proxy-internal-response" numbered="true" toc="default">
          <name>Proxy Internal Response</name>
          <ul spacing="normal">
            <li>Name: proxy_internal_response</li>
            <li>Description: The intermediary generated the response locally, without attempting to connect to the next hop (e.g. in response to a request to a debug endpoint terminated at the intermediary).</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code:</li>
          </ul>
        </section>
        <section anchor="proxy-internal-error" numbered="true" toc="default">
          <name>Proxy Internal Error</name>
          <ul spacing="normal">
            <li>Name: proxy_internal_error</li>
            <li>Description: The intermediary encountered an internal error unrelated to the origin.</li>
            <li>Extra Parameters: None</li>
            <li>Recommended HTTP status code: 500</li>
          </ul>
          <t>Note that additional information about the error can be recorded in the details parameter (as is the case for all errors).</t>
        </section>
        <section anchor="proxy-configuration-error" numbered="true" toc="default">
          <name>Proxy Configuration Error</name>
          <ul spacing="normal">
            <li>Name: proxy_configuration_error</li>
            <li>Description: The intermediary encountered an error regarding its configuration.</li>
            <li>Extra Parameters: None</li>
            <li>Recommended HTTP status code: 500</li>
          </ul>
          <t>Note that additional information about the error can be recorded in the details parameter (as is the case for all errors).</t>
        </section>
        <section anchor="proxy-loop-detected" numbered="true" toc="default">
          <name>Proxy Loop Detected</name>
          <ul spacing="normal">
            <li>Name: proxy_loop_detected</li>
            <li>Description: The intermediary tried to forward the request to itself, or a loop has been detected using different means (e.g. <xref target="RFC8586" format="default"/>).</li>
            <li>Extra Parameters: None.</li>
            <li>Recommended HTTP status code: 502</li>
          </ul>
        </section>
      </section>
      <section anchor="register-error" numbered="true" toc="default">
        <name>Defining New Proxy Error Types</name>
        <t>New Proxy Error Types can be defined by registering them in the HTTP Proxy Error Types registry.</t>
        <t>Registration requests are reviewed and approved by a Designated Expert, as per <xref section="4.5" sectionFormat="comma" target="RFC8126" format="default"/>. A specification document is appreciated, but not required.</t>
        <t>The Expert(s) should consider the following factors when evaluating requests:</t>
        <ul spacing="normal">
          <li>Community feedback</li>
          <li>If the value is sufficiently well-defined</li>
          <li>Generic types are preferred over vendor-specific, application-specific or deployment-specific values. If a generic value cannot be agreed upon in the community, the types's name should be correspondingly specific (e.g., with a prefix that identifies the vendor, application or deployment).</li>
          <li>Extra Parameters should not conflict with registered Proxy-Status parameters.</li>
        </ul>
        <t>Registration requests should use the following template:</t>
        <ul spacing="normal">
          <li>Name: [a name for the Proxy Error Type that matches sf-token]</li>
          <li>Description: [a description of the conditions that generate the Proxy Error Type]</li>
          <li>Extra Parameters: [zero or more optional parameters, along with their allowable type(s)]</li>
          <li>Recommended HTTP status code: [the appropriate HTTP status code for this entry]</li>
          <li>Notes: [optional]</li>
        </ul>
        <t>If the Proxy Error Type might occur in responses that are not generated by the intermediary -- for example, when the error is detected during response content processing and a Proxy-Status trailer field is appended -- that SHOULD be explained in the Notes.</t>
        <t>See the registry at <eref target="https://iana.org/assignments/http-proxy-status">https://iana.org/assignments/http-proxy-status</eref> for details on where to send registration requests.</t>
      </section>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>Upon publication, please create the HTTP Proxy-Status Parameters registry and the HTTP Proxy Error Types registry at <eref target="https://iana.org/assignments/http-proxy-statuses">https://iana.org/assignments/http-proxy-statuses</eref> and populate them with the types defined in <xref target="params" format="default"/> and <xref target="error-types" format="default"/> respectively; see <xref target="register-param" format="default"/> and <xref target="register-error" format="default"/> for its associated procedures.</t>
    </section>
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>One of the primary security concerns when using Proxy-Status is leaking information that might aid an attacker. For example, information about the intermediary's configuration and back-end topology can be exposed.</t>
      <t>As a result, care needs to be taken when deciding to generate a Proxy-Status field. Note that intermediaries are not required to generate a Proxy-Status field in any response, and can conditionally generate them based upon request attributes (e.g., authentication tokens, IP address).</t>
      <t>Likewise, generation of all parameters is optional.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <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="RFC8126" target="https://www.rfc-editor.org/info/rfc8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author initials="M." surname="Cotton" fullname="M. Cotton">
              <organization/>
            </author>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <author initials="T." surname="Narten" fullname="T. Narten">
              <organization/>
            </author>
            <date year="2017" month="June"/>
            <abstract>
              <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8499" target="https://www.rfc-editor.org/info/rfc8499">
          <front>
            <title>DNS Terminology</title>
            <author initials="P." surname="Hoffman" fullname="P. Hoffman">
              <organization/>
            </author>
            <author initials="A." surname="Sullivan" fullname="A. Sullivan">
              <organization/>
            </author>
            <author initials="K." surname="Fujiwara" fullname="K. Fujiwara">
              <organization/>
            </author>
            <date year="2019" month="January"/>
            <abstract>
              <t>The Domain Name System (DNS) is defined in literally dozens of different RFCs.  The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined.  This document gives current definitions for many of the terms used in the DNS in a single document.</t>
              <t>This document obsoletes RFC 7719 and updates RFC 2308.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="219"/>
          <seriesInfo name="RFC" value="8499"/>
          <seriesInfo name="DOI" value="10.17487/RFC8499"/>
        </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="I-D.ietf-httpbis-header-structure" target="http://www.ietf.org/internet-drafts/draft-ietf-httpbis-header-structure-19.txt">
          <front>
            <title>Structured Field Values for HTTP</title>
            <author initials="M" surname="Nottingham" fullname="Mark Nottingham">
              <organization/>
            </author>
            <author initials="P" surname="Kamp" fullname="Poul-Henning Kamp">
              <organization/>
            </author>
            <date month="June" day="3" year="2020"/>
            <abstract>
              <t>This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers".  It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-header-structure-19"/>
        </reference>
        <reference anchor="RFC7301" target="https://www.rfc-editor.org/info/rfc7301">
          <front>
            <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
            <author initials="S." surname="Friedl" fullname="S. Friedl">
              <organization/>
            </author>
            <author initials="A." surname="Popov" fullname="A. Popov">
              <organization/>
            </author>
            <author initials="A." surname="Langley" fullname="A. Langley">
              <organization/>
            </author>
            <author initials="E." surname="Stephan" fullname="E. Stephan">
              <organization/>
            </author>
            <date year="2014" month="July"/>
            <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>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC8586" target="https://www.rfc-editor.org/info/rfc8586">
          <front>
            <title>Loop Detection in Content Delivery Networks (CDNs)</title>
            <author initials="S." surname="Ludin" fullname="S. Ludin">
              <organization/>
            </author>
            <author initials="M." surname="Nottingham" fullname="M. Nottingham">
              <organization/>
            </author>
            <author initials="N." surname="Sullivan" fullname="N. Sullivan">
              <organization/>
            </author>
            <date year="2019" month="April"/>
            <abstract>
              <t>This document defines the CDN-Loop request header field for HTTP. CDN-Loop addresses an operational need that occurs when an HTTP request is intentionally forwarded between Content Delivery Networks (CDNs), but is then accidentally or maliciously re-routed back into the original CDN causing a non-terminating loop.  The new header field can be used to identify the error and terminate the loop.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8586"/>
          <seriesInfo name="DOI" value="10.17487/RFC8586"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAJs7I2AAA+1dW3Mbt5J+56/Ayg+xXCQl2c5NXp+NIsmJqmTZK8mb2kpO
6YAzIInVcMAzmBHFqJLfvn0BMJjhSJQsZ+M9lTzIJAcDoBt9+brRQAaDQa/U
ZaZ2xflUifeFuV4OzkpZVlb8eH7+XpwqOze5VeJHJVNViDdaZWlPjkaFutpt
tO+lJsnlDHpKCzkuB1qV48G0LOcjbQdzamip4WD7RS+VJTS8Odg7P/ytl8CX
iSmWu8KWaU/Pi11RFpUtn29vf7v9vCcLJXfF3nyeaWipYTZC5inMTGaDcz1T
vYUpLieFqea7NOfepVrCT+muOMpLVeSqHBzgjHowfJ5eyMzkMPZS2Z6dyaK8
+GdlSmV3RW56E11Oq9FAW1upQSZHKtsV8dR7PVmVU1Ps9sSgJ+A/ncOLb4fi
xJSlzidTOaOfmQ9vZXHZfmKKicz1r0THrngjbZkt6UGiyyUyVE4LmdMvhZpQ
o/862ucWpspL5NIe8KaQmZb0s5pJDdOc5ab8Dv8MgWB6UBV6V+AC2N2trcVi
MfRPtxqzfz8UZ/rSFDKa+XttyiL+uTntH4yZZCoefY4vWGr/3YSeDhMz6/Vy
U8zgpSsFHBOnb/af7+x86z5+s/P8K//x5bfwa0/n47p5rzcYDIQcIalJ2eud
T7UVIGLVTOWlSNVY58qKslNoxyikojTAsvxKLalVqkqYqRVmDGSDWMxUqmWx
BC47AZ+CcGSwUn14nmRVCh/FROWqAOlMhSoKU9ihmxYwUl2c4J/SXJySZoBs
PANSxOHB0fm7U+BIpiT0WqiZuVIwA5i9VQnyT4wU0KnEvBp5iX7W6x1om1TW
4nOYIrUnPRKlvARC55lMlICHSAsRiVJPc0TJF7gM+C3TthRPg+4NFpPvFi+G
sHybfbGY6mQqoGNZJFNgcipkKf7dSwi+aYfceGuPW9it9zTJrbjDrb8BG35y
o/9Ao4eVgwkmEikUY5DW5gD472JC3f/tlbCmKoCixKSK1Jl0zvL8obOYA7f2
yOqKkuY6p38G6rpUOXLSbpEO261Yh3H2uIYznaYgxL0naCYKk1a0OL0eMTcS
EQ2zgua1UIxMOcUpLmSRknXAFkjCBCRlIZdWPJWZNeIyN4tcSCs2wFaCgCjf
eGMTO5xKkIuRgskjA7B/sHMWBsiWwupJrscgHCDqc7BRKBI0r1TNM7NEFbBD
mDc91EmVyaIvWqPQlPYNEAKdHKgMlhPE/USVKDgwx/2DE7uJdMzCEChbSaGh
R5nhmhZgngrgSwXSCo9nMl+Kn9QIpgcGE9h4vpxj02zZF11c8zwq1D9haUvQ
VoPfWWtNoSc6B50oYF40V/g1D+/AF10E5bRiJJNL0uhMM/E/mgXSC9o6RvaR
fgqTJFVhvYLJWrlBlswIDEAOQj8uzExUcyBNyVmfJtNoNwaORZo/YvvRMBq6
tCobD52wyAQWcWbQpxFt0E+5nCuyNWw3xAIkFeYzVgvBUkiCb1+RqKtrOQNz
0Rdfbj8X38tU/MCCRFz5cvtl+I7ezlRlRLy6nivgdZ6g/QILM0WRK6egJDPk
QKyXQFquEmUtEgCclDoFcRpVkwkKNQ6FVFQ5miQFtkKWX1jodD5XyDR4gaSD
2D8Ue2mqsVde/Na6WxDpEqYKZKMA13ZYhrcaM5MjIMqtuLfCyLt6/YDQK1gU
TSK6FClMHUxwWCRYD5RGI1QuR5lya1CB3PTFzc2U7PNvvwWnIYERC5bYsPDB
ZQBFZtGmqCYhciN3T/jmBrRKziyMq3JwWoWXDgF2M2U3VLOAlszZOR5JpX1a
lJsbEqEBSVSDCKvKIGFO4FCagGxYPeCWZOgCwxNyANtAdgbtLDdgjaDVjxhB
tld5pUWP9+QJohjpVm4fp5cTDkOvDPQAWxBvgaF7++HsfKPP/4qTd/T59PA/
PxydHh7g57Mf946Pwwff4uzHdx+OD+pP9Zv7796+PTw54JfhV9H66e3ef28w
mzbevT8/eneyd7wBfHXOw4MFAJC4giOnxPNCoV6DuoAGgrkbwRd45/v992Ln
JfD73xxOAWbzl292vn4JX5BnPJjJwUbzV5JHVBJZYCcgPbCMc12CB+iLoJFT
VaihwzB2rhKy7bTwKKTizFvZlPG1xYGPBgfDBoZmOR4EkwxTAqq4O3AZy7yU
1zQ9EDz0I0OC9CjHMOh4gJ61jx/AeM/oA/REeAc+luYSqcGnwKKJs8i4soUa
wzen/raeKAscSyOZ60LpHGhEVMTi7NehQTAsGknlBtojIJ50DhSCrU7DteIM
Wj6tLwyOtNDwU3Cv3u0OQUTA9YupmW+ELlnlQKVyB740Q6hUF+4HwGnk1h2J
Tb/UpQ23REq0cuLmiTM3rBurzVoWh8wNK2bsYO5pM8EP3WKAGFPBY2mtSTR5
spqIo5JgoDhGtHVzs1bU+uLMcevFcOe33wCd//777zCHfNxrUCjEay9q2KLX
O5SAOGdqNgJeOoBBCK9QoIUWPfkq6Sg76MyIMJatQBbL9FgX0Mfd3a747CQz
oGtl5zr3PQARmXx0zyDVoD4T9JO93pvavzuuEUSdoR+eqAb3IBw0hn7oi0N+
BTAa8zEWZ1myXoWlXkTMYtYAZvF91dCq7hMloOngwK3BV1Bl9gya5WMOajcv
UHjIM6bparxV+81ojc4Q0870ZIqBWqJTfh2RBKt76Rxtje8wOFGIf1nBrXub
DG0KRs7wvIIpAdiBCjLWEzZGBixDwW0idcUm6OJQ1FmkmX0QUOor4qaMIBAg
ODTSt4kskAFeb6xVhwQ4ewcLXzqBvZJZpVisyBkS2pdkNclpaySzNsI4e2+G
h4DWkVX0s7NWAfb3ee2ZPSPFTh5jF+oBhFkDFMQgXjxVw8kwSBLLArTZcD8I
kIMNCAqBM8aW/Aab5sGLoZNYjKyoTS6O3uP6w3pZ4rSMADJTAJx7j4BHEdCA
eauIj/fDf8TDmqtfNG1bA6ffbt0gslQqQl9D8dNUA7kobtwLupN6pggOPHZY
QbL4kOBTAcpKsgscukKBBkmdVRhNx3RAmG4ghEcI+nQEJPFMIOyvIKhagr8e
0yLxV2SKha4Kl9MCY5QapNWaTQywCcKlKcMzEidvYFYVcGXiDkiRzSoo/wCE
XIMYk6DTongM63sI2LfWCNcA5R4YkUxBlVr5ExwrLFLTUTZmCUANpRUNKBJK
nrAsAEnDPIbiTRwEcTzXDLes4GithVW90fbBXOznbZWCwoKZYMOG2t5vcg7h
NhkYVCMyTnWc4+fmWQACOjHMOzLcAJU0Bl34jC2LdSqewURS7BPNFcdKPvwD
CfT99tEIBiW28FteoqnTNgHog+g0M46jcwnvrriWPtpEMgU1ZsauUgM2vMoz
mKaz4hgoBbFEwKhId3AZ3MzZTLWZ7jE8v9DgnETD6UhxHqAeEl035T9osSWs
ScELRqLc6MfZZO7BATOLlqjmsvEOL6wJ6wIYBwg5FNnOQmWUNETqyH20JRS4
4DUhBcl8F7t+WxMawsluJXOhUONBZPJunjiT43G+x5eYV4stThzrEQJ2Rr6l
lh0TEB9yQK1mkmt8LerSyQBGOJMcAn+c6xOYK8WGjET/QZ//Ub8FHGSrogmD
ee/j7DCuMPuMQ4ovz8FxoSmFBg4I9VmIWrhEtYNOld4j6oTpfmABWh3VO31l
a/DfdyPhRJIo0cLJm75A44tyLzMMDPrtaTaQ00qmZ84QDN9fDQjQ9+VLJ2bB
7vDDliHz8TeruSwh7Jq7bEiBwUdIW5FH9Tm4yLwF++AiIpwiZ7bIKhPBsFAR
q4GP7XwBi18QqIixdfTWjphfUYLEYJrByalvWVlv6IG2RKWUGazKzHdzc4O7
FhYmM6BpgP9di4HRGWztDHe6Ul0tgIzAEnDLKyb+dW3uL0rX/la0jJ3fvu6u
475I2c3K2JW4vll82Q24FSFjcidNL59/K86NEW9Rak5dIrSDqlMOdOmBJw97
vHAO9YJV+VbyOsdZI+ixuW/Lu0cg1gHRWuKCAWElnAF6DLh8VXlry8Q2w+Gn
1JkZxOIAh2BW2bIdY/FwCToOXIahOCJkEEclK8M5f+fEtc95CYJxUuSVx/TE
CZhtnDpzcJlU9oI4AzD1wuknrQQ8Kk1i3I+bK3acJsj5IBgPp2ErXWJCsh+w
nvDqwfYP1WyFhqcMG9uKtOljk5UXyOPComP+llEM4SvnOvYxrGHL7SSAx25m
I1ykhI+cp+gTwKZWUcq6saAh5L177JCt5tWYSYJciS7A2uCebFKzHwEypvp5
nwA6BfSjRzpDvEwgCiTkSpsKc/yAt+ATwZfGDBmAtGDYpsuJ5my54/bBzNIi
OuDasJO4yARpWK7IA9TSpK4BmcTeOGRhccKsouQ9zylhXKH7yvQlhyT1a33a
fJhzfESokVxBlZVhj6M5UMiguc2FFbkYU0hMe37limbATwsNE2hgBgINOYwz
mJq5ww3+653QYTWKdQp+R9CM7rrhW63KwOICQU8RjyJpRDmJJv6+WW8M1rmG
ozIOhn0s218JWDMt7UPzMUmah1DYFJNXgTWvUUZB3OOnbJsDA721iLnof+tk
ZSNhuXf8/kT45jUXC5eR/vrF9g74dlr9rv0pTh+i//IamrvMKEqhJkRMoY/k
qgoMDVzyRJax60O/AbyvKOECLgVaajslWTn3WQ4G0MB+l9SIwSQLxAjir2Lp
7WMnXShJLkDBnq7RE1jO0sf9Mf74cP5m8A3hnpQS2DRr2sn0U3Gq/KDV5uxH
vKQbr5pr+Xr63K8ySGCicA89VIbQMrd+Xb/QK/Y14OhWlQL3y5uX8YJ67Nm1
IMw5l9F/KDvixNGrNrmvn29v1wLvNsUcD9y3+9iLyOvckhtCm5XIOe85gN2l
NKFQGaeCNdtm3puH7nHCCGDp3UFAJUB2nUGrf47GeRxzGK5tdKCEjVdUJVP/
55jzeuOtzHB0Slz5ChQOhwcAp7DYw2F96MvkG8xsFLwDtODIsRMPHjqD0QAf
aBUgKL2reQvlj5YNnALiNvPhOcnrbd3wS6Dpvd4pf+RFDAUACIzQgauF4v0d
AnNXPKQE0rDwgSDqIW5sl7SFNiez5yqG6p2Il8MvMbu319pQC7t+LoGtOD1Y
x4Q4GV0EE8YDPbWbuFVXZWkN1Sg3ZjAlRogfzCDt5KOZVCjODKQ8bSAzzwDv
0A46gJWxUik6CfjRWb2gAbYaw2w1Z3wWKssGju/Q9geHTFsJyjntwqEKGHSU
V+B6IMTzhPe9Gb+X1NM8LKPpgIR5ciAGyCG0HJNCYbg3r3fMEk+bC74j5abs
sWMfbWBHGR+sZvFDO5Dn8AoSpa87cQIT2KCrSQ6A4We15NEErJ8BmQyTj+HN
ksfywox1XG2w5qhbAU+n62TZjYZArykpGOdnWN+IEnFC9XS//CyZSX4/sVuD
XOWGLJMpkHOplr/8Hbo4oF3qOZfeYU9p/YNPFtWg0KqZBFYmXP9D60q9nKIE
YbYE+6AIt6U33qwQvgr9wbu9M6VcbpdZ0qjB0jKXVNMlLSovlSZxGVaj6Ioo
D8UTOW/3hHRk0cXhON/WgOM3T+IUR2e67e58B0GmKN8xFGedIRdNenWnIrCq
K3yzLvV2cHIWkhhBDtLchkxFa2HP2y6/kUFr5iBgDdyO9Vhz5rZGu0HEAkDw
mBhV5pDEvzbZu+LE5PRkJYSLQMkuZk9qsg45qxgTxdmJh5GEXXEE/qmJAp87
EAXPfK8JN67U0qczcPzT/XcHh37rKcZldWrAC4erU422wjG5tZ5xzx3jFG6+
sBidgIV6g9WMERPrxxdgwC6o2HEtQ53BrndvcepxgiTwC9haheoeCqDcblmj
AA03JSA6d06g3mClAueATTHn6JOPwbbDAL4Qw1ealr480PvcurXv2lU/Ge8A
OJbZcOHVhgO3r1bKLZEWnQ9GtA8Y11G1emoEmI9TgO3VdfyQyyswaBi4dK9k
FTVYu5YOd9imoHNAFHUEcJO8KCLyPOSVXY1aVMCHjs+tJ+1MjXH3JHW7twA1
M3gOfia5pCahBMfn5cg8LvLH8ezFKs+OCD5O9UgDKuvmmiYU7Zus4xvGAHEl
gPDvRnGsbYfBkW15HIUd2g1df8gLMNa3ywVQWNVN7qnlbBYFvqb+aHr26xQA
AAeMpmtCoqx74Z6toeAL20int6aOOQbX0aee+7nf++2eflk/fjQFVASU1kEb
GtRSNTPwPoh+LJnPyBzDK6ehPtrlGoNppkITToyh7Lhi83WFzcNVDrYhTMee
y3reRZtfZk6lqXdwE7tNcVfpkwCWhiTL9E6CMGd8b3yGC4rl1wmFgaksJeLa
BmV+T2Fla2+Tw1Ffx+zkgvPKgCmpM+06C5YN5gXodqYfzZf/Q/H5qQAbfifP
F9jiQUx3wuTAIr3PHGvt2zGP8Q3aCnbZRbcmI5VIAhHgOUcQkKPfXWBIMq6y
bPP/EYePUSJQtMGXd1s5khmUbWrxYHdKr7OGhi2P2LO6ko+WFvuKSgAT3AG2
Ifrm0j7a0jtccX58hmCCk8mtqKTMbCsX98DwBDuPwpMaW6HgudWM6XXZ77Si
UAOLouxUXirCW2PolLa0PmfLX0P8dec0/NYsZw2xJIWKE3xptYvy65zEU0k7
DpRFki4Kwc0vPhyzOaxXc18VJeckVNeCJvXjj1nTPF5QCAggSvDBYNSzL3Cp
GRU2Tx4LTz4HFu9lQCpOlqBIk78Sn114mLKWuWFXgrWF3l7dobg9RKcXfIZ9
t7HRE+0MuJjW71PF2S8X14chA31xLvrP1itkvDtLzVXJLcHuKPO4h5Fu7OXz
sSzx9OX19WYNOV1dGcfAX/CWeTYe+qPUyMz4MFrYRqHaVV/DQNabPMGmeLm9
3Yc/L/DPl/jnK/zzDfzZ2cE/+GDnJf7Bpzv4dOfrPtam3C4D7kw4L0Vjw6ot
A3HFcZj1MO5kPi1A9ndv3WPq7IVfWi8m500xBFbHz2sJomwkCctUZXOLNZ24
SpW2U1iBcoEiU59rbAhP+/wkizXEFasyFqp0VqTrQOU61uuGeKX8cL1i/w/v
xIctH19RP5KuYhGBUzOLAx5vC+uDDLBoidUhSLblExv+dUBj+RdlVNDW3p5+
hIV96WEBPTrKQwzmdXqFJ/zzhQ5NH2DxaNdxJcpz5Hhy72cLPxP/H0lS884H
n/DE+rJjWUxuZSRvYF64VPyF1b8+hKO3cnFBKuB2R21UmeBTZiRHgFRxbrdb
Gn+oiTsY4OzaFsdlwQjAmQV32KjxDrPFWKGZFVXLiOujOgXwSuihGvZX9/RD
Zq6u+jaFz4TEAAGDm89YPO4tFp9IHOKigZyW7EqnFfDJSUjGiXBZfryM8C0Y
DTcSiQYpNO7muc23+GgRNJ5MeDQP4oYN6btb6vAlbHLvrj8/qfjepMv1MjGC
Vp/YQGCXH7Hk+NrDjAENVFsCaWNDEG2h1Fz817cF5+5wxr19hTvN8Qc5C39W
5OO9hevh49xFOD70l7/okJH7y8Yf7TG8mDzGZXhBeZjP8CPf7TSCED7Ma6zv
/LMUjtyOgdZ9Kuq8JUiuBYQaX3AF6MdlgVLFb3uW8fDut9aB09uXn9vfmbyI
dr3deHRwgG8/+JzXxN0edK8lSbjtp1sR1+FfCxIrSXsjpaUW99xFcXsBt+0v
gRHUpTvl5Ev/mnHu574/QqN+mE8KQM/iDRU+tHhW8cMLroro4lijD5+4WXHK
/ghy2L3kDj/JRravte3c3+goNn7gBgd1H2rx77/V4Qqv+QVXBenPUfN5FL59
iG6gqqtR8/bprM85F/JnJ+q5qvDIHUPryGC1zql5xVwrAjXhsTUVmXH3uCEH
kbLmJusth0l4MxVpjZGXDLiLvtB1AiB66dxovA0s1FyIjoMOj9l57eRcS2u6
jvc91Ff5t93KVzmdP69zmT41exsh96s1+zwkcL+R4e1kZiMJ/JhduUJNIKoh
3NzOLf9rMPPYgMocwGtJoyCJ2ZjBw4vUP1zHQAD1LHDRfYmx2vEFha7YD7uu
99/9GO4sVarHVBiOtx4BBHYqfXPzH1jv+uU3X9HB00c6s+5jK62a7lbxdXRg
ZeUs5kOPqjQ6+OuQyqc6pMIHpz/T8yk0uT/vbEpbX+51OKVxKqQ+o/IHHkGJ
T7w0Dp/40OneJ1DCOX13K8HqZSrRWNTrqkn55edfVWGQm4Qd/WHoxiFpvhjH
g1Jd8KVFXN0FPYOOuOMud1mlX352RQWhUH7lHGaolFd46Tb16eDmLz/7if29
1zsadzPT3V+GlxvE+Mgxx2+u333L7GDQrM4P15uF6vtgy13VUeM4P9oXuqXD
Wn/Dq2yKWPMKH7ZFzDIYmiZan/ZX1yBR9W0hirkx/HNPB4mjvZM9BCnRRVq9
3ge0CtHt2n1/GTfesOwk8l7nGEN0t8aVfATJCoimuzrNvMrcpGZ1rNW8XZMu
VgnXyXbdCosLjy7nSmVLfwNa6wSof7H7kFPzLrVwuYtj85m/s6zJavDa4XKz
Xu9dHhKQoFQzlOD4rrMEQLPzTIw8GtwH4YM1uuSsaeteXHeBjiasCIEJHg5p
X7bTDeZWS7ib9Qp018SAryWcm8xMlh5fgLgbPkPeuIghIc0F12PdwQy8nT1n
quiqQxcwBevX0jh3j1N8SWqj5MMbBu//1/ZFZcJ5fY09110iEcEg0wmc2BzP
XBUHeU8PGoGvhQb4Ud/Fgf+rA/R8iT9aA5Ta+GIFRLfH+lLxjUy+IIldQvNu
i8bVFnz9OuGO/wXn2svFf2IAAA==

-->

</rfc>
