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

Alex Rousskov <> Thu, 01 October 2015 18:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C0BA21B2E3F for <>; Thu, 1 Oct 2015 11:21:36 -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 qNM5x_WQfvX8 for <>; Thu, 1 Oct 2015 11:21:35 -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 0BF5D1B2E76 for <>; Thu, 1 Oct 2015 11:21:33 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZhiQf-0001u6-89 for; Thu, 01 Oct 2015 18:18:05 +0000
Resent-Date: Thu, 01 Oct 2015 18:18:05 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZhiQc-0001tL-JP for; Thu, 01 Oct 2015 18:18:02 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1ZhiQa-000485-1o for; Thu, 01 Oct 2015 18:18:01 +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 3AC2FE290; Thu, 1 Oct 2015 18:17:35 +0000 (UTC)
References: <> <> <> <> <>
Cc: Mark Nottingham <>
From: Alex Rousskov <>
X-Enigmail-Draft-Status: N1110
To: HTTP Working Group <>
Message-ID: <>
Date: Thu, 01 Oct 2015 12:17:08 -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: <>
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: 1ZhiQa-000485-1o 905cd571e0a782a427daefe398a55818
Subject: Re: Working Group Last Call for draft-ietf-httpbis-legally-restricted-status
Archived-At: <>
X-Mailing-List: <> archive/latest/30307
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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

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

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.

> The feedback we overwhelmingly have from publishers and potential
> consumers are that the status code is useful at this granularity.

I do not think IETF should publish _protocols_ with undefined key terms,
even it that makes "publishers and potential consumers" happy. Making
the choir happy is essential but not sufficient, especially when it is a
relatively small choir.

> 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

As for justifying the existence, I hope that this WG and IETF in general
resists blessing RFCs that extend protocol without a good justification
(because there is a cost associated with every extension). In other
words, RFCs do not need this, but RFCs blessed by a WG and IETF probably do.