4 ms·

This is a great example of a bad RFC: the description fails to motivate the necessity of establishing this concept of "rejected due to client impairment" let al

This is a great example of a bad RFC: the description fails to motivate the necessity of establishing this concept of "rejected due to client impairment" let alone even define what "impairment" means in this context. Instead of where paragraphs explaining those would be, it instead talks right away about how "oh this applies to AI too, and by the way a proxy server is allowed to do this" - very small and irrelevant details in comparison!

rablackburn 3y ago
You appear to have skipped the introduction (which comes before the statement about this being useful for non-human operators like bots) where it says: >> This request code may be used to provide visibility in cases where one or more valid requests create a dangerous situation, there is a pattern of erratic requests with the potential for danger, or the requester is otherwise detected as impaired. Why this is considered necessary is explained in the next sentence: >> Network-controlled devices are being used for beneficial but potentially dangerous activities such as construction and remote surgery. Identifying requester impairment is important for both accurately assessing the risk a given requester presents and preventing damage caused by a high-risk requester.
- akersten 3y ago
  I did read the intro, it similarly fails to define what does "danger" or "impaired" mean from the perspective of a webserver and why it would matter as part of the protocol. There's just nothing here that makes me think "this seems like something HTTP should be concerned about": > create a dangerous situation, there is a pattern of erratic requests with the potential for danger, or the requester is otherwise detected as impaired. "The risk a given requester represents" I mean... this is just so nebulous. Is this a special status code for webserver running in a breathalyzer? I'm convinced this is some kind of post-AI satire. To be clear I understand the need for specialized devices to prevent misuse and user error. But the HTTP protocol is like, the worst possible choice for where to build that out. This is a layer 0 concern, not layer 7. Who knows though. Maybe in a decade when Alcohol-as-a-Service startups are delivering fine liquor directly via the built-in straw of some next-gen Oculus headset, my virtual bartender will leverage this status when they cut me off.
  - salawat 3y ago
    > create a dangerous situation, there is a pattern of erratic requests with the potential for danger, or the requester is otherwise detected as impaired Eh... Seems awful indirect for an HTTP standard defined status code. Like what is it trying to say, and who could do anything about it? Sounds like wrong layer to me without more concrete details surrounding an implementation utilizing it. .
- flir 3y ago
  > such as construction and remote surgery I know there's some fuzziness between the layers, but shouldn't that be squarely in the application layer?

rablackburn 3y ago

You appear to have skipped the introduction (which comes before the statement about this being useful for non-human operators like bots) where it says: >> This request code may be used to provide visibility in cases where one or more valid requests create a dangerous situation, there is a pattern of erratic requests with the potential for danger, or the requester is otherwise detected as impaired. Why this is considered necessary is explained in the next sentence: >> Network-controlled devices are being used for beneficial but potentially dangerous activities such as construction and remote surgery. Identifying requester impairment is important for both accurately assessing the risk a given requester presents and preventing damage caused by a high-risk requester.

akersten 3y ago
I did read the intro, it similarly fails to define what does "danger" or "impaired" mean from the perspective of a webserver and why it would matter as part of the protocol. There's just nothing here that makes me think "this seems like something HTTP should be concerned about": > create a dangerous situation, there is a pattern of erratic requests with the potential for danger, or the requester is otherwise detected as impaired. "The risk a given requester represents" I mean... this is just so nebulous. Is this a special status code for webserver running in a breathalyzer? I'm convinced this is some kind of post-AI satire. To be clear I understand the need for specialized devices to prevent misuse and user error. But the HTTP protocol is like, the worst possible choice for where to build that out. This is a layer 0 concern, not layer 7. Who knows though. Maybe in a decade when Alcohol-as-a-Service startups are delivering fine liquor directly via the built-in straw of some next-gen Oculus headset, my virtual bartender will leverage this status when they cut me off.
- salawat 3y ago
  > create a dangerous situation, there is a pattern of erratic requests with the potential for danger, or the requester is otherwise detected as impaired Eh... Seems awful indirect for an HTTP standard defined status code. Like what is it trying to say, and who could do anything about it? Sounds like wrong layer to me without more concrete details surrounding an implementation utilizing it. .
flir 3y ago
> such as construction and remote surgery I know there's some fuzziness between the layers, but shouldn't that be squarely in the application layer?