ietf-openproxy
[Top] [All Lists]

RE: OPES protocol, pre-draft 01

2003-02-27 09:45:57

jfc,

        It looks like you are still missing the point: There is
absolutely NO semantical difference between <xaction-end error> or
<xaction-end zap> or <zap>. Any compliant implementation will have
exactly the same code to handle any of the three messages. We cannot
argue about incompliant implementations, of course.

I already explained why I would prefer not to add [up to three] more
message types to OPES (which is what <zap> solution requires). We can
do that later if needed.

The remaining difference is only in visual formatting in the predraft
document: <xaction-end error> versus <xaction-end zap>. I am surprised
you want to spend time arguing about this difference, especially since
the OPES binding and message encoding may make the visual difference
disappear.

<philosophical-rant>
    If you insist, I can say that "zap" name is inferior to "error"
    because "zap" is an action and "error" is information. You may
    have noticed that the protocol is being designed so that each side
    provides information about its state. The other side will
    interpret that information according to protocol rules and its own
    state. Using action names like "zap" or "terminate" or
    "do-what-i-tell-you" is not the best approach here because it is
    too specific and may not match the other side capabilities or
    state.

    The simplest example is when the other side already zapped the
    transaction in question. It cannot zap it again, yet the message
    explicitly tells it to do so. From design point of view, this is
    bad because it creates an exceptional situation -- the side has
    been asked to do something that it cannot. Note that if the
    current design philosophy is followed, the problem does not exist
    -- the side is informed that there was a fatal error on the other
    side, and is free to take _any_ OPES-compliant action (which, in
    this case, is ignoring the message).
</philosophical-rant>

Alex.

P.S. I do not know what "nr" means in your
     <xaction-end error nr "zap"> message.

On Thu, 27 Feb 2003, jfcm wrote:

At 00:43 27/02/03, Alex Rousskov wrote:
Do you agree that <xaction-end error> is equivalent to <zap>? Or is
there more functionality in <zap> that <xaction-end error> is missing

The more you add to <xaction-end error> the more you will make it looking
it alike at a given time. But the more you add "error" the more you add
possible error types confusion.

Let settles that <zap> means <xaction-end error nr "zap"> and let
developpers use it. IMHO thei will result in <zap> being first tested and
<action-end error nr "zap"> being the default in the action-end case,
freely tested as per the developper gusto or priorities.

Also <xaction-end error> calls of reread/maintenance of the code when the
protocol is enhanced and options added. <zap> not.

You will see that "nr zap" will complexify over time, while <zap> will stay
an immediate clean and reset  command. Are you ok with that?

Anyway in my version there will be <zap> support :-)
Thank you.
jfc