Date: 06 DEC 1977 0951-EST From: JZS at CCA Subject: Sam Strugglegear assails Boston To: Header-People at MIT-MC Bob Dornick of Quasar Industries and side-kick Sam, "programmed for random conversation", appeared on the WCVB Good Day program this morning and will be "chatting" with the folks at Jordan Marsh, Boston today. /Joanne -------  Date: 9 Dec 1977 1603-EST From: Philip Karlton at CMU-10A Subject: Parsing RFC733 address lists. To: Header-People at MIT-MC Message-ID: <09Dec77 160339 PK01@CMU-10A> How about somebody from the committee generating a list of pathological, but legal header lines that people can try shoving through their parsers? PK  Date: 09 DEC 1977 1634-EST From: JZS at CCA Subject: Parsing RFC733 address lists To: Header-People at MIT-MC This is an excellent idea. I'd also appreciate receiving sample messages for testing purposes directly from group members. Joanne -------  Date: 11 Dec 1977 1745-EST From: Brian K. Reid Subject: too late for the RFC, but you still might want to know To: Header-People at MIT-MC In the RFC, it states that the separation between the header and the body is to be a null line, i.e. CRLF CRLF. I assume that this is so that there will be no ambiguity in telling folded lines from end-of-header marks. However, folks around the net seem to be generating headers that have that blank in there (CRLF SPACE CRLF), so it might be a good idea for all of you folks who are frantically writing fancy mail-reading programs to make your programs be able to recognize that case, even though it is illegal. B.  Date: 12 DEC 1977 1040-PST Sender: DCROCKER at USC-ISI Subject: Re: too late for the RFC, but you still might want to know From: DCROCKER at USC-ISI To: Brien.Reid at CMUA Cc: Header-People at MIT-MC Message-ID: <[USC-ISI]12-DEC-77 10:40:22.DCROCKER> In-Reply-To: Your message of DECEMBER 11, 1977 (CRLF SPACE CRLF) is a bug. The old Unix Sndmsg generates it at some sites (including Rand, I'm afraid). Dave. -------  Date: 12 Dec 1977 1521-EST From: BRIAN REID at CMU-10A Subject: Bug To: DCROCKER at USC-ISI CC: Header-People at MIT-MC In-Reply-To: <[USC-ISI]12-DEC-77 10:40:22.DCROCKER> Ah, but it's a sufficiently subtle bug that I think it would behoove mail programs to look for it. What RDMAIL did with a message that had (CRLF SPACE CRLF) in it was to make the entire message into a header, then not print the `extra' header lines because my user profile says I don't want to see random extra header lines. One question, though: if a mail has no body but only a header, does the CRLF CRLF still need to be at the end?? Brian  Date: 12 DEC 1977 1400-PST Sender: DCROCKER at USC-ISI Subject: Re: Bug From: DCROCKER at USC-ISI To: BRIAN.REID at CMUA Cc: Header-People at MIT-MC Message-ID: <[USC-ISI]12-DEC-77 14:00:56.DCROCKER> In-Reply-To: Your message of DECEMBER 12, 1977 Unfortunately, it will be quite reasonable for messages to have (CRLF SPACE CRLF) as valid lines in a header. E.G. I expect our system to support that use. I believe the 733 syntax does not require CRLF CRLF if there is not body text. (Certainly meant to make it that way.) Dave. -------  Date: 6 Feb 1978 1223-PST From: ZELLICH at OFFICE-1 Subject: Net address change for zellich, wmartin, walsh To: msggroup at ISI, stefferud at ISI, header-people at MIT-AI I don't know if all three of us are still listed in both Header-People & Msggroup, but anyway: As of Monday, 6 Feb 78, Rich Zellich, Will Martin, and Bill Walsh directories have been moved from the SRI-KL to OFFICE-1. Directory names ZELLICH, WMARTIN, and WALSH are still valid - only the host has changed. Cheers, Rich -------  Date: 8 Feb 1978 2000-EST Sender: RICK.GUMPERTZ at CMU-10A Subject: address lists From: RICK GUMPERTZ(N810RG02) at CMU-10A To: Header-People at MIT-MC - - - - I asked this before but got no response, so here goes again: Suppose I want to put in a piece of mail an address field that lists the individuals in a group like Header-People but also gives a pseudo-user that can be used instead. How do I represent that? I.e. how do I say further mail should go to either the single address X or to all of the multiple address A,B,C,... Rick -------  Date: 10 Feb 1978 1404-EST From: BRIAN.REID at CMU-10D Subject: let's hear it for uniform standards To: Header-People at MIT-MC, bajzek at CMUA - - - - 300 PARC-MAXC FTP Service 2.9.0.2 %57 at FRI 10-FEB-78 10:26-PST 450 No such mailbox at this site. ?Transfer aborted. **COMMAND QUEUED** !SMLFL 10 Feb 1978 1322-EST ; NBS-10;436FPO.QED;Totally stupid 300 NBS-10 5.07B NBS 5/IL FTP Server 4B(32) 507 No such user as TOTALLY STUP *SMLFL 10 Feb 1978 1331-EST ; UTEXAS;423FPO.QED;Unknown User 300 UTEXAS RET-Unix Server FTP 050 Howdy Pardner! 450 User unknown **COMMAND QUEUED** !SMLFL 10 Feb 1978 1331-EST ; RAND-UNIX;423FPO.QED;Unknown User 300 Rand-Unix Server FTP 450 User Unknown **COMMAND QUEUED** !SMLFL 10 Feb 1978 1331-EST ; AMES-67;423FPO.QED;Unknown User 300 NASA AMES TSS/360 SERVER FTP -- ENTER USERID (OR "MAIL" COMMAND) 503 COMMAND "MLFL UNKNOWN USER" IGNORED: UNKNOWN USER SPECIFIED ?Transfer aborted. **COMMAND QUEUED** !SMLFL 10 Feb 1978 1331-EST ; MIT-MC;423FPO.QED;Unknown User 300- MIT-MC ITS 1100, FTP server 158 on 10 FEB 1978 1335-EST 300 Bugs/gripes to BUG-FTP @ MIT-AI 252 Thanks for the blurb FTP 4A(13) *SMLFL 10 Feb 1978 1347-EST ; MULTIC;472FPO.QED;Unknown User 030 Unattended Service 300-Multics 33.2: MIT, Cambridge, Mass. 300 Load = 20.0 out of 85.0 units: users = 20 450 Cannot locate mailbox for "Unknown"; please check spelling of user name. ?Transfer aborted. **COMMAND QUEUED** !SMLFL 10 Feb 1978 1347-EST ; ARGONN;472FPO.QED;Unknown User ? IMP6 Connection error - refused ?ICP connection failed **COMMAND QUEUED** *SMLFL 10 Feb 1978 1347-EST ; WHARTO;472FPO.QED;Unknown User 300 Wharton School 6.03v10 FTP Server 4B(32) 507 No such user as UNKNOW **COMMAND QUEUED** !SMLFL 10 Feb 1978 1347-EST ; LONDON;472FPO.QED;Unknown User 300 UC LONDON GATEWAY 18 46 ON 10 FEB 78 000 INDRA FTP Version 2.11 (19 Apr 77) 500 Command unrecognized ?Transfer aborted. **COMMAND QUEUED** !SMLFL 10 Feb 1978 1347-EST ; LBL;472FPO.QED;Unknown User ? IMP6 Connection error - host down ?ICP connection failed **COMMAND QUEUED** *SMLFL 10 Feb 1978 1347-EST ; UCLA-CCN;472FPO.QED;Unknown User 300 UCLA/CCN FTP SERVER NEW TELNET, ENTER COMMAND OR HELP 503 USER PARAMETER INVALID, REENTER THIS AND FOLLOWING PARAMETERS **COMMAND QUEUED** *SMLFL 10 Feb 1978 1349-EST ; SDAC-44;730FPO.QED;Unknown User 300 SDAC-44 FTP Server, Version 74.327 431 User name invalid ?Transfer aborted. **COMMAND QUEUED** !SMLFL 10 Feb 1978 1349-EST ; SRI-KL;730FPO.QED;Unknown User 300 SRI-KL FTP Service 101B(4) at Fri 10-Feb-78 10:53-PST 450 No such mailbox at this site. ?Transfer aborted. **COMMAND QUEUED** -------  Date: 10 FEB 1978 1508-PST To: HEADER-PEOPLE at MIT-MC From: Hathaway at AMES-67 Subject: BRIAN'S "LET'S HEAR IT ..." Brian, you're beautiful! And I will be the first to admit that my server's response is probably wrong (we returned a 503 for "Unknown User"), but it was a bit hard arriving at that decision, since: 1. there is no mention of MLFL in the official FTP protocol, 2. in the "Official Mail Protocol" (pages 239-240 in the ARPANET Protocol Handbook) it says that MLFL has the same replies as APPE, which can't be right because APPE (almost) always requires logon and MLFL usually does not, and 3. RFC 640, which was supposed to become official in February of 1974 (yep!) is not yet in universal use. At any rate, it seems the correct reply would be 530, at least ac- cording to RFC 640. That means "permanent failure" (since "Unknown User" is not likely to succeed if you tried it again) and "failure in authentication and accounting." Also I note that 530 is listed as a reply for MLFL (page 228) although it is not in the list of example messages (pages 225-226). It is particularly interesting that this "correct" code is one of the relatively few three digit numbers which was used by NOBODY in Brian's sample! And to repeat: Let's hear it for uniform standards!!!! Wayne PS: An aside to UTEXAS: "Howdy Pardner!"?????? That sounds like something a Teasip system would say! W. ------  Date: 21 Feb 1978 1750-EST From: RICK GUMPERTZ at CMU-10D (N810RG02) Subject: proposed Federal Information Processing Standard To: Header-People at MIT-MC, MsgGroup at USC-ISI, Wactlar at CMU-10A, Wulf at CMU-10A, Feinler at SRI-KL, Roach at MIT-Multics, Tavares at MIT-Multics, Newcomer at CMU-10A, Saltzer at MIT-Multics CC: Gumpertz @ CMU-10a Reply-To: Gumpertz @ CMU-10a Message-ID: <21Feb78 175050 RG02@CMU-10D> People: I am sending this to everyone I can think of who might be interested or might know of appropriate people to be forwarded to. Please feel free to forward this note to anyone whom you think it concerns. (aside to Jake: please forward this to the ARPANET liason list) I have recently discovered that the National Bureau of Standards published in the Federal Register (available at most major libraries) for 12 December 1978 (pp. 62408-16) a proposed standard for logging into and out of interactive computer systems. It claims to apply to all systems which will be used by a "Federal Government user" (whatever that is!). Not only does it specify to the word what messages will be generated, it flagrantly violates ASCII by suggesting a new meaning for the DLE code. Although I am sure some well meaning person put a lot of work into writing this document, I don't really think it is suitable as a FIPS. The first notice that I found of this standard was in "Minicomputer News", which may seem a rather unlikely source. To make things worse, the deadline for comments is 13 March 1978! Please try to get hold of a copy (if you are concerned with such things) and comment to NBS as soon as possible. Richard H. Gumpertz  Date: Tuesday, 21 Feb 1978 2027-EST From: Brian K. Reid Subject: Re: proposed Federal Information Processing Standard To: Header-People at MIT-MC, MsgGroup at USC-ISI, Wactlar at CMU-10A, Wulf at CMU-10A, Feinler at SRI-KL, Roach at MIT-Multics, Tavares at MIT-Multics, Newcomer at CMU-10A, Saltzer at MIT-Multics, Sproull at CMU-10A CC: RICK GUMPERTZ at CMU-10D (N810RG02) In-Reply-To: <21Feb78 175050 RG02@CMU-10D> Some highlights of this proposed standard: - [The System Signal] is generated by a computer, and indicates to the user that the next action is up to the user. . . . The system signal shall be generated so as to print or display the colon character (:) at the left margin of a line following a previously printed or displayed line of system message text." - "This Standard comes into play the instant there is established the capability of recognizable character transmission and receipt by a user's terminal. Thus, no commands, requests or messages may be presented to or accepted from a user between the time that the user approaches the terminal and the time that this Standard governs what the user sees and does." - The default value for the exit request signal is DLE [^P]. The exit request signal shall be recognized by the system at any time during the operation of a computer service or during the access procedures when the user is permitted to enter input." From the Introduction: "Just as the number and variety of users has grown, so has the number and variety of computer services, both within and outside the Federal Government. But while the services are no longer in their formative stages, users who choose to deal with more than one are still being asked to overlook differences that strike them as being frustrating and annoying....Specifically, this standard is intended to stem the proliferation of access -- entry and exit -- procedures, and to establish a single set of procedures that will have widespread applicability." "APPLICABILITY. The procedures specified in this standard apply to all user-terminal interactions where a Federal Government user is seeking access to or exit from one or more computer services."  Date: 23 FEB 1978 2313-EST From: MARS-RETRIEVER at CCA Subject: RFC 733 seems to be stabilizing. Besides, the new ARPANET protocol To: Date:, From:, Subject:, To: cc: Sender:, Message-ID:, [CMU-10A] 31 Oct 1977 22:, 27: handbook is due someday soon. I strongly feel that before 733 gets any sort of stamp of "official approval" as a standard, it should be implemented and used by at least a few sites. Design problems have a way of becoming more obvious when one tries to really implement the paper design. Does anyone out there have the time to get a 733 like mail sender/receiver running? Has anyone tried yet? Rick ------- -------  Date: 23 FEB 1978 2331-EST From: MARS-RETRIEVER at CCA Subject: Please ignore previous message To: Header-People at MIT-MC -------  Mail from SRI-KL rcvd at 24-Feb-78 1658-PST Date: 24 Feb 1978 1649-PST From: Feinler at SRI-KL (Jake Feinler) Subject: Online address for delivery of FIPS standard comments To: [SRI-KL]nlg-sndmsg-1-78: -- Messages from file: [SRI-KL]MAIL.TXT.1 -- Friday, February 24, 1978 14:44:20 -- Mail from NBS-10 rcvd at 24-Feb-78 1347-PST Date: 24 Feb 1978 (Friday) 1647-Est From: WATKINS at NBS-10 Subject: FIPS Standard replies To: Feinler at SRI-KL cc: Gumpertz at CMU-10A If network mail is sent to me (Watkins @nbs-10) concerning the proposed standard, I will print it out and forward to the proper person. I will not be able to do more than simply print it out on a line printer, so if anyone is concerned with formatting and type quality be forewarned that the transmission medium will be line printer type and paper. Shirley -------  Date: 24 Feb 1978 1652-EST From: Rick Gumpertz at CMU-10A Subject: net replies To: PBARAN at USC-ISI, MsgGroup at USC-ISI, Header-People at MIT-MC Message-ID: <24Feb78 165218 RG02@CMU-10A> I just got this -- Rick - - - - Begin forwarded message - - - - Date: 24 Feb 1978 (Friday) 1647-Est From: WATKINS at NBS-10 Subject: FIPS Standard replies To: Feinler at SRI-KL cc: Gumpertz at CMU-10A If network mail is sent to me (Watkins @nbs-10) concerning the proposed standard, I will print it out and forward to the proper person. I will not be able to do more than simply print it out on a line printer, so if anyone is concerned with formatting and type quality be forewarned that the transmission medium will be line printer type and paper. Shirley - - - - End forwarded message - - - -  Date: 3 Mar 1978 1156-PST From: Kahler at SUMEX-AIM Subject: FIPS Proposed Standard Sample Session To: [ISI]Mailing.List;149: cc: Header-People at MIT-MC To my understanding, this is what a typical terminal session might look like under the proposed standard. If this message takes a lot of paper, well, so will logging in and out under this proposal. Line editing, by the way, is not provided, or even anticipated. For all I know, we are expected to be perfect typists. [Signal your communications network (in this case the local TIP) that you want service and identify your terminal, then...] [TIP may type out a "network information message" identifying the TIP and the ARPA network] Abbreviated form - Yes or No? :No [User may also type HELP, ?, or LIST] Enter destination :SUMEX-AIM SUMEX-AIM is available Enter identification :Smith Enter password :password [Either not echoed, underprinted or overprinted] ["Service operation" commences] . . . [User types ^P at some point to exit] ^P Enter one of the following: Terminate or Leave or Stay or Suspend :T Smith has terminated SUMEX-AIM at date/time [Optional accounting stuff] END Rich -------  Date: 3 Mar 1978 1433-PST From: Feinler at SRI-KL (Jake Feinler) Subject: FIPS standard To: header-people at MIT-MC cc: feinler I talked to Shirley Watkins and she said that there are set procedures for having one's comments registered with respect to a FIPS standard. The most important procedure is that the comments must be received in writing and be signed by the sender. This may mean that the comments forwarded to Shirley (I believe at least two people responded to her) may not be valid input. There is still time for those of you who responded online to do so in a signed letter. I thought you would want this input so that you can make your comments count. Regards, Jake If you have questions you might direct them to either Shirley Watkins (Watkins@NBS-10) or Tom Pyke (Pyke@NBS-10) I would appreciate receiving copies of the dialog, if any. Thanks. -------  Date: 4 MAR 1978 0014-EST From: RMS at MIT-AI (Richard M. Stallman) To: watkins at NBS-10, pyke at NBS-10 CC: Roach at MIT-MULTICS, Tavares at MIT-MULTICS CC: Saltzer at MIT-MULTICS, Feinler at SRI-KL, Wulf at CMU-10A CC: Wactlar at CMU-10A, Newcomer at CMU-10A, msggroup at USC-ISI CC: header-people at MIT-MC I am not certain that I will be able to find the mental wherewithal to mail an actual US mail letter within a week. I hope that whoever is designing the standard is not legally prohibited from taking into account any knowledge that he gets via unofficial channels (though I wouldn't be surprised if the government were so cretinous). Here is the story: The operations which the login/logout standard is trying to standardize have no resemblance to the actual operations performed by users of most timesharing systems. IF it is true that the user is going to specify a service, his name, and a password, then the standard is fine as a way of doing it. But that isn't usually the case. Problems with the standard for Login: I know of no system except Multics in which the user says ANYTHING about what he intends to do before he logs in. If we interpret a "service" to mean the use of one or more programs, then the user does all the specification of the services he wishes to use AFTER logging in, on most systems. It would be horrible to be forced by a standard to restrict him! If, as the standard perhaps (it's not clear) suggests, a service is a large number of programs that can be used together or sequentially, than most timesharing systems offer only one service: the entire set of programs available on the machine. Thus, there is no point in asking the user to specify the service in advance. "Hello, welcome to ITS. What service would you like: ITS or ITS?" So far, things would be OK if only the "destination" specification could be omitted by the 99% of all systems which don't want it. But there is an additional problem: most systems provide "service" to the user BEFORE HE LOGS IN. Commercial systems such a Bottoms-10 and Twenex allow the user to run some programs such as SYSTAT or talk to the operator before logging in. Since the user does this exactly the same way he would do it if he WERE logged in, clearly the system is not doing anything special; it is just providing a restricted subset of the same (unique) service which it provides to logged-in users. On my system, ITS, it's even worse. Essentially complete service is available to whether you log in or not. This is deliberate and provides benefits to the user. But the login standard says that the computer MUST make the user log in as the very first thing he does, not giving him a chance to ask to do anything else. And when the ITS user decides to log in, he does so by typing a command, using the same syntax used for other commands. The command syntax used is ": ". Clearly it is better for the user to have a consistent syntax available for all commands including the :LOGIN command. Problems with the standard for "exit requests": As for the "exit request", its format limits the flexibility of the operating system and limits its architecture. I will describe each of the three operating systems for the PDP-10 and how it would be affected. Note that the problems depend on whether a "service" is a single program invocation or a whole session; I will describe separately the problems resulting from each assumption. ITS and Tenex/Twenex, if each program is a "service": On ITS and Tenex/Twenex, the user's "system commands" are actually read by a top-level command-reading program, a user-mode program distinguished very little from other programs run by the user. It creates inferior jobs and runs programs in them as specified by the user. Now, of course, there is a character to interrupt an inferior job and give more commands to the top level. If we regard each invocation of a program as a distinct service, then it is analogous to what the standard calls an "exit request". On ITS it is ^Z (Control-Z); on Tenex/Twenex it is ^C. It could conceivably be ^P, if that weren't already used for other things. But what it does is not the same as what the standard says about exit requests. It simply stops the inferior and lets you give more commands. You can give a command to continue (like "stay"), or a command to log out (like "terminate"). On Tenex/Twenex, you can run some other program, analogous to "leave". On ITS, you can run some other program, but it is analogous to "suspend" since ITS's top level allows up to 8 inferiors and all are independent. If you want to get rid of your old service, you must explicitly kill it. ITS also allows you to do other things, such as tell the program to run, but without control of the terminal (good for an assembly with its error output diverted). Of course, on both systems you can give innumerable other commands to communicate with other users, inquire about the system status, list your directory or delete or copy files, etc. without interfering with the job you have exited from. You aren't forced to say what to do with it right away; you can attend to other things and decide its fate whenever it is convenient for you. This is especially true on ITS, where absolutely anything else you do will not interfere with the status of the suspended program unless you explicitly kill or restart it. This power is very convenient, but it is forbidden by the standard, assuming once again that each program invocation is a service. ITS and Tenex/Twenex, if a whole session is a "service": If each program invocation is NOT a distinct service, then the whole session is one service-invocation, and the exit request can only be interpreted as a request to log out. On ITS and Tenex/Twenex, the way to log out is to give the appropriate command to the top-level program, which executes a logout system call in response. First, you must interrupt the inferior you are using, if necessary. The standard appears to require that a ^P be interpreted, at all times (not just when you are talking to the top level), as a request to log out. This can only be done by making ^P give control to the top level. This is an imposition on the character set available for inferior jobs; they can't use ^P for anything. Since the character for exitingthe inferior has to exist anyway, and logging out can be done with that followed by a command to the top level, the imposition is totally unnecessary. It is also somewhat of a screw. On ITS, you can run the usual top-level as an inferior, and command it to run sub-inferiors. It behaves totally as usual, except that it can't log in or out. The inferior-escape ^Z works with it too, since it really goes up one level rather than to the top. ^P, on the other hand, would have to go all the way to the top. This is rather untasteful. Also, logging out is not something done frequently, and, from an information-theoretic standpoint, it should not have a particularly short command. There are a dozen things I do far more often than log out. Should each one have a character to request it, which works all the time? They each deserve one more than logging out does. But better is not to give a special character to any of them. The top level program has commands for them all; I need only type ^Z or ^C to get back to it, and give the command. Finally, since ITS offers only one service ("ITS") and Tenex/Twenex offers only the "Tenex" or "Twenex" service, what is the meaning of "Leave"? Bottoms-10: So much for ITS and Tenex/Twenex. For Bottoms-10, the architecture is simpler - there is "the user's program" and there is the "system command level" - so there are no problems there. But the other problems - that the existing system is much more flexible than the standard allows - are the same. You type ^C or ^C^C to stop a program. ^C makes it stop only as soon as it waits for input. ^C^C stops it right away. This distinction is very useful and nobody would like having to give it up. Then, you can restart the program or run something else, or do various other things before you have to make up your mind. When you do decide, you speak your mind by giving a command, in the same syntax that system commands always use. This internal consistency is certainly valuable. It can't fit in with the logout standard, though, since the standard is designed for a situation where the possible user commands form a very limited set. So much for what happens if each program is a distinct service. If the whole session is one service, the problems are again similar to those of ITS and Tenex/Twenex. You log out by giving a system command, if necessary typing ^C or ^C^C first so you can give system commands. If ^P were to be effective at all times, it would be an additional superfluous way of exiting a user program. And again, logging out isn't frequent enough to need such special treatment. Conclusions: The conclusion is that the standard assumes that systems differ only in minor details from a specific model of interactions, and attempts to standardize the minor details. This assumption is false; the model used differs more from most timesharing systems than the systems differ from each other! In fact, the only systems I know of which actually fit the model assumed by the standard are the TIPs, ELFs, and other systems which exist only for communication with other systems. A user of the TIP might indeed specify his "destination" first of all, and then give his user name. Of course, TIPs don't ask you for a user name. So the model seems to fit only the composite interaction in which the TIP asks you for your destination, and connects you, and the machine you are connected to asks you for your name. The TIP also does have an escape character with which you can at any time close your connection to "leave" or "terminate". So I think that the proposed standard needs major rethinking. If what you want is a standard for TELNET programs and their command syntaxes, you should call it that, and not say that it applies to loggin in and out of timesharing systems. Questions: I would like to know your specific attitudes toward the problems I have mentioned. For example, do you think that standardization is so important that it outweighs all these disadvantages? Or do you think that the disadvantages don't exist? Do you consider a "service" to be a single program, or a session? Which systems did you have in mind when you formulated the standard? What, exactly, is a "Federal user"? Is everyone funded by ARPA a Federal user? What if ITS decides that the unspecified preamble for establishing communication consists of "^Z :OWATABUBIAM"? Is that within the standard? I will be glad to try to send you a US mail copy of this if it is important, though I can't promise success. Should I? What will that accomplish? Please send the answers to these questions to all the recipients of this message. Plea: PLEASE, PLEASE allow more time for comments, even a week more. Much of the ARPANET community learned about the proposed standard less than a week ago (Nobody makes a habit of reading the Federal Register here). It takes time for a person to articulate his thoughts. Everyone who has seen the standard here has been so shocked that he couldn't think. I am the first to recover enough to say anything coherent. My friends are so stunned they can't find words!  Date: 4 Mar 1978 1718-PST From: MRC at SU-AI (Mark Crispin) Subject: FTP in reality and myth To: Feinler at SRI-KL, Postel at USC-ISI CC: Header-People at MIT-MC [Jake and Jon, please forward this to the liaison group and the RFC list] While looking through the new protocol handbook (a beautiful job btw as an aside to the editors), I again noticed the funny state which the FTP protocol is in. For one thing, the document specifies a protocol which allegedly became official back in 1974, and which for the interim was to live on socket 21. Well, today, we have, according to "assigned numbers" the "old" FTP protocol living on socket 3, and the "new" protocol living on socket 25. A quick look by me on the network failed to find anybody who had a socket 25 FTP server. In addition, I noticed several pages devoted to conflicting descriptions of the reply codes. I have been told (though I do not know, since this was before the time when I was doing network programming) that the new protocol was so much hairier than the old one that nobody wanted to spend the time or money to implement it. I would like to bring this up before the community of ARPAnet hackers. Exactly what is the real state of the FTP protocol? How close is the true implementation to what the book says? I don't think it helps much to have the book describe a beautiful but legendary protocol. Additionally, on the reply codes, what is the true state of things on this? What document is telling the truth? Why isn't the "old" FTP protocol documented, if it is closer to reality than the "new" protocol? It seems like a major screw to not document an important protocol such as FTP (I have similar feelings about the lack of documentation on the old TELNET protocol, despite my strong preference for the new protocol). The reason for these questions is this; how else do you answer protocol questions when a conflict comes up between two hosts on who is losing by violating protocol? Worse, if the network software undergoes a redesign, compatability means the old protocols have to be supported too. Old source listings which may or may not themselves by lying aren't too helpful. I would like to hear the opinions of others on this matter. Perhaps if the "new" protocol really contains necessary improvements over the "old" one, then ARPA should fund the manpower for everbody to convert. Otherwise, the "new" protocol should be abandoned and something be done to clean up the mess on the "old" protocol so somebody going to write an FTP implementation knows what the hell is going on! Cheers, Mark -------  Date: 6 Mar 1978 1311-PST From: MRC at SU-AI (Mark Crispin) Subject: FTP continued To: MsgGroup at USC-ISI, Header-People at MIT-MC To: Feinler at SRI-KL, Postel at USC-ISIB The responses I have received so far seem to indicate that the new FTP protocol is not implemented by anybody, and that there are enough differences between the new and the old FTP protocols so that a different type user and server probably could not talk to each other effectively. Additionally, the people who replied to me were unanimous in their feelings that the new protocol should be flushed and replaced with a well-documented version of the old protocol. The feeling seemed to be that if any changes were necessary to the protocol, it should be in the reply codes to ensure standardization and to make them more esoteric. Because of this, I am asking the network hacker community if anybody is interested in forming a new "FTP group", to be charged with the responsibility NOT to design a new FTP protocol, but rather to get an agreed-upon standard documentation for the old protocol and possibly change the sense of some of the reply codes. The FTP protocol that results from this group's efforts is to conform to the reality of today, instead of generating a protocol that someday might be reality. The only changes to existing programs should be ones which are to correct what are violations of protocol today. What does everybody think? Jake and Jon, please forward this to the RFC and network liaison groups; and please also inform us what the chances of this project meeting with official sanction? I really believe that having a documented protocol which nobody implements while the implemented protocol is undocumented is intolerable; and I hope it isn't a case of an immovable object and an irresistable force. regards, -- mark -------  Date: 6 MAR 1978 1948-EST From: KLH at MIT-MC (Ken Harrenstien) To: mrc at SU-AI CC: HEADER-PEOPLE at MIT-MC, MsgGroup at USC-ISI Read RFC 691. It should be available from SRI-KL as RFC691.TXT. It has been around for quite a while, proposes ways in which the advantages of new FTP can be obtained with old FTP, and other good stuff. Probably it has not been pushed as much as it should have been because the author (Brian Harvey) took off for Paris for a couple years shortly after writing it. However, in one of my recent RFC's (XRSQ/XRCP, #743) I explained my position on reply codes, pointed out the 3 possible sets, and declared intent to use 691's - and nobody has commented. So perhaps the answer is that nobody reads RFC's. In any case the preface to the "new FTP" document lists RFC numbers which you can look up (or ask the NIC for) to get the scoop on old FTP and bickering thereof.  Date: 7 Mar 1978 1020-PST From: Kahler at SUMEX-AIM Subject: May I be put on the mailing list? To: Header-People at MIT-MC Can someone also show me where the previous Header-People messages are? I am a member of MSGGROUP and don't want to miss the Header-People stuff. Rich -------  Date: 09 MAR 1978 1337-EST From: JZS at CCA Subject: Re: May I be put on the mailing list? To: Kahler at SUMEX-AIM cc: Header-People at MIT-MC In response to your message sent 7 Mar 1978 1020-PST Header-People messages and the mailing list are maintained by Ken Harrenstien on MIT-MC. In addition, all Header-People messages are archived on the Datacomputer at CCA, and may be retrieved by sending a Retrieval Request to MARS-Retriever (or MARS-R) at CCA. I'm including, below, a sample RR which will retrieve the first month's messages. The date qualification is used to avoid getting nearly 800 messages (some of them quite lengthy) all at once. SAMPLE RR: (send message to MARS-R or MARS-Retriever@CCA) (SUBJECT: field is not used for retrieval) (the message body is the 'request form') TO: Header-People SINCE: 24 Sept 1976 UNTIL: 24 Oct 1976 ------- It is also possible to retrieve on the basis of words in the subject-field of the filed messages (e.g., SUBJECT: FIPS), and separately on the basis of words in the message body (e.g., TEXT: proposed standard). RFC744 describes MARS service more fully. I'd be glad to send you a copy - and to answer any other questions you might have about it. Joanne Z. Sattley JZS@CCA -------  Date: Fri, 10 Mar 78 14:21-PST Subject: RFC 733 Mail standard: Group Names From: Dcrocker at Rand-Unix To: Header-People at Mit-Mc cc: Borden at Rand-Unix Message-ID: I have two points to raise and want to keep the discussions separate, so the second will come in a different message. In implementing a parser for 733, we discovered that having group names be optional makes life much more difficult, even tho it isn't ambiguous. The problem is that, when beginning an
parse, encountering a ":" doesn't have a single meaning and it can be quite a while before you get to the comma or colon or other separator that decides the issue. For example: :include:foo at bar;; consists of two groups, one nested inside the other, where the first has no name, and the second is named "include". That may be a strange construction, but it's legal and the ambiguity isn't fully resolved until the first semi-colon is encountered. My suggestion is that we make life vastly simpler by requiring groups to have names. Therefore, if you hit a colon at the beginning, you know you have a "data type" label. Comments? Dave.  Date: 10 Mar 1978 1735-PST From: Kahler at SUMEX-AIM Subject: Great big long message coming To: [ISI]Mailing.List;149:, Header-People at MIT-MC, To: Roach at MIT-MULTICS, Saltzer at MIT-MULTICS, To: Tavares at MIT-MULTICS, Sproull at CMUA, Wulf at CMUA I wrote six pages of comments for the proposed FIPS which I will be sending to Shirley Watkins at NBS-10 and copying to you. I spent a lot of time on it, I hope it is read at NBS. Rich -------  Date: 10 Mar 1978 1817-PST From: Kahler at SUMEX-AIM Subject: Comments on proposed FIPS for user-terminal protocols To: Watkins at NBS-10, pyke at NBS-10 cc: [ISI]Mailing.List;149:, Header-people at MIT-MC, cc: Roach at MIT-MULTICS, Saltzer at MIT-MULTICS, cc: Tavares at MIT-MULTICS, Sproull at CMUA, Wulf at CMUA March 10, 1978 Associate Director for ADP Standards Institute for Computer Sciences and Technology National Bureau of Standards Washington, DC 20234 Comments regarding the proposed Federal Information Processing Standard entitled "User-Terminal Protocols -- Entry and Exit Procedures between Terminal Users and Computer Services", found in the Federal Register for Monday, December 12, 1977, pages 62408-62416: I wish to suggest several ways to increase the flexibility of the standard so it may better "benefit the users of computer services" and "in so doing impose minimal constraints upon the suppliers of computer services" (from the introduction, page 62408). These suggestions fall under the following categories: 1. User waiver of the standard's requirements 2. Who handles what? 3. Flexible ordering of system messages 4. Line editing 5. Exit-choice message 6. Available help 7. Multiple communications networks 8. Linefeeds USER WAIVER OF THE STANDARD'S REQUIREMENTS The protocol specified in the proposed standard is intended, and should be intended, for the use of computer novices and infrequent computer users who need a simple, understandable, predictable means of reaching their destination. As I understand it, there is no reason to require that more experienced users use the same protocol. Computer services do make a great variety of tools available to users during the entry/exit process with which the novice need not concern him or herself, but which the more experienced user finds very valuable. It is not the purpose of the standard to provide all these tools in a standard fashion. Neither do the goals of the standard make it in any way necessary to deny the experienced user access to these tools. We therefore need to provide in the standard a means for the user to waive its requirements and interact with the computer service in its own language and on its own terms, as is now the case, in order to have the full power of the computer service available to him or her. For example, make the word "WAIVE" and/or an "escape signal" such as the ASCII ESC code an acceptable user response to any of the system prompts specified in the standard, at which point the user will be able to interact with the computer service as though this standard had never been in force. This implies, of course, that the exitrequest signal will not be recognized by the computer service as such. That in fact is what would be desired by such a user, otherwise, the waiver would only be a partial one. Let the waiver be an implementor option. The implementor need not provide an alternative means of entry and exit outside the standard, but should be free to do so. All implementors of course do so now, since there is no standard in force at this time. WHO HANDLES WHAT? The definition of "computer service" provided in Appendix B and the rigid destination-userID-password sequence provided in the body of the proposed standard are the source of serious confusion. Is the user to be required every time to interact with a terminal telecommunications network which prompts him or her for a computer service name (destination) and then makes the connection, whereupon the computer service requests user identification and password at its option? Or is the network required to obtain destination, userID, and password from the user and actually log the user in at the destination? (This would cause an uproar. It would require that the network control every computer service on every network it had access to. Computer installations would be unable to manage their own affairs.) Who is supposed to intercept the exitrequest signal, the computer service or the network? If the computer service, how will the user exit the network if the service malfunctions? If the network intercepts the signal (as it should, being closer to the user) how can the user exit from the computer service first using a means provided by the standard? Worse yet, is a destination, as some speculate, an individual program running under the operating system of a computer service? A separate login might then be required to run each separate program! (This does not seem to be the case in view of the definition of "computer service", but the definition itself (A coherent logical entity...) is too vaguely general for me to be sure.) What the drafters of the proposed standard envision may be entirely different than any of the above, in which case can it be called a clear, concise, well-thought-out document in view of the wide range of futile attempts to read its meaning? My conclusion, after all this, is that the standard's authors in the attempt to make the network's operations transparent to the user (see Appendix A) have themselves confused the operation of the network with the operation of the computer service. I would recommend that we remember that the network is a computer service in its own right, performing a valuable function for the user, yet physically and logically separate from the destination computer services it serves. Perhaps the inexperienced user doesn't need to know this, but we do. The definition of "computer service" needs to reflect this understanding and be more simply, concisely and understandably defined, perhaps as: "A computer running a program that interacts with a user through a terminal, sending messages to the terminal and accepting commands and data from the user." There are many computer services which do not deal with user terminals, but we are not concerned here with them. It is the network's task to obtain a destination from the user and make the connection. It is then up to the destination computer service whether or not to ask for user name and password before proceeding. If there is no network intervening, a destination request is superfluous. The exitrequest signal (or some panic signal, see below under multiple communications networks) must be handled by the computer service (network or otherwise) closest to the user. If a panic-exit signal is provided for the user, the exitrequest signal can be sent through to be handled by the most remote computer service in use at the time. FLEXIBLE ORDERING OF SYSTEM MESSAGES There are only three combinations of the three parts of the entry protocol allowed by the proposed standard: destination only, or destination-userID or destination-userID-password. In practice, any combination will come up. If the standard is to be designed so as "not to impede technological advancements in computer services and networks" (from the introduction, page 62408), much greater flexibility is needed. In my networking experience I have personally encountered: destination-ID, destination-ID / user-ID / user-password, destination-ID / destination-password / user-ID / user-password, destination-ID / destination-password, destination-password, destination-password / user-ID, destination-password / user-ID / user-password, user-ID, and, most frequently, user-ID / user-password. These are all legitimate and proper combinations, and more are possible. Can this variety be any source of confusion in the user's mind, provided that prompting for each is uniform? When the user is prompted for a destination, password, or anything else in a consistent fashion, it is clear what is wanted, the user supplies the information and the interaction proceeds. The user is happy and the implementor has the information he or she needs in the order he or she needs it. I suggest that no specific order be required. I also suggest that the prompt for user identification be "Enter user identification" rather than "Enter identification", since in the majority of cases this prompt will be the first given, and it would otherwise be ambiguous which kind of identification is required. LINE EDITING Line editing capabilities are entirely unaddressed by the standard. This is a serious omission, especially from the novice's point of view. Any standard which attempts to serve the needs of the terminal user should provide a means for the user to correct typing errors before giving the user signal. Uniformity in line editing practices for the interactions covered by this standard would be as beneficial to the novice as the standardization of the system messages required for them. I propose a minimum of two editing signals for standardization. These may be called cancel-last-character and cancel-entire-line. The cancel-last-character signal requests that the computer service cancel the last text character typed in, whereupon the next-to-last text (i.e. non-editing-signal) character typed in becomes the last. Repeated cancel-last-character signals eventually would cancel the entire line. The cancel-entire-line signal would ask the computer service to ignore all that has been typed in since the system signal was last given, optionally print " XXX " on the current line, and repeat the system signal. The system response to the cancel-last-character signal may take one of several forms. On display terminals, when terminal character- istics are known to a sufficient extent, the character may be erased from the screen. On other terminals, the cancelled character may be retyped, preceded or followed by a slash (/), or preferably surrounded by square brackets ([]). It is not difficult, when several characters are cancelled in succession, to delay the printing of the right square bracket until some other character than cancel-last-character is typed. A typescript showing :ABCDE[EDC]ACUS would, if retyped by the system, be :ABACUS. The user, in this case, had typed "ABCDE###ACUS", where "#" indicates the cancel-last-character signal. My suggestions for default values for these signals: cancel-last-character DEL (DELETE, RUBOUT) and/or BS (BACKSPACE, control-H) cancel-entire-line CAN (CANCEL, control-X) Two other useful editing signals are cancel-word and retype-line, but ASCII has no control codes set aside for these functions. Cancel-word cancels characters up to, but not including, a space or tab. Retype-line shows the user what the input line really looks like after editing has been done. cancel-word ETB (control-W) retype-line DC2 (control-R) EXIT-CHOICE MESSAGE The exit-choice message (whose format may well have been the result of careful deliberation): Enter one of the following: Terminate or Leave or Stay or Suspend : is too long to be typed out on a 110 or 300 baud terminal every time the user wishes to exit, regardless of the fact that abbreviations may be available. In practice, users often need or wish to exit quickly. I suggest: Enter exit choice (Type ? for help) : (which is bad enough), with the requirement that help be offered in the same fashion as with the abbreviated form request. Perhaps implementors can be given the option of implementing either the longer message with no help provided or the shorter message with help available. AVAILABLE HELP The interests of the user would indeed be served if HELP, ?, and LIST were acceptable user responses every time the user is prompted with the system signal, as with the abbreviated form request, so that the user may have help at any point. Such a consistent feature would be welcomed by many a confused user, and would likely be found in use at one time or another at every point at which it is offered. If not required it should at least be permitted. MULTIPLE COMMUNICATIONS NETWORKS When, for example, two networks are involved in the connection process to a destination, the standard should make it clear that the user needs to give the second network as the destination to the first network, then the real destination to the second network. The first network cannot be required to know the names of all destinations accessible from all connecting networks. If such a thing is meant to be required, let that be clearly stated. Implied requirements such as these, which upon examination prove to be unreasonable and unworkable, are of course unacceptable. They are evidence that the impact of the standard, first on implementors and then on users, is not well understood. This is another result of the effort to make the network(s) involved totally transparent to the user. When a network is invoked in the terminal communications process, it will identify itself, request a destination of the user and make the connection. Each network invoked in turn identifies itself and repeats this simple process. The user will know by this interaction that he or she is talking for that brief period to a network. The network must provide a means for a panic exit for the user's safety, and the user should be aware that when the exitrequest signal (sent all the way down the line to the final destination) doesn't produce any results, there is still a way out. The panic signal, though armed by all networks (unless the user has issued a waiver), will be trapped of course by the first network in the chain, which will perhaps initiate a normal exit-request sequence. This is the minimum awareness a user must have of the network. In my opinion, every user using a network needs to know this much for his or her protection. It need not be at all confusing to the novice when properly and simply explained and demonstrated. The novice need know no more about the presence of the network than this. Regarding a default value for the panic-signal, I would suggest what is probably one of the least used control characters in ASCII because it is more difficult to type. It cannot be typed by holding the CTRL key down and typing a letter. It is FS (control-backslash), octal 34, decimal 28. The ESC (escape) code, though it may seem appropriate, is too heavily used for program commands and setting terminal parameters to be armed for a special purpose throughout the terminal session. I do suggest it for user waiver of the standard protocol (see above), because it will only be recognized as such during an entry/exit sequence. LINEFEEDS A minor detail - the ASCII linefeed character (LF) should also be in the list of characters required to be displayed by the terminal. The ASCII carriage return character (CR) returns the carriage to the left margin on the current line. An LF must follow the CR to move the carriage down to the next line. Even though some terminals will do a CRLF combination every time they receive a CR, this is not ASCII, and is not desirable for such applications as underlining or overstriking text on a line-by-line basis. The confusion arises because in common practice when the user types the CR key on a full-duplex terminal it is echoed by the system as CRLF. The drafting committee needs to have experienced assistance from users and implementors who are familiar with existing terminal communications networks like the ARPANET and TYMNET. Otherwise it may come up with another proposed standard that is impractical to implement where networks are concerned. I hope you will give these comments careful consideration. Sincerely, Richard Q. Kahler SUMEX Computer Project TB105, Stanford University Medical Center Stanford, CA 94305 -------  Date: Saturday, 11 Mar 1978 0220-EST From: Philip.Karlton at CMU-10A Subject: Re: RFC 733 Mail standard: Group Names To: Dcrocker at Rand-Unix CC: Header-People at Mit-Mc Message-ID: <11Mar78 022000 PK01@CMU-10A> In-Reply-To: I go along with the suggestion for forcing groups to have a non-null name. PK  Date: Sunday, 12 Mar 1978 1920-EST From: Brian K. Reid Subject: Proposed FIPS standard for User-Terminal protocols To: Watkins at NBS-10, Pyke at NBS-10 CC: MsgGroup at ISI, Header-People at MIT-MC, Roach at MIT-MULTICS, Saltzer at MIT-MULTICS, Tavares at MIT-MULTICS Associate Director for ADP Standards Institute for Computer Sciences and Technology National Bureau of Standards Washington, DC 20234 Re: Proposed FIPS entitled "User-Terminal Protocols -- Entry and Exit Procedures between Terminal Users and Computer Services" Sir or Madam: There are two difficulties with the proposed standard: (1) Technical problems with the details of the standard. (2) Administrative problems with the scope of applicability of the standard. I shall try to be brief rather than exhaustive. (1) The first point is just a couple of nits: - The DLE character (Data Link Escape) does not mean "escape from the data link", it means "begin an escape sequence" and is to be used by protocols within the data link. It is probably a very bad idea to have a single character be used to signal an exit request, but if you must use a single character, the correct one is probably EOT (End of Transmission). - There are no provisions for line and character editing: what is typed to erase a character or a line. (2) The second point is the meat of my comment. This standard is intended to apply to "Computer Services" It would be quite reasonable to standardize the login/logout procedure for turnkey user programs used by non-programmers, many of whom are hostile towards computer systems and want only the results of the user programs. For this set of computer users, namely those who are using canned software as a tool in the course of their daily work, there should be not only a standardized login/logout procedure but an attempt made to shield them from the knowledge that they are using a general-purpose interactive computer system. The authors of this standard have correctly noticed that users of turnkey software systems are often hostile towards the computers and annoyed at the differences that they find, but these turnkey system users, although numerous and influential, are not the only class of user of computer services procured by the Government. Programmers of any kind, whether Cobol trainees at HEW or assembly-language experts at some weapons lab, will be driven up the wall by this standard. The authors of this standard should recognize that these various classes of users exist, and should restrict the applicability of the standard so as to cover turnkey software services rather than all computer use. Brian K. Reid Graduate Student Department of Computer Science Carnegie-Mellon University Pittsburgh, PA 15213  Date: Sunday, 12 Mar 1978 1920-EST From: Brian K. Reid Subject: Proposed FIPS standard for User-Terminal protocols To: Watkins at NBS-10, Pyke at NBS-10 CC: MsgGroup at ISI, Header-People at MIT-MC, Roach at MIT-MULTICS, Saltzer at MIT-MULTICS, Tavares at MIT-MULTICS Associate Director for ADP Standards Institute for Computer Sciences and Technology National Bureau of Standards Washington, DC 20234 Re: Proposed FIPS entitled "User-Terminal Protocols -- Entry and Exit Procedures between Terminal Users and Computer Services" Sir or Madam: There are two difficulties with the proposed standard: (1) Technical problems with the details of the standard. (2) Administrative problems with the scope of applicability of the standard. I shall try to be brief rather than exhaustive. (1) The first point is just a couple of nits: - The DLE character (Data Link Escape) does not mean "escape from the data link", it means "begin an escape sequence" and is to be used by protocols within the data link. It is probably a very bad idea to have a single character be used to signal an exit request, but if you must use a single character, the correct one is probably EOT (End of Transmission). - There are no provisions for line and character editing: what is typed to erase a character or a line. (2) The second point is the meat of my comment. This standard is intended to apply to "Computer Services" It would be quite reasonable to standardize the login/logout procedure for turnkey user programs used by non-programmers, many of whom are hostile towards computer systems and want only the results of the user programs. For this set of computer users, namely those who are using canned software as a tool in the course of their daily work, there should be not only a standardized login/logout procedure but an attempt made to shield them from the knowledge that they are using a general-purpose interactive computer system. The authors of this standard have correctly noticed that users of turnkey software systems are often hostile towards the computers and annoyed at the differences that they find, but these turnkey system users, although numerous and influential, are not the only class of user of computer services procured by the Government. Programmers of any kind, whether Cobol trainees at HEW or assembly-language experts at some weapons lab, will be driven up the wall by this standard. The authors of this standard should recognize that these various classes of users exist, and should restrict the applicability of the standard so as to cover turnkey software services rather than all computer use. Brian K. Reid Graduate Student Department of Computer Science Carnegie-Mellon University Pittsburgh, PA 15213  Date: 13 March 1978 0018-est From: Robert M. Frankston Subject: Proposed FIPS for User=Terminal protocols To: Watkins at NBS-10, Pyke at NBS-10 cc: MsgGroup at USC-ISI, Header-People at MIT-MC cc: Roach at MIT-Multics, Saltzer at MIT-Multics cc: Tavares at MIT-Multics Associate Director for ADP Standards Institute for Computer Sciences and Technology National Bureau of Standards Washington, DC 20234 While I find the concept of a standard for entering and exiting computer based services attractive in some ways, I feel that the current attempts are premature and beset by technical problems. The standard is both too constricting and too vacuous. The essense seems to be the specification of a single destination and establishment of the exit procedure. The core of the entry procedure seems to be the specification of a destination (a strange term for the name of a service). Only one service may be specified at a time. This is a basic fallacy since the use of a communications network is itself a service. In Tymnet, for example, one must identify oneself to the network for billing purposes and access control. This is more than what seems to be allowed for in carrier accommodation action (4.1.3). Of course, one can stretch the meaning of 4.1 to include logging into a computer system since that can be considered simply part of the establishment of a communication path, and in doing so defeat the standard. As has been ponted out by others, specification of the service before authentication is very arbitrary since one may not know which service is desired before authentication. As a matter of fact, in many systems, the name of the service is known only whithin a given users environment (i.e. is listed in the user's directory) thus cannot be known prior to authentication. The authentication procedure itself is limiting. Some systems, like Multics (Honeywell 68/80) combine procedures 4.4 and 4.5 into a single authentication procedure so that one cannot determine the validity of a name without also knowing its password -- an attempt at additional security. Since the definition of a service is so vague, Multics can even be considered to combine specification of the destination into the same procedure in that the user's project name is also specified during the authentication procedure. As has been pointed out by others, the exit procedure also has problems. Aside from the use of the DLE character in an unusual manner there is the issue of which service interprets the control code. Also the attempt to limit one's choices of exit procedures is premature. One important class of exits is completely omitted -- one in which the user can disconnect from a service, but leave the service running noninteractively. If the specification of the destination and the exit procedures are not acceptable, one is left only with the use of the ":" as a prompt to the user and the user of the return character to end messages to the computer system (oh yes, also the suggestion that upper and lower case distinctions be ignored -- a point of contention among existing systems). The user of, and choice of signal characters seems to be a minor issue at this point. It seems premature to enforce a rigid standard at this point that completely governs the entry and exit procedures. The attempt to provide a uniform interface for users of computer systems seems, however, to be a reasonable goal. Perhaps the failure of the standard is its meekness. It requires that each computer system and service be modified to present a uniform interface geared to the lowest common denominator of terminals and classes of service. A bolder approach is to associate the smoothing of the interface with the terminal that can be personalized to the user's needs. What is requred is a set of high level protocols for communication between a user's terminal and a computer system. Much discussion is needed if such a protocol is to be developed, but the planning is necessary since any confusion due to differences in logging in and out of computer systems is trivial as compared with the interactions during the use of a service, especially with the ability to provide services dependent upon characteristics of specific terminals. PS: I want to express my dissatisfaction with the lack of publicity given to the standard. Admittedly this is just a Federal standard that is not intended to limit commercial usage. However, if the standard is to be implemented on a system by a manufacturer, the effect will be felt by all users.  Date: 13 Mar 1978 2026-EST Sender: HENDERSON at BBN-TENEXD Subject: Proposed FIPS standard for User-Terminal protocols From: HENDERSON at BBN-TENEXD To: Watkins at NBS-10, Pyke at NBS-10 Cc: MsgGroup at ISI, Header-People at MIT-MC Message-ID: <[BBN-TENEXD]13-Mar-78 20:26:53.HENDERSON> Associate Director for ADP Standards Institute for Computer Sciences and Technology National Bureau of Standards Washington, DC 20234 Re: Proposed FIPS entitled "User-Terminal Protocols -- Entry and Exit Procedures between Terminal Users and Computer Services" Sir or Madam: There are a number of problems with the proposed standard, but I wish to focus on one only. Computer systems will only be regarded as useful tools when they become forgiving of human errors. Even more strongly: they should be programmed so that the propensity for error among human is recognized and the computer can put its powerful resources to use in helping to correct them. We should strive for habitability as much as for power, for to be useful a tool must have both of these characteristics. The standard is not habitable as far as I am concerned. In entering the login information, no interaction with the user to help in this task is permitted: for example, how can a mistyped character be corrected? It is easily possible to mistype such that the terminal which one uses issues a DLE. For example, certain keyboards have the CNTL mode shift key beside the SHIFT mode shift key (the HP2645A, for example). Thus by a slight mispositioning of one finger, the attempt to type an uppercase P could cause immediate and irrevocable logout from the system. This seems a bit harsh. Sincerely, D. Austin Henderson, Jr. Computer Scientist Bolt Beranek and Newman Inc. Cambridge, Mass., 02138  Date: 13 MAR 1978 1905-PST From: POSTEL at USC-ISIB Subject: group names in 733 To: Header-People at MIT-MC cc: postel Dave: i agree that groups should have (non null) names. --jon. -------  Date: 14 Mar 1978 0034-EST From: Rick Gumpertz at CMU-10A Subject: group names To: Header-People @ MIT-MC Message-ID: <14Mar78 003441 RG02@CMU-10A> 1) I have no objection to requiring nnon-null group names. 2) Once again, I solicit comments on how to indicate that an address list consists of two alternatives, such as "Header-People@MIT-MC" or "Gumpertz@CMU-10a, Postel@USC-ISIB, ..." where either the fiirst or the second (but not both) alternative is an acceptable address for further correspondence. Perhaps some sort of change to group names to allow an optional "group address" would be reasonable? Rick  Date: Tuesday, 14 Mar 1978 1801-EST From: Philip.Karlton at CMU-10A Subject: Administrative: Mailing list changes To: MsgGroup at USC-ISI, Header-People at MIT-MC CC: RdMail at CMU-10A Message-ID: <14Mar78 180114 PK01@CMU-10A> Please change Philip.Karlton@CMU-10A to Karlton@PARC-MAXC Please add RdMail@CMU-10A.  From: Tavares.Multics at MIT-Multics Date: 03/20/78 1354-est Subject: Proposed FIPS To: Frankston at MIT-Multics, Roach at MIT-Multics, To: Saltzer at MIT-Multics, Tavares at MIT-Multics, To: Pyke at NBS-10, Watkins at NBS-10, Kahler at SUMEX-AIM, To: Feinler at SRI-KL, Gumpertz at CMU-10a, To: Newcomer at CMU-10a, Wactlar at CMU-10a Message-ID: [MIT-Multics]1.1.BBBJHLHwHjkkld Honeywell has responded to the proposed FIPS for login/logout in three letters. The first, sent in January, suggests that the assumption made by the standard that Government personnel tend to access more than one computer sys- tem, is false. It goes on to state that since the number of people accessing only one system exceeds the number accessing multiple systems, the total impact of having to re-learn the new procedures would be negative. It continues by expressing misgivings about the dichotomy of government purchasers insisting on off-the-shelf products, and other government agencies requiring special feat- ures for the government. Added to this is a statement that "Government use is a small percent of the total use", and mentions that users in the private sec- tor do not seem to be interested in such a standard. The second, sent earlier this month by our CBEMA representative, expresses "disappointment and concern that the Government has chosen to by-pass the pub- lic voluntary consensus standards-developing process", and quotes the relevant policy statement. It also warns against finessing the newly formed ISO/TC97/SC16 committee which is attempting to deal with just this problem. The third, sent just last week, was a nine page report dealing with spe- cifics, and expressing much of the same horror I have found in network communi- cations from others on this topic. Among the b^etes noirs mentioned were the upper-case only restriction, multi-network piggybacking, the single character exit request (which may be signalled by a dirty comm line), security implica- tions of telling a user whether it was the username or password that was wrong, and numerous requests for clarification. The letter ends by giving the propos- ers A for effort, but recommends it be referred to ANSI for more work. C. D. Tavares  Date: 20 Mar 1978 1418-EST From: Rick Gumpertz at CMU-10A Subject: FIPS To: MsgGroup @ USC-ISI, Header-People @ MIT-MC CC: Tavares.Multics at MIT-Multics Message-ID: <20Mar78 141814 RG02@CMU-10A> Chris apparently missed a few relevent people in his TO list for this note. I have taken the liberty of forwarding it. Rick - - - - Begin forwarded message - - - - From: Tavares.Multics at MIT-Multics Date: 03/20/78 1354-est Subject: Proposed FIPS To: Frankston at MIT-Multics, Roach at MIT-Multics, To: Saltzer at MIT-Multics, Tavares at MIT-Multics, To: Pyke at NBS-10, Watkins at NBS-10, Kahler at SUMEX-AIM, To: Feinler at SRI-KL, Gumpertz at CMU-10a, To: Newcomer at CMU-10a, Wactlar at CMU-10a Message-ID: [MIT-Multics]1.1.BBBJHLHwHjkkld Honeywell has responded to the proposed FIPS for login/logout in three letters. The first, sent in January, suggests that the assumption made by the standard that Government personnel tend to access more than one computer sys- tem, is false. It goes on to state that since the number of people accessing only one system exceeds the number accessing multiple systems, the total impact of having to re-learn the new procedures would be negative. It continues by expressing misgivings about the dichotomy of government purchasers insisting on off-the-shelf products, and other government agencies requiring special feat- ures for the government. Added to this is a statement that "Government use is a small percent of the total use", and mentions that users in the private sec- tor do not seem to be interested in such a standard. The second, sent earlier this month by our CBEMA representative, expresses "disappointment and concern that the Government has chosen to by-pass the pub- lic voluntary consensus standards-developing process", and quotes the relevant policy statement. It also warns against finessing the newly formed ISO/TC97/SC16 committee which is attempting to deal with just this problem. The third, sent just last week, was a nine page report dealing with spe- cifics, and expressing much of the same horror I have found in network communi- cations from others on this topic. Among the b^etes noirs mentioned were the upper-case only restriction, multi-network piggybacking, the single character exit request (which may be signalled by a dirty comm line), security implica- tions of telling a user whether it was the username or password that was wrong, and numerous requests for clarification. The letter ends by giving the propos- ers A for effort, but recommends it be referred to ANSI for more work. C. D. Tavares - - - - End forwarded message - - - -  Date: 21 Mar 1978 0038-PST From: MRC at SU-AI (Mark Crispin) Subject: message reliability, and a plea! To: Header-People at MIT-MC, MsgGroup at USC-ISI To: Feinler at SRI-KL, Malman at BBN-TENEXE In the course of the past few days, I have observed several cases where mail has not gone through for no good reason. My first gripe has to do with WHARTON being in this mode where any ICP to them ICP's back to your own host on the same socket. I understand that this mode is used for debugging the IMP interface. If so, WHY wasn't the NCC and the NIC told about this? And if they were, WHY weren't the network liaisons told? This means that mail to a person at WHARTON, instead of being delayed, it gets sent to that user-id at the sender's host! [God forbid a message ever get sent to a local user who has his/her mail forwarded to WHARTON--it will loop endlessly!] Please, people, if you are going to fool around like that, tell the rest of the world so we can make sure you will get your mail! I have also observed cases of messages being lost at other hosts due to something strange they are doing. For example: At CMU, apparently when the system is in "no login" mode (preparing for PM?) they accept FTP connections, but trying to mail to anybody there gets told NO REMOTE LOGINS AT THIS TIME. CMU should plain refuse the FTP connection so the message will be queued (or whatever is done when a host is down at the time) until CMU will accept mail; or CMU should allow mail even when the system is in this state. Harvard and NBS-10 both occasionally lose mail with a reply of "?Ill Mem Ref at user PC 000001". This message seems to indicate a bug in the mail program at their end, which I am told is non- repeatable but has been known for a long time. I wish they would do something about this. RAND-UNIX occasionally says "local system failure" or some such thing. Part of my unhappiness stems from the fact that SAIL's mail queuer does not mail the user the message s/he sent back, meaning it is lost forever. I've asked our mail maintainer to fix this problem but he hasn't gotten around to it yet. However, there is no good reason why mail should be lost in these cases. I wonder how many other sites have problems like these. Such things really degrade the reliability of ARPAnet mail greatly. -- Mark -------  Date: 21 March 1978 0915-est From: Robert M. Frankston Subject: Mail refusals To: Header-People at MIT-MC, MsgGroup at USC-ISI To: Feinler at SRI-KL, Malman at BBN-TENEXE I too have experienced CMU's login refusal. The long term solution is not for systems to refuse to communicate or fix all bugs. Rather there should be a reply code within FTP to say, I cannot process your request now, but perhaps at some other time I will be able to. The sender could then treat that as a refusal. Fancy senders can even inform the user's of the progress of their message. The issue of whether or not to return dead letters is a matter of local policy. An alternative solution, one that I prefer, is for the mail composition/sending program log a copy of the message for further reference in any case so that the user can get back the original if the copy sent is lost for any number of reasons, including those not apparent to the actual mail queuer/server program.  Date: 21 Mar 1978 0640-PST From: Feinler at SRI-KL (Jake Feinler) Subject: Re: message reliability, and a plea! To: MRC at SU-AI, Header-People at MIT-MC, MsgGroup at USC-ISI, To: Malman at BBN-TENEXE cc: FEINLER In response to the message sent 21 Mar 1978 0038-PST from MRC@SU-AI The NIC has received no word from Wharton for quite some time. At the last encounter they indicated that they were up and that the mailbox was now Wharton (instead of whatever else they had been using). This worked fine for a while and then mail to Howard Morgan began being rejected. He had used HMorgan also, so I changed to this. Again didn't work. Was about to call to find out what the problem was, but Mark seems to have pinpointed it. Since I will have occasion to send them some hardcopy mail, I will drop a copy of your complaint in the envelope. Jake -------  Date: Tue, 21 Mar 78 08:47-PST Subject: Re: message reliability, and a plea! From: Greep at Rand-Unix To: MRC at Su-Ai (Mark Crispin) cc: Header-People at Mit-Mc, MsgGroup at Usc-Isi, Feinler at Sri-Kl, cc: Malman at Bbn-Tenexe Message-ID: In-Reply-To: Your message of 21 Mar 1978 0038-PST Regarding your comment about the Rand-Unix server FTP saying `local system failure', we return, as do all other sites, what I believe to be appropriately numbered replies on conditions which temporarily make mail delivery impossible, such as no space available or inability to access necessary resources. Any information you or anyone else can provide on improper responses coming from here (e.g. unnumbered replies) would be appreciated; yours is the first such report I have had.  From: Pogran at MIT-Multics Date: 03/21/78 1457-est Subject: Message reliability; reflected ICP's and interface looping To: MRC at SU-AI cc: Malman at BBN-TENEXE, Feinler at SRI-KL, cc: MsgGroup at USC-ISI, Header-People at MIT-MC Message-ID: [MIT-Multics]1.1.BBBJHLLcFpBhKM Mark, I'd like to elucidate the "reflected ICP" problem that you mentioned with regard to Wharton. It's not Wharton's fault, believe me. It's the fault of the designers and maintainers of the IMP hardware and software, in not recognizing the effect that IMP-level maintenance software would have on high-level (e.g., FTP and mail) software throughout the ARPANET. We have experienced precisely this problem a number of times when the IMP port serving MIT-Multics was out of order and was being repaired (or, more likely, waiting to be repaired) by the Network Control Center. The problem is that, as a diagnostic aid, the NCC likes to "loop" the IMP's interface to a host. This can be done in either of two ways, both of which result in all messages directed at the host in question being returned to their sender! The first way this can be done is that a bit can be set in the IMP to cause the host interface in the IMP to loop the data around within the interface. This bit is normally turned on or off under program control remotely from the NCC. The NCC can then send messages to that host port, and they will be returned, via the looped host interface, to the IMP and to the NCC. The NCC software then looks for errors in the returned bits. The NCC can turn this bit on whenever they want to -- and they can just as easily forget to turn it off again! Looping can also be done physically at the IMP, by replacing the normal cable to the host's IMP interrface with a "loop-around plug" supplied with each IMP. Tests just like the ones used with the internal loop-around can be performed by the NCC, verifying the last of the interface hardware. Installation or removal of this plug is generally done by site (host) personnel at the request of the NCC. I've gone into all this detail because I believe it will aid in understanding the crux of the problem, which is this: The NCC seems to have the notion that while they've got the interface "looped", in whatever manner, nobody but the NCC will try to send messages to that host! Of course, that's not true. And, by virtue of the symmetry in the IMP-Host protocol which causes the IMP to route the wrapped-around NCC test messages back to the NCC, ANY message sent to that host port will be routed back to ITS sender. And -- this is the point the NCC ignores -- the symmetry of the Host-Host protocol results in any RFC directed at a looped host port being re-directed to the SAME destination socket at the ORIGINATING host! So, an ICP gets reflected, a mail request gets reflected, ... you get the idea. Now, because the NCC has the mistaken notion that nobody will try to send messages to a host port which is broken, and therefore looped, they will often leave an interface looped overnight, when, for example, a problem has been diagnosed in the late afternoon and a serviceman cannot be dispatched until morning. When the host in question is a major Network server, you can imagine the chaos! When I first discovered this problem affecting MIT-Multics, I suggested to Alex McKenzie that the IMP software be modified so that, when an interface is looped under program control, the IMP accepts messages for that interface ONLY from a designated host -- e.g., the Network Control Center. But nothing was ever done about it. So, Mark -- don't be cross with the Wharton people! Complain to the NCC instead! Yours for better networking, Ken Pogran  Date: 24 Mar 1978 0958-PST From: MRC at SU-AI (Mark Crispin) To: Header-People at MIT-MC, MsgGroup at USC-ISI Date: 24 Mar 1978 1253-EST From: SANTOS at BBN-TENEXE Subject: Re: Interface Looping To: Pogran at MIT-MULTICS, MRC at SU-AI cc: Feinler at SRI-KL, Malman, JHaverty, McKenzie, Walden, cc: Santos Ken and Mark, Ken's message of 3/21 was forwarded to me. Ken is basically correct in his description, although it should be pointed out that there is an internal IMP "Host test" that the NCC frequently uses which does not have these problems, i.e. the Host appears dead to the rest of the network. I have expanded the procedure for the NCC to use when conducting tests on a Host interface. They will now first change the Host's access control bits so that only the testing connection will be allowed. Other attempted Host connections will get back a Destination Dead (type 7, subtype 3). When they are done testing, the NCC will restore the normal Host access bits. By the way, the NCC does not often loop an interface and forget about it! I would appreciate it if you could update all the people on the original message's CC list as to our remedy. Also, feel free to report this kind of thing to me in the future. Regards, Paul ------- -------  Date: 30 Mar 1978 1209-EST Sender: HENDERSON at BBN-TENEXD Subject: Proposed MIL-STD-1679 (Navy) From: HENDERSON at BBN-TENEXD To: Header-people at MIT-MC Message-ID: <[BBN-TENEXD]30-Mar-78 12:09:37.HENDERSON> This standard is entitled: Military Standard Tactical Software Development The cover also contains the folloing NOTE: NOTE: This darft, dated 1 August 1977, prepared by Headquarters, Naval Material Command has not been approved and is subject to modification. Excerpt from contents: Section 5. Detailed Requirements. Section 5.3. Subprogram Design. Section 5.3.6 Recursive Programs. (page 5-6) Recursive procedures or programs shall not be used. The interesting part is that this section is in the midst of a design requirement which relects a strong requirement that structured programming discipline be used. Austin  Date: 25 APR 1978 0035-EST From: PGA at MIT-MC (Phillip G. Apley) To: HEADER-PEOPLE at MIT-MC People at other installations: Please place this conspicuously or put it on your message system. If you have seen this information already and are not interested, sorry to keep bugging you. If you are interested please read this fully. Some of the information has been changed. This is information about the MITERS Memory Co-op, a non-profit effort dedicated to getting cheap silicon for hackers everywhere. The more people involved, the cheaper the deal. No order is too small or large. Please tell your friends.  Date: 25 APR 1978 1127-EST From: PGA at MIT-MC (Phillip G. Apley) To: HEADER-PEOPLE at MIT-MC, pga at MIT-ML People at other installations: Please place this conspicuously or put it on your message system. If you have seen this information already and are not interested, sorry to keep bugging you. If you are interested please read this fully. Some of the information has been changed. This is information about the MITERS Memory Co-op, a non-profit effort dedicated to getting cheap silicon for hackers everywhere. The more people involved, the cheaper the deal. No order is too small or large. Please tell your friends. MIT ERS MEMORY CO OP 16K bits for $14.20 The TMS4116-30 is a 16K by 1 bit dynamic memory device normally available for a minimum cost of $38. It is compatible with the NEC UPD416 and the MK4116. The version we are purchasing is a device with maximum access time 300ns, and read write cycle time 500ns in a 16 pin plastic package. Refresh needs to be completed every millisecond, and temperature is speced at 55C. Thus far we have data sheets for the 4k 300 ns chip, for which timing is the same as the 4116-30. The difference in pinout is the substitution of an address bit for the Chip Enable line (the device must be externally latched). Data is also available for the 4116-25 (see your TI 'MOS Memory Handbook'). The Massachusetts Institute of Technology-Electronic Research Society is sponsoring this non-profit group purchase of TMS4116-30 memory components from Texas Instruments, intended to bring the low cost of large purchasing to individuals engaged in electronics research. Your signature on this order form indicates your guarantee that you qualify for tax exemption as a member of an educational organization (including undergraduates) engaged in electronics research. The Massachusetts tax exemption number for your educational institution should be provided. The cost of the components has been calculated to include the minimum shipping and handling charge. Cambridge residents will pick up their chips at MITERS. Unfortunately we are unable to accept credit, much as we would like to. Your university can send a check along with a purchase order, otherwise a personal check will be fine. Checks should be payable to 'MITERS Memory Co-op'. No orders will be accepted after May 5 1978. Any questions you may have will be answered at 617-494-0168, or contact PGA@MIT-ML through the ARPANET. _________________________________________________________________________ ORDER FORM Send to: Phillip G Apley MITERS 4 Ames St. #301C Cambridge, MA 02139 Please order me n= ____ (where n is any integer) units of the TMS4116-30. Enclosed find a check or money order for n x $14.20= ____. I realize that MITERS is responsible only for delivery of the stated number of new memory components from Texas Instruments, handled appropriately by MITERS and tested by TI, or for refund of the full amount of my remittance, at the option of MITERS. Components are guarranteed by Texas Instruments to meet the specs described herein. MITERS is not responsible for any other warranties either expressed or implied. Name _____________________________ Net Address(?) _____________________________ Shipping Address _____________________________ City, State _____________________________ Telephone #____________________________ Tax exemption #____________________________ Signature _____________________________ P.S. Real data sheets should be available shortly. The chip is a little slow, but is just fine for microprocessors and video displays.If your processor is a Z-80 you don't have to worry about refresh at all unless you are doing DMA, in which case you have to guarrantee certain timing constraints on your DMA channel. For comparison the next cheaper chip I was able to find was a 250ns version from NEC @ $20 in thousands. I have some and expect some more information about s-100 memory boards which use these chips. The SD Sales Board should be available at 30%off if we get a $2500 purchase. For further information stay tuned to the file ML:PGA;ERS TTY on ITS (MIT-ML) or ask me. Thanks for your interest.  Date: 3 May 1978 1906-PDT From: Kahler at SUMEX-AIM Subject: Moving to Oklahoma To: MsgGroup at ISI, Header-People at MC My family and I will be leaving California shortly after May 18, 1978 for Tulsa, Oklahoma to live with the summer heat, the winter cold, the locusts and the oil wells. I got married a year ago this month and came face-to-face all of a sudden with the housing situation here on the San Francisco Peninsula. I will be working for Honeywell in Tulsa doing software support for their Series 60, Level 68 (Multics) and Level 66 (GCOS) customers. (I don't yet have the offer letter in my hand, but I should in a few days.) This will be my first venture out into the "real world". I think it will do myself and my career a lot of good to find out what corporate people want from their computers after helping here at Stanford to meet the needs of medical AI researchers and college students taking computer-assisted instruction (CAI) courses. I am looking forward to learning about Multics first-hand. I'd like to see, after reading Elliot Organick's book and many of the technical papers, how such a secure system with a virtual memory such as Multics has can be implemented without a prohibitive amount of overhead. I'm glad it can. If any of you with Multics experience can tell me your feelings about the operating system and its user interfaces, I would greatly benefit from your comments. I haven't yet seen any literature more recent than 1971, except for a 1976 Multics Pocket Guide, Commands and Active Functions. In the human engineering category, TENEX (especially with our local SUMEX-AIM stuff in it) will be hard to beat. But since with Multics you can in theory put any teletype interface you please between you and the programs you run, maybe Multics is not at a disadvantage there. Not that any of my future customers would want terminal I/O that wasn't vanilla Multics. I will retain my network address here at SUMEX-AIM for a year or so, so it is not time yet to remove me from any mailing lists, but I expect to be much less of a contributor than before (not that I have contributed all that much), and much more a passive listener. Rich Kahler -------  Date: Wednesday, 3 May 1978 2247-EDT From: Brian Reid at CMU-10A Subject: Re: Moving to Oklahoma To: Kahler at SUMEX-AIM CC: MsgGroup at ISI, Header-People at MC Message-ID: <03May78 224737 BR10@CMU-10A> In-Reply-To: Kahler's message of 3 May 78 21:06 Please keep us posted. Go read Mark Twain's "Letters from the Earth" Then perhaps "The Grapes of Wrath". Do they have electricity in Oklahoma?  Date: Tuesday, 9 May 1978 0354-EDT To: Header-People @ mc  Date: 12 Jun 1978 1613-EDT From: Rick Gumpertz at CMU-10A Subject: The header of your last mail To: Feinler at SRI-KL (Jake Feinler) CC: Header-People @ MIT-MC Message-ID: <12Jun78 161357 RG02@CMU-10A> In-Reply-To: Jake Feinler's message of 11 Jun 78 23:26 Jake - I think the sysntax of your TO: list is illegal -- it appears to read To: [SRI-KL]nlg-sndmsg-6-78: without any terminating ";". Am I correct?? Rick  Date: 12 Jun 1978 1613-EDT From: Rick Gumpertz at CMU-10A Subject: The header of your last mail To: Feinler at SRI-KL (Jake Feinler) CC: Header-People @ MIT-MC Message-ID: <12Jun78 161357 RG02@CMU-10A> In-Reply-To: Jake Feinler's message of 11 Jun 78 23:26 Jake - I think the sysntax of your TO: list is illegal -- it appears to read To: [SRI-KL]nlg-sndmsg-6-78: without any terminating ";". Am I correct?? Rick  Date: 12 Jun 1978 1613-EDT From: Rick Gumpertz at CMU-10A Subject: The header of your last mail To: Feinler at SRI-KL (Jake Feinler) CC: Header-People @ MIT-MC Message-ID: <12Jun78 161357 RG02@CMU-10A> In-Reply-To: Jake Feinler's message of 11 Jun 78 23:26 Jake - I think the sysntax of your TO: list is illegal -- it appears to read To: [SRI-KL]nlg-sndmsg-6-78: without any terminating ";". Am I correct?? Rick  Date: 12 Jun 1978 1708-EDT From: Rick Gumpertz at CMU-10A Subject: Header-People To: KLH @ SRI-KL CC: Header-People @ MIT-MC Message-ID: <12Jun78 170817 RG02@CMU-10A> Why am I getting multiple copies of Header-People mail that I sent today?? Rick  Date: Tue, 13 Jun 78 16:52-PDT Subject: Re: text message format question From: Dcrocker at Rand-Unix To: POSTEL at Usc-Isib, Rick.Gumpertz at Cmu-10a cc: Dcrocker at Rand-Unix, postel at Usc-Isib, Header-People at Mit-Mc, cc: Pogran at Multics, Vittal at Bbnb, Henderson at Bbnd, cc: Feinler at Sri-Kl, Borden at Isd Message-ID: In-Reply-To: Your message of 13 JUN 1978 1249-PDT The requirement for the semi-colon was known when we specified it, but I agree that it would be nice to be nice to old programs if we can be so without purturbing the syntax unreasonably. This leads me to ask for opinions about the following change to the syntax in RFC 733: Page 15, Section D, definition of
, change / ([phrase] ":" #address ";") to be / ([phrase] ":" [#address ";"]) I would appreciate reactions from everyone receiving this note. If the reaction is solidly enough positive, then we can probably simply adopt it. (Note that a address consisting only of a colon would become legal.) Dave.  Date: 13 JUN 1978 1939-PDT Sender: CAINE at USC-ECL Subject: Re: text message format question From: CAINE at USC-ECL To: Dcrocker at RAND-UNIX Cc: POSTEL at USC-ISIB, Rick.Gumpertz at CMU-10A, Cc: Header-People at MIT-MC, Pogran at MULTICS, Vittal at BBNB, Cc: Henderson at BBND, Feinler at SRI-KL, Borden at ISD Message-ID: <[USC-ECL]13-JUN-78 19:39:56.CAINE> In-Reply-To: Dave, I concur with your proposed syntax change. Steve  Date: 13 JUN 1978 2246-EDT From: MOON at MIT-MC (David A. Moon) To: HEADER-PEOPLE at MIT-MC As long as Header-People seems to be active again, may I push for public condemnation of mail systems which send out headers containing user names with no host name? For example: From: JRLuser at Some-Random-Tenex (J. Random Luser) To: Moon at MIT-MC CC: JRLuser, SOLuser, Foo at 3rd-Party where JRLuser and SOLuser are users at the originating host.  Date: Wednesday, 14 Jun 1978 0020-EDT From: Brian Reid at CMU-10A Subject: Re: text message format question To: Dcrocker at Rand-Unix CC: Dcrocker at Rand-Unix, postel at Usc-Isib, Header-People at Mit-Mc, Pogran at Multics, Vittal at Bbnb, Henderson at Bbnd, Feinler at Sri-Kl, Borden at Isd, POSTEL at Usc-Isib, Rick.Gumpertz at Cmu-10a Message-ID: <14Jun78 002007 BR10@CMU-10A> In-Reply-To: I suspect that no matter what RFC733 reads, people are going to keep generating those old TENEX-style address-list TO fields anyhow, so I suspect that they ought to be legal. Though I haven't tried it, it seems that the "null address ==> optional semicolon" rule ought not to be hard to parse.  Date: Tue, 13 Jun 78 21:25-PDT From: Mike at Rand-Unix To: MOON at Mit-Mc (David A. Moon) cc: HEADER-PEOPLE at Mit-Mc Message-ID: In-Reply-To: Your message of 13 JUN 1978 2246-EDT I agree with Mr. Moon. Although a single user name without host specification can be understood to refer implicitly to the host the message came from, I would prefer that the host be explicitly spelled out. It also makes the 'reply' function in mail systems easier to implement.  Date: 13 Jun 1978 2227-PDT Sender: GEOFF at SRI-KA From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: Mike at RAND-UNIX Cc: HEADER-PEOPLE at MIT-MC Message-ID: <[SRI-KA]13-Jun-78 22:27:32.GEOFF> In-Reply-To: I disagree; I consider having the hostname there superfluous information and cluttering up the to and cc lines is non-needed crap. It seems simple to me that users without host names after them are on the host that the FROM person is. Why should we tack this on it each and every one of them again and again. ugh.  Date: 14 JUN 1978 0145-EDT From: RMS at MIT-AI (Richard M. Stallman) Subject: Recipient names without host names To: HEADER-PEOPLE at MIT-AI If my RMAIL reply command had to parse the recipients enough to find out whether they had hostnames, it would be at least twice as slow. So it just doesn't handle them, and probably never will.  From: Pogran at MIT-Multics Date: 06/14/78 1005-edt Subject: Response to Geoff's anti-clutter comment To: Geoff at SRI-KA cc: Mike at Rand-UNIX, Header-People at MIT-MC Message-ID: [MIT-Multics]1.1.BBBJHXwhFcWwPP Geoff, I take issue with your statement that "users without host names after them are on the host that the FROM person is". It is equally reasonable that one should interpret CC: JRLuser, SOLuser, Foo at 3rd-Party (to use Moon's example) to mean that all three of JRLuser, SOLuser, and Foo are located at 3rd-Party. At least, this interpretation was possible in the pre-733 days. The first mailer that came up on Multics did this, because it seemed natural to me. Of course, TENEX had already set a different, de facto standard, and bigwigs out there in Networkland complained to me that they could not use their TENEX "reply" commands, and would I please change my program to conform to (harrumph!) "standard". Ken  Date: 14 JUN 1978 1141-EDT From: JZS at CCA Subject: superfluous host names To: Geoff at SRI-KA cc: Header-People at MIT-MC In the case of a message with all local recipients which is then sent, forwarded or redistributed over the net, the inclusion of host names would clarify rather than clutter -- especially for mail-reading programs which try to sort out who is where and can't even after extraordinary effort. Oh well, it's at best an opinion from a jaundiced perspective... -------  Date: 14 Jun 1978 0752-PDT From: MRC at SU-AI (Mark Crispin) Subject: headers & clutter To: Moon at MIT-MC, Pogran at MIT-MULTICS CC: Header-People at MIT-MC I agree with Dave and Ken. Like Geoff, I can't stand gigantic mail headers, but at best, deleting the host name is only a drop in the bucket, and it does have significant problems. My feeling is that the clutter in mail headers are generated mostly by programs which use all the hairy options by default (or worse, because they can't be turned off). An example of this is getting a person-to-person message with a From, Reply-to, Sender, Message-ID, and Cc all being the mailbox name of the originator of the message! [I won't name any names, to protect the guilty] I really would like to see a public condemnation of all programs which use extended header features for no good reason except that they're there. A secondary cause of message header clutter is when a message is sent out to a large number of people (the famous DEC message comes to mind instantly!) who do not need to know who the other recepients of the message are, who probably do not want to know, and in some cases should not know! This problem seems to me to be more of a case of insufficient usage of mailing lists, BCC, and other ways to suppress the To list from coming out than a lack in the protocol; although I wonder. Maybe it would be a good idea if suppression of To-lists was discussed in some official context? The only times I have seen these features used were in formal system mailing lists (like Header-People) or in private lists (like a person's "friends" mailing list, a party invitation list, etc.), but almost never in one-shot mailings, despite the length of the recepient list and the irrelevancy to the recepient of whom else received the message. About BCC's: I recently received, as a BCC recepient, a fairly sensitive message which the recepient of the message would have been rather upset to know that I had gotten it. Two other people were on the BCC list, and all three of us saw the entire BCC list! This somehow seems morally wrong to me; it may be one thing to talk about somebody behind their back (in a positive as well as a negative sense) with another person, but doing it with a group which knows the identity of its members seems to be out-and-out conspiracy! I thought BCC's were supposed to be truly blind; if the BCC item is in the header, it is just to show the recepient why s/he got the message. Am I wedged? -- Mark -------  Date: Wed, 14 Jun 78 08:38-PDT Subject: Re: Response to Geoff's anti-clutter comment From: Greep at Rand-Unix To: Pogran at Mit-Multics cc: Geoff at Sri-Ka, Mike at Rand-Unix, Header-People at Mit-Mc Message-ID: In-Reply-To: Your message of 06/14/ [MIT-Multics]1.1.BBBJHXwhFcWwPP If tenex sends out messages without explicit hostnames in the address fields, then people sending messages from tenex should realize that different interpretations exist and another host's system may not be able to read their minds.  Date: 14 Jun 1978 1151-EDT From: Rick Gumpertz at CMU-10A Subject: Re: Recipient names without host names To: RMS at MIT-AI (Richard M. Stallman) CC: HEADER-PEOPLE at MIT-AI Message-ID: <14Jun78 115141 RG02@CMU-10A> In-Reply-To: Richard M. Stallman's message of 14 Jun 78 00:45 Although I think host names should be there whenever a message goes out on the net, I cannot buy RMS's argument about doubling the execution time. Twice epsilon, or even 5 times it, is insignificant when compared with the total cycles being expended in RMAIL, or for that matter the MIT-ITS machines as a whole. Arguments like that would have us still using only upper case, because it is faster to parse. When we argue execution time doubling, we really should take as a base not the time spent in parsing but rather the entire time spent in compiosing a reply! We might even add the time expended by some poor human processor trying to figure out why his mail didn't get through. Rick  Date: 14 Jun 1978 1157-EDT From: Rick Gumpertz at CMU-10A Subject: Re: headers & clutter To: MRC at SU-AI (Mark Crispin) CC: Header-People at MIT-MC Message-ID: <14Jun78 115728 RG02@CMU-10A> In-Reply-To: Mark Crispin's message of 14 Jun 78 09:52 It is not too hard for a mail printer to suppress the host name if it is equal to the local host name. Ours does this (I think) and it seems to be a win. Note that it is as easy as a single string comparison (or maybe a few, if one allows decimal host numbers as well). Therefore I say the host should always be there, letting the printer suppress it. Rick  Date: 14 Jun 1978 1302-EDT From: JHAVERTY at BBN-TENEXD Subject: (Response to message) To: GEOFF at SRI-KA, Mike at RAND-UNIX cc: HEADER-PEOPLE at MIT-MC, JHAVERTY In response to the message sent 13 Jun 1978 2227-PDT from Geoff@SRI-KA Consider the problems which occur when a message gets forwarded, redistributed, etc., and various places along the way add stuff to the fields involved with host names. Either you sacrifice a little space in the header to carry the info, or you add a fair amount of code everywhere to figure out when a 'naked' address has to be changed to include the implied host, preparatory to forwarding, replying, etc. Jack Haverty -------  Date: 14 Jun 1978 10:28 am (Wednesday) From: Horning at PARC-MAXC Subject: Re: text message format question To: Dcrocker at Rand-Unix cc: POSTEL at Usc-Isib, Rick.Gumpertz at Cmu-10a, postel at Usc-Isib, Header-People at Mit-Mc, Pogran at Multics, Vittal at Bbnb, Henderson at Bbnd, Feinler at Sri-Kl, Borden at Isd, LAUREL Team: Brotz at PARC-MAXC, Horning at PARC-MAXC, Kierr at PARC-MAXC, Levin at PARC-MAXC, Schroeder at PARC-MAXC, Wegbreit at PARC-MAXC, Taft at PARC-MAXC; In-Reply-To: Your message of Tue, 13 Jun 78 16:52-PDT Dave, By virtue of a programming error, Laurel (PARC's new message system) was "nice to old programs," (i.e., we didn't detect a missing semicolon). By popular demand, we removed this "feature," because people would rather be notified of header errors than have them interpreted other than they intended. I think that that the proposed relaxation of syntax is a definite retrograde step; we certainly wouldn't implement it again in Laurel. Jim H.  Date: 15 Jun 1978 1001-EDT Sender: HENDERSON at BBN-TENEXD Subject: Re: BCC From: HENDERSON at BBN-TENEXD To: MRC at SU-AI Cc: Header-People at MIT-MC Message-ID: <[BBN-TENEXD]15-Jun-78 10:01:39.HENDERSON> In-Reply-To: Your message of June 14, 1978 No, I don't think you're wedged. I think the idea was to save on computing different versions of the message for each BCC addressee. I think that this is a bad place to trade off efficiency against function. Actually I have from time to time advocated (the other days I get very unsure) that the notion of different "versions" of a message was immoral. If I get a message indicating that three other people got it I naturally assume that the other people got IDENTICAL copies (CC = "carbon copy", which implies a pretty strict copying function). BCC copies are usually made by "typing on a carbon". Either that or they are put into an envelope which indicates from whom they came, even though the message itself does not. There is nothing that prevents me sending out two messages saying the same thing to two people, with neither knowing that I have said it to the other. So BCC-style cannot be legislated against. But (on the advocating days) I feel that BCC should be removed from our mail systems, and mechanisms for preparing a number of messages with similar contents be relied upon for this function. Then at least the Message-ID's will show that the messages are in fact different, rather than versions of the same one. (In re-reading this I discover that this is not really an advocating day. Regard this, therefore, as musings.) Austin  Date: Thu, 15 Jun 78 09:31-PDT Subject: Re: BCC From: Greep at Rand-Unix To: HENDERSON at Bbn-Tenexd cc: MRC at Su-Ai, Header-People at Mit-Mc Message-ID: In-Reply-To: Your message of 15 Jun In-Reply-To: <[BBN-TENEXD]15-Jun-78 10:01:39.HENDERSON> If you consider the header to be an `envelope' and not part of the message proper, then it makes more sense to fudge things like address lists on different copies. In this case, though, a closer analogy would be the address on a letter showing through a window envelope, since the header is seen by the recipient as well as being used for delivery. There is no reason the BCC field has to show up at all, even on the BCC recipients' copies. Then all copies are the same.  Date: 15 Jun 1978 1026-PDT Sender: GEOFF at SRI-KA Subject: Re: BCC From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: Greep at RAND-UNIX Cc: HENDERSON at BBN-TENEXD, MRC at SU-AI, Cc: Header-People at MIT-MC Message-ID: <[SRI-KA]15-Jun-78 10:26:56.GEOFF> In-Reply-To: I think it is quite necessary for the BCC field to show up because this then gives the receiver of the message an `indication' of his `status' (if you will) on his seeing the message. i.e. if you got a copy of a message addressed to some group address like `To: Security-council-members:' and a copy of the message showed up in your mailbox, with BCC: Greep at RAND-Unix then you would know that is how you got the message, if the BCC field was not required, you'd right away assume you've been added to the members list and raise cain and possible embarrass the person who BCC'd you in the first place. I do agree though that people who are BCC'd should be aware of other BCC'd parties -- however, perhaps this could be an option of the particular message system to suit each persons feelings on this matter. g  Mail from OFFICE-1 rcvd at 15-Jun-78 1117-PDT Date: 15 Jun 1978 1115-PDT Sender: WMARTIN at OFFICE-1 Subject: Re: BCC From: WMARTIN at OFFICE-1 To: Geoff at SRI-KA Cc: wmartin Message-ID: <[OFFICE-1]15-Jun-78 11:15:50.WMARTIN> In-Reply-To: <[SRI-KA]15-Jun-78 10:26:56.GEOFF> Redistributed-To: Header-People at MC Redistributed-By: GEOFF Redistributed-Date: 15 Jun 1978 It is logical that a BCC: field should appear in a BCC-addressee's copy, as you said, to identify how that person got the message. However, why is BCC necessary at all? It seems more a source of problems and trouble than the minimal use it gets is worth, at least in my eyes. The simple way around the situation is not to use BCC at all; the originator of a message simply sends aa FORWARDed copy of his own file copy of the message to the BCC recipient. This is invisible to the original recipients, of course, and, if the sender wants the BCC-type receivers to know who else got a copy, he sends it to a list of addressees--otherwise he sends it to a single address at a time. This doesn't take much effort, and permits the inclusion of comments to the BCC-type addressees as a side benefit. Why have BCC at all if this fills the requirements? What could BCC do that this would not? Regards, Will Martin PS Please forward this to Header-People if you want. WM  Date: Thu, 15 Jun 78 11:39-PDT Subject: address list syntax From: Dcrocker at Rand-Unix To: Header-People at Mit-Mc Message-ID: Nothing like asking a simple question and starting a war... 1. In a previous note, I gave a group list example which did not contain a group name. I had forgotten that we agreed to require them. (To make it easier to distinguish group specs from "extended data-types, which are delimited by surrounding colons.) 2. The use of the BCC is and should be entirely up to the sender. IF the sender wants BCC recipients to know who they all are, then they should all be shown in the field; otherwise, not. Our personal preferences for its use shouldn't be imposed on others. 3. Only because nobody has mentioned it in the discussion about absent host names from address lists, I'd like to point out that that is patently illegal w/respect to 733. In addition, the degree of discussion, virtually free of consensus, that has just taken place on the topic makes it clear to me that we should not mess with the current spec. 4. Now about the optional semi-colon... The semi is needed only in order to terminate an address sublist (type = group). It seems quite silly to require the thing when that sublist is empty (i.e., when that name of the group is in the address field, but its contents are not shown. Horning (PARC) raised the only objection and that seems mostly to rest on the old use of group names to indicate a path to a file containing the address list for the group (ergo, allowing automatic inclusion of the list by functions like "reply"). Path-pointing is done in 733 completely separately, through the :Include: construct. Therefore, it seems that we can change the spec in RFC733, page 15, Section D, line 3 of
from / (phrase ":" #address ";") to be / (phrase ":" [#address ";"]) I am very tempted to suggest that the sub-
should be "1#address" thereby making the semi:colon legal ONLY when the address sub-list is specified; but I doubt it's worth the hassle. Comments? Dave.  Date: Thursday, 15 Jun 1978 1459-EDT From: Brian Reid at CMU-10A Subject: BCC fields To: Header-People at MIT-MC Message-ID: <15Jun78 145910 BR10@CMU-10A> In-Reply-To: CMU's RDMAIL does not generate a BCC field in the message at all; nobody has yet complained about this characteristic.  Date: 15 Jun 1978 1203-PDT Sender: GEOFF at SRI-KA Subject: Re: BCC From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: WMARTIN at OFFICE-1 Cc: Header-People at MC Message-ID: <[SRI-KA]15-Jun-78 12:03:00.GEOFF> In-Reply-To: <[OFFICE-1]15-Jun-78 11:15:50.WMARTIN> Your simple way around the BCC situation would be somewhat of an inconvience for me because of the way I handle my mail. I notice that you and most others who keep copies of their outgoing mail merely just CC themselves in the message itself. I do not do this because it makes the message system rescan my message file each time i send out a message which takes time -- even more time in the middle of the afternoon when the system is loaded, and 2ndly creates a garbage collection problem in my MESSAGE.TXT primary file. What I do is that for every message i send out I put a copy (HERMES FCC) into a file called SAVED.MESSAGES -- I also have my FDESTINATION in HERMES set to SAVED.MESSAGES as well, so that when i am 'done' with a message I simply MOVE it into SAVED.MESSAGES -- hence 'active' and unanswered mail remains in my primary MESSAGE.TXT file while all processed mail for the current month ends up in SAVED.MESSAGES -- then at the end of the month I archive SAVED.MESSAGES and start afresh. So for me, if I simply FORWARDed a copy of a message to someone (as you suggested for BCCing ) it would require me to quit out of my primary MESSAGE.TXT file, read in SAVED.MESSAGES, go scanning for that message, then FORWARD it off (therefore adding more header trash), and then return to my primary message file. This operation also has some sad side effects in that it makes me lose all 'recent' status on messages i was handling before in my primary message file. Also, in order for me to keep a record that I sent off this forwarded BCC I must keep an ENTIRE copy of the forwarded message around! Admittingly, BCC is only a convience to be had at COMPOSING time; however, I have been using the REDISTRIBUTE feature of HERMES to send later BCC's instead of FORWARDing them since REDISTRIBUTE then modifies the header of the message in my SAVED.MESSAGES file to indicate who i have redistributed it to, and doesn't require that an entire separate copy of the message itself exist. g  Date: 15 JUN 1978 1618-EDT From: Earl A. Killian Subject: Illegal headers To: HEADER-PEOPLE at MIT-MC During the recent flurry of Header-People messages I have received some headers I'd like to complain about. One message GEOFF redistributed to Header-People contained "Mail from OFFICE-1 rcvd at 15-Jun-78 1117-PDT" as the first line. This is, of course, illegal and caused my mail reading program to complain. I suggest OFFICE-1 change its mail system to not include such annotations in redistributed messages. Also, for quite some time some hosts have been sending headers with identical Sender: and From: lines. For example, one recent Header-People message contained both "From: HENDERSON at BBN-TENEXD" and "Sender: HENDERSON at BBN-TENEXD". Since this is strongly discouraged in RFC733 for good reason I'd like to ask that BBND correct its mailer. These small gripes really shouldn't have been sent to Header-People but I have no idea who to complain to at OFFICE-1 and BBND. Perhaps I should be able to mail to MAIL-MAINTAINERS@SOME-HOST (or some such name) to report problems with the mailer at SOME-HOST. The ITS systems do this (e.g. mail to BUG-MAIL@MIT-MC).  Date: Thursday, 15 Jun 1978 1637-EDT From: Brian Reid at CMU-10A Subject: Re: Illegal headers To: HEADER-PEOPLE at MIT-MC Message-ID: <15Jun78 163734 BR10@CMU-10A> In-Reply-To: Earl A. Killian's message of 15 Jun 78 15:18 As long as we're flogging particular mail systems, I'd like to gripe to the relevant party about the CRLF SPACE CRLF that separates header from message in a lot of Unix sites' mail systems. Will the person who maintains these things (if any such person exists) please fix? It should be, as we all know, CRLF CRLF.  Date: Thu, 15 Jun 78 14:36-PDT Subject: Re: text message format question From: Dcrocker at Rand-Unix To: Header-People at Mit-Mc cc: Postel at Usc-Isib, Feinler at Sri-Kl, Borden at Isd, cc: Brotz at Parc, Horning at Parc-Maxc, Levin at Parc-Maxc, cc: Schroeder at Parc-Maxc, Kierr at Parc, Wegbreit at Parc, cc: Taft at Parc Message-ID: Well, I think we now understand the problem and the solution: With respect to 733, if the semi-colon is made optional, then formal ambiguity can result with the nesting of several group lists. Since the idea of the semi is to delimit the end of a sub-list, it seems foolish to use/require the semi if the sub- list is emtpy. This leads now to recommending that the spec in RFC 733, page 15, section D,
definition, line 3 be changed from: / (phrase ":" #address ";") to be / (phrase ":" [1#address ";") which means that the semi is PROHIBITED if the list is empty and the semi is REQUIRED if the list is not empty. No ambiguities can result, since the first character after a colon resolves whether the sub-list is empty -- a comma or end-of-field indicates empty sublist and any other character says it is not empty and that a semi is required. Group specs nest so that a semi matches the most recent group-name colon. The problem at Parc stems from their having a user community which had a variant of MSG that used the group name as a path indicator and automatically fetched the referenced contents. Since that is handled very differently is 733, it is useful for the new Parc message system to flag the behavior (in an old message) as an error. That is, they are relying on the old behavior as being illegal in the new environment and we are trying to make it no longer illegal. Sigh. I suppose that the issue isn't really worth all of this text, but it bothered me during the initial specficiation stage since it looks silly to have "foo:;" in an address list.  Date: 15 JUN 1978 1441-PDT Sender: DCROCKER at USC-ISI Subject: Re: Illegal headers From: DCROCKER at USC-ISI To: Brian.Reid at CMU-10A Cc: HEADER-PEOPLE at MIT-MC Message-ID: <[USC-ISI]15-JUN-78 14:41:47.DCROCKER> In-Reply-To: <15Jun78 163734 BR10@CMU-10A> For one and all: there are two problems with fixing the offending Unix message program (a pseudo MSG): No one really maintains it and the effort needed to fix the behavior is remarkably non-trivial. At Rand, we keep deferring the effort in the belief that the program will shortly be superceded. We've been operating on the assumption for two years... Dave.  Date: 15 Jun 1978 1750-EDT From: Rick Gumpertz at CMU-10A Subject: Re: text message format question To: Dcrocker at Rand-Unix CC: Header-People at Mit-Mc Message-ID: <15Jun78 175025 RG02@CMU-10A> In-Reply-To: Is "XX: ,A,B;" legal?? What are the semantics of a group name without a group?? To whom should a reply be sent if the message says "Reply-to: Nice-people:" or such?? Rick  Date: Thu, 15 Jun 78 15:03-PDT Subject: Re: text message format question From: Dcrocker at Rand-Unix To: Rick Gumpertz at Cmu-10a cc: Dcrocker at Rand-Unix, Header-People at Mit-Mc Message-ID: In-Reply-To: Your message of 15 Jun <15Jun78 175025 RG02@CMU-10A> In the proposed change, "foo: , A, B;" is NOT legal. You have managed to find something that woumld require changing the basic definiton of the "#" construct so that the FIRST element of a list could NOT be empty. Seems like a terrible idea. The Reply-to example would "prevent" replying, since no valid address is shown; but that is legal now! Any idea how we can salvage my suggestion? Dave.  Date: 16 JUN 1978 0051-EDT From: RMS at MIT-AI (Richard M. Stallman) To: HEADER-PEOPLE at MIT-AI Date: 14 Jun 1978 1151-EDT From: Rick Gumpertz at CMU-10A Subject: Re: Recipient names without host names Twice epsilon, or even 5 times it, is insignificant when compared with the total cycles being expended in RMAIL, or for that matter the MIT-ITS machines as a whole. Arguments like that would have us still using only upper case, because it is faster to parse. When we argue execution time doubling, we really should take as a base not the time spent in parsing but rather the entire time spent in compiosing a reply! Arguments like this are very common, so it is important to point out why this one misses the point. It would make sense for a batch job, but mail systems are used by human beings! If a user has to wait a long time for the reply command to parse his header, it won't matter one whit to him that the CPU time used by that operation was miniscule compared to a whole day, or compared to how long it will take him to type his message, or compared to ANYTHING. He won't usually mind the time it takes him to compose the message, since he will be active then and not waiting for anything, but he will mind a much shorter period of enforced idleness. While Reply is parsing the header, the user has to twiddle his thumbs, and if he has to twiddle his thumbs too long he will decide it is unusable. It is on the borderline already, on our KA-10, and if it were twice as slow nobody would ever use it. I might as well just delete the facility as slow it down AT ALL.  Date: 16 JUN 1978 0056-EDT From: RMS at MIT-AI (Richard M. Stallman) To: HEADER-PEOPLE at MIT-AI Date: 14 Jun 1978 1151-EDT From: Rick Gumpertz at CMU-10A Subject: Re: Recipient names without host names We might even add the time expended by some poor human processor trying to figure out why his mail didn't get through. How about my own built-in header parser, which I use because Reply is slow? It has been known to be confused by recipient names without hostnames exactly like Reply. Since I can't patch myself with prefect reliability, and mail senders can, the only solution is not to generate such names.  Date: 16 Jun 1978 1028-EDT From: Rick Gumpertz at CMU-10A Subject: header parsing To: RMS at MIT-AI (Richard M. Stallman) CC: HEADER-PEOPLE at MIT-AI Message-ID: <16Jun78 102840 RG02@CMU-10A> In-Reply-To: Richard M. Stallman's message of 15 Jun 78 23:51 RMS - If your user can notice the header parsing time, even with lots of bells and whistles, my faith in you as a hacker of code extraordinaire will be shattered! Rick  Date: 16 Jun 1978 11:37 am (Friday) From: Karlton at PARC-MAXC Subject: Re: address list syntax In-reply-to: To: Dcrocker at Rand-Unix cc: Header-People at Mit-Mc It should be clear in the syntax that the trailing semi-colon is required if any more recipients are included in the list after the last member of the group. Your proposed change leaves things ambiguous. How about just saying in the semantic section that the end of string be allowed to close all open groups. PK  Date: 16 Jun 1978 1538-EDT From: Rick Gumpertz at CMU-10A Subject: Re: address list syntax To: Karlton at PARC-MAXC CC: Header-People @ MIT-MC Message-ID: <16Jun78 153810 RG02@CMU-10A> In-Reply-To: Karlton's message of 16 Jun 78 11:37 I guess I don't really like empty groups in the first place -- they should contain at least a :include: (or whatever that was) so that I can find the members if I really want them. Rick  Date: 23 Jun 1978 1558-PDT Sender: FEEDBACK at OFFICE-1 Subject: Illegal headers From: FEEDBACK at OFFICE-1 To: eak@MIT-MC Cc: FEINLER@SRI-KL, FEEDBACK, JORDAN, LIEBERMAN, header-people@MIT-MC Message-ID: <[OFFICE-1]23-Jun-78 15:58:07-PDT.FEEDBACK> In reply to your message of 15-JUN-78 1618-EDT Earl A. Killian Subject: Illegal headers Hi Earl, The header "Mail from OFFICE-1 rcvd at 15-Jun-78 1117-PDT" on messages from Office-1 or redistributed messages is generated by the host that is receiving the message, not by the originating host. I suggest that you contact someone at the host where you receive your mail, (MIT-MC?). Jeff Peters, our resident TENEX expert, believes this may be a feature on all TENEX operating systems. Regards, Pamela Allen/Feedback at Office-1  Date: 29 JUL 1978 1010-PDT Sender: DCROCKER at USC-ISI Subject: Transition From: DCROCKER at USC-ISI To: [ISI]Mailing.List;161:, To: Header-People at MIT-MC, list: Message-ID: <[USC-ISI]29-JUL-78 10:10:40.DCROCKER> I will be off the net from 1 Aug to about 25 Aug, and will be in transit from Los Angeles to the University of Delaware. Once situated in beautiful downtown Newark (De.), I'll be working on my doctorate. Tho Delaware is not (currently) on the network, I'll still have access to my mailbox and will be continuing as a consultant with Rand. Dave.  Date: 24 Aug 1978 1313-PDT Sender: WMARTIN at OFFICE-1 Subject: Change of address From: WILLIAM G. MARTIN To: MsgGroup at ISI, Header-People at MIT-MC Cc: DRXAL-HDA Message-ID: <[OFFICE-1]24-Aug-78 13:13:50.WMARTIN> Please change WMARTIN at OFFICE-1 to DRXAL-HDA at OFFICE-1. Change is eternal. Thanks, Will.  Date: 26 AUG 1978 2338-PDT Sender: STEFFERUD at USC-ISI Subject: Re: Change of address From: STEFFERUD at USC-ISI To: WMARTIN at OFFICE-1 Cc: MsgGroup, Header-People at MIT-MC, DRXAL-HDA at OFFICE-1 Message-ID: <[USC-ISI]26-AUG-78 23:38:08.STEFFERUD> In-Reply-To: <[OFFICE-1]24-Aug-78 13:13:50.WMARTIN> Hi Will - I will make the change with the next batch. I assume you will have a forwarding reflector put up at O-1. Best - Stef  Date: 19 Sep 1978 0756-PDT From: BH at SU-AI (Brian Harvey) Subject: MAIL, MLFL, dots To: Header-people at MIT-AI (Gee, I hope this mailing list still exists! This isn't actually about headers but it is about mail so I figured I'd start here.) Some of you have lately been receiving net mail about the fact that one of our users innocently tried mailing a message which included a line containing only a dot, and of course it didn't work. This has started some discussion of the relative merits of MAIL vs. MLFL. Basically it seems that although MLFL is in some abstract sense "the right thing" because it does away with all need for in-band signalling, it sometimes doesn't work, and it is alleged that some hosts sometimes even give positive acknowledgement of MLFL and then lose the message. MAIL on the other hand has a lot of problems besides the one about the dot, like the fact that normal editing functions are supposed to be allowed, so if you send a control-A or a control-C or the like to a TENEX as part of the text all is lost. It seems to me that it would be a lot of work for everyone to fix up MLFL and start using it in mail programs. That's why it hasn't been done all these years. So what I'd like to know is how hard it would be to create a new protocol command called XMAI or something which would be just like MAIL except that NVT editing functions would be disabled during it, and possibly some rule like "a line starting dot space should have the space ignored" to allow a line containing only a dot to be transmitted that way. (I choose dot space rather than, say, dot dot because then if some host doesn't actually strip off the space it won't generally look too bad.) Would this be an easy thing for everybody to implement? Is there a TENEX mail wizard in the house?  Date: 19 Sep 1978 1204-EDT From: Rick Gumpertz at CMU-10A Subject: Re: MAIL, MLFL, dots To: BH at SU-AI (Brian Harvey) CC: Header-people at MIT-AI Message-ID: <19Sep78 120414 RG02@CMU-10A> In-Reply-To: Brian Harvey's message of 19 Sep 78 09:56 What the hell is so hard about everyone supporting MLFL? That seems far easier than adding yet another new protocol! Rick  Date: 19 SEP 1978 1116-PDT Sender: GEOFF at USC-ISI Subject: Re: MAIL, MLFL, dots From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: BH at SU-AI Cc: Header-people at MIT-AI Message-ID: <[USC-ISI]19-SEP-78 11:16:25.GEOFF> In-Reply-To: Your message of SEPTEMBER 19, 1978 I think that creating XMAI is a bad idea, and is a half solution to the problems with MAIL and MLFL. I do not know of any hosts that take MLFL and then lose the message, can do document this for anyone host? I don't think it would be all that demanding of each sites MAIL wizard to implement MLFL in their mail sending programs, and also MLFL in their FTPSRVr. Actually, the last time i checked around the net the only site I can rember that didn't support MLFL was RAND-RCC (370/158 MVS), but even though they don't support it I don't see why you can't have your mail sending programs sense this and then re-try to send the message via regular MAIL. Tis is currently what the BBN MAILER program does, first try MLFL if it fails, then use MAIL. Lastly, if the MAILER program endsup using MAIL to transmit the message, why not just have it look at the text as it passes it thru to the foreign host for a line imbedded with just a "." on it and then patch it onthe fly to "."?  Date: 09/19/78 1507-EDT From: HAINES at LL Subject: XMAIl To: Header-people at MIT-AI I agree with Brian and Geoff that XMAI is a bad idea. Something we do NOT need is yet another way to send mail. Geoff's remarks about using MLFL when possible and (in MAIL) appending a blank to a line consisting of only a dot are good. Concerning MLFL: I fixed our FTP server to support MLFL over a year ago in response to a case where CMU couldn't get mail throught to us. To the best of my knowledge, it has never been used since. In particular, all the Header_People mail, the 'Usual Notice's, etc. use MAIL. What was that remark about 'normal editing allowed'? I am not aware that the FTP server should support any editing, let alone exotic handling of control characters. Ted Haines -------  Date: 19 Sep 1978 1526-EDT From: PDL at MIT-DMS (P. David Lebling) To: Header-people at MIT-AI Subject: MLFL Discussion -- Further Data Message-id: <[MIT-DMS].86646> What follows is a table of results of trying MLFL on every host listed as a Server in the ITS/SAIL host table. The data may be some- what out of date (this was compiled in November, 1977), both as to the hosts surveyed and the results. However, Header-People might find it interesting. The survey was taken by trying to find a legal addressee on each Server and doing a MLFL to him/her. On those for whom I had no such addressee, I just did "MLFL *******", with varying degrees of success. I'm not sure what the official FTP protocol says about asking for a LOGIN on MLFL, but since my survey program didn't do it, sites that asked for that are listed as "losers". Winners: Either MLFL worked or was correctly reported as not being implemented. 1) Transfer complete and acknowledged: 29 hosts. 1 == UCLA-ATS 86 == USC-ISI 5 == BBN-TENEXE 101 == DEC-MARLBORO 10 == LL 113 == BBN-TENEXD 11 == SU-AI 116 == USC-ISIE 15 == I4-TENEX 129 == UCLA-SECURITY 16 == AMES-67 134 == MIT-AI 31 == CCA-TENEX 150 == USC-ISIC 32 == PARC-MAXC 197 == BBN-TENEXA 49 == BBN-TENEXB 198 == MIT-ML 51 == SRI-KA 199 == RAND-UNIX 62 == UTEXAS 215 == USC-ECL 66 == SRI-KL 236 == MIT-MC 70 == MIT-DMS 241 == BBN-TENEX 76 == ILL-NTS 244 == USC-ISIB 78 == CMU-10A 2) Command not implemented: 4 hosts. 7 == RAND-RCC 506 COMMAND NOT IMPLEMENTED OR NOT RECOGNIZED 42 == LONDON 500 Command unrecognized 48 == AFWL 501 MLFL ******* 65 == UCLA-CCN 500 COMMAND UNRECOGNIZED Losers: 3) Hung forever at some point in dialogue: 6 hosts. 6 == MIT-MULTICS after icp in reply to "255 SOCK 13058" 18 == RADC-MULTICS after "230 Mail Server Process ready." 21 == LLL-COMP after "250 Mail transfer started." 44 == MIT-DEVMULTICS after icp in reply to "255 SOCK 4354" 56 == SUMEX-AIM after icp in reply to "255 SOCK 3276965378" 211 == NBS-UNIX after icp in reply to "255 SOCK 2060" 4) Asked for login: 5 hosts. 9 == HARV-10 504 USER command required before MLFL. 19 == NBS-10 454 Login please 110 == WHARTON 454 Login please 111 == WPAFB-AFAL 454 Login please 122 == BNL 530 NOT LOGGED IN. 5) Misc.: 4 hosts. 14 == CMU-10B 454 IMP1 Connection error - refused 46 == RUTGERS-10 "250 MLFL started." "452 Device DATA: does not exist " 142 == CMU-10D 454 IMP3 Connection error - timeout 231 == SDAC-44 "MLFL *******" "431 User name invalid" 6) ICP never succeeded: 7 hosts. 28 == ARPA-DMS 45 == MOFFETT-ARC 55 == ANL 58 == NYU 99 == LOGICON 143 == I4B-TENEX 179 == SRI-UNIX ---  Date: 19 Sep 1978 1237-PDT From: MRC at SU-AI (Mark Crispin) Subject: MAIL, MLFL, etc. To: Header-People at MIT-MC I agree with Ted, Geoff, and Rick. I don't understand why it would be that difficult to implement MLFL, yet easy to implement XMAI. Since mail is in the FTP server, supposedly a host has the capability to use data channels. I have heard accusations of some hosts losing mail with MLFL, but have never heard of definite blame being put on any one. I certainly seem to be able to send mail from Tenex (which, as Geoff describes, tries MLFL then MAIL if MLFL loses) and haven't had any problems. Suggestion: why don't people switch their USER programs to MLFL, and record any cases where MLFL alleges to work but doesn't (or an experimental MAIL, which asks the liaison at that site just to send a message back saying "yes I got your message"). If it comes through, win. If it loses, try to make sure it really lost and it isn't some human problem at that end. Once all the facts are in, perhaps something can be done to pressure the wizard at any truly losing site to fix it; or, the mail programs could have a special check for that site. [That last idea sounds too horrible to contemplate, but it's done all the time, due to quirks in different MAIL servers (*sigh*).] Something else which could be tried: I suggested long ago that MAIL should be divorced from FTP (an unhappy marriage at best). If there are still enough network wizards in the world, maybe socket nnn could be created to mean "MAIL protocol socket," and have duplexing similar to MAIL/MLFL at Tenex. One last note. My impression from reading the FTP protocols (real and imaginary, *sigh*) is that all editing capabilities belong in the USER host on FTP, and the server is under no obligation whatever to provide any. Since FTP uses old, not new, TELNET, you shouldn't have the problems with IAC editing commands. Actually, the only TELNET command which should be groked at all is old TELNET Data Mark, nicht wahr? I know that is a source of confusion for many new network wizards, who innocently write code for the published FTP, and then send damning letters across the network because they can't talk to anybody! -- mark  Date: Tuesday, 19 Sep 1978 1705-EDT From: Brian Reid at CMU-10A Subject: Re: XMAIl To: Header-people at MIT-AI CC: HAINES at LL Message-ID: <19Sep78 170512 BR10@CMU-10A> In-Reply-To: HAINES's message of 19 Sep 78 14:07 CMU maintains a table of the net sites that do and don't support MLFL. We try to use MLFL to those sites that supposedly support it. LL is in our list of sites that don't. I'll change it. There are about 35 sites that don't support MLFL. I include in this list a lot of sites that claim to support MLFL, because they won't allow MLFL without a USER, PASS, and ACCT. Bogus. Greep's mailer (Rand-Unix) is the right approach, as far as I am concerned--he tries MLFL, and if that doesn't work, he resorts to MAIL. It would be much more worthwhile if people would agree on a common set of reply codes for MAIL and MLFL, including the "no such user" message. After that's done, then we can think about exotica like lines with bare periods in them. Brian  Date: 19 SEP 1978 1423-PDT Sender: GEOFF at USC-ISI Subject: Re: XMAIl From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: HAINES at LL Cc: Header-people at MIT-AI Message-ID: <[USC-ISI]19-SEP-78 14:23:24.GEOFF> In-Reply-To: Your message of SEPTEMBER 19, 1978 Re -- your remark about "normal editing allowed". -- For sometime there have been two versions of the TENEX FTP Server program. Both authored by Bob Clements@BBN (who apparently isn't in on Header-people!), the frist version known as FTPSRV runs as one user job on TENEX logged in as SYSTEM or as a fork of SYSJOB. For each incoming FTP request, FTPSRV forks up an FTP Server process under itself to handle MAIL, FILES, etc. The flaw in this version was that all of the file system refereces made by uses had to be faked in FTPSRV since the user was really logging into a WHEEL (privilged) account which has access to everything, FTPSRV has to play like the file system and see if you were really able to do what you wanted to. About every 6 months or so, someone would find a new way to fake FTPSRV in believing that you rally had access to a file you weren't supposed to. About this time, 1.34 TENEX was up, and thus CRJOB, a way for one program to create a job with another user actualy logged in, so Clements ditched FTPSRV and wrote FTSCTL & FTPSER. What happens now, is that instead of all FTP Service functions being carried out by a single system job as sub forks there-of, FTSCTL spawns a not-logged-in FTPSER job (on an NVT) for each new user. When the user LOGGES in, FTPSER does a LOGIN just like when you login on a terminal, in fact, FTPSER runs on a terminal, hence I guess Bob Clements decided to add the regular TENEX editing and interupt characters to FTPSER (which I personally think was a mistake). One last thing to note is tht shoving characters down a TELNET connection to an FTPSER job on a TENEX is quite expensive in terms of overhead and processing, that is why I am very glad to see this discussion going on in hopes that MLFL will triumph and makes things easyer and more efficient in more ways than one. Perhaps someone will invite Bob Clements to join header-people and forward him all that has transpired since BH's message that started this round of discussions.  Date: 19 SEP 1978 1445-PDT Sender: GEOFF at USC-ISI Subject: Re: XMAIl From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: Brian.Reid at CMUA Cc: Header-people at MIT-AI, HAINES at LL Message-ID: <[USC-ISI]19-SEP-78 14:45:02.GEOFF> In-Reply-To: <19Sep78 170512 BR10@CMU-10A> I cannot understand why your MAILER needs a table of who does and doesn't support MLFL, I would think it would be much easyer to do what Greep's UNIX MAILER and BBN's TENEX MAILER do by trying MLFL first then MAIL if MLFL loses. Hence, why the list approach? I agree too that is is absolutely bogus of anyone who supports MAIL not logged in cannot support MLFL not-logged in. While we are on the subject of USER, PASS, ACCT , lists, and not-logged-in, it is equaly as cretinous for all our mail sending programs to have a special exception list (and crock/kludge code to go along with it) to support this nonsense wrt MULTICS hosts and the MLFL USER & PASS hack. Yuk!  Date: Tue, 19 Sep 78 14:49-PDT Subject: Re: XMAIl From: Greep at Rand-Unix To: Brian Reid at Cmu-10a cc: Header-people at Mit-Ai, HAINES at Ll Message-ID: In-Reply-To: Your message of Tuesday, 19 Sep 1978 1705-EDT In-Reply-To: <19Sep78 170512 BR10@CMU-10A> I should mention that the version of the mailer you mentioned, the one that tries MLFL first, is not actually installed yet, partly because of my recent relocation from Rand to Stanford. Another reason is that, embarassingly enough, MLFL did not always work to our own host! This was caused by an NCP bug which I fixed but which may still be present on other Unix systems.  Date: 19 SEP 1978 1751-EDT From: Earl A. Killian To: HEADER-PEOPLE at MIT-MC Perhaps we should all go de-implement the MAIL command in our FTP servers; making MLFL the only way to send mail.  From: Mike at Rand-Unix Date: 19 Sep 1978 at 1600-PDT To: Geoff at SRI-KA (Geoffrey S. Goodfellow) cc: Header-people at MIT-AI, HAINES at LL, Brian.Reid at CMUA Subject: Re: XMAIl In-reply-to: Your message of 19 SEP 1978 1445-PDT <[USC-ISI]19-SEP-78 14:45:02.GEOFF> Folks, Rand-Rcc has supported MLFL command for a few months now to the best of my knowledge. So please take us off your lusers lists in your various ftp's.  Date: 19 Sep 1978 1752-PDT From: BH at SU-AI (Brian Harvey) Subject: boy I really started something To: Header-people at MIT-MC I agree with everyone who has said that my XMAI idea is a crock. I knew all along it was a crock, but I suggested it because people have known for years now that MLFL was the right thing and nobody does it. I figured there were two possible reasons for that: (1) MLFL is harder since it involves an extra net connection and negotiations about sockets and such, and (2) it was alleged to me that it often didn't work, even sometimes when it was supposed to. I have no relevant first-hand information on that score. As to telnet editing, I am at home right now and don't have all the documents with me, but I have a distinct recollection of having read that the MAIL command in FTP was intended to be usable from someone at a TIP without having to log in first at some other host, so that the server was supposed to provide editing capability as for a telnet connection. I am forcefully reminded of this problem every time I RETR a file from an ITS system and try to mail it to a TENEX, because control-C is the ITS end of file character and sometimes shows up at the ends of the files they send, and TENEX aborts the entire operation when it sees one! (At least the tenices I talk to do that.) Since people seem to think that MLFL is more widely supported than I thought, I'll try it in our mailer; I just wanted to suggest something that everybody could get on the air quickly if MLFL wasn't going to solve the problem without a lot of work.  Date: 19 SEP 1978 1926-PDT Sender: DCROCKER at USC-ISI Subject: Addition to distribution lists From: DCROCKER at USC-ISI To: Header-People at MIT-MC, MsgGroup Cc: Szurko at RAND-UNIX Message-ID: <[USC-ISI]19-SEP-78 19:26:37.DCROCKER> Please add Szurko at Rand-Unix to the lists. Ed Szurko is the U of Delaware Electrical Engineering Department's Unix system honcho, and is just getting involved in network mail distribution. Thanks. Dave.  Date: 19 SEP 1978 2247-EDT From: Earl A. Killian To: HEADER-PEOPLE at MIT-MC By the way, I asked a Multics person to look into fixing the login before mail lossage and he thinks it just might get done this time (Honeywell has gotten complaints from RADC about some mail not getting through so...).  Date: 20 SEP 1978 1006-EDT From: KLH at MIT-AI (Ken Harrenstien) Subject: RCC, MLFL/MAIL, etc. To: geoff at SRI-KA, header-people at MIT-MC CC: Clements at BBN-TENEXA If my memory serves me correctly, I did ask Bob Clements if he'd like to join the header-people group, but he decided against it owing to enormous time pressures working with DEC on 20X development. Perhaps things now are more relaxed; he's certainly welcome. By the way, technically this mailing list is for fighting about header formats and I'm not sure how many people are really interested in working on straightening out things like FTP reply codes, which certainly need it. For the time being it doesn't matter; if several people announce that they are annoyed with "junk" mail re FTP, or that the size of the list intimidates them from talking about it, then we can just set up a "FTP-PEOPLE" group. It would be interesting if PDL could fire up another survey to get a snapshot of the MLFL picture nowadays. Anyway, as far as efficiency goes, MAIL is much better than MLFL for the ITS servers, as it avoids the overhead and real-time lag of negotiating and opening the data connection, which can be a drag with many small messages. The difference in transmission speed once things are set up is negligible, and chars are passed directly with no funny editing etc (I always considered the TNX PTY'ing kludge a big loss), and only about 2 people a year notice anything funny owing to the substitution of "crlf,crlf" for "crlf.crlf". If one really wanted to be efficient (and not just try to pass over a pristine stream of bytes) using XRSQ/XRCP (RFC 743) would save an amazing amount of time.  From: Pogran at MIT-Multics Date: 09/20/78 1039-edt Subject: MAIL & MLFL, etc. To: Header-People at MIT-AI Message-ID: [MIT-Multics]1.1.BBBJHjgGkHwxgl [I feel like I'm commenting as an "outsider" now, since I haven't had a thing to do with Multics software for nearly a year, but here goes ...] The Multics mailer has never maintained an exception list, and as far as I know, is capable of mailing to every ARPANET host that supports MLFL and/or MAIL in some way. It's more or less a "try this; if the response is unsatisfactory, try that" type of algorithm, where "this" and "that" are most commonly MLFL and MAIL, but with subsidiary decision points for trying USER and PASS, backing out of a MLFL when the server asks for a login after the SOCK reply, etc. If anybody really needs it, I'll try to write up the algorithm. And a comment on Honeywell eliminating Multics' need for USER/PASS: Once upon a time there was NO WAY to do mail-receiving on Multics without it; a year or so ago it was made possible in principle. If Honeywell, the maintainers of Multics ARPANET software these days, can put the manpower into it, it can be made to happen in fact. Let's hope they decide to do it! Ken  From: Kiessig at Rand-Unix Date: 20 Sep 1978 at 1121-PDT Message-Id: <[Rand-Unix]20-Sep-78 11:21:58.kiessig> To: KLH at MIT-AI Cc: Header-People at MIT-MC Subject: Re: RCC, MLFL/MAIL, etc. In-reply-to: Your message of 20 SEP 1978 1006-EDT. I for one think that an FTP-PEOPLE mailing list would be a good idea. Seems there's enough problems with FTP to make another list worth while.  Date: 21 Sep 1978 1824-EDT From: PDL at MIT-DMS (P. David Lebling) To: Header-people at MIT-AI Subject: New MLFL Survey (A Long Message) Message-id: <[MIT-DMS].86941> Here are the results of the MLFL Survey I ran September 20 and 21. As before, sites listed as SERVERs by the ITS host table were surveyed. Where I had the name of a real mailbox at a site (a Header-person, for example) I used that, otherwise the name "**". Once I got a "response" that seemed final I stopped surveying that site. If a site asked for a password after the MLFL command I gave "USER NETML" "PASS NETML" and retried the MLFL. Sites are grouped by the general result I got. Complete FTP scripts may be found, if you are interested, on MIT-DMS, file PDL;MLFL >. -site- -last ftp reply if lost- -when- 1) Sites that lost for various reasons: BNL 530 NOT LOGGED IN. after MLFL CMU-10A 454 IMP4 Connection error - timeout after SOCK CMU-10B 454 IMP2 Connection error - timeout after SOCK CMU-10D 454 IMP3 Connection error - timeout after SOCK HARV-10 431 INVALID ENTRY - Try again after USER LLL-MFE 454 Login please after SOCK LONDON 000 INDRA FTP Version 2.00 ... after ICP LONDON-VDH 000 INDRA FTP Version 2.00 ... after ICP NBS-10 454 Login please after SOCK WHARTON 454 DATA Connection error ... after SOCK WPAFB-AFAL 454 Login please after SOCK Note: "when" describes the last action performed by the surveyer before the indicated anomalous response. after ICP -- surveyer had done ICP to socket 3 after MLFL -- surveyer had sent MLFL command after USER -- surveyer had sent USER NETML in response to "504 Login please" after SOCK -- surveyer had attempted to connect to specified data socket 2) Sites that don't support MLFL and say so: AFWL 501 MLFL ** EGLIN 501 MLFL ** LBL 506 Command not implemented. UCLA-CCN 500 COMMAND UNRECOGNIZED WPAFB 501 MLFL ** 3) Sites that support MLFL (or at least go through all the right motions): AMES-67 LL-ASG SRI-KA BBN-TENEX MIT-AI SRI-KL BBN-TENEXA MIT-DMS SU-AI BBN-TENEXB MIT-MC SUMEX-AIM BBN-TENEXD MIT-ML UCLA-ATS BBN-TENEXE NBS-UNIX UCLA-SECURITY BBN-UNIX PARC-MAXC USC-ECL CCA-TENEX PARC-MAXC2 USC-ISI DEC-MARLBORO RADC-TOPS20 USC-ISIB I4-TENEX RAND-RCC USC-ISIC ILL-UNIX RAND-UNIX USC-ISIE LL RUTGERS UTEXAS 4) Sites that support MLFL but require "USER NETML" "PASS NETML" (Multics): MIT-DEVMULTICS MIT-MULTICS RADC-MULTICS 5) Others: a) Sites that might support it if I could mail to a real user (some of these run operating systems that are "known to work", e.g. TENEX): DCEC 450 User Unknown DTI 451 User Not Recognized LL-11 450 User Unknown LL-XN 450 User Unknown NOSC-SDL 451 User Not Recognized NTIA-ITS 451 User Not Recognized OFFICE-1 450 No such mailbox at this site RADC-XPER 451 User Not Recognized SDAC-44 431 User name invalid SDAC-UNIX 451 User Not Recognized SRI-UNIX 451 User Not Recognized b) Sites that either never responded to an ICP to socket 3, or were not accepting FTP users: ANL I4B-TENEX NOSC-CC ARPA-DMS ISI-SPEECH11 NOSC-SECURE1 CCA-SDMS LBL-UNIX NRL CCTC LLL-COMP NSWC-WO CMU-CMMP LOGICON NUSC CTO-DDS MOFFETT-ARC NWC DTNSRDC NADC NYU FNWC NCSC OFFICE-2 GUNTER-UNIX NDRE PENT-UNIX ---  Date: Thursday, 21 Sep 1978 1933-EDT From: Brian Reid at CMU-10A Subject: MLFL to CMU To: PDL at MIT-DMS (P. David Lebling) CC: Header-people at MIT-AI Message-ID: <21Sep78 193316 BR10@CMU-10A> In-Reply-To: <[MIT-DMS].86941> CMU supports MLFL. Since all 3 of our hosts gave the same error, you must have caught us at a time when the IMP was flaky.  Date: 21 Sep 1978 2009-EDT From: Rick Gumpertz at CMU-10A Subject: Re: MLFL to CMU To: Brian Reid at CMU-10A, PDL at MIT-DMS (P. David Lebling) CC: Header-people at MIT-AI Message-ID: <21Sep78 200955 RG02@CMU-10A> In-Reply-To: <21Sep78 193316 BR10@CMU-10A> It looks to me like the connection protocols are somehow getting out of step since we seem usually to show as connection timeout. Perhaps we should look into this further -- MLFL certainly works for us from CMU to CMU! Rick  ELLEN@MIT-MC 09/23/78 09:06:59 Re: Mis-directed message To: header-people at MIT-AI Begin forwarded message: ________________________________________________________________ From: Pogran at MIT-Multics Date: 09/19/78 1531-edt Subject: MAIL and MLFL discussion To: Header_People at MIT-MC Message-ID: [MIT-Multics]1.1.BBBJHjdGdMJqfc Folks: I agree 100% with Geoff's comments. The Multics mailer also uses the "first MLFL, then MAIL" rule (which means, Ted Haines, that mail sent directly from Multics to LL should use MLFL if you support it. Perhaps we can arrange a test?). In particular, I'd prefer to see, as Geoff suggests, the mailer that uses MAIL to scan for the newline-dot-newline sequence, rather than put the onus on FTP servers, in any way. Whether or not editing is allowed on the FTP TELNET control connection, used for sending MAIL, is, as far as I can tell, an open question. MAIL was originally intended SOLELY to permit "naked" TIP users to] open an FTP connection to a host and type mail (ah, the good old days!), so, mindful of this, some implementors allowed editing characters to have their normal effect over the FTP control connection. Multics tried this -- and then changed, when we discovered that mail tended to contain at-signs -- the Multics line-kill character! So an arriving messge which said: ... I'm not sure how you will feel about this, so please reply to me immediately. My mailbox is FOOBAR@ISI. George would come out: ... I'm not sure how you will feel about this, so please ISI. George Similar experiences elsewhere prompted implementors to drop the use of editing characters. The Multics net-mailing program (which either sends immediately or queues for the mailer) scans the text for newline-dot-newline and warns the user that there may be a problem. I think the consensus of the group is that Brian should bite the bullet and implement MLFL! Ken  Date: 11 Oct 1978 0636-PDT From: Klh at SRI-KL (Ken Harrenstien) Subject: "Deafnet" project! To: header-people at MC [Some of you will be receiving this message twice -- my apologies...] Greetings-- Pardon me for such a late and broadcast-style announcement, but really there are too many of you! In lieu of a reasonably personalized message, pray accept this short pointer; those curious souls wishing more information have but to ask. In brief, we at SRI International have just been awarded a contract from DHEW/OE/BEH for "Research in Telecommunications for the Deaf". The project will last 15 months, and has two primary tasks. The first is to provide a "service delivery demonstration" of a computer message system for the deaf community; the second is to conduct a survey and engineering study aimed at the design of a nationwide communications system for the deaf. Being deaf, and having a great store of experience in developing and using mail systems, I find this project peculiarly fulfilling and exciting. While keeping fingers in all the various pie-slices of the project, I'll be primarily responsible for Task 1, in which a DEC PDP-11/70 running UNIX will be installed at Gallaudet College and thereby will serve the Washington, D.C. deaf community. Managing things so that software gets modified, features added, users trained, public relations handled, etc. will be more than challenging... if my mail goes slightly unanswered over the next few months, at least you'll know why. There are many people who actually made this happen, and I can't possibly list them all even if I knew for sure who did what, but the following deserve special mention: Mario Grignetti, Dick Rubinstein, and others at BBN, for making many first steps; Chuck Jackson, Jeff Krauss, and Vint Cerf, for pushing and authoring the RFP; Plus unnamed and unknown entities within HEW/BEH, innumerable people at MIT, and SRI's Telecommunications Sciences group... In 15 months doubtless this list will be greatly expanded. Those wishing slightly more detail should read [SRI-KL] DN-INTRO.DOC which is the excerpted introduction to our original proposal (ITS types can read AI:KLH;PROP INTRO); the only change is that the proposal mentions a 11/60 which later was finalized to a 11/70. This introduction is 10 pages long; anyone who wants to tackle the entire proposal at 100 to 150 pages should contact me. --Ken -------  Date: 11 Oct 1978 0636-PDT From: Klh at SRI-KL (Ken Harrenstien) Subject: "Deafnet" project! To: header-people at MC [Some of you will be receiving this message twice -- my apologies...] Greetings-- Pardon me for such a late and broadcast-style announcement, but really there are too many of you! In lieu of a reasonably personalized message, pray accept this short pointer; those curious souls wishing more information have but to ask. In brief, we at SRI International have just been awarded a contract from DHEW/OE/BEH for "Research in Telecommunications for the Deaf". The project will last 15 months, and has two primary tasks. The first is to provide a "service delivery demonstration" of a computer message system for the deaf community; the second is to conduct a survey and engineering study aimed at the design of a nationwide communications system for the deaf. Being deaf, and having a great store of experience in developing and using mail systems, I find this project peculiarly fulfilling and exciting. While keeping fingers in all the various pie-slices of the project, I'll be primarily responsible for Task 1, in which a DEC PDP-11/70 running UNIX will be installed at Gallaudet College and thereby will serve the Washington, D.C. deaf community. Managing things so that software gets modified, features added, users trained, public relations handled, etc. will be more than challenging... if my mail goes slightly unanswered over the next few months, at least you'll know why. There are many people who actually made this happen, and I can't possibly list them all even if I knew for sure who did what, but the following deserve special mention: Mario Grignetti, Dick Rubinstein, and others at BBN, for making many first steps; Chuck Jackson, Jeff Krauss, and Vint Cerf, for pushing and authoring the RFP; Plus unnamed and unknown entities within HEW/BEH, innumerable people at MIT, and SRI's Telecommunications Sciences group... In 15 months doubtless this list will be greatly expanded. Those wishing slightly more detail should read [SRI-KL] DN-INTRO.DOC which is the excerpted introduction to our original proposal (ITS types can read AI:KLH;PROP INTRO); the only change is that the proposal mentions a 11/60 which later was finalized to a 11/70. This introduction is 10 pages long; anyone who wants to tackle the entire proposal at 100 to 150 pages should contact me. --Ken -------  Date: 11 Oct 1978 0636-PDT From: Klh at SRI-KL (Ken Harrenstien) Subject: "Deafnet" project! To: header-people at MC [Some of you will be receiving this message twice -- my apologies...] Greetings-- Pardon me for such a late and broadcast-style announcement, but really there are too many of you! In lieu of a reasonably personalized message, pray accept this short pointer; those curious souls wishing more information have but to ask. In brief, we at SRI International have just been awarded a contract from DHEW/OE/BEH for "Research in Telecommunications for the Deaf". The project will last 15 months, and has two primary tasks. The first is to provide a "service delivery demonstration" of a computer message system for the deaf community; the second is to conduct a survey and engineering study aimed at the design of a nationwide communications system for the deaf. Being deaf, and having a great store of experience in developing and using mail systems, I find this project peculiarly fulfilling and exciting. While keeping fingers in all the various pie-slices of the project, I'll be primarily responsible for Task 1, in which a DEC PDP-11/70 running UNIX will be installed at Gallaudet College and thereby will serve the Washington, D.C. deaf community. Managing things so that software gets modified, features added, users trained, public relations handled, etc. will be more than challenging... if my mail goes slightly unanswered over the next few months, at least you'll know why. There are many people who actually made this happen, and I can't possibly list them all even if I knew for sure who did what, but the following deserve special mention: Mario Grignetti, Dick Rubinstein, and others at BBN, for making many first steps; Chuck Jackson, Jeff Krauss, and Vint Cerf, for pushing and authoring the RFP; Plus unnamed and unknown entities within HEW/BEH, innumerable people at MIT, and SRI's Telecommunications Sciences group... In 15 months doubtless this list will be greatly expanded. Those wishing slightly more detail should read [SRI-KL] DN-INTRO.DOC which is the excerpted introduction to our original proposal (ITS types can read AI:KLH;PROP INTRO); the only change is that the proposal mentions a 11/60 which later was finalized to a 11/70. This introduction is 10 pages long; anyone who wants to tackle the entire proposal at 100 to 150 pages should contact me. --Ken -------  Date: 11 Oct 1978 0636-PDT From: Klh at SRI-KL (Ken Harrenstien) Subject: "Deafnet" project! To: header-people at MC [Some of you will be receiving this message twice -- my apologies...] Greetings-- Pardon me for such a late and broadcast-style announcement, but really there are too many of you! In lieu of a reasonably personalized message, pray accept this short pointer; those curious souls wishing more information have but to ask. In brief, we at SRI International have just been awarded a contract from DHEW/OE/BEH for "Research in Telecommunications for the Deaf". The project will last 15 months, and has two primary tasks. The first is to provide a "service delivery demonstration" of a computer message system for the deaf community; the second is to conduct a survey and engineering study aimed at the design of a nationwide communications system for the deaf. Being deaf, and having a great store of experience in developing and using mail systems, I find this project peculiarly fulfilling and exciting. While keeping fingers in all the various pie-slices of the project, I'll be primarily responsible for Task 1, in which a DEC PDP-11/70 running UNIX will be installed at Gallaudet College and thereby will serve the Washington, D.C. deaf community. Managing things so that software gets modified, features added, users trained, public relations handled, etc. will be more than challenging... if my mail goes slightly unanswered over the next few months, at least you'll know why. There are many people who actually made this happen, and I can't possibly list them all even if I knew for sure who did what, but the following deserve special mention: Mario Grignetti, Dick Rubinstein, and others at BBN, for making many first steps; Chuck Jackson, Jeff Krauss, and Vint Cerf, for pushing and authoring the RFP; Plus unnamed and unknown entities within HEW/BEH, innumerable people at MIT, and SRI's Telecommunications Sciences group... In 15 months doubtless this list will be greatly expanded. Those wishing slightly more detail should read [SRI-KL] DN-INTRO.DOC which is the excerpted introduction to our original proposal (ITS types can read AI:KLH;PROP INTRO); the only change is that the proposal mentions a 11/60 which later was finalized to a 11/70. This introduction is 10 pages long; anyone who wants to tackle the entire proposal at 100 to 150 pages should contact me. --Ken -------  Date: 11 Oct 1978 1004-PDT From: Klh at SRI-KL (Ken Harrenstien) Subject: Message Multiplicity To: Header-people at MC To forestall N people telling me they received N*4 copies of that message, let me point out that MIT-MC crashed several times while in the middle of handling the distribution request, and the mailer's failsafe policy obligates it to start over again... sigh. -------  Date: 30 NOV 1978 1522-PST Sender: DCROCKER at USC-ISI Subject: Address change From: DCROCKER at USC-ISI To: header-people at MIT-MC, To: [ISI]Mailing.List;170: Message-ID: <[USC-ISI]30-NOV-78 15:22:15.DCROCKER> Effective immediately, my official arpanet address is DCrocker at Rand-Unix Dave.  Date: 7 Dec 1978 1423-PST From: Mark Crispin Subject: RFC 733 & MSG To: MsgGroup at USC-ISI, Header-People at MIT-MC Hey, guys, guess what's happened down in the San Francisco Bay? Yah, you got it, we here at SAIL send RFC 733 style headers to the world. And just guess what happens? We blow the minds of almost every mail reading program in the world! The usual one is the Tenex MSG program. About one a week I get a complaint from some poor Tenex person that my mail headers zap MSG (and what's worse, I'm not the MAIL program maintainer here!). I understand (not that I should spread evil rumors) that the author and/or maintainer of MSG is ... who is one of the authors of 733 (name deleted to protect the guilty). Hey, pardners, why don't we get our act together? Is MSG going to be fixed? Will there be a widely available substitute for it (HERMES is NOT since BBN jealously guards it from other sites)? Or should SAIL roll back to pre-RFC 733? -- Mark P.S. Am I wedged, or do I remember the purpose of 733 being to make it easier for everybody's reader to parse everybody's headers?  Date: 07 DEC 1978 1857-EST From: JZS at CCA Subject: Re: RFC 733 & MSG To: MRC at SU-AI, MsgGroup at USC-ISI, Header-People at MIT-MC In response to the message sent 7 Dec 1978 1423-PST from Mark Crispin And here in Cambridge, we've been archiving the world's Arpanet mail on the Datacomputer -- with a parser specially trained to scan RFC #733 style headers. (Rather naive, eh?) After much grief scanning past the several flavors of old Unix-style messages [from LL-ASG (since reformed), UTEXAS, Rand-Unix, etc. -- and more recently from CCTC(!)], and the internal ITS-style messages which keep leaking out all over the net, we finally gave in and are now parsing the darn things. How about a consciousness raising effort? Let's rally 'round The Standard (and fix MSG, too)! --Joanne -------  Date: 7 DEC 1978 1632-PST Sender: DCROCKER at USC-ISI Subject: Re: RFC 733 & MSG From: DCROCKER at USC-ISI To: JZS at CCA Cc: header-people at MIT-MC, msggroup Message-ID: <[USC-ISI] 7-DEC-78 16:32:25.DCROCKER> In-Reply-To: Your message of DECEMBER 7, 1978 The issue is not one of consciousness-raising, per se, but of convincing the people with money that they should pay for the system modifications. good luck. Dave.  Date: 7 DEC 1978 1724-PST Sender: GEOFF at USC-ISI Subject: Re: RFC 733 & MSG From: the tty of Geoffrey S. Goodfellow To: MRC at SU-AI Cc: MsgGroup, Header-People at MIT-MC Message-ID: <[USC-ISI] 7-DEC-78 17:24:44.GEOFF> In-Reply-To: Your message of DECEMBER 7, 1978 as far as i am aware MSG and MM (TOPS-20 Mail Munger by MMcM) and HG can't handle the new style headers, in fact, as far as i am aware, HERMES is the ONLY(!) program available on TENEX or TOPS-20 which can parse the RFC733 style headers. maybe if someone approached the author of MSG and offered to make MSG win with 733 he might release the sources, but last i heard the author had no time to work on it (or funding i imagine)...  Date: 7 DEC 1978 1716-PST From: POSTEL at USC-ISIB Subject: re: standards To: DCrocker at ISIA cc: Header-People at MIT-MC, msggroup at ISIA Dave: who was it paid you to produce the standard? --jon. -------  Date: 7 DEC 1978 1732-PST Sender: FARBER at USC-ISI Subject: Re: RFC 733 & MSG From: FARBER at USC-ISI To: JZS at CCA Cc: MRC at SU-AI, MsgGroup, Header-People at MIT-MC Message-ID: <[USC-ISI] 7-DEC-78 17:32:42.FARBER> In-Reply-To: Your message of DECEMBER 7, 1978 Unfortunately the task of standard setting is ALWAYS easier than that of really adopting the standard by changing existing software to conform to it. In the case of programming languages the ONLY pressure that worked was that from major buyers ( like the Feds etc) to conform to the standard or not to get the business. Unfortunately our message systems are used to much to take the tack that "well if you don't conform you cannot play the game". That suggests that the only reasonable path is for major users ( with $'s) force conformity by pressure on those they buy computer time from. If some of them said conform or we will see if there is another supplier that will then it MAY work. BUT giving up and saying hell it will not happen guarantees that that will be the case. Dave  Date: 7 DEC 1978 1808-PST From: POSTEL at USC-ISIB Subject: re: standards & rfc 733 To: Geoff at SRI-KA cc: header-people at MIT-MC, msggroup at ISIA i am sure that the sources of msg can be provided to anyone who will take on the responsibility of modifying MSG to rfc 733 standards, and maintaining it thereafter. --jon. -------  Date: Thursday, 7 Dec 1978 2119-EST From: Brian Reid at CMU-10A Subject: Re: RFC 733 & MSG To: MsgGroup at USC-ISI, Header-People at MIT-MC Reply-To: MsgGroup at USC-ISI, Header-People at MIT-MC Message-ID: <07Dec78 211929 BR10@CMU-10A> In-Reply-To: Mark Crispin's message of 7 Dec 78 17:23 As I recall, one of the forces that motivated RFC733 in the first place was the rather disagreeable @i[de facto] standard of Tenex mail format. We minority sites were told "Be compatible with Tenex or you are wrong". The Tenex conventions were the product of convenience and not good design, and RFC733 was intended to be a legislated standard that would solve many of the known problems of the Tenex conventions-become-standards, with room to grow. We are now in a very amusing situation. The network has 3 to 5 TOPS-10 sites (depending on how you count), 1 360-67 (rah!), some ITS, some Multics, some Unixes, some IBM stuf, and some random and mysterious military machines who don't seem to get in on these header frays. And it has many Tenices/Twenices. 20? 30? Who knows. The interesting point is that essentially all of the minority sites -- the Tops-10 and the Waits and the Its and the Unix and the TSS people -- have implemented RFC733. The sluggards, the Tenex sites, have not. This is all quite strange in the light of the economics of software. The replication cost of software is zero. One person, somewhere in some Tenex site, has only to produce a good mail program, and everybody can use it. But nobody has, and I don't think anybody will soon. I have a lot of ideas about why this is happening, as the craft of the devoted hacker slowly dies. But as far as I'm concerned, the best way to deal with this problem is to ignore it. Let those of us who can use our ANSWER commands just smile, and continue to send out standard-format mail smug in the knowledge that it's going to barf up Tenex mail readers, until sooner or later somebody isn't going to be able to stand it any longer, and something will get done about it. Brian  Date: 07 DEC 1978 2253-EST From: JZS at CCA Subject: re: standards & rfc 733 To: Postel at USC-ISIB cc: MsgGroup at ISIA, Header-People at MIT-MC In response to the message sent 7 DEC 1978 1808-PST from POSTEL@USC-ISIB Alas for the lack of a SAILer... I think it would remove one of the impediments to updating MSG if the source were available for FTPing by anyone willing to look at it. Offering a SAIL compiler along with MSG might help too. --Joanne -------  Date: 7 DEC 1978 2248-PST From: POSTEL at USC-ISIB Subject: re: standards & RFC 733 To: Brian.Reid at CMU-10A cc: Header-People at MIT-MC, msggroup at ISIA Brian is right on. The thing to do is send things out in the standard format and when someone complains about not being able to parse it or answer it, tell him/her its his/her problem for using a dumb old NONSTANDARD program. --jon. -------  Date: 8 Dec 1978 1028-EST From: VITTAL at BBN-TENEXD Subject: MSG & RFC 733 To: MsgGroup at ISI, Header-People at MC Folks: I agree with Jon and Brian. My plans have been to fix MSG up for the last few months. I hopefully will have time toward the end of this month to make it understand the new standard and fix some other problems that have been bugging people for a long time. John -------  Date: 8 Dec 1978 1148-EST From: RICK.GUMPERTZ(N810RG02) at CMU-10A Subject: RFC 733 To: Header-People at MIT-MC Let RFC 733 not go the way of "NEW FTP", i.e. ignored and almost forgotten. Rick  Date: 8 DEC 1978 1340-EST From: EAK at MIT-MC (Earl A. Killian) Subject: Re: RFC 733 & MSG To: Geoff at SRI-KA CC: HEADER-PEOPLE at MIT-MC Since when can Hermes handle RFC733?? I've used Hermes quite a bit on BBN systems and never found in the slightest bit able to cope with RFC733 headers.  Date: 8 Dec 1978 1117-PST Sender: MCLURE at SRI-KL Subject: Re: Re: RFC 733 & MSG From: Stuart McLure Cracraft To: EAK at MIT-MC Cc: Geoff at USC-ISI, HEADER-PEOPLE at MIT-MC Message-ID: <[SRI-KL] 8-Dec-78 11:17:49.MCLURE> In-Reply-To: Your message of 8 DEC 1978 1340-EST As another Hermes user, I can vouch that it can handle 733. The only things that it can't handle are all those (BUG MUMBLE) messages from Its.  Date: 8 DEC 1978 1447-EST From: Earl A. Killian Subject: Re: RFC 733 & MSG To: McLure at SRI-KL, Geoff at USC-ISI cc: HEADER-PEOPLE at MIT-MC Sorry for speaking out without checking first. I guess it changed after I gave up on it and started using a mail reader built in EMACS. I just made some tests and found that it indeed does know how to reply to a RFC733 header: it finds the machine name inside the angle brackets and also no longer replies to the Sender: field. However the headers it generates aren't so great: Date: 8 Dec 1978 1426-EST Sender: EKILLIAN at BBN-TENEXE Subject: Testing From: EKILLIAN at BBN-TENEXE To: EAK at MC, To: EKillian Message-ID: <[BBN-TENEXE] 8-Dec-78 14:26:05.EKILLIAN> Foo. First of all it used the host name "MC" in the header, rather than the official host name "MIT-MC". This is illegal. In addition notice that it used two "To:" fields instead of one with a continuation line; this is "strongly discouraged" in RFC733. Finally it put in identical Sender: and From: lines, something "discouraged" in RFC733.  Date: Fri, 8 Dec 78 11:59-PST Subject: Re: RFC 733 & MSG From: Greep at Rand-Unix To: DCROCKER at Usc-Isi cc: header-people at Mit-Mc, msggroup at Usc-Isi Message-ID: In-Reply-To: Your message of 7 DEC In-Reply-To: <[USC-ISI] 7-DEC-78 16:32:25.DCROCKER> Whatdya mean money? Didn't you know all this stuff is done by hackers? If a few strategically located Chinese eateries (Coleen's, Louie's, etc) were to close down for a few days the hackers wouldn't have anything else to do with their time and would get all these mail fixes hacked pronto.  Date: 8 DEC 1978 1636-EST From: MOON at MIT-MC (David A. Moon) Sent-by: MOON5 at MIT-MC Subject: (BUG MUMBLE) MESSAGES FROM ITS To: McLure at SRI-KL CC: HEADER-PEOPLE at MIT-MC, GMP at MIT-MC, Geoff at USC-ISI IF THE DAMNED STANDARD PROVIDED ANOTHER WAY TO DO THIS, WE WOULD USE IT. THE ONLY WAY IT PROVIDES IS THE :ATOM: NOTATION WHICH IS NOT ACCEPTABLE FOR REASONS WHICH HAVE BEEN EXPLAINED BY KLH AND ME MANY TIMES. SINCE THE NEW MULTICS MAIL SYSTEM ALSO NEEDS A WAY TO DO THIS, AND SINCE THE 10X/20X MAJORITY IS EVIDENTLY NOT INTERESTED IN CONFORMING TO THE RFC733 STANDARD IN ANY CASE, I SUGGEST WE CREATE OUR OWN DE FACTO STANDARD. I WOULD SUGGEST THE SAME AS WHAT ITS DOES NOW, EXCEPT USING CURLY BRACKETS INSTEAD OF PARENTHESES. IT WON'T BE ANY MORE UNPARSEABLE BY HERMES AND IT WILL CEASE TO CONFLICT WITH RFC733'S USE OF PARENTHESES FOR COMMENTING. ITS WILL CONTINUE TO ACCEPT THE PARENTHESES NOTATION IN ANY CASE.  Date: 8 DEC 1978 1327-PST Sender: DCROCKER at USC-ISI Subject: re: standards From: DCROCKER at USC-ISI To: POSTEL at USC-ISIB Cc: DCrocker, Header-People at MIT-MC, msggroup Message-ID: <[USC-ISI] 8-DEC-78 13:27:30.DCROCKER> In-Reply-To: Your message of DECEMBER 7, 1978 The standard specified in RFC 733 was instigated by Steve Walker, while a Program Manager at Arpa's Information Processing Techniques Office and was theoretically under the supervision of the informal(?) advisory group on Computer-Aided Human Communication. Arpa funds paid for the effort. To keep the record straight, Unix message systems do not, yet, support that standard. The ISIA machine's Hermes also does not support the full standard. I expect the Unix situation will change. Dave.  Date: 8 DEC 1978 1324-PST Sender: GEOFF at USC-ISI Subject: Re: Re: RFC 733 & MSG From: the tty of Geoffrey S. Goodfellow To: EAK at MIT-MC Cc: Header-People at MC Message-ID: <[USC-ISI] 8-DEC-78 13:24:40.GEOFF> In-Reply-To: Your message of DECEMBER 8, 1978 version 4.1.6 seems to beable to handle them fine. perhaps it is up as NEWHERMES on your machine? I suggest you "Compose Suggestion" to ask why its not up on your machine. I griped about it a few months ago and they put it in shortly thereafter.  Date: 8 Dec 1978 1426-PST From: Brian Harvey Subject: What to do about (BUG MUMBLE) To: Header-people at MIT-MC We at SAIL have a similar problem for file recipients and solve it by quoting the string. The way I read 733 it ought to be ok to say To: "(BUG MUMBLE)" at MIT-AI and furthermore if the quoting doesn't override the commenthood of the parentheses in the standard then it ought to. We use it for distribution list files, as in To: "@S1.DIS[DIS,S1]" at SU-AI  Date: 8 DEC 1978 1732-EST From: RMS at MIT-AI (Richard M. Stallman) To: header-people at MIT-MC Another thing wrong with Date: 8 Dec 1978 1426-EST Sender: EKILLIAN at BBN-TENEXE Subject: Testing From: EKILLIAN at BBN-TENEXE To: EAK at MC, To: EKillian Message-ID: <[BBN-TENEXE] 8-Dec-78 14:26:05.EKILLIAN> Foo. is that there is no host name after Ekillian. Isn't this forbidden?  Date: 8 DEC 1978 1847-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: Why Tenex and Twenex don't handle 733 To: header-people at MIT-MC The reason is that the people in the Tenex world who are competent to do such work have come to care unbecomingly much about what their "bosses" want them to work on. They have become spineless. Elsewhere, the hackers feel competent to decide for themselves what needs to be done. When some part of the system needs fixing up, the hackers just do it. But servility to managers seems to be part of the culture that accompanies Tenex/Twenex wherever it goes. People at BBN have frequently been unwilling to fix bugs that were screwing users, because "We aren't funded to fix any bugs".  Date: 8 DEC 1978 1857-PST Sender: FARBER at USC-ISI Subject: Request for bibliographic information From: FARBER at USC-ISI To: [ISI]Mailing.List;172:, To: header-people at MIT-MC Message-ID: <[USC-ISI] 8-DEC-78 18:57:25.FARBER> Recently IFIPS TC6 has authorized the formation of a new working group WG 6.4 on Local Networks. As part of the first activity of that group, we are gathering a bibliography of pertinent literature in this area. We also expect to maintain a file of all referenced literature and to develop a mechanism for supplying copies. Now we need input into the bibliography. Please send me items by network and US mail. References to internal papers would also be very welcome. If you send copies of the papers I will put them in the file. We expect to publish the first bibliography in January 1979. Dave my address for US mail is: Prof David J. Farber University of Delaware Department of Electrical Engineering Newark, Del 19711  Date: 8 DEC 1978 2227-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: Long Live Structured Recipients To: HEADER-PEOPLE at MIT-MC I hope we don't have to go through all the arguments about structured recipients again. The "solution" of quoting the structured recipient is no solution, because quoting clearly ought to override the special meaning of the parentheses (or curly brackets) as structurers. Thus, "(BUG DDT)"@MIT-AI is NOT the same as (BUG DDT)@AI. The former is just a random (probably meaningless) mailbox. Note that things like (BUG "FOO BAR")@MIT-AI also make sense, as does (BUG "(FOO((")@MIT-AI if we ever have a program named "(FOO((" (which nothing prohibits). The reason we are not willing to adopt the standard on this issue is that it is not a mere incompatibility: our system is one level of sophistication above RFC733 and we think that the standard should advance to our level so that everyone can benefit from it. We aren't willing to take a step backwards just to be standard. We specifically do not want to find a crockish way of squeezing our winning structured recipients into the existing standard. Instead, we plan to implement what we claim the standard ought to be as a way of encouraging the rest of the world to take a step forward.  Date: 8 DEC 1978 2227-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: Long Live Structured Recipients To: HEADER-PEOPLE at MIT-MC I hope we don't have to go through all the arguments about structured recipients again. The "solution" of quoting the structured recipient is no solution, because quoting clearly ought to override the special meaning of the parentheses (or curly brackets) as structurers. Thus, "(BUG DDT)"@MIT-AI is NOT the same as (BUG DDT)@AI. The former is just a random (probably meaningless) mailbox. Note that things like (BUG "FOO BAR")@MIT-AI also make sense, as does (BUG "(FOO((")@MIT-AI if we ever have a program named "(FOO((" (which nothing prohibits). The reason we are not willing to adopt the standard on this issue is that it is not a mere incompatibility: our system is one level of sophistication above RFC733 and we think that the standard should advance to our level so that everyone can benefit from it. We aren't willing to take a step backwards just to be standard. We specifically do not want to find a crockish way of squeezing our winning structured recipients into the existing standard. Instead, we plan to implement what we claim the standard ought to be as a way of encouraging the rest of the world to take a step forward.  Date: 8 Dec 1978 2029-PST From: Mark Crispin Subject: Tenex and Tops-20 hackers To: RMS at MIT-AI CC: Header-People at MIT-MC Richard, I think it is unfair to the people who work on Tenex and Tops-20 to call them servile and/or spineless. A lot of those people share your distaste for the "real world". Many of them are there because they desire the income of the real world, but not the lossages. Working at a place like MIT is fine if you're single with no ties, but painful otherwise. Also, I doubt that anybody at BBN (or elsewhere) is explicitly forbidden to fix bugs. I suspect it is more a matter of priorities: suppose I am hired to do [a]. Now I may be involved in [b] and [c] because I have a personal interest in [b] and nobody else is qualified to work on [c]. I work on [a] because it pays my rent, lets me eat at Louis' every night, etc. I spend some time on [b] because it especially interests me. However, I totally neglect [c], not because I'm afraid to work on it, or I'm forbidden to (I might even be tacitly encouraged to), but just because it isn't worth it to me. Work on [c] is unpaid time that could be spent on [b]. If people would like to flame about this more, I'd suggest starting a new mailing list and not boring Header-People with this sort of bull. -- Mark  Date: 8 DEC 1978 2044-PST Sender: GEOFF at USC-ISI Subject: Re: Long Live Structured Recipients From: the tty of Geoffrey S. Goodfellow To: RMS at MIT-AI Cc: HEADER-PEOPLE at MIT-MC Message-ID: <[USC-ISI] 8-DEC-78 20:44:37.GEOFF> In-Reply-To: Your message of DECEMBER 8, 1978 What an incredibly boorish message that was! Let's keep LISPized lossage out of this discussion since it has no bearing and system-egotistical remarks appropriately squelched. Since you seem to disdain the pedestrian present and therefore refuse to implement "the standard" on the grounds its merely below your level, why should anyone else implement it then? If you don't like it, why don't you direct your efforts on the next version of RFC733 which corrects the deficiencies of the current standard, and will make the world a better place for us all, instead of just flaming about it, doing nothing,and not implementing it.  Date: 8 Dec 1978 2110-PST Sender: MCLURE at SRI-KL Subject: Re: Tenex and Tops-20 hackers From: Stuart McLure Cracraft To: rms at AI Cc: header-people at MC Message-ID: <[SRI-KL] 8-Dec-78 21:10:36.MCLURE> In-Reply-To: Your message of 8 Dec 1978 2029-PST Needless inflammable remarks have no place in discussions of this sort. 733 should be generally acknowledged; it is not so unreasonable as you make it out to be. i think the unreasonableness comes in LISPing mailing groups and then trying to propogandize that through hard-nosed oppressives  Date: 9 DEC 1978 0520-EST From: rms at MIT-AI (Richard M. Stallman) Sent-by: ___014 at MIT-AI Subject: Refusing to fix bugs. To: header-people at MIT-MC When I say that people at BBN refuse to fix bugs because they aren't funded to do so, I can cite a specific instance in which a person working at BBN was given such an answer. Anyone who wants details can ask for them. So much for specifics. That the general climate is also that way ought to be well known.  Date: 09 DEC 1978 0843-EST From: Joanne Sattley Subject: ITS format To: Header-People at MIT-AI My program is trying to parse its way through ITS-format mail and will index separately on as many different parts of each message as can be isolated. The line containing author/date/optional subject turns out to be easy to do once it has been found; since the order of header-lines is not important to the program, and all the others begin with a field-name followed by a colon, it picks out the author... line by finding an "@" instead of the colon. I'm looking for a reliable way to identify the beginning of the text portion of an ITS message & would appreciate learning your thoughts on this matter. --Joanne -------  Date: 9 Dec 1978 1154-EST From: RICK.GUMPERTZ(N810RG02) at CMU-10A Subject: quoting To: Header-People at MIT-MC It seems to me that there are two possible uses for quoting: 1) To make names not understood by other hosts (i.e. not understood by RFC 733) acceptable, with the proviso that the host that does understand it will do the "right" thing. 2) To literally quote the atom for all time. It seems that RMS thinks the second case is the only possibility. Personally, I see that as not very useful, but let us not argue that. Maybe RFC733 should have provided two sorts of quoting (what that discussion again?). In any case, it seems that te most reasonable compromise for practicality of getting things implemented is to use the first notation. ITS can get the second notion either by establishing their own internal quoting character such as \ (to keep the Lithpers happy) or by nesting quotes. Thus, "(BUG \MUMBLE)"@MIT-AI or "(BUG ""MUMBLE"")"@MIT-AI or maybe even "(BUG 'MUMBLE')"@MIT-AI as the EXTERNAL (i.e. ARPANET, not ITS internal) representation of a quoted MUMBLE parenthesized with BUG. For the really peverse person who wants to have a single level name with parens, """(BUG MUMBLE)"""@MIT-AI. Rick  Date: 9 DEC 1978 1206-PST Sender: DCROCKER at USC-ISI Subject: Re: Long Live Structured Recipients From: DCROCKER at USC-ISI To: RMS at MIT-AI Cc: HEADER-PEOPLE at MIT-MC Message-ID: <[USC-ISI] 9-DEC-78 12:06:08.DCROCKER> In-Reply-To: Your message of DECEMBER 8, 1978 It is incredible to me that you still do not understand the difference between what the "standard" interprets and what individual hosts interpret. The quoting convention is to overide the syntax of the standard, in case the contained text, which is presumed to be meaninfgul to the referenced host, happens to include characters which has special meaning to the standard. For example, "(Bug Mumble)" at mit-ai should cause (Mug Mumble) to be given as the arguement of the MAIL/MLFL Ftp command. (Bug "Mumble Foo") at mit-ai is likely meaningless, since everything between the parens is taken, by the standard, as a comment and therefore NOT passed in the FTP command. I believe you want "(Bug \"Mumble Foo\")" at mit-ai. dave.  Date: 9 DEC 1978 1753-EST From: RMS at MIT-AI (Richard M. Stallman) To: header-people at MIT-MC Most of the replies to my message have misunderstood our goals. We are not trying to find a way to compromise with RFC733. We could indeed use the solution suggested by DCROCKER and Gumpertz, if we thought that sort of "solution" desirable. But that would make them ugly, and what do we have to gain by that? Also, it would permit everybody else to forget about them, and never give the idea any further consideration. We don't want everyone to forget about the idea; we want everyone to adopt it. We are also unwilling to disfigure a feature we have used for years for the sake of a standard made by others who refused to consider our needs. It's not as if we didn't tell them or didn't try to help. They simply decided that we weren't important enough to them to be worth considering. And now, they quote their decision as if it were a fundamental fact that we are simply ignorant of (look at the tone of DCrocker's message). Well, we don't owe RFC733 any more consideration than it gave us (though in fact, we give it a lot more than that). We may be nothing in the eyes of the rest of the world, but to ourselves we are more important than the standard. Do not overlook the basic difference between the MIT situation and that of all the other sites that had to convert (including Tenex, which hasn't done so): everyone else had to make just cosmetic changes. They might well have been reluctant to do the work, but had no reason to be opposed to the result of the work. We don't mind doing some work, be we will not agree to make our system worse. We don't mind making some cosmetic changes ourselves, such as using curly brackets instead of parentheses, so that we have a system that other people could conceivably adopt. But we are adamant in keeping our system one which we can approve of and think of as properly designed for the goals that we have for it.  Date: 10 DEC 1978 1356-EST From: EAK at MIT-MC (Earl A. Killian) Subject: ITS format To: JZS at CCA-TENEX CC: HEADER-PEOPLE at MIT-MC Unfortunately the ITS "internal" header format was not really designed to be parsable. There is no real way to tell where the header ends and the text begins. Most of our programs stop when they find a line after the first which doesn't begin with "TO:" or "CC:" which of course loses when the user starts his text with one of those strings. Some programs determine whether a message has an ITS or net header by looking at the character after the first word; if it is an "@" then it is an ITS header. I much prefer, however, searching the first line for either "@" or ":" and seeing which is found (some people will set the from field of the message to their full name (i.e. something with spaces) which will confuse the first algorithm). Finally, do you know the syntax used to specify the "Sender:" when it is different from the "From:" in ITS headers?  Date: 10 DEC 1978 1954-PST From: POSTEL at USC-ISIB Subject: (BUG MUMBLE) To: RMS at MIT-AI cc: Header-People at MIT-MC Richard: pardon me, i seem to have forgot the details of just what winning thing it is that your mail system does when a message to "(BUG MUMBLE)" arrives and why it is that that syntax is so crucial to the operation of the feature. --jon. -------  Date: 11 DEC 1978 1831-EST From: MMCM at MIT-AI (Mike McMahon) Subject: Re: Re: RFC 733 & MSG To: McLure at SRI-KL, EAK at MIT-MC CC: Geoff at USC-ISI, HEADER-PEOPLE at MIT-MC Date: 8 Dec 1978 1117-PST Sender: MCLURE at SRI-KL From: Stuart McLure Cracraft In-Reply-To: Your message of 8 DEC 1978 1340-EST As another Hermes user, I can vouch that it can handle 733. The only things that it can't handle are all those (BUG MUMBLE) messages from Its. In fact HERMES cannot handle various quoting cases such as "@FILE.EXT[PRJ,PGM]" at SU-AI. Just as a matter of fact, MM violates 733 right now in parsing by accepting (BUG FOO) at MIT-AI as not a comment, and supplying the hostname in To fields that 10X/20X sites seem quite prone to leave out.  Date: 11 DEC 1978 1933-EST From: KLH at MIT-MC (Ken Harrenstien) Subject: What is (BUG MUMBLE) for? To: Postel at USC-ISIB CC: HEADER-PEOPLE at MIT-MC Jon asks what (BUG MUMBLE) is for. I'll explain again for the benefit of new-comers and others not up to the task of scanning Header-people archives. For many years, long before the dawn of CAHCOM or Header-people, and long long before RFC733, the ITS sites have been using the idea of "structured recipients". In brief, recipients are expressed as a LIST of elements, which may have sub-lists. The fact that the printed representation is LISP-like merely reflects a desire to accomodate the primary user population on these systems, which is accustomed to this sort of list representation; LISP itself is not involved. Each recipient has a TYPE and a NAME, and perhaps other ATTRIBUTES, in this general form: ( ... ) where each is expressed as ( ). EVERY recipient is expressed in this syntax or a degenerate form thereof. For example, the following are equivalent: Header-people@MC (Header-people @MC) (NAME Header-people (SITE MC)) It should be clear that this scheme has great flexibility and power. In current practice, we make use of the following recipient s: NAME - regular vanilla recipient NAME; send to personal mailbox BUG - NAME is a program name; send to implementors FILE - NAME is a filename; send to that file @FILE - NAME is a filename; send to recipients listed in file PGM - NAME is a program; run it with message text as argument *MSG - NAME is a bulletin-board name/site; post message there For example, what "Header-people" equivalences to is (@FILE [KSC;HEADER PEOPLE]) which is why that particular file always represents the Header-people group; if you furnished that recipient to the MC FTP server, the message would be handled in practically the same way as "Header-people". How this equivalencing is done is another subject, but it also involves structured lists of recipients and options, to a greater degree. The example (BUG MUMBLE) causes COMSAT to see if it knows who the maintainers of the MUMBLE program are; this information is kept in a public database. If there aren't any, the message is forwarded to MIT-AI, where most little-known programs are maintained, and if there are still no maintainers, the address is changed to (BUG RANDOM-PROGRAM) which is simply a vector to those people willing to accept bug messages about random programs. The point is that this behavior is special and is different from that accorded to a regular NAME-type recipient. ---------------------------------------------------------------- Anyway, that should answer the question of "what good is it". As far as the RFC733 form of representation goes, I agree with Moon and RMS that 733 was not responsive to our needs. (It should be noted that there was a fair amount of message traffic on the subject between the 733 authors and some ITS people, which was not distributed to Header-people, but nothing came of it). We made a considerable compromise in allowing "()"s to enclose comments; this was done in the expectation that a substitute would become available, but none was forthcoming. I might as well repeat some of RMS's message here: We could indeed use the solution suggested by DCROCKER and Gumpertz, if we thought that sort of "solution" desirable. But that would make them ugly, and what do we have to gain by that? Also, it would permit everybody else to forget about them, and never give the idea any further consideration. We don't want everyone to forget about the idea; we want everyone to adopt it. Those who think "ugliness" is a trivial reason probably under-estimate both the volume of ITS message traffic and the use of structured recipients in same. And it isn't necessary to force a revolution among mailers to "adopt" the idea; all that is required is some syntactical rule extensions to 733 which recognize bracket nestings. We have in fact proposed some specific extensions, but I don't suppose most people bothered to read the file describing them; this can be remedied by mailing it out.  Date: 12 Dec 1978 0918-PST From: Reid at SRI-KL Subject: FTP question To: Header-People at MIT-MC This is a straight technical question which has got me stumped. I want to FTP binary files to a Unix, setting all 8 bits of each character. I can't find any way to set that last bit, since FTP on both this 20 and CMU's 10 uses 7-bit characters when you give it BYTE 8. Any ideas? -------  From: Kiessig at Rand-Unix Date: 12 Dec 1978 at 1142-PST Message-Id: <[Rand-Unix]12-Dec-78 11:42:26.kiessig> To: Reid at SRI-KL cc: Header-People at MIT-MC Subject: Re: FTP question In-reply-to: Your message of 12 Dec 1978 0918-PST. I have had this same problem going from Unix => PDP-10/20's. There are two solutions that I have used with equal probabilities of success: 1) Send the sources of your "binary file", or the sources of the program that created this file. This can then either be recompiled or translated to a supported language. 2) Send the file as 4-bit bytes, and then reassemble these bytes on the receiving side. I'm not sure if your FTP will perform the correct operation if you specify 4-bit bytes, so you may in fact have to break the file up before you send it (someone else should know about this, right??). Transmitting "image format" between PDP-11's and 10/20's has been a problem for some time. I try to avoid it unless absolutely necessary by using 1) above. Rick  Date: 12 Dec 1978 1457-EST From: Rick Gumpertz at CMU-10A Subject: Re: FTP question To: Reid at SRI-KL Message-ID: <12Dec78 145728 RG02@CMU-10A> In-Reply-To: Reid's message of 12 Dec 78 12:18 Remailed-To: Header-People @ MIT-MC Remailed-From: Rick Gumpertz at CMU-10A Remailed-Date: 12 Dec 1978 1500-EST What modes does UNIX support?? Will it take Byte 36 Type Image?? If not, maybe would could bounce it through C.mmp -- it supports 8 bit ascii! See me for details Rick  From: Kiessig at Rand-Unix Date: 12 Dec 1978 at 1226-PST Message-Id: <[Rand-Unix]12-Dec-78 12:26:57.kiessig> To: Rick Gumpertz at CMU-10A To: Reid at SRI-KL cc: header-people at MIT-MC Subject: Re: FTP question In-reply-to: Your message of 12 Dec 1978 1457-EST. <12Dec78 145728 RG02@CMU-10A> UNIX does not support byte 36 type images (at least none that I know of do). Another way which I have transferred binary files between machines with much more success than the others I mentioned is to convert the whole file to its octal equivalent, and then ftp that file. This can then be converted back to its binary equivalent on the receiving machine with relative ease. Good luck, Rick  From: Dcrocker at Rand-Unix Date: 12 Dec 1978 at 1244-PST Message-Id: <[Rand-Unix]12-Dec-78 12:44:15.dcrocker> To: KLH at MIT-MC (Ken Harrenstien) cc: HEADER-PEOPLE at MIT-MC, Subject: Re: What is (BUG MUMBLE) for? In-reply-to: Your message of 11 DEC 1978 1933-EST Ken -- many thanks for your lengthy exposition about "structured addresses". Just to make sure I understand correctly, I take your note to say that RFC733 does NOT prevent you from transmitting the addresses but that you do not APPROVE of the proffered mechanism(s) and CHOOSE not to conform with it/them. Correct? (Please note that the above is truly intended to make a particular issue clear and is NOT intended to comment on the sagacity of your stance. That is an entirely separate discussion.) Thanks. Dave.  Date: 12 DEC 1978 1259-PST Sender: DCROCKER at USC-ISI Subject: Re: Re: RFC 733 & MSG From: DCROCKER at USC-ISI To: MMCM at MIT-AI Cc: McLure at SRI-KL, EAK at MIT-MC, Geoff, Cc: HEADER-PEOPLE at MIT-MC Message-ID: <[USC-ISI]12-DEC-78 12:59:42.DCROCKER> In-Reply-To: Your message of DECEMBER 11, 1978 (ISI) Hermes handles SOME of RFC733. It does NOT handle ALL of it. The following was a trivial test I conducted that should have succeeded. Lest you think I was being capricious, please note that it should have been handled, as per rfc733, and that its form really does occur on the net, now, with (at least) mail from CMU: Mail from USC-ISI rcvd at 12-DEC-78 1250-PST From: David Crocker at Rand-unix Subject: a test of 733 -------------------- The From: field is semantically invalid, in that Rand-Unix won't handle it properly, but Hermes doesn't know that. Nevertheless, its Reply function hiccuped on the syntax. Dave.  Date: 12 DEC 1978 1655-EST From: Joanne Sattley Subject: On beyond (BUG MUMBLE) To: DCrocker at RAND-UNIX, KLH at MIT-MC cc: Header-People at MIT-MC There are two other points of conflict between ITS-style mail and the 733 Standard Format which seem to have been overlooked: . The Standard does not provide for the unnamed ITS header line which contains the author/date/subject information; and . ITS-mail does not provide an unambiguous way of separating the message-header from the text body. I have no arguments to add to the structured recipients issue, though -- for what it's worth -- my program would be grateful for curly braces rather than parentheses. --Joanne -------  Date: 12 Dec 1978 1614-EST From: Rick Gumpertz at CMU-10A Subject: Re: FTP question To: Reid @ SRI-KL CC: header-people at MIT-MC Message-ID: <12Dec78 161409 RG02@CMU-10A> In-Reply-To: <[Rand-Unix]12-Dec-78 12:26:57.kiessig> CMU-Cmmp (Hydra) will support a funny form of image file. It assumes the PDP-10 has packed four bytes per word, with garbage in the top two bytes of each halfword. This is the /P format used by MACN11, LINK11, et. al. In any case, Hydra FTP knows how to transfer in 36 bit image mode from the PDP-10 and then throw away the padding and store it as a byte sequence. This all is used to transfer binary files compiled on the PDP-10 to be run on Hydra. It also can do the reverse (add 2 bits before each 16) for the inverse operation. Therefore, to transfer a file, one could shove it from the PDP-10 to Hydra in this funny image mode and then from Hydra to UNIX in ASCII mode, assuming UNIX allows arbitrary 8 bit data in ASCII mode. The inverse could be used for transferring in the other direction. To obtain a Hydra account, contact me. To copy the source of the funny packing/unpacking (which is in Bliss-11) contact me for that too. Aren't you sorry you asked? Rick Gumpertz  From: Kiessig at Rand-Unix Date: 12 Dec 1978 at 1532-PST Message-Id: <[Rand-Unix]12-Dec-78 15:32:35.kiessig> To: Rick Gumpertz at CMU-10A To: Reid at SRI-KL cc: header-people at MIT-MC Subject: Re: FTP question In-reply-to: Your message of 12 Dec 1978 1614-EST. <12Dec78 161409 RG02@CMU-10A> I believe most Unix installations accept 8-bit ASCII with no problems, so the scheme you suggest should work well, assuming all three machines are up and available at one time, etc.  Date: 12 DEC 1978 1941-EST From: MOON at MIT-MC (David A. Moon) Subject: On beyond (BUG MUMBLE) To: HEADER-PEOPLE at MIT-MC Now, wait a minute! There are two issues here. So-called ITS headers are an internal format which is not supposed to go out to anyone else on the network and which makes no attempt to conform to anyone else's standard. Unfortunately there is a misfeature of the way our mail system works whereby it can think it's sending from one ITS to another, and therefore uses an ITS header, but the mail ends up at a non-ITS site, causing grief to all concerned. It would have been fixed long ago except that it is difficult to fix. We certainly don't propose proseletyzing the use of these headers! ITS headers don't provide any extra feature, they are simply a compact form of header designed to avoid hassling humans with excess information. What we would like to see spread to the world in general, and be accomodated within RFC733, is ITS structured addresses. These are not headers but names for receivers of mail. Unlike ITS non-standard headers, these are not a cosmetic change but a semantic capability not otherwise present.  Date: Tuesday, 12 Dec 1978 2017-EST From: Brian Reid at CMU-10A Subject: Structured Recipients To: HEADER-PEOPLE at MIT-MC Message-ID: <12Dec78 201722 BR10@CMU-10A> In-Reply-To: David A. Moon's message of 12 Dec 78 19:41 From where I sit (which is in California this week) all of this brouhaha over structured recipients really boils down to quoting conventions. ITS people would like to be able to use XXX as a recipient name, for some binding of XXX. RFC733 says "If you want to use certain XXX values, you have to put them in quotes". But then ITS people say, "We can't guarantee that the string XXX won't contain a close-quote character and thereby screw up the quoting; we need a better quoting convention. Is this not the essence of the dispute? Are we not just fighting over the fact that some ITS addresses are hard to quote in the current RFC733 quoting convention? Or is there some deeper meaning that totally escapes me, by which there is a serious and irreversable semantic difference between putting "(BUG MUMBLE)" and (BUG MUMBLE) into one's TO list? Brian  Date: 12 DEC 1978 2200-EST From: KLH at MIT-MC (Ken Harrenstien) Subject: Clarification To: Dcrocker at RAND-UNIX CC: HEADER-PEOPLE at MIT-MC Yes, you are correct that while ITS sites are not prevented from transmitting the addresses, we don't approve of the mechanism and thus chose not to implement it. This is not quite as obstructionist as it might appear, since it derives from a belief that a better way exists and can be made a part of 733 with little perturbation. I was hoping to include the previously mentioned syntax specification here, but the only copy I can find is on paper and will require some work (I also want to make sure it synchs with 733 as published, as opposed to one of those intermediate versions). A little patience will suffice...  Date: 12 DEC 1978 2241-EST From: MMCM at MIT-AI (Mike McMahon) Subject: FTP question To: Reid at SRI-KL, Header-People at MIT-MC incanting "TYPE L" to the user FTP on SRI-KL will cause it to read and write 8-bit files correctly.  Date: 13 December 1978 0031-est From: Robert M. Frankston Subject: Requoting To: header-people at MIT-MC 1. I'd like to state that between the FTp issues and the structured address, I am impressed by the impulse response of a dormant header-people. 2. I think the basic issue is not quoting, it is one of requoting. For example, when one wants to send a letter to host A, via host B, what is the correct syntax? The problem with naive quoting is that it doesn't tell Host B whether to preserve the quoting, or remove it for the next level of interpretation. The advaantage of the nesting notation is that one only need to remove the top level nesting for local interpretation and then pass it on. Of course, both techniques, quoting to get odd characters in, and quoting for hiding atoms from interpretation are necessary but it should be realized that both functions are necessary. Thus one could say: to: {sas at arcmac} at mit-multics. Of course there is still the problem of how to express something like to: {sas at arcmac} at Frankston at mit-multics Where "Frankston at mit-multics" is the normal a3net address of my process which would then forward the mail out via the DDD network to the arcmac host. The first example is simpler since we assume tha the standard network server at mit-multics will parse {sas at arcmac} and do the forwarding itself.. In the second case, we can treat the address as a path through the network (specified backwrds} to the destination. Each processor handles the last token in deciding where the message is to go next.  From: Dcrocker at Rand-Unix Date: 13 Dec 1978 at 0759-PST Message-Id: <[Rand-Unix]13-Dec-78 07:59:57.dcrocker> To: KLH at MIT-MC (Ken Harrenstien) cc: HEADER-PEOPLE at MIT-MC, Subject: Re: Clarification In-reply-to: Your message of 12 DEC 1978 2200-EST Boy am I confused! Why is it that you cannot simply specify: sas at arcmac at mit-multics and sas at arcmac at Frankston at mit-multics ?? Dave.  Date: 13 Dec 1978 1153-EST From: Rick Gumpertz at CMU-10A Subject: Structured addresses To: Dcrocker at Rand-Unix CC: Header-People @ MIT-MC Message-ID: <13Dec78 115327 RG02@CMU-10A> In-Reply-To: <[Rand-Unix]13-Dec-78 07:59:57.dcrocker> Although it may conflict somewhat with your conception of the meaning of "at", it seems to me that ITS could use the form MUMBLE at BUG at MIT-MC as their external representation of structured names. Similarly, "[FILE NAME etc.]" at FILE at MIT-MC and so on. Of course, their mail reading programs could pretty this up internally for consumption by people, in LISP format or whatever they want. Rick  Date: 13 Dec 1978 1657-PST From: Klh at SRI-KL (Ken Harrenstien) Subject: New syntax for - s To: Header-people at MC Okay, here is some syntax to chew on. All I am going to furnish in this message is simply what a reader would have to know in order to do "Answering" correctly. Change to existing rule: Host-phrase = (phrase / balanced) host-indicator Add 2 new rules: balanced = ("[" *(btext / balanced / quoted-pair) "]") / ("{" *(btext / balanced / quoted-pair) "}") btext = * ; can fold This syntax is exactly the same as that for , with the delimiting characters changed. I wish 733 had adopted RMS's notion of "Parameterized BNF" so that comments and balanceds (and other stuff) could all share the same rules with different delimiters as parameters. As for semantics, the brackets and everything inside except the quote-next characters are retained when passing the string to the remote FTP server. You will note that this definition does not allow the use of quoted-strings within the body of the . This means that quotemarks can be included in the text, and passed to the remote site, with no special quoting. This definition also does not count <>s or ()s as necessary to balancedness. I don't see any particular reason for doing so, and in fact can think of some arguments against it. For example, filenames on both ITS and Multics make use of unbalanced ">"'s and files are a common form of structured address. I have at hand a more detailed definition which lays out the basic rules for what can be put inside a , but they may not be necessary and it seems better not to confuse matters at this stage of discussion. -------  Date: 13 DEC 1978 2109-EST From: KLH at MIT-MC (Ken Harrenstien) Subject: foo at bar at mumble at bletch To: Gumpertz at CMU-10A, Dcrocker at RAND-UNIX CC: HEADER-PEOPLE at MIT-MC You should be addressing R. Frankston, not me. I'm confused too. Forget about MUMBLE at BUG at MIT-AI. Remember our addresses are not just simply a type and a name. They are a structured form which could be called maximally general if you accept the premise that tree structure is so. I do agree that the quoting problem involves "re-quoting". Note also that the originating site of a message can theoretically always specify how its own addresses are to be quoted, by nesting things as deeply as necessary. However this is not true for messages that originate at other sites wherein the address is furnished by user typein. It seems perfectly reasonable to me to talk about standards for the FTP MAIL/MLFL commands (although probably not in as much depth as Hathaway would have liked), since there is already an implicit limitation (no CRLF allowed in the string) which 733 disregards (You can quote a CRLF in an address). Another thing some people may not realize is that the quote-next character is not allowed to quote the next character anywhere but within a comment or quoted-string, according to 733. Thus the only thing it is good for is quoting (,),", and perhaps CRLF. I think it should be more general than this. It should be clear that quoting is a big hairy problem and that the less one has to quote, the fewer snarls and tangles one will have in pushing addresses through various channels. This is one of the reasons we don't like a syntax which would force quoting of so many of our constructs, when reasonable non-quoting alternatives exist.  Date: 15 Dec 1978 1236-EST From: Rick Gumpertz at CMU-10A Subject: Re: New syntax for - s To: Klh at SRI-KL (Ken Harrenstien) CC: Header-People @ MIT-MC Message-ID: <15Dec78 123653 RG02@CMU-10A> In-Reply-To: Ken Harrenstien's message of 13 Dec 78 19:57 1) I think balanced text should only be delimited by (and count) braces. Brackets should be ignored as are <>. Make the parser as simple as possible. 2) Balanced text should be allowed anywhere an identifier is allowed rather than just in host phrases (syntactically anyway). I forget the exact 733 syntax so I am not describing this very exactly, but my intent should be clear. Why restrict things to particular contexts when they may be useful elsewhere as well? Rick  Date: 20 DEC 1978 1008-PST From: POSTEL at USC-ISIB Subject: re: rfc 733 & extensions To: Header-People at MIT-MC cc: postel i vote yes on the extensions put forward by KLH. Lets vote it in and produce a revised document. --jon. -------  Date: 20 DEC 1978 1940-PST Sender: DCROCKER at USC-ISI Subject: KLH's Proposed Changes to the RFC 733 Standard From: David H. Crocker To: Header-People at MIT-MC, To: [ISI]Mailing.List;174: Message-ID: <[USC-ISI]20-DEC-78 19:40:48.DCROCKER> KLH is proposing changes to the standard specified in RFC 733. These changes would allow the standard to more directly support features currently in use at the MIT 10's and deemed by them and others to be beneficial. A while ago, I verified that RFC 733 does not prevent the encoding of information which uses the features; rather, the mechanism for doing the encoding is deemed awkward. The encoding causes the information to be treated as a simple literal string, rather than a structured data object. It was claimed that one advantage to changing the standard was that it would make it more difficult for message system implementors to ignore the good things that one could do with the structure-encodings. If I understand the proposal correctly, two things are recommended: a) allow nesting of certain parentheses, and b) allow an additional parenthesization set (curly-brackets) within the standard. Angle- brackets now define mailbox-references, within addresses, and regular parentheses define (non-semantic) comments. The curly-brackets would define lists (or trees, since they could be nested) which could occur in place of an atom in an address. First, I hope the above is reasonably accurate, since what follows is based upon it. Second, let me slip in the comment that I think the use of structured data is generally a good idea. Third, what follows does not continue in such a supportive vain. I will first comment on the tactics of the proposal and then on its technical merits, within the current standard. The standard was defined over the course of one year and was published, in its current form, more than one year ago. Many (though of course not enough) sites have implemented parsers for the standard and some of these are being used. To incorporate the proposed change would require that these implementors go back and (again) change their message system address parsers. We are having enough difficulty in getting systems to conform to the standard even minimally; I have little hope that we would have even that much success in getting them to make further revisions. Remember that RFC733, itself, is claimed to be a revision. It attempts to re-specify the standard contained in RFC 680, with as few changes as possible, so that the message-using world can conduct business as it currently wants to while we go off and define a really good protocol/standard. That was our intent at the outset and nothing has changed since then. Some people seem not to appreciate the real-world difficulties in getting a place to allocate (and spend) the programmer-time to make a system change. Good intent on the part of a programmer is not enough, given that s/he has work to do which a) is what they are paid to do and b) takes up all/most of their time. The absence of strong motivation by the programmer is even worse, since then ONLY a directive from the boss will cause the change to happen (maybe). ("Good intention", of course, can really mean "possessiveness" and thereby can have the negative effect of prohibiting others from working on one's system.) All of this is intended to suggest that getting many tens of independently owned and operated systems to incorporate a standard is a non-trivial process and one ought to keep it as smooth as possible. (Some people wanted the standard phased in in a way that would have made it distinguishable from the old standard, expressly for the purpose of smoothness; unfortunately, it also would have added substantially to the cost of making the change, in some cases affecting other software.) There is a vast array of nifty features that we (collectively or at least individually) would like to see in message communication software. I have my set; each of you has yours; and though I would expect considerable overlap, the sets are not identical. If you look back to earlier drafts of the current standard, you will find that several features are no longer in it. Some fields are no longer defined and the list of special (reserved) characters has been shortened. In fact, curly- brackets used to be reserved. The reason the things were removed was to streamline the standard. This goes back to the basic intent of the effort. We were NOT trying to embody all -- or even all of the best -- of the good message system ideas; just enough of them to keep the real world quiet for a few years. That goal, I think, is being forgotten. Clearly, building a parser that maintains nesting of parentheses is no difficult thing. It is, however, more difficult than not maintaining the nesting. (We even require it at one point in the standard.) In this case, it seems particularly ill-advised to incur that cost for all RFC733 parsers when a) only a few are likely to use it in the near term, and b) the information embodied in the "list- isizing" can be encoded without imposing the burden on everyone. Should you think that the burden is trivial enough to be warranted, then note the confusion about "levels of quoting" that continues in our group even after TWO YEARS of discussion. From the perspective of the standard, address information occurs in two kinds of places. The first is an RFC733-oriented place and the second is everywhere else. Quoting only takes place within RFC733-oriented places. When information is put into an RFC733-oriented place, quoting is added as necessary and it is removed when translation takes place into a non- RFC733-oriented place. Translation between two RFC733-oriented places is a simple copy, with quoting preserved; no changes to the data should take place. For example, an MIT address might be "(Bug Mailer) at MIT-MC". In RFC733, this would be: "(Bug Mailer)" at MIT-MC and when it is translated, it is passed in a way that indicates that: (Bug Mailer) is a mailbox reference, and MIT-MC is a host reference For example, the FTP server should get exactly the first string and it does not need the second. Personally, I find it difficult to sustain the claim that the presence of the surrounding quotation marks is all that offensive, since we encounter them regularly in prose and most of us are fairly used to them. (For example, note how I specified the address when introducing it in the text.) However, such a quotation scheme does not support ALL character sequences and an added quoting mechanisms is provided, WITHIN QUOTED STRINGS. It was limited to that location because that is the (only) place that highly site-dependent information is SUPPOSED to occur. Only three characters need to be quoted: carriage-return and the two quotation characters. (I just discovered that the standard does not properly indicate that the single-quoting character (back-slack) itself needs to be quoted by a back-slash.) Neither is terribly popular within addresses. For example, it has been noted that the carriage return could not be supported in the Arpanet, since it terminates the ftp MAIL/MLFL command lines. (I suspect that that is not entirely true, but don't think the issue worth pursuing.) The second and third characters seem equally unlikely, but it did not seem reasonable to prohibit their use. It was claimed that the "::" construct is not adequate either. This wasn't elaborated upon, so I am not certain what objections there were. Note that this mechanism was specifically intended to provide a mechanism encoding new and experimental features. That is why, on its own, a "::" address is supposed to be ignored by those who do not understand it. The standard allows multiple address to be supplied for a single "person". This provides the necessary handle for the use of the special structure: Mailer Bugs <:list:(bug mailer) at mit-mc, "(bug mailer)" at mit-mc> The current standard says that the meaning of the list is that EACH mailbox is to receive a copy. However, ignorant sites couldn't use the first form and would therefore only send to the second, while knowledgeable sites should be able to discern that the two addresses resolve to the same mailbox and therefore they would only send one copy out. Well, enough of this. I am claiming that the timing of the proposal is wrong. The features were proposed before, analyzed, deemed meritorious for longer-term goals and rejected for the current standard. Some may feel that the proposal was "ignored" but, since I attended the relevant meetings, I am painfully certain that it received considerable attention. I am also claiming that the current standard allows encoding the information fairly easily, though admittedly, in a way which does not require/expect other sites to use it. I will end by commenting that I object to the idea of coercing others to conform to a special set of features, felt to be good by some but not in general use, without an extremely strong set of additional needs to support the coercion. It is one thing to OFFER something that you (privately) think is worthwhile; and it is quite another to IMPOSE it. The intent of RFC733 is to impose a standard. That is only reasonable in the face of a VERY strong need. The need has been demonstrated in the variety of difficulties experienced and expressed by many message system implementors. The current proposal fails to make an adequate case for ITS being imposed on everyone.  Date: 20 Dec 1978 2022-PST From: Mark Crispin Subject: KLH's proposed changes to RFC 733 To: Header-People at MIT-MC, MsgGroup at USC-ISI Yes, yes, yes, let's adopt KLH's changes. The argument that it would be an "imposition" is superfluous. RFC 733 in itself is an imposition; look at all the sites that haven't implemented it! The "real world" probably is never going to implement RFC 733. From my experience in dealing with the real world, they would consider two-year-long arguments about mail headers to be not only bullshit, but a waste of time and money. These are the sort of people who consider MSG needlessly hairy, and use it instead of the TYPE monitor command only because TYPE would type every message they've received since the year 1. And by real world I mean the REAL world. The REAL world has no representation on the Arpanet. Let's not kid ourselves; this stuff about mail headers is strictly for Arpanet hacker types like us. I doubt if anybody cares, other than perhaps being outraged at this use of taxpayer's money (think what would happen if Proxmire found out!). I have heard much of this sort of thing from several people: "Why does your [RFC 733] mail system send headers my [Tenex] mail reader can't read?" "Why is all of this cruft in the mail headers I receive"...as if it's MY fault as a hacker that this is happening. In light of all this, KLH's changes are reasonable. They seem to be of greater benefit than some of the RFC 733 options, like postal addresses and header comments, etc. They will provide a good deal of benefit to a certain group of extensive and sophisticated mail users without significantly screwing the rest of the world. So much violation of 733 goes on that is much more of a screw to others than supporting these addresses. Is the standard supposed to be a network-supported and designed standard, or a DCrocker-supported and designed standard? There doesn't seem to be much attention paid on the part of the authors of 733 for opposing viewpoints. In fact, it seems that any opposing viewpoint seems to get an immediate veto on what seems to be one person's esthetic standards. Sorry for this needlessly long message, but a scan of my incoming mail on this topic seems to indicate that this sort of thing is in vogue again. -- Mark  Date: 21 DEC 1978 0058-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: In the spirit of Fortran To: HEADER-PEOPLE at MIT-MC When RFC733 was about to come out, I tried to move for structured recipients to be included by talking with all the CAHCOM members in my vicinity. They liked the idea, but said that it was too late to include, and they would think about putting out a revised standard that included structured recipients in the not too distant future. (What was too late was when I started phoning them. Previously I had confined myself to using network mail, which is considerably worse for the task, as I found out). Now a lot of time has gone by with no such revision, and I am told that to change now would require people to change the changes they have already made, thus wasting their previous efforts. This is peculiar, because the person telling me this is the very person responsible for making things happen that way. A year ago, some CAHCOM people asked me to be patient and accompany them down the wrong road for a little while until they turned back; now, the othr CAHCOM person tells me that we have been going that way too long to turn back. This is a cheap swindle which I am not going to be moved by. DCrocker speaks of short-term vs. long-term goals. This is distinctly different from what I was told back then, though superficially similar. Perhaps he and the rest of CAHCOM were agreeing on two different things. In any case, given that he agreed that structured recipients were ultimately desirable, his belief that they ought to be delayed was a mistake, pure and simple. It is always easier to do a change along with ten other changes than to do it by itself, and this particular change was just a fraction of the changes that 733 ended up asking for. But this mistake was just an extension of an earlier wrong decision: that there should be an "interim" revision for the present, because the ultimate protocol of the future would be too far to aim for. This was based on a mistaken idea of what that ultimate should be: that it would be something very different from anything now in use in Arpanet mail - some mysterious non-ascii representation. This is the fundamental error, because text that is both human- readable and machine-readable is the ideal way for diverse systems to communicate, superior in robustness and the equal of any other scheme in flexibility. In fact, the ideal protocol would not be fundamentally different from 733. It would just involve a few extra features and escapes added in at the fringes. And the most prominent one, the one which is best known already to be useful, is our friend the structured recipient. If CAHCOM hadn't decided to put off structured recipients till the ultimate future, the ultimate future would be here today. Concerning the suggested syntax Mailing-list<:list:(bug mailer@mit-ai,"(bug mailer)"@mit-ai>, I doubt that we will adopt it in preference to just (bug mailer)@mit-ai, which is much simpler and easier to read.  Date: 21 Dec 1978 2201-EST From: SANTA at BBN-TENEXA Subject: A Very Merry Christmas To: Good little girls and boys: Near the end of 4th quarter comes a wonderful season, With long range projections and exchange without reason. But in case you've forgotten to tell Santa your dream, Or your wife and child must have just one more machine... This year Santa's prepared for the last-minute rush, With electronic mail, only buttons he'll push. His "office of the future" is equipped to the hilt, Now that TRS-80's and Qyx must be built. If your TI's at home and your children are curious, Tell them Santa's responding to those who send mail to us. From the Guttenberg Galaxy Santa sends you his best, May Christmas bring you peace, prosperity and rest. Rudolph T.R.N. Reindeer R.S.V.P. -------  Date: 6 January 1979 0058-est From: Robert M. Frankston Subject: Electronic Office of the Future/MIT Seminar To: header-people at MIT-MC The following wound up in my mailbox via the AI-Folks distribution list at BBN. Thought that some of the header people might be intersted and may have missed learning of this from other sources: Lyn: Could you please post this announcement at BBN? Thanks! Carl Electronic Office of the Future January 8-12 NE43-512A An integrated series of seminars will explore issues in the design and implementation of the "electronic office of the future." The subject is not hardware or software per se. It is the information systems used by office workers and how these systems can be observed, modeled, and transformed in a new technological environment. The activity will consist of lectures, discussions, and work sessions led by researchers from universities, industrial research laboratories, and consulting firms. Enrollment is limited. Regular attendance is preferred. Monday January 8 10:00 "Welcome and Preview" Carl Hewitt, M.I.T. 1:00 "The Office--An Interactive Highly Parallel System" Clarence Ellis, Xerox PARC 3:00 Demonstration of Prototype Systems Tuesday January 9 10:00 "Database Alerting and Corporate Memory" Howard Morgan, Wharton 1:00 "A Research Program in Office Automation" Michael Hammer and Mike Zisman, M.I.T. 3:00 "Modeling and Measuring Automated Information Systems" Gary Nutt, Xerox PARC Wednesday January 10 10:00 "Office Scheduling and the Production of Documents" Jack Buchanan, Harvard 1:00 "Behavioral Characterizations of Office Systems" Carl Hewitt, M.I.T. 3:00 Demonstration of Prototype Systems Thursday January 11 10:00 "Campus Communication Networks in the 80's" Joe Garber, Booze-Allen and Hamilton 1:00 "Future Modes of User Interaction" Panel Discussion 3:00 To be Announced Friday January 12 10:00 To be Announced 1:00 "Social Implications of the Electronic Office of the Future" Panel Discussion -------------------- End forwarded message  Date: 8 JAN 1979 1656-EST From: KLH at MIT-AI (Ken Harrenstien) Subject: News item To: Header-people at MIT-MC I thought the following message would be of interest to the header-people group in general, so am passing it on. ------------- Date: 3 Jan 1979 1147-PST From: GUERNYLUSBY at USC-ISIE Subject: mtg on message service support To: cerf at ISI, carlson at ISIA, myer at BBN, jhaverty at BBN, To: bthomas at BBN, farber at ISI, dcrocker at ISI, To: pool at BBN, cianflone at BBN, lyons at ISI, To: dcacode535 at ISI, cohen at ISIB, postel at ISIB, To: av at MIT-DMS, phw at MIT-AI, craighill at SRI-KL, To: anderson at RAND-UNIX, wactlar at CMU-10A, To: rothnie at CCA-TENEX, mills at ISIE cc: adams, adams at ISIA, russell at ISIA On 10 January 1979 we are holding a meeting at BBN in Cambridge, MA, starting at 0930, to discuss Message Service support on the ARPANET. The purpose of the meeting is to provide a basis for any standardization of efforts which may be necessary. We will take stock of the various message services currently available on the ARPANET, discuss problems which have been encountered between different message systems, review current protocols and review forthcoming developments. An agenda is given below. Each of you should be prepared to discuss current problems you are aware of and any developments which will impact future message service. AGENDA 1. Present State of Affairs o Survey of Message Systems o Current Problems o Format Protocols - RFC 560, 680, 733 o Distribution Service o Documentation 2. Future Developments in Message Technology o Multi-Media Techniques o Impact of Personal Computers o Distributed Service - NSW Project - Internetwork Addressing and Forwarding o Other 3. Impact of Changing Technology on the Message Service o Protocols o Distribution of Messages 4. Managing the Message Service 5. Supporting the Message Service LtCol Duane Adams DARPA/IPTO -------  Date: 12 January 1979 01:01 est From: Frankston.Frankston at MIT-Multics Subject: Dynamic addressing for intrnetworking To: header-people at MIT-MC Message-ID: <790112060127.242412 at MIT-Multics> Message-ID: <790112060144.214972 at MIT-Multics> I am trying to solve a very specific problem. Given a host on one network (such as the Arpanet) that is also connected to another net. How can messages be sent via this interconnected host to a user on the second net. The other hosts on the first net need not even be aware of the existance of the second net. In fact, the interconnecting host need not even be aware of the existance of the second net!!! I am not trying to add this conditions to be difficult, I have described a real situation that occurs when a nondistinguished process on the interconnecting host does the forwarding. Specifically, I may be using the interconnecting host as a mail drop and my computer would dial in once a day and exchange mail. Farber is already doing this at the University of Delaware. The primary requirement is that there be a syntax for specifying an address that has two parts, the first part corresponds to the Arpanet mailbox address that is currently in use. The second part has information to be used only by the second network. We can observe that this is identical to the two part address already used, one part is the host name that specifys where the mail is to be sent and the second part is a name fo local use withhin the next host. We can simply extend this syntax to allow what is in effect a path through the net. Thus one can specify: Frankston@Multics in the current protocol. This would be extended to : Frankston@Bobs_net@Multics. Where Bobs_net would be a mailbox on Multics that my computer can check periodically. For the LCS network, one can have: Frankston@LCS_net@MIT=MC. In this case, it would be most likely that LCS_net is a process giving immediate response. this is a minimal extension to the current syntax. The only requirement on senders is that the parse for the @ (or " at ") from the right. There are two requirements on receivers. First they need to parse for a second @ to find the mailbox name. Secondly they should insert, at the beginning of the letter a "recipient:" field that specifies the recipient name (possibly with the last @Multics or whatever stripped off) that was used for FTP so that the next network can continued to forward to the specific recipient. The drawback to this scheme is that it requires chanes to th senders and receivers. But, it can be introduced gradually. Though of course, mail with ext4e4ended addresses can only be exchanged between hosts implementing the protocol. I have not addressed all the issues of human interefacing, such as hiding long and complicated pathnames from naive users. It is a mistake to try to solve that at this level. That is the responsibility of aliasing and directory schemes. For example, I can have mail at ITS (assuming ITS implements this protocol) translated from "RMF@MIT-MC" to "Frankston@Bobs_net@Multics" so that I can still receive mail from unmodified hosts and so as not to burden a sender with a long pathname. A less frequent user of Arpanet mail might not setup an abbreviation, but would require a full pathname. That is the way itmust be since one cannot preregister all possible recipients in the world. Even less likely is the registration of all processes that might receive mail. We cannot even predict which networks will exist since a network can be created by any computer with access to the dial phone network and the ability to login to another host.  Date: 12 January 1979 01:03 est From: Frankston.Frankston at MIT-Multics Subject: via To: header-people at MIT-MC Message-ID: <790112060356.354291 at MIT-Multics> It would be a good practice for mail servers to prefix received letters with a "via:" that specifies the host from which the letter was received. This would aid in attempts to provide secure mail services. The security is relative to one's trust of the previous handler.  Date: 12 JAN 1979 0128-EST From: RMS at MIT-AI (Richard M. Stallman) To: header-people at MIT-MC I would like to second RMF's suggestion but there is no need at all to specify what any receiver should do on receiving a message address to FOO@BAR@RECEIVING-SITE. This is only meaningful in whatever ways RECEIVING-SITE thinks it is. Machines that don't connect to anything but the arpanet need not understand it at all in that context. Machines that do have other nets to forward onto can do things in a much better way than the way RMF suggests: just mail the thing off to FOO@BAR. BAR will be able to process this in the usual manner because he is told, at sending time, about FOO just as when anyone on RECEIVING-SITE mails to FOO@BAR. However, there is the problem that the From: will be MUMBLE@OTHER-SITE, which might be meaningless to BAR since they are not on any common network. This can be solved by adding "Via Gateway: RECEIVING-SITE" to the front of the message. Then FOO@BAR's automatic reply program can take the From: and add "@RECEIVING-SITE" to it. If there are several Via Gateway: fields then they must be put on first one outermost. To sum up, only mail sending systems need to be changed to implement this, except on machines that are actually gateways.  Date: 12 January 1979 01:52 est From: Frankston.Frankston at MIT-Multics Subject: More on addressing To: header-people at MIT-MC Message-ID: <790112065239.985901 at MIT-Multics> 1> in reply to RMS, a slight correction, a message to FOO@BAR@RECEIVING-SITE will be forwarded to BAR, not FOO@BAR. This is necessary since only BAR is a known name at the host, It is BAR itself that understand7s foo. 2. If we want to be even more compatable, we can use some character other than ! for the second level of pathnames. Thus one can send mail to FOO!BAR@RECEIVING-SITE. This has the advantage of not requiring modification to senders. It has the disadvantage that it does not nest well. i.e. only works for one level. For the moment, however, receivers understanding multinetting can process ! as a @ and old sites treat it as an alpha thus requiring only sites interested in the protocol need be modified but all sites will gain immediate acess to inernetting  Date: 12 January 1979 01:54 est From: Frankston.Frankston at MIT-Multics Subject: typo To: header-people at MIT-MC Message-ID: <790112065455.726813 at MIT-Multics> I mwant to say: 2. If we want to be even more compatable, we can use some character other than "@", such as "!".  From: Dcrocker at Rand-Unix Date: 11 Jan 1979 at 2308-PST Message-Id: <[Rand-Unix]11-Jan-79 23:08:17.dcrocker> To: Frankston.Frankston at MIT-Multics cc: header-people at MIT-MC Subject: Re: Dynamic addressing for intrnetworking In-reply-to: Your message of 12 Jan <790112060127.242412 at MIT-Multics> First of all, with all due modesty, I would like to correct your attribution of our current use of Inter-net mail. We, at Delaware, are entering the initial experimentation phase (read: we are working on transmitting the first message) of our "remote mailer" system. Granted, the difference between that and utility is likely to be less than a week. However, from the vantage point of my current activity, that counts as a lot to me. Minor point: Vint Cerf, at Arpa, has suggested that the term "gateway" be reserved for very low level network interfacing for such functions as packet format transformtion. The term "Mail Forwarder" though not as sexy, has been suggested for this context. Now much more to the point, I think your and Stallman's suggestions are excellent. In fact, I think they are so good, that I would like to recommend that the two of you read RFC #733, the syntactic definitions of host-phrase and host-indicator in Section III.E (page 15) and the semantic description in Section IV.A.f (pp. 19-20). I fail to see how your basic suggestion differs from what is already in the standard. Standardizing on the field-name "via:" seems quite reasonable to me. I have currently had our system adding it to a general- purpose "Source-Info" field, but like factoring out the information. About two days ago, the problem of the From field struck me. A (very) short-term seems to be to take advantage of the fact that systems are currently used to having NO hostname in the From field. A longer-term approach (still not optimal) is to have the From field reflect a back-path for the recipient. "Via gateway" requires that all receiving sites know how to use that field. In general, it seems to me that you can take a path or a location approach to addressing. The path approach should require no knowledge on the part of the recipient, to be able to formulate a reply. The location approach ("London England", rather than "dial ..." or "go to L.A. Airport and take flight xxx") requires that the recipient have some general world (inter-net) knowledge, at least to the level of knowing about mail forwarders. The "Via gateway" field would be useful in the latter case, I should think. --- Now that I have tried to make this note constructive, I would like to comment on my feelings on having spent more than a year in a group effort to produce a standard which has been repeatedly criticized by participants of the process, only to discover that they apparently have not bothered to become familiar with that standard: I bloody well do not like it, and I'm very glad that I had to type this note, rather than generate my words during an immediate reaction in a meeting. The vocabulary would have been quite different. Doesn't help your credibility much, either, guys. --- Dave.  Date: 12 JAN 1979 0211-EST From: RMS at MIT-AI (Richard M. Stallman) To: header-people at MIT-MC Ok, I see what RMF means, but again that applies only to those hosts that want to be able to accept mail for FOO@BAR@HOST with BAR being a user at HOST. I'm sure most hosts won't be interested and they will not have to be changed; and only HOST (and BAR's dialup program) have to know exactly how HOST deals with such messages. Please don't saddle us with any crock like FOO!BAR@RECEIVING-SITE. Defining FOO@BAR@RECEIVING-SITE won't screw anybody, in the sense that people who don't convert will not have any problems communicating with the hosts they now communicate with. Those hosts that want to send mail to other nets will hack this trivial hack. Those that don't care, won't.  Date: Friday, 12 Jan 1979 0300-EST From: Brian Reid at CMU-10A Subject: Re: More on addressing To: header-people at MIT-MC Message-ID: <12Jan79 030044 BR10@CMU-10A> In-Reply-To: <790112065239.985901 at MIT-Multics> Isn't this what "Foo@Bar"@Mit-MC was supposed to be for?  Date: 12 JAN 1979 0251-EST From: RMS at MIT-AI (Richard M. Stallman) To: header-people at MIT-MC DCrocker, I don't know whether you were at the meeting on Wednesday, but although I walked in thinking that FOO@BAR@BLETCH was part of the standard, nobody else there (including those who "ought" to know" seemed to think so, and the idea was so controvercial, that I and RMF walked out thinking that we had to push for it very hard.  Date: 12 JAN 1979 0607-PST Sender: FARBER at USC-ISI Subject: Re: More on addressing From: FARBER at USC-ISI To: reid at CMUA Cc: header-people at MIT-MC Message-ID: <[USC-ISI]12-JAN-79 06:07:14.FARBER> In-Reply-To: <12Jan79 030044 BR10@CMU-10A> Ah yes that is what foo@bar@mit-mc was supposed to do. The reaction to that notation by many ( including some who can control such things) is not allowed to be put in print. While its somewhat of a taste problem, it is essentailly unacceptable as far as I can tell. Note I am reporting not necessarily stateing my opinion. Dave  Date: 12 JAN 1979 1215-EST From: MOON at MIT-MC (David A. Moon) Sent-by: MOON5 at MIT-MC Subject: Transfinite flaming about internet addressing To: HEADER-PEOPLE at MIT-MC An excellent application for structured-recipient syntax.  Date: 14 January 1979 17:44 est From: Frankston.Frankston at MIT-Multics Subject: Friendly user @ hosta @ local-net1 @ major-netq To: header-people at MIT-MC Message-ID: <790114224425.907140 at MIT-Multics> My original intent at the Wednesday meeting was to ask whether the "foo at bar at nethost" syntax was valid. A simple yes by anyone present would have sufficed to answer my question and Tom Knight's request for an acceptable syntax. In any case, as Dcrocker points out, "foo at bar at nethost" is in the standard. The question now is, which mail servers can currently properly process this form of an address? And also, which mail sending programs permit it? In RFC 733, the example is "Friendly User @ hosta @ local-net1 @ major-netq". The assumption is that major-netq knows that local-net1 is a net and will thus be able to pass on the recipient name in addition to the text of the message. In order to allow local-net1 to be a nondistingushed user on major-netq it is necessary to have a mechanism such as the "recipient:" as I've proposed. I realize that there are many more issues involved, including those of taste. I am not addressing those -- they are related, but separate issues.  From: Kiessig at Rand-Unix Date: 15 Jan 1979 at 1606-PST Message-Id: <[Rand-Unix]15-Jan-79 16:06:44.kiessig> To: header-people at MIT-MC Subject: Re: Friendly user @ hosta @ local-net1 @ major-netq In-reply-to: Your message of 14 January 1979 17:44 est. <790114224425.907140 at MIT-Multics> After reading over a dozen messages on this local network recipient problem, it seems to me that you people are approaching it in the wrong way. Shouldn't the ARPAnet host be the ONLY machine which knows about "hosta @ local-net1"? The mail receiver should easily be able to determine which users' mail must be sent out over the local net(s). Hence for the above example, "Friendly user @ major-netq" should be all you need specify. "Foo at nethost" seems much more reasonable than "Foo at bar at nethost". The problem with this scheme could be in adding the "From:" field. Perhaps only the host which actually sends the mail out over the ARPA network should add in the host name. Using this method, only the machines that actually have local nets need make any changes to their software.  Date: 16 January 1979 03:58 est From: Frankston.Frankston at MIT-Multics Subject: For the doezenth time. To: kiessig at Rand-UNIX cc: header-people at MIT-MC Message-ID: <790116085811.144562 at MIT-Multics> One cannot abbreviate "For at bar at nethost" as "Foo at nethost" because "nethost" is utterly unaware of the existance of "foo". Furthermore, there may be a "Foo at bar" as well as a "Foo at Foo".. Not only that, "nethost" doesn't even know that "bar" represents a host instead of simply being another user on "nethost".  Date: Tue, 16 Jan 79 12:14-EST To: Header-People at Mit-MC From: Dcrocker at Rand-Unix Subject: RFC 733 Parsers Does anyone have code for a parser and data-manager (the thing that manipulates whatever structure you produce after the parse) that they would be willing to share? Dave.  Date: 19 Jan 1979 2059-PST From: Tovar Subject: Inter-networking To: Header-People at MIT-MC As i see things, there are two issues being addresses here: (1) how to send, and (2) how to reply. I would first like to address the issue of how to send. One suggestion, "Smith@MSR"@MIT-XYZ has two strikes against it. First, it looks ugly. Second, it does not nest well. That is, if another level of indirection is necessary, how are more quotes going to be added and if so, what hope is there for readability? Secondly, there has been some suggestion, which i do not completely understand, that at least some '@ something' can be removed from a construct like 'Friendly name @ hosta @ local-net1 @ majornetq'. In some instances, that is true, just as it is in the U.S. Postal Service, Tovar A.I. Project Stanford, CA 94305 not only works, but gets there faster than the official address of Tovar Artificial Intelligence Project Computer Science Department Stanford Universiy, Stanford CA 94305 While if i tried to do something like that at UCSB, i'm afraid there would be little hope, just as if i tried to send mail to John Smith @ IBM-Net @ CommercialNet or John Smith @ Louisville @ CommercialNet This, of course, assumes that everyone knows how to, and can legitimately send messages to, CommercialNet. There are some additional problems besides trying to get unique addresses. If you think we have trouble keeping host tables up-to-date, try adding how to get onto other networks. If you think we have trouble keeping host tables up-to-date, how about other networks that may well be more informal, or may actually change dynamically. At least until and if there comes about a widely accepted, and when i mean widely accepted, i mean in most accessable networks, i think the safest and most reasonable thing is to let the user specify the pathname and let each 'link' process what it understands or else complain. Or else complain? This brings me to part 2 of this verbose note. That, is, complain to whom? And how. I would like to point out that in handling a piece of mail, in general, one level of host/network addressing will be stripped off the 'To:' field before passing it on to the forwarding entity. This information will be lost unless we provide somewhere else to store it, such as a 'Via:' field. It could be argued that the 'Sender:' or 'From:' field could contain a full return address. However, it's going to be a problem for an intermediate site to decide where in the full return address to start, in order to tell the Sender that (s)he lost. However, i would suggest saving the information stripped off by a forwarding be inserted at the beginning of the 'Via:' field. Then, assuming all paths are bi-directional, the 'Via:' field would describe the path back to the sender during and after transmission. Question: Is the assumption of bi-directionality a reasonable one? Thus, i see the 'Via:' field serving several purposes. It provides a trace of where a message has been, to aid the human in chasing down problems. It provides the human recipient with a path to send a return message. It also provides the mail-reader with a path to send a return message. And it provides a simple path back for the forwarding sites in case errors are discovered along the way, like 'no such mailbox' or 'no such site'. I would like to remind people that whatever we do here is likely to be copied by other networks, especially if such networks would like to communicate smoothly with users of this network. I believe it is to our indirect benefit to make our protocols usable and acceptable to other networks, even if this means we have to think a lot harder about issues which do not directly affect us, and consider networks which may be either more ephemeral or more rigid than our own. --- Tovar To DCrocker: Please excuse me if i'm not up-to-date on all the details of RFC 733. I've been rather busy making sure i can pay the rent, so to speak.  Date: 19 Jan 1979 2101-PST From: Tovar Subject: Inter-networking To: Header-People at MIT-MC Inter-networking As i see things, there are two issues being addresses here: (1) how to send, and (2) how to reply. I would first like to address the issue of how to send. One suggestion, "Smith@MSR"@MIT-XYZ has two strikes against it. First, it looks ugly. Second, it does not nest well. That is, if another level of indirection is necessary, how are more quotes going to be added and if so, what hope is there for readability? Secondly, there has been some suggestion, which i do not completely understand, that at least some '@ something' can be removed from a construct like 'Friendly name @ hosta @ local-net1 @ majornetq'. In some instances, that is true, just as it is in the U.S. Postal Service, Tovar A.I. Project Stanford, CA 94305 not only works, but gets there faster than the official address of Tovar Artificial Intelligence Project Computer Science Department Stanford Universiy, Stanford CA 94305 While if i tried to do something like that at UCSB, i'm afraid there would be little hope, just as if i tried to send mail to John Smith @ IBM-Net @ CommercialNet or John Smith @ Louisville @ CommercialNet This, of course, assumes that everyone knows how to, and can legitimately send messages to, CommercialNet. There are some additional problems besides trying to get unique addresses. If you think we have trouble keeping host tables up-to-date, try adding how to get onto other networks. If you think we have trouble keeping host tables up-to-date, how about other networks that may well be more informal, or may actually change dynamically. At least until and if there comes about a widely accepted, and when i mean widely accepted, i mean in most accessable networks, i think the safest and most reasonable thing is to let the user specify the pathname and let each 'link' process what it understands or else complain. Or else complain? This brings me to part 2 of this verbose note. That, is, complain to whom? And how. I would like to point out that in handling a piece of mail, in general, one level of host/network addressing will be stripped off the 'To:' field before passing it on to the forwarding entity. This information will be lost unless we provide somewhere else to store it, such as a 'Via:' field. It could be argued that the 'Sender:' or 'From:' field could contain a full return address. However, it's going to be a problem for an intermediate site to decide where in the full return address to start, in order to tell the Sender that (s)he lost. However, i would suggest saving the information stripped off by a forwarding be inserted at the beginning of the 'Via:' field. Then, assuming all paths are bi-directional, the 'Via:' field would describe the path back to the sender during and after transmission. Question: Is the assumption of bi-directionality a reasonable one? Thus, i see the 'Via:' field serving several purposes. It provides a trace of where a message has been, to aid the human in chasing down problems. It provides the human recipient with a path to send a return message. It also provides the mail-reader with a path to send a return message. And it provides a simple path back for the forwarding sites in case errors are discovered along the way, like 'no such mailbox' or 'no such site'. I would like to remind people that whatever we do here is likely to be copied by other networks, especially if such networks would like to communicate smoothly with users of this network. I believe it is to our indirect benefit to make our protocols usable and acceptable to other networks, even if this means we have to think a lot harder about issues which do not directly affect us, and consider networks which may be either more ephemeral or more rigid than our own. --- Tovar To DCrocker: Please excuse me if i'm not up-to-date on all the details of RFC 733. I've been rather busy making sure i can pay the rent, so to speak.  Date: 20 Jan 1979 0903-PST From: Mark Crispin Subject: multi-networking To: Header-People at MIT-MC Well, in the "ideal" implementation everybody would know about everybody's network and how to get the message there. Hair in routing is possible too; it could know that there are several different ways with different costs, and it can make an intelligent assessment of what would be the "best" way (otherwise it could guess randomly). Hence, "MRC@SU-AI" would work from anywhere, regardless of whether or not the sending host has any direct network connection to SAIL. Of course, this is pie in the sky, but I feel it is the "right" way and it's important that nothing be done to prevent this way from eventually being implemented. Of course, this will happen in a future time, when everybody is using the same design hardware, the same operating system, there is peace on earth, good will towards (wo)men, and a cure is found for the common cold... Until then, it seems that the suggested foo@bar@bletch@garply@mumble is good enough, unless some hair needs to be stuck in for MIT's structured recepients or whatever. It has the gross disadvantage in that implicit to this scheme is a fixed method of routing--I would have to be a smart mail program indeed to know that the bar that I can get to by going through bletch and garply is the same bar that I (mumble) have a direct link to that the sender didn't know about! A final note: isn't it a reasonable assumption that a participant in inter-network mailing will be reasonably sophisticated, presumably enough to be part of a single community with one meta-host-table? If so you can have your pie in the sky and eat it too (I like pumpkin myself, but we bake apple and cherry too...). -- m  From: Dcrocker at Rand-Unix Date: 23 Jan 1979 at 1557-PST Message-ID: <102.285983854@Rand-Unix> To: Header-People at MIT-MC Subject: Modifications to RFC 733 Three things. 1. As a reminder, the official spec was modified some time ago to make group "names" required and no longer optional, for group lists. Syntactically, this changes "[phrase] ':' #address ';'" to be "phrase ':' #address ';'". This was done to resolve a parsing abiguity pertaining to the use of colons. 2. I would like to solicit opinions about imposing the same requirement on individual address lists, changing "[phrase]" '<' #address '>'" to be "phrase" '<' #address '>'". The only justification would be to make it consistent with the group list style. Do any of you care if it is consistent or do you care if it is not? 3. More important: Currently, group and individual lists have a syntactic distinction, but no semantic one. The semantics are that ALL mailboxes in the address list (#address) are to be referenced (e.g., receive copies of a reply). I would like to change that so the semantics for groups remain the same but for individuals it becomes ANY ONE OF the members of the list MAY be referenced (tho using more than one would be legal). The justification is the presumption that the typical need by the individual will be to ensure that at least one copy gets through to one of his/her mailboxes, rather than worrying about getting them to all of their mailboxes. In the (presumed) unusual case that the individual wants a copy in all mailboxes, they may use the group syntax. Again, do any of you care? Why? I feel rather strongly that the change should be made and would like to hear arguments in either direction. My general justification for requesting the change in #3 is some of the recent discussions we've had seemed to me to point up the need. I also presume no one would have to recode on the basis of the change. Thanks. Dave  Date: 24 Jan 1979 0603-PST From: Zellich at OFFICE-1 Subject: Re: Modifications to RFC 733 To: Dcrocker at RAND-UNIX, Header-People at MIT-MC cc: ZELLICH In response to the message sent 23 Jan 1979 at 1557-PST from Dcrocker@Rand-Unix Whether a "phrase" is specified or not for an individual address (list) seems to be more a matter of personal style of the sender, and shouldn't really matter to any header-parsing program...The program will just scan looking for a "<" and ignore anything found to the left if the "<" is found. I think it should be left as is. I don't quite understand the proposed semantic change for the individual lists - who/what decides which member(s) get referenced? If the sender is trying to assure that at least one copy gets through, s/he must have some suspicion that some supposedly-functioning mail mechanism is not really working somewhere. A host can indicate that it received and delivered the mail, and still fail to actually deliver it to the intended recipient [in readable form]. Rich -------  Date: 30 JAN 1979 1931-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: Peculiar header To: header-people at MIT-MC Date: 29 Jan 1979 2238-PST From: Bair at SRI-KL (James Bair) Subject: Workshop on Human-Computer Communication To: DIST2:, To:, To:, To:, To:, To:, To:, To:, To:, To:, To:, To: To:, To:, To:, To:, To:, To:, To:, To:, To: Neat, eh?  Date: 30 Jan 1979 1642-PST From: McLure at SRI-KL (Stuart McLure Cracraft) Subject: Re: Peculiar header To: RMS at MIT-AI, header-people at MIT-MC In-reply-to: Your message of 30-Jan-79 1631-PST That seems to have been caused by a file containing things like DIST2: foo@bar, foo1@bar, to: foo3@bar, to:foo4@bar, etc... ad infinitum. -------  Date: 31 JAN 1979 0902-PST Sender: FARBER at USC-ISI Subject: Re: Peculiar header From: FARBER at USC-ISI To: McLure at SRI-KL Cc: RMS at MIT-AI, header-people at MIT-MC Message-ID: <[USC-ISI]31-JAN-79 09:02:45.FARBER> In-Reply-To: Your message of 30 Jan 1979 1642-PST someone used the header from a message he received. Lik To: farber,smith To: jow,sam To: abe etc guess what that gives!! Dave  Date: 3 Feb 1979 1402-PST Sender: FEINLER at SRI-KL Subject: Who can shed some light? Replies to david@UTEXAS, cc: Feinler@SRI-KL From: FEINLER at SRI-KL To: HEADER-people@MIT-MC Cc: FEINLER Message-ID: <[SRI-KL] 3-Feb-79 14:02:23-PST.FEINLER> 9 Jan 1979 at 0913-CST *REF* david at UTEXAS: Aborted Mail Messages Distribution: FEINLER AT SRI-KL, david Received at: 9-Jan-79 07:23:43-PST Occasionally we receive aborted Arpanet mail messages. This con cerns some users, who fear they are losing good messages. I wonder if you could point me to information to help resolve this concern. The messages are always 60-odd bytes long. They come from dif- ferent places, as indicated by different header line formats. There is a header line, usually with just the date, and there is a line saying "*** SENDER ABORTED CONNECTION ***". It is unfortunate that the header line has just the date. I no- tice that MIT-ML includes the name of the sender in that line, so one can identify the sender of an aborted message. A line with just the date is frustrating, because you don't know what hap- pened. I wonder if it is worth suggesting that other mailers follow the practice of putting the sender name and date in the header? I don't know what mechanism would be appropriate for that suggestion. As far as I know, the messages are legitimately aborted by the sender, and it is not caused by a problem at our end. But I'd like to know if anyone has more information on this. Do senders know they are aborting the connection? If it happens sometime later, do the senders get notified? Can one safely ignore an aborted message and assume the sender will resend? I you would forward this to others who might be able to shed some light on my questions, I would appreciate it. Thank you. --David M. Phillips david@utexas  Date: Sat, 3 Feb 79 16:07-PST Subject: Aborted mail From: Greep at Rand-Unix To: david at Utexas cc: Feinler at Sri-Kl, header-people at Mit-Mc Message-ID: Reference: <[SRI-KL] 3-Feb-79 14:02:23-PST.FEINLER> The "sender aborted connection" message comes from the Unix server FTP and means that the socket was closed before receiving the line begining with a period that is supposed to end the message. There are a number of versions of the Unix NCP floating around, some of which are not especially reliable. My guess is that your NCP is just flaky for some reason. If you want to get a little more information, you can modify the server FTP to put a line at the beginning saying what host the message is coming from (some systems to this), then you might be able to find out something about the message from the wizard at that host. In any case the sending host should notice the failure and try to resend the message later, or at the least notify the originator of the failure. Jake: seems this sort of thing is more appropriate for MsgGroup than for Header-People.  Date: 4 FEB 1979 0752-PST Sender: FARBER at USC-ISI Subject: Re: Aborted mail From: FARBER at USC-ISI To: Greep at RAND-UNIX Cc: david at UTEXAS, Feinler at SRI-KL, header-people at MIT-MC Message-ID: <[USC-ISI] 4-FEB-79 07:52:09.FARBER> In-Reply-To: To the header-people list maintainers. Greep had a good idea in creating yet another list that could be used by people who have queryies pertaining to operational mail system problems. MSGGROUP is not right for bug problems. There is the wrong people on that list. How about a msg-maintainers mailing list. Dave  Date: 4 Feb 1979 1314-PST From: Feinler at SRI-KL (Jake Feinler) Subject: More groups To: header-people at MIT-MC, greep at RAND-UNIX, To: david at UTEXAS, farber at ISI cc: klh, feinler It was my understanding that Header-People was a group made up of the mail maintainers around the network which was why I directed the message to them. MSGGroup always seemed to be a group that talked more about the broad issues rather than specific implementation. If Header-People is made up of the implementors already, it seems redundant to start a group named MSG-Maintainers. However, I am just an observer of all these groups for the most part so these shouldbe considered comments from the sidelines. If another group is started, may I please be added to the distribution list for information purposes. Thanks, Jake -------  Date: 4 FEB 1979 1522-PST Sender: FARBER at USC-ISI Subject: Re: More groups From: FARBER at USC-ISI To: Feinler at SRI-KL Cc: header-people at MIT-MC, greep at RAND-UNIX, Cc: david at UTEXAS, klh at SRI-KL Message-ID: <[USC-ISI] 4-FEB-79 15:22:01.FARBER> In-Reply-To: Your message of 4 Feb 1979 1315-PST to risk just one more note. is there anyone on header-people who does not want to receive messages that deal with system maintenance issues as opposed to protocol matters. If you send me a note I will see if it warrants yet another list. Dave  Date: Monday, 5 Feb 1979 0143-EST From: Brian K. Reid Subject: Aborted messages To: FEINLER at SRI-KL CC: David at Utexas, Header-People at MIT-MC Message-ID: <05Feb79 014319 BR10@CMU-10A> In-Reply-To: <[SRI-KL] 3-Feb-79 14:02:23-PST.FEINLER> CMU has had trouble getting messages through to UTEXAS; I don't know enough about the inner workings of our mailer to know just what the problem is, but it's the only site on the network with which we have had such trouble. It ends up looking like a receiver timeout from this end.  Date: 5 February 1979 11:11 est From: Pogran.CompNet at MIT-Multics Subject: David's problem To: David at UTEXAS cc: Feinler at SRI-KL, Header-People at MIT-MC Message-ID: <790205161122.292528 at MIT-Multics> Looks like a good old-fashioned case of NCP/FTP bug to me. I would suggest that the scenario is something like this: The host wishing to xmit mail to UTexas issues an RFC on the FTP data connection. The UTexas NCP for some reason "doesn't see" the RFC; could be that the FTP Server didn't tell it to expect the connection, or didn't tell it soon enough, or gave the NCP worng parameters for the socket & the NCP didn't reject the RFC, or whatever. In any event, the UTexas NCP sends neither a matching RFC nor a CLS, and after a while the other host times out and aborts the FTP Telnet control connection, resulting in the "*** SENDER ABORTED ..." message at UTexas. The key to solving the problem would therefore seem to be the UTexas NCP maintainers' discovering why the data-connection RFC is not being fielded properly. Secondary issue: Some mailers use the FTP MAIL command, whhile others use MLFL. Most likely, this problem occurs with mailers that use MLFL. I'll let you know wheter Multics, which uses MLFL, was able to send this to UTexas successfully! Ken Pogran  Date: Mon, 5 Feb 79 12:55-PST Subject: Re: More groups Subject: Aborted mail From: Greep at Rand-Unix To: Feinler at Sri-Kl (Jake Feinler), FARBER at Usc-Isi cc: header-people at Mit-Mc, david at Utexas, klh at Sri-Kl Message-ID: In-Reply-To: Messages of 4 Feb 1979 1314-PST by Feinler and In-Reply-To: 4 FEB by FARBER <[USC-ISI] 4-FEB-79 07:52:09.FARBER> Jake, maybe you are right. I had thought that header-people was for people interested in the specifications of mail headers, not implementations per se. In response to Dave's suggestion, maybe just a general Wizards group is what is needed, similar to the liaison-group which now exists for administrative messages (but is sometimes used for technical correspondence).  Date: Monday, 5 Feb 1979 1731-EST From: Brian K. Reid Subject: WIZARDS mailing liit To: Header-people at MIT-MC Message-ID: <05Feb79 173148 BR10@CMU-10A> In-Reply-To: I think that a WIZARDS mailing list would be a good idea. The Liaison list is not available to us mortals, and it reaches the wrong kind of people.  Date: 5 FEB 1979 1820-EST From: MOON at MIT-MC (David A. Moon) Subject: David's problem (Pogran's theory) To: Pogran.CompNet at MIT-MULTICS, David at UTEXAS CC: HEADER-PEOPLE at MIT-MC, Feinler at SRI-KL I'd tend to doubt it was a connection-establishment problem, since supposedly the first line of the message header got through.  Date: 5 Feb 1979 1611-PST From: Feinler at SRI-KL (Jake Feinler) Subject: liaison-sndmsg.txt To: header-people at MIT-MC cc: feinler This file is available for FTP from SRI-KL. It is updated monthly after I send out the monthly liaison list (will be current by Weds of this week). Not all the Liaison are software maintainers by a large portion of them are. WIZARDS might be a better idea. This is just to let you know that the Liaison distribution list is publicly available as advertised in the front of all the NIC documents. Word of caution - it contains well over 100 names which makes queuing the message being sent almost mandatory unless you want to tie up your terminal until this time next Thursday. Jake -------  Date: 5 FEB 1979 1604-PST Sender: FARBER at USC-ISI Subject: Re: WIZARDS mailing liit From: FARBER at USC-ISI To: BR10 at CMU-10A Cc: Header-people at MIT-MC Message-ID: <[USC-ISI] 5-FEB-79 16:04:56.FARBER> In-Reply-To: <05Feb79 173148 BR10@CMU-10A> Does sound like a wizard list is "voted". I submit dcrocker at rand-unix, szurko at rand-unix, and farber at office-1 for the Univ of Delaware offerings. Dave  Date: 5 Feb 1979 1627-PST From: McLure at SRI-KL (Stuart McLure Cracraft) Subject: Re: WIZARDS mailing liit To: FARBER at USC-ISI, BR10 at CMU-10A Cc: Header-people at MIT-MC In-reply-to: Your message of 5-Feb-79 1604-PST Please include me on the list. Where will it be kept? on one of the ITS machines .MAIL.;NAMES > or where? It should definitely be publicly acessible to modification. -------  Date: 5 February 1979 21:15 est From: Palter.PDO at MIT-Multics Subject: Re: Re: WIZARDS mailing liit To: McLure at SRI-KL (Stuart McLure Cracraft) cc: FARBER at USC-ISI, BR10 at CMU-10a, Header-people at MIT-MC In-Reply-To: Msg of 02/05/79 19:27 from McLure Message-ID: <790206021532.012895 at MIT-Multics> Please include me on the list (for Multics). You should also include Greenberg@MIT-Multics in the list. I think it should indeed be kept on an ITS like Header-People as this allows for simpler modifications when necessary  Date: 5 Feb 1979 1818-PST From: McLure at SRI-KL (Stuart McLure Cracraft) Subject: Re: Re: Re: WIZARDS mailing liit To: Palter.PDO at MIT-MULTICS Cc: FARBER at USC-ISI, BR10 at CMU-10A, Header-people at MIT-MC In-reply-to: Your message of 5-Feb-79 2115-PST Who is going to implement this list? I suggest the person who first recommended it. -------  Date: Mon, 5 Feb 79 18:51-PST Subject: Re: liaison-sndmsg.txt From: Greep at Rand-Unix To: Feinler at Sri-Kl (Jake Feinler) cc: header-people at Mit-Mc Message-ID: In-Reply-To: Your message of 5 Feb 1979 1611-PST The problem with using the liaison list (in addition it to not being appropriate for this sort of thing) is that you can't just send mail to it, as you can with lists like header-people. (I never understood why this hasn't been implemented on tenex.) Each person has to FTP it himself, meaning outdated copies invariably spread around. Also it assumes that every mail-sending program can read tenex-style mailing list files.  Date: 5 FEB 1979 1909-PST Sender: FARBER at USC-ISI Subject: Re: Re: Re: WIZARDS mailing liit From: FARBER at USC-ISI To: McLure at SRI-KL Cc: Palter.PDO at MIT-MULTICS, BR10 at CMU-10A, Cc: Header-people at MIT-MC Message-ID: <[USC-ISI] 5-FEB-79 19:09:35.FARBER> In-Reply-To: Your message of 5 Feb 1979 1818-PST Well I would be happy to do so but alas I dont have an account on the ITS machine. Dave  Date: 5 Feb 1979 2037-PST From: Klh at SRI-KL (Ken Harrenstien) Subject: "wizards" list To: Header-people at MC I think Jake did the right thing in forwarding that note to Header-People. The list was, in fact, intended originally to help work out the header issues; however the approach used was that of trying to include all the message system maintainers and work things out directly rather than trying to penetrate through bureaucracy or liaisons. I don't know of any better forum for discussion of mailer problems in general, because I certainly hope that the current list includes all such maintainers. Whether more lists are necessary isn't clear to me. It would be nice to have similar lists for FTP and TELNET maintainers in particular, since these along with mail seem to compose the bulk of any arpanet interactions, but I'm not sure if this is what people are asking for. Seems as if something as general as "wizards" is going to have as much if not more randomness in its mail as Header-people does. Perhaps those who want other lists can be more specific about the kinds of people they want on the list, and the kinds of messages to be sent? (I also have the feeling that most people currently on the list (whether "interested observer" or "mail maintainer") are going to want to get in on a new list as well...) -------  Date: Tuesday, 6 Feb 1979 0851-EST From: Diana.Bajzek at CMU-10B (S300DB33) Subject: Re: "wizards" list To: Header-people @ MC Message-ID: <06Feb79 085152 DB33@CMU-10B> In-Reply-To: Ken Harrenstien's message of 5 Feb 79 23:37 I agree with Ken, I think most of the people in Header-people would liketo think of themselves as, and include themselves in "Wizards". But, if a new list is built, include Bajzek@CMUB.  Date: 6 Feb 1979 0909-PST From: Feinler at SRI-KL (Jake Feinler) Subject: Re: liaison-sndmsg.txt To: Greep at RAND-UNIX cc: header-people at MIT-MC, FEINLER In response to your message sent Mon, 5 Feb 79 18:51-PST I certainly agree with you that TENEX and TOPS-20 should implement being able to send messages to a group. If this were availabl then one could use all of the group distribution stuff the NIC maintains. We (the NIC) spent a lot of time trying to make this happen around TENEX but the effort became prohibitive in time and programming bucks and we gave up. I think this should be a feature of the Mail Protocol. I would also point out that just because one can send a message to a group (which by the way is a feature that has been available in NLS for many years but does not extend to non-NLS users unfortunately) does not insure that the group distribution list is up to date, as indeed many of them are not. Jake -------  Date: Tue, 6 Feb 79 09:14-PST Subject: Wizards mailing list From: Greep at Rand-Unix To: Header-People at Mit-Mc Message-ID: Since nobody is volunteering to maintain (or create) this list, maybe someone at MIT will add a feature by which this can be done without any manual intervention, e.g. sending a message of the form To: Mailing-list-updater@MIT-MC From: Foobar@Rand-Unix Add-to-list: Wizards-group would automatically add "Foobar@Rand-Unix" to the "Wizards-group". , with a similar "Delete-from-list" field. (The address to be added or deleted would not necessarily have to be taken from the "From" field.) I believe ITS already has provisions for incoming mail to invoke a program.  Date: 6 Feb 1979 0940-PST From: Feinler at SRI-KL (Jake Feinler) Subject: Re: Liaison Mailing List To: FURST at BBN-TENEXB, Klh cc: FEINLER, header-people at MIT-MC In response to the message sent 5 Feb 1979 2356-EST from Furst@BBN-TENEXB Sheldon, Ken does not maintain the Liaison Mailing List. It is maintained by the NIC as I stated in one of my previous messages. For quite a while it was on MC but was frequently out of date because the maintainer there did not bother to get a new copy from the NIC. There are other more serious problems involved in having the Liaison mailing list (or any really long mailing list) available on a given host, and that is that that host is bombarded by mail traffic that it may not wish to handle. My own feeling is that all mail hosts should be able to handle sending messages to a group distribution list. If the list is for local consumption it would be maintained locally. If it is global (i.e., netwide) it should be maintained by the NIC and the mailer would first look for the list locally. If not found, it would go to the global data base and look for the distribution list and upon finding it, send the message to the individuals included in the list. We are in the process of trying to make this happen by redoing the data base so that it is more universally usable. We do maintain many group membership lists already. The group distribution lists are very fluid and really do require a maintainer...they don't maintain themselves. However, there is a lot of work needed by way of standardizing mailers and redoing the protocol before what I am suggesting is a reality. Another issue that comes up is the one of 'junk mail'. If the mailing lists are really easy to use, they will be used by people who hve very little to say as well as by those who have something useful to say. I frankly don't know the answer to this one. Up until now I think peer group pressure has been the best deterrent for junk mail. If someone sends a really idiotic message he/she usually hears about it in no uncertain terms. I suppose at some point the mailing lists will be restricted to only those members included - that is an outsider won't be able to send a message to a given group unless he gets himself included in the mailing list or some such. Guess I have reservations about that, but can see it may get to be a matter of self preservation or maintaining ones sanity. Have more to say on the matter of group distribution but this will suffice to give a flavor of some of the problems and some of the potential benefits. Maybe we should open this up as a topic for discussion some time. Regards, Jake -------  Date: 06 FEB 1979 1843-EST From: Joanne Sattley Subject: Re: Liaison Mailing List To: Feinler at SRI-KL, FURST at BBN-TENEXB, Klh at SRI-KL cc: Header-People at MIT-MC In response to the message sent 6 Feb 1979 0940-PST from Feinler@SRI-KL -- here's a suggestion for an alternative method of handling group(s) mail using the CCA Datacomputer's public message store. It eliminates the need for maintaining mailing lists & allows members to select the junk and non-junk mail they wish to view. A. Composing the message Group mail could be written using exactly the same programs as are being used at present. The subject-field, however, would need to contain some group-identifying keyword: i.e., "liaisons", "wizards", "header-people", "FTPers", etc. or combinations of keywords, in addition to the usual subject information. The message would be addressed to: "public@CCA". At CCA, a mail-filing demon (aka MARS-Filer) would store the messages on the Datacomputer; they'd ordinarily be available for retrieval within the hour -- but the period could be adjusted if people felt a lack of freshness and spontaneity, both of which are desirable characteristics of the current practice. B. Reading group mail Anyone wishing to see mail of particular interest in one or more areas would send a message to: "MARS-R@CCA" (or to "MARS-Retriever@CCA") with the retrieval criteria in the body of the message. E.g., to see mail for wizards and TELNETii sent on the 6th of February: TO: public SUBJECT: wizards,TELNETii DATE: 6 Feb 1979 would do the trick. Or, to get a week's worth of mail, e.g., last week's: AFTER: 27 Jan 1979 BEFORE: 4 Feb 1979 TO: public with SUBJECT: field specs as desired. You'd need to say "wizards or telnetii" to see mail which pertained to either one or the other, rather than both. The requested messages are mailed out from MARS-Retriever; they'll appear as new mail in the requester's message file. The CCA programs to do this exist -- and run round the clock (although access to the Datacomputer from 7 to 9 AM EST is restricted to staged data because of PM). Please feel free to give it a try. --Joanne -------  Date: 6 FEB 1979 1943-EST From: RMS at MIT-AI (Richard M. Stallman) To: HEADER-PEOPLE at MIT-AI I am sure that if I got a message I thought was losing I wouldn't be satisfied with sending it to a retrieval system from which the other recipients of the losing message merely might retrieve it. I would want to make sure that I sent it to them and as soon as possible.  Date: Tue, 6 Feb 79 18:13-PST Subject: Re: liaison-sndmsg.txt Subject: Liaison Mailing List From: Greep at Rand-Unix To: Feinler at Sri-Kl (Jake Feinler) cc: header-people at Mit-Mc Message-ID: In-Reply-To: Messages of 6 Feb 1979 0909-PST by Feinler and In-Reply-To: 6 Feb 1979 0940-PST by Feinler I meant that it is easier to keep one list up-to-date than to keep many lists up-to-date since usually there is one place maintaining the list and there is no way to assure that updates to that copy are reflected in other copies. I see two practical problems with the scheme of having the sending site automatically retrieve a mailing list each time it wants to send mail to that list (in addition to the inefficiency of retrieving it): (1) it would require a standard format for mailing lists (I can just imagine the squabbles between the ITS and tenex people); and (2) it requires a fair amount of inteligence in each host to implement. A further (although non-technical) problem is that it would require each host on which mailing lists are kept to allow access to those files by anyone.  Date: 6 February 1979 22:56 est From: Frankston.Frankston at MIT-Multics Subject: Re: Re: Liaison Mailing List To: Feinler at SRI-KL (Jake Feinler) cc: FURST at BBN-TENEXB, Klh at SRI-KL, FEINLER at SRI-KL, header-people at MIT-MC In-Reply-To: Msg of 02/06/79 12:40 from Feinler Message-ID: <790207035647.348106 at MIT-Multics> It is nice to find a concrete example that justifies my flaming. The support of mailing list servers is a prime example of the need for an ability to extend the ability to provide mail services from the operating system maintainers to users. It should be possible for a user process to act as a secondary server for mail. Thus: LIASON-LIST at LIST-SERVER at NIC The above would appear in the recipient: field. either periodically the user process would service the mailbox, or in fancier systems, (such as ITS9 would wakeup automatically when there is mail waiting. the point is that one should not have to be dependent upon the local diety for new capabilities.  Date: 8 Feb 1979 1633-EST From: MICHAEL SHAMOS at CMU-10A (C370MS20) Subject: Are we professionals? To: header-people @ MIT-MC, msggroup @ USC-ISI Message-ID: <08Feb79 163318 MS20@CMU-10A> I am preparing some recommendations about professional certification of computer scientists to a subcommittee of the American Bar Association. Your ideas are important. Please read the following material and mail your carefully considered responses to SHAMOS@CMU-10A. The American Bar Association Section on Science and Technology has a subcommittee on Responsibilities of Computer Professionals. This group is studying issues relating to recognition of professional status for computer and data processing personnel. Such recognition would have advantages and disadvantages for us. For example, licensing laws and a code of professional conduct would seem to improve the image of the profession and the quality of its output but such status might at the same time impose legal liabilities and the spectre of malpractice. (A licensed systems programmer might be successfully sued by a user who paid for his code if it were not properly debugged.) As is the case with all licensed specialties, this risk of liability would be compensated for by higher salaries. I fear that the ABA may arrive at its conclusions by listening far more to lawyers than to computer scientists. It is important for those with intimate knowledge of the field and the nature of our work to provide input for the study. I thus propose to send a document to the chairman of the subcommittee with some ideas for consideration and I would like them to represent the thinking of a sizeable group of. us. Will you please mail me your thoughtful opinions? A copy of my memo will be made public. If you need someplace to start, consider the list of issues below. Please note that the ABA has NOT set itself up as any authrity in this matter. It will NOT dictate to the government what is to be done about computer professionals. It will make recommendations. In the absence of input from the computer science community these recommendations are likely to be followed. We surely want the initial reports to reflect our considered views. General What are the real aims of improving professionalism? The good of mankind, or bettering our own lot? If the public knew that its computer peple were guaranteed to be well-trained and accountable for their work, we might find greater acceptance of computers in general. Are computer people really professionals? (In this context a professional is one who by virtue of his special training and appreciation of ethical values is invested with special privileges and concomitant responsibilities.) Do the people you know fit this mold? Is one a professional just because he can work miracles with monitor UUOs (i.e. has technical skills the layman lacks)? The impetus for professionalization comes from the recognition that computer people can do a great deal of harm, both deliberately and innocently. How can we assure the public that we are qualified to do the job and that we will be answerable for the consequences? Certification Should computer scientists be licensed? This would presumably mean the intrusion of a government bureaucracy and the imposition of standards by the legislature. Some professional society would be designated to accredit individuals. Some excellent hackers might be shortchanged if there are stiff formal requirements. See if you can suggest a certification procedure that would avoid this problem. Should there be a division into professionals and paraprofessionals? For example, licensed systems analysts assisted by unlicensed coders? Would the professional take responsibility for the work of those under his supervision? Role of academic departments Presumably certification will require some academic degrees and/or a licensing examination and/or stiff apprenticeship requirements. What role will academic computer scientists play? Will we teach ethics? Will academics be looked to for guidance in such matters? Code of ethics Should professionals have to obey a code of responsibility? Who would set up and enforce such a thing? Give some examples of suitable provisions. What would constitute a "disbarment" offense? Remember that such a sanction would mean loss of livelihood for the individual. Would computer professionals be held to high abstract standards (e.g. "quality of life", "freedom from oppression", "preservation of the environment") or to the pragmatics of client representation ("do whatever your employer wants")? Imagine that you have been hired to design a credit-reporting system? The employer wants to include features that you regard as oppressive, such as the storage of unverified rumors about a customer's credit. Are you obliged to implement them, or may you withdraw from the job? If you think that we must always stand up for the little guy, don't you think that the American system requires that business be represented too? Should there be a privilege of confidentiality between a computer professional and his client analogous to the doctor-patient or attorney-client privileges? Guidelines for creating intelligent machines? (Cf. the current controversy over recombinant DNA.) Criminal responsibility if things get out of hand? (What good would it do by that time?) Liability How could claims be adjudicated fairly? A computer ombudsman to protect the public from abuse via computer? An arbitration panel of lawyers, computer scientists and businessmen to resolve disputes in which licensed professionals are involved? Malpractice insurance? I hope these topics have gotten you thinking. Before sending me a reply, go away and think hard about these matters. I think they are important and that we can have considerable influence on the administrative process that will take place if we can present views that are rational and carefully thought-out.  Date: 10 FEB 1979 0242-EST From: JIS at MIT-MC (Jeffrey I. Schiller) To: shamos at CMU-10A CC: HEADER-PEOPLE at MIT-MC, SIPB at MIT-MC It is my opinion that the computer science and data processing fields do not need any psuedo professionalism. By psuedo professionalism I am referring to professionalism granted to computer scientist by an as yet unknown third party (probably influenced by things not pertaining to computer science). I feel that adding "professionalism" to the computer science and data processing fields will have adverse affects to both the computer programmer and the consuming market as well. Professionalism will not increase the productivity of a given programmer, but will only provide a means of determining (I'm sure in an unreasonable way) and enforcing a minimum standard on programmers in general. This casting off of the low end of the spectrum isn't worth the kind of shakeup in the field that enforced professionalism would produce. Also to the detriment of the programmer is the possibility of law suits resulting from legitimate and unintentional bugs in programs. As anyone who has written reasonable sized programs can tell you, it is near impossible to write and release perfect software to do marvelous things in limited time. This is exactly what the programmer would have to do in order not to worry about a law suit. This fear of law suits would eventually lead to insurance (malpractice?) and other forms of bureaucratic lossage. Although the average programmers salary would go up, so would his expenses (insurance) go up. It is also not clear to me that programmers necessarily want professionalsim if the only reward is a hight salary. Most of the really good programmers I have met are working on very low wages, and don't care. That is the personality of the good programmer. On the other side of the coin, there is the affect of professionalism on the consumer (the consumer being defined here as any person benefiting from a programmers efforts). This I am sure would be negative. Look at the American Medical Association. This organization is a very powerful force in establishing the cost of health care. And this cost is not low. Could you imagine an American Programmers Association that set standards for both programming methods and prices. Currenly in computer science there is no "authority" to judge what is good and what is bad. This professionalism would surely create one. Could you image what would of happened 20 years ago if professionalism was introduced then and thos that controled this so far mithical APA decided (arbitrarily) that all good programs were to be written in assembly language. I am not implying that the field wouldn't advance in this environment, but that its advancement would be slowed down by red tape and "official acceptance".  Date: 10 Feb 1979 0052-PST From: Mark Crispin Subject: programmer professionalism (long & flaming message) To: Shamos at CMU-10A CC: Header-People at MIT-MC I must say, this proposal sounds pretty much like a loser. The legal implications are staggering. Speaking from my perspective, computer programming is an art rather than a science, requiring at least as much skill as knowledge. In my opinion, education in computer science can refine or assist in the acquistion of the skill through knowledge, but can never be a complete substitute. Consider the environment where professional certification would be important. If we are talking about a commercial application, software is often quite straightforward and requires little more than some training in COBOL. If professional certification requires a PhD, you won't have professionals, simply because that kind of job does not attract PhDs. Let's consider another common situation: that of the wizard. He or she knows the internals of the operating system intimately, can raise crashed systems from the dead, etc. This person is a wizard because s/he wants to be, and quite often has little or no interest in persuing a PhD in Computer Science. The average level of education appears to be a Bachelor's degree, sometimes with "some" grad school, but there are examples of both extremes. Back to the PhDs. Is a PhD in computer science really a measure of that person's competance as a programmer? Not really. A PhD is a measure of that person's competance in computer science. This is related to programming and often a CS PhD is a good programmer, but one does not imply the other. So suppose we don't consider education as a method of judging a person as a professional programmer. What do we use? [Note that we've already offended the PhDs, by telling them their years of education is irrelevant to how much of a professional they are in relation to a high-school drop-out.] How can a certification test be at all fairly administered? I have no doubt that I would miserably fail a certification test geared to a person who must understand IBM architecture (PDP-10 people, recall the ACM frobs published two years ago); but at the same time I am pretty sure that I could design a test that would just as badly penalize a highly competant IBM person, yet be quite fair in judging a person's competance on the PDP-10. I doubt that anybody is seriously considering a separate test for every different manufacturer's architecture. Now, about the professional programmer's association. Do I hear rumblings about the ACM? What about those of us who have made a conscious decision NOT to be ACM members? I feel it would be an enormous affort to me to force the ACM upon me as MY professional representation. I have no doubt that the ACM is an important part of other computer-oriented people's professional lives, but I was sickened by the constant internal bickering and the complete uselessness of the ACM publications (to me). The only thing of use to me that ACM had to offer were a few of the SIGs; but ACM's heavy- handed dealing with SIGART got me digusted enough to give up completely on them. Let's consider what happens now. I'm not talking about things like computer crime (which is already illegal without that awful bill before Congress). I won't consider a full-time job, because in that case the person is an employee and it's a whole different ball game from what we usually think of as a "professional" task. A programmer is hired as a consultant to write a piece of software (say, for example, a memory diagnostic). S/he is paid half of the agreed fee when s/he delivers it, and the other half upon completion of acceptance testing. At that point (other than the usual non-disclosure agreements) his or her responsibility ends. It is the customer's responsibility to design suitable acceptance tests, and it is assumed that quite probably a just-delivered program will require modification before it will be accepted. In some cases, the program was written off-line from the customer's system and has never even been run before. Under those conditions, is s/he to be sued because the program does not pass the acceptance tests the first run around? Worse, suppose the program develops a bug several months later. Is it lawsuit time? [Note that presently the customer would hire somebody (possibly the author) to fix it instead of suing.] This essentially means that every programmer could be sued for every program ever written, even if the bug isn't his or her fault? Have you ever dealt with this situation: "Your program doesn't work. Look at this garbage." [??????I'm gonna sue you?????????] "Hmm. I thought I tested that. Hey, what is this piece of code in here? I didn't write it. This just totally breaks it." "Oh, I put it in because I wanted to change the way the GARPLY function worked...." In conclusion, I support a preservation of the status quo rather than some misguided attempt of making our art into a profession. Nothing says that artists may not have a lobby (consider the power of the musicians' union within their own interests). -- Mark  Date: 10 Feb 1979 0533-PST From: Zellich at OFFICE-1 Subject: Is this correct? To: Header-People at MIT-MC Please take a look at the following message. Have I correctly interpreted RFC733, and is the header format correct? Thanks, Rich ****INCLUDED "RFC733" MESSAGE FOLLOWS**** 9-Feb-79 10:05:11-PST,942;000000000001 Date: 9 Feb 1979 1003-PST Sender: ZELLICH at OFFICE-1 Subject: RFC733 format test - Jim and John delete without reading - From: Richard W. Zellich To: John F. Foehner , James E. Burk Cc: Richard W. Zellich Message-ID: < 9-Feb-79 10:02:23-PST ZELLICH at OFFICE-1> This message is intended to test the new "RFC733" SEND command code. A meaningless extract of my Suspense File follows... Rich EXTRACT FROM SUSPENSE FILE 8 Feb 79 *1 Topic: Graphics specialist in-house 7-9 Feb... *2 Topic: Add Bcc to mail stuff & update test-bed Suspense *3 Topic: Correspond with Stefferud about remote printer setups *4 Topic: Compose message, with Jim Burk, on running NLS FE on PDP *5 Topic: Go over Budget dialog and spec's package with Jack and *6 Topic: Discuss Databeam/DNLS-emulation assistance with Ben Skees ****END OF INCLUDED MESSAGE**** -------  Date: 10 Feb 1979 0549-PST From: Zellich at OFFICE-1 Subject: Re: Are we professionals? To: MICHAEL SHAMOS at CMU-10A, header-people at MIT-MC, To: msggroup at USC-ISI cc: ZELLICH In response to the message sent 8 Feb 1979 1633-EST from MICHAEL SHAMOS@CMU-10A The ABA subcommittee should immediately contact the ICCP (Institute for Certification of Computer Professionals), 35 East Wacker Drive, Chicago, Illinois 60601. The ICCP exists for the express purpose of certifying computer "professionals", and has the following constituent societies: ACM ACPA AEDS AIA CIPS DPMA (who originated the CDP and started the whole thing) IEEE ACDP Two different types of examination are currently given (once a year each): The Certificate in Data Processing (CDP) exam, which covers all areas of data processing (a 5-part exam & you have to pass all 5 sections); and the Certificate in Computer Programing exam (CCP). There used to be a Registered Business Programer exam, but it has been dropped in favor of the CCP. Other examinations are in the planning or development stages: CEDPA - Certificate in Electronic Data Processing Auditing; CSA - Certificate in Systems Analysis; and CDE - Certified Data Educator. The ICCP program(s) and goals address many of the questions raised by Michael Shamos' message. In particular, there is a document titled "Code of Ethics, Conduct and Good Practice for Holders of the Certificate in Data Processing". You do not have to belong to any of the ICCP constituent societies to qualify for any of the Certificates, and there is no membership (only the societies') in the ICCP itself. Richard W. Zellich, CDP -------  Date: 10 Feb 1979 0921-PST Sender: GEOFF at SRI-KA Subject: Re: Is this correct? From: the tty of Geoffrey S. Goodfellow To: Zellich at OFFICE-1 Cc: Header-People at MIT-MC Message-ID: <[SRI-KA]10-Feb-79 09:21:35.GEOFF> In-Reply-To: Your message of 10 Feb 1979 0533-PST Who cares if it conforms to RFC733 or not? Contrary to most peoples believed conceptions, RFC733 was NOT "officially" adopted as a standard and/or "required" of anyone. Most of the (small number) of people who went ahead and implemented it and who go around barking at people who don't conform to it seem to be a small class of users who do not really understand the official sanctioning or management structure of the network, and who seem to think that all programs are supported and maintained via some undetermined pot of gold supplied by some nameless agency. In particular, DCA did not promulgate the work which let up to RFC733, nor did they officially bless its final form (to which many people have numerous objections, including the lack of backwards compatibility). Hence, the currently implementations of the RFC will be left up to those few who wish to do it on their own time or at the expense of the one they work for, but that gives them no right to complain to those who do not chose to implement it, or implement it correctly. So even if your message doesn't conform to the standard, you aren't breaking the law.  From: dcrocker at Rand-Unix Date: Sat, 10 Feb 79 12:33-PST To: Zellich at OFFICE-1 cc: Header-People at MIT-MC Subject: Re: Is this correct? In-reply-to: Your message of 10 Feb 1979 0533-PST. Rich -- I think that your sending a test message arouond, so that we can see what different sites are going to put out and how they are interpreting the standard is excellent. Your example looked fine except for two points, one an error and the other merely a verbosity. The To: filed contained a continuation line, consisting of "OFFICE-1>". The line must begin with a LWSP-Char (space or horizontial tab) but did not. Also, the message contained both a From and a Sender field, when the Sender field was unecessary. No Sender field is required if the From field contains a simple host-phrase (which yours did not) or a host-phrase followed by a machine id (which yours did). Note, this applies to the case, such as yours, in whihc the Sender contains the same mailbox reference as the From. Dave.  Date: 10 FEB 1979 1326-PST Sender: FARBER at USC-ISI Subject: Re: Is this correct? From: FARBER at USC-ISI To: GEOFF at SRI-KA Cc: Zellich at OFFICE-1, Header-People at MIT-MC Message-ID: <[USC-ISI]10-FEB-79 13:26:04.FARBER> In-Reply-To: <[SRI-KA]10-Feb-79 09:21:35.GEOFF> You know, I am sadly reminded of a person cutting his own throat because his toe hurts. One can argue with whether or not 733 is correct, too elaborate or what ever, but to sit on the official sanction platform and thus recommending that one not conform to even a "de facto standard" ( and I thing 733 is no less a standard than most other ArpaNet standard) is dangerous. I might very much want to see a simpler minimal standard, but I am very tired personally of using systems and receiving messages that CANNOT live with each other. Dave  Date: 10 FEB 1979 1444-PST From: POSTEL at USC-ISIB Subject: Official-ness of RFC 733 To: Zellich at OFFICE-1 cc: header-people at MIT-MC RFC 733 is as official as any ARPANET Protocol. It is published in the ARPANET Protocol Handbook under DCA sponsorship. It is the reference document in case of disputes between message system implementors. --jon. -------  Date: 10 Feb 1979 1457-PST Sender: GEOFF at SRI-KA Subject: Re: Official-ness of RFC 733 From: the tty of Geoffrey S. Goodfellow To: POSTEL at USC-ISIB Cc: Zellich at OFFICE-1, header-people at MIT-MC Message-ID: <[SRI-KA]10-Feb-79 14:57:31.GEOFF> In-Reply-To: Your message of 10 FEB 1979 1444-PST According to SANTOS@BBNE it isn't. He claims so on two grounds, one from the big message mtg. held at BBN recently,and the 2nd since he works directly for DCA and claims it isn't.  Date: Saturday, 10 Feb 1979 1827-EST From: Brian K. Reid Subject: message standards To: Header-people at Mit-MC Message-ID: <10Feb79 182715 BR10@CMU-10A> Hey guys, I have a plan. Let's design ANOTHER standard, since this one isn't quite enough.....  Date: 10 Feb 1979 (Saturday) 1836-Est From: NIH at NBS-10 Subject: Professionalism and Certification To: header-people at MIT-MC Our own organizations, ACM, IEEE, ICCP, etc. should be the focus of our comments, not the ABA. . . . Glenn  Date: 10 FEB 1979 1550-PST From: POSTEL at USC-ISIB Subject: Re: message standards To: Brian K. Reid Hey, as long as were taking on new tasks, lets design a new programming language, the existing ones don't do everything we want, and there aren't enough yet either. --jon. -------  Date: 10 Feb 1979 1550-PST From: Zellich at OFFICE-1 Subject: Re: Is this correct? To: dcrocker at RAND-UNIX cc: Header-People at MIT-MC, ZELLICH In response to your message sent Sat, 10 Feb 79 12:33-PST Yeah, I understand about the Sender/From fields, but am actually implementing a mail-sending program that calls someone elses existing mail code to convert the file from hierarchical strucutre to sequential and to FTP it off. I have no control whatsoever over the Sender field and had a choice of leaving the From field out entirely (and thereby losing the "phrase" personalization from the NIC Ident data base) or putting in a near-duplicate header field (same net address but different text string due to the "phrase" and <>'s). The LWSP beginning a continuation line is a real problem - thanks for pointing it out. That's going to be a fun one to fix since it is caused by the hierarchical-to-sequential code converting the up-to-2000- character strings I build, and that code wants to throw away any LWSP at the start of a line! Thanks to all you Header-People out there who have responded so far (Sure are a lot of you working on Saturday!) Cheers, Rich As an aside, you ought to see what that "phrase" personalization does to a message with many recipients -- it just about makes the whole header unreadable! You just can't win for losing... -------  Date: 10 FEB 1979 1603-PST From: POSTEL at USC-ISIB Subject: Official-ness of RFC 733 To: Geoff at SRI-KA cc: header-people at MIT-MC Geoff: 1) Santos works for BBN. 2) The "big message meeting" at BBN. Duane Adams (ARPA program manager for message technology) called the meeting to try to get a plan for stabilizing the current message system situation in the ARPANET. The sense of the meeting was "if a feature works at most sites it is in, if it causes problems at more than a few sites it is out". Basicly the idea is to close off development on the current type of message systems. RFC 733 is the reference document, but that does not sanction the implementation of the "advanced features" contained there in. --jon. -------  Date: 10 FEB 1979 1628-PST Sender: FARBER at USC-ISI Subject: Re: message standards From: FARBER at USC-ISI To: POSTEL at USC-ISIB Cc: Header-people at MIT-MC Message-ID: <[USC-ISI]10-FEB-79 16:28:53.FARBER> In-Reply-To: Your message of 10 FEB 1979 1550-PST Ah DOD2 Sorry could not resist  Date: 10 Feb 1979 1614-PST Sender: GEOFF at SRI-KA Subject: Re: message standards From: the tty of Geoffrey S. Goodfellow To: POSTEL at USC-ISIB Cc: Header-people at MIT-MC Message-ID: <[SRI-KA]10-Feb-79 16:14:38.GEOFF> In-Reply-To: Your message of 10 FEB 1979 1550-PST Isn't that what DOD-I is all about?  Date: 10 FEB 1979 2303-PST From: POSTEL at USC-ISIB Subject: re: Professional Computerists To: header-people at MIT-MC i suggest the situation for professional computerists should be modeled after the situation with engineers. There are professional engineers, and there are a lot of people who went through engineering school and now work for a company doing engineering with out being certified. There are even people doing engineering work who never went to engineering school. if there ever is a way to become a certified professional computerist (e.g. the ICCP) i suspect that many people who could easily qualify,won't bother. Mainly because they will be working for companies that don't care. --jon. -------  Date: 11 Feb 1979 1441-PST From: Zellich at OFFICE-1 Subject: re: Professional Computerists To: POSTEL at USC-ISIB, header-people at MIT-MC cc: ZELLICH In response to the message sent 10 FEB 1979 2303-PST from POSTEL@USC-ISIB Jon is quite correct -- this is the situation now, ans has been for some time. I received my CDP back in '66 or '67, and it was not a new program then. Most people/organizations have still never heard of the various certificates, the certifying body, or for that matter most of the constituent societies. Most ADP people, and the companies they work for, just couldn't care less. Nevertheless, it may be a good idea to have such a certification system on hand. With all the public and congressional flaming about privacy and security, and such things as EFT coming (however slowly), there may well be a push to bring us into an environment of legal protection and liability. Considering the awesome potential when we bring together personal computers, public/private/government networks, and EFT it is quite likely that not only business/MIS types like myself, but even the "hackers", systems programers, analysts, and functinal-area specialists will become subject to regulation and both criminal and civil court action. The poor system developers/maintainers are going to have to be damned sure they leave to loopholes whereby anyone can, either intentionally or otherwise, zap a system or violate anyone's privacy. The legal principle of the "reasonably prudent person" is all well and good, but it's awfully easy to bring a malpractice suit. I would certainly prefer a certification system within the ADP community, such as the ICCP one, to anything dreamed up by the ABA, consumer rights/action groups, or Congress. Please note that as a CDP holder, I have an input channel to the certifying body, without having to belong to ANY of the constituent societies. Rich -------  Date: 14 FEB 1979 1521-EST From: SIRBU at MIT-MC (Marvin A. Sirbu, Jr.) Subject: Request for bibliographic information To: HEADER-PEOPLE at MIT-MC, FARBER at USC-ISI  Date: 17 Feb 1979 1236-EST From: Rick Gumpertz at CMU-10A Subject: Losing headers To: Geoff @ SRI-KA CC: Header-People @ MIT-MC Message-ID: <17Feb79 123648 RG02@CMU-10A> Geoffrey - Your headers (see below) seem to be particularly nasty. In particular, where you have SENDER, I think you should have REPLY-TO. As it is, since RFC733 specifies that SENDER is NOT to be used for replys, the reply address is "the tty of Geoffry S. Goodfellow" at SRI-KA which SRI-KA rejects as an illegal address. I suspect your mail generator does not understand RFC733 properly. Can you look into it? Rick - - - - Begin forwarded message - - - - Date: 15 Feb 1979 1907-PST Sender: GEOFF at SRI-KA Subject: CMMP From: the tty of Geoffrey S. Goodfellow To: Gumpertz at CMUA Message-ID: <[SRI-KA]15-Feb-79 19:07:00.GEOFF> [Body deleted] - - - - End forwarded message - - - -  Date: 20 Feb 1979 0339-PST Sender: GEOFF at SRI-KA Subject: Re: Losing headers From: the tty of Geoffrey S. Goodfellow To: rg02 at CMUA Cc: Header-People at MIT-MC Message-ID: <[SRI-KA]20-Feb-79 03:39:33.GEOFF> In-Reply-To: <17Feb79 123648 RG02@CMU-10A> Reply-to: Geoff @ SRI-KA Now that I have figured out how to make wonderful HERMES generate "Reply-to:" how is this? However, I will still have a special template just for MIT sites, which will send the message without with "Reply-to" field just to remind them each time they one of my messages how I feel when I get one of their Illegaly formatted (ITS STYLE) headers in my MAILBOX and can't parse it. Perhaps they to, someday will fix their mail system to do the right thing, and not violate network protocol.  Date: 20 February 1979 23:09 est From: Frankston.Frankston at MIT-Multics Subject: Re: Losing headers To: Geoff at SRI-KA cc: rg02 at CMU-10a, Header-People at MIT-MC In-Reply-To: Msg of 02/20/79 06:39 from the tty of Geoffrey S. Goodfellow Message-ID: <790221040912.687701 at MIT-Multics> Please, don't accuse all MIT sites of sending out illegal heaaders. That is an ITS quirk and there are indeed other systems at MIT.  Date: 20 Feb 1979 2014-PST Sender: GEOFF at SRI-KA Subject: Re: Re: Losing headers From: the tty of Geoffrey S. Goodfellow To: Frankston.Frankston at MIT-MULTICS Cc: rg02 at CMU-10A, Header-People at MIT-MC Message-ID: <[SRI-KA]20-Feb-79 20:14:35.GEOFF> In-Reply-To: <790221040912.687701 at MIT-Multics> Reply-to: Geoff @ SRI-KA Sorry, I stand corrected. I meant to say MIT-ITS sites, and didn't think of XX or Multics at the time. Sorry.  Redistributed-Date: 22 February 1979 19:19 est Redistributed-By: Palter.PDO at MIT-Multics Redistributed-To: Header-People at MIT-MC Date: 20 Feb 1979 1008-PST Sender: rudisin at UCLA-SECURITY Subject: MSGGROUP# 792 Response to MSGGROUP 790 re licensing From: rudisin at UCLA-Security To: msggroup Redistributed-To: [ISI]Mailing.List;177: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 20 FEB 1979 This message is a response to the request by Shamos@cmua for comments on the issue of licensing of computer professionals. The very subject is nauseating to me and I am disturbed that such a debate can even take place, let alone that it seems reasonable to many people in our profession. Normally I would not waste the time to reply but recalling the pathetic nature of the IEEE's recent debate on the question, wherein the real issues were ig- nored, I am compelled to respond. In a word, the very idea of governmental licensing of com- puter professionals (or anyone else) is immoral. It is immoral because it is nothing less than a form of slavery. This word seems harsh because people are so used to accepting government licensure of most other disciplines, but it is nonetheless accu- rate. For what else can you call a set of laws which require you to seek the permission of some bureaucrat before you can practice your profession -- before you are allowed to freely use your mind as a computer scientist? This is the fundamental issue; rejection of the principle that licensing is legitimate or moral must be the cornerstone of the computer science community's rejection of the concept. The idea of governmental (coercive) registration is immoral because no government has any right at all to force me to obtain a license to practice this profession. If I wish to offer my services as a computer scientist, I will put my skill and reputa- tion on the line in the free market of ideas and services, by entering into voluntary agreements with customers. The intrusion of government into this market is wrong because it is such a tremendous violation of my right to interact freely and on a voluntary basis with other people. Please note that I have no objection at all to private forms of certification; for example one of the computer societies could offer a credential certifying that its bearer has attained a certain level of skill. If a given certification organization gained a reputation for being reliable in its assessment of pro- fessionals, there would continue to be a market for its service; if not, no one would care about a credential from that organiza- tion and it would be ignored. At any time people would be free to seek customers based on their own reputations, on the posses- sion of certification from various places, on experience, on edu- cation, and so on. A totally free market in the offering of com- puter skills allows maximum creativity and freedom and will fost- er innovation instead of hindering it. Regulation of the computer community would inevitably take us down the path of the regulation of all other industries and groups -- to mediocrity, stagnation and loss of liberty. It is inevitable and plainly obvious from examples such as that of licensing of physicians that the holding of a license is a shield behind which the mediocre can hide while claiming that they are as good as the best of professionals -- after all, doesn't every- one possess the same license? Hasn't the government proven that everyone with a license is of equal competence? This is absurd but is an effect of licensing that is sure to arise. With a licensing apparatus in place the mediocre individuals in a pro- fession can keep out the creative people who challenge their pet theories and procedures or who "threaten" them with greater skill. What better way will exist for mediocre people to guard themselves against the competition of a bright young newcomer self taught on his home microprocessor system than to claim that he has not been properly licensed and is thus a threat to the public? This may sound farfetched, and would certainly not happen immediately, but is inevitable at some later date, especially when you consider that the highly competent people in a profes- sion are usually too busy producing and innovating to waste time actively running the licensing boards. Licensing boards inevit- ably fall into the control of the no better than average member of the profession. Innovation is stifled, as is also apparent in the medical profession; any kind of development which runs counter to the wisdom of the licensing board is vigorously resisted and its practitioners are called quacks. An example is the medical debate over the role of nutrition in health and the holistic approach to health. Acceptance does eventually come for new ideas but only after unnatural and wasteful delays. The holding of a license also makes it far more difficult for a consumer to be protected, because once licensed it is very difficult for an inept practitioner to be unlicensed. This is again apparent from the medical profession -- members of the fra- ternity are very reluctant to testify against each other, and the delays in holding hearings to investigate alleged incompetence are enormous. The result is that instead of immediately being put out of business by market forces, incompetent doctors suffer almost no penalties because the licensing mechanism masks poor performance from view of the customers and eliminates the associ- ated free market penalties. Is the encouragement of mediocrity, the stifling of innova- tion, and the elimination of true market forces as a test of com- peting technologies in the interests of the community or of the public which licensing is erroneously intended to protect? The answer is clearly no. One of the reasons for the incredible vitality and excite- ment of the computer sciences is the fact that there is almost no regulation of the industry, beyond the general harassment and regulation that all businesses must contend with from government. The rapid rate of technological change is intimately connected with the tremendous freedom that computer scientists have in using new technologies, and which companies have in introducing them. There is no need for any of us to ask the approval of the licensing board to see if a new development is suitable. There is no need to wait until a committee studies a new technique and certifies it for use. We can adopt it and risk its use in the marketplace. One can see the contaminating effects of licensing and regulation on our field by looking at the intersection of computer technology and communications, where one can plainly see that the main obstacles to technological advancement in the communication field -- including the development of public com- puter based message systems -- is the onerous hand of government regulation. (Note that FCC regulation of telecommunications is the functional equivalent of the licensing of individuals under discussion here, applied to groups of people (companies)). There are a number of questions posed in Shamos' message and several issues raised which are worth considering separately. The number of erroneous ideas and false alternatives raised in the few paragraphs of the message approach the density of some of todays memory chips, so I will address them as a class. First, there is the issue of the role of the professional. I for one am not here to serve humanity or some fuzzy notion of the public good; my mind is not public property and neither are the fruits of my effort. No one with a sense of self esteem and integrity can accept the notion that a gang of bureaucrats has the right to tell him that he needs a license in order to use his mind to earn a living. I work for myself, by entering into voluntary relationships with other people -- individuals or or- ganizations, employers or employees. The main body of the message dealt with various problems of assuring the quality of work and of protecting customers from the effects of shoddy work. This is where the false alternatives creep in, for the choice confronting todays user of computer ser- vices is not one of being protected by government licensing versus being at the mercy of inept or unscrupulous programmers. An assertion such as this totally ignores the role of voluntary agreement -- in short, it ignores the mechanism of contracts. If I am seeking the design of a computer system there is a simple way to guarantee that it performs satisfactorily -- deal with a firm or a person who is willing to guarantee his work to a mutu- ally agreed upon extent. If the system performs as specified, he gets paid; if it does not, he fixes it at his own expense, and if that fails the system is rejected and he loses his money. All of the other issues raised in the message -- the credit reporting example, the confidentiality issue, codes of responsibility, malpractice, and adjudication of claims -- can all be handled by voluntary mechanisms called contracts. The notion that government licensing can magically improve the level of technology is absurd; if a guarantee of, say, a per- fectly performing compiler cannot be met by current technology it certainly cannot be met because a license is required to try. Instead, innovation will dry up because no one will be able to take the risk of developing a new compiler. I repeat -- issues of acceptable performance, liability for damages, and the han- dling of disputes can be handled without the immoral and disgust- ing use of coercion by government. In sum, licensing is an assault on the very foundations of the most exciting and fastest growing industry today -- that foundation being the free and untrammeled use of the mind and the offering of products for voluntary acceptance by potential custo- mers. Licensing is an attack on competence and an attack on innovation, and it must be resisted because it is immoral. Gerard J. Rudisin (rudisin@ucla-security)  Date: 25 FEB 1979 0236-EST From: MLK at MIT-MC (Michael L. Kazar) To: HEADER-PEOPLE at MIT-MC I am interested in hearing from people who have used either Vax/VMS or Vax/Unix. I am especially interested in problems people have run into with either VMS or Unix. Specific details on problems and features are especially desired. First-hand knowledge is really especially desired! Please send responses to Kazar@CMUA.  Date: 25 Feb 1979 2155-EST Sender: FURST at BBN-TENEXB Subject: Vax/Unix and VMS From: Furst at BBN-TENEXB (Sheldon R. Furst) To: Kazar at CMU-10A Cc: Header-People at MIT-MC Message-ID: <[BBN-TENEXB]25-Feb-79 21:55:27.FURST> Well, to begin with, I presume that when you refer to VAX/Unix, you refer to version 7 release from Bell/Western. This is presently running only at UC Berkeley, under a special deal with Bell (UC is designated the Homdel test site). It is a good guess that this will not be available commercially for quite a while (to my knowledge, Western still has yet to release 11/XX version 7 licenses). For more information, contact RJF@MC or WNJ@MC. At Lawrence Berkeley Laboratory we have one VAX with a second one arriving in two weeks. Both run VMS 24 hours a day, with a critical systems maintenance contract with DEC. We have lots of projects using this machine, including many that really get into the guts of the OS (spawn primitives, etc). For more information about this, contact Dennis Hall (Hall@BBNB). Also, Joel Moses and his group are doing a lot of nifty things at MIT (such as a C compiler under VMS). Contact JM@MIT-MC. Lastly, what does this have to do with headers? I think this message would have been more appropriately sent to Network-Liaisons (c/o Jake Feinler). -- Sheldon  From: dcrocker at Rand-Unix Date: Mon, 26 Feb 79 14:20-PST To: Header-People at mit-mc cc: Gaines at Rand-Unix Subject: addition to Header-People mailing list ------- Forwarded Message From: Gaines at Rand-Unix Date: 26 Feb 1979 at 1346-PST To: Dcrocker at Rand-Unix Subject:Header people conference Dave, How do I get on the equivelent of MSGROUP for headers? I'm getting interested enough in the subject that I'd like to be added. If you can take care of this simply by forwarding this request to the right person, that would be good. Stock ------- End of Forwarded Message  Date: 27 Feb 1979 1831-EST From: Rick Gumpertz at CMU-10A Subject: ITS headers To: RMS at MIT-AI CC: Header-People at MIT-MC Message-ID: <27Feb79 183103 RG02@CMU-10A> When oh when will you fix your mail programs to not let ITS headers out over the Arpanet?? Presumably the mailing daemon could automatically spot and convert your headers! Rick - - - - Begin forwarded message - - - - RMS@MIT-AI 02/27/79 19:56:32 To: msggroup at MIT-ML Veiled and vague threats, such as Pine's threats that some unidentified "real" users of our systems would force us to change our ways, are really sinking very low. I'd like you to identify the people who are going to do this, and then explain what will stop us from ignoring them. Even if such an event does come to pass, it won't prove anything about the morality issues. Similar events occur every day on our streets and in our parks. - - - - End forwarded message - - - -  Date: 27 Feb 1979 1758-PST Sender: GEOFF at SRI-KA Subject: Re: ITS headers From: the tty of Geoffrey S. Goodfellow To: rg02 at CMUA Cc: RMS at MIT-AI, Header-People at MIT-MC Message-ID: <[SRI-KA]27-Feb-79 17:58:25.GEOFF> In-Reply-To: <27Feb79 183103 RG02@CMU-10A> Reply-to: Geoff @ SRI-KA I'v brought this very item to the attention of BUG-MAIL@MIT-AI a few times, and gotten back replies such as "one of these days" or even being called an asshole by Dave Moon. Perhaps people who call others assholes will stop being them themselves, and get around to fixing long standing lossages that cause others grief.  Date: 27 FEB 1979 2109-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: ITS Headers To: HEADER-PEOPLE at MIT-AI I don't think there is anyone here who maintains COMSAT any more. I think therefore that you are out of luck. Probably nobody is interested in learning how to work on the mailer just do do something for the sake of other sites.  Date: 27 FEB 1979 2123-EST From: RMS at MIT-AI (Richard M. Stallman) To: HEADER-PEOPLE at MIT-AI I would like to apologize on behalf of anyone who called people "assholes" just because theuy'd like not to get ITS headers. That's a reasonable thing to want if you aren't on ITS, and it doesn't make them assholes. But that doesn't oblige us to put it very high on the list of things to be done.  Date: 28 Feb 1979 2227-PST Sender: GEOFF at SRI-KA Subject: [MOOERS at BBN-TENEXA: Re: Replying to messages with spaces...] From: the tty of Geoffrey S. Goodfellow To: Header-people at MC Message-ID: <[SRI-KA]28-Feb-79 22:27:17.GEOFF> Reply-to: Geoff @ SRI-KA Why HERMES cant reply to CMU messages. Begin forwarded message =========================== Mail from BBN-TENEXA rcvd at 28-Feb-79 2222-PST Date: 28 Feb 1979 2337-EST Sender: MOOERS at BBN-TENEXA Subject: Re: Replying to messages with spaces inthe from field. From: MOOERS at BBN-TENEXA To: GEOFF at SRI-KA Cc: MYER, MOOERS, AIRPLANES, Mooers Message-ID: <[BBN-TENEXA]28-Feb-79 23:37:41.MOOERS> In-Reply-To: <[SRI-KA]28-Feb-79 20:02:26.GEOFF> Neither Hermes nor SNDMSG will accept a To: field with the form To: Brian Reid at CMU-10A whether or not a REPLY command is used. Since CMU is the only host generating this type of From: field, and since ARPA is not pushing a strict enforcement of RFC733 if it means making disruptive changes in current systems, and since we don't have support for this kind of change anyway, we are not planning to do anything about it for the moment. ---Charlotte =========================== End forwarded message  Date: 5 MAR 1979 2217-EST From: RMS at MIT-AI (Richard M. Stallman) To: header-people at MIT-MC If I found :MAIL prompt me for a subject, I would probably be taken aback and need half a minute to figure out what I was doing again. To eliminate this problem I would train myself to ignore it. The result would be that the first line of my message would appear as the "subject". This might not be so bad. However, if it were going to do that, I would rather not have it bother me about it. I also wouldn't want the fact that the first line of my message was thought of as the "subject" to prevent me from rubbing out back into it in the way I otherwise could. I still think, though, that people should change mail readers to report the first line of the message as the subject, in summaries, if that's what they want. That is what ITS does. Once in a while I have something I consider a useful subject, but for the most part I don't have anything that feels worth supplying and subjects in messages I receive are usually information-free. Therefore, I think that making a mail sender bother the user for a subject will just get in the way of getting work done.  Date: 5 MAR 1979 2025-PST Sender: STEFFERUD at USC-ISI Subject: RMS on why bother? From: STEFFERUD at USC-ISI To: RMS at MIT-AI Cc: header-people at MIT-MC Message-ID: <[USC-ISI] 5-MAR-79 20:25:47.STEFFERUD> In-Reply-To: Your message of 5 MAR 1979 2217-EST MsgGroup contributions are kept in more or less organized form for later reference. did you not know you are talking into a recording device when you flame into MsgGroup? Cheers - Stef - - - - - - - - - - - - - - - - - - - - 453 chars/ 3 Date: 5 MAR 1979 2218-EST From: RMS at MIT-AI (Richard M. Stallman) - - To: Stefferud at USC-ISI Now that we have CBF;MSG LOG, why is it necessary for you to do any editing on it? Why not just let people read it as is? I hope it doesn't make you feel bad to be "replaced by a computer", but it sounds like you don't think that task is much fun, anyway. Does the transcript get printed and published? *** TRAILER *** Mail from MIT-AI rcvd at 5-MAR-79 1919-PST *** END /# 3  Date: 6 March 1979 05:53 est From: Frankston.Frankston at MIT-Multics (Bob Frankston) Subject: keywords To: header-people at MIT-MC Message-ID: <790306105320.324308 at MIT-Multics> {Hmm, flaming appears to be bacck on heade-people for the moment} I'd like it if keywrods were supplied in a ddition to subject to make it easier to keep trac of the multiple threads running through my mail and to give me, the recipient the ability to add more keywords. Alas, I do not expect anyone here to implement it. I have implemented it on my own mail system, unfortunately on an unneted VM system and find it a win.  Date: 6 March 1979 09:21 est From: Sibert.PDO at MIT-Multics Subject: Re: keywords To: Frankston.Frankston at MIT-Multics (Bob Frankston) cc: header-people at MIT-MC In-Reply-To: Msg of 03/06/79 05:53 from Bob Frankston Message-ID: <790306142113.819920 at MIT-Multics> Yup. There should be some such ability. Not right now, though. -- wos  Date: 6 March 1979 09:24 est From: Sibert.PDO at MIT-Multics (W. Olin Sibert) Subject: last message, from me To: header-people at MIT-MC Message-ID: <790306142448.577463 at MIT-Multics> Please ignore it. It is a demonstration of the slightly less than winning mail system I have implemented here. -- wos  Date: 6 MAR 1979 0836-PST From: POSTEL at USC-ISIB Subject: Subject Line To: Header-People at MIT-MC Does the fact that a message does not have a subject line have any correlation with the senders not knowing what he is saying until after the message is sent (if then) ? --jon. -------  Date: Wednesday, 7 Mar 1979 0118-EST From: Brian K. Reid Subject: RFC733 To: Header-People at MC Message-ID: <07Mar79 011816 BR10@CMU-10A> Sieg Heil! - - - - Begin forwarded message - - - - Date: Tuesday, 6 Mar 1979 1820-EST From: Howard Wactlar at CMU-10A (S300HW09) Subject: ARPA "order" To: RDMAIL at CMU-10A, bajzek at CMU-10A Message-ID: <06Mar79 182009 HW09@CMU-10A> Remailed-To: RdMail-Maintainers: (RDHACK.DST[A800RD00]) Rdmail at CMU-10A, Craig Everhart at CMU-10A, David Lamb at CMU-10A, Philip Lehman at CMU-10A, Bruce Nelson at CMU-10A, Brian Reid at CMU-10A, Karlton @ PARC-MAXC, Sapsford @ PARC-MAXC; Remailed-From: RdMail at CMU-10A Remailed-Date: Wednesday, 7 Mar 1979 0058-EST People, We have been officially asked by ARPA, through Duane Adams, program manager in their IPT office, to eliminate two-name from fields in mail we transmit. There was appropriate recognition that it was within the defined 733 spec, but that NOBODY benefitted by our using it. How about going back to placing a period between first and last names instead of a space when both first and last names are non-empty (i.e. no period if the first name is empty). How about getting it done as soon as reasonable. We made our point, now lets concede the issue and give the others on the net what they can all handle. If you have any technical or philosophical difficulties with the change, come talk to me (or send flaming mail if that makes you feel better). Thanks much, Howard - - - - Begin forwarded message - - - - Date: 6 MAR 1979 0703-PST Sender: ADAMS at USC-ISI Subject: Re: And Hermes' not handling multi-word mailbox names From: ADAMS at USC-ISI To: dcrocker at RAND-UNIX Cc: Adams, Farber at SRI-KA, Wactlar at CMU-10A, Mooers at BBNA Message-ID: <[USC-ISI] 6-MAR-79 07:03:20.ADAMS> In-Reply-To: Your message of Sat, 3 Mar 79 15:06-PST Dave, Requesting a change to Hermes to handle a two-name from field is exactly the kind of change I want to avoid requesting maintainers of message systems to have to incorporate. Here the corrective action is obvious-- those who use two-name from fields will remove them from their message systems. I have already asked Howard Wactlar of CMU to remove this feature from their system. Duane - - - - End forwarded message - - - - - - - - End forwarded message - - - -  Date: Tuesday, 6 Mar 1979 1820-EST From: Howard Wactlar at CMU-10A (S300HW09) Subject: ARPA "order" To: RDMAIL at CMU-10A, bajzek at CMU-10A Message-ID: <06Mar79 182009 HW09@CMU-10A> Remailed-To: RdMail-Maintainers: (RDHACK.DST[A800RD00]) Rdmail at CMU-10A, Craig Everhart at CMU-10A, David Lamb at CMU-10A, Philip Lehman at CMU-10A, Bruce Nelson at CMU-10A, Brian Reid at CMU-10A, Karlton @ PARC-MAXC, Sapsford @ PARC-MAXC; Remailed-From: RdMail at CMU-10A Remailed-Date: Wednesday, 7 Mar 1979 0058-EST Remailed-To: MsgGroup at ML, Header-People at MC Remailed-From: RdMail at CMU-10A Remailed-Date: Wednesday, 7 Mar 1979 0124-EST People, We have been officially asked by ARPA, through Duane Adams, program manager in their IPT office, to eliminate two-name from fields in mail we transmit. There was appropriate recognition that it was within the defined 733 spec, but that NOBODY benefitted by our using it. How about going back to placing a period between first and last names instead of a space when both first and last names are non-empty (i.e. no period if the first name is empty). How about getting it done as soon as reasonable. We made our point, now lets concede the issue and give the others on the net what they can all handle. If you have any technical or philosophical difficulties with the change, come talk to me (or send flaming mail if that makes you feel better). Thanks much, Howard - - - - Begin forwarded message - - - - Date: 6 MAR 1979 0703-PST Sender: ADAMS at USC-ISI Subject: Re: And Hermes' not handling multi-word mailbox names From: ADAMS at USC-ISI To: dcrocker at RAND-UNIX Cc: Adams, Farber at SRI-KA, Wactlar at CMU-10A, Mooers at BBNA Message-ID: <[USC-ISI] 6-MAR-79 07:03:20.ADAMS> In-Reply-To: Your message of Sat, 3 Mar 79 15:06-PST Dave, Requesting a change to Hermes to handle a two-name from field is exactly the kind of change I want to avoid requesting maintainers of message systems to have to incorporate. Here the corrective action is obvious-- those who use two-name from fields will remove them from their message systems. I have already asked Howard Wactlar of CMU to remove this feature from their system. Duane - - - - End forwarded message - - - -  Date: 7 Mar 1979 0218-EST From: Richard H. Gumpertz at CMU-10A Subject: Re: ARPA "order" and white-space in names Sender: Rick Gumpertz at CMU-10A To: Howard Wactlar at CMU-10A (S300HW09) CC: ADAMS at USC-ISI, MSGGROUP @ MIT-ML, Header-People @ MIT-MC, Newcomer at CMU-10A, Reid at CMU-10A Reply-To: Gumpertz (who has a first name AND a middle name!) at CMU-10A Message-ID: <07Mar79 021843 RG02@CMU-10A> In-Reply-To: <06Mar79 182009 HW09@CMU-10A> Damn it this annoys me. I have two names (well really three) and there is no period after the first. There is both a period and white-space after my middle initial. Although I have been compliant (complacent?) enough to list only my last name in mail addresses for me, I am seriously considering changing that just to be rebellious. Any time one requests that one avoid a standard, one is in a very questionable position. I just can't believe that some hacker on TENEX can't fix the problem somehow. Perhaps by internally changing spaces to something like # when queueing mail and then changing them back when actually transmitting it. (I am working under the assumption that the problem is that queueing is via file names which can't include blanks, or some such thing -- my best recollection of an old explanation I once saw.) Being depersonalized by a computer is bad enough; being stomped on one more time by TENEX is absolutely infuriating. Perhaps it is appropriate that TENEX was invented by a company whose initials can stand for BIG BAD NEIGHBOR. I have not been this mad in some time. What the hell do we develop standards for, if we will be asked not to use them? Richard H. Gumpertz An aside to Charlotte Mooers: what does Calvin think of all this?  Date: Wednesday, 7 March 1979 03:21-EST From: MTRAVERS at BBN-TENEXD (Mike Travers) Subject: Re: ARPA "order" and white-space in names To: Gumpertz at CMU-10A Cc: Howard Wactlar at CMU-10A, ADAMS at USC-ISI, MSGGROUP at MIT-ML, Cc: Header-People at MIT-MC, Newcomer at CMU-10A, Reid at CMU-10A In-reply-to: Your message of 7-Mar-79 0218-EST In point of fact, TENEX and TOPS20 are perfectly capable of having spaces in file names, by quoting them in the same manner in which lowercase chars are quoted. Making the mail systems such as HERMES capable of generating such files is another matter, of course. Also in regards to RFC733 and ARPA policy, I was told (indirectly) that ARPA does NOT plan to make this a bonafide, standardized standard, and they are going around telling people not to bother upgrading their software to handle/generate RFC733 messages. The mailsystem I use has just been modified to conform to RFC733, and I find it extremely annoying that now that I have conformed to the standard, I get complaints from HERMES users that they can't parse my messages, and HERMES people tell me they are not supposed to fix it. Does anyone know more about this situation? --Mike -------  Date: 7 MAR 1979 0635-EST From: CBF at MIT-MC (Charles Frankston) Subject: Subject fields To: HEADER-PEOPLE at MIT-MC As a random aside, for subjects without message fields, the ITS Rmail program does use the first line of the message as the subject for a summary request. This usually works out quite well. It goes through a little pain to skip over whitespace and stuff and try and get a good first text line though.  Date: 7 MAR 1979 0643-EST From: CBF at MIT-MC (Charles Frankston) Subject: keywords To: HEADER-PEOPLE at MIT-MC, Frankston.Frankston at MIT-MULTICS Keywords are often local to the eye of the beholder. I think perhaps it is more useful if the reciepient chooses his own keywords to file it under after he has read the message.  Date: 7 MAR 1979 1029-EST From: Charles Frankston at MIT-MC Sent-by: CBF at MIT-MC To: Richard H. Gumpertz at CMU-10A, Howard Wactlar at CMU-10A CC: HEADER-PEOPLE at MIT-MC, MSGGROUP at MIT-ML CC: Joe Newcomer at CMU-10A, Brian Reid at CMU-10A, ADAMS at USC-ISI If what is being said about this "ARPA order" is true, I find it disturbing. Firstly, RFC733 was one of the most democratically adopted standards I know of. I don't really care if it has been "blessed" by the Arpa bureacracy or not. Its design at least had widespread input and comment. The standard may not be universally loved, but it has been pointed out before that almost all of the non-Tenex/Tops-20 sites have taken steps toward adhereing to it. Now, we hear that some bureaucrat has ordered that CMU cannot do something that RFC733 specifies as legal, presumably because his (and perhaps other) mail reading program cannot handle them. Also presumably, these mail reading programs run on Tenex/Twenex, the operating system Arpa has tried so hard to get CMU, MIT and Stanford to run as the network standard operating system. Fine network standard operating system. The system with the most installations on the network, that in total most recieve the most Arpa support, cannot find the manpower to correctly implement a widely adopted network standard. I would like to hear Arpa's official position clarified soon. I think it is a very poor idea for them to simply decide that one aspect of the standard is null and void. That jeapordizes the whole idea of decent coherent standards and threatens to push us back to the dark ages before RFC733 when a new mail system implementor could first review a bunch of contradictory, incomplete and confusing standards, and then have to take a survey of the network to find out how many different ways it was implemented. I should point out that the change being demanded is retrogressive. It takes away capabilities. I point this out mainly to differentiate this "order" with the request the ITS and Multics sites have been making to support a progressive change to allow structured recipients. (Note, the structured recipient request was made during the drafting of RFC733 and ignored by the committee supposedly chosen by Arpa to draft the standard. I presume no one asked for the space restriction then, because I cannot believe that committee would have adopted something so difficult to implement on Tenex, but perhaps I am wrong). In any event, I will admit the point to be minor, and CMU could probably live without it. In fact, the ITS rmail program never was modified to reply them correctly either, because the change was actually somewhat painful. This dicussion have motivated me to rectify that. As of today, ITS Rmail will correctly reply to CMU headers. The pain proved to be about 2.5 hours worth of work. Thanks to Dave Moon, MC will now recieve incoming mail to addresses with imbedded spaces (he did that in about 5 minutes I guess). The rest of the ITS sites should do the same in a few days.  Date: 7 Mar 1979 1048-EST From: Rick Gumpertz at CMU-10A Subject: new ITS RMAIL To: Charles Frankston at MIT-MC CC: Header-People @ MIT-MC Message-ID: <07Mar79 104824 RG02@CMU-10A> In-Reply-To: Charles Frankston's message of 7 Mar 79 10:29 By the way you didn't respond correctly -- the correct response would have gone to Gumpertz at CMU-10A not Richard H. Gumpertz at CMU-10a. My note had a REPLY-TO field in it. Another little test of people's mail systems that I was running! Rick  Date: 7 MAR 1979 1129-EST From: EAK at MIT-MC (Earl A. Killian) To: HEADER-PEOPLE at MIT-MC I've been wondering in all the flurry of messages about flushing RFC733 whether that's actually more work than fully adopting it. For example, did the people that asked CMU to stop sending its two word names consider the possibility that it might be more difficult stop what they're doing now than it would be to fix Hermes? Btw, I'd be interested to hear from the CMU people if ARPA is going to provide funding for them to remove their two (or more) word names from ARPAnet headers. If the Hermes people can use "lack of funding" as an excuse for not implementing them, then can't CMU use the same excuse for not de-implementing them?  Date: 7 Mar 1979 1114-PST Sender: GEOFF at SRI-KA Subject: ARPA "orders", white-spaces, RFC733 and HERMES. From: the tty of Geoffrey S. Goodfellow To: Adams at ISI Cc: Everhart at CMUA, Lamb at CMUA, rdmail at CMUA, Cc: Newcomer at CMUA, MSGGROUP at ML, Header-People at MC Message-ID: <[SRI-KA] 7-Mar-79 11:14:21.GEOFF> Reply-to: Geoff @ SRI-KA Duane; I would like to ask you to please reconsider your asking CMU to eliminate the two-name field (also referred to as the "white-space") from mail they transmit. Currently what CMU does is completely legal within the "THE STANDARD" -- RFC733. I think it is rather unjust of you to ask them to remove the two-name field from mail they send just because HERMES (which, by the way, I use as well) cannot parse their headers when you try to use the REPLY command on such a message, but rather the correct and right approach would be to have the HERMES maintainers (BBN) modify HERMES to handle the "completely legal" headers they send. This brings me to the point of HERMES and RFC733 in general. Currently, I believe that HERMES does not support RFC733 at all, and in fact, in some ways actually violates it! An example of this would be if you were to REPLY to this message, HERMES would get my name NOT from the "REPLY-TO:" field as it should, but from the "SENDER:" field, which, according to the standard, is explicitly prohibited. Hence, i think it is rather important that HERMES be made 733 compatible. If that was the case today, you wouldn't have the problem you now have with CMU. One of the big problems with getting this done as I have come to understand it is that BBN will not touch HERMES or improve it unless you wave the almighty dollar (aka funding) in front of them. I for one would be curious to know just how many sites that do support RFC733 were funded by ARPA to do so, or even more interesting would be just how many sites that have any type of a mail system at all were funded by ARPA to design, code, debug, implement, maintain and have a running mail facility that allows them to communicate with users on their host computer as well as with the rest of the network? I would suspect there is only one possible and that being TENEX, even though i understand SNDMSG (first TENEX mail sending program) came about originally just as every other mail system on the network: Out of the pure NEED for one user to communicate with another, and then when hooked up to the network, the sites mail system wizard spent his own time, or on the time of the org. he works for making his mail system talk to the ARPANET. On the subject of RFC733, simply put/asked: JUST IS IT A STANDARD OR NOT? Jon Postel says it is, and he is the keeper and final word on standard right or wrongs, that i am currently aware of. Yet, others have told me, and i have heard rumblings from various corners of the net, that NO , 733 is not a standard. Please, tell us, for once, and for all, which it is? I presume, at least, that you are the person who has that say-so? Lastly, on the subject of HERMES, 733, et al. If BBN is unwilling to modify HERMES to handle CMU's two-name from field (and support RFC773 totally, without mega dollars flowing forth) at least have BBN make the sources for HERMES available so that gainful hackers like myself and others who enjoy doing things out of the pure interest of network standardization and for the sheer "fun of it" can FREELY do so, without have to tolerate institutions that refuse to do such things because they are not funded to. geoff  Date: Wednesday, 7 Mar 1979 1658-EST From: David Lamb at CMU-10A Subject: The ARPA whitespace "order" Sender: RdMail at CMU-10A To: Header-people @ mit-mc, MsgGroup @ usc-isi CC: Wactlar at CMU-10A, Everhart at CMU-10A, Lehman at CMU-10A, Nelson at CMU-10A Message-ID: <07Mar79 165838 RD00@CMU-10A> CMU will be complying with ARPA's request to remove whitespace in names generated by our RDMAIL program. I hope to head off what could turn into an acrimonious debate by explaining why we are doing so. When CMU converted to full compatibility with RFC733, we also began to make use of a number of the facilities that a number of other sites hadn't implemented. For example, we supplied an option to include a user's login PPN as a comment, for cases where someone had many accounts and wanted to let his friends see which hat he was wearing this week. Some sites didn't parse that sort of thing, so people who wanted to communicate with such sites simply turned off the option. We also decided to use a person's full name as the "recipient" portion of a local mail name. We have many cases where people with the same last name both have accounts. Having the two names separated by a space rather than a dot seemed like a nice piece of human engineering that was allowed by the standard, at least as we read RFC733. Unfortunately, a lot of other sites didn't see the standard as allowing that, and so didn't include it in their mail systems (I am told it isn't just Hermes, so I see no good reason for singling Hermes out. It merely happens that Hermes users were more vocal in their complaints). We weren't simple ordered by ARPA to make the change. It was discussed with our local site manager. CMU is the only site on the net which generates recipients with imbedded spaces. From the point of view of anyone managing time or money, it makes more sense to have one site make a change rather than many, especially if the change is as small as this one is (I expect to take a total of about 1/2 hour to make the change). It bothers me to some extent that ARPA seems to be "revising" the "standard", making "retrogressive" changes. I sympathise with anyone who feels like their democratically-arrived-at standard is being changed by apparently arbitrary bureaucratic fiat. But there is a whole other way of looking at the situation. From the point of view of the ARPA people who made the request, there was a protocol problem that was interfering with people's work, making some network communication difficult. Given the problem, the least expensive way to fix it was to ask the single site to change, rather than the many. It is certainly possible to bewail the degree to which people violate the RFC733 standard. On the other hand, it should be obvious from the recurrent heated debates that RFC733 is easy to misinterpret. It's easy to point the finger at someone and say "you are violating paragraph 3.4.1 of the standard", but that still leaves the practical everyday problems of finding someone with time, energy, and willingness to do the programming to make the change. I'm willing to fight for conformity when the piece of the standard in question is important to me, but parenthesised comments and blanks in names just aren't significant enough to me to fight for. I also can't believe it will get us anywhere to accuse Hermes sites of laziness (or whatever). Even if Hermes is the only system that has trouble with CMU headers, the fact that the problem has to be fixed on many sites means it's more work than fixing it here. Even if one site changes the source and passes on the change, there's more work. I am speaking here of this one change, which is probably fairly easy to make at either end; a big enough improvement in functionality would make that kind of multisite change worthwhile. I don't think that anyone need worry too much that ARPA might be "sabotaging" RFC733. The requested change is small; it's a direct result of the January meeting; it's one of the few RFC733-related problems that have really been interfering with communication. I'd rather not be included in direct replies to this note; I see everything that gets sent to the CMU RDMAIL account, which includes everthing that goes to the MSGGROUP and HEADER-PEOPLE mailing lists. David Alex Lamb  Date: Wednesday, 7 Mar 1979 1743-EST From: Brian K. Reid Subject: Header People, RFC733, etc. To: Header-people @ mit-mc, MsgGroup @ usc-isi CC: Wactlar at CMU-10A, Everhart at CMU-10A, Lehman at CMU-10A, Nelson at CMU-10A Message-ID: <07Mar79 174335 BR10@CMU-10A> In-Reply-To: <07Mar79 165838 RD00@CMU-10A> I am pretty bummed out at all of the time that I have wasted on this "standard", and I suspect that Dave, Jon, and company are even more bummed out by it all. I think that CAHCOM had absolutely no business soliciting help from the Arpanet community in the design of this standard, letting hundreds of man-hours get spent fine-tuning a very nice, reasonably consistent, and very usable standard, and then abandoning it. Human-readable but machine-processed ASCII headers are the wrong way to do computer mail anyhow; perhaps the general low quality of the current Arpanet mail systems that is resulting from our having to be compatible with this incompetent Hermes program will ultimately end up being a blessing, resulting in a redesign instead of an incremental upgrade. Brian  Date: 7 March 1979 20:23 est From: Frankston.Frankston at MIT-Multics (Bob Frankston) Subject: message ids To: header-people at MIT-MC Message-ID: <790308012331.101307 at MIT-Multics> It's been a long time since I've flamed about message ID's. I've modified my personaal mail checking program to use some herutistics to catch duplicates and it has worked fine. I have just received a letter sent without a subject line from EAK at MIT-MC to header-peole and redistributed by GEOFF at SRI-KA to MSGGRP. It would have been nice to have a message-id to give me a reasonable chance of detected the duplication. BTW, now that people have seemed to standardize on using both header-people and msggroup, why do we have both?  Date: 7 Mar 1979 2230-EST From: Rick Gumpertz at CMU-10A Subject: Re: The ARPA whitespace "order" To: David Lamb at CMU-10A CC: Header-People @ MIT-MC Message-ID: <07Mar79 223057 RG02@CMU-10A> In-Reply-To: <07Mar79 165838 RD00@CMU-10A> David.- Just.for.the.record,.I.think.you.are.making.a.big.mistake. ................Rick  Date: 7 Mar 1979 2240-EST From: Rick Gumpertz at CMU-10A Subject: RFC733 compliance To: Header-People at MIT-MC Message-ID: <07Mar79 224039 RG02@CMU-10A> I.have.a.couple.questions.that.might.be.able.to.elicit.some.useful.information: 1).Why.can't.Hermes.be.easily.modified.to.handle.the.spaces?..What.is ...the.technical.obstacle? 2).Who.maintains.Hermes?..Is.it.multiple.persons?..Have.they.no.funding ...or.is.that.a.red-herring? 3).What.systems.besides.Hermes.have.trouble.with.white-space,.if.any? ................Rick  Date: 7 MAR 1979 2311-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: Header People, RFC733, etc. To: MsgGroup at USC-ISI, Header-people at MIT-MC CC: Wactlar at CMU-10A, Everhart at CMU-10A, Lehman at CMU-10A CC: Nelson at CMU-10A Using the first name as well as the last one is certainly a good idea. It's one of Tenex's real losses that (at most sites) it ALMOST lets you refer to a person by his last name - but maybe you have to use his initial as well, and how can anyone predict? Maybe his login is his last name, or maybe it's his initial and last name. Whereas ITS and CMU, where the login and last name are usually or always different, don't have available any easy way out that only almost works, so they have special provisions that really do let you refer to a person by last name in mail. But that still leaves a problem of disambiguation. Only CMU has implemented a reasonable solution to the problem. I think that the CMU way is the only really right way to deal with it: let a person give the last name, or both names, and win as much as possible with whatever it gets. What COMSAT does is, if you send a message to an ambiguous lastname such as Frankston, send the message to all of the possibilities, which solves things for the most part but is clearly not right. To ask for the only winning solution to the problem to be banned because it is ahead of the rest of the world is stifling and wrong. And I can speak as one whose mail reader didn't (until yesterday) understand CMU headers: I would rather have my own system lose on them indefinitely and hope to make it win someday (as it finally does) than ask someone else to lose for my sake. The Tenex people who aren't willing to do as much for someone else's winning idea deserve no sympathy. The way to resolve such disputes between different systems is simple: change whichever ones don't do things right. Assuming you believe that progress beyond the current perfection is possible.  Date: 7 MAR 1979 2319-EST From: JNC at MIT-AI (J. Noel Chiappa) Subject: Livable Computers & all that... To: Rick Gumpertz at CMU-10A Remailed-To: MsgGroup @ MIT-ML, Header-People @ MIT-MC Remailed-From: Rick Gumpertz at CMU-10A Remailed-Date: 7 Mar 1979 2321-EST Incredible!! We finally get a computer mail system that will handle peoples NAMES, for God's sakes, and it gets flushed. Foo! We DESERVE to be looked at as inhuman etc. etc. Noel PS Keep.it.up.withe.the.".".action..I.love.it!!  Date: Wednesday, 7 Mar 1979 2351-EST From: David Lamb at CMU-10A Subject: CMU mail names Sender: RdMail at CMU-10A To: RMS at MIT-AI (Richard M. Stallman) CC: MsgGroup @ usc-isi, header-people @ mit-mc Message-ID: <07Mar79 235139 RD00@CMU-10A> In-Reply-To: Richard M. Stallman's message of 7 Mar 79 23:11 ARPA isn't really asking us to get rid of our first names (at least, as I interpret the request); they merely want us to send David Lamb at CMU-10A as David.Lamb at CMU-10A which, as you might suspect, is a trivial change for us to make. We still have some loopholes we don't intend to change that allow C410BR10 to appear as "Brian K. Reid" instead of "Brian.Reid", but that comes down to a personal decision on the part of individual people to generate headers that Hermes can't handle. All we are doing is making the default behaviour something that (a) Hermes can handle (b) isn't too different from what we have now. I do appreciate your praise of our mail names, though. Even though our login names are horrid, our Mail system, Finger program, and Systat all manage to treat people as names rather than bizarre character sequences. There's even some hope of eventually being able to log in via name rather than by CMU PPN, but that's a lot more work than we can foresee in the near future. It's all done via table lookup in a large binary file, but even so seems to work well and reasonably efficiently.  Date: 8 Mar 1979 0015-EST From: Rick Gumpertz at CMU-10A Subject: Redistribution To: GEOFF at SRI-KA CC: Header-People at MIT-MC, MsgGroup @ mit-ml Message-ID: <08Mar79 001529 RG02@CMU-10A> Geoff - I tend to choose my destinations carefully. In particular, I saw no reason to distribute some of my latest mail to MsgGroup. I am trying to keep down the amount of junk mail. Please refrain from redistributing mail unless you have a good reason. Rick  Date: 8 MAR 1979 0016-EST From: TVR at MIT-AI (Tovar) Subject: You are not alone To: Rick Gumpertz at CMU-10A CC: HEADER-PEOPLE at MIT-AI SAIL was also an early implemention of 733. And... ----- Date: 7 Mar 1979 2021-PST From: Hans Moravec To: TVR at MIT-AI [Text of message omitted.] ----- As far as i know, there is currently no maintainer of SAIL's mailer. The problem with spaces in names is of little personal concern to me as i have problems with bureaucrats who insist that there must be a space in a person's name. Nonetheless, i would certainly hate to have to send mail to John.L.Smith or Brian.K..Reid. All i can say to HERMES users is: "You think this is bad, just wait until you have to cope with inter-network mail!" --- Tovar P.S. In reply to Msd-id comment: Many of the headers i've seen lately are twice as long as the messages they contain!  Date: 7 Mar 1979 2121-PST Sender: GEOFF at SRI-KA Subject: Re: Redistribution From: the tty of Geoffrey S. Goodfellow To: rg02 at CMUA Cc: Header-People at MIT-MC, MsgGroup at MIT-ML Message-ID: <[SRI-KA] 7-Mar-79 21:21:30.GEOFF> In-Reply-To: <08Mar79 001529 RG02@CMU-10A> Reply-to: Geoff @ SRI-KA good reason: no one on header people would beable to answer your questions about HERMES policy issues, re: why.cant.hermes.be.modified.to.handle.spaces.and.who.maintains.hermes. things.for.people.not.on.header.people,like.adams.and.other.bbn.folk.  Date: 8 Mar 1979 0404-PST From: Mark Crispin Subject: A plea for sanity To: Header: ;, Header-People at MIT-MC, MsgGroup at MIT-ML Please, let's stop sending messages to both MsgGroup and Header-People. It is getting awfully silly getting four or five copies of the same message. Let's leave outrageous flaming messages with Header-People where they belong and not assault MsgGroup with the crud. I really think that MsgGroup exists for other purposes than flaming. My mailbox is growing on the average of 50 messages/day due to this multi-forwarding. And please, no comments about message-id's; instead of kludging around extra message copies let's not send them in the first place!! I hope I'm not going to get infinite retributions about being hypocritical by sending this message to both. I might as well do it rather than let somebody else forward it with HERMES and add three or four more header lines to the nth extra copy. -- Mark -------  Date: 8 Mar 1979 1326-PST From: Zellich at OFFICE-1 Subject: Re: ARPA "order" To: Wactlar at CMU-10A cc: Header-People at MIT-MC Please clarify a point for me -- Is it only the form Howard Wactlar at CMU-10A that they want changed to Howard.Wactlar at CMU-10A or do they ALSO want Howard Wactlar changed to Howard.Wactlar ? Rich -------  Date: 8 Mar 1979 2:18 pm (Thursday) From: Karlton at PARC-MAXC Subject: White space in tokens To: Header-People at MIT-MC, MsgGroup at USC-ISI cc: Wactlar at CMU-10A, RdMail-Maintainers: (RDHACK.DST[A800RD00]) Rdmail at CMU-10A, Craig Everhart at CMU-10A, David Lamb at CMU-10A, Philip Lehman at CMU-10A, Bruce Nelson at CMU-10A, Brian Reid at CMU-10A, Karlton @ PARC-MAXC, Sapsford @ PARC-MAXC; People and Flamers, I have enjoyed the conversations over the past couple years going through Header-People and MsgGroup and I wish once again to add a comment. A great deal of time and effort went into constructing RFC733. Many hard feelings were smoothed only due to the passage of time. The important thing is that a useable (not the end-all, be-all) standard was generated. This was done under the guise that the final result would become a recognized standard. I was assured of this more than once. In fact, my introduction to Header-People was because of complaints that CMU was not in compliance with RFC561. RFC724, a precursor to 733, even had as a title "Proposed Official Standard for the Format of ARPA Network Messages." When I added 733 compatible headers to RdMail I really thought that it had become "Official". It is not necessary to have CMU prohibit the sending of mail that contains white space in the delivery tokens. The user can specify how he/she wants the name to appear in the outgoing messages. (There even exists a profile switch that will cause the CMU programmer-number to be used as the delivery token.) Any user at CMU that wishes to generate First.Last instead of First Last can do so (and is not a particularly onerous task, but does involve the spending of the time to do so). Allow me to quote from the November 1978 version of the RdMail manual. If you do a lot of communicating with people at TENEX sites, it is suggested that you have no embedded blanks in your name-- use periods instead. This was done since the then existing systems (soon to be replaced!) could not cope with embedded spaces. I really am at a loss as to why HERMES is not fixed to handle this spaces. It was undergoing development at the time that 733 came out. It was written with the programming technology of 1975. I question the technical competence of a project leader that would allow the parser to be so inflexible that making this seemingly trivial change is a hard task. What has happenned to pride of craftmanship? No one builds bug free systems (in the technology available right now), especially those that have to deal with user interface issues. It has been my experience that any program that is being used all the time grows as its users' needs expand. Sometimes it is overwhelmed and a new program has to be written to take its place. PK p.s. RdMail-Maintainers: I request that you do not change RdMail so that people can no longer send out their names in the format that they wish. You might wish to undertake an education task at CMU, but please do not remove that feature from a program that I still consider (perhaps no longer rightfully) mine. If you still think that it is necessary to remove that feature, then I implore you to poll your users and ask them if they are willing to do without because those that communcate over the net are unwilling to learn how to set their user profile.  Date: 8 Mar 1979 1958-PST Sender: GEOFF at SRI-KA Subject: Re: White space in tokens From: the tty of Geoffrey S. Goodfellow To: Karlton at PARC-MAXC Cc: Header-People at MC, MsgGroup at ML, Everhart at CMUA, Cc: Lamb at CMUA, Sapsford at XEROX-PARC Message-ID: <[SRI-KA] 8-Mar-79 19:58:18.GEOFF> In-Reply-To: Your message of 8 Mar 1979 2:18 pm (Thursday) Reply-to: Geoff @ SRI-KA Re: "What has happenned to pride of craftsmanship?" Apparently it ran out the same time funding did.  Date: 9 Mar 1979 0315-EST From: Rick Gumpertz at CMU-10A Subject: Charlotte Mooers at BBN To: Header-People @ MIT-MC Message-ID: <09Mar79 031510 RG02@CMU-10A> I got a note from Charlotte Mooers a few days ago. She is out of town and promises to send a considered message next week. I am amazed she can restrain herself, but perhaps that explains the mysterious silence from BBN -- noone but the liason dares say anything. Rick  Date: 15 MAR 1979 2338-EST From: KLH at MIT-MC (Ken Harrenstien) Subject: Delivery glitch To: HEADER-PEOPLE at MIT-MC Due to some unknown person's mis-edit of the header-people mailing list, 4 messages failed to be forwarded on. I've included the times, sources, and text lengths below so that the originators can resend their messages, and rearranged a few things here so that in the future such re-sends shouldn't be necessary. 3/14 19:08:38 From PARC-MAXC TL=5320. ID=<[MIT-MC].366772> 3/15 13:56:15 From PARC-MAXC TL=560. ID=<[MIT-MC].367196> 3/15 16:50:30 From CMU-10A TL=274. ID=<[MIT-MC].367287> 3/15 17:13:35 From CMU-10A TL=255. ID=<[MIT-MC].367296>  Date: Thursday, 15 Mar 1979 1648-EST From: Brian.K..Reid Subject: ARPA request for compliance (RFC) To: Header-People at MIT-MC Message-ID: <15Mar79 164847 BR10@CMU-10A> Remailed-To: header-people at mit-mc Remailed-From: Brian.K..Reid Remailed-Date: Friday, 16 Mar 1979 0123-EST CMU's mail program has now been changed to put the dots in people's names.  Date: Thursday, 15 Mar 1979 1700-EST From: 220-54-1647 (C410BR10) Subject: alternate name forms To: Header-people at mit-mc Message-ID: <15Mar79 170041 BR10@CMU-10A> Remailed-To: header-people at mit-mc Remailed-From: Brian.K..Reid Remailed-Date: Friday, 16 Mar 1979 0124-EST But we can always use our social security numbers.....  Date: 15 Mar 1979 2248-PST From: Mark Crispin Subject: dots in front of my eyes To: Header-People at MIT-MC Does ARPA seriously intend that everybody who uses headers such as the headers in this message should replace the dots with whitespace? Mumble. I hated the idea of making mail headers hairier, but now that we have this RFC 733 let's stick to it. By the way, there are alternatives to HERMES for Tenex and Tops-20 winners. There is a version of MSG which groks these fancy headers which (I believe) has been sent to Vittal a while ago for distribution to the world. Also, for us Tops-20 people, there is a really neat new mail reading program called MM which is small, fast, and seems to do everything MSG does and more. Anyway, it does everything I want to do with my mail file. Stuart Cracraft at SRI (McLure@SRI-KL) is the contact for this program. -- Mark Social security numbers? Sigh. -------  Date: 16 March 1979 02:01 est From: Frankston.Frankston at MIT-Multics Subject: Re: dots in front of my eyes To: Mark Crispin cc: Header-People at MIT-MC In-Reply-To: Msg of 03/16/79 01:48 from Mark Crispin Message-ID: <790316070128.630443 at MIT-Multics> Are social security numbers worse than having to realize that Stuart Cracraft at SRI is really McLure@SRI-KL??  Date: 15 Mar 1979 2312-PST From: Stuart McLure Cracraft Subject: re: dots in front of your eyes To: Frankston.Frankston at MIT-MULTICS, Admin.MRC at SU-SCORE Cc: Header-People at MIT-MC In-reply-to: Your message of 16-Mar-79 0201-PST Or that Frankston.Frankston@Mit-Multics is really ... ??? -------  Date: 15 Mar 1979 11:14 pm (Thursday) Sender: Karlton at PARC-MAXC From: Karlton at PARC-MAXC Subject: Disclaimer To: Header-People at MIT-MC Original-Date: 15 Mar 1979 10:55 am (Thursday) Due to a misunderstanding that was brought to my attention I feel the following is in order. The opinions I expressed yesterday are my own and not that of any organization. I am an ex-member of the CMU community and am not in daily contact with them and my thoughts should not be interpreted as coming officially from CMU or representing the thoughts of the students as a whole or any other CMU group. PK  Date: 15 Mar 1979 11:13 pm (Thursday) Sender: Karlton at PARC-MAXC From: Karlton at PARC-MAXC Subject: Further comments on no LWS request to CMU To: Header-People at MIT-MC Original-Date: 14 Mar 1979 4:01 pm (Wednesday) I must be getting old. I decided to wait a week and calm down before mailing my second letter about the request to CMU to prevent having linear white space in recipient names. First I think you should see what the hackers at CMU proposed to do. I have taken the liberty to edit some comments from the following message. ------------------------------------------------------------ Date: Thursday, 8 Mar 1979 1936-EST From: Craig Everhart at CMU-10A Subject: Re: White space in tokens To: Karlton at PARC-MAXC Message-ID: <08Mar79 193622 CE10@CMU-10A> In-Reply-To: Karlton's message of 8 Mar 79 14:18 [...] Allow me to describe the planned method of handling the request. Basically, we don't restrict RDMAIL in ANY way from its current state. However, [...] we're taking the following tack. There shall be a distinguished version of RDMAIL, which will be the first version that will attempt to comply with the request. When RDMAIL is invoked, and it sees that it is incrementing the last-RDMAIL- version-used-on-this- file number over this distinguished number, it will clear out the user's name stored in the .MSG file. Then, for both this kind of cleared name, and the kind that you get because you're creating a .MSG file, the user name will be generated as "Philip.Karlton" and stored into the .MSG file as such. (This will overwrite, for instance, "Mary Shaw", "JON BENTLEY", and "Brian K. Reid".) When it does this, it will tell you so, in a warning message, probably. In any case, the user is then perfectly free to change his/her name BACK to whatever he/she pleases; the point here is to catch those people who have never done the PROFILE command as well as those who do it every week. ALIAS and FROM will be left untouched. [... paragraph deleted... PK]. Along with these program changes, we'll have to (once more!) stress that there are [...] mail readers on the network, and that if a user generates fancy headers (and they'll have to do this, explicitly, after this RDMAIL comes up, [...]), then they take the responsibility for the difficulty their correspondents will have in using the [...] replying systems. [... four more paragraphs deleted ... PK] Craig ------------------------------------------------------------ First I would like to point out that this solution will not work. The trouble is that just changing the senders name to not contain LWS is insufficient. All the names in the recipient lists must also be coerced to not contain LWS. Letting a CMU header (excuse the expression) out onto the net would be considered as ill mannered as letting an ITS header out. This could be done by changing the names that contain LWS and have a destination site of CMUxxx. (What should be done for names with LWS that are not going to CMU?) This will annoy the user who types a carefully considered list of names only to have the format changed by the program to one that is acceptable by the outside network when the user knows that the original is acceptable to the local mail handling program.. The following represents my best guess, and might be far from the truth. What happened is that some administrator came up to CMU's operations manager at a meeting someplace and asked that CMU stop sending out those "funny" headers that had LWS in the names. Agreeing to do this probably did not seem like much of an imposition since CMU accepted "First.Last" in place of "First Last" anyway. Not much thought was given to what was actually being asked or to what the implementation details would be. The crux of the entire matter, to me at least, is whether or not RFC733 is a network standard. If it is not a standard, then an explanation is due to many people and an apology to those that actually produced 733. If it is a standard, then the request to CMU to remove LWS was completely out of order. If 733 is to be replaced, then it should be replaced and a new standard should be issued. Vague wishes like "Make your program generate stuff my program can understand." make it impossible for the implementor. I have already had the misfortune of producing software to a floating goal and found that an extremely frustrating experience for both me and the client. If what HERMES will parse is to become the standard for network mail then a specification of that should be published. Does HERMES handle Reply-To: fields? Names in <>'s? Sender: fields? It does not seem reasonable for CMU to go in and fix up the sender names not to have LWS just to have someone complain that CMU is still sending bogus headers. If what happened is that BBN was asked to write a program for money (which is not a dishonorable thing to do as some have implied) and were told to just ignore the header controversy, then they should not be surprised that tempers flare when people get told that their work (and generating 733 was real work) was wasted and that no one (important) was going to pay attention anyway. PK  Date: 16 March 1979 02:30 est From: Frankston.Frankston at MIT-Multics Subject: Re: re: dots in front of your eyes To: Stuart McLure Cracraft cc: Frankston.Frankston at MIT-Multics, Admin.MRC at SU-SCORE, Header-People at MIT-MC In-Reply-To: Msg of 03/16/79 02:12 from Stuart McLure Cracraft Message-ID: <790316073013.198152 at MIT-Multics> I apologize for not knowing your middle name. There is no strong rule for what is a good name (or alias). Admittedly the social security number is one of the more obscure. Same goes for phone numbers for that matter. At least there is a standard way of going from person name to phone number, provided you know precisely where that person lives. I can appreciate the middle name as an identifier. There are a number of people who know me solely as Matthias (my middle name). One, in fact, became confused when he found that the two differnt people he know of, Bob Frankston and Matthias were me.  Date: 16 March 1979 02:30 est From: Frankston.Frankston at MIT-Multics Subject: Re: re: dots in front of your eyes To: Stuart McLure Cracraft cc: Frankston.Frankston at MIT-Multics, Admin.MRC at SU-SCORE, Header-People at MIT-MC In-Reply-To: Msg of 03/16/79 02:12 from Stuart McLure Cracraft Message-ID: <790316073028.513056 at MIT-Multics> damn non defaulting to fill rreply command!  Date: 15 Mar 1979 2348-PST From: Stuart McLure Cracraft Subject: more dotz To: frankston.frankson at MIT-MULTICS Cc: header-people at MIT-MC Mail from MIT-MULTICS rcvd at 15-Mar-79 2330-PST Date: 16 March 1979 02:30 est From: Frankston.Frankston at MIT-Multics Subject: Re: re: dots in front of your eyes To: Stuart McLure Cracraft cc: Frankston.Frankston at MIT-Multics, Admin.MRC at SU-SCORE, Header-People at MIT-MC In-Reply-To: Msg of 03/16/79 02:12 from Stuart McLure Cracraft Message-ID: <790316073013.198152 at MIT-Multics> To me, any combination of full last, middle or first is far more preferable than numbers. By the way, why is your mail system propagating the Re's in the subject field? It should not care about the upper/lower case distinction when parsing that field. -------  Date: 16 March 1979 03:51 est From: Frankston.Frankston at MIT-Multics Subject: Re: more dotz To: Stuart McLure Cracraft cc: header-people at MIT-MC In-Reply-To: Msg of 03/16/79 02:48 from Stuart McLure Cracraft Message-ID: <790316085121.081379 at MIT-Multics> 1. You can send mail to bob@mit-multics. Normally Multics cares strongly about case. It so happens that the network mail table has been setup so that the entries are checked for in all upper case. Thus if you send mail to Frankston or frankston it would work. But if you include the "." the name would be converted to a Multics pathname and must follow the strict conventions. 2. Again, case is the issue. It does not recogize "re:" as being "Re:". I have sent a note to the mail maintainers on this. But actually it is your mail system that should be consistant and capitalize "Re:". 3. I'm going to be in SF next week (and again in May and again in ??). Would be interested in visiting people on sites. The official reason is to attend IBM SHARE, but hopefully will have time this trip, or the next trip (when I'll be at the West coast Computer Faire) to visit around.  Date: 16 Mar 1979 0324-PST Sender: GEOFF at SRI-KA Subject: Re:.ARPA.request.for.compliance.(RFC) From: the.tty.of.Geoffrey.S..Goodfellow To: BR10 at CMU-10A Cc: Header-People at MIT-MC Message-ID: <[SRI-KA]16-Mar-79 03:24:33.GEOFF> In-Reply-To: <15Mar79.164847.BR10@CMU-10A> Reply-to: Geoff @ SRI-KA B.L.E.T.C.H.!  Date: Friday, 16 Mar 1979 1036-EST From: David Lamb Subject: Re: dots in front of my eyes Sender: RdMail at CMU-10A To: Mark Crispin CC: Header-People at MIT-MC Reply-To: RdMail at CMU-10A Message-ID: <16Mar79 103654 RD00@CMU-10A> In-Reply-To: Mark Crispin's message of 16 Mar 79 01:48 Actually, it's still quite easy to generate a non-dotted FROM field at CMU. You always get either a dotted REPLY-TO field, or a dotted name in <> in the FROM field. Of course if your name never had any white space (like RDMAIL) you don't get any spurious dots. The actual time spent on this little hack was about 3 hours looking at code on my part (I'm the newest of the RDMAIL maintainers, and wasn't familiar yet with the parts that needed to be changed), 1/2 hour looking at code on Craig Everhart's part, about 3 hours coding and compiling (I made the mistake of trying the change in the afternoon, when there are no cycles), and about 15 hours arguing with people over whether we should do the change or not. The non-technical portions of this sort of thing take far more time than the technical parts. David Alex Lamb  Date: Friday, 16 Mar 1979 1528-EST From: Brian.K..Reid Subject: certification of computer professionals To: MsgGroup at USC-ISI, Header-People at MIT-MC Message-ID: <16Mar79 152808 BR10@CMU-10A> Now that the flaming about the certification of computer professionals has pretty much died down (though such certification is still being considered, of course) I offer these two news stories from today's AP wire, with no further comment. a023 0026 16 Mar 79 PM-Topic, Advisory, Managing Editors: Wire Editors: It all started in a tiny part of a computer program used by an engineering firm designing nuclear reactors. It ended with the shutdown of five nuclear power plants at a time when President Carter is pushing oil conservation and the world oil market is in turmoil. The computer miscalculated some safety precautions required by law. The power from the closed plants now will have to be replaced by electicity generated with oil or coal. This may cost utility customers money and throw a curve at Carter's conservation program. In Today's Topic: The Little Computer and the Big Problem, AP writer Evans Witt traces this glitch in the system, from the obscure computer to its possible effect on the nation's energy problems. The story, illustrated by Laserphoto NY7, is upcoming next. The AP ap-ny-03-16 0328EST *************** a024 0044 16 Mar 79 PM-Topic-Glitch, Bjt,950 TODAY'S TOPIC: The . yyter and the Big Problem Laserphoto NY7 By EVANS WITT Associated Press Writer WASHINGTON (AP) - Something just didn't add up. And the result is: five nuclear power plants are shut down; millions of Americans may pay higher utility bills; and a sizable blow may have been struck to President Carter's efforts to reduce the use of imported oil and to control inflation. The immediate source of all this is part of the federal bureaucracy - the Nuclear Regulatory Commission which ordered the shutdowns. But in one sense, the ultimate culprit was ''Shock II,'' a tiny part of a computer program used by a private firm to design the power plants' reactors. Shock II was wrong and that means parts of the five reactors might not survive a massive earthquake. Shock II was the weak link that could have allowed the chain to snap. In between Shock II and the shutdowns were a public utility, a private engineering firm and the NRC staff. It was really the judgments of the dozens of scientists and engineers, not elected or appointed officials, that led to the shutdowns. Perhaps as a result, the decision's impact on the nation's energy situation was not even considered until the very last moment - when the commission itself was faced with the final decision. And at that point, the NRC said, it had no choice. It said the law was clear: serious questions about the reactors had been raised and the reactors had to be turned off until answers were found. The specific questions are arcane engineering issues, but the explanation is straightfoward: Will some of the systems designed to protect the reactor survive an earthquake - or will they fail, and possibly allow radioactive death to spew into the air? The regulations say the reactors must be able to withstand a quake equal to the strongest ever recorded in their area. The regulations don't allow any consideration of the likelihood of a major quake. All four states where the reactors are located - New York, Pennsylvania, Maine and Virginia - have had minor quakes in this decade and damaging quakes at least once in this century. The only way to test them - short of having a massive earthquake - is to test a model of the reactor. The ''model'' is actually a set of mathematical formulas in a computer that reflect how the reactor and its parts will behave in a quake. The model used for the five reactors came from Stone and Webster, the large Boston engineering and architectural firm that designed the plants. The Stone and Webster model indicated how strong and well supported pipes had to be and how strong valves had to be. The problem apparently cropped up after Stone and Webster suggested within the last few months more pipe supports in the secondary cooling system of the reactor at Shippingport, Pa., operated by Duquesne Light Co. in Pittsburgh. But why were the supports needed? ''This was not clear to us, looking at the calculations done by the models,'' said Gilbert W. Moore, Duquesne's general superintendent of power stations. So Dusquesne - and Stone and Webster - sent the computer models through their paces again, having them calculate and recalculate what would happen to the pipes in an earthquake. ''We came out with some numbers which were not in the range we would like,'' Moore said. That made the problem clear - the model now said the pipes might break in an earthquake. The previous analysis indicated an adequate safety margin in the pipes, and Stone and Webster's explanation was: ''One subroutine may not give uniformly conservative results.'' The problem was in a ''subroutine,'' a small part of the computer model, called ''Shock II,'' said Victor Stello, director of NRC's division of reactor operations. ''The facts were that the computer code they were using was in error,'' said Stello. ''Some of the computer runs were showing things are okay. In some cases, the piping systems were not okay. ''We didn't know the magnitude of the error or how many plants might be affected,'' he said. It was on March 1 that Duquesne told the NRC of the problem by telephone and asked for a meeting to discuss it. The same day, Energy Secretary James R. Schlesinger was telling Congress that unleaded gas might cost $1 a gallon within a year and service stations might be ordered shut down on Sundays because of oil shortages. The meeting took place on Thursday, March 8, in Washington with NRC staff, Stone and Webster engineers and Duquesne Light people on hand. Through the weekend, Stello said, engineers from NRC, Duquesne and Stone and Webster worked at the private firm's Boston office, analyzing the severity of the problem. ''By the middle of Sunday (March 10) we begin to get a pretty good idea of what it meant for the systems,'' Stello said. ''Monday, we got the latest information from our people at the Stone and Webster offices. It became clear that there would be a number of the safety systems that would have stresses in excess of allowable limits. The magnitude of the excess was considerable.'' Tuesday, members of the NRC were briefed by their staff of engineers and scientists. They asked for an analysis of the economic impact of the decision, and then ordered the plants closed within 48 hours. And the five reactors shut down: Duquesne Light Co.'s Beaver Valley plant at Shippingport, Pa.; Maine Yankee in Wiscasset, Maine; the Power Authority of New York's James Fitzpatrick plant at Scriba, N.Y.; and two Virginia and Electric Power Co. reactors at Surry, Va. It may take months to finish the analysis of the potential problems and even longer to make changes to take care of the situation. Until the reactors start generating again, the utilities will have to turn to plants using oil or coal. This may cost more, and that cost may be borne by the millions of utility customers. To replace the power from these nuclear plants could require 100,000 barrels of oil a day or more. And this at a time when President Carter has promised to cut U.S. oil consumption by 5 percent - about 1 million barrels a day - and when the world's oil markets are in turmoil because of recent upheavals in Iran. ap-ny-03-16 0346EST ***************  Date: 16 Mar 1979 1534-EST Sender: NMA at BBN-TENEXA Subject: Re: Re: more dotz From: NMA at BBN-TENEXA To: Frankston.Frankston at MIT-MULTICS Cc: McLure at SRI-KL, header-people at MIT-MC, stef at SRI-KA Message-ID: <[BBN-TENEXA]16-Mar-79 15:34:30.NMA> In-Reply-To: <790316085121.081379 at MIT-Multics> YOU CASE SENSITIVITY FOLKS NEED A REORIENTATION TO THE WORLD. IT IS THE REAL TRUTH THAT IF YOU WANT TO GET A MESSAGE ACROSS TO A RECEIVER, IT IS YOUR RESPONSIBILITY TO PACKAGE IT SO HE CAN CAPTURE THE MEANING. OR IF YOU WANT PEOPLE TO COMMUNICATE WITH YOU, THEN YOU MUST MAKE IT EASY AND CONVENIENT FOR THEM TO SO SO. ANY OTHER ATTITUDE INHIBITS THE FLOW OF INFORMATION. SEEMS TO ME THAT WE ARE AFTER A MAXIMIZATION OF POTENTIAL CONNECTIVITY AND POTENTIAL MOBILITY OF INFORMATION IN OUR BUDDING ELECTRONIC DEVICE CONTINUUM. THINGS LIKE CASE SENISTIVE MAIL RECEIVERS ARE CLEARLY COUNTER TO THE GOAL. OR CASE SENSITIVE FIELD NAME PARSING! OR ALL THESE OTHER PERSONAL STYLES THAT EACH OF YOU ARE BECOMING SO EMOTIONALLY ATTACHED TO. PERSONALY, I TAKE AFFRONT TO THOSE WHO TELL ME THAT WHAT I WANT IN MY RECEIVED MAIL IS OF NO CONCERN TO ME. B.L.E.C.H! BEST - STEF  Date: 16 March 1979 19:16 est From: Frankston.Frankston at MIT-Multics Subject: Re: Re: more dotz To: NMA at BBN-TENEXA cc: Frankston.Frankston at MIT-Multics, McLure at SRI-KL, header-people at MIT-MC, stef at SRI-KA In-Reply-To: Msg of 03/16/79 15:34 from NMA Plesae don't shout. Things are noisy enough here as is. Yeah, Multics does accept mail to recipient names in the network table even when shouted or in a mixture of shouted letters and unshouted ones. However, internally it is very nice to be able to take advantage fo the beauty of the full upper and lower case alphabets.  Date: 16 Mar 1979 1737-PST Sender: STEF at SRI-KA Subject: Re: Re: Re: more dotz From: STEF at SRI-KA To: Frankston.Frankston at MIT-MULTICS Cc: header-people at MIT-MC Message-ID: <[SRI-KA]16-Mar-79 17:37:47.STEF> In-Reply-To: Your message of 16 March 1979 19:16 est WHO IS SHOUTING? JUST CAUSE I'M STUCK WITH THIS UPPERCASE YOU SAY I'M SHOUTING. GEEZ! AND I SAID NOTHING ABOUT WITHHOLDING BEAUTY FROM THOSE WHO LOVE LOWER CASE. ALL YOU NEED DO IS DISPLAY IT THAT WAY FOR YOUR SELF. JUST DON'T MAKE ME LEARN TO ESCAPE THIS BEASTLY TERMINAL SO I CAN SEND YOU MAIL. OR SO YOU CAN MAKE SENSE OUT OF IT (INCLUDING YOUR PERSNICKETY PARSER THAT IS CASCADING THOSE "Re:" THINGS IN THE SUBJECT FIELDS.) CHEERS - STEF  Date: 16 March 1979 20:45 est From: Frankston.Frankston at MIT-Multics Subject: Re: Re: Re: more dotz To: STEF at SRI-KA cc: Frankston.Frankston at MIT-Multics, header-people at MIT-MC In-Reply-To: Msg of 03/16/79 20:37 from STEF 1. Bug in parser is being fixed (I think may be fixed by now). 2. The beauty is not necessarily in theparticular graphics chose, but rather in the variety and the expression possible iwth two cases rather than one. 3. We do accomdate cripple dterminals and system for receiving mail. We are, however, unable to read the mind of the sender and determine the original form of the letter before being smashed into the LOUD version. Sorry, it is a religous feeling here that computers need not shout and need not be congenitally defective. While we can deal with tose that are, we must also pity them.  Date: 16 Mar 1979 1757-PST Sender: STEF at SRI-KA Subject: Re: Re: Re: Re: more dotz From: STEF at SRI-KA To: Frankston.Frankston at MIT-MULTICS Cc: header-people at MIT-MC Message-ID: <[SRI-KA]16-Mar-79 17:57:50.STEF> In-Reply-To: Your message of 16 March 1979 20:45 est chuckle chuckle - the subject bug is in hermes, which has apparently assumed that no one would put an extra space in front of an "re:" Best - Stef  Date: Saturday, 17 Mar 1979 0007-EST From: Brian(space)Reid Subject: embedded spaces Sender: BR10 at CMU-10A To: Header-People at MIT-MC Reply-To: Brian.K..Reid Message-ID: <17Mar79 000730 BR10@CMU-10A> This seems to work too, and to my utter amazement, our RdMail can parse it correctly!  Date: 16 Mar 1979 2131-PST Sender: GEOFF at SRI-KA Subject: Re: embedded spaces From: the tty of Geoffrey S. Goodfellow To: BR10 at CMU-10A Cc: Header-People at MIT-MC Message-ID: <[SRI-KA]16-Mar-79 21:31:34.GEOFF> In-Reply-To: <17Mar79 000730 BR10@CMU-10A> Reply-to: Geoff @ SRI-KA So can HERMES (as this message demonstrates)! However, all, N.B. that the reason why HERMES can parse it is because of SENDER. Currently the way HERMES handles msgs is that if it can't parse from it goes looking for SENDER (an RFC733 violation indeed), so if you removed SENDER from your msg, HERMES would luze as before. This meaning also of course that HERMES knows NOTHING about REPLY-TO.  Via: Rand-Unix To: Msggroup@mit-mc, Header-People@mit-mc Subject: Dawning of a New Age? From: Dcrocker at UDEE Reply-to: Dcrocker at Rand-Unix Date: Sun, 18 Mar 79 16:19-EST Please to note the From field of this message. As of a couple of days ago, we are finally able to send messages onto the ArpaNet, from the University of Delaware. We use dial-up access to a Mail Relay host (currently Rand-Unix). We should shortly have automated pickup of mail, also. The current hack is to have return mail go to our accounts on Rand. The longer-term solution will remove this and have it go "directly" back to Delaware. You might be interested to know that we use 300 baud, which gives us an effective bandwidth of about a kilobyte per minute. As atrocious as that sounds, it obviously is somewhat useful. Only requirement is that the user not be expected to sit and watch it, so of course we have a background process do the dial-up and transfer. Dave.  Date: 2 Apr 1979 0843-PST From: POSTEL at USC-ISIE Subject: RFC on new message system available To: header-people at MIT-MC cc: postel RFC 753 is now available in the NIC online library at SRI-KL. Title: Internet Message Protocol Author: Jon Postel Pages: 62 pathname: RFC753.TXT This is very much a request for comments, so please send me your suggestions for improving the proposed message system and improving the document. Public access files may be copied from the NIC library at SRI-KL via FTP with username NICGUEST and password ARPA (actually SRI-KL allows copying of public access files via FTP without a login). --jon. -------  Via: To: Header-People@MIT-MC cc: Feinler@SRI-KL,, Farber@SRI-KA,, Szurko@UDEE Subject: Short term solution to an Internet addressing problem? From: Dcrocker at UDEE Reply-to: Dcrocker at Rand-Unix Date: Thu, 5 Apr 79 15:21-EST We have encountered an interesting addressing problem, in sending mail from the University of Delaware out to the Arpanet. You may notice that this message contains a "Reply-To" field in which the return address specifies a host on the Arpanet, whereas the From field specifies one that is not. This is a hack of some utility -- providing your message system can deal with Reply-To as it is supposed to -- but limits the solution (?) of the "host on another network" referencing problem to the sender's address only. Any addresses having the same problem but occurring in the "To" or "cc" fields are left hanging. I believe that there exists a tolerable, complete, "correct" solution but it requires a substantial conceptual change and I will be suggesting it later. A hack -- of the hackiest type -- seems reasonable for the VERY short term, contingent upon the ability of existing systems to tolerate it. To wit: extend the official Arpanet Host Names list to include the University of Delaware and have it have the same host number address as Rand-Unix. The potential problem is with the existing rule that a given address officially has only two strings associated, one the official name and the other a nickname. Our suggestion is to up that to at least three and  Via: To: Header-People@MIT-MC cc: Feinler@SRI-KL,, Farber@SRI-KA,, Szurko@UDEE Subject: Short term solution to an Internet addressing problem? From: Dcrocker at UDEE Reply-to: Dcrocker at Rand-Unix Date: Thu, 5 Apr 79 15:21-EST We have encountered an interesting addressing problem, in sending mail from the University of Delaware out to the Arpanet. You may notice that this message contains a "Reply-To" field in which the return address specifies a host on the Arpanet, whereas the From field specifies one that is not. This is a hack of some utility -- providing your message system can deal with Reply-To as it is supposed to -- but limits the solution (?) of the "host on another network" referencing problem to the sender's address only. Any addresses having the same problem but occurring in the "To" or "cc" fields are left hanging. I believe that there exists a tolerable, complete, "correct" solution but it requires a substantial conceptual change and I will be suggesting it later. A hack -- of the hackiest type -- seems reasonable for the VERY short term, contingent upon the ability of existing systems to tolerate it. To wit: extend the official Arpanet Host Names list to include the University of Delaware and have it have the same host number address as Rand-Unix. The potential problem is with the existing rule that a given address officially has only two strings associated, one the official name and the other a nickname. Our suggestion is to up that to at least three and  Via: To: Header-People@MIT-MC cc: Feinler@SRI-KL,, Farber@SRI-KA,, Szurko@UDEE Subject: Short term solution to an Internet addressing problem? From: Dcrocker at UDEE Reply-to: Dcrocker at Rand-Unix Date: Thu, 5 Apr 79 15:21-EST We have encountered an interesting addressing problem, in sending mail from the University of Delaware out to the Arpanet. You may notice that this message contains a "Reply-To" field in which the return address specifies a host on the Arpanet, whereas the From field specifies one that is not. This is a hack of some utility -- providing your message system can deal with Reply-To as it is supposed to -- but limits the solution (?) of the "host on another network" referencing problem to the sender's address only. Any addresses having the same problem but occurring in the "To" or "cc" fields are left hanging. I believe that there exists a tolerable, complete, "correct" solution but it requires a substantial conceptual change and I will be suggesting it later. A hack -- of the hackiest type -- seems reasonable for the VERY short term, contingent upon the ability of existing systems to tolerate it. To wit: extend the official Arpanet Host Names list to include the University of Delaware and have it have the same host number address as Rand-Unix. The potential problem is with the existing rule that a given address officially has only two strings associated, one the official name and the other a nickname. Our suggestion is to up that to at least three and preferably four. Some implementations may depend on that maximum of two and I need information from you as to whether any of your systems, or systems that you know about, rely on that limit. I know, for example, that the Rand-Unix host list, derived from the one maintained by Geoff, can handle an arbitrary number of aliases. Please let me know of any problems. Thanks. Dave Crocker  Date: Thursday, 5 Apr 1979 1739-EST From: Craig.Everhart at CMU-10A Subject: Re: Short term solution to an Internet addressing problem? Sender: RdMail at CMU-10A To: Header-People at MIT-MC Message-ID: <05Apr79 173949 RD00@CMU-10A> In-Reply-To: Dcrocker's message of 5 Apr 79 15:21 I happen to know that CMU's copy of the Arpanet host table only has room for a single nickname for any given host. I had wondered about the official status of the multiple nicknames to be found in {SRI-KL}HOSTS.TXT. So much for the direct answer to your question. I hope you know your outgoing mail had its header fields in an un-recommended order, with the Date: field coming last rather than first, and so forth. Craig Everhart  From: dcrocker at Rand-Unix Date: Thu, 5 Apr 79 15:18-PST To: Craig.Everhart at CMU-10A cc: Header-People at MIT-MC Subject: Re: Short term solution to an Internet addressing problem? In-reply-to: Your message of Thursday, 5 Apr 1979 1739-EST. <05Apr79 173949 RD00@CMU-10A> 1. with respect to the aliasing, many thanks for the info, tho I would of course have preferred a different response. Sigh. 2. with respect to header ordering, this erroneous belief of yours seems to be quite common. The apparent ordering requirement for headers, in the standard, is due to the nature of the specification tool and a NOTE at the beginning of section III.C, "General Syntax of Messages" disclaims the requirement, instead relegating it to a recommendation. I approve of the recommendation but the current software make following it somewhat difficult whereas sticking it on the beginning is easy. Does it really cause your software problems? dave.  Date: 5 April 1979 18:36 est From: Palter.PDO at MIT-Multics (Gary M. Palter) Subject: Re: Short term solution to an Internet addressing problem? To: Dcrocker at Rand-UNIX cc: Header-People at MIT-MC, Feinler at SRI-KL, Farber at SRI-KA, Szurko at Rand-UNIX In-Reply-To: Msg of 04/05/79 16:44 from Dcrocker We can add an arbitrary number of abbreviations for a host on Multics. However, if we did add UDEE as an abbreviation of Rand-Unix, ithe Multics mail system will put Rand-UNIX (the official name) into the header or the message, thus loosing some information. I will check intowhether the Multics version of the host table can have two separate hosts with the same address. (Even if this is possible, I expect that it will not help the situation any.) Whatever, I will put UDEE into the Multics host table (MIT only; someone else will have to get RADC and CISL upated.)  Date: Thursday, 5 Apr 1979 1836-EST From: Craig.Everhart at CMU-10A Subject: Re: Short term solution to an Internet addressing problem? To: dcrocker at Rand-Unix CC: Header-People at MIT-MC Message-ID: <05Apr79 183605 CE10@CMU-10A> In-Reply-To: dcrocker's message of 5 Apr 79 18:18 As you'll note, I only referred to the order of header fields as a recommendation, not as a requirement, in my message. The particular order of fields makes no difference to my mail reader (RDMAIL). I just figured that you, having been so intimately involved with RFC733, should not remain unaware of the glitch in the header to the mail you composed. Of course, since the recommended order was only a recommendation, answers involving the amount of programming time involved are that much more believable. Craig  Date: Thursday, 5 Apr 1979 1901-EST From: Richard H. Gumpertz Subject: Re: Short term solution to an Internet addressing problem? To: Dcrocker at Rand-Unix CC: Header-People @ MIT-MC Message-ID: <05Apr79 190142 RG02@CMU-10A> In-Reply-To: Dcrocker's message of 5 Apr 79 15:21 Why not "DCrocker at UDEE at Rand-Unix", with Rand-Unix informed of the meaning of pseudo-user "DCrocker at UDEE"? Rick  Date: 5 April 1979 2108-est From: Bob Frankston Subject: Prelogin help for Multics To: Pogran.CompNet at MIT-Multics Cc: Consultant.IPC at MIT-Multics Cc: header-people at MIT-MC It would be nice if the online consultant facility were available from a prelogin command. The system should check to see if an online consultant is available. If so, the text for the help command syould say something like For more help, type "olc" followed by a message for the online consultant, When the consutlant is not available a mail command could be available for the user to leave questions. This latter faiclity can be used to get informationabout user registration sent to the user via uUS mail or net mail depending on what is apporpriate.  Date: 5 April 1979 2138-est From: Bob Frankston Subject: Re: Short term solution to an Internet addressing problem? To: Rick.Gumpertz at CMU-10A Cc: DCrocker at Rand-unix, header-people at MIT-MC While I agree that pathnames should be usable for addressing people on the network, such as DCrocker at UDEE at Rand-Unix. The problem is representing the return address apropriately. When at UDEE, the reply field is simply "DCrocker at UDEE". I notice that Dave's message contained an attempt at a via field. It is that field, in conjunction with the reply field that is used to construct the reply pathname. Since most hosts do not handle the via constructs (in fact, none do currently) a gateway site such as Rand-Unix scould append its own name to the reply- field. Thus the header would start as: Reply-to: DCrocker at UDEE and become either Via: Rand-Unix Reply-to: DCrocker at UDEE or, if we just want to make changes at the gateway host, Reply-to: DCrocker at UDEE at Rand-Unix My full blown proposal also contains the suggestion for the repcipient: field used in allowing any user on any host to act as a gatewey, but I will not repeat that here. On additional compatability point. Most hosts do not deal with the multiple "at" problem at present (nor even the embedded space problem!!!) so that if we are dealng with interim solutions that do not require modifying old hosts, we can allow the word "via" to be a synonym for "at" such that the reply vield becomes Reply-to: DCrocker via UDEE at Rand_Unix. {To keep hermes happy, Reply-to: DCrocker.via.UDEE at Rand_Unix.}  Date: Thursday, 5 Apr 1979 2218-EST From: Richard H. Gumpertz Subject: Re: Short term solution to an Internet addressing problem? To: Bob Frankston CC: DCrocker at Rand-unix, header-people at MIT-MC Message-ID: <05Apr79 221830 RG02@CMU-10A> In-Reply-To: Bob Frankston's message of 5 Apr 79 21:38 1) Why add new fields? Seems to me that the gateway function should feel free to modify any machine-addresses (in FROM/TO/REPLY-TO/etc) as they go through the gateway (either the UDEE half or the Rand-Unix half -- it doesn't matter which) in each direction. Note that such addresses can be found thanx to RFC733 if that standard hasn't gone up in wishful smoke. 2) For the hosts that can't hack double @, VIA is a poor replacement because it requires delimiting spaces. We all know about spaces and Big-Bad-Neighbor. Maybe to be consistent you could use .VIA. (sigh) or, if UDEE names have no dots, more simply UserName.UDEE at RAND-Unix Rick Gumpertz  Sender: dcrocker at Rand-Unix Date: Thu, 5 Apr 79 20:38-PST To: Header-People at MIT-MC Subject: internet addressing, addendum From: Dave Crocker I appreciate the interest shown by the activity spike. However, you are trying to solve a different problem than the one I have. For the moment, the existing Reply-To contents are entirely adequate (tho, yes, I realize it obviously invovles the very worst sort of hackery to make it work). And, with respect to the Reply-To field, the nesting you suggest is what will happen, in some form, tho that cannot happen until a modified Rand FTP server, at least, is installed. Since Rand is a production facility, such major system changes take a long time. Got to make sure the change is safe. Howsomever, there is a very different problem that only got hinted at in the flurry of notes and that is addresses in the To and cc fields that reference UDEE. I have a very strong aversion to mucking with the existing text of a message and, unfortunately, those fields are part of the TEXT of the message, tho software uses it too. Ergo, my preference, my very strong preference, is to add fields. Also, I might add, that is many time easier to do. Something on the order of the Via field (but not exactly that and certainly not exactly what we are now generating) is what I have in mind and is what I obliquely referenced in my note earlier today. For the moment, I am, once again, looking for the minimum effort, probably hackiest (re)solution available and extending the hostname table seem(s/ed) the likeliest candidate. Note that we are NOT concerned with preserving the string "UDEE" on reply mail. Having the string be "Rand-Unix" is just fine. As I said, we are using a hack solution. Turns out is works because we have accounts on Rand. So, people, since at least one site relies on the limit of two strings, we won't be able to try to make the addition official. however, those who keep private lists, with arbitrary lists of aliases, PLEASE ADD "UDEE" and "UDel-EE" and aliases for Rand-Unix. (You listening Geoff??) Many thanks. Dave.  Date: Friday, 6 Apr 1979 0000-EST From: Richard H. Gumpertz Subject: Re: internet addressing, addendum To: Dave Crocker CC: Header-People at MIT-MC Message-ID: <06Apr79 000042 RG02@CMU-10A> In-Reply-To: Dave Crocker's message of 5 Apr 79 23:38 The header, in my opinion, is NOT part of the text. You should be manipualting it. adding a VIA field is a crock because it doesn't say which addresses are qualified by the VIA. Rick  Date: 6 April 1979 0216-est From: Bob Frankston Subject: internet addressing, addendum To: DCrocker at Rand-Unix Cc: header-people at MIT-MC In response to Rick Gumpertz' comment on "via". It applies to all address in the letter since it means they are all relative to the given gateway.  Date: 5 Apr 1979 2329-PST Sender: GEOFF at SRI-KA Subject: Re: Re: Short term solution to an Internet addressing problem? From: the tty of Geoffrey S. Goodfellow To: Frankston at MIT-MULTICS Cc: Rick.Gumpertz at CMU-10A, DCrocker at RAND-UNIX, Cc: header-people at MIT-MC Message-ID: <[SRI-KA] 5-Apr-79 23:29:40.GEOFF> In-Reply-To: Your message of 5 April 1979 2138-est Reply-to: Geoff @ SRI-KA However, sadly enough, HERMES does not know about the REPLY-TO: field, however if you put "SENDER: DCrocker.via.UDEE at RAND-UNIX) in there winnage would occur with HERMES.  Date: 5 Apr 1979 2334-PST Sender: GEOFF at SRI-KA Subject: Re: internet addressing, addendum From: the tty of Geoffrey S. Goodfellow To: DCrocker at RAND-UNIX Cc: Header-People at MIT-MC Message-ID: <[SRI-KA] 5-Apr-79 23:34:15.GEOFF> In-Reply-To: Your message of Thu, 5 Apr 79 20:38-PST Reply-to: Geoff @ SRI-KA Yes, I'm listening, and will add UDEE and UDEL-EE into my table for the next update.  Date: 6 Apr 1979 0026-PST From: Feinler at SRI-KL (Jake Feinler) Subject: Re: internet addressing, addendum To: GEOFF at SRI-KA, DCrocker at RAND-UNIX cc: Header-People at MIT-MC, FEINLER In response to the message sent 5 Apr 1979 2334-PST from the tty of Geoffrey S. Goodfellow Haven't had time to read all this stuff flying by, but do feel that we (either Geoff or I or anyone else) should not put in a nickname of that sort without the approval of RAND. It is clearly not a nickname or alias for RAND-UNIX. On the other hand, if they don't mind, I don't mind as a temporary stop-gap. Jake -------  Date: 6 Apr 1979 0103-PST From: Scott at SRI-KL (Scott J. Kramer) Subject: Re: Prelogin help for Multics To: Frankston at MIT-MULTICS, Pogran.CompNet at MIT-MULTICS Cc: Consultant.IPC at MIT-MULTICS, header-people at MIT-MC In-reply-to: Your message of 5-Apr-79 1808-PST I think that the "ocl" command could page the appropriate party (as :luser does on ITS) but in the event there was no one available to help you it would then automatically invoke the mail-type program wherein you could supply the neccessary information for having your inquiry answered. This mail message could be sent to the appropriate party according to a limited subject field, ie. the program would specify a list of subject options related (hopefully) to your inquiry. So maybe this solution can be considered in the already infinite list of alternatives to a difficult problem. Scott Kramer -------  Date: 6 April 1979 0407-est From: Bob Frankston Subject: Re: Prelogin help for Multics To: Scott at SRI-KL Cc: Consultant.IPC at MIT-Multics Cc: header-people at MIT-MC 1. The command is olc for online consultant. The standard version already looks in a table for the currently assigned consultant, if any. 2. The people acting as consultants are paid staff people who are usually doing other work at the time so I don't think that IPC would be happy about making this facility too freely available. It would only be intended for short questions on how to proceed further, maybe with a very tight resource limit, or a limit onthe # of messages. 3. The problem with mail is determining how to reply to a random user coming in from anywhere in the world. The current help command does give a phone number to call if there are problems. 4. Inany case this faiclity will not serve the purpose of helping user A get in touch with user B. The olc probalby has never heard of the person your are interested in communicating with. Multics has hundreds of registerd users, many of which are students in classes. The registration process is totally distirbuted, except that there is a central registry of usre names to prevent conflicts. Most of these people have never heard of each other. To take this to an extreme, imagine the phone system operating by allowing you to call a random person in a distant city to hel you get in touch with a friend. The intention of the "help" command that currently exists is to provide a means whereby one can ask questions about technical problems with logging in, including obtaining an account 4. it would be useful if the current help message were extended, atleast for network users, to give the phone number and mailbox name of the netowrk liason.  Date: 6 Apr 1979 0128-PST From: Scott at SRI-KL (Scott J. Kramer) Subject: Re: Re: Prelogin help for Multics To: Frankston at MIT-MULTICS Cc: Consultant.IPC at MIT-MULTICS, header-people at MIT-MC In-reply-to: Your message of 6-Apr-79 0107-PST Thanks for making that clearer Bob, I am not a Multics user. Anyways, my suggestion could be applied to other network sites; have an extended LUSER command. I think that in many cases if a random suddenly found himself being queried by the mail-type program his question would lose importance. Of course in situations like RMS's with UTAH, the program should prove sufficient assuming that the server has allowed itself to be queried. -------  Date: Friday, 6 April 1979 1108-EST From: Richard H. Gumpertz Subject: Re: internet addressing, addendum To: Bob Frankston CC: header-people at MIT-MC Message-ID: <06Apr79 110852 RG02@CMU-10A> In-Reply-To: Bob Frankston's message of 6 Apr 79 02:16 If VIA applies to all adresses, is there an ordering of VIAs for messages that travel through two different GATEWAYs?? I still prefere munging each address to be a complete entity by itself. Rick  Date: 6 APR 1979 1408-EST From: KLH at MIT-MC (Ken Harrenstien) Subject: Un(registered-mail-receipt) To: HEADER-PEOPLE at MIT-MC, (BUG MAIL) at MIT-MC To: (BUG CRTSTY) at MIT-MC, MsgGroup at MIT-ML It just struck me that despite general managerial dislike of the idea, I could have recently benefited from the feature (if it existed) of being able to tell the sender of a message whether the recipient has read it. My Header-people, MsgGroup, ITS, etc mail is all vectored to KLH@MIT-AI, and for the past 3 weeks I've been so crunched against the wall with local Deafnet hacking that I didn't read any of it. Hope silence hasn't been interpreted as indifference; there are certainly places where I ought to comment. Am catching up now (with 200-300 msgs), but just for the record, if there is something urgent (change to mailing list, fatal bugs in mail, etc) you may have better luck using KLH@SRI-KL. --Ken  Date: 6 April 1979 1801-est From: Bob Frankston Subject: Re: internet addressing, addendum To: Rick.Gumpertz at CMU-10A Cc: header-people at MIT-MC I agree that the via ordering is a problem and that all fields should probably be munged. The issue of ordered header fields is an important one in some contexts. I don't qutie know the best to handle it, maybe "via(1)" etc. My motivation of putting the via field at the beginning was to allow a host ftp server to put the name of the host from where the message came to be put in the "via" field and put the recipient name in at the same time. The use I suggested to Crocker was actually slightly different since it was meant to be appended by the gateway host as opposed to the receiving host.  Date: 6 APR 1979 1730-PST From: POSTEL at USC-ISIB Subject: re: short term solution to an internet addressing problem To: DCrocker at RAND-UNIX cc: Header-People at MIT-MC Dave: i guess i don't see what you are trying to do. as far as i can tell the VIA: line is just noise to every body except your gateway at rand. i hope you don't expect my mail reading/sending program to copy it into an answer i generate from one of your messages. and even tho rfc 733 says all those nice things about the use of the REPLY-TO line, Duane Adams has asked that we try to avoid making necessary the use of features not already generally implemented. several people (Rick in particular) have made the point about matching the information in one line with that in another. the point boils down to: each address must be complete and self contained. the hack that will work in the short term is for all users on the Delaware host to have external names of the form joe-UDEE@RAND-UNIX. The rest of us will think that joe-UDEE is some mail box at rand and rand can put all mail for any user name that ends "-UDEE" in the same file for later transmission to Delaware, and if you want at Deleware to fix the local names on the way in and out so you see the string "-UDEE@RAND-UNIX" as "UDEE" thats your business. --jon. -------  Date: 6 April 1979 20:54 est From: Frankston.Frankston at MIT-Multics Subject: Re: short term solution to an internet addressing problem To: POSTEL at USC-ISIb cc: DCrocker at Rand-UNIX, Header-People at MIT-MC In-Reply-To: Msg of 04/06/79 20:30 from POSTEL Why not use ".via." instead of "-" in "Jones.via.UDEE". As I've pointed out, this provides compatability for existing sites, but has the advantage of a glimpse ot future capabilities. PS: I haven't read your proposal for internetting yet, so this may be addressing issues you've already solved.  Date: 6 APR 1979 1813-PST From: POSTEL at USC-ISIB Subject: Re: Re: short term solution to an internet addressing problem To: Frankston.Frankston at MIT-MULTICS cc: DCrocker at RAND-UNIX, Header-People at MIT-MC, POSTEL In response to your message sent 6 April 1979 20:54 est Fine with me. the syntax within what i see as a single user name is up to the site that invents the names. if we are going to have several of these "out-of-net" hosts it would be nice to be consistent about it. your suggestion is helpful in that it tries to let the user see what is really going on, but it is not quite right since the message is really to/from UDEE and via RAND. how about "Jones.at.UDEE at RAND" (no, i thought not). --jon. -------  Date: 6 APR 1979 1822-PST From: POSTEL at USC-ISIB Subject: re: short term solution to an internet addressing problem To: header-people at MIT-MC 1 6 Apr FARBER at SRI-KA re: short term solution to an internet addressing problem 2 6 APR To: FARBER at SRI-KA re: short term solution to an internet addressing problem 1 -- ************************ Mail from SRI-KA rcvd at 6-APR-79 1814-PST Date: 6 Apr 1979 1805-PST Sender: FARBER at SRI-KA Subject: re: short term solution to an internet addressing problem From: FARBER at SRI-KA To: POSTEL at USC-ISIB Message-ID: <[SRI-KA] 6-Apr-79 18:05:50.FARBER> In-Reply-To: Your message of 6 APR 1979 1730-PST Jon, The basis problem we are in is that the hack solution we would like is one that is acceptable in the short term to parts of DOD. MMDF is being developed in part for real use by the DOD. We are searching for some solution that is acceptable to them and is also within Adams view of message system development. Certainly the additional pseudo-host route would work in part and was suggested with the hope that it would involve no work. I personnally thinnk the route you proposed will not work for several reasons (none technical). (that is unless you let me replace the - with an @ (chuckle). Dave 2 -- ************************ Mail from USC-ISIB rcvd at 6-APR-79 1820-PST Date: 6 APR 1979 1819-PST From: POSTEL Subject: re: short term solution to an internet addressing problem To: FARBER at SRI-KA cc: POSTEL In response to your message sent 6 Apr 1979 1805-PST Dave: well let's get those non-technical constraints out in the open! if we are going to have an online design session with random participants (and that is what's happening) then it is only fair that you state the whole problem. --jon. ------- -------  Date: 6 Apr 1979 1918-PST From: POSTEL at USC-ISIE Subject: New RFC Available To: header-people at MIT-MC RFC 754 is now available in the NIC online library at SRI-KL. Title: Out-of-Net Host Addresses for Mail Author: Jon Postel Pages: 10 pathname: RFC754.TXT Public access files may be copied from the NIC library at SRI-KL via FTP with username NICGUEST and password ARPA (actually SRI-KL allows copying of public access files via FTP without a login). --jon. -------  Date: 6 April 1979 2228-est From: Bob Frankston Subject: Re: Re: short term solution to an internet addressing problem To: POSTEL at USC-ISIB Cc: header-people at MIT-MC .at. is fine with me. The only reason for .via. was my evolution from suggesting " via " which was supposed to be transparent to existing mailers except for damn Hermes which objected to spaces. If we put the "." there then we might as well use .at., actually I'd prefer some character other than "." which would not be in conflict with RFC733 listing of innocuous characters so one would not have to quote it, but which is not in common use so that, for example ?at? could generally be used for parsing by participating hosts.  Date: Saturday, 7 April 1979 1129-EST From: Richard H. Gumpertz Subject: Re: short term solution to an internet addressing problem To: Hedaer-People @ MIT-MC Message-ID: <07Apr79 112924 RG02@CMU-10A> In-Reply-To: Frankston.Frankston's message of 6 Apr 79 20:54 1) I like .at. as suggested by Postel rather than "-". 2) via was invented as a crock to get around non-implementtion of multiple AT conjunctions. Therefore .via. is a double crock when .AT. will do just fine. Rick  Date: 9 April 1979 00:19-EST From: Charles Frankston Subject: ITS headers To: HEADER-PEOPLE at MIT-MC, MsgGroup at MIT-ML cc: BUG-BABYL at MIT-MC I have changed the ITS Rmail reply command to force an RFC733 header in any reply to a header that is not in ITS format. This is based on the assumption that anyone who sends out a network header probably should be replied to with a network header. Hopefully, this should eliminate many unwanted ITS headers. This change is conditional upon my not receiving too many complaints from the user community. Somehow, I don't expect to. I am suggesting that the maintainers of the other mail reading program do the same. The theory behind the change is that most people simply use the reply command somewhat blindly. In fact, I have noticed this is ture much more of the non-ITS particpaints, probably because they use such primitive mail systems that do not allow them to have an editor easily available to fix up their replies (take that Stef). Nonetheless, since I happen to know the maintainers of Babyl are easily sickened by excessive flaming, if anyone replies to this message, please do NOT blindly copy the CC:(bug babyl) line. Thank you.  Date: 10 APR 1979 1111-PST From: POSTEL at USC-ISIB Subject: re: short term solution to an internet addressing problem To: DCrocker at RAND-UNIX, Farber at SRI-KA cc: Header-People at MIT-MC Daves: as i understand things now, you want a host (RAND-Unix) to be able to act as a forwarder for some other host (or hosts) which are not otherwise connected to the ARPANET without there being an implication that the users for which forwarding is done are associated with the organization that owns the forwarding hosts. For example, there may be people at Delaware that don't want their names associated with RAND. So ok, think up a pseudonym for RAND (say GATEWAY-3/7) that does not contain the string "RAND", then give the users at Delaware external names of the form "Joe.of.UDEE@GATEWAY-3/7" which get used whenever we want Joe to be in a From, Sender, To, or CC field (or any other place a mailbox appears). Internal to Delaware it is possible substitute the string "UDEE" for the string ".of.UDEE@GATEWAY-3/7" so that the Delaware users are not bothered by it. Most of the hosts on the network will let one get away with this by entering "GATEWAY-3/7" as a nickname for RAND-Unix, but a few will insist on only using Official names in the actual messages sent. In this case the mechanism still works, but the user at Delaware appears to be in some way associated with RAND. One could get around this by having the gateway code in RAND-Unix translate "RAND-Unix" to "GATEWAY-3/7" for those messages going to Delaware. By the way there is no intention that the ".of." be recognized as being special by any mail processing program except that at RAND (or other gateway), to most mail processing programs it is just part of the user name. --jon. -------  Date: 11 April 1979 09:10-EST From: Mike McMahon Sender: MMcM at CADR5 at MIT-AI Subject: RsFC 753/4 flamage To: Header-People at MIT-MC It seems to me that RFC753 fails to address some of the fundamental problems with the current ARPANET mail protocol. Since it proposes to fundamentally change the method of message sending away from the outdated FTP MAIL command, now is definitely the time to figure out better how the rest of it should work in the multiple network environment it envisions (and which RFC754 shows to already be forming) as well. I cannot imagine that anyone has a mail system anyplace that is well enough designed that he/she will be able to adopt the internet scheme by simply changing the network sending routines and leaving the rest of the program intact. To get this going will require a large amount of programmer investment, in most cases a major overhaul or rewrite of the mailer; this would be much better invested toward getting something closer to what we believe to be right. The main problem with just about every mail program is HEADERS: spending all your time parsing them into your internal format and generating them back again in response. The extensible, data-typed, structured system proposed for the Message itself just begs to be used for headers. Why stick with RFC733? We all just implement a subset of it based on what other people send us and how responsive we are to our users. It isnt even left-to-right parsable (simplest example is "<", which has to get implemented in a sequential parser as "forget what you might have thought was going on", which ought not to be a valid parsing operation). I confess i am thoroughly confused as to whether or not PROPLIST is typed. The description of a Mailbox and the other instances of IA: seem to imply that it is, in that they are integers. However, the examples dont expand PROPLIST values into TEXT="Meeting Thrusday" and so on. Also i dont understand why one would need a size field for the value if it were typed. Obviously it needs to be typed to allow LISTs for structured recipients. Also it is not clear to me if the PROPLIST indicators are supposed to be unique or not, in the case of a continuation line TO: field, is each line a TO value, or is the value a string with CRLF and LWSP in it? I think we are mostly agreed that typing and immediately deleting all your mail is obsolete. The mail reader grovels over the message (parsing those damn headers), when it comes in from the net, or when it loads new mail, or when you want to reply to the message. So what's the point in having almost human readable headers in the message itself. A sufficiently well thought out structure for them should be able to guarantee that the "default" action at the other end shows "what you wanted" him/her to see. On a minor point, if my understanding of what "urgent" messages are in TCP, i.e. that they bypass normal flow-control mechanisms, it seems that this is entirely the wrong protocol level at which to be handling alarum messages. It seems it is much better done with multiple connections where necessary. Final thought: suppose i wanted to have multiple fonts in this message, as in the editor/mail-program i sent it with, if you also had a terminal that could display them, that would be another use for this structure.  Date: Wednesday, 18 April 1979 12:06-EST From: Earl Killian To: Header-People at MIT-MC Subject: MSG finally fixed! Date: 18 Apr 1979 1024-EST From: DUPUIS at BBN-TENEXE Subject: New Version of MSG A new version of MSG is up in as MSG.EXE. Old version is in as OLDMSG.EXE, it will stay in for one week and then be deleted. The only change in this new release of MSG is that it understands the new ARPANET mail standard formats for messages. This means that you will not be able to Answer messages from sites like MIT and CMU that generate addresses in that format. Please send all reports of problems or comments to MSG at BBNA. -------  Date: 18 April 1979 14:10-EST From: Earl A. Killian Subject: Please ignore this To: HEADER-PEOPLE at MIT-MC Testing.  Date: 6 April 1979 1801-est From: Bob Frankston Subject: Re: internet addressing, addendum To: Rick.Gumpertz at CMU-10A Cc: header-people at MIT-MC I agree that the via ordering is a problem and that all fields should probably be munged. The issue of ordered header fields is an important one in some contexts. I don't qutie know the best to handle it, maybe "via(1)" etc. My motivation of putting the via field at the beginning was to allow a host ftp server to put the name of the host from where the message came to be put in the "via" field and put the recipient name in at the same time. The use I suggested to Crocker was actually slightly different since it was meant to be appended by the gateway host as opposed to the receiving host.  Date: 11 April 1979 09:10-EST From: Mike McMahon Sender: MMcM at CADR5 at MIT-AI Subject: RsFC 753/4 flamage To: Header-People at MIT-MC It seems to me that RFC753 fails to address some of the fundamental problems with the current ARPANET mail protocol. Since it proposes to fundamentally change the method of message sending away from the outdated FTP MAIL command, now is definitely the time to figure out better how the rest of it should work in the multiple network environment it envisions (and which RFC754 shows to already be forming) as well. I cannot imagine that anyone has a mail system anyplace that is well enough designed that he/she will be able to adopt the internet scheme by simply changing the network sending routines and leaving the rest of the program intact. To get this going will require a large amount of programmer investment, in most cases a major overhaul or rewrite of the mailer; this would be much better invested toward getting something closer to what we believe to be right. The main problem with just about every mail program is HEADERS: spending all your time parsing them into your internal format and generating them back again in response. The extensible, data-typed, structured system proposed for the Message itself just begs to be used for headers. Why stick with RFC733? We all just implement a subset of it based on what other people send us and how responsive we are to our users. It isnt even left-to-right parsable (simplest example is "<", which has to get implemented in a sequential parser as "forget what you might have thought was going on", which ought not to be a valid parsing operation). I confess i am thoroughly confused as to whether or not PROPLIST is typed. The description of a Mailbox and the other instances of IA: seem to imply that it is, in that they are integers. However, the examples dont expand PROPLIST values into TEXT="Meeting Thrusday" and so on. Also i dont understand why one would need a size field for the value if it were typed. Obviously it needs to be typed to allow LISTs for structured recipients. Also it is not clear to me if the PROPLIST indicators are supposed to be unique or not, in the case of a continuation line TO: field, is each line a TO value, or is the value a string with CRLF and LWSP in it? I think we are mostly agreed that typing and immediately deleting all your mail is obsolete. The mail reader grovels over the message (parsing those damn headers), when it comes in from the net, or when it loads new mail, or when you want to reply to the message. So what's the point in having almost human readable headers in the message itself. A sufficiently well thought out structure for them should be able to guarantee that the "default" action at the other end shows "what you wanted" him/her to see. On a minor point, if my understanding of what "urgent" messages are in TCP, i.e. that they bypass normal flow-control mechanisms, it seems that this is entirely the wrong protocol level at which to be handling alarum messages. It seems it is much better done with multiple connections where necessary. Final thought: suppose i wanted to have multiple fonts in this message, as in the editor/mail-program i sent it with, if you also had a terminal that could display them, that would be another use for this structure.  Date: Wednesday, 18 April 1979 12:06-EST From: Earl Killian To: Header-People at MIT-MC Subject: MSG finally fixed! Date: 18 Apr 1979 1024-EST From: DUPUIS at BBN-TENEXE Subject: New Version of MSG A new version of MSG is up in as MSG.EXE. Old version is in as OLDMSG.EXE, it will stay in for one week and then be deleted. The only change in this new release of MSG is that it understands the new ARPANET mail standard formats for messages. This means that you will not be able to Answer messages from sites like MIT and CMU that generate addresses in that format. Please send all reports of problems or comments to MSG at BBNA. -------  Date: 18 APR 1979 1756-EST From: EAK at MIT-MC (Earl A. Killian) Subject: MSG finally fixed! To: McLure at SRI-KL CC: HEADER-PEOPLE at MIT-MC Date: 18 Apr 1979 1417-PST From: Stuart McLure Cracraft To: EKILLIAN at BBN-TENEXE, Header-People Re: MSG finally fixed! And of course the sources will remain carefully guarded and jealously hidden away so that things can not be done at a faster pace to MSG than has been the case in the past with incredibly slow bug fixes and complaints about 'not having the funding to do them'. So, what else is new? I'm just happy that another reason for abandoning RFC733 is going away.  Date: 19 April 1979 03:10 est From: Frankston.Frankston at MIT-Multics (Bob Frankston) Subject: Nonstandard header To: header-people at MIT-MC Message-ID: <790419081042.634416 at MIT-Multics> Apparently ITS has regurgitated a letter of mine from APril 6th with a nonstandard header. I apologize to all of those incovneienced and assume that the mail maintainers have also seen your complaints and will attempted to deal with the problem. I presume it to be a transient bug in the send_mail program on Multics. It has either gone away or shows up only in unusual circumstances.  Date: 23 April 1979 11:26-EST From: Ken Harrenstien Subject: MSG finally fixed? To: Dupuis at BBN-TENEXE cc: Header-People at MIT-MC Pardon me, but is this paragraph really what you wanted to say? It seems self-contradictory... "The only change in this new release of MSG is that it understands the new ARPANET mail standard formats for messages. This means that you will not be able to Answer messages from sites like MIT and CMU that generate addresses in that format." ????  Date: 23 APR 1979 1141-EST From: JNC at MIT-AI (J. Noel Chiappa) Subject: MSG and your health... To: header-people at MIT-MC One of these days, when the FDA investigates Chinese restaurants, they will decide that use of MSG is hazardous to your health.... Noel  Date: 23 APR 1979 1358-EST From: EAK at MIT-MC (Earl A. Killian) Subject: MSG finally fixed? To: KLH at MIT-MC CC: HEADER-PEOPLE at MIT-MC, Dupuis at BBN-TENEXE The message should have read "you will now be able to Answer" instead of "you will not be able to Answer".  Date: 8 May 1979 17:49 edt From: Frankston.Frankston at MIT-Multics (Bob Frankston) Subject: Visitation II To: header-people at MIT-MC Message-ID: <790508214904.117308 at MIT-Multics> For those interested, if any, I'll be in SF Thursday (5/10) through Monday (5/14) for the West Coast Computer Faire. I'll be at the Best Western Hotel SF Civic Center Motor Inn. 415-621-2826. I'll also try to bring a terminal to read my mail.