[standards-jig] JabberNG (Jabber over BEEP) (was: JEP-0017: Naive Packet Framing Protocol)

Iain Shigeoka iainshigeoka at yahoo.com
Fri Feb 1 19:20:51 UTC 2002

Hello all,

This is a short discussion starter on ideas for JabberNG (Jabber: Next
Generation) inspired by recent talk of Jabber packet framing and issues
brought up in the draft Jabber-RFC

We have identified several serious limitations with the Jabber protocols
that can prevent it from growing into roles beyond its current IM duties.
Most importantly in my opinion being the ability to transport arbitrary data
in-band.  In addition, several scalability problems may prevent it from
becoming as widely adopted as it could (see JEP-0017 and related list posts
for discussion on why Jabber framing is problematic.)

I took a few days off from Jabber to really dig into the BEEP protocols
(http://www.beepcore.org) as an alternative transport framework for building
Jabber systems.  If you are not familiar with BEEP I suggest reading the
protocol document.  BEEP is essentially a generic application transport
protocol that provides authentication, framing, multiple "channels" on one
connection, and other nice things.  I'm extremely impressed with the power
and simplicity of BEEP.  It is elegant.

So on to the discussion.  Having looked at APEX (the BEEP standard profile
for adding certain application protocols including IM and presence) I don't
think it is the best way of layering IM and presence (and a whole bunch of
other stuff) on top of BEEP.  I keep coming back to Jabber as a much better
protocol to put on top of BEEP.

I'd like to discuss the idea of implementing Jabber on top of BEEP.

Is it a good idea technically speaking?
What are the benefits and drawbacks from a non-technical standpoint?
Will it meet future needs?
Is it best as a JabberNG project, beep project, or completely new project?

-iain (troublemaker)

Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

More information about the Standards mailing list