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

Tim Bray <tbray@textuality.com> Wed, 30 September 2015 04:46 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 08DC01B5BC9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 29 Sep 2015 21:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.289
X-Spam-Level:
X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 EF6H7rI2vCAO for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 29 Sep 2015 21:45:58 -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 133711B5BC8 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 29 Sep 2015 21:45:57 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Zh9E1-00078R-Te for ietf-http-wg-dist@listhub.w3.org; Wed, 30 Sep 2015 04:42:41 +0000
Resent-Date: Wed, 30 Sep 2015 04:42:41 +0000
Resent-Message-Id: <E1Zh9E1-00078R-Te@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 <tbray@textuality.com>) id 1Zh9Dv-00073g-PC for ietf-http-wg@listhub.w3.org; Wed, 30 Sep 2015 04:42:35 +0000
Received: from mail-ig0-f173.google.com ([209.85.213.173]) by maggie.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <tbray@textuality.com>) id 1Zh9Dt-0001qS-AX for ietf-http-wg@w3.org; Wed, 30 Sep 2015 04:42:35 +0000
Received: by igxx6 with SMTP id x6so22521835igx.1 for <ietf-http-wg@w3.org>; Tue, 29 Sep 2015 21:42:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rNcxvJ3VNbvcNJEQcTZKlImrm/JMMuZ2Ra+31uegvW0=; b=gtGT3Pi0VXKGM6vFu+nLhUKIFaTR1CbpZitcEGoQMSl+dsFDmvo5ghTlgXL6Nxwrc9 3Pbyf5TgRr7LJtOvN/y7kUWUUWg/9pqgU0aPdBmwKLW6VscBhpv3pCXk2dafL5jd1Dtl DmTF+jCpvRmvAO8SYwSyMIrVNuYMX9Y4O+X4cd2rKN77em3FCdRLLqkRmeZPhGNP26Tb CzySgmaoVGKvowIF9L6Qv1VS0b0h9oeL+rQ+jLMteb51gHFLONLzNy6EG05BiSNtBrYh pCRTa71vM8BOFEDHmqTDz7zIOuz4SJFcRHyxZEN9oAwZCqAr/Eyri0LX47boPKIwBevm 5UYQ==
X-Gm-Message-State: ALoCoQln/K0jQ6Y1bD4pAyXzukPiiG8O/WH8/V0v1v1funC0QdznFNzvoHwWrxvMk4NQgc9SXl12
X-Received: by 10.50.57.102 with SMTP id h6mr3018397igq.29.1443588127179; Tue, 29 Sep 2015 21:42:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.30.4 with HTTP; Tue, 29 Sep 2015 21:41:47 -0700 (PDT)
X-Originating-IP: [24.84.248.61]
In-Reply-To: <560B60AA.504@treenet.co.nz>
References: <0E5383DD-927C-493F-90C4-4A9C7CB93308@mnot.net> <560B60AA.504@treenet.co.nz>
From: Tim Bray <tbray@textuality.com>
Date: Tue, 29 Sep 2015 21:41:47 -0700
Message-ID: <CAHBU6ivS1vURDQny9F6rYbAheMnxNEm-RLf15ACyE06cTC3EmQ@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="047d7bdc165e85e2110520ef8dab"
Received-SPF: none client-ip=209.85.213.173; envelope-from=tbray@textuality.com; helo=mail-ig0-f173.google.com
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: AWL=-0.613, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1Zh9Dt-0001qS-AX 5a9b5b168fca4b6f81a700a5dc87f773
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/CAHBU6ivS1vURDQny9F6rYbAheMnxNEm-RLf15ACyE06cTC3EmQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30287
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>

I’ll leave most of your points for others, but did want to provide
background on the specific phrase “legal demand”.  The earliest drafts said
something else, it may have actually been “legal requirement”.  At the time
I was a Google employee and consulted with a Google attorney who has
expertise in this area.  She explained that it would be wise to avoid any
phrases that suggested acknowledging the demand was justified or
legitimate, as this could be prejudicial should it come to litigation.
She recommended the use of “legal demand”, because this is just a statement
of a fact: Someone made a demand, and we decided to block access.  Thus,
the last few drafts have been careful to stick with that phrase.

On Tue, Sep 29, 2015 at 9:10 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

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


-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)