25-OCT-78 19:38:29-PDT,5731;000000000001 Mail-from: USC-ISI rcvd at 11-MAY-78 0024-PDT Date: 11 MAY 1978 0023-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 701 [isi]Proceeding.Survey#651-#700 From: MSGGROUP at USC-ISI To: [ISI]Mailing.List;155: Message-ID: <[USC-ISI]11-MAY-78 00:23:45.STEFFERUD> Redistributed-To: SANDBERG at BBN Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 25 JUL 1978 -- Messages from file: [USC-ISI]PROCEEDINGS.MSG#651-#700;1 -- THURSDAY, MAY 11, 1978 00:08:32-PDT -- 46 10 MAY MARTIN at USC-ECL MSGGROUP# 700 MAY 1979 IFIP TELEINFORMATICS CONFERENCE IN PARIS 45 10 May Geoff at SRI-KA (Geof MSGGROUP# 699 [THUERK at DEC-MARLBORO: ADRIAN@SRI-KL] 44 9 MAY RMS at MIT-AI (Richar MSGGROUP# 698 DEC message [VERY TASTY!] 43 8 MAY RMS at MIT-AI (Richar MSGGROUP# 697 Some Thoughts about advertising 42 7 May MRC at SU-AI (Mark Cr MSGGROUP# 696 in reply to Jake's message about advertising 41 7 May Feinler at SRI-KL (Ja MSGGROUP# 695 Personal comments on DEC message for MsgGroup 40 4 May Feinler at SRI-KL (Ja MSGGROUP# 694 DEC Message 39 4 May ZELLICH at OFFICE-1 MSGGROUP# 693 INOVATIONS IN ENGINEERING PUBLICATION 38 4 May JMC at SU-AI (John Mc MSGGROUP# 692 reaction 37 04 MAY SLES at CCA MSGGROUP# 691 Project Swing Carto 36 3 May PANKO at BBN-TENEXB MSGGROUP# 688 Reviewers Needed 35 2 May Mike at Rand-Unix MSGGROUP# 687 Re: Discussions of industrial applications 34 3 MAY DCROCKER at USC-ISI MSGGROUP# 686 Politics vs. Legalities 33 3 May Brian Reid at CMU-10A MSGGROUP# 685 Quasar, MsgGroup, and proper use of the ARPAnet 32 2 May DDEUTSCH at BBN-TENEX MSGGROUP# 684 Re: The Quasar Discussion 31 02 MAY SLES at CCA MSGGROUP# 683 Re: The Quasar Discussion 30 3 May MRC at SU-AI (Mark Cr MSGGROUP# 682 QUASAR and the censorship of MsgGroup 29 2 MAY FARBER at USC-ISI MSGGROUP# 681 Re: MsgGroup 28 2 May Brian Reid at CMU-10A MSGGROUP# 680 MsgGroup 27 2 MAY FARBER at USC-ISI MSGGROUP# 679 Re: Comment on Quasar Discussion Question 26 2 May JMC at SU-AI (John Mc MSGGROUP# 678 Comment on Quasar Discussion Question 25 1 MAY PBARAN MSGGROUP# 677 Re: The Quasar Discussion 24 1 May lauren at UCLA-Securi MSGGROUP# 676 MsgGroup and Quasar 23 1 MAY Stefferud, Farber MSGGROUP# 675 The Quasar Discussi 22 23 Apr Ole MSGGROUP# 674 Re: An article on Teletext/Viewdata 21 23 Apr FARBER at SRI-KL MSGGROUP# 673 A ICCC Tutorial 20 23 Apr LEFAIVRE at RUTGERS-1 MSGGROUP# 672 QUASAR ROBOT STILL LIVES 19 22 Apr Tom Bowerman MSGGROUP# 671 MORE ON ELECTRONIC MAIL 18 21 APR FARBER at USC-ISI MSGGROUP# 670 An article on Teletext/Viewdata 17 20 Apr Robert M. Frankston MSGGROUP# 669 Quasar 16 19 APR FARBER at USC-ISI MSGGROUP# 668 Re: More "advances" from "Quasar" 15 12 Apr PANKO at BBN-TENEXB MSGGROUP# 666 Computerworld Meets Computer Mail 14 05 APR JZS at CCA MSGGROUP# 665 RE: [Anders Sandberg, Civilekonom] 13 1 Apr GFF at SU-AI (Geoff G MSGGROUP# 664 ...a little more on the PO and EM scene... 12 1 Apr GFF at SU-AI (Geoff G MSGGROUP# 663 The PO & EM??? 11 1 Apr lauren at UCLA-Securi MSGGROUP# 662 More "advances" from "Quasar" 10 26 MAR Stefferud at USC-ISI MSGGROUP# 661 [Anders Sandberg visits] 9 24 MAR CAINE at USC-ECL MSGGROUP# 660 "The more things change, ..." 8 24 Mar MRC at SU-AI (Mark Cr MSGGROUP# 659 [SANTOS at BBNE: Re: Interface Looping] 7 03/21/ Pogran at MIT-Multics MSGGROUP# 658 Message reliability; reflected ICP's and interface looping 6 Tue, 2 Greep at Rand-Unix MSGGROUP# 657 Re: message reliability, and a plea! 5 21 Mar Robert M. Frankston MSGGROUP# 656 Mail refusals 4 21 Mar Feinler at SRI-KL (Ja MSGGROUP# 655 Re: message reliability, and a plea! 3 21 Mar MRC at SU-AI (Mark Cr MSGGROUP# 654 message reliability , and a plea! 2 03/20/ Tavares.Multics at MI MSGGROUP# 653 Proposed FIPS 1 19 MAR MSGGROUP at USC-ISI MSGGROUP# 651 [ISI]PROC EEDINGS.SURVEY#600-650 ------- 25-OCT-78 19:38:30-PDT,595;000000000001 Mail-from: USC-ISI rcvd at 11-MAY-78 1658-PDT Date: 11 MAY 1978 1658-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 702 SEVEN CHANGES TO MAILING LIST From: STEFFERUD at USC-ISI To: [ISI]Mailing.List;156: Message-ID: <[USC-ISI]11-MAY-78 16:58:06.STEFFERUD> ADD: Reynolds@I4-TENEX, Boggess@ISI, Peeler@ISI, MTravers@BBND, CHANGE: Gaschnig@CMUA to be Gaschnig@SRI-KL REMOVE: Schlesinger@PARC-MAXC, JimC@ISIB, A fresh copy of the Mailing.List may be FTPed directly from [ISIA], or requested via netmail by request to MsgGroup@ISI or to Stefferud@ISI. 25-OCT-78 19:38:30-PDT,962;000000000001 Mail-from: CCTC rcvd at 18-MAY-78 1044-PDT Date: 13 May 1978 at 0841-CDT From: csc@CCTC To: msggroup@usc-isi Subject: MSGGROUP# 703 wire-wrapping Redistributed-To: [ISI]Mailing.List;156: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 22 MAY 1978 - - - I am interested in information, evaluations, and opinions on available wire-wrapping materials and techniques. I am in the process of homebrewing an 8085 based intelligent terminal. due to the dynamic design of the system, wire-wrapping seems to be the best construction alternative available. Hence, I need information on what is available, and most importantly, how to use it and what pitfalls to watch out for. Incidentally, if anyone has any good ideas on what capabilities an intelligent terminal should provide, and how it should interface to a system, I'm also interested in ideas on this. Sincerely, Richard Groot csc@cctc ----- 25-OCT-78 19:38:30-PDT,1719;000000000000 Mail-from: SRI-KA rcvd at 21-MAY-78 1240-PDT Date: 21 May 1978 1216-PDT Sender: GEOFF at SRI-KA Subject: MSGGROUP# 704 ARPANET does it again! From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: [ISI]Mailing.List;156: Message-ID: <[SRI-KA]21-May-78 12:16:31.GEOFF> a291 1901 20 May 78 AM-Computer Grades,230 BOSTON (AP) - Four University of Southern Califora students have reportedly awarded themselves grades they never earned and embellished their records with courses they never took by tapping into the school's computer system, the Boston Globe source said the alleged scheme - involved four students with a knowledge of computer programming, the globe reported Saturday. ''We think the four students did change their grades and they added classes they'd never 'taken, such as upper-division, senior-level engineering classes,'' the source told the Globe. USC has refused comment on the story, but another university source said USC officials also worried about whether the students were able to change financial aid records, so that the university paid out money. ''There was some question whether they could have gone through the financial aid records, but I guess nobody could find that they actually got into the money,'' the Globe quoted a university staff member as saying. The newspaper did not identify the staff member. University officials had to go back to original records and manually check out the students' grades and courses. Word of the computerized grade juggling reached Boston via the ARPANET computer system set up by the U.S. Defense Department's Advanced Research Projects Agency, said the newspaper. ------- 25-OCT-78 19:38:30-PDT,986;000000000001 Mail-from: PARC-MAXC rcvd at 24-MAY-78 0929-PDT Date: 24 May 1978 9:27 am (Wednesday) From: Karlton at PARC-MAXC Subject: MSGGROUP# 705 News item for MAY 24, 1978 To: MsgGroup at USC-ISI Redistributed-To: [ISI]Mailing.List;157: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 27 MAY 1978 This little tidbit was in the Wednesday, May 24, 1978, issue of the "Valley Journal" that gets given away in Cupertino, CA. Litronix Inc., Cupertino, has entered an agreement with Corp., Miami, to produce Lexicon's pocket-sized electronic language translator. According to a statement released by Litronix, the contract will be worth $4.8 million, based on Lexicon's estimates of product deliveries. Litronix will make the translators and accompanying cartridges, using its own display modules and microcomputers and memory devices from other sources. I have no details of what the device is supposed to do. PK ------- 25-OCT-78 19:38:30-PDT,726;000000000000 Mail-from: BBN-TENEXB rcvd at 2-JUN-78 1720-PDT Date: 2 Jun 1978 1959-EDT Sender: PANKO at BBN-TENEXB Subject: MSGGROUP# 706 Query on Special Issue From: PANKO at BBN-TENEXB To: [ISI]Mailing.List;156: Message-ID: <[BBN-TENEXB] 2-Jun-78 19:59:47.PANKO> So far, only Vittal, Henderson, and Krauss have said that they will be submitting papers or minipapers for the special issue on computer mail of Computer Networks. If anyone else plans to submit an article (due date: July 1), please contact me ASAP so that I can make plans for review, etc. Even if you're not sure, please message me so that I can discuss possibilities with you. Aloha, Ra3y Panko, University of Hawaii ------- 25-OCT-78 19:38:30-PDT,1579;000000000000 Mail-From: SRI-KA rcvd at 6-JUN-78 2346-PDT Date: 6 Jun 1978 2330-PDT Sender: GEOFF at SRI-KA Subject: MSGGROUP# 707 Klatu/Quasar shows at the NCC From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: [ISI]Mailing.List;157: Cc: JMC at SAIL, LES at SAIL, Feigenbaum at SUMEX-AIM, Cc: hart at KL, Sacerdoti at KL, Amarel at RUTGERS-10, Cc: PHW at AI, Minsky at AI Message-ID: <[SRI-KA] 6-Jun-78 23:30:58.GEOFF> Those of you who are able to attend the NCC here in smogy Santa Ana/Los Angeles can get your first hand chance at looking Klatu right in the blinking eye. Klatu can be found at the Datamation booth drawing crowds. The routine seemsto be the usual; two guys in the crowd, one of them with his hand to his mouth talking away, and insulting people (to get a laugh) and another guy with his right hand inside an airline flight type bag with a shoulder strap. First the guy with the remote control seeks out a promissing female in the crowd, then the guy with the mike takes over and insults her, and then usualy convinces her to give klatu a hugg (really!!) at which time the guy with the remote sets off a siren. I will say one thing; at least they are/seem-to-be doing this as more of an amusement trick rather than promoting the 'domestic home android' with all the AI, and speech features built in. I'v been doing my best to point out to everyone just who is running this thing, and there has been no hassles with attempts to stop me from doing that as have been done at previous displays in random stores. g ------- 25-OCT-78 19:38:30-PDT,923;000000000000 Mail-From: USC-ISI rcvd at 7-JUN-78 0110-PDT Date: 7 JUN 1978 0110-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 708 Re: Klatu/Quasar shows at the NCC From: STEFFERUD at USC-ISI To: Geoff at SRI-KA Cc: [ISI]Mailing.List;157: Message-ID: <[USC-ISI] 7-JUN-78 01:10:48.STEFFERUD> In-Reply-To: <[SRI-KA] 6-Jun-78 23:30:58.GEOFF> More humorously, I was standing there watching it do nothing spectacular, when I said to the very interested appearing guy next to me - "I wonder where the furtive looking guy is who controls this thing?" He said "FURTIVE?" and instantly moved six paces away from me. I soon after realized that without any effort at all, I had picked out the guy with the voice. He was not furtive, nor really hiding what he was doing in any way that is not approproriate to an entertainment show. I agree with Geoff's assessment of the entertainment. Stef ------- 25-OCT-78 19:38:30-PDT,1361;000000000001 Mail-from: USC-ISI rcvd at 24-JUN-78 1345-PDTMail-from: USC-ISI rcvd at 24-JUN-78 1200-PDT Date: 24 JUN 1978 1156-PDT From: PBARAN Subject: MSGGROUP# 709 Two Paris Conferences To: STEFFERUD cc: PBARAN Redistributed-To: [ISI]Mailing.List;158: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 24 JUN 1978 Louis Pouzin (known to many of you for his work on Cyclades and on networks in general) is organizing two conferences: 1. International Symposium On Flow Control In Computer Networks Paris, 12-14 February 1979 2. Teleinformatics 79 Paris, 28-30 May 1979 Louis would be quite interested in papers on personal telecommunications and related topics for 2.; it is less technically oriented than 1. It will deal with the impact of telecomm on commerce, implications for the individual, social consequences and political issues as well as technological matters. Some of the specific areas include office automation, electronic mail, CAI, EFT and electronic publishing. To participate in either 1. or 2. you must send an intent to submit a paper ASAP. Draft papers are due by 15 Sept 78. For more info contact: Louis Pouzin Institut De Recherche D'Informatique Et D'Automatique 78150 Rocquencourt France or me: Dave Caulkins (mailbox PBARAN@ISI) ------- 225-OCT-78 19:38:30-PDT,529;000000000001 Mail-from: BBN-TENEXB rcvd at 27-JUN-78 1623-PDT Date: 27 Jun 1978 1913-EDT Sender: PANKO at BBN-TENEXB Subject: MSGGROUP# 710 Reviewers From: PANKO at BBN-TENEXB To: [ISI]Mailing.List;156: Message-ID: <[BBN-TENEXB]27-Jun-78 19:13:43.PANKO> I need reviewers for three articles: "OnTyme-A Computer Message System, by Walt Ulrich of Tymshare, "HP-Communication System," by Hank Taylor of Hewlett-Packard Electronic Message Services for the Deaf, by Jeff Krauss of the FCC. Any Volunteers? Ra3y 25-OCT-78 19:38:31-PDT,981;000000000001 Mail-from: SRI-KL rcvd at 29-JUN-78 0414-PDT Date: 28 Jun 1978 1641-PDT Sender: FARBER at SRI-KL Subject: MSGGROUP# 711 Info-text From: FARBER at SRI-KL To: uhlig, jgilbert at BBNB, caine at ECL, stef at KA, To: pbaran at ISI(Attn: Paul), pc at RAND-UNIX Cc: msggroup at ISI Message-ID: <[SRI-KL]28-Jun-78 16:41:35.FARBER> Redistributed-To: [ISI]Mailing.List;158: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 29 JUN 1978 Ref: Broadcast Engineering June 1978 Ad on page 61 Info-text, the US version of the BBC Ceefax System developed to NTSC standards by Micro TV Inc, the American licensee will have its first public over-the-air demonstration in Philadelphia Pa on 26-29 june. Micro TV Inc is a company based in Philadelphia at 3600 Conshohocken Ave . 19131. 215/879-0900 They offer to accept orders for early delivery of the necessary Info-text computers (pdp 11's) and decoders. Dave 25-OCT-78 19:38:31-PDT,405;000000000000 Mail-from: CCA-TENEX rcvd at 30-JUN-78 1423-PDT Date: 30 JUN 1978 1419-EDT From: SLES at CCA Subject: MSGGROUP# 712 Remove Sles at CCA To: [ISI]Mailing.List;156: I'm moving to Florida and will be electronic mail-less, so remove Sles at CCA from the MSGGROUP mailing list. I have enjoyed the dialogue over the past few years. Keep up the great work. --Steve Slesinger ------- 25-OCT-78 19:38:31-PDT,881;000000000000 Mail-from: USC-ISI rcvd at 30-JUN-78 1658-PDT Date: 30 JUN 1978 1658-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 713 Add McLure@SRI-KL, KENS@MIT-ML, Drop SLES@CCA, Subject: & Change DEHall@MIT-Multics to be Hall@BBNB From: STEFFERUD at USC-ISI To: [ISI]Mailing.List;159: Message-ID: <[USC-ISI]30-JUN-78 16:58:25.STEFFERUD> Please note that [ISI]mailing.list;159 is now the up to date mailing list. You should not use older lists with lower version numbers (;158 or lower) because they contain non- existant mailboxes, and you will miss new memebers. A new fresh copy of version ;159 may be obtained via FTP or by NetMail request to MSGGROUP@ISI. Or, you may have your items distributed by sending a copy to MSGGROUP@ISI for redistribution. An extra copy to STEFFERUD@ISI will help to catch my attention. Best regards - Stef 25-OCT-78 19:38:31-PDT,1134;000000000000 Mail-from: USC-ISI rcvd at 15-JUL-78 1305-PDT Date: 15 JUL 1978 1305-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 714 [ADD WIDENER@ECL, DROP CSC-NALCON@SRI-KL ] From: MSGGROUP at USC-ISI To: MSGGROUP Cc: STEFFERUD, MARS-FILER at CCA Message-ID: <[USC-ISI]15-JUL-78 13:05:07.STEFFERUD> THIS MESSAGE SOMEHOW GOT DISCOMBOBILATED, AND ANOTHER WAS GIVEN THE SAME "ACCESSIION NUMBER" (EG MSGGROUP# 709). TO REMEDY THE MISTAKE, I AM INCLUDING THIS FORWARDED COPY AS MSGGROUP# 714 TO KEEP THE RECORD COMPLETE, THOUGH IT MAA HAVE BEEN BENT A BIT. REGRETS - STEF Begin forwarded message Mail-from: USC-ISI rcvd at 11-JUN-78 2346-PDT Date: 11 JUN 1978 2346-PDT From: MSGGROUP at USC-ISI To: [ISI]Mailing.List;158: Subject: MSGGROUP# 709 ADD WIDENER@ECL, DROP CSC-NALCON@SRI-KL Message-ID: <[USC-ISI]11-JUN-78 23:46:29.STEFFERUD> Sender: STEFFERUD at USC-ISI Text: I HAVE ADOPTED THE CONVENTION OF INDICATING THAT THE COMPLETE MESSAGE CONTENT IS IN THE SUBJECT FIELD BY ENDING THE SUBJECT FIELD WITH "". STEF -------------------- End forwarded message 25-OCT-78 19:38:31-PDT,994;000000000000 Mail-from: USC-ISI rcvd at 22-JUL-78 1427-PDT Date: 22 JUL 1978 1426-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 715 [SRI-KL]RFC733.TXT Standard for the Format of ARPA Network Text Messages From: STEFFERUD To: [ISI]Mailing.List;160: Message-ID: <[USC-ISI]22-JUL-78 14:26:59.STEFFERUD> I have had several requests for copies of RFC733 which contains the "Standard for the Format of ARPA Network Text Messages." [SRI-KL]rfc733.txt contains the master Network Information Center copy of this document. It can be FTPed from SRI-KL by logging-in as ANONYMOUS with any password. [ISI]rfc733.txt contains a copy. On request, I will forward a copy via NETMAIL, but you should be warned that it may be too long for some message processors to handle. The file is 30 TENEX Pages long, contains 75,000 Characters, and prints 1996 lines of text on 38 pages. The file contains s for formfeed control. Best Regards - Stef 25-OCT-78 19:38:31-PDT,342;000000000000 Mail-from: USC-ISI rcvd at 22-JUL-78 2025-PDT Date: 22 JUL 1978 2025-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 716 DROP EKGordon@ECL, ADD Bair@SRI-KL, Carlson@ECL, Walsh@Office-1; From: MSGGROUP at USC-ISI To: [ISI]Mailing.List;160: Message-ID: <[USC-ISI]22-JUL-78 20:25:22.STEFFERUD> Best regards - Stef 25-OCT-78 19:38:31-PDT,1384;000000000001 Mail-from: RAND-UNIX rcvd at 25-JUL-78 1515-PDT Date: 25 Jul 78 15:14-PDT Subject: MSGGROUP# 717 Mail to tenex sites containing From: Greep at Rand-Unix To: MsgGroup at Usc-Isi cc: Clements at Bbn-Tenexa, Greep at Rand-Unix Message-ID: Redistributed-To: [ISI]Mailing.List;160: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 25 JUL 1978 BBN has recently modified the Tenex server FTP to treat the Ascii code ETX (control/C) as an `interrupt', apparently because that is the meaning of that character when sent from a logged in terminal on Tenex. One effect is that it is impossible to send mail (using the FTP MAIL command) that contains an ETX to a host running this version of the program. There does not seem to be any justification for handling an Ascii character as an interrupt, although possibly this action would appropriate for one of the telnet control characters, such as interrupt-process. The problem is compounded by the fact that when an ETX is received, Tenex issues a reply code immediately. At our host, the mailer never receives the reply because it is still trying to send the remainder of the message, and apparently neither NCP provides enough buffering to avoid deadlock. Has anyone else observed this problem? 25-OCT-78 19:38:31-PDT,973;000000000001 Mail-from: CMU-10A rcvd at 25-JUL-78 2042-PDT Date: 25 Jul 1978 2338-EDT From: Brian Reid at CMU-10A Subject: MSGGROUP# 718 Re: Mail to tenex sites containing To: Greep at Rand-Unix CC: Clements @ BBN-TenexA, MsgGroup @ USC-ISI, Reid at CMU-10A Message-ID: <25Jul78 233836 BR10@CMU-10A> In-Reply-To: Redistributed-To: [ISI]Mailing.List;160: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 26 JUL 1978 A variant of this same problem is the inability to send mail to many TOPS-10 sites that contains the sequence CR,LF,".",CR,LF. Mail is being transmitted over the control connection and not over the data connection. I think the right solution is to encourage as many sites as possible to implement MLFL without the need of USER and ACCT commands beforehand. Just for fun, here's an ETX character: . I suspect that even the local CMU mailer might have trouble with it. 25-OCT-78 19:38:31-PDT,1170;000000000001 Mail-from: SRI-KA rcvd at 25-JUL-78 2134-PDT Date: 25 Jul 1978 2125-PDT Sender: GEOFF at SRI-KA Subject: MSGGROUP# 719 Re: Mail to tenex sites containing From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: Greep at RAND-UNIX Cc: MsgGroup at USC-ISI, Clements at BBN-TENEXA Message-ID: <[SRI-KA]25-Jul-78 21:25:54.GEOFF> In-Reply-To: Redistributed-To: [ISI]Mailing.List;161: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 26 JUL 1978 I have observed this problem a number of times inthe past, along with another such problem which has to do with users putting a line in their message with just a `.' (dot) on it, which causes premature end of message to reveice and then causes buffers to run out. My (ad hoc) solution to this problem has been to go ovvr to the system with the offending queued up mail file and edit out the offending character thus allowing the message to go thru. I normaly notice this problem when I do an LD (SYSTAT like hack) on our system and see not logged in FTPSER jobs which have been idle for a long time and arre hung on ttyout wait. g 25-OCT-78 19:38:31-PDT,1183;000000000001 Mail-from: BBN-TENEXD rcvd at 25-JUL-78 2219-PDT Date: 26 Jul 1978 0117-EDT From: CLEMENTS at BBN-TENEXD Subject: MSGGROUP# 720 [CLEMENTS at BBND: Mail to tenex sites containing ] To: msggroup at isi, geoff at sri-ka Redistributed-To: [ISI]Mailing.List;161: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 26 JUL 1978 --------------- Mail-from: BBN-TENEXD rcvd at 26-Jul-78 0116-EDT Date: 26 Jul 1978 0115-EDT From: CLEMENTS at BBN-TENEXD Subject: Mail to tenex sites containing To: Greep at Rand-Unix Cc: Clements at Bbn-Tenexa In response to your message of 25 Jul 1978 1819-EDT A couple comments on your message. There's nothing "recent" about that change. It has been that way for quite some time (measured in years). Interrupt process does map to ^C, so in that sense, it is consistent. The correct solution to this and various other telnet-connection problems, and the long-standing problem of a . appearing in mail (the other recurring complaint) is to use MLFL, not MAIL for sending mail. That will give you transparent handling. /Rcc ------- --------------- ------- 25-OCT-78 19:38:32-PDT,1131;000000000001 Mail-from: RAND-UNIX rcvd at 26-JUL-78 0859-PDT Date: 26 Jul 78 08:58-PDT Subject: MSGGROUP# 721 Re: Mail to tenex sites containing From: Greep at Rand-Unix To: Brian Reid at Cmu-10a cc: MsgGroup at Usc-Isi, Greep at Rand-Unix, Clements at Bbn-Tenexa Message-ID: In-Reply-To: Your message of Tuesday, 25 Jul 1978 2338-EDT In-Reply-To: <25Jul78 233836 BR10@CMU-10A> Redistributed-To: [ISI]Mailing.List;161: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 26 JUL 1978 Not being able to send mail with a line containing only a period is due to the mail protocol, not a deficiency in implementations; such a line is defined as the end of the message. (Our mailer fudges this by inserting a space at the beginning of such a line, if one appears in a message to be sent, before transmitting it.) However, the mail protocol does not say anything about aborting the message on ETX. I agree that using MLFL is in general preferable. The ETX in your message got here just fine. What did the CMU mailer do when trying to send it to BBN? 25-OCT-78 19:38:32-PDT,1035;000000000001 Mail-from: CMU-10A rcvd at 26-JUL-78 0915-PDT Date: 26 Jul 1978 1211-EDT From: Brian Reid at CMU-10A Subject: MSGGROUP# 722 Re: Mail to tenex sites containing To: Greep at Rand-Unix CC: MsgGroup at USC-ISI, Clements at BBN-TenexA Message-ID: <26Jul78 121157 BR10@CMU-10A> In-Reply-To: Redistributed-To: [ISI]Mailing.List;161: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 27 JUL 1978 The CMU mailer choked when BBN returned an illegal FTP reply code: !SMLFL 25 Jul 1978 2338-EDT;BBN-TenexA;284RDM.QED[C410BR10];Clements 300 BBN-TENEXA FTP Service 3.0.4 at Tue 25-Jul-78 23:39-EDT 951 MAIL WILL BE FORWARDED TO CLEMENTS at BBN-TENEXD ?Transfer aborted. The mail to MsgGroup, however, didn't return any abnormal status to us. I don't know whether or not Clements ever got the mail. My ARPANET protocol handbook does not list code 951 anywhere. Maybe BBN's does, but I doubt it. Brian 25-OCT-78 19:38:32-PDT,1058;000000000001 Mail-from: RAND-UNIX rcvd at 26-JUL-78 0929-PDT Date: 26 Jul 78 09:27-PDT Subject: MSGGROUP# 723 Re: Mail to tenex sites containing From: Greep at Rand-Unix To: Brian Reid at Cmu-10a cc: Greep at Rand-Unix, MsgGroup at Usc-Isi, Clements at Bbn-Tenexa Message-ID: In-Reply-To: Your message of Wednesday, 26 Jul 1978 1211-EDT In-Reply-To: <26Jul78 121157 BR10@CMU-10A> Redistributed-To: [ISI]Mailing.List;161: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 27 JUL 1978 I take it your mailer stopped at the 951 message, not when trying to send the ETX. This is another Tenex non-standard hack. (I never tried to estimate the proportion of the code in our mailer that handles things like 900 messages from Tenex, requests to log in from Multics, and other esoterica, but I'm sure it's high.) ISIA is running the old version of server FTP that does not check for ETX. Also it looks like your mailer uses MLFL so this should not have been a problem anyway. 25-OCT-78 19:38:32-PDT,2151;000000000001 Mail-from: USC-ISI rcvd at 26-JUL-78 1242-PDT Date: 26 JUL 1978 1242-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 724 UNDELIVERABLE MAIL CONTAINING From: MSGGROUP at USC-ISI To: [ISI]Mailing.List;160: Cc: [ISI]ETXfailure.List;: Message-ID: <[USC-ISI]26-JUL-78 12:42:22.STEFFERUD> GEE WHIZ! When I redistributed MSGGROUP# 718 this morning, I got back 45 undeliverable messages from 11 HOSTs. The failed addresses are shown below. I will forward the offending message to the failed addresses after editing out the . As a side benefit, I note that a number of these addresses have been changed, with forwarding to other HOSTs. I plan to make the appropriate changes in the mailing list to avoid forwarding. [ISI]ETXfailure.List;:, @BBNA, Burchfiel, DDeutsch, Henderson, Mooers, Myer, NMA, @BBNB, DBall, Hall, Panko, Turman, Whallon, @BBN, Day, Heitmeyer, INFOMEDIA, Mathison, Pool, Walker, @BBND, MTravers, Vittal, @BBNE, JHaverty, @DEC-MARLBORO, KenKing, @OFFICE-1, WMartin, Walsh, Zellich, @PARC-MAXC, Brotz, Karlton, McDaniel, Metcalfe, White, @SRI-KA, Ole, Pine, SDSAN-DMS, @SRI-KL, Bair, Dames, Engelbart, Farber, Feinler, Gaschnig, Geoff, @SRI-KL, Grobstein, Jordan, McLure, Stone, Taylor, vonGehren, All other HOSTs in Mailing.list work OK, with the possible exception of Roberston@RUTGERS-10 which has not been accepting any mail for the past week. The issue has spawned six messages to date, which will require a day or so for me to redistribute. The delay is due to the fact that I must redistribute them only one at a time due to directory limits on the number of file names that I may have at any ssngle time. If I redistribute two messages in succession, I blow the limits. So, I must wait for each to clear before doing the next. If you cannot wait to get your message out, then you will have to send it dirrectly. I suggest that you directly copy those who are directly involved in the discussion, and let the others get their copy via my redistribution, albeit with a delay. Cheers - Stef 25-OCT-78 19:38:32-PDT,918;000000000001 Mail-from: PARC-MAXC rcvd at 26-JUL-78 1508-PDT Date: 26 JUL 1978 1508-PDT From: NELSON at PARC-MAXC Subject: MSGGROUP# 725 Re: Mail to tenex sites containing To: Greep at RAND-UNIX, MsgGroup at USC-ISI Redistributed-To: [ISI]Mailing.List;161: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 27 JUL 1978 In response to the message sent Tue, 25 Jul 78 15:14-PDT from Greep@Rand-Unix As long as we're talking about disgustingly random character treatment again, let's remember that the Tenex FTP server also eats ^Ls, or at least the one here did in my test last night. I like my mail READING program to make decisions like these, not supposedly "transparent" distribution systems. And let's PLEASE not have the file vs. file pointer argument again: I don't like to grope around for my mail, that's what these machines are for! Bruce ------- 25-OCT-78 19:38:32-PDT,1056;000000000001 Mail-from: SU-AI rcvd at 27-JUL-78 0037-PDT Date: 27 Jul 1978 0034-PDT From: MRC at SU-AI (Mark Crispin) Subject: MSGGROUP# 726 9xx codes To: Reid at CMU-10A, Greep at RAND-UNIX, MsgGroup at USC-ISI Redistributed-To: [ISI]Mailing.List;161: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 27 JUL 1978 BBN uses these codes to mean "experimental" codes. I think that is documented somewhere in the green book, although of course nobody implements the green book's idea of an FTP protocol (nobody, that is, who expects to be able to talk to anybody else). I do know that it is explicitly documented in RFC 385. Harvey, in his RFC 691 (which should be required reading for all network hackers, especially protocol hackers), disapproves of this convention; but he does acknowledge its existance. To the best of my knowledge, his scheme for reply codes was never implemented by anybody except possibly Harrenstein at MIT (although SU-AI's new FTP (whenever it is written) will use them). -- m 25-OCT-78 19:38:32-PDT,557;000000000001 Mail-from: CMU-10A rcvd at 27-JUL-78 0857-PDT Date: 27 Jul 1978 1154-EDT From: Rick Gumpertz at CMU-10A Subject: MSGGROUP# 727 Re: Mail to tenex sites containing To: MsgGroup at Usc-Isi Message-ID: <27Jul78 115409 RG02@CMU-10A> In-Reply-To: Redistributed-To: [ISI]Mailing.List;161: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 27 JUL 1978 I mildly object too -- why not use telnet IP?? Surely whatever is connected can generate an IP (?) Rick 25-OCT-78 19:38:32-PDT,561;000000000001 Mail-from: SRI-KA rcvd at 28-JUL-78 0356-PDT Date: 28 Jul 1978 0239-PDT Sender: SDSAN-DMS at SRI-KA Subject: MSGGROUP# 728 RE: MAIL TO TENEX SITES CONTAINING From: SDSAN-DMS To: MSGGROUP at USC-ISI Cc: SDSAN-DMS Message-ID: <[SRI-KA]28-Jul-78 02:39:19.SDSAN-DMS> Redistributed-To: [ISI]Mailing.List;161: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 28 JUL 1978 IF OUR LIST OF RANDOM CHARACTER TREATMENT IS TO BE COMPLETE I WISH TO ADD MY PET PEEVE ON THE DISAPPEARANCE OF LINE FEEDS. TOM BOWERMAN 25-OCT-78 19:38:32-PDT,810;000000000001 Mail-from: USC-ISI rcvd at 28-JUL-78 0539-PDT Date: 28 JUL 1978 0539-PDT Sender: GOODWIN at USC-ISI Subject: MSGGROUP# 729 "my computer's better than yours" From: GOODWIN at USC-ISI To: stefferud Message-ID: <[USC-ISI]28-JUL-78 05:39:17.GOODWIN> Redistributed-To: [ISI]Mailing.List;161: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 29 JUL 1978 In view of latest MSGGROUP exchange I couldnt resist sending you this item from Aug Reader's Digest: "I've invented a computer that's almost human," boasted one scientist to another. "You mean it can think?" asked his colleague. "No. But when it makes a mistake, it can put the blame on some other computer." "The Right Hand" 25-OCT-78 19:38:33-PDT,659;000000000000 Mail-from: USC-ISI rcvd at 29-JUL-78 1028-PDT Date: 29 JUL 1978 1010-PDT Sender: DCROCKER at USC-ISI Subject: MSGGROUP# 730 Transition From: DCROCKER at USC-ISI To: [ISI]Mailing.List;161:, To: Header-People at MIT-MC, list: Message-ID: <[USC-ISI]29-JUL-78 10:10:40.DCROCKER> I will be off the net from 1 Aug to about 25 Aug, and will be in transit from Los Angeles to the University of Delaware. Once situated in beautiful downtown Newark (De.), I'll be working on my doctorate. Tho Delaware is not (currently) on the network, I'll still have access to my mailbox and will be continuing as a consultant with Rand. Dave. 25-OCT-78 19:38:33-PDT,730;000000000001 Mail-from: USC-ISI rcvd at 9-AUG-78 1233-PDT Date: 9 AUG 1978 1232-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 731 Special Issue of Bell System technical Journal From: FARBER at USC-ISI To: [ISI]Mailing.List;161: Message-ID: <[USC-ISI] 9-AUG-78 12:32:51.FARBER> The July-August issue of the BSTJ (Bell System technical Journal) is devoted to the UNIX operating system. It has 22 articles that cover all aspects of the system. recommended reading. It can be obtained from Bell Laboratories for $2.00 the issue ($20.00 per year) . Write requesting Volume 57, No. 6 part 2 to: Bell Laboratories Circulation Group Whippany, N.J. 07981 Checks should be payable to the BSTJ. Dave 25-OCT-78 19:38:33-PDT,424;000000000000 Mail-from: SRI-KA rcvd at 15-AUG-78 1752-PDT Date: 15 Aug 1978 1743-PDT Sender: GEOFF at SRI-KA Subject: MSGGROUP# 732 "Intelligent Copiers" WSJ, Page 4, 15AUG78 From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: [ISI]Mailing.List;161: Message-ID: <[SRI-KA]15-Aug-78 17:43:56.GEOFF> See today's (15AUG78) copy of the Wall Street Journal, on Page 4, Columns 2, 3 & 4. Xerox is revealed (at last). g 25-OCT-78 19:38:33-PDT,546;000000000001 Mail-from: SRI-KL rcvd at 19-Aug-78 1148-PDT Date: 19 Aug 1978 1148-PDT Sender: BAIR at SRI-KL Subject: MSGGROUP# 733 Message system features question From: BAIR at SRI-KL To: stefferud@ISI Cc: BAIR Message-ID: <[SRI-KL]19-Aug-78 11:48:04-PDT.BAIR> Redistributed-To: [ISI]Mailing.List;162: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 22 AUG 1978 Stef, Where can I find (online) a list of the user features of the ideal msg system? This may be a question for the MSGGROUP. Thanks, jim 25-OCT-78 19:38:33-PDT,356;000000000001 Mail-from: USC-ISI rcvd at 22-AUG-78 2232-PDT Date: 22 AUG 1978 2232-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 734 ADD Hewitt@SRI-KA, CHANGE NELC3030 to be Comport@ISI From: MSGGROUP at USC-ISI To: [ISI]Mailing.List;162: Cc: Hewitt at SRI-KA, Comport, NELC3030 Message-ID: <[USC-ISI]22-AUG-78 22:32:07.STEFFERUD> Stef 25-OCT-78 19:38:33-PDT,1738;000000000001 Mail-from: CCA-TENEX rcvd at 24-AUG-78 0850-PDT Date: 24 AUG 1978 1151-EDT From: JZS at CCA Subject: MSGGROUP# 735 Re: Message system features question To: BAIR at SRI-KL cc: Stefferud at ISI, Rothnie at CCA, Winter at CCA, cc: MARS-Filer at CCA Redistributed-To: [ISI]Mailing.List;162: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 24 AUG 1978 In response to your message sent 19 Aug 1978 1148-PDT Prompted by your recent request for a list of the user features of the ideal message system, and armed with a few years' worth of messages on or bordering on that topic (available via the CCA MARS message archiving and retrieval service), I decided to look into what might already be available online -- though I do hope that MsgGroup will again take up the discussion. I sent 3 retrieval requests to MARS-Retriever@CCA: (1) for any messages with the words 'user', 'features', 'ideal', 'message' and 'system' appearing in the body of any public message on file; (2) for any messages with the words 'user' and 'features' in the message-body; and (3) for any messages with the words 'ideal', 'message' and 'system'. The first request did not retrieve any messages; the second retrieved about 20 messages; and the third request produced 4 messages. One message in particular, MsgGroup# 34 from Dave Crocker, dated back on 20 June 1975, offers 'an initial list' of desired features for the ideal message system. I found the other messages interesting and pertinent as well. Please let me know if you'd like to see them. The whole batch takes 23 disk pages, a little over 56K bytes. Joanne Sattley 25-OCT-78 19:38:33-PDT,986;000000000000 Mail-from: USC-ISI rcvd at 26-AUG-78 2328-PDT Date: 26 AUG 1978 2328-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 736 Re: Message system features question From: STEFFERUD at USC-ISI To: JZS at CCA Cc: BAIR at SRI-KL, Stefferud, Rothnie at CCA, Winter at CCA, Cc: MARS-Filer at CCA, [ISI]Mailing.List;162: Message-ID: <[USC-ISI]26-AUG-78 23:28:26.STEFFERUD> In-Reply-To: Your message of AUGUST 24, 1978 Hi Joanne - Your finding is interesting. How about sending a "survey" or index of each "find" to MsgGroup for us all to see. Then we might be able to ask for specific msgs. While we are at it, how about making the message files availble for FTP to MsgGroup@ISI where they are openly available to all the members. I recall that anyone can use the CCA DATA-COMPUTER archives by sendng appropriate query msgs to MARS-Retriever@CCA. Do you have some handy info on how we can all do that to search for stuff of interest? Thanks - Stef 25-OCT-78 19:38:33-PDT,867;000000000001 Mail-from: SRI-KA rcvd at 28-AUG-78 0639-PDT Date: 28 Aug 1978 0633-PDT Sender: OLE at SRI-KA Subject: MSGGROUP# 737 Re: CCA DATA-COMPUTER archives From: Ole at SRI-KA (Ole J. Jacobsen) To: MSGGROUP at USC-ISI Cc: Geoff Message-ID: <[SRI-KA]28-Aug-78 06:33:55.OLE> Redistributed-To: [ISI]Mailing.List;163: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 31 AUG 1978 The last msg to Msggroup, reminded me of something I heard some time ago: My boss, Yngvar said that we can all use the DATA-COMPUTER back in Boston, not only for searching through other msgs, but also archive our own stuff. In my opinion there is no better way to keep old important msgs,-as opposed to having them in a huge msg-file which tends to get unmanageable. I think Geoff does this, but perhaps that is one of his priveleges?? OLE 25-OCT-78 19:38:33-PDT,1067;000000000001 Mail-from: SRI-KA rcvd at 28-AUG-78 1102-PDT Date: 28 Aug 1978 1054-PDT Sender: GEOFF at SRI-KA Subject: MSGGROUP# 738 Re: CCA DATA-COMPUTER archives From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: Ole Cc: MSGGROUP at USC-ISI Message-ID: <[SRI-KA]28-Aug-78 10:54:50.GEOFF> In-Reply-To: <[SRI-KA]28-Aug-78 06:33:55.OLE> Redistributed-To: [ISI]Mailing.List;163: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 31 AUG 1978 Because the CCA DATACOMPUTER MARS system doesn't allow for security of ones messages what I do is to maintain a monthly file in my TENEX called SAVED.MESSAGES which contains a copy of every message I have sent or moved out of my primary MESSAGE.TXT for the current month. then at the end of the month I store that file on the Datacomputer under one of my DFTP sub-directories. If MARS had some privacy hooks in it, I'd use it for storing all of my messages, but alas, it doesn't seem to, unless of course, i encrypted all messages i sent there which is more trouble than its worth. 25-OCT-78 19:38:34-PDT,1927;000000000001 Mail-from: CCA-TENEX rcvd at 29-AUG-78 1330-PDT Date: 29 AUG 1978 1631-EDT From: JZS at CCA Subject: MSGGROUP# 739 Re: Message system features question To: STEFFERUD at USC-ISI cc: BAIR at SRI-KL, Rothnie at CCA, Winter at CCA, cc: MARS-Filer at CCA Redistributed-To: [ISI]Mailing.List;163: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 1 SEP 1978 In response to your message sent 26 AUG 1978 2328-PDT Hi Stef - I've made the batch of retrieved messages, copies of the retrieval requests (aka query msgs), and a list of the interesting SUBJECT: fields directly available from the Datacomputer via the DFTP program. Anyone with access to DFTP may type "ATTACH COMMON>MARS" at it to get to the right node, and then "DIR[CRLF][CRLF]" to see what's filed there. "GET filename.extension[CRLF]" moves a copy of the file from the Datacomputer to the caller's local directory. Below is a list of the current files: RR.SAV A Tenex program for generating Retrieval Requests interactively. USER.CARD A one-page blurb on how to use MARS. MARS.RFC744 A technical memorandum on the prototype MARS Service. MARS.NOTE1 An informal report on the status of the Service as of the end of March, 1978. BATCH.RR The Retrieval Requests which retrieved the ideal-msg- system messages from MARS. BATCH.IDEAL The retrieved messages. BATCH.SUBJECTS The SUBJECT fields of most of the retrieved messages. I'm willing to mail out any of this information to anyone who requests it -- and would be delighted to discuss MARS, answer questions on the Service and assist in its use. The messages which have MSGGROUP numbers include: 16, 34, 38, 89, 128, 131, 141, 198, 240, 258, 267, 269, 607 and 733. People can FTP these (or read them locally) out of the PROCEEDINGS files at ISI if they prefer. Regards, -- Joanne ------- 25-OCT-78 19:38:34-PDT,316;000000000000 Mail-from: USC-ISI rcvd at 1-SEP-78 1836-PDT Date: 1 SEP 1978 1836-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 740 CHANGE WMartin@OFFICE-1 to be DRXAL-HDA@OFFICE-1 From: MSGGROUP at USC-ISI To: [ISI]Mailing.List;163: Message-ID: <[USC-ISI] 1-SEP-78 18:36:03.STEFFERUD> Best - Stef 25-OCT-78 19:38:34-PDT,1130;000000000001 Mail-from: USC-ISI rcvd at 2-SEP-78 1145-PDT Date: 2 SEP 1978 1144-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 741 Re: Message system features question From: STEFFERUD at USC-ISI To: JZS at CCA Cc: [ISI]Mailing.List;163: Message-ID: <[USC-ISI] 2-SEP-78 11:44:59.STEFFERUD> In-Reply-To: Your message of AUGUST 29, 1978 Hi Joanne - Thanks for the information. Those of us who have access to DFTP will no doubt take advantage. However, I would like to help those who do not have DFTP access to get at the same information. At a minimum, I would like to collect copies of the messages that were retrieved, and put that collection in a separate MsgGroup file. I will distribute a "Survey" of the headers of those messages so everyone in MsgGroup can know what they are. I will pull the MsgGroup messages you cited to start that collection. Can you set up a "MSG" file of the others at [CCA] for FTP to [ISI]? I would also like to include copies of the query messages you used for search and retrieval, and any other CCA info files that you mentioned. Thanks - Stef 25-OCT-78 19:38:34-PDT,1609;000000000000 Mail-from: USC-ISI rcvd at 3-SEP-78 1538-PDT Date: 3 SEP 1978 1538-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 742 Ideal Message System Features Collection From: MSGGROUP at USC-ISI To: [ISI]Mailing.List;163: Message-ID: <[USC-ISI] 3-SEP-78 15:38:15.STEFFERUD> In-Reply-To: <[USC-ISI] 2-SEP-78 11:44:59.STEFFERUD> I have retrieved all the files shown in MSGGROUP# 739, and they are now available for FTP from [ISI]. The specific file names are shown below: [USC-ISI] 3-SEP-78 15:10:35 PGS MARS.NOTE1;1 11 .RFC744;1 5 USER.CARD;1 1 BATCH.IDEAL;1 21 .RR ;1 1 .SUBJECTS;1 1 RR .SAV;1 19 Copies of all these may be obtained by using the MARS Retriever procedures or by request msg sent to MsgGroup. I encourage you all to try out the MARS Retriever thing to see how it works. I have printed these files out for inspection, and find that USER.CARD and MARS.RFC744 are both included in MARS.NOTE1. RR.SAV is of course a binary executable file. I have also reconstructed a TENEX msg file from the BATCH.IDEAL file, and the MSG HEADERS will be distributed in a separate message. I have placed the reconstructed messages in COLLECTION.IDEAL where I will accumulate messages that relate to the "Ideals" question. I will dig these out by tracking back from the initial messages retrieved from MARS. I hope you will point out important messages from the record that relate to the question so I will not have to do all the digging. Best - Stef 25-OCT-78 19:38:34-PDT,3865;000000000000 Mail-from: USC-ISI rcvd at 3-SEP-78 1555-PDT Date: 3 SEP 1978 1554-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 743 Collection.Survey for Collection.Ideal From: STEFFERUD at USC-ISI To: [ISI]Mailing.List;163: Message-ID: <[USC-ISI] 3-SEP-78 15:54:48.STEFFERUD> -- Messages from file: [USC-ISI]COLLECTION.IDEAL;1 -- SUNDAY, SEPTEMBER 3, 1978 15:46:24-PDT -- 1 12 JUN WALKER at USC-ISI MSGGROUP# 16 More on NMSG (544 chrs) 2 20 JUN DCROCKER at USC-ISI MSGGROUP# 34 Getting Specific: Recommendation and Attempt (2719 chrs) 3 21 JUN DCROCKER at USC-ISI MSGGROUP# 38 Thoughts on Command Specification (3765 chrs) 4 16 JUL MOOERS at BBN-TENEXA MSGGROUP# 89 [MOOERS at BBN-TENEXA: XMAIL/MAILSYS: Xed, Format, ^E bug] (1483 chrs) 5 14 AUG WATSON at BBN-TENEXB MSGGROUP# 128 The Chapter on the NLS Journal System by Jim White (3892 chrs) 6 15 AUG DCROCKER at USC-ISI MSGGROUP# 131 Participation in Design Review (1090 chrs) 7 18 AUG DCROCKER at USC-ISI MSGGROUP# 141 NMSG Answer Command / Keyword Invocation of Functions (1644 chrs) 8 4 NOV MOOERS at BBN-TENEXA MSGGROUP# 198 1. HOW MAILSYS DESIGNERS VISUALIZE THE SYSTEM (2003 chrs) 9 29 DEC DCROCKER at USC-ISI MSGGROUP# 240 User Specification of Presentation Format (for Mailsys) (3782 chrs) 10 12 JAN FARBER at USC-ISI MSGGROUP# 258 Some comments on Primative Commands (1049 chrs) 11 15 JAN GROBSTEIN at OFFICE-1 MSGGROUP# 267 re:walker on primitives & non-simple systems (1898 chrs) 12 19 JAN FARBER at USC-ISI MSGGROUP# 269 What is the intended audience (2081 chrs) 13 28 SEP Ken Harrenstien (KLH Mailing list of MAIL programmers (3402 chrs) 14 22 OCT RMF at MIT-MC (Robert Headers fields and names (1761 chrs) 15 3 NOV MOON at MIT-MC (David Jack Haverty's comments on RFC 724 (3152 chrs) 16 8 Feb dmis,anad MSGGROUP# 453 introduction [bowerman@bbnb] (1098 chrs) 17 10 MAY Kahler at SUMEX-AIM MSGGROUP# 545 Re: What's in a name... (2309 chrs) 18 25 MAY Kahler at SUMEX-AIM MSGGROUP# 568 Introduction Richard Kahler (KAHLER@SUMEX-AIM) (1186 chrs) 19 09/01/ Pogran.CompNet at MIT On "From", "Sender", and secretari (1204 chrs) 20 22 Sep BRIAN.REID at CMU-10A mail privacy (1870 chrs) 21 30 Oct MRC at SU-AI (Mark Cr DIALnet mail formats (2465 chrs) 22 13 NOV SIRBU@MIT-MC MSGGROUP# 607 [SIRBU@MIT-MC: Telecommunications Policy Seminar] (1467 chrs) 23 4 Jul MOON at MIT-AI The birth of Emacs (1233 chrs) 24 19 Aug BAIR at SRI-KL MSGGROUP# 733 Message system features question (602 chrs) 25-OCT-78 19:38:34-PDT,1541;000000000000 Mail-from: USC-ISI rcvd at 4-SEP-78 2137-PDT Date: 4 SEP 1978 2137-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 744 [SANDBERG: P.G. HOLMLOEF VISITNG THE U.S.] From: STEFFERUD at USC-ISI To: [ISI]Mailing.List;163: Message-ID: <[USC-ISI] 4-SEP-78 21:37:40.STEFFERUD> Sandberg and Holmloev are from Sweden, and it seems reasonable for us to help them make contacts here in the US, hence I am forwarding this to MsgGroup for your information. Please note that Holmloev does not have netmail access, so you should contact him directly at IFF in Menlo park. Thanks - Stef Begin forwarded message Mail-from: BBN-TENEXA rcvd at 4-SEP-78 1109-PDT Date: 4 Sep 1978 1402-EDT From: SANDBERG at BBN-TENEXA To: STEFFERUD at USC-ISI, SANDBERG Subject: P.G. HOLMLOEF VISITNG THE U.S. Message-ID: <[BBN-TENEXA] 4-Sep-78 14:02:37.SANDBERG> Sender: SANDBERG at BBN-TENEXA HI STEF, MAY BE YOU COULD FORWARD THIS MESSAGE TO THOSE THAT YOU THINK MIGHT BE INTERESTED. MR. P.G. HOLMLOEV, PH D., FROM STOCKHOLM SCHOOL OF ECONOMICS, HAS ASKED ME TO ANNOUNCE THAT HE IS NOW WORKING WITH THE INSTITUTE FOR THE FUTURE, MENLO PARK, CAL. HIS CURRENT WORK AND INTEREST INCLUDE PUBLIC'S ATTITUDES TOWARDS TELECOMMUNICATIONS AND COMMUNICATIONS AT WORK. PREVIOUS WORK CONCERNED WITH NEWSMEN, NEWS SELECTION, READERS ATTITUDES TOWARDS PUBLISHED AND UNPUBLISHED NEWS, NEWS MEDIA IN SOCIETY AND ARGUMENTATION IN ADS. BEST REGARDS ANDERS S. -------------------- End forwarded message 25-OCT-78 19:38:34-PDT,2524;000000000001 Mail-from: CCA-TENEX rcvd at 5-SEP-78 1223-PDT Date: 05 SEP 1978 1523-EDT From: JZS at CCA Subject: MSGGROUP# 745 CCA DATACOMPUTER MARS archives, PUBLIC vs PRIVATE To: Geoff at SRI-KA, Ole at SRI-KA cc: MsgGroup at USC-ISI, Rothnie at CCA, Winter at CCA Redistributed-To: [ISI]Mailing.List;163: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 5 SEP 1978 Hello - I'd like to shed a little light on what can & cannot be retrieved by sending a retrieval request to MARS-Retriever. (See Stef's message MSGGROUP# 742 for a list of all MARS information available in the [ISI] directory. The USER.CARD file describes the format of a retrieval request.) There are both PUBLIC and PRIVATE messages archived in the MARS database; they're assumed to be PRIVATE unless marked as PUBLIC during the filing operation -- and this can be done in one of two ways: either the messages show "PUBLIC@CCA" as a recipient, or special arrangements have been made for MARS-Filer to mark them (as is the case with MsgGroup messages). There is no way for anyone to retrieve anybody else's private messages using the MARS-Retriever. The program, once started up by Tenex, runs without human intervention. It constructs a sequence of commands in Datalanguage, the programming language used to communicate instructions to the Datacomputer. The Datalanguage which is generated by the program (based upon scanning and interpreting the retrieval request (RR) message) has appended to it, a qualification such that every message retrieved from the Datacomputer must satisfy one of the following requirements: . The person who sent the RR also archived the message; . The person who sent the RR also composed the message (regardless of who archived it); . The person who sent the RR also appears on the message as a recipient; or . The message is marked "public". Retrieved messages are automatically mailed back to the person who sent the RR. PRIVATE does not mean SECURE, however. MARS message traffic is as vulnerable as is all ARPANET message traffic; MARS Tenex files are as available as Geoff's SAVED.MESSAGES file; MARS transmissions over the net are as susceptible to snooping as are any others... The MsgGroup and Header-People transcripts compose the bulk of the PUBLIC messages. I'd welcome contributions to it, and/or suggestions of other sources of informative messages. --Joanne Sattley ------- 25-OCT-78 19:38:34-PDT,708;000000000001 Mail-from: USC-ISI rcvd at 9-SEP-78 1238-PDT Date: 9 SEP 1978 1238-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 746 Procedure Change [ISI]MAILING.LIST;164 From: STEFFERUD at USC-ISI To: [ISI]Mailing.List;164: Message-ID: <[USC-ISI] 9-SEP-78 12:38:16.STEFFERUD> I have been uncomfortable with bothering all of you for every change in the mailing list, yet the list must be maintained. So, from now on, I will only notify those who ask to be notified. The mailing list pathname is [ISI]MAILING.LIST;* and it will be open for FTP or direct reading from ISI directories. I will forward a copy via netmail reply to any requests. Best regards - Stef 25-OCT-78 19:38:35-PDT,892;000000000001 Mail- from: BBN-TENEX rcvd at 9-SEP-78 1309-PDT Date: 9 Sep 1978 1606-EDT Sender: POOL at BBN-TENEX Subject: MSGGROUP# 747 Mailing List & Capabilities Question From: POOL at BBN-TENEX To: Stefferud at USC-ISI Message-ID: <[BBN-TENEX] 9-Sep-78 16:06:16.POOL> Redistributed-To: [ISI]Mailing.List;164: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 11 SEP 1978 Would you please forward a copy of the MSGGROUP mailing list to me via netmail. Incidentally, if anyone produces a relatively concise statement of the capabilities of an "ideal" message and/or teleconferencing system which reflects the opinions of a large fraction of the community, I would sure like to see it. I am promoting message and/or teleconference system usage in the Department of Energy and would find such a document very useful. James C T Pool 25-OCT-78 19:38:35-PDT,1206;000000000001 Mail-from: USC-ISI rcvd at 20-SEP-78 1612-PDT Date: 20 SEP 1978 1548-PDT Sender: DCROCKER at USC-ISI Subject: MSGGROUP# 748 Cheap Text Editing Terminal Question From: DCROCKER at USC-ISI To: [ISI]Mailing.List;165: Message-ID: <[USC-ISI]20-SEP-78 15:48:04.DCROCKER> This is a general request for guidance and info. We are about to purchase some cheap (less than $1500.00) terminals which will be used primarily for 2-D text editing (using the rand editor, ned, about which you allowed to make no cracks). It is my general impression that there are no real winners and so I am looking for comments from people about general reliability, visual fatigue (due to lousy display characteristics), ease of typing (for true typists, like secretaries), and availability of function keys (12 +- 4) (preferably laid out in a 2-d pad, rather than linear group at the top of the terminal). Keyboard feel and visual fatigue are the most important points. Ned does not require much intelligence in the terminal (i.e., none) since it really only uses clear screen and absolute cursor positioning. Any help will be appreciated; I haven't looked at terminals in a few years. Dave. 25-OCT-78 19:38:35-PDT,910;000000000001 Mail-from: BBN-TENEXD rcvd at 13-OCT-78 1238-PDT Date: 13 Oct 1978 1442-EDT Sender: KONCER at BBN-TENEXD Subject: MSGGROUP# 749 AUTOMATED OFFICE OF THE FUTURE From: KONCER at BBN-TENEXD To: STEFFERUD at ISI Cc: KONCER Message-ID: <[BBN-TENEXD]13-Oct-78 14:42:01.KONCER> Redistributed-To: [ISI]Mailing.List;167: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 16 OCT 1978 REFERRED TO BY: E. VON GEHREN, ARMY MATERIEL COMMAND MAILBOX: KONCER AT BBND (301) 597-2738 MANAGEMENT ANALYST, OAS, DD SOCIAL SECURITY ADMINISTRATION 6401 SECURITY BLVD. BALTIMORE, MD. 21235 WE ARE DEVELOPING THE AUTOMATED OFFICE OF THE FUTURE AT THE SOCIAL SECURITY ADMINISTRATION. THE OFFICE OF ADVANCED SYSTEMS IS INTERESTED IN YOUR APPROACH TO COST JUSTIFICATION FOR THE AUTOMATED OFFICE. 25-OCT-78 19:38:35-PDT,755;000000000001 Mail-from: SRI-KA rcvd at 14-OCT-78 1656-PDT Date: 14 Oct 1978 1330-PDT From: FJW at MIT-MC Subject: MSGGROUP# 750 IBM 370/AMHDAL 470 MESSAGE SYSTEM QUESTION To: Stef Redistributed-To: [ISI]Mailing.List;167: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 16 OCT 1978 Do you still manage the Msggroup Mailing-List? If so, I'd like to be placed on it. Secondly, I'd like to inquire of this group if there is a non-network MAIL system available for the IBM 370 (an AMDAHL 470), who has it, and how do I get and install it? (This assumes that any necessary auxillary software and OS hooks come with it.) If it is not "free", then how much? Please contact me at FJW@MIT-MC. Thanks, Frank Wancho 23-FEB-79 22:59:12-PST,6858;000000000001 MAIL-FROM: USC-ISI rcvd at 25-OCT-78 2011-PDT Date: 25 OCT 1978 2011-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 751 [ISI]PROCEEDINGS.SURVEY#701-750 From: MSGGROUP at USC-ISI To: [ISI]Mailing.List;168: Message-ID: <[USC-ISI]25-OCT-78 20:11:34.STEFFERUD> Redistributed-To: Sternberg at OF1, David at UTEXAS, Redistributed-To: Szurco at RAND-UNIX Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 7 FEB 1979 -- WEDNESDAY, OCTOBER 25, 1978 19:58:15-PDT -- 43 14 Oct FJW at MIT-MC MSGGROUP# 750 IBM 370/AMHDAL 470 MESSAGE SYSTEM QUESTION (755 chrs) 42 13 Oct KONCER at BBN-TENEXD MSGGROUP# 749 AUTOMATED OFFICE OF THE FUTURE (910 chrs) 41 20 SEP DCROCKER at USC-ISI MSGGROUP# 748 Cheap Text Editing Terminal Question (1206 chrs) 40 9 Sep POOL at BBN-TENEX MSGGROUP# 747 Mailing List & Capabilities Question (892 chrs) 39 9 SEP To:[ISI]Mai MSGGROUP# 746 Procedure Change [ISI]MAILING.LIST;164 (708 chrs) 38 05 SEP JZS at CCA MSGGROUP# 745 CCA DATACOMPUTER MARS archives, PUBLIC vs PRIVATE (2524 chrs) 37 4 SEP To:[ISI]Mai MSGGROUP# 744 [SANDBERG: P.G. HOLMLOEF VISITNG THE U.S.] (1539 chrs) 36 3 SEP To:[ISI]Mai MSGGROUP# 743 Collection.Survey for Collection.Ideal (3865 chrs) 35 3 SEP MSGGROUP at USC-ISI MSGGROUP# 742 Ideal Message System Features Collection (1609 chrs) 34 2 SEP To:JZS at CCA MSGGROUP# 741 Re: Message system features question (1130 chrs) 33 29 AUG JZS at CCA MSGGROUP# 739 Re: Message system features question (1927 chrs) 32 28 Aug Geoff at SRI-KA (Geof MSGGROUP# 738 Re: CCA DATA-COMPUT ER archives (1067 chrs) 31 28 Aug Ole at SRI-KA (Ole J. MSGGROUP# 737 Re: CCA DATA-COMPUT ER archives (867 chrs) 30 26 AUG To:JZS at CCA MSGGROUP# 736 Re: Message system features question (986 chrs) 29 24 AUG JZS at CCA MSGGROUP# 735 Re: Message system features question (1738 chrs) 28 19 Aug BAIR at SRI-KL MSGGROUP# 733 Message system features question (546 chrs) 27 15 Aug Geoff at SRI-KA (Geof MSGGROUP# 732 "Intelligent Copiers" WSJ, Page 4, 15AUG78 (424 chrs) 26 9 AUG FARBER at USC-ISI MSGGROUP# 731 Special Issue of Bell System technical Journal (730 chrs) 25 29 JUL DCROCKER at USC-ISI MSGGROUP# 730 Transition (659 chrs) 24 28 JUL GOODWIN at USC-ISI MSGGROUP# 729 "my computer's better than yours" (810 chrs) 23 28 Jul SDSAN-DMS MSGGROUP# 728 RE: MAIL TO TENEX SITES CONTAINING (561 chrs) 22 27 Jul Rick Gumpertz at CMU- MSGGROUP# 727 Re: Mail to tenex sites containing (557 chrs) 21 27 Jul MRC at SU-AI (Mark Cr MSGGROUP# 726 9xx codes (1056 chrs) 20 26 JUL NELSON at PARC-MAXC MSGGROUP# 725 Re: Mail to tenex sites containing (918 chrs) 19 26 JUL MSGGROUP at USC-ISI MSGGROUP# 724 UNDELIVERABLE MAIL CONTAINING (2151 chrs) 18 26 Jul Greep at Rand-Unix MSGGROUP# 723 Re: Mail to tenex sites containing (1058 chrs) 17 26 Jul Brian Reid at CMU-10A MSGGROUP# 722 Re: Mail to tenex sites containing (1035 chrs) 16 26 Jul Greep at Rand-Unix MSGGROUP# 721 Re: Mail to tenex sites containing (1131 chrs) 15 26 Jul CLEMENTS at BBN-TENEX MSGGROUP# 720 [CLEMENTS at BBND: Mail to tenex sites containing ] (1183 chrs) 14 25 Jul Geoff at SRI-KA (Geof MSGGROUP# 719 Re: Mail to tenex sites containing (1170 chrs) 13 25 Jul Brian Reid at CMU-10A MSGGROUP# 718 Re: Mail to tenex sites containing (973 chrs) 12 25 Jul Greep at Rand-Unix MSGGROUP# 717 Mail to tenex sites containing (1384 chrs) 11 22 JUL To:[ISI]Mai MSGGROUP# 715 [SRI-KL]RF C733.TXT Standard for the Format of ARPA Network Text Messages (994 chrs) 10 28 Jun FARBER at SRI-KL MSGGROUP# 711 Info-text (981 chrs) 9 27 Jun PANKO at BBN-TENEXB MSGGROUP# 710 Reviewers (529 chrs) 8 24 JUN PBARAN MSGGROUP# 709 Two Paris Conferenc (1361 chrs) 7 7 JUN To:Geoff at SRI-KA MSGGROUP# 708 Re: Klatu/Quasar shows at the NCC (923 chrs) 6 6 Jun Geoff at SRI-KA (Geof MSGGROUP# 707 Klatu/Quasar shows at the NCC (1579 chrs) 5 2 Jun PANKO at BBN-TENEXB MSGGROUP# 706 Query on Special Issue (726 chrs) 4 24 May Karlton at PARC-MAXC MSGGROUP# 705 News item for MAY 24, 1978 (986 chrs) 3 21 May Geoff at SRI-KA (Geof MSGGROUP# 704 ARPANET does it again! (1719 chrs) 2 13 May csc@CCTC MSGGROUP# 703 wire-wrapping (962 chrs) 1 11 MAY MSGGROUP at USC-ISI MSGGROUP# 701 [isi]Proc eeding.Survey#651-#700 (5731 chrs) 23-FEB-79 22:59:13-PST,1597;000000000001 Mail-from: OFFICE-1 rcvd at 26-OCT-78 1135-PDT Date: 26 Oct 1978 1058-PDT Sender: FARBER at OFFICE-1 Subject: MSGGROUP# 752 Announcement of meeting and call for papers From: FARBER at OFFICE-1 To: [ISI]Mailing.List;168: Message-ID: <[OFFICE-1]26-Oct-78 10:58:33.FARBER> Redistributed-To: Rindfleisch at SUMEX-AIM Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 18 JAN 1979 At the Kyoto meeting of IFIP Technical Committee 6, the formation of the working group 6.5 on International Computer Message Services was approved and forwarded for approval to the next IFIP General Assembly. As a first activity, the proposed group WG 6.5 is holding a workshop in the Montreal area in early March. At the workshop we expect to cover a spectrum of areas of interest to people involved in the Message Technology field. Among the areas that will be covered will be: Addressing and Delivery, Authentication and Privacy, Regulatory and Management Issues, Protocols, Standard Field Coding and Language, Functions and Facilities. We invite you to contribute papers , presentations etc to the meeting and hope that you pass on this information to others you might know who are working in this area. While attendance is limited we hope to handle all qualified people. For further information contact: Prof. David J. Farber Department of Electrical Engineering University of Delaware Newark, Del 19711 Tele 302-738-1163 ( messages on 2405) ARPANET Farber at Office-1 23-FEB-79 22:59:13-PST,2918;000000000001 Date: 29 OCT 1978 1433-PST Subject: MSGGROUP# 753 New Bio for Einar Stefferud From: Stefferud at ISI To: MsgGroup Cc: Stefferud Mail-from: USC-ISI rcvd at 29-OCT-78 1444-PST Redistributed-To: Rindfleisch at SUMEX-AIM Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 18 JAN 1979 - EINAR STEFFERUD - Einar Stefferud is Founder and President of Network Management Associates, Inc. His firm provides analysis and planning services to management on problems of shared resource environments, particularly those of computer/communication networks, information processing, and office automation. His current practice is focused on management and planning for transfer of technology into the automated office. Assignments include working with all levels of management to deal with the full range of policy, planning, organization, and operating issues, including: - Needs and requirements identification, - Kinds and levels of service to be provided, - Retention and utilization of staff, - Acquisition and utilization of equipment, - Integration of computer, communication, and office technologies, - Operation of facilities and Allocation of resources, - Budgets for service functions, - Management structures for shared facilities, - Planning for service function development, and - Relationships between service functions and their parent institutions. His client list includes SRI International, Hughes Aircraft Company, Digital Equipment Corporation, US Army Materiel Development and Readiness Command (DARCOM), US Army Test and Evaluation Command (TECOM), US Army Yuma Proving Ground, Defense Advanced Research Projects Agency (DARPA), Temple University, Brigham Young University and the LDS Church, and the University of Wisconsin. Contracts have entailed analysis and planning for information processing activities, computer/communication networks, and office automation, resulting in long- and short-range planning documents for organization and operation. Prior to establishment of his own firm in 1969, he served as an Operations Research Scientist at System Development Corporation, as Manager of the Computer Center at Carnegie Institute of Technology, Consultant to The RAND Corporation, and as a Research Associate at the University of California at Los Angeles. He has earned a BA and MBA from UCLA, published in numerous period- icals, organized and participated in many professional conferences. Contact: Einar Stefferud, President Network Management Associates, Inc. 17301 Drey Lane Huntington Beach, California 92647 (714) 842-3711 9-78 23-FEB-79 22:59:13-PST,885;000000000001 Date: 3 NOV 1978 1136-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 754 [FARBER: Please add LPouzin at BBN] From: STEFFERUD at USC-ISI To: MsgGroup Message-ID: <[USC-ISI] 3-NOV-78 11:36:15.STEFFERUD> Mail-from: USC-ISI rcvd at 3-NOV-78 1136-PST Redistributed-To: [ISI]Mailing.List;170: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 3 NOV 1978 Welcome aboard Louis! Stef Begin forwarded message Mail-from: OFFICE-1 rcvd at 3-NOV-78 0532-PST Date: 3 Nov 1978 0531-PST From: FARBER at OFFICE-1 To: Stefferud at ISI Cc: LPouzin at BBN Subject: MSGGROUP Message-ID: <[OFFICE-1] 3-Nov-78 05:31:24.FARBER> Sender: FARBER at OFFICE-1 You should add LPOUZIN at BBN to the MSGGROUP list. Welcome to the US (at least in a message sense). Dave -------------------- End forwarded message 23-FEB-79 22:59:13-PST,413;000000000001 Mail-from: USC-ISI rcvd at 30-NOV-78 1536-PST Date: 30 NOV 1978 1522-PST Sender: DCROCKER at USC-ISI Subject: MSGGROUP# 755 Change DCrocker@ISI TO BE DCrocker@RAND-UNIX From: DCROCKER at USC-ISI To: header-people at MIT-MC, To: [ISI]Mailing.List;170: Message-ID: <[USC-ISI]30-NOV-78 15:22:15.DCROCKER> Effective immediately, my official arpanet address is DCrocker at Rand-Unix Dave. 23-FEB-79 22:59:13-PST,1262;000000000001 Mail-from: SRI-KA rcvd at 4-DEC-78 1929-PST Date: 3 DEC 1978 2120-EST Subject: MSGGROUP# 756 Computerized Bulletin Board Service for New England/Country From: SAM at MIT-AI (Samuel R. Lipson) To: bboard at SU-AI, bboard at RUTGERS, bboard at USC-ISIB Cc: info-micro at MIT-MC, info-pcnet at MIT-MC Redistributed-To: [ISI]Mailing.List;173: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 10 DEC 1978 Today marks the first full day of operation of New Englands first Computerized Bulletin Board Service. The system is intended to provide a message exchanging service for personal computer enthusiasts, and as such no login or account is required. Anyone may access the system by dialing (617)-963-8310 with a 110 or 300 baud Ascii terminal. The system does not transmit parity for those of you who would need to reconfigure you terminals. To tell the system what your baud rate is simply type a carriage return, wait a few seconds and if it has not responded type another cr. (I find on 300 baud terminals it takes 2). From then on the system is self-explanatory. Happy Hacking, 's/Comments to me: Sam Lipson SAM%MIT-AI P.S. The system is NOT mine, this announcement is for a friend. 23-FEB-79 22:59:13-PST,534;000000000001 Mail-from: USC-ISI rcvd at 6-DEC-78 1135-PST Date: 6 Dec 1978 0909-PST Subject: MSGGROUP# 757 TWX/TELEX interface info wanted. From: Geoff at SRI-KL (Geoff Goodfellow) To: [SRI-KL]LIAISON-10-78: Redistributed-To: [ISI]Mailing.List;172: Redistributed-By: GEOFF at USC-ISI Redistributed-Date: 6 DEC 1978 anyone know of any available whizmo's on the market today that would allow you to interface your TWX & TELEX up to a time-sharing system? i.e. auto- dialer (ACU), speak the right protocols, etc.? 23-FEB-79 22:59:13-PST,1195;000000000001 Mail-from: SU-AI rcvd at 7-DEC-78 1425-PST Date: 7 Dec 1978 1423-PST Subject: MSGGROUP# 758 RFC 733 & MSG From: Mark Crispin To: MsgGroup, Header-People at MIT-MC Hey, guys, guess what's happened down in the San Francisco Bay? Yah, you got it, we here at SAIL send RFC 733 style headers to the world. And just guess what happens? We blow the minds of almost every mail reading program in the world! The usual one is the Tenex MSG program. About one a week I get a complaint from some poor Tenex person that my mail headers zap MSG (and what's worse, I'm not the MAIL program maintainer here!). I understand (not that I should spread evil rumors) that the author and/or maintainer of MSG is ... who is one of the authors of 733 (name deleted to protect the guilty). Hey, pardners, why don't we get our act together? Is MSG going to be fixed? Will there be a widely available substitute for it (HERMES is NOT since BBN jealously guards it from other sites)? Or should SAIL roll back to pre-RFC 733? -- Mark P.S. Am I wedged, or do I remember the purpose of 733 being to make it easier for everybody's reader to parse everybody's headers? 23-FEB-79 22:59:13-PST,882;000000000001 Mail-from: CCA-TENEX rcvd at 7-DEC-78 1555-PST Date: 07 DEC 1978 1856-EST Subject: MSGGROUP# 759 Re: RFC 733 & MSG From: JZS at CCA To: MRC at SU-AI, MsgGroup, Header-People at MIT-MC In response to the message sent 7 Dec 1978 1423-PST from Mark Crispin And here in Cambridge, we've been archiving the world's Arpanet mail on the Datacomputer -- with a parser specially trained to scan RFC #733 style headers. (Rather naive, eh?) After much grief scanning past the several flavors of old Unix-style messages [from LL-ASG (since reformed), UTEXAS, Rand-Unix, etc. -- and more recently from CCTC(!)], and the internal ITS-style messages which keep leaking out all over the net, we finally gave in and are now parsing the darn things. How about a consciousness raising effort? Let's rally 'round The Standard (and fix MSG, too)! --Joanne 23-FEB-79 22:59:13-PST,504;000000000001 Mail-from: USC-ISI rcvd at 7-DEC-78 1635-PST Date: 7 DEC 1978 1632-PST Sender: DCROCKER at USC-ISI Subject: MSGGROUP# 760 Re: RFC 733 & MSG From: DCROCKER at USC-ISI To: JZS at CCA Cc: header-people at MIT-MC, msggroup Message-ID: <[USC-ISI] 7-DEC-78 16:32:25.DCROCKER> In-Reply-To: Your message of DECEMBER 7, 1978 The issue is not one of consciousness-raising, per se, but of convincing the people with money that they should pay for the system modifications. good luck. Dave. 23-FEB-79 22:59:13-PST,262;000000000001 Mail-from: USC-ISIB rcvd at 7-DEC-78 1726-PST Date: 7 DEC 1978 1716-PST Subject: MSGGROUP# 761 re: standards From: POSTEL at USC-ISIB To: DCrocker Cc: Header-People at MIT-MC, msggroup Dave: who was it paid you to produce the standard? --jon. 23-FEB-79 22:59:14-PST,800;000000000001 Mail-from: USC-ISI rcvd at 7-DEC-78 1724-PST Date: 7 DEC 1978 1724-PST Sender: GEOFF at USC-ISI Subject: MSGGROUP# 762 Re: RFC 733 & MSG From: the tty of Geoffrey S. Goodfellow To: MRC at SU-AI Cc: MsgGroup, Header-People at MIT-MC Message-ID: <[USC-ISI] 7-DEC-78 17:24:44.GEOFF> In-Reply-To: Your message of DECEMBER 7, 1978 as far as i am aware MSG and MM (TOPS-20 Mail Munger by MMcM) and HG can't handle the new style headers, in fact, as far as i am aware, HERMES is the ONLY(!) program available on TENEX or TOPS-20 which can parse the RFC733 style headers. maybe if someone approached the author of MSG and offered to make MSG win with 733 he might release the sources, but last i heard the author had no time to work on it (or funding i imagine)... 23-FEB-79 22:59:14-PST,1176;000000000001 Mail-from: USC-ISI rcvd at 7-DEC-78 1732-PST Date: 7 DEC 1978 1732-PST Sender: FARBER at USC-ISI Subject: MSGGROUP# 763 Re: RFC 733 & MSG From: FARBER at USC-ISI To: JZS at CCA Cc: MRC at SU-AI, MsgGroup, Header-People at MIT-MC Message-ID: <[USC-ISI] 7-DEC-78 17:32:42.FARBER> In-Reply-To: Your message of DECEMBER 7, 1978 Unfortunately the task of standard setting is ALWAYS easier than that of really adopting the standard by changing existing software to conform to it. In the case of programming languages the ONLY pressure that worked was that from major buyers ( like the Feds etc) to conform to the standard or not to get the business. Unfortunately our message systems are used to much to take the tack that "well if you don't conform you cannot play the game". That suggests that the only reasonable path is for major users ( with $'s) force conformity by pressure on those they buy computer time from. If some of them said conform or we will see if there is another supplier that will then it MAY work. BUT giving up and saying hell it will not happen guarantees that that will be the case. Dave 23-FEB-79 22:59:14-PST,393;000000000001 Mail-from: USC-ISIB rcvd at 7-DEC-78 1811-PST Date: 7 DEC 1978 1808-PST Subject: MSGGROUP# 764 re: standards & rfc 733 From: POSTEL at USC-ISIB To: Geoff at SRI-KA Cc: header-people at MIT-MC, msggroup i am sure that the sources of msg can be provided to anyone who will take on the responsibility of modifying MSG to rfc 733 standards, and maintaining it thereafter. --jon. 23-FEB-79 22:59:14-PST,2139;000000000001 Mail-from: CMU-10A rcvd at 7-DEC-78 1820-PST Date: Thursday, 7 Dec 1978 2119-EST Subject: MSGGROUP# 765 Re: RFC 733 & MSG From: Brian Reid at CMU-10A To: MsgGroup, Header-People at MIT-MC Message-ID: <07Dec78 211929 BR10@CMU-10A> In-Reply-To: Mark Crispin's message of 7 Dec 78 17:23 Reply-To: MsgGroup at USC-ISI, Header-People at MIT-MC As I recall, one of the forces that motivated RFC733 in the first place was the rather disagreeable @i[de facto] standard of Tenex mail format. We minority sites were told "Be compatible with Tenex or you are wrong". The Tenex conventions were the product of convenience and not good design, and RFC733 was intended to be a legislated standard that would solve many of the known problems of the Tenex conventions-become-standards, with room to grow. We are now in a very amusing situation. The network has 3 to 5 TOPS-10 sites (depending on how you count), 1 360-67 (rah!), some ITS, some Multics, some Unixes, some IBM stuf, and some random and mysterious military machines who don't seem to get in on these header frays. And it has many Tenices/Twenices. 20? 30? Who knows. The interesting point is that essentially all of the minority sites -- the Tops-10 and the Waits and the Its and the Unix and the TSS people -- have implemented RFC733. The sluggards, the Tenex sites, have not. This is all quite strange in the light of the economics of software. The replication cost of software is zero. One person, somewhere in some Tenex site, has only to produce a good mail program, and everybody can use it. But nobody has, and I don't think anybody will soon. I have a lot of ideas about why this is happening, as the craft of the devoted hacker slowly dies. But as far as I'm concerned, the best way to deal with this problem is to ignore it. Let those of us who can use our ANSWER commands just smile, and continue to send out standard-format mail smug in the knowledge that it's going to barf up Tenex mail readers, until sooner or later somebody isn't going to be able to stand it any longer, and something will get done about it. Brian 23-FEB-79 22:59:14-PST,528;000000000001 Mail-from: CCA-TENEX rcvd at 7-DEC-78 1952-PST Date: 07 DEC 1978 2253-EST Subject: MSGGROUP# 766 re: standards & rfc 733 From: JZS at CCA To: Postel at USC-ISIB Cc: MsgGroup, Header-People at MIT-MC In response to the message sent 7 DEC 1978 1808-PST from POSTEL@USC-ISIB Alas for the lack of a SAILer... I think it would remove one of the impediments to updating MSG if the source were available for FTPing by anyone willing to look at it. Offering a SAIL compiler along with MSG might help too. --Joanne 23-FEB-79 22:59:14-PST,464;000000000001 Mail-from: USC-ISIB rcvd at 8-DEC-78 0342-PST Date: 7 DEC 1978 2248-PST Subject: MSGGROUP# 767 re: standards & RFC 733 From: POSTEL at USC-ISIB To: Brian.Reid at CMU-10A Cc: Header-People at MIT-MC, msggroup Brian is right on. The thing to do is send things out in the standard format and when someone complains about not being able to parse it or answer it, tell him/her its his/her problem for using a dumb old NONSTANDARD program. --jon. 23-FEB-79 22:59:14-PST,463;000000000001 Mail-from: BBN-TENEXD rcvd at 8-DEC-78 0758-PST Date: 8 Dec 1978 1028-EST Subject: MSGGROUP# 768 MSG & RFC 733 From: VITTAL at BBN-TENEXD To: MsgGroup, Header-People at MC Folks: I agree with Jon and Brian. My plans have been to fix MSG up for the last few months. I hopefully will have time toward the end of this month to make it understand the new standard and fix some other problems that have been bugging people for a long time. John 23-FEB-79 22:59:14-PST,467;000000000001 Mail-from: USC-ISI rcvd at 8-DEC-78 1119-PST Date: 8 DEC 1978 1340-EST Subject: MSGGROUP# 769 Re: RFC 733 & MSG From: EAK at MIT-MC (Earl A. Killian) To: Geoff at SRI-KA Cc: HEADER-PEOPLE at MIT-MC Redistributed-To: msggroup Redistributed-By: FARBER at USC-ISI Redistributed-Date: 8 DEC 1978 Since when can Hermes handle RFC733?? I've used Hermes quite a bit on BBN systems and never found in the slightest bit able to cope with RFC733 headers. 23-FEB-79 22:59:14-PST,634;000000000001 Mail-from: RAND-UNIX rcvd at 8-DEC-78 1200-PST Date: Fri, 8 Dec 78 11:59-PST Subject: MSGGROUP# 770 Re: RFC 733 & MSG From: Greep at Rand-Unix To: DCROCKER Cc: header-people at MIT-MC, msggroup Message-ID: In-Reply-To: Your message of 7 DEC In-Reply-To: <[USC-ISI] 7-DEC-78 16:32:25.DCROCKER> Whatdya mean money? Didn't you know all this stuff is done by hackers? If a few strategically located Chinese eateries (Coleen's, Louie's, etc) were to close down for a few days the hackers wouldn't have anything else to do with their time and would get all these mail fixes hacked pronto. 23-FEB-79 22:59:15-PST,852;000000000001 Mail-from: USC-ISI rcvd at 8-DEC-78 1331-PST Date: 8 DEC 1978 1327-PST Sender: DCROCKER at USC-ISI Subject: MSGGROUP# 771 re: standards From: DCROCKER at USC-ISI To: POSTEL at USC-ISIB Cc: DCrocker, Header-People at MIT-MC, msggroup Message-ID: <[USC-ISI] 8-DEC-78 13:27:30.DCROCKER> In-Reply-To: Your message of DECEMBER 7, 1978 The standard specified in RFC 733 was instigated by Steve Walker, while a Program Manager at Arpa's Information Processing Techniques Office and was theoretically under the supervision of the informal(?) advisory group on Computer-Aided Human Communication. Arpa funds paid for the effort. To keep the record straight, Unix message systems do not, yet, support that standard. The ISIA machine's Hermes also does not support the full standard. I expect the Unix situation will change. Dave. 23-FEB-79 22:59:15-PST,580;000000000001 Mail-from: USC-ISI rcvd at 8-DEC-78 1843-PST Date: 8 DEC 1978 1842-PST Sender: FARBER at USC-ISI Subject: MSGGROUP# 772 re: standards From: FARBER at USC-ISI To: DCROCKER Cc: POSTEL at USC-ISIB, Header-People at MIT-MC, msggroup Message-ID: <[USC-ISI] 8-DEC-78 18:42:57.FARBER> In-Reply-To: <[USC-ISI] 8-DEC-78 13:27:30.DCROCKER> I understand the problem. I suspect that when problems arrise a rapid call to set an indefinite time would help everyone. You are doing a great job. Notes like mine are testimony to the fact that outages are surprising. Dave 23-FEB-79 22:59:15-PST,1062;000000000001 Mail-from: USC-ISI rcvd at 8-DEC-78 1857-PST Date: 8 DEC 1978 1857-PST Sender: FARBER at USC-ISI Subject: MSGGROUP# 773 Request for bibliographic information From: FARBER at USC-ISI To: [ISI]Mailing.List;172: Message-ID: <[USC-ISI] 8-DEC-78 18:57:25.FARBER> Recently IFIPS TC6 has authorized the formation of a new working group WG 6.4 on Local Networks. As part of the first activity of that group, we are gathering a bibliography of pertinent literature in this area. We also expect to maintain a file of all referenced literature and to develop a mechanism for supplying copies. Now we need input into the bibliography. Please send me items by network and US mail. References to internal papers would also be very welcome. If you send copies of the papers I will put them in the file. We expect to publish the first bibliography in January 1979. Dave my address for US mail is: Prof David J. Farber University of Delaware Department of Electrical Engineering Newark, Del 19711 23-FEB-79 22:59:15-PST,1190;000000000001 Mail-from: USC-ISI rcvd at 9-DEC-78 1339-PST Date: 9 DEC 1978 1206-PST Sender: DCROCKER at USC-ISI Subject: MSGGROUP# 774 Long Live Structured Recipients From: DCROCKER at USC-ISI To: RMS at MIT-AI Cc: HEADER-PEOPLE at MIT-MC Message-ID: <[USC-ISI] 9-DEC-78 12:06:08.DCROCKER> In-Reply-To: Your message of DECEMBER 8, 1978 Redistributed-To: msggroup Redistributed-By: FARBER at USC-ISI Redistributed-Date: 9 DEC 1978 It is incredible to me that you still do not understand the difference between what the "standard" interprets and what individual hosts interpret. The quoting convention is to overide the syntax of the standard, in case the contained text, which is presumed to be meaninfgul to the referenced host, happens to include characters which has special meaning to the standard. For example, "(Bug Mumble)" at mit-ai should cause (Mug Mumble) to be given as the arguement of the MAIL/MLFL Ftp command. (Bug "Mumble Foo") at mit-ai is likely meaningless, since everything between the parens is taken, by the standard, as a comment and therefore NOT passed in the FTP command. I believe you want "(Bug \"Mumble Foo\")" at mit-ai. dave. 23-FEB-79 22:59:15-PST,644;000000000001 MAIL-FROM: MIT-MC rcvd at 10-DEC-78 0930-PST Date: 10 DEC 1978 1230-EST From: FFM at MIT-MC (Steven J. Kudlak) Subject: MSGGROUP# 775 RFC 733 and the world To: stew at SUMEX-AIM CC: msggroup at USC-ISI I was under the impression that Stew Rubenstein at SUMEX had designed a program to correctly hack the new flavor of message headers. However I can't remember the exact context too clearly or whether it has SUMEX site dependent hacks or whatever. However I think on closer evalauation it will be found that there are programs besides HERMES on TENEX sites that can hack the new standard. Have fun all, Sends Steve 23-FEB-79 22:59:15-PST,676;000000000001 MAIL-FROM: SUMEX-AIM rcvd at 11-DEC-78 1521-PST Date: 11 Dec 1978 1522-PST From: Rubenstein at SUMEX-AIM Subject: MSGGROUP# 776 RFC733, et al. To: FFM at MC cc: msggroup at ISI I am in the process of finishing a message handling program, called MRD for lack of a better name, which will parse and generate RFC733 style message headers. It is written in FAIL, and features such things as optionally storing the "parse pointers" for a file in page 700, so that all it has to do is parse any new messages. Work has slowed since the summer (I'm a student as well as a part-time programmer at SUMEX), but if you're interested, let me know... Stew ------- 23-FEB-79 22:59:15-PST,1994;000000000001 Mail-from: CMU-10A rcvd at 14-DEC-78 1059-PST Date: 14 Dec 1978 1358-EST From: Joe Newcomer at CMU-10A Subject: MSGGROUP# 777 The RFC flak To: STEFFERUD @ USC-ISI Redistributed-To: [ISI]Mailing.List;174: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 18 DEC 1978 I generally don't participate in these msggroup frays, but this one is too good to miss. I don't recall the exact history of RFC733 at CMU, but part-time employees or those working part-time on our mail reader made both MAIL and RDMAIL programs conform to RFC733, or some close approximation thereunto, in a very short period of time (weeks). RFC733 has now been around a long time (two years?) and seems to be the victim of "it's not my responsibility..." types of excuses. The adoption of a new standard always incurs a software cost as existing code is broght into conformty (damn this 0-key rollover keyboard...), and if anyone had even considered this back when RFC733 was adopted all the TENEX sites would now conform, since the expenditure would have been inevitable anyway. When you can't postpone the inevitable, you might as well lie back and enjoy it.... Why doesn't some TENEX site associated with or proximate to a university hire a part-time undergraduate for a semester to make the changes? It can't possibly cost that much. The usual reason for not making changes is not cost, but lack of manpower. You don't need terribly sophisticated programmers to take an existing mail system and make it conform to a new standard. If the tenex sites were weeping about their programs nonconforming during the first couple months of RFC733, I might feel sympathetic, but too much time has elapsed to evoke anything from me now but bewilderment. If you didn't like the standard, you obviously had time to object; now that it is the standard, there is little excuse for not conforming. joe newcomer 23-FEB-79 22:59:15-PST,1216;000000000001 Mail-from: SRI-KL rcvd at 14-DEC-78 1222-PST Date: 14 Dec 1978 1220-PST Sender: MCLURE at SRI-KL Subject: MSGGROUP# 778 RFC733 handling From: Stuart McLure Cracraft To: MSGGROUP at USC-ISI Message-ID: <[SRI-KL]14-Dec-78 12:20:58.MCLURE> In-Reply-To: <[USC-ISI]14-DEC-78 10:49:47.STEFFERUD> Redistributed-To: [ISI]Mailing.List;174: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 18 DEC 1978 Oh certainly there are other systems that can handle Rfc733 'Partially'. But none can do it thus far as well as HERMES can. MM handles simple stuff like but can't hack multiple addresses as such. However, HERMES still has some problems. THe most reasonable thing about it that I have found is the use of templates, user modifiable, for generation of sends, replies, forwarding, etc. This feature should be incorporated in new systems, in my opinion, since it offers the user the choice whether to send rfc733 headers or only just accept them. If you make a default, then someone invariably will lose whereas if yo have a choice then the person can only be accused of sending 'non-standard' message headers. 23-FEB-79 22:59:15-PST,667;000000000001 Mail-from: USC-ISI rcvd at 18-DEC-78 1802-PST Date: 18 DEC 1978 1802-PST Sender: FARBER at USC-ISI Subject: MSGGROUP# 779 Request for information From: FARBER at USC-ISI To: [ISI]Mailing.List;173:, To: header-people at MIT-MC Message-ID: <[USC-ISI]18-DEC-78 18:02:14.FARBER> We would like to collect a list of the various message systems that are up and running on computers attached to the ARPANET. Information as to the name of the message system, the machine type it is running on as well as the author and number of sites it is on would be greatly appreciated. I will distribute the results via msggroup. Again thanks Dave 23-FEB-79 22:59:16-PST,1958;000000000001 Mail-from: CCA-TENEX rcvd at 19-DEC-78 1209-PST Date: 19 DEC 1978 1510-EST From: Joanne Sattley Subject: MSGGROUP# 780 Re: The RFC flak To: Joe Newcomer at CMU-10A cc: MsgGroup at USC-ISI Redistributed-To: [ISI]Mailing.List;174: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 19 DEC 1978 In response to your message sent 14 Dec 1978 1358-EST To the best of my knowledge, all Tenex sites do transmit the Standard. Nonstandard mail is sent out by some Unixes (those running old message- generating programs) and by MIT (which accidentally mails its internal format over the net). The Tenex problem has to do with reading the headers of -- and composing answers to -- mail written using the more glamorous and exotic mailbox formats. John Vittal of BBN has promised to work on updating the MSG program we use. Nearly a year ago, I did look into the feasibility of installing RDMAIL on my Tenex, in response to someone's airy idea that all it needed was a set of switches around the hardware-dependent code to make it work. I still think that RDMAIL is a fine program; but based in part on an inspection of the code, and partly upon an appraisal of the situation by Brian Reid, I've decided against trying to construct a Tenex version. As the developer of a message archiving system, and the implementor of a program which takes a whack at scanning any message that comes its way, I'm in favor of the universal acceptance and use of a standard message format; the Standard (almost any standard would do really) just makes my job easier. But I'm still ready to discuss, re-examine, and implement changes and extensions to RFC #733 which is, after all, a meritorious basic document. I'd be interested in hearing more opinions on Ken Harrenstien's newly re-proposed extension to allow "structured recipients". All those in favor? --Joanne ------- 23-FEB-79 22:59:16-PST,697;000000000001 Mail-from: USC-ISIE rcvd at 19-DEC-78 1826-PST Date: 19 Dec 1978 1827-PST From: POSTEL at USC-ISIE Subject: MSGGROUP# 781 New RFC Available [SRI-KL]RFC751.TXT To: [isie]Request-For-Comments.List: RFC Announcement RFC 751 is now available in the NIC online library at SRI-KL. 751 is: "Survey of FTP MAIL and MLFL" by P. David Lebling (5 pages) pathname: RFC751.TXT Public access files may be copied from the NIC library at SRI-KL via FTP with username NICGUEST and password ARPA (actually SRI-KL allows copying of public access files via FTP without a login). --jon. ------- 23-FEB-79 22:59:16-PST,517;000000000001 Mail-from: MIT-AI rcvd at 20-DEC-78 0417-PST Date: 20 DEC 1978 0718-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP# 782 Tenex loses indeed To: STEFFERUD at USC-ISI Redistributed-To: [ISI]Mailing.List;174: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 20 DEC 1978 I have within the past couple of weeks received mail from either Tenex or Twenex which had recipient names without host names, for people on the same machine as the sender. 23-FEB-79 22:59:16-PST,9898;000000000000 mail-from: USC-ISI rcvd at 20-DEC-78 2018-PST Date: 20 DEC 1978 1940-PST Sender: DCROCKER at USC-ISI Subject: MSGGROUP# 783 KLH's Proposed Changes to the RFC 733 Standard From: David H. Crocker To: Header-People at MIT-MC, To: [ISI]Mailing.List;174: Message-ID: <[USC-ISI]20-DEC-78 19:40:48.DCROCKER> KLH is proposing changes to the standard specified in RFC 733. These changes would allow the standard to more directly support features currently in use at the MIT 10's and deemed by them and others to be beneficial. A while ago, I verified that RFC 733 does not prevent the encoding of information which uses the features; rather, the mechanism for doing the encoding is deemed awkward. The encoding causes the information to be treated as a simple literal string, rather than a structured data object. It was claimed that one advantage to changing the standard was that it would make it more difficult for message system implementors to ignore the good things that one could do with the structure-encodings. If I understand the proposal correctly, two things are recommended: a) allow nesting of certain parentheses, and b) allow an additional parenthesization set (curly-brackets) within the standard. Angle- brackets now define mailbox-references, within addresses, and regular parentheses define (non-semantic) comments. The curly-brackets would define lists (or trees, since they could be nested) which could occur in place of an atom in an address. First, I hope the above is reasonably accurate, since what follows is based upon it. Second, let me slip in the comment that I think the use of structured data is generally a good idea. Third, what follows does not continue in such a supportive vain. I will first comment on the tactics of the proposal and then on its technical merits, within the current standard. The standard was defined over the course of one year and was published, in its current form, more than one year ago. Many (though of course not enough) sites have implemented parsers for the standard and some of these are being used. To incorporate the proposed change would require that these implementors go back and (again) change their message system address parsers. We are having enough difficulty in getting systems to conform to the standard even minimally; I have little hope that we would have even that much success in getting them to make further revisions. Remember that RFC733, itself, is claimed to be a revision. It attempts to re-specify the standard contained in RFC 680, with as few changes as possible, so that the message-using world can conduct business as it currently wants to while we go off and define a really good protocol/standard. That was our intent at the outset and nothing has changed since then. Some people seem not to appreciate the real-world difficulties in getting a place to allocate (and spend) the programmer-time to make a system change. Good intent on the part of a programmer is not enough, given that s/he has work to do which a) is what they are paid to do and b) takes up all/most of their time. The absence of strong motivation by the programmer is even worse, since then ONLY a directive from the boss will cause the change to happen (maybe). ("Good intention", of course, can really mean "possessiveness" and thereby can have the negative effect of prohibiting others from working on one's system.) All of this is intended to suggest that getting many tens of independently owned and operated systems to incorporate a standard is a non-trivial process and one ought to keep it as smooth as possible. (Some people wanted the standard phased in in a way that would have made it distinguishable from the old standard, expressly for the purpose of smoothness; unfortunately, it also would have added substantially to the cost of making the change, in some cases affecting other software.) There is a vast array of nifty features that we (collectively or at least individually) would like to see in message communication software. I have my set; each of you has yours; and though I would expect considerable overlap, the sets are not identical. If you look back to earlier drafts of the current standard, you will find that several features are no longer in it. Some fields are no longer defined and the list of special (reserved) characters has been shortened. In fact, curly- brackets used to be reserved. The reason the things were removed was to streamline the standard. This goes back to the basic intent of the effort. We were NOT trying to embody all -- or even all of the best -- of the good message system ideas; just enough of them to keep the real world quiet for a few years. That goal, I think, is being forgotten. Clearly, building a parser that maintains nesting of parentheses is no difficult thing. It is, however, more difficult than not maintaining the nesting. (We even require it at one point in the standard.) In this case, it seems particularly ill-advised to incur that cost for all RFC733 parsers when a) only a few are likely to use it in the near term, and b) the information embodied in the "list- isizing" can be encoded without imposing the burden on everyone. Should you think that the burden is trivial enough to be warranted, then note the confusion about "levels of quoting" that continues in our group even after TWO YEARS of discussion. From the perspective of the standard, address information occurs in two kinds of places. The first is an RFC733-oriented place and the second is everywhere else. Quoting only takes place within RFC733-oriented places. When information is put into an RFC733-oriented place, quoting is added as necessary and it is removed when translation takes place into a non- RFC733-oriented place. Translation between two RFC733-oriented places is a simple copy, with quoting preserved; no changes to the data should take place. For example, an MIT address might be "(Bug Mailer) at MIT-MC". In RFC733, this would be: "(Bug Mailer)" at MIT-MC and when it is translated, it is passed in a way that indicates that: (Bug Mailer) is a mailbox reference, and MIT-MC is a host reference For example, the FTP server should get exactly the first string and it does not need the second. Personally, I find it difficult to sustain the claim that the presence of the surrounding quotation marks is all that offensive, since we encounter them regularly in prose and most of us are fairly used to them. (For example, note how I specified the address when introducing it in the text.) However, such a quotation scheme does not support ALL character sequences and an added quoting mechanisms is provided, WITHIN QUOTED STRINGS. It was limited to that location because that is the (only) place that highly site-dependent information is SUPPOSED to occur. Only three characters need to be quoted: carriage-return and the two quotation characters. (I just discovered that the standard does not properly indicate that the single-quoting character (back-slack) itself needs to be quoted by a back-slash.) Neither is terribly popular within addresses. For example, it has been noted that the carriage return could not be supported in the Arpanet, since it terminates the ftp MAIL/MLFL command lines. (I suspect that that is not entirely true, but don't think the issue worth pursuing.) The second and third characters seem equally unlikely, but it did not seem reasonable to prohibit their use. It was claimed that the "::" construct is not adequate either. This wasn't elaborated upon, so I am not certain what objections there were. Note that this mechanism was specifically intended to provide a mechanism encoding new and experimental features. That is why, on its own, a "::" address is supposed to be ignored by those who do not understand it. The standard allows multiple address to be supplied for a single "person". This provides the necessary handle for the use of the special structure: Mailer Bugs <:list:(bug mailer) at mit-mc, "(bug mailer)" at mit-mc> The current standard says that the meaning of the list is that EACH mailbox is to receive a copy. However, ignorant sites couldn't use the first form and would therefore only send to the second, while knowledgeable sites should be able to discern that the two addresses resolve to the same mailbox and therefore they would only send one copy out. Well, enough of this. I am claiming that the timing of the proposal is wrong. The features were proposed before, analyzed, deemed meritorious for longer-term goals and rejected for the current standard. Some may feel that the proposal was "ignored" but, since I attended the relevant meetings, I am painfully certain that it received considerable attention. I am also claiming that the current standard allows encoding the information fairly easily, though admittedly, in a way which does not require/expect other sites to use it. I will end by commenting that I object to the idea of coercing others to conform to a special set of features, felt to be good by some but not in general use, without an extremely strong set of additional needs to support the coercion. It is one thing to OFFER something that you (privately) think is worthwhile; and it is quite another to IMPOSE it. The intent of RFC733 is to impose a standard. That is only reasonable in the face of a VERY strong need. The need has been demonstrated in the variety of difficulties experienced and expressed by many message system implementors. The current proposal fails to make an adequate case for ITS being imposed on everyone. 23-FEB-79 22:59:16-PST,2627;000000000001 mail-from: SU-AI rcvd at 20-DEC-78 2022-PST Date: 20 Dec 1978 2022-PST From: Mark Crispin Subject: MSGGROUP# 784 KLH's proposed changes to RFC 733 To: Header-People at MIT-MC, MsgGroup at USC-ISI Redistributed-To: [ISI]Mailing.List;174: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 20 DEC 1978 Yes, yes, yes, let's adopt KLH's changes. The argument that it would be an "imposition" is superfluous. RFC 733 in itself is an imposition; look at all the sites that haven't implemented it! The "real world" probably is never going to implement RFC 733. From my experience in dealing with the real world, they would consider two-year-long arguments about mail headers to be not only (well known brown colored bull substance) but a waste of time and money. These are the sort of people who consider MSG needlessly hairy, and use it instead of the TYPE monitor command only because TYPE would type every message they've received since the year 1. And by real world I mean the REAL world. The REAL world has no representation on the Arpanet. Let's not kid ourselves; this stuff about mail headers is strictly for Arpanet hacker types like us. I doubt if anybody cares, other than perhaps being outraged at this use of taxpayer's money (think what would happen if Proxmire found out!). I have heard much of this sort of thing from several people: "Why does your [RFC 733] mail system send headers my [Tenex] mail reader can't read?" "Why is all of this cruft in the mail headers I receive"...as if it's MY fault as a hacker that this is happening. In light of all this, KLH's changes are reasonable. They seem to be of greater benefit than some of the RFC 733 options, like postal addresses and header comments, etc. They will provide a good deal of benefit to a certain group of extensive and sophisticated mail users without significantly screwing the rest of the world. So much violation of 733 goes on that is much more of a screw to others than supporting these addresses. Is the standard supposed to be a network-supported and designed standard, or a DCrocker-supported and designed standard? There doesn't seem to be much attention paid on the part of the authors of 733 for opposing viewpoints. In fact, it seems that any opposing viewpoint seems to get an immediate veto on what seems to be one person's esthetic standards. Sorry for this needlessly long message, but a scan of my incoming mail on this topic seems to indicate that this sort of thing is in vogue again. -- Mark 23-FEB-79 22:59:16-PST,772;000000000001 Date: 28 DEC 1978 1040-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 785 FAREWELL FROM ED VONGEHREN From: E. von Gehren To: [ISI]Mailing.List;175: Message-ID: <[USC-ISI]28-DEC-78 10:40:32.STEFFERUD> MAIL-FROM: USC-ISI rcvd at 28-DEC-78 1040-PST MAIL-FROM: USC-ISI rcvd at 28-DEC-78 1013-PST {Dear Friends, Acquaintances, and Associates - On 3 January 1979 I start a new job with Bell Northern Research, Ltd, in Ottawa, Canada. After many fine years with the U. S. government I'm leaving to go on to new challanges. The work I've been doing in DARCOM these past four years has opened me to a world of broader horizons, and now I'm ready to step over the border (pun intended). Peace, Ed 23-FEB-79 22:59:16-PST,664;000000000001 Mail-from: USC-ISIE rcvd at 2-JAN-79 2059-PST Date: 2 Jan 1979 2059-PST From: POSTEL at USC-ISIE Subject: MSGGROUP# 786 New RFC 752 Available To: [isie]Request-For-Comments.List: RFC Announcement RFC 752 is now available in the NIC online library at SRI-KL. 752 is: "A Universal Host Table" by Mark Crispin (13 pages) pathname: RFC752.TXT Public access files may be copied from the NIC library at SRI-KL via FTP with username NICGUEST and password ARPA (actually SRI-KL allows copying of public access files via FTP without a login). --jon. ------- 23-FEB-79 22:59:17-PST,5005;000000000000 Mail-from: BBN-TENEX rcvd at 24-JAN-79 0735-PST Date: 24 Jan 1979 0955-EST Sender: POOL at BBN-TENEX Subject: MSGGROUP# 787 Planning for a DOE Workshop From: POOL at BBN-TENEX To: Hathaway at AMES-67, Burchfiel at BBNA, DDeutsch at BBNA, To: Mathison at BBNA, Mooers at BBN-TENEXE, Myer at BBNA, To: NMA at BBNA, Sandberg at BBNA, Day at BBNB, Hall at BBNB, To: Panko at BBNB, Turman at BBNB, Whallon at BBNB, INFOMEDIA, To: Pool, LPouzin, JHaverty at BBND, Koncer at BBND, To: MTravers at BBND, Vittal at BBND, MARS-Filer at CCA, To: Gross at CCA, JZS at CCA, Tom at CCA, RCT at CCA, To: Mark.Faust at CMUA, Rick.Gumpertz at CMUA, Lehman at CMUA, To: BZM at CMUA, Newcomer at CMUA, Brian.Reid at CMUA, To: RdMail at CMUA, Wactlar at CMUA, TBlount at ECL, Caine at ECL, To: Carlisle at ECL, Carlson at ECL, RDeMent at ECL, To: JMcHugh at ECL, HSolomon at ECL, Widener at ECL, To: Reynolds at I4-TENEX, MSGGROUP at ISIA, Adams at ISIA, To: PBaran at ISIA, Broos at ISIA, Comport at ISIA, To: Goodwin at ISIA, Kirstein at ISIA, Schlaff at ISIA, To: Spivey at ISIA, Stefferud at ISIA, Tasker at ISIA, To: Walker at ISIA, Cohen at ISIB, Ellis at ISIB, Holg at ISIB, To: Postel at ISIB, Stotz at ISIB, Schill at ISIE, KLH at MIT-AI, To: Hewitt at MIT-AI, RMS at MIT-AI, MSGGRP at MIT-DMS, To: Vezza at MIT-DMS, Frankston at MIT-MULTICS, To: Palter at MIT-MULTICS, Pogran at MIT-MULTICS, FFM at MIT-MC, To: FJW at MIT-MC, Sirbu at MIT-MC, CBF at MIT-ML, KENS at MIT-ML, To: Cotton at NBS-10, Dunlavey at NBS-10, JWalker at NBS-10, To: ARMTE at OFFICE-1, DRXAL-HDA at OFFICE-1, DBall at OFFICE-1, To: Dames at OFFICE-1, Farber at OFFICE-1, Grobstein at OFFICE-1, To: Taylor at OFFICE-1, vonGehren at OFFICE-1, Walsh at OFFICE-1, To: Zellich at OFFICE-1, Engelbart at OFFICE-2, To: Jordan at OFFICE-2, Stone at OFFICE-2, Brotz at PARC-MAXC, To: Danielson at PARC-MAXC, AHenderson at PARC-MAXC, To: Karlton at PARC-MAXC, McDaniel at PARC-MAXC, To: White at PARC-MAXC, Anderson at RAND-UNIX, To: DCrocker at RAND-UNIX, Gaines at RAND-UNIX, To: Greep at RAND-UNIX, Kiessig at RAND-UNIX, GRM at RAND-UNIX, To: Szurko at RAND-UNIX, MLW at RAND-UNIX, Geoff at SRI-KA, To: Hewitt at SRI-KA, Ole at SRI-KA, Pine at SRI-KA, To: SDSAN-DMS at SRI-KA, Bair at SRI-KL, LCampbell at SRI-KL, To: Feinler at SRI-KL, Gaschnig at SRI-KL, McLure at SRI-KL, To: Pickens at SRI-KL, MRC at SU-AI, DGR at SU-AI, To: Feldman at SUMEX-AIM, Kahler at SUMEX-AIM, To: Rindfleisch at SUMEX-AIM, Lauren at UCLA-SECURITY, To: Rudisin at UCLA-SECURITY, Steve at UCLA-SECURITY Cc: Austin at BBN-TENEXB, RBBell at BBN-TENEXB, Cc: BNL(Attn: Peshkin), TDButler at BBN-TENEXB, Cc: Buzbee at BBN-TENEXB, Cleland at BBN-TENEXB, Cc: Corones at BBN-TENEXB, Erickson at BBN-TENEXB, Cc: Gardiner at BBN-TENEXB, Hooper at BBN-TENEXB, Cc: Huddleston at BBN-TENEXB, Lohrding at BBN-TENEXB, Messina, Cc: Quong at BBN-TENEXB, Royston at BBN-TENEXB, Cc: Shampine at BBN-TENEXB, Trent at BBN-TENEXB, Cc: RCWard at BBN-TENEXB, Wendroff at BBN-TENEXB, Cc: Hall at BBN-TENEXB, DWatson at BBN-TENEXB, MGoldstein, Cc: Franceschini, Estrin at MIT-MULTICS Message-ID: <[BBN-TENEX]24-Jan-79 09:55:03.POOL> We are exploring the possibility of organizing a workshop on "Challenges and Opportunities for Computer-aided Communication in the Department of Energy". We would hope to address long term questions related to message and teleconference systems. We would seek individuals within DOE mission programs who have potential applications and ask them to outline their anticipated needs in terms of their objectives rather than their conception of available resources. We would also seek individuals in the research community and ask them to survey the state of the art and project the anticipated developments in the area. The workshop would avoid "marketing" and "regulatory" issues, while focusing on technical questions. Unfortunately, we have already encountered a difficulty. The number of meetings is so large that we are having a problem determining a date to propose. We would prefer to have the workshop in the late summer or early fall. While I am, of course, aware of major professional society meetings, I am not adequately aware of meetings which are potential conflicts with the proposed workshop. Therefore, I am interested in learning about 1) the potential interest in participating in such a workshop (based upon the ideas outlined above), and 2) dates of specialized meetings which might cause a conflict for potentially interested participants. Please reply to Pool@BBNC. NOTE: Please excuse the explicit display of the addressees; however, I wanted individuals receiving this message to be aware who received it so that they might forward the text to other individuals potentially interested in the proposed workshop. 23-FEB-79 22:59:17-PST,8341;000000000000 Mail-from: SRI-KL rcvd at 29-JAN-79 2234-PST Date: 29 Jan 1979 2233-PST From: Bair at SRI-KL (James Bair) Subject: MSGGROUP# 788 Workshop on Human-Computer Communication To: DIST2:, To:, To:, To:, To:, To:, To:, To:, To:, To:, To:, To: To:, To:, To:, To:, To:, To:, To:, To:, To: W O R K S H O P "Development of Guidelines for Human-Computer Communication" 19th to 21st February 1979 - Le Bischenberg/Strasbourg - FRANCE Sponsored by: - IFIP WG 6.3 (International Federation for Information processing) - IRIA, Paris (Institut de Recherche d'Informatique et d'Automatique) - ANACT, Paris (Agence Nationale pour l'Amelioration des Conditions de travail) We are in the process of obtaining the sponsorship of the EUROPEAN COMMISSION, Brussels (If you are not personally interested in this workshop or if you do not need this announcement anymore, please pass it on to someone who may be interested. Thank you.) THIS WORKSHOP IS INTENDED FOR ALL THOSE WHO WORK IN THE AREA OF HUMAN-COMPUTER COMMUNICATION: + users, non-EDP professionals + users, EDP-experts + designers from organizations using or manufacturing computers + planners + trade unionists + scientists and researchers. AIMS AND GOALS OF THE WORKSHOP During the last few years there has been an increasing demand for guidelines for human-computer communication covering questions like: - how to design a screen which causes minimum eyestress - which functions of a terminal are required for a particular job - how to design a user language for a specific or general purpose system - how to introduce a system into a user environment, etc. The request for such guidelines stems from very different groups: from users, designers, managers, trade unionists, and vendors. These groups have realized that many users have a lot of difficulties with present systems and that too many systems have failed due to inadequate human-computer communication design. Therefore, guidelines are necessary to aid the design process. This workshop aims at the development of guidelines in close cooperation of all those who are affected by such systems. The goal of the workshop is to list the key issues for the guidelines and to work them out. The resultant guidelines will be edited and distributed by IFIP under the leadership of IFIP WG 6.3 (Working Group 6.3 on Human-Computer Communication of the International Federation for Information Processing, IFIP). This workshop will also enable the participants to discuss solutions to their problems in this area with the help of others with similar problems and experiences. SPEAKERS: There will be six speakers - one for each topic suggested below (page 3) 1. Ergonomics: Mme. Paul-Rey, (not yet confirmed) Institut de Medicine sociale et preventive, Geneve, CH 2. Problems of consistency: Doug Engelbart, Tymshare, Inc., Cupertino,, California, U.S.A. 3. Language design: Reinhard Kofer, Siemens AG, Munchen, FRG 4. Impacts on human communication: Roger Pye, Communication Studies and Planning, Ltd., London, GB 5. Interface for the handicapped: Chris Evans, National Physics Laboratory, Teddington, GB 6. Impacts on organizations: Frank Land, London School of Economics, London, GB ORGANIZATION COMMITEE: Sabine Rohlfs, Softlab, Munchen Gerlinde Schoenberg, EIFIP, Frankfurt Jean-Louis Grange, IRIA, Paris Najah Naffah, IRIA, Paris Jim Bair, SRI International, California, U.S.A. Chairpersons: Sabine Rohlfs Gerlinde Schonberg ------------- THE METHOD OF THE WORKSHOP This workshop is based on active learning methods, i.e. the experience of the participants will determine the resulting guidelines. Lectures will take less than one third of the time, but the speakers will be participating throughout the three days. The main part of the workshop is scheduled for discussions and preparation of the guidelines in small working groups formed at the end of the first day of the workshop. Each participant joins the working group he is most interested at. Each group will elect a chairperson and a secretary, who will present the results of their working group in both oral and written form at the end of the second and third day for plenary discussion. (See schedule) SCHEDULE hours first day second day third day 2 opening working working lectures groups groups 2 lectures working working groups groups 2 lectures working presentation of groups results by chair- person & secretary 2 definition presentation plenary discussion of topics, of results by and editing of organization chairperson results or working and secretary groups SUGGESTED TOPICS 1. Ergonomics: Screen, keyboard 2. Problems of consistency and system integration 3. Language design for non-computer professionals 4. Impacts on human communication 5. Interface for the handicapped 6. Impacts on organizations: socio-technical design, economics SOME REMARKS ON THE EUROPEEN INSTITUTE FOR PLANT AND PROCESS DESIGNERS (EUROPAISCHES INSTITUT FUR INDUSTRIE-PLANER, e.V.) This institute started its work about one year ago. It has been established in Strasbourg/France and in Frankfurt/Western Germany with the financial aid of the European Community. Its aim is to contribute to the improvement of the quality of working life, both by doing research on the impact of new forms of work-organization, and by organizing seminars for all those who are responsible for the design and change of working conditions. This workshop is part of its effort to study the impact of new technologies such as EDP on existing work-organizations, and to gain a better understanding of the socio-technical constraints which too often prevent an efficient and satisfying use of new technologies. ADMINISTRATIVE INFORMATION TIME: The workshop will begin at 10 a.m. on Monday, 19th February, 1979 and end at 6 p.m. on Wednesday , 21st February, 1979 PLACE: The workshop will be held at: F-67210 Le Bischenberg/Obernai about 25KM away from Strasbourg/France (Best way is to take a taxi either from the airport or from the central station). FEES: Fees for the workshop are as follows: DM-350.-per person, excluding meals and accommodation. 50% of the fees have to be payed if a participation is withdrawn after the 10th of February. For registration please fill in enclosed form and mail to: EIFIP c/o G. Schonberg Berger Str. 176 D - 6 FRANKFURT/Main 60 (Tel. 0611/492922) W O R K S H O P: "DEVELOPMENT OF GUIDELINES FOR HUMAN-COMPUTER COMMUNICATION" 19th to 21st Feb. 1979 A P P L I C A T I O N F O R M Surname:.............................. Forename:............................. Title:................................ Nationality:.......................... Employing Organization:............... ...................................... Title of Present Post:................ ...................................... Address:.............................. ...................................... ...................................... Tel.:................................. Form of payment: / / I enclose a cheque for DM 350.- / / I remit the amount of DM 350.- to EIFIP, Deutsche Bank AG Filiale Leipziger Str. D-6 Frankfurt/Main 90 Bank account: 456/8093 Number of Bank: 50070010 Hotel Reservation: / / I would like a Hotel Reservation in the hotel where the workshop takes place. Date:...............Signature:......................... ------- 23-FEB-79 22:59:17-PST,609;000000000001 Mail-from: SRI-KA rcvd at 7-FEB-79 1119-PST Date: 7 Feb 1979 at 1159-CST From: david at UTEXAS Subject: MSGGROUP# 789 Add David@UTEXAS To Mailing Lists To: klh at sri-kl,steff at sri-ka Redistributed-To: stefferud at ISI, msggroup at ISI Redistributed-By: STEF at SRI-KA Redistributed-Date: 7 Feb 1979 Would you please add my name to the header-people and MsgGrp mailing lists that you two respectively maintain. My mailbox is david@utexas. My name is David M. Phillips. I am the liaison for this host and the closest thing they have to a software maintainer now. Thank you. ------- 23-FEB-79 22:59:17-PST,6683;000000000001 Mail-from: CMU-10A rcvd at 8-FEB-79 1335-PST Date: 8 Feb 1979 1633-EST From: MICHAEL SHAMOS at CMU-10A (C370MS20) Subject: MSGGROUP# 790 Are we professionals? To: header-people @ MIT-MC, msggroup @ USC-ISI Message-ID: <08Feb79 163318 MS20@CMU-10A> Redistributed-To: [ISI]Mailing.List;177: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 9 FEB 1979 I am preparing some recommendations about professional certification of computer scientists to a subcommittee of the American Bar Association. Your ideas are important. Please read the following material and mail your carefully considered responses to SHAMOS@CMU-10A. The American Bar Association Section on Science and Technology has a subcommittee on Responsibilities of Computer Professionals. This group is studying issues relating to recognition of professional status for computer and data processing personnel. Such recognition would have advantages and disadvantages for us. For example, licensing laws and a code of professional conduct would seem to improve the image of the profession and the quality of its output but such status might at the same time impose legal liabilities and the spectre of malpractice. (A licensed systems programmer might be successfully sued by a user who paid for his code if it were not properly debugged.) As is the case with all licensed specialties, this risk of liability would be compensated for by higher salaries. I fear that the ABA may arrive at its conclusions by listening far more to lawyers than to computer scientists. It is important for those with intimate knowledge of the field and the nature of our work to provide input for the study. I thus propose to send a document to the chairman of the subcommittee with some ideas for consideration and I would like them to represent the thinking of a sizeable group of. us. Will you please mail me your thoughtful opinions? A copy of my memo will be made public. If you need someplace to start, consider the list of issues below. Please note that the ABA has NOT set itself up as any authrity in this matter. It will NOT dictate to the government what is to be done about computer professionals. It will make recommendations. In the absence of input from the computer science community these recommendations are likely to be followed. We surely want the initial reports to reflect our considered views. General What are the real aims of improving professionalism? The good of mankind, or bettering our own lot? If the public knew that its computer peple were guaranteed to be well-trained and accountable for their work, we might find greater acceptance of computers in general. Are computer people really professionals? (In this context a professional is one who by virtue of his special training and appreciation of ethical values is invested with special privileges and concomitant responsibilities.) Do the people you know fit this mold? Is one a professional just because he can work miracles with monitor UUOs (i.e. has technical skills the layman lacks)? The impetus for professionalization comes from the recognition that computer people can do a great deal of harm, both deliberately and innocently. How can we assure the public that we are qualified to do the job and that we will be answerable for the consequences? Certification Should computer scientists be licensed? This would presumably mean the intrusion of a government bureaucracy and the imposition of standards by the legislature. Some professional society would be designated to accredit individuals. Some excellent hackers might be shortchanged if there are stiff formal requirements. See if you can suggest a certification procedure that would avoid this problem. Should there be a division into professionals and paraprofessionals? For example, licensed systems analysts assisted by unlicensed coders? Would the professional take responsibility for the work of those under his supervision? Role of academic departments Presumably certification will require some academic degrees and/or a licensing examination and/or stiff apprenticeship requirements. What role will academic computer scientists play? Will we teach ethics? Will academics be looked to for guidance in such matters? Code of ethics Should professionals have to obey a code of responsibility? Who would set up and enforce such a thing? Give some examples of suitable provisions. What would constitute a "disbarment" offense? Remember that such a sanction would mean loss of livelihood for the individual. Would computer professionals be held to high abstract standards (e.g. "quality of life", "freedom from oppression", "preservation of the environment") or to the pragmatics of client representation ("do whatever your employer wants")? Imagine that you have been hired to design a credit-reporting system? The employer wants to include features that you regard as oppressive, such as the storage of unverified rumors about a customer's credit. Are you obliged to implement them, or may you withdraw from the job? If you think that we must always stand up for the little guy, don't you think that the American system requires that business be represented too? Should there be a privilege of confidentiality between a computer professional and his client analogous to the doctor-patient or attorney-client privileges? Guidelines for creating intelligent machines? (Cf. the current controversy over recombinant DNA.) Criminal responsibility if things get out of hand? (What good would it do by that time?) Liability How could claims be adjudicated fairly? A computer ombudsman to protect the public from abuse via computer? An arbitration panel of lawyers, computer scientists and businessmen to resolve disputes in which licensed professionals are involved? Malpractice insurance? I hope these topics have gotten you thinking. Before sending me a reply, go away and think hard about these matters. I think they are important and that we can have considerable influence on the administrative process that will take place if we can present views that are rational and carefully thought-out. 23-FEB-79 22:59:17-PST,1932;000000000001 Mail-from: OFFICE-1 rcvd at 10-FEB-79 0552-PST Date: 10 Feb 1979 0549-PST From: Zellich at OFFICE-1 Subject: MSGGROUP# 791 Re: Are we professionals? To: MICHAEL SHAMOS at CMU-10A, header-people at MIT-MC, To: msggroup at USC-ISI cc: ZELLICH Redistributed-To: [ISI]Mailing.List;177: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 11 FEB 1979 In response to the message sent 8 Feb 1979 1633-EST from MICHAEL SHAMOS@CMU-10A The ABA subcommittee should immediately contact the ICCP (Institute for Certification of Computer Professionals), 35 East Wacker Drive, Chicago, Illinois 60601. The ICCP exists for the express purpose of certifying computer "professionals", and has the following constituent societies: ACM ACPA AEDS AIA CIPS DPMA (who originated the CDP and started the whole thing) IEEE ACDP Two different types of examination are currently given (once a year each): The Certificate in Data Processing (CDP) exam, which covers all areas of data processing (a 5-part exam & you have to pass all 5 sections); and the Certificate in Computer Programing exam (CCP). There used to be a Registered Business Programer exam, but it has been dropped in favor of the CCP. Other examinations are in the planning or development stages: CEDPA - Certificate in Electronic Data Processing Auditing; CSA - Certificate in Systems Analysis; and CDE - Certified Data Educator. The ICCP program(s) and goals address many of the questions raised by Michael Shamos' message. In particular, there is a document titled "Code of Ethics, Conduct and Good Practice for Holders of the Certificate in Data Processing". You do not have to belong to any of the ICCP constituent societies to qualify for any of the Certificates, and there is no membership (only the societies') in the ICCP itself. Richard W. Zellich, CDP ------- 23-FEB-79 22:59:17-PST,10505;000000000001 Date: 20 Feb 1979 1008-PST Sender: rudisin at UCLA-SECURITY Subject: MSGGROUP# 792 Response to MSGGROUP 790 re licensing From: rudisin at UCLA-Security To: msggroup Redistributed-To: [ISI]Mailing.List;177: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 20 FEB 1979 This message is a response to the request by Shamos@cmua for comments on the issue of licensing of computer professionals. The very subject is nauseating to me and I am disturbed that such a debate can even take place, let alone that it seems reasonable to many people in our profession. Normally I would not waste the time to reply but recalling the pathetic nature of the IEEE's recent debate on the question, wherein the real issues were ig- nored, I am compelled to respond. In a word, the very idea of governmental licensing of com- puter professionals (or anyone else) is immoral. It is immoral because it is nothing less than a form of slavery. This word seems harsh because people are so used to accepting government licensure of most other disciplines, but it is nonetheless accu- rate. For what else can you call a set of laws which require you to seek the permission of some bureaucrat before you can practice your profession -- before you are allowed to freely use your mind as a computer scientist? This is the fundamental issue; rejection of the principle that licensing is legitimate or moral must be the cornerstone of the computer science community's rejection of the concept. The idea of governmental (coercive) registration is immoral because no government has any right at all to force me to obtain a license to practice this profession. If I wish to offer my services as a computer scientist, I will put my skill and reputa- tion on the line in the free market of ideas and services, by entering into voluntary agreements with customers. The intrusion of government into this market is wrong because it is such a tremendous violation of my right to interact freely and on a voluntary basis with other people. Please note that I have no objection at all to private forms of certification; for example one of the computer societies could offer a credential certifying that its bearer has attained a certain level of skill. If a given certification organization gained a reputation for being reliable in its assessment of pro- fessionals, there would continue to be a market for its service; if not, no one would care about a credential from that organiza- tion and it would be ignored. At any time people would be free to seek customers based on their own reputations, on the posses- sion of certification from various places, on experience, on edu- cation, and so on. A totally free market in the offering of com- puter skills allows maximum creativity and freedom and will fost- er innovation instead of hindering it. Regulation of the computer community would inevitably take us down the path of the regulation of all other industries and groups -- to mediocrity, stagnation and loss of liberty. It is inevitable and plainly obvious from examples such as that of licensing of physicians that the holding of a license is a shield behind which the mediocre can hide while claiming that they are as good as the best of professionals -- after all, doesn't every- one possess the same license? Hasn't the government proven that everyone with a license is of equal competence? This is absurd but is an effect of licensing that is sure to arise. With a licensing apparatus in place the mediocre individuals in a pro- fession can keep out the creative people who challenge their pet theories and procedures or who "threaten" them with greater skill. What better way will exist for mediocre people to guard themselves against the competition of a bright young newcomer self taught on his home microprocessor system than to claim that he has not been properly licensed and is thus a threat to the public? This may sound farfetched, and would certainly not happen immediately, but is inevitable at some later date, especially when you consider that the highly competent people in a profes- sion are usually too busy producing and innovating to waste time actively running the licensing boards. Licensing boards inevit- ably fall into the control of the no better than average member of the profession. Innovation is stifled, as is also apparent in the medical profession; any kind of development which runs counter to the wisdom of the licensing board is vigorously resisted and its practitioners are called quacks. An example is the medical debate over the role of nutrition in health and the holistic approach to health. Acceptance does eventually come for new ideas but only after unnatural and wasteful delays. The holding of a license also makes it far more difficult for a consumer to be protected, because once licensed it is very difficult for an inept practitioner to be unlicensed. This is again apparent from the medical profession -- members of the fra- ternity are very reluctant to testify against each other, and the delays in holding hearings to investigate alleged incompetence are enormous. The result is that instead of immediately being put out of business by market forces, incompetent doctors suffer almost no penalties because the licensing mechanism masks poor performance from view of the customers and eliminates the associ- ated free market penalties. Is the encouragement of mediocrity, the stifling of innova- tion, and the elimination of true market forces as a test of com- peting technologies in the interests of the community or of the public which licensing is erroneously intended to protect? The answer is clearly no. One of the reasons for the incredible vitality and excite- ment of the computer sciences is the fact that there is almost no regulation of the industry, beyond the general harassment and regulation that all businesses must contend with from government. The rapid rate of technological change is intimately connected with the tremendous freedom that computer scientists have in using new technologies, and which companies have in introducing them. There is no need for any of us to ask the approval of the licensing board to see if a new development is suitable. There is no need to wait until a committee studies a new technique and certifies it for use. We can adopt it and risk its use in the marketplace. One can see the contaminating effects of licensing and regulation on our field by looking at the intersection of computer technology and communications, where one can plainly see that the main obstacles to technological advancement in the communication field -- including the development of public com- puter based message systems -- is the onerous hand of government regulation. (Note that FCC regulation of telecommunications is the functional equivalent of the licensing of individuals under discussion here, applied to groups of people (companies)). There are a number of questions posed in Shamos' message and several issues raised which are worth considering separately. The number of erroneous ideas and false alternatives raised in the few paragraphs of the message approach the density of some of todays memory chips, so I will address them as a class. First, there is the issue of the role of the professional. I for one am not here to serve humanity or some fuzzy notion of the public good; my mind is not public property and neither are the fruits of my effort. No one with a sense of self esteem and integrity can accept the notion that a gang of bureaucrats has the right to tell him that he needs a license in order to use his mind to earn a living. I work for myself, by entering into voluntary relationships with other people -- individuals or or- ganizations, employers or employees. The main body of the message dealt with various problems of assuring the quality of work and of protecting customers from the effects of shoddy work. This is where the false alternatives creep in, for the choice confronting todays user of computer ser- vices is not one of being protected by government licensing versus being at the mercy of inept or unscrupulous programmers. An assertion such as this totally ignores the role of voluntary agreement -- in short, it ignores the mechanism of contracts. If I am seeking the design of a computer system there is a simple way to guarantee that it performs satisfactorily -- deal with a firm or a person who is willing to guarantee his work to a mutu- ally agreed upon extent. If the system performs as specified, he gets paid; if it does not, he fixes it at his own expense, and if that fails the system is rejected and he loses his money. All of the other issues raised in the message -- the credit reporting example, the confidentiality issue, codes of responsibility, malpractice, and adjudication of claims -- can all be handled by voluntary mechanisms called contracts. The notion that government licensing can magically improve the level of technology is absurd; if a guarantee of, say, a per- fectly performing compiler cannot be met by current technology it certainly cannot be met because a license is required to try. Instead, innovation will dry up because no one will be able to take the risk of developing a new compiler. I repeat -- issues of acceptable performance, liability for damages, and the han- dling of disputes can be handled without the immoral and disgust- ing use of coercion by government. In sum, licensing is an assault on the very foundations of the most exciting and fastest growing industry today -- that foundation being the free and untrammeled use of the mind and the offering of products for voluntary acceptance by potential custo- mers. Licensing is an attack on competence and an attack on innovation, and it must be resisted because it is immoral. Gerard J. Rudisin (rudisin@ucla-security) 23-FEB-79 22:59:18-PST,1464;000000000001 Mail-from: BBN-TENEXB rcvd at 21-FEB-79 1803-PST Date: 21 Feb 1979 2046-EST Sender: PANKO at BBN-TENEXB Subject: MSGGROUP# 793 Adios from Ra3y Panko From: PANKO at BBN-TENEXB To: [ISI]Mailing.List;177: Message-ID: <[BBN-TENEXB]21-Feb-79 20:46:46.PANKO> I want to thank you all for the help and stimulation you have given me over the last few years. While I would like to continue talking with all of you for many years to come, I no longer have any justification for an ARPANET mailbox. This current mailbox will be dying very soon, perhaps by the time you have received this message. Although off the net, I am not dying myself, so please stay in touch. My mailing address is Raymond R. Panko, College of Business Administration, University of Hawaii at Manoa, 2404 Maile Way, Honolulu, Hawaii, 96822. My work phone is (808) 948-7611; my home phone is (808) 261-2657. Contrary to popular opinion, a trip or phone call to Hawaii no longer costs a significant fraction of the GNP. Let me offer a piece of brotherly advice to you all. Computer mail is rapidly emerging as a commercial enterprise, and you will need to get involved in the outside world, or you may soon find your fine efforts prohibited by regulation, or you may at least find cast-in-concrete standards for computer mail that beggar the dream. Again, thank you, and may God be with you all. Ra3y 23-FEB-79 22:59:18-PST,11166;000000000001 Mail-from: USC-ISI rcvd at 23-FEB-79 0547-PST Date: 23 FEB 1979 0547-PST Sender: FARBER at USC-ISI Subject: MSGGROUP# 794 The CMU Finger program and privacy ... Subject: an interesting set of messages Subject: [The Finger at CMU-10A (F100TF00): Finger and Privacy] From: FARBER at USC-ISI To: [ISI]Mailing.List;177: Message-ID: <[USC-ISI]23-FEB-79 05:47:22.FARBER> When I first saw this set of messages I felt they were of strong interest to the message group community and asked that they be "desensitized" by removing certain names and internal refernces. Dave Begin forwarded message Mail-from: OFFICE-1 rcvd at 23-FEB-79 0539-PST Date: Thursday, 22 Feb 1979 1358-EST From: The Finger at CMU-10A (F100TF00) To: FARBER at OFFICE-1 Subject: Finger and Privacy In-Reply-To: <[OFFICE-1] 9-Feb-79 05:24:12.FARBER> Message-ID: <22Feb79 135842 TF00@CMU-10A> Redistributed-To: farber at ISI Redistributed-By: FARBER at OFFICE-1 Redistributed-Date: 23 Feb 1979 [[ Sorry for the delay in replying to your note -- I have been up to my eyeballs in the CMU admissions committee! ]] A short time ago, the CMU Finger program was endowed with the ability to reveal when a user last logged in and when that user last read his/her mail with our RDMAIL program. To respect the privacy of the individual I arranged for two user profile bits to be added to our existing profile facility (which determines whether a user automatically sees a bulletin board, or gets a message when mail arrives etc.) The two new bits determine whether Finger may reveal the date/time a user last logged in and the date/time that the MAIL.MSG file was last changed. The default setting for the profile bits inhibits Finger from revealing this information. A fairly warm discussion ensued and some of the most significant contributions are appended below. To give you an idea of the level of feeling in the discussion, I should say that I have been referred to as spineless, socially irresponsible, petty politician and other less printable descriptions. The important thing to observe from the notes below is that the issue being discussed IS NOT that I provided the option for inhibiting the information, but that the DEFAULT actually coceals information. Personally, I find this attitude a little disturbing. I would encourage discussion of these issues since I believe that the Computer Science community is approaching the point at which a great deal of its interactions are made through a mechanical medium. The issues of privacy in such a medium are of paramount importance. I would really like to be assured that others share and actively support the individual rights position. If not, its time our community stood back to examine its attitudes and wonder why the general public doesn't trust computers! Ivor Durham (Durham @ CMU-10A) [[ Dave, please feel free to add your own commentary to this part. ]] -------------------------------------------------------------------- ----Message 26 is---- Date: Tuesday, 30 Jan 1979 1808-EST From: Subject: FINGER To: Durham at CMU-10A, Wactlar at CMU-10A, Wulf at CMU-10A I feel very strongly that the decision to make FINGER default to "you cannot finger me" was a very very very bad idea. However, what's done is done, and I'm not going to make a big stink out of it. However, I think that it is possible to recover a certain amount of good sense at this point, after the fact, by changing FINGER so that it will only provide this service (information about people) to those individuals who are allowing themselves to be fingered. I propose the following behavior for FINGER. If user A has enabled himself to be fingered, then if he does a FINGER B, the information that he sees should be determined by the profile bits for B. If user A has not enabled himself to be fingered, and he does a FINGER B, then if B allows the fingering, A should not be shown it, rather a polit message to the point that finger service is only available to those people who allow it of themselves, and the minimum information should be given. Not-logged-in fingers should assume the worst; network fingers can probably go either way. ----Message 27 is---- Date: Wednesday, 31 Jan 1979 0020-EST Subject: Re: Public Pressure. In-Reply-To: <31Jan79 000012 ID20@CMU-10A> [[ The previous message was re-mailed to about half a dozen people all of whom traditionally hold strong opinions on subjects such as that under discussion. My reply encouraged them not to add fuel to the fire, but to encourage people to set their profile bits according to their personal preference rather than ignore the facility. The following message is a response to that note.]] Ivor, I find myself angry that you implement something that is so nice without considering the (more important) social ramifications. If we as computer scientists continue to punt such issues to second place, who the hell is going to take responsiblity for them? In particular, I refer to your attitude about talking to HDW the other day. [[This refers to a discussion in which I had agreed with our operations manager that Finger should be inhibited from revealing login and mail information by default. ID.]] I do not bicker with your RIGHT to leave finger alone, or to leave useage decisions to the elders. And I think that <'s proposal has the smack of a hack. But HE said THAT off the top because HE didn't want to nearly-uselessly flame like I am--like I feel I MUST as an outraged CSist. The decision to remain paranoid is one I accepted because I know how much work and shit would have to be plowed through to change it. I don't hope for it now. But when I yell "closed and tight atmosphere" from my corner and not "free and open research community", be prepared to talk about the REAL thing and please DONT say "What ever policy they decide is fine; I'm just a mechanism." I don't accept your right to punt. I am NOT a mechanism. ----Message 28 is---- Date: 31 Jan 1979 0626-EST From: BILL WULF at CMU-10A (X390WW17) Subject: two cents worth Friends, I have just been sitting here watching the batch of notes fly by concerning the new FINGER, the default of its profile bits, etc. I can't help adding my two cents worth. I presume that we all agree that its kind of a trivial point -- trivial in the sense that the important point is that the facility now exists, and that in the steady state people will get their profile bits set to whatever seems right for themselves (at least the regular system users will). I hope that the fact that Ivor went to the trouble of installing this feature won't get lost in a flap about the default setting of a couple of bits that take seconds to reset. On the other hand the issue of personal privacy is NOT a trivial issue. I think Ivor made exactly the right choices. In questions where personal freedoms, personal privacy, etc. are involved, ALWAYS err on the side of requiring the individual to take positive action. Default on the safe side. I realize that we are a "friendly", "cooperative", ..., community, and I expect that most people won't mind this information being released. But you must recognize that the information can act of coerce people into a particular lifestyle. A major attraction, to me, of netmail is that I read it when I want to -- not when the sender wants me to. Last week I chose not to read my mail for 4 days. As soon as it becomes public that I did that, however, there can/will be both external and internal pressure to read it everyday. Now, maybe that's good too, the goodness/badness is not the issue. The point is that simply because we are a friendly community does not give everyone the right to know certain things about me -- and only I can determine what the things I want known are. Thus, even though information about when I last logged in may seem trivial, its not up to us to decide whether that is something that a particular individual wants known. Again, I think Ivor made exactly the right choices. Bill ----Message 30 is---- Date: Wednesday, 31 Jan 1979 1036-EST From: Ivor Durham at CMU-10A (X335ID20) Subject: Re: Public Pressure. To: [[Response to message 27]] I have not taken 'just the mechanism' attitude. I really believe that the correct, socially conscious (as a computer scientist) decision was made. What is the difference between, releasing this information and telling the world just how much you get paid or pay in taxes, just because this department says we make no monetary distinctions in our support program. Craig captured something of the problem when he said that one must consider the large portion of the community who are very naive users and who barely know how to do more than run RDMAIL and LINED. Should we, the people that hold the strong attitudes about how this place should be run, arbitrarily decide for them what should be done to the system and what information about them shouuld be released? As I said in my reply to 's note, the steady state of the PROFIL bits will bE the same independent of their initial value -- if we spend our energy educating people in what we believe is the right and good way to use this computer system. The decision to remain paranoid covers an entire spectrum -- why is your mailbox protected? Presumably, because you like to exchange personal notes and views which you may not wish to be widely distributed. Some people protect their UFD's for the simple reason that leaving some files open for inspection might encourage people to request new features and hacks for which there is no real time to implement them. The implementation effort for all of the suggestions made so far is minor because I think I have an appropriate structure for gathering all of the information about any user - 1 function call will fill in all of the details about a user given his/her name or PN. Hence work is not an issue at all. Having rambled around a little, let me return to your first paragraph that suggests that I punted the social ramification issue. I thought I had made my opinion quite clear ahead of time. I didn't punt the issue because I'd already drawn my own conclusions. Again, referring to Brian's note, my original scheme was enable all of the bits and then give the world a week to unset them before installing the new finger. The social implications here are not that the decision violates any 'right' of a close knit community, but the rights of the individual. We opted for siding with the individual. Simple as that, I think. I take full responsibility for what I do. Believe me, I wouldn't have gone along with something I didn't believe with issues as potentially great as privacy for the individual. Ivor -------------------- End forwarded message 23-FEB-79 22:59:18-PST,4001;000000000001 Mail-from: SRI-KL rcvd at 23-FEB-79 1006-PST Date: 23 Feb 1979 0958-PST From: McLure at SRI-KL (Stuart McLure Cracraft) Subject: MSGGROUP# 795 Re: The CMU Finger program and privacy ... Subject: an interesting set of messages To: FARBER at USC-ISI, msggroup at USC-ISI, durham at CMU-10A In-reply-to: Your message of 23-Feb-79 0547-PST Redistributed-To: [ISI]Mailing.List;177: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 23 FEB 1979 We here at SRI have had a FINGER program for quite some time now, and with this big bruhaha over CMU'S program and restrictions, I feel compelled to speak forth. Our program has had the default of telling last login, logout, detach, attach, whether the person has mail or not, and who the mail is from if it is local mail. If it is netmail, then it merely tells the site it is from. It will give all this information, even over network fingers. Never has anyone at either of our sites complained about 'privacy' being encroached upon by this program. I am very surprised that an atmosphere such as CMU's would fall prey to the sort of paranoia that is so apparent at many installations that couldn't claim to as much enlightenment in the field. Having a program which tells these things is not an encroachment on privacy. Rather, the entire purpose of the program is to lend a bit more personality to the interaction of computer scientists and users on a time-sharing system. The case of telling whether or not the person has mail (which is certainly no big feat in itself) has always struck me as something of paramount importance to include with the default finger information. Usually one FINGERs someone else to gain information not immediately available through system tables in the monitor, having some sort of daemon do the FINGER database updating. I, for one, would like to know when the person last read their mail, since if I intend to send someone mail I certainly don't want to waste my time if they haven't read theirs for a great deal of time. This can partially be achieved by noting the last login/logout/attach/detach, but not totally. It is necessary to include the feature of last read since that is the only exact way of determining it. As for telling who it is from, I can't imagine why anyone would be so paranoid about it that they couldn't accept the fact that FINGERing someone can also be of help in determining when your mail has gone through. Indeed, our TOPS-20 system has the @INFORMATION MAIL command which, when given a user name as an argument, tells whether that person has mail and who/where it is from. And remember that TOPS-20 systems are noted for the paranoia and 'security' built into them. As for the notion that it puts undue pressure on people, I must only guffaw. Never, in the approximately 2 years that we have run FINGER has anyone that I know of complained about the pressure being exerted on them by some subsystem program that gives out 'too much information'. Remember that all this is the default in our FINGER and there is no way to specify, 'say, I would like to get this person's personal name with FINGER but not information about mail'. They are given it all, including plan information which the person may have left. I hope that our experience will be of help to you in squelching paranoid bureuacrats who insist on stiffling human interaction and free delivery of information on computer systems. I suspect that if your FINGER had originally done all these things by default, no one would have ever complained about them. But of course since many people get so set in their ways that they cannot accept any changes in their lifestyle or mode of operation, we must expect that the vocal minority will speak forth, causing undue lossage to the vast majority who want featureful subsystems for their system. The only solution is to ignore them. ------- 23-FEB-79 22:59:18-PST,3259;000000000000 Mail-from: USC-ISI rcvd at 23-FEB-79 1739-PST Date: 23 FEB 1979 1738-PST Sender: FARBER at USC-ISI Subject: MSGGROUP# 796 A defense of the rights of the individual Subject: [COTTON at NBS-10: FINGER [ok to redistribute, with or with...] From: FARBER at USC-ISI To: [ISI]Mailing.List;177: Message-ID: <[USC-ISI]23-FEB-79 17:38:57.FARBER> This time an editorial comment. BRAVO Ira (even though you are a bureaucrat) Dave (wonder if professors are not bureaucrats in their own right) Begin forwarded message Mail-from: NBS-10 rcvd at 23-FEB-79 1541-PST Date: 23 Feb 1979 (Friday) 1842-Est From: COTTON at NBS-10 To: farber at USC-ISI, ABRAMS, stefferud at USC-ISI Subject: FINGER [ok to redistribute, with or without my name] I was going to ignore the latest flurry of messages on FINGER, but I guess someone has to speak up for the paranoid bureaucrats of the world! We were recently offered a copy of FINGER for our system, and after reading the functional description of the system I raised the privacy issue with Ivor. Whether this inquiry instigated the current controversy I don't know, but I feel the same now as I did then. To me, there is no doubt that FINGER makes available information about individuals that some individuals would prefer not be made available, and that they have a right to expect would not be made available. I note McLure's assertion that FINGER does NOT deal in information that people might consider personal or private, but I fail to find any justification for that assertion other than many reasons why the information might be useful to others. Why should people be able to look into my mailbox. They can be arrested for doing so with my physical mailbox. People don't snoop in my desk out of respect for my privacy and my right to do and organize my work in my own way. Most supervisors hesitate to rummage through a person's desk, even in a rush situation. Are computer systems so different that information should be treated with less respect? We have a capability implemented on our system that permits a message originator to determine if it has been received by the addressee. This is analogous to "return receipt requested." Any more detailed information, or information about mail from anyone else is clearly private information. I certainly agree with the comment made in a previous message that where defaults have to be made, they should be made in the direction of protecting privacy. Finally, I have somewhat of a problem in dealing with the "paranoid bureaucrat" memo without resorting to personal invective myself. The letter seems typical of unthinking technologists who seem to feel that because something CAN be done that it OUGHT to be done, without regard to the social consequences. I simply suggest that anyone who thinks that the right to personal privacy in all aspects of life, and particularly with respect to computer systems, is not a subject of great public concern is just out of touch. As they say, "responsible replies invited." Ira W. Cotton, D.B.A. National Bureau of Standards (undeniably a bureaucrat; hopefully not paranoid) -------------------- End forwarded message 23-FEB-79 22:59:18-PST,3269;000000000001 Mail-from: RAND-UNIX rcvd at 23-FEB-79 1828-PST From: dcrocker at Rand-Unix Date: Fri, 23 Feb 79 18:28-PST To: McLure at SRI-KL cc: msggroup at USC-ISI, durham at CMU-10A Subject: MSGGROUP# 797 Re: #795 The CMU Finger program and privacy ... an interesting set of messages In-reply-to: Your message of 23 Feb 1979 0958-PST. Redistributed-To: [ISI]Mailing.List;177: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 23 FEB 1979 Stuart -- This topic does not lend itself to detached and objective discussion, so... Your reasoning is impressively simplistic and your presumption quite depressing. Simplistic because you blithely assume the absence of vocalized complaints to guarantee the absence of problems and depressing because you assert your point of view as if no alternatives can be tolerated. (Several of the notes in the original series caused me the same reaction, so in a peculiar sense this diatribe isn't (solely) personal, Stuart.) The absence of vocalized problems could be due to many, many factors. Users who care may not be aware of the "feature"; those who use the feature may not, currently, abuse it; and so on. No one complained about the Enemies List, either. Much more serious, to me, is your basis for arguing for open access as the default. Remember that point of view the next time you wonder about your medical, financial activity, and credit records. These all have much more open access than is reasonable, and most people concerned with privacy issues usually claim it is a problem. You want to add to the lack of control. How dare you remove that choice from me. It is not enough to tell me that I can go an change the default. I may not know about the default, in the first case; and why should the burden for providing protection be placed on me? It's none of your business when I last logged or read my mail, UNLESS I WANT TO LET IT BE YOUR BUSINESS. That choice should and must be mine, not a system hacker's or administrator's. I, personally, don't mind people knowing if I'm online now. I'm not too thrilled about their knowing exactly when I last read my mail, tho. In fact, it occurs to me that your logic, carried to its conclusion, would remove file protection and let you read -- oh, what the hell, even modify -- my mail. Absurd? I wonder. If I am wrong about the logical conclusion, then you are admitting that there is, even for as open-minded a person as yourself, some need for privacy (and security). Now that we have agreed on the need for SOME line, we are left only with quibbling about were to place it. In doing this quibbling, it is extremely important to remember that different people have very different preferences; these differences are real and do not reside soley in the hearts of liberals or bureaucrats. We must balance the damage due to privacy violations with the pain (inconvenience) of having to change the defaults. The only competing factor is your "right to know" information about me. Good luck trying that one out on this domain. As to the privacy versus defaults issue, I would much rather be inconvenienced than violated. Dave. 23-FEB-79 22:59:19-PST,2499;000000000001 Mail-from: SRI-KL rcvd at 23-FEB-79 1914-PST Date: 23 Feb 1979 1905-PST From: McLure at SRI-KL (Stuart McLure Cracraft) Subject: MSGGROUP# 798 Re: #795 The CMU Finger program and privacy ... To: dcrocker at RAND-UNIX Cc: msggroup at USC-ISI, durham at CMU-10A In-reply-to: Your message of 23-Feb-79 1830-PST Redistributed-To: [ISI]Mailing.List;177: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 23 FEB 1979 Comparing computer systems with usual real-world life (e.g. slow mail, etc.) is probably unfair. It is my contention that environments where restraints and restrictions are minimal actually turn out to be the most productive. I am not advocating total abandonment of security, just relaxation. Why should I be infringed by a default that doesn't give me the information I want? It goes both ways you know. You can be protective about the information that you have mail from so and so and logged in last at such and such a time, but I certainly don't care about that dispersion at all and I welcome the chance to find out such things about people who aren't presently on the system if there is a reason. For example, suppose you have a colleague who you are working on a project with. How do you expect to find out the current status of that person without a database that contains a reasonable amount of information regarding their last known whereabouts and when they last communicated via mail? To me, the ability to do that is certainly far more important than worrying about possible missuse of the command by randoms. Besides, I have never seen abuse of the Finger command at the sites I've hacked at. Never. How could anyone possibly use that information to do evil? Yes, your point about the logical conclusion of complete access (to valid users (i.e. not allowing randoms to login, of course)) is probably correct. I have not spent an appreciable amount of time on a system where protection is nil, as in the ITS sites, but I suspect that it would not be such a bad affair at all. Certainly the people who currently work under those situations have chosen it for a reason. Complete access eliminates the need for administrative decisions as to who should have access to what. If people spent a little less time worrying about security and protection of systems where the goal is research, then perhaps the environment for work would be a far more productive one. ------- 23-FEB-79 22:59:19-PST,1743;000000000001 Mail-from: NBS-10 rcvd at 23-FEB-79 2111-PST Date: 24 Feb 1979 (Saturday) 0012-Est From: JWALKER at NBS-10 Subject: MSGGROUP# 799 Privacy and the FINGER To: farber at USC-ISI, stefferud at USC-ISI Redistributed-To: [ISI]Mailing.List;177: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 23 FEB 1979 Like Ira, I am a BUREAUcrat. I am going to add two more cents of opinion to the FINGER controversey. I am in full agreement with Ira's position on the subject of personal information. It is a problem of sufficient magnitude that it is of national concern. The issue goes from the somewhat trivial one of my name's being on a mailing list for junk (or other!) mail to one of credit data, background, and so on. How I conduct my affairs (except in the case of certain Civil Serpents) is, or should be, my own business, until such time as it impacts others directly. How much, and which, mail is left on my desk is not a subject for public consumption, and I for one don't like having it distributed without my express permission. Defaults in this regard which automatically divulge personal information are at the least unwise. Unlike Ira, I am definitely paranoid. I have been around big government for sufficiently long to realize that eventually we will all be FINGERed. I'd like to forstall that for as long as possible, and certainly don't want to assist that trend. One tack we, as computer professionals (licensed or unlicensed), can take is to build in at the outset the tradition of really HARMLESS defaults. I'd suggest that we (by which I mean some of you) reexamine our basic duties as professionals, and perhaps take them more seriously. 23-FEB-79 22:59:19-PST,10600;000000000001 Mail-from: MIT-AI rcvd at 23-FEB-79 2121-PST Date: 24 FEB 1979 0017-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP# 800 FINGER: An analysis of the arguments and the issue. To: Cotton at NBS-10, Abrams at NBS-10, Mclure at SRI-KL To: Durham at CMU-10A, Wulf at CMU-10A, Farber at USC-ISI To: Stefferud at USC-ISI, DCrocker at USC-ISI Redistributed-To: [ISI]Mailing.List;177: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 23 FEB 1979 I have just seen many examples of falacious, and sometimes unfair, practices of argument on the subject of FINGER. I would like to analyse them and analyse the issue as well, and then present my opinion. First, here is a quote that I consider a gratuitous insult: The letter seems typical of unthinking technologists who seem to feel that because something CAN be done that it OUGHT to be done, without regard to the social consequences. This is typical of dishonest argumentation. It calls anyone who doesn't consider one particular social consequence, in one particular situation, to be important enough to affect a particular decision, an "unthinking technologist" who has no "regard for social consequences" in general. It thus attempts to deny the very possibility of a reasonable view differing from that of the author of the quote. The fact is that ALL opinions on this question are based on social consequences, as envisioned by the different people. The real seat of the issue is, which consequences are weightier? No matter how you feel about the specific issue at hand (whether the particular social consequence is important enough...) you should condemn the tactics exemplified by this quote. Some people have argued that FINGER should not by default reveal certain information simply because revealing it was a violation of privacy. Here is an example: In questions where personal freedoms, personal privacy, etc. are involved, ALWAYS err on the side of requiring the individual to take positive action. Default on the safe side. Because this line of argument doesn't depend at all on what sort of privacy is being considered, or on what other consequences there are, it is a great oversimplification: all violations of privacy of any nature are lumped together and considered infinitely evil compared to absolutely everything else. I can't actually DISPROVE such a view, of course, but I doubt that the people who implicitly invoked it would own up to it in public. Another example: What is the difference between, releasing this information and telling the world just how much you get paid or pay in taxes, just because this department says we make no monetary distinctions in our support program. The difference is one of consequences and importance, which is what makes all the difference. This view lacks lacks a sense of proportion. (Is it immoral for me to run through a Ladies' room (given that I am male) to evade an armed enemy? Do mandatory tests for Tuberculosis violate privacy?) Speaking about "defending the rights of the individual" is another example of this oversimplification. There are many imaginable rights of the individual which our society (substitute I, you, or any other set of people, ad lib) chooses, on the balance, not to grant, and others which are the centers of great controvercies. I offer that it must be decided separately for each type of information whether it is more important for people to be able to keep it private or for them to be able to find it out, and that neither conclusion can be supported a priori without knowing what information it is and which group of people you are talking about (Is it a research group's machine or a timesharing company's machine?). Just as keeping a secret can be called defending one's privacy, it can also be called being uncooperative with one's co-workers. There. Now the slanted adjectives are balanced. Similarly, DCrocker has just said that Mclure's reasoning, carried to a "logical conclusion", would imply that he ought to have no file protection and anyone ought to be able to read his mail, and then suggests that this is "absurd". (Sorry, no exact quote; that message isn't in my RMAIL yet). This sense of "logical conclusion" has no logical validity, and is only a disguise for throwing away proportion. Any belief can be exagerated enough to become absurd; so what? I actually DO believe that people should be able to read each others' mail, on research systems; but in no way does that follow from my beliefs about the FINGER information. They are two distinct issues, on which I have two distinct opinions (that are similar). There are systems for which I would believe that mail should be private but not last logout time. DCrocker also talks about tax and medical records, as if they were the same issue. Well, they are not; Nobody has presented a real proof that if it is right to reveal a person's last logout time then it is right to reveal his medical records, and until someone can come up with one we should drop the subject of medical records. It is a SIMILAR question, I grant, but all the details are different and there is no reason to expect the answer to be the same. Consider again the mandatory tuberculin tests, here. To talk about keeping secret when you last logged in or out is absurd once you are going to allow people to find out whether you are logged in right now, because they can collect that information themselves if they want to. All they have to do is run programs to check every 10 seconds who is logged in and keep histories. There are some systems which don't let you find out who is logged in. Keeping secret a person's last logout time makes sense on them. I don't think it makes much sense to do one without the other. Whether you have mail is somewhat more reasonable to keep private. I conjecture that keeping private whether one has mail, and from whom, is probably right when it is right to keep the mail private. I was surprised to find out that FINGER at SRI, of all places, provides that information, since ours doesn't, and SRI is generally heavy on security. (I happen to believe that a research computer should have no privacy whatever, since its raison d'etre is to get work done and not to provide people with private places to do their own personal things. It is definitely my experience that privacy interferes with getting work done, when I have to deal with non-ITS systems. On ITS, we have commands explicitly for making it convenient to read someone's mail (of course, there is no protection). They are very heavily used. A lot of work gets done because of them. However, there are situations such as public timesharing services in which I would consider it right to keep mail private, and also whether one has mail and from whom. Some people protect their UFD's for the simple reason that leaving some files open for inspection might encourage people to request new features and hacks for which there is no real time to implement them A lot of work gets done at MIT in exactly that way. As one who is treated in that fashion more than almost anyone else, I think it's a good thing and that those people referred to are unwise and are sabotaging the work of their lab. I have stated these views so you can get an idea of the details of a position which actually says that, in a certain situation, people's desires for privacy SHOULD BE DENIED - so you won't think such a thing is unimaginable). However, the issue that pressure will result if people can tell whether you have mail is a red herring, I can testify. I have felt free to ignore my mail for several days - though it makes a hell of a pile afterward - and the fact that people could tell I was doing so didn't stop me. And here I am a system wizard. If there's anyone who people will want to pressure to do something, it's me. I don't think this phenomenon even exists. That people might be embarrassed if others knew who they had received mail from, I agree will happen, and the question is just whether it is important for them to be safe from such embarrassment. But this pressure problem won't happen. Nor does the fact that one can set the bits mean that everyone will set them the way he wants them: I presume that we all agree that its kind of a trivial point -- trivial in the sense that the important point is that the facility now exists, and that in the steady state people will get their profile bits set to whatever seems right for themselves (at least the regular system users will). Most people won't even know the bits exist. Most of the rest will assume that if the default is not to reveal the information then there must be some terrible, though unobvious, danger in revealing it. Only a few would actually consider changing the settings from the default. The advocates of privacy know this when it suits them (see DCrocker's recent message) but not when it doesn't suit them. One last example of an implicit, controvercial assumption: Thus, even though information about when I last logged in may seem trivial, its not up to us to decide whether that is something that a particular individual wants known. The assumption here is that others are assuming that people won't mind. But what about the alternative belief that such desires for secrecy are petty whims that, even if provided for, don't merit being treated like sacred cows? That if the person omits to take the action to get his whim, it's hardly worth noticing, much less getting alarmed about? The quote implicitly attaches a great deal of importance to whether the individual wants it known or not; but it is reasonable not to consider it the slightest bit important. I do think that the suggestion of making FINGER provide information only to those who themselves make it available is a good one, a truly fine one! It makes those who wish to be private, secretive, and uncooperative get a taste of their own medicine! They may still prefer the privacy, and that's ok, but they will be forced to see both sides of he question - something which many of them now are unwilling to do. And it may succeed in getting those people to whom the privacy is not important to go to the trouble of deciding to set their bits. I do not say what I am not proud of; I wish no privacy for this letter.