[Standards-JIG] JEP-45 MUC - small issues

Gaston Dombiak dombiak_gaston at hotmail.com
Mon Oct 4 01:49:45 UTC 2004


While implementing MUC I found some possible scenarios which weren't covered
by the JEP (AFAIK). My idea is to validate the decisions I made and if
necessary add these clarifications to the JEP.

1. Registering with a room: What happens if the room does not exist?
My decision was to return a NOT_FOUND error if the user tries to register
with a non-existent room

2. Registering with a room: What happens if the IQ (set) packet does not
include a form?
My decision was to return a BAD_REQUEST error if the user tries to register
with a room but the IQ packet does not include a form.

3. Setting affiliation to "member" but the user was already affiliated with
the room
The JEP specifies that in a members-only room if a user is granted
membership he/she will receive an invitation to the room. This means that if
his affiliation changes to "member" we should send an invitation. But it's
possible that a user was an admin and his admin privileges were revoked
(downgraded to member) and in that case I decided to avoid sending an
invitation since the user already knows the room.

4. The form used for configuring the room allows to set the list of admins
and owners
In general granting and revoking privileges is done by sending the delta
(only the changes) to the server. But the JEP doesn't specify if the
configuration form must also include the delta or the whole list of
admins/owners. Since the form is dynamic I assumed that it'd be difficult
for a client to only send the delta for the new list of admins and owners.
Therefore, our MUC implementation considers that the whole list will be sent
by the client containing new and existing users/admins. IMHO, it's the
server's responsibility to obtain the admins/owners to remove and to add to
the list.

That's all as far as I remember. I'll post to the list if anything else
comes to my mind.

Regards,

  -- Gato






More information about the Standards mailing list