[Nmc-wg] Response codes:

[Michael Bischoff]

Hello All,

Ok to take in the things discussed at ogf30 with regards to capabilities:

A very usefull comment was that SIP also modeled their response codes
in a similar way as http does
which we also basing ours off, so lets learn from both:
http://en.wikipedia.org/wiki/List_of_SIP_response_codes

Proposed changes from comments:
> http://perfsonar.net/status/
>       informational/
>             too_busy
>             backend_service_not_available
>             protocol_bridge
Too_busy, backend_service_not_available and protocol bridge seem like
they are errors. informational seems to be used in http to advertise
things that happened during the exchange but didn't have an effect
upon successfully completing it.

I'm guessing you could advertise deprecation here like "your still
using version '1.0' please move to '1.1' as this service supports it"
though the LS should iron this out.

SIP's ringing, queued etc seems to indicate that they are dealing with
more statefull connections.

>       successful/
>             query_accepted/
>             echo/
>             registration/
>             deregistration/
>             keepalive/
Could probably suffice with just an 'ok' here as a client know what he
sends he already knows
what was succesfull
>        redirection/
not modified might be usefull for the LS, but thats completely subject
to the architecture which there is no consensus upon.
>        clienterror/
>             bad_request/
>             unauthorized/
>             method_not_allowed/
>             not_acceptable/
>             message_not_allowed/
>             event_type_not_allowed/
>             expected_response_tool_arge/
>         servererror/
>             internal_server_error/
the end of  internal_server_error/ can probably be dropped as
http://perfsonar.net/status/servererror/internal/ gives you the same
amount of information as
http://perfsonar.net/status/servererror/internal_server_error/
>             service_unavailable/
not sure if we could just say unavailable, do we have the notion of
more then one service at one spot?
>             protocol_not_supported/
>             unknown_version/
>             data_fetch_error/
Could probably be data_fetching or processing


Categorizing should be like:
https://docs.google.com/drawings/pub?id=1IXUZUSmy83cAJlpiHR96BGkBdgajXKu5IOJ6AnHVkPk&w=960&h=720

For every type of error one should assert if there is a usecase in
which it is recoverable and if there is a usecae where it's
unrecoverable.
Should there be usecases for both recoverable and unrecoverable then
there should also be two status codes for that single type of error,
this to allow a client to take a appropriate action.