[Standards] RFC vs privacy lists

Florian Zeitz florian.zeitz at gmx.de
Wed Apr 27 22:24:38 UTC 2011


Am 27.04.2011 23:43, schrieb Florian Zeitz:
> Am 27.04.2011 23:28, schrieb Yann Leboulanger:
>> No, the outgoing iq is not blocked, but the reply is.
>> So a client sends an iq, but nver get an answer, which is against the
>> RFC.
>>
> As you pointed out yourself, and as Remko has pointed out is defined in
> XEP-0016 on decent servers the client DOES get a reply. A
> service-unavailable reply, but still a reply.
>
> You are in fact right that privacy lists allow you to shoot yourself in
> the foot in this regard. If you block all incommig IQs ALL of them are
> going to be blocked, including the ones from your server. If that's not
> what you want whitelist the server, I'm not really sure what the problem
> is.

<opens mouth, inserts foot>

Okay, so I see where you're coming from now. And it is in fact a problem.
Strictly following XEP-0016 when a client sends a type get/set IQ to 
it's server, the server should send itself an error IQ and the client 
would never see an answer.
Now, one might argue that expecting an answer from someone you have 
blogged from sending you one is a stupid idea. That's not entirely 
wrong, but still clashes with the RFCs.
The easiest way to fix this (IMHO) is probably to send the user a type 
error IQ whenever he is trying to send a type get/set one to a JID that 
is blocked from answering.
That does not fix your problem however and I maintain that the solution 
to that is to allow entities that you want to receive IQs from to send 
you IQs :).



More information about the Standards mailing list