Summary

  • RFC 3195's RAW profile carries familiar syslog messages over BEEP, whose channel promises reliable, ordered message delivery; COOKED adds structured entries and positive or negative replies for each entry.
  • These mechanisms answer different questions. A delivered frame or <ok/> is not, by itself, proof of event origin, durable storage, indexing, or operational response.

The word “reliable” can sound broader than the protocol guarantee. RFC 3195, published in November 2001 as a Standards Track memo, maps syslog onto BEEP, a connection-oriented framework. Its two profiles expose a useful design choice. RAW favors low overhead and backward compatibility: the payload keeps the legacy syslog form, while BEEP supplies reliable, ordered delivery on an individual channel. COOKED uses structured operations and allows each entry to receive an ok or an error. It is a protocol answer about that entry, not a receipt for every later stage of a logging system. (RFC 3195 §§1, 3.1, 4.4.2)

Consider the evidence chain. A sender emits an event; a BEEP peer receives a complete message; a COOKED listener may accept or reject an entry; a collector may parse it, write it, index it, replicate it, or create an alert. Those are separate state changes. RFC 3195 defines the first transport and profile exchanges, not a general storage transaction. Even <ok/> does not specify whether the collector flushed to durable media or whether downstream consumers saw the record. An error can be an administrative refusal, which is evidence of a policy decision—not evidence that the event never existed.

The separation is visible in RAW. BEEP's frame trailer marks the end of a message, and its mapping defines reliable, in-order delivery within the channel. But RAW's opening listener message has no syslog-entry semantics; the initiator's answer carries one or more entries. The document also sets a 1,024-byte ceiling for each RAW event body, explicitly excluding BEEP framing overhead. That is a payload boundary, not a promise of durable retention. It differs from RFC 3164's whole-packet limit and relay-truncation issue, which is a separate mechanism. (RFC 3195 §3.3; RFC 3164)

RFC 3195 is unusually candid about another gap: BEEP can protect communication without protecting the message object. Its security section says a compromised device could generate incorrect messages, and relays or collectors could modify, insert, or delete them without detection unless additional techniques were used. The memo treats authentication, replay protection, integrity, and confidentiality as separately provisioned services. A secured channel may authenticate a peer on one hop; that identity is not automatically the same as the hostname written in an event, nor an end-to-end signature over the event itself. (RFC 3195 §§5, 10; RFC 5425 §4)

Later syslog work makes the distinction even clearer. RFC 5848 defines signed message blocks that can support origin authentication, integrity, replay resistance, sequencing, and detection of missing messages. It separately warns that reliable transport cannot prevent application-layer loss—for example, when a receiver closes a TCP or TLS session. That is not proof that RFC 3195 was broadly deployed or that signatures solve every retention problem. It shows that delivery, authenticity, and completeness require different evidence. (RFC 5848 §§1, 8.3–8.7)

The design's lasting value is its precision about scope. RAW can answer, “Did this BEEP channel reliably deliver its message in order?” COOKED can add, “Did this listener reply positively or negatively to this entry?” Neither can answer, without other controls, “Was the event authentic?”, “Did it survive a storage failure?”, or “Did an operator respond?” For incident review, the audit trail should preserve transport/session status, per-entry replies, signature verification, collector persistence, and downstream processing as different receipts.

RFC 3195 specifies protocol behavior; the available sources do not establish current implementation prevalence or performance.

Sources: RFC 3195; RFC 3195 current RFC Editor record; RFC 3195 IETF Datatracker text; RFC 3080, The BEEP Core; RFC 3081, BEEP over TCP; RFC 3164, The BSD Syslog Protocol; RFC 5424, The Syslog Protocol; RFC 5425, TLS Transport Mapping for Syslog; RFC 5426, Syslog UDP Transport; RFC 5848, Signed Syslog Messages; RFC 6587, Transmission of Syslog Messages over TCP; RFC 2782, DNS SRV; RFC 2119, Requirement-Level Keywords.