[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
presence.

Greets,
	Jacek



More information about the Standards mailing list