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

Peter Saint-Andre stpeter at jabber.org
Mon Oct 4 17:27:19 UTC 2004

In article <cjqabq$8ll$1 at sea.gmane.org>,
 "Gaston Dombiak" <dombiak_gaston at hotmail.com> wrote:

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

Yes, JEPs do not always include all scenarios because either (1) the 
author was not thorough enough or (2) the scenario is covered by the 
baseline XMPP specs.

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


Also, if the user is already registered, the room should return an IQ 
result with an empty <register/> element as described in JEP-0077.

I've clarified all of these in JEP-0045.
> 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.

That makes sense.

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

Yes, I clarified this in my working copy, which I will release in the 
next few days.


More information about the Standards mailing list