8-OCT-77 11:36:48-PDT,1368;000000000001 Mail-From: CMU-10A rcvd at 8-OCT-77 1136-PDT Date: 8 Oct 1977 1218-EDT From: Brian Reid at CMU-10A Subject: MSGGROUP# 601 [DUNLAVEY: Time] Subject: You must not have gotten this one To: MsgGroup at ISI Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 8 Oct 1977 12:18:38 Brian Reid Stef, You should include Dick Dunlavey's answer to my question also. Enclosed herewith: Begin forwarded message - - - - - - - - - Date: 6 Oct 1977 (Thursday) 0235-Est From: DUNLAVEY at NBS-10 Subject: Time To: BRIAN REID(C410BR10) at CMU-10A Brian, Dr. Hall of the Time Service Division, U.S. Naval Observatory, Wash. D.C. says that there are no standards nationwide to distinguish the meaning of 12 a.m. and 12 p.m. They are and always have been ambiguous. It was for this reason, he says, that train schedules never use either, but 11:59 or 12:01 instead (I never noticed this myself). "Noon", of course, is unambiguous for a given day; but "midnight" must be given as between two specific dates. The 24-hour clock removes most of these ambiguities, but even then the use of 2400 hours is discouraged, and 0000 hours is always used to denote the beginning of the specificied day. For further of information you may contact Dr. Hall at: (202) 254-4486 Any time, Dick End forwarded message ------- 9-OCT-77 22:17:50-PDT,6802;000000000001 Mail-From: USC-ISI rcvd at 9-OCT-77 2217-PDT Date: 9 OCT 1977 2116-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 602 SURVEY OF [ISI]PROCEEDINGS.MSG#551-600 From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI] 9-OCT-77 21:16:10.STEFFERUD> Redistributed-To: Jordan at KL Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 29 JAN 1978 -- Messages from file: [USC-ISI]PROCEEDINGS.MSG#551-#600;1 -- SUNDAY, OCTOBER 9, 1977 21:03:24-PDT -- 41 8 OCT MSGGROUP at USC-ISI MSGGROUP# 600 Re: A.M. and P.M. time designation standard (605 chrs) 40 7 Oct RICK.GUMPERTZ at CMU- MSGGROUP# 599 Re: A.M. and P.M. time designation standard (686 chrs) 39 7 OCT MSGGROUP at USC-ISI MSGGROUP# 598 Re: A.M. and P.M. time designation standard (1583 chrs) 38 6 Oct DDEUTSCH at BBN-TENEX MSGGROUP# 597 Re: A.M. and P.M. time designation standard (1121 chrs) 37 5 Oct BRIAN REID(C410BR10) MSGGROUP# 596 A.M. and P.M. time designation standard (1145 chrs) 36 6 SEP CARLISLE at USC-ECL MSGGROUP# 593 U S Electronic Mail Association (2976 chrs) 35 29 AUG DCROCKER at USC-ISI MSGGROUP# 592 Social Statistic of Computer-based Human Communication (921 chrs) 34 25 AUG DCROCKER at USC-ISI MSGGROUP# 591 Pending availabilit y of report on Unix message system (776 chrs) 33 3 Aug Panko at SRI-KL MSGGROUP# 589 Computer Conferencing Vs. Face to Face Conferencing (734 chrs) 32 1 Aug Frankston at MIT-Mult MSGGROUP# 588 message system survey (774 chrs) 31 31 Jul MTK at SU-AI (Marc Ka MSGGROUP# 587 RE: USE OF CASSETTES ON ARPA (1177 chrs) 30 28 Jul Geoff at SRI-KA (Geof MSGGROUP# 586 An interesting notion. (781 chrs) 29 27 Jul PANKO at SRI-KL MSGGROUP# 585 Viewdata Demonstration (2270 chrs) 28 25 Jul BRIAN REID(C410BR10) MSGGROUP# 584 Another stunning success by USPS (1054 chrs) 27 23 Jul PANKO at SRI-KL MSGGROUP# 583 Meeting with John Morton (1010 chrs) 26 20 Jul RHILL at BBN-TENEXB MSGGROUP# 582 NETALK 138 USE OF CASSETTES ON ARPA (1093 chrs) 25 10 Jul STEF at SRI-KA MSGGROUP# 581 DIALNET and Home Computers - A Computer Faire Paper (14935 chrs) 24 1 Jul MTK at SU-AI (Marc Ka MSGGROUP# 580 Introduction for Marc Kaufman (MTK@SU-AI) (977 chrs) 23 9 JUN PANKO at OFFICE-1 MSGGROUP# 577 Copy, not cc (901 chrs) 22 4 Jun Frankston at MIT-Mult MSGGROUP# 575 Multiple copy problem. (i.e. msggroup/header-peo ple) (985 chrs) 21 2 JUN PANKO at OFFICE-1 MSGGROUP# 574 Special Journal Issue on Computer Mail (1811 chrs) 20 30 MAY GEOFF at SRI-KA MSGGROUP# 573 Re: [NELSON: #569 Does it know about mail, too?] (1151 chrs) 19 27 MAY PANKO at OFFICE-1 MSGGROUP# 571 NTC'77 Computer Mail Sessions (1537 chrs) 18 26 MAY PANKO at OFFICE-1 MSGGROUP# 570 New Addresses for Ray Panko (1116 chrs) 17 26 MAY NELSON at PARC-MAXC MSGGROUP# 569 Does it know about mail, too? (1718 chrs) 16 25 MAY Kahler at SUMEX-AIM MSGGROUP# 568 Introduction Richard Kahler (KAHLER@SUMEX-AIM) (1185 chrs) 15 25 MAY MACRAK at MIT-MC (Sta MSGGROUP# 567 Internetwork mail. (2804 chrs) 14 25 May RICK.GUMPERTZ at CMU- MSGGROUP# 566 Re: RFC724 and non-ARPA networks (1015 chrs) 13 25 May BRIAN.REID at CMU-10A MSGGROUP# 565 RFC724 and non-ARPA networks (2187 chrs) 12 24 May Geoff at SRI-KA (Geof MSGGROUP# 564 Computerized Conferencing Artical on "Blackboard". (8690 chrs) 11 05/24/ Pogran at MIT-Multics MSGGROUP# 563 All the headers, large and small (2882 chrs) 10 24 MAY POSTEL at USC-ISIB MSGGROUP# 562 Comments on Time Zones (718 chrs) 9 23 May POSTEL at USC-ISIE MSGGROUP# 561 Comments on RFC 724 (7375 chrs) 8 22 MAY FARBER at USC-ISI MSGGROUP# 560 A comment on the "efficiency" of message systems (3936 chrs) 7 22 May PHILIP.KARLTON at CMU MSGGROUP# 559 Re: MSGGROUP# 554 RFC 724 (1035 chrs) 6 21 MAY PANKO at OFFICE-1 MSGGROUP# 558 Simple Headers (1552 chrs) 5 21 MAY RMS at MIT-AI (Richar MSGGROUP# 557 horrors! I wasted 3 cents! (724 chrs) 4 21 MAY PANKO at OFFICE-1 MSGGROUP# 556 Panko's Submission in FCC Computer Inquiry (43874 chrs) 3 21 May DDEUTSCH at BBN-TENEX MSGGROUP# 555 RE MCKENZIE COMMENT ON RFC 724 (682 chrs) 2 19 May MCKENZIE at BBN-TENEX MSGGROUP# 554 RFC 724 (5118 chrs) 1 17 MAY MSGGROUP at USC-ISI MSGGROUP# 551 [ISI]Proc eedings.msg#501-#550 (7761 chrs) ------- 5-NOV-77 11:48:51-PST,477;000000000001 Mail-From: UCLA-SECURITY rcvd at 18-OCT-77 1519-PDT Date: 18 Oct 1977 1516-PDT Sender: csk at UCLA-Security Subject: MSGGROUP# 603 info From: csk at UCLA-Security To: msggroup at isi There is a guy here at ucla who is interested in mail systems. He is looking for information on the arpanet mail services. Is there a current list of documents which is appropriate to give him? (i.e. rfcs, other documents, etc.) Thanks. Charley Kline (csk@isi) ------- 5-NOV-77 11:48:53-PST,749;000000000001 Mail-From: USC-ISI rcvd at 19-OCT-77 1522-PDT Date: 19 OCT 1977 1522-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 604 Re: info From: MSGGROUP at USC-ISI To: csk at UCLA-SECURITY Cc: msggroup, Stefferud, csk Message-ID: <[USC-ISI]19-OCT-77 15:22:16.STEFFERUD> In-Reply-To: Your message of OCTOBER 18, 1977 HI Charley - Yes there is some info. For example, there are the transactions files in MsgGroup which are publicly accessible by anyone with ARPANET access. Does your friend have such assess, or will you get the stuff for him? I will send you the procedures for accessing, and then you can decide what to do with it, and decide if he should become a member on the mailing list of MsgGroup. OK? Stef ------- 5-NOV-77 11:48:53-PST,7360;000000000001 Mail-From: CMU-10A rcvd at 25-OCT-77 1812-PDT Date: 25 Oct 1977 1513-EDT Sender: BRIAN.REID at CMU-10A Subject: MSGGROUP# 605 For Your Information (about Robots, not Messages) From: BRIAN REID(C410BR10) at CMU-10A To: MSGRP.DST - - - - The Carnegie-Mellon University Artificial Intelligence Lab meets `The Ultimate Home Appliance' (Reported by Mark Fox and Brian Reid) On October 24, 1977, a well-known department store in the heart of Pittsburgh advertised the appearance of a `domestic robot' named Sam Strugglegear. Although this robot is not yet offered for sale, its inventor, Anthony Reichelt of Quasar Industries in New Jersey, claims that its powers include speech recognition with a 4800-word vocabulary, sonar-navigated steering, and the ability to do household chores such as vacuuming, serving of drinks, and babysitting. This highly-publicized `robot' has been described in Newsweek, Parade, and other national magazines. Knowing of CMU's pioneering work in Artificial Intelligence, particularly in the field of speech recognition, various friends have called CMU to ask how this robot might be so much better at speech recognition than our talented and dedicated research team. Rising to the challenge, four courageous members of our department went downtown to investigate. They found a frightening sight: in the men's department, among the three-piece suits, was a 5'2'' image of an aerosol can on wheels, talking animatedly to the crowd. The robot seemed able to converse on any subject, to recognize the physical features of the customers, and to move freely (though slowly) in any direction. While the crowd was quite charmed by the talented machine, we were dubious, and moved in to investigate it more closely. The robot moved on a set of wheels; there were two large drive wheels about ten inches in diameter, and several small stabilizing wheels: a mechanism quite similar to the MIT turtle. It moved about three inches per second, approximately one tenth the normal walking speed of an adult. We saw both arms rotate at the shoulder along a horizontal axis. Although there was a joint at the elbow, we never saw it move (perhaps this model had no actuator in the elbow). The hands were like clam-shells in design. There was a rod at the wrist that could be used for opening and closing the hands, but on the model we saw, the hands were actually glued shut, so that they could not move even if there were an actuator. The actuators for the arms were electric motors attached to the arms by gears rather than belts. When an arm was blocked while in motion, the motor would stop dead, indicating the presence of some primitive feedback mechanism. One patron asked to see the robot vacuum a carpet, but was brushed off with the reply that its batteries were running low. The CMU team next set out to investigate the robot's sensory mechanisms. Pushing and blocking its motion had no effect; the motors kept spinning away. It didn't seem able to tell that an object was blocking its path. Covering the faceplate did not change its behavior at all. Since the robot seemed able to navigate around the room without hitting anything, we found it quite curious that it had no detectable sensory reactions. Feeling more dubious, we began looking around the room for evidence of remote control. Lo and behold, about ten feet from the robot, standing in the crowd, we found a man in a blue suit with his hand held contemplatively to his mouth like Aristotle contemplating the bust of Homer in the famous Rembrandt painting. After watching for a while, we noticed that whenever the robot was talking, the man in the blue suit could be seen muttering into his hand. Further seeing that this man had a wire dangling suspiciously from his waist to his shoe, one of the CMU group screwed up his courage and approached this stranger. "Do many people figure out what you are doing?", we asked. "No," he said, "they are usually too busy watching the robot to notice me." "Aha!", we thought to ourselves, "it looks like we're on to something here." We then asked him what were the robot's speech and vision abilities, to which he replied that the machine can see about ten inches, dimly, and that its speech-understanding ability was about 200 words of unconnected speech in a quiet environment. We didn't really believe his statement of the robot's abilities, and in the light of our discoveries of the robot's poor perceptive skills, we were convinced that there must be yet another remote control handling the motion. Time was running out; they needed to move the machine to a suburban store for an evening demonstration. We returned to CMU feeling unsatisfied. When we gave our report to the rest of the lab back at CMU, a second group of eight immediately set out to the suburban store, determined to find the source of the robot's control. They found a furtive-looking and rather disagreeable person loitering in the back of the room. He was carrying an airline flight bag, with his hand stuck down inside the bag. We asked him his business, to which he replied that he was a truck driver. He became extremely agitated when we asked him what was in the bag, asking if we were police. We dispatched a person to watch him, in an attempt to find correlations between movements of his hand and movements of the robot, whereupon he got very excited and called for store officials to come get us away from him. We never did get to see in the bag. However, we did see the man with the microphone say to a store official, "Tell him we want to take it for a walk," whereupon the store official wandered over to the `bag man' and whispered something to him. It would be tempting to call this robot a fake, but it is not. It is a fake robot, but a reasonably good parlor trick, more in the domain of magicians than of computer scientists. However, one is reminded of how much better were the parlor tricks of olden days -- for example, the chess-playing robot built by Baron Wolfgang von Kempelen in 1769. Spectators were given a view of the inside of the robot, satisfying themselves that it could not possibly contain a person. The robot would then trounce them at chess, all the while rolling its eyes and nodding its head. The workings of this famous `Turk' were not revealed until 1848, more than 70 years later, when it was bought by the Philadelphia Chess Club and disassembled. Thousands of people, including Napoleon and Edgar Allan Poe, tried unsuccessfully to figure out how it worked; very rarely was it even beaten. Kempelen's description of his own robot, circa 1771, is probably the best summary of Sam Strugglegear: "A mere bagatelle, not without merit in point of mechanism, but whose effects appear marvelous only from the boldness of conception and the clever choice of methods adopted for promoting the illusion." ------- 5-NOV-77 12:09:52-PST,458;000000000001 Mail-From: USC-ISI rcvd at 5-NOV-77 1209-PST Date: 5 NOV 1977 1202-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 606 ADD Sles@CCA, Sirbu@MIT-MC, WMartin@SRI-KL, Zellich@SRI-KL From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI] 5-NOV-77 12:02:10.STEFFERUD> A fresh copy of the entire list is available from [isi]mailing.list. I will forward a copy via netmail on request. Best - Stef ------- 13-NOV-77 00:18:23-PST,1467;000000000001 Mail-From: USC-ISI rcvd at 13-NOV-77 0018-PST Date: 13 NOV 1977 0009-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 607 [SIRBU@MIT-MC: Telecommunications Policy Seminar] From: SIRBU@MIT-MC To: [ISI]Mailing.List: Message-ID: <[USC-ISI]13-NOV-77 00:09:34.STEFFERUD> Begin forwarded message -------------------- Mail-From: MIT-MC rcvd at 11-NOV-77 0921-PST From: SIRBU@MIT-MC 11/11/77 12:12:43 Subject: Telecommunications Policy Seminar Subject: Re: Seminar on Electronic Message Services Nov 17 Subject: November 17, 1977 4:00 - 6:00 P.M. M.I.T. Bldg 37, Room 252 To: (*MSG *ITS) at MIT-MC, (*MSG *ITS) at MIT-DMS Cc: MSGGROUP at USC-ISI Speakers: Buford F. Smith Don Wehe Director of Telecommunications Marketing Representative Cook Industries TYMNET, Inc (subsidiary of TYMSHARE) Moderator: Albert Vezza Research Associate Laboratory for Computer Science, M.I.T. Computer based mailbox sevices (CMS) are moving out of the university, and into regular commercial operation. In this seminar, we shall hear from both a user and a vendor of CMS services. The user, an inter- national grain trading company, has implemented an in-house system for middle managers with interesting features for distributing messages. The vendor is offering a common carrier service which can be used for inter-corporate communications. -------------------- End forwarded message ------- 13-NOV-77 10:49:49-PST,563;000000000001 Mail-From: USC-ISI rcvd at 13-NOV-77 1049-PST Date: 13 NOV 1977 1043-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 608 REQUEST FOR REVIEW OF [Policy Seminar] From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Cc: SIRBU at MIT-MC, VEZZA at MIT-DMS Message-ID: <[USC-ISI]13-NOV-77 10:43:17.STEFFERUD> In-Reply-To: <[USC-ISI]13-NOV-77 00:09:34.STEFFERUD> HI ALL - I WOULD LIKE TO REQUEST ONE OR MORE REVIEWS OF THE SEMINAR FOR DISTRIBUTION TO MSGGROUP. I ASSUME A NUMBER OF OUR "MEMBERS" WILL BE ATTENDING? THANKS - STEF ------- 13-NOV-77 20:00:55-PST,696;000000000001 Mail-From: USC-ISI rcvd at 13-NOV-77 1605-PST Date: 13 NOV 1977 1557-PST From: FARBER at USC-ISI Subject: MSGGROUP# 609 united airlines and the world of thhe future To: [ISI]Mailing.List: i was talking with a key man from ua the other day and he related a true story that was shhocking but true. ua top management had made a deep and fundamental chhange in their policies that required for implementation a cahnge to the software on the corporations computers ( i have not further details). they were forced to retract their descision because they could not get the software changed in a timely fashion due to the complexity of the systems. !!!!!!! dave ------- 13-NOV-77 20:39:43-PST,1298;000000000001 Mail-From: USC-ISI rcvd at 13-NOV-77 2039-PST Date: 13 NOV 1977 2023-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 610 Re: united airlines and the world of thhe future From: STEFFERUD at USC-ISI To: FARBER Cc: [ISI]Mailing.List: Message-ID: <[USC-ISI]13-NOV-77 20:23:55.STEFFERUD> In-Reply-To: Your message of NOVEMBER 13, 1977 I guess I must be a bit more philosophic about the policy control problem you ascribe to UA. Bureaucracies have been doing that to large institutions since they were invented. The more interesting observation is that our computer systems seem to be no better than our bureaucracies! Sigh! And, for another horror story, there was the brokerage house that was forced to merge with another because their computer system showed their capital accounts to be below the norms, only to find after sorting things out after the merger that the problem was in the system, not in the accounts. Not only that, but there was also a rumor that they knew they had problems with the systems, evidenced by certain accounts disappearing and reappearing without apparent cause, but they did not seem able to unravel the problem. Yes, computers are maybe not helping as much as we would like to tell ourselves? Cheers - Stef ------- 14-NOV-77 13:49:33-PST,617;000000000001 Mail-From: USC-ISI rcvd at 14-NOV-77 1349-PST Date: 14 NOV 1977 1331-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 611 ADD Caine@ECL, EKGordon@ECL, MARS-Filer@CCA; DROP MTK@SU-AI, NSmith@SUMEX-AIM From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]14-NOV-77 13:31:02.STEFFERUD> Marc T. Kaufman seems to have dropped off the net, along with NSmith. Steve Caine and E. Kent Gordon have obtained their own mailboxes at ECL. Joanne at CCA asked to have MARS-Filer added to facilitate archiving of MSGGROUP transactions in the Data Computer at CCA. Stef ------- 16-NOV-77 14:44:12-PST,456;000000000001 Mail-From: SRI-KL rcvd at 15-NOV-77 1839-PST Date: 15 Nov 1977 1809-PST Sender: PANKO at SRI-KL Subject: MSGGROUP# 612 Alive Again From: PANKO at SRI-KL To: [ISI]Mailing.List: Cc: rulifson at PARC-MAXC Message-ID: <[SRI-KL]15-Nov-77 18:09:54.PANKO> I have at least temporary access to my mailbox again. I appologize for all the messages I didn't answer, but when you don't have a terminal, it's hard to communicate. Ra3y ------- 25-NOV-77 23:13:57-PST,940;000000000001 Mail-From: USC-ISI rcvd at 21-NOV-77 1521-PST Date: 21 NOV 1977 1500-PST Sender: DCROCKER at USC-ISI Subject: MSGGROUP# 613 RFC 733: Standard for the Format of ARPA Network Text Messages From: DCrocker@Rand-Unix,Vittal@bbnd,Pogran@multics,Henderson@bbnd To: Walker, Feinler at SRI-KL, Postel at ISIB Cc: Header-People at MIT-MC, [ISI]Mailing.List: Message-ID: <[USC-ISI]21-NOV-77 15:00:50.DCROCKER> RFC 733 is at last available for inclusion in the Protcol Handbook and distribution as an RFC. The document is in [USC-ISIA]Standard.Doc and is accessible via FTP by using login Anonymous and any password. The document is 38 text pages long and is fully-formatted. It has been a very long haul, since last year, and we would like to particularly thank the members of Header-People who contributed so much time offering ideas to the specification process. Dave, John, Ken, and Austin. ------- 25-NOV-77 23:13:57-PST,679;000000000001 Mail-From: CMU-10A rcvd at 21-NOV-77 1701-PST Date: 21 Nov 1977 1950-EST Sender: BRIAN.REID at CMU-10A Subject: MSGGROUP# 614 Fake robot: a call for help From: BRIAN REID(C410BR10) at CMU-10A To: Header-People at MIT-MC, MSGRP.DST - - - - A reporter from Business Week magazine is going to Quasar tomorrow morning (Tuesday 22 Nov) at 10:00 a.m. I want him to take with him a person who would be able to exposte the thing for what it is. Are any of you folks in New York City? Would any of you be willing to go along with this reporter tomorrow morning? If so, please let me know IMMEDIATELY, and I will connect you up. Brian Reid ------- 28-NOV-77 14:38:18-PST,932;000000000001 Mail-From: DEC-MARLBORO rcvd at 28-NOV-77 1421-PST Date: 28 Nov 1977 1719-EST From: KENKING at DEC-MARLBORO Subject: MSGGROUP# 615 Add Ken King to MsgGroup To: STEFFERUD at ISI Redistributed-To: [ISI]Mailing.List: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 30 NOV 1977 I was given your name by Marvin Sirbu at MIT. I would like to get on the distribution list for the Message Group. I am in the R&D Group at Digital and head of the Office Automation Project here. I have been working for the past two years to get electronic mail into the company. We will be using the CCA TDA package. I am currently designing a new system that will use our Word Processing Products as a base and build upon them. I am interested in future generations of electronic mail systems and in the effect that such systems have on the people that use them. Thanks. Ken King ------- 29-NOV-77 14:44:09-PST,1463;000000000001 Mail-From: SRI-KL rcvd at 29-NOV-77 1444-PST Date: 29 Nov 1977 1445-PST From: Panko at SRI-KL (Ra3y Panko) Subject: MSGGROUP# 616 NTC'77 Computer Mail Session, 6 DEC 77 in LA To: stefferud at USC-ISI cc: msggroup at USC-ISI Redistributed-To: [ISI]Mailing.List: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 30 NOV 1977 Stef, you asked for a refresher about the computer mail session at this year's NTC'77. Here is the information. Please pass it on to the MSGGROUP (I can't do group mailings). The National Telecommunications Conference is one of the IEEE's big annual conferences. It will have dozens of paper sessions. The computer mail session will be one of these. NTC'77 will be held from December 5-7, 1977, at the Los Angeles Marriott. The computer mail session (Session 21) will be held Tuesday morning, December 6, from 9:00 until noon, in a room to be determined. There will be six papers. Panko and Panko will give an introductory paper. Ted Myer and Johnn Vittal will talk on message technology in the ARPANET. Jake Feinler of SRI will talk on a network identification system. Jacques Vallee and R. Beebe of Infomedia will talk on TOPICS and NOTEPAD. Walt Ulrich of Tymshare and Hank Taylor of Hewlett-Packard will discuss their companies' systems in separate papers. I think this will be a very good session (of course, I am the chairman). Aloha, Ra3y ------- 3-DEC-77 01:11:58-PST,1976;000000000000 Mail-From: USC-ISI rcvd at 3-DEC-77 0111-PST Date: 3 DEC 1977 0042-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 617 [Greep at Rand-Unix: Mail redistribution] From: STEFFERUD at USC-ISI To: [ISI]Mailing.List;142: Message-ID: <[USC-ISI] 3-DEC-77 00:42:35.STEFFERUD> IT IS CLEAR THAT THE TENEX FTP MAIL RECEIVER IS PUTTING NON-STANDARD HEADER FIELDS IN THE HEADERS OF RECEIVED MESSAGES. THIS WOULD PROBABLY NOT EVER CASUE ANY TROUBLE, EXCEPT THAT THE HERMES REDISTRIBUTE FUNCTION ALSO SEND THOSE FIELDS OUT WITHOUT MODIFICATION TO MAKE THEM LEGITIMATE. THE FIELDS IN QUESTION ARE THE "RECEIPT POSTMARKS," WHICH SHOULD PERHAPS NOT BE FORWARED BY HERMES. IN ANY CASE IT SEEMS CLEAR THAT HERMES OWNS THE PROBLEM OF MAKING SURE IT IS SENDING ONLY MESSAGES THAT ARE LEGITIMATE. IT IS ALSO CLEAR THAT NO ONE ELSE CAN BE HELD ACCOUNTABLE. HOPEFULLY, NOW THAT RFC733 IS AVAILABLE TO USE AS A STANDARD, SOMEONE CAN DO SOMETHING ABOUT IT. IN THE MEANTIME, I CAN EITHER AVIOD USE OF REDISTRIBUTION BY USING FORWARD INSTEAD, OR I CAN MODIFY THOSE FIELDS TO PUT IN A COLON TO MAKE THEM LOOK MORE LEGITIMATE. WHAT WOULD YOU ALL LIKE ME TO DO, WHILE WE WAIT FOR THE BABY TO COME? BEST - STEF Begin forwarded message -------------------- Mail-From: RAND-UNIX rcvd at 1-DEC-77 1559-PST Date: 1 Dec 1977 at 1559-PST From: Greep at Rand-Unix To: Stefferud at Isi Cc: Greep at Rand-Unix Subject: Mail redistribution Message-ID: <[Rand-Unix] 1-Dec-77 15:59:55.Greep> The redistribution puts the 'Mail from ...' line at the beginning of the message, but this is not a valid header field (there's no colon in it). Just thought you might want to know since some of the people on MsgGroup may have mail systems that barf at this (ours puts it in a field called 'Unknown-text'). I imagine someone has complained about this already. -------------------- End forwarded message ------- 7-DEC-77 21:42:21-PST,2272;000000000001 Mail-From: MIT-MC rcvd at 5-DEC-77 1127-PST Date: 5 DEC 1977 1428-EST From: SIRBU at MIT-MC (Marvin A. Sirbu, Jr.) Subject: MSGGROUP# 618 Private express statutes and electronic mail To: msggroup at USC-ISI CC: SIRBU at MIT-MC Msggroup members may be interested in an exchange of correspondence I had last year with the Assistant General Counsel of the USPS concerning private express statutes and electronic mail. Enclosed is a copy of a letter I received dated August 23, 1976. ------------- Dear Dr. Sirbu This replies to your letter of June 28, 1976, in which you inquired whether the Private Express Statutes [Title 39, U.S. Code, articles 601-606 and Title 18, U.S. Code, articles 1694- 1699 and 1724] apply to the transmission of messages by telephone or electronic communication links. By means of the Statutes, the Congress, wtih certain exceptions, conferred a monopoly upon the U.S. Postal Service over the carriage of letters for others over post routes. The regulations implementing the Statutes are codified as Parts 310 and 320 of Title 39, Code of Federal Regulations, copy attached. Hereafter, unless specifically noted otherwise, references to sections are to sections in Part 310. A letter is a message directed to a specific person or address and recorded in or on a tangible object. Section 310.1(a). A message, while being sent by telephone or electronic communications links, is not regarded as recorded in or on a tangible object. Therefore, while being so transmitted, the message is not considered a letter within the meaning of the Statutes and regulations and the Private Express Statutes and regulations do not apply. If a message transmitted by telephone or electronic communication links is at some time reduced to a "hard" copy, i.e., recorded on a tangible object, such as paper, tape, etc., see article 310.1(a)(1), such a "hard" copy could, depending upon the nature of the message and the method of carriage, become subject to the Private Express Statutes and regulations if it is privately carried over post routes as defined in article 310.1(d)(1)-(5). Sincerely, Jackt T. DiLorenzo Assistant General Counsel Opinions Division --------------------- ------- 15-DEC-77 11:24:53-PST,1641;000000000001 Mail-From: BBN-TENEXA rcvd at 14-DEC-77 0607-PST Date: 14 Dec 1977 0854-EST Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP# 619 Re:[Greep: Mail redistribution] From: MOOERS at BBN-TENEXA To: STEFFERUD at USC-ISI Cc: [ISI]Mailing.List;142: Message-ID: <[BBN-TENEXA]14-Dec-77 08:54:03.MOOERS> In-Reply-To: <[USC-ISI] 3-DEC-77 00:42:35.STEFFERUD> We have discussed this problem. There are two aspects (a) the fact that the FTP server places the "Mail from..." on the messages, and (b) the problem of having the Hermes Redistribute command modify these lines for recipients who are not in the TENEX environment. Recipients who are in the TENEX enviroment now get "Mail from ..." lines on all messages, anyway. Hermes now puts these lines in a field named "Other:" when it analyzes the messages into fields. This is not an ideal solution; it seems to be the equivalent of the "Unknown-Text" field. We will start proceedings to get the FTP server modified as soon as possible, which, in view of the schedules of the people involved, means in the middle or end of January. A reasonable solution would be to modify the FTP server to create a line that reads "Mail-from: ..." Once this is done at BBN, the change will have to be propagated to other TENEX sites. (The Hermes group has not distributed this kind of program; it would presumably be done through the regular procedures for distributing SUBSYS programs.) At the same time, we will put in the works a change to the Hermes Redistribute command to indentify and modify existing "Mail from ..." lines. ---Charlotte Mooers ------- 15-DEC-77 11:24:54-PST,1822;000000000001 Mail-From: USC-ISI rcvd at 14-DEC-77 1334-PST Date: 14 DEC 1977 1318-PST From: TASKER at USC-ISI Subject: MSGGROUP# 620 Formatted Messages - Self-Defining To: [ISI]Mailing.List;142: I'm Bill Neumann at MITRE (Bedford). I'm working on command and control systems, where the message traffic consists primarily of reports intended for data base storage or application program processing. In these applications, message standards are usually created to constrain the semantics of the user's message through the specification of the different types, contents, format and interpretation. Traditionally, these applications have utilized binary encoding techniques or man readable character representations as a means of implementation on automated systems. Is anyone aware of any work being done for this latter type of application that has gone beyond these approaches and considered the use of protocols and/or self descriptive structures (as might be found in symbol tables) as a means of providing a standard approach to the problem of message exchange at the user text level? The possible benefits of such an approach over conventional binary encoding or character text might be: 1. Machine and communication media independent messages 2. Improved flexibility with respect to enhancing the contents of old messages or creating new ones. 3. Improved configuration control through the use of a common tabular message data base which describes message structures, contents and formats. 4. Reduced costs associated with the development of unique but essentially redundant message exchange software developments through the use of a common descriptive message data base. /Bill Neumann c/o TASKER@ISI ------- 15-DEC-77 11:24:54-PST,838;000000000001 Mail-From: USC-ISI rcvd at 15-DEC-77 0958-PST Date: 15 DEC 1977 0946-PST From: POSTEL at USC-ISI Subject: MSGGROUP# 621 Self Defining Messages To: Tasker at ISIA cc: [ISI]Mailing.List;142: ATTN: Bill Neumann Bill: two items come to mind, one is the format of messages used in the National Software Works (NSW) project, and the other is a proposal for an encoding for electronic mail. A reference for the second is RFC 713, which can be copied from the NIC online library at SRI-KL via ftp using the username NICGUEST and password ARPA, the pathname for the document is RFC713.TXT i don't have a good reference for the current version of the NSW scheme, i suggest that you contact Robert Millstein at Compass to get a citation (MILLSTEIN@SRI-KA). --jon. ------- 15-DEC-77 11:52:16-PST,526;000000000001 Mail-From: USC-ISI rcvd at 15-DEC-77 1152-PST Date: 15 DEC 1977 1140-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 622 ADD CSC-NALCON@SRI-KL, Remove SGilbert@BBNB From: MSGGROUP at USC-ISI To: [ISI]Mailing.List;143: Cc: CSC-NALCON at KL Message-ID: <[USC-ISI]15-DEC-77 11:40:42.STEFFERUD> Steve Sutkowski is back as CSC-NALCON@KL - Welcome! Shirley Gilbert has taken a position without an ARPANET mailbox. She may be reached via JGilbert@BBNB. And - A Happy Holiday to All! Stef ------- 18-DEC-77 21:56:15-PST,2661;000000000001 Mail-From: USC-ISI rcvd at 18-DEC-77 2156-PST Date: 18 DEC 1977 2134-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 623 DIALNET developments? Subject: [MRC at SU-AI (Mark Crispin): Message group] From: MSGGROUP at USC-ISI To: [ISI]Mailing.List;143: Message-ID: <[USC-ISI]18-DEC-77 21:34:01.STEFFERUD> Begin forwarded message -------------------- Mail-From: SU-AI rcvd at 15-DEC-77 2130-PST Date: 15 Dec 1977 2104-PST From: MRC at SU-AI (Mark Crispin) To: Stefferud at USC-ISI Subject: Message group Would people in your group be interested in Dialnet mail formats? We have decided that our high-level non-interactive mail protocols are going to be in the form of S-expressions; while not strictly LISP it will be "LISP-ese". What a server needs is not really a "LISP interpreter" but merely a "LISP reader". Since I've been worried about generating something that nobody will want to do (some of the hairiest aspects of 733 come to mind), I intend to make very little of the protocol required. The idea is in keeping with the earlier Dialnet philsophy that you can be a cretin and still win, whether you are talking to another cretin or to a winner. Winners can win too. There is not going to be any "mail header" as the ARPAnet has. Everything is going to be in terms of protocol negotiations. A transmitted message might look like this: (TO MRC) (ACCEPTED '(TO MRC) MORE-ALLOWED) (DATE-TIME (12. 15. 77.) (21. 23.) PST) (OKAY) (MESSAGE-ID 'FOO-BAR-GARPLY) (NOT-IMPLEMENTED '(MESSAGE-ID 'FOO-BAR-GARPLY)) (MESSAGE-TEXT '(This/ is/ a/ test/ message.)) (OKAY) (END) (OKAY) This is all very theoretical and off the top of my head so to say. I want to make the syntax unambiguous and easily machine-parsable, since I expect that people will want more hairy options later on (sigh). I expect the initial SAIL implementation will be a "cretin" and will develop as the protocol develops. It is important to me that a workable system can be brought up with a minimum of effort. Any help you or others in your group can give in the way of suggestions or criticism will be appreciated. I can give pointers to relevent documentation files written or being written (ie, in varying degrees of chaos!!!); some of them can only be printed on an XGP, but most will print reasonably on a lineprinter as long as the file transfer is done in TYPE A to deSAILify the file (due to our "winning" text editor). Thanks much, merrie xmas & hippie new year and all of that. [Mark] ------- -------------------- End forwarded message ------- 20-DEC-77 08:22:20-PST,1233;000000000001 Mail-From: USC-ISI rcvd at 20-DEC-77 0822-PST Date: 20 DEC 1977 0807-PST Sender: WALKER at USC-ISI Subject: MSGGROUP# 624 Status Change (for Steve Walker) From: WALKER at USC-ISI To: [ISI]Mailing.List;143: Message-ID: <[USC-ISI]20-DEC-77 08:07:26.WALKER> It has been a long time since I have sent a message to this group but I have certainly enjoyed the dialog which has taken place here for the past two and a half years. In remembering all the things that have happened during that time, it is with a good bit of reluctance that I announce my departure from ARPA in late January for a position with the Undersecretary of Defense for Research and Engineering. In my new position I hope to be able to influence the acceptance by the Defense Dept of secure computer systems, interactive message systems and general networking capabilities. I plan to remain active on the ARPAnet and to maintain close contact with groups such as yours. I am personally proud to have been associated with the collection of people on the ARPA network who got this whole message handling, electronic mail thing started. Keep up your excellent work. Have a good holiday season. Steve Walker, ARPA ------- 20-DEC-77 17:21:58-PST,3097;000000000001 Mail-From: USC-ISI rcvd at 20-DEC-77 1721-PST Date: 20 DEC 1977 1656-PST Sender: DCROCKER at USC-ISI Subject: MSGGROUP# 625 [Dcrocker: [Re: Cost of using MS?]] From: DCROCKER at USC-ISI To: [ISI]Mailing.List;143: Message-ID: <[USC-ISI]20-DEC-77 16:56:15.DCROCKER> Sirbu, at MIT, just asked me about the cost of using the Rand message system. It occurred to me that we haven't much discussed that point, so I thought y'all might be interested in my response to him: Begin forwarded message -------------------- Date: 20 Dec 1977 at 1509-PST Subject: Re: Cost of using MS? From: Dcrocker at Rand-Unix To: Sirbu at Mit-Mc (Marvin A. Sirbu) cc: Dcrocker at Rand-Unix Message-ID: <[Rand-Unix]20-Dec-77 15:09:55.Dcrocker> In-Reply-To: Your Message of 20 DEC I do not have any real data on MS costs. It appears that the system's computational overhead is minimal, but that disk storage requirements for all message systems is quite high. Paul Baran, in a 1974 study for Arpa, had an Appendix which made estimates of messaging costs, using different technologies, of which computer-based tools were only a part. Standard cost was $5.00 - $6.00 per message. This assumed a very low cost for the primary worker (manager). I will replicate his table, below, but using some more likely numbers for the emerging architecture of message systems. The particular scheme he described in his report was of intelligent terminals doing direct-dial to each other. The probable future scheme is to have enhanced intelligent terminals connected through a local net to an area service computer which in turn is connected to other service computers through an Arpa-type net. My calculations assume fairly heavy use of the terminal by an individual (1-2 hours per day!). Less use would then require that the terminal be shared among people and this lessens its availability: Preparation (10 min) $1.20 Addressing (.5 min) .10 Transmission (~instantly) .20 Very-Intelligent Terminal ($100/mon) 1.00 Receiver reads message 1.00 ----- $3.50 These figures are obviously highly optimistic with respect to the cost terminals in the future. I suspect that Baran's original cost range would be an apprpriate estimate for current "production" message systems. For example, the Tymnet people claim computer costs of under a dollar (and possibly as low as tweny cents) for using OnTym. Critical to the term "production" is the degree to which the system has been optimized to reduce unecessary computation and storage. By the way, Baran's report was CableData R-160, and was the Second Quarterly Technical Report, Arpanet Management Study: New Application Areas. Appendix G is the one cited, and it elaborates the derivation of some of the numbers. Note that the above estimates show a bottleneck with human preparation and reading time. I doubt that we will be able to get below the above numbers. Dave. -------------------- End forwarded message ------- 3-JAN-78 12:52:49-PST,1979;000000000001 Mail-From: USC-ISI rcvd at 3-JAN-78 1252-PST Mail-from: SRI-KL rcvd at 21-DEC-77 1215-PST Date: 21 Dec 1977 1213-PST Sender: PANKO at SRI-KL Subject: MSGGROUP# 626 Message Costs From: PANKO at SRI-KL To: msggroup at USC-ISI Cc: panko Message-ID: <[SRI-KL]21-Dec-77 12:13:09.PANKO> Redistributed-To: [ISI]Mailing.List;144: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 3 JAN 1978 Just a short note on costs to follow Dave Crocker's message. As some of you know, I am doing a cost/benefits study on computer mail for a client. This work will involve a cost analysis. I hope that some of the cost analysis will be made available in six to twelve months. In this December's 1977 National Telecommunications Conference, there was a session on computer mail that included some cost information. In my paper, I noted that there were three different types of computer mail. Telex/TWX replacements offer few functions but cost only a dime or so per message. Commercial mail systems offer some ARPANET-style functions but cost about $0.70 per message. ARPANET mail systems for which I have hard data seem to cost about $6 per message. I can't comment on Dave's numbers, because he makes a number of assumptions that differ from the data I have from other systems. One comment on the ARPANET costs. The $6 per message figure assumes that you are using a centralized PDP-10-KA computer accessed via a commercial network like Telenet. If you have a distributed architecture with many local PDP-10s, and if you use KL technology PDP-10s, the per message cost would be around $2. As Dave's note indicated, the terminal cost begins to dominate if you make what I consider to be reasonable assumptions about usage (a half hour per day). To me, this indicates that we need many dumb terminals scattered around the office, not a few expensive and centralized intelligent terminals. Ra3y ------- 6-JAN-78 06:33:41-PST,705;000000000001 Mail-From: SRI-KL rcvd at 6-JAN-78 0633-PST Date: 6 Jan 1978 0628-PST Sender: PANKO at SRI-KL Subject: MSGGROUP# 627 FORTRAN/machine language conversion From: PANKO at SRI-KL To: msggroup at ISI Cc: panko Message-ID: <[SRI-KL] 6-Jan-78 06:28:41.PANKO> A number of message systems (most, in fact) are written in fairly high level languages, like FORTRAN or SAIL. Some of these could be rewritten in machine language and even put on computers with stripped-down executives to reduce overhead. Does anybody have any idea about the relative running speeds or costs of such conversions? What I'd really like is some sort of formal study results, but I'm realistic. Aloha, Ra3y ------- 28-JAN-78 12:28:21-PST,655;000000000001 Mail-From: BBN-TENEXB rcvd at 17-JAN-78 1457-PST Date: 17 Jan 1978 1528-EST From: PANKO at BBN-TENEXB Subject: MSGGROUP# 628 Minicomputer System Projections To: [ISI]Mailing.List;145: cc: rulifson at PARC-MAXC, taylor at PARC-MAXC, cc: sutherland at PARC-MAXC Has anyone in the group seen a study that projects the costs of minicomputer systems to 1980 or 1985? I am only interested in total system costs, not component costs such as the LSI CPU. Basically, I am trying to project the costs of minicomputer-based message systems, such as OnTyme, MS, or EIES, to 1980 and 1985. Mahalo (Thanks) and Aloha, Ra3y ------- 30-JAN-78 23:57:20-PST,556;000000000001 Mail-From: USC-ISI rcvd at 30-JAN-78 2357-PST Date: 30 JAN 1978 2337-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 629 Add INFOMEDIA(Vallee), Pool, Schlaff, Schill, Jordan From: MSGGROUP at USC-ISI To: [ISI]Mailing.List;146: Cc: INFOMEDIA at BBN, Pool at BBN, Schlaff, Schill at ISIE, Cc: Jordan at KL Message-ID: <[USC-ISI]30-JAN-78 23:37:55.STEFFERUD> Welcome to Jacques Vallee of INFOMEDIA, James Pool of the Dept. of Energy, Dick Schlaff and John Schill of the Navy, and Dale Jordan of TYMSHARE. Best - Stef ------- 31-JAN-78 20:41:19-PST,491;000000000000 Mail-From: USC-ISI rcvd at 31-JAN-78 2041-PST Date: 31 JAN 1978 2041-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 630 Dropping GEdwards@SRI-KL, LeDuc@SRI-KL, VU@SRI-KL From: MSGGROUP at USC-ISI To: [ISI]Mailing.List;147: Message-ID: <[USC-ISI]31-JAN-78 20:41:06.STEFFERUD> If you want a fresh copy of the full mailing list after all the recent changes, just request it by return netmail. Or FTP a copy from [isi]mailing.list Best - Stef ------- 6-FEB-78 20:56:37-PST,499;000000000000 Mail-From: USC-ISI rcvd at 6-FEB-78 2056-PST Date: 6 FEB 1978 2048-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 631 DROP Perlingiero, MOVE WMartin, Walsh, Zellich From: MSGGROUP at USC-ISI To: [ISI]Mailing.List;148: Message-ID: <[USC-ISI] 6-FEB-78 20:48:06.STEFFERUD> Could that be spring in the air with all these changes blooming? Perlingiero@BBN appers to have gone off the net. WMartin, Walsh, and Zellich have moved onto OFFICE-1 from SRI-KL. Stef ------- 8-FEB-78 18:07:17-PST,2662;000000000001 Mail-From: BBN-TENEXB rcvd at 8-FEB-78 1807-PST Date: 8 Feb 1978 2054-EST Sender: PANKO at BBN-TENEXB Subject: MSGGROUP# 632 Special Journal Issue on Computer Mail Subject: MSGGROUP# 632 Specifics on Computer Networks Computer Mail Issue From: PANKO at BBN-TENEXB To: [ISI]Mailing.List;145: Cc: brulifson at PARC-MAXC, rulifson at PARC-MAXC Message-ID: <[BBN-TENEXB] 8-Feb-78 20:54:11.PANKO> I am guest editing a special issue on computer mail in Computer Networks. This is Phil Enslow's journal. The issue will bring together five to eight papers on various aspects of computer mail. If you have a paper or a hot idea, I'd like to hear about it. I'd like to put this issue together fairly quickly. Aloha, Prof. Raymond R. Panko College of Business Administration University of Hawaii at Manoa 2404 Maile Way Honolulu, HI 98622 Ra3y ------- Mail-From: BBN-TENEXB rcvd at 15-FEB-78 1609-PST Date: 15 Feb 1978 1908-EST Sender: PANKO at BBN-TENEXB Subject: MSGGROUP# 632 Specifics on Computer Networks Computer Mail Issue From: PANKO at BBN-TENEXB To: msggroup at USC-ISI Cc: panko Message-ID: <[BBN-TENEXB]15-Feb-78 19:08:44.PANKO> Some ground rules: Computer Networks special issue on computer mail. Computer Networks is assembling a special issue on computer mail. The guest editor will be Prof. Raymond R. Panko of the University of Hawaii. The special issue will have four to six main articles. About half of these will be overview papers, discussing trends in computer mail. The other half will be technical articles stressing cost analysis, behavioral studies, technical specifications of systems, and things of that ilk. There may also be a brace of four to eight minipapers, covering important issues and facts. Each would be one to three typewritten pages in length. All papers will be reviewed, and authors will be expected to be responsive to reviews. Selection of papers will be based first on inherent quality and second upon the need to balance technical and overview papers. Due to space limitations, not all papers may be accepted. All papers must be received for review by May 1, 1977. If you are interested in submitting a paper, please write to Prof. Panko at the address below and request an author's information package. All statements in this announcement should be regarded as subject to change. Prof. Raymond R. Panko, College of Business Administration, University of Hawaii at Manoa, 2404 Maile Way, Honolulu, Hawaii, 96822, USA ------- 15-FEB-78 16:26:43-PST,684;000000000000 Mail-From: BBN-TENEXB rcvd at 15-FEB-78 1626-PST Date: 15 Feb 1978 1912-EST Sender: PANKO at BBN-TENEXB Subject: MSGGROUP# 633 Ground Rules on Computer Network Special Issue From: PANKO at BBN-TENEXB To: [ISI]Mailing.List;148: Message-ID: <[BBN-TENEXB]15-Feb-78 19:12:38.PANKO> If you are interested in submitting a paper to the special issue of Computer Networks dealing with Computer Mail, please send me a message, and I will send you a copy of the ground rules. I have also sent a copy of the ground rules to msggroup at ISI. Aloha, Ra3y (p.s. This will be the last message on the special issue that will be sent to the full MSGGROUP.) ------- 22-FEB-78 23:54:21-PST,1930;000000000001 Mail-From: CMU-10D rcvd at 21-FEB-78 1449-PST Date: 21 Feb 1978 1750-EST From: RICK GUMPERTZ at CMU-10D (N810RG02) Subject: MSGGROUP# 634 proposed Federal Information Processing Standard To: Header-People at MIT-MC, MsgGroup at USC-ISI, Wactlar at CMU-10A, Wulf at CMU-10A, Feinler at SRI-KL, Roach at MIT-Multics, Tavares at MIT-Multics, Newcomer at CMU-10A, Saltzer at MIT-Multics CC: Gumpertz @ CMU-10a Reply-To: Gumpertz @ CMU-10a Message-ID: <21Feb78 175050 RG02@CMU-10D> Redistributed-To: [ISI]Mailing.List;149: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 23 FEB 1978 People: I am sending this to everyone I can think of who might be interested or might know of appropriate people to be forwarded to. Please feel free to forward this note to anyone whom you think it concerns. (aside to Jake: please forward this to the ARPANET liason list) I have recently discovered that the National Bureau of Standards published in the Federal Register (available at most major libraries) for 12 December 1978 (pp. 62408-16) a proposed standard for logging into and out of interactive computer systems. It claims to apply to all systems which will be used by a "Federal Government user" (whatever that is!). Not only does it specify to the word what messages will be generated, it flagrantly violates ASCII by suggesting a new meaning for the DLE code. Although I am sure some well meaning person put a lot of work into writing this document, I don't really think it is suitable as a FIPS. The first notice that I found of this standard was in "Minicomputer News", which may seem a rather unlikely source. To make things worse, the deadline for comments is 13 March 1978! Please try to get hold of a copy (if you are concerned with such things) and comment to NBS as soon as possible. Richard H. Gumpertz ------- 22-FEB-78 23:54:21-PST,2597;000000000001 Mail-From: CMU-10A rcvd at 21-FEB-78 1725-PST Date: Tuesday, 21 Feb 1978 2027-EST From: Brian K. Reid Subject: MSGGROUP# 635 Re: proposed Federal Information Processing Standard To: Header-People at MIT-MC, MsgGroup at USC-ISI, Wactlar at CMU-10A, Wulf at CMU-10A, Feinler at SRI-KL, Roach at MIT-Multics, Tavares at MIT-Multics, Newcomer at CMU-10A, Saltzer at MIT-Multics, Sproull at CMU-10A CC: RICK GUMPERTZ at CMU-10D (N810RG02) In-Reply-To: <21Feb78 175050 RG02@CMU-10D> Redistributed-To: [ISI]Mailing.List;149: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 23 FEB 1978 Some highlights of this proposed standard: - [The System Signal] is generated by a computer, and indicates to the user that the next action is up to the user. . . . The system signal shall be generated so as to print or display the colon character (:) at the left margin of a line following a previously printed or displayed line of system message text." - "This Standard comes into play the instant there is established the capability of recognizable character transmission and receipt by a user's terminal. Thus, no commands, requests or messages may be presented to or accepted from a user between the time that the user approaches the terminal and the time that this Standard governs what the user sees and does." - The default value for the exit request signal is DLE [^P]. The exit request signal shall be recognized by the system at any time during the operation of a computer service or during the access procedures when the user is permitted to enter input." From the Introduction: "Just as the number and variety of users has grown, so has the number and variety of computer services, both within and outside the Federal Government. But while the services are no longer in their formative stages, users who choose to deal with more than one are still being asked to overlook differences that strike them as being frustrating and annoying....Specifically, this standard is intended to stem the proliferation of access -- entry and exit -- procedures, and to establish a single set of procedures that will have widespread applicability." "APPLICABILITY. The procedures specified in this standard apply to all user-terminal interactions where a Federal Government user is seeking access to or exit from one or more computer services." ------- 23-FEB-78 11:50:32-PST,349;000000000000 Mail-From: USC-ISI rcvd at 23-FEB-78 1150-PST Date: 23 FEB 1978 1128-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 636 Add HIXON@ISIA, Change PANKO@KL to be PANKO@BBNB From: MSGGROUP at USC-ISI To: [ISI]Mailing.List;149: Cc: Hixon, Panko at BBNB Message-ID: <[USC-ISI]23-FEB-78 11:28:31.STEFFERUD> THANKS - STEF ------- 24-FEB-78 17:02:25-PST,1078;000000000001 Mail-from: CMU-10A rcvd at 24-FEB-78 1702-PST Date: 24 Feb 1978 1652-EST From: Rick Gumpertz at CMU-10A Subject: MSGGROUP# 637 [Watkins@NBS-10: FIPS Standard replies] To: PBARAN at USC-ISI, MsgGroup at USC-ISI, Header-People at MIT-MC Message-ID: <24Feb78 165218 RG02@CMU-10A> Redistributed-To: [ISI]Mailing.List;149: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 25 FEB 1978 I just got this -- Rick - - - - Begin forwarded message - - - - Date: 24 Feb 1978 (Friday) 1647-Est From: WATKINS at NBS-10 Subject: FIPS Standard replies To: Feinler at SRI-KL cc: Gumpertz at CMU-10A If network mail is sent to me (Watkins@nbs-10) concerning the proposed standard, I will print it out and forward to the proper person. I will not be able to do more than simply print it out on a line printer, so if anyone is concerned with formatting and type quality be forewarned that the transmission medium will be line printer type and paper. Shirley - - - - End forwarded message - - - - ------- 3-MAR-78 22:51:22-PST,1315;000000000001 Mail-from: SUMEX-AIM rcvd at 3-MAR-78 1231-PST Date: 3 Mar 1978 1155-PST From: Kahler at SUMEX-AIM Subject: MSGGROUP# 638 FIPS Proposed Standard Sample Session To: [ISI]Mailing.List;149: cc: Header-People at MIT-MC To my understanding, this is what a typical terminal session might look like under the proposed standard. If this message takes a lot of paper, well, so will logging in and out under this proposal. Line editing, by the way, is not provided, or even anticipated. For all I know, we are expected to be perfect typists. [Signal your communications network (in this case the local TIP) that you want service and identify your terminal, then...] [TIP may type out a "network information message" identifying the TIP and the ARPA network] Abbreviated form - Yes or No? :No [User may also type HELP, ?, or LIST] Enter destination :SUMEX-AIM SUMEX-AIM is available Enter identification :Smith Enter password :password [Either not echoed, underprinted or overprinted] ["Service operation" commences] . . . [User types ^P at some point to exit] ^P Enter one of the following: Terminate or Leave or Stay or Suspend :T Smith has terminated SUMEX-AIM at date/time [Optional accounting stuff] END Rich ------- 3-MAR-78 22:51:23-PST,11962;000000000001 Mail-from: MIT-AI rcvd at 3-MAR-78 2120-PST Date: 4 MAR 1978 0014-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP# 639 Strong Reaction to FIPS Proposed Standard To: watkins at NBS-10, pyke at NBS-10 CC: Roach at MIT-MULTICS, Tavares at MIT-MULTICS CC: Saltzer at MIT-MULTICS, Feinler at SRI-KL, Wulf at CMU-10A CC: Wactlar at CMU-10A, Newcomer at CMU-10A, msggroup at USC-ISI CC: header-people at MIT-MC Redistributed-To: [ISI]Mailing.List;149: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 3 MAR 1978 I am not certain that I will be able to find the mental wherewithal to mail an actual US mail letter within a week. I hope that whoever is designing the standard is not legally prohibited from taking into account any knowledge that he gets via unofficial channels (though I wouldn't be surprised if the government were so cretinous). Here is the story: The operations which the login/logout standard is trying to standardize have no resemblance to the actual operations performed by users of most timesharing systems. IF it is true that the user is going to specify a service, his name, and a password, then the standard is fine as a way of doing it. But that isn't usually the case. Problems with the standard for Login: I know of no system except Multics in which the user says ANYTHING about what he intends to do before he logs in. If we interpret a "service" to mean the use of one or more programs, then the user does all the specification of the services he wishes to use AFTER logging in, on most systems. It would be horrible to be forced by a standard to restrict him! If, as the standard perhaps (it's not clear) suggests, a service is a large number of programs that can be used together or sequentially, than most timesharing systems offer only one service: the entire set of programs available on the machine. Thus, there is no point in asking the user to specify the service in advance. "Hello, welcome to ITS. What service would you like: ITS or ITS?" So far, things would be OK if only the "destination" specification could be omitted by the 99% of all systems which don't want it. But there is an additional problem: most systems provide "service" to the user BEFORE HE LOGS IN. Commercial systems such a Bottoms-10 and Twenex allow the user to run some programs such as SYSTAT or talk to the operator before logging in. Since the user does this exactly the same way he would do it if he WERE logged in, clearly the system is not doing anything special; it is just providing a restricted subset of the same (unique) service which it provides to logged-in users. On my system, ITS, it's even worse. Essentially complete service is available to whether you log in or not. This is deliberate and provides benefits to the user. But the login standard says that the computer MUST make the user log in as the very first thing he does, not giving him a chance to ask to do anything else. And when the ITS user decides to log in, he does so by typing a command, using the same syntax used for other commands. The command syntax used is ": ". Clearly it is better for the user to have a consistent syntax available for all commands including the :LOGIN command. Problems with the standard for "exit requests": As for the "exit request", its format limits the flexibility of the operating system and limits its architecture. I will describe each of the three operating systems for the PDP-10 and how it would be affected. Note that the problems depend on whether a "service" is a single program invocation or a whole session; I will describe separately the problems resulting from each assumption. ITS and Tenex/Twenex, if each program is a "service": On ITS and Tenex/Twenex, the user's "system commands" are actually read by a top-level command-reading program, a user-mode program distinguished very little from other programs run by the user. It creates inferior jobs and runs programs in them as specified by the user. Now, of course, there is a character to interrupt an inferior job and give more commands to the top level. If we regard each invocation of a program as a distinct service, then it is analogous to what the standard calls an "exit request". On ITS it is ^Z (Control-Z); on Tenex/Twenex it is ^C. It could conceivably be ^P, if that weren't already used for other things. But what it does is not the same as what the standard says about exit requests. It simply stops the inferior and lets you give more commands. You can give a command to continue (like "stay"), or a command to log out (like "terminate"). On Tenex/Twenex, you can run some other program, analogous to "leave". On ITS, you can run some other program, but it is analogous to "suspend" since ITS's top level allows up to 8 inferiors and all are independent. If you want to get rid of your old service, you must explicitly kill it. ITS also allows you to do other things, such as tell the program to run, but without control of the terminal (good for an assembly with its error output diverted). Of course, on both systems you can give innumerable other commands to communicate with other users, inquire about the system status, list your directory or delete or copy files, etc. without interfering with the job you have exited from. You aren't forced to say what to do with it right away; you can attend to other things and decide its fate whenever it is convenient for you. This is especially true on ITS, where absolutely anything else you do will not interfere with the status of the suspended program unless you explicitly kill or restart it. This power is very convenient, but it is forbidden by the standard, assuming once again that each program invocation is a service. ITS and Tenex/Twenex, if a whole session is a "service": If each program invocation is NOT a distinct service, then the whole session is one service-invocation, and the exit request can only be interpreted as a request to log out. On ITS and Tenex/Twenex, the way to log out is to give the appropriate command to the top-level program, which executes a logout system call in response. First, you must interrupt the inferior you are using, if necessary. The standard appears to require that a ^P be interpreted, at all times (not just when you are talking to the top level), as a request to log out. This can only be done by making ^P give control to the top level. This is an imposition on the character set available for inferior jobs; they can't use ^P for anything. Since the character for exitingthe inferior has to exist anyway, and logging out can be done with that followed by a command to the top level, the imposition is totally unnecessary. It is also somewhat of a screw. On ITS, you can run the usual top-level as an inferior, and command it to run sub-inferiors. It behaves totally as usual, except that it can't log in or out. The inferior-escape ^Z works with it too, since it really goes up one level rather than to the top. ^P, on the other hand, would have to go all the way to the top. This is rather untasteful. Also, logging out is not something done frequently, and, from an information-theoretic standpoint, it should not have a particularly short command. There are a dozen things I do far more often than log out. Should each one have a character to request it, which works all the time? They each deserve one more than logging out does. But better is not to give a special character to any of them. The top level program has commands for them all; I need only type ^Z or ^C to get back to it, and give the command. Finally, since ITS offers only one service ("ITS") and Tenex/Twenex offers only the "Tenex" or "Twenex" service, what is the meaning of "Leave"? Bottoms-10: So much for ITS and Tenex/Twenex. For Bottoms-10, the architecture is simpler - there is "the user's program" and there is the "system command level" - so there are no problems there. But the other problems - that the existing system is much more flexible than the standard allows - are the same. You type ^C or ^C^C to stop a program. ^C makes it stop only as soon as it waits for input. ^C^C stops it right away. This distinction is very useful and nobody would like having to give it up. Then, you can restart the program or run something else, or do various other things before you have to make up your mind. When you do decide, you speak your mind by giving a command, in the same syntax that system commands always use. This internal consistency is certainly valuable. It can't fit in with the logout standard, though, since the standard is designed for a situation where the possible user commands form a very limited set. So much for what happens if each program is a distinct service. If the whole session is one service, the problems are again similar to those of ITS and Tenex/Twenex. You log out by giving a system command, if necessary typing ^C or ^C^C first so you can give system commands. If ^P were to be effective at all times, it would be an additional superfluous way of exiting a user program. And again, logging out isn't frequent enough to need such special treatment. Conclusions: The conclusion is that the standard assumes that systems differ only in minor details from a specific model of interactions, and attempts to standardize the minor details. This assumption is false; the model used differs more from most timesharing systems than the systems differ from each other! In fact, the only systems I know of which actually fit the model assumed by the standard are the TIPs, ELFs, and other systems which exist only for communication with other systems. A user of the TIP might indeed specify his "destination" first of all, and then give his user name. Of course, TIPs don't ask you for a user name. So the model seems to fit only the composite interaction in which the TIP asks you for your destination, and connects you, and the machine you are connected to asks you for your name. The TIP also does have an escape character with which you can at any time close your connection to "leave" or "terminate". So I think that the proposed standard needs major rethinking. If what you want is a standard for TELNET programs and their command syntaxes, you should call it that, and not say that it applies to loggin in and out of timesharing systems. Questions: I would like to know your specific attitudes toward the problems I have mentioned. For example, do you think that standardization is so important that it outweighs all these disadvantages? Or do you think that the disadvantages don't exist? Do you consider a "service" to be a single program, or a session? Which systems did you have in mind when you formulated the standard? What, exactly, is a "Federal user"? Is everyone funded by ARPA a Federal user? What if ITS decides that the unspecified preamble for establishing communication consists of "^Z :OWATABUBIAM"? Is that within the standard? I will be glad to try to send you a US mail copy of this if it is important, though I can't promise success. Should I? What will that accomplish? Please send the answers to these questions to all the recipients of this message. Plea: PLEASE, PLEASE allow more time for comments, even a week more. Much of the ARPANET community learned about the proposed standard less than a week ago (Nobody makes a habit of reading the Federal Register here). It takes time for a person to articulate his thoughts. Everyone who has seen the standard here has been so shocked that he couldn't think. I am the first to recover enough to say anything coherent. My friends are so stunned they can't find words! ------- 4-MAR-78 23:50:02-PST,3529;000000000000 Mail-from: SU-AI rcvd at 4-MAR-78 2340-PST Date: 4 Mar 1978 2309-PST From: GFF at SU-AI (Geoff Goodfellow) Subject: MSGGROUP# 640 News artical about ViewData in London england To: MSGGRP.LST[G,GFF]: CC: pc at RAND-UNIX a298 2016 28 Feb 78 AM-Viewdata,510 By A.O. SULZBERGER JR. Associated Press Writer LONDON (AP) - The British Post Office, which also is responsible for communications systems, announced Tuesday that by 1979 - a year earlier than originally planned - it will provide computer data service to anyone with a telephone and a television set. Post Office Telecommunications chief Peter Benton said a test of the Viewdata computerized information service will begin in June with 1,500 subscribers in London, Birmingham and Norwich. Britain has budgeted $44.85 million to phase in Viewdata, which the Post Office calls the world's first publicly available computer data system. About $10 million of that will be spent on the trial. Viewdata's developers hope the system will bring the computer into every British home or office equipped with a television set and a telephone. It will allow subscribers to call up information stored in a central computer memory and display it in words and diagrams on a television screen. A hungry and thirsty tourist in a London hotel with a Viewdata terminal in the room would pick up the phone, which is linked to a central computer, and press a few buttons on a unit the size of a calculator. The page entitled ''Eating and Drinking'' would appear on the television screen. Instructions show how to narrow the range until the names of best pubs and restaurants in a given area - Chelsea, for example - appear on the screen. The same process can theoretically be used to book a seat at a soccer match in Leeds, or get train and plane schedules, help with taxes or the latest international price for tobacco or tomatoes. The British Broadcasting Corp. and the Independent Broadcasting Authority have private services that provide information in much the same manner as Viewdata, but these are limited to between 3,000 and 6,000 users. The major cost of Viewdata to the consumer is the initial investment. Television sets capable of receiving Viewdata now cost about $1,365, but this is expected to drop as the receivers go into mass production. Rentals will be available. Other costs will be the normal price of the phone call and perhaps a service charge for the information. This charge would be indicated on the page of information and included in the telephone bill. The system was developed by the Post Office Research Center's Computer and Mathematics Department headed by Sam Fedida, 59, described as Viewdata's inventor. So far it has cost about $2.7 million. During the Viewdata trial, users will have 60,000 pages of data provided by about 100 organizations including the British railroad system, the Financial Times newspaper, the Guiness Book of Records and the Consumers' Association. The system also will offer information on job vacancies and educational opportunities. Current forecasts call for 2.5 million sets throughout Britain to be linked to the Viewdata network within seven years, by which time the system should have a capacity of 250,000 pages of information. The Viewdata program has been sold to West Germany and there are plans to introduce it into the United States. ap-ny-02-28 2316EST *************** ------- 9-MAR-78 11:23:56-PST,2118;000000000001 Mail-from: SU-AI rcvd at 6-MAR-78 1314-PST Date: 6 Mar 1978 1311-PST From: MRC at SU-AI (Mark Crispin) Subject: MSGGROUP# 641 FTP DOCUMENTATION (continued from header-people) To: MsgGroup at USC-ISI, Header-People at MIT-MC To: Feinler at SRI-KL, Postel at USC-ISIB Redistributed-To: [ISI]Mailing.List;149: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 9 MAR 1978 The responses I have received so far seem to indicate that the new FTP protocol is not implemented by anybody, and that there are enough differences between the new and the old FTP protocols so that a different type user and server probably could not talk to each other effectively. Additionally, the people who replied to me were unanimous in their feelings that the new protocol should be flushed and replaced with a well-documented version of the old protocol. The feeling seemed to be that if any changes were necessary to the protocol, it should be in the reply codes to ensure standardization and to make them more esoteric. Because of this, I am asking the network hacker community if anybody is interested in forming a new "FTP group", to be charged with the responsibility NOT to design a new FTP protocol, but rather to get an agreed-upon standard documentation for the old protocol and possibly change the sense of some of the reply codes. The FTP protocol that results from this group's efforts is to conform to the reality of today, instead of generating a protocol that someday might be reality. The only changes to existing programs should be ones which are to correct what are violations of protocol today. What does everybody think? Jake and Jon, please forward this to the RFC and network liaison groups; and please also inform us what the chances of this project meeting with official sanction? I really believe that having a documented protocol which nobody implements while the implemented protocol is undocumented is intolerable; and I hope it isn't a case of an immovable object and an irresistable force. regards, -- mark ------- 9-MAR-78 11:23:56-PST,1173;000000000001 Mail-from: MIT-MC rcvd at 6-MAR-78 1657-PST Date: 6 MAR 1978 1948-EST From: KLH at MIT-MC (Ken Harrenstien) Subject: MSGGROUP# 642 RE: FTP DOCUMENTATION & RFC691 To: mrc at SU-AI CC: HEADER-PEOPLE at MIT-MC, MsgGroup at USC-ISI Redistributed-To: [ISI]Mailing.List;149: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 9 MAR 1978 Read RFC 691. It should be available from SRI-KL as RFC691.TXT. It has been around for quite a while, proposes ways in which the advantages of new FTP can be obtained with old FTP, and other good stuff. Probably it has not been pushed as much as it should have been because the author (Brian Harvey) took off for Paris for a couple years shortly after writing it. However, in one of my recent RFC's (XRSQ/XRCP, #743) I explained my position on reply codes, pointed out the 3 possible sets, and declared intent to use 691's - and nobody has commented. So perhaps the answer is that nobody reads RFC's. In any case the preface to the "new FTP" document lists RFC numbers which you can look up (or ask the NIC for) to get the scoop on old FTP and bickering thereof. ------- 12-MAR-78 14:29:23-PST,546;000000000001 Mail-from: SUMEX-AIM rcvd at 10-MAR-78 1750-PST Date: 10 Mar 1978 1735-PST From: Kahler at SUMEX-AIM Subject: MSGGROUP# 643 Great big long message coming To: [ISI]Mailing.List;149:, Header-People at MIT-MC, To: Roach at MIT-MULTICS, Saltzer at MIT-MULTICS, To: Tavares at MIT-MULTICS, Sproull at CMUA, Wulf at CMUA I wrote six pages of comments for the proposed FIPS which I will be sending to Shirley Watkins at NBS-10 and copying to you. I spent a lot of time on it, I hope it is read at NBS. Rich ------- 12-MAR-78 14:29:23-PST,1460;000000000001 Mail-from: SU-AI rcvd at 10-MAR-78 1810-PST Date: 10 Mar 1978 1809-PST From: MRC at SU-AI (Mark Crispin) Subject: MSGGROUP# 644 FIPS standard To: Watkins at NBS-10 CC: RWG, MsgGroup at USC-ISI Redistributed-To: [ISI]Mailing.List;149: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 12 MAR 1978 Shirley, I sent in a comment about the proposed standard. I understand that it will not be accepted unless US mailed and signed (ugh). I didn't keep a copy of it. If necessary I will try to remember what I said and sign it and (ugh) US mail it; however, Richard Stallman (RMS@AI) has written a much better description as to why the standard is a loser and for the most part I would be saying over again his points. Hopefully the people at NBS will take Stallman's comments seriously. The entire idea of even having a standard is bad for many reasons; it forever restricts the architecture of new operating systems, but the proposed standard is one of the worst possible implementations of this bad idea that could have been designed. It is my sincere desire that not only will the proposed standard be abandoned, but the idea of having a standard at all as well. I suspect that if such a standard ever was made official, it would be openly violated by everybody--it would be only words on paper that ever so often implementors would be harassed about. -- Mark ------- 12-MAR-78 14:29:23-PST,16192;000000000001 Mail-from: SUMEX-AIM rcvd at 10-MAR-78 1922-PST Date: 10 Mar 1978 1818-PST From: Kahler at SUMEX-AIM Subject: MSGGROUP# 645 Comments on proposed FIPS for user-terminal protocols To: Watkins at NBS-10, pyke at NBS-10 cc: [ISI]Mailing.List;149:, Header-people at MIT-MC, cc: Roach at MIT-MULTICS, Saltzer at MIT-MULTICS, cc: Tavares at MIT-MULTICS, Sproull at CMUA, Wulf at CMUA Redistributed-To: [ISI]Mailing.List;149: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 12 MAR 1978 March 10, 1978 Associate Director for ADP Standards Institute for Computer Sciences and Technology National Bureau of Standards Washington, DC 20234 Comments regarding the proposed Federal Information Processing Standard entitled "User-Terminal Protocols -- Entry and Exit Procedures between Terminal Users and Computer Services", found in the Federal Register for Monday, December 12, 1977, pages 62408-62416: I wish to suggest several ways to increase the flexibility of the standard so it may better "benefit the users of computer services" and "in so doing impose minimal constraints upon the suppliers of computer services" (from the introduction, page 62408). These suggestions fall under the following categories: 1. User waiver of the standard's requirements 2. Who handles what? 3. Flexible ordering of system messages 4. Line editing 5. Exit-choice message 6. Available help 7. Multiple communications networks 8. Linefeeds USER WAIVER OF THE STANDARD'S REQUIREMENTS The protocol specified in the proposed standard is intended, and should be intended, for the use of computer novices and infrequent computer users who need a simple, understandable, predictable means of reaching their destination. As I understand it, there is no reason to require that more experienced users use the same protocol. Computer services do make a great variety of tools available to users during the entry/exit process with which the novice need not concern him or herself, but which the more experienced user finds very valuable. It is not the purpose of the standard to provide all these tools in a standard fashion. Neither do the goals of the standard make it in any way necessary to deny the experienced user access to these tools. We therefore need to provide in the standard a means for the user to waive its requirements and interact with the computer service in its own language and on its own terms, as is now the case, in order to have the full power of the computer service available to him or her. For example, make the word "WAIVE" and/or an "escape signal" such as the ASCII ESC code an acceptable user response to any of the system prompts specified in the standard, at which point the user will be able to interact with the computer service as though this standard had never been in force. This implies, of course, that the exitrequest signal will not be recognized by the computer service as such. That in fact is what would be desired by such a user, otherwise, the waiver would only be a partial one. Let the waiver be an implementor option. The implementor need not provide an alternative means of entry and exit outside the standard, but should be free to do so. All implementors of course do so now, since there is no standard in force at this time. WHO HANDLES WHAT? The definition of "computer service" provided in Appendix B and the rigid destination-userID-password sequence provided in the body of the proposed standard are the source of serious confusion. Is the user to be required every time to interact with a terminal telecommunications network which prompts him or her for a computer service name (destination) and then makes the connection, whereupon the computer service requests user identification and password at its option? Or is the network required to obtain destination, userID, and password from the user and actually log the user in at the destination? (This would cause an uproar. It would require that the network control every computer service on every network it had access to. Computer installations would be unable to manage their own affairs.) Who is supposed to intercept the exitrequest signal, the computer service or the network? If the computer service, how will the user exit the network if the service malfunctions? If the network intercepts the signal (as it should, being closer to the user) how can the user exit from the computer service first using a means provided by the standard? Worse yet, is a destination, as some speculate, an individual program running under the operating system of a computer service? A separate login might then be required to run each separate program! (This does not seem to be the case in view of the definition of "computer service", but the definition itself (A coherent logical entity...) is too vaguely general for me to be sure.) What the drafters of the proposed standard envision may be entirely different than any of the above, in which case can it be called a clear, concise, well-thought-out document in view of the wide range of futile attempts to read its meaning? My conclusion, after all this, is that the standard's authors in the attempt to make the network's operations transparent to the user (see Appendix A) have themselves confused the operation of the network with the operation of the computer service. I would recommend that we remember that the network is a computer service in its own right, performing a valuable function for the user, yet physically and logically separate from the destination computer services it serves. Perhaps the inexperienced user doesn't need to know this, but we do. The definition of "computer service" needs to reflect this understanding and be more simply, concisely and understandably defined, perhaps as: "A computer running a program that interacts with a user through a terminal, sending messages to the terminal and accepting commands and data from the user." There are many computer services which do not deal with user terminals, but we are not concerned here with them. It is the network's task to obtain a destination from the user and make the connection. It is then up to the destination computer service whether or not to ask for user name and password before proceeding. If there is no network intervening, a destination request is superfluous. The exitrequest signal (or some panic signal, see below under multiple communications networks) must be handled by the computer service (network or otherwise) closest to the user. If a panic-exit signal is provided for the user, the exitrequest signal can be sent through to be handled by the most remote computer service in use at the time. FLEXIBLE ORDERING OF SYSTEM MESSAGES There are only three combinations of the three parts of the entry protocol allowed by the proposed standard: destination only, or destination-userID or destination-userID-password. In practice, any combination will come up. If the standard is to be designed so as "not to impede technological advancements in computer services and networks" (from the introduction, page 62408), much greater flexibility is needed. In my networking experience I have personally encountered: destination-ID, destination-ID / user-ID / user-password, destination-ID / destination-password / user-ID / user-password, destination-ID / destination-password, destination-password, destination-password / user-ID, destination-password / user-ID / user-password, user-ID, and, most frequently, user-ID / user-password. These are all legitimate and proper combinations, and more are possible. Can this variety be any source of confusion in the user's mind, provided that prompting for each is uniform? When the user is prompted for a destination, password, or anything else in a consistent fashion, it is clear what is wanted, the user supplies the information and the interaction proceeds. The user is happy and the implementor has the information he or she needs in the order he or she needs it. I suggest that no specific order be required. I also suggest that the prompt for user identification be "Enter user identification" rather than "Enter identification", since in the majority of cases this prompt will be the first given, and it would otherwise be ambiguous which kind of identification is required. LINE EDITING Line editing capabilities are entirely unaddressed by the standard. This is a serious omission, especially from the novice's point of view. Any standard which attempts to serve the needs of the terminal user should provide a means for the user to correct typing errors before giving the user signal. Uniformity in line editing practices for the interactions covered by this standard would be as beneficial to the novice as the standardization of the system messages required for them. I propose a minimum of two editing signals for standardization. These may be called cancel-last-character and cancel-entire-line. The cancel-last-character signal requests that the computer service cancel the last text character typed in, whereupon the next-to-last text (i.e. non-editing-signal) character typed in becomes the last. Repeated cancel-last-character signals eventually would cancel the entire line. The cancel-entire-line signal would ask the computer service to ignore all that has been typed in since the system signal was last given, optionally print " XXX " on the current line, and repeat the system signal. The system response to the cancel-last-character signal may take one of several forms. On display terminals, when terminal character- istics are known to a sufficient extent, the character may be erased from the screen. On other terminals, the cancelled character may be retyped, preceded or followed by a slash (/), or preferably surrounded by square brackets ([]). It is not difficult, when several characters are cancelled in succession, to delay the printing of the right square bracket until some other character than cancel-last-character is typed. A typescript showing :ABCDE[EDC]ACUS would, if retyped by the system, be :ABACUS. The user, in this case, had typed "ABCDE###ACUS", where "#" indicates the cancel-last-character signal. My suggestions for default values for these signals: cancel-last-character DEL (DELETE, RUBOUT) and/or BS (BACKSPACE, control-H) cancel-entire-line CAN (CANCEL, control-X) Two other useful editing signals are cancel-word and retype-line, but ASCII has no control codes set aside for these functions. Cancel-word cancels characters up to, but not including, a space or tab. Retype-line shows the user what the input line really looks like after editing has been done. cancel-word ETB (control-W) retype-line DC2 (control-R) EXIT-CHOICE MESSAGE The exit-choice message (whose format may well have been the result of careful deliberation): Enter one of the following: Terminate or Leave or Stay or Suspend : is too long to be typed out on a 110 or 300 baud terminal every time the user wishes to exit, regardless of the fact that abbreviations may be available. In practice, users often need or wish to exit quickly. I suggest: Enter exit choice (Type ? for help) : (which is bad enough), with the requirement that help be offered in the same fashion as with the abbreviated form request. Perhaps implementors can be given the option of implementing either the longer message with no help provided or the shorter message with help available. AVAILABLE HELP The interests of the user would indeed be served if HELP, ?, and LIST were acceptable user responses every time the user is prompted with the system signal, as with the abbreviated form request, so that the user may have help at any point. Such a consistent feature would be welcomed by many a confused user, and would likely be found in use at one time or another at every point at which it is offered. If not required it should at least be permitted. MULTIPLE COMMUNICATIONS NETWORKS When, for example, two networks are involved in the connection process to a destination, the standard should make it clear that the user needs to give the second network as the destination to the first network, then the real destination to the second network. The first network cannot be required to know the names of all destinations accessible from all connecting networks. If such a thing is meant to be required, let that be clearly stated. Implied requirements such as these, which upon examination prove to be unreasonable and unworkable, are of course unacceptable. They are evidence that the impact of the standard, first on implementors and then on users, is not well understood. This is another result of the effort to make the network(s) involved totally transparent to the user. When a network is invoked in the terminal communications process, it will identify itself, request a destination of the user and make the connection. Each network invoked in turn identifies itself and repeats this simple process. The user will know by this interaction that he or she is talking for that brief period to a network. The network must provide a means for a panic exit for the user's safety, and the user should be aware that when the exitrequest signal (sent all the way down the line to the final destination) doesn't produce any results, there is still a way out. The panic signal, though armed by all networks (unless the user has issued a waiver), will be trapped of course by the first network in the chain, which will perhaps initiate a normal exit-request sequence. This is the minimum awareness a user must have of the network. In my opinion, every user using a network needs to know this much for his or her protection. It need not be at all confusing to the novice when properly and simply explained and demonstrated. The novice need know no more about the presence of the network than this. Regarding a default value for the panic-signal, I would suggest what is probably one of the least used control characters in ASCII because it is more difficult to type. It cannot be typed by holding the CTRL key down and typing a letter. It is FS (control-backslash), octal 34, decimal 28. The ESC (escape) code, though it may seem appropriate, is too heavily used for program commands and setting terminal parameters to be armed for a special purpose throughout the terminal session. I do suggest it for user waiver of the standard protocol (see above), because it will only be recognized as such during an entry/exit sequence. LINEFEEDS A minor detail - the ASCII linefeed character (LF) should also be in the list of characters required to be displayed by the terminal. The ASCII carriage return character (CR) returns the carriage to the left margin on the current line. An LF must follow the CR to move the carriage down to the next line. Even though some terminals will do a CRLF combination every time they receive a CR, this is not ASCII, and is not desirable for such applications as underlining or overstriking text on a line-by-line basis. The confusion arises because in common practice when the user types the CR key on a full-duplex terminal it is echoed by the system as CRLF. The drafting committee needs to have experienced assistance from users and implementors who are familiar with existing terminal communications networks like the ARPANET and TYMNET. Otherwise it may come up with another proposed standard that is impractical to implement where networks are concerned. I hope you will give these comments careful consideration. Sincerely, Richard Q. Kahler SUMEX Computer Project TB105, Stanford University Medical Center Stanford, CA 94305 ------- 13-MAR-78 23:31:39-PST,1364;000000000000 Mail-From: USC-ISI rcvd at 13-MAR-78 2331-PST Date: 13 MAR 1978 2205-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 646 Anders Sandberg visits From: STEFFERUD at USC-ISI To: [ISI]Mailing.List;149: Message-ID: <[USC-ISI]13-MAR-78 22:05:43.STEFFERUD> Hi All - Last Saturday I met with Anders Sandberg of the University of Gothenburg, department of Business Administration, Vasagatan 3, s-411 24 Goteborg, Sweden. Tel. 46(031) 175300 Anders is visiting the US to learn about Organizational and Social Consequences of Computer-Communication Applications, including Word/Text Processing aspects. It has occurred to me that MsgGroup members might bee interested in meeting with him, and perhaps assisting him in making contacts et al. He will be in Los Angeles till Thursday, March 16th; in WAshington, D.C. from Tuesday, 21 Feb till Friday the 24th; and then to New York on Monday, 27th till 30th. He may go to visit the Univ of Mich and then to Sweden, or alternately go to Boston and then to Sweden, depending on developments along the way. I will serve as a point of contact as he goes along, if any of you would like to establish contact. I will depend on those of you who will be seeing him to check in with me so I may relay to you. If you are interested, please let me know. Best - Stef ------- 10-MAY-78 22:27:22-PDT,3435;000000000000 Mail-From: USC-ISI rcvd at 18-MAR-78 2241-PST Mail-from: CMU-10A rcvd at 12-MAR-78 1631-PST Date: 12 Mar 1978 1920-EST From: Brian K. Reid Subject: MSGGROUP# 647 Proposed FIPS standard for User-Terminal protocols To: Watkins at NBS-10, Pyke at NBS-10 CC: MsgGroup at ISI, Header-People at MIT-MC, Roach at MIT-MULTICS, Saltzer at MIT-MULTICS, Tavares at MIT-MULTICS Redistributed-To: [ISI]Mailing.List;149: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 18 MAR 1978 Associate Director for ADP Standards Institute for Computer Sciences and Technology National Bureau of Standards Washington, DC 20234 Re: Proposed FIPS entitled "User-Terminal Protocols -- Entry and Exit Procedures between Terminal Users and Computer Services" Sir or Madam: There are two difficulties with the proposed standard: (1) Technical problems with the details of the standard. (2) Administrative problems with the scope of applicability of the standard. I shall try to be brief rather than exhaustive. (1) The first point is just a couple of nits: - The DLE character (Data Link Escape) does not mean "escape from the data link", it means "begin an escape sequence" and is to be used by protocols within the data link. It is probably a very bad idea to have a single character be used to signal an exit request, but if you must use a single character, the correct one is probably EOT (End of Transmission). - There are no provisions for line and character editing: what is typed to erase a character or a line. (2) The second point is the meat of my comment. This standard is intended to apply to "Computer Services" It would be quite reasonable to standardize the login/logout procedure for turnkey user programs used by non-programmers, many of whom are hostile towards computer systems and want only the results of the user programs. For this set of computer users, namely those who are using canned software as a tool in the course of their daily work, there should be not only a standardized login/logout procedure but an attempt made to shield them from the knowledge that they are using a general-purpose interactive computer system. The authors of this standard have correctly noticed that users of turnkey software systems are often hostile towards the computers and annoyed at the differences that they find, but these turnkey system users, although numerous and influential, are not the only class of user of computer services procured by the Government. Programmers of any kind, whether Cobol trainees at HEW or assembly-language experts at some weapons lab, will be driven up the wall by this standard. The authors of this standard should recognize that these various classes of users exist, and should restrict the applicability of the standard so as to cover turnkey software services rather than all computer use. Brian K. Reid Graduate Student Department of Computer Science Carnegie-Mellon University Pittsburgh, PA 15213 ------- 10-MAY-78 22:27:22-PDT,5160;000000000000 Mail-From: USC-ISI rcvd at 18-MAR-78 2241-PST Mail-from: MIT-MULTICS rcvd at 12-MAR-78 2125-PST Date: 13 March 1978 0018-est From: Robert M. Frankston Subject: MSGGROUP# 648 Proposed FIPS for User=Terminal protocols To: Watkins at NBS-10, Pyke at NBS-10 cc: MsgGroup at USC-ISI, Header-People at MIT-MC cc: Roach at MIT-Multics, Saltzer at MIT-Multics cc: Tavares at MIT-Multics Redistributed-To: [ISI]Mailing.List;149: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 18 MAR 1978 Associate Director for ADP Standards Institute for Computer Sciences and Technology National Bureau of Standards Washington, DC 20234 While I find the concept of a standard for entering and exiting computer based services attractive in some ways, I feel that the current attempts are premature and beset by technical problems. The standard is both too constricting and too vacuous. The essense seems to be the specification of a single destination and establishment of the exit procedure. The core of the entry procedure seems to be the specification of a destination (a strange term for the name of a service). Only one service may be specified at a time. This is a basic fallacy since the use of a communications network is itself a service. In Tymnet, for example, one must identify oneself to the network for billing purposes and access control. This is more than what seems to be allowed for in carrier accommodation action (4.1.3). Of course, one can stretch the meaning of 4.1 to include logging into a computer system since that can be considered simply part of the establishment of a communication path, and in doing so defeat the standard. As has been ponted out by others, specification of the service before authentication is very arbitrary since one may not know which service is desired before authentication. As a matter of fact, in many systems, the name of the service is known only whithin a given users environment (i.e. is listed in the user's directory) thus cannot be known prior to authentication. The authentication procedure itself is limiting. Some systems, like Multics (Honeywell 68/80) combine procedures 4.4 and 4.5 into a single authentication procedure so that one cannot determine the validity of a name without also knowing its password -- an attempt at additional security. Since the definition of a service is so vague, Multics can even be considered to combine specification of the destination into the same procedure in that the user's project name is also specified during the authentication procedure. As has been pointed out by others, the exit procedure also has problems. Aside from the use of the DLE character in an unusual manner there is the issue of which service interprets the control code. Also the attempt to limit one's choices of exit procedures is premature. One important class of exits is completely omitted -- one in which the user can disconnect from a service, but leave the service running noninteractively. If the specification of the destination and the exit procedures are not acceptable, one is left only with the use of the ":" as a prompt to the user and the user of the return character to end messages to the computer system (oh yes, also the suggestion that upper and lower case distinctions be ignored -- a point of contention among existing systems). The user of, and choice of signal characters seems to be a minor issue at this point. It seems premature to enforce a rigid standard at this point that completely governs the entry and exit procedures. The attempt to provide a uniform interface for users of computer systems seems, however, to be a reasonable goal. Perhaps the failure of the standard is its meekness. It requires that each computer system and service be modified to present a uniform interface geared to the lowest common denominator of terminals and classes of service. A bolder approach is to associate the smoothing of the interface with the terminal that can be personalized to the user's needs. What is requred is a set of high level protocols for communication between a user's terminal and a computer system. Much discussion is needed if such a protocol is to be developed, but the planning is necessary since any confusion due to differences in logging in and out of computer systems is trivial as compared with the interactions during the use of a service, especially with the ability to provide services dependent upon characteristics of specific terminals. PS: I want to express my dissatisfaction with the lack of publicity given to the standard. Admittedly this is just a Federal standard that is not intended to limit commercial usage. However, if the standard is to be implemented on a system by a manufacturer, the effect will be felt by all users. ------- 10-MAY-78 22:27:22-PDT,2084;000000000000 Mail-From: USC-ISI rcvd at 18-MAR-78 2240-PST Mail-from: BBN-TENEXD rcvd at 13-MAR-78 1740-PST Date: 13 Mar 1978 2026-EST Sender: HENDERSON at BBN-TENEXD Subject: MSGGROUP# 649 Proposed FIPS standard for User-Terminal protocols From: HENDERSON at BBN-TENEXD To: Watkins at NBS-10, Pyke at NBS-10 Cc: MsgGroup at ISI, Header-People at MIT-MC Message-ID: <[BBN-TENEXD]13-Mar-78 20:26:53.HENDERSON> Redistributed-To: [ISI]Mailing.List;149: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 18 MAR 1978 Associate Director for ADP Standards Institute for Computer Sciences and Technology National Bureau of Standards Washington, DC 20234 Re: Proposed FIPS entitled "User-Terminal Protocols -- Entry and Exit Procedures between Terminal Users and Computer Services" Sir or Madam: There are a number of problems with the proposed standard, but I wish to focus on one only. Computer systems will only be regarded as useful tools when they become forgiving of human errors. Even more strongly: they should be programmed so that the propensity for error among human is recognized and the computer can put its powerful resources to use in helping to correct them. We should strive for habitability as much as for power, for to be useful a tool must have both of these characteristics. The standard is not habitable as far as I am concerned. In entering the login information, no interaction with the user to help in this task is permitted: for example, how can a mistyped character be corrected? It is easily possible to mistype such that the terminal which one uses issues a DLE. For example, certain keyboards have the CNTL mode shift key beside the SHIFT mode shift key (the HP2645A, for example). Thus by a slight mispositioning of one finger, the attempt to type an uppercase P could cause immediate and irrevocable logout from the system. This seems a bit harsh. Sincerely, D. Austin Henderson, Jr. Computer Scientist Bolt Beranek and Newman Inc. Cambridge, Mass., 02138 ------- 10-MAY-78 22:34:57-PDT,1045;000000000001 Mail-from: USC-ISI rcvd at 14-MAR-78 2202-PST Date: 14 MAR 1978 2142-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 650 [isi]message.sandberg holds traffic for Anders Sandberg From: STEFFERUD at USC-ISI To: [ISI]Mailing.List;149: Message-ID: <[USC-ISI]14-MAR-78 21:42:04.STEFFERUD> Hi All - Just so you know, and so any of you can grab the mail for Anders, I will place it all in the file named in the subject above. Please note that there is traffic for Anders regarding his possible visit to Boston and to Washington. I have been talking with John McKendree here at the AIIE Conference on the Automated Office, and find that he is planning the Washington Segment of the vist (or part of it at least). John has planned a meeting with Ron Uhlig and others with Anders, but they would like to know more about his plans for hotel, et all. If any of you have a report on the Ander's whereabouts, please let me know cause folks herabout are wanting to make contact. Thanks, Stef ------- 10-MAY-78 23:20:24-PDT,6793;000000000001 Mail-From: USC-ISI rcvd at 20-MAR-78 0026-PST Date: 19 MAR 1978 2348-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 651 [ISI]PROCEEDINGS.SURVEY#600-650 From: MSGGROUP at USC-ISI To: [ISI]Mailing.List;150: Message-ID: <[USC-ISI]19-MAR-78 23:48:46.STEFFERUD> -- Messages from file: [USC-ISI]PROCEEDINGS.MSG#600-#650;1 -- SUNDAY, MARCH 19, 1978 23:35:00-PST -- 40 14 MAR STEFFERUD at USC-ISI MSGGROUP# 650 [isi]mess age.sandberg holds traffic for Anders Sandberg (1045 chrs) 39 13 Mar HENDERSON at BBN-TENE MSGGROUP# 649 Proposed FIPS standard for User-Terminal protocols (2037 chrs) 38 13 Mar Robert M. Frankston MSGGROUP# 648 Proposed FIPS for User=Terminal protocols (5113 chrs) 37 12 Mar Brian K. Reid PROCEEDINGS.MSG#551 -600 (6801 chrs) 1 8 Oct BRIAN.REID at CMU-10A MSGGROUP# 601 [DUNLAVEY: Time] (1367 chrs) ------- 10-MAY-78 23:20:24-PDT,659;000000000000 Mail-From: USC-ISI rcvd at 20-MAR-78 1030-PST Date: 20 MAR 1978 1009-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 652 NINE CHANGES IN MAILING LIST From: MSGGROUP at USC-ISI To: [ISI]Mailing.List;151: Message-ID: <[USC-ISI]20-MAR-78 10:09:03.STEFFERUD> CHANGE: Philip.Karlton@CMUA to be Karlton@PARC-MAXC Vittal@BBNA to be Vittal@BBND ADD: Day@BBN, RdMail@CMUA, Hewitt@MIT-AI, MRC@SU-AI (Marc Crispin) Feldman@SUMEX-AIM(Jeff Lasky) DROP: Mark@UCLA-SECURITY, Dick@ILL-NTS, Thanks - Stef PS: You can get a fresh copy of the mailing list by FTP or by SNDMSG request to Steferud@ISI or MsgGroup@ISI. ------- 10-MAY-78 23:20:24-PDT,2510;000000000001 Mail-from: MIT-MULTICS rcvd at 20-MAR-78 1058-PST From: Tavares.Multics at MIT-Multics Date: 03/20/78 1354-est Subject: MSGGROUP# 653 Proposed FIPS To: Frankston at MIT-Multics, Roach at MIT-Multics, To: Saltzer at MIT-Multics, Tavares at MIT-Multics, To: Pyke at NBS-10, Watkins at NBS-10, Kahler at SUMEX-AIM, To: Feinler at SRI-KL, Gumpertz at CMU-10a, To: Newcomer at CMU-10a, Wactlar at CMU-10a Message-ID: [MIT-Multics]1.1.BBBJHLHwHjkkld Redistributed-To: [ISI]Mailing.List;151: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 22 MAR 1978 Honeywell has responded to the proposed FIPS for login/logout in three letters. The first, sent in January, suggests that the assumption made by the standard that Government personnel tend to access more than one computer sys- tem, is false. It goes on to state that since the number of people accessing only one system exceeds the number accessing multiple systems, the total impact of having to re-learn the new procedures would be negative. It continues by expressing misgivings about the dichotomy of government purchasers insisting on off-the-shelf products, and other government agencies requiring special feat- ures for the government. Added to this is a statement that "Government use is a small percent of the total use", and mentions that users in the private sec- tor do not seem to be interested in such a standard. The second, sent earlier this month by our CBEMA representative, expresses "disappointment and concern that the Government has chosen to by-pass the pub- lic voluntary consensus standards-developing process", and quotes the relevant policy statement. It also warns against finessing the newly formed ISO/TC97/SC16 committee which is attempting to deal with just this problem. The third, sent just last week, was a nine page report dealing with spe- cifics, and expressing much of the same horror I have found in network communi- cations from others on this topic. Among the b^etes noirs mentioned were the upper-case only restriction, multi-network piggybacking, the single character exit request (which may be signalled by a dirty comm line), security implica- tions of telling a user whether it was the username or password that was wrong, and numerous requests for clarification. The letter ends by giving the propos- ers A for effort, but recommends it be referred to ANSI for more work. C. D. Tavares ------- 10-MAY-78 23:20:24-PDT,2597;000000000001 Mail-from: SU-AI rcvd at 21-MAR-78 0041-PST Date: 21 Mar 1978 0038-PST From: MRC at SU-AI (Mark Crispin) Subject: MSGGROUP# 654 message reliability, and a plea! To: Header-People at MIT-MC, MsgGroup at USC-ISI To: Feinler at SRI-KL, Malman at BBN-TENEXE Redistributed-To: [ISI]Mailing.List;151: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 22 MAR 1978 In the course of the past few days, I have observed several cases where mail has not gone through for no good reason. My first gripe has to do with WHARTON being in this mode where any ICP to them ICP's back to your own host on the same socket. I understand that this mode is used for debugging the IMP interface. If so, WHY wasn't the NCC and the NIC told about this? And if they were, WHY weren't the network liaisons told? This means that mail to a person at WHARTON, instead of being delayed, it gets sent to that user-id at the sender's host! [God forbid a message ever get sent to a local user who has his/her mail forwarded to WHARTON--it will loop endlessly!] Please, people, if you are going to fool around like that, tell the rest of the world so we can make sure you will get your mail! I have also observed cases of messages being lost at other hosts due to something strange they are doing. For example: At CMU, apparently when the system is in "no login" mode (preparing for PM?) they accept FTP connections, but trying to mail to anybody there gets told NO REMOTE LOGINS AT THIS TIME. CMU should plain refuse the FTP connection so the message will be queued (or whatever is done when a host is down at the time) until CMU will accept mail; or CMU should allow mail even when the system is in this state. Harvard and NBS-10 both occasionally lose mail with a reply of "?Ill Mem Ref at user PC 000001". This message seems to indicate a bug in the mail program at their end, which I am told is non- repeatable but has been known for a long time. I wish they would do something about this. RAND-UNIX occasionally says "local system failure" or some such thing. Part of my unhappiness stems from the fact that SAIL's mail queuer does not mail the user the message s/he sent back, meaning it is lost forever. I've asked our mail maintainer to fix this problem but he hasn't gotten around to it yet. However, there is no good reason why mail should be lost in these cases. I wonder how many other sites have problems like these. Such things really degrade the reliability of ARPAnet mail greatly. -- Mark ------- 10-MAY-78 23:20:25-PDT,1089;000000000001 Mail-from: SRI-KL rcvd at 21-MAR-78 0642-PST Date: 21 Mar 1978 0640-PST From: Feinler at SRI-KL (Jake Feinler) Subject: MSGGROUP# 655 Re: message reliability, and a plea! To: MRC at SU-AI, Header-People at MIT-MC, MsgGroup at USC-ISI, To: Malman at BBN-TENEXE cc: FEINLER Redistributed-To: [ISI]Mailing.List;151: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 22 MAR 1978 In response to the message sent 21 Mar 1978 0038-PST from MRC@SU-AI The NIC has received no word from Wharton for quite some time. At the last encounter they indicated that they were up and that the mailbox was now Wharton (instead of whatever else they had been using). This worked fine for a while and then mail to Howard Morgan began being rejected. He had used HMorgan also, so I changed to this. Again didn't work. Was about to call to find out what the problem was, but Mark seems to have pinpointed it. Since I will have occasion to send them some hardcopy mail, I will drop a copy of your complaint in the envelope. Jake ------- 10-MAY-78 23:20:25-PDT,1240;000000000001 Mail-from: MIT-MULTICS rcvd at 21-MAR-78 0713-PST Date: 21 March 1978 0915-est From: Robert M. Frankston Subject: MSGGROUP# 656 Mail refusals To: Header-People at MIT-MC, MsgGroup at USC-ISI To: Feinler at SRI-KL, Malman at BBN-TENEXE Redistributed-To: [ISI]Mailing.List;151: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 22 MAR 1978 I too have experienced CMU's login refusal. The long term solution is not for systems to refuse to communicate or fix all bugs. Rather there should be a reply code within FTP to say, I cannot process your request now, but perhaps at some other time I will be able to. The sender could then treat that as a refusal. Fancy senders can even inform the user's of the progress of their message. The issue of whether or not to return dead letters is a matter of local policy. An alternative solution, one that I prefer, is for the mail composition/sending program log a copy of the message for further reference in any case so that the user can get back the original if the copy sent is lost for any number of reasons, including those not apparent to the actual mail queuer/server program. ------- 10-MAY-78 23:20:25-PDT,1059;000000000001 Mail-from: RAND-UNIX rcvd at 21-MAR-78 1003-PST Date: Tue, 21 Mar 78 08:47-PST Subject: MSGGROUP# 657 Re: message reliability, and a plea! From: Greep at Rand-Unix To: MRC at Su-Ai (Mark Crispin) cc: Header-People at Mit-Mc, MsgGroup at Usc-Isi, Feinler at Sri-Kl, cc: Malman at Bbn-Tenexe Message-ID: In-Reply-To: Your message of 21 Mar 1978 0038-PST Redistributed-To: [ISI]Mailing.List;151: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 22 MAR 1978 Regarding your comment about the Rand-Unix server FTP saying `local system failure', we return, as do all other sites, what I believe to be appropriately numbered replies on conditions which temporarily make mail delivery impossible, such as no space available or inability to access necessary resources. Any information you or anyone else can provide on improper responses coming from here (e.g. unnumbered replies) would be appreciated; yours is the first such report I have had. ------- 10-MAY-78 23:20:25-PDT,4004;000000000001 Mail-from: MIT-MULTICS rcvd at 21-MAR-78 1159-PST From: Pogran at MIT-Multics Date: 03/21/78 1457-est Subject: MSGGROUP# 658 Message reliability; reflected ICP's and interface looping To: MRC at SU-AI cc: Malman at BBN-TENEXE, Feinler at SRI-KL, cc: MsgGroup at USC-ISI, Header-People at MIT-MC Message-ID: [MIT-Multics]1.1.BBBJHLLcFpBhKM Redistributed-To: [ISI]Mailing.List;151: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 22 MAR 1978 Mark, I'd like to elucidate the "reflected ICP" problem that you mentioned with regard to Wharton. It's not Wharton's fault, believe me. It's the fault of the designers and maintainers of the IMP hardware and software, in not recognizing the effect that IMP-level maintenance software would have on high-level (e.g., FTP and mail) software throughout the ARPANET. We have experienced precisely this problem a number of times when the IMP port serving MIT-Multics was out of order and was being repaired (or, more likely, waiting to be repaired) by the Network Control Center. The problem is that, as a diagnostic aid, the NCC likes to "loop" the IMP's interface to a host. This can be done in either of two ways, both of which result in all messages directed at the host in question being returned to their sender! The first way this can be done is that a bit can be set in the IMP to cause the host interface in the IMP to loop the data around within the interface. This bit is normally turned on or off under program control remotely from the NCC. The NCC can then send messages to that host port, and they will be returned, via the looped host interface, to the IMP and to the NCC. The NCC software then looks for errors in the returned bits. The NCC can turn this bit on whenever they want to -- and they can just as easily forget to turn it off again! Looping can also be done physically at the IMP, by replacing the normal cable to the host's IMP interrface with a "loop-around plug" supplied with each IMP. Tests just like the ones used with the internal loop-around can be performed by the NCC, verifying the last of the interface hardware. Installation or removal of this plug is generally done by site (host) personnel at the request of the NCC. I've gone into all this detail because I believe it will aid in understanding the crux of the problem, which is this: The NCC seems to have the notion that while they've got the interface "looped", in whatever manner, nobody but the NCC will try to send messages to that host! Of course, that's not true. And, by virtue of the symmetry in the IMP-Host protocol which causes the IMP to route the wrapped-around NCC test messages back to the NCC, ANY message sent to that host port will be routed back to ITS sender. And -- this is the point the NCC ignores -- the symmetry of the Host-Host protocol results in any RFC directed at a looped host port being re-directed to the SAME destination socket at the ORIGINATING host! So, an ICP gets reflected, a mail request gets reflected, ... you get the idea. Now, because the NCC has the mistaken notion that nobody will try to send messages to a host port which is broken, and therefore looped, they will often leave an interface looped overnight, when, for example, a problem has been diagnosed in the late afternoon and a serviceman cannot be dispatched until morning. When the host in question is a major Network server, you can imagine the chaos! When I first discovered this problem affecting MIT-Multics, I suggested to Alex McKenzie that the IMP software be modified so that, when an interface is looped under program control, the IMP accepts messages for that interface ONLY from a designated host -- e.g., the Network Control Center. But nothing was ever done about it. So, Mark -- don't be cross with the Wharton people! Complain to the NCC instead! Yours for better networking, Ken Pogran ------- 10-MAY-78 23:20:25-PDT,1545;000000000001 Mail-from: SU-AI rcvd at 24-MAR-78 0958-PST Date: 24 Mar 1978 0958-PST From: MRC at SU-AI (Mark Crispin) Subject: MSGGROUP# 659 [SANTOS at BBNE: Re: Interface Looping] To: Header-People at MIT-MC, MsgGroup at USC-ISI Redistributed-To: [ISI]Mailing.List;151: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 24 MAR 1978 Date: 24 Mar 1978 1253-EST From: SANTOS at BBN-TENEXE Subject: Re: Interface Looping To: Pogran at MIT-MULTICS, MRC at SU-AI cc: Feinler at SRI-KL, Malman, JHaverty, McKenzie, Walden, cc: Santos Ken and Mark, Ken's message of 3/21 was forwarded to me. Ken is basically correct in his description, although it should be pointed out that there is an internal IMP "Host test" that the NCC frequently uses which does not have these problems, i.e. the Host appears dead to the rest of the network. I have expanded the procedure for the NCC to use when conducting tests on a Host interface. They will now first change the Host's access control bits so that only the testing connection will be allowed. Other attempted Host connections will get back a Destination Dead (type 7, subtype 3). When they are done testing, the NCC will restore the normal Host access bits. By the way, the NCC does not often loop an interface and forget about it! I would appreciate it if you could update all the people on the original message's CC list as to our remedy. Also, feel free to report this kind of thing to me in the future. Regards, Paul ------- 10-MAY-78 23:20:25-PDT,1633;000000000001 Mail-from: USC-ECL rcvd at 24-Mar-78 2046-PST Date: 24 MAR 1978 2047-PST Sender: CAINE at USC-ECL Subject: MSGGROUP# 660 "The more things change, ..." From: CAINE at USC-ECL To: MSGGROUP at ISI Message-ID: <[USC-ECL]24-MAR-78 20:47:31.CAINE> Redistributed-To: [ISI]Mailing.List;151: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 26 MAR 1978 I have recently been re-reading the complete collection of Sherlock Holmes stories -- which I haven't done in a number of years. They have been long noted as providing an excellent insight into the day-to-day life of Victorian England. It doesn't take much reading to realize that Mr. Holmes usually assumes that, if he posts a letter in the morning to any address in London, he will surely have received an answer sometime that same afternoon -- he only uses telegrams (which he frequently does use) when he wants INSTANT response or when the address is far outside of London. Mr. William S. Baring-Gould in his "Annotated Sherlock Holmes" confirms this. In the late nineteenth century there were twelve daily mail deliveries in the City of London and six daily deliveries in the rest of the metropolitan London area! Twelve mail deliveries a day is really quite a lot. I expect that, on the average, I only check my net mailbox six to eight times per day. Maybe if we want to study how business will behave in the face of extremely rapid written communication, we would find some interesting source material from a hundred years ago. Steve ------- 10-MAY-78 23:20:25-PDT,1797;000000000000 Mail-From: USC-ISI rcvd at 26-MAR-78 1643-PST Date: 26 MAR 1978 1623-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 661 [Anders Sandberg visits] From: STEFFERUD at USC-ISI To: [ISI]Mailing.List;151: Message-ID: <[USC-ISI]26-MAR-78 16:23:24.STEFFERUD> Anders Sandberg is now in New York. On Monday, Mar 27 he will visit Martin Elton and John Carey at the Alternative Media Center, NY Univ, 144 Bleeker St. (212) 260-3990 On tuesday, he will visit the Wharton School in Philadelphia. Contact Prof Hackeatorn (215) 565-6857. On Wed, Mar 29, he will visit Murray Turoff at NJIT (201) 645- 5352. And then Anders will go to Boston, and you can reach him through Joanne Sattley (JZS@CCA). If you folks in Boston capture a departing message from Anders for us MsgGroupers, please drop it in the box. Thanks - Stef Begin forwarded message Mail-From: CCA-TENEX rcvd at 24-MAR-78 1247-PST Date: 24 MAR 1978 1546-EST From: JZS at CCA To: Frankston at MIT-MULTICS, Vittal at BBNA, Myer at BBNA, Rothnie at CCA Cc: Stefferud at USC-ISI, MARS-Filer at CCA Subject: MSGGROUP# 646 Anders Sandberg visits I have just now talked to Mr. Sandberg about his visit to the Boston area & have arranged for him to meet with Tolly Holt (now the director of B.U.'s Computing Center) on Friday, 31 March, at 10 AM. Dr. Holt has indicated a willingness to entertain as many as care to attend. Mr. Anders has not yet settled the remainder of his schedule, but is planning to call me some time next week. I'm willing to relay information to him from anyone - and to (loosely) coordinate matters if you'll let me know your intentions. Joanne Sattley ------- -------------------- End forwarded message ------- 10-MAY-78 23:20:25-PDT,3577;000000000001 Mail-from: UCLA-SECURITY rcvd at 1-APR-78 0254-PST Date: 1 Apr 1978 0252-PST Sender: lauren at UCLA-Security Subject: MSGGROUP# 662 More "advances" from "Quasar" From: lauren at UCLA-Security To: MSGGROUP at ISI Redistributed-To: [ISI]Mailing.List;152: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 19 APR 1978 It's been sometime now since we've heard anything new from "Quasar Industries," the firm which has made all of those marvelous advances in AI research and robotics while the rest of the computer science community struggles along with basic research. As you may recall, "Quasar" is the firm claiming to market "intelligent household androids," capable of washing dishes, babysitting, serving you drinks, and all sorts of other wondrous things. A "prototype" unit, variously known as "Sam Strugglegear" and "Klatu" has been making the rounds of shopping centers in major cities throughout the U.S. over the past few months. As the "Quasar" claims have spread, various network-related groups have actually observed "Sam" in action, and have generally given rather, uh, unfavorable reports. (I should add that recently a number of us here in Southern California saw the unit in action at a local department store; the group included people from UCLA, Rand, ISI, and other local sites. What we saw so closely resembled previous reports that it does not merit further discussion here, other than to say that when "Quasar" felt "threatened" during their demonstration, their immediate response was to try have us ejected from the store!) In any case, some new information has begun circulating concerning our friends at "Quasar." They have now announced some new products that will accompany their household androids line. These include a "robot guard" supposedly for industrial and governmental use, and maybe even a "robot paramedic" unit. The guard is touted as a highly versatile unit, and will be equipped with all sorts of "non-lethal" restraining/disrupting devices, such as strobe lights to temporarily blind the intruder, and an ultrasonic unit to "confuse" the unfortunate person. As usual, these announcements are being stated as fact by the mass media, talked about in much the same manner as the announcement of a new type of steel-belted tire. It is indeed unfortunate that this situation has not improved; indeed it appears to be getting worse. The most lengthy article I have seen to date concerning "Quasar" and their products is in the April 1978 edition of "Interface Age" magazine (an issue devoted to robotics, what else?) This article seems to give more information about the internals of "Quasar" than any previous publications. "Quasar" appears to be claiming that the department store demos have just been a means to help provide R&D funds. The implication from Quasar continues to be that the "household android," "robot guard," and other forthcoming products, are real, have all of the amazing capabilities they claim, and will be marketed. I suggest that anyone wishing to gain a little more insight into "Quasar" should read the "Interface" article. Well, that about does it for this installment. Isn't it nice to know that we no longer need work on all of these AI and related projects; that "Quasar" has already solved all the problems and is ready to market the fruits of their labors? I welcome comments on the whole "Quasar" business from any interested parties. --Lauren-- [Lauren@UCLA-SECURITY] ------- 10-MAY-78 23:20:26-PDT,2879;000000000001 Mail-from: SU-AI rcvd at 1-APR-78 2220-PST Date: 1 Apr 1978 2204-PST From: GFF at SU-AI (Geoff Goodfellow) Subject: MSGGROUP# 663 The PO & EM??? To: MSGGRP.DST[G,GFF]: PM-Electronic Mail,410 By JEFFREY MILLS Associated Press Writer WASHINGTON (AP) - The Postal Service announced today an $895,000 test of an international electronic message service using satellites to transmit messages between the United States and overseas. The program will be run jointly by the Postal Service and the Communications Satellite Corp. and will involve five or six other countries. ''There is an indicated need in today's society for a less costly and more rapid exchange of information, particularly in international communications,'' Postmaster General William F. Bolger said in announcing the project. He said the test with Comsat demonstrates the Postal Service's commitment to explore what its role should be in electronic communications. The contract signed by the Postal Service and Comsat calls for development of an international electronic message service system and a one-month operational demonstration in February 1979. A decision on whether to proceed with the field trial will be made before the expiration of the contract. The system will use the satellites of the International Telecommunications Satellite Organization and Comsat-operated United States earth station facilities to send messages electronically between two sites in this country and several overseas locations. The Postal Service said New York and Washington are being considered as the sites for the U.S. transmission points. Bolger said the Postal Service has been looking into the use of electronic technologies to transmit mail since 1969 and is currently considering ways it might usefully become involved in electronic transmission systems within the United States. The Postal Service policy has been to avoid entering the electronic field where private businesses are willing to offer such service to the American public. ''I believe the experience the Postal Service will gain from this international electronic message program will give us important knowledge to aid our thinking about a domestic electronic system,'' Bolger said. The electronic system being tested will convert the original mail document into digital electrical signals. These signals will be transmitted by earth and satellite communication to receiving stations overseas. There, a duplicate of the original document will be made and delivered to the addressee through the mail system in those countries. Bolger said this could cut the delivery time over current intercontinental mail and eliminate the roundabout routing that mail between countries often must undergo. ap-ny-03-28 1147EST *************** ------- 10-MAY-78 23:20:26-PDT,1817;000000000001 Mail-from: SU-AI rcvd at 1-APR-78 2345-PST Date: 1 Apr 1978 2328-PST From: GFF at SU-AI (Geoff Goodfellow) Subject: MSGGROUP# 664 ...a little more on the PO and EM scene... To: MSGGRP.DST[G,GFF]: BC-Mail 03-29 BY WILLIAM HINES (2d story) (c) 1978 Chicago Sun-Times WASHINGTON - The nation's new postmaster general, who says he heads ''the world's finest delivery system,'' has unveiled a $2 million plan to make the Postal Service even more sensational - with satellites. About a year from now, if William F. Bolger's plan becomes reality, people in a bit of a hurry will be able to send mail overseas in a fraction of the time that airmail takes and at a fraction of the cost of a phone call or cable. Bolger, who took over the trouble-ridden Postal Service March 15, said he isn't sure the idea will work out. But the Postal Service thinks enough of the plan to have agreed to pay $895,000 to Communications Satellite Corp. for advice and about $1 million to gear up for a one-month test next February. The plan is to shoot facsimile messages to other continents via satellites, using ground facilities here and abroad to get the transmitted messages to their addresses. If the plan works, Bolger said, the service probably would cost between $1 and 14 a page - although this range is by no means definite. Conceivably, the new service would fall between instantaneous communicaiton such as a telephone call at several dollars a minute (person-to-person) and an airmail letter at 31 cents a half-ounce. Who would use it and how often are questions that remain to be answered in the demonstration next Frebuary. If it all shakes down nicely in the demonstration, the Postal Service will launch a one-year field trial, Bolger said. ------- 10-MAY-78 23:20:26-PDT,739;000000000001 Mail-from: CCA-TENEX rcvd at 5-APR-78 0955-PST Date: 05 APR 1978 1256-EST From: JZS at CCA Subject: MSGGROUP# 665 RE: [Anders Sandberg, Civilekonom] To: MsgGroup at USC-ISI cc: Rothnie at CCA, Sattley at RADC-20 Redistributed-To: [ISI]Mailing.List;152: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 19 APR 1978 Mr. Sandberg was last seen on Friday, juggling pounds of documentation and a fistful of airplane tickets, and looking absolutely brimful of information about all he had seen and discussed. He asked me to express to the group his appreciation for all the help he had received during the course of his long visit across the country. Joanne Sattley ------- 10-MAY-78 23:20:26-PDT,1598;000000000001 Mail-from: BBN-TENEXB rcvd at 12-APR-78 1022-PST Date: 12 Apr 1978 1306-EST Sender: PANKO at BBN-TENEXB Subject: MSGGROUP# 666 Computerworld Meets Computer Mail From: PANKO at BBN-TENEXB To: [ISI]Mailing.List;148: Cc: rulifson at PARC-MAXC, taylor at PARC-MAXC Message-ID: <[BBN-TENEXB]12-Apr-78 13:06:45.PANKO> Computerworld's March 13 issue had a front-page article entitled, "Two Software Houses Back Use of Electronic Messaging." The article describes two software packages -- one developed by the MSGGROUP's very own Computer Corporation of America (CCA), and the other developed by On-Line Software International (OSI). Both systems are sold as software packages that you may lease. CCA's COMET package runs on a PDP-11 minicomputer from DEC. COMET goes for $40,000 or $1,446 per month on a 36-month lease (with an optional maintenance service contract at $350 per month). OSI's Messenger service runs on IBM 360s and 370s, under the Customer Information Control System (CICS). Messenger will cost $18,000, or $60 per month under a 60-month lease/purchase plan that allows 50% of the lease cost to be applied to equity. CCA's COMET can also be use on a service basis on CCA's own PDP-11. Users will be charged $100 per billable account and $50 per month for each user within the account. That ($100 or $50? -- I can't tell which) covers 7 hours of connect time and 500 messages stored each month. I'd really be interested in hearing more from CCA folks on this. Aloha, Ra3y ------- 10-MAY-78 23:20:26-PDT,1031;000000000001 Mail-from: SRI-KL rcvd at 18-APR-78 1326-PST Date: 18 Apr 1978 1318-PST Sender: UHLIG at SRI-KL Subject: MSGGROUP# 667 Ron Uhlig Moving to Canada From: UHLIG at SRI-KL To: msggroup at ISI Message-ID: <[SRI-KL]18-Apr-78 13:18:22.UHLIG> Redistributed-To: [ISI]Mailing.List;152: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 20 APR 1978 On 1 May 1978 I will be leaving my job with the US Army Materiel Development and Readiness Command (DARCOM) to begin a new job as Manager of the the Data Systems Planning Department of Bell Northern Research, Limited, in Ottawa, Canada. I have enjoyed working with many of you over the last several years, and hope to continue to work with some of you in my new capacity. After 1 May, my new address will be: Manager - Data Systems Planning Bell Northern Research, Ltd. Dept. 3D40 P. O. Box 3511 Station C Ottawa, Ontario K1Y 4H7 Canada Ron Uhlig ------- 10-MAY-78 23:20:26-PDT,1095;000000000000 Mail-from: USC-ISI rcvd at 19-APR-78 1830-PST Date: 19 APR 1978 1830-PST Sender: FARBER at USC-ISI Subject: MSGGROUP# 668 Re: More "advances" from "Quasar" From: FARBER at USC-ISI To: lauren at UCLA-SECURITY Cc: [ISI]Mailing.List;152: Message-ID: <[USC-ISI]19-APR-78 18:30:08.FARBER> In-Reply-To: Your message of APRIL 1, 1978 Lauren Indeed I wish to relate more on the story of the Quasar saga. When I was in beautiful Boca Raton Florida ( temperature 85 and the same humidity), I heard on the local radio and newspaper that the Dade county police were considering the purchase of a Quasar robot to act as a guard in the county jail. It costs $70000 and was full of marvelous facilities including a large vocabulary and various strobe devices designed to subdue the poor escaping inmate. The basic issue that the paper reporte4d on was the study by the county as to whether the purchase of such a robot was cost effective . Anyone for a good product liability lawsuit the first time that robot hurts an inmate. Dave ------- 10-MAY-78 23:20:26-PDT,1635;000000000001 Mail-from: MIT-MULTICS rcvd at 19-APR-78 2128-PST Date: 20 April 1978 0020-est From: Robert M. Frankston Subject: MSGGROUP# 669 Quasar To: msggroup at USC-ISI cc: lauren at UCLA-Security, gumpertz at CMU-10a Redistributed-To: [ISI]Mailing.List;152: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 20 APR 1978 First, a comment, since there appears to be a general inerest in Quasar (and maybe related hacks) and since the delay via msggroup is so long, it would be nice if someone on a forwarding host (such as ITS) could establish an appropriate mailing list ("QUASAR-ETC"?) so that distribution can be more efficient. For those who are unaware, the Boston Globe had an article in their magainze section March 12, 1978. It was featured on the cover of the magazine section. It did include quotes from people such as Minsky and Fredkin, but more with the attitude of "it just goes to show you that those academicians can't do anything practical, and all you need is some guy working in the back of a garage to put them to shame" (this is not a quote, just an attempt to convey the tone of the article. If yo are ierested, perhaps you can write to the Globe for a copy of the issue. From the index to the magazine section: After R2-D2, Klatu? There could be a robot around the house -- possibly as soon as next year -- to dust, vacuum, babysit or event serve cocktails if the prediction of one manufacturer comes true. By Andrew Blake. Andrew Blake is a staff writer for new england magazine. ------- 10-MAY-78 23:20:27-PDT,408;000000000000 Mail-from: USC-ISI rcvd at 21-APR-78 1349-PST Date: 21 APR 1978 1348-PST Sender: FARBER at USC-ISI Subject: MSGGROUP# 670 An article on Teletext/Viewdata From: FARBER at USC-ISI To: [ISI]Mailing.List;152: Message-ID: <[USC-ISI]21-APR-78 13:48:53.FARBER> There is a very good article on the UK Viewdata in the current Popular Science ( May 1978 pp108). Well done. Dave ------- 10-MAY-78 23:20:27-PDT,4415;000000000001 Mail-from: SRI-KA rcvd at 22-APR-78 1740-PST Date: 22 Apr 1978 1739-PST Sender: SDSAN-DMS at SRI-KA Subject: MSGGROUP# 671 MORE ON ELECTRONIC MAIL From: Tom Bowerman To: MSGGROUP at USC-ISI Cc: SDSAN-DMS Message-ID: <[SRI-KA]22-Apr-78 17:39:44.SDSAN-DMS> Redistributed-To: [ISI]Mailing.List;152: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 23 APR 1978 THE FOLLOWING STORY APPEARED IN THE CHICAGO SUN-TIMES ON 22 APRIL 1978 AND MAY BE OF GENERAL INTEREST. TOM CHICAGO - Western Union by 1990 might be providing message service by terminal directly into people's homes, according to the company chairman. No distant dream, R. W. McFall said it might happen because of competition from the U.S. Postal Service. The postmaster general told a congressional committee that the post office plans by 1985 to test 10 cities for overnight delivery of mail through electronic transmission. McFall told shareholders at Western Union's annual meeting in Chicago that the postal system's plans pose no immediate threat to Western Union's popular Mailgram service. ''They don't expect full electronic delivery until the 1990s, and we're not going to stand still ourselves,'' McFall told the meeting at the Continental Plaza hotel. ''I think by 1990 you'll see a lot of terminal-equipped homes. You can go to a Radio Shack today and buy a home computer for $500, and that's not much more than a color television costs.'' Western Union's Mailgram service started in 1970 and transmits messages to post offices for delivery with the next business day's mail. It's been a growth area for the company, and McFall said that during this year's first quarter, 600,000 Mailgrams were sent each week, an increase of 10 per cent over the same period last year and a company record. The question about competition from the U.S. government came from a shareholder after McFall said the tariff rate structure has brought a lower rate of return on Mailgrams to Western Union so far but that the rate would increase as more years pass. Though Mailgram service, telegrams and money orders are the most visible of Western Union's revenue generators, those combined in 1977 accounted for one-fourth of the company's $650,460,000 revenue. The bulk came from teletypewriter networks provided business firms and from leased communication systems to private business and the federal government. The latter included installation last year for the U.S. Department of Agriculture of a data system using meteor burst technology to collect and communicate snow and rainfall information in Western states. At the first annual meeting in 10 years in Chicago of the New Jersey-based company, shareholders were told first quarter results were slightly above a year ago. The company posted net income of $11 million, or 56 cents a share, on revenues of $164 million. That compares with a year ago net of $9.6 million, or 55 cents a share, on revenues of $157 million. The company faces a major problem in 1979, McFall said, when it might have to pay substantially higher rates for facilities that Western Union leases from American Telephone and Telegraph because long-term contracts expire this year. The leasing fee was $76 million last year, should be $90 million this year and higher in 1979. By 1980, McFall said the growth of Western Union's own transmission capacity should reduce such leasing fees. McFall also told shareholders the company is pleased that the Federal Communications Commission has begun an inquiry into telegram competition. ''We are not afraid of competition so long as we are allowed to compete on the same basis as everyone else,'' McFall said. He added he would also like to see legislation that would eliminate a ban on Western Union from providing its new communication services internationally. In voting at the meeting, two shareholder proposals from Lewis D. Gilbert were defeated but received significant support. A proposal to allow shareholders to buy new stock before being offered through brokerage firms - so-called pre-emptive rights - gained 16.3 per cent in favor. And a proposal that no profit-sharing compensation be paid in a year when no cash dividend on common stock is declared won 17.9 per cent of those voting. ------- 10-MAY-78 23:20:27-PDT,2519;000000000001 mail-from: CMU-10A rcvd at 23-APR-78 1306-PST Date: 23 Apr 1978 (Sunday) 1319-EST From: LEFAIVRE at RUTGERS-10 Subject: MSGGROUP# 672 QUASAR ROBOT STILL LIVES To: AMAREL, RSMITH, SRIDHARAN, KAPLAN, DSMITH, To: JOSH, GOLDBERG cc: MINSKY at MIT-AI, HENRY at MIT-AI, DHT at MIT-AI, cc: KEN at MIT-AI, KLH at MIT-AI, JMC at SU-AI, cc: REID at CMU-10A, BAK at MIT-ML Remailed-to: MsgGroup at USC-ISI Remailed-by: Reid at CMU-10A Remail-date: Sunday, 23 April 1978 1601-EST Redistributed-To: [ISI]Mailing.List;153: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 23 APR 1978 Much to my surprise, given the flurry of activity last November/December, the Quasar "robot" appears to be alive and well. Following is an article which appeared in the New Brunswick HOME NEWS today (Sunday, April 23): --------------------------------------------------------------- TALKING ROBOT TO BE SHOWN Its name is Klatu. It can walk your dog, answer your doorbell, vacuum the rugs and babysit your kids. Quasar Industries of Rutherford claims that its creation, Klatu, a 5-foot 2-inch, 180-pound talking robot, can perform all these tasks and more. Critics are skeptical, however, of Quasar's claims. Several computer experts have expressed doubt that technology is far enough advanced at present to make the development of such an android possible. The public is invited to judge for itself during an outdoor demonstration of Klatu's abilities beginning at noon on Wednesday, April 26, at Middlesex County College. The demonstration is sponsored by the Forum Committee of the College Center Program Board and is open to the general public free of charge. The rain location will be inside the College Center. Called a "Domestic Android", Klatu will be marketed in less than two years for about $4000, according to Quasar President Anthony Reichelt, and could be the ultimate appliance of the near future. On the other hand, its critics wonder if it is indeed a self-contained functional robot or a machine operated by humans using remote controls. For further information on the demonstration, call the college Office of Student Activities, 548-6000, extension 327. ------------------------------------------------------------------ I have a class to teach on Wednesday afternoon, but hope that some other interested faculty or graduate students will be able to attend this "demonstration" of Klatu's abilities. ------- 10-MAY-78 23:20:27-PDT,1009;000000000001 mail-from: SRI-KL rcvd at 23-APR-78 1404-PST Date: 23 Apr 1978 1349-PST Sender: FARBER at SRI-KL Subject: MSGGROUP# 673 A ICCC Tutorial From: FARBER at SRI-KL To: [ISI]Mailing.List;152: Message-ID: <[SRI-KL]23-Apr-78 13:49:17.FARBER> This note is to announce to interested people the holding of a Tutorial by the International Council for Computer Communications ( a non-profit corporation ) -- the sponsors of the ICCC conferences. The tutorial will be held in Washington, DC on May 17, 1978 and is entitled "The Office of the Future ". The lecturers will be : Ronald Uhlig on New Applications of Computers in the Office David Farber on The Future Impact of Evolving Computer Technology on Office Systems James H. Bair on The Impact of the Office of the Future on Individuals and Organizations. Information can be obtained from ICCC % Ed Boyer POB 9745 Washington , D.C. 20016 or from Ron Uhlig ( Uhlig at sri-kl) ------- 10-MAY-78 23:20:27-PDT,663;000000000001 Mail-from: SRI-KA rcvd at 23-APR-78 2359-PST Date: 23 Apr 1978 2312-PST From: Ole Subject: MSGGROUP# 674 Re: An article on Teletext/Viewdata To: MSGGROUP at ISI cc: Ole Redistributed-To: [ISI]Mailing.List;153: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 25 APR 1978 Einar, RE: MSGGROUP #670 An article on Teletext/Viewdata Let me add that the April 1978 issue of "WIRELESS WORLD" had an article on the Viewdata computer by S.Fedida of the UK Post Office Research Centre. I don't know if you get that magasine in the states, but would be glad to send you a copy if you want. OLE ------- 10-MAY-78 23:20:27-PDT,1443;000000000001 Mail-From: USC-ISI rcvd at 1-MAY-78 2149-PDT Date: 1 MAY 1978 2149-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 675 The Quasar Discussion From: Stefferud, Farber To: [ISI]Mailing.List;153: Message-ID: <[USC-ISI] 1-MAY-78 21:49:35.STEFFERUD> The Quasar discussion raises some interesting issues aside from the question of whether the robot is real or fake, or whether the realities of it all need to be publicly exposed for some reason or other. One of the issues that we are directly concerned about is the question of the exposures we all have in MsgGroup. MsgGroup files are open to the public. At least that public which can access the files or who might gain access to a printout of the files by what ever path. There are no known restrictions on distribution of the MsgGroup Transactions. We are asking for potential problems when we criticize the QUASAR robot efforts via MsgGroup. We are using US Government facilities to possibly put in a poor light the activities of an "honest" (and we must assume this) industrial corporation. This could backlash on all of us including ARPA. It is therefore suggested that we carefully censor our comments on QUASAR and others to just reporting facts that are of technical interest to the community. In the meantime, it might be interesting to discuss the pros and cons of such MsgGroup discussions. What think you all? Stef & Dave 10-MAY-78 23:20:27-PDT,1648;000000000001 Mail-from: UCLA-SECURITY rcvd at 1-MAY-78 2254-PDT Date: 1 May 1978 2239-PDT Sender: lauren at UCLA-Security Subject: MSGGROUP# 676 MsgGroup and Quasar From: lauren at UCLA-Security To: Stefferud at ISI Redistributed-To: [ISI]Mailing.List;153: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 2 MAY 1978 Hmmm. I never thought about it in quite that light before, but I suppose you have a valid point. I guess we're all so used to the "free" forum for idea interchange represented by MsgGroup that such pragmatic thoughts as yours too infrequently enter into our minds. I'm not too sure where the line should be drawn, however. To a certain extent, our discussions have simply been an interchange of "facts" and opinion -- two elements that are presumably of recognized value in professional discussions. At what point these become "slanderous" or involve unwise use of network resources is seemingly not clearcut. I would venture that the overall issue of the robot itself is of direct interest to many in the Arpanet community, since some of us are working on research efforts which directly or indirectly are involved with high-level AI research. Whether or not MsgGroup represents the proper forum for such discussions is another matter. I suppose not. My suspicion is that such items get distributed through MsgGroup simply because it seems to have the largest potential interested audience. I do not propose any answers to the overall questions concerning this issue; I'm only attempting to briefly summarize my current thinking on this matter. --Lauren-- ------- 10-MAY-78 23:20:27-PDT,998;000000000001 Mail-from: USC-ISI rcvd at 1-MAY-78 2255-PDT Date: 1 MAY 1978 2251-PDT From: PBARAN Subject: MSGGROUP# 677 Re: The Quasar Discussion To: STEFFERUD cc: PBARAN Redistributed-To: [ISI]Mailing.List;153: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 2 MAY 1978 In response to your message sent 1 MAY 1978 2149-PDT The whole QUASAR thing was first aired via the ARPANET by Brian Reid; this resulted in a S.F. Chronicle story in which John McCarthy was quoted saying less than complimentary (but accurate) things about QUASAR. The ARPA connection was mentioned; as I recall there was no adverse comment by the powers that be. I suppose Stef and Dave are right; we should encourage factual accounts like Brian's and avoid drawing the obvious inferences. However it is a good deal less than satisfying to have to go on about 'agricultural implements' instead of just saying 'spades'. Dave Caulkins (mailbox PBARAN@ISI) ------- 10-MAY-78 23:20:28-PDT,1384;000000000001 Mail-from: SU-AI rcvd at 2-MAY-78 0312-PDT Date: 2 May 1978 0310-PDT From: JMC at SU-AI (John McCarthy) Subject: MSGGROUP# 678 Comment on Quasar Discussion Question To: MsgGroup at USC-ISI, MRC CC: LES Redistributed-To: [ISI]Mailing.List;153: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 2 MAY 1978 I have received a copy of MRC's message without knowing what preceded it. However, I can say that neither Minsky nor Brian Reid nor I have been deterred by speculation that Quasar might sue us. We have stated our opinion that they are fraudulent to any newsmen that asked (I have talked to more than 20), issued a press release, and written a joint letter to the Justice Department and the Postal Inspector. I think someone seems to be frightened of his shadow, because I know of know case in which a scientist has been sued for expressing his opinion that something is fraudulent. When Reichelt gave his spiel at some community college in New Jersey he denounced me by name according to Bob Smith, but did not threaten suit. According to Smith, as with the three other groups of eyewitnesses, the fraud is transparent enough so that Reichelt has no chance of successfully suing anyone. Moreover, it has never been the custom of carnival snake oil salesmen to sue their critics. So have no fear. ------- 10-MAY-78 23:20:28-PDT,1087;000000000001 Mail-from: USC-ISI rcvd at 2-MAY-78 1155-PDT Date: 2 MAY 1978 1155-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 679 Re: Comment on Quasar Discussion Question From: FARBER at USC-ISI To: JMC at SU-AI Cc: MsgGroup, MRC at SU-AI, LES at SU-AI Message-ID: <[USC-ISI] 2-MAY-78 11:55:08.FARBER> In-Reply-To: Your message of MAY 2, 1978 Redistributed-To: [ISI]Mailing.List;153: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 3 MAY 1978 John, I have no fear of being sued by someone who does not like me to say the truth about them. However, we are using a public vehicle called the ARPANET . We therebye expose ARPA, DOD and our future access and use of that network to certain dangers when we use that vehicle for potential libelous material ( and I mean that in a legal way). I suggest that we reserve our interactions relative to Quesar on the net to the reporting of uninterpreted facts. That way we serve the purpose of informing people without the danger of cutting our own throat. Dave ------- 10-MAY-78 23:20:28-PDT,1750;000000000001 Mail-from: CMU-10A rcvd at 2-MAY-78 1745-PDT Date: 2 May 1978 2043-EDT From: Brian Reid at CMU-10A Subject: MSGGROUP# 680 MsgGroup To: Stefferud at USC-ISI, Farber at USC-ISI CC: MsgGroup at USC-ISI Message-ID: <02May78 204349 BR10@CMU-10A> In-Reply-To: <[USC-ISI] 1-MAY-78 21:49:35.STEFFERUD> Redistributed-To: [ISI]Mailing.List;153: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 3 MAY 1978 Stef and Dave, MsgGroup is the closest that we have to a nationwide computer science community forum. MsgGroup is supposedly devoted to topics involving electronic mail. One of the many virtues of computer-based mail systems is their astounding ability to support conferencing. All of us are still learning a lot about the ways in which people communicate over these marvelous mail systems, and about the kinds of discussions that can and cannot be made to work over computer-based mail networks. Despite the large amount of supposed chitchat that passes over MsgGroup and friends, I believe that such conferencing schemes are still very much at the research stage, and that ARPA and the public will ultimately benefit from our experiences using MsgGroup as a nationwide community forum, no matter what the topic at hand. Until such time as people start suggesting the overthrow of our government over MsgGroup, I don't think any sensible topic should be off limits unless you decide that said topic falls outside the scope of MsgGroup. If you decide to restrict the topics that ought to be discussed in MsgGroup, then I submit that there ought to be a "Network-Forum" mailing list which could be a general-purpose forum. Brian ------- 10-MAY-78 23:20:28-PDT,1455;000000000001 Mail-from: USC-ISI rcvd at 2-MAY-78 1933-PDT Date: 2 MAY 1978 1933-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 681 Re: MsgGroup From: FARBER at USC-ISI To: reid at CMUA Cc: Stefferud, MsgGroup Message-ID: <[USC-ISI] 2-MAY-78 19:33:42.FARBER> In-Reply-To: <02May78 204349 BR10@CMU-10A> Redistributed-To: [ISI]Mailing.List;153: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 3 MAY 1978 I for one am a bit tired of being accused of constraint of the free interchange of information. I would for the last time point out that my worry ( and it is indeed a worry) is that we might compromise the ARPA agency by using the ARPANET for conversations that could be construed as libelous to a industrial concern. Let me point out that the presense of the University people on the network is viewed as LESS than desirable by some in the DOD. Some day we might have to defend our right to access things like AUTODIN II. I really don't want to give someone a handle on which he can complain about the use of the net. The formation of a network forum list does not change things, it only masks them . Message group is widely 'read' and as such is a good vehicle. All I am suggesting is that we report facts. Facts are never a problem. Conjecture and things like it can be a problem. Perhaps we can ask some of our ex ARPA fiends to make a comment. Dave ------- 10-MAY-78 23:20:28-PDT,2293;000000000001 Mail-from: SU-AI rcvd at 3-MAY-78 0117-PDT Date: 3 May 1978 0052-PDT From: MRC at SU-AI (Mark Crispin) Subject: MSGGROUP# 682 QUASAR and the censorship of MsgGroup To: MSGGRP.DIS[1,MRC]: QUASAR and the censorship of MsgGroup That is an interesting point. Prudence would counsel us to take the self-censorship approach that Stef and Dave have proposed. I do not feel, however, that prudence in this case is warranted. It is most unfortunate that people cannot speak as individuals, or that we, as scientists, are unable to communicate with fellow scientists freely about a matter which concerns us. In QUASAR's case, we are referring to what certain members of the computer science communitity feel is a hoax being perpretrated upon the public. The charge is indeed a serious one, and if true it means that the public is being subjected to a deception which besides making money for QUASAR is discrediting the work of the computer science community. Suppose Senator Proxmire were to demand a cutoff for ARPA-sponsored AI research on the grounds that QUASAR's "developments" have made AI research unnecessary? I agree a lawsuit is no joking matter. However, restraining the freedom to question the veracity of reports of alleged developments in any field is preventing us from performing our duties as scientists. Are we to allow any charlatan who can say "lawsuit" and "lawyers" to run roughshod over scientific inquiry and freedom? I am aware of one ARPAnet site which is right now being literally blackmailed by threats of a lawsuit regarding the rights to the source of their proprietary software (the claim is that since it was developed partially with ARPA funding, it is "public domain" and whomever wants a copy for commercial purposes can have one). They submit to this extortion, not because it is reasonable, but because there are no "legal precedents" and don't want to take the risk, however unlikely, of losing. I propose that it should be officially noted that the members of MsgGroup are speaking as individuals in a candid fashion to the other members of the group, and are speaking neither for their organizations, or ARPA, or MsgGroup or any other individual in MsgGroup. -- Mark ------- 10-MAY-78 23:20:28-PDT,919;000000000001 Mail-from: CCA-TENEX rcvd at 2-MAY-78 0722-PDT Date: 02 MAY 1978 1020-EDT From: SLES at CCA Subject: MSGGROUP# 683 Re: The Quasar Discussion To: STEFFERUD at USC-ISI Redistributed-To: [ISI]Mailing.List;153: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 3 MAY 1978 In response to your message sent 1 MAY 1978 2149-PDT What a strange message. I'm normally a listener only, but I have this urge to answer your message. The point you made is quite valid; there is a tendency to become rather "informal", possibly even improper, with NET mail. Maybe this is its dangerous virtue? Is there a way to limit (with some kind of disclaimer) the "publicness" of MSGGROUP, rather than trying to limit our conversational tone or topic? Enough! I had nothing to say, except that your message had some funny kind of impact on me. --Steve Slesinger (Sles) ------- 10-MAY-78 23:20:28-PDT,1849;000000000001 Mail-from: BBN-TENEXA rcvd at 2-MAY-78 0808-PDT Date: 2 May 1978 1058-EDT Sender: DDEUTSCH at BBN-TENEXA Subject: MSGGROUP# 684 Re: The Quasar Discussion From: DDEUTSCH at BBN-TENEXA To: STEFFERUD at USC-ISI(Attn: Farber) Message-ID: <[BBN-TENEXA] 2-May-78 10:58:41.DDEUTSCH> In-Reply-To: <[USC-ISI] 1-MAY-78 21:49:35.STEFFERUD> Redistributed-To: [ISI]Mailing.List;153: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 4 MAY 1978 If I interpret you correctly, you are concerned that one or more "random" people with access to the ARPAnet might come accross MsgGroup transactions and interpret them as being "official". I agree that if that were to occur the backlash could be very bad. While noting that the net is supposed to be used for official business only, we all know that it has been, and probably will continue to be used for a variety of social and personal purposes. (Who hasn't used net mail for personal communication? Who hasn't spent time playing some new game over the net? Be honest.) As long as the net is used for its primary purposes nobody is going to scream about the extra traffic generated by unofficial use. The danger lies in the possible interpretation of MsgGroup transactions being "official" US government pronouncements. You are suggesting that we do some self-censoring. There is an alternative. If we are careful to label our personal opinions as such I believe that the danger will be greatly reduced. If Quasar (or anyone else) disagrees with my opinion they may choose to debate with me. They may choose to send messages to MsgGroup in disagreement. They may choose to ignore the whole thing. I see no grounds for any complaint on their part because I am entitled to my opinion as long as it is stated as such. Debbie ------- 10-MAY-78 23:20:28-PDT,1970;000000000001 Mail-from: CMU-10A rcvd at 3-MAY-78 0929-PDT Date: 3 May 1978 1229-EDT From: Brian Reid at CMU-10A Subject: MSGGROUP# 685 Quasar, MsgGroup, and proper use of the ARPAnet To: MsgGroup at USC-ISI Message-ID: <03May78 122947 BR10@CMU-10A> In-Reply-To: John McCarthy's message of 2 May 78 05:10 Redistributed-To: [ISI]Mailing.List;153: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 4 MAY 1978 I think that the real issue is not lawsuits but proxmires. I have never seen any ARPA statement on proper or improper use of the network; I have always just used the "reasonable person" principle. I assume that the military types within ARPA would probably like to restrict access to the network as tightly as they could, and that the academic types would rather that there be free access. I also assume that the military types would like us to restrict our use of the network to traffic directly related to ARPA contract work. Dave seems to think that I accused him of censoring the traffic in MsgGroup. Not at all. I think that it is quite reasonable for there to be discussion forums whose content and membership is limited to specific topics; in this sense, Stef and/or Dave play the role of a meeting chairman, steering the direction of the discussions to stay within the appointed set of topics. My point was that research in computer-based message systems is still in its infancy, and we need a lot more experience in their use. Computer-message-based conferencing, whether on some seemingly frivolous topic like the Quasar robot or on some seemingly serious topic like message header formats, needs to be studied seriously and in more detail. I therefore submit, again, that no topic short of subversion should be considered off limits, unless we hear to the contrary from someone at ARPA. Should we ask Col. Whittaker for an opinion? Brian ------- 10-MAY-78 23:20:29-PDT,2273;000000000001 Mail-from: USC-ISI rcvd at 3-MAY-78 1123-PDT Date: 3 MAY 1978 1050-PDT Sender: DCROCKER at USC-ISI Subject: MSGGROUP# 686 Politics vs. Legalities From: DCROCKER at USC-ISI To: [ISI]Mailing.List;153: Message-ID: <[USC-ISI] 3-MAY-78 10:50:36.DCROCKER> In the early days of the ArpaNet, I once investigated the possibilities of obtaining funding to establish a preliminary "Community Resources Information" network, using SRI's NLS system to organize textual data about groups offering assorted community services and using the ArpaNet to link geographically separated communities. The project was to start small and allow graceful evolution; participants would merely need to gain access to the ArpaNet. My investigations were cut short when it was pointed out to me that Arpa affilliation with such an effort (it was, after all, their network) was a prime candidate for some news sensationalist to begin shouting that "The Defense Departments Supports Abortion Acitivies". It was not important then, or now, whether such publicity is accurate; it IS important that such publicity tends to have disastrous effects to which there is no recourse. Faced with such problems, instituional decision-makers tend to be very conservative; justice and truth tend to be irrelevant. The solution to this sort of problem usually is to avoid puting the decision-maker in the position of having to make a choice in which you can lose. For example, erroneous publicity might develop, claiming that various subversives at sites around the country were using Department of Defense communications systems for the purpose of suppressing free enterprise. A consequent of such adverse publicity might be an edict that all ArpaNet mail had to pertain directly to the activities for which the participant was funded, and had better be justifiable as such in the future. The point is not that we should not discuss such things, but rather that we should discuss them with the understanding that our statements, through distribution lists such as MsgGroup, are in the public domain and that statements made within such a group are usually attributed to the group and not merely to the individual making the comments. Dave. ------- 10-MAY-78 23:20:29-PDT,1556;000000000001 Mail-from: RAND-UNIX rcvd at 2-MAY-78 1554-PDT Date: 2 May 78 15:51-PDT Subject: MSGGROUP# 687 Re: Discussions of industrial applications From: Mike at Rand-Unix To: Stefferud at Isi cc: Mike at Rand-Unix Message-ID: Redistributed-To: [ISI]Mailing.List;153: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 4 MAY 1978 Stef: When industry starts bringing out products which are a result of, or of interest to, the various projects in progress in the Arpanet community, then I believe it is proper for us to report and critique those products freely. Of course we should avoid slander and certainly mark conjecture and hearsay as such, but that doesn't mean that we should abandon making editorial comments (read: give our opinions) just because it comes from the private sector. In fact, it is the opinions of those in the community who are (blush, ahem) on the cutting edge of the field which helps place the reports in context and which helps to legitimize and affirm the use of the Arpanetwork as an effective communication device between researchers. If IBM were to come out with a message system which resembled Bananard and proclaimed it as the Ultimate Message System, would any of us hesitate to denounce it as a fraud? Another issue, not yet addressed, is whether the Msggroup is the correct place for this issue. Perhaps there should be an 'AI-Followers' group, or 'Computer-Fraud-Followers'? Mike Wahrman. Mike at Rand-Unix ------- 10-MAY-78 23:20:29-PDT,520;000000000001 Mail-from: BBN-TENEXB rcvd at 3-MAY-78 1722-PDT Date: 3 May 1978 2011-EDT Sender: PANKO at BBN-TENEXB Subject: MSGGROUP# 688 Reviewers Needed From: PANKO at BBN-TENEXB To: [ISI]Mailing.List;153: Cc: rulifson at PARC-MAXC Message-ID: <[BBN-TENEXB] 3-May-78 20:11:12.PANKO> I need reviewers for the special issue on computer networks. If you'd like to be a reviewer, please send me a message and tell me what subjects you would feel competent to review. Ra3y Panko (Univ. of Hawaii) ------- 10-MAY-78 23:20:29-PDT,2461;000000000001 Mail-from: SUMEX-AIM rcvd at 3-MAY-78 1905-PDT Date: 3 May 1978 1905-PDT From: Kahler at SUMEX-AIM Subject: MSGGROUP# 689 Moving to Oklahoma To: MsgGroup at ISI, Header-People at MC Redistributed-To: [ISI]Mailing.List;153: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 4 MAY 1978 My family and I will be leaving California shortly after May 18, 1978 for Tulsa, Oklahoma to live with the summer heat, the winter cold, the locusts and the oil wells. I got married a year ago this month and came face-to-face all of a sudden with the housing situation here on the San Francisco Peninsula. I will be working for Honeywell in Tulsa doing software support for their Series 60, Level 68 (Multics) and Level 66 (GCOS) customers. (I don't yet have the offer letter in my hand, but I should in a few days.) This will be my first venture out into the "real world". I think it will do myself and my career a lot of good to find out what corporate people want from their computers after helping here at Stanford to meet the needs of medical AI researchers and college students taking computer-assisted instruction (CAI) courses. I am looking forward to learning about Multics first-hand. I'd like to see, after reading Elliot Organick's book and many of the technical papers, how such a secure system with a virtual memory such as Multics has can be implemented without a prohibitive amount of overhead. I'm glad it can. If any of you with Multics experience can tell me your feelings about the operating system and its user interfaces, I would greatly benefit from your comments. I haven't yet seen any literature more recent than 1971, except for a 1976 Multics Pocket Guide, Commands and Active Functions. In the human engineering category, TENEX (especially with our local SUMEX-AIM stuff in it) will be hard to beat. But since with Multics you can in theory put any teletype interface you please between you and the programs you run, maybe Multics is not at a disadvantage there. Not that any of my future customers would want terminal I/O that wasn't vanilla Multics. I will retain my network address here at SUMEX-AIM for a year or so, so it is not time yet to remove me from any mailing lists, but I expect to be much less of a contributor than before (not that I have contributed all that much), and much more a passive listener. Rich Kahler ------- 10-MAY-78 23:20:29-PDT,610;000000000001 Mail-from: CMU-10A rcvd at 3-MAY-78 1947-PDT Date: 3 May 1978 2247-EDT From: Brian Reid at CMU-10A Subject: MSGGROUP# 690 Re: Moving to Oklahoma To: Kahler at SUMEX-AIM CC: MsgGroup at ISI, Header-People at MC Message-ID: <03May78 224737 BR10@CMU-10A> In-Reply-To: Kahler's message of 3 May 78 21:06 Redistributed-To: [ISI]Mailing.List;153: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 4 MAY 1978 Please keep us posted. Go read Mark Twain's "Letters from the Earth" Then perhaps "The Grapes of Wrath". Do they have electricity in Oklahoma? ------- 10-MAY-78 23:20:29-PDT,553;000000000001 Mail-from: CCA-TENEX rcvd at 4-MAY-78 1143-PDT Date: 04 MAY 1978 1443-EDT From: SLES at CCA Subject: MSGGROUP# 691 Project Swing Cartoon To: [ISI]Mailing.List;153: A while back someone requested the source of the cartoon showing how plans for a simple swing get distorted by the planners, implementors, etc. I found the source: "Project Swing I" Allan Dundes and Carl R. Pagter Urban Folklore from the Paperwork Empire (Austin Texas 1975), American Folklore Society Memoir Series, Vol 62:168,975. --sles ------- 10-MAY-78 23:20:29-PDT,1124;000000000001 Mail-from: SU-AI rcvd at 4-MAY-78 1043-PDT Date: 4 May 1978 1040-PDT From: JMC at SU-AI (John McCarthy) Subject: MSGGROUP# 692 reaction To: stefferud at USC-ISI CC: pbaran at USC-ISI Redistributed-To: [ISI]Mailing.List;153: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 4 MAY 1978 There was no threat; it just seemed that people were wasting each other's time in meta-discussions, and I think Mark was wasting his time and mine, and I am worried about whether we will complete Dialnet on time. However, if you like meta-discussions consider this. The DEC message about the 2020 demonstration was a nuisance. At SU-AI, the main nuisance was that 19 copies of it, consisting mostly of distribution list, took up scarce disk space. Nevertheless, the announcement was appropriate, and, while the audience was somewhat random, it is probably no more so than the mailing list that brought me a paper copy of the same announcement. Query: leaving questions peculiar to ARPANET aside, how should advertising be handled in electronic mail systems? ------- 10-MAY-78 23:20:29-PDT,4825;000000000001 Mail-from: OFFICE-1 rcvd at 4-MAY-78 2104-PDT Date: 4 May 1978 2102-PDT From: ZELLICH at OFFICE-1 Subject: MSGGROUP# 693 INOVATIONS IN ENGINEERING PUBLICATION To: JMC at SU-AI, stefferud at USC-ISI cc: pbaran at USC-ISI, ZELLICH, msggroup at ISI Redistributed-To: [ISI]Mailing.List;153: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 5 MAY 1978 In response to the message sent 4 May 1978 1040-PDT from JMC@SU-AI A partial answer to John's query on how advertising should be handled in electronic mail systems is contained in the following article on "Innovations in Engineering Publications" - note the paragraph on the user-specified keyword "items of interest" profile. Perhaps each site could have it's own profile of local users and all advertising and community bulletin board type items would be broadcast to each host? Of course, there would have to be something in the incoming item (the To/Cc address(es) maybe) to tell the local mail receiver/deliverer that the message required special handling, but then we all know that the mail system maintainers have just loads of spare time they don't know what to do with anyway, don't we? What say ye, msggroup? This sounds interesting, desirable, and maybe even attainable - anybody want to try defining a way to send/identify/deliver such items (the local profile facility could be unique at each host - I don't see any need for standardization there)? Cheers, Rich [zellich@office-1] *************************************************************************** INNOVATIONS IN ENGINEERING PUBLICATION Innovations in Engineering Publication. Center; The Western Development Laboratory is participating in a study, "Innovations in Engineering Publications" sponsored by the National Science Foundation. The study seeks to assess electronic delivery of time-valued publications to aerospace engineers, scientists, and technical managers. We will receive access through computer terminals to at least three publications, Aerospace Daily, SRI's DATALOG, and IEEE Transactions on Aerospace and Electronic Systems. Aerospace Daily publishes daily brief items gathered mostly in Washington of technical and market interest in aerospace. DATALOG publishes monthly abstracts of research at SRI and related information in Aerospace and other disciplines. The abstracts of the technical articles on aerospace engineering development in the bimonthly IEEE Transactions will be published. As copy is prepared by the publisher, it is entered simultaneously into the online system and immediately becomes available to the users. Note this means online readers will get their publication from a couple of days to a couple of months ahead of paper delivery. A display terminal with a special two-dimensional viewing system will be installed at a single location at Western Lab and hooked directly via telephone line to a computer at SRI where the publications are stored. It will also be possible for users at Western Lab who have full duplex teletype-type terminals and couplers or modems to have access to the publications at the SRI computer. Each user may build a keyword profile which will notify him or her of new items of interest, and retrospective searches of the publications by keywords are possible. Users can also send messages or questions to the publishers or other users through an electronic mail system. The National Science Foundation foresees that technical publications will be distributed increasingly through computers in the future both to take advantage of rapid delivery and automated filtering, and to avoid rising costs associated with conventional publications methods. This is a chance for them, the publisher involved, and us, to get a taste of what is too come. As part of the project, investigators are making a descriptive study of the use of the system which will require a certain number of interviews and questionnaires. In addition, a monitor built into the computer system will record commands used in reading the publications. The present schedule calls for: A Preliminary screening questionnaire to possible participants which will take about 10 minutes. About half of those responding will be scheduled for further participation. Those who agree to participate and are selected will fill in a second questionnaire in somewhat greater depth. A demonstration training period of about 2 hours will be some time in May. The program will run about nine months. During this time participants will be interviewed three times, not more than half an hour each time. There will be a final evaluation questionnaire. ------- 10-MAY-78 23:20:30-PDT,1491;000000000001 Mail-from: SRI-KA rcvd at 5-MAY-78 1203-PDT Mail-from: SRI-KL rcvd at 5-May-78 0732-PDT Date: 4 May 1978 1635-PDT From: Feinler at SRI-KL (Jake Feinler) Subject: MSGGROUP# 694 DEC Message To: DEC-MAIL-RECIPIENTS: Redistributed-To: [ISI]Mailing.List;154: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 5 MAY 1978 Date: 4 MAY 1978 0452-PDT To: FEINLER at SRI-KL From: DCACODE535 at USC-ISI JAKE, YOU MAY HAVE RECEIVED THE MSG SENT OUT BY DEC ON MAY 1 ABOUT WHICH I HAVE ALREADY RECEIVED SEVERAL COMPLAINTS AS YOU CAN READILY IMAGINE. CAN YOU FORWARD THE FOLLOWING MESSAGE TO ALL ADDRESSES OF THE SUSPECT MESSAGE PLUS ALL HOST AND TIP LIAISONS? THANKS: NOTE: Please direct your comments, if any, directly to DCACODE535@ISI. Thanks, Jake. ---------- ON 2 MAY 78 DIGITAL EQUIPMENT CORPORATION (DEC) SENT OUT AN ARPANET MESSAGE ADVERTISING THEIR NEW COMPUTER SYSTEMS. THIS WAS A FLAGRANT VIOLATION OF THE USE OF ARPANET AS THE NETWORK IS TO BE USED FOR OFFICIAL U.S. GOVERNMENT BUSINESS ONLY. APPROPRIATE ACTION IS BEING TAKEN TO PRECLUDE ITS OCCURRENCE AGAIN. IN ENFORCEMENT OF THIS POLICY DCA IS DEPENDENT ON THE ARPANET SPONSORS, AND HOST AND TIP LIAISONS. IT IS IMPERATIVE YOU INFORM YOUR USERS AND CONTRACTORS WHO ARE PROVIDED ARPANET ACCESS THE MEANING OF THIS POLICY. THANK YOU FOR YOUR COOPERATION. MAJOR RAYMOND CZAHOR CHIEF, ARPANET MANAGEMENT BRANCH, DCA ------- ------- 10-MAY-78 23:20:30-PDT,2192;000000000001 Mail-from: SRI-KL rcvd at 7-MAY-78 1527-PDT Date: 7 May 1978 1527-PDT From: Feinler at SRI-KL (Jake Feinler) Subject: MSGGROUP# 695 Personal comments on DEC message for MsgGroup To: Stef at ISI cc: feinler Redistributed-To: [ISI]Mailing.List;154: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 7 MAY 1978 I was not going to comment (and add to the traffic) on the issue of the DEC message that was sent out, but after having several conversations with people about and around on this issue I think I will add what hopefully will be useful insight to the problem. NOTE: The comments are my own. They do not represent any official message from DCA or the NIC. There are two kinds of message that have been frowned upon on the network. These are advertising of particular products and advertising for or by job applicants. I would like to point out that there are good reasons (other than taking up valuable resources and the fact that some recipients object) for not permitting these kinds of messages. There are many companies in the U.S. and abroad that would like to have access to the Arpanet. Naturally all of them cannot have this access. Consequently if the ones that do have access can advertise their products to a very select market and the others cannot, this is really an unfair advantage. Likewise, if job applicants can be selected amongst some of the best trained around, or if the applicants themselves can advertise to a very select group of prospective employers, this is an unfair advantage to other prospective employees or employers who are not on the net. I have heard some rumblings about 'control' and 'censorship' of the net by the powers-that-be, but I feel in these two particular areas they are leaning over backwards to be fair to the big guys and the small guys alike. In addition, the official message sent out asked us ('us' being network users) to address the issue ourselves. I personally think this is reasonable and think we should lend our support or otherwise be saddled with controls that will be a nuisance to everyone involved. Regards, Jake ------- 10-MAY-78 23:20:30-PDT,3281;000000000001 Mail-from: SU-AI rcvd at 7-MAY-78 2058-PDT Date: 7 May 1978 2057-PDT From: MRC at SU-AI (Mark Crispin) Subject: MSGGROUP# 696 in reply to Jake's message about advertising To: MsgGroup at USC-ISI Redistributed-To: [ISI]Mailing.List;154: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 8 MAY 1978 I agree with Jake about suppressing advertising for many of the same reasons as I disagreed with suppressing subjective messages about QUASAR. The ARPAnet is not, as Jake pointed out, a public resource; it is available to pretty much a select group of people (high school kids regardless!). We are all engaged in activities relating to, or in support of, official US Government business. ARPAnet mail therefore is more of an "interoffice memo" sort of thing than a trade journal, not intended for public distribution although not "top secret" either. Even MsgGroup is in this class; however inappropriate QUASAR is to MsgGroup's intent (and it was inappropriate) I feel that any censorship can only lead to worse things later on. I am sure that DCA realizes this also; otherwise the ARPAnet would have been curbed long ago. Whether or not QUASAR is a fake is a valid topic to be discussed among the computer science community via the ARPAnet; although it is inappropriate for MsgGroup. If there is sufficient interest, another group should be created whose purpose and interests embrace this issue. I don't see any place for advertising on the ARPAnet, however; certainly not the bulk advertising of that DEC message. From the address list, it seems clear to me that the people it was sent to were the Californians listed in the last ARPAnet directory. This was a clear and flagrant abuse of the directory! I am not sure as to how far this should be carried though. I would not mind hearing from DEC about their new products via ARPAnet mail, but I would expect considerably more technical content and considerably less of a sales pitch. Where is the line to be drawn between this sort of thing (if it is to be allowed at all) and advertising? Another point Jake mentioned which concerns me is that of employment hunting (by employee or employer). Is that to be taken to mean that a person cannot establish contacts at another ARPAnet site and poke around about a possible position there? Is this really unfair to non-ARPAnet people? Allow me to point out that at times a job is created in order to have a particular person on the staff, and if that person is unavailable, the job won't exist. This all seems worthy of examination by the MsgGroup community, as it involves how electronic mail is to be used. Something else; I would greatly appreciate it if all comments about this make a distinction between ARPAnet mail and mail on another (possibly commercial) network. Saying that electronic junk mail is a no-no on the ARPAnet doesn't answer the question. I shudder to think about it, but I can envision junk mail being sent to people who implement Dialnet, and no way it could be prevented or stopped. I guess the ultimate solution is the command in your mail reading subsystem which deletes an unwanted message. -- Mark ------- 10-MAY-78 23:20:30-PDT,2250;000000000001 Mail-from: MIT-AI rcvd at 7-MAY-78 2316-PDT Date: 8 MAY 1978 0213-EDT From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP# 697 Some Thoughts about advertising To: stefferud at USC-ISI Redistributed-To: [ISI]Mailing.List;154: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 8 MAY 1978 1) I didn't receive the DEC message, but I can't imagine I would have been bothered if I have. I get tons of uninteresting mail, and system announcements about babies born, etc. At least a demo MIGHT have been interesting. 2) The amount of harm done by any of the cited "unfair" things the net has been used for is clearly very small. And if they have found any people any jobs, clearly they have done good. If I had a job to offer, I would offer it to my friends first. Is this "evil"? Must I advertise in a paper in every city in the US with population over 50,000 and then go to all of them to interview, all in the name of fairness? Some people, I am afraid, would think so. Such a great insistence on fairness would destort everyone's lives and do much more harm than good. So I state unashamedly that I am in favor of seeing jobs offered via whatever. 3) It has just been suggested that we impose someone's standards on us because otherwise he MIGHT do so. Well, if you feel that those standards are right and necessary, go right ahead and support them. But if you disagree with them, as I do, why hand your opponents the victory on a silver platter? By the suggested reasoning, we should always follow the political views that we don't believe in, and especially those of terrorists, in anticipation of their attempts to impose them on us. If those who think that the job offers are bad are going to try to prevent them, then those of us who think they are unrepugnant should uphold our views. Besides, I doubt that anyone can successfully force a site from outside to impose censorship, if the people there don't fundamentally agree with the desirability of it. 4) Would a dating service for people on the net be "frowned upon" by DCA? I hope not. But even if it is, don't let that stop you from notifying me via net mail if you start one. ------- 10-MAY-78 23:20:30-PDT,685;000000000001 Mail-from: MIT-AI rcvd at 9-MAY-78 1528-PDT Date: 9 MAY 1978 1827-EDT From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP# 698 DEC message [VERY TASTY!] To: Stefferud at USC-ISI CC: Geoff at SRI-KL Redistributed-To: [ISI]Mailing.List;154: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 9 MAY 1978 Well, Geoff forwarded me a copy of the DEC message, and I eat my words. I sure would have minded it! Nobody should be allowed to send a message with a header that long, no matter what it is about. Forward this if you feel like it. [EDITORS NOTE: ACTUALLY, I THINK RMS@MIT-AI NEEDS SOME MORE COPIES. /STEF] ------- 10-MAY-78 23:20:30-PDT,13632;000000000000 Mail-from: SRI-KA rcvd at 10-MAY-78 0921-PDT Date: 10 May 1978 0910-PDT Sender: GEOFF at SRI-KA Subject: MSGGROUP# 699 [THUERK at DEC-MARLBORO: ADRIAN@SRI-KL] From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: msggroup at ISI Message-ID: <[SRI-KA]10-May-78 09:10:14.GEOFF> Begin forwarded message =========================== Mail-from: DEC-MARLBORO rcvd at 3-May-78 0955-PDT Date: 1 May 1978 1233-EDT From: THUERK at DEC-MARLBORO Subject: ADRIAN@SRI-KL To: DDAY at SRI-KL, DAY at SRI-KL, DEBOER at UCLA-CCN, To: WASHDC at SRI-KL, LOGICON at USC-ISI, SDAC at USC-ISI, To: DELDO at USC-ISI, DELEOT at USC-ISI, DELFINO at USC-ISI, To: DENICOFF at USC-ISI, DESPAIN at USC-ISI, DEUTSCH at SRI-KL, To: DEUTSCH at PARC-MAXC, EMY at CCA-TENEX, DIETER at USC-ISIB, To: DINES at AMES-67, MERADCON at SRI-KL, EPG-SPEC at SRI-KA, To: DIVELY at SRI-KL, DODD at USC-ISI, DONCHIN at USC-ISIC, To: JED at LLL-COMP, DORIN at CCA-TENEX, NYU at SRI-KA, To: DOUGHERTY at USC-ISI, PACOMJ6 at USC-ISI, To: DEBBY at UCLA-SECURITY, BELL at SRI-KL, JHANNON at SRI-KA, To: DUBOIS at USC-ISI, DUDA at SRI-KL, POH at USC-ISI, To: LES at SU-AI, EAST at BBN-TENEX, DEASTMAN at USC-ECL, To: EBISU at I4-TENEX, NAC at USC-ISIE, ECONOMIDIS at I4-TENEX, To: WALSH at SRI-KL, GEDWARDS at SRI-KL, WEDWARDS at USC-ISI, To: NUSC at SRI-KL, RM at SU-AI, ELKIND at PARC-MAXC, To: ELLENBY at PARC-MAXC, ELLIS at PARC-MAXC, ELLIS at USC-ISIB, To: ENGELBART at SRI-KL, ENGELMORE at SUMEX-AIM, To: ENGLISH at PARC-MAXC, ERNST at I4-TENEX, To: ESTRIN at MIT-MULTICS, EYRES at USC-ISIC, To: FAGAN at SUMEX-AIM, FALCONER at SRI-KL, To: DUF at UCLA-SECURITY, FARBER at RAND-UNIX, PMF at SU-AI, To: HALFF at USC-ISI, RJF at MIT-MC, FEIERBACH at I4-TENEX, To: FEIGENBAUM at USC-ISI, FEINLER at SRI-KL, To: FELDMAN at SUMEX-AIM, FELDMAN at SRI-KL, FERNBACH at LLL-COMP, To: FERRARA at RADC-MULTICS, FERRETTI at SRI-KA, To: FIALA at PARC-MAXC, FICKAS at USC-ISIC, AFIELD at I4-TENEX, To: FIKES at PARC-MAXC, REF at SU-AI, FINK at MIT-MULTICS, To: FINKEL at USC-ISIB, FINN at USC-ISIB, AFGWC at BBN-TENEX, To: FLINT at SRI-KL, WALSH at SRI-KL, DRXAN at SRI-KA, To: FOX at SRI-KL, FRANCESCHINI at MIT-MULTICS, To: SAI at USC-ISIC, FREDRICKSON at RAND-RCC, ETAC at BBN-TENEXB, To: FREYLING at BBN-TENEXE, FRIEDLAND at SUMEX-AIM, To: FRIENDSHUH at SUMEX-AIM, FRITSCH at LLL-COMP, ME at SU-AI, To: FURST at BBN-TENEXB, FUSS at LLL-COMP, OP-FYE at USC-ISIB, To: SCHILL at USC-ISIC, GAGLIARDI at USC-ISIC, To: GAINES at RAND-UNIX, GALLENSON at USC-ISIB, To: GAMBLE at BBN-TENEXE, GAMMILL at RAND-UNIX, To: GANAN at USC-ISI, GARCIA at SUMEX-AIM, To: GARDNER at SUMEX-AIM, MCCUTCHEN at SRI-KL, To: GARDNER at MIT-MULTICS, GARLICK at SRI-KL, To: GARVEY at SRI-KL, GAUTHIER at USC-ISIB, To: USGS-LIA at BBN-TENEX, GEMOETS at I4-TENEX, To: GERHART at USC-ISIB, GERLA at USC-ISIE, GERLACH at I4-TENEX, To: GERMAN at HARV-10, GERPHEIDE at SRI-KA, DANG at SRI-KL, To: GESCHKE at PARC-MAXC, GIBBONS at CMU-10A, To: GIFFORD.COMPSYS at MIT-MULTICS, JGILBERT at BBN-TENEXB, To: SGILBERT at BBN-TENEXB, SDAC at USC-ISI, To: GILLOGLY at RAND-UNIX, STEVE at RAND-UNIX, To: GLEASON at SRI-KL, JAG;BIN(1525) at UCLA-CCN, To: GOLD at LL-11, GOLDBERG at USC-ISIB, GOLDGERG at SRI-KL, To: GROBSTEIN at SRI-KL, GOLDSTEIN at BBN-TENEXB, To: DARPM-NW at BBN-TENEXB, GOODENOUGH at USC-ISIB, To: GEOFF at SRI-KL, GOODRICH at I4-TENEX, GOODWIN at USC-ISI, To: GOVINSKY at SRI-KL, DEAN at I4-TENEX, TEG at MIT-MULTICS, To: CCG at SU-AI, EPG-SPEC at SRI-KA, GRISS at USC-ECL, To: BJG at RAND-UNIX, MCCUTCHEN at SRI-KL, GROBSTEIN at SRI-KL, To: MOBAH at I4-TENEX, GUSTAFSON at USC-ISIB, GUTHARY at SRI-KL, To: GUTTAG at USC-ISIB, GUYTON at RAND-RCC, To: ETAC-AD at BBN-TENEXB, HAGMANN at USC-ECL, HALE at I4-TENEX, To: HALFF at USC-ISI, DEHALL at MIT-MULTICS, To: HAMPEL at LLL-COMP, HANNAH at USC-ISI, To: NORSAR-TIP at USC-ISIC, SCRL at USC-ISI, HAPPY at SRI-KL, To: HARDY at SRI-KL, IMPACT at SRI-KL, KLH at SRI-KL, To: J33PAC at USC-ISI, HARRISON at SRI-KL, WALSH at SRI-KL, To: DRCPM-FF at BBN-TENEXB, HART at AMES-67, HART at SRI-KL, To: HATHAWAY at AMES-67, AFWL at I4-TENEX, BHR at RAND-UNIX, To: RICK at RAND-UNIX, DEBE at USC-ISIB, HEARN at USC-ECL, To: HEATH at UCLA-ATS, HEITMEYER at BBN-TENEX, ADTA at SRI-KA, To: HENDRIX at SRI-KL, CH47M at BBN-TENEXB, HILLIER at SRI-KL, To: HISS at I4-TENEX, ASLAB at USC-ISIC, HOLG at USC-ISIB, To: HOLLINGWORTH at USC-ISIB, HOLLOWAY at HARV-10, To: HOLMES at SRI-KL, HOLSWORTH at SRI-KA, HOLT at LLL-COMP, To: HOLTHAM at LL, DHOLZMAN at RAND-UNIX, HOPPER at USC-ISIC, To: HOROWITZ at USC-ISIB, VSC at USC-ISI, HOWARD at LLL-COMP, To: HOWARD at USC-ISI, PURDUE at USC-ISI, HUBER at RAND-RCC, To: HUNER at RADC-MULTICS, HUTSON at AMES-67, IMUS at USC-ISI, To: JACOBS at USC-ISIE, JACOBS at BBN-TENEXB, To: JACQUES at BBN-TENEXB, JARVIS at PARC-MAXC, To: JEFFERS at PARC-MAXC, JENKINS at PARC-MAXC, To: JENSEN at SRI-KA, JIRAK at SUMEX-AIM, NICKIE at SRI-KL, To: JOHNSON at SUMEX-AIM, JONES at SRI-KL, JONES at LLL-COMP, To: JONES at I4-TENEX, RLJ at MIT-MC, JURAK at USC-ECL, To: KAHLER at SUMEX-AIM, MWK at SU-AI, KAINE at USC-ISIB, To: KALTGRAD at UCLA-ATS, MARK at UCLA-SECURITY, RAK at SU-AI, To: KASTNER at USC-ISIB, KATT at USC-ISIB, To: UCLA-MNC at USC-ISI, ALAN at PARC-MAXC, KEENAN at USC-ISI, To: KEHL at UCLA-CCN, KELLEY at SRI-KL, BANANA at I4-TENEX, To: KELLOGG at USC-ISI, DDI at USC-ISI, KEMERY at SRI-KL, To: KEMMERER at UCLA-ATS, PARVIZ at UCLA-ATS, KING at SUMEX-AIM, To: KIRSTEIN at USC-ISI, SDC at UCLA-SECURITY, To: KLEINROCK at USC-ISI, KLEMBA at SRI-KL, CSK at USC-ISI, To: KNIGHT at SRI-KL, KNOX at USC-ISI, KODA at USC-ISIB, To: KODANI at AMES-67, KOOIJ at USC-ISI, KREMERS at SRI-KL, To: BELL at SRI-KL, KUNZELMAN at SRI-KL, PROJX at SRI-KL, To: LAMPSON at PARC-MAXC, SDL at RAND-UNIX, JOJO at SRI-KL, To: SDC at USC-ISI, NELC3030 at USC-ISI, To: LEDERBERG at SUMEX-AIM, LEDUC at SRI-KL, JSLEE at USC-ECL, To: JACOBS at USC-ISIE, WREN at USC-ISIB, LEMONS at USC-ISIB, To: LEUNG at SRI-KL, J33PAC at USC-ISI, LEVIN at USC-ISIB, To: LEVINTHAL at SUMEX-AIM, LICHTENBERGER at I4-TENEX, To: LICHTENSTEIN at USC-ISI, LIDDLE at PARC-MAXC, To: LIEB at USC-ISIB, LIEBERMAN at SRI-KL, STANL at USC-ISIE, To: LIERE at I4-TENEX, DOCB at USC-ISIC, LINDSAY at SRI-KL, To: LINEBARGER at AMES-67, LIPKIS at USC-ECL, SLES at USC-ISI, To: LIS at SRI-KL, LONDON at USC-ISIB, J33PAC at USC-ISI, To: LOPER at SRI-KA, LOUVIGNY at SRI-KL, LOVELACE at USC-ISIB, To: LUCANIC at SRI-KL, LUCAS at USC-ISIB, DCL at SU-AI, To: LUDLAM at UCLA-CCN, YNGVAR at SRI-KA, LYNCH at SRI-KL, To: LYNN at USC-ISIB, MABREY at SRI-KL, MACKAY at AMES-67, To: MADER at USC-ISIB, MAGILL at SRI-KL, KMAHONEY at BBN-TENEX, To: MANN at USC-ISIB, ZM at SU-AI, MANNING at USC-ISI, To: MANTIPLY at I4-TENEX, MARIN at I4-TENEX, SCRL at USC-ISI, To: HARALD at SRI-KA, GLORIA-JEAN at UCLA-CCN, MARTIN at USC-ISIC, To: WMARTIN at USC-ISI, GRM at RAND-UNIX, MASINTER at USC-ISI, To: MASON at USC-ISIB, MATHIS at SRI-KL, MAYNARD at USC-ISIC, To: MCBREARTY at SRI-KL, MCCALL at SRI-KA, MCCARTHY at SU-AI, To: MCCLELLAND at USC-ISI, DORIS at RAND-UNIX, MCCLURG at SRI-KL, To: JOHN at I4-TENEX, MCCREIGHT at PARC-MAXC, MCCRUMB at USC-ISI, To: DRXTE at SRI-KA cc: BPM at SU-AI MCKINLEY@USC-ISIB MMCM@SRI-KL OT-ITS@SRI-KA BELL@SRI-KL MEADE@SRI-KL MARTIN@USC-ISI MERRILL@BBN-TENEX METCALFE@PARC-MAXC JMETZGER@USC-ISIB MICHAEL@USC-ISIC CMILLER@SUMEX-AIM MILLER@USC-ISI SCI@USC-ISI MILLER@USC-ISIC MITCHELL@PARC-MAXC MITCHELL@USC-ISI MITCHELL@SUMEX-AIM MLM@SU-AI JPDG@TENEXB MOORE@USC-ISIB WMORE@USC-ISIB JAM@SU-AI MORAN@PARC-MAXC ROZ@SU-AI MORGAN@USC-ISIB MORRIS@PARC-MAXC MORRIS@I4-TENEX OT-ITS@SRI-KA LISA@USC-ISIB MOSHER@SRI-KL MULHERN@USC-ISI MUNTZ;BIN(1529)@UCLA-CCN MYERS@USC-ISIC MYERS@RAND-RCC DRCPM-FF-FO@BBN-TENEXB NAGEL@USC-ISIB NAPKE@SRI-KL NARDI@SRI-KL NAYLOR@USC-ISIE LOU@USC-ISIE NESBIT@RAND-RCC NEUMANN@SRI-KA NEVATIA@USC-ECL NEWBY@USC-ISI NEWEKK@SRI-KA NIELSON@SRI-KL NLL@SUMEX-AIM NILSSON@SRI-KL NITZAN@SRI-KL NOEL@USC-ISIC NORMAN@PARC-MAXC NORTON@SRI-KL JOAN@USC-ISIB NOURSE@SUMEX-AIM PDG@SRI-KL OMALLEY@SRI-KA OCKEN@USC-ISIC OESTREICHER@USC-ISIB OGDEN@SRI-KA OKINAKA@USC-ISIE OLSON@I4-TENEX ORNSTEIN@PARC-MAXC PANKO@SRI-KL TED@SU-AI PARK@SRI-KL PBARAN@USC-ISI PARKER@USC-ISIB PEARCE@USC-ISI PEPIN@USC-ECL PERKINS@USC-ISIB PETERS@SRI-KL AMPETERSON@USC-ISI ASLAB@USC-ISIC EPG-SPEC@SRI-KA PEZDIRTZ@LLL-COMP CHARLIE@I4-TENEX UCLA-DOC@USC-ISI WPHILLIPS@USC-ISI PIERCY@MOFFETT-ARC PINE@SRI-KL PIPES@I4-TENEX PIRTLE@SRI-KL POGGIO@USC-ISIC POH@USC-ISI POOL@BBN-TENEX POPEK@USC-ISI POSTEL@USC-ISIB POWER@SRI-KL PRICE@USC-ECL RANDALL@USC-ISIB RANDALL@SRI-KA RAPHAEL@SRI-KL RAPP@RAND-RCC RASMUSSEN@USC-ISIC RATTNER@SRI-KL RAY@ILL-NTX FNWC@I4-TENEX BRL@SRI-KL RETZ@SRI-KL SKIP@USC-ISIB RICHARDSON@USC-ISIB RICHES@USC-ECL GWEN@USC-ECL OP-RIEDEL@USC-ISIB RIES@LLL-COMP RINDFLEISCH@SUMEX-AIM OP-ROBBINS@USC-ISIB ROBINSON@SRI-KL JROBINSON@SRI-KL RODRIQUEZ@SRI-KL MARTIN@USC-ISI ROM@USC-ISIC ROMIEZ@I4-TENEX ROSE@USC-ISI ROSEN@SRI-KL BARBARA@I4-TENEX ROTHENBERG@USC-ISIB RUBIN@SRI-KL JBR@SU-AI RUBINSTEIN@BBN-TENEXD RUDY@USC-ECL RUGGERI@SRI-KA RULIFSON@PARC-MAXC DALE@USC-ISIB SACERDOTI@SRI-KL SAGALOWICZ@SRI-KL ALS@SU-AI SANTONI@USC-ISIC SATTERTHWAITE@PARC-MAXC SAWCHUK@USC-ECL CPF-CC@USC-ISI SCHELONKA@USC-ISI SCHILL@USC-ISIC SCHILLING@USC-ISI SCHULZ@SUMEX-AIM SCOTT@SUMEX-AIM CPF-CC@USC-ISI OP-SEATON@USC-ISIB SENNE@LL NORM@RAND-UNIX AFWL@14-TENEX SHEPPARD@LL-ASG SHERWIN@USC-ISI SHERWOOD@SRI-KL SHORT@SRI-KL SHORTLIFE@SUMEX-AIM SHOSHANI@BBN-TENEX MARTIN@USC-ISI UCLA-NMC@USC-ISIE SDL@USC-ISIC SKOCYPEC@USC-ISI SLES@USC-ISI SLOTTOW@UCLA-CCN NOAA@14-TENEX SMALL@USC-ISI DAVESMITH@PARC-MAXC DSMITH@RAND-UNIX SMITH@SUMEX-AIM SMITH@USC-ECL MARCIE@I4-TENEX USARSGEUR@USC-ISI LOGICON@USC-ISI EPA@SRI-KL SONDEREGGER@USC-ISIB SPEER@LL AMICON-RN@USC-ISI SPROULL@PARC-MAXC PROJX@SRI-KL STEF@SRI-KA STEFIK@SUMEX-AIM STEPHENS@SRI-KA CFD@I4-TENEX STOCKHAM@SRI-KA STOTZ@USC-ISIB ALLEN@UCLA-SECURITY STOUTE@MIT-ML STRADLING@SRI-KL STROLLO@PARC-MAXC UCLA-0638@UCLA-CCN CRT@SRI-KA SUNSHINE@RAND-UNIX SUTHERLAND@SRI-KL SUTHERLAND@RAND-UNIX SUTHERLAND@PARC-MAXC SUTTON@USC-ISIC SWEER@SUMEX-AIM TAFT@PARC-MAXC TAYLOR@USC-ISIB TAYLOR@PARC-MAXC TAYNAI@SUMEX-AIM TEITELMAN@PARC-MAXC TENENBAUM@SRI-KL GREEP@RAND-UNIX TERRY@SUMEX-AIM TESLER@PARC-MAXC THACKER@PARC-MAXC PWT@RAND-UNIX TIPPIT@USC-ISIE TOBAGI@USC-ISIE TOGNETTI@SUMEX-AIM TORRES@SRI-KL TOWNLEY@HARV-10 ELINA@UCLA-ATS TUCKER@SUMEX-AIM TUGENDER@USC-ISIB LLLSRG@MIT-MC UNCAPHER@USC-ISIB NOSC@SRI-KL UNTULIS@SRI-KL MIKE@UCLA-SECURITY AARDVARK@UCLA-ATS UZGALIS;BIN(0836)@UCLA-CCN VANGOETHEM@UCLA-CCN VANMIEROP@USC-ISIB VANNOUHUYS@SRI-KL VEIZADES@SUMEX-AIM VESECKY@USC-ISI AV@MIT-DMS VICTOR@USC-ISIC VIDAL@UCLA-SECURITY OP-VILAIN@USC-ISIB RV@RAND-UNIX SDL@USC-ISIC VOLPE@SRI-KL VONNEGUT@I4-TENEX VU@SRI-KL WACTLAR@CMU-10A WAGNER@USC-ISI WAHRMAN@RAND-UNIX WALDINGER@SRI-KL WALKER@UCLA-SECURITY WALKER@SRI-KL WALLACE@PARC-MAXC EVE@UCLA-SECURITY LOGICON@USC-ISI DON@RAND-UNIX WATSON@USC-ISIC WEIDEL@USC-ECL WEINBERG@SRI-KL JLW@MIT-AI LAUREN@UCLA-SECURITY WEISSMAN@I4-TENEX WELLS@USC-ISIC GERSH@USC-ISI WETHEREL@LLL-COMP RWW@SU-AI SCRL@USC-ISI TWHELLER@SRI-KA MABREY@SRI-KL WHITE@PARC-MAXC WHITE@SUMEX-AIM WIEDERHOLD@SUMEX-AIM WILBER@SRI-KL EPG-SPEC@SRI-KA WILCOX@SUMEX-AIM WILCZYNSKI@USC-ISIB WILE@USC-ISIB OP-WILLIAMS@USC-ISIB WILSON@USC-ISIB TW@SU-AI SCI@USC-ISI WISNIEWSKI@RAND-UNIX WOLF@SRI-KL PAT@SU-AI NELC3030@USC-ISI WYATT@HARV-10 LEO@USC-ISIB YEH@LLL-COMP YONKE@USC-ISIB YOUNGBERG@SRI-KA ZEGERS@SRI-KL ZOLOTOW@SRI-KL ZOSEL@LLL-COMP DIGITAL WILL BE GIVING A PRODUCT PRESENTATION OF THE NEWEST MEMBERS OF THE DECSYSTEM-20 FAMILY; THE DECSYSTEM-2020, 2020T, 2060, AND 2060T. THE DECSYSTEM-20 FAMILY OF COMPUTERS HAS EVOLVED FROM THE TENEX OPERATING SYSTEM AND THE DECSYSTEM-10 COMPUTER ARCHITECTURE. BOTH THE DECSYSTEM-2060T AND 2020T OFFER FULL ARPANET SUPPORT UNDER THE TOPS-20 OPERATING SYSTEM. THE DECSYSTEM-2060 IS AN UPWARD EXTENSION OF THE CURRENT DECSYSTEM 2040 AND 2050 FAMILY. THE DECSYSTEM-2020 IS A NEW LOW END MEMBER OF THE DECSYSTEM-20 FAMILY AND FULLY SOFTWARE COMPATIBLE WITH ALL OF THE OTHER DECSYSTEM-20 MODELS. WE INVITE YOU TO COME SEE THE 2020 AND HEAR ABOUT THE DECSYSTEM-20 FAMILY AT THE TWO PRODUCT PRESENTATIONS WE WILL BE GIVING IN CALIFORNIA THIS MONTH. THE LOCATIONS WILL BE: TUESDAY, MAY 9, 1978 - 2 PM HYATT HOUSE (NEAR THE L.A. AIRPORT) LOS ANGELES, CA THURSDAY, MAY 11, 1978 - 2 PM DUNFEY'S ROYAL COACH SAN MATEO, CA (4 MILES SOUTH OF S.F. AIRPORT AT BAYSHORE, RT 101 AND RT 92) A 2020 WILL BE THERE FOR YOU TO VIEW. ALSO TERMINALS ON-LINE TO OTHER DECSYSTEM-20 SYSTEMS THROUGH THE ARPANET. IF YOU ARE UNABLE TO ATTEND, PLEASE FEEL FREE TO CONTACT THE NEAREST DEC OFFICE FOR MORE INFORMATION ABOUT THE EXCITING DECSYSTEM-20 FAMILY. ------- =========================== End forwarded message ------- 10-MAY-78 23:20:30-PDT,2119;000000000001 Mail-from: USC-ECL rcvd at 10-MAY-78 1501-PDT Date: 10 MAY 1978 1506-PDT From: MARTIN at USC-ECL Subject: MSGGROUP# 700 MAY 1979 IFIP TELEINFORMATICS CONFERENCE IN PARIS To: MSGGROUP at ISI cc: MARTIN Redistributed-To: [ISI]Mailing.List;154: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 10 MAY 1978 I AM US REPRESENTATIVE FOR A CONFERENCE EXPLORING APPLICATIONS OF DISTRIBUTED SYSTEMS AND NETWORKS. THE CALL FOR PAPERS IS LATE IN ARRIVING AND SO I AM TRING TO GET THE WORD OUT SO WHEN IT DOES ARRIVE IT GETS TO THE RIGHT PEOPLE AND THEY ARE READY TO RESPOND. THE DATE FOR STATEMENTS OF INTENT IS JUNE 20TH OF THIS YEAR. THE TOPICS ARE - OFFICE AUTOMATION AND WORD PROCESSING -TELECONFERENCING AND MGT OF DISTRIBUTED ORGANIZATIONS -NEW MARKETING OPPORTUNITIES -VIEWDATA AND LIKE SERVICES -ELECTRONIC MAIL -ENTERTAINMENT AND LEISURE ACTIVITY -COMPUTER-AIDED INSTRUCTION AND EDUCATION -ELECTRONIC FUNDS TRANSFER AND AUTOMATED BANKING -ELECTRONIC NEWSPAPERS -PUBLIC INFORMATION DISSEMINATION -SECURITY AND AUTHENTICATION -IMPEDIMENTS TO PROGRESS -TECHNICAL AND POLITICAL -STANDARDIZATION -VALUE ADDED SERVICES -COMMUNICATION TECHNIQUES -MICROELECTRONICS THEY WANT A SIGNED STATEMENT THAT THE PAPER HAS NOT BEEN SUBMITTED ELSEWHERE AND THAT IF ACCEPTED THE AUTHOR AGREES TO SHOW UP IN PARIS TO PRESENT IT. FINAL PAPERS HAVE TO BE SUBMITTED BY SEPT 15TH. PAPERS ARE TO FIT UNDER JUST ONE TOPIC. IF THIS LOOKS LIKE SOMETHING YOU ARE INTERESTED IN, HOW ABOUT SENDING ME A NOTE WITH A MAILING ADDRESS SO I CAN SEND YOU THE CALL FOR PAPERS WHEN IT ARRIVES. I CAN BE REACHED AT MARTIN@USC-ECL. BY MAIL IT IS DR. TOM MARTIN, ANNENBERG SCHOOL, UNIV. OF SO. CAL., LA, CALIF. 90007. BY PHONE ITS (213)741-7414. I WON'T BE CONTACTABLE AT ANY OF THESE PLACES AGAIN UNTIL NEXT MONDAY. IF YOU ARE NOT INTERESTED (OR ARE INTERESTED AND DON'T FEEL PROTECTIVE) PLEASE PASS THE MESSAGE ALONG TO PEOPLE YOU KNOW WHO ARE INTERESTED -- WHETHER OR NOT ON THE NET. THANK YOU. TOM MARTIN -------