| 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):