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 (especially as it seems we then continue to use the current meaning elsewhere in the document). *** In the definition of Non-Anonymous Room (4.2), it says an occupant can choose any desired room nickname - I think it's more accurate to say that they can *request* it, as the room may not agree to serve it [existing before the patch]. In the definition of Open Room, not 'anyone' may enter, as banned users can't. [also predates the patch]. 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. " 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. (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. *** "** 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. If we're changing wording to "MUC Component", let's go to "MUC service" instead, given that MUCs are rarely components these days. 7.1.4 "The room subject (if any)" - we were going to make this mandatory even when there's no subject (and I think later in the document we do). "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? ** When adding the additional address on history - what's the reason for this namespace? "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? 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? 7.4 - MAY return an error if you can't send - why not MUST? 1:1 conversion->MUC conversion: it's not a change, but I object to normative language on the UI here. "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? *** "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. *** With my Council hat on, *** are the things that I'd like to see changed before publishing or at least for me to be shouted down on (i.e. at least discussed and consensus reached). /K
