RFC 3117 (rfc3117) - Page 3 of 27

On the Design of Application Protocols

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;

   3. define an exchange model on top of the electronic mail
      infrastructure that (more or less) does what you want; or,

   4. define a new protocol from scratch that does exactly what you
      want.

   An engineer can make reasoned arguments about the merits of each of
   the these approaches.  Here's the process we followed...

   The most appealing option is to find an existing protocol and use
   that.  (In other words, we'd rather "buy" than "make".) So, we did a
   survey of many existing application protocols and found that none of
   them were a good match for the semantics of the protocol we needed.

   For example, most application protocols are oriented toward
   client/server behavior, and emphasize the client pulling data from
   the server; in contrast with Blocks, a client usually pulls data from



Rose                         Informational