[Jabber-IETF] Agenda items
ben at blahr.com
Mon Oct 7 12:49:03 CDT 2002
-----BEGIN PGP SIGNED MESSAGE-----
Pete Chown wrote:
| Iain Shigeoka wrote:
|> BTW, Pete, you may be interested in the JNG (Jabber: Next Generation) and
|> Jabber Framing discussions we had in standards-jig about a month or so
| Can I read a summary of this work somewhere?
I'm not sure if there's a summary of the discussions that took place on
the standards-jig discussion, but you can find the original post (that
sparked the debate) at:
That post began a rather heated debate and several related threads. In
addition, that post contains a link to the framing prototypes developed
by Mike Lin.
| Do you think this work should be included in the RFCs that we prepare?
| Are we going to be specifying Jabber as it is used right now, or
| developing a new revision of the Jabber protocol?
This is an extremely controversial subject within the community. There
are many people within the community (myself included) who feel that
there are more important issues to work out in the protocol than speed.
Frankly, I think the goals currently outlined in the WG charter are
rather ambitious, considering the tight timeframe we are currently
It is my opinion that JNG as nothing more than a set of ideas of how the
core protocol (as low as the transport layer) could be optimized for
better performance. It is my opinion that some of the proponents of
these ideas are ignoring the simple solutions, and suggesting
optimizations that ignore the simple elegance that is XMPP. The has been
no definitive proof that these optimizations are necessary.
Implementations of the protocol have been proven to be highly scalable,
despite the fact that the protocol uses XML at the network level. There
have been many tricks employed by developers of different related
software packages that have been employeed to achieve this scalability,
but the protocol still remains simple enough that even novice developers
can implement it.
I question the circumstance under which it would be better to develop a
binary protocol that preemptively precludes developers from being able
to contribute to the community, in order to offer an unquantifiable
Regardless of all of the above, I believe that any of these discussions
are outside the scope of the goals currently outlined.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the xmppwg