10-MAY-78 22:14:10-PDT,5624;000000000001 Mail-From: USC-ISI rcvd at 15-APR-77 2244-PST Date: 15 APR 1977 2217-PST From: STEFFERUD at USC-ISI Subject: MSGGROUP# 501 [ISI]PROCEEDINGS.SURVEY#451-#500 To: [ISI]Mailing.List: -- Messages from file: [USC-ISI]PROCEEDINGS.MSG#451-#500;1 -- FRIDAY, APRIL 15, 1977 21:28:47-PST -- 36 15 APR WALSH at OFFICE-1 MSGGROUP# 500 FROM/SENDER (IN REPLY TO STALLMAN COMMENTS) (2257 chrs) 35 15 APR Kahler at SUMEX-AIM MSGGROUP# 499 Re: Intuitive commands and suggestions (1077 chrs) 34 14 APR RMS at MIT-AI (Richar MSGGROUP# 498 MORE Re: CONFUSION RE: $492 FROM/SENDER (1086 chrs) 33 14 APR To:RMS at MIT-AI MSGRROUP# 497 Re: CONFUSION RE $492 FROM/SENDER (1495 chrs) 32 14 APR RMS at MIT-AI (Richar MSGGROUP# 496 CONFUSION RE #492 FROM/SENDER (1755 chrs) 31 14 APR PANKO at OFFICE-1 MSGGROUP# 495 Graphnet (1555 chrs) 30 14 APR MSGGROUP at USC-ISI MSGGROUP# 494 [BROTZ at PARC-MAXC: Introduction] (931 chrs) 29 13 APR WALSH at OFFICE-1 MSGGROUP# 492 Intuitive commands & suggestions on FROM/TO/CC/FCC/SH OW (4579 chrs) 28 12 APR WALSH at OFFICE-1 MSGGROUP# 491 Introduction of Rich Zellich (WALSH AT OFFICE-1) (1426 chrs) 27 11 APR LEDUC at OFFICE-1 MSGGROUP# 490 Electronic Message systems for the U.S. postal service (12633 chrs) 26 8 Apr Geoff at SRI-KA MSGGROUP# 488 Artical on ARPANET. (666 chrs) 25 5 Apr Geoff at SRI-KA MSGGROUP# 487 The 1st West Coast Computer Faire. (1662 chrs) 24 1 APR HOUGH at OFFICE-1 MSGGROUP# 486 Electronic Mail: $1 Billion a Year (1728 chrs) 23 1 APR HOUGH at OFFICE-1 MSGGROUP# 485 Article on New Public Data Networks (447 chrs) 22 25 Mar DDEUTSCH at BBN-TENEX MSGGROUP# 484 Electronic Mail seminar at MIT (7059 chrs) 21 29 Mar mark at UCLA-Security MSGGROUP# 483 Introduction for Mark Kampe (714 chrs) 20 27 Mar HENDERSON at BBN-TENE MSGGROUP# 482 Introduction for Austin Henderson (757 chrs) 19 26 Mar BRUCE.NELSON at CMU-1 MSGGROUP# 480 Introduction for Bruce Nelson (514 chrs) 18 25 MAR STEFFERUD AT USC-ISI MSGGROUP# 478 [Pogran AT MULTICS: Report on Sirbu Seminar] (4156 chrs) 17 23 MAR To:CBF at MIT-ML MSGGROUP# 477 Re: [Communications policy seminar at MIT] (881 chrs) 16 23 MAR STEFFERUD AT USC-ISI MSGGROUP# 476 [Communications policy seminar at MIT] (1716 chrs) 15 22 MAR PANKO at OFFICE-1 MSGGROUP# 475 RE: Draft History of ARPANET Computer Mail (529 chrs) 14 18 MAR PANKO at OFFICE-1 MSGGROUP# 474 Draft Survey of ARPANET Computer Mail (20189 chrs) 13 14 MAR FARBER at USC-ISI MSGGROUP# 473 Here we go!! (1101 chrs) 12 11 MAR PANKO at OFFICE-1 MSGGROUP# 472 NTC'77 Computer Mail Session (1019 chrs) 11 24 FEB METCALFE at PARC-MAXC MSGGROUP# 469 Re: Request for Voluntary Introductions (471 chrs) 10 23 FEB PANKO at OFFICE-1 MSGGROUP# 468 Introduction: Ra3y Panko (1555 chrs) 9 22 Feb Geoff at SRI-AI MSGGROUP# 467 Self Introduction: GEOFF@SRI-AI (740 chrs) 8 19 Feb PHILIP KARLTON(N810PK MSGGROUP# 466 Karlton's Introducti (828 chrs) 7 18 FEB PANKO at OFFICE-1 MSGGROUP# 465 NASA, the USPS & CMS (489 chrs) 6 17 FEB FARBER at USC-ISI MSGGROUP# 462 An Invited paper for a special issue of AAAS SCIENCE (34075 chrs) 5 17 Feb Gaines at Rand-Unix MSGGROUP# 461 INTRODUCTION from Stock Gaines@RAND-UNIX (879 chrs) 4 16 FEB STEFFERUD AT USC-ISI MSGGROUP# 460 Request for Voluntary Introductions (2031 chrs) 3 16 FEB Farber at Rand-Unix MSGGROUP# 458 CB mail (431 chrs) 2 16 FEB PANKO at OFFICE-1 MSGGROUP# 456 CB Computer Mail Dra (13009 chrs) 1 8 Feb dmis,anad MSGGROUP# 453 introduction [bowerman@bbnb] (1097 chrs) ------- 10-MAY-78 22:14:11-PDT,1472;000000000001 Mail-From: USC-ISI rcvd at 15-APR-77 2307-PST Date: 15 APR 1977 2249-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 502 Separate Files of Large Messages From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]15-APR-77 22:49:09.STEFFERUD> The following message files are kept to facilitate individual FTP access to single large messages. Please feel free to GET them with FTP, or request a copy to be forwarded via SNDMSG. Send your reuest to MsgGroup@ISI or to Stefferud@ISI. Best, Stef -- Messages from file: [USC-ISI]MSGGROUP#.490;1 1 11 APR LEDUC at OFFICE-1 MSGGROUP# 490 Electronic Message systems for the U.S. postal service (12633 chrs) -- Messages from file: [USC-ISI]MSGGROUP#.474;1 1 18 MAR PANKO at OFFICE-1 MSGGROUP# 474 Draft Survey of ARPANET Computer Mail (20189 chrs) -- Messages from file: [USC-ISI]MSGGROUP#.462;1 1 17 FEB FARBER at USC-ISI MSGGROUP# 462 An Invited paper for a special issue of AAAS SCIENCE (34075 chrs) -- Messages from file: [USC-ISI]MSGGROUP#.456;1 1 16 FEB PANKO at OFFICE-1 MSGGROUP# 456 CB Computer Mail Dra (13009 chrs) ------- 10-MAY-78 22:14:11-PDT,1414;000000000001 Mail-From: OFFICE-1 rcvd at 17-APR-77 0240-PST Date: 15 APR 1977 1908-PST Sender: WALSH at OFFICE-1 Subject: MSGGROUP# 503 FROM/SUBJECT/TO/CC - ONE MORE TIME AROUND From: WALSH at OFFICE-1 To: MSGGROUP at USC-ISI Cc: STEFFERUD at USC-ISI Message-ID: <[OFFICE-1]15-APR-77 19:08:15.WALSH> IN REPLY TO VARIOUS REPLIES ON MY ORIGINAL SUGGESTIONS: I REALIZE THAT MANY OF THE FEATURES ESPOUSED EXIST INDIVIDUALLY (AT LEAST IN PART) ON VARIOUS MAIL SYSTEMS AROUND THE NET. BASICALLY, I AM MAKING A PITCH FOR BOTH STANDARD AND OPTIONAL-ADD-ON FEATURES ON THAT ROSY FUTURE DAY WHEN THERE IS FINALLY A REAL-LIVE MESSAGE PROTOCOL. SPECIFICALLY ON FROM/TO & ATTN SUBFIELDS: FRANKLY, I AGREE WITH RMS THAT THE REAL (OR REPLY-TO) NAME/MAILBOX SHOULD APPEAR FIRST, FOLLOWED BY THE ACTUAL MAILBOX IN USE WITHIN PARENTHESES. I DON'T THINK THERE IS MUCH OF A QUESTION ON "WANTING" TO SUPPORT MULTIPLE PEOPLE USING ONE MAILBOX - THE SITUATION EXISTS, FOR VARIOUS REASONS, SO WE PRETTY WELL HAVE TO SUPPORT IT. NEXT TIME SOMEBODY WANTS TO PROPOSE A MESSAGE PROTOCOL, I'LL VOTE FOR HAVING THE "SUBFIELD" APPEAR FIRST (ACTUALLY, IT DOESN'T MAKE ANY DIFFERENCE WHAT THE ACTUAL TRANSMISSION PROTOCOL IS, EXCEPT THAT PEOPLE TEND TO PRINT THINGS OUT IN THE ORDER THEY'RE FOUND IN THE INPUT STREAM). NO COMMENTS ON PUTTING A PROGRAM-NAME IN THE FCC FIELD? RICH ZELLICH(WALSH@OFFICE-1) ------- 10-MAY-78 22:14:11-PDT,372;000000000001 Mail-From: USC-ISI rcvd at 18-APR-77 0014-PST Date: 18 APR 1977 0004-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 504 $Add VU@OFFICE-1$ From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Cc: VU at OFFICE-1 Message-ID: <[USC-ISI]18-APR-77 00:04:43.STEFFERUD> Stef - PS: the $---$ subject convention indicates no significant text. ------- 10-MAY-78 22:14:11-PDT,1598;000000000001 Mail-From: OFFICE-1 rcvd at 18-APR-77 0613-PST Date: 18 APR 1977 0602-PST Sender: VONGEHREN at OFFICE-1 Subject: MSGGROUP# 505 FROM/SENDER HANGUP From: E. VON GEHREN To: MSGGROUP at ISI CC: STEFFERUD at ISI Message-ID: <[OFFICE-1]18-APR-77 06:02:27.VONGEHREN> THIS WHOLE THING IS JUST A MATTER OF CONVENTION, WHAT ONE HAS GOTTEN USED TO (OR THINKS THAT THEY MIGHT HAVE GOTTEN USED TO). AS YOU NOTE FROM MY FROM FIELD YOU CAN PUT ANY THING YOU WANT INTO THE FROM FIELD. (IN HERMES YOU COULD SET UP YOUR OWN COMPOSE TEMPLATE TO SHOW "JOE BLOW USING " IF YOU WISH. THE HANG UP COMES WHEN ONE WISHES TO USE THE REPLY COMMANDS. PERHAPS WE SHOULD CONCENTRATE OUR ANNOYANCE ON THE MECHANISM USED IN THE REPLY. AS FOR MENTAL SET, I'VE GOTTEN NOW TO THINK THAT IT IS MOST REASONABLE FOR "SENDER" TO MEAN HOST-DIRECTORY IDENTIFICATION, AND "FROM" AS MY PERSONAL EXPRESSION OF MY IDENTITY. I FEEL THAT IT'S IMPORTANT TO TRACK BOTH. KNOWING THE TRUE MEANING OF THE "SENDER" FIELD, I NEVER SHOP IT WHEN PRINTING MY MESSAGES - MY INTEREST IS SEEING THE "FROM" , WHO YOU SAY YOU ARE. ELECTRONIC MAIL IS NO DIFFERENT THAN OTHER MEDIA; EACH GENERATES IT'S OWN SET OF CONVENTIONS AND RULES OF SOCIAL BEHAVIOR. THE ISSUE YOU'RE ARGUING FALLS INTO THIS AREA - IT REQUIRES THE ADOPTION OF SOME GENERALLY ACCEPTED CONVENTIONS AND SOCIAL RULES. THAT'S ALL YOU SHOULD BE PUSHING FOR - NOT THE ADOPTION OF SOME NEW MECHANISM FOR THE MACHINE. YES?? PEACE- ED ------- 10-MAY-78 22:14:12-PDT,1632;000000000001 Mail-From: CMU-10A rcvd at 18-APR-77 1519-PST Date: 18 Apr 1977 1816-EST From: Brian Reid at CMU-10A Subject: MSGGROUP# 506 Message headers: a note from the grass roots To: MsgGroup at ISI CC: Header-People at MIT-AI Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 18 Apr 1977 18:16:37 Brian Reid Just thought I would forward this without further comment. Begin forwarded message - - - - - - - - - Date: 7 Apr 1977 1712-EST From: Bob Chansler at CMU-10A Reply-To: Cheese Coop at CMU-10A Subject: Re: Close, but no cigar To: BRIAN.REID at CMU-10A CC: Chansler@CMU-10A Sender: BOB.CHANSLER at CMU-10A Message-ID: [CMU-10A] 7 Apr 1977 17:12:49 Bob Chansler In-Reply-To: Your message of April 6, 1977 My-Seq-#: 39492094 Yr-Seq-#: 4992488 Class: A Subclass: MCMXLVII Author: RC12 Typist: Fred Terminal: TTY88 FE-L#: 44 Reason: Did Godzilla need a reason? Valid: Not before 12 Apr 1977 1321Z Suspend: After 19 Apr 1977 0000Z Spelling-errors-this-message: 0 Spelling-errors-to-date: 23 Weather: Light rain, fog. Forecast: Clearing by morning Psych-evaluation-of-sender: slightly unstable Security-level: Public Security-sublevel: 0 Authority-to-send: general Authority-to-rcv: general #-people-in-terminal-room: 12 XGP: UP-cutter not working Ht/Wt-sender: 76/205 Machines: M&Ms available but almond machine is empty M&Ms-Last-Nickel: 17 HDR-chksum: 032114567101 - - - - Brian, I do not understand your concern about the size of message headers. Bob. ------- End forwarded message ------- 10-MAY-78 22:14:12-PDT,823;000000000001 Mail-From: USC-ISI rcvd at 18-APR-77 1937-PST Date: 18 APR 1977 1927-PST Sender: FARBER at USC-ISI Subject: MSGGROUP# 507 A new terminal from TI From: FARBER at USC-ISI To: pc at RAND-UNIX Cc: [ISI]Mailing.List: Message-ID: <[USC-ISI]18-APR-77 19:27:46.FARBER> In the Wall Street journal of 18 April 1977, TI announced a new terminal weighting 17 lbs and containing 20000 characters of Bubble memory ( non-volital of course). The memory can be used during the day to store from 16 to 20 pages of text which can then in the evening be transmitted to the computer and visa versa. ( a liberal quoting of the WSJ). Cost is $2995. Additional memory available at $500 per 20,000 characters up to 80000. Delivery 4 th quarter 77. Closer and closer we get !!!! Dave ------- 10-MAY-78 22:14:12-PDT,1004;000000000001 Mail-From: OFFICE-1 rcvd at 19-APR-77 2019-PST Date: 19 APR 1977 1511-PST Sender: PANKO at OFFICE-1 Subject: MSGGROUP# 508 Name that Medium From: PANKO at OFFICE-1 To: [ISI]Mailing.List: Message-ID: <[OFFICE-1]19-APR-77 15:11:54.PANKO> I am looking for a name to call the tyype of system I am using now. Is it a message service? Perhaps, but in advanced systems like Journal Mail, and in real-life mail systems, the average "message" is 3 pages. Hardly a message. Then there is computer mail, but mail denotes transmission, and transmission is really a small part about what this medium is all about. Probablyb between 70% and 90% of all HERMES costs relate to message processing before and after transmission. I am currently leaning toward Communication Processing System (CPS) or Message Processing System (MPS). Neither is very catchy. Do any of you have better ideas about what to call systems like SNDMSG, HERMES, MIT-DMS, MS, MSG, etc.? ------- 10-MAY-78 22:14:12-PDT,2539;000000000001 Mail-From: MIT-DMS rcvd at 20-APR-77 0823-PST DATE: 20 APR 1977 0731-EST FROM: JFH at MIT-DMS SENDER: JFH at MIT-DMS SUBJECT: MSGGROUP# 509 MESSAGE HEADERS AND SOCIAL CONVENTIONS ACTION-TO: MSGGROUP at USC-ISI, VONGEHREN at OFFICE-1 MESSAGE-ID: <[MIT-DMS].50162> I think you have hit on a very good point -- that electronic mail headers require adoption of conventions and social rules. Part of the source of the message header battle stems from the fact that we are really trying to define social conventions as well as machine-interaction conventions, at the same time, using the same mechanism. The best example of this is the continued conflict between those who want short, succint message headers that they can scan easily (one social convention, analogous to return address and postmark), those who want verbose, complete headers, which tell everything about the environment in which the message was sent, and those who want verbose, but syntactically precise message headers, likewise with lots of information, but in a form which is easily and reliably processable by computer programs. I doubt that the disagreements will ever be resolved in a single mechanism, or protocol for headers, since there are too many conflicting requirements, and no one will be pleased with the compromise. It might be more profitable to consider a mail-transfer mechanism which permits several different modes of transfer. Ideally, the mode would be picked by the receiver, either individually or on a host-specific basis, depending on which available option is desired and/or supported. This would require some minor changes to FTP protocols (Ken Harrenstien proposed one possible implementation a while ago), which would permit a negotiation of the mode to be used. Users/systems who want 'short and sweet' headers could ask for them; those who want to send or receive complete headers, and those who want program-processable headers could express their preference. New modes could be introduced experimentally for evaluation, and so on. Of course, not all messages would arrive in the desired format, because it may not be supported by the sender, for example. But such a message transfer structure would permit social interactions to take over -- for example, a user who likes short headers would complain to the sender of verbose headers, exerting pressure to provide a short-header option which could be selected during the FTP negotiation. Jack Haverty (JFH@MIT-DMS) ------- 10-MAY-78 22:14:12-PDT,1515;000000000001 Mail-From: USC-ISIB rcvd at 20-APR-77 1134-PST Date: 20 APR 1977 1124-PST From: POSTEL at USC-ISIB Subject: MSGGROUP# 510 talk on "office of future" APR 21 @ UCLA To: stefferud at ISIA Date: 18 APR 1977 1146-PST From: NANCY Subject: "The office of the future"...by Dr. Warren Sterling...April 21, 1977...5:00-7:00 P.M. April 21, 1977 5:00-7:00 P.M. THE OFFICE OF THE FUTURE Dr. Warren Sterling Xerox Corporation 3400 Boelter Hall UCLA ABSTRACT Evolution in the business office will lead to increased use of electronic data processing systems in the areas of word processing and information services. An attendant challenge will be to provide new technological solutions to the classical image and document handling problems of creation, conversion, storage, retrieval, manipulation, and distribution. This presentation will examine some of these information handling problems and the technology of the office of the future which will deal with them. In particular, an experimental word processing system, utilizing a full page soft display and electronic filing, will be discussed. The system is organized with a distributed function architecture in which three autonomous processors each perform a specific set of functions. An overview of the hardware subsystems and the system software will be presented. ------- 10-MAY-78 22:14:12-PDT,2178;000000000001 Mail-From: USC-ISI rcvd at 20-APR-77 2318-PST Date: 20 APR 1977 2312-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 511 [KLH: Everything you wanted to know about FROM/TO/CC..] From: STEFFERUD at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]20-APR-77 23:12:48.STEFFERUD> Begin forwarded message -------------------- Date: 20 APR 1977 1908-EST From: KLH at MIT-MC (Ken Harrenstien ) To: Stefferud at USC-ISI Subject: Pls forward: Everything you wanted to know about FROM/TO/CC... Mail-From: MIT-MC rcvd at 20-APR-77 1610-PST Would you please inform the rest of the Msggroup that if they'd like to read about a bunch of spirited sluggers pounding an equine cadaver to smithereens, they are welcome to access the files KSC;HEADER OOMIN KSC;HEADER OMIN KSC;HEADER MINS on MIT-MC (no password required), which in that order form a transcript of the Header-people messages. Altogether they contain 503K chars worth of discussion about the same things people have recently been mentioning - but in greater depth and breadth than most people are likely to worry about. (For 10X types, that's about 196 disk pages) --Ken -------------------- End forwarded message *** COORDINATOR'S NOTE: Ken also asked me to announce whatever I know about RFC 724's status. All I know is that it is rumored that it should be out shortly, like in a week. This is not based on any authoritative information, but it is a lovely rumor. For those who do not know of it, RFC 724 is a Request For Comment which is supposed to contain rational solutions for the short term to many of the issues in our recent MsgGroup discussions. Also, it is supposed to provide staging for a move into more structured mail transmission standards. Lest anyone misinterpret my comments as less than enthusiastic about RFC 724, let me point out that Standards Development is exceedingly slow and painful work. We should applaud the effort of those who are working on RFC 724, and wish for them that the task was not so difficult and time consuming. Stef ------- 10-MAY-78 22:14:12-PDT,362;000000000001 Mail-From: USC-ISI rcvd at 21-APR-77 0017-PST Date: 21 APR 1977 0005-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 512 $Add Gumpertz@CMUA, Remove McLindon@ISI$ From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]21-APR-77 00:05:56.STEFFERUD> Stef [Note: Subject: $---$ means no addintional info in TEXT] ------- 10-MAY-78 22:14:13-PDT,2467;000000000001 Mail-From: SRI-KA rcvd at 21-APR-77 1106-PST Date: 21 Apr 1977 1104-PST From: Geoff at SRI-KA Subject: MSGGROUP# 513 "It is very distressing that present postal management ..." To: [ISI]Mailing.List: The following artical on EM appeared in the paper a bit ago, for those that might have missed it, here it is: [Geoff] AM-Electronic Mail, 320 By JEFFREY MILLS Associated Press Writer WASHINGTON (AP) - The Postal Service should begin offering electronic message service in addition to the traditional mail service, the chairman of the House Postal Service subcommittee said Wedensday. If it does not enter the electronic message field, the Postal Service ''will be faced by crippling losses in (mail) volume, skyrocketing rates, reductions in services and the need for greater government subsidies,'' said Rep. James M. Hanley, D-N.Y. ''It is very distressing that present postal management does not see the need to put greater emphasis on the research and development of new electronic message systems,'' he said. The Postal Service is studying whether to offer electronic mail service. Under this concept, a message would be transmitted electronically between post offices and a computer printout of the message would be delivered with the next day's mail. Such a service would save mail-handling expenses. However, the Postal Service has not determined whether it would be proper for it to compete against private companies that are beginning to offer electronic message services. ''I fear that the Postal Service, if left to its own devices, would study the issue of electronic transfer until the agency was obsolete,'' Hanley said at a subcommitee hearing. ''It would be deciding whether or not to move when the private sector had cornered the market.'' Hanley said, ''We are entering a new era of communications'' and urged the Postal Service to ''adapt to a new environment in the communications field.'' Roger Salaman, a Commerce Department technology researcher, agreed that mail volume will go down due to ''cost trends which increasingly favor electronic modes of communications.'' Salaman told the panel that the financial problems of the deficit-ridden Postal Service cannot be attributed to inefficient management. ''Rather, the problem is more accurately identified as the result of changing technology,'' he said. Comments Ra3y/Stef? ------- 10-MAY-78 22:14:13-PDT,1882;000000000001 Mail-From: USC-ISI rcvd at 21-APR-77 1307-PST Date: 21 APR 1977 1242-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 514 Re: "It is very distressing that present Subject: postal management ..." From: STEFFERUD at USC-ISI To: Geoff at SRI-KA Cc: [ISI]Mailing.List: Message-ID: <[USC-ISI]21-APR-77 12:42:55.STEFFERUD> In-Reply-To: Your message of APRIL 21, 1977 Hi Geoff, per you request for comment - It seems to me that the Honourable Congresspeople and others reported in the "AM-Electronic Mail, 320" Article are missing a vital conceptual point, to wit: Reduction from a paper media (analog in basic form) to electronic media (digital in basic form) and back to paper (analog again) is not ever going to be cheap. It will also not ever be very fast if it retains use of the traditional foot powered "local loop" of the USPS for final delivery, hence it will not suffice for first class mail in the future. It has occurred to me that we are fast reaching a stage where "keystroke" conservation is becoming vital. It will not be reasonable to reduce captured keystokes from their basically digital character, to paper analog forms for hand delivery. It is my opinon that the advent of the "home" computer, which will also become the "personal" computer for both home and office, will make the perfect "mailbox" for electronic mail, and that the part of the USPS which does home delivery is one of the key parts to be bypassed by electronic mail. It reminds me of the automation of garbage collection, as pointed out by Herb Simon in his book on "The Shape of Automation." Automatic gargage collection is relatively untinkable until you conceive of the in-sink disposer. The key is not in automating the bag/can/truck/person mechanism. It is in bypassing them. More? Stef ------- ------- 10-MAY-78 22:14:13-PDT,1246;000000000001 Mail-From: CMU-10A rcvd at 22-APR-77 0457-PST Date: 22 Apr 1977 0112-EST From: Brian Reid at CMU-10A Subject: MSGGROUP# 515 what else does anybody ever talk about--message headers To: MsgGroup at ISI Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 22 Apr 1977 01:12:58 Brian Reid As I watch with great amazement as the proposals and counter-proposals roll past my screen in the MsgGroup mail, I keep asking myself the following silly little question. Maybe somebody can help. Given that essentially all of us use fancy programs for reading our mail, and given that these programs can print out the mail any way they see fit, then why can't people simply configure their message-printing programs to not print those pieces of the header that they find unworthy. As long as everybody uses the same format (talk about a pipe dream), then one's mail-reading program can just print out the parts meeting the esthetic requirements of the individual mail user. Go ahead and put in 34 different header fields. All I ever really want to look at is FROM and DATE, for example. Maybe I'm missing a point in a big way. But then again, maybe simple answers are the least obvious. Brian Reid ------- 10-MAY-78 22:14:13-PDT,1856;000000000001 Mail-From: OFFICE-1 rcvd at 22-APR-77 1234-PST Date: 22 APR 1977 1228-PST Sender: WALSH at OFFICE-1 Subject: MSGGROUP# 516 CONTENTS OF SUBJECT FIELDS From: WALSH at OFFICE-1(WILL MARTIN) To: HEADER-PEOPLE at MIT-MC, MSGGROUP at USC-ISI Cc: WALSH, STEFFERUD at USC-ISI Message-ID: <[OFFICE-1]22-APR-77 12:28:26.WALSH> THIS IS JUST A COMMENT, INSPIRED BY OUR RECENT PERUSAL OF THE MSGGROUP AND HEADER-PEOPLE ARCHIVES. THIS HAS BEEN FASCINATING READING, AND THE INFORMATION WE HAVE GLEANED WILL BE OF GREAT HELP IN OUR FUTURE WORK. HOWEVER, IN THESE FILES OF MESSAGES, IT HAS OFTEN BEEN VERY DIFFICULT TO LOCATE ALL THE MESSAGES ABOUT ITEMS OF INTEREST WITHOUT ACTUALLY READING EVERY MESSAGE IN THE FILES. THIS CAN BE QUITE A TASK, CONSIDERING THE 450+ MESSAGES IN MSGGROUP, FOR EXAMPLE. CONSEQUENTLY, I OFFER THE FOLLOWING SUGGESTION: IN THESE GROUP-CONFERENCE TYPES OF MESSAGE EXCHANGES, PAY CLOSE ATTENTION TO THE CONTENTS OF THE SUBJECT: FIELD YOU CREATE. LOOK AT IT WITH THIS QUERY IN MIND--"WILL THIS MAKE SENSE TO SOMEONE LOOKING AT A LISTING OF MESSAGE HEADERS 6 MONTHS FROM NOW?" THE "RE:" TYPES OF SUBJECTS WILL BE CLEAR IF THE ORIGINAL MESSAGE SUBJECT WAS CLEAR; THE ONLY PROBLEM THERE ARISES WHEN THERE HAS BEEN A STRING OF REPLIES, EACH OF WHICH NESTS THE ORIGINAL SUBJECT IN ANOTHER LEVEL OF "RE:". IF YOU ARE ADDING A MESSAGE TO ONE OF THESE CONFERENCE FILES, COPYING ONE SOMEONE ELSE HAS SENT YOU, FOR EXAMPLE, USE AN EDITOR TO CHANGE THE SUBJECT: FIELD IF IT ISN'T CLEAR, OR IS AN IN-GROUP JOKE. I HOPE THIS DOESN'T OFFEND ANYONE; THESE FILES ARE A VALUABLE INFORMATIONAL RESOURCE, AND I'M JUST LOOKING TOWARD MAKING THE RETRIEVAL OF THIS INFORMATION AS FAST AND COMPLETE AS POSSIBLE. REGARDS, WILL MARTIN (WALSH AT OFFICE-1). ------- 10-MAY-78 22:14:13-PDT,983;000000000001 Mail-From: USC-ISI rcvd at 22-APR-77 1756-PST Date: 22 APR 1977 1636-PST Sender: FARBER at USC-ISI Subject: MSGGROUP# 517 A reply to msggroup 516 RE: CONTENTS OF SUBJECT FIELDS From: FARBER at USC-ISI To: Walsh at OFFICE-1(Attn: Will_Martin) Cc: header-people at MIT-MC, Cc: [ISI]Mailing.List: Message-ID: <[USC-ISI]22-APR-77 16:36:49.FARBER> Keywords: msg516,keywords Will, While I think your comments are very appropriate re some of the rather "interesting" subject fields, there is a field defined in message text called KEYWORDS . This field is serviced by some of the more "advanced" message systems and allows the inclusion of keywords ala CACM. Perhaps , in fact, it is necessary to create and maintain a list of keywords like the ACM and IEEE to allow more organized handling of large message files. Indeed perhaps some of the more interesting ideas in auto-keyword generation are worth looking at . Dave ------- 10-MAY-78 22:14:13-PDT,867;000000000001 Mail-From: USC-ISI rcvd at 22-APR-77 1810-PST Date: 22 APR 1977 1716-PST Sender: DCROCKER at USC-ISI Subject: MSGGROUP# 518 Re: [Reid: MSGGROUP# 515 what else does anybody ever talk... From: DCROCKER at USC-ISI To: MSGGROUP, To: [ISI]Mailing.List: Message-ID: <[USC-ISI]22-APR-77 17:16:40.DCROCKER> In-Reply-To: <[USC-ISI]22-APR-77 14:49:10.STEFFERUD> Alas, your point is entirely reasonable and, in fact, the basis of much of the current header-definition effort. The standard counter is that there are a significant number of systems (MSG, for example) which merely dump out the entire text of the message. For users of these systems, the maze of fields is bewildering. However, much of the problem should go away soon, when 2d-generation (or are they 3d-generation?) get distributed. (It says here...) Dave. ------- 10-MAY-78 22:14:13-PDT,828;000000000001 Mail-From: OFFICE-1 rcvd at 23-APR-77 0810-PST Date: 23 APR 1977 0800-PST Sender: PANKO at OFFICE-1 Subject: MSGGROUP# 519 Re: [Reid: MSGGROUP# 515 what else does anybody ever talk... From: PANKO at OFFICE-1 To: MSGGROUP at USC-ISI Message-ID: <[OFFICE-1]23-APR-77 08:00:12.PANKO> In-Reply-To: <[USC-ISI]22-APR-77 14:49:10.STEFFERUD> I agre whole heartedly. I don't care what your system dumps into my file. In fact, I rather like having the info around somewhere. But I sure don't want to wait five minutes while the syystem gives me the header of something I don't want to read. NLS Journal mail prints just a few things in the header (albeit pretty weird things) and puts the rest of the information at the end of the message in a way that is invisible under normal circumstances. ------- 10-MAY-78 22:14:13-PDT,1008;000000000001 Mail-From: OFFICE-1 rcvd at 25-APR-77 0557-PDT Date: 25 APR 1977 0545-PDT Sender: VONGEHREN at OFFICE-1 Subject: MSGGROUP# 520 THE NEED FOR MEANINGFUL SUBJECTS From: VONGEHREN at OFFICE-1 To: MSGGROUP at USC-ISI Message-ID: <[OFFICE-1]25-APR-77 05:45:05.VONGEHREN> In-Reply-To: <[USC-ISI]22-APR-77 14:53:08.STEFFERUD> Reference: [MARTIN: MSGGROUP# 516 CONTENTS OF SUBJECT FIELDS] Keywords: SOCIAL CONVENTIONS, HEADER DICIPLINE AAH YES. HOW ONE SELECTS THE SUBJECT IS IMPORTANT; I'VE BEEN TRYING TO TELL MY CORRESPONDANTS THIS FOR SOME TIME NOW. I'M WELL AWARE THAT NO TWO PEOPLE THINK ALIKE, AND THEREFORE WILL NOT USE THE SAME "EXACT" WORDING FOR MESSAGE SUBJECTS, BUT TO BE TOTALLY UNCONCERNED WITH ANOTHERS FUTURE RETRIEVAL NEEDS (WHEN SELECTING YOUR SUBJECT) IS RATHER UN-SOCIAL. SPONTANEITY IS INHERENT IN THE NATURE OF A GOOD MESSAGE SYSTEM; SLOPPINESS OF THOUGHT IS A HUMAN TRAIT. PEACE- ED ------- 10-MAY-78 22:14:14-PDT,1179;000000000001 Mail-From: OFFICE-1 rcvd at 25-APR-77 0621-PDT Date: 25 APR 1977 0614-PDT Sender: VONGEHREN at OFFICE-1 Subject: MSGGROUP# 521 PERSONAL VIEW OF MESSAGE HEADERS From: E. VON GEHREN To: MSGGROUP at ISI Message-ID: <[OFFICE-1]25-APR-77 06:14:58.VONGEHREN> I JUST WANT TO SHOW YOU ALL TWO VERSIONS OF A MESSAGE HEADER; ONE AS THE SYSTEM WOULD LIKE TO SHOW IT TO ME AND THE OTHER AS I SEE IT (BY PERSONAL CHOICE). RECENT Message 140 1701 chars Date: 22 APR 1977 1449-PST Sender: STEFFERUD at USC-ISI Subject: [Reid: MSGGROUP# 515 what else does anybody ever talk about--message headers] From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]22-APR-77 14:49:10.STEFFERUD> Mail-From: USC-ISI rcvd at 22-APR-77 1658-PST #140, 1701 chars Date: 22 APR 1977 1449-PST From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Subject: [Reid: MSGGROUP# 515 what else does anybody ever talk about--message headers] PEACE- ED PS. EVEN THOUGH I USUALLY VIEW ONLY THAT PART OF THE HEADER I'M INTERESTED IN, I STILL HAVE ACCESS TO THE WHOLE THING. /VG ------- 10-MAY-78 22:14:14-PDT,2095;000000000001 Mail-From: BBN-TENEXA rcvd at 25-APR-77 0907-PDT Date: 25 Apr 1977 1157-EDT Sender: HENDERSON at BBN-TENEXA Subject: MSGGROUP# 522 Re: CONTENTS OF SUBJECT FIELDS From: HENDERSON at BBN-TENEXA To: WALSH at OFFICE-1 Cc: Myer, Mooers, Vittal, Dodds, Cc: Farber at USC-ISI, Stefferud at USC-ISI Message-ID: <[BBN-TENEXA]25-Apr-77 11:57:35.HENDERSON> In-Reply-To: <[OFFICE-1]22-APR-77 12:28:26.WALSH> I appreciate your idea of taking thought in advance for the retrieval of messages in the future. However, I think there are two factors which have to be weighed against the technique you suggest: 1. It is often difficult to tell what (as seen in light of subsequent discussion) a message may turn out to be about. It is only the subsequent discussion, and the contents of other messages which really determine an appropriate subject. These are difficult to know at the time you prepare the message. 2. (A more subtle point about the medium.) One of the reasons that this medium of message communication is so popular is that the formality involved is kept to a minimum, allowing all to focus on the content rather than the form. This CONSIDERABLE reduction (as compared to other media) in the personal cost of making a comment creates a sense of easy "polylogue". Addition of constraints on form (such as picking an "appropriate" subject) can significantly increase the perceived psychic load, and therefore ought not to be introduced without careful thought about the impact such constraints may have upon the "feel", and therefore the use, of the medium. For these reasons, I see your suggestion as being more applicable to those who are maintaining a data base of messages. They can catalogue it with keywords, subjects, and structure for the ease of those coming along behind in a way which is impossible or undesireable for those creating the messages in the first place. Whatever organization you see in the MSGGROUP messages has been added after the fact by Stef (more power to him) in just such a fashion. Austin ------- 10-MAY-78 22:14:14-PDT,1124;000000000001 Mail-From: OFFICE-1 rcvd at 25-APR-77 1512-PDT Date: 25 APR 1977 1510-PDT From: PANKO at OFFICE-1 Subject: MSGGROUP# 523 Visible vs. Full Headers To: [ISI]Mailing.List: A brief follow-up on Ed's comment. In NLS Journal Mail, a great deal of information is collected, but only a little of the total header is displayed in the recipient's in box. If the reader needs more information about a header, he or she can go to the permanent access copy. In my ideal system, the user would select among a dozen or so standard headers or program his or her own. Certain information, such as the sender or SEEN/UNSEEN would only be displayed when they differ from default conditions. Perhaps we can implement something like Journal Mail's invisible information by havving an invisible field to hold all relevant information. The visible header would then give selected information, including such information as SENDER only when this differs from the FROM filed. The INVISIBLE FIELD would be standardized and would not normally be printed in the standard print or type commands. ------- 10-MAY-78 22:14:14-PDT,1867;000000000001 Mail-From: MIT-DMS rcvd at 25-APR-77 1732-PDT DATE: 25 APR 1977 1455-EDT FROM: JFH at MIT-DMS SENDER: JFH at MIT-DMS SUBJECT: MSGGROUP# 524 Meaningful Subjects: meaningful to whom? ACTION-TO: MSGGROUP at USC-ISI MESSAGE-ID: <[MIT-DMS].50441> The real question is, I think, how to attach flags to messages which will let the reader: a/ classify the message quickly when he first sees it b/ find it later quickly from anything ranging from a pile of paper to a data base retrieval system. The former is satisfied by the message header -- subject as well as author, etc., and is strongly affected by recent memory in a dialogue such as this one about subjects. I think it is unlikely that receivers will ever be totally satisfied with what the author puts in the subject, because minds work differently, people have different categories, etc. The author can of course choose hopefully meaningful subjects. The problem is aggravated however, when authors try to put data in the subject (or header in general) which is to be used for long-term retrieval keys -- e.g. MSGGROUP 520, which I doubt will ring any bells in anyone's head in a month or so, but might be useful for someone researching th idea of subject fields, who has previously found 520. This is another example of conflicts of interests in header field usage -- short term versus long term retrieval/classification keys. What I hope for is a system which permits me, on receiving a message, to edit the header (or append new fields to it), so that my copy will be organized/filed in a way that is personally useful. I think that splitting issues such as this into header-related items and ignoring the possibilities of programs to help is somewhat dangerous. Jack Haverty ------- 10-MAY-78 22:14:14-PDT,1102;000000000001 Mail-From: USC-ISI rcvd at 25-APR-77 2050-PDT Mail-From: CMU-10A rcvd at 25-APR-77 2040-PDT Date: 25 Apr 1977 2338-EST From: Brian Reid at CMU-10A Subject: MSGGROUP# 525 Introduction for Brian Reid (Reid@CMUA) To: Stefferud at ISI CC: Reid@CMU-10A Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 25 Apr 1977 23:38:45 Brian Reid In-Reply-To: Your long-ago request for introductions. INTRODUCTION -- Brian K. Reid (REID at CMUA) I am a graduate student at Carnegie-Mellon University in Pittsburgh. I arrived there after spending numerous years in the airline software business, where I developed an interest in electronic message protocols and the like. My categorization in your menu of titles is "User". My research interests are in document production and what IBM likes to call "word processing", of which I view electronic mail as a vital component; I come to mail systems by viewing them as specialized document-formatters with a communications link. I also run our food coop; we mostly sell cheese and processed meats. Brian ------- 10-MAY-78 22:14:14-PDT,969;000000000001 Date: 26 APR 1977 1217-PDT From: STEFFERUD Subject: MSGGROUP# 526 Introduction for Einar Stefferud (Stefferud@ISI) To: MSGGROUP cc: STEFFERUD Mr Einar Stefferud is a computer management scientist and is President of Network Managment Associates, Inc. in Huntington Beach, California. His firm specializes in development of computer management structures and policies for business, government and educational institutions. He is currently involved in planning, development and installation of management structures for computer networks. In MsgGroup, he serves as the conference coordinator, and he maintains the record of the conference. In this role he is a "user" and a "critic" without portfolio. Outside of MsgGroup, NMA is involved in various aspects of message system developments, including design and evaluation of systems, and planning for installation and management of message systems in large organizations. ------- 10-MAY-78 22:14:14-PDT,693;000000000001 Mail-From: OFFICE-1 rcvd at 26-APR-77 1523-PDT Date: 26 APR 1977 1521-PDT From: PANKO at OFFICE-1 Subject: MSGGROUP# 527 Computer Inquiry Submission To: [ISI]Mailing.List: cc: rulifson at PARC-MAXC, metcalfe at PARC-MAXC, cc: taylor at PARC-MAXC, sutherland at PARC-MAXC, cc: day at OFFICE-1, bedford at OFFICE-1, atkinson at OFFICE-1, cc: leduc at OFFICE-1 I plan to submit comments in the FCC's Second Computer Inquiry. A draft will be available near the end of this month. If you wish to review it and provide suggestions, please let me know. I must ask, however, that your comments and my draft be kept completely confidential. Ra3y Panko ------- 10-MAY-78 22:14:15-PDT,902;000000000001 Mail-From: USC-ISI rcvd at 26-APR-77 1645-PDT Date: 26 APR 1977 1619-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 528 Reformatted version of MsgGroup# 490 Electronic message Subject: Systems for the USPS From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]26-APR-77 16:19:37.STEFFERUD> The original sumission of this message was in raw NLS format. The Proceedings copy has been replaced with an "output to termnal" copy of the original. This one is suitable for framing, for those who might care. Cheers, Stef -- Messages from file: [USC-ISI]MSGGROUP#.490;2 -- TUESDAY, APRIL 26, 1977 16:10:08-PDT -- 1 11 APR LEDUC at OFFICE-1 MSGGROUP# 490 Electronic Message systems for the U.S. postal service (14335 chrs) ------- 10-MAY-78 22:14:15-PDT,844;000000000001 Mail-From: CMU-10A rcvd at 26-APR-77 1704-PDT Date: 26 Apr 1977 1934-EST From: Brian Reid at CMU-10A Subject: MSGGROUP# 529 MsgGroup introductions Sender: BRIAN.REID at CMU-10A To: [ISI]Mailing.List - - - - Dear MsgGroup members, I recently looked at the INTRODUCTIONS file at ISI, hoping to find in it the introductions of most of MsgGroup, but was disappointed to find that only about 20 people seem to have come forward with an introduction. I really don't know who all of you are out there, nor can I imagine quite why there are so few introductions in the file. Maybe Stef is reluctant to prod people to provide intros, but I am not. Regardless of your role in MsgGroup, even if you only listen without actually participating, howabout sending in an introduction? Brian Reid ------- 10-MAY-78 22:14:15-PDT,1119;000000000001 Mail-From: BBN-TENEXA rcvd at 26-APR-77 1847-PDT Date: 26 Apr 1977 2145-EDT Sender: DDEUTSCH at BBN-TENEXA Subject: MSGGROUP# 530 Introduction for DDeutsch@BBNA From: DDEUTSCH at BBN-TENEXA To: MSGGROUP at ISI Cc: Brian.Reid at CMU-10A Message-ID: <[BBN-TENEXA]26-Apr-77 21:45:26.DDEUTSCH> Brian, you shamed me into it. I am a recent addition to the HERMES implementation staff. This makes me quite interested in both the thoughts of other people who design and build message systems and in the comments of those people who use them. I do not have the years of expertise that some members of the group seem to own. Many discussions which are generally found to carry a sense of deja vu are fresh and interesting to me because of this. I hope to contribute when I can add a fresh point of view. My prior experience includes work on on-line rapid large database retrieval. I also am an APL fan (though not one of those lunatics who thinks that you can and should do everything in it) and would be glad to compare notes on APL with anyone similarly inclined. ---Debbie Deutsch ------- 10-MAY-78 22:14:15-PDT,595;000000000001 Mail-From: UCLA-SECURITY rcvd at 27-APR-77 1611-PDT Date: 27 Apr 1977 1557-PDT Sender: rudisin at UCLA-Security Subject: MSGGROUP# 531 Introduction of Rudisin & request for information From: rudisin at UCLA-Security To: msggroup at isi I am Jerry Rudisin, a Master's degree student at UCLA working under Jerry Popek and am interested in the area of secure message systems, network protocols and the like. I am told that your group could point me to much literature in this area. If so please respond to rudisin at UCLA-Security and add me to your mailing list. Thanks. ------- 10-MAY-78 22:14:15-PDT,2089;000000000001 Mail-From: USC-ISIE rcvd at 27-APR-77 1653-PDT Date: 27 Apr 1977 1644-PDT From: POSTEL at USC-ISIE Subject: MSGGROUP# 532 Introduction of Jon Postel To: msggroup at ISIA cc: postel Hello: My name is Jon Postel and i am mostly a user and infrequently an implementer of message systems. My background with the ARPANET and with computer message system goes back a ways. The first time i played with a computer message system was in 1967. I first got involved in the ARPANET in 1968 when the UCLA Network Measurement Center began to plan to attach the first host to the ARPANET. Since that time i have been involved in protocol development for the ARPANET and more recently for other networks too. I have also been involved in development of operating systems and interactive applications programs. I am quite interested in the design of user command languages. I was at UCLA in the Network Measurement Center project working on operating systems, applications programs, and protocol design and implementation until September 73. Then i moved to MITRE-Washington where i did a survey of network control program inplementations. In July 74 i joined Keydata in Washington to update the network software in the data management system Keydata operates for ARPA. In September 74 i moved to SRIs Augmentation Research Center to work on the National Software Works project. ARC is the home of NLS which i came to know and love. In March 77 i moved to ISI where i am involved in a project evaluating protocols for internetwork communication. I currently serve as the coordinator of the "Request for Comments" series of ARPANET memos. I have been using various computer message system since they first became available to me. I use currently use MSG and NLS. I find i prefer command recognition modes that minimize keystrokes. I feel that applications programs (including messages systems) should be constructed so the user can choose the recognition mode she prefers. My mail box is "POSTEL@ISIB" --jon. ------- 10-MAY-78 22:14:15-PDT,1360;000000000001 Mail-From: USC-ISI rcvd at 29-APR-77 1023-PDT Mail-From: PARC-MAXC rcvd at 29-APR-77 0947-PDT Date: 29 APR 1977 0948-PDT From: JWHITE at PARC-MAXC Subject: MSGGROUP# 533 Introduction for Jim White (JWhite@PARC) Subject: and a change of address from White@ISIC to JWhite@PARC-MAXC To: stefferud at ISI cc: jwhite An Introduction I have been involved with the ARPANET since 1969. I implemented one of its first Network Control Programs on an IBM 360/75 while at UCSB. I contributed to the design of the current Host-Host, FTP, and RJE protocols. While at SRI I worked on the NLS Journal System. I'm interested (among other things) in the high-level protocols required to implement distributed systems such as network mail. Also while at SRI, I developed a high-level, application-independent procedure call protocol designed to support a large class of distributed systems (see proceedings of 1976 NCC). --Jim White A Change of Address I have left SRI-ARC and am now with Xerox in Palo Alto, where I will be involved in the design and implementation of Office Information Systems. I would like to remain plugged into the MSGGROUP dialog. Would you please, therefore, change [ISIC] to [PARC-MAXC] (note the leading "J") in the MSGGROUP distribution list. ------- 10-MAY-78 22:14:15-PDT,1305;000000000001 Mail-From: CMU-10A rcvd at 29-APR-77 1058-PDT Date: 29 Apr 1977 1348-EST Sender: BRIAN.REID at CMU-10A Subject: MSGGROUP# 534 Mail anomalies at various sites From: BRIAN REID(C410BR10) at CMU-10A To: MSGRP.DST - - - - Dear MsgGroup: I am curious as to whether or not the network community en masse notices the same "anomalies" in various sites' implementations of Mail and mail delivery that I see from CMU. Since TENEX mailers in their various forms are the de facto standard, it is sadly the case that whatever they do must be considered acceptable. However, even within TENEX sites, I have noticed that some places will take mail-files and some will only take them with login. Here at CMU we have resorted to the ghastly tactic of building and maintaining a local table of host characteristics that our mailer consults to find out what gyrations to go through in delivering mail to various sites. I really hope that all of the network sites don't have to do this, and I am curious as to how other non-TENEX sites cope with the problem, if at all. Does your site regularly send mail to many places? Do you experience periodic troubles with mail delivery to certain sites or classes of sites? Please let me know if it is just us. Brian Reid ------- 10-MAY-78 22:14:16-PDT,2210;000000000001 Mail-From: CMU-10A rcvd at 29-APR-77 1340-PDT Date: 29 Apr 1977 1612-EST From: Philip Karlton at CMU-10A Subject: MSGGROUP# 535 Could FTP error codes be appendix to RFC724 To: MsgGroup at ISI, Header-People at MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 29 Apr 1977 16:12:41 Philip Karlton I have no desire to hold up the final version of this long awaited RFC, but I do think it would be an advantage to the ARPA community at large if some consistency could be coerced accross sites as to what the correct error codes are. It would make the "dumb" FTP's a little more graceful in handling the return messages if they did not have to parse some arbitrary string to find out what happened. There are really only three cases: (a) it worked; (b) it didn't work this time but if you try again later it might; and (c) this will never work. I realize that there is some existing standard (I even saw it flashed accross my face once about a year ago.) but there are sites that do not adhere to it (including CMU for some cases). Here is a non-exhaustive list of failures for which I would like to know the correct code: No such user (please don't send this request again) Mail transfered correctly (for some ridiculous reason this is a different code for MAIL and MLFL) Must log in before sending mail (why not send the account and password back in some fixed format on this error and then no table of special cases need be maintained at each site) No job slots available Secondary storage full Transfers not allowed during busy time of day User exists but is not allowed to recieve mail MAIL allowed but not MLFL MAIL allowed with no log in but not MLFL with no log in (Should there be a difference between MAIL and MLFL?) ... It sure would be nice (from my point of view anyway) if a site would just force a local login if necessary when it gets a mail command if that is really what it wants. Phil Karlton ------- 10-MAY-78 22:14:16-PDT,2905;000000000001 Mail-From: USC-ISIB rcvd at 29-APR-77 1507-PDT Date: 29 APR 1977 1503-PDT From: POSTEL at USC-ISIB Subject: MSGGROUP# 536 Re: Could FTP error codes be appendix to RFC724 To: PhilipKarlton at CMU-10A, MsgGroup at ISI, To: Header-People at MIT-MC cc: POSTEL In response to the message sent 29 Apr 1977 1612-EST from Philip Karlton at CMU-10A to all: i believe that Phil's request to get out in the open all the really used responses that ftp servers make to mail requests is valuable. i hope that the exercise will be carried out as i believe it will lead to more consistent behavior on the part of the set of mail sending and receiving programs. for the record i have pulled together the responses the book say are legal. looking at them there seem to be altogether to many, and a few seem quite strange. but as i said for the record here they are: The "official" Protocol (the one in the protocol handbook) lists the following responses for the mail and mlfl commands, the commands are characterized as follows: 1xx positive preliminary reply 2xx positive completion reply 3xx positive intermediate reply 4xx transient negative completion reply 5xx permanent negative completion reply The responses for the MAIL command are: 250 Requested file action okay; completed. 354 Start mail input; end with . 421 Service not available 450 Requested file action not taken: file unavailable 451 Requested action aborted: local error in processing 452 Requested action not taken: insufficient storage space in system 500 Syntax error, command unrecognized 501 Syntax error in parameters or arguments 502 Command not implemented 530 Not logged in 550 Requested action not taken: file unavailable 552 Requested file action aborted: exceeded storage allocation 553 Requested action not taken: file name not allowed The responses for the MLFL command are: 125 Data connection already open: transfer starting 150 File status ok; about to open data connection 226 Closing data connection: requested file action successful 250 Requested file action okay; completed. 421 Service not available 425 Can't open data connection 426 Connection trouble, closed: transfer aborted 450 Requested file action not taken: file unavailable 451 Requested action aborted: local error in processing 452 Requested action not taken: insufficient storage space in system 500 Syntax error, command unrecognized 501 Syntax error in parameters or arguments 502 Command not implemented 530 Not logged in 532 Need account for storing files 550 Requested action not taken: file unavailable 552 Requested file action aborted: exceeded storage allocation 553 Requested action not taken: file name not allowed --jon. ------- 10-MAY-78 22:14:16-PDT,922;000000000001 Mail-From: CMU-10A rcvd at 30-APR-77 0938-PDT Date: 29 Apr 1977 1858-EST From: Rick Gumpertz at CMU-10A Subject: MSGGROUP# 537 FTP reply codes To: Karlton@CMU-10A, POSTEL at USC-ISIB CC: Header-people@MIT-MC, Stefferud@USC-ISI (for distribution to MsgGroup) Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 29 Apr 1977 18:58:11 Rick Gumpertz In-Reply-To: Your messages of April 29, 1977 Phil, Jon - It seems to me that the crux of the problem is that no one really knows what the standard is. My Protocol Handbook contains two sets of reply codes. Beside that, I am repeatedly told that many sites do not support the "new" (4 year old) FTP. What we really need is ONE clear standard, and some checking of who implements it. Maybe we should have a published monthly survey of FTP implementations, much like the old Telnet surveys. Peace, Rick Gumpertz ------- 10-MAY-78 22:14:16-PDT,4607;000000000001 Mail-From: SRI-KA rcvd at 1-MAY-77 0721-PDT Date: 1 May 1977 0721-PDT Sender: BOWERMAN at SRI-KA Subject: MSGGROUP# 538 ARTICLE ON ELECTRONIC MAIL IN "COMPUTER DECISIONS",APRIL 1977 From: dmis,anad To: MSGGROUP at ISI Cc: bowerman Message-ID: <[SRI-KA] 1-May-77 07:21:36.BOWERMAN> The April 1977 issue of "COMPUTER DECISIONS" has an excellent article by Stephen A. Caswell , Director of Development for International Resource Development (a New Cannan, Connecticut Market Research and Consulting firm) entitled "Electronic Mail Delivers". The author refers to development of two trends: 1. In the same manner that computer and communications Technologies are converging, the different types of information handled by these formerly separate systems are also converging. 2. The convergence of communication and computer Technologies will bring the Director of MIS from the somewhat specialized world of accounting and order-entry into the mainstream of business communications. The author discusses hard copy & paper-based business communications and points out that electronic data communications revenues have already surpassed those that the Postal Service receives as a business-to-business message carrier of first-class mail. Additionally, competition between the various systems is discussed. The article is well written and contains good discussion of the traditional as well as the newer products. The author concludes by predicting that by the mid 1980s, communicating word processors could be reduced in cost to about $1,000, or about the cost of a high grade office typewriter today. I am attaching my version of two charts shown in the article, since i think they are significant enough to warrant distribution in case you do not find the article. Tom Bowerman BUSINESS-TO-BUSINESS HARD COPY AND VISUAL MESSAGE MARKETS, 1977 48% = ELECTRONIC DATA COMMUNICATIONS 36% = POSTAL SERVICE (BUSINESS TO BUSINESS) 6% = TELEX/TWX 5% = FACSIMILE 3% = FAXGRAM, MESSAGE SWITCHING 2% = TELEGRAM TIME AND COST FOR EMMS (Electronic Mail & Message Systems) Note: You may want to connect the letters to make the following graph more readable. COST PER MSG $2.80+ W + + + + + + W $2.45+ + + + + + + T W T T $2.10+ + T + + + + + W T T T T $1.75+ + W + + + + + T T T T T T T T T W $1.40+ + + + + + + W W R $1.05+ + + + + + + R W M R M M M R M M M M W M M $ .70+ + R + + M M M M + + W M R M M M R W R W P W P $ .35+ + + R + W+ P P + + R P W P R P W P P P P P P R R W P P P P R R W R R W $ .00+ + + + + R + 1977 1979 1981 1983 1985 1987 NOTE: POLITICAL AND REGULATORY FACTORS MAY CHANGE THE TIME FRAME, BUT THE OUTCOME WILL BE THE SAME. P = U.S. POSTAL SERVICE R = REMOTE COPYING M = MAILGRAM W = COMMUNICATING WORD PROCESSOR T = TELEX/TWX ------- 10-MAY-78 22:14:16-PDT,311;000000000001 Mail-From: USC-ISI rcvd at 1-MAY-77 1705-PDT Date: 1 MAY 1977 1628-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 539 $Change BOWERMAN@BBNB to be BOWERMAN@SRI-KA$ From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI] 1-MAY-77 16:28:09.STEFFERUD> STEF ------- 10-MAY-78 22:14:16-PDT,401;000000000001 Mail-From: USC-ISI rcvd at 2-MAY-77 1509-PDT Date: 2 MAY 1977 1420-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 540 $ Add JWalker@NBS-10, DBall@BBNB $ From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Cc: JWalker at NBS, DBall at BBNB Message-ID: <[USC-ISI] 2-MAY-77 14:20:59.STEFFERUD> [Note - $----$ in subject field indicates empty text field.] Stef ------- 10-MAY-78 22:14:16-PDT,2702;000000000001 Mail-From: DEC-MARLBORO rcvd at 3-MAY-77 1936-PDT Date: 3 May 1977 2234-EDT From: RICART at DEC-MARLBORO Subject: MSGGROUP# 541 Introduction for Glenn Ricart (DGR@SU-AI) To: stefferud at ISI Introduction for Glenn Ricart My interest in MAIL systems stems back to 1971 when I wrote a MAIL system in SAIL for non-ARPAnet DECsystem-10s. It had basic capabilities for sending, receiving, holding, deleting, and forwarding MAIL. It was originally installed at the National Institutes of Health, but special versions were soon spun off by the National Security Agency and the Brookings Institution for use on their machines. Other people probably ran it also; I don't remember. NSA and Brookings each made improvements to the original SAIL code, and vigorous use at NIH brought forth numberous improvements at NIH also. Beginning in 1974, a new MAIL system for the same audience was written by me in assembler with substantial improvements as a result of lessons learned from the original version and constant suggestions and comments. This version of the NIH mail system is now in use at many non-ARPAnet DEC-10 installations. I believe that it is the best non-ARPAnet MAIL system for the DEC-10. Over 25 other installations have requested copies to date. Development on the NIH mail system is proceeding primarily at NIH and the University of Texas at Austin. Developmental contributions have also been received from the University of Louisville and The Catholic University, and bug reports and minor fixes and enhancements have been produced in numerous locations. A long delayed new version of NIH mail will be worked upon during the summer of 1977. I'm getting into the MSGGROUP to avoid making mistakes that anyone else has made and to try to glean the best of the prevailing ideas. I am coorperating with Stanford University in the development of DIALNET, and I hope that a variant of the NIH mail system will be used on DIALNET. I am the Working Group Chairman for DECsystem-10/20 Networks and Communications for DECUS, the DEC users' group, and co-publish the NETSIG newsletter. The Working Group is currently engaged in a project to register user-built networks, especially those constructed using DEC-10/20; this registry will be used by others who are going to set up their own networks. My other technical interests are in communications technology and protocols, operatings systems, synchronization problems in networks, computer conferencing systems, and solutions to the mutual exclusion problem. My non-technical interests include Frisbee freakdom, hiking, computer games, photograph, and electronics. ------- 10-MAY-78 22:14:17-PDT,1630;000000000001 Date: 4 MAY 1977 1703-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 542 FUNCTIONS OF COMPUTER CORRESPONDENCE SYSTEMS From: CARLISLE at USC-ECL To: MSGGROUP Message-ID: <[USC-ISI] 4-MAY-77 17:03:55.STEFFERUD> Several graduate students and I are conducting a national survey of the functions of Computer Correspondence. The results will be published in the early fall of this year. Your participation in this survey is strongly encouraged so that the system you are working on will receive the proper attention. In the first part of this survey, which was completed in March, we obtained user manuals for over 20 Computer Correspondence Systems. Analysis led to the derivation of a functional description of current and future Computer Correspondence Systems. This was reported in the Electronic Mail Session at Interface '77 in Atlanta this spring. I would like to invite you to join the other system developers and expert users in describing your system in terms of these functions. Please let me know as soon as possible if you want to participate in this attempt to accurately describe the emerging market of Computer Correspondence Systems to the public. (If you do, please specify whether you prefer to receive the survey form on-line or in hardcopy form.) Participants will, of course, receive a copy of our summary. Jim Carlisle Assistant Professor, USC/ Annenberg School of Communications Co-Director, PhD Program on Human Interaction With Computers (REPLY TO: Carlisle @ ECL) ------- ------- 10-MAY-78 22:14:17-PDT,900;000000000001 Mail-From: SRI-KA rcvd at 7-MAY-77 0101-PDT Date: 7 May 1977 0052-PDT From: Geoff at SRI-KA Subject: MSGGROUP# 543 What's in a name OR A rose by any other name... To: [ISI]Mailing.List: cc: Network-Liaison-Group: We are pretty disgusted with the current flavor of Tenex message systems, and have decided its time for a brand spanking new one, so here is your chance for fame, glory, and immortality. If you have a fantastic idea(s) for a message system, we'd like to hear about it. We are also currently looking for a super-winning name to call this message system. The only limitation is that it be 6 characters or fewer so that it will show up nicely in SYSTAT listings. Your message system name suggestion, and/or ANY and all great ideas for a message system in the creation process can be sent to: GEOFF@SRI We're interested in YOUR ideas.... ------- 10-MAY-78 22:14:17-PDT,1237;000000000001 Mail-From: OFFICE-1 rcvd at 9-MAY-77 1002-PDT Date: 9 MAY 1977 0942-PDT From: PANKO at OFFICE-1 Subject: MSGGROUP# 544 Plea for Standard Terminology To: [ISI]Mailing.List: cc: rulifson at PARC-MAXC, taylor at PARC-MAXC, cc: sutherland at PARC-MAXC, day at OFFICE-1 Besides protocol variances, it is also common for various sites to use the same term in different ways. I propose that we all adopt the following definitions and keep things strict. CONFERENCE - a place where conversation is substituted for the dreariness of work and the loneliness of thought. PROGRAM - any assignment that can't be completed in one telephone call. EXPEDITE - to compound confusion with commotion. CHANNELS - trails left by interoffice memos. ACTIVATE - to make carbons and add more names to the memo. RE-ORIENTATION - getting used to work again. RELIABLE SOURCE - the guy you just met. INFORMED SOURCE - the guy who told the guy you just met UNIMPEACHABLE SOURCE - the guy who started the rumor originally. GIVE SOMEONE THE PICTURE - a long, confused and inaccurate statement to a newcomer. Should I change this into an RFC? It's a lot better than most I've seen. Aloha. Ra3y ------- 10-MAY-78 22:14:17-PDT,2309;000000000001 Mail-From: SUMEX-AIM rcvd at 10-MAY-77 1658-PDT Date: 10 MAY 1977 1643-PDT From: Kahler at SUMEX-AIM Subject: MSGGROUP# 545 Re: What's in a name... To: Geoff at SRI cc: [ISI]Mailing.List: Geoff, Regarding your request for message-system ideas: MSGGROUP would probably like to know what you don't like about what is available, and what your reply to your own message would be. I have a lot of features in our bulletin board system of a human engineering nature which I would recommend to you. (BBD is the bulletin reader, POST is the bulletin poster which also sends local mail.) POST lets you go back and change sections of the message, e.g. add someone to the cc list. You can edit the middle of any of these sections by putting the latter portion in a "reserve buffer" a character, word or line at a time or all at once and get it back the same way. This looks great on a Datamedia. POST lets you retype all sections of your message or bulletin at once (to, cc, subject, message) as well as the one you are currently working on. This is all done by assigning control characters (which are about all assigned by now) to each function. With regard to the message reader-manipulator, I do not favor one-letter commands that are grabbed and spelled out by the program. I am not so conservative of keystrokes that I care nothing for the poor user who wants to back up. To me it is well worth the programming effort to have the help features that BBD has. They include command recognition with , partial matches of commands and topic names with "?", the ability to type "?" anywhere in a multiple-field command and get SOMETHING, a help system that gives command-specific help without delay, and a good line-editor that supports display terminals. BBD is getting a better line editor and command parser that will have POST's reserve buffer stuff in it. The basic idea is that a user who knows that is used to end commands, that he can type "?" to get help and who knows what a control character is should be able to sit down and run a program and find out what it does, how to ask for what he wants, and where to find on-line documentation. My name suggestion for your message system is "MESS". Rich ------- 10-MAY-78 22:14:17-PDT,2388;000000000001 Mail-From: OFFICE-1 rcvd at 11-MAY-77 0741-PDT Date: 11 MAY 1977 0729-PDT Sender: WALSH at OFFICE-1 Subject: MSGGROUP# 546 ABSENTEE ADDRESSEES From: WALSH at OFFICE-1 To: MSGGROUP at USC-ISI Cc: STEFFERUD at USC-ISI, WALSH Message-ID: <[OFFICE-1]11-MAY-77 07:29:40.WALSH> A QUESTION HAS COME UP THAT MIGHT BE OF INTEREST TO MSGGROUP, AND I'M WONDERING IF THE SUBJECT HAS BEeN DISCUSSED IN PAST EXCHANGES. THIS IS ORIENTED TOWARD OFFICIAL MAIL, WHICH IS INTENDED TO BE DELIVERED TO A POSITION RATHER THAN TO AN INDIVIDUAL (EVEN THOUGH THE ADDRESS INCLUDES AN INDIVIDUAL'S NAME). THERE DOESN'T SEEM TO BE MUCH OF ANY PROVISION MADE FOR CONTINUTY IN NETWORK MAIL DELIVERY WHEN INDIVIDUALS LEAVE. I HAVE JUST TRIED TO SEND A MESSAGE TO A BBN PERSON (CROWTHER) WHO SEEMS TO HAVE LEFT THE NET. THE ORIGINAL REFERENCE I HAD ONLY HAD HIS NAME, WITH NO OTHER INFORMATION. IF I HAD BEEN WRITING A LETTER TO BE MAILED TO HIS OFFICE, IT WOULD BE SHUFFLED AROUND AND MIGHT EVENTUALLY REACH THE NEW PERSON WHO HAS ASSUMED HIS DUTIES. WITH NET MAIL, THERE IS NO SUCH PROVISION--DELIVERY FAILS, AND THE MESSAGE RETURNS TO ME AS /UNDELIVERABLE-MAIL/.ETC. WHAT OPTIONS DO I HAVE IN A SITUATION LIKE THIS? I HAVE CHECKED THE ARPANET DIRECTORY (JULY 76) AND NLS ON-LINE INFORMATION, AND THE INDIVIDUAL CANNOT BE FURTHER TRACED. I HESITATE TO IMPOSE ON SOME OTHER, ARBITRARILY-PICKED, BBN PERSON; THAT IS, SENDING THE ORIGINAL MESSAGE TO THEM AND ASKING THAT THEY DO THE WORK OF FINDING OUT TO WHOM TO FORWARD THE ITEM. I THINK THAT WHAT WE NEED HERE IS A GENERAL OFFICE ADDRESS (LIKE "MAIL-DELIVERY AT BBN", FOR EXAMPLE, OR "GENERAL-DELIVERY-ARPANET" AT SOME HOST FOR THE ENTIRE NET) TO USE IF PERSONAL ACCOUNT DELIVERY ATTEMPTS FAIL. IS THERE SOMETHING LIKE THIS ALREADY IN EXISTENCE? COULD THIS BE THE RESPONSIBILITY OF THE NETWORK INFORMATION CENTER? THIS WOULD SEEM TO INVOLVE LESS OVERHEAD THAN SOME SORT OF AUTOMATIC INTERCEPT AND FORWARDING ROUTINE, WHICH IS ANOTHER WAY OF SATISFYING THE NEED. WHAT DO YOU ALL THINK? IS THE PROBLEM PREVALENT ENOUGH TO WARRANT ANY WORK ON IT, OR RARE ENOUGH TO IGNORE? REGARDS, WILL MARTIN (WALSH AT OFFICE-1) ------- 10-MAY-78 22:14:17-PDT,461;000000000001 Mail-From: UCLA-SECURITY rcvd at 11-MAY-77 1558-PDT Date: 11 May 1977 1529-PDT Sender: steve at UCLA-Security Subject: MSGGROUP# 547 Introduction of Steven Abraham From: steve at UCLA-Security To: stefferud at isi my name is steven abraham, and i work in the security group under jerry popek at UCLA. i currently am involved in network security, and now have an interest in message systems in general. please add me to your mailing list. ------- 10-MAY-78 22:14:17-PDT,987;000000000001 Mail-From: USC-ISI rcvd at 12-MAY-77 1602-PDT Date: 12 MAY 1977 1548-PDT Sender: CAHCOM at USC-ISI Subject: MSGGROUP# 548 Availability of RFC #724: Subject: Proposed Official Standard for Subject: the Format of ARPANET Messages From: Pogran at MIT-Multics, Vittal at BBN-TenexA, DCrocker at Rand-Unix From: Henderson at BBN-TenexD To: Walker Cc: Postel at USC-ISIB, Cahcom-steering-committee-members:, Cc: [ISI]Mailing.List:, Cc: [BBNA]MAILINGLIST: Message-ID: <[USC-ISI]12-MAY-77 15:48:04.CAHCOM> RFC 724, "Proposed Official Standard for the Format of ARPA Network Messages", is at last available. It is located in the file [USC-ISIA]RFC724.TXT with read-access for all. Copies can be retrieved through FTP by using a user name of ANONYMOUS and your last name as the password. The file is 82K characters long, which is 39 printed pages. Ken Pogran John Vittal Dave Crocker Austin Henderson ------- 10-MAY-78 22:14:18-PDT,1539;000000000001 Mail-From: USC-ISIE rcvd at 13-MAY-77 1820-PDT Date: 13 May 1977 1816-PDT From: POSTEL at USC-ISIE Subject: MSGGROUP# 549 RFCs 724 & 729 Available To: [isie]Request-For-Comments.List: Request for Comments 724 is now available online at Office-1. The title is: "Proposed Official Standard for the Format of ARPA Network Messages". The authors are: Ken Pogran, John Vittal, Dave Crocker, and Austin Henderson. The document is 36 text pages long. This important document proposes standards to be used in the sndmsg headers that may have implications on many current mail processing programs, and may impact the kinds of messages system to be built in the future. Please send any comments and criticisms to any of the authors of this RFC by 15 June 1977. It is planned that the standard will be officially adopted by 1 September 1977, with hosts expected to accept its syntax by 1 January 1978. The document is available from Office-1 and may be copied via FTP. From your host you may connect to the Office-1 FTP server and access the document by first supplying the FTP username NICGUEST and password ARPA. The pathname of the document is: RFC724.TXT Also available at Office-1 is RFC729 titled "Telnet Byte Macro Option" authored by Dave Crocker. The pathname for this file is: RFC729.TXT This document 3 pages long and may be copied from Office-1 using the procedure described above. --jon. ------- 10-MAY-78 22:14:18-PDT,2488;000000000001 Mail-From: MIT-MULTICS rcvd at 16-MAY-77 0803-PDT From: Pogran at MIT-Multics Date: 05/16/77 1106-edt Subject: MSGGROUP# 550 Ways of combatting the "Absentee Addressee problem" To: MsgGroup at USC-ISI cc: Stefferud at USC-ISI Will, There are three kinds of mechanisms in use at various ARPANET hosts already to help combat the kind of problem you bring up in MSGGROUP # 546. These are: Position-oriented mailbox names, automatic forwarding,and "general delivery" service. A number of sites have the mailbox name "Liaison", for example, which is often an "extra name" on the ARPANET Liaison's mailbox. Here at MIT-Multics, whenever the Liaison changes, we move the mailbox name "Liaison" from the former Liaison's mailbox to the new Liaison's mailbox. This ensures that queries regarding resources available here at MIT-Multics, etc. will not be lost due to personnel leaving, going on vacation, etc. The automatic forwarding concept is perhaps less suited to combating the problem you described, but it, too can serve well under some circumstances. If a person handling a particular task leaves, mail arriving for him/her can be forwarded to someone else, perhaps the person who's taken over that task. Of course, this also results in the forwarding of personal mail for the person who has left, but this should not be a problem for, as we know, the ARPANET is not to be used for personal mail. Quite a few hosts seem to have "General Delivery" mechanisms these days, which cause mail for unknown recipients to be printed on a line printer, or something like that, and examined by an operator. This sort of thing does not interact well with current mail transmission protocols, however, because it is not easy to tell whether a reply of the form, "An operator will attempt to deliver your mail" is to be taken as SUCCESSFUL delivery or UNSUCCESSFUL delivery of the message. This often leads to consternation on the part of the sender, especially when the mail was routed to "general delivery" because of a simple, un-caught misspelling of a valid user's name. So, mechanisms exist on various hosts to help combat the problem. Can we work towards more general adoption of techniques like "position-oriented mailbox names"? Can we work towards uniform treatment of "general delivery", and its integration with mail-transmission protocols? I think that we can, slowly, and I think that we should. Ken Pogran ------- 10-MAY-78 22:14:18-PDT,7762;000000000001 Mail-From: USC-ISI rcvd at 17-MAY-77 0048-PDT Date: 17 MAY 1977 0012-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 551 [ISI]Proceedings.msg#501-#550 From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]17-MAY-77 00:12:25.STEFFERUD> -- Messages from file: [USC-ISI]PROCEEDINGS.MSG#501-#550;1 -- MONDAY, MAY 16, 1977 13:34:23-PDT -- 46 05/16/ Pogran at MIT-Multics MSGGROUP# 550 Ways of combatting the "Absentee Addressee problem" (2487 chrs) 45 13 May POSTEL at USC-ISIE MSGGROUP# 549 RFCs 724 & 729 Available (1538 chrs) 44 12 MAY Henderson at BBN-Tene MSGGROUP# 548 Availability of RFC #724: (986 chrs) 43 11 May steve at UCLA-Securit MSGGROUP# 547 Introduction of Steven Abraham (460 chrs) 42 11 MAY WALSH at OFFICE-1 MSGGROUP# 546 ABSENTEE ADDRESSEES (2387 chrs) 41 10 MAY Kahler at SUMEX-AIM MSGGROUP# 545 Re: What's in a name... (2308 chrs) 40 9 MAY PANKO at OFFICE-1 MSGGROUP# 544 Plea for Standard Terminology (1236 chrs) 39 7 May Geoff at SRI-KA MSGGROUP# 543 What's in a name OR A rose by any other name... (899 chrs) 38 4 MAY CARLISLE at USC-ECL MSGGROUP# 542 FUNCTIONS OF COMPUTER CORRESPONDENCE SYSTEMS (1630 chrs) 37 3 May RICART at DEC-MARLBOR MSGGROUP# 541 Introduction for Glenn Ricart (DGR@SU-AI) (2701 chrs) 36 1 May dmis,anad MSGGROUP# 538 ARTICLE ON ELECTRONIC MAIL IN "COMPUTER DECISIONS",APRIL 1977 (4606 chrs) 35 29 Apr RICK.GUMPERTZ at CMU- MSGGROUP# 537 FTP reply codes (921 chrs) 34 29 APR POSTEL at USC-ISIB MSGGROUP# 536 Re: Could FTP error codes be appendix to RFC724 (2904 chrs) 33 29 Apr PHILIP.KARLTON at CMU MSGGROUP# 535 Could FTP error codes be appendix to RFC724 (2209 chrs) 32 29 Apr BRIAN REID(C410BR10) MSGGROUP# 534 Mail anomalies at various sites (1304 chrs) 31 29 APR JWHITE at PARC-MAXC MSGGROUP# 533 Introduction for Jim White (JWhite@PARC) (1358 chrs) 30 27 Apr POSTEL at USC-ISIE MSGGROUP# 532 Introduction of Jon Postel (2088 chrs) 29 27 Apr rudisin at UCLA-Secur MSGGROUP# 531 Introduction of Rudisin & request for information (594 chrs) 28 26 Apr DDEUTSCH at BBN-TENEX MSGGROUP# 530 Introduction for DDeutsch@BBNA (1118 chrs) 27 26 Apr BRIAN.REID at CMU-10A MSGGROUP# 529 MsgGroup introductions (843 chrs) 26 26 APR MSGGROUP at USC-ISI MSGGROUP# 528 Reformatted version of MsgGroup# 490 Electronic message (901 chrs) 25 26 APR PANKO at OFFICE-1 MSGGROUP# 527 Computer Inquiry Submission (692 chrs) 24 26 APR To: MSGGROUP MSGGROUP# 526 Introduction for Einar Stefferud (Stefferud@ISI) (969 chrs) 23 25 Apr BRIAN.REID at CMU-10A MSGGROUP# 525 Introduction for Brian Reid (Reid@CMUA) (1100 chrs) 22 25 APR JFH at MIT-DMS MSGGROUP# 524 Meaningful Subjects: meaningful to whom? (1866 chrs) 21 25 APR PANKO at OFFICE-1 MSGGROUP# 523 Visible vs. Full Headers (1123 chrs) 20 25 Apr HENDERSON at BBN-TENE MSGGROUP# 522 Re: CONTENTS OF SUBJECT FIELDS (2094 chrs) 19 25 APR E. VON GEHREN MSGGROUP# 521 PERSONAL VIEW OF MESSAGE HEADERS (1177 chrs) 18 25 APR VONGEHREN at OFFICE-1 MSGGROUP# 520 THE NEED FOR MEANINGFUL SUBJECTS (1007 chrs) 17 23 APR PANKO at OFFICE-1 MSGGROUP# 519 Re: [Reid: MSGGROUP# 515 what else does anybody ever talk... (827 chrs) 16 22 APR DCROCKER at USC-ISI MSGGROUP# 518 Re: [Reid: MSGGROUP# 515 what else does anybody ever talk... (866 chrs) 15 22 APR FARBER at USC-ISI MSGGROUP# 517 A reply to msggroup 516 RE: CONTENTS OF SUBJECT FIELDS (982 chrs) 14 22 APR WALSH at OFFICE-1(WIL MSGGROUP# 516 CONTENTS OF SUBJECT FIELDS (1855 chrs) 13 22 Apr BRIAN.REID at CMU-10A MSGGROUP# 515 what else does anybody ever talk about--message headers (1245 chrs) 12 21 APR Stefferud at USC-ISI MSGGROUP# 514 Re: "It is very distressing that present (1881 chrs) 11 21 Apr Geoff at SRI-KA MSGGROUP# 513 "It is very distressing that present postal management ..." (2466 chrs) 10 20 APR Stefferud at USC-ISI MSGGROUP# 511 [KLH: Everything you wanted to know about FROM/TO/CC..] (2176 chrs) 9 20 APR POSTEL at USC-ISIB MSGGROUP# 510 talk on "office of future" APR 21 @ UCLA (1514 chrs) 8 20 APR JFH at MIT-DMS MSGGROUP# 509 MESSAGE HEADERS AND SOCIAL CONVENTIONS (2538 chrs) 7 19 APR PANKO at OFFICE-1 MSGGROUP# 508 Name that Medium (1003 chrs) 6 18 APR FARBER at USC-ISI MSGGROUP# 507 A new terminal from TI (822 chrs) 5 18 Apr BRIAN.REID at CMU-10A MSGGROUP# 506 Message headers: a note from the grass roots (1631 chrs) 4 18 APR E. VON GEHREN MSGGROUP# 505 FROM/SENDER HANGU (1597 chrs) 3 15 APR WALSH at OFFICE-1 MSGGROUP# 503 FROM/SUBJECT/TO/CC - ONE MORE TIME AROUND (1413 chrs) 2 15 APR MSGGROUP at USC-ISI MSGGROUP# 502 Separate Files of Large Messages (1471 chrs) 1 15 APR Stefferud at USC-ISI MSGGROUP# 501 [ISI]PROC EEDINGS.SURVEY#451-#500 (5623 chrs) ------- 10-MAY-78 22:14:18-PDT,307;000000000001 Mail-From: USC-ISI rcvd at 17-MAY-77 0144-PDT Date: 17 MAY 1977 0124-PDT Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 552 $Add JHannon@SRI-KA, Remove WClark@BBNB$ From: MSGGROUP at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]17-MAY-77 01:24:49.STEFFERUD> Stef ------- 10-MAY-78 22:14:18-PDT,486;000000000001 Mail-From: CMU-10A rcvd at 19-MAY-77 1737-PDT Date: 19 May 1977 2032-EDT Sender: BRIAN.REID at CMU-10A Subject: MSGGROUP# 553 Please ignore this message From: BRIAN REID(C410BR10) at CMU-10A To: MSGRP.DST cc: DIANA.BAJZEK - - - - I'm testing some obscure bug in our mailer, which seems only to fail on large distribution lists, and this is the only large distribution list that can reliably generate the error. Sorry for the bother. Brian. ------- 10-MAY-78 22:14:18-PDT,5118;000000000001 Date: 19 May 1977 1710-EDT From: MCKENZIE at BBN-TENEXE Subject: MSGGROUP# 554 RFC 724 To: MSGGROUP at USC-ISI cc: mckenzie Gentlemen, I have not read through the entire text of this RFC and tried to fully understand its implications; unfortunately I will almost certainly not have time to do so, prior to the announced deadline. Therefore I am at the disadvantage of trying to comment on a subject which is of great importance to me, without fully understanding what has been proposed. Nevertheless, there are some general comments which I feel must be made by someone. The following is my personal opinion. It is not the "official" opinion of my Division of BBN, all of BBN, or any other group. As some of you already know, I am not particularly enamored of change for the sake of change. I am not a hacker, and I haven't been inside the guts of a complex program for 10 years. I don't want to spend a lot of time trying to learn how to use a new system for doing things that I can already do; I want to be left alone by the system designers to do my job. To some extent, I believe this attitude is present in many members of the group who have been called "naive users". During the past few years I have been exposed to various PDP-10 based message systems. I currently use an old version of MSG exclusively, and learned to use it solely through the "HELP" and "?" commands. My impressions of the "sophisticated message handling/office automation" systems which seem to have inspired RFC 724 are that: - They have 2 or 3 times as much code as as MSG-level software (objective measurement); and take at least twice as much computer time to run as MSG-sized (subjectively). The contracts and jobs I'm currently working on CANT AFFORD more computer time. - It is common for these systems to have more than a shelf-inch of documentation which must be read before being able to use them. I haven't got time to read that much, and I certainly have no desire to do so. - Nevertheless, "standards" promulgated in RFC 680 (I'm extrapolating from comments previously made to arrive at this assertion) result in an increasing amount of "trash" in the headers of all the messages output by MSG which were input by these advanced systems. Until recently I had a 150 baud terminal. Each time I complained about the time spent typing headers, I was told that to eliminate the typeout of this trash I had to invest the one time effort, and the continuing computer cost, of switching to a more advanced system. Obviously, I recite these problems not to seek sympathy but because I think there are some lessons available to be extracted. First, the idea of creating greater and greater amounts of machine-parsable header information is pleasant to those seeking more and more "sophisticated" mail handling, but it comes at a cost. The cost is likely to be either: - burdening the user who doesn't choose a sophisticated parser with printing lots of junk on his potentially slow terminal (many of my co-workers still have old TTY 33's because their contracts can't support the purchase of new terminals,); or - burdening users with the typically substantial computer cost increases associated with running the more sophisticated systems, as well as the one-time human costs of trying to use the new systems. Second, perhaps it is time to consider the users, substantial in number I think, who are NOT "attempting to push the system to the limits of their imagination" (page 3 of RFC 724). It doesn't seem rational to me to invent new and different protocols, the burden of which must be borne by all, in order to mollify the hackers among us. Of course, I may be marked as an "outsider" because I don't automatically feel that "resolution ... could best be obtained by immediately junking the existing 'interim' mail facility" (page 3 again) and not just because of a lack of general understanding. To summarize: if there is a clear need for something, perhaps it should be done, even if it causes pain for everyone. On the other hand, in recent years I've become pretty strongly opposed to causing everyone pain in order to provide a goody to a small subset of the community. A mail system clearly needs to know where to deliver a message, and I think the current systems can do so. A mail system MAY need to know where a message came from (although I doubt it) and again most systems seem to be able to discover this also. I have great doubt that a mail system needs to do more (the world's telegram, telegraph, and postal systems seem to get by with this much) and I think the hackers should be denied having more. I don't want to know the first name of Postel's secretary, I don't want the name typed on my terminal, and I can't afford the cost of having the computer throw the information away!!! Please, please, please simplify, rather than complicating! Regards, Alex McKenzie ------- 10-MAY-78 22:14:19-PDT,683;000000000001 Mail-From: BBN-TENEXA rcvd at 21-MAY-77 1316-PDT Date: 21 May 1977 0840-EDT Sender: DDEUTSCH at BBN-TENEXA Subject: MSGGROUP# 555 RE MCKENZIE COMMENT ON RFC 724 From: DDEUTSCH at BBN-TENEXA To: MSGGROUP at ISI Cc: McKenzie at BBN-TENEXE Message-ID: <[BBN-TENEXA]21-May-77 08:40:27.DDEUTSCH> Perhaps the optimal solution is to provide an MSG-like system which eliminates (or ignores) all headers except to and from, and maybe subject. Since Alex never wants to see any other headers, this could be done at little cost. Then he could continue to use his slow terminal without unnecessary agravation and without much computational overhead. ---Debbie ------- 10-MAY-78 22:14:19-PDT,43875;000000000001 Mail-From: OFFICE-1 rcvd at 21-MAY-77 1518-PDT Date: 21 MAY 1977 1518-PDT From: PANKO at OFFICE-1 Subject: MSGGROUP# 556 Panko's Submission in FCC Computer Inquiry To: msggroup at USC-ISI cc: panko --------- < PANKO, FCC-INQUIRY.NLS;22, >, 21-MAY-77 15:00 RA3Y ;;;; Before the FEDERAL COMMUNICATIONS COMMISSION Washington, D. C. 20554 In the matter of ) ) Ammendment of Section 64.702 of ) Docket No. 20828 the Commission's Rules and ) Regulations (Computer Inquiry) ) COMMENTS OF RAYMOND R. PANKO My name is Raymond R. Panko. I am an independent consultant in Menlo Park, California. For several years I have been active in the analysis of new forms of electronic mail, particularly the new "computer message services," which are just beginning to reach commercial availability after five years of experimentation and quasicommercial use. My comments primarily address the impact of the proposed "computer rules" on the development of computer message services (CMSs). Although I was with Stanford Research Institute until this summer and will be joining the University of Hawaii this autumn, my comments are entirely my own. In my comments, I wish to make six points: Electronic mail, which generates revenues of between $1 billion and $2 billion annually in the United States, is beginning to be revolutionized by the application of computer processing tools. While a few computer message services are function-by-function replacements for traditional teletypewriter message-switching services, most are primarily message-PROCESSING services, in which only 10% to 20% of total costs are due to functions handled in traditional message-switching systems. The current computer rules have impaired the development of CMS, because their applicability is highly uncertain. The proposed rules should have an equally adverse impact. It is possible to create relatively unambiguous rules to determine which computer message services should be considered communication services. The approach taken to the creation of CMS rules may have general applicability for the general regulation of computer-based services with communication elements. The Federal Communications should not use its powers to fracture coherent services if this fracturing harms the value of the service to the user. Because my background is primarily in marketing research, organizational behavior, and corporate strategy, not regulation, I would be surprised if the rule changes I suggest below could be adopted in total. However, I feel that it is imperative that the FCC understand the importance of CMS and also understand how heavily the current and proposed rules are affecting the development of CMS. THE LARGE ELECTRONIC MAIL INDUSTRY IS BEGINNING TO BE REVOLUTIONIZED BY THE APPLICATION OF COMPUTER PROCESSING TOOLS. It is popular mythology that electronic mail is a new phenomenon and that teletypewriter-based services, the earliest form of electronic mail, are mordibund. But just the opposite is true. Table 1 lists the sizes of contemporary electronic mail services. While public telegram transmissions are indeed small and fading rapidly, they are vanishing in large part because business is turning to better message services. At a quarter billion dollars annually, Telex and TWX are healthy indeed. Yet Telex and TWX themselves are too expensive for most businesses with heavy communication needs; most large businesses use "private-wire" teletypewriter systems, which function like Telex and TWX, but which are operated internally and are used only for intracompany communication. Although new forms of electronic mail, such as facsimile and communicating typewriters, are growing rapildy, they are still small, and even their rapid growth is due primarily to the fact that they are essentially replacement services in the large electronic mail marketplace. The costs of traditional electronic mail services are high. A typical message costs between $1 and $2. Although some new forms of electronic mail, such as high-speed facsimile, promise to be cheaper, they are only useful in "mailroom" applications, where a message is written out, hand carried or mailed to the transmission center, and mailed out or hand-delivered at the reception end. This is inconvenient and expensive, and businesses are not flocking to high-speed mailroom services in record numbers. The last five years have seen the emergence of a new form of electronic mail called computer message service, or CMS, in which computer-based tools are integrated with traditional message-switching systems. The users of these computer message services can send or receive messages directly, do this through secretaries, or do this through mailroom systems; the CMSs are interactive and relatively easy to learn. In CMS, the sender has sophisticated word processing tools for message composition, and some systems offer the sender special routines for prerelease clearance of the message or even for semantic error detection, when business forms are being handled. Transmission itself is very inexpensive, generally between one and five cents, because most CMSs send messages over packet-switched networks or store messages until there is sufficient volume for low-cost, high-speed transmission. The receiver also has sophisticated tools for message reading and disposition. When a message arrives, it is filed immediately and, in some cases, also printed immediately. The user may retrieve new and old messages in any order, file them away by topic, recover them by content, author, or date, delete them, forward them to others, dash off brief replies, annotate messages, or send them to calendar programs to appear later as reminders. Forms transmissions are frequently integrated into data bases at the sending and receiving end. The cheapest of the new CMSs are "mailroom" systems, and these are very cheap indeed. Hewlett-Packard, for example, recently replaced its private-wire and public teletypewriter systems with an internal CMS called COMSYS. COMSYS is primarily used to handle forms, as are most electronic mail systems, but about 15% of its transmissions consist of brief messages or documents. Forms are entered into intelligent terminals. Where appropriate, input information is checked against local data bases, to check for consistency with previous orders. The messages are stored in local minicomputers until they are polled by the central computer. Telephone transmission lines are used to send messages at speeds of 1200 bits per second or faster. When messages come in, they are printed on a high-speed, high-quality printer. Currently, COMSYS handles about 50 million messages annually. The price? COMSYS costs Hewlett-Packard about five cents per message for domestic transmission, not counting the typist's labor. This low price has revolutionized communication practices within Hewlett-Packard, yet even that company is just beginning to understand what it has created (the system probably pays for itself simply by its ability to reduce errors in forms handling). Hewlett-Packard will soon introduce a commercial offspring of COMSYS, to be called the HP 2026. Organizationally, the staffing of COMSYS resembles the staffing of traditional mailroom teletypewriter networks. Terminals are clustered in basement offices, and messages must be delivered to the office for entry by trained operators. In contrast, most CMSs are "convenience" systems, in which the user or secretary uses the system directly. This gives better control, much faster turn-around time, and reduces the labor costs spent carrying the message to the delivery room. Convenience systems, of course are more expensive. One CMS called PLANET, for example, costs about $1.70 per message, a price that is still competitive with Telex and TWX. TYMNET's simpler ONTYM message-switching system, in comparison, will probably cost between $0.50 and $0.70 per message; if the user's firm leases an ONTYM computer for on-premises application, the cost will be between $0.25 and $0.50 per message. Some very sophisticated CMSs cost as much as ten dollars per message. Prices are expected to fall dramatically in the very near future. The PLANET system, for example, which now costs $1.70 per message now, is projected to cost only $0.25 per message by 1985. Within a decade, even the most sophisticated and extensive computer message systems should be cheaper than Telex, TWX, or convenience facsimile systems. It is too early to tell whether mailroom or convenience CMSs will attract more of the market, but it is clear that one of them has an excellent chance of revolutionizing electronic mail in the very near future. Cheaper yet more powerful than traditional forms of electronic mail, CMS should be immensely attractive. CMSs ARE PRIMARILY MESSAGE PROCESSING SERVICES Traditional electronic mail systems have been TRANSMISSION systems. A message is preprepared on paper for facsimile or on punched paper tape for teletypewriter services. It is transmitted, then printed once at the recipient's terminal. But the life cycle of a message is much longer than this. The author may dig through past correspondence for references, problems, and solutions. He or she may dictate or type a draft, reword it, clean it up, route it for sign-offs and comments, change it again, then finally send it. The receiver will not only read it but will also file it, add it to special data bases of messages, retrieve it later, forward it, send off replies, and so on. Both the sender and receiver may route mandatory copies to files or responsible people. The sender may have to get the attention of receivers for urgent messages, contact the receiver again if an action memo has not been replied to for a week, and so on. When documents and reports -- as opposed to brief memos -- are sent, there is additional processing. The author may have to keep track of deadlines, make copies for distribution, engage in joint authorship, route drafts for review, and handle mailings. While a document is in process, the author may have to send periodic status reports to management. After a document is sent, it may be assigned special status. For example, if it is a periodically-updated report, users asking for earlier versions must be told that a newer version exists. If the document is a paper in a technical journal, it will have to be indexed and placed in a table of contents. If it is a monthly progress report, it must be added to a master control file and indexed for quick retrieval. And, of course, access is often controlled, for reasons of privacy and security. As many as 90% of all messages in traditional electronic mail applications are business forms, such as sales orders, inventory changes, and so on -- not interpersonal messages. Forms contain data, so they are often integrated with data bases both before and after transmission. Information in forms is often checked for reasonableness against data bases during creation and during integration into master data bases at the reception end. The development of CMS has been primarily the development of processes that handle the message over its entire life cycle, in order to speed completion and reduce the labor costs. Since businesses spend 30% of their labor hours processing paperwork but only 0.5% to 1% of their revenues on transmission services of all kinds, including telephony, the development of life-cycle CMSs will be essential to the improvement of office productivity in the years ahead. Understandably, the processing of messages before and after transmission consumes the bulk of all costs in most CMSs I know of. Except in very simple systems, few of the functions offered in CMS were available in any real sense in traditional common carrier message-switching services. While there were some pale precursors of CMS services in traditional networks, they were rudimentary. For example, while messages were traditionally preprepared in Telex and TWX, this was done on clumsy paper tape, a truly barbaric practice. If the Federal Communications Commission regulates only services that are transmission services, i.e., replacements of existing message-switching services, then virtually no CMS would be regulated. However the FCC should allow reasonable upgrading of traditional services, to bring the benefits of interactive computing to bear on such processes as text keying. It should probably, for example, be possible to type in and address messages interactively, although substantial word processing certainly falls outside the FCC's jurisdiction and so could not be regulated. The problem, in the end, is how to create a reasonable and fairly unambiguous set of rules to determine when the FCC's authority ends. I discuss this problem below. THE CURRENT RULES HAVE STIFFLED THE DEVELOPMENT OF CMS, AND THE PROPOSED RULES WOULD DO THE SAME The current rules do not address computer message services directly, so vendors must guess at the rules' applicability on the basis of the general language in the rules. This has caused great confusion. The current rules require that "message-switching" services be offered by common carriers. Traditionally, the term message-switching has been the antonym of circuit-switching; that is, it has been a transmission technique. But store-and-forward correspondence systems, which use message-switched transmission, are also called message-switching systems, presumably because they use message-switched transmission. A computer-based system that merely takes an interpersonal message from one point and delivers it to another point via message-switched transmission would certainly be considered message-switching and would certainly be regulated under the current and proposed rules. On the other hand, the current rules forbid carriers from offering computer-based services other than message-switching services. So where do CMSs stand, in which most costs are due to text-editing, sequenced reading and retrieval, and other processing tools? Certainly CMSs are used for communication in the broadest sense of the term, but so are word processing systems, over which the FCC certainly has no jurisdiction. Turning to the proposed rules, these still require message-switching services to be offered by common carriers, but they specifically forbid common carriers from offering data processing services, except through separated subsidiaries. The rules specifically name, as data processing services: word processing, text editing, and information retrieval. Moreover the very definition of data processing in the proposed rules includes "programmed response to input data," which seems to forbid all interactive computing. Looking at both the current and proposed rules, my guess that the FCC would consider CMSs to be message-PROCESSING services, and that the Commission would forbid common carriers from offering such systems, except through arms-length subsidiaries. But the FCC has already regulated one "message-switching" service that is really a computer message service, albeit a primative one. This is TYMNET's forthcoming message-switching service, described in TYMNET Tariff No. 1. TYMNET's system will allow limited text-editing and the retrieval of old messages up to three days after they are sent or received. I personally have strong doubts that TYMNET's new "message-switching service" should really be considered a message-switching service and therefore subject to common carrier regulation. My doubts rest on the fact that the service will have some text-editing and information retrieval functions. While transmission costs during message delivery, based upon TYMNET's tariffs and use patterns in other CMSs, will probably be about 20% of the total cost of the service. Perhaps I am making too much of the TYMNET message-switching service as a test of the computer rules. In its tariff application, TYMNET did not spell out the details of the service. It merely called it a message-switching service, without describing its functions, so the FCC's tariffing of the service should really not set a precedent. Overall, I hope that TYMNET's message-switching service will not become a major test case, because it is really a very simple system and is probably not a harbinger of future systems. Unlike most CMSs, it will offer few functions to the user that have not been offered in the past. Most current CMSs are (and, I believe, most future CMSs will be) life-cycle processing systems, in which transmission will be a negligible part of the total cost of the system and will also be a negligible part of the value to the user. The real value to the user will be in reducing the human labor needed to prepare, handle, distribute, and dispose of a message, document, or form. I would guess that the FCC would not attempt to regulate message systems in which 80% to 90% of the cost will come in processing the message before and after it is transmitted. But the FCC has already agreed to regulate one simple CMS, albeit with atypical characteristics. I certainly wouldn't bet my house on the FCC's interpretations. Just so, businesses are not willing to invest several million dollars on CMSs, only to find selves facing unexpected and potentially fatal regulatory problems. Betting on a service not addressed directly in such critical rules is a very great gamble. I think the FCC is doing the CMS industry an injustice in not addressing the service directly in their commputer rules. Many time-sharing networks offer CMSs, but only a handful are willing to talk about their services openly, preferring to let others risk the expenses of the court tests they believe will be needed to clarify the status of CMS. While one could take a hard-nosed line, saying that vendors should bite the bullet and face the regulatory arena squarely, this attitude does little for users who could benefit from CMS in a more definite environment. In any case, I personally have considerable sympathy for data processing vendors who have had no prior experience with FCC regulation and may have to face the full ceremonial dress of common carrier regulation. Let's face it. Common carrier regulation is pretty weird to an outsider. The least the Commission could do is clarify where a service like CMS really stands. Because CMS vendors have kept low profiles, few users have been aware of available services, and the market has been slow to mature. And, coming full circle, the FCC has not become aware of either the importance of CMs or of the impact of its rules on CMS services. This is a bad situation all around. IT IS POSSIBLE TO BUILD REASONABLY UNAMBIGUOUS RULES CONCERNING THE REGULATORY BOUNDARY OF THE FCC IN CMS. The Federal Communications Commission must develop rules to determine when a CMS is to be considered a message-switching service, and therefore subject to common carrier regulation. Obviously, if a particular CMS is primarily a message-processing service, it will lie outside the FCC's jurisdiction. The real question is how much processing must be present before the FCC's jurisdiction ends. We need a quantitative rule, with reasonably measurable tests. While a rigorously measurable test is only an ideal, I believe that it is possible to create a test that will be an improvement over the current definitional approach. I will suggest such a rule. Before beginning, however, I note that message-switching services are gradually being integrated into tools for word processing, message filing and retrieval, data bank managment, and even process control. I take it as a given that the FCC has no jurisdiction over such services. I do not believe, however, that services should be considered beyond the FCC's jurisdiction simply because they involve "programmed response to input data," because this would include all forms of interactive computing. In fact, I question whether the current rules would allow dial tones to be generated by an ESS-1 switch. Now to begin. I believe that CMS is important enough to address explicitly in the rules. I also believe that it is possible to describe a set of functions that embrace what public teletypewriter message-switching systems serve. I present my tentative list below. I have not included extensive text-editing, because the types of editing used on paper tape preparation are minimal. My list includes: the typing in of the message, including simple editing of the types used on paper tape punching machines, naming the recipient or recipients and giving their identifier (for example a unique code name or a telephone number) directory assistance functions needed to locate the identifier of the recipient or recipients, the creation, maintainance, and use of mailing lists, and the transmission of the message from the sender to the recipients. This may include: storage during transmission, automatic dialing and answering, the maintainance of message integrity during transmission, security to aid in authentication of the sender, privacy controls, speed and code conversion, signal processing, multiplexing, pulse format conversion, analog-to-digital and digital-to-analog conversion, signal processing, as defined in footnote 15 of the Notice of Inquiry and Proposed Rule Making, message and circuit switching, as defined in footnote 14 of the Notice of Inquiry and Proposed Rule Making, and input/output processing, as defined in paragraph 21 of the Notice of Inquiry and Proposed Rule Making, except that interactive editing would be restricted to the editing needed to convert a message in one format to the format required by the transmission network. I believe that there is ample precedent for calling a system with these characteristics a message-switching system subject to FCC regulation. As a test and rule, I suggest that the FCC require a CMS to apply for common carrier status if over 50% of the average service cost for reasonably representative users is due to the functions listed above. This test would be applied only when a common carrier whose transmission facilities are used by the unregulated CMS challanges the unregulated status of the CMS. If a common carrier wishes to offer a regulated CMS, it would have to provide reasonable information, based upon experimentation or analogies with existing CMSs, indicating that over 50% of the cost to a typical user would consist of functions in the list above. It would also have to supply proof, based upon statistics gathered during operation, that over 50% of the expenses for a reasonably representative sample of users during subsequent actual operation consist of the services listed above. To further clarify matters, I suggest that a handful of borderline commands be explictly called processing functions, not to be included in statistics as communication commands: Reading commands that display or remotely print whole messages, except when such commands are used to print all new messages. Considered as processing tools would be commands that control the order in which new messages are read or that allow the users to read old messages. Whole commands should be considered; where commands are of the predicate-object variety, for example, "Print New-Messages," or "Print Message 7," the command should be recorded as a communication event only if the object is all new messages. Scanning commands, which display or remotely print brief summaries of messages (usually giving the sender, date and time, title, and sequence number in the message file), except where such commands are used to scan all new messages. Parts of "compose" commands or prompted sequences, in which the message is prepared for sending, except where 1) the body of the message is being typed and the only editing commands are "delete last character," delete last word," "delete last line," "delete entire field," "print last line," and "print whole field," 2) the distribution list is entered or the addresses of intended recipients are gathered from on-line functions resembling telephone directory assistance, 3) a title is entered, 4) where the completed message (text, distribution list, etc.) is retyped so that the user can review it before sending, or 5) the user tells the system that the message is complete and ready for sending. Excluded from calculations will be costs incurred before the user enters the CMS program and after he or she leaves it. Thus, the type spent logging into the computer and out of it, and the time spent initializing the CMS program and terminating it, would be excluded from calculations. I suggest that the 50% rule, together with the additional guidance in the preceding paragraphs, will allow the Commission to pass judgment on whether a particular CMS is a message-processing or message-switching service. In any particular application, of course, there will be ambiguities in the interpretation of some commands. But I feel that the 50% "trigger point" is high enough tha most CMSs will be categorized fairly easily. One problem I forsee is how to draw the line between the CMS and other programs in a multiprocessing computer. For most CMSs, this should not be a major problem, because most CMSs are distinct programs, which the user enters, works in for awhile, then quits. One may well consider all time spent in the CMS, together with time spent in related subprograms, such as text-editing, as being relevant for the statistical analysis. (While a user is in a CMS program, he or she may call a subprogram, in order to take certain required actions, for example text-editing. While text editing and related commands can be, and often are, integrated as commands in the CMS, many CMSs take advantage of the existence of already-developed text-editing programs on the computer and merely execute these programs as subprograms. Not only text-editing but other tools as well are often reached as subprograms). In considering submitted analyses, of course, the FCC will require a full description of each command, and will pass final judgment on whether specific commands are desired by users as part of a CMS program. User behavior and desires should form the basis for the inclusion or exclusion of commands where user information is available. In many computer systems, however, CMS functions are distributed among several programs. For example, on the computer system I use, I have a single in-box for my incoming mail, and there is a single deep-level program, in the guts of the software, that handles all message delivery. But several user-level programs exist for handling mail. I can send a message with the single-command program SNDMSG and read new mail with the single-command program, MESSAGE. Or, I may compose and edit a message with a text editor, taking my choice of NLS, TECO, XED, or NETED -- then send the message through SNDMSG. Or, I can do nearly everything I need to do in message composing, reading, filing and retrieving with HERMES and MSG. In practice, I use most of these user-level programs over the course of any given month, employing each as appropriate. If a particular CMS is close to the 50% trigger, then the vendor should be required to provide a general analysis of the use patterns of relevant systems. I do not propose a standard set of statistical tests to be performed, since this will be a difficult problem in more complex cases, and it is probably impossible to foretell what tests will be appropriate in a particular system. I do suggest that the FCC require a challanged vendor to develop an appropriate methodology and to provide an appropriate statistical analysis, together with detailed information on individual command uses -- so that others may redo the analysis. The FCC may wish, however, to establish a standard initial analysis approach, to settle cases where the system falls far enough above or below the 50% cut-off to require no further analysis. I do not claim that my suggested rule and test will always be easy to apply. I do believe, however, that simple, first-cut analyses will be sufficient to classify most CMSs as message-processing or message-switching services, so that litigation will not be extensive. Remaining cases will be more or less difficult, depending on the nearness of parity between message-processing and message-switching applications. But close cases would always be difficult, and the sugested approach would at least provide statistical data for the consideration of these residual difficult cases. THE APPROACH TAKEN TO THE CREATION OF CMS RULES MAY HAVE GENERAL APPLICABILITY FOR THE REGULATION OF COMPUTER-BASED SERVICES WITH COMMUNICATION ELEMENTS. In the approach described above, vendors of services challanged by common carriers serving them would be required to provide statistical analyses capable of determining, within reasonable limits, what percentages of user costs arise from services categorized by the FCC as being communication services. In most cases, the statistical analysis would make the FCC's decision simple. In harder cases, it would at least provide a quantitative basis for discussions. This approach would obligate the FCC to define communication services, rather than data processing services, as the Commission proposes to do in the Notice of Inquiry. This seems reasonable. From a pragmatic point of view, the FCC does not have the skill or regulatory mandate to define the newly-developed, rapidly changing, and complex data processing industry's boundary. But the FCC does have expertise in communication, plus a regulatory mandate to regulate communication services. That mandate, it seems to me, places the burden of defining the telecommunications boundary on the FCC and does not allow it to define data processing. While the goal of defining data processing, namely to allow carriers to establish proper ancillary services that use computers, is laudable, the Commission can only achieve this goal by creating an explicated working definition of communications in the context of several key services. THE FEDERAL COMMUNICATIONS COMMISSION SHOULD NOT USE ITS POWERS TO FRACTURE INTEGRATED SERVICES INTO REGULATED COMMUNICATION SERVICES AND UNREGULATED PROCESSING SERVICE, IF THIS FRACTURING HARMS THE VALUE OF THE COMBINED SERVICE TO USERS. As discussed above, every message has a life cycle, during which extensive processing occurs. Furthermore, in the total information environment of a firm, a message is merely one of many information flows. These flows are often interrelated, and all are destined for processing and storage, often by computer agents. This may seem abstract, but businesses are beginning to install very real life-cycle message processing systems and to integrate these into general information handling systems. Because paperwork processing consumes 30% of all labor hours in a corporation, integrated systems are crucial to productivity growth in the United States. Yet the FCC has unwittingly, albeit with the highest intentions, been a substantial impediment to the development of integrated information systems for hire. The most obvious example is in the area of securities. The FCC has already decreed that Western Union may not integrate information retrieval into its SICOM communication system for the stock brokerage community -- except if Western Union creates an arms-length subsidiary to provide such service, in which case the user would not have an integrated service, anyway. Similarly, Bunker Ramo is prohibited from expanding its information retrieval service to include message communications -- unless it creates an arms-length common carrier subsidiary. But, again, there would still be no integrated service. For the user, it is hard to see any benefits in this mandatory fragmentation of the service. The user is justifiably piqued that he or she is not allowed to buy his information/communication service in one coherent package. Where in this arrangment of fragmented service is the public interest, convenience, and necessity? How does it make available to all people of the United States a rapid, efficient, Nation-wide, and world-wide wire and radio communication service? Perhaps there was a time when communication was so expensive that regulatory interference with service evolution was tolerable. But now communications represent an almost insignificant part of business expenses, while information and message processing hold the key to office automation, which is critical to future productivity growth in this country. I would urge the FCC very strongly to eliminate the unbearable mischief that operational separation has caused and can only continue to cause. There is only one reason for imposing maximum separation -- that AT&T and Western Union might underprice their service in the competitive marketplace. But I find it difficult to believe that AT&T or Western Union, under existing FCC and state accounting rules, could underprice their nontransmission services in the market place more than could such unregulated companies as IBM, Xerox, or Exxon. CERTIFICATE OF SERVICE I, Raymond R. Panko, do hereby certify that copies of my foregoing "response" were this day of May 24, 1977, sent by first class mail to parties of the Commission's May 5, 1977 service list and also to Keller & Heckman as counsel for the Central Committee on Telecommunications of the American Petroleum Institute (Central Committee). Dr. Raymond Robert Panko Table 1 ELECTRONIC MAIL IN THE UNITED STATES 1977 ESTIMATE (millions of dollars per year) Message Medium Annual Revenues Private-wire teletypewriter ...................... $600 to $1,200 Western Union message services Telex and TWX $240 Telegrams 60 Mailgrams 50 Other 50 TOTAL .............................................. $400 Facsimile .......................................... $200 to $300 Communicating typewriters ........................... $40 to $100 GRAND TOTAL .................................... $1,240 to $2,050 ------- 10-MAY-78 22:14:20-PDT,725;000000000001 Mail-From: MIT-AI rcvd at 21-MAY-77 1946-PDT Date: 21 MAY 1977 2247-EDT From: RMS at MIT-AI (Richard M. Stallman ) Subject: MSGGROUP# 557 horrors! I wasted 3 cents! To: stefferud at USC-ISI I can't believe that the time it takes to parse a message in the format of the proposed standard, and print only some of the fields, is worth noticing compared with the cost of doing any real work on a computer. A single compilation will certainly use as much time as weeks worth of parsing headers. Besides, nobody is going to be required to increase the number of fields put in headers, under the proposed standard. It just says exactly how people should do what they are going to do somehow anyway. ------- 10-MAY-78 22:14:20-PDT,1553;000000000001 Mail-From: OFFICE-1 rcvd at 22-MAY-77 0423-PDT Date: 21 MAY 1977 0914-PDT From: PANKO at OFFICE-1 Subject: MSGGROUP# 558 Simple Headers To: [ISI]Mailing.List: I am in partial agreement with Alex McKenzie's comment that people who use simple systems like SNDMSG/MESSAGE should not have to wade through piles of header garbage or have to spend extensive computer resources processing out the garbage. What he says is true and just, and I agree with that part completely. I do question how many people in the future will have the problem; I don't think it will be the majority. But it may be a very large minority. Let me suggest a simple compromise. 1) define a minimal header specification. Include To:, From:, Sender if different from From:, Subject:, Text:, and a SIMPLE time stamp. 2) send this header, followed by the message body, then followed by the optional information. 3) this fuller information would be set apart from the rest of the text by clear and unambiguous delimiters, so that a fairly simple system could delete it or not print it. Even simpler systems would print the extra stuff, but this would be at the end and could simply be snipped off the paper at the end of the message. I strongly recommend a simple, basic header, for use by simple systems. When your average message cost begins to climb to between $5 and $10 per message on ARPANET systems, you have no right to ignore people who want to pay less. Ra3y Panko ------- 10-MAY-78 22:14:20-PDT,1036;000000000001 Mail-From: CMU-10A rcvd at 22-MAY-77 1352-PDT Date: 22 May 1977 1652-EDT From: Philip Karlton at CMU-10A Subject: MSGGROUP# 559 Re: MSGGROUP# 554 RFC 724 To: MSGGROUP at USC-ISI CC: mckenzie@BBN-TENEXE Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 22 May 1977 16:52:47 Philip Karlton In-Reply-To: McKenzie's message of May 19, 1977 The responses I have seen so far miss the point I believe. The reason for the new definition of header lines is that the current ad hoc header format is not consistantly obeyed by all sites. For instance, I am told that MSG cannot handle names with spaces in them such as in my From: field. It is essential to have a standard format for items that programs might want to parse even if mine doesn't. On the other hand, I should hope that not all of the fields will be filled in by systems with some default value just in case somebody wants it. People normally are willing to tailor their messages to their correspondents. PK ------- 10-MAY-78 22:14:20-PDT,3937;000000000001 Mail-From: USC-ISI rcvd at 22-MAY-77 1618-PDT Date: 22 MAY 1977 1512-PDT Sender: FARBER at USC-ISI Subject: MSGGROUP# 560 A comment on the "efficiency" of message systems From: FARBER at USC-ISI To: [ISI]Mailing.List: Message-ID: <[USC-ISI]22-MAY-77 15:12:09.FARBER> Over the previous several days there have been a number of messages that pertain to the new RFC. I think there are two interesting and debatable axises to these comments.. One has to do with the appearance of the message system to the user and the other relates to "computer" utilization. I would like to comment on both these issues. As to the appearance of the message system to the user and the "fact" that expansion as allowed by rfc 724 would create a mass of "unwanted" fields etc, I believe that this argument is both true and false. The true part is that many users have no interest in seeing a mass of fields that have nothing to do with the basic information being transmitted. The addition to most modern message systems of a profiling mechanism allows the possibility of the user choosing what fields are relevant to HIM and suppressing others. I would note that the term relevant to HIM is key. What I want to see may well depend on who I am and what instantiation of me is currently reading the messages. As to the inefficiency of such a mechanism, namely "look at all the stuff I have to throw away", that is again an argument that will depend on just who I am and what I am using the system for. A similar argument can be made for the wrongness of the elaboration of programming languages and operating systems that has occurred over the past 20 years. Clearly to some users (like the old AEC) one needs only Fortran and a boot loader . After all their problems ran for 24 hours. That argument was made for years at SHARE meetings and to IBM. However current computers have a broader base of users and to decide that a given user represents a broad section of the user community usually leads to errors in design. I believe that is true in message systems. The same arguments for broading languages no doubt will hold for message systems. Part of that argument is that the trade of computer time (in small amounts) is a profitable trade for decreasing user confusion and increasing his productivity and the usefulness of the resultant product. Now for the second issue.. Computer efficiency. Certainly TENEX cycles cost real monies, especially to ARPA IPTO. However we must look sometime down the future and note that the day of the 11/70 on a chip is within two or three years and that EVERY terminal will probably have a micro-processor of some power in it at that stage. Just for calibration of the state of the art at the current time, an INTEL 8080 is roughly the computational equivalent of a 360/40 and it is resident in increasing number of terminals. So we will find more and more of the message system computation capable of being performed in the terminal itself, especially those parts that are relevant to the user appearance issues. So talking about parsing times may be talking about vanishing relevant amounts of processing costs. Note there is negligible advantage to having my local micro operating efficiently in terms of computer power but much advantage to having me operate efficiently I realize that the above analysis is overly simplified . But I am suggesting, among other things, that we look forward to the future directions in message systems when we attempt to evaluate current systems and suggested standards. Are we going on a "correct" vector or are we creating artifacts that are not relevant to tomorrows problems and computers. Dave ------- 10-MAY-78 22:14:20-PDT,7376;000000000001 Mail-From: USC-ISIE rcvd at 23-MAY-77 1823-PDT Date: 23 May 1977 1804-PDT From: POSTEL at USC-ISIE Subject: MSGGROUP# 561 Comments on RFC 724 To: MSGGROUP at ISIA, Header-People at MIT-MC cc: postel at ISIB Comments on RFC 724 General Comments: Most of the preface and most of section one really turned me off. It seems like someone is trying to score a point some intense war in some very narrow interest group, not a general introduction to the problems in mail systems. That in fact is just what is really needed and would be really useful -- an introduction to the issues of mail systems and a commentary on which are to be attacked by this proposal. i strongly recommend that section one be replaced in future editions. The only real problem currently aflicting the ad hoc arpanet mail system that i percieve (perhaps i don't see clearly enough) is the desire to include people's real names along side their computer mailbox names. This is only a problem when the mail manipulating programs attempt to implement an answer function that derives the destination of the answer from the contents of the header fields. (I like the answer function myself.) The reason this is a problem is that the de facto reference document (rfc 680) does not speak to this inclusion of real names. This proposal (rfc 724) speaks to much more that the current problem so i feel it should more clearly point out the problems it solves (and how it solves them) and the future services it makes possible (and how it does that). Nitpicks: page ii para 3: Why is properly in quotes? Does it mean something different than the normal definition? page 2 para 3: Check the name of this document! It may have more words but the same confusion arises. Lets face it, the title should have the word MAIL in it. page 2 para 3: I strongly disagree with the notion that rfc 680 was less official than rfc 561, and the notion that rfc 680 received poor distribution. page 3 para 1: Is there a list of mail system implementors that feel justified in ignoring rfc 680? page 3 para 4: Are there references for the "at least two suggestions for a mail transmission protocol"? page 4 item 6: Why comments in only SOME header items? This sounds like a flaw in the specification. (I later learn that some header items are arbitrary strings so comments could not be recognized, but this statement raises a red flag.) page 6 sect D: The officialness of standards is always a question at every level of at every level of protocol. To my knowledge no arpanet protocol at any level has been stamped as official by ARPA. The question of official protocols brings up the question of who are the officials anyway? Why should this collection of computer research organizations take orders from anybody? It is clear that it is in everyones interest to work together and cooperate to evolve the best system we can. Perhaps there is too much emphasis on official and not enough emphasis on best specification so far. I prefer to view the situation as a kind of step by step evolution, where documents such as rfcs 561, 680, and 724 record the steps. To make a big point of officialness about one step may make it very hard to take the next step. Because a set of programs with a generally parallel purpose behave in various ways does not prove beyond a reasonable doubt that a document claiming to be a standard specification does not exist. page 7 para 3: This paragraph is not clear. Perhaps what it intends to say is the format of the presentation of the specification is not ment to implicitly specify things too. page 8 para 1: The authors hereby take control personally, could the authority be vested in the CAHCOM or the NIC? If a person has an idea for an extension how does she get a hearing? page 10 item 2: The last sentence of the first paragraph is confused, i think it should say "The may be composed of any ASCII characters (other than and , which have not been removed by unfolding). That is, after unfolding there may not be any or in a ." page 10 item 3: The last sentence is difficult to parse, perhaps it would help to say that is equivalent to a single , and this will be used in the format of this specification document. page 11 def of : The is the definition of a fold. I would suggest that be defined explicitly, so as not to confuse. My first reaction was "Ah! This is a fold, and a fold would be removed before i get to analyze this so i will never see this! What is it doing here?" page 12 def of : This contains a hidden definition of <">, please pull that out as an explict definition. page 12 def of : typo "zero of more" ==> "zero or more" page 12 def of : How is this different from ? Is ok ? page 12 defs of misc chars: <"> should be defined, as should def refers to an undefined page 13 item 3: You might want to say that s won't be encountered in quoted strings since unfolding will be done prior to syntatic analysis. page 14 item 6: What is a line? 64, 65, 72, 80, 132, 2000? page 15 para 1: If multiple instances of the same header item occur, do they have to be adjacent? page 16 def of : What is the implication of a (undefined formal, by the way) address list? page 17 def of : What is the implication of a reference list? This allows a message to contain "References:" (of course the syntax allows a lot of silly things). page 17 def of : Why a null day? why not define to be