[Standards] XEP-0045 Issues

Dave Cridland dave at cridland.net
Mon Jul 21 20:24:26 UTC 2014

Commenting further where I have something to say beyond agreement with
Tobais's suggestions.

On 21 July 2014 19:03, Tobias Markmann <tmarkmann at googlemail.com> wrote:

> > Order of stanzas sent for affiliation changes
> >
> > 9.7 "an admin MUST NOT be allowed to revoke moderator status from a user
> whose affiliation is "owner" or "admin". If an admin attempts to revoke
> moderator status from such a user, the service MUST deny the request and
> return a <not-allowed/> error to the sender:"
> >         I feel like admins should be able to remove (hide) their
> moderator-ship
> +1. I think admins should be allowed to remove their admin status.
Hmmmm. I'm not against it, but it's a special-case in security-related
code, which always worries me.

> >
> >
> > Can a "http://jabber.org/protocol/muc#user" have multiple children?
> >         e.g. more than one invite?
> >         The schema at the end suggests yes...
> >         If so; how to signal the failure of a single sub-request....
> >
> I think the XEP was written with a singe invite child in mind but maybe
> one of the authors can chime in on that.
I see nothing in the text suggesting you are allowed to invite multiple
jids, and the text seems definitively singular. The text (for XEPs) trumps
the schema.

> > 10.1
> >         What should happen in a partial failure of room configuration?
> >                 e.g. set whois to moderators, then password to blank:
> the first change has already been applied, but the next one is invalid
> >
> >                 It seems that room config must all be validated
> up-front, before making changes rather than processing in order...
> >                         This suggests race conditions
> >         Is configuration Last-Write-Wins?
> If the configuration throws errors the creator should cancel room
> configuration http://xmpp.org/extensions/xep-0045.html#example-162 .
> Ideally configuration is done and then the room unlocked. This way only the
> creator can configure the room.
I think:

a) Configuration changes must be atomic.

b) This doesn't introduce any further race conditions than if they aren't;
it just simplifies the cases where a race condition applies to
last-change-submitted wins.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140721/d580ed0b/attachment.html>

More information about the Standards mailing list