[MUC] XEP-0045 review, part 1

luca 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

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="hag66 at shakespeare.lit/pda" id='rooms10'
    to="sorcerer at shakespeare.lit/laptop"
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items'
         node='http://jabber.org/protocol/muc#rooms'/>
</iq>

<iq from="sorcerer at shakespeare.lit/laptop" 
to="hag66 at shakespeare.lit/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
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/muc/attachments/20100122/c46b2a6c/attachment-0001.htm>


More information about the MUC mailing list