[Standards] admin->none, what happens to user if in member-only room
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 element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an 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 element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an 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': If the user is affiliation is moved to 'none' and the room is member-only, the user is to be kicked: . 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
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 20.09.2011 08:46, Peter Saint-Andre wrote: On 9/19/11 4:40 PM, Alexander Holler wrote: No, but maybe adding some muc-features which are making it obvious what is supported by the server is an option. I don't know if there is an implemention which supports e.g. those voice-requests as described, those I've tested seem not to have it implemented. If you test more implementations and find that none of them support the feature (and the developers say they have no plans to implement the feature), then it might make sense to remove the feature from the spec. Peter We have a patch and we are going to include it in the new ejabberd version. Please don't remove the feature from the spec. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Tue, Sep 20, 2011 at 3:50 PM, Alexander Holler wrote: > Am 20.09.2011 00:46, schrieb Peter Saint-Andre: >> >> On 9/19/11 4:40 PM, Alexander Holler wrote: >>> >>> Am 19.09.2011 20:23, schrieb Peter Saint-Andre: On 9/6/11 10:38 AM, Alexander Holler wrote: > > Looking again at XEP-0045, > > I don't see a reason why a request for voice should be handled in > another way than a request for membership. ;) > > In fact I would suggest to replace both with an unified "request for > affiliation" which should work like the request for membership in 7.10 > (with an attribute 'affiliation' and maybe a xmlns something other than > 'jabber:iq:register'). Is there a strong reason to change this now, other than protocol hygiene? >>> >>> No, but maybe adding some muc-features which are making it obvious what >>> is supported by the server is an option. I don't know if there is an >>> implemention which supports e.g. those voice-requests as described, >>> those I've tested seem not to have it implemented. >> >> If you test more implementations and find that none of them support the >> feature (and the developers say they have no plans to implement the >> feature), then it might make sense to remove the feature from the spec. > > Since sending a private messages to administrators is always possible (even > without voice), I think there isn't really a need for this feature. That's not true. PMs to room admins are not always possible. For example, jab...@conference.jabber.org has PMs disabled for non-moderators, and sending to admins doesn't work. -- Waqas Hussain
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Am 20.09.2011 00:46, schrieb Peter Saint-Andre: On 9/19/11 4:40 PM, Alexander Holler wrote: Am 19.09.2011 20:23, schrieb Peter Saint-Andre: On 9/6/11 10:38 AM, Alexander Holler wrote: Looking again at XEP-0045, I don't see a reason why a request for voice should be handled in another way than a request for membership. ;) In fact I would suggest to replace both with an unified "request for affiliation" which should work like the request for membership in 7.10 (with an attribute 'affiliation' and maybe a xmlns something other than 'jabber:iq:register'). Is there a strong reason to change this now, other than protocol hygiene? No, but maybe adding some muc-features which are making it obvious what is supported by the server is an option. I don't know if there is an implemention which supports e.g. those voice-requests as described, those I've tested seem not to have it implemented. If you test more implementations and find that none of them support the feature (and the developers say they have no plans to implement the feature), then it might make sense to remove the feature from the spec. Since sending a private messages to administrators is always possible (even without voice), I think there isn't really a need for this feature. Regards, Alexander
