From: werme@alingo.uucp (Eric Werme USSG) Newsgroups: alt.culture.internet,soc.history,alt.folklore.computers Subject: Early ARPAnet Email (was Draft History of early ARPANET Part 3/3) Date: 30 Dec 93 15:05:33 GMT I guess it's time for a new subject line. I trimmed the newsgroups line, I forgot to check it last time. kenner@lab.ultra.nyu.edu (Richard Kenner) writes: >In article werme@zk3.dec.com writes: >>RFC 542 does not mention MAIL or MLFL, and the first RFC I can find that >>describes them is RFC 765 in 6/80 (and it describes a lot more that I never >>heard of). MAIL & MLFL were very much an afterthought, but Ed & I implemented >>them almost immediately and within a week couldn't imagine life without them. >I agree that MAIL and MLFL were an afterthought, but I don't think you have >to go to RFC 765. The protocol for mail headers was RFC 733. It was >superceded by RFC 822. Forget that 6/80 date - my point was that MAIL and MLFL were alive and well before I left CMU (7/74). It's rather interesting how well and long MAIL & MLFL served the ARPAnet as people had been exploring mail protocols well before FTP came into general use. The predecessor to RFC733 was RFC724 (7/77) which includes some history: I. PROBLEMS WITH ARPANET MESSAGE STANDARDS A. BACKGROUND AND HISTORY Today's ARPA Network "mail" or "message" service uses, for its delivery mechanism, two special commands of the File Transfer Protocol. Viewed from within the structure of FTP, the entire message, both header and text, is data for the FTP MAIL and MLFL commands. This facility was added to the File Transfer Protocol as an afterthought; it was an interim solution to be used only until a separate mail transmission protocol was specified. Several versions of such a protocol have been proposed, but none has yet received general acceptance. Meanwhile, attempts have been made to improve upon the original interim facility. As message service subsystems on various host systems (especially TENEX) developed to the point where rudimentary parsing of incoming messages was being done, it became clear that it would be desirable to standardize the format and content of the headers of messages transmitted between hosts using these FTP commands. To this end, an ad hoc committee wrote RFC 561, which suggested a standard message header format. The committee was unofficial, so it could not legislate a standard, it could only recommend. However, the standard it suggested adequately met an urgent need, and was generally adopted. Several salient points should be noted: 1. RFC 561 defined the concept of a message header, and specified the syntax which delimited it from the actual text of a message; 2. It proposed a standard format for the most obvious and most urgently-needed header items: "From:", "Date:", and "Subject:"; 3. It proposed that a general standard syntax be used for all other header items; 4. RFC 561 is still, today, an unofficial standard, adhered to by most because of its utility; 5. Its syntax was designed to allow humans to read the text easily, without the aid of special message processing systems. As message services grew in sophistication, the need for specific header items in RFC 561's "miscellaneous" category grew: "To:" and "cc:", especially, were generated and recognized by several different message services. However, there was no specific standard for the syntax of the contents of these items. The message service subsystems on TENEX developed a particular format for these items; since more messages originated from the TENEX hosts on the Network than from any other type of host system, the TENEX format for these fields soon became a de facto standard. Message service subsystems on TENEX began to parse these fields, expecting them to be in the TENEX-generated format. Message service subsystems on other hosts -- Multics, for example -- began to dabble with other formats for these fields, since there was no standard for them, only to receive complaints from users of TENEX message service subsystems that their "non- standard" message headers could not be parsed according to the (de facto) "standard" syntax. Recognizing that the time had come to make an attempt to standardize the additional header fields that had come into use since RFC 561 was published, ARPA's Message Service Committee chartered a small group in 1975 to develop a revised version of RFC 561 which would define the syntax of these additional message header fields. Several things should be noted about this small group of people: first, they were TENEX-oriented; when the functionality of the message header items they desired was matched by the functionality of an already-existing message header item of the TENEX message subsystems, they adopted the syntax used by the TENEX message subsystems. Second, they based additional header items not already found on TENEX message subsystems on the deliberations of the Message Service Committee. Third, they were not familiar with the procedure for publication of a document as a Network RFC. The document which this group produced, labelled RFC 680, "Message Transmission Protocol", received only limited distribution. Matters were further confused because its title was misleading, since it was not a protocol for the transmission of messages between ARPA Network hosts, but rather a standard for the format of messages transmitted via the standard File Transfer Protocol. Some, including the Message Service Committee, believed that RFC 680 became a Network Standard. This was not strictly true, because it never received proper distribution, and it had never been "officially blessed" by anyone, to turn it from a request for comments into an accepted official ARPA Network standard document. Reflecting this confusion over the status of the document are the facts that the document DOES currently reside in the "official" ARPANET Protocol Handbook, and most users and message system implementors remain unaware that this is so. Various RFCs that may be interesting include the following. Some are not at gatekeeper.pa.dec.com, some are despite the NIC's "(Not online)" warning. 0095 Distribution of NWG/RFC's through the NIC. S.D. Crocker. Feb-04-1971. (Not online) (Obsoleted by RFC0155) 0155 ARPA Network mailing lists. J.B. North. May-01-1971. (Not online) (Obsoletes RFC0095) (Obsoleted by RFC0168) [I suspect these are Snail-mail addresses....] 0196 Mail Box Protocol. R.W. Watson. Jul-20-1971. (Not online) (Obsoleted by RFC0221) [This may also have nothing to do with Email, but given the overlap between authors in RFC221 and RFC561, maybe RFC196 does refer to Email.] 0278 Revision of the Mail Box Protocol. A.K. Bhushan, R.T. Braden, E. Harslem, J.F. Heafner, A.M. McKenzie, J.T. Melvin, R.L. Sundberg, R.W. Watson, J.E. White. Nov-17-1971. (Not online) (Obsoletes RFC0221) 0453 Meeting announcement to discuss a network mail system. M.D. Kudlick. Feb-07-1973. (Not online) 0475 FTP and network mail system. A.K. Bhushan. Mar-06-1973. (Not online) 0561 Standardizing network mail headers. A.K. Bhushan, K.T. Pogran, R.S. Tomlinson, J.E. White. Sep-05-1973. (Not online) (Updated by RFC0680) 0680 Message Transmission Protocol. T.H. Myer, D.A. Henderson. Apr-30-1975. (Not online) (Updates RFC0561) 0724 Proposed official standard for the format of ARPA Network messages. D. Crocker, K.T. Pogran, J. Vittal, D.A. Henderson. May-12-1977. (Not online) (Obsoleted by RFC0733) 0780 Mail Transfer Protocol. S. Sluizer, J.B. Postel. May-01-1981. (Not online) (Obsoletes RFC0772) (Obsoleted by RFC0788) 0788 Simple Mail Transfer Protocol. J.B. Postel. Nov-01-1981. (Not online) (Obsoletes RFC0780) (Obsoleted by RFC0821) 0821 Simple Mail Transfer Protocol. J.B. Postel. Aug-01-1982. (Format: TXT=124482 bytes) (Obsoletes RFC0788) 0822 Standard for the format of ARPA Internet text messages. D. Crocker. Aug-13-1982. (Format: TXT=109200 bytes) (Obsoletes RFC0733) (Updated by RFC1138, RFC1148) -- Eric (Ric) Werme | werme@zk3.dec.com Digital Equipment Corp. | This space intentionally left blank.