[Standards-JIG] Re: MUC presence issues

Joe Hildebrand hildjj at gmail.com
Tue Oct 10 04:29:03 UTC 2006


On Oct 9, 2006, at 11:38 AM, Ian Paterson wrote:

> Ian Paterson wrote:
>> This version of the probe solution would probably require even  
>> less state than the groupchat bounce solution, since as soon as I  
>> go unavailable all state can be forgotten.
>
> In fact no extra state would need to be kept at all. Today servers  
> already have to remember who they sent directed available presence  
> to in case I go offline without sending directed unavailable presence.

As long as the response is interpreted to mean "the presence that you  
LAST got from me is still valid", I'm ok with this, since otherwise  
the server does have to keep track of all of the presence extensions,  
priorities, etc. to ensure that the new presence is good.  Caps in  
particular, since, what with PEP, I can imagine sending different  
caps to different people.

If that's the case, I'm not sure how you distinguish between the  
response to the probe and a client just sending an update, though.  I  
suppose in response to a probe by someone on the avails list, but not  
"both" or "from" in the roster, you respond with something like:

<presence from='user at example.com/resource'  
to='room at conference.example.com'>
   <ignore xmlns='http://xmpp.org/protocol/ignore'/>
</presence>

or something similar.  Of course, if we've missed just a single  
presence update, the room will still show me with incorrect status/ 
show...



More information about the Standards mailing list