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

Ian Paterson ian.paterson at clientside.co.uk
Fri Oct 22 18:09:20 UTC 2004

> I am very well aware that my expectations may be a
> bit drastic and old-fashioned... I'm an "old-fart" that grew up in
> an environment in which hardware resources were very expensive...

Me too. I understand and share your pain. :)

> Many, many techniques for increasing or smoothing throughput simply
> don't seem to be useable with such a protocol. This is disturbing.

I agree. Although we still have to prove this is a significant bottle-neck
in real-world applications.

> In part, my questions about JEP-0017 are an attempt to gain some
> insight into the thinking that might have influenced the choices
> made in writing JEP-0124. [snip]
> The similarity between the rejected JEP-0017 framing and HTTP 1.1
> framing is interesting since JEP-0124, while it claims to prefer
> HTTP 1.1, does not take the "obvious" step of exploiting chunked
> encoding.

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)" which sends a complete HTTP POST request, and
a high-level event listener like "receive(XMLstring)" which only fires after
*all* the chunks of the response have been received.]

That said, we should avoid burdening server implementors with multiple new
XMPP stanza transports (like JEP-0017 and JEP-0124) unless they are strictly
necessary. IMHO a single multi-purpose transport is an attractive idea.

As Bob pointed out, HTTP 1.1's chunked encoding (RFC2068 Section 3.6) makes
it easy to merge relatively efficient stanza framing into JEP-0124 without
radical changes.

As the primary author of JEP-0124, I would support the inclusion of OPTIONAL
chunked encoding *if* people think this is a good way to optimise the
processing of XMPP stanzas. It certainly would be nice to give server
implementors another good reason to implement JEP-0124.

More information about the Standards mailing list