zweig@brutus.cs.uiuc.edu (Johnny Zweig) (12/02/89)
I just realized that RFC793 says to go from CLOSE-WAIT to LAST-ACK state on page 23, and this would appear to be the Right Thing (no need to enter CLOSING and thus TIME-WAIT since the other end's FIN is acked by this end's FIN). However, on page 61 it says to enter CLOSING state. Which page is in error? (Please no flames for having implemented my TCP directly out of RFC793 and never looking at how UNIX does it or anything -- I've heard it before.) -Johnny TCP
barmar@think.com (12/02/89)
In article <1989Dec1.232714.23698@brutus.cs.uiuc.edu> zweig@cs.uiuc.edu writes: >Which page is in error? Page 61 is wrong. See p.93 of RFC1122, section 4.2.2.20.(a). If you're implementing a TCP you should read all of section 4.2.2 of RFC1122, "Requirements for Internet Hosts -- Communications Layers", which documents a number of errors in RFC793. In fact, you should read this entire document (as well as its companion, RFC1123, which documents the application layer and support protocols). Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
barns@GATEWAY.MITRE.ORG (12/04/89)
Short answer: Page 23 is correct; page 61 is in error. See RFC 1122, section 4.2.2.20 (a), bottom of page 93. General comment: (I had been thinking that "they" [or "we"] had been a bit neglectful in not making a specific publication announcement in the TCP-IP mailing list/newsgroup. The relative absence of relevant mail led me to think that maybe I was wrong. Now I think maybe my first impression was more correct. So, here goes:) The answers for this question and many others like it can be found in the "Host Requirements RFCs". There are three documents in this set. RFC 1122 provides standards updates and guidance to implementors for TCP, IP, and (to a limited extent) lower layers. RFC 1123 provides similar material for TCP applications (TELNET, FTP, TFTP, SMTP/RFC822, DNS, and management/support services). RFC 1127 provides some background discussion on the documents, including a list of unfinished business. RFC 1122 and RFC 1123 are "mandatory"; RFC 1127 is just informational and contains no specific technical direction. Everyone who ever does anything requiring knowledge of what is happening (or ought to be happening) inside implementations of the "TCP/IP suite" ought to browse through these documents at least once, and keep a copy nearby for reference. This is especially true for implementors, but it also holds for people who do troubleshooting, design new software that interfaces to these protocols, or prepare specifications for procurement. They also have some educational merit; I think it's probably accurate to say that most (if not all) of those who took part in writing these documents learned some new and grotesque tales of perverse misinterpretations of the specifications, botched implementations, or bizarre failure modes. If you find such things amusing, read between the lines of these documents and your day will be filled with hilarity. Caveat: Yes, I was responsible for (or irresponsible for) a few words in those RFCs. I wasn't a chief guru, but maybe occasionally an assistant guru, and often a conspicuous presence in the peanut gallery. Bill Barns / MITRE-Washington / barns@gateway.mitre.org