Re: Working Group Last Call for draft-ietf-httpbis-legally-restricted-status
Mark Nottingham <mnot@mnot.net> Thu, 01 October 2015 01:03 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A931ACDE9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Sep 2015 18:03:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiA4gGzJFHGW for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Sep 2015 18:03:54 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 733F91ACDE3 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 30 Sep 2015 18:03:48 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ZhSEf-00025h-6u for ietf-http-wg-dist@listhub.w3.org; Thu, 01 Oct 2015 01:00:37 +0000
Resent-Date: Thu, 01 Oct 2015 01:00:37 +0000
Resent-Message-Id: <E1ZhSEf-00025h-6u@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1ZhSEc-00024w-4G for ietf-http-wg@listhub.w3.org; Thu, 01 Oct 2015 01:00:34 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by maggie.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1ZhSEQ-0006ED-1W for ietf-http-wg@w3.org; Thu, 01 Oct 2015 01:00:33 +0000
Received: from [192.168.0.21] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (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 <mnot@mnot.net>
In-Reply-To: <560C8035.5010209@measurement-factory.com>
Date: Thu, 01 Oct 2015 10:59:54 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B7347414-BC49-4D61-844B-6056F9155345@mnot.net>
References: <0E5383DD-927C-493F-90C4-4A9C7CB93308@mnot.net> <560C8035.5010209@measurement-factory.com>
To: Alex Rousskov <rousskov@measurement-factory.com>
X-Mailer: Apple Mail (2.2104)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
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: maggie.w3.org 1ZhSEQ-0006ED-1W eb2cea4a01370b1c6bb97cd9f51bff96
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Working Group Last Call for draft-ietf-httpbis-legally-restricted-status
Archived-At: <http://www.w3.org/mid/B7347414-BC49-4D61-844B-6056F9155345@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30293
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Hi Alex, > On 1 Oct 2015, at 10:37 am, Alex Rousskov <rousskov@measurement-factory.com> 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 <https://www.chillingeffects.org/> 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 <https://github.com/httpwg/http-extensions/issues/80>. 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. Cheers, -- Mark Nottingham https://www.mnot.net/
- Working Group Last Call for draft-ietf-httpbis-le… Mark Nottingham
- Re: Working Group Last Call for draft-ietf-httpbi… Amos Jeffries
- Re: Working Group Last Call for draft-ietf-httpbi… Tim Bray
- Re: Working Group Last Call for draft-ietf-httpbi… Ted Hardie
- Re: Working Group Last Call for draft-ietf-httpbi… Alex Rousskov
- Re: Working Group Last Call for draft-ietf-httpbi… Mark Nottingham
- Re: Working Group Last Call for draft-ietf-httpbi… Alex Rousskov
- Re: Working Group Last Call for draft-ietf-httpbi… Mark Nottingham
- Re: Working Group Last Call for draft-ietf-httpbi… Alex Rousskov
- Re: Working Group Last Call for draft-ietf-httpbi… Julian Reschke
- Re: Working Group Last Call for draft-ietf-httpbi… Mark Nottingham
- Re: Working Group Last Call for draft-ietf-httpbi… Mark Nottingham
- Re: Working Group Last Call for draft-ietf-httpbi… Mark Nottingham
- Re: Working Group Last Call for draft-ietf-httpbi… Alex Rousskov
- Re: Working Group Last Call for draft-ietf-httpbi… Matthew Kerwin
- Re: Working Group Last Call for draft-ietf-httpbi… Amos Jeffries
- Re: Working Group Last Call for draft-ietf-httpbi… Alex Rousskov
- Re: Working Group Last Call for draft-ietf-httpbi… Matthew Kerwin
- Re: Working Group Last Call for draft-ietf-httpbi… Mark Nottingham
- Re: Working Group Last Call for draft-ietf-httpbi… Alex Rousskov
- Re: Working Group Last Call for draft-ietf-httpbi… Krzysztof Jurewicz
- Re: Working Group Last Call for draft-ietf-httpbi… Mark Nottingham
- Re: Working Group Last Call for draft-ietf-httpbi… Tim Bray