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

Mark Nottingham <> Thu, 01 October 2015 01:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 57A931ACDE9 for <>; Wed, 30 Sep 2015 18:03:56 -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 qiA4gGzJFHGW for <>; Wed, 30 Sep 2015 18:03:54 -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 733F91ACDE3 for <>; Wed, 30 Sep 2015 18:03:48 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZhSEf-00025h-6u for; Thu, 01 Oct 2015 01:00:37 +0000
Resent-Date: Thu, 01 Oct 2015 01:00: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 1ZhSEc-00024w-4G for; Thu, 01 Oct 2015 01:00:34 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1ZhSEQ-0006ED-1W for; Thu, 01 Oct 2015 01:00:33 +0000
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id B7E7222E261; Wed, 30 Sep 2015 20:59:57 -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 10:59:54 +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.248, 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: 1ZhSEQ-0006ED-1W eb2cea4a01370b1c6bb97cd9f51bff96
Subject: Re: Working Group Last Call for draft-ietf-httpbis-legally-restricted-status
Archived-At: <>
X-Mailing-List: <> archive/latest/30293
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Alex,

> 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. 

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.

> 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 <>. I'm very concerned about trying to over-genericise this mechanism; let's not boil an ocean we don't have to.

> 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?

> and explain why they deserve a special HTTP status code.

That discussion needs to happen in the WG, not *necessarily* in the draft. 


Mark Nottingham