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

Iain Shigeoka iainshigeoka at yahoo.com
Mon Feb 4 21:09:20 UTC 2002

On 2/2/02 4:17 PM, "Dave Smith" <dizzyd at jabber.org> wrote:

> On Fri, Feb 01, 2002 at 11:20:51AM -0800, Iain Shigeoka wrote:

>> I'd like to discuss the idea of implementing Jabber on top of BEEP.
> Oy. You just want to start a discussion? That's like setting someone on
> fire to help them get warm.. :)

:)  Well, subtly is definitely not my strong suit!  :)

> In all seriousness, I think this is actually a good place to start the
> discussion. I've gone over BEEP in the past and found it to be a little
> more complex than what we have needed. However, there is a _lot_ of
> interest in a secondary transport for Jabbber, so I suppose we should
> take it to task.


>> Is it a good idea technically speaking?
> Well, technically BEEP is pretty decent; complicated, but thorough.
> Personally, I classify it as a "cathedral" -- something so good, yet so
> complex that most people have a hard time using it.
> Now, this is just my personal opinion, but I think one of the reasons
> that Jabber has survived as long as it has, is due to it's weaknesses
> (technically speaking). I mean, we _don't_ have binary transport,
> framing, or anything. But..the popularity of Jabber has taken off --
> mostly because it's dang simple. I write XML out to a socket and read it
> off the socket. 
> It's my belief that this characteristic of simplicity is something we
> must embrace and keep even as we move to more complex
> protocols/transports. Another way of looking at it is that Jabber solves
> problem in a JIT manner. However, I digress...
> I don't want to use BEEP -- it's too...much. I'm all for taking the
> lessons learned in it and re-applying those to Jabber.

Granted.  I can see your point of view on this.  What I'd like to do is
approach this from a slightly different perspective though.  Let's imagine
BEEP is like TCP, a transport we assume exists and works.  If we put a
simplified programming interface on it like Sockets programming does for
TCP, then accessing BEEP should be about as simple as accessing TCP, e.g.
open, write, read, close.

I just downloaded the Java beep-core stuff so I don't know if it is more on
the TCP or socket level yet.  However, if it is not, we could create a
simplified programming interface that will meet Jabber developer's needs.  I
imagine the same could be true for the C and other BEEP libraries.  Since
this should only need to be done by a very limited number of people I don't
think this is a very big stretch.  And very few will program BEEP directly,
just as very few people program TCP directly.  When was the last time you
generated TCP headers... :)

I agree that we could create a simplified just for Jabber but if we can
build on existing BEEP code, we may be able to avoid having to deal with the
entire transport layer.

Notice that I"m talking about raw BEEP here and _not_ APEX!

>> What are the benefits and drawbacks from a non-technical standpoint?
> Well, this may sound harsh, but I haven't exactly seen BEEP as a project
> which has succeeded. I'm a little wary of adopting a project that so
> many people don't use.

Agreed.  The adoption has been pretty slow and the development community is
very quiet.  However, I think there is a lot of power on building on top of
an IETF standard rather than pioneering _everything_ ourselves...  And this
could actually be a strength in our favor.  If the Jabber community backs
BEEP, the BEEP protocols will go from a pretty quiet little standard into a
major internet standard.  Creating Jabber BEEP experts seems like a positive
for Jabber developers.

>> Will it meet future needs?
> The more immediate question, is what do we need right now? I'm all about
> planning for the future, but let's not get ahead of ourselves.  What
> problems need to be solved in the near-term? Jabber has always been on a
> curve along the lines of 3-9 months (IMHO, again). We solve immediate
> problems, but we put thought into the flexibility and vitality of the
> design.

Agreed.  My impression is scalability and security are the major fires to be
put out at the moment.  Scalability mostly from ISPs and security from
people looking at enterprise applications of Jabber technology.

BEEP's framing would seem to really help scalability of server
implementations.  At least if we designed the Jabber layer correctly to
exploit BEEP frames.

And the combination of transport security via SASL, and framing opens up the
door to a more flexible security infrastructure, as well as the ability to
easily accommodate arbitrary packet encryption (you can easily toss in
binary blobs of encrypted data into a BEEP frame.)

>> Is it best as a JabberNG project, beep project, or completely new project?
> *shrug*
> Looking back at this email, I hope my remarks aren't too inflammatory --
> they're just some personal opinions. That doesn't make them hills for me
> to die on.. :)

No no no.  This is exactly the kind of thing I want to hear.  I am getting
the feeling that this is a pretty big break from the status quo and we may
be best served by spinning this off into another project.  Then if it is
chosen as a JNG candidate, merge it back under the auspices of the Jabber

Redesigning the transport layer is traumatic enough that everything from
servers to chatbots to clients are going to need to be rewritten.  From a
developer-relations standpoint that is pretty uncool...



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

More information about the Standards mailing list