doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

diff --git a/doc/rfc/rfc7725.txt b/doc/rfc/rfc7725.txt
new file mode 100644
index 0000000..91d8e3a
--- /dev/null
+++ b/doc/rfc/rfc7725.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           T. Bray
+Request for Comments: 7725                                    Textuality
+Category: Standards Track                                  February 2016
+ISSN: 2070-1721
+
+
+             An HTTP Status Code to Report Legal Obstacles
+
+Abstract
+
+   This document specifies a Hypertext Transfer Protocol (HTTP) status
+   code for use when resource access is denied as a consequence of legal
+   demands.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   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 (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+Bray                         Standards Track                    [Page 1]
+
+RFC 7725                     HTTP-status-451               February 2016
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   3.  451 Unavailable For Legal Reasons . . . . . . . . . . . . . .   2
+   4.  Identifying Blocking Entities . . . . . . . . . . . . . . . .   3
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   5
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5
+
+1.  Introduction
+
+   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 that includes the
+   requested resource.
+
+   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.
+
+   [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 [RFC4084] states, such restrictions should be made explicit.
+
+2.  Requirements
+
+   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 [RFC2119].
+
+3.  451 Unavailable For Legal Reasons
+
+   This status code indicates that the server is denying access to the
+   resource as a consequence of a legal demand.
+
+   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.
+
+   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:
+
+
+
+Bray                         Standards Track                    [Page 2]
+
+RFC 7725                     HTTP-status-451               February 2016
+
+
+   HTTP/1.1 451 Unavailable For Legal Reasons
+   Link: <https://spqr.example.org/legislatione>; rel="blocked-by"
+   Content-Type: text/html
+
+   <html>
+    <head><title>Unavailable For Legal Reasons</title></head>
+    <body>
+     <h1>Unavailable For Legal Reasons</h1>
+     <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.</p>
+    </body>
+   </html>
+
+   The use of the 451 status code implies neither the existence nor
+   nonexistence 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.
+
+   Note that in many cases clients can still access the denied resource
+   by using technical countermeasures such as a VPN or the Tor network.
+
+   A 451 response is cacheable by default, i.e., unless otherwise
+   indicated by the method definition or explicit cache controls; see
+   [RFC7234].
+
+4.  Identifying Blocking Entities
+
+   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 that could choose to deny access -- for example, ISPs,
+   cache providers, and DNS servers.
+
+   It is useful, when legal blockages occur, to be able to identify the
+   entities actually implementing the blocking.
+
+   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
+   URI reference [RFC3986] identifying itself.  When used for this
+   purpose, the "Link" header field MUST have a "rel" parameter whose
+   value is "blocked-by".
+
+   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.
+
+
+
+Bray                         Standards Track                    [Page 3]
+
+RFC 7725                     HTTP-status-451               February 2016
+
+
+5.  Security Considerations
+
+   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.
+
+6.  IANA Considerations
+
+   The HTTP Status Codes Registry has been updated with the following
+   entry:
+
+   o  Code: 451
+
+   o  Description: Unavailable For Legal Reasons
+
+   o  Specification: RFC 7725
+
+   The Link Relation Type Registry has been updated with the following
+   entry:
+
+   o  Relation Name: blocked-by
+
+   o  Description: Identifies the entity that blocks access to a
+      resource following receipt of a legal demand.
+
+   o  Reference: RFC 7725
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, DOI 10.17487/RFC3986, January 2005,
+              <http://www.rfc-editor.org/info/rfc3986>.
+
+   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988,
+              DOI 10.17487/RFC5988, October 2010,
+              <http://www.rfc-editor.org/info/rfc5988>.
+
+
+
+
+
+Bray                         Standards Track                    [Page 4]
+
+RFC 7725                     HTTP-status-451               February 2016
+
+
+   [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
+              Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
+              RFC 7234, DOI 10.17487/RFC7234, June 2014,
+              <http://www.rfc-editor.org/info/rfc7234>.
+
+7.2.  Informative References
+
+   [RFC4084]  Klensin, J., "Terminology for Describing Internet
+              Connectivity", BCP 104, RFC 4084, DOI 10.17487/RFC4084,
+              May 2005, <http://www.rfc-editor.org/info/rfc4084>.
+
+   [RFC4924]  Aboba, B., Ed. and E. Davies, "Reflections on Internet
+              Transparency", RFC 4924, DOI 10.17487/RFC4924, July 2007,
+              <http://www.rfc-editor.org/info/rfc4924>.
+
+Acknowledgements
+
+   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.
+
+   Thanks also to Ray Bradbury.
+
+Author's Address
+
+   Tim Bray
+   Textuality
+
+   Email: tbray@textuality.com
+   URI:   http://www.tbray.org/ongoing/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bray                         Standards Track                    [Page 5]
+