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

[Mark Nottingham <[e-mail]>]

Personal opinions below.

> On 1 Oct 2015, at 2:33 pm, Alex Rousskov <[e-mail]> 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.

Cheers,


--
Mark Nottingham   https://www.mnot.net/