Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbatt!ucbvax!G.BBN.COM!CLYNN
From: CLYNN@G.BBN.COM.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Interpreting RFC 793
Message-ID: <[G.BBN.COM]22-Apr-87.09:17:40.CLYNN>
Date: Wed, 22-Apr-87 08:17:00 EST
Article-I.D.: <[G.BBN.COM]22-Apr-87.09:17:40.CLYNN>
Posted: Wed Apr 22 08:17:00 1987
Date-Received: Fri, 24-Apr-87 00:01:39 EST
References: <288@kuling.UUCP>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 11

Bjorn,
	Technically, you can't; in fact, the next paragraph on page 75,
FIN-WAIT-2, says to do exactly the same thing as does the FIN-WAIT-1
state when the FIN has been acked.  I view the situation as an explicit
restatement of robustness -- a correct implementation shouldn't get into
that state, but if it does (software implementations have been known to
contain bugs) then there is a way to recover.  Maybe there should be a
statement to the effect that you shouldn't be here, write an entry into
the system error log.

Charlie