Most RFCs define a protocol. RFC 3117 is different: it's Marshall Rose stepping back after two decades of designing application protocols (SMTP extensions, SNMP, BEEP, the Internet Message format) to write down the taste behind that work. It is an Informational RFC, not a standard, and reads more like an essay by a craftsman than a specification. If you have ever had to argue with a colleague about whether to use HTTP, gRPC, raw TCP, or roll your own framing, this is the document you wish they had read first.

Rose organizes the design space around a handful of axes that every application protocol implicitly answers, whether the designers realize it or not:

• Connection lifecycle: connection-oriented vs. connectionless, and whether one connection carries one exchange (HTTP/1.0), many serialized exchanges (HTTP/1.1 keep-alive), or many interleaved exchanges (BEEP, HTTP/2, AMQP).
• Framing: octet-stuffed delimiters (SMTP's lone .), length-prefixed records, or self-describing structures. Rose is blunt that delimiter-based framing is almost always a mistake — it forces escaping, and escaping forces parsers to scan every byte.
• Encoding: textual (human-debuggable, expensive to parse, ambiguous about whitespace) vs. binary (compact, fast, opaque on the wire). He notes the textual-protocol religion is largely a historical accident of 7-bit telnet links.
• Reporting: in-band status codes, out-of-band events, and whether errors are transient or permanent — a distinction SMTP got right with its 4xx/5xx split and that nearly everyone since has copied.
• Asynchrony: can the server push? Can a client have multiple outstanding requests? Is ordering preserved per-channel or globally?

The document's most cited contribution is the section on common pitfalls. Rose enumerates the ways protocols rot: assuming the network is reliable, conflating identification with authentication, making the protocol depend on the transport's flow control instead of providing its own, building in versioning that nobody can actually use, and — his favorite target — putting policy into the protocol when it belongs in the application. The "robustness principle" (be liberal in what you accept) gets a careful re-examination: Rose argues that liberal acceptance creates de facto standards out of bugs, a critique that became orthodoxy two decades later when Postel's principle fell out of favor.

There's a wonderful section on scalability that distinguishes three independent axes — number of concurrent users, size of individual exchanges, and rate of exchanges per user — and points out that protocols optimized for one axis (say, HTTP for many short exchanges) often fail spectacularly on another (long-lived streaming). This framing predates and predicts every "WebSockets vs. long-polling vs. SSE vs. gRPC streaming" debate of the 2010s.

The backstory: Rose wrote this while developing BEEP (RFC 3080), a generic application-protocol framework that was supposed to be the substrate for everything from SYSLOG to network management. BEEP itself never caught on — HTTP ate the world instead — but RFC 3117 outlived its sponsor protocol because the analysis is independent of the conclusion. Read it today and you'll find a checklist that quietly grades HTTP/2, QUIC, gRPC, MQTT, and whatever JSON-over-WebSocket thing your team is currently shipping.