On 19.09.2010 04:09, Waqas Hussain wrote:
> On Mon, Sep 13, 2010 at 5:20 AM, Florian Zeitz <[email protected]> wrote:
>> 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.
>
> 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.
>>>> 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 '[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
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...
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.
--
Florian Zeitz
