[Standards] XEP-0045 Issues
tmarkmann at googlemail.com
Mon Jul 21 18:03:37 UTC 2014
Hi and welcome to the list,
You will find my reply inline.
On Thu, Apr 24, 2014 at 9:37 PM, Daurnimator <quae at daurnimator.com> wrote:
> 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
> 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'
> What 'from' jid should we attach to a mediated invite if you're
inviting while not in the room and the room is anonymous
The section on mediated invites starts with:
> It can be useful to invite another user to a room in which one is an
If you're inviting to an anonymous room the 'from' JID is the occupant JID
> 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
Well..that'd be only for the error case, not? This would then be for a
rather short time.
I also think http://xmpp.org/extensions/xep-0045.html#example-58 is missing
a full JID in the 'to'-attribute of the 'decline'-tag. This could be needed
to correctly forward the decline in case of multi-session nicknames. At
least for non-anoynmous rooms.
> 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?
I think one item should be sufficient since all sessions of a multi-session
nicks should share the same role.
> Why are actor and reason missing in example 114?
I think not particular reason. According to the paragraph before actor and
reason are optional:
>...including the status code and optionally the reason and actor:
> 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
+1. I think admins should be allowed to remove their admin status.
> 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.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards