Change:
This borrows some of the spin off suggestions made during the discussion on . It does not address the issue itself. See that issue for next steps.
There may be cases (imagine new capsule types) where somthing went wrong but none of the existing codes are appropriate. Signalling NO_ERROR is not appropriate and may be misleading.
Close context capsules carry two items of information about the reason for closing: close codes and close details. In my mind, the close code is meant for software (if you receive this close code instead of that one, the implementation will behave differently) whereas the close details are for humans trying to debug things. So when we're thinking of adding a new close code (as opposed to sending more prose in close details), it begs the question: how would software treat GENERALERROR differently from NOERROR?
good question! We should probably try to capture the ethos of these error codes so everyone has the same expectation. For instance HTTP/3 says from HTTP status codes which indicate error conditions. Stream errors indicate that the sender did not transfer or consume the full request or response, while HTTP status codes indicate the result of a request that was successfully received. Is a close code more like a HTTP status code or a stream error code? It feels like the latter, so to use your examples, when thinking about retry registration, it sounds like we have categories where it is safe to retry registration (NOERROR), most definitely not allowed to retry (UNKNOWNFORMAT, DENIED), maybe retry (RESOURCELIMIT). So I guess a GENERALERROR type would fit into a maybe retry bucket. And if some new use of capsules requires "don't retry" where the existing codes aren't suited, they really should define a new code. Alternatively, we seem to just be reinventing HTTP status codes - so we could, y'know, just use that value range here :laughing:
I agree writing some text about the ethos and intended use of closes codes is a good idea. Perhaps something like: Close codes are intended to allow implementations to react differently when they receive them - for example, some close codes require the receiver to not open another context under certain conditions. Extensions to this mechanism MAY define new close codes if they wish to have receivers react differently. I don't think NOERROR is in the "safe to retry" category, because unknown codes are meant to be treated as NOERROR. Perhaps we merge NOERROR and GENERALERROR and rename the result UNKNOWN_ERROR?
How about we spin off "ethos and intention" to a new ticket? Ah good point. I'm all for bikeshedding a name - how about MAYBE_ERROR? I realise that the current definition is slightly ambiguous as to whether the `Close Details" field would be populated or not.
Sure! I prefer UNKNOWNERROR to MAYBEERROR, but I don't care too much. Agreed. Perhaps something like: NOERROR: This indicates that the registration was closed without any action specified for the receiver. I'm not loving that sentence, but my intent was to convey that close codes exist to carry some action or requirement of the receiver, and NOERROR carries no such action or requirement.
I think can handle the ethos stuff, I don't think we need to bother with an open and shut issue but if you do that's ok. That leaves the remaining question about name. I think with the new text it becomes clearer that the "NOERROR" is really just "CLOSEDWITHNOACTION"
I like . Beyond that, I don't much care about the name. Slight preference for NOERROR but I'm OK with CLOSEDWITHNOACTION
I'm happy without another error code right now. So how about we close this ticket and spin off just a naming bikeshed issue?
Sounds good, closing this one. I'll let you open the naming issue :)
Approved modulo a typo

Discussion:
The context ID to close. The close code allows an endpoint to provide additional <del> information as to why a datagram context was closed.  The codes are defined in close-codes. </del> <ins> information as to why a datagram context was closed. close-codes defines a set of codes, the circumstances under which an implementation sends them, and how receivers react. </ins> This is meant for debugging purposes.  It consists of a human- readable string encoded in UTF-8.

4.4.3.1. <ins> Close codes are intended to allow implementations to react differently when they receive them - for example, some close codes require the receiver to not open another context under certain conditions. </ins> This specification defines the close codes below.  Their numeric <del> values are in iana-close-codes. </del> <ins> values are in iana-close-codes.  Extensions to this mechanism MAY define new close codes and they SHOULD state how receivers react to them. </ins> <del> This indicates that the registration was closed without any additional information. </del> <ins> This indicates that a context was closed without any action specified for the receiver. </ins> This indicates that the sender does not know how to interpret the datagram format type associated with this context.  The endpoint