M.T. Rose
  Invisible Worlds, Inc.
  February 25, 2001



Table of Contents

2.  The Problem in Application Protocol Design
3.  The Target Market
4.  Application Protocol Mechanisms
5.  IETF Applications and Security
6.  The BEEP Core
7.  Framing
8.  Channels and Profiles
9.  Profile Definitions
10.  Encoding
11.  Reporting
12.  Asynchrony
13.  Transport Mappings
14.  Flow Control
15.  Authentication and Privacy
16.  syslog
17.  intrusion detection
18.  Operational Taxonomies
19.  An Application Datagram Service
20.  Entities
21.  Modes
22.  Operations
23.  Enveloping
24.  An Example
25.  Another Example
26.  Options
27.  The Report Service
28.  The Access Service
29.  The Presence Service
30.  Status



I-Ds on BEEP:

I-Ds on apex:

Other I-Ds:


2. The Problem in Application Protocol Design

A lot of application protocols, a lot of similarities, not a lot of reuse

Need an application protocol? Three choices:

If choosing the first option involves little or no work, take it

If the application protocol's requirements are a good fit with the web or email, use it

Otherwise, let's talk about coming up with a decent 90% solution


3. The Target Market

Limiting the problem domain:

This doesn't accommodate things like:

That's OK... we can define alternative frameworks later, according to the demands of the standards marketplace


4. Application Protocol Mechanisms

There are (at least) six tasks that application protocols have to perform:

     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/chunking 
Authentication  SASL         user/pass  user/pass 
       Privacy  SASL or TLS  none       TLS (nee SSL) 


5. IETF Applications and Security


(Graphic courtesy of Bob "RL" Morgan, University of Washington)


6. The BEEP Core

     Mechanism  BEEP
     ---------  ----
       Framing  counting with a trailer
      Encoding  MIME, defaulting to application/octet-stream
     Reporting  3-digit with localized textual diagnostic
    Asynchrony  independent channels
Authentication  SASL
       Privacy  SASL or TLS


7. Framing

The header is:

    tag SP channel SP msgno SP more SP seqno SP size CRLF

Several "consistency rules" used to validate each frame

The payload is 0 or more octets

The trailer is:

    "END" CRLF

So, what's a channel?


8. Channels and Profiles

A profile defines the messages exchanged on a given channel

At startup, channel 0 is bound to the channel management profile

RPY 0 0 . 0 124 
Content-Type: application/beep+xml

  <profile uri="http://.../TLS" />
  <profile uri="http://.../SEP" />
  <profile uri="http://.../sasl/OTP" />
  <profile uri="http://.../sasl/..." />

<start number="1">
  <profile uri="..."> ... </profile>
  <profile uri="..."> ... </profile>

<close number="1" code="200" />


9. Profile Definitions

A registration template defines:

Two kinds of profiles:

Protocol =

    BEEP + 1 or more profiles
         + authorization policies
         + provisioning rules


    MSG -> RPY
    MSG -> ERR
    MSG -> zero or more ANS, followed by NUL


10. Encoding

All payloads are MIME-encoded, by default:

Content-Type: application/octet-stream
Content-Transfer-Encoding: binary

BEEP defines a minimal XML media type, application/beep+xml, i.e.,


11. Reporting

Each profile defines messages for both positive and negative replies

For negative replies, the channel management profile uses 3 digit reply codes with a localized diagnostic, e.g.,

    <error code="421"
           xml:lang="en-US">service not available</error>

A list of preferred languages is passed in the <greeting> when a BEEP session is established


12. Asynchrony

Channels handle asynchrony:

Segmentation is handled by framing

So, what about flow control?


13. Transport Mappings

A BEEP session is connection-oriented, and mapped onto a transport service that defines how:

At present, one mapping is defined: onto a single TCP connection

In the future, look for transport mappings onto:


14. Flow Control

The TCP-based mapping re-introduces the window-based flow control mechanism of TCP, each channel:

When a channel is created, it has a 4K window, after that it's managed:

    "SEQ" SP channel SP ackno SP size 

BEEP peers expected to use basic fairness algorithms, e.g.,


15. Authentication and Privacy

Each BEEP session has a single authentication identity/privacy context:

Start a channel with a SASL profile, e.g.,

<start number="1">
    <profile uri="http://.../sasl/OTP">

Or start a channel with a SASL profile that has a security layer, or start a channel with the TLS profile, e.g.,

<start number="1">
    <profile uri="http://.../TLS">
        &lt;ready />

When the underlying negotiation process begins, a tuning reset occurs


16. syslog

A server/client relationship:

    C: establish and tune session
    S: MSG (i'm ready to act as a sink)
    C: ANS (audit entry 1)
    C: ANS (audit entry 2)
    C: ANS (audit entry N)
    C: NUL


17. intrusion detection

An interesting requirement:

Realized using a "tunneling" tuning profile:

     C: establish session to proxy #1
     C: start tunneling profile
     C: specify route (via IP or SRV)

    P1: establish session to proxy #2
    P1: start tunneling profile
    P1: specify remaining route (via IP or SRV)
    Pn: establish session to server
    Pn: start pass-through profile
    Pn: specify empty route

     S: pass back status to Pn

If successful:


18. Operational Taxonomies

Five distinguishing characteristics:

For example:

Messaging applications vary considerably in their operational requirements, e.g., timeliness, reliability, determinism, etc.

These features come at a cost, in terms of both infrastructure and configuration complexity

The underlying service must be extensible to support different requirements in a consistent manner


19. An Application Datagram Service

APEX is about "application-layer relaying"

Looks like the email model:

The APEX model is:

The APEX model is option-driven, allowing:

APEX provides:

The default mode:

The mesh's behavior is modified by self-contained options,


20. Entities

  administrative domain #1        administrative domain #2
+--------------------------+    +--------------------------+
|   +------+               |    |               +------+   |
|   |      |               |    |               |      |   |
|   | appl |               |    |               | appl |   |
|   |      |               |    |               |      |   |
|   +......+     +------+  |    |  +------+     +......+   |
|   |      |     |      |  |    |  |      |     |      |   |
|   |end-  |     |relay |  |    |  |relay |     |end-  |   |
|   | point|     |      |  |    |  |      |     | point|   |
|   +------+     +------+  |    |  +------+     +------+   |
|   |      |     |      |  |    |  |      |     |      |   |
|   | APEX |     | APEX |  |    |  | APEX |     | APEX |   |
|   |      |     |      |  |    |  |      |     |      |   |
|   +------+     +------+  |    |  +------+     +------+   |
|        ||       ||  ||   |    |   ||  ||       ||        |
|        ===========  ================  ===========        |
+--------------------------+    +--------------------------+

             | <-- APEX relaying mesh --> |


21. Modes

Two modes of operation: endpoint-relay and relay-relay

Both modes are peer-to-peer:

Endpoints have names, i.e., "local@domain"

The local-part prefix "apex=" is reserved for APEX services

Relays aren't named, per se

Relays are located using the SRV algorithm:


22. Operations

Applications attach as endpoints, 1:N by default

Relays bind on behalf of administrative domains (FQDNs)

Both exchange datagrams (termed "data")

APEX access policies are used for:

The APEX access service is used for:


23. Enveloping

Envelope contains:

The content is a MIME object, with optimization for XML objects

The URI is usually internal, but can be external


24. An Example

C: MSG 1 1 . 42 1234
C: Content-Type: multipart/related; boundary="boundary";
C:               start="<>";
C:               type="application/beep+xml"
C: --boundary
C: Content-Type: application/beep+xml
C: Content-ID: <>
C: <data content=''>
C:     <originator identity='' />
C:     <recipient identity='' />
C: </data>
C: --boundary
C: Content-Type: image/gif
C: Content-Transfer-Encoding: binary
C: Content-ID: <>
C: ...
C: --boundary--


25. Another Example

C: MSG 1 1 . 42 295
C: Content-Type: application/beep+xml
C: <data content='#Content'>
C:     <originator identity='' />
C:     <recipient identity='' />
C:     <data-content Name='Content'>
C:         <statusResponse transID='86'>
C:             <destination identity=''>
C:                 <reply code='250' />
C:             </destination>
C:         <statusResponse>
C:     </data-content>
C: </data>


26. Options

Options may be present on any operation:

    <!ELEMENT option      ANY>
    <!ATTLIST option
              internal    NMTOKEN           ""
              external    %URI;             ""
              targetHop   (this|final|all)  "final"
              seeNoEvil   (true|false)      "true"
              transID     %UNIQID;          #REQUIRED
              localize    %LOCS;            "i-default">

One option defined: statusRequest


27. The Report Service

Triggered by a relaying seeing a "statusRequest" option,

"targetHop" attribute can be used for traceroute-like functionality

<data content='#Content'>
    <originator identity='' />
    <recipient identity='' />
    <data-content Name='Content'>
        <statusResponse transID='86'>
            <destination identity=''>
                <reply code='250' />


28. The Access Service

Controls access for endpoint reception of data

Controls access to other APEX services

<access owner=''
        lastUpdate='14 May 2000 13:02:00 -0800'>
    <entry actor=''
           actions='all:all' />
    <entry actor=''
           actions='core:data' />
    <entry actor='*'
         actions='core:data presence:subscribe
                            presence:watch' />
    <entry actor='*@*' actions='core:data' />

Two operations:

    get -> access entry or error
    set -> reply (confirmation or error)

Simple spin-lock to avoid write-write conflicts


29. The Presence Service

Repository for rendezvous information

<presence publisher=''
          lastUpdate='14 May 2000 13:02:00 -0800'
    <tuple destination='apex:fred/'
           availableUntil='14 May 2000 14:02:00 -0800' />
    <tuple destination=''
           availableUntil='31 Dec 2525 23:59:59 -0800' />

Four operations:

    subscribe -> event-driven notifications or error

      publish -> reply (confirmation or error)

        watch -> reply,
                 followed by event-driven notifications

    terminate -> reply

Subscribe and watch are duration-based services:

Simple spin-lock to avoid write-write conflicts


30. Status

BEEP's core and TCP mapping specifications:

BEEP Working Group:

APEX Working Group:

The Website:

Open Source Implementations (in progress):