10-MAY-78 22:10:37-PDT,3615;000000000001 Mail from BBN-TENEXA rcvd at 24-JUL-75 1339-PDT Date: 24 JUL 1975 1622-EDT Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP# 101 Proposed new MAILSYS features inspired by MSG. From: MOOERS at BBN-TENEXA To: [ISI]Mailing.List: Cc: AIRPLANES, HENDERSON, RBRACHMAN Message-ID: <[BBN-TENEXA]24-JUL-75 16:22:49-EDT.MOOERS> Stef: In your message of 14 July 1975 to Myer, you suggested that there be more discussion of future plans for MAILSYS and other message systems. The remainder of this message is intended as a step in that direction. The next release of MAILSYS will introduce new features designed to improve the performance of the system, especially in the message-processing commands. This memo discusses a few areas of improvement that were inspired by features in MSG. ENTERING THE MAILSYS SYSTEM When you give the command MAILSYS (CR) to the EXEC, you will have the option of specifying which file you want to use as the INBOX. @MAILSYS (CR) If you simply type @MAILSYS (CR) MAILSYS will input the default INBOX MESSAGE.TXT;1. MAILSYS will then automatically print out on your terminal, a set of one-line SURVEYs of all RECENT messages -- that is, all messages that have arrived since the last time you looked at that INBOX. This printout can be easily aborted if you don't want to see it at the moment. At your option, MAILSYS will interrupt a working session with an automatic SURVEY of new incoming messages. You will be able to set this option as part of your DEFAULT PROFILE. THE CONCEPT OF THE CURRENT ITEM The current item in MAILSYS is the item which is ready to be scanned and printed out, or otherwise output when the next message-processing command is given. The current item will be able to be (1) printed out "Current Item is N of M". (2) incremented or decremented by one. (3) set to any arbitrary number. (4) entered in an item list symbolically, as "." COMMAND STRUCTURE Wherever possible, the commands requiring several lines and the use of previously constructed FILTERS will be replaced by multipart, one-line commands. It will be possible to use "throwaway" one-time FILTERS, entered on the same line as the primary command. This will substantially reduce the burden of typing commands. LINEPRINTER OUTPUT Messages printed out on the lineprinter will automatically be preceded by a list of one-line SURVEYs, forming a table of contents. It will be possible to use MAILSYS to print out the MAILSYS on-line documentation on the lineprinter. SURVEYING The ability of MSG to SURVEY messages is considerably more flexible than the current MAILSYS implementatin, which offers only a SURVEY of all messages. The new MAILSYS release will provide a better engineered survey command that will make it possible to generate selective SURVEYs showing just part of the INBOX contents. MESSAGE STATUS MSG provides a simple and uniform way of describing various states of a message, which we will embody in the new release of MAILSYS. RECENT -- all messages that have arrived since the last time the user entered the INBOX OLD -- messages that arrived before the user last entered the INBOX SEEN -- messages marked SEEN UNSEEN -- messages that have not been marked SEEN DELETED -- messages marked for deletion UNDELETED -- messages that have never been marked for deletion, or that have been DELETED and then UNDELETED ---Charlotte ------- 10-MAY-78 22:10:38-PDT,452;000000000001 Date: 24 JUL 1975 1504-PDT Subject: MSGGROUP# 102 Sender: FARBER at USC-ISI From: FARBER at USC-ISI To: WALKER, STEFFERUD, MSGGROUP Message-ID: <[USC-ISI]24-JUL-75 15:04:37-PDT.FARBER> The following message was sent to MOoers in response to his msg of 24 July I approve very much of the ideas you put forth . I will wait egarly to having a chance to see how they work in practice within the MAILSYS enviornment Dave ------- 10-MAY-78 22:10:38-PDT,2273;000000000001 Date: 24 JUL 1975 1706-PDT From: TASKER Subject: MSGGROUP# 103 MSG Answer command To: MSGgroup [This is a copy of a message already sent to Vittal.] John: I just sent a message to your ISIA directory by mistake (re some changes Mooers is adding to MAILSYS). I used Answer to generate the message to Mooers and found that the A command is now a little confusing to use. The typeout of: <- Answer Respond to sender, specify additional cc: in message: (caps are my input) made me think that I was first supposed to enter the additional CC's. Naturally MSG came back and told me I was dumb by saying "No number given" to which I verbally replied "You ##$%&&%, you didn't give me the chance!! How the hell am I supposed to terminate my CC's and give you a number!!" To make matters (a little) worse, the help offered after entering the A for Answer (<- Answer ?) gives adequate information as to the options, but then types, "Send response to:" making me further believe that I was being asked for the actual CC items. How about "Response option:" instead? (I admit that this reaction on my part was not entirely rational at this point, but it WAS my reaction -- triggered by the earlier message leading me to believe that I was next expected to specify the actual CC items. As you're probably aware, user "mental context" has a lot to do with how a user interprets anything the least bit ambiguous.) The quick and dirty solution is to take away the colon that follows the "cc" and move the "in message:" up to the same line. If you can do it, it wounld probably be a little better to the terminal user if you could rearrange the response to be something like: <- aNSWER MESSAGE #: or <- aNSWER MESSAGE #: , r [ I know you are trying to keep the syntax consistent, so this is merely an illustration. However, something needs to be done. I also find it convenient to have the message system print out what's in the text buffer so far (as MAILSYS does). (This would clearly be inappropriate for Forward, but would be nice for Answer.) ------- 10-MAY-78 22:10:38-PDT,588;000000000001 Mail from USC-ISI rcvd at 26-JUL-75 1231-PDT Date: 26 JUL 1975 1214-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 104 MsgGroup Mailing.List To: [ISI]Mailing.List: [ISI]Mailing.List: @BBN, Burchfiel, Gilbert, NGoodwin, Myer, @BBNA, Mooers, @BBNB, Watson, @I4-TENEX, Pirtle, @ISI, MsgGroup, PBaran, DCrocker, Ellis, Farber, Iseli, Kirstein, Mclindon, Mealy, Ryland, Spivey, Stefferud, Tasker, Walker, @ISIB, Stotz, Vittal, @MIT-DMS, Vezza, @OFFICE-1, Robertazzi, Uhlig, @RUTGERS-10, Kohanski, @SRI-AI, Geoff, ------- 10-MAY-78 22:10:38-PDT,2609;000000000001 Mail from USC-ISI rcvd at 26-JUL-75 1317-PDT Date: 26 JUL 1975 1306-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 105 Mil Jernigan on MsgGroup Efforts To: [ISI]Mailing.List: Date: 26 JUL 1975 0138-PDT From: ISELI Subject: MsgGroup Efforts To: stefferud cc: iseli, robertazzi at OFFICE-1 Hi, Stef - I have been reading your MsgGroup messages with great interest and watching the development of your message system. I wonder if it would be possible to join your group and attend the one-day meeting in September. While Jean Iseli is out of town for a bit I have the use of his directories (which is why this message is coming from ISELI) and am taking care of his mail for him...sending him a printout through the common, ordinary, plebian come-down of U. S. Mails at the moment. I am Mil Jernigan, associated with Roland Bryan (UCSB Computer Systems Lab) in his consulting firm of ACC out of Santa Barbara, but located in the Washington DC area as a consultant to the DOD community in the area of ARPANET "technology" (a euphemism if I ever heard one!). Since the entire concepts of ARPANET and computer networks and the man/machine interface as computer networks are applied to communication is "my bag", all of the ideas on message handling are very much in my field of interest. I was with Doug Engelbart's SRI-ARC group through the whole development of the ARPANET until last September when I came East to work in this end of it. I ordinarily use the ROBERTAZZI@OFFICE-1 directory or this one at ISI. There are a number of approaches to message handling that some of the people I have been talking to have been exploring on a theoretical or not yet implemented...if we are going to implement it.... sort of basis. Have heard a lot of ideas kicked around, but nothing as far along as your group has gone. Thanks for your consideration. Please SNDMSG me at either (probably best to use the first one) at ROBERTAZZI@OFFICE-1 or here as ISELI@ISI (which does not have to be added since Jean is already getting the messages). However, I would appreciate having my name and address of ROBERTAZZI at OFFICE-1 added. Please inform me of the meeting. I am looking forward to it. Mil Jernigan c/o ROBERTAZZI@OFFICE-1 U. S. Mails to Ms. Mil E. Jernigan P. O. Box 174 Annapolis Junction, Maryland 20701 Phone: (301)953-7561 P. S.: Jean sends his regards and sorry he could not get together with you before he left for Oregon. He will probably be back for a bit some time next month. ------- ------- 10-MAY-78 22:10:38-PDT,730;000000000001 Mail from USC-ISI rcvd at 26-JUL-75 1317-PDT Date: 26 JUL 1975 1303-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 106 Robertazz@OFFICE-1 Added To: [ISI]Mailing.List: Hi Mil, Welcome to Message Group. You are now in the master Mailing list in [ISI]Mailing.list. (Robertazzi@Office-1) You will receive some introductory stuff in the next few messages to get you into it. Message Group Members should add Robertazzi@Office-1 to their lists or use the new official list just sent to you via SNDMSG. Best Regards, Stef PS: I am forwarding your request for MsgGroup membership to the group for their information. I found it very interesting and good group input. S ------- 10-MAY-78 22:10:38-PDT,575;000000000001 Date: 27 JUL 1975 1545-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 107 Mailbox Finder Program at ISI From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Cc: alan at ISIB Message-ID: <[USC-ISI]27-JUL-75 15:45:08-PDT.STEFFERUD> ISI is now running a program called MAILBOX, which has the ability to redirect mail, which is sent to several addresses of a user, to one address. For more information, read MAILBOX.USER-DOC or request that copy of the file (2 pages, 3694 Chars) be sent via SNDMSG. Regards, Stefferud@ISI ------- 10-MAY-78 22:10:39-PDT,611;000000000001 Mail from USC-ISI rcvd at 28-JUL-75 1445-PDT Date: 28 JUL 1975 1431-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 108 Adding Tom Marill to MsgGroup To: Tom at CCA cc: [ISI]Mailing.List: Hi Tom, Welcome to Message Group. Your name is 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 Tom@CCA (for Tom Marill) 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:39-PDT,551;000000000001 Date: 28 JUL 1975 1913-PDT From: STEFFERUD Subject: MSGGROUP# 109 New MsgGroup List To: MsgGroup List Recipients: cc: MSGGROUP [ISI]Mailing.List: @BBN, Burchfiel, Gilbert, NGoodwin, Myer, @BBNA, Mooers, @BBNB, Watson, @CCA, Tom, @I4-TENEX, Pirtle, @ISI, MsgGroup, PBaran, DCrocker, Ellis, Farber, Iseli, Kirstein, Mclindon, Mealy, Ryland, Spivey, Stefferud, Tasker, Walker, @ISIB, Stotz, Vittal, @MIT-DMS, Vezza, @OFFICE-1, Robertazzi, Uhlig, @RUTGERS-10, Kohanski, @SRI-AI, Geoff, ------- 10-MAY-78 22:10:39-PDT,717;000000000001 Date: 28 JUL 1975 1906-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 110 RE: mailing list From: STEFFERUD at USC-ISI Cc: [ISI]Mailing.List: Message-ID: <[USC-ISI]28-JUL-75 19:06:41-PDT.STEFFERUD> In response to the message sent 28 JUL 1975 1852-EDT from WATSON at BBN-TENEXB Hi Dick: There is no problem with sending you a copy of the new member list each time it changes. I will set up a file in Recipients.newlists to hold the addresses of all who want a new list each time, and then send it to you all. I have been sending the new list to each new member each time anyway. A new list is being sent to you now under separate cover. Best regards, Stef ------- 10-MAY-78 22:10:39-PDT,10500;000000000001 Mail from BBN-TENEXA rcvd at 30-JUL-75 1200-PDT Date: 30 JUL 1975 1357-EDT Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP# 111 (NELC at USC-ISIB: Comments on Mail System) From: MOOERS at BBN-TENEXA To: NELC at ISIB Cc: MYER, HENDERSON, CALVIN, MALMAN, Postel at BBNB, Cc: Postel at SRI-ARC, [ISI]Mailing.List: Message-ID: <[BBN-TENEXA]30-JUL-75 13:57:02-EDT.MOOERS> In-Reply-To: Your message to Malman at BBN, 17 July 1975 The following message from NELC at ISIB was forwarded to me at BBN. I am including it and my reply in one message to members of the Message Group. (I've stripped off a few of the "envelopes" that came with it, in the interest of saving space.) ---Charlotte Mooers Begin forwarded message ---------------------------------- 4942 Chars Mail from USC-ISIB rcvd at 17-JUL-75 1334-EDT Date: 17 JUL 1975 1034-PDT From: NELC at USC-ISIB Subject: COMMENTS ON MAIL SYSTEM To: MALMAN at BBN, POSTEL at BBNB, POSTEL at SRI-ARC THE FOLLOWING COMMENTS WERE PREPARED PRIOR TO MY READING OF RFC#680 BY MEYER AND ANDERSON OF BBN-TENEX. NO NETWORK ADDRESSES WERE GIVEN FOR THEM SO COULD YOU PLEASE FORWARD THIS MESSAGE TO THEM. SOME OF THE ISSUES I RAISE WERE CONSIDERED IN THE RFC, BUT OTHERS WERE NOT, MOST NOTABLY THE ISSUE OF MULTIPLE ADDRESSEES ("IN-BASKETS") WITHIN A SINGLE MAILBOX. I see that the mail mechanism is being upgraded. I would like to enter my opinion about services that should be included in any such system. The services divide naturally into two areas that are normally reflected in different sub-systems that the user invokes: creation/sending functions and recieving/filing systems, plus a couple of functions on the nether ground between. First, the creation/sending functions. There should be a way of creating, editing, and verifying a letter before sending it. In other words, a text editor should be a part of the facility, either by the send function calling on a host editor, or having a host editor that can call the send function. XED here at ISI is a good example of the latter approach. It should be possible to send mail to different "in-baskets." If no in-basket is specified in the send request, a standard in- basket should be assumed(like MESSAGE.TXT). (More about in-baskets below.) The header information should be more standardized so that certain information is always included in all messages. The minimum should be the date/time sent, the originator, the addressees(both action and informational,if any), and a subject. NLS mail(at OFFICE-1) does not include the addressees -- this means that if an "interesting" message is ever recieved, you fire off copies to anyone who might be interrested if you're not sure they got a copy. It's possible to recieve half-a-dozen copies of the message before things settle down. The ability to "can" a distribution list and re-use it is very useful. It should be possible to send to multiple distribution lists. It should be possible to exclude elements of a distribution list. Elements of distribution list should be permitted to be further references to other distribution lists. A distribution list shouldn't be identical to a file, i.e., it shouldn't be necessary to clutter up a directory with a lot of names. As a middle ground between send and recieve functions, it should be possible to request a "return reciept," i.e., a message that is sent back to the originator when the mail is first read by an addressee. The return reciept would be a standard message that identifies the message(by its subject line?) and the addressee who opened it. This would reduce the hassle of people asking that reciept of messages be acknowledged. It should be possible to send a copy of a message to another addressee. Another function present should be to send a reply to a recieved message, that is, merely indicate that you wish to reply to the message and your message will be sent to the originator of the recieved message. Options should permit the inclusion of the original addressees and the addition of new addressees to be sent carbon copies. MSG and BANANARD at ISI have some good facilities along this line. It is a blessing for someone as stumble-fingered as I am. The recieve function should insert the time of reciept in the message header before placing it in the appropriate in-basket. It should be possible to read from the various in-baskets and then file the messages in various files. Messages should be placable in more than one file without undue space penalty. NLS has some nice facilities along this line. There should be an associated journal file. This file would contain the header information of each message recieved and functions would be available to search it on various attributes -- a range of dates, the originator, an addressee, the in-basket, a partial match(computed by some hit function) on the subject, or some combination ** of the above. It should also be possible to search through in-baskets and files as well. In these cases, the search functions could be extended to scan through the text of the messages, but I'm not too crazy about the idea. There should be functions, selectable between implicit and explicit, that permit older messages and journal entries to be archived. Messages should age independantly, so that, for example, all messages that haven't been viewed for at least a month and all journal entries over a year old could be archived. Retrieval functions will be necessary as well. -------------------- End forwarded message NELC -- We appreciated your thoughtful comments on mail systems, and we'd like to know your full name. Report RFC # 680 "Message Transmission Protocol" by Myer and Henderson covers only a small part of the questions that have to be considered in the design of mail systems. I have attempted to comment on the topics you discussed in the order in which you presented them. 1. Creation/Sending Function. MAILSYS now includes a choice of text editor, TECO or XED, that can be run within MAILSYS on a "lower fork". FUTURE PLANS: Text editing facility within MAILSYS that is automatically invoked when text is entered in a message field. 2. MAILSYS automatically includes in the header information, the DATE/TIME sent, the SENDER, the addressees (TO, CC, and BCC for those on the BCC list), and the SUBJECT, if any. The other optional headers are included if they are used. 3. Distribution lists can be entered from files. A list of addressees can be given a "groupname". The groupname alone appears on the copies of the message. (See, for example, the group name of the Message Group in the CC Field of this message.) The SENDER, but not the recipient, can look at the complete list. FUTURE PLANS: We're thinking of a "Cache-Citation" delivery system that would make it possible for the recipients to see the complete lists hidden in group names. The problem of MAILSYS-accessible directories for message files and for saved parts of messages, such as addressee lists, is under study. 4. Return receipts. At present, you are notified by TENEX MAILER only if your mail is undeliverable (if, for example, there is no such MAILBOX at a remote site). FUTURE PLANS: The "Cache-Citation" system would include a capability for automatic receipts which notify the SENDER whether or not the recipient has processed each individual message. 5. Sending a copy to another addressee. This can be done now with the MAILSYS commands FORWARD and INCLUDE. 6. MAILSYS has a REPLY that helps you answer messages in the way you want. It fills in the TO, SUBJECT, and IN-REPLY-TO fields and automatically calls the TEXT field for you to fill in. You have the option of setting the system defaults so that copies go to all the addressees in the CC field of the original message. You can also add (or add to) any message fields, as you wish. 7. The next release of MAILSYS will change the date-time in the one-line SURVEY from "date sent" to "date received". MAILSYS now records and displays the date received in the full text of the message. 8. All messages are placed in the standard INBOX, MESSAGE.TXT;1, in each directory. The recipient can easily transfer messages from MESSAGE.TXT;1 to any other file. Any MAILSYS-readable file can be turned into a temporary INBOX for the purpose of processing, but not receiving, messages, through the use of the command INPUT (CR). There is a real difficulty with having the ability to send messages to more than one INBOX in a directory: How can the sender be sure that the recipient will check all his/her INBOXES? How can the sender know for sure which files are considered to be message-receiving INBOXES by the recipient? At present, the decision is to have only one INBOX for incoming messages. The Attention Subfield of the addressee fields may be able to solve the problem of several people using the same INBOX. 9. The function of the associated "journal file" is partially filled by the MAILSYS command SURVEY. It is now possible to SURVEY messages and selected upon almost all parts of the header fields. FUTURE PLANS: Complete facility for searching for all addressees and text strings in all header fields. Possibly also, an index file associated with each message file so that it is not necessary to parse the message file each time a SURVEY is made. 10. The problem of archiving older message is under study at present. In some installations, messages can be archived through the use of the TENEX EXEC in the local TENEX archive-backup facility for general file storage. The present MAILSYS system has a subcommand (and default option) of the command SEND which is called ARCHIVE, and which causes a copy of the message to be sent to the DATACOMPUTER for permanent storage. It is our understanding that the DATACOMPUTER is an experimental, public-access information facility whose entire contents is accessible to all users of the ARPANET. Messages ARCHIVED in the DATACOMPUTER can be retrieved, one by one, with the command RETRIEVE through the use of the MESSAGE-ID fields of the ARCHIVED messages. ---Charlotte Mooers ------- 10-MAY-78 22:10:39-PDT,3051;000000000001 Mail from BBN-TENEXA rcvd at 31-JUL-75 1130-PDT Date: 31 JUL 1975 1322-EDT Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP# 112 Standard mail protocol on FROM and SENDER -- a discussion From: MOOERS at BBN-TENEXA To: [ISI]Mailing.List: Message-ID: <[BBN-TENEXA]31-JUL-75 13:22:26-EDT.MOOERS> These comments on the "standard mail protocol" for the FROM and SENDER fields are the result of correspondence between Dan Kohanski of Rutgers and Ted Myer and Austin Henderson of BBN. We thought the rest of the Message Group might like to see them. ---------- The new standard mail protocol, defined in the Network Working Group paper, RFC #680 (NIC #32116), "Message Transmission Protocol", by Myer and Henderson, April 30, 1975, has changed the specifications for the FROM and SENDER fields from that of the earlier paper RFC #561 (NIC # 18516), "Standardizing Network Mail Headers", by Bhushan, Progran, Tomlinson and White, 5 September 1973. The new definitions are as follows: "FROM. This field contains the identity of the person who wished this message to be sent. This is expected to be the originator field which is specified by the user in the case that the message is being entered by one person for another. The message-creation process should default this field to be the user entering the message. [The usage for FROM and SENDER differs from that of RFC 561.]" In other words, FROM defaults to SENDER. "SENDER. This field contains the identity of the person who sends the message. This field is expected to be set by the message- creation process automatically. It is possible that some sites will not include this field in external communications." RFC #680 goes on to say " It is expected that the current system will be able to authenticate only the SENDER field; however, later systems might have mechanisms to verify that the FROM actually authorized the SENDER to act on his/her behalf. It is expected that when the FROM is authenticated, the SENDER will no longer be necessary for external distribution." What this means is that the "standard mail protocol", as defined in RFC #680, is not actually in use at the moment. The "SENDER" field is the primary field now, in the sense that it is the field automatically filled in by MAILSYS. However, if you are simply scanning mail, the FROM field is more useful because it is more likely to tell you who really originated the message. For this reason, the MAILSYS command "SURVEY" in its standard form prints out a one-line summary containing the item no., date, FROM field, and SUBJECT. However, it is possible to do a more elaborate survey that includes the SENDER field, or any other header field you want. Maybe you want to be able to look at SENDER if somebody types "Bob" or "Guess Who?" in the FROM field, assuming that you correspond with more than one Bob, or you can't guess. That kind of problem doesn't come up very often, and it will eventually cease to exist. ---Charlotte Mooers ------- 10-MAY-78 22:10:39-PDT,2040;000000000001 Mail from RUTGERS-10 rcvd at 31-JUL-75 1235-PDT Date: 31 Jul 1975 1535-EDT From: KOHANSKI at RUTGERS-10 Subject: MSGGROUP# 113 RUTGERS-HARVARD AUTHENTICATION OF "FROM" FIELD To: BURCHFIEL at BBN-TENEX, GILBERT at BBN-TENEX, To: NGOODWIN at BBN-TENEX, MYER at BBN-TENEX, MOOERS at BBN-TENEXA, To: WATSON at BBN-TENEXB, PIRTLE at I4-TENEX, MSGGROUP at USC-ISI, To: PBARAN at USC-ISI, DCROCKER at USC-ISI, ELLIS at USC-ISI, To: FARBER at USC-ISI, ISELI at USC-ISI, KIRSTEIN at USC-ISI, To: MCLINDON at USC-ISI, MEALY at USC-ISI, MEALY at USC-ISI, To: RYLAND at USC-ISI, SPIVEY at USC-ISI, STEFFERUD at USC-ISI, To: TASKER at USC-ISI, WALKER at USC-ISI, STOTZ at USC-ISIB, To: VITTAL at USC-ISIB, VEZZA at MIT-DMS, ROBERTAZZI at OFFICE-1, To: UHLIG at OFFICE-1, KOHANSKI, GEOFF at SRI-AI, To: TOM at CCA-TENEX CHARLOTTE MOOERS HAS SUGGESTED I FILL THE GROUP IN ON PART OF A PRELIMINARY DISCUSSION WHICH LED TO THE DEFINITIONS OF THE "FROM" AND "SENDER" FIELDS THAT HAS JUST BEEN DISTRIBUTED. IN THIS CONTEXT, I HAD DESCRIBED TO TED MYERS THE NATURE OF THE MAIL AUTHENTICATION IN USE AT RUTGERS AND HARVARD. WHEN A USER LOGS IN, HIS NAME IS TAKEN FROM THE SYSTEM ACCOUNTING FILES AND INCLUDED IN THE MONITOR TABLES; THE USER HAS NO WAY OF INTERFERING WITH THIS PROCESS, AND SO THE MONITOR IS GUARANTEED TO KNOW THE USER ACCORDING TO THE NAME THE SYSTEM MANAGER HAS ASSIGNED HIM. MAIL USES THIS SAME TABLE TO SUPPLY THE VALUE OF THE "FROM" FIELD, AND SO AUTHENTICITY IS PRESERVED. SHOULD A USER GIVE HIS PASSWORD TO SOMEONE ELSE, THAT PERSON CAN THEN SEND MESSAGES UNDER HIS NAME, BUT THIS IS UNAVOIDABLE AND AT THE USER'S CONSCIOUS RISK. WE PERMIT PEOPLE WHO ARE NOT LOGGED IN TO SEND MAIL LOCALLY, BUT NOT ACROSS THE ARPANET. IN THIS CASE, THE "/ID:" SWITCH IS REQUIRED, IN WHICH THE MAILMAILER SUPPLIES SOME IDENTIFICATION. THIS CANNOT BE GUARANTEED, AND SO THE MAIL PROGRAM ADDS A TAG TO THE "FROM" FIELD WHICH READS: "(NOT LOGGED IN)" AS A WARNING. [DANIEL KOHANSKI] ------- 10-MAY-78 22:10:40-PDT,584;000000000001 Mail from USC-ISI rcvd at 31-JUL-75 1650-PDT Date: 31 JUL 1975 1635-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 114 Adding Engelbart@OFFICE-1 To: [ISI]Mailing.List: Hi Doug, Welcome to Message Group. Your name is 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 Engelbart@OFFICE-1 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:40-PDT,3262;000000000001 Date: 31 JUL 1975 1700-PDT From: AUTHENTICATOR Sender: FALSIFIER Subject: MSGGROUP# 115 Automatic Authentication To: Kohanski at RUTGERS-10, Mooers at BBN-TENEXA, Stefferud Cc: MSGGROUP I am concerned about some problems with the AUTHENTICATION issue. Some time ago one of our MsgGroup Members demonstrated that one could easily send a message to anyone that looked like it came from anywhere, with all the earmarks of authentications but in fact being false. That somehow violates our sense of how things aught to be, and I see that there is quite a bit of effort being applied to in fact prevent that kind of thing. I wonder why this is really necessary? The US Mail doesn't do this for us now, and it never will because no Postal Service is in the AUTHENTICATION business. If you think about it, even NOTORIZATION does not "guarantee" authenticity, though it does subject the NOTORY to legal action in the event of a violation. I suspect that AUTHENTICATION is only going to be a relative thing, which in case of a serious need to be absolutely sure of the source, will require extra efforts to determine the required degree of AUTHENTICITY, such as calling for verification by phone., forwarding the message back to the sender for verification, etc. There are other ways to establish extreme degrees of authenticity when required, so I don't see a need to automate it in the Message System. If it is customary to AUTHENTICATE messages by some other extra network means, the likelihood of violations should decrease as the possibility of successful violation becomes limited. To restate my point. A degree of authenticity is clearly required so our normal communications will be smooth and not subject to doubt at every turn. My question is directed at the perceived need for extreme degrees of automatic authentification. I don't think we, or anyone else, will ever succeed in relieving us of our individual responsibilities for authenticating our received messages by analyzing the messages, checking back on the source, or what ever. In some ways, the more we depend on automatic AUTHENTICATION, or on other than ourselves for authentication, the more subject we become to being duped by the clever ones among us. Best regards, Stef PS: I am attaching the original message that provided the demonstration for your perusal. - - - - - - - - - - - - - 813 Chars TO: INTERESTED PERSONS FROM: Whoever I want to claim to be 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:10:40-PDT,702;000000000001 Mail from USC-ISI rcvd at 31-JUL-75 2007-PDT Date: 31 JUL 1975 2007-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 116 FROM/SENDER, MAILSYS/MSG To: MOOERS at BBNA, VITTAL at ISIB cc: [ISI]Mailing.List: It seems clear to me that the new (RFC #680) spec for FROM and SENDER make good sense. FROM should default to SENDER. And Answer should similarly default to SENDER when FROM is not a legal address. Is it reasonable to omit the SENDER when it is the same as FROM? And, is it an accident that MSG chooses the SENDER field and the first subject field for inclusion in its SURVEY while XMAIL chooses the opposite, FROM and last SUBJECT? Curiously, Stef ------- 10-MAY-78 22:10:40-PDT,416;000000000001 Mail from USC-ISI rcvd at 1-AUG-75 1628-PDT Date: 1 AUG 1975 1614-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 117 New NMSG Answer Command To: VITTAL at ISIB cc: [ISI]Mailing.List: Hi John, I like the new version of NMSG Answer much better. It took a minute figure out what was happening, without reading any instructions. It is much more intuitive now. Thanks, Stef ------- 10-MAY-78 22:10:40-PDT,364;000000000001 Mail from USC-ISI rcvd at 1-AUG-75 1831-PDT Date: 1 AUG 1975 1821-PDT From: FARBER at USC-ISI Subject: MSGGROUP# 118 Answer commands To: vittal at ISIB cc: [ISI]Mailing.List: John, Being always poking, I have been trying NMSG. I find that the answer command there is much better than the one that is MSG. I vote for it. Dave ------- 10-MAY-78 22:10:40-PDT,616;000000000001 Mail from USC-ISI rcvd at 1-AUG-75 1930-PDT Date: 1 AUG 1975 1919-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 119 Adding Pickens@ISIB to MsgGroup To: [ISI]Mailing.List: Hi John, Welcome to MsgGroup Mailing.List. Since you helped to frame the MsgGroup Procedures and are involved with the management of the Proceedings in @ISI, I will not burden you with all the new member stuff. MsgGroup Members should add Pickens@ISIB to their mailing lists or obtain a new copy from [ISI]Mailing.List or request that I SNDMSG a copy to you. Enjoy, Stef ------- 10-MAY-78 22:10:40-PDT,260;000000000001 Date: 4 AUG 1975 1135-PDT From: TASKER Subject: MSGGROUP# 120 NMSG Answer Command To: Vittal at ISIB cc: Msggroup John: Bravo! I used the new Answer command in NMSG today and I LIKE it! Keep up the good work. Aloha Nui, Pete ------- 10-MAY-78 22:10:40-PDT,610;000000000001 Date: 8 AUG 1975 2318-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 121 Adding Panko@OFFICE-1 From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]8-AUG-75 23:18:44-PDT.STEFFERUD> Hi Ray, Welcome to Message Group. Your name is 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 Panko@OFFICE-1 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:41-PDT,717;000000000001 Mail from USC-ISI rcvd at 11-AUG-75 1354-PDT Date: 11 AUG 1975 1332-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 122 Moving Ryland to Rutgers-10 To: [ISI]Mailing.List: Date: 11 AUG 1975 1324-PDT From: STEFFERUD Subject: Re: going away To: RYLAND, STEFFERUD In response to the message sent 11 AUG 1975 1256-PDT from RYLAND at USC-ISI Hi, Sorry to see you go, but I guess we must all agree that ISIA has been overloaded lately. Hope Rutgers-10 will suffice for you. [ISI]Mailing.List has been modified per your request and the group is informed that your Mail should be addressed to Ryland@Rutgers-1 in the future. Best regards, Stef ------- ------- 10-MAY-78 22:10:41-PDT,1131;000000000001 Date: 13 AUG 1975 2026-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 123 A short report on an experiment using CALENDAR and Subject: SNDMSG From: FARBER at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]13-AUG-75 20:26:53-PDT.FARBER> Several months ago, an experimental marriage of the CALENDAR system of the tenex and the sndmsg facility was designed and implemented by John Pickens and myself. The idea was to generate from the calendar data base each morning the appointments of the day and to sndmsg this information to the person. As an additional by product an reminder mechanism was implemented which "rang" an alarm at specified times of the day and printed the reason for the alarm on the console. The system proved rather usable although inadequacies of the tenex required explicit actions on the part of users at LOGIN time for the reminder mechanizm . I believe that the experiment showed the usefulness of expanding the message system into a personal communication system as well as an interpersonal one. Dave ------- 10-MAY-78 22:10:41-PDT,3318;000000000001 Mail from SRI-AI rcvd at 14-AUG-75 0501-PDT Date: 14 AUG 1975 0459-PDT From: GEOFF at SRI-AI Subject: MSGGROUP# 124 Mailbox hack at ISI. To: [ISI]Mailing.List: cc: Alan at ISIB A couple weeks ago, Stef (I think) sent out a message about the new MAILBOX hack that ISI ofered to its users. I had known about this for sometime, when I discovered it at BBN, but when I sent a note to Clements about it, I got no response, and just sort of passed it off at the time as something that I'd like, but was in no rush to get. When I discovered that it had been brought up on the ISI 10's, I sent ALAN@ISIB, a message asking 'HOW' one went about bringing it up. He at least responded to my query, and sent me some blurb that he managed to srounge out of BBN, that really didn't help that much at all; I mostly had to punt and look at what BBN and ISI had done with it. Anyway, my major gripes about it, after uncovering its inner most secrets of operation are: 1. It requires that a person, namely a systems group member, who is a wheel, do all the manipulation of the Database rather than the user himself, which is somewhat of a hassle for both parties involved. 2. the only way that you can get the hack to 'do its thing', is to have a systems group member fiddle with the users MESSAGE.TXT, (again requiring wheel), turn the bit off that allows the message.txt file to be deleted. This is REALLY not the way to do it. See 3. Major gripe: 3. The fowarding scheme works fine for people who have a directory on machine in questionm with their message.txt's deleted, as SNDMSG will try to write it at, and fail and then attempt to sent it though the network, in which FTP Serve will foward it to the correct address, providing an entry has been made in the MAILBOX database. However, nicnames will not work at ALL, unless routed though the network, I.E. I have GOODFELLOW@SRI-AI defined as a nickname for GEOFF@SRI-AI. This works fine if some user sends mail to GOODFELLOW@SRI-AI, though the ftp server. However, if a user on SRI-AI, tries to send a note to user GOODFELLOW, he gets the message 'No such local user'!!! But!, if the local user sends to GOODFELLOW@SRI-AI (having the mail go though the Ftp Server), all is peachy. That is pretty bad I think, since local users are the ones that you deal with the most, and are probly the ones to make the mistake the most of anyone. The right way to do it would be for SNDMSG to pull in the hash table that MAILBOX makes (and FTP Server uses), into it at start up time and then when a users TO person fails, try it against what is in the Database, and act accordinly. This could also be made one step better, by having the mail put directly into the users fowarded MESSAGE.TXT (if its the the same system), and not have to route the mail though FTPSRV, which would take longer for starters, and uses more over head than shoving it directly in the file. I think that pretty much covers what I think needs to be added to the MAILBOX system to make it better. I'm sure that others have ideas on how to improve it, and would enjoy sharing them. Tiredly yours, [Geoff] ------- 10-MAY-78 22:10:41-PDT,2886;000000000001 Date: 14 AUG 1975 1454-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 125 Defined Files From: Stefferud at ISI, Pickens at ISIB To: [ISI]Mailing.List: Message-ID: <[USC-ISI]14-AUG-75 14:54:21-PDT.FARBER> Special-Handling: To be kept as message #3 in Special-Handling: [ISI]message.txt Effective with this message there is a new procedure for handling messages in the "files-only" directory at ISIA. The following files are now defined and are accessible: [ISI]MESSAGE.TXT now contains several introductory messages which describe the current procedures, and is followed by any recently arrived messages which have not been processed by the MsgGroup Secretary. [ISI]TRANSCRIPT.MSG contains the entire transcript of the MsgGroup proceedings to date, minus the unprocessed messages in MESSAGE.TXT. Each message in this file has been modified to insert a unique MsgGroup transaction number (e.g MSGGROUP# n) at the beginning of its SUBJECT: field. [ISI]PROCEEDINGS.MSG contains all substantive dialogue messages, but excludes administrative messages, etc. [ISI]PROCEEDINGS.HEADERS contains the extracted headers of all the messages in PROCEEDINGS.MSG to facilitate less expensive searching of the Proceedings. Headers include all SENDER: FROM: TO: CC: KEYWORD: etc. fields stripped from the original messages. It is in SNDMSG file format so it can be read and searched with any message handling system. [ISI]ADMINISTRATIVE.MSG contains only administrative messages. (e.g. new members, announcements of procedures, etc.) [ISI]MAILING.LIST contains the current mailing list, which includes MSGGROUP@ISI. [ISI]RECIPIENTS.MAILING-LIST contains the addresses of MsgGroup members who wish to automatically receive a fresh copy of the MAILING.LIST each time it is revised. Future procedures for sorting and cross-referencing the messages and for archiving old messages (and retrieving them back) are being investigated. These procedures were developed by John Pickens and Einar Stefferud. The tools for implementation were provided by John for use in managing the conference files. They are not for general use. The tools include some TECO MACROS for extracting individual messages from a given MSG file, an automatic sequencer, and a text stripper for producing the HEADERS file. There is potential for appending new fields with these tools to include KEYWORDS, FILED-UNDER, and other annotations useful to the conduct of a SNDMSG TeleConference. Your suggestions are welcome on any aspect of operations. Please send them to MSGGROUP@ISI. Best Regards, John and Stef ------- 10-MAY-78 22:10:41-PDT,3000;000000000001 Date: 14 AUG 1975 1513-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 126 New Msggroup Procedures From: Stefferud at ISI, Pickens at ISIB To: [ISI]Mailing.List: Message-ID: <[USC-ISI]14-AUG-75 15:13:15-PDT.FARBER> Special-Handling: To be kept as message #2 in Special-Handling: [ISI]MESSAGE.TXT Welcome to MsgGroup: This message will tell you how to access the MsgGroup files and how to send dialogue messages to the group. Additional messages may be found in [ISI]MESSAGE.TXT which explain more about the message handling procedures and the way the files are organized. ACCESSING [ISI]FILES If you have a Directory at ISIA, you can LOGIN to ISI and preceed all file references with the directory name to access the files. (e.g.filename.extension) If you do not have a Directory at ISIA, FTP may be used to GET a copy of the files for perusal in your own directory. In FTP, you should LOGIN ANONYMOUS at ISIA with password ARPA to GET any [ISI]Filename.Extension TO Filename.Extension (including TTY:). Unfortunately you cannot use MSG through FTP, but you can use MSG, MAILSYS or any other mail handling system on MSG files transfered via FTP to TENEX sites. Simple requests for copies of messages will obtain Forwarded messages from the files. An MSG Survey Listing of the headers in PROCEEDINGS.MSG is available upon request for the convenience of those who do not wish to use FTP. Send your request to MSGGROUP@ISI. FTP users will find it in [ISI]PROCEEDINGS.SURVEY. ENTERING INTO THE MSGGROUP DIALOGUE There are two alternative methods for entering messages into the MsgGroup dialogue. 1. Send your message to [ISI]MAILING.LIST, using , which will deliver it to everyone, including a copy to MSGGROUP@ISI. Then individual recipients may discard their personal copy with the knowledge that a copy will be kept in [ISI]. 2. Send one copy of your message to MSGGROUP@ISI. You may want to then notify everyone in [ISI]MAILING.LIST of your contribution. Periodic notices of unannounced arrivals will be sent to MAILING.LIST. [ISI]MESSAGE.TXT will be monitored to process all messages into the transcript file, to answer and to remove administrative messages, and to move stuff to separate files as may become appropriate. Long messages (documents etc.) may be placed in separate MSG files to facilitate FTP access of single documents. Future procedures for sorting and cross-referencing the messages and for archiving old messages (and retrieving them back) are being investigated. Your suggestions are welcome on any aspect of operations. Please send them to MSGGROUP@ISI. If you wish further assistance or more information, please request it by sending a message to MSGGROUP@ISI. Best Regards, Einar Stefferud and John Pickens ------- 10-MAY-78 22:10:41-PDT,3414;000000000001 Mail from SRI-AI rcvd at 14-AUG-75 1948-PDT Date: 14 AUG 1975 1939-PDT From: GEOFF at SRI-AI Subject: MSGGROUP# 127 Comments on MAILBOX hack & a thought for the day from Alan@ISIB. To: [ISI]Mailing.List: Mail from USC-ISIB rcvd at 14-AUG-75 1448-PDT Date: 14 AUG 1975 1451-PDT From: ALAN at USC-ISIB Subject: Re: Mailbox hack message To: Geoff at SRI-AI cc: Alan Yes, i would enjoy sharing my views on MAILBOX. I agree wholeheartedly with your major gripe. Removing that prolem would create a major convienience for mail senders. Remember, tho, that as users get attached to that feature, it must be incorpor- ated into XMAIL, and other hacks, like MSG, which can send mail, or the users will be very confused. I beleive that the inertia to be overcome is great, but, if it can be done, it will be well worth it. One additional suggestion that i have for MAILBOX, (besides the need for better documentation ) is that it should accept host nicknames in its text file. I disagree strongly with your first 2 gripes. The logic and code required to implement them in a secure way is complex enough, so that it would not be completed unless as a recognised project. First of all, there are several jokers on the net who delight in showing system program- mers expamples of weaknesses in their software, and would jump on an insecure implementation of your ideas like a heroin addict going thru the D.T.s . Secondly, altho there may not be a security problem right now, there may be one in the furure. All we need is one, at the wrong time to cause some real damage. Assuming that solos. to your 2 gripes are installed, here are 5 exs. of malicious use, in approximate order of 'ease of solo.'. 1)A user deletes other users forwarding addresses. 2)A user inserts messages-from-the-phantom 100s of pages long, in the text file. 3)If no check on a PERMANENT mailbox is done, a user gives himself the nickname LICKLIDER, waits for mail, then deletes the nickname. 4)A user gives himself the nickname LICKLIEDER, plus several others like it, and recieves mispelled mail. 5)A user with an account on 2 more machines creates an infinite loop by having mail sent to a garbage address on machine 1 go to a garbage address on machine 2, and visa-versa , and then sends a series of messages to one of the addresses. Unless all of these problems (plus those which hackers much more clever than i can think of ) are solved, we cannot let the users touch the mailbox.text file. Lastly, i would like to apologise for my curt replies to your mail concerning MAILBOX . I was in a period of having to do a lot of things under time pressure, and couldn't really concern myself at all with worries about enhancments to convenience items. Also, i didn't (and still do not) know much more about MAILBOX than the info contained in that .MEM file i got from BBN. For those reasons, my replies to you were minimal. Hope we can have better contact in the future, Alan P.S. thought for the dsy: Yesterday, we had some DEC guys down here, and one mentioned that ARPA seems to consist of a bunch of people who beleive they communicate with each other, because they send messages to each other on different computers. ------- So much for DEC and its understanding of the network....[Geoff] ------- 10-MAY-78 22:10:42-PDT,57921;000000000001 Mail from USC-ISIC rcvd at 15-AUG-75 0505-PDT Date: 14 AUG 1975 1701-PDT Sender: WATSON at BBN-TENEXB Subject: MSGGROUP# 128 The Chapter on the NLS Journal System by Jim White From: WATSON at BBN-TENEXB To: Burchfiel at BBN, Gilbert at BBN, NGoodwin at BBN, Myer at BBN, To: Mooers at BBNA, To: WATSON, To: Tom at CCA, To: Pirtle at I4-TENEX, To: MsgGroup at ISI, PBaran at ISI, DCrocker at ISI, Ellis at ISI, Farber at ISI, Iseli at ISI, To: Kirstein at ISI, Mclindon at ISI, Mealy at ISI, Spivey at ISI, Stefferud at ISI, To: Tasker at ISI, Walker at ISI, To: Pickens at ISIB, Stotz at ISIB, Vittal at ISIB, To: Vezza at MIT-DMS, To: Engelbart at OFFICE-1, Panko at OFFICE-1, Robertazzi at OFFICE-1, Uhlig at OFFICE-1, To: Kohanski at RUTGERS-10, Ryland at RUTGERS-10, To: Geoff at SRI-AI, To: ------- at SRI-AI Message-ID: <[BBN-TENEXB]14-AUG-75 17:01:19-PDT.WATSON> Recorded Dialog:.Center=3; the NLS Journal, Identification, and Number Systems By James E White.Pbs; OUR CONCEPTION OF RECORDED DIALOG RECORDED DIALOG One of the prime objectives of the augmentation system developed at ARC is to aid collaborating knowledge workers by providing flexible computer tools and methodology for communicating with one another. We collectively refer to such tools and a methodology as a Dialog Support System (DSS). Its primary task is to provide mechanisms for transmitting online messages and documents between users. However, for large projects or those about which some larger community of users must remain informed, the dialog soon becomes unmanageable without additional computer aids. arc's DSS therefore 1) permanently records (copies to read-only storage), 2) numbers (assigns a unique accession, or catalog number), 3) and catalogs (records author, title, number, and location) each piece of dialog--for later consultation, for reference by later documents, and for examination by interested bystanders. THE JOURNAL arc's DSS is implemented as a set of computer processes called the Journal, consisting of a foreground subsystem that interacts with the user and provides primitives for entering a message or document in the Journal (with title, author and other information), reserving catalog numbers, and so forth; and a background process that further processes submission requests and delivers mail to the addressees indicated by the author. The Journal is supported by several additional systems: an Identification System responsible for maintaining information about users--their location, group memberships, phone numbers, and so forth--and a Number System responsible for keeping track of which catalog numbers have been assigned, and to whom, and which are available for future assignment. Since its implementation in April of 1971, the Journal has been heavily used (now containing over 10,000 messages and documents), initially by the ARC staff, then by a larger user community with network access to arc's computer facility, and most recently by commercial and government users of a second computer facility operated for ARC. The Journal has evolved as a result of our experience and in response to the increased demands placed upon it by its growing user base. This section describes that experience and evolution. OUR INITIAL IMPLEMENTATION THE arc/NLS ENVIRONMENT arc's DSS resides on a heavily loaded Digital Equipment Corporation (DEC) PDP-10 running Bolt, Beranak, and Newman's (BBN) TENEX operating system. TENEX provides a time-sharing environment in which 10 to 20 users independently interact with any of a variety of applications packages called "subsystems". arc's PDP-10 is devoted almost exclusively to providing access to a single subsystem, arc's NLS [1], a comprehensive system of tools for manipulating structured text. NLS provides a very general set of primitives for manipulating and viewing tree-structured text files. Commands are provided for manipulating the tree's structure, e.g., for adding nodes called "statements" to the tree, for deleting single statements or whole branches of the tree, for moving or copying a subset of the tree from one location to another, and so forth. In order to maintain flexibility in the first implementation and to facilitate maintenance of the system, NLS text files were consistently used in implementing the Journal, Identification, and Number Systems' principal data bases, as well as for catalogs, indices, and a variety of internal, inter-process communication files. STRUCTURE The Journal The Journal System is a set of procedures that runs in both foreground and background modes to maintain a data base of recorded documents, and to distribute them to specified addressees. Larger Journal documents are stored as separate files in a set of system directories. Short documents, called "messages", given special treatment in the interests of economical storage, are stored in a set of (currently about 20) files, several hundred to a file. Whenever a document remains unreferenced for a month, it is archived to magnetic tape by TENEX, and its online storage released for other use. Although over 10,000 items have been journalized on the PDP-10 since April of 1971, most have long ago been archived and therefore do not occupy online storage, except when brought back for reexamination. The Journal maintains a system catalog of all recorded documents, implemented as a set of (currently five) online files. The catalog contains information used by NLS to locate a Journal item given its catalog number, as well as information used by stand-alone programs to produce nonsystem catalogs and indices (by author, titleword, and number). Journal mail addressed to a particular user is delivered in one or both of two delivery modes, online and hard copy. The delivery parameters are selected by the addressee and maintained by the Identification System. A document's author need know nothing about the delivery modes of its addressees. ON-LINE DELIVERY Regular users of NLS normally receive online delivery of all their Journal mail. Each item is placed by the Journal in a special NLS file called the user's "initial" file (so named because the file's name is the user's ident, which is usually his initials). For convenience, this file is automatically loaded for the user when he enters NLS. The text of short messages is delivered to the user in its entirety. For longer items, only a citation giving the document's author, title, and date, and a convenient, machine-readable pointer (called a "link") to the text of the document are delivered. HARD COPY DELIVERY Hard copy line printer output is sent by U.S. mail to users who never or only infrequently use NLS or who, for one reason or another, want it in place of, or in addition to, online delvery. A substantial amount of clerical support is required to support hard copy delivery. The Journal maintains information about ongoing distribution operations in a single NLS file, used also as a vehicle for communication between the submission and distribution components of the background system. The Identification System The Identification System is a set of procedures that maintains a large data base, implemented as a single, very large NLS file, containing information about individuals, groups of individuals, and organizations (each of which is assigned a unique name called an "ident"). Various information fields are maintained for each ident, and procedures are provided for manipulating each field. The Identification System includes an NLS subsystem that permits users to interrogate and modify the data base themselves, subject to the appropriate access controls. Because of the data base size, and because updating the data base involves creation of a new version of the file (requiring about 30 seconds or more of real time on a loaded system), all of the changes for a particular ident are collected from the user before the file is updated. The Number System The Number System is a set of procedures that manage a data base, implemented essentially as a single NLS file, containing information about the assignment of catalog numbers to Journal documents. The data base contains: 1) a number of blocks of numbers available for assignment 2) a list of assigned numbers (either recently used, assigned but as yet unused, or in the process of being used) and for each the date and time of assignment and the idents of the users to whom they were assigned. It is often useful to know in advance what number will be assigned by the system to a particular item. This is necessary, for example, to create a set of documents that internally reference one another. A catalog number may therefore be reserved for later submission, or "preassigned". The RFC number system, a separate special-purpose number system patterned after the master system (and thus able to use most of the same primitives), was implemented at the request of an informal group of network protocol developers. An item may have an RFC number in addition to the master catalog number. EXPERIENCE AND PROBLEMS A number of problems with the initial Journal implementation have been encountered and attacked. Some of the major problems are described below. Excessive real-time required for submission: In the initial implementation, the entire submission process, with the exception of delivery, was performed in the foreground and therefore kept the user from other work for what often, given the system load, proved to be an inordinate amount of time. In an attempt to alleviate this problem, the submission mechanism was restructured, and all manipulation of catalog, distribution, and storage files deferred to the background process. A special system directory was established for queuing submission requests for the background process that now goes through two distinct phases. First, all queued submissions are processed: numbers are assigned where necessary, the document is stored in the appropriate message or separate file in the appropriate system directory, the document is cataloged, and a distribution request is queued. And second, whatever distribution requests have accumulated are processed, one individual addressee at a time. To further reduce the amount of processing that must take place in the foreground, a form of submission is permitted in which the task of assigning a catalog number is deferred to the background process. Deferred submission is the default, and most submissions are therefore of this type. Since deferred submission does not require write access to any system files, a user can submit an item in this mode at any time, regardless of the state of the Journal or Number System files. Background delivery degraded system performance: The Journal background process has proven to be very expensive to run, and often has had a detrimental effect upon the responsiveness of the system as viewed by its interactive users. We have experimentally varied the frequency with which the background process runs (and thus with which mail is delivered) from once per day initially, to its current frequency of once every hour. The background process now periodically checks the load average (the TENEX monitor's measure of system demand) and suspends processing if it is above some predetermined cut-off value. Processing is resumed only when the load average drops sufficiently. The check is performed at a point in the process when the system files are consistent and least vulnerable to a crash. Between these check points, the process runs at high priority. The benefits of this strategy are threefold: the background process does not add appreciably to the system load when it's already high; it can exploit slack times throughout the day; and since the probability of a crash increases with system load, the Journal and Number System files are usually in a relatively invulnerable state when a crash occurs. Data bases vulnerable to system failures: A very serious problem of the initial Journal implementation was the vulnerability of the various system files to hardware (especially disk) problems, monitor crashes, and exhausted disk storage. The processing of hard copy output, besides being time consuming, was similarly vulnerable to both software and hardware failures. The danger of losing system files because of lack of disk storage has been greatly reduced by also checking for available disk space at the same time the load average is checked. Processing is terminated until the next hour if space is too low. This strategy prevents losing a system file due to exhausted disk space during a file update. A number of problems associated with the processing of hard copy output have been largely eliminated. A variety of monitor bugs have been fixed or avoided. The bulk of the processing is done during the evening or early morning hours. Because of the volume of hard copy output produced by the Journal, the print requests were first placed on magnetic tape and printed on an IBM 360 system elsewhere at SRI, and finally contracted outside of SRI. Network delivery, described in the next section, has, on the other hand, drastically reduced the volume of hard copy produced, and thus recently permitted us to resume printing on our own system at OFFICE-1. EXTENSIONS FOR A NETWORK ENVIRONMENT THE ARPANET ENVIRONMENT In July of 1970, arc's PDP-10 became part of the ARPANET, now an international network of large-scale computer facilities called "hosts" linked by 50 kb communication lines. Once the lowest level, inter-machine communication protocol was developed, the central task was to design and implement the software protocols required for general, inter-process communication, and other, more specialized exchanges. This task was undertaken by an informal group of geographically separated systems programmers called the Network Working Group (NWG). In early l969, ARC had offered to serve as the Network Information Center. As soon as hardware connections were made and protocol development reached a stage sufficient to permit simple, teletype-like use of a remote time-sharing system, ARC began to provide dialog support for the NWG via the Journal. JOURNAL CHANGES TO SUPPORT THE NETWORK At first, the Network user used the Journal in nearly the same manner as a local user. Like local users, he had to login to the ARC system and use NLS to compose and journalize a document. But unlike most local users, he received hard copy, rather than online delivery of his Journal mail. When ARPANET protocols developed to the point of permitting the transmission of text files and mail to users at remote hosts via the Network itself, the Journal was modified to utilize this new capability. Network Delivery The File Transfer Protocol (FTP) [2] devised by the NWG permits the transmission of text to a named "mailbox" at a remote host. For purposes of receiving mail, therefore, each Network user has a network address consisting of a host name and a mailbox name. To exploit this new Network capability, we added a third, network delivery mode to the existing online and hard copy modes, storing a network address in the ident file for each Network user. A Network user can thus take delivery of all Journal mail addressed to him, in his own system, simply by storing the appropriate delivery parameters in the Identification System. Rather than deliver extremely long documents in their entirety, via the Network, we made the same size distinction for network delivery as for online delivery, sending only citations for long documents. We modified the FTP software supplied by BBN to recognize a distinctive pathname (that the Journal provides with the delivered citation) that, when used to retrieve Journal documents, invokes a conversion of the tree-structured document to sequential form before transmission through the Network. A Network user can thus retrieve the full text of any Journal document sent to him. Network Submission The fact that the Network user had to explicitly connect to and login at arc's PDP-10 to enter a document into the Journal, and that he had to compose the document using NLS, complicated life for some users, forcing them to learn the details of NLS, in which some had only one, specialized interest. To alleviate this problem, we implemented a facility that permits users to journalize documents composed via their local editor without explicitly connecting to the ARC system or logging in, and without any knowledge of the NLS command language. We did this by further modifying BBN's FTP software to recognize a special mailbox name of the form "authors/addressees" and to interpret it, in the context of a mail delivery, as a Journal submission. The ident lists of "authors" and "addressees" are verified by NLS, running beneath the FTP program in an inferior fork. If the ident lists are found correct, the "mail" is immediately journalized. Thus the remote user can journalize a document using the normal, Network mail facility provided by his system. EXPERIENCE AND PROBLEMS The Journal's Network submission and delivery facilities have been in operation since mid-1973. The latter has suffered from a few, relatively minor problems. Network addresses, for example, are not well understood by some users who, in attempting to modify them themselves, have frequently modified them incorrectly. In such cases, delivery of the user's mail is prevented until the error is discovered and corrected by ARC personnel. Because of this, almost all identification changes are now done by ARC staff. Many users are unwilling to explicitly retrieve the text of long documents for which they are sent only a citation, even though the retrieval process is straightforward, even automatable. The submission facility suffers from more severe problems, one of which is that the ident verification and journalization processes are very time-consuming and must be completed before the user's request is acknowledged and he is "set free". A more satisfactory strategy would be to queue the request and acknowledge it immediately, releasing the user for other work, and then to perform the expensive processes in background mode, with a Network message sent to the author in case of failure. A second problem is that the conversion that the Journal must make between the sequential text file presented by the user and the tree-structured NLS file required by the Journal is often unsatisfactory to the user. We believe this to be a very difficult problem to solve, one perhaps best handled by permitting the inclusion of sequential files in the Journal data base, thereby eliminating the need for conversion. A final problem is the inadequacy of the mail subset of the FTP, which makes it difficult or impossible for the user to transmit any of the optional parameters supported by the Journal, and which forces the user interface to remain somewhat artificial. ARC has proposed a separate mail protocol [3], but no protocol development is being carried out in that area at present. EXTENSION TO A DUAL-SITE SYSTEM THE sri-arc/UTILITY ENVIRONMENT In January of 1974, ARC began operation of a second, "utility" PDP-10 system we call OFFICE-1 to provide NLS support in a stable environment to what has proved to be an ever-growing clientele. The facility is operated for ARC by Tymshare, Inc. from Cupertino, California. Like arc's own PDP-10, OFFICE-1 is connected to the ARPANET, through which most of its users gain access to it. The Utility's software configuration is essentially identical to arc's, providing the full range of NLS service to its users. One such service is, of course, the DSS. In providing Journal service from the Utility, we decided to include that second system within the domain of what is conceptually a single Journal spanning both the ARC and Utility machines. That is, rather than simply replicate the software, thereby creating a second, independent system, we decided to couple the two DSS systems, making all items journalized from either system available at both and addressable to users resident on either machine. Thus, for example, we employ a single Ident File, but maintain it in duplicate. STRUCTURAL CHANGES In implementing a dual-host Journal, we were somewhat pressed for time and therefore decided to design and implement an interim system and later replace it with a more efficient and carefully thought-out implementation. The interim dual-host Journal we decided upon involves duplicate Journal, Identification, and Number Systems, cognizant of each other at only a few points in the code. The two systems communicate with one another through the ARPANET via FTP. We implemented a special, assembly-language module to perform the FTP operations on NLS's behalf, since the corresponding FTP software provided by BBN is neither designed to be called by another program (since it's implemented as an interactive subsystem) nor structured in such a way that the relevant subroutines can be easily extracted. The portion of BBN's FTP software that was retained has been modified to deal more satisfactorily with NLS files, which have blank spots in their address space. Two Journal Systems Each submission request, regardless of its source, is fully processed by the Journal System on each machine. Each system's Journal catalog and document files, though in a sense maintained independently, are always identical (neglecting the obvious time lag). To avoid duplicate delivery of each Journal item, as would naturally occur as a consequence of duplicating the submission request, we partitioned the idents, assigning responsibility for delivering mail to any particular user to (in most cases) just one of the two systems--the one on which the user does most of his work. Submission requests are duplicated in the following manner: The background process on each system, before processing recent submissions, moves any files in the other host's special communication directory (OUTJOURNAL) to a local submission queue directory (TEJOURNAL), thus adding them to the list of local submissions to be processed. Then, in processing that list, a copy of each submission request, except those obtained from the second host, is queued for the other system in the local communication directory (OUTJOURNAL again). Two Identification Systems To simplify the task of uniting the two Identification Systems, we bypassed the problem entirely by permitting additions and modifications from only one machine. The other machine is periodically sent an updated copy of the entire data base. Two Number Systems The two Number Systems function independently, each assigning catalog numbers from a separate block. Numbers preassigned on one machine must be used on that machine, and the RFC Number system is available on only one machine. EXPERIENCE AND PROBLEMS Aside from the obvious inefficiency of duplicating each submission on the remote machine even though the item may be of only local interest, there have been no serious problems with our interim implementation. An occasional asynchrony problem arises as a result of the time delay between an addition or modification to the ident file and receipt of the modified version of the data base at the second machine. For instance, an ident could be added to the Identification System, a Journal item sent to him from that machine (which already knows of his existence), and the item could reach the remote system via FTP before that system becomes aware of his addition to the system, causing an error in the remote system's Journal delivery function. The most common problem with the dual-host system is Network transmission errors during file transfers. Such failures cause the item being transmitted to be delayed until an operator finds the file in an unusual state on the source machine. He must then check the destination system to verify that the file has not in fact arrived, which is the usual case, and then requeue it for transmission. Since occasional Network failures are inevitable, we are attempting to enhance the performance of the dual-host system by automating the detection and requeuing process. The redundancy of information within the dual-host system is occasionally useful for reconstructing data lost due to a malfunction of the file system. A backup of the file system recently experienced by the Utility cost no more than reconstruction time; no Journal files were lost. PRIVATE DIALOG COMING TO GRIPS WITH THE PROBLEM From the outset, one of the design goals for the Journal has been to provide an atmosphere in which memos, formal design documents, proposals, and other items, once published, would thereafter be readily accessible to anyone who cared to consult them. Author and subject indices are periodically produced and anyone, whether an active participant in the dialog or not, can therefore browse through the list of items authored by a particlar individual or written on a particular subject, skimming or reading in full any items that look useful or appealing to him. This model of dialog was appropriate for the system's initial user community, ARC itself, where subgroups working on highly interrelated tasks must keep abreast of one another's activity. As the Journal's user community grew to encompass researchers throughout the ARPANET, the model remained for the most part appropriate. Again the participants were engaged in separate but interrelated subtasks of a single, large project (i.e., ARPANET protocol design and implementation), and each working group had legitimate (and often vital) interest in the work of the others. But with the extension of the Journal to a dual-host system, a new class of users became involved. Many Utility users, though anxious to use the Journal as a dialog support aid, were not at all anxious to have all of their dialog (including, perhaps, personal correspondence, new product information, and so forth) accessible to the general public. Thus ARC was compelled to address itself to the problems of nonpublic, or private dialog, and to provide support for it through the Journal. CHANGES TO THE JOURNAL What follows is a brief discussion of the more fundamental implementation problems that we encountered in tackling this problem; the reader is referred to [4] for a more detailed statement of the Journal changes made. Three tests must be applied in establishing a user's right to view a recorded document: 1) Who is requesting access to the document? 2) Has he explicitly been granted access to the document? 3) Is he a member of any group (perhaps by way of one of more levels of indirection) that has been granted access to the document? Who is the Requestor? The Journal has always tolerated imposters, simply accepting the user's word for the ident he declares at login to be his. It has done so because it could afford to, and because it was difficult to do otherwise. Access to a user's personal files is controlled by the monitor, and all system files (i.e, Journal documents) were accessible to everyone. The only thing that hinged on the ident claimed by the user was the authorship of items he journalized during the session. Since the Journal designates users by ident, rather than by directory name, and since elements of the two name spaces cannot, in general, be placed in one-to-one correspondence (several users, each with an ident, often sharing a single directory), the monitor's login identity check was of little use as it stood. Rather than significantly perturb the TENEX login procedure, we adopted the following strategy: 1) For those users who have personal directories, we constructed a system data base giving ident as a function of directory. TENEX was modified to infer the user's ident from his stated directory name (which, of course, had to be accompanied by the appropriate password) at login, using the data base, and to store it in a read-only, job-global cell for subsequent interrogation by NLS. 2) For those users who share a directory, we placed opposite the directory name in the data base the idents of the users who use the directory. When TENEX encounters such a user at login, it interrogates him for his ident, accepting only one that appears in the list. Thus, those users who are assigned a personal directory, and who login only under that directory, are completely protected by the System (i.e., they cannot be impersonated), while those who work in a community directory, are less fully protected, since they can be impersonated by any other member of the directory community. We are encouraging user organizations to set up separate directories for each user. Has the Requestor been Granted Access to the Document? We have defined two classes of Journal items: private and public. Whenever a document is entered into the Journal, its author can select the class most appropriate, with public being the default. Private documents are defined to be readable only by the clerk, an author, or a distributee. That list of idents, including in general those both of individuals and groups, is stored as text in the first statement of the file that ultimately holds the document in read-only storage. Whenever a user attempts to load the file, the list is consulted, and if the requestor's ident appears in it, his request for the document is honored. Has He been Granted Access by Implication? Since authors and distributees may be groups of people (or other groups), as well as individuals, the access list for a private document in general contains group, as well as individual idents. A user who requests access to a private document may therefore have legitimate access to it by virtue of his membership in a group, without his individual ident appearing explicitly in the access list. Because group idents are used heavily is this way, we were compelled to provide efficient means for verifying an ident's implicit appearance in an access list. To this end, the Identification System was modified to maintain back links, as well as forward links between each group ident and the idents of its members. That is, not only is a membership list maintained for each group ident, but in addition, now a group list is maintained for each individual or group ident, specifying the list of groups in which the ident is a member. The logged-in user's group list is loaded by NLS once per session, and by a simple search of that list, most instances of legitimate access attempts to private documents can be identified. For those cases in which the user's claim to a document is more complicated (e.g., requestor A is a member of group B that is a member of group C, that appears in the access list), the Identification System is consulted and its data base examined more thoroughly. EXPERIENCE AND PROBLEMS The private dialog feature of the Journal has been in advertised use for only a few months, and hence any in-depth attempt to evaluate its performance or use would be premature. The areas in which effects are most likely to be expected are those involving intimate collaboration between users. It's long been common practice, for example, for cooperating users to impersonate one another to get at a file that, though necessarily residing in one particular directory, is in reality a joint file. In implementing private dialog, we've necessarily restricted such practices, and the result will probably be the design and implementation of more formal methods for accomplishing such shared tasks. OUR THINKING ABOUT A GENERAL, MULTISITE SYSTEM MOTIVATION Recognizing the immediate need to provide dialog support for Utility users, and recognizing also that the implementation of an efficient dual-host dialog support system would require significantly more than simple modification of the existing, single-host system, we elected to make the short-term modifications described earlier and then to begin design work on a general, multihost system to be distributed on an arbitrary number of ARPANET host systems. The implementation of such a system would involve a complete rewriting of the present Journal, Number, and Identification Systems. Furthermore, we expect that the new DSS will in many ways be a different system, one in which many of the basic concepts of the previous system find a place, but also one in which new concepts appear. DESIGN GOALS In designing a MultiHost Journal System (MHJS), we had a number of goals in mind, the first necessarily being modularity: Modularity: We envision a system composed of modules, each providing some specialized service to the others, or to the end user, and which together comprise a coherent system. Each module implements a set of primitives whose syntax and basic function are to be standardized, but whose internal workings would be left unspecified by the design (within certain broad constraints), being dependent upon the implementation machine, and the particular role that the module is to play within the System as a whole. Reconfigurability: The MHJS must be reconfigurable. Although the design suggests in broad terms the manner in which the System is to be constructed from its component modules, the design does no more than specify a family of MHJSs from which a particular configuration can be selected [in the same way that a computer system manufacturer provides a set of hardware modules (disk drives, CPUs, etc.) from which the customer configures his particular system]. The design specifies a small set of module types, each of which is replicated in appropriate numbers for a particular system configuration. The MHJS must be reconfigured, for example, to accommodate the addition of new hosts to the system, or it might be reconfigured to place an instance of a frequently used module closer to a population center, or for any of a variety of other reasons. Optimum Data Base Distribution: It is, of course, more expensive to manipulate remote data bases than local ones; sometimes it is impossible (e.g., when the remote host is down). The MHJS, therefore, must attempt to reduce the frequency with which remote data bases must be dealt with by replicating portions of them in centers of user population and message traffic. Uniform and Consistently-Applied Access Controls: The MHJS must recognize the existence of private information of every type (documents, catalogs, idents, etc.) and provide the access controls necessary to protect it, providing for private dialog of a much more flexible nature than that described in the preceeding section. With these goals in mind, then, we began designing a MultiHost Journal System. Some of the more important concepts we came up with are described below; the reader is referred to [5] for a more complete discussion. SOME IMPORTANT CONCEPTS Isolating the Recording, Cataloging, and Distribution Functions The original Journal implemented a single user primitive we called "Submit" which records, catalogs, and distributes a document. We considered that primitive fundamental to dialog support, and the vision of it colored our thinking about the Journal's internal structure. We've since learned that the subprimitives from which Submit is constructed are also of interest to the user. For example, we've found it useful to be able to distribute a previously submitted document to additional users, an operation that we've implemented and call "secondary distribution" (even the name reflects our bias toward "Submit"). We now recognize, further, the need to be able to distribute a document without recording it at all, a facility that the present Journal still does not offer. And we recognize the cataloging subfunction of "Submit" to be a more generally useful tool, applicable, for example, to personal as well as system data bases. Access Controls We decided from the outset of the design to implement flexible access controls throughout the MHJS, applying them not only to documents, but to data elements of all types--catalogs, idents, and so forth. Controlling access to a data element consists of specifying, when the data element is created, the list of individual or group idents granted access to it, and then limiting access to members of that list. This is the same kind of access control now implemented in the present Journal, as we've already described, and is by far the most satisfactory type we know. In the MHJS, we've taken the additional (and natural) step of assigning passwords to idents, and requiring their use, as a means of verifying the user's identity. Catalog Number Assignment The present Journal assigns every recorded document a unique identifier, called a catalog number, by which the document can be referenced or retrieved. Since the MHJS is conceptually a single Journal, we must somehow maintain uniqueness in catalog number assignment, while yet hopefully making the assignment process reasonably efficient and reasonably insensitive to host failures. These requirements preclude the simplest implementation, i.e., assignment of numbers by a single module at a single host. The approach we think most satisfactory is to station several instances of a module we've called the Number Vendor at strategic points about the system. Each additional Number Vendor, assuming it resides on a different host, increases the probability of a user's being able to obtain a catalog number when he wants it, as well as reducing the overhead (by placing the source closer to him). At any time, each Number Vendor owns a subset of the universe of catalog numbers from which it can satisfy user requests. A Number Vendor may assign only catalog numbers that it itself has been assigned by another Number Vendor, except for one special root Number Vendor assigned initial possession of the entire name space. Number Vendors might be stationed throughout the MHJS, each with responsibility for servicing a segment of the user population, and each replenishing its number supply, when it nears bottom, from the Root Vendor. This strategy permits a form of number assignment that is both efficient and insensitive to the host failures that periodically make the Root Number Vendor inaccessible. Publishing a Document In our design of a MHJS, we've made central a concept that is given only lip service in the present Journal, that of subcollections. A subcollection is a subset of all recorded documents, each of whose members shares some common attribute, e.g., author, subject, and so forth. A single document may be assigned to zero or more subcollections, either explicitly by the author, or by the system. Although hard copy subcollection catalogs can be generated, the Journal maintains no online subcollection catalogs, thus severely limiting the utility of the concept in its present implementation. A major concern of the MHJS is to provide specialized marketplaces in which documents can be exchanged. Such a marketplace is called a "forum", and one speaks of "publishing" a document in a forum. In the MHJS we've thus placed great stress on the concept of allying a recorded document with other documents related to it (i.e., placing it in a subcollection), relegating the concept of simply recording a document to a less central role. Users with interest in a particular forum can formally declare that interest, and, subject to appropriate access controls and accounting disciplines, become "subscribers" of it, thereafter automatically receiving an announcement of each new document published. The prime responsibility of the Publisher, the module that implements a forum, is therefore to catalog each document as it is contributed, and send a copy of the catalog entry (giving the document's author, title, date of publication, etc.) to each of its subscribers. We've thus given the old concept of subcollections an active, rather than passive character, with the system notifying interested users as new documents are made available. Maintaining Networks of Documents For reasons of efficiency and reliability, it is necessary to permit an arbitrary number of physical copies of a document to exist simultaneously within the MHJS. Each additional copy, assuming it is created on a different host, increases the probability of a user's being able to retrieve the document when he wants it. A retrieval request can be satisfied most quickly, of course, if a copy of the requested document already exists on the user's own host. The system might therefore create a copy of the document at each major population center, anticipating a rash of retrieval requests; and then delete the copies a month later, once the period of peak demand has passed. Access to a document and all its copies is uniformly controlled on the basis of access lists assigned by the author. A user, for example, cannot read a document unless the author granted him read access to it. The copying of documents, however, is a system function designed to promote efficiency and is therefore unhindered by access controls. Each recorded document within the MHJS is therefore implemented as a network of copies whose topology is a dynamic characteristic of the system and changes with such things as the frequency with which it is referenced. The system keeps track of the various copies of a document, and can thus direct the curious user to the nearest one. Distributing Information About Users and Modules A need that pervades the MHJS, even more so than in the present Journal, is that of swift access to information about users of the system. In the present system the data base is called the Ident File and describes the users and user groups known to the system. To implement the access controls that the MHJS seeks to maintain throughout, both human users and system modules are assigned idents. Group idents are very heavily used, being extremely convenient for implementing access lists for the various data bases within the system. For reasons of efficiency and reliability, it is highly desirable to maintain copies of subsets of the Ident File at various locations within the system, each under the control of a module called a Registrar. An ident can be known to an arbitrary number of Registrars, and that particular set of Registrars is called the ident's "domain". Information about the ident can be obtained from any Registrar in its domain. Modifications to an ident are relayed by the Registrar that receives the modification request to all Registrars affected. The Registrar turns out to be the workhorse of the MHJS, and its importance cannot be underestimated. In designing the MHJS we discovered that: 1) Virtually every system module must deal with incidental data bases that are lists of user/program names (e.g., access lists), and each must provide mechanisms for retrieving and modifying them. 2) System modules can be relieved of a significant burden by providing a specialized module (the Registrar) whose function is to provide the primitives required to manipulate these data bases. 3) Furthermore, the lists then become accessible from any one of an arbitrarily large set of Registrars (the group ident's domain), since the Registrar already implements the required broadcast facility. 4) Since the existence of a document's read access list (for example) implies the existence of the document itself, whether or not a document exists can be determined by consulting the nearest Registrar. 5) Race conditions associated with the creation of a document (e.g., two users attempting to create a document with the same catalog number simultaneously at two different points in the system), for example, can be arbitrated by the use of locking mechanisms implemented by the Registrars. CONCLUSION Having made heavy and continuous use of the Journal for over three years now, ARC has found it to be a powerful dialog support tool for knowledge workers. During the course of its use, the Journal has been substantially modified to increase its efficiency, extend its geographical reach, and provide the new features we've discovered to be important. Initially an experimental system supporting a fairly small number of geographically concentrated researchers, it now supports a large, geographically distributed user community linked by the ARPANET. Initially a software system implemented on a single computer, it now operates on a pair of PDP-10 systems linked by the Network, and design work has been done for a general, multihost system. Initially exclusively a forum for public dialog, it now supports private communication as well. The Journal will further evolve and new features will be implemented and experimented with as we continue to gain experience in the dialog support field. ACKNOWLEDGEMENTS Many past and present members of the Augmentation Research Center have contributed to the design, implementation, and evolution of arc's Dialog Support System. The contributions of the following individuals warrant special acknowledgement: William S. Duvall, Douglas Engelbart, David Evans, J. David Hopper, Charles Irby, and Jeanne North. .PBS; References .IOvr=11; .PlexNum=21; (13B1A) sri-arc. Online Team Environment / Network Information Center and Computer Augmented Team Interaction. Augmentation Research Center, Stanford Research Institute, Menlo Park, California 94025. 6-MAR-73. (13041,) (13C2B1) Nancy Neigus. File Transfer Protocol. BBN. Boston, Massachusetts. 12-JUL-73. (17759,) (13C3D) James E. White. NWG/RFC 524 #1 A Proposed Mail Protocol. Augmentation Research Center, Stanford Research Institute, Menlo Park, California 94025. 31-MAY-73. (17140,) (13E2A) James E. White. A Description of the New NLS Privacy Features. Augmentation Research Center, Stanford Research Institute, Menlo Park, California 94025. 7-MAY-74. (22911,) (13F2B) James E. White. Description of a Multi-Host Journal System. Augmentation Research Center, Stanford Research Institute, Menlo Park, California 94025. MHJSPAPER.NLS;33,. (23144,) [6] D. C. Engelbart, R. W. Watson, J. C. Norton, The Augmented Knowledge Workshop, paper presented at the National Computer Conference, New York City, June 1973. .Text[R]="User Programs"; .Iovr=0; .Igs; ------- 10-MAY-78 22:10:44-PDT,1248;000000000001 Mail from USC-ISIC rcvd at 15-AUG-75 0506-PDT Date: 14 AUG 1975 1659-PDT Sender: WATSON at BBN-TENEXB Subject: MSGGROUP# 129 Beware the following long message From: WATSON at BBN-TENEXB To: Burchfiel at BBN, Gilbert at BBN, NGoodwin at BBN, Myer at BBN, To: Mooers at BBNA, To: WATSON, To: Tom at CCA, To: Pirtle at I4-TENEX, To: MsgGroup at ISI, PBaran at ISI, DCrocker at ISI, Ellis at ISI, Farber at ISI, Iseli at ISI, To: Kirstein at ISI, Mclindon at ISI, Mealy at ISI, Spivey at ISI, Stefferud at ISI, To: Tasker at ISI, Walker at ISI, To: Pickens at ISIB, Stotz at ISIB, Vittal at ISIB, To: Vezza at MIT-DMS, To: Engelbart at OFFICE-1, Panko at OFFICE-1, Robertazzi at OFFICE-1, Uhlig at OFFICE-1, To: Kohanski at RUTGERS-10, Ryland at RUTGERS-10, To: Geoff at SRI-AI, To: ------- at SRI-AI Message-ID: <[BBN-TENEXB]14-AUG-75 16:59:37-PDT.WATSON> The message to follow this one is a chapter from a report which while about a year old contains grist that should be of use to the message group . The chapter summarizes experience with the NLS Journal and has been passed out to some of you before but there are enough new peop;e in the dialog that it seems worthwhile to pass it on to them. Dick ------- 10-MAY-78 22:10:44-PDT,12206;000000000001 Mail from BBN-TENEXA rcvd at 15-AUG-75 0939-PDT Date: 15 AUG 1975 1144-EDT Sender: HENDERSON at BBN-TENEXA Subject: MSGGROUP# 130 Distribution of previous message re: New Protocol. From: HENDERSON at BBN-TENEXA To: [ISI]Mailing.List: Message-ID: <[BBN-TENEXA]15-AUG-75 11:44:47-EDT.HENDERSON> The enclosed was sent to Tom Ellis for distribution to the members of the Message Service Committee. Don Oestreicher has informed me that Tom is currently on holidays. Therefore I am distributing it directly to you. Austin Henderson -------------------- Date: 11 AUG 1975 1312-EDT Sender: HENDERSON at BBN-TENEXA Subject: Message Transfer Protocol. From: HENDERSON at BBN-TENEXA To: Ellis at ISIB, Gilbert at BBN, Walker at BBN Cc: Oestreicher at ISIB, JFH at MIT-DMS, COTCO-PROJECT: Message-ID: <[BBN-TENEXA]11-AUG-75 13:12:03-EDT.HENDERSON> This note expresses BBN's current position on the proposed new Message Transmission Protocol (MTP) (Haverty, July 8, 1975). In addition, it presents the outline (although not the details) of an alternative proposal. 0. Briefly, our objections to the proposed MTP protocol are as follows: 1. It does not respond to the mandate of the Message Service Committee (MSC) in that it does not support the transmission of arbitrary structured objects. 2. It addresses a collection of problems not fundamental to the future development of message-based communication in the network. In doing so, MTP overlooks a simple solution to the problem of encoding structured objects, adopting the overly-complex view that messages are changing objects which may appear differently to different receivers of them. 3. It leaves untouched the critical issue of extending the currently-primitive notion of message transmission services to include process-to-process service in addition to the user-to-user service. Our alternative response to the MSC's mandate is indicated. 1. The mandate of the MTP SubCommittee of the MSC, as BBN understands it, was to propose a new protocol for sending structured messages in the network. We interpret this mandate to imply a request for two things: (1) a definition of, and an encoding for, "structured messages", and (2) a definition of, and protocol for, sending messages (of all kinds) in the network. Also implied in the mandate is a request for a specification for representing RFC680 messages as "structured messages". 2. The document produced by the MTP SubCommittee is a response to this mandate. It defines a structured message as a two-dimensional matrix: on one dimension is a list of field names (e.g., ACTION, ADDRESSES, IN THE NAME OF, REVIEWERS), and on the other a list of persons (users) concerned with this message (presumably including the sender(s) and addressee(s)). The information contained in the matrix (its entries) may be changed by the users associated with those entries; thus, a message is a time-varying object. The encoding proposed for a message is based on the DPS 8-bit format known as PCPB8. The encoding interprets certain PCPB8 lists as typed objects. By explicitly including type, (as opposed to type being implied by position in the encoding) it is possible to provide for alternative encodings and optional information. Page 2 Sending a message, as defined by the report, is potentially an elaborated exchange of signals (MSIGNALS) among servers on a number of hosts in the network. It is possible, for example, for one server to inform another that a message exists. The notified server can, then or later, request that different entries in the message be transmitted to it. Further, when entries are changed, the fact of these changes can be transmitted to other users associated with the message. The protocol implementing this extended exchange is based on MSIGNALS. These signals are PCPB8 encodings of requests for action and responses to these requests. The servers are assumed to communicate MSIGNALS over network connections established in response to ICP's (or something like them) on special reserved sockets. 3. Some specific criticisms of MTP deserve mention: a. MTP does not support the transmission of arbitrary structured objects. Rather, the fields permitted in messages are a fixed set. MTP ought to have defined a general message, and then shown how to map the messages of RFC680 (or an extension) onto that. b. There seems to be no way for a server to decide when it can get rid of its messages. c. A server has to retain all its requests until a response comes back. This may require considerable overhead. d. The typing scheme used in the encoding of MSIGNALS is used inconsistently. Ideally, types should be included explicitly where position does not make clear what to expect; they should not be used otherwise. This rule is not followed. For example, the prototypical FLDVAL (page 17) only appears in forms where it is expected, so typing is unnecessary to say that it is a FLDVAL; however, should be an optional part of a FLDVAL, yet no typing is put on it, thus forcing it to be present always. e. MTP permits a receiving server to ask for message fields only when it needs them. A user requesting to see a field has such a need. However, a receiving server cannot afford in reality to take the risk that the network or sending host may not be available when the user makes his request. Consequently, a receiving host will always want the whole message. Thus, MTP is too general, permitting transmission of partial messages. f. MTP views messages as changing objects. This requires that, in order to propagate changes in messages, the servers must understand the structure of those messages. This means that it is impossible to divorce what is transmitted from the Page 3 mechanisms which transmit it. This leads to complexity. g. Another source of complexity in MTP is the inordinate number of options available throughout. Also, the use of alternative encodings for many objects adds to this problem. h. The complexity of MTP implies servers of not insignificant size. A small host on the network may well have trouble furnishing adequate resources to support such a server. 4. We feel that MTP is unnecessarily complicated for use as a primitive message transmission service. In particular, MTP appears to be an attempt to implement high-level abstractions using an underlying facility for sending MSIGNALS between servers. It is this more primitive capability which we think should be embodied in a network-wide message transmission system (MTS). Then, using such a service to send MSIGNALS, servers could be built to implement MTP. 5. An alternative and simpler response to the MSC's mandate is as follows: a. Regard messages as unchanging objects. Then the servers which transmit messages will not need to understand their structure. This permits separating the structure of messages from the transmission of messages. b. To support the creation of server processes which communicate quickly by sending messages to one another (as exemplified by the MTP protocol), build a high-speed message transmission system (MTS) whose function it is to transmit messages which it views simply as collections of bits. c. Adopt PCPB8 as an encoding for structured objects when structured objects are to be transmitted. This defines structured objects as those objects which can be encoded in PCPB8. 6. A message transmission service (MTS) is responsible for delivering a message (any bit string) to a collection of receivers. To give this meaning, we must say who receivers are. "User at host" is an inconvenient way to name processes. Also it ties a user or a process to a particular host. We, therefore, feel that this is a good time to broaden our view of message transmission by changing the notion of "address". A new message transmission service (MTS) should be provided in the network by having co-operating servers at each host. These servers, in addition to managing network connections over which messages are transmitted, maintain a network-wide collection of addresses. A process could request an address which it could supply to other processes to have them send messages to it. By making addresses be 72 (or 144) bits long, there should be no need to re-use addresses for any reasonable duration of the MTP Page 4 system (say 100 years). A number of extensions of this MTP service are imaginable. Associated with certain addresses could be character strings (names of people, subsystems, services). The MTP service could be queried to obtain addresses whose associated strings meet certain criteria. Also associated with an address could be a program to be run when a message arrives for that address. There need be no requirement that addresses be host-dependent; that is, the service could be extended to be able to move an address to another host. Conceivably, addresses which had moved might receive their messages a bit slower, due to forwarding. The service can be designed to answer a reasonable set of queries concerning addresses (location, strings, programs), speed of service (host temporarily down), cost of service, and the like. Since the MTS serves both high- and low-speed communication, there is a need for some method of guaranteeing that high-speed messages not be held up by slow-speed ones. That is, the MTS should understand message priority. ________ What is needed then, is a protocol which MTS servers are to use in implementing MTS. We are drafting such a proposal now. 7. In conclusion, BBN feels that: a. messages should be conceived of as unchanging objects: b. a Message Transmission Service (MTS) should be constructed based on an extended notion of address, with the intent that it serve both user-to-user, and process-to-process message transmission. c. an encoding for structured objects is available in the DPS format called PCPB8. d. the conceptual and implementation complexity of MTP is too great to be acceptable as the primitive network message transmission protocol. Rather, it should be regarded as a higher level service which could be implemented using an MTS. e. MTP has some serious limitations for practical message transmission, and, therefore, needs further work before being accepted as a higher-level network standard. ------- -------------------- ------- 10-MAY-78 22:10:45-PDT,1090;000000000001 Mail from USC-ISI rcvd at 15-AUG-75 1812-PDT Date: 15 AUG 1975 1800-PDT From: DCROCKER at USC-ISI Subject: MSGGROUP# 131 Participation in Design Review To: [ISI]Mailing.List: Hello again. I have been on an extended vacation and am finally beginning to catch up on the Group's activity during my absence. For starters, I would like to strongly support the suggestion that the group be informed of design plans (and thank Charlotte Mooers for initating a response to the request). I believe that much of the agony and frustration experienced by users, and directed at designers, can be avoided by gathering meaningful feedback from a group such as this. I would specifically like to suggest that we be informed of progress/thinking along the ENTIRE development path: Selection of general features, selection of specific form of the features, selection of command words which will invoke the functions, etc., so that we can in turn provide some indication, and perhaps increase in, the ultimate user acceptance of new systems and features. ------- 10-MAY-78 22:10:45-PDT,11484;000000000001 Mail from USC-ISIB rcvd at 15-AUG-75 2324-PDT Date: 15 AUG 1975 2308-PDT From: NELC at USC-ISIB Subject: MSGGROUP# 132 More comments on mail service To: [ISI]Mailing.List: Charlotte -- My appologies for taking so long to respond, but we have been undergoing a reorganization and office-moving that has kept us pretty busy. I will remember to sign this one -- sorry I forgot to sign the previous one. First I want to say someting about the philosophy employed in the prior message. I was trying to identify features that I thought were good and practical, not features I thought were missing. In fact, I drew heavily upon some of my background in the use of mail systems -- not only computer mail services, such as the ARPAnet mail protocol, but also the some of the military message communication services. Thus, I listed several features that I knew existed and which I thought worth retaining. The paragraphs below are an attempt to give my reactions to what you had to say in your very thoughtful comments to the previous diatribe. 1. (Your point 1) Good. I'm glad to see that we agree on the desirability of a text editor in conjunction with a mail service. 2. (2) As I discussed above, I realize that the current message service automatically puts in certain header information. My point was that some minimum set of this information should be required. Some mail servers, notably NLS, don't supply some of the more critical fields. (NLS doesn't supply "TO", "FROM", or "CC", nor does it put "SUBJECT:" or "DATE:" in front of the information that it does supply.) 3. Some of the header info is self-explanatory. "TO" means to whom it is sent, "CC" tells who received carbon copies. But what in the world is "BCC"?? 4. (3) I think you misunderstood this one. One problem of mine currently is that I have a whole bunch of very short(one or two line)files that contain the Net mailbox for somebody. It is frequently very convient to do this for people you send a lot of mail to. The problem is then twofold: first, each mailing list requires an entire file all to itself at a corresponding cost in wasted storage and cluttered directory listings; and second, often you want to send mail to all of a mailing list EXCEPT a few. I feel that the concept of mailing lists should be explicitly present in the mail service, and that all management of the mailing lists should be its responsibility. A mechanism similar to the "funny name" file managed by the TENEX ARCHIVER could be used, for example. 5. (more 3) Another feature that would be useful for a mailing list facility would be to permit the items of a mailing list to make references to other mailing lists, including the ability to exclude items of the other mailing list. The possibility of infinite recursion is present, of course, but this could be identified and some suitable action taken. 6. It would be nice if duplicate names were spotted and merged so that only one copy was actually delivered. XED does this; it is very handy when sending mail to multiple mailing lists. 7. (3 & 4) What is a "Cache-Citation"? How does it cause the return-reciept function to be performed? 8. (5) I know. MSG does it with Forward. 9. (6) I know. MSG does it with Answer. These were "good features that should be retained." 10. (7) This issue was one of validation. Most mail recievers already do it and should continue to do so. 11. (8 & 9) This is a very tangled skein that I will attempt to unravel. I tried to state what I wanted in a very abstract way without specifying any implementation methodologies. This time I will describe more of the specific model I had in mind. The backbone of the process is the journal file. Every incoming message is logged in this file with enough information for display, search, and retrieval. The full actual text of the message goes into another file. The current ATTN parameter is a partial answer to how the in-basket could be specified. In this interpretation, the journal file acts as an index to the messages, identifying the location where the message actually is. This pointer could be as simple as a file name/offset or as complex as the "archive handle" of the message in the Datacomputer. 12. (con't) Another interpretation is that the system supports a set of "file folders" that copies of incoming messages can be placed in. (These file folders could be implemented as a set of keywords that are retained with the message.) In this view the in-baskets are just distinguished file folders into which incoming messages may be directed. A message not directed to any specific in-basket, or to an illegal in-basket, would be placed in some default in-basket. Mail that has been routed to the default in-basket could be re-routed to the appropriate in-basket(see later about specifying additional folders). 13. (con't) A message coming from the outside may only be routed to an in-basket, while internal messages(messages to myself) could be routed to a folder, thus giving a "Memo to file" capability. A copy of outgoing messages would be routed to a special file folder, so that a file of messages authored would automatically be kept. 14. (con't) As the user examines his mail, he can specify additional folders(keywords) in which copies must be put. Mail put in an in-basket would be equivalent to routing it on to another member of the group. Note that actually putting full copies into each folder would be a great waste of file space; it is probable that a mechanism like that of NLS, where only one copy is retained and an index is used to locate the contents. 15. (con't) This seems to imply that the implementation would consist of a journal/index file and a set(see comments about your point 10) of associated files containing the the full text of the message. The journal/index file would contain only enough so that the display, search, and retrieval functions could operate; this would basically be the information in the header, the folder names(keywords), the pointer to the full text, and an "examined" flag(see below). 16. (con't) An additional problem that would have to be addressed would be how to correctly tell each individual user of the directory when mail was waiting for them. To solve this, the "not examined" concept of MSG should be supported(a good idea all by itself) and as long as "not examined" mail exists in an in-basket, the logon/logoff handler would comment about it. 17. (con't) Although much of this mechanism was envisioned to ease the problems encountered when multiple users are sharing the same mailbox, the file-folder management that is a natural fallout would be very useful even if you are the only user of the mailbox. In fact, looking back at the model, it is hard to tell which one is the fallout of the other. The mechanism is intuitively appealing since it follows very closely the way mail delivery actually works in many places. I recieve my mail in a common mailbox with the three other people with whom I share an office; whenever any one of us goes by the mailbox, we grab all the mail and put it on the desk of the correct person. 18. (10) The archival problem is basically one of splitting the messages into units that can be archived individually. In the two-level scheme above, this can be done by placing the data into a sequence of files. Messages would be appended to one file until it exceeded some reasonable size(about 20 pages would be reasonable for us) and let the standard archival mechanism remove the files in the usual way. The journal file could use the same system for putting in physical breaks, but it would mark those files containing the information for the last (say) 100 journal entries as not archivable. Searches would be limited to only that last 100 entries unless extended by the user. It would be probably be reasonable to permit the size limit of the text files, the size limit of the journal files, and the number of active journal entries to be setable by the user. In the event that the user wants to see a message that has been archived, the mail system would notify the user. If he still wanted to see it, the mail system would construct the necessary retrieval request and post it. The user should be able to "lock" a particular message, that is, specify that the message is not to be archived. Also an "unlock" function. This was a long set of comments in this paragraph; also somewhat confused. I hope that all of my thoughts can be deciphered. 19. (con't) Keeping the messages in the Datacomputer is good idea. I presume that you've worried about it, but what provisions have been made to ensure that people don't go around reading the mail? Some of my spook friends in Security would be a little hesitant about the information I already keep on the ARPAnet -- not classified, of course, but the equivalent of commercial proprietary -- plans and cost estimates. (Actually, I pity anybody who tries to use it -- it goes to my sponsor after me and doesn't come out the same afterwards.) 20. What is the relationship of MSG to MAILSYS? Many of the commands are so similar that I suspect that it is either a precursor or an offshoot. 21. Another feature that we seem to need around here is the ability to reformat the messages and the index (header) data and print it on the line printer (COM, etc.) and put it in our own archives. This seems to me to be the security blanket approach, but it may be required for political (sales?) reasons. 22. A feature that would be neat, but I don't know how it could be done, would be to permit files to be "attached" to the message. We operate in the mode where we prepare documents and send them to other people on the net. The thing to be avoided in this case is having a long file that will only be edited and sent back and forth many, many times. It wastes message file space to hold ten or twenty copies of the same document, only slightly different in each version. What would be better would be the ability to send a "file handle" that would be good for only one time and permit the guy at the other end to pull the file and examine it. If he wanted to send it back, you would have the option of putting it in the same file again, thus conserving storage, or putting it in a new file. In addition, the document in the file would be clean -- it wouldn't have any message headers or other stuff that would be irrelevent to its basic function as a document. 23. One last thing. A bell that would be useful to me, since I would forget my head if it weren't firmly attached, is a "tickler file." I'm not even sure that the mail system is the place to put it. All it needs to be is a spot where I can request that a message be sent back to me at a certain time. I hope these comments are useful to you. Although I can't afford to do very much(it's on my own time), I would like to be kept informed as to what you're doing. I think Charlotte is such a pretty name. Greg Noel -- NELC@ISIB(Attn: Greg) ------- 10-MAY-78 22:10:45-PDT,468;000000000001 Date: 17 AUG 1975 1340-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 133 A 5 page desciption of the Calendar Sndmsg Experiment From: FARBER at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]17-AUG-75 13:40:08-PDT.FARBER> A short 5 page memo on the experiment is in a message in message.txt of msggroup with the keywords calendar , sndmsg , experiment. Requests for direct copies should be sent to Farber@isi. Dave and John ------- 10-MAY-78 22:10:45-PDT,8699;000000000001 Date: 17 AUG 1975 1616-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 134 A 5 page description of the UCI Calendar-SNDMSG Experiment From: FARBER at USC-ISI To: MSGGROUP Message-ID: <[USC-ISI]17-AUG-75 16:16:32-PDT.FARBER> Keywords: calendar , sndmsg , experiment Experimental CALENDAR/CLOCK/MESSAGE system An experimental system exists which merges the services of CALENDAR, CLOCK, FILWATCH, and SNDMSG in order to give the user a more dynamic calendar/alarm-clock mechanism. (Of the above, CLOCK and FILWATCH may not be known. Briefly, CLOCK is a subsystem which accepts a file of times and notices. When a noted time arrives the indicated message is printed on the user's terminal, no matter what he is doing. FILWATCH is a subsystem which continuously (sort of) monitors the status of designated files. It is used primarily to detect any change of status within the MESSAGE.TXT file) A brief overview of how the whole thing works is as follows: The user, or his secretary, uses the CALENDAR subsystem to create appointments and/or daily entries for tasks to be done. A special format is required, which does not restrict normal calendar entries, for those entries which will cause notices to appear at specific times of the day. (See below) If desired, a special file may also be maintained with more permanent notices. (This file must be maintained in the format required by the CLOCK program) Examples of such notices are ... lunch time at 12:00, rent due on the 1st of every month, and quitting time at 5:00. At the first logon of the day, or whenever new calendar entries are added, the user runs a program which initializes his notices file and sends him a message with the day's calendar. After this program is complete, and at each successive login he runs another program which starts both CLOCK and FILWATCH. From this point on he may proceed as normal - editing, running subsystems, reading mail, or whatever. How to Use this System The special formatting rules for CALENDAR entries and appointments are very simple to explain. All calendar entries for the current day are split into two groups- those with specific time identifiers and those without specific time identifiers. A time identifier is simply one or more 4 digit fields, separated by commas, and must be the first data in the entry/appointment. (1100 means 11:00 A.M. 2300 means 11:00 P.M.) The time identifiers indicate at which time(s) the notice is to be printed. Entries without time identifiers will be printed every time the monitor program is started up. Multiple line entries are acceptable and will get converted correctly for the CLOCK subsystem. (See the APPENDIX for the format required directly by the CLOCK subsystem) To initialize the current day's message and clock files, the user simply types the sequence "DO STARTUP ".After a significant amount of output (remember, this is experimental) and 2 the creation of a temporary file (MONITOR.SCRATCH) everything will have been initialized. Now to begin monitoring (done at each successive login) the user simply types "DO MONITOR ". 3 APPENDIX CLOCK -- A Reminder System CLOCK is a system which will give you a reminder by typing out a notice on your terminal at various points through the day. Such a notice may appear more than once throughout the logon period. The specification of the times and associated notices is done in the following way. CLOCK starts by asking you for a file where the time/notice sequences are to be found. After acquiring this information, you are left at a lower EXEC. If you want to leave clock or reset the notices, QUIT from that EXEC. The file must consist of a set of either 2 line or 3 line specifications. The two line specification has as the first line a list of the times of day the notice is to appear (if the notice is to appear at more than one time, the times may be seperated by either a space or comma). The second line is the notice. The three line specification has a 'date specifier' as the first line, with the time and notice lines as the second and third. A date specification may precede any group of notices in a file of notices. The specification states on what dates the notices are to be output to the terminal as specified by the respective time specifier for each notice until the next date specification is found. The date specification is a line of text beginning with an asterisk (*), containing date specifiers separated by semi-colons (;) and ending with the usual carriage-return linefeed. The date specification applies to all notices following it until the next specification. A date specifier is any of the following: o the word "DAILY"; o any of the words "MONDAY", "TUESDAY", "WEDNESDAY", "THURSDAY", "FRIDAY", "SATURDAY", "SUNDAY"; o a date specified according to day, month, and year; o a day of the month, that is, an integer in the range of 1 to 31 inclusive; o a pair of dates separated by a colon (:); o a pair of days of the month separated by a colon 4 (:). The word "DAILY" signifies that the following notices are to be sent every day. Similarly, a particular weekday, say "FRIDAY", specifies that every Friday the following notices are to be sent. In just the same way, a date or a 2 day of the month also specify particular days for delivery of the following notices. A pair of dates or days of the month specify a range of days over which to deliver the following notices; the range is from the earlier of the two in the year or month, to the later of the two. The word "DAILY" may be abbreviated to "D"; similarly the weekdays may be abbreviated to one or two characters each, as long as the abbreviation is unambiguous. However, if the abbreviation is ambiguous, the match will be made if today's day is appropriate. Thus, if "S" is used, the following notices will be sent every Saturday and Sunday. Note that a time of 0 implies only at startup or midnight. However, a time of 2400 means only midnight. The date specification is valid only from a disk file. If the file is TTY:, you will be prompted for the time/notice sequences. A time sequence is terminated by two carriage return line-feed pairs. To terminate the acquisition mechanism, a null time sequence should be specified. The following is a sample file time/notice specifications: 0 This notice will appear daily at 0000 and also on program startup. 1200,1300 This notice will appear daily only at noon and 1:00pm. 2400 This notice will appear daily at 0000 but not at program startup. 13 115 This notice will appear daily at 00:13 and 01:15am. *daily 0 These notices will also appear daily. *D 0 5 The date specification can be abbreviated; case shift is ignored. *monday;tuesday 0 Every Monday and Tuesday this will appear on startup. *m;w 0 Monday Wednesday - Only ";" may be used to separate date specifiers *w;f 0 Wednesday and Friday for this one. *t 0 Both Tuesday AND Thursday; similarly, "s" matches Saturday Sunday 3 *1TU;2F;SUN 0 The first Tuesday and second Friday of the month, and every Sunday. *1/2/75 0 This would have come out on Jan 2, 1975 *January 2, 1975 0 Same *1/3/75:19/1/75 0 Every day from Jan 3 thru Jan 19, 1975, this would appear on startup *3/1/75:19/1/75 0 Every day from Jan 19 thru March 1, 1975, this would appear. *3/1/75:3/12/75;5w 0 Between March 1 and 12, 1975, and also on the fifth Wednesday of each month *24:31;1 0 Between the 24th and 31st, and also on the 1st, of each month. 0 Rent due on the first. *1 1000,1300,1400,1500,1600,1700 PAY THE RENT!!! (note the bell in the message, very useful sometimes) 6 ------- 10-MAY-78 22:10:46-PDT,1111;000000000001 Date: 17 AUG 1975 1900-PDT From: WALKER Subject: MSGGROUP# 135 Re: The Chapter on the NLS Journal System by Jim White To: WATSON at BBN-TENEXB, Burchfiel at BBN, Gilbert at BBN, To: NGoodwin at BBN, Myer at BBN, Mooers at BBNA, Tom at CCA, To: Pirtle at I4-TENEX, MsgGroup, PBaran, DCrocker, Ellis, To: Farber, Iseli, Kirstein, Mclindon, Mealy, Spivey, To: Stefferud, Tasker, Walker, Pickens at ISIB, Stotz at ISIB, To: Vittal at ISIB, Vezza at MIT-DMS, Engelbart at OFFICE-1, To: Panko at OFFICE-1, Robertazzi at OFFICE-1, Uhlig at OFFICE-1, To: Kohanski at RUTGERS-10, Ryland at RUTGERS-10, Geoff at SRI-AI, To: ------- at SRI-AI In response to the message sent 14 AUG 1975 1701-PDT from WATSON at BBN-TENEXB One of the primary reasons for establishing the MsgGroup directory was to save us all the pain of receiving 60,000 char messages. As the provider of most of our message storage space, I must insist that we attempt to make better use of MsgGroup and refrain from sending such massive files to everyone. Thanks for the continuing dialogue. Steve ------- 10-MAY-78 22:10:46-PDT,1505;000000000001 Date: 17 AUG 1975 2026-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 136 The Long Message Problem From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]17-AUG-75 20:26:01-PDT.STEFFERUD> To all MsgGroupers: I have received a numer of messages indicating that some members are muchly bothered by the use of [ISI]Mailing.List for transmission of large and VERY large documents. We had three that qualify last Friday. It is recommended that you all send long documents by placing a single copy in MsgGroup@ISI and sending out a notice of availability. One of my received messages pointed out that this situation exemplifies the typically wasteful behavior of people in a free resource situation. The 57,907 character message went to 33 directories, resulting in instant consumption of 1.9 Million characters of storage in various HOSTs. Perhaps some of you would like to comment on the economics of Message Systems in this regard. (Or any other regard, since economics should be part of what MsgGroup is interested in). I suggest that anything larger than 3,000 to 5,000 characters be sent in the "1 copy to MsgGroup@ISI" mode. The new procedures recently sent to you should cover the efficient handling of this mode. Just to be sure, I have checked the files and find that all the long messages are truly there. You can all delete your copies of them without worry of loss. Comments anyone? Stef ------- 10-MAY-78 22:10:46-PDT,2564;000000000001 Mail from USC-ISI rcvd at 18-AUG-75 0056-PDT Date: 18 AUG 1975 0047-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 137 Issue Matrix Suggestion To: [ISI]Mailing.List: After some review of the various aspects and dimensionalities of the MsgGroup problem space, I have drawn up a tentative issue matrix for consideration in our discussions. It has two primary dimensions: Activities and Tools * Activities: | | | * | A. Message | B. Meetings & | C. Fact * | Exchange | Conferences| Gathering Tools: * | | | ----------------------------------------------------------- 1. Text | | | Processing | | | ----------------------------------------------------------- 2. Access & | | | Delivery | | | ----------------------------------------------------------- 3. Filing & | | | Retrieval | | | ----------------------------------------------------------- 4. Data Banking | | | & Retrieval | | | ----------------------------------------------------------- In addition to these dimensions, it seems clear that there is a third dimension, from Formal to Informal, for the entire table. In terms of this matrix, the major interest of MsgGroup now appears to focus on Message Exchange and Conferences using Text Processing, Access & Delivery, and Filing & Retrieval Tools. It is clear that the Activity and Tool categories in this taxonomy are very general, but they can each be factored into subcategories and they do afford some clarity and efficiency in our discussion. For example, the prior paragraph appears to reasonably define the domain of interest of MsgGroup, which is at least one small step forward at this point. With the matrix, it seems possible to develop subject encoding schemes to help label messages to show their subject content. Perhaps we might try to use the matrix row and column headings to encode our messages. (eg. /A./2. means "Message Access & Delivery systems.) To indicate subcategories, we could use a decimal system, and we could include as many row and column headings as we wish in our message SUBJECT fields by preceeding each category code with a slash "/" so we can range over any part of our defined problem space that we may wish in any given message. I will be interested in seeing your comments on these ideas. Unfortunately, I must be away from the network for a couple weeks, so I will have to wait till I return to see what you all think of these ideas. Enjoy, Stef ------- 10-MAY-78 22:10:46-PDT,671;000000000001 Mail from USC-ISI rcvd at 18-AUG-75 1314-PDT Date: 18 AUG 1975 1259-PDT From: FARBER at USC-ISI Subject: MSGGROUP# 138 Adding Bill Danielson to mailing list To: [ISI]Mailing.List: Hi Bill Danielson, Welcome to Message Group. Your name is 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 micro@ISI to their lists or get a new list from [ISI], or ask me to SNDMSG a new official copy. Best Regards, Stef (this actually was done by John Pickens while Stef is away on vacation) ------- 10-MAY-78 22:10:46-PDT,669;000000000001 Mail from USC-ISI rcvd at 18-AUG-75 1315-PDT Date: 18 AUG 1975 1254-PDT From: FARBER at USC-ISI Subject: MSGGROUP# 139 Adding Jake Feinler to mailing list To: [ISI]Mailing.List: Hi Jake Feinler, Welcome to Message Group. Your name is 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 Feinler@BBN to their lists or get a new list from [ISI], or ask me to SNDMSG a new official copy. Best Regards, Stef (this actually was done by John Pickens while Stef is away on vacation) ------- 10-MAY-78 22:10:46-PDT,3151;000000000001 Mail from USC-ISIB rcvd at 18-AUG-75 1641-PDT Date: 18 AUG 1975 1624-PDT From: PICKENS at USC-ISIB Subject: MSGGROUP# 140 Let's put the large file issue to rest: To: [ISI]Mailing.List: There has been considerable discussion recently about how to enter large files in to the MessageGroup discussion. The two methods currently advertised, and their respective drawbacks, are as follows: I. Send the large file to everyone (now numbering about 35 participants) A. The system mailer goes bananas shipping the large file, free of charge, all over the network. B. Storage is used inefficiently, especially for those persons who didn't give a darn about the message anyway. II. Send the large file only to MSGGROUP@ISI and send an abstract advertising its existance to the MessageGroup Membership. A. Non ISI users must FTP the entire [ISI]PROCEEDINGS.MSG in order to get at the single message. B. In advertising its existance, the sender has no convenient way of determining its accession number. This problem has no convenient solution but needs to be solved quickly, and in a manner satisfactory to all. Therefore, the following procedure is proposed for large file processing ( a large file is bigger than about 5000 characters): 1. Send the file via normal message channels to MSGGROUP@ISI. 2. Send another message to MSGGROUP@ISI requesting that the large file be given an accession number and a unique filename. In practice the filename assigned to the message will be identical to the accession number. For example, if this were MSGGROUP# 999, then it would be stored as the file MSGGROUP#999.MSG in [ISI]. Myself or Stef will process this request as soon as possible. When the accession number has been assigned, and the unique file created, we will notify the sender of the original message. 3. When the sender receives notification that his message has been entered into as described above he may then send an abstract to the entire group advertising the existance of the large file and also quoting its exact accession number. It should be noted that this procedure does not affect the previously announced procedures for manipulating MessageGroup files. By following this procedure participants may access large files entered into the discussion via normal FTP. (Users with accounts on ISI may, of course, use COPY or TCOPY to get copies of the files). (If this procedure proves to be useful and workable then I will be glad to show any TENEX user how to automate the retrieval process to the point that only the accession number need be specified in order to FTP the named file into ones own directory. Send requests on how to do this to PICKENS@ISIB.) I hope, in spite of the delay between sending the file to MSGGROUP@ISI and being able to announce it publically, that this procedure will be satisfactory to all. Any complaints, questions, and/or suggestions should be sent to MSGGROUP@ISI,STEFFERUD@ISI, and PICKENS@ISIB. John Pickens ------- 10-MAY-78 22:10:47-PDT,1645;000000000001 Mail from USC-ISI rcvd at 18-AUG-75 1725-PDT Date: 18 AUG 1975 1711-PDT From: DCROCKER at USC-ISI Subject: MSGGROUP# 141 NMSG Answer Command / Keyword Invocation of Functions To: [ISI]Mailing.List: To start my current spate of notes about specific aspects of mail systems, I'd like to add my support to the recent modification to (n)MSG's Answer command. However, I have one piece of criticism which derives from my continuing interest in making the mail system command language(s) more humane: How about multiple-word specification for response-class? Instead of having to remember some fairly arcane keywords (e.g., E(body who received the note, plus cc:'s to be specified) how about allowing a number of keywords per specification? E.g.: S(ender) R(ecipients) A(dd cc's), or E(verbody)? The latter would NOT allow any CC: specification -- unless the user also typed the Add keyword. Since the goal is to provide the user with a set of fairly intuitive keywords, a great deal of care should be put into discovering which particular words are best, and I do not believe the ones in the above example constitute that ideal. They do, however, demonstrate the structure of specification that I am thinking of. Sndmsg, with its Queuing options, is another example. About selection of command words I have more to say, and will in my next message. (My intent, here, is to avoid the "large message" problem by creating smaller, self-contained messages. In a teleconferencing sense, the intent is to keep each "entry" fairly atomic and therefore separately manipulable.) Dave. ------- 10-MAY-78 22:10:47-PDT,3652;000000000001 Mail from USC-ISI rcvd at 18-AUG-75 1854-PDT Date: 18 AUG 1975 1838-PDT From: DCROCKER at USC-ISI Subject: MSGGROUP# 142 Considerations in User Command Vocabulary Selection To: [ISI]Mailing.List: I would like to open a discussion about The Selection of Appropriate Command Invocation Vocabulary. That is, what word will most likely be remembered by the user as invoking a specific function? My understanding of the IA Project's approach to the problem is that they will have a monitor which notices frequent errors and helps the user develop her own vocabulary. Short of having a system which is that flexible (if, in fact, we wish to exclude such a feature from any near-term developments) I believe that this group can be instrumental in helping decide upon the best command words to be used in the mail systems we are/will be using. For the scope of this note, I would like to assert the importance of more complex command syntax (as per my last note and some earlier communications) and of the PERSPECTIVE of the command vocabulary. A more complex (i.e., "natural") syntax seems to be understood as useful, so I will only discuss the question of perspective. The tendency is for a system to have user commands which indicate what computer-related action the system should take. For example, a text editor typically has a "read" command, because the system is reading data from a file into its internal work space. I suspect that, though accurate and precise as a formal description of the system's action, "read" is NOT appropriate to the perspective that SHOULD be available to the user. For something like a text editor, the perspective of an office environment will probably provide a more natural set of command words. For example, what directions does a boss give to a secretary, in order to make the contents of a "file" available for perusal? Unfortunately, two different commands occur to me: 1. If the boss wishes the file to appear on her desk, she tells her secretary to "Get" the file for her; 2. if she merely wishes to prepare her secretary for taking action upon the file, in the boss' behalf, the boss might say "Open" the file. (In fact, "Get" might be used in the latter case, also.) Consequently I will, for the moment, merely assert that either of these words is a better choice than "Read". In the case of other functions, more alternatives may present themselves and we will be faced with making arbitrary selections, which is why I imagine that the IA Project's approach will win. For the present, I suggest selecting a particular perspective (a model that the user can hold of what the computer is equivalent to) and then applying it to the selection of command words. To elaborate upon the problem, without providing any more assistance in finding its solution, I will close with another example of sub-optimal choice of perspective. The example was related to me by Stefferud: In Mailsys, the user can specify "Filters," a capability I find extremely appealing. Stef suggests, however, that people are not used to consciously thinking in terms of "filters" (i.e., of looking through everything in order to extract a subset) but rather focus only upon the characteristics of the subgroup. It might be useful for him to elaborate upon this particular complaint, since it seems to get at the problem of perspective to a more subtle (and insidious) level. ------- 10-MAY-78 22:10:47-PDT,994;000000000001 Date: 21 AUG 1975 0854-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 143 Voice Messages From: FARBER at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]21-AUG-75 08:54:27-PDT.FARBER> Keywords: MSGGROUP,Voice,Messages,IBM,Future,RFC At the risk of getting ahead of ourselves, I would like to raise the subject of the effect of voice messages on the message systems of the future. Besides the technical feasibility of digital voice on the ARPANET, we do know that various groups, including IBM, are experimenting with the idea of a voice memo. That is a "document" that can be edited, filed, retrieved with various retrieval facilities and heard. I would expect that there would be a blend of the written word and the spoken word in such a system. Is there any one in MSGGROUP that is currently thinking down the line of such a combined system and if so can we bat the ideas about in a side conversation. Dave ------- 10-MAY-78 22:10:47-PDT,1138;000000000001 Mail from BBN-TENEXB rcvd at 21-AUG-75 1002-PDT Date: 21 AUG 1975 1241-EDT Sender: WATSON at BBN-TENEXB Subject: MSGGROUP# 144 voice and text and graphics From: WATSON at BBN-TENEXB To: Burchfiel at BBN, Gilbert at BBN, NGoodwin at BBN, Myer at BBN, Mooers at BBNA, WATSON, To: Tom at CCA, Pirtle at I4-TENEX, MsgGroup at ISI, PBaran at ISI, DCrocker at ISI, Ellis at ISI, To: Farber at ISI, Iseli at ISI, Kirstein at ISI, Mclindon at ISI, Mealy at ISI, Ryland at ISI, Spivey at ISI, Stefferud at ISI, To: Tasker at ISI, Walker at ISI, Stotz at ISIB, Vittal at ISIB, Vezza at MIT-DMS, To: Engelbart at OFFICE-1, Robertazzi at OFFICE-1, Uhlig at OFFICE-1, Kohanski at RUTGERS-10, Geoff at SRI-AI Message-ID: <[BBN-TENEXB]21-AUG-75 12:41:17-EDT.WATSON> Dave as you know we recently genralized the NLS file system to handle a range of data types. The first use has been to install in NLS a sophisticated mixed text and graphics capability. We have been planning for some years on also installing voice, with editing of voice mixed voice text etc. Voice messages being just one of many possible applications. Dick ------- 10-MAY-78 22:10:47-PDT,2865;000000000001 Mail from USC-ISI rcvd at 21-AUG-75 1536-PDT Date: 21 AUG 1975 1526-PDT From: DCROCKER at USC-ISI Subject: MSGGROUP# 145 Organizing User's View of Mail System Capabilities To: [ISI]Mailing.List: As more capabilities are added to the mail systems, it becomes increasingly difficult for a user to visualize the system's capability space. Having multi-word command invocation will mitigate the problem, somewhat; but I would like to open a discussion about the possible advantages of "chunking" the command environment, further, by explicitly separating assorted functions into different mail system sub-systems. Structurally, the system would have an executive, with several parallel working environments under it. (For example: Message reading, message entry/editing, message formatting, profile manipulation, etc. Communication between modules would have to be allowed, as in the case of the Answer command. To some extent, such an organization could be viewed as regressive, since it is the kind of environment we have been (or at least seem to have been) trying to get away from. The difference is that the organization I am suggesting would be under a standard interface, with modules designed to cooperate with each other. Another difference is that subsystems would be "immediately" available (not having to go through start-up overhead) and would occasionally be invoked automatically, as in the case of the text editor. A third difference is the ability to bounce between the different subsystems, without losing previous work. In reality, providing such a view onto the mail system should only entail altering the user interface (of Mailsys). It is my impression that it is already designed to perform the above functions, and I am not really concerned with the internals (such as requiring separate processes). I AM concerned with helping the user a) easily learn to do simple things, and b) be able to visualize the working environment. A special note concerning the number of process levels: I believe that having more than two levels (an Exec and a series of parallel inferior processes) is inordinately confusing to most users. Several people have recently questioned that assertion, and I do not have any empirical data to support it, but my suspicion that it is correct is very strong. (Especially in light of how difficult it is for some users to visualize even ONE process level.) Let me reiterate that this note is intended to open a discussion. I am suggesting something that I think MIGHT be useful and would like to ask as many of you as can to respond. Think of this as a survey. Dave. ------- 10-MAY-78 22:10:48-PDT,2469;000000000001 Mail from USC-ISI rcvd at 21-AUG-75 1627-PDT Date: 21 AUG 1975 1614-PDT From: DCROCKER at USC-ISI Subject: MSGGROUP# 146 Mailsys Integration with Existing Software To: [ISI]Mailing.List: There seems to be a slight tendency to have Mailsys replicate functions that are currently available in other pieces of software. I believe that an attempt should be made to, instead, have Mailsys use existing software, whenever possible and appropriate. Also when appropriate, the software should be integrated into the Mailsys environment as smoothly as possible. Specifically, the Format command should not provide yet another idiosyncratic text formatter, as it currently does, and a small editor should not be built for Mailsys (a recent note from Charlotte Mooers sounded as if such was planned). MRUNOFF will do all that the current Format command does, plus allow the user the option of more sophisticated manipulations. In addition, the sources for MRUNOFF are available for modification, so that the interface between it and Mailsys can be made quite smooth. The same arguments hold true for editors. I would also like to recommend that SPELL (a corrector) be incorporated into Mailsys, although the 42,00 word vocabulary in the BBN version has typographical errors in it. ISI has brought up its own version of the program, with many fewer words and errors. (It turns out that, given the design of SPELL, an overly large vocabulary causes problems since infrequently used, but correctly spelled, words are often typos for frequently used words.) Most of these programs have mildly cumbersome start-up scenarios, which could be greatly reduced through the use of a Mailsys-specific profile for each program, and (therefore) sufficient modifications to the programs to allow use of the profiles. As a result of this approach towards including existing functions/software into Mailsys a) a user can view it as a COMPLETE message creation/manipulation environment, never having to leave the environment to perform useful but unavailable message manipulation functions, and b) text manipulation not performed within the Mailsys environment will be with familiar software. Again, I am interested in hearing comments on the above. Dave. ------- 10-MAY-78 22:10:48-PDT,1756;000000000001 Mail from BBN-TENEX rcvd at 22-AUG-75 1127-PDT Date: 22 AUG 1975 1403-EDT Sender: NGOODWIN at BBN-TENEX Subject: MSGGROUP# 147 (Organizing User's View of Mail System Capabilities) From: NGOODWIN at BBN-TENEX To: [ISI]Mailing.List: Message-ID: <[BBN-TENEX]22-AUG-75 14:03:46-EDT.NGOODWIN> In-Reply-To: Your message of AUGUST 21, 1975 Dave, I like the idea of having the message-handling systems structured so that the user sees only the parts of the system which relate to the particular functions he is trying to perform at that time. This is the idea I was trying to put across in my message, Msggroup #56, of 25 June, which was relayed to the group by Steve Walker. I think some people in the group were put off by the use of menu-based, display oriented sequences as an example of such a system, but the basic idea is the same. The user should not be constantly confronted with, or concerned about the availability of, all commands at all times. He should not have to care about Exec level commands, or know about inferior forks (sounds like tin eating implements to me). He should know about the commands/actions/entries needed or available to help him get through that part/chunk of messages-handling he is immediately involved with. A word about MAILSYS duplicating functions available elsewhere, and in particular the development of a new text editor. I may be speaking out of turn, but my understanding is that ISI and BBN are each developing whole-screen text editors. These editors will not be repeats of TECO or XED, but will offer the user with a display terminal a new, and I feel very important, capability. Please don't discourage this development. Regards, Nancy Goodwin, MITRE ------- 10-MAY-78 22:10:48-PDT,864;000000000001 Mail from USC-ISI rcvd at 22-AUG-75 1308-PDT Date: 22 AUG 1975 1254-PDT From: DCROCKER at USC-ISI Subject: MSGGROUP# 148 User-specific Profile Facility To: [ISI]Mailing.List: As more systems are utilizing "Profiles" for each user, in order to taylor system appearance and performance to suit each user's preferences, there is beginning to be a proliferation of Profile-record files in each person's directory. The files typically need very few words or storage but must each use up an entire page. Several years ago, there was some discussion of creating a general profile facility within Tenex. If the idea was tabled, I would like to suggest we re-open discussion on it. If the idea is still being worked on, could we get some idea of what the facility's design looks like? ------- 10-MAY-78 22:10:48-PDT,387;000000000001 Date: 22 AUG 1975 1435-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 149 New Member for MSGGROUP From: FARBER at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]22-AUG-75 14:35:16-PDT.FARBER> I have asked Bob Anderson of the RAND Corporation to join the MSGGROUP conference. Please add him to your mailing lists. Welcome Bob, Dave Farber ------- 10-MAY-78 22:10:48-PDT,2298;000000000001 Mail from USC-ISI rcvd at 26-AUG-75 1531-PDT Date: 26 AUG 1975 1517-PDT From: DCROCKER at USC-ISI Subject: MSGGROUP# 150 Thoughts on the Design of a Shared Profile System To: [ISI]Mailing.List: I would like to get some reaction to the following design of an interim profile system: A file is kept in the user's directory, with the user having only read and append access to the file. The file contains a series of Ascii lines of the form: ":". Any arbitrary program may read its user-specific profile information, from this file, by searching for lines with the appropriate keyword, using as data. For multi-line profile information, can end with monotonically increasing numeric characters. For profile information which is to be used only when the program is run under some other program (e.g., Mrunoff run by Mailsys) the calling program (Mailsys, in this case) can pass a parameter which is a string to be concatenated to . This could lead to a of "MrunoffMailsys1", for example. The using program would be constrained to use the LAST line when a is repeated, so that updated profile information will always be used, independently of having the profile file garbage collected. Garbage collection could be done by a trivial system process that would be run once a day (or week, or whatever). Note that this facility could be used by ANY process, including the EXEC (to execute a login/start-up scenario, for example). The system has the advantages of being easily implemented and allowing each program to maintain its own information with (almost) no impact on other using programs. The disadvantage, besides a fairly unaesthetic design, is the "(almost)". A program could steal another program's , which is unlikely, and could add so many profile lines that it becomes infeasible for anyone to read the file. I believe the benefit of the system would be sufficient to justify the risk. Thoughts, anyone? Dave. ------- 10-MAY-78 22:10:48-PDT,1126;000000000001 Date: 26 AUG 1975 1948-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 151 (Thoughts on the Design of a Shared Profile System) From: FARBER at USC-ISI To: DCROCKER Cc: [ISI]Mailing.List: Message-ID: <[USC-ISI]26-AUG-75 19:48:41-PDT.FARBER> In-Reply-To: Your message of AUGUST 26, 1975 Dave, I think that your proposal has merits. An alternative is , of course, non shared profile files all using standard external names and internal formats. This still needs your sub-profile mechanizm. The prime thing that has bothered me with Tenex is the lack of a LOGIN Profile facility. This eliminates the ability to make the system appear to the novice user the way I want it to appear, not the way Tenex designers thought was proper. Telling the user to type xxxx is a poor second. While I am at it, what systems like Tenex need really is a MACRO facility at command level so that user defined macros etc can "hide" and customize the system to the user. (Remember the facilities in assembler like BEFAP and MAP ; please DO is not a macro facility). Dave ------- 10-MAY-78 22:10:48-PDT,419;000000000001 Date: 27 AUG 1975 1324-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 152 Change of Mail address for Mil Jernigan From: FARBER at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]27-AUG-75 13:24:22-PDT.FARBER> For those of you who maintain your own MSGGROUP mailing ~ list , please change Robertazzi at Office-1 to Jernigan@OFFICE-1 to reflect a new mailbox for Mil. Dave ------- 10-MAY-78 22:10:48-PDT,3466;000000000001 Mail from USC-ISI rcvd at 27-AUG-75 1619-PDT Date: 27 AUG 1975 1604-PDT From: DCROCKER at USC-ISI Subject: MSGGROUP# 153 Proposed Modification to Address List Specification (and Solution to Attn Field Problem?) To: [ISI]Mailing.List: Currently, Sndmsg (and XMail/Mailsys?) do not put the full network address of the sender of LOCAL mail, so that such mail which is automatically forwarded (to the recipient's real home machine) cannot be "Answered." The sender is viewed as local and then found not to be. This problem can be easily remedied by always including the full network address in the Sender and From fields. Rather than merely fix this small problem, it might be interesting to use the opportunity to clean up the entire Name vs. Mailbox, and Shared Mailbox vs. Individual Recipient situation. I believe that the problem with the Attn field will disappear, as a side benefit of my proposal. "DCrocker" is fairly understandable as a person's name. "JFH," "Micro," and "Tom" are not. So, getting a piece of mail which claims to be from "Micro@ISI" does not really help me know what PERSON authored the note. I therefore recommend that the specifications in RFC 680 ("Message Transmission Protocol") be changed to allow name/address lists of the general form: free-text-name , ... The modified BNF for the specification would be approximately as follows: Address-field = Address-list / Address-list "," Address-field Address-list = Namelist / Groupname ":" Grouplist Groupname = Word Grouplist = / "(" Namelist ")" Namelist = Individual / Individual "," Namelist Individual = Mailbox / Name "<" Mailbox ">" Name = {Ascii string without CR, LF, "(", ")", "<", or ">"} Mailbox = User "@" Host User = Word Host = {A standard host name} Word = {Ascii string without CR, LF, or SP} Don't let the differences throw you. That really is BNF. I just wanted to try the changes out. Note that FULL network address is always required and that the names of a group's membership may optionally be included. The last Word in the Name field could be used for sorting mail into different files within a shared mailbox. This is intended to replace the Attn field, not the Key field. (By the way, can anyone explain to me the conditions under which a person uses ATTN:, on a normal letter, rather than simply include the person's name as the top line of the address specification?) Some examples: Dave Crocker DCrocker@ISI, Dave Farber A-Group:(Stef, Steve Walker , Farber@ISI), DCrocker@ISI The critical aspect to my proposal is the distinction between people's names and their addresses. By formalizing some of the syntax involved, special machine processing can be used. For example, a mail-printing program could show only Names, and not bother with showing the Address. I would then see that a piece of mail was from "Bill Danielson" rather than "Micro@ISI." As usual, I welcome comments. Dave. ------- 10-MAY-78 22:10:49-PDT,1088;000000000001 Date: 27 AUG 1975 1840-PDT From: FARBER Subject: MSGGROUP# 154 copy of reply to dcrocker 27 Aug To: MSGGROUP Date: 27 AUG 1975 1837-PDT From: FARBER Subject: Re: Proposed Modification to Address List Specification (and Solution to Attn Field Problem?) To: DCROCKER cc: STEFFERUD, WALKER In response to your message sent 27 AUG 1975 1604-PDT Dave, First I would like to specifically thank you for your flurry of contributions to the msggroup discussion. They have been well thought out and valuable in stimulating thought and activity. I tend to agree with your proposel and would recommend it to msggroup and to the message committee. I have not sent this note via popular distribution to hold down the volume. I think by the way that one uses attn: when one is addressing an organization rather than just a person. It is vague in my mind but I would ask steve walker to comment since NSA seems to be the home of such indirectness. Director NSA ... attn:Walker . again thanks Dave and keep up the fine contributions. Dave ------- ------- 10-MAY-78 22:10:49-PDT,434;000000000001 Date: 30 AUG 1975 1648-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 155 Change of address From: FARBER at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]30-AUG-75 16:48:21-PDT.FARBER> Bill Danielson has moved to the RAND Corp. Please change his MSGGROUP address in private mailing lists to BRD@RAND-RCC The MSGGROUP mailing.list has been changed to reflect this. Dave Farber ------- 10-MAY-78 22:10:49-PDT,365;000000000001 Date: 31 AUG 1975 1635-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 156 In refernce to change of address 30 August 1975 MSGGROUP From: FARBER at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]31-AUG-75 16:35:49-PDT.FARBER> To clarify an inadequate message, please delete micro@isi and replace it by BRD@rand-rcc Dave ------- 10-MAY-78 22:10:49-PDT,772;000000000001 Date: 3 SEP 1975 1355-PDT From: UCSB Subject: MSGGROUP# 157 MSG from FARBER re: Washington gathering sent 20 AUG To: msggroup Date: 20 AUG 1975 1122-PDT Sender: FARBER at USC-ISI Subject: Washington Get-to-gether From: FARBER at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]20-AUG-75 11:22:44-PDT.FARBER> This note is to remind all about the informal meeting in Washington of the MSGGROUP . The date is 12 September. We will be publishing a draft agenda soon. If you want to make a informal formal presentation , please sndmsg about the subject so I can reserve some time. Also, can I get a volenteer to handle the local arrangements in the DC area. Hotels dont have msg access yet. Dave ------- ------- 10-MAY-78 22:10:49-PDT,720;000000000001 Mail from USC-ISIB rcvd at 3-SEP-75 1641-PDT Date: 3 SEP 1975 1638-PDT From: PICKENS at USC-ISIB Subject: MSGGROUP# 158 Automated retrieval of [ISI]MAILING.LIST for TENEX users To: [ISI]Mailing.List: The following character string, when run either with the RUNFIL or DO subsystems, will grab the most current version of the MSGGROUP mailing list and put it in your TENEX directory under the name MAILING.LIST. It is included here for reference, but it may also be accessed via FTP as [ISI]GETLIST. Any questions should be directed to PICKENS@ISIB. John Pickens ---------->ftp isi login anonymous arpa get mailing.list mailing.list bye quit ------- 10-MAY-78 22:10:49-PDT,261;000000000001 Mail from OFFICE-1 rcvd at 5-SEP-75 0753-PDT Date: 5 SEP 1975 0755-PDT From: PANKO at OFFICE-1 Subject: MSGGROUP# 159 Excuse me, this is a test. To: [ISI]Mailing.List: I am trying to learn how to send messages to the mailing list. ------- 10-MAY-78 22:10:49-PDT,7078;000000000001 Mail from OFFICE-1 rcvd at 5-SEP-75 1425-PDT Date: 5 SEP 1975 1422-PDT From: PANKO at OFFICE-1 Subject: MSGGROUP# 160 Ease of Use and NLS To: msggroup at USC-ISI < PANKO, EASE-OF-USE.NLS;2, >, 5-SEP-75 09:43 RA3Y ;;;; INTRODUCTION A major theme of this teleconference has been ease of use: how rapidly and naturally can users learn to send messages, read their mail and file their mail away. Several comments have suggested that NLS is difficult to use. Without remarking on the overall validity of these comments, I would like to note that NLS offers a hierarchy of mail-handling tools, including simple and formal tools as well as the detailed specifications of the Sendmail subsystem. SINGLE-COMMAND TOOLS NLS allows users to read their mail and send mail with single commands. For example, the command "Print Journal" prints each citation in the user's in-box (Journal branch), then prints the full text of the citation. "Print Journal" works on the user's teletype terminal. The command "Output Journal" prints citations and full text on a line printer. To send mail, the user types "Interrogate" in the Sendmail subsystem. The user is then prompted for receivers, a title, and a filename or message. At the end of the sequence, the user can send the mail or decline to send the mail. If the mail is not sent, the user may go back and change specifications or add specifications, such as privacy or keywords. I personally feal that "print journal" and "interrogate" could use some tweaking. For example, "print journal" may deluge you with a many-page document every now and then and does not automatically print only new mail. But these single-command tools to work rather well, and the idea behind them, providing simplicity for novel users without compromising in overall power, should certainly be contemplated. FORMAL TOOLS Sometimes it is desirable to lock the user into a set pattern of input corresponding to some form used in the organization. To partially address the need for repetitive structuring, NLS provides a "Sendmail Form" feature, in which specifications are listed in an automatically-structured NLS file. Once the form is set up, the clerk can simply change information that is unique to this message, then use the "Process (sendmail form)" command to send a message or file under the specifications of the form. To format mail exactly in accordance with a particular form, a user subsystem can be created in a week or less. The subsystem can employ specific interrogate sequences, sendmail forms and other features of the sendmail system. At least one NLS client has developed a "forms subsystem" for this type of work. SPECIFYING MAIL IN DETAIL NLS is probably best-known for its ability to process mail sending in detail. The Sendmail subsystem does have about 40 commands for doing this, although few transmission would use as many as a dozen. If the full Dialogue Suport System Concept that has been designed were implemented, the number of commands would probably double. Sendmail allows user to specify authors (the actual sender is called the clerk), title, comments, keywords, subcollections and privacy status. The user may type in a message, send a file or part of a file, or send a citation to an offline document. The user is even given some control over the accession number of the mail item. Sendmail allows users to foreward items, but at present there is no answer command. Because there are so many commands, a "show status" command is available to review the parameters of the transmission. NLS uses "idents" in transmission, which are like telephone numbers. A "show record" command based upon a lastname or ident will give the correct ident and other useful information about the person. In transmissions, a lastname preceeded by a period may be used in place of an ident. If there is more than one person in the ident file with the last name, their full names, organizations and idents will be listed, and the sender will be asked to type in the correct ident. READING MAIL IN DETAIL Except for brief messages, which are delivered in full, the user only receives a citation (like an envelope but with a title and perhaps a comment) to the full file. This allows the user to skim through mail and prevents the user's work space from becoming crowded with uninteresting mail. By printing the part of the user's file which holds the citations and brief messages, the user can find items he or she wishes to see in full. Each citation also lists the author(s), time sent, accession number of the item, a title and a note about special conditions (for example, if it was forwarded by somebody). Optionally, an author's comment may be included or the full text of the message, if it is brief. Each citation contains a "link" to the full text item. By pointing to the link, the user loads the full text. The journal item can be read online or printed on a line printer, as the user desires. Authors' idents are listed in the citation. If the reader is unfamiliar with the ident, the "show record" command can be used to give the person's full name, organization, telephone number and other useful information. Detailed information about the clerk, the primary receivers of the message, and other details of the transmissionjp is contained in the origin statement of the full text item. Uninteresting citations can be deleted. Interesting items can be annotated with standard NLS editing commands and moved, again with standard NLS commands, to appropriate branches of the user's "filing cabinet" file. It sometimes happens that a user will wish to search through the public items in the Journal file by author, date or titleword. Special tools for doing this are provided. If a journal item is old so that it is no longer online (items are held online for 21 days AT ALL NLS SITES), Tenex interrogate features can be used to retrieve the item. Sometimes teleconferences (like the current conference we are participating in) are held. A special directory and group ident are set up. Mail for the conference is sent to the single ident, and all receivers will receive the citation to the item as well, if they wish. If things get too burdensome, people can remove their name from the group ident but retain read access to the directory. Usually, but not always, any NLS user can read the file, even if it is online at a different NLS site. ------- 10-MAY-78 22:10:50-PDT,275;000000000001 Mail from OFFICE-1 rcvd at 5-SEP-75 1431-PDT Date: 5 SEP 1975 1416-PDT From: PANKO at OFFICE-1 Subject: MSGGROUP# 161 Another Longie To: [ISI]Mailing.List: I am sending a discussion of "ease of use" in NLS to the message group directory at ISI. ------- 10-MAY-78 22:10:50-PDT,252;000000000001 Mail from USC-ISI rcvd at 5-SEP-75 1703-PDT Date: 5 SEP 1975 1651-PDT From: FARBER at USC-ISI Subject: MSGGROUP# 162 PANKO's message on ease of NLS use is [ISI]MSGGROUP#.160 To: [ISI]Mailing.List: John Pickens ------- 10-MAY-78 22:10:50-PDT,1513;000000000001 Date: 7 SEP 1975 1254-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 163 MSGGROUP Meeting on 12 Sept in Washington D.C. From: FARBER at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]7-SEP-75 12:54:32-PDT.FARBER> Keywords: msggroup,meeting,1975 Special-Handling: please note location and time 1. Meeting starts at 0900, 12 Sept. - Ends in mid Afternoon. Blackboards and Coffee will be available. Expected attendance is 12 people. 2. Location is at SAI (Scientific Applications, Inc.) 1911 North Fort Myer Drive, Suite 1200 Rosslyn (Arlington), Virginia 3. Transport arrangements from the Mayflower Hotel for COMPCON attendees will be made during the COMPCON Meeting. 4. It should be noted that this is an un-official meeting and thus anything said will be considered "off-the-record" and not subject to "but you said you were going to ..." In line with this Steve Walker is attending as an interested participant - not as an ARPA program director. 5. The tentative agenda includes: A. Agenda Discussion - Farber B. Issue Matrix Structure - Stefferud C. MsgGroup Proceedings Processing - Stefferud D. MSGIRS Concepts and Application - Vezza E. Discussion of Voice Messages - Farber F. Open discussion of MAILSYS and MSG improvements G. Additional Topics (etc). A announcement will be placed on the COMPCON Board. Please indicate on it additional topics or the need for transportation Dave and Stef ------- 10-MAY-78 22:10:50-PDT,433;000000000001 Mail from USC-ISI rcvd at 10-SEP-75 2015-PDT Date: 10 SEP 1975 2009-PDT From: STEFFERUD at USC-ISI Subject: MSGGROUP# 164 Add vonGehren@OFFICE-1 To: [ISI]Mailing.List: Hi Ed, Welcome to MsgGroup! Since you have been getting copies of the MsgGroup Proceedings through Ron Uhlig, I will not burden you with the usual introductory messages. If you want any info, just ask. Best regards, Stef ------- 10-MAY-78 22:10:50-PDT,22405;000000000001 Mail from BBN-TENEXA rcvd at 18-SEP-75 1517-PDT Date: 18 SEP 1975 1804-EDT Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP# 165 A Conceptual Introduction to MAILSYS Message-processing commands From: MOOERS at BBN-TENEXA To: msggroup at ISI Message-ID: <[BBN-TENEXA]18-SEP-75 18:04:23-EDT.MOOERS> Bolt Beranek and Newman Inc. -- D R A F T -- Not for Publication A CONCEPTUAL INTRODUCTION TO MAILSYS MESSAGE-PROCESSING COMMANDS 9/18/75 I. MAILSYS TERMINOLOGY A. OBJECTS IN THE MAILSYS ENVIRONMENT CURRENT OBJECTS If an OBJECT is defaulted, i.e., not specified by name, in a MAILSYS command, the system uses the current OBJECT. A.1. The current INBOX -- file containing messages. A.2. The current MESSAGE-LIST -- set of messages in INBOX. A.3. The CURRENT MESSAGE, symbolized by "." -- message just acted upon in some way. Initially set to "the one before the first" in MESSAGE-LIST. A.4. The current FILTER -- acts on a message-list; selects messages on the basis of information or status. A.5. The current TEMPLATE -- specifies parts of message to be output. A.6. The current SURVEY-TEMPLATE -- template used by SURVEY command. A.7. The current STREAM -- type of output: a printing device or file and a specification for separating messages. A.8. The current setting of the SWITCHES -- User's choices of switch settings for commands that have more than one default option. PERMANENT OBJECTS Named Message-lists: ALL, RECENT-MSGS, OLD-MSGS, NEW-MSGS, SEEN-MSGS, UNSEEN-MSGS, DELETED-MSGS, UNDELETED-MSGS Named Filters: BLANK, SEEN, UNSEEN, DELETED, UNDELETED, TODAY, YESTERDAY Named Templates: VERBATIM, ALL, BASIC-SURVEY, NULL The SURVEY-TEMPLATE: The contents of the SURVEY-TEMPLATE can be changed, but only one SURVEY-TEMPLATE can exist. The SWITCHES: The settings of the switches can be changed, but only one group of settable SWITCHES can exist. OBJECTS CREATED AND STORED BY THE USER Named Message-Lists Named Filters Named Templates B. MESSAGE-HANDLING COMMANDS B.1. TRANSCRIBE: Copies messages to printing devices or files. (Special cases: READ, (LF), ^, PRINT, LINEPRINT, SURVEY.) Files are NOT MAILSYS-readable. B.2. FILE: Copies messages to MAILSYS-readable files. B.3. DELETE: Marks messages for deletion. B.4. UNDELETE: Removes DELETE markings. B.5, EXPUNGE: Physically removes DELETED messages from the files. C. OBJECT-HANDLING COMMANDS C.1. SHOW: Prints out any or all current objects, and any or all fields of the current message being built for sending. (Special case: STATUS = SHOW INBOX) C.2. USE: Creates a current object which is a copy of a literal value or a named object. USE takes current FILTER, INBOX, MESSAGE-LIST, STREAM, SURVEY-TEMPLATE, TEMPLATE or . (= CURRENT MESSAGE). (Special cases: INPUT, CONSIDER, JUMP-TO) MODIFY: Allows User to change the current object; calls a more of less elaborate editor, depending upon the object. MODIFY takes FILTER, INBOX, SURVEY-TEMPLATE, PROFILE [Not yet implemented.], SWITCHES, TEMPLATE. REMEMBER: Copies the current object into a named object. REMEMBER takes FILTER, MESSAGE-LIST, TEMPLATE. C.5. FORGET: Physically removes named object from the enviroment. D. THE USER'S PROFILE -- Characterization of the User Through Choice of Used-Defined Filters and Templates, the SURVEY-TEMPLATE, and Settings of Switches. D.1. RESET: Saves the PROFILE across sessons. [Not yet implemented.] II. THE MAILSYS COMMANDS A. CURRENT OBJECTS IN THE MAILSYS ENVIRONMENT The MAILSYS current environment is composed of a number of OBJECTS. Only one of each of these objects can exist at any one time as the current OBJECT. There are eight current OBJECTS in all. A.1. The current INBOX, named "INBOX". An inbox is a file identified by a Tenex file name which contains MAILSYS-readable messages. Each message is identified by a message number. Initial setting: MESSAGE.TXT;1 in the User's directory. Any other file that contains MAILSYS-readable messages may be used as the INBOX. A.2. The current MESSAGE-LIST, named "MESSAGE-LIST". A message-list is an ordered set of message-groups, separated by commas: , , ... , Initial setting: all RECENT messages in INBOX. A message-group may be: A literal message number or range of numbers: Ex.: 3 1-4 = 1,2,3,4 9-5 = 9,8,7,6,5 A special symbol for a message number: % = last message in INBOX . = the CURRENT MESSAGE A predefined, named list of messages: ALL or * = all messages in INBOX RECENT-MSGS = all messages that have arrivedd since you last looked at INBOX OLD-MSGS = all messages that arrived before you last looked at INBOX NEW-MSGS = messages that have arrive during this session, but that have not been looked at SEEN-MSGS = all messages marked seen UNSEEN-MSGS = all messages not marked seen DELETED-MSGS = all messages marked deleted UNDELETED-MSGS = all messages not marked deleted A User-defined, named list of messages A message-group acted upon by a filter: / Ex.: ALL/FROM JONES DELETED-MSGS/SUBJECT BOSTON 23-%/UNSEEN MESSAGE-LIST may set be to any combination of literal or named message-groups; it may be MODIFIED, named and REMEMBERED during a working session. A.3. The CURRENT MESSAGE, symbolized by "." This is the message which has just been acted upon in some way. Initial setting: "the one before the first", that is, the position just before the first message on MESSAGE-LIST. This convention is adopted so that the command (LF) can be used to print out the first message. (LF) changes the CURRENT MESSAGE to the next message on MESSAGE-LIST, and then prints the new CURRENT MESSAGE on the User's terminal. ^ changes the CURRENT MESSAGE to the previous message on MESSAGE-LIST, and then prints it. The CURRENT MESSAGE can always be entered in a message-list symbolically as "." SHOW . (CR) prints out the message number of the CURRENT MESSAGE on the User's terminal. USE . (CR) or JUMP-TO (CR) changes the message number of the CURRENT MESSAGE to . A.4. The current FILTER, named "FILTER". A filter is a tool for selecting messages on the basis of their status or of the information they contain. It is always used in conjunction with a message-list. Initial setting: empty -- no current filter A filter may be: A predefined, named filter: BLANK -- passes any message DELETED -- passes only messages marked deleted UNDELETED -- passes only messages not marked deleted SEEN -- passes only messages marked seen. UNSEEN -- passes only messages not marked seen. TODAY -- passes only messages received today. YESTERDAY -- passes only messages received yesterday. A User-defined filter. A one-time, throwaway literal filter: BEFORE AFTER ONDATE where may be entered as 4-JUL-76, 4 JUL 76, or 7/4/76, and the month may be abbreviated or spelled, upper- or lower-case. where A.7. The current STREAM, named "STREAM". A stream defines the place and manner in which messages are output: = Initial setting: TTY: NOSEPARATE The may be TTY: -- prints messages on the User's terminal. LPT: -- prints messages on the lineprinter. -- copies messages into a file with the TENEX file designation . The may be NOSEPARATE -- does not separate messages. SEPARATE -- inserts a formfeed after each message. The USE command changes STREAM to a new literal value (e.g., to the lineprinter, or to a Tenex file); it may not be named. Only one STREAM can exist at a time. A.8. The current SWITCHES or default settings, named "SWITCHES". This feature allows the User to choose between the different default options associated with many of the MAILSYS commands. SWITCHES may be MODIFIED but may not be named. Only one SWITCHES can exist at one time. SWITCHES may be saved across sessions as part of the User's PROFILE. B. COMMANDS THAT DO THINGS TO MESSAGES: TRANSCRIBE (Special Cases: READ, (LF), ^, PRINT, LINEPRINT, and SURVEY), FILE, DELETE, UNDELETE, EXPUNGE B.1. TRANSCRIBE -- The general command for processing messages. TRANSCRIBE