draft-ietf-httpbis-legally-restricted-status.xml

<?xml version="1.0" encoding="utf-8"?>

<!DOCTYPE rfc [
<!ENTITY rfc2119 SYSTEM 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc4084 SYSTEM 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4084.xml'>
<!ENTITY rfc4924 SYSTEM 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4924.xml'>
<!ENTITY rfc7234 SYSTEM 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7234.xml'>
<!ENTITY rfc3986 SYSTEM 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml'>
<!ENTITY rfc5988 SYSTEM 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5988.xml'>
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocdepth="1" ?>
<?rfc tocindent="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>

<rfc ipr="trust200902" 
     docName="draft-ietf-httpbis-legally-restricted-status-latest" 
     category="std">

  <front>
    <title abbrev="HTTP-status-451">An HTTP Status Code to Report Legal Obstacles</title>
    <author initials="T." surname="Bray" fullname="Tim Bray">
      <organization>Textuality</organization>
      <address>
      	<email>tbray@textuality.com</email>
      	<uri>http://www.tbray.org/ongoing/</uri>
      </address>
    </author>

    <date/>
    <area>Applications and Real-Time</area>
    <workgroup>HTTP</workgroup>
    <keyword>HTTP</keyword>

    <abstract>

      <t>This document specifies a Hypertext Transfer Protocol (HTTP) 
      status code for use when resource access is denied as a
      consequence of legal demands.</t>

    </abstract>

  <note title="Editorial Note (To be removed by RFC Editor before publication)">
    <t>
      Discussion of this draft takes place on the HTTPBIS working group mailing list
      (ietf-http-wg@w3.org), which is archived at <eref
      target="https://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
    </t>
    <t>
      Working Group information can be found at <eref
      target="https://tools.ietf.org/wg/httpbis/"/>
      and <eref target="http://httpwg.github.io/"/>; source code and issues
      list for this draft can be found at
      <eref target="https://github.com/httpwg/http-extensions"/>.
    </t>
    <!--<t>
      The changes in this draft are summarized in <xref target="changes.since.00"/>.
    </t>-->
  </note>
  </front>

  <middle>

    <section title="Introduction">
      <t>This document specifies a Hypertext Transfer Protocol (HTTP) 
      status code for use when a server operator has received a legal
      demand to deny access to a resource or to a set of resources which
      includes the requested resource.</t>

      <t>This status code can be used to provide transparency
      in circumstances where issues of law or public policy affect server
      operations. This transparency may be beneficial both to these operators
      and to end users.</t>
      <t><xref target="RFC4924"/> discusses the forces working
      against transparent operation of the Internet; these clearly include
      legal interventions to restrict access to content.  As that document
      notes, and as Section 4 of <xref target="RFC4084"/> states, such
      restrictions should be made explicit.</t>
      
      <t>Feedback should occur on the ietf-http-wg@w3.org mailing list.</t>
    </section>

    <section title="Requirements">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
      this document are to be interpreted as described in <xref
      target="RFC2119"/>.</t>
    </section>


    <section title="451 Unavailable For Legal Reasons">
      <t>This status code indicates that the server is denying access
      to the resource as a consequence of a legal demand.</t> 
      
      <t>The server in question might not be an origin server.  This type of
      legal demand typically most directly affects the operations of ISPs and
      search engines.</t>

      <t>Responses using this status code SHOULD include an explanation,
      in the response body, of the details of the legal demand: the party
      making it, the applicable legislation or regulation, and what classes of
      person and resource it applies
      to.  For example:</t>

      <figure><artwork type="example">
HTTP/1.1 451 Unavailable For Legal Reasons
Link: &lt;https://spqr.example.org/legislatione>; rel="blocked-by"
Content-Type: text/html

&lt;html>
 &lt;head>&lt;title>Unavailable For Legal Reasons&lt;/title>&lt;/head>
 &lt;body>
  &lt;h1>Unavailable For Legal Reasons&lt;/h1>
  &lt;p>This request may not be serviced in the Roman Province 
  of Judea due to the Lex Julia Majestatis, which disallows 
  access to resources hosted on servers deemed to be 
  operated by the People's Front of Judea.&lt;/p>
 &lt;/body>
&lt;/html></artwork></figure>

<t>The use of the 451 status code implies neither the existence nor
non-existence of the resource named in the request. That is to say,
it is possible that if the legal demands were removed,
a request for the resource still might not succeed.</t>

<t>Note that in many cases clients can still access the denied resource by
using technical countermeasures such as a VPN or the Tor network.</t>

<t>A 451 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls; see <xref target="RFC7234"/>.</t>
    </section>

    <section title="Identifying Blocking Entities">
      <t>As noted above, when an attempt to access a resource fails
      with status 451, the entity blocking access might or might not be the
      origin server.  There are a variety of entities in the resource-access
      path which could choose to deny access, for example ISPs,
      cache providers, and DNS servers.</t>
      <t>It is useful, when legal blockages occur, to be able to identify the
      entities actually implementing the blocking.</t>
      <t>When an entity blocks access to a resource and returns status 451, it
      SHOULD include a "Link" HTTP header field <xref target="RFC5988"/>
      whose value is a URI reference <xref target="RFC3986"/>
      identifying itself.  When used for this purpose, the "Link" header field
      MUST have a "rel" parameter whose value is "blocked-by".</t>
      <t>The intent is that the header be used to identify the entity actually
      implementing blockage, not any other entity mandating it.  A
      human readable response body, as discussed above, is the appropriate
      location for discussion of administrative and policy issues.</t>
    </section>

    <section title="Security Considerations">

      <t>Clients cannot rely upon the use of the 451 status code.
      It is possible that certain legal authorities might wish
      to avoid transparency, and not only demand the restriction of access 
      to certain resources, but also avoid disclosing that the demand 
      was made.  </t>

    </section>

    <section title="IANA Considerations">
      <t>The HTTP Status Codes Registry should be updated with the
      following entry:</t>

      <t><list style="symbols">
	<t>Code: 451</t>
	<t>Description: Unavailable for Legal Reasons</t>
	<t>Specification: [ this document ]</t>
      </list></t>

      <t>The Link Relation Type Registry should updated with the
      following entry:</t>
      <t><list style="symbols">
	<t>Relation Name: blocked-by</t>
	<t>Description: Identifies the entity blocking access to a resource
	folllowing on receipt of a legal demand.</t>
	<t>Reference: This document</t>
      </list></t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      &rfc2119;
      &rfc7234;
      &rfc3986;
      &rfc5988;
    </references>

    <references title="Informative References">
      &rfc4084;
      &rfc4924;
    </references>

    <section title="Acknowledgements">
      <t>Thanks to Terence Eden, who observed that the existing
      status code 403 was not really suitable for this situation, and
      suggested the creation of a new status code.</t>
      <t>Thanks also to Ray Bradbury.</t>
    </section>


  </back>
</rfc>