[Standards] JID matching in XEP-0045

Florian Zeitz florian.zeitz at gmx.de
Mon Sep 20 05:53:05 CST 2010


Am 20.09.2010 04:32, schrieb Waqas Hussain:
> On Mon, Sep 20, 2010 at 6:41 AM, Florian Zeitz <florian.zeitz at 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. <user at domain/resource> (only that resource matches)
>>    2. <user at domain> (any resource matches)
>>    3. <domain/resource> (only that resource matches)
>>    4. <domain> (the domain itself matches, as does any user at 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 'me at 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'. me at 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
>> evildoer at 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 me at example.com would
>> always be an occupant in this scenario
>>
> 
> I meant does me at 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, me at 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
'me at example.com'. However, regardless of the current text: Do you agree
it makes sense for 'me at 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


More information about the Standards mailing list