20-Dec-83 19:46:01-PST,6906;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 31 Jan 84 02:20:23-PST Received: From Usc-Eclc.ARPA by BRL via smtp; 31 Jan 84 4:36 EST Date: 20 Dec 1983 17:00:07 PST Subject: MSGGROUP#2201 SURVEY #2151-#2200 from MSGGROUP.2101-2200.1 From: MsgGroup Moderator - Stefferud Reply-To: MsgGroup-Request@brl To: msggroup@eclc Remailed-date: 31 Jan 1984 0045-PST Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup: ; Some of you may have missed some of these messages for some reason. You can FTP the whole file from [ECLC]msggroup.2101-2200.1, using FTP with LOGIN ANONYMOUS with Password MSGGROUP. I will remail requested items, with some delay for processing, if you will request them by reply mail to MsgGroup-Request@BRL. Please cite items you want by their specific Msggroup#nnnn identifiers, as shown. ======== MSGGROUP#2151 SURVEY #2101-#2150 from MSGGROUP.2101-2200.1 7231 chars 27 August 1983 1200-PDT From: MsgGroup Moderator - Stefferud MSGGROUP#2152 Re: Errors returned under separate cover? 1548 chars 27 August 1983, 20:57-EDT (Saturday) From: Robert W. Kerns < MSGGROUP#2153 Re: Errors returned under separate cover? 3436 chars 28 Aug 1983 1657-PDT From: ESTEFFERUD@usc-ecl To: Schiller@m MSGGROUP#2154 Re: Errors returned under separate cover? 899 chars 28 Aug 1983 22:12-PDT From: BILLW@sri-kl To: ESTEFFERUD@usc- MSGGROUP#2155 Re: ISI-VAXA's SMTP sender doesn't say HELO 705 chars 29 Aug 83 02:50:58-PDT (Mon) From: Henry W. Miller MSGGROUP#2159 RFC 876-877 Now Available 1552 chars 9 Sep 1983 19:05:19 PDT From: POSTEL@USC-ISIF To: Request MSGGROUP#2160 [Jeffrey@OFFICE-6: IBM's DCA/DIA] 1203 chars 26 Sep 1983 0905-PDT From: MsgGroup Moderator T MSGGROUP#2172 Re: privacy of files 752 chars 17 Oct 83 15:54:23-CDT From: Clive Dawson To MSGGROUP#2176 MsgGroup vs Human-nets for "privacy of files" 1082 chars 18 Oct 1983 10:31-PDT From: ESTEFFERUD@usc-ecl To: MsgGroup@ MSGGROUP#2177 NLM-MCS 495 chars 18 Oct 83 19:07:28 EDT From: Ron Natalie To: MSGGROUP#2178 Re: NLM-MCS 741 chars 18 Oct 1983 16:20-PDT From: the tty of Geoffrey S. Goodfello MSGGROUP#2179 Re: NLM-MCS 1026 chars 18 Oct 83 18:00:51-PDT From: Mark Crispin To: MSGGROUP#2191 Re: nicknames 940 chars 1 Nov 83 22:54:38-PST From: David Roode To: MSGGROUP#2192 Re: nicknames 935 chars 2 Nov 83 08:43:52-PST From: Mark Crispin : Re: nicknames] 3083 chars 10 Nov 1983 0000-PST From: MsgGroup Moderator - Stefferud ] 872 chars 10 Nov 83 17:09:07 CST (Thu) From: Marvin Solomon To: Huma MSGGROUP#2198 forwarding errors 1772 chars 22 Nov 83 0601 EST From: Rudy.Nedved@cmu-cs-a To: MsgGroup@b MSGGROUP#2199 RFCs 886 & 887 Now Available 2333 chars 16 Dec 1983 17:44:27 PST From: WESTINE@USC-ISIF To: Reques MSGGROUP#2200 RFCs 884 and 885 Now Available 1708 chars 19 Dec 1983 17:59:37 PST From: WESTINE@USC-ISIF To: Reques 21-Dec-83 21:46:11-PST,1790;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Wed 21 Dec 83 21:44:33-PST Date: 21 Dec 1983 20:50:30 PST From: WESTINE@USC-ISIF Subject: MSGGROUP#2202 RFCs 889, 891 and 892 Now Available To: Request-for-Comments-List: New Requests for Comments are now available from the Network Information Center in the directory at SRI-NIC. RFC 889: Title: Internet Delay Experiments Author: D. Mills Pages : 12 pathname: RFC889.TXT This memo reports on some measurements of round-trip times in the Internet and suggests some possible improvements to the TCP retransmission timeout calculation. This memo is both a status report on the Internet and advice to TCP implementers. RFC 891: Title: DCN Local-Network Protocols Author: D. Mills Pages : 26 pathname: RFC891.TXT This RFC provides a description of the DCN protocols for maintaining connectivity, routing, and clock information in a local network. These procedures may be of interest to the designers and implementers of other local networks. RFC 892: Title: ISO Transport Protocol Specification Author: ISO Pages : 82 pathname: RFC892.TXT This document specifies the Transport Protocol developed by the ISO. It is presented in RFC form for the information of the ARPA Internet community. This is not an ARPA Internet standard. Public access files may be copied from the directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. 27-Dec-83 21:07:03-PST,1509;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Tue 27 Dec 83 21:03:28-PST Date: 27 Dec 1983 20:11:05 PST From: WESTINE@USC-ISIF Subject: MSGGROUP#2203 RFC 869 & 878 Now Available To: Request-for-Comments-List: New Requests for Comments are now available from the Network Information Center in the directory at SRI-NIC. RFC 869: Title: A Host Monitoring Protocol Author: R. Hinden Pages : 70 pathname: RFC869.TXT This RFC specifies the Host Monitoring Protocol used to collect information from various types of hosts in the Internet. Designers of Internet communications software are encouraged to consider this protocol as a means of monitoring the behavior of their creations. RFC 878: Title: The ARPANET 1822L Host Access Protocol Author: A. Malis Pages : 48 pathname: RFC878.TXT This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. The 1822L procedure allows ARPANET hosts to use logical identifiers as well as 1822 physical interface identifiers to address each other. Public access files may be copied from the directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon 13-Jan-84 16:09:58-PST,1062;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Fri 13 Jan 84 16:06:54-PST Date: 13 Jan 1984 15:11:36 PST From: WESTINE@USC-ISIF Subject: MSGGROUP#2204 RFC 888 Now Available To: Request-for-Comments-List: A new Request for Comments is now available from the Network Information Center in the directory at SRI-NIC. RFC 888: Title: Stub Exterior Gateway Protocol Author: L. Seamonson & E. Rosen Pages: 38 pathname: [SRI-NIC]RFC888.TXT This note defines the protocol that stub gateways use with core gateways to exchange routing information. This is an ARPA official protocol. All gateway designers and implementers should study this document carefully. Public access files may be copied from the directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. 17-Jan-84 08:41:54-PST,2213;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 17 Jan 84 08:38:06-PST Received: From Ucl-Cs.ARPA by BRL via smtp; 17 Jan 84 10:48 EST Via: mrxa.ac.uk; to 44d.Ucl-Cs.AC.UK over Sercnet with NIFTP; 17 Jan 84 15:41 GMT Date: 17 Jan 1984 10:21:04-GMT Subject: MSGGROUP#2205 Recommendations from a study of Electronic Mailbox Systems From: Hugh Smith To: MsgGroup [Paul Wilson asked me to forward this note to the group - HTS] Recommendations from a study of Electronic Mailbox Systems The British National Computing Centre (NCC) recently completed a study of Electronic Mailbox Systems. The studies recommendations are now being published to as wide an audience as possible in the belief that the issues raised are of crucial importance to the development and use of this communication medium. The recommendations suggest that organisations need to implement mailbox systems to remain competitive; advise that a mailbox structures research program be initiated; proposes demonstrator projects to test ECMA, CCITT and ISO mailbox-related standards; encourages suppliers to provide a structuring capability in their products; and calls for the development of a programming language designed specifically for mailbox applications. You can see the full text of these recommendations in the following message. This message has been distributed simultaneously today, the 17th January 1984, to a total of over 62,700 users in the following mailbox systems: Prestel MAILBOX; GEISCO's Quik-Com system; British Telecom NE internal system; Usenet; HP's internal HPDeskManager network; Texas Instruments Inc MSG system; ICL internal systems; Komex from GMD (West Germany); COM; Mailnet; Blend; Xerox Internet; STSC APL PLUS SIG Icebox;CSC NOTICE; JANET; ARPANET; NPL Scrapbook and EDIT systems; EIES at NJIT; NCC's Zynar network; COMET; Digital internal (ALL-IN-ONE); Zynar/Nestar network; I P Sharp Associates MAILBOX; Datapoint Electronic Mail Service; Internal Plessey system; Bell Northern Research COCOS. 17-Jan-84 09:06:54-PST,8485;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 17 Jan 84 09:05:27-PST Received: From Ucl-Cs.ARPA by BRL via smtp; 17 Jan 84 10:54 EST Via: mrxa.ac.uk; to 44d.Ucl-Cs.AC.UK over Sercnet with NIFTP; 17 Jan 84 15:45 GMT Date: 17 Jan 1984 10:21:34-GMT Subject: MSGGROUP#2206 Recommendations from a study of Electronic Mailbox Systems From: Hugh Smith To: MsgGroup [Paul Wilson asked me to forward this note to the group - HTS] ELECTRONIC MAILBOX SYSTEMS The British National Computing Centre (NCC) is an independant, non profit distributing, membership organisation which has the objective of promoting the more efficient and effective use of Information Technology. A recent NCC study investigated the design and management of Electronic Mailbox Systems. As a result of this work a number of requirements have been identified for the effective deployment of Mailbox Systems. These are reproduced immediately below in the form of a series of recommendations, and followed by some general background information. 1 The strategic application of Mailbox Systems will result in a significant improvement in the profitability and competitive ness of organisations - though the full impact will not become apparent until organisations have developed new cultures that take advantage of the new medium. Recommendation: Organisations should be encouraged to implement Mailbox Systems, and to implement them quickly. 2 Despite the importance of the concept of structuring to the effective deployment of mailbox systems, the current level of knowledge of this subject is very low. Most of the work in this area is currently being done at a few centres in the United States. This project has identified very little work of this nature being undertaken in the UK at the present time. Recommendation: A UK Mailbox Structuring Research Program should be initiated immediately. This should concentrate on applied research with the results being transferred rapidly to Industry and Commerce - preferably via a mailbox communication channel. 3 Mailbox Systems need to be written in flexible, high level, communication oriented, programming languages so that they can be easily written and modified at will. Existing languages do not possess such features and consequently they slow down the development of mailbox systems and, more damagingly, constrain the addition of new structures. Recommendation: Research should be done to establish what features are required of a high level, mailbox oriented, language. This should take the form of first establishing the many requirements that have already been recorded in the literature, and then building on those. Once a definitive set of requirements have been established an appropriate language for use in the UK and elsewhere should then be developed. 4 Very few of the Mailbox Systems currently on the market have any structuring facilities , nor the flexibility to allow new structures to be incorporated. Recommendation Suppliers should be encouraged to develop new products which provide structuring capabilities. Recommendation: The UK Government's Software Products Scheme should take this requirement into account when considering applications for funding the development of proposed Mailbox Systems. 5 The power of a communication system lies in the number of people that can be contacted through it. Consequently, the interconnection of mailbox systems is crucial to the develop ment of the medium and must, in turn, rely on the development and adoption of standards. At the International level bodies such as ECMA, CCITT and ISO are working on such standards and the UK is supporting these efforts. Within the UK itself a consortium led by the Department of Industry is working on Intercept standards with the intention of anticipating the international work and recommending standards which will stimulate the interconnection of mailbox and other message systems in the short term. Recommendation: Consideration should be given to the funding of Demonstrator Projects which utilise the Messaging Intercept Standards. Background_Information Mailbox Systems work by providing the individual with a personal mailbox through which messages can be prepared, sent, received and filed. Incoming messages are deposited and held in the mailbox until they are accessed at a time and place of the recipient's choosing. Mailbox systems can be used in informal, unstructured ways just as the telephone is today. This kind of use can benefit the individual by saving time, reducing inter ruptions and improving communications. However such benefits are intangible, difficult to measure and do not make a direct impact on an organisations profitability. Alternatively, mailbox communication can be structured so that specific tasks can be undertaken. Mailbox structuring is equivalent to the structuring that is imposed on certain types of face-to-face communication; for example, face-to-face meetings often have a Chairman, an agenda, fixed procedures for conducting the meeting and minutes are produced. However, whereas face-to- face structures must rely on the compliance of the individual and the memorising or recording of the communication that has taken place, mailbox structures can be easily controlled and no communication is lost or forgotten. Consequently Mailbox structures have far greater scope and constitute a powerful new form of communication. This study has identified 13 different types of applications for structured mailbox systems each of which can provide tangible benefits. These include; the control of branches, transaction processing, education and training, project control and communi cations between customers and suppliers. The application of mail box systems can improve the quality of work that is done, increase productivity, save people time and reduce communication costs and administrative overheads. However these benefits all relate to the limited use of a mailbox system over a short time period: The most significant benefits will only emerge when the system has been extended to all employees and a high degree of skill and familiarity with its use has been acquired. Organisations that have been through this process seem to develop a new working culture which takes advantage of the flexibility of the mailbox medium. They become less concerned with processes and more concerned with getting things done. Delegation is more common and people are more flexible and responsive. The system breaks down the demarcation lines within the hierarchy. Further details of the points made in this document are contained in the following NCC publications: 1 'Introducing the electronic mailbox', P A Wilson, 1984. 2 'Commercial electronic mailbox systems' P A Wilson, 1983. 3 'Standards and the electronic mailbox' P A Wilson, 1984. 4 'Using the electronic mailbox' P A Wilson, 1984. 5 'Mailbox Message Systems' P A Wilson, an exclusive report for subscribers to NCCs Office Technology Circle, 1984. 6 'Getting the message' An NCC video, 35 mins, U-matic VHS or Beta formats, 1983. 7 'Planning Office Automation: Electronic message systems' J A T Pritchard & P A Wilson, 1982. 8 'Electronic mail systems: A practical evaluation guide' W J Welch & P A Wilson, 1981. Should you wish to obtain further information, to comment on these recommendations or to contribute to any initiatives relating to them, please contact the following: Within the UK: John Perkins, Marketing Manager Outside the UK: John Edwards, NCC International At the following address: NCC Oxford Road Manchester M1 7ED Telex 668962 NCCMAN Paul Wilson Senior Consultant Office Systems Division 4th January 1984 25-Jan-84 07:38:56-PST,1648;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 25 Jan 84 07:34:00-PST Received: From Rutgers.ARPA by BRL via smtp; 25 Jan 84 9:37 EST Date: 25 Jan 84 09:35:27 EST From: Charles Hedrick Subject: MSGGROUP#2207 request for a service To: cic@CSNET-CIC.ARPA, msggroup@BRL.ARPA, tops-20@SU-SCORE.ARPA, nic@SRI-NIC.ARPA We have had several occasions recently where someone wanted to establish a research collaboration with a colleague, but we have been unable to find a route for computer mail. In one case this was for a University in Australia, which supposedly has a UUCP address, and in another case it was somebody on Bitnet. (Interestingly enough, in both cases we had claimed routes, but the mail disappeared in the bit bucket. We were unable to locate anyone who could help us in figuring out where it went.) There are a number of Universities that are not part of the Arpanet, CSnet, etc. but which those of us in the community would like to be able to reach. Does anyone know of either - a database listing as many universities as possible and how to get mail to them (all possible routes, for those that are on more than one net) - a mailing list for discussin delivery paths. This would include both changes in existing networks and forwarding services, and tips on finding obscure places. If possible the maintainer of the database should add information as it shows up on this mailing list. If these things do not exist, would anyone like to create them? This would seem a perfect job for NIC or CIC, if they are willing. ------- 25-Jan-84 19:53:06-PST,1044;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 25 Jan 84 19:49:50-PST Received: From Nosc-Cc.ARPA by BRL via smtp; 25 Jan 84 22:12 EST Received: by Nosc.ARPA (4.12/4.7) id AA15564; Wed, 25 Jan 84 19:12:34 pst Date: Wed, 25 Jan 84 19:12:08 pst From: bang!bam@nosc Message-Id: <8401260312.AA15564@Nosc.ARPA> To: msggroup@brl Subject: MSGGROUP#2208 Request for service (to Australia) There are several paths to Australia. Two that I know of are accessable via the uucp network: mhtsa!australia!basservax will get you to the University of Sydney, Basser Dept. of Computer Science. ...!decvax!mulga is the path to the "OZ" net via Melbourne University. Both paths are expensive to use. The first uses Telenet to Midas and the second is a direct connection made daily (I believe). Burdening either paths with large transmissions should be avoided. I'll be happy to assist anyone with addressing info to particular sites 'down under'. Bret Marquis bam@NOSC sdcsvax!bang!bam 27-Jan-84 00:06:29-PST,1900;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 27 Jan 84 00:04:39-PST Received: From Usc-Ecl.ARPA by BRL via smtp; 27 Jan 84 2:34 EST Return-path: Received: from BRL by USC-ECL; Wed 25 Jan 84 08:54:36-PST Received: From Rochester.ARPA by BRL via smtp; 25 Jan 84 11:48 EST Received: by sen.rochester (3.327.3N) id AA24037; 25 Jan 84 11:48:49 EST (Wed) Received: by cay.Rochester (3.327.3N+) id AA03475; 25 Jan 84 11:45:13 EST (Wed) Message-Id: <84/01/25 1134.700@Filter-Queen> Date: 25 Jan 1984 11:34-EST From: Lee.Moore@Rochester.ARPA Subject: MSGGROUP#2209 Re: request for a service To: msggroup-request@BRL.ARPA In-Reply-To: msggroup-request's message of 25 Jan 84 093527 EST Origin: Filter-Queen Redistributed-To: msggroup@brl Redistributed-By: ESTEFFERUD@usc-ecl Redistributed-Date: 26 Jan 1984 On uucp: We get a database in the mail every two weeks on who is connected to who in the UUCP world. There is a program that will find paths using this database. I have pretty good success this way. Unfortately, this database is only machine names. For sites that are also subscribers to Usenet, there are monthly directories that contain machines and institution names. I could mail you a sample set, if you like. UUCP mailers vary dramaticly in quality. Many just dump mail into the bit-bucket on any error. On bitnet: Bitnet is a much better situation. All machines know how to route mail so you don't have to know paths. Since it uses leased lines, transportation is almost as good as the Arpanet. When I want to send to bitnet, I just mail through Berkeley. Unfortuately, mailing back doesn't (seem) to work. I guess Berkeley doesn't want to forward from bitnet to arpanet. Columbia used to do this but they have become so flakey as to be useless. =lee 27-Jan-84 23:03:41-PST,1043;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 27 Jan 84 22:59:19-PST Received: From Ucb-Vax.ARPA by BRL via smtp; 28 Jan 84 1:39 EST Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.19) id AA20000; Fri, 27 Jan 84 09:51:38 pst Received: from UCBCMSA.BITnet by ucbjade.CC.Berkeley.ARPA (4.13/4.11) id AA08708; Fri, 27 Jan 84 09:42:05 pst Message-Id: <8401271742.AA08708@ucbjade.CC.Berkeley.ARPA> Date: 27 Jan 84 09:34:39 PST Fri From: SPGGGM%UCBCMSA.CC@berkeley Cc: msggroup@brl.ARPA Subject: MSGGROUP#2210 bitnet to arpanet Hi, The reason mail from bitnet to arpanet doesn't work is that the internal mail delivery mechanism for bitnet to bitnet mail is so simple that essentially no code has been needed to be written. To get to arpanet (or UUCP, or csnet, or whatever) however, some code must be written. Various people are working on this code within bitnet; some sites are even now able to send from bitnet to arpanet through Berkeley. Greg Minshall 27-Jan-84 19:33:28-PST,1229;000000000001 Return-path: <@MIT-MC:EE.GDS@mit-oz> Received: from BRL by USC-ECLC; Fri 27 Jan 84 19:32:20-PST Received: From Mit-Mc.ARPA by BRL via smtp; 27 Jan 84 22:22 EST Date: 27 Jan 84 22:20:06 EST Fri From: Greg Skinner Subject: MSGGROUP#2211 Re: request for a service To: Lee.Moore@ROCHESTER.ARPA cc: msggroup-request@BRL.ARPA In-Reply-To: Message from "Lee.Moore@Rochester" of Wed 25 Jan 84 11:34:00-EST I've seen some addreses com back from bitnet sites via Berkeley, like this one (g.bostonu=csc126@Berkeley). You might try "some csnet-arpanet address spec"@psuvax1 if you're on Bitnet. for example, if I wanted to send mail from psuvax1 to my account on xx, I think "gds%mit-xx".csnet-relay@psuvax1 would work. Of course this depends on what csnet-relay is called in the CSnet domain, but I think the syntax is correct. A friend has told me that only certain people are allowed to use ibm-sj as a route out of IBM's internal network, so that would probably lose for someone sending from Bitnet to VNET to CSnet, etc. I tried contacting a friend who works for IBM Endicott but haven't heard a reply or a failed-mail message, so I'm still hoping. --greg ------- 13-Feb-84 15:01:11-PST,744;000000000001 Return-Path: Received: from BRL by USC-ECLC; Mon 13 Feb 84 15:00:57-PST Received: From Mit-Mc.ARPA by BRL via smtp; 13 Feb 84 17:03 EST Date: 13 Feb 1984 16:52 EST (Mon) Message-ID: From: David Siegel Subject: MSGGROUP#2212 random messages To: msggroup@BRL.ARPA Cc: rookies%MIT-OZ@MIT-MC.ARPA For some reason, every now and then I get messages from people wanting to be added or deleted from this mailing list. I never receive any discussion mail or digests, only addition and deletion requests. To tell you the truth, I don't even know what this mailing list is about! Maybe someone might have some idea as to what is going on here. Thanks! 14-Feb-84 00:01:47-PST,1551;000000000001 Return-Path: Received: from BRL by USC-ECLC; Mon 13 Feb 84 23:59:32-PST Received: From Usc-Eclc.ARPA by BRL via smtp; 14 Feb 84 2:31 EST Date: 13 Feb 1984 2328-PST From: MsgGroup Moderator - Stefferud Subject: MSGGROUP#2213 Re: random messages To: DMS%MIT-OZ@MIT-MC.ARPA, msggroup@BRL.ARPA cc: rookies%MIT-OZ@MIT-MC.ARPA In-Reply-To: Your message of 13-Feb-84 1652-PST It is not entirely clear from your message, just which list it is that you are concerned about. So I checked my Msggroup-request archives. Your memory seems not to be serving you well. Here is your request to be added, as I found it in my request archives, properly addressed to msggroup-request, rather than to msggroup, as you have now lapsed. I can appreciate that substantive traffic has not been flowing, and that there seem to be too many people out there who do not know about, or forget about the *-request convention for administrative mail, so we should forgive you for this transgression. Perhaps this episode will help you to remember. None the less, I will remove you from the list on the next update. Best regards - Stef Return-path: <@MIT-MC:DMS@mit-oz> Received: from BRL by USC-ECLC; Sun 2 Oct 83 09:34:27-PDT Received: From Mit-Mc.ARPA by BRL via smtp; 2 Oct 83 12:30 EDT Date: Sun 2 Oct 83 12:31:12-EDT From: David M. Siegel Subject: Please add my name to this mailing list To: msggroup-request@mit-oz cc: dms@mit-oz Thanks ------- ------- 25-Feb-84 19:47:46-PST,1309;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Sat 25 Feb 84 19:47:25-PST Date: 25 Feb 1984 19:00:34 PST From: WESTINE@USC-ISIF Subject: MSGGROUP#2214 RFC 890 Now Available To: Request-for-Comments-List: A new Request for Comments is now available from the Network Information Center in the directory at SRI-NIC. RFC 890: Title: Exterior Gateway Protocol Implementation Schedule Author: J. Postel Pages: 3 pathname: [SRI-NIC]RFC890.TXT This memo is a policy statement on the implementation of the Exterior Gateway Protocol in the Internet. This is an official policy statement of ICCB and DARPA. After 1-Aug-84 there shall be no dumb gateways in the Internet. Every gateway must be a member of some autonomous system. Some gateway of each autonomous system must exchange routing information with some gateway of the core autonomous system using the Exterior Gateway Protocol. Public access files may be copied from the directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. 25-Feb-84 22:43:23-PST,1128;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Sat 25 Feb 84 22:43:00-PST Date: 25 Feb 1984 21:41:13 PST From: POSTEL@USC-ISIF Subject: MSGGROUP#2215 RFC 896 Now Available To: Request-for-Comments-List: A new Request for Comments is now available from the Network Information Center in the directory at SRI-NIC. RFC 896: Title: Congestion Control in IP/TCP Internetworks Author: J. Nagel Pages: 9 pathname: [SRI-NIC]RFC896.TXT This memo discusses some aspects of congestion control in IP/TCP Internetworks. It is intended to stimulate thought and further discussion of this topic. While some specific suggestions are made for improved congestion control implementation, this memo does not specify any standards. Public access files may be copied from the directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. 28-Feb-84 20:56:52-PST,852;000000000001 Return-Path: Received: from BRL by USC-ECLC; Tue 28 Feb 84 20:54:43-PST Received: From Cit-Vax.ARPA by BRL via smtp; 28 Feb 84 23:16 EST Received: by cit-vax.ARPA id AA01100 at Tue, 28 Feb 84 20:04:20 pst Date: 28 Feb 84 20:04:20 pst Tues From: Don Speck Message-Id: <8402290404.AA01100@cit-vax.ARPA> To: MsgGroup@brl Subject: MSGGROUP#2216 electronic-mail "telephone directory" Is there any kind of electronic-mail address directory -- someplace where I can look up the electronic address of people that I'd like to send electronic mail to? I'm hoping for the electronic-mail equivalent of a telephone directory (indexed by name and university?), though I realize that is probably hopelessly naive. -Don- P.S. I am not on the list, so please send replies to me (speck@cit-vax). 28-Feb-84 22:14:52-PST,941;000000000001 Return-Path: Received: from BRL by USC-ECLC; Tue 28 Feb 84 22:12:59-PST Received: From Purdue-Merlin.ARPA by BRL via smtp; 29 Feb 84 0:43 EST From: Christopher A Kent Message-Id: <8402290543.AA06532@merlin.ARPA> Received: by merlin.ARPA; Wed, 29 Feb 84 00:43:40 est Date: 29 Feb 1984 0043-EST (Wednesday) To: Don Speck Cc: MsgGroup@brl.ARPA Subject: MSGGROUP#2217 Re: electronic-mail "telephone directory" In-Reply-To: Your message of Tue, 28 Feb 84 20:04:20 pst. <8402290404.AA01100@cit-vax.ARPA> If you're a CSNET member, you can access the CSNET "nameserver", which is just such a white pages, of CSNET members. There are even hacks to go into delivermail and sendmail (I think the 4.2 version is done now) and let you put nameserver queries into your outgoing headers. Contact CIC@CSNET-CIC for full details. Cheers, chris ---------- 29-Feb-84 00:58:25-PST,1162;000000000001 Return-Path: Received: from BRL by USC-ECLC; Wed 29 Feb 84 00:58:18-PST Received: From Office-3.ARPA by BRL via smtp; 29 Feb 84 3:28 EST Date: 29-Feb-84 00:26 PST From: Rich Zellich Subject: MSGGROUP#2218 Re: electronic-mail "telephone directory" To: Don Speck Cc: MsgGroup@brl Message-ID: <[OFFICE-3]GVT-RICH-476C0> In-reply-to: <8402290404.AA01100@cit-vax.ARPA> There is also, of long standing, the ARPANET Network Information Center Query system. You can connect to the SRI-NIC host (0/73 or 10.0.0.73) and give the login/command NICQUERY. That will drop you into an interactive program tht lets you ask about ANY resource on the ARPANET/MilNet - users, hosts, TACs, software, etc. There is also the NIC-provided WHOIS program, that interacts across a network connection with the NIC's user data base. A copy of WHOIS is available free from the NIC for at least Tenex, TOPS-20, and Unix systems. For more information, try a copy of the ARPANET Resource Handbook or ARPANET Directory, if you can find one of them locally, or send netmail to NIC@SRI-NIC. -Rich 29-Feb-84 01:28:49-PST,1124;000000000001 Return-Path: Received: from BRL by USC-ECLC; Wed 29 Feb 84 01:28:24-PST Received: From Sri-Nic.ARPA by BRL via smtp; 29 Feb 84 3:35 EST Date: 29 Feb 84 00:36:23-PST Wed From: David Roode Subject: MSGGROUP#2219 Re: electronic-mail "telephone directory" To: speck@cit-vax, MsgGroup@brl In-Reply-To: Message from "Don Speck " of Tue 28 Feb 84 23:35:17-PST Location: EJ286 Phone: (415) 859-2774 You can access the NIC database of MILNET and ARPANET users via a TCP connection to port 43 decimal on SRI-NIC as described in RFC812. Various types of search qualifications are available including mailbox name across all sites and specific mailbox as well as site name. We are interested in specific suggestions for improvements to this server. If you do not have a capability to access this server from your site, you can telnet to SRI-NIC and use the command "WHOIS" which is available without need for login. A help message for this program is available as HLP:WHOIS.HLP from SRI-NIC (via FTP under the ANONYMOUS login convention). ------- 29-Feb-84 02:34:14-PST,455;000000000001 Return-Path: Received: from BRL by USC-ECLC; Wed 29 Feb 84 02:30:02-PST Received: From Brl-Bmd.ARPA by BRL via smtp; 29 Feb 84 5:04 EST Date: 29 Feb 84 4:55:15 EST Wed From: Stephen Wolff To: speck@cit-vax cc: MsgGroup@brl Subject: MSGGROUP#2220 Re: electronic-mail "telephone directory" And rfc812 or more generally rfcnnn is available via ANONYMOUS FTP of the file rfcnnn.txt at SRI-NIC. 29-Feb-84 02:49:17-PST,1514;000000000001 Return-Path: Received: from BRL by USC-ECLC; Wed 29 Feb 84 02:45:44-PST Received: From Dca-Eur.ARPA by BRL via smtp; 29 Feb 84 5:08 EST Date: 29 February 1984 10:05 GMT From: Turkewitz@dca-eur Subject: MSGGROUP#2221 Re: electronic-mail "telephone directory" To: MSGGroup@brl Date: 29 Feb 1984 09:58:14 Z Comment: Forwarded message(s): ----------------------------------------------------- Date: 29 Feb 1984 8:44:34 GMT (Wednesday) From: daemon @ dca-eur Subject: Undeliverable mail To: Turkewitz @ dca-eur Text: Mail addressed to MSG-Group at brl could not be sent. 550 (USER) Unknown user name in "MSG-Group@brl" ------- Unsent message is below ------- Date: 29 February 1984 08:41 GMT From: Turkewitz @ dca-eur To: speck @ cit-vax CC: Turkewitz @ dca-eur, MSG-Group @ BRL Re: electronic-mail "telephone directory" Date: 29 Feb 1984 08:28:27 Z Text: Don, The NIC (Network Operations Center at SRI in Menlo Park) keeps such a directory for the Defense Data Network (DDN). It is accessed via the "nicname" protocol (RFC 812). The nicname server runs on the SRI-NIC machine. You will need the nicname user program (if you don't already have it on your machine), which in many cases can be obtained from the NIC. You then type "nicname name" to access the directory. There are other options to. Send a message to NIC @ SIR-NIC for further information. --Ken -------------END OF FORWARDED MESSAGE(S)------------- 1-Mar-84 23:27:43-PST,1455;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Thu 1 Mar 84 23:24:57-PST Date: 1 Mar 1984 22:25:54 PST From: POSTEL@USC-ISIF Subject: MSGGROUP#2222 RFC 897 Now Available To: Request-for-Comments-List: A new Request for Comments is now available from the Network Information Center in the directory at SRI-NIC. RFC 897: Title: Domain Name System Implementation Schedule Author: J. Postel Pages: 8 pathname: [SRI-NIC]RFC897.TXT This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet. This memo is a partial update of RFC 881. The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System. The names of hosts will be changed to domain style names. Hosts will begin to use domain style names on 14-Mar-84, and the use of old style names will be completely phased out before 2-May-84. This applies to both the ARPA research hosts and the DDN operational hosts. This is an official policy statement of the ICCB and the DARPA. Public access files may be copied from the directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. 2-Mar-84 13:37:58-PST,662;000000000001 Return-Path: Received: from BRL by USC-ECLC; Fri 2 Mar 84 13:36:22-PST Received: From Cit-Vax.ARPA by BRL via smtp; 2 Mar 84 15:38 EST Received: by cit-vax.ARPA id AA14925 at Fri, 2 Mar 84 12:31:06 pst Date: 2 Mar 84 12:31:06 pst Fri From: Don Speck Message-Id: <8403022031.AA14925@cit-vax.ARPA> To: MsgGroup@brl Subject: MSGGROUP#2223 Re: electronic mail "telephone directory" The response to my query has been astounding (at least to me). If people are interested, I can try to summarize for the list when I get some time, maybe next week (although final exams are near). Thanks! -Don- 5-Mar-84 02:43:19-PST,4101;000000000001 Return-Path: Received: from BRL by USC-ECLC; Mon 5 Mar 84 02:39:32-PST Received: From Ucl-Cs.ARPA by BRL via smtp; 5 Mar 84 5:16 EST Date: 5 Mar 84 10:13:30 GMT From: Hsmith@ucl-cs.arpa To: msggroup@brl.arpa, header-people@mit-mc.arpa Subject: MSGGROUP#2224 CBMS 84 International Federation for Information Processing IFIP WG 6.5 International Working Conference on COMPUTER-BASED MESSAGE SERVICES Nottingham, UK 1-4th May 1984 Final Announcement Conference Sessions include: Message Architecture & Multimedia Systems Naming/Addressing and Directory Services User Interface Architecture Services and Cost/Benefit Issues Regulatory and Security Considerations Conference and Message System Interconnection Message Server Implementations Teletex Systems Panel I - International CBMS Standards Activities:Overview Panel II - International CBMS Standards Activities: The Commercial View Panel III - Intermediate Term Interconnection Strategies Working Group Sessions The objective of this conference is to promote the interchange of information and discussion about national and international computer-based message services. Because many service and inter- connection requirements remain to be established for these emerg- ing systems, the conference includes a number of working ses- sions. Issues to be discussed in the working sessions include both technical and economic/political aspects of message ser- vices. The conference brings together 27 speakers from eight countries to present papers on computer-based messaging systems and ser- vices. There are no parallel paper sessions in order to allow delegates to attend all presentations. In addition to the papers, three panels serve to review progress and issues in; standards activity, commercial developments, and intermediate term interconnection requirements. The final day and a half is devoted to working sessions which will develop the issues raised by the panels and address a number of application topics. The application topics will include multimedia systems, directory service standards, conferencing system requirements, user environment services, and facilities for impaired communities. Venue The conference will be held in the Albany Hotel situated in the centre of Nottingham, UK. The City is approximately two hours by train from London. Air Travellers arriving at Heathrow or Gatwick may also reach the city via a shuttle flight to East Midlands Airport. The City is some twenty minutes taxi ride from the airport. Further information will be sent with registration details. Registration The Conference registration fee is #90 (90 pounds UK sterling). This includes a copy of the proceedings, a conference dinner on May 2nd, and refreshments during the sessions. Address for Further Details: CBMS '84 Human Computer Interaction Group Nottingham University Nottingham NG7 2RD England Arpa: hsmith@ucl-cs.isid Telephone: (+44) 602 506101 Ext: 3587 Telex: 37346 UNINOT G Programme Committee G. Antoni, Italy J. Palme, Sweden A. Danthine, Belgium S. Ramani, India P. Kirstein, UK P. Schicker, Switzerland J. Garcia-Luna, USA K. Smaaland, Norway R. Miller, USA L. Tarouco, Brazil N. Naffah, France J. White, USA G. Neufeld, Canada K. Wimmer, German Federal Republic Organising Committee H.T. Smith, Nottingham University, UK W. Dzida, GMD Bonn, German Federal Republic R. Uhlig, Bell Northern Research, Canada 22-Mar-84 23:05:18-PST,3070;000000000001 Return-Path: Received: from BRL by USC-ECLC; Thu 22 Mar 84 23:01:16-PST Received: From Cit-Vax.ARPA by BRL via smtp; 23 Mar 84 1:34 EST Received: by cit-vax.ARPA id AA04970 at Thu, 22 Mar 84 22:27:11 pst Date: 22 Mar 84 22:27:11 pst Thu From: Don Speck Message-Id: <8403230627.AA04970@cit-vax.ARPA> To: MsgGroup@Brl.ARPA Subject: MSGGROUP#2225 electronic mail "telephone directory" Cc: JLarson.PA@Parc-Maxc.ARPA, SSchwartz.Network@Mit-Multics.ARPA, daul@Office-2.ARPA, jmchugh@Usc-Ecl.ARPA, kelley@Office-2.ARPA, muslin@Dec-Marlboro.ARPA, rem@Mit-Mc.ARPA, steve@Ucl-Cs.ARPA Here is the summary of responses on electronic-mail "white-pages" directories that I promised. I've tried the CSNET and ARPAnet stuff, and they seemed to work OK for me. CSNET: info courtesy milazzo@cmu-cs-g Telnet to CSNET-SH and login as "ns" (no password) to run the CSNET Name Server. Contact CIC@CSNET-CIC for details. "help" will list interesting commands. "whois user" will display NameServer entry of "user". "site list" will list all of the CSNet member sites. "quit" will get you out of ns. ARPAnet, MILnet, DDN: info courtesy zellich@office-3,roode@sri-nic, turkewitz@dca-eur,steve@brl-bmd Read the ARPAnet Directory, ARPAnet Resource Handbook publications Telnet to SRI-NIC and type NIC; this runs NIC-Query, an interactive program to search the NIC database. [Reminiscent of ITS info]. Telnet to SRI-NIC and type WHOIS, which looks up people in the NIC database. [A lot like finger]. WHOIS can also be run on your own machine; versions for Tenex, TOPS-20, and Unix are available from NIC@SRI-NIC. The "nicname" program works similarly, and is also available from NIC@SRI-NIC. See RFC812, which you get by FTP'ing RFC812.TXT from SRI-NIC with ANONYMOUS login. Usenet: info courtesy sun!idi!kiessig@Berkeley Rick Kiessig is publishing a directory, due in May. If you send him your U.S. mail address, he'll send you information when it's ready. MAILNET: info courtesy Willut%educom.mailnet@mit-multics Send mail to POSTMASTER%site.MAILNET@MIT-MULTICS for the site of interest. Mailnet sites include: Carnegie-Mellon University CARNEGIE.MAILNET University of Chicago UCHICAGO.MAILNET Dickinson College DICKINSON.MAILNET University of Durham (U.K.) DURHAM.MAILNET EDUCOM EDUCOM.MAILNET Grinnell College GRINNELL.MAILNET Iowa State University IOWA-STATE.MAILNET Massachusetts Institute of Technology MIT-MULTICS.ARPA University of Michigan UMICH-MTS.MAILNET New Jersey Institute of of Technology NJIT-EIES.MAILNET University of Newcastle-upon-Tyne (U.K.) NEWCASTLE.MAILNET Northwestern University NORTHWESTERN.MAILNET Stanford University STANFORD.MAILNET Stockholm University QZ Computing Center QZCOM.MAILNET Rensselaer Polytechnic Institute RPI-MTS.MAILNET 29-Mar-84 18:01:57-PST,1209;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Thu 29 Mar 84 17:59:38-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 29 Mar 84 20:35 EST Received: From brl-aos.arpa.ARPA by BRL-AOS via smtp; 27 Mar 84 4:08 EST Received: From rand-unix.arpa.ARPA by BRL-AOS via smtp; 27 Mar 84 2:29 EST From: vortex!lauren@Rand-Unix.ARPA Date: 23-Mar-84 15:05:30 PST Fri Sender: Lauren Weinstein Subject: MSGGROUP#2226 "Usenet" directory Message-ID: <8403231505.4839.1.VT2.2@vortex.UUCP> To: speck@Cit-Vax.ARPA CC: msggroup@Brl.ARPA Two points here. First of all, we are really talking about a UUCP users directory, not a Usenet directory. The "Usenet" is a subset of the systems that communicate via UUCP (defined by their transferring "netnews" newsgroups). Secondly, Rick's effort, as far as I know, is commercial and will almost certainly not be fully inclusive, since a variety of persons have expressed unwillingness to provide data for a commercial enterprise. However, a more general, publicly available, and free service to provide directory services at some level is in the works in other quarters. --Lauren-- 30-Mar-84 08:30:50-PST,1008;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Fri 30 Mar 84 08:29:24-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 30 Mar 84 10:39 EST Received: From purdue-merlin.arpa.ARPA by BRL-AOS via smtp; 30 Mar 84 10:35 EST From: Larry Peterson Message-Id: <8403301532.AA25365@merlin.ARPA> Received: by merlin.ARPA; Fri, 30 Mar 84 10:32:26 est Date: 30 Mar 1984 1032-EST (Friday) To: msggroup@BRL.ARPA Cc: fox%vpi@CSNet-Relay.ARPA, sollins@mit-xx.ARPA, almes@washington.ARPA Subject: MSGGROUP#2227 user interfaces I am working on a survey of user interfaces and need some help tracking down interfaces that maintain a chain of replies for the user. That is, does any one know of an user interface that will do the following for me: if I am reading a message that is a reply to another messages, I can ask for the original message. I know the edmas mailer at Washington does this, but are there any others? Cheers, Larry Peterson 30-Mar-84 16:54:34-PST,950;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Fri 30 Mar 84 16:50:44-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 30 Mar 84 19:21 EST Received: From dec-marlboro.arpa.ARPA by BRL-AOS via smtp; 30 Mar 84 19:15 EST Date: 30 Mar 1984 1911-EST From: Larry Campbell To: Larry Peterson , msggroup@Brl-Aos.ARPA cc: fox%vpi@Csnet-Relay.ARPA, sollins@Mit-Xx.ARPA, almes@Washington.ARPA Subject: MSGGROUP#2228 Re: user interfaces Message-ID: <"MS11(2364)+GLXLIB1(1056)" 12003575922.24.71.64536 at DEC-MARLBORO> References: Message from Larry Peterson of 30-Mar-84 1644-EST In-reply-to: <8403301532.AA25365@merlin.ARPA> Version 11 of MS (also known as DECmail/MS), which isn't yet released, does this. Of course it relies on the replier's mail system to propagate the message-ID of the original message. -------- 30-Mar-84 20:35:49-PST,1180;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Fri 30 Mar 84 20:34:16-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 30 Mar 84 23:07 EST Received: From office-2.arpa.ARPA by BRL-AOS via smtp; 30 Mar 84 23:05 EST Date: 30-Mar-84 20:01 PST From: DLS.TYM@OFFICE-2.ARPA Subject: MSGGROUP#2229 Re: user interfaces To: Larry Peterson Cc: msggroup@BRL.ARPA, fox%vpi@CSNet-Relay.ARPA Cc: sollins@mit-xx.ARPA, almes@washington.ARPA Message-ID: <[OFFICE-2.ARPA]TYM-DLS-4E4T2> In-reply-to: <8403301532.AA25365@merlin.ARPA> Augment Mail does this by automatically chaining together identifiers as an item is Sent, Answered, Answered back, ... The chain of mail identifiers is placed in the In-reply-to: field. In the case of mail arriving from outside our system, it keeps both the Augment identifier and any outside identifier it can find. The mail identifiers are also 'names' that the user can directly address, so it's quite easy to jump through a sequence of messages by using the Jump (to) Name command and just pointing to an identifier. Duane Stone Tymshare / McDonnell Douglas 30-Mar-84 22:45:04-PST,1237;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Fri 30 Mar 84 22:44:28-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 31 Mar 84 1:20 EST Received: From usc-ecl.arpa.ARPA by BRL-AOS via smtp; 31 Mar 84 1:16 EST Date: 30 Mar 1984 22:10-PST Sender: ESTEFFERUD@Usc-Ecl.ARPA Subject: MSGGROUP#2230 Re: user interfaces From: ESTEFFERUD@Usc-Ecl.ARPA To: DLS.TYM@Office-2.ARPA Cc: llp@Purdue.ARPA, msggroup@Brl-Aos.ARPA, fox%vpi@Csnet-Relay.ARPA Cc: sollins@Mit-Xx.ARPA, almes@Washington.ARPA Message-ID: <[USC-ECL]30-Mar-84 22:10:30.ESTEFFERUD> In-Reply-To: <[OFFICE-2.ARPA]TYM-DLS-4E4T2> Hi Duane --- What you say is very nice for your Augment users, but it depends on your non-Augment correspondents returning your original MESSAGE-ID in the IN-REPLY-TO field. However, I note from other mail replies received from other Augment users, that Augment does not match this courtesy of returning my orignal MESSAGE-ID in the IN-REPLY-TO field so I can do the same kind of tracking on my end. What Augement sends out is the internal Augement replacement ID. Just for grins, I suggest that you reply to this message to let us all see how Augment handles it. Cheers - Stef 2-Apr-84 10:11:42-PST,2185;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 2 Apr 84 10:10:50-PST Received: From mit-multics.arpa.ARPA by BRL-MIS via smtp; 2 Apr 84 9:08 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2627058091452342@MIT-MULTICS.ARPA>; 31 Mar 1984 13:21:31 est Date: 31 Mar 84 13:43 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL%QZCOM.MAILNET@MIT-MULTICS.ARPA, msggroup@BRL.ARPA, "Larry Peterson" cc: fox@vpi, sollins@MIT-XX.ARPA, almes@WASHINGTON.ARPA Subject: MSGGROUP#2231 user interfaces Message-ID: <49922@QZCOM> In-Reply-To: <8403301532.AA25365@merlin.ARPA> the COM and PortaCOM computer mail and conference systems have the following commands for tracing chains of commenting messages: (1) Reading all messages on which a certain message comments (2) Reading all messages, which comment on a certain message (3) In PortaCOM: Same as (1) and (2) but recursively finding comments on comments etc. In COM: Sequentially traversing all messages in the "subconference" created by a set of messages interrelated by comment links, either beginning with the oldest or beginning with the newest. Thus, all messages interrelated by comment links will form a kind of implicit "subconference". Such a subconference can traverse conferende boundaries, that is, a comment can belong to a wholly or partly different set of conferences or mailboxes than the commented entry. Our experience is that this facility is VERY useful and VERY much used by the COM users. Of course, the facility is more useful if old messages are kept in the data base, which COM/PortaCOM does for a certain time period, e.g. 4 months. And keeping old messages in the data base is possible only if the system, like COM/PortaCOM, only stores one copy of a message even if it has many receivers, otherwise the data base would be flooded with too much text items. 2-Apr-84 07:42:49-PST,1417;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 2 Apr 84 07:42:40-PST Received: From mit-multics.arpa.ARPA by BRL-MIS via smtp; 2 Apr 84 9:09 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2627058451325301@MIT-MULTICS.ARPA>; 31 Mar 1984 13:27:31 est Date: 31 Mar 84 13:47 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL%QZCOM.MAILNET@MIT-MULTICS.ARPA, msggroup@BRL.ARPA, "Larry Peterson" cc: fox@vpi, sollins@MIT-XX.ARPA, almes@WASHINGTON.ARPA Subject: MSGGROUP#2232 user interfaces Message-ID: <49923@QZCOM> In-Reply-To: <49922@QZCOM> Of course, this facility will be more useful if all mail systems on the networks did create (a) Message-id fields, (b) In-reply-to fields referring to the message-id of the original message. COM does this, but many systems do not. I would very much urge all mail system designers to do this. Even if you cannot produce in-reply-to fields, at least message-id-fields are very easy to produce (for example by munging the current date and time if you have no other way of doing it) and even if you only produce message-id-fields and not in-reply-to-fields, this is still valuable. 2-Apr-84 10:30:01-PST,925;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 2 Apr 84 10:28:53-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 2 Apr 84 9:29 EST Received: From usc-ecl.arpa.ARPA by BRL-AOS via smtp; 2 Apr 84 9:10 EST Date: 31 Mar 1984 08:54-PST Sender: ESTEFFERUD@Usc-Ecl.ARPA Subject: MSGGROUP#2233 Re: user interfaces From: ESTEFFERUD@Usc-Ecl.ARPA To: WBD.TYM@Office-2.ARPA Cc: DLS.TYM@Office-2.ARPA, llp@Purdue.ARPA, msggroup@Brl-Aos.ARPA Cc: fox%vpi@Csnet-Relay.ARPA, sollins@Mit-Xx.ARPA Cc: almes@Washington.ARPA Message-ID: <[USC-ECL]31-Mar-84 08:54:43.ESTEFFERUD> In-Reply-To: <[OFFICE-2.ARPA]TYM-WBD-4E5AM> Thanks - I am delighted to see my original ID come back. Has this been changed recently? I have some other mail from Augment Mail that did it differnetly. I will privately send you a copy, without bothering MsgGroup with further details. Cheers - Stef 2-Apr-84 10:59:14-PST,766;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 2 Apr 84 10:57:15-PST Received: From nrl-css.arpa.ARPA by BRL-MIS via smtp; 2 Apr 84 9:47 EST From: Mark Weiser Date: 1 Apr 84 22:47:51 EST To: msggroup@Brl-Mis.ARPA Subject: MSGGROUP#2234 user interfaces The 'notes' system for handling uucp mail has mesage chaining. So does the 'vnews' system a little bit, also for uucp mail. Notes uses both message id's and subject lines within net newsgroups to try to keep all messages about the same topic together under a single 'notesfile' heading. One can easily ask for the parent message that started the whole discussion, or any member of the chain. vnews only remembers the immediate parent. 2-Apr-84 10:24:25-PST,1887;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 2 Apr 84 10:21:52-PST Received: From usc-ecl.arpa.ARPA by BRL-MIS via smtp; 2 Apr 84 9:10 EST Date: 1 Apr 1984 23:31-PST Sender: ESTEFFERUD@Usc-Ecl.ARPA Subject: MSGGROUP#2235 Re: user interfaces From: ESTEFFERUD@Usc-Ecl.ARPA To: WWB.TYM@Office-2.ARPA Cc: DLS.TYM@Office-2.ARPA, llp@Purdue.ARPA, msggroup@Brl-Mis.ARPA Cc: fox%vpi@Csnet-Relay.ARPA, sollins@Mit-Xx.ARPA Cc: almes@Washington.ARPA Message-ID: <[USC-ECL] 1-Apr-84 23:31:08.ESTEFFERUD> In-Reply-To: <[OFFICE-2.ARPA]TYM-WWB-4E9GO> One primary problem that we (TYM folk and I) have just now uncovered is that while Augment is indeed returning my original ID, and appending its own internal ID (which is OK by me), it is placing one part of this two part construction on a continuation line without the required blank space at the beginning of the continuation line, so my various User Agents cannot see it. I assume this is a real bug which will be promptly corrected now that it has been found to exist. Your header fields with an example of the bug are included at the end of this message. Except for this new found bug, all that you say is correct and true. I think that you thus should be accorded the last word on this topic in this forum. Thanks much for the clarification ---- Stef Return-Path: Received: from OFFICE-2 by USC-ECL; Sun 1 Apr 84 22:18:35-PST Date: 1-Apr-84 22:16 PST From: Bill Barns Subject: Re: user interfaces To: ESTEFFERUD@Usc-Ecl.ARPA Cc: DLS.TYM@OFFICE-2.ARPA, llp@Purdue.ARPA, msggroup@Brl-Aos.ARPA Cc: fox%vpi@Csnet-Relay.ARPA, sollins@Mit-Xx.ARPA Cc: almes@Washington.ARPA Message-ID: <[OFFICE-2.ARPA]TYM-WWB-4E9GO> In-reply-to: <[USC-ECL]30-Mar-84 22:10:30.ESTEFFERUD> <[OFFICE-2.ARPA]TYM-DLS-4E4T2> 2-Apr-84 11:48:02-PST,6515;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 2 Apr 84 11:47:16-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 2 Apr 84 10:46 EST Received: From purdue-merlin.arpa.ARPA by BRL-AOS via smtp; 2 Apr 84 10:45 EST From: Larry Peterson Message-Id: <8404021544.AA21904@merlin.ARPA> Received: by merlin.ARPA; Mon, 2 Apr 84 10:44:19 est Date: 2 Apr 1984 1044-EST (Monday) To: msggroup@BRL.ARPA Cc: fox%vpi@CSNet-Relay.ARPA, sollins@mit-xx.ARPA, almes@washington.ARPA Subject: MSGGROUP#2236 summary of user interfaces I appreciate the response I got to my search for user interfaces that allow a user to chain through a sequence of replies. Since a number of replies were sent only to me, I thought that I would summarize what I found out. First, there are a number of teleconferencing systems that maintain reply sequences --> EIES, Panalog, PLATO Notes, COM/PartaCom, and Forum. In addition, several mail interfaces do the same --> CMU's RdMail (alias Mercury), SRI/Tymeshare's Augment, Symbolic's ZMAIL, Xerox's Officetalk, the interface on the EAN mail system (used on CDN CCITT X.400), and the soon to be released Version 11 of MS, (also known as DECmail/MS). The basic implementation approach that I heard about involved linking the Message-Id and the In-Reply-To fields, although COM links Comments (?). Also, Augment and Officetalk apparently allow branches rather than requiring a linear list. (Other's may do this too, but no one mentioned it.) The reason that I was interested in such mail interface programs is that we are developing a new approach to computer mail as part of the TILDE project at Purdue. The system that we are working on is based on conversations rather than memos, and we provide a "linking" of messages in a more powerful way than reply-chains. (The reply chains mentioned above are actually a subset of what we support.) The following is an overview of our approach. If you are interested in more information, send me a note and I can forward a Tech Report on the subject. ---Conversation-Based Mail--- The fundamental object of communication is the "conversation" rather than the memo. Instead of reading, writing, and filing individual memos, the user participates in a set of conversations. A conversation consists of a group of "messages", which are shared by a set of "participants". Participants are able to view all messages associated with the conversation, and as well as add new messages. Thus, we take the view that messages are "submitted" to a specific conversation rather than mailed to a group of recipients. The underlying structure of conversation-based mail maintains the relationship among the messages which make up a particular conversation. Informally, when a participant composes a message, he does so in the context of the messages he has already seen. Specifically, "message context" is a relation "R" that holds between messages "i" and "j", such that message-i R message-j iff message-i had been read by the author of message-j before composing message-j. The set of such relations for all the messages in a conversation can be represented by a directed acyclic graph called a "context graph", where messages make up the nodes. An edge leading from node "i" to node "j" implies message-i R message-j, and reads "%message-i "precedes" message-j. A topological sort is done on the graph to display messages to the user in a meaningful order. Each conversation has a "topic" and each message has a "subject". Whether a conversation is actually restricted to a single topic or not is a decision made by the participants. It is envisioned, however, that this will be the case as users are free to have more than one conversation with the same participants at the same time. A conversation begins when a user defines the set of participants and submits an initial message. New members may be added to a conversation by having that list expanded to include them. Similarly, old members may be removed. Being added to a conversation means having access to the entire "history" of the conversation. Removal implies not being able to read any future messages submitted to the conversation. Each participant in a conversation is known by a "universal-name" which is understood by the underlying mechanisms that support conversation-based mail. In addition to universal names, a private set of "aliases" is maintained for each user. These aliases are used by a participant to specify other members of a conversation, and by the user interface when presenting participant names to that user. At any time, a given user will be participating in a set of conversations. In contrast to a memo-based system where messages are perceived to be either "new" or "old", this set of conversations is partitioned into "foreground" and "background" subsets. A conversation is said to be in the foreground if a participant has acted on it in the past n days. Foreground conversations are further partitioned into those that contain messages not yet seen by the user, and those in which the user is up-to-date. The set of messages which make up a conversation are classified as being either "visible" or "hidden". Visible messages are automatically displayed and made available to participants when a conversation is viewed. Participants are able to hide certain messages when they are determined to be irrelevant to the conversation. Hidden messages are still maintained in the history of the conversation, and may be examined with special commands, but are not automatically displayed to the user. It should be note that the degenerate case of conversation-based mail is the same as memo-based mail. For example, a user can start up a new conversation by simply sending an initial message. If replies are also sent in separate conversations, a set of independent conversations results. Such a set of conversations is equivalent to the set of independent memos generated by current memo-based user interfaces. Furthermore, basing mail on conversations leads to a scheme for incorporating all forms of mail-like activities into one format. For example, current system-wide bulletin boards can be replaced by a single conversation, with all users on the system as participants. Similarly, each news group that a user belongs to can be managed as a conversation. Larry Peterson 2-Apr-84 20:10:49-PST,1370;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 2 Apr 84 20:08:10-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 2 Apr 84 22:44 EST Received: From office-2.arpa.ARPA by BRL-AOS via smtp; 2 Apr 84 22:41 EST Date: 2 Apr 84 19:37 PST From: Kirk Kelley Subject: MSGGROUP#2237 Re: user interfaces To: MsgGroup@BRL.ARPA Message-ID: <[OFFICE-2.ARPA]TYM-KIRK-4F1FT> In-reply-to: <49923@QZCOM> <49922@QZCOM> Speaking of user interfaces and message identifiers, here is my entry for the shortest human decipherable date and time format. DATETIME := DD M YY H MM For example, a message sent April 2, 1984 at 5:57 am GMT would have an identifier with a datetime component thus: 02A84E57 DD := DIGIT DIGIT Day of the month. M := 'J|'F|'M|'A|'Y|'U|'L|'G|'S|'O|'N|'D. The algorithm is: starting with January, the first unused letter in a month's name is used for that month. YY := DIGIT DIGIT The last two digits of the year. H := 'A|'B|'C ... 'V|'W|'X Hour of the day. A = 1 am GMT. MM := DIGIT DIGIT [SS] Minute in the hour. SS := DIGIT DIGIT This is an optional "seconds field" used when a sender generates more than one message identifier per minute. -- kirk 3-Apr-84 01:00:22-PST,1496;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Tue 3 Apr 84 00:58:24-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 3 Apr 84 3:26 EST Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 3 Apr 84 3:20 EST Date: 3 April 1984 03:19-EST From: Robert Elton Maas Subject: MSGGROUP#2238 Re: user interfaces To: KIRK.TYM@Office-2.ARPA cc: MsgGroup@Brl-Aos.ARPA Date: 2-Apr-84 19:37 PST From: Kirk Kelley Speaking of user interfaces and message identifiers, here is my entry for the hortest human decipherable date and time format. DATETIME := DD M YY H MM 54 6 87 ? 10 [I assume you really meant HH instead of H, but that's not the important part I'm criticizing below] Why do you persist the mixmash of putting the digits in random order instead of from high-order to low-order? I do it this way, so the digits within each field and the fields overall are consistently ordered: YY M DD HH MM 87 6 54 32 10 Thus EST as I write this message is: 84.4.03 03:14. It would also be logical to do low-order first throughout, as: Four and ten minutes after three on the 3rd of April four and eighty. but I prefer high-order first because that's the way I've written numeric quantities all my life, i.e. 1984 instead of 4&80&900&1000. 3-Apr-84 15:57:09-PST,1457;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Tue 3 Apr 84 15:54:32-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 3 Apr 84 18:31 EST Received: From office-2.arpa.ARPA by BRL-AOS via smtp; 3 Apr 84 18:26 EST Date: 3 Apr 84 15:23 PST From: Kirk Kelley Subject: MSGGROUP#2239 Re: user interfaces (identifier date time) To: Robert Elton Maas To: John Covert Cc: MsgGroup@Brl-Aos.ARPA Message-ID: <[OFFICE-2.ARPA]TYM-KIRK-4F39R> In DATETIME := DD M YY H MM Transposing YY and DD would be ok. The rationalization for persisting with the "standard" ordering is to minimize the amount needed to uniquely identify a message from a certain person in your personal monthly or yearly subset in the case where you happened to get only one message from that person that day. I SAID it was a rationalization. The original spec reveals why it is H instead of HH. The hour is represented as a single letter from A to X. For example, a message sent April 2, 1984 at 5:57 am GMT would have an identifier with a datetime component thus: 02A84E57 In the design of this format, conciseness was as important a requirement as human decipherability. Other proposals that better meet both requirements would be more interesting than complaints about how cryptic (or vebose) this one is. -- kirk 3-Apr-84 19:30:41-PST,966;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Tue 3 Apr 84 19:29:36-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 3 Apr 84 21:05 EST Received: From usc-isif.arpa.ARPA by BRL-AOS via smtp; 3 Apr 84 21:06 EST Date: 3 Apr 1984 18:03:39 PST From: POSTEL@Usc-Isif.ARPA Subject: MSGGROUP#2240 re: user interfaces (identifier date time) To: msggroup@Brl-Aos.ARPA Kirk: GACK! I hope i never see one of your concise time strings! Even more, i hope i never have to explain it to anyone!! Why not use the ISO standards for date and time [ISO-2014, ISO-3307, ISO-4031]? The format is generally YYYY MM DD HH MM SS OM OS, with various separators. The local time in Calcutta India of two hours nine minutes and twenty-three seconds past noon on the third of February 1984 would be 1984-02-03-14:09:23-05:00 or 19840203140923-5000 --jon. ------- 5-Apr-84 19:03:43-PST,6174;000000000001 Return-Path: Received: from [192.5.22.17.] (for BRL-MIS) by USC-ECLC; Thu 5 Apr 84 19:02:00-PST Received: From mit-multics.arpa.ARPA by BRL-MIS via smtp; 5 Apr 84 21:36 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2627513924848961@MIT-MULTICS.ARPA>; 05 Apr 1984 19:58:44 est Date: 04 Apr 84 12:25 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL%QZCOM.MAILNET@MIT-MULTICS.ARPA, msggroup@BRL.ARPA, "Larry Peterson" cc: fox@vpi, sollins@MIT-XX.ARPA, almes@WASHINGTON.ARPA Subject: MSGGROUP#2241 summary of user interfaces Message-ID: <50424@QZCOM> In-Reply-To: <8404021544.AA21904@merlin.ARPA> Sorry, a misunderstanding: COM uses "message-id" och "in-reply-to" fields to keep the relationships between messages going, just like most other systems. To a local user of COM, the word "in-reply-to" is presented using the word "comment on", but this is only a matter of wording, the concept is the same and in network mail the word "in-reply-to" is of course used. Any message can be a comment on any number of other messages, and can have any number of comments on it. There is not even in COM any requirement that the graph is directed, circularities like "A in-reply-to B", "B in-reply-to C", "C in-reply-to A" can be created. PortaCOM however is a little more restricted, every message can only be a comment on one previous message (but can have several coments on it) and circularities are not permitted. This makes it possible in PortaCOM to have user commands for traversing the graph, which in PortaCOM is always a tree, in various directions. Since COM allows any number of relations in any order, commands for traversing the graph are not so easy to implement. Thus, instead, COM keeps a linear sequential list of all text items belonging to a certain "set-of-related-messages", and uses this list when someone wants to traverse or search on the set of related messages. Commands to follow the "in-reply-to" relations back and forward in COM are thus not automatically recursive, so as to avoid loops. ----------------------------------------------------------- The structure you describe sounds very similar to the way a computer conferencing system works, where your set of related messages correspond to a conference in a conference system. The advantage with this, as you point out, is that a reader of messages can read messages one conference (or topic or message-set or whatever you prefer to call it) a time, and can decide himself in which order to read the conferences, e.g. read the important conferences immediately, save the less important for another time, or even skip entirely part of a less important conference and still stay as a member of that conference. This gives the reader of messages more control of the communication process. ---------------------------------------------------------- In COM/PortaCOM we have chosen not to link the concept of "messages related by in-reply-to references" to the concept of "conferences". Any message can belong to any number of "conferences" in COM and PortaCOM, but only to one set of "reply-related-messages". These concepts are completely independent, a reply can continue a discussion in another conference. Example: One message in "experience with XYZ-ware" proposes a change in XYZ-ware". A set of messages discussing how to implement this change are written in "implementation of XYZ-ware" but can still have an "in-reply-to" relation to the original suggestion. Another difference, as it works in COM/PortaCOM, is that a conference requires an explicit command by someone to start a conference, and explicit commands to add members to the conference, either by the new member himself (for open conferences) or by the organizer of the conference (for closed conferences). A reply-set is created automatically every time someone writes a message which is a reply to a previous message. Thus, new reply-sets are created hundreds of times each day by our users, new conference only perhaps one or two a day. A conference, but not a reply-set, can also serve as a network distribution list, that is, send messages in the conference to members of the conference at remote sites. Parallel conferences can also be created between COM or other conference system on several sites, with all messages copied by network mail between the parallel conferences. --------------------------------------------------------- The basic structure of COM is a data base with the main elements in the data base being "texts", "mailboxes", "conferences" and "links". A link can be created at any time, and can link a text message to another text message (IN-REPLY-TO link) or a text message to a conference or mailbox (TO or CC link). Links can also be removed or changed, e.g. moving an entry to another conferences or linking it to one more conference, at any time, subject to some restrictions to stop misuse of this feature. --------------------------------------------------------- A user of COM normally reads one conference at a time, and within a conference, one reply-set at a time. A message is only shown once to a user, even if both the message and the user belongs to more than one conference. There are commands for skipping all or part of the messages in one conference, or in one reply-set, without reading it. Our experience is that it is very useful to have conferences and reply-sets as independent concepts, even though they serve partly the same purpose of structuring the message data base. Conferences are a more stable thing with a longer life time, reply-sets come and go every day and are created automatically, not requiring any human intervention. This is important because humans are lazy, and would not create all this structure if they had to use explicit commands to create them every time this is needed. 5-Apr-84 11:14:18-PST,1075;000000000001 Return-Path: Received: from [192.5.22.17.] (for BRL-MIS) by USC-ECLC; Thu 5 Apr 84 11:11:21-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 5 Apr 84 13:31 EST Received: From cmu-cs-a.arpa.ARPA by BRL-AOS via smtp; 5 Apr 84 13:22 EST Date: 5 Apr 84 1316 EST (Thursday) From: Richard H. Gumpertz To: Kirk Kelley Subject: MSGGROUP#2242 Re: user interfaces (identifier date time) CC: MsgGroup@Brl-Aos.ARPA In-Reply-To: <[OFFICE-2.ARPA]TYM-KIRK-4F39R> Message-Id: <05Apr84.131604.RG02@CMU-CS-A.ARPA> The ANSI/ISO date standard isn't all that much longer. Why not use it? 840402 is just one digit longer 84093 is the same length (last 3 digits are day-of-year) but hard to decode The date may be extended with a time, such as 8404020557, without ambiguity, but some punctuation might make it a bit more readable. In any case, LOTS of people are now using the standard, so why re-invent the wheel? Make it readable by the uninitiated! Rick Gumpertz 5-Apr-84 19:40:46-PST,1017;000000000001 Return-Path: Received: from [192.5.22.17.] (for BRL-MIS) by USC-ECLC; Thu 5 Apr 84 19:38:05-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 5 Apr 84 21:58 EST Received: From brl-mis.arpa.ARPA by BRL-AOS via smtp; 5 Apr 84 21:51 EST Received: From mit-multics.arpa.ARPA by BRL-MIS via smtp; 5 Apr 84 21:37 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2627514629024079@MIT-MULTICS.ARPA>; 05 Apr 1984 20:10:29 est Date: 05 Apr 84 15:32 +0100 From: Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL%QZCOM.MAILNET@MIT-MULTICS.ARPA, msggroup@BRL-AOS.ARPA Subject: MSGGROUP#2243 Re: user interfaces Message-ID: <50561@QZCOM> In-Reply-To: <50331@QZCOM> I agree with Robert. Write date-time using a consistent ordering. Why not even step up to use the ISO format for date-times? 9-Apr-84 06:32:54-PST,992;000000000001 Return-Path: Received: from [192.5.22.17.] (for BRL-MIS) by USC-ECLC; Mon 9 Apr 84 06:32:38-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 9 Apr 84 8:17 EST Received: From ur-cs-gw.ARPA by BRL-AOS via smtp; 6 Apr 84 15:05 EST Received: by sen.rochester (3.327.3O) id AA10794; 6 Apr 84 15:03:54 EST (Fri) Received: by cay.Rochester (3.327.3N+) id AA09106; 6 Apr 84 15:03:17 EST (Fri) Message-Id: <8404062003.10794@sen.rochester> Date: 6 Apr 84 15:03:54 EST (Fri) From: Liudvikas Bukys Subject: MSGGROUP#2244 looking for etiquette documents To: MsgGroup@BRL.ARPA Can anyone direct me to a "network mail etiquette" document suitable for instruction of new users? I'm looking for something more fleshed-out than "no commercial use, no vulgarity, no chain letters". I already have a copy of "Emily Post for Usenet". I'm looking for something with an Arpanet orientation. Liudvikas Bukys bukys@rochester.arpa 12-Apr-84 15:16:11-PST,1574;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Thu 12 Apr 84 15:12:59-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 12 Apr 84 14:23 EST Received: From brl-mis.arpa.ARPA by BRL-AOS via smtp; 12 Apr 84 14:23 EST Received: From mit-multics.arpa.ARPA by BRL-MIS via smtp; 12 Apr 84 14:15 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2628097590775564@MIT-MULTICS.ARPA>; 12 Apr 1984 14:06:30 est Date: 06 Apr 84 18:11 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: msggroup@BRL-AOS.ARPA Subject: MSGGROUP#2245 ISO date standard Message-ID: <50813@QZCOM> In-Reply-To: <05Apr84.131604.RG02@CMU-CS-A.ARPA> The COM system uses the ISO date standard in all its internal printing of dates. This date standard is almost universally used here in Sweden nowadays. However, when we send out mail to RFC822-based networks, we convert the date to the format used in that standard. And in input to message retrieval commands, we accept also the format "3-April" for those who prefer that format. We have delivered COM to some universities in the U.S. and we have been wondering if they would complain about the date standard we use, and require us to make an "american" version of COM with the date format MM/DD/YY most commonly used in the U.S. So far, we have not received any such complaint. 9-Apr-84 10:41:32-PST,636;000000000001 Return-Path: Received: from [192.5.22.17.] (for BRL-MIS) by USC-ECLC; Mon 9 Apr 84 10:39:32-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 9 Apr 84 12:52 EST Received: From rand-unix.arpa.ARPA by BRL-AOS via smtp; 9 Apr 84 12:48 EST Date: 9 Apr 1984 08:59-PST To: Liudvikas Bukys Cc: MsgGroup@BRL.ARPA Subject: MSGGROUP#2246 Re: looking for etiquette documents In-reply-to: Your message of 6 Apr 84 15:03:54 EST (Fri). <8404062003.10794@sen.rochester> From: norm@Rand-Unix.ARPA I'd appreciate your sending me a copy of "Emily Post for Usenet". 9-Apr-84 15:13:12-PST,965;000000000001 Return-Path: Received: from [192.5.22.17.] (for BRL-MIS) by USC-ECLC; Mon 9 Apr 84 15:12:54-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 9 Apr 84 14:44 EST Received: From rutgers.arpa.ARPA by BRL-AOS via smtp; 9 Apr 84 14:40 EST Date: 9 Apr 84 14:39:12 EST From: Charles Hedrick Subject: MSGGROUP#2247 network etiquette To: msggroup@BRL.ARPA We also recommend the following pair of conventions: - Many people are not fast typists. They have a tendency to be as brief as possible when writing messages. This means that they may have an appearance of being curt or abrupt. You should avoid reacting emotionally, as this appearance is probably not intended. - If you are mad at somebody, call them or talk to them in person. A number of feuds have been fueled by network mail exchange, where a simple person-to-person meeting would have smoothed things out. ------- 9-Apr-84 16:26:59-PST,1881;000000000001 Return-Path: Received: from [192.5.22.17.] (for BRL-MIS) by USC-ECLC; Mon 9 Apr 84 16:26:41-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 9 Apr 84 18:41 EST Received: From ur-cs-gw.ARPA by BRL-AOS via smtp; 9 Apr 84 18:36 EST Received: by sen.rochester (3.327.3O) id AA15550; 9 Apr 84 17:52:06 EST (Mon) Received: by cay.Rochester (3.327.3N+) id AA03732; 9 Apr 84 17:51:35 EST (Mon) Message-Id: <8404092252.15550@sen.rochester> Date: 9 Apr 84 17:52:06 EST (Mon) From: Liudvikas Bukys Subject: MSGGROUP#2248 "Emily Post for Usenet"; still looking for etiquette documents To: msggroup@brl.ARPA Cc: ROBBINS%MIT-OZ@MIT-MC.ARPA, norm@rand-unix.ARPA, rucker@brl-aos.ARPA Due to popular demand, I have placed the following files in ROCHESTER.ARPA's "public" directory for FTP by user "anonymous", password "guest". public/usenet.rules: Rules for posting to Usenet public/usenet.emily-post: Emily Post for Usenet public/usenet.questions: Answers to Frequently Asked Questions public/usenet.style: Hints on writing style for Usenet Usenet is a distributed bulletin board system running on about 800 machines, in North America, Europe, Australia, and Korea, with a total of a few thousand users. Discussions are organized by topic in "newsgroups". The articles listed above were recently posted to the "net.announce.newusers" newsgroup in the hope that new users, having just discovered an audience of 1000 people, will learn good manners and refrain from asking (again) what "foobar" means. ------- I am still looking for Arpanet mail guidelines for new users. In particular, I would be interested to know what kind of policy statements made it onto the record after messes such as the last chain letter incident. Liudvikas Bukys bukys@rochester rochester!bukys 10-Apr-84 13:45:49-PST,829;000000000001 Return-Path: Received: from [192.5.22.17.] (for BRL-MIS) by USC-ECLC; Tue 10 Apr 84 13:45:30-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 10 Apr 84 16:03 EST Received: From utah-20.arpa.ARPA by BRL-AOS via smtp; 10 Apr 84 15:56 EST Date: 10 Apr 84 13:54:49-MST From: Jay Lepreau Subject: MSGGROUP#2249 Re: "Emily Post for Usenet"; still looking for etiquette documents To: bukys@ROCHESTER.ARPA cc: msggroup@BRL.ARPA In-Reply-To: Message from "Liudvikas Bukys " of Mon 9 Apr 84 17:52:06-MST Usenet has at least 10,000 regular readers, an estimate made awhile ago. Of course, no one (I hope!) attempts to read all the newsgroups. With over 800 machines your figure of 1000 users obviously doesn't make sense. ------- 19-Apr-84 03:29:47-PST,1270;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Thu 19 Apr 84 03:25:12-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 19 Apr 84 6:02 EST Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 19 Apr 84 5:59 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2628671400961917@MIT-MULTICS.ARPA>; 19 Apr 1984 05:30:00 est Date: 13 Apr 84 22:13 +0200 From: KPJ_Jaakkola_QZ_%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: KPJ_Jaakkola_QZ_%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL%QZCOM.MAILNET@MIT-MULTICS.ARPA, msggroup@BRL.ARPA cc: "Elaine Kerr" <114%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA>, "Murray Turoff" <103%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA>, "Roxanne Hiltz" <120%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA> Subject: MSGGROUP#2250 network etiquette Message-ID: <51681@QZCOM> In-Reply-To: <51632@QZCOM> Re political propaganda: Anyone may introduce their favourite political propaganda, as long as it is certain who is the source. Never should an administrator (in the role of an administrator) output any propaganda (of whatever kind, political, religious etc). 19-Apr-84 04:04:51-PST,6771;000000000001 Date: 19 Apr 84 03:45:00-PST Subject: MSGGROUP#2251 SURVEY #2201-#2250 from MSGGROUP.2201-2300.1 From: Einar Stefferud - MsgGroup Moderator Reply-To: MsgGroup-request@BRL To: MsgGroup@BRL Here is the SURVEY listing of MsgGroup messages 2201-2250. You can FTP the whole file from [ECLC]msggroup.2201-2300.1, using FTP with LOGIN ANONYMOUS using Password MSGGROUP. I will remail requested items, with some delay for processing, if you will request them by reply mail to MsgGroup-Request@BRL. Please cite items you want by their specific Msggroup#nnnn identifiers, as shown. ======== MSGGROUP#2201 SURVEY #2151-#2200 from MSGGROUP.2101-2200.1 6906 chars 20 Dec 1983 17:00:07 PST From: MsgGroup Moderator - Stefferu MSGGROUP#2202 RFCs 889, 891 and 892 Now Available 1790 chars 21 Dec 1983 20:50:30 PST From: WESTINE@USC-ISIF To: Reques MSGGROUP#2203 RFC 869 & 878 Now Available 1509 chars 27 Dec 1983 20:11:05 PST From: WESTINE@USC-ISIF To: Reques MSGGROUP#2204 RFC 888 Now Available 1062 chars 13 Jan 1984 15:11:36 PST From: WESTINE@USC-ISIF To: Reques MSGGROUP#2205 Recommendations from a study of Electronic Mailbox Systems 2213 chars 17 Jan 1984 10:21:04-GMT From: Hugh Smith MSGGROUP#2217 Re: electronic-mail "telephone directory" 941 chars 29 Feb 1984 0043-EST (Wednesday) From: Christopher A Kent T MSGGROUP#2219 Re: electronic-mail "telephone directory" 1124 chars 29 Feb 84 00:36:23-PST Wed From: David Roode MSGGROUP#2220 Re: electronic-mail "telephone directory" 455 chars 29 Feb 84 4:55:15 EST Wed From: Stephen Wolff T MSGGROUP#2224 CBMS 84 4101 chars 5 Mar 84 10:13:30 GMT From: Hsmith@ucl-cs.arpa To: msggrou MSGGROUP#2225 electronic mail "telephone directory" 3070 chars 22 Mar 84 22:27:11 pst Thu From: Don Speck Received: from BRL-MIS by USC-ECLC; Thu 19 Apr 84 04:00:00-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 19 Apr 84 6:01 EST Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 19 Apr 84 5:58 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2628671254081038@MIT-MULTICS.ARPA>; 19 Apr 1984 05:27:34 est Date: 13 Apr 84 19:03 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL%QZCOM.MAILNET@MIT-MULTICS.ARPA, msggroup@BRL.ARPA cc: "Elaine Kerr" <114%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA>, "Murray Turoff" <103%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA>, "Roxanne Hiltz" <120%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA> Subject: MSGGROUP#2252 network etiquette Message-ID: <51632@QZCOM> In-Reply-To: <51162@QZCOM> Here are the ethical rules which we are applying for the COM usage at QZCOM. I am fully aware that they are not comprehensive. Note: To make them applicable to ARPANET, just replace the word "conference" with the word "mailing list" wherever it appears below. In addition to this, I believe that in the EIES computer conference system, they have much experience on ethical guidelines for computer-mediated message systems. I suggest that you ask someone there to send in their guidelines. You could e.g. write to "Elaine Kerr" <114%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA> COPYRIGHT Text in COM is copyrighted both by the author and the computer centre running COM. Texts may be copied in single copies on paper or to your personal computer for your own personal use. Other copying requires permission from the computer centre. A person who enters text into COM will thereby give permission for this text to be copied to other message system according to the principles commonly used for the COM system. ADVERTISEMENTS IN COM Commercial avertising is permitted in COM. However, QZ customers who wish to publish advertisements in COM should to it only in special COM conferences intended for the publication of advertisements. ETHICS, GENERAL Just as in any other instance of human intercourse, certain ethical guidelines should be applied to the usage of the COM system. Since COM is a new medium which may be unfamiliar to many, it might be a good idea to codify the more important of these guidelines in writing. These guidelines are by no means mandatory, but they should still be adhered to unless there are strong reasons for not doing so. MISREPRESENTATION OF FACT: Should misrepresentation of fact occur in COM, this should be put right at once, e.g. by using the COM command COMMENT to enter a correction. Thus, the correction will automatically be sent to anyone who got the misstatement before. Should the misrepresen- tation be of personal data, routine procedure should also call for erasing the entire notice containing the misstatement, by means of the COM command ERASE OBJECT . PASSING ON TEXTS: Letters and entries of closed conferences should not be moved to open ones without the author's permission. POLITICAL PROPAGANDA: The COM system should not be used for such activity as may be interpreted as propaganda for a given political party. This ethical rule does not prevent political discussions in COM. Political questions might arise for various reasons; there might for instance be discussions on research policy and other political topics. SUBJECTIVE STATEMENTS CONCERNING INDIVIDUALS: Subjective statements concerning individual persons should not be entered in open COM conferences. IRONY: Experience tells us that irony in COM is often misinterpreted and taken seriously by mistake. This could be prevented by means of a certain convention, accepted in COM. By this convention, you put whatever you mean ironically within a special kind of "irony parentheses". Like this: (. Text to be taken ironically .) MAKING APPOINTMENTS VIA COM: Making appointments via COM usually does not work very well. The reason for this might be that COM is generally felt to be such an interactive medium that you automatically try to make appointments according to the same conventions as in face-to-face meetings. This does not work. If you want to make an appointment via COM for a physical meeting, you shall have to arrange for all participants simultaneously to make a list of their available time. Guided by this information, you may then quickly and easily book your meeting. SPECIAL PRIVILEGES OF THE ORGANIZERS: The organizer's privileges of subtracting and moving entries, and excluding members, should be employed with great care. Misrepresen- tations of fact are often best corrected by means of a corrective notice, in some instances combined with erasure of the incorrect message. The option to move entries should be used when the contents of an entry has obviously no bearing on the purpose of the conference. In this manner you will aid COM users who are trying to decide by choice of conference what to read. 19-Apr-84 04:19:54-PST,1888;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Thu 19 Apr 84 04:16:47-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 19 Apr 84 6:02 EST Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 19 Apr 84 5:58 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2628671347522520@MIT-MULTICS.ARPA>; 19 Apr 1984 05:29:07 est Date: 13 Apr 84 19:20 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL%QZCOM.MAILNET@MIT-MULTICS.ARPA, msggroup@BRL.ARPA cc: "Elaine Kerr" <114%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA>, "Murray Turoff" <103%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA>, "Roxanne Hiltz" <120%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA> Subject: MSGGROUP#2253 network etiquette Message-ID: <51634@QZCOM> In-Reply-To: <51632@QZCOM> What is the opinion in the Arpanet mail community towards anonymous and pseudonymous messages? I have noted some messages without any FROM field, but I guess this was probably not any intentionaly anonymity. The SMTP sender cannot be avoided, but of course you could make it into . EIES are using anonymity, especially with pen names, quite a lot and claim that it has great advantages in certain applications where people would otherwise be too shy. COM allows anonymity, but it is not widely used. The COM-RFC-mail interface does not allow sending out anonymous entries, mainly because we must know the author to know whom to bill. This could be modified, since the author name can be found in the data base, even if it is not readable to users. We have been discussing to allow anonymity only in special conferences (Arpanet jargon: Mailing lists) where all entries are anonymous. 22-Apr-84 00:09:14-PST,1404;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Sun 22 Apr 84 00:08:27-PST Date: 21 Apr 1984 22:51:56 PST From: WESTINE@USC-ISIF Subject: MSGGROUP#2254 RFC 898 Now Available To: Request-for-Comments-List: A new Request for Comments is now available from the Network Information Center in the directory at SRI-NIC. RFC 898: Title: Gateway Special Interest Group Meeting Notes Author: R. Hinden Pages: 24 pathname: [SRI-NIC]RFC898.TXT This memo is a report on the Gateway Special Interest Group Meeting that was held at ISI on 28 and 29 February 1984. Robert Hinden of BBNCC chaired, and Jon Postel of ISI hosted the meeting. Approximately 35 gateway designers and implementors attended. These notes are based on the recollections of Jon Postel and Mike Muuss. Under each topic area are Jon Postel's brief notes, and additional details from Mike Muuss. This memo is a report on a meeting. No conclusions, decisions, or policy statements are documented in this note. Public access files may be copied from the directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. 23-Apr-84 08:59:00-PST,2042;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 23 Apr 84 08:57:28-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 23 Apr 84 11:15 EST Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 23 Apr 84 11:14 EST Date: 23 April 1984 11:12-EST From: Robert Elton Maas Subject: New topic, name domains vs. IFIP "user-friendly" non-domain names To: MsgGroup@Brl-Aos.ARPA (This message went astray becuse I didn't know what host now maintains this mailing list and the convenience vector at my local host (MIT-MC) was totally broken and there's no such thing as a "generic" or "net-wide" mailing list where anybody on any host could just mail to "MsgGroup" without having to remember the correct host. Thanks to ESTEFFERUD I now know the correct host for MsgGroup, so now I'm resending this message directly there.) COMSAT@MIT-MC 04/18/84 12:00:04 Re: Msg of Wednesday, 18 April 1984 11:59-EST To: REM at MIT-MC ============ A copy of your message is being returned, because: ============ Could not open the file DSK:CBF;MSGROU >because FILE NOT FOUND ============ Failed message follows: ============ REM@MIT-MC 04/18/84 11:59:33 Re: Arpa-Internet name domains vs. IFIP WG 6.5 user-friendly names To: MSGGROUP at MIT-MC The concensus seems to be that MsgGroup is the correct place to discuss differences between the heirarchial naming method being adopted by the Internet community and the non-heirarchial naming method being proposed to CCITT by IFIP WG 6.5. It has been suggested that the IFIP proposal would permit heirarchial domains of naming authority, but I fail to see it. Could somebody explain it to me? After that is cleared up, perhaps we who have seen both the IFIP proposal and the Internet plan could discuss the differences and debate the merits? Personally I like the explicit heirarchial nature of the Internet plan, and would like something like that incorporated into the IFIP proposal, unless it's already there somewhere. 28-Apr-84 06:30:48-PST,1559;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Sat 28 Apr 84 06:28:35-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 28 Apr 84 9:01 EST Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 28 Apr 84 9:04 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2629461317084472@MIT-MULTICS.ARPA>; 28 Apr 1984 08:55:17 est Date: 25 Apr 84 19:05 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, msggroup@Brl-Aos.ARPA Subject: Non-deliverable messages Message-ID: <53207@QZCOM> We who participate in ARPANET mailing lists via MAILNET have to pay the charge not only of sending messages to the list, but also of sending all messages from ARPANET to our site. It is then rather a nuisance when we receive error-messages that an entry which someone at our site made in an ARPANET mailing list could not be delivered to one member of that mailing list - information which is of very little value to us. Could not this be solved in the following way: (a) Such error-messages are sent to the SMTP-sender, not to the author. (b) ARPANET mailing lists, when redistributing messages, indicate the postmaster at the site handling the mailing list, and not the original author, as the SMTP sender when redistributing the message. 28-Apr-84 06:44:56-PST,1568;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Sat 28 Apr 84 06:43:56-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 28 Apr 84 9:01 EST Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 28 Apr 84 9:05 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2629461356526362@MIT-MULTICS.ARPA>; 28 Apr 1984 08:55:56 est Date: 25 Apr 84 19:13 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, msggroup@Brl-Aos.ARPA Subject: Non-deliverable messages Message-ID: <53211@QZCOM> In-Reply-To: <53207@QZCOM> Here is an example of the kind of messages we get, and have to pay for. If the postmaster at the mailing list site had been the SMTP-sender when re-transmitting from the mailing list, this problem would not have occurred: Liaison@MIT-MULTICS.ARPA @QZCOM:POSTMASTER_at_QZ@ODEN.MAILNET Return-Path: Received: from MIT-MULTICS.ARPA by QZCOM.MAILNET; 25 Apr 84 10:38 +0100 From: Network_Server.Daemon at MIT-MULTICS.ARPA Subject: Unable to deliver mail from POSTMASTER_at_QZ@QZCOM.MAILNET Message will be returned under separate cover. To: LATZKO@RU-BLUE.ARPA at COLUMBIA-20.ARPA: Network mail authorization failure Mail from POSTMASTER_at_QZ@QZCOM.MAILNET to LATZKO@RU-BLUE.ARPA is not authorize d 28-Apr-84 07:09:54-PST,7277;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Sat 28 Apr 84 07:06:05-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 28 Apr 84 9:02 EST Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 28 Apr 84 9:05 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2629461462928224@MIT-MULTICS.ARPA>; 28 Apr 1984 08:57:42 est Date: Thu, 19 Apr 84 20:27:04 EST From: "Elaine Kerr" <114%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA> Reply-to: "Elaine Kerr" <114%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA>, Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, MsgGroup@Brl-Aos.ARPA Subject: EIES NORMS Message-ID: SMTP sender: @MIT-MULTICS.ARPA:114@NJIT-EIES (Jacob, I cannot figure out how to send this to Message_group_at_BRL%qzQZCOM. Mailnet or to "Liudvikas Bukys" or whatever if you don't want to read them) . ====== ETIQUETTE AND HINTS FOR USING THIS NEW COMMUNICATIONS MEDIUM INFORMALITY: People tend to treat messaging and conferencing somewhat informally. Perfect grammar and typing are much less important than making your meaning clear. Later, if you need to use an item in a report or paper, it's simple to go bac k and edit it. Since most of the people on EIES have not met each other in person, there is a good deal of "getting to know you" communication which is very important in making people feel comfortable about communicating in this new way. We sugge st that new groups spend some time at the beginning with introductions. A ne w group may even wish to schedule a simultaneous on-line session in which group members introduce themselves and explore possible areas of common concern. NEED FOR EXPLICIT RESPONSES: Since non-verbal cues (such as nods, smiles, and frowns) are absent in comput erized conferencing, it is very important to let others know explicitly wheth er you understand, agree, or disagree with what they have said and to spell out your intentions or expectations. People cannot hear your tone of voice and m ay not recognize subtle humor or may misinterpret an innocent remark. If you ne ed further explanation, you must send a message or enter a conference comment asking for it. It is useful to indicate your agreement or support of someone 's comments. Otherwise, EIES can be like talking into a tape recorder with n o feedback at all. Metacommunication (communication about communication) is es pecially important. If you're not getting responses from others, perhaps you're talking off the s ubject or your style is too verbose or difficult to understand. If this is t he case, consider sending a message to a friend in your group or to the group mo derator, asking why people seem to be ignoring you. If you're going to be off line for a few days because of travel or other comm itments, try to let your group know in advance so that they will not expect a ny messages or responses from you. You might want to use +SNAME to change your name temporarily to something like JOE AWAY TILL 10/2. MAINTAINING THE PRIVACY OF PRIVATE MESSAGES: It is considered a breach of confidentiality to copy a private message to ano ther person without the author's explicit permission. Because it is very eas y to copy items on EIES, one could never be sure that confidential messages would remain so without this norm. If you send a message to someone such as a conference moderator and don't mind if it's copied into the conference or to other people, say so explicitly. RECOGNIZING AUTHORSHIP: This refers to proper citation or credit. If you're using an item written by someone else on EIES for publication elsewhere, please treat is as you would any other intellectual property by footnoting it or otherwise giving proper credi t to the author. MESSAGES VS. CONFERENCE COMMENTS: Conferences are generally meant for items that need to be reviewed or discuss ed later, or for items that should form part of the permanent transcript. Messages are for more temporary or private items. It is not too important to decide how to enter an item since it can always be moved or deleted later. If you're unsure about whether to enter it into a conference, you can send it as a message to the conference moderator and let him or her decide. PREVENTING INFORMATION OVERLOAD: As you get more active on EIES, you may find yourself engaging in a number of simultaneous conversations with people on different subjects, as well as participating in a number of conferences. This aspect of computerized confer encing can be overwhelming at times. The use of item Associations and Keys will help keep track of the various thr eads of a discussion at it takes place. At some point you may wish to go bac k and list the item titles (CHOICE 2) to review what has been discussed. If the message traffic is intense and you can't respond to everything right a way, you could lose track of messages. EIES has a feature that allows you to enter on-line reminders to yourself (see ?REMINDERS). Different people have their own systems for filing printed copies of their EI ES traffic. Some discard it; others fold it up and put it away somewhere; ot hers file by person, topic, conference, etc; and still others have developed color coding schemes. You'll need to figure out yourself what kind of system work s best for you and your needs. NEW SOURCES OF EMBARRASSMENT AND HOW TO AVOID THEM: The most embarrassing thing you can do on EIES is to forget to erase your Scr atchpad. You may then find that a very private message becomes the first par t of another message or conference comment. To avoid this, erase your Scratchpad after composing each item, check what line you're on in the Scratchpad befor e beginning composition, or use +CNM to enter the Scratchpad for message compos ition. If you've mistakenly entered a comment into the wrong conference, you can cop y it and then delete it from the incorrect location (see ?COPY and ?DELETE). Until you're comfortable with the pace of this communications medium, be care ful about responding immediately in a heated, emotional, or potentially controversial situation. One nice feature of computerized conferencing is th at you can compose your item, "sleep on it," and later decide whether or not to send it. 28-Apr-84 07:54:07-PST,1015;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Sat 28 Apr 84 07:51:37-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 28 Apr 84 9:12 EST Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 28 Apr 84 9:16 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2629462131631001@MIT-MULTICS.ARPA>; 28 Apr 1984 09:08:51 est Date: 26 Apr 84 09:28 +0200 From: KPJ_Jaakkola_QZ_%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: KPJ_Jaakkola_QZ_%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, msggroup@Brl-Aos.ARPA Subject: Non-deliverable messages Message-ID: <53282@QZCOM> In-Reply-To: <53207@QZCOM> Should not messages indicating problems of sending to a mailing list item to a participant be sent to the mailing list request handler? That is, for FOO-REQUESTS for mailing list FOO. 28-Apr-84 08:09:12-PST,1073;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Sat 28 Apr 84 08:05:31-PST Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 28 Apr 84 9:12 EST Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 28 Apr 84 9:17 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2629462340746693@MIT-MULTICS.ARPA>; 28 Apr 1984 09:12:20 est Date: 26 Apr 84 20:04 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: "Robert Elton Maas " , Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: msggroup@BRL.ARPA Subject: network etiquette Message-ID: <53351@QZCOM> In-Reply-To: <53231@QZCOM> An advantage with pseudonyms over anonymous messages is that an intelligent mail system could allow you to reply, while still keeping the name of the person behind the pseudonym secret. 29-Apr-84 12:10:16-PDT,1069;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Sun 29 Apr 84 12:09:45-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 29 Apr 84 14:36 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 29 Apr 84 14:38 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2629564507544331@MIT-MULTICS.ARPA>; 29 Apr 1984 14:35:07 edt Date: 28 Apr 84 11:56 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, msggroup@Brl-Aos.ARPA Subject: Non-deliverable messages Message-ID: <53596@QZCOM> In-Reply-To: <53282@QZCOM> Yes, that sounds like a good idea. That would mean that when the mailing list FOO sends out entries in the mailing list to its subscribers, it should indicate "FOO-REQUEST" as the SMTP sender (and not the original author of the message!) 29-Apr-84 16:50:05-PDT,1501;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Sun 29 Apr 84 16:46:36-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 29 Apr 84 18:58 EDT Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 29 Apr 84 18:59 EDT Date: 29 April 1984 18:57-EST From: Robert Elton Maas Subject: Non-deliverable messages To: Jacob_Palme_QZ%QZCOM.MAILNET@Mit-Multics.ARPA cc: msggroup@Brl-Aos.ARPA (b) ARPANET mailing lists, when redistributing messages, indicate the postmaster at the site handling the mailing list, and not the original author, as the SMTP sender when redistributing the message. It's not usually the job of the system postmaster to maintain random mailing lists that are stationned at that host, rather each mailing list has its own maintainer. A convention that has been established recently is to have a ...-REQUEST pseudo-mailbox for each major mailing list which vectors to the appropriate maintainer. For example: INFO-PCNET (INFO-PCNET-REQUEST vectors to myself, REM) HUMAN-NETS (HUMAN-NETS-REQUEST vectors to Mel Pleasant or somesuch) SPACE-ENTHUSIASTS, aka SPACE (SPACE-REQUEST vectors to OTA or somesuch) Ideally the mailer at the mailing-list-maintaining host should know the appropriate ...-REQUEST pseudo-mailbox for each major mailing list, sending barfbacks there instead of to Postmaster, using Postmaster only when the -REQUEST doesn't exist or isn't known to the software. 29-Apr-84 17:25:46-PDT,1553;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Sun 29 Apr 84 17:23:45-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 29 Apr 84 19:18 EDT Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 29 Apr 84 19:16 EDT Date: 29 April 1984 19:12-EST From: Robert Elton Maas Subject: EIES NORMS To: 114%NJIT-EIES.MAILNET@Mit-Multics.ARPA cc: MsgGroup@Brl-Aos.ARPA It is useful to indicate your agreement or support of someone 's comments. Otherwise, EIES can be like talking into a tape recorder with no feedback at all. Metacommunication (communication about communication) is especially important. Same goes for Arpanet. I often give reinforcing feedback when somebody says something really nicely stated that I agree with. (Gee, this seems to be self-referent, I'm agreeing with the above quoted text here.) But most people usually adopt the "if it ain't broken, don't fix it" philosophy, i.e. don't upset the applecart, don't comment except to correct or rebut. Maybe when structured text (hypertext) is generally available it'll be easy and common for people who agree with expressed views to flag the views as agreed-with, so later readers can see various articles highlighted with tens or hundreds of "I agree too" flags and thus know the article is a real concensus, and thus give more weight to what is said than would be appropriate if it as just one person's opinion. [Just for hack value: self-referent meta-communication such as this is fun!] 29-Apr-84 17:59:45-PDT,2576;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Sun 29 Apr 84 17:58:33-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 29 Apr 84 20:09 EDT Received: From su-score.arpa.ARPA by BRL-AOS via smtp; 29 Apr 84 20:14 EDT Date: Sun 29 Apr 84 17:07:30-PDT From: Mark Crispin Subject: redistribution lists To: MsgGroup@BRL.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) As the developer of one of the major Internet mailsystems which has redistribution-style mailing lists, I would like to comment on the recent exchange of messages regarding error reports and how they should be sent. I definitely sympathize with the people who have to pay for electronic mail messages. I would certainly agree that they have every reason to feel badly treated by being made to pay for zillions of mail failure notifications from some large mailing list. On the other hand, there is another side. Some of the mailsystems involved, mine included, behave the way they do for historical reasons. In particular, much of the code was written long before Return-Path and conventions such as "-REQUEST" existed. There are two issues involved. First is the support of null Return-Path. The TOPS-20 mailsystem literally cannot tell the difference between a null Return-Path and a non-existant Return-Path. The distinction is important; the former case means "errors should be discarded" and the latter means "errors should be send to the 'sender', an abstract entity which may ultimately be determined by parsing the message header." The result is the silly behavior of sending an error to a Mailer Daemon or other entity that specified it didn't want errors returns to it. This could be fixed, but it is non-trivial to do. Second is the official status of conventions such as "-REQUEST". Unfortunately, there are no printed standards which specify this sort of convention, merely folklore. It is very difficult for software developers to develop a portable product for a wide range of environments to deal in folklore for a single environment. More importantly, it is not at all clear to me how global "-REQUEST" is, or what the rules to determine its appropriateness. This is at least partially due to the many kinds of mailing lists which can exist and the hazy distinction between a "mailing list" and a "forwarding" which several mailsystems, TOPS-20 included, have. ------- 29-Apr-84 18:26:44-PDT,5678;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Sun 29 Apr 84 18:25:39-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 29 Apr 84 20:30 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 29 Apr 84 20:28 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2629585026599509@MIT-MULTICS.ARPA>; 29 Apr 1984 20:17:06 edt Date: 29 Apr 84 19:24 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, MAILNET_Postmasters%QZCOM.MAILNET@MIT-MULTICS.ARPA, Eng-Leong_Foo%QZCOM.MAILNET@MIT-MULTICS.ARPA To: MAILNET_Postmasters%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: Eng-Leong_Foo%QZCOM.MAILNET@MIT-MULTICS.ARPA bcc: msggroup@BRL.ARPA Subject: BIOENERGY 85 Message-ID: <53724@QZCOM> ********************************************************************** * Please make copies of the text below available to all researchers * * at your university who are involved with reseach in Biology: * ********************************************************************** Announcement by Eng-Leong Foo COMPUTER CONFERENCING ACTIVITIES ON BIOENERGY --------------------------------------------- Two computer conferences have been arranged from 15 June to 21 June 1984 during the Special Seminar on BIOENERGY IN DEVELOPING COUNTRIES (June 15-16) and the BIOENERGY 84 WORLD CONFERENCE AND EXHIBITION (June 18-21) at Gothenburg, Sweden. . AIMS The general aims of the Biogas and Bioenergy 84 Computer Conferences are: (a) to provide an additional communication technique to participants for their exchange of information, discussion of papers and posters, etc; (b) to allow the on-line participation of those who are unable to attend the face-to-face conferences at Gothenburg; and (c) to enable participants of the face-to-face conferences to acquaint themselves with computer conferencing techniques. . SCOPE The Biogas Computer Conference will primarily be a technical conference for the discussion of biogas papers and posters that are presented at the two face-to-face conferences. To participate, please join the teleconference "Anaerobic Digestion (MIRCEN)" in COM (QZ, Stockholm) or "Mircenet Newsletter" in EIES (U.S.A.). A preliminary list of participants who are presenting biogas papers or posters is available from the organizer and those who wish to participate on-line should obtain this list in order to request papers or posters (if available) from the authors. . The teleconference "Bioenergy 84" is intended for general communication and discussion of all other bioenergy related topics. It will also be available to exhibitors to make announcements about their products. "Bioenergy 84" will be available only in COM. . For questions concerning how to convert your personal computer into a communication terminal, COM's computer network account, and other technical communication information, please write to either: QZ computer Centre, Stockholm University, Box 27322, S 102 54 Stockholm, Sweden; or Computerized Conferencing and Communication Center, New Jersey Institute of Technology, 323 High Street, Newart, New Jersey 07102, U.S.A. . We look forward to your participation on-line. . Organizers: Biogas Computer Conference Bioenergy 84 Mr. Eng-Leong Foo Dr. Ingemar Falkehag Scientific Secretary S|dergatan 3A UNESCO/UNEP/ICRO S-462 00 V{nerborg Microbiological Resources Center Sweden Karolinska Institute Tel. 0521-13421 S-104 01 Stockholm, Sweden Tel. 08/340560 ext.1627 Eng-Leong Foo can also be reached via MAILNET, ARPANET, BITNET etc. as P2269%QZCOM@MIT-MULTICS.ARPA and via JNT-MAIL as P2269@QZCOM --------------------------------------------------------------- Comment by Jacob Palme: You can participate in these conferences in three ways: (a) Get an account in the EIES computer conference system in New Jersey. (b) Get an account in the COM computer conference system in Stockholm, Sweden. (c) Get all entries in the conferences sent via MAILNET to your personal mailbox in any mail system which can be reached via MAILNET, CSNET, ARPANET, BITNET, JNT-MAIL or USENET. If you prefer alternative (b) och (c) you must send a postal letter with your signature to Customer Registration, QZ Computer Centre, Box 27322, 102 54 Stockholm. Indicate if you represent a university or a public research institute, since this will give you lower rates. If you prefer alternative (c), be sure to indicate exactly your electronic mail address to reach you from either YORK (in the U.K.) or from MIT-MULTICS.ARPA (in the U.S.), in your letter to us. The charges in alternative (b) will be that you will have to pay the computer network costs to connect to QZ, plus a charge of about 0.20 US Dollars/read entry. The charges in alternative (c) will be 1-2 US Dollars per transmitted entry except for JNT-MAIL, where the charge will be half as much. These charges apply for universities. For public research, multiply by 1.6, for commerical users, multiply by 2.2. ----------------------------------------------------------------- Other conferences in COM at QZ which may be of interest in the biology field: Bioconversion planning (Closed) Bioconversion technical (Closed) MIRCENET NEWSLETTER (Open) Nitrogen fixation (Open) Computerized Communication in Life Sciences (Open) ANAEROBIC DIGESTION (MIRCEN) (Open) 29-Apr-84 20:26:26-PDT,3009;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Sun 29 Apr 84 20:24:17-PDT Received: From harvard.arpa.ARPA by BRL-MIS via smtp; 29 Apr 84 22:50 EDT Message-Id: <8404300256.AA05203@harvard.UUCP> From: lhasa!stew@Harvard.ARPA Date: 29 Apr 84 22:38 EDT To: harvard!msggroup@Brl-Mis.ARPA Subject: Non-deliverable messages Sending all the messages failing on a distributed mailing list should \not/, in my opinion, go back to either the real sender or the mailing list coordinator, unless there is no alternative. Coordinators of large mailing lists often have other things to do with their time. Making them worry about why some random mailbox two gateways and three redistributions down the line is not accepting mail at the moment is not really reasonable. I propose that the message be returned to the handling agent closest to the failing mailbox. This may be the postmaster at the destination site, or at a redistributing site, or it may well be the -REQUEST mailbox. The motivation is obviously that the closer to the failure we can hit, the more likely we are to find the responsible party. This scheme requires that every redistribution point put a Resent-From: or Redistributed-From: header line into the message. These would then be checked first for return addresses. The drawback here, of course, is that the delivery software would have to be changed to do this if it doesn't already. An alternative would be to have each redistributer make itself the Sender. This is, in fact, how I read RFC822, section 4.4.4: "The 'Sender' field mailbox should be sent notices of any problems in transport or delivery of the original messages. If there is no 'Sender' field, then the 'From' field mailbox should be used." There is also provision for a 'Resent-Sender' field. However, the standard does not dictate when a 'Resent-' address should be given precedence, only that it be 'more recent'. Ideally then, the field to use is 'Resent-Sender', which should be interpreted as the agent which most recently handled the message, and which, presumably, is related to the mechanism for storing the address which failed. So how do we implement this? In my case, as an example, MSGGROUP sends to MSGGROUP-INCOMING@HARVARD.ARPA which is an alias that includes, among other addresses, lhasa!msggroup-incoming. This sends mail via (pseudo-) uucp mail to my machine, lhasa, which has another alias. So when mail to my mailbox fails, the message should be returned to lhasa!postmaster. Since I \am/ lhasa!postmaster this will probably also fail, though! So it ought to go to the next most recent agent, harvard!postmaster. If anyone can show me how to mung sendmail config files to make this happen, I will see that you are canonized :-) Stew Rubenstein lhasa!stew@harvard.arpa {allegra!ima,ihnp4,decvax!genrad!wjh12}!harvard!lhasa!stew@UUCP Harvard Chemical Labs, 12 Oxford St., Cambridge, MA 02138 @ U.S. Mail 29-Apr-84 22:19:51-PDT,1793;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Sun 29 Apr 84 22:16:45-PDT Received: From simtel20.arpa.ARPA by BRL-MIS via smtp; 30 Apr 84 0:48 EDT Date: 29 Apr 1984 22:53 MDT (Sun) Message-ID: From: "Frank J. Wancho" To: lhasa!stew@Harvard.ARPA Cc: msggroup@Brl-Mis.ARPA Subject: Non-deliverable messages In-reply-to: Msg of 29 Apr 1984 20:38-MDT from lhasa!stew at Harvard.ARPA Stew, As a maintainer of several mailing lists, and the former maintainer of one very large list, I tend to agree with your approach, but only for two annoying classes of returned mail: Quota exceeded and the gratuitous Failed after n days, will try another m days (or equivalent). ALL other failed mail should be returned to the list maintainer at the -REQUEST address (and NOT to the maintainer of record). (All of the lists which originate on this host have a -REQUEST entry, which is, in turn, a two-entry mailing list: one entry for the maintainer and one to a special mail file set up to receive copies of such mail for subsequent processing. The first entry simply serves to notify the maintainer that there is a problem. Unfortunately, we do not yet have the facility that automatically inserts/replaces the Return-Path header item with the -REQUEST addresses for mail sent to these lists. I, for one, would welcome such a feature to lift it out of the "folklore" arena and made a standard... and it doesn't *have* to be set up as -REQUEST; it could be a single, specially prefixed extry in the list itself.) However, even with Return-Path, there are certain sites which ignore that entry and insist on returning mail to the originator of the message... --Frank 29-Apr-84 23:35:32-PDT,805;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Sun 29 Apr 84 23:34:02-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 30 Apr 84 2:02 EDT Received: From office-2.arpa.ARPA by BRL-AOS via smtp; 30 Apr 84 2:01 EDT Date: 29-Apr-84 22:58 PDT From: William Daul OAD / TYMSHARE / McDonnell Douglas Subject: Re: EIES NORMS To: Robert Elton Maas Cc: 114%NJIT-EIES.MAILNET@Mit-Multics.ARPA, MsgGroup@Brl-Aos.ARPA Message-ID: <[OFFICE-2.ARPA]TYM-WBD-4L1NN> In-reply-to: EXT-REM-4L153 I agree with Robert regarding giving senders "feedback" to their electronic contribution to either myself or mail groups. What I worry about is having thousands of people giving me "feedback"...oh well so far I am safe. --Bi<< 29-Apr-84 23:55:33-PDT,1114;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Sun 29 Apr 84 23:52:17-PDT Received: From harvard.arpa.ARPA by BRL-MIS via smtp; 30 Apr 84 2:11 EDT Message-Id: <8404300617.AA06341@harvard.UUCP> From: lhasa!stew@Harvard.ARPA Date: 30 Apr 84 02:09 EDT To: harvard!wancho@simtel20.ARPA, harvard!msggroup@brl-mis.ARPA Subject: RE: Non-deliverable messages RFC822 says that Return-Path is supposed to point back to the "originator", not to transport or redistribution agents... But I guess standards are there to be interpreted; certainly in this case we can "interpret" originator as the agent which caused this piece of mail to be sent to this address if that is the most useful. The problem is that RFC822 simply does not adequately address the concept of centrally-maintained mailing lists. This is certainly a topic for which a new RFC would be appropriate. Anyone want to get famous? Stew Rubenstein lhasa!stew@harvard.arpa {allegra!ima,ihnp4,decvax!genrad!wjh12}!harvard!lhasa!stew@UUCP Harvard Chemical Labs, 12 Oxford St, Cambridge, MA @ U.S. Mail 30-Apr-84 07:31:31-PDT,958;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 30 Apr 84 07:29:52-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 30 Apr 84 9:39 EDT Received: From brl-tgr.arpa.ARPA by BRL-AOS via smtp; 30 Apr 84 9:40 EDT Date: Mon, 30 Apr 84 9:32:16 EDT From: Ron Natalie To: Jacob_Palme_QZ%QZCOM.MAILNET@mit-multics.arpa, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@mit-multics.arpa cc: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@mit-multics.arpa, msggroup@brl-aos.arpa Subject: Re: Non-deliverable messages All the BRL based mailing lists (at least) already do this. We change the return path to the -REQUEST address for the list. Unfortunately there are other lists who don't do that. More regretfully, there are a few arpanet sites out there (line MIT) that throw away the return path and send back to the original sender. -Ron 30-Apr-84 09:01:19-PDT,795;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 30 Apr 84 09:01:05-PDT Received: From brl-tgr.arpa.ARPA by BRL-MIS via smtp; 30 Apr 84 10:17 EDT Date: Mon, 30 Apr 84 10:20:06 EDT From: Ron Natalie To: Frank J. Wancho cc: lhasa!stew@harvard.arpa, msggroup@brl-mis.arpa Subject: Re: Non-deliverable messages The RETURN PATH in SMTP is the argument to the MAIL FROM command. This should be set to FOO-REQUEST. The "RETURN-PATH" header line should not be inserted by the list people but by the person who removes the letter from the SMTP realm. The RETURN PATH (from MAIL FROM) should be changed into something answerable by the realm it is being forwarded into at that time. -Ron 30-Apr-84 11:34:03-PDT,1668;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 30 Apr 84 11:31:29-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 30 Apr 84 11:23 EDT Received: From bbnccd.arpa.ARPA by BRL-AOS via smtp; 30 Apr 84 11:21 EDT Date: Mon, 30 Apr 84 11:06:35 EDT From: Jon Solomon Subject: Re: redistribution lists In-Reply-To: Your message of Sun 29 Apr 84 17:07:30-PDT To: Mark Crispin Cc: MsgGroup@BRL.ARPA I don't believe that the mailsystem is responsible for inserting an appropriate return path or sender to force mail system errors to be returned to a specific mailbox. Using the digested lists as an example doesn't address the problems of immediate distribution lists returning errors to the sender of each message. Digested list maintainers can (and in most cases do) insert the return path for their lists because all the incoming mail goes out as the body of a message. The only part of a digest that a mail system cares about is the header. I distribute TELECOM, and all the errors from that list go to TELECOM-REQUEST (which is basically back to me). In the case of immediately distributed lists, some sort of filter mechanism must be inserted into the process of delivery to specify the correct return path/reply-to address. A mail system can support this sort of behavior by allowing the user to write the filter, and then run it over all mail going to a specific address. I believe this sort of filter mechanism is sufficiently useful that modifying the mailsystem to support it is possible without jeapordizing portability. I have spoken, --Jon 30-Apr-84 12:42:23-PDT,1729;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 30 Apr 84 12:41:28-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 30 Apr 84 14:58 EDT Received: From su-score.arpa.ARPA by BRL-AOS via smtp; 30 Apr 84 14:47 EDT Date: Mon 30 Apr 84 11:42:34-PDT From: Mark Crispin Subject: redistribution lists To: MsgGroup@BRL.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I might also add that an attitude which can be taken is that large redistribution lists are a luxury, that they have at best an indirect relationship to the purpose for which the US taxpayers pay for Internet, and that therefore the annoyance and inconvenience of the occasional failed mail message is the necessary price to pay for this luxury. For those on networks who pay charges for mail, their charges are small compared to what the US taxpayers pay for Internet, and that therefore it once again is the necessary price for electronic mail interaction with the Internet. I do not necessary agree with this attitude. Neither, however, do I necessarily disagree with it. I do, however, strongly disagree with the approach advocated by certain members of this list which states that the appropriate solution to the problem -- if it is a problem to be solved -- is technological. Many of the notorious examples of bad software design originates in the attitude that any problem should be fixed by adding a special-case heuristic. I personally favor a operational/comprehensive design approach and advocate adding heuristics only to match the design improvements. ------- 30-Apr-84 13:33:22-PDT,888;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 30 Apr 84 13:30:04-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 30 Apr 84 15:43 EDT Received: From usc-isif.arpa.ARPA by BRL-AOS via smtp; 30 Apr 84 15:38 EDT Date: 30 Apr 1984 12:34:51 PDT From: POSTEL@Usc-Isif.ARPA Subject: re: non-deliverable messages To: msggroup@Brl-Aos.ARPA The sending of a message to a mailing list like msggroup can be seen as a two step process. The first step is the sending of a single message from the author to a mailing-list service. The second step is the sending of many messages by the mailing-list service to the many subscribers to the mailing-list. Any error in the first step should be reported to the author. Any error in the second step should be reported to the manager of the mailing-list service. --jon. ------- 30-Apr-84 14:42:54-PDT,1385;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 30 Apr 84 14:39:19-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 30 Apr 84 17:09 EDT Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 30 Apr 84 17:09 EDT Date: 30 Apr 1984 16:43 EDT (Mon) Message-ID: From: David Siegel To: POSTEL@USC-ISIF.ARPA Cc: msggroup@BRL-AOS.ARPA Subject: non-deliverable messages In-reply-to: Msg of 30 Apr 1984 15:34-EDT from POSTEL at Usc-Isif.ARPA It would seem to me that this problem could be solved as follows: Have one internet host be a central mailing-list wide distribution center. All internet wide mailing-lists will have an address at that cite. (This also solves another common problem of not know where Info-So-and-so is located) The mail forwarding software at that cite can then be hacked to send all failed messages to info-so-and-so-request. If the load this would put on a particular host is too large, the central cite could forward the messages to other machines for redistribution. In addition, this central cite could have some kind of on-line package (like the NIC query system) to allow users to add and delete there names from any of this lists. This could all be done automatically, taking some of the load off the mailing list maintainer. 30-Apr-84 23:27:17-PDT,553;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 30 Apr 84 23:24:35-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 1 May 84 1:57 EDT Received: From xerox.arpa.ARPA by BRL-AOS via smtp; 1 May 84 1:49 EDT Received: from Gamay.ms by ArpaGateway.ms ; 30 APR 84 22:47:23 PDT From: DonWinter.pasa@XEROX.ARPA Date: 30 Apr 84 22:47:19 PDT Subject: Re: non-deliverable messages In-reply-to: POSTEL@USC-ISIF.ARPA's message of 30 Apr 84 12:34:51 PDT To: POSTEL@USC-ISIF.ARPA cc: msggroup@BRL-AOS.ARPA AMEN 1-May-84 23:38:52-PDT,1330;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Tue 1 May 84 23:37:18-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 2 May 84 2:07 EDT Received: From sri-nic.arpa.ARPA by BRL-AOS via smtp; 2 May 84 2:05 EDT Date: Tue 1 May 84 23:04:22-PDT From: David Roode Subject: redistribution lists To: MsgGroup@BRL.ARPA Location: EJ286 Phone: (415) 859-2774 If a mailsystem existed which treated mail to mailing lists (exploders) this way If mail is to mailing list then check for definition of delivery error mailbox corresponding to that mailing list and if found use it in the return path else use normal return path then a site could choose the type of treatment it desired for a particular mailing list by selecting whether or not to define the delivery error mailbox corresponding to that mailing list. For example, if the mail is sent to INFO-PASCAL, the site handling the exploding of INFO-PASCAL could control how the mailsystem prepared Return Paths for INFO-PASCAL by defining or not defining INFO-PASCAL-ERRORS appropriately. In no way need such a feature in a mailsystem FORCE a user of that mailsystem to divert delivery errors to a handler at that site rather than returning them to the submittor of the message. ------- 2-May-84 16:34:39-PDT,2350;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Wed 2 May 84 15:13:24-PDT Received: From seismo.arpa.ARPA by BRL-MIS via smtp; 2 May 84 17:46 EDT Return-Path: Received: by seismo.ARPA; Wed, 2 May 84 17:32:52 EDT To: MsgGroup@Brl-Mis.ARPA Posting-Version: version B 2.10.1 6/24/83; site ut-ngp.UUCP From: ut-ngp!werner@Seismo.ARPA Subject: Re: redistribution lists Message-Id: <568@ut-ngp.UUCP> Date: Tue, 1-May-84 11:23:26 EDT Received: by hou3c.UUCP; Tue, 1-May-84 20:25:42 EDT References: <522@hou3c.UUCP> In-Reply-To: <522@hou3c.UUCP> Organization: Comp. Center, Univ. of Texas at Austin < THE BUG IS DEAD !!! (rumour from a net-famous person) Reincarnating...> a) any delivery problems should go to the maintainer of the 'most recent' redistribution list and NOT TO THE SENDER. b) the delivery system which redistributes a 'broad-casted' article should NOT BE RESPONSIBLE to provide a return-path to the author. With the current incompatibility mess it is asking too much from the mailers to provide a path across 3 different nets and 5 different 'redistribution lists'. c) the author of an article should 'sign' his article, including some useful paths to his mail-box. d) NO ANONYMOUS messages. Either have another person post for you who vouches for the source, or post it as if you, yourself had another person asking you to post. That goes for kremlvax and moskvax, too. (which was a good joke, I'd like to hear more. Got 4.2 up yet??) The not-very-flexible-opinion of werner @ ut-ngp We do the thinking at tax-payers' expense at BIG-STATE-U the prototype under contract to EYE-BE-AM the first production model at BIG-$$$ salary for TI-EYE We become a partner to market an "improved version" for micros Then we find some venture capital and develop the definitive version, (luckily we NEVER signed any non-disclosure forms - we are too famous to be pushed into that) We either make it big, but get pushed out of the company because we have less than 50% of the shares, or we go broke .... both lead us to become a CONSULTANT to tell others how we wished we had done it ..... NEXT TIME, WE ARE GOING TO DO IT RIGHT ... FER SURE (famous last words) Gad, it feels like Monday ... 2-May-84 17:45:16-PDT,6627;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Wed 2 May 84 17:41:07-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 2 May 84 20:05 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 2 May 84 19:57 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2629842426591275@MIT-MULTICS.ARPA>; 02 May 1984 19:47:06 edt Date: 29 Apr 84 19:24 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, MAILNET_Postmasters%QZCOM.MAILNET@MIT-MULTICS.ARPA, Eng-Leong_Foo%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: MAILNET_Postmasters%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: Eng-Leong_Foo%QZCOM.MAILNET@MIT-MULTICS.ARPA bcc: msggroup@BRL.ARPA, msggroup@BRL.ARPA, Carl-Goran_Heden%QZCOM.MAILNET@MIT-MULTICS.ARPA, Anders_Elleg}rd%QZCOM.MAILNET@MIT-MULTICS.ARPA, Ingemar_Falkehag%QZCOM.MAILNET@MIT-MULTICS.ARPA, Hans_Egneus_G|teborg_U%QZCOM.MAILNET@MIT-MULTICS.ARPA, John_B._Black_Univ._of_Guelph%QZCOM.MAILNET@MIT-MULTICS.ARPA, Robert_Kokke_UNU%QZCOM.MAILNET@MIT-MULTICS.ARPA, J.Aman_%_EDXA_%QZCOM.MAILNET@MIT-MULTICS.ARPA, "Tom Jeffries-FPL" <483%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA>, "INT. DEVEL. RES. CENTRE" <291%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA>, "Murray Moo-Young" <604%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA>, "D. G. Howell" <367%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA> Subject: BIOENERGY 85 Message-ID: <53724@QZCOM> ********************************************************************** * Please make copies of the text below available to all researchers * * at your university who are involved with reseach in Biology: * ********************************************************************** Announcement by Eng-Leong Foo COMPUTER CONFERENCING ACTIVITIES ON BIOENERGY --------------------------------------------- Two computer conferences have been arranged from 15 June to 21 June 1984 during the Special Seminar on BIOENERGY IN DEVELOPING COUNTRIES (June 15-16) and the BIOENERGY 84 WORLD CONFERENCE AND EXHIBITION (June 18-21) at Gothenburg, Sweden. . AIMS The general aims of the Biogas and Bioenergy 84 Computer Conferences are: (a) to provide an additional communication technique to participants for their exchange of information, discussion of papers and posters, etc; (b) to allow the on-line participation of those who are unable to attend the face-to-face conferences at Gothenburg; and (c) to enable participants of the face-to-face conferences to acquaint themselves with computer conferencing techniques. . SCOPE The Biogas Computer Conference will primarily be a technical conference for the discussion of biogas papers and posters that are presented at the two face-to-face conferences. To participate, please join the teleconference "Anaerobic Digestion (MIRCEN)" in COM (QZ, Stockholm) or "Mircenet Newsletter" in EIES (U.S.A.). A preliminary list of participants who are presenting biogas papers or posters is available from the organizer and those who wish to participate on-line should obtain this list in order to request papers or posters (if available) from the authors. . The teleconference "Bioenergy 84" is intended for general communication and discussion of all other bioenergy related topics. It will also be available to exhibitors to make announcements about their products. "Bioenergy 84" will be available only in COM. . For questions concerning how to convert your personal computer into a communication terminal, COM's computer network account, and other technical communication information, please write to either: QZ computer Centre, Stockholm University, Box 27322, S 102 54 Stockholm, Sweden; or Computerized Conferencing and Communication Center, New Jersey Institute of Technology, 323 High Street, Newart, New Jersey 07102, U.S.A. . We look forward to your participation on-line. . Organizers: Biogas Computer Conference Bioenergy 84 Mr. Eng-Leong Foo Dr. Ingemar Falkehag Scientific Secretary S|dergatan 3A UNESCO/UNEP/ICRO S-462 00 V{nerborg Microbiological Resources Center Sweden Karolinska Institute Tel. 0521-13421 S-104 01 Stockholm, Sweden Tel. 08/340560 ext.1627 Eng-Leong Foo can also be reached via MAILNET, ARPANET, BITNET etc. as P2269%QZCOM@MIT-MULTICS.ARPA and via JNT-MAIL as P2269@QZCOM --------------------------------------------------------------- Comment by Jacob Palme: You can participate in these conferences in three ways: (a) Get an account in the EIES computer conference system in New Jersey. (b) Get an account in the COM computer conference system in Stockholm, Sweden. (c) Get all entries in the conferences sent via MAILNET to your personal mailbox in any mail system which can be reached via MAILNET, CSNET, ARPANET, BITNET, JNT-MAIL or USENET. If you prefer alternative (b) och (c) you must send a postal letter with your signature to Customer Registration, QZ Computer Centre, Box 27322, 102 54 Stockholm. Indicate if you represent a university or a public research institute, since this will give you lower rates. If you prefer alternative (c), be sure to indicate exactly your electronic mail address to reach you from either YORK (in the U.K.) or from MIT-MULTICS.ARPA (in the U.S.), in your letter to us. The charges in alternative (b) will be that you will have to pay the computer network costs to connect to QZ, plus a charge of about 0.20 US Dollars/read entry. The charges in alternative (c) will be 1-2 US Dollars per transmitted entry except for JNT-MAIL, where the charge will be half as much. These charges apply for universities. For public research, multiply by 1.6, for commerical users, multiply by 2.2. ----------------------------------------------------------------- Other conferences in COM at QZ which may be of interest in the biology field: Bioconversion planning (Closed) Bioconversion technical (Closed) MIRCENET NEWSLETTER (Open) Nitrogen fixation (Open) Computerized Communication in Life Sciences (Open) ANAEROBIC DIGESTION (MIRCEN) (Open) 5-May-84 20:25:42-PDT,1923;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Sat 5 May 84 20:21:38-PDT Date: 5 May 1984 19:24:32 PDT From: POSTEL@USC-ISIF Subject: RFCs 893, 894, and 895 Now Available To: Request-for-Comments-List: New Requests for Comments are now available from the Network Information Center in the directory at SRI-NIC.ARPA. RFC 893: Title: Trailer Encapsulations Author: S. Leffler & M. Karels Pages : 6 pathname: RFC863.TXT This RFC discusses the motivation for use of "trailer encapsulations" on local-area networks and describes the implementation of such an encapsulation on various media. This document is for information only. This is NOT an official protocol for the ARPA-Internet community. RFC 894: Title: A Standard for the Transmission of IP Datagrams over Ethernet Networks Author: C. Hornig Pages : 3 pathname: RFC894.TXT This RFC specifies a standard method of encapsulating Internet Protocol (IP) datagrams on an Ethernet. This RFC specifies a standard protocol for the ARPA-Internet community. RFC 895: Title: A Standard for the Transmission of IP Datagrams over Experimental Ethernet Networks Author: J. Postel Pages : 3 pathname: RFC895.TXT This RFC specifies a standard method of encapsulating Internet Protocol (IP) datagrams on an Experimental Ethernet. This RFC specifies a standard protocol for the ARPA-Internet community. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIF.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 7-May-84 06:56:06-PDT,2230;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 7 May 84 06:54:07-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 7 May 84 9:17 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 6 May 84 19:44 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2630187568170580@MIT-MULTICS.ARPA>; 06 May 1984 19:39:28 edt Date: 06 May 84 17:03 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, msggroup@BRL.ARPA, "Mark Crispin" Subject: redistribution lists Message-ID: <54328@QZCOM> In-Reply-To: <53863@QZCOM> @MIT-MULTICS.ARPA,@BRL-MIS:msggroup-request@BRL-MIS.ARPA @QZCOM:conference_153@ODEN.MAILNET Date: Sun 29 Apr 84 17:07:30-PDT From: Mark Crispin Second is the official status of conventions such as "-REQUEST". Unfortunately, there are no printed standards which specify this sort of convention, merely folklore. It is very difficult for software developers to develop a portable product for a wide range of environments to deal in folklore for a single environment... This shows that a good message exchange standard should certainly include concepts corresponding to the "-REQUEST" convention, that is they should include network mail operations to: - Automatically add yourself to a distribution list (the list manager or managing program can of course control who are allowed to make this operation on the list) - Automatically remove yourself from the list - Automatically add and remove other people remotely from the list (remote control of a distribution list via the network) this is useful when the controller of a main list wants to add or remove members from a sublist - Communicate in general with the list manager All the above operations, and many more, are covered by the GILT standard developed by a cooperation of institutes in nine European countries. 7-May-84 18:13:15-PDT,5715;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 7 May 84 18:11:11-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 7 May 84 20:42 EDT Received: From ucb-vax.arpa.ARPA by BRL-AOS via smtp; 7 May 84 20:42 EDT Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.27) id AA01016; Mon, 7 May 84 17:40:25 pdt Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.14.3/4.16) id AA10791; Mon, 7 May 84 17:40:50 pdt Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.16) id AA06491; Mon, 7 May 84 17:40:02 pdt Date: Mon, 7 May 84 17:40:02 pdt From: William C. Wells Message-Id: <8405080040.AA06491@ucbopal.CC.Berkeley.ARPA> To: info-nets%mit-oz@Mit-Mc.ARPA Subject: UUCP Mail Site Registry Cc: -%ucbopal.CC@Ucb-Vax.ARPA, Collection%ucbopal.CC@Ucb-Vax.ARPA, Data%ucbopal.CC@Ucb-Vax.ARPA, Regisrty%ucbopal.CC@Ucb-Vax.ARPA, UUCP%ucbopal.CC@Ucb-Vax.ARPA, msggroup@brl.ARPA From ksh@cbosgd.UUCP Wed May 2 18:57:16 1984 Newsgroups: net.mail Subject: UUCP data collection form Article-ID: net.mail/388 As you may have heard, Rob Kolstad and Scott Bradner are collecting data for an accurate network map (of uucp links: those across which mail can be passed). This map contains not only connections but also connection quality. The "quality" indicates about how long it takes correspondence to get from your site to the connected site. Our path-finding program will understand connections indicated by those sites that you call and that call you and deduce optimal routing functions from the "big picture". Send forms to ihnp4!convex!kolstad (Rob Kolstad) for a-m sites cbosgd!wjh12!map (Scott Bradner) for n-z sites p.p.s: There are more complex and accurate ways to specify your connection list. Let us know if you'd like the more complex directions. (If you know how to use pathalias, the complex way allows you to use the DAILY, HOURLY, DEMAND, arithmetic, and the like.) ############ How to make the network map correct for your site ######### Checklist: _____ 1. Fill in the "site information" below the dotted line with whatever info you wish to disclose to the public. Please don't include any secrets but do tell us as much as you can. (Don't worry about your latitude & longitude if you don't know them). _____ 2. Complete the "site connection" section. An example section for your site is enclosed -- it may even be correct. If not, try to find out to what sites your machine connects and how often. Make your entry similar to this one for harvard which includes the machines to which it talks and also the frequency of connection: # WJH12 wjh12 genrad(A), linus(B), mhuxi(B), foxvax1(B), vaxine(B), amd70(C) aunix = hscaunix aunix = HARVUNXA HarvNet = {wjh12, unixvax, aunix, bunix, littauer}:(LOCAL) BITNET(HARVUNIXW) fred@HARVUNIXW.bitnet --------------- Explanation of Harvard's entry: ----------------------- # Precede comments by a pound sign # # +--- Tabs before connected sites # v wjh12 genrad(A), linus(B), mhuxi(B), foxvax1(B), vaxine(B), amd70(C) # harvard talks to the six machines shown above. The parenthesized items are # the frequency of connection (the "routing cost") from this table: # NOTE: these sites call at these frequences even if they do not have # anything for the harvard site, do not include a site that calls you ONLY # when they have something for you # A 2 hours or less # B 12 hours or less # C One day or less # D One week or less # F Dead (never) { only used if you once talked to a site } # If your machine has aliases that many people know, list those alternate # names for your machine like this: aunix = hscaunix aunix = HARVUNXA # NOTE: the names on the LEFT must appear in a routing table somewhere, # the names on the RIGHT are the aliases and appear here ONLY. # If you have a local network, make an entry like the one below which uses # the colon (:) as its separator character for addresses like # foxvax1!wjh12!unixvax:ralph # +-- see the colon! # v HarvNet = {wjh12, unixvax, aunix, bunix, littauer}:(LOCAL) # Regular separator characters are: ! @ : . ^ % # Other characters may be used and must be quoted if used in the above context. # Put your sitename as the FIRST name in any network of which it is a part. # If you are a part of the BTL action network and call those 600 or so # sites on demand, include this line: BTLACTION # If you have access to other nets, please list the name of the net, your # machine's name on that net, # and the character (or a prototype address) you use to access the net, e.g.: BITNET(HARVUNIXW) % # or BITNET(HARVUNIXW) fred@HARVUNIXW.bitnet # PLEASE SEND A SEPARATE LETTER FOR EACH COMPUTER # My records for your computer (quite possibly with dummy frequencies) # are below: ----------- please cut here and return this form electronically ------------ =Name: framus =Machine Type/OS: VAX 11/780, 4.2BSD =Organization: Framus Zots, Inc =Contact Person: Ronald Reagan =Electronic-Addr: decvax!ucbvax!framus!rar =Phone: (800) 555-1212 =Postal-Address: 1600 Pennsylvania Ave, Washington, DC 12345 =Long/Lat Coors: =Comments: =Editor: Nancy Reagan, 5/2/84 = ================================================== # framus allegra(C), fortune(C), hplabs(C), ios(C), tymix(C), ucbvax(C) 7-May-84 22:26:53-PDT,1206;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Mon 7 May 84 22:25:59-PDT Date: 7 May 1984 21:28:47 PDT From: POSTEL@USC-ISIF Subject: RFC 904 Now Available To: Request-for-Comments-List: A new Request for Comments is now available from the Network Information Center in the directory at SRI-NIC.ARPA. RFC 904: Title: Exterior Gateway Protocol Formal Specification Author: D. Mills Pages: 30 pathname: RFC904.TXT This memo is the specification of the Exterior Gateway Protocol. This memo updates portions of RFC 888 and RFC 827. Anyone working on an implementation of the EGP should follow this specification. This RFC specifies an official protocol of the DARPA community for use between gateways of different autonomous systems in the ARPA-Internet. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIF.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 8-May-84 20:21:16-PDT,7371;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Tue 8 May 84 20:19:56-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 8 May 84 22:41 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 8 May 84 16:44 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2630347267618990@MIT-MULTICS.ARPA>; 08 May 1984 16:01:07 edt Date: 29 Apr 84 19:24 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, MAILNET_Postmasters%QZCOM.MAILNET@MIT-MULTICS.ARPA, Eng-Leong_Foo%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: MAILNET_Postmasters%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: Eng-Leong_Foo%QZCOM.MAILNET@MIT-MULTICS.ARPA bcc: msggroup@BRL.ARPA, msggroup@BRL.ARPA, Carl-Goran_Heden%QZCOM.MAILNET@MIT-MULTICS.ARPA, Anders_Elleg}rd%QZCOM.MAILNET@MIT-MULTICS.ARPA, Ingemar_Falkehag%QZCOM.MAILNET@MIT-MULTICS.ARPA, Hans_Egneus_G|teborg_U%QZCOM.MAILNET@MIT-MULTICS.ARPA, John_B._Black_Univ._of_Guelph%QZCOM.MAILNET@MIT-MULTICS.ARPA, Robert_Kokke_UNU%QZCOM.MAILNET@MIT-MULTICS.ARPA, J.Aman_%_EDXA_%QZCOM.MAILNET@MIT-MULTICS.ARPA, "Tom Jeffries-FPL" <483%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA>, "INT. DEVEL. RES. CENTRE" <291%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA>, "Murray Moo-Young" <604%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA>, "D. G. Howell" <367%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA>, T|nu_Spuhl_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, msggroup@BRL.ARPA, "Tom Jeffries-FPL" <483%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA>, "INT. DEVEL. RES. CENTRE" <291%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA>, "Murray Moo-Young" <604%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA>, "D. G. Howell" <367%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA>, ANAEROBIC_DIGESTION_%QZCOM.MAILNET@MIT-MULTICS.ARPA, MIRCENET_NEWSLETTER%QZCOM.MAILNET@MIT-MULTICS.ARPA, BIOENERGY_84%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: BIOENERGY 85 Message-ID: <53724@QZCOM> ********************************************************************** * Please make copies of the text below available to all researchers * * at your university who are involved with reseach in Biology: * ********************************************************************** Announcement by Eng-Leong Foo COMPUTER CONFERENCING ACTIVITIES ON BIOENERGY --------------------------------------------- Two computer conferences have been arranged from 15 June to 21 June 1984 during the Special Seminar on BIOENERGY IN DEVELOPING COUNTRIES (June 15-16) and the BIOENERGY 84 WORLD CONFERENCE AND EXHIBITION (June 18-21) at Gothenburg, Sweden. . AIMS The general aims of the Biogas and Bioenergy 84 Computer Conferences are: (a) to provide an additional communication technique to participants for their exchange of information, discussion of papers and posters, etc; (b) to allow the on-line participation of those who are unable to attend the face-to-face conferences at Gothenburg; and (c) to enable participants of the face-to-face conferences to acquaint themselves with computer conferencing techniques. . SCOPE The Biogas Computer Conference will primarily be a technical conference for the discussion of biogas papers and posters that are presented at the two face-to-face conferences. To participate, please join the teleconference "Anaerobic Digestion (MIRCEN)" in COM (QZ, Stockholm) or "Mircenet Newsletter" in EIES (U.S.A.). A preliminary list of participants who are presenting biogas papers or posters is available from the organizer and those who wish to participate on-line should obtain this list in order to request papers or posters (if available) from the authors. . The teleconference "Bioenergy 84" is intended for general communication and discussion of all other bioenergy related topics. It will also be available to exhibitors to make announcements about their products. "Bioenergy 84" will be available only in COM. . For questions concerning how to convert your personal computer into a communication terminal, COM's computer network account, and other technical communication information, please write to either: QZ computer Centre, Stockholm University, Box 27322, S 102 54 Stockholm, Sweden; or Computerized Conferencing and Communication Center, New Jersey Institute of Technology, 323 High Street, Newart, New Jersey 07102, U.S.A. . We look forward to your participation on-line. . Organizers: Biogas Computer Conference Bioenergy 84 Mr. Eng-Leong Foo Dr. Ingemar Falkehag Scientific Secretary S|dergatan 3A UNESCO/UNEP/ICRO S-462 00 V{nerborg Microbiological Resources Center Sweden Karolinska Institute Tel. 0521-13421 S-104 01 Stockholm, Sweden Tel. 08/340560 ext.1627 Eng-Leong Foo can also be reached via MAILNET, ARPANET, BITNET etc. as P2269%QZCOM@MIT-MULTICS.ARPA and via JNT-MAIL as P2269@QZCOM --------------------------------------------------------------- Comment by Jacob Palme: You can participate in these conferences in three ways: (a) Get an account in the EIES computer conference system in New Jersey. (b) Get an account in the COM computer conference system in Stockholm, Sweden. (c) Get all entries in the conferences sent via MAILNET to your personal mailbox in any mail system which can be reached via MAILNET, CSNET, ARPANET, BITNET, JNT-MAIL or USENET. If you prefer alternative (b) och (c) you must send a postal letter with your signature to Customer Registration, QZ Computer Centre, Box 27322, 102 54 Stockholm. Indicate if you represent a university or a public research institute, since this will give you lower rates. If you prefer alternative (c), be sure to indicate exactly your electronic mail address to reach you from either YORK (in the U.K.) or from MIT-MULTICS.ARPA (in the U.S.), in your letter to us. The charges in alternative (b) will be that you will have to pay the computer network costs to connect to QZ, plus a charge of about 0.20 US Dollars/read entry. The charges in alternative (c) will be 1-2 US Dollars per transmitted entry except for JNT-MAIL, where the charge will be half as much. These charges apply for universities. For public research, multiply by 1.6, for commerical users, multiply by 2.2. ----------------------------------------------------------------- Other conferences in COM at QZ which may be of interest in the biology field: Bioconversion planning (Closed) Bioconversion technical (Closed) MIRCENET NEWSLETTER (Open) Nitrogen fixation (Open) Computerized Communication in Life Sciences (Open) ANAEROBIC DIGESTION (MIRCEN) (Open) 9-May-84 10:48:03-PDT,1665;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Wed 9 May 84 10:47:40-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 9 May 84 13:22 EDT Received: From usc-ecl.arpa.ARPA by BRL-AOS via smtp; 9 May 84 13:09 EDT Date: 9 May 1984 10:02-PDT Sender: ESTEFFERUD@Usc-Ecl.ARPA Subject: BioEnergy Message Looping From: ESTEFFERUD@Usc-Ecl.ARPA To: msggroup@Brl-Aos.ARPA Message-ID: <[USC-ECL] 9-May-84 10:02:55.ESTEFFERUD> Hi All - We seem to have a loop in the BIOENERGY message. It seems to me to be entirely based at QZCOM, as I interpret the headers. The copies arrived here on Apr-29, May-2, & May-8, with new addresses appended to each prior message. I have informed Jacob Palme of the problem and I expect that he will fix it before any more copies escape his QZCOM system in Sweden. In the meantime, please just delete any additional copies you receive, rather than forewarding them to me, or complaining about them furter. At least, this is a slow moving loop, with about a week between repetitions. Also, I should note that announcements of this kind are frowned on in the ARPANET when they include requests or solicitations for funds in any way. And, BIO ENERGY is not even close to the announced topics of interest to the Msggroup audience. Thank you all for your kind patience and tolerance of the problems that we will encounter as we hook together our strange collection of networks around the world. To me, it is more important to get ourselves hooked together, than to avoid (at some high cost) all minor annoyances such as this BIOENERGY message. Best regards --- Stef 10-May-84 20:37:05-PDT,985;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Thu 10 May 84 20:36:20-PDT Date: 10 May 1984 19:41:23 PDT From: POSTEL@USC-ISIF Subject: RFC 899 Now Available To: Request-for-Comments-List: A new Request for Comments is now available from the Network Information Center in the directory at SRI-NIC.ARPA. RFC 899: Title: Requests for Comments Summary - Notes 800-899 Author: J. Postel and A. Westine Pages: 18 pathname: RFC899.TXT This memo is a slightly annotated lisy of the 100 RFCs from number 800 through 899. This is a status report on these RFCs. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIF.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 10-May-84 21:04:12-PDT,5293;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Thu 10 May 84 21:02:19-PDT Received: From seismo.arpa.ARPA by BRL-MIS via smtp; 10 May 84 23:29 EDT Return-Path: Received: by seismo.ARPA; Thu, 10 May 84 23:15:35 EDT To: MsgGroup@Brl-Mis.ARPA Posting-Version: version B 2.10.1 6/24/83; site deepthot.UUCP From: Julian Davies Subject: Re: New topic, name domains vs. IFIP "user-friendly" non-domain names Message-Id: <302@deepthot.UUCP> Date: Wed, 25-Apr-84 20:50:49 EST Received: by hou3c.UUCP; Fri, 27-Apr-84 09:47:38 EST References: <497@hou3c.UUCP> In-Reply-To: <497@hou3c.UUCP> Organization: UWO CS, London Canada ------------------------------------- From: REM@Mit-Mc.ARPA (Robert Elton Maas) Sender: ka@hou3c.UUCP (Kenneth Almquist) It has been suggested that the IFIP proposal would permit heirarchial domains of naming authority, but I fail to see it. Could somebody explain it to me? -------------------------------------- I wonder which version of the IFIP proposal you are looking at. The latest one I have is "A User-friendly Naming Convention for Public data Networks", Version 2, November 183, arising from the IFIP WG6.5 NASE Subgroup meeting, Ottawa, July 1983. The need is seen for the naming process to be 'user friendly'; that is it should not depend on knowledge of things which humans are unlikely to know routinely. Perhaps an important source of confusion would be to not distinguish between "names" and "addresses". Names are to be expressed in terms of things people can remember easily. Addresses on the other hand are 'machine-oriented'. The systems for identifying people in practically all current message systems, including the ARPAnet 'internet' style, are what would be called 'machine oriented' in this context. The domain names and host names appearing in addresses are closely tied to the hardware config- urations of the networks. It is anticipated that one of the purposes of the directories to be provided in future will be translating from 'names' to 'addresses'. As an example, my university has several machines with mail boxes and mail software; this is not unusual. My address would identify inter alia which machine *my* mail box is on, and which network(s) it can be reached by. My *name* however, would be something like (Canada, University of Western Ontario, Julian Davies) as a fairly minimal version, or I could be named by a more elaborate specification which also mentioned the Province, my department, and maybe a nickname or telephone number to be sure of avoiding ambiguity. The structure of *names* is defined, now, by a directed labelled graph structure. However, the structure is not arbitrary, and the First Guideline is: The dominant structure of the Graph should be hierarchical. That is, the graph will be 'almost' a tree. A tree would be a perfect hierarchy, but here we allow for some flexibility, that in some cases a person may be reachable via several different routes through the directory structure. For instance, it may be that multi-nationals such as IBM would be represented at the top level of the hierarchy, and someone in IBM Bulgaria (for instance) could be reached either starting with the Bulgaria National directory database, or with the IBM top-level database, in either case ending up looking in database provided by that particular organization. The graph also allows for certain links to 'skip a level'; but the graph should certainly be cycle-free. Someone who happens to know the *address* for a person (e.g. an internet address as they now exist) is free to use it. Some people might even remember X.121 numbers they way we have to remember telephone numbers, for a person's personal workstation. But the object is to provide a system at least as good as the telephone directory, and use the power of the computer to help people figure out how to contact each other when they do NOT know the particular networks etc that are involved. -------------------------------------------- After that is cleared up, perhaps we who have seen both the IFIP proposal and the Internet plan could discuss the differences and debate the merits? Personally I like the explicit heirarchial nature of the Internet plan, and would like something like that incorporated into the IFIP proposal, unless it's already there somewhere. -------------------------------------------- In short, the hierarchy is there, but disguised because that seems more likely to be useful. Especially when the message systems get really widespread. But the Differences between the Internet plan and the IFIP proposal are a result of one being a scheme for addresses and the other a proposal for names. The directories will mediate when required. In reality, the name form *has* to have a hierarchy somewhere, because it would be quite impractical otherwise to implement the directory servers. The database will be far too large to put all in one place, or to search without a good search strategy and indexing scheme (say, 10 or 20 years from now). Julian Davies UUCP !uwo!julian ENVOY DJ.DAVIES 10-May-84 22:50:09-PDT,1437;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Thu 10 May 84 22:50:04-PDT Date: 10 May 1984 21:13:57 PDT From: POSTEL@USC-ISIF Subject: RFC 905 Now Available To: Request-for-Comments-List: A new Request for Comments is now available from the Network Information Center in the directory at SRI-NIC.ARPA. RFC 905: Title: ISO Transport Protocol Specification (ISO DP 8073) Author: ISO Pages: 164 pathname: RFC905.TXT This is the current specification of the ISO Transport Protocol. This document is the text of ISO/TC97/SC16/N1576 as corrected by ISO/TC97/SC16/N1695. This is the specification currently being voted on in ISO as a Draft International Standard (DIS). This document is distributed as an RFC for your information only, it does not specify a standard for the ARPA-Internet or DARPA research community. Our thanks to Alex McKenzie of BBN for making this online version available. Please note the size of this document, the file contains 258,729 characters. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIF.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 14-May-84 22:48:42-PDT,3081;000000000001 Return-Path: Received: from BRL-MIS by USC-ECL; Fri 11 May 84 16:02:58-PDT Received: From mit-mc.arpa.ARPA by BRL-MIS via smtp; 11 May 84 18:11 EDT Date: 11 May 1984 17:56-EDT From: "Marvin A. Sirbu, Jr." Subject: Re: New topic, name domains vs. IFIP "user-friendly" non-domain names To: deepthot!julian@Seismo.ARPA cc: jbs@Mit-Xx.ARPA, MsgGroup@Brl-Mis.ARPA The domain style names are no more "addresses" than are IFIP style names. It is perfectly plausible for there to be domain style names of the form "Julian_Davies.University_of_Western_Ontario.Canada." All that is required is a top level domain named Canada that contains a subdomain named University_of_Western_Ontario, etc. This domain name would then map into a mail forwarder or host where you read your mail. The differences have to do not with what is a name and what is an address, but rather what is the object that the two types of names are in fact names of. Domain style names are names of host computers. IFIP style names are names of "User Agents" which are mail processes running on either a personal workstation or a shared host. To fully identify a mail process using domain style domains, one has to say something like, Davies@Julian_Davies.University_of_Western_Ontario.Canada in order to identify the process on the host Julian_Davies.University_of_Western_Ontario.Canada. The other difference has to do with attaching a specific semantics to the various components. In domain style names, there is no semantics associated with the subdomain University_of_Western_Ontario. In IFIP style names, this would be specified as a locale or an organziation. What is the value of specifying some semantics? It might make it easier to guess. It also forces databases to be organized by the particular semantics chosen, instead of whatever happened to be convenient. For example, there is no reason why Internet_protocol_czar.ARPA couldn't be a valid name for Jon's personal workstation; indeed this might even be a sensible thing to do from a Hamming code point of view if Jon gets lots of messages. The IFIP proposal doesn't provide a semantic category for Internet_protocol_czar and thus could not accept a name of that form. For implementation reasons, the semantic categories must be arranged in a hierarchy. This then leads to the requirement that the top layer in the hierarchy must have entries for ALL valid values of the next semantic level. This imposes constraints on the ability to agregate levels on the basis of administrative or operational performance reasons as opposed to for reasons of name structure. Thus, if semantic categories are country, city, address, person, that works fine for France.Paris.Kennedy_Blvd.John_Doe, but not for USA.Paris.Kennedy_Blvd.John_Doe, because you need another level of hierarchy -- State names -- to CONVENIENTLY disambiguate, at least in the US. Domain names give you more flexibility to define categories as you please. Marvin Sirbu 14-May-84 22:48:43-PDT,4180;000000000001 Return-Path: Received: from BRL-MIS by USC-ECL; Sun 13 May 84 17:42:41-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 13 May 84 20:03 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 13 May 84 19:58 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2630792591482569@MIT-MULTICS.ARPA>; 13 May 1984 19:43:11 edt Date: 07 May 84 08:38 +0200 From: Vilkko_Virkkala_KONE_OY_Helsinki%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Vilkko_Virkkala_KONE_OY_Helsinki%QZCOM.MAILNET@MIT-MULTICS.ARPA, Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: msggroup@BRL-AOS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Computer conferencing and creative decision making, a new Message-ID: <54372@QZCOM> aspect In January I wrote a paper on the above theme, sent a summary of it to this conference, and mailed copies of the full text to a few persons who asked for it. Recently a new aspect of the theme has appeared. As described in my January paper there is a great need to increase participation in the decision making process in most of our organizations. More participation seems to lead to better productivity, better work satisfaction, and even better health of the members of the organization. In my paper I saw two main obstacles to increased participation: - time needed in discussions - managers' learning habits It now seems that there may be a third one, too: health of the manager. Recently published studies at the University of Pennsylvania (see e.g. "The dilemma of excellence: how strategic decision making can kill you." in International Management, Apr.-84, or "Top decision makers - victims of their own competence" in Management Review Febr. -84) seem to indicate that good, very participative decision making can really kill the leader. These studies have shown that better managers are more "multidimensional", meaning that they can genuinely see the problem situation from many viewpoints and also integrate these viewpoints somehow in their decisions. Now, added participants in a decision-making discussion certainly bring added viewpoints in, and also require that their viewpoints should be observed in the decision. Otherwise their their presence is just lip-service to the participation idea. Thus added participation requires more "multidimensionality" from the leader. Unfortunately, according to the Pennsylvania studies, more multidimensional managers appear to have a greatly increased risk of coronary heart disease. As one of the articles says, "this link between excellence and disease is very disturbing, indeed." What is the reason to this? I'd like to throw in a wild guess, to at least open the discussion: that the reason is stress caused by a too difficult mental process. Imagine yourself in the situation that you have to play simultaneous blind chess against a few opponents. You have written, partly faulty notes, in the style "Queen in F7", and you have helpers who give you partly faulty descriptions of the situation in different corners, but you do not see the situation on a chessboard. You also know that you can win or lose millions in the game. There are persons who could do this very well, but I would feel greatly stressed. I would also be willing to find simplified strategies that would not make it necessary to consider the situation in every corner of the board. If the Pennsylvania findings are correct, then probably a number of different things should be done to lessen the stress on good managers. A few ideas are given in the articles, and I can imagine a few more. I also believe that tools, similar to the chessboard, that make complicated situations easier to grasp, can be useful in this respect. In my January paper I try to give some ideas about such tools to persons who have the possibility to develop them further. 14-May-84 22:48:45-PDT,4258;000000000001 Return-Path: Received: from BRL-MIS by USC-ECL; Mon 14 May 84 19:54:23-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 14 May 84 22:20 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 14 May 84 22:20 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2630887602779906@MIT-MULTICS.ARPA>; 14 May 1984 22:06:42 edt Date: 07 May 84 08:38 +0200 From: Vilkko_Virkkala_KONE_OY_Helsinki%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Vilkko_Virkkala_KONE_OY_Helsinki%QZCOM.MAILNET@MIT-MULTICS.ARPA, Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: msggroup@BRL-AOS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA bcc: "NifTAL MIRCEN Hawaii" <211%NJIT-EIES.MAILNET@MIT-MULTICS.ARPA> Subject: Computer conferencing and creative decision making, a new Message-ID: <54372@QZCOM> aspect In January I wrote a paper on the above theme, sent a summary of it to this conference, and mailed copies of the full text to a few persons who asked for it. Recently a new aspect of the theme has appeared. As described in my January paper there is a great need to increase participation in the decision making process in most of our organizations. More participation seems to lead to better productivity, better work satisfaction, and even better health of the members of the organization. In my paper I saw two main obstacles to increased participation: - time needed in discussions - managers' learning habits It now seems that there may be a third one, too: health of the manager. Recently published studies at the University of Pennsylvania (see e.g. "The dilemma of excellence: how strategic decision making can kill you." in International Management, Apr.-84, or "Top decision makers - victims of their own competence" in Management Review Febr. -84) seem to indicate that good, very participative decision making can really kill the leader. These studies have shown that better managers are more "multidimensional", meaning that they can genuinely see the problem situation from many viewpoints and also integrate these viewpoints somehow in their decisions. Now, added participants in a decision-making discussion certainly bring added viewpoints in, and also require that their viewpoints should be observed in the decision. Otherwise their their presence is just lip-service to the participation idea. Thus added participation requires more "multidimensionality" from the leader. Unfortunately, according to the Pennsylvania studies, more multidimensional managers appear to have a greatly increased risk of coronary heart disease. As one of the articles says, "this link between excellence and disease is very disturbing, indeed." What is the reason to this? I'd like to throw in a wild guess, to at least open the discussion: that the reason is stress caused by a too difficult mental process. Imagine yourself in the situation that you have to play simultaneous blind chess against a few opponents. You have written, partly faulty notes, in the style "Queen in F7", and you have helpers who give you partly faulty descriptions of the situation in different corners, but you do not see the situation on a chessboard. You also know that you can win or lose millions in the game. There are persons who could do this very well, but I would feel greatly stressed. I would also be willing to find simplified strategies that would not make it necessary to consider the situation in every corner of the board. If the Pennsylvania findings are correct, then probably a number of different things should be done to lessen the stress on good managers. A few ideas are given in the articles, and I can imagine a few more. I also believe that tools, similar to the chessboard, that make complicated situations easier to grasp, can be useful in this respect. In my January paper I try to give some ideas about such tools to persons who have the possibility to develop them further. 17-May-84 02:43:43-PDT,2409;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Thu 17 May 84 02:39:57-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 17 May 84 5:15 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 17 May 84 5:09 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2631084920646677@MIT-MULTICS.ARPA>; 17 May 1984 04:55:20 edt Date: 16 May 84 17:50 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA bcc: msggroup@BRL-AOS.ARPA, Computerized_Communication_in_Life_Sciences%QZCOM.MAILNET@MIT-MULTICS.ARPA, Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Interact 84: Human-Computer Interaction Message-ID: <55700@QZCOM> The first IFIP conference on human-computer interaction will take place at the Imperial College, London, United Kingdom, 4-7 September 1984. One-day tutorials on monday, September 3. TOPICS: Task analysis and system design, Modelling the user, Behavioural aspects of text editors, Behavioural methodologies - observations and experiments, Menu usage, Command interfaces and their use, Speech io, Advanced telephone systems, Aids for the disabled, Adaptive interfaces, Novel io, Input devices and comparisons, Documentation, manuals and on-line help, Language design, Tools and principles for dialogue design, Intelligent software aids, Novice and expert, Graphical interaction, Cad, Comprehension, Terminals and work places, Design guidelines, methods and tools, Visual and display characteristics, Design approaches, Training, Training new users, Evaluation - problems and methods, Evaulation studies, Electronic mail and computer conferencing, HF in the system r&d cycle, Organisation and social issues, Task allocation, Use of databases, Formal representations, User aspects, Knowledge based techniques. Registration fee bedore 31 july for members of IFIP UKL 140, for non-members UKL 175. Secretariat: Conference Services The Institution of Electrical Engineers Savoy Place London WC2R 0BL United Kingdom Telephone 01-240 1871 ext 222 Telex 261176 IEE LDN G 19-May-84 19:48:57-PDT,3558;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Sat 19 May 84 19:48:06-PDT Received: From seismo.arpa.ARPA by BRL-MIS via smtp; 19 May 84 22:22 EDT Return-Path: Received: by seismo.ARPA; Sat, 19 May 84 22:22:04 EDT To: MsgGroup@Brl-Mis.ARPA Posting-Version: version B 2.10.1 6/24/83; site deepthot.UUCP From: Julian Davies Subject: Re: New topic, name domains vs. IFIP "user-friendly" non-domain names Message-Id: <311@deepthot.UUCP> Date: Thu, 17-May-84 15:50:23 EDT Received: by hou3c.UUCP; Fri, 18-May-84 08:50:06 EDT References: <564@hou3c.UUCP> In-Reply-To: <564@hou3c.UUCP> Organization: UWO CS, London Canada I gather this is quite a controversial topic in some USA circles. A response to Marvin Sirbu, which doesn't claim to settle the question... Regarding the idea that the IFIP naming scheme identifies User Agents, which are 'mail processes' rather than some kind of arbitrary machine specifier... I do see the distinction between 'names' and 'addresses' as crucial to making sense of this. The Directory Service is supposed to provide a translation from 'names' to 'addresses'; The address will be something on the nature of a Session Service Access Point, and could be a process identifier or a specific machine address (e.g. X.121) with extra protocol identifier specifications. IFIP names do not (as yet) have an agreed format for being typed. The name Canada, University_of_Western_Ont, Julian_Davies is suposed to be something that is guessable and/or easy to remember. It is up to the directory server to remember that that name is associated with an address which currently could look like djmdavies%uwo-hobbit.MLNET@uwo.UUCP or 302031500076.FTMAIL.djmdavies {these are both slightly invented} or could be an .ARPA address, or something else which includes specific machine and userid codes. The point is not that my mailbox "process" floats around, but that other people don't need to remember exactly where it is. For users at MIT, IFIP names could look like USA, MIT, and never mind whether the mailbox is on MIT-MULTICS, or MIT-AI, or MIT-whatever (maybe somewhere down on a LAN). --------------- Domains regarded as not having specific semantics, or more precisely not having 'types', while IFIP name components are 'typed': This is a fair comment. I think only trying it out will settle the matter of what is "best", which presumably means easiest to manage and use. The IFIP name I quoted for myself should perhaps have been given as C="Canada", O="Univ of Western Ont", PN=("Julian", "Davies") to make the infrastructure clearer. Showing the types of the attributes or components involved means that the elements do not have to be given in any specific order, whereas the domain-oriented name/address makes order significant. It is a matter of personal taste perhaps. The typed structuring does lend itself to being represented within the scheme of X.409 (Presentation Transfer Syntax and Notation) for representing typed data structures in messages. Some people think that it will be easier for ordinary people to use. Anyone who does not like it could presumably keep on typing addresses directly, and ARPA-style domain-based names count as addresses in my view. A lot will depend on the quality of the user interfaces and of the directory service. UUCP: ..watmath!deepthot!julian 20-May-84 17:15:08-PDT,2427;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Sun 20 May 84 17:14:34-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 20 May 84 19:44 EDT Received: From usc-isif.arpa.ARPA by BRL-AOS via smtp; 20 May 84 19:33 EDT Date: 20 May 1984 16:33:02 PDT From: POSTEL@Usc-Isif.ARPA Subject: ARPA Domain Style Names vs. IFIP User Friendly Naming Convention To: msggroup@Brl-Aos.ARPA In my view the main difference between these systems can be found in the goals. The IFIP system is intended to be user friendly. I think that means the user gets lots of choices and the system will try to work with what ever the user enters. The IFIP system is discussed in the context of directory assistance. I think that this means the user gets to supply some facts about the person he is trying to reach and the system will search for the exact address. The ARPA system is intended to ease some administrative problems. It is not particularly "user friendly". It is assumed that the full correct exact name will be supplied and the appropriate information will be returned. (Except, that it may try to do name completion within limits, and with respect to a given context.) The ARPA system is discussed in terms of name to address translation. No generalized searching is required. It should be clear to anyone that what is a name and what is an address is not an issue. Just like programs and data, names and addresses depend on who is using them. You may think of some collection of statemens you wrote in Pascal as a program, but to the Pascal compiler it is just data. There may be an IFIP style directory assistance system where one enters a name (as a list of data-typed attributes) and gets back an address. It could be that in some cases the address returned is exactly the thing to enter into an ARPA style system (as a domain style name) to turn a host name into an ARPA-Internet address. I think the IFIP system is trying to solve a much harder problem than the ARPA system, and i think the IFIP system will be much harder and take much longer to implement than the ARPA system will. I believe that the IFIP system will provide a valuable service and i look forward to using it. I hope you will excuse me to do what i can to get the limited ARPA Domain Name system operating in the next few months. --jon. ------- 20-May-84 18:05:31-PDT,2150;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Sun 20 May 84 18:04:18-PDT Received: From mit-mc.arpa.ARPA by BRL-MIS via smtp; 20 May 84 20:29 EDT Date: 20 May 1984 20:28-EDT From: Robert Elton Maas Subject: Re: New topic, name domains vs. IFIP "user-friendly" non-domain names To: MsgGroup@Brl-Mis.ARPA In-Reply-To:deepthot!julian@seismo.ARPA Perhaps we shouldn't think in terms of a dichotomy between addresses and routes, nor even a trichotomy between names addresses and routes, but rather in terms of a whole continuem of names&addresses&routes from the most verbose nieve database query (even more verbose and/or sloppy than the IFIP proposal) to the most momentarily-optimum route. We can then think of a whole series of resolvers at each stage in this continuum, some of which are sticky (the answer is cached, like you jot down the phone number so you don't have to call 411 or 555-1212 again for the same number) while others are dynamic (it doesn't do much good to remember which IMP a packet passed through since due to varying loads the next packet may find that IMP constipated and take a more efficient route that avoids that IMP). Even stickiness may be a contimuum. Phone numbers change once every several years. Hops on USENET change every few weeks. Hops between Arpanet IMPs change on a minute by minute basis. Perhaps everything can be sticky for some time period, then recomputed after that? General database query: somebody who is interested in space exploration and has futuristic views, who has access to electronic mail. Unstructured name: Jerry Pournelle, science-fiction writer. IFIP name: Name=(Pournelle, Jerry), Country=USA, State=MA, City=Boston/Cambridge, Company=MIT, Dept=MC. Domain name: POURNE@MC.MIT.ARPA.DOD.USA Host address: ARPA 10.3.0.44 POURNE Possible route from here: DIALUP:(, Bell212, , PCNET), USER#10.0.0.11 IMP#11,56,43,32,2, 21,34,4,25,24,12,55,47,14,18,10,44 SERVER#10.3.0.44 RCPT:POURNE (Sorry of those hops are out of date, I have 1980 Arpanet directory) 24-May-84 06:48:42-PDT,2122;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Thu 24 May 84 06:45:37-PDT Received: From seismo.arpa.ARPA by BRL-MIS via smtp; 23 May 84 23:10 EDT Return-Path: Received: by seismo.ARPA; Mon, 21 May 84 13:53:00 EDT To: MsgGroup@Brl-Mis.ARPA Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Laura Creighton Subject: Re: redistribution lists Message-Id: <3885@utzoo.UUCP> Date: Sun, 20-May-84 19:01:58 EDT Received: by hou3c.UUCP; Mon, 21-May-84 16:23:58 EDT References: <533@hou3c.UUCP> In-Reply-To: <533@hou3c.UUCP> Organization: U of Toronto Zoology As long as people are thinking about *whom* to mail *what* to: Every so often I post something to unix-wizards. Every so often things do not go well. The last time I posted to unix-wizards, some site (I think it was BRL, but I could be wrong) which appears to be a critical path for many people was down. Very down. I received more than 300 messages saying that the mail was undeliverable. There would have been many fewer messages if it wasn't deemed fit to tell me that``Messaged failed after x days, trying for y more days '' or some such. It conceivably would have been useful to tell me ``problem suspected at BRL (if indeed that was the site)'', ONCE, but sending me the text of my message did not help much. I shudder to think of what would have happened if I had posted 4 or 5 articles to unix-wizards that week. I was the wrong person to send this stuff to. There wasn't a thing I could do, so I threw it all away. I also throw away messages that I receive which inform me that somebody who used to be on the mailing list no longer has an account. Something tells me somebody else would be a better person to inform. Laura Creighton decvax!utzoo!laura@berkeley -- Laura Creighton utzoo!laura "Not to perpetrate cowardice against one's own acts! Not to leave them in the lurch afterward! The bite of conscience is indecent" -- Nietzsche The Twilight of the Idols (maxim 10) 24-May-84 09:02:36-PDT,1427;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Thu 24 May 84 09:01:45-PDT Received: From usc-ecl.arpa.ARPA by BRL-MIS via smtp; 24 May 84 11:25 EDT Date: 24 May 1984 08:19-PDT Sender: ESTEFFERUD@Usc-Ecl.ARPA Subject: Re: redistribution lists From: ESTEFFERUD@Usc-Ecl.ARPA To: utzoo!laura@Seismo.ARPA Cc: MsgGroup@Brl-Mis.ARPA Message-ID: <[USC-ECL]24-May-84 08:19:43.ESTEFFERUD> In-Reply-To: <3885@utzoo.UUCP> The problem you cite is a very well know one, but knowing about the problem and eliminating it everywhere in the combined Internet are two very different things. We are now at the point where general discussions about the general case, without attaching specific details such as one of the returned messages, can only frustrate the lot of us who have been receiving these complaint messages for a very long time now. I think it must be about 3 years ago that we modified the BRL distribution system to insert a new Return-Path (which you should see in this message) to direct failure notices back to a BRL-list-maintainer. So, it seems to me that either you are citing a very old case, or you have a new case of some different kind of failure. It would be nice if you would send the relevant detailed information on your cataclismic case to postmaster@BRL so they might determine what you are so vaguely refering to. Thanks for trying to help! Stef 29-May-84 17:47:03-PDT,2107;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Tue 29 May 84 17:46:57-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 29 May 84 18:41 EDT Received: From usc-ecl.arpa.ARPA by BRL-AOS via smtp; 25 May 84 1:07 EDT Date: 24 May 1984 22:01-PDT Sender: ESTEFFERUD@Usc-Ecl.ARPA Subject: Re: redistribution lists From: ESTEFFERUD@Usc-Ecl.ARPA To: BILLW@Sri-Kl.ARPA Cc: msggroup@Brl-Aos.ARPA Message-ID: <[USC-ECL]24-May-84 22:01:11.ESTEFFERUD> In-Reply-To: <[SRI-KL]24-May-84 13:24:29.BILLW> Hi Bill --- You asked "What exactly does the BRL Mailer do?" Well, in a logical sense, it is not the Mailer at BRL that does it. It is a Distributor which is invoked when a mail item arrives for Distribution to a list that is stored at BRL by a list maintainer. The Distributor, acting as though it were a User Agent, with authority to modify the message in any way it sees fit, simply causes the Distributed copies to be given a specified Return-Path: field content. In the case of MsgGroup, this is: Return-path: It might be argued that this Distributor is in fact implemented as though it were a module of the Mailer, but logically speaking, it must be operating outside the authority of the mailer, else it should not be messing with the return path in this way. So, it is logical, as I see things, to consider it to be acting with the rights and privileges of User Agent, which acts on behalf of subscribers, to remail items received from contributors, who are assumed to understand that they are contributing to a quasi publishing operation which will broadcast their contribution to a list, and hopefully will buffer the contributors from failed mail notices resulting from failures beyond the Distribution point. It will be nice when all public distribution lists in the Internet operate in this manner. I understand that BRL uses this arrangement for all lists that the maintainer wishes to operate this way. It is a matter of individual maintainer's prerogatives to do so. Enough? Stef 29-May-84 18:15:52-PDT,1327;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Tue 29 May 84 18:13:37-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 29 May 84 18:55 EDT Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 27 May 84 16:15 EDT Date: Sun 27 May 84 16:14:14-EDT From: Greg Skinner Subject: redistribution lists To: msgroup@BRL.ARPA I often get upset when I send a message to a list such as human-nets, which occasionally has out-of-date addresses whose host machines may have crashed. I too, get messages such as ... foo at AMES-TSS: Message undeliverable for x days, will try for another y days In USENET, the user is able to "cancel" an article he posts. The cancellation is first done locally at his own site (the article is deleted from his local filesystem), then a control message is sent to all other machines to whom the poster's site talks to, instructing them to delete their received copy from their filesystems. And so on and so forth ... It would be a useful feature if at the redistribution point, a facility was enabled so that users could send a cancellation message instructing the host to dequeue the currently undeliverable messages. Greg Skinner ARPA: gds%mit-eddie@XX UUCP: ...decvax!genrad!mit-eddie!gds ------- 29-May-84 19:07:18-PDT,1086;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Tue 29 May 84 19:03:25-PDT Received: From brl-tgr.arpa.ARPA by BRL-MIS via smtp; 29 May 84 20:44 EDT Date: Thu, 24 May 84 20:23:43 EDT From: Mike Muuss To: Laura Creighton cc: MsgGroup@BRL-MIS.ARPA Subject: Re: redistribution lists BRL specificly adjusts the SMTP MAIL FROM field so that failure notifications from the Unix-Wizards list go to Unix-Wizards-Request. However, there are some sites (most notably the PDP-20 systems) which are "very clever", and discard the MAIL FROM field, and re-parse the header. If such a site has a "mail exploder" which further redistributes the Unix-Wizards mail, and there is a problem, they will return the messages back to the sender, rather than Unix-Wizards-Request. The 4.1 BSD (BBN) UNIX systems also exhibit this problem; 4.2's SENDMAIL seems to do it right. I doubt that we will ever get all the systems on the net to ever implement the specification correctly. -Mike