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

Alex Rousskov <> Thu, 01 October 2015 00:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4CC0D1A7D81 for <>; Wed, 30 Sep 2015 17:41:21 -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 PlRp_J5GyPwV for <>; Wed, 30 Sep 2015 17:41:19 -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 8AD541A7113 for <>; Wed, 30 Sep 2015 17:41:19 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZhRss-0003YL-R2 for; Thu, 01 Oct 2015 00:38:06 +0000
Resent-Date: Thu, 01 Oct 2015 00:38:06 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZhRso-0003XU-Gf for; Thu, 01 Oct 2015 00:38:02 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1ZhRsm-000574-Jp for; Thu, 01 Oct 2015 00:38:02 +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 5B05FE290; Thu, 1 Oct 2015 00:37:35 +0000 (UTC)
To: HTTP Working Group <>
References: <>
From: Alex Rousskov <>
X-Enigmail-Draft-Status: N1110
Cc: Mark Nottingham <>
Message-ID: <>
Date: Wed, 30 Sep 2015 18:37:09 -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: 1ZhRsm-000574-Jp 324a313f0790e4745f874925ea675e34
Subject: Re: Working Group Last Call for draft-ietf-httpbis-legally-restricted-status
Archived-At: <>
X-Mailing-List: <> archive/latest/30292
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 09/29/2015 09:29 PM, Mark Nottingham wrote:
> So, this is the announcement of WGLC for: 

>   [RFC4924] discusses the forces working against transparent operation
>    of the Internet; these clearly include legal interventions to
>    restrict access to content.  As that document notes, and as Section 4
>    of [RFC4084] states, such restrictions should be made explicit.

The above paragraph may be interpreted as a skilful attempt to justify
dedicating a special status code to denials based on "legal demands".
Neither of the two RFCs mentioned in the quoted paragraph require or
even suggest that "legal demands" require such a special treatment.

Those RFCs say that restrictions should be disclosed. Using that to
justify a new HTTP status code dedicated to a particular type of a
restriction is quite a stretch IMHO. HTTP already provides means to
satisfy those two RFCs by allowing error responses with arbitrary
content that may include all sorts of disclosures.

Please note that the above is not an argument against adding a special
status code for "legal demand" denials. It is an argument against using
those two innocent RFCs as a justification for doing so. I think that
paragraph should be deleted.

If that paragraph is removed, the only justification offered for the new
status code is:

> This status code can be used to provide transparency in circumstances
> where issues of law or public policy affect server operations.  This
> transparency may be beneficial both to these operators and to end
> users.

Since the existing HTTP error mechanisms can already be used to do all
of the above, that justification is insufficient at best.

I failed to find any other explanation why a new code dedicated to
"blocked by legal demands" responses is needed.

Moreover, the term "legal demand" is itself undefined. Could it mean a
verbal demand from XYZ legal department? A written request by a law
enforcement officer lacking jurisdiction? Does responding with this
status code constitute the responder's agreement that the demand to
block was legal??

IMHO, the draft should be revised to remove the words "legal" and
"demand". It should specify a generic mechanism to point to the blocking
entity (i.e., Section 4). Such a generic mechanism can then be used by
those who block because of "legal demands" (using their own definition
of that term) and by those who block for other reasons.

Alternatively, some serious effort should be made to define "legal
demands" and explain why they deserve a special HTTP status code.

Thank you,