Hi Toerless, Providing errors with more detailed information is certainly helpful. My gut feeling would be to have this as SHOULD and not as MUST. Reasoning is that for instance in BRSKI-PRM, we have different error codes for different states in the verification as discussed in the design Team meetings (see https://github.com/anima-wg/anima-brski-prm/issues/103). This allows to easily deduce in which state the pledge currently is and allows appropriate reaction in that specific state. Having more detailed information may lead to a more specific handling in that state. Based that the current approach allows for proper reaction, I would consider it as optional.
Best regards Steffen > -----Original Message----- > From: Toerless Eckert <[email protected]> > Sent: Wednesday, September 6, 2023 8:31 PM > To: [email protected] > Cc: [email protected] > Subject: Use of problem details in BRSKI (and other ANIMA) documents (rfc9457) > > 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%2Fassignments%2Facme%2Facme.xhtml%23acme-error- > types&data=05%7C01%7Csteffen.fries%40siemens.com%7C96d0c9691fa94b1c6 > 62e08dbaf0779f0%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638 > 296218869389810%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ > QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata= > aFb8goeUiPdCq2xCiZ5bRJPiZhtzmu6ws4jGuGUczBk%3D&reserved=0 > > --- 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%2Frfc%2Frfc8075.txt&data=05%7C01%7Csteffen.fries%40siemens.co > m%7C96d0c9691fa94b1c662e08dbaf0779f0%7C38ae3bcd95794fd4addab42e14 > 95d55a%7C1%7C0%7C638296218869389810%7CUnknown%7CTWFpbGZsb3d8e > yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7 > C3000%7C%7C%7C&sdata=37o%2Fj9xAL9Mtf3lazwZogLGAGJ1Bzo60E%2BuSXBx > rX5k%3D&reserved=0 > section 5.5.1 > -- > --- > [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
