Re: Working Group Last Call for draft-ietf-httpbis-legally-restricted-status
Mark Nottingham <mnot@mnot.net> Thu, 01 October 2015 05:40 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 330BF1B29F4 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Sep 2015 22:40:27 -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 oKKHvmDfGl-M for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Sep 2015 22:40:25 -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 8CB7E1B29F3 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 30 Sep 2015 22:40:23 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ZhWYj-0006qp-6n for ietf-http-wg-dist@listhub.w3.org; Thu, 01 Oct 2015 05:37:37 +0000
Resent-Date: Thu, 01 Oct 2015 05:37:37 +0000
Resent-Message-Id: <E1ZhWYj-0006qp-6n@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1ZhWVB-0003P8-BY for ietf-http-wg@listhub.w3.org; Thu, 01 Oct 2015 05:33:57 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by lisa.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1ZhWV7-0000EV-Vp for ietf-http-wg@w3.org; Thu, 01 Oct 2015 05:33:56 +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 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 <mnot@mnot.net>
In-Reply-To: <560CB7A3.6080201@measurement-factory.com>
Date: Thu, 01 Oct 2015 15:33:24 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <805EFF40-ECA6-4A67-AE3E-F165079F388C@mnot.net>
References: <0E5383DD-927C-493F-90C4-4A9C7CB93308@mnot.net> <560C8035.5010209@measurement-factory.com> <B7347414-BC49-4D61-844B-6056F9155345@mnot.net> <560CB7A3.6080201@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.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: lisa.w3.org 1ZhWV7-0000EV-Vp 49c33a2c88b78e6760ebc95fc9e2d0bd
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/805EFF40-ECA6-4A67-AE3E-F165079F388C@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30296
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>
Personal opinions below. > On 1 Oct 2015, at 2:33 pm, Alex Rousskov <rousskov@measurement-factory.com> 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 <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. > > 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 >> <https://github.com/httpwg/http-extensions/issues/80>. > > > 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. 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