Re: Working Group Last Call for draft-ietf-httpbis-legally-restricted-status
Alex Rousskov <rousskov@measurement-factory.com> Thu, 01 October 2015 00:41 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 4CC0D1A7D81 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Sep 2015 17:41:21 -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 PlRp_J5GyPwV for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Sep 2015 17:41:19 -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 8AD541A7113 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 30 Sep 2015 17:41:19 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ZhRss-0003YL-R2 for ietf-http-wg-dist@listhub.w3.org; Thu, 01 Oct 2015 00:38:06 +0000
Resent-Date: Thu, 01 Oct 2015 00:38:06 +0000
Resent-Message-Id: <E1ZhRss-0003YL-R2@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 <rousskov@measurement-factory.com>) id 1ZhRso-0003XU-Gf for ietf-http-wg@listhub.w3.org; Thu, 01 Oct 2015 00:38:02 +0000
Received: from mail.measurement-factory.com ([104.237.131.42]) by lisa.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <rousskov@measurement-factory.com>) id 1ZhRsm-000574-Jp for ietf-http-wg@w3.org; Thu, 01 Oct 2015 00:38:02 +0000
Received: from [65.102.233.169] (unknown [65.102.233.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.measurement-factory.com (Postfix) with ESMTPSA id 5B05FE290; Thu, 1 Oct 2015 00:37:35 +0000 (UTC)
To: HTTP Working Group <ietf-http-wg@w3.org>
References: <0E5383DD-927C-493F-90C4-4A9C7CB93308@mnot.net>
From: Alex Rousskov <rousskov@measurement-factory.com>
X-Enigmail-Draft-Status: N1110
Cc: Mark Nottingham <mnot@mnot.net>
Message-ID: <560C8035.5010209@measurement-factory.com>
Date: Wed, 30 Sep 2015 18:37:09 -0600
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <0E5383DD-927C-493F-90C4-4A9C7CB93308@mnot.net>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=104.237.131.42; envelope-from=rousskov@measurement-factory.com; helo=mail.measurement-factory.com
X-W3C-Hub-Spam-Status: No, score=-5.4
X-W3C-Hub-Spam-Report: AWL=-1.495, BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1ZhRsm-000574-Jp 324a313f0790e4745f874925ea675e34
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/560C8035.5010209@measurement-factory.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30292
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>
On 09/29/2015 09:29 PM, Mark Nottingham wrote: > > So, this is the announcement of WGLC for: > https://tools.ietf.org/html/draft-ietf-httpbis-legally-restricted-status-02 > [RFC4924] discusses the forces working against transparent operation > of the Internet; these clearly include legal interventions to > restrict access to content. As that document notes, and as Section 4 > of [RFC4084] states, such restrictions should be made explicit. The above paragraph may be interpreted as a skilful attempt to justify dedicating a special status code to denials based on "legal demands". Neither of the two RFCs mentioned in the quoted paragraph require or even suggest that "legal demands" require such a special treatment. Those RFCs say that restrictions should be disclosed. Using that to justify a new HTTP status code dedicated to a particular type of a restriction is quite a stretch IMHO. HTTP already provides means to satisfy those two RFCs by allowing error responses with arbitrary content that may include all sorts of disclosures. Please note that the above is not an argument against adding a special status code for "legal demand" denials. It is an argument against using those two innocent RFCs as a justification for doing so. I think that paragraph should be deleted. 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?? 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. Alternatively, some serious effort should be made to define "legal demands" and explain why they deserve a special HTTP status code. Thank you, Alex.
- 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