Hi,
we had already some discussion on this list regarding how to return a result or
an error status.
So far we see three options:
a) Messages such as TE and CE have an anonymous result parameter which is a
structure of the form {uni [string]}, where uni is the status/error code and
string an optional human readable description.
b) Like a) plus an error flag as additional named parameter for an abnormal
condition that cannot be expressed via a result parameter.
c) If we define only two result codes {200 ok} and {400 error} and allow for
omitting the result in case of "ok" and there is probably no reason for a
textual description of a successful operation, we can replace the result
parameter by a named parameter "Error: text".
I think a) is the best solution. Saying this I am simply lacking of imagination
what these conditions in b) are that cannot be expressed via result.
Oskar: I remember you talked about this. Can you show some examples why an
additional error flag is needed and a result structure is not sufficient?
This is why I prefer a) over c):
1. More than one error code is useful. In my prototype implementation I already
used two different codes trying to differentiate between syntax errors and
semantical errors. For the latter I used code 500 (which is probably not the
best number), e.g. {500 "18:CS message missing"} vs. {400 "24:Leading zero not
allowed"}.
While one can argue that this differentiation is not really necessary, how
about further error codes that tell one agent that the transaction was not
terminated due to a syntax error but because the other agent reached its
internal max. of open transactions per connection or because a negotiation
offer did not contain any matching feature?
I assume that some implementation can make use of well-known error codes (e.g.
open a new connection and try that transaction there).
2. Protocol extensions such as TLS may need result codes to indicate s.th. like
"authentication required"
3. Some application protocol bindings may benefit from more than one success
status. FTP for example uses different codes to return if a file was created or
replaced if I remember correctly. Maybe situations come up where such
differentiation will also be wanted within OCP result codes.
4. Testing tools or statistics in OCP products will it have easier to count
error conditions due to different codes rather than handling different textual
error descriptions.
Regards
Martin