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

Mark Nottingham <> Mon, 19 October 2015 05:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6FD291A1B96 for <>; Sun, 18 Oct 2015 22:44:29 -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 UPTlLLsk40UV for <>; Sun, 18 Oct 2015 22:44:28 -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 E0C9C1A1B7B for <>; Sun, 18 Oct 2015 22:44:27 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1Zo3CK-0004N8-Ke for; Mon, 19 Oct 2015 05:41:28 +0000
Resent-Date: Mon, 19 Oct 2015 05:41:28 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1Zo3CH-0004MQ-VS for; Mon, 19 Oct 2015 05:41:25 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1Zo3CF-00047W-E3 for; Mon, 19 Oct 2015 05:41:25 +0000
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 891CD22E1F4; Mon, 19 Oct 2015 01:40:58 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Mon, 19 Oct 2015 16:40:55 +1100
Cc: HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Krzysztof Jurewicz <>
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.284, 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: 1Zo3CF-00047W-E3 94af03751376581848db7e0c5e40b924
Subject: Re: Working Group Last Call for draft-ietf-httpbis-legally-restricted-status
Archived-At: <>
X-Mailing-List: <> archive/latest/30379
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Krzysztof,

On 17 Oct 2015, at 7:59 pm, Krzysztof Jurewicz <> wrote:
> On September the 18th I argued that this status code should be either split into two or moved to the 5xx range ( ). Since no objections have been raised, I guess that this proposition has been either considered as legitimate or overlooked?

Sorry, I meant to respond to that earlier.

It isn't a good fit as a 5xx, because that implies that the fault is on the server side, and the client can reasonably retry the request in hopes of that being corrected. That doesn't align well with the semantics we've defined. That's one reason why 404 and 410 are 4xx codes, not 5xx.

4xx is a better fit, because it tells the client they need to change *something* about the request if they want to retry it (and that can include changing the legal jurisdiction they're in). It doesn't mean that a retried request will necessarily succeed, though (see again 404 and 410).

Regarding splitting it into separate status codes -- keep in mind that the point of status codes is to allow generic, automated software to take advantage of the semantics. The responses you give as examples don't enable that (without a lot more protocol extension work). Even then, I'm not seeing how making this distinction at the status code level is important -- if there's an automated way to recover from the condition, that can be denoted by the protocol extensions that enable it, not the status code.

Lastly, if we start doubling up on status codes like this (e.g., one for recoverable, one for unrecoverable), we're going to run out quickly!


Mark Nottingham