[Standards-JIG] Re: MUC presence issues
Joe Hildebrand
hildjj at gmail.com
Mon Oct 9 23:29:03 CDT 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-JIG
mailing list