[Standards-JIG] Re: MUC presence issues

Joe Hildebrand hildjj at gmail.com
Sun Oct 8 02:29:57 UTC 2006


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.

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