doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc3117.txt b/doc/rfc/rfc3117.txt
new file mode 100644
index 0000000..bc92445
--- /dev/null
+++ b/doc/rfc/rfc3117.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+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;
+
+   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                      [Page 3]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+   the server, but it also may request the server to asynchronously push
+   (new) data to it.  Clearly, we could mutate a protocol such as FTP
+   [2] or SMTP into what we wanted, but by the time we did all that, the
+   base protocol and our protocol would have more differences than
+   similarities.  In other words, the cost of modifying an off-the-shelf
+   implementation becomes comparable with starting from scratch.
+
+   Another approach is to use HTTP [3] as the exchange protocol and
+   define the rules for data exchange over that.  For example, IPP [4]
+   (the Internet Printing Protocol) uses this approach.  The basic idea
+   is that HTTP defines the rules for exchanging data and then you
+   define the data's syntax and semantics.  Because you inherit the
+   entire HTTP infrastructure (e.g., HTTP's authentication mechanisms,
+   caching proxies, and so on), there's less for you to have to invent
+   (and code!).  Or, conversely, you might view the HTTP infrastructure
+   as too helpful.  As an added bonus, if you decide that your protocol
+   runs over port 80, you may be able to sneak your traffic past older
+   firewalls, at the cost of port 80 saturation.
+
+   HTTP has many strengths: it's ubiquitous, it's familiar, and there
+   are a lot of tools available for developing HTTP-based systems.
+   Another good thing about HTTP is that it uses MIME [5] for encoding
+   data.
+
+   Unfortunately for us, even with HTTP 1.1 [6], there still wasn't a
+   good fit.  As a consequence of the highly-desirable goal of
+   maintaining compatibility with the original HTTP, HTTP's framing
+   mechanism isn't flexible enough to support server-side asynchronous
+   behavior and its authentication model isn't similar to other Internet
+   applications.
+
+   Mapping IPP onto HTTP 1.1 illustrates the former issue.  For example,
+   the IPP server is supposed to signal its client when a job completes.
+   Since the HTTP client must originate all requests and since the
+   decision to close a persistent connection in HTTP is unilateral, the
+   best that the IPP specification can do is specify this functionality
+   in a non-deterministic fashion.
+
+   Further, the IPP mapping onto HTTP shows that even subtle shifts in
+   behavior have unintended consequences.  For example, requests in IPP
+   are typically much larger than those seen by many HTTP server
+   implementations -- resulting in oddities in many HTTP servers (e.g.,
+   requests are sometimes silently truncated).  The lesson is that
+   HTTP's framing mechanism is very rigid with respect to its view of
+   the request/response model.
+
+
+
+
+
+
+Rose                         Informational                      [Page 4]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+   Lastly, given our belief that the port field of the TCP header isn't
+   a constant 80, we were immune to the seductive allure of wanting to
+   sneak our traffic past unwary site administrators.
+
+   The third choice, layering the protocol on top of email, was
+   attractive.  Unfortunately, the nature of our application includes a
+   lot of interactivity with relatively small response times.  So, this
+   left us the final alternative: defining a protocol from scratch.
+
+   To begin, we figured that our requirements, while a little more
+   stringent than most, could fit inside a framework suitable for a
+   large number of future application protocols.  The trick is to avoid
+   the kitchen-sink approach.  (Dave Clark has a saying: "One of the
+   roles of architecture is to tell you what you can't do.")
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                         Informational                      [Page 5]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+2. You can Solve Any Problem...
+
+    ...if you're willing to make the problem small enough.
+
+   Our most important step is to limit the problem to application
+   protocols that exhibit certain features:
+
+   o  they are connection-oriented;
+
+   o  they use requests and responses to exchange messages; and,
+
+   o  they allow for asynchronous message exchange.
+
+   Let's look at each, in turn.
+
+   First, we're only going to consider connection-oriented application
+   protocols (e.g., those that work on top of TCP [7]).  Another branch
+   in the taxonomy, connectionless, consists of those that don't want
+   the delay or overhead of establishing and maintaining a reliable
+   stream.  For example, most DNS [8] traffic is characterized by a
+   single request and response, both of which  fit within a single IP
+   datagram.  In this case, it makes sense to implement a basic
+   reliability service above the transport layer in the application
+   protocol itself.
+
+   Second, we're only going to consider message-oriented application
+   protocols.  A "message" -- in our lexicon -- is simply structured
+   data exchanged between loosely-coupled systems.  Another branch in
+   the taxonomy, tightly-coupled systems, uses remote procedure calls as
+   the exchange paradigm.  Unlike the connection-oriented/connectionless
+   dichotomy, the issue of loosely- or tightly-coupled systems is
+   similar to a continuous spectrum.  Fortunately, the edges are fairly
+   sharp.
+
+   For example, NFS [9] is a tightly-coupled system using RPCs.  When
+   running in a properly-configured LAN, a remote disk accessible via
+   NFS is virtually indistinguishable from a local disk.  To achieve
+   this, tightly-coupled systems are highly concerned with issues of
+   latency.  Hence, most (but not all) tightly-coupled systems use
+   connection-less RPC mechanisms; further, most tend to be implemented
+   as operating system functions rather than user-level programs.  (In
+   some environments, the tightly-coupled systems are implemented as
+   single-purpose servers, on hardware specifically optimized for that
+   one function.)
+
+   Finally, we're going to consider the needs of application protocols
+   that exchange messages asynchronously.  The classic client/server
+   model is that the client sends a request and the server sends a
+
+
+
+Rose                         Informational                      [Page 6]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+   response.  If you think of requests as "questions" and responses as
+   "answers", then the server answers only those questions that it's
+   asked and it never asks any questions of its own.  We'll need to
+   support a more general model, peer-to-peer.  In this model, for a
+   given transaction one peer might be the "client" and the other the
+   "server", but for the next transaction, the two peers might switch
+   roles.
+
+   It turns out that the client/server model is a proper subset of the
+   peer-to-peer model: it's acceptable for a particular application
+   protocol to dictate that the peer that establishes the connection
+   always acts as the client (initiates requests), and that the peer
+   that listens for incoming connections always acts as the server
+   (issuing responses to requests).
+
+   There are quite a few existing application domains that don't fit our
+   requirements, e.g., nameservice (via the DNS), fileservice (via NFS),
+   multicast-enabled applications such as distributed video
+   conferencing, and so on.  However, there are a lot of application
+   domains that do fit these requirements, e.g., electronic mail, file
+   transfer, remote shell, and the world-wide web.  So, the bet we are
+   placing in going forward is that there will continue to be reasons
+   for defining protocols that fit within our framework.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                         Informational                      [Page 7]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+3. Protocol Mechanisms
+
+   The next step is to look at the tasks that an application protocol
+   must perform and how it goes about performing them.  Although an
+   exhaustive exposition might identify a dozen (or so) areas, the ones
+   we're interested in are:
+
+   o  framing, which tells how the beginning and ending of each message
+      is delimited;
+
+   o  encoding, which tells how a message is represented when exchanged;
+
+   o  reporting, which tells how errors are described;
+
+   o  asynchrony, which tells how independent exchanges are handled;
+
+   o  authentication, which tells how the peers at each end of the
+      connection are identified and verified; and,
+
+   o  privacy, which tells how the exchanges are protected against
+      third-party interception or modification.
+
+   A notable absence in this list is naming -- we'll explain why later
+   on.
+
+3.1 Framing
+
+   There are three commonly used approaches to delimiting messages:
+   octet-stuffing, octet-counting, and connection-blasting.
+
+   An example of a protocol that uses octet-stuffing is SMTP.  Commands
+   in SMTP are line-oriented (each command ends in a CR-LF pair).  When
+   an SMTP peer sends a message, it first transmits the "DATA" command,
+   then it transmits the message, then it transmits a "." (dot) followed
+   by a CR-LF.  If the message contains any lines that begin with a dot,
+   the sending SMTP peer sends two dots; similarly, when the other SMTP
+   peer receives a line that begins with a dot, it discards the dot,
+   and, if the line is empty, then it knows it's received the entire
+   message.  Octet-stuffing has the property that you don't need the
+   entire message in front of you before you start sending it.
+   Unfortunately, it's slow because both the sender and receiver must
+   scan each line of the message to see if they need to transform it.
+
+   An example of a protocol that uses octet-counting is HTTP.  Commands
+   in HTTP consist of a request line followed by headers and a body. The
+   headers contain an octet count indicating how large the body is. The
+   properties of octet-counting are the inverse of octet-stuffing:
+
+
+
+
+Rose                         Informational                      [Page 8]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+   before you can start sending a message you need to know the length of
+   the whole message, but you don't need to look at the content of the
+   message once you start sending or receiving.
+
+   An example of a protocol that uses connection-blasting is FTP.
+   Commands in FTP are line-oriented, and when it's time to exchange a
+   message, a new TCP connection is established to transmit the message.
+   Both octet-counting and connection-blasting have the property that
+   the messages can be arbitrary binary data; however, the drawback of
+   the connection-blasting approach is that the peers need to
+   communicate IP addresses and TCP port numbers, which may be
+   "transparently" altered by NATS [10] and network bugs.  In addition,
+   if the messages being exchanged are small (say less than 32k), then
+   the overhead of establishing a connection for each message
+   contributes significant latency during data exchange.
+
+3.2 Encoding
+
+   There are many schemes used for encoding data (and many more encoding
+   schemes have been proposed than are actually in use).  Fortunately,
+   only a few are burning brightly on the radar.
+
+   The messages exchanged using SMTP are encoded using the 822-style
+   [11].  The 822-style divides a message into textual headers and an
+   unstructured body.  Each header consists of a name and a value and is
+   terminated with a CR-LF pair.  An additional CR-LF separates the
+   headers from the body.
+
+   It is this structure that HTTP uses to indicate the length of the
+   body for framing purposes.  More formally, HTTP uses MIME, an
+   application of the 822-style to encode both the data itself (the
+   body) and information about the data (the headers).  That is,
+   although HTTP is commonly viewed as a retrieval mechanism for HTML
+   [12], it is really a retrieval mechanism for objects encoded using
+   MIME, most of which are either HTML pages or referenced objects such
+   as GIFs.
+
+3.3 Reporting
+
+   An application protocol needs a mechanism for conveying error
+   information between peers.  The first formal method for doing this
+   was defined by SMTP's "theory of reply codes".  The basic idea is
+   that an error is identified by a three-digit string, with each
+   position having a different significance:
+
+   the first digit: indicating success or failure, either permanent or
+      transient;
+
+
+
+
+Rose                         Informational                      [Page 9]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+   the second digit: indicating the part of the system reporting the
+      situation (e.g., the syntax analyzer); and,
+
+   the third digit: identifying the actual situation.
+
+   Operational experience with SMTP suggests that the range of error
+   conditions is larger than can be comfortably encoded using a three-
+   digit string (i.e., you can report on only 10 different things going
+   wrong for any given part of the system).  So, [13] provides a
+   convenient mechanism for extending the number of values that can
+   occur in the second and third positions.
+
+   Virtually all of the application protocols we've discussed thus far
+   use the three-digit reply codes, although there is less coordination
+   between the designers of different application protocols than most
+   would care to admit.  (A variation on the theory of reply codes is
+   employed by IMAP [14] which provides the same information using a
+   different syntax.)
+
+   In addition to conveying a reply code, most application protocols
+   also send a textual diagnostic suitable for human, not machine,
+   consumption.  (More accurately, the textual diagnostic is suitable
+   for people who can read a widely used variant of the English
+   language.) Since reply codes reflect both positive and negative
+   outcomes, there have been some innovative uses made for the text
+   accompanying positive responses, e.g., prayer wheels [39].
+   Regardless, some of the more modern application protocols include a
+   language localization parameter for the diagnostic text.
+
+   Finally, since the introduction of reply codes in 1981, two
+   unresolved criticisms have been raised:
+
+   o  a reply code is used both to signal the outcome of an operation
+      and a change in the application protocol's state; and,
+
+   o  a reply code doesn't specify whether the associated textual
+      diagnostic is destined for the end-user, administrator, or
+      programmer.
+
+3.4 Asynchrony
+
+   Few application protocols today allow independent exchanges over the
+   same connection.  In fact, the more widely implemented approach is to
+   allow pipelining, e.g., command pipelining [15] in SMTP or persistent
+   connections in HTTP 1.1.  Pipelining allows a client to make multiple
+   requests of a server, but requires the requests to be processed
+   serially.  (Note that a protocol needs to explicitly provide support
+   for pipelining, since, without explicit guidance, many implementors
+
+
+
+Rose                         Informational                     [Page 10]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+   produce systems that don't handle pipelining properly; typically, an
+   error in a request causes subsequent requests in the pipeline to be
+   discarded).
+
+   Pipelining is a powerful method for reducing network latency.  For
+   example, without persistent connections, HTTP's framing mechanism is
+   really closer to connection-blasting than octet-counting, and it
+   enjoys the same latency and efficiency problems.
+
+   In addition to reducing network latency (the pipelining effect),
+   asynchrony also reduces server latency by allowing multiple requests
+   to be processed by multi-threaded implementations.  Note that if you
+   allow any form of asynchronous exchange, then support for parallelism
+   is also required, because exchanges aren't necessarily occurring
+   under the synchronous direction of a single peer.
+
+   Unfortunately, when you allow parallelism, you also need a flow
+   control mechanism to avoid starvation and deadlock.  Otherwise, a
+   single set of exchanges can monopolize the bandwidth provided by the
+   transport layer.  Further, if a peer is resource-starved, then it may
+   not have enough buffers to receive a message and deadlock results.
+
+   Flow control is typically implemented at the transport layer.  For
+   example, TCP uses sequence numbers and a sliding window: each
+   receiver manages a sliding window that indicates the number of data
+   octets that may be transmitted before receiving further permission.
+   However, it's now time for the second shoe to drop: segmentation.  If
+   you do flow control then you also need a segmentation mechanism to
+   fragment messages into smaller pieces before sending and then re-
+   assemble them as they're received.
+
+   Both flow control and segmentation have an impact on how the protocol
+   does framing.  Before we defined framing as "how to tell the
+   beginning and end of each message" -- in addition, we need to be able
+   to identify independent messages, send messages only when flow
+   control allows us to, and segment them if they're larger than the
+   available window (or too large for comfort).
+
+   Segmentation impacts framing in another way -- it relaxes the octet-
+   counting requirement that you need to know the length of the whole
+   message before sending it.  With segmentation, you can start sending
+   segments before the whole message is available.  In HTTP 1.1 you can
+   "chunk" (segment) data to get this advantage.
+
+
+
+
+
+
+
+
+Rose                         Informational                     [Page 11]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+3.5 Authentication
+
+   Perhaps for historical (or hysterical) reasons, most application
+   protocols don't do authentication.  That is, they don't authenticate
+   the identity of the peers on the connection or the authenticity of
+   the messages being exchanged.  Or, if authentication is done, it is
+   domain-specific for each protocol.  For example, FTP and HTTP use
+   entirely different models and mechanisms for authenticating the
+   initiator of a connection.  (Independent of mainstream HTTP, there is
+   a little-used variant [16] that authenticates the messages it
+   exchanges.)
+
+   A large part of the problem is that different security mechanisms
+   optimize for strength, scalability, or ease of deployment.  So, a few
+   years ago, SASL [17] (the Simple Authentication and Security Layer)
+   was developed to provide a framework for authenticating protocol
+   peers.  SASL let's you describe how an authentication mechanism
+   works, e.g., an OTP [18] (One-Time Password) exchange.  It's then up
+   to each protocol designer to specify how SASL exchanges are
+   generically conveyed by the protocol.  For example, [19] explains how
+   SASL works with SMTP.
+
+   A notable exception to the SASL bandwagon is HTTP, which defines its
+   own authentication mechanisms [20].  There is little reason why SASL
+   couldn't be introduced to HTTP, although to avoid certain race-
+   conditions, the persistent connection mechanism of HTTP 1.1 must be
+   used.
+
+   SASL has an interesting feature in that in addition to explicit
+   protocol exchanges to authenticate identity, it can also use implicit
+   information provided from the layer below.  For example, if the
+   connection is running over IPsec [21], then the credentials of each
+   peer are known and verified when the TCP connection is established.
+
+   Finally, as its name implies, SASL can do more than authentication --
+   depending on which SASL mechanism is in use, message integrity or
+   privacy services may also be provided.
+
+3.6 Privacy
+
+   HTTP is the first widely used protocol to make use of a transport
+   security protocol to encrypt the data sent on the connection.  The
+   current version of this mechanism, TLS [22], is available to all
+   application protocols, e.g., SMTP and ACAP [23] (the Application
+   Configuration Access Protocol).
+
+
+
+
+
+
+Rose                         Informational                     [Page 12]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+   The key difference between the original mechanism and TLS, is one of
+   provisioning not technology.  In the original approach to
+   provisioning, a world-wide web server listens on two ports (one for
+   plaintext traffic and the other for secured traffic); in contrast, by
+   today's conventions, a server implementing an application protocol
+   that is specified as TLS-enabled (e.g., [24] and [25]) listens on a
+   single port for plaintext traffic, and, once a connection is
+   established, the use of TLS on that connection is negotiable.
+
+   Finally, note that both SASL and TLS are about "transport security"
+   not "object security".  What this means is that they focus on
+   providing security properties for the actual communication, they
+   don't provide any security properties for the data exchanged
+   independent of the communication.
+
+3.7 Let's Recap
+
+   Let's briefly compare the properties of the three main connection-
+   oriented application protocols in use today:
+
+                Mechanism  ESMTP        FTP        HTTP1.1
+           --------------  -----------  ---------  -------------
+                  Framing  stuffing     blasting   counting
+
+                 Encoding  822-style    binary     MIME
+
+                Reporting  3-digit      3-digit    3-digit
+
+               Asynchrony  pipelining   none       pipelining
+                                                   and chunking
+
+           Authentication  SASL         user/pass  user/pass
+
+                  Privacy  SASL or TLS  none       TLS (nee SSL)
+
+   Note that the username/password mechanisms used by FTP and HTTP are
+   entirely different with one exception: both can be termed a
+   "username/password" mechanism.
+
+   These three choices are broadly representative: as more protocols are
+   considered, the patterns are reinforced.  For example, POP [26] uses
+   octet-stuffing, but IMAP uses octet-counting, and so on.
+
+
+
+
+
+
+
+
+
+Rose                         Informational                     [Page 13]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+4. Protocol Properties
+
+   When we design an application protocol, there are a few properties
+   that we should keep an eye on.
+
+4.1 Scalability
+
+   A well-designed protocol is scalable.
+
+   Because few application protocols support asynchrony, a common trick
+   is for a program to open multiple simultaneous connections to a
+   single destination.  The theory is that this reduces latency and
+   increases throughput.  The reality is that both the transport layer
+   and the server view each connection as an independent instance of the
+   application protocol, and this causes problems.
+
+   In terms of the transport layer, TCP uses adaptive algorithms to
+   efficiently transmit data as networks conditions change.  But what
+   TCP learns is limited to each connection.  So, if you have multiple
+   TCP connections, you have to go through the same learning process
+   multiple times -- even if you're going to the same host.  Not only
+   does this introduce unnecessary traffic spikes into the network,
+   because TCP uses a slow-start algorithm when establishing a
+   connection, the program still sees additional latency.  To deal with
+   the fact that a lack of asynchrony in application protocols causes
+   implementors to make sloppy use of the transport layer, network
+   protocols are now provisioned with increasing sophistication, e.g.,
+   RED [27].  Further, suggestions are also being considered for
+   modification of TCP implementations to reduce concurrent learning,
+   e.g., [28].
+
+   In terms of the server, each incoming connection must be dispatched
+   and (probably) authenticated against the same resources.
+   Consequently, server overhead increases based on the number of
+   connections established, rather than the number of remote users.  The
+   same issues of fairness arise: it's much harder for servers to
+   allocate resources on a per-user basis, when a user can cause an
+   arbitrary number of connections to pound on the server.
+
+   Another important aspect of scalability to consider is the relative
+   numbers of clients and servers.  (This is true even in the peer-to-
+   peer model, where a peer can act both in the client and server role.)
+   Typically, there are many more client peers than server peers.  In
+   this case, functional requirements should be shifted from the servers
+   onto the clients.  The reason is that a server is likely to be
+   interacting with multiple clients and this functional shift makes it
+   easier to scale.
+
+
+
+
+Rose                         Informational                     [Page 14]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+4.2 Efficiency
+
+   A well-designed protocol is efficient.
+
+   For example, although a compelling argument can be made than octet-
+   stuffing leads to more elegant implementations than octet-counting,
+   experience shows that octet-counting consumes far fewer cycles.
+
+   Regrettably, we sometimes have to compromise efficiency in order to
+   satisfy other properties.  For example, 822 (and MIME) use textual
+   headers.  We could certainly define a more efficient representation
+   for the headers if we were willing to limit the header names and
+   values that could be used.  In this case, extensibility is viewed as
+   more important than efficiency.  Of course, if we were designing a
+   network protocol instead of an application protocol, then we'd make
+   the trade-offs using a razor with a different edge.
+
+4.3 Simplicity
+
+   A well-designed protocol is simple.
+
+   Here's a good rule of thumb: a poorly-designed application protocol
+   is one in which it is equally as "challenging" to do something basic
+   as it is to do something complex.  Easy things should be easy to do
+   and hard things should be harder to do.  The reason is simple: the
+   pain should be proportional to the gain.
+
+   Another rule of thumb is that if an application protocol has two ways
+   of doing the exact same thing, then there's a problem somewhere in
+   the architecture underlying the design of the application protocol.
+
+   Hopefully, simple doesn't mean simple-minded: something that's well-
+   designed accommodates everything in the problem domain, even the
+   troublesome things at the edges.  What makes the design simple is
+   that it does this in a consistent fashion.  Typically, this leads to
+   an elegant design.
+
+4.4 Extensibility
+
+   A well-designed protocol is extensible.
+
+   As clever as application protocol designers are, there are likely to
+   be unforeseen problems that the application protocol will be asked to
+   solve.  So, it's important to provide the hooks that can be used to
+   add functionality or customize behavior.  This means that the
+   protocol is evolutionary, and there must be a way for implementations
+   reflecting different steps in the evolutionary path to negotiate
+   which extensions will be used.
+
+
+
+Rose                         Informational                     [Page 15]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+   But, it's important to avoid falling into the extensibility trap: the
+   hooks provided should not be targeted at half-baked future
+   requirements.  Above all, the hooks should be simple.
+
+   Of course good design goes a long way towards minimizing the need for
+   extensibility.  For example, although SMTP initially didn't have an
+   extension framework, it was only after ten years of experience that
+   its excellent design was altered.  In contrast, a poorly-designed
+   protocol such as Telnet [29] can't function without being built
+   around the notion of extensions.
+
+4.5 Robustness
+
+   A well-designed protocol is robust.
+
+   Robustness and efficiency are often at odds.  For example, although
+   defaults are useful to reduce packet sizes and processing time, they
+   tend to encourage implementation errors.
+
+   Counter-intuitively, Postel's robustness principle ("be conservative
+   in what you send, liberal in what you accept") often leads to
+   deployment problems.  Why? When a new implementation is initially
+   fielded, it is likely that it will encounter only a subset of
+   existing implementations.  If those implementations follow the
+   robustness principle, then errors in the new implementation will
+   likely go undetected.  The new implementation then sees some, but not
+   widespread deployment.  This process repeats for several new
+   implementations.  Eventually, the not-quite-correct implementations
+   run into other implementations that are less liberal than the initial
+   set of implementations.  The reader should be able to figure out what
+   happens next.
+
+   Accordingly, explicit consistency checks in a protocol are very
+   useful, even if they impose implementation overhead.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                         Informational                     [Page 16]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+5. The BXXP Framework
+
+   Finally, we get to the money shot: here's what we did.
+
+   We defined an application protocol framework called BXXP (the Blocks
+   eXtensible eXchange Protocol).  The reason it's a "framework" instead
+   of an application protocol is that we provide all the mechanisms
+   discussed earlier without actually specifying the kind of messages
+   that get exchanged.  So, when someone else needs an application
+   protocol that requires connection-oriented, asynchronous
+   interactions, they can start with BXXP.  It's then their
+   responsibility to define the last 10% of the application protocol,
+   the part that does, as we say, "the useful work".
+
+   So, what does BXXP look like?
+
+           Mechanism  BXXP
+       --------------  ----------------------------------------
+             Framing  counting, with a trailer
+
+            Encoding  MIME, defaulting to text/xml
+
+           Reporting  3-digit and localized textual diagnostic
+
+          Asynchrony  channels
+
+      Authentication  SASL
+
+             Privacy  SASL or TLS
+
+
+5.1 Framing and Encoding
+
+   Framing in BXXP looks a lot like SMTP or HTTP: there's a command line
+   that identifies the beginning of the frame, then there's a MIME
+   object (headers and body).  Unlike SMTP, BXXP uses octet-counting,
+   but unlike HTTP, the command line is where you find the size of the
+   payload.  Finally, there's a trailer after the MIME object to aid in
+   detecting framing errors.
+
+   Actually, the command line for BXXP has a lot of information, it
+   tells you:
+
+   o  what kind of message is in this frame;
+
+   o  whether there's more to the message than just what's in this frame
+      (a continuation flag);
+
+
+
+
+Rose                         Informational                     [Page 17]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+   o  how to distinguish the message contained in this frame from other
+      messages (a message number);
+
+   o  where the payload occurs in the sliding window (a sequence number)
+      along with how many octets are in the payload of this frame; and,
+
+   o  which part of the application should get the message (a channel
+      number).
+
+      (The command line is textual and ends in a CR-LF pair, and the
+      arguments are separated by a space.)
+
+   Since you need to know all this stuff to process a frame, we put it
+   all in one easy to parse location.  You could probably devise a more
+   efficient encoding, but the command line is a very small part of the
+   frame, so you wouldn't get much bounce from optimizing it.  Further,
+   because framing is at the heart of BXXP, the frame format has several
+   consistency checks that catch the majority of programming errors.
+   (The combination of a sequence number, an octet count, and a trailer
+   allows for very robust error detection.)
+
+   Another trick is in the headers: because the command line contains
+   all the framing information, the headers may contain minimal MIME
+   information (such as Content-Type).  Usually, however, the headers
+   are empty.  That's because the BXXP default payload is XML [30].
+   (Actually, a "Content-Type: text/xml" with binary transfer encoding).
+
+   We chose XML as the default because it provides a simple mechanism
+   for nested, textual representations.  (Alas, the 822-style encoding
+   doesn't easily support nesting.) By design, XML's nature isn't
+   optimized for compact representations.  That's okay because we're
+   focusing on loosely-coupled systems and besides there are efficient
+   XML parsers available.  Further, there's a fair amount of anecdotal
+   experience -- and we'll stress the word "anecdotal" -- that if you
+   have any kind of compression (either at the link-layer or during
+   encryption), then XML encodings squeeze down nicely.
+
+   Even so, use of XML is probably the most controversial part of BXXP.
+   After all, there are more efficient representations around.  We
+   agree, but the real issue isn't efficiency, it's ease of use: there
+   are a lot of people who grok the XML thing and there are a lot of XML
+   tools out there.  The pain of recreating this social infrastructure
+   far outweighs any benefits of devising a new representation.  So, if
+   the "make" option is too expensive, is there something else we can
+   "buy" besides XML? Well, there's ASN.1/BER (just kidding).
+
+
+
+
+
+
+Rose                         Informational                     [Page 18]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+   In the early days of the SNMP [31], which does use ASN.1, the same
+   issues arose.  In the end, the working group agreed that the use of
+   ASN.1 for SNMP was axiomatic, but not because anyone thought that
+   ASN.1 was the most efficient, or the easiest to explain, or even well
+   liked.  ASN.1 was given axiomatic status because the working group
+   decided it was not going to spend the next three years explaining an
+   alternative encoding scheme to the developer community.
+
+   So -- and we apologize for appealing to dogma -- use of XML as the
+   favored encoding scheme in BXXP is axiomatic.
+
+5.2 Reporting
+
+   We use 3-digit error codes, with a localized textual diagnostic.
+   (Each peer specifies a preferred ordering of languages.)
+
+   In addition, the reply to a message is flagged as either positive or
+   negative.  This makes it easy to signal success or failure and allow
+   the receiving peer some freedom in the amount of parsing it wants to
+   do on failure.
+
+5.3 Asynchrony
+
+   Despite the lessons of SMTP and HTTP, there isn't a lot of field
+   experience to rely on when designing the asynchrony features of BXXP.
+   (Actually, there were several efforts in 1998 related to application
+   layer framing, e.g., [32], but none appear to have achieved orbit.)
+
+   So, here's what we did: 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 over a channel.
+
+   Channels provide both an extensibility mechanism for BXXP and the
+   basis for parallelism.  Remember the last parameter in the command
+   line of a BXXP frame? The "part of the application" that gets the
+   message is identified by a channel number.
+
+   A profile is defined according to a "Profile Registration" template.
+   The template defines how the profile is identified (using a URI
+   [33]), what kind of messages get exchanged, along with the syntax and
+   semantics of those messages.  When you create a channel, you identify
+   a profile and maybe piggyback your first message.  If the channel is
+   successfully created, you get back a positive response; otherwise,
+   you get back a negative response explaining why.
+
+   Perhaps the easiest way to see how channels provide an extensibility
+   mechanism is to consider what happens when a session is established.
+   Each BXXP peer immediately sends a greeting on channel zero
+
+
+
+Rose                         Informational                     [Page 19]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+   identifying the profiles that each support.  (Channel 0 is used for
+   channel management -- it's automatically created when a session is
+   opened.) If you want transport security, the very first thing you do
+   is to create a channel that negotiates transport security, and, once
+   the channel is created, you tell it to do its thing.  Next, if you
+   want to authenticate, you create a channel that performs user
+   authentication, and, once the channel is created, you tell it to get
+   busy.  At this point, you create one or more channels for data
+   exchange.  This process is called "tuning"; once you've tuned the
+   session, you start using the data exchange channels to do "the useful
+   work".
+
+   The first channel that's successfully started has a trick associated
+   with it: when you ask to start the channel, you're allowed to specify
+   a "service name" that goes with it.  This allows a server with
+   multiple configurations to select one based on the client's
+   suggestion.  (A useful analogy is HTTP 1.1's "Host:" header.) If the
+   server accepts the "service name", then this configuration is used
+   for the rest of the session.
+
+   To allow parallelism, BXXP allows you to use multiple channels
+   simultaneously.  Each channel processes messages serially, but there
+   are no constraints on the processing order for different channels.
+   So, in a multi-threaded implementation, each channel maps to its own
+   thread.
+
+   This is the most general case, of course.  For one reason or another,
+   an implementor may not be able to support this.  So, BXXP allows for
+   both positive and negative replies when a message is sent.  So, if
+   you want the classic client/server model, the client program should
+   simply reject any new message sent by the server.  This effectively
+   throttles any asynchronous messages from the server.
+
+   Of course, we now need to provide mechanisms for segmentation and
+   flow control.  For the former, we just put a "continuation" or "more
+   to come" flag in the command line for the frame.  For the latter, we
+   introduced the notion of a "transport mapping".
+
+   What this means is that BXXP doesn't directly define how it sits of
+   top of TCP.  Instead, it lists a bunch of requirements for how a
+   transport service needs to support a BXXP session.  Then, in a
+   separate document, we defined how you can use TCP to meet these
+   requirements.
+
+   This second document pretty much says "use TCP directly", except that
+   it introduces a flow control mechanism for multiplexing channels over
+   a single TCP connection.  The mechanism we use is the same one used
+
+
+
+
+Rose                         Informational                     [Page 20]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+   by TCP (sequence numbers and a sliding window).  It's proven, and can
+   be trivially implemented by a minimal implementation of BXXP.
+
+   The introduction of flow control is a burden from an implementation
+   perspective -- although TCP's mechanism is conceptually simple, an
+   implementor must take great care.  For example, issues such as
+   priorities, queue management, and the like should be addressed.
+   Regardless, we feel that the benefits of allowing parallelism for
+   intra-application streams is worth it.  (Besides, our belief is that
+   few application implementors will actually code the BXXP framework
+   directly -- rather, we expect them to use third-party packages that
+   implement BXXP.)
+
+5.4 Authentication
+
+   We use SASL.  If you successfully authenticate using a channel, then
+   there is a single user identity for each peer on that session (i.e.,
+   authentication is per-session, not per-channel).  This design
+   decision mandates that each session correspond to a single user
+   regardless of how many channels are open on that session.  One reason
+   why this is important is that it allows service provisioning, such as
+   quality of service (e.g., as in [34]) to be done on a per-user
+   granularity.
+
+5.5 Privacy
+
+   We use SASL and TLS.  If you successfully complete a transport
+   security negotiation using a channel, then all traffic on that
+   session is secured (i.e., confidentiality is per-session, not per-
+   channel, just like authentication).
+
+   We defined a BXXP profile that's used to start the TLS engine.
+
+5.6 Things We Left Out
+
+   We purposefully excluded two things that are common to most
+   application protocols: naming and authorization.
+
+   Naming was excluded from the framework because, outside of URIs,
+   there isn't a commonly accepted framework for naming things.  To our
+   view, this remains a domain-specific problem for each application
+   protocol.  Maybe URIs are appropriate in the context of a
+   particularly problem domain, maybe not.  So, when an application
+   protocol designer defines their own profile to do "the useful work",
+   they'll have to deal with naming issues themselves.  BXXP provides a
+   mechanism for identifying profiles and binding them to channels. It's
+   up to you to define the profile and use the channel.
+
+
+
+
+Rose                         Informational                     [Page 21]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+   Similarly, authorization was explicitly excluded from the framework.
+   Every approach to authorization we've seen uses names to identify
+   principals (i.e., targets and subjects), so if a framework doesn't
+   include naming, it can't very well include authorization.
+
+   Of course, application protocols do have to deal with naming and
+   authorization -- those are two of the issues addressed by the
+   applications protocol designer when defining a profile for use with
+   BXXP.
+
+5.7 From Framework to Protocol
+
+   So, how do you go about using BXXP? To begin, call it "BEEP", not
+   "BXXP" (we'll explain why momentarily).
+
+   First, get the BEEP core specification [35] and read it.  Next,
+   define your own profile.  Finally, get one of the open source SDKs
+   (in C, Java, or Tcl) and start coding.
+
+   The BEEP specification defines several profiles itself: a channel
+   management profile, a family of profiles for SASL, and a transport
+   security profile.  In addition, there's a second specification [36]
+   that explains how a BEEP session maps onto a single TCP connection.
+
+   For a complete example of an application protocol defined using BEEP,
+   look at reliable syslog [37].  This document exemplifies the formula:
+
+   application protocol = BEEP + 1 or more profiles
+                        + authorization policies
+                        + provisioning rules (e.g., use of SRV RRs [38])
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                         Informational                     [Page 22]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+6. BXXP is now BEEP
+
+   We started work on BXXP in the fall of 1998.  The IETF formed a
+   working group on BXXP in the summer of 2000.  Although the working
+   group made some enhancements to BXXP, three are the most notable:
+
+   o  The payload default is "application/octet-stream".  This is
+      primarily for wire-efficiency -- if you care about wire-
+      efficiency, then you probably wouldn't be using "text/xml"...
+
+   o  One-to-many exchanges are supported (the client sends one message
+      and the server sends back many replies).
+
+   o  BXXP is now called BEEP (more comic possibilities).
+
+7. Security Considerations
+
+   Consult Section [35]'s Section 8 for a discussion of BEEP-related
+   security issues.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                         Informational                     [Page 23]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+References
+
+   [1]   Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+         August 1982.
+
+   [2]   Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
+         RFC 959, October 1985.
+
+   [3]   Berners-Lee, T., Fielding, R. and H. Nielsen, "Hypertext
+         Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
+
+   [4]   Herriot, R., "Internet Printing Protocol/1.0: Encoding and
+         Transport", RFC 2565, April 1999.
+
+   [5]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+         Extensions (MIME) Part One: Format of Internet Message Bodies",
+         RFC 2045, November 1996.
+
+   [6]   Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
+         Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
+         HTTP/1.1", RFC 2616, June 1999.
+
+   [7]   Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
+         September 1981.
+
+   [8]   Mockapetris, P., "Domain names - concepts and facilities", STD
+         13, RFC 1034, November 1987.
+
+   [9]   Microsystems, Sun., "NFS: Network File System Protocol
+         specification", RFC 1094, March 1989.
+
+   [10]  Srisuresh, P. and M. Holdrege, "IP Network Address Translator
+         (NAT) Terminology and Considerations", RFC 2663, August 1999.
+
+   [11]  Crocker, D., "Standard for the format of ARPA Internet text
+         messages", STD 11, RFC 822, August 1982.
+
+   [12]  Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
+         2.0", RFC 1866, November 1995.
+
+   [13]  Freed, N., "SMTP Service Extension for Returning Enhanced Error
+         Codes", RFC 2034, October 1996.
+
+   [14]  Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
+         December 1994.
+
+   [15]  Freed, N., "SMTP Service Extension for Command Pipelining", RFC
+         2197, September 1997.
+
+
+
+Rose                         Informational                     [Page 24]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+   [16]  Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer
+         Protocol", RFC 2660, August 1999.
+
+   [17]  Myers, J., "Simple Authentication and Security Layer (SASL)",
+         RFC 2222, October 1997.
+
+   [18]  Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444,
+         October 1998.
+
+   [19]  Myers, J., "SMTP Service Extension for Authentication", RFC
+         2554, March 1999.
+
+   [20]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
+         Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
+         Basic and Digest Access Authentication", RFC 2617, June 1999.
+
+   [21]  Kent, S. and R. Atkinson, "Security Architecture for the
+         Internet Protocol", RFC 2401, November 1998.
+
+   [22]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+         2246, January 1999.
+
+   [23]  Newman, C. and J. Myers, "ACAP -- Application Configuration
+         Access Protocol", RFC 2244, November 1997.
+
+   [24]  Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS",
+         RFC 2487, January 1999.
+
+   [25]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
+         June 1999.
+
+   [26]  Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
+         53, RFC 1939, May 1996.
+
+   [27]  Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S.,
+         Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge,
+         C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J.
+         and L. Zhang, "Recommendations on Queue Management and
+         Congestion Avoidance in the Internet", RFC 2309, April 1998.
+
+   [28]  Touch, J., "TCP Control Block Interdependence", RFC 2140, April
+         1997.
+
+   [29]  Postel, J. and J. Reynolds, "Telnet Protocol Specification",
+         STD 8, RFC 854, May 1983.
+
+
+
+
+
+
+Rose                         Informational                     [Page 25]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+   [30]  World Wide Web Consortium, "Extensible Markup Language (XML)
+         1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-
+         xml-19980210>.
+
+   [31]  Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple
+         Network Management Protocol (SNMP)", STD 15, RFC 1157, May
+         1990.
+
+   [32]  World Wide Web Consortium, "SMUX Protocol Specification",
+         Working Draft, July 1998, <http://www.w3.org/TR/1998/WD-mux-
+         19980710>.
+
+   [33]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
+         Resource Identifiers (URI): Generic Syntax", RFC 2396, August
+         1998.
+
+   [34]  Waitzman, D., "IP over Avian Carriers with Quality of Service",
+         RFC 2549, April 1999.
+
+   [35]  Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
+         3080, March 2001.
+
+   [36]  Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March
+         2001.
+
+   [37]  New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195,
+         November 2001.
+
+   [38]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+         specifying the location of services (DNS SRV)", RFC 2782,
+         February 2000.
+
+   [39]  <http://mappa.mundi.net/cartography/Wheel/>
+
+Author's Address
+
+   Marshall T. Rose
+   Dover Beach Consulting, Inc.
+   POB 255268
+   Sacramento, CA  95865-5268
+   US
+
+   Phone: +1 916 483 8878
+   EMail: mrose@dbc.mtview.ca.us
+
+
+
+
+
+
+
+Rose                         Informational                     [Page 26]
+
+RFC 3117         On the Design of Application Protocols    November 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                         Informational                     [Page 27]
+