[Standards-JIG] proposal : defer action in AMP (JEP 79)

Maciek Niedzielski machekku at miroku.uaznia.net
Wed Aug 31 21:43:26 UTC 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jacques Belissent wrote:
>> And what if I don't give an expiration date and user does not login to
>> that resource ever? Should it be stored forever?
>> I guess that the implementators would like to be able to do something
>> with deferred messages after some time of waiting.
>> I think it would be a good idea to have two different actions:
>> a) defer or drop after some time
>> b) defer or deliver to any resource after some time
>>
> 
> This is not an entirely new problem.  Stored messages that have no AMP
> extension and not been picked up somehow have to be dealt with one way
> or another.  This is up to the implemtation and site policies.
> unexpiring deferred messages could be submitted to the same policies.

If I send a message to someone who is offline for a month, I may suspect
that the message could be dropped.
But imagine a situation like this:
I send a message to romeo at example.org/Home with a AMP rules defined as
in previous post. Romeo is now offline... installing a new Jabber
client. He quickly sets up everything and connects as
romeo at example.org/AtHome.
I may not even notice this small change, but my message will be deferred
and after some time silently dropped.
I think these situations are a bit different.


> Are there real-life use cases for b)?

I have a friend who is an admin of a computer network which I use.
Sometimes it's easier for him to solve my 'problems' when he's at work.
So I'd like to send them to his 'Work' resource, even if he's not there
at the moment.
Now let's say that I just sent my message, although 'Work' is not
connected right now. But I don't know that he just went on 1-week
holiday. In such case, I'd like to have a rule saying "if he doesn't
connect at work within 24 hours, deliver it where possible".

So, in general, it's a situation when a message it's more convenient for
a person to receive it at particular resource and is not urgent, so it
may wait a bit, but not too long. And it's better to get it somewhere
else than to wait too long.

- --
Maciek
 xmpp:machekku at chrome.pl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1-nr1 (Windows XP)

iD8DBQFDFiR+7knNPWzAbeURAugEAKCCXqMYe1NRRewOp8Zp+q9+taNBtwCfS8bT
rSqcB+toSo5rYgY7b+30/34=
=Jw8g
-----END PGP SIGNATURE-----



More information about the Standards mailing list