Dear ANIMA-WG In the weekly BRSKI calls we did discuss on and off the issue of limited HTTP error codes returned when calling BRSKI endpoint URIs. Especially the point that it's difficult to map all error conditions to unique HTTP status codes.
So, i would hereby like to suggest that we revisit error codes returned by new BRSKI work to follow what the IETF has specified and follow what seems to be like a very simple way to apply that method, as found in ACME (which is kinda related to our BRSKI work). -- Reference: RFC7807 defines how to signal problem details for HTTP APIs. It was superceeded by RFC9457, but of course, there are more RFC already using/referencing RFC7807 than RFC9457. --- Simple example: ACME, RFC9115 seems like a good, minimum complexity way to apply this problem report method. It specifies for example: ... MUST return an error response with status code 403 (Forbidden), providing a problem document [RFC7807] with type "urn:ietf:params:acme:error:unknownDelegation". And then there is an IANA section asking to register this "unknownDelegation". Aka: minimum text work. --- Longer example reference: Of course, one of our RFC, maybe rfc8366bis needs to ask for creation of a registry for "urn:ietf:params:brski", and the error registry, but that's easily written, especially when it follows the ACME approach. RFC8555 , the main ACME does of course introduce a long list of error codes, They can also all be found in the registry: https://www.iana.org/assignments/acme/acme.xhtml#acme-error-types --- Example of how to apply: Lets take an example with BRSKI-PRM, which currently specifies: 400 Bad Request: if the pledge detected an error in the format of the request or detected invalid JSON even though the PER media type was set to application/json. Instead of just returning 400, we could change this to MUST/SHOULD also indicate an appropriate problem report. --- How to apply to BRSKI: Technically, the eror transaction would look like this GET /.well-known/brski/tpvr HTTP/1.1 Host: brski-registrar.example.com Content-Type: application/json Accept: application/json, application/problem+json { ... existing BRSKI PRM PVR data } Aka: in the request, the initiator would indicate that it supports problem+json HTTP/1.1 400 Bad Request Content-Type: application/problem+json Content-Language: en { "type": "urn:ietf:params:brski:error:ErrorNameNNN", "title": "...", "detail": "...", "blablabla": "...", } In the reply, we would be able to have a combination of specific ErrorNameNNN and other fields. I think the logic of applying ErrorNameNNN and the other fields would be based on the following considerations: Whenever an initiator should or could have two different reactions to two different errors, such as different retries, then there MUST be two different ErrorNameNNN. Aka: automated reactions must be possible by only examining the ErrorNameNNN. Whenever it is easy to distinguish two different Errors by name, then we should also introduce those different ErrorNameNNN. The list of ACME error codes might be a good help. Whenever there must be a human in the loop anyhow to resolve the issue, it is sufficient to describe the problem differences in the "detail" and potentially other fields, which can be custom, such as indicated via "blablabla". So, for the example of this "Bad Request", the problem of course is that some plege or agent developer (or even worse customer/operator) needs to figure out what the registrar did not like. --- Bad ? Example what to do: What i have seen in other protocols, and what is quite ugly, but the minimum, is, translated to this registrar example, that the developer of the code that is parsing the request message/data-structure simply emits a different numeric error code on every code line where an error is encountered. This would translate to: { "type": "urn:ietf:params:brski:error:CrypticVendorError", "detail": "ExampleCorpMegaRegistrar, v0.97b, code: 0x10057" } Aka: some crap where the operator needs to call support of that Registrar, but at least then it just needs to tell the software version v0.97b and the code 0x10057 and then 3rd level support may be able to tell the operator whats "wrong" on the othrer side (agent/pledge). But - this is least amount of spec effort on our side (as in: we don't specify anything beyond CrypticVendorError. And of course, this is not what ACME did, they tried to break down the errors more by analyzing what errors could exist and come up with better Error codes for them. Which of course is more work. Cheers toerless ============== https://www.rfc-editor.org/rfc/rfc8075.txt section 5.5.1 -- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
