[Standards] RFC vs privacy lists

Matthew Wild mwild1 at gmail.com
Thu Apr 28 13:49:40 UTC 2011


On 28 April 2011 14:30, Yann Leboulanger <asterix at lagaule.org> wrote:
> Le 28/04/2011 15:20, Matthew Wild a écrit :
>>
>> On 28 April 2011 14:16, Yann Leboulanger<asterix at lagaule.org>  wrote:
>>>
>>> Le 28/04/2011 14:12, Remko Tronçon a écrit :
>>>>>
>>>>> I thought we had established "incoming" means incoming from the
>>>>> client's
>>>>> POV.
>>>>
>>>> Right, i actually meant the whole chain, up to and including the
>>>> server part (up to the stanza router).
>>>> It doesn't make sense to filter out stanzas from your own server (not
>>>> talking about the ones from other users on your server). But the XEP
>>>> could use some more specification of what "incoming" really is to
>>>> avoid this problem of shooting yourself in the foot.
>>>
>>> if that could be written in XEP-0016 that incoming iq is from a client to
>>> another client, or at least not from user's server to user, that would be
>>> perfect I think.
>>> And probably that "clients should not send iq get|set to jid that are
>>> blocked"
>>>
>>
>> Why not just clarify that privacy lists only block incoming iqs of
>> type "set"/"get"? Doesn't that solve everything in the least
>> surprising way?
>
> that would, yes, but isn't it a problem to be spammed with iq result|error?
>

What is there to gain by spamming someone with result/error? They can
never generate replies, so you can't use them to find someone's online
status. They'll be immediately discarded by the client (I hope) if
their id doesn't match a sent iq request.

Finally, the iq would not reach the client anyway - an unhandled iq
result/error would stop at the server unless it is sent to the full
JID. Your full JID is typically only known by people with access to
your presence, so that excludes people you have completely blocked.

It seems a non-issue to me.

Regards,
Matthew



More information about the Standards mailing list