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

Bob Wyman bob at wyman.us
Thu Oct 21 20:50:10 UTC 2004


	Between the comments on this list and various offlist messages, I'm
beginning to get some sense of why JEP-0017 was rejected. However, I'm also
getting a strong sense that many of the "issues" that are being raised are
either orthogonal or otherwise not compelling.
	A few comments:
	1. Arguments that oppose framing because it is "hard" to do or
because the extra framing information would "break XML" are irrelevant. My
assumption is that if a framing extension was defined for XMPP, it would be
enabled via the stream initiation mechanism (JEP-0095) or as a
stream:features (RFC3920), neither of which existed when JEP-0017 was being
considered. Since framing would thus be optional, anyone who had difficulty
implementing it or wished to use unmodified XML parsers could simply ignore
it. However, those who were capable of implementing framing and saw value in
it would be able to use it.
	2. The issues of framing and routing are being mixed together
inappropriately in this discussion. The issues are orthogonal. It is
entirely possible to define a robust framing extension that has no direct
impact on the ease of routing XMPP packets. It is also possible, but
probably more disruptive, to make changes to increase the route-ability of
XMPP packets without introducing framing. The issues should therefore
probably be dealt with separately. (Framing alone might, for some
applications, allow the development of generally higher throughput XMPP
processors. XMPP Routers are only one class of XMPP processors that might
benefit from framing.)
	3. Arguments that "processors are fast and getting faster thus
framing isn't necessary" are at best focusing on only part of the user
community -- admittedly, at present, the largest part. It may be that most
developers, who have relatively light throughput requirements, can rely on
hardware to provide the power they need to overcome any inefficiencies that
might exist in their code, however, very large or otherwise demanding XMPP
implementations will always be able to benefit from an improvements in
either software or protocol that allow more efficient utilization of
resources. 
	My guess is that the average XMPP installation today probably
requires much less power then the average hardware box delivers. However,
there are some who are trying to build XMPP applications that will handle
millions of simultaneous connections. Even small percentages of efficiency
improvements in large installations can justify or compel large amounts of
investment...
	4. Arguments that say that the insertion of "non-xml" textual
framing information between XMPP stanzas somehow "breaks" or violates the
rules of XML are simply wrong. The whole point of XMPP is that you have a
single "document" which is the <stream/> and that document contains stanzas.
Any data which appears between stanzas is simply content of the <stream/>
element.  While non-stanza data might break XMPP rules (I'm not sure.) its
presence certainly doesn't break any rules of XML itself as long as the
interspersed text conforms to the encoding rules for the stream.
	5. Observations such as "XML processing has not historically been a
problem for XMPP processors" or "Framing hasn't been needed in the past" are
interesting but not relevant to a discussion of the need for framing in the
future. The reality is that Jabber/XMPP has historically only been used for
a single application -- instant messaging, and IM applications are well
known to present very light server loads per connection. In particular, IM
messages are typically so small that they can be contained in only one or a
very small number of TCP/IP packets and the per-stream stanza transmission
rate is so low that there will typically be only a small number of
simultaneous in-transit stanzas at any one moment (and thus a need for only
a small number of simultaneous XML parse contexts). However, if XMPP is to
be used in other non-IM applications, we will see very different usage and
load patterns that are more typical of applications that *have* been proven
in the past to benefit greatly from framing in protocols. 
	Just a few comments... I would still appreciate hearing any other
comments on why JEP-0017 and similar ideas for framing in XMPP might have
been rejected in the past.

		bob wyman





More information about the Standards mailing list