On Tue, Jan 24, 2012 at 6:14 PM, Peter Saint-Andre <[email protected]> wrote: > Snipping areas of agreement... > > On 1/24/12 2:14 AM, Kevin Smith wrote: >>>> " 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?
We did, I just think having that parenthesised text "(and thus implicitly the full JID)" confuses things, given that (whichever spec it's documented in) MUC sharing is increasingly well deployed. But this is minor, I don't think it's worth spending more time on. >>> 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). +1 >>> 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. I'm fine with that. >>>> "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. Discussed with higher bandwith. /K
