draft-ietf-httpbis-legally-restricted-status-04.txt   rfc7725.txt 
HTTP Working Group T. Bray Internet Engineering Task Force (IETF) T. Bray
Internet-Draft Textuality Request for Comments: 7725 Textuality
Intended status: Standards Track November 10, 2015 Category: Standards Track February 2016
Expires: May 13, 2016 ISSN: 2070-1721
An HTTP Status Code to Report Legal Obstacles An HTTP Status Code to Report Legal Obstacles
draft-ietf-httpbis-legally-restricted-status-04
Abstract Abstract
This document specifies a Hypertext Transfer Protocol (HTTP) status This document specifies a Hypertext Transfer Protocol (HTTP) status
code for use when resource access is denied as a consequence of legal code for use when resource access is denied as a consequence of legal
demands. demands.
Editorial Note (To be removed by RFC Editor before publication)
Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at [1].
Working Group information can be found at [2] and [3]; source code
and issues list for this draft can be found at [4].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on May 13, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7725.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2
3. 451 Unavailable For Legal Reasons . . . . . . . . . . . . . . 3 3. 451 Unavailable For Legal Reasons . . . . . . . . . . . . . . 2
4. Identifying Blocking Entities . . . . . . . . . . . . . . . . 3 4. Identifying Blocking Entities . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction 1. Introduction
This document specifies a Hypertext Transfer Protocol (HTTP) status This document specifies a Hypertext Transfer Protocol (HTTP) status
code for use when a server operator has received a legal demand to 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 deny access to a resource or to a set of resources that includes the
requested resource. requested resource.
This status code can be used to provide transparency in circumstances This status code can be used to provide transparency in circumstances
where issues of law or public policy affect server operations. This where issues of law or public policy affect server operations. This
transparency may be beneficial both to these operators and to end transparency may be beneficial both to these operators and to end
users. users.
[RFC4924] discusses the forces working against transparent operation [RFC4924] discusses the forces working against transparent operation
of the Internet; these clearly include legal interventions to of the Internet; these clearly include legal interventions to
restrict access to content. As that document notes, and as Section 4 restrict access to content. As that document notes, and as Section 4
of [RFC4084] states, such restrictions should be made explicit. of [RFC4084] states, such restrictions should be made explicit.
Feedback should occur on the ietf-http-wg@w3.org mailing list.
2. Requirements 2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. 451 Unavailable For Legal Reasons 3. 451 Unavailable For Legal Reasons
This status code indicates that the server is denying access to the This status code indicates that the server is denying access to the
resource as a consequence of a legal demand. resource as a consequence of a legal demand.
skipping to change at page 3, line 34 skipping to change at page 3, line 20
<head><title>Unavailable For Legal Reasons</title></head> <head><title>Unavailable For Legal Reasons</title></head>
<body> <body>
<h1>Unavailable For Legal Reasons</h1> <h1>Unavailable For Legal Reasons</h1>
<p>This request may not be serviced in the Roman Province <p>This request may not be serviced in the Roman Province
of Judea due to the Lex Julia Majestatis, which disallows of Judea due to the Lex Julia Majestatis, which disallows
access to resources hosted on servers deemed to be access to resources hosted on servers deemed to be
operated by the People's Front of Judea.</p> operated by the People's Front of Judea.</p>
</body> </body>
</html> </html>
The use of the 451 status code implies neither the existence nor non- The use of the 451 status code implies neither the existence nor
existence of the resource named in the request. That is to say, it nonexistence of the resource named in the request. That is to say,
is possible that if the legal demands were removed, a request for the it is possible that if the legal demands were removed, a request for
resource still might not succeed. the resource still might not succeed.
Note that in many cases clients can still access the denied resource Note that in many cases clients can still access the denied resource
by using technical countermeasures such as a VPN or the Tor network. by using technical countermeasures such as a VPN or the Tor network.
A 451 response is cacheable by default; i.e., unless otherwise A 451 response is cacheable by default, i.e., unless otherwise
indicated by the method definition or explicit cache controls; see indicated by the method definition or explicit cache controls; see
[RFC7234]. [RFC7234].
4. Identifying Blocking Entities 4. Identifying Blocking Entities
As noted above, when an attempt to access a resource fails with As noted above, when an attempt to access a resource fails with
status 451, the entity blocking access might or might not be the status 451, the entity blocking access might or might not be the
origin server. There are a variety of entities in the resource- origin server. There are a variety of entities in the resource-
access path which could choose to deny access, for example ISPs, access path that could choose to deny access -- for example, ISPs,
cache providers, and DNS servers. cache providers, and DNS servers.
It is useful, when legal blockages occur, to be able to identify the It is useful, when legal blockages occur, to be able to identify the
entities actually implementing the blocking. entities actually implementing the blocking.
When an entity blocks access to a resource and returns status 451, it When an entity blocks access to a resource and returns status 451, it
SHOULD include a "Link" HTTP header field [RFC5988] whose value is a SHOULD include a "Link" HTTP header field [RFC5988] whose value is a
URI reference [RFC3986] identifying itself. When used for this URI reference [RFC3986] identifying itself. When used for this
purpose, the "Link" header field MUST have a "rel" parameter whose purpose, the "Link" header field MUST have a "rel" parameter whose
value is "blocked-by". value is "blocked-by".
The intent is that the header be used to identify the entity actually The intent is that the header be used to identify the entity actually
implementing blockage, not any other entity mandating it. A human implementing blockage, not any other entity mandating it. A human-
readable response body, as discussed above, is the appropriate readable response body, as discussed above, is the appropriate
location for discussion of administrative and policy issues. location for discussion of administrative and policy issues.
5. Security Considerations 5. Security Considerations
Clients cannot rely upon the use of the 451 status code. It is Clients cannot rely upon the use of the 451 status code. It is
possible that certain legal authorities might wish to avoid possible that certain legal authorities might wish to avoid
transparency, and not only demand the restriction of access to transparency, and not only demand the restriction of access to
certain resources, but also avoid disclosing that the demand was certain resources, but also avoid disclosing that the demand was
made. made.
6. IANA Considerations 6. IANA Considerations
The HTTP Status Codes Registry should be updated with the following The HTTP Status Codes Registry has been updated with the following
entry: entry:
o Code: 451 o Code: 451
o Description: Unavailable for Legal Reasons o Description: Unavailable For Legal Reasons
o Specification: [ this document ] o Specification: RFC 7725
The Link Relation Type Registry should updated with the following The Link Relation Type Registry has been updated with the following
entry: entry:
o Relation Name: blocked-by o Relation Name: blocked-by
o Description: Identifies the entity blocking access to a resource o Description: Identifies the entity that blocks access to a
folllowing on receipt of a legal demand. resource following receipt of a legal demand.
o Reference: This document o Reference: RFC 7725
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66,
3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://www.rfc-editor.org/info/rfc3986>.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/ [RFC5988] Nottingham, M., "Web Linking", RFC 5988,
RFC5988, October 2010, DOI 10.17487/RFC5988, October 2010,
<http://www.rfc-editor.org/info/rfc5988>. <http://www.rfc-editor.org/info/rfc5988>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014, RFC 7234, DOI 10.17487/RFC7234, June 2014,
<http://www.rfc-editor.org/info/rfc7234>. <http://www.rfc-editor.org/info/rfc7234>.
7.2. Informative References 7.2. Informative References
[RFC4084] Klensin, J., "Terminology for Describing Internet [RFC4084] Klensin, J., "Terminology for Describing Internet
Connectivity", BCP 104, RFC 4084, DOI 10.17487/RFC4084, Connectivity", BCP 104, RFC 4084, DOI 10.17487/RFC4084,
May 2005, <http://www.rfc-editor.org/info/rfc4084>. May 2005, <http://www.rfc-editor.org/info/rfc4084>.
[RFC4924] Aboba, B., Ed. and E. Davies, "Reflections on Internet [RFC4924] Aboba, B., Ed. and E. Davies, "Reflections on Internet
Transparency", RFC 4924, DOI 10.17487/RFC4924, July 2007, Transparency", RFC 4924, DOI 10.17487/RFC4924, July 2007,
<http://www.rfc-editor.org/info/rfc4924>. <http://www.rfc-editor.org/info/rfc4924>.
Appendix A. Acknowledgements Acknowledgements
Thanks to Terence Eden, who observed that the existing status code Thanks to Terence Eden, who observed that the existing status code
403 was not really suitable for this situation, and suggested the 403 was not really suitable for this situation, and suggested the
creation of a new status code. creation of a new status code.
Thanks also to Ray Bradbury. Thanks also to Ray Bradbury.
Author's Address Author's Address
Tim Bray Tim Bray
 End of changes. 25 change blocks. 
53 lines changed or deleted 39 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/