[Standards-JIG] JEP-0017 Framing: Why was it rejected?
jean-louis.seguineau at antepo.com
Thu Oct 21 13:11:19 UTC 2004
Well David, I tend to disagree with this statement. I believe we have to
leave the end user decide if using XMPP is adequate for a certain
application by presenting the proper pros and cons for each usage.
In certain cases, the end user may take the 'educated' decision to allow for
faster switching at a router level and keep the full blown well-formedness
checking to another point in the resulting XMPP network. It all depends of
the end goal of the specific application that uses XMPP, and as long as we
provide the proper information, then in many cases XMPP will be a more than
adequate answer in its present form.
It also means that the implementation of XMPP routers should be built in a
way that leave the user decide how to use them. You are raising a good
point, but maybe some application context will not require this control to
be enforced at every node in the resulting XMPP network.
I would also be very interested by hard facts, and I appreciate Peter's post
in this regards. I also concur to say XML processing is also the least of
our worries. I also would need to be seriously convinced that a box can't
route packets fast enough. I also agree that the real overhead is coming
from enforcing a plethora of business logic rules.
So in the meantime, I still believe that XMPP can provide a very compelling
answer to many large scale applications.
Director, product Engineering
Chief Software Architect
Antepo, Inc. ( www.antepo.com )
Date: Wed, 20 Oct 2004 15:20:18 -0600
From: David Waite <dwaite at gmail.com>
Subject: Re: [Standards-JIG] JEP-0017 Framing: Why was it rejected?
To: Peter Millard <pgmillard at gmail.com>, Jabber protocol discussion
list <standards-jig at jabber.org>
Message-ID: <3eb0429d041020142041f3bd32 at mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII
On Wed, 20 Oct 2004 15:11:33 -0600, Peter Millard <pgmillard at gmail.com>
> As a related side note... if you just want something that routes
> packets, you definitely don't need a full-blown XML parser.. All you
> need is an "angle-bracket parser", and strstr to find the to= bits.
Not true, you have to do well-formedness checking as a router;
otherwise you can do a denial of service by exploiting correct xml
behavior in the recipient (disconnecting on receipt of non-well-formed
Besides, there are several places where both angle brackets can be
included without contributing to element nesting; inside attributes,
comments, and CDATA.
More information about the Standards