On Mon, Jan 23, 2012 at 11:46 PM, Peter Saint-Andre <[email protected]> wrote: > On 1/19/12 7:49 AM, Kevin Smith wrote: >> Some comments, a couple of which predate the patch but most of which >> are a consequence of it: >> >> Redefining the meaning of 'room JID' seems unwise at this stage > > See other message in this thread.
Ok. I note that, given the existing body of code, literature and experience, changing this now is somewhere between ineffective (if people continue to use room JID) and confusing. But I won't block on it if everyone else thinks it's an improvement. >> [existing before the patch]. > > Which patch is that? I mean that this is not a complaint with the proposed changes, rather the existing version. >> In the definition of Open Room, not 'anyone' may enter, as banned >> users can't. [also predates the patch]. > > Changed in my working copy to: > > "A room that non-banned entities are allowed to enter..." Ta. > >> Table 5: Role State Chart and supporting text - could do with tidying >> up a little - I think we've discussed this previously. It's ok for an >> owner to kick an admin (and probably an admin to kick an admin, or an >> owner an owner), but not an admin kick an owner. > > Isn't that what this proviso text is all about, right after the table? > > * A moderator MUST NOT be able to revoke moderator status from an > occupant who is equal to or above the moderator in the hierarchy > of affiliations. I think that owners not being able to kick owners is largely pointless (as they could just demote them first and then kick them), but ok. >> " not the nick (and thus implicitly the full JID) as with roles." - >> isn't right, it's the nick, not the user's full JID, that defines >> roles (the user may have multiple full JIDs with the same nick) - so I >> think the parenthesised bit should go. > > But a nick is associated with a full JID. The point of the parenthical > remark is to remind the reader that a role is *not* associated with a > bare JID. (Thus "implicitly".) A nick *isn't* associated with a single full JID, it's associated with a set of full JIDs - all those sharing the nick in the room. It's not associated with a bare JID, either, as there may be multiple nicks with same bare JID in the room. >> (s/one result may be that/ e.g./, the user's nickname is reserved in >> the room). - I don't like this change, it implies membership always >> reserves the nick. *** > > First, it's a MAY, i.e., OPTIONAL for a server to support, so "always" > is incorrect. > > Second, this was intended as something that a server might do (it's not > even an all-caps MAY), so I suggest changing "may" to "might". The full paragraph was: """ The member affiliation provides a way for a room owner or admin to specify a "whitelist" of users who are allowed to enter a members-only room. When a member enters a members-only room, his or her affiliation does not change, no matter what his or her role is. The member affiliation also provides a way for users to register with an open room and thus be lastingly associated with that room in some way (e.g., the user's nickname is reserved in the room). """ My concern is that the "e.g." isn't clear (to me) whether it is giving an example of one way a service might make registered users lastingly associated with the room, or whether it's saying that it is an example of one of the things that does happen when you register with a room. So the previous text of "one result may be that" seemed less ambiguous to me. >> "** An admin or owner MUST NOT be able to revoke moderation privileges >> moderator status from another admin or owner." - This is somewhat >> silly [and always has been] and leads to the 'owner removes admin >> state, removes moderator state, kicks, promotes back to admin' dance. > > Yes, it's always been a bit silly. Probably we were paranoid about room > takeovers at the time we wrote that text. Suggested fix? "A moderator SHOULD NOT be able to revoke moderation privileges from someone with a higher affiliation them themselves (i.e. an unaffiliated moderator may not remove moderation privileges from an admin or owner, and an admin may not from an owner" ? >> "The room SHOULD also reflect the original 'id' value, if provided in >> the presence stanza sent by the user." - this is a significant change, >> is it necessary? ** > > How many clients include IDs in <presence/> notifications? Few or none, I imagine. > Is it difficult to pass through what the client sent? I doubt it's difficult for most implementations. > I don't see this as a necessary feature, but it might be nice for the > client to receive presence with the ID it included, for tracking purposes. Perhaps it's just that I'm not sure what we're trying to achieve here and don't like change for change's sake in Draft XEPs. I can probably be talked around. >> When adding the additional address on history - what's the reason for >> this namespace? > > You mean this? > > <message > from='[email protected]/firstwitch' > id='162BEBB1-F6DB-4D9A-9BD8-CFDCC801A0B2' > to='[email protected]/broom' > type='groupchat'> > <body>Thrice the brinded cat hath mew'd.</body> > <delay xmlns='urn:xmpp:delay' > from='[email protected]' > stamp='2002-10-13T23:58:37Z'/> > <addresses xmlns='http://jabber.org/protocol/address'> > <address type='ofrom' jid='[email protected]/desktop'/> > </addresses> > </message> > > Discussed here: > > http://mail.jabber.org/pipermail/muc/2011-December/000300.html > > To which you replied: > > http://mail.jabber.org/pipermail/muc/2011-December/000301.html Ah, because it's a XEP-0033 namespace. Ok then. >> "Because not all service implementations support MUC history >> management, a client SHOULD NOT depend on receiving only the history >> that it has requested." - if we think servers won't implement the >> spec, is mandating that clients do more work right? What client action >> are we requiring here? > > Better phrased as: > > Note: It is known that not all service implementations support MUC > history management, so in practice a client might not be able depend > on receiving only the history that it has requested. Thanks. >> 7.2.16 - mandating subject is sent is good (as above), maybe we need >> to say not to send previous subject change messages in the history? > > Well, that's pretty much stated already by text like this: > > After the room has optionally sent the discussion history to the new > occupant, it SHALL send the current room subject. > > and: > > The service MUST send all discussion history messages before > delivering the room subject and any "live" messages sent after the > user enters the room. > > However, I append sentence to the latter paragraph: > > The service MUST send all discussion history messages before > delivering the room subject and any "live" messages sent after the > user enters the room. Note well that this means the room subject > (and changes to the room subject prior to the current subject) are > not part of the discussion history. I think this makes it clearer for stupid people like me, thanks. >> "If the user's nickname is modified by the service as a result of >> registration and the user is in the room, the service SHOULD include >> status code "210" in the updated presence notification that it sends >> to all users." - this is new, I think, couldn't it break things? *** > > In what way does that break things? Prior to this change, 210 could only be received on 'your own' stanzas, so it's been reasonable for clients/libs to assume any time it sees 210 it's receiving its own stanza (and, given that servers tend to only send one status code at a time (to work around buggy clients), this is probably a sensible thing to do). If clients start receiving 210 from other people, I think it's entirely likely that things will break. >> "If the removed member is not currently in the room, the service >> SHOULD send a message to the user's bare JID indicating the change in >> affiliation." - I don't understand where this came from or what it >> achieves - clients can't rely upon receiving such a message (and I >> don't think examples are given). It also seems to be an interesting >> spam angle. I note we've removed the equivalent bit about losing >> ownership. *** > > I have no problem with removing that text and have done so in my working > copy, although I rather doubt that it's a significant spam angle because > it needs to be triggered by the room owner or admin. Ok, thanks.
