An HTTP Status Code to Report Legal Obstacles
draft-ietf-httpbis-legally-restricted-status-04

[Ballot comment]
Why do we have this sentence?

  Feedback should occur on the ietf-http-wg@w3.org mailing list.

What sort of feedback is expected, if this becomes an RFC?

[Ballot comment]
I think the dicussion has run to the end of it natural course and touching it further will likely make it worse not better. so despite any misgivings I might have I think it should probably go forward without any changes to the current text respecting definitions of legally restricted.

Fred Baker did the opsdir review, I am pleased to see that we are congruent.

[Ballot comment]
I realize that the way this document uses the term "legal demand" has been discussed at some length, but I'm concerned that the way that it is used may limit the applicability of the status code, so I wanted to mention that here.

The term "legal" has at least two meanings, one being "related to the law" and the other being "authorized by law." I think it would be a shame if use of this status code could be interpreted as a concession on the part of a server operator that any particular demand was authorized by law. Sometimes a server operator may feel the need to comply with a request even if it does not believe the request is authorized by law (e.g., while litigation is pending, or out of fear of adverse consequences for its employees). Operators shouldn't be put in the position where they have to be concerned that using the status code could later be used as evidence that they believed a particular request was authorized by law, particularly if there is a chance that they will be sued for having blocked the resource.

The tricky part is that it takes more words to convey this concept than the document currently uses. My suggestion would be to replace "legal demand" with "demand based on a claim of legal violation" in the abstract, section 1, and the first paragraph of section 3, and replace all other instances of "legal demand" with "demand." This is a little clunky but it's the best idea I could come up with.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-httpbis-legally-restricted-status-04.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the HTTP Status Codes registry located at:

http://www.iana.org/assignments/http-status-codes/

a new status code is to be registered as follows:

Value: 451
Description: Unavailable for Legal Reasons
Reference: [ RFC-to-be ]

Second, in the Link Relation Types subregistry of the Link Relations registry located at:

http://www.iana.org/assignments/link-relations/

a new relation type is to be registered as follows:

Relation Name: blocked-by
Description: Identifies the entity blocking access to a resource following on receipt of a legal demand.
Reference: [ RFC-to-be ]
Notes: none

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-httpbis-legally-restricted-status@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, barryleiba@gmail.com, mnot@pobox.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (An HTTP Status Code to Report Legal Obstacles) to Proposed Standard


The IESG has received a request from the Hypertext Transfer Protocol WG
(httpbis) to consider the following document:
- 'An HTTP Status Code to Report Legal Obstacles'
  as Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-12-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies a Hypertext Transfer Protocol (HTTP) status
  code for use when resource access is denied as a consequence of legal
  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].




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-legally-restricted-status/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-legally-restricted-status/ballot/


No IPR declarations have been submitted directly on this I-D.

## 1. Summary

Mark Nottingham is the document shepherd; Barry Leiba is the responsible
Area Director.

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

Its requested publication type is Proposed Standard.

## 2. Review and Consensus

This document started as an individual draft, which the WG discussed and
initially decided to "hold". The primary reason for this was that it
wasn't clear if there were use cases that would benefit from a status
code (as opposed to just using the body of the response), and whether
there was interest in deployment.

Over time, this was clarified; both Web sites and consuming software
demonstrated interest. Importantly, we heard that having an indicator
that an automated client could easily detect would help users like Lumen
(formerly, Chilling Effects).

As a result (and after discussion both on list and in meetings), we
decided to adopt the draft.

Technical discussion involved a broad selection of the Working Group.
There was some back and forth about what the right scope for the status
code's semantics should be (as well as whether we needed more than one),
but we were able to achieve consensus on the current document.

451 has already been adopted by some sites on the Web, and based upon
discussions (mostly private), it appears that a significantly larger
number will adopt it once it becomes standard. On the client side,
interest has been expressed by Lumen, Article19, CDT and others.

## 3. Intellectual Property

The author has stated that their direct, personal knowledge of any IPR
related to this document has already been disclosed, in conformance with
BCPs 78 and 79.

# Shepherd Writeup for draft-ietf-httpbis-legally-restricted-status

## 1. Summary

Mark Nottingham is the document shepherd; Barry Leiba is the responsible Area Director.

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

Its requested publication type is Proposed Standard.


## 2. Review and Consensus

This document started as an individual draft, which the WG discussed and initially decided to "hold". The primary reason for this was that it wasn't clear if there were use cases that would benefit from a status code (as opposed to just using the body of the response), and whether there was interest in deployment.

Over time, this was clarified; both Web sites and consuming software demonstrated interest. Importantly, we heard that having an indicator that an automated client could easily detect would help users like Lumen  (formerly, Chilling Effects).

As a result (and after discussion both on list and in meetings), we decided to adopt the draft.

Technical discussion involved a broad selection of the Working Group. There was some back and forth about what the right scope for the status code's semantics should be (as well as whether we needed more than one), but we were able to achieve consensus on the current document.

451 has already been adopted by some sites on the Web, and based upon discussions (mostly private), it appears that a significantly larger number will adopt it once it becomes standard. On the client side, interest has been expressed by Lumen, Article19, CDT and others.


## 3. Intellectual Property

The author has stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.