> Now, anyone who takes this approach [designing something
> "lightweight" instead of TCP] is quite clearly implicitly saying that
> that the TCP designers, and everyone who looked at it since, are too
> inept to see how to design a more-lightweight protocol.

Not always; sometimes just that existing protocols (such as TCP) are
designed based on assumptions that are invalid for the task at hand.

For example, I once designed a file transfer protocol that used UDP (it
was somewhat like TFTP, only with some checksumming guff added).  It
was designed to survive certain kinds of brokenness I was struggling
with at the time, brokenness which among other things broke TCP.  This
does not mean that there's anything wrong with TCP within its design
parameters, just that I wanted something suitable for an environment
that was outside those parameters.  (Not that it's really a case of
lightweight versus heavyweight, just an example of a case where
designing a new protocol does not necessarily imply any slight on
existing protocols.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B