RFC 3080: One Connection Was Not One Conversation

Summary

RFC 3080 let several independent exchanges share one BEEP session. Channel zero managed the session, but each application channel acquired syntax and semantics only when the peer accepted a named profile.
A live transport, a valid greeting, an advertised capability, an open channel and a successful application effect were different receipts. None could safely stand in for the next.

The wire was open; the application was not

Imagine two peers with a clean transport connection between them. Both send valid greetings. Each can parse channel zero. Yet every profile proposed for the first application channel is refused.

Nothing is wrong with the wire. Nothing is malformed in the session-management exchange. But there is still no application conversation.

That diagnostic captures the design choice at the center of RFC 3080. Published in March 2001 on the Standards Track, the Blocks Extensible Exchange Protocol Core described a generic kernel for connection-oriented, asynchronous applications. It did not assign one application meaning to a connection. Instead, it created a session in which multiple independent exchanges could coexist under one application user identity.

The distinction started below the application. RFC 3080 defined the BEEP core, but left the mapping to an underlying transport to separate documents. RFC 3081, for example, mapped one BEEP session onto one TCP connection. TCP establishment was therefore a transport receipt. It was not an application choice, and it was not evidence that a useful profile would be accepted.

Channel zero was a manager, not the work

At session start, only channel zero existed. It carried the channel-management profile: greetings, advertisements of supported profiles, requests to start channels, requests to close them and, eventually, release of the session.

The greeting was deliberately modest. A peer listed profiles it could support while acting in the server role. The other peer did not thereby acquire a channel using any of them. Advertisement was capability evidence, not selection. RFC 3080 even warned readers not to infer ordering from an example in which one greeting appeared first: both peers sent their replies independently.

To obtain a working lane, a peer sent start on channel zero. It named a proposed channel number and offered one or more profile URIs. The recipient selected one profile in a positive reply or rejected the channel when none was acceptable. The accepted URI was the binding event. Before it, the number was only a proposal.

The numbering rule was a small example of a thin common mechanism. The initiating peer chose odd positive channel numbers; the listening peer chose even ones. Each side could create channels without asking a central allocator and without colliding with the other. It was coordination by deterministic partition, not by continuing authority.

The profile supplied the meaning

A BEEP channel was a lane, not a complete application protocol. The profile bound to it defined message syntax and semantics. RFC 3117 later summarized the construction plainly: an application protocol was BEEP plus one or more profiles.

The core contributed exchange forms. MSG began a request. RPY or ERR completed a one-to-one exchange. ANS carried one of multiple answers, and NUL ended that one-to-many series. Message numbers distinguished exchanges inside a channel, while payload sequence numbers advanced across every frame on the channel.

Those mechanics allowed concurrency without collapsing meaning. Frames from different channels could interleave. A segmented message remained sequential within its own channel, except that multiple ANS replies could be interleaved and later collated by answer number. One channel could be busy while another progressed. But interleaving did not prove fairness, completion or equal priority; it only defined what ordering remained valid.

The same boundary appeared in later profiles. RFC 3195 used BEEP profiles for reliable syslog delivery. RFC 4227 gave SOAP its own profile identifiers and boot-to-ready state. RFC 4744 mapped NETCONF onto a profile and kept manager/agent roles separate from BEEP’s initiator/listener roles. Each application inherited the lane machinery, then had to define what a message meant and what counted as ready.

Security tuning changed the session, not the outcome

RFC 3080 distinguished initial-tuning channels from continuous application channels. TLS and SASL could alter the security conditions of the session before sustained data exchange began. Only one tuning channel could be active at a time.

That sequencing mattered because pre-tuning observations were not automatically trustworthy after security changed. The TLS discussion required peers to discard cached session information from before successful negotiation: an active attacker might have modified it. A new protected state needed new evidence, not a decorative lock placed over stale assumptions.

Authentication also did not erase authorization. RFC 3080 said a channel should apply access control appropriate to the authenticated identity and privacy level before performing work. A session could know who a peer was and still refuse a profile, a channel or a particular operation.

Sharing one connection created a second control problem

Multiplexing independent channels over one substrate saved connections, but it also made resource contention visible. RFC 3081 noted that TCP flow control operated per connection. Without another mechanism, a slow or greedy BEEP channel could starve or deadlock its neighbors.

The TCP mapping therefore added per-channel sliding windows and SEQ frames. A newly created channel began with a 4096-octet window. The receiver advertised the next expected sequence number and the payload window it could accept. This was not retransmission; TCP already handled reliable delivery. It was local admission control inside a shared transport.

That detail belongs to RFC 3081, but it illuminates RFC 3080. Independence was not created by drawing channel numbers on one stream. It required separate accounting, separate progress and a rule for who could consume shared capacity.

A later port release did not rewrite the earlier layers

BEEP acquired real profile specifications: reliable syslog, SOAP and NETCONF among them. It also acquired lifecycle evidence. RFC 9900 later released the port numbers assigned to NETCONF over BEEP and NETCONF over SOAP while retaining the service names.

That record should not be bent into a victory or a failure myth. An RFC can define a coherent architecture without winning permanent deployment. A service name can survive after a numeric port is released. An application profile can disappear from common use without making the distinction between connection, negotiated meaning and effect less valid.

The historical lesson is narrower. RFC 3080 refused to let the lowest visible success absorb every higher claim. The wire could be open while no profile was selected. A profile could be selected while access was denied. A reply could be received while no external state changed.

One Connection Was Not One Conversation: RFC 3080

Why it matters

Summary

The wire was open; the application was not

Channel zero was a manager, not the work

The profile supplied the meaning

Security tuning changed the session, not the outcome

Sharing one connection created a second control problem

A later port release did not rewrite the earlier layers

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing