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

Jacques Belissent jacques.belissent at sun.com
Wed Aug 31 22:23:39 UTC 2005

Maciek Niedzielski wrote:
> 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.

If you have an amp element in the message that says "deliver only to 
this specific client, ever (use case a)", why would you want to deliver 
to the different client?

>>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.

yea ok...  Still I'm wondering if integration with email systems for 
offline message delivery already covers this use case.  Or at least 
covers it sufficiently that making changes to jep 79 is not justified.


> - --
> Maciek
>  xmpp:machekku at chrome.pl
> Version: GnuPG v1.2.1-nr1 (Windows XP)
> iD8DBQFDFiR+7knNPWzAbeURAugEAKCCXqMYe1NRRewOp8Zp+q9+taNBtwCfS8bT
> rSqcB+toSo5rYgY7b+30/34=
> =Jw8g

More information about the Standards mailing list