Ok one last one that I can see in Section 6, however this one is not strictly muc as it's an issue in the schema for XEP-0030.
In 6.2 Discovering Rooms, example 5 shows how the service can return a partial list of room by using ResultSet management (XEP-0059). The problem here is that in the schema defined in for disco#items (XEP-0030) it doesn't allow for any additional elements to be included in the query element, only 0 or more 'item' elements - however example 5 shows a 'set' element in the 'http://jabber.org/protocol/rsm' namespace. So does disco-items.xsd need changing, and would this be part of the muc review or should it be done separately? In either case the fix would be to add an xs:element to disco-items.xsd either refering directly to 'set' in the rsm namespace or as xs:any NB: I originally came up with this one early last year (as I use JAXB to generate classes directly from the schemas), but in the end didn't need ResultSet Management so it wasn't a problem. Peter On 1/22/10, Peter Saint-Andre <[email protected]> wrote: > 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 > > > -- Peter Mount e: [email protected] w: http://retep.org xmpp:[email protected] MSN: [email protected]
