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
2) Affiliation/
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?
3)Hidden 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.
4)Privileges 5.1.1
/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
unmoderated rooms.
*** 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 [8]) 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="[email protected]/pda" id='rooms10'
to="[email protected]/laptop"
type='get'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/muc#rooms'/>
</iq>
<iq from="[email protected]/laptop"
to="[email protected]/pda" type="error" id="rooms10" >
<query xmlns="http://jabber.org/protocol/disco#items";
node="http://jabber.org/protocol/muc#rooms"; />
<error type="cancel" >
<feature-not-implemented xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
</error>
</iq>
Peter Saint-Andre ha scritto:
As noted [1] the XSF's new Technical Review Team [2] has decided to kick
off its activities with a review of XEP-0045: Multi-User Chat. [3] 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
privileges.
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)?
Peter
[1] http://mail.jabber.org/pipermail/muc/2010-January/000067.html
[2] http://xmpp.org/xsf/teams/techreview/
[3] http://xmpp.org/extensions/xep-0045.html
