Slashdot Mirror


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?"

1 of 195 comments (clear)

  1. Re:Not so impressed by Twylite · · Score: 5, Insightful

    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.

    --
    i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net