[Standards-JIG] JEP-0045 (MUC) - IQ Stanza Semantics
jajcus at bnet.pl
Wed Feb 18 07:57:11 UTC 2004
On Tue, Feb 17, 2004 at 10:46:50AM -0800, JD Conley wrote:
> There are a few instances of using type='set' IQ packets in MUC where a
> type='result' is not expected to be returned. This is obviously by
> design. I assume this is because the request is "confirmed" with
> presence information being sent to the occupants. Although there are
> less packets traveling around, this goes against the way IQ usually
> works (get returns result/error, set returns result/error) and could be
> troublesome in clients.
I just assumed, that <iq type="result"/> must be sent and in my MUC
implementation (IRC transport gateway) I always send it. This is how
XMPP works, when done overwise it would not be XMPP.
I found other semantic problems with MUC, but with presence handling.
IMHO if service sends available presence from a jid it should always
send unavailable presence from that jid at some time. MUC conference
sends available presence from all room occupants to the user entering
the room, but it is not required to send unavailable presences from
occupants left when user leaves the room. This could break any Jabber
entities (servers, gateways, clients) that do some kind of presence
tracking or caching.
There are even more problems with existing client implementations of
MUC. Some of them send presence to bare jid of the room instead of
user's room jid (room at conference/nick). Yabber does this when closing
the chat, which makes my IRC gateway not disconnect the user (as
unavailable presence sent to bare room jid _is_not_ MUC conference quit
request). JAJC seems to have the same problem (I didn't see XML logs, so
I am not sure). tkabber sends presence updates (e.g. on auto-away) to
bare room jid - this also seems wrong - if it sent presence to
room at conference/jid to enter the conference it should use the same "to"
for all presence uptates.
IMHO <iq/> and <presence/> handling should be better clarified in MUC
specification and defined to be more consistent with XMPP specification
and regular XMPP usage.
I also have got and idea for <presence/> optimisations that could be
done in XMPP, but it is too late to introduce it (it would be a major
change to protocol which is already accepted). The optimisation would
allow to use unavailable presence sent from bare jid instead of
sending it from all connectected resources (this would be great for MUC
conference logout) and to user unavailable presence sent from a domain
instead of each JID in that domain (whould be good for server/component
shutdown). However such optimisation is not included in current XMPP
specification and should never be used.
More information about the Standards