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

Alex Rousskov <> Tue, 13 October 2015 04:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9F0871B3059 for <>; Mon, 12 Oct 2015 21:25:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ceLUj6Law3_T for <>; Mon, 12 Oct 2015 21:25:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0CE081B3054 for <>; Mon, 12 Oct 2015 21:25:06 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1Zlr5h-0006SJ-77 for; Tue, 13 Oct 2015 04:21:33 +0000
Resent-Date: Tue, 13 Oct 2015 04:21:33 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1Zlr5d-0006PA-1f for; Tue, 13 Oct 2015 04:21:29 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1Zlr5b-0002rt-76 for; Tue, 13 Oct 2015 04:21:28 +0000
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1067DE299; Tue, 13 Oct 2015 04:21:04 +0000 (UTC)
To: Mark Nottingham <>
References: <> <> <> <> <> <> <>
Cc: HTTP Working Group <>
From: Alex Rousskov <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Mon, 12 Oct 2015 22:20:56 -0600
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
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: 1Zlr5b-0002rt-76 3e228699bb4865319830b6ad5009ec2d
Subject: Re: Working Group Last Call for draft-ietf-httpbis-legally-restricted-status
Archived-At: <>
X-Mailing-List: <> archive/latest/30355
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 10/12/2015 06:41 PM, Mark Nottingham wrote:
>> On 2 Oct 2015, at 4:17 am, Alex Rousskov wrote:
>>  1. Marking all censorship cases.
>>  2. Marking all censorship cases imposed by any external force.
>>  3. Marking censorship forced by an undefined term "legal demand".
>>  4. Marking censorship forced by some well-defined obstacle,
>>     one out of many such obstacles.
>> Needless to say, finding the right scope for the new status code is a
>> judgement call. IMHO, #1 and/or #2 deserve a dedicated HTTP status code
>> while #3 and #4 do not (for different reasons).

> I'm not hearing anyone else take up that position, and I'd note that
> we've already demonstrated consensus to adopt the document based upon
> #3.

Yes, I acknowledge that during the WG Last Call, you should interpret
the lack of discussion about this issue as an "everything is fine"
feedback. I have nothing more of substance to add and rest my case. You
should stop reading now.

[ As for adoption, FWIW, I would have supported the adoption, but
suggested that the too-narrow scope should be adjusted. Perhaps that
would have been wrong, and you are not overreaching with the "adoption
implies agreement on scope" argument. ]

>> An *outside force* other than a "legal demand" may compel me to block a
>> resource. I speculate that most "blocked by external forces" content in
>> the world is blocked by external forces other than a specific "legal
>> demand". Should those who are forced to block by an external source
>> * block silently;
>> * violate the draft and misuse 451;
>> * reserve another status code for their broader(!) use case;

> Surely that would be 403? Would it help to point this fallback out explicitly?

No, 403 does not imply that I am being forced to block something by a
3rd party. 403 just "blocks silently", not addressing the use cases #1
and #2 in the numbered list at the top of this email.

> We already have:

> """ Responses using this status code SHOULD include an explanation,
> in the response body, of the details of the legal demand: the party
> making it, the applicable legislation or regulation, and what classes
> of person and resource it applies to. """

> So perhaps a sentence or two before that noting why this is -- i.e.
> that the legal context varies.

I do not think it would help unless you are willing to say that the
"legal context" varies so much that it may perfectly apply to blocking
reasons other than the undefined areas of "legal obstacles" and "legal
demands" :-).