"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".