W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: Protocol Action: 'An HTTP Status Code to Report Legal Obstacles' to Proposed Standard (draft-ietf-httpbis-legally-restricted-status-04.txt)

From: Virgil Griffith <i@virgil.gr>
Date: Tue, 22 Dec 2015 14:51:45 +0000
Message-ID: <CADop2NH43z2k7H0cdmQ80RFbwjA6Z7kEGWaY1jFJtsT6KO4UsQ@mail.gmail.com>
To: The IESG <iesg-secretary@ietf.org>, IETF-Announce <ietf-announce@ietf.org>
Cc: httpbis-chairs@ietf.org, draft-ietf-httpbis-legally-restricted-status@ietf.org, ietf-http-wg@w3.org, barryleiba@gmail.com, The IESG <iesg@ietf.org>, mnot@pobox.com, rfc-editor@rfc-editor.org
I'd like to revive the discussion of the 5xx equivalent of this, (tentative
name, error 551) ?

On my website, onion.link, we use both errors.  We use 451 for cases in
which the client's jurisdiction forbids the transmission of content (the
largest case for us is Russia and it's anti-drug laws), but we use 551 for
cases in which the server's jurisdiction (in our case, USA) forbids the
transmission of content (usually child abuse).

I feel this is an important distinction because the implication is that the
client could can VPN around a 451, while for a 551 no VPN would help.


On Tue, Dec 22, 2015 at 1:23 AM The IESG <iesg-secretary@ietf.org> wrote:

> The IESG has approved the following document:
> - 'An HTTP Status Code to Report Legal Obstacles'
>   (draft-ietf-httpbis-legally-restricted-status-04.txt) as Proposed
> Standard
> This document is the product of the Hypertext Transfer Protocol Working
> Group.
> The IESG contact persons are Ben Campbell, Barry Leiba and Alissa Cooper.
> A URL of this Internet Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-legally-restricted-status/
> Technical Summary
> This document specifies a Hypertext Transfer Protocol (HTTP) status code
> for use when resource access is denied as a consequence of legal
> demands.
> 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
> <https://lumendatabase.org> (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.
> Personnel
> Mark Nottingham is the document shepherd; Barry Leiba is the responsible
> Area Director.
Received on Tuesday, 22 December 2015 14:52:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC