[Standards-JIG] JEP-0045 (MUC) - IQ Stanza Semantics
faceprint at faceprint.com
Wed Feb 18 13:30:05 UTC 2004
On Wed, 2004-02-18 at 02:57, Jacek Konieczny wrote:
> 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 imagine the problem of clients sending presence to the bare room JID
instead of room at conference/nick is due to the examples. The examples
all show presence being sent to the bare JID, while the text above them
says it should be sent to room at conf/nick.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the Standards