zweig@p.cs.uiuc.edu (06/19/89)
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....)
CERF@A.ISI.EDU (06/20/89)
Johnny, Flaming aside, your points have merit. Please bear in mind, however, that the RFCs were written rather a long time ago when the normal programming paradigms and languages for communication protocol implementation typically used concepts like pointers and function calls/system calls. It is HARD to write good specifications which are readable, applicable to a variety of implementation methods, and specific enough to really tie down the details. Erring in one direction leaves you open to complaints about insufficient detail while erring in the other leads to cries that you've bound the implementation options too severely. Have you done any implementions based on the OSI specifications? Marshall Rose has, and I'm not sure he'd fully concur with your apparent view that these specs are easier to use... Vint Cerf
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (06/25/89)
Indeed, specifications should not be tied to implementations--though
designs should have been done with implementability in mind--that's
why The Book says
An interface
to an interpreter
of a protocol
is NOT
the protocol
(line breaks approximate; haven't found the box that contains the
home copy of The Book yet).
HOWEVER, I do hope you just omitted the joke symbol when you said
that otherwise the 4.3BSD code would be the spec....
fatigued (from upacking around 7500 pounds of Stuff) cheers,
map
-------