Next group of problems:
1. In comments node how to ensure that a comment was posted by exactly
this man and a comment was not forged by a swindler? We have a
publisher attribute for an item documented in XEP-60 but still have no
full definition of it's behavior. So for now I think that client
Hi,
I have a problem with privacy list on an ejabberd server, and developers
are right to say there is a problem in the standards:
Let's say I configure a list to block all IQ for jid with
subscription=none (nice anti-spam rule).
Now I don't get any iq answer to, let's say, disco#info on my
That's normal because RFC [1] says that Privacy lists MUST be the first
delivery rule applied by a server, superseding ...
XEP 16 (copied from the RFC), section 2.14 says that the server should
return service-unavailable.
cheers,
Remko
XEP 16 (copied from the RFC), section 2.14 says that the server should
return service-unavailable.
And by 'should', i mean MUST.
cheers,
Remko
On 04/27/2011 08:02 PM, Remko Tronçon wrote:
That's normal because RFC [1] says that Privacy lists MUST be the first
delivery rule applied by a server, superseding ...
XEP 16 (copied from the RFC), section 2.14 says that the server should
return service-unavailable.
Really? I See the case
Let's say I configure a list to block all IQ for jid with
subscription=none (nice anti-spam rule).
Now I don't get any iq answer to, let's say, disco#info on my server.
That's normal because RFC [1] says that Privacy lists MUST be the first
delivery rule applied by a server, superseding
On 04/27/2011 09:04 PM, Kim Alvefur wrote:
Let's say I configure a list to block all IQ for jid with
subscription=none (nice anti-spam rule).
Now I don't get any iq answer to, let's say, disco#info on my server.
That's normal because RFC [1] says that Privacy lists MUST be the first
delivery
On 04/27/2011 10:00 PM, Remko Tronçon wrote:
If a user setup this rule it's because he doesn't want spam. And if server
don't block result|error, user can be spammed of iq result for ex
According to xep-0016:
The allowable child elements are:
message/ -- blocks incoming message stanzas
iq/
So a client is not allowed to send an iq to its server if this anti-spam
rule is set?
I'm not quite following why it's not ok to send an iq to your own server?
The XEP says that privacy lists block *incoming* IQs (that is,
'incoming' from the point of view of the client, so from other
entities
On 04/27/2011 10:42 PM, Remko Tronçon wrote:
So a client is not allowed to send an iq to its server if this anti-spam
rule is set?
I'm not quite following why it's not ok to send an iq to your own server?
The XEP says that privacy lists block *incoming* IQs (that is,
'incoming' from the point
Am 27.04.2011 23:28, schrieb Yann Leboulanger:
On 04/27/2011 10:42 PM, Remko Tronçon wrote:
So a client is not allowed to send an iq to its server if this anti-spam
rule is set?
I'm not quite following why it's not ok to send an iq to your own server?
The XEP says that privacy lists block
On Apr 20, 2011, at 09:35 , XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: JSON Content Type support
Abstract: This specification defines JavaScript Object Notation (JSON) use in
XMPP service.
URL:
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
13 matches
Mail list logo
