Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!aurora!labrea!agate!ucbvax!QUABBIN.SCRC.SYMBOLICS.COM!DCP
From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP-IP Verification Suite
Message-ID: <19880204221500.5.DCP@SWAN.SCRC.Symbolics.COM>
Date: 4 Feb 88 22:15:00 GMT
References: <922@thumper.bellcore.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 30


    Date: 2 Feb 88 19:32:51 GMT
    From: thumper!karn@faline.bellcore.com  (Phil R. Karn)

    a) getting rid of gaps and ambiguities in the specs themselves that can
    allow different implementations to "conform" yet not be interoperable, and

You forgot (that goes between a and b):
Convincing a vendor that his implementation is broken.  

I remember when I was testing the TCP I wrote for Symbolics LispMs.  We
were one of the first to use segments with overlapping sequence numbers
in a big way (mostly for telnet).  It didn't work with Unix machines.
The response was "Well, Unix is right, so you must be doing something
wrong."  

We then got calls from people trying to communicate between our machines
and Apollo.  Apollo said "We have no trouble talking to Unix machines."

We still have a similar problem with Unix TCP/FTP giving a reply code
for some operation, DELETE I think, that is not what the FTP spec says
it should be.  The typical answer from Unix people is "You should only
look at the first digit; the others are secondary information."  And we
respond with "The spec says it should return <xyz>."  And it goes 'round
and 'round.

I'm not saying we don't occaisionally pass the buck without looking; I'm
just relaying anecdotes of how difficult things can be.

    b) figuring out how to armtwist the vendor of a broken implementation to
    fix it once a problem has been identified.