[Standards] XEP-0045 Issues

Daurnimator quae at daurnimator.com
Thu Apr 24 19:37:44 UTC 2014


Hi List,

I'm a new subscriber, so I don't have the thread to reply to.

I recently re-wrote much of the MUC library used in prosody.
While doing so, I made a list of ambiguities and issues with the MUC
specification (XEP-0045)

Regards,
Daurnimator.


7.8.2 "The <room at service> itself MUST then add a 'from' address to the
<invite/> element whose value is the bare JID, full JID, or occupant JID of
the inviter and send the invitation to the invitee specified in the 'to'
address"
        What 'from' jid should we attach to a mediated invite if you're
inviting while not in the room and the room is anonymous

7.8.2 "If the inviter supplies a non-existent JID, the room SHOULD return
an <item-not-found/> error to the inviter."
        Does this mean we need to track invite ids?
                Invites do not have to be acknowledged; so this needs to be
stored in 'id' or something so the server is stateless

9.5: "MAY include the 'nick' and 'role' attributes for each member that is
currently an occupant."
        What if bare_jid is in room under multiple nicks?
                Just send multiple items?

        Why are actor and reason missing in example 114?

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


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

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140424/244a88b9/attachment.html>


More information about the Standards mailing list