ietf-openproxy
[Top] [All Lists]

RE: OPES protocol, pre-draft 01

2003-02-26 12:28:27

On Wed, 26 Feb 2003, Oskar Batuner wrote:

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"

Great! We have an agreement on the above messages. Note that processor
may need to send "normal" <xaction-end> messages as well: this is both
an application-dependent and OPES service dependent issue that we
probably should not restrict too much without good reasons.

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

I agree with the definition. You prefer a specific error code for this
specific level of error. I prefer to keep it similar with the other
abnormal messages. Since processor may need to send "normal"
<xaction-end> messages too (see above), and since the final difference
between our approaches is minor (special message name versus a special
message flag), I would make the changes to have all <*-end> OPES
messages to use an optional "error" field for now and wait for more
objections/comments.

We have a semantics-level agreement. The remaining syntax-level
difference may even disappear once we start selecting specific
bindings and encodings for OPES.

Thank you,

Alex.