[ejabberd] in-order delivery

Peter Millard pgmillard at gmail.com
Mon Mar 13 18:08:24 MSK 2006

ID attributes on iq elements are provided so that an entity can do
async tracking of a request response transaction with-out having to
block. This allows a client to possibly do other things (could be GUI
operations, could be XML stream ops) while waiting for a response.

I guess what I do not understand, is how are you interpreting this
part of RFC 3920:

10. Server Rules for Handling XML Stanzas:
Compliant server implementations MUST ensure in-order processing of
XML stanzas between any two entities.

The two entities in question in my examples are a full user jid
(pgm at jabber.org/foo) and the server (jabber.org). Chatting with Alexey
on Friday I found out that basically ejabberd uses different
processing queues depending on the type of packet that is delivered.
So if a presence packet comes in, it goes to queue A, if a roster
packet comes in, it goes to queue B, if an iq:privacy packet comes in,
it goes to queue C. Using this architecture, how are you complying
with the in-order *PROCESSING* requirement of section 10? If queue C
is not heavily loaded, it will clearly be processed before my presence
packet in queue A.

Does this articulate the problem any more? I don't understand how you
can say that this "should not" be a requirement since the client can
just do the right thing. Sure clients can block and wait for the
response, but according to this requirement in the RFC, they shouldn't
have to. The fact of the matter is, that it *IS* a requirement in
3920, and it's specified as a MUST.

This hasn't stopped jabber.org from using ejabberd, it just *really*
concerns me from a compliance standpoint (ejabberd is claiming to be
100% XMPP compliant). I would like to see it addressed in future
ejabberd releases.

I do understand that this is probably a problem with the core
architecture of how things work in ejabberd, and I do realize that
it's not easy to fix :) I'm not looking for a fix right away, I'm just
looking for someone on the ejabberd team to acknowledge that this
really is a problem.
At this point, it seems like everyone is just blowing me off, and
saying "make the client do the right thing". How about we comply with
the RFC instead?


On 3/9/06, Mickael Remond <mickael.remond at process-one.net> wrote:
> * Sergei Golovan <sgolovan at nm.ru> [2006-03-09 08:58:00 +0300]:
> > On Wed, Mar 08, 2006 at 07:44:48PM -0700, Peter Millard wrote:
> > > The roster versus presence problem isn't nearly as bad as processing
> > > jabber:iq:privacy packets. If a client sends an iq-set which enables a
> > > privacy list, then I send some other packet, the iq-set for the
> > > privacy list MUST be enabled before my second packet is processed.
> > > This is one of the reasons that RFC says that an entity must *process*
> > > the packets in order.
> >
> > As I said in one of the previous messages in this thread, if you really want
> > use privacy lists for security and not for listing "privacy lists" in client
> > features then you must check server reply before sending another packet.
> >
> > Do you really think that after getting an error reply from the server (except
> > probably feature-not-implemented) one may act the same as if the reply was OK?
> I think Sergei has a good point here.
> My understanding was that if a behaviour is important he has everything
> to check that his IQ has been processed. I thought this is why the iq id
> attributes was for: To allow the client to match the result of an IQ
> request.

More information about the ejabberd mailing list