"So why," I am asked from time-to-time, "should we bother thoroughly specifying on-the-wire protocols? Why isn't just having the app (or whatever) open a socket to the other machine and schlep bytes over to it good enough? Why isn't it good enough to hide the protocol behind an API and only think about this protocol stuff in terms of APIs?" Examples of this are various apps or chunks of middleware which are built in a given environment and on a given (set of) platform(s). Often, it seems, the "protocols" aren't designed per se, rather APIs are designed and some common technique (perhaps one that's a feature of the environment this is being done within, e.g. SUN ONC RPC) is used "under the hood" of the API to actually get bits across the wire in a coherent fashion, but the on-the-wire protocol per se is (often) never designed and/or documented as such (in these situations). Most everyone on this list "gets" why we (the IETF community) design and document protocols from an on-the-wire perspective -- but I can't seem to find it concisely written down anywhere. What I'm looking for is existing documents that concisely explain this reasoning (so I can use 'em when trying to answer the above class of questions). E.g. I've been trying to RTFM and have looked at.. Architectural Principles of the Internet http://www.ietf.org/rfc/rfc1958.txt The Design Philosophy of the DARPA Internet Protocols. D.D.Clark, Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August 1988. http://netweb.usc.edu/cs551f00/papers/Clark.pdf End-To-End Arguments in System Design. J.H. Saltzer, D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984. http://www.reed.com/Papers/EndtoEnd.html Stacks: Interoperability in Today's Comuter Networks. Carl Malamud, 1992. Computer Networks. Andrew Tanenbaum, 1981 (yes, my bookshelf is dusty). Internetworking with TCP/IP: Principles, Protocols, and Architecture. Douglas Comer, 1988. ..plus poked about in http://www.ietf.org/ and with http//google.com/, and yet I haven't been able to find a paper, book, or whatever that clearly and concisely says something like.. "when designing computer-to-computer network communications, it behooves the designers to do so from an on-the-wire protocol perspective, because blah, blah, blah..." [true story: while I was researching/writing this, someone dropped by to ask some questions w.r.t. an "industry leading" vendor's authentication server. We were discussing communication between the server and code running on another node, and I said something like "..and so one uses some protocol to talk with the server, right?", and he says "Right, they've defined an API that you call." and gives me an otherwise blank look. ~sigh~ ] Now, Comer does come pretty close with this bit in section 1.3 of the above-referenced book.. Much of our discussion of services will focus on standards called "protocols". Protocols, like TCP/IP, give the formulas for passing messages, specify the details of message formats, and describe how to handle error conditions. Most important, they allow us to discuss communication standards independent of any particular vendor's network hardware. In a sense, protocols are to communication what programming languages are to computation. A programming language allows one to specify or understand computation without knowing the details of any particular CPU instruction set. Similarly, a communication protocol allows one to specify or understand data communication without depending on a detailed knowledge of a particular vendor's network hardware. ..and I do like his analogy of protocols as compared to (higher than assembly) programming languages. But I guess I'm looking for something more fleshed out and focused on this point. Anyone have any ideas and/or relevant pointers? thanks, JeffH ps: I note that RFC 1983 has a nice concise definition for "protocol".
