Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!csd4.milw.wisc.edu!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!zweig
From: zweig@p.cs.uiuc.edu
Newsgroups: comp.protocols.tcp-ip
Subject: Specification vs. Implementation
Message-ID: <93400026@p.cs.uiuc.edu>
Date: 18 Jun 89 22:40:00 GMT
Lines: 51
Nf-ID: #N:p.cs.uiuc.edu:93400026:000:3258
Nf-From: p.cs.uiuc.edu!zweig    Jun 18 17:40:00 1989


   I have been looking over the draft printouts of the Host Requirements
RFCs and there are a few points that both confuse and bother me.
   It seems to me that there is a big difference between a specification and an
implementation. That's why RFCs exist -- otherwise, source code to the
BSD 4.3 implementation of TCP/IP would be published as "the protocol"....
   So why on Earth does the Host Requirements (draft) RFC tell me that when
I implement my IP I need to provide calls that specify, among other things,
pointers to buffers? And, while I'm asking about RFCs, why does RFC 793
call SYN-SENT/ESTABLISHED/etc. "states" when, according to p.70, the SYN-
RECEIVED state needs to know whether the connection was originally opened
passively or actively -- i.e. a state that cares which state it was entered
from? There should be 2 states: SYN-RECEIVED-AND-I-USED-TO-BE-IN-LISTEN and
the complementary one. Of course, there's the boo-boo involving SND.WL1 and
SND.WL2 never getting initialized.
   Yes yes yes yes yes! I know that it is pointed out that there is no need
to implement the calls literally -- "A host implemntation MUST support the
logical information flow implied by these calls, but need not literally
implement the calls themselves." If the requirement is _for_ information
flow, shouldn't it be _in terms of_ information flow? I guess I just don't
see the point of using function-calls that can probably be traced back to a
specific implementation to express ideas which can be cast just as clearly
in other terms.
   It seems to me that specifying a protocol in terms of assigning stuff to
variables and calling functions with pointers is missing an important point.
   I suppose I would just like to see the phrase "for example" appear more
often....
   Granted, I detest the long-winded, nit-picky, incomprehensible way the ISO
specifies things as much as the next guy -- but at least a protocol is
specified in terms of what services it needs to provide -- not which variables
to increment...
   I've never written a line of code that uses mbufs, and I never intend to.
If I want to write in C++ and use new/delete to have memory management
handled by lovingly hand-crufted code to do it, I don't want to have my boss
shake a finger at me and say "this doesn't comply with the host-requirements
RFC:  you don't have a pointer to a buffer, and you use an error-object to
handle error-reporting, and...."
   It's not a huge point, really -- so please don't burn my house down for
going on about it. But it seems like a messy way to do something that alot of
people have worked hard to come up with ways to do cleanly.
   The chains binding specification to implementation need to be broken once
and for all, and I think June 1989 is high time. Protocols ought to be
specified in terms of functionality, not function-calls.

-Johnny Zweig
-------------------------------------------------------------------------------
 (These opinions are my own -- and maybe I'm just cranky because I've been
  trying to write an object-oriented implementation of TCP and not getting
  enough sleep. So don't blame the UIUC Department of Computer Science for
  engendering or encouraging a jerk like me; I just use their 56 kbps line to
  Purdue....)