On the Design of Application Protocols
RFC 3117
Document | Type |
RFC - Informational
(November 2001; No errata)
Was draft-mrose-beep-design (individual)
|
|
---|---|---|---|
Author | Marshall Rose | ||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 3117 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group M. Rose Request for Comments: 3117 Dover Beach Consulting, Inc. Category: Informational November 2001 On the Design of Application Protocols Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo describes the design principles for the Blocks eXtensible eXchange Protocol (BXXP). BXXP is 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. Rose Informational [Page 1] RFC 3117 On the Design of Application Protocols November 2001 Table of Contents 1. A Problem 19 Years in the Making . . . . . . . . . . . . . . . 3 2. You can Solve Any Problem... . . . . . . . . . . . . . . . . . 6 3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . . . 8 3.1 Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4 Asynchrony . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . 12 3.6 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.7 Let's Recap . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Protocol Properties . . . . . . . . . . . . . . . . . . . . . 14 4.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2 Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 15 4.5 Robustness . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. The BXXP Framework . . . . . . . . . . . . . . . . . . . . . . 17 5.1 Framing and Encoding . . . . . . . . . . . . . . . . . . . . . 17 5.2 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.3 Asynchrony . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . . 21 5.5 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.6 Things We Left Out . . . . . . . . . . . . . . . . . . . . . . 21 5.7 From Framework to Protocol . . . . . . . . . . . . . . . . . . 22 6. BXXP is now BEEP . . . . . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 27 Rose Informational [Page 2] RFC 3117 On the Design of Application Protocols November 2001 1. A Problem 19 Years in the Making SMTP [1] is close to being the perfect application protocol: it solves a large, important problem in a minimalist way. It's simple enough for an entry-level implementation to fit on one or two screens of code, and flexible enough to form the basis of very powerful product offerings in a robust and competitive market. Modulo a few oddities (e.g., SAML), the design is well conceived and the resulting specification is well-written and largely self-contained. There is very little about good application protocol design that you can't learn by reading the SMTP specification. Unfortunately, there's one little problem: SMTP was originally published in 1981 and since that time, a lot of application protocols have been designed for the Internet, but there hasn't been a lot of reuse going on. You might expect this if the application protocols were all radically different, but this isn't the case: most are surprisingly similar in their functional behavior, even though the actual details vary considerably. In late 1998, as Carl Malamud and I were sitting down to review the Blocks architecture, we realized that we needed to have a protocol for exchanging Blocks. The conventional wisdom is that when you need an application protocol, there are four ways to proceed: 1. find an existing exchange protocol that (more or less) does what you want; 2. define an exchange model on top of the world-wide web infrastructure that (more or less) does what you want;Show full document text