Subject: why specify on-the-wire protocols?

From: [email-masked]
Date: Tue, 07 Nov 2000 23:45:51 -0800

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