Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!tut.cis.ohio-state.edu!ucbvax!GATEWAY.MITRE.ORG!barns
From: barns@GATEWAY.MITRE.ORG
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  RFC793 pages 23 and 61
Message-ID: <8912041413.AA01744@arcturus.mitre.org>
Date: 4 Dec 89 14:13:07 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 38

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


Brought to you by Super Global Mega Corp .com