5-Apr-79 14:08:15-PST,7579;000000000001 Mail-from: USC-ISI rcvd at 8-MAR-79 1817-PST Date: 8 MAR 1979 1817-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 901 SURVEY [ISI]PROCEEDINGS.MSG#851-#900 From: STEFFERUD at USC-ISI To: [ISI]Mailing.List;183: Message-ID: <[USC-ISI] 8-MAR-79 18:17:12.STEFFERUD> Redistributed-To: Walters at SRI-KA, Foster at SRI-KL Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 31 Mar 1979 -- Messages from file: [USC-ISI]PROCEEDINGS.MSG#851-#900;1 -- THURSDAY, MARCH 8, 1979 17:55:12-PST -- 50 8 Mar Karlton at PARC-MAXC MSGGROUP# 900 White space in toke (3622 chrs) 49 8 Mar the tty of Geoffrey S MSGGROUP# 899 Re: Horrible Erroneous Reply-program ... (931 chrs) 48 8 Mar Mark Crispin Mai MSGGROUP# 880 [isi]FING ER.MSG#794-#NNN & ...PRT#794-#NNN (821 chrs) 29 5 MAR To:RMS at MIT-AI MSGGROUP# 879 RMS on why bother? (1180 chrs) 28 5 MAR RMS at MIT-AI (Richar MSGGROUP# 878 Let's go without subjects till someone fixes all our (1464 chrs) 27 5 Mar the tty of Geoffrey S MSGGROUP# 877 Re: [MIT-MC]CBF;MSG LOG - ETC. (1112 chrs) 26 5 MAR To:CBF at MIT-ML MSGGROUP# 876 Re: [MIT-MC]CBF;MSG LOG - ETC. (1915 chrs) 25 3 Mar Mike Royko MSGGROUP# 875 Levity, on the lighter side of mail delivery with the (5599 chrs) 24 2 Mar the tty of Geoffrey S MSGGROUP# 874 Re: No flames; technical question (809 chrs) 23 2 MAR WEISSMAN at I4B-TENEX MSGGROUP# 873 No flames; technical question (507 chrs) 22 1 Mar Frankston.Frankston a MSGGROUP# 872 Shame on you (1111 chrs) 21 28 Feb david at UTEXAS MSGGROUP# 871 Simple FINGER Limit (1351 chrs) 20 28 Feb Sweer at SUMEX-AIM MSGGROUP# 870 clarification of my suggestion (1506 chrs) 19 28 Feb Frankston.Frankston a MSGGROUP# 869 Form (as opposed to content) (1567 chrs) 18 27 Feb Gaines at Rand-Unix MSGGROUP# 868 the finger discussi (4890 chrs) 17 Wednes Bruce Leverett at CMU MSGGROUP# 867 "Take your business to TYMSHARE" (3679 chrs) 16 Tuesda BZM Mai MSGGROUP# 851 SURVEY OF [ISI]PROCEEDINGS.MSG#801 -#850;1 (7280 chrs) 5-Apr-79 14:08:16-PST,410;000000000001 Mail-from: MIT-ML rcvd at 8-MAR-79 1657-PST Date: 8 March 1979 19:14-EST From: Richard M. Stallman Subject: MSGGROUP# 902 Helping others fix HERMES To: msggroup at MIT-ML I think that BBN owes us a statement of whether they will co-operate with other people who wish to fix bugs in HERMES that BBN is not willing to fix. Can ARPA "order" them to try to negotiate in good faith? 5-Apr-79 14:08:16-PST,562;000000000000 MAIL-FROM: MIT-ML rcvd at 8-MAR-79 2102-PST Date: 8 Mar 1979 1958-PST Sender: GEOFF at SRI-KA Subject: MSGGROUP# 903 Re: White space in tokens From: the tty of Geoffrey S. Goodfellow To: Karlton at PARC-MAXC Cc: Header-People at MC, MsgGroup at ML, Everhart at CMUA, Cc: Lamb at CMUA, Sapsford at XEROX-PARC Message-ID: <[SRI-KA] 8-Mar-79 19:58:18.GEOFF> In-Reply-To: Your message of 8 Mar 1979 2:18 pm (Thursday) Reply-to: Geoff @ SRI-KA Re: "What has happenned to pride of craftsmanship?" Apparently it ran out the same time funding did. 5-Apr-79 14:08:16-PST,717;000000000000 MAIL-FROM: MIT-ML rcvd at 8-MAR-79 2146-PST Date: Thu, 8 Mar 79 21:35-PST Subject: MSGGROUP# 904 Re: Horrible Erroneous Reply-program ... Subject: Making Everyone Squirm From: Greep at Rand-Unix To: Geoff at Sri-Ka cc: msggroup at Mit-Ml Message-ID: In-Reply-To: Your message of 8 Mar <[SRI-KA] 8-Mar-79 10:42:03.GEOFF> Did the government pay for the development of Hermes? If so, can BBN legitimately protect it? Sounds like somebody should send a message to the authors of Hermes (if anyone actually knows who they are) and just ask them why they don't fix it, instead of all this conversation about "why doesn't anyone from BBN comment", etc. 5-Apr-79 14:08:17-PST,1578;000000000000 MAIL-FROM: MIT-ML rcvd at 9-MAR-79 0417-PST Date: 8 Mar 1979 2309-PST Sender: GEOFF at SRI-KA Subject: MSGGROUP# 905 Re: Horrible Erroneous Reply-program ... Subject: Making Everyone Squirm From: the tty of Geoffrey S. Goodfellow To: Greep at RAND-UNIX Cc: msggroup at MIT-ML Message-ID: <[SRI-KA] 8-Mar-79 23:09:06.GEOFF> In-Reply-To: Reply-to: Geoff @ SRI-KA The development of HERMES was done (as i understand it) in some quasi-nebulous way with the government and BBN so that I think BBN has it as a product or some such, but I am not sure since I have never heard a policy statement from ANYONE as to just what rights BBN has or doesn't have over HERMES. Needless to say: We'd all love to hear such a statement . In case you (and others aren't aware) two important HERMES people are on the msggroup list and have (silently) just watched (or perhaps just deleted without reading) all stuff sent to msggroup. In particular, Mooers@bbna is the user-Liaison (as I understand it), and Myer@bbna is (was?) the project leader. There are others such as Doug Dodds, DDeutsch, etc. who do the programming. I'd indeed say: "why doesn't anyone from BBN (or ARPA) comment". But as I said before, perhaps their not funded to. **Please note that these "understandings" are made up of bits and pieces of info collected ever since I'v heard of HERMES, and could be in gross error, but since I have never heard differently, since this is what I'v heard thru the grape-vine, this is what I know. ** 5-Apr-79 14:08:17-PST,404;000000000000 MAIL-FROM: MIT-ML rcvd at 9-MAR-79 0418-PST Date: 8 Mar 1979 2344-PST From: Steven Tepper Subject: MSGGROUP# 906 Use of unmaintained software To: Geoff at SRI-KA CC: MsgGroup at MIT-MC If BBN cannot (or will not) reasonably maintain Hermes and will not permit anyone else to do so, prudence would seem to dictate caution before committing oneself to using it. 5-Apr-79 14:08:17-PST,641;000000000000 MAIL-FROM: MIT-ML rcvd at 9-MAR-79 0419-PST Date: 9 Mar 1979 0042-PST From: Steven Tepper Subject: MSGGROUP# 907 Keeping Hermes happy To: MsgGroup at MIT-ML Maybe someone can write a preprocessor for Hermes that will turn the headers into a form that it will accept (and hopefully also the originating system would accept in case of a reply). That way no other changes would have to be made, and it should be possible to do this without touching Hermes - the preprocessor could be named Hermes so that users would automatically get it, and it would call the real Hermes after munging the mailbox. 5-Apr-79 14:08:17-PST,1049;000000000001 Date: 11 Mar 1979 1051-PST Subject: MSGGROUP# 908 Flames + emotion From: PBARAN To: msggroup Cc: pbaran Redistributed-To: MSGGROUP at ML Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 12 Mar 1979 The high emotional content of recent MSG GROUP exchanges on FINGER and name field white space I believe to be very good. These are not matters for dispassionate rationality. If some computer systems treat me like a schmuck or a fool or a thing I have every right to be outraged at the managers and designers of such systems. Make no mistake - what our 'toy' systems do to us today is going to happen to a hell of a lot of people tomorrow. In the computer game there is a distressing tendency for an informal set of operating procedures to become a de facto standard through rapid diffusion. And the wider the diffusion the more difficult even desirable change becomes. So flame on. Let's get it all out in the open where (and while) there is some hope of resolution. Dave Caulkins 5-Apr-79 14:08:17-PST,5476;000000000001 Mail-from: PARC-MAXC rcvd at 14-Mar-79 1609-PST Date: 14 Mar 1979 4:01 pm (Wednesday) From: Karlton at PARC-MAXC Subject: MSGGROUP# 909 Further comments on no LWS request to CMU To: MsgGroup at USC-ISI, Header-People at MIT-MC cc: Craig Everhart at CMU-10A Redistributed-To: msggroup at MC Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 14 Mar 1979 I must be getting old. I decided to wait a week and calm down before mailing my second letter about the request to CMU to prevent having linear white space in recipient names. First I think you should see what the hackers at CMU proposed to do. I have taken the liberty to edit some comments from the following message. ------------------------------------------------------------ Date: Thursday, 8 Mar 1979 1936-EST From: Craig Everhart at CMU-10A Subject: Re: White space in tokens To: Karlton at PARC-MAXC Message-ID: <08Mar79 193622 CE10@CMU-10A> In-Reply-To: Karlton's message of 8 Mar 79 14:18 [...] Allow me to describe the planned method of handling the request. Basically, we don't restrict RDMAIL in ANY way from its current state. However, [...] we're taking the following tack. There shall be a distinguished version of RDMAIL, which will be the first version that will attempt to comply with the request. When RDMAIL is invoked, and it sees that it is incrementing the last-RDMAIL- version-used-on-this- file number over this distinguished number, it will clear out the user's name stored in the .MSG file. Then, for both this kind of cleared name, and the kind that you get because you're creating a .MSG file, the user name will be generated as "Philip.Karlton" and stored into the .MSG file as such. (This will overwrite, for instance, "Mary Shaw", "JON BENTLEY", and "Brian K. Reid".) When it does this, it will tell you so, in a warning message, probably. In any case, the user is then perfectly free to change his/her name BACK to whatever he/she pleases; the point here is to catch those people who have never done the PROFILE command as well as those who do it every week. ALIAS and FROM will be left untouched. [... paragraph deleted... PK]. Along with these program changes, we'll have to (once more!) stress that there are [...] mail readers on the network, and that if a user generates fancy headers (and they'll have to do this, explicitly, after this RDMAIL comes up, [...]), then they take the responsibility for the difficulty their correspondents will have in using the [...] replying systems. [... four more paragraphs deleted ... PK] Craig ------------------------------------------------------------ First I would like to point out that this solution will not work. The trouble is that just changing the senders name to not contain LWS is insufficient. All the names in the recipient lists must also be coerced to not contain LWS. Letting a CMU header (excuse the expression) out onto the net would be considered as ill mannered as letting an ITS header out. This could be done by changing the names that contain LWS and have a destination site of CMUxxx. (What should be done for names with LWS that are not going to CMU?) This will annoy the user who types a carefully considered list of names only to have the format changed by the program to one that is acceptable by the outside network when the user knows that the original is acceptable to the local mail handling program.. The following represents my best guess, and might be far from the truth. What happened is that some administrator came up to CMU's operations manager at a meeting someplace and asked that CMU stop sending out those "funny" headers that had LWS in the names. Agreeing to do this probably did not seem like much of an imposition since CMU accepted "First.Last" in place of "First Last" anyway. Not much thought was given to what was actually being asked or to what the implementation details would be. The crux of the entire matter, to me at least, is whether or not RFC733 is a network standard. If it is not a standard, then an explanation is due to many people and an apology to those that actually produced 733. If it is a standard, then the request to CMU to remove LWS was completely out of order. If 733 is to be replaced, then it should be replaced and a new standard should be issued. Vague wishes like "Make your program generate stuff my program can understand." make it impossible for the implementor. I have already had the misfortune of producing software to a floating goal and found that an extremely frustrating experience for both me and the client. If what HERMES will parse is to become the standard for network mail then a specification of that should be published. Does HERMES handle Reply-To: fields? Names in <>'s? Sender: fields? It does not seem reasonable for CMU to go in and fix up the sender names not to have LWS just to have someone complain that CMU is still sending bogus headers. If what happened is that BBN was asked to write a program for money (which is not a dishonorable thing to do as some have implied) and were told to just ignore the header controversy, then they should not be surprised that tempers flare when people get told that their work (and generating 733 was real work) was wasted and that no one (important) was going to pay attention anyway. PK 5-Apr-79 14:08:18-PST,756;000000000001 Mail-from: PARC-MAXC rcvd at 15-Mar-79 1057-PST Date: 15 Mar 1979 10:55 am (Thursday) From: Karlton at PARC-MAXC Subject: MSGGROUP# 910 Disclaimer To: MsgGroup at USC-ISI, Header-People at MIT-MC Redistributed-To: MSGGROUP at MC Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 15 Mar 1979 Due to a misunderstanding that was brought to my attention I feel the following is in order. The opinions I expressed yesterday are my own and not that of any organization. I am an ex-member of the CMU community and am not in daily contact with them and my thoughts should not be interpreted as coming officially from CMU or representing the thoughts of the students as a whole or any other CMU group. PK 5-Apr-79 14:08:18-PST,8051;000000000001 Mail-from: CMU-10A rcvd at 16-Mar-79 1233-PST Date: Friday, 16 Mar 1979 1528-EST From: Brian.K..Reid Subject: MSGGROUP# 911 certification of computer professionals To: MsgGroup at USC-ISI, Header-People at MIT-MC Message-ID: <16Mar79 152808 BR10@CMU-10A> Redistributed-To: MSGGROUP at ML Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 16 Mar 1979 Now that the flaming about the certification of computer professionals has pretty much died down (though such certification is still being considered, of course) I offer these two news stories from today's AP wire, with no further comment. a023 0026 16 Mar 79 PM-Topic, Advisory, Managing Editors: Wire Editors: It all started in a tiny part of a computer program used by an engineering firm designing nuclear reactors. It ended with the shutdown of five nuclear power plants at a time when President Carter is pushing oil conservation and the world oil market is in turmoil. The computer miscalculated some safety precautions required by law. The power from the closed plants now will have to be replaced by electicity generated with oil or coal. This may cost utility customers money and throw a curve at Carter's conservation program. In Today's Topic: The Little Computer and the Big Problem, AP writer Evans Witt traces this glitch in the system, from the obscure computer to its possible effect on the nation's energy problems. The story, illustrated by Laserphoto NY7, is upcoming next. The AP ap-ny-03-16 0328EST *************** a024 0044 16 Mar 79 PM-Topic-Glitch, Bjt,950 TODAY'S TOPIC: The . yyter and the Big Problem Laserphoto NY7 By EVANS WITT Associated Press Writer WASHINGTON (AP) - Something just didn't add up. And the result is: five nuclear power plants are shut down; millions of Americans may pay higher utility bills; and a sizable blow may have been struck to President Carter's efforts to reduce the use of imported oil and to control inflation. The immediate source of all this is part of the federal bureaucracy - the Nuclear Regulatory Commission which ordered the shutdowns. But in one sense, the ultimate culprit was ''Shock II,'' a tiny part of a computer program used by a private firm to design the power plants' reactors. Shock II was wrong and that means parts of the five reactors might not survive a massive earthquake. Shock II was the weak link that could have allowed the chain to snap. In between Shock II and the shutdowns were a public utility, a private engineering firm and the NRC staff. It was really the judgments of the dozens of scientists and engineers, not elected or appointed officials, that led to the shutdowns. Perhaps as a result, the decision's impact on the nation's energy situation was not even considered until the very last moment - when the commission itself was faced with the final decision. And at that point, the NRC said, it had no choice. It said the law was clear: serious questions about the reactors had been raised and the reactors had to be turned off until answers were found. The specific questions are arcane engineering issues, but the explanation is straightfoward: Will some of the systems designed to protect the reactor survive an earthquake - or will they fail, and possibly allow radioactive death to spew into the air? The regulations say the reactors must be able to withstand a quake equal to the strongest ever recorded in their area. The regulations don't allow any consideration of the likelihood of a major quake. All four states where the reactors are located - New York, Pennsylvania, Maine and Virginia - have had minor quakes in this decade and damaging quakes at least once in this century. The only way to test them - short of having a massive earthquake - is to test a model of the reactor. The ''model'' is actually a set of mathematical formulas in a computer that reflect how the reactor and its parts will behave in a quake. The model used for the five reactors came from Stone and Webster, the large Boston engineering and architectural firm that designed the plants. The Stone and Webster model indicated how strong and well supported pipes had to be and how strong valves had to be. The problem apparently cropped up after Stone and Webster suggested within the last few months more pipe supports in the secondary cooling system of the reactor at Shippingport, Pa., operated by Duquesne Light Co. in Pittsburgh. But why were the supports needed? ''This was not clear to us, looking at the calculations done by the models,'' said Gilbert W. Moore, Duquesne's general superintendent of power stations. So Dusquesne - and Stone and Webster - sent the computer models through their paces again, having them calculate and recalculate what would happen to the pipes in an earthquake. ''We came out with some numbers which were not in the range we would like,'' Moore said. That made the problem clear - the model now said the pipes might break in an earthquake. The previous analysis indicated an adequate safety margin in the pipes, and Stone and Webster's explanation was: ''One subroutine may not give uniformly conservative results.'' The problem was in a ''subroutine,'' a small part of the computer model, called ''Shock II,'' said Victor Stello, director of NRC's division of reactor operations. ''The facts were that the computer code they were using was in error,'' said Stello. ''Some of the computer runs were showing things are okay. In some cases, the piping systems were not okay. ''We didn't know the magnitude of the error or how many plants might be affected,'' he said. It was on March 1 that Duquesne told the NRC of the problem by telephone and asked for a meeting to discuss it. The same day, Energy Secretary James R. Schlesinger was telling Congress that unleaded gas might cost $1 a gallon within a year and service stations might be ordered shut down on Sundays because of oil shortages. The meeting took place on Thursday, March 8, in Washington with NRC staff, Stone and Webster engineers and Duquesne Light people on hand. Through the weekend, Stello said, engineers from NRC, Duquesne and Stone and Webster worked at the private firm's Boston office, analyzing the severity of the problem. ''By the middle of Sunday (March 10) we begin to get a pretty good idea of what it meant for the systems,'' Stello said. ''Monday, we got the latest information from our people at the Stone and Webster offices. It became clear that there would be a number of the safety systems that would have stresses in excess of allowable limits. The magnitude of the excess was considerable.'' Tuesday, members of the NRC were briefed by their staff of engineers and scientists. They asked for an analysis of the economic impact of the decision, and then ordered the plants closed within 48 hours. And the five reactors shut down: Duquesne Light Co.'s Beaver Valley plant at Shippingport, Pa.; Maine Yankee in Wiscasset, Maine; the Power Authority of New York's James Fitzpatrick plant at Scriba, N.Y.; and two Virginia and Electric Power Co. reactors at Surry, Va. It may take months to finish the analysis of the potential problems and even longer to make changes to take care of the situation. Until the reactors start generating again, the utilities will have to turn to plants using oil or coal. This may cost more, and that cost may be borne by the millions of utility customers. To replace the power from these nuclear plants could require 100,000 barrels of oil a day or more. And this at a time when President Carter has promised to cut U.S. oil consumption by 5 percent - about 1 million barrels a day - and when the world's oil markets are in turmoil because of recent upheavals in Iran. ap-ny-03-16 0346EST *************** 5-Apr-79 14:08:18-PST,1114;000000000001 Mail-from: UCLA-SECURITY rcvd at 16-Mar-79 1555-PST Date: 16 Mar 1979 1549-PST From: lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP# 912 AP stories/certification (no flames!) To: MSGGROUP at ISI Redistributed-To: MSGGROUP at ML Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 16 Mar 1979 Well, I DO have a comment. Certification does not, will not, and cannot, provide verificiation of the accuracy of computer programs. I would wager that in a fully certified CS community, there would be just as many "bugs" in programs as a non-certified community. One thing that certification might do, however, is lull agencies into thinking that anyone with a certificate was just as good for a project (skill-wise) as any other certificate holder. As I have commented before, this will most certainly not be the case. I'm all for tight standards for critical software products. But I feel that these standards can be met without the substantial disadvantages that another government certification program would incur. --Lauren-- ------- 5-Apr-79 14:08:19-PST,1444;000000000001 Mail-from: SRI-KA rcvd at 16-Mar-79 1750-PST Date: 16 Mar 1979 (Friday) 1750-Est From: COTTON at NBS-10 Subject: MSGGROUP# 913 On Reid's distribution of story on reactors To: stefferud at SRI-KL Redistributed-To: MSGGROUP at ML Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 16 Mar 1979 Since comment was specifically witheld, I cannot be sure what the point is. Clearly programmers are increasingly in positions of great leverage; that is, their work products have great effect. What that says about certification I am not sure, since I don't understand how certification might have avoided the problem cited. What IS clear to me is that we need much more formal procedures (dare I call them standards) for the review of work products (e.g., programs) before they are released for use. I am curious how many others in MSGGROUP work under a regime where written documents require rigorous and formal review before they are released, but where programs are not similarly reviewed, and where often only a single person in the organization knows how the program works. Until both we and the organizations for which we work begin to view programs in the same light as reports (that is, as work output whose quality reflects on the performing organization; and as work output whose quality CAN be controlled), we can look forward to more plant closings and similar fiascos. 5-Apr-79 14:08:19-PST,2330;000000000000 Mail-from: MIT-ML rcvd at 18-Mar-79 0033-PST Date: 18 Mar 1979 0014-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 914 FJW IN DEFENSE OF PROGRAMMER(S) From: FJW@MIT-ML To: msggroup at ML Message-ID: <[USC-ISI]18-Mar-79 00:14:00.STEFFERUD> Begin forwarded message Mail-from: MIT-ML rcvd at 17-Mar-79 2343-PST Since we now have a real-life, non-academic example of a program apparently gone wrong, I would like to know more about the subroutine in question and the programmer(s) who wrote and tested it. Specifically, in what language and compiler implementation of that language and on what machine was this program written and by programmers of what experience. In fact, I would like to see the actual code, if that is possible. To: msggroup at MIT-ML FJW@MIT-MC 03/18/79 02:30:53 Re: SHOCK II The acticle says that this subroutine gave inconsistent results presumably with the same data(?). This usually happens when there is mishandled overflow, underflow, truncation error, or a non-pseudo-random number generator in the program (among other things). I would like to know which one it was, or was it simply "bad" programming. Perhaps I would like to be able to come out in defense of the programmer(s) involved, given all the facts available, and so too should this community. The question is: Would any resonably experienced programmer in that language and on that machine have made the same "mistake" (assuming one was made)? However, if it was the result of a compiler error, machine ideosyncracy, or error in the vendor-supplied run-time subroutine library, then we have an entirely different situation. Based on the results of that answer, we can proceed to discuss the merits of experience vs. certification... I believe that not one of us so-called "experienced" programmers can claim that every program we wrote ran the very first time the way it was intended, if at all, or that every program in production use did not develop some obscure bug after successfully running for perhaps years. Nonetheless, we simply cannot let so public and vital an "error" go on the record without an appropriate defense on behalf of the entire programming community (if one is possible). --Frank -------------------- End forwarded message 5-Apr-79 14:08:19-PST,1430;000000000001 Mail-from: MIT-ML rcvd at 18-Mar-79 1358-PST Via: Rand-Unix To: msggroup at mit-mc cc: farber Subject: MSGGROUP# 915 An interesting new offering From: Farber at UDEE Reply-to: Farber at Rand-Unix Date: Sun, 18 Mar 79 16:06-EST At the IEEE Seminar on Small Systems on 17 March 1979, William vonMeister of Digital Broadcasting Corporation "announced" the availability of TCA (Tymsharing Computer Access). He said it will be officially announced at NCC in June. The service gives access to "national" timesharing services from over 200 cities between the hours of 6 pm and l 8 am (local time) for a flat rate of $2.50 per hour including connect and computer charges. The services include fortran, basic, micro-software support tools, bullitan boards, classified ads, electronic message services and more. Storage charges are $1/2000 characters/ day. It will cost $100 signup charge and a $5 minimum charge per month. Royalties will be paid for user submitted software of 9 % of charged time. I asked him if the network that would support this was tymshare and he said no. That seems to leave Telenet?. He claimed that the service was being tested at present in Washington. For further info, he said to contact: TCA %DBC 7670 Old Springhouse Rd. McLean, Virginia 22101 Betty Tonmsing Further information would be appreciated Dave 5-Apr-79 14:08:19-PST,1061;000000000000 Mail-from: MIT-ML rcvd at 18-Mar-79 1417-PST Via: Rand-Unix To: Msggroup@mit-mc, Header-People@mit-mc Subject: MSGGROUP# 916 Dawning of a New Age? From: Dcrocker at UDEE Reply-to: Dcrocker at Rand-Unix Date: Sun, 18 Mar 79 16:19-EST Please to note the From field of this message. As of a couple of days ago, we are finally able to send messages onto the ArpaNet, from the University of Delaware. We use dial-up access to a Mail Relay host (currently Rand-Unix). We should shortly have automated pickup of mail, also. The current hack is to have return mail go to our accounts on Rand. The longer-term solution will remove this and have it go "directly" back to Delaware. You might be interested to know that we use 300 baud, which gives us an effective bandwidth of about a kilobyte per minute. As atrocious as that sounds, it obviously is somewhat useful. Only requirement is that the user not be expected to sit and watch it, so of course we have a background process do the dial-up and transfer. Dave. 5-Apr-79 14:08:20-PST,3101;000000000001 Mail-from: MIT-ML rcvd at 18-Mar-79 1531-PST Via: Rand-Unix To: msggroup at mit-mc Subject: MSGGROUP# 917 A Survey of ARPANET Mail Systems -- Subject: corrections and additions appreciated From: Farber at UDEE Reply-to: Farber at Rand-Unix Date: Sun, 18 Mar 79 17:52-EST Redistributed-To: heiser at ECL Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 26 Mar 1979 List of ARPANET Mail Systems Compiled by David J. Farber University of Delaware (farber at sri-ka) Mail System Authors Machines -------------- -------- -------------- $NETMAIL AMES 360/67 BABYL EAK MIT-MC, -AI, -ML BANANARD Yonke Tenex COMSAT Harrenstein MIT-MC, -AI, -ML COMSYS Lebling & Haverty MIT-DMS DMS Broos TOPS-20 FTP (ftp server) BBN Tenex, TOPS-20 FTPS (ftp server) Harrenstein MIT-MC, -AI, -ML HERMES BBN Tenex (14 sites) HG Calvin MAIL (reader) Wermes TOPS-10 (CMU) MAIL (sender) Harvey SU-AI 10 MAIL/QMAIL (reader) Harrenstein MIT-MC, -AI, -ML MAILER (services) BBN Tenex, TOPS-20 MAILSTAT (services) BBN Tenex, TOPS-20 MH Borden PDP/11 Unix MM McMahon SRI-KL MS D. Crocker PDP/11 Unix MSG Vittal Tenex (18 sites) MSG (version 1) UCB - RAND PDP/11 Unix MSG (version 2) D. Crocker PDP/11 Unix MSGH Ness Wharton PDP/10 NETMAIL Yonke POD Lebling MIT-DMS print-mail Palter & Sibert Multics all RCV (reader) Harvey SU-AI 10 RD Haines LLL IBM VM/370 RD Roberts Tenex, TOPS-20 RDMAIL Karlton TOPS-10 (CMU) READMAIL LLL IBM VM/370 READMAIL Tomlinson Tenex, TOPS-20 read_mail (reader) Palter & Sibert Multics all RMAIL Stallman MIT-MC, -AI, -ML send_mail Palter & Sibert Multics all SIGMA (Not ARPANET ISI Dedicated TENEX general service) SNDMSG Tomlinson Tenex, TOPS-20 SNDMSG UCB - RAND PDP/11 Unix SWAMP Guyton IBM 370 Wylber Wharton Mail System Ness Wharton PDP/10 5-Apr-79 14:08:20-PST,825;000000000001 Mail-from: MIT-ML rcvd at 18-Mar-79 1716-PST Date: 18 Mar 1979 1929-EST Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP# 918 Re: A Survey of ARPANET Mail Systems -- ... From: MOOERS at BBN-TENEXA To: Farber at RAND-UNIX Cc: msggroup at MIT-MC, Mooers Message-ID: <[BBN-TENEXA]18-Mar-79 19:29:40.MOOERS> In-Reply-To: Your message of Sun, 18 Mar 79 17:52-EST Redistributed-To: heiser at ECL Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 26 Mar 1979 At present writing, Hermes is running at 16 sires: BBNA,BBNB,BBN,BBND,BBNE ISI,ISIB,ISC,ISID,ISIE SRI-KA, SRI-KL USC-ECL, OFFICE-1, OFFICE-2 PARC-MAXC1 The next version, which will go up shortly, will be installed on PARC-MAXC2, as well. Thanks for the list. It is very useful to have. ---Charlotte 5-Apr-79 14:08:20-PST,3004;000000000001 Mail-from: MIT-ML rcvd at 19-Mar-79 0440-PST Date: 19 MAR 1979 0722-EST From: CBF at MIT-MC (Charles Frankston) Subject: MSGGROUP# 919 certification of computer professionals To: Brian Reid at CMU-10A CC: MsgGroup at MIT-ML, hwc at SU-AI I entirely disagree with any interpretation that this reactor shutdown incident shows a need for certification of computer professionals. It is not a computer professionals responsibility to ensure that Civil Engineering models are correct. To require this would be to imply that a programmer must become an expert in every field that he writes a program for! If indeed a professional programmer wrote the program in question, (which I doubt), then his only responsibility would be to ensure insofar as possible that his program correctly implemented the algorithm as given to him by the civil engineer, and that he advised and encouraged the civil engineer to thouroughly check the program. For the Civil Engineer to blindly trust that the program gives the correct answer is negligence on the part of the Civil Engineer, not the programmer who presumably does not posses the expert knowledge to determine that the answers are correct in any but the most obvious cases. Now, the interesting point of this all is, Civil Engineers are certified! Therefore, I claim this case is de facto proof that certification is NOT a panacea against human error or bad judgement. If anyone is truely interested, I checked with a source at Stone & Webster. The program in question was in fact not written by them. They do not even have a programming department. The program is a purchased program product that has its origins at the MIT Civil Engineering dept at least 10 years ago. As best as my sources know, the only verification that was done of the correctness of the program was with trivial test cases. They use the program as a black box into which they throw numbers and get back numbers. Stone & Webster for those who don't know, was the first Civil Engineering firm in the world. Stone and Webster were 2 very early MIT graduates. As far as procedures at the company right now. All design work is signed by the designer and reviewed and signed by another designer. These designers are not necessarily liscensed or degreed, however, the work they do is generally broken down into almost trivial subsections of a design. The entire design is then supposedly checked and signed by a certified Civil Engineer. I think the reputation of the firm means a lot more than the fact that they employ certified engineers. (Most of the company btw, is now putting in large amounts of overtime. Stone & Webster is paying a million dollars a day to cover the costs of the reactor shutdowns). I do not therefore see the reason to saddle the computer industry, in which proper design practices are far less obvious than Civil Engineering with a certification mechanism that seems to have such little benefit. 5-Apr-79 14:08:20-PST,2287;000000000001 Mail-from: MIT-ML rcvd at 19-Mar-79 0552-PST Date: 19 MAR 1979 0837-EST From: CBF at MIT-MC (Charles Frankston) Subject: MSGGROUP# 920 An interesting new offering To: msggroup at MIT-ML, Farber at RAND-UNIX Redistributed-To: heiser at ECL Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 26 Mar 1979 It might be noted for comparison purposes that for the past couple of years, the charges on the MIT Multics system have been approximately as follows: Shift 2 (6PM-Midnight): $4.00 per hour Shift 3 (Midnight-9AM): $2.00 per hour Shift 4 (Weekends 9AM-6PM): $6.00 per hour There is device charge for usage from Telenet of about $1.25 per hour. I believe the Tymnet connection has a similar surcharge. There is no Arpanet surchage. 9AM to 6PM weekdays gets charged for CPU time, memory usage and connect time. Typical light usage might average $6.00 per hour, but heavy crunching can run as high as $40 per hour. Background (idle priority only) absentee (batch without cards) cost a flat $25 per CPU hour (68/80 cpu = 75% of KL10). Disk storage is $.02/day/4096 characters and is backed up to magnetic tape continuously (during attended operation) for that price. Multics of course has fortran, pl1, cobol, basic, lisp, apl and bcpl. Secure electronic mail, text processing, numerous special purpose packages and an excellent environment for developing new software. (Features like dynamic linking and a practically unlimited virtual address space). Governement users should have no problem purchasing time from MIT. Non-government users are handled on a case by case basis. The point of this is though MIT gets substantial discounts on the hardware, the prices MIT pays are not low as compared to lets say DEC hardware, or the latest spate of IBM announcements. The IPS (Informatin Processing Services) by no means runs a low overhead operation. The machine has an operator or operators in attendance 16 hours a day, there is a staff of system programmers, online consulting for simple problems and clerks to do the billing. The IPS is supposed to break even each year, and they come close to it. Therefore, it does not surprise me that commercial services can offer similar rates. 5-Apr-79 14:08:21-PST,1575;000000000001 Mail-from: MIT-ML rcvd at 20-Mar-79 2203-PST Date: Tuesday, 20 March 1979 21:32-PST From: WANCHO at SRI-KA To: MsgGroup@MIT-ML Subject: MSGGROUP# 921 Details on Stress Analysis Error from "CW" From Computerworld, March 19, 1979: ...The error occured when a programming subroutine to determine the strength of the pipe fittings mistakenly subtracted horizontal stress figures from vertical stress figures instead of adding them, causing the design of fittings one-third to one-sixth the strength required by regulations. The subroutine was used until 1972 by Stone and Webster Engineering Corp., a nuclear design and construction firm based in Boston. Stone and Webster agreed with the NRC [Nuclear Regulatory Commission] that the pipe supports "may not give uniformly conservative results at all times," but disagreed that the shutdown of the power stations was warranted. Keith Wichman, an engineer at the Division of Operating Reactors, the NRC's engineering branch, said the Stone and Webster subroutine is the only one known to the division that used algebraic summation to calculate stress. This type of summation "is technically an error" compared with two other accepted ways - absolute summation and square root of the sum of the squares, he said. Calling the Stone and Webster technique "deficient," Wichman said the division is investigating to see if the same kind of subroutine has been used by anyone else. "To our knowledge, this is the first instance where anyone was using this particular technique," he added.... 5-Apr-79 14:08:21-PST,29274;000000000001 Date: Thu, 22 Mar 79 09:36-EST Subject: MSGGROUP# 922 Multi-Channel Memo Distribution Document From: Farber at UDEE To: msggroup Cc: farber at SRI-KA Special-Handling: The text body contains ^L paging control Special-Handling: characters, and "backspace underscoring." Via: Rand-Unix Reply-to: Farber at Rand-Unix Redistributed-To: heiser at ECL Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 26 Mar 1979 COMPONENTS OF A CHANNEL-INDEPENDENT MEMO TRANSMISSION SYSTEM David H. Crocker Edward S. Szurkowski David J. Farber University of Delaware, Newark, Delaware 19711 ABSTRACT________ The advent of packet-switched networks led to increased use of computers for sending messages between people. However, attachment to such networks is expensive and often restricted by organizational policies. In addition, availability of several networks creates the need for forwarding memos between them. The work described here is designed to free users from dependence upon any particular communication environment and provide a memo distribution facility which can employ whatever channels are available. This will support variable-network structures, simu- lation of network attachment, and inter-network mail forwarding. INTRODUCTION____________ While it has been common for stand-alone time-sharing sys- tems to provide some message (memo) services for their users, the advent of packet-switched networks created a major boost to the use of these services and resulted in a demand for improvements to their functionality. This seems primarily to be due to the vastly increased base of potential communicants and to their geo- graphic separation. The ArpaNet provided the first major oppor- tunity for ongoing inter-organizational human communication to take place using geographically distributed computers [13,9,3]. Network-based commercial message systems are beginning to appear, although most of their initial orientation is towards using the network to connect the users' terminals to the same machine, rather than towards having a number of machines, each located near users, and using the network to transmit messages between machines. The existing ArpaNet system allows communication among several thousand computer users. However, there still are many thousands (and even millions) of potential communicants who can- not take advantage of computer-based message systems since they are not attached to a major computer network. The costs of attaching to such a network are quite high and, as in the case of the ArpaNet, there often may be organizational policies restrict- ing who is allowed to access it. In addition, the current trend is towards 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 is intended to create an application-level system for the distribution of memos between machines not attached to a 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. We are using the term "memo" to indicate the role the messages usually play within human communication. They are for- matted to contain some header information, such as recipient lists and a subject line, followed by a body. Delivery usually occurs within a few minutes. The full range of formal inter- organizational communications is not currently being attempted. A full message system may be viewed as consisting of a user environment and a distribution package (see Figure 1). The user environment must allow the user to create, view, and modify messages and to interface with the distribution package, which must accept messages for transmission and attempt to place them into the mailboxes of intended recipients [1,15]. Most work has been devoted to the devlopment of sophisti- cated user environments, allowing the full-range of text editing (word processing) [e.g., 1,7,8]. In a few cases, data-base management systems have been employed to help users wade through the mass of messages they have to process [14,15]. For example, an informal survey of various ArpaNet users indicates that pro- cessing 20-50 messages a day is not uncommon. There has been little work attempting to develop robust distribution facilities. As a replacement to the existing trivial protocol [10, 11], two robust ones have been proposed for the ArpaNet, although neither has been pursued [5,16]. Another attempt is now underway [12]. GOALS_____ The University of Delaware's Multi-channel Memo Distribu- tion Facility (MMDF) is intended to interface to the user- oriented systems in such a way as to provide an integrated view of a communication environment which can have a variety of dif- ferent transmission channels. Consequently, sending a message to a local user, to a user on a machine attached through a local, national or international network, or to one on a machine acces- sible only through a telephone call will involve the same effort for the user. In addition, changing the available channels while retaining the same recipient population (e.g., converting from ArpaNet connections to a local network, if all of the user's mes- sages have been to local machines) often will be completely tran- sparent to users. At present, the level of functionality being provided is approximately the same as is used on the ArpaNet. A recipient list is established and the text of the message is then passed. Also, provisions exist for indicating that a message is to be broadcast on users' terminals, rather than (or in addition to) being put into their mailboxes. This is already experimentally available on some ArpaNet hosts [6]. ARCHITECTURE____________ MMDF is being implemented on the Unix operating system, running on DEC PDP-11s and has modules for handling 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 in which the message con- sists of a collection of headers (some being highly structured) followed by the body [2]. Primary Functionality In order to provide reasonable data security and privacy and to facilitate deferred delivery of messages, MMDF operates separately from individual users, once their messages have been submitted for transmission. In particular, no storage (file) space is shared and users' access to MMDF's storage space is highly restricted. See Figure 2, for an overview of the MMDF process structure. Distribution of a memo is requested by invoking the SUBMIT program which is responsible for accepting a message, parsing its distribution list, queueing it in MMDF's file space and, option- ally, for invoking the DELIVER process if delivery is to be attempted immediately. (A background DELIVER process runs every 15 minutes, trying to send those messages not delivered immedi- ately.) 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 verifies destination specif- ications as completely as possible. The syntax checking only verifies that fields are properly delimited and is not concerned with the internal format of specific fields. Source information is supposed to indicate who sent the message, since it is not considered acceptable for anonymous senders to consume -- and possibly flood -- storage space of recipients. For the specifi- cation of destination mailboxes, SUBMIT can fully certify the existence of mailboxes on the local machine but can only certify the existence of the indicated host for mailboxes on other machines. In the latter case, detection of non-existent mail- boxes is deferred until delivery is actually attempted. However, a more robust inter-machine functional protocol might allow com- plete 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, when a user moves; and the facility allows a single name to be used for sending memos to a group of users. A message is queued into two files. The first contains status information and the address list and the second contains the message text. Status information includes the time the mes- sage was queued and the person to whom return mail is to be sent. The former is to allow delivery of queued messages, in the order queued, and to determine when message delivery has been unduly delayed; and the latter is to allow MMDF to inform the sender of delivery problems. SUBMIT parses the address list to the extent necessary for it to distinguish which delivery channel is to be used. In fact, most of MMDF's sophistication is in SUBMIT's ability to de- multiplex these address specifications. For example, the specif- ication "CMorris at Office-1, Farber at UDEE, KLH at Gallaudet" must be understood to have the first copy delivered via the ArpaNet, the second via the local machine, and the latter sent over the telephone to a system in Washington, D.C. Once parsing is accomplished, the addresses are listed in a rigid format, to be used by the DELIVER program. DELIVER is responsible for managing the transmission pro- cess, recording its success and handling delivery failures. DELIVER uses part of the information recorded by SUBMIT to deter- mine which transmission modules to invoke. However with only one exception, DELIVER does not have any understanding of the differ- ences between these modules or how they handle addresses. If DELIVER is running as the background daemon responsible for processing messages not sent at the time of submission, it uses the time of queuing so that messages will be delivered in the order submitted. In addition, this is used for a two-level time-out. After the first time-out (e.g., 72 hours) a warning message is returned to the sender indicating to whom the message has not yet been successfully transmitted. After the second time-out (e.g., 7 days), the message, itself, is returned to the sender with an indication of which intended recipient(s) never got the message. The normal mode for message systems is to have the sender initiate delivery. That is, when a message is queued an active attempt is made to deliver it into the recipient's mailbox. In order to implement a special use of telephone-based delivery, we have added a "passive" delivery mode, called "Post Office Box" delivery. In this mode, a queued message is held until the reci- pient machine attaches itself and requests (i.e., polls for) any P.O. Box messages being held for it. This allows a machine attached to a network to hold messages arriving from the net, until disconnected machines call up. This mode requires the one exception in DELIVER's ignorance of the specifics of different delivery modules, since it must not invoke the P.O. Box module unless specifically requested. Transmission Modules Currently, four transmission modules have been built: LOCALSND, ARPASND, PHONESND, and POBOXSND. Modules responsible for non-local delivery must handle two protocols. The low-level protocol allows data to be transferred and the higher-level pro- tocol deals with the semantics of submitting memos into the receiving system. Minus various user interface features, there- fore, the higher level protocol should correlate with the features of the SUBMIT program. The LOCALSND delivery module must run with special privileges, since it must be able to write onto any user's mail- box and, for privacy reasons, mailboxes normally will be pro- tected. The standard action is to append a new message to the end of the recipient's mailbox. However, a feature is available which allows any recipient to have a special program which will be invoked to handle the actual reception. For example, this would allow automatic incorporation into a data-base management system for some users but not for others. For a machine attached to the ArpaNet, the ARPASND module handles delivery to other attached hosts. It employs the File Transfer Protocol (FTP) and sends a separate copy of the message for each recipient [10, 11]. (Unfortunately, some ArpaNet hosts will accept messages, indicating successful delivery, even when the recipient is unknown. They typically then send the message to a lineprinter or to the operator.) Receipt of ArpaNet mes- sages is accomplished separately, by a FTP serving process which invokes SUBMIT. Since telephone calls are usually expensive and slow to make, the PHONESND module, requiring dial-out hardware, will nor- mally only be invoked by the background daemon, for example when several messages are waiting to be sent. It calls the destina- tion computer and then starts a slave (serving) process which cooperates in the exchange of messages. The data-transfer proto- col currently being used is extremely simple, idiosyncratic and believed to be implementable on any operating system. No attempt has yet been made to perform data compression or otherwise maxim- ize effective channel bandwidth. In operation, PHONESND accomplishes pickup of memos from the attached host, as well as transmitting queued messages to it. However, to DELIVER, PHONESND appears merely to be another transmission module. Queued messages are sent first, as shown in the top half of Figure 3. Then it requests the slave process to initiate transmission of any P.O. Box messages waiting to be picked up, as shown in the bottom half of Figure 3. The figures show the full process structure for two Unix-based MMDF systems participating in this type of exchange. POBOXSND, therefore, does not initiate any connections, instead merely "releasing" any messages waiting for its caller. Note that PHONESND implements a particular delivery and pickup policy. Altering the policy, for example having pickup precede delivery, would of course be quite easy. The policy for initiating Phone delivery is implemented in DELIVER and, again, could be altered to suit different cost and performance policies. In the initial implementation, DELIVER believes that the Phone module is actually the ArpaNet module. This is due to the requirements of a contractor, to have unattached machines behave as if connected to the ArpaNet. What is significant, however, is that eventually connecting one of these unattached processors will be completely transparent to its users. The contractor, then, can allow sites to begin using network memo communications for a much smaller cost than otherwise would be required. ACCESS______ CONTROL_______ & DATA____ SECURITY________ All of the modules in MMDF can access message text and therefore must be viewed as "trusted" processes, free of any Tro- jan Horse security violations. However, the system is designed to prevent unauthorized access by others, to the limit of the operating system. All memos offerred 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 limited, although the prohibition against anonymous memos could be considered excessive and some organizations may want to relax it. By the same token, much stronger enforcement of memo syntax may be desired, to guarantee that user programs can use information in the message for filing and constructing replies. Machines which exchange memos, such as shown in Figure 3, must do so with prior agreement, since the caller must be able to log into the "server." The question of the server's trusting the caller -- for example, whether it believes that a message's source information has been adequately authenticated -- can be treated as an administrative issue. Using the example, a server which trusts a caller will not have to add a disclaimer to a sub- mitted memo, indicating that the source information has not been authenticated. To some extent, the operational control, here, can be viewed as involving communication between message system "security kernels". Once a message 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 limit of the operating system and MMDF software integrity. STATUS______ A version of the system is currently in operation on The Rand Corporation's PDP 11/70, attached to the ArpaNet, and on the University of Delaware, Dept. of Electrical Engineering's PDP 11/70, which only has dial-out capabilities. The system runs as a collection of user programs. No modifications to the operating system are required, although a file exclusive-open and the Alarm (time-out) system call are used if available. As mentioned above, 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 flexibility and avoids the address-space problems common to 16-bit machines. To date, the two machines have cooperated to pass a message queued at Delaware, across a telephone connection, into the MMDF queue at Rand and destined for another ArpaNet machine. Shortly, the system is expected to be fully functioning and regularly exchanging messages between the two machines (and therefore between the University of Delaware and other ArpaNet hosts). 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 not available in the United States Postal system; retrieving a piece of mail, once it has been placed in an outgoing mailbox, is virtually impossible. Therefore, this pro- gram is not considered to be critical to the operation of the facility. CONCLUSIONS___________ In the past, computer-based message distribution has been limited to the local machine and, possibly, to an attached packet network. Attachment to such a network is expensive and still severely limits to whom messages can be sent. The current pro- ject is developing a distribution facility which takes advantage of any transmission channels available to it, including the tele- phone and local networks, and promises to greatly reduce the entry cost for performing computer-based memo processing. Although no attempt has yet been made to carefully optimize system performance, and some of its design would appear to impose substantial costs, preliminary indications show reasonable operating cost and performance. With proper tuning, the system should constitute an extremely cost-effective communications tool. ACKNOWLEDGEMENTS________________ The current software makes use of a skeleton delivery sys- tem built at the Rand Corporation, for the Defense Advanced Research Projects Agency, and already contained the alias and two-staged time-out features. Also, Robert Anderson and Stockton Gaines, of The Rand Corporation, have been extremely cooperative in permitting the use of their Unix system during the development of this system. 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 Readiness and Materiel Command. REFERENCES__________ [1] Crocker, D.H. Framework_________ and___ Functions_________ of__ the___ MS__ Personal________ Message_______ System______. R-2134-ARPA, The Rand Corporation: Santa Monica, Ca. (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 Interna- tional: Menlo Park, Ca. (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, Ca. (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, Univ. of South. Calif: Marina del Rey, Ca. (Feb., 1977). [8] Henderson, D.A. and Myer T.H. Issues in Message Technology. In: Proceedings___________ of__ the___ Fifth_____ Data____ Communication_____________ Symposium_________, IEEE 77CH1260-9C, pp 6: 1-9 (Sept, 1977). [9] Kahn, R.E. The ARPA Network -- Packet-switching Technology. In: IEEE____ Conference__________ on__ Communication_____________ Systems_______ and___ Technology__________, p. 134 (1974). [10] Neigus, N. File Transfer Protocol for the ARPA Network. In: [4]. [11] Postel, J. Mail Protocol. In: [4]. [12] Postel, J. personal communication, Jan. 1979. [13] 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). [14] Sattley, J. MARS -- A Message Archival and Retrieval Ser- vice. RFC No. 744, NIC No. 42857. Network Information Center, SRI International: Menlo Park, Ca. (Jan, 1978). [15] Vezza, A. and Broos, M. An Electronic Message System: Where Does it Fit? In: Proceedings___________ of__ Trends______ & Applications____________: Computer________ Networks________, IEEE: New York (1976). [16] White, J.E. A Proposed Mail Protocol. RFC No. 524, NIC No. 17140, Network Information Center, SRI International: Menlo Park, Ca. (June, 1973). ------------------------------------------------------------------------------ | User environment Distribution Package | | | | ----------------------- | | | Show Compose Format | ----------- ----------- | | | File Edit Send | ---> | Accept | . . . . > | Deliver | | | ----------------------- | & queue | ----> ----------- | | / / ----------- | | | | mailbox1 mailboxN | | V | | --> Queue of --- Local & Foreign | | Messages Mailboxes | ------------------------------------------------------------------------------ Figure 1: General System Structure for Memo Processing ------------------------------------------------------------------------------ | --------- -------- --------- | | |user | --> |SUBMIT| . .> |DELIVER| . . . . . | | |program| -------- . --------- . . . . | | --------- | . . . . V . . . | | | . ---------- . . . -- | | | . ------> |LOCALSND| . . . | | | | . | ---------- V . . |--> | | | . | ---------- . . | Delivery | | | . |--------> |POBOXSND| . . | to | | | . | ---------- V . | various | | | . | ---------- . | mailboxes | | | . |-----------> |PHONESND| . | | | | . | ---------- V | | | | . | --------- | | | V . |---------------> |ARPASND| | | | (limited) Queue of | --------- -- | | (access ) messages --- | | / / | | Addresses Texts | ------------------------------------------------------------------------------ Figure 2: MMDF Process Structure ------------------------------------------------------------------------------ | Disconnected Host (Caller) . Attached Host (Server) | | ----------------- . ------------- | | * Telephone | | | . | | V . | | Deliver (daemon) . | | SEND | . --> Submit | | TO V . | | | NET [Phonesnd]->(outgoing) . . . . .> [Slave] -> (incoming) | | [-----------------------------] . [-------------------] | | PICKUP [Phonesnd]<-(incoming) < . . . . [Slave] <- (outgoing) | | FROM | . ^ . | | NET V . | . | | Submit . | Deliver (pickup) | | . | . | | . ^ V | | . -------< POboxsnd | ------------------------------------------------------------------------------ Figure 3: Network Mail Forwarding for Disconneted Hosts 5-Apr-79 14:08:22-PST,833;000000000001 Mail-from: MIT-ML rcvd at 26-Mar-79 1200-PST Date: 26 Mar 1979 11:42 am (Monday) From: White at PARC-MAXC Subject: MSGGROUP# 923 Re: A Survey of ARPANET Mail Systems -- Subject: corrections and additions appreciated In-reply-to: Your message of Sun, 18 Mar 79 17:52-EST. To: Farber at Rand-Unix cc: msggroup at mit-mc, Victor@Office-2 Redistributed-To: heiser at ECL Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 26 Mar 1979 Dave, You should include SRI's (now Tymshare's) NLS Journal (now Augment) among your list of Arpanet mail systems. I believe it runs on SRI-KL (Tops-20), OFFICE-1 (Tenex), and OFFICE-2 (Tenex). You might consult someone like Ken Victor (Victor@Office-2) for more details and for verification of those given here. /Jim White 5-Apr-79 14:08:22-PST,513;000000000000 Mail-from: MIT-ML rcvd at 27-Mar-79 0952-PST Date: 27 Mar 1979 1233-EST From: Rick Gumpertz at CMU-10A Subject: MSGGROUP# 924 Re: A Survey of ARPANET Mail Systems -- Subject: corrections and additions appreciated To: Farber at Rand-Unix CC: msggroup at mit-mc Message-ID: <27Mar79 123349 RG02@CMU-10A> In-Reply-To: Farber's message of 18 Mar 79 17:52 The MAIL program at CMU is a SENDER, not a READER. It was written by Werme without an S at the end. Rick 5-Apr-79 14:08:23-PST,677;000000000001 Mail-from: USC-ISIE rcvd at 2-Apr-79 1358-PST Date: 2 Apr 1979 1357-PST From: POSTEL at USC-ISIE Subject: MSGGROUP# 925 New RFC Available [SRI-KL]753.TXT To: [isie]Request-For-Comments.List: RFC 753 is now available in the NIC online library at SRI-KL. Title: Internet Message Protocol Author: Jon Postel Pages: 62 pathname: 753.TXT Public access files may be copied from the NIC library at SRI-KL via FTP with username NICGUEST and password ARPA (actually SRI-KL allows copying of public access files via FTP without a login). --jon. ------- 5-Apr-79 14:08:23-PST,1229;000000000001 Mail-from: MIT-ML rcvd at 3-Apr-79 1741-PST Date: 3 APR 1979 2026-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP# 926 RMS on inability to communicate To: msggroup at MIT-ML Special-handling: Contributed by RMS without subject. Special-handling: Repaired by Stefferud I just had the frustrating experience of trying to get in touch with someone at UTAH-20, where I do not have an account (I had tried sending mail but got no answer). I found myself prevented from communicating not only with him but with any human being. A not-logged-in user isn't even allowed to ask the operator to decide whether to help him - there is no way he can make his presence known! He is condemned automatically by the computer, with no possibility of appeal. This is not the first ARPANET computer I have had this problem with. In addition, there was no RSEXEC server, so I couldn't link to them from MIT. This, also, has happened elsewhere. I hope you will all join me in declaring that every ARPANET computer with a TELNET server ought to give anybody who connects to it SOME way of contacting a human user to plead his case to. And in identifying the other machines which don't provide one. 5-Apr-79 14:08:23-PST,539;000000000000 Mail-from: MIT-ML rcvd at 3-Apr-79 1804-PST Date: Tuesday, 3 Apr 1979 2051-EST From: Brian K. Reid Subject: MSGGROUP# 927 rights of not-logged-in users To: RMS at MIT-AI (Richard M. Stallman) CC: msggroup at MIT-ML Message-ID: <03Apr79 205149 BR10@CMU-10A> In-Reply-To: Richard M. Stallman's message of 3 Apr 79 20:26 Maybe not every system can deal with malicious randoms as easily as ITS can, but I think it's a very worthwhile thing for people without an account to be able to contact *somebody*. 5-Apr-79 14:08:23-PST,1805;000000000000 Mail-from: MIT-ML rcvd at 4-Apr-79 0038-PST Date: 4 Apr 1979 0021-PST From: Mark Crispin Subject: MSGGROUP# 928 communication when not logged in To: MsgGroup at MIT-ML [C'mon, RMS, put subject lines in MsgGroup mail!] I must disagree with RMS. There are enough random malicious people floating around TIPs that this sort of thing is necessary. SCORE, like all other Tops-20 systems, disallows links when not logged in. There have been too many incidents across the network where a villian has lunk to a naive user with some story about "system failure, you have to re-type your password." Unlike other Tops-20s, we DO allow sends (logged in or otherwise), but that is conditional on it not being abused. Due to the way SEND is implemented on Tops-20 a tremendous (anonymous) harassment potential exists via program-controlled sends; this is why it is privileged every place else. The solution seems to be to let the mail systems do their work. That allows a user to decide for him/her self if and when to answer. If you are in contact with a person enough to justify frequent linking, you should be able to arrange for a guest account on that system. Another way of immediate communication is to use the telephone, which is of far higher bandwidth for person-person communication than any link. Talking with the computer operator is not an answer; most systems do not have an operator to talk to! Finally, I don't like the idea of "identifying" sites which have this practice. Many of us got it this way from the vendor of our operating system and decided that it wasn't worth changing. Perhaps if it was the other way many of us would leave it as well (consider Tenex, which by BBN default allows not logged-in links). ------- 5-Apr-79 14:08:23-PST,3813;000000000000 Mail-from: MIT-ML rcvd at 4-Apr-79 0309-PST From: RWK@MIT-MC Date: 04/04/79 05:45:42 Subject: MSGGROUP# 929 Re: Humanizing Login Servers To: msggroup at MIT-ML Special-handling: Arrived in ITS HEADER FORMAT. Special-Handling: Repaired by Stefferud. I just noticed RMS's note about trying to get in touch with a human behind the mechanical bariers at UTAH-20. I too have encountered this difficulty a number of times. Unix's and Multics's seem to be the worst culprits, but by no means the only ones. In addition, RMS tells me he was told that UTAH-20's lack is due to ARPA pressure. The way I see it, there can be no justification for this. MRC's note about the "System Failure, please retype your password" I find unbelievable. Any person that naive, in the unlikely event that a malicious random would try such a thing, is so naive as to present a danger to himself and anyone around him, would be perpetually broke, if he managed to not get killed outright from sheer stupidity. On ITS we've always had the ability to send immediate (TTY) messages, send mail, and link while not logged in. On MC we have probably the highest network-random traffic of any host. I have NEVER seen any great problem with abuse of sends, and the ONLY problem I've ever seen with linking has been due to the ability to "slave" someones terminal in a link (i.e. to type to his program, log him out, etc.). Interestingly enough, since we got passwords, I don't think that kind of abuse has happened once. Also, as I recall, it was MRC who urged me to not have our password system inhibit links! Interestingly, the ability to send mail was not an easy solution to RMS's problem. Had it been a UNIX, he probably would have had no way to find any name to mail to. I once had reason to communicate with anyone at UTEXAS. I ended up writing a program which sent to Smith, ASmith, BSmith .... etc, and luckily hit one out of the 27. In RMS's case, he could do a FINGER, however, most users there lack network priveledges, so if he sent them mail, they'd not be able to reply! (Clearly, that is an evil in itself. It's alegedly also due to DARPA pressure.) I think there should be 4 minimum things that ANY site should support not-logged-in. 1) A way of telling who is on the system. Not to revive the FINGER debate, but I also think it's good to give a HUMAN name; the idea is that of FRIENDLY PEOPLE, instead of COLD MACHINES. 2) A way to SEND TTY messages. 3) The ability to RECEIVE TTY messages. 4) A way to send MAIL. Also HIGHLY desirable: 5) A way to link, and to be linked to. 6) A way to type public access files. In conclusion, let me remark on this alleged DARPA pressure. It seems to me that the primary purpose and benifit of this network is to enhance communication of ideas. It also seems that DARPA's recent moves are in direct contradiction of this purpose, and as such, are wasting the taxpayers money and standing in the way of research. I have heard that the reason for DARPA's recent "crackdowns" is that the Government Accounting Office is has said something along the lines of "we'll wait until we finish our investigation before we shut down the net". If this is the case, then I think the GAO is acting as a menace to the taxpayer and researcher alike, and that DARPA's response is totally backwards. Instead, they should publicize the situation. Certainly the network community can provide enough evidence of the benifit of an open network to stop the GAO in its tracks. And I think we (the users) would deserve to be told the facts. I hope this is merely an erroneous rumor (in which case DARPA's actions remain unjustified), but I fear it may be the case. Does anyone out there know the facts? 5-Apr-79 14:08:24-PST,3001;000000000000 Mail-from: MIT-ML rcvd at 4-Apr-79 0415-PST Date: 4 Apr 1979 0348-PST From: Stuart McLure Cracraft Subject: MSGGROUP# 930 Re: Humanizing Login Servers To: rwk at MIT-MC Cc: msggroup at MIT-ML In-reply-to: Your message of 4-Apr-79 0307-PST (You've let yet another non-standard network header out to dozens of people on the network.) I find it interesting that the two major locally hacked/maintained academic sites on the network, (e.g. the ITS machines and SAIL), both have more of these features, whereas practically no other site allows them all and certainly not terminal linking or sending when not-logged in. We have the 4 minimum requirements you proposed, however the sending and linking features are limited to coming from other network sites. This is a better way of limiting the flow of any possible randoms who might be hacking through a TIP or dialing directly. Saying that you have 'never seen any occurence' of abuse of allowd links/sends from local not logged jobs is really a matter of opinion. I would bet that a number of people are offended by constantly being asked questions by randoms. In fact, I have discussed this with some MIT people and a couple of them have confirmed that fact. They are sick and tired of randoms questioning them. We have always tried to allow the maximum in contacting users of our machine. Specifically network links are allowed and also network sends (although not local links or sends from not logged in jobs). I think that this policy is the bare minimum and anything less involves incarcerating the user population behind a fence. Anything more involves a certain risk of having randoms on the system. When you are at an academic site with no 'paying' customers, I think it is fine. But when there are people on the system who, for the most part, cannot be bothered by randoms of any nature, this is the obvious solution. To me, the ITS systems are too open, Multics, Unix, default TENEX and default TWENEX too closed. In the former three, the 'misfeatures' of too much or too little protection are built directly into the operating system and to change them would require a great deal of work. Witness the complete lack of any file or directory protection on ITS, and the intense paranoia of the Multics and Unix systems, where the former restrains users practially as much as Tymshare's machines, and the latter is almost but not quite as bad. On TENEX and TWENEX, only minor hacks are required to make them win in this manner. One need only have an RSSER server for the links and a reasonable FTP server that has the capabilities for accepting those SENDS. As for typing public files, I think that is a misfeature at best. Since we allow anonymous logins, it is not necessary. As for DARPA, that is completely news to me. I would like to keep informed of such matters, although not necessarily through the medium of msggroup. Stuart ------- 5-Apr-79 14:08:24-PST,1131;000000000000 Mail-from: MIT-ML rcvd at 4-Apr-79 0437-PST Date: 4 April 1979 07:08-EST From: Robert W. Kerns Subject: MSGGROUP# 931 McLure's reply to my message To: msggroup at MIT-ML Sorry for not being clearer on this, but what I meant was that I've not seen instances of abuse of sending messages WHILE NOT LOGGED IN. It is indeed true that many people here are tired of being asked too many questions by too many randoms; however 99.9% of the questions come from logged in randoms, and probably 75% of the ones which come from randoms not logged in are people who have accounts or who know of our generosity. I really don't think that our density of questions would be at ALL valid on any other ARPA site. However, the number of times that IMPORTANT communications have been delivered by not-logged-in users makes it obvious that it's worth having these features. In fact, we have never even considered removing any of these features. Even though we do get "constant" questions. But for the rest of the world, who have not taken on the burdens we have, you will not find "constant" questions. 5-Apr-79 14:08:24-PST,2091;000000000000 Mail-from: MIT-ML rcvd at 4-Apr-79 0458-PST Date: 4 Apr 1979 0430-PST From: Mark Crispin Subject: MSGGROUP# 932 humanizing login servers To: RWK at MIT-MC, McLure at SRI-KL Cc: MsgGroup at MIT-ML Stuart sent almost the exact answer I was going to send. I'd like to make a few hopefully non-flaming additions. It is unacceptable to have the attitude that because a user is naive s/he is "stupid." There are a lot of bright people who do not know every in and out of a computer system and don't intend to learn, but at the same time must use it. A computer system typically makes strange demands at odd times to a user, and all too often the "consultant" simply says "do this" or "type that" without any explanation; perhaps because the user did not want an explanation. About abuse of sends, let me point out that ITS was the first place where the "cookie bear" was implemented. A "cookie bear" is trivial on Tops-20 if the TTMSG JSYS is unprivileged as it is on Stanford Tops-20's. One of ITS' advantages is that its human interface is non-existant; often before a loser knows enough to do anything serious s/he has grown up enough not to (or has been thrown off). Most UNIX systems allow the WHO command as a special login. Every one that I've had to talk to has. There is also the Arpanet Directory, which exists for the precise purpose of finding people and their network addresses! I would not go about making too many waves about GAO or DARPA. Let me point out that the Arpanet is DCA's network and they can do whatever they want with it that they damn well please. The people at DCA aren't the evil spoil-sports you picture them to be; they perform the necessary function of running the network and defending it before Congress, and they understand our special environment and needs more than you might believe. If a little paranoia against random outsiders makes "them" feel reassured so they don't pull the plug, then by all means I'd rather have paranoia than lose the network. -- Mark ------- 5-Apr-79 14:08:24-PST,1371;000000000000 Mail-from: MIT-ML rcvd at 4-Apr-79 0520-PST Date: 4 April 1979 07:47-EST From: Robert W. Kerns Subject: MSGGROUP# 933 Humanizing Login Servers To: msggroup at MIT-ML First off, I think I'm quite aware of the difference between naive users and stupidity. I help a lot of very naive users. I know damned well they aren't stupid. I also don't think they'd fall into MRC's hypothesized trap. My whole point was that the trap requires stupidity, and the users aren't stupid. Second, I don't see what a cooky bear has to do with not-logged-in users, unless MRC is proposing to make that a no-login command too! Thank you for the info about the WHO login. The ARPANET directory is woefully inadaquate for the task of finding someone who's online or even for finding out someone's network address. Many people aren't even in it (I'm not, most of the people I communicate with aren't either!) As for DARPA, my point was that if there was pressure, I didn't exactly agree with the way DARPA was handling it (although I'm sympathetic for their position). And if there wasn't any pressure, then they're the villans. (It's not "their" network, it's the taxpayer's!). And in any event, I'd like to know what was going on, since it affects me in unpleasant ways. I wouldn't call this making waves, just good citezenship. 5-Apr-79 14:08:25-PST,644;000000000000 Mail-from: MIT-ML rcvd at 4-Apr-79 0539-PST Date: 4 April 1979 08:25 est From: Frankston.Frankston at MIT-Multics Subject: MSGGROUP# 934 Re: Humanizing Login Servers To: msggroup at MIT-ML In-Reply-To: Msg of 04/04/79 08:09 from Robert W. Kerns To make the usual defense for Multics. A Multics system can be set to be fairly open. It is a matter o finstallation and project admnistrator decided defaults. For example, there is an Initial "help" command that can be informative. The installation can setup a passwrodless project for the "enter" command that can be used to assist visitors if that is thought desirable. 5-Apr-79 14:08:25-PST,1185;000000000000 Mail-from: MIT-ML rcvd at 4-Apr-79 0836-PST Date: 4 April 1979 11:18 est From: Pogran.CompNet at MIT-Multics Subject: MSGGROUP# 935 "Not-Logged-In" use and helpfulness of Subject: ARPANET hosts To: MsgGroup at MIT-ML Message-ID: <790404161818.789421 at MIT-Multics> The community of ARPANET server hosts is a diverse one; there are very likely as many viewpoints on what it means to be an ARPANET server as there are servers. I think the issue is not so much one of what the operating system, or the login programs (called the "Answering Service" in Multics parlance; an apt name, I think), permit a not-logged-in user to do, so much as what the administrators or managers of that server see their role as being; e.g., the Multics system at MIT is run by Information Processing Services as a computing utility, while the MIT AI Lab ITS system is operated by a research organization. To exaggerate, the purveryors of the former might perceive themselves as being justly cold and aloof, while the caretakers of the latter might view their friendliness to outsiders as part of their proper role as a research organization. Ken Pogran 5-Apr-79 14:08:26-PST,891;000000000000 Mail-from: MIT-ML rcvd at 4-Apr-79 0845-PST Date: Wed, 4 Apr 79 07:33-PST Subject: MSGGROUP# 936 Re: Humanizing Login Servers From: Greep at Rand-Unix To: McLure at Sri-Kl (Stuart McLure Cracraft) cc: msggroup at Mit-Ml Message-ID: In-Reply-To: Your message of 4 Apr 1979 0348-PST You are mistaken about the over-protectiveness of Unix being a part of the operating system. The login program, which is not part of the Unix kernel, could easily be modified to allow certain commands without logging in. I will do this for you on SRI-Unix if you want. By the way, I never saw RMS' original message (I assume one exists since everybody has been replying to it). My guess is that this is because of the bug in the ITS mailer that assumes that the mail has been successfully transmitted even if a negative acknowledgement is returned. 5-Apr-79 14:08:26-PST,739;000000000000 Mail-from: MIT-ML rcvd at 4-Apr-79 1302-PST From: RWK@MIT-MC Date: 04/04/79 15:48:19 Subject: MSGGROUP# 937 Re: "Not-Logged-In" use and helpfulness of Subject: ARPANET hosts To: MsgGroup at MIT-ML Special handling: Arrived in ITS Format. Repaired by Stefferud. Date: 4 April 1979 11:18 est From: Pogran.CompNet at MIT-Multics .... To exaggerate, the purveryors of the [MIT-Multics] might perceive themselves as being justly cold and aloof ... Maybe the purveyors are "justly" cold and aloof; however, they're imposing their coldness and aloofness between friendly me and any friendly researcher who is on "their" machine. Sounds like just another way to say "they don't care". 5-Apr-79 14:08:27-PST,3374;000000000001 Mail-from: MIT-ML rcvd at 4-Apr-79 1354-PST Date: 4 APR 1979 1322-PST From: AHENDERSON at PARC-MAXC2 Subject: MSGGROUP# 938 Open and closed systems, Subject: communication and research. To: msggroup at MIT-ML I remember Larry Roberts talking about the resesons for building the ARPANet (circa 1968 at Lincoln Lab). First there was the question of whether packet-switching was a viable alternative to the way that communication was then being done within the government (and particularly, of course, within DoD - eg Autodin). The second point was to see what would happen when coommunication capability was supplied to a bunch of people who had motivation to communicate with one another. That is, "put it out there and watch what happens". What has happened is an extension of things which were happening in single-computer systems (and the communities they supported) into the distributed environment made possible by the net. Thus mail, linking, running of programs, moving of files have all been rethought in these new terms. This rethinking has been made scientifically interesting by two independent factors: the technical problems introduced by distribution, and the sociological problems introduced by trying to merge local communities of such disparate natures. The recent discussions of the MSGGROUP and HEADER-PEOPLE have made it quite clear that the potential for the taxpayer really getting his(her) moneysworth out of the network in the sociological domain is now beginning to be realized. For example, on the FINGER question, after the initial period of people hurling bricks at each other (a good indication in the research world that there is probably an interesting problem lurking about), the discussion turned to trying to figure out how to construct our environment so that the perceived needs of the various mmembers of the community could be met simultaneously. This produced some more careful analyses of what the needs of users (comunity-wide) were, and then some suggestions for mechanisms which would support these needs. The results may be difficult to implement on some systems. In fact they may not be implemented at all. But the ideas are invaluable. So, for me (and my tax dollars), the question is not whether the net should be run open or closed, but rather can it be used to discover (through use) what the real needs of a distributed heterogeneous user community, and to use the intuitions (produced by use) to suggest analyses of, and mechanisms for meeting, those needs. And one of the ways of answering whether the net CAN be run in such a way, is to show that it IS BEING run that way. To this end, the considerable effort being expended by members of MSGGROUP and HEADER- PEOPLE in discovering, articulating, and discussing the needs of this c0mmunity are invaluable. This kind of work is the stuff of which advances in the usability of computer systems are made. If you accept this analysis, then I have two suggestions: First, keep the brick-throwning stage to a minimum (although I will grant that the expression of the depth of feelings is important). And second, try to include in your thinking the needs of as wide a user-community as possible. In particular, think of the stupid and terrified users too. Austin ------- 5-Apr-79 14:08:27-PST,1498;000000000000 Mail-from: MIT-ML rcvd at 4-Apr-79 1915-PST From: Grm at Rand-Unix Date: 4 Apr 1979 at 1837-PST To: rwk at Mit-Mc cc: msggroup at Mit-Ml From the tty of: Gary R. Martins .:. Subject: MSGGROUP# 939 Decent Headers .:. Dear RWK - It seems a reasonable assumption that your comments and ideas are as valuable as those of any other member of this ethereal colloquium. If I've got the time to participate at all, I'd like to have available everybody's inputs and reactions. But, every time I (and my colleagues) get a msg without anything like a reasonable header on it -- like your recent msg on LINKS &c -- we have to go to extraordinary lengths just to unclog the local mail. That work is incurred WHETHER WE WANT TO READ YOUR MSG OR NOT! I suppose that sending out msgs with scrambled headers is easier -- i.e., less work for you -- than filling in all the blanks. Well, I surely don't want to impose any additional work on you. On the other hand, it hardly seems fair for you to gum up your recipients' systems, just to save typing a few chars. Yes ? Oh, sooner or later we'll probably get around to making our mail system more defensive, so that it can just discard wild char streams. Eventually, all networked systems will have to move in that dreary direction, I suppose. Meanwhile, have a heart! We indeed lose something exciting when we all drive on the right-hand side of the street, but think of the lives we save! Gary 5-Apr-79 14:08:27-PST,588;000000000000 Mail-from: MIT-ML rcvd at 4-Apr-79 2150-PST Date: 5 April 1979 00:37-EST From: Robert W. Kerns Subject: MSGGROUP# 940 Losing ITS headers! To: MsgGroup at MIT-ML cc: BUG-MAIL at MIT-MC Please accept my humble apologies for my losing headers. It is not my desire to send them, nor laziness, rather it's the necessity for remembering to do it. I HATE ITS HEADERS! I'm annoyed when I get them, myself. I have, as have many others, complained. But it's useless, everyone is too busy, and it's too hard to fix....so the ITS mailer's worst fault remains. 5-Apr-79 14:08:27-PST,3538;000000000000 Mail-from: MIT-ML rcvd at 4-Apr-79 2257-PST Date: 5 APR 1979 0135-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP# 941 "If you can send net mail you have no right Subject: to want anything else" To: msggroup at MIT-ML Even if you are lucky enough to know someone to send net mail to, that is not a sufficient way of being able to communicate. Sending net mail is like making a phone call on a phone with a broken speaker: there is no assurance that you have got through, that anyone is listening, that the person listening is who you think it is, etc. My attempt to get in touch with ANYONE@Utah came after my mail had not been answered. I handled the situation by running a SYSTAT and sending mail to all the users who were logged in, telling them about the same thing that I told MSGGROUP. This served two purposes: it gave me some chance of getting a response from a human, which is what I wanted, and it let them know how pissed off I was. I advocate this as a useful technique for such situations. Some people at the site may not like it; that just shows that you have succeeded in registering a complaint. Let nobody mention the Arpanet directory again, unless he can finr UTAH-20 in it. If it were there, the chance is about 50/50 that the liaison is the very person who I was trying to get in touch with in the first place. It would have been extremely useful to be told that I could get in touch with him through himself if I couldn't reach him directly. When I finally reached him, I asked for something that is a lot less than the basic minimums that have been proposed to msggroup (minimums that I agree with, and do not believe will be a burden for any site): just to have a program that I could run, as a non-logged-in user, that would send a message to someone of its own chosing (not specified by me), just so that I could get SOME human to talk to me and find out who I was and what I wanted. Such a program could have a list of people willing to deal with such requests and ask whichever of those people happened to be logged in. He refused. He has an exagerated idea of how much work it would be. It will be some work, I grant. But it is work everyone is obligated to do. If you think he might be justified, consider the analogous situation in which you have gone into a public restroom to find only a pay toilet -- and you had no change. If you were to complain to the manager, you know what he would say: "Hoards of randoms will come in from the Tips and dirty up the place; it will be lots of work to keep it clean; I can't possibly be obligated to do any work for anybody else". All three clauses are wrong. That the third one is wrong is the least obvious and most controvercial, but I think this is is a counterexample: in many cities, everyone is legally required to shovel his sidewalk when it snows. Since it isn't in any way a man's fault that snow falls on his sidewalk, this can't be thought of as a deserved punishment. It is simply work that people are required to do for their neighbors' sake. If clause three is believed, this law has to be immoral. Is it? In addition, the pay toilet's owner is insulting the public by considering them sloppier than they are, and exagerating their numbers, both of which serve as rationalizations. Let's decide that computers which won't let you get through to a live human being are in a class with pay toilets and unshoveled sidewalks. 5-Apr-79 14:08:28-PST,1217;000000000000 Mail-from: MIT-ML rcvd at 4-Apr-79 2320-PST Date: 4 Apr 1979 2253-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 942 Re: Losing ITS headers! From: STEFFERUD at USC-ISI To: RWK at MIT-MC Cc: MsgGroup at MIT-ML, BUG-MAIL at MIT-MC, rms at MIT-MC Message-ID: <[USC-ISI] 4-Apr-79 22:53:33.STEFFERUD> In-Reply-To: Your message of 5 April 1979 00:37-EST May I respectfully suggest that you consider the rest of us who must make up for your lack of care and "subject" courtesy, and just stop sending mail if you can't remember to do it right. It is clear to me from the constant appologizing from ITS sites, except for RMS who wears the lack of subjects like a badge of honor, that you really do not consider it important enough to bother with. If my logic is correct, you should consider not bothering us at all. Cheers - Stef PS: If I seem annoyed with you all, it is because I am. You make me do a lot of hard work to correct your messes for inclusion in the record of MsgGroup. PPS: May I further suggest that those of you who care begin sending subjectless junk mail in bundles to the offenders amongst us. Perhaps such an experession of disproval will get some notice. 5-Apr-79 14:08:28-PST,1276;000000000000 Mail-from: MIT-ML rcvd at 4-Apr-79 2347-PST Date: Wed, 4 Apr 79 23:37-PST Subject: MSGGROUP# 943 Re: "If you can send net mail you have no Subject: right to want anything else" From: Greep at Rand-Unix To: RMS at Mit-Ai (Richard M. Stallman) cc: msggroup at Mit-Ml Message-ID: In-Reply-To: Your message of 5 APR 1979 0135-EST How about Jake or someone (note the "one" - not a comittee, or it will never get done!) just deciding on a good mailbox name to use for this sort of thing. Hopefully at least most sites could make provisions for handling mail sent to this name such that someone would see it who would be reasonably likely to do something intelligent with it. Even those sites without any generalized mail aliasing could probably stick in a kludge just for this one name. For example, Rand-Unix has a mailbox name "liaison" for sending to the network liaison and "mother" for sending to the system mother. ISI has, or at least at one time, had a mailbox called "action" (although sending mail to it never seemed to produce any). I'm sure other sites have a similar concept, but each site has its own name. I'm not trying to advocate any particular name, just that there be one. 5-Apr-79 14:08:28-PST,3452;000000000000 Mail-from: MIT-ML rcvd at 5-Apr-79 0012-PST Date: 5 APR 1979 0237-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP# 944 How the ITS headers escaped and gave birth Subject: to HEADER-PEOPLE. To: msggroup at MIT-ML In the beginning, when KLH created the ITS mailer called COMSAT, he gave it the ability to format the header in several ways, which it does according to which sites the recipients are at and, for local users, what they have said in the mailer data base that they prefer to receive. However, it can do this only on the machine on which the message originates. It does not have the ability to reformat incoming messages. This is relevant when a message is sent, for example, to MSGGROUP@ML from AI. The mailer on AI knows only that the message is going to another ITS and makes an ITS header. The mailer on ML learns where the message is really going but then it is too late to do anything about it. The right way to fix this was to make the mailer know how to parse the headers of incoming mail. Then it could regenerate every message's header, individually for each recipient. Each person would receive all of his messages, wherever from, in his preferred format. All messages to non-ITS's would be put in the right format for them. All this was clear to KLH when the COMSAT was created. But when he thought about actually doing it, he saw that the header formats used by the various systems on the network were so different that his mind boggled at the idea of parsing them all reliably enough to make it part of delivering the message. He knew that, in order to make this plan feasible, he would first have to tackle the gargantuan task of standardizing the header format of network mail. He began a long-term approach to this problem by creating a mailing list for discussing standardization. It was called HEADER-PEOPLE. But, realizing that this would take eons to bear fruit, he created an interim facility whereby the sender of a message could specify the format to be used. For example, in this message I specified $VN for Net format header. $VR for RFC733 may also work. Someday, when Ragnarok comes and Twenex and Tenex adopt RFC733, KLH's many-year plan will finally be able to be completed. Who knows, this might even happen soon. But until then, people on AI who send to forwarders like MSGGROUP@ML must remember to say $VN. Unfortunately, no person can remember anything with 100% reliablility, especially when emotionally aroused, as by some flaming message from MSGGROUP or a computer system that says "You are an unperson" no matter what he tells it. Demanding that we cease to be human and stop ever forgetting is unlikely to achieve anything. I can't honestly promise I will never forget again. I can't say "I'll try", because that would imply that I can try harder than I have been. It has ALWAYS been my intention to send only net headers to non-ITS sites. For example, I had no idea until today that my original message about Utah-20 had an ITS header. Something that I do unawares, I can't promise to prevent. People must just accept my fallibility; or if they won't accept it, I will just accept their nonacceptance, since I can't do anything about it. So there things stand. I hope that this issue will not be allowed to distract everyone from all other issues, as it has in the past. 5-Apr-79 14:08:28-PST,406;000000000000 Mail-from: MIT-ML rcvd at 5-Apr-79 0029-PST Date: 5 APR 1979 0240-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP# 945 Liaison and Mother To: msggroup at MIT-ML, greep at RAND-UNIX I think this is a good idea, but sending mail to them is not enough. A person should be able to ask on line to speak to the liaison and the mother, even if he can't ask to speak to anyone else. 5-Apr-79 14:08:29-PST,864;000000000000 Mail-from: MIT-ML rcvd at 5-Apr-79 0837-PST Date: 5 April 1979 11:21 est From: Pogran.CompNet at MIT-Multics Subject: MSGGROUP# 946 Re: Liaison and Mother To: RMS at MIT-AI cc: MsgGroup at MIT-ML Message-ID: <790405162104.244596 at MIT-Multics> It would be nice to "link" to Liaison and/or Mother without being logged in BUT -- consider that many of our systems operate unattended "out of hours", with users logged in, but without someone responsible for the operation of the machine. On some systems (e.g., ITS's at MIT), late-night users might want to take turns subbing for Mother/Liaison, but at others no one might be willing to. That certainly shouldn't deter us from trying to implment tehe service, of course; we must realize that even with our best intentions, we can't guarantee that it will be there when we need it! Ken 5-Apr-79 14:08:29-PST,1384;000000000001 Mail-from: MIT-ML rcvd at 5-Apr-79 0906-PST Date: 5 Apr 1979 0838-PST From: Pickens at SRI-KL (John Pickens) Subject: MSGGROUP# 947 MSGGROUP storage efficiencies To: msggroup at MIT-ML All, For every flurry of message exchanges over the MSGGROUP distribution medium I picture the ARPANET hosts sinking a little under the weight of all that redundant storage. I recall discussing storage efficiencies in the early days of MSGGROUP, and, as a result, at least one central repository was earmarked for bulk storage of the dialogue. I agree with the need for multiple mailboxes, because of the difficulty in accessing mailboxes not on the local host. But those on a common host could coalesce their resources and share a common mailbox (for message receipt). This mailbox would require an administrator, and would be accessable in similar fashion to a bulletin board. Except for 1) message alert on newly arrived messages and 2) redefining "recent" to apply on a per user basis (for bboards) rather than a mailbox basis, this mode could work every bit as well as the multiple personal mailboxes mode per site that we are now in. Question: How many sites are actually operating in this mode now? How acceptible is this mode? Question: How many would like to get into this mode? (Particularly my neighbors on SRI-KL) John Pickens ------- 5-Apr-79 14:08:29-PST,842;000000000000 Mail-from: MIT-ML rcvd at 5-Apr-79 0959-PST Date: Thursday, 5 Apr 1979 1240-EST From: Philip L. Lehman (C410PL30) Subject: MSGGROUP# 948 Re: MSGGROUP storage efficiencies To: msggroup at MIT-ML Message-ID: <05Apr79 124025 PL30@CMU-10A> In-Reply-To: John Pickens's message of 5 Apr 79 11:38 CMU keeps a repository of all MSGGROUP, HEADER-PEOPLE and other related messages (TEMP:MSGGRP.MSG[A800RD00]@CMU-10A), which is perusable with our mail-reading program (RDMAIL). We find it convenient to have interested people remain in the MSGGROUP and HEADER-PEOPLE distribution lists. This allows them to read messages as they come in. However, these people usually then delete their personal copies of such messages, and can always go to the archive if they wish to read an old message. Philip 5-Apr-79 14:08:29-PST,716;000000000000 Mail-from: MIT-ML rcvd at 5-Apr-79 1049-PST Date: 05 APR 1979 1338-EST From: JZS at CCA (Joanne Sattley) Subject: MSGGROUP# 949 Re: MSGGROUP storage efficiencies To: MsgGroup at MIT-ML MsgGroup and Header-People mail is archived on CCA's Datacomputer using the MARS message archiving service - and can be retrieved by sending query messages to "MARS-Retriever@CCA". Archived mail is indexed by date, by any recognizable mailbox that appears on the message, and by words in the subject-field and text-body. An interactive program, called RR, is available (for TENEXes and TOPS-20s only, sorry) to help prepare and mail the query messages. Please let me know if you need a copy of it. ------- 5-Apr-79 14:08:30-PST,1580;000000000000 Mail-from: MIT-ML rcvd at 5-Apr-79 1116-PST Date: 5 Apr 1979 at 1250-CST From: david at UTEXAS Subject: MSGGROUP# 950 Special Interest BBoards To: msggroup at mit-ml In reference to John Pickens suggestion... We recently put up a bboard on our DEC-10 on an experimental basis. We expect this could be a means to reduce redundant storage of mail messages on our single system. But to be successful it requires: - convenient and flexible bboard perusal program - special interest bboards, or a way for the perusers to select items of special interest - and because our administration may not condone sponsoring bboards, we need user sponsored bboards. We use the POST program from CMU. We started out using their BBOARD peruser, but decided it is too big for what it does. So we use a TECO hack that's actually pretty nice. It records in a BB.TIM file in the user's directory, the name of a bboard and the date/time from the subject line of the last item viewed on that bboard. This simple mechanism allows anyone to keep track of their place on any number of bboards, which can be arbitrary files. For controlling posting of items, we can use the standard (under TOPS- 10) file daemon mechanism. So, for example, our user who wants a science fiction bboard can set it up in her directory and allow anyone to post items to it. If the CS department sets up a bboard, they might want to allow only CS accounts to post to it. The scheme has good possibilities for improving communications among our users with small costs. ------- 9-Apr-79 21:44:59-PST,7700;000000000001 Mail-from: STEFFERUD filed at 5-Apr-79 1415-PST Date: 5 Apr 1979 1415-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 951 SURVEY [ISI]PROCEEDINGS.MSG"901-#950 From: STEFFERUD at USC-ISI To: MSGGROUP at MIT-ML Message-ID: <[USC-ISI] 5-Apr-79 14:15:12.STEFFERUD> Redistributed-To: Katz at ISIE, finn at ISIE, Lawrence at SRI-KL Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 6 Apr 1979 -- Messages from file: [USC-ISI]PROCEEDINGS.MSG#901-#950;1 50 5 Apr david at UTEXAS MSGGROUP# 950 Special Interest BBoards (1580 chrs) 49 05 APR JZS at CCA (Joanne Sa MSGGROUP# 949 Re: MSGGROUP storage efficiencies (716 chrs) 48 Thursd Philip L. Lehman 753.TXT (677 chrs) 24 27 Mar Rick Gumpertz at CMU- MSGGROUP# 924 Re: A Survey of ARPANET Mail Systems -- (513 chrs) 23 26 Mar White at PARC-MAXC MSGGROUP# 923 Re: A Survey of ARPANET Mail Systems -- (833 chrs) 22 Thu, 2 Farber at UDEE MSGGROUP# 922 Multi-Channel Memo Distribution Document (29274 chrs) 21 Tuesda WANCHO at SRI-KA MSGGROUP# 921 Details on Stress Analysis Error from "CW" (1575 chrs) 20 19 MAR CBF at MIT-MC (Charle MSGGROUP# 920 An interesting new offering (2287 chrs) 19 19 MAR CBF at MIT-MC (Charle MSGGROUP# 919 certification of computer professionals (3004 chrs) 18 18 Mar MOOERS at BBN-TENEXA MSGGROUP# 918 Re: A Survey of ARPANET Mail Systems -- ... (825 chrs) 17 Sun, 1 Farber at UDEE MSGGROUP# 917 A Survey of ARPANET Mail Systems -- (3101 chrs) 16 Sun, 1 Dcrocker at UDEE MSGGROUP# 916 Dawning of a New Age? (1061 chrs) 15 Sun, 1 Farber at UDEE MSGGROUP# 915 An interesting new offering (1430 chrs) 14 18 Mar FJW@MIT-ML MSGGROUP# 914 FJW IN DEFENSE OF PROGRAMMER(S) (2330 chrs) 13 16 Mar COTTON at NBS-10 MSGGROUP# 913 On Reid's distribution of story on reactors (1444 chrs) 12 16 Mar lauren at UCLA-Securi MSGGROUP# 912 AP stories/certific ation (no flames!) (1114 chrs) 11 Friday Brian.K..Reid PROCEEDINGS.MSG#851-#900 (7579 chrs) 9-Apr-79 21:45:00-PST,3700;000000000001 Mail-from: MIT-ML rcvd at 5-Apr-79 1329-PST Date: Thursday, 5 Apr 1979 1459-EST From: Brian K. Reid Subject: MSGGROUP# 952 BBoards To: msggroup at mit-ml Message-ID: <05Apr79 145949 BR10@CMU-10A> In-Reply-To: david's message of 5 Apr 79 13:50 Redistributed-To: Katz at ISIE, finn at ISIE, Lawrence at SRI-KL Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 6 Apr 1979 We fight about BBoards a lot at CMU. That's because we use them extensively, and anything that people use a lot they will also fight about, simply because it represents a significant fragment of their daily working habits. Some people want computer bboards to behave like cork ones: they will actively go look at it every now and then. Others want computer bboards to be like public message files: every time a new message arrives in one of the public bboards, all interested parties should be told about it. Still others want the bboards to be like the loudspeakers in M*A*S*H -- droning out messages to everyone, whether they are interested or not. We haven't really got the manpower to build what we want, primarily because it would involve eextensive changes to our mail delivery program and certain changes to our monitor, both of which come hard around here. But we've got a reasonable compromise. (1) a "must see" bboard that gets printed at everybody when they log on, every time, even if they have seen it before. Always full of useless drivel. (2) A "community" bboard. If a user has requested thhe service, then all messages in the community bboard will be printed for the user in a fashion somewhat similar to the way his mail gets printed to him. Ideally we would like no distinction between private mail and bulletin board messages, both in terms of the notification mechanism and the way that people read current messages and retrieve old ones, but various technical and political difficulties make this unworkable. (3) A whole slew of special-intereste bboards. At last count there were about 15One for apartment rentals, one for hardware status news, several for detailed announcements of changes to popular software or operating systems, one for the AP news. We also gather bboards from around the net, so that interested CMU folks can follow the MIT or SRI or SAIL bboards. We know about more, but some seem to be more boring than others. What we really want is to eliminate the distinction between mailing lists andbboards. If, for example, I mail to some name like Hydra-People, which is a distribution list of people who care about Hydra, then right now the mail will be placed in their mailboxes, replicated N times. On the other hand, if I post in the Hydra bboard, then one copy of it will be stored, and all persons who have registered their interest in receiving the Hydra bboard will get those messages. The problem is really one of getting your listeners attention. Sometimes a person sending a message wants to make sure it comes to the attention of the intended recipients, so he uses mail instead of post. But if the two mechanisms were in fact one, and the "post" mechanism stored one copy of the mail in a public place and then tickled the mailboxes of all of the intended recipients so that it looked like they had new mail, then everybody would be happy. One of the properties of a public mailing list, invisible to the casual user, would be whether it was implemented as a "post and notify" list or as a "multiple copies of the message" list. Whew. This is a lot of verbiage. Brian 9-Apr-79 21:45:00-PST,1048;000000000001 Mail-from: MIT-ML rcvd at 5-Apr-79 1331-PST Date: 5 Apr 1979 1304-PST From: Zellich at OFFICE-1 Subject: MSGGROUP# 953 Re: Mail Storage Efficiency and BBoards To: msggroup at MIT-ML Redistributed-To: Katz at ISIE, finn at ISIE, Lawrence at SRI-KL Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 6 Apr 1979 How about that... what everybody is saying they want is the NLS (AUGMENT) Journal Mail system! For those of you who aren't familiar with this facility, it posts the mail to a central file system (one per host) and delivers a short (3 or 4 line) citation to each addressees Journal Mail file. Addressing is via NIC Idents, so special-interest groups can easily be addressed and anybody not part of a group can still look up items of interest (by author, titleword, or date) in a Journal Index file. Of course, this system isn't accessible except on OFFICE-1, OFFICE-2, or SRI-KL, but it's interesting to see that somebody's design was so close to the mark. ------- 9-Apr-79 21:45:00-PST,1351;000000000001 Mail-from: MIT-ML rcvd at 5-Apr-79 1513-PST Date: 5 Apr 1979 1438-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 954 Re: #953 Mail Storage Efficiency and BBoards From: STEFFERUD at USC-ISI To: Zellich at OFFICE-1 Cc: msggroup at MIT-ML Message-ID: <[USC-ISI] 5-Apr-79 14:38:45.STEFFERUD> In-Reply-To: Your message of 5 Apr 1979 1304-PST Redistributed-To: Katz at ISIE, finn at ISIE, Lawrence at SRI-KL Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 6 Apr 1979 HMmmm - Close but no cigar. In implementation, NLS Journal mail is not addressed via NIC Idents. It is addressed and delivered according to the contents of a private NLS (TYMSHARE MAINTAINED) file of NLS Journal addresses which is not kept in synch with the NIC IDENT FILE. ALAS! Also, the NLS file system is basically incompatible with RFC 733 mail and with sequential text files. We could ship all this sequential text mail into NLS and index it there, et al, but it would munge the formats and generally make it hard to read and hard to chew. But, I will agree that many of the concepts in the Journal Mail system are what we want. It is the failure to complete the concept by connecting it to the rest of the world with reliable and convenient transport and access paths that defeats it. Best - Stef 9-Apr-79 21:45:00-PST,2194;000000000001 Mail-from: MIT-ML rcvd at 5-Apr-79 1624-PST Date: 5 April 1979 18:50-EST From: Richard M. Stallman Sender: ___023 at MIT-AI Subject: MSGGROUP# 955 In case you assumed I knew the insides of COMSAT To: MSGGROUP at MIT-AI Redistributed-To: Katz at ISIE, finn at ISIE, Lawrence at SRI-KL Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 6 Apr 1979 I had no part in writing the ITS mailer, and haven't even read its code. Some of you may have assumed that I was conversant with it and could easily fix any problem in it if I had a mind to. This isn't so. If I were determined to work on it, I could read it and figure it out, just as with any other large complicated program. That would take a lot of determination first, and then a lot of time and effort. Since I have no shortage of things to do on programs I am already familiar with and can work on efficiently, I'd rather leave the work on the mailer to people who already understand it. However, while they are busy, I do think that when a clean solution to the problem of ITS headers leaking out becomes visible the manpower will exist to implement it. The problem is that the solution which was obviously the best, which is to reformat headers when forwarding, was not possible because headers were to nonstandard, and nobody wanted to do it crockishly. But if this becomes possible to do, or if someone has heuristics for parsing headers that appear to be robust enough to be used for this, then it can be done. On the other hand, there are people who think that unless we can guarantee that no ITS headers will ever arrive on other sites, we have to stop using ITS headers at all. This would be the tail wagging the dog. One or two messages every few weeks with ITS headers are not sufficient reason to compel a whole user community to change how it does things. Nobody would ever agree to implement this, busy or not. We would like to save other people the inconvenience of ITS headers, but we don't think that that inconvenience has sufficient gravity to justify or require such a large imposition on a much larger group of people. 9-Apr-79 21:45:00-PST,701;000000000001 Mail-from: MIT-ML rcvd at 5-Apr-79 1652-PST Date: 5 Apr 1979 1626-PST From: Stuart McLure Cracraft Subject: MSGGROUP# 956 Re: In case you assumed I knew the insides Subject: of COMSAT To: rms at MIT-AI Cc: msggroup at MIT-AI In-reply-to: Your message of 5-Apr-79 1550-PST Redistributed-To: Katz at ISIE, finn at ISIE, Lawrence at SRI-KL Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 6 Apr 1979 Having to say that whole thing every few months must get to be rather boring. You should have a stock reply in a file somewhere that you can just forward off to people who ask you about such things. ------- 9-Apr-79 21:45:00-PST,573;000000000001 Mail-from: MIT-ML rcvd at 5-Apr-79 1716-PST Date: 5 APR 1979 1936-EST From: SIRBU at MIT-MC (Marvin A. Sirbu, Jr.) Subject: MSGGROUP# 957 BBoards To: msggroup at MIT-ML, BR10 at CMU-10A Redistributed-To: Katz at ISIE, finn at ISIE, Lawrence at SRI-KL Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 6 Apr 1979 In a data-base message system environment such as DMS or CCA's COMET system, there wouldn't be the distinction between mailboxes and bboards that you speak about because ALL messages only exist in one copy. 9-Apr-79 21:45:00-PST,953;000000000001 Mail-from: MIT-ML rcvd at 6-Apr-79 0819-PST Date: 6 Apr 1979 0804-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 958 Re: In case you assumed I knew the insides Subject: of COMSAT From: STEFFERUD at USC-ISI To: rms at MIT-AI Cc: MSGGROUP at MIT-AI Message-ID: <[USC-ISI] 6-Apr-79 08:04:17.STEFFERUD> In-Reply-To: Your message of 5 April 1979 18:50-EST Redistributed-To: Katz at ISIE, finn at ISIE, Lawrence at SRI-KL Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 6 Apr 1979 The correct analogy is that ITS headers are like bad breath out here in the rest of the net. If you don't mind offending people with your bad breath, and don't mind telling peole that you refuse to brush your teeth just because you don't have time, well ... PS: It is a very good friend that will bother to tell one about his bad breath. If I did not care, I would ignore you. Stef 9-Apr-79 21:45:00-PST,1203;000000000001 Mail-from: MIT-ML rcvd at 6-Apr-79 0916-PST Date: Friday, 6 April 1979 1134-EST From: Brian.K..Reid Subject: MSGGROUP# 959 ITS headers To: MsgGroup at MIT-ML Message-ID: <06Apr79 113438 BR10@CMU-10A> In-Reply-To: <[USC-ISI] 6-Apr-79 08:04:17.STEFFERUD> It's no particular problem for us to read ITS headers, but they're a nuisance. Maybe the following thing could be hacked up. Nobody really wants to *send* these ITS headers; some people just want to *read* them. You don't care what format the message is in, you just want the thing that appears on your screen when you read it to look like an ITS header. Is it possible to modify the ITS mail *reader* to display an ITS header to the user even though the actual message is in some other format? Then the people who want to read ITS headers can have their way, and the rest of us who don't can have our way too. This is the solution that we at CMU have taken to the dots problem. We now put dots in our headers, but the mail reader will remove the dots from the names on display. This way I never have to look at the dots, but they're in the file in case somebody needs them. Brian 9-Apr-79 21:45:00-PST,422;000000000001 Mail-from: MIT-ML rcvd at 6-Apr-79 0957-PST Date: 6 Apr 1979 0823-PST From: Bair at SRI-KL (James Bair) Subject: MSGGROUP# 960 Re: MSGGROUP storage efficiencies To: Pickens, msggroup at MIT-ML cc: BAIR In response to the message sent 5 Apr 1979 0838-PST from Pickens@SRI-KL John, Sounds like a great idea to me. Paying for administrative labor is a major problem I think. Jim Bair ------- 9-Apr-79 21:45:00-PST,998;000000000001 Mail-from: MIT-ML rcvd at 6-Apr-79 1131-PST Date: 6 APR 1979 1408-EST From: KLH at MIT-MC (Ken Harrenstien) Subject: MSGGROUP# 961 Un(registered-mail-receipt) To: HEADER-PEOPLE at MIT-MC, (BUG MAIL) at MIT-MC To: (BUG CRTSTY) at MIT-MC, MsgGroup at MIT-ML It just struck me that despite general managerial dislike of the idea, I could have recently benefited from the feature (if it existed) of being able to tell the sender of a message whether the recipient has read it. My Header-people, MsgGroup, ITS, etc mail is all vectored to KLH@MIT-AI, and for the past 3 weeks I've been so crunched against the wall with local Deafnet hacking that I didn't read any of it. Hope silence hasn't been interpreted as indifference; there are certainly places where I ought to comment. Am catching up now (with 200-300 msgs), but just for the record, if there is something urgent (change to mailing list, fatal bugs in mail, etc) you may have better luck using KLH@SRI-KL. --Ken 9-Apr-79 21:45:01-PST,1551;000000000001 Mail-from: MIT-ML rcvd at 6-Apr-79 1508-PST Date: 6 April 1979 17:49-EST From: Richard M. Stallman Subject: MSGGROUP# 962 ITS mail reading is very primitive Sender: ___074 at MIT-AI To: MSGGROUP at MIT-AI (THIS TTY HAS NO LOWER CASE) THE MAIN WAY OF READING MAIL ON ITS IS BY PRINTING THE FILE. THERE IS A SPECIAL COMMAND TO FIND A PERSON'S MAIL FILE, SO NO USER-INTERFACE CHANGES WOULD BE NEEDED FOR THE SORT OF REFORMATTING THAT REID SUGGESTS. BUT RIGHT NOW THE THING DOESN'T EVEN NOTICE WHERE ONE MESSAGE ENDS AND THE NEXT BEGINS. SOME PEOPLE DON'T USE ANYTHING ELSE. OTHERS USE RMAIL WHEN THEY WANT TO EDIT THE MAIL AND DELETE ONLY SOME OF IT. RMAIL COULD NOT BE MADE TO REFORMAT MESSAGES REASONABLY. THIS IS NOT JUST A GUESS. A SUBROUTINE HAS ALREADY BEEN WRITTEN WHICH PARSES HEADERS FOR THINGS LIKE SUMMARIES AND REPLIES. THIS IS SO SLOW THAT I NEVER USE EITHER OF THEM. IF JUST GOING TO THE NEXT MESSAGE WERE THAT SLOW IT WOULD BE UNUSABLE. AN ALTERNATIVE TO RMAIL EXISTS THAT REFORMATS ALL HEADERS ONCE AND FOR ALL WHEN A MESSAGE IS FIRST SEEN, AND KEEPS VARIOUS INFO THERE. ITS USERS ARE ALL ON THE KL. I DOUBT THAT IT WOULD BE ACCEPTABLE ON THE KA'S. THE REASON FOR THIS SLOWNESS IS THAT THEY ARE WRITTEN IN TECO. BUT ANY OTHER SORT OF MAIL EDITOR WOULD NOT BE USED BECAUSE PEOPLE WOULD PREFER THE ONES THAT LET THEM EDIT REPLIES WITH THEIR ACCUSTOMED EDITORS, ALSO WRITTEN IN TECO. TECO DOES ESPECIALLY BADLY AT THIS SORT OF TASK (PARSING) FOR THE SAME REASONS THAT APL WOULD. 9-Apr-79 21:45:01-PST,1088;000000000001 Mail-from: MIT-ML rcvd at 6-Apr-79 1849-PST Date: 6 April 1979 21:25-EST From: Charles Frankston Subject: MSGGROUP# 963 Re: "Not-Logged-In" use and helpfulness of Subject: ARPANET hosts To: MSGGROUP at MIT-MC During the discussion of this issue, MRC happened to mention that a lot of Unix sites supported a special name of who to their login program that allowed one to get a list of logged in users. A quick check revealed to me that indeed, most Unix sites spend most of their time down, but of those that weren't, about half did support these conventions. This would have been useful to me several times in the past. Similarly, various persons, like Ken Pogran have been careful to point out how MIT-Multics is run by a business organisation, and obviously cannot have the types of services RMS is requesting. I just thought I'd mention to those who may draw the wrong conclusions, that MIT- Multics does support RSEXEC who and RSEXEC network links and has a "liason" mailbox that should be able to answer questions. 9-Apr-79 21:45:01-PST,603;000000000001 Mail-from: USC-ISI rcvd at 6-Apr-79 1947-PST Date: 6 Apr 1979 1946-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 964 Re: #962 ITS mail reading is very primitive From: STEFFERUD at USC-ISI To: RMS at MIT-AI Cc: MSGGROUP at MIT-AI Message-ID: <[USC-ISI] 6-Apr-79 19:46:03.STEFFERUD> In-Reply-To: Your message of 6 April 1979 17:49-EST I think it is very important to note that ITS users, as described by RMS, appear to simply use text editors to read their mail. I wonder if the comments and recomendations coming from ITS users are the product of such limited experience. Stef 9-Apr-79 21:45:01-PST,2229;000000000001 Mail-from: MIT-ML rcvd at 6-Apr-79 2202-PST Date: 6 April 1979 23:57-EST From: Charles Frankston Subject: MSGGROUP# 965 RE #964 ITS mail reading very primitive? To: STEFFERUD at USC-ISI cc: MSGGROUP at MIT-MC Firstly, RMS wasn't saying that all ITS users read their mail in a text editor. What he was saying, was that when contemplating changes to the way mail works on ITS, he had to accomodate those users who didn't even use the editor to read their mail, but rather simply printed the file out on the terminal. I fail to see why this shocks you so. On every computer system I have worked there have been users who are deathly afraid of anything as complicated as a mail reading program. In fact since many of our users are on high speed hardwired terminals, it can be a rather effective way of reading one's mail. I seem to remember certain people arguing that headers should be kept down to a minimum because they always read their mail with TTY33's and couldn't possibly afford any other terminal (or they read their mail from silent700's in the midst of Yellowstone park). As to the issue that we are so "primitive" as to read our mail with "text editors", at least my text editor can correctly parse RFC-733 headers. That's more than I can say for the mail reading program that is used by most Tenex users, which undoubtedly had an order of magnitude more manpower put into it than my text editor. Of course, saying that ITS users read their mail with a text editor is a bit like my saying MSG users read their mail with Macro-10. It just so happens that two mail reading programs on ITS are written in Teco. Considering some former ITS users have carried one of them to Tenex rather than use anything available there, I sincerly doubt any of our users would use the tools you claim to be so much above our primitiveness even if they were available here. Btw, I remember you complaining about all the effort you had to spend reformatting ITS headers and subjectless headers etc. to generate your MsgGroup logs. For a small fee, I might be willing to reformat every message in the log to whatever format you desire using our primitive text editors. 9-Apr-79 21:45:01-PST,1000;000000000001 Mail-from: MIT-ML rcvd at 6-Apr-79 2223-PST Date: Fri, 6 Apr 79 20:31-PST Subject: MSGGROUP# 966 Re: "Not-Logged-In" use and helpfulness of Subject: ARPANET hosts From: Greep at Rand-Unix To: CBF at Mit-Mc (Charles Frankston) cc: MSGGROUP at Mit-Mc Message-ID: In-Reply-To: Your message of 6 April 1979 21:25-EST It is true that MIT-Multics supports network links through server rsexec, but the default is to refuse, and as I understand it the user has to not only allow links but also allow each particular link. I've never found anyone who knew what all these commands were, so in practice the feature does not seem to be too useful. I think the ITS system is much better. When a new luser logs in there are usually so many people spying on his terminal that he doesn't have to ask questions, someone will tell him what he's doing wrong. This spares him having to get up the nerve to bother someone with problems. 9-Apr-79 21:45:01-PST,818;000000000001 Mail-from: MIT-ML rcvd at 6-Apr-79 2224-PST Date: 6 April 1979 23:37-EST From: Charles Frankston Subject: MSGGROUP# 967 "Not-Logged-In" use and helpfulness of Subject: ARPANET hosts To: greep at RAND-UNIX cc: MSGGROUP at MIT-MC Hmmm. You're right, I had the mistaken impression of the state of Multics Rsexec links nowadays. Apparently a user does have to explicitly accept them. (Which is not surprising, but I thought that perhaps this implicitely happened when he accepted normal Multics messages). However, this is not so much due to concious decision right now as the age of the implementation. In fact, I have been informed it doesn't even work anymore. Oh well. Multics does support FTP XSEN protocol however, which can be used for the same purpose. 9-Apr-79 21:45:01-PST,567;000000000001 Mail-from: MIT-ML rcvd at 6-Apr-79 2225-PST Date: Fri, 6 Apr 79 20:42-PST Subject: MSGGROUP# 968 Re: How the ITS headers escaped and gave birth Subject: to HEADER-PEOPLE. From: Greep at Rand-Unix To: RMS at Mit-Ai (Richard M. Stallman) cc: msggroup at Mit-Ml Message-ID: In-Reply-To: Your message of 5 APR 1979 0237-EST Why would it be necessary for the ITS mailer to recognize (and reformat) all headers? Why not just look for ITS headers and handle them? Anything else could get sent out as is. 9-Apr-79 21:45:01-PST,803;000000000001 Mail-from: MIT-ML rcvd at 6-Apr-79 2225-PST Date: 6 Apr 1979 2112-PST Sender: GEOFF at SRI-KA Subject: MSGGROUP# 969 Re: "Not-Logged-In" use and helpfulness of Subject: ARPANET hosts From: the tty of Geoffrey S. Goodfellow To: CBF at MIT-MC Cc: greep at RAND-UNIX, MSGGROUP at MIT-MC Message-ID: <[SRI-KA] 6-Apr-79 21:12:58.GEOFF> In-Reply-To: Your message of 6 April 1979 23:37-EST Reply-to: Geoff @ SRI-KA Several 10X and 20s also support XSEN, currently i believe only SRI-KL, SRI-KA, OFFICE-1,2&3 & SU-SCORE and maybe some of the BBN systems. Using XSEN in conjunction with RSEXEC SSINF (WHO) and netmail to Liaison@at-site-in-question seems to dothe job just fine. However, its might be worthy of note that Utah-20 doesn't support any of the above.... 9-Apr-79 21:45:01-PST,360;000000000001 Mail-from: MIT-ML rcvd at 6-Apr-79 2237-PST Date: 7 APR 1979 0109-EST From: JNC at MIT-MC (J. Noel Chiappa) Subject: MSGGROUP# 970 Huh??? To: stefferud at USC-ISI CC: msggroup at MIT-ML If you are under the impression that RMAIL (or its successor, BABYL, also written in TECO) is an editor, then it seems that you are badly mistaken. Noel 9-Apr-79 21:45:01-PST,422;000000000001 Mail-from: MIT-ML rcvd at 6-Apr-79 2251-PST Date: 7 APR 1979 0113-EST From: JNC at MIT-MC (J. Noel Chiappa) Subject: MSGGROUP# 971 Mating habits of waterfowl (sorry, D.M.) To: greep at RAND-UNIX CC: msggroup at MIT-ML If you think that the underutilized hackers around here spend all their spare time "spying" on tourists' consoles, then I have some land in Florida I'd like to interest you in... Noel 9-Apr-79 21:45:01-PST,1380;000000000001 Mail-from: MIT-ML rcvd at 6-Apr-79 2309-PST Date: Fri, 6 Apr 79 22:54-PST Subject: MSGGROUP# 972 Re: Mating habits of waterfowl (sorry, D.M.) From: Greep at Rand-Unix To: JNC at Mit-Mc (J. Noel Chiappa) cc: msggroup at Mit-Ml Message-ID: In-Reply-To: Your message of 7 APR 1979 0113-EST If you think that the underutilized hackers around here spend all their spare time "spying" on tourists' consoles, then I have some land in Florida I'd like to interest you in... Noel Calm down, I wasn't trying to insult anyone. I was just referring to my experiences when I first started hacking ITS - frequently when I was trying to figure out how to do something a mysterious message would appear on my screen from some beneficent (and knowledgeable) user providing me with instructions. Other people have mentioned having similar experiences. I did not say that these helpful gremlins were MIT people wasting their time letting their eyes wander instead of accomplishing wonderful hackages - in fact I did not say they were MIT people at all. In my early ITS hacking stage I didn't know who was who so it is entirely likely that my mentors were other, more experienced, tourists on the system. I'm not planning on moving to Florida, but if you should by any chance need a nice bridge in Brooklyn... 9-Apr-79 21:45:02-PST,1293;000000000001 Mail-from: MIT-ML rcvd at 7-Apr-79 0144-PST Date: 6 Apr 1979 2301-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 973 Re: Huh??? From: STEFFERUD at USC-ISI To: JNC at MIT-MC Cc: msggroup at MIT-ML Message-ID: <[USC-ISI] 6-Apr-79 23:01:10.STEFFERUD> In-Reply-To: Your message of 7 APR 1979 0109-EST No, I do not think RMAIL or BABYL are editors. I was responding to the content of the RMS message which described ITS users as simply printing their messages linearly with a editor for cutting and printing, or whatever. By the way, I am an EMACS freak too, and love it for what it does, but when it comes to handling mail, cutting and pasting at the text stream level does not do it for my filing needs. I am also looking at things beyond the level of hacker/users. My work involves the transfer of these technologies into organizations and businesses that will not tolerate a need to think in editor terms to get the work done. I realize that one can in fact use an editor, with added bells and whistles to do every thing. This derived from the Turing experiment. EMACS is a Turing Machine. It can do anything. This does not mean that I should. Or is it really true that the triumph of technology is: "CAN IMPLIES SHALL!" Best - STef 9-Apr-79 21:45:02-PST,763;000000000001 Mail-from: MIT-ML rcvd at 7-Apr-79 0402-PST Date: 7 Apr 1979 0351-PST (Saturday) From: lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP# 974 "Can Implies Shall" To: Stefferud at ISI CC: MsgGroup at ML Stef, I'm afraid that for many people, "Can Implies Shall" is exactly what technology is all about. The ability to deal with technical subjects without invoking this idea is the difference between the true "technocrats" -- the truly dangerous people, and reasonable human beings who happen to work in technical areas, but are still concerned with the impact of their work on the overall fabric of society. I wonder what sort of breakdown into the two groups we would find for ARPANET type people? --Lauren-- ------- 9-Apr-79 21:45:02-PST,6788;000000000001 Mail-from: MIT-ML rcvd at 7-Apr-79 0512-PST Date: 7 April 1979 07:31-EST From: Richard M. Stallman Subject: MSGGROUP# 975 Long dry and grim message. Subject: I'm too angry to be sarcastic now. To: MSGGROUP at MIT-AI I will discuss these things: A) The falacies of Stefferud's last message B) How such messages form a pattern which creates a dilemna for me C) The difference between a mistake and a sin. I have noticed a pattern of falacious reasoning that Stefferud uses frequently. Here is an outline of his latest message, which I will analyse: 1) X offers (among other things) the power of a Turing machine. 2) To do something that involves programming requires much thought. 3) Doing any common, typical operation with X must be complicated 4) X is only good for hackers, and is of no value to ordinary users. 5) Anyone who advocates X has no concern for unsophisticated users. 6) Anyone who advocates X must think that X is good only because it is powerful, without regard to utility. Steps 3, 6 and 7 are falacious. Things are clouded by the presence of a factual misunderstanding as well. None of the three ways of processing mail that I described was to "cut and paste" if that means just reading a mail file into EMACS and editing it. Mail file reading "using" the editor is done with the programs RMAIL and BABYL, written in TECO (as EMACS is), which implement special command loops with commands especially for dealing with mail files (next message, delete, file elsewhere, reply, etc). RMAIL and BABYL call EMACS as a subroutine whenever text (such as a reply) has to be input. EMACS can also be used to edit the text of a message if the user asks for that. Ths common mail operations are as easy as they could be. Now, doing things the way Stefferud thought we do would indeed be less convenient. However, his further conclusions would still not follow. It would still be the case that common operations - the operations of everyday editing - have been programmed already, so that actual use does not involve doing any programming, any more than rearranging any other file with the editor. EMACS is NOT a Turing machine (It is not possible to write programs in EMACS, as opposed to TECO). It is a program written in one (Teco), which does not insist on totally cutting the user off from the Turing machine in case he should want to get to it. It allows the power of the underlying Turing machine to be available without thereby being hard to use for the sorts of thing that would be possible at all with an alternative. Looked at another way, the Turing power in EMACS made it possible to write RMAIL so that it could use the packaged operations of EMACS. Thus, the Turing power of TECO is being useful to all the unsophisticated users who use RMAIL, even if they don't know it's there. Appealing to the imaginary needs of the unsophisticated user is very common as a justification for computer system misfeatures and lacunae which benefit no user at any level of sophistication. Steps 6 and 7 attribute a motivation based on an action: If X will produce Y, and Z does X, Z must want Y. This is always risky, and in this case it happens to be wrong. The conclusion only follows if Z BELIEVES that X will produce Y. Even if my belief that the Turing power is useful turns out to be wrong in some sense, it is still factually incorrect that I was motivated by a desire to do things just because they can be done. I believe that having EMACS to edit replies with is useful for people of all levels of sophistication, and that belief remains a fact even if what I believe is wrong. (There is ample evidence that it's right.) Not everything that can be done should be done; but this doesn't imply that nothing should ever be done. The principle is of no help in making any decision. Any argument that appeals to it is suspect. It is relevant only when someone actually says "because it can be done" as a reason. This has got very far from the "original" topic of ITS headers, which was itself a digression. It seems that every time I send a message, somebody misinterprets it as something absurd, and points out the obvious absurdity. When this happens I have the choice of answering and creating a digression that is just a waste of time for most people in MSGGROUP, or not answering and fearing that I am letting other people, who have no first-hand knowledge, be misled the misinterpretation is the truth. For example, I didn't want anyone to go off thinking that I actually process mail in the way Stefferud criticized. I have just received a message from one person who seems to have done so. How is a person who has never used ITS, RMAIL or EMACS to know how Stefferud was wrong? I feel a great compulsion to make sure that everyone understands the nuances of anything that I am explaining. What am I to do about this? Perhaps I can in the future just send a message saying "X's message involved a misunderstanding. The things he is criticizing do not exist. If anyone isn't sure what actually exists, ask me," if this will suffice to prevent them from being carried along by X's mistake. I notice that the frequency of such factual misunderstandings is highest at times when people are emotionally antagonistic to what I say. My theory is that people who would like to criticize something often jump at a chance to misunderstand it so that it becomes more open to criticism. This is a tendency that I have also seen in myself. I decided to work consciously against it in myself. Other people can certainly do so also. (Note: I know that, if this were taken as an argument or proof, it would be an example of the same falacy as steps 6 and 7 above. I do not intend it as a solid argument. It is a generality which I know might be false in any particular case). Finally, since it seems I have never actually said this to anyone but Stefferud, I was convinced by him a couple of months ago that there was a good reason for having subjects in msggroup mail. I therefore decided at the time to put them in. I never thought of this as worth announcing to anyone. But it has become apparent that I am going to forget them continually, especially when I am aroused about some issue. These are mistakes, and I might have been willing to apologize for them as minor mistakes. But when it happens I find that people consider it a major sin; they upbraid me and tell me that it was shameful. I resent this. I don't think it is shameful, or of great significance, and I refuse to apologize for it as if it were, because that would be to assent. I refuse to be ashamed. 9-Apr-79 21:45:02-PST,1644;000000000001 Mail-from: MIT-ML rcvd at 7-Apr-79 0549-PST Date: 7 Apr 1979 0536-PST Sender: SDSAN-DMS at SRI-KA Subject: MSGGROUP# 976 Re: Long dry and grim message. Subject: I'm too angry to be sarcasti... From: SDSAN-DMS at SRI-KA To: RMS at MIT-AI Cc: MSGGROUP at MIT-AI Message-ID: <[SRI-KA] 7-Apr-79 05:36:03.SDSAN-DMS> In-Reply-To: Your message of 7 April 1979 07:31-EST I am in complete accord with RMS. I generally watch new flurries in MSGGROUP with a great deal of interest at the beginning of the series. Then as someone is unable to make the point they wish to make, they resort to personal attacks. There is a great tendency on the net to consider what all others do, who do not do as you do, to be hacking - and to consider what you do to be innovative. It would be much more constructive if the initial issues in a series of messages on a subject could be addressed rather than diverting to something you are more familiar with, such as slinging mud. As for ITS, EMACS, HERMES, RMAIL, MSG, BANANARD, etc, I have used most of them and used them as a naive user most of the time. It seems to me that each one was the most appropriate for me in the circumstances under which I was using it. I once served as "moderator" or whatever you might call it for a scaled down version of MSGGROUP and was advised by the MSGGROUP "moderator" that my task was to stay in the background instead of participating so much. I took the advice literally. The group disappeared, which was maybe where it should have gone initially. I now return that advise, since I no longer need it. Tom 9-Apr-79 21:45:02-PST,2026;000000000001 Mail-from: MIT-ML rcvd at 7-Apr-79 0958-PST Date: 7 Apr 1979 0939-PST From: Mark Crispin Subject: MSGGROUP# 977 MSG To: MsgGroup at MIT-ML To correct a misstatement; MSG is not written in assembly language. MSG is written in SAIL, a "higher-level language" of the ALGOL persuasion. From the viewpoint of a subsystem implementor, it is big (a subsystem written in it is at least 2-3 times the size of the equivalent assembly language code), hard to debug (BAIL just doesn't make it over DDT, but DDT is pretty much useless in SAIL programs), and violates just about every operating system convention in the book. On Tenex, you can add lots of extra page faults since SAIL doesn't know that there is such a thing as locality of reference. Still, people insist that one should program this way. In any case, MSG should not be blamed on assembly language programmers. I wish to point out that MM, which in my opinion is the neatest mail system for Tops-20, is written in assembly language. I don't want to get into a debate about assembly language vs. "high- level" languages; so let me turn to another question, that of performance. RMAIL was once a very fast subsystem. Being written in display TECO made it that much nicer when it came to composing replies. As time passed, more and more people added more and more features to RMAIL without giving sufficient consideration to performance. After all, computers are getting faster, so why care about writing efficient subsystems? Unfortunately, the computer that one is forced to use tends to remain static in terms of compute power over long periods of real time. RMAIL became grossly slow such that now I agree with RMS that it is unusable on the slower KA machines. Can we see some consideration for performance in future mail systems and protocol designs? It doesn't mean a sacrifice of human engineering; usually the best human-engineered programs are often the best in performance as well. 9-Apr-79 21:45:02-PST,894;000000000001 Mail-from: MIT-ML rcvd at 7-Apr-79 1058-PST Date: 7 April 1979 13:46-EST From: Robert W. Kerns Subject: MSGGROUP# 978 STEFFERUD's lack of tact, "Bad Breath", indeed! To: MSGGROUP at MIT-MC Give me a good soul with bad breath over a difficult personality, any day. I think Stef's using the wrong analogy; I think he's laughing at someone with a speech impediment. Pointing out the error is one thing; that would have taken one line, or could be done with a modicum of humor, as Grm did. For Stef to jump on the bandwagon to try to grind it into me I find rather unfriendly, and far more offensive than bad breath! [Stef: Sorry to flame back over MsgGroup, but you persist in trying to make me the fool via this medium! I wish the rest deserve to know I'm not just sitting here groveling in silence, but have replied in private.] 9-Apr-79 21:45:02-PST,1333;000000000001 Mail-from: MIT-ML rcvd at 7-Apr-79 1134-PST Date: 7 Apr 1979 1116-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 979 Re: STEFFERUD's lack of tact, "Bad Breath", Subject: indeed! From: STEFFERUD at USC-ISI To: RWK at MIT-MC Cc: MSGGROUP at MIT-MC Message-ID: <[USC-ISI] 7-Apr-79 11:16:00.STEFFERUD> In-Reply-To: Your message of 7 April 1979 13:46-EST You are correct in several ways. 1. My bad breath message was atrocious in public. It was intended to be pivate when I sent it by error to the group. I apologize fully but cannot take it back out of the record. And my apology will not be much help either since the error was one of carelessness and showed lack of consideration for the involved parties. 2. I liked GRM's mode and tone better than mine too, but that was the first of his efforts to deal with it compared to my two years worth of trial. 3. You are correct in feeling put upon by my lumping you in with the ITS group, what ever that may be, if it exists. In your side messages I find your efforts to sort the issues and smooth things out to be very helpful. I accept your castigation here, and ask that we retire from public to sort out the rest of it. Best - Stef 9-Apr-79 21:45:02-PST,5894;000000000001 Mail-from: MIT-ML rcvd at 7-Apr-79 1220-PST Date: 7 Apr 1979 1103-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 980 Re: Long dry and grim message. Subject: I'm too angry to be sarcasti... From: STEFFERUD at USC-ISI To: SDSAN-DMS at SRI-KA Cc: RMS at MIT-AI, MSGGROUP at MIT-AI Message-ID: <[USC-ISI] 7-Apr-79 11:03:08.STEFFERUD> In-Reply-To: <[SRI-KA] 7-Apr-79 05:36:03.SDSAN-DMS> Yes Tom, I did advise you to cut back on your effort to respond conclusively to each message entered in that other conference you mention. I have also tried to start up some similar message conferences with no success, either by being quiet or being noisy. MSGGROUP has a life of its own, and I am not sure I know what its life sources are. The dynamics are extremely complicated and defy unravelling without a large and educated effort. This is one reason I am trying hard to maintain the record of this group as I am. Someday someone may have the time and inclination to research it out. In doing my coordinating job, as a volunteer because I think it is important and valuable to the community, I find that certain things done by participants cause me larger than expected difficulties. One of these is the lack of subject fields. Another is ragged formats that exceed 72 character line lengths. ITS Headers are a very special annoyance because they must be carefully dissected with XED (EMACS is not available on ISIA) or some other editor. Manual editing is required because the repair problems are very complex and not subject to automation. As things work now, I must edit all messages outside HERMES because HERMES will not do the surgery that is needed on the headers. Then I must bring them back into TENEX message format standard compliance. The problems with HERMES include loss of various fields with the EXPLODE command which, in my opinion should never lose anything when it is being used to modify or annotate a received message. Please note carefully that I find HERMES to be quite deficient. Another problem is that TENEX puts a non-standard line at the top of the header of each new message (the "mail from" line) which causes other systems to hiccup when I REDISTRIBUTE MSGGROUP mail to UNIX sites. I repair these in all received MSGGROUP mail by converting "Mail from" to be "Mail-from:" so your various message systems with think it is a legal header field. HERMES won't repair these automatically, and won't let me touch that field with the EXPLODE command, so I must do it manually with an editor. I am not facile enough with TECO to create a set of macros for this task. The list of little technical hangups is longer than his but I don't have time just now to fully delineate them here. As I see it, I am caught in my MSGGROUP administration task at the vortex of the convergence of computer, communication and office technologies, and I am paying for this through having to manually adjust for the inconsistencies and incompatibilities of the many different message systems out there. I must accommodate to all the sending and all the receiving incompatibilities on behalf of the members of MSGGROUP, both current and future. Now then, perhaps my efforts are wasted. A frequent thought at times. People ask me every now and then why I do it. My reply is that this discussion seems to have some real information buried in its noise, which does not seem to be captured anywhere else. I believe it is worth recording and I am doing it for this reason. The volume of mail and the expanding membership indicate that there is real demand for the services I render, so I continue. Since I am doing it as a volunteer, and since my time is as limited as everyone else in this forum, I have asked those who cause special difficulties for me to help by not sending problem messages to me. Generally, everyone has agreed to cooperate, with one notable exception, and this exception has demanded that I fully explain to his satisfaction why I want what I want. And he refused for a very long time to put subject fields in his messages to MSGGROUP. According to his last message he intends to continue this practice of forgetting them when he is in emotional dump mode, which I regard as simple and deliberate discourteousness at best. And it clearly annoys me. For the record, when I receive a subjectless message in MSGGROUP, I invent one of my own chosing, on the assumption that you have left me to do as I please. I will continue the practice of being provocative. If you don't like what I do, the solution is simple and obvious. In my sparing with RMS of this issue, things have gotten quite heated at times, as you may well realize from your own experiences. The sparing has spilled over into MSGGROUP. For this I apologize with the same seriousness and depth of feeling that RMS shows in his continuing apologies for his forgetfulness. In fact, my reply to him about bad breath got into MSGGROUP by mistake when I failed to note in haste that I was replying to a public message. It was gone before I could stop it. It was in bad taste in public and I apologize for it. I must note at this point that apologies do not substitute for good etiquette and the avoidance of offensive actions by me or anyone else. One hallmark of civilized behavior is the exercise of care to avoid offending others by our forgetfulness. No volume of apologies will make up for continued lapses accompanied by declarations that apologies are the best we can expect since the offender is to preoccupied with something to be bothered. I believe that etiquette is a higher order protocol to be called upon here and now. (Yes there are more than 7 levels!) Sorry bout all this but it is part of the record here. Best regards - Stef 9-Apr-79 21:45:03-PST,2759;000000000001 Mail-from: MIT-ML rcvd at 7-Apr-79 1318-PST Date: Saturday, 7 April 1979 1555-EST From: Brian K. Reid Subject: MSGGROUP# 981 MsgGroup administration To: The Infamous Message Group Message-ID: <07Apr79 155526 BR10@CMU-10A> In-Reply-To: <[USC-ISI] 7-Apr-79 11:03:08.STEFFERUD> I'm curious. Does anybody out there really have a terminal that's limited to 72 characters? I always very carefully format my messages to have a 79-char right margin (some terminals auto-crlf if you try to print in position 80). If this 72-character limit is real, then I'll gladly switch to it. Now, on another topic: the fast draw. I think that all of us who use netmail a lot have noticed that people tend to be more savage than they really mean when they're shooting back and forth via netmail. This is probably one of the major non-intuitive things that I've learned about the sociology of network communication by being actually involved with it. There's a certain body of literature on network communication, most of it coming from Murray Turoff and his people, in which they comment at great length about how people behave in computer conferencing, and they have never mentioned this fact. Or rather I have never seen them mention it. Now the computer conferencing that the sociology people write about all the time is much more primitive than ARPAnet conferencing, in that the computer is just a conferencing tool and not the primary instrument of daily work, as it is for all of us. But the quick-draw temper syndrome that even reasonable people fall into is very interesting, and is one of the major drawbacks to netmail as a primary communications medium. Maybe someday when the word "computer conferencing" starts meaning "ARPAnet conference" and not "Delphi Conference" then someone will venture to formalize and analyze and explain why we're always at each other's throat. I think that one of the reasons that Header-People always got more emotional than MsgGroup was that MsgGroup mail was delayed by Stef while Header-People mail was instantly rebroadcast by the repeater at MC. There's something about the delay in Stef's manual forwarding that prevented MsgGroup from getting emotional very often. Now that there's a repeater for MsgGroup, you will note that the emotional tone of MsgGroup has come to resemble the Header-People of olden days: a whole order of magnitude more messages, often flaming. Now I find this much more interesting -- I enjoy listening to flaming at times, and am quite capable of using autoflush when I don't want to listen to it -- but we might want to consider whether this change in tone of MsgGroup is for the better. Brian 9-Apr-79 21:45:03-PST,1069;000000000001 Mail-from: MIT-ML rcvd at 7-Apr-79 1348-PST Date: 7 April 1979 16:34-EST From: Richard M. Stallman Subject: MSGGROUP# 982 We're better off without the flaming To: MSGGROUP at MIT-AI As one who is in some sense a major contributor to the flaming in msggroup, though without having that as my intention, I think that Brian is likely to be right about the cause of the flaming, and in any case that one is better off without it. Maybe we should go back to not using the automatic forwarder. Aside from effects on amount of flaming, the presence of Stefferud@ISI as one of the recipients of a message would automatically prevent an ITS header from being used. Part of the reason that header people had more flaming was just that I, and maybe other people, knew that it had more flaming and so figured that that was the appropriate place to transfer flaming to. We figured that the people on header-people were the ones who had decided to participate in flaming and the ones who put themselves on msggroup were those that didn't. 9-Apr-79 21:45:03-PST,484;000000000001 Mail-from: MIT-ML rcvd at 7-Apr-79 1405-PST Date: 7 Apr 1979 1345-PST From: Mark Crispin Subject: MSGGROUP# 983 flaming To: MsgGroup at MIT-ML Yes, let's go back to the old way of sending it to ISI and letting Stef administer it. I think there is a place for flaming and there is also a place for more reserved discussions, just as there is a place for both open and closed-door systems. They all serve necessary and valid purposes. ------- 9-Apr-79 21:45:03-PST,424;000000000001 Mail-from: CMU-10A rcvd at 7-Apr-79 1408-PST Date: Saturday, 7 April 1979 1707-EST From: Brian K. Reid Subject: MSGGROUP# 984 Manual vs. Automatic reforwarding To: MsgGroup at USC-ISI Message-ID: <07Apr79 170705 BR10@CMU-10A> In-Reply-To: Mark Crispin's message of 7 Apr 79 16:45 Though if Stef doesn't want to do the work, I think that a simple time delay in the repeater would do the job. 9-Apr-79 21:45:03-PST,780;000000000001 Mail-from: MIT-ML rcvd at 7-Apr-79 1500-PST Date: 7 Apr 1979 1443-PST From: PBARAN at USC-ISI Subject: MSGGROUP# 985 In defense of flames To: msggroup at MIT-ML 1) Emotion is the hallmark of an issue of real concern to those who become emotional. Such issues should not be dismissed because of their emotional content, nor should they be subjected to some Procrustean 'rational discussion'. 2) Msggrp has addressed several such issues on a piecemeal basis. In the near past we have had the FINGER and NOT-LOGGED-IN flames. Maybe we should tackle the thing on a more global basis. Let me suggest a topic for discussion which is more general in nature: What are the rights of message system users ? Dave Caulkins (reply to PBARAN@ISI) ------- 9-Apr-79 21:45:03-PST,2061;000000000001 Mail-from: USC-ISI rcvd at 7-Apr-79 1551-PST Mail-from: MIT-ML rcvd at 7-Apr-79 1532-PST Date: 7 April 1979 18:10-EST From: Robert W. Kerns Subject: MSGGROUP# 986 Fast Draw! To: MSGGROUP at MIT-MC I think the fast draw comes from three main sources. First, the communications channel is effective enough to carry on arguments which otherwise would only be carried on in person. However, in MsgGroup, there's a bigger audience than there would be in a typical argument carried on in your office. And the second contributary to the fast draw comes from the fact that the communications channel is not as effective as the in-person one, but near enough so that sometimes we mistakenly treat it as if it were. Sometimes something will be said in jest or in some other manner which just does not carry through to the typed message. And the obverse of this is that sometimes someone will take advantage of the slight anonyminity that mail gives to say something he wouldn't say in person. And third, sometimes people don't deal with the people on the other end as people, but as programs or character streams, and they get pissed at the characters comming at them without trying to understand the person behind the character stream. I think that the faster bandwidth is far better, even if it does lead to an occasional fight, particularly if that fight is resolved. The background for a fight might exist when there is inadaquate communications for it to take place; I think it's better that it be handled than let simmer to hinder future communication. As I've said before, I think one of the most exciting aspects of network communications is what it can do for HUMAN interactions, and I think the fast draw syndrome is a symptom of "growing pains" of adapting to this new medium. Certainly, a "higher protocol" must be evolved to deal with the new types of relationships which form. Anyway, 'nuf said; I hope to retire from hyperactive network-mailing for a while to get some other work done! 9-Apr-79 21:45:03-PST,1011;000000000001 Mail-from: MIT-ML rcvd at 7-Apr-79 1555-PST Date: 7 Apr 1979 1511-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 987 Re: We're better off without the flaming From: STEFFERUD at USC-ISI To: RMS at MIT-AI Cc: MSGGROUP at MIT-AI Message-ID: <[USC-ISI] 7-Apr-79 15:11:39.STEFFERUD> In-Reply-To: Your message of 7 April 1979 16:34-EST I heartily agree on cessation of flaming in MSGGROUP. On the other hand, I do not see why the COMSAT forwarder is to be blamed for the flaming. Frankly, I find that the COMSAT forwarder takes a lot of pressure off me and simplifies the processing task. Without it, things often get out of sequence because mail is sent to me at various mailboxes around the net and to MSGGROUP, etc and then I have to mess around with getting it into synch again. Further, I am going away on a trip again and I still have no backup person to operate things while I am away. How about leaving the COMSAT forwarder there and just avoid flaming? Best - Stef 9-Apr-79 21:45:03-PST,474;000000000001 Mail-from: MIT-ML rcvd at 7-Apr-79 1628-PST Date: Saturday, 7 April 1979 1823-EST From: Brian K. Reid Subject: MSGGROUP# 988 Re: In defense of flames To: msggroup at MIT-ML Message-ID: <07Apr79 182306 BR10@CMU-10A> In-Reply-To: PBARAN's message of 7 Apr 79 17:43 Hmm. It's certainly true that there's been more traffic in MsgGroup in the last month than in the entire previous year. Maybe this is the right way to run such a discussion. 9-Apr-79 21:45:03-PST,926;000000000001 Mail-from: MIT-ML rcvd at 7-Apr-79 1705-PST Date: 7 April 1979 1813-est From: Bob Frankston Subject: MSGGROUP# 989 MsgGroup administration To: BR10 at CMU-10A Cc: msggroup at MIT-ML 1. Even in the absence of model 33 teletypes (and I presume that there rae very few on these discussion groups -- they just can't type out all the verbage), there is a use for the ability to print out letters in 10 pitch for inclussion in loseleaf binders on 8 1/2 by 11 paper. I prsonally like 65 chars since that means 1 inch margins, but 72 seems like a reasonable compromise. I am having a similar argument with the Multics people who think 79 is fine (though often don't even enforce that). 2. Now that msggroup is instant, I am quite unclear as to the distinction between the two groups -- I suspect that therer is a high overlap of the two lists. 9-Apr-79 21:45:03-PST,2303;000000000001 Mail-from: MIT-ML rcvd at 7-Apr-79 1706-PST Date: 7 Apr 1979 1555-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 990 Re: #981 MsgGroup administration From: STEFFERUD at USC-ISI To: BR10 at CMU-10A Cc: MsgGroup at MIT-ML Message-ID: <[USC-ISI] 7-Apr-79 15:55:26.STEFFERUD> In-Reply-To: <07Apr79 155526 BR10@CMU-10A> Yes, there are 72 character platens out there, and there are folks who like to have a margin on the left to avoid printing on the holes in their printer paper (purchased by someone else so they have no choice) et al. (8.5 - 7.9) = 0.6 inches for right and left margins. As for the rapid turnaround syndrome, it has been with us for many years. I recall long ago at Carnegie Tech (before CMU) when we had a terrible crunch on G-21 computer time and established a policy for giving selected hardship case grad students all the time they could handle on a first priority basis. I carefully counseled each of them when issuing the privilege, but a few killed themselves anyway because the could not willfully control their urge to hustle the job back into the system with a quick fix reaction. Like the great KKKAZUUUUMP Bird, they worked in ever smaller circles at ever increasing speed until ... I suspect that this is the same phenomenon in new quarters. Seems to me that someone long ago did some research at CMU on the effects of interactive use in problem solving and found a propensity for interactive computer users to find local solutions as compared to batch system users. The work was done in Engineering somewhere, back around 1968? (I'm guessing on the date). As for Murray Turoff and his colleagues, I agree that they seem not to have found it, though I have been involved with discussions that had the flavor when I had an EIES account. Maybe this explains why I don't have an account now? When an issue really gets to me, as suggested by Dave Caulkins, I feel compelled to dig into it. It takes real will power to avoid over reactions. So, yes I think the delays I caused were a factor, but I really think we should see if we can learn to live with the mechanism and still not flame. After all, we don't do it in face to face meetings. We should be able to learn to handle it here. Let's try - Stef 9-Apr-79 21:45:04-PST,1051;000000000001 Mail-from: MIT-ML rcvd at 8-Apr-79 2038-PST Date: 8 Apr 1979 1238-PST From: Feinler at SRI-KL (Jake Feinler) Subject: MSGGROUP# 991 Re: "Not-Logged-In" use and helpfulness of Subject: ARPANET hosts To: GEOFF at SRI-KA, CBF at MIT-MC cc: greep at RAND-UNIX, MSGGROUP at MIT-MC, FEINLER, cc: frank at UTAH-20 In response to the message sent 6 Apr 1979 2112-PST from the tty of Geoffrey S. Goodfellow Am wondering if Utah-20 personnel are included in the discussion going back and forth as I do not remember seeing any replies from them. As you know Utah has not had a major Server on the net for a while and might like to get feedback from some of you as to what is available. Randy Frank is the Liaison for Utah-20. Is he a member of MsgGrp or Header People? He is FRANK@UTAH-20 if not. I am having difficulty keeping up with the volume of messages flying back and forth on this and other topics, so if Randy is in the thick of things, scratch this message. Regards, Jake ------- 9-Apr-79 21:45:04-PST,1317;000000000001 Mail-from: MIT-ML rcvd at 8-Apr-79 2039-PST From: Gaines at Rand-Unix Date: 8 Apr 1979 at 1257-PST To: MsgGroup at Mit-Ml Subject: MSGGROUP# 992 Automatic redistribution of MsgGroup mail I think that on balance, the automatic redistribution is a plus. I am not convinced that this is even a major cause of the high emotional content of some of the recent traffic. The advantage of something close to a conversation that the rapid redistribution gives seems excellent to me. Intemperate outbursts are often the result of a failure to follow conventional folk wisdom, which includes such notions as "count to 10 before you..." and "sleep on it." In the case of our on-line systems, it is possible for most of us to compose something in the heat of the moment, but save it for a second look when we are calmer before firing it off. This has the virtue that while the prose produced in an emotional state generally has qualities that are missing in our less passionate moments (and, often but not always, they are positive qualities), we can consider more at our leasure whether the emotional outpourings are directed at some positive goal. I would prefer to let people "act in haste, repent at leisure" than to have discussions that now take days spread out over weeks. Stock Gaines 9-Apr-79 21:45:04-PST,2962;000000000001 Mail-from: MIT-ML rcvd at 8-Apr-79 2041-PST Date: 8 Apr 1979 1430-PST From: Feinler at SRI-KL (Jake Feinler) Subject: MSGGROUP# 993 Re: In defense of flames To: PBARAN at USC-ISI, msggroup at MIT-ML cc: FEINLER In response to the message sent 7 Apr 1979 1443-PST from PBARAN@USC-ISI Rather than a title 'In defense of flames' I should have perhaps used one 'Under what circumstances are flames defensible (i.e., admissable)' Also, rather than a rights of message senders/receivers, I would like to see a group come up with an 'etiquette of message sending'. I believe this is a 'protocol' issue equal to some of the machine protocol issues discussed in MsgGrp and Header-People. Consequently I would like to invite any who are interested to join me in a new group which I have dubbed METHICS (for message code of ethics). What I would like to see come out of this group is something akin to the "10 (or 20) Commandments of Electronic Mail Users". Lest this seem like a put-on, let me state that I am quite serious and have a forum for the outcome of this group. Just recently it was my privilege to be made Co-chairman of a Committee for User Requirements for IFIP Working Group 6.5 on Electronic Mail. Donald Davies of the National Physical Laboratory, Teddington, Middlesex, England is the other Co-chairman. This is a topic which is certainly suitable for this group to address. I personally have come from a different technical field (chemistry) which has a long history of dialog and technical intercourse. Over the many years in this field (as in most of the other older scientific fields such as biology, medicine, physics, and mathematics, for instance) there has evolved a methodology and etiquette or protocol for publishing, criticizing, proclaiming, disclaiming, announcing, denouncing, acclaiming, etc. It is my feeling (and apparently the feeling of many others) that our very young field of computer science is just beginning to evolve its methodology and ethics. We are the pioneers oddly enough, so it seems reasonable that we assess ourselves in the hopes that our assessment and recommendations will help lay a solid foundation for those to come. It is with some trepidation that I send this message, as it is quite possible that I will be incinerated by the subsequent flames, or drowned by the deluge of messages, or disappointed by the lack of response. I also will need to get agreement with Donald Davies and with Louis Pouzin before this can be officially be considered an IFIP WG 6.5 activity. Also, I am not a Computer Scientist. I am however one of those rare birds, a USER, and also an interested onlooker. So carrying that banner and brandishing my vorpal electronic user pen (which we all know is mightier than the sword, and hopefully the barb), I march into the foray shouting, "Ethics, anyone?" Regards, Jake Feinler (Feinler@SRI-KL) ------- 9-Apr-79 21:45:04-PST,748;000000000001 Mail-from: MIT-ML rcvd at 8-Apr-79 2058-PST Date: 8 Apr 1979 1644-PST From: Feinler at SRI-KL (Jake Feinler) Subject: MSGGROUP# 994 Re: In defense of flames To: PBARAN at USC-ISI, msggroup at MIT-ML cc: FEINLER In response to the message sent 8 Apr 1979 1430-PST from Feinler@SRI-KL I have been reminded that it would be inappropriate for the METHICS group to represent anything other than the views of the ARPANET community if we are to use the ARPANET for the dialog. Therefore, may I suggest we keep METHICS as an ARPANET interest group, and I will make the dialog and recommendations available to the IFIP subcommittee and Working Group and report back to you any actions they might take. Regards, Jake ------- 9-Apr-79 21:45:04-PST,489;000000000001 Mail-from: MIT-ML rcvd at 8-Apr-79 2059-PST Date: 8 April 1979 1940-est From: Bob Frankston Subject: MSGGROUP# 995 Re: In defense of flames To: Feinler at SRI-KL Cc: Msggroup at MIT-ML I agree with discussing the protocol and etiquette issues. I suspect, however, that most of the people on header-people/msggroup will want to participate so I don't really expect success in forming a separate discussion group. 9-Apr-79 21:45:04-PST,1096;000000000000 Mail-from: MIT-ML rcvd at 8-Apr-79 2059-PST Date: 8 APR 1979 1956-EST From: SIRBU at MIT-MC (Marvin A. Sirbu, Jr.) Subject: MSGGROUP# 996 Re: In defense of flames To: Feinler at SRI-KL, msggroup at MIT-ML, PBARAN at USC-ISI CC: FEINLER at MIT-MC It is hard for me to imagine how a code of ethics for message users would differ from any code governing civil discourse. The requirements for politeness, intelligibility, etc. are not likely to differ whether one is writing a letter, talking on the telephone or speaking face-to- face. If there is a difference it is that the rapid feedback provided by net-mail allows one more latitude in firing off cryptic comments, which can be readily clarified if necessary in a following exchange. This is not dissimilar to the way we use telephones or speak face-to- face; it is in contrast to letters where the delay in receiving a request for clarification obliges us to take more pains in writing the first time. Nevertheless I look forward to seeing any suggestions others may wish to make for such a code. Marvin Sirbu 9-Apr-79 21:45:04-PST,917;000000000000 Mail-from: MIT-ML rcvd at 8-Apr-79 2100-PST From: Mike at Rand-Unix Date: 8 Apr 1979 at 2006-PST To: Feinler at Sri-Kl cc: Msggroup at Mit-Ml, Mike at Rand-Unix Subject: MSGGROUP# 997 METHICS I would like to see Methics be a separate mailing list. Msggroup was not designed to be a medium for all topics and I am quite tired of hearing people 1) apologizing for sending long messages on a topic unrelated to messages and/or 2) loudly bemoaning that their mailbox is filled with non-message Msggroup mail. This noise can be avoided by the simple device of the Methics mailing list. No one will be annoyed by an ethics message coming from such a source, and, with luck, the new list may be smaller than Msggroup or Header-People. (If there is even one less flamer it will be worthwhile). And, as a final note, Stef will probably be much obliged as well. Please add me to your list, Jake. 9-Apr-79 21:45:04-PST,1300;000000000000 Mail-from: MIT-ML rcvd at 8-Apr-79 2157-PST Date: 9 April 1979 00:19-EST From: Charles Frankston Subject: MSGGROUP# 998 ITS headers To: HEADER-PEOPLE at MIT-MC, MsgGroup at MIT-ML cc: BUG-BABYL at MIT-MC I have changed the ITS Rmail reply command to force an RFC733 header in any reply to a header that is not in ITS format. This is based on the assumption that anyone who sends out a network header probably should be replied to with a network header. Hopefully, this should eliminate many unwanted ITS headers. This change is conditional upon my not receiving too many complaints from the user community. Somehow, I don't expect to. I am suggesting that the maintainers of the other mail reading program do the same. The theory behind the change is that most people simply use the reply command somewhat blindly. In fact, I have noticed this is ture much more of the non-ITS particpaints, probably because they use such primitive mail systems that do not allow them to have an editor easily available to fix up their replies (take that Stef). Nonetheless, since I happen to know the maintainers of Babyl are easily sickened by excessive flaming, if anyone replies to this message, please do NOT blindly copy the CC:(bug babyl) line. Thank you. 9-Apr-79 21:45:04-PST,965;000000000001 Mail-from: MIT-ML rcvd at 9-Apr-79 1422-PST Date: 09 APR 1979 1709-EST From: JZS at CCA (Joanne Sattley) Subject: MSGGROUP# 999 MEthics To: Feinler at SRI-KL cc: MsgGroup at MIT-ML Jake - As a private pilot, I've noticed, especially in the group mail, a remarkable similarity between one individual addressing another (copy to the group) and an airborne pilot transmitting to a ground receiver (copy to anyone on the same frequency). On the chance that the rules which govern these restricted radio transmissions might also apply to electronic mail, I whipped out my operator permit and found (alas) a collection of thou-shalt-nots. Here's what's applicable for the consideration of the MEthics group: "Prohibitions: use of obscene, indecent, or profane language. unauthorized disclosure or use of messages. superfluous, false, or deceptive signals or communications." Please add my name to your list. --Joanne ------- 9-Apr-79 21:45:04-PST,837;000000000001 Mail-from: MIT-ML rcvd at 9-Apr-79 1434-PST Date: 9 Apr 1979 0711-PST From: Pine at SRI-KA (Bud Pine) Subject: MSGGROUP#1000 Re: In defense of flames To: SIRBU at MIT-MC, Feinler at SRI-KL, msggroup at MIT-ML, To: PBARAN at USC-ISI cc: FEINLER at MIT-MC, PINE In response to the message sent 8 APR 1979 1956-EST from SIRBU@MIT-MC Marvin, I think I disagree with some of what you say. As marshall McLuan once said "the medium is the message", and we have a very undusual medium. It is much like a verbal conversation always with a recorder on. There is much more that is different and unusal about the medium and our usage of it. I am particularly interested in the socialogical aspects, and would like to be on the new methics if one is set up. I will also remain on the other lists. Bud -------