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

Amos Jeffries <squid3@treenet.co.nz> Wed, 30 September 2015 04:14 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 6ABC91B5B75 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 29 Sep 2015 21:14:40 -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 wagOsHUzXLAI for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 29 Sep 2015 21:14:36 -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 CF1E41B5B74 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 29 Sep 2015 21:14:36 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Zh8jp-0006DR-DB for ietf-http-wg-dist@listhub.w3.org; Wed, 30 Sep 2015 04:11:29 +0000
Resent-Date: Wed, 30 Sep 2015 04:11:29 +0000
Resent-Message-Id: <E1Zh8jp-0006DR-DB@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 <squid3@treenet.co.nz>) id 1Zh8ji-0006Ck-IV for ietf-http-wg@listhub.w3.org; Wed, 30 Sep 2015 04:11:22 +0000
Received: from 121-99-228-82.static.orcon.net.nz ([121.99.228.82] helo=treenet.co.nz) by lisa.w3.org with esmtp (Exim 4.80) (envelope-from <squid3@treenet.co.nz>) id 1Zh8jg-00038V-Mj for ietf-http-wg@w3.org; Wed, 30 Sep 2015 04:11:22 +0000
Received: from [192.168.20.251] (unknown [121.98.42.176]) by treenet.co.nz (Postfix) with ESMTP id 2647BE6EB3 for <ietf-http-wg@w3.org>; Wed, 30 Sep 2015 16:10:47 +1200 (NZST)
To: ietf-http-wg@w3.org
References: <0E5383DD-927C-493F-90C4-4A9C7CB93308@mnot.net>
From: Amos Jeffries <squid3@treenet.co.nz>
X-Enigmail-Draft-Status: N1110
Message-ID: <560B60AA.504@treenet.co.nz>
Date: Wed, 30 Sep 2015 17:10:18 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; 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=121.99.228.82; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-4.8
X-W3C-Hub-Spam-Report: AWL=-0.157, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_RCVD_IP=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1Zh8jg-00038V-Mj 9d46f14b0036c3e56daf531196f5bc5c
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/560B60AA.504@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30286
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 30/09/2015 4:29 p.m., Mark Nottingham wrote:
> Everyone,
> 
> After talking with the editor and our AD, I think this document is ready to progress; the only remaining action on it is to add the registration template for the new link relation.
> 
> So, this is the announcement of WGLC for: 
>  https://tools.ietf.org/html/draft-ietf-httpbis-legally-restricted-status-02
> 
> Please review the document carefully, and comment on this list.
> 

Section 1:

 "for use when a server operator has a received a legal demand to deny
access to a resource"

This is a lot more restrictive than what I understood was being agreed
to. This phrasing implies that a specific-URL DMCA type notice is
required before the status may be used.

It would be a lot more reasonable to also allow the status to be used
when a blanket law requirement was levelled on the operator. For example
schools following laws on porn fitering, or national level restrictions
on categories of traffic. In cases like these operators dont receive
per-resource demands, they often receive a one-off notice "law X applies
to you" and are then expected to censor proactively to the best of their
ability and face the court on overlooked URLs.

Probably this can be resolved with s/legal demand/legal requirement/.

There are other "legal demand" phrase uses elsewhere to keep in sync.

If "legal demand" is being used with a meaning other than a specific
warrant DMCA takedown etc. Then that definitely needs to be explained.


Section 1:

 "This transparency s/may be/is/ beneficial"

 How much benefit and in what ways is the questionable part IMHO. Not
whether there is benefit.


Section 4:
 "A human readable response body, as discussed above, is the appropriate
location for discussion of administrative and policy issues."

 This is specification document, not a discussion one. I suggest
rephrasing along the lines of:

 "A human readable response body, as defined above, is the appropriate
location for text regarding administrative and policy issues."

and/or with a reference to section 3 instead of just "above".



Amos