[Standards-JIG] JEP-0017 Framing: Why was it rejected?

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Wed Oct 20 18:47:04 UTC 2004

On Wednesday 20 October 2004 10:47 am, Heiner Wolf wrote:
> Hi,
> > To Bob: the main argument against framing is probably just
> > that it makes the protocol less clean-looking.  The notion of a streamed
> > XML document that you can throw right at a SAX parser is compelling. 
> > Sure, it is possible to implement specs like JEP-0017 that graft on
> > framing, but how much sense does it make to skip over a piece of what is
> > supposed to be a continuous document?
> It makes sense in some applications. When the XMPP RFC news hit
> slashdot.org the only concern was that XMPP is not suited for large scale
> applications. Message routers must parse all traffic just to find
> destination addresses. Some people say that in order to process 10.000.000
> messages per minute (even distributed over many processors) you need to get
> to the destination address quickly. You need framing, because 10.000.000
> XML parsers cost way too much CPU. Maybe time and performace increases
> invalidate this argument. But it would be interesting to know what really
> is the bottleneck in todays very large messaging networks.

All I meant is that it doesn't make sense from an XML standpoint regarding 
xmpp-core's existing protocol, not that it wouldn't be useful.

Of course, this leads to the question: how useful is framing to XMPP?  Framing 
would allow you to skip the parsing of a stanza, either because you'd rather 
1) parse it later, or 2) not parse it at all (bit bucket).  Let's look at 

1) A server generally cannot trash a stanza without reading it, because the 
server either must reply to it or deliver it to a client.  One good reason to 
drop a stanza might be if it exceeds some size limit, but the server can 
terminate the connection then.

2) Allowing implementations to be able to decide when to actually parse a 
stanza (as opposed to being forced into on-the-fly parsing) would have been 
nice, at least in terms of flexibility.  However, I have yet to see a good 
argument as to how XMPP is not scalable without this.  You'd want to 
distribute parsing across your message routers anyway.


More information about the Standards mailing list