10-MAY-78 22:09:56-PDT,753;000000000001 Date: 7 JUN 1975 1432-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 001 TCTALK From: FARBER at USC-ISI To: MessageGroup: Message-ID: <[USC-ISI]7-JUN-75 14:32:54-PDT.FARBER> There is a distributed network teleconferencing facility oriented to networks experimentally avilable called TCTALK. It was the result of a thesis of Jim Calvin at BBN. It can be accessed at the ISIA site via TCTALK. questions relative to it can be answered by Calvin or Geoff at SRI-AI. I would recommend that you try it if you have not. Improvements are being made on a time available basis by Calvin. The full discription of TCTALK is available via the net and is in essense Calvins CASE thesis. Contact CAlvin for that. Dave 10-MAY-78 22:09:57-PDT,2463;000000000001 Mail-from: USC-ISI rcvd at 7-JUN-75 2024-PDT Date: 7 JUN 1975 2024-PDT From: WALKER at USC-ISI Subject: MSGGROUP# 002 Message Group Status To: MessageGroup: First let me appologize for not being very responsive to many of you. AS you may have guessed we have been quite busy of late defending this wonderful network that we are responsible for; as "Net Manager" a nasty portion of all this has fallen upon me. My concern here is that it will no doubt get worse before it gets better, so let me also appologize in advance. My reason for seeking to establish a group of people concerned with message processing was (and remains) to develop a sense of what is mandatory, what is nice and what is not desirable in message services. We have had a lot of experience with lots of services and should be able to collect our thoughts on the matter. My goal at present was not to establish "another committee" but to see if a dialog can develop over the net. I sense that to some extent this has already happened but there are many who have not entered the discussion. There are lots of possible reasons for this and I do not wish to force anyone to participate but I strongly urge anyone with comments (positive or negative) to toss them in. While supporting philosophical discussions, I like very much the specifics of the evaluation suggested by Jean Iseli in the message forwarded by Farber on 7 June. Can we try to do this, the results may surprise many of us. I would encourage a FORUM-type setup if its not to difficult to setup, realizing that many (myself included) will have little time to contribute. I worry that such arrangements tend to fragment the overall group but maybe thats good if the fragments report in now and then. I've asked Dave Farber to maintain a list of Message Group participants, he will distribute a file indicator that you should be able to access this time. I'd like to add Rob Stotz at ISIB to our discussions. To the "newcomers" incase you haven't already sensed it, this whole thing is a new attempt, there is no background except for a few messages sent around this week (check with Farber). Again, those of you who do not wish your message files to be filled with "junk mail", feel free to withdraw. I hope from all this to develop a long term strategy for where message services should go on the ARPAnet and indeed in the DoD. Let's have at it. Steve ------- 10-MAY-78 22:09:57-PDT,716;000000000001 Date: 7 JUN 1975 2109-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 003 mailing list for message group From: FARBER at USC-ISI To: MessageGroup: Message-ID: <[USC-ISI]7-JUN-75 21:09:47-PDT.FARBER> An up to date ( I hope) list of the members of the message discussion group will be maintained in my directory for your use. If you would like a copy as it is changed , feel free to copy and tell me and I will forward changes. The directory is [ISI]MSGRP.MAILING-LIST OR [ISI]MESSAGEGROUP.LIST I too second the motion of Steve to Lets have it. I will also maintain a file of correspondance if you miss any or do not feel like making like a file clerk. Dave 10-MAY-78 22:09:57-PDT,1645;000000000001 Mail-from: USC-ISI rcvd at 8-JUN-75 1636-PDT Date: 8 JUN 1975 1629-PDT From: DCROCKER at USC-ISI Subject: MSGGROUP# 004 Use of a Teleconferencing system, in place of Net Mail To: MessageGroup: I have spent the better part of this past spring looking at our teleconferencing capabilities (part of a seminar at ISI) and, as a result, suggest we continue to use Network mail as our communications tool, rather than using TCTALK or FORUM. TCTALK is essentially a real-time system in which participants must painfully watch the typist, who has the "floor," enter his comments. It is a very inefficient process, currently. Forum has a long start-up curve and requires that all participants have access to the same machine. (TCTALK currently only requires access to a Tenex.) Use of Net Mail a) is extrememly convenient for most, if not all, of us, since we already exercise it for other activities; b) allows passive observation of the dialogue, rather than forcing everyone to explicitly catch up on recent comments (5 of us recently blew off any casual observers to our seminar by doubling the size of our online transcript, in the space of 10 days. It became too much work to catch up); c) mail is easily deleted and so "junk" mail is not really a serious problem. Most, if not all of us, have mail reading systems which allow a "menu" review of mail, prior to reading the contents. For the record, I happen to like the promise of teleconferencing, but do not believe our current tools are appropriate for use by other than computer hackers. (cf. the suggestions by PBARAN last week.) Dave. ------- 10-MAY-78 22:09:58-PDT,870;000000000001 Date: 8 JUN 1975 1823-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 005 Administrative suggestion From: FARBER at USC-ISI To: MessageGroup: Message-ID: <[USC-ISI]8-JUN-75 18:23:18-PDT.FARBER> For those of you who want to passively watch the proceedings of the message discussion without seeing a streme of mail arriving at your mail box to be handled I will , with the help of Stefferud, maintain a file called [[ISI]msg.proceedings This file will contain a uptodate list of msg group correspondance. If you do not want to personally receive the mail let me know and I will delete you from the main mailing list but leave you on the list that will be used for non standard correspondance. Dave I will attempt to also arrange a set of keywords that can be used to retrieve from this file. 10-MAY-78 22:09:58-PDT,771;000000000001 Date: 10 JUN 1975 1145-PDT From: DCROCKER Subject: MSGGROUP# 006 Re: Mail to Mealy@HARV-10 To: MEALY at HARV-10 cc: WALKER, FARBER, STEFFERUD, ELLIS, KIRSTEIN, ISELI, PBARAN, cc: VITTAL at USC-ISIB, STOTZ at USC-ISIB, UHLIG at OFFICE-1, cc: WATSON at OFFICE-1, VEZZA at MIT-DMS In response to your message sent 10-Jun-75 11:19 This may seem like a small point, but it could have some impact on development: A number of subsystems (I am specifically aware of SAIL and XOFF) run on Tenex and NON-Tenex sites, with only one copy of the source. Compile-time switches differentiate code for the differnt systems. So it would seem possible, if the basic mail program is sufficiently modular, to provide it for the DEC monitor systems, too. ------- 10-MAY-78 22:09:58-PDT,956;000000000001 Mail-from: USC-ISIB rcvd at 10-JUN-75 1458-PDT Date: 10 JUN 1975 1458-PDT From: PATTI at USC-ISIB Subject: MSGGROUP# 007 MESSAGE COMMITTEE INFO To: MESSAGE SERVICES COMMITTEE: cc: ELLIS A testable message system has been provided by BBN/ARPA at ISI as "XMAIL" and BBNA, B, C and D as "MAILSYS." These subsystems are there per our recommendations for a reasonable period to be evaluated and constructively critiqued to aid finalization for public release later. I urge all Message Committee members to actively participate in the testing phase along with other "selected" testors. Steve Walker has asked others to join a wider group called "Message Group" for which a list is available in: [ISI]MESSAGEGROUP.LIST Incidentally, an alternative system called NMSG is available at ISI and I invite your comments/suggestions on this system. Both systems should be self-instructing! Regards, Tom TOE/ph ------- 10-MAY-78 22:09:58-PDT,253;000000000001 Mail-from: USC-ISIB rcvd at 10-JUN-75 1553-PDT Date: 10 JUN 1975 1553-PDT From: PATTI at USC-ISIB Subject: MSGGROUP# 008 NEW NAME FOR MESSAGEGROUP.LIST To: FARBER at ISI cc: ELLIS PLEASE ADD Thanks, Patti for Ellis ------- 10-MAY-78 22:09:58-PDT,836;000000000001 TO: INTERESTED PERSONS FROM: Whoever I want to claim to be SUBJECT: MSGGROUP# 009 RE: THE MYTH OF SECURITY One reason that some people keep security on their directory, rather than simply on sensitive, individual files, is to force the delivery of mail to be by mailer, rather than by SNDMSG. I believe that it is their perception that mail so delivered is somehow 'authenticated'. This note constitutes proof that such authentication does not, in fact, take place. I could as easily have stated that the message was from LICKLIDER. This is not meant as a criticism of the current mechanism, since I do not believe it has ever been touted as 'secure'. rather, I just wanted to clarify the point, in some people's minds. DAVE CROCKER. (Note that this is local mail to some people. The 'hole' is not net-specific.) 10-MAY-78 22:09:58-PDT,290;000000000001 Mail-from: USC-ISI rcvd at 11-JUN-75 1013-PDT Date: 11 JUN 1975 1013-PDT From: ELLIS at USC-ISI Subject: MSGGROUP# 010 NEW "MSG" VERSION To: MessageGroup: THE NEW VERSION OF "MSG" AT ISI IS CALLED "NMSG". IT IS IN THE TESTING PHASE BUT SHOULD BE USEABLE BY THIS GROUP. ------- 10-MAY-78 22:09:58-PDT,565;000000000001 Mail-from: USC-ISI rcvd at 12-JUN-75 0503-PDT Date: 12 JUN 1975 0503-PDT From: WALKER at USC-ISI Subject: MSGGROUP# 011 NMSG To: MessageGroup: TOM ELLIS: Why do we put up systems with out documentation?????? NMSG - ? # yeilds "Documentation for # Not Available" Why is NMSG available without this???? I really hate to get mad about this but will we never learn? Please do somethingto get some documentation for NMSG online or pull it off the system. In the future do not put any system "up" without documentation. Steve ------- 10-MAY-78 22:09:58-PDT,976;000000000001 Mail-from: USC-ISI rcvd at 12-JUN-75 0549-PDT Date: 12 JUN 1975 0549-PDT From: WALKER at USC-ISI Subject: MSGGROUP# 012 NMSG Complaints, Addendum To: MessageGroup: Tom, ? ? in NMSG gives a nice summary. I'll admit that "#" is labeled "news" and perhaps there is no "news" yet, but why isn't there a file which says "No news yet" instead of "Not Available"? Will there be a "five"page (not 25 page) description of NMSG commands? When? First impressions of NMSG are good, I still don't understand why "Answer" works only on the current message, while "Forward"allows a . Don't change Forward, change Answer! If this were done, is there any need for the Go To command? I'm bugged by user interaction details like "no documentation" and the differences between the way answer and forward work. I note with great joy that NMSG now prints the message number at the beginning of the message print out. Great! Steve ------- 10-MAY-78 22:09:58-PDT,594;000000000001 Date: 12 JUN 1975 1043-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 013 Current Message Group Mailing List From: FARBER at USC-ISI To: MessageGroup: Message-ID: <[USC-ISI]12-JUN-75 10:43:25-PDT.FARBER> This is the current contents of the file [is]messagegroup.list (also msgrp.mailing-list) MessageGroup: @BBN, Burchfiel, Myer, Gilbert, @ISI, tasker, Mclindon, Walker, Farber, Stefferud, Ellis, Kirstein, Iseli, Dcrocker, pbaran, @isib, vittal, Stotz, @Office-1, Uhlig, Watson, @Mit-DMS, Vezza @HARV-10, mealy, Dave Farber 10-MAY-78 22:09:59-PDT,355;000000000001 Mail-from: USC-ISI rcvd at 12-JUN-75 1337-PDT Date: 12 JUN 1975 1334-PDT From: ELLIS at USC-ISI Subject: MSGGROUP# 014 "NMSG" STATUS To: [ISI]MessageGroup.List: I'D LIKE TO REMIND ALL THE "NMSG" IS ONLY AT THE EXPERIMENTAL PHASE AND HAS NOT BEEN GENERALLY ADVERTISED. STEVE WALKER: THANKS FOR YOUR CONSTRUCTIVE COMENTS. ------- 10-MAY-78 22:09:59-PDT,751;000000000001 Mail-from: USC-ISI rcvd at 12-JUN-75 1338-PDT Date: 12 JUN 1975 1329-PDT From: VITTAL at USC-ISI Subject: MSGGROUP# 015 NMSG To: [ISI]MessageGroup.List: There is a new one on on all the ISI machines. It fixes some of the questions Walker had about the news feature. If you are interested, the manual (almost up to date) resides on NMSG.MAN and the news (which is extracted from the help file) is NMSG.DOC. If you would like a hard copy mailed to you, let me know (on ISIB, please), and I'll ship you one. My appologies for the correct documentation not being on line; as excuses go, it seems like an old help file somehow got in the way. We will be extra careful in the future. John ------- 10-MAY-78 22:09:59-PDT,545;000000000001 Mail-from: USC-ISI rcvd at 12-JUN-75 1826-PDT Date: 12 JUN 1975 1826-PDT From: WALKER at USC-ISI Subject: MSGGROUP# 016 More on NMSG To: [ISI]MessageGroup.List: I really like the "TO: First Addressee" feature for messages which I originate. Very nice! I think user prompting features in Bananard are still better then NMSG. Giving the user a prompt for what to do next after tying a command should be easy. For example: Forward (message seq): We're getting there! Thanks for fixing the help files. Steve ------- 10-MAY-78 22:09:59-PDT,728;000000000001 Date: 13 JUN 1975 0925-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 017 a query re terminal speeds From: FARBER at USC-ISI To: [ISI]MessageGroup.List: Message-ID: <[USC-ISI]13-JUN-75 09:25:52-PDT.FARBER> I would like to point out to those who are blessed with access that allows 2400 speed terminals that there are those of us who get our mail at 300 speed. I wonder what the effect is on the appearance of the mailsystems. I believe that many of the ways we are doing things would change. (like the appearance of network notes -- short and sweet). Should we be thinking of this as an important issue or will our users, as opposed to implementers, have high speed access? Dave 10-MAY-78 22:09:59-PDT,1967;000000000001 Mail-from: USC-ISIB rcvd at 13-JUN-75 0937-PDT Date: 13 JUN 1975 0933-PDT From: VITTAL at USC-ISIB Subject: MSGGROUP# 018 Re: Walker's NMSG comments To: Message Group: First, the prompting issue. There are three different type-out (prompting) modes in NMSG. There is the normal that you get when you start it up, a verbose mode which the V command will provide, and a concise mode which the K command will provide. The V command will cause additional prompting like Forward (message sequence) as Steve suggests. The only reason you want the verbose mode is when you are starting to learn msg. After a relatively short startup time, the additional typeout becomes overbearing, but if you want it you can always type V and get it. The concise mode shortens typeout even more than the normal mode, and is sometimes very criptic -- it should NOT be used by novices. About the Answer vs. Forward. It is well understood what it means to forward several messages at once (this is allowed), but it is not understood what it means to answer several messages simultaneously. Does everybody on all lists get a copy of the response? I think that the only reasonable solution is to be able to answer exactly one message. The problem then becomes (in the MSG domain) of how do you specify the message number being answered and the sub-command (if one is given) both in a clean way that is consistent with the rest of the MSG command structure. A suggestion goes something like the following: Answer in message number: xx This is probably the closest alternative solution to the one that's implemented that is in the right 'spirit'. However, the reservation that I have is that it is probably better to know what you're answering BEFORE you specify the . These are about the only reasons that it's structure is as it currently exists. Any suggestions? Forward will not be changed. John ------- 10-MAY-78 22:09:59-PDT,3702;000000000001 Mail-from: USC-ISI rcvd at 13-JUN-75 1350-PDT Date: 13 JUN 1975 1350-PDT From: TASKER at USC-ISI Subject: MSGGROUP# 019 NMSG Observations To: [ISI]MessageGroup.List: Dear Group: I am finding NMSG quite interesting and not too hard to adjust to from BananaRD (which was my previous favorite). I particularly enjoy the convenience the F and A commands provide: previously I had to use temporary files for such activity (especially F) and I never felt that a non computer freak would take to that. I do find the Answer command could use another sub-option, namely, one that allows the answerer to ADD a person to the address list. Sometimes, after a dialogue with one or two we find it desirable (or necessary) to include another party. (Sometimes older messages must be forwarded to him, but as often, there is enough context in the answer to make that unnecessary.) In mentioning this to Nancy (NGoodwin@BBNC) she indicated the following: With MAILSYS REPLY is used the way ANSWER is in NMSG, I guess. The author of the reply can add to the address list, and the subject line if he/she answers NO in response to an automatic system question SEND? after the body of the message is complete. The additions appear in the second and onward lines of the message header fields, so would not appear in a SURVEY (I'm not sure about NMSG surveys). If the author adds still more text, the SEND question is not asked again, but use proceeds as usual. What do the rest of you find regarding the need for such an additional suboption? Regarding the filtering: Maybe I just don't keep enough mail on-line to fully exercise these options - but I find the subjects of the messages I receive often of VERY litle help in pointing to the contents. This becomes worse after an extended number of messages have been exchanged on a topic. The national level military community has come to the same conclusion and is now having systems built that construct lists of keywords from a complete text search. However, maybe provision of these masks will encourage people to pay more serious attention to the construction of the subject. (This is not always the answer since we often want to summarize our main interest or thought in the subject for emphasis or attention-catching, thereby leaving out any subordinate thoughts that might have been included in the text. Furthermore, the author's keywords may well not be those used by the recipient.) For the present, I tend to use separate files to keep my stuff in order. Anyway, the military (I include the intelligence functions in that term) has struggled with the problem and there is, as yet, no non-trivial solution. I have had some problem with "Are you sure you want to abort?" message under the TO and CC portions of any of the commands involving SNDMSG with an environment of two to three line hits per minute. So far, whenever a line hit(s) has caused the abort message, I have immediately responded with "N" and received the abort message at least another time -- if not several more times. Is this just a function of my noisey lines? Re Dave's comment about speed of terminal: I agree!! (although you might not have guessed it from the length of this missive). The terminal speed will also have a very significant effect on the communications (Net) and the host loading. The way I used the 2400 bps terminal in Rob's office was VERY different from the way I use my 300 bps TI735. Anyway, guys, keep up the good work. You have come a ways from READMAIL. ALOHA, Pete Tasker (At CINCPAC Headquarters, Hawaii) ------- 10-MAY-78 22:09:59-PDT,1093;000000000001 Mail-from: USC-ISI rcvd at 13-JUN-75 1432-PDT Date: 13 JUN 1975 1424-PDT From: TASKER at USC-ISI Subject: MSGGROUP# 020 NMSG Abort Character/Sequence To: [ISI]MessageGroup.List: cc: NGoodwin at BBNC, wilcox, pacomj6 John: The message I just sent to you Re NMSG was aborted in the middle of transmission to the addressees. I was called away from the terminal while SNDMSG was doing its laborious thing with the distribution list and some line hits caused the abort message and also produced a "y". Presto! The rest of the addresses had to be included in a retransmittal. Extensive experience with line hits and TECO suggests to me that DEL is probably one of the poorest choices for an abort character. Furthermore, I think the abortion process at certain stages of activities (like the TO and CC and Send) should require more than just two letters. It is very unlikely that I would abort in these stages, so, as a result, I would be very happy to put up with having to type in "YES" and then confirm with a . Aloha, Pete -- ------- 10-MAY-78 22:09:59-PDT,938;000000000001 Mail-from: USC-ISI rcvd at 13-JUN-75 1512-PDT Date: 13 JUN 1975 1507-PDT From: FARBER at USC-ISI Subject: MSGGROUP# 021 an answer and an item for the group To: [ISI]MessageGroup.List: 1 13 JUN DCROCKER Re: a query re terminal speeds 2 13 JUN CALVIN at BBN-TENEXA Hg 1 -- ************************ Date: 13 JUN 1975 1140-PDT From: DCROCKER Subject: Re: a query re terminal speeds To: FARBER In response to your message sent 13 JUN 1975 0925-PDT Oh boy, do I agree with your concern! ------- 2 -- ************************ Mail-from: BBN-TENEXA rcvd at 13-JUN-75 1249-PDT Date: 13 JUN 1975 1545-EDT From: CALVIN at BBN-TENEXA Subject: Hg To: farber at ISI Point of information (i just got a note via somewhere about this): i wrote HG here at BBN. If you've any questions or comments about it, please feel free to send them to me. jim calvin ------- ------- 10-MAY-78 22:10:00-PDT,2075;000000000001 Mail-from: USC-ISI rcvd at 13-JUN-75 1515-PDT Date: 13 JUN 1975 1515-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 022 Message FILING Function To: [ISI]MessageGroup.List: cc: STEFFERUD Greetings, NMSG certainly is a step forward. It is my choice for processing my own files of messages. In fact, I find that NMSG is really my on-line file processing system for my "Network" office. I really have two offices. One in here and the other out there with conventional fixtures and file folders etc. What I have out there, but don't have in here, is some way to make notes on the corners of my messages. Out there, I keep track of who got copies: bcc from me, forwarded through me, etc. I would like to see the discussion group consider that NMSG, XMAIL, HG, ETC. are really on-line message filing systems that should allow us to do the kinds of things we do with paper files, in addition to the kinds of things we do with computer files. I don't see any reason to give up the benefits of one to get the other. I realize that this raises some difficult problems, but not insurmontable ones. The most difficult part would appear to be the means for modifying a message after it is received, in order to attach notes to the corners. What I suggest is a FILING field that I can add, the same way that I can add a BCC field to an outgoing message in XMAIL. (I sure wish NMSG had BCC.) Then we need "String Search" on the new FILING field so we can go looking for things by our rememberence of our annotations, instead of what some sender thought I would like to have in the SUBJECT field. It should be obvious that there is no way for the senders of messages to get the desired thing in the SUBJECT field more than half the time. In terms of ISELI's Functional list, I suggest that we add the FILING function. By the way, I endorse Iseli's list and look forward to seeing how our competing systems show up when the evaluators show us their results. Best regards to you all, Stef ------- ------- 10-MAY-78 22:10:00-PDT,879;000000000001 Date: 13 JUN 1975 1900-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 023 stefferud 13 june 1975 1515 pdt From: FARBER at USC-ISI To: [ISI]MessageGroup.List: Message-ID: <[USC-ISI]13-JUN-75 19:00:05-PDT.FARBER> I agree with the need expressed by Stef. I feel that I am turning into a file clerk. As do many of us we keep separate files that we put different items into. I note the KEYWORD feature of the MAILSYS (XMAIL) system and feel that the two things are interrelated. One problem is that there is no way I can "add" a field to a message I have received and then do something with it. If I could add the KEYWORD field or for that matter a subject extention field etc then I believe that much of what stef wants could be gotten without much apparatus. In addition I think the general capability would be useful. Dave 10-MAY-78 22:10:00-PDT,719;000000000001 Mail-from: USC-ISIB rcvd at 18-JUN-75 2049-PDT Date: 18 JUN 1975 1228-PDT From: VITTAL at USC-ISIB Subject: MSGGROUP# 024 NMSGG Release as MSG To: Message Group: I would like to release NMSG in its current form to the world at large sometime next week. It is intended to replace the current MSG. If there is anything you feel strongly about seeing in the released version, or there are any objections to its being released, please let me know. This is not meant to indicate that the development of MSG will terminate. There should probably always be an experimental version open to the group which represents the current state of development of MSG. I await your comments. John ------- 10-MAY-78 22:10:00-PDT,4071;000000000001 Mail-from: BBN-TENEXA rcvd at 18-JUN-75 2106-PDT Date: 18 JUN 1975 2242-EDT Sender: MYER at BBN-TENEXA Subject: MSGGROUP# 025 COMMENTS ON MESSAGE SYSTEMS From: MYER at BBN-TENEXA To: [ISI]MessageGroup.List: Cc: PEW, NICKERSON Message-ID: <[BBN-TENEXA]18-JUN-75 22:42:33-EDT.MYER> Here are some initial thoughts on NMSG and Mailsys. First off, I'd like to comment separately on what we see as the two basic functions of these programs -- reading and processing existing messages on the one hand and creating new messages on the other. The message processing part of NMSG has an extremely clean, smooth human interface. It lets most of the essential things happen with a minimum of effort and permits the user a simple mental model of what's going on. In contrast, the MAILSYS reading and processing commands have tended to confuse people, and make some rather basic operations quite hard to accomplish. For some time we've been in the midst of overhauling this part of Mailsys, with the aim of making it much more attractive to its user. Jim Calvin's HG program was an early experiment in this direction. In the overhaul process, we have found it profitable to draw on the good work that went into MSG and its predecessors, and the same is certainly true of NMSG. Some things we particularly liked in NMSG and will bring out in a new Mailsys are: . the simple command language . the way of specifying message sequences and the very easy way you can get special sequences (by A,D,F, etc.) . the explicit message pointer (current message number) and the manipulations you can perform on it. . the uniformity of command groups such as PUT, TYPE, LIST and MOVE. We also liked convenience features such as the automatic surveying of recent messages, the inclusion of headers on message listings, printing "+" and "-" on surveys, and the ability to specify an object file on entering NMSG. We have a somewhat different view on the matter of message creation. In company with several other systems NMSG relies on the earlier SNDMSG program as its workhorse for outgoing messages. As you all know, SNDMSG employs a prompt-driven form of input that leads the user through the steps of message creation. Our view is that this approach has several limitations: . You have to create message parts in the fixed order that's built into SNDMSG. . There's no way to go back and change a part once you have created it. . It's hard to see how you could gracefully extend SNDMSG to let the user select a subset of the many header fields now allowed in RFC-680. Because of these problems we took a "user-driven" rather than prompt-driven approach in structuring the create part of Mailsys. Hence the separation between creating a message and sending it, the ability to create message parts in any order and at the "top level" of Mailsys, and the ability to manipulate message parts, once created, through DISPLAY, ERASE, EDIT, FORMAT, ADD, and SAVE. An interesting by-product of this approach is that it's quite easy to make special prompt-driven sequences by "wiring up" groups of create primitives. The MAILSYS commands FORWARD, REPLY, and SNDMSG were all done this way, and we will soon make it possible for users to specify their own sequences. We are frankly pleased with how this part of Mailsys has turned out. However, that doesn't prove that the world will be, so we'd very much appreciate any feedback you can provide. In particular, we'd like to know how the rest of you feel about user driven vs prompted input, and how you feel about our particular implementation, specially with regard to human factors. The foregoing sums up our initial reactions. However, we're continuing to review both systems, and I expect to have some further thoughts and questions in the next few days. /Ted Myer 10-MAY-78 22:10:00-PDT,1012;000000000001 Mail-from: USC-ISI rcvd at 19-JUN-75 1138-PDT Date: 19 JUN 1975 1137-PDT From: WALKER at USC-ISI Subject: MSGGROUP# 026 Al, Thanks, Welcome and a Complaint To: [ISI]MessageGroup.List: All that amazing stuff and no subject for my simpleminded system (namely: me) to file by. Really great! Its not your long windedness that bothers me, its the two feet of my valuable paper that you wasted after you were finished but your system wasn't. Anyway, thanks for your valuable comments. I think many good ideas are beginning to appear more and more often here.Perhaps there is hope in this process converging on a set of reasonable concepts. I for one would like to try the ISI version of your system. Sounds very interesting (and anything that can eat up all those keywords must be wonderful). I am gratified to note that most members of the Message Committee have joined our dialogue, and no one has begged to get out yet. Thanks for all your contributions. Steve ------- 10-MAY-78 22:10:00-PDT,8504;000000000001 Mail-from: MIT-DMS rcvd at 19-JUN-75 0946-PDT DATE: 19 JUN 75 1207-EDT FROM: Vezza at MIT-DMS SUBJECT: MSGGROUP# 027 KEYWORDS: no-conference, simplicity-of-use, message-service-complexity, KEYWORDS: message-composer, message-reader, third-party-record-service, KEYWORDS: answer-message-group, high-speed-terminals, message-systems ACTION-TO: Mealy at HARV-10, Watson at OFFICE-1, Uhlig at OFFICE-1, ACTION-TO: Stotz at USC-ISIB, Vittal at USC-ISIB, PBaran at USC-ISI, ACTION-TO: DCrocker at USC-ISI, Iseli at USC-ISI, Kirstein at USC-ISI, ACTION-TO: Ellis at USC-ISI, Stefferud at USC-ISI, Farber at USC-ISI, ACTION-TO: Walker at USC-ISI, Mclindon at USC-ISI, Tasker at USC-ISI, ACTION-TO: Gilbert at BBN-TENEX, Myer at BBN-TENEX, ACTION-TO: Burchfiel at BBN-TENEX MESSAGE-ID: <[MIT-DMS]19 JUN 75 12:08:01-EDT.17739> Sorry to have been silent for so long. I think I finally caught up with what has transpired thus far, so I'll add some of my comments to this potpourri. There certainly are things you can do with a high-speed terminal that are at best painful with a 30 or 60 character/second one. It admits to a different modus operandi. One is not so worried about compressing things into one line. One scans and searches data bases differently. I don't mean brute force, but at each point in the search, more information about the situation can be presented to the user. For instance, because I typically use a 2000 character/second terminal, I don't mind printing out 20 or so message headers including the subject field when I am searching for a message in my data base (which, by the way, currently contains over 600 messages). Also, one of my pet peeves is that no message system (including the DMS message system) expands the TO field so that one can see who was sent a copy of a message when the TO field was specified by a list-name instead of by a list. Again, because of the high speed terminal I use, I don't mind having the list expanded and seeing all the names. However, I realize that those with low speed terminals would object, and rightly so. This is a problem because the list of names is modified by additions and deletions; therefore, it is not always possible to ascertain exactly who has obtained a copy of a paticular message. I think you can see what I am getting at. It is often important for coordination purposes to know who has been sent what. This is especially true at the executive decision making level. Solution: Transmit the list name and the list. Modify message reading systems to inhibit printout of the list per se, but allow the user the option of requesting the list when he desires it. A person composing a message should be able to modify any field at any time except those fields that are stamped by the message system, i.e., sender for athentication purposes, date, time, and message id fields. Likewise the recipient, for the purpose of adding notes, keywords, comments, etc. Why is it not this way? I suspect that there is some notion in the minds of message system implementers about message integrity, the idea being that a message system which allows users to tamper with messages could not be used for record traffic. Thus, I suspect many of the difficulties associated with adding notes, changing fields, etc., is really a design decision. I don't know this for a fact, but I suspect it's true. One solution would be to provide a third party recording service for record traffic. Thus, when anyone wants to send a recorded message, he would send it indirect through the third party recording service which would stamp the message, send it out to each recipient, and keep a copy of it for record purposes. Although this seems cumbersome, I think it would be far easier to get such a mechanism certified than it would be to get message systems and operating systems certified. Someone, I believe Vittal, raised a good issue about using one message to answer several. (As I am doing with this one.) Clearly, we want to be able to do that. Perhaps it wants to be a different command, such as "answer group", where the arguments to that command are either a list of mesages or a group name for a set of messages that have been collected under that group name. Reply to and references want to have all the reply to and reference numbers in those fields. The subject field probably doesn't want to be stuck in automatically. The To and Carbon Copy fields probably do, but again, the sender must be given the option of editing them. I think Paul Baran had a good point about making a simple system. We indeed should have the capability somewhat like the one he described, but the system shouldn't stop there. That is to say, if a user of such a system wants more capability and is willing to learn how to use it he shouldn't be prevented from doing so. It has been my observation that once people get hooked into one of these systems, even "non-computer types", they demand more, not less capability, and nothing is more frustrating than to discover that one can't perform a seemingly simple task because the system doesn't provide the capability. The difficulty lies in getting over the initial hurdle so that the person can see for himself that use of the system provides a pay off. Having done something very similar once before -- that is, from the DMS, automatically log in to another computer on the ARPANET, activate A program and obtain results from that program, all without the user knowing the details of how it was done or for theat matter hiding it so that he didn't know that another computer system was being used. It can be done. It would be interesting and useful to develop such an adjunct to the message services, but for such a system to be made operational a great deal of cooperation is necessary. For instance, I have noticed that recently ISI had a global change of account numbers. If systems like ISI still wanted to maintain such flexibility and there were many terminals on the Net that logged in automatically, each terminal's program, micro-code or whatever, would need to be updated to change account numbers. This is only one simple problem. There are many others. I don't mean to discourage such a project, but what I am trying to point out is that it is not as trivial as it might sound I can sympathize with the file clerking operations necessary to maintain an orderly file system. Currently, every evening a daemon runs on the DMS, indexes, all messages I have received or sent the previous day by the following fields: To, From, Blind Carbon Copy, Carbon Copy, Keyword, Filed-under, Message ID, References, Reply To, Sender and Date and inserts the messages into a data base. An Information Retrieval System is available which allows retrieval using the indices. I have found it very useful. Our programming system, including the Information Retrieval System, PAGE 2 is now operation on ISI. Would one or two of you like your own private indexing, filing and retrieval system for your messages? Any takers? The IRS won't be integrated into the reader as it is on the DMS but I think it still might prove useful. Also, you may have to manually start the index job until it is made an autostart job (a trivial operation). There are a number of people who are participating in this discussion who probably heard of the DMS message system. Therefore, I am sending by US Mail to Faber, Steffenrud, Tasker, Walker and Baran copies of some of the documentation on the DMS message system. If anyone else wants a copy, send message me a request. Let me cast my vote for not using a conferencing system and for staying with message systems as a means for communication, mainly because the message systems performed a rendezvous so nicely and I don't know of a conferencing system that performs the rendezvous well yet. For those of you using low speed terminals, I apologize for being so long winded. Steve, as you no doubt discovered, I already have an account on ISI. Al 10-MAY-78 22:10:00-PDT,803;000000000001 Mail-from: USC-ISI rcvd at 19-JUN-75 1506-PDT Date: 19 JUN 1975 1506-PDT From: ELLIS at USC-ISI Subject: MSGGROUP# 028 COMMAND MNEMONICS To: [ISI]MessageGroup.List: I think it is time for this group to try to publish a set of "preferred" command mnemonics for message processing. Hopefully, it is not too late! However, if we don't, we can only blame ourselves for further proliferation. I suggest a way to get started is for Myer and Vittal to provide a short treatise on pro and con of their approaches (i.e., Vittal's obvious problems with his single letter commands .. albeit they're very efficient). Also, comments from Gilbert, Uhlig and Tasker on any serious conflicts we're generating with deeply ingrained DoD traditions. Regards, Tom TOE/ph ------- 10-MAY-78 22:10:01-PDT,872;000000000001 Mail-from: MIT-DMS rcvd at 19-JUN-75 1514-PDT DATE: 19 JUN 75 1726-EDT FROM: AV at MIT-DMS SUBJECT: MSGGROUP# 029 My Apologies. KEYWORDS: carriage-returns, field, subject, Apologies ACTION-TO: Mealy at HARV-10, Watson at OFFICE-1, Uhlig at OFFICE-1, ACTION-TO: Stotz at USC-ISIB, Vittal at USC-ISIB, PBaran at USC-ISI, ACTION-TO: DCrocker at USC-ISI, Iseli at USC-ISI, Kirstein at USC-ISI, ACTION-TO: Ellis at USC-ISI, Stefferud at USC-ISI, Farber at USC-ISI, ACTION-TO: Walker at USC-ISI, Mclindon at USC-ISI, Tasker at USC-ISI, ACTION-TO: Gilbert at BBN-TENEX, Myer at BBN-TENEX, ACTION-TO: Burchfiel at BBN-TENEX MESSAGE-ID: <[MIT-DMS]19 JUN 75 17:31:26-EDT.17754> My very humble apologies to all of you. All was my fault not the systems, the missing subject field and the 100 or so carriage-returns at the end of the message. Al 10-MAY-78 22:10:01-PDT,1044;000000000001 Mail-from: USC-ISI rcvd at 19-JUN-75 1541-PDT Date: 19 JUN 1975 1526-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 030 RE: Command Nmemonics To: ellis at ISI cc: [ISI]MessageGroup.List: Tom, I agree completely on the need for choosing prefered or standard nmemonics for message filing systems, but I would like to see the nmemonics structuring alternatives expanded beyond a choice between MSG and XMAIL. For example, the NLS approach to menu hierachies should be included in the exploration. I don't know that NLS has the better answer, but their approach has received a great deal of thought and we should hear from them what the advantages are and why they like it. I think this issue is at the core of the problem. XMAIL assumes that the TENEX command structure is the best basis, while MSG assumes that there is some other more humanly intuitive structure. MSG has some of the properties of the NLS structure, but has not carried it through out the language. Best Regards, Stef ------- 10-MAY-78 22:10:01-PDT,1147;000000000001 Mail-from: USC-ISI rcvd at 19-JUN-75 1613-PDT Date: 19 JUN 1975 1541-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 031 Re: appologies To: myer at BBN cc: [ISI]MessageGroup.List: Hi Al, Today my TI'#% is running at about 6 chars per second for reasons that are not obvious, either net congestion or ISI overload. I for one would just as soon not see the entire addressee list on every message all day. Dealing with the effluvia from this terminal is already bad enough without any surplus. May I suggest a convention that some of my friends and I use for short messages (notes we call them) which can be fitted into one line of SUBJECT text. We bracket the Subject in $......$ to alert the receiver to not bother printing it out since it is all contained in the SUBJECT part of the SURVEY. Needless to say these notes must be very short to avoid long printouts on the right hand half of the page. Also, I am pleased to accept your appology. I appreciate the difficulty of remembering that some of us are in oxcarts when you are zooming around in your masserati. Best regards, Stef ------- 10-MAY-78 22:10:01-PDT,544;000000000001 Date: 20 JUN 1975 1004-PDT Sender: NRL at USC-ISI Subject: MSGGROUP# 032 message group membership From: NRL at USC-ISI To: FARBER Cc: NRL, GILBERT at BBN, Bergstrom at BBN Message-ID: <[USC-ISI]20-JUN-75 10:04:34-PDT.NRL> Hi Dave, I just reviewed the contents of the MESSAGE.PROCESSING file and am interested in joining the discussion. Could you include me (NRL@ISI) and Clint Bergstrom (BERGSTROM@BBN - works with Dick Gilbert on COTCO) as memberss of the message dis- cussion group. Thanks much, Connie Heitmeyer 10-MAY-78 22:10:01-PDT,4107;000000000001 Mail-from: USC-ISIB rcvd at 20-JUN-75 1442-PDT Date: 20 JUN 1975 1441-PDT From: STOTZ at USC-ISIB Subject: MSGGROUP# 033 ISI's IA project To: MessageGroup: I would like to introduce to all who are not already familiar with it, the IA project at ISI. We are implementing a military message service for a test in an operational military environment. This project is independent of the MSG and XED editor developments at ISI although there is some overlap of personalities. We are currently coding the message creation and coordination phase of the service. There is some background documentation I will send via U.S. Mail to anyone who asks me (please let me know your mail address with request). In many ways a military message service has the same requirements as one that serves computer researchers. The most distinguishing characteristic is that the message service that the military has now is extremely formal. Formal messages always pass between organization commanders (i.e. the message FROM field and the addressee fields contain the names of organization commanders even though the messages often are originated by and are eventually delivered to lower echelon people). Messages are archived for up to 7 years, and are considered to be statements of official position of the commander of the organization from which they originate. This introduces a need for "coordination" on outgoing messages and for "distribution determination" on incoming messages. Here coordination means getting consensus and approval of a message by a number of people in the organization. Distribution determination establishes who should get a copy of the message. Some fairly sophisticated algorithms have been developed for this this latter problem. It turns out that author designated keywords is one of the poorer ways of doing it. The military's requirements for security, privacy, accessibility and reliability are in general more critical than ours and military message systems deal in larger volumes of traffic. This last is aggrevated by the distribution algorithms which tend to send a copy to anyone who might be interested rather than risk missing the proper message recipient. At CINCPAC an average of 40 copies are made of each message received. Another major concern of the IA project is how to provide an interactive computer service of this sort to users who have no background or training in computer based systems and who want to use the service to get a job done. The background documents describe our basic approach to all this and I will not belabor your TI terminals with it here. But let me briefly address a few issues that have been raised and how we plan to handle them. 1. Terminals - The IA service is being built at this time for CRTs only. This way we can provide a full screen editor which we feel is more natural to use. 2. Coordination - The IA message service will provide "coordination" which allows collection of multi-users edits, comments and sign-offs on a message prior to its release. 2 3. Message storage - To minimize storage requirements, IA keeps a single central copy of a message and distributes citations to it, rather than creating a message copy for each addressee. To simplify verification of system integrity, we plan to restrict user access to formal, archived messages to read-only. Thus any personal comments, etc., to be added by recipients will have to be stored in each users personal directory along with a hook to the appropriate message. 4. Distribution determination - Messages received by our system will have already been processed for distribution determination. The IA service will extend this by allowing the user to create his own routing tables for automatic redistribution of his traffic. ------- 10-MAY-78 22:10:01-PDT,2721;000000000001 Mail-from: USC-ISI rcvd at 20-JUN-75 1541-PDT Date: 20 JUN 1975 1529-PDT From: DCROCKER at USC-ISI Subject: MSGGROUP# 034 Getting Specific: Recommendation and Attempt To: [ISI]MessageGroup.List: Judging from the comments of the last week, it may be useful for us now to begin a directed effort to develop specifications for an idealized (if not ideal) message processing system. Jean Iseli's approach has the advantage of being concise, so we may want to work from it, expanding and modifying it as appropriate. We could take votes in order to determine to relative importance of various features. Mostly for the sake of variety, I offer an initial list of my own. I believe it reflects many of the wishes expressed during the current dialogue. We will not doubt find that many of the features are expensive to build and others are cheap, but we will at least be able to give very specific preference lists to Myer/Vittal/et cie. The following list describes features. I would like us also to delve into the realm of "feel." Exactly how should the features appear to users? I will be sending some other notes concerning this. For reference, some of you may be interested in reading a draft of a paper that I wrote as a result of participating in Jim Carlisle's seminar on Teleconferencing. Many of the issues are the same. The formated file is in [ISI]Teleconferencing-E199-Paper.Txt and is accessible through FTP. User Interface "Profiles" for user-specific tailoring, between sessions Intuitive command words Multi-level commands, for collecting generic functions Command macros Single interface to all the tools Variety of command invocation styles Ability to "hide" capabilities, to provide simple view Message Creation Create message fields in any order Creation separated from transmission Editor available for each/every buffer Spelling corrector Text formater Table of contents builder (?) Message Reading Ability to refer to classes of messages, by name (Recent, Old, ...) Labelled filters, by date and/or string content Table of contents generated Multiple open message files Message Filing Automatic filing, according to filtering System knowledge of file names (=> naming conventions) Ability to delete messages Ability to archive messages, only saving local pointer Automatic catalog building Misc. Answer-back facility (by secretaries, as well as recipient) Forwarding facility The above is by no means complete and I welcome comments from the group. Dave. ------- 10-MAY-78 22:10:01-PDT,494;000000000001 Date: 21 JUN 1975 1022-PDT From: MEALY Subject: MSGGROUP# 035 MESSAGEGROUP.LIST To: FARBER I GUESS YOU MISSED MY MSG ASKING ALL TO SEND MAIL TO ME @ISI RATHER THAN @HARV-10, SINCE THE VOLUME CLOGS UP OUR DISK SPACE (ONLY ABOUT 2300 BLOCKS WHICH =400 ODD PAGES). SINCE THEN, A LOT OF THE MESSAGE GROUP HAVE CHANGED THEIR ONW COPIES OF THE LIST, BUT OTHERS ARE USING YOU UNUPDATED COPY. I AM CHECKING ISI FOR MAIL TO ME ABOUT EVERY OTHER DAY, ON THE AVERAGE.. CHEERS ------- 10-MAY-78 22:10:02-PDT,318;000000000001 Mail-from: HARV-10 rcvd at 21-JUN-75 1129-PDT Date: 21-Jun-75 14:32 From: MEALY at HARV-10 SUBJECT: MSGGROUP# 036 I CAN'T MAKE SNDMSG INCLUDE A FILE USING ^B WITHOUT IT REPROMPTING ME WITH To: AFTER I GIVE THE ^Z. ALSO, ^Q DOES NOTHING. WHAT GOES? (THE FILE IN QUESTION IS [ISI]MESS.TXT). ------- 10-MAY-78 22:10:02-PDT,3080;000000000001 Mail-from: USC-ISI rcvd at 21-JUN-75 1304-PDT Date: 21 JUN 1975 1258-PDT From: DCROCKER at USC-ISI Subject: MSGGROUP# 037 Reactions to Mailsys To: [ISI]MessageGroup.List: At the beginning of spring, last year, Nancy Neigus (BBN-IMP group) and I reviewed the design specifications for what has become Mailsys. At the time, we were chairing the USING group. At the end of last month, I shared some of my reactions to the existent system with the Jerry Burchfiel. You might be interested in the gist of my comments: I especially like the header-printing and filter controls and the ability to selectively and iteratively create and modify portions of the message, before sending it -- as opposed to the non-reversible sequence in Sndmsg. Unfortunately, I am less enthusiastic about some aspects of the user interface. I am making a distinction between the functions performed (which I like a lot) and the way the functions are invoked. The "Tenex Exec-like" capabilities of command completion and optional invocation of sub-commands (via comma) are great. However, there are at least four different commands that cause printing at the terminal (Read, Display, Printfilter, and Survey) and several other commands constitute variants of conceptually similar actions. Also, use of "%" and "*" (rather than "first,", "last," "current," and "all") is extremely non-intuitive. The end effect of these two characteristics is that Mailsys feels extremely complex and is not trivial to start using. I want to strongly lobby for multi-part commands, so that functions which appear similar to the user (I don't care how different their actual code is) can be invoked similarly. Consequently -- for example -- the printing commands would be much more pleasant to use if invoked with "Show Message ...", "Show Filter...", "Show Menu", etc. (I don't feel religious about using the keyword "show.") Any reasonably intuitive word is fine. However, my feeling is that "read" is not intuitive as a COMMAND. It is an accurate description of what I want to do, but not of what I want MAILSYS to do. I may be wrong about this particular psychological point, but I wanted to illustrate the kind of considerations which are critical to making Mailsys seem friendly. And therein lies an interesting point. Mailsys has lots of very friendly features, but their effect is seriously limited if the user perceives the system, as a whole, as being too complex. Having "?" generate in excess of 50 lines of commands is damn scary, especially since the commands are not listed alphabetically. (Side comment: I really like the partial-command "?" capability, as well as the single-character aliases for some commands, though I suggest that the aliases not be included in a "?" list.) ------- 10-MAY-78 22:10:02-PDT,3767;000000000001 Mail-from: USC-ISI rcvd at 21-JUN-75 1345-PDT Date: 21 JUN 1975 1335-PDT From: DCROCKER at USC-ISI Subject: MSGGROUP# 038 Thoughts on Command Specification To: [ISI]MessageGroup.List: While keyword -- as opposed to obscure character (e.g., "%") -- invocation of functions appeals to me, I have become very wary of being locked into having the first-character typed cause automatic command completion and invocation, as is embodied in MSG and XED. Too many contortions are needed to think of the command word. The problem becomes especially severe when the system has many commands. This, and the advantage of "chunking" conceptually similar commands together, is why I am lobbying for multi-part commands. Ron Tugender and I discussed the problem of command specification and settled on a variation of the SRI-ARC NLS scheme that would be essentially as follows: Our intent was to reduce the number of key strokes necessary for a) proficient users and/or b) frequent commands, while providing a more simple, predictable interface to the naive user. The system may be tailored for frequent-command preference, automatic completion, and automatic invocation. In the former, frequently-used commands are disambiguated by their first character. All other commands must be preceded by a blank. (For completeness, the preferred command may also be specified this way) The latter features automatically complete and/or invoke a command as soon as it is disambiguated. At any time, Question mark will provide a list of commands acceptable at that point (cf. Tenex Telnet, Mailsys). It and escape will also automatically print as much of the rest of the command word as is common to all the alternatives. (If I have typed a "D" and then question mark, the system would type an "e" for me and then show "Delete" and "Describe." I would then not have to type the "e.") In passive mode, escape and blank will perform the same actions as currently are performed by the Tenex Exec. With these three options, several tailored environments may be established, according to user proficiency and preference. A sophisticated user, on a speedy terminal, will have all three functions turned on. The Command interface will then look very similar to MSG, except that there will be some commands that require several strokes, with as the first, to specify. The advantage this offers over the current scheme in (e.g.) MSG is that ALL commands may then have intuitive labels. (As per my earlier comments about Mailsys.) A naive user will have all the features turned off. In addition, he is not told of the recognition/completion capabilities available with and . He therefore must type the full command word(s) and invoke them with carriage return. Very slow but very natural. When he starts complaining (or investigating the full documentation) he discovers and . Eventually, he may also want the single-character invocation mode. Other operating modes are apparent and useful, as in the case of slow terminals (auto-completion turned off). For these sorts of options to be reasonable to use, there must also be a permanent Profile facility, to record the desired defaults. Xed has such a facility. Others are planned. It would be useful to have a generalized profile facility so that the user's directory does not become cluttered with many different profile files. Additionally, these files tend to waste a great deal of space. Xed uses one word, out of an entire page. ------- 10-MAY-78 22:10:02-PDT,412;000000000001 Mail-from: USC-ISI rcvd at 21-JUN-75 1527-PDT Date: 21 JUN 1975 1516-PDT From: DCROCKER at USC-ISI Subject: MSGGROUP# 039 Nits: ISI and Mailer To: [ISI]MessageGroup.List: 1. Why does ISI default to RAIsing lower case to upper case? 2. Why does MAILER continue to deliver mail out of sequence, by working from the highest version number to the lowest, instead of vice-versa? ------- 10-MAY-78 22:10:02-PDT,481;000000000001 Mail-from: USC-ISI rcvd at 22-JUN-75 1444-PDT Date: 22 JUN 1975 1444-PDT From: WALKER at USC-ISI Subject: MSGGROUP# 040 LOWER CASE AT ISI To: [ISI]MessageGroup.List: Thanks for your comments, Dave. Last Friday I asked several people why ISIA had upper case as a default. No one has commented on why it is; I suspect that it just happened. If no one objects in the next day or so, I will request that the default be changed to upper/lower. Steve ------- 10-MAY-78 22:10:02-PDT,166;000000000001 Date: 22 JUN 1975 1447-PDT From: WALKER Subject: MSGGROUP# 041 $Add NGOODWIN @BBN to Message Lisy, Nancy Goodwin at Mitre To: Farber cc: Walker ------- 10-MAY-78 22:10:02-PDT,1322;000000000001 Mail-from: USC-ISI rcvd at 22-JUN-75 1638-PDT Date: 22 JUN 1975 1631-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 042 MAILER, MAILSTAT, ETC. To: [ISI]MessageGroup.List: Dave Crocker's question about MAILER sending mail out of order prompts me to ask why MAILER and MAILSTAT and SNDMSG (and XMAIL?) are not in agreement on how to handle HOST name recognition. It seems to me that SNDMSG recognizes HOSTs with a minimum type-in and without confusion between upper and lower cases. Mailstat will accept HOST names in either case, but will not recognize anything less than the full typeout of the HOST name. Then, after renaming a HOST or a DIRECTORY name for MAILER, after MAILER refuses to mail an improperly addressed msg for instance, MAILER refuses to recognize lowercase directory or HOST names. I may have some of the details wrong but the inconsistencies are a fact. Would some one please track down the true facts, and then take action to make them consistent. The SNDMSG reconition and handling rules seem to be prefered over the others, though some rethinking of the whole thing might be appropriate in the context of Tom Ellis' suggestion about Command Standards and Dave Crocker's distertation on Command Strucures and their reconition and invocation. ------- 10-MAY-78 22:10:02-PDT,736;000000000001 Mail-from: BBN-TENEXB rcvd at 23-JUN-75 0915-PDT Date: 23 JUN 1975 1212-EDT Sender: WATSON at BBN-TENEXB Subject: MSGGROUP# 043 warning about length of next message From: WATSON at BBN-TENEXB To: burchfiel at BBN, myer at BBN, gilbert at BBN, walker at ISI, farber at ISI, stefferud at ISI, ellis at ISI, kirstein at ISI, To: iseli at ISI, dcrocker at ISI, uhlig at OFFICE-1, vezza at MIT-DMS Cc: WATSON Message-ID: <[BBN-TENEXB]23-JUN-75 12:12:55-EDT.WATSON> The next message is a chapter from a final report in preparation that talks about the NLS user interface, command recognition etc that seems relevant to the current discussion of the mailservice user interfac3. Its quite long around 15+ psges so be warned. Dick 10-MAY-78 22:10:03-PDT,1152;000000000001 Mail-from: USC-ISIB rcvd at 23-JUN-75 1000-PDT Date: 23 JUN 1975 1001-PDT From: PATTI at USC-ISIB Subject: MSGGROUP# 044 Meeting Notes To: MESSAGE SERVICES COMMITTEE: cc: Oestreicher Message Committee: The 'Message Structure' sub-committee consisting of: 1. Jack Haverty (JFH@MIT-DMS) 2. Austin Henderson (HENDERSON@BBNA) 3. Don Oestreicher (OESTREICHER@ISIB) met at BBN on June 9th and 10th. The result of this meeting was a general decision on the next generation of message communication protocols and formats. The design makes use of the SRI-ARC PCPB8 format for structured information. The sub-committee plans to have a draft report available for the whole committee by the end of this month. The report will contain two main sections: A. Protocols for cooperating message processing services. B. Virtual message structure for information interchange between cooperating message processing services. Any questions or comments may be directed to the sub-committee members individually or the sub-committee jointly. dr0 for the 'message strusture' sub-committee Patti for D. Oestreicher ------- 10-MAY-78 22:10:03-PDT,422;000000000001 Mail-from: BBN-TENEXB rcvd at 23-JUN-75 1015-PDT Date: 23 JUN 1975 1316-EDT From: WATSON at BBN-TENEXB Subject: MSGGROUP# 045 2nd try on NLS User Interface Paper To: burchfiel at BBN, myer at BBN, gilbert at BBN, walker at ISI, To: farber at ISI, stefferud at ISI, ellis at ISI, To: kirstein at ISI, iseli at ISI, dcrocker at ISI, To: uhlig at OFFICE-1, vezza at MIT-DMS, watson at MIT-DMS ser ------- 10-MAY-78 22:10:03-PDT,48022;000000000001 Mail-from: BBN-TENEXB rcvd at 23-JUN-75 1028-PDT Date: 23 JUN 1975 1329-EDT From: WATSON at BBN-TENEXB Subject: MSGGROUP# 046 2nd try on NLS User Inte9face Paper (for real this time?) To: burchfiel at BBN, myer at BBN, gilbert at BBN, To: walker at ISI, farber at ISI, stefferud at ISI, To: ellis at ISI, kirstein at ISI, iseli at ISI, To: dcrocker at ISI, uhlig at OFFICE-1, vezza at MIT-DMS cc: watson Issues in the Design of the NLS User Interface.Center=3; .Pbs; By Richard W Watson INTRODUCTION The user interface has two sides: the input side by which the user inputs information, indicating by various conventions and controls what he wishes accomplished; and the output side by which the machine provides feedback and other assistance to the user in command specification, and provides various forms of information portrayal. Man has many motor and other capabilities that could be the basis for input and command specifications; similarly he has his full range of senses that could be targets for system output. To date, computer information systems make use of only a few motor and sensory capabilities in their man-machine dialog. An important area of research involves exploring the advantages to be gained and the techniques to be used to extend this range. There is interesting research going on in areas of speech, eye movement, brain wave control, hand written script, and video graphics that will undoubtedly be integrated into the truly multimedia systems to be built in the near future. We call the user's collection of input-output equipment and arrangement of work tables and work space, the workstation. At the present time, input centers around various types of keyboard devices: standard typewriter- type, function button, keyset (chord), and graphical pointing devices: mouse, electronic pen-tablet, light pen, joystick. The dominant output means are printers and displays of varying capabilities. The present NLS user interface has been developed around this equipment, although many of the principles used in its design can be easily extended for use with other media [3]. The prime motivation for the use of the mouse for pointing and two keyboards, (standard typewriter-like and keyset), as the input devices for the display version NLS 7 (DNLS), are described in references [2][3]. NLS can also be used from typewriter terminals (TNLS). In this chapter, we concentrate on describing some of the motivations behind the design of the NLS command language and the forms of information portrayed to assist the user in command specifications. Forms of general NLS information portrayal are described in reference [1]. The NLS is a prototype collection of tools in a growing workshop of tools and services to aid knowledge work [1][4], and we expect the number of tools and vocabulary that controls their use to grow. We further expect that the use of such a workshop will spread throughout those occupations involved with information in various forms and that there will be infrequent and casual users of such systems, along with many people who will spend large fractions of their day using such workshops. Another goal is to match the speed of system responsiveness to the natural speed and flow of ma's thought processes. It is from these basic expectations that our user interface work has developed. The sections below enumerate several assumptions and areas of concern around which the NLS user interface has developed to date. A key point to mention is that we do not consider the NLS user interface a static, finished product. It will change, based on analysis of usage experience, and the technology and media available. HIGH LEVEL ASSUMPTIONS UNDERLYING THE DESIGN OF THE NLS USER INTERFACE First we describe a few high- level assumptions that affect the user interface design and then discuss some of the lower level issues and thespecific techniques used to deal with them. 1) Coordinated Set Of User Interface Principles There will be a common command interaction discipline, over the many application areas in the workshop, that shapes user interface features, such as the language, control conventions, methods for obtaining help, and computer-aided training. This commonality has two main implications. One, it means that while each domain within the core workshop area or within a specialized application system may have a vocabulary unique to its area, this vocabulary will be used within language and control structures common throughout the workshop system. A user will learn to use additional functions by increasing vocabulary, not by having to learn separate "foreign" languages. Two, when in trouble, he will invoke help or tutorial functions in a standard way. 2) Grades Of User Proficiency A once-in-a-while user with a minimum of learning will want to be able to get at least a few straightforward things done. In fact, even an expert user in one domain will be a novice in others. Users will be clerical workers, information specialists, executives, engineers, and others. Attention to novice-oriented, and tutorial help features is required. Users also want and deserve the reward of increased proficiency and capability from improvements in their skills and knowledge, and in their conceptual orientation to the problem domain and to their workshop's system of tools, methods, conventions, etc. "Advanced vocabularies", short concise control notation and conventions in every special domain will be important and unavoidable. A corollary feature is that workers in the rapidly evolving augmented workshops should be involved continuously with testing and training in order that their skills and knowledge may most effectively harness available tools and methodology. 3) Ease Of Communication Between Subsets And Addition Of Workshop Domains One cannot predict which domains or application systems within the workshop will want to communicate in various sequences with which others, or what operations will be needed in the future. Thus, results must be easily communicated from one set of operations to another, and it should be easy to add or interface new domains to the workshop. A corollary is that the total workshop may contain a very large number of tools and services. Some users may have access to only a subset of its capabilities while others will have access to many or all capabilities. As described below, we expect the workshop to be embedded in a computer network and thus communication between tools and between users must take place across both process and host boundaries according to well specified conventions and protocols [5][6]. 4) User Programming Capability Or User Interface Extensibility There will never be enough professional programmers and system developers to build or interface all the tools that users may need for their work. Therefore, it must be possible, with various levels of ease, for users to add or interface new tools, and extend the language to meet their needs. They should be able to do this in either a variety of programming languages with which they may have training, or in the basic user-level language of the workshop itself. 5) Range Of Workstations And Symbol Representations The range of work stations available to the user will increase in scope and capability. These work stations will support text with large, open-ended character sets, pictures, voice, mathematical notation, tables, numbers, and other forms of knowledge. Even small portable hand-held consoles will be available. The multiplicity of possible terminals indeed raises the question of whether a consistent set of control and portrayal conventions is possible. As hardware decreases in cost, more and more capabilities will be placed in the work station both in the form of user interface aids and facilities, and in the form of frequently used tools. 6) Distributed Nature Of The User Interface Processes The collection of facilities to support interfaces with the system of tools can be conceived of as a single service as seen by the user. These facilities may all reside in a processor in the work station or be distributed in two or more processors, depending on the level of their sophistication and state of the art with respect to cost, hardware capability, and so forth. 7) Embedded In a Computer Network The computer-based tools of a knowledge workshop will be provided in the environment of a computer network, such as the ARPANET [7]. For instance, the core functions will consist of a network of cooperating processors performing special functions, such as editing, publishing, exchanging documents and messages, data management, and so forth. Less commonly used, but important functions, might exist on a single machine. The total computer-assisted workshop will be based on many geographically separate systems. Once there is a "digital-packet transportation system," it becomes possible for the individual user to reach out through his processor to other people and other services scattered throughout a "community". The "labor marketplace" where he transacts his knowledge work will be literally independent of geographical location. Specialty application systems will exist in the way that specialty shops and services now do--and for the same reasons. When it is easy to transport the material and negotiate the service transactions, one group of people will find that specialization can improve their cost/effectiveness, and that there is a large enough market within reach to support them. And, in the network-coupled computer-resource marketplace, there will be a growth of specialty shops, such as application systems specially tailored for particular types of analyses, or for checking through text for spelling errors, or for doing the text-graphic document typography in a special area of technical portrayal, and so on. There will be brokers, wholesalers, middle men, and retailers. The key point to emphasize is that even when hardware costs decrease to the point where a user can perform 90% of his work using tools and information that operate in the processor in his work station, he will want to have access to a computer network to: a) Communicate in various forms with others b) Access very large or special data bases c) Access special tools that run elsewhere 8) Problem Orientation Of The Command Language And Tolerance For Ambiguity The user has a task that he wishes performed by the system. Depending on the nature of the task and operations available to him on the system, he may be able to express what he wants accomplished in a single "statement" or command to the machine, or it may require a series of commands. One of the goals of the designers of the command language and system is to understand the nature of the user's application domain so that the user can express his needs with words that are similar to his natural problem solving vocabulary and language forms. The machine should then break down the request into smaller steps as required. If there is ambiguity in the user's command, the machine should recognize it, if possible, and prompt appropriately for clarification. There is still much research and development required to fully meet this goal. Many people hope to allow novice users or users in certain applications to use natural language in making statements to the machine. This capability will require models of the user and task domains for understanding. Even when systems are able to interpret commands given in natural language, the precision and usage efficiency of appropriate artificial languages will make the latter's continued use preferable, especially for skilled users. Given the above general considerations as background, we can move on to examine features of the NLS user interface in more detail. MORE DETAILED DISCUSSION OF THE NLS USER INTERFACE A command language must allow unambiguous specification of what the user wishes accomplished. The operation to be performed, and the entities or information items (arguments) to be acted upon, or used to determine what is to be acted upon, must be specified. These can be specified in a variety of ways: by typing them in in full or in some form of abbreviation, by pointing at them on a screen, by pronominal reference, or by use of default values where appropriate. The order of their specification, the syntax or grammar of the language, can have various forms. For example, operational keywords can be specified, followed by the arguments, or vice versa. Arguments can be in fixed positions or explicitly named and occur in any order. Some arguments or keywords can be optional and require special characters to indicate their presence. Arguments or keywords can have defaulted values under certain conditions. Pronominal references can be allowed to refer to previous occurences. Arguments may be given types by the system and language designer for more extensive error checking and feedback. Arguments and keywords can be specified by complete or partial typein (there are a variety of forms of command recognition that are discussed later) or designated by pointing to representations on a display or by use of specially coded function keys. Or, the machine may ask questions and the user just fill in the blanks. Depending on the characteristics of the computer and communications system, it may or may not be possible to provide command word or keyword completion, prompts or other feedback, argument checking, default value fill in, and so forth, during the command specifications. For example, in line-at-a-time, half-duplex systems, the user usually must complete the entire specification of the command before transmission to the system, while in character-at-a-time, full-duplex systems, the system can react to each character received and provide more extensive aids to the user during command specification. The above discussion outlines just a few of the many choices available to the language designer. As the purpose of this section is not to be a complete tutorial on all possible choices available and their advantages and disadvantages, the following discussion only gives main NLS command language features and the motivation for their adoption. THE NLS COMMAND LANGUAGE The NLS command language generally has the following form, where angle brackets group meta symbols: The fields in a command are of a fixed order, although some commands have optional fields that can be specifically requested. Other fields can have a system-supplied default value. Because NLS operates from a character-at-a-time, full-duplex system, several levels of help are available, as described later, for giving cues and prompts, explicitly listing options or syntax, and giving full documentation on what the system expects next during command specification. It was not felt that much would be gained for novice users by allowing fields to be specified in any order by using explicit field names. Novice users do not need to be aware of optional fields. As much as possible NLS makes the operational specification of the form verb-noun followed by arguments and possibly other keywords. We have also tried to maximize the fullness of the verb-noun matrix. This approach seemed to be natural, and follows normal English imperative forms to aid learning. The choice of verb-noun form seemed to fall out naturally when considering such important areas as editing. A given verb, such as DELETE, can naturally be applied to many entities, such as statement (a paragraph, title, equation), character, number, text, file etc. Learning is easier if the user can form a model of how the system works that can be consistently applied. In this case, a user can learn n verbs and m nouns and understand that generally, if it is meaningful, they can be used in pairs. Having learned n+m vocabulary terms, he can apply them in the form of n x m commands. We have tried to pick command keywords that have normal usage related to the operation described. A synonym capability would be easy to implement. Four forms of command keyword recognition are provided to enable the user to choose the one most appropriate to his terminal type, system response, previous system experience, and present NLS experience level. We have worked to pick an operational vocabulary for the present system that guarantees keywords to be unique in a maximum of three characters: 1) A single-character mode allowing high-speed single-character recognition of the most commonly used commands; less commonly used commands require an escape character followed by enough characters for unique recognition: With large and expanding command sets one cannot choose keywords with mnemonic value and guarantee uniqueness with the first character. This mode is generally preferred by experienced users because of the simplicity and speed with which frequently used operations can be expressed. We find that experienced users are very concerned that commands be formed with the minimum number of input operations, and that commands have the richness needed to specify adjective or adverb type operations as needed. There is thus some conflict in certain commands between these goals for the experienced user and the need for command simplicity for the novice. 2) A demand mode requiring a right delimiter to initiate recognition: This has proved to be popular for new users of typewriter terminals, particularly those with experience using the TENEX operating system. Modes C and D have not turned out to be heavily used. 3) An anticipatory mode requiring the user to type enough characters until the command is uniquely specified; the system then automatically fills in the remainder. 4) A fixed mode that guarantees recognition on entry of three characters. Given the implementation approach outlined later, it is quite easy to add other recognition modes, such as allowing the user to choose keywords from a menu displayed on the screen. However, experiments have shown that the time it takes to point at some item on the screen is equivalent to several keystrokes and thus would be disadvantageous to skilled users, although possibly of value to novices [2][3]. Operand argument specification is contained in a number of fields that are variable with the type of command. All commands of a similar type have had the order of the operands made as consistent and as natural (relative to normal English usage) as possible. Infrequently used operand fields are optional and novice users need not be aware of their existence. Related to argument specification is the problem of choosing argument delimiters. One can recognize the following delimiting functions. 1) Delimiting command words 2) Delimiting arguments 3) Delimiting optional arguments, selection type, or command word fields 4) Delimiting commands 5) Selecting arguments off a display screen, and confirming the selections One could choose separate characters (codes) to represent each of these functions. To do so seemed to us to add an unnecessary complication for the user and so, except for using a special character to indicate an optional argument, selection type, or command word, a single code is used for the other function in NLS. We call this code "Command Accept" (CA) even though it is used for other purposes as well. The system allows the user to define which keyboard character is to serve this function if he finds the system default to be inconvenient. One of the buttons on the mouse also serves this function. Arguments can be typed in, defaulted where appropriate, or specified by pointing to appropriate entities on the display screen. There are three flavors of command completion. 1) Completion of the command indicating execute the command and return to the base state to await input of the next command: The default indication for this form is one of the buttons on the mouse in DNLS, which is translated into a control character, or CR in TNLS. The use of CR in TNLS is quite natural and generally does not conflict with textual input as most text in NLS is typed in without explicit CRs and is appropriately formatted by the system for various output devices. If the TNLS user wishes to input an explicit CR in his text file, he must precede it with an escape character. If he has need to enter many CRs in his text string, he can redefine the completion character, Command Accept, to be some other character. 2) Completion of the command and return to an appropriate point for quick repetition of the command. Repetition mode continues until explicitly commanded to delete out of it. This mode is very useful when a delete or other operation is repeated several times. 3) Completion of the command and entry to insert-statement mode for addition of new paragraphs or other text statements: This mode is like command repeat above except that it always takes you to the insert command. It is used frequently when one adds, replaces, or moves text, and then wants to follow it with new statements. It speeds text input when inserting sequences of paragraphs. The system is to be used from a variety of terminal types, including both typewriter-type terminals and displays. The two-dimensional displays are to be the preferred work station types whenever a design decision must be made between language forms possibly favoring one type or the other. It was decided to make the command language syntax for the typewriter (TNLS) version and the display (DNLS) version as close as possible, except where the difference between the one-dimensional and two-dimensional media clearly prohibits this or would seriously limit one or the other version. This decision was made to allow people working in environments consisting of both typewriter and display terminals to be able to move back and forth with ease. The system has been organized into clearly defined subsystems with uniform rules for their entry and exit. Any subsystem can be entered from any other, either to "execute" a single command with automatic return or to perform a chain of commands. The user can return, either to a specifically named subsystem in the path of subsystems traversed or enter a new subsystem. The issue of how to group commands into subsystems has to do with training and patterns of use rather than system constraints. It relates to learnability and, to some extent ease of command specification using single characters, and to "knowing where you are" in a command or operational space. One could construct a system where all commands were in a single subsystem. Study of the command set of a large system particularly conceived of as a set of tools shows that operations tend to group together such that to perform a given task, such as sending a message or calculating a budget, generally require several related suboperations. Certain operations, such as moving in information space or seeking help, tend to be used as suboperations of many or all tasks. This latter observation has led to "universal" commands available from within any subsystems. One can also imagine certain commands to be needed frequently in just two or more subsystems and thus implemented in each subsystem having the need. There are now no instances of this case in NLS. The ability to execute a single command in another subsystem with automatic return has been very useful. Provision has been made for user-controllable options on prompting, feedbac, and other parameters whenever it seemed a single option, might not be appropriate to some significant class of users. A mechanism is implemented that enables the user, or someone acting in his behalf, to create a file stating what options he wants to run. The system automatically sets his options when he enters. This facility can also be used with small extensions to subset commands. This user option capability, when coupled with the ease by which the user interface can be redefined using the Control Meta Language described below, makes possible tailoring the user interface to specific users or groups of users. All operations that have a natural inverse command have been given one. (NLS still does not have an "undo" facility.) A general undo/redo facility has a number of technical difficulties and its value can be questioned. However, the ability to undo or redo the last one, two, or three commands would clearly be useful. User Programming: As indicated earlier the ability of the user to extend the system himself is important. There is a tradeoff between ease of extension specification and operational efficiency. In providing such a facility one does not have to be deeply concerned with efficiency if the task handled by the extension is performed infrequently. If the operation is performed frequently, then it should probably be inserted as a system feature and implemented efficiently by professionals. This area is ripe for much additional development. The extensions must be specified in some language to indicate what sequence of events is to take place, what arguments to collect, and so forth, when a given user action is performed. NLS now offers two forms of extensibility. The first allows users with some basic programming knowledge to write programs in the Algol like L10 language in which the system is implemented, calling on NLS system primitives as needed. They can use the Control Meta Language to specify a user interface if desired. These programs can be installed by the user as part of his default subsystems, loaded as subsystems as needed, or used as content analyzer patterns [8]. The user can also write sequences of NLS commands and have these sequences executed at will. A specific sequence of commands can be automatically invoked when the user first enters NLS. HELP, STATUS, AND PORTRAYAL FACILITIES ORGANIZATION of the TERMINAL DISPLAY AREA The NLS display screen is organized into windows as described in some detail in [9] These windows are arbitrary rectangles. Windows can be displayed essentially all the time or overlayed with others. Windows can grow dynamically. Some windows are allocated and displayed or not displayed under system control for status and feedback information. Others can be created and manipulated by the user for display in his information space. With typewriter terminals, one does not have this two-dimensional random display capability and while the same information can be given to him, less can be given automatically or must be given in an altered form. Let us now consider each of the information spaces and the type of feedback, help, and other status information available to the user. 1) Information space The present NLS information space is hierarchically organized. A user has a directory or directories within which there are files. A file can contain notes on many subjects stored under various headings, his mail, or single documents. Files in turn are hierarchically organized as a tree of information nodes (now text strings but soon to be generalized to include illustrations and other entities). Files can contain cross citations to specific points within other files or the same files, thus creating networks. NLS has appropriate commands for moving within and between files and for obtaining a display of the path over which one has traveled and commands for backtracking along this path [3]. Display screens have a limited number of lines within which to display information, and typewriters, even at 30 chars/sec or higher, cannot quickly and easily print out large documents. Also, the user often wants to see a summary or overview of a document or have it formatted in special ways to aid his understanding. To meet this need for easy control of information portrayal, NLS has a concept called "view specification". The user can change his "view" within the commands for moving in information space or by separate command. So that he can be reminded of his current view, the most commonly used view parameters are fed back to him in a small window in the upper right hand corner of the screen. When he is at a point in a command where it is permissible to change views, this fact is fedback both by prompt (if prompts are turned on) and by enlarging the characters in the view-feedback window. For more discussion on moving, viewing, and portrayal in NLS see [3][6]. 2) Subsystem or tool space NLS is viewed as a collection of tools (subsystems) that can be used cooperatively or stand alone. Each subsystem contains a number of logically related commands and has a name, such as Base (the collection of editing and file manipulating commands), Calculator, etc. All the tools work on information in the same file structure and the user can move from one tool to another, or execute commands on a single command basis in any tool from any other tool, as mentioned earlier. The user can receive a display of subsystems available to him or an ordered list of the subsystems in which he has previously been. The current subsystem within which he is operating is fed back in a small window in the upper left-hand corner of the screen in DNLS and as a four-character prompt in TNLS. 3) Command syntax space There are several levels of feedback and Help available to the user in formulating a command to the system (14,). Each is described below. The Help data base clearly is also generally useful for understanding the system as a whole. a) Command keyword recognition: The options here were described earlier and this mode is primarily useful in minimizing keystrokes and in triggering additional feedback. b) Noise words: When the system recognizes a keyword or field it generates what we call "noise words" set off in parentheses so the user can distinguish between what he has input and what the system has added. The noise words aid the user in remembering what to do next. Novice users report that noise words are one of the most useful initial aids. As more experience is gained, the other aids take on more importance. This is an important point to note: users at different levels of experience value different forms of feedback. Usefulness is not only determined by the inherent characteristics of the aids, but also, by how they are implemented. c) Prompts: When the user completes the specification of a field in a command, he is prompted with some terse characters indicating the type of thing expected next and the alternatives available to him for how he can specify, select, or address the needed argument. Users can turn prompts off, which some users of TNLS do when they reach a certain level of proficiency, although many highly skilled users always operate with them on. DNLS users tend to always operate with them on because the high speed of the display does not slow down work while providing useful information. Users can also specify terse prompting in which case optional fields are not prompted for. Beginning users have indicated that prompting is useful, but would like them to be more mnemonic and of word length. d) Next Options and Syntax: If the noise words and prompts are not sufficient to jog a user's memory about what options are available to him next, he can strike a ? or a . If he strikes a ?, the system displays, in alphabetical order, all the command keywords that are legitimate for the next field or more extensive information than is available in the prompts for other fields. If he strikes , the system prints out the syntax of the command from his present position to the end of the command. The ? facility is extensively used and is very useful in refreshing one's memory about infrequently used commands or new commands for a user with only a basic knowledge of command system concepts and vocabulary. The feature does not seem to be extensively used at present and may indicate that the ? facility is sufficient. e) Help Data Base: If the above facilities are not sufficient because of uncertainty about a basic concept or vocabulary word or the user wishes more information about the effects or use of a command, he can enter the the Help tool. Entry can be from the basic command level or from any point during command specification. In the latter case, the system utilizes the information input at this point to take the user to an initial point that describes the command and field where he is at. (15) Once in the Help Data Base, a simple set of command conventions and the organization of the data base allow the user to easily move to reference related subjects or move to new subjects or back up to higher level descriptions (15). f) Active Tutorial Help: The next level of Help facility would be an active tutorial facility. We have not yet implemented such a facility but can see its value. An example of such a facility is the work going on at BBN on the NLS-Scholar system [10]. ERROR MESSAGES AND RECOVERY Error messages indicating an incorrectly spelled file name or improperly specified entity are fed back to the user in a window at the top of the screen. The user is left at an appropriate point within the command specification or where necessary he must start over again to respecify the command. The text of error messages is important and should be as specific to the problem as possible. This has implications within the system design for trapping error conditions as early as possible and determining the appropriate message for the specific error and total context of the user. While we have made progress in this area, there is much more that could be done to meet the need stated above. There are now no automatic error correction mechanisms built into the system, such as spelling correction or "Do What I Mean" type facilities. These would probably be useful to add when resources permit. EDITING AND BACKUP DURING COMMAND SPECIFICATION The user can perform certain simple editing and backup operations during command specification. At any point during command specification he can command delete, which will take him back to the basic command level. This is useful if he gets confused and wants to return to a known state or changes his mind about which command to perform next. The user can delete the last character input or last selection made on the screen with another character or button push on the mouse. He can repeat this process and continue the incremental backup process to the basic command state. The user can delete the last word input, or the field specified to date, or the field specified with another character or button push on the mouse. He can also repeat this process backwards to the basic command state as well. IMPLEMENTATION The mechanisms and data bases needed to implement the user interface have been modularized and isolated. This "Frontend" can run on a separate computer, such as a mini-computer close to the user, and communicate with the basic tool information processing routines ("Backend") over a communication network. The Frontend consists of terminal handling capabilities [9], a command language interpreter (2a1), and two data bases, a Grammar representing the language syntax and noise words; and a User Profile indicating how the user wants various parameters set for him, such as his prompt and command recognition modes, keyboard key translations, etc. The Grammar is generated from a high-level description of the user interface written in a language special for this purpose we call Control Meta Language (2a1,). Given this particular system organization it is very easy to tailor, subset, or modify the user interface for individuals or groups, or to create interfaces for new tools. Further all the levels of help information, except the Help Data Base, are derived from the Grammar, which guarantees correctness of these levels of documentation as the system changes and is debugged. Various forms of hard copy documentation, such as command summaries, are also derived from the Grammar representation. The user interface must implement a man/machine dialog. In this section, we discuss issues from machine to man. The discussion centers around the use of displays, with comments on how the problem is dealt with for typewriters. Let us examine some of the types of information that the user needs in order to keep his bearings. There are four main areas or dimensions along which the user needs information to help him a) to know where he has been, b) to know where he is, and c) to know where he can go from here. Clearly the command language and user interface must offer provisions to move in these spaces as well as obtain status. 1) Information Space The user needs to know where he is in his information space, and what view or portrayal of the many possible is being displayed to him. Generally he arrived at his present position from previous points and he may want to be able to backtrack to previous points or views as well as to move on. 2) Subsystem or Tool Space In workshops containing many tools and commands, the user needs to know which tool is active and possibly needs to know which ones he was in previously and their order, and which ones he can enter from here. 3) Command Syntax Space During the specifications of a command, the user may need to know what he can or is expected to do next and how to back up to a previous point. 4) Information Input Space During input of information, drawings, tex, etc., the user needs to have ways to see and possibly modify, in simple ways, information that he is entering. .PBS; ARC Journal References .IOvr=11; .PlexNum=21; (8A4) (8A5) (8E1B) (8E1C) Douglas C. Engelbart. A Research Center for Augmenting Human Intellect. Augmentation Research Center, Stanford Research Institute, Menlo Park, California 94025. 68. (3954,) (8A4) (8D3E) William E. English. Display-Selection Technique for Text Manipulation. Augmentation Research Center, Stanford Research Institute, Menlo Park, California 94025. MAR-67. (9694,) (8A4) (8D3E) Douglas C. Engelbart. Design Considerations for Knowledge Workshop Terminals. Augmentation Research Center, Stanford Research Institute, Menlo Park, California 94025. 14-MAR-73. (14851,) (8A5) (8E1C) Douglas C. Engelbart, Richard W. Watson, James C. Norton. The Augmented Knowledge Workshop. Augmentation Research Center, Stanford Research Institute, Menlo Park, California 94025. 1-MAR-73. (14724,) (8B1C2) James E. (Jim) White. Version 2 of the Procedure Call Protocol (PCP). Augmentation Research Center, Stanford Research Institute, Menlo Park, California 94025. PCP-COVER.NLS;5,. (24590,) (8B1C2) Jonathan B. Postel and James E. (Jim) White. Notes on a Distributed Programming System. Augmentation Research Center, Stanford Research Institute, Menlo Park, California 94025. 21-MAR-75. (25613,) (8B1G1) Lawrence G. Roberts and Barry D. Wessler. (University of Utah, Computer Science Department). The ARPA Network. Advanced Research Projects Agency, Information Processing Techniques, Washington, D.C. MAY-71. (7750,) (8D10B) No Author. L10 Users' Guide: Content Analyzer. Augmentation Research Center, Stanford Research Institute, Menlo Park, California 94025. L10.NLS;7,. (24426,) (8E1) (8E1H1) Charles H. Irby. Display Techniques for Interactive Text Manipulation. Augmentation Research Center, Stanford Research Institute, Menlo Park, California 94025. 15-NOV-73. (20183,) (8E1E7) M. C. Gringnetti et. al. An Intelligent Online Assistant and Tutor--NLS Scholar. AFIPS Conference Proceedings, Vol. 44. Anaheim, California. MAY-75. (25054,) .Text[R]="Command Meta Language"; .Iovr=0; .Igs; ------- 10-MAY-78 22:10:04-PDT,259;000000000001 Date: 23 JUN 1975 1051-PDT From: FARBER Subject: MSGGROUP# 047 Re: MESSAGEGROUP.LIST To: MEALY cc: FARBER In response to your message sent 21 JUN 1975 1022-PDT I put your name on the list. Dave is away until Mid July. John Pickens ------- 10-MAY-78 22:10:04-PDT,302;000000000001 Date: 23 JUN 1975 1052-PDT From: FARBER Subject: MSGGROUP# 048 Re: $Add NGOODWIN @BBN to Message Lisy, Nancy Goodwin at Mitre To: WALKER cc: FARBER In response to your message sent 22 JUN 1975 1447-PDT I made the addition for Dave. He is away until mid July. John Pickens ------- 10-MAY-78 22:10:04-PDT,2283;000000000001 Mail-from: USC-ISI rcvd at 23-JUN-75 1433-PDT Date: 23 JUN 1975 1420-PDT From: TASKER at USC-ISI Subject: MSGGROUP# 049 MAILSYS; creation prompting To: [ISI]MessageGroup.List: Ted Myer suggested that I share the text of my 19 Jun 1975 1759-PDT reply to his 18 Jun 1975 22:42:33-EDT message with the group: Ted: I read with great interest your note to the msggroup about MAILSYS and NMSG and found myself agreeing with you: NMSG DOES do a better job at the message management, and MAILSYS DOES do a better job at creation. My only serious concern with MAILSYS message creation is apparently being addressed already by you guys: prompting. The military user currently is used to a prompting message creation system (the message creation form DD173) and would probably feel more comfortable (at least initially) with some prompting. (I find that I myself spend more time creating the header in MAILSYS due, in part, to the lack of prompting). The military user will probably want to tailor prompting for his informal traffic use and call on a common DD173 one for the record messages. I would suggest that the formal message prompting might actually prompt for the required fields and then list the other fields as guidance, as opposed to requiring the operator to discard every field he doesn't want to use. This is my own guess -- if the prompting is flexible, we can let the real user find out what he wants. (I'm sure you guys have thought about this more seriously and in more depth than I have, so please excuse me if this is presump- tuous). In any case, I really like the manipulation flexibility you now provide, and I am very much interested in what your thinking has been in this area and what the creation prompting capabilities look like when they're ready. Sitting here in the offices of a potential military user (CINCPAC J6), I am extremely gratified and excited to see the msg group interacting and that those interactions appear to be converging around real capabilities that I think can be sold to the operational military guy. A scant three or four months ago I never would have even hoped for the current state of affairs and the direction it indicates. Aloha, Pete ------- ------- 10-MAY-78 22:10:04-PDT,2783;000000000001 Mail-from: BBN-TENEXB rcvd at 23-JUN-75 1448-PDT Date: 23 JUN 1975 1701-EDT Sender: WATSON at BBN-TENEXB Subject: MSGGROUP# 050 Some [ore NLS Experience that might be useful From: WATSON at BBN-TENEXB To: burchfiel at BBN, myer at BBN, gilbert at BBN, walker at ISI, farber at ISI, stefferud at ISI, ellis at ISI, kirstein at ISI, To: iseli at ISI, dcrocker at ISI, uhlig at OFFICE-1, vezza at MIT-DMS Cc: WATSON Message-ID: <[BBN-TENEXB]23-JUN-75 17:01:18-EDT.WATSON> The paper I flooded you with this morning discussed the motivation behind the NLS multipart command structure, command recognition modes, help features etc. From the dialog to date there is also some other experience in the NLS world that would seem relevant. First is the concept in the NLS Journal of Recorded dialog. That is dialog that gets a permanent number, is placed in read only storage, has access protection, is cataloggYd for later retrieval etc so that it is known by all that it will be around when you want to reference it. Thus when the dialog proceeds you do not have to send out copies of back or side messages, but instead can place citations (NLS links) in the text o fthe message referencing other relevant material and know the reader can get to it. With the institution of numbering messages and the archival demon we have made a start on a netwide basis toward such a capability but we need to go further. Second the issue of problems people have with slow terminals dealing with the stuff generated on the faster terminalas can be partially handled if messages were structured and concepts like NLS viewspecifications were more generally available. Rather than use the various mail reading programs I find it easier because of the viewspecs, split screen capabilities to handle my reading filing using normal NLS commands. The key here is that once the stuff is in NLS it is structured and I can bring the full power of a command set designed to deal with structure to bear on the material. The addition of graphics voice and other media in the future will also demand structure. And while I have not yet seen what the structure sub committtee has proposed I strongly endorse us moving to a structured world as soon as possible. This will also facilitate addition of margin notes etc. It is becoming clear to me as I read the dialog that there really is no such thing as a simple message service as people gain experience, there is only a complete office with a range of tools for creation reading filing etc needed and therefore we need I believe to desig7 a system that will allow a market place of tools to work together which gets us into some of the experience and goals of the NSW, but thats a whole world beyond today. Really enjoying the dialog. Dick 10-MAY-78 22:10:05-PDT,941;000000000001 Mail-from: BBN-TENEXB rcvd at 23-JUN-75 1448-PDT Date: 23 JUN 1975 1642-EDT Sender: WATSON at BBN-TENEXB Subject: MSGGROUP# 051 Help how do you know where you got left From: WATSON at BBN-TENEXB To: burchfiel at BBN, myer at BBN, gilbert at BBN, walker at ISI, farber at ISI, stefferud at ISI, ellis at ISI, kirstein at ISI, To: iseli at ISI, dcrocker at ISI, uhlig at OFFICE-1, vezza at MIT-DMS Cc: WATSON Message-ID: <[BBN-TENEXB]23-JUN-75 16:42:57-EDT.WATSON> Jerry, this morning when I was trying to send that paper on the NLS user interface, in the middle of the send part I ran out of file space and the system aborted. I could not find out how far it had gotten from any of the status type command s so I could see you to send it to on the next try. Is there a way I could have found out? If not htere probably should be of determining status other than doing a dir and seeing what unsent mail files exist. Thanks Dick 10-MAY-78 22:10:05-PDT,1981;000000000001 Mail-from: USC-ISI rcvd at 23-JUN-75 1557-PDT Date: 23 JUN 1975 1542-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 052 [ISI]MessageGroup.List: To: WATSON at BBN-TENEXB cc: [ISI]MessageGroup.List: Hi Dick: At first I was a bit bothered by the printout of the SEND list in your messages, and then I noticed that they were shorter than they were supposed to be. When Dave Farber accepted the "keeper of the lists" job, he volunteered me to help with the chore. Dave is away on vacation. I note that you must be using an old list. The current list is enclosed for your use, and the use of everyone on the list. The master list is stored in: [ISI]MessageGroup.LIST and in [ISI]MSGRP.MAILING-LIST and both are read accessible for your convenience. MSGRP is a slightly abreviated list excluding those who have asked Dave to help them avoid too much junk mail. I will include both in this message. [ISI]MessageGroup.List: @BBN,NGoodwin,Burchfiel,Myer,Gilbert, @ISI,Mealy,Tasker,Mclindon,Walker,Farber,Stefferud,Ellis, Kirstein,Iseli,DCrocker,PBaran, @ISIb,Vittal,Stotz, @Office-1,Uhlig,Watson, @Mit-DMS,Vezza, @I4-TENEX,PIRTLE, [ISI]MessageGroup.List: @BBN,Burchfiel,Myer,Gilbert,NGoodwin, @ISI,Mealy,Tasker,Mclindon,Walker,Farber,Stefferud,Ellis, Kirstein,Iseli,DCrocker,PBaran, @ISIb,Vittal,Stotz, @Office-1,Uhlig,Watson, @Mit-DMS,Vezza Dick, I am glad to see you in this dialogue and I am looking forward to reading the paper as soon as I can get it out on a printer. I hope all of us at ISI are not keeping a copy. My Directory for one in impossible to keep from going over allocation with the flood of text I am receiving. Best regards to you all. Stef PS: I have no explanation for the duplicate heading on the different lists. I am just sending you what I found in the files, with a bit of compression in the number of lines consummed. S ------- 10-MAY-78 22:10:05-PDT,4443;000000000001 Date: 24 JUN 1975 1110-PDT Sender: AMC at USC-ISI Subject: MSGGROUP# 053 Army Materiel Command Interests in Message Systems From: AMC at USC-ISI To: [ISI]MessageGroup.List: Cc: Gilbert at OFFICE-1, Arntson at OFFICE-1, Cianflone at OFFICE-1, Mitchell at OFFICE-1, Dsmith at OFFICE-1, Gunn at OFFICE-1, Uhlig at OFFICE-1 Message-ID: <[USC-ISI]24-JUN-75 11:10:24-PDT.AMC> I have been sitting back for some time watching the messages flow through my mail box on the various message systems. The recent message from Tom Ellis on Command Mnemonics and from Rob Stotz on the ISI IA Project have acted as a catalyst to finally get me to say something (in addition to the fact that I am about to disappear for two weeks beginning this Saturday). For those of you unfamiliar with our "experiment" in Army Materiel Command, we have been using OFFICE 1 for communication among seven of the key managers in data processing in Army Materiel Command (AMC). The "experiment" portion of our use is about to end and we hope to write up the results this summer. In general, we have had the same kind of experience in improved communication that ARPA had when they began using a message system on the network. Continuing major cuts in the Army Materiel Command work force plus some fairly major reorganizations which are now being planned are leading us to give serious consideration to adopting an on-line computer based message system for key managers throughout the command. We are in the early stages of trying to define what such a system needs to look like. There is some similarity to the IA Project however that project deals more with formal message handling, in so far as I can tell, rather than the more innormal message traffic that we hope to use it for within AMC. Possibly, when we get done, the IA Project and what we want to do in AMC will merge together into a good total message handling system. Since we are aiming more at the informal communications we are not terribly concerned with the DOD traditions that Tom Ellis mentions in his message on Command Mnemonics. Our primary concern is that the message system be easily usable by noncomputer science people, some of whom are actively hostile to computers in general. The demonstrations that we have given to various noncomputer science, non technical personnel around AMC have generally been well received. But one must know far too much "computerese" to use any of the existing systems. It is clear that we need a simple text editor which can be invoked to change the message body however, we would perfer that one not have to go through a separate action to send a message after that. Furthermore, the fixed order in which the other portions of the message appear and are prompted are desirable for our purposes. Disposing of messages needs also to be very simple. The current ability to move messages with the move command in msg appear to fill the bill for what we need. However we do need the ability to add notes to a message at the point in the text where we want to make a note We have a strong need for teleconferencing because our key managers are greatly dispersed geographically. The message system that we eventually adopt needs a teleconference capability. We don't want message handling and teleconferencing to be in two separate systems. Because of this we also want to make it easy in the middle of a message based teleconference to link to a data bank somewhere in AMC to pick up information which is needed at that point in time. An FTP type capability, simple to use for the novice, would meet the need very nicely. For technical reasons we may have to go to the one copy per group feature, such as Rob Stotz cites in the IA project. However, it would be better if this were transparent to the end user. This is based on problems we have had in getting some of the people involved in our current experiment to understand that this is the way the journal works at OFFICE 1. As we get better definition on our requirements during the next few months I will put additional messages into the network to keep you all current on our thinking. This message is only intended to be introductory. Ron Uhlig 10-MAY-78 22:10:05-PDT,1770;000000000001 Mail-from: USC-ISI rcvd at 24-JUN-75 1200-PDT Date: 24 JUN 1975 1152-PDT From: DCROCKER at USC-ISI Subject: MSGGROUP# 054 Helping Secretaries Answer Boss' Mail To: [ISI]MessageGroup.List: cc: [ISI]FOLK.ATSGROUP: Since it is very common for secretaries to answers mail for their bosses, I have been trying to think of a clean way for our current mail systems to be used to that effect. At ISI, I am told, secretaries simply log into their bosses' directory and "ghost" responses; that seems to me to be the wrong idea. The following seems to be workable and I would like to solicit comments on it: Using MSG (for the moment) Boss PUTs appropriate messages into a pre-designated file, such as ANSWER.MSG. When convenient, the secretary CONNECTS to Boss' directory and starts MSG with automatic read-in of ANSWER.MSG. MSG automatically flags Recent messages (added to the file since it was last read) so the secretary will easily be able to tell what new mail needs responding to. The secretary then tells MSG to Answer each piece of mail, allowing him/her to also send a copy (through the * facility in SNDMSG; Mailsys should offer an improvement to this, since the * thing only works on existing files) to RESPONSES.MSG (or whatever) which will also be in Boss' directory. Boss will then be able to easily tell what messages have been answered, and will have a copy of the response. The above obviously is not as smooth as one would want, but suggests what tailored functions might be useful, such as a command which does PUTs only to a file like ANSWER.MSG, so Boss does not have to remember the name. Comments? Dave. ------- 10-MAY-78 22:10:05-PDT,210;000000000001 Date: 24 JUN 1975 1244-PDT From: MEALY Subject: MSGGROUP# 055 Re: MESSAGEGROUP.LIST To: FARBER In response to your message sent 23 JUN 1975 1051-PDT Thanks for updating the mailing list. ------- 10-MAY-78 22:10:05-PDT,4798;000000000001 Mail-from: USC-ISI rcvd at 25-JUN-75 0725-PDT Date: 25 JUN 1975 0725-PDT From: WALKER at USC-ISI Subject: MSGGROUP# 056 Message from Mitre To: [ISI]MessageGroup.List: Mail-from: BBN-TENEX rcvd at 25-JUN-75 0702-PDT Date: 25 JUN 1975 1001-EDT Sender: NGOODWIN at BBN-TENEX From: Nancy Goodwin To: Walker at ISI Cc: tasker at ISI Message-ID: <[BBN-TENEX]25-JUN-75 10:01:17-EDT.NGOODWIN> Steve, Thanks for adding my name to the message group list. I have been interested in the exhange of ideas about the user interface, and especially like the idea of establishing a single list of command names for message handling systems. The transfers among Mailsys, MSG, and HG have been frustrating, as I try to remember which command is used for which action. Jon and I thought the message group would be interested in our recommendation that a display-oriented message handling system should be developed for use by the computer-naive. (Experts might like it too.) This will be discussed in the paper we are preparing for you, but the lag between final draft, publication, and distribution, and the speed of the current exchange of ideas among the group, lead us to think it would be useful to introduce this recommendation to the group now. I would have sent it to the message group directly, but have not yet managed to get the group name accepted as an address by Mailsys, or managed to penetrate the mysteries of FTP to get a copy in my own directory, and have no patience left for typing them all out. There is something wrong with the available instructional material in this regard - I find none that is helpful. Regards, Nancy ****** ****** ****** ****** ****** ****** Recommendation for a display-oriented message handling system: (from draft of MITRE paper, prepared for ARPA, 6-23-75) Rather than searching for the best syntax for a typewriter-oriented users' language, it would be worthwhile to carry the concept of a display-oriented text editor further, and design an entire message handling system which is display-oriented. a computer-naive user should not have to think in terms of commands and arguments when interacting with the message handling system. A display-oriented system could present options to the user, which could then be rearranged if necessary before computer processing, but which would not require the user to be concerned with syntax at all. With a display-oriented system, the user's typing would be minimized; this would, in turn, reduce the errors he would and could make. Obviously, typing is necessary during message creation and editing, and when entering comments or changes to a message. However, typing as a means for interaction with the system could be reduced, and possibly eliminated. Message reading and manipulation especially lend themselves to a structured sequence, in which typing would be minimal. For example, suppose a list of 20 messages is in the current file. Instead of typing "READ 1,2,3" or its equivalent, the user could select READ from a list of displayed options (using lightpen, mouse, cursor moving keys, etc.) select the messages he wants to see, and use an ENTER key when the list is complete. The messages would then be displayed as though the command list had been typed, except that no typing or syntax errors would have been possible. To move messages to another file, the appropriate command would be selected, the list of messages would be selected, and then a list of message files would be displayed. (An area for entering new file names could be provided.) After selecting the target file, the messages would be moved, and the list of messages and options displayed again. If the user tried to enter a list of messages before selection of a READ or MOVE command, either an error message could be presented, or that sequence could be allowed. Only those options that were valid at a particular point in the job sequence would be displayed at a given time. The user would not, however, have to be trapped into an undesired sequence. Escape options could always be included on the menu. Use of a display-oriented sequence is dependent on two factors: high speed transmission, so that lists of options could change very quickly and prompts could be presented without impeding the user's progress; and, use of a video display terminal, so that whole pages of text and options could be presented at once, and so that options could be selected, messages selected, etc. ------- 10-MAY-78 22:10:05-PDT,812;000000000001 Mail-from: USC-ISI rcvd at 25-JUN-75 0816-PDT Date: 25 JUN 1975 0809-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 057 [ISI]MessageGroup.List To: [ISI]MessageGroup.List: HI, I asked Dave Farber why he had two lists with only one name difference for the MessageGroup and he explained that [ISI]MSGRP.MAIL-LIST is an obsolete list and that he does not have any abreviated list because no one has asked to receive their messages through the filter he offered to provide. [ISI]MessageGroup.list is the only list you should be using. If anyone wants a copy for use in sending messages, I will be pleased to send you one in a message. You would have to edit the Message header junk away, but that is rather easy, I think. Best Regards, Stef ------- 10-MAY-78 22:10:06-PDT,3941;000000000001 Mail-from: BBN-TENEXA rcvd at 25-JUN-75 1259-PDT Date: 25 JUN 1975 1528-EDT Sender: ROURKE at BBN-TENEXA Subject: MSGGROUP# 058 Message Annotation and Related Security Issues From: myer To: [ISI]MessageGroup.List: Message-ID: <[BBN-TENEXA]25-JUN-75 15:28:41-EDT.ROURKE> Here are some thoughts on annotation, suggested by: . Stefferud 13 Jun Message Filing Function . Farber 13 Jun Answer to the Above . Vezza 19 Jun General Comments The following approaches toward annotation could be implemented rather quickly within the framework of our existing message systems. It might make sense to put up one or more of them on an experimental basis. 1. We could make it possible to annotate existing messages by adding new header fields. How about NOTES for plain text and FKEYS (standing for "File Keys") to hold key words? Attaching the new fields could be done by a command (how about "ANNOTATE"?) or an option to WRITE (which is like MOVE and PUT in MSG.) We would propose an initial cut that would avoid file shuffling by combining annotation with the transfer of messages into new files. Later, if message files get more structured, it should be possible to annotate messages in place. The Filter option would be extended to permit selective retrieval based on the new fields (it now handles the standard RFC-680 headers). This annotate feature would help preserve message integrity by segregating the added information. If you saw NOTES or FKEYS on a message, you could assume they were not part of the original. We could enforce this convention by making it impossible to SEND messages containing these fields. You would have to work a good deal harder, however, to authenticate the notations themselves. 2. We could make it possible to copy messages out of a file into the active work area of Mailsys. Once copied in this fashion, the fields of a message could be added to, edited, replaced, deleted, etc. using the present manipulation commands. It would then be possible to re-file the modified message. To help preserve integrity with this scheme, the system could add a "MODIFIED-BY" header field each time a message was put through the change operation. The added field would identify the manipulator, and possibly the date the changes were made. 3. An entirely different approach would disallow any modification of messages, once SENT. Instead, annotation would be accomplished by encapsulating existing messages in new ones, with the new message bearing such special header fields and notes as might be desired. A crude version of this can be accomplished right now with the FORWARD or INCLUDE commands. For example, you can set up a message containing any pattern of header fields you wish (including KEYWORDS), begin the text with your annotations, and then INCLUDE the message(s) you wish to annotate. It would not be difficult to embody something like the above operation in a special, prompted annotation sequence. The above are some rather rough first thoughts on how to do annotation. Questions: Does any of them seem like a desirable approach? If so, which makes most sense? Are there sufficient security measures in the first two? Would it make sense to put up one or more of these on a temporary, experimental basis? Your comments are invited. Incidentally, on the subject of security, we are going to have to make some system changes before the measures suggested above can have much effect. For example, right now if you're sufficiently careful about it, you can use an ordinary text editor to make any changes you want to an existing message file. As long as such free access is allowed to message files, I don't see how we can preserve message integrity. Regards, Ted Myer 10-MAY-78 22:10:06-PDT,404;000000000001 Mail-from: BBN-TENEXB rcvd at 25-JUN-75 1400-PDT Date: 25 JUN 1975 1701-EDT From: WATSON at BBN-TENEXB Subject: MSGGROUP# 059 Request to change address list To: farber at ISI, stefferud at ISI cc: watson I have accounts at both office-1 and bbnb; bbnb is my nominal home and would appreciate it if you could change your message address list so that my mail goes there. Thanks Dick ------- 10-MAY-78 22:10:06-PDT,250;000000000001 Date: 25 JUN 1975 1526-PDT From: FARBER Subject: MSGGROUP# 060 Re: Request to change address list To: WATSON at BBN-TENEXB cc: FARBER In response to your message sent 25 JUN 1975 1701-EDT I've done it for you. John Pickens ------- 10-MAY-78 22:10:06-PDT,2907;000000000001 Mail-from: BBN-TENEXB rcvd at 25-JUN-75 1432-PDT Date: 25 JUN 1975 1733-EDT From: WATSON at BBN-TENEXB Subject: MSGGROUP# 061 Need for Net Wide Ident System To: NGoodwin at BBN, Burchfiel at BBN, Myer at BBN, To: Gilbert at BBN, Mealy at ISI, Tasker at ISI, To: Mclindon at ISI, Walker at ISI, Farber at ISI, To: Stefferud at ISI, Ellis at ISI, Kirstein at ISI, To: Iseli at ISI, DCrocker at ISI, PBaran at ISI, To: Vittal at ISIB, Stotz at ISIB, Uhlig at OFFICE-1, To: Vezza at MIT-DMS, PIRTLE at I4-TENEX, watson at BBNB One aspect of a message system needing some discussion has to do with addressing. Recent notes indicate some problems for example in keeping all the address lists for this dialog the same on the several computers from which we all work. In the NLS system we have tried to come to grips with some of the issues in a central Ident system. The system itself is something of a kludge and would not remmend it to anyone, but there are acouple of ideas worth mentioning behind it. 1) We recognize that the9e are at least two types of idents required, one for individuals and the other for dialog groups. 2)People move from organization to organization and from computer to computer, therefore the ident contains no info about these but the supporting data in the ident record keeps track of such things, including mode of delivery, online, through US mail etc. 3) For groups there is a coordinator who gets to add subtract idents from group lists ala Farber in our case. 4) No matter which computer one submits a mail item from one uses the idents of the addressees and a lookup is made in the ident file to obtain the where and how type info for distribution. I like the idea ala sndmsg of having people be able to keep more informal groups as strings in some file of theirs and can imagine idents being searched for in some strategy like try the central official one then try mine etc. We have found that letting people go Zn and change or add new idents on their own tend to produce a dirty data base with lots of errors etc and do not know exactly how to get around this problem on a netwide basis. Having a central database gets into all the problems the BBN people have been working on with their TIP log in data base and know they will have similar problems. The problem of what constitutes a unique ident netwide ( NLS presentmly has the bad feature of limiting idents to a few characters and you get the akward situation of rww3 type things which seem to insult people)) needs to be agreed on. There is clearly a need to have synonyms and other abrieviations tailorable to individuaml usage, although care is required here when the distribution is printed for the receivers of how they can idenitify and send replys to such if they are recorded in my private file. Enough I just wanted to open up this area for discussion. Dick ------- 10-MAY-78 22:10:06-PDT,1047;000000000001 Mail-from: USC-ISI rcvd at 25-JUN-75 1513-PDT Date: 25 JUN 1975 1505-PDT From: ELLIS at USC-ISI Subject: MSGGROUP# 062 Secretaries answering Boss' mail To: [ISI]MessageGroup.List: Dave: I share your concern about the secretary "ghosting" problem. Your suggestion for an answer.msg file does create a good "tickler" file. However, the basic problem is that a recipient of a message sent via a secretary is somewhat confused by the name in the "FROM" field and is unable to use the MSG "answer" command correctly. The original message committee considered this problem a serious one and recommended that there be a "SENDER" field which is machine verified and that the "FROM" field be filled in - if different - to represent the authorizor of the message. Another possibility which doesn't lengthen (vertically) the header is to extend the "FROM" field with a ",for so and so." to be filled in by the secretary. Probably neither of the above are doable in the short term. Regards, Tom ------- 10-MAY-78 22:10:06-PDT,570;000000000001 Mail-from: BBN-TENEXA rcvd at 26-JUN-75 0756-PDT Date: 26 JUN 1975 1045-EDT Sender: ROURKE at BBN-TENEXA Subject: MSGGROUP# 063 ISI's IA Project From: myer To: Stutz at ISIB Cc: [ISI]MessageGroup.List: Message-ID: <[BBN-TENEXA]26-JUN-75 10:45:50-EDT.ROURKE> Rob: I read with interest your account of the IA project. Given the current effort in refining and testing MSG, I would have thought you planned to make it a part of your military service. Question: is this the case or are the two projects completely unrelated. Ted Myer 10-MAY-78 22:10:06-PDT,414;000000000001 Date: 26 JUN 1975 0939-PDT From: WALKER Subject: MSGGROUP# 064 Another addition to the Message Group To: Farber cc: Walker To the message list tender(in Farber's absense): Please add Spivey at ISI to the message group list. This is Maj Bert Spivey with tha Army Staff who has some good ideas on message services. Please send him a reference to the back dialogue too. Thanks Steve ------- 10-MAY-78 22:10:07-PDT,243;000000000001 Date: 26 JUN 1975 1528-PDT From: FARBER Subject: MSGGROUP# 065 Re: Another addition to the Message Group To: WALKER cc: FARBER In response to your message sent 26 JUN 1975 0939-PDT Spivey added to list. John Pickens ------- 10-MAY-78 22:10:07-PDT,371;000000000001 Date: 26 JUN 1975 1531-PDT From: FARBER Subject: MSGGROUP# 066 Membership in msg group To: SPIVEY cc: farber I added your name to the mailing list . ave Dave Farber is on vacation until mid-July. msg.proceedings has a transcript of what has been transpiring, tho I don't know if that is complete or is the official copy. John Pickens ------- 10-MAY-78 22:10:07-PDT,1619;000000000001 Mail-from: USC-ISI rcvd at 26-JUN-75 1108-PDT Date: 26 JUN 1975 1051-PDT From: DCROCKER at USC-ISI Subject: MSGGROUP# 067 Secretaries Answering Boss' mail To: [ISI]MessageGroup.List: Tom -- perhaps there is a short-term function that could be easily implemented: Given the current state of network/system/mail security, I suggest we ignore authentication issues. Anyone who wants to generate specious mail can easily do so. I tried it myself, recently, and found it every bit as easy as I feared. I am told that Tenex programmers have a been aware of the problem for quite some time. (Having your directory "protected" so that only the system mailer can deliver mail does not help. The mailer does not do any verification.) Also: The mail system, given the arrangement I suggested, would have two directory names (login and connected, with the mail sitting in the connected). Mailsys already "knows" about the SENDER field and I imagine MSG could learn fairly easily. So a mail system action along the following lines seems relatively easy: The user invokes a "secretary answer-back" command (no command name comes to mind, just yet) which causes the system to perform a normal Answer command (a la MSG) with one difference. The FROM field is the name of the Connected directory and the SENDER field is the Login directory. Admittedly, a hack. However I think that it might be sufficient within the current mail environment. However, I don't have secrtaries answer my mail, so I would appreciate an evaluation of the above, from those of you who do. Dave. ------- 10-MAY-78 22:10:07-PDT,1109;000000000001 Mail-from: BBN-TENEXB rcvd at 26-JUN-75 1931-PDT Date: 26 JUN 1975 2232-EDT From: WATSON at BBN-TENEXB Subject: MSGGROUP# 068 Minor Complaint with Survey and Operation of Mailsys To: burchfiel at BBN, myer at BBN cc: NGoodwin at BBN, Burchfiel at BBN, Myer at BBN, cc: Gilbert at BBN, Mealy at ISI, Tasker at ISI, cc: Mclindon at ISI, Walker at ISI, Farber at ISI, cc: Stefferud at ISI, Ellis at ISI, Kirstein at ISI, cc: Iseli at ISI, DCrocker at ISI, PBaran at ISI, cc: Vittal at ISIB, Stotz at ISIB, Uhlig at OFFICE-1, cc: Vezza at MIT-DMS, PIRTLE at I4-TENEX, watson at BBNB I am not exacctly sure how mailsys is implemented but frequently I do a survey and either have TI paper with message numbers around or remember them and decide later to go into Mailsys and print one or do something with it and can not use the message number until I do a survey of the whole days messages again. I assume that new messages get appended to end of file and so order does not change and thus old message numbers should still be valid. If so would like to use them. Thanks Dick ------- 10-MAY-78 22:10:07-PDT,764;000000000001 Mail-from: BBN-TENEXA rcvd at 27-JUN-75 0935-PDT Date: 27 JUN 1975 1226-EDT Sender: ROURKE at BBN-TENEXA Subject: MSGGROUP# 069 Your file space problem From: myer To: watson at BBNB Cc: STROLLO, [ISI]MessageGroup.List: Message-ID: <[BBN-TENEXA]27-JUN-75 12:26:05-EDT.ROURKE> Dick: My view is that the system should not have aborted under circumstances such as you describe. Our present file space enforcement policy seems much too rigid, and will hopefully soon be replaced by an alternative that will let you get your work done. Concerning status, you can presently use the MAILSTAT subsystem to check on unsent mail. Our plans call for embedding Mailstat functions into Mailsys. Regards, Ted Myer 10-MAY-78 22:10:07-PDT,1809;000000000001 Mail-from: BBN-TENEXA rcvd at 27-JUN-75 1258-PDT Date: 27 JUN 1975 1548-EDT Sender: ROURKE at BBN-TENEXA Subject: MSGGROUP# 070 Secretarial Mail Processing From: myer To: [ISI]MessageGroup.List: Message-ID: <[BBN-TENEXA]27-JUN-75 15:48:45-EDT.ROURKE> Dave & Tom: When we did the create part of Mailsys, we put in the SENDER and FROM fields as recommended by the message committee. The logic works as follows: SENDER is automatically filled in by Mailsys with the user's logged-in name. This is the authentication stamp. FROM is available to the user and will take any text string. Our secretaries log in under their own names and connect to our directories in order to process our mail. By convention each secretary inserts the authorizor's name into the FROM field of each outbound message. Thus, my messages will frequently show: SENDER: ROURKE at BBN-TENEXA because this is how my secretary, Mary Ann Rourke, logged-in; and FROM MYER, because this is how she filled out the FROM field. I believe this is what the committee had in mind. Problems: 1). The Mailsys REPLY command gives SENDER priority over FROM in setting up the outbound TO: field. That is, if the object message had a SENDER field the reply will go to that individual. 2). Since FROM accepts plain text, there's no guarantee that it will contain a legitimate network address. Possible fix: 1). Have REPLY given FROM priority, default back to SENDER if no FROM field or one that's not syntactically correct. 2). Make it possible (by option) for FROM to automatically pick up the Connected directory names. Comments? If this scheme looks reasonable we could probably make the change fairly quickly. Regards, Ted 10-MAY-78 22:10:07-PDT,679;000000000001 Mail-from: USC-ISI rcvd at 30-JUN-75 0932-PDT Date: 30 JUN 1975 0932-PDT From: ELLIS at USC-ISI Subject: MSGGROUP# 071 Secretary mail processing To: [ISI]MessageGroup.List: Ted and Dave: In my opinion, MAILSYS has done the right thing for the moment with SENDER and FROM fields. I like your "possible fix" but would like to emphasize that the connected directory be filled in "by option." This touches on another issue and that is aids for answering "forwarded" mail as in delegating the action or asking another more familiar for the answer. This is further complicated by possibly being nested several deep. Any suggestions? -- Tom ------- 10-MAY-78 22:10:07-PDT,999;000000000001 Mail-from: USC-ISIB rcvd at 30-JUN-75 0940-PDT Date: 30 JUN 1975 0940-PDT From: STOTZ at USC-ISIB Subject: MSGGROUP# 072 MSG and IA To: [ISI]MessageGroup.List: Date: 26 JUN 1975 1658-PDT From: STOTZ Subject: MSG and IA To: myer at BBN cc: STOTZ Ted, The MSG effort is completely separate from the IA project in terms of an officially sanctioned project. Some IA people have influenced the product, but it was basically done by John Vittal on his own time. However, the history is that MSG originated as a program by Barry Wessler called (I believe) NRD. Marty Yonke and John Vittal effectively rewrote it into a program called WRD. Marty then rewrote that effort, calling the result BANANARD. BANANARD was really the starting point for the code for MSG, but the real credit goes to Barry for the original idea for the system. I will expand further on the IA project and its goals as soon as I can get some free time. Rob ------- ------- 10-MAY-78 22:10:08-PDT,405;000000000001 Mail-from: USC-ISI rcvd at 30-JUN-75 1311-PDT Date: 30 JUN 1975 1239-PDT From: DCROCKER at USC-ISI Subject: MSGGROUP# 073 ANSWER selection of destination(s) To: [ISI]MessageGroup.List: The use of mailing list pathnames as the Groupname for the mailing list now makes it possible for an Answer command to automatically insert the list into the To: and/or CC: fields. Dave. ------- 10-MAY-78 22:10:08-PDT,932;000000000001 Mail-from: USC-ISI rcvd at 30-JUN-75 1344-PDT Date: 30 JUN 1975 1233-PDT From: DCROCKER at USC-ISI Subject: MSGGROUP# 074 Re: Secretary mail processing To: [ISI]MessageGroup.List: In response to your message sent 30 JUN 1975 0933-PDT I guess my current feeling is that the Answer command should perform as it currently does; but if it finds that the CONNECTed directory is different from the Login directory, it should ask the user if the FROM field should be "..." (the Connected dir) and SENDER field "..." (the login dir). I agree that the user should be prompted, rather than having the actions taken too automatically. Nice thing about Mailsys is the ability to iterate through the buffers, prior to msg transmission. (By the way, the business with the '"..."'s above was to suggest that the actual text to be used, rather than the terms "login" or "connected" directory.) Dave. ------- 10-MAY-78 22:10:08-PDT,692;000000000001 Mail-from: BBN-TENEXA rcvd at 30-JUN-75 1411-PDT Date: 30 JUN 1975 1657-EDT Sender: ROURKE at BBN-TENEXA Subject: MSGGROUP# 075 MSG From: myer To: stotz at ISIB Cc: [ISI]MessageGroup.List: Message-ID: <[BBN-TENEXA]30-JUN-75 16:57:51-EDT.ROURKE> Rob: Many thanks for your note and your interesting comments on the geneology of MSG. Here are two thoughts for you: 1. You would do the world a great service if you could explain where the BANANA came from in BANANARD. 2. It may be that MSG has a yet more primitive ancestor than NRD in the form of RD -- a system of Teco Macros that was (I believe) put together by Larry Roberts. Regards, Ted Myer 10-MAY-78 22:10:08-PDT,850;000000000001 Mail-from: BBN-TENEXA rcvd at 30-JUN-75 1441-PDT Date: 30 JUN 1975 1705-EDT Sender: ROURKE at BBN-TENEXA Subject: MSGGROUP# 076 (Minor Complaint with Survey and Operation of Mailsys) From: myer To: WATSON at BBN-TENEXB Cc: [ISI]MessageGroup.List: Message-ID: <[BBN-TENEXA]30-JUN-75 17:05:57-EDT.ROURKE> In-Reply-To: Your message of JUNE 26, 1975 Dick: Mailsys has to parse your message file before it can access the items contained. However, the parsing should happen automatically, when required, and it should be invisible to you. This is the case with SURVEY and READ, but not with WRITE. Needless to say, that's one of the things we're fixing. In the meantime if you do something like READ the item (abort with CTRL-E once output starts), you'll then be able to WRITE it. Ted Myer 10-MAY-78 22:10:08-PDT,4336;000000000001 Mail-from: USC-ISIB rcvd at 30-JUN-75 1527-PDT Date: 30 JUN 1975 1519-PDT From: STOTZ at USC-ISIB Subject: MSGGROUP# 077 ( Forwarded Mail ) To: [ISI]MessageGroup.List: Date: 23 JUN 1975 1721-PDT From: COHEN Subject: On network-mail system. To: ELLIS cc: OESTREICHER, STOTZ, VITTAL, COHEN AN UNSOLICITED MINORITY REPORT ON NETWORK MESSAGE SYSTEMS by the naive Danny Cohen (1) The MAIL system should consist of MAILSND and MAILRCV processes, communicating with each other according to some NMP (Net-Mail-Protocol). This protocol could be either a level-2 protocol, i.e. interfaced to the NCP directly, nested in the Host-to-Host (level-1) protocol, or (preferably) a level-3 protocol, interfaced to the FTP, nested in the File-Transfer-Protocol (level-2). (2) The NMP should allow inclusion of an (open-ended) set of control instructions in addition to the data (text, etc.). I would suggest inclusion of some escape character (say "*" for ease of notation in this message, but of course a non-printing character should be used). Would you believe anything (nearly) except ^C, ^O, ^T, ^Z, etc. (3) This structure will allow the use of multi-addressed messages, i.e., single transnet transmission of a message for all its receivers at the same host. The MAILRCV could have its own directory, which would include MAIL-LISTs constructed of individual names (both local and remote) and other MAIL-LISTs (also both local and remote). This will allow easy and simple implementation of mail-forwarding, addressing functions rather than individuals, addressing all members of a remote team, etc. The proper use of the escape character will allow simple and easy implementation of features like encryption of selected portions of a message or comments in any given field (e.g., "c/o" and "Attention"). (4) The original message preparation and message processing can be separated, as suggested by Ted Myer. BBN's approach to (original) message preparation looks very attractive, especially the ability to edit each field at any time and the formatting of messages. Page 2 The message input stage should allow interface to any available text editor to which the user is accustomed, and should include at least trivial formatting (like MRUNOFF and PRERUN, which do the obvious things right and are idempotent). I would recommend having FORMAT do at least as much as PRERUN does. The message processing should follow the approach represented currently by ISI's NMSG, which attempts to provide the user with the features he might want to have in the most natural and obvious way. (5) The online documentation should address several classes of users: * Those who know how to use the system but have forgotten the exact instruction format. They know "what" but forgot "how". * Those who are familiar with systems like this but not with this particular one. They know "what" but don't know "how". * The totally naive user who doesn't even know "what" (to expect from the system). All the available HELP should be like that in Casner's "MACGEN" (i.e., callable at ANY stage, with ability to return to that exact stage with the same screenload). (6) The system should be well interfaced with the ARCHIVE and RETRIEVAL systems. I suggest having a means of achieving sets of messages with their headers appended to an existing file in such a way that this file can be searched and the name of the archived file can easily be found. ------- I felt these comments might be of interest to the group. Rob Stotz ------- 10-MAY-78 22:10:08-PDT,2182;000000000001 Mail-from: USC-ISI rcvd at 1-JUL-75 1127-PDT Date: 1 JUL 1975 1113-PDT From: DCROCKER at USC-ISI Subject: MSGGROUP# 078 Format Processing for Message Preparation To: [ISI]MessageGroup.List: cc: Cosell at BBN, Anderson at RAND-RCC Rob -- Thanks for forwarding Danny's note. It reminded me of some similar suggestions I have: I like the idea of having a formatter which lets the user type his message in a natural way and then augments the appearance. (Mrunoff and PreRun know about double carriage-returns as para- graph breaks, PreRun has a number of other, more complex conven- tions for formatting pieces of text.) Along the lines of giving a user the tools he (maybe) uses elsewhere, I suggest having Mailsys use Mrunoff and Spell (a spelling corrector) rather than duplicate code. I also suggest that the formatter have the following rules: 1. It not paginate. (Mrunoff has this as a run-time option.) 2. It perform paragraph breaks upon encountering double-. 3. It indent the left margin if either the first or second lines of the new paragraph are to the right of the left margin of the last paragraph. (And out-dent the margin, if the reverse is true.) 4. It "hang" the first line out to the left of the left margin of the rest of the lines of the paragraph, if the second line is indented from the first. (This kind of formatting was demon- strated in Danny's note; e.g., with the asterisks.) 5. It "fill" lines with words from following lines, but NOT jus- tify lines. At the least, this would be a minor concession to those with slow terminals. I believe the above implies an idempotent processing capability. (By the way, I would like to thank BBN for expanding my vocabu- lary. Not being a mathematician, I had never heard the word before. It has an interesting sound to it. Oh, and while I am on the subject, can anyone give me a definitive judgement upon whether the noun, referring to a person or thing which "formats," is "formating" or "formatting?" Thanks.) What are the group's feelings about the above? Dave. ------- 10-MAY-78 22:10:08-PDT,2728;000000000001 Date: 1 JUL 1975 2206-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 079 New MessageGroup Procedure To: [ISI]Mailing.List: cc: amc, dale Effective with this message there is a new procedure for communications in the MessageGroup. A "files-only" directory has been established at ISIA that will contain the mailing list and the current complete MessageGroup Proceedings. To access the files in this directory simply login to ISI and preceed all file references with the directory name, e.g. filename.extension. FTP may also be used to GET a copy of the files for perusal in your own directory if you are not @ISI. In FTP, login ANONYMOUS with password ARPA to GET any Filename.Extension TO Local File (including TTY:). Unfortunately you cannot use MSG through FTP. The following files are currently defined: MESSAGE.TXT (readable by msg or xmail) contains the Proceedings to date. MAILING.LIST contains the current mailing list, including MSGGROUP@ISI. Junk-Mail. (readable by MSG or XMAIL) contains Junk Mail culled from the proceedings for the indicated week. There are two alternative methods for entering messages into the MessageGroup dialogue. 1. Send the message to [ISI]Mailing.List which will deliver it to everyone and place a copy in the Proceedings so individual recipients may discard their copy with the knowledge that a copy is in the Proceedings (in Message.txt). 2. Send one copy of your message to MSGGROUP@ISI for the Proceedings and then notify everyone in [ISI]mailing.List of your contribution. Note that this will place a copy of your notice in the Proceedings because MSGGROUP@ISI is in the mailing list. We will monitor and review the Proceedings to remove "junk" mail etc. and move stuff to separate files as may become appropriate. Long messages (documents etc.) will be placed in separate MSG or XMAIL readable files to facilitate FTP access of single documents. Junk mail will be Moved to [ISI]Junk-Mail. which will be ARCHIVED weekly so nothing will be destroyed. ARCHIVing policy for the main Proceedings file in Message.Txt is not clear as yet. We could ARCHIVE the whole thing each week to maintain a single complete backup without deletion of any messages, or we could delete earlier messages after some suitable period. Likewise, policy for handling Message.Txt after it has grown large is not clear either. Your suggestions are welcome on any aspect. Please send them to [ISI]Mailing.List or to STEFFERUD@ISI. Best Regards, Stef ------- 10-MAY-78 22:10:08-PDT,893;000000000001 Date: 2 JUL 1975 1531-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 080 MsgGroup@ISI is Operational From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Cc: DALE, AMC Message-ID: <[USC-ISI]2-JUL-75 15:31:41-PDT.STEFFERUD> Hi, You may have had trouble getting MsgGroup@ISI to accept messages mailed to it. Seems that "File-Only" Directories at ISI do not normally get Message.Txt files established in them, and we did not coordinate our plans with ISI Operations. Our SNAFU has been overcome with help from Dale and his Staff. Many thanks. It has been suggested that if you do not send a notice of shipment for messages mailed only to MsgGroup@ISI, we should send a notice of arrival for you. This seems a very good idea. We will send out such arrival notices once per day as required. More suggestions are welcome. Best Regards, Stef 10-MAY-78 22:10:09-PDT,1239;000000000001 Date: 4 JUL 1975 1412-PDT From: KIRSTEIN Subject: MSGGROUP# 081 The Attention Field To: MsgGroup attn:ptk,srw I have not entered the latest set of Mail Dialog, though I have also been following it with great interest. As many of you know, we are in the positon of having several users sharing one account. For this we developed the simmpleminded POST system, which sorted mail by the ATTENTIPN field at the start of the message(see above). We realize this should ideally be iin the header, and it was so defiined in one of the versions of mailsys of BBBN. Particularly when there is the sort of quantity of mail as is being generated by this recent spate of corresspondence, this ATTN field could come iin very useful. In one version it could act as a comnmonly recognized keyword, which could be appropriately sorted into a special file of that name in each recipients directory. It can also be used , if defined differently, to be sorted into a ffile other than the general message file, in the directory of any particular account so desiring it. If such a tecnique is not used, the general message file quickly becomes completely unusable in an environment like ours.~Peter T Kirstein ------- 10-MAY-78 22:10:09-PDT,548;000000000001 Date: 8 JUL 1975 2025-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 082 New MsgGroup Member To: Geoff at SRI-AI cc: [ISI]Mailing.List: Hi Geoff, Welcome to Message Group. Your name in now in the master Mailing list in [ISI]Mailing.list. You will receive some introductory stuff in the next few messages to get you into it. Message Group Members should add GEOFF@SRI-AI to their lists or get a new list from [ISI], or ask me to SNDMSG a new official copy. Best Regards, Stef ------- 10-MAY-78 22:10:09-PDT,826;000000000001 Mail-from: USC-ISI rcvd at 8-JUL-75 2058-PDT Date: 8 JUL 1975 2058-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 083 Mailbox Problem at MsgGroup@ISI To: [ISI]Mailing.List: Until further notice, you should be aware of a difficulty with FTP delivering mail to MsgGroup@ISI. The System is refusing to send mail to MsgGroup@ISI from ISI or from ISIB. The same problem no doubt exists from other sites but we have no hard evidence yet. There is no difficulty getting the system to deliver mail addressed to MsgGroup@ from ISI, but this option is not available to other sites. In the interim, please circumvent the problem by sending your MsgGroup mail to everyone on the list or be sure to copy Stefferud@ISI so I can insert it into the Proceedings from ISI. Thank you, Stef ------- 10-MAY-78 22:10:09-PDT,2751;000000000001 Date: 9 JUL 1975 2132-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 084 XMAIL circa July 1, 1975 From: STEFFERUD at USC-ISI To: mail2 at BBN Cc: [ISI]Mailing.List: Message-ID: <[USC-ISI]9-JUL-75 21:32:43-PDT.STEFFERUD> I was delighted to find that XED had been "put into XMAIL" until I discovered that the only way to get back to XMAIL is to Write the file from XED and exit from XED to the EXEC and then restart XMAIL, having lost everything in my various buffers. Furthermore, I get "ILLEG INST 256016000002 AT 167620" when I type "xed text: and it then puts me out to the EXEC having lost all my various buffers. Frankly, I find this to be encredible. Either I am just too dumb to use XMAIL or it should be recalled again because it does not perform as advertised. Having written the above, I decided I had better read the help file stuff on XED and TECO and EDIT before sending this message. I trust you all know what I found, but let me review it for you. DES EDIT has not been changed in the help file, although it is no longer available as a working command. DES XED gives a question mark. DES TECO gives a question mark. For some strange reason, DESCRIBE was not even accepting subcommands for a while, but with some persistence it began behaving normally again. Back to the problems with XED. In my opinion xed has not been "put into XMAIL!" Either it has a bug that ppevents putting the text field into the XED buffer following the XED command, or it was designed to require writing the file and then reloading it into XED, writing it from XED into another file and then reloading it with ^B into the chosen XMAIL buffer. The SAVE.FIELD Command does allow me to save any field I wish, one at a time in separate files, but this just doesn't meet my expectations to Back to the problems with XED. In my opinion xed has not been "put into XMAIL!" Either it has a bug that ppevents putting the text field into the XED buffer following the XED command, or it was designed to require writing the file and then reloading it into XED, writing it from XED into another file and then reloading it with ^B into the chosen XMAIL buffer. The SAVE.FIELD Command does allow me to save any field I wish, one at a time in separate files, but this just doesn't meet my expectations to be able to move form XMAIL to XED and back as with TECO. And one more thing, though I doubt that this is a complete list of the new troubles I will find, FORMAT still can't handle too long lines, as I expect this message to demonstrate. This of course renders XMAIL useless for reasonable text entry. Best regards, Stef ------- 10-MAY-78 22:10:09-PDT,4026;000000000001 Date: 11 JUL 1975 1211-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 085 Subdivision of Messages From: STEFFERUD@ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]11-JUL-75 12:11:39-PDT.STEFFERUD> Keywords: ENVELOPE,HEADING,TEXT,ANNOTATION,REFERENCES,KEYWORDS Keywords: SUBDIVISION,ATTN,TO,FROM,DATE,POSTMARK,CARE-OF,SUBJECT,IN-REPLY-TO,PLEASE-REPLY-TO,POINTERS,RETRIEVAL Keywords: MESSAGE,REVISION,COORDINATION,EDITING,NOTES Keywords: This message is prompted by an exchange of messages with Peter Kirstein following his "The Attention Field" message (MsgGroup #82). I hope it does not depend on any of the content of the messages you don't have, since we don't want to burden you with the whole bunch. I have been putting ATTN: stuff in the subject line of messages to shared mailboxes. The POST system certainly provides a systematic way to use ATTN fields, though I appreciate that the POST system has not been made efficient. I would like to see the idea propigated to MSG and XMAIL. Actually, I am beginning to see that there are several legitimate subsections of messages, though I agree that subdividing will threaten to over complicate things again for our non-computernik friends, including our secretaries (bless them, its hard to get along without them in here). My ideas are only half formed at this time. How about the following: ENVELOPE: Contains the addresses, including ATTN:, Care-Of: and Post-Mark: subfields. ATTN and Care-Of subfields would have to be associated with specific addressees on the envelope. Addressing protocols are messy, especially since SNDMSG preempted the comma which is normally used to put Last names first in addresses. Dave Farber and i have had several discussions on this topic without resolving it. We need Sur-names, Given-names, ATTN, Care-of, plus mailbox location fields. HEADING: Contains the Date: To: From: Subject: In-reply-to: Ref: Please-reply-to: etc. type fields such as we find on normal office correspondence now. This Header should not have all the stuff that XMAIL puts there now. Much of what MSG and XMAIL put in the Header belongs on the envelope, or elsewhere. eg. SENDER belongs on the envelope, Message-ID belongs on the envelope, "Mail-from: . . . . . . ." belongs on the envelope, etc. The date and time of release of the message belong in the header, but the time and date of posting and delivery belong on the envelope. Keywords belong elsewhere. TEXT: Contains the main body of the message, letter, memo, note, document, or what have you. ANNOTATIONS: Contains notes and comments such as one writes on envelopes and in the margins to keep track of things like "Who received copies," "What I think of this or that," etc. This subsection should be subject to appending after receipt, and subject to selective dissemination when the message is forwarded in a new envelope. Two way pointers into text would be nice. REFERENCES: Contains formal references to other system accessible documents, messages, etc. which might be susceptible to automatic retrieval via pointing to the reference. This subsection should also be susceptible to appending after receipt. Again, pointers would be nice. They might even be used to point to other messages which make up a collection of coordination information as required by the IA Project. KEYWORDS: Contains specifically chosen words or phrases to serve as keywords for keyword searches. Possibly there might be a program that analyzes messages to prepare keyword tables automatically and store them in a keyword subsection to avoid recomputing the keyword list for future searches. Again, this subsection should be susceptible to modification after receipt, or later to allow for revision of keywords in new situations. Any Comments, Stef ------- 10-MAY-78 22:10:09-PDT,3381;000000000001 Mail-from: BBN-TENEXA rcvd at 11-JUL-75 1741-PDT Date: 11 JUL 1975 2040-EDT Sender: MYER at BBN-TENEXA Subject: MSGGROUP# 086 (XMAIL circa July 1, 1975) From: MYER at BBN-TENEXA To: STEFFERUD at USC-ISI Cc: [ISI]Mailing.List: Message-ID: <[BBN-TENEXA]11-JUL-75 20:40:07-EDT.MYER> In-Reply-To: <[USC-ISI]9-JUL-75 21:32:43-PDT.STEFFERUD> Stef: 1. I don't know who told you that XED had been "put into XMAIL" as of July 1. No link between the two was attempted at ISI til July 9. 2. When we did make the attempt, XED was not in [ISI], where we had expected it, so we put a private copy in [ISI]. In so doing, we failed to realize that had unusually stringent file protection. We were able to access it -- logged in as SUSSMAN -- but apparently you were not. Ron Tugender's attached message explains this further. In any case the situation should now be restored to normal. 3. I'm not familiar with XED, but I believe it is supposed to hand it's text buffer back to XMAIL through the EXIT command. We have tried this with the current implementation on ISI and it appears to work. 4. I apologize for the documentation problem you ran into. That was my decision, and apparently a mistake in judgement. I felt that the notice we included in the NEWS command would be sufficient to get people started. Evidently I was wrong. 5. Thanks for pointing out the long lines problem in Xmail's formatter. We'll fix it as soon as we can. In the meantime if you'll remember to toss in an occasional , I think you'll find the formatter can straighten out quite considerably ragged text. Even with the bug you discovered, we have found XMAIL to be far from "useless for reasonable text entry". 6. This leads to a general comment. Please bear in mind that XMAIL represents the "limited experimental release of a developing system to a select group of friendly co-workers." As long as that's the case, you are going to keep seeing various forms of ragged behavior, especially when we put up new versions. The alternative is to regard XMAIL as a production system. If that's to be the case, then we'd prefer to withdraw it altogether until we ourselves are far more satisfied, not only with it's operation, but also the underlying design. Regards, Ted Myer -------------------- Mail-from: USC-ISIB rcvd at 10-JUL-75 1219-EDT Date: 10 JUL 1975 0927-PDT Sender: TUGENDER at USC-ISIB Subject: XMAIL-XED problems on ISIA From: TUGENDER at USC-ISIB To: Myer at BBNA Cc: Stefferud at ISIA, Cc: ISI-IA: Message-ID: <[USC-ISIB]10-JUL-75 09:27:14-PDT.TUGENDER> Ted, I checked out Stef's problems on ISIA and the reason he can't get XED from XMAIL is that the private copy of XED you are using is on a directory which is protected against any files being opened by other users. Its protection would have to be relaxed for users to access files there. Since you may not know as yet, the runnable version of XED at ISIA is XED.SAV (analogous to XED.SAV on ISIB). Having XMAIL call the version of XED on assures you of accessing the latest version of XED on ISIA. Ron ------- -------------------- ------- 10-MAY-78 22:10:09-PDT,5128;000000000001 Date: 14 JUL 1975 1445-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 087 ((XMAIL circa July 1, 1975)) From: STEFFERUD at USC-ISI To: MYER at BBN-TENEXA Cc: [ISI]Mailing.List: Message-ID: <[USC-ISI]14-JUL-75 14:45:24-PDT.STEFFERUD> In-Reply-To: <[BBN-TENEXA]11-JUL-75 20:40:07-EDT.MYER> Hi Ted, It appears that we have orthogonal views of the world, which have led to significant differences in our expectations. First to answer the points in your message of 11-July-75. 1. XMAIL NEWS, "Changes as of July 1" told me that XED had been "Put into XMAIL. I took the announcement at face value and assumed the obvious when I read it on July 9. 2. Ron Tugender's message does explain what happened (XMAIL pointed to a version of XED that was in an unaccessible Directory). Your message explains that you did not check out the operation of XED from the situation to be faced by MsgGroup users. I would like to assume that you will modify your release procedures for future changes to achieve better quality assurance for MsgGroup. 3. XED does work now as you supposed it should, and I agree that it is well done, both in design and implementation. It works exactly as I expected when I tried to use it on July 9. 4. I accept your apology regarding the documentation goof and I apologize for reacting so strongly when I found that it was not properly done. My reaction was based on the assumption that it had been the way I found it since July 1, 1975 since that is what NEWS said. If one can't trust the documentation, who can one trust? 5. I agree about the "occasional " to cope with the "long lines problem in FORMAT" but I will now use XED to enter text because it gives me auto insertion and gives me the power of the edit features of XED right there in my text entry facility. The assembly line approach to text entry is not reasonable, in my opinion. It does not make sense to me to enter text in one system, edit it in another , and square it up in yet another. If XED only had a "Fill" capability to square text without "Justification" I would find that it meets all my needs for message text entry. At least until something better came along in a single "package." Actually, I find that FORMAT messes up my intersentence spacing and makes the text look like I don't know the typing rules. (ie. two spaces following a period at the end of a sentence.) I would prefer simple filling of lines in place of low quality justification procedures. Non-network recipients of FORMATted messages must wonder about our secretaries' training. The other problem with the "occasional " solution is that I typically discover that I need the after it is too late. When I am composing my thoughts at the keyboard, it is very distracting to think about things like "occasional s." 6. I understand and appreciate the "limited release" concept and I apologize for violating the spirit of it by blasting in the MsgGroup channel instead of commenting privately to MAIL2@BBN. Indeed one alternative is for you to withdraw from MsgGroup exposure until the whole "package" is completed and then deliver it as a fait accompli. As things are going now, we are not far from that because we only get to feed back our concerns after you have done the implementation, which puts us in the position of attackers if we don't like what we see. By the time we get to register our thoughts, you are too far down the pike to accomodate our ideas (I think). Another alternative is for us to withdraw from commenting. I would like to suggest another alternative. A. I suggest that you let us know more in advance what you are going to do to XMAIL. For example, what are your next changes in the works? I would much prefer to give you constructive suggestions than carping criticism after it is too late. B. I also suggest that you adopt well thought out release procedures for system releases to MSgGroup which are like those for real products, at least to the extent that you don't leave such big holes for MsgGroup members to fall into. I would have had no reaction at all if the "Changes as of July 1" had been dated July 9, or had indicated that the "XED in XMAIL" feature was coming in the near future. Ted, We all want to help make XMAIL succeed. To help, we need more than the privilege of previewing it before public release. Hopefully we can have a better information interchange through the MsgGroup. I would like to hear from others in the group on this subject. My very best regards, Stef PS: I just discovered that XMAIL steals ^Es so the ^E command in XED is lost. It seeems that XMAIL remembers about ^E typed into XED and saves it for after return to XMAIL, where upon it reacts to the ^E and wipes out the modified text in the buffer. Its kind of an interesting bug. Good luck Stef ------- 10-MAY-78 22:10:10-PDT,568;000000000001 Mail-from: USC-ISI rcvd at 14-JUL-75 1653-PDT Date: 14 JUL 1975 1612-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 088 New MsgGroup Member To: RYLAND at ISI cc: [ISI]Mailing.List: Hi Chris, Welcome to Message Group. Your name in now in the master Mailing list in [ISI]Mailing.list. You have received some introductory stuff to get you into it. Message Group Members should add Ryland@ISI to their lists or get a new list from [ISI], or ask me to SNDMSG a new official copy. Best Regards, Stef ------- 10-MAY-78 22:10:10-PDT,1484;000000000001 Mail-from: BBN-TENEXA rcvd at 16-JUL-75 0850-PDT Date: 16 JUL 1975 1135-EDT Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP# 089 [MOOERS at BBN-TENEXA: XMAIL/MAILSYS: Xed, Format, ^E bug] From: MOOERS at BBN-TENEXA To: [ISI]Mailing.List: Message-ID: <[BBN-TENEXA]16-JUL-75 11:35:22-EDT.MOOERS> Begin forwarded message -------------------- Mail-from: BBN-TENEXA rcvd at 15-JUL-75 1449-EDT Date: 15 JUL 1975 1443-EDT Sender: MOOERS at BBN-TENEXA Subject: XMAIL/MAILSYS: Xed, Format, ^E bug From: MOOERS at BBN-TENEXA To: Stefferud at USC-ISI Cc: MYER, ROURKE, AIRPLANES Message-ID: <[BBN-TENEXA]15-JUL-75 14:43:28-EDT.MOOERS> Thanks for your message. Glad you are happy with XED now. I agree with you completely about the "justification" feature of FORMAT. Please note that >DEFAULT FORMAT NOJUSTIFY (CR) >RECORD.PROFILE (CR) will make FORMAT fill but not justify for you henceforth. We believe that XMAIL/MAILSYS needs editing capabilities within the system, and not in a subsystem like XED or TECO. This is on our priority list of new features. FORMAT is not really a separate system -- just a command in MAILSYS. Perhaps a FILL cpability could be included in an editing system that was automatically invoked whenever the user gave a message-creating command and began to enter text. We will look into the ^E bug. ---Charlotte Mooers ------- -------------------- End forwarded message ------- 10-MAY-78 22:10:10-PDT,776;000000000001 Date: 16 JUL 1975 1725-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 090 Proposed One Day Meeting of the Message Group From: FARBER at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]16-JUL-75 17:25:00-PDT.FARBER> The COMPCON this year will attract many of the message group to Washington. I would like to suggest that we gather on Friday September 12 th (right after COMPCON ) to both get up to date on the plans of the various implementers and to interchange ideas and physically meet each other. If there is sufficient interest Stef and I will form the agenda for the day. Please RSVP both your interest in such a get-together and particular session topics you would like to schedule or see held. Dave ------- 10-MAY-78 22:10:10-PDT,1013;000000000001 Mail-from: USC-ISI rcvd at 16-JUL-75 1902-PDT Date: 16 JUL 1975 1859-PDT From: FARBER at USC-ISI Subject: MSGGROUP# 091 Due to an error in Detach and Mailer , you may not have received this message To: [ISI]Mailing.List: Date: 16 JUL 1975 1725-PDT Sender: FARBER at USC-ISI Subject: Proposed One Day Meeting of the Message Group From: FARBER at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]16-JUL-75 17:25:00-PDT.FARBER> The COMPCON this year will attract many of the message group to Washington. I would like to suggest that we gather on Friday September 12 th (right after COMPCON ) to both get up to date on the plans of the various implementers and to interchange ideas and physically meet each other. If there is sufficient interest Stef and I will form the agenda for the day. Please RSVP both your interest in such a get-together and particular session topics you would like to schedule or see held. Dave ------- ------- 10-MAY-78 22:10:10-PDT,1632;000000000001 Mail-from: BBN-TENEXA rcvd at 17-JUL-75 0922-PDT Date: 17 JUL 1975 1222-EDT Sender: ROURKE at BBN-TENEXA Subject: MSGGROUP# 092 Stotz 10 Jul 1975 -- Need for Message Structure From: myer To: [ISI]Mailing.List: Message-ID: <[BBN-TENEXA]17-JUL-75 12:22:01-EDT.ROURKE> Rob: The message service subcommittee report "Proposed Specification of Inter-site Message Protocol" describes a structured message representation and a transmission protocol that I believe is intended to meet just the need you describe in your message. As you know, that report is now in draft form and under review by the full message service committee. I'd suggest going over it for any defects that might prevent it from performing the IA coordination functions you describe. My understanding is that it's not too late to make changes to the design. For general information, we plan to replace the existing Tenex Mailer/FTPSRV distribution system with one that implements the new message protocol. The new system will feature a cache/citation form of delivery that will eliminate much of the wasted redundancy built into the present approach. More on this later. Our hope is that the new delivery system will be useful to the IA project in supporting the various coordination functions you have described in recent messages. For example, it should enable coordination among groups scattered over two or more host computers. It will also permit useful redundant storage of messages at multiple sites for backup purposes. Ted Myer ------- 10-MAY-78 22:10:10-PDT,482;000000000001 Date: 17 JUL 1975 0932-PDT Sender: RYLAND at USC-ISI Subject: MSGGROUP# 093 (Stotz 10 Jul 1975 -- Need for Message Structure) From: RYLAND at USC-ISI To: ROURKE at BBN-TENEXA Cc: [ISI]Mailing.List: Message-ID: <[USC-ISI]17-JUL-75 09:32:23-PDT.RYLAND> In-Reply-To: <[BBN-TENEXA]17-JUL-75 12:22:01-EDT.ROURKE> Ted: How can the members of the message group get copies of the "proposed specification", in order to comment on it? Thanks, Chris Ryland ------- 10-MAY-78 22:10:10-PDT,748;000000000001 Date: 18 JUL 1975 1006-PDT Sender: ELLIS at USC-ISI Subject: MSGGROUP# 094 "Proposed Message Protocol" From: Tom Ellis To: [ISI]Mailing.List: Message-ID: <[USC-ISI]18-JUL-75 10:06:25-PDT.ELLIS> Chris Ryland and all: The "Message Committee" (much smaller than the Message Group) has a draft "proposed structured message protocol for intersite communication" recently prepared by a subcommittee. The Message Committee will "debug" this draft over the next several weeks before it is released to the larger audience. I would appreciate the "Group" being patient while the debug process is going on because I don't think it can be effectively "coordinated" over the whole group at this stage. Thanks, Tom ------- 10-MAY-78 22:10:11-PDT,1155;000000000001 Mail-from: USC-ISIB rcvd at 18-JUL-75 1204-PDT Date: 18 JUL 1975 1135-PDT From: STOTZ at USC-ISIB Subject: MSGGROUP# 095 New message transmission protocol To: myer at BBN cc: [ISI]Mailing.List: Ted, You are correct that the Message Service subcommittee's proposed protocol is designed to allow transmission of structured messages across the net. Don Oestreicher from the IA project is a member of that subcommittee, so that IA's requirements are already represented. However we will be reviewing the spec. The point of my message was to support the need for the new protocol and for message services that can take advantage of it, i.e. one's that provide more information than just the message itself. For those who are interested, contact Jack Haverty at MIT (JFH@MIT-DMS) for a copy of the proposed message transmission protocol. I am pleased to hear that BBN is implementing a new message handler to replace MAILER/FTPSRV. We are most interested in your design plans for this as we do plan to use it in our military message service. When can we expect to hear more about it? Regards, Rob ------- 10-MAY-78 22:10:11-PDT,602;000000000001 Mail-from: USC-ISI rcvd at 19-JUL-75 2250-PDT Date: 19 JUL 1975 2241-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 096 New Member Mooers@BBNA To: Mooers at BBNA cc: [ISI]Mailing.List: Hi Charlotte, Welcome to Message Group. Your name in now in the master Mailing list in [ISI]Mailing.list. You will receive some introductory stuff in the next few messages to get you into it. Message Group Members should add Mooers@BBNA to their lists or get a new list from [ISI], or ask me to SNDMSG a new official copy. Best Regards, Stef ------- 10-MAY-78 22:10:11-PDT,1825;000000000001 Mail-from: USC-ISI rcvd at 20-JUL-75 1724-PDT Date: 20 JUL 1975 1724-PDT From: WALKER at USC-ISI Subject: MSGGROUP# 097 MsgGroup vs Message Committee To: [ISI]Mailing.List: A comment on MsgGroup versus the "Message Committee". There has been some extra confusion of late about the two groups referred to above. Let me give you my view of what has been happening in hopes that it will make more sense. Last fall a group called the Message Service Committee was formed to plot a course for future development of message services on the ARPAnet. This group was chaired by Tom Ellis of ISI and included Jerry Burchfiel of BBN, Al Vezza of MIT, Tom Marill of CCA, Dick Watson of SRI Rob Stotz of ISI, and Peter Kirstein of U of London (did I forget anyone? sorry). This group has met several times and has made some recommendations. Their latest draft report is on a proposed protocol for transmitting structured message on the Net. This is a detailed adaptation of the latest PCP protocol for message transmission. It has very little (if anything) to do with the deliberations of the MsgGroup. Furthermore, it is at present a draft subject to much revision. I have directed that it not be distributed outside the Message Committee, please don't be offended. The MsgGroup, on the other hand, was formed largely spontaneously by a group of interested people commenting on how message services should appear to users (as opposed to how they should function internally). I'm pleased with the progress of this "conference". I am trying to arrange for Stefferud to serve as a "paid" organizer so that the groups ramblings can come out in a coherent form. I would encourage your continued participation here and in groups such as Dave Farber's Compcon get together. Steve ------- 10-MAY-78 22:10:11-PDT,731;000000000001 Mail-from: USC-ISI rcvd at 21-JUL-75 1251-PDT Date: 21 JUL 1975 1246-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 098 Add Kohanski@Rutgers-10 to MsgGroup List To: Koohanski at RUTGERS-10 cc: [ISI]Mailing.List: Hi Kohanski, Welcome to Message Group. Your name is now in the master Mailing list in [ISI]Mailing.list. So we may know you in a more friendly manner, will you please let us know your first name? You will receive some introductory stuff in the next few messages to get you into it. Message Group Members should add Kohanski@Rutgers-10 to their lists or get a new list from [ISI], or ask me to SNDMSG a new official copy. Best Regards, Stef ------- 10-MAY-78 22:10:11-PDT,3654;000000000001 Mail-from: BBN-TENEXA rcvd at 22-JUL-75 0617-PDT Date: 22 JUL 1975 0904-EDT Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP# 099 The Attention Subfield in The MAILSYS Address Fields. From: MOOERS at BBN-TENEXA To: [ISI]Mailing.List: Cc: HENDERSON, RBRACHMAN, ULMER Message-ID: <[BBN-TENEXA]22-JUL-75 09:04:54-EDT.MOOERS> Reference: Kirstein "The Attention Field", Msggroup #82. Discussion of Kirstein's message of July 7. The problem is that one MAILBOX sometimes serves a group of users or projects. How can the messages, as they arrive, be brought to the attention of different users? And how can they be sorted out at a later date? There are three ways that the current MAILSYS system can handle this: (1) Use the KEYWORDS field to store the appropriate keywords, names, names of projects, or whatever. The KEYWORDS field takes a text string as its argument. The idea is that it will usually consist of words, separated by commas, but this is not at all required. Ex: KEYWORDS: WHATZIT, WHOSIS The KEYWORDS field can be displayed in a long-form SURVEY with the command >SURVEY,(CR) >>KEYWORDS (CR) >>(CR) If you wish to search the KEYWORDS field with a READ or SURVEY command, you can first set up a FILTER: >FILTER (CR) >>REQUIRE KEYWORDS (CR) >>(CR) Then you can perform the sort and store the selected messages in a file with >READ,(CR) >>FILTER (CR) >>OUTPUT (CR) >>(CR) The commands can be typed in the abbreviated mode, of course. (2) Use the "Attention Subfield" of the MAILSYS address fields (TO, CC, and BCC). As currently implemented, the MAILSYS address field has the form
= , , ... where = @ () which is displayed as Name at Host (Attn: Text String) Ex: Mooers at BBNA (Attn: WHATZIT) Until now, the documentation of showed the form = @ (, , ... ) and the idea was (and is) that in future versions of MAILSYS, could be the primary user assigned to a multi-user MAILBOX, and the names in the parentheses could be secondary users authorized to use the MAILBOX. Whether the secondary users should be assigned identities in the system so that MAILSYS can parse and check them in -- at least in the local directory -- is an interesting point for debate. At present, the attention subfield is available for any kind of flag. It has the advantage of being in the TO, CC, and BCC fields, where you would normally look for an addressee, and the disadvantage that MAILSYS can't sort on it. In the address fields, MAILSYS will FILTER only for address lists and will not touch the stuff inside the parentheses, whether it consists of duly authorized names or not. Future versions of MAILSYS will certainly have to filter and sort on the Attention Subfields of messages. (3) It is also possible to put the attention flag at the beginning of the SUBJECT field, e.g., Ex: SUBJECT: WHATZIT: More thoughts on the Attention Problem. Then you can search for WHATZIT with a FILTER. This has the advantage that the attention flag shows up on a normal short-form SURVEY, and the disavantage that the subject field is, perhaps, not a very logical place for an attention flag. I hope this clarifies matters. I have changed the on-line documentation to reflect the system as it is now. ---Charlotte ------- 10-MAY-78 22:10:11-PDT,413;000000000001 Date: 22 JUL 1975 2108-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 100 One Day Meeting In Washington Query Subject: REF:msg 90-91 16 July 1975 From: FARBER at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]22-JUL-75 21:08:19-PDT.FARBER> Please RSVP ASAP as to your interest in such a one day meeting and any specific topics you would like to hear or present. Dave -------