ietf-openproxy
[Top] [All Lists]

Re: OCP error and result indication

2003-07-11 09:31:13


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.


<Prev in Thread] Current Thread [Next in Thread>