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.
> (especially as it seems we then continue to use the current meaning
> elsewhere in the document). ***
Fixed in my working copy.
> 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
Good catch. Fixed in my working copy.
> [existing before the patch].
Which patch is that?
> 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..."
> 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.
It seems that there is an asterisk missing in one of the cells, though.
Fixed in my working copy.
> " 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".)
> (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".
> "** 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?
> If we're changing wording to "MUC Component", let's go to "MUC
> service" instead, given that MUCs are rarely components these days.
+1
> 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).
Good catch. Fixed in my working copy.
> "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 notifications?
Is it difficult to pass through what the client sent?
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.
> When adding the additional address on history - what's the reason for
> this namespace?
You mean this?
Thrice the brinded cat hath mew'd.
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
> "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.
> 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 e
