[December 06, 2001] "BEEP is a new Internet standards-track protocol framework for new Internet applications. BEEP as an Application Protocol Framework is a turbocharger for Internet applications that offers advanced features such as: (1) a standard application layer that supports dynamic, pluggable application 'profiles' [protocols]; (2) peer-to-peer, client-server, or server-to-server capabilities; (3) multiple channels over a single authenticated session; (4) support for arbitrary MIME payloads, including XML; (5) a standard layer for session management..." [beepcore.org description]
IETF RFC 3080 'The Blocks Extensible Exchange Protocol Core' "describes a generic application protocol kernel for connection-oriented, asynchronous interactions called BEEP. At BEEP's core is a framing mechanism that permits simultaneous and independent exchanges of messages between peers. Messages are arbitrary MIME content, but are usually textual (structured using XML). All exchanges occur in the context of a channel -- a binding to a well-defined aspect of the application, such as transport security, user authentication, or data exchange. Each channel has an associated "profile" that defines the syntax and semantics of the messages exchanged. Implicit in the operation of BEEP is the notion of channel management. In addition to defining BEEP's channel management profile, this document defines: (1) the TLS transport security profile; and, (2) the SASL family of profiles. Other profiles, such as those used for data exchange, are defined by an application protocol designer..." XML DTDs include (1) BEEP Channel Management DTD, (2) TLS Transport Security Profile DTD, and (3) SASL Family of Profiles DTD"
[September 06, 2000] Several IETF Internet Draft documents describe the 'BEEP' ['BXXP'] Framework (Blocks eXtensible eXchange Protocol Framework).
Blocks eXtensible eXchange Protocol (BXXP, a.k.a. BEEP) is a protocol framework being developed under IETF rules. "A working group of the Internet Engineering Task Force (IETF) has been tasked with submitting revised specification to the Internet Engineering Standards Group (IESG) for consideration as a standards-track publication. Using BXXP as a framework for application protocols has these advantages: (1) All of the tips and tricks of experienced protocol designers are freeze-dried into a unified programming framework that can be used over and over again. (2) It is an application protocol framework for connection-oriented, asynchronous request/response interactions. (3) BXXP handles all the dirty work of initiating connections, framing, managing security, and multiplexing multiple channels in a single authenticated connection, freeing developers to work on adding new application features. (4) The protocol is designed for extensibility through the use of profiles that "snap into" the BXXP framework. (5) Security profiles enable the reuse of security and authentication mechanisms among multiple applications. (6) Data communication profiles make it easy to determine the messages applications must exchange. (7) Profiles can be easily created and customized to quickly develop new Internet applications."
[December 31, 2001] See also the proposed "ANTACID Replication Service." Described in two IETF Internet Draft documents, the ANTACID Replication Service specifies a protocol and algorithms "designed to replicate hierarchically named repositories of XML documents for business-critical, internetworked applications." The protocol is defined in terms of a BEEP profile. XML DTDs are presented in appendices of the 'Protocol and Algorithms' document.
References:
Beepcore.org - A community portal for developers of applications using BEEP
The Blocks Extensible Exchange Protocol Core. Request For Comments: 3080.
- "Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP)." April 2003.
BEEPwg -- Mailing list for the IETF's BEEP working group 'beepwg@lists.beepcore.org'
"The Facts On BEEP." BEEP FAQ document. By D. New. March 29, 2001 or later. Discusses why it is useful to use BEEP and situations for which it is inappropriate. [Consider that] Internet protocols reinvent a set of basic functions, including: (1) Separating each request from the next, (2) Matching responses to requests, (3) Permitting multiple outstanding requests (pipelining), (5) Permitting multiple asynchronous requests (multiplexing), (6) Reporting errors, (7) Negotiating encryption, and (8) Logging in users. BEEP specifies reusable tools for all of these functions, instead of requiring the same decisions to be made over again for each new application. BEEP provides a framework that integrates existing Internet standards for encryption and authentication and new standards for connection management..."
[July 21, 2003] "The Security Components Exchange Protocol (SCXP)." By Yixian Yang (Information Security Center, Beijing University of Posts and Telecom, BUPT). IETF Internet Draft. Reference: draft-yang-scxp-00. June 2003, expires December 2003. Section 7 supplies the SCXP XML DTDs (SCXP DTD, channelType Option DTD, channelPRI Option DTD). "This document describes the Security Components Exchange Protocol (SCXP), an application-level protocol for exchanging data between security components. SCXP supports mutual-authentication, integrity, confidentiality and replay protection over a connection-oriented protocol. SCXP is designed on Blocks Extensible Exchange Protocol (BEEP), and it can be looked upon a profile of BEEP in a way. BEEP is a generic application protocol framework for connection-oriented, asynchronous interactions. Within BEEP, features such as authentication, privacy, and reliability through retransmission are provided. A chief objective of this protocol is to exchange data between security components..."
[April 30, 2003] "Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP)." By Ward K. Harold (IBM, Austin, Texas). IETF Network Working Group, RFC. Reference: Request for Comments #3529. Category: Experimental. April 2003. 15 pages. "XML-RPC is an Extensible Markup Language-Remote Procedure Calling protocol that works over the Internet. It defines an XML format for messages that are transfered between clients and servers using HTTP. An XML-RPC message encodes either a procedure to be invoked by the server, along with the parameters to use in the invocation, or the result of an invocation. Procedure parameters and results can be scalars, numbers, strings, dates, etc.; they can also be complex record and list structures. This document specifies a how to use the Blocks Extensible Exchange Protocol (BEEP) to transfer messages encoded in the XML-RPC format between clients and servers... The BEEP profile for XML-RPC is identified as http://iana.org/beep/transient/xmlrpc in the BEEP 'profile' element during channel creation. In BEEP, when the first channel is successfully created, the 'serverName' attribute in the 'start' element identifies the 'virtual host' associated with the peer acting in the server role... In XML-RPC Message Exchange, a request/response exchange involves sending a request, which results in a response being returned. The BEEP profile for XML-RPC achieves this using a one-to-one exchange, in which the client sends a 'MSG' message containing an request, and the server sends back a 'RPY' message containing an response. The BEEP profile for XML-RPC does not use the 'ERR' message for XML- RPC faults when performing one-to-one exchanges. Whatever response is generated by the server is always returned in the 'RPY' message. This memo defines two URL schemes, xmlrpc.beep and xmlrpc.beeps, which identify the use of XML-RPC over BEEP over TCP. Note that, at present, a 'generic' URL scheme for XML-RPC is not defined... The IANA has registered the profile specified in Section 6.1, and has selected an IANA-specific URI http://iana.org/beep/xmlrpc..." See "Blocks eXtensible eXchange Protocol Framework (BEEP)."
[October 18, 2002] "Beep BEEP!" By Rich Salz. From XML.com (October 16, 2002). ['In this month's XML Endpoints column Rich Salz concludes his look at methods for transporting binary data in SOAP, with an examination of BEEP. Rich ends with a plea to Microsoft's Don Box to consider BEEP to overcome the limitations of HTTP in web services.'] "This article is the last in a series examining how one might go about sending binary data as part of a SOAP message. This month we look at BEEP, the Blocks Extensible Exchange Protocol. The primary inventor of BEEP is Marshall Rose, a long-time 'protocol wonk' within the IETF community. Marshall has authored more than 60 RFC's, covering everything from core SNMP details to a DTD for IETF RFCs. Like SOAP 1.2, BEEP is described in a transport-neutral manner and is defined in RFC 3080. The most common transport is TCP, and the TCP mapping is found in RFC 3081... BEEP actually addresses a wider range of problems than just SOAP and binary data. According to the RFC, BEEP is 'a generic application protocol kernel for connection-oriented, asynchronous interactions.' In other words, it's like an application-level transport protocol. Unlike many application protocols, it supports more than just lockstep request-response interchanges, which makes it suitable for applications such as event logging (see RFC 3195, for 'Reliable Syslog'), and general peer-to-peer interactions. One of the more interesting implications of BEEP's design principals is that it supports multiplexing -- that is, multiple channels communicating over a single transport stream. BEEP allows different applications, or multiple instances of the same application, to use the same stream for independent activities, including independent security mechanisms. For example, a single BEEP-over-TCP link between a browser and a web server would efficiently allow the browser to fetch a page over SSL-encrypted HTTP, while also streaming in multiple images over unencrypted HTTP. A BEEP message is the complete set of data to be exchanged. BEEP defines three styles of message exchange, distinguished by the type of reply the server (or, more accurately, the message recipient) returns: (1) Message/reply, the server performs a task, and sends a positive reply back. (2) Message/error, the server does not perform the task, and sends a negative reply back. (3) Message/answer, the server sends back zero or more answers, followed by a termination indicator. This style is appropriate for streaming data, for example..."
[May 07, 2002] "XML Watch: Worm's-eye BEEP. Part 2 of An Introduction to the Blocks Extensible Exchange Protocol Standard." By Edd Dumbill (Editor and publisher, xmlhack.com). From IBM developerWorks, XML zone. March 2002. ['In this second article examining BEEP -- Blocks Extensible Exchange Protocol -- Edd builds on the broad principles of BEEP outlined in his previous article, explaining how the protocol is implemented, and providing an example of how it is used in Java.'] "BEEP is a peer-to-peer protocol framework. It isn't as much a ready-made protocol in itself, like HTTP, but a framework on which such protocols can be built. It takes care of many of the features of such protocols so that they don't need to be reinvented. The main areas of functionality are: (1) Separating one message from the next; (2) Encoding messages; (3) Multiple channels of communication over a single connection; (4) Reporting errors; (5) Negotiating encryption; (6) Negotiating authentication. In the previous article, I explained that communication in a BEEP session takes place over one or more channels, which are multiplexed over the transport protocol. I will assume that, per RFC 3081, we're using BEEP over TCP/IP. This need not be the case: A mapping of BEEP could be made onto a different connection-oriented transport protocol. The first channel, channel 0, has a special role and is used for session management. All communication over a channel is defined by a profile, which is basically a description of permissible interactions. For XML-based protocols, a profile could be based around a DTD or schema that specifies the syntax for messages. (Obviously, more than just syntax specification is required to completely define the profile.) When peers connect using BEEP, they request profiles of each other in order to structure their communication. Profiles fall into two categories: tuning and data exchange. Tuning profiles affect the whole session and are typically responsible for security and authentication. A data exchange profile, as indicated above, defines the exchanges on a particular channel... Now that you have a high-level idea of what BEEP does, let's swoop down to the other extreme and investigate how the fundamentals of the protocol are implemented... BEEP offers the Internet protocols world, which includes the growing area of Web services, a plausible alternative to the continued overloading of HTTP. Its flexible nature and deep-rooted support for MIME means it should adapt well to connection-oriented protocol needs. The number of freely available implementations of BEEP is steadily increasing, as is the BEEP user community. Developers creating new application protocols should seriously consider using BEEP as the substrate for their work." See also the abstract for Part 1.
[December 06, 2001] "XML Watch: Bird's-eye BEEP. Part 1 of an introduction to the Blocks Extensible Exchange Protocol standard of the IETF." By Edd Dumbill (Editor and publisher, xmlhack.com). From IBM developerWorks. December 2001. ['While debate continues on reusing HTTP as a convenient way to connect applications, a new protocol called BEEP -- Blocks Extensible Exchange Protocol -- has been standardized by the Internet Engineering Task Force (IETF). Making use of XML itself, BEEP does for Internet protocols what XML has done for documents and data. In his first column for developerWorks, seasoned XML observer Edd Dumbill explains how BEEP provides a framework that allows developers to focus on the important aspects of their applications rather than wasting time with the detail of establishing communication channels.'] "Welcome to the first article in a series that will examine the practicalities of using new XML-based technologies. In these columns, I'll take a look at an XML technology, and at attempts to deploy it in a practical system. In addition to reporting on the deployment experience, I expect to have some fun along the way too. I won't expect too much prior knowledge from the reader, but a grounding in basic Web standards such as XML and HTTP will help. Why [do] we need another type of distributed computing protocol to add to CORBA/IIOP, SOAP, XML-RPC, and friends.... BEEP sits at a different level. It's a framework. SOAP can happily be implemented on top of BEEP. BEEP takes care of the connections, the authentication, and the packaging up at the TCP/IP level of the messages -- matters that SOAP deliberately avoids. BEEP really competes on the same level as HTTP... This is the best way to look at BEEP: it is essentially a refactoring of an overloaded HTTP to support the common requirements of today's Internet application protocols. BEEP is a peer-to-peer protocol, which means that it has no notion of client or server, unlike HTTP. However, as with arguments and romance, somebody has to make the first move. So for convenience I'll refer to the peer that starts a connection as the initiator, and the peer accepting the connection as the listener. When a connection is established between the two, a BEEP session is created. All communication in a session happens within one or more channels, as illustrated in Figure 1. The peers require only one IP connection, which is then multiplexed to create channels. The nature of communication possible within that channel is determined by the profiles it supports (each channel may have one or more.) The first channel, channel 0, has a special purpose. It supports the BEEP management profile, which is used to negotiate the setup of further channels. The supported profiles determine the precise interaction between the peers in a particular channel. Defining a protocol using BEEP comes down to the definition of profiles..." Article also in PDF format.
[December 06, 2001] "IETF BEEP (RFC 3080). A Framework for Next Generation Application Protocols." By Eamon O'Tuathail. November 2001. Technical Whitepaper by Clipcode.com. "BEEP (the Blocks Extensible Exchange Protocol) is a new specification that provides a common set of services to help designers of application protocols. In the past, when designers were faced with the need for a new application protocol, they had to either face the daunting task of designing a complete new protocol - which is a lot of work, or somehow piggyback on top of an existing protocol (usually HTTP) - and live with all the advantages and disadvantages of the existing protocol. BEEP is a new approach that recognizes that many application protocols are trying to solve the same set of issues again and again. "How do I set up a connection?" "What message exchange styles should be supported (e.g. one-way, request/response, request/N-response)?" "What about security?" "Who can initiate a message exchange -- the client, the server, or both?" "Is asynchronous messaging to be supported (sending multiple messages at the same time)?" The reusability theory that object-oriented professionals have been preaching since the '80s can easily be applied to the design of application protocols - and that is exactly what BEEP does. BEEP tackles those issues that are common to many application protocols once, and leaves the design of the remaining 10% to 20% of issues that are unique to each application protocol to the designers of that application protocol...Example uses of BEEP include distributed application-to-application communication, distributed user interfaces, web services and peer-to-peer services. Rather than targeting every possible application protocol type, BEEP is aimed at a specific subset with a well-defined list of attributes. BEEP is connection-oriented -- which means that a connection is established and maintained -- and then messages flow over this, and sometime later the connection is closed. BEEP supports asynchronous interactions, which mean either party to the connection can initiate a message exchange. BEEP defines the concept of discrete messages that belong to well-defined message exchange patterns. The result of this is that BEEP is suitable for some application protocols, such as peer-to-peer communications, and not suitable for others..."
The Blocks eXtensible eXchange Protocol Framework. By Marshall T. Rose (Invisible Worlds, Inc.). Network Working Group Internet-Draft. 'draft-ietf-beep-framework-01'. 58 pages. September 11, 2000. "This memo describes a generic application protocol framework for connection-oriented, asynchronous interactions. The framework permits simultaneous and independent exchanges within the context of a single application user-identity, supporting both textual and binary messages... At the core of the BXXP framework is a framing mechanism that permits simultaneous and independent exchanges of messages between peers. Messages are arbitrary MIME content, but are usually textual (structured using XML). Frames are exchanged in the context of a 'channel'. Each channel has an associated 'profile' that defines the syntax and semantics of the messages exchanged. Implicit in the operation of BXXP is the notion of channel management. In addition to defining BXXP's channel management profile, this document defines: (1)the TLS transport security profile; and, (2) the SASL family of profiles. Other profiles, such as those used for data exchange, are defined by an application protocol designer. A registration template is provided for this purpose." See especially: (1) section 2.2.2.2 on "XML-based Profiles", (2) section 6.2 for "BXXP Channel Management DTD", (3) section 6.4 for "TLS Transport Security Profile DTD", and (4) section 6.6 for "SASL Family of Profiles DTD." See extracts. [cache]
See also ongoing work by Rose: (1) "On the Design of Application Protocols", draft-mrose-beep-design-00 (work in progress), July 2000. (2) "Mapping the BXXP Framework onto TCP", draft-ietf-beep-tcpmapping-01 (work in progress), September 2000.
"Technology Overview: Blocks Extensible Exchange Protocol and the Blocks Architecture." "This document provides an explanation of the Blocks Extensible Exchange Protocol (BEEP) and Invisible Worlds' Blocks architecture. It is intended to introduce this exciting new technology, explain how it easily integrates into the existing Internet infrastructure, and to outline the benefits it offers to business and end-users alike. What you won't find are our proposed solutions to specific business applications or requirements. Instead, you'll learn about our new technology and how it relates to breaking down enterprise-wide communications barriers and creating solutions that grow with your enterprise, no matter how fast it grows or how vast it is."
"Maps, Space, and Other Metaphors for Meta-data." "This memo describes the design principles for the Blocks architecture. The Blocks architecture focuses on the management of meta-data."
[January 28, 2000] XML Objects in the Proposed IETF 'Blocks' Architecture. Two recent IETF Internet draft documents describe an extensible exchange protocol and architecture called 'Blocks'. "Blocks: Architectural Precepts." By Marshall T. Rose and Carl Malamud, of Invisible Worlds, Inc. IETF Network Working Group Internet-Draft (draft-mrose-blocks-architecture-00.txt). January 22, 2000, Expires: July 22, 2000. [Alternate URL: MappaMundi.] Summary: "Blocks is an architecture for managing metadata. The architecture supports two models: the Blocks exchange model organizes information into navigation spaces, whilst the Blocks convergence model allows for bulk synchronization and knowledge management. This document, at present, focuses on the first model. Objects are represented as XML documents, i.e., objects residing in an SEP datastore are well-formed XML documents. There are a small number of mandatory attributes for each object besides its name, e.g., the identity of the Blocks server that is responsible for managing the object along with a serial number generated by that Blocks server when the object was created, and so on. The properties that compose the content of the object are textual, and possibly structured. Objects are exchanged using an application protocol framework known as the Blocks eXtensible eXchange Protocol (BXXP). BXXP provides asynchronous request-response interactions over TCP. The goal for the Blocks exchange model is to provide an infrastructure that supports a variety of strategies for organizing information. On the assumption that delayed binding encourages reuse, the design supports a general approach that encompasses the skulk-transform-store and retrieve-evaluate-publish paradigms." Note also, from: CNet News.com article by Paul Festa (January 26, 2000): "San Francisco start-up Invisible Worlds said it plans to appear before the Internet Engineering Task Force (IETF) to propose standardization of its protocol for transporting XML data across the Web. Invisible Worlds' 'blocks' technology works for XML the way the Web's underlying HTTP (Hyptertext Transfer Protocol) works for HTML, said Carl Malamud, the company's chief executive. "What we've developed is a standard way of getting XML back and forth," Malamud said in an interview. Malamud conceded that XML can travel via HTTP, but he said there is no consensus on how to do that. Invisible Worlds will present its proposal at the task force's next three-times-yearly meeting, in March. News of its proposal was first reported by The Wall Street Journal. See also: The Blocks eXtensible eXchange Protocol." [cache]
The Blocks eXtensible eXchange Protocol. April 2000. 'draft-mrose-blocks-protocol-02' [' This memo describes the Blocks eXtensible eXchange Protocol (BXXP), a generic application protocol framework for connection-oriented, asynchronous request-response interactions. BXXP permits both multiplexing of independent request/response streams over a single transport connection, as well as segmentation and flow control of both textual and binary messages.'] [cache]
Blocks eXtensible eXchange Service. By Marshall T. Rose and Marco R. Gazzetta. March 2000. 'draft-mrose-blocks-service-01'. "Blocks is an architecture for managing metadata. The architecture supports two models: the Blocks exchange model organizes information into navigation spaces, whilst the Blocks convergence model allows for bulk synchronization and knowledge management. This memo describes how to provision a Blocks service. . .This document describes how to provision a Blocks service. Service provisioning consists of several activities: (1) defining the structure of the object types for exchange; (2) defining the naming hierarchy used for objects; (3) configuring mixers to create objects and store them in one or more BXXP servers; and, (4) configuring builders to perform the retrieve-evaluate-publish paradigm. . .Defining Object Types The SEP datastore DTD defines the rules used for structuring objects in an SEP datastore. In brief: (1) each object must be a well-formed XML document; (2) the root element of each object must contain a "name" attribute; and, (3) each element in the object, termed a property, may contain either character data or subordinate elements, but not both. The SEP datastore DTD describes both a generic syntax and a specific syntax for an object type. The specific syntax uses a syntactic minimization technique to increase readability and reduce size. For this reason, use of a specific syntax is recommended. See section 6: The BXXS DTD (DTD for Blocks eXtensible eXchange Service). Also Appendix A (The RFC space DTD) and Appendix C (The BANANA DTD). The BANANA DTD defines the 'soa.request' document type, which should be mailed as an 'text/xml' MIME attachment ..." [cache]
The Blocks Simple Exchange Profile. IETF Internet Draft. March 1999. "Blocks is an architecture for managing metadata. The architecture supports two models: the Blocks exchange model organizes information into navigation spaces, whilst the Blocks convergence model allows for bulk synchronization and knowledge management. This memo describes the Simple Exchange Profile (SEP) used to exchange objects, termed blocks, residing in an SEP datastore." [cache]
