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

Hi Mark,
 thanks for taking the time to review this, based on your & Amos' [1] feedback, I've submitted a new draft:

Regarding this question:

> 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?

Yes, we include information in both the response header and the response body, we have found it to be largely ineffective. Our experience is that tools and humans see 500, think 'I know what that means...' and proceed to filing a problem report/complaining to the wrong party far too often. Also the extra information in the response header and body may end up being lost in the journey back to the client/monitoring tools. For example the access log will only show the status code, custom error pages may hide extra information in the response body. 

https://datatracker.ietf.org/doc/draft-divilly-user-defined-resource-error/ <https://datatracker.ietf.org/doc/draft-divilly-user-defined-resource-error/>

Changes in this draft:

- Use 5NN instead of 555 through out
- Remove 555 from the draft name
- Explain use of 5NN: https://tools.ietf.org/html/draft-divilly-user-defined-resource-error-00#section-1 <https://tools.ietf.org/html/draft-divilly-user-defined-resource-error-00#section-1>
- Explain why 500 Internal Server Error does not suffice: https://tools.ietf.org/html/draft-divilly-user-defined-resource-error-00#section-2.1 <https://tools.ietf.org/html/draft-divilly-user-defined-resource-error-00#section-2.1>. TLDR, folks only see the status code in the response, they ignore anything else is my experience
- Do not indicate that the draft seeks to update RFC 7231

Regarding the following point:

> 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.


I see this proposal as enhancing the interface rather than clouding it with implementation details. When an error occurs, then very often some follow up action needs to be taken. Often that action is to file a problem report or examine some logs. The purpose of this status code is to help inform the client with whom to file the problem report or which logs to examine.

This proposal provides a clear classification for tools and humans, that can inform their decision about to how to deal with the error condition.

This falls outside what HTTP does or should specify. I see this proposal as a tiny layer atop the HTTP protocol to help with this pain point. 

I still feel this a pretty specialised use-case at this time and there likely is not enough consensus to standardise this approach, which is why I filed it as an informational draft. My hope with submitting the original draft was that others with similar requirements might come across the draft and choose to harmonise on using 555 as the status code for this condition, and that over time a consensus might build that it would be appropriate to try get it standardised.

I understand now that this approach is not in line with RFC 7231, so I've amended the draft to avoid preferring (squatting on) any particular status code.

Regards,
Colm

[1]: https://lists.w3.org/Archives/Public/ietf-http-wg/2020JanMar/0244.html <https://lists.w3.org/Archives/Public/ietf-http-wg/2020JanMar/0244.html>

> On 26 Mar 2020, at 03:49, Mark Nottingham <mnot@mnot.net> wrote:
> 
> Hi Colm,
> 
> For reference, the guidance for new status codes is here:
>  https://httpwg.org/specs/rfc7231.html#considerations.for.new.status.codes <https://httpwg.org/specs/rfc7231.html#considerations.for.new.status.codes>
> 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?
> 
> Cheers,
> 
> 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.
> 
>