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

JD Conley jconley at winfessor.com
Tue Feb 17 18:46:50 UTC 2004


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.

For example section 7 (moderator use cases) outlines the kicking and
voice protocols.  Both can return an error, but neither return a result.
You have no intuitive way of accurately matching the presence packets
that are received in result to your iq set since they don't have to have
the same ID.  So a client application could indefinitely keep around the
id of the iq set waiting for the result/error, or fall back to a timeout
condition where it may notify the user that their request was
unsuccessful when in fact it was succesful.  Or the client could wait
around for the presence packet with the correct status code and JID to
confirm the request.  But that seems to make the client more complicated
than it needs to be.

After all of that babbling, I realized not having the result goes
against XMPP-Core section 9.2.3 (IQ Semantics).  So shouldn't it be
changed in the MUC examples, or at least mentioned that a result must be
returned?

JD



More information about the Standards mailing list