18-Aug-82 17:23:56-PDT,7263;000000000001 Mail-from: ARPANET site BRL rcvd at 18-Aug-82 1722-PDT Date: 18 Aug 1982 1313-PDT Sender: MSGGROUP at Usc-Eclc Subject: MSGGROUP#1801 SURVEY #1751-#1800 from MSGGROUP.1700-1750.1 From: MsgGroup Moderator - Einar Stefferud Reply-To: MsgGroup-Request at BRL To: MSGGROUP.BRL at BRL Message-ID: <[USC-ECLC]18-Aug-82 13:13:33.MSGGROUP> Via: Usc-Eclc; 18 Aug 82 16:14-EDT Via: Brl-Bmd; 18 Aug 82 17:22-EDT The TENEX formatted message file [ECLC]MSGGROUP.1701-1800.1 may be FTPed from [ECLC], or you may request that specific items be redistributed to you. Send any requests to MSGGROUP-REQUEST@ECLC or to MSGGROUP-REQUEST@BRL. ECLC supports FTP LOGIN ANONYMOUS with PASSWORD MSGGROUP. Best - Stef =========== Survey of #1751-#1800 from [ECLC]MSGGROUP.1701-1800: MSGGROUP#1751 SURVEY of [ECLC]MSGGROUP.1700-1750.1 6722 chars 5 May 1982 1900-PDT From: MsgGroup at ECL To: MSGGROUP at M MSGGROUP#1752 Re: UNIX date formats 1224 chars 5 May 1982 19:17-PDT From: Steve Hartwell To: MSGGROUP#1790 re: Net Mail Security Vulnerability Query 646 chars 7 Jul 1982 1530-PDT From: POSTEL at Usc-Isif To: TMPLee.D MSGGROUP#1791 NetMail Security Vulnerability Query 863 chars 8 July 1982 01:20-EDT From: David A Moon To: T MSGGROUP#1792 DRAFT Mail Specifications Available 1940 chars 8 Jul 82 23:15:00 PDT From: Postel@USC-ISIF MSGGROUP#1793 RFCs 813-817 Now Available 2369 chars 19 Jul 1982 1743-PDT From: POSTEL at USC-ISIF To: "Request MSGGROUP#1794 NJIT - Preliminary Announcement 4735 chars 15 Aug 1982 1404-PDT From: MsgGroup Moderator - Stefferud RFC819.TXT [SRI-NIC]RFC821.TXT [SRI-NIC]RFC822.TXT 1902 chars 15 Aug 82 11:22:33 PST From: Postel at USC-ISIF To: "Request MSGGROUP#1796 Re: #1794 NJIT - Preliminary Announcement 696 chars 17 Aug 1982 0751-EDT From: JMCKENDREE at Bbnb To: MsgGroup.b MSGGROUP#1797 Re: #1794 NJIT - Preliminary Announcement 4034 chars 17 Aug 1982 1150-PDT From: Einar Stefferud Remailed-to: msggroup.brl at BRL-BMD Via: Usc-Eclc; 19 Aug 82 3:56-EDT Via: Brl-Bmd; 19 Aug 82 12:31-EDT Vint - With XMAILR, nothing especially wrong happens when more than one instance of it (a mail sender) runs. The multiple XMAILRs battle each other for the individual queue requests, but (due to file interlocking) for any queue file one will emerge the definite victor. The other XMAILRs, being graceful losers, will move on to the next files. Benefits of doing this are: improved throughput for local mail; some improved throughput for network mail by consuming a greater share of the network bandwidth; a reduced chance of having the mailsystem hang up on a very expensive queue request (either to a very slow receiving host or with many recepients). The benefits are of variable merit; at times multiple XMAILRs have assisted me in "disaster recovery". A memorable day comes to mind right away; at one time the EDITOR-PEOPLE mailing list was an immediate expansion list. With ~200 recepients, it takes some time to deliver an EDITOR-PEOPLE message. A raging battle developed on EDITOR-PEOPLE about why EMACS was the most wonderful thing imaginable vs. why it's the most horrible thing imaginable, and soon SCORE found itself with several EDITOR-PEOPLE messages in its queue. Then came the coup de grace. XMAILR got hung up while delivering a message. It wasn't XMAILR's fault; it was blocked in a system call, and the particular condition it was blocked on left interrupts disabled (a TOPS-20 kernal bug). Timeouts are implemented as clock interrupts, and with interrupts disabled it had no way of getting out of the predicament it found itself in. It remained in this state for several hours; by the time I intervened there were several hundred queued messages. It eventually ran to over 1500 messages before it finally came under control. I had four XMAILRs running at once to drain the queues. The problem with multiple mail delivery processes, though, is that a site may not want extra network bandwidth consumed by the mailsystem. It depends upon what the site thinks is important. Also, it is not a panacea. Two XMAILRs can be "busied" out of service for a long time just by having two messages to a long mailing list. My experience with long mailing lists is that messages to them happen in large batches. Jon Solomon has suggested a "third class" form of mailing which will help somewhat. I've asked him to make a semi-formal writeup of the scheme he proposes to implement, because it seemed to me to be the sort of thing that MsgGroup would be interested in talking about before starting actual coding. I think a good form of "third class" mailing would be moderately complicated; not necessarily difficult, but somewhat more than the first thing that comes off the top of one's head. -- Mark -- 19-Aug-82 10:33:39-PDT,710;000000000001 Mail-from: ARPANET site BRL rcvd at 19-Aug-82 1031-PDT Mail-from: ARPANET site USC-ISI rcvd at 18-Aug-82 1705-PDT Date: 18 Aug 1982 1654-PDT Sender: CERF at Usc-Isi Subject: MSGGROUP#1803 Re: Multiple XMAILRs (Re: #1802) From: CERF at Usc-Isi To: Admin.MRC at Su-Score Cc: postel at Usc-Isif, MsgGroup at Usc-Eclc Message-ID: <[USC-ISI]18-Aug-82 16:54:40.CERF> In-Reply-To: Your message of 18 Aug 1982 1432-PDT Remailed-date: 19 Aug 1982 0056-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup.brl at BRL-BMD Via: Usc-Eclc; 19 Aug 82 3:56-EDT Via: Brl-Bmd; 19 Aug 82 12:33-EDT Mark, the "classes of mail" idea seems worth pursuing. Vnt 19-Aug-82 15:35:14-PDT,1445;000000000001 Mail-from: ARPANET site BRL rcvd at 19-Aug-82 1533-PDT Mail-from: ARPANET site BRL-BMD rcvd at 19-Aug-82 0910-PDT Date: 18 Aug 82 21:22:04-EDT (Wed) From: Doug Kingston To: CERF at Usc-Isi cc: Admin.MRC at Su-Score, postel at Usc-Isif, MsgGroup at Usc-Eclc Subject: MSGGROUP#1804 Re: #1800 Re: #1794 ... #1799 Remailed-date: 19 Aug 1982 1431-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup.brl at BRL-BMD Via: Usc-Eclc; 19 Aug 82 17:32-EDT Via: Brl-Bmd; 19 Aug 82 17:36-EDT Several points: Type of Verification: MMDF verifies all addresses that are handed it at submission time. If the address is local, it checks to make sure the account exists, if the address is foreign, it checks to make sure the host exists in one of several hosts tables (BRL and BRL-BMD have delivery paths other than the ARPANET). Each address is passed against the list. Even with caching of sitenames, with a list of several hundred names, it takes some time, especially on a heavily loaded PDP-11 during prime time. Multiple Servers and Delivery Processes: We commonly run more than one of both types of processes. Throughput: Throughput is a term that needs some careful use. How do you measure it? Is it TOTAL time/ Length or is it time after verification/Length, Does that include the address list verification interaction under SMTP? Etc. -Doug- 19-Aug-82 09:36:38-PDT,638;000000000001 Mail-from: ARPANET site BRL rcvd at 19-Aug-82 0935-PDT Date: 18 Aug 1982 1456-PDT From: Mark Crispin Subject: MSGGROUP#1805 Re: [Einar Stefferud: Re: #1794 ... Sender: ADMIN.MRC at Su-Score To: MsgGroup.BRL at BRL Reply-To: Admin.MRC at Su-Score Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In-Reply-To: Your message of 18-Aug-82 0232-PDT Via: Su-Score; 18 Aug 82 17:59-EDT Via: Brl-Bmd; 19 Aug 82 11:58-EDT Stef - No apology was needed, as no offense was taken. I think the discussion cleared the air. -- Mark -- ------- 19-Aug-82 19:57:53-PDT,525;000000000001 Mail-from: ARPANET site BRL rcvd at 19-Aug-82 1957-PDT Date: 19 August 1982 05:15 edt From: Schauble.Multics at Mit-Multics Subject: MSGGROUP#1806 FTP vs special mail protocol To: MsgGroup at Mit-Ai Via: Mit-Ml; 19 Aug 82 22:34-EDT I understand that all of the current efforts at mail systems are moving away from using FTP style protocols for mail transfer. Is there any documentation on why this is being done? If not, could someone offer thoughts on why the FTP protocols are inadequate? Paul 20-Aug-82 14:31:09-PDT,1364;000000000001 Mail-from: ARPANET site BRL rcvd at 20-Aug-82 1425-PDT Date: 20 Aug 1982 0934-PDT Sender: CERF at Usc-Isi Subject: MSGGROUP#1807 Re: FTP vs special mail protocol From: CERF at Usc-Isi To: Schauble.Multics at Mit-Multics Cc: MsgGroup at Mit-Ai Message-ID: <[USC-ISI]20-Aug-82 09:34:41.CERF> In-Reply-To: Your message of 19 August 1982 05:15 edt Via: Mit-Ml; 20 Aug 82 16:43-EDT Paul, two things are happening. The UK has moved towards something they call NIFTP which bags mail into files and moves files from host to host where a program is supposed to periodically open the bags (identifiable by special file names) and process them. In a different direction, SMTP has been developed to handle things in a more on-line fashion, negotiating whether certain items should be delivered at all, eliminating the dupliate transmission of message bodies for multiple receivers, etc. SMTP also includes specific information to aid in the forwarding of mail to other sites (something lacking in the old FTP/NCP mail). I think the general feeling, for the SMTP guys, was that you need some application-specific knowledge in the protocol to allow for some negotiation, and this wasn't immediately forthcoming from the existing FTP design. Rather than change all the FTP's, a mail-specific transport system was designed. Vint Cerf 20-Aug-82 15:01:18-PDT,3640;000000000001 Mail-from: ARPANET site BRL rcvd at 20-Aug-82 1500-PDT Date: 20 Aug 1982 1118-EDT Sender: DDEUTSCH at Bbna Subject: MSGGROUP#1808 Re: FTP vs special mail protocol From: DDEUTSCH at Bbna To: SCHAUBLE.MULTICS at Mit-Multics Cc: MsgGroup at Mit-Ai, DDeutsch at Bbna Message-ID: <[BBNA]20-Aug-82 11:18:19.DDEUTSCH> In-Reply-To: Your message of 19 August 1982 05:15 edt Via: Mit-Ml; 20 Aug 82 16:45-EDT There was a discussion of just that topic at a recent IFIP WG 6.5 meeting. There are at least three reasons that people came up with. 1. FTP is a unilateral action; mail requires two parties to agree to the transfer. In order to FTP a file, you must have proper access at the point the request is made, the current location of the file, and the final location of the file. In order to transfer a piece of mail, you must be allowed to initiate transfer, and the recipient must be willing to accept it. To reiterate, there is one "user" during FTP, but two during mail transfer. 2. File transfer is usually thought of as taking place over a direct connection between source and destination systems; mail transfer is now being modelled as being store-and-forward. This is not to say that store-and-forward file transfer is "wrong". It is just that right now there seems to be much more of a need for store-and-forward mail transfer than store-and forward file transfer. (Perhaps that has something to do with the differences between two people communicating and one person arranging where his files are stored. I very well might want converse with someone who happens to be far removed from me in terms of network topology. However, I would want to set up my data storage so that it was as close to me on the network, and therefore as easy to access, as possible.) 3. There are many differences between the services offered by a mail transfer protocol and a file transfer protocol. For example, mail transfer protocols may deal with forwarding, address validation, timed or repeated delivery, alternate destinations, notification of delivery, and the like. These are outside of the province of file transfer. On the other hand, an FTP provides services such as deleting and renaming files, appending to files, and listing directories. These are outside the province of mail transfer. It is true that file and mail transfer protocols have some common ground. They both must be able to reliably transfer data between two "adjacent" nodes on a network. Perhaps the best way to model the protocols is to break out the reliable transfer part, make it into its own, separate protocol, and build both FTP and mail transfer protocols on top of it. It could be diagrammed like this: +---------------+---------------+ | File Transfer | Mail Transfer | +---------------+---------------+ | Reliable Data Transfer | +-------------------------------+ The job of the reliable data transfer protocol would be to transfer data between two adjacent nodes. It would insert checkpoints in the data stream, and be able to recover if the connection went down. It could have different grades of service, so that the time-out interval for mail could be different from the time-out interval for files. Having both file transfer protocols and mail transfer protocols share a common reliable transfer protocol would keep us all from having to re-invent and re-implement the data transfer wheel. Debbie 20-Aug-82 16:09:16-PDT,1338;000000000001 Mail-from: ARPANET site BRL rcvd at 20-Aug-82 1604-PDT Date: 20 Aug 1982 1507-PDT From: POSTEL at Usc-Isif Subject: MSGGROUP#1809 FTP vs Mail To: msggroup at BRL Via: Usc-Isif; 20 Aug 82 18:16-EDT If you really go look at the FTP spec for the ARPANET or for the ARPA Internet you will see that the mail commands are really some sort of wart. The mail commands and the actual mail transfer do not make use of any of the general purpose FTP mechanisms. Mail does not use the FTP access control commands (USER, PASS, ACCT). Mail does not use any of the file type negotiation of FTP - exactly one file type is allowed for mail. I could go on. In the end one can conclude that the mail transfer, and commands, have very little to do with FTP, but at the time it was being invented that was a convienent place to put it. In the planning for moving from the NCP base to the TCP base, it seemed appropriate to split the MAIL and FTP into separate protocols with separate servers. I still think this is a good move. In general, i think that low frequency special case things should be moved toward using general purpose mechanism. In the case of mail we had a high volume special case thing distorting a general purpose mechanism for file transfer. So, we gave mail its own mechanism. --jon. ------- 21-Aug-82 12:37:30-PDT,693;000000000001 Mail-from: ARPANET site BRL rcvd at 21-Aug-82 1232-PDT Date: 21 Aug 1982 1154-PDT Sender: CERF at Usc-Isi Subject: MSGGROUP#1810 Re: FTP vs special mail protocol From: CERF at Usc-Isi To: DDEUTSCH at Bbna Cc: SCHAUBLE.MULTICS at Mit-Multics, MsgGroup at Mit-Ai Message-ID: <[USC-ISI]21-Aug-82 11:54:22.CERF> In-Reply-To: <[BBNA]20-Aug-82 11:18:19.DDEUTSCH> Via: Mit-Ml; 21 Aug 82 14:59-EDT DEBBIE, IN THE INTERNET WORLD, THE RELIABLE DATA TRANSPORT PROTOCOL IS THE TCP. WHILE TCP DOES NOT HAVE CHECKPOINTING, I RATHER IMAGINE THAT SUCH A FUNCTION MIGHT VARY IN FTP OR MAIL, DEPENDING ON THE TYPE OF OBJECTS BEING TRANSFERRED AND THE DATA STRUCTURES INVOLVED. VINT 21-Aug-82 14:42:08-PDT,3613;000000000001 Mail-from: ARPANET site BRL rcvd at 21-Aug-82 1441-PDT Date: 21 Aug 82 16:25:24-EDT (Sat) From: Dave Crocker To: MsgGroup at BRL Subject: MSGGROUP#1811 Verification & delays Via: Udel-Relay; 21 Aug 82 16:40-EDT One advantage of reading MsgGroup only periodically is that things have mostly died-down by the time I get to review everyone's comments. Plus, I don't feel compelled to rush to respond to someone's harangue. Then again, having just read the sequence about the XMailer/MMDF lockup, let me rush to respond... It is quite common for mail systems to perform some action, beyond simply storing a copy of the address and the message, when receiving mail from the net. I seem to recall that a number of systems expand mailing lists AND perform all local deliveries, before giving the final OK. MMDF just does address verification. The resulting delay for very large address lists has been known about for quite some time and is being fixed. This is part of a more general issue that is becoming interesting to me and has been one of the topics of discussion in IFIP WG 6.5. Mailing list expansion has, in general, been handled as a fundamental feature of the mail systems that permit it. I now believe that the correct model is to keep mailing lists out of the basic transport system and then provide them in as a value-added service. This comes in two flavors, both of which are being tried by people: 1. An additio to the basic transport service. Here, list handling is offered by the same "organization" that does transport, but it is a factored service. This has the advantage of keeping the mail object within the trusted(?) transport service's domain, but permits its handling to be performed asyncronously from normal transport. In MMDF, it will be a separate "channel". 2. Automatic user re-submission module. In this case, a user outside of the transport service has a program that receives mail and then re-submits it to the distribution list. The message often is massaged, such as having a sequence number assigned and having a Reply-To field added to direct users' comments to the distribution list. This might be viewed as a publishing service and is just the thing that Stef has planned for MsgGroup. It has the advantage of being implementable by any user, rather than requiring certification by the transport service; this also means that the original object can be changed arbitrarily and the transport service can no longer make any certification as to the correlation between the contents of the new message and the original. As to the question of simple address verification, I think that it is quite useful for transport participants to do a reasonable amount of handshaking. It is not uncommon for the recipient to have less information than the sending site and this limits the ability of receiving sites to respond so a class of errors. I am told that that is one of the reasons that the UUCP network can lose mail. It implements mail on top of a remote-execution mechanism (sort of file-transfer mechanism, but with finer-grained control), except that the basic mechanism does not know anything about mail. Dave P.S. I am glad to hear that XMAILR has finally put in a more rational approach to transmission delays than the original 5-minute limit that it imposed on the entire connection, independent of message size. XMAILR/MMDF interactions have consistently provided interesting opportunities to develop more sophisticated models of mail transport. 21-Aug-82 22:17:58-PDT,1173;000000000001 Mail-from: ARPANET site BRL rcvd at 21-Aug-82 2214-PDT Date: 22 Aug 1982 0005-EDT From: Larry Campbell To: CERF at Usc-Isi, DDEUTSCH at Bbna cc: SCHAUBLE.MULTICS at Mit-Multics, MsgGroup at Mit-Ai Subject: MSGGROUP#1812 Re: FTP vs special mail protocol Message-ID: <"MS11(2227)+GLXLIB1(1056)" 11849739882.13.71.26309 at DEC-MARLBORO> Regarding: Message from CERF at Usc-Isi of 21-Aug-82 1454-EDT In-reply-to: <[USC-ISI]21-Aug-82 11:54:22.CERF> Via: Mit-Ml; 22 Aug 82 0:27-EDT I think what's really needed today is a reliable @i[store-and-forward] protocol, which TCP is not. It's all very nice to be funded by the latest tax increase so as to have 56 KB lines that are always up, but in real life you'd like to be able to take advantage of dialup lines, AVD lines, and the like. The NBS protocol goes a long way towards allowing a general-purpose @i[store-and-forward] message system on which you could build either file transfer, mail transfer, or even transaction processing. You still need a reliable real-time protocol for each hop, and TCP fills the bill nicely. But it's not the total solution. -------- 23-Aug-82 03:49:55-PDT,1193;000000000001 Mail-from: ARPANET site BRL-BMD rcvd at 23-Aug-82 0330-PDT Date: 23 Aug 82 6:27:59-EDT (Mon) From: Michael Muuss To: Admin.MRC at Su-Score cc: CERF at Usc-Isi, postel at Usc-Isif, MsgGroup at Usc-Eclc Subject: MSGGROUP#1813 UNIX, TENEX, and Timeouts Mark - You overstate the UNIX -vs- TENEX issue; both can be easily modified. The timeout issue is really quite clear; the MMDF mailer that BRL is currently using is doing an incorrect thing by validating adresses upon receipt. MMDF is being fixed by it's maintainer to get around this problem in the future; for a mail system which tries to do so much, and is still in it's infancy, MMDF has been doing rather well. Until the fix is released, we will continue to suffer with the present techniques. Please don't be offended. Please don't feel compelled to "fix" XMAILR. If you can, tell people to bounce mail to slow sites off of BRL-BMD, which is especially patient. BRL and BRL-BMD have been mailing quite a number of digests and larger lists using the double-hop technique; it does work well enough. Hopefully, things will be better soon. Best, -Mike 23-Aug-82 10:13:54-PDT,754;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Aug-82 1005-PDT Date: 23 Aug 1982 1205-EDT Sender: DDEUTSCH at Bbna Subject: MSGGROUP#1814 Re: FTP vs special mail protocol From: DDEUTSCH at Bbna To: LCAMPBELL at Dec-Marlboro Cc: CERF at Usc-Isi, DDEUTSCH at Bbna Cc: SCHAUBLE.MULTICS at Mit-Multics, MsgGroup at BRL Message-ID: <[BBNA]23-Aug-82 12:05:19.DDEUTSCH> In-Reply-To: <"MS11(2227)+GLXLIB1(1056)" 11850112741.30.71.6978 at DEC-MARLBORO> Via: Bbna; 23 Aug 82 12:09-EDT Larry- My comment was on mail and file transfer protocols in general, not specifically on the NBS protocols. However, since you raised the issue, I would like to point out that the NBS mail transfer protocols are intended to handle store-and-forward. Debbie 23-Aug-82 10:29:02-PDT,2304;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Aug-82 1026-PDT Date: 23 Aug 1982 1157-EDT Sender: DDEUTSCH at Bbna Subject: MSGGROUP#1815 Re: FTP vs special mail protocol From: DDEUTSCH at Bbna To: CERF at Usc-Isi Cc: DDEUTSCH at Bbna, SCHAUBLE.MULTICS at Mit-Multics Cc: MsgGroup at BRL Message-ID: <[BBNA]23-Aug-82 11:57:56.DDEUTSCH> In-Reply-To: <[USC-ISI]21-Aug-82 11:54:22.CERF> Via: Bbna; 23 Aug 82 12:14-EDT Vint- The Reliable Transfer Protocol would operate above TCP on the Internet. It assumes that dependable, end-to-end data transport is provided by a lower protocol layer. RTP would build upon this in two ways: 1. Should the connection fail, the sending RTP entity would attempt to reestablish it and resume transmission. Because it inserts checkpoints into the data stream, it would usually be able to pick up fairly close to where it left off. Not having to restart from the beginning could be very valuable especially when transferring large pieces of data (such as fax) or when running over low-bandwidth connections (such as regular telephone lines). 2. RTP would provide a queuing. That is, the sending RTP entity would take care of trying to set up a connection with the receiving RTP entity, shielding its user from this task. This transaction-like behavior would make things simpler for the RTP user. It would only have to decide where the data should go, and hand that destination and the data to RTP. Some time later, it would learn if transfer had taken place. Your comment about checkpointing raises an interesting question about protocol architecture. When does it make sense to combine the general use of checkpointing, efficient recovery from a failure, with application-specific uses, such as delineating the structure of a data object? In general, I wonder how frequently it is useful to receive only part of a piece of data. Even if you checkpointed at points that made sense in terms of the data being transmitted, how frequently does that buy you something useful? My first impulse is to keep those goals separate, and use some other mechanism for indicating data type and structure. That would yield a more generally useful protocol. Debbie 23-Aug-82 14:37:34-PDT,682;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Aug-82 1434-PDT Date: 23 Aug 1982 1013-EDT From: Larry Campbell To: CERF at Usc-Isi cc: DDEUTSCH at Bbna, SCHAUBLE.MULTICS at Mit-Multics, MsgGroup at Mit-Ai Subject: MSGGROUP#1816 Re: FTP vs special mail protocol Message-ID: <"MS11(2227)+GLXLIB1(1056)" 11850112741.30.71.6978 at DEC-MARLBORO> Regarding: Message from CERF at USC-ISI of 22-Aug-82 2046-EDT In-reply-to: <[USC-ISI]22-Aug-82 17:46:50.CERF> Via: Mit-Ml; 23 Aug 82 17:01-EDT No, I only meant that TCP wasn't sufficient. If the NBS transport protocol doesn't handle store-and-forward, then it's insufficient also. -------- 23-Aug-82 17:12:11-PDT,646;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Aug-82 1709-PDT Date: 23 Aug 1982 1637-PDT From: COHEN at Usc-Isib Subject: MSGGROUP#1817 Re: FTP vs special mail protocol To: DDEUTSCH at Bbna cc: CERF at Usc-Isi, SCHAUBLE.MULTICS at Mit-Multics, MsgGroup at BRL In-Reply-To: <[BBNA]23-Aug-82 11:57:56.DDEUTSCH> Via: Usc-Isib; 23 Aug 82 19:39-EDT Folks, Since "RTP" is already in use for several years for Real-Time-Protocol -- how about having another name for the Reliable-Transfer-Protocol, or at least use other acronym for it? Cheers, Danny. ------- 23-Aug-82 18:06:25-PDT,652;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Aug-82 1804-PDT Date: 22 Aug 1982 1746-PDT Sender: CERF at Usc-Isi Subject: MSGGROUP#1818 Re: FTP vs special mail protocol From: CERF at Usc-Isi To: LCAMPBELL at Dec-Marlboro Cc: DDEUTSCH at Bbna, SCHAUBLE.MULTICS at Mit-Multics Cc: MsgGroup at Mit-Ai Message-ID: <[USC-ISI]22-Aug-82 17:46:50.CERF> In-Reply-To: <"MS11(2227)+GLXLIB1(1056)" 11849739882.13.71.26309 at DEC-MARLBORO> Via: Mit-Ml; 23 Aug 82 20:28-EDT LARRY, DID YOU MEAN IN YOUR RECENT NOTE THAT THE NBS TRANSPORT PROTOCOL HANDLES STORE AND FORWARD? I CERTAINLY NEVER GOT THAT IMPRESSION FROM READING THE SPEC. VINT 23-Aug-82 18:10:17-PDT,700;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Aug-82 1809-PDT Date: 23 Aug 1982 1730-PDT From: POSTEL at Usc-Isif Subject: MSGGROUP#1819 Re: FTP vs special mail protocol To: COHEN at Usc-Isib, DDEUTSCH at Bbna cc: CERF at Usc-Isi, SCHAUBLE.MULTICS at Mit-Multics cc: MsgGroup at BRL, POSTEL at USC-ISIF Via: Usc-Isif; 23 Aug 82 20:41-EDT In response to the message sent 23 Aug 1982 1637-PDT from COHEN@Usc-Isib Especially since RTP (= Real Time Protocol) is opposite of "Reliable Transfer Protocol" in the time sense (maybe it should be the "take forever protocol"). I am not persuaded that another layer of protocol is needed besides TCP for reliability. --jon. ------- 26-Aug-82 23:59:20-PDT,2648;000000000001 Mail-from: ARPANET site BRL rcvd at 26-Aug-82 2356-PDT Date: 26 Aug 1982 2250-PDT Sender: GEOFF at Sri-Csl Subject: MSGGROUP#1820 Xerox Woes -- Long lines with out returns in them. From: the tty of Geoffrey S Goodfellow at SRI-CSL Reply-To: Geoff at Sri-Csl To: MsgGroup at BRL, Header-People at Mit-Mc Message-ID: <[SRI-CSL]26-Aug-82 22:50:49.GEOFF> Via: Sri-Csl; 27 Aug 82 2:02-EDT The following poop is reputed to come from Xerox. It deals with the problem of letting long lines out to pollute our old outmoded terminals which are afflicted with inferior technology(?). Hopefully this is not a veiled scheme to induce us all to buy STARS!? Here is the Xerox statement of the problem, and the (unfortunate) disposition of the Xerox mail system maintainers on the issue. ======= Begin Xerox Poop ====== Description: Getting mail with long sentences without CRs poses serious problems for many ARPAnet recipients. It is not reasonable to require Xerox personell to remember to manually apply the Chop hack to such msgs before sending. MailSend should incorporate the Chop feature, the way Laurel does. Disposition: Rejected "This is the wrong solution to the problem. As is stated in the RFC to replace 733 (the standard for ARPA messages) ... it is interesting to note that the receiver of a message can exercise an extraordinary amount of control over the message's appearance." By placing explicit CRs into the message (where just white space line breaking was intended by the user) on the way out, the formatting ability of the remote displayer is limited. As someone noted recently "In general, the sender cannot know the properties of the receiver's terminal; so it is inappropriate for the sender to insert automatic line breaks for formatting purposes. Indeed, such insertion can make the receiver's job much more difficult: it is far easier for the receiver to insert line breaks as they are needed than for it to distinguish CRLFs that were inserted by the sender's mail program from ones that truly represent breaks in the text." ====== End Xerox Poop ====== Does anyone out in ARPANET, or CSNET, or INTERNET, (other than Xerox StarNet) agree with this type of rationale? Does anyone like these long lines? Is there anyone out there with a terminal or a system that can and does break long lines as the Xerox argument claims we can and do? I find the Xerox attitude on this issue rather anti-social myself.... Then of course, there is also the issue of Xerox Internet mail leaking out onto the ARPANET Internet without "at PARC-MAXC" on its from fields. ------- 27-Aug-82 01:37:51-PDT,3046;000000000001 Mail-from: ARPANET site MIT-MC rcvd at 27-Aug-82 0137-PDT Mail-from: SU-NET host Shasta rcvd at 27-Aug-82 0123-PDT Date: 27 Aug 1982 01:23-PDT - Friday To: Geoff at Sri-Csl Cc: MsgGroup at BRL, Header-People at Mit-Mc Subject: MSGGROUP#1821 Re: Xerox Woes -- Long lines with out returns in them. Reply-to: Hartwell at Score In-reply-to: Your message of 26 Aug 1982 2250-PDT. <[SRI-CSL]26-Aug-82 22:50:49.GEOFF> From: Steve Hartwell I agree with the Xerox position. Although I am sympathetic to those who do not have the easy capability to reformat incoming messages (I mean in their personal mailboxes -- It would be a gross error to implement linefolding at the input MTP level) I feel very strongly about interfering with the contents (body) of mail messages. For one, it is both conceivable and in practice on this machine for mail messages to be processed by programs rather than people. For example, on Shasta you can send mail to our Canon printer. (Remotely, from any machine). I would certainly NOT want the sending program to break lines at some arbitrary boundary for me, for every reason under the sun. If this seems like a trivial example, I can provide more if you'd like. Moreover, given that there are so many different terminal widths, it seems unfair to choose what would have to be the lowest common denominator of them all. For those of you who think this is 80, or even 72, think again. The number of users with Apple I 40-column monitors is not a small minority. No, the width of the output is the responsibility of the thing that is doing the output. I can no more insist that the sender respect my terminal width than I would insist that s/he include screen formatting control characters for my particular terminal type. It doesn't do any harm to ask contributors to consider the audience when sending a message; on that basis I would add my opinion that it is unwise to send messages with long lines unless there is some gainful purpose to doing so. (While I'm at it, could you Puh-LEEZE not right-justify text... !) Item 2: about not adding "at PARC-MAXC" Any message which does not contain a proper, valid, and attainable return address should be rejected. Mail headers are read and interpreted by programs routinely, and should conform to proper format for that reason (as compared to the message body, which has no such requirement, and shouldn't). Besides, it's not fair to force readers to guess how to reply to messages or edit the incoming messages so that the headers are in the format they should have been in the first place. I potentially hang myself here since Shasta is on the local Stanford ethernet and my return address by default would be indirected through Sumex or Score, and some mailers do not permit addresses of the form Hartwell@Shasta at Sumex (Notably, USC-ECLC, the home of our beloved Moderator....). Fortunately, I can provide a Reply-to field that forwards to me here at Shasta. 27-Aug-82 02:17:51-PDT,1539;000000000001 Mail-from: ARPANET site BRL rcvd at 27-Aug-82 0213-PDT Date: 27 August 1982 0434-EDT (Friday) From: Craig.Everhart at Cmu-10a To: Geoff at Sri-Csl Subject: MSGGROUP#1822 Re: Xerox Woes -- Long lines with out returns in them. CC: MsgGroup at BRL In-Reply-To: <[SRI-CSL]26-Aug-82 22:50:49.GEOFF> Message-Id: <27Aug82 043445 CE10@CMU-10A> Via: Cmu-10a; 27 Aug 82 4:38-EDT I like the idea of the long lines. Admittedly, at the moment my mail reader just wraps the lines around the screen with no regard for where the word breaks are, but they're absolutely right that in a world of different-width screens/scrollers, with or without variable-pitch fonts, there's no sense in imposing a given line-length regime. Let the mail readers do that part of the presentation too! There are probably lots of systems out there that insist on buffering lines of text before processing them; such systems will probably be confused by stretches of over about 100 characters without a line break. (I know of at least one--our FTP server, before I got to it and had it do something reasonable for very long lines of text.) Does that mean they're wrong in allowing the receiver maximum flexibility? It's *not* like a very fine break-lines-at-word-breaks algorithm is hard to code, you know. With a little forethought, you can even figure out something reasonable to do with Tab characters, should they appear other than after a line break. I suspect we'd be better off without the ad-hominem arguments, too. Craig 27-Aug-82 02:17:57-PDT,684;000000000001 Mail-from: ARPANET site BRL rcvd at 27-Aug-82 0216-PDT Date: 27-Aug-82 01:46-PDT From: KELLEY at Office-2 Subject: MSGGROUP#1823 RE: Xerox Woes -- Long lines with out returns in them. To: Geoff at Sri-Csl Cc: MsgGroup at BRL, Header-People at Mit-Mc Identifier: TYM-KIRK-13ASX In-reply-to: <[SRI-CSL]26-Aug-82 22:50:49.GEOFF> Length: 1 page(s)[estimate] Posted: 27-Aug-82 00:45-PDT Via: Office-2; 27 Aug 82 4:50-EDT As a Tymshare (Augment) Mail user, I like the official Xerox policy and plan to do it here for exactly the reasons given. It allows receiving tables in tact and still "chopping" paragraphs as needed by Augment readers' window sizes. -- Kirk 27-Aug-82 02:56:37-PDT,2376;000000000001 Mail-from: ARPANET site BRL rcvd at 27-Aug-82 0253-PDT Date: 27 August 1982 04:54 edt From: Barry.Margolin at Mit-Multics Subject: MSGGROUP#1824 Re: Xerox Woes -- Long lines with out returns in them. Sender: Margolin.Multics at Mit-Multics To: Hartwell at Su-Score cc: Geoff at Sri-Csl, MsgGroup at BRL, Header-People at Mit-Mc In-Reply-To: Message of 27 August 1982 04:32 edt from Steve Hartwell Via: Mit-Multics; 27 Aug 82 5:01-EDT We recently went through much of the same controversy over when line filling should take place (this was in the context of a subsystem called Forum, which is an online conferencing system for Multics). Both sides have their merits, but we eventually opted to default to filling by the creator of the message, with a reader option to allow him to refill the message, and a writer option to disable filling. The main point of our reasoning was that the majority of input is just prose text, and most users are using terminals that support the default filling line length (72, I believe). It is wasteful of computrons for each reader of a message to have to fill the message, when most would have been satisfied with the filling that happened once, at submission time. For those who do want to fill when they print the message (because they are on a small screen micro, presumably) it is no great trick to fill a piece of text that already contains line breaks; newlines are considered whitespace by the filler. Another reason that we opted for input filling is that the submitter might have gone to some pains to format his text in a particular way; if the reader is always refilling, then it is difficult for him to make the output look correct. Overlength lines might be intended to come out overlength, but there is no way to convey this information to the reader's formatter. If there were enough computrons in the world and a standard mail text-formatting language, then it would probably be right to make message text be the input for this formatter, so that the sender could specify his intended format exactly. On the other hand, this might make electronic mail too difficult for naive users to use. barmar PS: Note that this message is one long paragraph. I hope your mail-reader is smart enough to put in the paragraph breaks for you... 31-Aug-82 21:08:11-PDT,3609;000000000001 Mail-from: ARPANET site BRL rcvd at 31-Aug-82 2104-PDT Mail-from: ARPANET site MIT-MC rcvd at 27-Aug-82 0255-PDT Date: 27 Aug 1982 0223-PDT From: Mark Crispin Subject: MSGGROUP#1825 Re: Xerox Woes -- Long lines with out returns in them. Sender: ADMIN.MRC at Su-Score To: Geoff at Sri-Csl cc: MsgGroup at BRL, Header-People at Mit-Mc Reply-To: Admin.MRC at Su-Score Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In-Reply-To: Your message of 26-Aug-82 2250-PDT Remailed-date: 30 Aug 1982 1754-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup at BRL-BMD Via: Usc-Eclc; 30 Aug 82 20:56-EDT Via: Brl-Bmd; 31 Aug 82 22:53-EDT The SMTP standard, while it recommends that no limit be imposed upon lengths received, establishs maximum transmitted lengths. "The maximum total length of a text line including the is 1000 characters (but not counting the leading dot duplicated for transparency)." This translates to no more than 12 80-character lines; line 13 will violate the SMTP standard unless a line break is forced. If Xerox's MailSend maintainers really did send that message, it is an example of monumental egotism which reflects poorly on the entire Xerox organization, including the many individuals there who have worked long and hard to establish better communications between Xerox and the rest of the world (not to mention having contributed a good deal to the state of the art in general). I hope that the Xerox personnel on these lists will do us a favor by putting pressure to bear on the individuals who have this attitude. Xerox's software, as evidenced by the Alto/Dolphin software I am most familiar with, goes to some lengths to shield the user from the need to format text. In particular, it dynamically formats the text in real time as the user edits it, PROVIDED the user enters the text as a run-on, unformatted line. This is similar to what EMACS does with Auto Fill mode; unlike EMACS, the Xerox style formatting is done continuously (EMACS converts the last space into a CRLF if the line becomes too long). This relieves the Xerox user from issuing a formatting command (the EMACS M-Q command), but also lulls the Xerox user into a false sense of security that the message will look to the recepient the way it looks to the sender. The reason is that while EMACS actually converts the stored spaces into CRLF's, the Xerox software stores the text as specified by the user and only displays it in a formatted fashion. The argument that the sender does not know of the properties of the receiver's terminal is spurious, as is the claim that the receiver would have trouble interpreting between needed line breaks and true breaks in the text. Most Internet senders assume a "canonical terminal width" of between 65 and 72 characters. This length displays reasonably on most terminals; terminals with shorter widths generally have features to work around their limitation. For example, my Atari microcomputer's terminal emulator deals with its 40 character/line limit by doing Xerox- style dynamic formatting at display time; a 65 to 72 character line comes out just about right. The argument about line breaks vs. text breaks confuses me. A premature line break is obviously a text break. Paragraph breaks are preferably expressed as two consecutive line breaks; a combination pleasing to the eye on almost any medium displayed upon. -- Mark -- ------- 2-Sep-82 02:18:21-PDT,3105;000000000001 Mail-from: ARPANET site BRL rcvd at 2-Sep-82 0214-PDT Mail-from: ARPANET site MIT-MC rcvd at 27-Aug-82 0521-PDT Date: 27 Aug 1982 0510-PDT From: Mike Peeler Subject: MSGGROUP#1826 RE: Xerox Woes -- Long lines with out returns in them. To: KELLEY at Office-2 cc: Geoff at Sri-Csl, MsgGroup at BRL, Header-People at Mit-Mc, Human-Nets at Su-Score In-Reply-To: Your message of 27-Aug-82 0146-PDT Remailed-date: 2 Sep 1982 0110-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup at BRL-BMD Via: Usc-Eclc; 2 Sep 82 4:10-EDT Via: Brl-Bmd; 2 Sep 82 4:12-EDT I agree with the 0X people. It's so easy to do something right about long lines, and so lazy to bomb out on them, that I just pity the poor people who have to work on systems with such brain damage. I have no sympathy, however, for those on micros with 40-character wide displays and no lowercase. I would opt to use my Smith-Corona and correcting cartridge rather than deal with such idiocy. I support 0X' stand on long lines even though I've always reformatted digests I put out to 70 columns, and even though I myself limit my text to columns 10 through 60. The former was my tribute to the reality that some of our readers do not live in the best of all possible worlds. The latter was the result of my own evaluation of the human factors involved in reading. Printed text of the readable variety is between eight and twelve words per line. A left margin prevents automatic text-processors from reformatting: given that I'm doing the formatting on the sending side, I don't want it messed up at the other end. So I chose left and right margins of ten each from columns 0 and 70, respectively, which puts about ten words on a line. With only 40 columns the right margin would get excessively ragged, and with 60, it would be centered on the screen instead of around reading position, which is normally somewhat to the left of real center and somewhat more so on a crt. For you word processor fans, EMACS makes all this happen automagically. Let it be known that even after 0X' chopper gets through, the lines remain longer than eighty characters, a fact I detected by the tell-tale warparound (sic) that messages from our Altos produce on our cheapo Heap... uh, Zenith's. (I'm even now on an Alto masquerading as a Datamedia. It's great!) That puts them more than 25% beyond optimal reading range. On another topic, current on Human-Nets, I have just switched back to two spaces after periods. I noticed that I do read faster when I can isolate the sentences visually. (Holistic parsing?) In most print the punctuation abuts tightly against the previous character, so that there is no real need for much extra distance. With a fixed-width font, though, I think an extra space does help. Regards, Mike ------- 27-Aug-82 07:20:43-PDT,402;000000000001 Mail-from: ARPANET site BRL rcvd at 27-Aug-82 0716-PDT Date: 27 Aug 82 9:00:40-EDT (Fri) From: Ron Natalie To: msggroup at BRL Subject: MSGGROUP#1827 Long Lines? Via: Brl-Bmd; 27 Aug 82 9:26-EDT Aslongasweareremovingthecarriagereturns,whydon'twegetridoftheextrawhitespacecausedbyplacingspacesandtabsbetweenwordsinaletter.It'stimeforthemailreaderstodotheirshareofthework.Ron 2-Sep-82 02:23:21-PDT,1125;000000000001 Mail-from: ARPANET site BRL rcvd at 2-Sep-82 0223-PDT Mail-from: ARPANET site BRL rcvd at 29-Aug-82 1228-PDT Date: 27 August 1982 02:14-EDT From: Earl A Killian Subject: MSGGROUP#1828 Xerox Woes -- Long lines with out returns in them. To: Geoff at Sri-Csl cc: HEADER-PEOPLE at Mit-Mc, MsgGroup at BRL Via: Mit-Mc; 29 Aug 82 14:42-EDT Remailed-date: 2 Sep 1982 0137-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup at BRL-BMD Via: Usc-Eclc; 2 Sep 82 4:37-EDT Via: Brl-Bmd; 2 Sep 82 4:47-EDT I don't think Xerox is winning, but thought I'd answer the question you raised: Is there anyone out there with a terminal or a system that can and does break long lines as the Xerox argument claims we can and do? The operating system here wrapped the lines with an overflow indication, so I had no trouble reading the message. So I didn't need to, but just for fun, I asked my mail reader to refill the message text as well. It didn't do this automatically (I'd consider that a bug), but it was a single simple command. 27-Aug-82 14:37:50-PDT,1250;000000000001 Mail-from: ARPANET site BRL rcvd at 27-Aug-82 1432-PDT Date: 27 Aug 1982 12:43 PDT From: AHenderson at Parc-Maxc Subject: MSGGROUP#1829 Re: Xerox Woes -- Long lines with out returns in them. In-reply-to: Admin.MDP's message of 27 Aug 1982 0510-PDT To: Mike Peeler cc: KELLEY at Office-2, Geoff at Sri-Csl, MsgGroup at BRL, Header-People at Mit-Mc, Human-Nets at Su-Score Via: Parc-Maxc; 27 Aug 82 16:32-EDT Mike: The other piece that you might want to factor into your arguments is that not all terminals measure line length in "characters". Some use "points" or "inches". What with variable pitch fonts and different type sizes, families and faces, breaking lines into "reasonable" lengths becomes even more problematic to handle at the sending end. In fact, this discussion reminds me of another in the field of graphics: resolution independence; there too, it is important to separate content from form in a way which still honors the creators intent. All the best, Austin PS: Let me hasten to add that in this matter I speak for myself, not the company that I am pleased to work for. Were I to do the latter, I'd probably have to spend more time than I'd like with the lawyers. 27-Aug-82 14:41:17-PDT,1496;000000000001 Mail-from: ARPANET site BRL rcvd at 27-Aug-82 1437-PDT Date: 27 Aug 1982 1340-PDT From: POSTEL at Usc-Isif Subject: MSGGROUP#1830 Effective Communication To: MsgGroup at BRL, Header-People at Mit-Mc To: Human-Nets at Su-Score Via: Usc-Isif; 27 Aug 82 16:52-EDT When the sender or speaker cares about effectively communicating he or she adapts to the capabilities of the receiver or listener. When we want childern to understand something we speak slowly and use common small words. When we send computer mail we adapt to a "average capability" receiver. There are of course differences of opinion as to what this "average capability" is, and even more differences about what it should be. I think that for some time the "average capability" has been reasonably assumed to be the ability to handle ASCII characters with up to 72 characters on a line. The assumption is that these will be fixed width. There are no real expectation that format effectors like back space and even tab will do reasonable things for the "average capability" receiver. I think it is pretty clear that receivers with 40 character lines know that they are below average, and don't complain about longer lines. When better than average senders communicate with better than average receivers they can make use of their common superior features, but when they want to include the average receiver in their discussion, they should come down to our level. --jon. ------- 2-Sep-82 14:38:39-PDT,5404;000000000001 Mail-from: ARPANET site BRL rcvd at 2-Sep-82 1436-PDT Mail-from: ARPANET site MIT-MC rcvd at 27-Aug-82 1438-PDT Mail-from: SU-NET host Shasta rcvd at 27-Aug-82 1422-PDT Date: 27 Aug 1982 14:22-PDT - Friday To: Geoff at Sri-Csl, MsgGroup at BRL, Header-People at Mit-Mc, Human-Nets at Su-Score Subject: MSGGROUP#1831 Re: Xerox Woes -- Variable width fonts In-reply-to: Your message of Friday, 27 August 1982, 15:54-EDT. From: Brian Reid Remailed-date: 2 Sep 1982 1222-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup at BRL-BMD Via: Usc-Eclc; 2 Sep 82 15:21-EDT Via: Brl-Bmd; 2 Sep 82 15:32-EDT Good grief; this has certainly degenerated into a lot of @i[ad hominem]. Let me, as an outsider to Xerox, explain what is going on before people get angrier in the absence of the facts. It is certainly true that some Xerox-origin mail violates the Arpanet format standards, but there is no malice or piggishness behind it. Xerox has an in-house mail system that handles many times as much mail as the Arpanet. That mail system is divided into two distinct parts, namely the delivery part and the sender/reader part. The delivery part is called "Grapevine"; it is documented in various public technical reports. It is uniformly used by everyone, and works beautifully; it is a much nicer mail system than anything I have seen on the Arpanet or in Unix-land. This mail system originated in the Xerox reseach lab in Palo Alto. Originally there was an Alto mail program, named Laurel (also documented in a public technical report) that sent, received, filed, and managed mail. Laurel is a masterpiece of human engineering, but not terribly functional. One of the properties of Laurel was that it automatically wrapped lines to fit on the screen, so that a message would appear properly regardless of whether or not the sender and the receiver had the same screen parameters. At some point in the design of their mail system, the folks at Xerox addressed the issue of export to alien networks, one of which is the Arpanet. They seem to have decided (correctly) that the transport mechanism (grapevine) should not mess with the contents of a mail message, but only move it around. If the requirements of an alien network were different, it was the responsibility of either the portal program (at the Xerox/Alien boundary) or of the user program (at the sender's fingertips) to meet those requirements. I am a little fuzzy here, but I believe that what happened next was that an engineering decision was made to put the formatting code in the user program (Laurel) and not in the portal program. I don't know the thinking behind this step, and in from my vantage point it seems to have been the wrong place to put it. Nevertheless, Laurel was modified so that when it was sending a message to an Arpanet recipient, it carefully formatted the message to conform to Arpanet format standards. This was all happening at the time that RFC733 was being settled, and there was a certain amount of disagreement as to just what those standards were, but because Laurel was developed in the research community there and the Arpanet was used to communicate with other researchers, it happened. The Xerox mail system was such a success that it migrated out of the computer research lab and into all corners of the company. The Xerox internet connects all kinds of interesting places, thousands of miles apart, and they all exchange mail uniformly, without any need to know the physical or logical location of the recipients. In particular, it migrated into the development branches of the company, who had computers other than the Alto, and who therefore could not run Laurel. Lacking an Alto on which to run Laurel, somebody in a non-research division wrote a different program, which ran on his development computer, that handled mail and interfaced to Grapevine. Since I have never seen this different program documented in a public place, I shouldn't say more about it, but let me say that the person who wrote it had no interest in communicating with the Arpanet, and wrote a (fairly simplistic) program that would let people in the development branch send mail to each other. He failed to include any code for compatibility with alien networks, but the thing works just fine for sending mail inside Xerox, which is what he used it for. As more people got these non-alto computers, they began using this alternative mail program. Many of them are sufficiently removed from the Arpanet research community that they probably have no idea that their mail escaping to the Arpanet is violating its standards. There is certainly no sneering at the standards, just ignorance of them, and since only one message in many many thousand is an Arpanet message, this does not appear to the folks who maintain that program (if anybody maintains it) to be a big problem. I consider this kind of situation to be an inevitable social consequence of a fully distributed computing environment. My own solution to it has been to add some simple code to my mail-reading program to wrap lines for me as it displays the text on my screen. It leaves the file intact, in case I need to preserve the original line breaks for some reason. Brian Reid Stanford 28-Aug-82 14:45:23-PDT,1515;000000000001 Mail-from: ARPANET site BRL rcvd at 28-Aug-82 1443-PDT Date: 27 August 1982 07:48-EDT (Friday) From: K Shane Hartman To: Craig.Everhart at Cmu-10a Cc: Geoff at Sri-Csl, MsgGroup at BRL Subject: MSGGROUP#1832 Xerox Woes -- Long lines with out returns in them. Via: Mit-Xx; 28 Aug 82 16:43-EDT In addition, the long lines are compatible with the multimedia (RFC767) representation of plain text (the paragraph "protocol") proplist:( name: Protocol name: Paragraph name: Version index: 1 name: Data list:( text: ;Each text element is a "paragraph". text: ... ):endlist ):endlist There is no restriction on the contents of the text elements (other than size: a text element has length less than 77777777 octal). In particular, a "long" text element may or may NOT contain CRLF's depending on the mail composer. Presumably, the mail reader would be smart enough to deal with lines that are too long for the display terminal it is connected too. Our experimental mail reader for multimedia messages will treat text in this manner. I don't see why a reader for SMTP internet messages cannot perform the same formatting functions, thus making the recipient independent of the terminal on which the message was composed (and providing a nicer appearance). I think Xerox is right about this issue. Those with dumb mail readers will have to put up with wrapped lines, which aren't that difficult to read anyway. -|Shane|- ------- 27-Aug-82 15:11:38-PDT,2228;000000000001 Mail-from: ARPANET site BRL rcvd at 27-Aug-82 1507-PDT Date: 27 August 1982 1653-EDT (Friday) From: Craig.Everhart at Cmu-10a To: Admin.MRC at Su-Score Subject: MSGGROUP#1833 Re: Xerox Woes -- Long lines with out returns in them. CC: MsgGroup at BRL In-Reply-To: Mark Crispin\@SU-SCORE's message of 27 Aug 82 04:23-EST Message-Id: <27Aug82 165344 CE10@CMU-10A> Via: Cmu-10a; 27 Aug 82 17:07-EDT Do you know what an ``ad hominem'' argument is? Do you know why it's usually considered tasteless? We're comparing two different paradigms for the representation of running prose. One puts line breaks in explicitly. The other, in assuming that the reader can put line breaks at word breaks where appropriate for the particular device, gains a measure of generality the other paradigm lacks, generality useful in the more-and-more-heterogenous world we compute in. You're just lucky that breaking 65-to-72-character lines tends to look OK on a 40-character screen. What if the screen were 32 characters wide? Or 64? Yes, EMACS auto-fill puts explicit CRLFs into the text, rather than leaving line breaks as spaces and displaying them as line breaks. I could argue that its doing so is inconvenient because there's nothing special about that word break (at the end of the line); wouldn't it be handier if the word breaks were re-shuffled when I added text to the middle of a line in an auto-filled paragraph? Of course, that's not a mail-transmission issue, but it's a pleasant piece of fallout from the different paradigm for running prose. The Xerox text paradigm makes explicit CRLFs mean something special--namely, the obvious thing, that the following characters should start at the left margin. As others have noted, this allows hand-formatted text in the middle of running prose. Interpreting CRLFs as ordinary word breaks and re-filling destroys this property. Can't we take the issue seriously? Instead of either poking fun or whipping out the protocol handbook from our hip holster? What's wrong with growth? It is unfortunate if, as you say, the SMTP protocol currently insists on a CRLF every 1000 characters. Unfortunate, but not fatal. Craig Everhart 27-Aug-82 16:31:08-PDT,1505;000000000001 Mail-from: ARPANET site BRL rcvd at 27-Aug-82 1629-PDT Date: 27 August 1982, 15:54-EDT - Friday From: Robert W Kerns Subject: MSGGROUP#1834 Re: Xerox Woes -- Variable width fonts To: AHenderson at Parc-Maxc Cc: Mike Peeler , KELLEY at Office-2, Geoff at Sri-Csl, MsgGroup at BRL, Header-People at Mit-Mc, Human-Nets at Su-Score In-reply-to: The message of 27 Aug 82 15:43-EDT from AHenderson at PARC-MAXC Via: Mit-Mc; 27 Aug 82 18:34-EDT Coming from a competing environment with variable width fonts, I'd like to point out that in order to transmit anything remotly tabular, there must be some sort of agreement on what the relative widths of characters are. Seems the only feasible way to do that currently is to use fixed-width fonts for displaying messages. That's what we do; and I can't say that fixed width fonts have caused me cancer of the eyeball, but they have allowed me to make sense of many messages that would have been rendered unreadable with variable-width fonts. To use variable-width fonts when composing a message meant for the outside world strikes me as elitist and isolationist, given the current state in the rest of the world. This doesn't mean I'm not willing to talk about improving the rest of the world so we could use variable-width fonts, graphics, sound, animation, or what have you in messages, but I do recognize the current limitations and stick to fixed-width ascii messages. 27-Aug-82 16:31:06-PDT,1957;000000000001 Mail-from: ARPANET site BRL rcvd at 27-Aug-82 1629-PDT Date: 27 Aug 1982 1522-PDT Sender: CERF at Usc-Isi Subject: MSGGROUP#1835 Re: Effective Communication From: CERF at Usc-Isi To: POSTEL at Usc-Isif Cc: MsgGroup at BRL, Header-People at Mit-Mc Cc: Human-Nets at Su-Score Message-ID: <[USC-ISI]27-Aug-82 15:22:40.CERF> In-Reply-To: Your message of 27 Aug 1982 1340-PDT Via: Usc-Isi; 27 Aug 82 18:33-EDT Jon, Basically I am in agreement with you except for one point. It appears that, as personal computers with bitmap displays become more prevalent, and along with them, the regular use of windows, that smaller width display formats may become somewhat more common. Should this be the case, one would typically expect the clever window system to aid in the display of information not specifically formatted for that purpose - for instance by automatically wrapping lines as needed. The 40 char displays (such as the awful APPLE display I occasionally use at home) usually automatically wrap. Most other hand-held terminals I have seen, with narrow displays (e.g. 16X32 on a TV screen) also do this. Consequently, it would appear that, no matter how carefully one has formatted a message, it may have to be displayed on a device not quite suitable, but that receiver needs to cope somehow. Perhaps someday we will be able to carry along some instructions or assumptions about the output display capability so that the receiver can do more than just wraparound as needed. In the meantime, I think I agree that some "typical" assumptions like 72 char wide or something will usually result in fairly regulard displays. The deliberate avoidance of any CR's at all can only tend to irritate those receivers with limited capability in their mail reading programs. However, I am not sure I would insist that all mail be formatted in this fashion - depends a good deal on who is likely to receive it. Vint 27-Aug-82 16:56:32-PDT,1451;000000000001 Mail-from: ARPANET site BRL rcvd at 27-Aug-82 1652-PDT Date: 27 Aug 1982 16:11:19-PDT From: mo at Lbl-Unix (Mike O'Dell [system]) To: CERF at Usc-Isi cc: MsgGroup at BRL, Header-People at Mit-Mc, Human-Nets at Su-Score, POSTEL at Usc-Isif Subject: MSGGROUP#1836 Re: Effective Communication In-reply-to: Your message of 27 Aug 1982 1553-PDT (Friday). <[USC-ISI]27-Aug-82 15:22:40.CERF> Via: Lbl-Unix; 27 Aug 82 19:12-EDT To really do this "right" in the long run requires sending "structured documents" which record the original semantics intended. This could make the interchange format look something akin to Scribe input. While this is indeed most general and offers the greatest freedom in tailoring the presentation WITHOUT scarificing the intended semantics, it means you probably couldn't read mail (with the intended typography) on a Fuzzball. There has to be some compromise between the power you need on occassion and the functionality you use routinely. Note that such a compromise might be accomplished by simply "typing" the documents as to the "presentation layer functionality" needed to display it. Then if readers-composers offered options as to whether to format-on-output, people could be reasonably happy. As for limits on line length, any number you pick is wrong, or will be if you wait long enough. It is just that some numbers are wrong sooner than others. -Mike 2-Sep-82 17:00:31-PDT,1302;000000000001 Mail-from: ARPANET site BRL rcvd at 2-Sep-82 1659-PDT Mail-from: ARPANET site MIT-MC rcvd at 27-Aug-82 1814-PDT Date: 27 August 1982 16:40-PDT - Friday From: Jonathan Alan Solomon To: Header-People at Mit-Mc, Msggroup at BRL, Human-Nets at Rutgers Address: 3737 South Hoover Street Room PHE 204 Los Angeles, California 90089-0273 Phone: (213) 202-1793 Subject: MSGGROUP#1837 Effective Communication Remailed-date: 2 Sep 1982 1558-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup at BRL-BMD Via: Usc-Eclc; 2 Sep 82 18:59-EDT Via: Brl-Bmd; 2 Sep 82 19:03-EDT I'm a bit confused, I thought that the limit of 1000 characters was so that the mail transportation implementation could, if need be, impose a maximum limit. Presumably the """"best"""" implementation is one which negotiates the max limit, if any, in the contact. My receiver could TELL your sender that we only want 72 character lines. Your sender could either chop directly along those lines (hoping we patch all of it back together for the user), or do the form of autofilling some of us get in our mail senders. Anyway - where does restriction actually happen? At the sender? Receiver? The processing agents? Cheers, --JSol 27-Aug-82 18:20:22-PDT,2365;000000000001 Mail-from: ARPANET site BRL rcvd at 27-Aug-82 1818-PDT Date: 27 Aug 1982 1714-PDT Sender: STEF at Darcom-Ka Subject: MSGGROUP#1838 Re: Xerox Woes -- Long lines with out returns in them. From: STEF at Darcom-Ka To: MsgGroup at BRL Message-ID: <[DARCOM-KA]27-Aug-82 17:14:42.STEF> In-Reply-To: <27Aug82 165344 CE10@CMU-10A> Via: Darcom-Ka; 27 Aug 82 20:24-EDT I agree entirely with Jon Postel, but I would say it more strongly. The 80 column terminal is indeed the defacto standard, and 40 column displays are Johnny-come-lately cheapos whose owners knew full well what they were buying when they did it. No offense intended, but it was their choice when they did it. A very large and significant proportion of terminals out here in the ARPANET are not able to correctly break lines at the last white space before 80 columns at terminal display time. To do so requires code in the display software to support our "old technology" terminals. Very few of our current Message System User Agents have that capability, and to add this capability now would require retrofitting it into MSG, HERMES, MM, (in TWENEX Land), and retrofitting it into XMSG (ala MMDF) and MAIL, and derivitives in UNIX Land. I leave it to others to add to this list for other Operating System Lands. I am only a user of these systems, with no ability to get them changed, and I do not see any money coming from anywhere, like XEROX or ARPA, to retrofit HERMES. (Vint ... I am not here suggesting that you should!) MSG has been untouchable for many years. MM is similarly unfunded for such "updates." Therefore, telling me that all I need to do is fix my software is among the greatest of all possible insults. There is a very large potential for Xerox Longline mail (and similar mail from other sources) to greatly offend its recipients. From the tone of the Xerox decision, and some of the current MsgGroup mail, I am beginning to feel that the offensiveness is quite intentional. It is very difficult to avoid taking it personally. So, it is my experience that such mail does indeed offend me, greatly. Therefore, I respectfully request that the Xerox folks reconsider their position, and install the Chopper at the PARC gateway to do for STAR originated mail what the Chopper does now for Laurel originated mail. Best - Stef 27-Aug-82 21:10:55-PDT,1481;000000000001 Mail-from: ARPANET site BRL rcvd at 27-Aug-82 2108-PDT Date: 27 August 1982 21:54-EDT From: Gail Zacharias Subject: MSGGROUP#1839 Xerox Woes -- Long lines with out returns in them. To: Geoff at Sri-Csl, Admin.MDP at Su-Score cc: HEADER-PEOPLE at Mit-Mc, Human-Nets at Su-Score, MsgGroup at BRL Via: Mit-Mc; 27 Aug 82 23:25-EDT It seems to me that any half-decent mail reader has to have the capability to reformat a message at viewing time, if for no other reason than the fact that tastes vary, even if everbody used same-width terminal. Given that, totally unformatted messages are no worse than messages formatted in a way you dislike, and those will always exist. With regard to MDP's policy, putting a left margin in your message with the express purpose of foiling reformatting by the receiver strikes me as infinitely more anti-social than not formatting it at all. If I ask for reformatting it's because I want it. If I ask for it to happen automatically, it's because I want it to happen automatically, your appreciation of your own formatting notwithstanding. Anyhow, one way to deal with this problem would be a header field, e.g. Format: Rigid (tables, code -- do not touch, display in fixed font) or Format: Free-form (Xerox style, needs formatting) or Format: Typical (usual case, doesn't need reformatting, but ok to do so) or Format: Scribe (contains scribe formatting directives (to be discouraged....)) etc .... 27-Aug-82 23:55:46-PDT,1322;000000000001 Mail-from: ARPANET site BRL rcvd at 27-Aug-82 2353-PDT Date: 28 Aug 1982 0151-EDT From: Robert W Kerns Subject: MSGGROUP#1840 1000 character limit To: JSol at Usc-Eclc, Header-People at Mit-Mc, Msggroup at BRL, Human-Nets at Rutgers cc: RWK.SCRC-TENEX at Mit-Mc In-Reply-To: Your message of 27-Aug-82 1943-EDT Via: Mit-Mc; 28 Aug 82 2:13-EDT Actually, the 1000 character limit can be necessary for VMS. Records (lines) are written in a single I/O call, and are limited in size to the program's quota for system buffer space. It's possible to get around this, especially in VMS 3.0, but not with a "normal" text file. I expect the 1000 character limit is imposed for situations like this, rather than having anything to do with presentation format. Anyway, I think this discussion is silly, particularly so since it is taking place on three mailing lists, with largely overlapping readership. If someone were to propose an experimental protocol with imbedded formating, that might be interesting. The rest of the world can communicate with the tools they have now, and think about the future. But flames about how what we're doing now is not the wave of the future are simply too obvious to be worth sending to 3 large-distribution mailing lists. ------- 2-Sep-82 18:17:38-PDT,1945;000000000001 Mail-from: ARPANET site BRL rcvd at 2-Sep-82 1816-PDT Mail-from: ARPANET site MIT-MC rcvd at 28-Aug-82 0713-PDT Date: 28 Aug 1982 0701-PDT From: Mike Peeler Subject: MSGGROUP#1841 Re: Xerox Woes -- Long lines with out returns in them. To: GZ at Mit-Mc cc: Geoff at Sri-Csl, HEADER-PEOPLE at Mit-Mc, Human-Nets at Su-Score, MsgGroup at BRL In-Reply-To: Your message of 27-Aug-82 1854-PDT Remailed-date: 2 Sep 1982 1713-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup at BRL-BMD Via: Usc-Eclc; 2 Sep 82 20:16-EDT Via: Brl-Bmd; 2 Sep 82 20:22-EDT Gail, I agree with you about the capabilities the mail-readers of the future ought to have. As Stef (Thank you, Stef) points out, we have to separate the normative concepts from the current operating problems. In principle, we agree, you and I. In practice, I chose to use a left margin to deal with a specific problem. Mail-readers which fill text only for the purpose of limiting its right margin are doing the wrong thing to mine, since I intentionally use a short right margin. If my format bothers your eyes, I happen to know it would only take you a few keystrokes to remove the margin and reformat this message. Not formatting the text at all is, given the current state of the world, far more anti-social. Most people do not have the kind of mail-reader that will fool around with the body of a message. This majority will have to live with the message in its original presentation. For that matter, what is wrong with my wanting my work presented in a particular way? Would anyone consider an artist anti-social if he took measures to make sure a museum displayed his painting in his particular notion of the proper lighting? Regards, Mike ------- 28-Aug-82 13:45:33-PDT,1202;000000000001 Mail-from: ARPANET site BRL rcvd at 28-Aug-82 1342-PDT Date: 28 August 1982 11:50 edt From: Barry.Margolin at Mit-Multics Subject: MSGGROUP#1842 Re: Xerox Woes -- Long lines with out returns in them. Sender: Margolin.Multics at Mit-Multics To: Mike Peeler cc: GZ at Mit-Mc, Geoff at Sri-Csl, HEADER-PEOPLE at Mit-Mc, Human-Nets at Su-Score, MsgGroup at BRL In-Reply-To: Message of 28 August 1982 10:01 edt from Mike Peeler Via: Mit-Multics; 28 Aug 82 15:52-EDT I doubt that most mail reading programs format the text automatically, although many will do so on demand. This makes Xerox's message just more anti-social, because I will most likely have to read it twice - once to find out that it is not formatted, then with it reformatted. I will then have to hope that my reformatting did what was intended, not screwing up any tables or diagrams. I liked someones idea about the "Format:" header field, but for now we should restrict ourselves to a few simple values like "Formatted", "Unfilled", etc., and leave things like "Scribe" or "RFC-1024" (the DoD standard text formatter, to be designed in five years) for the future. barmar 3-Sep-82 01:27:06-PDT,747;000000000001 Mail-from: ARPANET site BRL rcvd at 3-Sep-82 0126-PDT Mail-from: ARPANET site MIT-MC rcvd at 28-Aug-82 1418-PDT Date: 28 Aug 1982 1411-PDT From: Brian Harvey Subject: MSGGROUP#1843 who should break long lines To: header-people at Mit-Mc Remailed-date: 3 Sep 1982 0036-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup at BRL-BMD Via: Usc-Eclc; 3 Sep 82 3:37-EDT Via: Brl-Bmd; 3 Sep 82 3:41-EDT Let me tell you, when you spend a couple of weeks reading your mail at 1200 baud, you develop a new conception of what issues are really important and which aren't. I recommend it to all mailing list participants. P.S. -- Postel is right, of course, as usual. 28-Aug-82 21:23:16-PDT,1611;000000000001 Mail-from: ARPANET site BRL rcvd at 28-Aug-82 2119-PDT Date: 28 Aug 1982 1447-PDT From: MsgGroup Moderator - Stefferud Subject: MSGGROUP#1844 MsgGroup@BRL is failing from XMAILR Sites! To: MsgGroup at Mit-Ml Reply-To: MsgGroup-request at Mit-Ml Via: Mit-Ml; 28 Aug 82 23:32-EDT Hi All - We are having trouble again with the XMAILR/MMDF timeout. All mail to MSGGROUP@BRL from XMAILR sites is failing because BRL MMDF is taking the time to validate the whole MsgGroup list before signalling acceptance to XMAILR for the item. XMAILR is timing out! There are two ways to avoid this problem with mail from XMAILR sites. 1. Address it to MsgGroup@MIT-ML which will correctly relay it to BRL without entrapment by the timeout problem. 2. Address it to MsgGroup@BRL-BMD which will also corrctly relay it to BRL without entrapment by the timeout problem. I suggest that we all avoid using the MsgGroup@BRL address until this is fixed in order to avoid trouble for the unwary who might REPLY without paying close attention. In the meantime, I hope that I can figure out some way with the BRL Postmaster to arrange for MsgGroup@BRL to become isolated from this timeout problem, which afflicts any list relay operations there. I will next REMAIL any items that I have, which have failed to get through to MsgGroup. If, after I do this, you still have an item that has not be delivered, please find a way to get it delivered, or send it to MsgGroup@ECLC and I will remail it (with a bit of a delay). Sorry bout all this. Stef ------- 29-Aug-82 19:53:18-PDT,1313;000000000001 Mail-from: ARPANET site BRL rcvd at 29-Aug-82 1952-PDT Sender: Farrell at Parc-Maxc Date: 29-Aug-82 14:22:27 PDT (Sunday) From: Farrell.pa at Parc-Maxc Subject: MSGGROUP#1845 Re: Xerox Woes -- Long lines with out returns in them. In-reply-to: STEF's message of 27 Aug 1982 1714-PDT, <[DARCOM-KA]27-Aug-82 17:14:42.STEF> To: STEF at Darcom-Ka cc: MsgGroup at Mit-Ml Via: Mit-Ml; 29 Aug 82 21:36-EDT Aside from the particulars of the controversy (which others seem to be covering in gory detail), I would like to correct one point: Star hasn't, doesn't, and for a while into the future won't, send messages to the Arpanet. What you see coming out of the Xerox internet (via PARC-MAXC) comes from the Grapevine message transport system, as serviced by message systems Laurel & Hardy, which are Xerox development tools, not products. When Star is ready to send to the Arpanet, there will be harder problems than long lines -- who is ready to accept a piece of mail which is a folder containing a record file, a simple document, and a document with a couple of barcharts? Back to the issues under discussion, one other point: All the word-processing systems I know encourage typists to let the machine do the line-breaking, unless they want an explicit newline. Relevant? Jerry 30-Aug-82 15:07:32-PDT,5514;000000000001 Mail-from: ARPANET site BRL rcvd at 30-Aug-82 1506-PDT Date: 29 Aug 1982 15:15 PDT From: Taft at Parc-Maxc Subject: MSGGROUP#1846 Line folding To: MsgGroup at Mit-Ml, HeaderPeople at Mit-Mc cc: Taft at PARC-MAXC Via: Mit-Ml; 30 Aug 82 16:21-EDT It is a curious coincidence that this discussion erupted just one day after many of the responsible people within Xerox had a meeting to decide what we should do about RFC 822. Perhaps I can put this discussion to rest with a little bit of authoritative information about our position and our plans. 1. Commentary on the discussion so far The "Xerox position" has been reasonably well articulated in several messages, particularly the ones from Hartwell, Everhart, and Peeler; so I do not intend to repeat most of those arguments here. And there are certainly reasonable technical and pragmatic grounds for disagreement with the "Xerox position". On the other hand, insulting and inflammatory remarks about motives and attitudes serve no constructive purpose; they are inappropriate in a large public forum such as this one; and they do not deserve the dignity of a reply. 2. Elaboration on the "Xerox position" Our practice of making the recipient's mail software responsible for formatting messages for the recipient's terminal is a very pragmatic one. There is no "standard" line width anywhere in the Xerox Internet; variable-width fonts and variable-size display windows make this a meaningless concept. Though 80 x 24 display terminals may be more-or- less "standard" in the ARPA Internet right now, I am certain this will not be true for very much longer. The proposal, "Let the sender break lines as a courtesy to unsophisticated recipients, and smart recipients reformat to suit their own needs" breaks down because there is no reliable way for the recipient, no matter how smart, to distinguish CRs put in for line folding from CRs that truly represent breaks in the text. Making this distinction is possible only if there is either (a) a syntactic distinction between the two uses (i.e., two kinds of CRs), or (b) higher-level formatting information (a la Scribe, Tex, Pub, etc.) indicating which text may be reformatted and which is to be taken literally. Neither approach seems likely to be adopted by the ARPA Internet community any time soon. The proposal, "Let the sender and recipient negotiate over line length" doesn't work since (a) the sender may be sending to a distribution list and not know the identity of the ultimate recipients; (b) the recipient may wish to display the same message in different-size windows; and (c) in general, the sender and recipient don't communicate directly, but only via one or more store-and-forward intermediate agents. Breaking unfolded paragraphs into lines appropriate for the recipient's terminal is such a trivial procedure for the recipient's mail software to do that it seems inconceivable that even the tiniest microcomputer should be incapable of doing so. And indeed, most of the messages so far suggest that the problem lies not with low-powered computers but with crufty old big-computer software, such as MSG, which nobody is maintaining any more. In an evolving network environment, I consider it an untenable position that a standard (whether official or de-facto) should have to cater to software that is no longer being maintained. If nobody is prepared to devote resources to maintenance, the software should be allowed to die. 3. History and plans Until now, we have permitted unfolded text to escape into the Arpanet simply because the mail forwarding software on PARC-MAXC (as well as all our other transport software) does not make ANY modifications to message content. This reflects our belief in the principle of rigid separation between envelope and content information. During the discussions that led to RFC 822, I (and several other people) argued strongly for having this principle written into the standard, along with a statement that line folding be the responsibility of the recipient. However, because of the short time available for issuing and implementing RFC 822, we lost on this issue. (As an aside, though, I should mention that RFC 822 still does NOT prescribe that the sender do line folding, except for one non-binding recommendation that HEADERS be folded to "65 or 72 characters".) Therefore, it is our intention to conform to RFC 822 and to de-facto usage by implementing a mail translation gateway that WILL translate names and WILL do line folding when forwarding mail between the Xerox and ARPA Internets. Though this violates the principles by which we believe message systems should work, we recognize that our adherance to these principles causes inconvenience to some ARPA Internet users. To those unsuspecting users whose mail software chokes on long lines from Xerox senders, we apologize. To implementors of such software, we can only suggest that well-engineered mail-handling software should tolerate arbitrary message content, even if it can't handle all of it in an ideal fashion. If there are any chinks in the armor, the software will eventually break, and unsuspecting users will be inconvenienced. (Yes, there are messages that break Laurel!) It is likely that the mail translation gateway software will be done well before the January 1 scheduled cutover to RFC 822. Ed Taft Xerox PARC 30-Aug-82 15:32:37-PDT,4156;000000000001 Mail-from: ARPANET site BRL rcvd at 30-Aug-82 1528-PDT Date: 30 Aug 1982 11:28:21-CDT From: Marvin Solomon Reply-to: solomon at Uwisc To: MsgGroup at Mit-Ml Subject: MSGGROUP#1847 Line folding Via: Mit-Ml; 30 Aug 82 17:00-EDT As a fairly disinterested observer (at least, one who is amazed by the heat of the discussion so far), I would like to make a few observations. Part of the disagreement seems to arise from differing models of what constitutes "plain textual material". In particular, what is the role of CRLF? One possibility is that it is a pair of what ANSI calls "format effectors". Quoting the USASCII standard (X3.4-68), a format effector is "A functional character which controls the layout or positioning of information in printing or display devices". On the other hand, some systems use the pair as if it were an indication of end-of-record. In particular, the "record" model is the only explanation I can think of for imposing a limit of 1000 characters per "line". In the context of FTP or Telnet, such a record-oriented approach may make some sense. But in the context of SMTP, which is supposed to sit on top of an unstructured byte-stream service (such as TCP), I hope we can dispense with that notion. (Am I wrong? Is there really an SMTP server that will break if it gets 10000 characters in a row without CRLF?) Even if we restrict ourselves to the "format effector" model, there is some room for discussion. Both the sender and the receiver have valid reasons for wanting to determine format: The (human) sender may want to fine-tune the format based on semantic information that would be difficult to determine from the text itself (for example, columns of figures or centered titles). The receiver, however knows the characteristics of the destination device (font widths, line lengths, etc.) The ideal solution is some sort of standard formatting language, but I don't think anyone expects one to arise in the near future. A modest alternative is a convention on "mandatory" vs "optional" line breaks. One de facto standard understood by many formatters is that a CRLF followed immediately by another CRLF or by white space is mandatory. Allow me to suggest another alternative. I've long been annoyed by the convention of using TWO characters for end-of-line. I'm sure this subject was debated long and heatedly before I joined the Internet community, but even the 1968 ANSI standard recognizes the possibility of doing things differently. "Where appropriate, this character [LF] may have the meaning 'New Line' (NL), a format effector which controls the movement of the printing point to the first printing position on the next printing line. Use of this convention requires agreement between sender and recipient of data." The Telnet and SMTP standards recognize the special nature of CRLF by requiring that CR which is really to mean "carriage-return" be followed by NULL. I don't know of any special significance attached to a bare LF. Let me propose one: CRLF and bare-LF mean mandatory and optional end-of-line. I'm not sure which should be which. I guess the decision depends on whether you think the "default" should be sender-specified or receiver-specified formatting. If sender-specified is the default (my own personal preference, as one who works in an environment in which ALL terminals are 80x24), then I guess CRLF should be the optional eol. Then a dumb (non-Xerox) sender would insert CRLF wherever the sending person hit carriage-return and a dumb receiver would display the information just that way, while a smart receiver might reformat the text at will. A smart sender would use bare-LF to force formatting conventions if it suspected that a smart receiver might play with the format. A smart sender should also probably insert CRLF every so often as a courtesy, if the message was being sent into an environment where it might encounter a dumb receiver. Marvin Solomon Computer Sciences Department University of Wisconsin, Madison WI solomon@uwisc ...!harpo!uwvax!solomon 30-Aug-82 15:42:50-PDT,2162;000000000001 Mail-from: ARPANET site BRL rcvd at 30-Aug-82 1539-PDT Date: 30 August 1982 1723-EDT (Monday) From: Richard H Gumpertz To: Taft at Parc-Maxc Subject: MSGGROUP#1848 Re: Line folding CC: MsgGroup at Mit-Ml, HeaderPeople at Mit-Mc In-Reply-To: Taft@Parc-Maxc's message of 29 Aug 82 17:15-EST Message-Id: <30Aug82 172303 RG02@CMU-10A> Via: Mit-Ml; 30 Aug 82 17:23-EDT Via: Brl; 30 Aug 82 17:33-EDT Via: Brl-Bmd; 30 Aug 82 17:38-EDT Perhaps a compromise is in order. For example, the mail sender could MARK those line breaks that are for convenience only. The simplest schem I have seen for this is to precede the line break with the spaces that would have been there anyway. That is, rather than changing FOOBAR to FOOBAR, it would be changed to FOOBAR. If there were two spaces, as after a sentence, one might get something like FOO.BAR. Explicit line breaks would have no spaces preceding. Note that the trailing spaces are, for the most part, invisible to most readers. At worst, they would force the line-formatter to use a slightly shorter line-length so that they would still fit on the line. Smart line-displayers could suppress the printing of trailing spaces and so use the full terminal line-width. On the other hand, the trailing spaces now make it easy to reformat: If the CRLF is preceded by a SP, it is not a true line break and can be punted. If it is not preceded by a space, it must be preserved . Mail sending programs could format to some "reasonable" length like 72 fixed-width characters. Mail receivers for fancy terminals (variable width, long lines, etc.) and for trivial terminals (40 characters) could reformat as needed. The majority of normal terminals would just display the 72-character lines as received. The only issue left would be how a user would interact with his mail-sending program to meet this convention. While he might follow it himself, there might be a better interface. Note, however, that the issue is now a local one rather than a inter-machine one and so is much easier to solve. Rick 30-Aug-82 15:47:33-PDT,1645;000000000001 Mail-from: ARPANET site BRL rcvd at 30-Aug-82 1544-PDT Date: 30 August 1982 14:44-PDT - Monday From: Jonathan Alan Solomon To: Mike Peeler Cc: Geoff at Sri-Csl, GZ at Mit-Mc, HEADER-PEOPLE at Mit-Mc, Human-Nets at Su-Score, MsgGroup at BRL Address: 3737 South Hoover Street Room PHE 204 Los Angeles, California 90089-0273 Phone: (213) 202-1793 Subject: MSGGROUP#1849 Xerox Woes -- Long lines with out returns in them. Via: Usc-Eclc; 30 Aug 82 17:47-EDT Via: Brl; 30 Aug 82 17:57-EDT Via: Brl-Bmd; 30 Aug 82 18:02-EDT For that matter, what is wrong with my wanting my work presented in a particular way? Would anyone consider an artist anti-social if he took measures to make sure a museum displayed his painting in his particular notion of the proper lighting? We've strayed off the discussion (as I see it), which was that Xerox wanted to send streams of data as mail without carriage returns. However, to answer your question, Yes. I think that I have a right to look at your work of art in the light (or point of view) that I think is best. That's my opinion. Electronic mail is defined (in the ARPA sense) to be several lines of text separated by newlines (,). Xerox is ignoring this definition of Internet electronic mail if they insist on sending messages without carriage returns. In fact, it would imply that at least one carriage return is required to consider the text "mail", in the current sense. (Note: I am not talking about multi media mail). --JSol 30-Aug-82 18:26:51-PDT,1758;000000000001 Mail-from: ARPANET site BRL rcvd at 30-Aug-82 1825-PDT Date: 30 Aug 1982 1725-PDT From: MsgGroup Moderator - Stefferud Subject: MSGGROUP#1850 [dpk@BRL: Re: HELP! MsgGroup@BRL Mail is failing!] To: MsgGroup at BRL Via: Usc-Eclc; 30 Aug 82 20:28-EDT Via: Brl; 30 Aug 82 20:39-EDT Via: Brl-Bmd; 30 Aug 82 20:43-EDT Hi All - The enclosed message resolves our BRL timeout problems, and the channels are clearing their queues. The SU-Score queues to MsgGRoup@BRL have been accidently cleared by means of rejection and return to their SENDERs. I will now REMAIL those items which got to me via Header-People, or which have been supplied to me by other alternate routes. If you have an item which still has not gotten out to the group, and you still want it to go out, please just forward a copy to MsgGroup-Request@BRL and I will remail it after processing it into the archives. Thanks to you all for tolerating all this trouble! Best Regards - Stef ===== Date: 30 Aug 82 17:19:04-EDT (Mon) From: Doug Kingston To: STEF at Darcom-Ka cc: JSol at Usc-Eclc, MsgGroup at Usc-Eclc, DPK at Brl, Hartwell at Su-Score Subject: Re: HELP! MsgGroup@BRL Mail is failing! I have eliminated the possibility for any further XMAILER/MMDF problems with the MSGGROUP mailing list. All mail sent to msggroup at BRL or BRL-BMD will be accepted immediately (with a single address verification), and the list will be verified between our two machines. This should have been set up this way before, but must have slipped through. Sorry for any problems. This is the same system we use with the other mailing lists that go through BRL. -Doug- ------- 31-Aug-82 21:56:26-PDT,7003;000000000001 Mail-from: ARPANET site BRL rcvd at 31-Aug-82 2154-PDT Date: 30 Aug 1982 1927-PDT Sender: MSGGROUP at Usc-Eclc Subject: MSGGROUP#1851 SURVEY #1800-#1850 from MSGGROUP.1801-1900.1 From: MsgGroup Moderator - Einar Stefferud Reply-To: MsgGroup-Request at BRL To: MSGGROUP at BRL Message-ID: <[USC-ECLC]30-Aug-82 19:27:44.MSGGROUP> Via: Usc-Eclc; 30 Aug 82 22:27-EDT Via: Brl; 30 Aug 82 22:38-EDT Via: Brl-Bmd; 31 Aug 82 22:57-EDT MSGGROUP#1801 SURVEY #1751-#1800 from MSGGROUP.1700-1750.1 7263 chars 18 Aug 1982 1313-PDT From: MsgGroup Moderator - Einar Steffe MSGGROUP#1802 Multiple XMAILRs (Re: #1794 ... #1799) 3559 chars 18 Aug 1982 1432-PDT From: Mark Crispin To: CERF at Usc-Isi MMSGROUP#1803 Re: Multiple XMAILRs (Re: #1802) 710 chars 18 Aug 1982 1654-PDT From: CERF at Usc-Isi To: Admin.MRC at MSGGROUP#1804 Re: #1800 Re: #1794 ... #1799 1445 chars 18 Aug 82 21:22:04-EDT (Wed) From: Doug Kingston T MSGGROUP#1805 Re: [Einar Stefferud: Re: #1794 ... 638 chars 18 Aug 1982 1456-PDT From: Mark Crispin To: MsgGroup.BRL at MSGGROUP#1806 FTP vs special mail protocol 525 chars 19 August 1982 05:15 edt From: Schauble.Multics at Mit-Mul MSGGROUP#1807 Re: FTP vs special mail protocol 1364 chars 20 Aug 1982 0934-PDT From: CERF at Usc-Isi To: Schauble.Mult MSGGROUP#1808 Re: FTP vs special mail protocol 3640 chars 20 Aug 1982 1118-EDT From: DDEUTSCH at Bbna To: SCHAUBLE.MUL MSGGROUP#1809 FTP vs Mail 1338 chars 20 Aug 1982 1507-PDT From: POSTEL at Usc-Isif To: msggroup MSGGROUP#1810 Re: FTP vs special mail protocol 693 chars 21 Aug 1982 1154-PDT From: CERF at Usc-Isi To: DDEUTSCH at B MSGGROUP#1811 Verification & delays 3624 chars 21 Aug 82 16:25:24-EDT (Sat) From: Dave Crocker T MSGGROUP#1829 Re: Xerox Woes -- Long lines with out returns in them. 1250 chars 27 Aug 1982 12:43 PDT From: AHenderson at Parc-Maxc To: Mike MSGGROUP#1830 Effective Communication 1496 chars 27 Aug 1982 1340-PDT From: POSTEL at Usc-Isif To: MsgGroup MSGGROUP#1831 Re: Xerox Woes -- Variable width fonts 5135 chars 27 Aug 1982 14:22-PDT - Friday From: Brian Reid To MSGGROUP#1840 1000 character limit 1322 chars 28 Aug 1982 0151-EDT From: Robert W Kerns To: MSGGROUP#1844 MsgGroup@BRL is failing from XMAILR Sites! 1611 chars 28 Aug 1982 1447-PDT From: MsgGroup Moderator - Stefferud Remailed-to: msggroup at BRL-BMD Via: Usc-Eclc; 3 Sep 82 4:12-EDT Via: Brl-Bmd; 3 Sep 82 4:20-EDT Brian - The fact that the problem exists did not get people upset. In fact, it is quite reasonable for the developer of a program (which was intended to be run internally only) would not expect to think of all the external needs. What got people upset was the apparently flippant attitude, as expressed in the alleged Xerox communication, when the maintainer was confronted with the problem. Even if the maintainer felt that Laurel-style automatic breaks were wrong, s/he could have answered something to the effect of: "Thank you for your problem report. While we are not convinced that your suggested solution is the appropriate one, we are concerned that this is causing problems for some Internet users. We are investigating alternative solutions to the problem, and hope to have a workable solution in the not-too-distant future. We would like to inquire as to how much of a problem it is for mail receivers to insert line breaks at their end. This is what we use internally, and this is preferable in our environment." The point is, a software maintainer should always give the impression that s/he CARES about problems users encounter with the software. Brian, I remember you making several strong statements to me about the necessity of having effective electronic mail communication irregardless of who is "right". And you're quite right on this. Because of all the misunderstandings which can arise from different interpretations of jargon terms (you and I have first-hand experience with the interpretation of the term "routed address"), it is important that problems be expressed in plain English whenever possible and that people go to great lengths to (1) avoid stating anything that would give offense and (2) avoid interpreting statements as offensive when none was intended. ------- 3-Sep-82 02:21:45-PDT,1443;000000000001 Mail-from: ARPANET site BRL rcvd at 3-Sep-82 0221-PDT Mail-from: ARPANET site MIT-MC rcvd at 29-Aug-82 1657-PDT Date: 29 August 1982 1919-EDT (Sunday) From: David.Lamb at Cmu-10a To: header-people at Mit-Mc, msggroup at BRL Subject: MSGGROUP#1853 Re: Xerox Woes -- Long lines with out returns in them. Sender: David.Lamb at Cmu-10a Reply-To: Rdmail at Cmu-10a In-Reply-To: Earl A. Killian@MIT-MC's message of 27 Aug 82 01:14-EST Message-Id: <29Aug82 191931 RD00@CMU-10A> Remailed-date: 3 Sep 1982 0112-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup at BRL-BMD Via: Usc-Eclc; 3 Sep 82 4:13-EDT Via: Brl-Bmd; 3 Sep 82 4:22-EDT Shortly after this controversy about breaking long lines started, I added code to RdMail to break long lines. Whether this is done is under the control of the user, but is the default unless the user changes the templates that control printing on the terminal. This only affects output to the terminal (unless the user changes the template that controls mail forwarding). It took a total of about 7 hours, most of which was tracking down a really obscure bug that has nothing to do with breaking lines, but that I happened to tickle with this change. Thus there is at least one non-Xerox system that now breaks lines as Xerox suggested. I've had no user feedback yet, since only about 30 people use the experimental version. 3-Sep-82 02:27:47-PDT,1587;000000000001 Mail-from: ARPANET site BRL rcvd at 3-Sep-82 0225-PDT Mail-from: ARPANET site MIT-MC rcvd at 29-Aug-82 1859-PDT Date: 29 Aug 1982 18:40-PDT - Sunday To: Taft at Parc-Maxc cc: MsgGroup at Mit-Ml, Header-people at Mit-Mc Subject: MSGGROUP#1854 Re: Line folding In-reply-to: Your message of 29 Aug 1982 15:20 PDT. From: gaines at Rand-Unix Remailed-date: 3 Sep 1982 0113-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup at BRL-BMD Via: Usc-Eclc; 3 Sep 82 4:13-EDT Via: Brl-Bmd; 3 Sep 82 4:24-EDT I don't think the numbers support your view that the 24x80 display will become less prevelent soon. Enormous numbers of these are being sold, and the majority of the large volume (or expected large volume) workstations also have adopted this format. We all look forward to the day when a first-class bit map display costs no more than the equivalent, at that time, of today's $700 Televideo, but that won't be soon. On the matter of stuffing CRs: For most messages the formatting within paragraphs doesn't matter. For these, an appropriate header entry might be included. Then the recipient (program or person) would know that the CRs within paragraphs were inserted for the convience of display on common 80 character terminals with unsophisticated software support, but that they weren't meaningful. Without such an entry, all formatting could be considered meaningful, and it would be up to the recipient to figure out how to deal with the message if the sender's formatting caused him problems. 31-Aug-82 21:28:12-PDT,3610;000000000001 Mail-from: ARPANET site BRL rcvd at 31-Aug-82 2125-PDT Sender: Karlton at Parc-Maxc Date: 30-Aug-82 20:06:42 PDT (Monday) From: Phil Karlton Subject: MSGGROUP#1855 Re: Effective Communication In-reply-to: POSTEL's message of 27 Aug 1982 1340-PDT To: MsgGroup at BRL, Header-People at Mit-Mc Reply-To: Karlton.pa at Parc-Maxc Via: Parc-Maxc; 30 Aug 82 23:05-EDT Via: Brl; 30 Aug 82 23:18-EDT Via: Brl-Bmd; 31 Aug 82 22:58-EDT As the individual responsible for rejecting the request for automatic insertion of NewLines into outgoing messages, I believe that I should explain in slightly more detail why. The mail composer for which I have responsibility is a very simple program. It represents about three days work on my part. (I owe most of the ease of producing the tool to the fact that a large number of software packages (communication with the mail servers, mail parsing, display, editing) are available.) It makes no edits of the messages other than to prepend a Date: field and a From: field if necessary. As Jon Postel said, "When the sender or speaker cares about effectively communicating he or she adapts to the capabilities of the receiver or listener." Since the overwhelming majority of the messages that get sent using this tool never get near the Arpanet, I felt (and still do) that it was up to the sender to make sure that the recipient would be able to understand the message. It is not a difficult task (in our environment) to break lines just before a message is sent. In fact, that is what I intend to do to this message. Some felt that this last second editing was too onerous, so a package (Chop) was written (not by me) to do long line breaking and was made available to the general community as an "official hack". Users can load Chop into their environment, and, then, with a SINGLE button push, get their messages into the form that they want. What the original change request was complaining about was that even this was too much for a user to have to do. I disagree. I was also aware that the Xerox mail gateway was going to be changed "someday" so that it would do line folding. I had no desire to write software that would soon be obsolete and add no function (in the eyes of most of the users, including those signing my paychecks) to the tool I was charged with releasing and then maintaining. If I had been more discreet and friendly when rejecting the original change request, this flap would not have occurred. I thought the individual to whom I sent the reply, had known most of the above. I suppose I will have to start taking diplomacy lessons. There is one point of misinformation that I saw that I should correct. I was not ignorant of RFC733 when I wrote the tool in question; I wrote what was probably the very first 733 conforming mail editor: RdMail at CMU. (I still feel slightly guilty about the other fire I started by having RdMail allow names with spaces in them in mail headers.) I was just trying to get a simple tool going that would allow our community of users to get its job done. I was pleased that they (and I) would be able to communicate with Arpanet recipients, I just had no idea that it would be so awful to merely follow the standard. I have no desire to fan any more flames. If you feel the need to enlighten my attitude, please send me a personal message rather than trying to convince me in a public forum that I am a fool. I should also add that I am speaking for myself and not as an official representative of Xerox. PK 31-Aug-82 21:28:13-PDT,2130;000000000001 Mail-from: ARPANET site BRL rcvd at 31-Aug-82 2126-PDT Date: 30 Aug 1982 2119-PDT Sender: GEOFF at Sri-Csl Subject: MSGGROUP#1856 Re: Effective Communication From: the.tty.of.Geoffrey.S.Goodfellow at Sri-Csl Reply-To: Geoff at Sri-Csl To: Karlton.pa at Parc-Maxc Cc: MsgGroup at BRL, Header-People at Mit-Mc Message-ID: <[SRI-CSL]30-Aug-82 21:19:22.GEOFF> In-Reply-To: Your message of 30-Aug-82 20:06:42 PDT (Monday) Via: Sri-Csl; 31 Aug 82 0:29-EDT Via: Brl; 31 Aug 82 0:40-EDT Via: Brl-Bmd; 31 Aug 82 23:03-EDT Although I think your view (and Postel's) on "Effective Communication" is amiable in principle, it is not so in actual practice. Two actual examples come to mind: Because at the time a message is composed, it may be addressed to or include a Xerox Internet Distribution List (such as Movie.PA^, for example), which may have on it one or more ARPANET recipients. The user, composing the message, doesn't have any idea or notion about the ARPANET folk on the list, and that Chop should be invoked -- the result being, a non-chopped message leaks out to the ARPANET recipients. And secondly, for the same reason that people, by the virtue of human nature, accidentally reply to all recipients of a message when they only meant to have their reply go only to the sender. Or even worse, as some of us have admitted in times past, replied to all recipients of a message they were a BCC recipient on! My point is simple: Line-folding (aka Chopping) should be automatic (for that recipients that expect folded (Chopped) lines). It is all together too easy for users to forget or overlook or not even KNOW, that they should invoke the "chop hack" because a message includes (or might include) some ARPANET recipients. I think the solution Ed Taft intends to implement in the PARC-MAXC gateway is an excellent one: The Xerox Internet folk get their non-folded lines, which your terminals will handle for you in the way you are USED TO, and we ARPANET folk will get our folded (chopped) lines, which we are USED TO. The best of both worlds, for each worlds users. 31-Aug-82 21:43:10-PDT,1827;000000000001 Mail-from: ARPANET site BRL rcvd at 31-Aug-82 2142-PDT Date: 31 Aug 1982 0210-PDT From: Mike Peeler Subject: MSGGROUP#1857 Re: Xerox Woes -- Long lines with out returns in them. To: JSol at Usc-Eclc cc: Geoff at Sri-Csl, GZ at Mit-Mc, HEADER-PEOPLE at Mit-Mc, Human-Nets at Su-Score, MsgGroup at BRL In-Reply-To: Your message of 30-Aug-82 1451-PDT Via: Su-Score; 31 Aug 82 5:16-EDT Via: Brl; 31 Aug 82 5:28-EDT Via: Brl-Bmd; 31 Aug 82 23:08-EDT JSol, You ignored or misunderstood the issue when you said Electronic mail is defined...to be several lines of text separated by newlines... Xerox is ignoring this definition of Internet electronic mail if they insist on sending messages without carriage returns. They are not sending messages without newlines. Only do they omit SPURIOUS newlines. This means they send CRLF if and only if the sender claims the line MUST break there. The receiver, which could conceivably know something about the device being used for output, can then act accordingly, one possibility being to treat whitespace as optional line breaks and explicit newlines as mandatory. Or it can do whatever else it wants to do. Their policy may be inconvenient for those whose mail-readers cannot handle it, but let's get one thing straight: it does ADD INFORMATION by eliminating "noise". I realize that subsequent messages from Marvin Solomon and Rick.Gumpertz@Cmu-10a to MsgGroup have covered this topic in greater depth, but I want to make it clear that, while Xerox may indeed be guilty of obstinacy, it is not by any means for no reason. Regards, Mike ------- 1-Sep-82 08:25:16-PDT,2566;000000000001 Mail-from: ARPANET site BRL rcvd at 1-Sep-82 0823-PDT Date: 31 August 1982 11:49-PDT - Tuesday From: Jonathan Alan Solomon To: Mike Peeler Cc: Geoff at Sri-Csl, GZ at Mit-Mc, HEADER-PEOPLE at Mit-Mc, Human-Nets at Su-Score, MsgGroup at BRL Address: 3737 South Hoover Street Room PHE 204 Los Angeles, California 90089-0273 Phone: (213) 202-1793 Subject: MSGGROUP#1858 Xerox Woes -- Long lines with out returns in them. Via: Usc-Eclc; 31 Aug 82 14:50-EDT Via: Brl; 31 Aug 82 14:57-EDT Via: Brl-Bmd; 1 Sep 82 9:35-EDT After readig Jon Postel's comments, I am inclined to retract my statement that Xerox would be violating protocol by sending mail which has infinite line length. I don't see within the SMTP spec any indication that the line length of 1000 characters was meant to be enforced unless implementations could not be "infinite". It was my misunderstanding that it was to be a hard limit. Also, in RFC822 (the son of RFC733), line folding to conform to the 65 to 72 lines "should" be done in the header, but is also not enforced by the standard. Nothing is said about the message text. However, I do find it annoying that I have seen quite a bit of Xerox mail which does NOT have *any* newlines in it (maybe I did not make myself clear enough before). I am complaining that Xerox software gives the impression to the end user that newlines exist, when in the text of the message; the newlines disappear. I have received messages from Xerox-land which have been without any newlnes, while the user who composed them assured me that they saw separate lines when they sent the text. Somehow this seems unreasonable. Some questions for Xerox: Does the machine allow users to insert newlines? If not sending them is the default case, then is the fact that newlines will be removed by the program well documented, as well as a method for turning off this behavior? Is it company wide policy (or some such nonsense) that the software should be UNABLE to add in newlines even if the sender wants them there (This would seem to violate Mike Peeler's statement of composer rights to formatting)? As a mailing list moderator, I get alot of feedback from Xerox employees who may not be sophistocated enough to understand how to specfically add newlines, people keep telling me that they thought the newlines were there. *THIS* is what I am complaning about, note the spec doesn't seem to specifically prohibit Xerox from doing it. Cheers, --JSol 1-Sep-82 09:18:19-PDT,7073;000000000001 Mail-from: ARPANET site BRL rcvd at 1-Sep-82 0913-PDT Date: 31-Aug-82 15:35:03 PDT (Tuesday) From: holbrook.ES at Parc-Maxc Subject: MSGGROUP#1859 Background and info on the Xerox environment In-reply-to: JSol's message of Tuesday, 31 August 1982 11:49-PDT To: Jonathan Alan Solomon cc: Mike Peeler , Geoff at Sri-Csl, GZ at Mit-Mc, HEADER-PEOPLE at Mit-Mc, MsgGroup at BRL Via: Parc-Maxc; 31 Aug 82 18:41-EDT Via: Brl; 31 Aug 82 18:46-EDT Via: Brl-Bmd; 1 Sep 82 9:39-EDT Various people have shed light on the Xerox side of this uproar: Brian Reid provided a bit of history on early roots of the problem in the Alto world, Phil Karlton gave us his story from the point of view of the implementor of the mail tools in question, and Ed Taft has now made the whole arguement moot by telling us that Xerox has already decided to install line chopping software at MAXC gateway. But Jon Solomon's message pointed out to me that there is still some misunderstanding floating around. I'll try to try to fill in some more of the gaps. Although Brian Reid was reluctant to say anything about the offending mail software, a paper has been submitted for publication that discusses the Development Environment [1], so I think I can safely shed some light without hurting anyone's eyes. Let me pause to give the usual disclaimer: I do not speak as a representative of Xerox, but only as a (relatively new) employee. Brian pointed out that the old Alto/Laurel mail system was designed by researchers who were sensitive to the ARPANET gateway sitting in their lap. Some care was taken to be able to interface properly with the outside world, and the people using the system were more aware of the issues involved. Now the world has changed somewhat. Grapevine has opened up the world of mail to non-researchers in Xerox. Although there are still more Altos around than anything else, new hardware/software combinations have come into use. One such combination is the Dandelion and the Mesa Development environment. The Dandelion (or DLion as it's known here) is the machine used in the 8010 Star workstation. As someone else from Xerox noted, the Star product is not the problem: it doesn't communicate with the ARPANET or (for the moment) Grapevine. The software called into question runs in the Mesa Development Environment, which includes all of the tools used to develop Star and the other NS8000 products. A little history: the Mesa Development Environment was born out the the experience gained from the Alto and its tools. Although many of the tools in the Development Environment existed in the Alto world, the interaction between the Alto tools was clumsy. Each tool tended to have its own style of interaction; furthermore, when you were running one tool, you couldn't run anything else. The Mesa Development Environment sought to remedy those problems. Building on the style of interaction developed in Smalltalk, InterLisp-D, and other research efforts, the Mesa Environment was developed using the paradigm of multiple-overlapping windows. In the Development environment, each 'tool' (examples compiler, mail user agent, file transfer utility, and so on) lives in a separate window. Each window can be grown, shrink, or stretched to fit the users desires. Unlike the Alto world, the Mesa environment tends not to use many different proportionally spaced fonts; typically, all tools use a single fixed-space font. The user can specify the default font he wants to use; individual tools may also choose to use different fonts. A mail tool exists; it is called Hardy. Hardy is loosely based on Laurel; it lacks many of Laurel's fancier features, but the because of the power of the environment in which it is used (multiple windows, large screen, mouse), it is very usable. Hardy, however, is only a mail reading tool; to send mail, it communicates with a Mail Send Tool. The Mail Send Tool lives in a separate window, and multiple Mail Send Tools mail be simultaneously in existance. I could, for example, move my mouse back into the Hardy window to read mail that I just received, and invoke a new Mail Send Tool to reply to a message without disturbing the message I was previously composing. Now we get to the heart of the problem. Since windows (including the Mail Send Tool) can be stretched in any manner desired, the software that underlies all windows that contain editable text automatically breaks lines that are wider than the current window. All breakage is done at word boundaries. This is similar to Emacs auto-fill mode, in that the cursor goes to the next 'line' during typein, but this word break mode is also active whenever text is displayed in a window. Thus, if I change the shape of the window that I'm reading my mail in, the text changes shape to fill out the window. When I'm reading mail, I often expand the Hardy tool window to fill the entire screen. (This can be done with one mouse click). If the text contains no extraneous newlines, I can get lots of information on my screen at once. Here's where the confusion comes in for users: the may be split over many 'logical window lines', but may in fact be a single unbroken physical line. There is no 'company policy' against newlines. The user is free to enter newline characters where ever he wants, but no one ever does unless he has to. But that's not the whole story. Phil Karlton noted that a hack exists that allows the user to chop up his message prior to sending with a single keypress. So why does mail come out unchopped? We could plead ignorance of how it looks to those out there, but that doesn't apply to everyone. I started at Xerox in mid July; prior to that, I was at UC Irvine living on 80 column CRTs. I correspond regularly with people in the net, yet people still receive unchopped messages from me on occasion. I confess: I am guilty. My problem is partially one of conditioning. This message not withstanding, I typically don't send very long messages. I tend to quickly dash things off - and for me, the sooner I've got a message off the better. As soon as I type my name at the bottom of a message, I go into automatic mode. Typing my name at the end of a message and reaching up with the mouse and bugging 'Deliver' are one action. It takes a very concicous effort to break that routine. It's not natural. So, I will welcome the installation of line chopping software at the PARC gateway. Until then, I and others will occasionally be guilty of net pollution. Please bear with us; if you find someone who doesn't seem to be aware of what they are doing, let them know. But don't pound on us; some of us are doing the best that we can. Paul Holbrook [1] Eric Harslem and LeRoy Nelson. "A retrospective on the development of Star". submitted to 6th Conference on Software Engineering, Tokyo, Japan, September 1982. 1-Sep-82 08:23:27-PDT,3221;000000000001 Mail-from: ARPANET site BRL rcvd at 1-Sep-82 0818-PDT Date: 31 August 1982 16:40-PDT - Tuesday From: Jonathan Alan Solomon To: holbrook.ES at Parc-Maxc Cc: Mike Peeler , Geoff at Sri-Csl, GZ at Mit-Mc, HEADER-PEOPLE at Mit-Mc, MsgGroup at BRL Address: 3737 South Hoover Street Room PHE 204 Los Angeles, California 90089-0273 Phone: (213) 202-1793 Subject: MSGGROUP#1860 Background and info on the Xerox environment Via: Usc-Eclc; 31 Aug 82 19:44-EDT Via: Brl; 31 Aug 82 19:45-EDT Via: Brl-Bmd; 1 Sep 82 9:41-EDT Paul, Thanks very much for your explanation, and thank you for pointing out what I was essentially trying to say. I'm sorry if you felt that I was pounding at you. The conditioning problem you describe is the heart of the problem with Internet mail. Everybody is used to a different set of "conditions". You went from the UNIX/TOPS-20 environment into the Xerox environment and have to "unlearn" what you have built up mostly out of habit. This is the complaint of many EMACS users trying to get used to (for example) TVEDIT (and contrawise too!) Also, everyone would like to implement their own version of the best, rosiest, and most advanced computer world. I, for example, consider the new From: field in RFC822 to be a step backwards in computer technology, equal in magnitude to Xerox Alto's having to conform to IBM 1130's! We have to all come to grips with the reality that IBM1130's do exist, and if we want to talk to them, we have to talk their way (Please nobody pounce on me saying that there aren't any IBM 1130's on the ARPANET, I meant it only as an example.) You have also demonstrated an awareness for the problem and a personal solution, Xerox has a different solution, which will involve insuring that even if users forget, the internet mail gateway software will fill the lines to something "reasonable". I think your solution, i.e. to change your habits, is more useful in the long run and will make you more conscious of the recipients of your message. I am more concerned with the non-researchers (particularly secretaries and administrators) who may have a hard enough time learning how to log onto the machine. The responsibility to insure that the text appears (Mike Peeler's statement) the way they want it, or (my statement) a way I can read it, is on the sender of the message, not on some arbitrary agent between the sender and the receiver. How 'bout a novice mode in this software which, when you mouse the "deliver" key, that it explains that the text is not formatted as it appears on the screen, it could further offer to format the text of the message to look exactly like what is on the screen, experts may not need this mode, so it should be switchable, but it might even be a useful reminder for you to use until you get sick of it (your memory might improve). You will be fulfilling what I consider a responsibility to your readers by insuring that mail is formatted so we can read it. I consider the "chopper" software to be a compromise, but the real problem is in design of the software and education of the users. Cheers, --JSol 1-Sep-82 08:03:32-PDT,1427;000000000001 Mail-from: ARPANET site BRL rcvd at 1-Sep-82 0800-PDT Date: 31 August 1982 1951-EDT (Tuesday) From: Craig.Everhart at Cmu-10a To: Taft at Parc-Maxc, Geoff at Sri-Csl Subject: MSGGROUP#1861 Re: Line folding and Effective Communication CC: MsgGroup at BRL, Karlton.pa at Parc-Maxc In-Reply-To: Taft@PARC-MAXC's message of 29 Aug 82 17:20-EST, <[SRI-CSL]30-Aug-82 21:19:22.GEOFF> Message-Id: <31Aug82 195141 CE10@CMU-10A> Via: Cmu-10a; 31 Aug 82 19:50-EDT Via: Brl; 31 Aug 82 19:55-EDT Via: Brl-Bmd; 1 Sep 82 9:44-EDT In order that Xerox' move to have its Arpa mail gateway fold long lines be as little a step backward as possible, I hope that some scheme for distinguishing inserted CRLFs is chosen, so that information isn't lost to those who want to reclaim it. Rick Gumpertz' suggestion (of leaving the whitespace on the line, before the CRLF) seems the best, and least obtrusive, so far. I can see pathological cases coming up if there are long sequences of whitespace (like many spaces or tabs) at the position of the line break, but this won't happen but very rarely in running prose, and will not produce that weird a result anyway. Pathology begets pathology. It's too bad that there's so much feeling about sticking to what the community is "USED TO." What did your favorite mail readers do on the occasional too-long line in the past, anyway? Craig Everhart 1-Sep-82 08:25:18-PDT,2568;000000000001 Mail-from: ARPANET site BRL rcvd at 1-Sep-82 0824-PDT Date: 31 August 1982 20:23 edt From: Barry.Margolin at Mit-Multics Subject: MSGGROUP#1862 Re: Background and info on the Xerox environment Sender: Margolin.Multics at Mit-Multics To: Jonathan Alan Solomon cc: holbrook.ES at Parc-Maxc, Mike Peeler , Geoff at Sri-Csl, GZ at Mit-Mc, HEADER-PEOPLE at Mit-Mc, MsgGroup at BRL In-Reply-To: Message of 31 August 1982 19:54 edt from Jonathan Alan Solomon Via: Mit-Multics; 31 Aug 82 20:32-EDT Via: Brl; 31 Aug 82 20:35-EDT Via: Brl-Bmd; 1 Sep 82 9:47-EDT While I do not believe in recipients formatting the message, I have to disagree with JSol that the Xerox users should learn to format their messages themselves. Within the Xerox world, sending the messages without extraneous newlines is the preferred method. Someone several days ago pointed out that messages can make their way outside Xerox-land without the sender's explicit knowledge, perhaps because an ARPAnet user was added to a mailing list. The sender cannot be expected to know of this, and cannot be expected to suddenly change habits. Since the preferred message formats differ between the two networks, it is the job of the gateway program to do the appropriate reformatting, however much we all hate the idea of automatic text munging. At least an agent that is on the Xerox network can be expected to have a better idea of the meaning of a agent on the receiver's computer. I have a question for the Xerox people. We now understand the interface that the mail sending programs present to the users. Lines are automatically wrapped to fit on the screen, and the user may insert explicit newlines anywhere he or she wishes. How, on the other hand, does one insert an explicit "don't put a newline here", in order to have an explicit over-length line, or does the concept not exist on the Xerox machines? On most systems I have used, a text line generally maps into a terminal line, but if the text line overflows the terminal line we get a continuation indicator in the margin and the text continues on the next line (breaking exactly at the margin, rather than at a word). This is not very aesthetic, but at least it retains the structure that its creator intended, and indicates that the reader should send it to a printer or wider terminal in order to see it appropriately. Tables very often come this way, and it would often not be appropriate to break these at word boundaries. 3-Sep-82 02:46:40-PDT,2424;000000000001 Mail-from: ARPANET site BRL rcvd at 3-Sep-82 0245-PDT Mail-from: ARPANET site SU-SCORE rcvd at 1-Sep-82 1215-PDT Date: 31 Aug 1982 2150-PDT From: Mark Crispin Subject: MSGGROUP#1863 more on Xerox mail Sender: ADMIN.MRC at Su-Score To: MsgGroup at Usc-Eclc Reply-To: Admin.MRC at Su-Score Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Via: Mit-Ml; 1 Sep 82 0:55-EDT Via: Brl; 1 Sep 82 1:09-EDT Remailed-date: 3 Sep 1982 0114-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup at BRL-BMD Via: Usc-Eclc; 3 Sep 82 4:14-EDT Via: Brl-Bmd; 3 Sep 82 4:26-EDT Well, now that the long-lines controversy is pretty much a dead issue, let's rock the boat with two more questions: First, for the Xerox people. Is it too much to hope that when the relay between Xerox and the ARPANET is fixed to automatically chop that it will also be fixed to put in an "at PARC-MAXC" if necessary at the end of the From line? I understand the technical difficulties involved, but the task of fixing the From line seems to be not much more difficult or onerous than auto-chopping . It should also be philsophically less objectionable. I have inquired about this before, and was told that there was no manpower to fix it; will it happen now that the autochop is going to be done? Second, I'd be interested to hear from people about reformatting algorithms for fixed-width 24x80 terminals. I am seriously considering making such a service available in MM, and would like to hear a concensus as to what a good algorithm would be. I've concluded that the obvious one of folding at the last space on an over-long line isn't good enough. What do you do about folded message which are just slightly too long, as in 85 character margins? The result of simple folding may even be uglier than no folding or folding at column 80 unconditionally. But unfolding CR's to match margins can really mess up tables. I guess that some smarts about not unfolding a short line are needed. What do we do, though, about raw CRs or raw LFs or backspaces, or raw CR's used for overtyping (e.g. underlining of emphasis)? My feeling is that if I'm going to offer line-folding I ought to do it right; otherwise I shouldn't do it at all. -- Mark -- ------- ------- 3-Sep-82 03:02:46-PDT,2608;000000000001 Mail-from: ARPANET site BRL rcvd at 3-Sep-82 0257-PDT Mail-from: ARPANET site MIT-MC rcvd at 1-Sep-82 1010-PDT Date: 1-Sep-82 9:53:18 PDT (Wednesday) From: holbrook.ES at Parc-Maxc Subject: MSGGROUP#1864 Re: Background and info on the Xerox environment In-reply-to: Margolin.Multics's message of 31 August 1982 20:23 edt To: Barry.Margolin at Mit-Multics cc: Geoff at Sri-Csl, GZ at Mit-Mc, HEADER-PEOPLE at Mit-Mc, MsgGroup at BRL Remailed-date: 3 Sep 1982 0115-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup at BRL-BMD Via: Usc-Eclc; 3 Sep 82 4:15-EDT Via: Brl-Bmd; 3 Sep 82 4:28-EDT Remember that unlike Emacs auto fill mode, there are no physical newlines in the text where the text is broke by by the window display software. With regard to the question about explicit an "don't put a newline here" indicator, no such thing exists. However, if a line is wider than your window but contains a newline at the end of it, you get the same effect that you do on many terminal when lines overflow 80 columns: part of the text gets put on the next line alone. To put it another way, If I write text broken up into short lines like this, and then display it in a narrow window, it comes out looking like this: | If I write text broken up | | into | | short lines like this, and| | then display | | it in a narrow window, it | | comes out looking like | | this: | (Folks with proportionally spaced fonts won't like me for that, but then they probably are familar with what I'm trying to get across...) As you can see, it is clear that the text contains physical lines that are wider than the window. This is obvious to the user, so all he does is increase his window size. Of course, this is what gets people into trouble when they are composing messages without newlines. If the width of the window happens to be close to 80 characters wide, it can look like it is properly broken up when it isn't. This was the point of Jon's message. Regarding the PARC gateway, I would hope that there might be a way to send mail across without having it formatted. If I wanted to send a table suitable for printing on a 132 column printer, I would not want the gateway to mess that up. Perhaps a field in the header could inform the gateway that the sender has taken responsibility for seeing that the message is formatted properly. Paul 2-Sep-82 21:47:01-PDT,1030;000000000001 Mail-from: ARPANET site BRL rcvd at 2-Sep-82 2142-PDT Date: 2-Sep-82 18:34:32 PDT (Thursday) From: AlHall at Parc-Maxc Subject: MSGGROUP#1865 Re: Xerox Woes -- Long lines without returns in them. In-reply-to: Your message of 28 Aug 1982 0701-PDT To: Mike Peeler cc: MsgGroup at BRL, AlHall at Parc-Maxc Via: Parc-Maxc; 2 Sep 82 22:52-EDT Via: Brl; 2 Sep 82 23:57-EDT Via: Brl-Bmd; 3 Sep 82 0:04-EDT Mike: Regarding your statement: [-->] "If my format bothers your eyes, I happen to know it would only take you a few keystrokes to remove the margin and reformat this message." It just so happens that I read this message off of a host that allows only message "reading" -- it does not allow for editing of the messages. I don't know if you meant to imply this, but blindly adding margins to messages is not a cure-all, and may be as much of a problem for the user to deal with as are "Long lines without returns in them." -- Al 6-Sep-82 14:43:11-PDT,1082;000000000001 Mail-from: ARPANET site BRL rcvd at 6-Sep-82 1440-PDT Date: 6 Sep 1982 1356-PDT Sender: MSGGROUP at Usc-Eclc Subject: MSGGROUP#1866 Query on Recipient Specified Redistribution From: MsgGroup Moderator - Stefferud Reply-To: MsgGroup at BRL To: MsgGroup at BRL Message-ID: <[USC-ECLC] 6-Sep-82 13:56:12.MSGGROUP> Via: Usc-Eclc; 6 Sep 82 16:58-EDT Via: Brl-Bmd; 6 Sep 82 17:05-EDT Date: 1 Sep 1982 9:37:59 EDT (Wednesday) From: Subject: Re: : Add to List Thank you for adding me to the MsgGroup List. I have a specific interest and perhaps you could help. I am interested in obtaining information on mail systems which have a unique characteristic; specifically one which supports recipient specified redistribution of incoming messages. I am not aware of any system which would allow a collection of subusers to specify which particular messages each user wants to review based upon subject matter or key words in the body of the message. Any leads are appreciated. Regards, Andy Schoka 6-Sep-82 16:47:38-PDT,869;000000000001 Mail-from: ARPANET site BRL rcvd at 6-Sep-82 1646-PDT Date: 6 Sep 1982 1558-PDT From: Feinler at Sri-Nic (Jake Feinler) Subject: MSGGROUP#1867 Re: #1831 Re: Xerox Woes -- Variable width fonts To: reid.Shasta at Sumex-Aim, Geoff at Sri-Csl To: MsgGroup at BRL, Header-People at Mit-Mc To: Human-Nets at Su-Score cc: FEINLER at Sri-Nic Via: Sri-Nic; 6 Sep 82 19:00-EDT Via: Brl; 6 Sep 82 19:07-EDT Via: Brl-Bmd; 6 Sep 82 19:16-EDT In response to the message sent 27 Aug 1982 14:22-PDT - Friday from reid.Shasta@Sumex-Aim Brian, I am curious about your statement that Grapevine 'handles many times as much mail as the Arpanet'. On what do you base this statement? To the best of my knowledge no one knows how much mail traffic is carried by the Arpanet. If you have any figures, I would be glad to get them. Jake ------- 6-Sep-82 21:37:50-PDT,1503;000000000000 Mail-from: ARPANET site BRL rcvd at 6-Sep-82 2133-PDT Date: 6 September 1982 22:24 cdt From: Stachour.CSCswtec at Hi-Multics Subject: MSGGROUP#1868 Re: #1866 Query on Recipient Specified Redistribution To: MsgGroup at BRL In-Reply-To: Msg of 09/06/82 15:56 from MsgGroup Moderator - Stefferud Via: Hi-Multics; 6 Sep 82 23:29-EDT Via: Brl; 6 Sep 82 23:37-EDT Via: Brl-Bmd; 6 Sep 82 23:48-EDT While not directly supporting the automatic re-distribution of messages, the Multics mail_system does provide, in its design, the primitives for allowing any user to build that function. Specifically, in each mailbox there is reserved a field for an event-channel identifier. If this field is non-null, the posting of a message into the mailbox is followed by the signalling of an event over the event-channel, identifying the message just arrived. This field may be set by 'anyone' who has proper access to the mailbox in question. [The Multics security mechanisms, including the 'adrosw' extended access on mailboxes will not be discussed here.] It is possible for a (blocked or running ) process to be awaiting a call on that event-channel. Upon the arrival of a message, the process would retrive the msg from the mailbox, scan it for key-words, particular senders, or whatever criteria would be desired. The process could then forward that message, write it to a file, toss it to the bit-bucket, ..., as appropriate. Paul Stachour, Honeywell CCSC 6-Sep-82 23:22:42-PDT,2090;000000000001 Mail-from: ARPANET site BRL rcvd at 6-Sep-82 2321-PDT Mail-from: SU-NET host Shasta rcvd at 6-Sep-82 2220-PDT Date: 6 Sep 1982 22:16-PDT - Monday To: Feinler at Sri-Nic, (Jake, Feinler) Cc: Geoff at Sri-Csl, Header-People at Mit-Mc, MsgGroup at BRL Subject: MSGGROUP#1869 Re: #1831 Re: Xerox Woes -- Variable width fonts In-reply-to: Your message of 6 Sep 1982 1558-PDT. From: Brian Reid Via: Sumex-Aim; 7 Sep 82 1:20-EDT Via: Brl; 7 Sep 82 1:27-EDT Via: Brl-Bmd; 7 Sep 82 1:31-EDT Jake, My estimate of relative mail traffic over Grapevine and Arpanet is based on 3 things: (1) experience at a half-dozen or so ARPANET sites watching netmail activity in and out at various times, which gave me a very rough idea of the netmail patterns in and out of those sites. I have never seen more than 1000 messages a day be sent from one Arpanet site. (In this statistic a human-nets broadcast to half of the human race is considered to be one message because the same thing is sent to all recipients.) I would be very surprised if there were more than 5 machines on the Arpanet that had outgoing message traffic that was even CLOSE to 1000 messages a day. (2) second-hand experience (i.e. hearing Grapevine people talk about it) of mail volumes at Xerox. I have no idea whether or not their numbers are considered secret, but I had better play safe and not repeat them, since Xerox considers practically everything to be secret. (3) considerations of locality. On the ARPANET machines that I have used the vast majority of the computer mail that is sent and received is local. At places like CMU and MIT, which have a zillion machines, there is a lot of "local" mail that actually moves from one machine to another but not via the Arpanet. By contrast, at Xerox all mail goes through Grapevine, because there is no such concept as "local" when everyone has his own machine. Brian 7-Sep-82 01:47:58-PDT,2284;000000000001 Mail-from: ARPANET site BRL rcvd at 7-Sep-82 0146-PDT Date: 6 Sep 1982 2357-PDT Sender: STEF at Darcom-Ka Subject: MSGGROUP#1870 Re: #1831 Re: Xerox Woes -- Variable width fonts From: STEF at Darcom-Ka To: reid.Shasta at Sumex-Aim Cc: Header-People at Mit-Mc, MsgGroup at BRL Message-ID: <[DARCOM-KA] 6-Sep-82 23:57:36.STEF> In-Reply-To: Your message of Monday, 6 Sep 1982 22:16-PDT Via: Darcom-Ka; 7 Sep 82 3:02-EDT Via: Brl; 7 Sep 82 3:08-EDT Via: Brl-Bmd; 7 Sep 82 3:58-EDT Hi Brian - All that analysis is interesting, but I find it a bit strained to lean on the technical distinction between Grapevine defining everything to be netmail, and then discounting local CMU mail. I tend to feel that mail is mail is mail, no matter how far it does (or does not) travel, or whether it goes out and back into its source host or not. In the end, it all has to be composed and sent, and then received and processed. However, I would tend to agree that Xerox users process more mail per user on the average. I base is on a hypothesis that the amount of mail a user will tolerate is proportional to the power of their processing tools. I believe that the Laurel/Grapevine tools are superior, and that those bit-mapped displays on ALTOs make for better tools. This cannot infer however, that all these Xerox users are more productive. I expect that much of the extra power goes into their many fascinating junk lists. But, of course, many are more productive. I expect that something like Parkinson's law applies here. Mail volume expands to fill the available capacity to process it. The task for management then, is to find ways to keep people focused on being productive. I doubt that this focusing activity can be automated with addtional technical features and functions. Anybody ever seen a FOCUS Command? Yes, I know this is veering off the original topic, but it seems important at this point to note that although these tools give users the power to do more, there is nothing in these tools that will automatically make make people use that capability to produce more. Indeed, I find that these tools often help me procrastinate faster, better, and more convincingly, and with less effort too! Cheers - Stef 7-Sep-82 03:52:03-PDT,2098;000000000001 Mail-from: ARPANET site BRL rcvd at 7-Sep-82 0347-PDT Date: 7 September 1982 05:35-EDT From: Gail Zacharias Subject: MSGGROUP#1871 Re: #1866 Query on Recipient Specified Redistribution To: schoka at Mitre cc: MsgGroup at BRL Via: Mit-Mc; 7 Sep 82 5:39-EDT Via: Brl; 7 Sep 82 5:53-EDT Via: Brl-Bmd; 7 Sep 82 6:00-EDT The ITS mailer allows an arbitrary program to be run when a message for a given recipient arrives. As far as I know, these are mostly used for sending stuff to the various printers and similar applications, though looking through the mailing list data base, I see that a couple people do have private programs set up. You might want to get in touch with them and see if they are or were doing what you're interested in. They are ALAN@MC, DCP@MC and DUFTY@MC. [Ed. DUFFY@MC] Here are the relevant excerpts from the mailing list documentation: RECIPIENT TYPES The TYPE attribute determines the interpretation of the recipient name string, and can at present be any of the following: .... PGM - The string is a filespec of a program which should be started and run, with the message text as JCL. See separate section about "PGM" recipients. .... MORE ABOUT THE "PGM" RECIPIENT TYPE Sending to a Program When mail arrives for a recipient of type PGM, its is treated as a , and the specified file thereupon loaded and started as an inferior job of the Comsat. The message text will be passed on as JCL for the program, and any errors can be reported to the appropriate person. The default action, in the absence of specific directives, is to let the job run for either 2 seconds run time or 1 minute real time, whichever comes first, and then disown it. Hence, the JCL must be read within a reasonable time after startup. .... The special attributes for handling PGM recipients are (R-PGM-MNTNR ) This specifies where error messages pertaining to job execution should be sent. If none is specified none is sent, other than a standard copy to COMSAT-WIZARD. 7-Sep-82 14:51:39-PDT,965;000000000001 Mail-from: ARPANET site BRL rcvd at 7-Sep-82 1447-PDT Date: 7 Sep 1982 1309-PDT From: Mark Crispin Subject: MSGGROUP#1872 Re: number of messages Sender: ADMIN.MRC at Su-Score To: Header-People at Mit-Mc, MsgGroup at BRL Reply-To: Admin.MRC at Su-Score Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Via: Su-Score; 7 Sep 82 16:13-EDT Via: Brl; 7 Sep 82 16:18-EDT Via: Brl-Bmd; 7 Sep 82 16:44-EDT I have seen SCORE process more than 1000 messages/day on several occasions. SCORE's mailer is a busy (not-so) little beaver; if it gets blocked for even as short an interval as an hour hundreds of messages will pile up in its queues. I don't have firm statistics, but I am fairly certain it has delivered more than 1000 pieces of netmail in a single day during busy days. I'll confess that much of the netmail is to other Stanford facilities. ------- 7-Sep-82 17:12:04-PDT,2010;000000000001 Mail-from: ARPANET site BRL rcvd at 7-Sep-82 1710-PDT Mail-from: SU-NET host Shasta rcvd at 7-Sep-82 1502-PDT Date: 7 Sep 1982 14:57-PDT - Tuesday To: STEF at Darcom-Ka Cc: Header-People at Mit-Mc, MsgGroup at BRL Subject: MSGGROUP#1873 Stef's comment on my answer to Jake In-reply-to: Your message of 6 Sep 1982 2357-PDT. <[DARCOM-KA] 6-Sep-82 23:57:36.STEF> From: Brian Reid Via: Sumex-Aim; 7 Sep 82 17:58-EDT Via: Brl; 7 Sep 82 18:05-EDT Via: Brl-Bmd; 7 Sep 82 18:12-EDT I think that for this issue it is quite appropriate to pay careful attention to the distinction between local mail and network mail, even if the network is 10 feet long and goes to the next room. The essence of this discussion has been that there is a particular standard for the format of mail during transport, which is used by Xerox internally but which has been judged "losing", "too expensive", "wrong", "bogus", and so forth by a random collection of hackers in the Arpanet community. There have been two parts to the discussion: (1) Is the Xerox standard a reasonable thing to do, technically? (2) Given that Xerox has been gating mail from their internet out to the Arpanet without adjusting its format, which violates conventions but not standards on the Arpanet, Arpanet, should they be pressured into changing this behavior? My point at the time I sent the original message a couple of weeks ago is that the Xerox folks had a huge amount of mail traffic TRANSPORTED OVER A NETWORK, AND THEREFORE SUBJECT TO RULES AND CONVENTIONS OF NETWORK TRANSPORT. They needed to adopt a transport convention that was better than what the Arpanet uses, because they had a higher volume of mail that could be damaged by an inappropriate format. In summary: the Xerox people had a greater need for good network transport conventions than did Arpanet people, because all of the Xerox mail had to go through network transport. 7-Sep-82 17:48:22-PDT,821;000000000001 Mail-from: ARPANET site BRL rcvd at 7-Sep-82 1748-PDT Date: 7 Sep 82 19:28:03-EDT (Tue) From: Michael Muuss To: MsgGroup at BRL cc: Header-People at Mit-Mc Subject: MSGGROUP#1874 Messages per Day (BRL) Via: Brl-Bmd; 7 Sep 82 19:42-EDT Via: Brl; 7 Sep 82 19:47-EDT Via: Brl-Bmd; 7 Sep 82 19:59-EDT BRL processes about 200 messages per day, with between 1 and 700 recipients per message (average of about 20). This implies delivery of about 4000 COPIES of messages per day. No real distinction is made between local and network(s) delivery in these statistics. We don't even mail most of the big digests any more! Who says the ArpaNet doesn't carry lots of mail? We sometimes have to run 5 or 6 network mailers just to push the stuff out in a timely fashion. -Mike 7-Sep-82 18:08:01-PDT,2718;000000000001 Mail-from: ARPANET site BRL rcvd at 7-Sep-82 1807-PDT Date: 7 Sep 1982 1641-PDT From: Mark Crispin Subject: MSGGROUP#1875 local mail vs. network mail Sender: ADMIN.MRC at Su-Score To: MsgGroup at BRL, Header-People at Mit-Mc Reply-To: Admin.MRC at Su-Score Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Via: Su-Score; 7 Sep 82 19:41-EDT Via: Brl; 7 Sep 82 19:47-EDT Via: Brl-Bmd; 7 Sep 82 19:58-EDT I think the issue of transport conventions is irrelevant. Xerox comprises an essentially homogenous community. When dealing with a heterogeneous community sacrifices at times have to be made to meet some sort of common denominator. I am interested in seeing some sort of automatic line-breaking available in the MM mailsystem for TOPS-20. I feel, though, that I want to do more than the half-way solution of merely breaking overly long lines. I also want it to repair lines that are "just slightly" too long, such as messages using an 85 character margin on my 80 character/line terminal. I would want such messages presented to me in a pleasing format, much as M-G or repeated applications of M-Q in EMACS would do for me. As a mailsystem maintainer, I would like time to think about these issues. I'm also worried about the RFC 822, SMTP, and TCP/IP conversions. My mailsystem presently talks (perfectly valid) RFC 733, FTP, and NCP; in some cases my mailsystem's usage of RFC 733 is invalid under RFC 822 (e.g. multiple at's and allowing non-mailbox From's) and addressing these matters has top priority. Since Xerox has decided to apply line breaks in messages sent out over the Internet, let's get our TCP/IP transitions done first. Once that has been completed, we ought to talk somewhat about the structure of the text of an electronic mail message and means of dealing with alternative notions of proper structure. I at least would like to see something done in this area, but, hey, I don't know about the other software wizards, but my brain overloads when I have too many things to do. Please don't talk about forcing us mailsystem maintainers to deal with long-line messages now. At least with me (and perhaps others) it scares us and makes us react defensively when we already have the terrifying December 31 deadline hanging over us. After December 31, I think all of the ARPANET software maintainers should all get together and have a big party. Everybody else should wait a week (a month? six months?) for us to recover from our hangovers then give us the long lines. We'll be much more receptive. -- Mark -- ------- 7-Sep-82 21:57:18-PDT,1141;000000000001 Mail-from: ARPANET site BRL rcvd at 7-Sep-82 2152-PDT Date: 7 September 1982 2356-EDT (Tuesday) From: Craig.Everhart at Cmu-10a To: STEF at Darcom-Ka, Admin.MRC at Su-Score Subject: MSGGROUP#1876 Re: #1831 Re: Xerox Woes -- Variable width fonts and local mail vs. network mail CC: MsgGroup at BRL In-Reply-To: <[DARCOM-KA] 6-Sep-82 23:57:36.STEF>, Mark Crispin\@Su-Score's message of 7 Sep 82 18:41-EST Message-Id: <07Sep82 235659 CE10@CMU-10A> Via: Cmu-10a; 7 Sep 82 23:52-EDT Via: Brl; 7 Sep 82 23:59-EDT Via: Brl-Bmd; 8 Sep 82 0:13-EDT CMU's RdMail has had a Context command for years. You have to tell it some sequence of messages to which you now wish to restrict your attention, but something like <-context new intersect subject 'printing' with abbreviations and all, can work quite nicely. It is unfortunate that reformatting barely-too-long lines in messages is so much more invasive than reformatting those that are way too long. I only hope that the artificial folding imposed at the Xerox gateway is undoable, but I guess I've said that before. Craig Everhart 7-Sep-82 21:57:20-PDT,2140;000000000001 Mail-from: ARPANET site BRL rcvd at 7-Sep-82 2154-PDT Date: 7 Sep 82 23:50:33-EDT (Tue) From: Doug Kingston To: MsgGroup at BRL cc: AlHall at Parc-Maxc, dpk at BRL, stef at Darcom-Ka Subject: MSGGROUP#1877 Long lines and the Arpanet Via: Brl-Bmd; 8 Sep 82 0:01-EDT There was a recent problem with the MsgGroup mailing list that would be of interest to the entire list. The symtom was that a certain user at Wharton-10 was receiving an endless number of copies of a message from Al Hall at Parc-Maxc. Upon looking at the logs, it appeared that the Wharton FTP was returning: "500 Last line was too long." This code is classified as a syntax error code, but it also implies permanent error. MMDF, our outbound mailer, considers syntax errors (500 and 501) as transmission errors and requeues them for later retry. The reasoning for this is that there should be no syntax errors in a working system, and if there were, something is quite ill. The Wharton mailer was passing the partially complete letter onto the poor user at Wharton after rejecting it. MMDF would resubmit it, and it would be rejected again,... and again, ... and again. The blame is probably ours for not giving up on the letter. What kind of letter is this you ask?? Why a letter with a 266 character line, of course! The long line didn't give our mailer any problems, but the complications with another mailer as a result caused one person a lot of grief. I personally feel that the text of the message ought to be able to be ANYTHING the user desires, including binary. But the world is not prepared for that yet. It would be resonable for that to be part of some yet to be conceived RFC. This gets back to the desire to separate the "envelope" and the "letter". But I'm getting afield. As this incident shows, it would be very civilized of Xerox if they would chop their lines at the gateway, until the rest of the world has a chance to catch up with modern mail technology. Your Postmaster, Doug PS. We will be putting a line chopper into our mail reader soon... 8-Sep-82 01:47:23-PDT,808;000000000001 Mail-from: ARPANET site BRL rcvd at 8-Sep-82 0146-PDT Date: 7 September 1982 20:36-EDT From: Earl A Killian Subject: MSGGROUP#1878 statistics To: HEADER-PEOPLE at Mit-Mc, MsgGroup at BRL Via: Mit-Mc; 8 Sep 82 3:48-EDT Via: Brl; 8 Sep 82 3:57-EDT Via: Brl-Bmd; 8 Sep 82 4:06-EDT Here are some MC statistics for the 24 hours of 9/6/82. This is unfortunately a holiday, but older data is on tape. 933 mail new items were submitted, 601 from the network. 2353 icps were attempted, 1057 of which failed. 3439 recipients received mail (no idea how many local). Of the above, some of the stuff used the multiple recipient feature of mail delivery for network mail. 247 messages reaching 940 recipients were sent with this technique (i.e. 3.8 recipients per message). 8-Sep-82 03:51:48-PDT,756;000000000001 Mail-from: ARPANET site BRL rcvd at 8-Sep-82 0347-PDT From: smb.unc at BRL Date: 7 Sep 82 23:46:13 EDT (Tue) Original-From: Steve Bellovin Subject: MSGGROUP#1879 minor complaint To: MsgGroup at BRL, Header-People at Mit-Mc Via: (unc); 8 Sep 82 5:39-EDT Via: Brl-Bmd; 8 Sep 82 5:44-EDT Via: Brl; 8 Sep 82 5:57-EDT Via: Brl-Bmd; 8 Sep 82 6:10-EDT Is there any chance we can get this discussion on just one of the two lists? I'm starting to feel like Captain Yossarian ("I see everything twice!"), and I suspect I'm not the only one. To avoid further debate on both lists simultaneously, I hereby suggest that we move the "long lines from Xerox" discussion, and all its children, to just MSGGROUP. --Steve 8-Sep-82 14:10:01-PDT,2227;000000000001 Mail-from: ARPANET site BRL rcvd at 8-Sep-82 1408-PDT Date: 8 Sep 1982 9:42:37 EDT (Wednesday) From: schoka at Mitre Subject: MSGGROUP#1880 Re: #1866 Re: recipient specified redistribution In-Reply-to: Your message of 6 Sep 1982 19:40 PDT To: MsgGroup at Usc-Eclc Remailed-date: 8 Sep 1982 1226-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup at BRL-BMD Via: Usc-Eclc; 8 Sep 82 15:23-EDT Via: Brl-Bmd; 8 Sep 82 15:48-EDT This message is a follow-up of an earlier request for information on a subject I have termed recipient-specified distribution. Within the military community, formal communications are accomplished through General Service (GENSER) message traffic on the AUTODIN network. In many cases the originators of these messages address them to organizations or component offices rather than to specific individuals. At the receiving office which may contain tens to hundreds of personnel a manual distribution function is performed. Multiple hard copies of the incoming message are distributed to individuals who have specified their requirement to recieve a copy of that message. That requirement may be based upon such items as originator, subject, or specific message content in the form of key words or phrases. In most cases this recipient specified 'profile' is dynamic in nature and is subject to frequent update based upon the current operational situation. Each individual or group of individuals performing a like function requires their own profile and each profile may contain hundreds of entries. Today the process of recipient-specified message distribution is mostly a manual operation. My interest is in identifying candidate computer-based capabilities which may automate in part or in toto the administrative distribution function assuming that recipients are provided terminals with which they may receive and review their messages in electronic form. One generic source of analogous capability appears to be the emerging commercial electronic mail systems being employed on ARPANET. However, my knowledge of this community is limited and I look to this MsgGroup forum for any leads. 8-Sep-82 13:51:16-PDT,1778;000000000001 Mail-from: ARPANET site BRL rcvd at 8-Sep-82 1349-PDT Date: 8 September 1982, 03:58-EDT - Wednesday From: Robert W Kerns Subject: MSGGROUP#1881 Re: Stef's comment on my answer to Jake To: reid.SU-SHASTA at BRL Cc: STEF at Darcom-Ka, Header-People at Mit-Mc, MsgGroup at BRL In-reply-to: The message of 7 Sep 82 17:57-EDT from Brian Reid Via: Mit-Ml ; 8 Sep 82 8:39-EDT Via: Brl ; 8 Sep 82 15:17-EDT Via: Brl-Bmd ; 8 Sep 82 15:38-EDT My point at the time I sent the original message a couple of weeks ago is that the Xerox folks had a huge amount of mail traffic TRANSPORTED OVER A NETWORK, AND THEREFORE SUBJECT TO RULES AND CONVENTIONS OF NETWORK TRANSPORT. Actually, it had to do with the rules and conventions of transport, not the fact that it went over a piece of cable or a phone line. The problem arises from the fact that the mail reader and the mail sender have to communicate. At TOPS-20 sites, for example, mail is composed by BABYL, MM, MSG, HERMES, etc. If one of these were to expect that the receiver breaks lines, you can be sure there would be an uproar from the users of all the other software! All messages are transported, whether they happen to pass through something called a network or not. In summary: the Xerox people had a greater need for good network transport conventions than did Arpanet people, because all of the Xerox mail had to go through network transport. This is nonsense, when you realize (from above) that the word "network" is completely spurious. And in order to communicate with US, their greatest need is transport protocols which are COMPATIBLE. They realized this, and have promised to fix it. 9-Sep-82 03:45:23-PDT,603;000000000001 Mail-from: ARPANET site BRL rcvd at 9-Sep-82 0344-PDT Date: 9 Sep 1982 0219-PDT From: Mike Peeler Subject: MSGGROUP#1882 Re: Xerox Woes -- Long lines without returns in them. To: AlHall at Parc-Maxc cc: MsgGroup at BRL In-Reply-To: Your message of 2-Sep-82 1834-PDT Via: Su-Score; 9 Sep 82 5:22-EDT Via: Brl; 9 Sep 82 5:38-EDT Via: Brl-Bmd; 9 Sep 82 5:45-EDT Al, When I said, "I happen to know it would only take you a few keystrokes..." I thought it would be clear I was specifically addressing not you, but the ADDRESSEE! Yours, Mike 9-Sep-82 09:30:42-PDT,742;000000000001 Mail-from: ARPANET site BRL rcvd at 9-Sep-82 0927-PDT Return-path: @USC-ISID,@UCL-CS,steve@ucl-cs Via: USC-ISID ; Thursday, September 9, 1982 08:21:58-PDT Date: 9 Sep 82 9:17:35-BST (Thu) From: Steve Kille Reply-To: steve%ucl-cs at Usc-Isid To: header-people at Mit-Mc, msggroup at BRL cc: indra.UCL-CS at BRL Subject: MSGGROUP#1883 UCL statistics Via: Usc-Isid; 9 Sep 82 11:28-EDT Via: Brl; 9 Sep 82 11:38-EDT Via: Brl-Bmd; 9 Sep 82 11:53-EDT For those interested, here are UCL-CS statistics for 6 September. 95 local letters processed 107 letters from various networks 692 local recipients (total) 81 network recipients 3.9 recipients per letter average Steve Kille --------  9-Sep-82 13:57:14-PDT,773;000000000001 Mail-from: ARPANET site BRL rcvd at 9-Sep-82 1354-PDT Date: 9 September 1982, 15:31-EDT - Thursday From: Robert W Kerns Subject: MSGGROUP#1884 UCL statistics To: steve%ucl-cs at Usc-Isid Cc: header-people at Mit-Mc, msggroup at BRL, indra.UCL-CS at BRL Fcc: SCRC:OUTGOING.BABYL In-reply-to: The message of 9 Sep 82 16:17-EDT from Steve Kille Via: Mit-Mc; 9 Sep 82 15:45-EDT Via: Brl; 9 Sep 82 15:53-EDT Via: Brl-Bmd; 9 Sep 82 16:12-EDT For those interested, here are UCL-CS statistics for 6 September. 95 local letters processed 107 letters from various networks How many people use your system in a day? This is about the number of messages I receive personally every day. 10-Sep-82 00:41:50-PDT,991;000000000001 Mail-from: ARPANET site BRL rcvd at 10-Sep-82 0039-PDT Date: 10 September 1982, 02:16-EDT - Friday From: Robert W Kerns Subject: MSGGROUP#1885 More header mangling To: MsgGroup at BRL, HEADER-PEOPLE at Mit-Mc Via: Mit-Mc; 10 Sep 82 2:40-EDT Via: Brl; 10 Sep 82 2:48-EDT Via: Brl-Bmd; 10 Sep 82 2:57-EDT I wish whatever it is (at BRL, I think) that is mangling my headers I send to MsgGroup would stop it. It probably thinks it is doing everybody a service, but it is wrong. I can *NOT* be reached as RWK.SCRC-TENEX at MIT-MC. I *CAN* be reached as "RWK at SCRC-TENEX" at MIT-MC. If this translater wants to "help" convert to the standard that was decreed without telling anyone, it could convert it to "RWK.SCRC-TENEX.MIT-MC" at BRL, and forward that to "RWK at SCRC-TENEX" at MIT-MC. It does no one any good to convert from a formerly legal address that still works to a currently legal (but stupid) address that does NOT work. 10-Sep-82 01:21:51-PDT,795;000000000001 Mail-from: ARPANET site BRL rcvd at 10-Sep-82 0118-PDT Date: 10 Sep 82 3:24:38-EDT (Fri) From: Doug Kingston To: Robert W Kerns cc: MsgGroup at BRL, HEADER-PEOPLE at Mit-Mc Subject: MSGGROUP#1886 Re: More header mangling Via: Brl-Bmd; 10 Sep 82 3:30-EDT Via: Brl; 10 Sep 82 3:41-EDT Via: Brl-Bmd; 10 Sep 82 3:44-EDT I will endeavor to see what I can do, but the MIT gateway is largely at fault for allowing ILLEGAL headers onto the network. The conversion of illegal headers is undefined operation. I also have a more serious bug to fix which will take precedence. The person responsible for the address parser is currently unavailable for two weeks, so I may have difficultly unearthing the "problem" myself. -Doug- 10-Sep-82 02:21:47-PDT,2333;000000000001 Mail-from: ARPANET site BRL rcvd at 10-Sep-82 0218-PDT Date: 10 Sep 1982 0111-PDT From: Mark Crispin Subject: MSGGROUP#1887 header mangling Sender: ADMIN.MRC at Su-Score To: MsgGroup at BRL, Header-People at Mit-Mc Reply-To: Admin.MRC at Su-Score Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Via: Su-Score; 10 Sep 82 4:15-EDT Via: Brl; 10 Sep 82 4:31-EDT Via: Brl-Bmd; 10 Sep 82 4:34-EDT In an attempt to work around the problem of multiple at's and relays, I am planning on having MMAILR use "%" instead of multiple " at "'s to indicate a routed address. In other words, the former RWK at SCRC-TENEX at MIT-MC will become RWK%SCRC-TENEX at MIT-MC I would like to ask the maintainers of the MIT I.T.S. FTP server to make the (simple) change to their software so that "%" is accepted as an alternative to "@". This will be done to the TOPS-20 FTP server shortly, in a release with some other bugfixes for TOPS-20 FTPSER in the XMAILR environment. Once the code in MMAILR is debugged, it will be retrofitted into XMAILR. For those folks wondering what MMAILR is, it is a TOPS-20 only descendant of XMAILR for the brave new world of SMTP and TCP/IP. It supports the new standard for the format of queued mail, and has several incompatible changes in interface from XMAILR. MMAILR is still "under development" and isn't ready for any sites to run yet, although it will be in alpha test soon. You know, I just realized one loss with not having multiple at addresses. MM used to be smart enough to realize when a relay route was not needed. If it recognized any of the host names in the route list, it could flush the remainder of the route and compute the route itself. With the new scheme, MM cannot have any knowledge of what constitutes a relay-routed address and so cannot be smart about how to deliver it. If I receive a message for whom one of the recepients is FOO%SU-SCORE at MIT-XX, it would have to deliver to XX since it really cannot know that the FOO is a local mailbox; formerly it did. Any scheme where it would know that "%" is a relay character with certain hosts would remove generality and otherwise would not be trustworthy. -- Mark -- ------- 10-Sep-82 02:41:50-PDT,935;000000000001 Mail-from: ARPANET site BRL rcvd at 10-Sep-82 0236-PDT Return-path: @USC-ISID,@UCL-CS,steve@ucl-cs Via: USC-ISID ; Friday, September 10, 1982 01:14:04-PDT Date: 10 Sep 82 9:09:25-BST (Fri) From: Steve Kille To: Robert W Kerns cc: steve%ucl-cs at Usc-Isid, header-people at Mit-Mc, msggroup at BRL, indra.UCL-CS at BRL Subject: MSGGROUP#1888 Re: UCL statistics Via: Usc-Isid; 10 Sep 82 4:42-EDT Via: Brl; 10 Sep 82 4:50-EDT Via: Brl-Bmd; 10 Sep 82 5:00-EDT There are about 70 local users. At a guess, there are 20 or so users processing 20-30 messages a day comprising most of the local load. These figures are probably not at all stable, as a usable return path from the ARPANET ha only become available over the last few months. I will be compiling some rather more detailed statistics in the near future if anyone is interested Steve --------  10-Sep-82 03:21:44-PDT,2521;000000000001 Mail-from: ARPANET site BRL rcvd at 10-Sep-82 0318-PDT Date: 10 Sep 1982 0154-PDT From: Mark Crispin Subject: MSGGROUP#1889 Re: More header mangling Sender: ADMIN.MRC at Su-Score To: dpk at BRL cc: RWK.SCRC-TENEX at Mit-Mc, MsgGroup at BRL, HEADER-PEOPLE at Mit-Mc Reply-To: Admin.MRC at Su-Score Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In-Reply-To: Your message of 10-Sep-82 0024-PDT Via: Su-Score; 10 Sep 82 5:00-EDT Via: Brl; 10 Sep 82 5:20-EDT Via: Brl-Bmd; 10 Sep 82 5:25-EDT This isn't completely fair. At the time the software which sends multiple-at headers was implemented, it was done as part of the official, published standard, RFC 733. Those who decided to invalidate multiple-at addresses did so without generally publishing the decision (much less consulting with the implementors of relays into the MIT, Stanford, CMU, and Rutgers local networks!) deserve the recriminations. Those of us who implemented a multiple-at address mailsystem in good faith, believing the published standards, do not. I am under the impression that even RFC 822 supports multiple at headers if the string with the extra at's is quoted, e.g. that "RWK@SCRC-TENEX" at MIT-MC is a perfectly valid address. So let's not talk about "illegal" headers; until I see somebody go to jail for generating a multiple at addresses let's say "invalid under the current standard" and recognize that these addresses were valid in the standard in effect up to less than a month ago. It has already been agreed that we'll change our mail software to use "%" instead of multiple at's, although we would rather move away from relays in favor of domains entirely. Allow us time to convert! It is clear to me, though, that a site relaying messages should not reformat the message header the way BRL is doing. If BRL's mailer perceives that the header is invalid, it should treat it as text and build a new header on top of it. Any reformatting of the header could actually destroy information; as in this case where BRL's mailer destroyed information which would be meaningful to some sites at least in favor of information which is useless to everybody. At the same time, I recognize that BRL has other matters which are of greater priority to address. Hopefully we'll both have our mailsystems fixed in the not-too-distant future. Peace, -- Mark -- ------- 10-Sep-82 13:25:23-PDT,933;000000000001 Mail-from: ARPANET site BRL rcvd at 10-Sep-82 1321-PDT Date: 10 Sep 82 11:29:29-EDT (Fri) From: Dave Crocker To: rwk.src-tenex at Mit-Mc cc: MsgGroup at BRL, HEADER-PEOPLE at Mit-Mc Subject: MSGGROUP#1890 Re: More header mangling Via: Udel-Relay; 10 Sep 82 13:16-EDT Via: Brl; 10 Sep 82 13:32-EDT Via: Brl-Bmd; 10 Sep 82 13:50-EDT Nice to have your attention. I have repeatedly reported the situation to people at MIT, to no effect. The problem, of course, is that you guys are sending out illegal headers. It is, therefore, not too suprising that MMDF's header-munging code mishandles it. If you sent out "mbox at foo" at bar, things would be fine. Unfortunately, the initial stuff is not quoted, so that the specification contains two parts. If you fix that and headers are still mangled, when relayed, we'll be glad to try to find the problem at our end. Dave 10-Sep-82 16:04:17-PDT,2915;000000000001 Mail-from: ARPANET site BRL rcvd at 10-Sep-82 1601-PDT Date: 10 September 1982 14:36-PDT - Friday From: Jonathan Alan Solomon To: Dave Crocker Cc: HEADER-PEOPLE at Mit-Mc, MsgGroup at BRL, RWK.SCRC-TENEX at BRL Address: 3737 South Hoover Street Room PHE 204 Los Angeles, California 90089-0273 Phone: (213) 202-1793 Subject: MSGGROUP#1891 More header mangling Via: Usc-Eclc; 10 Sep 82 17:37-EDT Via: Brl; 10 Sep 82 17:48-EDT Via: Brl-Bmd; 10 Sep 82 17:56-EDT 1) I believe RFC822 will be officially implemented on Jan 1983, which means that until then we follow RFC733, right? Mail system implementors need time to work, right? 2) During the conversion - we should EXPECT to find inconsistencies, and problems replying to mail. Messages which are so crucial should have instructions in the message as to how to reply (note I put my USPS address and my home telephone number in the headers if you can't get electronic mail to me). 3) It will do no good to throw flames at each other. According to ARPA, USER.HOST@FORWARDER is as invalid as USER@HOST@FORWARDER, so BRL is as much at fault as MIT, BRL may (if it feels compelled to) change USER@HOST@FORWARDER into USER%HOST@FORWARDER. 4) I don't consider it valid to change RWK at SCRC-TENEX into rwk.src-tenex at Mit-Mc, under *ANY* mail standard. a) First of all, rwk is not lower case, both rfc733 and rfc822 specify that mail gateways should not change case of mail. b) src-tenex is not src-tenex, but SCRC-TENEX. You don't need an rfc to realize that the name is mispelled, even if the world knew how to forward to that address, src-tenex is not even a valid host. i) not only that, but scrc-tenex wouldn't be valid either since it is lower case c) Mit-Mc is MIT-MC, not casified. 4) ECL will eventually support all forms of forwarding. Currently it allows you to send user%host@forwarder, and user@host@forwarder. 5) To the best of my knowledge, RFC822 doesn't allow "JSOL at MIT-MC" or "JSOL%MIT-OZ" at MIT-MC as valid, it seems to require (someone correct me if I am wrong, I'm about to make changes to XMAILR to support this) JSOL%MIT-OZ@MIT-MC, or JSOL@MIT-MC. I seem to recall much hot flammage about this particular topic on Header-People not too recently. Someone out there (in UNIX land?) complained that ,"a","t", was too hard to parse? Please - nobody take all of this flaming personally. I think it's horribly silly to argue about things which we have all committed to change. The secret word here is time, give us maintainers time to implement things!! Rwk - perhaps you just wanted to hear that MMDF will be changed to conform to Rfc822? Yes, well it will be changed, so will XMAILR. Anyone want to volunteer to change COMSAT (on ITS?). Peace, --JSol 12-Sep-82 17:36:44-PDT,1660;000000000001 Mail-from: ARPANET site BRL rcvd at 12-Sep-82 1736-PDT Date: 10 September 1982, 19:50-EDT - Friday From: Robert W Kerns Subject: MSGGROUP#1892 Re: More header mangling To: dpk at BRL Cc: header-people at Mit-Mc, MsgGroup at BRL In-reply-to: The message of 10 Sep 82 03:24-EDT from Doug Kingston Via: Mit-Mc; 10 Sep 82 21:24-EDT Via: Brl; 12 Sep 82 19:23-EDT Via: Brl-Bmd; 12 Sep 82 19:44-EDT Date: 10 Sep 82 3:24:38-EDT (Fri) From: Doug Kingston I will endeavor to see what I can do, but the MIT gateway is largely at fault for allowing ILLEGAL headers onto the network. The conversion of illegal headers is undefined operation. I also have a more serious bug to fix which will take precedence. The person responsible for the address parser is currently unavailable for two weeks, so I may have difficultly unearthing the "problem" myself. Thanks for your attention. I'm very hostile to the idea that MIT is "at fault" in this matter. Mark Crispin's observations sum up the situation very well; this is something that was changed out from beneath MIT and other places that implemented relaying early on. It was done in such a way as to guarentee maximal disruption. I can sympathize with your needing time to do it; I certainly do not have time to fix MIT's software for them. Back when I worked for MIT that might have been a posibility. (Actually, I'm not sure who put on that header; come to think of it it probably was XMAILR (Mark Crispin's work), rather than the MIT software, but MIT is in the same boat.) 12-Sep-82 17:47:01-PDT,2597;000000000001 Mail-from: ARPANET site BRL rcvd at 12-Sep-82 1743-PDT Date: 10 September 1982, 19:29-EDT - Friday From: Robert W Kerns Subject: MSGGROUP#1893 Re: More header mangling To: dcrocker at Udel-Relay Cc: MsgGroup at BRL, HEADER-PEOPLE at Mit-Mc In-reply-to: The message of 10 Sep 82 11:29-EDT from Dave Crocker Via: Mit-Mc; 10 Sep 82 20:06-EDT Via: Brl; 12 Sep 82 19:21-EDT Via: Brl-Bmd; 12 Sep 82 19:42-EDT Date: 10 Sep 82 11:29:29-EDT (Fri) From: Dave Crocker Nice to have your attention. I have repeatedly reported the situation to people at MIT, to no effect. The problem, of course, is that you guys are sending out illegal headers. It is, therefore, not too suprising that MMDF's header-munging code mishandles it. If you sent out "mbox at foo" at bar, things would be fine. Unfortunately, the initial stuff is not quoted, so that the specification contains two parts. As you well know, this is perfectly legal under RFC733. The decision to make declare it illegal was made almost in secret much later, without MIT's participation, and not announced until after everybody maintaining MIT's mailer had left MIT. There is no hope of making the change in the immediate future. If the people trying to impose this change had been less secretive (or if they had paid attention to MIT's calls for structure in mailbox names at the time, which would provide an alternative to this technique), then this situation could have been avoided. In the meantime, we all have to live with the consequences, even those of us who had nothing to do with the mess. If you fix that and headers are still mangled, when relayed, we'll be glad to try to find the problem at our end. Dave Doing nothing at all when you don't understand the header is the ONLY reasonable course. Of course, if you DID want to understand and convert the double syntax to fit the current decrees, (and you must have understood it to make this wrong conversion!), convert it to be "FOO@BAR" at BAZ, and all will be well. I can see no reason to believe that converting to "FOO.BAR" would EVER be understood, since if it were, then that syntax would have been generated in the first place. Since it now appears that MIT will be converted to TCP, there is hope of getting MIT's mailer changed as well, but I doubt it would happen until after the TCP conversion. Unless there's someone at MIT going to do it that I don't know about. 12-Sep-82 22:36:03-PDT,2185;000000000001 Mail-from: ARPANET site BRL rcvd at 12-Sep-82 2232-PDT Date: 12 Sep 1982 2126-PDT From: ROODE at Sri-Nic (David Roode) Subject: MSGGROUP#1894 line breaks in messages To: MsgGroup at BRL Location: EJ296 Phone: (415) 859-2774 Via: Sri-Nic; 13 Sep 82 0:34-EDT Via: Brl; 13 Sep 82 0:39-EDT Via: Brl-Bmd; 13 Sep 82 0:46-EDT A lot of the discussion on the semantically) meaningful carriage line break issue stemmed from return"? I say the problem is it trying to define or redefine the has meant either, with intelligent ASCII CRLF sequence. Over the decision-making required on the years, has this meant "carriage part of the reader to discern return of formatting circumstance" which function was applicable in a or "mandatory (syntactically and given instance. * * * * Someone said the multimedia distinction. I would then mail format described in RFC 767 require or at least strongly required the exclusion of urge use of the sequence CRLF formatting-motivated CRLF's in in the manner most closely text bodies. Not so. It compatible with existing usage. specifically allows them, but Namely, CRLF would mean "line does not require them. More break as seen by sender." importantly a separate means of (Note that this encoding indicating the "mandatory" reflects the fact that a carriage return or equivalent is mandatory carriage return is provided via the multimedia also a carriage return as structured message format. seen by the sender.) I would propose use of the This is merely an EXTENSION of three character sequence CR CRLF the Xerox encoding which provides to indicate mandatory carriage for optionally preserving some return. This should cause minimal additional information and thereby problems for existing mail systems allowing the final recipient to which do not recognize such a decide on its usefulness to him. ------- 13-Sep-82 09:46:41-PDT,847;000000000001 Mail-from: ARPANET site BRL rcvd at 13-Sep-82 0943-PDT Date: 13 Sep 82 11:45:07-EDT (Mon) From: Ron Natalie To: msggroup at BRL, mmdf at BRL Subject: MSGGROUP#1895 Header Mangling. Via: Brl-Bmd; 13 Sep 82 11:46-EDT Via: Brl; 13 Sep 82 11:59-EDT Via: Brl-Bmd; 13 Sep 82 12:13-EDT Another can of gasoline on the flames... Changing standards certainly are an annoyance but they are not an excuse. The ARPAnet leader formats were changed on Jan 1 1981 (less than two years ago) and the entire net protocal will be switched to TCP/IP by New Years. MIT didn't seem to have any problems supporting the last change and I suppose TCP will be in by the deadline. Those who refuse to change by asserting the "we did it our way first" rule will probably be first against the wall when the revolution comes. 13-Sep-82 11:11:33-PDT,1048;000000000001 Mail-from: ARPANET site BRL rcvd at 13-Sep-82 1107-PDT Date: 13 Sep 1982 1239-EDT From: Larry Campbell To: Ron Natalie , msggroup at BRL, mmdf at BRL Subject: MSGGROUP#1896 Re: Header Mangling. Message-ID: <"MS11(2227)+GLXLIB1(1056)" 11855644277.24.71.5181 at DEC-MARLBORO> Regarding: Message from Ron Natalie of 13-Sep-82 1145-EDT Via: Dec-Marlboro; 13 Sep 82 12:46-EDT Via: Brl; 13 Sep 82 13:09-EDT Via: Brl-Bmd; 13 Sep 82 13:13-EDT Note that the long leader change was announced at least two years in advance; TCP/IP has had even more advance PR. RFC822, however, has been discussed among a small set of people for only a couple of months and has now been "mandated" despite continuing, valid technical objections. I think this is what RWK is objecting to; it is a high-handed, ill-thought-out fiat by a small number of people who have not given the matter sufficient opportunity for debate, and have not allowed enough time for implementation changes. -------- 13-Sep-82 12:17:25-PDT,843;000000000001 Mail-from: ARPANET site BRL rcvd at 13-Sep-82 1214-PDT Date: 13 September 1982 1343-EDT (Monday) From: Richard H Gumpertz To: MsgGroup at BRL Subject: MSGGROUP#1897 RFC 822 Message-Id: <13Sep82 134335 RG02@CMU-10A> Via: Cmu-10a; 13 Sep 82 14:10-EDT Via: Brl; 13 Sep 82 14:20-EDT Via: Brl-Bmd; 13 Sep 82 14:32-EDT RFC stands for Request For Comments. It is not at all clear that comments were really wanted. If there were such a thing as an acceptance vote on 822, I guess I would have to vote against it -- too many of the changes seem to be capricious and without agreement by a large number of the people impacted. In fact, I am not sure why 822 even exists. Why not leave things as they are until we can agree upon a complete (not incremental) overhaul of mail protocols? Rick 13-Sep-82 20:47:58-PDT,442;000000000001 Mail-from: ARPANET site BRL rcvd at 13-Sep-82 2046-PDT Date: 13 September 1982 2043-EDT (Monday) From: Richard H Gumpertz To: MsgGroup at BRL Subject: MSGGROUP#1898 RFC Message-Id: <13Sep82 204325 RG02@CMU-10A> Via: Cmu-10a; 13 Sep 82 22:49-EDT Via: Brl; 13 Sep 82 22:58-EDT Via: Brl-Bmd; 13 Sep 82 23:06-EDT It has been suggested that RFC now stands for "Requirements For Compliance". Rick 13-Sep-82 21:19:52-PDT,2576;000000000001 Mail-from: ARPANET site BRL rcvd at 13-Sep-82 2115-PDT Date: 13-Sep-82 19:40:55-PDT (Mon) From: UCBARPA.eric at Ucb-C70 Subject: MSGGROUP#1899 Re: Header Mangling. Message-Id: <8208140240.14786@UCBARPA.BERKELEY.ARPA> Received: by UCBARPA.BERKELEY.ARPA (3.198 [9/12/82]) id A14786; 13-Sep-82 19:40:57-PDT (Mon) Received: from UCBARPA.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.198 [9/12/82]) id A11317; 13-Sep-82 19:44:14-PDT (Mon) Phone: (415) 548-3211 To: header-people at Mit-Mc, msggroup at BRL Via: Ucb-C70; 13 Sep 82 22:52-EDT Via: Brl; 13 Sep 82 22:58-EDT Via: Brl-Bmd; 13 Sep 82 23:09-EDT It doesn't seem that "mysterious disappearing protocol" argument is about RFC 822, but about the rather silent modification of RFC 733. I agree that to change a standard silently and without notice can only be considered an extraordinary botch. I heard about it by word of mouth several years after the fact. In any case arguing about it seems like beating a dead horse. The people that caused this made a bad management error and presumably regret it. To reverse the decision now would probably break as many systems as it would fix. 822 however is published, and a conversion period has been specified. It isn't perfect, but sometimes it is necessary to just get something out. To imply that TCP has come out without "valid technical questions" or intense debate is simply naive. Many people feel it is being shoved down their throats. Long have I listened to the "discussions" of how "stupid" it is. I know a number of people who intend to do nothing because "DCA wouldn't DARE turn off NCP." Hah! (Or perhaps I should save my laughs for 1-Jan-83.) But in any case something had to happen to try to improve the previous situation. I don't normally participate in these discussions because I feel it is more important to move the UNIX world forward than argue that we should be allowed to stay the same. I find it ironic that people have claimed that 822 isn't a BIG enough step -- considering that a lot of the debaucheries in it were to make it easier for those of you who already have working mail systems. I accept that you all have valid points. Now, how about we move forward and stop cussing each other out? eric allman P.S. Before any of you start yelling at me about the bad headers Berkeley has been producing, let me say that I feel this is endemic to building new mail systems. Please be polite to me -- I intend to be polite to you when you undergo the painful effort of conversion. 16-Sep-82 09:28:20-PDT,723;000000000001 Mail-from: ARPANET site BRL rcvd at 16-Sep-82 0923-PDT Date: 16 Sep 1982 1113-EDT From: J Noel Chiappa Subject: MSGGROUP#1900 Re: Header Mangling. To: ron at BRL, msggroup at BRL, mmdf at BRL cc: JNC at Mit-Xx In-Reply-To: Your message of 13-Sep-82 1145-EDT Via: Mit-Xx; 16 Sep 82 11:16-EDT Via: Brl; 16 Sep 82 11:34-EDT Via: Brl-Bmd; 16 Sep 82 11:44-EDT Referrring to your assertion that 'I suppose TCP will be in by the deadline', you may very well not be correct. There are NO ITS system wizards working for MIT now to do TCP/IP. MIT has been investigating hiring one from SRI to do it, but time passes and I see no action. So maybe the whole argument will become moot. -------