Am 20.09.2010 04:32, schrieb Waqas Hussain: > On Mon, Sep 20, 2010 at 6:41 AM, Florian Zeitz <florian.ze...@gmx.de> 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. > Wouldn't that mean that banning <domain> is also forbidden? While a bare JID in form it is not the bare JID of the occupant and we don't treat it as one when matching...
>>> 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 'm...@example.com' 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'. m...@example.com 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 >> evild...@example.com 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 m...@example.com would >> always be an occupant in this scenario >> > > I meant does m...@example.com's affiliation (as seen by all occupants) > change as well? My answer is yes. > Yes, makes sense. I realized later I mixed up affiliation and role when replying to this part... >> 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. > Me neither. If one doesn't want this situation to arise s/he may not use a <domain> JID. This is not any worse than the previous behavior though. >> 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, m...@example.com 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. > I disagree. The text does not explicitly talk about the JID. Removing 'example.com' is equivalent to removing "his or her own ownership" for 'm...@example.com'. However, regardless of the current text: Do you agree it makes sense for 'm...@example.com' not to be able to remove 'example.com' if that is the only JID in the owners list? > 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. > I'm still not convinced the current behavior of ban/outcast lists is "bare JIDs only". Even in your implementation it can also contain domain parts. While personally I can't see a use-case either, I don't think matching by full JID is harmful. Also do you think other lists should be able to contain full JIDs? I'll try to come up with a patch against xep-45 trying to catch all edge cases. If only to see how feasible this would be. -- Florian Zeitz
