Re: Working Group Last Call for draft-ietf-httpbis-legally-restricted-status

Mark Nottingham <> Thu, 01 October 2015 05:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 330BF1B29F4 for <>; Wed, 30 Sep 2015 22:40:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oKKHvmDfGl-M for <>; Wed, 30 Sep 2015 22:40:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CB7E1B29F3 for <>; Wed, 30 Sep 2015 22:40:23 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZhWYj-0006qp-6n for; Thu, 01 Oct 2015 05:37:37 +0000
Resent-Date: Thu, 01 Oct 2015 05:37:37 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZhWVB-0003P8-BY for; Thu, 01 Oct 2015 05:33:57 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1ZhWV7-0000EV-Vp for; Thu, 01 Oct 2015 05:33:56 +0000
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 25A0522E1F4; Thu, 1 Oct 2015 01:33:27 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Thu, 01 Oct 2015 15:33:24 +1000
Cc: HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Alex Rousskov <>
X-Mailer: Apple Mail (2.2104)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.4
X-W3C-Hub-Spam-Report: AWL=1.211, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1ZhWV7-0000EV-Vp 49c33a2c88b78e6760ebc95fc9e2d0bd
Subject: Re: Working Group Last Call for draft-ietf-httpbis-legally-restricted-status
Archived-At: <>
X-Mailing-List: <> archive/latest/30296
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Personal opinions below.

> On 1 Oct 2015, at 2:33 pm, Alex Rousskov <> wrote:
> On 09/30/2015 06:59 PM, Mark Nottingham wrote:
>>> On 1 Oct 2015, at 10:37 am, Alex Rousskov wrote:
>>> If that paragraph is removed, the only justification offered for the new
>>> status code is:
>>>> 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.
>>> Since the existing HTTP error mechanisms can already be used to do all
>>> of the above, that justification is insufficient at best.
>>> I failed to find any other explanation why a new code dedicated to
>>> "blocked by legal demands" responses is needed.
>>> Moreover, the term "legal demand" is itself undefined. Could it mean a
>>> verbal demand from XYZ legal department? A written request by a law
>>> enforcement officer lacking jurisdiction? Does responding with this
>>> status code constitute the responder's agreement that the demand to
>>> block was legal??
>> This is well-covered ground; the purpose of the status code is making
>> it possible to track censorship and similar situations, when the
>> party who is adhering to the legal demand wishes to say so.
> The end result (i.e., the draft) does not reflect the goal you talk
> about above. The proposed status code does not define a "Blocked By
> Sensors or Similar" status code. It defines an "Unavailable For Legal
> Reasons" status code (also documented as a "consequence of legal demands").
> For example, if I am censoring content (your use case!) based on my
> religious believes, then I cannot use the proposed status code unless
> some authority has also issued a "legal demand" for me to do so.

You misunderstand "my use case."  The introduction on the document says clearly:

This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when a server operator has a received a legal demand to deny access to a resource.

You -- as a server operator -- imposing your beliefs upon the content being served doesn't qualify for 451 for exactly that reason; this status code is intended to capture cases when the server operator has been compelled to operate against their wishes by a legal demand, not act as a barometer of what standards (religious, parental, whatever) are self-imposed by publishers around the world.

>> For example, Chilling Effects <> can
>> spider the Web for such content when such a status code is defined.
>> There's already been pre-standardisation deployment of the status
>> code by some sites, and interest from others.
> Removing the words "legal" and "demand" from the draft will not break
> Chilling Effects. The technical mechanism to report the HTTP agent
> responsible for "blocking" the resource remains the same. The status
> code remains the same.

That would introduce a lot of noise and make the status code nearly useless. 

>>> IMHO, the draft should be revised to remove the words "legal" and
>>> "demand". It should specify a generic mechanism to point to the blocking
>>> entity (i.e., Section 4). Such a generic mechanism can then be used by
>>> those who block because of "legal demands" (using their own definition
>>> of that term) and by those who block for other reasons.
>> We've already had discussion along those lines too; see
>> <>.
> Wrong link? Issue 80 is about "origin vs intermediary" distinction. I am
> talking about "legal reasons vs all other blocking reasons" distinction,
> and I am _not_ saying there should be another code added. One code is
> more than enough!
> Said that, if this draft is approved in its too-narrow form, then I sure
> hope somebody submits these drafts:
> * Code 452 (Unavailable For Political Reasons)
> * Code 453 (Unavailable For Religious Reasons)
> * Code 454 (Unavailable For Parental Reasons)
> * Code 455 (Unavailable For Military Reasons)
> * ...
>> I'm very concerned about trying to over-genericise this mechanism;
>> let's not boil an ocean we don't have to.
> The mechanism is already general enough. It is the wording describing
> the applicability of the mechanism that is too restrictive.
>>> Alternatively, some serious effort should be made to define "legal demands"
>> Defining the phrase precisely on a global scale isn't realistic. What do you have in mind?
> I suggest removing that phrase. IMO, that should be done for many
> reasons, including the fact(?) that it is unrealistic to define its
> meaning precisely enough. However, if folks disagree, then _they_ should
> make the effort to define what they use. This is supposed to be a part
> of a protocol specification. Definitions of key terms in protocol specs
> ought to be precise.

The feedback we overwhelmingly have from publishers and potential consumers are that the status code is useful at this granularity.

>>> and explain why they deserve a special HTTP status code.
>> That discussion needs to happen in the WG, not *necessarily* in the draft. 
> The result of that discussion (i.e., the final/polished explanation)
> should be in the draft. If a protocol extension draft does not justify
> the need for the extension (i.e., why the existing mechanisms are
> insufficient), then something went wrong regardless of the preceding WG
> discussion.

RFCs need to be sufficiently well-described to be interoperable; they don't need to defend their existence like an academic paper would.


Mark Nottingham