On 1/22/10 6:07 AM, luca wrote: > 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
I think I've decided not to change the names of these, because then we would either need to (1) change the disco features or (2) live with a mismatch between the human-readable names and the disco features. > 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? The "none" affiliation is positively used only to "zero out" an existing affiliation. > 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. You could find the room by trying to join it, then publish the results on your blog. > 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 That's better, thanks. > /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 ” Yes, I already fixed that: http://xmpp.org/extensions/tmp/xep-0045-1.25.html#table-3 > 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 Thanks, fixed now. > 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> In fact XEP-0030 doesn't have good coverage of error flows so I think the XSF's Technical Review team needs to review that one next. ;-) According to XEP-0030 I think the user would return an empty <query/> element here, but it is under-specified in XEP-0030 (does the user return <feature-not-implemented/> because it doesn't know about that node?). /psa
smime.p7s
Description: S/MIME Cryptographic Signature
