10-MAY-78 22:12:10-PDT,6117;000000000001 Reader-Id: 37 Date: 5 MAR 76 1526-PST From: STEFFERUD at USC-ISI Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 301 GENERAL Ballot Comments To: [ISI]Mailing.List: Message-Id: <[USC-ISI]5-MAR-76 15:26:41-PST.STEFFERUD> This message contains general comments collected from MsgGroup Ballots on Basic Command Names. These comments do not make easy reading, but they do convey some important concepts and issues. The comments are unchanged from the original, except for formatting, and extraction from their ballot contexts. * * * * * * * * * * * * I SUGGEST THAT IT MIGHT BE FRUITFUL TO SOLICIT A SPECIAL VOTE TO DEFINE . THERE IS MUCH IMPLIED THERE. DO WE REALLY MEAN "MESSAGE" OR ARE WE TALKING ABOUT OBJECTS WE CAN POINT TO IN GENERAL? DOES THIS REALLY GET US INTO DISCUSSION OF A COMMAND STRUCTURE OF "VERB - NOUN - OBJECT"? * * * * * * * * * * * * With respect to editors: with non-computer personnel, or those with limited time to learn and explore new systems, it is desirable to maximize positive learning transfer. If 99% of our users here use SOS, an SOS-like editor is far more appropriate than any other kind. If 99% of ISI users use XED, analogously for them. I do not care to learn more than one editor at a time if at all possible, because my experience has shown that the negative learning transfer can be disastrous. I cite an example from personal experience: I once worked on another editor while I was using SOS. In SOS, "D" means "delete" and "P" means print. In the other editor, "D" meant "display" and "P" meant "purge". The results were as you might expect. Therefore, if we must specify an editor, the common subset editor must be suitable for use on a half-duplex system and must use full command names (only!). If any site chooses to use command abbreviations, command completion, full duplex (SOS or TENEX-like) editing, etc., these must be considered *extensions* of the basic editing capabilities, and may be specified in the user profile. It must be understood that such systems are non-standard, however, and the extensions must not be the defaults. * * * * * * * * * * * * The purpose of the core system should be to provide Sndmsg- Readmail facilities PLUS a taste of the better things in life. By providing the hint of other, interesting features we are likely to get better user response about what they need and want as opposed to user adaption of what is available to what they need. Standard extentions to the core system should be clearly specified. To me the core system defines the minimal system we wish to pass judgment upon. There are obvious extentions (Reply, Forward, etc) which should be uniform across the arpanet--but not required for the core system. Standard editing features are crucial!!!!!!!! * * * * * * * * * * * * I do not feel that command completion is a side issue. I cannot find a copy of my comments on TENEX-biased mail systems, so I presume that I sent it and you have received it. However, I will briefly summarize: If this protocol is truly to be network- universal, then it should be as independent of operating-system bias as possible. Therefore, the "common subset" commands should assume that they must be spelled out in their entirety, or to uniqueness. The editing of lines should be left to the individual operating systems. To speak blithely of control-A or control-W is meaningless if I am sitting at a 2741 connected to a 360 (half duplex!). I may choose to implement TECO, XED, SOS, or my favorite editor as a subsystem. The best the common subset can specify is that there be some operation which performs character deletion during composition (^A, ^H, rubout, backspace), line deletion during composition, etc. But most of these operations are implemented at interrupt level in the host operating system and cannot be easily changed. I have even worked on a system in which the line delete (control-U, for TOPS-10 hackers), character delete (rubout, ^H), and break-on-line-feed were implemented in a hardware multiplexer box. How command completion, ^A, ^W, etc. could ever be applied to such a case I cannot tell. * * * * * * * * * * * * As I understood the original question, you were asking only about named commands . (not about control z and the like). Therefore, Yes, I am in agreement on al items in the ballot, except the ____ * * * * * * * * * * * * We need to vote on two further issues: the standardization of msg sequence specification methods, and the standardization of control sequences for input and editing purposes. In regards to the latter, what we need to do is to spec out a standard set of control sequences like "retype line", "end of FIELD: input", "delete line", "delete last word", etc., and say how they fit into the command set. Then, the individual system implementors could map certain control chars into these functions (or, e.g., on a 370 or half-duplex terminal, the sequence . could be specified to mean "end of FIELD: input", etc.) * * * * * * * * * * * * I strongly disagree with any assumption that "normal ^A, ^W, ^R, ^S" commands are available in mail editors. In particular, the only one I even have the vaguest idea about is ^A, which is character delete. There are lots of computers out in the world that do not run TENEX, and some that cannot even run full-duplex devices. Therefore, some culture-independent way of expressing these concepts should be adopted. Almost no system beyond TENEX allows full-duplex interpretation of every character, with good reason: it's expensive. Such assumptions should not be any part of the proposal. * * * * * * * * * * * * Have Print, Delete, Undelete, File, default to the "Current Sequence", not the "Current Message". Call the Current Message ".", then it's quite easy to refer to it explicitly in these commands. Have the current sequence be "Recent", but also user settable. ------- 10-MAY-78 22:12:11-PDT,2205;000000000001 Mail from USC-ISI rcvd at 6-MAR-76 0102-PST Date: 6 MAR 1976 0042-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 302 Recently Processed Messages From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]6-MAR-76 00:42:36-PST.STEFFERUD> Special-Handling: The following Messages have been processed into Special-Handling: [ISI] TRANSACTIONS.MSG, and into Special-Handling: PROCEEDINGS.MSG; Ballot related messages are Special-Handling: being accumulated into PROCEEDINGS.BALLOT so Special-Handling: you can FTP them easily. /Stef -- Messages from file: [USC-ISI]TRANSACTIONS.MSG;6 -- SATURDAY, MARCH 6, 1976 00:30:15-PST -- 292 13 FEB STEFFERUD at USC-ISI MSGGROUP# 292 [PBaran on ballots and things] (3351 chrs) 293 13 FEB STEFFERUD at USC-ISI MSGGROUP# 293 Recent msgGroup Proceedings (2926 chrs) 294 4 MAR STEFFERUD at USC-ISI MSGGROUP# 294 Vote Tabulation (3166 chrs) 295 4 MAR STEFFERUD at USC-ISI MSGGROUP# 295 "FIELDS"/SEND: Ballot Comments (3150 chrs) 296 4 MAR STEFFERUD at USC-ISI MSGGROUP# 296 COMPOSE/REPLY/FORWAR D/RESEND: Ballot Comments (6001 chrs) 297 4 MAR STEFFERUD at USC-ISI MSGGROUP# 297 QUIT/DELETE/UNDELETE /CLEANUP: Ballot Comments (4786 chrs) 298 5 MAR STEFFERUD at USC-ISI MSGGROUP# 298 GET/FILE: Ballot Comments (2936 chrs) 299 5 MAR To:[ISI]Mai MSGGROUP# 299 PRINT/NEXT/SUMMARIZE : Ballot Comments (5586 chrs) 300 5 MAR To:[ISI]Mai MSGGROUP# 300 [GROBSTEIN at OFFICE-1: ballot tabulation message error] (1345 chrs) 301 5 MAR To:[ISI]Mai MSGGROUP# 301 GENERAL Ballot Comments (6117 chrs) ------- 10-MAY-78 22:12:12-PDT,1658;000000000001 Mail from USC-ISI rcvd at 16-MAR-76 1303-PST Date: 16 MAR 1976 1207-PST Sender: AMC at USC-ISI Subject: MSGGROUP# 303 Forwarding a message without inclosures From: UHLIG@OFFICE-1 To: [ISI]Mailing.List: Message-ID: <[USC-ISI]16-MAR-76 12:07:26-PST.AMC> I have been keenly aware of the lack of an ability to easily forward only my comments (i.e. send a message without the inclosures) during the last several days. I often receive messages which I forward to others on my staff or elsewhere in the command for action. Usually I want the people on the original to and cc list to see the comments I am sending along with the forwarded message. But I hate to dump another copy of the original message in their directory when they already have the original. (Sometimes the original is quite long). My only recourse now is to send two messages. The first one just contains my comments and tells those who didn't receive the original that it is being forwarded to them. The second message is the forwarded message. This is a very common problem in any office, and I think the mechanism to do this should be incorporated into an extension of the forward command, to send only the added comments to the people on the original list of to and cc addressees. (This is obviously not in the "primitive" set of commands). (This is also obviously easier to implement, in some sense of the word easy, with a central cache of messages, but I don't think that is sufficient reason to be for or against a central cache). Ron Uhlig ------- 10-MAY-78 22:12:12-PDT,2493;000000000001 Mail from USC-ISI rcvd at 16-MAR-76 1303-PST Date: 16 MAR 1976 1148-PST Sender: AMC at USC-ISI Subject: MSGGROUP# 304 Comment on the set of ballot comments From: UHLIG@OFFICE-1 To: [ISI]Mailing.List: Message-ID: <[USC-ISI]16-MAR-76 11:48:18-PST.AMC> In reading the set of messages containing ballot comments sent out by Stef, I noticed an interesting phenomenon. Quite frequently comments appeared like "that's something you TENEX guys do, but you don't do things that way on our machine". (Since Stef stripped all the names off, I feel comfortable in discussing this, without stepping on anybody's toes). I believe that is a very dangerous direction for the MSGGROUP discussion to go. One of my most frequent problems in dealing with Army scientists who need a new computer (my principle job) is to get them to state their requirements instead of what they think they can run on machine x. They often initially understate their requirements by large factors (like 3 to 10 times under what they really need). I fear the ballot comments had that same orientation. There was a flavor of fitting message systems to machines rather than discussing what message system users really need, and then worrying about what hardware to use in meeting those requirements. An example is in the area of the "DELETE" command, where there were some comments to the effect that the "CLEANUP" function is peculiar to TENEX machines, and, by implication, must not really be needed. Someone said why don't you just file things in a wastebasket file. That may, in fact, be a good answer. We have found in DARCOM (formerly Army Material Command or AMC) that protective mechanisms like having to delete and then expunge are good for our set of very naive users. I don't really care whether those mechanisms are supported in the operating system of the machine or in the message system applications programming. However, I do need such mechanisms. I think we all need to be very careful to not let the particular machine or machines used to implement a message system take on more importance than the user needs. That's long enough on my soapbox for now. I would be interested to know whether others feel the same as I do about some of those comments, or whether I'm "seeing things that aren't really there". Ron Uhlig ------- 10-MAY-78 22:12:12-PDT,1281;000000000001 Mail from USC-ISI rcvd at 20-MAR-76 1733-PST Date: 20 MAR 1976 1726-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 305 [TASKER at USC-ISI: (Vote Tabulation)] From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]20-MAR-76 17:26:24-PST.STEFFERUD> I think Pete Tasker has an important point here. Clearly we are not in agreement as to the "person" of the message handler. Is it first, second, third, or whatever???? Stef Begin forwarded message -------------------- Mail from USC-ISI rcvd at 15-MAR-76 1712-PST Date: 15 MAR 1976 1702-PST Sender: TASKER at USC-ISI Subject: (Vote Tabulation) From: TASKER at USC-ISI To: STEFFERUD Cc: FARBER, Cc: GOODWIN Message-ID: <[USC-ISI]15-MAR-76 17:02:22-PST.TASKER> In-Reply-To: <[USC-ISI]4-MAR-76 13:08:30-PST.STEFFERUD> Stef: It occurs to me that we have one big issue to resolve before a next vote: Should message system commands for a novice user be from the perspective of doing something oneself ("read message") or from the perspective of asking the computer to do it for you ("print message")? What do the human factors experts say? -Pete ------- -------------------- End forwarded message ------- 10-MAY-78 22:12:12-PDT,546;000000000001 Mail from USC-ISI rcvd at 24-MAR-76 1404-PST Date: 24 MAR 1976 1344-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 306 ADD mlw@RAND-ISD to MsgGroup From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Cc: mlw at RAND-ISD Message-ID: <[USC-ISI]24-MAR-76 13:44:57-PST.STEFFERUD> Welcome to Mike Wahrman (mlw@RAND-ISD) who is joining MsgGroup. Please add to your MsgGroup Mailing.List, or get a new copy from [ISI]MAILING.LIST;51. I will forward a copy to those who request it. Enjoy, Stef ------- 10-MAY-78 22:12:12-PDT,1046;000000000001 Mail from SRI-AI rcvd at 24-MAR-76 1523-PST Date: 24 MAR 1976 1524-PST From: Geoff at SRI-AI Subject: MSGGROUP# 307 ( Forwarded Mail ) Mail monitoring by Rand Corp. management To: NETWORK-LIAISON-GROUP: cc: [ISI]Mailing.List: Mail from RAND-ISD rcvd at 23-MAR-76 1159-PST Date: 23 Mar 1976 at 1156-PST From: jal at RAND-ISD Subject: Mail monitoring by Rand Corp. management To: hackers: This is to inform the network hackers that the Rand Corporation management has implemented a monitoring policy on incoming and outgoing arpanet mail communications with foreign sites. Starting yesterday, all arpanet mail to rand-rcc or rand-isd will be copied and sent to the correspondence desk (as is the case with U.S. mail). Mail going out from rand-rcc and rand-isd to other sites will be similarly copied and monitored by correspondence. I am sorry to be the bearer of this news. ------- i am fowarding this message on behalf of john lowry (jal), systems manager, rand-isd unix system. [geoff] ------- 10-MAY-78 22:12:12-PDT,676;000000000001 Mail from USC-ISI rcvd at 24-MAR-76 1612-PST Date: 24 MAR 1976 1601-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 308 (( Forwarded Mail )) From: STEFFERUD at USC-ISI To: Geoff at SRI-AI Cc: jal at RAND-ISD, Cc: [ISI]Mailing.List: Message-ID: <[USC-ISI]24-MAR-76 16:01:07-PST.STEFFERUD> In-Reply-To: Your message of MARCH 24, 1976 Hi Geoff, I am more curious as to the content of the policy and procedures used by RAND than I am sorry to see it happen. Since we all may have reason to want to understand what this means to our various activites, do you suppose we could get someone at RAND to speak for RAND? Best, Stef ------- 10-MAY-78 22:12:12-PDT,1115;000000000001 Mail from USC-ISI rcvd at 3-APR-76 1848-PST Date: 3 APR 1976 1834-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 309 Adding KLH@MIT-AI (Ken) Subject: [KLH at MIT-AI: MSGGROUP] From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]3-APR-76 18:34:41-PST.STEFFERUD> Please add KLH@MIT-AI to your MsgGroup member lists or abtain a new list from [ISI]Mailing.List;55. Stef Begin forwarded message -------------------- Mail from MIT-AI rcvd at 3-APR-76 1321-PST Date: 3 APR 1976 1619-EST From: KLH at MIT-AI Subject: MSGGROUP To: stefferud at USC-ISI From what I gather by looking through a few of the files, you are the person to check with about putting my name on the mailing list. I haven't finished reading what I've got yet, but it looks as though I ought to keep up on whatever is transpiring; I implemented and am responsible for the common mail system running on MIT-AI, MIT-ML, and MIT-MC. Hope to hear from you shortly... Ken ------- -------------------- End forwarded message ------- 10-MAY-78 22:12:13-PDT,5939;000000000001 Mail from USC-ISI rcvd at 5-APR-76 2252-PST Date: 5 APR 1976 2222-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 310 [Vezza: Command Language Structure, DELETE, FORWARD, SUMMARIZE] From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]5-APR-76 22:22:52-PST.STEFFERUD> Special-Handling: This message is somewhat delayed, but it is Special-Handling: still very relevant and useful in our Special-Handling: discussion of message systems. Stef GENERAL COMMENTS: I have some difficulty accepting the names of the common "primitive commands" that must exist in all message systems, whether they be unsophisticated ones or not or somewhere in between. As I understand it, they are to serve several purposes, two of them being: 1. To allow a user to use any one of the message systems without the need of learning different conventions. 2. To provide a common set of commands that will ease the transition process of users graduating from a simple to a more sophisticated message system. To satisfy the above two purposes, the basic common "primitive command" set must behave exactly the same in each system. * * * * * * * * * * * * COMMENTS ON DELETE: I learned that in those message systems offering an integrated on-line filing system, the "DELETE" command should delete the message(s) from the on-line filing system as well as the "cache" or "MESSAGE.TXT" file or whatever it is called. Herein lies the difficulty. DELETE means different things in different message systems. For instance, in MSG it means delete from the MESSAGE.TXT, in MSGDMS it means delete from the on-line data base. Thus, the user must be consciously aware of what system he is using because DELETE in MSG will delete the message(s) from MESSAGE.TXT and in other systems from the on-line data base. Thus DELETE doesn't perform the same function in both systems. Of course there are many aguments that a person who uses two systems should be sophisticated enough to know the difference. However, I can't buy them, because they lay a hidden trap for persons who think they are sophisticated enough but, mentally slip unknowingly. A scenario might be someone thinking they are in MSG but really in MSGDMS saying delete and then wondering and complaining about why the daemon didn't file that message. The situation for a user who is graduating to a more sophisticated system is equally as bad. He has learned that DELETE means delete from MESSAGE.TXT and he has the Pavlovian conditioning for that action. He is then told all about something called a daemon that will file messages for him automatically. He sets the daemon to work but continues with his ingrained habits. The last comment on the subject of DELETE, DELETE is a computer word when applied to objects such as messages. In non- computer type offices -- where computers aren't used on a daily basis -- one "deletes words" from a paragraph but one doesn't "delete" letters or memos from a file. The words used instead are "pull and discard," "discard" or "remove." There are probably others. Having discovered the problem one thinks that maybe there is a simple solution. Unfortunately, there isn't because the actions "DELETE" in MSG and MSGDMS are not isomorphic. That being the case, my complaint is really reduced to the usurption of the word "delete" which will be wasted on naive users anyway. It might be better to teach the user to say "FILE" and explain that because he is not yet allowed filing cabinets it winds up in the circular file. The introduction of the action and concept of "DELETE" can be left for a later time. Either that, or MSGDMS and similar systems will be forced to adopt the two level "DELETE" and "EXPUNGE" technique that currently MSGDMS is using and is so widely criticized. * * * * * * * * * * * * COMMENTS ON FORWARD: The second term I have difficulty with is the "FORWARD" command. Forward means to pass something on from an intermediate point. In the normal sense, one's mail is forwarded when mail is sent to an old address. Forwarding does not mean distributing it to new people. In an office, if a recipient of a letter or memo wishes others to see it, he attaches a distribution list to it and SENDS it to the the people on distribution list. So why not use the word SEND or SEND.MESSAGE. The composing systems MSG, HERMES and MSGDMS can easily determine if this is an additional distribution of an existing message or whether or not it means send this new message I have composed, and treat each accordingly. * * * * * * * * * * * * COMMENTS ON SUMMARIZE SUMMARIZE also seems to me to be slightly missleading for it conveys the idea that an intellegent function of some sort is taking place. Of course it is not, at least not at this time. summarize means "to make a summary of." The action that is realy taking place is the printing or listing of some information about messages. Furthermore what is really being printed is a list of message subjects (or the begining of them anyway), senders, and other ancillary information. It is a list of summaries of messages only in the sense that a subject or part of one is a summary. Therefore I suggest "LIST.SUMMARIES" (only because "PRINT.SUMMARIES" conflicts with "PRINT.MESSAGE"). If someone could find a better word than summary I would even be happier. * * * * * * * * * * * * COMMENT ON COMMAND LANGUAGE STRUCTURE: Obviously I agree with Watson about two or more word command names. Especially so if consoles that people use get faster which they will. Originated by Al Vezza (Vezza@MIT-DMS) Edited by Einar Stefferud (Stefferud@ISI) ------- 10-MAY-78 22:12:13-PDT,1712;000000000001 Mail from MIT-AI rcvd at 7-APR-76 0245-PST This mail mis-addressed to [ISI]MAILING.LIST Date: 7 APR 1976 0544-EST From: KLH at MIT-AI Subject: MSGGROUP# 311 Self-introduction To: [ISI]Mailing.List at USC-ISI At Stef's request I am sending a note that includes my "real" name as well as a little more background... NIC Ident "KLH2" => Ken Harrenstien, KLH @ MIT-AI. I'm a MIT student, at least until June, and have for the past two years been responsible for the design, implementation, and maintenance of the programs comprising our mail system. I would probably qualify as a network hacker... The "mail system" I refer to is a first-generation effort which was mostly directed at providing sending capabilities; it consists of a demon-style job (COMSAT - communications satellite) through which everything is routed, plus a user-run program (MAIL/QMAIL) for composing messages. Handling of received messages can be done by the RMAIL program, actually an ITS TECO loaded with sophisticated macros. The latter was written by Richard Stallman (RMS @ MIT-AI), who may be joining the group shortly. This system currently runs on the 3 ITS sites of MIT-AI, MIT-ML, and MIT-MC. Whereas MIT-DMS is also an ITS system, their message handling programs are not likely to be used, for various good reasons. For the time being, I will just sit back digesting the transactions thus far. It is something of a pity that there is not a short description list to go with the mailing list, so that I could get a feel for the proportion of users/managers/hackers, as well as immediately seeing whom to ask about a specific subject... --Ken ------- ------- 10-MAY-78 22:12:13-PDT,886;000000000001 Mail from MIT-AI rcvd at 7-APR-76 2256-PST Date: 8 APR 1976 0155-EST From: RMS at MIT-AI Subject: MSGGROUP# 312 REQUEST FOR MEMBERSHIP (RMS@MIT-AI) To: msggroup at USC-ISI 1) I would like to enter your mailing list. 2) On the subject of mail systems, can't there be set up a name which when mailed to automatically forwards to all the people on the mailing list? ITS has that feature, and I have heard that TENEX is getting it. It would be much more convenient than copying the file to ones own machine. 3) I maintain this system's mail reader, called RMAIL. It is designed for display consoles, unlike most. It is documented in the file .INFO.;RMAIL ORDER on this machine (I guarantee you will be surprised to find out what language it's written in). Our FTP server does not expect you to log in; our system is not paranoid the way most systems are. ------- 10-MAY-78 22:12:13-PDT,880;000000000001 Mail from MIT-AI rcvd at 8-APR-76 0651-PST Date: 8 APR 1976 0949-EST From: KLH at MIT-AI Subject: MSGGROUP# 313 Slight misunderstanding To: msggroup at USC-ISI Whoops! A couple of people have already asked me if I meant, in my introductory message, that MSGDMS was not useful in general... nothing of the sort! I was only referring to the possibility of its use on our 3 other ITS systems. It seemed to me that some people might assume, because we and MIT-DMS use the same operating system, that we naturally have or will use MSGDMS, and I wished to inform them that we don't and probably won't. Sorry if it sounded bigger than that. Explaining why would get into implementation and system details that the MsgGroup may or may not be interested in-- from what I've read most people are concerned with what users see on their terminal. --Ken ------- 10-MAY-78 22:12:13-PDT,1614;000000000001 Mail from USC-ISI rcvd at 8-APR-76 1202-PST Date: 8 APR 1976 1110-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 314 Welcome Richard Stallman (RMS@MIT-AI) From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]8-APR-76 11:10:25-PST.STEFFERUD> Please add RMS@MIT-AI (Richard Stallman) to your MsgGroup mailing list, or obtain a new copy form [ISI]Mailing.List;56. Richard and Ken Harrenstien (KLH@MIT-AI) have been perusing the MsgGroup Proceedings and have raised a number of issues that I think are well worth discussion. So, Welcome to MsgGroup. Enjoy. See you in the discussions, Stef Begin forwarded message -------------------- Mail from MIT-AI rcvd at 7-APR-76 2256-PST Date: 8 APR 1976 0155-EST From: RMS at MIT-AI To: msggroup at USC-ISI 1) I would like to enter your mailing list. 2) On the subject of mail systems, can't there be set up a name which when mailed to automatically forwards to all the people on the mailing list? ITS has that feature, and I have heard that TENEX is getting it. It would be much more convenient than copying the file to ones own machine. 3) I maintain this system's mail reader, called RMAIL. It is designed for display consoles, unlike most. It is documented in the file .INFO.;RMAIL ORDER on this machine (I guarantee you will be surprised to find out what language it's written in). Our FTP server does not expect you to log in; our system is not paranoid the way most systems are. ------- -------------------- End forwarded message ------- 10-MAY-78 22:12:13-PDT,6591;000000000001 Mail from OFFICE-1 rcvd at 12-APR-76 0744-PST Date: 12 APR 1976 0721-PST From: PANKO at OFFICE-1 Subject: MSGGROUP# 315 Computer Message Services--summary of a draft paper (longish) To: [ISI]Mailing.List: < PANKO, SUMMARY.NLS;2, >, 12-APR-76 07:17 RA3Y ;;;; The following is the summary from a draft paper entitled "The Outlook for Computer Message Services: a Preliminary Assessment." Please let me know if you would like a draft copy to review (or just peruse). Since the paper is still somewhat drafty, please don't quote any of these numbers without checking back with me. The Non-Medical Use of Drugs Directorate in Canada began using a computer for its internal communication in late 1974. During its first six months on the system, NMUD's 92 staff members sent 20,800 messages, at an average price of about $1.50 per message. The Directorate is very happy with this instant communication medium, whose terminals are so inexpensive that they can be carried around by staff members on the road..F="Draft for Comment .Split; Summary"; The Directorate is not the only user of "computer message service." Other users of computer-based communication systems include the U.S. Geological Survey, the Office of Telecommunications of the Department of Commerce, Gulf Oil, the National Security Agency, Stanford Research Institute, the Business Planning Group of Bell Canada, and a host of other commercial and governmental groups. Some organizations, in fact, have been using computer message services (CMS) for more than a decade. Today, almost any organization that wishes to use CMS can choose among a number of software packages for their in-house computers, or among a number of message services on national and international computer networks. Even at current prices -- $0.75 to $1.75 per message on most systems -- computer preparation and delivery may be cost-competitive with inter-office and postal delivery. Furthermore, CMS prices could fall to between $0.25 and $0.65 within a year; by and 1985, conservative cost projection indicates that prices will fall to between 15 and 30 cents per message. At those prices, most organizational mail is likely to flow by computer rather than by mail-carrier. Although our cost projections are preliminary, it is hard to escape the feeling that a communication revolution of unparalleled scale is about to unfold. Proliferation of computer message services could raise a number of sticky policy issues. For example, the Federal Communications Commission has already asserted authority over computer "message switching." But the extent of its authority is unclear, and its aegis over "electronic mail" may be challenged by the U.S. Postal Service. It even seems to be an open question whether any existing agency should be allowed to control computer message services, or even whether extensive regulation would promote or stymie the emergence of a healthy national communication. In other nations, the British Post Office has already taken official action against computer message services, specifically against users of the TYMNET and the ARPANET; the Canadian Department of Communication is now conducting policy-related research on computer message services. The effect that policy decisions of other nations could have on the development of computer message services in the U.S. is unknown. Record communication already constitutes a large fraction of international telecommunications traffic. For example, the Canadian international carrier, TELEGLOBE, obtains 20 percent of its revenues from Telex traffic. Other carriers are believed to obtain similar percentages of their total traffic from teletype services. If computer message services could displace current Telex services, the development of international agreements on computer message service should be given high priority, but may become difficult to interconnect the message services of different nations if radically different courses of action are taken in the regulation of computer message services. A major question that should guide policy makers is whether a national system of computer-based human communication -- incorporating not only computer mail and computer conferencing but also electronic funds transfer, document and correspondence control and other tools to support the diverse forms of communication that take place in organizations -- is to be created, or whether a fragmented message service industry -- offering computer mail, computer teleconferencing and other services as separate and fragmented tools -- is to be allowed or encouraged to exist. Particularly if office automation is to be a key to the future growth of productivity in the United States, whether or not regulators take an integrated view of computer message services may have repercussions far beyond affected communication industries. In the past, CMS has been an invisible industry. Usage has generally gone unreported, often because of concerns over uncertain FCC responses. Regulatory agencies, in turn, have generally been ignorant of computer message services or have been unwilling to become involved until a clearer picture of CMS emerges. While benign neglect has probably been beneficial in the past, it remains to be seen whether a potentially key communication medium can mature into a coherent national communication system without oversight or whether the continuing lack of information flows caused by past regulatory actions is in the public interest. But the theoretical question of whether or not government SHOULD get involved is rapidly becomming moot. Walter Hinchman, chief of the FCC's Common Carrier Bureau, has recently announced that the Commission is preparing to re-open the Computer Inquiry. By late 1976, computer message services are likely to lose most of their invisibility. This paper is a limited incursion into the area of computer message services. It merely surveys costs, market potential and the general regulatory picture, in order to show that a large and potentially policy-laden medium appears to be emerging. It does not probe these areas deeply, much less consider the broader questions of what impacts computer message services will have on organizations and the general public if they are or are not allowed to develop rationally. ------- 10-MAY-78 22:12:14-PDT,607;000000000001 Mail from OFFICE-1 rcvd at 15-APR-76 0808-PST Date: 15 APR 1976 0746-PST From: PANKO at OFFICE-1 Subject: MSGGROUP# 316 Delays in Responding to Requests for Summaries To: [ISI]Mailing.List: Fellow Message Service Groupies, I have literally been deluged with requests for copies of my paper on computer message services, and it may take me a week or two to get the extra copies that I need printed up. I will respond as rapidly as possible. P.S., the document is about 90 pages long, so FTP isn't very feasible. Raymond R. "Ra3y" Panko Stanford Research Institute ------- 10-MAY-78 22:12:14-PDT,722;000000000001 Mail from OFFICE-1 rcvd at 20-APR-76 2116-PST Date: 20 APR 1976 2106-PST From: PANKO at OFFICE-1 Subject: MSGGROUP# 317 Another FCC Computer Inquiry To: [ISI]Mailing.List: Sometime in the next three to six months, the FCC is planning to reopen the Computer Inquiry. In the last Inquiry, which ended in 1972, the Commission asserted jurisdiction over for-hire computer message switching. It required that all for-hire message services be treated as common carrier services. That means tarrifing and other fun things. It is far from clear what the FCC will be focusing on this time, but the results of this new Inquiry may have long-lived consequences for all computer mail systems. ------- 10-MAY-78 22:12:14-PDT,728;000000000001 Mail from MIT-AI rcvd at 29-APR-76 1821-PDT Date: 29 APR 1976 2112-EST From: RMS at MIT-AI Subject: MSGGROUP# 318 CHECK To: MsgGroup@USC-ISI On most systems there is nothing to prevent a user from patching the mail-reading program so that it will not send a receipt. If that were difficult, he could always print out his mailbox with a "print file" command. Undoubtedly, if any number of users wished to be able to avoid sending receipts, there would begin to circulate an alternate version of the mail-reading program, that asked the user before sending one. That could be prevented only by including excruciating protection mechanisms in the system, of the sort that make useful work impossible. ------- 10-MAY-78 22:12:14-PDT,1652;000000000001 Mail from MIT-AI rcvd at 30-APR-76 0537-PDT Date: 30 APR 1976 0817-EST From: KLH at MIT-AI Subject: MSGGROUP# 319 MIT-AI Mail Statistics for Jan-Feb-Mar 76 To: lisT.mailinG[Info Sci Ins]: COMSAT (the mailer running on MIT-AI, MIT-ML, and MIT-MC) keeps a statistics script file as it runs, and I have just crunched a number of these stat files. For first 3 months of 1976 (Jan/Feb/Mar - 91 days), the AI mailer processed 9925 messages which went out to 16359 recipients. That's roughly 180 messages sent per day. Other relevant values are: Avg rcpts/msg: 1.64 Variance: 2.74 Median: 1.0 63.3% msgs had only 1 rcpt. 91.4% had 2 or less. avg chars/msg: 446.0 Variance: 1.0E+27! Median: 198.0 (50% msgs were less than 198 chars) 80.7% were less than 500. 93.1% were less than 1000. [Note that the definition of message length here applies only to the length of the TEXT. The header is not taken into account. Also, the length figures apply to the 16359 messages output; those for the input are quite similar.] Other interesting numbers, such as the ratio of local/net messages, can also be derived with a speed roughly proportional to the demand for them. I don't however have precise CPU time figures; the most I can say is that for one 7-day benchmark the satellite used 0.3% of the KA-10's time. I think that before we can adequately visualize future services, we need to have some handle on the present type and volume of mail. These figures, and others like them, should help. Just remember that MIT-AI is not the same sort of facility as ISI... Enjoy, etc-- --Ken ------- 10-MAY-78 22:12:14-PDT,1947;000000000001 Mail from BBN-TENEXA rcvd at 4-MAY-76 1506-PDT Date: 4 May 1976 1115-EDT Sender: MYER at BBN-TENEXA Subject: MSGGROUP# 320 ((Comment on Panko's CHECK command)) From: MYER at BBN-TENEXA To: STEFFERUD at USC-ISI, To: PBaran at ISI Cc: HENDERSON, DODDS, RBRACHMAN, BURCHFIEL, Cc: [ISI]Mailing.List: Message-ID: <[BBN-TENEXA]4-May-76 11:15:27-EDT.MYER> In-Reply-To: <[USC-ISI]28-APR-76 12:22:42-PDT.STEFFERUD> The idea of this "return receipt" feature has popped up many times in discussions of automated message processing. We find ourselves thoroughly agreeing with Stef in his concern over potential invasion of privacy. My feeling is that properly controlled, the return receipt feature could be implemented without infringement of human rights. Let me offer two models: 1. The registered Mail Model. The postman offers me a registered letter, but to get it I've got to sign a receipt. If I sign the receipt, then the sender knows I got his letter. If I don't sign then I don't get the letter. In this first model, the sender insists that he know whether or not I received his letter. In a second more lenient scheme, the sender indicates his desire for a receipt but makes no demand for one. In this case it is entirely up to me, the receiver, whether I acknowledge him or not. The physical analogy of this situation is the return postcard that sometimes accompanies various types of standard invitations. If I'm feeling energetic and/or polite I will return "self-addressed stamped postcard" otherwise I'll probably chuck it along with the invitation. I believe that these and other similar receipting mechanisms could be implemented fairly straightforwardly in any of several message systems such as the BBN - Hermes system. I think the key issue as Stef points out is to avoid implementing features that would tend to infringe on the right to privacy. /Ted ------- 10-MAY-78 22:12:14-PDT,1551;000000000001 Mail from OFFICE-1 rcvd at 6-MAY-76 1624-PDT Date: 6 MAY 1976 1607-PDT From: PANKO at OFFICE-1 Subject: MSGGROUP# 321 An Electronic Want Ad To: [ISI]Mailing.List: < PANKO, WANT-AD.NLS;1, >, 6-MAY-76 15:52 RA3Y ;;;; As often happens in this business, my part of SRI is suffering some lean times, and I will probably be looking for a job around July 1. If you a potential job opening or could point me in a promising direction, I would be grateful. My paper on the outlook for computer message services, which many of you have read, indicates my current behavioral and economic interests. During my three years at SRI, I have worked on a number of other projects, including a survey of computer and verbal teleconferencing systems, a technology assessment of communication-travel interactions, and demand/economic studies of pay television and cable television. I also worked for Doug Engelbart at ARC for nine months. Academically, I have a Ph.D. in communication from Stanford, an M.B.A. with an organizational communication concentration from Seattle University, and a B.S. in physics from Seattle. My cumulative GPA is 3.95. My primary career goal is to understand and if possible improve human communication/collaboration. But the bulk of my past research has revolved around the cost, demand, regulatory and user behavior aspects of technology. Raymond R. Panko 808 Coleman Ave., #12 Menlo Park, CA 94025 work: (415) 326-6200, ext. 4213 home: (415) 323-9896 ------- 10-MAY-78 22:12:14-PDT,805;000000000001 Mail from RUTGERS-10 rcvd at 7-MAY-76 1138-PDT Date: 7 May 1976 (Friday) 1433-Est From: KOHANSKI at RUTGERS-10 Subject: MSGGROUP# 322 FAREWELL SPEECH TO THE TROOPS To: @MSGGRP.MAI[1,2] at RUTGERS-10: DEAR PEOPLE - I HAVE LISTENED TO MANY AN ARGUMENT RAGING AMONG THE MSGGROUP MEMBERS, AND SOME OF THEM HAVE EVEN BEEN MEANINGFUL. SOMETIMES I HAVE EVEN ADDED A WORD OR TWO, JUST TO FAN THE FLAMES. BUT, ALAS, SUCH ACTIVITIES MUST GO THE WAY OF ALL GOOD (?) THINGS, AS I AM TAKING MY FINAL BOW AND LEAVING THE RUTGERS STAGE FOR GREENER (AT LEAST IN THE GREENBACK SENSE) PASTURES. RUTGERS WILL CONTINUE TO SPEAK ITS MIND THROUGH DON ROBERTSON, WHO IS ALREADY ON THE DISTRIBUTION LIST. I WISH YOU ALL THE BEST OF LUCK AS YOU SEARCH FOR A MORE HUMANE (!?) MESSAGE SYSTEM. [DAN KOHANSKI] 10-MAY-78 22:12:15-PDT,1895;000000000001 Date: 13 May 1976 1712-PDT SENDER: ANONYMOUS Mail from USC-ISI rcvd at 13-MAY-76 1712-PDT From: An Interested Party Subject: MSGGROUP# 323 Mail Monitoring and Personal Mail To: [ISI]Mailing.List: Dear Message Group members: It has come to my attention that some high-ranking military officer has taken it upon himself to insure that ARPANet mail is used only for official purposes. Apparently, he warned the Principal Investigators that he would be monitoring network mail, and would crack down on obviously "chatty" mailings, e.g. poems about computer hacks, the latest snoopy posters, etc. I think his concern is justified. We all know of cases where net mail is abused in this way, and I think it's all our concern that any abuses be halted. Still, the idea of a "net mail monitor" (presumably clandestine) goes against the whole notion of a (practically) free-access information network. It's something like a boss who decides to bug the offices of his employees to crack down on chatting and overly-long coffee breaks. His desire is valid, but the method isn't -- you don't invade the privacy of everyone to catch the few offenders. Certainly, we all engage in "chatty" message, but most of our mail -- I feel that I can speak for most people using the network mail systems -- DOES concern our work, at least in part. Still, if I feel like sending Joe@Anysite a message asking him "what's up these days?", there is no harm to that! I'm sending this message anonymously, for obvious reasons -- our "monitor" will probably pick this up. I felt each of you ought to be aware of this seemingly unimportant -- but, I feel, extremely significant -- policy decision. I will confess that I am a member of the Message group (it hasn't come to a police state yet!), and I hope we can discuss this issue. A Concerned Citizen -------- 10-MAY-78 22:12:15-PDT,392;000000000001 Mail from USC-ISI rcvd at 14-MAY-76 0931-PDT Date: 14 MAY 1976 0904-PDT From: FARBER at USC-ISI Subject: MSGGROUP# 324 Welcome to MSGROUP -- Stock Gaines of RAND To: [ISI]Mailing.List: Stock Gaines of RAND Corp has been placed in the master mailing list of the MSGGROUP. Please update your local mailing lists to include him gaines@rand-isd Dave Farber ------- 10-MAY-78 22:12:15-PDT,2134;000000000001 Date: 20 MAY 1976 1350-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 325 [MsgGroup at USC-ISI: MSGGROUP# ONE: Welcome to MsgGroup] From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]20-MAY-76 13:50:07-PDT.STEFFERUD> Revised introductory message. Someone removed this message and the other introductory messages from [ISI]MESSAGE.TXT. We would appreciate it if no one would mess up our files in the future. Thank you, Stef Begin forwarded message -------------------- Mail from USC-ISI rcvd at 20-MAY-76 1212-PDT Date: 20 MAY 1976 1212-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# ONE: Welcome to MsgGroup From: MsgGroup at USC-ISI To: MSGGROUP Message-ID: <[USC-ISI]20-MAY-76 12:12:24-PDT.STEFFERUD> Special-Handling: DO NOT REMOVE FROM POSITION NUMBER ONE IN MESSAGE.TXT! Hi, Welcome to MsgGroup. The purpose of MsgGroup is to hold an informal teleconference on the subject of message systems, as they might be, as they should be, and how we can get there from where we are. We are keeping a complete transcript of all messages received at MsgGroup@ISI, but are separating the administative messages from the substantive content messages in order to compact the Proceedings. This message explains how to find out more about the msgGroup files and procedures, and how to join the group if you are so inclined. The next message (MSGGROUP# TWO) in [ISI]MESSAGE.TXT contains a description of our procedures for exchanging messages among MsgGroup members. The third message (MSGGROUP# THREE) in [ISI]MESSAGE.TXT explains about the PROCEEDINGS files and tells what is kept in them. If you are interested in joining the fray, send a message to MsgGroup@ISI, Stefferud@ISI, or Farber@ISI and we will add you to the mailing list. Best Regards, Stef and Dave PS: This message is to be kept as the first message in [ISI]MESSAGE.TXT for reading by strangers to MsgGroup. ------- -------------------- End forwarded message ------- 10-MAY-78 22:12:15-PDT,2940;000000000001 Mail from USC-ISI rcvd at 20-MAY-76 1455-PDT Date: 20 MAY 1976 1409-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 326 [MsgGroup at USC-ISI: MSGGROUP# THREE: Defined MsgGroup Files] From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]20-MAY-76 14:09:30-PDT.STEFFERUD> Begin forwarded message -------------------- Mail from USC-ISI rcvd at 20-MAY-76 1325-PDT Date: 20 MAY 1976 1325-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# THREE: Defined MsgGroup Files From: MsgGroup at USC-ISI To: MSGGROUP Message-ID: <[USC-ISI]20-MAY-76 13:25:22-PDT.STEFFERUD> Special-Handling: DO NOT REMOVE FROM POSITION NUMBER THREE IN MESSAGE.TXT! This message describes the procedures for handling messages in the "files-only" directory at ISIA. The following files are now defined and are accessible as "read-only-files:" [ISI]MESSAGE.TXT contains several introductory messages which describe the current procedures, which are followed by any recently arrived messages which have not been processed. [ISI]TRANSCRIPT.MSG contains the entire transcript of the MsgGroup proceedings to date, minus the unprocessed messages in MESSAGE.TXT. Each message in this file has been modified to insert a unique MsgGroup accession number (e.g MSGGROUP# nnn) at the beginning of its SUBJECT field. [ISI]PROCEEDINGS.MSG contains all substantive dialogue messages, but excludes administrative messages, etc. [ISI]PROCEEDINGS.SURVEY contains a SURVEY listing of all the Headers of messages in PROCEEDINGS.MSG to facilitate less expensive searching of the Proceedings. [ISI]MSGGROUP#.nnn files contain single long messages which are separated out for easy FTP access. "nnn" stands for the MsgGroup accession number assigned to all received messages. Notices of creation of these files will be sent to the members. [ISI]ADMINISTRATIVE.MSG contains only administrative messages. (e.g. new members, etc.) [ISI]MAILING.LIST contains the current network mailing list, which includes MSGGROUP@ISI so that copies will automatically be delivered there. [ISI]RECIPIENTS.MAILING-LIST contains the network addresses of MsgGroup members who wish to automatically receive a fresh copy of the MAILING.LIST each time it is revised. Future procedures for sorting and cross-referencing the messages and for archiving old messages (and retrieving them back) are being investigated. Your suggestions are welcome on any aspect of operations. Please send them TO: MSGGROUP@ISI, STEFFERUD@ISI. Best Regards, Stef PS: this message is intended to remain in position number three in [ISI]MESSAGE.TXT for reading by interested people. ------- -------------------- End forwarded message ------- 10-MAY-78 22:12:15-PDT,4065;000000000001 Mail from USC-ISI rcvd at 20-MAY-76 1456-PDT Date: 20 MAY 1976 1401-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 327 [MsgGroup at USC-ISI: MSGGROUP# TWO: MsgGroup Procedures] From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]20-MAY-76 14:01:59-PDT.STEFFERUD> Begin forwarded message -------------------- Mail from USC-ISI rcvd at 20-MAY-76 1313-PDT Date: 20 MAY 1976 1313-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# TWO: MsgGroup Procedures From: MsgGroup at USC-ISI To: MSGGROUP Message-ID: <[USC-ISI]20-MAY-76 13:13:31-PDT.STEFFERUD> Special-Handling: DO NOT REMOVE FROM POSITION NUMBER TWO IN MESSAGE.TXT! This message will tell you how to read the MsgGroup files and how to send dialogue messages to the group. You need not be a "Member" to read the files or to send dialoue messages to the group. Please do not modify any files without authorization from STEFFERUD@ISI! The next message, "MSGGROUP#.THREE: Defined Files" will explain more about the message handling procedures and the way the files are organized. READING [ISI]FILES If you have a Directory at ISIA, you can LOGIN to ISI and preceed all file references with the directory name to read the files. (e.g.filename.extension) If you do not have a Directory at ISIA, then FTP may be used to GET a copy of the files for perusal in your own directory. In FTP, you should LOGIN ANONYMOUS at ISIA with password ARPA to GET any Filename.Extension TO Filename.Extension (including TTY:). Unfortunately you cannot use any message handling system "through" FTP, but you can use MSG, MAILSYS or any other mail handling system on MSG files transfered via FTP to TENEX sites. Simple requests for copies of messages (addressed TO: MSGGROUP@ISI, STEFFERUD@ISI) will obtain Forwarded copies of the messages from the files. An MSG Listing of the headers in PROCEEDINGS.MSG is available upon request for the convenience of those who do not wish to use FTP. Send your request to MSGGROUP@ISI. FTP users will find this file in [ISI]PROCEEDINGS.SURVEY. ENTERING INTO THE MSGGROUP DIALOGUE There are two alternative methods for entering messages into the MsgGroup dialogue. 1. Send your message to [ISI]MAILING.LIST, which will deliver it to everyone, including a copy to MSGGROUP@ISI. Then individual recipients may discard their personal copy with the knowledge that a copy will be kept in [ISI]. 2. Send one copy of your message to MSGGROUP@ISI. You may want to then notify everyone in [ISI]MAILING.LIST of your contribution. Periodic notices of unannounced arrivals will be sent to MAILING.LIST. To assure prompt notice of your message, please send a copy of it to STEFFERUD@ISI. [ISI]MESSAGE.TXT will be monitored to process all messages into the transcript file, to answer and to remove administrative messages, and to move stuff to separate files as may become appropriate. Long messages (documents etc.) may be placed in separate MSG files to facilitate FTP access of single large documents. They will be placed in files named: MSGGROUP#.nnn to correspond to their assigned MsgGroup accession numbers. Future procedures for sorting and cross-referencing the messages and for archiving old messages (and retrieving them back) are being investigated. Your suggestions are welcome on any aspect of operations. Please send them TO: MSGGROUP@ISI, STEFFERUD@ISI. If you wish further assistance or more information, please request it by sending a message TO: MSGGROUP@ISI, STEFFERUD@ISI. Best Regards, Einar Stefferud PS: This message is intended to remain as message number two in [ISI]MESSAGE.TXT for reading by interested persons. ------- -------------------- End forwarded message ------- 10-MAY-78 22:12:15-PDT,1263;000000000001 Mail from OFFICE-1 rcvd at 28-MAY-76 0952-PDT Date: 28 MAY 1976 0938-PDT From: PANKO at OFFICE-1 Subject: MSGGROUP# 328 A Computer Teleconference on Resources and Regulation: a Solicitation for Participants To: [ISI]Mailing.List: cc: taylor at PARC-MAXC, sutherland at PARC-MAXC, cc: rulifson at PARC-MAXC Murray Turoff, of the New Jersey Institute of Technology will be holding a computer teleconference later this year on various aspects of computer conferencing. Murray has asked me to chair a session on "resources and regulation," which I take to mean economics and regulation. I don't know the full ground rules yet, so I can't give you too much more information. But if you are interested in participating on either economics or regulation, I would like to hear from you. I do know that there will be only 10 participants in my session, and I want to hold about half the slots open for people from the FCC, OTP, Western Union and the U.S. Postal Service. In other words, I have the distasteful task of saying no to many people who would like to join. The overall goal of the teleconference, as I understand it, will be to help NSF understand some of the issues raised by computer teleconferencing. ------- 10-MAY-78 22:12:15-PDT,1239;000000000001 Mail from USC-ISI rcvd at 3-JUN-76 1110-PDT Date: 3 JUN 1976 1048-PDT From: WALKER at USC-ISI Subject: MSGGROUP# 329 New Intelligent Terminal Program Committee To: [ISI]Mailing.List: A new committee has been established to assist the ARPA Intelligent Terminal Program in developing new methods for human to human and human to machine communications. A major thrust of the IT program in the next few years will be exploring the ways in which message services as we now know them should evolve, employing additional communications media both between the human and the computer, and between the computers themselves. I expect the committee, through extensive use of subgroups, to explore many avenues of interest to MsgGroup types and imagine that many of you will be involved in some of its activities. I encourage your comments and participation in the work of the group. I expect very substantial results from these and related efforts. Dave Farber will chair the committee and will be calling upon MsgGroup participation on a frequent basis, I'm sure. The name of the committee is CAHCOM which is purported to stand for Computer Assisted Human COMmunication. Steve Walker, ARPA ------- 10-MAY-78 22:12:16-PDT,1449;000000000001 Mail from USC-ISI rcvd at 6-JUN-76 0942-PDT Date: 6 JUN 1976 0928-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 330 CHANGES TO [ISI]MAILING.LIST;61 From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI] 6-JUN-76 09:28:59.STEFFERUD> There have been some changes and one member seems to have disappeared. If anyone has information as to the network whereabouts of Steve Sutkowski (SUTKOWSKI@UTAH-10) please let me know. Other changes are the addition of GAINES@RAND-ISD and the departure of KOHANSKI@RUTGERS-10. A new copy of the list is attached for your convenience. Best, Stef - - - - - - - [ISI]Mailing.List: @BBN, Gilbert, Heitmeyer, Hornish, Perlingiero, @BBNA, Burchfiel, Henderson, Mooers, Myer, @BBNB, Feinler, SMartin, Watson, @CCA, Tom, @CMUA, Barnes, Newcomer, Wactlar, @I4-TENEX, Pirtle, @ISI, MsgGroup, PBaran, Bryan, Broos, DCrocker, Farber, Goodwin, Kirstein, McLindon, Spivey, Stefferud, Tasker, Walker, @ISIB, Ellis, Steve, Stotz, Vittal, Wulf, @ISIC, White, @ISID, Mealy, Ryland, @MIT-AI, KLH, RMS, @MIT-DMS, Vezza, @MIT-MULTICS, DEHall, Pogran, @OFFICE-1, Dames, Engelbart, Grobstein, Panko, Stone, Taylor, Uhlig, vonGehren, @PARC-MAXC, McDaniel, @RAND-ISD, gaines, mlw, @RAND-RCC, Anderson, BRD, @RUTGERS-10, Robertson, @SRI-AI, Geoff, @UCLA-ATS, Lauren, Mark, ------- 10-MAY-78 22:12:16-PDT,1915;000000000001 Mail from USC-ISI rcvd at 13-JUN-76 1648-PDT Date: 13 JUN 1976 1605-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 331 Adding MSGGRP@MIT-DMS to MSGGROUP mailing list From: STEFFERUD at USC-ISI To: JFH at MIT-DMS Cc: [ISI]Mailing.List: Message-ID: <[USC-ISI]13-JUN-76 16:05:06.STEFFERUD> Hi Jack, I have added MSGGRP@MIT-DMS to [ISI]MAILING.LIST per your request. MsgGroup members are asked to add this address to their personal lists or FTP a new copy from [ISI]. What you guys are planning to do sounds very interesting. May we ask that you let us know how it works out? If we may be of further assistance, please ask. Best regards, Stef Begin forwarded message -------------------- Mail from MIT-DMS rcvd at 7-JUN-76 1127-PDT DATE: 7 JUN 1976 1336-EDT FROM: JFH at MIT-DMS SUBJECT: MSGGROUP mailing list KEYWORDS: MSGGRP, MSGGROUP, Message, Group ACTION-TO: Stefferud at USC-ISI CC: Broos at MIT-DMS MESSAGE-ID: [MIT-DMS].33672 Mike Broos has referred me to you to get a name added to the MSGGROUP mailing list. Please add MSGGRP at MIT-DMS. This mailbox will serve to collect MSGGROUP messages at DMS for various interested parties (including myself) who are working on various message systems here. Also, I am going to set it up to store the messages in a file. The main purpose of having a single such mailbox is to avoid handling the same message once for each interested user, and to make it easier for people here to look at such messages since they can just ask locally to be placed on the distribution list. Jack Haverty (JFH@MIT-DMS) P.S. Please don't remove any existing addressees at DMS, since they won't be linked to the MSGGRP mailbox until I find out who they are. -------------------- End forwarded message ------- 10-MAY-78 22:12:16-PDT,490;000000000001 Mail from USC-ISI rcvd at 16-JUN-76 2255-PDT Date: 16 JUN 1976 2249-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 332 Welcome Back Steve Sutkowski@OFFICE-1 From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]16-JUN-76 22:49:02.STEFFERUD> Hi Steve, as you requested, you have been re-entered in [ISI]MAILING.LIST;65. MsgGroup members are requested to add you to their lists or FTP a new one. Welcome back! Stef ------- 10-MAY-78 22:12:16-PDT,4541;000000000001 Mail from SRI-AI rcvd at 20-JUN-76 0113-PDT Date: 19 JUN 1976 2156-PDT From: Geoff at SRI-AI Subject: MSGGROUP# 333 I think they're seeing the light.... To: [ISI]Mailing.List: a212 0924 19 Jun 76 AM-Electronic Mail, Bjt two takes, 480-660 By JEFFREY MILLS Associated Press Writer WASHINGTON (AP) - The Postal Service is taking the first steps toward establishing an electronic mail system that promises overnight delivery of letters at a price no higher than current rates. The mail agency has signed a $2.2 million contract with the RCA Corp. to study what alternatives are available to the Postal Service in the area of computerized message systems. ''Weknow it is technologically feasible to have a national electronic message service. We could do it today,'' said Ralph Marcotte, Postal Service program manager for the RCA contract. ''The question we want answered now is whether there is a national market for it,'' he said in an interview. ''The chances are very good that the study will come up with at least one alternative that is economically feasible and that would be accepted by the public,'' he said. Technology exists to use leased lines, facsimile devices, communications satellites and other devices to send messages electronically, he said. One possible application is for the Postal Service to establish ''electronic mail kiosks'' at such places as shopping centers. A person could enter a message written in block letters into a machine equipped with optical character readers that could convert the message into digital form. The message then could be transmitted to a Postal Service receiving unit near the addressee. A computer printout of the message could be delivered with the next day's mail. Another possibility is for a business to link its own computer electronically with that of the nearest Postal Service message station. ''His computer would talk to our computer and then our's would send the message electronically,'' Marcotte said. The message could be received by computer by the addressee or a printout could be delivered conventionally. ''The cost of sending a one-page business document would be as low as a nickel per page, not including any delivery costs,'' he said. Marcotte said the chances appear good for delivering an electronic letter for the same or less than the current 13-cent price of a first-class letter. One potential problem with electronic mail is that private companies now entering the field of electronic message systems may complain about competition from the government. Marcotte said systems run by private enterprise ''would tend to go along routes of high profitability and high usage'' while the Postal Service would try to serve all areas of the country. Officials point out that the Postal Service already has a nationwide delivery network, an asset that companies do not have. An electronic system would enable the Postal Service to save considerable mail handling. The Postal Service now employs about 700,000 workers, nearly 1 per cent of the American labor force, in moving the mails. MORE 1224pED 06-19 *************** a213 0928 19 Jun 76 AM-Electronic Mail, 1st add, 180 WASHINGTON: mails. Postal officials say another possible advantage to the agency would be that electronic mail could recover business that the Postal Service has been losing in recent years. Use of the mail has been declining, partly because of rising mail rates and partly because of the increasing use of privately owned electronic communications at the expense of the U.S. mail. The Postal Service could begin offering an electronic mail service ''as soon as three years from now if everything goes right,'' Marcotte said. ''We have the obvious option of growing in steps as demand for the service grows. We could start with leased lines and then later go to satellites, for example,'' he said. Marcotte said a possible ''second generation'' is for people to buy a ''black box'' to receive mail electronically in his own home. This is not feasible yet, he said. Marcotte said electronic mail ''would be a supplement to the present first-class mail and eventually might be a substitute.'' He concedes that this ''would be a rather radical departure from the present postal system. It certainly would change our image.'' 1228pED 06-19 *************** Comments anyone? [Geoff] ------- 10-MAY-78 22:12:16-PDT,296;000000000001 Mail from USC-ISI rcvd at 21-JUN-76 1253-PDT Date: 21 JUN 1976 1220-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 334 $Please add CBF@MIT-ML to mailing list.$ To: [ISI]Mailing.List: I have been asked to try sending one line "Add/Drop messages. Comments? Stef ------- 10-MAY-78 22:12:16-PDT,845;000000000001 Mail from USC-ISI rcvd at 21-JUN-76 2259-PDT Date: 21 JUN 1976 2257-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 335 Request to add Charles Frankston: CBF@MIT-ML Subject: [FARBER at USC-ISI: Request for MSGGROUP membership] From: STEFFERUD at USC-ISI To: MSGGROUP Message-ID: <[USC-ISI]21-JUN-76 22:57:34.STEFFERUD> Begin forwarded message -------------------- Mail from USC-ISI rcvd at 20-JUN-76 1514-PDT Date: 20 JUN 1976 1503-PDT Sender: FARBER at USC-ISI Subject: Request for MSGGROUP membership From: FARBER at USC-ISI To: STEFFERUD Cc: cbf at MIT-ML Message-ID: <[USC-ISI]20-JUN-76 15:03:55.FARBER> Mr Charles Frankston (CBF@MIT-ML) reuested to be put on the MSGGROUP mailing list at NCC Dave ------- -------------------- End forwarded message ------- 10-MAY-78 22:12:16-PDT,1349;000000000001 Mail from SUMEX-AIM rcvd at 23-JUN-76 1616-PDT Date: 23 JUN 1976 1610-PDT From: KAHLER at SUMEX-AIM Subject: MSGGROUP# 336 MSGFIX To: [ISI]Mailing.List: SUMEX-AIM has a new MSGFIX to replace the TECO version. It is written in TENEX SAIL. You give it an input and an output file and it takes off. This will make routine editing of message-format files possible without worrying about changing the character counts. MSGFIX interprets every situation but one properly, and that is the case where two or more messages are juxtaposed within another message. The simple remedy is insert a blank line between the messages with an editor before running MSGFIX. The program looks for a line beginning with 7 hypens followed by a valid SNDMSG-style date-size stamp, and assumes that here is the end of one message and the beginning of the next. It pays no attention to existing character counts so that it may treat each message the same way every time it runs, whether that message needs a count correction or not. I thought I would offer this little hack to message-program users around the net because, as far as I know, there is no way provided to fix up such files without going into TECO and doing it by hand. You are welcome to the source file, just send me a message. Rich Kahler ------- 10-MAY-78 22:12:17-PDT,655;000000000001 Mail from USC-ISI rcvd at 24-JUN-76 2021-PDT Date: 24 JUN 1976 2005-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 337 A request for information From: FARBER at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]24-JUN-76 20:05:21.FARBER> I am looking for the existance on the Net of a compiler for PL/M. For those who dont recognize the language processor , it is a cross compiler generating code for the Intel 8008 and the 8080 microprocessor. The use I have in mind is for some experiments in programming the HP 2644 and it's successor to help in informal message processing. Thanks, Dave ------- 10-MAY-78 22:12:17-PDT,943;000000000001 Mail from BBN-TENEXA rcvd at 25-JUN-76 0837-PDT Date: 25 Jun 1976 1114-EDT Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP# 338 (MSGFIX) From: MOOERS at BBN-TENEXA To: KAHLER at SUMEX-AIM Cc: MYER, AIRPLANES, Cc: [ISI]Mailing.List: Message-ID: <[BBN-TENEXA]25-Jun-76 11:14:42.MOOERS> In-Reply-To: Your message of June 23, 1976 What is the motivation behind your hack? Are you (1) editing the content of messages in your file, or (2) fixing up garbled messages? If (2), how are the messages getting garbled? through message- systems or through people using TECO to edit them? We are planning to get rid of the seven hyphens at the end of Hermes messages, because they can now be supplied by printing templates, if people want them, and they become a nuisance in some circumstances, such as in the use of the Hermes "Explode" command. What will this do to your program? ---Charlotte ------- 10-MAY-78 22:12:17-PDT,650;000000000001 Mail from USC-ISI rcvd at 25-JUN-76 1107-PDT Date: 25 JUN 1976 1018-PDT Sender: LIPNER at USC-ISI Subject: MSGGROUP# 339 About MSGFIX From: LIPNER at USC-ISI To: Mooers at BBNA Cc: Kahler at SUMEX-AIM, Myer at BBNA, AIRPLANES at BBNA, Cc: [ISI]mailing.list:, [ISI]Mailing.List: Message-ID: <[USC-ISI]25-JUN-76 10:18:21.LIPNER> Charlotte-- I haven't used Kahler's MSGFIX, but messages DO get garbled-- and apparently by message systems as well as by teco hackers. Remember that file of messages of Lipner's the other day, full of control characters... I hope the hackers keep hacking. ---Sles ------- 10-MAY-78 22:12:17-PDT,3504;000000000001 Mail from SUMEX-AIM rcvd at 25-JUN-76 1811-PDT Date: 25 JUN 1976 1757-PDT From: KAHLER at SUMEX-AIM Subject: MSGGROUP# 340 MSGFIX To: mooers at BBN-TENEXA cc: [ISI]Mailing.List: Charlotte, Sorry for the delay. I have a lot to say, are you ready? We have never had mail garbled by message-programs that I know of. We have occasionally had a new user mess up his message.txt file by running SOS on it and leaving the line numbers in, or some such thing. It is nice to be able to fix similar kinds of accidents on the spot. We have a brand-new bulletin-board system here, with central and local bulletin-boards, topics and expire dates for the bulletins, a special SNDMSG called POST, a nightly batch job that keeps things cleaned up, etc., and I often found myself wanting to make a minor correction to an announcement I had posted. Since I wrote the BBD program to fix up message counts as part of the cleanup in case any editing had been done, I would get into our fine TV editor and make the changes, then have BBD rebuild the files. I figured that the same thing would be easy enough to do for message-format files too, and now that MSGFIX is written, it opens the door for people who have community message-files to correct spelling errors and the like without worrying about messed-up counts. Perhaps it also opens up a Pandora's box for those concerned about message-file security. The only file security we have of course is that provided by the time-sharing monitor, and a file protected from a text editor will be protected from MSGFIX too. So MSGFIX was intended to be of infrequent use to repair the effects of accidents with editors, but as I said, it makes it a lot easier to edit message-format files routinely. I don't know if you are worried about message-tampering there or not, but there are some on the net that are. Regarding HERMES, it is something I have only heard a little about. Of course, if HERMES messages will not have the format that SNDMSG currently puts out, MSGFIX, as written, won't know what to do on those files, except maybe make the character count as long as the file, or blow up when string-space is exceeded. A MSGFIX written for a message format that had no trailer on the message would have to assume end-of-message-and-beginning-of-new-one every time it found a valid header. Then you would make trouble inserting messages into other messages unless you were careful to remove the date-size stamp. If I had been in on the original decision about message-format, I would have recommended a distinctive short sequence of characters as a message separator (like -o0o-), and let it be known that anybody who put that sequence in a message he sent would get a lecture from the guy who received it, or else have a smart SNDMSG that would insert a space in front of any line that started that way, or disallowed it entirely. But I'm sure that whoever made the decision on the current message-format had good reasons for having character counts in headers instead. (Maybe for speed reasons, but some message programs have missed the boat there.) ------ Once MSGFIX has passed the test of time, I plan to put in our version an automatic rename of the corrected file to message.txt;1, if the input file was message.txt;1, with proper warning to the user. Hope these few thoughts are useful to you. I am rarely this verbose. Rich ------- 10-MAY-78 22:12:17-PDT,1620;000000000001 Mail from USC-ISI rcvd at 25-JUN-76 2345-PDT Date: 25 JUN 1976 2345-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 341 [STEFFERUD at USC-ISI: [MOOERS at BBN-TENEXA: (MSGFIX)]] From: STEFFERUD at USC-ISI To: MSGGROUP Message-ID: <[USC-ISI]25-JUN-76 23:45:34.STEFFERUD> Special-Handling: This message is sent to MsgGroup@ISI as an Special-Handling: example of a modified forwarded message for the Special-Handling: record. Stef Begin forwarded message -------------------- Mail from USC-ISI rcvd at 25-JUN-76 2318-PDT Date: 25 JUN 1976 2317-PDT Sender: STEFFERUD at USC-ISI Subject: [MOOERS at BBN-TENEXA: (MSGFIX)] From: STEFFERUD at USC-ISI To: STEFFERUD Message-ID: <[USC-ISI]25-JUN-76 23:17:59.STEFFERUD> Begin forwarded message -------------------- Mail from BBN-TENEXA rcvd at 25-JUN-76 0841-PDT Date: 25 Jun 1976 1114-EDT Sender: MOOERS at BBN-TENEXA Subject: (MSGFIX) From: MOOERS at BBN-TENEXA To: KAHLER at SUMEX-AIM Cc: MYER, AIRPLANES, Cc: [ISI]Mailing.List: Bcc: STEFFERUD at USC-ISI Message-ID: <[BBN-TENEXA]25-Jun-76 11:14:42.MOOERS> In-Reply-To: Your message of June 23, 1976 [I defy anyone to prove that this is not a message that Charlotte sent to Stefferud at USC-ISI without using more information than is contained here-in, including the fact that this is an unlikely message for Charlotte to ever send to anyone! Enjoy, Stef] ---Charlotte ------- -------------------- End forwarded message ------- -------------------- End forwarded message ------- 10-MAY-78 22:12:17-PDT,4295;000000000001 Mail from USC-ISI rcvd at 26-JUN-76 0043-PDT Date: 26 JUN 1976 0031-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 342 Authentification versus MSGFIX From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]26-JUN-76 00:31:15.STEFFERUD> With reference to the recent MsgGroup correspondence on MSGFIX, and for the record, I maintain that there is absolutely no way to prevent users from modifying received messages with any useful guarantee. Thus we should not design and implement our systems to prevent annotations and modifications by users on the false promise that this will facilitate authenticity of messages that have resided in the recipients directory for more than 15 minutes (if that long!). It might even be considered a hoax to prevent users from treating their received mail as data in a data management system, if the reason is that the system should "cause" integrity in spite of the motives, incentives, morals, ethics, etc of the recipients of our messages. For example, if I FORWARD a message to you which I have received from someone else, I can edit it in the process of forwarding it via HERMES by putting the text of the forwarded message in an editer and doing what I will with it with no way for you to detect that I did anything at all, unless you can find some way to check the character count of the forwarded message, which I don't think you can do. My basic and continuing position on this issue is that authentification should be accomplished through some kind of feedback channel, independent of the original message transmission path. Any open loop transmission technique that will guarantee the authenticity of sent messages will be more expensive than we want to pay for and more expensive than the problem can or will justify. And this still does not deal with the problem of authenticating messages retrieved from a user's files after receipt from an authenticating transmission channel. Authentification should be provided by means of some extra channel of communication such as a County Recorders Office that is charged with maintaining an archive of records for later verification of the facts that such records as the ones originally recorded did in fact exist at the time of the recording. And this still does not attest to the validity of the content of the recorded documents. Authentification is just too big a problem to be solved by making it difficult to modify received messages. I think it is time to quit wasting so much effort in the vain attempt to solve the problem with such disfunctional results as preventing users from modifying or annotating their received message data bases. Furthermore, I maintain that by providing a false promise of authenticity, we are setting ourselves up for some real fraud one of these days. Mail is not now authentifiable and we should be sure that the users know this. Any other position is, in my opinion, unethical and immoral, and poor business too! Comments? Stef PS: As evidence I submit the following example which has also been sent to MsgGroup at ISI for the record and for your inspection. 1041 Chars Mail from USC-ISI rcvd at 25-JUN-76 2318-PDT Date: 25 JUN 1976 2317-PDT Sender: STEFFERUD at USC-ISI Subject: [MOOERS at BBN-TENEXA: (MSGFIX)] From: STEFFERUD at USC-ISI To: STEFFERUD Message-ID: <[USC-ISI]25-JUN-76 23:17:59.STEFFERUD> Begin forwarded message -------------------- Mail from BBN-TENEXA rcvd at 25-JUN-76 0841-PDT Date: 25 Jun 1976 1114-EDT Sender: MOOERS at BBN-TENEXA Subject: (MSGFIX) From: MOOERS at BBN-TENEXA To: KAHLER at SUMEX-AIM Cc: MYER, AIRPLANES, Cc: [ISI]Mailing.List: Bcc: STEFFERUD at USC-ISI Message-ID: <[BBN-TENEXA]25-Jun-76 11:14:42.MOOERS> In-Reply-To: Your message of June 23, 1976 [I defy anyone to prove that this is not a message that Charlotte sent to Stefferud at USC-ISI without using more information than is contained here-in, including the fact that this is an unlikely message for Charlotte to ever send to anyone! Enjoy, Stef] ---Charlotte ------- -------------------- End forwarded message ------- ------- 10-MAY-78 22:12:17-PDT,430;000000000001 Mail from USC-ISI rcvd at 26-JUN-76 0044-PDT Date: 26 JUN 1976 0024-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 343 Adding: @SUMEX-AIM, Kahler, Rindfleisch, NSmith, From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]26-JUN-76 00:24:12.STEFFERUD> To get a copy of the full [ISI]mailing.list, you can FTP it or I will send a copy upon request. Best, Stef ------- 10-MAY-78 22:12:18-PDT,1460;000000000001 Mail from USC-ISI rcvd at 26-JUN-76 0133-PDT Date: 26 JUN 1976 0128-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 344 [STEFFERUD at USC-ISI: [ISI]Message.Txt;1 Protection?] From: STEFFERUD at USC-ISI To: MSGGROUP Message-ID: <[USC-ISI]26-JUN-76 01:28:22.STEFFERUD> Special-Handling: For the MsgGroup Record Begin forwarded message -------------------- Mail from USC-ISI rcvd at 26-JUN-76 0119-PDT Date: 26 JUN 1976 0046-PDT Sender: STEFFERUD at USC-ISI Subject: [ISI]Message.Txt;1 Protection? From: STEFFERUD at USC-ISI To: ACTION Cc: STEFFERUD, DCROCKER, WALKER, FARBER Message-ID: <[USC-ISI]26-JUN-76 00:46:41.STEFFERUD> It has come to my attention that the MsgGroup mailbox can no longer be read from non-connected directories. This is not the way it was set up nor the way it should be. I expect that this condition has existed since the conversion from old to new . Now that we have detected the problem, please reset [ISI]Message.txt so it can be read by any directory but only appended to by FTP or by connected directories. I believe that we want to continue as a files only directory so do not change it in this regard. Thank you, Stef PS: Steve, if this action requires your blessing, please give it by return mail. Thanks, S/ ------- -------------------- End forwarded message ------- 10-MAY-78 22:12:18-PDT,2350;000000000001 Mail from USC-ISI rcvd at 26-JUN-76 1311-PDT Date: 26 JUN 1976 1256-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 345 ((MSGFIX)) From: STEFFERUD at USC-ISI To: MOOERS at BBN-TENEXA, Kahler at SUMEX-AIM Cc: [ISI]Mailing.List: Message-ID: <[USC-ISI]26-JUN-76 12:56:53.STEFFERUD> In-Reply-To: <[BBN-TENEXA]25-Jun-76 11:14:42.MOOERS> I want to explain my need for MSGFIX to support processing of the MsgGroup traffic. I am supposed to process each arriving message in [ISI] Message.txt to insert "MSGGROUP# NNN" into the beginning of the subject. This number is an accession number and cannot be inserted by the originator of the message because there is no way to handily supply such numbers in advance. I am currently far behind in getting the processing done. This is partly due to the difficulty of doing it with the available tools which do not allow (except for MSGDMS) any modification of any field without destroying the ability to process the message with our current message handling systems (MSG, HERMES, RD, and a lot of others at non tenex sites. MSGFIX will provide the required tool. HERMES allows modification, but it will also change the SENDER field, the DATE field, etc. I have used MSGDMS in the past, but it is quite cumbersome for my purpose and it changes some parts of the messages in unfortunate ways, such as altering the received date. MSGDMS also puts out its internal "reader id" when it Outputs in MSG format so the result is a bit strange. I have no complaint with MSGDMS. My use of it for MsgGroup processing is not properly part of the DMS design effort or goal set. I hasten to add that it is not part of the design effort or goal set for the HERMES implementers or the MSG maintainers, or anybody else! But! I still have my problem of not having the tools I need to do the job. My purpose in this message is not to complain about my past lack of tools, but to clearly state that I have a real need for the MSGFIX Hack, and I have every intention of using it because it will make my MsgGroup processing task bearable. If anyone wishes to tell me I should not be modifying the MSGGROUP transaction messages, they are welcome to take over responsibility for the task! My very best regards, Stef ------- 10-MAY-78 22:12:18-PDT,905;000000000001 Mail from USC-ISI rcvd at 26-JUN-76 1723-PDT Date: 26 JUN 1976 1710-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 346 FTP trouble with Message.Txt From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]26-JUN-76 17:10:17.STEFFERUD> Some members have complained that message.txt has refused to allow access via FTP or otherwise be read without connecting with the proper password. It appears that the protection has been erroneously reset. I have taken actions to have it reset correctly to allow reading but not writing from any directory or via FTP. To temporarily solve the problem, and until the protection is reset to allow reading (but not writing) without connecting, I have copied the file into Message.FTP, which will allow access without connecting. (It has protection 777752) Enjoy, Stef ------- 10-MAY-78 22:12:18-PDT,728;000000000001 Mail from BBN-TENEXA rcvd at 28-JUN-76 0654-PDT Date: 28 Jun 1976 0948-EDT Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP# 347 (About MSGFIX) From: MOOERS at BBN-TENEXA To: LIPNER at USC-ISI Cc: kahler at SUMEX-AIM, Cc: MYER, AIRPLANES, Cc: [ISI]Mailing.List: Message-ID: <[BBN-TENEXA]28-Jun-76 09:48:53.MOOERS> In-Reply-To: <[USC-ISI]25-JUN-76 10:18:21.LIPNER> Don't mean to sound disapproving; let's just say the hacker's use of those unspeakable seven little hyphens raised my hackles quite irrationally. Indeed, messages do get garbled, and yes, it's a good idea to fix them up. I don't want to see the seven little hypens cast in concrete, however. Cheers, ---Charlotte ------- 10-MAY-78 22:12:18-PDT,2373;000000000001 Mail from BBN-TENEXA rcvd at 28-JUN-76 0905-PDT Date: 28 Jun 1976 1149-EDT Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP# 348 (((MSGFIX))) From: MOOERS at BBN-TENEXA To: STEFFERUD at USC-ISI, To: kahler at SUMEX-AIM Cc: MYER, AIRPLANES, Cc: [ISI]Mailing.List: Message-ID: <[BBN-TENEXA]28-Jun-76 11:49:19.MOOERS> In-Reply-To: <[USC-ISI]26-JUN-76 12:56:53.STEFFERUD> I fired off my first message this morning before I finished reading my mail. That should teach me a lesson! I have a couple of more comments about the MSGFIX program. Steff: I think we are now well aware of the type of message processing you need to do for the MsgGroup, and that we do agree that it is properly a part of the design effort of Hermes, although it has not been our first priority. Your analysis has shown very clearly that, under present circumstances, it is impossible to prevent falsification of messages if the falsifier is determined and experienced in using a general text editor such as TECO. However, when users modify messges, it may be (I would argue definitely is) desirable to lay down an "audit trail" showing who modified what and when, with the purpose of allowing honest users to trace the history of a message. This is quite different from focussing on fraud. Rich Kahler: Your bulletin-board system sounds interesting. About the seven little hyphens: Hermes has a Save-field command that saves the contents of a message-field, such as the Text:-field, in an ordinary TENEX file. Hermes also has an Explode command, which turns an incoming message into an outgoing message by placing all the user-created fields (e.g., To, Cc, Subject, Keywords, Text) in the coresponding fields of the message being created. The problem with the seven little hypens is that they pile up when message- fields are iterated through these commands. One fix that we are considering is to eliminate them from the Text:-field and allow the user to insert them when the message is printed, and to omit them if he chooses. After all, they are not part of the message that the user sent out, and when you use the Save-field command to store one of Stef's mailing lists in a TENEX file, you may find yourself sending messages to -------@UCLA-ATS, if you are not careful. Very embarassing. ---Charlotte ------- 10-MAY-78 22:12:18-PDT,274;000000000001 Mail from USC-ISI rcvd at 28-JUN-76 1717-PDT Date: 28 JUN 1976 1650-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 349 $Adding Carlisle@ISID, Lipner@ISI$ To: [ISI]Mailing.List: Another "Subject Only" Add message for your comfort. Enjoy, Stef ------- 10-MAY-78 22:12:18-PDT,233;000000000001 Mail from USC-ISI rcvd at 28-JUN-76 1717-PDT Date: 28 JUN 1976 1638-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 350 $Message.Txt now fixed to allow FTP$ To: [ISI]Mailing.List: Enjoy, Stef ------- 10-MAY-78 22:12:18-PDT,214;000000000001 Mail from SUMEX-AIM rcvd at 28-JUN-76 2231-PDT Date: 28 JUN 1976 2221-PDT From: KAHLER at SUMEX-AIM Subject: MSGGROUP# 351 $Please delete RINDFLEISCH@SUMEX-AIM$ To: [ISI]Mailing.List: ------- 10-MAY-78 22:12:19-PDT,903;000000000001 Mail from SUMEX-AIM rcvd at 28-JUN-76 2253-PDT Date: 28 JUN 1976 2248-PDT From: KAHLER at SUMEX-AIM Subject: MSGGROUP# 352 Message trailers To: Mooers at BBNA cc: [ISI]Mailing.List: Charlotte, The possibility immediately suggests itself that HERMES not consider the trailer (of 7 hyphens or whatever) a part of the text field. HERMES could, for example, examine the last 9 characters of the message and if they were "-------" it would say to itself "This is a trailer" and lop it off, when isolating a text field. I mentioned before that a trailer helps a program like MSGFIX distinguish between a real message and a message embedded within another. Otherwise, you just have MSGFIX look for date-size stamps only and hope (in vain) that there aren't any embedded ones. It's easier on the eyes, too, to have some kind of trailer. Rich ------- 10-MAY-78 22:12:19-PDT,802;000000000001 Mail from SUMEX-AIM rcvd at 29-JUN-76 0128-PDT Date: 29 JUN 1976 0112-PDT From: KAHLER at SUMEX-AIM Subject: MSGGROUP# 353 More on trailers To: mooers at BBNA cc: [ISI]Mailing.List: Charlotte, It has occurred to me that my suggestion was something you had just said you were considering. If so, that was dumb of me. That makes two dumb things I have had to fix today. If the text field is everything up to the hyphens, and the forwarding process deleted both the date-size stamp and trailing hyphens from messages it inserted in another message, then neither the stamps nor the trailing hyphens need proliferate. One date-size stamp would be found at the head of the message, and one set of hyphens at the end. But do as you think best. Rich ------- 10-MAY-78 22:12:19-PDT,739;000000000001 Mail from SUMEX-AIM rcvd at 29-JUN-76 1416-PDT Date: 29 JUN 1976 1350-PDT From: KAHLER at SUMEX-AIM Subject: MSGGROUP# 354 TENEX SAIL Consulting To: [ISI]Mailing.List: I wanted to announce to everybody on this mailing list that I am available for questions on TENEX SAIL, which is distributed to the net through SUMEX-AIM. Please don't consider any question too simple. Any question I can't answer I can forward to Bob Smith (RSMITH@SUMEX-AIM) who very ably maintains TENEX SAIL. Interested parties who have accounts at SUMEX-AIM can check the SUMEX bulletin-board every so often for SAIL news. We will try to keep current copies of SAIL bulletins on our export directory . Rich ------- 10-MAY-78 22:12:19-PDT,597;000000000001 Mail from SUMEX-AIM rcvd at 30-JUN-76 0240-PDT Date: 30 JUN 1976 0233-PDT From: KAHLER at SUMEX-AIM Subject: MSGGROUP# 355 MSGFIX available again (for real) To: [ISI]Mailing.List: MSGFIX is now available from directory at SUMEX-AIM. The new version has some more protective stuff in it, and will update the input file if no output file is given. I think the only one who got a copy last time was Geoff@SRI, because he has an account here. There are three MSGFIX files on , MSGFIX.SAI, the source, MSGFIX.HELP, and MSGFIX.SAV. Rich ------- 10-MAY-78 22:12:19-PDT,234;000000000001 Mail from USC-ISI rcvd at 30-JUN-76 1250-PDT Date: 30 JUN 1976 1234-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 356 $Please change Vittal@ISIB to Vittal@BBNA in MsgGroup$ To: [ISI]Mailing.List: Stef ------- 10-MAY-78 22:12:19-PDT,1164;000000000001 Mail from USC-ISI rcvd at 2-JUL-76 1502-PDT Date: 2 JUL 1976 1431-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 357 New MsgGroup Membership Change procedures From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI] 2-JUL-76 14:31:31.STEFFERUD> For a variety of reasons, all due to administrative problems of keeping the mailing list up-to-date without bothering you all too much, I will henceforth request each new member to send a message from the directory to which MsgGroup Mail is to be delivered. This new procedure should eliminate retractions and corrections caused by inaccurate assumptions on my part. I am also going to send all changes in the Subject line of Membership Change Notices. When there is no additional text, the change notice will have $---$ brackets around the Subject field. This will facilitate administration of your private MsgGroup mailing lists without requiring you to print out each entire Change Notice. For those with Key word search facilities, I will include the phrase "Membership Change Notice" in the Key-Word field. Best Regards, Stef ------- 10-MAY-78 22:12:19-PDT,3469;000000000001 Mail from USC-ISI rcvd at 2-JUL-76 1635-PDT Date: 2 JUL 1976 1621-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 358 ((About MSGFIX)) From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Cc: MOOERS at BBN-TENEXA, LIPNER, kahler at SUMEX-AIM, Cc: MYER at BBN-TENEXA, AIRPLANES at BBN-TENEXA Message-ID: <[USC-ISI] 2-JUL-76 16:21:35.STEFFERUD> In-Reply-To: <[BBN-TENEXA]28-Jun-76 09:48:53.MOOERS> It seems to me that the seven little hyphens at the end of some of our messages are not going to go away because of the unilateral decisions of any one message system implementation group. They are put there by any system that wants to do so. If and when our message systems let us deal with the garbled message problem in a rational way, and deal with the annotation- modification problem in a rational way, then maybe we won't need MSGFIX or the seven little hyphens. It has been pointed out by some MULTICS users that a better solution to the whole problem is to place all message files behind a security curtain that would only allow access through controlled software to avoid the garbled message problem. I assume they include message modification facilities in the message handling system. In the meantime we TENEX users need hacks like MSGFIX just to survive, and we will have to manually assure (via our favorite editors) that the seven little hyphens are present in every proper place (and not present in every improper place) so MSGFIX will not screw up our files. The seven little hyphens are certainly not cast in concrete. Enough message creation/sending systems now omit the hyphens to require considerable care on the part of any MSGFIX user, but MSGFIX will at least afford us the means of repair if screw-ups do occur in its use. Now then, taking a more global view, what I see happening is that our budding message service affords us the opportunity (and may even force us) to delay the binding time of the format and content of our electronic correspondence. Where we used to be able to control what the receiver sees when he opens our mail, we can no longer do so. As Charlotte Mooers so directly pointed out, HERMES allows us to delay insertion of the seven hyphens until the receiver's version of HERMES prints the message, so the sender is relieved of this duty. HERMES, and other systems such as MSGDMS, are being designed to maximize the ability of the receiver to control the appearance of received mail. I believe that this introduces significant new degrees of freedom into person/person communications, and I don't think we understand the trouble we can cause for ourselves if we don't understand our new degrees of freedom. I realize that my last two paragraphs are a bit murky, but it is the best I can do at the time. I have been trying to articulate the thought for several months and have finally taken a shot at it. The MSGFIX discussion has given me a vehicle. I am assured in a side communication that MSGDMS will facilitate the kind of message modification that I need for MsgGroup Processing when the newest version is ready for me to try. This I regard as very good news, and as a move in the right direction. Unfortunately, such developments make things more difficult for those who would limit our ability to modify received messages. I fear that we cannot have it both ways. Comments? Stef ------- 10-MAY-78 22:12:20-PDT,1319;000000000001 Mail from USC-ISI rcvd at 2-JUL-76 2137-PDT Date: 2 JUL 1976 2126-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 359 [MCDANIEL at PARC-MAXC: Re: Authentification versus MSGFIX] From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI] 2-JUL-76 21:26:12.STEFFERUD> Gene McDaniel agreed that this should be forwarded to the group. Stef Begin forwarded message -------------------- Mail from PARC-MAXC rcvd at 26-JUN-76 1652-PDT Date: 26 JUN 1976 1652-PDT From: MCDANIEL at PARC-MAXC Subject: Re: Authentification versus MSGFIX To: STEFFERUD at USC-ISI cc: MCDANIEL In response to your message sent 26 JUN 1976 0031-PDT Hear! Hear! To support you in a slightly different way, authentification/ protection/security is quite possible on a system which is designed for it. Message systems are most correctly viewed as subsystems in a complex system environment. Getting there from here is far more labor than it is worth. The interesting things to do with message systems is to explore ways to make such systems convenient, usable, molded to particular needs, etc. There are far greater gains for the world as a whole to be explored in that direction! Gene ------- -------------------- End forwarded message ------- 10-MAY-78 22:12:20-PDT,1039;000000000001 Mail from USC-ISI rcvd at 2-JUL-76 2201-PDT Date: 2 JUL 1976 2139-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 360 Please remove Ryland@ISID from MsgGroup [RYLAND@HARV-10: LEAVING MSGGROUP] From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI] 2-JUL-76 21:39:55.STEFFERUD> Begin forwarded message -------------------- Mail from USC-ISID rcvd at 1-JUL-76 1236-PDT Date: 1 JUL 1976 1227-PDT Sender: RYLAND at USC-ISID Subject: LEAVING MSGGROUP From: RYLAND@HARV-10 To: STEFFERUD at ISI Message-ID: <[USC-ISID]1-JUL-76 12:27:19-PDT.RYLAND> STEF- IT IS WITH SOME REGRET THAT I REQUEST MY NAME BE REMOVED FROM THE MSGGROUP MAILING LIST. I'M MOVING FOR NEW YORK VERY SOON, AND WON'T BE ABLE TO BE INVOLVED IN THE MESSAGE GROUP DIALOGUE FROM THERE, UNLESS MY PLANS CHANGE. THANKS FOR THE CHANCE TO BE PART OF A FASCINATING INTERCHANGE ON A VERY INTERESTING SUBJECT. CHEERS! CHRIS ------- -------------------- End forwarded message ------- 10-MAY-78 22:12:20-PDT,1281;000000000001 Mail from USC-ISI rcvd at 4-JUL-76 0959-PDT Date: 4 JUL 1976 0946-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 361 [Richard M. Stallman (RMS@MIT-AI): MSGFIX, etc.] From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI] 4-JUL-76 09:46:09.STEFFERUD> Begin forwarded message -------------------- Mail from MIT-AI rcvd at 3-JUL-76 1611-PDT Date: 3 JUL 1976 1910-EST From: Richard M. Stallman (RMS @ MIT-AI) Subject: MSGFIX, etc. To: Stefferud at USC-ISI Please forward this to MSGGROUP unless it's redundant: The reason that MSGFIX has trouble with missing hyphen-lines comes only from working with a message system that wasn't designed to have a MSGFIX at all. That can certainly be remedied; appropriate delimiters can be inserted between messages when they are put in the mailbox (we use ^_). More fundamentally, I think it is mistaken to adopt a mailbox format with internal pointers, etc., simply because they are not accessed at a high enough rate for efficiency to matter. It is better to keep a format that is convenient for the user to edit, not needing any MSGFIX (it also makes things easier to debug). ------- -------------------- End forwarded message ------- 10-MAY-78 22:12:20-PDT,222;000000000001 Mail from USC-ISI rcvd at 5-JUL-76 1246-PDT Date: 5 JUL 1976 1210-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 362 $Welcome Mathison@BBN & Walker@BBN to MsgGroup$ To: [ISI]Mailing.List: ------- 10-MAY-78 22:12:20-PDT,2195;000000000001 Mail from RUTGERS-10 rcvd at 5-JUL-76 1249-PDT Date: 5 Jul 1976 (Monday) 1543-Est From: ROBERTSON at RUTGERS-10 Subject: MSGGROUP# 363 RE: MSGFIX, ETC. [IN RESPONSE TO MESSAGE SENT BY RMS@MIT-AI] To: @MSGGRP.MAI[1001,1013] at RUTGERS-10: HERE AT RUTGERS, SINCE THE IMPLEMENTATION OF MSGH (OUR MESSAGE HANDLER), WE HAVE ELIMINATED THE USE OF SEVEN HYPHENS AT THE END OF MESSAGES. WHEN DESIGNING MSGH, I DECIDED TO RELY SOLEY ON THE CHARACTER COUNT CONTAINED IN THE DATE-TIME STAMP AT THE BEGINNING OF EACH MESSAGE. I FOUND IT TO BE ADEQUATE FOR DELIMITING MESSAGES AND AN EXCELLENT MEANS FOR RAPID EVALUATION OF THE MESSAGE FILE. I DISAGREE WITH STALLMAN'S STATEMENT THAT A MAILBOX FORMAT, INCLUDING INTERNAL POINTERS, IS NOT JUSTIFIED DUE TO THE INFREQUENCY OF ITS ACCESS, AND THAT A SINGLE CHARACTER MESSAGE DELIMITER IS ALL THAT IS NEEDED. MANY OF OUR USERS KEEP LARGE FILES OF ACCUMULATED MESSAGES AND ACCESS THEM FREQUENTLY. WITHOUT THE ADVANTAGE OF THE CHARACTER COUNT IN THE DATE-TIME STAMP, UNTOLD TIME WOULD BE SPENT BY THE MESSAGE HANDLER EACH TIME A USER DECIDED TO EXAMINE THE CONTENTS OF SUCH A FILE. AN ADDED ADVANTAGE IS THAT THE DATE-TIME STAMP IS DIFFICULT FOR A USER TO DUPLICATE WITHIN A MESSAGE (WITHOUT GOING OUT OF HIS OR HER WAY). I DO AGREE, THOUGH, IN THE NEED FOR A MSGFIX OR SOME SIMILAR CAPABILITY. SEVERAL MONTHS AGO, I ADDED WITHIN MSGH THE ABILITY TO DIAGNOSE AND AUTOMATICALLY CORRECT, IF THE USER SO DESIRES, ERRORS IN THE CHARACTER COUNT OF THE DATE-TIME STAMP OF A MESSAGE. THIS CAME ABOUT AFTER HAVING HAD THE NEED, ON SEVERAL OCCATIONS, TO RECONSTRUCT A MESSAGE FILE FROM THE AFTERMATH OF A USERS SESSION WITH SOS. ALSO ON TWO OCCATIONS WE EXPERIENCED DISK FAILURES WHILE THE MAILER WAS APPENDING A MESSAGE TO A USERS QUEUED MAIL RENDERING THE FILE UNREADABLE BY THE MESSAGE HANDLER; DUE TO THE DISAGREEMENT OF THE CHARACTER COUNT IN THE DATE-TIME STAMP AND THE ACTUAL NUMBER OF CHARACTERS IN THE (PARTIAL) MESSAGE. UNDER SUCH CIRCUMSTANCES, THERE MUST BE A WAY TO RECOVER SUCH THAT THE FILE CAN ONCE AGAIN BE PROCESSED BY THE MESSAGE HANDLER. [DON] 10-MAY-78 22:12:20-PDT,1417;000000000001 Mail from SUMEX-AIM rcvd at 5-JUL-76 2327-PDT Date: 5 JUL 1976 2320-PDT From: KAHLER at SUMEX-AIM Subject: MSGGROUP# 364 Character counts and delimiters To: [ISI]Mailing.List: Don, There are lots of date-size stamps found within messages, due to the insertion of whole messages into other messages for forwarding or whatever. There are some in the MSGGROUP mail. Smart forwarding routines can leave the stamp out when they forward a message, and I suppose yours does since you do not expect to find date-size stamps embedded in messages. If it weren't for that, MSGFIX could just look for the stamp and that would be it. I don't see yet how counts are faster than one-character delimiters. In SAIL (DEC or TENEX version), for example, it is a matter of giving the INPUT routine a count and saying "Read me that much" versus giving INPUT a break character and saying "Keep reading until you find the break character". In either case you are reading through the whole file once to set up your random-access pointers unless you have saved them somewhere from a previous session (as we do with our bulletin-boards). Then when it comes time to type out a message you set the file pointer and read either until count is exhausted or break character is found, then type out what you found. Both cases would seem to take the same amount of time. Rich ------- 10-MAY-78 22:12:20-PDT,799;000000000001 Mail from RUTGERS-10 rcvd at 6-JUL-76 0522-PDT Date: 6 Jul 1976 (Tuesday) 0818-Est From: ROBERTSON at RUTGERS-10 Subject: MSGGROUP# 365 RE: CHARACTER COUNTS AND DELIMITERS To: @MSGGRP.MAI[1001,1013] at RUTGERS-10: THE REASON CHARACTER COUNTS IN THE DATE-TIME STAMP ARE FASTER IN MSGH, AS APPOSED TO SCANNING FOR A SINGLE CHARACTER DELIMITER, IS THAT MSGH READS THE ENTIRE MESSAGE FILE INTO CORE IN DUMP MODE AND THEN MAKES USE OF THE CHARACTER COUNTS TO RUN QUICKLY THRU THE MESSAGE FILE, NOW IN CORE, AND SET UP RANDON ACCESS POINTERS. THE RANDOM ACCESS POINTERS ARE IN THE FORM OF BYTE POINTERS (WE HAVE A PDP-10) AND TO TYPE A MESSAGE MSGH SIMPLY DUMPS EVERYTHING BETWEEN BYTE POINTERS, EXCLUDING THE DATE-TIME STAMP WHEN DUMPING TO A TTY AND WHEN FORWARDING. [DON] 10-MAY-78 22:12:20-PDT,932;000000000001 Mail from BBN-TENEXA rcvd at 6-JUL-76 0941-PDT Date: 6 Jul 1976 1224-EDT Sender: HENDERSON at BBN-TENEXA Subject: MSGGROUP# 366 Re: Character counts and delimiters From: HENDERSON at BBN-TENEXA To: KAHLER at SUMEX-AIM Cc: [ISI]Mailing.List: Message-ID: <[BBN-TENEXA] 6-Jul-76 12:24:26.HENDERSON> In-Reply-To: Your message of July 5, 1976 Even if you don't get the whole of a message file into core (having the file open prevents new mail from arriving), you still can speed things up with the character count: when you have one local header (I think you have been calling it a date-time stamp) located, you can simply add the length to the location of the first character of the message to locate the local header of the next message (which of course we all know). Then just set the file pointer to that point (rather than reading through the file to that point), and proceed. Austin ------- 10-MAY-78 22:12:20-PDT,384;000000000001 Mail from OFFICE-1 rcvd at 6-JUL-76 1000-PDT Date: 6 JUL 1976 0945-PDT From: PANKO at OFFICE-1 Subject: MSGGROUP# 367 MSGFIX - a definition please To: [ISI]Mailing.List: I would be grateful if somebody could give a capsule summary of what MSGFIX does. The current discussion is very interesting, but I could really use a nutshell description. Thanks ------- 10-MAY-78 22:12:21-PDT,1244;000000000001 Mail from USC-ISI rcvd at 6-JUL-76 1050-PDT Date: 6 JUL 1976 1034-PDT Sender: DCROCKER at USC-ISI Subject: MSGGROUP# 368 RE: MSGFIX, ETC. [IN RESPONSE TO MESSAGE SENT BY RMS@MIT-AI] From: DCROCKER at USC-ISI To: ROBERTSON at RUTGERS-10 Cc: [ISI]Mailing.List:, Cc: Mark: Message-ID: <[USC-ISI] 6-JUL-76 10:34:22.DCROCKER> In-Reply-To: Your message of JULY 5, 1976 An approach to message-structuring which is probably going to be used at Rand is to have both structuring and character-delimiter information maintained. The structure information (to some level of detail) will probably be simple pointers and byte counts for fields. The character delimiter will be in the message file, between messages. The delimiter will be easily detectable and reproducible by the user and never used by the system unless the structure information is incorrect or lost. A Series of simple consistency checks will let the system know when the files are out of synch. The design decision came out of discussion very similar to what has been said about MsgFix and in fact I have merrily copied the MsgGroup exchange to the Rand crew, since the discussion consistently supported my point of view. Dave. ------- 10-MAY-78 22:12:21-PDT,1826;000000000001 Mail from USC-ISI rcvd at 6-JUL-76 1222-PDT Date: 6 JUL 1976 1139-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 369 [Richard M. Stallman (RMS@MIT-AI): Mailbox Format Criteria] From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI] 6-JUL-76 11:39:46.STEFFERUD> Begin forwarded message -------------------- Mail from MIT-AI rcvd at 6-JUL-76 1019-PDT Date: 6 JUL 1976 1318-EST From: Richard M. Stallman (RMS @ MIT-AI) To: stefferud at USC-ISI Please send to msggroup (I am sending these through you because I haven't maintained a list of the group. Can't there be a name to mail to that always forwards to everyone in the group? That is possible with MIT-AI's mailer, and I believe also at BBN) My message a couple of days ago has created an argument about whether character counts in messages can save time. Let's end it; it is clear that in some implementations, character counts will make some operations faster. The next question, which people have been ignoring, is HOW MUCH faster. The time saving for an operation that scans the entire file is only .5 second on a KA-10 for a tremendous 100,000 character mailbox; for most people's mailboxes it will be unnoticeable. If even that much time is considered unacceptable, the mail reader can create a table of pointers each time it is invoked; then the .5 second cost is incurred only once per invocation. Since even a format using delimiters and no counts is acceptably fast, the question of speed can be ignored when comparing different mailbox formats. The choice of a mailbox format should be based on other criteria, such as (for one) how convenient it is for the user to edit his file. ------- -------------------- End forwarded message ------- 10-MAY-78 22:12:21-PDT,2609;000000000001 Mail from USC-ISI rcvd at 6-JUL-76 1222-PDT Date: 6 JUL 1976 1131-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 370 [ Pogran at MIT-Multics: MSGFIX Debating Society (a.k.a. MsgGroup)] Subject: [ Pogran at MIT-Multics: My previous message] From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI] 6-JUL-76 11:31:01.STEFFERUD> I have been trying to write a message to make the points that Ken Pogran makes in the enclosed messages, so I am taking advantage of his efforts. I think the Count vs. Delimiter discussion should split off from the main stream with a separate list. I will accumulate a mailing list for such a separate discussion and keep it in if any of you want to participate. When it is completed, we should bring the conclusions back to MsgGroup proper. Just let me (Stefferud@ISI) know what you want and I will set up the group with a separate transactions file in . Enjoy, Stef Begin forwarded messages -------------------- Mail from MIT-MULTICS rcvd at 6-JUL-76 0854-PDT From: Pogran at MIT-Multics Date: 07/06/76 1154-edt Subject: MSGFIX Debating Society (a.k.a. MsgGroup) To: Stefferud at USC-ISI Stef, I am getting tired of having my mailbox deluged with stuff regarding MSGFIX. Character counts, delimiters, core dumps -- all totally irrelevant to the original intent and purpose of MsgGroup. Can we impose a moratorium on MSGFIX discussion within MsgGroup, and have those truly interested in MSGFIX debate among themselves (with their own mailing list)? Or maybe we need a more extensive graphic example of just how much of people's time and ARPA's computing resources can be spent on discussions of bit-pushing (character-pushing?)? Or perhaps someone can pick up on Gene McDaniel's comment and get us back on the right track? Regards, Ken -------------------- Mail from MIT-MULTICS rcvd at 6-JUL-76 0856-PDT From: Pogran at MIT-Multics Date: 07/06/76 1157-edt Subject: My previous message To: Stefferud at USC-ISI Stef, If you're wondering why I sent my previous message to you instead of to MsgGroup -- well, maybe someday I'll write a program to convert TENEX address-list files into a form acceptable to the Multics Mailer, but I haven't yet. Makes it very difficult to send messages from Multics to MsgGroup. Perhaps if you think my message is worthwhile and not just sour grapes (again) you could forward it to MsgGroup? Ken -------------------- End forwarded messages ------- 10-MAY-78 22:12:21-PDT,1416;000000000001 Mail from SUMEX-AIM rcvd at 6-JUL-76 1604-PDT Date: 6 JUL 1976 1541-PDT From: KAHLER at SUMEX-AIM Subject: MSGGROUP# 371 Summary of MSGFIX features To: [ISI]Mailing.List: This is the summary of MSGFIX features requested by Panko @OFFICE-1. I am sending this to everybody because it is not a part of the argument, and was requested before the creation of the other list. MSGFIX asks for an input file and an output file. If you do not give an output file, it will update the input file. The program changes character counts only. Once it determines that the file begins with a valid date-size stamp it looks for a line beginning with "-------", followed by a line with a valid stamp. When it finds that combination it puts the correct character- count in the header of the message it just finished reading (ignoring the former count) and copies the message out to the outfile. This works fine in every case but one, the case where two or more messages are juxtaposed inside another. If the integer DEBUG has a non-zero value in it, you can see the uncorrected and corrected headers go by. MSGFIX is available via FTP from [SUMEX-AIM]msgfix.sai. Some comments on msgfix.help. You ought to be able to take the source and rewrite it in whatever language you wish if you don't have SAIL, making modifications to suit you. Rich ------- 10-MAY-78 22:12:21-PDT,8301;000000000001 Mail from USC-ISI rcvd at 7-JUL-76 0106-PDT Date: 7 JUL 1976 0024-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 372 Procesed MsgGroup Proceedings Messages To: [ISI]Mailing.List: The following MSG HEADERs listing includes the substantive messages that have just been moved from [ISI] Message.Txt to Proceedings.MSG, with MSGGROUP# assigned. Hopefully these assigned numbers will aid in referencing each other's messages in our dicussions. In the future, MsgGroup Transactions will be processed in a more timely manner, now that I have handy tools for processing them one at a time as they arrive. Administrative messages hvae been moved into Administrative.MSG, while a complete copy of all messages is kept in TRANSACTIONS.MSG, which now holds 371 messages, with all numbers corresponding to their MSGGROUP#. A copy of the HEADERS SURVEY of each of these files, including any archived portions will be kept in . Best Regards, Stef -- Messages from file: [USC-ISI]PROCEEDINGS.MSG;8 -- WEDNESDAY, JULY 7, 1976 00:05:04-PDT -- 260 6 JUL KAHLER at SUMEX-AIM MSGGROUP# 371 Summary of MSGFIX features (1416 chrs) 259 6 JUL To:[ISI]Mai MSGGROUP# 370 [ Pogran at MIT-Multics: MSGFIX Debating Society (a.k.a. MsgGroup)] (2609 chrs) 258 6 JUL To:[ISI]Mai MSGGROUP# 369 [Richard M. Stallman (RMS@MIT-AI): Mailbox Format Criteria] (1826 chrs) 257 6 JUL DCROCKER at USC-ISI MSGGROUP# 368 RE: MSGFIX, ETC. [IN RESPONSE TO MESSAGE SENT BY RMS@MIT-AI] (1244 chrs) 256 6 JUL PANKO at OFFICE-1 MSGGROUP# 367 MSGFIX - a definition please (384 chrs) 255 6 Jul HENDERSON at BBN-TENE MSGGROUP# 366 Re: Character counts and delimiters (932 chrs) 254 6 Jul ROBERTSON at RUTGERS- MSGGROUP# 365 RE: CHARACTER COUNTS AND DELIMITERS (799 chrs) 253 5 JUL KAHLER at SUMEX-AIM MSGGROUP# 364 Character counts and delimiters (1417 chrs) 252 5 Jul ROBERTSON at RUTGERS- MSGGROUP# 363 RE: MSGFIX, ETC. [IN RESPONSE TO MESSAGE SENT BY RMS@MIT-AI] (2195 chrs) 251 2 JUL To:[ISI]Mai MSGGROUP# 359 [MCDANIEL at PARC-MAXC: Re: Authentification versus MSGFIX] (1319 chrs) 250 2 JUL To:[ISI]Mai MSGGROUP# 358 ((About MSGFIX)) (3469 chrs) 249 30 JUN To: [ISI]M MSGGROUP# 356 $Please change Vittal@ISIB to Vittal@BBNA in MsgGroup$ (234 chrs) 248 30 JUN KAHLER at SUMEX-AIM MSGGROUP# 355 MSGFIX available again (for real) (597 chrs) 247 29 JUN KAHLER at SUMEX-AIM MSGGROUP# 354 TENEX SAIL Consultin (739 chrs) 246 29 JUN KAHLER at SUMEX-AIM MSGGROUP# 353 More on trailers (802 chrs) 245 28 JUN KAHLER at SUMEX-AIM MSGGROUP# 352 Message trailers (903 chrs) 244 28 Jun MOOERS at BBN-TENEXA MSGGROUP# 348 (((MSGFIX))) (2373 chrs) 243 28 Jun MOOERS at BBN-TENEXA MSGGROUP# 347 (About MSGFIX) (728 chrs) 242 26 JUN To:MOOERS at BBN-TENE MSGGROUP# 345 ((MSGFIX)) (2350 chrs) 241 26 JUN To:MSGGROUP MSGGROUP# 344 [STEFFERUD at USC-ISI: [ISI]Message.Tx t;1 Protection?] (1460 chrs) 240 26 JUN To:[ISI]Mai MSGGROUP# 343 Adding: @SUMEX-AIM, Kahler, Rindfleisch, NSmith, (430 chrs) 239 26 JUN To:[ISI]Mai MSGGROUP# 342 Authentification versus MSGFIX (4325 chrs) 238 25 JUN To:MSGGROUP MSGGROUP# 341 [STEFFERUD at USC-ISI: [MOOERS at BBN-TENEXA: (MSGFIX)]] (1620 chrs) 237 25 JUN KAHLER at SUMEX-AIM MSGGROUP# 340 MSGFIX (3504 chrs) 236 25 JUN LIPNER at USC-ISI MSGGROUP# 339 About MSGFIX (650 chrs) 235 25 Jun MOOERS at BBN-TENEXA MSGGROUP# 338 (MSGFIX) (943 chrs) 234 24 JUN FARBER at USC-ISI MSGGROUP# 237 A request for information (655 chrs) 233 23 JUN KAHLER at SUMEX-AIM MSGGROUP# 336 MSGFIX (1349 chrs) 232 19 JUN Geoff at SRI-AI MSGGROUP# 333 I think they're seeing the light.... (4541 chrs) 231 3 JUN WALKER at USC-ISI MSGGROUP# 329 New Intelligent Terminal Program Committee (1239 chrs) 230 28 MAY PANKO at OFFICE-1 MSGGROUP# 328 A Computer Teleconference on Resources and Regulation: a Solicitation for Participants (1263 chrs) 229 13 May An Interested Party MSGGROUP# 323 Mail Monitoring and Personal Mail (1895 chrs) 228 7 May KOHANSKI at RUTGERS-1 MSGGROUP# 322 FAREWELL SPEECH TO THE TROOPS (805 chrs) 227 6 MAY PANKO at OFFICE-1 MSGGROUP# 321 An Electronic Want A (1551 chrs) 226 4 May MYER at BBN-TENEXA MSGGROUP# 320 ((Comment on Panko's CHECK command)) (1947 chrs) 225 30 APR KLH at MIT-AI MSGGROUP# 319 MIT-AI Mail Statistics for Jan-Feb-Mar 76 (1652 chrs) 224 29 APR RMS at MIT-AI MSGGROUP# 318 CHECK (728 chrs) 223 20 APR PANKO at OFFICE-1 MSGGROUP# 317 Another FCC Computer Inquiry (722 chrs) 222 12 APR PANKO at OFFICE-1 MSGGROUP# 315 Computer Message Services--summary of a draft paper (longish) (6591 chrs) 221 8 APR KLH at MIT-AI MSGGROUP# 313 Slight misunderstand ing (880 chrs) 220 7 APR KLH at MIT-AI MSGGROUP# 311 Self-introduction (1712 chrs) 219 5 APR To:[ISI]Mai MSGGROUP# 310 [Vezza: Command Language Structure, DELETE, FORWARD, SUMMARIZE] (5939 chrs) 218 24 MAR To:Geoff at SRI-AI MSGGROUP# 308 (( Forwarded Mail ) (676 chrs) 217 24 MAR Geoff at SRI-AI MSGGROUP# 307 ( Forwarded Mail ) Mail monitoring by Rand Corp. management (1046 chrs) 216 20 MAR To:[ISI]Mai MSGGROUP# 305 [TASKER at USC-ISI: (Vote Tabulation)] (1281 chrs) 215 16 MAR UHLIG@OFFICE-1 MSGGROUP# 304 Comment on the set of ballot comments (2493 chrs) 214 16 MAR UHLIG@OFFICE-1 MSGGROUP# 303 Forwarding a message without inclosures (1658 chrs) 213 6 MAR To:[ISI]Mai MSGGROUP# 302 Recently Processed Messages (2205 chrs) ------- 10-MAY-78 22:12:22-PDT,2684;000000000001 Mail from USC-ISI rcvd at 7-JUL-76 2141-PDT Date: 7 JUL 1976 2133-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 373 [ISI]DELIMITER.LIST (MSGFIX discussion subgroup) Subject: [HENDERSON at BBN-TENEXA: Re: [ Pogran at MIT-Multics: Subject: MSGFIX Debating Society (a.k.a. MsgGroup)]...] From: STEFFERUD at USC-ISI To: AIRPLANES at BBNA, Geoff at SRI-AI, Henderson at BBNA, To: Kahler at SUMEX-AIM, MsgGroup, Robertson at RUTGERS-10, To: Stefferud, [ISI]DELIMITER.LIST: Cc: [ISI]Mailing.List: Message-ID: <[USC-ISI] 7-JUL-76 21:33:44.STEFFERUD> I am setting up the separate discussion group list in [ISI] DELIMITER.LIST for those who are interested. The initial recipients on the list are shown in the TO: field of this message. MsgGroup@ISI is included to capture the traffic, but DELIMITER messages will be siphoned off into MESSAGE.DELIMITER where anyone who is interested may acccess them in the normal ways. Austin Henderson has asked that I forward the following message to anyone whom I think should see it, and I feel that it summarizes much of what we all should have learned from the nitty gritty of the discussion provoked by MSGFIX. So here it is for you all to read. Enjoy, Stef Begin forwarded message -------------------- Mail from BBN-TENEXA rcvd at 7-JUL-76 0825-PDT Date: 7 Jul 1976 1122-EDT Sender: HENDERSON at BBN-TENEXA Subject: Re: [ Pogran at MIT-Multics: MSGFIX Debating Society (a.k.a. MsgGroup)]... From: HENDERSON at BBN-TENEXA To: STEFFERUD at USC-ISI Message-ID: <[BBN-TENEXA] 7-Jul-76 11:22:14.HENDERSON> In-Reply-To: <[USC-ISI] 6-JUL-76 11:31:01.STEFFERUD> Stef: I'm not terribly interested in the detailed debate over MSGFIX, as I am coming around to the position that Hermes ought to make editing of messages easy, and therefore editing of message-files will be less needed. However a program to try and make sense out of a message-file which is not quite acceptable to Hermes ought to be available as well -- also from within Hermes. Doug Dodds and I have taken the MSGFIX discussion as a cue to think about reasonable heuristics for doing "the right thing" on message-files which need cleaning up. The implementation of that little program is now on our list of "things to be done". I should probably stay in touch with any further discussion about MSGFIX, however. So if a subgroup is formed, put me on it. I don't feel any strong desire to have such a subgroup formed however. Austin ------- -------------------- End forwarded message ------- 10-MAY-78 22:12:22-PDT,287;000000000001 Mail from USC-ISI rcvd at 12-JUL-76 1326-PDT Date: 12 JUL 1976 1314-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 374 $Please add wec@RAND-ISD to $ From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]12-JUL-76 13:14:53.STEFFERUD> 10-MAY-78 22:12:22-PDT,3785;000000000001 Mail from SU-AI rcvd at 28-JUL-76 0315-PDT Date: 28 JUL 1976 0251-PDT From: Geoff Goodfellow (GFF @ SU-AI) Subject: MSGGROUP# 375 Mailman of the future -- a computer? To: MSGGRP.DIS[G,GFF]:; n605 2017 27 Jul 76 THE PUBLIC CONCERN: MAIL Consumer column By KAY MILLS (c) 1976, Newhouse News Service WASHINGTON - The mailman of the future may be a computer delivering electronic bills and business messages - perhaps even personal letters - over data networks to stations around the country. The beginning stages of development of electronic funds transfer (EFT) systems and digital data networks between businesses foreshadow this futuristic ''electronic mail'' concept, according to a report prepared for the White House Office of Telecommunications Policy (OTP) by Arthur D. Little, Inc. ''About two-thirds of all first-class mail, and 35 per cent of all mail, is devoted to messages concerned with transactions - orders, invoices, bills and payments,'' the firm told OTP in a report titled, ''Telecommunications and Society, 1976-1991.'' ''EFT techniques can impact a very significant fraction of this mail by making possible the conduct of such transactions through electronic rather than hard-copy messages.'' The report indicated that ultimately perhaps 30 per cent or more of all first-class transaction mail may be handled by EFT techniques. Within a few years, the report added, it is conceivable some firm may market for under $300 printer terminals which can be connected to home telephone lines, to receive and transmit personal and business correspondence. The study does not advocate any particular course for electronic mail development but instead outlines possible scenarios which that development might follow. It discusses what might happen, for example, if the U.S. Postal Service fights competition from electronic firms, using the protection the law grants it now as a monopoly service for first class mail, or if the Postal Service joins the potential competition in cooperative ventures. But there are drawbacks - concern for letter carriers' jobs and for the possible loss of privacy of people's personal mail. Heretofore, the report said, telecommunications gains have been of ''major net social benefit,'' replacing older, less efficient service. ''This may not continue to be the case,'' the study said. The National Association of Letter Carriers is concerned that if the U.S. Postal Service loses the letter business to electronic transmissions, rates for the rest of mail delivery - newspapers, circulars, magazines - will be driven so high those media, too, will find alternate delivery means. James H. Rademacher, president of the Letter Carriers, says he's as concerned about another facet of the plunge toward electronic mail. He thinks advocates of that system are ''unwittingly falling into the hands of a subversive movement in this country which seeks to destroy the most important facts about mail: its security, sanctity and personalness.'' If Americans reach the day when they can turn on the television set in their living room and read a letter from mother in California, Rademacher says, they must be assured that the government has created protections so that everyone else isn't reading that letter, too. For its part, the Postal Service has awarded a two-year $2.2 million contract to RCA's Government Communications Systems Division in Camden, N.J., to determine the technical and economic aspects of an electronic message system. A spokesman added that the Postal Service is already involved with electronic mail to the extent that it currently delivers Western Union mailgrams. JG END MILLS 7-27 ------- 10-MAY-78 22:12:22-PDT,540;000000000001 Mail from USC-ISI rcvd at 30-JUL-76 1120-PDT Date: 30 JUL 1976 1044-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 376 A request for information From: FARBER at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]30-JUL-76 10:44:53.FARBER> Paul Heller of EDUCOM has requested help in identifing machines that have operational mail systems. He knows about pdp 10,11 and Multics . He is especially interested in UNIC 1110's . Can we help him and in the meanwhile get a list for ourselves. Dave ------- 10-MAY-78 22:12:22-PDT,330;000000000001 Mail from USC-ISI rcvd at 30-JUL-76 1313-PDT Date: 30 JUL 1976 1242-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 377 RE: A Request for information From: FARBER at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]30-JUL-76 12:42:55.FARBER> Sorry, that UNIC 1110 was a UNIVAC 1110. Dave ------- 10-MAY-78 22:12:22-PDT,309;000000000001 Mail from USC-ISI rcvd at 2-AUG-76 1609-PDT Date: 2 AUG 1976 1559-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 378 $Add Frankston@MIT-MULTICS, Delete Mealy@ISID$ From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI] 2-AUG-76 15:59:07.STEFFERUD> Stef ------- 10-MAY-78 22:12:22-PDT,507;000000000001 Mail from OFFICE-1 rcvd at 14-AUG-76 1219-PDT Date: 14 AUG 1976 1219-PDT From: HOUGH at OFFICE-1 Subject: MSGGROUP# 379 Panko now receives mail as Hough@Office-1 To: [ISI]Mailing.List: cc: hough at OFFICE-1, rulifson at PARC-MAXC I am currently receiving all my mail as hough at office-1. My mail has not been getting through as panko@offic-1, so if you were looking for m, here I am, folks. Sorry if the disappearance of my office-1 mail box has inconvienced any body. ------- 10-MAY-78 22:12:22-PDT,294;000000000001 Mail from USC-ISI rcvd at 22-AUG-76 1349-PDT Date: 22 AUG 1976 1329-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 380 $Please add Karlton@CMUA$ From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]22-AUG-76 13:29:05.STEFFERUD> Stef ------- 10-MAY-78 22:12:23-PDT,922;000000000001 Mail from MIT-DMS rcvd at 22-AUG-76 1639-PDT DATE: 22 AUG 1976 1836-EDT FROM: COMMUNICATION-DAEMON at MIT-DMS SUBJECT: MSGGROUP# 381 Error while processing message KEYWORDS: ERROR, BUG, PROCESS MESSAGE-ID: <[MIT-DMS].38596> An error occurred while processing a message which may be of concern to you. The message id was <[USC-ISI]22-AUG-76 13:29:05.STEFFERUD> . The message was from MSGGROUP at USC-ISI. The subject was $Please add Karlton@CMUA to Mailing.List$. The PARSING process failed because a MUDDLE error occurred during the processing. This indicates a possible bug, and has been reported to the system maintainer(s). The problem has also been reported to the message system maintainer(s). If you do not understand the reasons for the problem, send a message to the COMMUNICATION-SYSTEM-MAINTAINER for help. Please include the id of the failing message. 10-MAY-78 22:12:23-PDT,309;000000000001 Mail from USC-ISI rcvd at 26-AUG-76 1250-PDT Date: 26 AUG 1976 1244-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 382 $Add DINGMAN@OFFICE-1, Drop GOODWIN@ISI$ From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]26-AUG-76 12:44:58.STEFFERUD> Stef ------- 10-MAY-78 22:12:23-PDT,1160;000000000001 Mail from USC-ISI rcvd at 30-AUG-76 1246-PDT Date: 30 AUG 1976 1225-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 383 MsgGroup membership changes since 1 JUL 1976 From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]30-AUG-76 12:25:53.STEFFERUD> Due to a misunderstanding about the way HERMES discards all addresses following a failure to recognize a local address in an "Input from file" operation, all addresses following Bryan@ISI may have been ommited from my messages to Mailing.list since Bryan@ISI disappeared from the system. (Or since HERMES aquired its new behavior sometime in August. I cannot be sure of what went out.) So, I am recapping the changes in this message: Replace GOODWIN@ISI with DINGMAN@OFFICE-1. Replace WATSON@BBNB with POSTEL@ISIC. Replace PANKO@OFFICE-1 with HOUGH@OFFICE-1. Add KARLTON@CMUA, FRANKSTON@MIT-MULTICS and WEC@RAND-ISD. Remove BRYAN@ISI. You may FTP a new copy from [ISI]Mailing.List or I will send you a new clean copy upon request. Thank you, and Best Regards, Stef ------- 10-MAY-78 22:12:23-PDT,2536;000000000001 Mail from USC-ISI rcvd at 31-AUG-76 2155-PDT Date: 31 AUG 1976 2136-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 384 Processed Transactions Msgs - Summer, 1976 From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]31-AUG-76 21:36:23.STEFFERUD> The following Headers are the messages processed through MsgGroup this Summer. Since there was some confusion regarding the mailing list, I am including all messages in the list, which is only 12 Headers long. Best, Stef -- Messages from file: [USC-ISI]TRANSACTIONS.MSG;6 -- TUESDAY, AUGUST 31, 1976 21:16:41-PDT -- 372 7 JUL To: [ISI]M MSGGROUP# 372 Procesed MsgGroup Proceedings Messages (8301 chrs) 373 7 JUL To:Stefferud, [ISI]DELIM ITER.LIST (MSGFIX discussion subgroup) (2684 chrs) 374 12 JUL To:[ISI]Mai MSGGROUP# 374 $Please add wec@RAND-ISD to $ (287 chrs) 375 28 JUL Geoff Goodfellow (GFF MSGGROUP# 375 Mailman of the future -- a computer? (3785 chrs) 376 30 JUL FARBER at USC-ISI MSGGROUP# 376 A request for information (540 chrs) 377 30 JUL FARBER at USC-ISI MSGGROUP# 377 RE: A Request for information (330 chrs) 378 2 AUG MSGGROUP at USC-ISI MSGGROUP# 378 $Add Frankston@MIT-M ULTICS, Delete Mealy@ISID$ (309 chrs) 379 14 AUG HOUGH at OFFICE-1 MSGGROUP# 379 Panko now receives mail as Hough@Office-1 (507 chrs) 380 22 AUG MSGGROUP at USC-ISI MSGGROUP# 380 $Please add Karlton@CMUA$ (294 chrs) 381 22 AUG COMMUNICATION-DAEMON MSGGROUP# 381 Error while processing message (922 chrs) 382 26 AUG MSGGROUP at USC-ISI MSGGROUP# 382 $Add DINGMAN@OFFICE- 1, Drop GOODWIN@ISI$ (309 chrs) 383 30 AUG MSGGROUP at USC-ISI MSGGROUP# 383 MsgGroup membership changes since 1 JUL 1976 (1160 chrs) ------- 10-MAY-78 22:12:23-PDT,1216;000000000001 Mail from USC-ISI rcvd at 12-SEP-76 1953-PDT Date: 12 SEP 1976 1935-PDT Sender: DCROCKER at USC-ISI Subject: MSGGROUP# 385 Deletion of Format Effectors by FTP server (receiver) From: DCROCKER at USC-ISI To: action, clements at BBN Cc: [ISI]Mailing.List:, Cc: [BBNA]HDISCUSS.MAILINGLIST:, Cc: Noel at ISID Message-ID: <[USC-ISI]12-SEP-76 19:35:57.DCROCKER> Greg Noel just pointed out to me that format effectors were being deleted by the mail system. Since I knew that this was not entirely true, I checked. It now appears to me that the FTP code which receives mail over the net is eliminating form-feeds. Other characters may also be stripped, but form-feeds were the most notable. Since I tried both Sndmsg and Mailer, getting the same effect, I am fairly sure it is the receiving, and not the sending, code. In the past, I had simply assumed that mail senders were intentionally removing the form-feeds, to be nice to people with soft-copy terminals, although I personally found such consideration a nuisance since I could not then easily get a paginated hard copy of their document. Never occurred to me that it was a bug. Dave. ------- 10-MAY-78 22:12:23-PDT,520;000000000001 Mail from USC-ISI rcvd at 13-SEP-76 2106-PDT Date: 13 SEP 1976 2053-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 386 Mailing.List Changes: Lauren, DBrown, PHeller, & Pirtle From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]13-SEP-76 20:53:44.STEFFERUD> Please change Lauren@UCLA-ATS to Lauren@RAND-UNIX, add DBrown@BBN and PHeller@BBN, and remove Pirtle@I4-TENEX. A fresh copy of the complete list will be sent on request. Thank you, Stef ------- 10-MAY-78 22:12:23-PDT,744;000000000001 Mail from USC-ISIC rcvd at 15-SEP-76 1005-PDT Date: 15 SEP 1976 0931-PDT From: POSTEL at USC-ISIC Subject: MSGGROUP# 387 Message Interest Group Suggested To: [ISI]Mailing.List: Walt Ulrich of Tymeshare is quite interested in message exchange systems, and would like to form a interest group on the topic. Unfortuantely Walt does not have access to the ARPANET so does not have an network mailbox. Walt is interested in exchanging papers and memos on the general topic of messages and mail systems. Walt's address is: Walt Ulrich Tymeshare 20705 Valley Green Dr. Cupertino, CA. 95014 Phone: (408) 446-6000 --jon. ------- 10-MAY-78 22:12:23-PDT,1124;000000000001 Mail from USC-ISIB rcvd at 13-SEP-76 0825-PDT Date: 13 SEP 1976 0826-PDT Sender: COHEN at USC-ISIB Subject: MSGGROUP# 388 Re: Deletion of Format Effectors by FTP server (receiver) From: COHEN at USC-ISIB To: DCROCKER at USC-ISI Message-ID: <[USC-ISIB]13-SEP-76 08:26:15-PDT.COHEN> REFERENCE: MSGGROUP# 385 SIn response to your message sent 12 SEP 1976 1935-PDT DAVE, TNX FOR YOUR MSG. I THOUGHT THAT ONLY 'QUEUED" MAIL BENEFITS FROM THE AUTOMATIC ^L-REMOVAL FEATURE. THIS INCLUDES ALL OF MAILSYS (OLD HERMES, AT ISI) AND SNDMSG (OUTPUT, IF THE "Q" OPTION IS SELECTED). AS A STANDARD PROCEDURE HERE, WE INSIST ON USING MAILSYS ALWAYS, EXCEPT WHEN WE CARE FOR THE ^Ls. IF WE DO (E.G. LONG FORMATTED REPORTS) WE USE SNDMSG, JUST TO SAVE THEM. I FIND THE IDEA THAT ANY PROCESS IN THE SYSTEM FEELS FREE TO REMOVE ANYTHING (^L TO START WITH) A LITTLE SHORT OF ACCEPTED. WHAT IS NEXT TO BE REMOVED? SPELLING ERRORS? BAD IDEAS? I HOPE YOU'LL FIX THIS PROBLEM...... BEST OF LUCK, DANNY. P.S. FEEL FREE TO FORWARD THIS MSG, IF YOU WISH SO - DANNY. ------- 10-MAY-78 22:12:23-PDT,632;000000000001 Mail from USC-ISID rcvd at 13-SEP-76 1259-PDT Date: 13 SEP 1976 1253-PDT Sender: NOEL at USC-ISID Subject: MSGGROUP# 389 (Deletion of Format Effectors by FTP server (receiver)) From: Greg Noel To: DCROCKER at USC-ISI Message-ID: <[USC-ISID]13-SEP-76 12:53:50-PDT.NOEL> In-Reply-To: <[USC-ISI]12-SEP-76 19:35:57.DCROCKER> REFERENCE: MSGGROUP# 385 Hi -- Thanks for broadcasting the problem. Please keep me posted on the resolution, since it would be convenient to use the mail system to move our print files automatically to our auto-print directory (moving them from SRI-AI to ISID). -- Greg ------- 10-MAY-78 22:12:24-PDT,1069;000000000001 Mail from BBN-TENEXA rcvd at 13-SEP-76 1136-PDT Date: 13 Sep 1976 1430-EDT From: CLEMENTS at BBN-TENEXA Subject: MSGGROUP# 390 formfeeds in mail To: dcrocker at ISI cc: clements REFERENCE: MSGGROUP# 385 dave, please copy this to whoever was in the list for the previous message. The TENEX ftp server strips formfeeds (actually, converts them to linefeeds, to keep the character count the same) on incoming mail. This was a conscious decision on my part, in response to the receipt of some tomes in my mail, and seeing others with the same problem. i believe that any message long enough to require formfeeds should be sent as a pointer to a file. on a slow terminal, or a scope with a limited number of lines, a formfeed seems simply wrong in a mail file. i realize there will be those who disagree with this view, and of course the code can easily be changed. I would prefer not to change it, and would like to hear argument from those who believe that a mail file is the place for long paginated tomes. /rcc ------- 10-MAY-78 22:12:24-PDT,3981;000000000001 Mail from USC-ISI rcvd at 15-SEP-76 1606-PDT Date: 15 SEP 1976 1517-PDT Sender: DCROCKER at USC-ISI SUBJECT: MSGGROUP# 391 [REPLIES to MSGGROUP# 385 from NOEL@ISID, COHEN@ISIB, CLEMENTS@BBNA] Subject: [Greg Noel: MSGGROUP# 389 (Deletion of Format Effectors by FTP server (receiver))] Subject: [COHEN at USC-ISIB: MSGGROUP# 388 Re: Deletion of Format Effectors by FTP server (receiver)] Subject: [CLEMENTS at BBN-TENEXA: MSGGROUP# 390 formfeeds in mail] From: DCROCKER at USC-ISI To: [ISI]Mailing.List:, To: [BBNA]HDISCUSS.MAILINGLIST:, To: Action, Noel at ISID Message-ID: <[USC-ISI]15-SEP-76 15:17:39.DCROCKER> REFERENCE: MSGGROUP# 385, MSGGROUP# 387, MSGGROOUP# 388, REFERENCE: MSGGROUP# 390 Enclosed are the three responses I got to my initial note. Personally, I view the FTP behavior as a serious bug and believe it should be quickly changed. Note that Clements awaits our arguments to that effect. Dave. Begin forwarded messages -------------------- Mail from USC-ISID rcvd at 13-SEP-76 1259-PDT Date: 13 SEP 1976 1253-PDT Sender: NOEL at USC-ISID Subject: MSGGROUP# 389 (Deletion of Format Effectors by FTP server (receiver)) From: Greg Noel To: DCROCKER at USC-ISI Message-ID: <[USC-ISID]13-SEP-76 12:53:50-PDT.NOEL> In-Reply-To: <[USC-ISI]12-SEP-76 19:35:57.DCROCKER> REFERENCE: MSGGROUP# 385 Hi -- Thanks for broadcasting the problem. Please keep me posted on the resolution, since it would be convenient to use the mail system to move our print files automatically to our auto-print directory (moving them from SRI-AI to ISID). -- Greg ------- -------------------- Mail from USC-ISIB rcvd at 13-SEP-76 0825-PDT Date: 13 SEP 1976 0826-PDT Sender: COHEN at USC-ISIB Subject: MSGGROUP# 388 Re: Deletion of Format Effectors by FTP server (receiver) From: COHEN at USC-ISIB To: DCROCKER at USC-ISI Message-ID: <[USC-ISIB]13-SEP-76 08:26:15-PDT.COHEN> REFERENCE: MSGGROUP# 385 SIn response to your message sent 12 SEP 1976 1935-PDT DAVE, TNX FOR YOUR MSG. I THOUGHT THAT ONLY 'QUEUED" MAIL BENEFITS FROM THE AUTOMATIC ^L-REMOVAL FEATURE. THIS INCLUDES ALL OF MAILSYS (OLD HERMES, AT ISI) AND SNDMSG (OUTPUT, IF THE "Q" OPTION IS SELECTED). AS A STANDARD PROCEDURE HERE, WE INSIST ON USING MAILSYS ALWAYS, EXCEPT WHEN WE CARE FOR THE ^Ls. IF WE DO (E.G. LONG FORMATTED REPORTS) WE USE SNDMSG, JUST TO SAVE THEM. I FIND THE IDEA THAT ANY PROCESS IN THE SYSTEM FEELS FREE TO REMOVE ANYTHING (^L TO START WITH) A LITTLE SHORT OF ACCEPTED. WHAT IS NEXT TO BE REMOVED? SPELLING ERRORS? BAD IDEAS? I HOPE YOU'LL FIX THIS PROBLEM...... BEST OF LUCK, DANNY. P.S. FEEL FREE TO FORWARD THIS MSG, IF YOU WISH SO - DANNY. ------- -------------------- Mail from BBN-TENEXA rcvd at 13-SEP-76 1136-PDT Date: 13 Sep 1976 1430-EDT From: CLEMENTS at BBN-TENEXA Subject: MSGGROUP# 390 formfeeds in mail To: dcrocker at ISI cc: clements REFERENCE: MSGGROUP# 385 dave, please copy this to whoever was in the list for the previous message. The TENEX ftp server strips formfeeds (actually, converts them to linefeeds, to keep the character count the same) on incoming mail. This was a conscious decision on my part, in response to the receipt of some tomes in my mail, and seeing others with the same problem. i believe that any message long enough to require formfeeds should be sent as a pointer to a file. on a slow terminal, or a scope with a limited number of lines, a formfeed seems simply wrong in a mail file. i realize there will be those who disagree with this view, and of course the code can easily be changed. I would prefer not to change it, and would like to hear argument from those who believe that a mail file is the place for long paginated tomes. /rcc ------- -------------------- End forwarded messages ------- 10-MAY-78 22:12:24-PDT,963;000000000001 Mail from BBN-TENEXA rcvd at 16-SEP-76 1249-PDT Date: 16 Sep 1976 1542-EDT Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP# 392 Stef's problem with the aborted address-list. Subject: Re: MSGGROUP# 383 MsgGroup membership changes since 1 JUL 1976 From: MOOERS at BBN-TENEXA To: MSGGROUP at USC-ISI Cc: [ISI]Mailing.List: Message-ID: <[BBN-TENEXA]16-Sep-76 15:42:39.MOOERS> In-Reply-To: <[USC-ISI]30-AUG-76 12:25:53.STEFFERUD> REFERENCE: MSGGROUP# 383 Stef-- When you a list of names into a To: field, HERMES acts as if you were typing it in, and if the list contains an erroneous local name, you get the following message: Not a local user: Nobody@BBNA Continue typed input from: I take it you would prefer a message that tells you more explicitly that the input of the list has been aborted. I'll bring this to the attention of the implementers. ---Charlotte ------- 10-MAY-78 22:12:24-PDT,1116;000000000001 Mail from USC-ISI rcvd at 16-SEP-76 1642-PDT Date: 16 SEP 1976 1634-PDT Sender: DCROCKER at USC-ISI Subject: MSGGROUP# 393 Re: Stef's problem with the aborted address-list.... From: DCROCKER at USC-ISI To: MOOERS at BBN-TENEXA Cc: MSGGROUP, Cc: [BBNA]HDISCUSS.MAILINGLIST: Message-ID: <[USC-ISI]16-SEP-76 16:34:38.DCROCKER> In-Reply-To: <[BBN-TENEXA]16-Sep-76 15:42:39.MOOERS> REFERENCE: MSGGROUP# 392, MSGGROUP# 383 The issue is a bit more complex than discussed, so far. I may not have write-access to the filed list and forcing me to go into the exec, copy the list into my space, and edit it to correct its errors, return to Hermes, and then (after erasing whatever names were successfully incorporated from the last inclusion) re-including the file...well, I guess you get the gist of my concern. Hermes should flag the offending text, indicating the nature of the problem, and then continue to include the file's contents into the field. The user can then edit the text, from within Hermes, and it will be re-parsed upon exiting the editor. Dave. ------- 10-MAY-78 22:12:24-PDT,643;000000000001 Mail from MIT-AI rcvd at 16-SEP-76 1703-PDT Date: 16 SEP 1976 2003-EST From: Ken Harrenstien (KLH @ MIT-AI) Subject: MSGGROUP# 394 ^B & aborted address-list To: Stefferud at USC-ISI, mooers at BBN-TENEXA Message-ID: <871.[MIT-AI] 09/16/76 20:03:29> REFERENCE: MSGGROUP# 392 Good grief, why should the input be aborted at all?? It's a terrible pain, I would think, to have it abort on the first address of a 100-rcpt list. The ITS mailer merely reports the error (which is usually syntactical, since it doesn't need to check for existence) and continues to slurp up whatever is there. So much for that triviality. ------- 10-MAY-78 22:12:24-PDT,922;000000000001 Mail from MIT-AI rcvd at 17-SEP-76 0420-PDT Date: 17 SEP 1976 0208-EDT From: Ken Harrenstien (KLH @ MIT-AI) Subject: MSGGROUP# 395 FTP stuff To: Stefferud at USC-ISI, DCROCKER at USC-ISI, Clements at BBN-TENEX Message-ID: <964.[MIT-AI] 09/17/76 02:08:10> REFERENCE: MSGGROUP# 385, MSGGROUP# 391 Well, our FTP doesn't change anything about the text it receives, which I would recommend as a general measure. I do however think that the business of the FTP MAIL command needs to be rethought; 1) There is no way to specify several recipients on a single site to receive a following message. This is not difficult and would result in vastly improved efficiency. 2) The current ptcl has a weakness already in specifying arbitrary text - . is illegal . There are others, but I don't have time right now. Stef, can you forward this to MSGGROUP if you think it's germane. ------- 10-MAY-78 22:12:24-PDT,882;000000000001 Mail from USC-ISIC rcvd at 19-SEP-76 2211-PDT Date: 19 SEP 1976 2155-PDT From: POSTEL at USC-ISIC Subject: MSGGROUP# 396 so your doing me a favor? To: [ISI]Mailing.List: cc: Clements at BBNA REFERENCE: MSGGROUP# 385, MSGGROUP# 390, MSGGROUP# 391 do me a favor and do me no more favors. i really don't like the idea that ftp servers delete certain format effectors (or fold lines or truncate lines or whatever) at their implementers option because the implementer thinks it looks nicer ot that mail is supposed to be read on a display terminal or whatever reason. i do think that the sender of mail should be allowed to format it to appear any way the sender wants using the standard format effectors. if that format annoys the receiver of the mail the receiver can reformat it for him self or complain to the sender. --jon. ------- 10-MAY-78 22:12:25-PDT,2362;000000000001 Mail from CMU-10A rcvd at 19-SEP-76 2337-PDT From: NEWCOMER at CMUA (JOE N810JN11) Date: 20 Sep 1976 234 EDT Subject: MSGGROUP# 397 format effectors To: STEFFERUD at ISIB Edited-by: Stefferud REFERENCE: MSGGROUP# 385, MSGROUP# 396 Regarding the comments of POSTEL@ISIC: The choice of when to do such a "favor" for someone can be bound at any time. However, one of the poorest choices of time is in the FTP server. If a format effector is to be removed or modified, or lines are to be truncated or wrapped, that decision should be postponed until the latest possible instant. By binding that decision too early, you have provided an information-losing transformation that is not easily invertible; the best choice is not what the FTP designer thinks about how someone may possibly want to use the data received, but to pass the data as received. Let some higher-level protocol (e.g., the mailbox-to-screen transfer program) decide if, at that instant, it wishes to suppress or re-interpret some format effector. As to long mail items: I may or may not like them, but I certainly don't want the FTP mail server to decide that for me. Perhaps that is the only way the data can be transmitted by the sender. In any case, an FTP mail server that changes format effectors should stamp the mail received with large red ink: "DAMAGED IN HANDLING" and perhaps we could then institute "insured mail" where the recipient or sender can sue the implementor of the mail server for damage in transit. Since this seems to impose unnecessary mechanism, it seems so much simpler to just accept the bytes as received, and not play games at the server level. Since this sort of low-level /a priori/ decision process manifests itself in a number of pieces of software and makes it difficult or impossible to use (list of said software which has bitten me in the past will be supplied upon request, complete with editorial comments) I feel very strongly about such decisions; it always appears as if someone who does not understand the application of the data is transforming it to suit some narrow subset of the applications and going through extra work to do so, when making no decision requires no effort and does not constrain later applications! Joe Newcomer ------- 10-MAY-78 22:12:25-PDT,295;000000000001 Mail from USC-ISI rcvd at 21-SEP-76 2122-PDT Date: 21 SEP 1976 2038-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 398 $Please Remove PHeller@BBN$ From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]21-SEP-76 20:38:02.STEFFERUD> Stef ------- 10-MAY-78 22:12:25-PDT,1811;000000000001 Mail from MIT-AI rcvd at 22-SEP-76 0258-PDT Date: 22 SEP 1976 0543-EDT Sender: KLH at MIT-AI Subject: MSGGROUP# 399 Multi-rcpt FTP server installed on ITS From: KLH at MIT-AI (Ken Harrenstien) To: MsgGroup at USC-ISI Message-ID: <2748.[MIT-AI] 09/22/76 05:58:14> I've just installed a new server on MIT-AI, MIT-ML, MIT-MC, and MIT-DM which handles multi-rcpt MAIL as previously discussed; this note both announces and describes the procedure for using it. To specify a recipient, the user process sends XRCP and receives a reply of either 200 for acknowledgement or 450 for refusal. Any number of rcpts may be specified in any order before sending the message text; each is merely stored away until such time as a MAIL or MLFL command is received. Upon completion of either (whether success or failure) all recipient names are flushed. Specifying a recipient name as an argument to the MAIL or MLFL command simply adds it to the list; thus, a null argument is permissible if one or more XRCP's have succeeded, and normal operation without XRCP is as before. Note that if the MAIL or MLFL fails, it is considered to have failed for all recipients which were specified. However, the result of each XRCP has no effect on other XRCP's. Whether or not other servers someday implement this, the fact is that the ITS sites will be using it, and anyone who wants to take advantage of the feature will have our every encouragement... P.S. Does anyone know which network sites don't support the new FTP protocol? I know that the ITS server doesn't, but am willing to spend the night it would require for conversion, provided that "new FTP" is not a completely dead turkey. -Ken ------- 10-MAY-78 22:12:25-PDT,525;000000000001 Mail from USC-ISI rcvd at 25-SEP-76 1830-PDT Date: 25 SEP 1976 1815-PDT Sender: FARBER at USC-ISI Subject: MSGRROUP# 400 Article in Aviation Week From: FARBER at USC-ISI To: [ISI]Mailing.List:, To: Cahcom-steering-committee-members:, To: [BBNA]HDISCUSS.MAILINGLIST:, To: List: Message-ID: <[USC-ISI]25-SEP-76 18:15:20.FARBER> There was a rather good article describing the ARPANET, The Navy C&C Testbed and a bit about the IT in Aviation Week September 27 1976 Dave -------