TOC |
|
TOC |
TOC |
I-Ds on BEEP:
I-Ds on apex:
Other I-Ds:
TOC |
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
TOC |
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
TOC |
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)
TOC |
(Graphic courtesy of Bob "RL" Morgan, University of Washington)
TOC |
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
TOC |
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?
TOC |
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 <greeting> <profile uri="http://.../TLS" /> <profile uri="http://.../SEP" /> <profile uri="http://.../sasl/OTP" /> <profile uri="http://.../sasl/..." /> </greeting> END <start number="1"> <profile uri="..."> ... </profile> <profile uri="..."> ... </profile> </start> <close number="1" code="200" />
TOC |
A registration template defines:
Two kinds of profiles:
Protocol =
BEEP + 1 or more profiles + authorization policies + provisioning rules
Exchanges:
MSG -> RPY MSG -> ERR MSG -> zero or more ANS, followed by NUL
TOC |
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.,
TOC |
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
TOC |
Channels handle asynchrony:
Segmentation is handled by framing
So, what about flow control?
TOC |
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:
TOC |
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.,
TOC |
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"> <blob>AGJsb2NrbWFzdGVy</blob> </profile> </start>
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"> <ready /> </profile> </start>
When the underlying negotiation process begins, a tuning reset occurs
TOC |
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
TOC |
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:
TOC |
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
TOC |
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,
TOC |
administrative domain #1 administrative domain #2 +--------------------------+ +--------------------------+ | +------+ | | +------+ | | | | | | | | | | | appl | | | | appl | | | | | | | | | | | +......+ +------+ | | +------+ +......+ | | | | | | | | | | | | | | |end- | |relay | | | |relay | |end- | | | | point| | | | | | | | point| | | +------+ +------+ | | +------+ +------+ | | | | | | | | | | | | | | | APEX | | APEX | | | | APEX | | APEX | | | | | | | | | | | | | | | +------+ +------+ | | +------+ +------+ | | || || || | | || || || | | =========== ================ =========== | +--------------------------+ +--------------------------+ | <-- APEX relaying mesh --> |
TOC |
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:
TOC |
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:
TOC |
Envelope contains:
The content is a MIME object, with optimization for XML objects
The URI is usually internal, but can be external
TOC |
C: MSG 1 1 . 42 1234 C: Content-Type: multipart/related; boundary="boundary"; C: start="<1@example.com>"; C: type="application/beep+xml" C: C: --boundary C: Content-Type: application/beep+xml C: Content-ID: <1@example.com> C: C: <data content='cid:2@example.com'> C: <originator identity='fred@example.com' /> C: <recipient identity='barney@example.com' /> C: </data> C: --boundary C: Content-Type: image/gif C: Content-Transfer-Encoding: binary C: Content-ID: <2@example.com> C: C: ... C: --boundary-- C: END
TOC |
C: MSG 1 1 . 42 295 C: Content-Type: application/beep+xml C: C: <data content='#Content'> C: <originator identity='fred@example.com' /> C: <recipient identity='barney@example.com' /> C: <data-content Name='Content'> C: <statusResponse transID='86'> C: <destination identity='barney@example.com'> C: <reply code='250' /> C: </destination> C: <statusResponse> C: </data-content> C: </data> C: END
TOC |
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
TOC |
Triggered by a relaying seeing a "statusRequest" option,
"targetHop" attribute can be used for traceroute-like functionality
<data content='#Content'> <originator identity='apex=report@example.com' /> <recipient identity='fred@example.com' /> <data-content Name='Content'> <statusResponse transID='86'> <destination identity='barney@example.com'> <reply code='250' /> </destination> </statusResponse> </data-content> </data>
TOC |
Controls access for endpoint reception of data
Controls access to other APEX services
<access owner='fred@example.com' lastUpdate='14 May 2000 13:02:00 -0800'> <entry actor='wilma@example.com' actions='all:all' /> <entry actor='mr.slate@example.com' actions='core:data' /> <entry actor='*@example.com' actions='core:data presence:subscribe presence:watch' /> <entry actor='*@*' actions='core:data' /> </access>
Two operations:
get -> access entry or error set -> reply (confirmation or error)
Simple spin-lock to avoid write-write conflicts
TOC |
Repository for rendezvous information
<presence publisher='fred@example.com' lastUpdate='14 May 2000 13:02:00 -0800' publisherInfo='http://www.example.com/fred/'> <tuple destination='apex:fred/appl=im@example.com' availableUntil='14 May 2000 14:02:00 -0800' /> <tuple destination='mailto:fred@flintstone.com' availableUntil='31 Dec 2525 23:59:59 -0800' /> </presence>
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
TOC |
BEEP's core and TCP mapping specifications:
BEEP Working Group: bxxpwg@invisible.net
APEX Working Group: apexwg@invisible.net
The Website: http://bxxp.org/
Open Source Implementations (in progress):