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 <presence/> 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?
<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
> "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 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.
> 7.4 - MAY return an error if you can't send - why not MUST?
Yeah, I think MUST is better here. I can't recall why we said it was "MAY".
> 1:1 conversion->MUC conversion: it's not a change, but I object to
> normative language on the UI here.
Sure. I've cleaned that up in my working copy.
> "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?
The current published version (1.24) has:
The service MAY rewrite the new occupant's roomnick (e.g., if
roomnicks are locked down). If the service does not accept the new
occupant's requested roomnick but instead assigns a new roomnick, it
MUST include a status code of "210" in the presence broadcast that
it sends to the new occupant.
Waqas Hussain (IIRC) pointed out that this code was not sent in other
cases where the roomnick might be changed on the server side, so for the
sake of consistency I added text about that.
> "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.
> 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).
See discussion above.
Peter
--
Peter Saint-Andre
https://stpeter.im/
