[Standards] XEP-0045 Issues

Tobias Markmann 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
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


The section on mediated invites starts with:
> It can be useful to invite another user to a room in which one is an
occupant.
If you're inviting to an anonymous room the 'from' JID is the occupant JID
I think.

>
>
> 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
moderator-ship

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

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

Cheers,
Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140721/83c4355f/attachment.html>


More information about the Standards mailing list