25-Mar-80 23:08:04-PST,6153;000000000001 Mail-from: MIT-ML rcvd at 25-Mar-80 0225-PST Date: 23 March 1980 2005-PST (Sunday) From: MSGGROUP at USC-ECL Subject: MSGGROUP#1501 SURVEY [ECL]MSGGROUP#.1451-1500 To: MsgGroup at MIT-ML Message-ID: <[USC-ECL]23-Mar-80 20:05:17.MSGGROUP> Redistributed-To: msggroup at MIT-ML Redistributed-By: STEFFERUD at OFFICE-1 Redistributed-Date: 25 Mar 1980 MSGGROUP#1451 SURVEY [ECL]MSGGROUP#.1401-1450 6255 chars 28 DEC 1979 1634-PST From: ESTEFFERUD at USC-ECL MSGGROUP#1452 re: quoted without comment 381 chars 28 Dec 1979 1635-PST From: POSTEL at USC-ISIB MSGGROUP#1453 re: quoted without comment 898 chars 28 DEC 1979 2058-PST From: ESTEFFERUD at USC-ECL MSGGROUP#1454 Re: quoted without comment 804 chars 29 December 1979 01:02 est From: Frankston.Frankston at MI MSGGROUP#1455 Electronic Mail Systems 1047 chars 6 Jan 1980 1:07 am (Sunday) From: Becker at PARC-MAXC MSGGROUP#1456 PBS program on computers and education 1147 chars 10 Jan 1980 0200-PST (Thursday) From: Lauren at UCLA-Securit MSGGROUP#1457 Replies to Electronic Meta-Mail 2523 chars 10 Jan 1980 4:41 pm (Thursday) From: Becker.PA at PARC-MAXC MSGGROUP#1458 message floods and mail protocols 1485 chars 11 January 1980 1448-EST (Friday) From: David.Lamb at CMU-10 MSGGROUP#1459 After the deluge 1548 chars 12 January 1980 19:58 est From: Frankston.Frankston at MIT MSGGROUP#1460 Re: After the deluge 2760 chars 13 Jan 1980 1519-PST From: Zellich at OFFICE-1 MSGGROUP#1461 SAVE-LARGE-LISTS mailings 917 chars 15 Jan 1980 (Tuesday) 2130-EDT From: DREIFU at WHARTON (Henr MSGGROUP#1462 implementation note to mailsystem implementors 1787 chars 15 Jan 1980 2212-PST From: Mark Crispin for details.) Some problems: 1. An interesting tension: the receiver of a message may well have his own format through which he prefers to display all messages. Which has priority, the sender's or the receiver's format? 2. The format specification language implicitly defines the nature of message displays (location, fonts, bold, italics, grey scale, color, ...). How can we leave this open ended? How can we support sophisticated specifications and at the same time not-quite-so-sophisticated display equipment. (The Graphics Protocol people have some answers one might trade on here.) I suggest that a structured sublanguage be put together for experimenting with some of these ideas. Austin [Editors Note: Austin appears tp have used proportional spacing in composition, and this led him to put more than 72 (Actually more than 80) caharacters per line in the text he sent out. I have left this message formtted exactly as sent to avoid masking the problems it causes from the recorded transcript of MSGGROUP.] 25-Mar-80 23:08:05-PST,1412;000000000001 Mail-from: MIT-MC rcvd at 24-Mar-80 1224-PST Date: 24 Mar 1980 1456-EST Sender: DDEUTSCH at BBN-TENEXA Subject: MSGGROUP#1504 Self-formatting messages From: DDEUTSCH at BBN-TENEXA To: MsgGroup at MIT-MC Cc: DDeutsch Message-ID: <[BBN-TENEXA]24-Mar-80 14:56:54.DDEUTSCH> As Rich Zellich has pointed out, this problem is being discussed by a number of groups, including the communicating word processor people. An ANSI committee, mostly representing communicating word processor manufacturers, has been working on a standard for transmitting page images. (The actual work is being done by working group 4 of X4A12, which is the parent technical committee.) I was involved in this work in its earlier stages, and still get all the mailings. They have created a draft standard for a page image format. As its name implies, it is a series of rules for how to indicate the format of a paged document. It depends upon the ASCII format effectors to indicate formatting. PIF's authors have knowingly created a rather small set of formatting options in order to allow the standard to be useful with as much of the existing hardware in the field as is possible. I am willing to discuss this further with anyone who wants the specifics. People who would like a copy of the draft standard should contact X4A12 by writing to CBEMA, 1828 L St. NW, Washington, D.C. 20036. Debbie 25-Mar-80 23:08:05-PST,1045;000000000001 Mail-from: MIT-ML rcvd at 24-Mar-80 1337-PST Date: 24 March 1980 16:15-EST From: "Marvin A. Sirbu, Jr." Subject: MSGGROUP#1505 Re: Line lengths and columnated text To: AHenderson at PARC-MAXC, Zellich at OFFICE-1 cc: MsgGroup at MIT-ML I applaud your recognition of the need for format standards. Let me propose however, that instead of fixing on specifiers for font, line length, etc., we move towards a higher level convention such as Scribe. In the Scribe formatting language, users specify higher level constructs such as "quotation", "list" or "heading" using ASCII based coding conventions. These designations are then compiled into formatting descriptions appropriate to a particular output device (e.g. on an XGP a heading might be in Boldface; on a Diablo printer it might simply be overstruck; on the appropriate terminal it might be alternate intensity or reverse video.) Mail reading programs would then have to format the message according to the particular output terminal type. 25-Mar-80 23:08:05-PST,2757;000000000001 Mail-from: MIT-ML rcvd at 25-Mar-80 0015-PST Date: 24 Mar 1980 2348-PST Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1506 Re: Line lengths and columnated text From: STEFFERUD at OFFICE-1 To: MsgGroup at MIT-ML Message-ID: <[OFFICE-1]24-Mar-80 23:48:17.STEFFERUD> In-Reply-To: Your message of 24 March 1980 16:15-EST I remember a long ago version of this conversation, where-in I recall complaining about some folks amongst us who keep trying to force us all to buy masseratti terminals, or at least they seem to be trying to fix things so us poor folk can not live in the same net with THEM. WEll, I have gotten all the way up to 1200 baud now, and have at least 24x80 characters on my screen to look at. But I see that the masserratis have been advancing too! Sigh. Now we have folks who compose on proportional pitch displays for sending to us poor monospace folks. So I repeat myself - "The poor will be with us always!" Recently I overheard some folks worrying about how to deal with compatibility in public nets with those old five bit baudot TTYs. Seems that they are just the thing for deaf folks cause they are so cheap (affordable). I suggested that the cheapest solution is for the Govt to replace them all with TT33s. Sorry, used masserratis are still too expensive. So, while you are all going rapidly off in the high performance direction, I want to hook my anchor a bit farther back in the other direction. Just to keep things in balance. (Dare I chuckle?) No, I am not just trying to be anachhronistic. Only a little dramatic. We really have serious troubles ahead with the business of leaving the display format unbound till final display time at the receivers terminal, and dependent on the receiver's selected style of display. Seems to me that much of the research in this field is concerned with delaying the binding time on variables. Well, we have just unbound the location of the ink on the paper in our communications medium. We have unbound the font, the number of characters on the line, the manner of highlighting, et al. I am not really against all this. But I do want to make note of the horrendous task ahead if we really want this stuff to be wide spread. How about a SCI-FI piece where all variables are left unbound until someone has an inspiration to fix a few, just for the hell of it? Imagine the boom in business for artists to design letter heads that will convey the intended feelings of taste and style no matter how you might display them at your place? Please note! I am not trying to throw cold water on your thoughts and ideas. I am just trying to ask a few hard questions that bother me every time this subject comes up. Stef 25-Mar-80 23:08:05-PST,787;000000000001 Mail-from: PARC-MAXC rcvd at 25-Mar-80 0927-PST Date: 25 Mar 1980 09:23 PST From: AHenderson at PARC-MAXC Subject: MSGGROUP#1507 Re: Line lengths and columnated text In-reply-to: STEFFERUD's message of 24 Mar 1980 2348-PST, <[OFFICE-1]24-Mar-80 23:48:17.STEFFERUD> To: STEFFERUD at OFFICE-1 cc: MsgGroup at MIT-ML Right on, brother. I'm with you. But I wasn't necessarliy implying that this research should be done only so the masserattis could make the VW's owners of the world feel "poor". In fact, we know that there is a reverse psychology about such things which will mitigate against agreement. I think formatting conventions would jhelp this masseratti owner to print out messages using a fixed pitch font WHERE THAT WAS IMPORTANT. That's all. Austin 25-Mar-80 23:08:05-PST,3134;000000000001 Mail-from: MIT-ML rcvd at 25-Mar-80 1345-PST Date: 25 Mar 1980 1515-EST From: WJN at MIT-DMS (Wayne J. Noss) To: AHenderson at PARC-MAXC Cc: Zellich at OFFICE-1, MsgGroup at MIT-ML, Raver at MIT-DMS, Neal at MIT-DMS, Slogin at MIT-DMS, LYS at MIT-DMS In-reply-to: Message of 24 Mar 80 at 1100 EST by AHenderson@PARC-MAXC Subject: MSGGROUP#1508 [Re: Re: Line lengths and columnated text] Message-id: <[MIT-DMS].141545> I think the problem of what format information (local or sender's) to use when displaying messages is really one which arises only because of inadequate abstraction. Messages I send are filled to a certain width because this is a width I like to see when receiving messages. Before I became accustomed to automatic filling, I filled manually to the width of the widest line of the message I was replying to (if available). The whole point is that the line width is not part of the message, but an adjustable parameter to be determined by other means--either by what I perceive to be the receiver's desires, or what my text editor gives me. The format is not "fill to column n", but "text" or "paragraph". The fact that this is a paragraph fully expresses ALL the format information I intend. Whether paragraphs are delimited by indentation, blank lines, or whatever, and whether or not they are right-adjusted, and to what width, are matters of taste and are not part of the information in a message. There are times when more explicit format information may have to be included in order to convey the information properly. If, for example, a message contains information requiring consecutive lines to line up properly, then a format desriptor other than "text" or "paragraph" would be needed. Preferably, some descriptor such as "table" would describe the situation fully, but, if not, something like "fixed-width font, nofill", should suffice. The receiver can then tailor incoming messages according to his/her wishes, within the constraints imposed by the (properly abstracted) format specifier that comes with the message. For example, I might specify that text be shown in a certain (variable-width) font, with paragraphs separated by a blank line and indented .5 inch, with text filled (but not adjusted) to 6 inches wide. If something comes labeled "paragraph", this spec would do a thorough formatting; if something comes with a more specific specification, my tailoring would simply be of no effect. What I would consider a reasonable means of accomplishing the desired abstractive functionality would be for a message composer to compose the message interspersed with formatting information, akin to the information fed to text fomatting programs. Only necessary formatting information would be included. The receiver would have what is essentially a subroutine, to be implicitly called at the beginning of the message, containing only formatting information, establishing defaults for all options. The display could then be driven by a text formatter, using the current settings of all options. --WJN 25-Mar-80 23:08:05-PST,1154;000000000001 Mail-from: MIT-ML rcvd at 25-Mar-80 1430-PST Date: 25 Mar 1980 1407-PST Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1509 Re: [Re: Re: Line lengths and columnated text] From: STEFFERUD at OFFICE-1 To: WJN at MIT-DMS Cc: MsgGroup at MIT-ML, Raver at MIT-DMS, Neal at MIT-DMS, Cc: Slogin at MIT-DMS, LYS at MIT-DMS Message-ID: <[OFFICE-1]25-Mar-80 14:07:04.STEFFERUD> In-Reply-To: <[MIT-DMS].141545> In response to your message sent 25 Mar 1980 1515-EST Hi WJN, and others who may not have learned the MSGGROUP rules: Taking your claim to match the line width on received mail to guide your sent mail formatting, please limit your MSGGROUP mail to 72 columns. 72 Columns is the long established limit for MSGGROUP mail because a number of our members are actually still using 72 column terminals. [Right Ken?] On those terminals, your long lines will look very ugly, and I am sure you do not want to have that result. And, if you do not send it that way to the group, then I have to reformat it for inclusion in the MSGGROUP transcript. I would rather not do that extra work if it may be avoided. Cheers - Stef 27-Mar-80 22:13:02-PST,1940;000000000001 Mail-from: MIT-ML rcvd at 26-Mar-80 2124-PST Date: 27 March 1980 00:03 est From: Frankston at MIT-Multics (BOB at SAI-Prime) Subject: MSGGROUP#1510 Fixed width fonts, Teletext/Viewdata and TVs Sender: SALawrence.SoftArts at MIT-Multics To: msggroup at MIT-ML Message-ID: <800327050335.513136 at MIT-Multics> Original to: ,msggroup at mit-ml 1. First, proportional fonts are nice in their place, but the fixed width of the font used for composing letters is an integral part of their formatting. Thus they should be viewed with the expected font, just as they are best viewed on a wide enough terminal. The reason that I am sensative to this is my years of annoyance with documentation people who insist on printing tabular information in proportional font. It has a tendency to make tabular information (such as program listings or keyboard dialogs) totally confusing especially since white space is often critical. The reason that the "real world" gets away with this is that tabular information normally consists of digits (organized into numbers) and words. The numbers a printed with unit width digits, and the words are set to start in appropriate columns. But computer tables consist of digits and letters. Each letter must appear in the appropriate column, and doesn't! 2. Lots of 40 character terminals (or 32?) may soon be appearing in the form of your home TV. With not many lines. How can one make use of a network containing a mixture of these and wide terminal? It would seem to make some sort of reformatting mandatory. PS: I apologize if I have slipped past 72 columns (like I did on one of the lines above), but finally, I have found a use of the idiot bell that this terminal rings in TTY33 compatability moe (the only mode it apparently has (actually it does have some cursor control, but ...) 27-Mar-80 22:13:02-PST,497;000000000001 Mail-from: MIT-MC rcvd at 27-Mar-80 0659-PST Date: 27 Mar 1980 (Thursday) 0907-EST From: COTTON at NBS-10 Subject: MSGGROUP#1511 removal from mailing lists To: human-nets at MIT-AI, header-people at MIT-MC, msggroup at MIT-MC Please remove my name from all automatic distribution mailing lists (COTTON@NBS-10) since I will be leaving NBS shortly. After April 1 I will be at Booz, Allen & Hamilton, Inc., 4330 East West Highway, Bethesda, MD 20014. (301/951-2200) Ira Cotton 9-Apr-80 21:02:16-PST,1153;000000000001 Mail-from: MIT-ML rcvd at 1-Apr-80 0113-PST From: RMS@MIT-AI Date: 04/01/80 04:02:07 Subject: MSGGROUP#1512 Another Stone-Wall Host RMS@MIT-AI 04/01/80 04:02:07 Re: Another Stone-Wall Host To: msggroup at MIT-ML Once again I was unable to reach someone because the host he was on won't let me communicate with him without logging in. I won't give the name of the host; it doesn't really matter. It's only a matter of time before it happens to me on YOUR host. I had tried sending him mail, but had no way of knowing what his system tells him when he gets mail. Maybe it only said "You have some mail". Maybe nothing. And his phone number at work was not available to me. It was very frustrating to be able to see that he was logged in and not be able to communicate. Actually, it happened also with another person at another host. For him, I eventually managed to figure out a phone number, by indirection and guesswork, but by the time I called it he had just gone home. I knew he was there because I could ask that withoout logging in. If I could have sent him a message then and there, I would have reached him. 9-Apr-80 21:02:16-PST,1209;000000000001 Mail-from: MIT-ML rcvd at 8-Apr-80 1440-PST Date: 8 Apr 1980 1411-PST From: Alan R. Katz Subject: MSGGROUP#1513 GTE electronic mail To: msggroup at MIT-ML, human-nets at MIT-AI Thought you all might be interested in this. Alan --------------- From the Wall St. Journal, April 3, 1980; page 32: GTE UNIT PLANS TO OFFER ELECTRONIC MAIL SERVICE GTE Telenet, a unit of General Telephone and Electronics Corp. said it plans to offer an electronic mail service starting July 14. Called Telemail, the service will carry messages electronically between various types of data terminals. In a filing with the Federal Communications commision, GTE Telenet said it plans to charge 22 cents a minute during normal business hours and five cents a minute otherwise, with prime-time discounts of as much as 50% for high volume users. Telemail will be different from current telex and facsimile services, GTE Telenet said, in that it will be able to reach desktop and portable terminals as well as centralized communications rooms. The company estimated there are more than 1.5 million terminals already in use that could be reached by Telemail. ------- 9-Apr-80 21:02:16-PST,1094;000000000001 Mail-from: MIT-ML rcvd at 9-Apr-80 1033-PST Date: 9 Apr 1980 1001-PST From: Zellich at OFFICE-1 Subject: MSGGROUP#1514 Contact Query NLS8.5/L10 Language [Conversion] To: [SRI-KL]liaison-sndmsg.txt:, MsgGroup at MIT-ML, To: Human-Nets at MIT-MC The Management Information Systems Division of the Army Automated Logistics Management Systems Activity is interested in talking to anyone who is running NLS 8.5, either in a stand-alone environment or on the ARPANET. We are also interested in contact with anyone programing in the L10 language, particularly with any experience in converting L10 programs to C or PASCAL. Please send any responses to me, rather than replying thru any of the groups in the distribution of this message. Thanks, Rich Zellich [My apologies to MsgGroup and Human-Nets people collectively - I KNOW they aren't the correct forums for this type of query, but we wanted to assure a wider distribution than just the Network Liaisons because of the many isolated projects that can be found at many sites.] ------- 25-Apr-80 22:44:05-PST,1053;000000000001 Mail-From: MIT-ML rcvd at 23-Apr-80 2124-PST Date: 24 April 1980 00:04 est From: Frankston at MIT-Multics (BOB at SAI-Prime) Subject: MSGGROUP#1515 Worldmail Sender: SALawrence.SoftArts at MIT-Multics To: msggroup at MIT-ML Message-ID: <800424050437.863077 at MIT-Multics> Original to: msggroup at mit-ml Now that GTE/Telenet is attempting to sell electronic mail to the masses, an Tymnet is also making such noises and STC (Source telecomputing, nee Telecommunications Associates or somesuch) it is important to start to look at the issues of interchange of mail between the various networks and what can be done about standards. Admittedly, I've been making these noises for a long time and haven't done anything concrete myself, but it doesn't look like we have much more time in which we can watch passively and hope things will turn out right. All of our previous sins are about, within the next year or two, to become institutionalized. (This is an approriate place for biblical comments about sowing and reaping). 25-Apr-80 22:44:05-PST,450;000000000001 Mail-From: MIT-ML rcvd at 24-Apr-80 0533-PST Date: 24 April 1980 08:25-EST From: "Marvin A. Sirbu, Jr." Subject: MSGGROUP#1516 Worldmail To: Frankston at MIT-MULTICS, msggroup at MIT-ML The National Bureua of Standards has hired some of our own MSGGROUP members at BBN to draft a standard for exchanging messages between computer-based message systems. Would someone from BBN like to comment on what they are doing? 25-Apr-80 22:44:05-PST,682;000000000001 Mail-From: MIT-ML rcvd at 24-Apr-80 2244-PST Date: 24 Apr 1980 2227-PST From: POSTEL at USC-ISIE Subject: MSGGROUP#1517 re: world mail To: msggroup at MIT-ML some of you may recall RFC 753 from about a year ago. It described a structured data mail delivery system. since then we have done a little experimenting, and now are preparing a revised version of the specification. i would like your comments, especially on the ability of the current proposal to support "worldmail". The current draft is in the file MPM-DRAFT.TXT on ISIE. This file may be copied via FTP using the FTP username ANONYMOUS and password GUEST. --jon. ------- 25-Apr-80 22:44:06-PST,823;000000000001 Mail-From: MIT-ML rcvd at 25-Apr-80 0133-PST Date: 24 Apr 1980 2355-PST Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1518 Re: Worldmail From: STEFFERUD at OFFICE-1 To: MSGGROUP: Message-ID: <[OFFICE-1]24-Apr-80 23:55:11.STEFFERUD> In-Reply-To: Your message of 24 April 1980 08:25-EST IFIP has a Working Group 6.5 doing something in this area. I have an electronic copy of the report from their March 1979 Workshop in Montreal, for those who want it. It runs 23 TENEX pages. I will take orders from all who want a copy via ARPANET mail, and will also plant a copy for FTP ACCESS. I will announce the file location and name after I get it planted. Best - Stef PS: Note that I have rigged the address fields of this message to prevent accidental sending of requests to the whole group. S/ 25-Apr-80 22:44:06-PST,1604;000000000001 Mail-From: MIT-ML rcvd at 25-Apr-80 0846-PST Date: 25 Apr 1980 1055-EST Sender: DDEUTSCH at BBN-TENEXA Subject: MSGGROUP#1519 A follow-up to Marvin Sirbu's message From: DDEUTSCH at BBN-TENEXA To: MsgGroup at MIT-ML Cc: DDeutsch, msg-fmt Message-ID: <[BBN-TENEXA]25-Apr-80 10:55:09.DDEUTSCH> Reply-To: Msg-Fmt As Marvin Sirbu pointed out, NBS has contracted to BBN for the development of a message format standard. Work has just gotten started. No final decisions have been made. The goal is to produce a standard for message syntax and semantics. We are not defining anything having to do with message transport, nor does NBS expect the definitive answer to how to do addressing. The standard will define what a message and its components are, and how to represent them. Thus its scope is somewhat similar to RFC 733. It is important that the standard avoid "repeating the sins of the past" and that it look forward to future advances in the field. It is also important that the standard be acceptable to the vendors of commercial computer based message systems. This means that the standard will probably have to be simpler than RFC 733. ("Simpler", in this case, means "more austere".) It also means that it will have to be extensible in order to be able to support the sort of things which can be done with RFC 753 messages. We'd appreciate your thoughts and suggestions. Please do not send them to me; my mailbox has reached alarming proportions. Instead you should send messages to MSG-FMT@BBNA, which is the project's brand-new mailbox. Debbie 25-Apr-80 22:44:06-PST,57788;000000000001 Mail-From: OFFICE-1 rcvd at 25 April 1980 22:26-PDT Date: 25 April 1980 22:26-PDT From: Stefferud at OFFICE-1 Subject: MSGGROUP#1520 IFIP WG6.5 Montreal Workshop Report To: MSGGROUP at USC-ECL 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT ABSTRACT: This report of the March 1979 IFIP Working Group 6.5 Workshop, held on March 1-2, 1979 at the Hyatt Regence Hotel in Montreal, Canada has been prepared for IFIP by Einar Stefferud, Ronald Uhlig, David Farber and Ian Cunningham. It does not necessarily represent the positions of any of the attendees or their institutions, but it does represent an attempt to summarize and synthesize an integrated description of the issues that were identified and discussed in the workshop, and which are involved with evolution and development of international computer message services. IFIP WG 6.5 is chartered to concentrate on standards for data structures, addressing, and higher level protocols to effect international computer mediated message services. Page 0 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT TABLE OF CONTENTS Page Number INTRODUCTION....................................................2 SUBGROUP ISSUE LISTS............................................4 USER ENVIRONMENT.............................................4 SYSTEM ENVIRONMENT...........................................4 POLICY ENVIRONMENT...........................................4 QUESTIONS RAISED................................................5 GENERAL CMS ENVIRONMENT DISCUSSION..............................7 CMS USER ENVIRONMENT DISCUSSION................................10 PRIMARY USER SERVICES.......................................10 ANCILLARY USER SERVICES.....................................11 USER TERMINALS AND COMPUTERS................................11 CMS USER LANGUAGES..........................................12 CMS USER STANDARDS..........................................12 LONG TERM USER EXPECTATIONS.................................13 USER ECONOMICS - COSTS VS BENEFITS..........................13 CMS SYSTEM ENVIRONMENT DISCUSSION..............................15 ARCHITECTURE................................................15 PROTOCOLS...................................................16 SERVICES....................................................17 TRANSFER.................................................17 MEDIATION................................................18 STORAGE..................................................19 RELIABILITY..............................................19 SECURITY & PRIVACY.......................................19 STANDARDS...................................................20 ECONOMICS - COSTS VS PRICES.................................20 CMS POLICY ENVIRONMENT DISCUSSION..............................21 REGULATION..................................................21 TARIFFS.....................................................21 USE OF EXISTING FACILITIES..................................22 SPECIFICATION OF FUTURE FACILITIES..........................22 ECONOMICS - TRADE AND COMMERCE..............................22 APPENDICES.....................................................24 APPENDIX A: ATTENDEES......................................24 APPENDIX B: SUBGROUP PARTICIPANTS..........................25 APPENDIX C: ADDRESSES OF IFIP WG 6.5 CHAIR PEOPLE..........26 Page 1 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT I. INTRODUCTION The IFIP Working Group on "International Computer Message Services" (IFIP WG 6.5) held a Workshop Meeting in Montreal, Canada, on March 1-2, 1979. Ronald Uhlig is Chairman of IFIP WG 6.5 and served as Chairman of the workshop. David Farber served as Program Chairman for the Workshop. The following statement of "AIMS & PURPOSE" is taken directly from the IFIP WG 6.5 Charter: "Computer mediated messaging is a rapidly emerging service area. Messages may be processed, stored, and transmitted between users potentially within the jurisdiction of separate carriers, computer systems, and/or computer networks. Technical, economical, and political issues need to be resolved in order for a viable international computer message service to develop. This Working Group will concentrate on standards for data structures, addressing, and higher level protocols to effect international computer mediated message services. Such a service could impact existing international postal and communication agreements, and economics of the world-wide communication system. These issues will also be studied in conjunction with appropriate IFIP 'Working Groups'." The purpose of the IFIP WG 6.5 Montreal Workshop was to identify and discuss issues related to Computer Message Systems and to set the stage for future work. The following sessions were held: Introduction (R. Uhlig) Scope and Models (I. Cunningham) Functions and Facilities (J. Pickens & D. Davies) Economics (E. Stefferud) Addressing & Protocols (D. Crocker, J. Postel, N. Naffah, Mike Schroeder) Regulatory Issues (G. Edwards, Bill McLean, P. Walker, R. Pye) Experiments & Experiences (D. Farber) Discussion & Organization of Work (Attendees) Page 2 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT At the end of the meeting it was decided to organize activities of Working Group 6.5 for the next year into three broad categories (USER ENVIRONMENT, SYSTEM ENVIRONMENT, and POLICY ENVIRONMENT) for consideration by subgroups. GENERAL ENVIRONMENT issues are to be considered by the whole Working Group 6.5. Initial lists of issues for each subgroup to consider were identified and three subgroups were formed. Subgroups and International Co-Chair people are: USER ENVIRONMENT: Donald Davies - Europe Elizabeth Feinler - North America SYSTEM ENVIRONMENT: Najah Naffah - Europe Ian Cunningham - North America POLICY ENVIRONMENT: Gwen Edwards - North America Roger Pye - Europe Page 3 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT II. SUBGROUP ISSUE LISTS USER ENVIRONMENT Primary services Ancillary services Terminals and Computers Languages Standards Economics - Prices vs Benefits SYSTEM ENVIRONMENT Architecture Protocols Services Transfer Mediation Storage Reliability Security & privacy Standards Economics - Costs vs Prices POLICY ENVIRONMENT Regulation Tariffs Use of existing facilities Specification of future facilities Economics - Trade Page 4 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT III. QUESTIONS RAISED A collection of questions was complied from the discussions and reviewed during the final session. The questions did not always fall easily into exclusive subgroup domains. They are listed below with tags appended to indicate which committees might be primarily concerned. 1. What is, or is not, a "message?" (USER) (SYSTEM) 2. What group(s) should (will) supply technical standards for CMS? (POLICY) 3. In what ways do privacy techniques conflict with: (1) Transborder data flow policies? (POLICY) (2) Transport mechanisms? (SYSTEM) (3) Economic feasibility? (USER) 4. Should CMS be a regulated service? (POLICY) (1) Should it be universal? (2) Who should supply the service? (3) What should be included in the service? 5. What should be the interface between message composition/reading software and the transport mechanism? (SYSTEM/USER) 6. What architecture should be assumed for CMS? (SYSTEM) 7. What methods are available for provision of privacy, authentication, and signature services? (SYSTEM) 8. What vocabulary should be used in discussing CMS? (USER) (POLICY) 9. What are "junk electronic messages" and how can we deal with them? (USER) 10. How can "naming problems" be minimized? (SYSTEM) 11. What message structure and contents are needed for transport? (SYSTEM) 12. How should different languages and alphabets be dealt with? (SYSTEM) 13. What user composition/reading/filing services are desired? (USER) Page 5 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT 14. What is the relationship among: (POLICY) (1) International Postal Services, (2) Electronic Funds Transfer, (3) Common Carrier Services, and (4) existing or planned communication services? 15. What is an office? (USER) (1) What is an automated office? (2) How does CMS fit in? 16. What are the business needs for CMS? How will these affect: (1) Development of services? (USER) (2) Development of standards? (SYSTEM) The remainder of this report is organized according to the chosen subgroup categories and initial issue lists. Discussions held during the workshop are reported under the appropriate subtitles. Page 6 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT IV. GENERAL CMS ENVIRONMENT DISCUSSION The appearance of computer message services is a natural outgrowth of technology advances and the convergence of communication and computer technologies. The new services arose out of the need in early time-sharing computer systems to communicate among users and operators in the course of interactive computing sessions. Since their inception computer message systems have expanded beyond the bounds of single computers to become more ubiquitous. In various current networks of computers, large numbers (thousands) of individuals and agencies are able to communicate among themselves via message exchange using many different computers and terminals in the process. Computer Message Services use communication mechanisms to deliver message texts from senders to receivers. When the receiver is using a different computer than the sender, then an inter-process communication path must be set up to allow the two computers to accomplish the message text transfer between them. Sometimes the sender and receiver collaborate directly to establish the communication path between their separate computer file systems. In other cases, certified computer system programs with special access privileges are used to copy a designated message text from the sender's private file space to the receiver's private file space without direct involvement of either party. In at least one current computer network, the message text transfer mechanism is manifested as a file transfer process that operates according to a file transfer protocol for interprocess communication. In general, any communication channel between sender and receiver can provide this functional capability if their computers and terminals can be made to use it. The end-user product of Computer Message Service is typewritten communication between individuals. This end result is much the same as with traditional record carrier message services, except that delivery consists of placing electronic copies into computer files which allows the power of a computer to be applied to them. The receivers then have the option to display and process their messages in various ways. Delivery of an electronic copy in place of a printed paper copy is what distinguishes computer message systems from traditional record carrier systems. Page 7 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT This difference may seem small and perhaps inconsequential, but it appears to have profound impacts on the future of record communication systems, and on the ways people might use message services in the conduct of business. Much is heard about office automation which involves use of electronic filing systems and electronic computing devices in offices to store and process information. The natural consequence of these office automation efforts will be to interconnect the coming proliferation of computing devices for message communications. The prospect of interconnection of large numbers of computers for international message communication must pose a threat of revolution for established record carriers who are faced with finding ways to deal with an uncertain future. They must retain a place for themselves in the future message service marketplace, and they must protect their current capital investment. It seems clear that the advent of computer networks with their high speed data links and flexible transport protocol capabilities must threaten to significantly impact record communication systems. Thus the problems to be solved are far greater than those of new system design or interactive user interface design. We must find an acceptable evolutionary path that will continually advance existing message system facilities into the future to help provide computer message services on a broad international scale. In summary, we have so far identified the general environment in which fledgling computer message services must develop and mature. It is to the task of searching for and finding satisfactory ways that IFIP WG 6.5 is dedicated. Among the problems, we find wide disparities between regulatory policies in different countries, difficult interfaces among old and new communication networks, and incomplete understanding of the required functional behavior of message processing systems. All of which must be dealt with in the face of dramatic advances in converging computer and communication technologies. To help understand the issues and develop solutions, we need models to provide frameworks for our discussions. We need models for user environments, for service definition, for systems architectures, for communication paradigms and protocols, for economics, for tariffs and regulation, for international relations and trade, for interactions among all these, and for many other aspects of the computer message services domain. Models are needed to simplify descriptions, partition problems, develop terminology, and identify needed capabilities. Page 8 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT At this general level of discussion, our tentative CMS model consists of people who enter information into computers for processing, and who then want to transfer their information to others for communication purposes. The model includes the cases where message texts are to be moved between different computers via some communication facilities, and between computer file systems that are controlled by different individuals or agencies. It includes mechanisms that can copy text from a sender's file space to a receiver's file space, either under joint simultaneous control of the sender/receiver pair, or under control of a third party delivery agent which picks up posted message texts and delivers copies of them to receivers by correctly interpreting attached addresses for receivers' electronic "mailboxes." Our tentative CMS model assumes that the senders and receivers will have the option to apply any available computation to files in their possession. Clearly this tentative general CMS model needs extensive expansion and refinement. It will be the work of the IFIP WG 6.5 subgroups to refine our tentative model, develop subsidiary models, and postulate solutions to the problems. USER ENVIRONMENT discussions will focus on the actions and processes invoked by users in the context of entering, editing, sending, receiving, filing, retrieving, displaying and processing messages with their computers. User Environment models are generally based on interactive computer system concepts. Productivity and end-use functionality issues will dominate. SYSTEM ENVIRONMENT discussions will focus on the design and construction of systems and facilities to meet user functional requirements, and will focus on issues of interfacing to, and utilizing, existing facilities. System Environment models are generally based on computer networking concepts. Architectural issues and standards will dominate. POLICY ENVIRONMENT discussions will focus on issues of transnational interfaces, network interfaces, regulation, tariffs, and transition from existing facilities to new more functional facilities. Policy Environment models are generally based on international relations concepts and on economic marketplace concepts. Political issues must be faced here along with the technical issues. Page 9 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT V. CMS USER ENVIRONMENT DISCUSSION User Environment models are generally based on interactive computer system concepts. The user is expected to interact with CMS systems through interactive terminals connected to computers which are in turn connected to message transport networks. There is no particular size requirement for CMS user system computers, other than the capacity required to meet CMS transport interface standards. A. PRIMARY USER SERVICES Primary user services will include message ORIGINATION, SENDING, TRANSPORT, RECEIVING, FILING, RETRIEVAL, and other PROCESSING by means of user accessible systems of various kinds, located in diverse places, and connected through various communication networks. Technical design and access constraints should be minimized. Choices among user systems and services should be left open to consumer choice as may be governed by national, local, and private interests. ORIGINATION includes all forms of data entry, editing, and formatting. From the functional point of view, origination should be allowed for virtually any facility with the capacity to properly interface to CMS transport facilities. Large and small computers, word processors, TWX and TELEX terminals should somehow be useable for origination. There should be no particular limit or constraint on the functionality or variety of origination systems, as long as they comply with established CMS standards and protocols. SENDING, TRANSPORT, and RECEIVING will require accessible, reliable, secure, and authenticated delivery systems. Third party delivery agents will need to be certified in these regards, and direct collaboration between send/receive pairs will require verification of identities. Technological constraints on access to transport facilities should be minimized, and access to CMS systems should be as ubiquitous as national and local policy might allow. FILING, RETRIEVAL and other PROCESSING, as with ORIGINATION should be possible for virtually any facility that is able to properly interface to CMS transport facilities. Messages should be able to flow into personal correspondence files, transaction processing systems, institutional data banks, or any other kind of information processing systems that the receiver may choose to use. TWX and TELEX printers must be accommodated. Page 10 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT Over all, it will be desirable in the user environment to integrate all these services under a single operating system. Users will need to be able to send and receive from the same system. that they use for ORIGINATION, FILING, RETRIEVAL and other PROCESSING. Indeed, the capability to send, receive, and process messages may become a requirement for all computer systems. B. ANCILLARY USER SERVICES Ancillary CMS services include a variety of things such as name and address directories, mailing assistance, accounting, billing, etc. Address verification and routing determination will be valuable services in the complex future world of interconnected networks, as will charge determination and auditable billing for prepaid and postpaid deliveries. Ancillary services should be available to users through their interactive terminal systems, so that they might verify addresses as they are attached to an outgoing message, or obtain cost information before posting a message for delivery. The entire user environment is expected to be based on interactive computer systems with communication network connections. It is natural to expect these systems to use their network connections for access to ancillary services. C. USER TERMINALS AND COMPUTERS In the General CMS User Model, terminals connected to computers will provide the primary user interface. Terminals will be used to enter message contents into computer files, and terminals will be used to examine received messages by selecting them from their "mailbox" file for display, or for other processing. The computer will serve as a user controllable message text buffer between the terminal and the message transport facilities. Users may enter messages into computers and edit them there before handing them over to the transport mechanisms. Received messages may be delivered into computer message files for later retrieval and examination. Sending and receiving need not require the active presence of any users or their terminals since the computer operating system can interface to the message transport network on their behalf. Page 11 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT None-the-less, it is not intended from the user environment perspective to force delivery to be made to a computer file on behalf of a possibly absent receiver. Delivery to CMS network connected terminals which print received messages on paper should be acceptable on some regular basis. Conversely, it is required that delivery to an absent receiver's files is also a regularly available delivery process. D. CMS USER LANGUAGES The expected user population is extremely large and varied. It would seem important to be able to cater to the full variety of applications and user disciplines. Given the expected size of the market, there should be no need to constrain users to any particular set of CMS user interface languages. The user environment will be a consumer oriented retail market environment where taste and style will be important. User interface languages are important aspects of style, and user interface style can be a vital factor in operational performance. For every discipline there are special languages. Witness the variety of hand calculator "languages" and recognize that CMS users will exhibit an even broader range of applications, even though they will be using their different user interface languages to send and receive messages though a common CMS network. E. CMS USER STANDARDS There are two main needs for standards in the user environment, even though users tend to abhor standards. One is at the message transport network interface and the other is in the message content and format. These standards are needed to attain the desired ubiquity for CMS. The vast variety of different users in different countries speaking different languages and working in different disciplines using different user interfaces will need to adhere to some minimum format and content standards if they are to exchange messages via some common transport network. They will also have to adhere to standards for the content of their messages to allow receiving computers to correctly interpret the content. Certain fields of each message will have to adhere to format standards. Development of these standards will require consideration of both user and system environment issues. Page 12 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT Among the payoffs that users will expect from standards will be regular ways to represent the full alphabets of different languages and disciplines to enable communication in every possible language. In return for conformance to CMS standards, the users should see an expanded range of communication and greater ease of access to, and use of, CMS facilities. F. LONG TERM USER EXPECTATIONS Computer Message Services that handle textual information represent an early manifestation of the convergence of computers and communications. In the long term, with continued technology advances and continued convergence, CMS should expand to handle voice, graphics, facsimile, and other forms of data in CMS facilities. The expectation is that users, with appropriate equipment, should be able to send and receive messages that "contain" all these forms of information. G. USER ECONOMICS - COSTS VS BENEFITS In the user environment, economic issues are dominated by questions of "cost/benefit." Will the customer derive enough benefit from use to justify purchase of the service. In the long term, we must ask whether CMS can be and will be viable as a competitive service. Since Computer Message Services are not yet well defined, it is difficult to answer this question in advance. Instead we must ask what kinds and levels of end-user service will promise to make CMS viable in the international marketplace. CMS appears to promise the following kinds of communication benefits: Connectivity among individuals and agencies with access to CMS. Those who have access will be able communicate through the CMS facilities with others who have access. As the number of connected individuals and agencies grows, the value of being connected will grow. Evidence of this value can be seen in the ubiquitous TELEX/TWX service, which derives great benefit from having a large number of terminal nodes installed in every nation. This same kind of value is evidenced where voice telephone service is widely available. The same can be said for regular postal services which serve large populations. The key source of value lies in the range of easily addressable potential communicants. Page 13 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT Mobility of information under individual or agency control. With access to CMS, users will be able to move information from their computers to other CMS users, and thus be able mobilize their information and deploy it as may be needed. Potential ease of controllable movement will provide important benefits. This raises the issue of security and privacy. Information value can be diminished by undesired disclosure or unauthorized access, as by enemies, or competitors, or even innocent misdelivery. One key to user values derived from mobility lies in the ability of an individual or agency user to control the delivery of information sent through the CMS facilities. Page 14 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT VI. CMS SYSTEM ENVIRONMENT DISCUSSION System Environment Models are generally concerned with architecture and with the protocols and interface standards for interactions among components and modules, initially cast in terms of services to be delivered by the system. Workshop discussions identified the following list of system services: TRANSFER, MEDIATION, STORAGE, RELIABILITY, SECURITY and PRIVACY. The desired CMS System Architecture was seen to combine these service facilities to provide an interface to user environment facilities for sending and receiving computer messages. A. ARCHITECTURE Workshop presentations identified the following kinds of components: computers, terminals, communication links, communication processes, interprocess interfaces, message transport mechanisms, file systems, user interfaces, computer operating systems, message delivery mechanisms, address interpreters, routing mechanisms, security controls, encryption mechanisms, accounting systems, directory data bases, mailboxes, computer networks, record carriers, etc. Now the question becomes one of deciding how to organize the collection of such things into a workable system to provide international computer message services. Discussions led toward a conclusion that the architecture for CMS should be open to accommodate the widest possible kinds of user facilities, and thus provide a solid technical basis for CMS to become ubiquitous. The system architecture should also accommodate existing message system interconnection, and facilitate utilization of existing message system facilities. Except for identification of probable components and general notions of architectural constraints, the workshop did not develop specific architectures or models. A number of concepts were presented calling for modular separation among send/receive processes, actual transmission processes, and user processes. Such an architecture demands distributed processing and decentralized control, which would appear to be appropriate for an international system based on distributed ownership and operation of facilities. Further development of architectures and models was left to the SYSTEMS ENVIRONMENT Subgroup. Page 15 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT B. PROTOCOLS Protocols are the syntactic and semantic procedures used between components of a distributed system to provide linkages and interfaces among the modules which collectively perform the service functions to be delivered by an application system, in this case CMS. Since CMS protocols would control communications across both vendor and organizational boundaries, agreements on standards for protocols to support CMS are essential if service ubiquity is to be realized. Various protocols were discussed in the workshop, ranging from research proposals for inter-network computer message services, to the developing CCITT standards and protocols for TELETEX services. ARPANET message systems, based on file transfer protocols were discussed, and it became clear that currently operational ARPANET mechanisms do not represent the desired protocols for an international CMS system, though ARPANET experience has been quite valuable. Another developmental protocol was described which uses the dial telephone network, (and might utilize any available communication channel) to establish a message transfer facility between computers, but it it was presented as an interesting expedient solution for near term implementation. It was recognized that messaging protocols utilize basic data transfer mechanisms such as generalized inter-process communication, file transfer, and virtual terminal services. The issues in these areas have been under study by IFIP WG 6.1 for a number of years and work on developing international standards is in progress in ISO (Open Systems Architecture) and CCITT (Layered Models Of Public Data Network Service Applications) and it is presumed that these would provide the underlying mechanisms for message transfer etc. The development of message architectures and models by the Systems Environment sub-group should lead to the identification of specific protocols for message services that need to be standardized by either CCITT or ISO or both. Page 16 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT C. SERVICES 1. TRANSFER Transfer services would be provided by implementation of protocols in distributed intercomputer processes to achieve delivery of "posted" messages through some communication link between sending and receiving computers. Transfer processes might operate as directly invoked user processes, or as background processes not requiring direct involvement of either the sender, the receiver, or their terminals. Transfer might use simple links for proximate computers, or complex internet links for distant computers. Distance in this context must be measured in terms of the available network paths rather than geographic distance. Although discussion showed no inherent reason why transfer services should not also allow delivery of messages to relatively low capability terminals such as the new TELETEX or older TELEX terminals, delivery to computers was considered essential to any CMS. Likewise, origination and sending from low capability terminals could not be disallowed. Delivery to a computer would typically mean that the receiving computer creates a file copy of the message for retrieval by the user upon request. In concept, the CMS delivery process would deliver to a "mailbox" in a computer and the user would poll the computer mailbox for new arrivals. Discussion brought out problems with routing of transfers across multiple networks, through gateways or other facilities. One of the basic difficulties here had to do with naming confusion. Gateways have taken on specific technical meaning in the development of internet protocols, and IFIP WG 6.5 would like to avoid conflicting use of terms. During discussion, the term "message transfer station" was coined for use to identify the mechanism for transferring messages across internet boundaries. Transfer services were seen to require end-to-end control of transfers to assure proper delivery to the intended addressees. Page 17 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT Addressing structures of several messaging systems were described. The discussion noted a need to clearly differentiate between the notions of name, address and route. In addition, researchers were reaching the conclusion that it is architecturally important to differentiate between naming-addressing aspects of the transfer service and the structure and contents of a message. The notion was introduced of a property list (somewhat analogous to a postal envelope) which is to be available to both the transfer facilities and to the message recipient and is guaranteed to be accurate. This property list should be used by USER ENVIRONMENT processes for REPLY generation and other functions that critically depend upon accurate information about addresses, postmarks, identification numbers,, etc. This distinction between "envelopes" and "contents" is essential for generalized message services where the contents may not contain any addressing data. eg. pictures, programs etc. 2. MEDIATION Mediation services are needed to allow interfacing among diverse and often incompatible terminals, computers, networks, and services. Voice telephone and TWX/TELEX connections leave mediation to be done by the connecting devices when they are not naturally compatible. Some networks such as TYMNET, TELENET, DATAPAC, TRANSPAC, and PSS (among others) provide mediation among diverse terminals and HOST computers through the net, but they do not yet provide universal mediation for all possible computers and terminals. And these networks do not currently provide general mediation services between incompatible computers for file transfers or message transfers. The ARPANET provides, in a research environment, a greater array of mediation services than most other networks, and thus ARPANET experience has been important in developing the concepts. However, as with any artifact of research, the ARPANET does not generally provide a good example of how to implement any specific service function. Instead, problems discovered from ARPANET experience will more often point to better ways to implement in successor systems. Additional complexities are seen for mediation services in trying to mediate between foreign language alphabets, and foreign languages in general. A companion problem of similar complexity will arise from the need to accommodate older existing message facilities and terminals. Page 18 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT 3. STORAGE Storage services in the CMS systems would serve several functions. One is to hold messages enroute to their destinations, either while being transmitted, or while backed up waiting for a channel to open. Other purposes might be to provide archival storage for authentication, or for long term storage. In certain cases, encryption keys might need to be held in CMS systems storage for an encryption system to serve a large public. Other uses would include public directories such as the name/address data bases. 4. RELIABILITY Reliability services are needed for rather obvious reasons. If users are to become dependent on CMS services, then the service must be reliable in terms of guaranteed delivery, continuous operation, ability to accommodate to address changes, adapt to alternate routing when channels are blocked, etc. And when all else fails, the CMS systems must notify the sender of failures, or at least provide such notice when requested by the sender. To provide these functional services, CMS will need to use redundant communication channels, adaptive routing schemes, error control mechanisms, end-to-end transfer control, and provide records of deliveries. Some form of sender authentication should be included, but workshop discussion led to the notion that CMS should probably use "out of channel" communications to provide positive authentication at acceptable costs. There is some evidence that stringent requirements for absolute authentication of senders might involve only a small fraction of CMS messages. 5. SECURITY & PRIVACY There were Workshop presentations and discussions on encryption mechanisms aimed at security and privacy, including transmission of "signatures" and other forms of authentication. By and large, encryption schemes were characterized as relatively expensive on the one hand, and of somewhat uncertain future guarantee against cracking on the other. Most schemes depend on computational difficulty for their protection against code breaking, and there has been a history of mathematical breakthroughs to render some schemes relatively insecure. It is impossible to know when in the future someone will achieve another breakthrough to short cut the computational complexity of other schemes. Page 19 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT Another problem with encryption for security and privacy stems from the problem of key establishment and distribution. Various schemes for public keys and other means for handling keys were discussed, but no conclusions could be drawn for CMS system designs. This is not to say that encryption is useless or pointless. Instead, it seemed clear that use of encryption should be limited in CMS to those situations where its high cost can be justified. None-the-less, security and privacy remain serious problems. Some national governments insist on the privilege of inspection for electronic message transmission, and there exist legal requirements to disclose to some governments, any keys used to encrypt electronically transmitted information. D. STANDARDS System environment standards are needed to achieve interoperability among the diverse distributed processing modules that will make up an international message system. Standards are needed in the areas of transfer facility interfaces, naming & addressing, dates, content structures and formats. Recommendation X.121 proposes an international numbering scheme for public data networks. Interoperability here means that the sent and received messages should be computer processable by both parties and by the transfer facilities between them. At present, most of the standards effort is focused on text messages, but it is clear that future developments will soon need efforts focused on mixed media including voice, facsimile and graphics. E. ECONOMICS - COSTS VS PRICES SYSTEM ENVIRONMENT economics are basically a profitability question. Can the required kinds and levels of service be provided at acceptable prices using system facilities that will yield acceptable profits (or losses)? Cost factors include terminals, computers and communications, plus security, reliability, ubiquity, etc. Page 20 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT VII. MS POLICY ENVIRONMENT DISCUSSION A. REGULATION The regulatory policy environment appears to be quite complex due to wide variations in prevailing attitudes and practices in different countries. The USA allows interconnection to public telecommunication networks while other countries do not. In some countries, communication utilities are combined with the regular postal service in the form of government owned and operated PTTs. Even the meaning of the word "regulation" is different from one country to the next. And, in the USA there is movement to rewrite the entire basis of regulation with legislative action to facilitate competition. This means that regulatory attitudes and actions regarding CMS will be hard to predict. A great deal of education may need to be done, with a great deal of negotiation to follow. Emergence of CMS at this time will add to the difficulty of sorting out the issues, and it will be sensible to make CMS part of the solution rather than part of the problem. B. TARIFFS Tariffs serve more than one role. They provide the means for dividing revenues among international partners, and provide means for controlling the flow of information across international borders. They also provide for subsidies in various forms, and serve to control the kinds and levels of service to be offered in any given state or country. Several models for CMS tariff patterns are available, but it is uncertain which might apply. Postal Service models involve third party delivery agencies of the form envisioned for some CMS services, while the TELEX and Voice Telephone models involve international communication channels as required by CMS. Even Broadcast models have some applicability. The task presented to the 6.5 POLICY ENVIRONMENT Subgroup is to look for some ways to draw a blend of applicable models to form a basis for CMS tariffs. Among the things to be accomplished is analysis of the available models, and comparison of each with the evolving conceptual models of CMS. Page 21 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT C. USE OF EXISTING FACILITIES It is imperative that existing investments in international message communication facilities be protected, while it is equally imperative that CMS facilities be developed, installed, and brought into operation. Thus ways must be found to utilize existing facilities in the evolution of CMS. Policies should be explored for collaboration with the operators of existing facilities. D. SPECIFICATION OF FUTURE FACILITIES Without concurrence among policy bodies among the affected nations and states, it is impossible to foresee full network interconnection of CMS facilities. Somehow a scenario for full interconnection needs to be developed. E. ECONOMICS - TRADE AND COMMERCE With the advent of computer networks, and now the promises of CMS, the information processing industry is beginning to transform itself into a modern mass production, mass distribution, mass consumption industry. Without benefit of computer networks, production of information services has been confined to co-location with local markets. With computer networks,, and with CMS, information service producers may gain access to mass markets, and consumers may gain access to the full range of produced services. In short, CMS is part of a potentially burgeoning international industry, with information serving as the basic commodity, computation serving as the basic engine of production, and communication serving as the basic means of transport. All the benefits of trade can accrue to participants in this new industry structure, if the trading partners can work out a policy framework to facilitate trade. Resolution of the issues will not be easy. Information does not behave like other commodities. For example, use does not necessarily diminish supply, and the value of information may be either enhanced or diminished by disclosure, depending on each specific case. Protection of both private and national interests in information will be important, but it will not be easy to determine how to protect those interests. Page 22 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT As with other cases of industrial transformation from cottage industry to modern industry structures, there will be considerable disruption of the old organizations of capital and labor. This was noted in the discussion about protection of the existing message system facilities and investments. The same concerns must be applied to problems of labor displacement. Policies for accommodation to change will be needed in every sector that will be impacted by CMS, and it is difficult to imagine any sector that might be left out. Page 23 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT APPENDICES The appendices include the list of attendees, tentative subgroup participants, and addresses of IFIP WG 6.5 Chair people. APPENDIX A: ATTENDEES Belgium: Andre Danthine; Canada: George Barker, Gregor Bochmann, Ian Cunningham, Gwen Edwards, Bill McLean, Penny Napke, Dave Twyver, Ronald Uhlig; France: Bernard Gagey, Michel Gien, Jean-Louis Grange', Najah Naffah, Louis Pouzin, Hubert Zimmerman; Germany: H. Fergen; Switzerland: Peter Schicker; UK: Mike Burgess, Donald Davies, Bill Medcraft, Roger Pye, Terence Westgate; USA: Vint Cerf, Lennie Copeland, Ira Cotton, David Crocker, John Day, Debbie Deutsch, David Farber, Elizabeth Feinler, Ken Harrenstein, Ron Kunzelman, Robert Metcalfe, John Peters, John Pickens, Jon Postel, Mike Schroeder, Einar Stefferud, Philip Walker, Shirley Watkins, Jim White. Page 24 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT APPENDIX B: SUBGROUP PARTICIPANTS USER ENVIRONMENT SUBGROUP: Chair: Donald Davies (UK) & Elizabeth Feinler (USA) Tentative Participants: Belgium: Andre Danthine; Canada: Ian Cunningham; France: Bernard Gagey, Jean-Louis Grange'; Germany: H. Fergen; Switzerland: Peter Schicker; UK: Donald Davies, Roger Pye, Terence Westgate; USA: Vint Cerf,Ira Cotton, David Crocker, Debbie Deutsch, David Farber, Elizabeth Feinler, Robert Metcalfe, Mike Schroeder, Einar Stefferud, Shirley Watkins. SYSTEM ENVIRONMENT SUBGROUP: Chair: Najah Naffah (France) & Ian Cunningham (Canada) Tentative Participants: Belgium: Andre Danthine; Canada: Gregor Bochmann, Ian Cunningham, Gwen Edwards, France: Michel Gien, Najah Naffah, Hubert Zimmerman; Germany: H. Fergen; UK: Bill Medcraft; USA: Vint Cerf, Ira Cotton, David Crocker, Debbie Deutsch, David Farber, Elizabeth Feinler, Ken Harrenstein, Robert Metcalfe, John Pickens, Mike Schroeder, Shirley Watkins, Jim White. POLICY ENVIRONMENT SUBGROUP: Chair: Gwen Edwards (Canada) & Roger Pye (UK) Tentative Participants:, Canada: Gwen Edwards, Ronald Uhlig; France: Louis Pouzin; UK: Mike Burgess, Roger Pye, Terence Westgate; USA: David Farber, Philip Walker. Page 25 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT APPENDIX C: ADDRESSES OF IFIP WG 6.5 CHAIR PEOPLE Cunningham, Ian (Co-Chair: System Environment Subgroup) Bell Northern Research PO Box 3511, Station C Ottawa, Ontario, Canada K1Y 4H7 Davies, Donald (Co-Chair: User Environment Subgroup) National Physical Laboratory Teddington, Middlesex, UK Edwards, Gwen (Co-Chair: Policy Environment Subgroup) Bell Canada 25 Eddy Street Hull, Quebec, Canada Farber, David (Chair: Workshop Program) University of Delaware Dept. of Electrical Engineering Newark, Delaware, USA 19711 Feinler, Elizabeth (Co-Chair: User Environment Subgroup) SRI International Network Information Center, J2021 Menlo Park, CA, USA 94025 Naffah, Najah (Co-Chair: System Environment Subgroup) IRIA 78150 Rocquencourt France Pouzin, Louis (Chair: IFIP TC 6) IRIA 78150 Rocquencourt France Pye, Roger (Co-Chair: Policy Environment Subgroup) Communications Studies and Planning Ltd. Circus House 21 Great Pitchfield London, UK W1P 7FD. Uhlig, Ronald (Chair: IFIP WG 6.5) Bell-Northern Research PO Box 3511, Station C Ottawa, Ontario, Canada K1Y 4H7 Page 26 30-Sep-79 IFIP WORKING GROUP 6.5 REPORT OF THE MARCH 1979 MONTREAL WORKSHOP 30 Sep 79 ------- 11-May-80 22:48:54-PDT,1434;000000000000 Mail-from: MIT-ML rcvd at 26-Apr-80 0018-PST Date: 25 Apr 1980 2337-PST Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1521 ABSTRACT of IFIP WG6.5 Montreal Workshop Report From: Stefferud at OFFICE-1 To: MSGGROUP at MIT-ML Message-ID: <[OFFICE-1]25-Apr-80 23:37:12.STEFFERUD> This is the abstract of the full report which has the accession number MSGGROUP#1520, and which is stored in [ECL]MSGGROUP#.1520;1 Requests for copies via ARPANET MAIL should be sent to Stefferud@OF1, or to MSGGROUP@ECL. 30-Sep-79 MARCH 1979 IFIP WORKING GROUP 6.5 WORKSHOP REPORT ABSTRACT: This report of the March 1979 IFIP Working Group 6.5 Workshop, held on March 1-2, 1979 at the Hyatt Regence Hotel in Montreal, Canada has been prepared for IFIP by Einar Stefferud, Ronald Uhlig, David Farber and Ian Cunningham. It does not necessarily represent the positions of any of the attendees or their institutions, but it does represent an attempt to summarize and synthesize an integrated description of the issues that were identified and discussed in the workshop, and which are involved with evolution and development of international computer message services. IFIP WG 6.5 is chartered to concentrate on standards for data structures, addressing, and higher level protocols to effect international computer mediated message services. 11-May-80 22:48:55-PDT,820;000000000001 Mail-from: MIT-ML rcvd at 3-May-80 2120-PDT Date: 4 May 1980 00:10-EDT From: Richard M. Stallman Subject: MSGGROUP#1522 In reply to your message of 3-Jan-80 1715-EDT To: MSGGROUP at MIT-AI I bet you were wondering what message that was! Automatically inserted In-Reply-To fields in replies to my messages would be very useful to me if they could actually tell me what message the reply was for, but I don't want to keep copies of all the messages I send (would be too many) and without them I can't tell much from the date. I suspect a lot of other people must feel the same way: either we know what the reply is about anyway, or the date of the original message is no help. The first line of the text of the original message, or part of it, would probably be a lot more useful. 11-May-80 22:48:55-PDT,12849;000000000001 Mail-from: MIT-ML rcvd at 3-May-80 2327-PDT Date: 3 May 1980 2153-PDT Sender: GEOFF at SRI-KA Subject: MSGGROUP#1523 (LONG) Boston Globe Article on Electronic Mail Subject: Mentions GTE's Telemail, CCA's COMNET, TYMNET's On-Tyme-II and Subject: BBN HERMES. From: the tty of Geoffrey S. Goodfellow To: MsgGroup at ML Cc: JMcKinney at ISI, Roberts at ISI, WGinsberg at ISI, Cc: Cerf at ISI, Kahn at ISI, Lukasik at ISI Message-ID: <[SRI-KA] 3-May-80 21:53:22.GEOFF> Reply-to: Geoff @ SRI-KA Attention: financial editors By Ronald Rosenberg (c) 1980 Boston Globe (Field News Service) BOSTON-Most mornings when Christopher Coulson arrives at his office at MSP Inc., in Lexington, Mass., he reads and answers his messages from as far away as London and Australia or as nearby as down the hall. Afterward, he may ask colleagues about the status of certain reports or sales promotion materials or call a meeting with several company officials. He accomplishes these correspondence chores without combing through a wad of scribbled messages. Nor does he pick up the telephone and call 20 people. His efficiency weapon? An intra-company electronic mail system that requires only one phone call to his ''mailbox'' for his stored messages. Electronic mail is a reality at MSP and a rapidly growing band of companies concerned about more efficient communications. And as electronic mail use increases, so does the number of suppliers. Just last month, for example, GTE introduced a system called ''Telemail,'' which it hopes will gain a share of a market that may grow to the $4.5 billion range by the end of the decade. Here's how electronic mail works for MSP: Coulson has at his desk a video display terminal that, through his telephone, is linked to several worldwide telephone networks. With this one-call system, he can store, send and receive messages to and from the company's London headquarters, as well as worldwide branch offices, without waiting for return calls or gnashing of teeth over having just missed a call. With a flow of terse, electronic messages, there is no need for two people to be available simultaneously to communicate. ''Because of time zone changes, we only had four hours during the business day to reach London from Lexington. But now we can put any problems or questions on file and they can respond to them when they start work, instead of waiting for us,'' said Coulson, manager of communications for the computer software firm. In addition, there are fewer slips of paper to keep track of, since the paperless memos are kept automatically in a sort of electronic file cabinet with catalog headings. It can store one million pieces of inter-office mail, the equivalent of papers that would fill 50 filing cabinets. Coulson says electronic mail has cut telephone usage to London significantly: from 90 minutes daily before the service was installed to approximately 15 minutes once every three days. MSP's traveling salesman carry a portable terminal, which connects to any phone, to receive their mailbox messages. They also can query the Lexington office about sales authorizations, for example, using the terminal, and don't have to wait for the boss to call with a reply. MSP is typical of a relatively small but rapidly growing band of companies using electronic mail. The appeals include better office communications than either the telephone for short messages or the regular postal service: improved speed, lower cost, greater reliability (memos don't get lost so easily) and reduced interruption of productive work. That's the pitch put forth by electronic mail service companies such as Computer Corp. of America (CCA), which developed COMET, the system used by MSP. The small, Cambridge-based firm estimates 5 billion long-distance telephone calls could be replaced annually by nonvocal communications in the United States. Until recently CCA was virtually alone in the market. But big business has discovered electronic mail and, sensing high profits, stands ready to commit untold millions to systems. Prospective supplilers include General Telephone & Electronics, which last month introduced Telemail through its Telenet subsidiary, and Tymnet Inc., the Cupertino, Calif., computer time-sharing firm that has developed On-Tyme-II. Telemail will be on the market beginning July 14, while Tymnet has been available in the past two years, with new capabilities due June 1. Another competitor is Bolt Beranek and Newman Inc. The well-known, Cambridge-based, scientific research firm developed the first electronic mail system, Hermes, for the military more than 20 years ago. It plans to market a commercial version for offices in the near future. Each of the four firms claims significant cost-and-time savings with its brand of electronic mail. Tymnet maintains that placing a business call requires an average of four attempts per caller to get through and exchange information. And although the substance of a message requires only seconds to communicate, a phone conversation typically lasts over five minutes. Then, a redundant follow-up process creates memoes and other written records of the vocal transaction. Millions of dollars in personnel time and paper thus are wasted each year, the company contends. Subscription fees vary, depending on different message usage and terminal-to-system connect time formulas. MSP pays $1,100 per month. but CCA charges smaller subscribers a flat fee of $60 to send and receive an unlimited number of messages for up to 9 hours per month. Of the firm's 700 customers, most send 50 messages, each three to five lines long, per month. Additional time costs $7 per hour. GTE has not yet set its Telemail figures but it is expected to cost approximately $13.50 per hour, with discounts available based on the volume of messages. In many ways it is a copy of CCA's COMET with a few additional capabilities, including acknowledging that a message has been received and arranging for memos to be sent at predetermined hours to selected people. Tymnet service rates are the most involved, depending on the length of time the terminal is connected to the system and the number of characters and messages transmitted. Each message costs between 40 cents and 60 cents. Unlike COMET or Telemail, Tymnet permits users to send material from portable printing terminals directly to a facsimile machine for a paper copy in two to six minutes. More recently, local minicomputer companies, notably Wang Laboratories Inc. and Prime Computer Corp., entered the electronic mail field, announcing plans to sell their computer hardware. Wang's Mailway is a software package enhancement for its word and data processing equipment. It allows Wang users to distribute documents to a number of recipients regardless of their locations as long they use Wang terminals. With 50,000 word processing work stations, the company has a sizable base to market its electronic mail software. Wang is introducing a Mailway version for users of its word processing equipment that permits intermediate storage for ''store and forward'' mail processing. ''Electronic mail won't displace the telephone, but as soon as any comments can be put to writing it will be put on a terminal now instead of vocalized on the telephone,'' says Anthony Mallia, Wang's director of telecommunications. And Prime earlier this month introduced one of the most sophisticated electronic mail systems, one that goes beyond sending and receiving information to individuals or lists. Prime users can annotate received mail, forward or redirect messages, and acknowledge receipt of documents when they are read. The user can maintain a calendar, keep personal and staff schedules, store and access a telephone message log and keep reminders, according to Russell E. Planitzer, Prime's vice president of marketing development. One unique Prime feature prevents a memo from being forwarded to an unauthorized recipient. For example, if a confidential memo is sent from the personnel office to the comptroller's office, the message cannot be printed out or forwarded to someone else-only returned electronically to the sender. Digital Equipment Corp. has been experimenting internally with an electronic mail system at its Maynard, Mass., headquarters and throughout most of its New England operations. It is expected to market an electronic mail system tied to its data communications network system within the next year. Not far behind are IBM, AT&T, Xerox, Hughes, Western Union and Exxon-funded subsidiaries that are developing sopisticated systems tied to satellites as part of broad-based office communications systems. At stake during the 1980s is a flowering of new markets for message services and products. Together they accounted for about $1 billion in revenue in 1979, of which the primary components were communicating word processing equipment, facsimile machines and TelexTWX services, according to a recent electronic mail study by International Resource Development Inc., a Norwalk, Conn., market-research firm. By 1989, the market will quadruple to $4.5 billion, with 50 companies competing for chunks of the rapidly expanding electronic mail market, the study says. ''By any standards, however,'' the report continues, ''the market for electronic mail is risky for the participants and will probably remain so. The actual needs of the future user of electronic mail are still not very well defined, and several of the current market participants are frank about their sketchy knowledge of the expected future levels of demand for products and services that in many cases do not exist today.'' A study by Waltham-based International Data Corp. concurs, adding that a big problem with electronic mail is cost justification. Since many large companies insist on ''hard dollar'' savings before installing anything, they are taking a wait-and-see attitude. The study says many potential customers in manufacturing, petroleum, transportation, banking and insurance question whether anticipated ''soft dollar'' savings are enough reasons to invest heavily in electronic mail. The savings are defined as increased management productivity, better access to information, additional business opportunities and more efficiency. ''This is a question many companies will have to answer during the 1980s,'' the report notes. At Exxon in New York City, these concerns are being studied by Robert M. Dickinson, manager of the oil company's office systems technology. ''Electronic mail is in its infancy and its success depends on changes in the office system where the aim must be to reduce the amount of paper work,'' he said, noting the company is examining many different systems, including CCA's COMET, and GTE's Telemail. ''I don't see us using it on a broad basis until the late 1980s, when we can tie electronic mail to word processing equipment, no matter who makes the equipment. But in the next two to three years a large number of professionals-financial analysts, business researchers in the comptroller's office and data processing people-will have video display terminals and they will start to use electronic mail,'' Dickinson said. Still, the question remains whether corporate executives will take the time to type their messages and learn the new system or be tempted by habit to pick up the telephone. ''Some have a fear of typing, a kind of executive attitude, and they feel somewhat intimidated if a message is sent and they have to reply to it,'' said David J. Horton, GTE's vice president of marketing for the communications network systems. ''But that barrier will come down when he is shown how easy it is to use and how profitable it can become both in time and money saved if he sends just two to three messages per day instead of phone calls.'' Where is the U.S. Postal Service in electronic mail? Solidly committed to it. Initial plans will permit electronic transmission of computer-generated, bulk, first-class mail for delivery through the postal system. A utility company, for example, could transmit monthly bills directly from its computers to customers' district post offices where invoices would be printed out and delivered by the local mail carrier. In theory, both the post office and the sender would benefit by plugging into electronic mail because it promises faster delivery, lower mailing costs and far less manual sorting. ENDIT ROSENBERG ny-0504 0001edt ********** ------- 11-May-80 22:48:55-PDT,747;000000000001 Mail-from: MIT-ML rcvd at 4-May-80 0021-PDT Date: 4 May 1980 0118-EDT (Sunday) From: Richard H. Gumpertz Subject: MSGGROUP#1524 Re: "In reply to ..." To: Richard M. Stallman CC: MSGGROUP at MIT-AI Message-ID: <04May80 011818 RG02@CMU-10A> In-Reply-To: Richard M. Stallman's message of 3 May 80 23:10-EST That is what the SUBJECT field is for! The IN-REPLY-TO field is an extra hint. Use of the first line as a pseudo-subject is a crock. I suppose the first line might be nice if no subject was included, but... My pet gripe in that area is the use of the word "your" when a note is going to many people. At least the "your" should be expanded to someone's name. Rick 11-May-80 22:48:55-PDT,728;000000000001 Mail-from: MIT-ML rcvd at 4-May-80 0037-PDT Date: 4 May 1980 0208-EDT (Sunday) From: Richard H. Gumpertz Subject: MSGGROUP#1525 Smart TTYs To: the tty of Geoffrey S. Goodfellow CC: MsgGroup at MIT-ML Message-ID: <04May80 020833 RG02@CMU-10A> Dear TTY, I someday would like to meet a TTY that can generate all the messages that you do. Where did you get all your training in English? Have you considered acting as the machine end of a Turing test? Were either of you parents desks? Do you ever travel with Geoff? Are you one TTY or a team? I hope you will understand my curiosity -- I don't get to hold many conversations with TTYs. Rick Gumpertz 11-May-80 22:48:55-PDT,449;000000000001 Mail-from: MIT-ML rcvd at 4-May-80 0353-PDT Date: 4 May 1980 0326-PDT From: Mark Crispin Subject: MSGGROUP#1526 "In reply to" To: MsgGroup at MIT-ML Better yet, messages should be sent with subject lines. I don't think it is unreasonable for the ITS mail program to ask for a subject before the message. Several mailsystems (including MM) have features which aren't as useful without subject lines. ------- 11-May-80 22:48:55-PDT,360;000000000001 Mail-from: MIT-ML rcvd at 4-May-80 0854-PDT Date: 4 May 1980 0847-PDT Sender: GEOFF at SRI-KA Subject: MSGGROUP#1527 Re: Smart TTYs From: the tty of Geoffrey S. Goodfellow To: Rick.Gumpertz at CMU-10A Cc: MsgGroup at MIT-ML Message-ID: <[SRI-KA] 4-May-80 08:47:18.GEOFF> In-Reply-To: <04May80 020833 RG02@CMU-10A> Reply-to: Geoff @ SRI-KA Yes. 11-May-80 22:48:55-PDT,1081;000000000001 Mail-from: MIT-ML rcvd at 4-May-80 1003-PDT Date: 4 May 1980 1253-EDT (Sunday) From: Brian.Reid at CMU-10A Subject: MSGGROUP#1528 Re: In reply to your message of 3-Jan-80 1715EDT To: Richard M. Stallman CC: MSGGROUP at MIT-AI Message-ID: <04May80 125307 BR10@CMU-10A> In-Reply-To: Richard M. Stallman's message of 3 May 80 23:10-EST CMU's Rdmail program will use the contents of the in-reply-to field to automatically find the message(s) referred to. It works best when there is a message-id in the In-Reply-To field, but it can use the date and time to search back through the message database to find the message being referred to. This process may be used recursively in either direction to extract a whole question-reply chain. Our view seems to have become that the main purpose of a mail program is as a database manager; its display and editing functions are trivial or else some text editor can be used for them. This feature of "find me the message to which he is referring" is a very simple database function. Brian 11-May-80 22:48:55-PDT,3735;000000000001 Mail-from: MIT-ML rcvd at 5-May-80 1012-PDT Date: 5 May 1980 1242-EDT From: WJN at MIT-DMS (Wayne J. Noss) To: RMS at MIT-AI Cc: MSGGROUP at MIT-AI, WJN at MIT-XX In-reply-to: Message of 04 May 80 at 0000 EDT by RMS@MIT-AI Subject: MSGGROUP#1529 Re: In reply to your message of 3-Jan-80 1715EDT Message-id: <[MIT-DMS].145993> RMS et al, Automatically inserted In-Reply-To fields in replies to my messages would be very useful to me if they could actually tell me what message the reply was for, but I don't want to keep copies of all the messages I send (would be too many) and without them I can't tell much from the date. I suspect a lot of other people must feel the same way: either we know what the reply is about anyway, or the date of the original message is no help. The first line of the text of the original message, or part of it, would probably be a lot more useful. You may see an improvement in the header of this message. At least it tells whose message ("by RMS@MIT-AI") is being replied to, rather than "your message of ...", which is rather unhelpful when mailing lists are involved. I am not aware of a rigorous definition of "In-Reply-To", but I should think it would refer to a minimal, definitive reference to a particular message. In message systems (such as the COMSYS data base on DM) where all messages have serial numbers or other unique identifiers ("Message-ID"'s), "In-Reply-To" should refer to that ID. Nothing more is needed. Replying to Mail-from: systems that send unserialized, un-ID'ed messages (e. g., COMSAT and XX) requires finding some other way of uniquely identifying the message being replied to; hence the date and time. In general, the sender-ID also needs to part of the unique identification, because senders can (and do) send messages at the same time, etc. In short, I think that the functionality supported on this system (MIT-DMS) is a useful and proper one for the purpose of positively identifying the message being replied to. In-Reply-To, in what I perceive to be its supposed semantics, does not pretend to be of any help whatever to users who don't save their outgoing messages. It points to a message so that the recipient of the reply can find and study the actual message referred to. It gives information adequate for the message system, not the human user, to find the message. In my opinion, the proper solution to the problem described is to use the "Subject" field in the header of NEW messages. It is for the human user, not the automated system, and can clearly summarize the ideas presented in the message. Many mail systems automatically generate subject lines for replies, giving reference to the original subject line. I send "Subject" lines on nearly all my messages, and when replies come back, I almost never have to refer to the actual message I sent in order to figure out what is going on. The subject line of the reply refers to my subject line, and so I know what the topic of my message--the one being replied to--was. I notice that many users of the ITSes other than DM do not often use "Subject" lines, probably because :MAIL and :RMAIL don't prompt for them on those systems the way the mail composers on most other systems (including DM and XX) do. I would respectfully suggest the consistent use of "Subject" on new messages, perhaps modifying :MAIL and :RMAIL to make its use more comfortable. If "Subject" is not enough for what we want (a subject identification of a message, especially a reply), a new field should be defined. "In-Reply-To" is already being used for something else. Wayne Noss 11-May-80 22:48:55-PDT,554;000000000001 Mail-from: MIT-ML rcvd at 7-May-80 1257-PDT Date: 7 May 1980 1240-PDT From: MJMARCUS at USC-ISI Subject: MSGGROUP#1530 FCC Decision on 2nd Computer Inquiry To: human-nets at MIT-AI, msggroup at MIT-AI cc: mjmarcus The FCC's decision on the 2nd Computer Inquiry was released in full on May 5, 1980. For the next few weeks copies can be requested by Mail to Consumers Assistance Office FCC 1919 M St.,NW Washington, DC 20554 or by netmail to MJMarcus at USC-ISI. Mike Marcus, FCC Office of Science and Technology ------- 11-May-80 22:48:56-PDT,589;000000000001 Mail-from: USC-ISIF rcvd at 8-May-80 0253-PDT Date: 7 May 1980 1936-PDT From: POSTEL at USC-ISIF Subject: MSGGROUP#1531 New RFC Available To: [ISIF]Request-for-Comments.List: A new RFC is now available in the NIC online library at SRI-KL. RFC 763: Title: Role Mailboxes Author: Marshall Abrams Pages : 1 pathname: [SRI-KL]RFC763.TXT Public access files may be copied from the NIC library at SRI-KL via FTP with username NICGUEST and password ARPA. --jon. ------- 11-May-80 22:48:56-PDT,941;000000000001 Mail-from: MIT-ML rcvd at 10-May-80 0012-PDT Date: 9 May 1980 1227-PDT Subject: MSGGROUP#1532 help and advise from you From: ADPSC at USC-ISI To: msggroup at MIT-ML, msggroup at MIT-AI, human-nets at MIT-AI, To: jmchugh at USC-ECL Cc: adpsc at OFFICE-1, jsharkey at OFFICE-1 folks, we have a problem here at our organization that perhaps someone of you could help us with-- would appreciate any help, advice, etc. that you can provide. PROBLEM: we have a relatively large data base of 2 billion characters resident on a honeywell 66/60. we would like to provide our users with an on-line access capability to this data base in a CHEAP way--speed is not important. we do not want the additional disk drives required because of the costs involved. QUESTION: does anyone know of any existing storage media that will interface with the honeywell?? please send any info to georgatos at isi thank you esther 23-May-80 17:33:55-PDT,1523;000000000001 Mail-from: MIT-ML rcvd at 12-May-80 2311-PDT Date: 12 May 1980 2220-PDT Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1533 ROLE MAILBOXES - full text of RFC763 From: STEFFERUD at OFFICE-1 To: MsgGroup at MIT-ML Message-ID: <[OFFICE-1]12-May-80 22:20:39.STEFFERUD> On reading this RFC and discovering that it was delightfully short and that it raises a proper MsgGroup issue, I dcided to broadcast it directly to the group. I hope it will stimulate some discussion. I took this text from the indicated pathname: [SRI-KL]RFC763.TXT Marshall Abrams NBS 7 May 80 Network Working Group Request for Comments: 763 ROLE MAILBOXES Occasionally it is necessary to send mail to someone on the net who is known only as the incumbent in an official position. Often the mail is undeliverable because of employee turnover. We have also had such a problem at NBS and have therefore created MAIL address synonyms such as SYSTEMS, MANAGEMENT, and LIAISON to ensure that mail is correctly delivered no matter who the incumbent happens to be. I suggest that all systems which permit MAIL address synonyms install them. I further suggest that the NIC or the ARPANet management select a standardized set of synonyms, thus increasing their utility. Marshall Abrams 23-May-80 17:33:56-PDT,388;000000000001 Mail-from: SU-SCORE rcvd at 14-May-80 1942-PDT Date: 14 May 1980 1941-PDT From: Mark Crispin Subject: MSGGROUP#1534 Re: #1533 ROLE MAILBOXES - full text of RFC763 To: STEFFERUD at OFFICE-1 In-Reply-To: Your message of 12-May-80 2220-PDT I am LIAISON@SCORE and SAIL (as well as a bunch of other things) for precisely this reason. -- Mark -- ------- 23-May-80 17:33:56-PDT,595;000000000000 Mail-from: SRI-KA rcvd at 23-May-80 0007-PDT Date: 22 May 1980 1120-EDT From: David Lamb at CMU-10A Subject: MSGGROUP#1535 RdMail manuals To: MsgGroup at MIT-ML Reply-To: RdMail at CMU-10A Message-ID: <22May80 112045 RD00@CMU-10A> Redistributed-To: stefferud at OF1 Redistributed-By: STEF at DARCOM-KA Redistributed-Date: 23 May 1980 The RdMail manuals are finally all gone. For those of you who have received copies, I would be very interested in any comments you might have on the manual. I will be bringing out a revision in the early fall when the new students arrive. 23-May-80 17:33:56-PDT,2107;000000000001 Mail-from: MIT-ML rcvd at 23-May-80 0003-PDT Date: 22 MAY 1980 2345-PDT From: JMCHUGH at USC-ECL Subject: MSGGROUP#1536 Office Automation w/PRIME Computer To: MsgGroup at MIT-ML cc: Hughes.List: "THE MOST PRODUCTIVE OFFICE IN THE WORLD. HERE. NOW." is the title on their brochure. Had heard about PRIMACS, the PRIME computer solution to office automation, but had a chance to see it at the NCC. They are using a 32K Ontel intelligent terminal to obtain a word processing capability (terminal cost is $4,8000). They also offer a dumb terminal (labelled an "executive" terminal) for $2,600 which can perform cursor edit (they claim --- I wasn't able to see it) of one screen at a time (versus one page at a time and horizontal scroll for the other... also no underlining on the executive terminal). The cheaper terminal does not have the nicely placed and labelled function keys of the more expensive Ontel. All in all, they have apparently covered a number of interesting "office automation" functions with an easy-to-use (if bothersome) menu approach, but on quick look have missed some of the functionality that we normally enjoy on ARPANET server hosts. The sales literature notes: WORD PROCESSING * Full Text Editing * Screen Editor * Key Driven / Menu Oriented MANAGEMENT COMMUNICATIONS AND SUPPORT * Electronic Mail * Correspondence Management * Electronic Intray * Calendar Management * Appointment Scheduling * Tickler File ADVANCED TEXT MANAGEMENT * Automatic Proofreading * Hyphenation * Multi-lingual Dictionaries TERMINALS * Administrative Workstation * Management Workstation * Letter-quality Printer It'll probably be a month or two before I get a chance to do a careful evaluation of what they have and don't have. If you want any of that info when it's available, let me know. In the meantime, I'll not bother to keyboard any of the additional sales/press release info unless somebody requests it... Cheers - Jim ------- 23-May-80 17:33:56-PDT,833;000000000001 Mail-from: MIT-ML rcvd at 23-May-80 0154-PDT Date: 23 May 1980 0045-PDT Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1537 Re: #1536 Office Automation w/PRIME Computer From: STEFFERUD at OFFICE-1 To: JMCHUGH at USC-ECL Cc: MsgGroup at MIT-ML Message-ID: <[OFFICE-1]23-May-80 00:45:40.STEFFERUD> In-Reply-To: Your message of 22 MAY 1980 2345-PDT Hi Jim - I detect a bit of confusion. Hope you can clarify it. You say that you saw the PRIMACS system at NCC. It is my impression that PRIMACS is offered by ACS America, to run on PRIME Computers. What I saw at NCC was offered by PRIME, and they told me that it is not the same as PRIMACS. (I expect they might rather I had not mentioned PRIMACS at all, hence we better be careful not to confuse the two separate offerings here in MsgGroup.) Best - Stef 23-May-80 17:33:56-PDT,626;000000000001 Mail-from: MIT-ML rcvd at 23-May-80 0436-PDT Date: 23 May 1980 (Friday) 0724-EDT From: DREIFU at WHARTON (Henry Dreifus) Subject: MSGGROUP#1538 Re: #1537 Stef's RE: PRime/Primacs clarification To: STEFFERUD at OFFICE-1 cc: msgroup at MIT-ML, jmchugh at USC-ECL Prime will sell you PRIMACS, at least our sales Representative is willing to contract to it. I presume that PRIME and ACS are in some kind of deal. Eg: PRIME cannot sell as many 300type computers with out a good WP system, and ACS cannot run a WP system without a PRIME computer. I think they have a good OEM discount schedule as well. /Hank 23-May-80 17:33:56-PDT,604;000000000001 Mail-from: MIT-ML rcvd at 23-May-80 0836-PDT Date: 23 May 1980 (Friday) 1115-EDT From: DREIFU at WHARTON (Henry Dreifus) Subject: MSGGROUP#1539 Possible danger if Micro-wave-orbiting energy is Subject: transmitted? To: msgroup at MIT-ML I am looking for some information in this area, and am very much a non-expert. I would like to know of some of the hazzards of using Microwave energy from orbiting stations in space. It has been pointed out to me that there is a possibility that it would heat up the Earth too much, and we would look like Venus. Any comments? /Hank 23-May-80 17:33:56-PDT,1035;000000000001 Mail-from: MIT-ML rcvd at 23-May-80 1012-PDT Date: 23 May 1980 1250-EDT Sender: POOL at BBN-TENEX Subject: MSGGROUP#1540 Re: #1536 Office Automation w/PRIME Computer From: POOL at BBN-TENEX To: JMCHUGH at USC-ECL Cc: MsgGroup at MIT-ML Message-ID: <[BBN-TENEX]23-May-80 12:50:42.POOL> In-Reply-To: Your message of 22 MAY 1980 2345-PDT Because parts of the Office of Energy Research at the Department of Energy has been exploring "commercially available" office automation capabilities, I have talked with both ACS and local representatives of Prime. Their stories seem to be consistent, namely, Prime invested a (small?) amount of effort to adapt the ACS software to "improve reliability, maintainability, etc" and "bring it to the Prime program product standards so that it could be supported by the Prime field staff". Neither seems to want to discuss future developments in response to questions about inadequate functions. J. Pool, Office of Energy Research, Department of Energy 23-May-80 22:25:27-PDT,1155;000000000001 Date: 23 MAY 1980 1436-PDT From: JTUCKER Subject: MSGGROUP#1541 RE: #1536 PRIME OFFICE To: JMCHUGH cc: MSGGROUP Redistributed-To: msggroup at MIT-ML Redistributed-By: STEFFERUD at OFFICE-1 Redistributed-Date: 23 May 1980 Howdy Jim. While from both your description and the Prime brochures it can be seen that Prime Office Automation offers everything from soup to nuts, I spent considerable time at NCC playing with the word processing and found it basic and incomplete. Certainly not comparable in editing capabilities to say the Wang WPS, Xerox or DEC systems. Even elementary functions such as text reformatting (which they say can be accomplished using their "ruler") were not yet ready. Interesting also to note that if a document is created and then sent to another system user for review, the same document can never be edited. Once it is sent to the Prime (as the Primers called it) it is only avail- able for copying. The same is of course true for all messages. They have got some good ideas. And they have a lot of work to do. Jeff ps: dictionaries weren't available either. ------- ------- 23-May-80 22:25:27-PDT,669;000000000000 Mail-from: MIT-ML rcvd at 23-May-80 1728-PDT Date: 23 May 1980 1710-PDT Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1542 Re: #1539 Possible danger Micro-wave-orbiting... From: STEFFERUD at OFFICE-1 To: DREIFU at WHARTON Cc: msgroup at MIT-ML Message-ID: <[OFFICE-1]23-May-80 17:10:07.STEFFERUD> In-Reply-To: Your message of 23 May 1980 (Friday) 1115-EDT Well, I expect that if the beam got off target it might fry a few mostly innocent folk. Fry? No, I guess it would be more like explode, as in the case of the lady who tried to dry her poodle in the microwave oven. UGH! I would be curious to find out if my expectations are wrong. Stef 23-May-80 22:25:27-PDT,4492;000000000001 Mail-from: MIT-ML rcvd at 23-May-80 1903-PDT Date: 23 May 1980 2128-EDT (Friday) From: Brian.Reid at CMU-10A Subject: MSGGROUP#1543 RE: #1539 Microwaves To: STEFFERUD at OFFICE-1 CC: DREIFU at WHARTON, msgroup at MIT-ML Message-ID: <23May80 212814 BR10@CMU-10A> In-Reply-To: <[OFFICE-1]23-May-80 17:10:07.STEFFERUD> Ah, the subject matter in MsgGroup diverges again. I love it. I think I can help here. With all radiation, the question of danger is a matter of degree. The proponents and opponents of various kinds of radiation (solar, nuclear, microwave, etc) merely don't agree on what constitutes a harmful dose. It's easy to measure lethal doses, as with the apocryphal story of the woman and her poodle, but accurate diagnosis of the effects of sublethal doses of radiation is an art and not a science. The "flavor" of electromagnetic radiation comes from its frequency. The long-wave stuff, like ordinary AM radio and below, we take on faith that it doesn't hurt us too much because we live in a world full of it. As wavelengths get shorter, the ability of the radiation to affect matter in general and bodily tissues in particular varies. If radiation is "absorbed", it generates heat. some radiation goes right through us--radio waves, for example-- and other radiation bounces off--light, for example. The rest is absorbed somewhere in our bodies. Some wavelengths are absorbed almost entirely by the skin--infrared and very high frequency microwaves. Some wavelengths "penetrate" and heat other things. Still other wavelengths are absorbed not by making the molecules vibrate (thermal absorbtion), but by messing around with the electrons or nuclei of the very atoms. Many frequencies of gamma rays have this unhappy property: they ionize or otherwise mess with the construction of the atoms. The microwave ovens that you use to thaw frozen peas and cook soybean burgers use a frequency that has been very carefully selected to excite one of the normal modes of resonance of a water molecule. This means, in effect, that it "locks in" on the water molecules and transmits energy directly to them. The percentage of the generated energy (usually on the order of 100 to 200 watts of effective radiated power) that actually shows up as heat in the food is really high. When you are wondering whether radiation will affect you, the answer is always "yes", but when you are wondering whether the effect will be noticeable, there is no easy answer. Too much infrared from a fireplace will toast you to a crisp. Too much gamma radiation will ionize your brain (many computer hackers already seem to have ionized brains, so this is not a problem). Farmers who live near high-voltage transmission lines swear that too much 60-Hz energy messes up their livestock. Too much sun will make you think Steve Martin is funny. And so on. For each kind of radiation, there is some threshhold below which everything is ok, some threshhold above which nothing is ok, and a big fuzzy gray area in between. Almost all of the radiation to which we are exposed falls in this gray area where we really don't know the score. If the microwave power being beamed down to earth were the same exact frequency that was needed to excite the water molecule, we would be in trouble. If it were beamed down at 60Khz (not exactly micro), then we would have a very hard time collecting it with anything at all. If there were some magic frequency that didn't excite the normal modes of oscillation of any of the molecules in any living beast but also didn't bounce off an antenna back into space, and if the energy per square meter were kept low enough that it didn't ionize, then there would be no problem. The real answer lies somewhere in between, a complex function of energy density, frequency, and period of exposure. For those of you who haven't ^O'd out yet, let me close with the mention that the May 2 1980 issue of @i[Science] magazine contained an article proposing that home heating be accomplished by direct microwave heating of the occupants, rather than the current clumsy indirect scheme wherein the room is heated hot enough to be able to heat the occupants by reradiation. It pointed out that about 1/20th of the energy would be needed, and that those people who found it to be too warm could wear sweaters with metallized threads in them that would cause them to stay cooler. Brian 24-May-80 11:58:23-PDT,841;000000000001 Mail-from: MIT-ML rcvd at 23-May-80 2239-PDT Date: 24 May 1980 00:18 edt From: Sibert at MIT-Multics (W. Olin Sibert) Subject: MSGGROUP#1544 RE: #1539 microwaves Sender: Sibert.SysMaint at MIT-Multics To: msggroup at MIT-AI Another detail about microwaves from space is that all the suggested mechanisms hinge on having the beams be self-aligning in some fashion, so that, when all was well, the beams would be focused on a small area, but if something happened to distract it, the beam would lose coherence, and be spread out over a much wider (several hundred mile diameter) area. This coherence would be maintained by a feedback system between the receiving and transmitting antennas. Therefore, if the beam were to go "off-center", it would simply fall apart, rather than frying anything in its narrow path. 27-May-80 23:12:07-PDT,1727;000000000001 Mail-from: MIT-ML rcvd at 25-May-80 1843-PDT Date: 25 May 1980 (Sunday) 2124-EDT From: MORGAN at WHARTON (Howard Morgan) Subject: MSGGROUP#1545 Re: #1536 Prime Office Automation To: STEFFERUD at OFFICE-1 cc: MsgGroup at MIT-ML Since this is msggroup, I thought I would put in a few points about the message system on the Prime, which I spent about 45 minutes covering in detail at the NCC. It is poor from a network point of view, since addressing is done via 3 letter initials of the people you want. They differentiate between NOTES, which permit you to enter text and send it, and MAIL, where already created documents are sent, without any editing permitted. The capabilities for handling messages when they are received are not as complete as the typical MSG system on the net, which is rather disappointing. They have done a lot of work on the calendar and scheduling system, but again take some poorly thought out shortcuts. If person A requests a meeting time with you, it is called "shadow blocked" and no one else can request the same time until you accept or deny the request. This means that a malicious executive could block most of your time (if he knew you were going away for a few days), and deny you the real choice of meetings typical to office environments. ALso at the show was Four-PHase's OMS/IV Office Management System, which has a cleaner mail system, reasonable text editing, and a calendar tickler file at least as good as Prime's. In addition, some pricing indiicated that PRIME wants at least a 550 to run the Office Automation, and thus it would cost $250K for a reasonable system with 25 stations (some managerial, some clerical). [Howard Morgan] 27-May-80 23:12:08-PDT,810;000000000001 Mail-from: MIT-ML rcvd at 27-May-80 1007-PDT Date: 27 May 1980 0939-PDT Sender: LUNDQUIST at USC-ISI Subject: MSGGROUP#1546 Info on Office Automation From: LUNDQUIST at USC-ISI To: MSGGROUP at MIT-ML Message-ID: <[USC-ISI]27-May-80 09:39:10.LUNDQUIST> Gentlepersons, I have enjoyed the recent correspondence on PRIME and the automated office. Our organization is working on a 'command - executive information system' that will include word processing, calendar schedule management, terminal installation in admin offices, work centers and executive-level offices, electronic mail, etc. I don't want msggroup cluttered up, but if additional information that anyone has could be sent along to myself or SACADOS at ISI, I would appreciate it. Chuck Lundquist 27-May-80 23:12:08-PDT,3042;000000000001 Date: 27 May 1980 1327-PDT From: HARMON at USC-ISI Subject: MSGGROUP#1547 Re: #1539 Biological Effects of Radiation To: MSGGROUP at USC-ECL cc: Harmon Redistributed-To: msggroup at MIT-ML Redistributed-By: STEFFERUD at OFFICE-1 Redistributed-Date: 27 May 1980 The effects of electromagnetic radiation on biological systems can be described by three classes of effects. These are short term effects, long term effects and genetic effects. Most of the work in exploring these effects has been concerned with high energy radiation and includes the effects of atomic particles as well as photons. This focus of interest has been governed by the impact of widespread nuclear energy conversion interests. More recently there has been considerable interest in lower energy forms of EM radiation (i.e., transmission line radiation, microwaves, VLF and ELF). Short term radiation effects include such effects as radiation sickness, burns, etc. Long term effects include such effects as cancer, reduced reproductive power and long term mental effects. In general, long term effects are not manifested immediately after exposure (rather years later). Further, the effects of prolonged exposure to low levels of radiation are classified under long term effects. Genetic effects are not manifested by the organism that was exposed to the radiation. Rather, these effects become apparent (i.e., measureable) only in the generations propagated by the exposed organism (though the situation may be complicated by continuing exposure of the suceeding generations). The characterization of radiation effects is made extremely difficult by the complexity of the biological systems in which we are interested. Detailed modeling of the situation of radiation interacting with biological materials is still in a relatively primitive state. Short term effects are the best characterized (for all forms of radiation). Long term and genetic effects are much less amenable to study. This situation is complicated by stochastic behavior of the mechanisms. In some respects, this sort of study is like carcinogen effects study and is therefore plagued by most of the problems being experienced by the cancer research people (e.g., the infamous sacchrin studies). This is just more information on the aspects of just determining if and what the effects of microwave radiation on biological systems are. This field reminds me all too much of the types of traps which exist in the nuclear energy controversy. Intelligent examination of the critical issues of the biological effects of radiation requires understanding of considerable technical detail to avoid the pitfalls (and the traps set by partially informed special interest groups) which lead to misconceptions. Beware! There has been more study on this topic in the efforts related to Solar Power Satellite. I will look at the literature from this effort for more information. Scott ------- ------- 27-May-80 23:12:08-PDT,1244;000000000001 Mail-from: MIT-ML rcvd at 27-May-80 1754-PDT Date: 27 May 1980 (Tuesday) 2030-EDT From: DREIFU at WHARTON (Henry Dreifus) Subject: MSGGROUP#1548 Office automation. To: msgroup at MIT-ML In my wanderings of the past few weeks I have faltered between nine or ten different systems, and have come to the conclusion: Micro-processors are currently capable of handling the simple office things that I would want to see in my office. Mini-computers are about 1 to 2 years from readyness. They provide a more promising solution to the classic OA problems. They are also more suited for intelligent distributed systems. Micro's are not that advanced to do complex file and transaction managment, filing, multiple storage and retrieval data base support, NETwork mail, and so forth. Large Systems: There are some subsets of just about everything that I would want to use in my OA system spread out over the net, The DOVER at MIT, the Nice terminals at the Pentagon, the photocomposer at CMU, and so forth. But... that does not work too well for some reason... cant seem to figure that one out... In any case, I would watch the MINI market for about 1 year from now, it will not look at all the same! Hank Dreifus 27-May-80 23:12:08-PDT,1257;000000000001 Mail-from: MIT-ML rcvd at 27-May-80 1931-PDT Date: 27 May 1980 1914-PDT Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1549 Re: #1546 Info on Office Automation From: STEFFERUD at OFFICE-1 To: LUNDQUIST at USC-ISI Cc: MSGGROUP at MIT-ML Message-ID: <[OFFICE-1]27-May-80 19:14:29.STEFFERUD> In-Reply-To: <[USC-ISI]27-May-80 09:39:10.LUNDQUIST> As the "Coodinator in Chief" of MsgGroup, I would like to take this opportunity to ask whether we should shift our focus to office automation in general, as a natural expansion from the message systems orientation that we have had for the last five years? (Yes! Count them, five whole years!) It is my opinion that the ARPANET provides the best available prototypical office automation environment, one that contains all the required facilities, elements, functions, and features somewhere or other around the net. I use a wide variety of systems on different hosts to get my work done. I truly use the network as my electronic office, which is somewhat remarkable because I am working as a mangement consultant, rather than as a computer or network technician. Unless we hear some serious disent, we should consider this change of focus to be a fait accompli. Cheers - Stef 27-May-80 23:12:08-PDT,625;000000000001 Mail-from: MIT-ML rcvd at 27-May-80 2008-PDT Date: 27 May 1980 (Tuesday) 2256-EDT From: MORGAN at WHARTON (Howard Morgan) Subject: MSGGROUP#1550 Re: #1549 MSGGROUP changing focus To: Msggroup at MIT-ML I agree wholeheartedly with Stef that we should accept our destiny and let all office automation be within the Msggroup purview. I, too, conduct large amounts of my work via various network facilities, and often describe the "office of the future" to groups as already existing within the net framework. So by all means let's continue discussions such as the recent one on the Prime OA stuff. [Howard] 5-Jun-80 15:07:08-PDT,6235;000000000000 Mail-from: MIT-ML rcvd at 28-May-80 0201-PDT Date: 27 MAY 1980 2339-PDT Sender: MSGGROUP at USC-ECL Subject: MSGGROUP#1551 SURVEY [ECL]MSGGROUP#.1501-1550 From: MSGGROUP at USC-ECL To: MsgGroup at MIT-ML Message-ID: <[USC-ECL]27-MAY-80 23:39:27.MSGGROUP> MSGGROUP#1501 SURVEY [ECL]MSGGROUP#.1451-1500 6153 chars 23 March 1980 2005-PST (Sunday) From: MSGGROUP at USC-ECL MSGGROUP#1502 Re: Line lengths and columnated text 3162 chars 23 Mar 1980 2026-PST From: Zellich at OFFICE-1 MSGGROUP#1503 Re: Line lengths and columnated text 2777 chars 24 Mar 1980 11:02 PST From: AHenderson at PARC-MAXC MSGGROUP#1504 Self-formatting messages 1412 chars 24 Mar 1980 1456-EST From: DDEUTSCH at BBN-TENEXA MSGGROUP#1505 Re: Line lengths and columnated text 1045 chars 24 March 1980 16:15-EST From: "Marvin A. Sirbu, Jr." MSGGROUP#1514 Contact Query NLS8.5/L10 Language [Conversion] 1094 chars 9 Apr 1980 1001-PST From: Zellich at OFFICE-1 MSGGROUP#1515 Worldmail 1053 chars 24 April 1980 00:04 est From: Frankston at MIT-Multics (BOB MSGGROUP#1516 Worldmail 450 chars 24 April 1980 08:25-EST From: "Marvin A. Sirbu, Jr." I think the term "office automation" is at once too broad and too narrow for the charter of MsgGroup. The MsgGroup ought to broadly focus on issues relevant to computer generation, manipulation, and transmission of messages. One of the real mistakes is to consider that a message system is an isolated entity. In fact, one expects that messages will be used in conjunction with other tools and facilities and should be naturally integrated into a complete environment for the processing of text and data. But, there are nevertheless aspects of office automation that are pretty distant from issues related to messages. Taste and judgment rather than any sort of strict rules should be the determinant of whether something is appropriate for the MsgGroup, and we ought to take kindly to rather far removed discussions if somebody considers that they are worth presenting to the MsgGroup. However, I think we ought to still say that our focus is on issues related to computers and messages. The field of office automation is too narrow. Messages are used in other context than what people normally associate with the office environment. A substantial community of users for message systems is the command and control community and while many of the procedures may be reminiscent of the procedures in an office, there are also important aspects of that environment that have no relation at all to the office environment. Men communicate for a large variety of reasons in a wide variety of circumstances and we should not narrowly constrain ourselves to any one subset of that universe of communications. So here's a vote against a change of focus and a vote for a very wide latitude in interpreting what falls within the purview of MsgGroup. 5-Jun-80 15:07:08-PDT,1085;000000000001 Date: 29 May 1980 0055-PDT Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1553 Re: Info on Office Automation From: STEFFERUD at OFFICE-1 To: Gaines at RAND-UNIX Cc: MSGGROUP at MIT-ML Message-ID: <[OFFICE-1]29-May-80 00:55:39.STEFFERUD> In-Reply-To: Your message of 28 May 1980 at 1017-PDT Thanks Stockton for your careful comments. I concur with your assessment and suggestion. I see the new focus as being wider as you propose it, but your clarification is very helpful. From my ARPANET experience, I find that office automation should mean the application of computer networking and computer mail facilities to all kinds of work in all possible locations. Office Automation does not belong exclusively to the Word Processing Industry any more than to the TWX Switching Industry or the ADP Systems Industry. It belongs to the integration of all these, which to this date has only been demonstrated in these hallowed ARPANET halls. And, to me, COMPUTER NETWORK MAIL is THE KEY ADDED INGREDIENT. So to further set our new context - Onward! Stef 5-Jun-80 15:07:08-PDT,1328;000000000001 Mail-from: MIT-ML rcvd at 29-May-80 1957-PDT Date: 29 May 80 21:58-EDT (Thu) From: Farber at UDel-EE Reply-to: Farber at Rand-Unix Subject: MSGGROUP#1554 Call for Papers IFIP Symposium Computer Message Systems To: msggroup at Mit-Ml Message-ID: <80149.79137.1570 @ UDel-EE> Call for Papers IFIP TC-6 International Symposium on Computer Message Systems Montreal, Canada 6-8 April 1981 Computer mediated messaging is a rapidly emerging new service area on the international scene. Messages may be processed, stored, and transmitted bewteen users potentially within the jurisdiction of separate carriers, computer systems, and/or computer networks. This will be an international symposium aimed at promoting interchange of information and discussion on technical, economical, and political issues. Papers are desired from all topic areas. Papers must be received by 30 Sept 1980 for consideration. Papers will be reviewed, and authors will be notified by Nov 1980 regarding acceptance. The Program committee members for North America are: David Farber - USA Ronald Uhlig - Canada Complete copies (not abstracts), in 4 copies should be sent to: Ronald P. Uhlig, BNR Ltd. Dept 3D20, Box 3511, Station C, Ottawa, Canada KIY 4H7 5-Jun-80 15:07:08-PDT,1008;000000000001 Mail-from: MIT-ML rcvd at 5-Jun-80 1216-PDT Date: 5 JUN 1980 1152-PDT To: MSGGROUP at MIT-ML From: Hathaway at AMES-67 Subject: MSGGROUP#1555 Request for ideas on textbooks I will keep this short, since it is really not a MSGGROUP topic. I am looking for recommendations on a book or books to be used as texts in a one-quarter course on "computer commincation networks." The course is at the graduate level and is software oriented; I do NOT want to get into modems, modulation, etc. I DO want to cover procotolc heavily, however, at all levels: transmission, error re- covery, flow control, connection, character data, graphics, message systems, etc. In other words, all the way from bits to applications, with particular emphasis on SOCIAL applications (mail, EFT, etc.). The last time (two years ago) I used Green and Lucky with numerous handouts, with limited success. Any ideas would be VERY much ap- preciated! Please reply to HATHAWAY@AMES-67. And thanx! Wayne. ------ 5-Jun-80 15:07:08-PDT,536;000000000001 Mail-from: MIT-ML rcvd at 5-Jun-80 1308-PDT Date: 5 Jun 1980 1246-PDT From: POSTEL at USC-ISIF Subject: MSGGROUP#1556 Re: Request for ideas on textbooks To: Hathaway at AMES-67, MSGGROUP at MIT-ML cc: POSTEL In response to the message sent 5 JUN 1980 1152-PDT from Hathaway@AMES-67 Wayne: Two suggestions: "Computer Networks and their Protocols" Davies, Barber, Price & Solomonides. Wiley, 1979. "A Practical View of Computer Communications Protocols" McQuillan & Cerf. IEEE Tutorial , 1978. --jon. 12-Jun-80 15:28:02-PDT,1266;000000000000 Mail-from: MIT-ML rcvd at 6-Jun-80 2127-PDT Date: 6 Jun 1980 2104-PDT Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1557 [Walsh: BUDGET TECHNIQUES IN NON-PROFIT ORGANIZATIONS] From: STEFFERUD at OFFICE-1 To: MSGGROUP at MIT-ML Message-ID: <[OFFICE-1] 6-Jun-80 21:04:39.STEFFERUD> Although we tend to think of technical matters as dominating our office automation and message system concerns, it is clear to me that funding strategies must be developed and adopted. So, I am passing this along to see if anyone out there can help Bill Walsh find what he is looking for. Best - Stef Begin forwarded message Date: 6 Jun 1980 1915-PDT From: Walsh To: STEFFERUD at OFFICE-1 Cc: WALSH at OFFICE-1 Subject: BUDGET TECHNIQUES IN NON-PROFIT ORGANIZATIONS STEF -- I AM NOT SURE AS TO WHETHER THIS IS A PROPER SUBJECT FOR MSGGROUP BUT I WILL RELY ON YOUR JUDGEMENT TO PASS IT IF YOU APPROVE. I AM SEEKING REFERENCE MATERIEL ON BUDGET TECHNIQUES USED IN NON-PROFIT ORGANIZATIONS TO BUILD A CONCEPTUAL FRAMEWORK FOR ALTERNATIVE OFFICE AUTOMATION SYSTEMS DESIGN PROPOSALS. IF THERE IS ANYONE WHO HAS HAD A SIMILAR EXPERIENCE, I WOULD APPRECIATE HEARING FROM THEM. REGARDS, BILL WALSH End forwarded message 12-Jun-80 15:28:02-PDT,2134;000000000001 Mail-from: MIT-ML rcvd at 10-Jun-80 0850-PDT Date: 10 JUN 1980 0822-PDT To: MSGGROUP at MIT-ML From: Hathaway at AMES-67 Subject: MSGGROUP#1558 Results of textbook information request This is a report on the results of my request for information on textbooks for a course on "computer communication networks," with emphasis on software protocols and social applications. The request went out to MSGGROUP and HUMAN-NETS on June 5. I have so far received 18 responses, with 14 making specific recommendations on books and 6 requesting that I prepare a summary of what I hear (which is what you are reading ...). The recommended books are: Computer Networks and Their Protocols Davies, Barber, Price, and Solomonides; Wiley, 1979 (7 recommendations) A Practical View of Cmputer Communications Protocols McQuillan and Cerf, IEEE Tutorial Series, 1978 (3 recommendations) The Network Nation Starr Roxanne Hiltz and Murray Turoff (2 recommendations) Advances in Computer Communications and Networking Wesley Chu, 1979 Communications Technology and Social Policy Gerbner, George, Larry Gross, and William Melody (eds.) Computer-Communication Network Design and Analysis Mischa Schwartz, Prentice Hall, 1977 Queueing Systems Computer Applications (Vol II) L. Kleinrock, 1976 Technical Aspects of Data Communication Digital Press Telecommunication Transmission Handbook Roger Freeman Toward Paperless Information Systems F. W. Lancaster "Doll's book on computer communications" "All of James Martin's books" "one forthcoming later this year by Tannenbaum, Prentice Hall" Arpanet protocol handbook DEC DNA architecture series IBM SDLC series The following journals were also recommended: IEEE Transactions on Communications, April 1980 On-Line Review (has published three bibliographies) Proceedings of the IEEE, November 1978 All in all, a very interesting and valuable exercise. Thank you to all who participated. Wayne H. 7-Jul-80 23:14:36-PDT,5074;000000000000 Mail-from: MIT-ML rcvd at 25-Jun-80 1153-PDT Date: 25 JUN 1980 1053-PDT From: JMCHUGH at USC-ECL Subject: MSGGROUP#1559 Correspondence Mgmnt Sys [quote] To: MsgGroup at MIT-ML ---Quote from Management Information Systems Week, 5/21/80 As Volume Grows at Boeing CORRESPONDENCE SYSTEM TO EASE FLOW By Caroline Young SEATTLE --- Boeing Commercial Airplane Co. is improving correspondence flow in its customer-support engineering department with the installation of an in-house "Correspondence Management System" (CMS), Dean Muncey, customer-support supervisor, said last week. The CMS is designed to ease handling of a correspondence volume increasing by 12 percent per year. It logs letters, telegraphic messages, service reports --- any kind of correspondence from customers or Boeing field engineers --- for short- and long-term storage. The CMS can be used to track correspondence that needs a reply. It also is said to make researching easier. Original listings are stored on microfilm with retrieval capability. Previously, the customer-support department filed correspondence in hard-copy form. When the system is fully operational by the end of the year, two other parts will have been added. A special subsystem will track items logged by field engineers that need follow-up action. When this is completed, the information will be printed and then wiped out of the computer's memory to conserve storage space. The computer will also be connected to another computer in the company for sending telegraphic messages to other offices. Muncey declined to give the system's cost, but said Boeing will break even when "we see we are able to handle more work with the same number of people." The department, which hasn't hired additional employees, has to prove to Boeing management "within the next couple of years" that the system is a good investment, he added. BELIEVED FIRST-OF-KIND Muncey said he thinks other industries that handle large amounts of paper could use the same kind of system. "This system is not a tremendous breakthrough technically," he said. "All this equipment has been available. What is unique is that this is the first time, to my knowledge, that this kind of system has been put together for use as an office tool." The system will eventually consist of: A Boeing Conversational Terminal Services (CTS) large-scale central computer; an International Business Machines Corp. (IBM) "3033"; 15 Control Data Corp. CRTs; 8 to 10 Control Data printers, and an Eastman Kodak Co. "Oracle Microfilm Retrieval System." The department now has six CRTs and six printers. Boeing had originally planned to use a minicomputer in the CMS, but later decided to stay with the IBM 3033 because "we felt our own large-scale could do the job," Muncey said. In using an in-house computer, the customer-support department didn't have to worry about hiring a person to maintain and operate the system. Instead, the department uses Boeing CTS personnel. Boeing spent two years researching the correspondence problem, and set up a committee to study automated office equipment. It also called in an outside consultant, Katherine Ascher of Arcadia Associates, to do the conceptual design. "All the committee really did was verify that automated equipment could be used. We really didn't need a computer expert at that time. We needed someone versed in the management and office techniques and Boeing didn't have anyone like that," he said, explaining why Ascher was called in. DESIGNED BY BOEING UNIT Boeing's computer services department did the actual design and installation of the CMS. Installation started at the beginning of this year. Muncey has been involved with the CMS project since its conception. "I am what you might call the 'operational architect,'" he said. "I knew how we operated in customer support. The prime ingredient was to design the system around our operations, not to have to change what we were doing to accommodate the computer." The system is working well so far, he said, although there have been a few minor problems. For example, if a piece of correspondence required a reply, it was waste of the operator's time to retrieve the original listing and note the date on which a reply was sent. Instead, the computer was reprogrammed to update the information automatically, saving time and money. Employees have to be trained to use the equipment correctly. Muncey said he demonstrated the system for management people and visiting field representatives. The operators received more specialized training. "We designed the system to be as simple as possible, but there is some selling involved," he said. "People are scared of computers. We have to make them understand that this is only a tool and it won't disrupt their whole routine." "When it's all in and working, it will be a relief. Right now, it's a pain in the neck sometimes," he said. ------- 7-Jul-80 23:14:36-PDT,625;000000000001 Mail-from: USC-ISIF rcvd at 13-Jun-80 1747-PDT Date: 13 Jun 1980 1526-PDT From: LINDA at USC-ISIF Subject: MSGGROUP#1560 RFC 764 Now Available To: [ISIF]Request-for-Comments.List: RFC Announcement A new RFC is now available in the NIC online library at SRI-KL. RFC 764: Title: Telnet Protocol Specification Author: Jon Postel Pages : 15 pathname: [SRI-KL]RFC764.TXT Public access files may be copied from the NIC library at SRI-KL via FTP with username NICGUEST and password ARPA. --jon. ------- 7-Jul-80 23:14:36-PDT,900;000000000001 Mail-from: MIT-ML rcvd at 18-Jun-80 1246-PDT Date: 18 Jun 1980 1152-PDT Sender: BERTAPELLE at USC-ISI Subject: MSGGROUP#1561 Info on Office Automation From: BERTAPELLE at USC-ISI To: SROSS at MIT-XX Cc: LUNDQUIST, MSGROUP at MIT-ML Message-ID: <[USC-ISI]18-Jun-80 11:52:30.BERTAPELLE> Sandor, I am answering for Chuck Lundquist, who works in this office also. We are also interested in trying to characterize the things that are going into "office automation workstations". We are currently doing an initial design of an Information System for the Strategic Air Command headquarters. We are looking for what is available "off-the-shelf" to help us leverage our personnel and time. So far we have not received anything that has not been sent to the Msgroup. We will try to summarize any particulars that we get for the Msgroup. Tony Bertapelle (BERTAPELLE at USC-ISI) 7-Jul-80 23:14:37-PDT,608;000000000001 Mail-from: USC-ISIF rcvd at 18-Jun-80 2137-PDT Date: 18 Jun 1980 2107-PDT From: POSTEL at USC-ISIF Subject: MSGGROUP#1562 RFC 765 Available To: [ISIF]Request-for-Comments.List: A new RFC is now available in the NIC online library at SRI-KL. RFC 765: Title: File Transfer Protocol Specification Author: Jon Postel Pages : 70 pathname: [SRI-KL]RFC765.TXT Public access files may be copied from the NIC library at SRI-KL via FTP with username NICGUEST and password ARPA. --jon. ------- 7-Jul-80 23:14:37-PDT,900;000000000001 Mail-from: MIT-ML rcvd at 3-Jul-80 1816-PDT Date: 3 JUL 1980 1800-PDT From: JMCHUGH at USC-ECL Subject: MSGGROUP#1563 How does OA change managers? To: MsgGroup at MIT-ML ---Quote from article titled "Office of the Future" by John J. Connell from THE EXECUTIVE May 1980 [ Words are capitalized for my emphasis. -jm- ] . . . a number of the new office technologies can improve managerial and professional productivity. However, their usage raises one of the key behavioral issues in this new field. In those FEW cases where managers have used advanced technology, they have changed their approaches to the handling of their assignments, IN WAYS THAT HAD NOT BEEN ANTICIPATED. THEY LITERALLY MANAGE DIFFERENTLY. . . . ------- Does anyone have any pointers to info on HOW they manage "differently"? ---Jim ------- 7-Jul-80 23:14:37-PDT,690;000000000001 Mail-from: MIT-ML rcvd at 7-Jul-80 0832-PDT Date: 7 Jul 1980 0748-PDT Sender: BERTAPELLE at USC-ISI Subject: MSGGROUP#1564 Re: How does OA change managers? From: BERTAPELLE at USC-ISI To: JMCHUGH at USC-ECL Cc: MsgGroup at MIT-ML Message-ID: <[USC-ISI] 7-Jul-80 07:48:51.BERTAPELLE> In-Reply-To: Your message of 3 JUL 1980 1800-PDT Jim, There is an article in the 24 June 1980 issue of The Wall Street Journal on this topic. The title is "Computer Choler: Many Managers Resist 'Paperless' Technology For Their Own Offices". This article addresses your comment in a slightly different way but it is appropriate, I think. The article is on page 1. Tony Bertapelle 7-Jul-80 23:14:37-PDT,17485;000000000001 Mail-from: MIT-ML rcvd at 7-Jul-80 1744-PDT Date: 1 Jul 1980 0234-PDT From: Feinler at SRI-KL Subject: MSGGROUP#1565 ARPANET NEWS from DCA Dear Liaison, Maj. Haughney of the Defense Communications Agency (DCA) has asked me to distribute the following ARPANET newsletter to all of you. Will you please pass it on to administrators and systems people who may not otherwise see it. Send questions and replies to DCACODE535@ISI. Thanks. Jake --------------------------------------------------------------------- GENTLEPERSONS: There are several changes forthcoming to the ARPANET over the next couple of years which will have considerable impact upon the ARPANET community. Since you, the liaisons, are the primary point of contact for users, DCA believes that it is a good idea to keep the liaisons better informed of actions that will affect you and your users over the next few years. To achieve this goal, DCA will publish a network newsletter which will provide management and technical information and guidance to you, the liaisons. This net message is DCA's first newsletter. Future newsletters will be provided through the ARPANET on an as needed basis. Widest dissemination of pertinent information contained in this newsletter to ARPANET users by the liaisons is requested. Maj. Joseph Haughney DCA --------------------------------------------------------------------- ANEWS-1 DCA Code 531 1 July 1980 (DCACODE535@ISI) (202) 692-6175 ARPANET NEWSLETTER --------------------------------------------------------------------- Over the past eleven years, the ARPANET has grown considerably and has become the major U. S. Government research and development communications network. The ARPANET liaisons have made significant contributions to the network's success. Your efforts are voluntary, but are critical to successful operation of each Host, IMP, and TIP. Your continued support of the ARPANET is greatly appreciated and will facilitate continued smooth ARPANET operation. To aid you in performance of your duties, DCA will attempt to provide you with the latest information in network improvements. This information is grouped into two major areas: management and technical improvements. However, a brief discussion of where we are going with the ARPANET is in order. The ARPANET is still a rapidly growing network. It provides a service which is both cost and operationally effective. We predict the ARPANET will grow to approximately 100 nodes by 1983, when we will begin transferring some of the subscribers to DOD's AUTODIN II network. While the ARPANET is quite successful, it does have some problems. The basic hardware and software are becoming obsolete. The nodes use minicomputers developed in the 1960s which no longer have sufficient memory and other capabilities to support technical improvements to the network. In addition, the ultimate goal of our planning is to provide for an ARPANET II which will be a virtual network and make use of several different physical networks (e.g. AUTODIN II, residual ARPANET, and commercial networks to provide interconnectivity between users while still maintaining network transparency. This goal is subject, as usual, to cost, schedule and technical constraints. The meshing of our immediate problems with our long term goal has produced the following course of action. The ARPANET will be "modernized" over the next three years to eliminate immediate problems. We will also develop the capability to readily transfer ARPANET nodes and users to AUTODIN II, and possibly commercial networks, when this is financially and operationally feasible. Now that we have stated our goal, we will address the various supporting actions that we are undertaking which will have an impact on you, the liaisons. MANAGEMENT ACTIONS ACCESS POLICY The ARPANET is not meant to compete with commercial networks. Commercial networks should be used whenever there is not any requirement to communicate with ARPANET hosts and/or subscribers. There have been some developments in work being done on gateways between commercial networks and the ARPANET. Some hosts have implemented such gateways. However, such interfaces are proscribed unless specifically authorized by DCA. Access problems with internet gateways, as recently evidenced by the illegal access of a Canadian Firm's computer by someone operating a New York high school's computer system through a TELENET/DATAPAC gateway, show that technical problems must still be resolved. Hence, if you have an unauthorized gateway in your Host computer, DCA should be informed immediately, and the gateway terminated or suspended until DCA can review the access controls for gateways. DCA has recently asked the ARPANET Sponsors for a detailed survey of all ARPANET users. This survey information will be added to the Network Information Center (NIC) Identification Data Base. The reason for the expanded data base is to provide an all encompassing description of who, where, and why a user is on the ARPANET. This information will be used for planning to move users onto AUTODIN II and as a validation mechanism for the TIP Log-in program, which we will discuss later. To reduce workload on the liaisons, we plan to send out quarterly updates of the master file which the host and TIP liaison will be responsible for verifying and updating. This report will, hopefully, be initially published in June of 1981. It will replace the TIP inventory report which TIP liaisons now send us. Host systems which do not have any mechanism for managing backside terminal/user validation and verification, should establish procedural or software control mechanisms to obtain the required information. You may wonder why we are placing such emphasis on knowing who is on the ARPANET. When the network was small, a decentralized management approach was established due to the nature of the network and the small community of users. This promoted flexibility and synergy in network use. Now that the network has grown to over 66 nodes and an estimated four to five thousand users, flexibility must be tempered with management control to prevent waste and misuse. The decentralized management of network access and resources is still our objective. We just want to ensure that we can verify proper resource utilization and prevent unauthorized penetrations. We believe that the data base that we are establishing, can be used as a tool for improving your and our management control. We deal in gross quantities, you deal in the particulars. DCA will be publishing a new Host/TIP Liaison Responsibilities letter in July 1980 which will describe these new reporting requirements. TIP LOG IN ARPA has let a contract to Bolt Beranek and Newman, Inc. (BBN) to study and develop, if feasible, a TIP Log-In program and data base. By mid 1982 this effort should, hopefully, result in a means to directly control access to TIPS. The design will take into account the problems encountered with a previous TIP Log-in effort made on the ARPANET several years ago. The present design suggests an approach where a user would log into a TIP when he wants access to the network. The TIP would transmit the log-in information to a regional data base node, which would verify the user and validate to the TIP that that user is allowed network access. In some cases, this may result in a double log-in, depending upon the host password system design. The regional data bases would be updated on a daily basis from a master data base. This data base would be constructed based on a permission tree structure where permissions are delegated down the tree. For example, a sponsor would grant permission to a contract monitor to connect a certain number of users. The contract monitor would then grant permissions for that number of users to a contractor, who would then delegate these permissions to his program manager. The program manager could delegate permissions down to the project leader or the individual users. When the contract is terminated, the contract monitor revokes his permission, which deletes the contractor personnel's access to the ARPANET. The previously-mentioned ARPANET NIC Data Base will be used initially to cross-check the TIP Log-in data base, and hence it's accuracy is critical to preventing valid users from being temporarily without service when TIP Log-in is implemented. The TIP Log-in data base will be managed by the NIC when it becomes operational. The TIP Log-in data base will eventually replace all or part of the NIC data base, depending upon whether or not we are successful in our development effort to incorporate terminals which access the network through hosts into the TIP Log-in software. BBN is also studying the feasibility of applying TIP Log-in mechanisms to host computer users. Hence, host liaisons should also ensure that their terminals and users are included in the NIC Data Base to preclude problems with service, if TIP Log-in is implemented for the Hosts. TIP INVENTORY For TIP liaisons, we have mentioned that we intend to eliminate the TIP Quarterly Inventory and replace it with a NIC Data Base Update. You should be sure of the accuracy of your inputs, because we intend to structure the TIP buffering mechanism to support only those TIP ports which are reflected in the NIC Data Base. All new TIP users will have to have a complete entry in the NIC Data Base and be approved by DCA before these users will be permitted access to the TIP. NOTE: This procedure includes dial-in users. Guidelines for approval and procedures for requesting new user access will be outlined in the new ARPANET Host/TIP Liaison Responsibilities letter which will be sent to you in July 1980 as mentioned above, and the TIP buffering allocation scheme will be enforced as of 1 February 1981. 96 BIT HEADERS DCA recently announced by net note that only 96-bit headers will be accepted by the network nodes as of 1 January 1981. This date still stands. Users, when reviewing the impact of the header change upon them, should also review their applications software to ensure their compatibility with 96-bit headers. We have received some queries from liaisons who did not realize the possible impacts on their applications software of the 96-bit headers. LIAISON MEETINGS In order to improve information dissemination between DCA and the liaisons, we plan to hold a series of one day meetings for liaisons. These meetings will cover the items discussed in this newsletter plus any topics, problems, etc., that the liaisons wish to discuss. These meetings will occur in the Fall of 1980. Tentative scheduling for the meetings are: GEOGRAPHICAL AREA DATE MEETING SITE New England 21 Nov To be determined Washington D.C. 18 Nov DCA Headquarters West Coast 30 Sept Naval Postgraduate School Monterey, Calif Mid West 3 Dec St Louis Area Proposed agenda items, comments, etc., should be forwarded by net mail to DCACODE535@ISI no later than 15 September 80. SPONSOR RELATIONS The ARPANET has Sponsors who represent the various communities of interest found on the network. These Sponsors handle funding and management of community resources. DCA Code 535 attempts to assist the liaisons whenever possible with problem areas and questions that are not resolved by the NCC or the NIC. However, your first point of contact in such situations, should be your ARPANET Sponsor. In some cases, the Sponsor may still refer the liaison to DCA. However, the Sponsor can sometimes handle the situation within his own resources. Such contacts can also keep the Sponsor better aware of the services being provided to his users and enable him to more effectively represent them. In other words, it pays to know your Sponsor and work with him. CIRCUIT FORECASTING AT&T has stated a twelve to eighteen month lead time to provide wideband 50/56KB service. This lead time may be even longer in California. To provide timely service, they have asked us to forecast our requirements as much as possible. These forecasts are not firm orders, but are used by AT&T for planning purposes to estimate such things as modem production requirements and transmisssion overbuilds. If you have, or know of, any new node or high speed VDH requirements which are being contemplated or discussed, please let DCA know immediately. These requirements may just be in the discussion stage and unfunded. However, by including such possible requirements in our forecast, we hope to reduce circuit, and hence node/VDH installation lead times, to a more reasonable time frame. TECHNICAL NEW ARPANET PROTOCOLS The Office of the Secretary of Defense has directed that a set of DOD Standard Protocols be used on all Department of Defense communications networks. This directive applies to the ARPANET. The ARPANET Host protocols will be replaced over the next three years with the new DOD Standard Protocol set. This has a direct impact on host operating systems and some applications programs that use the ARPANET. The ARPANET Network Control Program (NCP) will be replaced by two DOD protocols, the DOD Standard Transmission Control Protocol (TCP) and the Internet Protocol (IP). ARPANET FTP and TELNET protocols will also be updated and standardized. Planning for this transition is still under development. The NIC plans to publish for DCA a new Protocol Handbook by the end of this year, which will provide details on the new protocol specifications. DCA also intends to provide an ARPANET online protocol clearinghouse which will provide a repository for already developed implementations of these protocols and act as a clearinghouse to resolve problem areas and coordinate new protocol implementation development. As soon as the planning is finished, we will publish the details. In the meantime, unless you have already begun development of the protocols, you may want to start budgeting for the protocol software development for your host. NOTE: H316 TIP protocol development is being addressed by an ARPA contract with BBN, and involves a hardware addition to the TIP which will be discussed later. DOD Standard Protocol Development for the PLURIBUS TIP is still being studied as to the most cost and operationally effective way to implement the protocols. C/30 PROCURMENT The new BBN C/30 IMP and TIP can now be ordered. These computers are direct replacements for the Honeywell 316 hardware, and run the existing IMP and TIP software in an emulation mode. The C/30 costs from $20,000 to $35,000 depending upon configuration. These new systems will begin to be installed as new nodes in late fall of 1980. We hope to eventually replace all Honeywell equipment with the C/30s depending, of course, on funding availability. Unless there is a need for a node which requires a large amount of processing power, the BBN C/30 or equivalent will be the only type of node hardware procurred in the future. The C/30 will also be used to support the DOD Standard TCP and Internet Protocol implementation in the TIP. This will be accomplished by removing the IMP software from the H316 TIP and placing it in a C/30. The removal of the IMP software will make room in the TIP for the installation of the programs to support the new and existing protocols in the TIP. All H316 TIPs will require installation of the C/30 IMP to support the DOD protocols by late 1983. DCA will contact the Sponsors when an installation schedule is known. Sponsor's will approve C/30 procurement. However, for those sites which must fund for hardware node procurement, approximately $20,000 should be budgeted in Fy 1981 or 1982, to support procurement of the C/30 Protocol TIP expansion hardware. SUMMARY We have attempted to address items which will have a direct impact on liaisons and their users for the next few years. If you have any questions on these subjects, drop DCA and your Sponsor a net note. Due to the fact that some of our actions are still in the planning and development stage, some of the information that we provided you is nebulous. However, at least, you have an approximate idea of what is planned for the network. We will try to provide the specifics as they develop and incorporate them in our next newsletter. If you have any items that you wish addressed in the next newsletter, please let us know. We will attempt to address them wherever possible. 21-Jul-80 18:43:45-PDT,11427;000000000001 Mail-from: MIT-ML rcvd at 8-Jul-80 0123-PDT Date: 7 Jul 1980 2321-PDT Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1566 ELECTRONIC VS PAPER MEDIA CONTINUA- A COMPARISON From: STEFFERUD at OFFICE-1 To: MSGGROUP at MIT-ML Message-ID: <[OFFICE-1] 7-Jul-80 23:21:39.STEFFERUD> REPRINT FROM 1980 NCC PERSONAL COMPUTING DIGEST Page 1 COPYRIGHT 1980 by the American Federation of Information Processing Societies, Inc. Copying is Permitted without payment of royalty provided that (1) each reproduction is done without alteration, And (2) reference to this Digest and notice of Copyright are included on the first page. The title And abstract may be used further without permission In computer-based and other information service Systems. Permission to publish other excerpts should be requested in writing from AFIPS Press. REPRINT FROM 1980 NCC PERSONAL COMPUTING DIGEST Session: "Networks You Can Access With Your Personal Computer" Chaired by: Clifford Barney - - - - - - - ELECTRONIC VS PAPER MEDIA CONTINUA - - A COMPARISON Einar Stefferud, President, Network Management Associates, Inc. 17301 Drey Lane, Huntington Beach, CA 92647 INFORMATION AUTOMATION TECHNOLOGIES Technologies for information automation may be separated into two classes, depending on whether they provide paper media facilities or electronic media facilities. We need to understand their differences. Paper Media Technologies dominate the current environment. Much of the effort to automate deals with paper. Photocopiers have dramatically improved mobility of information on paper. Facsimile transmission systems move paper images at electronic speeds. Word processing concentrates on paper documents. Electric typewriters improve the quality of printed documents, though typing speeds remain at 50-60 words per minute after 50 years of advancing technology. Micrographics allow compaction of files to a fraction of their paper equivalent volume, and allow handling of pictures and drawings as well as text, but the images are not easily modified because they are recorded permanently on film. Micrographic images are miniaturized paper image copies. Postal systems provide transport for paper, though not always at electronic speeds. It is easy to imagine paper or its equivalent being sent to any part of the earth. Few places are immune to paper intrusion, and we spend great amounts of money on security to restrict its flow. Paper affords extreme mobility and the paper media continuum has few if any discontinuities. Constraints on movement primarily stem from administrative decisions rather than technical constraints. REPRINT FROM 1980 NCC PERSONAL COMPUTING DIGEST Page 2 STEFFERUD: ELECTRONIC VS PAPER MEDIA CONTINUA - - A COMPARISON The pervasiveness of paper media dominates data processing. Recent announcements herald arrival of fast remote printers to serve as electronic document distributors. Facsimile delivers printed paper. TWX delivers printed paper. The fact is that most technology is applied to handling printed paper and its equivalents. Paper media will remain in use until full functional equivalence is available with alternative media. Electronic Media Technologies see new applications every day. Terminals provide remote access to computers and files. Data base systems organize data for rapid query and analysis. Interactive systems make information directly available to those who need it. Networks allow data to move between files in different computers. Text editing and word processing provide for assembly, cutting, pasting, editing, and formatting. In one instance, the ARPANET has proven feasibility of a computer network continuum that is approximately equivalent to what is provided by the paper media continuum. The ARPANET was established by the Department of Defense Advanced Research Projects Agency (DARPA) as an experimental research network of geographically and organizationally separated heterogeneous computers. Using computer interaction protocols, a general purpose file transfer service has been developed for moving data files between computers. A data file in any network connected computer can conveniently and easily be moved to another network connected computer. Network files enjoy real mobility. With an operational File Transfer Process, users found that they could run "background" processes to establish connections and move files while the users were not actively "logged-in." Thus a network mail system was born from coincidence of need and capability. Network mail enables users to prepare texts in their private files and post them for delivery to the addressee's private files. With the ARPANET feasibility demonstration, it is clear that technology advances can lead to an integrated full function computer network continuum. Although all the pieces are not yet assembled, we have seen enough to know that technology will become available at sufficiently low prices. What remains is to work out the necessary system designs. Moving Toward An Electronic Media Continuum Experience with our prototypical networks has surfaced some difficult problems. Some standards and protocols have been developed, but the problems are far from trivial when we consider all the incompatible codes and standards that already exist in the computer-communication industry, and which must be compromised to achieve a common set of standards. REPRINT FROM 1980 NCC PERSONAL COMPUTING DIGEST Page 3 STEFFERUD: ELECTRONIC VS PAPER MEDIA CONTINUA - - A COMPARISON We need to evolve toward the "Electronic World of the Future" without a revolution. In spite of current incompatibilities, pragmatic means must be found for interconnection of equipment to enable movement of data among individuals and systems. We must begin to give mobility to information in existing computer files. We must do something about the fact that paper based information locked in a three combination safe is more mobile than information in a personal computer in an unlocked room. Our current systems are like islands with limited access to the other world. Without the correct interfaces and access privileges, connection to any network is impossible. As some people move into the new medium ahead of others, they will suffer the problems of operating across the boundaries between paper and electronic worlds. They will find network connected people easier to reach than other people, and will tend to narrow their interactions to easily reached communicants. A final problem is that users tend to misunderstand the interpersonal and social consequences of interaction through the new medium. Looking back at the introduction of other new technologies, we find that they were surrounded by disruptions and havoc till people learned to live with them. How many people were maimed or killed before learning to drive with consideration and care? How many lives were disrupted by intrusion of the telephone, by people sharing party lines, or by crank callers? Moving into the new electronic continuum will cause disruptions and require adjustments and accommodations. COMPUTER COMMUNICATION NETWORK CONCEPTS Data networks provide connections among computers and terminals. Connections come in several forms ranging from direct wiring to sophisticated switched and multiplexed networks that can be shared among a number of users. Economics determine which is better in each situation. Steady data flows between specific points over long periods favor fixed wiring. Intermittent bursty data flows favor switched and multiplexed lines. Switching affords flexibility in arrangements. Establishing connections is one thing, and transmitting data is quite another. The distinction is similar to the difference between highways and trucking, tracks and trains, canals and barging. The first does not cause the second. It is relatively easy to establish data communication connections, but transport facilities are not generally available to move data between many of the connectable pairs. Typically, different terminals and computers are idiosyncratic enough to be unable to receive what each other sends. In a terribly literal sense, they are whistling different tunes together. REPRINT FROM 1980 NCC PERSONAL COMPUTING DIGEST Page 4 STEFFERUD: ELECTRONIC VS PAPER MEDIA CONTINUA - - A COMPARISON To receive implies comprehension, according to basic communication definitions, and this requires agreement on the meaning of trans- mitted signal patterns. The development work in computer networking focuses on solving protocol problems. One of the purposes in providing connections is to couple people to their work, their tools, their information bases, and to each other. Terminals provide the primary data interface for connecting people to computers, files, word processors, message systems, etc. Another purpose for connections is to couple systems together to enable information to flow directly among them. REQUIREMENTS FOR THE AUTOMATED ENVIRONMENT The electronic environment must provide the full range of functions that are provided now by paper media facilities. Individuals must be able to receive and send packages of information, be able to file and retrieve information, and be able to process their information, all within an integrated facility providing all the needed tools. The user environment must consist of an integrated facility connected to other local facilities, and to non-local facilities. Information files must be capable of being held private or shared in a controlled manner with others. Information must be potentially transferable among a very large number of individuals and facilities. Connection Requirements. User facilities must provide access to remote resources and tools through network connections. These connections must be usable in regular and convenient ways. Constraints should be reduced to administrative barriers. Mediation Requirements. It must become regular and convenient to communicate between normally incompatible devices through network services that mediate between them. This kind of mediation is one of the services provided by value added data networks. Voice telephone systems do not provide mediation. This leaves the communicating devices on their own to resolve their differences. Transport Requirements. Beyond mediated connections we need file transfer processes. Preferably these will run in "background" with error checking and correcting procedures so we will not have to proof received data or constantly monitor the transfer processes. Mail Requirements. In the ultimate, we need the electronic equivalent of postal services for envelopes of electronic data. We need third party handling so data can be posted and then delivered to addresses imprinted on the envelopes. Until we have true electronic mail in this form, we will not be able to live and work in the electronic media device environment without resorting to paper to achieve mobility for our information. 21-Jul-80 18:43:45-PDT,601;000000000001 Mail-from: USC-ISIF rcvd at 8-Jul-80 2353-PDT Date: 8 Jul 1980 2101-PDT From: LINDA at USC-ISIF Subject: MSGGROUP#1567 RFC 766 Now Available To: "[ISIF]Request-for-Comments.List": A new RFC is now available in the NIC online library at SRI-KL. RFC 766: Title: Internet Protocol Handbook Author: Jon Postel Pages : 2 pathname: [SRI-KL]RFC766.TXT Public access files may be copied from the NIC library at SRI-KL via FTP with username NICGUEST and password ARPA. --jon. ------- 21-Jul-80 18:43:45-PDT,592;000000000001 Mail-from: MIT-ML rcvd at 15-Jul-80 1012-PDT Date: 15 Jul 1980 0940-PDT Sender: GOODWIN at USC-ISI Subject: MSGGROUP#1568 request for msg system info From: GOODWIN at USC-ISI To: msggroup at MIT-ML Cc: goodwin Message-ID: <[USC-ISI]15-Jul-80 09:40:14.GOODWIN> I am looking for information on readily available message systems that will run on a VAX or equivalent sized machine. There is interest in using a msg system as a front end to applications using graphics and data base management tools. A good user interface is a must. Nancy Goodwin MITRE Corp. Goodwin @ISI 6-Sep-80 14:53:31-PDT,3387;000000000000 Mail-from: MIT-ML rcvd at 22-Aug-80 1103-PDT Date: 22 Aug 1980 1320-EDT Sender: LOVETT at BBNA Subject: MSGGROUP#1569 IFIP Symposium From: MYER at BBNA To: msggroup at MIT-AI Message-ID: <[BBNA]22-Aug-80 13:20:51.LOVETT> 1. Commitments are flowing in for papers to be given at the IFIP Symposium next spring, and we need reviewers. If you can review one or more papers, please send me (Myer @ BBNA) your name, mailing address and the number of papers you'd be willing to handle. 2. We'd also like to hear from you if you plan to attend the Symposium, so as to get some idea of the prospective attendance. For any who missed the earlier announcements the call for papers follows. CALL FOR PAPERS IFIP TC-6 INTERNATIONAL SYMPOSIUM ON COMPUTER MESSAGE SYSTEMS Ottawa, Canada 6 - 8 April 1981 Program Committee Chairman, Ronald Uhlig, Canada Andre Danthine, Belgium David Twyver, Canada Najah Naffah, France Klaus Wimmer, Germany Tiber Szentivanyi, Hungary Guiseppe Attardi, Italy Donald Davies, UK David Farber, USA Ted Myer, USA Computer mediated messaging is a rapidly emerging new service area on the international scene. Messages may be processed, stored, and transmitted between users potentially within the jurisdiction of separate carriers, computer systems, and/or computer networks. This will be an international symposium aimed at promoting interchange of information and discussion on technical, economical, and political issues. Papers are desired in the following topic areas: - Naming/Addressing issues - User requirements for message services - System design, protocol and formats - Hardware/Software implementation of message systems - Performance of message systems - Reliability, availability and integrity - Cost/Benefits issues - Centralized vs. decentralized systems - Security requirements and techniques - Authentication and digital signatures - Facsimile messaging - Integration of text, facsimile and voice messages - Electronic mail - Computer conferencing - Teletex - Voice messaging - National and international regulation of message traffic - Relation to office systems - Human factors in message systems - Social impacts of message systems - Implications of computer messaging for developing countries Complete copies (not abstracts), in 4 copies, should be sent to: Ronald P. Uhlig, Bell Northern Research Ltd., Dept. 3D20, Box 3511, Station C, Ottawa, Canada KIY 4H7 Telephone 613/596-2358 Papers must be received by 30 September 1980 for consideration. Papers will be reviewed, and authors will be notified by 30 November 1980 regarding acceptance. For further information please contact Ron Uhlig at above address or Ted Myer (Myer at BBNA) or Dave Farber (Farber at UDel-EE). Ted Myer 6-Sep-80 14:53:31-PDT,721;000000000001 Mail-from: USC-ISIF rcvd at 23-Aug-80 0230-PDT Date: 23 Aug 1980 0154-PDT From: LINDA at USC-ISIF Subject: MSGGROUP#1570 RFC 759 Available To: "[ISIF]Request-for-Comments.List": A new RFC is now available in the NIC online library at SRI-KL. RFC 759: Title: Internet Message Protocol Author: Jon Postel Pages : 79 pathname: [SRI-KL]RFC759.TXT This is a specification for a multi-network computer mail delivery system for structured documents. Public access files may be copied from the NIC library at SRI-KL via FTP with username NICGUEST and password ARPA. --jon. ------- 6-Sep-80 14:53:31-PDT,901;000000000001 Mail-from: USC-ISIF rcvd at 5-Sep-80 2300-PDT Date: 5 Sep 1980 2142-PDT From: LINDA at USC-ISIF Subject: MSGGROUP#1571 RFCs 767 & 768 To: "[ISIF]Request-for-Comments.List": New RFCs are now available in the NIC online library at SRI-KL. RFC 767: Title: A Structured Format for the Transmission of Multimedia Documents Author: Jon Postel Pages : 40 pathname: [SRI-KL]RFC767.TXT This is a specification for a multi-network computer mail document format. RFC 768: Title: User Datagram Protocol Author: Jon Postel Pages : 3 pathname: [SRI-KL]RFC768.TXT This is a reissue of the specification of the user level datagram protocol. Public access files may be copied from the NIC library at SRI-KL via FTP with username NICGUEST and password ARPA. --jon. ------- 28-Sep-80 02:18:24-PDT,490;000000000001 Mail-from: MIT-ML rcvd at 26-Sep-80 0211-PDT Date: 26 Sep 1980 0200-PDT (Friday) From: Lauren at UCLA-SECURITY (Lauren Weinstein) Subject: MSGGROUP#1572 Telenet To: MSGGROUP at ML I am trying to track down organizations who are "Telenet customers". That is, people who either have a host on Telenet, use Telemail, etc. If you fall into this catagory, I would appreciate your dropping me a note so I can ask you a few simple questions. Thanks much. --Lauren-- ------- 28-Sep-80 02:18:24-PDT,746;000000000001 Mail-from: USC-ISIF rcvd at 27-Sep-80 0032-PDT Date: 26 Sep 1980 2232-PDT From: BROWN at USC-ISIF Subject: MSGGROUP#1573 RFC 769 Available To: "[ISIF]Request-for-Comments.List": A new RFC is now available in the NIC online library at SRI-KL. RFC 769: Title: Rapicom 450 Facsimile File Format Author: Jon Postel Pages : 2 pathname: [SRI-KL]RFC769.TXT This is a specification for a file format for the exchange of facsimile data between users of Rapicom 450 machines. Public access files may be copied from the NIC library at SRI-KL via FTP with username NICGUEST and password ARPA. --jon. ------- 28-Sep-80 02:18:24-PDT,3147;000000000001 Mail-from: MIT-ML rcvd at 27-Sep-80 1254-PDT Date: 27 September 1980 15:14 edt From: Sibert at MIT-Multics (W. Olin Sibert) Subject: MSGGROUP#1574 NBS Computer Standards Sender: Sibert.Multics at MIT-Multics To: header-people at MIT-AI, human-nets at MIT-AI, msggroup at MIT-AI The following cheerful news is brought to us by the September 29 issue of Computerworld. Copyright (c) 1980 by CW Communications, Inc. Following ANSI guidelines: NBS to Give Format Standards Over Four Years Chicago - The National Bureau of Standards (NBS) will release over the next four years a series of format standards aimed at improving computer communications and integration and at aiding electronic mail transmissions between automated offices. The MBS-sanctioned standards - five in all - will be voluntarily developer by the user and vendor community, following American National Standrads Institute (ANSI) guidelines and processing requirements, according to James H. Burrows, director of the NBS' Institute for Computer Science and Technology (ICST). The ICST manages the governmentwide computer standards program and provides technical assistance to federal agencies. At the recent National Symposium on Office Automation, sponsored by the Data Processing Management Assicoation's Education Foundation (DMPA) here, Burrows gave a brief outline of each of the proposed protocol standards. The NBS standards will include: 1) A message interchange format standard, which will allow users of one system to send and receive messages from a foreign system. 2) A flexible disk format standard to establish common file formatting and labelling for flexible disks. 3) A text editing directives standard that will establish a common set of user directives for text editing systems. 4) A text formatting directives standard to provide directives for text formatting systems. 5) A message processing directives standard establishing a common set of directives for computer-based message systems. The latter three standards will provide a minimal level of functioanllity and help users switch from one text editing, formatting, or message system to another, Burrows explained. As a flagship for these five standards, the NBS is planning to release several guidelines geared to help users plan for, select, and evaluate computer based office machinery. The first guideline, "requirements analysis for office automation systems", which Burrows said will be available in late October or early November, will recommend a process to measure the benefits of office automation. Drafts of the requirements analysis guideline have already been circulated to a number of federal agencies and vendors for comments. ------------------------------------------------------- It all sounds kinda familiar, doesn't it? Remember NETED? Standard mail systems, described in an RFC too old for me to remember? Since the ARPAnet technical community has already been through exactly this same process, perhaps we should provide some input; presumably Mr. Burrows is the person to talk to. 28-Sep-80 02:18:24-PDT,949;000000000000 Mail-from: MIT-ML rcvd at 27-Sep-80 1355-PDT Date: 27 Sep 1980 1623-EDT Sender: DDEUTSCH at BBNA Subject: MSGGROUP#1575 Re: NBS Computer Standards From: DDEUTSCH at BBNA To: Sibert at MIT-MULTICS Cc: header-people at MIT-AI, human-nets at MIT-AI, Cc: msggroup at MIT-AI Message-ID: <[BBNA]27-Sep-80 16:23:12.DDEUTSCH> In-Reply-To: Your message of 27 September 1980 15:14 edt I believe that Marvin Sirbu mentioned (at least to MsgGroup) last spring that NBS was having BBN develop a message format standard. This is the very same standard as was mentioned in the CW article. We have finally made it to the "draft standard" stage. NBS will soon be publishing a document for public review. The lessons learned on the ARPAnet have not been ignored by either NBS or the draft standard's authors. After the public has made its comments and suggestions the draft standard will be revised into a final version. Debbie 3-Oct-80 13:48:29-PDT,762;000000000001 Mail-from: MIT-ML rcvd at 29-Sep-80 0616-PDT Date: 29 Sep 1980 0841-EDT From: POGRAN at BBND Subject: MSGGROUP#1576 Re: NBS Computer Standards To: Sibert.Multics at MIT-MULTICS, header-people at MIT-AI, To: human-nets at MIT-AI, msggroup at MIT-AI cc: POGRAN NBS/ICST has been an ARPANET participant just about as long as anyone else; I think we can safely assume that they are fully aware of the ARPANET experience in these areas. In particular, I think the fact that the goals, and the phrasing, sounded so familiar to us is an indication that NBS is aware. What NBS must now do is LISTEN to all the input they're soliciting from industry -- and still come up with technically valid standards, a la ARPANET. Ken Pogran ------- 3-Oct-80 13:48:30-PDT,749;000000000001 Mail-from: MIT-ML rcvd at 29-Sep-80 0835-PDT Date: 29 September 1980 11:12-EDT Monday From: John A. Pershing Jr. To: POGRAN at BBND Cc: Sibert.Multics at MIT-MULTICS, header-people at MIT-AI, human-nets at MIT-AI, msggroup at MIT-AI Subject: MSGGROUP#1577 NBS Computer Standards It seems the one lesson to be learned from the ARPA Net (which NBS apparently hasn't learned) is that there IS such a thing as too many protocols. With DOD issuing their "standard" protocol, ANSI issuing theirs, yet another coming from Europe (CCITT), plus the extant ARPA Net, ChaosNet, PRNet, PUP, etc., etc., etc., this country needs another "standard" protocol about as much as I need another hole in my head. -jp 3-Oct-80 13:48:30-PDT,1000;000000000001 Mail-from: MIT-ML rcvd at 30-Sep-80 1608-PDT Date: 30 Sep 1980 (Tuesday) 0933-EST From: WATKINS at NBS-10 Subject: MSGGROUP#1578 NBS Standards Program in Computer Based Office Systems To: Sibert at MIT-MULTIC cc: header-people at MIT-AI, human-nets at MIT-AI, msggroup at MIT-AI As manager of the NBS program in Computer Based Office Systems, I would be happy to receive any comments either on the general program of standards planned or any specific product. It would greatly expedite things, if comments were directed to me (either via netmail, USPS mail, or phone) rather than Jim Burrows or any of our contractors. The success of this standards program, as any, is dependent upon sound technical inputs from vendors, Government, users, and implementors. I look forward to hearing from the ARPANET community and certainly their voice of experience. Shirley Ward Watkins (301) 921-3516 National Bureau of Standards Bldg. 225 B226 Washington, D. C. 20234 3-Oct-80 13:48:30-PDT,1357;000000000001 Mail-from: USC-ISIF rcvd at 1-Oct-80 0304-PDT Date: 1 Oct 1980 0232-PDT From: BROWN at USC-ISIF Subject: MSGGROUP#1579 New RFCs Available To: "[ISIF]Request-for-Comments.List": New RFCs are now available in the NIC online library at SRI-KL. RFC 770: Title: Assigned Numbers Author: Jon Postel Pages : 15 pathname: [SRI-KL]RFC770.TXT This is the list of numbers used for network, protocols, ports, etc. RFC 771: Title: Mail Transition Plan Author: Vint Cerf and Jon Postel Pages : 9 pathname: [SRI-KL]RFC771.TXT This is a draft plan for computer mail service during the transition from an ARPANET NCP based protocol environment to a Internet TCP based protocol environment. RFC 772: Title: Mail Transfer Protocol Author: Suzanne Sluizer and Jon Postel Pages : 31 pathname: [SRI-KL]RFC772.TXT This is a draft protocol proposal for computer mail transfer, separate from file transfer. Public access files may be copied from the NIC library at SRI-KL via FTP with username NICGUEST and password ARPA. --jon. ------- 3-Oct-80 13:48:30-PDT,747;000000000001 Mail-from: USC-ISIF rcvd at 2-Oct-80 0005-PDT Date: 1 Oct 1980 2146-PDT From: BROWN at USC-ISIF Subject: MSGGROUP#1580 RFC 773 Available To: "[ISIF]Request-for-Comments.List": A new RFC is now available in the NIC online library at SRI-KL. RFC 773: Title: Comments on the NCP/TCP Mail Service Transition Strategy Author: Vint Cerf Pages : 11 pathname: [SRI-KL]RFC773.TXT This is an expanded discussion of the computer mail plan outlined in RFC 771. Public access files may be copied from the NIC library at SRI-KL via FTP with username NICGUEST and password ARPA. --jon. ------- 21-Dec-80 14:55:26-PST,4095;000000000001 Mail-from: MIT-ML rcvd at 8-OCT-80 1736-PDT Date: 8 Oct 1980 1719-PDT From: Brian K. Reid Subject: MSGGROUP#1581 Call for Papers To: MsgGroup at MIT-ML Since the interest areas of MsgGroup probably overlap substantially with the interest area of this conference, I'm sending the call for papers out. Please pass it around; post it on local bboards (physical and electronic), etc. CALL FOR PAPERS ACM SIGPLAN-SIGOA SYMPOSIUM ON TEXT MANIPULATION ________ JUNE 8-10, 1981 PORTLAND, OREGON This symposium will deal with the variety of tools, techniques, and programs that have been developed for creating and manipulating text, whether natural language text or programming language text. The emphasis is to be on ideas that can be generalized beyond the context in which they were originally developed. Suggested topics include, but are not limited to: - String manipulation languages - Text Editors - Editing environments for particular programming languages - Text formatting programs and pretty-printers - The linguistics of text, i.e. formal structure of textual material - Typesetting and document formatting languages - Interactive systems for document layout - Techniques for particular applications, e.g. mathematics, literature indices, newspaper publication - Treatment of special problems, e.g. hyphenation, character set limitations, graphics in text - Practical algorithms for text searching, comparison, etc. Papers describing systems that have been in use for some time, but have not been presented in the open literature, are particularly encouraged. Presentations of commercially available systems are welcome as long as the techniques on which these systems are based can be presented openly. Any proprietary restrictions on these techniques must accompany the paper, and will be considered in evaluating the suitability of the paper for the symposium. Rules - Authors must submit full papers. The paper may be revised or expanded for publication in the symposium proceedings if it is accepted. - The submitted paper must contain its title on the first page, but no indication of its authorship. - Acknowledgements and other identifying information should be omitted from the submitted paper. - The name and address of the author should appear in a cover letter to the chairman. (This information will be withheld from the rest of the committee during the selection process). - Proprietary restrictions should be stated in an attachment to the paper itself. - The final paper will be limited to ten pages of model paper, which is approximately 25 double-spaced typed pages. Papers exceeding this limit may receive less careful scrutiny than the work merits. Seven copies of each submitted paper must be received by the conference chairman no later than December 5, 1980. The papers to be presented at the symposium will be selected by the program committee, and authors will be notified of acceptance or rejection of their papers by February 13, 1981. The full text of each accepted paper must be typed on model paper and received by the conference chairman by March 27, 1981. Authors of accepted papers will be expected to sign a copyright release form. Proceedings will be distributed at the symposium and will subsequently be available for purchase from ACM. The members of the program committee are: Russell Abbott Brian Kernighan Charles Geschke James King David Hanson Brian Reid Paul Abrahams, Chairman Submitted papers should be sent to the conference chairman: Paul Abrahams ACM Symposium on Text Manipulation P.O. Box 161 Deerfield MA 01342 ------- 21-Dec-80 14:55:26-PST,2805;000000000001 Mail-from: USC-ISIF rcvd at 12-Dec-80 0526-PST Date: 11 Dec 1980 2155-PST From: BROWN at USC-ISIF Subject: MSGGROUP#1582 INWG Announcement To: "[ISIF]Request-for-Comments.List": Working Group 6.1 of the International Federation for Information Processing (IFIP) held its fall meeting on October 26 and 31, in conjunction with ICCC 80, in Atlanta, Georgia. At this meeting it was agreed that the group would expand its efforts into a number of new areas. The objective is to make the existing organizational framework available to support workers already active in the new areas, providing an established forum for the exchange of ideas. IFIP is a scientific organization and promotes development of information processing on a technical, rather than "political", basis. Working Group 6.1, also known as the International Network Working Group (INWG), has been active for several years in the development of communication protocols for computer networks from a technical viewpoint; the standards organizations have been more concerned with commercial factors in this development. We feel that it is now appropriate to pursue the same approach to a broader set of computer communication topics. We therefore invite individuals, research groups, and commercial organizations interested in an active exchange of technical ideas in any of the following areas to contact us. - Specification, Verification, Testing, and Certification techniques for computer network protocols. We are planning a workshop on this topic in mid-1981. - Assessment of the ISO proposals for Open Systems Interconnection (OSI) from the viewpoint of internal computer system architecture. For example, considerations of implementation and performance; are they idiosyncratic to each system or can useful generalizations be made? Another workshop on this topic is being planned for 1981. - Protocols for new application areas, such as the management of distributed data bases, and network operating systems. - Interconnection of public and private networks. The tremendous growth in the local network field makes this a topic of especial relevance. - Communications protocols for personal and small business computers, especially for such functions as program distribution and electronic mail. You can contact WG6.1 to express interest in any of these topics, or others of concern to you, via the chairman Alex McKenzie BBN 10 Moulton Street Cambridge, MA 02238 USA 617/497-2962 McKenzie@BBND ------- 23-Dec-80 01:23:48-PST,4093;000000000001 Mail-from: USC-ECL rcvd at 22-Dec-80 0355-PST Date: 22 DEC 1980 0327-PST From: MSGGROUP at USC-ECL Subject: MSGGROUP#1583 CLEARING THE DECK FOR ACTION To: "[ECL]MAIL.LST;46": MSGGROUP has been quiet for some time now so the MAIL.LST is probably a bit rusty. I have received indications that some new items will be placed before the group in the near future so I want to clear the decks for action before it all starts. So, here is the current list. I will record what the mailer does with each address as this message goes out, and will catch some of the changes that need to be made that way. If your address needs correction, please let me know. It is important to avoid undue loading on MIT-**. We should avoid forwarding when we could have the correct address in the main list. Etc. Thank you for your help. See you around the discussions if any get started. Hava Merry! Stef "[ECL]MAIL.LST;46":, Hathaway@AMES-67, Reynolds@AMES-67, Burchfiel@BBNA, DDeutsch@BBNA, Gonzalez@BBNA, Mathison@BBNA, Mooers@BBNA, Myer@BBNA, OFI@BBNA, JPershing@BBN-TENEXA, Resnick@BBNA, Sandberg@BBNA, Tappan@BBNA, Wagreich@BBNA, Maloneye@BBNB, JMcKendree@BBNB, INFOMEDIA@BBN, Pool@BBN, vonGehren@BBN, Bernstein@BBND, JHaverty@BBND, Pogran@BBND, McQuillan@BBND, Swernofsky@BBND, Vittal@BBND, Dekker@CCA, JZS@CCA, Tom@CCA, RCT@CCA, Rick.Gumpertz@CMUA, Lehman@CMUA, RdMail@CMUA, Wactlar@CMUA, PBaran@ECL, Caine@ECL, Carlson@ECL, RDeMent@ECL, Falcone@ECL, JGiger@ECL, Heiser@ECL, JMcHugh@ECL, MsgGroup@ECL, HSmith@ECL, JDASteel@ECL, JTucker@ECL, AWalden@ECL, Widener@ECL, Adams@ISI, ADPSC@ISI, Broos@ISI, Comport@ISI, Harmon@ISI, Hosmer@ISI, Kirstein@ISI, MJMarcus@ISI, Maxwell@ISI, Roberts@ISI, Schlaff@ISI, Tasker@ISI, TI-HQ@ISI, Walker@ISI, Cohen@ISIB, Ellis@ISIB, Holg@ISIB, Stotz@ISIB, DGordon@ISIC, Bertapelle@ISIE, Gage@ISIE, Lundquist@ISIE, McCrary@ISIE, Schill@ISIE, Finn@ISIF, Katz@ISIF, Postel@ISIF, MO@LBL-Unix, SventekV@LBL-UNIX, JNC@MIT-AI, Derway@MIT-AI, Duffey@MIT-AI, Finin@MIT-AI, Foner@MIT-AI, KLH@MIT-AI, Hewitt-Junk@MIT-AI, PROCEP@MIT-AI, CStacy@MIT-AI, RMS-MSGGROUP@MIT-AI, MSGGRP@MIT-DMS, Vezza@MIT-DMS, JRDavis.Multics@MIT-Multics, Frankston@MIT-MULTICS, Hornig@MIT-Multics, Palter@MIT-MULTICS, Sibert@MIT-MULTICS, Solomon@MIT-Multics, Strayhorn.RCI@MIT-Multics, DCC@MIT-MC, HIC@MIT-MC, CBF@MIT-MC, RKJ@MIT-MC, RWK@MIT-MC, FFM@MIT-MC, Newman@MIT-MC, CPR@MIT-MC, KenS@MIT-MC, Sirbu@MIT-MC, JSol@MIT-MC, Taft@MIT-MC, GZ@MIT-MC, JDG@MIT-ML, DP@MIT-ML, MP@MIT-ML, MDG@MIT-XX, Greif@MIT-XX, RI@MIT-XX, Sross@MIT-XX, MT@MIT-XX, Watkins@NBS-10, DBall@OFFICE-1, DRDAR-MST@OFFICE-2, Hewitt@OFFICE-2, King@OFFICE-2, Taylor@OFFICE-2 RHill@OFFICE-3, Parsons@OFFICE-3, Rounds@OFFICE-3, Smith@Office-3, Stefferud@OFFICE-3, Walsh@OFFICE-3, Waugh@OFFICE-3, Zellich@OFFICE-3, Stone@OFFICE-2, Engelbart@OFFICE-2, Jordan@OFFICE-2, Brodie@Parc-Maxc, Brotz@Parc-Maxc, Cohen@Parc-Maxc, Danielson@Parc-Maxc, Dolbec@Parc-Maxc, Hamilton.ES@Parc-Maxc, AHenderson@Parc-Maxc, Karlton@Parc-Maxc, Korb@Parc-Maxc, McDaniel@Parc-Maxc, McGregor@Parc-Maxc, Newman.ES@Parc-Maxc, White@Parc-Maxc, GeoffM@RAND-AI, RAND-MsgGroup@RAND-UNIX, TBowerman@DARCOM-KA, EFields@DARCOM-KA, Geoff@DARCOM-KA, Grobstein@DARCOM-KA, Ole@DARCOM-KA, Steffey@DARCOM-KA, Sternberg@DARCOM-KA, Wancho@DARCOM-KA, Whallon@DARCOM-KA, FBIEDERMAN@DARCOM-HQ, LLayten@DARCOM-HQ, CWALTERS@DARCOM-HQ, LCampbell@SRI-KL, Chesley@SRI-KL, Foster@SRI-KL, Future-NET@SRI-KL, Fylstra@SRI-KL, Gaschnig@SRI-KL, Knutsen@SRI-KL, EKozel@SRI-KL, Malek@SRI-KL, McLure@SRI-KL, Meyers@SRI-KL, Pickens@SRI-KL, Scott@SRI-KL, JPM@SU-AI, Admin.MRC@SU-SCORE, NCP.Pine@SU-SCORE, Reid@SU-Score, Bair@SUMEX-AIM, Blohm@SUMEX-AIM, Rindfleisch@SUMEX-AIM, Lauren@UCLA-SECURITY, Mike@UCLA-SECURITY, Rudisin@UCLA-SECURITY, Steve@UCLA-SECURITY, MsgGroup@UDEL, Landweber@UTAH-20, David@UTEXAS, Rick@UTEXAS, Dreifu@Wharton, Morgan@Wharton, Patti@Wharton, ------- 23-Dec-80 01:23:49-PST,462;000000000001 Mail-from: MIT-ML rcvd at 22-Dec-80 1838-PST Date: 22 Dec 1980 2124-EST From: Marvin Sirbu Subject: MSGGROUP#1584 Mail systems for VAX/VMS To: msggroup at MIT-ML Does anyone out there know of a decent mail system that will run on a DEC PDP 11/780 under VMS (or a PDP-11 under RSX-11M). I know there are lots of good systems which run under UNIX, but unless they can be easily converted to run under VMS that won't help. ------- 23-Dec-80 01:23:49-PST,891;000000000001 Mail-from: MIT-ML rcvd at 22-Dec-80 2306-PST Date: 22 Dec 1980 2252-PST Sender: STEFFERUD at OFFICE-3 Subject: MSGGROUP#1585 Re: Mail systems for VAX/VMS From: Stef at DARCOM-KA To: SIRBU at MIT-XX Cc: msggroup at MIT-ML, Stef at DARCOM-KA Message-ID: <[OFFICE-3]22-Dec-80 22:52:00.STEFFERUD> In-Reply-To: Your message of 22 Dec 1980 2124-EST Reply-To: Stef at DARCOM-KA Hi Marvin - Have you talked with John McQuillan about their plans at BBN Management Information Systems? They may be coming up on VAX/VMS though they are compiling on a VAX/UNIX. I get confused in all those variations, but I think he said they are targeting on VAX/VMS for their first commercial delivery. By the way, the list is about cleaned up so you can get ready to pose your EM Crime Question to the group. Please give me a little warning that it is coming though. Hava Merry! Stef 23-Dec-80 22:24:13-PST,1077;000000000001 Mail-from: MIT-ML rcvd at 23-Dec-80 2214-PST Date: 23 Dec 1980 2155-PST Sender: STEFFERUD at OFFICE Subject: MSGGROUP#1586 CORRECTION Re: Mail systems for VAX/VMS From: Stef at DARCOM-KA To: MsgGroup at MIT-ML Cc: Stef at DARCOM-KA Message-ID: <[OFFICE-3]23-Dec-80 21:55:27.STEFFERUD> In-Reply-To: <[OFFICE-3]22-Dec-80 22:52:00.STEFFERUD> Reply-To: Stef at DARCOM-KA Hoist by my own petard! I goofed in sending my message to the whole MsgGroup list. It was intended to be a private message to Marvin Sirbu and now I must clarify and correct what I have put into a public record. 1. The correct company name is BBN Information Management Corporation, not BBN Management Information Systems. 2. No company announcement has been made that I know of regarding any mail system product for VAX/VMS. It is true that I have heard some rumors, but I wish to be very careful (now that I have goofed) to distinguish between rumors and announcements. My appologies to all - May all your genies stay in their bottles in the coming New Year! Stef 17-Jan-81 12:43:10-PST,4461;000000000001 Mail-from: MIT-ML rcvd at 17-Jan-81 0557-PST Date: 17 Jan 81 08:16-EST (Sat) From: Dave Farber Subject: MSGGROUP#1587 The Computer Science Network To: msggroup at Mit-Ml Message-ID: <8116.29764.6690 @ UDel-EE> Via: UDel.UDNet; 17 Jan 81 05:14-EST The Science Board of the National Science Foundation on Friday approved the creation and funding of CSNET - a computer network in support of Computer Science and Engineering research. A brief overview of the network follows. Dave CSNET A Computer Science Network CSNET is a cooperative effort of computer scientists to establish a computer-based communications network which will interconnect computer science research groups in universities, industry and government. Based on recent advances in computer network technology, including interna- tional protocol standards and the availability of com- mercial packet networks, CSNET will provide a feasible means for collaborative work at the forefront of computer science research. The benefits to the community are expected to be very significant, when compared to initial investments and continuing costs. In particu- lar, CSNET will help to solve two critical problems which the computer science community now faces: severe per- sonnel shortages and low productivity in software develop- ment. CSNET will link hosts on a number of other com- puter communications networks including the Department of Defense ARPANET and public packet networks such as TELENET and TYMNET. CSNET will evolve by adoption of new technology as it becomes available and hence will offer continuing state-of-the-art computer communications services to the computer science research community. As new public networks are established, CSNET will expand to accommodate hosts that are connected to them. Gate- ways will connect the component networks so that communi- cation between any two CSNET hosts will be possible. For CSNET hosts that are not directly connected to existing networks, a telephone-based memo relay system called "PHONENET" will extend CSNET interconnection to all who desire it. If neither PHONENET nor public network links can be justified for a host, access for individu- als may be via a Service Host which will operate in the mode of a time-sharing utility. Communications services to be provided include memo and file transfer and interactive terminal access to remote systems and databases. The new Department of Defense (DoD) internet host-to-host protocols (TCP/IP) will be used. These protocols are being implemented by a number of industry and university groups for many computer systems of the type used by the computer science research community. Availability of these already-developed and tested implementations will significantly reduce the cost of January 17, 1981 - 2 - CSNET implementation. In the future, most public network hosts will utilize the X.25 international standard protocol for network con- nection. A major CSNET software effort will involve development of X.25 packages and interfaces for relevant operating systems and adaptation of X.25 interfaces to the DOD host-to-host protocols. CSNET will be implemented in several parallel phases. Phase One, to be completed at the end of the first year, includes implementing PHONENET and establishing a Service Host. The Service Host will provide access to CSNET via local public network dial-in ports, for researchers without a local CSNET host. Phase Two, to be com- pleted by the end of the third year, will involve imple- menting and testing the X.25 network connection protocol plus required operating system and higher-level protocol interfaces. This will enable full host-to-host communica- tions services via the public networks. Years Four and Five will be devoted to expanding the number of sites attached to CSNET as well as transitioning to a long term operating organization. January 17, 1981 19-Jan-81 23:11:04-PST,1223;000000000001 Mail-from: MIT-ML rcvd at 19-Jan-81 1457-PST Date: 19 JAN 1981 1736-EST From: SIRBU at MIT-MC (Marvin A. Sirbu, Jr.) Subject: MSGGROUP#1588 Crime and electronic mail To: msggroup at MIT-ML CC: Stefferud at USC-ECL I am currently conducting a study for the Criminal Statistics Division of the Justice Department on crime and electronic mail. They are interested in knowing if it's time to start collecting statistics on crime and electronic mail. Therefore, I would appreciate any answers you might have to the following questions. 1. Have you personally experienced any difficuties with any of the following EMS related crimes? a. Theft of services b. Theft of information c. Theft of finances d. Damage or destruction of equipment e. Invasion of privacy f. Misrepresentation of identity 2. Do you know of anyone who has had any difficulties of the type listed above? Please provide a source or contact. 3. What systems were involved in the incidents reported on above? What networks? 4. What potential criminal difficulties do you forsee in EMS? Thank you very much for your help. I will summarize the replies and distribute them to msggroup. Marvin Sirbu 2-Feb-81 17:58:38-PST,748;000000000001 Mail-from: USC-ISIF rcvd at 27-Jan-81 0158-PST Date: 27 Jan 1981 0028-PST From: LINDA at USC-ISIF Subject: MSGGROUP#1589 RFC 776 Available To: "[ISIF]Request-for-Comments.List": A new RFC is now available in the NIC online library at SRI-KL. RFC 776: Title: Assigned Numbers Author: Jon Postel Pages : 13 pathname: [SRI-KL]RFC776.TXT This is a update of the assigned network, protocol, socket, port, and link numbers used in the ARPANET and the ARPA Catenet. Public access files may be copied from the NIC library at SRI-KL via FTP with username NICGUEST and password ARPA. --jon. ------- 2-Feb-81 17:58:39-PST,676;000000000001 Mail-from: MIT-ML rcvd at 30-Jan-81 2058-PST Date: 30 Jan 1981 2041-PST From: Zellich at OFFICE-3 (Rich Zellich) Subject: MSGGROUP#1590 NBS Draft Report on Message Format Standard To: MsgGroup at MIT-ML, Header-People at MIT-MC cc: Parsons, Zellich Anyone who didn't receive a copy of the following report should take steps to obtain one: NBS Report No. ICST/CBOS - 80-2, "Specification of a Draft Message Standard" You can probably get one by writing to the address given for comments: National Bureau of Standards (Code CBOS) Systems and Network Architecture Division Technology Building, Room B218 Washington, DC 20234 ------- 2-Feb-81 17:58:39-PST,401;000000000001 Date: 2 Feb 1981 (Monday) 0950-EST From: WATKINS at NBS-10 Subject: MSGGROUP#1591 NBS Draft Report on Message Format Standard To: msggroup at MIT-ML, header-people at MIT-MC Copies of NBS Report NO. ICST/CBOS - 80-2, "Specification of a Draft Message Format STandard" may be obtained by sending netmail to watkins@nbs-10. Please send your USPS address with your request. Shirley 10-Feb-81 17:25:11-PST,24218;000000000001 Mail-From: STEFFERUD Received-Date: 10-Feb-81 1725-PST Date: 10 Feb 1981 1725-PST Sender: STEFFERUD at OFFICE-3 Subject: MSGGROUP#1592 FCC Notice of Inquiry for General Docket 80-756 From: STEFFERUD at OFFICE-3 To: MsgGroup at ECL Cc: Maxwell at ISI, MJMarcus at ISI Message-ID: <[OFFICE-3]10-Feb-81 17:25:04.STEFFERUD> Fcc: MSGGROUP#.1551-1600 The following is an unofficial copy of an FCC Notice Of Inquiry for General Docket Number 80-756. The content has been proofed in an attempt to be as accurate as possible, but none-the-less, this must not be construed in any way to be an official copy. An official copy will be mailed to you via USPS if you send a mailing label with your request to MJMarcus@@ISI. This copy is being circulated via MsgGroup to allow individuals with ARPANET access to comment informally on the NOI. Interested parties may file comments on or before March 16, 1981. You may file informal comments by sending messages to MJMarcus@ISI. To be considered by the FCC, your informal comment should include your full name and US Postal Service Address. All such message comments will be forwarded to the Secretary for filing in the Docket, as stated in paragraph 23 of the NOI where informal comments are solicited from DEAF-NET users via netmail. If you have any questions about this procedure, you may question Mike Marcus privately, or with MsgGroup distribution so we may share your questions and the answers. The format of the NOI is changed from the official printed version. Underscores have been omitted, all footnotes are moved to the end of the document, rather than including them on each page where they are cited, and the pagination is different because of this. To assure that your comments are traceable to the content of the NOI, please cite the text by paragraph number rather than by page number. Any discussion of this NOI in the regular manner of group discussion via MsgGroup distribution will also be made available to the FCC as informal public comments in response to the NOI, and as such will be forwarded to the Secretary for filing in the Docket. Again, inclusion of your name and USPS address on your comments will be desireable. This is a new kind of activity for MsgGroup and we hope that it might afford some progress in the use of network facilities for this kind of inquiry. This use of MsgGroup is not sponsored by the FCC, though it is understood that FCC staff members are aware of our undertaking. Best Regards, Einar Stefferud (STEF) BEFORE THE FEDERAL COMMUNICATIONS COMMISSION FCC 80-702 WASHINGTON, D.C. 20554 28507 In the Matter of ) ) General Docket 80 - 756 Digital Communications ) Protocols ) ) ) NOTICE OF INQUIRY Adopted: December 4, 1980 Released December 8, 1980 By the Commission: 1. In the Final Decision of Amendment of Section 64.702 of the Commission's Rules and Regulations (Second Computer Inquiry)[1] hereafter referred to as the FINAL DECISION we adopted a dichotomy for network services, with basic services being subject to our Title II regulation and enhanced services not so subject. The FINAL DECISION also provided that certain common carriers[2] must set up separate subsidiaries if they wished to provide enhanced services and that such subsidiaries must have separate personnel and facilities from that portion of the carrier that provides basic services.[3] 2. In the FINAL DECISION, an enhanced service is defined in part as one in which "Computer processing applications are used to act on the content, code, protocol, and other aspects of the subscribers information".[4] We pointed out that "while comments in this proceeding (Docket 20828) do not address protocol conversion in any depth, the question arises as to whether some flexibility should be afforded a basic service provider that is subject to the separation requirement, in view of the structure we are setting forth".[5] We also stated that we would consider a NOTICE OF INQUIRY on this question. There may be reasons for allowing a carrier subject to the separation requirement to have certain protocol conversions within its network rather than in a separate subsidiary's facilities. 3. While the comments in Docket 20828 prior to the Final Decision did not address protocol conversions in depth, the comments filed by various parties in the reconsideration phase of the docket have commented on the conversion issues in terms of our basic/enhanced definition. These comments will be included in the docket in this proceeding; the parties are welcomed to elaborate or comment on them insofar as they relate to issues addressed here. -2- 4. In the FINAL DECISION we defined protocols as "governing the methods used for packaging the transmitted data in quanta, the rules for controlling the flow of information, and the format of headers and trailers surrounding the transmitted information and of separate control messages".[6] A carrier would be providing a protocol conversion if the information exiting its network at the destination(s) of a transmission is in a different protocol than that given the network at the point of origination. Protocol conversions internal to the network do not, how- ever, constitute an enhanced services long as information is delivered in the same protocol in which it is received. 5. The FINAL DECISION suggests that protocol conversions can be accomplished in the device external to a basic network with little or no impact on the efficiency and throughput of transmission in the network as compared to a case where protocol conversions are wholly internal to the network. It may be true in the future that if protocol conversions must be performed external to the network it may limit the throughput and efficiency of a carrier's network. For example, if a carrier subject to the separation requirement chooses to offer a basic packet switched service, it must deliver packets of information to the destination in the same size as it received them even if it might be efficient in some cases to deliver other size packets constituting the same information. The basic policy question involved in this inquiry is to weigh the magnitude of the benefit (if any) of allowing certain protocol conversions to be performed by the carrier providing basic service against the regulatory implications of allowing exceptions to our structural separation of enhanced services for AT&T.[7] 6. In its Petition for Reconsideration, the National Telecom- munications and Information Administration (NTIA) agreed with the FINAL DECISION in the possible need for some protocol conversions stating: "Certain enhanced services may be economically feasible if implemented in conjunction with basic service, but not otherwise..in providing a basic level compatibility between dissimilar terminals and computers in a data communications network, it may not be economically feasible to interface with a low level protocol and code conversion compatibi- lity machine owned by a separate subsidiary and located in a separate facility".[8] -3- 7. The Computer Corporation of America (CCA) also questions the conversion prohibition, stating that: "Basic services should include code and protocol conversion functions..Data users have come to regard speed, code, and protocol conversions as important essential components of data communications service. These functions offer the means of achieving a compatible path or channel between two points in a data communications network..To the data user, the speed, code, and protocol operations performed by a packet carrier are used only to facilitate the transmission of the users information from its point of origin to its destination".[9] 8. The American Telephone and Telegraph Company (AT&T) has asked that we consider protocols in the context of the seven level hierarchy proposed by the International Organization for Standardization (ISO) [10] and that "basic service be permitted to include lower level conversions through level (4) immediately".[11] 9. The International Business Machine Corporation (IBM) has taken specific exception to these views. IBM states "it is not true that protocol conversion must be performed as part of basic service ..There is no basis in the record or in experience for concluding that the provision of code and protocol conversion as part of enhanced rather than basic service would impose significant losses in efficiency on AT&T or the public or would result in a loss of ubiquitous service".[13] 10. The Associated Data Processing Service Organization, Inc. (ADAPSO) argues that "if AT&T is allowed to perform protocol conversion, then AT&T could selectively choose which protocols and codes it utilizes and thus could destroy the competitiveness of equipment and service offerings of others". ADAPSO further argues that the provision of protocol conversions would duplicate existing enhanced services in the basic network and "would create immeasurable opportunities for cross- subsidization".[14] 11. In the same vein, Tymnet, Inc. argues that allowing AT&T and GTE to offer conversions as part of a basic service would allow them to offer services equivalent to those now offered by Tymnet without any structural safeguards to prevent anticompetitive conduct.[15] -4- Discussion 12. In order to focus comments in this proceeding better, we shall discuss three specific areas in which the lack of protocol conversions might affect network efficiency should in the future AT&T decide to offer packet switched basic service as part of its network. We specifically request comments on these examples but also ask the parties to raise and discuss any other examples. 13. The first example, deals with the interconnection of multiple packet switched networks. Our general competitive policy supports the existence of multiple national and regional packet networks. In such an environment, a user may chose not to subscribe to all available networks, but may wish to communicate with those who are not connected to the same network(s) it is connected to. This need would require network interconnection. There are three basic technical approaches for network interconnection.[16] These are a common switching node, a common host (a computer common to both networks) or an internode device or gateway. If the multiple networks are of different ownership, the common switching node solution would be organizationally difficult. This method is also the most complex as "it involves implementing in the same device all the switching capabilities of each network as well as the mapping from one protocol to the other".[17] Thus this approach is both complex and involves a protocol conversion device that is joint to the interconnected networks. This approach has been rarely used even when there has been no regulatory concerns. 14. The common host approach on the other hand is the "simplest and most straight forward".[18] All messages destined to the second network go to a common host that is connected to both. However, each network treats this common host as an explicit point of origination or destination for messages. Thus, from the point of view of both networks, no protocol conversions are needed as a part of the network. However, as McQuillan and Cerf have observed, this type of implementation has certain penalties, for "reassembly of segments at each (common host) gateway leads to increases in delay and in packet interarrival time variance, which may seriously affect the performance of real time application software (e.g., slow scan video, compressed packet speech, etc.).[19] -5- 15. We note, however, that there is some disagreement within the technical community on this point. The "Pup internetwork architecture" [20] uses what is effectively the common host approach and avoids inefficiencies by requiring certain standards of the interconnected networks. 16. The third alternative is the internode device or gateway that translates "between the internal packet format of its own network and some common internetwork format".[21] This type of interconnection implicitly leads to protocol translation as the network gives information to the gateway in internal network format and the gateway outputs the information in internetwork format. This would happen in both the case where the gateway was part of the basic network or the case where it is external to the network. In the case where the gateway is considered part of the basic network, it is converting from the internal protocol to internet protocol, and such translation would be prohibited in AT&T's basic network under the FINAL DECISION. In the case where the gateway is external to the network, the network is outputting information in internal protocol; whereas it received it in external protocol, again constituting a protocol conversion.[22] Thus, some type of protocol conversion flexibility may be needed in basic networks to allow for efficient network interconnection. We specifically request comments on this formulation of the network interconnection question and would welcome discussion of alternative methods of network interconnection. 17. We also note that the CCITT recommended X.25 protocol allows for the originator of a connection to request a packet size different than that used at the destination. (While the draft February 1980 revision of X.25 provides for negotiated packet sizes between the originating and terminating user data terminal equipment (DTE), it does not require it).[23] Thus the terminating network data communications equipment (DCE) may be required to split a packet before it can deliver it to the terminating DTE. -6- 18. As mentioned above in paragraph 5, there are other types of protocol conversions that could clearly be done in separate units from the network with little or no impairment of performance. These involve simple transformations on the data stream such as changing the physical representation of the data. In the ISO/OSI model these would generally be equivalent to what are called the physical layer and the data link layer. We specifically request comments on the correctness of this view. 19. In the record of Telecommunications Services for the Deaf and Hearing Impaired, CC Docket No. 78-50, we have learned much about the needs of the deaf community. In particular we have learned o two different teletypewriter standards for the deaf which have evolved. These are the original Baudot code combined with a Weitbrecht modem and the ASCII code combined with a 103-equivalent modem.[24] While the Baudot/Weitbrecht standard is predominant in the deaf community, many more pieces of ASCII/103 equipment exist as this is common in both the commercial and home computer markets. Therefore, it may be in the public interest to encourage the offering of services that interconnect the two types of equipment. As such an interconnection involves code and protocol conversion it would not be allowed under the terms of the FINAL DECISION. We specifically request comments on this issue. Matters to be addressed in this Inquiry 20. The subjects listed below are not exhaustive. They merely typify the Commission's areas of concern. Information not directly responsive to these questions but relevant to the general subject matter of the inquiry is welcome and invited. To facilitate staff review each response should clearly state the precise topic or question being addressed. A. Under what circumstances would the protocol conversion prohibition of the FINAL DECISION inhibit the efficient interconnection of packet switched networks? In this case what would be the minimum amount of conversion needed to allow efficient interconnection? Should a carrier subject to the separation requirement be allowed to perform this conversion? B. Is the ISO/OSI model appropriate for classifying different levels of protocols in this proceeding? If it is, is it appropriate to allow carriers subject to the separation requirement to use different "physical layer" protocols at the input and output of a con- nection? Is it appropriate to allow such carriers to perform "data link layer" protocol conversions? C. To date this Commission has had little role in the formulation or recommendation of CCITT protocols such as X.25. Should we take a more active role in this area? If so, what should it be? D. Should the Commission allow AT&T, within its common carrier network to offer the packet size modification features of the X.25 protocol? -7- E. Should the Commission allow offerors of basic service subject to the separation requirement to offer services in their network that include interconnect of Baudot/Weitbrecht terminal and ASCII/103 terminal? F. The main emphasis of the discussion in the Notice and consequently in the above questions has been upon the static, operating efficiency of digital networks. We recognize that the offering of protocol concapabilities has implications beyond static operational efficiency. Allowing one or more types of conversions within AT&T's common carrier network may discourage competitive entities from offering similar services. This may ultimately reduce the options available to customers and increase their costs. We therefore seek specific comments on the dynamic effects of these alternatives, especially their impact on the provision of enhanced services and the incentives created for AT&T. Comment Filing and Ordering Clause 21. In view of the foregoing, we seek to obtain information from interested members of the public in order to assist the Commission in resolving the regulatory and policy questions presented by the protocol conversion issue. We specifically request respondents to address the questions in paragraph 20. 22. Accordingly, pursuant to Sections 4(i), 4(j), 403 and 404 of the Communications act of 1934, as amended, IT IS ORDERED that the aforementioned inquiry IS HEREBY INSTITUTED. 23. Interested parties may file comments on or before March 16, 1981. Reply comments must be filed on or before May 15, 1981. Pursuant to the procedures set forth in Section 1.51(c)(1) of the Commission's Rules (47 CFR 1.51(c)(1)) an original and five copies should be filed with the Secretary of the Commission. If you would like each Commissioner to have a copy, you should include six additional copies. All comments and replies should be clearly marked with the designation General Docket No. 80-756, and will be available for public inspection in the Docket Reference Room at the Commission's Headquarter's. Parties who wish to file informal comments by deaf standard (Baudot/Weitbrecht) TTY may send messages to the Commission's unattended TTY 24 hours per day by calling (202)-254-9292. DEAF-NET users may file informal comments by sending messages to MJMARCUS@USC-ISI. All such message comments will be forwarded to the Secretary for filing in the Docket. All written comments should be sent to: Secretary, Federal Communications Commission, Washington, DC 20554. For further information, please contact Michael Marcus at (202)-632-7073. For general information on how to file comments please contact the F.C.C. Consumer Affairs Office at (202)-632-7000. Federal Communications Commission William J. Tricarico Secretary -8- FOOTNOTES [1] 77 F.C.C. 2d 384. [2] This provision presently applies only to AT&T. See Final Decision at para. 290 and Memorandum Opinion and Order adopted October 28, 1980 FCC 80- , at para. [3] 47 CFR 64.702(c). [4] FINAL DECISION at para. 97. [5] FINAL DECISION at fn. 37. [6] FINAL DECISION at fn. 33. Such protocols are used in digital communications and are essential when packet switching is used in a network. [7] The purpose and scope of this proceeding is not to re-examine whether the offering of protocol conversion should be classified as a basic service. This proceeding is premised on the classification of such services as set forth in the FINAL DECISION. [8] Petition of NTIA (July 12, 1980) pg. 8. While those comments and others were essentially addressing the classification of protocol offerings as enhanced services, we believe consideration should be given as to the need for protocol conversion within AT&T's network even though enhanced. [9] Petition of CCA (June 11, 1980) pg. 10-11. [10] See Hubert Zimmerman, "OSI Reference Model - The ISO Model of Architecture for Open Systems Interconnection", IEEE Transactions on Communications, Vol. COM-28 No. 4, Pg. 425-432, (April 1980). The seven levels in this architecture model are as follows: 1. Physical control, 2. Link control, 3. Network control, 4. Transport end to end control, 5. Session control, 6. Presentation control, 7. Process control. [11] Reply of AT&T (Sept. 5, 1980) at pg. 50. [12] Footnote not utilized. [13] Opposition of IBM (August 4, 1980) at pg. 25-27. [14] ADAPSO Opposition (August 4, 1980) at pg. 14. [15] Tymnet Opposition (August 4, 1980) at pg. 11. -9- [16] See Ira W. Cotton, "Computer Network Interconnection" reprinted in Marshall Abrams, et. al, Computer Networks: A Tutorial, IEEE Computer Society, 1978, pg. (4-38)-(4-52). [17] Id. at pg (4-50). [18] Id. at pg. (4-49). [19] John M. McQuillan and Vinton G. Cerf, Tutorial: A Practical View of Computer Communications Protocols, IEEE Computer Society, 1978, pg. 169. [20] David R. Boggs, et. al. "Pup: An Internetwork Architecture", IEEE Transactions on Communications, Vol. COM-28, No. 4, (April 1980) p. 612-623. [21] McQuillan and Cerf, op. cit. at p. 15. Most networks use an internal protocol that is different than the external protocol that it presents to its users. This is done for internal efficiency and the choice of internal protocol depends on factors such as user characteristics, desired response time, and type of communication facilities used (as transmission delays are a key factor). [22] If it outputed the information in external protocol to avoid the conversion, it would really be a "common host" system, subject to the limitation and penalties mentioned above. [23] The X.25 protocol describes connections between user data terminal equipment (DTE) and network data communications equipment (DCE). See Antony Rybczynski, "X.25 Interface and End-to-End Circuit Service Characteristics", IEEE Transactions on Communications, Vol. COM-28, No. 4, (April 1980), p 500-509 and Draft Revised CCITT Recommendation X.25, reprinted in Computer Communication Review, Vol. 10, No. 1+2 (January/April 1980) p. 48-55. [24] Named after the Western Electric model number that established the de facto standard. 10-Feb-81 19:22:33-PST,3224;000000000001 Mail-From: STEFFERUD Received-Date: 10-Feb-81 1922-PST Date: 10 Feb 1981 1922-PST Sender: STEFFERUD at OFFICE-3 Subject: MSGGROUP#1593 [STEFFERUD: MSGGROUP#1592 FCC Notice of Inquir...] From: STEFFERUD at OFFICE-3 To: MSGGROUP: Message-ID: <[OFFICE-3]10-Feb-81 19:22:32.STEFFERUD> Gentlepeole --- This is a citation of availability for the full text of the FCC NOI described below. You may FTP it from [ECL]MSGGROUP#.1592;1 with LOGIN ANONYMOUS and PASSWORD MSGGROUP. You may also request a netmail copy by reply message, or by netmail request to MSGGROUP@ECL OR ESTEFFERUD@ECL. The full text message contains 25,000 characters. Enjoy! Stef Begin forwarded message Date: 10 Feb 1981 1725-PST Subject: MSGGROUP#1592 FCC Notice of Inquiry for General Docket 80-756 From: STEFFERUD at OFFICE-3 To: MsgGroup at ECL Cc: Maxwell at ISI, MJMarcus at ISI Message-ID: <[OFFICE-3]10-Feb-81 17:25:04.STEFFERUD> The following is an unofficial copy of an FCC Notice Of Inquiry for General Docket Number 80-756. The content has been proofed in an attempt to be as accurate as possible, but none-the-less, this must not be construed in any way to be an official copy. An official copy will be mailed to you via USPS if you send a mailing label with your request to MJMarcus@@ISI. This copy is being circulated via MsgGroup to allow individuals with ARPANET access to comment informally on the NOI. Interested parties may file comments on or before March 16, 1981. You may file informal comments by sending messages to MJMarcus@ISI. To be considered by the FCC, your informal comment should include your full name and US Postal Service Address. All such message comments will be forwarded to the Secretary for filing in the Docket, as stated in paragraph 23 of the NOI where informal comments are solicited from DEAF-NET users via netmail. If you have any questions about this procedure, you may question Mike Marcus privately, or with MsgGroup distribution so we may share your questions and the answers. The format of the NOI is changed from the official printed version. Underscores have been omitted, all footnotes are moved to the end of the document, rather than including them on each page where they are cited, and the pagination is different because of this. To assure that your comments are traceable to the content of the NOI, please cite the text by paragraph number rather than by page number. Any discussion of this NOI in the regular manner of group discussion via MsgGroup distribution will also be made available to the FCC as informal public comments in response to the NOI, and as such will be forwarded to the Secretary for filing in the Docket. Again, inclusion of your name and USPS address on your comments will be desireable. This is a new kind of activity for MsgGroup and we hope that it might afford some progress in the use of network facilities for this kind of inquiry. This use of MsgGroup is not sponsored by the FCC, though it is understood that FCC staff members are aware of our undertaking. Best Regards, Einar Stefferud (STEF) [The full text is ommitted from this notice of availability.] 14-Feb-81 18:45:49-PST,4410;000000000001 Mail-from: MIT-ML rcvd at 11-Feb-81 1526-PST Date: 11 Feb 1981 1437-PST Sender: STEFFERUD at OFFICE Subject: MSGGROUP#1594 Para 1 & 20 extracted from the FCC NOI for Docket 80-756 From: STEFFERUD at OFFICE To: MsgGroup at MIT-ML Message-ID: <[OFFICE-3]11-Feb-81 14:37:26.STEFFERUD> By popular demand, and in amends for my gross omission of any indication of the subject of the NOI, here is an excerpt consisting of paragraphs 1 and 20 which identify the subject matter. Please do not respond to this without getting a full copy and reading it to avoid firing idle shots in the dark. And thanks to those who brought my gross failure to my attention. Best - Stef BEFORE THE FEDERAL COMMUNICATIONS COMMISSION FCC 80-702 WASHINGTON, D.C. 20554 28507 In the Matter of ) ) General Docket 80 - 756 Digital Communications ) Protocols ) ) ) NOTICE OF INQUIRY Adopted: December 4, 1980 Released December 8, 1980 By the Commission: 1. In the Final Decision of Amendment of Section 64.702 of the Commission's Rules and Regulations (Second Computer Inquiry)[1] hereafter referred to as the FINAL DECISION we adopted a dichotomy for network services, with basic services being subject to our Title II regulation and enhanced services not so subject. The FINAL DECISION also provided that certain common carriers[2] must set up separate subsidiaries if they wished to provide enhanced services and that such subsidiaries must have separate personnel and facilities from that portion of the carrier that provides basic services.[3] [Paragraphs 2-29 ommitted] Matters to be addressed in this Inquiry 20. The subjects listed below are not exhaustive. They merely typify the Commission's areas of concern. Information not directly responsive to these questions but relevant to the general subject matter of the inquiry is welcome and invited. To facilitate staff review each response should clearly state the precise topic or question being addressed. A. Under what circumstances would the protocol conversion prohibition of the FINAL DECISION inhibit the efficient interconnection of packet switched networks? In this case what would be the minimum amount of conversion needed to allow efficient interconnection? Should a carrier subject to the separation requirement be allowed to perform this conversion? B. Is the ISO/OSI model appropriate for classifying different levels of protocols in this proceeding? If it is, is it appropriate to allow carriers subject to the separation requirement to use different "physical layer" protocols at the input and output of a con- nection? Is it appropriate to allow such carriers to perform "data link layer" protocol conversions? C. To date this Commission has had little role in the formulation or recommendation of CCITT protocols such as X.25. Should we take a more active role in this area? If so, what should it be? D. Should the Commission allow AT&T, within its common carrier network to offer the packet size modification features of the X.25 protocol? E. Should the Commission allow offerors of basic service subject to the separation requirement to offer services in their network that include interconnect of Baudot/Weitbrecht terminal and ASCII/103 terminal? F. The main emphasis of the discussion in the Notice and consequently in the above questions has been upon the static, operating efficiency of digital networks. We recognize that the offering of protocol concapabilities has implications beyond static operational efficiency. Allowing one or more types of conversions within AT&T's common carrier network may discourage competitive entities from offering similar services. This may ultimately reduce the options available to customers and increase their costs. We therefore seek specific comments on the dynamic effects of these alternatives, especially their impact on the provision of enhanced services and the incentives created for AT&T. Comment Filing and Ordering Clause 8-Mar-81 22:27:10-PST,3749;000000000001 Mail-from: MIT-ML rcvd at 6-Mar-81 2038-PST Date: 6 Mar 1981 1727-EST Sender: LOVETT at BBNG Subject: MSGGROUP#1595 Symposium on Computer Message Systems on April 6-8 From: MYER at BBNG To: HUMAN-NETS at MIT-AI, Stef at DARCOM-KA, Stefferud at OFFICE Cc: Myer Message-ID: <[BBNG] 6-Mar-81 17:27:10.LOVETT> Redistributed-To: MsgGroup at MIT-ML Redistributed-By: STEFFERUD at OFFICE-3 Redistributed-Date: 6 Mar 1981 Earlier we circulated notices of a symposium on computer message systems sponsored by IFIP Technical Committee 6, Working Group 6.5. The Symposium will be held in Ottawa, Canada, April 6-8. Having seen the papers to be presented, we believe this will be an exciting meeting of landmark significance. We hope to see you there. If you have questions, feel free to contact either of us. Ted Myer Myer@BBN (617)491-1850 Dave Farber Farber @UDel-EE (302)738-1163 * * * SUMMARY (The full announcement will be made available through the network; details to follow.) This is the first international symposium dealing exclusively with computer-mediated messaging. It is aimed at promoting interchange of information and discussion on technical, economical and political issues. Program Committee: Ronald Uhlig, Chairman, Canada; Andre Danthine, Belgium; David Twyver, Canada; Najah Naffah, France; Klaus Wimmer, Germany; Tibor Szentivanyi, Hungary; Giuseppe Attardi, Italy; Peter Schicker, Switzerland; Donald Davies, UK; David Farber, USA; Theodore Myer, USA. Organizing Committee Chairman: Peter Trau, Bell-Northern Research, Ottawa, Canada. This symposium brings together 35 speakers from 12 countries to, present papers on all aspects of computer messaging. There will, be no parallel sessions so that everyone can attend all presentations and interact with the speakers and others in the audience. The official language will be English. The symposium will be held at the prestigious Chateau Laurier Hotel in Ottawa, the beautiful capital of Canada. Conference Schedule Summary Monday, 6 April Morning o Keynote Session o Voice Messaging Afternoon o Facsimile Messaging and Extensions o User Requirements for Computer Messaging o Computer Conferencing Tuesday, 7 April Morning o Computer Message System Design o Computer Message System Protocols Afternoon o Teletex o Naming (Addressing) Issues o Panel: International Regulatory Issues in Computer Messaging Wednesday, 8 April Morning o Computer Message System Implementation o Corporate Message Systems o Message Systems and Office Automation Afternoon o Security and Computer Message Systems o Human Factors in Computer Message Systems Registration is $300.00. Symposium fee includes admission to all sessions, lunch on April 6-8, a cocktail party on April 7, and one copy of the symposium proceedings. (Copies of all papers will be available at the conference.) Advance registration is advisable due to the limited size of the conference (600 conferees). The Symposium fee may be paid in Canadian or US dollars. Send certified cheque or money order to: IFIP TC-6 Symposium '81 Bell-Northern Research, Dept. 3D20 P.O. Box 3511, Station "C" Ottawa, Ontario, Canada, K1Y 4H7 12-Mar-81 11:22:33-PST,971;000000000001 Mail-from: MIT-ML rcvd at 10-MAR-81 1849-PST Date: 10 MAR 1981 2136-EST From: KLH at MIT-AI (Ken Harrenstien) Subject: MSGGROUP#1596 Anybody else hear of these folks? To: HUMAN-NETS at MIT-AI CC: (*MSG *BBOARD) at MIT-AI, msggroup at MIT-ML I just received a letter from an outfit called the Leona Publishing Co. Ltd, of Tokyo. Apparently they want to prepare an "Office Automation Report" and include a chapter about "researchers in the field", one of which is supposed to be yours truly, who is supposed to oblige by sending a mini-bio. I don't really think this is a "Who's Who" type of scam, but I would like to know what, if anything, is known about these folks. Anybody else received similar letters? Might be interesting to figure out what mailing list they used. [P.S. Enclosed was a $4 check to cover "mailing costs"; unusual, but more curious is the fact that it's drawn on the First National Bank of Boston. Nice and homey...] 15-Mar-81 22:00:14-PST,894;000000000001 Date: 13 Mar 1981 1642-EST Sender: LOVETT at BBND Subject: MSGGROUP#1597 FTP Info for Symposium on Computer Message Subject: Systems on April 6-8 From: LOVETT at BBND To: HUMAN-NETS at MIT-AI, Stef at DARCOM-KA, Stefferud at OFFICE-3 Message-ID: <[BBND]13-Mar-81 16:42:49.LOVETT> Redistributed-To: msgroup at MIT-ML Redistributed-By: STEFFERUD at OFFICE-3 Redistributed-Date: 15 Mar 1981 The full text is now available for the announcement of the Symposium on Computer Message Systems sponsored by IFIP Technical Committee 6, Working Group 6.5, to be held in Ottawa, Canada, April 6-8, 1981. FTP from BBND. Log in as BBNDEMO, password BBN. The filename is IFIP.DOC. If you have further questions, feel free to contact either of us: Ted Myer Myer@BBN (617)491-1850 Dave Farber Farber@UDel-EE (302)738-1163 30-Apr-81 15:59:46-PDT,984;000000000001 Date: 2 APR 1981 0041-EST From: FFM at MIT-MC (Steve Kudlak) Subject: MSGGROUP#1598 SNA and Bisync here to stay??? To: info-micro at MIT-AI, msggroup at USC-ISI Please try to excuse the form of this letter for it was prepared on flakey equipment. Besides I was always taught content is more important than form... Awhile ago I had an interview, I fear unfortunately for me with an IBM type. Anyway this person sort of ended on the note of "the biSINK world will not go awayy and SNA is here to stay"... I admit to the poetic paraphrasing, but..thatt was theessence of his message. Anyway I would like to know how the rest of the world feels/thinks on this point. The nearest to res of world i can get is msgggroup andinfo-micro. I am especiallty interested in what micro-type s especially 68000 types have to say. So as not to bias things one way or another I want statemy views immediately.. Thanks muchly, Have fun... SendsSteve 30-Apr-81 15:59:46-PDT,1151;000000000001 Mail from USC-ISIF rcvd at 21-Apr-81 1946-PST Date: 21 Apr 1981 1536-PST Sender: LINDA at USC-ISIF Subject: MSGGROUP#1599 RFCs 777 and 778 now available From: LINDA at USC-ISIF To: "[ISIF]Request-for-Comments.List": Message-ID: <[USC-ISIF]21-Apr-81 15:36:59.LINDA> RFC Announcement New RFCs are now available in the NIC online library at SRI-KL. RFC 777: Title: Internet Control Message Protocol Author: Jon Postel Pages : 14 pathname: [SRI-KL]RFC777.TXT This describes the control messages used between hosts and gateways to report errors and other information of interest to the IP module. RFC 778: Title: DCNET Internet Clock Service Author: D.L. Mills Pages : 5 pathname: [SRI-KL]RFC778.TXT This describes a internet clock synchronization and delay measurement service. Public access files may be copied from the NIC library at SRI-KL via FTP with username NICGUEST and password ARPA. --jon. 30-Apr-81 15:59:46-PDT,780;000000000001 Mail-from: ARPANET host OFFICE-3 rcvd at 30-Apr-81 1041-PDT Date: 29 Apr 1981 1714-PDT Sender: LINDA at USC-ISIF Subject: MSGGROUP#1600 RFC779 now available From: LINDA at USC-ISIF To: "[ISIF]Request-for-Comments.List": Message-ID: <[USC-ISIF]29-Apr-81 17:14:16.LINDA> A new RFC is now available in the NIC online library at SRI-KL. RFC 779: Title: TELNET SEND-LOCATION Option Author: E. Killian Pages : 1 pathname: [SRI-KL]RFC779.TXT Describes a new Telnet option used to report the location of a user's terminal. Public access files may be copied from the NIC library at SRI-KL via FTP with username NICGUEST and password ARPA. --jon.