All,
I'm cross-posting this to NM, NMC and NML, who are currently using the
urn:ogf:network syntax.
This namespace is currently not formalized. To this end, 3 documents
will be created:
- an Internet-Draft with syntax description and delegation of urn:ogf
- a GFD with procedural description for subdelegations in urn:ogf
- a GFD with syntax and subdelegation of urn:ogf:network
The first document has been created, and is available at
http://tools.ietf.org/html/draft-dijkstra-urn-ogf
You can leave feedback at
https://forge.gridforum.org/sf/go/artf6459
Or download the (XML) document source code at:
https://forge.gridforum.org/sf/scm/do/listRepositories/projects.nml-wg/scm
Regards,
Freek Dijkstra
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=1IXUZUSmy83cAJlpiHR96BGkBdgajXKu5IO…
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.
