Moving to the new model will be difficult because meanings of errors may overlap. Let's take 3 examples mentioned above. We can assign them to
clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/not_acceptable
but this one:
clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/bed_request
also provides true info about error situations.
I'm thinking that maybe we should say that the first part of result code URL is standard but the second part is not controled by NMC.
Standard parts of result codes: http://perfsonar.net/status/informational/ http://perfsonar.net/status/successful/ http://perfsonar.net/status/redirection/ http://perfsonar.net/status/clienterror/ http://perfsonar.net/status/servererror/
Example of complete result code: http://perfsonar.net/status/informational/something_which_is_proposed_by_ser...
Still thinking about it :) Pieces in result code like successful, clienterror, servererror are not enough for us for automatic categorization done by a receiver (e.g. client app)? Second part of result code would be just human readable. Do our client apps use detailed result code information for automatic actions? If we needed a more detailed result code for a specific automatic action we could add it to NMC. Roman
Cheers, Roman
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg