On 10.09.2010 19:31, Kevin Smith wrote:
> On Thu, Aug 5, 2010 at 7:50 PM, Florian Zeitz <[email protected]> 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.
>> 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).

--
Florob

Reply via email to