On Mon, Sep 13, 2010 at 5:20 AM, Florian Zeitz <florian.ze...@gmx.de> wrote: > On 10.09.2010 19:31, Kevin Smith wrote: >> On Thu, Aug 5, 2010 at 7:50 PM, Florian Zeitz <florian.ze...@gmx.de> wrote: >>> [This time from the correct account...] >>> >>> Hi, >>> as discussed in jdev@ today XEP-0045 is slightly underspecified and/or >>> different from what people expect in terms of matching JIDs. >>> >>> 1. Roles: (not discussed in jdev@) >>> "Roles are granted, revoked, and maintained based on the occupant's room >>> nickname or full JID" >>> One can join a room with the same nickname from multiple different >>> resources. What happens if different full JIDs have different roles, but >>> the same nick is unspecified (AFAICT). I'd expect this to be strictly >>> nickname based... >> >> Makes sense to me at the moment. >> >>> 2. Affiliations: (discussed in jdev@) >>> Affiliations are supposed to be handled by bare JID, however: >>> a) Outcasts are an exception from this rule and use the same matching as >>> privacy lists.
That's only partially true. Full JIDs are still not allowed. >>> b) It's not clear what happens if e.g. a domain is in the list of >>> members. Does that mean only the server itself may join the groupchat, >>> or are all accounts on the server supposed to be able to join the >>> groupchat too. >>> It seems people (including me) mostly expect the JID matching rules >>> specified for privacy list to apply to all forms of affiliation. In fact >>> it seems to be implemented this way in ejabberd. >>> My personal use-case is that I'm hosting a MUC for university purposes >>> on my own server that should be members only, but all users of the >>> university's server should be members. >> >> I think server-JID means all JIDs on the server are the given >> affiliation. I don't see any other way making sense. >> > Which (just to be clear) is exactly what the usual (privacy list) > matching specifies. > So, as a sort of push: > Is there anyone who actually disagrees with this assessment? > Otherwise I'd propose this to be changed in an iteration of XEP-0045 > (also taking into account it already is the status-quo in at least > ejabberd). > 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. -- Waqas Hussain
