Summary

  • RFC 3205 treated HTTP reuse as a design choice with inherited behavior, not as a shortcut that automatically delivered interoperability or security.
  • Its central burden was explicitness: define service identity, methods and media types, proxy interaction, caching, and the boundary between HTTP errors and application outcomes.

The bargain had another party

By early 2002, HTTP offered a tempting kit for new application protocols: developers knew it, browsers could speak it, servers and client libraries already existed, and TLS or familiar authentication might be available. If a site already served the Web, another application could appear cheaper to prototype on the same machinery. Passing through a firewall was also cited as an advantage. The bargain seemed to be “reuse the installed base.”

RFC 3205, Keith Moore's BCP 56, made the less visible counterparty part of the design. HTTP was not only an encoding exchanged by two endpoints. A request could meet a client library, a proxy, a cache, a firewall, a NAT, a web server and then application code—each with its own reading of familiar fields. Saving effort in one component did not make those components share the application's meaning.

The memo was deliberately advice, not a conformance specification. It said so and avoided RFC 2119's capitalized requirement words. Its point was not that every application should avoid HTTP. It was that the choice should be made with costs and boundaries visible. HTTP had accumulated persistence, ranges, content negotiation and caching. A layered protocol might inherit features it did not need, then spend effort profiling them away. For very small, frequent transactions, TCP and HTTP overhead could matter; persistent connections could reduce the connection cost when several exchanges reused one open session.

Familiar status codes could tell the wrong story

The difficult case was not necessarily a malformed request. It was a response that one layer called success while another layer understood as an application failure. A proxy did not need to know the new application to act on HTTP semantics. Under ordinary conditions, it could cache a successful response. An intermediary could also replace or augment an error body. The client might therefore receive a valid HTTP response whose application meaning had been made stale, obscured or altered.

RFC 3205 separated errors detected in HTTP's request line and headers from outcomes encoded by the layered application. If an application used generic 200 or 500 responses for body-level results, it had to specify how successful responses avoided harmful caching and how clients survived transformed error bodies. If the protocol could not function when an intermediary cached or changed those responses, the memo advised against using HTTP as its substrate. That is more precise than saying “HTTP status codes are bad”: the risk arose where HTTP's generic success/failure model and the application's transaction model diverged.

The same boundary appeared in media types and methods. A content type could identify what an object was, but did not by itself authorize an operation on it. The application had to make its action explicit. Nor did inventing a new HTTP method automatically settle whether a distinct service needed its own port or URI scheme.

Reuse included identity and deployment

Port 80 and http: already meant something to operators, software and users. RFC 3205 asked whether a service had separate data, code, process or traffic-control needs; those differences could justify a distinct port. A widely used service with different setup, credentials or provisioning might need its own URI scheme rather than an http: label that hid the distinction. The memo treated this as a question of service identity and operations, not naming aesthetics.

Libraries brought their own assumptions too. A client could need to translate a custom service URL into an HTTP-shaped URL for a library; a proxy might then see the absolute URL and interpret it as ordinary HTTP. Reused code could transmit HTTP/1.1 even where the application needed to say how that version label should be understood. The specification—not a hopeful assumption about a library—had to describe the interaction among client, server and proxy.

That shifts the economics of reuse. Existing code can reduce the cost of the first implementation, but its generic behavior becomes part of the system boundary. More independent implementations mean more chances for a shortcut in one client to collide with a cache rule, proxy behavior or server assumption elsewhere. This is an inference from the memo's design analysis, not a measured estimate of engineering expense or evidence that any named protocol failed.

A successor records the pattern's persistence

RFC 9205 replaced RFC 3205 in 2022 as BCP 56, after two decades of HTTP development and experience. It addresses HTTP-based APIs across separate implementations, asynchronous client and server evolution, extensibility, caching, state, authentication and coexistence with Web browsing. Its existence shows the design problem remained relevant enough for updated guidance. It does not prove universal adoption of either document, or that the 2002 advice predicted every later API practice.

The historical lesson is narrower and more useful: protocol reuse does not erase a boundary; it moves the boundary into the semantics of shared software. An implementation can compile against an HTTP library and still disagree with another implementation about what a response means. Interoperability requires spelling out what the surrounding HTTP system may do, what the application must do, and which layer owns each result.

The contemporary architecture vocabulary for devices between endpoints is developed in RFC 3234. For the original HTTP/1.1 context, see RFC 2616; the requirement-word convention RFC 3205 chose not to use is specified in RFC 2119. The authoritative text, record and later replacement are RFC 3205, its RFC Editor record, the IETF Datatracker record, RFC 9205 and its RFC Editor record.