While XEP 45, Section 9.4 is reasonable clear that loss of membership causes a 
kick from the room, Section 10.7 is less clear of what happens on loss of admin 
privs.

10.7 says:
  If the user is in the room, the service MUST then send updated presence from 
this individual to all occupants, indicating the loss of administrative 
privileges by sending a presence element that contains an <x/> element 
qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing 
an <item/> child with the 'affiliation' attribute set to a value other than 
"admin" or "owner" and the 'role' attribute set to an appropriate value given 
the affiliation level and the room type

and then gives an example of showing the user moved to participant.

It doesn't detail what actually is 'appropriate'.

If in a member-only room, a user is moved to affiliation none (the user was 
only removed from admin list, not added to member), it seems appropriate to me 
to kick the user (just as the case when members are moved to none).

I suggest 10.7 be revised to be clear as to what should happen here. 
Specifically, I suggest the above text changing 10.7 to read:
    If the user is in the room, the service MUST then send updated presence 
from this individual to all occupants, indicating the loss of administrative 
privileges by sending a presence element that contains an <x/> element 
qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing 
an <item/> child with the 'affiliation' attribute set to a value other than 
"admin" or "owner" and the 'role' attribute set to an appropriate value given 
the affiliation level and the room type.

    If the user is affiliation is moved to 'none' and the room not member-only, 
the user is to be moved to 'participant':

    <insert current example 188>

    If the user is affiliation is moved to 'none' and the room is member-only, 
the user is to be kicked:

    <insert kick example>.


It may be appropriate to call out other cases as well, but I'm especially 
interested in clarifying the second case as it seems mostly likely to be 
incorrectly implemented.

-- Kurt

Reply via email to