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

David Waite dwaite at gmail.com
Thu Oct 21 00:18:15 UTC 2004


On my long list of advantages of a non-xml framing protocol, speed
didn't even make it.

1. You could push well-formedness checking of xml off to the endpoints
(or the component doing XMPP-core protocol translation)
2. Easier message validation and rejection.
3. Messages could be split up on arbitrary binary boundaries, rather
than requiring full stanzas. Currently, a client can only receive one
stanza at a time, and a client's only option for rejecting a stanza
due to size is to close the connection.
4. You can actually use off the shelf XML tools, rather than having to
hunt down or cobble together a push/pull parser that doesn't do
internal buffering, writing your own DOM or cobbling together creation
code based on the push/pull parser events, writing your own
serialization code to deal with the namespace funkiness...
5. Stanzas could be Xml documents,rather than quasi-documents existing
as top-level elements in a framing document.
6. If the routing information is on the frame rather than in the
message, you can have clear separation of user content and routing
requirements/values (rather than embedding extra routing information
as an extension within message bodies)
7. If the body is treated opaque, you could actually support in-band
digital signatures and encryption for 'standard' xml end-to-end
encryption (without base-64 encoding, as you usually have to do now,
based on your transformation setup).
8. If the body is treated as 8-bit safe opaque, you can do in-band
transfers without base64 encoding.

On Wed, 20 Oct 2004 19:47:48 +0200, Heiner Wolf <wolf at bluehands.de> wrote:
> 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.



More information about the Standards mailing list