[Standards-JIG] Re: MUC presence issues
ian.paterson at clientside.co.uk
Sun Oct 8 09:52:09 UTC 2006
Joe Hildebrand wrote:
> That means a lot more state for the server to maintain. Instead of
> just holding the last transmitted presence stanza, it would have to
> hold the last transmitted presence stanza for each place you directed
> I prefer the idea of auto-bouncing groupchat messages to unavailable
I'm primarily a client developer, so forgive me if I'm missing something
Do you mean only auto-bouncing groupchat messages from JIDs that have
received directed presence? (If not AFAICT this would be a presence leak.)
In which case the servers would need to remember who I sent unavailable
presence to even after I go offline... So there are state issues either way.
I prefer the idea of allowing a server to confirm the integrity of
directed presence because it will increase the reliability of XMPP (not
The server wouldn't need to remember directed presence stanzas I send to
subscribers. So, this extra state shouldn't be a problem under normal
usage. I guess the average number of rooms each user occupies at any one
time will be less than one.
If the RFC said "SHOULD respond to presence probes" (not "MUST"), then
my server would be free to either disable support entirely, or to forget
some of the state if it starts to accumulate during my session.
> On Oct 7, 2006, at 7:51 PM, Ian Paterson wrote:
>> JD wrote:
>>> When [a server] receives an unavailable it has to broadcast it
>>> to all the places the user sent directed presence.
>>> The only time I really notice it is in the s2s case when a
>>> server goes down.
>> Yes, you're right.
>> AFAICT (please correct me again if I'm wrong), RFC 3921 and RFC
>> 3921bis do not provide for my server answering a presence probe that
>> was sent on behalf of another user who is not subscribing to my
>> presence, but who has received directed available presence from me.
>> Even so, I agree with you it would be a very good solution, with
>> general applicability for the reliability of directed presence... and
>> much better than the keep-alive alternative. :-) The request-response
>> would double the s2s traffic when compared to keep-alive, but there
>> would be no c2s traffic on either side... and clients would be kept
>> So perhaps this can be added to section 4.3 of RFC 3921bis? It seems
>> no presence leaks would occur as long as the user's server that sends
>> the probe receives an error if the user has already received
>> unavailable presence from me, and otherwise only receives an exact
>> copy of the last directed presence stanza that my server sent to the
>> user on my behalf.
>> - Ian
More information about the Standards