24-JUN-79 04:37:06-PDT,6166;000000000001 Date: 24 JUN 1979 0351-PDT Sender: JMCHUGH at USC-ECL Subject: MSGGROUP#1201 SURVEY [ecl]proceedings.msg#1151-1200 From: JMCHUGH at USC-ECL To: MsgGroup at MIT-ML Message-ID: <[USC-ECL]24-JUN-79 03:51:03.JMCHUGH> Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 Survey of Messages in [ECL]PROCEEDINGS.MSG#1151-1200 MSGGROUP#1151 SURVEY [isi]proceedings.msg#1101-#1150 6338 chars 29 Apr 1979 2200-PDT From: STEFFERUD at USC-ISI MSGGROUP#1152 ftp quoting 465 chars 29 April 1979 01:49 est From: Frankston.Frankston at MIT-Mu MSGGROUP#1153 Re: ftp quoting 939 chars 28 Apr 79 23:27-PST (Sat) From: Greep at Rand-Unix MSGGROUP#1154 Re: ftp quoting 469 chars 29 April 1979 02:32 est From: Frankston.Frankston at MIT-Mu MSGGROUP#1155 The Marketing Principle 2251 chars 29 Apr 1979 1954-PDT From: PANKO at SRI-KL MSGGROUP#1156 Marketing Electronic Mail 1391 chars 29 April 1979 2316-EDT (Sunday) From: Brian K. Reid MSGGROUP#1165 More on Office Automation Stats 999 chars 2 May 1979 0820-PDT From: Bair at SRI-KL (James Bair) MSGGROUP#1166 "Privacy" 2462 chars 2 May 1979 1029-PDT From: Geoff Goodfellow MSGGROUP#1167 Bair's Message on Professional Time 1562 chars 2 May 1979 1755-PDT From: Panko at SRI-KL (Ra3y Panko) MSGGROUP#1168 "PAPERLESS OFFICE" DEBUT 1030 chars 3 May 79 (05/03/79 18:31:52) From: KENS@MIT-MC MSGGROUP#1169 (N.Y.Times) "Privacy" 4486 chars 4 May 1979 0940-PDT From: Geoff Goodfellow MSGGROUP#1170 Nobody wants computer mail! 2172 chars 4 May 1979 1818-PDT From: PANKO at SRI-KL MSGGROUP#1171 Direct vs Indirect Users 2147 chars 7 May 1979 1832-PDT From: PANKO at SRI-KL Msggroup#1172 Message Systems 994 chars 14 MAY 1979 1437-PDT From: HSMITH at USC-ECL Msggroup#1173 More on Drills and Holes 1266 chars 16 May 1979 1758-PDT From: PANKO at SRI-KL Msggroup#1174 Re: More on Drills and Holes 1043 chars 16 May 79 21:54-EDT (Wed) From: Dcrocker at UDEE Msggroup#1175 The medium is *not* the mechanism 2534 chars 17 May 1979 1546-PDT From: PICKENS at SRI-KL MSGGROUP#1176 Re: The medium is *not* the mechanism 1340 chars 18 May 1979 01:29 edt From: Frankston.Frankston at MIT-Mul MSGGROUP#1177 resent MsgGroup messages 797 chars 18 May 1979 0047-PDT From: Mark Crispin mailing.list;200 MOVE MsgGroup to ECL, 2544 chars 28 MAY 1979 2304-PDT From: MSGGROUP at USC-ECL MSGGROUP#1191 general information systems 786 chars 5 Jun 1979 1615-EDT From: KONCER at BBN-TENEXA MSGGROUP#1192 Delaware's Memo Distribution Project 5940 chars 9 Jun 79 15:04-EDT (Sat) From: Dcrocker at UDel-EE MSGGROUP#1193 Special Interest Group Mailing Lists 1365 chars 9 June 1979 21:42-PDT (Saturday) From: WANCHO at SRI-KA MSGGROUP#1194 Re: Special Interest Group Mailing Lists 1495 chars 10 Jun 1979 1737-PDT From: Zellich at OFFICE-1 MSGGROUP#1195 Re: Special Interest Group Mailing Lists 954 chars 10 Jun 1979 2249-PDT From: STEF at SRI-KA MSGGROUP#1196 Re: Special Interest Group Mailing Lists 1150 chars 11 June 1979 13:32-EDT From: "Marvin A. Sirbu, Jr." In-Reply-To: <18Jun79 103335 DL10@CMU-10A> Mail-from: MIT-ML rcvd at 20-JUN-79 1346-PDT Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 In addition to information on mail reader/sender problems with RFC733 violations, I would also like to collect info on MAIL-related FTP protocol violations. David 21-JUN-79 23:41:17-PDT,598;000000000001 Date: 21 Jun 1979 at 2327-PDT Sender: Mike at RAND-UNIX Subject: MSGGROUP#1205 MSGGROUP SCREWUP From: Michael Wahrman To: Msggroup at ML Cc: Mike at RAND-UNIX Mail-from: MIT-ML rcvd at 21-JUN-79 2341-PDT Reply-to: Mike at Rand-Unix Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 It has come to my attention that I have not been receiving Msggroup messages in recent days. Does there exist someone who can fix this for me? This explains why Msggroup has seemed so silent... 22-JUN-79 04:23:19-PDT,705;000000000001 Date: 22 June 1979 07:14-EDT Subject: MSGGROUP#1206 MSGGROUP SCREWUP From: Charles Frankston To: Mike at RAND-UNIX Cc: Msggroup at MIT-ML Mail-from: MIT-ML rcvd at 22-JUN-79 0423-PDT Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 Such complaints are probably best sent to Stef rather than to every body. I can't really say why you may have been dropeed, but on 9 June 1979 per request, I replaced all persons at Rand-Unix with RAND-MsgGroup@RAND-UNIX. As of then, you were in the list as MLW@Rand-Unix (that is an alias for you, isn't it?). I suggest you check into the matter locally. 24-JUN-79 11:02:54-PDT,2172;000000000001 Mail-from: MIT-ML rcvd at 24-JUN-79 1040-PDT Date: 24 Jun 1979 1316-EDT Sender: JMCKENDREE at BBN-TENEXB Subject: MSGGROUP#1207 Paperless Office Ground Floor Opportunity From: JMCKENDREE at BBN-TENEXB To: estefferud at USC-ECL Cc: jmckendree, jmchugh at USC-ECL, Cc: msggroup at MIT-ML Message-ID: <[BBN-TENEXB]24-Jun-79 13:16:07.JMCKENDREE> Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 Robert Landau is a consultant to Larry Stockett's Micronet Corp. at the Watergate in Washington, DC. Their Paperless Office is a showcase with lots of vendor-donated equipment to make the operation as paper-less as the state of the art permits. [See also Ken Showalter's (KENS@MIT-MC) message, titled "PAPERLESS OFFICE" DEBUT, datead 3-May-79 to MSGROUP@MIT-ML ] Bob called to my attention this morning the following advertisement placed in the Washington Post on page N-11: MICRONET'S PAPERLESS OFFICE AT WATERGATE has a contract to develop and manage a "Paperless Office" for a major organization. This project extends for five years and encompasses the full range of electronic office automation: teleconferencing, word processing, electronic mail, business graphics, micrographics and related technologies. We are now assembling a team to plan, develop and implement this model office. A briefing on this project will be conducted at Micronet on Saturday, June 30, 1979 for prospective consultants and employees as facility planners, system designers, software specialists, technicians, project and task managers and other related disciplines. If you want challenge, and are interested in office automation and productivity, please call Mrs. Stein for a reservation to attend this briefing at (202) 333-4800. *********** The above ad reflects a contract between Micronet and a major organization which itself is a consortium of major corporations interested in building a showpiece and demonstration operations several times the scale of the operation of Micronet itself here in Washington. For your information. 16-JUL-79 15:01:08-PDT,6002;000000000001 Mail-From: SRI-KA rcvd at 16-Jul-79 1324-PDT Date: 16 Jul 1979 1133-PDT Sender: GEOFF at SRI-KA Subject: MSGGROUP#1208 "The call will find you..." From: the tty of Geoffrey S. Goodfellow To: Msggroup at ML Message-ID: <[SRI-KA]16-Jul-79 11:33:35.GEOFF> Reply-to: Geoff @ SRI-KA Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 n027 0923 16 Jul 79 BC-AT&T (ART AVAILABLE ON REQUEST) By N.R. KLEINFIELD c.1979 N.Y. Times News Service NEW YORK - It grows even faster than the United States. Every working day, its installers plug in 100,000 more telephones, its customers moving so often that it must put in seven to gain one. Its long limbs connect 135 million phones (48,000 of them in cars and trucks) and by the year 2000 it expects to have a hundred million more. Every day, a torrent of 493 million calls bolts through its trunks. Long-distance talking, if the projections of its planners are right, will swell by 8 percent a year for the next two decades, overseas chatter, by 21 percent. In the more than 100 years of its existence, the sprawling American Telephone and Telegraph Co. system has extended its service to virtually every American who desires it, at a price almost every American can afford. ''Phones are more pervasive than bathtubs,'' one analyst says. The nation seems essentially telephone-saturated - there are even phone booths in the middle of forests to oblige talkative hunters - but call volumes still spiral upward. In fact, having a phone is no longer enough. People want more. Bell promises they are going to get it. As the nation hurtles into the years of the ''information society,'' Bell people say, all manner of ingenious capabilities will be common. The phone will automatically put through a wake-up call to you in the morning. It will electronically snap on the lights and air-conditioner (or heat) shortly before you saunter through your office door. When you take off at the end of the day, the phone will lock up. Dash off a staff memo at your desk and it will be automatically transmitted to receiving devices attached to phones throughout your company. On your lunch hour, you'll call home and get the clothes washer going. Later on, you'll have to momentarily interrupt a meeting to call the drier. An hour before you wrap up for the day, you'll phone the microwave oven to start the Yankee pot roast. Pull into the gas station and run your credit card through a device. The gadget will dial a number over the phone lines to a data base that validates your card. The pump unlocks. You put in your 12 gallons of unleaded and are charged $50. Other things. You will vote by phone. Electric and gas companies will read meters over the phone. And the mail will come by phone; no more postman with pouch slung over his shoulder. Still other things. ''I'll want to repair my 1956 Granada,'' says Howard Anderson, president of the Yankee Group, a consulting group, ''I'll call the specifics into a data bank and out will pour instructions on how to do it. I'll be out there in my driveway, flat on my back, all greasy, and I'll be shouting into my telephone, 'Now I've taken off the wheel, what do I do next?' And the phone will respond, 'Now take out the bearings.' At night, I'll be doing my income taxes and there will be a computer program I can call to explain the horrendous mess to me. All of this from AT&T'' There might be a visual display on everybody's phone that prints out the number of the calling party. (Oh, no, it's Aunt Corky again! Let it ring. Better yet, punch a button that causes the phone to deliver a recorded message reporting that you have, on short notice, been sent to prison.) Matters may be arranged so that there will be no phone books and no directory assistance operators. You want a person's number? Dial the letters of the name and the number flashes on your display. The phone may be wedded to the TV set, or else to a wall screen (which, when not in use, can display an electronic picture of, say, ships on a shimmering ocean). That way, you can do your shopping at home by calling up mops and looking them over on your screen. Call up the Sears catalogue on the phone and order away. Do your banking by phone. You want to read the newspaper? Dial it up on the phone. There will be no standard telephone. A cornucopian array of models will exist. Says the Yankee Group's Anderson, ''If you want a polka-dot phone waking you up each morning to 'The Battle Hymn of the Republic,' be AT&T's guest.'' It is probable - in the long run - that the telephone will no longer be called the telephone. And so the name, the American Telephone and Telegraph Co., will become a misnomer (the telegraph portion already is a misnomer) and it, too, will undoubtedly be changed in time. William G. Sharwell, AT&T's vice president in charge of planning, pondered the future: ''The mobile phone has got to be one of the big areas of expansion. Not only will there be phones in every car, but a cordless telephone that you can carry around with you in your pocket. A possibility is a national telephone number for everybody. Anyone who wants to reach you can dial that number, and the call will be forwarded. You're shopping at the supermarket. You're sunbathing at the beach. You're in Beirut. You're climbing the Alps. The call will find you.'' Charles L. Brown, the chairman of AT&T, said in his office off the marble halls of 195 Broadway: ''I look forward with relish to the future. I would hope that our basic goals of offering high-quality telephone service at relatively low cost to the public, and service that is innovative and that has the approval of customers of all kinds will still be foremost in our mind. I fully expect they will.'' =========================== 28-JUL-79 14:43:55-PDT,2066;000000000001 Date: 28 Jul 1979 1442-PDT Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1209 Re: ITS headers zapping the network From: STEFFERUD at OFFICE-1 To: McLure at SRI-KL, MsgGroup at MIT-ML Cc: Admin.MRC at SU-SCORE, geoff at SRI-KA, Bug-MAIL at MIT-AI, Cc: RMS at MIT-AI, Frankston at MIT-MULTICS, Stefferud Message-ID: <[OFFICE-1]28-Jul-79 14:42:40.STEFFERUD> In-Reply-To: Your message of 28 Jul 1979 1101-PDT Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 MIT ITS Headers have broken loose in the net again, causing damage which has been repaired by careful surgery performed by dedicated hackers around the net, and it has been suggested that the ARPANET message community take actions that might help to eliminate the sources of the problem. It has been suggested by several people that we as receivers of mail that disables our mail processors should announce to the public that we will not read such mail, preferring to delete it without reading to cleanse our mailboxes. I concur completely with the notion of simply announcing that I (we) will not bother to read such mail, so that if the sender wants us to see it, it is the sender's responsibility to send it correctly. I herewith announce that I will delete all such mail without reading, regardless of source. I also encourage others to make such public announcements. I will further contribute to the process by announcing that MSGGROUP@ECL will always delete such mail from the proceedings, no matter who it may come from, or how important the subject may be. Such deletions will not be dignified with notices to the senders. We have taken MARS-Filer@CCA out of the automatic distribution lists so that the Public Access MSGGROUP messages in the DATA COMPUTER will only include clean stuff, to be posited there by REDISTRIBUTION to PUBLIC@CCA after processing by myself and my various MSGGROUP helpers. Enuff is Enuff - the time has come to clean up this act. Best - Stef 29-JUL-79 12:01:03-PDT,2691;000000000001 Mail-From: MIT-MC rcvd at 28-Jul-79 1733-PDT Date: 28 July 1979 20:31-EDT From: David A. Moon Subject: MSGGROUP#1210 ITS headers "zapping" the network To: McLure at SRI-KL, MsgGroup at MIT-ML, STEFFERUD at OFFICE-1 cc: BUG-MAIL at MIT-MC, Frankston at MIT-MULTICS, RMS at MIT-AI, geoff at SRI-KA, Admin.MRC at SU-SCORE Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 I hope you don't think we're deliberately dragging our feet on this in order to make trouble for the rest of the world. Far from it. The problem is that our mail system was designed many years ago, some aspects of it being considerably older than the Arpanet. Furthermore we (foolishly, as it turned out) chose to use the Arpanet mail-delivery protocol (of FTP) when that came out. Unfortunately, this protocol is highly deficient and makes it extremely difficult for us to keep our headers from getting to outside hosts, although we have done some things to make it happen less often. The only way we can fix the problem for good is by designing an entirely-new network mail-transmission protocol for use between our several machines, and so far we just haven't had time for such a major undertaking, especially when the problem to be fixed is so minor. Let me say that I am thoroughly sick and tired of listening to these complaints every few weeks about our non-standard headers. You don't hear us constantly complaining about the non-standard headers transmitted by Tenex, which conform to no published mail protocol and cause continual problems to users because our mail software doesn't parse them, or the funny addressees sent out by WAITS which we have trouble parsing, or the fact that the TOPS-10 ftp server frequently crashes while receiving mail, causing mail from us not to get through, or the fact that the Tenex ftp server gets "scratch file failures" causing spurious mail rejections, or the fact that after at least seven years of Arpanet mail there is still no common header format, no common set of FTP reply codes for mail transmission, and no mail protocol that provides for the more advanced features we provide for our own users. We have complained about each of these things once or twice then ceased to bother the world, since it clearly doesn't care. In the hope of preventing the outside world from over-reacting in the fashion of Stefferud in his letter, when I get a chance I will look into putting in a kludge in the mailer to detect an outgoing ITS header at the lowest level and prefix it with something the outside world can parse. 29-JUL-79 12:33:44-PDT,3973;000000000001 Mail-From: STEFFERUD filed at 29-Jul-79 1232-PDT Date: 29 Jul 1979 1232-PDT Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1211 Re: This is a test AND [MSGGROUP#1199] From: STEFFERUD at OFFICE-1 To: MOON at MIT-MC Cc: MSGGROUP at MIT-ML Message-ID: <[OFFICE-1]29-Jul-79 12:32:54.STEFFERUD> In-Reply-To: Your message of 7/29/79 00:13:09 Fcc: SAVED.MESSAGES;1 Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 Hi David - Did you intend to bury the TO field in the BODY instead of in the HEADER? And what will you do with CC fields? Is this new ITS header a hack that will protect the network from inadvertant escapes of ITS Headers, while the regular RFC733/680/etc/??? ITS headers will still be available to those who choose to use them? If so, this seems to meet the entire short term requirement that originally surfaced in the current flap. Whether something can be done about the other crisis generators sent by other hosts remains to be seen. I can live with your new ITS header. It does not bomb my mail receiver or present me with unreadable display of your message. Finding the TO and perhaps the CC fields buried in the BODY is only an inconvenience, not a crisis. From a longer term point of view, and going beyond this current flap over escaping crisis generators, it seems to me that we are seeking interoperability among our differently hosted message systems. To me this implies that we should want to send each other formats that our systems can parse correctly, and allow us easily to correspond with each other. I don't know of any other reasonable objective for this exercise. In the interests of this longer term objective, I am resending a prior request (MSGGROUP#1199) from David Lamb for specific information regarding interoperability failures so he might catalogue them and help us get a handle on the problems of stabilizing the ARPANET mail situation. I would like to encourage you all to assist by feeding the requested information to David Lamb. Best - Stef Date: 18 June 1979 1033-EDT Subject: MSGGROUP#1199 Info collection for compromise From: David.Lamb at CMU-10A To: MSGGROUP at MIT-ML Message-ID: <18Jun79 103335 DL10@CMU-10A> In-Reply-To: <[SRI-KA] 7-Jun-79 16:06:16.STEF> Folks: Over the last few months I've seen a lot of exchanges where someone reported that some aspect of someone else's mail sender was making his/her life difficult. The problems usually boil down to the fact that many (perhaps most) sites don't implement "full" RFC733; either the sender sends something not according to the standard, or the receiver doesn't recognise something permitted by the standard. This effectively means that despite the existence of the standard, we often have trouble communicating with each other. I am interested in trying to determine a subset of RFC733 supported by most sites. My short-term hope is that those mail senders which are readily reconfigured or changed can be convinced to use only the subset when communicating across the net. In particular, I hope to be able to make RDMAIL do this. I intent to document what I find in the hope that other mail system maintainers might be inclined to do the same. I am sure that many cases will arise where some sort of compromise would have to be negotiated, but I believe the attempt is worthwhile. If you know of any feature of someone else's mailer that causes problems for your reader, or any feature of your mailer that causes someone else a problem, please send a note to Lamb at CMU-10A describing the problem, including the specific mailer and reader and what part of RFC733 was involved. Please note that I am NOT trying to change RFC733, or to force people to implement the full thing; I'm just trying to help stabilize the current setup. David Alex Lamb 2-AUG-79 21:50:50-PDT,798;000000000001 Mail-from: MIT-MC rcvd at 29-Jul-79 1515-PDT Date: 29 JUL 1979 1815-EDT From: MOON at MIT-MC (David A. Moon) Subject: MSGGROUP#1212 Re: This is a test AND [MSGGROUP#1199] To: STEFFERUD at OFFICE-1 Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 The ITS mailer tries, and has always tried, to send network format headers to non-ITS hosts. This new thing is just a kludge to stick on something that looks parseable when the mailer has been faked out, by forwarding through multiple hosts, into sending an ITS header to a non- ITS host. So don't consider it "the new official ITS header" or anything like that. It doesn't have TO and CC lines since it isn't generated by the normal header mechanism. 2-AUG-79 21:50:50-PDT,1347;000000000001 Mail-from: MIT-ML rcvd at 1-Aug-79 1109-PDT Date: 1 AUG 1979 1340-EDT From: SIRBU at MIT-MC (Marvin A. Sirbu, Jr.) Subject: MSGGROUP#1213 Privacy and the USPS ECOM proposal To: msggroup at MIT-ML CC: CLJ at MIT-MC, KRAUSS at MIT-MC, Pool.Datanet at MIT-MULTICS CC: Solomon at HARV-10 Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 On July 26 the Postal Rate Commission (2000 L St NW, Washington, DC) issued a notice of inquiry for comments on the privacy issue as it relates to the Postal Service's Electronic Computer Originated Mail Proposal. Under the ECOM proposal messages originating in machine readable form would be transmitted via Western Union to 25 post offices around the country to be printed and delivered with regular mail (much like mailgram only cheaper) The Postal Rate Commission has asked for comments on both the protection of privacy of messages in transit, and whether copies of messages should be archived for six months as is the current practice for telegrams (in another proceeding announced July 23, the FCC has asked for comments as to whether that requirement for telegrams should be changed). The notice has been published in the Federal Register for the 26th or 27th. Comments are due by August 17. 3-SEP-79 20:56:21-PDT,1084;000000000001 Mail-from: MIT-ML rcvd at 1-Sep-79 0102-PDT Mail-from: CMU-10A rcvd at 27-AUG-79 2350-PDT Date: 28 August 1979 0248-EDT TUESDAY From: Brian.Reid at CMU-10A Subject: MSGGROUP#1214 Re: [ecl]mail.lst;3 To: MSGGROUP at USC-ECL Message-ID: <28Aug79 024845 BR10@CMU-10A> In-Reply-To: <[USC-ECL]27-AUG-79 23:32:13.MSGGROUP> Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 A few months ago we all decided to keep the tone of MsgGroup more civilized, to refrain from invective, to "cut the flaming." Today I realize that MsgGroup has been idle ever since. I'm not sure if this is a good thing. It's certainly interesting. If we can't have anger and passion and mission to fan the fires of our conversation, and we can't use the ham radio operator's technique of never talking about anything but technical details [those conversations having been banished to another mailing-list group] then what's left? Anybody got a good scandal or topic of interest? Brian ------- 3-SEP-79 20:56:21-PDT,458;000000000001 Date: 08/30/79 07:45:51 Subject: MSGGROUP#1215 CRTs and eyestrain From: SIRBU@MIT-MC To: msggroup at MIT-ML Cc: SIRBU at MIT-MC Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 Does anyone out there know who has done research on the subject of eyestrain or other problems from prolonged use of CRT terminals? SIRBU@MIT-MC 08/30/79 07:45:51 Re: CRTs and eyestrain 3-SEP-79 20:56:21-PDT,726;000000000001 Mail-from: MIT-ML rcvd at 1-Sep-79 0118-PDT Date: 30 Aug 1979 0944-PDT From: Bair at SRI-KL (James Bair) Subject: MSGGROUP#1216 Re: CRTs and eyestrain To: sirbu at MIT-MC cc: MsgGroup@ECL Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 In response to your message sent 08/30/79 07:45:51 Marvin: Dr. Ostberg of Sweden (leo first name I believe). He has done extensive work on the subject. He's at the University of Lulea, Lulea Sweden. He made a presentation to the NATO ASI on MCI in Athens, 1976. Proceedings available from Prof. Brian Shackel, Univ. of Technology, Loughbourough, England. jim bair ------- 7-SEP-79 13:55:04-PDT,895;000000000001 Mail-from: MIT-ML rcvd at 6-Sep-79 2042-PDT Date: 6 Sep 1979 2026-PDT Sender: PANKO at SRI-KL Subject: MSGGROUP#1217 Leaving/Paper From: PANKO at SRI-KL To: msggroup at MIT-ML Message-ID: <[SRI-KL] 6-Sep-79 20:26:56.PANKO> Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 My current mailbox will be passing away on septembeR 8,and I will be leaving the MSGGROUP unless something radical happens. I have enjoyed the conversations since 1975. I am writing an overview paper on computer mail. If you would likea copy,please send a copy of your mailing address in a form that can be placed on the outside of a mailing envelope. Replyby September 8, of course. Raymond R. Panko (Ra3y), College of Business Administration, University of Hawaii at Manoa, 2404 Maile Way, Honolulu, HI 96822. 7-SEP-79 13:55:04-PDT,633;000000000001 Mail-from: SRI-KA rcvd at 7-Sep-79 1209-PDT Date: 6 Sep 1979 2348-EDT Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP#1218 Re: Leaving/Paper From: MOOERS at BBN-TENEXA To: PANKO at SRI-KL Cc: msggroup at MIT-ML, Mooers Message-ID: <[BBN-TENEXA] 6-Sep-79 23:48:53.MOOERS> In-Reply-To: <[SRI-KL] 6-Sep-79 20:26:56.PANKO> Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 We will miss you! Please send a copy of your paper to: Charlotte Mooers Bolt Beranek and Newman Inc. 50 Moulton Street Cambridge, Mass. 02138 ---Charlotte 7-SEP-79 13:55:04-PDT,602;000000000001 Mail-from: SRI-KA rcvd at 7-Sep-79 1213-PDT Date: 6 Sep 1979 2119-PDT From: LCAMPBELL at SRI-KL Subject: MSGGROUP#1219 Re: Leaving/Paper To: PANKO at SRI-KL, msggroup at MIT-ML In-reply-to: Your message of 6-Sep-79 2026-PDT Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 PLEASE SEND ME A COPY OF YOUR OVERVIEW PAPER ON ELECTRONIC MAIL. MY POSTAL ADDRESS IS: LARRY CAMPBELL 56 SUMMER ST. ACTON, MASS. 01720 MY NETMAIL ADDRESS IS EITHER LCAMPBELL@KL OR LCAMPBELL@DEC-2136. THANK YOU... ------- 7-SEP-79 13:55:04-PDT,738;000000000001 Mail-from: SRI-KA rcvd at 7-Sep-79 1216-PDT Date: 6 Sep 1979 2317-PDT Sender: GEOFF at SRI-KA Subject: MSGGROUP#1220 Re: Leaving/Paper From: the tty of Geoffrey S. Goodfellow To: PANKO at SRI-KL Cc: msggroup at MIT-ML Message-ID: <[SRI-KA] 6-Sep-79 23:17:57.GEOFF> In-Reply-To: <[SRI-KL] 6-Sep-79 20:26:56.PANKO> Reply-to: Geoff @ SRI-KA Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 Ra3y, I'll see what i can do to save your dir from going away -- don't give up yet!! Please send me a copy of your paper: Geoffrey S. Goodfellow, Computer Resources, SRI International, 333 Ravenswood Ave., Menlo Park, Ca. 94025. Thanks. 7-SEP-79 13:55:05-PDT,687;000000000001 Date: 7 Sep 1979 0542-PDT Sender: STERNBERG at SRI-KA Subject: MSGGROUP#1221 Re: Leaving/Paper From: STERNBERG at SRI-KA To: PANKO at SRI-KL Cc: msggroup at MIT-ML Message-ID: <[SRI-KA] 7-Sep-79 05:42:16.STERNBERG> In-Reply-To: <[SRI-KL] 6-Sep-79 20:26:56.PANKO> Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 I would appreciate a copy of your paper. My address is : HQ, U.S. Army Materiel Development and Readiness Command 5001 Eisenhower Avenue Alexandria, VA 22333 Attn: DRCMS-IS (Sternberg) Thanks, Nate 7-SEP-79 13:55:05-PDT,693;000000000001 Date: 7 Sep 1979 0808-PDT From: Bair at SRI-KL (James Bair) Subject: MSGGROUP#1222 Re: Leaving/Paper To: PANKO, msggroup at MIT-ML cc: BAIR Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 In response to the message sent 6 Sep 1979 2026-PDT from PANKO@SRI-KL Ra3y, I would definitely like a copy of your paper. Also have a question: are ou working on a research contract or grant in the area now? I would appreciate a descirition of your research in progress or recently finished. Thanks much, Jim James H. Bair BNR, Inc. 3174 Porter Dr. Palo Alto, CA 94304 ------- 7-SEP-79 13:55:05-PDT,494;000000000001 Date: 7 Sep 1979 0859-PDT From: COMPORT at USC-ISI Subject: MSGGROUP#1223 RE:Leaving/Paper To: PANKO at SRI-KL, msggroup at MIT-ML cc: COMPORT Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 Yes...please send me a copy of your overview on Electronic Mail mail to : Thomas Comport Code 812 Naval Ocean Systems Center San Diego, Ca. 92152 thanks, tom ------- 7-SEP-79 13:55:05-PDT,1003;000000000001 From: Gaines at Rand-Unix Date: 7 Sep 1979 at 0949-PDT To: msggroup at Mit-Ml SUBJECT: MSGGROUP#1224 Misuse of the reply facility in a message system Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 I think we are all seeing a good example of how a feature of a message system can be misused. Panko, in announcing his pending departure from the Arpanet, also asked for people interested in his forthcoming paper to let him know. Quite a number have done that using the reply facility. Most of these replies are of interest only to the sender and Panko. But the reply mechanism adds the msggroup as an addressee, and I imagine in most systems, it is hard to get the advantage of automatic header generation and still eliminate the cc: field. The result: lots of useless traffic to the msggroup. I think this is a problem, and would be interested in thoughts about the solution. Stock Gaines 7-SEP-79 13:55:05-PDT,910;000000000001 Date: 7 Sep 1979 1327-EDT From: LCAMPBELL at DEC-2136 To: MsgGroup at ML From-the-terminal-of: Larry Campbell Reply-to: LCampbell at SRI-KL Subject: MSGGROUP#1225 Bug in the Reply command Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 I am one of the guilty parties who helped flood the MsgGroup reflector at ML with requests for Ra3y's paper. I believe that MM, the message system I was using at the time, and other message systems apparently used by the other culprits, have bugs. The Reply command should default to replying ONLY to the sender of the mail, not to every address listed in the header. MS (DEC's version of MM), the program with which I am composing this message, does just that: the reply command will reply only to the sender of a message, unless told to do otherwise. -------- 7-SEP-79 13:55:05-PDT,984;000000000001 Mail-from: MIT-ML rcvd at 7-Sep-79 1148-PDT Date: 7 September 1979 1424-EDT From: Brian.Reid at CMU-10A Subject: MSGGROUP#1226 Re: Misuse of the reply facility in a message system. To: Gaines at Rand-Unix CC: msggroup at Mit-Ml Message-ID: <07Sep79 142406 BR10@CMU-10A> In-Reply-To: Gaines's message of 7 Sep 79 11:49-EST Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 In CMU's message system, as with most others, the user is given the option of selecting the set of recipients of mail generated in reply to another message. When I answered Ray's message, I directed output only to the sender of the original message (one option) and not to "everybody mentioned in the original header" (another option). I am quite sure that everybody who answered the message had those same options, and out of force of habit chose not to exercise the one that seems to me to be correct. 8-SEP-79 00:28:52-PDT,928;000000000001 Mail-from: MIT-ML rcvd at 7-Sep-79 1651-PDT Date: 7 September 1979 1338-EDT From: Richard H. Gumpertz Subject: MSGGROUP#1227 Re: Misuse of reply facility in a message system To: Gaines at Rand-Unix CC: msggroup at Mit-Ml Message-ID: <07Sep79 133812 RG02@CMU-10A> In-Reply-To: Gaines's message of 7 Sep 79 11:49-EST Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 RDMAIL solves the problem by explicitly prmompting for the TO and CC fields. There are magic short names (R, C, T, etc) which may be used to set the CC field appropriately. In generating this note, I said (where RDMAIL OUTPUT is in ()): (@)ANSWER . (TO [Gaines at Rand-Unix]: ) (CC: )T etc. Works very nicely -- typing a few characters is very cheap -- but doesn't have the problems you mentioned. Rick 8-SEP-79 00:28:53-PDT,1144;000000000001 Mail-from: MIT-ML rcvd at 7-Sep-79 1601-PDT Date: 7 Sep 1979 1139-PDT From: Stuart McLure Cracraft Subject: MSGGROUP#1228 Re: Bug in the Reply command To: LCampbell at SRI-KL, MsgGroup at MIT-ML In-reply-to: Your message of 7-Sep-79 1027-PDT Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 I disagree. I much prefer having my default in MM reply to everyone in the to and cc fields. The major reason for this is that I deal with large amounts of traffic between several people far more often than dealing with a single message to one person on a large mailing list. But in any event, when I answered Panko's message, I simply did REPLY SENDER which does the appropriate thing. People should be more aware of the capabilities of their message systems and use them accordingly, rather than blaming some resultant lossage on one or more defaults of their system. Dealing with a group of several people in message exchanges seems to be just as common an occurence as mailing list transactions, if not more so. ------- 8-SEP-79 00:28:53-PDT,792;000000000001 Mail-from: MIT-ML rcvd at 7-Sep-79 1623-PDT Date: 7 Sep 1979 1546-PDT From: Mark Crispin Subject: MSGGROUP#1229 reply facility of mail systems To: MsgGroup at MIT-ML Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 On the mail system I use (MM), there are two types of reply, "REPLY (TO) ALL" and "REPLY (TO) SENDER". My MM profile sets up the default to be to sender only. Even if it didn't, I am still given the change to add and delete addresses from the recepient list before actually sending the message off. I cannot imagine a hairy mail program not having that feature. Why bother writing such a program if you aren't going to include it? Mark ------- 8-SEP-79 00:28:53-PDT,1041;000000000001 Mail-from: MIT-ML rcvd at 7-Sep-79 1544-PDT Date: 7 Sep 1979 1257-PDT (Friday) From: lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1230 Misuse of reply facility in a message system In-reply-to: Your message of 7 Sep 1979 at 0949-PDT To: Gaines at Rand-Unix CC: msggroup at ml Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 And I EXPLICITELY put MSGGROUP on the CC: line! Well, while watching the parade of paper requests zooming by, I was starting to think much the same thing. The most obvious solution would be to make sure most message systems had a capability for either including or EXCLUDING the cc: line in replies. When I implemented net replies within the msg program at UCLA, I simply threw out the cc: line completely, letting people add it back in manually if they wanted it (they are prompted for it as always). Probably an easily settable switch would be the ideal solution. --Lauren-- ------- 8-SEP-79 00:28:53-PDT,1060;000000000001 Mail-from: MIT-ML rcvd at 7-Sep-79 1527-PDT Date: 7 September 1979 1550-EDT From: David Lamb Subject: MSGGROUP#1231 Re: Misuse of reply facility in a message system Sender: RdMail at CMU-10A To: Gaines at Rand-Unix CC: msggroup at Mit-Ml Reply-To: RdMail at CMU-10A Message-ID: <07Sep79 155041 RD00@CMU-10A> In-Reply-To: Gaines's message of 7 Sep 79 11:49-EST Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 I think we can't really blame the folks whose mailers defaulted the CC field on them. Anytime a system always does something for you by default, you eventually forget about the default unless you regularly override the default. We could argue for a long time about whether this is bad. RDMAIL doesn't default any name lists without first prompting you; this usually means you have to type an extra carriage return that you "didn't really need to", but it avoids the situation we've just seen with the answers to Ra3y's note. David 8-SEP-79 00:28:53-PDT,1745;000000000001 Mail-from: MIT-ML rcvd at 7-Sep-79 1855-PDT Date: 7 Sep 1979 2131-EDT Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP#1232 REPLY facility and MSGGROUP at MIT-ML address. From: MOOERS at BBN-TENEXA To: MSGGROUP at MIT-ML Cc: Mooers Message-ID: <[BBN-TENEXA] 7-Sep-79 21:31:35.MOOERS> Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 It is clear that a number of message systems do give the user the choice of replying just to the sender, or replying to the names in the TO and CC fields. Hermes has a REPLY-COPIES switch, and also a way to override the current switch setting for an individual message. It is even possible to reply to only the names in the SENDER and TO fields, and not to the names in the CC field. However, the real problem here is that the MSGGROUP at MIT-ML looks like a simple addressee. Only after you use it, or see it in use, are you aware that MSGGROUP "fans out" to a long list of other addressees. If you don't know that (as I didn't the first time I used it), or if you temporarily forget about the booby trap (as I did in replying to Ra3y), there is nothing you can do once the message is sent. Perhaps the solution is to change the way MSGGROUP at MIT-ML works. For example, if the addressee name MSGGROUP at MIT-ML appears in the TO field, the automatic "fan-out" program might assume that the sender really means to use the "fan-out" facility. If the name MSGGROUP at MIT-ML appears in the CC field, the automatic program might send a message to the sender, explaining the program and asking whether the sender really means to make use of the automatic "fan-out". ---Charlotte Mooers 8-SEP-79 00:28:53-PDT,607;000000000001 Mail-from: MIT-ML rcvd at 7-Sep-79 2038-PDT Date: 7 September 1979 2152-EDT From: Brian.Reid at CMU-10A Subject: MSGGROUP#1233 "fan out" in addresses To: MOOERS at BBN-TENEXA CC: MSGGROUP at MIT-ML Message-ID: <07Sep79 215218 BR10@CMU-10A> In-Reply-To: <[BBN-TENEXA] 7-Sep-79 21:31:35.MOOERS> Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 It certainly would be nice to be able to determine by lexical inspection of an address whether or not that address represented a single person or a mailing list. 8-SEP-79 00:28:53-PDT,2168;000000000001 Mail-from: MIT-ML rcvd at 7-Sep-79 2357-PDT Date: 8 September 1979 02:45-EDT From: Robert W. Kerns Subject: MSGGROUP#1234 "fan out" in addresses To: MSGGROUP at MIT-ML Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 Date: Friday, 7 September 1979 2152-EDT From: Brian.Reid at CMU-10A To: MOOERS at BBN-TENEXA cc: MSGGROUP at MIT-ML Re: "fan out" in addresses It certainly would be nice to be able to determine by lexical inspection of an address whether or not that address represented a single person or a mailing list. Well, the distinction is not 100% clear cut. I and other people have their mail sent to more than one place. Some people have their mail sent to other people as well. Some people have all their mail CC'd to their secretary. Other things are mailing-lists which try to look as much like a person as possible. The distinction is semantic, not really functional. On ITS, it's done by a naming convention of INFO- for informational lists and BUG- for bug-report lists, and the mail reply commands in the various programs defaultly delete all INFO-xxx recipients. BABYL lets you add other things to not reply to by default (and it's aways easily over-ridden). There's no standard prefix for discussion mailing lists though. The INFO-xxx and BUG-xxx recipients turn into (INFO xxx) and (BUG xxx) under the ITS structured-recipient scheme, and some similar forwarding of the information that something is a mailing-list would definately be desirable. However, I generally DO want to reply to a discussion list like MsgGroup, rather than to the sender. I usually end up deleting the To: lines and turning the CC: line into a To: line, so the sender and any of his original To:'s don't get duplicate copies. In this case, it was due to the character of the message that I deleted the MsgGroup and kept the sender, rather than the other way around. If he'd had a way to do it, perhaps he should have specified "Reply only to sender" in the message header? 8-SEP-79 01:05:25-PDT,842;000000000001 Mail-from: MIT-ML rcvd at 8-Sep-79 0039-PDT Date: 8 Sep 1979 0026-PDT From: Mark Crispin Subject: MSGGROUP#1235 replying to messages To: MsgGroup at MIT-ML Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 What do other people in the group think about a general condemnation of the practice of replying to a message by inserting the message with commentary below it? It's alright for local MIT or SAIL mail, but gets damned annoying (to me at least) in net mail! One clarification about MM; Larry said he sent his message using MM from SRI-KL. SRI does not run a modern version of MM and cannot until they run a modern version of Tops-20. Please do not judge MM based upon SRI's ancient version! Mark ------- 8-SEP-79 13:47:24-PDT,642;000000000001 Mail-from: MIT-ML rcvd at 8-Sep-79 0736-PDT Date: 8 Sep 1979 1024-EDT Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP#1236 Please, no 80-column texts! From: MOOERS at BBN-TENEXA To: MSGGROUP at MIT-ML Message-ID: <[BBN-TENEXA] 8-Sep-79 10:24:29.MOOERS> Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 I wish that MSGGROUP members would format their messages to 72-character width. Many people receive messages on TI's or other terminal set to 72 characters. Also, 80 characters is really pretty hard to read, even on a scope. ---Charlotte 8-SEP-79 17:47:21-PDT,1043;000000000001 Mail-from: MIT-ML rcvd at 8-Sep-79 1537-PDT Date: 8 Sep 79 17:59-EDT (Sat) From: Dcrocker at UDel-EE Reply-to: Dcrocker at Rand-Unix Subject: MSGGROUP#1237 Availability of Message System Paper To: Msggroup at Mit-Ml Message-ID: <79250.64795.7931 @ UDel-EE> Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 Last Spring, we made available to MsgGroup a paper on the University of Delaware's distribution system. A revised, expanded version of the paper will be presented at the 6th DataCom Symposium in November and we have it available for anyone who wants a copy, online or hardcopy. The paper is now titled "An Internetwork Memo Distribution Capability -- MMDF". If you want a copy, please send (only) me a message with the appropriate addressing information. The paper is about 14 printed pages, single-spaced. The online will come fully formatted with (bless Unix' soul) pagination done by line-feeds and not form-feeds. Dave. 9-SEP-79 13:59:58-PDT,514;000000000001 Mail-from: MIT-ML rcvd at 8-Sep-79 2220-PDT Date: 8 Sep 1979 2157-PDT From: LCAMPBELL at SRI-KL Subject: MSGGROUP#1238 Re: replying to messages To: Admin.MRC at SU-SCORE, MsgGroup at MIT-ML In-reply-to: Your message of 8-Sep-79 0026-PDT Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 YES, ESPECIALLY WHEN FORCED TO READ MAIL AT 300 BAUD, HAVING AN EARLIER MESSAGE INSERTED INTO THE REPLY TO IT IS ANNOYING. ------- 10-SEP-79 23:23:58-PDT,45646;000000000001 Date: 9 Sep 79 16:06-EDT (Sun) From: Dcrocker at UDel-EE Reply-to: Dcrocker at Rand-Unix Subject: MSGGROUP#1239 MMDF - Full text - with ^L & underscore Subject: An Internetwork Memo Distribution Capability To: MSGGROUP at USC-ECL Message-ID: <79251.58002.2180 @ UDel-EE> Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 The following is the paginated version WITH ^L form-feeds. It also includes imbedded underscores. The text is 823 lines long, and prints on 14 pages. Dave. ----- AN INTERNETWORK MEMO DISTRIBUTION CAPABILITY -- MMDF David H. Crocker Edward S. Szurkowski David J. Farber September, 1979 Department of Electrical Engineering University of Delaware Newark, Delaware 19711 (To be published in the Proceedings___________ of__ the___ Sixth_____ Data____ Communications______________ Symposium_________, Pacific Grove, California, November 1979.) AN INTERNETWORK MEMO DISTRIBUTION CAPABILITY -- MMDF ABSTRACT________ The advent of packet-switched networks has led to increased use of computers for sending text messages (memos) between peo- ple. However, attachment to common carrier or equivalent packet networks is expensive and/or restricted by organizational poli- cies. In addition, use of several networks creates the need for relaying memos between them. The work described here is designed to free users from dependence upon any particular communication environment and to provide a memo distribution facility which can employ whatever communication channels are available. It will support variable-network structures, emulation of network attach- ment, and inter-network memo forwarding. INTRODUCTION____________ It has been common for stand-alone time-sharing systems to provide some text message (memo) services to their users. Such services typically allow simple transmission of a block of text from one user's storage space into some other user's space. As such, these facilities are little more than restricted disk file-copy mechanisms. Little or no specialized software is pro- vided to aid in creation, viewing, or final disposition of mes- sages. However, the advent of packet-switched networks gave a major boost to the use of these services and resulted in a demand for improvements to their functionality. These changes seem pri- marily to be due to the vastly increased base of potential com- municants and to their geographic separation. The DARPA Network (ARPANET) provided the first major oppor- tunity for ongoing inter-organizational human communication to take place using geographically distributed computers [15, 9, 3]. Common carrier-oriented, network-based message systems are begin- ning to appear, although most of their initial orientation is toward using the network to connect the users' terminals to the same machine, rather than toward having a number of machines, each located near users, and employ the network to transmit mes- sages between machines. The existing ARPANET-based environment is still quite lim- ited in size and there are many potential communicants who are not attached. A user's costs of attaching to a common carrier- oriented packet network are quite high and, as in the case of the ARPANET, there often may be organizational policies restricting who is allowed to access it. In addition, the current trend is toward a profusion of networks, so attachment to one will not guarantee the ability to send messages to a given other user. The work underway at the University of Delaware has created an 2 application-level system for the distribution of memos between machines not attached to a packet network, to permit machines to emulate network attachment and to allow inter-network memo dis- tribution. FRAMEWORK_________ FOR___ MEMO____ PROCESSING__________ The basic object of manipulation is a message, currently limited to text and not including drawings, facsimile, speech, or the like. It has a structured segment, containing some header information such as recipient lists and a subject line, and it has an unstructured body of text. Users may have a program aid in the acquisition of the message parts (e.g., by prompting) and then initiate transmission. For messages sent to users of the same machine, delivery is, of course, quite rapid; to users on machines attached to the same network, delivery usually occurs within a few minutes. The recipient may have available a program which aids in processing messages for initial viewing and later disposition (filing or deletion). Often, the creation and recep- tion programs are identical (or linked) so that, for example, the destination address and subject lines of a reply message can automatically be taken from the received message. We classify the existing message systems as "memo" proces- sors to indicate their usual role within human communications. They do not attempt to support the full range of formal inter- organizational communications, which could require such services as full typography, multiple media (e.g., voice and facsimile) and authenticated "signatures". Architecturally, a message system may be factored into user and distribution environments. (See Figure 1). The user environment may allow the user to create, view, modify, remove and/or store messages and to interface with the distribution package for submission (posting) and receipt (delivery). The distribution package is responsible for accepting a message when posted, transmitting (relaying) it on toward the equivalent package on the recipient's machine and delivering it into the recipient's domain. If sender and receiver reside on the same machine, a zero-hop case results in exercising only one package; on the ARPANET, delivery between a sender and receiver using different machines is usually one hop. An intended reci- pient may be a person or a process; with the former, delivery is necessarily to some computer-based "agent" such as a standard disk file or a special program [12, 1, 18, 14]. Most work has been devoted to the development of sophisti- cated user environments, with a wide range of text (word) pro- cessing features [e.g., 1, 7, 8]. In a few cases, data-base management systems have been employed to help users wade through the mass of memos they have to process [17, 18]. For example, an informal survey of various ARPANET users indicates that process- ing 20-50 memos a day, per user, is not uncommon. Over the course of a year, management of the resulting glut of data can be 3 extremely difficult. Delivery facilities have received relatively little atten- tion. The most important standard feature for network environ- ments is a facility's taking responsibility for re-trying transmission when a receiving host's distribution package is not initially available; failure to transmit a message within a period of time usually results in the message's being returned to its sender. Some systems also allow forwarding mail to a reci- pient known to the system, but having a mailbox on another machine which can be reached. Several systems provide an extremely useful extension to this service, by allowing the known name to map into more than one address; sending mail to a distri- bution list thereby only requires specification of one address. A more robust environment might include change-of-address notifi- cation, return-receipt, levels of privacy (such as end-to-end encryption), priority handling and the like. On the ARPANET, the existing mail transmission protocol allows only simple transfer of a single message for a single recipient [11, 13]. A separate transfer is required to send a copy of a memo to each indicated recipient. Two replacement pro- tocols have been proposed, but neither has been pursued [5, 19]. Another attempt is now underway [14]. Also in the past year, IFIPS Working Group 6.5 has been formed to begin specifying a standard for international use. GOALS_____ The University of Delaware's Multi-channel Memo Distribu- tion Facility (MMDF) is intended to interface to user-environment systems in such a way as to provide an integrated view of a com- munication environment which can have a variety of different transmission channels. Consequently, sending a message to a local user, to a user on a machine attached through a local, national or international packet network, or to one on a machine accessible only through a telephone call involves the same effort and procedures for the user. The degree to which users are impacted by changing underlying channels is minimized. It is also intended that the need for multi-hop relaying will be tran- sparent to the user. At present, the level of service provided to the user is approximately the same as is available on the ARPANET. By allow- ing specification of a list of recipients, for a given channel, MMDF provides a degree of message batching ("bagging"); this is in contrast with the transfer-per-copy required in the ARPANET protocol. Also, provisions exist for indicating that a memo is to be broadcast on users' terminals, rather than, or in addition to, being put into their mailboxes. This is already experimen- tally available on some ARPANET hosts [6]. An additional capa- bility, which has to date received only limited use, allows reci- pients to have their own agent program automatically invoked to take non-standard actions during final delivery. 4 ARCHITECTURE____________ MMDF is implemented under Western Electric's Unix(TM) operating system, running on DEC PDP-11s and has modules for han- dling deliveries to the local machine, the ARPANET, and machines accessible through a telephone call. Memos must conform to the syntactic requirements now in effect for ARPANET text messages [2]. Primary_______ Functionality_____________ In order to provide reasonable data security and privacy and to facilitate deferred deliver of messages, MMDF operates separately from the user, once a memo is submitted for transmis- sion; however a sender may elect to observe the initial transmis- sion attempt. In particular, no storage (file) space is shared with users and users' access to MMDF's storage space is highly restricted. Figure 2 is an overview of the MMDF process struc- ture. Posting of a memo is initiated by some higher-level memo- manipulation system's invoking the SUBMIT program which is responsible for accepting a memo, parsing and partially verifying its distribution list, queuing the memo in MMDF's file space and, optionally, for invoking the DELIVER process if delivery is to be attempted immediately. (A background DELIVER daemon runs period- ically, processing those memos not yet transmitted.) Since all memos are passed through the SUBMIT process, it is quite easy to impose various format and content policies on them. Currently, SUBMIT enforces basic syntactic requirements, authenticates source information and partially verifies destina- tion specifications. The syntax checking only verifies that fields are properly delimited and is not concerned with their internal format. Source information is supposed to indicate who sent the memo, since it is not considered acceptable for anonymous senders to consume -- and possibly flood -- storage space of recipients; however some "anonymous" mail is currently allowed, but such messages are explicitly marked as having unau- thenticated source addresses. For the specification of destina- tion mailboxes, SUBMIT can fully certify the existence of mail- boxes on the local machine, but can only certify the existence of the (next) host specified in non-local addresses. In the latter case, detection of non-existent mailboxes is deferred until delivery is actually attempted. A more robust inter-machine functional protocol might allow complete certification at the time of submission. An aliasing facility is provided to extend the basic list of known names (i.e., login names). The extension allows users to receive mail under several names, as might be necessary if the user's login name were not well known. Also, mail can be accepted for forwarding to another machine; and the facility sup- ports distribution lists by allowing a single alias name to expand into multiple addresses. The facility currently is merely a keyword-oriented, string-replacement mechanism and proves 5 remarkably useful, given its simplicity. A more sophisticated mechanism would understand human name construction and would intelligently map first/last name combinations into user mailbox addresses. Through a simple protocol, a single SUBMIT process can accept multiple memos for posting. A posted memo is queued into two files; the first contains envelope-related information and the second contains the message text. Envelope information includes message status, such as the time the memo was queued, as well as the return address and the recipient address list. Con- ceptually, it is useful to think of this file as containing a set of independent envelopes. Addresses consist of a mailbox reference and an optional host reference. If the host reference is present and does not refer to the local host, mailbox reference may include further host reference(s), implying multi-hop relaying. However, this is not relevant to the SUBMIT which is parsing the address solely to select the (next) transmisson channel. The local channel receives special handling (e.g., verification of the mailbox references) since it effects final delivery, but SUBMIT otherwise is not aware of individual channels' characteristics. The address is actually a transport path specification, in which a host reference directly maps into a channel name, through a sim- ple name-table search. A more robust facility might make a stronger separation between address and path, as discussed in [16]. DELIVER is responsible for managing the transmission pro- cess, recording its success and handling failures. It invokes subordinate processes to perform actual transmission on indivi- dual channels. The envelope list stored by SUBMIT explicitly names the appropriate channel for each address, so that DELIVER is not required________ to have any specific information about channels. However it does have code which implements policies attempting to regulate when____ a channel may be invoked. If DELIVER is running as the background daemon responsible for processing memos not yet transmitted, it uses the time of queueing so that memos will be delivered in the order submitted. In addition, this is used for a two-stage time-out in the event of transmission failures. After the first time-out (e.g., one day) a warning memo may be sent to the return address, indicating to whom the memo has not yet been successfully transmitted. After the second time-out (e.g., four days), the entire memo is removed from the queue and may be sent to the return address. The normal mode for message systems is to have the distri- bution package initiate transmission to the next relay site. That is, when a message is queued an active attempt is made to transmit it on toward the recipient. In order to implement a special use of telephone circuit-based delivery, we have added a "passive" mode, called "Post Office Box" delivery. In this mode, a queued message is held until the next, or recipient, machine attaches itself and requests (i.e., polls for) any P.O. Box 6 messages being held for it. For example, this allows a machine attached to a network to hold messages arriving from the net, until unattached machines call up. A more robust option allows a message to be handled in both modes, according to which side first initiates connection, so that it is actively sent if the holding machine initiates and passively sent if the receiving machine initiates. Control_______ of__ Transmission____________ Modules_______ When a transmission module is invoked, it has access to the memo's text, but not its address list. A simple protocol is used by DELIVER to pass individual addresses to a module. After receiving an address the module responds to DELIVER with an indi- cation that the "envelope" is acceptable or not, that a copy of the entire memo has just been sent for the indicated addressee, or that an error occurred. When DELIVER indicates the end of the address list for that module, the module signals normal comple- tion or an error. If normal completion is indicated, DELIVER marks as completely processed those addresses which were previ- ously marked as only having had the envelope accepted. One of the error conditions is for an unavailable host and this may occur at any time. If it does, DELIVER terminates the current invocation of the module and moves on; the background DELIVER will then again try transmission at a later time. The current policy is to have the background DELIVER minim- ize channel invocations, so that it attempts to send all messages queued for a channel, before moving on to the next one. Transmission____________ Modules_______. Currently, four transmission modules have been built: LOCALSND, ARPASND, PHONESND, and POBOXSND. Transmission to another machine involves two levels of protocols. A low-level link protocol allows uninterpreted data to be transferred; a higher one deals with the semantics of passing memos. Minus various user interface features, the higher level protocol should correlate with the features of the SUBMIT program. None of the existing modules use a mail submission protocol which allows con- tinuation after interruption from sending a message (or address list). Instead, transmission must restart from the beginning of the negotiation, including full transmission of the message text. Under Unix, the LOCALSND delivery module must run with spe- cial privileges, since it must be able to write onto any user's mailbox and, for privacy reasons, mailboxes normally are pro- tected. The standard action is to append a new message to the end of a recipient's mailbox file. However, a feature is avail- able which allows any recipient to have a special program invoked at the time of delivery. The program may take full responsibil- ity for delivery or may merely augment normal delivery with other special actions. Currently, it is used for automatic incorpora- tion into a simple data base which holds system-wide public news messages. An alternate use might have the user's program take special action to notify the user of the message's arrival, while 7 still allowing standard delivery of the message. For a machine attached to the ARPANET, the ARPASND module handles transmission to other attached hosts. It employs the File Transfer Protocol (FTP) for mail submission and sends a separate copy of the message for each recipient [11, 13]. (Unfortunately, some hosts will accept messages, indicating suc- cessful delivery, even when the recipient is unknown. They typi- cally then send the message to a lineprinter or to the operator.) Receipt of messages from attached hosts is accomplished separately, by a FTP serving process which invokes SUBMIT. PHONESND performs telephone-based transmission and requires use of dial-out hardware. Since telephone calls may be expensive and slow to make, DELIVER may have a particularly stringent pol- icy regarding the timing of PHONESND's use, such as limiting calls to the period of lowest telephone rates and/or until several messages are queued. To effect transmission, PHONESND calls the destination com- puter and then starts a slave (serving) process which runs as a normal user program and does not require any special operating system privileges. The data-transfer (link-level) protocol currently being used is simple and idiosyncratic; it is believed that it can be implemented on any operating system, employed in a user process having no special privileges and operates in a strictly half-duplex manner. No attempts have yet been made to perform data compression or otherwise maximize effective channel bandwidth; however it appears likely that such enhancements would not be difficult. PHONESND accomplishes pickup of P.O. Box-held memos from a host, as well as transmitting queued messages to it. However to DELIVER, PHONESND appears merely to be another transmission module. The current policy is to send outbound messages, as shown in the top half of Figure 3, before retrieving P.O. Box messages, as shown in the bottom half the figure. It depicts the full process structure for two Unix-based MMDF systems partici- pating in this type of exchange. As a normal transmission module, PHONESND is handed an address by DELIVER, transmits it to the slave which passes it onto the SUBMIT. SUBMIT then returns an acceptance or rejection response, which the slave transmits back to PHONESND, which passes it to DELIVER. When DELIVER signals PHONESND that there are no more addresses for a message, PHONESND attempts to send the message text. Upon successful completion, it notifies DELIVER. When DELIVER signals that there are no more messages, PHONESND invokes a local version of SUBMIT and asks the slave process to initiate transmission of any P.O. Box messages waiting to be picked up. The slave then invokes a DELIVER, on its end, requesting pickup of any P.O. Box mail for the calling host (determined by the name under which it logged into the slave host). The slave's DELIVER invokes the POBOXSND module which 8 actually performs the mail transfer back up to the slave, across to the calling PHONESND, and onto its SUBMIT. The transaction then follows a submission protocol identical with that originally used to submit mail in the other direction. Note that POBOXSND does not initiate any connections. Instead it merely "releases" any messages waiting for its caller, up through the controlling terminal connection. In the MMDF running at the University of Delaware, DELIVER believes that the PHONESND module is actually the ARPANET module. In this fashion, the system thinks that it actually is attached to the network, with the PHONESND module being the only one aware of the need to go through a telephone call and relay station. Such attachment emulation could be quite useful for allowing a number of unattached machines to share the costs of using a common-carrier packet network. A greater average delivery time is the only____ performance difference that can be perceived by users. What is also significant is that the eventual transition of connecting one of these unattached processors directly will be completely transparent to its users. The cost of entering into network-based memo communications is thereby greatly reduced. ACCESS______ CONTROL_______ & DATA____ SECURITY________ All of the modules in MMDF can access memo text and there- fore must be viewed as "trusted" processes, free of any Trojan Horse security violations. However, the system is designed to prevent unauthorized access by others, to the limit of the operating systems's capabilities to do so. All memos offered for distribution are passed through the SUBMIT process, so that all policies regarding the "validity" of memos are implemented in it. The policies described earlier are relatively few. As an example of differing policies, stronger enforcement of memo syntax may be desired, to guarantee that user programs can use information in the memo for filing and con- structing replies. Machines which exchange memos, via MMDF's PHONESND, must do so with prior agreement since the caller must be able to log into the server. This login requirement makes the question of the server's trusting the caller -- for example, whether it believes that a memos's source information has been adequately authenti- cated -- purely an administrateive issue. Using the example, a server which trusts a caller will not have to add a disclaimer to a submitted memo, indicating that the source information has not been authenticated. To some extent, the system's operational control can be viewed as involving communication between message system "security kernels". Once a memo is submitted for transmission, it resides in file storage which is protected from users. Only authorized processes, such as SUBMIT and DELIVER are able to access the data in that storage space. Therefore, memos are protected to the 9 limit of the operating system and MMDF software integrity. STATUS______ Two sets of MMDF systems are currently operational. The initial set consists of the University of Delaware, Department of Electrical Engineering's DEC PDP 11/70, which has dial-out hardware and is not attached to the ARPANET, and the Rand Corporation's PDP 11/70, which is attached to the ARPANET. As discussed above, use of Rand's system allows the Delaware system to emulate network connection. An early version of MMDF software was exported to SRI International, for its use in tying together a PDP 11/70 at Gal- laudet College, in Washington, D.C. and an SRI PDP 11/40 in Menlo Park, California, as a demonstration telecommunication network for the deaf ("Deafnet"). The project is funded by the Depart- ment of Health, Education and Welfare, and this first phase is intended to show the feasibility of augmenting the deaf community's existing mechanism (direct station-to-station phone calls using obsolete baudot TTY's and non-standard modems) with current communication technology, particularly that of distri- buted computer networks. MMDF runs as a collection of user programs. No modifica- tions to the operating system are required, although a file exclusive-open mechanism, developed at Rand, and the Alarm (time-out) system call are used if available. As mentioned ear- lier, the local delivery process must run with extra privileges, to be able to write onto any user's mailbox. Due to the nature of Unix, it is convenient to have each functional module occupy a separate process. This imposes measurable additional costs, but provides considerable flexibil- ity and avoids the address-space problems common to 16-bit machines. The Delaware and Rand machines have been cooperating to provide a regular, reliable service for exchanging memos, since the middle of Spring, 1979. The background DELIVER processes at both sites have a one-half hour sleep cycle. Because Delaware has access to a WATS telephone line, for calling Rand, the current policy is to allow queued memos to be transferred when the background DELIVER next wakes up. If no mail has gone out within two hours, Delaware forces a call to request any P.O. Box mail that is waiting. During a transfer session, total effective bandwidth tends to be 1-1.2 kilobytes per minute______, using 300 baud modems. Transfer of 250 kilobyte memos is common and transfers of more than 500 kilobytes have been accomplished. However it should be noted that large transfers commonly require several tries before completing successfully; this would be considerably less painful if the protocols allowed continuation after interr- uption, rather than requiring starting from the beginning. With the current configuration, it is common to have closed-loop com- munication between a Delaware and ARPANET user, with one memo in 10 each direction, take two hours. While much slower than is com- monly experienced by hosts directly connected to the ARPANET, it is eminently useful. The only piece of software not yet built would allow users to query about the status of queued memos which have not yet been sent and, optionally, to remove these memos from the queue. Note that this capability is essentially unavailable with the United States Postal Service; retrieving a piece of mail, once it has been placed in an outgoing mailbox, is virtually impossible. Consequently, this program is not considered to be critical to the operation of the facility. CONCLUSION__________ In the past, computer-based memo distribution has been lim- ited to a shared local machine and, possibly, to an attached packet network. Attachment to common carrier-oriented networks of this type is expensive and still severely limits to whom mes- sages can be sent. The current project has developed a distribu- tion facility which can take advantage of a wide range of transmission channels available to it, including the telephone and local networks, and promise to reduce greatly the entry cost for performing computer-based memo processing. Although no attempt has yet been made to optimize system performance carefully, and some of its design would appear to impose substantial costs, preliminary indications show reasonable operating performance and costs. With proper tuning, the system should constitute an extremely cost-effective communication tool. ACKNOWLEDGEMENTS________________ The current software makes use of a skeleton distribution system which was built by Steven Tepper, of the Rand Corporation, for the Defense Advanced Research Projects Agency, and already contained provisions for the alias, two-stage time-out and individualized-receipt features. Also, Robert Anderson, formerly of Rand, and Stockton Gaines, of Rand, have been extremely cooperative in permitting the use of their Unix system during the development of this system. SRI adapted MMDF to operate symmetrically, with any host able to originate or receive calls. Our discussions with them led to a more general implementation of the active/passive mechanism and to the system's status-logging package. And, of course, the exchange provided us with a better understanding of some of the difficulties in transporting the system into other operating situations. Our participation in the recent activities of IFIPS Working Group 6.5, on International Computer Message Services, has also greatly aided in our understanding of this domain; some of the vocabulary used in this paper and some of the organization to 11 Figure 1 were taken from those discussions. We would also like to thank Vinton Cerf, of DARPA, for some cogent comments on an earlier draft of this paper. This work has been supported in part by the University of Delaware and in part by research contracts from the General Sys- tems Division of International Business Machines and from the Department of the Army Materiel Development and Readiness Com- mand. REFERENCES__________ [1] Crocker, D.H. Framework_________ and___ Functions_________ of__ the___ MS__ Personal________ Message_______ System______. R-2134-ARPA, The Rand Corporation: Santa Monica, Calif. (1977). [2] Crocker, D.H., Vittal, J.J., Pogran, K.T., and Henderson, D.A. Standards for the Format of ARPA Network Text Mes- sages. In: [4]. [3] Crocker, S.D., Heafner, J.F., Metcalfe, R.M. and Postel, J.B. Function-oriented Protocols for the ARPA Network. In: AFIPS_____ Proceedings___________, Vol. 40, 271-9 (1972). [4] Feinler, E. and Postel, J. (eds.). ARPANET_______ Protocol________ Handbook________. NIC-7104-REV-1, Network Information Center, SRI International: Menlo Park, Calif. (1978) (AD-A0038901). [5] Haverty, J.F. MSDTP -- Message Services Data Transmission Protocol. RFC No. 713, NIC No. 34739, Network Information Center, SRI International: Menlo Park, Calif. (April, 1976). [6] Harrenstein, K.L. FTP Extension: XSEN. In: [4]. [7] Heafner, J.F., Miller, L.F., and Zogby, B.A. Sigma_____ Message_______ Service_______ Reference_________ Manual______. ISI/WP-5, Information Sciences Institute, University of Southern California: Marina del Rey, Calif. (Feb., 1977). [8] Henderson, D.A. and Myer T.H. Issues in Message Technology. In: Proceedings___________ of__ the___ Fifth_____ Data____ Communications______________ Symposium_________, 77CH1260-9C, IEEE: New York, pp. 6:1-9 (Sept., 1977). [9] Kahn, R.E. The ARPA Network -- Packet-switching Technology. In: IEEE____ Conference__________ on__ Communication_____________ Systems_______ and___ Technology__________, IEEE: New York, p. 134 (1974). [10] Levin, R. and Schroeder, M.D. Transport of Electronic Mes- sages Through a Network. In: Boutmy & Danthine (eds), TeleInformatics_______________ 79__. North-Holland Publishing (June 1979). [11] Neigus, N. File Transfer Protocol for the ARPA Network. In: [4]. 12 [12] Pickens, J. Functional Distribution of Computer Based Mes- saging Systems. In: Proceedings___________ of__ the___ Sixth_____ Data____ Communications______________ Symposium_________, IEEE: New York (Nov. 1979). [13] Postel, J. Mail Protocol. In: [4]. [14] Postel, J. An Internetwork Message Structure. In: Proceedings___________ of__ the___ Sixth_____ Data____ Communications______________ Symposium_________, IEEE: New York (Nov. 1979). [15] Roberts, L.G. and Wessler, B.D. The ARPA Computer Network. In: N. Abramson & F.F. Kuo (eds.), Computer________ Communication_____________ Networks________, Prentice-Hall: Englewood Cliffs, N.J., pp. 485-500 (1972). [16] Schoch, J.F. Inter-Network Naming, Addressing, and Routing. In: Proceedings___________ of__ COMPCON_______ 78__. IEEE: New York (Fall, 1978). [17] Sattley, J. MARS -- A Message Archival and Retrieval Ser- vice. RFC No. 744, NIC No. 42857, Network Information Center, SRI International: Menlo Park, Calif. (Jan, 1978). [18] Vezza, A. and Broos, M. An Electronic Message System: Where Does it Fit? In: Proceedings___________ of__ Trends______ and___ Applications____________: Computer________ Networks________, IEEE: New York (1976). [19] White, J.E. A Proposed Mail Protocol. RFC No. 524, NIC No. 17140, Network Information Center, SRI International: Menlo Park, Calif. (June, 1973). 13 ---------------------------------------------------------------- | User Environment Distribution Environment | | | | --------------- Queue of | | ----------------- Posting | Accept and |----> memos | | | Compose Send-|--------> | Queue memos | | | | | Format Show | --------------- V | | | Edit File | ------------------ | | ----------------- | | | | / / / V V | | Memo Receiving ------------- ------------ | | Folder1... Mailbox <----- | Deliver | | Relay to |--> | | | To Local | | Foreign | | | | Mailboxes | | Sites | | | ------------- ------------ | ---------------------------------------------------------------- Figure 1: General System Structure for Memo Processing ---------------------------------------------------------------- | --------- -------- --------- | | |user | -> |SUBMIT| . > |DELIVER| . . . . | | |program| -------- . --------- . . . . | | --------- | . . . . V . . . | | | . --------- . . . -- | | | . -----> |ARPASND| . . . | | | | . | --------- V . . |--> | | V . | ---------- . . | Relay | | (limited) Queue of |------> |POBOXSND| . . | toward | | (access ) messages --| ---------- V . | foreign | | / / | ---------- . | mailboxes | | Envelopes Texts |---------> |PHONESND| . | | | | ---------- V -- | | | ---------- Deliver | | -------------> |LOCALSND| -> to local | | ---------- mailboxes | ---------------------------------------------------------------- Figure 2: MMDF Process Structure ---------------------------------------------------------------- | Unattached Host (Caller) Attached Host (Server) | | * | | DELIVER (daemon) | | | Send --> SUBMIT | | V to | | | [Phonesnd]->(outgoing) . .> Net . > [Slave] -> (incoming) | | [----------------------------------------------------------] | | [Phonesnd]<-(incoming) <. . Pickup < . [Slave] <- (outgoing) | | | from ^ | | | V Net | V | | SUBMIT | DELIVER | | | (pickup)| | | | V | | -<--- POBOXSND | ---------------------------------------------------------------- Figure 3: Network Mail Forwarding for Unattached Hosts 10-SEP-79 23:23:58-PDT,910;000000000001 Mail-from: MIT-ML rcvd at 10-Sep-79 0734-PDT Date: 10 SEP 1979 0716-PDT From: RDEMENT at USC-ECL Subject: MSGGROUP#1240 Re: Please, no 80-column texts! To: MOOERS at BBN-TENEXA, MSGGROUP at MIT-ML Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 In response to the message sent 8 Sep 1979 1024-EDT from MOOERS@BBN-TENEXA IT SHOULD NOT BE NECESSARY TO IMPOSE FORMATING ON THE ORIGINATOR. IT IS A REQUIREMENT OF THE RECIEVIER AND SHOULD BE HANDLED BY THE RECEIVERS MAIL SYSTEM. I BET THERE ARE PEOPLE USING HOME COMPUTERS THAT HAVE ONLY 40COL DISPLAYS. MAYBE WE SHOULD ALL RESTRICT OUR MESSAGGES TO 40 CHAR PER LINE. I THINK ITS TIME WE USE THESE SOPHISTICATED MACHINES WE COMMUNICATE THROUGH TO OVERCOME LOCAL LIMITATIONS RATHER THAN IMPOSING THEM ON THE WHOLE MESSAGE COMMUNITY. { ------- 10-SEP-79 23:23:59-PDT,1049;000000000001 Mail-from: MIT-ML rcvd at 10-Sep-79 0933-PDT Date: 10 Sep 1979 at 0958-CDT From: david at UTEXAS Subject: MSGGROUP#1241 Re: Please, no 80-column texts! To: RDEMENT at USC-ECL cc: msggroup at mit-ml Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 You are wrong, wrong, wrong. The originator of a message has the sole responsibility for determining how a message looks, and the originator should have a self-interest in seeing that the message is attractive, so people will want to read it. You sent your message in all uppercase and with several typos. Am I supposed to be able somehow to figure out how to make that mixed upper/lowercase and fix the errors so it is acceptable to look at? No one is suggesting that we restrict ourselves to 40 columns, or even worse, all uppercase. A 72 column line allows lots of room and accomodates most people. I personally prefer a shorter column width, about 60 columns, for readability. ------- 10-SEP-79 23:23:59-PDT,1847;000000000001 Mail-from: MIT-ML rcvd at 10-Sep-79 1136-PDT Date: 10 Sep 1979 1051-EDT Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP#1242 Re: Please, no 80-column texts! From: MOOERS at BBN-TENEXA To: RDEMENT at USC-ECL Cc: MSGGROUP at MIT-ML, Mooers Message-ID: <[BBN-TENEXA]10-Sep-79 10:51:53.MOOERS> In-Reply-To: Your message of 10 SEP 1979 0716-PDT Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 Actually I am able to reformat 80-column messages with very little trouble using Hermes. It would be a very poor idea to re-format incoming messages automatically, so I suppose that what you are suggesting is that the mailhandling system give the user the choice of either changing the actual line length in the stored message (as Hermes is able to do) or displaying the message with a line length different from the stored form. I suppose the TI terminal does that, in some sense, when it "wraps" lines. Perhaps my background in typography is what really triggered this complaint. Eighty columns is a very long line for reading. In the "real world" of ordinary print, the only time that people use a column width of more than 60 characters is in the "fine print" of legal documents -- that is in places where the author wants to discourage the reader from reading the text. It is unfortunate that the standard 8-1/2 by 11 paper tempts people to use very long lines in books produced on the typewriter. It is even more unfortunate that the 80-column Hollerith card causes people who are used to dealing with computers to feel that 80 characters is a reasonable line length for text. It really is too long. And most people will blame the author rather than the line length when they have trouble reading a report! ---Charlotte 10-SEP-79 23:23:59-PDT,666;000000000001 Mail-from: MIT-ML rcvd at 10-Sep-79 0900-PDT Date: 10 Sep 1979 0810-PDT Sender: DBALL at OFFICE-1 Subject: MSGGROUP#1243 Re: Leaving/Paper From: DBALL at OFFICE-1 To: PANKO at SRI-KL Cc: msggroup at MIT-ML, dball Message-ID: <[OFFICE-1]10-Sep-79 08:10:25.DBALL> In-Reply-To: <[SRI-KL] 6-Sep-79 20:26:56.PANKO> Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 Ray: I would like a copy of your overview on electronic mail. Send to: Donald A. Ball USA AVRADCOM ATTN: DRDAV-ES PO BOX 209 St. Louis, MO 63166 Good luck in your future endeavors! Don Ball 10-SEP-79 23:23:59-PDT,2029;000000000001 Mail-from: MIT-ML rcvd at 10-Sep-79 1023-PDT Date: 10 September 1979 1137-EDT From: Brian.Reid at CMU-10A Subject: MSGGROUP#1244 Re: Please, no 80-column texts! To: MOOERS at BBN-TENEXA CC: RDEMENT at USC-ECL, MSGGROUP at MIT-ML, Mooers at BBN-TENEXA Message-ID: <10Sep79 113733 BR10@CMU-10A> In-Reply-To: <[BBN-TENEXA]10-Sep-79 10:51:53.MOOERS> Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 We normally send around to one another text that is either typed in by hand or is the output of some text formatter. If there were some kind of very simple standard for a text communication language, then what we could send around to one another could be in this text communication language and not in its processed output. Regions of text could be marked according to whether or not they were supposed to be centered, justified, accented (boldface or whatever), and so forth. Then the recipient's mail reader could process the text communication language into actual text, taking into account the characteristics of the recipient's terminal, and display that text to him. I am certainly not proposing that MsgGroup adopt any such standard -- we've had enough trouble getting people to agree on the syntax of a header. But as a consideration in the design of future systems, there ought to be some way to include in the text of a message enough information to allow it to be reformatted as needed by the recipient, in such a way that the recipient is never even aware that the text may have been in some other format when it left the sender's terminal. Of course these "formatting commands" that would be included in the text would never be displayed to the person reading the mail; he would only see the result of having processed them. A scheme like this can only work if everybody uses the same conventions. People in the ARPAnet community will never use the same conventions for anything. Brian 10-SEP-79 23:23:59-PDT,1170;000000000001 Mail-from: MIT-ML rcvd at 10-Sep-79 1256-PDT From: Gaines at Rand-Unix Date: 10 Sep 1979 at 0933-PDT To: RDEMENT at Usc-Ecl cc: MOOERS at Bbn-Tenexa, MSGGROUP at Mit-Ml Subject: MSGGROUP#1245 Re: Please, no 80-column texts! In-reply-to: Your message of 10 SEP 1979 0716-PDT. Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 Reformatting headers by the receiver's message system is one thing; reformatting the body of a message is another. There is substantial structure to headers to guide this process, and a great deal of (almost) agreed upon convention to take advantage of. But this does not apply to the body. Its form, as well as its content, in entirely the responsiblity of the sender unless there has been prior agreement between sender and receiver about format. The problem is not with the sophistication of the receiving machine. For both historical reasons and because it is natural for many widely used printing devices, a line width less than or equal to 72 characters makes a lot of sense. The suggestion of 40 characters is ridiculous. 10-SEP-79 23:23:59-PDT,2013;000000000001 Mail-from: MIT-ML rcvd at 10-Sep-79 1304-PDT Date: 10 SEP 1979 1157-PDT From: ESTEFFERUD at USC-ECL Subject: MSGGROUP#1246 Re: Please, no 80-column texts! To: RDEMENT, MOOERS at BBN-TENEXA, MSGGROUP at MIT-ML Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 In response to the message sent 10 SEP 1979 0716-PDT from RDEMENT@USC-ECL There are lots of real problems involved with attempts to reformat someone else's text to fit a new page size, or file structure. Tabular formats provide the most strikng and obvious example. I have seen numerous cases where the whole representation scheme had to be rethought to place it differently on the page. This is not your average artificial intelligence program problem, and it is certainly beyond anything we have in current message handling systems anywhere, in or out of ARPANET. I suggest my famous time honored test: "If your secretary reformatted your incoming mail without asksing, would you fire him?" (Again?) I find it unthinkable that I might actually trust the receiver to properly format my texts if I am to be held accontable for the meaning of the communication. I see no way to relieve the sender of full responsibility for formatting unless the sender abdicates the normal responsibilies for saying what is meant to be understood by the receiver. If I don't care what the receiver sees, then by definition I should not have sent the message in the first place. NOW THEN, regarding MSGGROUP communications, I am reformatting them with great care (I WISH I NEED NOT DO SO) to fit them into 72 column formats for the MSGGROUP PROCEEDINGS before shipping them off to the CCA DATACOMPUTER. I have previously requested MSGGROUP submissions to be formatted to less than 72 columns, and must warn you that I will reformat them to be 72 columns or less if you do not do so on your own. Best regards - Stef ------- 10-SEP-79 23:23:59-PDT,1037;000000000001 Mail-from: MIT-ML rcvd at 10-Sep-79 1948-PDT Date: 10 September 1979 2159-edt From: Bob Frankston Subject: MSGGROUP#1247 40 columns To: msggroup at mit-ml Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 A recent issue of the IEEE transactions on consumer electornics deals with Teletext and viewdata systems with display messages on a standard TV set. The standard appears to be developing as 40 columns by 24 lines. Considering that this will probably represent the most common terminal we should take the problems of communicating over such a interface seriously. An implication is that either the sender will have to take much care in formatting (most common case) or the receiver would have to have some control over the presentation. Possibly X1J6 can deal with some of the issues of embedding formatting controls in text, though I won't hold my breath waiting for them. 10-SEP-79 23:23:59-PDT,2224;000000000001 Mail-from: MIT-ML rcvd at 10-Sep-79 2142-PDT Date: 10 SEP 1979 2124-PDT From: JMCHUGH at USC-ECL Subject: MSGGROUP#1248 Let's see the WHOLE msg! To: MsgGroup at MIT-ML Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 It seems to me that there is no way for me to not accept responsibility for anything that I do in sending a message. Like talking on the phone and mumbling my words or coughing, there will be a response to what I do (or don't do) whether I desire that response or not. There is a "body language" associated with written communication that is just as subtle as the physical type . . . format IS important! Regardless of defaults and options available to a user in automatically generating addresses when responding to a message, I believe the user should SEE the resulting header to make sure it meets his/her needs. MSG at ECL has a profile switch which permits the user to always see the To: and cc: fields. But it would also be nice to be able to see the WHOLE message before sending. CNTRL-S types the message text, but there is no way to see the message header while in the MSG A(nswer) command. Yes, I have the responsbility to make my message communicate (even if my reader at some point in time is known to use 40-character display width), but I certainly want to be able to SEE what I'm delivering! Cheers - Jim ------ P.S. MSG (on Tenex at ECL) has a bug and I'm not sure where to get action --- so I'll "publish" it here: If ANYTHING (other than a legal address) is typed after it asks for "Additional addresses" and before it indicates that you should type the message text, it produces the results below. Unfortunately, there may be quite a delay between a carriage return after "Additional addresses" and the message text cue (a delay which tends to trap new users --- and sometimes older users who are used to typing ahead). ---The old subject line is discarded, the first line of text becomes the subject, and "Re:" is inserted in the cc: field. ... and the user is not able to SEE the horrible header before sending. ------- 11-SEP-79 15:46:00-PDT,1398;000000000001 Mail-from: SRI-KA rcvd at 11-Sep-79 1308-PDT Date: 11 SEP 1979 0032-PDT Sender: MSGGROUP at USC-ECL Subject: MSGGROUP#1249 [Dcrocker at UDel-EE: MSGGROUP#1239 MMDF ...] From: MSGGROUP at USC-ECL To: MsgGroup at MIT-ML Message-ID: <[USC-ECL]11-SEP-79 00:32:28.MSGGROUP> Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 This forwarded message contains only the header and explanitory text of DCrocker's MMDF text, along with a full path name listing to show exactly what file name to use for FTP retrieval of the full text message. [USC-ECL]MSGGROUP#.1239;1 - 1 file, 18 pages MSGGROUP#1239 has been placed separately in a message file to ease FTP access to it. Or, you may obtain a copy via netmail by netmail request sent to ESTEFFERUD@ECL, JMCHUGH@ECL, or MSGROUP@ECL. Begin forwarded message - - - - - - - - - - - - - - - - - - - -45515 chars Subject: MSGGROUP#1239 MMDF - Full text - with ^L & underscore An Internetwork Memo Distribution Capability Date: 9 Sep 79 16:06-EDT (Sun) From: Dcrocker at UDel-EE - - To: MSGGROUP at USC-ECL The following is the paginated version WITH ^L form-feeds. It also includes imbedded underscores. The text is 823 lines long, and prints on 14 pages. Dave. End forwarded message 11-SEP-79 15:46:00-PDT,1486;000000000001 Mail-from: MIT-ML rcvd at 11-Sep-79 0254-PDT Date: 11 September 1979 05:40-EDT From: "Marvin A. Sirbu, Jr." Subject: MSGGROUP#1250 Re: Please, no 80-column texts! To: MOOERS at BBN-TENEXA cc: MSGGROUP at MIT-ML Redistributed-To: Public at CCA Redistributed-By: ESTEFFERUD at USC-ECL (connected to MSGGROUP) Redistributed-Date: 12 SEP 1979 I was intigued by Charlotte's comment that most print is 60 character lines or less, so I did a non-random sample from several books at hand. Science magazine. three columns per page. about 30 characters per column Tolkein, "The Two Towers," (London: Unwin Books (paperback) 1974) about 77 characters per line Tolkein, "The Return of the King," (New York: Ballentine/Fantasy 1965) about 57 characters per line "The Official Warren Commission Report on the Assassination of President John F. Kennedy (Garden City, N.Y.: Doubleday (hardbound), 1964) about 68 characters per line. Proust, "Un Amour de Swann," (Paris: Livre de Poche, 1971) about 57 characters per line. Gottfried, "Quantum Mechanics," (New York: W.A. Benjamin (hardbound) 1966 about 70 characters per line. These are all of course typeset. I conclude that while magazines and some paperbacks adhere to the 60 character line limit, there are plenty of examples of longer line lengths. I will add, however, that the Unwin Tolkein edition does look more like a legal contract than a typical paperback. 11-SEP-79 13:10:02-PDT,6162;000000000001 Date: 11 September 1979 02:00-EDT Sender: MSGGROUP at USC-ECL From: MsgGroup at ECL Subject: MSGGROUP#1251 [ECL]SURVEY.1200-1250;1 To: MSGGROUP at USC-ECL Message-ID: <[USC-ECL]11-SEP-79 02:00:00.MSGGROUP> Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Messages from: [ECL]MSGGROUP#.1200-1250;1 MSGGROUP#1201 SURVEY [ecl]proceedings.msg#1151-1200 6142 chars 24 JUN 1979 0351-PDT From: JMCHUGH at USC-ECL MSGGROUP#1202 Re: Special Interest Group Mailing Lists 1028 chars 18 Jun 1979 1704-PDT From: Zellich at OFFICE-1 MSGGROUP#1203 Re: Special Interest Group Mailing Lists 1164 chars 18 Jun 1979 1714-PDT From: Feinler at SRI-KL (Jake Feinler) MSGGROUP#1204 Re: Info collection for compromise 557 chars 20 June 1979 1628-EDT From: David.Lamb at CMU-10A MSGGROUP#1205 MSGGROUP SCREWUP 574 chars 21 Jun 1979 at 2327-PDT From: Michael Wahrman MSGGROUP#1211 Re: This is a test AND [MSGGROUP#1199] 3949 chars 29 Jul 1979 1232-PDT From: STEFFERUD at OFFICE-1 MSGGROUP#1212 Re: This is a test AND [MSGGROUP#1199] 794 chars 29 JUL 1979 1815-EDT From: MOON at MIT-MC (David A. Moon) MSGGROUP#1213 Privacy and the USPS ECOM proposal 1323 chars 1 AUG 1979 1340-EDT From: SIRBU at MIT-MC (Marvin A. Sirbu, MSGGROUP#1214 Re: [ecl]mail.lst;3 1063 chars 28 August 1979 0248-EDT TUESDAY From: Brian.Reid at CMU-10A MSGGROUP#1215 CRTs and eyestrain 327 chars 08/30/79 07:45:51 From: SIRBU@MIT-MC MSGGROUP#1216 Re: CRTs and eyestrain 705 chars 30 Aug 1979 0944-PDT From: Bair at SRI-KL (James Bair) MSGGROUP#1217 Leaving/Paper 764 chars 6 Sep 1979 2026-PDT From: PANKO at SRI-KL MSGGROUP#1218 Re: Leaving/Paper 502 chars 6 Sep 1979 2348-EDT From: MOOERS at BBN-TENEXA MSGGROUP#1219 Re: Leaving/Paper 471 chars 6 Sep 1979 2119-PDT From: LCAMPBELL at SRI-KL MSGGROUP#1220 Re: Leaving/Paper 607 chars 6 Sep 1979 2317-PDT From: the tty of Geoffrey S. Goodfellow MSGGROUP#1221 Re: Leaving/Paper 556 chars 7 Sep 1979 0542-PDT From: STERNBERG at SRI-KA MSGGROUP#1222 Re: Leaving/Paper 562 chars 7 Sep 1979 0808-PDT From: Bair at SRI-KL (James Bair) MSGGROUP#1223 RE:Leaving/Paper 363 chars 7 Sep 1979 0859-PDT From: COMPORT at USC-ISI MSGGROUP#1224 Misuse of the reply facility in a message system 872 chars 7 Sep 1979 at 0949-PDT From: Gaines at Rand-Unix MSGGROUP#1225 Bug in the Reply command 779 chars 7 Sep 1979 1327-EDT From: LCAMPBELL at DEC-2136 MSGGROUP#1226 Re: Misuse of the reply facility in a message system. 853 chars 7 September 1979 1424-EDT From: Brian.Reid at CMU-10A MSGGROUP#1227 Re: Misuse of reply facility in a message system 797 chars 7 September 1979 1338-EDT From: Richard H. Gumpertz In-Reply-To: <[USC-ECL]11-SEP-79 00:32:28.MSGGROUP> Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I wonder if there is a version available that has not been through the mail system and had the underscores converted to ^H^H^H^H____ . Tom Bowerman 111-SEP-79 16:44:59-PDT,1370;000000000001 Mail-from: USC-ECL rcvd at 11-Sep-79 1028-PDT Date: 11 SEP 1979 0620-PDT From: JMCHUGH Subject: MSGGROUP#1253 Communications, Color & Games To: Hughes.List: CC: MSGGROUP Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 ---quoted from News & Comment in COMPUTER DECISIONS, August 1979. ". . . However, when communications between word procesors is desirable,lack of standardization is a problem. And communications are really vital. As Prof. Howard Lee Morgan of the Wharton School pointed out, 85 percent of a manager's work day is taken up with communications. ... "Prof. Morgan touted color displays for "executive" word processors, which are called management work stations. He uses one that is segmented to look like the top of his cluttered desk. One segment displays his "calendar," another lists electronic mail references, and so forth. "Before executives will work these stations, they have to be acclimated, said Morgan. He finds that executives, who usually scorn keyboarding, are much more willing to sit at a keyboard if they first spend several hours playing games like blackjack with the display. According to Morgan, some executives now handle revisions of their documents on word processors. But they refuse to enter long documents by keyboard." 11-SEP-79 16:44:59-PDT,2038;000000000001 Mail-from: MIT-ML rcvd at 11-Sep-79 1008-PDT Date: 11 September 1979 1143-EDT From: Brian.Reid at CMU-10D (A800BR10) Subject: MSGGROUP#1254 line widths To: "Marvin A. Sirbu, Jr." CC: MsgGroup at MIT-ML, Mooers at BBNA Message-ID: <11Sep79 114331 BR10@CMU-10D> Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Every book on introductory typography will tell you that the readability of set type is affected by factors like line length and line spacing. If you care to read the primary source, so read the study by Sir Cyril Burt: @i[A Psychological Study of Typography.] Cambridge University Press, 1959. See page 14, in particular, on which he asserts that the line length should never be more than two to three times the length of the string "abcdef.....xyz" in lower case in the font being used. (This distance is called, naturally, an "alphabet"). Burt suggests that two to three alphabets is the best line width for maximum legibility. On our fixed-pitch terminals, this comes to 52-78 columns, for which 72 is a nice compromise. This problem has been researched quite a bit; we are really johnnies-come-lately to the fray. If you care, the definitive sources on readability of type should include the classic work by Paterson and Tinker @i[How to Make Type Readable] (Harper and Row, 1940), and Tinker's more recent update, @i[Legibility of Print] (Iowa State University Press, 1963), and finally @i[Studies in Legibility of Printed Text] (Almqvist and Wiskell, Stockholm, 1965). Paterson and Tinker also measured the legibility of material in all-upper-case versus mixed caps/lowercase, and found a fairly consistent 12% decrease in reading time of material set in all caps. [ANNOTATION BY STEFFERUD, 22 Sept 1979: MSGGROUP#1260 & #1266 contain a challenge and reply to the claimed "12% decrease in reading time," and Brian Reid agrees that he meant to say "12% decrease in reading speed."] Brian 11-SEP-79 16:44:59-PDT,1112;000000000001 Mail-from: MIT-ML rcvd at 11-Sep-79 1051-PDT Date: 11 Sep 79 13:07-EDT (Tue) From: Dcrocker at UDel-EE Reply-to: Dcrocker at Rand-Unix Subject: MSGGROUP#1255 Sender control of Message Display Format To: MsgGroup at Mit-Ml Message-ID: <79253.47227.7060 @ UDel-EE> Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Some time ago, Jon Postel, I believe in response to some NSW needs, proposed some standard formats. A little while after that (I believe during the development of the RFC 733 format standard) I suggested standardizing some header components to transmit formatting descriptor information. No one has ever expressed much interest in either of these, in the past. Now, I've lost pointers to either document. I believe Jon's proposal was an RFC, but can seem to locate it. I've searched the MsgGroup transcript for my proposal, but couldn't find it; perhaps it was with Header-People. If anybody finds either document, it might be worth redistributing them (or pointing at them) for the current discussion. Dave. 11-SEP-79 16:44:59-PDT,1441;000000000001 Mail-from: MIT-ML rcvd at 11-Sep-79 1251-PDT Date: 11 Sep 1979 1400-EDT Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP#1256 Re: line widths From: MOOERS at BBN-TENEXA To: Brian.Reid at CMU-10D Cc: SIRBU at MIT-MC, MsgGroup at MIT-ML, Mooers Message-ID: <[BBN-TENEXA]11-Sep-79 14:00:42.MOOERS> In-Reply-To: <11Sep79 114331 BR10@CMU-10D> Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Thanks for supplying the references. I believe that Paterson and Tinker also point out that a number of other factors decrease legibility. Some of these are typewriter and sanserif typefaces and close vertical spacing (like single-space on a typewriter). Many of the typefaces available on terminals appear to be far worse than the classic typewriter and sanserif faces available to Paterson and Tinker. These factors -- close vertical spacing in particular -- are arguments for shorter line lengths. That is why we chose 65 characters for the line length in Hermes. The 80-character line is a historical accident, really. The 80-column Hollerith card was determined by the mechanical considerations in the design of the first Hollerith machines, and by Hollerith's unilateral decision to make the first Hollerith card the size of a dollar bill. That's an old-style dollar bill, of course. There haven't been any around for a long long time. ---Charlotte 11-SEP-79 16:44:59-PDT,886;000000000001 Mail-from: MIT-ML rcvd at 11-Sep-79 1334-PDT Date: 11 Sep 1979 1234-PDT From: Zellich at OFFICE-1 Subject: MSGGROUP#1257 Re: Sender control of Message Display Format To: Dcrocker at RAND-UNIX, MsgGroup at MIT-ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I don't have any info. on the original documents, but I heartily agree with putting standard formatting information in the Header. I don't know if any mail system could make much use of things like "Line-Width:" or "Page-Length:", but there is definitely a need for a header field describing tab settings. Of course, it wouldn't take care of the case where the sender changed tab settings throughout the document, but then nothing short of the recently-mentioned embedded standard formatting commands would handle that, anyway. Rich ------- 11-SEP-79 16:44:59-PDT,636;000000000001 Mail-from: MIT-ML rcvd at 11-Sep-79 1446-PDT Date: 11 September 1979 1726-EDT From: Richard H. Gumpertz Subject: MSGGROUP#1258 Re: Sender control of Message Display Format To: Dcrocker at Rand-Unix CC: MsgGroup at Mit-Ml Message-ID: <11Sep79 172620 RG02@CMU-10A> In-Reply-To: <79253.47227.7060 @ UDel-EE> Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 My ARPANET PROTOCOL HANDBOOK (REV Jan 78) has something similar on page 325, titled STANDARD FILE FORMATS (RFC 678, NIC 31524) which may be what you were looking for. Rick 22-SEP-79 11:37:32-PDT,821;000000000001 Mail-from: MIT-ML rcvd at 13-Sep-79 0306-PDT Date: 12 SEP 1979 1601-PDT From: JMCHUGH Subject: MSGGROUP#1259 Intra-Company EM System To: STrulock, LDodson, GAnderson cc: EStefferud, AJWichner, AWalden, BHuber, jmchugh, JTucker, cc: MacKenzie Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 --- from In The Industry column of WORD PROCESING REPORT, September 1, 1979. Nippon Electric has developed an intra-company electronic mail system (called ICEMS---Intra-Company Electronic Mail System) which consists of a central switch linking up the terminals. This central switch of the combined computer and fax systems features an integrated electronic exchange to handle both data and voice using voice grade lines. ------- 22-SEP-79 11:37:33-PDT,622;000000000001 Mail-from: MIT-ML rcvd at 15-Sep-79 1708-PDT Date: 15 SEP 1979 1958-EDT From: DCC at MIT-MC (David Caulkins) Subject: MSGGROUP#1260 Re: line widths (and reading speeds?) To: brian.reid at CMU-10D CC: msggroup at MIT-ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Do I interpret your message of 11 Sep 79 correctly ? i.e. material set in all caps reads 12% FASTER than that set in mixed caps/lower case. It is to be hoped that Sir CyrilBurt's work on typography does not suffer from the fraud that marred his work in psychology. Dave Caulkins 22-SEP-79 11:37:33-PDT,597;000000000001 Mail-from: MIT-ML rcvd at 15-Sep-79 1823-PDT Date: 15 Sep 1979 1813-PDT (Saturday) From: lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1261 all caps To: DCC at MC CC: Msggroup at ml Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 All caps definitely reads faster -- and more error free. There are fewer characters in an all caps font that can be easily confused. Have you ever seen radio or TV announcing copy? It is ALWAYS all caps, extra-big type, and fewer characters per line. --Lauren-- ------- 22-SEP-79 11:37:33-PDT,2000;000000000001 Mail-from: MIT-ML rcvd at 15-Sep-79 2041-PDT Date: 15 September 1979 23:25-EDT From: Frank J. Wancho Subject: MSGGROUP#1262 ALL CAPS To: MsgGroup at MIT-ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Also speeches, TelePrompter copy, cue cards, freeway and other road signs, TWXs... TWXs? Have you ever tried to read one of those lately? Which brings us back to the original(?) subject... I have lived for several years with an UPPER case terminal, but in the last two or so, I don't know how I did. I abhor them now. I don't write for speed-reading ability, I write for content - and I would like to think that that's the way it's read. I also get upset when I have taken the time to compose my material in both cases, only to find out later that the intended recipient had missed the underlying tone because he had an UPPER case-only terminal. As for width of the line problem - it is mostly output from those who apparently have 84-character per line terminals and either don't know when to quit, or don't bother/forget to reformat to something less, or don't know any better because it looks OK to HIM. In those cases, I will take the time it takes to make a single keystroke to reformat the text so I can see what s/he has to say, before I delete it. The same goes for spurious backspaces and linefeeds. As for 60 characters, maximum, consider overall appearance/balance on a typical terminal with an 80 character width. I'd vote for 60 based on a paper width of 8 inches and 10 characters/inch, IF I had my printer set for one-inch margins. But, most of the time my printer is set much nearer the left margin because I work with card-image code and other text. Then you must consider those printing terminals on which margins cannot be changed and paper is $2-3/100 feet... a limit of 60 wastes 20% of the paper...anyway, consider balance/appearance. --Frank 22-SEP-79 11:37:33-PDT,1485;000000000001 Mail-from: MIT-ML rcvd at 15-Sep-79 2137-PDT Date: 15 SEP 1979 2125-PDT From: JMCHUGH at USC-ECL Subject: MSGGROUP#1263 Re: all caps To: lauren at UCLA-SECURITY cc: JMCHUGH, MsgGroup at MIT-ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 In response to your message sent 15 Sep 1979 1813-PDT (Saturday) Re: "All caps definitely reads faster --- and more error free." Though I have met others who thought as you, Lauren, I believe that the research as well as careful personal observation disprove it. The only error-free aspect of all caps typography is that it completely eliminates any question of what words should have initial caps. It sure cuts down on proofreading costs and exposure to criticism for incorrect capitalization. Conventions on briefing charts, speeches and TV news copy traditionally have used all caps, but they are also typically double-spaced copy --- and in many cases use very short lines. One place where you WILL find single-spaced all caps copy (and on very long lines) is in installment contracts and terms and condi- tions --- documents that the preparing company does not want read. Lauren, as you drive the freeways, note what is all caps and what is initial caps on the signs. I think that you will find short instruc- tions (like "EXIT") in all caps and all street names in initial caps.... Best - Jim ------- 22-SEP-79 11:37:33-PDT,1224;000000000001 Mail-from: MIT-ML rcvd at 16-Sep-79 0318-PDT From: FFM@MIT-MC Date: 09/16/79 06:07:24 Subject: MSGGROUP#1264 ALL CAPS Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 FFM@MIT-MC 09/16/79 06:07:24 Re: ALL CAPS To: DCC at MIT-MC, MSGGROUP at MIT-ML I DON'T KNOW WHETHER ALL CAPS READS FASTER. IM IGHT THINK THAT IT WOULD CAUSE YOUR MIND MIGHT BE SWITCHED INTO EMERGENCY MODE AS MOST THINGS IN ALL CAPS HAVE BEEN IN THINGS OF THE TONE OF "You better read this right now!!!" However that effect wears out I suspect. Anyway I am under the impression that the reason teleprompter things read fast is not only all caps but short sentences and large letters are used. I think all this complaining about prettyness of correspondence is slightly prima donna-ish. " Unless you make your letter pretty the may I want it , I ; won't read it so there!!" you can imagine someone saying. However one should try to make it easy to read for most everybody if at all possible. So 60 collumn lines and a minimum of real cruft is nice. All caps is not a capitol offense but after 5 pages of the stuff it does wear on one a bit. Have fun Sends Steve 22-SEP-79 11:37:33-PDT,2259;000000000001 Mail-from: MIT-ML rcvd at 16-Sep-79 0417-PDT Date: 16 Sep 1979 0404-PDT (Sunday) From: lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1265 informal typographical "mannerisms" To: MSGGROUP at ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I hope I am correct in assuming that the real issue in the ongoing "all caps" discussion is the question of overall "accurate information flow" rather than completely a question of message prettiness. I was particularly interested by the comment concerning loss of meaning in a message that was read in all caps but was written in mixed upper/lower case. I wonder how many of us have really thought seriously about some of the "mannerisms" we commonly use in messages: I definitely DO NOT agree. -- caps for emphasis Oh yeah, tell me ALLLLL about it. -- caps and elongation for emphasis and to simulate a particular speech pattern Well ... golly ... I'm not sure. -- dots as used in common literature for "delay". One thing's for sure, ** I ** do not agree with you. -- another means to emphasize something already in caps Of course, there are many other such typographical "mannerisms" in common use. All of them share one thing in common: they are all attempts to force the written medium to carry more information than would result without their use in the same message. Some time ago, during the more flaming discussions of MSGGROUP, there were several instances where tempers seemed to have flared completely as a result of "misunderstood" emphasis and meaning. It is damned hard to properly express sarcasm in some written messages, for example. Perhaps we should address ourselves more formally to the issues involved with such ad hoc mannerisms, at least to the point of some general guidelines so that problems such as all caps will not necessarily be a serious detriment to information flow. I am definitely not suggesting "STANDARDS FOR INFORMAL COMMUNICATIONS VIA NETMAIL". Rather I am suggesting that we not let this issue slide by without some semi-serious consideration by the group. --Lauren-- ------- 22-SEP-79 11:37:33-PDT,620;000000000001 Mail-from: MIT-ML rcvd at 16-Sep-79 0959-PDT Date: 16 September 1979 1247-EDT From: Brian.Reid at CMU-10A (C410BR10) Subject: MSGGROUP#1266 Re: all caps To: lauren at UCLA-Security (Lauren Weinstein) CC: DCC at MC, Msggroup at ml Message-ID: <16Sep79 124732 BR10@CMU-10A> In-Reply-To: Lauren Weinstein's message of 15 Sep 79 20:13-EST Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 As a matter of fact, I got it wrong; I said "12% decrease in reading time" but I should have said "12% decrease in reading speed." all caps is harder to read. 22-SEP-79 11:37:33-PDT,1061;000000000001 Mail-from: MIT-ML rcvd at 16-Sep-79 1205-PDT Date: 16 Sep 1979 1138-PDT (Sunday) From: lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1267 Re: all caps In-reply-to: Your message of Sunday, 16 September 1979 1247-EDT To: Brian.Reid at CMU-10A CC: dcc at mc,msggroup at ml Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I suspect there is alot more to this "all caps" speed business than meets the eye. I guess a more useful question might be: "What is the optimal format of written material for maximal speed of reading and/or maximum accuracy of reading?" I did some Teleprompter work years ago in a broadcasting environment and definitely found that all caps read faster when the lines were scrolling by me at a fixed speed (I found this out when some jerk accidently produced an upper/lower case prompting scroll one day and really caused a mess.) I guess it depends largely on a complex of factors, of which capitalization is only one. --Lauren-- ------- 22-SEP-79 11:37:33-PDT,633;000000000001 Mail-from: MIT-ML rcvd at 16-Sep-79 1502-PDT Date: 16 September 1979 1517-EDT From: Brian.Reid at CMU-10A (C410BR10) Subject: MSGGROUP#1268 Re: all caps To: lauren at UCLA-Security (Lauren Weinstein) CC: dcc at mc, msggroup at ml Message-ID: <16Sep79 151716 BR10@CMU-10A> In-Reply-To: Lauren Weinstein's message of 16 Sep 79 13:38-EST Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I'm sure the UCLA library will have all three of the books that I mentioned in my note last week. They explain the complex of factors, of which capitalization is only one. 22-SEP-79 11:37:33-PDT,1464;000000000001 Mail-from: MIT-ML rcvd at 16-Sep-79 2227-PDT Date: 16 Sep 1979 2209-PDT (Sunday) From: lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1269 capitalization and misunderstandings? To: Msggroup at ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 It has been brought to my attention that it was possible to interpret my last message concerning "some jerk" who screwed up Teleprompter copy as a shot against those on the upper/lowercase side of this exciting (yawn!) capitalization controversy. This was not the case. In fact, I've definitely lost track of what this whole discussion started out about. Seems to me it had something to do with lines longer than 72 characters or some such ... In any case, as far as I am concerned, there is no controversy. All caps is good for some things. Mixed cases is good for others. Virtually all my own work, messages, etc. is all in mixed case (I haven't used an uppercase only terminal since the old days of model 33 ttys.) I really don't think this is such an big issue -- the overall format questions are much more important. But I'll tell ya' one thing! If you're "on the air" reading copy "cold" (for the first time) and suddenly the text changes from big uppercase letters to (smaller) lowercase copy (with lots more characters per line by the way), it can be very disconcerting! --Lauren-- ------- 22-SEP-79 11:37:33-PDT,1066;000000000001 Mail-from: MIT-ML rcvd at 17-Sep-79 0751-PDT Date: 17 Sep 1979 0717-PDT Sender: WALTERS at SRI-KA Subject: MSGGROUP#1270 Re: capitalization and misunderstandings? From: WALTERS at SRI-KA To: lauren at UCLA-SECURITY Cc: Msggroup at ML Message-ID: <[SRI-KA]17-Sep-79 07:17:41.WALTERS> In-Reply-To: Your message of 16 Sep 1979 2209-PDT (Sunday) Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I HAVE BEEN FOLLOWING THE COMMENTS OF THE MSGGROUP WITH (MIXED) INTEREST SINCE GAINING ACCESS SOME MONTHS AGO. I APPRECIATE THE CANDIDNESS OF THE COMMENTS, AND HAVE GAINED TREMENDOUSLY IN THE PROCESS. THE TIME HAS COME FOR ME TO OFFER AN OBSERVATION. THE CURRENT DIALOG ON "ALL CAPS", AND LAURENS COMMENT ABOUT "(I HAVEN'T USED AN UPPERCASE ONLY TERMINAL SINCE THE OLD DAYS OF MODEL 33 TTYS.)", HAS MADE SENSE, BUT I MUST POINT OUT THAT THERE ARE SOME PEOPLE THAT HAVE ONLY "UPPERCASE ONLY" AND ARE EXTREMELY GLAD TO HAVE IT, BECAUSE IT IS MUCH BETTER THAN " " (NOTHING). BUZ WALTERS 22-SEP-79 11:37:33-PDT,1073;000000000001 Mail-from: MIT-ML rcvd at 17-Sep-79 0940-PDT Date: 17 Sep 1979 0856-PDT Sender: HARMON at USC-ISI Subject: MSGGROUP#1271 Re: capitalization and misunderstandings? From: HARMON at USC-ISI To: lauren at UCLA-SECURITY Cc: Msggroup at ML Message-ID: <[USC-ISI]17-Sep-79 08:56:28.HARMON> In-Reply-To: Your message of 16 Sep 1979 2209-PDT (Sunday) Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Your disconcerting experience with the case change on the teleprompter may have been more the result of the surprise caused by the change than the change from upper case to mixed case itself. If you had been reading only upper case for a long time and thus were expecting only upper case then the element of surprise could have been considerable. This sudden change in mental state would certainly break your concentration. If you were under any time pressure the loss of the concentrated state would cause even greater emotional involvement and further aggravate the situation. Scott 22-SEP-79 11:37:34-PDT,864;000000000001 Mail-from: MIT-ML rcvd at 18-Sep-79 1543-PDT Date: 18 SEP 1979 1453-PDT From: MACKENZIE at USC-ECL Subject: MSGGROUP#1272 CAPS To: msggroup at MIT-ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Perhaps the reason the upper/lower case TelePrompter scroll bothered Lauren was because she had grown accustomed to all caps. Speaking for myself, I find the occassional all upper-case message to be disconcerting, and more difficult to read. I believe this is because I am accustomed to upper and lower case. A co-worker, who uses this terminal for programming, always set's the "upper case only" option when he uses the terminal, not only because of the infrequent difficulties you can experience when using lower case in programming, but because he's "used to it". Kevin ------- 22-SEP-79 11:37:34-PDT,687;000000000001 Mail-from: MIT-ML rcvd at 18-Sep-79 1616-PDT Date: 18 SEP 1979 1546-PDT From: MACKENZIE at USC-ECL Subject: MSGGROUP#1273 Oops! To: msggroup at MIT-ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Uggggggggh! On reading my copy of my last message to the group, I realized that: 1) I used the personal pronoun "she" without knowing whether it is appropriate, and in fact, I think Steff told me it was not. 2) It is a repeat of a response made by someone else in the group, whose response I hadn't seen at the time. I shall now crawl back into my hole and beat myself severely. Sorry! Kevin ------- 22-SEP-79 11:37:34-PDT,804;000000000001 Mail-from: MIT-ML rcvd at 18-Sep-79 1706-PDT Date: 18 Sep 1979 1647-PDT (Tuesday) From: lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1274 Re: Oops! In-reply-to: Your message of 18 SEP 1979 1546-PDT To: MACKENZIE at USC-ECL CC: msggroup at ml Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I hereby publicly accept your apologies. You're right, "SHE" is INCORRECT. In any case, the comments concerning the Teleprompter fiasco make sense to me. It could well have been the disruption from upper-case to mixed-case, rather than the mixed-case itself, that was the real problem. All that I realized at the time was that something had seriously gone wrong and I had to cover for it! --Lauren-- ------- 22-SEP-79 11:37:34-PDT,857;000000000001 Mail-from: MIT-ML rcvd at 18-Sep-79 1847-PDT Date: 18 Sep 1979 1757-PDT From: FYLSTRA at SRI-KL (David Jon Fylstra) Subject: MSGGROUP#1275 upper/lower case, revisited To: msggroup at MIT-ML Cc: fylstra at SRI-KL Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Speaking of reading news copy on the air, did you ever stumble across copy from the UPI wire service that read like 0bell34$3-.34$3 ?? It really comes out of the Model 15 teletype that way. 5-bit Baudot uses two shifts, Figures and Letters, for the interpretation of each 5- bit pattern. Sometimes the shift character (octal 33 or 37) gets garbaged, and subsequent characters are printed in the reverse shift. If uppercase-only text throws you, you should try inverting the above in real-time! Dave ------- 22-SEP-79 11:37:34-PDT,512;000000000001 Mail-from: MIT-ML rcvd at 19-Sep-79 1752-PDT Date: 19 September 1979 2037-EDT From: Brian.Reid at CMU-10A Subject: MSGGROUP#1276 First mail system? To: MsgGroup at ML Message-ID: <19Sep79 203703 BR10@CMU-10A> Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Does anybody know authoritatively which was the very first computer mail system? Which computer? When? Use your own intuition for when to call something a "mail system". Brian 22-SEP-79 11:37:34-PDT,810;000000000001 Mail-from: MIT-ML rcvd at 19-Sep-79 1847-PDT Date: 19 Sep 1979 1807-PDT Sender: GEOFF at SRI-KA Subject: MSGGROUP#1277 Re: First mail system? From: the tty of Geoffrey S. Goodfellow To: Brian.Reid at CMU-10A Cc: MsgGroup at ML Message-ID: <[SRI-KA]19-Sep-79 18:07:39.GEOFF> In-Reply-To: <19Sep79 203703 BR10@CMU-10A> Reply-to: Geoff @ SRI-KA Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Tenex SNDMSG was born aprox. around July of '72 (just for the record) by Tomlinson. Surely TOPS-10 had something before then? I fowarded your msg off to McCarthy, as since he invented TimeSharing, perhaps he might know when the first mail system was born also, and asked him to reply to MSGGROUP@ML if he had any pearls to offer. Geof 22-SEP-79 11:37:34-PDT,634;000000000001 Mail-from: MIT-ML rcvd at 20-Sep-79 0639-PDT Date: 20 September 1979 09:28 edt From: Pogran.CompNet at MIT-Multics Subject: MSGGROUP#1278 Re: First mail system To: Brian.Reid at CMU-10a cc: MsgGroup at MIT-ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Brian, How about the "mail" command on MIT's 7094 CTSS system, from the early sixties? It placed messages sequentially in a file in the user's directory called "MAIL BOX". Ken Pogran Reference: P. A. Crisman, editor, CTSS PROGRAMMER'S GUIDE, second edition, sec. AH.9.05, revised 2/66. 7-OCT-79 22:28:15-PDT,578;000000000001 Mail-from: MIT-ML rcvd at 22-Sep-79 1414-PDT Date: 22 September 1979 1701-edt From: Bob Frankston Subject: MSGGROUP#1279 Re: First mail system? To: Geoff @ SRI-KA Cc: MsgGroup at ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I don't know when the first mail system was setup, but by 1972 the concept was ancient history. I assume that the CTSS mail system was in the 1963-1965 range, though may be earlier than that. Saltzer.CSR at MIT-Multics would know more about it. 7-OCT-79 22:28:15-PDT,437;000000000001 Mail-from: MIT-ML rcvd at 22-Sep-79 1428-PDT Date: 22 September 1979 1705-edt From: Bob Frankston Subject: MSGGROUP#1280 Re: First mail system? To: Geoff @ SRI-KA Cc: MsgGroup at ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 McCarthy invented TimeSharing????????????? Huh? I knew he invented lisp, but never heard the larger claim. 7-OCT-79 22:28:15-PDT,588;000000000001 Mail-from: SUMEX-AIM rcvd at 24-Sep-79 0045-PDT Date: 24 Sep 1979 0034-PDT From: Wiederhold at SUMEX-AIM Subject: MSGGROUP#1281 Re: First mail system? To: Frankston at MIT-MULTICS cc: stefferud at OFFICE-1 Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 In response to your message sent 22 September 1979 1705-edt In many minds LISP is equivalent to timesharing, and there is some validity to that thought since few languages integrate the interactive and the creative processes on computers. Gio ------- 7-OCT-79 22:28:15-PDT,661;000000000001 Mail-from: MIT-ML rcvd at 24-Sep-79 1836-PDT Date: 24 Sep 1979 1420-EDT From: SWG at MIT-XX Subject: MSGGROUP#1282 invention of time-sharing To: Geoff at SRI-KA Cc: Frankston at MIT-MULTICS, MsgGroup at MIT-ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Perhaps you were thinking of McCarthy as an early advocate of time-sharing, as in Project MAC at M.I.T. In fact, McCarthy said in the book "Computers and the world of the future" (1962) that the first paper on time-sharing that he knew of was by Christopher Strachey at the UNESCO conference in Paris in June 1959. ------- 7-OCT-79 22:28:15-PDT,661;000000000001 Mail-from: MIT-ML rcvd at 25-Sep-79 1012-PDT Date: 25 Sep 1979 0941-PDT Sender: FARBER at SRI-KA Subject: MSGGROUP#1283 Re: invention of time-sharing From: FARBER at SRI-KA To: SWG at MIT-XX Cc: Geoff, Frankston at MIT-MULTICS, MsgGroup at MIT-ML Message-ID: <[SRI-KA]25-Sep-79 09:41:15.FARBER> In-Reply-To: Your message of 24 Sep 1979 1420-EDT Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Just to add confusion to the discussion, the Bell Relay Computer in the 40's could run two people swapping them as approriate. Time sharing with a relay machine was indeed very useful. Dave 7-OCT-79 22:28:15-PDT,648;000000000001 Mail-from: MIT-MULTICS rcvd at 26-Sep-79 0924-PDT Date: 25 September 1979 22:26 edt From: Frankston.Frankston at MIT-Multics Subject: MSGGROUP#1284 Re: First mail system? To: Wiederhold at SUMEX-AIM cc: Frankston at MIT-Multics, stefferud at OFFICE-1 In-Reply-To: Msg of 09/24/79 03:34 from Wiederhold Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Both Lisp and Basic started off their lives as batch languages!!!!! Lisp jobs were usually too large to run on CTSS effectively from a termiNal and basic was a card language for the GE 235. Timesharing came to their rescue. 7-OCT-79 22:28:16-PDT,736;000000000001 Mail-from: USC-ECL rcvd at 26-SEP-79 0926-PDT Date: 26 SEP 1979 0926-PDT From: RAHE at USC-ECL Subject: MSGGROUP#1285 TOPS-10 mail systems To: [ECL]MAILING.LIST;204: cc: rahe Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 The University of Delaware Computing Center is attempting to implement ARPA style message systems on the various computer systems it operates. We currently have a good handle on systems for a Unix-running 11/70, and the Buroughs B7700. We would be interested in learning if anyone has or knows of an ms or msg like system that would run on a DEC-10 running TOPS-10 V6.03A. Any help would be greatly appreciated. ------- 7-OCT-79 22:28:16-PDT,2368;000000000001 Mail-from: MIT-ML rcvd at 28-SEP-79 1417-PDT Date: 28 Sep 1979 1358-PDT From: LUKASIK at USC-ISI Subject: MSGGROUP#1286 Available Positions To: MsgGroup at MIT-ML cc: HOLG at USC-ISIB Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Having left the directorship of DARPA in l975 and having been at Xerox and RAND in the interim, I recently assumed the position of Chief Scientist at the Federal Communications Communications Commission in Washington. I am now seeking a few good individuals to work with me.. the first position is that of my deputy and iis a Senior Executive Service position with a salary to 52.8K. The Deputy Chief Scientist/Engineer serves as principal assistant to the Chief Scientist, in directing technical, scientific and engineering activities of the Office. The accepted applicant will be responsible for the development and completion of projects and programs involving research and analysis activities of a scientific, technical and related engineering, mathematical and physical science nature in broad areas of telecommunications. Candidates must be U.S. citizens and have six years of experience which would have demonstrated an extensive background, knowledge and experience in varied areas of telecommunications. The accepted applicant must have experience in meeting and dealing with a diversified segment of government, industry, and the public on national and international levels relative to resolution of problem areas; obtaining support for policy positions, and providing expertise in the area of telecommunications. Masters degreee or equivalent in Engineering or related fields is derived. I am also seeking a few good people with broad interests in the communications area to join a new Technical Planning Staff. This group will be involved with technology assessment and advanced planning in a variety of comunications disciplines from TV broadcasting tocomputer networks. These positions are at the GS13/15 level (salary from 29K to 50K). If you are interested in any of these positions send me a resume or SF171 either by mail to Dr. Stephen Lukasik, FCC/OST, 2025 M St. NW, Washington ,DC 20554 or by SNDMSG to Lukasik at ISI. for further information you may also call Mike Marcus at (202) 632-7060. ------- 7-OCT-79 22:28:16-PDT,1814;000000000001 Mail-from: MIT-ML rcvd at 28-SEP-79 2219-PDT Date: 29 Sep 1979 0101-EDT From: OFI at BBN-TENEXA Subject: MSGGROUP#1287 And let your Demon do the walking To: msggroup at MIT-ML cc: ofi at BBNA Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Has anyone written a program to deal with undeliverable messages by checking the addresses against a "master directory" or "white pages" to identify the possible addresses which the sender might use in place of the one that "failed"? Of course, such a program should allow the author to review and approve substitute addresses, since automatic forwarding to addresses selected out of a directory would be unacceptably risky (to most serious users -- though perhaps not to some junk- mailers.) One possibility would be to process undelivered messages with a demon program in background mode. The demon could search for possible valid replacements for the misnomer and send these back to the author in a message. I find the current message regarding undeliverable mail very unhelpful since it doesn't facilitate my doing anything constructive. I would like to see a capability such as the "BBN spell" procedure for proposing and selecting "corrected spellings of words." With "foreign networks" (relax ARPA, I mean Telenet and Tymnet, etc.) now interfacing with ARPANET, such a program might also be useful in translating addresses from one network protocol standard to another. Who wants to design one of these? What would the basic features be? Perhaps more importantly, what are the social, political and organizational issues raised by such a (perhaps too appropriately named) "demon"? Jim Carlisle ------- 7-OCT-79 22:28:16-PDT,1687;000000000001 Mail-from: MIT-ML rcvd at 28-SEP-79 2311-PDT Date: 28 Sep 1979 2255-PDT From: Mark Crispin Subject: MSGGROUP#1288 let your demon do the walking To: MsgGroup at MIT-ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I think the whole way Tenex does mail delivery from beginning to end is unfortunate. Tops-20 local mail (a.k.a. "IPCF mail"), ITS COMSAT, and WAITS mail have been steps in the right direction, but all have rather serious design flaws in one aspect or another. A nice idea would be to have something like a "mail system database server", maintained by the NIC, that would supply information about known network users to interested mail daemons. For example, suppose somebody thinks, "I want to send a message to Mark Crispin - he's at SRI I think - let's try CRISPIN@SRI". Well, I'm not at SRI, I'm at Stanford. The mailer could say "well, couldn't find Crispin at SRI, what does the database say?" and the database could say yes, I know of a Mark Crispin, network address Admin.MRC@SU-SCORE, with alternate addresses ....." [The reason for the alternate addresses are for the "you can't get there from here" problem with multi- networking.] The daemon could then tell the user, "I couldn't find CRISPIN@SRI, but if you wanted Mark Crispin try Admin.MRC@SU-SCORE". You don't want it automatically sending it without asking the user first, but at least the bother of doing the lookup has been done. This service could (and should) be offered from several different hosts, using a database updated from a single source. It can work! Mark ------- 7-OCT-79 22:28:16-PDT,1019;000000000001 Mail-from: MIT-ML rcvd at 28-SEP-79 2328-PDT Date: 29 Sep 1979 0212-EDT Saturday From: Brian.Reid at CMU-10A Subject: MSGGROUP#1289 Re: let your demon do the walking To: Mark Crispin CC: MsgGroup at MIT-ML Message-ID: <29Sep79 021212 BR10@CMU-10A> In-Reply-To: Mark Crispin's message of 29 Sep 79 00:55-EST Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Ah, but suppose that you are trying to reach a Cohen at CMU. We have Ellis Cohen, Eve Cohen, Don Cohen, Ernest Cohen, Fred Cohen, and probably more by now. What would you want this smart server to do with mail to "Cohen@CMUA" ? Is "Jon Rosenberg" the same person as "John Rosenberg" (until recently at CMU; yes, but now we have both a "Jon" and a "John".) I think a higher degree of interactiveness is necessary to get questions like this right, and it is often difficult to tell whether it is ok to go ahead and send the mail even if it might not be right. 7-OCT-79 22:28:16-PDT,870;000000000001 Mail-from: MIT-ML rcvd at 28-SEP-79 2344-PDT Date: 28 Sep 1979 2326-PDT From: Mark Crispin Subject: MSGGROUP#1290 Re: let your demon do the walking To: Brian.Reid at CMU-10A cc: MsgGroup at MIT-ML In-Reply-To: Your message of 28-Sep-79 2314-PDT Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Well, it can do several things: . It can barf completely, as most mailers do. . It can list out the multiple Cohens, and ask me to choose. . It can send to all the Cohens, as MIT does. . It can put it in a dead-letter box, and have an operator figure out who it should go to. I personally like the last solution, as it is also good for misspelled names - suppose it went to Cohan at CMU? Humans are better at this sort of thing than computers are. mark ------- 7-OCT-79 22:28:16-PDT,731;000000000001 Mail-from: MIT-ML rcvd at 29-SEP-79 0107-PDT Date: 29 Sep 1979 0041-PDT (Saturday) From: lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1291 Re: let your demon do the walking In-reply-to: Your message of 28 Sep 1979 2326-PDT To: Admin.MRC at SU-SCORE CC: MsgGroup at ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I agree fully that unclear situations should be cleared by an operator of some sort -- a human at any rate. I clearly remember the mass of mail that got forwarded from MIT to my local UCLA mailbox when another Weinstein appeared on the system. Forwarding to all is clearly NOT the right solution! --Lauren-- ------- 7-OCT-79 22:28:16-PDT,1476;000000000001 Mail-from: USC-ISI rcvd at 30-Sep-79 2254-PDT Mail-from: MIT-MC rcvd at 29-Sep-79 1411-PDT Date: 29 SEP 1979 1714-EDT From: SIRBU at MIT-MC (Marvin A. Sirbu, Jr.) Subject: MSGGROUP#1292 Standards To: DCROCKER@RAND at MIT-MC, Stefferud at USC-ISI CC: SIRBU at MIT-MC Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I'm trying to find out what the current state of the art is in the development of national/international (as opposed to ARPANET) standards for electronic mail systems, including both communicating word processors and computer based message systems. There are now commercial electronic mail systems -- advertising themselves as such -- operating for the general public via COMET, ONTYME, MAILBOX (Scientific Timesharing), HERMES, AUGMENT, and "The Source" from TCA. To my knowledge, only Hermes, Augment and Comet come close to meeting RFC 733 type standards. In addition, there are many companies experimenting with in-house systems. The possiblity exists, that, unless a standard is agreed upon realtively soon, it may be difficult to get all these different groups to convert. The second problem, that of communicating word processors is obviously even more difficult. I have heard rumors of an ANSI group working on the problem, but I don't have any details. I'd appreciate any help you could give me in finding out what's going on in these two areas. Marvin 7-OCT-79 22:28:16-PDT,649;000000000001 Mail-from: MIT-ML rcvd at 30-Sep-79 2303-PDT Date: 30 September 1979 1508-EDT (Sunday) From: Richard H. Gumpertz Subject: MSGGROUP#1293 Re: And let your Demon do the walking To: OFI at BBN-TENEXA CC: msggroup at MIT-ML Message-ID: <30Sep79 150852 RG02@CMU-10A> In-Reply-To: OFI's message of 29 Sep 79 00:01-EST Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Daemon is spelled with AE, not E, in the middle. With just an E, the implication is for an evil type character; with the AE, it is a minor deity that does nice things for people. Rick 7-OCT-79 22:28:16-PDT,582;000000000001 Mail-from: MIT-MC rcvd at 30-Sep-79 2328-PDT Date: 30 Sep 1979 16:05-EDT From: Robert W. Kerns Subject: MSGGROUP#1294 And let your Demon do the walking To: MSGGROUP at MIT-MC Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I dunno, it seems that Demon is really apropriate. You have to perform the apropriate magical rites to bind it to your service, and even then it's looking for a way to screw you. Maybe when it's been thouroughly domesticated a Demon undergoes a metamorphosis to Daemon? 7-OCT-79 22:28:16-PDT,1259;000000000001 Mail-from: MIT-ML rcvd at 2-Oct-79 0329-PDT Date: 1 Oct 1979 02:15-EDT From: Richard M. Stallman Subject: MSGGROUP#1295 Ambiguous letters and operators To: MSGGROUP at MIT-AI Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Having operators sort out ambiguous mail addresses is fine but it uses up human effort that not all sites have available. Here, failing mail is looked at that way, but only at long intervals by the mail maintainers. It would be a real loss for ambiguous mail to suffer such delays, because ambiguous mail can happen through no fault of the sender when a new user appears and makes a previously unambiguous address lose. There would be no delay if the sender were told of the problem and asked to re-send (as happens for failing mail), but if the dead letter box doesn't get examined for a couple of weeks this reduces to the option of just asking the sender to pick one. For a system which can't provide operators to dispatch ambiguous mail promptly, I think that it is better to deliver to everyone and notify the sender (which MIT doesn't do, now) than to put in the dead letter box to be seen weeks later and notify the sender. 7-OCT-79 22:28:16-PDT,720;000000000001 Mail-from: MIT-ML rcvd at 2-Oct-79 0330-PDT Date: 1 Oct 1979 1753-EDT Sender: DDEUTSCH at BBN-TENEXA Subject: MSGGROUP#1296 Discussion of directory daemons (or demons?) From: DDEUTSCH at BBN-TENEXA To: MSGGROUP at MIT-ML Cc: KLH at SRI-KL, Feinler at SRI-KL, Postel at ISIB, Mooers, DDeutsch Message-ID: <[BBN-TENEXA] 1-Oct-79 17:53:25.DDEUTSCH> Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I like the idea of supporting addressing through some kind of directory service so much that I wrote an RFC (757) about it! Jon Postel has assured me that it will be announced sometime in the near future. This discussion is interesting... Debbie 7-OCT-79 22:28:16-PDT,508;000000000001 Mail-from: MIT-ML rcvd at 2-Oct-79 0328-PDT Date: 1 OCT 1979 1553-PDT From: POSTEL at USC-ISIB Subject: MSGGROUP#1297 Re: let your demon do the walking To: Mark Crispin try the program WHOIS available from Jake Feinler. --jon. ------- 7-OCT-79 22:28:16-PDT,1165;000000000001 Mail-from: MIT-ML rcvd at 2-Oct-79 0457-PDT Date: 2 OCT 1979 0748-EDT From: SIRBU at MIT-MC (Marvin A. Sirbu, Jr.) Subject: MSGGROUP#1298 Time stamps To: Msggroup at MIT-ML CC: Verplank at PARC-MAXC Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I recently received the following message which seems worth passing along ---------------------------- Some subtle things start happening with time-stamped messages. My boss' boss' boss complains of the ravings of the late-nighters; he can tell from the time stamp (and the sender's habits) how seriously to take the message. Some people use it blatently as a kind of one-up's-manship: "I work logner hours than you do". Some would like to remove the time stamp. Others want the ability to delay sending messages until a prescribed time: arbitrary time-stamps, (or even pre-dating?) ----------------- Question: must we time stamp messages with the actual time they are posted? What problems would be caused by the following possibilities? 1. delay sending 2. arbitrary time-stamp 3. no time stamp Marvin 7-OCT-79 22:28:17-PDT,1379;000000000001 Mail-from: MIT-ML rcvd at 2-Oct-79 0533-PDT Date: 2 Oct 1979 0522-PDT From: Zellich at OFFICE-1 Subject: MSGGROUP#1299 Re: Time stamps To: SIRBU at MIT-MC, Msggroup at MIT-ML cc: Verplank at PARC-MAXC, ZELLICH Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 In response to the message sent 2 OCT 1979 0748-EDT from SIRBU@MIT-MC Frankly, I really like seeing an accurate time-stamp. With the volume of non-real-time conferencing going up all the time, and the idiosyncrasies and problems of various mailers around the net, it's nice to be able to unravel the sequence of comments received in scrambled order. I understand the comments about late-nighters, although I sometimes are one...but if somebody thinks s/he can use the time stamp for added informational value, why take that information away? Interaction between humans is complex and difficult enough to understand when conducted only in writing - let's not arbitrarily eliminate any non-verbal clues just because someone occasionally misunderstands them (or understands them, as the case may be). It shouldn't be too hard, anyway, for a large number of us to get our messages sent any time we want to - and are those with the less sophisticated systems likely to get time-stamp changes made, anyway? Cheers, Rich ------- 7-OCT-79 22:28:17-PDT,2361;000000000001 Mail-from: MIT-ML rcvd at 2-Oct-79 0742-PDT Date: 2 OCT 1979 0848-EDT From: FFM at MIT-MC (Steve Kudlak) Subject: MSGGROUP#1300 Time stamps To: SIRBU at MIT-MC CC: msggroup at MIT-ML, verplank at PARC-MAXC Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I tend to ignore things like time stamps except in certain conditions where I have my attention called to it. For example if I am on line at night, as usual and I get a message from a daytimer I will wonder what he or she is doing up at my hours and if I should approach that person physically i'll usually inquire after their mood etc. OF course I tend to ignore lots of things like that and concentrate on the contents which I have been told is the important part of messages and tend to agree, the rest being helps and prettiness. For example if one gets a dull message at 9am about the mumble-frotz-foo on the ods-bodkins system in perferct english and speeling that might not be as interesting as message at 2:30am about something were interested in. Many places already have facilities that allow you to have messages sent at any time you want to have them sent. CMU has this and so does SAIL. So there is one way or another at various places a de facto arbitrary 'time stamp'. This is perhaps a winning way to deal with those people who think a mornie is only way to be or those who think only pearls of wisdom come after midnight and before 7am. Certainly looking at a time stamp to tell how to take a message is mostly a ridiculous idea, sometime it could be valuable, I contend one could tell a bit more about people smetime with such info but not really that much. I mean perhaps we should time stamp with the phase of the moon in addition to date and time. Having no timestamp might confuse or bother some mail handlers. It might be cute but might be pretty useless for messages where you wanted to get hold of someone and wanted to know if they left a hour ago, 3 hours ago, 3 days ago etc. Basically I think people should have as many options as they want without seriously screwing over other people. A send the mail at any time or a pick the timestamp migh be cute. 791002 084823 FFM FFM;MC:FFM OMAIL TUESDAY OCT 02,1979 215 FQ+3D.21H.43M.46S. Have fun Sends Steve