On Mon, Sep 20, 2010 at 6:41 AM, Florian Zeitz <[email protected]> wrote: > On 19.09.2010 04:09, Waqas Hussain wrote: >> >> That's only partially true. Full JIDs are still not allowed. >> > Not as far as I can tell. XEP-45 explicitly says: > > When an entity is banned from a room, an implementation SHOULD match > JIDs in the following order > (these matching rules are the same as those defined for privacy > lists in RFC 3921): > > 1. <u...@domain/resource> (only that resource matches) > 2. <u...@domain> (any resource matches) > 3. <domain/resource> (only that resource matches) > 4. <domain> (the domain itself matches, as does any u...@domain or > domain/resource) > > This is BTW not implemented in Prosody, which AFAIR always throws away > the resource. >
Hmm, the XEP is inconsistent here. See http://xmpp.org/extensions/xep-0045.html#ban "The ban MUST be performed based on the occupant's bare JID." and "The service MUST add that bare JID to the ban list [...]" I personally don't see much value in banning individual resources. >> This adds a ton of edge cases. I'm not very opposed to the change >> mind, but the complications it adds need to be taken into >> consideration. >> >> With the current behavior, we can make an assumption: All occupants in >> the room are either present in the affiliations' lists, or have >> affiliation='none'. >> >> With the new proposed behavior, we get new cases: >> 1. If 'example.com' is owner, and '[email protected]' is an occupant, >> what happens if example.com's affiliation changes? >> 2. If an owner removes affiliation of an occupant, who had affiliation >> inherited from a hostname, what happens? >> 3. If there's a single owner 'example.com'. [email protected] joins, and >> is an owner. Can it remove example.com from the owners list, given >> that it itself is an owner, and has a different JID? Can it see itself >> in the owners list? >> >> The above list isn't exhaustive. The point is, this wouldn't be a >> simple two-line change. >> > I think that some/most of these issues are solved just by matching in > the right order. > This is possible because a person only has one affiliation at a time. > E.g. If example.com is in the owners list, you can put > [email protected] in the member or outcast list to prevent him from > doing anything bad. > > As for the new cases, I don't even think all of the three are new: > 1. Matching bare before domain as in privacy lists [email protected] would > always be an occupant in this scenario > I meant does [email protected]'s affiliation (as seen by all occupants) change as well? My answer is yes. > 2. Personally I'd like to generally think of it as removing a JID from > one of the lists. As the occupant is never on any list this is > impossible. See above for a possible workaround. However giving someone > on a host that is in one of the list a affiliation of none is not > possible this way... I don't see this as a major issue. > 3. XEP-45 is already quite specific about that. Removing an owner from > the list (including yourself) is only permitted if there are still > owners left after that: > > A service MUST NOT allow an owner to revoke his or her own ownership > privileges if there are no other owners; if an owner attempts to do > this, the service MUST return a <conflict/> error to the owner. > However, a service SHOULD allow an owner to revoke his or her own > ownership privileges if there are other owners. > > So, such an action would be permitted, if there is another entry besides > 'example.com' in the owner list. Going strictly by that text, [email protected] should be able to remove example.com, since it's not 'his or her' JID. The current text assumes that an owner would always be in the owners' list. > -- > Florian Zeitz > As I said before, I'm not against the change (I can certainly see how it can be useful). I'd just like implementation behavior in all such cases to be explicitly specified, and text which depends on current behavior to be updated. My current preference for the ban list is to keep bare JIDs only though. -- Waqas Hussain
