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

Mark Nottingham <> Tue, 13 October 2015 00:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 67B911B2E50 for <>; Mon, 12 Oct 2015 17:44:24 -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 e22kM7QaMgLP for <>; Mon, 12 Oct 2015 17:44:22 -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 76ADF1B2E4E for <>; Mon, 12 Oct 2015 17:44:22 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZlnfA-0005SL-VT for; Tue, 13 Oct 2015 00:41:57 +0000
Resent-Date: Tue, 13 Oct 2015 00:41:56 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1Zlnf7-0005RV-6R for; Tue, 13 Oct 2015 00:41:53 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1Zlnf3-0000WN-3D for; Tue, 13 Oct 2015 00:41:52 +0000
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 2049822E261; Mon, 12 Oct 2015 20:41:24 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Tue, 13 Oct 2015 11:41:22 +1100
Cc: HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Alex Rousskov <>
X-Mailer: Apple Mail (2.2104)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.3
X-W3C-Hub-Spam-Report: AWL=1.323, 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: 1Zlnf3-0000WN-3D 6720348267c530311963f186e15a0a21
Subject: Re: Working Group Last Call for draft-ietf-httpbis-legally-restricted-status
Archived-At: <>
X-Mailing-List: <> archive/latest/30354
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Alex,

> On 2 Oct 2015, at 4:17 am, Alex Rousskov <> wrote:
> On 09/30/2015 11:33 PM, Mark Nottingham wrote:
>>> On 1 Oct 2015, at 2:33 pm, Alex Rousskov wrote:
>>> On 09/30/2015 06:59 PM, Mark Nottingham wrote:
>>>> 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.
>>> 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:
> Your use case was, and I quote, "making it possible to track censorship
> and similar situations". The use case in the draft is a lot narrower. I
> was talking about your use case (which I support), not the one in the
> draft (which I find unnecessarily too narrow).
>> 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, 
> Yes, I understand that 451 *as proposed* would disqualify the use case
> in the example. We need to find a balance between:
>  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.

>> not
>> act as a barometer of what standards (religious, parental, whatever)
>> are self-imposed by publishers around the world.
> I agree that it makes sense to distinguish self-imposed and forced
> censorship, and, given the apparent consensus around 451, we can focus
> on the latter. My self-imposed censorship example was deficient in that
> area. Sorry.
> 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?

> or should we allow them to use 451 because their use case (i.e.,
> "something outside of my control is forcing me to block this") is common
> and well-defined? I think we should.


>> RFCs need to be sufficiently well-described to be interoperable; they
>> don't need to defend their existence like an academic paper would.
> The interoperability problems often stem from poor definitions. Your
> "publishers and potential consumers" think they know what the extension
> means because they have defined it or they trust your interpretation.
> Those who add support for the extension in the future either need a
> definition or at least an explicit disclosure that the term is left
> undefined on purpose, allowing the sender and the recipient interpret it
> differently.

It does seem reasonable to note that the interpretation of the status code depends upon the context of the server generating it, and that the server SHOULD include as much detail as they can in the body.

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.

Mark Nottingham