Draft: draft-ietf-masque-h3-datagram

Commentary: 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  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 " do n't retry " where the existing codes are n'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 do n'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 MAYBEERROR ? 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 do n'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 do n'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 do n'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
The close code allows an endpoint to provide additional
information as to why a datagram context was closed.  The codes
are defined in close-codes.
The close code allows an endpoint to provide additional
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.
This specification defines the close codes below.  Their numeric
values are in iana-close-codes.
This indicates that the registration was closed without any
additional information.
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.
This specification defines the close codes below.  Their numeric
values are in iana-close-codes.  Extensions to this mechanism MAY
define new close codes and they SHOULD state how receivers react to
them.
This indicates that a context was closed without any action
specified for the receiver.