[MUC] XEP-0045 review, part 1
luca.tagliaferri at gmail.com
Fri Jan 22 07:07:55 CST 2010
1) Maybe "invisible rooms" makes more sense that "private" and "hidden".
a.Invisible means the room is existing but cannot be seen by someone
b.hidden the room is existing and you can see but cannot find it
A long-lived association or connection with a room; the possible
affiliations are "owner", "admin", "member", and "outcast" (naturally it
is also possible to have no affiliation); affiliation is distinct from
role. An affiliation lasts across a user's visits to a room./
It is not clear to me which sense has having no affiliation; is it that
the user is not participating in the room?
A room that cannot be found by any user through normal means such as
searching and service discovery; antonym: Public Room./
Does it mean there are "unnormal means" users have to find it? I think
it is better to specify that normal users cannot find and if admins and
invited people on the contrary can.
/Each role has privileges not possessed by the next-lowest role/
Maybe it would be better to state:
/Each role has all the privileges possessed by the next-lowest role plus
some special ones
/5) Table 3: Privileges Associated With Roles
There is definitely some incongruence in the "Roles table" using:
/ * Default; configuration settings MAY modify this privilege.
** An implementation MAY grant voice by default to visitors in
*** A moderator MUST NOT be able to revoke voice privileges from an
admin or owner./
For instance the use of ** does not have anything to do with the usage
of it in the table where it says "
Send Messages to All No No** Yes Yes "
6) Example 4. Service Returns Disco Item Results
There is a typo here:
/If the full list of rooms is large (see XEP-0030 for details), the
service MAY return only a partial list of rooms. If it does so, it
SHOULD include a <set/> element (as defined in Result Set
Management ) to indicate that the list IS not the full result set./
The "IS" is missing
7)The "error flow example" for http://jabber.org/protocol/muc#roooms
discovery example could be:
<iq from="hag66 at shakespeare.lit/pda" id='rooms10'
to="sorcerer at shakespeare.lit/laptop"
<iq from="sorcerer at shakespeare.lit/laptop"
to="hag66 at shakespeare.lit/pda" type="error" id="rooms10" >
<error type="cancel" >
Peter Saint-Andre ha scritto:
> As noted  the XSF's new Technical Review Team  has decided to kick
> off its activities with a review of XEP-0045: Multi-User Chat.  This
> week I am hoping that everyone has a chance to read and review Sections
> 1 through 6 (the first ~20 pages). I have completed my own review and I
> have found a number of editorial issues that I shall be fixing, but
> nothing huge. In particular:
> 1. I'd like to rename "Unsecured Room" to "Unprotected Room" because
> "security" is such a vague concept and because the antonym is "Password
> *Protected* Room".
> 2. I'd like to rename Section 5 "Roles, Affiliations, and Privileges"
> and describe roles and affiliations as "shortcuts" to certain bundles of
> 3. I think we need examples of error flows in Section 6 (e.g., what does
> the client return if it doesn't support the well-known service discovery
> node "http://jabber.org/protocol/muc#rooms").
> What other issues have you found during your reading of XEP-0045
> (Sections 1 through 6)?
>  http://mail.jabber.org/pipermail/muc/2010-January/000067.html
>  http://xmpp.org/xsf/teams/techreview/
>  http://xmpp.org/extensions/xep-0045.html
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the MUC