http://perfsonar.net/status/       informational/             too_busy             backend_service_not_available protocol_bridge Too_busy, backend_service_not_available and protocol bridge seem like

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: 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.