Subject: OCP error and result indication

From: "Martin Stecher" <[email-masked]>
Date: Fri, 11 Jul 2003 11:45:15 +0200

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

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 11 Jul 2003 10:31:12 -0600 (MDT)

On Fri, 11 Jul 2003, Martin Stecher wrote:

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

Paraphrasing: Result is an anonymous parameter with the following
syntax:
	result = { code [text] }
	code = decimal
	text = string

> b) Like a) plus an error flag as additional named parameter for an
> abnormal condition that cannot be expressed via a result parameter.

Let's ignore this issue until Oskar provides more feedback. If
something cannot be expressed via a result parameter/code, then we
will add more options. If everything can be expressed with existing
means, then (a) and (b) are the same.

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

Scratch that. See (d) below.

  d) Errors are indicated by a named "Error" parameter with the
     following syntax:

	Error: code [text]

     Success is defined as absence of errors.

  e) Result is an anonymous parameter with the following syntax:

	result = { outcome code [text] }
	outcome = "+" | "-"
	code = decimal
	text = string

     we can replace "+" and "-" with something else, of course.

Let's approach the problem from the design point of view. What
information are we trying to relay here?

	1) is the result a success or failure? (true/false)
	2) what kind of success (if it is success)?
	3) what kind of error (if it is an error)?

(a) relies on specific code ranges (e.g., 2xx) to support (1) and
    supports (2) and (3) via specific code values (e.g., 404)

(d) relies on the presence of Error parameter to support (1) and
    does not support (2) and
    supports (3) via specific code values (e.g., 404)

(e) relies on the outcome "sign" to support (1) and
    supports (2) and (3) via specific code values (e.g., 404)

(e) is clearly better than (a) from the design point of view because
it is symmetric, but (a) is what people are used to. (d) lacks
functionality that might be needed for extensions.

Should we go with (a)?

Thanks,

Alex.