clienterror/not_acceptable/ - not further specified means it's a bad request but we don't know why(not sure if we should allow that) clienterror/not_acceptable/bad_request/ clienterror/not_acceptable/bad_request/event_type_not_allowed - I'm using this as an example because it was used before not because I agree with this error formulation as it tells me nothing? clienterror/not_acceptable/needs_authorization (perhaps something better would be information required to do authorization was not supplied (but thats kinda long ;) clienterror/not_acceptable/request_too_large clienterror/too_many_requests - this is when one client(ip?) sends too many request - hence it being client error, there could also be a servererror variant which means the server is too busy/being DoS-ed etc. My original question was do you or Roman envision these translating directly to a single result code in the new model, or would these be encoded as different codes for different situations. They should probably map - given that they make sense in the first place - to a single result code _with a common 'base'_(the left size of / exmple <BASE>/<MORE_SPECIFIC_BASE>/result_code I suppose you could call it parent too if you view it as a tree of values. Michael On Thu, May 13, 2010 at 4:43 PM, romradz@man.poznan.pl <romradz@man.poznan.pl> wrote:
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
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg