Snipping areas of agreement... On 1/24/12 2:14 AM, Kevin Smith wrote: > On Mon, Jan 23, 2012 at 11:46 PM, Peter Saint-Andre <stpe...@stpeter.im> > 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.
I think it's an improvement, and a much less significant change than node => localpart. >>> 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. Indeed it probably is useless, but it's always been useless. :) The concern is more about a non-admin moderator (which is allowed, since moderator is a role) kicking an admin or 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. >> >> 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. I thought we agreed to define that multi-JID support in a separate spec? >>> (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. I'm not seeing a big difference here, but in my working copy I've changed it to: "one result might be that the service could reserve the user's nickname in the room" >>> "** 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" > ? With minor edits, changed in my working copy to: A moderator SHOULD NOT be allowed to revoke moderation privileges from someone with a higher affiliation than themselves (i.e., an unaffiliated moderator SHOULD NOT be allowed to revoke moderation privileges from an admin or an owner, and an admin SHOULD NOT be allowed to revoke moderation privileges 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. How about: For tracking purposes, the room might also reflect the original 'id' value if provided in the presence stanza sent by the user. No normative force there, just a suggestion. >>> "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. But we have a separate status code (110) for self-presence. Peter -- Peter Saint-Andre https://stpeter.im/
