W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

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

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 1 Oct 2015 15:33:24 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <805EFF40-ECA6-4A67-AE3E-F165079F388C@mnot.net>
To: Alex Rousskov <rousskov@measurement-factory.com>
Personal opinions below.

> On 1 Oct 2015, at 2:33 pm, Alex Rousskov <rousskov@measurement-factory.com> wrote:
> On 09/30/2015 06:59 PM, Mark Nottingham wrote:
>>> On 1 Oct 2015, at 10:37 am, Alex Rousskov wrote:
>>> 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??
>> 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.
> The end result (i.e., the draft) does not reflect the goal you talk
> about above. The proposed status code does not define a "Blocked By
> Sensors or Similar" status code. It defines an "Unavailable For Legal
> Reasons" status code (also documented as a "consequence of legal demands").
> 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:

This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when a server operator has a received a legal demand to deny access to a resource.

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, not act as a barometer of what standards (religious, parental, whatever) are self-imposed by publishers around the world.

>> For example, Chilling Effects <https://www.chillingeffects.org/> can
>> spider the Web for such content when such a status code is defined.
>> There's already been pre-standardisation deployment of the status
>> code by some sites, and interest from others.
> Removing the words "legal" and "demand" from the draft will not break
> Chilling Effects. The technical mechanism to report the HTTP agent
> responsible for "blocking" the resource remains the same. The status
> code remains the same.

That would introduce a lot of noise and make the status code nearly useless. 

>>> 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.
>> We've already had discussion along those lines too; see
>> <https://github.com/httpwg/http-extensions/issues/80>.
> Wrong link? Issue 80 is about "origin vs intermediary" distinction. I am
> talking about "legal reasons vs all other blocking reasons" distinction,
> and I am _not_ saying there should be another code added. One code is
> more than enough!
> Said that, if this draft is approved in its too-narrow form, then I sure
> hope somebody submits these drafts:
> * Code 452 (Unavailable For Political Reasons)
> * Code 453 (Unavailable For Religious Reasons)
> * Code 454 (Unavailable For Parental Reasons)
> * Code 455 (Unavailable For Military Reasons)
> * ...
>> I'm very concerned about trying to over-genericise this mechanism;
>> let's not boil an ocean we don't have to.
> The mechanism is already general enough. It is the wording describing
> the applicability of the mechanism that is too restrictive.
>>> Alternatively, some serious effort should be made to define "legal demands"
>> Defining the phrase precisely on a global scale isn't realistic. What do you have in mind?
> I suggest removing that phrase. IMO, that should be done for many
> reasons, including the fact(?) that it is unrealistic to define its
> meaning precisely enough. However, if folks disagree, then _they_ should
> make the effort to define what they use. This is supposed to be a part
> of a protocol specification. Definitions of key terms in protocol specs
> ought to be precise.

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

>>> and explain why they deserve a special HTTP status code.
>> That discussion needs to happen in the WG, not *necessarily* in the draft. 
> The result of that discussion (i.e., the final/polished explanation)
> should be in the draft. If a protocol extension draft does not justify
> the need for the extension (i.e., why the existing mechanisms are
> insufficient), then something went wrong regardless of the preceding WG
> discussion.

RFCs need to be sufficiently well-described to be interoperable; they don't need to defend their existence like an academic paper would.


Mark Nottingham   https://www.mnot.net/
Received on Thursday, 1 October 2015 05:33:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:39 UTC