The Blocks Extensible Exchange Protocol Core
Extracted elements (30)
Message numbers are unidirectionally-significant: msgno values in MSG messages from the initiating peer are independent of those from the listening peer. This reflects BEEP's peer-to-peer nature where both sides can concurrently send MSG messages on the same channel number.
Only one tuning channel may be established at any given time, in contrast to multiple simultaneous data exchange channels. This is because tuning channels (transport security, authentication) perform initialization with global session impact and must not be run concurrently to avoid race conditions on session state.
All BEEP peers, including those acting only in the client role, MUST be prepared to receive MSG messages and handle them gracefully. All profiles must provide an appropriate error message for unexpected MSG messages, reflecting BEEP's peer-to-peer nature.
Transport mapping documents MUST define how a BEEP session is established and released, how initiating vs. listening roles are identified, how messages are reliably sent/received in order on a single channel, and how messages on different channels are sent without ordering constraints.
A BEEP peer acting in the server role MUST process all MSG messages for a given channel in the order received, and MUST generate replies in that same order for a given channel.
Before accepting a close request, a BEEP peer MUST finish sending queued MSG messages, await complete replies to outstanding MSG messages, and finish sending complete replies to outstanding received MSG messages. The peer MUST also be prepared to process MSG messages received on the channel until a positive close reply is received.
If a BEEP peer acting as server sends a pre-emptive negative reply before receiving the final MSG frame, it MUST ignore subsequent MSG frames for that message. If the client receives a negative reply before sending the final frame, it MUST send a MSG frame with continuation '.' and zero-length payload.
If a frame is poorly-formed (bad keyword, invalid parameters, unknown channel, mismatched sequence number, incorrect NUL usage, etc.), the session MUST be terminated without generating a response; logging a diagnostic entry is RECOMMENDED.
Once transport security (TLS) is successfully negotiated, a SASL security layer MUST NOT be negotiated; conversely, once any SASL negotiation is successful, a transport security profile MUST NOT begin its underlying negotiation process.
The 'serverName' attribute from the first successful 'start' element is binding for the BEEP session duration. Subsequent 'serverName' values are ignored.
To avoid channel number conflicts, BEEP peers in the initiating role MUST use only odd positive integers for channel numbers; peers in the listening role MUST use only even positive integers.
When a BEEP peer sends the 'ready' element to initiate TLS, it MUST NOT send any further traffic on the underlying transport service until a 'proceed' or 'error' reply is received.
When a message is segmented into multiple frames, those frames MUST be sent sequentially on the same channel without interleaving frames from other messages on that channel. The exception is ANS frames in a one-to-many exchange, which MAY be interleaved using the ansno for collation.
Whenever a successful SASL authentication occurs, the authenticated identity is updated for ALL existing and future channels on the BEEP session, and no additional authentication attempts are allowed.
BEEP is a generic application protocol kernel for connection-oriented, asynchronous interactions. All exchanges occur in the context of a channel, each bound to a profile that defines the syntax and semantics of messages exchanged. Messages are arbitrary MIME content, typically XML.
BEEP supports three exchange styles: MSG/RPY (one-to-one positive reply), MSG/ERR (one-to-one negative reply), and MSG/ANS...NUL (one-to-many reply where the server streams zero or more ANS messages followed by a NUL terminator).
Channel zero is the only channel defined at session start and is reserved for channel management. Channel management allows peers to advertise supported profiles (via greeting), create channels (via start), and close channels or release sessions (via close). A BEEP peer SHOULD support at least 257 concurrent channels.
The 'close' element is sent on channel zero to close a channel (number != 0) or release the session (number == 0). It carries a numeric reply code and optional xml:lang and textual diagnostic. A peer receiving a close request MAY reject it with an error, or MUST drain all queued/outstanding MSG messages before accepting with an 'ok' reply.
The SASL family of profiles maps each IANA-registered SASL mechanism to a URI 'http://iana.org/beep/SASL/mechanism'. Challenges and responses are exchanged as 'blob' elements (always base64-encoded). The 'blob' element carries an optional 'status' attribute: 'abort' (client aborts), 'complete' (server signals success), or 'continue' (default).
The 'start' element is sent on channel zero to create a new channel. It carries a 'number' attribute (channel id), an optional 'serverName' attribute, and one or more 'profile' elements each with a 'uri', optional 'encoding', and an optional initialization message up to 4K octets. The server replies with the selected profile element or an error.
Upon session establishment both peers immediately send a positive reply with msgno 0 on channel zero containing a 'greeting' element. The greeting lists supported profiles (via 'profile' elements), and optionally 'features' (optional channel management features) and 'localize' (preferred language tags for diagnostics).
The IANA maintains a registry of standards-track BEEP profiles (per the profile registration template in Section 5.1) and a registry of standards-track features for the channel management profile (per Section 5.2). Non-standards-track feature identifiers must begin with 'x-'. The IESG designates an expert to review submissions.
The MIME media type 'application/beep+xml' is registered. It is a subset of XML 1.0 that prohibits entity references other than the five predefined general entities and numeric references, and prohibits XML and DOCTYPE declarations. The charset parameter defaults to UTF-8.
A man-in-the-middle may cause down-negotiation to the weakest available cipher suite. A BEEP peer SHOULD be configurable to refuse weak cipher suites, and administrators should carefully choose which ciphersuites are provisioned.
A man-in-the-middle may modify protocol exchanges prior to successful TLS negotiation. Upon completing negotiation, a BEEP peer MUST discard previously cached information about the BEEP session.
A man-in-the-middle may remove security-related profiles from the BEEP greeting or generate a negative reply to the TLS 'ready' element, preventing security negotiation. A BEEP peer SHOULD be configurable to refuse to proceed without an acceptable level of privacy.
Before performing any task associated with a message, each channel SHOULD apply appropriate access control based on the authenticated identity and privacy level associated with the BEEP session. Authorization is an internal matter for each peer; unauthorized operations may be rejected with error code 530.
TLS negotiation state: (1) client sends 'ready' element in channel creation and stops sending traffic; (2) server, upon processing 'ready', drains pending replies then sends 'proceed', implicitly closes all channels including channel zero; (3) client receives 'proceed', implicitly closes all channels and begins TLS handshake; (4) upon completion (success or failure) both peers issue new greetings.
A BEEP frame consists of a header, payload, and trailer. The header encodes keyword (MSG/RPY/ERR/ANS/NUL), channel (0..2147483647), msgno (0..2147483647), more indicator ('*' or '.'), seqno (0..4294967295), size (0..2147483647), and for ANS frames, ansno (0..4294967295). The trailer is the literal string 'END' followed by CRLF.
Every payload octet on a channel has an associated sequence number starting at 0 when the channel is created. Sequence number arithmetic is performed modulo 2^32 (range 0..4294967295). The expected seqno for the next frame equals (seqno + size) mod 4294967296.