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