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

Bob Wyman bob at wyman.us
Fri Oct 22 20:01:13 UTC 2004

Ian Paterson wrote:
> Chunked encoding certainly would make JEP-0124 even more efficient.
> However, the motivation for JEP-0124 was to enable clients running
> in constrained environments to send and receive XMPP stanzas. ...
> Unfortunately these restricted runtime environments eliminate the
> advantages of chunked encoding. [Their APIs are typically limited
> to a high-level method like "post(XMLstring)"
	Yes, I can see that.

	What I was thinking of was something different... i.e. an attempt to
accomplish three goals:
	1. Bring minimal framing to XMPP
	2. Allow efficient, firewall-piercing implementation of
	   XMPP over HTTP
	3. Make XMPP over raw TCP/IP virtually indistinguishable from XMPP
	   over HTTP.

	Imagine if JEP-0017 was redefined as HTTP 1.1 chunk transfer
coding[1]. Then, imagine a new JEP or an addition to JEP-0124 that defines
"XMPP over HTTP" for "non-challenged clients" as not much more then "Use
chunks!". If these two things happen, the only real difference between "XMPP
over TCP/IP" and "XMPP over HTTP" would be that in the HTTP case, you would
prefix the <stream/> element with HTTP request/response headers. All other
aspects of the protocol would be identical. For both transports, you would
be receiving multiple stanzas per connection -- unlike what JEP-0124 calls
for today. Once you got past the HTTP request/response headers, the code
needed to process XMPP streams would be identical. (Note: You would probably
want to also include the sid[2] from JEP-0124 when running over HTTP.)
	Both HTTP 1.1 servers and clients are already required to support
chunk encoding for either requests or responses. Also, as a result of
mod-pubsub[3] and the products of KnowNow[4], there is already a substantial
body of experience with streaming protocols over HTTP 1.1 connections.
Mod-pubsub/KnowNow is already being successfully used in a number of
enterprises and on the open Internet for a variety of applications.[5]
	I think it would be very nice to be able to use virtually identical
code for "XMPP over TCP/IP" and "XMPP over HTTP" while also getting minimal
framing (chunk support) in XMPP...

		bob wyman

[1] http://www.ietf.org/rfc/rfc2616.txt 
	See 3.6.1 Chunked Transfer Coding
[2] SID= Session ID
[3] http://www.mod-pubsub.org/blog/index.php
	The mod-pubsub.org site seems to be broken this week...
[4] http://knownow.com/
[5] See the mod-pubsub RSS streamer:

More information about the Standards mailing list