[Standards] Presence Priority Implementation Guide

Rachel Blackman rcb at ceruleanstudios.com
Mon May 21 16:31:53 UTC 2007

>> How I handle it in Astra is that for the first message, I send to  
>> the bare JID of the other person.  After I receive a message (or  
>> if they initiate the chat), I send to the fully qualified JID  
>> they've messaged me from.
>> If I close the chat window, I assume the chat is done and no  
>> longer remember that resource, obviously enough.  However, I / 
>> also/ forget the resource if I receive a 'gone' Chat State  
>> Notification.  If I get a 'gone,' I do not close the chat window  
>> to that person, but if I send another message I will revert to  
>> sending it using the bare JID again.  This logic makes sense to  
>> me, as gone is used for 'I have been away from the keys for a long  
>> time' or 'I closed my chat window to you.'
>> This method seems to work fairly well for anything that supports  
>> XEP-0085, though it does sort of require blindly trusting the  
>> server's delivery mechanics when sending to a bare JID.  On the  
>> other hand, it doesn't work so well if the other client doesn't  
>> support XEP-0085.
> It's also probably a good idea to forget the resource whenever you  
> get a presence change from that user's bare JID; certainly you  
> should if you get a presence change from the resource you're  
> chatting with.

 From the bare JID, yes, I agree (and handle it as such).  But I  
think a presence change from the resource in question is a bit too  
generalized; if I'm talking to someone on a resource that's marked  
'idle' and then they mark it as available, I don't know that I really  
want/need to forget that resource.  Now, I agree if the presence is  
a /downward/ change -- available to away, away to xa, etc. -- that  
you should reset to bare JID for the next message, and effectively re- 
negotiate the conversation.

Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/

More information about the Standards mailing list