[Standards-JIG] reliabilty of sending data revisited
thoutbeckers at splendo.com
Tue Oct 12 20:48:25 UTC 2004
On Tue, 12 Oct 2004 12:36:08 -0700, Justin Karneges
<justin-keyword-jabber.093179 at affinix.com> wrote:
> On Tuesday 12 October 2004 11:58 am, Tijl Houtbeckers wrote:
>> I assume you mean JEP-22 instead of 12. I've read JEP-79 a few more
>> when it was in last call, and it doesn't seem to me like it's meant to
>> provide delivery notifications.
> Actually, it does. You can use the notify action (Section 3.4.3) with
> deliver condition (3.5.1).
The way I understand it, the notify action is the same as the error
message. The difference is with the error the packet is dropped, and with
notify the server does the "default" action instead of the requested
For example, if you don't want your message stored offline, forwareded
etc., you specify the deliver condition with value "direct" and with the
"error" action. This way, if it can't be delivered directly you get an
error (in your message packet) and the packet is dropped. If you just want
to drop it "drop" if you want to drop it and get an alert rather than an
error message (I assume to provent a large body of text being copied into
the "error" message) you use "alert".
However, if you just want a *notification* when a message is stored
offline, forwared, etc., you specify the deliver direct condition with
value "direct" and with the "notify" option. If it can't be delivered
directly you get a notification, but the message is treated as "normal" by
the server. You still won't know what *did* happen as far as I can see.
In other words, as far I understand an action is only trigged when the
conditions in a rule fail. (The reason why the example for the "notify"
action is called: Example 8. "error" response). I have to admit that, like
I said, I had to read over this JEP more than once.
I imply here that when the JEP refers to "a rule's condition is met"
(which will lead to executing the action in the rule) is when that rule's
requirments can not be met by the server. Else I can make no sense of the
delivery rules in the JEP or the descriptions given for the different
So if I'm right on this, how can you get a notification of a rule that's
delivered succesfully? Specifying some form of deliver and notify as
action will only give you a notification when something *different* is
done than you specified. You should have a "no- deliver" action or a
"don't" value for the deliver action for it to work :)
But if I'm wrong on this (and someone please explain it to me then), it
would mean "a rule's condition is met" means that when the value of your
action ("direct" from deliver in this case) *is* done you actually raise
the action. Why would I want an error, drop or alert when I specify
"direct" and it's send direct. That would mean that if I want an error,
drop or alert when a message is NOT delivered direct I have to make rules
for every value that is NOT direct. Including future ones I suppose.
This is because the JEP says nowhere that I see states that the action
"notify" is triggered differently from the actions "error", "drop" and
"alert". Then how could you ever put more than one AMP rule in a message?
As soon as I get a "hit" on one condition the processing stops. So if I
want to be notified for direct delivery AND match resource it'd be
impossible. Look at the processing rules for servers from the JEP:
Process rules until condition is met.
If a condition is met, execute that rule's action
If no conditions are met, perform "default" behavior for message
This is why it really seems to me that AMP is meant to provide notifaction
OR a drop/error when one of your rules is NOT met. For notification of
things that go right there's still only JEP-0022 (including notification
of offline storage). If that's not how AMP was meant, well IMHO it MUST
have the notification the way I described it. Delivery notification could
be useful for AMP, but to me that's no core requirment. But just add a
condition to the AMP protocol ("notifysucces" or something that you can
use with "deliver").
>> What I think would be usefull start is a hop-to-hop mechanism like
>> (securing every stanza) and a new AMP delivery condition that will
>> you / give an error when your message is routed onto a path with no
>> JEP-ACK availiable and one for when delivery fails.
> Yes, JEP-Ack will make AMP more effective.
Cause I seem to interpret AMP the other way around, in my case it's AMP
that will make JEP-ACK more effective :) In any case, "just" JEP-ACK will
solve most of the problems anyway.
> However, having a "require Ack" AMP condition seems like it might be
> since the client isn't supposed to care about how things work beyond the
> first hop. But it might be worth discussing more later.
It's definatly not a requirment for JEP-ACK. But it will enable you to get
a warning (or error and dropped packet) when part of the path your message
takes does not have JEP-ACK. (That is, if I'm not dead wrong about AMP
here). For most practical plain IM purposes, that's almost the same as
end-to-end reliability, without much hassle for the client, and a
realistic view of how soon servers/clients will be running that implement
JEP-ACK and AMP.
> In any case, I'll re-push JEP-Ack to the council soon.
I'll be looking forward to that :)
More information about the Standards