Will BEEP Simplify Network Programming?

hensley writes "There is a (not quite) new effort by the IETF to standardize a framework for network applications, called BEEP, the Blocks Extensible Exchange Protocol. Standardized in RFC3080, it takes care of all lower level tasks an application level protocol has to like framing, authentication and capabilities negotiation in a modular and lightweight way. In the current issue of Internet Packet Journal (a quite nice and free-as-in-beer technical publication by Cisco) is a well written Introduction to this framework. Why isn't anyone adopting this protocol besides some Java libraries like beep4j and PermaBEEP and a C library called RoadRunner. I couldn't find any applications based on this protocol, regardless of it's promised capabilities. Is everybody still inventing his own application layer protocol?"

Comments

XML is too much sometimes

[Pauly]

I've played with BXXP/BEEP, and it is quite cool. Truly amazing P2P applications should be sprouting from its vines. However, the application that should be it's shining glory doesn't use it: Jabber. There must be someone out there in the jabber community that can expound on this.

Hanging my head in shame, I'm one of those "still inventing his own application layer protocols". ASN.1 and RPC were also supposed to save me from doing this. Lately, I've found I've been implementing my own protocols using the concept of netstrings to suit my admittedly low-level needs better. Sadly, as XML and its derivatives mushroom in complexity, I find them less appealing.

Re:Not so impressed

[Twylite]

I'm sorry, but I can't buy much of this at all.

BEEP is a ridiculous waste of time which equates to XML-encoded-TCP over TCP/IP. The many unsubtle problems that causes should be obvious; if they aren't, here are some:

• Multiple channels to a single endpoint: typically not useful without routing; few protocols require multiple data bands, and those that do usually require QOS in at least one band, in which case you want separate TCP/IP connections where QOS will (hopefully) be supported by routers between you and the server.
• XML protocol headers: Adds a massive amount of bandwidth and processing overhead, which achieve little if any benefit over a binary encoding. Contrary to popular bullshit, XML is not human readable (as if computers care about that), is not fast/efficient and is not programmatically simple to decode (2 grammars, 2 character encodings, 5 syntactically different data classes, and 2 orthogonal data models all in once specification with more BNF rules than C++!). The XML spec. states explicitly "Terseness is of minimal importance..." - certainly NOT what you want to use as header data on packets in a communication channel.
• Security: BEEP proides just another mechanism for hiding attacks, and requires a new application level firewall which must feature a full XML parser (in order to monitor and firewall individual channels within the protocol). Not only that ... you think that Unicode attacks are bad? With several years of development behind them, MS XML parser and Xerces STILL aren't fully XML 1.0 compilant -- how many security compromises do you think may be present with all the encodings XML supports, and how many will be present in the hundreds of less mature products?

You point out that SGML is a bad thing for encoding "at that level", but in the same breath say that XML is a good thing. Since XML is SGML-compatible, and largely employs the same syntax (but doesn't allow SGML short-cuts like leaving out closing tags), I fail to follow your argument.

And in your musings about the IETF, has it ever struck you that maybe the IETF also think that adding an incomprehensibly slow transport layer on top of an existing and widely supported transport layer is a shit idea? BEEP is NOT an application level protocol, even if it wants to claim to be one.

Re:Annoyed

[anshil]

I'm completly sharing your visions.

XML maybe very cool and ideal to store data, for config files and all that. How cool would be a completly XML based /etc directory?

However I don't see any real benefits for protocols.

In example what does XML-RPC do any good? Is conventional RPC suddendly uncool? What can XML-RPC do, what normal RPC can't? Except that it uses 5 times more bandwith.

It's just sad, if you type RPC in google, the first five links you get is all about XML-RPC. So marketing words can boost a whole technology? Nobody seems to remember what RPC itself is, and a lot of developers mismatch it today if you talk with them about RPC, you say hey why don't we use RPC? Instead of stuffing sockets ourself, and they start to talk about XML, RPC does not need XML at all.