[Standards-JIG] reliabilty of sending data revisited

Tijl Houtbeckers 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  
>> times
>> 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  
> the
> 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  
>> notify
>> 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  
> overkill,
> 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  

> In any case, I'll re-push JEP-Ack to the council soon.
>   http://delta.affinix.com/specs/jep-ack.html

I'll be looking forward to that :)

More information about the Standards mailing list