[Standards] Blocking command and Privacy Lists

Kurt Zeilenga kurt.zeilenga at isode.com
Mon Dec 22 13:31:16 UTC 2014


> On Dec 21, 2014, at 5:19 PM, Sam Whited <sam at samwhited.com> wrote:
> 
> Hi all,
> 
> 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).

Yes, the expected behavior of a 191 request should be all stanzas to/from the specified JID are blocked.

> 
> However, Gajim (and possibly other clients that use privacy lists) seems
> to block everything but presence information.

> 
> 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).

I don’t see why a user who says “block this jid” would expect all communications to/from that JID not be blocked.


> 
> 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. …

I oppose this suggested change to XEP 191.

I think if anything in XEP 191 needs to change, it’s the discussion of how one maps XEP 191 onto XEP 4 privacy lists that should change.  It should be clearly stated that the blocking entity is required to perform the mapping in such a way that all communications with the blocked JID are blocked.

— Kurt

> 
> Best,
> Sam
> 
> -- 
> Sam Whited
> pub 4096R/54083AE104EA7AD3
> https://blog.samwhited.com
> 




More information about the Standards mailing list