[Standards-JIG] JEP-0045 (MUC) - IQ Stanza Semantics

Jacek Konieczny jajcus at bnet.pl
Thu Feb 19 09:40:10 UTC 2004

On Thu, Feb 19, 2004 at 09:23:45AM -0000, Richard Dobson wrote:
> > When it leaves the room he receives only his own unavailable presence:
> >
> > <presence to="..." from='room at server/him' type='unavailable'/>
> >
> > So his client or any entite in the middle may consider
> 'room at server/nick1',
> > 'room at server/nick3', 'room at server/nick4' still online.
> Why would it?, surely when leaving the room the client will forget the
> presences of anyone in that room and servers shouldnt be caching that data
> anyway,

I don't say it should be cashed, but assumption that if A receives
"available" presence from B it will receive "unavailable" presence
from B when it becomes unavailable seems just sane to me. Like receiving
iq type "error" or "result" in response to any "iq" sent.

I can imagine persisten client connection agent, which whould stay
connected to a server as a proxy for a client which may connect or
disconnect when needed. If no assumption about presence is made then
such aget must know any protocol extension using <presence/> stanzas.

And why use <presence/> instead of <message/> if it is not to be
treated like other <presence/> stanzas?

I don't say current MUC specification is not compliant with XMPP, but
the presence usage is not quite consistent with typical XMPP usage of


More information about the Standards mailing list