Re: New Version Notification for draft-divilly-status-555-00.txt

Mark Nottingham <> Thu, 26 March 2020 03:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D2703A098A for <>; Wed, 25 Mar 2020 20:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.214
X-Spam-Status: No, score=-4.214 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-1.463, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=KqNOx9zg; dkim=pass (2048-bit key) header.b=oecCA6RK
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fMGl9FCr91H8 for <>; Wed, 25 Mar 2020 20:53:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BB9E3A096C for <>; Wed, 25 Mar 2020 20:53:35 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jHJX4-0008BX-Rn for; Thu, 26 Mar 2020 03:50:14 +0000
Resent-Date: Thu, 26 Mar 2020 03:50:14 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jHJX2-0008Am-Nd for; Thu, 26 Mar 2020 03:50:12 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jHJWz-0005bG-P2 for; Thu, 26 Mar 2020 03:50:12 +0000
Received: from compute4.internal (compute4.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 4E7F552B; Wed, 25 Mar 2020 23:49:55 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute4.internal (MEProxy); Wed, 25 Mar 2020 23:49:55 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=9 0IpMu+jnfehdCNeJrnKNYtdNtXkfssbeJeXFXixc9I=; b=KqNOx9zgPvhWBo8ax gwUIbJg9PBzcgg/1k9bCN2Mb5PDN50Vp86AVfViUiXOlH/Fng+nHQ5/74xHrcThz OtRcrpET6i7x+hBMCMC0UQXUR3YDl3BekfMwoaYk8uDXRxtKA1/5YUR5XePcQbca NDdg5HpZphQ3owJ/MIO7LZtEmaYnOvoL/yLGSLRjT0hDCqP0O+F/Ow4LobuvfQxi k7iHusKilM1UDvmkm3KVhQsQ2X7JlpJ2W61M01KK4nlo2cfJcQ0syA3w7KyudRnj /STTG3T5X++Gzpl64mbIxALvGxkNTAr75Tg4Auy3e0K0nPvvm+nzKk+4sXIaRLC4 pRmVQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=90IpMu+jnfehdCNeJrnKNYtdNtXkfssbeJeXFXixc 9I=; b=oecCA6RKce/j7BbK82jTzV81pGj4dai3zTikKmEn2NpRLj0CUP1916SpL 3FW2SuRdhhlek1p42mFZQNJnrgAa8dvjfmYGNuJ9RS6yIJunO+qfi0Dzz6eG7gW4 gLNJ/izQPeaT5AmFE/aQftjmyJSrJVTK7CjOptjIo7+q5WZzX3fX1GHodHmIuI1m ObvaBj841roMagxNowdmxOJ+lBPOB9O4BAFAE946VrmP1hs4AoEE1ekFxc14Bidp zqRFjqBVj+ogf+Sf2rRvoGzdyG6THxU5YYwuU2cZ/XLJmuaxNOPps9Q7vWrzqXds xXeVGkswp1p/55qPDlyjxHCiai6QA==
X-ME-Sender: <xms:YSZ8Xg1ThoA4LL--aE-SckTqTUsDhgitJ42OUjBuSL62P8BVAjOhBw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehhedgieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh ephhhtthhpfihgrdhorhhgpdhorhgrtghlvgdrtghomhdpihgvthhfrdhorhhgpdhmnhho thdrnhgvthenucfkphepudduledrudejrdduheekrddvhedunecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:YSZ8XgUUykwizoZghxNq5SJT0UdzEjBbsbe1JE-vjoYx9FZ5FAplAw> <xmx:YSZ8XqmjNuM8Hoga4b4uYOlRCaACl8VcOUkO9zC_FE8OSsCh2mHCSg> <xmx:YSZ8XiB7YndzIU3t1WdwcKr02ROXBUx8cy4KIGNWATwI-PBrEDHZxg> <xmx:YiZ8XkDL_n8gtMrjHNwwIr6YXTDwccdDFmRP_-h1AfV8FVbJAK6iyQ>
Received: from (unknown []) by (Postfix) with ESMTPA id EEF3830681DB; Wed, 25 Mar 2020 23:49:51 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
From: Mark Nottingham <>
In-Reply-To: <84C127AC-BA21-4CD8-9F79-8920ADE5BA4C@ORACLE.COM>
Date: Thu, 26 Mar 2020 14:49:49 +1100
Cc: HTTP Working Group <>, Roy Fielding <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <84C127AC-BA21-4CD8-9F79-8920ADE5BA4C@ORACLE.COM>
To: Colm Divilly <>
X-Mailer: Apple Mail (2.3608.
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-9.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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: 1jHJWz-0005bG-P2 e06b81236914bfa37eb5526eb4874393
Subject: Re: New Version Notification for draft-divilly-status-555-00.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/37481
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Colm,

For reference, the guidance for new status codes is here:

I agree this condition is potentially applicable to any resource, but it might fall afoul of another principle that we haven't written down as well -- that HTTP focuses on standardising the interface to the resource, not its implementation details (which this seems to be about). Roy might have some more thoughts here.

More generally, when someone needs to convey more refined information about what caused an error, the advice we give is to put that information in the response body or a response header. Did you consider that approach?


P.S. As an aside - we discourage people from "squatting" on status codes like this because it makes it harder to use them in standards later, and they are a relatively scarce resource. Please don't use it until it has been standardised, and in the future, it's best to make proposals along the lines of "a new 5xx status code" rather than a specific number. Thanks.

> On 25 Mar 2020, at 10:02 am, Colm Divilly <> wrote:
> Hi All,
>  for a product I help develop: Oracle REST Data Services (ORDS) [1], we provide a hosted environment where third party users can dynamically at runtime define their own REST APIs using SQL. Naturally there will be coding and runtime errors in these REST APIs. This creates a challenge for users and operators. When such a resource raises an error the only appropriate HTTP status code to use is 500 Internal Server Error. This causes confusion as it looks like there is something wrong with ORDS, where in fact there is only something wrong with the user supplied SQL. Despite explanatory text to clarify this, operators and users very often miss this distinction, and file support issues against ORDS. Further, automated tools that monitor the access log only see the 500 status code, and thus cannot differentiate between 'real' 500 errors in ORDS itself that need remediation versus 500 errors in the user supplied REST APIs that probably do not need any remediation. If a distinct status code for these kinds of errors appeared in the access log, it makes it immediately clear to both humans and tools that the error condition is caused by a user defined resource.
> We believe assigning a new HTTP status code (we chose 555 just because it is memorable) to clearly identify errors arising in these dynamically defined user REST APIs is the cleanest way to resolve this confusion. TBH not sure if this use-case is common enough to be worth standardising, so have filed this as an 'Informational' draft. Perhaps 'serverless' platforms that have a similar paradigm of third party users publishing programmatic resources to their platforms might also find this approach useful.
> Appreciate any feedback anyone may have on this approach.
> Regards,
> Colm Divilly
> [1]:
>> Begin forwarded message:
>> From:
>> Subject: New Version Notification for draft-divilly-status-555-00.txt
>> Date: 20 March 2020 at 11:35:55 GMT
>> To: "Colm Divilly" <>
>> A new version of I-D, draft-divilly-status-555-00.txt
>> has been successfully submitted by Colm Divilly and posted to the
>> IETF repository.
>> Name:		draft-divilly-status-555
>> Revision:	00
>> Title:		User Defined Resource Error HTTP Status Code
>> Document date:	2020-03-20
>> Group:		Individual Submission
>> Pages:		5
>> URL:  
>> Status:
>> Htmlized:
>> Htmlized:
>> Abstract:
>>   This document specifies an additional HyperText Transfer Protocol
>>   (HTTP) status code to indicate server error conditions arising during
>>   evaluation of user defined resources hosted by the server.
>> Conventions and Terminology
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at
>> The IETF Secretariat

Mark Nottingham