[Standards-JIG] Re: MUC presence issues

Ian Paterson 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 
> presence.
> I prefer the idea of auto-bouncing groupchat messages to unavailable 
> resources.

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 
just MUC).

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.

- Ian

> 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 
>> simple.
>> 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 mailing list