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: <19880204220953.4.DCP@SWAN.SCRC.Symbolics.COM>
Date: 4 Feb 88 22:09:00 GMT
References: <922@thumper.bellcore.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 22


    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 still have this 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.

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