Just as data file metaformats have evolved to simplify serialization
for storage, application protocol metaformats have evolved to simplify
serialization for transactions across networks. The tradeoffs are a
little different in this case; because network bandwidth is more expensive
than storage, there is more of a premium on transaction economy.
Still, the transparency and interoperability benefits of textual
formats are sufficiently strong that most designers have resisted
the temptation to optimize for performance at the cost of readability.
The Classical Internet Application Metaprotocol
Marshall Rose's RFC 3117, On the Design of
Application Protocols,[55] provides an excellent overview of the
design issues in Internet application protocols. It makes explicit
several of the tropes in classical Internet application protocols that
we observed in our examination of SMTP, POP, and IMAP, and provides an
instructive taxonomy of such protocols. It is recommended
reading.
The classical Internet metaprotocol is
textual. It uses single-line requests and responses, except for
payloads which may be multiline. Payloads are shipped either with a
preceding length in octets or with a terminator that is the line
".\r\n". In the latter case the payload is
byte-stuffed; all lines that start with a period get
another period prepended, and the receiver side is responsible for
both recognizing the termination and stripping away the stuffing.
Response lines consist of a status code followed by a human-readable
message.
One final advantage of this classical style is that it is
readily extensible. The parsing and state-machine framework doesn't
need to change much to accommodate new requests, and it is easy to
code implementations so that they can parse unknown requests and
return an error or simply ignore them. SMTP, POP3, and IMAP have all
been extended in minor ways fairly often during their lifetimes, with
minimal interoperability problems. Navely designed binary
protocols are, by contrast, notoriouslybrittle.
