7-OCT-79 22:30:06-PDT,5949;000000000001 Date: 2 Oct 1979 0800-PDT Sender: MSGGROUP at USC-ECL Subject: MSGGROUP#1301 [ECL]SURVEY.1251-1300;1 From: MSGGROUP at USC-ECL To: MSGGROUP at USC-ECL Message-ID: <[USC-ECL] 2-Oct-79 08:00:00.MSGGROUP Mail-from: USC-ECL rcvd at 2-Oct-79 0802-PDT Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Survey of messages from file [ECL]MSGGROUP#.1251-1300;1 MSGGROUP#1251 [ECL]SURVEY.1200-1250;1 6057 chars 11 September 1979 02:00-EDT From: MsgGroup at ECL MSGGROUP#1252 Re: [Dcrocker at UDEE: MSGGROUP#1239 MMDF ... 515 chars 11 Sep 1979 0321-PDT From: SDSAN-DMS at SRI-KA MSGGROUP#1253 Communications, Color & Games 1265 chars 11 SEP 1979 0620-PDT From: JMCHUGH MSGGROUP#1254 line widths 1933 chars 11 September 1979 1143-EDT From: Brian.Reid at CMU-10D (A800 MSGGROUP#1255 Sender control of Message Display Format 1007 chars 11 Sep 79 13:07-EDT (Tue) From: Dcrocker at UDel-EE MSGGROUP#1256 Re: line widths 1336 chars 11 Sep 1979 1400-EDT From: MOOERS at BBN-TENEXA MSGGROUP#1257 Re: Sender control of Message Display Format 781 chars 11 Sep 1979 1234-PDT From: Zellich at OFFICE-1 MSGGROUP#1258 Re: Sender control of Message Display Format 531 chars 11 September 1979 1726-EDT From: Richard H. Gumpertz MSGGROUP#1295 Ambiguous letters and operators 1154 chars 1 Oct 1979 02:15-EDT From: Richard M. Stallman In-Reply-To: Your message of 2 Oct 1979 0522-PDT Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 1. Delayed sending. I agree that time stamps should be accurate, that is, they should show the time that the message was actually sent. However, it should be possible to delay sending messages -- that would be extremely valuable for reminders, calendar functions, and such. The value of such a function has been recognized for a long time, and, as you say, people who work with one or another sophisticated system can send delayed messages now, even if it takes a bit of finageling. 2. Arbitrary time stamps. If we could send messages with totally arbitrary time stamps we might as well not have them at all. For the purpose of getting one's boss's boss's boss to take one's ravings seriously, one might try to delay actually sending the message, one way or another, and remember what William Blake said: The truth that's told with bad intent Beats all the lies you can invent. On the TENEX/TOPS-20 where I work, the time stamp is placed on the message by the program that delivers the message, as well as by the program that prepares and sends it. Sometimes the two programs are the same -- more often they are not. Delayed messages could be implemented to show the actual time that the message was sent (via delayed send) as well as the received date. Or it could show the time that the delayed send was executed. Or both. 3. No time stamp. This is certainly a reasonable option. Many applications of the Hermes message system are really database applications, and in those situations, the time stamp, sender, and message-ID fields are simply superfluous. However, when you really send a message to someone else, you are using a privileged process to place your text in computer storage that you normally have no access to. A time stamp seems to be a reasonable requirement in the circumstances. ---Charlotte 7-OCT-79 22:30:06-PDT,1849;000000000001 Mail-from: MIT-ML rcvd at 2-Oct-79 0816-PDT Date: 2 Oct 1979 10:37 edt From: Pogran.CompNet at MIT-Multics Subject: MSGGROUP#1303 Re: Time stamps To: MsgGroup at MIT-ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I think Charlotte's points are very good. There is another situation in which time stamps are invaluable: In an ongoing discussion (like this one), where people are responding to each other's messages, I have no guarantee that the order in which messages appear in my mailbox is the logical order in which the messages were written. The vagaries of the network mail system (mailer daemons, the up/down state of my host, a sender's host, etc.) virutally ensure that some messages will be received by me out of sequence. And they may not make sense, unless I can look at their time stamps and thus determine their proper order. Of course, we could route all such traffic through Stef to receive an official MsgGroup number; then all recipients could order the messages by MsgGroup number. But then, Stef would have to have some way of assigning number is the correct order ... This is but one example. We need some way of determining, unequivocally the correct order of a sequence of messages. I don't know of a better way than by using time stamps. Note that I am not suggesting that we legislate that all messages MUST have time stamps; I think messages should have them, by default, though perhaps a sender should be able to request that his/her message be dispatched without one. But as Charlotte notes in her last paragraph, the sender can do nothing to prevent the receiving host's mail daemon from time-stamping the delivery of a message into a recipient's mailbox. And I believe that is as it should be. Ken Pogran 7-OCT-79 22:30:07-PDT,722;000000000001 Mail-from: MIT-ML rcvd at 2-Oct-79 0945-PDT Date: 2 OCT 1979 0928-PDT Sender: STOTZ at USC-ISIB Subject: MSGGROUP#1304 Time Stamps From: STOTZ at USC-ISIB To: msggroup at MIT-ML Cc: stotz Message-ID: <[USC-ISIB] 2-OCT-79 09:28:12.STOTZ> Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 In the world of military communications the time stamp serves the very important function of a message identifier (in combination with the sender's name). To provide uniformity the time stamps (called Date Time Group) are given in Greenwich Mean Time. If you do not provide a time stamp, how do you propose to provide a unique message identifier? Rob Stotz 7-OCT-79 22:30:07-PDT,637;000000000001 Mail-from: MIT-ML rcvd at 2-Oct-79 1106-PDT Date: 2 October 1979 1302-EDT (Tuesday) From: Richard H. Gumpertz Subject: MSGGROUP#1305 Re: Time Stamps To: STOTZ at USC-ISIB CC: msggroup at MIT-ML Message-ID: <02Oct79 130239 RG02@CMU-10A> In-Reply-To: <[USC-ISIB] 2-OCT-79 09:28:12.STOTZ> Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Your message already had a unique message identifier -- the Message-ID I referenced in my header. I agree that the time stamp should be kept, but unique-id does not seem a good reason for it. Rick 7-OCT-79 22:30:07-PDT,624;000000000001 Mail-from: MIT-ML rcvd at 2-Oct-79 1057-PDT Date: 2 Oct 1979 1039-PDT Sender: SDSAN-DMS at SRI-KA Subject: MSGGROUP#1306 Re: Time stamps From: SDSAN-DMS at SRI-KA To: Zellich at OFFICE-1 Cc: SIRBU at MIT-MC, Msggroup at MIT-ML, Verplank at PARC-MAXC Message-ID: <[SRI-KA] 2-Oct-79 10:39:19.SDSAN-DMS> In-Reply-To: Your message of 2 Oct 1979 0522-PDT Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I agree with Rich Zellich...even though mailer on many systems sends the last message queued first and the time stamp is not always meaningful. Tom 7-OCT-79 22:30:07-PDT,1526;000000000001 Mail-from: MIT-ML rcvd at 2-Oct-79 1131-PDT Date: 2 Oct 1979 11:02 am (Tuesday) From: AHenderson at PARC-MAXC Subject: MSGGROUP#1307 Re: Time stamps To: MOOERS at BBN-TENEXA cc: Zellich at OFFICE-1, SIRBU at MIT-MC, Msggroup at MIT-ML, Verplank Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Seems to me there are a number of times which may be of interest to a person receiving a message: 1. The time written: 'taint necessarily the time sent; I often slepp on an important message, but want to record when I originally wrote it - helps with the time sequencing - what had I seen when I thought these thoughts. Sometimes it is even "the timeS written" - in that it stretches out over interruptions. 2. The time when some message system inserted it into the delivery system. (I think this is the accepted meaning of the current DATE field.) 3. The time when the delivery system placed it in my inbox. (I think this is the TENEX/TOPS-20 header line time stamp.) 4. The time(s) when I looked at it. (This is sometimes the meaning of the rubber stamps which people use in their own offices, although I think those are often used by secretaries to mark type-3 time). 5. The times when I modify it (make additions to it). (Does HERMES associate time stamps with COMMENT fields?) 6. Etc.??? There are authentication and social impact issues with all of these times. Conclusion: This may be an interesting subject. Austin 7-OCT-79 22:30:07-PDT,1543;000000000001 Mail-from: MIT-ML rcvd at 2-Oct-79 1236-PDT Date: 2 Oct 1979 1507-EDT Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP#1308 Re: Time stamps From: MOOERS at BBN-TENEXA To: AHenderson at PARC-MAXC Cc: Zellich at OFFICE-1, SIRBU at MIT-MC, Msggroup at MIT-ML, Cc: Verplank at PARC-MAXC, Mooers Message-ID: <[BBN-TENEXA] 2-Oct-79 15:07:17.MOOERS> In-Reply-To: Your message of 2 Oct 1979 11:02 am (Tuesday) Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Hermes does associate time stamps and authors with comments. See the [Text] field of this message. When we first implemented the REFILE command, we rewrote the Date: field every time a message was edited and refiled. People objected, quite rightly, to losing the original date of messages that they had edited or commented on. To rectify that, we implemented a COMMENT command which simply adds a [Text] field wihtout changing the message -- that was fine. We then changed the REFILE command to NOT change the date and sender of the original message. It turns out that some people want that function, and others want a record of the last time that the message was edited. Having a message-equivalent of the READ DATE on a TENEX/TOPS-20 file would be useful sometimes, too, I agree. ---Charlotte P.S. The last times I or someone else at BBNA has sent a message to the addressees on this message, I have received TWO copies from MIT-ML. I wonder if this will happen again? And if so, why? 7-OCT-79 22:30:07-PDT,654;000000000001 Mail-from: MIT-ML rcvd at 2-Oct-79 1326-PDT Date: 2 Oct 1979 1546-EDT Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP#1309 Re: Time stamps From: MOOERS at BBN-TENEXA To: AHenderson at PARC-MAXC Cc: Zellich at OFFICE-1, SIRBU at MIT-MC, Msggroup at MIT-ML, Cc: Verplank at PARC-MAXC, Mooers Message-ID: <[BBN-TENEXA] 2-Oct-79 15:46:43.MOOERS> In-Reply-To: Your message of 2 Oct 1979 11:02 am (Tuesday) [Text]: Note by MOOERS on 2 Oct 1979 1544-EDT [Text]: [Text]: And here is it. Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Oops, I forgot the comment field. ---Charlotte 7-OCT-79 22:30:07-PDT,1657;000000000001 Mail-from: MIT-ML rcvd at 2-Oct-79 1359-PDT Date: 2 Oct 1979 1326-PDT Sender: GOODWIN at USC-ISI Subject: MSGGROUP#1310 Re: Time Stamps From: GOODWIN at USC-ISI To: Rick.Gumpertz at CMU-10A Cc: STOTZ at USC-ISIB, msggroup at MIT-ML Message-ID: <[USC-ISI] 2-Oct-79 13:26:45.GOODWIN> In-Reply-To: <02Oct79 130239 RG02@CMU-10A> Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 The message IDs and references I see in Hermes look a lot like the reference Rob described - an originator and a date time group. Using a GMT based ID also makes sense for communications that commonly cross time zones. I find myself having to notice the time zone and translate times to some common zone on those occasions when I care about the relative times of message creation or arrival. [Since I live in the Eastern time zone, use a message system located in - and time stamping things in - the Pacific time zone, and often have communicated with folks who are on Hawaiian Standard Time all year long, I have become adept at these translations.] As Rob said, in military communications the message originator-DTG is a critical message identifier. It is presently the basis on which messages are stored and retrieved in central message files (which, incidently, may initially be paper files, later transferred to microfilm when the messages exceed certain ages.) Because the originator-DTG is used for purposes of identification, it sometimes happens that for outgoing messages the DTG is deliberately changed slightly from the actual time,to ensure providing a unique identifier. 7-OCT-79 22:30:07-PDT,1644;000000000001 Mail-from: MIT-ML rcvd at 2-Oct-79 2247-PDT Date: 2 Oct 1979 1643-PDT From: FINN at USC-ISIE Subject: MSGGROUP#1311 Re: Time stamps To: AHenderson at PARC-MAXC cc: FINN, Msggroup at MIT-ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 In response to your message sent 2 Oct 1979 11:02 am (Tuesday) This recent discussion of unique ID's, data-time stamps and the like has been a subject of some study by the International Standards Organization. The reports in question are ISO-3307 "Information Interchange -- Representations of the time of day" and ISO-4031 "Information Interchange -- Representation of local time differentials". This is the representation we chose in the Internet message system (see RFC:753, IEN:85 - Internet Message Protocol). Although some would argue that it looks 'ugly', it does contain all the necessary information. It is important to remember that this is designed to transfer time information from machine to machine. How it is presented locally to a user is up to the interfacing programs and their designers. An example of the standard would be the time now, as I write this: 1979-10-02-15:19:00-08:00 Here the -08:00 denotes the difference locally from GMT. The general direction, left-to-right, is least-to-most specific. More precise timing information is indicated by suffixing .xxxx as a part of a second to the :YY minutes portion. That is variable length and can be extended as needed or be eliminated entirely if so desired. -- ggf ------- 7-OCT-79 22:30:07-PDT,1287;000000000001 Mail-from: USC-ISIB rcvd at 2-Oct-79 2202-PDT Date: 2 OCT 1979 2108-PDT From: POSTEL at USC-ISIB Subject: MSGGROUP#1312 New RFCs Available To: [ISIE]Request-for-Comments.List: Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Three new RFCs are now available in the NIC online library at SRI-KL. RFC 756 Title: The NIC Name Server -- A Datagram Based Information Utility Author: John Pickens, Elizabeth Feinler, and James Mathis Pages: 12 pathname: RFC756.TXT RFC 757 Title: A Suggested Solution to the Naming, Addressing, and Delivery Problem for ARPANET Message Systems Author: Debra Deutsch Pages: 20 pathname: RFC755.TXT RFC 758 Title: Assigned Numbers Author: Jon Postel Pages: 12 pathname: RFC755.TXT These 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. ------- 7-OCT-79 22:30:07-PDT,4885;000000000001 Mail-from: SU-AI rcvd at 3-Oct-79 0449-PDT Date: 02 Oct 1979 2230-PDT From: Geoff Goodfellow Subject: MSGGROUP#1313 Privacy Safeguards to Congress. To: "@MAILST.6[G,GFF]" at SU-AI Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 n093 1913 02 Oct 79 AM-PRIVACY Administration's Proposals on Privacy Safeguards Sent to Congress By DAVID BURNHAM c. 1979 N.Y. Times News Service WASHINGTON - The Carter administration sent to Congress on Tuesday legislative proposals aimed at increasing privacy safeguards for millions of Americans holding insurance policies or using credit cards. Several national authorities on privacy law and congressional critics, however, have joined in charging that the administration's separate bill specifying the investigative powers of the Federal Bureau of Investigation would undermine the broad effort of the last few years to develop clear controls over government agencies' access to the private records of American citizens. The new privacy proposals dealing with insurance companies, credit card companies and institutions involved in the electronic transfer of financial information were strongly endorsed by Commerce Secretary Juanita M. Kreps and Esther Peterson, President Carter's consumer adviser. Mrs. Kreps, the co-chairman of an administration committee established two years ago to develop a unified privacy policy, discussed the latest proposals in a news conference Tuesday and an earlier interview. Among the new proposals, she said, were the following: - Insurance companies would be required to inform prospective policyholders of what information about them would be collected; to give policyholders the right to see and, if necessary, correct information in their files, and to inform individuals of the reasons for adverse decisions about them, such as denial of coverage or raised premiums. - Credit card and check authorization companies would be required to inform their customers of the kinds of personal information collected and would give individuals the right to challenge a request for disclosure of the records when the request was made in the course of a civil suit. - Disclosure of ''electronic funds transfers'' could be made to a government agency only after it had obtained a court order. Those are transactions in which the computer in a customer's bank is instructed to transfer a credit to the computer in the seller's bank. ''Not to be overly dramatic about it, but we live in an information fishbowl,'' said Mrs. Kreps. ''Many public and private groups, such as banks, credit card companies and the Social Security Administration, have records in their files in which a great deal of our private lives can be revealed.'' Among the critics of the government's approach on privacy are David F. Linowes, a professor at the University of Illinois and former chairman of the Privacy Protection Commission, an advisory body established by Congress in 1974; Ronald L. Plesser, a Washington lawyer and former general counsel of the commission; and congressmen such as Rep. Stewart B. McKinney, R-Conn. They have said in interviews and Senate testimony that the administration's bill establishing a charter for the FBI represents a serious threat to individual privacy. The legislative drive of the last few years to improve individuals' privacy protection has involved several goals. A law passed last year, for example, established the legal presumption that bank records are the private property of customers and that all federal law-enforcement agencies, including the FBI, could examine them only after the individual had been notified. Individuals could then challenge in court the request for information. The FBI charter, however, would establish a new set of legal procedures when the bureau wanted to examine insurance files, credit card records and telephone logs. Critics of the charter charge that the standards for acquiring such categories of information are much less rigorous than those the bureau must meet when it seeks bank records. John Hotis, an FBI inspector and special assistant to the director, William H. Webster, denied that the charter provision on access to records would weaken privacy safeguards. ''The charter would establish safeguards for insurance and telephone records that are comparable to those for bank records,'' he said. Among the charter provisions criticized by Plesser was one that he said would permit the bureau to share personal information it collected with other investigative bodies and another that would allow it to search an individual's insurance, credit card and telephone records without informing him. ny-1002 2212edt *************** 7-OCT-79 22:30:07-PDT,700;000000000001 Mail-from: MIT-ML rcvd at 3-Oct-79 1015-PDT Date: 3 October 1979 1203-EDT (Wednesday) From: Richard H. Gumpertz Subject: MSGGROUP#1314 Re: Time stamps To: FINN at USC-ISIE CC: MsgGroup at MIT-ML Message-ID: <03Oct79 120313 RG02@CMU-10A> In-Reply-To: FINN's message of 2 Oct 79 18:43-EST Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Interesting that ANSI and ISO can't get together on such a thing. ANSI standard for time zone reresentation is different. Also no punctuation in ANSI dates. I suppose that is typical -- what fun are standards if one can't go off and create one's own? Rick 7-OCT-79 22:30:08-PDT,2976;000000000001 Mail-From: MIT-ML rcvd at 7-Oct-79 2129-PDT Date: 7 Oct 1979 2106-PDT Sender: GEOFF at SRI-KA Subject: MSGGROUP#1315 Two TV programs of note From: the tty of Geoffrey S. Goodfellow To: MSGGROUP at ML Message-ID: <[SRI-KA] 7-Oct-79 21:06:55.GEOFF> Reply-to: Geoff @ SRI-KA Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Although these really don't deal directly with Message systems, they do deal with the social and techonolgical implications behind them, and hence worthy of a note to MSGGROUPers. Begin forwarded messages =========================== From: LARKE@MIT-ML Date: 10/07/79 23:11:10 Subject: "CONNECTIONS" LARKE@MIT-ML 10/07/79 23:11:10 Re: "CONNECTIONS" THIS MESSAGE DEALS WITH A TV SHOW THAT TAKES SCIENCE ITSELF (INVENTIONEERING) AND PUTS IT IN A FASCINATING NEW LIGHT. ITS CALLED "CONNECTIONS"; ITS ON PBS, AND ITS QUITE SPECTACULAR. NATURALLY, THE SHOW COMES TO US FROM THE BBC. ALL GOOD PBS SHOWS DO SO. THIS TEN PART SERIES TAKES SOME INVENTION EACH SHOW AS A STARTING POINT (FOR EXAMPLE, THE INVENTION OF MONEY), AND WINDS ITS WAY THROUGH A SERIES OF RELATED - BUT SOMETIMES JUST BARELY - SCIENTIFIC DISCOVERIES AND EVENTS (TRIANGULAR SAILS, THE COMPASS,ELECTRICITY, CLOUDS, AND CLOUD CHAMBERS) AND FINALLY WINDS UP AT SOME MODERN INVENTION LIKE THE ATOMIC BOMB, WHICH , FROM AA LONG AND WINDING ROAD HAS BEEN LINKED TO THE INVENTION OF COINAGE. IF IT SOUNDS DRY, PERISH THE THOUGHT. ITS ENLIVENED BY DETAILED RECREATIONS AND REENACTMENTS, AND LIBERAL DOSES OF HUMOR. THE ONLY BORING SEGMENT IS THE AMERICAN- PRODUCED DISCUSSION OF THE TOPIC WHICH FOLLOWS EACH SHOW. FOR ANYONE WITH A CURIOUS NATURE: ANYONE WITH AN INTEREST IN INVENTIONS, OR HISTORY: ANYONE BOREDOF DREK THAT THE COMMERCIAL NETWORKS FEED US; BE SURE YOU MAKE "CONNECTIONS" PART OF YOUR TV SCHEDULE. =========================== =========================== Date: 7 Oct 1979 2029-PDT From: Stuart McLure Cracraft Subject: 'Fast Forward' 'Fast Forward' is also highly recommended. It's a Canadian production which traces computer technology from its birth on through the present and into the future. The emphasis is on impact on society and how computer technology will saturate every avenue of modern day society. The first showed explained the aims of the series and demoed various things including one of the high resolution color raster displays someone hacked up at MIT for a thesis to paint things with. The second talked about other things including networks, and had a description of the Arpanet with implications for future networking for the masses. A demo of Zork by Fredkin was included for the games fanatics. Descriptions of these are provided by visiting experts including prof's from various places, Bell labs researches, etc. ------- =========================== End forwarded messages 11-OCT-79 13:56:58-PDT,631;000000000001 Mail-from: MIT-ML rcvd at 8-Oct-79 0644-PDT Date: 8 Oct 1979 at 0830-CDT From: david at UTEXAS Subject: MSGGROUP#1316 Oct 79 IEEE Spectrum To: msggroup at mit-ml,info-micro at mit-ai,home-sat at mit-ai Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 A "must see" issue for anyone with an interest in computers or communications: the October 1979 issue of "IEEE Spectrum", a special issue on "Communications: onward to the 80s". Major sections on satellite communications, data comm, consumer telephone, home/office comm, and component technology. ------- 11-OCT-79 13:56:58-PDT,2803;000000000001 Mail-from: MIT-ML rcvd at 8-Oct-79 1712-PDT Date: 8 OCT 1979 1634-PDT Sender: MSGGROUP at USC-ECL Subject: MSGGROUP#1317 EDUNET: A view Toward File Transfer From: ESTEFFERUD at USC-ECL To: MsgGroup at MIT-ML Message-ID: <[USC-ECL] 8-OCT-79 16:34:00.MSGGROUP> Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Excerpts from EDUNET NEWS, Number 13, Fall 1979 From page 1 - "From the Executive Director: A VIEW TOWARD FILE TRANSFER" "Currently there is no generally accepted procedure for transferring data files from one computer to another using a communications network such as TELENET or TYMNET. If such a file transfer procedure were available, reliable, convenient, and economical, we would almost certainly find dramatic growth in the use of such network services as electronic mail, remote job entry, and transfer of more traditional alphanumeric files. Since its beginning, EDUNET has received many requests for this capability. "According to current TELENET and TYMNET tariffs, file transfer is already economically viable. Considering variable charges only (for packets or for characters) a one million character file - equivalent to 12,500 punched cards - could be transferred for a cost of $3.91 on TELENET or $30.00 on TYMNET. A three hundred word electronic mail message could be transferred on TELENET for less than a penny. Since these costs are sufficiently attractive, we should begin to look at what is required to make file transfer available. "Groups developing national and international standards (e.g., X.25) are not likely to develop a standard for file transfer for at least two and perhaps as long as five years. If we choose not to wait, we in EDUNET can agree on a standard. Several file transfer procedures are already in use (e..g., FTP on ARPAnet), so we would not need to start from scratch; and developing such a capability is probably possible in the EDUNET community. The host computers involved would require a good connection to the network and would need to be willing to make a modest investment in software development. "The first step is to find out the degree of interest among network participants. Those interested in pursuing it further should contact me directly. Hopefully, we can form an ad hoc group to prepare the way." Signed: Paul S. Heller, Executive Director, EDUNET Excerpt From page 7 - "EDUNET, an activity of EDUCOM, is a national computing network for higher education and research. The EDUNET NEWS is a quarterly publication of EDUNET. It is distributed free of charge to EDUNET members and to other interested individuals." You may write to: EDUNET, P.O. Box 364, Princeton, NJ 08540 11-OCT-79 13:56:58-PDT,1146;000000000001 Mail-from: MIT-ML rcvd at 9-Oct-79 0913-PDT Date: 9 Oct 1979 0852-PDT From: Yeager at SUMEX-AIM Subject: MSGGROUP#1318 TTYFTP... To: esteffrud at USC-ECL cc: msggroup at MIT-ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 In reference to your message concerning file transfer and EDUNET, we HAVE such a program, TTYFTP, which does packeted, checksummed, etc.., file transfers on ANY line with compatible modems at either end. Currently, we can transfer files on TYMNET between ourselves, and Rutgers, on a phone line between ourselves and UC Santa Cruz, and on a 2400 BUAD line between ourselves and our own 2020, ie, our PDP10 <---> our DEC2020. It is written in MAINSAIL, a machine independent language developed here at SUMEX, and, is up on the following operating systems: TENEX, TOPS20 version 1 - version 3, RT11, and RSX11-M. So, anyone who wishes to have such a program, and has one of the above operating systems should contact me. Bill PS. The UC Santa Cruz <--> SUMEX has TTYFTP under RT11 <--> TENEX. ------- 11-OCT-79 13:56:58-PDT,720;000000000001 Mail-from: MIT-ML rcvd at 11-Oct-79 1127-PDT Date: 11 Oct 1979 1100-PDT Sender: FARBER at SRI-KA Subject: MSGGROUP#1319 Re: EDUNET: A view Toward File Transfer From: FARBER at SRI-KA To: ESTEFFERUD at USC-ECL Cc: MsgGroup at MIT-ML Message-ID: <[SRI-KA]11-Oct-79 11:00:20.FARBER> In-Reply-To: <[USC-ECL] 8-OCT-79 16:34:00.MSGGROUP> Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Stef, I noticed that both the apple and the radio shack "home computers" offer a ftp server (they would not think of it as that). I assume they are programmed in Basic and thus would be usable on any system with a basic implementation. Dave 19-OCT-79 16:29:29-PDT,1107;000000000001 Mail-From: MIT-ML rcvd at 11-Oct-79 2118-PDT Date: 11 October 1979 23:30 edt From: Frankston.Frankston at MIT-Multics Subject: MSGGROUP#1320 Re: EDUNET: A view Toward File Transfer To: FARBER at SRI-KA cc: ESTEFFERUD at USC-ECL, MsgGroup at MIT-ML In-Reply-To: Msg of 10/11/79 14:00 from FARBER Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Dave, Please elaborate by what you mean when you so that you nitce that both Apple and Radio Shack have ftp servers. I know that the APple has a simple block data transfer scheme. Dunno about the radio shack. Calling them FTP servers is streching things quite a bit. I very much doubt they are in basic since the basics on both machines are too slow to even sustain 30 cps. Especially on the Apple which does almost all (at least all manufacturer-supplied) I/O without interrupts -- often with a bit banger. I have heard rumors, though about the existance of software to interface some of these machines to more stnadard time sharing systems but haven't persued them yet. 119-OCT-79 16:29:30-PDT,719;000000000001 Mail-From: MIT-ML rcvd at 11-Oct-79 2200-PDT Date: 11 October 1979 21:39-PDT (Thursday) From: Frank J. Wancho To: MsgGroup at MIT-ML Subject: MSGGROUP#1321 EDUNET FTP Comments Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 PCNET protocol notwithstanding, there is TELESTAR for the NorthStar using 256-byte block transfer with checksum (ala Intel's HEX format) - the receiver returns the recomputed checksum when it matches and the transmitter retransmits when that checksum doesn't match what was sent...and IGT used by the TEKTRONIX 4081 to transfer host-computed data to the 4081. (The 4081 is a packaged Interdata 7/16.) 19-OCT-79 16:29:30-PDT,706;000000000001 Mail-From: MIT-MC rcvd at 14-Oct-79 1100-PDT Date: 14 Oct 79 13:41-EDT From: Farber at UDel-EE Reply-to: Farber at Rand-Unix To: msggroup at mit-mc Subject: MSGGROUP#1322 Telephone Network Protocols Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I have noticed a increasing interest in utilizing the telephone network for transmission and access by those in msggroup. I would like to start a discussion on what the different link and FTP protocols are that have been developed for this media, why and how they differ. If persons interested in such a discussion will message me, I will start a mailing list etc. Dave 19-OCT-79 16:29:30-PDT,624;000000000001 Mail-From: MIT-MC rcvd at 14-Oct-79 1128-PDT Date: 14 Oct 1979 1416-EDT From: OFI at BBN-TENEXA Subject: MSGGROUP#1323 Re: Telephone Network Protocols To: Farber at RAND-UNIX, msggroup at MIT-MC Cc: ofi at BBN-TENEXA In-reply-to: Your message of 14-Oct-79 1404-EDT Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Dave: We're working on an interface from a set of word processors, including CPT, Wang and a few others into Network-based electronic mail systems. We'd like to be involved in your mini-conference. Regards, Jim Carlisle ------- 19-OCT-79 16:29:30-PDT,592;000000000001 Mail-From: MIT-MC rcvd at 14-Oct-79 2110-PDT Date: 14 Oct 1979 2358-EDT Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP#1324 Re: Telephone Network Protocols From: MOOERS at BBN-TENEXA To: Farber at UDEL-EE Cc: msggroup at MIT-MC, Mooers Message-ID: <[BBN-TENEXA]14-Oct-79 23:58:19.MOOERS> In-Reply-To: Your message of Sun, 14 Oct 79 13:41-EDT Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Please include me on your list of people interested in the discussion of telephone network portocols. ---Charlotte Mooers 19-OCT-79 16:29:30-PDT,799;000000000001 Mail-From: MIT-ML rcvd at 15-Oct-79 0449-PDT Date: 14 Oct 1979 2218-PDT (Sunday) From: lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1325 CC: CC: CC: CC: CC: ... To: MSGGROUP at ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Please. Must we go through this again? (I feel the flames rising already.) PLEASE...when sending responses to individual solicitations do not include MSGGROUP as a member of the CC: list. It is only slightly less irritating than all these messages I get to general mailing lists that ask to be put on the list (and that is even understandable to a point since people often, unfortunately, have no idea who to contact to be added...) Peace (I hope.) --Lauren-- ------- 19-OCT-79 16:29:30-PDT,669;000000000001 Mail-From: MIT-ML rcvd at 16-Oct-79 0651-PDT Date: 16 Oct 1979 0634-PDT From: LUKASIK at USC-ISI Subject: MSGGROUP#1326 Regulation of Computer Communications To: MsgGroup at MIT-ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I have been requested to give the key note address at the December Computer Networking Workshop at NBS. The topic will be regulation of computer communications. I would be interested to know what questions and concerns you have in this area. your viewpoints would also be welcome. Steve Lukasik reply to: LUKASIK@usc-isi Chief Scientist,FCC ------- 19-OCT-79 16:29:30-PDT,1501;000000000001 Mail-From: MIT-MC rcvd at 17-Oct-79 2030-PDT Date: 17 Oct 1979 2016-PDT From: Almsa at OFFICE-1 Subject: MSGGROUP#1327 Remote Site Work Environment - Request Subject: for Information To: MsgGroup at MIT-MC cc: Mayne at OFFICE-1 Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 We are attempting to develop a conceptual approach for employees, namely programers and system designers, to work at locations remotely located from the "main office" environment. We are trying to locate organizations currently employing people at remote locations using terminals as their primary source of communication and work environment. To date, we have found only one organization employing remote use of personnel. We would appreciate any information relative to this subject, whether it be government, academic community, or industry. John P. Mayne ELITE System Manager Management Information Systems Division USA DARCOM Automated Logistics Management Systems Activity 210 N. 12th St. St. Louis, MO Please address replies to MAYNE@OFFICE-1 This is not exactly a MsgGroup topic, but we are attempting to reach as broad a group with this query as possible. If any of you are aware of other Net-wide distribution groups that would be non-redundant with MsgGroup, we would appreciate it if you would take the trouble to redistribute this message. Thank you, Rich ------- 27-OCT-79 15:18:19-PDT,686;000000000001 Mail-from: MIT-MC rcvd at 24-Oct-79 2243-PDT Date: 24 Oct 1979 2125-PDT From: Glenn Ricart Subject: MSGGROUP#1328 Portable MAIL Systems To: MsgGroup at MIT-MC Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I was recently asked if I knew of mail systems written in a language widely available on different machines...hence portable. The questioner had one of the less common minis. Do people know of relatively full-featured mail systems implemented in BASIC, PASCAL, FORTRAN, MAINSAIL or other widely-available languages? (ARPAnet capabilities not a prerequisite.) . . . . Glenn 27-OCT-79 15:18:20-PDT,699;000000000001 Mail-from: MIT-ML rcvd at 26-Oct-79 1529-PDT From: Gaines at Rand-Unix Date: 26 Oct 1979 at 1503-PDT To: msggroup at Mit-Ml cc: Monroe at Rand-Unix Subject: MSGGROUP#1329 MH Manual Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Rand has developed a message system for UNIX called MH (for Message Handler). A manual has been prepared and will be available shortly. It provides a fairly good description of the system for the non-user who wants to understand what MH is like. Anyone interested please send your name and mailing address to me, and I'll add it to the intial distribution list for the report. Stock Gaines 27-OCT-79 15:18:20-PDT,808;000000000001 Mail-from: MIT-ML rcvd at 26-Oct-79 1644-PDT From: Gaines at Rand-Unix Date: 26 Oct 1979 at 1627-PDT To: msggroup at Mit-Ml Subject: MSGGROUP#1330 more on ordering the MH Manual Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 The printed copy is using good typesetting, and will be much more readable than an on-line copy, so I am not planning on distributing the on-line version. There will be a delay of several weeks while the document goes through a DoD security review, required because the work was sponsored by the Air Force. I need the distribution list now, though. Rand will be distributing the system through the normal UNIX users group distribution, and I will send an announcement when it is ready. Stock Gaines 27-OCT-79 15:18:20-PDT,653;000000000001 Mail-from: MIT-ML rcvd at 27-Oct-79 1123-PDT Date: 27 Oct 1979 1103-PDT Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1331 Re: MH Manual From: STEFFERUD at OFFICE-1 To: Gaines at RAND-UNIX Cc: msggroup at MIT-ML, Monroe at RAND-UNIX Message-ID: <[OFFICE-1]27-Oct-79 11:03:36.STEFFERUD> In-Reply-To: Your message of 26 Oct 1979 at 1503-PDT Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Please send me a copy of the MH Manual, to the following address: Einar Stefferud Network Management Associates, Inc. 17301 Drey Lane Huntington Beach, CA 92647 Thank You - Stef 27-OCT-79 15:18:20-PDT,863;000000000001 Mail-from: MIT-AI rcvd at 27-Oct-79 1131-PDT Date: 27 OCT 1979 1424-EDT From: JNC at MIT-AI (J. Noel Chiappa) Subject: MSGGROUP#1332 Your request for an MH manual... To: stefferud at OFFICE-1 CC: msggroup at MIT-ML Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Goddammit, why do people have to flame about this EVERY TIME IT HAPPENS? DO NOT CC REQUESTS TO MSGGROUP. I don't know what kind of brain-damaged mail reader you are usuing, but it should be possible to avoid deluging me with the inforamtion that "X wants a FOO". I could understand if it hadn't happened before, but since it's already happened N times, I would have thought that people would have remembered. Noel PS My advance apologies for the irritation. Had I waited a while, this ould have been more reasoned.... 27-OCT-79 15:18:20-PDT,899;000000000001 Mail-from: SRI-KA rcvd at 27-Oct-79 1146-PDT Date: 27 Oct 1979 1147-PDT Sender: GEOFF at SRI-KA Subject: MSGGROUP#1333 Re: MH Manual From: the tty of Geoffrey S. Goodfellow To: STEFFERUD at OFFICE-1 Cc: Gaines at RAND-UNIX, msggroup at MIT-ML, Cc: Monroe at RAND-UNIX Message-ID: <[SRI-KA]27-Oct-79 11:47:08.GEOFF> In-Reply-To: <[OFFICE-1]27-Oct-79 11:03:36.STEFFERUD> Reply-to: Geoff @ SRI-KA Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I KNEW IT, I KNEW IT, I KNEW IT... I JUST KNEW SOMEONE WOULD DO IT! I was just mentioning to Mclure yesterday that I wondered who would be the first person to thoughtlessly reply to Stock's MSG and CC the whole MSGGROUP, and reactivate the whole flameage that occurred a month ago when people did likewise... Really now Stef, i thought you knew your HERMES better than that! 27-OCT-79 15:18:20-PDT,556;000000000001 Mail-from: CMU-10A rcvd at 27-Oct-79 1251-PDT Date: 27 October 1979 1548-EDT From: Brian.Reid at CMU-10A Subject: MSGGROUP#1334 UNCLE!!! To: Geoff @ SRI-KA CC: STEFFERUD at OFFICE-1, Gaines at RAND-UNIX, msggroup at MIT-ML, Monroe at RAND-UNIX Message-ID: <27Oct79 154805 BR10@CMU-10A> In-Reply-To: <[SRI-KA]27-Oct-79 11:47:08.GEOFF> Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Please let's just let this whole subject drop. The flames are worse than the original "sin". 28-OCT-79 13:01:31-PST,853;000000000001 Mail-from: MIT-MC rcvd at 28-Oct-79 0757-PST Date: 28 Oct 1979 0740-PST Sender: FARBER at SRI-KA Subject: MSGGROUP#1335 Re: UNCLE!!! From: FARBER at SRI-KA To: Brian.Reid at CMU-10A Bcc: msggroup at MIT-MC Message-ID: <[SRI-KA]28-Oct-79 07:40:00.FARBER> In-Reply-To: <27Oct79 154805 BR10@CMU-10A> Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Just one last word. I almost did the same thing as Stef. My hermes profile is set to include CCs and it is soooo easy to not look. A technique that I use sometimes to avoid such aflood of junk is to BCC the list. That way Hermes and others will not use that list in the reply function. Oh how we do become experts in avaoiding computer quirks. I wonder if a corporation president will be willing to do so. Dave 28-OCT-79 13:01:31-PST,3129;000000000001 Mail-from: MIT-ML rcvd at 28-Oct-79 1149-PST Date: 28 Oct 1979 1114-PST Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1336 Re: UNCLE!!! From: STEFFERUD at OFFICE-1 To: FARBER at SRI-KA Cc: msggroup-at-mit-ml: Message-ID: <[OFFICE-1]28-Oct-79 11:14:45.STEFFERUD> In-Reply-To: <[SRI-KA]28-Oct-79 07:40:00.FARBER> Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 As a central figure in this episode I claim the real last word and with it I want to divert the discussion toward a substantive issue. Seems to me that ettiquette is just another high level protocol, with tolerance for human foibles since it operates at the human communication level. It should be clear that we cannot expect future mutitudes of computer mail system users will accept responsibility for dealing with system designs that provide trap doors to fall through and goblins that jump out to grab the unwary, etc. (As an inverterate gotcha player, I am tempted, but ...) I find that the deeper I sink into concentration on the substance of my work, the more prone I am to being trapped by habit and my lack of intuitive response to HERMES. After using HERMES for 4 years it is still not intuitive for me. This is not true for all HERMES users, but it is true for me, and this should mean something for the design of message handling systems. To me, it means that these systems must have command interfaces that let the users sink into concentration on their work, with intuitive and unconcious response to the message system, whatever that might mean. The universe of users were not given to us to keep our systems busy. Instead, our systems are to be given to the users to get their work done. In specific terms, I think this means that we need to be concerned with the "human interoperability" of our systems in real life human communication situations where they will be used. We need ways to issue requests for private replies that are distributed via broadcast deliveries without forcing every receiver to be wary of the potential for self dishonor. With our current tools, it is a bit like tricking our unwary friends into wetting their pants in public. Dave's suggestion will fill the bill, but in my view it uses a disfunctional design flaw in HERMES BCC features. BBC ettiquette calls for BCC receivers not to disclose their receipt of the message, but our systems make it trivial to err in replying to them. Dave proposes that we take advantage of this flaw to counter other flaws. My concern is that we not deliberately concatenate our design glitches, and hawk them as solutions to the problems of good design. I am certain that Dave agrees with me on this last point. I just want to call attention to the pitfalls afforded by glitch concatenation. Our current systems exist as convoluted hyperplanes cut through multitudes of incompatible complexes. No wonder we have trouble training people to use them in their regular work. Hyperplaning through ARPANET may be fun for us, but ... Peace - Stef 28-OCT-79 13:01:31-PST,904;000000000001 Mail-from: MIT-MC rcvd at 28-Oct-79 1158-PST Date: 28 Oct 1979 1144-PST (Sunday) From: Lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1337 Re: UNCLE!!! In-reply-to: Your message of 28 Oct 1979 0740-PST To: FARBER at SRI-KA CC: MSGGROUP at MC Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 This is being specifically directed to a CC: of Msggroup! As for the corporation president -- I'll bet he/she will be more careful after they see the bill for $50,000 for the one accidental reply to the "United-States-Population" mailing list! One problem (?) we have with the Arpanet message facilites, of course, is that to all intents and purposes (to most users) they are essentially free! --Lauren-- P.S. I am certain that, in the future, this "problem" will be amply dealt with. --LW-- ------- 28-OCT-79 13:01:31-PST,2690;000000000001 Mail-from: MIT-MC rcvd at 28-Oct-79 1227-PST Date: 28 Oct 1979 1151-PST (Sunday) From: Lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1338 Teletext/Viewdata To: MSGGROUP at MC CC: HOME-SAT at AI Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I am considering starting a mailing list for persons interested in the development of Teletext and Viewdata systems. For those unfamiliar with these terms: 1) Teletext is a system for transmitting "magazines" of up to 1000 or more pages, each containing multi-color textual and graphics data, on the "usused" portion of the television vertical interval, right along with normal programming. This data can be news summaries, buying guides, bulletins, anything. One of these systems has been in use in the U.K. for over 4 years under the names CEEFAX and ORACLE. 2) Viewdata is a system for the mass-availability of dial-in data information services. The user typically uses the same teletext decoder as in (1) above, but this time the data comes over the phone in a manner which we are all familiar with. The primary difference is that this a service for EVERYONE, not just computer facility staff and the like. Both of these services display on the home TV screen, in many cases superimposed over regular programming. (For example, in the case of a news bulletin, it would appear in a little box at the bottom of the screen, if the viewer had appropriately enabled his box). There also all sorts of proposed combinations of services, such as a service where you dial a phone number, request a page with Touch Tones, then receive the page over the air as in normal teletext. I have a massive collection of information on these subjects (I am in the process of building a decoder for the British and French standards, both of which are being tested sporadically here in L.A.) For general information, I recommend interested persons obtain the July 1979 edition of the IEEE Transactions on Consumer Electronics, which was totally devoted to these issues. If there is enough interest expressed to me, I'll see about getting a list set up. I strongly feel that within 5 or 6 years, these services will be a VERY important provider of information to the public (especially teletext -- since there will be pressure to build decoders into all new TV's). One company is already using a Teletext system on the vertical interval of WTBS (the CH. 17 superstation from Atlanta broadcast over SATCOM I and available via many cable companies around the country...) --Lauren-- ------- 28-OCT-79 13:01:31-PST,1905;000000000001 Mail-from: MIT-ML rcvd at 28-Oct-79 1237-PST Date: 28 Oct 1979 1513-EST (Sunday) From: Brian.Reid at CMU-10A Subject: MSGGROUP#1339 Re: UNCLE!!! To: STEFFERUD at OFFICE-1 CC: FARBER at SRI-KA, MsgGroup at MIT-ML Message-ID: <28Oct79 151344 BR10@CMU-10A> In-Reply-To: <[OFFICE-1]28-Oct-79 11:14:45.STEFFERUD> Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I don't think that this is a poorly understood problem in user interface design. Lots of people have reached the conclusion that a good human interface to a program should keep the user informed about what the program is doing. Although I don't personally like the idea of defaulting the recipient lists on a reply (the mail I get is sufficiently diverse that no one single default would do), I see nothing wrong with such behavior as long as the program @i[tells the user what it is defaulting!] I'd like to offer up as a counterexample to defaults the way that CMU's RdMail program handles this sorts of things. Instead of defaulting the To: and CC: lists, it constructs from the incoming message a set of "canned" possibilities, each of which has a single-character token. Thus, if I want the reply to go to the To: and Sender: fields, I can type T,S. If I want the reply to go to the To: field and a CC to be sent to everybody else, then I can type A in reponse to the CC prompt, which will cause CC: everybody; the duplicate-elimination algorithm will then remove from the CC list those people already in the TO list. The details really aren't relevant, but by the program's providing a whole set of default recipient-lists with short names and allowing me (forcing me, in fact) to choose which list or lists should receive the message, I avoid this problem. I'm sure you've never seen anybody from CMU accidentally send mail to someone. 4-NOV-79 23:53:21-PST,1098;000000000001 Mail-from: SRI-KL rcvd at 28-Oct-79 1359-PST Date: 28 Oct 1979 1356-PST From: Stuart McLure Cracraft Subject: MSGGROUP#1340 Re: UNCLE!!! To: STEFFERUD at OFFICE-1, FARBER at SRI-KA Cc: msggroup at MIT-ML In-reply-to: Your message of 28-Oct-79 1114-PST Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 A simple solution to this sender/all problem is for the mail program to simply ask 'reply to:' after which the person can specify one of the two alternatives, this being done before each reply unless the person has set a flag to specifically prohibit this. Of course, the question would only be asked if such an alternative of including other people on the to/cc lists existed, e.g. it would not be asked for single person exchanges. Both MM and MSG do it this way. I think it is completely adequate and far less cumbersome than CMU's method. It seems to me that in cases where potentially important alternatives exist for which no good default exists, the software should query the user. ------- 4-NOV-79 23:53:22-PST,1310;000000000001 Mail-from: BBN-TENEXA rcvd at 28-Oct-79 1453-PST Date: 28 Oct 1979 1741-EST Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP#1341 Re: UNCLE!!! From: MOOERS at BBN-TENEXA To: McLure at SRI-KL Cc: STEFFERUD at OFFICE-1, FARBER at SRI-KA, msggroup at MIT-ML, Cc: Mooers Message-ID: <[BBN-TENEXA]28-Oct-79 17:41:14.MOOERS> In-Reply-To: Your message of 28 Oct 1979 1356-PST Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Hermes also has a switch that governs whether replies are sent to names in the To and Cc fields. The REPLY-COPIES switch is can be set to Ask, Yes or No, and the default is always Ask. Stef's point is that either he has set the switch to Yes, or he has developed the habit of always answering Yes to the question. CMU forces the user to think about (and remember) a code that governs the reply function -- maybe it is harder to develop an automatic habit for that. I think Stef is asking for a function that can take a list of people he expects to get mail from and allow him to specify what he wants to have happen for each of them. I'd like that, too. Alternatively, I would like MSGGROUP at MIT-ML to warn the unwary user. That lovely "fan-out" is really a booby trap on occasion. ---Charlotte 4-NOV-79 23:53:22-PST,715;000000000001 Mail-from: MIT-ML rcvd at 28-Oct-79 1548-PST From: JNC@MIT-MC Date: 10/28/79 18:38:40 Subject: MSGGROUP#1342 Handling of Reply.. Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 JNC@MIT-MC 10/28/79 18:38:40 Re: Handling of Reply.. To: msggroup at MIT-ML Charlotte: A list of default actions from user X really isn't what's needed. In the MSGGROUP case, there are cases where you will and won't want the reply to go to MSGGROUP. Something more along the lines of MM is what seems to work best; I always make myself type in ALL the recipients, as a check to make sure they are going to the right places, but I'm a known atavism. Noel 4-NOV-79 23:53:22-PST,1701;000000000001 Mail-from: MIT-ML rcvd at 28-Oct-79 1646-PST Date: 28 October 1979 1930-EST From: Brian.Reid at CMU-10A Subject: MSGGROUP#1343 this sort of discussion To: Frank J. Wancho CC: MsgGroup at MIT-ML Message-ID: <28Oct79 193039 BR10@CMU-10A> In-Reply-To: Frank J. Wancho's message of 28 Oct 79 18:10-EST Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 I think that the human-interface behavior of a message handler is one of the central issues to which MsgGroup ought to be addressing itself. Things that feel like flaming or software nits usually get sent off to Header-People, where we normally wear asbestos underwear. The correct behavior of mail handling programs is, as I see it one of our main concerns. It's really too bad that we have so little experience using each other's systems. I've used RDMAIL, MM, MSG, Hermes, and Laurel, and find that their implied "user models" are subtly but critically different. Some programs put speed above everything (MM), others put class above everything (Laurel), others flexibility and power (Hermes and RdMail). Laurel seems to have the best user interface that I've seen (but naturally: it runs on an Alto) and about the worst functionality; Hermes seems to be the opposite end of the spectrum: it can do anything in the hands of a wizard, but woe betide the novice. It would be great if all of us could get experience at using one anothers' mail systems before deciding what behavior is good and what behavior is not. But we can't, and maybe this flaming back and forth about which programs do what is the best that can be had. Brian 4-NOV-79 23:53:22-PST,821;000000000001 Mail-from: MIT-MC rcvd at 28-Oct-79 1801-PST Date: 28 October 1979 21:01-EDT From: "Marvin A. Sirbu, Jr." Subject: MSGGROUP#1344 Re: UNCLE!!! To: McLure at SRI-KL, MOOERS at BBN-TENEXA cc: msggroup at MIT-ML, STEFFERUD at OFFICE-1, FARBER at SRI-KA Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Perhaps what is needed is a way of automatically distinguishing between persons and mailing lists. Thus if a reply request (or a default) results in all recipients being CC:'d, the system would give the user a special warning or ask for an additional confirmation for the list. If I had to pay for every message I might even want an automatic warning every time a message I proposed to send would generate costs in excess of $XX. 4-NOV-79 23:53:22-PST,1374;000000000001 Mail-from: MIT-ML rcvd at 28-Oct-79 1914-PST Date: 28 Oct 79 21:24-EST (Sun) From: Dcrocker at UDel-EE Reply-to: Dcrocker at Rand-Unix Subject: MSGGROUP#1345 Re: UNCLE!!! To: Brian.Reid at Cmu-10a cc: MsgGroup at Mit-Ml Message-ID: <79300.77057.1540 @ UDel-EE> In-Reply-To: Your message of Sunday, 28 October 1979 1513-EST In-Reply-To: <28Oct79 151344 BR10@CMU-10A> Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Curious thing, Brian. You philosophically called for one type of behavior, but your example was of something quite different -- a very important difference. You called for letting the computer do whatever it does and that will be ok, as long as the user is "informed". In your example, however, you explicity required ACTION from the user. Simply displaying information to the user is hopelessly inadequate as a means of preventing disaster. Users get used to not reading the display. (Forget the issue of their "responsibility" to read the thing; statistically, we habituate stimuli that ON THE AVERAGE contain no useful information -- humans make lousy exception detectors in these sorts of situations.) Your example was, I think, of a much better approach, which is to require the user to give some explicit signal BACK, before processing continues. Dave. 4-NOV-79 23:53:22-PST,589;000000000001 Mail-from: MIT-ML rcvd at 28-Oct-79 1930-PST Date: 28 October 1979 2202-EST From: Brian.Reid at CMU-10A Subject: MSGGROUP#1346 Re: UNCLE!!! To: Dcrocker at Rand-Unix CC: MsgGroup at Mit-Ml Message-ID: <28Oct79 220230 BR10@CMU-10A> In-Reply-To: <79300.77057.1540 @ UDel-EE> Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 CMU's rdmail exhibits the behavior that I believe is best. I guess what I meant was "if you absolutely must default things, for heaven's sake at least tell the user what you are defaulting." 4-NOV-79 23:53:22-PST,1375;000000000001 Mail-from: RAND-UNIX rcvd at 28-Oct-79 1936-PST Date: 28 Oct 79 22:01-EST (Sun) From: Dcrocker at UDel-EE Reply-to: Dcrocker at Rand-Unix Subject: MSGGROUP#1347 Re: UNCLE!!! To: "Marvin A. Sirbu, Jr." cc: McLure at Sri-Kl, MOOERS at Bbn-Tenexa, msggroup at Mit-Ml, cc: STEFFERUD at Office-1, FARBER at Sri-Ka Message-ID: <79300.79293.3600 @ UDel-EE> In-Reply-To: Your message of 28 October 1979 21:01-EDT Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Though it is inadequately distinguished within the syntax, 733 provides a way of making the addressing distinction you propose. If you use groupnames (which derive from the same construct on tenex sndmsg) to encase the mailing list address (whether a single auto-expanding address or a fully-contained list), the user program could flag them. Unfortunately, that won't help accidentally cc'ing to individuals, which certainly can be as dangerous as cc'ing to groups. For example, a co-worker sends me a note, cc'ing our boss. I reply, accidentally including the boss, but include disparaging remarks that preservation of my job dictates I not make known. Well, one approach is to avoid putting in writing (which is what this medium equates to) anything you don't want to see used in a court of law... Dave. 4-NOV-79 23:53:22-PST,945;000000000001 Mail-from: MIT-ML rcvd at 28-Oct-79 2255-PST Date: 29 October 1979 0141-EST From: BZM Subject: MSGGROUP#1348 Moby-CC Confirmations To: "Marvin A. Sirbu, Jr." CC: MsgGroup @ ML Message-ID: <29Oct79 014113 BN30@CMU-10A> In-Reply-To: "Marvin A. Sirbu, Jr."'s message of 28 Oct 79 20:01-EST Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 Laurel does this in several ways. The checks were added because of heavily red-shifted pyrotechnics about exactly this crap. It's not ALWAYS right, but at least the flamethrowers and fire extinguishers have disappeared, although, of course, butane lighters and squirtguns still emerge when "poor" value judgments are made. The high temperatures caused no permanent damage and, in general, the climate at Xerox is once again temper-ate and reason continues to prevail. Bruce 4-NOV-79 23:53:22-PST,1370;000000000001 Mail-from: MIT-ML rcvd at 29-Oct-79 1020-PST From: Gaines at Rand-Unix Date: 29 Oct 1979 at 1003-PST To: msggroup at Mit-Ml SUBJECT: MSGGROUP#1349 automatic replies: the issues are subtle! Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 The issues concerning automatic replying are more subtle than any of the discussants has noticed. In particular, I sent my first message announcing the forthcoming MH manual To: msggroup CC: monroe Jo Ann Monroe is my secretary! Obviously, I wanted her to get replies to this message to do the bookkeeping of preparing the distribution list. After the first few replies came in with NO CC: in them, I sent my second message out without the CC: field. Messy as it sounds, I think some distinction needs to be made between list of addressees, where the name of the list appears in an address field of a header, and names of individuals. Probably message systems will need to be informed of which such lists should not normally be included in the CC: fields of replies, or query the user about them, or some such {very ugly, but pragmatically necessary} scheme. This may be one of those cases where a clean solution will not be found, but practical necessity will force the inclusion of something no one really likes, but everyone needs. 4-NOV-79 23:53:22-PST,858;000000000001 Mail-from: MIT-ML rcvd at 29-Oct-79 1046-PST Date: 29 October 1979 1317-EST From: Brian.Reid at CMU-10A Subject: MSGGROUP#1350 Re: automatic replies: the issues are subtle! To: Gaines at Rand-Unix CC: msggroup at Mit-Ml Reply-To: Brian.Reid at CMU-10A, Scribe (I don't have a secretary) at CMU-10A, RdMail at CMU-10A Message-ID: <29Oct79 131717 BR10@CMU-10A> In-Reply-To: Gaines' message of 29 Oct 79 13:03-EST Redistributed-To: Public at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 30 DEC 1979 This is how I ask for replies to go to persons other than myself. Can your message system handle this automatically? If CMU rdmail is asked to ANSWER this message, it will offer initially to send the reply to the Reply-To list rather than the From list, because of the presence of the Reply-To. 29-OCT-79 12:20:31-PST,5647;000000000001 Date: 29 Oct 1979 at 1203-PST Subject: MSGGROUP#1351 Survey of [ECL]MSGGROUP#.1301-1350 From: EStefferud at USC-ECL To: MSGGROUP at USC-ECL Mail-from: USC-ECL rcvd at 29-Oct-79 1220-PST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Messages in [ECL]MSGGROUP#.1301-1350;1 MSGGROUP#1301 [ECL]SURVEY.1251-1300;1 5844 chars 2 Oct 1979 0800-PDT From: MSGGROUP at USC-ECL MSGGROUP#1302 Re: Time stamps 2382 chars 2 Oct 1979 0934-EDT From: MOOERS at BBN-TENEXA MSGGROUP#1303 Re: Time stamps 1744 chars 2 Oct 1979 10:37 edt From: Pogran.CompNet at MIT-Multics MSGGROUP#1304 Time Stamps 617 chars 2 OCT 1979 0928-PDT From: STOTZ at USC-ISIB MSGGROUP#1305 Re: Time Stamps 532 chars 2 October 1979 1302-EDT (Tuesday) From: Richard H. Gumpertz MSGGROUP#1306 Re: Time stamps 519 chars 2 Oct 1979 1039-PDT From: SDSAN-DMS at SRI-KA MSGGROUP#1307 Re: Time stamps 1421 chars 2 Oct 1979 11:02 am (Tuesday) From: AHenderson at PARC-MAXC MSGGROUP#1308 Re: Time stamps 1438 chars 2 Oct 1979 1507-EDT From: MOOERS at BBN-TENEXA MSGGROUP#1309 Re: Time stamps 549 chars 2 Oct 1979 1546-EDT From: MOOERS at BBN-TENEXA MSGGROUP#1310 Re: Time Stamps 1552 chars 2 Oct 1979 1326-PDT From: GOODWIN at USC-ISI MSGGROUP#1311 Re: Time stamps 1539 chars 2 Oct 1979 1643-PDT From: FINN at USC-ISIE MSGGROUP#1312 New RFCs Available 1182 chars 2 OCT 1979 2108-PDT From: POSTEL at USC-ISIB MSGGROUP#1313 Privacy Safeguards to Congress. 4780 chars 02 Oct 1979 2230-PDT From: Geoff Goodfellow MSGGROUP#1314 Re: Time stamps 595 chars 3 October 1979 1203-EDT (Wednesday) From: Richard H. Gumpert MSGGROUP#1315 Two TV programs of note 2871 chars 7 Oct 1979 2106-PDT From: the tty of Geoffrey S. Goodfellow MSGGROUP#1316 Oct 79 IEEE Spectrum 526 chars 8 Oct 1979 at 0830-CDT From: david at UTEXAS MSGGROUP#1317 EDUNET: A view Toward File Transfer 2698 chars 8 OCT 1979 1634-PDT From: ESTEFFERUD at USC-ECL MSGGROUP#1318 TTYFTP... 1041 chars 9 Oct 1979 0852-PDT From: Yeager at SUMEX-AIM MSGGROUP#1319 Re: EDUNET: A view Toward File Transfer 615 chars 11 Oct 1979 1100-PDT From: FARBER at SRI-KA MSGGROUP#1320 Re: EDUNET: A view Toward File Transfer 1002 chars 11 October 1979 23:30 edt From: Frankston.Frankston at MIT- MSGGROUP#1321 EDUNET FTP Comments 614 chars 11 October 1979 21:39-PDT (Thursday) From: Frank J. Wancho MSGGROUP#1322 Telephone Network Protocols 601 chars 14 Oct 79 13:41-EDT From: Farber at UDel-EE MSGGROUP#1323 Re: Telephone Network Protocols 519 chars 14 Oct 1979 1416-EDT From: OFI at BBN-TENEXA MSGGROUP#1324 Re: Telephone Network Protocols 487 chars 14 Oct 1979 2358-EDT From: MOOERS at BBN-TENEXA MSGGROUP#1325 CC: CC: CC: CC: CC: ... 694 chars 14 Oct 1979 2218-PDT (Sunday) From: lauren at UCLA-Security MSGGROUP#1326 Regulation of Computer Communications 564 chars 16 Oct 1979 0634-PDT From: LUKASIK at USC-ISI MSGGROUP#1327 Remote Site Work Environment - Request for Information 1396 chars 17 Oct 1979 2016-PDT From: Almsa at OFFICE-1 MSGGROUP#1328 Portable MAIL Systems 581 chars 24 Oct 1979 2125-PDT From: Glenn Ricart MSGGROUP#1329 MH Manual 594 chars 26 Oct 1979 at 1503-PDT From: Gaines at Rand-Unix MSGGROUP#1330 more on ordering the MH Manual 703 chars 26 Oct 1979 at 1627-PDT From: Gaines at Rand-Unix MSGGROUP#1331 Re: MH Manual 548 chars 27 Oct 1979 1103-PDT From: STEFFERUD at OFFICE-1 MSGGROUP#1332 Your request for an MH manual... 758 chars 27 OCT 1979 1424-EDT From: JNC at MIT-AI (J. Noel Chiappa) MSGGROUP#1333 Re: MH Manual 794 chars 27 Oct 1979 1147-PDT From: the tty of Geoffrey S. Goodfellow MSGGROUP#1334 UNCLE!!! 451 chars 27 October 1979 1548-EDT From: Brian.Reid at CMU-10A MSGGROUP#1335 Re: UNCLE!!! 748 chars 28 Oct 1979 0740-PST From: FARBER at SRI-KA MSGGROUP#1336 Re: UNCLE!!! 3024 chars 28 Oct 1979 1114-PST From: STEFFERUD at OFFICE-1 MSGGROUP#1337 Re: UNCLE!!! 799 chars 28 Oct 1979 1144-PST (Sunday) From: Lauren at UCLA-Security MSGGROUP#1338 Teletext/Viewdata 2585 chars 28 Oct 1979 1151-PST (Sunday) From: Lauren at UCLA-Security MSGGROUP#1339 Re: UNCLE!!! 1800 chars 28 Oct 1979 1513-EST (Sunday) From: Brian.Reid at CMU-10A MSGGROUP#1340 Re: UNCLE!!! 993 chars 28 Oct 1979 1356-PST From: Stuart McLure Cracraft MSGGROUP#1349 automatic replies: the issues are subtle! 1265 chars 29 Oct 1979 at 1003-PST From: Gaines at Rand-Unix MSGGROUP#1350 Re: automatic replies: the issues are subtle! 753 chars 29 October 1979 1317-EST From: Brian.Reid at CMU-10A 29-OCT-79 14:32:05-PST,502;000000000001 Mail-from: MIT-ML rcvd at 29-Oct-79 1414-PST Date: 29 OCT 1979 1356-PST From: MACKENZIE at USC-ECL Subject: MSGGROUP#1352 Re: UNCLE!!! To: Brian.Reid at CMU-10A cc: msggroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 In response to your message sent Sunday, 28 October 1979 1513-EST I bet you we will. Even more likely now that you've made the challenge. Chuckle, Kevin ------- 29-OCT-79 14:36:27-PST,2719;000000000001 Mail-from: MIT-ML rcvd at 29-Oct-79 1432-PST Date: 29 OCT 1979 1313-PST From: MACKENZIE at USC-ECL Subject: MSGGROUP#1353 Sinking into concentration To: msggroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 It seems to me that you have suggested a possible explanation for RULE #1 of the rules of interactive, non-sophisticated user oriented computer system design. MAKE IT IDIOT PROOF. Sounds easy, right? There are problems though. One, you lose power. Oh yes, I know, a "properly designed system" can be powerful without being complicated. I've heard that a thousand times. Has anyone ever seen one? I would be very interested in hearing about ANY computer system that it is generally agreed is powerful and easy to use for both sophisticated and novice users. I can't think of an example. With the current tools availible, both hardware and software, I think ease of use and power are generally either/or, with some pleasent exceptions. Two, you lose flexibility. Time and time again, I have seen "proper" system designs begun, and near completion, when the inevitable "oops" is found, calling for either redesign (always too expensive) or a sneaky, backdoor, sometimes kludgy solution to a problem not considered in the original design. These are the beginnings of your "non-intuative" problems. It gets worse. The system hits the field, and even if you didn't have any "oops"`s (I want you on my next design team!), there are ALWAYS problems found in the field that must be solved, and QUICKLY. Enter more "non-intuative" fixes. And worse. As a system matures (such as Hermes?), more and more suggestions appear on how to "improve" it, and modification (being cheaper, although a bad solution) is usually picked as the method to implement them. Soon we have a system which bears little resemblence to the "properly designed system" it started out to be. The only solution I see is experience. The more systems of a particular type that are written, the higher the general quality of the systems produced. Batch operating systems for small computers are an example of a product that is nearing perfection due to maturity. They are also obsolete. Perhaps better tools for software/hardware development will appear, shortening the cycle of product development, and giving users a higher level of participation. The field trends in this direction now. Meanwhile, I cry as I watch my "proper" designs bastardized, and put to uses for which they were never intended, all to save money, then criticised for their inadaquacy! Whew. Kevin ------- 30-OCT-79 14:19:43-PST,994;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 0446-PST Date: 30 Oct 1979 at 0614-CST From: david at UTEXAS Subject: MSGGROUP#1354 Reply to: Sinking into concentration To: MACKENZIE at USC-ECL cc: msggroup at mit-ml Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 You expressed interest in hearing about ANY computer system that is generally agreed is powerful and easy to use for both sophis- ticated and novice users. I'd like to suggest the UNIX operating system as an example. The basis for UNIX's simplicity and power is the concept of having simple, well-designed tools that can be combined to form more powerful tools. Once the novice or expert learn the easy and consistent combining rules, they can quickly and easily achieve interesting effects with only a few simple tools. This kind of system design is explained quite well in the book SOFTWARE TOOLS by Kernighan and Plauger. ------- 30-OCT-79 14:19:44-PST,1771;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 0710-PST Date: 30 Oct 1979 0650-PST From: Zellich at OFFICE-1 Subject: MSGGROUP#1355 TRS-80 Mailgram Package Offered To: MsgGroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 From the 15 Oct 79 issue of INFORMATION SYSTEMS NEWS: MAILGRAM PKG. OFFERED Fort Worth, Texas... Radio Shack said that its TRS-80 personal computer and a software package, to be available by December, will allow Mailgrams to be sent directly to distant post offices. Getting into the Mailgram network requires $1200 worth of Radio Shack hardware: a TRS-80 4K Level-II Model I computer, expansion interface, RS-232-C serial interface board and telephone interface. The software package, containing a program on cassette tape, has not been priced yet, but it is expected to run about $50. The package will contain an application form for a Western Union account number. The purchaser applies for the number and then pays a $50 set-up charge to pay for Western Union's bookkeeping. The software package will be called Radio Shack/Western Union Mailgram. Once Installed, the system can send Mailgrams to any post office that has a Mailgram printer. According to Western Union, there is a Mailgram printer within four hours delivery time of any location in the U.S. Overnight delivery is guaranteed. The Mailgram network will be international by the end of this year. Protocols are being established for accessing Telex and TWX networks. ------- 30-OCT-79 14:19:44-PST,3519;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 0905-PST Date: 30 Oct 1979 0735-PST Sender: ROUNDS at OFFICE-1 Subject: MSGGROUP#1356 The use of CC From: William G. Martin To: msggroup at MIT-ML Message-ID: <[OFFICE-1]30-Oct-79 07:35:54.ROUNDS> Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Hi, folks! I'm getting rather confused by some of the discussion regarding automatic CC'ing, because I can't relate the arguments to the way I have found myself using ARPANET mail. I've been doing this stuff since 1976, and primarily use HERMES -- in fact, I even teach it. I have found that all the automatic reply features controlled by switches in Hermes are bad for me; I turn those switches off, and change my reply template (the pattern Hermes follows for prompting me in making a Reply) to send me a copy automatically, address the reply to the sender of the original message, and just prompt me for typing in any CC addressees. As a normal operating practice, why would you WANT to send your reply to the CC addressees? Gaines' use, as described in his recent "issues are subtle" message, is exceptional! Very seldom would you want to direct your reply to anyone other than the sender. If that person wants others to see your message, it is up to him to redistribute it. In the unusual cases, either an explicit user-field, like REPLY-TO, as Brian Reid described, or just putting the instructions in the text -- "Reply to FOO at Host1 and ZIP at Host2" -- will make everything clear. Let's relate this to traditional communications: the vast majority of telephonic or written messages are between one person and another, even if addressed to an organization -- in that case, usually one person is the action officer. The exchange may be presented to someone else after the fact for review or information, at either end, but then it is passed as a file folder, for example. Your boss isn't interested in being bothered by transactions in progress; he wants to know the results -- it's your job to take care of the detail. This is true all up the chain of command. In regard to non-supervisory interaction, if I want to let a colleague know about something, I wait to forward him at least an initial complete exchange -- query and reply. The only times I would CC him on the initial inquiry sent out is if I wanted him to let him know that I already did it, so he wouldn't duplicate the effort. That doesn't mean that I am asking the recipient to reply to him, too -- it's MY responsibility to continue to inform someone if I was the one to start the information flow to them. I have no right to expect someone else to continue something I started, unless I employ them and so direct them. I recognize the concern, and I do share it, that we mustn't allow systems to force excessive retyping of long addressee lists, for example. The machine should do the work, not the operator. But let's use some strict analysis in deciding what should happen automatically, and what options should be the easier ones. The basic reply should permit explicit CC'ing, but only go to the Reply-To field or the Sender, in that sequence. A reply to a CC field should be optional, but not automatic. Let the user specify different kinds of Replies, if they want unusual defaults, like their message to go to the entire group of addressees automatically. Regards, Will Martin 30-OCT-79 14:19:44-PST,2547;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 0931-PST Date: 30 Oct 1979 0957-EST Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP#1357 Re: Handling of Reply.. From: MOOERS at BBN-TENEXA To: JNC at MIT-MC, MSGGROUP at MIT-ML Cc: Mooers Message-ID: <[BBN-TENEXA]30-Oct-79 09:57:30.MOOERS> In-Reply-To: Your message of 10/28/79 18:38:40 Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Your message neatly made sure that the reply would NOT be sent to MSGGROUP, by using a non-ARPAnet To: field. Of course, there are cases where I will or will not want the message to go to MSGGROUP. The point is either to flag potential booby-traps -- like the MSGGROUP fan-out -- and then exclude them from any automatic Cc function, or to make a policy of forcing the user to look at and confirm every Cc. It is easy enough to do either one in Hermes. The second option, never including To and CC names in the reply, is trivial. For the first option, a list of users can be given a "group name", which is never included in a reply message because the actual list of users is not included in the message. That's fine if all the users are on the same system, or a few systems, and a file or message containing the user-list can be duplicated on all the systems and kept up to date. It's not so good in a network situation like MSGGROUP. The MSGGROUP at MIT-ML is a first, crude cut at providing user-list services automatically for all hosts having the ability to send messags to MIT-ML. It is not surprising that it doesn't work perfectly. It isn't really sensible to accuse users of not using the automatic Cc function properly. Instead, we need to look at both the automatic Cc function (which is being done) and the network user-list function (which the people who have commented so far have not really done). The fact is that the automatic Cc function in Hermes and other systems really works very well for many users in most situations. We need something to handle the exceptional situation like MSGGROUP at MIT-ML. Perhaps MSGGROUP at MIT-ML should store an incoming message, and query the sender "If MSGGROUP at MIT-ML redistributes this message to everyone on the MSGGROUP list, it will be sent to 75 people. Please confirm by replying to this message." As has been suggested, the answer may be quite different when the person who sends the message to MSGGROUP has to pay a fee per copy redistributed. ---Charlotte 30-OCT-79 14:19:44-PST,2580;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 1006-PST Date: 30 Oct 1979 0940-PST Sender: GEOFF at SRI-KA Subject: MSGGROUP#1358 Re: The use of CC From: the tty of Geoffrey S. Goodfellow To: ROUNDS at OFFICE-1 Cc: msggroup at MIT-ML Message-ID: <[SRI-KA]30-Oct-79 09:40:40.GEOFF> In-Reply-To: <[OFFICE-1]30-Oct-79 07:35:54.ROUNDS> Reply-to: Geoff @ SRI-KA Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 I take exception to several points in your msg... The in the 3rd paragraph, you state "if a person wants others to see your message, it is up to him to redistribute it" -- i disagree, and i have had my hands slapped on this one in the past (rg02). Namely, when I REPLY to a message, sending ONLY to the SENDER of that message, i do so for a good reason, and if i wanted others to be copied in on my reply I would have included them in. I then think it is your responsibility as the recipient of my (private) message between us to ASK ME if I don't mind that others get a copy of it before sending it out. I think that is basic common courtesy, nothing more. Re: your "traditional communications". They are based on a one-on-one type of communication, where I think of these electronic messages as office memos, where many people are usually copied on one note. Particularly when you are working in small working groups, or trying to coordinate something that involves more than one person; and it is just this type of electronic message sending that makes up about 80% or more of my use of the message system. I also am very conscious of my use of HERMES, and hence have my switches set up my switches accordingly to always send copies to everyone and NEVER ask me any questions about doing so. In the case of Stock Gaines's message, I simply override those defaults by saying: >REPLY, +>NOCOPIES +> and got the desired result. It just takes a little effort on the part of the user, to be a little more consciously aware of what he is doing, and I think CMU's RDMAIL makes this even more so. If someone doesn't think they are that consciously aware, then they should set the REPLY-COPIES switch in HERMES to ASK so they will be asked if they wanted COPIES sent out, and if they just end up typing a YES out of habit, then that is their (bad) habits fault, and they should probably go as far as to set REPLY-COPIES to NO, and then if they want copies sent out, do a >REPLY, +>COPIES +> in HERMES. ------- 30-OCT-79 14:19:44-PST,1854;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 1054-PST Date: 30 Oct 1979 0940-PST From: Larry Campbell Subject: MSGGROUP#1359 Re: The use of CC To: msggroup at MIT-ML, Rounds at OFFICE-1 In-reply-to: Your message of 30-Oct-79 0735-PST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Will: your concern for "controlled" communication between "subordinate" and "superior", and your use of the phrase "chain of command", indicates a military orientation to me. Perhaps what you say is true in highly structured bureaucracies, such as the military, but it is definitely not true in other environments. The best example of this is the environment I worked in up until a few weeks ago: a small (10 people) operating system development group at a large computer vendor. We frequently engaged in what we called "mail wars" over particular issues which cropped up from time to time. They usually went something like this: someone would want to make a change, or add a feature. He would send mail to the entire group, describing the change, and asking for comments. Each person would reply to the entire address list; that way, everyone sees the entire discussion and gets a wider range of opinions to reflect on. Frequently someone would have an objection to the original proposal, which a third person would be able to refute. If the objector's reply only went to the sender of the note, the third person would never get the chance to refute the objection. Occasionally these mail wars got out of hand, just as Msggroup has in the past, but we all felt that the benefits of this type of roundtable discussion far outweighed the disadvantages. Petty mail wars were generally halted or limited by social pressure. ------- 30-OCT-79 14:19:44-PST,3732;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 1222-PST Date: 30 Oct 1979 1152-PST Sender: ROUNDS at OFFICE-1 Subject: MSGGROUP#1360 More re CC From: William G. Martin To: msggroup at MIT-ML Message-ID: <[OFFICE-1]30-Oct-79 11:52:25.ROUNDS> Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Once more into the breach... I think that what we are seeing here is another example of the classic user-designer dichotomy. (It's amazed me how much of this I have seen, in person and at some remove, among a community which talks so constantly about fulfilling the USERS' needs above all else...) First of all, let's remember who is paying for all this development of message systems, and who is going to be using it when it is a really viable and implemented thing. Right now, the user population is skewed to a very un-natural sample; the majority (including me) are people oriented toward data processing. Some actually do it; others manage those who do, and others support or are supported by them. But the future goal is for this to be used by anyone and everyone who works in offices. That means that the use should be designed to fit their needs, not ours. The systems are meant to improve the productivity of currently-existing offices, and must facilitate their existing operational patterns. It's going to be enough of a wrench to introduce these new developments without at the same time trying to restructure their basic behavior patterns! The way I described "traditional communications" is the way things really work in most offices. Of course, unusual work situations also exist, such as the special small development groups Larry Campbell described, and they should be supported too, but they are NOT the norm! Business communications are structured, not only in government, but in any large corporation. There really is a chain of command; it must be recognized and considered in preparing a marketable product for our customers. Another problem is forgetting the difference between personal and business communication. If I send YOU (personally) a letter, and ask you to keep it to yourself, and you show it to others, you are violating our implied contract of mutual trust. If I send a letter to an organization, even if it is to the attention of a person's name or an official title, that letter is only "private" with respect to the entire organization! The individual receiving it is perfectly well entitled to pass it around within the organization, to any extent necessary to perform the business of that organization. These facilities are provided for the purpose of conducting business, and that's why they are being bought. Just like the telephone service, a certain amount of personal use is tolerated, but not officially sanctioned. The concerns we have for designing in "privacy" features are for the organizational requirements, such as limiting access to information because whoever is in charge does not want that information compromised. The fact that it also helps protect individual privacy is nice, but not what is being paid for! There is definitely a need to be filled in both modes; office memo/roundtable discussions are facilitated by mass CC'ing -- normal business communications are not. I'm not saying that either mode should be eliminated; far from it -- these systems must be made as versatile as possible. It's just that the primary use must be kept uppermost in mind when establishing defaults and the most common options. Ideally, the systems will be tailored to individual preference, and everyone will be happy. Will Martin 30-OCT-79 14:19:44-PST,1840;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 1312-PST Date: 30 Oct 1979 1125-PST Sender: HARMON at USC-ISI Subject: MSGGROUP#1361 Re: Sinking into concentration From: HARMON at USC-ISI To: MACKENZIE at USC-ECL Cc: msggroup at MIT-ML Message-ID: <[USC-ISI]30-Oct-79 11:25:59.HARMON> In-Reply-To: Your message of 29 OCT 1979 1313-PST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Dear Kevin, I take issue with a few of the points that you made concerning system design. First, modifications to a particu- lar system are not always bad if the system is PROPERLY de- signed (i.e., modular with well controlled coupling between the modules). In fact, the principles of good design are supposed to encourage flexibility and extensibility in systems. Thus, I feel that good systems are responsive to changes either before or after release. All too often system designers are resistant to making changes because of an adherence to the pristine seed idea. After all it is a good idea why should it change (especially in response to the demands of the un- informed user). Finally, I agree that as time progresses systems will get better (whatever they were designed for). How- ever, there is another factor to consider, the evolution of the common user. As computer systems become more wide- spread I suspect that the user will become more sophisti- cated and, thus, will be somewhat more capable. As an example consider the development of the automobile and the resulting evolution of the driver. Perhaps, the cumber- some systems required to support the "idiot" user will be less necessary as users become more familiar with the area of the system performance which impacts their interests. Sincerely, Scott 30-OCT-79 14:19:44-PST,695;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 1349-PST Date: 30 Oct 1979 1233-PST (Tuesday) From: Lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1362 mailgrams To: MSGGROUP at ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Actually, Western Union has had a service for something like two years where you could call a dialup line with ANY terminal and send mailgrams directly. They have protocols for just about any speed and type of terminal you can imagine. So I imagine the TRASH-80 stuff is basically just a terminal driver with maybe a little formatting stuff. --Lauren-- ------- 1-NOV-79 23:38:50-PST,2324;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 1429-PST Date: 30 Oct 1979 1256-PST From: Mark Crispin Subject: MSGGROUP#1363 UNIX To: david at UTEXAS, MACKENZIE at USC-ECL cc: msggroup at MIT-ML In-Reply-To: Your message of 30-Oct-79 0453-PST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 I think that description (ie, a computer system that is... powerful and easy to use for both sophisticated and novice users) could be better applied to TOPS-20 (and to some extents TENEX) than UNIX. UNIX suffers from the idea that all commands should be between 2 to 6 characters; I can't respect any operating system where I have to know to type "ls" to see a directory of my files. It is conceeded that the TOPS-20 help system isn't far removed from TOPS-10's, ie, a directory of short files which a HELP command will show as "topics" based upon the file name. But at least you can see the full menu with a wildcard help as a standard feature (I understand that this is a special hack in certain UNIX systems to allow this). In addition, well-written subsystems such as the EXEC and the better utilities have built-in help provided with noise words, recognition, completion, and ? to list the menu of options. I generally am able to figure out how to use an unfamiliar TOPS-20 program without reading its documentation merely by using ? to see the menu and following each command through recognition and its noise words. LOTS has extended HELP to have tree-structure within the help file, including menus, etc. Of course, help files are just that - help files - and other directories exist for the actual online manual or documentation to reside. I don't wish to criticise UNIX - far from it. It is far and away the best minicomputer operating system and is better than many "large" computer operating systems. This is made more impressive by the fact that it is written in a moderately high-level language (C). It's just that it is unfair to present UNIX as a system "anybody can use" - it just isn't THAT friendly; also from a systems point of view it lacks some important features (although TOPS-20 lacks some that UNIX has, so the score is about even on that point). ------- 1-NOV-79 23:38:50-PST,1835;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 1517-PST Date: 30 Oct 1979 1320-PST From: Larry Campbell Subject: MSGGROUP#1364 Re: More re CC To: msggroup at MIT-ML In-reply-to: Your message of 30-Oct-79 1152-PST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 I don't believe that "office memo/roundtable discussions" and "normal business communications" are mutually exclusive, as Will Martin apparently does. The office situations he talks about create images in my mind of people sneaking around, sending confidential memos to "superiors" and "subordinates", covering their asses, and in general paying more attention to the political impact of "who knows, or receives, what" than to getting the job done. If this is "normal business communications", then something is seriously wrong with "normal business", and should be corrected. Business should be a cooperative venture, entered into by groups of people with common goals, who can be friendly and cooperative, and should not be a cauldron of palace politics, with people climbing over other people by means of secrecy and misdirection. As far as I'm concerned, secrecy has no place in a business organization, with the possible exception of sensitive personnel and personal matters (salary reviews, for instance). Of course, excessive flooding of mailboxes with irrelevant stuff is discourteous, and can and should be regulated by common courtesy. However, I find it extremely objectionable to wire assumptions about organizations into mail systems which are, at best, of only limited applicability, and at worst, perpetuate the sort of stifling and authoritative organizational mistakes which have become tradition in American business. ------- 1-NOV-79 23:38:50-PST,4674;000000000001 Mail-from: MIT-MC rcvd at 30-Oct-79 1538-PST Date: 30 October 1979 15:01-EST From: Charles Frankston Subject: MSGGROUP#1365 The use of CC To: ROUNDS at OFFICE-1 cc: MSGGROUP at MIT-MC Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 I would also have to express strong disagreement with your position re not replying to CC fields. Firstly, I think that analogies of electronic mail to telephone and paper communications must be taken very carefully. Electronic mail is a new medium and it may not necessarily make sense to use it in the same fashion as existing medium, any more than it would have made sense to use telephones in precisely the same fashion as telegraphs that preceeded them. In this case I think it is obvious enough why most telephone conversations are one to one and I don't need to go into why those reasons do not apply to electronic mail. As for paper communications, I think a case can be made that a good deal of paper communications does not go to just one person. Note, that as of yet, hardly anyone is using electronic mail for the things that I believe generate most of the single point to single point U.S. mail communications; which is the mailing of bills, orders, etc. by business. On the other and, electronic mail is currently used extensively for communications which today does got to many recipients, ie. inter-office memorandum etc. As a new medium I also claim electronic mail has generated new uses not heretofore possible. For example, most of my use of the medium consists of back and forth technical discussions, often among persons widely dispersed geographically. It is rude in these discussions to suddenly drop someone. In fact, the great advantage of electronic mail for this sort of use, is that it is easy to simply CC anyone I think might be interested or have information to provide on the current topic. You might say that I should just make it a multi-recipient message, but there are subtle differences to a CC which I take advantage of. Ie. if I send a question to several people, generally each reciepient doesn't really know if he is expected, or best equiped to answer it. But I can make the situation clearer by CC'ing it to people to who I might think are interested in the reply. I think the Reply-To field is cumbersome for this purpose (most people would then have to appear in the CC and Reply-To fields). Furthermore it won't work right, at least not with my mail reader. Like most modern mail readers, we have an option to include the CC field. However, the Reply-To: field is always included, since it is defined by RFC-733 to override the From: field. Therefore by attempted to pre-bind my decision to reply or not reply to those that the message was copied to, you've removed my easy means of sending a note to the sender of the message alone! (Whew!, that paragraph was probably too long). But, I'm willing to grant that people may use electronic mail in a drastically different way than Geoff and I apparently do. This is why most mail systems give one the choice. Since many people have pointed out the fashion in which their mail systems give one the choice, I'll take the oppurtunity to once again point out the advantages of having one's mail reader built into the display editor. When I type a reply, either the flavor that replies to CC's or the one that does not, I am shown exactly the information that is going to be used to form the header. I can then of course simply edit it (with my favorite editor, the screen editor of course) to be exactly what I intended. This is what is on top of my screen: To:Geoff@SRI-KA Subject:Re: The use of CC Header-Force:RFC733 To:ROUNDS@OFFICE-1 Cc:msggroup@MIT-ML Notice, that since I wanted to be able to be able to use the pronoun "you" in the message I decided to delete Geoff (since I know he's on msggroup anyway). I also removed the "@MIT-ML" from msggroup, since I'm on MC, by evaluating the list locally, MC can make sure ROUNDS doesn't get 2 copies of the reply. MIT-ML can no longer reasonably perform that optimization. Someone looking over my shoulder also pointed out that Subject:Re: looked funny, so I removed that too. This was all very easy. Ie. if people want to talk about simple general mechanisms, I think using normal editing commands to control the editor makes it much more likely that users will know HOW to control their editor than having the remember a plethoria of special purpose commands. 1-NOV-79 23:38:50-PST,1229;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 1542-PST Date: 30 October 1979 14:14-PST (Tuesday) From: Thomas R. Bowerman To: MOOERS at BBN-TENEXA cc: JNC at MIT-MC, MSGGROUP at MIT-ML, SDSAN-DMS at SRI-KA, MARS-Filer at CCA Subject: MSGGROUP#1366 Handling of Reply.. Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 A couple of obvious (often overlooked) solutions. If an unwanted message or two bothers you, get off the mailing list; is one solution. A second solution is to delete all messages with cc: Msggroup, without reading them. Others that come to mind are to compare the time used in flaming to the time used in reading an occasional unwanted message or to go a bit further and delete your message text before going into the message system, thus assuring you are never disturbed. As a matter of fact, I was glad Stef sent me a copy of his reply as I value his opinion and determined that I also wanted a copy of the document that started the entire discussion. As a matter of fact, his request for a copy of the message has been one of the more interesting messages in this series. Maverick 1-NOV-79 23:38:50-PST,1328;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 1613-PST From: Kiessig at Rand-Unix Date: 30 Oct 1979 at 1458-PST To: admin.mrc at Su-Score cc: msggroup at Mit-Ml Subject: MSGGROUP#1367 Re: UNIX In-reply-to: Your message of 30 Oct 1979 1256-PST. Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 i don't think that tops-20 is really nice to the naive user. and i don't think unix is, either. in fact, not one of the many systems i have used do i really consider to be really helpful to a user that is just starting to learn. people just don't design computer systems with naive users in mind. i have run into this problem many times. there have been attempts by several installations to make their systems more friendly, but this sometimes just serves to confuse things, since the changes don't exist every where. as far as i know, the systems that have come closest to being really nice to the naive user are the ones whose users require that. these would be systems like some of the newer word-processing machines on the market, or some of the special purpose systems that are being manufactured. in the research area, you are lucky to find a system that you can really understand, even after several years experience on it! 1-NOV-79 23:38:50-PST,974;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 1653-PST Date: 30 Oct 1979 1629-PST Sender: FARBER at SRI-KA Subject: MSGGROUP#1368 Re: UNIX From: FARBER at SRI-KA To: Kiessig at RAND-UNIX Cc: admin.mrc at SU-SCORE, msggroup at MIT-ML Message-ID: <[SRI-KA]30-Oct-79 16:29:02.FARBER> In-Reply-To: Your message of 30 Oct 1979 at 1458-PST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Well I should get my cane out and comment on all those nice systems that existed before BLACK Tuesday (the IBM 360 announcement date), but rather than that maybe I should comment that there are reasonable systems that seem to be easy to use and flexible. The HP 300 (Amigo) system is a fair example of that. It is friendly yet powerful. Far from perfect but than what isn't. I find UNIX to be very usable but friendly it is not !!! But then TOPS/20 aint either. Dave 1-NOV-79 23:38:50-PST,1999;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 1732-PST Date: 30 OCT 1979 1654-PST From: MACKENZIE at USC-ECL Subject: MSGGROUP#1369 Sinking into concentration To: msggroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Your point concerning increasing user sophistication is excellent, I think. Thank you. As to systems being responsive to change, weellll.... The dictates of economics often have a hand here too, in that the more flexibility that is built into a system, the more system resources it takes to operate, and the longer it takes to develop. It's been my experience that the tradeoff competition between money and flexibility has a fairly consistant winner, and it ain't flexibility. Even when the "proper" decision is made concerning flexibilty, it seems to me that the reduced rate of obsolesence is often not worth the effort, as the areas where the system must "flex" are not the areas into which flexibity was designed. By definition, the design problems that really screw you up are those that you didn't think of, not those that you planned for. Please take these comments in the light of current progress in the field. Your premise, that flexibility is the answer is quite sound. I just don't think our understanding of software develop- ment, or our tools are adaquate to meet the challenge yet. I believe the real answer to our problems will be heavier user participation in development thru "natural language" programming. I see the software business moving more and more into the tools business, and away from specific application solutions. I think an analogy to this is the automobile. There are many people who do all their own maintenance on their car(s), and nearly everyone understands how they work to some extent. I think we *must* see this trend in computers, if computer usage is to grow as rapidly as predicted. Kevin ------- 1-NOV-79 23:38:50-PST,733;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 1803-PST Date: 30 OCT 1979 1708-PST From: MACKENZIE at USC-ECL Subject: MSGGROUP#1370 Still more Re: CC To: msggroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 I did a quick survey in our company, and asked several non-compputer friends to do the same. We found very few memos, other than those of the "just a note to tell you that..." variety (and these too were few), that did not have a (sometimes huge) cc list. These are all *paper* offices, not electronic. I don't believe that the pattern described by Will is nearly as common as he represented it to be. Kevin ------- 1-NOV-79 23:38:50-PST,813;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 1823-PST Date: 30 October 1979 20:45-EST From: "Marvin A. Sirbu, Jr." Subject: MSGGROUP#1371 Re: The use of CC To: ROUNDS at OFFICE-1, Geoff at SRI-KA cc: msggroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Geoff, you argue that the recipient of a message has to ask permission of the sender before he circulates it to third parties. That contradicts my understanding of normal protocol regarding letters. Typically, once I have sent a letter, it is as much the property of the recipient as it is of me; he may show it to whomever he wishes. Only if I specifically request that he not circulate it can I expect him to treat it as confidential. 1-NOV-79 23:38:50-PST,1374;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 1842-PST From: JNC@MIT-MC Date: 10/30/79 21:19:04 Subject: MSGGROUP#1372 UNIX.... Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 JNC@MIT-MC 10/30/79 21:19:04 Re: UNIX.... To: msggroup at MIT-ML MRC: there is nothing in UNIX that says that either command names have to be less than six characters or that you can't have command completion, etc. in the shell (EXEC, in TOPS20). These two decisions are both independeant of each other and the system. Command names are what you call them; if you don't like ls then add links to the names list and directory and dir, etc. Please do not confuse teh sytem interface with the exec interface with people's names for commands: the MIT version of ls is NOT called ls, so to make that complaint to somebody from our local UNIX users group would get a blank stare. It would also be nice if people would use systems before they bitch about the misfeatures; I bet that 99% of the people who complain that "UNIX has a fragile file system" have never been in a position to decide for themselves, but are just repeating what they heard. I'm tired of people complaining that "system X has Y lossage" when they have a) never used X to find out, and b) it isn't true anyway. Noel 1-NOV-79 23:38:50-PST,1534;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 1920-PST Date: 30 October 1979 2159-EST From: Brian.Reid at CMU-10A Subject: MSGGROUP#1373 Messages and business To: Larry Campbell CC: msggroup at MIT-ML Message-ID: <30Oct79 215928 BR10@CMU-10A> In-Reply-To: Larry Campbell's message of 30 Oct 79 16:20-EST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 It is not our job to redesign business. We are systems people, not business people. Who was it who noticed a number of years back that system designs tend to mirror the organization of the institutions in which they are designed? If a mail system does not support the kinds of communication that take place within a business, they will not use it. No matter that the designer of the mail system believes that "businesses should x" or "businesses should not y". If it does what the designer wants and not what the clients want, it is worthless. Now oftentimes, however, the end users don't know what they want. It is in that domain that the expertise of the system designer can help: he knows what is good; he knows what other people want, and he might be able to postulate something that would be good for these users. For that reason--that nobody really yet has enough{ experience with mail systems to honestly know what they want--we should be designing more and different and varied mail systems, for people and organizations to try. Brian 1-NOV-79 23:38:50-PST,737;000000000001 Mail-from: MIT-MC rcvd at 30-Oct-79 2032-PST Date: 30 October 1979 21:04-EST From: Richard M. Stallman Subject: MSGGROUP#1374 Reply-to is not the answer To: msggroup at MIT-MC Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 When I receive a message addressed to many people, whether I want to send my reply to the sender or to all of them depends on what I am saying. This is true when all the other people are part of a mailing list like MSGGROUP, just as it is when they are explicitly listed. Any mechanism such as Reply-to, whereby the sender of the message specifies who gets the reply, cannot deal with this. 1-NOV-79 23:38:50-PST,1847;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 2052-PST Date: 30 OCT 1979 2152-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP#1375 Who are our mail systems for? To: ROUNDS at OFFICE-1 CC: msggroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 One should not be over-general in saying who computer mail systems are intended to be used by. Some people, you perhaps, HERMES authors perhaps, may be trying to write computer mail systems for use by laymen in businesses, but many of the mail systems on the Arpanet now (including at least MM and RMAIL, and probably the systems at CMU and SAIL) were developed for the sake of the research communities that are using them. This does not mean that simplicity was regarded as a fault, but it does mean that different things are simple or complex, and that simplicity's weight may be a little less and power's weight may be a little more. We are exhorted to remember who is funding mail systems, but ours were not funded as mail systems. They were written as general improvements to systems intended for use by sophisticated local people. There are certainly a lot more laymen than hackers. And they ought to have mail systems that do what they want. But not EVERY mail system has to be for them, just some mail systems. There are a lot of Arpanet sites full of sophisticated computer users, and we are no less deserving of software that meets our needs than laymen are. But very often, giving sophisticated users suitable software is called an unworthy goal. It is time for those of us who are trying to write software for laymen to stop deprecating the efforts of those of us who write software for the communities of sophisticated users that we belong to. 1-NOV-79 23:38:50-PST,756;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 2114-PST Date: 30 OCT 1979 2201-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP#1376 Who are our mail systems for. To: rounds at OFFICE-1 CC: msggroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 When I spoke of laymen vs. sophisticated users, I should also have spoken of traditional business communication vs. researchers' patterns of communication. Traditional business communication patterns may be a good guide for how to make a mail system better for use in a traditional business, but they do not necessarily indicate how to make a mail system good for an Arpanet research community. 1-NOV-79 23:38:50-PST,929;000000000001 Mail-from: MIT-ML rcvd at 30-Oct-79 2134-PST Date: 30 OCT 1979 2209-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP#1377 One example of reason to reply to everyone. To: rounds at OFFICE-1 CC: msggroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 I'd like to offer an example of one reason one might want to reply to all the recipients of a message, and not just to the sender. If the message is about a controvercial issue, and you disagree with it, and you think that it contains falacious but seductive arguments or incorrect facts which might have misled one of the recipients, then you will want to send the rebuttal to all of them, not rely on the sender to redistribute it. Taking into account what sort of discussions go on in these mailing lists, this is a pretty frequent mode of usage. 1-NOV-79 23:38:50-PST,4314;000000000001 Mail-from: MIT-MC rcvd at 30-Oct-79 2310-PST Date: 31 OCT 1979 0140-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: MSGGROUP#1378 CC: or not CC: To: rounds at OFFICE-1 CC: MSGGROUP at MIT-MC Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 You asked why anyone would want a reply to go to a CC: recipient. I find it hard to concieve of the circumstance where one would NOT want a CC recipient to get a CC of the reply. You talk a lot about one-on-one and chain-of-command communications. In these, why would there be a CC: recipient to reply to at all? Except in cases like a CC: to your secretary, in which case of COURSE you want the reply to also go to your secretary. Or when there is another person who has an intrest in the matter, like an affirmative action officer who is CC:'d a copy of a request for a job description, and who OF COURSE, should be sent a copy of the job description. If I CC: somebody (like MsgGroup in this message), it's an indication that I think this person has an interest in the subject. If I'm asking a question, it's not much use to CC: somebody unless he also gets the reply! I really don't see how this principle changes from one environment to another. Certainly how much you USE the CC: feature. However, it DOES make a difference when the CC: becomes less of a reasoned "This person needs to know about this exchange" to "Broadcast this proclomation to the world, or MsgGroup, or the U.S." In that event, it is more likely that the reply-er would consider it a major error to reply to that CC:. But that's true in any environment, and the business/research distinction you're invoking doesn't come in at all. As to Reply-to:, it would seem to me that this works perfectly for what it's designed to do, and nothing more: Providing instructions on how to reply to the author. It's perfectly legit to include your secretary in the Reply-to: field to cause replies to you to also go to him/her/it(!). To unravel the "how do I say replies should just be sent to me" question, I think we should focus on TYPES of communications rather than on "What field in the header should I set?". For example, there are questions and polls, which differ in that polls are intended to collect mass responses, not to obtain a single datum. It's acceptable to send the reply of a question to a CC:'d recipient, but not in a poll! (You might argue that, but at least accept the distinction that in a poll the people being polled should not be deluged with all the responses). There are formal anouncements, advertisements and public notices. There are bank drafts, love letters, and jokes. These all have differing ways in which replies need to be handled, whether they should be defaultly handled by your secretary, etc. Rather than having a myriad options to set in the header and having to know the effect of each one, maybe it would be better to identify a set of applications which provide the basic spectrum of how messages should be handled, and provide those to the user. Flexibility would dictate that these be built on concepts like the BCC:, Reply-to:, and other primitives we don't have yet, but the user shouldn't have to worry about this most of the time. He might say "I want to announce a new software product to the XYZ-users, with orders going to XYZ-sales and more information available from publications." Hopefully, this system could AT LEAST manage to avoid people from CC:ing their orders to XYZ-users. At the other end of the spectrum, it might provide automatic return-addressing, say, giving the user the option of sending for more info, ordering (prompting for delivery info and PO number) etc., just like the pre-printed order/more- info cards that are included with paper advertisements now. Different departments and different might want different option sets like this, and there still are problems with making it as easy as possible for the user to make small changes in the options. But it is an aproach which can keep the executive from having to worry about accidentally replying to HOMEOWNERS. (BKR, isn't this sort of like the Scribe philosophy wrt document formating?) 1-NOV-79 23:38:51-PST,1501;000000000001 Mail-from: MIT-ML rcvd at 31-Oct-79 0045-PST Date: 31 OCT 1979 0030-PST From: JMCHUGH at USC-ECL Subject: MSGGROUP#1379 CCs Really Do Help! To: MacKenzie at USC-ECL cc: MsgGroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 (KEVIN, PLEASE CONSIDER THE FOLLOWING TO BE WORTH ONE G*O*T*C*H*A PAYABLE IN THE BREW OF MY CHOICE NEXT TIME YOU'RE IN LOS ANGELES!) Mail-from: MIT-ML rcvd at 30-OCT-79 1725-PST Date: 30 OCT 1979 1654-PST From: MACKENZIE at USC-ECL Subject: Sinking into concentration To: msggroup at MIT-ML Your point concerning increasing user sophistication . . . After finding the two responses to your original msg, I assume that the word "Your" refers to HARMON at USC-ISI, not MSGGROUP at MIT-ML. Mail-from: MIT-ML rcvd at 30-OCT-79 1759-PST Date: 30 OCT 1979 1708-PST From: MACKENZIE at USC-ECL Subject: Still more Re: CC To: msggroup at MIT-ML This appears to be in response to the msg from William G. Martin at MIT-ML with the subject: More re CC. Kevin, please don't let the current pointed comments on who is or is not using the Cc: field correctly discourage you from using the A(nswer) command in MSG . . . it would help the rest of us keep track of things in the midst of the deluge! Cheers - Jim ------- 1-NOV-79 23:38:51-PST,482;000000000001 Mail-from: MIT-ML rcvd at 31-Oct-79 0244-PST Date: 31 October 1979 05:36-EST From: Richard M. Stallman Subject: MSGGROUP#1380 Discussion of Unix and other operating systems. To: msggroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Isn't this a little far astray for msggroup? Besides, the size of this topic is so big that we would never see the end of it. 1-NOV-79 23:38:51-PST,562;000000000001 Mail-from: MIT-ML rcvd at 31-Oct-79 0909-PST Date: 31 Oct 1979 0856-PST Sender: PICKENS at SRI-KL From: PICKENS at SRI-KL Subject: MSGGROUP#1381 What about BCC Usage Conventions? To: mumblefoo at SRI-UNIX Bcc: msggroup at MIT-ML Message-ID: <[SRI-KL]31-Oct-79 08:56:34.PICKENS> Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Now that CC: has been put to rest, who understands the proper usages of BCC:, i.e. from the perspective of organizational dynamics? JRP 1-NOV-79 23:38:51-PST,687;000000000001 Mail-from: MIT-ML rcvd at 31-Oct-79 1742-PST Date: 31 OCT 1979 1729-PST From: MACKENZIE at USC-ECL Subject: MSGGROUP#1382 Re: CCs Really Do Help! To: JMCHUGH cc: MsgGroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 In response to your message sent 31 OCT 1979 0030-PST 1) I absolutely refuse to debate the by now very seversly beaten to death CC issue. 2) Sorry about the use of the personal pronoun. I have another solution, and I will use it, but I will not present it here for fear that it will add fire to this...(bite tounge)...dis- cussion. Kevin ------- 1-NOV-79 23:38:51-PST,752;000000000001 Mail-from: MIT-ML rcvd at 31-Oct-79 1800-PST Date: 31 OCT 1979 1742-PST From: MACKENZIE at USC-ECL Subject: MSGGROUP#1383 Operating system discussion To: msggroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 I (regretably) started this discussion by asking y'all to name a large software system that is easy to use for both the sophisticated user and the novice, and powerful. I think the point is made. There ain't none. Or if there is, they are VERY few. Can we let this rest? Mr Stallman is right. It really can go on forever................................................................. ................... Kevin ------- 1-NOV-79 23:38:51-PST,570;000000000001 Mail-from: MIT-MC rcvd at 31-Oct-79 2030-PST Date: 31 Oct 79 21:31-EST From: Farber at UDel-EE Reply-to: Farber at Rand-Unix To: msggroup at mit-mc Subject: MSGGROUP#1384 NY Times. Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 In the 28 Oct Sunday edition of the New York Times there was a special section "Office80" on the future office automation. Howard Anderson of the Yankee Group had the lead piece which discussed among other things Computer Mail. Dave 2-NOV-79 14:46:58-PST,651;000000000001 Mail-from: MIT-ML rcvd at 2-Nov-79 1256-PST Date: 2 November 1979 1533-EST From: Richard H. Gumpertz Subject: MSGGROUP#1385 "Your" To: JMCHUGH at USC-ECL CC: MsgGroup at MIT-ML Message-ID: <02Nov79 153308 RG02@CMU-10A> In-Reply-To: JMCHUGH's message of 31 Oct 79 03:30-EST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Why don't mailers other than CMU's try to produce reasonable in reply to fields rather than stuff starting with "your"? See above for an example. It isn't perfect, but it sure beats "your". Rick 2-NOV-79 14:46:58-PST,1160;000000000001 Mail-from: MIT-ML rcvd at 2-Nov-79 1401-PST Date: 2 NOV 1979 1344-PST From: JMCHUGH at USC-ECL Subject: MSGGROUP#1386 Re: "Your" [in-reply-to field] To: Rick.Gumpertz at CMU-10A cc: MsgGroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 In-Reply-To: Rick.Gempertz's message of 2 Nov 79 15:33-EST --or-- In response to your message sent Friday, 2 November 1979 1533-EST Your observation on "in-reply-to" fields is interesting to me, Rick, because I've never paid any attention to the difference prior to your message. I do think it very important to have information presented regarding the fact that the current message is in reply to a specific previous msg. And though it seems like a fine point that you're surfacing, I can relate to the aesthetics . . . and potential irritation --- I see that CMU's mailer does a nice job on this. But somehow I can't get excited about the format of such information. Best - Jim P.S. Wouldn't this topic be more appropriate for HEADER.PEOPLE than for MsgGroup? ------- 2-NOV-79 14:46:59-PST,598;000000000001 Mail-from: MIT-ML rcvd at 2-Nov-79 1435-PST Date: 2 Nov 1979 1421-PST From: Larry Campbell Subject: MSGGROUP#1387 Re: "Your" [in-reply-to field] To: JMCHUGH at USC-ECL, Rick.Gumpertz at CMU-10A Cc: MsgGroup at MIT-ML In-reply-to: Your message of 2-Nov-79 1344-PST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Yes, I believe CMU's "In-reply-to:" is a real winner, and will shortly implement the same function in DEC's mail prog for TOPS20 (MS, MM's great-grandnephew). ------- 5-NOV-79 20:00:10-PST,1476;000000000001 Mail-from: MIT-ML rcvd at 5-Nov-79 0807-PST Date: 5 November 1979 1045-EST (Monday) From: David.Lamb at CMU-10A Subject: MSGGROUP#1388 Survey of mailer problems To: MsgGroup at MIT-ML Message-ID: <05Nov79 104508 DL10@CMU-10A> Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 A few months ago I circulated a note asking people to let me know about problems people were having with each others' mailers. I have summarised the results of the responses to that note, as well as what I could find from old messages in the MARS filer, in the file MAILER.DOC[C410DL10] at CMU-10A. CMU's FTP server allows you to retrieve files without logging in. The file contains 114 lines, which was somewhat longer than I thought reasonable to include in a mail message. I was surprised at how few problems I managed to discover this way; there were less than a dozen, almost all of which I'd heard of before. If any of you notice some I've missed after reading the file, please let me know. I also believe that some of the problems mentioned in the survey have been resolved (such as CMU's names-containing-blanks). I am interested in talking with other mail system maintainers to try to resolve what to do about the other problems on the list. David [NOTE - The file has been placed in the message following this one in the MSGGROUP Proceedings for convenient access] 5-NOV-79 20:00:10-PST,4257;000000000001 Mail-from: CMU-10A rcvd at 5-Nov-79 1237-PST Date: 5 November 1979 1530-EST (Monday) From: David.Lamb at CMU-10A Subject: MSGGROUP#1389 Re: Survey of mailer problems To: STEFFERUD at OFFICE-1 Message-ID: <05Nov79 153034 DL10@CMU-10A> In-Reply-To: <[OFFICE-1] 5-Nov-79 08:25:55.STEFFERUD> Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 This note summarises a number of RFC733-related problems people have been having with each others' mailers over the last year or so. In almost all cases the problem falls into one of two classes: a sender implements some part of RFC733 that a receiver cannot handle, or a sender (and sometimes a receiver) does something not permitted by the standard. Most of these topics have come up several times. Several of them have been "fixed" in particular instances, for particular mail senders or particular mail receivers. 1. Address List Problems 1.1. Missing Host Names in Address Lists Some mailers leave out host names in address lists when the host name is the same as that of the sender. For example, From: Person1 To: person2 at site2, person3 Sender: person4 at site1 This shortened header is assumed to be the same as From: person1 at site1 To: person2 at site2, person3 at site1 Sender: person4 at site1 The mailer at Site2 may be unable to determine that replies should be sent to Site1. There are two apparent solutions to this, both involving quite a bit of work. The first is to require all mailers to always provide explicit site names, as specified in RFC733. The second is to have mail receivers believe that missing site names are the same as that of the originator. 1.2. Embedded Spaces in Mail Addresses A number of mailers are unable to reply to messages containing names of the form Firstname LastName at Host All such mailers appear to be able to accept names of the form FirstName.LastName at Host Carnegie-Mellon appears to be the only site that generates names with embedded spaces. Its mailer has been modified so that names may optionally have the space converted to a dot. A slight variant on this difficulty was the inability of some mail readers to handle names of the form Name @ Host where there were spaces around the at-sign. This was condidered a bug and fixed at CMU. 1.3. Case Distinctions in Mail Names At some sites the names "Person", "person", and "PERSON" are all considered to be different. Additionally, other sites generate headers of the form From: Person at Site1 To: .... CC: PERSON at Site1 2. DATE Field Problems 2.1. Day-of-Week RFC733 allows a date field to include a day of week before the date. For example, Wednesday, 26 September 1979 12:07-EDT This causes other mailers to be unable to recognise a valid date in this field. This usually has the consequence of treating the date as some base date years in the past, causing searches based on date to fail. Solutions to this difficulty include optionally omitting the day-of- week field, or placing it after the date as a comment. For example, 26 September 1979 12:07-EDT (Wednesday) 2.2. Nonstandard Date Forms At least one mailer generates dates of the form 2 Jul 1979 9:07 am (Monday) leaving out the timezone field, and adding an "am/pm" field not mentioned in the standard. This typically messes up receivers which do sorting or searching on the date field. 3. Long Lines in Message Texts Many people send mail with text lines longer than 72 characters. This makes it difficult to view such mail on narrow terminals. 4. Nonstandard "Mail from" line Each piece of incoming mail on (certain? all?) TENEX sites gets a new line added to the beginning of the header of the form Mail from HOST rcvd 25-JUN-79 1231-PDT which violates RFC733 format for header lines. Any attempt to redistribute such messages requires eliminating or modifying that line. Suggested solution: change this line to begin with some keyword such as "Mail-from:" or "Origin:" or "Via:". 29-NOV-79 21:11:26-PST,1263;000000000001 Mail-from: MIT-ML rcvd at 13-Nov-79 1702-PST Date: 13 Nov 79 18:51-EST (Tue) From: Dcrocker at UDel-EE Reply-to: Dcrocker at Rand-Unix Subject: MSGGROUP#1390 Lesson on Learning To: News at UDel-EE, MsgGroup at Mit-Ml Message-ID: <79316.67865.4830 @ UDel-EE> Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 SAN JOSE (AP) -- "In the pink" means in the clink at the Santa Clara County jail, where two cells have been painted hot pink to test a theory that the color of a person's surroundings affects his behavior. The new color scheme has had mixed results, said jail commander Lt. Paul Becker. When it's used properly, there's a difference," he said. "You take a guy who's hostile and leave him in the strip cell for 15 minutes and he won't be quite as hostile. "But after 20 minutes it has a reverse effect," he said. "We left some guys in the holding cell for about three hours and they tore some of the paint off the walls. ...Becker [said] he got the idea while attending a class on the relation of criminal behavior to body chemistry. "We didn't learn about the reverse effect until the second class," said Becker. 29-NOV-79 21:11:26-PST,1286;000000000001 Mail-from: MIT-ML rcvd at 22-Nov-79 1355-PST Date: 22 NOV 1979 1346-PST From: JDASTEEL at USC-ECL Subject: MSGGROUP#1391 THE REAL THANKSGIVING TURKEYS To: msggroup at MIT-ML cc: msggroup at ECL Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 A noted historian claimes that the first Thanksgiving was not a festive gathering of pilgrims and indians, but rather a slaughtering of some 700 indians by white settlers. Historian Professor Newell, former chairperson of Connecticut anthropology department, claims that the traditional image of sharing festivities is fictitous. His findings are based on historical letters and reports some 300 years ago between colonial leaders in America and their supervisors in Europe. Correspondence described how the 700 members of the Pequot tribe--men, women, and children-- were ambushed and massacred by settlers in 1637, as the indians were feasting. This alleged massacre took place in Groton, Connecticut. Newell says the governor of Massachusetts Bay Colony proclaimed it a holiday celibrating a slaughter which wiped out an entire tribe. [ THIS REPORT WAS AIRED YESTERDAY OVER RADIO KNX-FM, L.A., CA.] ------- 29-NOV-79 21:11:26-PST,1393;000000000001 Mail-from: MIT-ML rcvd at 23-Nov-79 0924-PST Date: 23 Nov 1979 1206-EST Sender: BERNSTEIN at BBN-TENEXD Subject: MSGGROUP#1392 Re: THE REAL THANKSGIVING TURKEYS From: BERNSTEIN at BBN-TENEXD To: JDASTEEL at USC-ECL Cc: msggroup at MIT-ML, msggroup at ECL Message-ID: <[BBN-TENEXD]23-Nov-79 12:06:33.BERNSTEIN> In-Reply-To: Your message of 22 NOV 1979 1346-PST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 the experts here say that what is being referred to by the learned Perfesser is a well known massacre during the war called "King Phillip's war" which was fought in the area mentioned and pitted the settlers against the Indians. The first Thanksgiving, on the other hand , was celebrated when, after the first hard winter subsequent to the Mayflower's arrival in these parts, a good harvest pointed toward a "survivable" winter. At the time of the first Thanksgiving, settlers and Indians were ostensibly friends. 13 years later the settler folk decided that it was inconvenient having the indigenous folk around, and so happened King Phillips war, during which among other things, the Pequot tribe was wiped out. I have it on good authority that this debunking has gone toooooo far. The source is Bill Earle, sophisticate, and knower of most things. Dave Bernstein 29-NOV-79 21:11:26-PST,721;000000000001 Mail-from: MIT-ML rcvd at 23-Nov-79 1033-PST Date: 23 Nov 1979 1313-EST Sender: BERNSTEIN at BBN-TENEXD Subject: MSGGROUP#1393 Re: THE REAL THANKSGIVING TURKEYS From: BERNSTEIN at BBN-TENEXD To: BERNSTEIN Cc: JDASTEEL at USC-ECL, msggroup at MIT-ML, msggroup at ECL Message-ID: <[BBN-TENEXD]23-Nov-79 13:13:53.BERNSTEIN> In-Reply-To: <[BBN-TENEXD]23-Nov-79 12:06:33.BERNSTEIN> Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 After some quick research, Bill Earle wishes to change King Phillip's war to Pequot War (1637), but the remaining information remains as-is. Thanksgiving is placed in 1621, and Pequot War in 1637. 29-NOV-79 21:11:26-PST,1060;000000000001 Mail-from: MIT-ML rcvd at 28-Nov-79 0722-PST Date: 28 Nov 1979 0614-PST Sender: RIVANCIW at SRI-KA Subject: MSGGROUP#1394 basic text editor and message system From: RIVANCIW at SRI-KA To: SRI-KA.COMMUNITY:, To: OFFICE-1 COMMUNITY:, To: OFFICE-2 COMMUNITY: Cc: rivanciw, saucier, sternberg Message-ID: <[SRI-KA]28-Nov-79 06:14:44.RIVANCIW> Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 I am trying to locate a text editor and/or a message system that is written in the BASIC language. If you know of any text editor or message system written in the BASIC language could you please send me a message telling me how i might get more information. It is not necessary that these programs be running on the sri-ka or office machine (or for that matter on any arpa host). I will greatly appreciAte any help you can give me in locating these programs Randy Ivanciw Special Asst. to the Director Management Information Systems HQ DARCOM, U> S> Army 29-NOV-79 21:11:26-PST,1742;000000000001 Mail-from: MIT-ML rcvd at 28-Nov-79 2309-PST Date: 28 Nov 1979 2255-PST From: Geoff at SRI-KL (Geoff Goodfellow) Subject: MSGGROUP#1395 System Stories Wanted. To: msggroup at ML cc: bboard at SCORE, bboard at SAIL, bboard at CMUA, cc: bboard at UTAH-20, bboard at RUTGERS, *mac at AI, cc: morgan at WHARTON, dreifus at WHARTON, kirsner at WHARTON Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Date: 28 Nov 1979 2227-PST From: Neumann Subject: SYSTEM STORIES To: bboard SIGOPS-SIGSOFT ANECDOTAL HISTORY OF COMPUTER SYSTEMS. In connection with the forthcoming 7th Symposium on Operating Systems Principles at Asilomar CA (10-12 December 1979), we are collecting true stories on system (mis)behavior, e.g., that "surprises, baffles, spoofs, or even hoodwinks its designers and keepers." Humorous or socially relevant tales of system software are desired, pertaining to bugs, reliability, security, the human condition, social disasters, etc. A panel of distinguished experts is being assembled. The most interesting entries are expected to be published in the SIGOPS Operating Systems Review or in the SIGSOFT Software Engineering Notes, as appropriate. Your contribution should be sent to me (as coordinator). Try to send it in something by 7 December 1979, although later contributions will also be welcomed. [Please leave nose tone on-turned. In other words, sniff out all the good stories.] Peter G. Neumann, SRI International, L3004, Menlo Park CA 94025 Phone (415) 326-6200 ext. 2375 ------- Please send them to NEUMANN@SRI-KL. Anyone up for a diddy on DATE75 for starters? ------- 9-DEC-79 15:21:02-PST,1066;000000000001 Mail-from: MIT-ML rcvd at 7-Dec-79 0710-PST Date: 7 Dec 1979 0636-PST Sender: ROUNDS at OFFICE-1 Subject: MSGGROUP#1396 Any PERTs out there? From: William G. Martin To: msggroup at MIT-AI Message-ID: <[OFFICE-1] 7-Dec-79 06:36:03.ROUNDS> Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Gentlepeople: Does anybody know of any PERT or PERT-like systems running on any net hosts currently? We are looking for something that will take alphanumeric input and produce a simple graphic output, with (preferably) activities represented by lines with labels, and events by circles, numbered for reference. The current method of producing output is immaterial; while we would be particularily interested in systems that could use Tektronix-type graphic terminals or some kinds of plotters for output, we may be able to procure any specialized equipment required for a particular system. Thanks for your assistance. Will Martin (Replies to ROUNDS at OFFICE-1) 9-DEC-79 15:21:02-PST,1530;000000000001 Mail-from: MIT-ML rcvd at 8-Dec-79 0154-PST Date: 8 DEC 1979 0445-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP#1397 Stone-wall systems, again To: msggroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 I just found myself needing to get a file off of SRI-KL. SRI-KL is running a funny system version for a few days for testing. It appears that the account I use doesn't work. It wasn't running an FTP server so I couldn't just get the file with it, nor could I send net mail. It wasn't running an RSEXEC server so I couldn't contact anyone through a network link. If it were really down, I couldn't complain. Any system can be down. But the damned thing was up enough to let me connect, up enough to let me try to log in. It just didn't, BY POLICY, allow me to communicate with any human being. The assumption is, anyone without an account is an unperson and receives a deaf ear from a moronic machine with NO APPEAL to any intelligent being. To add to the above, this is one of the few times I have ever had a deadline to work against. It is approximately right now. 24 hours from now will certainly be too late! The general attitude has usually been that a problem that only requires a day or a few days' delay can't be too important. Here is the (not very surprising) counterexample. But even when it isn't a complete screw as it is now, it is immensely frustrating. 9-DEC-79 15:21:02-PST,1169;000000000001 Mail-from: MIT-ML rcvd at 8-Dec-79 1028-PST Date: 8 Dec 1979 1012-PST From: Stuart McLure Cracraft Subject: MSGGROUP#1398 Re: Stone-wall systems, again To: RMS at MIT-AI, msggroup at MIT-ML In-reply-to: Your message of 8-Dec-79 0145-PST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 We are attempting to bring up release 3 and have set testing times for running 3 during the week. During those times, no FTPSER runs since people would lose mail. No RSEXEC runs because no one has gotten around to it. Also, you would not have found the file you were looking for since the file system from the default OS was not dumped to this one. We needed to keep the ARPANET connection up for debugging of net network code in our monitor. Didn't you see the login message saying that it was an experimental system?? Our policy will continue to enable remote SEND's and RSEXEC-links by default. Many TOPS-20 sites are not even this open. Please, before you criticize on the grounds of lack of openess and ITS-like atmosphere, get the facts. ------- 9-DEC-79 15:21:02-PST,1411;000000000001 Mail-from: MIT-ML rcvd at 8-Dec-79 2302-PST Date: 8 Dec 1979 2239-PST From: Meyers at SRI-KL (Harris A. Meyers) Subject: MSGGROUP#1399 Re: Stone-wall systems, again To: RMS at MIT-AI, msggroup at MIT-ML In-reply-to: Your message of 8-Dec-79 0145-PST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 sorry, if you were inconvenienced, however you might talk to us before making a fool of yourself by flaming at the world. What you encountered was one of 2 schedeuled software down times per week. The reason you did not have an account was that we were not running on the production disks, and only had accounts for people who had requested them on the test packs, this has been anounced several times on system messages. We pupposly do were not running RSEXEC or FTPSER because of the different file system (what you wanted would not have been there anyway)>. There were several ways oyou could have communicated with people, but this is not the time to explain the phone system to you, sufice it to say that I had a message up that you saw when you telneted to the system saying what was happening, & asking you to send me mail to me under the production system if you had any questions, or problems ( the production system came back up around 4:30, and scheduled back ap at 6:00). harris ------- 9-DEC-79 15:21:03-PST,680;000000000001 Mail-from: MIT-ML rcvd at 9-Dec-79 0205-PST Date: 9 DEC 1979 0151-PST From: ESTEFFERUD at USC-ECL Subject: MSGGROUP#1400 Re: Stone-wall systems, again To: Meyers at SRI-KL, RMS at MIT-AI, msggroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 In response to the message sent 8 Dec 1979 2239-PST from Meyers@SRI-KL OK, let it be henceforth agreed that messages on such topics do not belong in MsgGroup for the obvious reason that they deal with personal frustrations with problems that have absolutely nothing to do with mail or message services. Best - Stef -------