On 1/3/12 9:15 AM, John MacAuley wrote:
On 2011-12-21, at 5:44 AM, Henrik Thostrup Jensen wrote:
I think we also need a plan with the error codes and their classification. Do we provide the errors in order to tell a user went wrong (in which case a string will suffice), or do we provide error codes so a client can intelligently handle some cases, or both?
The answer is probably the latter, with some semantics for errorId, which can enable the client to automatically classify and potentially recover from the error. The distinction between text and variables are somewhat artifial and only makes sense for missing of invalid parameters. If we assume that the error string is for humans only, the distincition between:
text: Missing parameters: Start time, Dest STP.
and
text: Missing parameters variables: ["Start time", "Dest STP"]
Is just unneeded complexity. If a client is missing a parameter, it probably won't be able to change the request and fill it out automatically by looking at the error response. It should just be fixed and send the parameter in the first place.
It seems there are some key "classes" of errors with some relation to the stage at which it is generated: a) primitive formatting errors (a request primitive is ill-formed), b) protocol errors (confuses the state machine/flow chart), c) service request processing errors (e.g. Aggregator issues between NSAs) d) service request resource errors (the uPA/NRM cannot fill the request), and e) service instance failure errors (an otherwise good service breaks). Are there other classifications? (I don't recall the details of prior discussions on this.) These classes are listed in order of detection ...(sort of I think..:-) So a "service request resource error" implicitly means the request was well formed and conformed to protocol, and the message was processed to reach an appropriate NSA, but the resources required were incorrect or unavailable. (Note: the order above loops - as each message flows from NSA to NSA the gantlet of checks repeats) The order for detecting more detailed error conditions may be less than obvious: If a service resource request is rejected because available resources were not available for that user...is this a resource unavailable? or unauthorized? It depends on how you prioritize your constraints. If you prune the constraint based search by authorization policy first, and resources remain that are authorized for that user, but then the resources needed to reach his particular destination are already in use, then this is a "resource unavailable" error - regardless of whether other [unauthorized] resources are available and would have met the technical requirements for the connection. Likewise, if the technical requirements are used to prune the resources first, and then the user fails on authorization of the sole path to his destination, then this would generate a "unauthorized" error. And in either case, if the requested time window is blocked, but the path finder failed on "resource unavailable" or "unauthorized" then the path finder will terminate and the user will not know that his schedule was flawed as well. The request actually had several problems. (And if you tell a path finder to "continue searching" despite missed constraints, your search space explodes, and the results (or errors) may not even be relevant.) So we can re-order constraints, but we cannot ignore them. In general - the universe of possible primitive formulations are overwhelmingly "erroneous" in some fashion - only a very few intelligently constructed primitives are actually going pass the gauntlet to be successful. So our approach should not be to enumerate all possible errors we may encounter, but to classify the errors in some broad fashion and communicate that class only. We can refine some error classes to define more specific classes where they may be (a) [relatively] frequent/common errors, or (b) expose a key or "critical" condition (for the RA or the PA). just some thoughts... Jerry