ietf-openproxy
[Top] [All Lists]

RE: OPES protocol, pre-draft 01

2003-02-25 09:24:54

On Tue, 25 Feb 2003, Oskar Batuner wrote:

Abnormal termination is different from normal termination (and all
other normal messages) in the sense that it switches context from
message processing to termination and cleanup. I think this
difference justifies presence of a separate message.

Both normal and abnormal termination switch callout server context
from message processing to termination and cleanup, don't they? I
agree that abnormal termination may have side-effects different from
normal termination. For example, if the callout server caches some
transaction information, it may want to purge the cache if the
transaction terminated abnormally.

Another difference is that abnormal termination message may arrive
at any moment, other messages are limited by the processing context
(protocol state machine).

Good point. This distinction can be useful if an implementation wants
to ignore/log non-control messages sent on the control channel.

In some sense it is a question of preferences - as you have
correctly pointed out difference between normal and abnormal
termination messages can be determined by some additional reason
code in the same message. I prefer to keep an explicit difference.

You have convinced me that the difference may be big enough to deserve
explicit protocol support. However, since the implementation code
handling each message would be almost the same, it may be more
appropriate to indicate the difference via an explicit optional flag:

        <data-end xid amid [error] reason>
        <message-end xid amid [error] reason>
        <xaction-end xid [error] reason>

instead of having six very similar messages:

        <data-end-error xid amid reason>
        <message-end-error xid amid reason>
        <xaction-end-error xid reason>
        <data-end-ok xid amid reason>
        <message-end-ok xid amid reason>
        <xaction-end-ok xid reason>

The first approach provides explicit error notification while better
matching the code that is likely to be written to support the logic.
It also allows us to reuse the same "error" notification mechanism
with other message types if needed.

Do we have an agreement now? Would you still prefer the second
approach?


Thank you,

Alex.