* Dave Cridland <[email protected]> [2014-12-22 09:19]: > On 22 December 2014 at 01:19, Sam Whited <[email protected]> wrote: > > XEP-0191 (Blocking command) specifies that once a contact is blocked, no > > stanzas are delivered from them to the user: > > > > > Once the user has blocked communications with the contact, the > > > user's server MUST NOT deliver any XML stanzas from the contact to > > > the user. The block remains in force until the user subsequently > > > unblocks commmunications with the contact (i.e., the duration of the > > > block is potentially unlimited and applies across sessions). > > > > However, Gajim (and possibly other clients that use privacy lists) seems > > to block everything but presence information. > > Slightly confused by this. XEP-0191 is server-side enforced, so the > behaviour will be applied and controlled by the server, not the client.
Gajim uses XEP-0016 to block all stanzas except for <presence-in/> notifications. Sam and I were discussing the relationship of XEP-0191 blocklist entries to privacy lists. XEP-0191 doesn't mention the fact that XEP-0016 allows for blocking only some kinds of stanzas. It just says the server | SHOULD map the blocklist to the default privacy list, where each blocked | JID is represented as a privacy list item of type "jid" and action | "deny". [ http://xmpp.org/extensions/xep-0191.html#privacy ] To me, it's unclear whether this mapping rule is meant to also apply to privacy list items that block some kinds of stanzas but not others. > > From a user perspective, this seems like the expected behavior (I block > > someone, they can't receive information about my presence or send me > > messages, but I can still see their presence unless they block me). > > > > Am I interpreting everything correctly, and if so, is this something > > that would be considered for change? I'd like to propose that the line > > from XEP-0191 be rewritten to read something like: > > > > > Once the user has blocked communications with the contact, the > > > user's server MUST NOT deliver any XML stanzas from the contact to > > > the user except for presence stanzas. ... > > This would mean that probes still get sent, which seems inappropriate. > > Otherwise we're in the slightly weird situation that we're predicating on > remote servers sending presence without a probe - this is quite possible, > but could lead to some very odd behaviour when this get out of sync. We already have this issue when implementing XEP-0016. ejabberd was changed just recently to send probes in order to support that use case.¹ This leaks the user's availability to the remote server's admin, but it's the only way to make that feature usable. As I understood it, other servers behave that way, too. As far as I can see, XEP-0016 itself doesn't mention outgoing probes. It just says the presence notifications which are subject to privacy rules | do not include presence subscriptions, only presence information that | is broadcasted to entities that are subscribed to a user's presence | information. Thus this includes presence stanzas with no 'type' | attribute or of type='unavailable' only. [ http://xmpp.org/extensions/xep-0016.html#protocol ] Holger ¹ This was discussed here: https://github.com/processone/ejabberd/issues/275
