Re: Introduction and internet draft proposal for HTTP response 420 Requester Impaired

Hey Richard,

First off, I like this idea!

I have some concerns that it might be seen as an April Fool's joke (as was
its original genesis!) such that people won't take it seriously.

A couple of questions:

1. From a purely technical POV, how does this differ from 400 Bad Request,
which is currently used for this sort of thing - clearly it's up to the
server to make the decision that the client is 'impaired' rather than just
sending an invalid request, but how does it do that? Different servers
might consider different sorts of requests as invalid based on the request
content ("Does this sound like the request someone who's stoned out of
their gourd might make?") but that's a per-server decision, so we have a
lack of standardization.

2. I assume that the point of this is to signal to the client that it is
not making sense, and should maybe stop asking questions until it's no
longer impaired. But in Section 4 (Security Considerations) you say "If the
impaired requesters are identifiable because they have been authenticated,
their requests SHOULD be denied until they have been determined not to be
impaired.". How would a server determine that a client is no longer
impaired unless it starts accepting requests from it again, to gauge its
impairment (or lack thereof)?

Rory

On Mon, Dec 11, 2023 at 4:00 AM Richard Roda <richard_roda@hotmail.com>
wrote:

> My name is Richard Roda.  I am a Sr. Developer at USANA
> <https://www.usana.com/ux/dotcom/enu-US/home>.  I have been developing
> using HTTP long enough to remember transitioning from 1.0 to 1.1.  My most
> relevant vendor certification is Security+ ce
> <https://www.credly.com/badges/931df564-c412-4bca-bef5-f75e3a49c106/linked_in_profile>.
> My details may be found on my LinkedIn page
> <https://www.linkedin.com/in/richardroda/>.  I am proposing an HTTP
> status code for 420 as a Requester Impaired code.  The original idea for
> this was an April Fool's RFC.  420 is an available client error response
> code, and the number 420 is associated with marijuana use.   However, as I
> was writing and drafting it occurred to me that this is a legitimate need.
> With AI systems being given more operational autonomy and the fact that
> Large Language Models (LLMs) can "hallucinate" responses, non-human as
> well as human requesters can be impaired.  If impaired requestors are
> attached to something like remote-operated heavy equipment the results
> could be catastrophic.  Dedicating an HTTP response code to this will allow
> for better visibility and remediation of impaired requesters.
>
> Any feedback on this would be appreciated.  I am also on the #httpbiz
> stream on Zulip.  I might not respond immediately to messages because of my
> day job.
>
> https://datatracker.ietf.org/doc/draft-richardroda-420requesterimpaired/
> An HTTP Status Code to Report Requester Impairment
> <https://datatracker.ietf.org/doc/draft-richardroda-420requesterimpaired/>
> This document specifies a Hypertext Transfer Protocol (HTTP) status code
> for use when an operation or resource is denied due to requester impairment.
> datatracker.ietf.org
> **
>
>

-- 
Rory Hewitt

https://www.linkedin.com/in/roryhewitt