RE: OPES protocol, pre-draft 01

["Oskar Batuner" <batuner@xxxxxxxxx>]

See below.

> -----Original Message-----
> From: owner-ietf-openproxy@xxxxxxxxxxxx
> [mailto:owner-ietf-openproxy@xxxxxxxxxxxx]On Behalf Of Alex Rousskov
> Sent: Tuesday, February 25, 2003 11:25 AM
> To: OPES WG
> Subject: RE: OPES protocol, pre-draft 01
> 
> 
> 
> 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?

I'd prefer something in between:

  <data-end xid amid [error] reason>
  <message-end xid amid [error] reason>
  <xaction-end xid reason>       -- issued by server,
                                    processing is done,
                                    "you know the results"

  <xaction-abort xid reason> -- issued by any party,
                                "just forget it",
                                results of previous processing 
                                can not be relied upon 
                                and should be discarded

Oskar