[Standards] XEP-0016, blocking incoming IQs - interpretation problem

Florian Schmaus flo at geekplace.eu
Fri May 8 13:13:19 UTC 2020

On 5/8/20 2:55 PM, Bartłomiej Górny wrote:
> On 08/05/2020 14:34, Florian Schmaus wrote:
>> On 5/8/20 12:41 PM, Bartłomiej Górny wrote:
>>> Hello
>>> We have a question, how exactly should a privacy list behave if it is
>>> set up to block all incoming IQs. Namely: should it block all incoming
>>> iqs whatsoever (including iq responses to the user's iq requests sent to
>>> the server, iq pushes from the server etc), or only iq stanzas sent by
>>> other users (entities with non-empty localpart other then the user's
>>> own)?
>>  From xep16:
>> <iq/> -- blocks incoming IQ stanzas
>> so this means all IQ stanzas, independently of their type.
> Thanks for answering. We are not wondering about types of iqs, though,
> but about senders. If we block iqs from an entity it is quite clear that
> it should block get, set etc. The question is basically, how to
> interpret example 44. Should a global block on iqs block stanzas from
> other users only, or from all entities - users, servers, my server, my
> server account?

Ahh, yes, the dreaded example 44.

Strictly following the XEP would mean that you will not even get IQ
responses from any subsequent privacy-list related IQ request. Or any
other IQ from the service.

I personally think that servers implementing xep16 should *always* allow
stanzas from themself (not sure if this includes internal components
though, I think not). That is why I have created


6 years ago.

I'd love to get that clarification into xep16 too. But someone™ needs to
do it.

- Flroain

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200508/93a02ed4/attachment.sig>

More information about the Standards mailing list