Keep encoding, delivery and security limits visible
05Correct framing locates messages in bytes. It does not determine their character encoding, promise durable storage or secure the transport. This Historic description helps explain existing deployments while pointing new systems toward the separately specified TLS transport.
Plain-TCP framing leaves observer access and tampering concerns unresolved. The drawing separates legacy interoperability from the recommended RFC 5425 TLS transport. TLS is a different transport mapping, not a flag inside the decimal length prefix.
Source for this drawing: RFC 6587 · Read RFC section 5 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
An intact frame is neither authenticated data nor proof of end-to-end processing.
- Legacy implementations have been observed changing framing methods from one frame to the next (§3.4.3). The RFC calls that probably not a good idea. It defines no in-band capability negotiation that makes every receiver support such a switch.
- The legacy transport framing carries no character-set or encoding indicator (§3.1). Relays have forwarded messages in their received encodings, so one connection can carry different encodings. Dropping or rewriting non-ASCII octets damages encodings such as UTF-8 and is described as poor practice. Message-format indicators such as RFC 5424’s BOM are a separate layer.
- TCP supplies transport-level recovery and flow control, but this syslog transport adds no application-level receipt confirmation. A TCP ACK does not prove that the collector parsed, saved or acted on the message.
- The IESG Note and §4 recommend RFC 5425 TLS transport and do not recommend new plain-TCP deployments except to interoperate with existing systems. §5 says plain TCP here has no meaningful security provisions: authentication, integrity protection and privacy are absent. Framing does not repair that.
- The RFC is Historic, April 2012, with no formal update or obsoletion relationships. The TLS mapping is recommended complementary work, not an invented formal replacement edge. This guide does not turn historical observations into uppercase MUST/SHOULD/MAY mandates or repeat old TLS-version requirements as current policy.
TLS means Transport Layer Security. The picture is an applicability/trust comparison, not a TLS handshake or deployment recipe. Modern TLS background is optional reading; no DNS, listener, port, account, logging service or security setting is changed.
Read the RFC section ↗