25-Feb-85 12:54:48-PST,135;000000000000 Date: 25 Feb 1985 12:25:28 PST From: msggroup-request@brl Subject: Survey of [ECLC]msggroup.2401-2500 To: msggroup@brl 25-Feb-85 14:05:03-PST,1602;000000000001 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Mon 25 Feb 85 14:03:18-PST Received: from mit-mc.arpa by BRL-AOS.ARPA id a000219; 25 Feb 85 16:43 EST Date: 25 February 1985 16:42-EST From: "Christopher C. Stacy" Subject: "Computer conferencing" To: Jacob_Palme_QZ%QZCOM.MAILNET@mit-multics.ARPA cc: MSGGROUP@BRL-AOS.ARPA In-reply-to: Msg of 25 Feb 85 17:56 +0100 from Jacob_Palme_QZ%QZCOM.MAILNET at MIT-MULTICS.ARPA When someone says "computer conferencing" to me, what usually comes first to mind is an interactive message system resembling a conference. One simple interactive system I am familiar with makes the communication very much lke a formal conference: participants may join the conference, there is a chairman, people may take or yield the floor, and so forth. The next thing that comes to mind is a system like the Multics conferencing system (I can't remember the name of the program). This is also a conference, but it is not really interactive. The last thing which comes to mind is a more sophisticated interactive system supporting multi-media such as TV, sound, and graphics. I don't know how far poeple have gone with such systems. When I hear "computer conferencing", I never think of mailing lists or bboards, since they lack the kind of structure I associate with the word "conference". How about "computer messaging system" to most generally describe the different interactive and non-interactive memo-like facilities, including the one I am using to send this message? Chris 25-Feb-85 15:48:56-PST,995;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Mon 25 Feb 85 15:48:13-PST Received: from ucb-vax.arpa by BRL-AOS.ARPA id a000769; 25 Feb 85 18:21 EST Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA08279; Mon, 25 Feb 85 15:15:17 pst Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.19/4.33.1) id AA16830; Mon, 25 Feb 85 15:20:33 pst Received: by ucbopal.CC.Berkeley.ARPA (4.19/4.33) id AA11989; Mon, 25 Feb 85 15:20:31 pst Date: Mon, 25 Feb 85 15:20:31 pst From: "William C. Wells" Message-Id: <8502252320.AA11989@ucbopal.CC.Berkeley.ARPA> To: CSTACY@MIT-MC.ARPA, Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Re: "Computer conferencing" Cc: MSGGROUP@BRL-AOS.ARPA I suggest "computer message system(s)" instead of "computer messaging system". I do not think there is a verb "to message" yet. Regards, Bill 25-Feb-85 23:10:18-PST,5192;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Mon 25 Feb 85 23:09:04-PST Received: from office-2.arpa by BRL-AOS.ARPA id a001829; 26 Feb 85 1:47 EST Date: 25-Feb-85 22:45 PST From: William Daul - Augmentation Systems - McDnD Subject: The Second International Symposium On Computer Message Systems Announcement To: WRS.TYM@OFFICE-2.ARPA, TDIR.TYM@OFFICE-2.ARPA To: ASD.TYM@OFFICE-2.ARPA, GNOSIS.TYM@OFFICE-2.ARPA To: RM.COR@OFFICE-2.ARPA, DCE.TYM@OFFICE-2.ARPA To: PAF.TYM@OFFICE-2.ARPA, LKW.TYM@OFFICE-2.ARPA To: {iosd.m/marvin}ONTYME@office-2.ARPA, CG.TYM@OFFICE-2.ARPA To: MSGGROUP@BRL-AOS.ARPA, INFO-NETS%MIT-OZ@MIT-MC.ARPA To: human-nets@RUTGERS.ARPA Message-ID: The following was reproduced (without permission) from an outline sent to the IFIP Working Group 6.5 members from: Ronald P. Uhlig Northern Telecom, Inc. 2100 Lakeside Boulevard Richardson, Texas 75081 USA If you are interested in submitting a paper, please send the proposed title and proposed authors to Mr. Uhlig, ASAP. Full papers for review will be require no later than 15 April 1985. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- The Second International Symposium On Computer Message Systems will be held in Washington, D.C., 4-6 September 1985. Since the first symposium, held in Ottawa, Canada in 1981, very significant progress has been made in the field of message systems. In 1981, IFIP Working Group 6.5 had just defined a basic mail/messaging model. The X.400 series of standards for Message Handling Systems (MHS), based on the IFIP Model, has now been developed by CCITT, and comparable standards have emerged from ISO. This has opened up the possibility of creating a worldwide network of interconnected message systems. Many new systems, both public and private have come into being since 1981, and the electronic mail industry is growing rapidly. On going work in IFIP, CCITT, ISO, and other bodies in Directory Services, Document Exchange, and other areas promise to make MHS and the new standards even more important in the future. Since we are now entering a new era in electronic mail, the time is right to hold a major international symposium on Message Systems. The purpose of the symposium is to exchange information, discuss technical, economic, and legal issues, and explore impacts of message systems on the people and organizations which use them. Papers are desired in the following topic areas: Interconnection of Computer Based Message Systems (CBMS) Interconnection of Public & Private Message Systems Interworking among systems following standards Interworking between existing systems and new systems Interworking of CBMS and Telematic Services Interworking with TWX/Telex and physical delivery Document & Message Architectures Document Structuring: Revisable forms and final forms Document Interchange & Document Content Conversion Message Exchange Protocols Message Content Protocols Voice Messaging Integrated voice and text messaging Multimedia CBMS Multimedia Message (Data, Voice and Image) Graphics vs. Facsimile in messages Multimedia Message Workstations Multimedia Message standards and protocols Interworking of multimedia systems with single media systems Multimedia message demands on subnetworks Message content conversion (voice<-->text) Use of MHS Standards as a Foundation for Other Services Message Systems as base for distributed office system applications Extensions to MHS, e.g. Conferencing, Electronic Publishing, Business Data Interchange ... Vertical CBMS Applications Industry specific standards Electronic Funds Transfer Applications in transportation, law, medicine and travel Directory Services, Naming and Addressing Public Policy Issues In Computer Messaging Privacy, Confidentiality, Authentication and Security Legal Status of CBMS Social and Behavioral Impacts of Message Systems Impacts on Developing Nations Corporate/Organizational Messaging Systems Multinational private message systems Internal corporate standards and strategy Efficiency and Cost/Benefit Impact on Administration and Management User Environment User Interface Issues Message Editing Messaging for the Handicapped Human Factors Integration with Office Automation Tools CBMS Implementations & Experiments Experiments and Evaluation of P1, P2, & P3 protocols New Products and Services CBMS as an Industry Microeconomics Macroeconomics Industry projections--domestic & international Other topics relevant to Computer Based Message systems will receive full consideration. PROGRAM CHAIRMAN: Ronald Uhlig -- USA PROGRAM VICE-CHAIRMAN: Richard Miller -- USA 26-Feb-85 00:08:24-PST,1625;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Tue 26 Feb 85 00:05:18-PST Received: from usc-ecl.arpa by BRL-AOS.ARPA id a001928; 26 Feb 85 2:46 EST Date: 25 Feb 1985 23:41-PST Sender: ESTEFFERUD@usc-ecl.ARPA Subject: Re: "Computer conferencing" From: ESTEFFERUD@usc-ecl.ARPA To: MSGGROUP@BRL-AOS.ARPA Message-ID: <[USC-ECL]25-Feb-85 23:41:39.ESTEFFERUD> In-Reply-To: <92645@QZCOM> Maybe "structured communications" or "structured mail" is what you are looking for in a name. We should not be confused by the fact that the first structured communications systems were called "conferencing systems" (which they did indeed resemble). The reality that I see is that EIES, COM, CONFER, PLANET, and others like them, happened to focus on the idea of facilitating group discussions, patterned after the notions of face to face group discussions, though conducted in an asynchonous mode. But, there are many other structured situations that depend on communications. Are you trying to encompass all of these others? Like military command? Or business transactions (order entry, time cards, et al). How about the Boss/Subordinate diad? Or the boss and two subordinate triad? Two bosses and two shared subordinates? How about other team oriented activities? (Anyone for Volley Ball?) This is an area that I have been trying to sneak up on for a long time now, like for years. Only minor progress so far. Somehow, ordinary mail is already a major chore to keep working, so there is little time left for the interesting problems. Cheers - Stef 26-Feb-85 00:40:34-PST,879;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Tue 26 Feb 85 00:36:57-PST Received: from sri-nic.arpa by BRL-AOS.ARPA id a001966; 26 Feb 85 3:19 EST Date: Tue 26 Feb 85 00:18:11-PST From: David Roode Subject: Re: "Computer conferencing" To: Jacob_Palme_QZ%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, MSGGROUP@BRL-AOS.ARPA In-Reply-To: Message from "Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA" of Mon 25 Feb 85 17:56:00-PST Location: EJ286 Phone: (415) 859-2774 Sometimes people understand what you mean if you refer to "Electonic Bulletin Boards," depending I think on their past exposure to hardcopy bulletin boards for venting opinions on issues. ------- 26-Feb-85 18:39:12-PST,941;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Tue 26 Feb 85 18:36:58-PST Received: from mit-multics.arpa by BRL-AOS.ARPA id a008226; 26 Feb 85 21:17 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2655770991596314@MIT-MULTICS.ARPA>; 26 Feb 1985 21:09:51 est Date: 26 Feb 85 22:58 +0100 From: Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Tommy_Ericson__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: "Computer conferencing" Message-ID: <93026@QZCOM> In-Reply-To: <92786@QZCOM> I share your views. "Computer messaging system" is pretty close to "Message handling system", but one could argue that that is already taken by X.400 in a way. Tommy 26-Feb-85 18:39:13-PST,1082;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Tue 26 Feb 85 18:37:33-PST Received: from mit-multics.arpa by BRL-AOS.ARPA id a008220; 26 Feb 85 21:16 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2655770959583567@MIT-MULTICS.ARPA>; 26 Feb 1985 21:09:19 est Date: 26 Feb 85 22:53 +0100 From: Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Tommy_Ericson__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: Re: "Computer conferencing" Message-ID: <93025@QZCOM> In-Reply-To: <26 FEB 1985 08:51:19 XACF03@CFGA> Well, I think that it is time to introduce a sister to all of the CAx family (CAD,CAM,CAI,..), namely >> CAC - Computer Aided Communication << "In the field of CAC, a certain focus has recently been put onto GROUP COMMUNICATION, its nature, value and problems." sounds nice to me. 27-Feb-85 00:47:48-PST,781;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Wed 27 Feb 85 00:43:21-PST Received: from usc-ecl.arpa by BRL-AOS.ARPA id a000302; 27 Feb 85 3:23 EST Date: 27 Feb 1985 00:18-PST Sender: ESTEFFERUD@usc-ecl.ARPA Subject: Re: "Computer conferencing" From: ESTEFFERUD@usc-ecl.ARPA To: MSGGROUP@BRL-AOS.ARPA Message-ID: <[USC-ECL]27-Feb-85 00:18:43.ESTEFFERUD> In-Reply-To: <93025@QZCOM> I have great trouble trying to think of any kind of computer use that involves communication, that would not be legitimaty included under "computer aided communication". All WP, for example. Reminds me of the famous quote: "Our PC 'talks to' {IBM,DEC,UNIX,...}. I keep seeing the lips move, but I don't hear much. Cheers - Stef 27-Feb-85 16:40:37-PST,1136;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Wed 27 Feb 85 16:40:10-PST Received: from csnet-pdn-gw by BRL-AOS.ARPA id a013613; 27 Feb 85 19:19 EST Received: from bostonu by csnet-relay.csnet id ah05985; 27 Feb 85 12:21 EST Received: from buenga (buenga.ARPA) by bu-cs.ARPA (4.12/4.7) id AA24116; Wed, 27 Feb 85 11:48:08 est Received: from BUCS20 by buenga with DECNET ; Wed, 27 Feb 85 11:47:57 EST Date: Wed 27 Feb 85 11:45:19-EST From: Phil Budne Subject: Re: "Computer Conferencing" To: msggroup%brl-aos%bu-cs@buenga A name that I like quite a bit is "Computer-Mediated Communication". I have seen it used in the book _Computer-Mediated Communication Systems_ by Kerr & Hiltz, 1982 Academic Press. Another is the article "Social Psychological Aspects of Computer-Mediated Communication" in the October 1984 issue of _American Psychologist_. Along with _The Network Nation_ these are the among best sources for information about Computer Conferencing (Computer-Mediated Communication). ------- 27-Feb-85 18:30:51-PST,2089;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Wed 27 Feb 85 18:30:41-PST Received: from uci-icse.arpa by BRL-AOS.ARPA id a014121; 27 Feb 85 21:01 EST Date: Wed, 27 Feb 85 11:23:23 EST From: "Thomas A. Moulton" <995%njit-eies.mailnet@uci-icsa.ARPA> To: msggroup-request@BRL-AOS.ARPA Subject: Computerized Conferencing Message-ID: Resent-To: msggroup@brl.ARPA Resent-Date: 27 Feb 85 17:57:35 PST (Wed) Resent-From: Einar Stefferud Received: from Localhost by UCI-ICSE; 27 Feb 85 17:58:29 PST (Wed) Here are some reactions to the usage of Computerized Conferencing -------------------------------------- M 15471 Charlton Price (Charlton,116) 2/26/85 11:14 AM L:5 KEYS:/CC/WHAT TO CALL IT/ A: 15454 To Arpanet via Tom Moulton: I like "computer-based communications" or "computerized information exchange" to cover conferencing, electronic mail, message systems, etc. Hello, Stef! Long time no talk.. Charlton Price (116 on EIES) M 15497 Roxanne Hiltz (Roxanne,120) 2/26/85 12:21 PM L:13 KEYS:/FOR YOU TO FORWARD TO EINAR ET. AL OR TELL ME HOW/ -------------------------------------- Einar-- structured communication is the closest of the suggestions in the group of messages I have seen on what to call "computer conferencing" to capture what I think is the essence of the idea. But the problem with that is it does not mention computers! You can have structured communications in face-to-face modes (eg, Robert's Rules of Order), in hand written modes (eg, Delphi structures), etc. What is wrong with the term I have been using lately, computer-mediated communication, as the most general term? It gets accross the idea of the computer playing an active role in creating a possible variety of structures. I then see mail systems, conferencing systems (for group discussions), BBoard systems, project management systems, etc. as sub-categories of the more general term. -------------------------------------- 27-Feb-85 21:00:18-PST,984;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Wed 27 Feb 85 20:57:39-PST Received: from usc-ecl.arpa by BRL-AOS.ARPA id a014501; 27 Feb 85 23:41 EST Date: 27 Feb 1985 20:36-PST Sender: ESTEFFERUD@usc-ecl.ARPA Subject: Re: Computerized Conferencing From: ESTEFFERUD@usc-ecl.ARPA To: msggroup@BRL-AOS.ARPA Message-ID: <[USC-ECL]27-Feb-85 20:36:33.ESTEFFERUD> In-Reply-To: The problem with all the names so far seems to be that they include too much, or too little, more or less. To review: We are talking about structured communications of some kind. The kind seems to be related to computer network mail, though some people would argue that networks are not a required ingredient. So, I will happily adjust my nomination to be "Structured Computer Mail" or "Structured Computer Network Mail" ... Everything else I have seen so far just does not convey anything to me. Enjoy! Stef 1-Mar-85 00:30:42-PST,2016;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Fri 1 Mar 85 00:30:36-PST Received: from uci-icse.arpa by BRL-AOS.ARPA id a001041; 1 Mar 85 2:56 EST EIES: Date: Thu, 28 Feb 85 11:42:53 EST From: "Martin R. Lyons" <991%njit-eies.mailnet@mit-multics.ARPA> To: msggroup@BRL-AOS.ARPA cc: Murray%njit-eies.mailnet@mit-multics.ARPA, Elaine%njit-eies.mailnet@mit-multics.ARPA, Roxanne%njit-eies.mailnet@mit-multics.ARPA In-Reply-To: Your message of Wed 27 Feb 85 11:45:19-EST Subject: Re: "Computer Conferencing" EIES: Message-ID: Date: 28 Feb 85 23:52:10 PST (Thu) Sender: stef@uci-icse.ARPA Received: from Localhost by UCI-ICSE; 28 Feb 85 23:54:11 PST (Thu) [This message has been edited by stef@uci to reformat long lones.] The authors of _Computer-Mediated Communications Systems_, Elaine Kerr and Roxanne Hiltz, as well as Murray Turoff, Director of the Computerized Conferencing and Communications Center are reachable via Mailnet at this site. CCCC operates the Electronic Information Exchange System (EIES), at the New Jersey Institute of Technology. EIES was the first computerized conferencing system of its kind. The net addresses for the authors mentioned above are: Murray Turoff Murray%NJIT-EIES.Mailnet@MIT-MULTICS.ARPA or @MIT-MULTICS.ARPA:Murray@NJIT-EIES.Mailnet Roxanne Hiltz Roxanne%NJIT-EIES.Mailnet@MIT-MULTICS.ARPA or @MIT-MULTICS.ARPA:Roxanne@NJIT-EIES.Mailnet Elaine Kerr Elaine%NJIT-EIES.Mailnet@MIT-MULTICS.ARPA or @MIT-MULTICS.ARPA:Elaine@NJIT-EIES.Mailnet ----- MAILNET: Marty@NJIT-EIES.Mailnet ARPA: Marty%NJIT-EIES.Mailnet@MIT-MULTICS.ARPA or @MIT-MULTICS.ARPA:Marty@NJIT-EIES.Mailnet USPS: Marty Lyons, CCCC/EIES @ New Jersey Institute of Technology, 323 High St., Newark, NJ 07102 (201) 596-2932 "You're in the fast lane....so go fast." 1-Mar-85 00:33:17-PST,5418;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Fri 1 Mar 85 00:32:53-PST Received: from uci-icse.arpa by BRL-AOS.ARPA id a001057; 1 Mar 85 3:05 EST EIES: Date: Thu, 28 Feb 85 11:53:00 EST From: "Martin R. Lyons" <991%njit-eies.mailnet@mit-multics.ARPA> To: msggroup@BRL-AOS.ARPA cc: Murray%njit-eies.mailnet@mit-multics.ARPA, Elaine%njit-eies.mailnet@mit-multics.ARPA, Roxanne%njit-eies.mailnet@mit-multics.ARPA Subject: Re: "Computer Conferencing" EIES: Message-ID: Date: 01 Mar 85 00:00:30 PST (Fri) Sender: stef@uci-icse.ARPA Received: from Localhost by UCI-ICSE; 01 Mar 85 00:02:35 PST (Fri) This is from Murray Turoff, director of CCCC @ NJIT: M 16296 Murray Turoff (Murray,103) 2/28/85 1:22 AM L:64 KEYS:/WHATS IN A NAME/ TO: (Group 98), (Group 10), W2vy [This message has been edited by stef@uci to reformat the long lines.] [It arrived here with no breaks in the paragraphs. ... Stef] A ROSE IS A ROSE There is a great tendency in the computer field to find a new name for what one is doing regardless of its roots. This helps to vendors to establish products as unique only to them and for claiming they are at the forefront. Hence there is a multitude of names in the literature to designate message systems and computerized conferencing systems. One recent example, perhaps the worse of late is the state of New Jerseys use of the word TELEMATICS to incorporate not only these systems but CAD/CAM as well. (one needs to recall that ATT consultants are heavily used in this state). To reiterate a point laid out quite well in our book (The Network Nation, hiltz and turoff, addison wesely 1978) the basic idea that is being talked about is "structuring communications" around the nature of the group and its application. There is the idea of designing for a group of people and to provide an appropriate structure. This idea has its roots in four application area where the first special systems were build. One area is some very early CAI work at Northwestern and Illinois where those working on such a system felt that communications among the students as a group or class were a very crucial addition to the process. Another area was the Delphi area viewed as a communication structuring process (see the Delphi Method, Linstone and Turoff, 1975). I put the first delphi conference system on the air in 1970. In the Delphi book are many possible communication structures which have not been implemented yet because they require graphics. Delphis were traditionally done and are still done by paper and pencil. Any of you who are students looking for projects will find lots of ideas in that book for systems that have yet to be built by anyone. The third area where the idea of structured communications evolved was in Englbarts work at SRI in the support of project groups and the joint creation of documents and reports. The fourth area was on-line gaming where the communication structure for a group was a game and they were all players. There was some early work on this on the JOSS system at RAND. I do feel the work on message systems has largely focused on the needs of the individual rather than the group and there are very significant design differences in trying to optimize one or the other. Also the message system philosophy is really the idea that there must be one perfect design that everyone will use rather than the multitude of tailored systems those of us in computerized conferencing systems believe are possible. A recent term that seems to have emerged in the arpa net community to include these systems is "collaborative work" systems. I think the term roxanne and I like and use about as often as we use computerized conferencing is "computer mediated communication systems". I think this term has become standard in IBM currenlty, while collaborative work systems seems to be the DEC standard. The term "assisted" really sounds more to me like a message system and I prefer the word "mediated" since it implies more in the way of structuring. I suggest that some of you new to this area or having had only experience with message system forms of networking go back to look at the Network Nation and some of the earlier references you will find there. Also, don't forget about the very rich literature in psychology and sociology on structuring group processes (e.g. Nominal Group Processes, etc.) I have a thesis student at the moment implementing a Zero Based Budgeting system as a "computer mediated communication system". In no way could one refer to that as a message system and make any sense. This is a Ph.D. in management he is doing and his sepciality is budgeting. ---- P.S. Author's Net address is Murray%NJIT-EIES.Mailnet@MIT-MULTICS.ARPA ----- MAILNET: Marty@NJIT-EIES.Mailnet ARPA: Marty%NJIT-EIES.Mailnet@MIT-MULTICS.ARPA or @MIT-MULTICS.ARPA:Marty@NJIT-EIES.Mailnet USPS: Marty Lyons, CCCC/EIES @ New Jersey Institute of Technology, 323 High St., Newark, NJ 07102 (201) 596-2932 "You're in the fast lane....so go fast." 1-Mar-85 14:25:46-PST,2110;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Fri 1 Mar 85 14:25:34-PST Date: 1 Mar 1985 11:09:58 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 939 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 939: Title: Executive Summary of the NRC Report on Transport Protocols for Department of Defense Data Networks Author: National Research Council Mailbox: herb@WISC-RSCH.ARPA Pages: 20 Characters: 43485 pathname: RFC939.TXT This RFC reproduces the material from the "front pages" of the National Research Council report resulting from a study of the DOD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4). The point of this RFC is to make the text of the Executive Summary widely available in a timely way. The order of presentation has been altered, and the pagination changed. This RFC is distributed for information only. This RFC does not establish any policy for the DARPA research community or the DDN operational community. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. 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. ------- 2-Mar-85 02:23:07-PST,3627;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Sat 2 Mar 85 02:19:45-PST Received: from usc-ecl.arpa by BRL-AOS.ARPA id a013233; 2 Mar 85 4:58 EST Date: 2 Mar 1985 01:56-PST Sender: ESTEFFERUD@usc-ecl.ARPA Subject: Re: "Computer Conferencing" From: ESTEFFERUD@usc-ecl.ARPA To: Murray%njit-eies.mailnet@mit-multics.ARPA Cc: msggroup@BRL-AOS.ARPA, 991%njit-eies.mailnet@mit-multics.ARPA Cc: Elaine%njit-eies.mailnet@mit-multics.ARPA Cc: Roxanne%njit-eies.mailnet@mit-multics.ARPA Message-ID: <[USC-ECL] 2-Mar-85 01:56:55.ESTEFFERUD> In-Reply-To: The message of 01 Mar 85 00:00:30 PST (Fri) from "Martin R. Lyons" <991%njit-eies.mailnet@mit-multics.ARPA> Hi Murray -- Thanks for reminding us. We always like to encourage new members of these discussion groups to do their homework. In keeping with this idea, I hope our new msggroup participants will make an effort to review the last 10 years of MsgGroup transactions (2500 pages in [ECLC] in which we have discussed many of the issues related to how we might be able to facililtate a vast array of different user agent (UA) services with a standard message transfer agent (MTA). There are other discussion groups' archives that might be reviewed, such as Header-People where the issues of RFC 733/822 were (too) thoroughly aired. I think Human-nets discussed these issues too. I also suggest that our readers review the seminal work of the IFIP 6.5 Systems Environment Group's work on the Mail System Model, which has led to adoption of the new CCITT X.400 structured mail standards which will surely support a wide variety of UA functions and services. I think that after such a review, we might all have a great difficulty agreeing with you that "..... the work on message systems has largely focused on the needs of the individual rather than the group and there are very significant design differences in trying to optimize one or the other. Also the message system philosophy is really the idea that there must be one perfect design that everyone will use rather than the multitude of tailored systems those of us in computerized conferencing systems believe are possible." Having been a participant in many of those discussions, I believe that "one perfect design" is the last thing most of us have been striving for, though I will not claim to speak for everyone. This idea was given up way back in 1976 after a spirited debate about what are the "essential" commands for a UA, though we did not know to call it a UA at that time. After that, we concentrated on the idea that whatever else a UA might do, it must be able to process information from others, and vice versa. The key word is "InterOperation". Anyway, I believe that structured communication tools will be much easier to build and operate in the network environment with the X.400 standards than without. I also belive (strongly) that structured communication system standards, if any are needed, must stand above and separate from the X.400 standards, and that implementation of structured communication tools should use the services of X.400 without violating the OSI concept of level separations, because violations hamper interoperation. Structured communication tools should use message services, but not be imbedded inside them. Let me ask -- Would you buy conferencing services from your favorite Post Office? Would you like to have your communication structures codified in USPS regulations? Enjoy -- Stef 4-Mar-85 08:59:07-PST,4347;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Mon 4 Mar 85 08:58:30-PST Received: from simtel20.arpa by BRL-AOS.ARPA id a008238; 4 Mar 85 11:25 EST Date: Mon 4 Mar 85 09:23:15-MST From: "William G. Martin" Subject: Re: "Computer Conferencing" To: ESTEFFERUD@USC-ECL.ARPA cc: Murray%njit-eies.mailnet@MIT-MULTICS.ARPA, msggroup@BRL-AOS.ARPA, 991%njit-eies.mailnet@MIT-MULTICS.ARPA, Elaine%njit-eies.mailnet@MIT-MULTICS.ARPA, Roxanne%njit-eies.mailnet@MIT-MULTICS.ARPA, WMartin@ALMSA-1.ARPA In-Reply-To: Message from "ESTEFFERUD@usc-ecl.ARPA" of Sat 2 Mar 85 02:56:00-MST Hi! Just to jump in with both feet... I find that my experience with the user-interface side of electronic message systems (since 1976 being an instructor and general trouble-shooter/problem-solver in message-related issues in this US Army activity) does support the contention that message systems ARE tailored to support the individual rather than the group (at least the systems we have had access to are that way). Maybe this is not the thrust of the argument, but it is one way of interpreting the statement. Message systems (I use the term to refer to the user-interface side of things, not the transmission processes) seem to be designed to function well in an ideal environment, where every individual has his/her own account or directory, where these people do their own mail-reading and processing, and where there are plenty of machine cycles and storage resources to support any need. When we actually implement these systems in the real, practical world, where we run into situations such as contracts or payment agreements arranged on a per-directory basis, which provides a financial incentive to limit the number of directories (and therefore share them), or where the procurement realities result in having to operate in environments with limited computer resources for long periods of time while awaiting the promised delivery of more machines or peripherals, where terminal access is not immediate or convenient for many people (which gives them less incentive to learn to use such message systems, or to remember any skills once learned, if they do not apply them often), or where individuals view message-reading as a task to be done by their clerical staff and not by themselves, then these systems' applicability diverges from the needs of the organization. This is a feedback loop, of course, and the more the systems are perceived as lacking utility, the less they are used, which actually decreases their utility, and so on... I've been a user of HERMES, TENEX MSG, UNIX msg, MM, and a couple other mail interfaces on and off for nearly a decade. All have good points, and can provide adequate user support for most requirements, as long as they are operated in the ideal environment I mentioned above. As soon as you begin to impose practical restrictions (the kinds of things you run into anywhere, not bizarre or unusually arbitrary rules or policies), the user runs into difficulties and anomalous behavior on the part of the software, which makes functioning in the given environment difficult. For example, to take a simple and basic need: I don't know of a message system that supports office mail-handling well -- a situation where any of several clerical employees would be authorized to retrieve newly-arrived mail, distribute it or circulate it as appropriate, file or process it according to instructions from personnel in the office, and generally act upon it the same as they would for paper documents, while at the same time maintaining a level of security or privacy that would prevent unauthorized access by personnel either in or out of that office, and yet would make provisions for continued operations while all these clerical types are out sick, on vacation, replaced by temporaries, etc. This is a common office requirement; every mail system I know of breaks down somewhere in that scenario, especially if you are operating under security regulations restricting password sharing. Well, I think I've gone on too long on what is probably a side issue. It is something I deal with daily, though, and I guess I've been sensitized to it. Regards, Will Martin ------- 4-Mar-85 15:36:57-PST,11751;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Mon 4 Mar 85 15:35:10-PST Received: from office-2.arpa by BRL-AOS.ARPA id a001653; 4 Mar 85 17:59 EST Date: 4-Mar-85 14:55 PST From: Duane Stone / Augmentation Systems Div / MDC Subject: Re: "Computer Conferencing" To: "William G. Martin" Cc: ESTEFFERUD@USC-ECL.ARPA Cc: Murray%njit-eies.mailnet@MIT-MULTICS.ARPA Cc: msggroup@BRL-AOS.ARPA, 991%njit-eies.mailnet@MIT-MULTICS.ARPA Cc: Elaine%njit-eies.mailnet@MIT-MULTICS.ARPA Cc: Roxanne%njit-eies.mailnet@MIT-MULTICS.ARPA Cc: WMartin@ALMSA-1.ARPA Message-ID: In-reply-to: EXT-WMartin-1VPG3 Message from "ESTEFFERUD@usc-ecl.ARPA" of Sat 2 Mar 85 02:56:00-MST Comment: normally a reader-only of the MSGROUP, but also having 2 feet, decided to jump in. Will -- by no means are your observations / complaints a "side issue". As 'office support' tools in general (and electronic mail in particular) move from focus on individuals, to groups, to organizations they will have to evolve to deal with the 'real' business world. I used to use those mail systems you mentioned until about 3 years ago -- so I don't know how they may have evolved since then -- but I can relate how we have met some of the problems you mentioned (and others which will be discovered) within the AUGMENT environment (AUGMENT originated with Engelbart & group at SRI, then moved to Tymshare, now at McDonnell Douglas). Identifying "users" An identification system(s) is needed which uniquely encodes different kinds of 'mail-addresses' for an organization and relates these to directories. It should operate over any number of hosts to minimize problems associated with moving groups of users for contractual or load-balancing reasons -- and multiple identification systems should be able to operate on a single host. The job of updating the identification system is given to privileged system-admin people who can authenticate/validate changes. Some of the classes of mail-addresses ("idents") we've found useful are: Individual -- one per real-live person. Role -- associates one or more individual idents with the role ident. List -- a list of addresses that crosses identification system boundaries. Process -- a program that further processes any mail-items delivered to it. Group -- arbitrary subsets of any of the above; groups can also contain group-idents. (synonyms should be allowed for any of the above) Multiple users per directory More than one individual ident can be associated with a directory. A common login name and password is shared for a directory. However, before entering AUGMENT and accessing it's mail system, the user must provide her/his ident. Separate mail-boxes, mail-files and mail-profiles are available for each ident. In addition to normal operating system file protection, access to the mail-files may be limited by placing a list of user idents in the first statement in the file... so the file protection may be as open or as closed as the individual wishes (or office policy dictates). There is no protection against someone who is sharing a directory from using another's ident if they know it. The 'office' mailbox A directory (normally files-only -- i.e., can't log into it) and Role-ident is set up for the office. If the boss of the office does not want to deal with the mail system her/himself, one or more people (assistant, administrator, clerk, secretary) is delegated the responsibility. Their idents are associated with the role-ident. The individual logs in to her/his private directory, gives an Act Role command, and if the individual-ident is associated with the role-ident AND the user knows the password of the office directory, they can pick-up, answer, send, file, etc. the office mail. Any mail sent will say From: ROLE-IDENT and Sender INDIVIDUAL-IDENT. When finish acting in that role, the user gives the Act Self command, the office mail file updated, and s/he will be free to do her/his own thing. Up and down the 'chain-of-command' In most/many organizations, official correspondence doesn't go outside the organization without first being reviewed by several levels in the organization... with each level wanting to polish it a bit more before it's seen by their superiors. The routing is often pre-determined within the organization. In this case the 'normal' broadcast mode of electronic mail is not appropriate. So we have a delivery specification that says 'route it through the following addresses in-turn'. Each recipient may edit the body of the mail-item (a record is kept on who last changed which paragraphs when) and then use a command to pass the item on to the next address in the list. Comments may be appended to the message before it is passed, but the routing list cannot be changed. The originator may specify his/her ident in the Cc: field to get a copy of the item each time it is passed -- this provides the originator a means of tracking the item as it progresses through the organization. Permanent Records of Mail-items Electronic mail systems that assume the individual is 'in-charge' may leave the filing and ultimate disposition of mail-items up to the individual. Organizations like to have a "corporate knowledge base" evolve from the work done by individuals. This suggests some central library where all "important" items are permanently recorded, assigned a number, and indexed by such things as title-word, date, author, key-word, etc. There should be a facility to relate a document to other documents in the library with such tags as: Part-of:, Addendum-to:, In-reply-to:, Supercedes: ... Submission of a message/file to the library should be simply an alternate delivery specification for mail (with private or public access specified by the user) with a reference delivered to the user containing a pointer to where the file is located in the library. As in the case of identification systems -- a library should be able to operate over a number of hosts and more than one library on any given single host. Automatic archival based on frequency of access is helpful in keeping on-line library files from getting out of hand, but should be coupled with automatic retrieval, should a user wish to access an archived document. A search facility is needed to allow retrieval of documents containing a particular string in a particular field (and boolean combinations thereof). "Important" depends on the organization. There are some organizations that just have a policy that says the originator is responsible for determining which things should be submitted to the library. Others will argue that a document only becomes 'worthy' of permanent recording when it is signed -- and have decreed that the system will automatically submit something to the library when it receives an electronic signature (another requirement if electronic mail is to be used for official business). Others feel that each version of the document and any/all comments made on it are worthy of recording so a history is maintained. "Permanent" also depends on the organization. Most (government) organizations have inherited elaborate regulations on how to dispose of paper documents... if it falls into a certain class, throw it away in 2 years, if another retain it for 5 years, if another retain it for 10 years then send it to the National Archives, etc.. They are reluctant to abandon these rules completely (even tho the next 100 years of their output could be contained on a few optical disks). So it's necessary to develop some kind of retention code (which can be changed at a later date) associated with each library document to indicate how long the document can be retained in the library before it is purged or disposed of in another manner. Interfaces to other Mail Systems One should assume there will be other mail systems in use within any given organization, often developed before (or without reference-to) domestic or international standards. The user should not have to deal with the idiosyncrasies of each. At the most, the user should only have to provide a different style of address to have mail delivered to an address in a 'foreign' mail system -- i.e., all the usual commands and procedures to send, answer, forward, file, etc. mail should be those of the 'home-base' mail system; any translations required to/from foreign mail systems should be done transparently to the user to the degree possible. Interfaces to other Organizational Support Systems If an electronic mail system is not closely coupled with a decent "word processing" / "document production" system, it's use in the organizational setting will be limited. Most (all?) organizations do not live in an on-line-only environment. They receive paper as input -- they generate a lot of paper as output. The input side (computer aided processing of images, voice, fax) is just beginning to emerge and it's not at all clear (to me) how systems will evolve to take advantage of this. The output side (at least for text and simple graphics) has been with us for some time. Organizations are well aware of the capabilities of SOTA word processors and to some extent of output attainable from COM and laser printers. I'd argue that if you give them EMACS or XED (by way of example only!) as the mail editor/formatter tools associated with the electronic mail system that it will never gain enough acceptance to be used on a wide-scale organizational basis. But more to the point -- as Calendar, Suspense, Project-Management, ... tools move into the organizational environment, a tight coupling between them and the mail system seems desirable. That is, if there is a change in the due-date for a suspense item, those affected should be automatically be notified by mail -- likewise for an appointment (Calendar) or milestone (Project-Management)... and any Reminders attached to mail-items generated by these tools should be automatically updated. Such tools can make use of the Process-ident mentioned earlier to provide this coupling, and should operate, as the ident system and the library -- in a multi-host environment -- transparent to the user. To summarize this rather long-winded message -- I think Will has hit on a number of those issues that will make a real difference in whether electronic mail systems have a REAL impact on large organizations. Whether we call it Computer/Electronic Aided/Mediated/Mangled Communication/Conference/Mail/Message {System} will have little impact (I suspect) on the rate at which the technology is integrated into the working life of an organization (whose mission in life has nothing to do with 'pushing' computers). Attention to the issues of applying 'it' to business and government organizations just might have an impact. Opinions are my own, etc. etc... Stoney 4-Mar-85 21:37:46-PST,1537;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Mon 4 Mar 85 21:35:02-PST Received: from mit-multics.arpa by BRL-AOS.ARPA id a000175; 5 Mar 85 0:04 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2656293264398349@MIT-MULTICS.ARPA>; 04 Mar 1985 22:14:24 est Date: 04 Mar 85 03:21 +0100 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: Re: "Computer Conferencing" Message-ID: <93815@QZCOM> In-Reply-To: <[USC-ECL] 2-Mar-85 01:56:55.ESTEFFERUD> The best thing in the X.400 standards about group communication is that it says nothing at all about this, and thus does not prejudge the field with some half-baked solution. The worst thing in the X.400 standards for group communication is that it does not contain two very essential things: (a) Indication in the message header of whether an incoming message was distributed to a UA via some kind of group communication entity (mailing list or whatever). (b) Mandatory globally unique IPMessageID-s. These are two VERY serious deficiencies in X.400, so I cannot agree with the statement that X.400 is a good basis for introducing group communication. But of course we will have to use what we have, whether we like it or not! 6-Mar-85 17:49:17-PST,2426;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Wed 6 Mar 85 17:49:11-PST Received: from mit-multics.arpa by BRL-AOS.ARPA id a015319; 6 Mar 85 20:25 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2656459044993457@MIT-MULTICS.ARPA>; 06 Mar 1985 20:17:24 est Date: 06 Mar 85 18:09 +0100 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: Re: "Computer Conferencing" Message-ID: <94423@QZCOM> In-Reply-To: Some people believe in the idea of modelling electronic office systems after manual office systems, with electronic ledgers, drawers, waste baskets etc. This may make the computer less frightening to some people, but it is important to realize that electronic communication has special, different properties and that equating it too much with manual communication modes may lead to false conclusions. Some of the differences in the electronic world are: - People tend to distribute the same information to much more people when they use electronic than when they use manual methods, because the cost and effort of sending copies to more people or to mailing lists/conferences are so small. - Some systems develop sophisticated facilities for sorting the unread messages for a user and giving him control of what to read when and even what to skip without reading. - The average reading time is very low (in COM less than 30 seconds/ message) indicating that many people skip messages of less interest. This means that you are not with electronic media so afraid of sending a message to many people, since you know they can skip it very fast if they are not interested. - Special ethics and conventions tend to develop. - A very important technical property of computers is to allow handling of "hypertext" - e.g. references between messages, storing the same message at many places without really copying it, operating on all instances of a message at all places by one single command. Office systems which map manual system concepts onto computers sometimes forget the new possibillities that this gives. 14-Mar-85 00:42:55-PST,868;000000000000 Return-Path: Received: from BRL-HEP (for BRL-AOS) by USC-ECLC; Thu 14 Mar 85 00:41:10-PST Received: from wisc-rsch.arpa by BRL-AOS.ARPA id a015421; 14 Mar 85 3:13 EST Received: by wisc-rsch.arpa; Thu, 14 Mar 85 02:12:11 cst Received: by maccunix.UUCP (4.12/4.7) id AA16581; Wed, 13 Mar 85 22:53:05 cst Date: Wed, 13 Mar 85 22:53:05 cst From: Jeff Myers Message-Id: <8503140453.AA16581@maccunix.UUCP> To: uwvax!msggroup@BRL.ARPA Subject: list add... Please add me to your mailing list. thanx, jeff m -- Jeff Myers The views above may or may not University of Wisconsin-Madison reflect the views of any other Madison Academic Computing Center person or group at UW-Madison. ARPA: uwmacc!myers@wisc-rsch.ARPA UUCP: ..!{ucbvax,allegra,heurikon,ihnp4,seismo}!uwvax!uwmacc!myers 19-Mar-85 11:25:57-PST,1831;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Tue 19 Mar 85 11:25:17-PST Date: 19 Mar 1985 09:43:09 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 942 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 942: Title: Transport Protocols for Department of Defense Data Networks Author: National Research Council Mailbox: Jerome@WISC-RSCH.ARPA Pages: 88 Characters: 222477 pathname: RFC942.TXT This RFC reproduces the National Research Council report resulting from a study of the DoD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4). This RFC is distributed for information only. This RFC does not establish any policy for the DARPA research community or the DDN operational community. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. 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. ------- 23-Mar-85 04:16:15-PST,1924;000000000000 Return-Path: Received: from BRL-AOS (for BRL-AOS) by USC-ECLC; Sat 23 Mar 85 04:14:56-PST Received: from csnet-pdn-gw by BRL-AOS.ARPA id a012639; 23 Mar 85 6:56 EST Received: from bostonu by csnet-relay.csnet id af04269; 23 Mar 85 6:40 EST Received: from buenga (buenga.ARPA) by bu-cs.ARPA (4.12/4.7) id AA05427; Fri, 22 Mar 85 23:04:02 est Received: from BUCS20 by buenga with DECNET ; Fri, 22 Mar 85 23:01:16 EST Date: Fri 22 Mar 85 23:02:20-EST From: Phil Budne Subject: Volunteers Needed. To: MsgGroup%BRL@buenga I am currently involved in an independent undergraduate project to assess how use of computers for communication compares with more traditional communication media. I currently am looking for volunteers who feel they are "addicted" to use of computer mediated communication. Volunteers will be asked to answer a questionnaire, and perhaps participate in an interview. If you are interested, please complete the following 10 questions, and mail your answers to BUDD@BU-CS (see paths below). ALL INFORMATION GATHERED WILL BE KEPT CONFIDENTIAL. 1) Your age 2) Gender 3) Primary Occupation. 4) To what extent does your job involve working with computers. 5) How long you have been using computers. 6) When and Where you started using computers. 7) Average hours per week "on line". 8) How much time spent involved in computer mediated communication. 9) How often do you check for new messages? 10) An address at which you can be reached. Feel free to redistribute this to anyone who might find it of interest. Thank You!! Phil Budne BU: budd@bu-cs ARPA: budd%bu-cs.csnet@csnet-relay.ARPA Usenet: ....seismo!harvard!bu-cs!budd ------- 3-Apr-85 13:12:02-PST,2248;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Wed 3 Apr 85 13:08:28-PST Date: 3 Apr 1985 09:25:35 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 940 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 940: Title: Toward an Internet Standard Scheme for Subnetting Author: GADS Mailbox: Mills@USC-ISID.ARPA Pages: 3 Characters: 7061 pathname: RFC940.TXT Several sites now contain a complex of local links connected to the Internet via a gateway. The details of the internal connectivity are of little interest to the rest of the Internet. One way of organizing these local complexes of links is to use the same strategy as the Internet uses to organize networks, that is, to declare each link to be an entity (like a network) and to interconnect the links with devices that perform routing functions (like gateways). This general scheme is called subnetting, the individual links are called subnets, and the connecting devices are called subgateways (or bridges, or gateways). This RFC discusses standardizing the protocol used in subnetted environments in the ARPA-Internet. Distribution of this memo is unlimited. The author of this RFC is the Gateway Algorithms and Data Structures (GADS) Task Force, chaired by David L. Mills. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. 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. ------- 5-Apr-85 08:25:28-PST,369;000000000000 Return-Path: Received: from BRL-AOS by USC-ECLC; Fri 5 Apr 85 08:23:22-PST Received: from amsaa.arpa by BRL-AOS.ARPA id a005706; 5 Apr 85 11:01 EST Date: Fri, 5 Apr 85 10:54:57 EST From: Kevin Ulmer (SSAO) To: msggroup@BRL.ARPA Subject: remove Please remove me from this mail list. Thanks 16-Apr-85 15:32:04-PST,2070;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Tue 16 Apr 85 15:28:02-PST Date: 16 Apr 1985 12:26:50 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 941 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 941: Title: Addendum to the Network Service Definition Covering Network Layer Addressing Author: ISO Mailbox: McKenzie@BBN-UNIX.ARPA Pages: 34 Characters: 707061 pathname: RFC941.TXT This Addendum to the Network Service Definition Standard, ISO 8348, defines the abstract syntax and semantics of the Network Address (Network Service Access Point Address). The Network Address defined in this Addendum is the address that appears in the primitives of the connection-mode Network Service as the calling address, called address, and responding address parameters, and in the primitives of the connectionless-mode Network Service as the source address and destination address parameters. This document is distributed as an RFC for information only. It does not specify a standard for the ARPA-Internet. Distribution of this document is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. 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. ------- 24-Apr-85 11:53:36-PST,2021;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Wed 24 Apr 85 11:53:05-PST Date: 24 Apr 1985 10:14:04 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 943 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 943: Title: Assigned Network Numbers Author: J. K. Reynolds and J. Postel Mailbox: JKREYNOLDS@USC-ISIF.ARPA Pages: 50 Characters: 108133 pathname: RFC943.TXT This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This RFC will be updated periodically, and in any case current information can be obtained from Joyce Reynolds. The assignment of numbers is also handled by Joyce. If you are developing a protocol or application that will require the use of a link, socket, port, protocol, network number, etc., please contact Joyce to receive a number assignment. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. 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. ------- 30-Apr-85 17:26:42-PDT,1616;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Tue 30 Apr 85 17:23:00-PDT Date: 30 Apr 1985 15:00:29 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 944 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 944: Title: Official ARPA-Internet Protocols Author: J. K. Reynolds and J. Postel Mailbox: JKREYNOLDS@USC-ISIF.ARPA Pages: 40 Characters: 63693 pathname: RFC944.TXT This RFC identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned. This memo is an official status report on the numbers used in the ARPA-Internet community. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. 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. ------- 9-May-85 12:06:42-PDT,2018;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Thu 9 May 85 12:05:56-PDT Date: 9 May 1985 10:21:42 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 945 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 945: Title: A DoD Statement on the NRC Report Author: Jon Postel Mailbox: POSTEL@USC-ISIF.ARPA Pages: 2 Characters: 5402 pathname: RFC945.TXT In May 1983 the National Research Council (NRC) was asked jointly by DoD and NBS to study the issues and recommend a course of action. The final report of the NRC committee was published in February 1985 (see RFC-942). The enclosed letter is from Donald C. Latham (ASDC3I) to DCA transmitting the NRC report and requesting specific actions relative to the recommendations of the report. This RFC reproduces a letter from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC3I) to the Director of the Defense Communications Agency (DCA). This letter is distributed for information only. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. 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. ------- 9-May-85 17:44:20-PDT,1967;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Thu 9 May 85 17:43:51-PDT Received: from xerox.arpa by BRL-AOS.ARPA id a017024; 9 May 85 20:21 EDT Received: from Cabernet.MS by ArpaGateway.ms ; 09 MAY 85 17:19:27 PDT Date: 9 May 85 17:19:08 PDT (Thursday) From: AlHall.pa@XEROX.ARPA Subject: X.400 and ARPAnet To: MsgGroup@BRL.ARPA cc: AlHall.osbuNorth@XEROX.ARPA I've heard tell that DARPA is considering adopting ISO Transport protocols in lieu of TCP/IP. Since this could generate interest in someone implementing an ARPAnet/X.400 Mail Gateway, I would be interested in hearing whether anyone has thought much about how ARPA text headers might be handled. X.400 allows for only a subset of the ARPA header fields in its structured Attributes, so the original ARPA header would have to be kept elsewhere if the additional information is to be retained. It's true that the header could remain at the top of the text body in the "primary" Body Part (X.400 supports multiple Body Parts), but for non-ARPA recipients, this could result in a lot of duplicate information in the visible portion of the message. The reason for this is that a text-oriented implementation of X.400 -- or its associated mail system -- would by default display the Attributes as the "real" text header and the primary Body Part, which in this case would also include the ARPA header, as the text body. An alternative might be to set down a convention to have some well-known Body Part contain the ARPA header, have the Attributes contain a bare-bones representation of the ARPA header, and have the primary Body Part contain just the text body. This way, those sites that want to see only the "essential" portions of the message can display the Attributes and the primary Body Part, and the ARPA-like sites can display the "ARPA header" Body Part and the primary Body Part. Comments ? Questions ? -- Al 9-May-85 18:59:26-PDT,1622;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Thu 9 May 85 18:59:18-PDT Received: from bbna.arpa by BRL-AOS.ARPA id a017201; 9 May 85 21:38 EDT Date: 9 May 1985 21:37-EDT Sender: DDEUTSCH@BBNA.ARPA Subject: Re: X.400 and ARPAnet From: DDEUTSCH@BBNA.ARPA To: AlHall.pa@XEROX.ARPA Cc: MsgGroup@BRL.ARPA, AlHall.osbuNorth@XEROX.ARPA, DDeutsch@BBNA.ARPA Message-ID: <[BBNA.ARPA] 9-May-85 21:37:39.DDEUTSCH> In-Reply-To: The message of 9 May 85 17:19:08 PDT (Thursday) from AlHall.pa@XEROX.ARPA I don't have time right now to do the side-by-side comparison that you've done, but I believe that the mapping for most fields should be pretty straightforward. If you would give examples of which ARPAnet header fields cannot be represented in an X.400, perhaps I or somebody else can suggest how to get around those specific problems. Considering how many of the ideas in the P2 protocol (rules for the structure and processing of user messages) can be traced back to ARPAnet mail, the problem may not be as bad as it seems at first glance. --Debbie P.S. You may also be interested to know that if the ISO version of P2 follows the same pattern as ISO has been taking for P1 (the message transfer protocol), their P2 is likely to be a slightly larger superset of CCITT (X.400) P2. This might help solve some of the problem you describe. In my opinion, the real sticky part (if any) in building a gateway between ARPAnet and X.400 mail systems would be encountered when trying to relate SMTP and the P1 protocol, which have very dissimilar world views. 9-May-85 23:50:49-PDT,876;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Thu 9 May 85 23:50:37-PDT Received: from uci-icse.arpa by BRL-AOS.ARPA id a000305; 10 May 85 2:33 EDT To: MsgGroup@brl.ARPA cc: Demco.ubc@csnet-relay.ARPA Subject: Re: X.400 and ARPAnet In-reply-to: Msg 9 May 1985 21:37-EDT <[BBNA.ARPA] 9-May-85 21:37:39.DDEUTSCH> Date: 09 May 85 21:46:05 PDT (Thu) From: Einar Stefferud Received: from Localhost by UCI-ICSE; 09 May 85 21:47:11 PDT (Thu) Since an Internet-to-X.400 gateway has been implemented at the University British Columbia (UBC.CSNET) via an MMDF Channel for relaying mail to the Canadian EAN X.400 (X.25) network, I think we should ask our friends at UBC if might tell us how they did it and what problems they encountered. Also, how can folks get more technical information? Best - Stef 10-May-85 00:32:14-PDT,1161;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Fri 10 May 85 00:32:09-PDT Received: from xerox.arpa by BRL-AOS.ARPA id a000182; 10 May 85 3:22 EDT Received: from Riesling.ms by ArpaGateway.ms ; 09 MAY 85 20:18:07 PDT Sender: "Albert C. Hall.osbunorth"@XEROX.ARPA Date: 9 May 85 20:17:26 PDT (Thursday) Subject: Re: X.400 and ARPAnet From: AlHall.osbunorth@XEROX.ARPA To: DDEUTSCH@BBNA.ARPA cc: MsgGroup@BRL.ARPA, AlHall.osbunorth@XEROX.ARPA In-Reply-to: DDEUTSCH%BBNA:ARPA's message of 9 May 85 18:38:47 PDT (Thursday) Debbie: The fields "Received:" and "Remailed-date:" are both fairly common in ARPA headers. In addition, ARPA headers are free-form, so they are inherently capable of containing fields that are outside any enumerated list of fields, even a super-superset of CCITT P2. Some programs depend on self-defined header lines, such as "LineFolding: ON", "Redistributed: XeroxInfoLawInterest^.PA", and "PreviousRecipients: geacc022%timevx%cit-hamlet.ARPA". Even though these fields may seem trival to some, they are somewhere between convenient and crucial to others. -- Al 10-May-85 09:13:59-PDT,2861;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Fri 10 May 85 09:12:57-PDT Received: from bbna.arpa by BRL-AOS.ARPA id a007996; 10 May 85 11:51 EDT Date: 10 May 1985 11:50-EDT Sender: DDEUTSCH@BBNA.ARPA Subject: Re: X.400 and ARPAnet From: DDEUTSCH@BBNA.ARPA To: AlHall.osbunorth@XEROX.ARPA Cc: DDEUTSCH@BBNA.ARPA, MsgGroup@BRL.ARPA Message-ID: <[BBNA.ARPA]10-May-85 11:50:06.DDEUTSCH> In-Reply-To: The message of 9 May 85 20:17:26 PDT (Thursday) from AlHall.osbunorth@XEROX.ARPA If my message implied that certain fields were "trivial", I apologize. That was not my intent. The function of "Received" is present in the P1 envelope, and therefore could easily be preserved at the boundary between ARPAnet and X.400 mail systems. It is the TraceInformation field, which is defined in X.411 as follows: TraceInformation ::= sequence {GlobalDomainIdentifier, DomainSuppliedInfo} DomainSuppliedInfo ::= arrival [0] implicit Time deferred [1] implicit Time optional action [2] implicit Integer {relayed(0), rerouted(1)} converted EncodedInformationTypes previous GlobalDomainIdentifier optional} The mapping between this and "Received" looks pretty close. The X.400 paradigm for remailing messages is that you encapsulate the "original" message as a BodyPart of a new message. The submission timestamp (which is the arrival in the first piece of TraceInformation) is the "Date" of a message. When remailing a message, the original message's "Date" is recorded as part of the ForwardedIPMessage BodyPart and the "Remailed-date" is the new submission timestamp. This is how "Remailed-date" is supported by X.400. In P1, the PerDomainBilateralInfo envelope field is used for extensions. While the point is not heavily emphasized in the recommendations, there is also an escape mechanism that allows for nonstandard extension data elements. That is the use of the "Private" class of data elements (the other three classes being Universal, Application-Defined, and Context-Dependent). A private data element can be anything you want it to be, as long as it is properly structured. I don't remember any discussion of exactly how P2 was to be privately extended, but here is how I would do it. I'd use the PerDomainBilateralInfo to signal that the message content was an ARPA (or Xerox or whatever) extended version of IPM P2. Then I'd use private tagged data elements to represent the extension fields. (If you used context-dependent identifiers you might get stuck one day if the recommendations are extended.) Maybe the UBC people can suggest alternate approaches, but based on this, I think that a P2 gateway is definitely a feasible proposition. Are there any other ARPA headers that seem problematic? Cheers, Debbie 10-May-85 19:32:57-PDT,2434;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Fri 10 May 85 19:31:18-PDT Received: from xerox.arpa by BRL-AOS.ARPA id a017158; 10 May 85 21:24 EDT Received: from Riesling.ms by ArpaGateway.ms ; 10 MAY 85 18:23:08 PDT Sender: "Albert C. Hall.osbunorth"@XEROX.ARPA Date: 10 May 85 18:21:18 PDT (Friday) Subject: Re: X.400 and ARPAnet From: AlHall.osbunorth@XEROX.ARPA To: DDEUTSCH@BBNA.ARPA cc: AlHall.osbunorth@XEROX.ARPA, MsgGroup@BRL.ARPA In-Reply-to: DDEUTSCH%BBNA:ARPA's message of 10 May 85 08:51:15 PDT (Friday) Debbie: No need to apologize. Your message didn't imply that any fields were trivial -- I was just anticipating such a response from some random person (I know a lot of random people). Thanks for being concerned, though. Pressing on ... I'm interested in how you would handle comments-in-names such as "Riesling.ms@Xerox.ARPA (a Grapevine mail server)" and "Gary Ansok ". This is actually a larger issue if users wish to retain the original ordering of their ARPA headers; unless "placement" information is also included in the PerDomainBilateralInfo envelope field, there will be no way of knowing where to insert the extra header information when reconstructing a text header. Actually, the comments-in-names case is sufficiently complicated such that it might be a better idea just to include the entire ARPA header someplace in the PerDomainBilateralInfo envelope field. [For those of you less-versed in X.400, the issue that I'm raising here is: Given that a certain mail gateway would parse most but not all of the ARPA header into, say, a record of pre-defined objects, how should the additional information be stored so that 1) a site that knows nothing of ARPA headers will not end up with redundant information at the top of its messages, and 2) no information is missing from the ARPA header if it needs to be reconstructed for an ARPA site. If the ARPA header is left untouched and encapsulated with the text body of the message, then "1)" would fail because sites would probably display both the record of pre-defined objects and the text body by default. On the other hand, if only the pre-defined objects are saved, and the rest of the ARPA header is thrown away, then "2)" would fail because comments-in-names and user-defined header fields would be lost.] -- Al 14-May-85 02:28:28-PDT,1346;000000000000 Return-Path: Received: from BRL-AOS by USC-ECLC; Tue 14 May 85 02:26:00-PDT Received: from mit-multics.arpa by BRL-AOS.ARPA id a000366; 14 May 85 5:02 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2662361722209815@MIT-MULTICS.ARPA>; 14 May 1985 04:55:22 edt Date: 12 May 85 13:58 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: MsgGroup@BRL-AOS.ARPA Subject: Re: X.400 and ARPAnet - handling "comments in names" Message-ID: <104373@QZCOM> In-Reply-To: <104286@QZCOM> AlHall.osbunorth@XEROX.ARPA raises the issue of how to map comments-in-names, wh FROM: AlHall.osbunorth@XEROX.ARPA Pressing on ... I'm interested in how you would handle comments-in-names such as "Riesling.ms@Xerox.ARPA (a Grapevine mail server)" and "Gary Ansok ". Reply: The P2 header contains a field called "originator". Within this field, there is a subfield called "freeformName". Maybe this subfield is suitable for storing either only the comment, or (perhaps better) the full name, i.e. the strings within quotes in the message cited above. 14-May-85 13:27:51-PDT,932;000000000000 Return-Path: Received: from BRL-AOS by USC-ECLC; Tue 14 May 85 13:26:58-PDT Received: from wiscvm.arpa by BRL-AOS.ARPA id a010016; 14 May 85 13:53 EDT Received: from (U41513)UICVM.BITNET by WISCVM.ARPA on 05/14/85 at 12:53:07 CDT Date: Tue, 14 May 85 12:38:03 cet To: MSGGROUP@BRL.ARPA From: U41513%UICVM.BITNET@WISCVM.ARPA Subject: internet mail/ anyone for Bitnet and the world outside? Greetings from the windy city of Chicago! John Melinyshyn (312) 687 3314 Electrical Enginnering at the University of Illinois at Chicago Internetworking: Essentially, this file is a 'message in a bottle' for those of us here who would like to know more about neighboring networks. If you would like help, please do so. Also, if we are playing with fire, we would appreciate the knowledge of any regulations concerning mail transfer through this network. Thanks for your time. 14-May-85 20:56:24-PDT,768;000000000000 Return-Path: Received: from BRL-AOS by USC-ECLC; Tue 14 May 85 20:55:21-PDT Received: from usc-isif.arpa by BRL-AOS.ARPA id a000942; 14 May 85 23:32 EDT Date: 14 May 1985 20:26:05 PDT From: POSTEL@USC-ISIF.ARPA Subject: re: x.400 and ARPANET (really X.400 <-> RFC-822 mappings) To: MsgGroup@BRL.ARPA Hi. I find this to be a very interesting discussion. I'd love to have a memo that lays out the mapping between things in ARPA-mail (RFC-822) and ISO-mail (CCITT X.400). I've had a little trouble integrating all the concepts and all the details in the X.400 documents. I would find a note that describes how an ARPA-mail message maps into an ISO-mail message very helpful in groking the whole thing. --jon. ------- 22-May-85 13:25:51-PDT,3363;000000000000 Return-Path: Received: from BRL-AOS by USC-ECLC; Wed 22 May 85 13:25:24-PDT Received: from xerox.arpa by BRL-AOS.ARPA id a014559; 22 May 85 15:41 EDT Received: from Cabernet.MS by ArpaGateway.ms ; 22 MAY 85 12:40:19 PDT Date: 22 May 85 12:40:11 PDT From: Murray.pa@XEROX.ARPA Subject: Names with spaces To: INFO-NETS@MIT-MC.ARPA, Postmaster@MIT-MC.ARPA, MsgGroup@BRL.ARPA, HEADER-PEOPLE@MIT-MC.ARPA Cc: Murray.pa@XEROX.ARPA, Hamilton.OSBUSouth@XEROX.ARPA A month or so ago, Bruce sent an innocent msg to INFO-NETS that caused a lot of confusion. It seems as though lots of systems out there crashed every half-hour or so whenever MC tried to (re)transmit Bruces' msg on to them. The error message was something like "no closing quote". I think some systems can't tolerate mismatched quotes in the From field of the header, and MC managed to drop one. I think the From line looked like this when it left here: From: "Bruce A. Hamilton.OsbuSouth"@Xerox.ARPA The line that was killing CIT-VAX was: From: Can anybody fill me in on the fine print? Is there something special about the From line, or will any header line containing mismatched quotes cause the same problem? Any reason why it crashes the system instead of logging a message and blundering on? The only victim I've been in contact with is CIT-VAX. I think they are running a vanilla 4.2BSD. How many other systems got cought by the same bug? Did your system crash? Is there a reasonable bug fix? Any hope of fixing MC? ... Sending mail that crashes systems is high on my list of things not to do, especially when you can kill many systems with only one message. Currently, I have a filter installed that rejects any outgoing msg if the From field needs quoting. Is that good enough? (If you want a test case, just let me know.) ----- Part of our mail system makes heavy use of spaces in names. I'm getting a lot of flak about rejecting all these messages. We started seriously using quoted names with spaces early this year. There were various bugs that had to be fixed, both here and at other sites nearby where we exchange lots of mail. Things calmed down after a while. Then Brian Reid started complaining. He is the postmaster at a site that was relaying some of our mail on to the UUCP world. Several of the next layer of machines didn't know about quotes, and the rejections were landing in Brian's mailbox. I "solved" that one by translating all the spaces to underbars in the return-path in the envelope. I did that because I "knew" that none of our names contained any underbars so I could make the reverse translation without fear of breaking anything. Is the space/underbar substitution universal enough that I can do it to the whole header without fear of mangling some address that really should have a space in it? I haven't yet managed to convince myself that I won't provoke a really obscure problem if I just blindly "fix" all the quoted spaces to/from underbars. Have all the (flakey) Unix systems out there established a de-facto addendum to RFCs 821/822 that prohibits quoted strings? ----- Does/will the X400 world have spaces in names, or will there be spaces in names by the time they get mapped/translated into RFC 821/822 format? 22-May-85 14:40:28-PDT,1303;000000000000 Return-Path: Received: from BRL-AOS by USC-ECLC; Wed 22 May 85 14:39:53-PDT Received: from sri-csl.arpa by BRL-AOS.ARPA id a015905; 22 May 85 17:14 EDT Date: 22 May 1985 14:11-PDT Sender: GEOFF@sri-csl.ARPA Subject: Re: Names with spaces From: "the tty of Geoffrey S. Goodfellow" To: Murray.pa@xerox.ARPA Cc: INFO-NETS@mit-mc.ARPA, Postmaster@mit-mc.ARPA, MsgGroup@brl.ARPA Cc: HEADER-PEOPLE@mit-mc.ARPA, Hamilton.OSBUSouth@xerox.ARPA Message-ID: <[SRI-CSL]22-May-85 14:11:11.GEOFF> In-Reply-To: The message of 22 May 85 12:40:11 PDT from Murray.pa@XEROX.ARPA Hal Implementing "solutions" like changing spaces to underbars just to keep people's mailers which can't grok legal protocol from crashing seems inappropriate to me, at least in the long term. If quoted spaces are indeed legal to send, well send them for heavens sakes. If they crash people's mailers, then those mailers should be fixed -- plain and simple. All it takes is one wizard to discern the fix, post it, and everyone else should follow suit. Thank goodness its a solid bug you've found, and not one that would cause peoples mailer's to crash on every 3rd message to come by with a quoted space when there's a full moon out or something like that. g 22-May-85 19:01:07-PDT,2657;000000000000 Return-Path: Received: from BRL-AOS by USC-ECLC; Wed 22 May 85 18:57:45-PDT Received: from rand-unix.arpa by BRL-AOS.ARPA id a016765; 22 May 85 21:34 EDT Received: by rand-unix.ARPA; Wed, 22 May 85 18:07:23 pdt From: Steve Tepper Message-Id: <8505230107.AA22510@rand-unix.ARPA> Date: 22 May 85 18:07:15 PDT (Wed) To: INFO-NETS@mit-mc.ARPA, MsgGroup@brl.ARPA, HEADER-PEOPLE@mit-mc.ARPA Subject: Re: Names with spaces I will seize the current fracas about spaces in names as an opportunity to give vent to a long-standing gripe, which has to to with network protocols in general but is a particularly sore point when it comes to mail. My complaint is that, given the lack of any network police, the decision as to who has to change what to make it work with something else is often more of a political question than a technical one. Typically the scenario is something like this: User Foo@FooHost wants to send mail to Bar@BarHost. Now it turns out that the person who maintains the software used at BarHost (who likely doesn't even work there, unless BarHost is a one-of-a-kind operating system) has decided to "improve" the mail system in some way which is uncontestably at variance with the standard, with the result that some mail breaks. A cleanliness freak would, justifiedly, state flatly that the burden is on either BarHost or their software maintainer to get it fixed. The reality is unfortunately different. It may be that Bar@Barhost is Foo's project sponsor, or someone else of sufficient stature that Foo considers the ability to communicate electronically with Bar a high-priority matter. Complaining that the problem is at BarHost may be morally satisfying but does not get the message delivered, especially if the person who made the offending change is obstinate and claims that his "improved" version is so obviously superior that it is incumbent on the rest of the world to mimic his changes until they become a de facto standard. The outcome: some poor soul at FooHost has to figure out what BarHost's mail server is now willing to accept and hack up FooHost's mailer to accomodate it, without disrupting other mail services from FooHost in the process. I am exerting considerable restraint here by refraining from mentioning the names of any guilty parties (and all the cases I dealt with were too far in the past to be of any immediate concern), but I'm sure other people have also found themselves in the unpleasant situation of being the person who had to "fix" something to accomodate someone else's non-standard "improvements". 22-May-85 22:14:05-PDT,1246;000000000000 Return-Path: Received: from BRL-AOS by USC-ECLC; Wed 22 May 85 22:09:27-PDT Received: from mit-multics.arpa by BRL-AOS.ARPA id a000386; 23 May 85 0:36 EDT Date: Thu, 23 May 85 00:18 EDT From: Barry Margolin Subject: Re: Names with spaces To: Murray.pa@XEROX.ARPA cc: info-nets@MIT-MC.ARPA, MsgGroup@BRL.ARPA, header-people@MIT-MC.ARPA, Hamilton.OSBUSouth@XEROX.ARPA Message-ID: <850523041830.813992@MIT-MULTICS.ARPA> To answer the question that appeared at the end of the original message, X.400 should not have any problems in this respect. X.400 messages are binary data structures, and the protocols between mailer processes are also binary messages. There is no text parsing involved. For instance, rather than having a mailer daemon transmit Character strings are encoded as a type word followed by a length byte followed by the specified number of characters (I am purposely simplifying, leaving out things like the character set identifier). No ambiguity is possible within the protocol (of course, user interfaces are another problem, as they must translate between this form and printed form). barmar 23-May-85 11:57:17-PDT,496;000000000000 Return-Path: Received: from BRL-AOS by USC-ECLC; Thu 23 May 85 11:54:32-PDT Received: from brl-tgr.arpa by BRL-AOS.ARPA id a013962; 23 May 85 14:21 EDT Date: Thu, 23 May 85 14:18:45 EDT From: Ron Natalie To: Steve Tepper cc: INFO-NETS@MIT-MC.ARPA, MsgGroup@BRL.ARPA, HEADER-PEOPLE@MIT-MC.ARPA Subject: Re: Names with spaces AHEM. Can we please get this discussion down to only one group please. 24-May-85 18:53:34-PDT,1247;000000000000 Return-Path: Received: from BRL-AOS by USC-ECLC; Fri 24 May 85 18:52:37-PDT Received: from xerox.arpa by AOS.BRL.ARPA id a000283; 24 May 85 21:21 EDT Received: from Tokay.ms by ArpaGateway.ms ; 24 MAY 85 17:59:18 PDT Sender: "Albert C. Hall.osbunorth"@XEROX.ARPA Date: 24 May 85 17:58:49 PDT (Friday) Subject: Re: X.400 and ARPAnet From: AlHall.osbunorth@XEROX.ARPA To: MsgGroup@BRL.ARPA cc: AlHall.osbunorth@XEROX.ARPA, DDEUTSCH@BBNA.ARPA, steve%cs.ucl.ac.uk@UCL-CS.ARPA In-Reply-to: steve%ucl-cs:ARPA's message of 14 May 85 13:47:59 PDT (Tuesday) Steve: I'd like to hear more about the way that the ARPA/X.400 Mail Gateways at UCL and UBC handle the mappings between the ARPA header fields and the P2-level X.400 Attributes. I am mostly interested in the "fudging" that was done for the non-"obvious" cases, and why the "unreasonable" ones were deemed as such. I agree with your expectation that there will be a number of ARPA/X.400 Mail Gateways, and I'd like to see them all cooperate in reversing the mappings of the others. Could you shed some more light on the UCL and UBC implementations, and on the document that was "commissioned, but never released" ? Thanks, Al 24-May-85 18:58:33-PDT,5128;000000000000 Return-Path: Received: from BRL-AOS by USC-ECLC; Fri 24 May 85 18:57:02-PDT Received: from xerox.arpa by AOS.BRL.ARPA id a000279; 24 May 85 21:20 EDT Received: from Tokay.ms by ArpaGateway.ms ; 24 MAY 85 17:59:04 PDT Sender: "Albert C. Hall.osbunorth"@XEROX.ARPA Date: 24 May 85 17:58:33 PDT (Friday) Subject: Re: X.400 and ARPAnet From: AlHall.osbunorth@XEROX.ARPA To: MsgGroup@BRL.ARPA cc: AlHall.osbunorth@XEROX.ARPA, DDEUTSCH@BBNA.ARPA, steve%cs.ucl.ac.uk@UCL-CS.ARPA In-Reply-to: steve%ucl-cs:ARPA's message of 14 May 85 13:47:59 PDT (Tuesday) Well, I'm back from vacation -- sorry for the delay. Included below is a message sent to me by Steve Kille. I'm forwarding it (with permission) because my main intent here is to get a consensus regarding which parts of the ARPA header, if any, are "expendable." As such, I'd prefer to see replies to this conversation copied to MsgGroup%BRL.ARPA if at all possible. I've already seen an implementation similar to an ARPA/X.400 Mail Gateway in which "autocratic" decisions were made about the usefulness of comments-in-names and user-definable header fields. Basically, they were both disallowed ... and then later, after it was too late, several people complained that they were unable to use certain facilities on remote hosts, etc. In addition, what I'm trying to avoid here is duplicate or conflicting ways of representing any information in ARPA headers that *is* deemed useful -- including perhaps the ordering of the fields -- that does not map directly into the basic Attributes of X.400 messages. -- Al ---------------------------------------------------------------- Sender: steve%ucl-cs:ARPA:Xerox Date: 14 May 85 13:47:59 PDT (Tuesday) Subject: Re: X.400 and ARPAnet From: steve%cs.ucl.ac.uk%ucl-cs To: AlHall:OSBU North cc: DDEUTSCH%bbna In-Reply-to: Your message of 10 May 85 18:21:18 PDT (Friday). GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV To: AlHall.osbunorth cc: DDEUTSCH@bbna.arpa Subject: Re: X.400 and ARPAnet In-reply-to: Your message of 10 May 85 18:21:18 PDT (Friday). From: Steve Kille Return-Path: Received: from ucl-cs (UCL-CS.ARPA) by Xerox.ARPA ; 14 MAY 85 13:47:31 PDT Phone: +44-1-387-7050 ext 773 Message-ID: <1360.484940148@UCL-CS.AC.UK> GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV Al, There is already an Arpa / X.400 mail gateway (at UCL), using (as Stef noted) MMDF one the ARPA side, and EAN (the University of British Columbia X.400 system on the other). However, there is access control on the MMDF side, and so it is not generally available. A similar gateway at UBC can be accessed through Csnet. The gateway was implemented at UBC (functionality defined in the code), and clearly shows that basic interoperability can be acheived. (Note: the UBC implementation interworked with Sendmail, and I used this as the basis for an MMDF channel). Some considerations in more general terms: I cannot see a great deal of use for a P1 level gateway (e.g. between P1 and SMTP), simply because there is not common P2 level protocol. A P2 level gateway (as produced by UBC) makes more sense, to provide an 'Inter Personal Messaging Service'. This would be between P2 on one side, and variuos RFC 822 derived protocols on the other (e.g. SMTP, JNT Mail, UUCP mail....). As already noted, most of the basic functions either map in a basic manner (e.g. To: / primary recpient) or do not map at all (e.g. G4 fax makes little sense in the RFC 822 world). Variuos others do not map directly, but can be fudged in a number of ways. In practice, none of these others are vastly significant. Addressing is a complex issue, and a proper solution should work in the general case. I have seen two attempts to specify this mapping. One is in the EAN code. This makes the obvious mappings, makes reasonable choices for the fudges, and makes a very specific address mapping, to allow for easy interworking with the RFC 822 world. Another specifcation was made in a document commissioned, but never released. This again makes the obvious mappings, notes the unreasonable ones, and makes another choice of fudges (unfortunately without considering other possibilities). A very specific address mapping, different to the EAN one, is suggested. It would be a very useful thing, if someone were to specify a preferred set of mappings, preferably discussing choices where they exist. I suspect that there will be a number of such gateways, and it would be very useful if they behaved in the same manner. In particular, a common mechanism for mapping betwen the addresses would be sensible. If other aspects were defined, it would (point 2 in your second message), allow for minimum loss of information if a message crossed between x.400/822 more than once - I'm not sure that this is very useful. In general, your points 1) and 2) are a tradeoff. Steve ---------------------------------------------------------------- 27-May-85 11:55:05-PDT,1506;000000000000 Return-Path: Received: from BRL-AOS by USC-ECLC; Mon 27 May 85 11:53:07-PDT Received: from mit-multics.arpa by AOS.BRL.ARPA id a005325; 27 May 85 14:28 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2663519254382560@MIT-MULTICS.ARPA>; 27 May 1985 14:27:34 edt Date: 27 May 85 15:23 +0100 From: Knut_Smaaland_UiO%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA, COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA To: MSGGROUP@BRL-AOS.ARPA, Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA, COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Subject: ISO work on group communication in message systems Message-ID: <106375@QZCOM> In-Reply-To: <106370@QZCOM> A correction to the handling procedure of group communication within ISO/TC97. At its plenary in Washington DC ISO/TC97/SC18 decided to leave the decision on how to handle group communication to ISO/TC97/SC18/WG1. The NWI proposal wil be sent on a 3 month letter ballot to ISO/TC97 member bodies only if ISO/TC97/SC18/WG1 decides to do so. If they decide not to do it, any member body of ISO is free to suggest the same NWI and then it will be sent out on a 3 month letter ballot regardless of the SC18 opinion. Or any other TC97 sub committee can propose the same NWI. 27-May-85 12:15:52-PDT,17909;000000000000 Return-Path: Received: from BRL-AOS by USC-ECLC; Mon 27 May 85 12:15:13-PDT Received: from mit-multics.arpa by AOS.BRL.ARPA id a005319; 27 May 85 14:27 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2663519032870116@MIT-MULTICS.ARPA>; 27 May 1985 14:23:52 edt Date: 27 May 85 14:15 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA, COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA To: MSGGROUP@BRL-AOS.ARPA, Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA, COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA, Murray@njit-eies.mailnet, Elaine@njit-eies.mailnet, Roxanne@njit-eies.mailnet, 116@njit-eies.mailnet Subject: Subject: ISO work on group communication in message systems Message-ID: <106370@QZCOM> Report from meeting with the ISO/TC 97/SC 18/WG 4 ad hoc group on group communication, May 20-24, 1985. ISO/TC 97/SC 18 decided on its meeting in Washington D.C. in April 1985 to consider whether to develop standards for group communication within MOTIS (MOTIS = the ISO standard for message systems). In order to prepare for this decision, and ad hoc meeting was called in Paris last week. The question will also be discussed in ISO/TC 97/SC 18/WG 1 in July, and then sent out on a vote to the ISO member nations. Here is a report from the meeting in Paris. La Defense is a fascinating place, a multitude of extreme high- rise buildings outside Paris. In one of the smallest, only 20 stories high, resides AFNOR, the french standards organization, where we met in the basement. Present at the meeting were Fred Sztajnkrycer (France, chairman), Carl-Uno Manros (Germany), Knut Smaaland (Norway), Jacob Palme (Sweden) and Uta Pankoke-Babatz (Germany) and Sylvianne de Bresson (AFNOR, France, secretary). Note particularly that there was no American representative, even though computer conferencing originated in the U.S. and the important work being done with EIES, Parti, Notepad, Confer and other U.S. conference system and that many large public services (ITT-Dialcom with Parti, Telemail with Bulletin Boards, The Source with Parti etc.) provide such facilities. Carl-Uno Manros told about the CCITT meeting in Geneva a few weeks ago. CCITT will set up a question-and-answer service for implementors, and will discuss limitations on un-limited-length parameters in the X.400 standard. A clean-up version of X.400 will appear in 1986 and a major revision of X.400 will appear at the end of the study period. Integration of electronic mail and postal systems will be an important work item. Another subject will be a more general access protocol for work stations (P7) than the present teletex protocol (P5). They are NOT going to do any work on group communication, that subject is NOT felt of interest for CCITT. We then began talking about what is meant by group communication. Everyone agreed that computer conferencing, bulletin boards and distribution lists are included. Additionally, suggestion were made to include voting, controlled cirulation, service groups (consisting of several people, but only one of them handles each incoming message), joint text editing, various kinds of office procedures etc. We also discussed the relationship to archiving, and concluded that we have to look at that problem closely, since the borderline between group communication and archiving may be difficult to define. Uta Pankoke-Babatz presented some papers from the work in DFN, where they had found that a good distribution agent must really perform some activities both at the UA and the MTA level. At the MTA level, it can reject messages from senders who are not allowed to send to this distribution agent, but at the UA level, it can produce a new P2 envelope around the old message, indicating that it has been forwarded by this distribution agent. We then tried to clarify the need for group communication facilities by listing various group communiation activities needing group communication facilities: - Formal organization groups. - Project groups. - Service groups. - Consumer (of information) groups. Notes from the discussions during the second day. Scenarios of group communication activities: Scenario I: This scenario describes a meeting between a group of people, such as a project group, task group, interest group, formal organiztional group. - Activity: A meeting - Message types: Entries, replies, questions, votes, vote answers, vote results - Roles: Chairman, creator, active member, listener - Functions: Make interventions, call for a vote, make questions, make comments - Rules: Rights of the chairman, how to count votes - Activity elements: Lists, histories of members, listeners, chairman etc. - Basic tools or needed services: Distribution lists, directories, archiving etc. Scenario II: This scenario describes a group of people, which may be an organizational unit, with the task of receiving requests from people and responding to them. Incoming messages are sent by clients outside the group to the user service, and then handled by one or more of the people in the group and replies are sent to the clients. - Activity: User services (one kind, other kinds can exist) - Message types: Requests, assignments, answers - Roles: Clients, organizer, staff members - Functions: Request, reply, request assignment, check open requests, refuse request etc. - Rules: Clients send requests to the activity, the organizer receives requests, the organizer assigns them to staff members, staff member receives assignenments, accepts or refuse, answers and reports to the organizer or forwards answers to organizer who can answer etc. - Activity elements: List of requests (open, answered), list of answers, list of clients - Basic tools or needed services: Scenario III: - Activity: Joint editing. - Message types: Document parts, suggested revisions of document parts, comments on the document and its parts - Roles: Editor, participants, listeners - Functions: Submit texts, comment on texts, modify the master document - Rules: Who may comment and suggest revisions, who may enter revisions into the master document. - Activity elements: Master document, parts of the master document, histories of the master document and its parts, lists of chairman, participants, listeners - Basic tools or needed services: Distribution lists, directories, archiving etc. List of basic functions in a group distribution environment - Making a text available to a group. - Distribution of a text to members of a group. - Asking for a text belonging to a group. - Requesting the recipients of a text to perform actions on it. - Act on a text. - Create and modify a group and its structure. - Relations between groups. - Directories of groups. Functional model of a group distribution system (Proposed by Uta Pankoke-Babatz) Tools: Description of the entities of the group Description of the intended procedure Recording of the operation (results) General operations: Receiving messages Creating tag messages Forwarding (distribution of messages) Recording of messages Access to the recording Local operations: Recognising special group message by the tag Recognize the indented operation Reply services Comment on the tag message Interprete relations beween group messages Create group messages of different message types Another functional model (Proposed by Fred Sztajnkryker, extended by Uta Pankoke-Babatz, Carl-Uno Manros and others) Directory services: Stores lists of people who fullfil different roles in relation to the group activity: Organizers, contributors, distribution recipients, readers, potential members. Also handles access control to these lists. Note that the same person can be a member of more than one of these lists. Note that often, one or more of these lists will just contain a reference to one or more other lists, e.g. saying that all employees of XYZ corporation are allowed to read the transcript of a group activity. History services: Storing the transcript of the group process and making this available to the readers on request. Distribution agent: Receiving messages, forwarding them to the distribution recipients, storing them in the history services, performing other (?) operations for the group. Members (UA-s): Sending different types of messages to the distribution agent, recieving messages from the distribution agent (if on the distribution list), retrieving messages from the recording (if on the readers list) etc. Report from the third day of the meeting On the third day of the meeting we began discussing how group communication can fit into MOTIS. Fred Sztajnkrycer produced a structural model (described here as modified in group discussions): +-----------+ +-----------+ ! Directory ! ! Archiving ! ! services !----+ +----! services ! +-----------+ ! ! +-----------+ ! ! ! ! +-------+ ! ! ! ! +-------+ ! Group ! +----------+ ! ! +----------+ ! Group ! ! UA !--o--! ! +---o--! !--o--! UA ! +-------+ ! ! Group !-----+ ! Group ! ! +-------+ ! ! activity ! ! activity ! ! +-------+ ! ! agent !--------! agent ! ! +-------+ ! Group !--o--! ! ! !--o--! Group ! ! UA ! ! +----------+ +----------+ ! ! UA ! +-------+ ! ! +-------+ +----------- Via MHS MTA-s ----------+ The objects in this model are: Group UA-s: The Group UA represents a user of the group activity services in the same way as a UA represent a user of the messaging services. The Group UA can perform group operations on the other services, like sending a a group message, receiving a group message, retrieving a group message, operating on the Directory Services to add a member to a group etc. Directory services: These will store lists of O/R names which are related to groups ("members") and their relations to the group (access rights). Note that an agent can have many different relations to a group. For example for a distribution list/bulletion board application an agent can have rights to send messages to the group, to read messages from the group archives, to modify some of the properties of the group (e.g. add themselves as members), to get all new messages sent via the group sent to them etc. One agent can have one or more of these rights. For other more complex kinds of group activities, like user services, voting etc. other kinds of relations between agent names and the group can be envisaged. Note that the list of agent names having certain relations to a group can be either an explicit list of names, or a description, e.g. saying that all names with a certain property (e.g. all citizens of Sweden) have a certain relation to the group (e.g. the right to read the group archives if these are public Swedish governmental documents) without having to list all the citizens of Sweden. The Directory Services can further store information that a group member can get messages belonging to the group by having them sent automatically to the member (distribution) or by reading them from the group archives. The Directory Service can also store information that a certain agent only has MHS capabilities (not GCS capabilities) so that messages distributed via the group to this agent must be formatted according to MHS protocols (e.g. the P2 protocol) instead of the more advanced protocols available when sending a message to a Group User Agent. Archiving services: The archiving services are used to store messages belonging to a group activity. These are important, since some participants in the group process may prefer to, or have assigned roles, such that they do not get all new messages distributed automatically to them, instead retrieving messages at times of their own choice. The archives also allows a new member to retrieve previous communication in the group (if allowed) and saves each individual member the burden of keeping complete personal archives. Group activity agent: The group activity agent is the central agent handling the group process. This agent may for example receive messages sent to the group, store them in the Archives, retrieve the list of members from the Directory Services and send the message to those members who are getting automatic distribution of all new messages. There can be different types of Group Activity Agents for different types of group activities, but the standard need not necessarily define a different type of Group Activity Agent for each different kind of human communication process. A group may be a member of a group. If, for example, a communication process goes on between 500 distribution members in North America and 500 in Europe, one subgroup in North America can handle North American distribution, and one subgroup in Europe can handle European distribution, so that a list of five hundred names need not be included every time a message is shipped across the Atlantic. 4. Recommendations for future work: 4.1 Scopre of the work: Develop a model for group communication. Define services and one or more protocols. Express requirements on other services. See the list of issues to be resolved. 4.2 Impact on existing work: GCS will be an extension of current work, but will fit into the MOTIS model services and protocols. 4.3 Proposed time scale: 4.4 Needed liaisons: CCITT - 9.33, 3.5 of COM 7, COM 8(?). ISO - SC 18 Wg 1, SC 21 WG 16/4, group on filing and retrieval. ECMA - TC 32. Appendix A: List of some issues to be resolved: Which GCS serices are required? Which new protocols are needed? Examples: - A protocol between Group UA and Group Activity Agent? - A protocol between Group Activity Agents? Or can the same protocol be used as between a Group UA and a Group Activity Agent? - What requirements does group communication put on the protocols for communication with the Directory Services and Archiving Services? Should a Group UA operate directly on the Directory Services and Archiving Services, or should the Group UA always operate on the Group Activity Agent, which will then perform the necessary operations on the Directory Services or Archiving Services? Can a group activity be distributed on several Group Activity Agents? What relations can exists between groups? One can envisage an equalitarian structure, where all the Group Activity Agents are equal, or a tree structure with one root Agent controlling the other Agents handling subgroups. Other relations are also possible. How are new messages sent between the Group Activity Agents? How shall GCS relate to existing MOTIS, and in particular, how shall an implementation of MOTIS without GCS be able to interact with implementations with GCS. Should, in this case, the P2 protocol be used to send and distribute group messages? What is the relation of a group message and an IPMessage? How are roles supported by the GCS and the GAA? Should there be a facility for sending out only the header, or only the abstract, of larger messages, and letting the recipient retrieve the full message only when required? Which activity types are needed? To what extent should real world communication processes be mapped by one complex activity type, or by a collection of related more simple activity types? For example, voting may be regarded as a part of a meeting activity, or voting may be regarded as a separate temporary activity, handling the vote, and with an established relation to the meeting in which the vote is called. Other activity types to be considered may be joint text editing, controlled circulation, service units, electronic publishing (with editors, referees, writers and readers). What relations between and structure on the set of groups is needed? How should a group be mapped onto the directory services? What directory functions are needed to support e.g. a search for "a group discussing the use of Pascal for writing real time applications". How should "news control" be handled. By news control is meant a facility for helping a user to find only messages s/he has not yet read. Should the necessary storage of information about read messages for news control be in the Group User Agent, in the Archiving Services or in the Group Activity Agent? What loop control facilities should be used. There are four major loop control methods to be considered: - By full list expansion at one single point. - By control of the relations between the Group Activity Agents so that no loop is allowed. - By trace information sent along with the messages. - By a storage of (at least) the IPMessageID-s of the messages which are passed on by a Group Activity Agent. It is very important to define the requirements which the various group activities can put on the Directory Services and the Archiving Services, as input to the ISO working groups preparing standards for these services. Liaison must be established between the work on group communication in SC 18/WG 4 and the work on Directory Services and Filing/Retrieval Services in other ISO working groups. 29-May-85 12:08:11-PDT,2306;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Wed 29 May 85 12:06:02-PDT Date: 29 May 1985 10:00:46 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 946 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 946: Title: Telnet Terminal Location Number Option Author: R. Nedved Mailbox: Rudy.Nedved@CMU-CS-A.ARPA Pages: 4 Characters: 6513 pathname: RFC946.TXT Many systems provide a mechanism for finding out where a user is logged in from usually including information about telephone extension and office occupants names. The information is useful for physically locating people and/or calling them on the phone. In 1982 CMU designed and implemented a terminal location database and modified existing network software to handle a 64-bit number called the Terminal Location Number (or TTYLOC). It now seems appropriate to incorporate this mechanism into the TCP-based network protocol family. The mechanism is not viewed as a replacement for the Terminal Location Telnet Option (SEND-LOCATION) but as a shorthand mechansim for communicating terminal location information between hosts in a localized community. This RFC proposes a new option for Telnet for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. 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. ------- 2-Jun-85 16:43:09-PDT,2045;000000000001 Return-Path: Received: from BRL-AOS by USC-ECLC; Sun 2 Jun 85 16:42:13-PDT Received: from usc-isif.arpa by AOS.BRL.ARPA id a001147; 2 Jun 85 19:16 EDT Date: 2 Jun 1985 16:13:02 PDT From: POSTEL@USC-ISIF.ARPA Subject: re: ISO Work on Group Communication To: msggroup@BRL-AOS.ARPA Jacob Palme: Thank you for the report on the meeting in Paris on Group communication issues in computer mail systems. In reading the report, i wondered how much consideration was given to the possible distinction between building group communication IN the mail system, vs. building it ON it. That is, one could take the view that the support for group communication must be incorportated in the depths of the mail system, or one could take the view that group communication facilities can be built entirely outside the mail system as a "value added service" in a separate layer on top of the mail system. Probably either view is too extreme, and as a practical matter there will be some of each in the end system. However, i would be interested if there were any features of group communication that could not be provide if the second (separate layer) model were adopted. Just now i can't think of anything for group communication we do in tha ARPA-mail system that could not be provided as a separate value added service. Note that many of the group communication support functions are implemented in the same programs that provide the basic mail service, but that it need not be that way -- at least not in concept or specification. Another thought struck me while reading the report, is that maybe the scope is getting too large. While it is important to consider many aspects of a problem before choosing a solution, it is also important to choose problems small enough to be solved. In particular, i am concerned that "joint editing" may include a lot of issues and concerns that are beyond what most people want to include in the group communication problem. --jon. ------- 4-Jun-85 16:08:12-PDT,2897;000000000001 Return-Path: Received: from BRL-AOS by USC-ECLC; Tue 4 Jun 85 16:06:17-PDT Received: from mit-multics.arpa by AOS.BRL.ARPA id a000222; 4 Jun 85 14:08 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2664213040969504@MIT-MULTICS.ARPA>; 04 Jun 1985 15:10:40 edt Date: 03 Jun 85 22:57 +0100 From: Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: 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: re: ISO Work on Group Communication; INside or On-Top Message-ID: <107456@QZCOM> In-Reply-To: <107354@QZCOM> I have given this question a great deal of thought, too. My conclusion is that a very good group communication system would need very few additions to the definition of the message transport protocol (P1). The major work could be concentrated on the interworking of P1 and a good, general-purpose Directory System done within an MTA. (Yes, I admit that I in this way regard X.400 merely as a message transportation system - and this may possibly be required, since you cannot change CCITT Recommendations (or ISO Standards) over-night.) The most important facilities of Group Communication lies within the semantical definitions of how the group works, in two ways: - intra-group semantics (what todays ARPA-mailing lists provide) - inter-group semantics (what some conferencing systems provide). And these things can rather easily be separated from the transportation of the message - provided that the directory systems are connected. Thus, I strongly favour a 'value-added' approach with a limited number of additions to the current definition of X.400-X.430. Re: 'anything for group communication we do in the ARPA-mail system that could not be provided as a separate value added service' - for one thing, the maintenance of distributed group definitions COULD be made "on-top" of RFC822, but this would probably not be accepted: people want to know the results in "real-time". Another example: obtaining an answer for inquiries like 'Who are the members of group X?' is again something that people would not like to wait for - since no other human is involved they expect the answer to be almost instantaneous. And these things can more easily be solved by means of a general-purpose Directory System using connection-oriented protocols. Scope: I tend to agree in your concern. However, these points should not be neglected as things are now: the fact is that standardization work is currently working on the same level in some respects as is state-of-the-art research! This might be good, but it could also be dangerous when considering that they (CCITT, ISO, ECMA, IEEE) do not necessary work as unbound as "free" researchers do. 4-Jun-85 16:08:12-PDT,130;000000000001 Date: 04 Jun 85 16:25 PDT From: msggroup-request@brl To: msggroup@brl Subject: Survey of [ECLC]msggroup.2401-2500 4-Jun-85 16:32:25-PDT,5372;000000000001 Return-Path: Received: from BRL-AOS by USC-ECLC; Tue 4 Jun 85 16:30:08-PDT Received: from mit-multics.arpa by AOS.BRL.ARPA id a000232; 4 Jun 85 14:09 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2664213351368404@MIT-MULTICS.ARPA>; 04 Jun 1985 15:15:51 edt Date: 04 Jun 85 02:27 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, MSGGROUP@BRL-AOS.ARPA Cc: COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: re: re: ISO Work on Group Communication Message-ID: <107466@QZCOM> In-Reply-To: <107354@QZCOM> FROM: POSTEL@USC-ISIF.ARPA In reading the report, i wondered how much consideration was given to the possible distinction between building group communication IN the mail system, vs. building it ON it. That is, one could take the view that the support for group communication must be incorportated in the depths of the mail system, or one could take the view that group communication facilities can be built entirely outside the mail system as a "value added service" in a separate layer on top of the mail system. Comment: ISO is in a very early stage at present, so all possibillities are open. It would be very valuable if more people from North America could participate. Please talk to ANSI if you want to participate. As a general reply to your question: X.400 already has two layers on top of each other: P2 on top of P1/P3. There was general agreement on the Paris meeting that group communication is to use P1 for the transportation of group messages, so in that sense group communication will already be on top of the main transport layer, P1, in X.400. Group communication will also involve accesses to the directory and archiving system. I am not myself very much involved with standardization of directory services, but have gathered that this will probably NOT use the P1 layer because it may be too slow for efficient cooperation between distributed directory systems. As I understand, France wants directory systems on top of P1, but not most other countries in ISO. For archiving, no standardization has yet even begun as I understand. At the Paris meeting, the idea was to use for group communication an extension of the P2 protocol, which is close to your ideas, even if group communication was not planned as entirely on top of P2. Note that for users of CBMS-s without support for group communication, messages will still be sendable and recievable to/from groups using the unextended P2 protocol. (The directory system will thus have to store knowledge of which members of a group can only handle the P2 protocol.) FROM: POSTEL@USC-ISIF.ARPA Just now i can't think of anything for group communication we do in tha ARPA-mail system that could not be provided as a separate value added service. Comment: Note that there are many services which are not at present in ARPANET mail which will be available in future ISO group communication standards. Example of this will be standardized way of remote addition and removal of members of a group, so that no human group maintainer need read and handle requests for membership and removal from people except where human access control is desired. Another example is automatic ways of asking for extracts from the group archives, it is even planned, which is very different from ARPANET today, that some users may primarily participate in groups by requesting new items from the archives rather than having things sent automatically to them. The most important point, where the P2 protocol is lacking in something important for group communication, is in my opinion the lack of a compulsory, globally unique IPMessageID. And it is much neater to add things like this by extensions to P2 than by a new protocol on top of P2. FROM: POSTEL@USC-ISIF.ARPA Another thought struck me while reading the report, is that maybe the scope is getting too large. While it is important to consider many aspects of a problem before choosing a solution, it is also important to choose problems small enough to be solved. In particular, i am concerned that "joint editing" may include a lot of issues and concerns that are beyond what most people want to include in the group communication problem. Comment: ISO will with high probability begin with standards for the most basic group, the project and discussion group, needing tools similar to mailing lists, bulletin boards, computer conferences. It is important to be aware of other group activities, such as joint editing, even if your standard will not have special support for them, so that you design a standard which will not make such activities difficult. Special ISO standards for specialized group activities like joint editing will probably not come until there is much more research done, and knowledge gathered, on how such activities can be handled in a distributed mail network. 10-Jun-85 13:41:00-PDT,1515;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Mon 10 Jun 85 13:40:44-PDT Date: 10 Jun 1985 11:08:43 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 947 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 947: Title: Multi-Network Broadcasting Within the Internet Author: Ken Lebowitz Mailbox: kjl@BBN-CLXX.ARPA Pages: 5 Characters: 12854 pathname: RFC947.TXT This RFC describes the extension of a network's broadcast domain to include more than one physical network through the use of a broadcast packet repeater. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. 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. ------- 12-Jun-85 12:31:48-PDT,1668;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Wed 12 Jun 85 12:28:55-PDT Date: 12 Jun 1985 10:48:15 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 948 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 948: Title: Two Methods for the Transmission of IP Datagrams Over IEEE 802.3 Networks Author: Ira Winston Mailbox: IRA%UPENN@CSNET-RELAY.ARPA Pages: 5 Characters: 11843 pathname: RFC948.TXT This memo describes two methods of encapsulating Internet Protocol (IP) [1] datagrams on an IEEE 802.3 network [2]. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. 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. ------- 31-Jul-85 16:27:45-PDT,1801;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Wed 31 Jul 85 16:26:08-PDT Date: 31 Jul 1985 13:38:29 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 949 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 949: Title: FTP Unique-Named Store Command Author: Mike Padlipsky Mailbox: PADLIPSKY@USC-ISI.ARPA Pages: 2 Characters: 4130 pathname: RFC949.TXT There are various contexts in which it would be desirable to have an FTP command that had the effect of the present STOR but rather than requiring the sender to specify a file name instead caused the resultant file to have a unique name relative to the current directory. This RFC proposes an extension to the File Transfer Protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. 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. ------- 23-Aug-85 17:30:14-PDT,1174;000000000000 Return-Path: Received: from [192.5.22.82.] (for BRL-AOS) by USC-ECLC; Fri 23 Aug 85 17:29:53-PDT Received: from lll-tis-gw by AOS.BRL.ARPA id a001518; 23 Aug 85 20:07 EDT Return-Path: Received: by lll-tis-b.ARPA; Fri, 23 Aug 85 17:05:53 pdt Message-Id: <8508240005.AA23144@lll-tis-b.ARPA> Date: Fri Aug 23 17:05:51 1985 From: "Michael C. Berch" Subject: PROFS to RFC822/SMTP conversion? To: header-people@MIT-MC.ARPA, msggroup@BRL.ARPA Status: N We're looking for a way to connect IBM systems using the PROFS mail system to the DDN. This presumably would involve producing RFC822 headers and running a SMTP server/client process. Does a product exist that accomplishes either or both of these? This assumes that the IBM system either has a TCP/IP implementation or talks to a gateway that provides TCP/IP service for it. Any information, anecdotes, vendor names, or suggestions gratefully appreciated. Thanks in advance. ----- Michael C. Berch Control Data Corp. / Lawrence Livermore Natl. Laboratory mcb@lll-tis-b.ARPA {akgua,allegra,cbosgd,decwrl,dual,ihnp4,sun}!idi!styx!mcb 26-Aug-85 17:10:50-PDT,2863;000000000000 Return-Path: Received: from BRL-AOS by USC-ECLC; Mon 26 Aug 85 17:10:05-PDT Received: from sumex-aim.arpa by AOS.BRL.ARPA id a022750; 26 Aug 85 19:37 EDT Date: Mon 26 Aug 85 16:35:29-PDT From: Mark Crispin Subject: BBS's: they're at it again To: MsgGroup@BRL.ARPA, Human-Nets@RUTGERS.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: 1 (415) 968-1052 Message-ID: <12138311313.64.CRISPIN@SUMEX-AIM.ARPA> Forgive me if this is old news. I just read in the 26 August issue of Computerworld that Sen. Paul S. Trible Jr. (R.-Va.) has introduced a bill (S. 1305) which would ban "pornographic" messages from computer bulletin boards. In particular, Trible wants to close down "sex talk" computer services and networks run by alleged child molesters who share information about their victims. It is hard to object to making it difficult for child molesters, but it is the other aspects of this bill which are chilling. For several years I have run a BBS which is more or less the electronic equivalent of a bathroom wall. The messages have ranged from the merely crude to the outrageous (in the positive sense), but by and large it's all in fun. There obviously is a social need for what is essentially a public graffitti board. The only run-in my BBS has ever had with the law up to now was about a year ago. A Pacific Bell investigator was looking into a case of toll fraud and wanted whatever information I could provide about a call the BBS got a few weeks prior. I didn't have much to tell the guy since my BBS allows any string for a "name" and "where calling from", but I gave him what little I had. It turned out my info verified to him that he was on the right track, he thanked me and that was the end of it. If S. 1305 passes my BBS and hundreds like it would be made illegal. It is completely unclear as to what constitutes "pornography" -- would a Planned Parenthood BBS providing information about VD be "pornographic"? Granted, my BBS is rather openly "dirty", but all the messages on it are posted by the same people who read them. I don't see who is getting harmed by it, especially since almost all of the escapades described in the messages on my BBS are anatomically impossible! The most idiotic statement I have heard is about children with modems could dial up an X-rated BBS. I wonder what parents have in their heads when they buy their kids modems. What, pray tell, do these parents think these kids are doing with their modems? Calling up BBS's is about the most innocuous thing they can do. Otherwise, they are running up bills on their parents' Visa card calling up CompuServe/Source/etc. or cracking systems they have no business being on. -- Mark -- ------- 27-Aug-85 06:38:33-PDT,887;000000000000 Return-Path: Received: from BRL-AOS (for BRL-AOS) by USC-ECLC; Tue 27 Aug 85 06:37:13-PDT Received: from xerox.arpa by AOS.BRL.ARPA id a029659; 27 Aug 85 9:06 EDT Received: from BacoNoir.ms by ArpaGateway.ms ; 27 AUG 85 06:06:11 PDT Date: 27 Aug 85 09:06:09 EDT (Tuesday) Subject: Re: BBS's: they're at it again In-reply-to: <12138311313.64.CRISPIN@SUMEX-AIM.ARPA> To: Mark Crispin cc: MsgGroup@BRL.ARPA, Human-Nets@RUTGERS.ARPA From: Dave Message-ID: <850827-060611-1950@Xerox> So what if your BBS is "dirty", if people are offended by the content of the messages, then they should not bother calling again. I view this the same way I view "dirty" magazines in a book store, if you don't like that kind of magazine don't buy it. No one is forcing you to read/buy anything you don't want to. 27-Aug-85 11:56:42-PDT,4685;000000000000 Return-Path: Received: from BRL-AOS by USC-ECLC; Tue 27 Aug 85 11:56:17-PDT Received: from cisl-service-multics.arpa by AOS.BRL.ARPA id a008437; 27 Aug 85 14:13 EDT Received: FROM LADC BY CISL-SERVICE-MULTICS.ARPA WITH dial; 27 AUG 1985 14:06:15 EDT Date: Tue, 27 Aug 85 10:52 PST From: Dave Platt To: MsgGroup Subject: Laws concerning BBS I downloaded the following information from a bulletin board a couple of weeks ago... it bears on the same issue as the recent messages from Mark Crispin and Dave Mensing. Particularly disturbing to me is the suggestion that BBS might be required to register with the government as public utilities! It's also disturbing that Congress is writing new laws which would regulate BBS without consulting the very people who write the software and run the boards! [This is disturbing but not particularly surprising to me... I once read someone's advice that if you like either sausages or law you should not observe them in the process of being made... sigh.] If I see any follow-up information (e.g. a contact address for the ad hoc group mentioned in this file) I'll post it also. ----------------------------------------------- BBSLAW01.MSG From Chip Berlet, Public Eye Magazine. HELP FIGHT BAD BBS LAWS - 01 FEDERAL LEGISLATION RESTRICTING BBS OPERATION DUE SOON! POST THIS MESSAGE ON EVERY BBS IN AMERICA! A new federal law that would outlaw some BBS systems and severely restrict all others could be passed by Congress in 1985. A mobilization of SYSOPS and BBS users is urgently needed to ensure we have a chance to speak out on the new law. Watch BBS's for messages with "BBSLAWXX.MSG" headers or "HeLP FIGHT BAD BBS LAWS - XX" titles. An ad-hoc group will be posting these messages on BBS's and the commercial systems. LAWMUG SYSOP Paul Bernstein and I have learned the law could be introduced as soon as MID JULY! Although aspects of the new law have been discussed for months by "experts" in Washington, NOT ONE SYSOP WAS CONSULTED until a June 20 conference in Chicago which Paul and I attended. 0 Vague language in another telecommunications law already introduced in Congress might also restrict BBS activities. We urged the Congressional aide involved in that legislation to exempt BBS systems until we could let SYSOPS and lawyers study the language more carefully. We must also monitor this law. The law restricting BBS operations was prompted by panic over the possibility that children (minors) might read pornographic material, and by the wave of publicity regarding the malicious hackers and illegal credit card and phone information posted on BBS's by electronic graffiti vandals. Among the ideas SERIOUSLY DISCUSSED for the new federal law restricting BBS's are provisions which would require: * Registration of all BBS's as a public utility. * BBS users to log in with, and post their legal names. * SYSOPS to keep a log of all names of users. * SYSOPS to keep a log of all messages & access times. * Criminal penalties for SYSOPS whose BBS's contain had illegal messages posted on them - even if the SYSOP was not aware of the message and had not been informed the message was there nor given a chance to remove it! While the law is currently only being discussed, there is much pressure to restrict and regulate BBS's. A good BBS law could protect BBS's and SYSOPS. A bad law could destroy BBS's in their infancy as a telecommunications phenomena. BBS's put the indivial back into mass society in the age of telecommunications. BBS's encourage information sharing and remove barriers to discussion posed by social status, wealth, class, race, sex, physical size, and many physical handicaps. bBS's encourage the democratic process and are a powerful new communications system which deserves Constitutional protection and First Amendment Rights. NO LEGISLATION WITHOUT REPRESENTATION! There will be differing views of wording, law, and tactics; all should be given a chance to be heard. Congress should delay passage of any BBS legislation until BBS users and SYSOPS have a chance to discuss the legal issues and make their opinions known in a series of Congressional hearings. Our discussion must start immediately and we must organize to block bad BBS legislation until our voices are heard. We share the responsibility. Time is short. Spread the word. It is the electronic age. We are all Paul Revere.... 28-Aug-85 00:50:21-PDT,1457;000000000000 Return-Path: Received: from BRL-AOS by USC-ECLC; Wed 28 Aug 85 00:49:21-PDT Received: from scrc-stony-brook.arpa by AOS.BRL.ARPA id a016129; 28 Aug 85 3:21 EDT Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 302403; Wed 28-Aug-85 03:19:45-EDT Date: Wed, 28 Aug 85 03:20 EDT From: "Robert W. Kerns" Subject: Laws concerning BBS To: Dave Platt cc: MsgGroup In-Reply-To: The message of 27 Aug 85 14:52-EDT from Dave Platt Message-ID: <850828032052.5.RWK@CROW.SCRC.Symbolics.COM> Date: Tue, 27 Aug 85 10:52 PST From: Dave Platt * Registration of all BBS's as a public utility. * BBS users to log in with, and post their legal names. * SYSOPS to keep a log of all names of users. * SYSOPS to keep a log of all messages & access times. * Criminal penalties for SYSOPS whose BBS's contain had illegal messages posted on them - even if the SYSOP was not aware of the message and had not been informed the message was there nor given a chance to remove it! This reminds me very much of the kinds of controls the Soviet Union places on copy machines! I think a lot could be made of the parallel here. I even think the motives are similar! 4-Sep-85 16:08:18-PDT,2390;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Wed 4 Sep 85 16:07:15-PDT Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Wed 4 Sep 85 14:20:43-PDT Date: 4 Sep 1985 14:18:23 PDT Subject: RFC951 Now Available From: Ann Westine 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 951: Title: Bootstrap protocol (BOOTP) Author: Bill Croft and John Gilmore Mailbox: CROFT@SUMEX-AIM.ARPA Pages: 12 Characters: 29038 pathname: RFC951.TXT This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting of two phases. This RFC describes the first phase, which could be labeled 'address determination and bootfile selection'. After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs. The file transfer will typically use the TFTP protocol, since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP or FTP. This RFC suggests a proposed protocol for the ARPA-internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 11-Sep-85 03:34:48-PDT,1685;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Wed 11 Sep 85 03:32:18-PDT Received: from xerox.arpa by AOS.BRL.ARPA id a021279; 11 Sep 85 6:00 EDT Received: from Cabernet.MS by ArpaGateway.ms ; 11 SEP 85 02:59:41 PDT Date: Wed, 11 Sep 85 02:59:36 PDT From: Murray.pa@XEROX.ARPA Subject: Names with spaces - I'd like to remove our trap To: MsgGroup@BRL.ARPA Cc: Murray.pa@XEROX.ARPA, JLarson.pa@XEROX.ARPA Reply-To: Murray.pa@XEROX.ARPA, JLarson.pa@XEROX.ARPA Message-ID: <850911-025941-5393@Xerox> Back in May, somebody at Xerox sent out a message to INFO-NETS with a From line containing a properly quoted space. That blew a few systems out of the water. I don't mean user mail processing systems, but the main operating system. And since the nasty message wasn't accepted, MC tried to send it to them again every half hour or so. I never managed to get a description of the bug. I seem to remember that one of the systems was at Cal Tech, but that was a long time ago. I think somebody at MC mentioned that several people had phoned asking to have the poison message killed. I consider crashing other systems to be antisocial, even if the protocol police couldn't nab us for anything. So I inserted a trap into our mail gateway to prevent such "nasty" messages from getting to the outside world. Well, that was a long time ago. Various users around here have been grumbling. I'd like to remove that trap. ... Did your system have this disease? Have you fixed it yet? What's a reasonable amount of warning to give people before I remove our filter? Any suggestions on how to contact the appropiate people? 12-Sep-85 06:39:36-PDT,1962;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Thu 12 Sep 85 06:39:09-PDT Received: from csnet-pdn-gw by AOS.BRL.ARPA id a010949; 12 Sep 85 9:07 EDT Received: from hplabs by csnet-relay.csnet id aa05033; 12 Sep 85 9:00 EDT Received: by HP-VENUS id AA01224; Wed, 11 Sep 85 21:08:55 pdt Message-Id: <8509120408.AA01224@HP-VENUS> Date: Wed, 11 Sep 85 9:46:27 MDT From: Dave Taylor Subject: Joining the group To: veeger!hpcnof!hplabs!MsgGroup@BRL.ARPA Source-Info: From (or Sender) name not authenticated. Hello! I'd like to join the ARPA MsgGroup if possible. My ARPA address is: hpcnof!dat@HPLABSD.ARPA As far as the latest topics: --------------------------------------- In reference to Mark Crispins' comment about "Pornographic" bulletin boards, I'm in agreement with Mark and Dave Mensing - if people don't like it, they shouldn't read it! What really disturbs me about this proposed law is that part of the justification is that "children playing with computers and modems could log on and read disgusting pornographic material". I agree that this isn't desireable, BUT notice that the government is shifting into the role of 'protector' of the people, rather than the usual 'representative' of the people. The real issue is that this implies that the people in Congress (et al) "know better" what's good for society than society does! This is also exemplified by the new pressure on recording labels to 'rate' their albums before releasing them to the public. As an aside, of course, I question what parents would rather make BBS's illegal than monitor the activities of their children, and, at the same time, think it's pretty naive of our society to think that our children haven't heard/read worse! (Of course, Mark, I haven't ever read your BBS!) --- Dave Taylor hpcnof!dat@HPLABSD.ARPA 12-Sep-85 06:44:33-PDT,713;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Thu 12 Sep 85 06:40:47-PDT Received: from csnet-pdn-gw by AOS.BRL.ARPA id aa11027; 12 Sep 85 9:14 EDT Received: from hplabs by csnet-relay.csnet id ao05033; 12 Sep 85 9:06 EDT Received: by HP-VENUS id AA12141; Thu, 12 Sep 85 01:33:28 pdt Message-Id: <8509120833.AA12141@HP-VENUS> Date: Wed, 11 Sep 85 16:31:06 MDT From: Dave Taylor Subject: oops! To: veeger!hpcnof!hplabs!MsgGroup@BRL.ARPA Source-Info: From (or Sender) name not authenticated. Sorry, but my return address should be: hpcnof!dat@HPLABS.CSNET-RELAY Thanks. -- Dave Taylor 12-Sep-85 12:14:21-PDT,2443;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Thu 12 Sep 85 12:11:53-PDT Received: from simtel20.arpa by AOS.BRL.ARPA id a020502; 12 Sep 85 14:40 EDT Date: Thu 12 Sep 85 12:37:49-MDT From: Mark Crispin Subject: Re: Joining the group To: hpcnou!dat%hplabs.csnet@CSNET-RELAY.ARPA, MsgGroup@BRL.ARPA In-Reply-To: <8509120408.AA01224@HP-VENUS> Message-ID: <12142713573.14.MRC@SIMTEL20.ARPA> Personally, I think rating record albums is an excellent idea. It used to be that kids would buy certain albums because they thought they had racy lyrics on them. Now, they'll buy the albums because they KNOW they have racy lyrics on them, and not be suckered into spending money on an album with a suggestive cover but no actual sexual content. Haven't you noticed that most movies today are PG or R? Only the rauchiest of the raunch gets an X these days, and nothing is more chilling to sales than a G rating. After a while, you get to assume that most of the movies you'll see are R, with an occasional PG "family picture". Turning to kids with modems, I think a better approach is for the government to ban sales or use of modems to persons under the age of 18. If they aren't old enough to drink, smoke, vote, or be tried as an adult in a court of law, they aren't old enough to be trusted to use modems in a responsible manner. Back in the early 70's, the world of computing was quite friendly to the moden/net hopping hacker. There were plenty of systems of there with little or no security, and many guest accounts for those of us who got our jollies at poking around. Today, the primary result of the "personal computer revolution" seems to have been the creation of a generation of kids who: . know Basic as their primary computing language (ugh!) . know spaghetti code and PEEK/POKE as their primary software tools technique . believe that computers exist solely for their entertainment . have no sense of responsibility towards other users of shared facilities . get their jollies at cracking other systems . are glorified by the media as "whiz kids" I'm happy that the personal computer revolution has fizzled out. It was a fad that had its day and is gone. Once computing comes back to the hackers and other responsible users, we ought to see less of silly bills such as S.1305. ------- 12-Sep-85 13:30:29-PDT,1301;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Thu 12 Sep 85 13:28:02-PDT Received: from su-score.arpa by AOS.BRL.ARPA id a023304; 12 Sep 85 15:56 EDT Received: from IMSSS by Score with Pup; Thu 12 Sep 85 12:53:21-PDT Date: 12 Sep 1985 1251-PDT From: Rem@imsss Subject: Banning modems for underaged people? To: MsgGroup%BRL@su-score.ARPA People under 18 years old can get licenses for driving a motor vehicle, which is capable of killing pedestrians and other innocent people. Robotics and networking hasn't yet developed to the point where a random dialup user can issue a command that accidently kills someone. Therefore restrictions on modem usage shouldn't be more drastic than restrictions on driving motor vehicles, they should be gentler. How about requiring a modem license, which involves a simple test on laws regarding privacy of data, value of computer time on various computers, etc. before anyone under 18 can buy or use a modem? Re BBS and song lyrics, I suggest somebody transcribe the lyrics to the various horribly-sick rock-music songs currently popular, and post them on the lewd-BBS, clearly labeled as to the record being transcribed (brand, name of album, song on album, author of lyrics, singer on album). ------- 12-Sep-85 21:58:44-PDT,1358;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Thu 12 Sep 85 21:57:53-PDT Received: from isi-vaxa.arpa by AOS.BRL.ARPA id a026018; 13 Sep 85 0:32 EDT Received: by isi-vaxa.ARPA (4.12/4.7) id AA02786; Thu, 12 Sep 85 21:31:02 pdt From: "Jeffery A. Cavallaro" Message-Id: <8509130431.AA02786@isi-vaxa.ARPA> Date: 12 Sep 1985 2130-PDT (Thursday) To: Mark Crispin Cc: hpcnou!dat%hplabs.csnet@CSNET-RELAY.ARPA, MsgGroup@BRL.ARPA Subject: Re: Joining the group In-Reply-To: Your message of Thu 12 Sep 85 12:37:49-MDT. <12142713573.14.MRC@SIMTEL20.ARPA> Gee, that's funny. The "kids" that you described (getting thrills by breaking into systems, no courtesy on shared systems, exhibiting no responsibility, etc.) would a lot like most undergrads when I went to school. I dare say that things probably haven't changed much. In all seriousness, I am getting tired on THIS community pointing the finger at everyone else and shouting "lack of responsibility !!!". Whether it be discussions about junk mailing lists, excessive flame sessions, or whatever, we better clean up our own backyard. Many times, we are guilty of the same offenses, and many times promote them by are attitudes, actions, and reactions. Ok, I feel better now. Jeff 12-Sep-85 23:25:52-PDT,872;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Thu 12 Sep 85 23:23:20-PDT Received: from usc-ecl.arpa by AOS.BRL.ARPA id a026142; 13 Sep 85 2:00 EDT Date: 12 Sep 1985 22:59-PDT Sender: ESTEFFERUD@USC-ECL.ARPA Subject: Re: Joining the group From: MsgGroup Moderator Reply-To: msggroup-request@BRL.ARPA To: hpcnou!dat%hplabs.csnet@CSNET-RELAY.ARPA To: MRC@SIMTEL20.ARPA, rem%imsss@SU-SCORE.ARPA Cc: MsgGroup@BRL.ARPA Message-ID: <[USC-ECL.ARPA]12-Sep-85 22:59:46.ESTEFFERUD> In-Reply-To: <12142713573.14.MRC@SIMTEL20.ARPA> OK Folks - This topic is outside the domain of MsgGroup interests. Please move it from MsgGroup to some other list. Perhaps Human-Nets would be a better choice, though I cannot speak for the Human-Nets Moderator. Thanks - Stef (Your Favourite Hardnosed BBoard Moderator) 15-Sep-85 15:57:04-PDT,1047;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Sun 15 Sep 85 15:55:58-PDT Received: from rand-unix.arpa by AOS.BRL.ARPA id a000422; 15 Sep 85 18:33 EDT Return-Path: Received: from vortex.UUCP by rand-unix.ARPA; Sun, 15 Sep 85 15:34:31 pdt Date: Sun, 15-Sep-85 10:41:28 PDT From: Lauren Weinstein Subject: Killing people with modems Message-Id: <8509151041.1818.0.VT1.00C@vortex.UUCP> To: MSGGROUP@BRL.ARPA Actually, the Sloan-Kettering Cancer Center case came pretty close. The crackers were almost futzing around with files that involved radiation therapy records for cancer patients. At least they got *close* to those records. It could have been nasty if they had maliciously or accidently altered data in those files. --- Banning modems won't work. You can throw one together with a few chips. Are we going to ban chips, too? Many of the worst crackers aren't even underage, but are adult "infants." --Lauren-- 15-Sep-85 16:02:03-PDT,898;000000000001 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Sun 15 Sep 85 15:57:23-PDT Received: from mit-mc.arpa by AOS.BRL.ARPA id a000435; 15 Sep 85 18:37 EDT Date: Sun 15 Sep 85 18:36:11-EDT From: Gregbo Subject: Re: Joining the group To: msgroup@BRL.ARPA In-Reply-To: <12142713573.14.MRC@SIMTEL20.ARPA> Message-ID: <12143543398.66.MDCG.GDS@MIT-OZ> Supposing there were responsible, under age 18 kids who wanted to seriously develop software? Should they be denied modems? Suppose they were in college and neede the modem to connect to the school computer. Should they be denied modems? Perhaps the ban should be for anyone who does not give reasonable cause why they should own a modem. Purchaser should provide proof of needing the modem, such as school, job, sponsored independent work, etc. --gregbo ------- 16-Sep-85 08:10:41-PDT,1364;000000000001 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Mon 16 Sep 85 08:10:29-PDT Received: from xerox.arpa by AOS.BRL.ARPA id a016362; 16 Sep 85 10:42 EDT Received: from BacoNoir.ms by ArpaGateway.ms ; 16 SEP 85 07:40:40 PDT Date: 16 Sep 85 10:40:36 EDT (Monday) Subject: Re: Joining the group In-reply-to: <12143543398.66.MDCG.GDS@MIT-OZ> To: Gregbo cc: msgroup@BRL.ARPA From: Dave Message-ID: <850916-074040-3916@Xerox> SAY WHAT? Since when should anyone regardless of age be required to give just cause to own a modem? Just because a few misguided kids abuse them is no reason to deny access to anyone under 18. And why 18? I know plenty of 'adults' who if they had the knowledge would not hesitate to take part in similar abuses. The problem isn't the kids its the niaviete' of the companys and the government as to the security of their systems that are the problems. These kids for the most part are performing a service; if a corperate or foreign spy . or an embezzler were to gain access to these systems they could cause much greater damage to the company or nation security in the case of the gov't. Less time should be spent arguing about the kids and more should be spent on beefing up the security on systems!!! < Dave > 16-Sep-85 09:40:02-PDT,1165;000000000001 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Mon 16 Sep 85 09:38:37-PDT Received: from css-ring-gw by AOS.BRL.ARPA id a027938; 16 Sep 85 12:12 EDT Return-Path: Received: from hadron.UUCP by seismo.CSS.GOV with UUCP; Mon, 16 Sep 85 12:03:55 EDT Received: by hadron.UUCP (4.12/4.7) id AA09617; Mon, 16 Sep 85 12:02:48 est Date: Mon, 16 Sep 85 12:02:48 est From: "Joseph S. D. Yao" Message-Id: <8509161702.AA09617@hadron.UUCP> To: MsgGroup@BRL.ARPA, Rem@imsss.arpa Subject: Re: Banning modems for underaged people? > Robotics and networking hasn't yet developed to the point where a random > dialup user can issue a command that accidently kills someone. Hmmm. I seem to remember reading somewhere in a fairly reliable journal of hackers who tied up a medical monitoring computer. This constitutes being able to issue a command that accidentally kills someone. God forbid it should be other than accidental! (God forbid it should happen at all.) If I come across a more precise reference, I will forward it. Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} 16-Sep-85 11:03:13-PDT,1367;000000000001 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Mon 16 Sep 85 11:00:24-PDT Received: from css-ring-gw by AOS.BRL.ARPA id a006805; 16 Sep 85 13:38 EDT Return-Path: Received: from hadron.UUCP by seismo.CSS.GOV with UUCP; Mon, 16 Sep 85 12:17:34 EDT Received: by hadron.UUCP (4.12/4.7) id AA09685; Mon, 16 Sep 85 12:16:11 est Date: Mon, 16 Sep 85 12:16:11 est From: "Joseph S. D. Yao" Message-Id: <8509161716.AA09685@hadron.UUCP> To: Mdcg.Gds%MIT-OZ@MIT-MC.ARPA, msgroup@BRL.ARPA Subject: Re: Joining the group (Banning modems) > From: Gregbo > Perhaps the ban should be for anyone who does not give reasonable > cause why they should own a modem. Purchaser should provide proof of > needing the modem, such as school, job, sponsored independent work, > etc. Modems don't kill people. People kill people. Perhaps we should register modems using the same techniques we should for registering handguns. No more Saturday-night 2400-baud specials. ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) The opinions expressed herein do not reflect the opinions of any conscious, sentient being in Known Space, and I will disavow them strongly if I ever wake up. Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} 16-Sep-85 11:46:28-PDT,2880;000000000001 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Mon 16 Sep 85 11:45:39-PDT Received: from usc-ecl.arpa by AOS.BRL.ARPA id a009024; 16 Sep 85 14:18 EDT Date: 16 Sep 1985 11:15-PDT Sender: ESTEFFERUD@USC-ECL.ARPA Subject: ENOUGH! Re: Joining the group Subject: Re: Killing people with modems Subject: Re: Banning modems for underaged people? From: MsgGroup-Moderator-Einar-Stefferud Reply-To: MsgGroup-Request@BRL.ARPA To: Msggroup@BRL.ARPA Cc: "Attn: Dave-Taylor" Cc: "Attn: Mark-Crispin" Cc: Rem%imsss@SU-SCORE.ARPA Cc: "Attn: Jeffery-A-Cavallaro" Cc: "Attn: Gregbo" Cc: "Attn: Lauren-Weinstein" Cc: "Attn: Dave" Cc: "Attn: Joseph-S-D-Yao" Message-ID: <[USC-ECL.ARPA]16-Sep-85 11:15:15.ESTEFFERUD> Gentle People All -- After careful review of the subject messages, I find that the discussion still has nothing to do with the focusing topic of MsgGroup, which is dedicated to network mail system issues. The lack of discussion on network mail system issues is no excuse to abuse the list with other topics, especially when randomly initiated by a naive new member who has not done his homework. You will note that on September 12, I requested that discussion of this new topic be terminated in MsgGroup. You will also note that some people appear to be quite oblivious to my request. TAKE NOTE: Additional messages on this topic will be taken as a requests for the sender's removal from the MsgGroup mailing list. SURVEY of the discussion so far: Joining the group 1961 chars Wed, 11 Sep 85 9:46:27 MDT From: Dave Taylor Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Tue 17 Sep 85 01:11:16-PDT Received: from mit-mc.arpa by AOS.BRL.ARPA id a021704; 17 Sep 85 3:45 EDT Date: Tue, 17 Sep 85 03:43:50 EDT From: "Christopher C. Stacy" Subject: Banning modems for underaged people? To: hadron!jsdy@seismo.ARPA cc: MsgGroup@BRL.ARPA In-reply-to: Msg of Mon 16 Sep 85 12:02:48 est from Joseph S. D. Yao Message-ID: <[MIT-MC.ARPA].647405.850917.CSTACY> It just occurred to me that anyone can telephone a fire department and have them dispatched to an imaginary emergency. This could prevent the firemen from being dispatched to a real fire in time to save property or even lives. Clearly telephones should require operator's liscenses, only issued to persons over the age of eighteen years, and all such users of these dangerous devices should be registered with the government. Maybe The Phone Company could surgically implant identification transponders in telephone users to ensure that only approved persons could use the communications terminal. 17-Sep-85 10:39:58-PDT,2416;000000000001 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Tue 17 Sep 85 10:39:41-PDT Received: from csnet-pdn-gw by AOS.BRL.ARPA id a010913; 17 Sep 85 13:00 EDT Received: from hplabs by csnet-relay.csnet id ab13648; 17 Sep 85 12:49 EDT Received: by HP-VENUS id AA15336; Mon, 16 Sep 85 21:34:01 pdt Message-Id: <8509170434.AA15336@HP-VENUS> To: veeger!hpcnof!hplabs!MsgGroup@BRL.ARPA Date: Mon, 16 Sep 85 22:15:23 MDT From: Dave Taylor Subject: Mail headers and electronic communications Source-Info: From (or Sender) name not authenticated. In the past few weeks I've been exploring the ARPA/non-arpa gateway capabilities, and have encountered a number of electronic- mail related oddities. I'd like to present them herein and request information on what they mean and (perhaps) how to avoid getting them. This first section is about message headers... 1. A lot of mail I get has the header changed from a 'To:' line to an "Apparently-To:" line. For example: Apparently-To: What I surmise is that the ARPA system validates all addresses before sending mail out, and this address can't be verified... 2. I've also gotten mail with a header of the form "Not-Verified: hpcnof!dat@HPLABSD.ARPA" presumably, this is the same beast rearing it's head... The next question has to do with addressing... I've noticed that my electronic mail return address varies and is either "hpcnof!dat@HPLABSD.ARPA", "hpcnof!dat@HPLABS@CSNET-RELAY" or "hpcnof!dat%HPLABS@CSNET-RELAY". Why the difference when they are all coming from the ARPA system? What's the precedence of the '%' sign? Finally.. On the message that the MsgGroup moderator sent out there were a number of 'Subject:' lines - is this legal RFC-822 header? Also, how does one correctly parse and assign relative importance to the variety of possible return addresses in a message? The one's I've seen are: "From: address" "Reply-To: address" "Sender: address" I presume that the priority of building return addresses is Reply-To, then From, then a parse of the message path, then as a final resort the Sender. Is this right? Trying to understand the confusion, -- Dave Taylor hpcnof!dat%HPLABS@CSNET-Relay 17-Sep-85 10:41:25-PDT,2577;000000000001 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Tue 17 Sep 85 10:41:03-PDT Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Tue 17 Sep 85 08:54:49-PDT Date: 17 Sep 1985 08:50:27 PDT Subject: RFC955 Now Available From: Ann Westine 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 955: Title: Towards a Transport Service for Transaction Processing Applications Author: Robert Braden Mailbox: Braden@UCLA-CCN.ARPA Pages: 10 Characters: 23066 pathname: RFC955.TXT The DoD Internet protocol suite includes two alternative transport service protocols, TCP and UDP, which provide virtual circuit and datagram service, respectively. These two protocols represent points in the space of possible transport service attributes which are quite "far apart". We want to examine an important class of applications, those which perform what is often called "transaction processing". We will see that the communication needs for these applications fall into the gap "between" TCP and UDP -- neither protocol is very appropriate. This RFC is concerned with the possible design of one or more new protocols for the ARPA-Internet, to support kinds of applications which are not well supported at present. The RFC is intended to spur discussion in the Internet research community towards the development of new protocols and/or concepts, in order to meet these unmet application requirements. It does not represent a standard, nor even a concrete protocol proposal. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 18-Sep-85 14:50:44-PDT,2058;000000000001 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Wed 18 Sep 85 14:46:51-PDT Received: from mit-multics.arpa by AOS.BRL.ARPA id a009703; 18 Sep 85 16:52 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2673377384553614@MIT-MULTICS.ARPA>; 18 Sep 1985 16:49:44 edt Date: 17 Sep 85 23:01 +0100 From: Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: 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: Subject: Default receiver list on REPLY Message-ID: <123173@QZCOM> In-Reply-To: <[USC-ECL.ARPA]16-Sep-85 11:15:15.ESTEFFERUD> Thank you, Mr Moderator, for helping to make my reading of this mailing list easier. I assume that all other participants also appreciate to keep discussions in their proper forum, but there could be a simple answer to good persons not having taken the appropriate action in time: many mail system (to my knowledge) are lacking a facility to easily change the reveicer list when composing a REPLY to something; some BB systems have very thight walls between different topics. (One bad example is vanilla VAXMAIL.) In our group communication ("conferencing") system it is very easy to modify the receiver list (Add/Subtract type commands). BUT this is not used as often as it should! People seem to concentrate so much on the contents that they forget about the framework (reveicers). I am considering a mode where the user is shown the inherited set of receivers followed by a confirmation question. Possibly users should then learn quickly to add an extra "YES" before starting on the text, but ... Anyone else having opinions on this? Tommy Ericson PS I should add that I do not consider the discussions on laws etc. and of no interest (on the contrary!), but I would like to follow it in a more proper forum, saving my poor brain from too many context switches. 22-Sep-85 14:13:38-PDT,5059;000000000001 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Sun 22 Sep 85 14:11:12-PDT Received: from rand-unix.arpa by AOS.BRL.ARPA id a017382; 22 Sep 85 16:49 EDT Return-Path: Received: by rand-unix.ARPA; Sun, 22 Sep 85 13:50:23 pdt From: Jim Guyton Message-Id: <8509222050.AA13263@rand-unix.ARPA> To: HUMAN-NETS@rutgers.ARPA, MsgGroup@BRL.ARPA Cc: IRList%vpi@csnet-relay.ARPA Cc: rand-docs@RAND-UNIX.ARPA Subject: Electronic Document distribution experiment Date: 22 Sep 85 13:50:19 PDT (Sun) ARPANET ANNOUNCEMENT The Rand Corporation is conducting an experiment in electronic publishing. The documents listed below have been fully reviewed and published as printed Rand publications. By making the same document (excluding tables and graphics) available on the ARPANET, Rand is attempting to assess the needs of the electronic user. If you are interested in copying any of the documents, please contact RAND-DOCS@RAND-UNIX.ARPA. We will send you an electronic questionnaire, and as soon as you complete and return it, we will supply the information you need to access the document. We may also send you a follow-up questionnaire to get your reaction to the electronic document. If you find that the electronic version doesn't meet your needs because of the missing illustrations and graphics, you can then contact RAND-DOCS and order a printed copy of the document which will be sent to you via the U.S. Post. We welcome any comments or suggestions on this experiment. Just send all correspondence to RAND-DOCS@RAND-UNIX.ARPA. AVAILABLE TITLES R-3283-NSF/RC "Toward an Ethics and Etiquette for Electronic Mail," by N.A. Shapiro, R.H. Anderson. July 1985. (95K bytes) R-3160-AF "ROSS: An Object-Oriented Language for Constructing Simulations," by D. McArthur, P. Klahr, S. Narain, October 1984. (64K bytes) R-3158-AF "TWIRL: Tactical Warfare in the ROSS Language," by P. Klahr, J.W. Ellis, Jr., W.D. Giarla, S. Narain, E.M. Cesar, Jr., S. Turner, September 1984. (150K bytes) ABSTRACTS of above documents: R-3283-NSF/RC. Toward an Ethics and Etiquette for Electronic Mail. N.A. Shapiro, R.H. Anderson. July 1985, 35 pp., $4.00 This report discusses some important general attributes of electronic mail and message systems, and the effects of those attributes on the quality and appropriateness of communication. The authors discuss the "etiquette" of sending and receiving electronic mail, drawing on personal observation of inappropriate and counterproductive uses of these systems. By presenting some initial guidelines, the authors attempt to accelerate the process by which social customs and behavior appropriate to electronic mail become established, and thereby to accelerate the effective use of such systems. R-3160-AF. ROSS: An Object-Oriented Language for Constructing Simulations. D. McArthur, P. Klahr, S. Narain. October 1984, 28 pp., Ref., $4.00 This report provides an overview of ROSS, an object-oriented language currently being developed at Rand. The goal of ROSS is to provide a programming environment in which users can conveniently design, test, and modify large knowledge-based simulations of complex mechanisms. Object-oriented programming languages, and ROSS in particular, enforce a message-passing style of programming in which the system to be modeled is represented as a set of objects and their behaviors (rules for object interaction). This style is especially suited to simulation, since the mechanism or process to be simulated may have a decomposition that maps naturally onto objects, and the real-world interactions between the objects may be easily modeled by object behaviors and object message transmissions. In addition to describing some of the basic ROSS commands and features, the report discusses some software that interfaces directly with ROSS, including a sophisticated screen-oriented editor and a color graphics package. Facilities for browsing among objects and their behaviors are also described, and examples of browsing and editing are presented using SWIRL, a military combat simulation written in ROSS. R-3158-AF. TWIRL: Tactical Warfare in the ROSS Language. P.Klahr, J.W. Ellis, Jr., W.D. Giarla, S. Narain, E.M. Cesar, Jr., S.Turner, September 1984, 49 pp., Bibliog., $4.00 This report describes TWIRL, a simulation of a primarily ground combat engagement between two opposing military forces. It was developed to further experiment with the ROSS language, an object-oriented simulation language that was successfully used to develop the SWIRL air battle simulation, and to develop a prototype simulation that could be used to explore issues in electronic combat. The authors describe the objects that comprise TWIRL and provide extensive examples of object behaviors to explain and illustrate the process of building a simulation in ROSS. 25-Sep-85 11:02:56-PDT,2467;000000000001 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Wed 25 Sep 85 11:02:07-PDT Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Wed 25 Sep 85 09:08:47-PDT Date: 25 Sep 1985 09:07:47 PDT Subject: RFC956 Now Available From: Ann Westine 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 956: Title: Algorithms for Synchronizing Network Clocks Author: D. L. Mills Mailbox: Mills@USC-ISID.ARPA Pages: 26 Characters: 68868 pathname: RFC956.TXT This RFC discussed clock synchronization algorithms for the ARPA-Internet community, and requests discussion and suggestions for improvements. The recent interest within the Internet community in determining accurate time from a set of mutually suspicious network clocks has been prompted by several occasions in which errors were found in usually reliable, accurate clock servers after thunderstorms which disrupted their power supply. To these sources of error should be added those due to malfunctioning hardware, defective software and operator mistakes, as well as random errors in the mechanism used to set and synchronize clocks. This report suggests a stochastic model and algorithms for computing a good estimator from time-offset samples measured between clocks connected via network links. Included in this report are descriptions of certain experiments which give an indication of the effectiveness of the algorithms. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 3-Oct-85 10:50:29-PDT,2298;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Thu 3 Oct 85 10:47:05-PDT Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Thu 3 Oct 85 09:09:38-PDT Date: 3 Oct 1985 09:04:03 PDT Subject: RFC957 Now Available From: Ann Westine 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 957: Title: Experiments in Network Clock Synchronization Author: D. L. Mills Mailbox: Mills@USC-ISID.ARPA Pages: 27 Characters: 70490 pathname: RFC957.TXT This RFC discusses some experiments in clock synchronization in the ARPA-Internet community, and requests discussion and suggestions for improvements. One of the services frequently neglected in computer network design is a high-quality, time-of-day clock capable of generating accurate timestamps with small errors compared to one-way network delays. Such a service would be useful for tracing the progress of complex transactions, synchronizing cached data bases, monitoring network performance and isolating problems. In this memo one such clock service design will be described and its performance assessed. This design has been incorporated as an integral part of the network routing and control protocols of the Distributed Computer Network (DCnet) architecture. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 11-Oct-85 14:59:02-PDT,1991;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Fri 11 Oct 85 14:58:48-PDT Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Fri 11 Oct 85 12:14:17-PDT Date: 11 Oct 1985 11:07:14 PDT Subject: RFC958 Now Available From: Ann Westine 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 958: Title: Network Time Protocol (NTP) Author: D. L. Mills Mailbox: Mills@USC-ISID.ARPA Pages: 14 Characters: 31520 pathname: RFC958.TXT This document describes the Network Time Protocol (NTP), a protocol for synchronizing a set of network clocks using a set of distributed clients and servers. NTP is built on the User Datagram Protocol (UDP), which provides a connectionless transport mechanism. It is evolved from the Time Protocol and the ICMP Timestamp message and is a suitable replacement for both. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 15-Oct-85 22:56:54-PDT,1436;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Tue 15 Oct 85 22:54:21-PDT Received: from mit-multics.arpa by AOS.BRL.ARPA id a012276; 16 Oct 85 1:33 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2675474810733497@MIT-MULTICS.ARPA>; 12 Oct 1985 23:26:50 edt Date: 11 Oct 85 11:43 +0100 From: Per_Lindberg_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, MSGGROUP@BRL-AOS.ARPA Cc: Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: BBS's: they're at it again Message-ID: <127141@QZCOM> In-Reply-To: <12138311313.64.CRISPIN@SUMEX-AIM.ARPA> A very important point there, Mark! It sounds very similar to that case about a year ago, where the police impounded some poor guy's home computer because his BBS contained a calling card number entered anonymously by some criminal. (The story was told by Jerry Pournelle in BYTE magazine about a year ago). It is impossible that a BBS sysop could be held responsible for information entered by others, just as supermarket owners cannot possibly be held responsible for notes on their billboards. Once you start to censor, you have to censor *everything*. 17-Oct-85 06:57:08-PDT,13931;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Thu 17 Oct 85 06:52:58-PDT Received: from csnet-pdn-gw by AOS.BRL.ARPA id a004316; 17 Oct 85 9:06 EDT Received: from hplabs by csnet-relay.csnet id ao05575; 17 Oct 85 8:58 EDT Received: by HP-VENUS id AA03533; Wed, 16 Oct 85 17:58:16 pdt Message-Id: <8510170058.AA03533@HP-VENUS> To: veeger!hpcnof!hplabs!hpccc!mcgregor@CSNET-RELAY.ARPA, veeger!hpcnof!hplabs!hpcea!laubach@CSNET-RELAY.ARPA, veeger!hpfcla!hpisla!tw@CSNET-RELAY.ARPA, veeger!hpcnof!hplabs!hpcea!wunder@CSNET-RELAY.ARPA Date: Tue, 15 Oct 85 9:01:42 MDT From: Dave Taylor Subject: Summary of mail headers Cc: veeger!hpcnof!hplabs!MsgGroup@BRL.ARPA Organization: Hewlett Packard, Colorado Networks Operation X-Location: Fort Collins, Colorado, USA X-Mailer: msg [version 2.1c] Source-Info: From (or Sender) name not authenticated. The following document is submitted for review and revision. So far I know of one errata: it doesn't contain the "Status:" header (generated by mailx). Please address all comments to me so as we can generate a correct and up-to-date list. -- Dave ----------------------------------------------------------------------------- Summary of Network Mail Headers ------------------------------- Dave Taylor Hewlett Packard, Colorado Networks Operation Last Revision: October 11th, 1985 This document contains an exhaustive description of each of the possible mail headers from electronic messages sent/received or shipped through any of the following networks: USENET (uucp), ARPANET, BITNET, and CSNET. While every effort has been made to make this list complete, there are still some headers that are not included. If any errors, inac- curacies or omissions are found, please mail the information includ- ing a sample header to me at ihnp4!hpfcla!d_taylor or hplabs!hpcnou!d_taylor. (This list is ordered more or less alphabetically) 1. Apparently-To: This header indicates that the message is destined to a network that does not do address verification. For example, if a message were sent from ARPA to a non-ARPA address, it would have this header included. Example: Apparently-To: 2. Bcc: - Blind Carbon Copies This is used by the sender of the message to have copies of the message go to people without the 'main' adressees knowing about it. They are the "lowest" of the three groups of people who can receive a message (This is like giving a Xerox (tm) of your memo to your office mate...) Example: Bcc: jack@NLM-VAX, my_boss 3. Cc: This header indicates whom the secondary recpients of the mes- sage are. These people will receive copies of the message, but not via directl addressing. (This is similar to the carbon-copies func- tion on a standard office memo). Example: Cc: hplabs!hpcnof!d_taylor, joe@HARVARD.EDU 4. Comments: This is for the addition of arbitrary text in the header of an outgoing message. Example: Comments: This mail was generated by a test version of mailit, a new program that does inter-domain host verification using psychic communications. If it doesn't get the mail to you - you'll feel a slight chill... 5. Date: The date and time the message was sent (or the date and time that the message hit the first 'intelligent' mailer - which will add this field if it isn't present). Example: Date: Fri, Jan 19, 1985 12:04 MST 6. Encrypted: This header is for the sending and receiving of encrypted mail, and (usually) indicates the encryption program used. It can option- ally include a public key encryption key (which, by itself, is use- less). Example: Encrypted: public-encode, SECUREMAIL 7. From The From line where From isn't followed by a colon is added by the receiving mail system and simply indicates what time the mail was received. If the mail was sent by someone else on the same sys- tem, the second field will indicate their username, otherwise it is essentially useless information. Example: From dat Wed Aug 7 1985 00:04:03 MST 8. From: This From line is generated by the senders mail system, and will usually indicate not only the address the message took to get there, but also has the full name of the sender. Sometimes this header will be generated by a mailer en-route, in which case only the address will be present. "Smartmailers" (mail transport sys- tems) update the address on the From: line as it passes through their machine... Example: From: ihnp4!dartvax!eddy (Eddy Van Halen) 9. >From Certain mailers (the 'un-smartmailers') don't update the From: line and in fact do absolutely the minimum needed to indicate pas- sage of the message. This includes simply rewriting the "From" line (see the first "From" header above) by prefixing it with a '>' char- acter and appending "remote from ". Example: >From uucp Wed Sep 25 03:40:09 1985 remote from veeger 10. In-Reply-To: This header is generated when a message is a direct response to another message and can have two forms; either using the Message-Id or actually using the From: line and the Date: line. The following is an example of the latter form... Example: In-Reply-To: Message from "wrap@AMES (Joe Wrap)" of 12 Sep 85 20:37:01 EDT 11. Keywords: This is used to indicate keywords or phrases to help categorize the incoming message. It is generated by the sender... Example: Keywords: mail, electronic communications, standards, addressing 12. Message-Id: This is a unique message identification number and is generated by the sending mailer. The format for the id number is (usually): YYMMDDHHMM{SS}.@hostname{domain(s)} For example, if a message is sent by someone at MIT-LAB on the 6th of August 1985 at 9:02:03 am, the message id would be: Message-Id: <850806090203.xxxx@MIT-LAB.EDU.ARPA> Also, if the sender doesn't generate this header, a 'smartmailer' along the way will include one relative to that machine. Example: Message-Id: <8502040302.42432@HP.COM.ARPA> 13. Posted-Date: This is a permutation of the "Date:" field. See "Date:". Example: Posted-Date: Mon, 12 Aug 85 23:30:46 pdt 14. Received: This is added by each mail transport system relaying the mes- sage. It indicates sending and receiving hosts and the current date and time at that point. Oftentimes, this header will also include a unique message identification number for tracking purposes. Examples: Received: by HP-VENUS id AA00541; Mon, 7 Oct 85 10:29:09 pdt Received: from CMU-CS by UCB-VAX.ARPA (4.24/5.3) 15. References: This is used to indicate a referenced article or message (as opposed to "replying to" a message). Most commonly, this is used in conjunction with notes or news (electronic conferencing systems) to indicate mail in reference to a specified article or posting. Example: References: Your posting in net.mail (hpcnoe.302) of 4 Jan, 85 16. Reply-To: This indicates a return address for the receiver if they desire to respond to the message. This address superscedes the address generated (en-route) on the "From:" line. Most commonly, this is used by an individual mailing for a group so that any response to the individual will go to the group instead. Example: Reply-To: HUMAN-NETS@RUTGERS 17. Resent- When someone forwards mail to a third party the original headers will be prepended with "Resent-" to preserve the informa- tion. The headers that currently are allowed to be prefixed in this manner are: Resent-Bcc: Resent-Date: Resent-From: Resent-Message-ID: Resent-Reply-To: Resent-Sender Resent-To: Resent-cc: Each field is documented elsewhere herein. 18. Return-Path: This header is added at message recption by the mail transport system and is intended to indicate the return address of the sender. This is superceded by 'Reply-To:' for responses, if it's present. Example: Return-Path: basic!doug@uw-july 19. Sender: This is used when the person originating the message is dif- ferent from the person actually sending the message. For example, if I have a secretary, my mail could be "From:" me, but the "Sender:" would be my secretary. Example: Sender: hplabs!STEFAN@USC-ECL 20. Sent: A variation of the "Date:" field. Example: Sent: Friday, June 28th 1985 at 3:19 pm 21. Subject: This indicates, in one line usually, a summarized subject of the message. Example: Subject: thoughts on your proposal... 22. To: Indicates the person or persons that the mail message is directly addressed to (as opposed to 'cc:' and 'bcc:' above). The list of names may appear on an arbitrary number of lines. Example: To: Dave Taylor 23. Via: Usually indicative of a gateway transition, this is added by the gateway software transitioning from one network to another. The example below is from a message sent from the CSNET to the Usenet.. Example: Via: CSNet; 18 Sep 85 14:26-PDT Extensions and User Defined Fields ---------------------------------- There are many more headers that can be found in electronic mail (some of which are listed below) and often the personal headers are prefixed by "X-", since it is guaranteed that any extensions to the mail headers will not begin with these two letters. It is important to note that this section is by no means complete - there are a great number of strange headers floating about. I've tried to document the most common and most interesting ones here. 24. Latitude: This header indicates the relative Latitude and Longtitude (geographic location) of the sender. Theoretically, if you have a "Great Circle" program, you could feed it these entries and your own location and figure out how far away from you they are. It's of dubious use, though. Example: Latitude: 40.4166 Longitude: 86.9166 25. Organization: This is a quite common header (with it's European variant "Organisation:") and indicates the organization that the sender works for or is attending (in the case of a University). Examples: Organisation: the Antelope project, Kruislaan 312, Amsterdam Organization: Hewlett Packard, Colorado Networks Operation 26. Origin: This is mostly used to verify that the sending username is actually the person who sent it. it contains the tty device sending the message, the hostname of the machine and the date sent. Example: Origin: tty613 on hpccc; Mon, 23 Sep 85 09:48:38 PDT 27. Phase-Of-The-Moon: This is a strangely popular header that is presumed to indicate what phase the moon is in at the senders' site...more dubious infor- mation! Example: Phase-Of-The-Moon: Waning Crescent (18% of Full) 28. Phone: The telephone number by which the sender can be reached (usu- ally their work phone number). Example: Phone: +31 20 5924122, +31 20 947183 29. Postal-Address: The "overland" (non-electronic) mail address for the sender of the message. Example: Postal-Address: Dave Taylor, HP Colorado Networks, 3404 East Harmony Road Fort Collins, Colorado 80525 30. Sunrise: What time sunrise and sunset are at the senders location. Example: Sunrise: 6:23 Sunset: 19:08 (CST) 31. Telephone: This is the same as 'Phone:' above. Example: Telephone: (415) 857-5875 32. X-Location: This is the geographic location of the sender. Example: X-Location: Fort Collins, Colorado, USA 33. X-Mailer: This indicates what mailer the sender used to compose and actu- ally transmit the message. It's usually used to indicate non- standard mailers... Example: X-Mailer: fastmail [version 1.0] 34. X-Sent-By-Nmail_Version: This is the same as the "X-Mailer:" header, only much more specific. It should, in fact, be absorbed into the previous header. Example: X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 18-Oct-85 17:35:12-PDT,4311;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Fri 18 Oct 85 17:33:13-PDT Received: from rand-unix.arpa by AOS.BRL.ARPA id a003905; 18 Oct 85 20:03 EDT Return-Path: Received: from vortex.UUCP by rand-unix.ARPA; Fri, 18 Oct 85 16:31:40 pdt Date: Fri, 18-Oct-85 09:46:23 PDT From: Lauren Weinstein Subject: header doc Message-Id: <8510180946.664.0.VT1.00C@vortex.UUCP> To: MSGGROUP@BRL.ARPA I have been unable to reach the author directly, so I'm posting this reply I made to his posting in Usenet. Note that I'm not trying to criticize the author, but rather to avoid the havoc which might result if that preliminary document is taken as absolute in its current form. --- I do hope people aren't going to take that document in its current form and use it as a reference. In particular, the descriptions of From_ (From followed by space) >From_ From: Return-Path: Sender: are woefully inadequate and misleading. By failing to indicate the important variations between uucp format and 822 format use of such headers, all sorts of confusion may result. For example, saying that smart sites SHOULD update the From: line is very misleading. Updating of that sort has caused lots of problems since the From: line (which is supposed to be an 822 format line) is not subject to uniform handling across the networks. Especially when @-sign addresses are present, but in general even when only ! addresses are present, the From:, To:, and other 822 lines should be LEFT ALONE by all intermediate sites. The uucp From_ line (and >From_ lines), must either be left on messages to provide routing info or else folded into a single From_ line (NOT a From: line unless the site doing the folding is absolutely certain it is folding all info from the various From_ and >From_ lines CORRECTLY, and only when @-addresses are not in use). If a site insists on folding From_ and >From_ lines, it should never do so unless Received: lines are being added, since otherwise important date/time transit info is lost. If a site is going to try create a new From: line from the From_ and >From_ lines, it must do so only completely on that basis, NOT by simply trying to update the existing From: line which may rooted off of a different address. If an @ address is present it must not try do this under any conditions, since incorrect hybrid addresses almost always result. And the site must still always be sure to properly add a new From_ line, update the >From_ lines or create a new folded From_ line as appropriate. The existence of From_ and >From_ lines is critical. Once again, the best solution is to never count on the From: line as being an accurate route back to the author unless it is in 822 @-form. Such addresses, especially, should not be touched by intermediate sites under any conditions. Return-Path is also not reliable as a return address. In general, for pure uucp mail, the only valid return address for replies is that generated from the From_ and >From_ lines. Use of the From: line is possible in some cases, especially when @-addresses are present instead of ! addresses with smart mailers. But if intermediate sites insist on trying to do simple updates of the From: lines based on existing From: lines, the information in the From: line frequently will be incomplete. The recommendation is that sites stop trying to update the From: lines at all, both in the presence of @ addresses and in the presence of simple ! addresses or hybrids. Leaving From: alone in all cases is probably the best solution in all cases in the long run. In the short run, those ARPA gateways that modify the From: lines now while we're still in our hybrid environment should realize that it is very important that they create their new From: lines based on the correct info (as discussed above). Eventually, under domains, such modifications of the From: lines will be completely undesirable in all cases. As we move toward domain addressing, many of these problems with From:, etc. will gradually become of less significance (assuming we can get sites to stop modifying these lines and just leave them alone in most cases!) --Lauren-- 25-Oct-85 07:06:33-PDT,2589;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Fri 25 Oct 85 07:05:26-PDT Received: from csnet-pdn-gw by AOS.BRL.ARPA id a022428; 25 Oct 85 7:25 EDT Received: from hplabs by csnet-relay.csnet id af01813; 25 Oct 85 7:19 EDT Received: by HP-VENUS id AA08794; Thu, 24 Oct 85 14:22:55 pdt Message-Id: <8510242122.AA08794@HP-VENUS> To: veeger!hpcnof!hplabs!MsgGroup@BRL.ARPA Date: Thu, 24 Oct 85 14:36:08 MDT From: Dave Taylor Subject: More thoughts on mail headers Organization: Hewlett Packard, Colorado Networks Operation X-Location: Fort Collins, Colorado, USA X-Mailer: msg [version 2.1c] Source-Info: From (or Sender) name not authenticated. Since I posted my original mail header document I've gotten a number of messages about it. There seem to be two types of notes in general: 1. You forget this header: 2. You don't know what you're talking about with what you say about header
- in the ideal mail system that means . The first kind are great! I've added at least 25 headers since I first passed it out to the net (I'll be posting a new copy soon) It's the second kind that bother me - These people just seem to have missed entirely the title of the list; "Summary of Network Mail Headers" the title is most certainly NOT "How Mailers Should Generate and Use Headers" or "The Ultimate Mail System"!! Nonetheless, it has become quite apparent to me that some people are misinterpreting the definitions of various mail headers (most specifically stuff like "Received:", "From:" and so on (especially the issue of 'smart' versus 'dumb' mailers!)). For that purpose, I'd like to propose that those very same people get together and write a companion document that details "What The Headers Should Mean". Seriously. In the meantime, PLEASE! I'm trying to create a valid, up-to-date document that lists WHAT HEADERS THERE ARE AND WHAT THEY ARE USED FOR. If you don't like my definitions, okay. Mail me another one and we'll see what we can do...if you don't like the purpose I've indicated, then, if you have a better definition that jibes with the apparent use of the header in mail that I HAVE ON MY COMPUTER, then we'll change it. If not, then contact the "What the Headers Should Mean" group! Slightly annoyed, --- Dave Taylor hplabs!hpcnou!dat ihnp4!hpfcla!d_taylor or hpcnou!dat@HPLABSD.ARPA hpcnou!dat@HPLABS.CSNET-RELAY 25-Oct-85 09:01:45-PDT,1258;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Fri 25 Oct 85 08:58:19-PDT Received: from css-ring-gw by AOS.BRL.ARPA id a029040; 25 Oct 85 11:25 EDT Return-Path: Received: from hadron.UUCP by seismo.CSS.GOV with UUCP; Fri, 25 Oct 85 11:10:18 EDT Received: by hadron.UUCP (4.12/4.7) id AA24790; Fri, 25 Oct 85 11:05:29 edt Date: Fri, 25 Oct 85 11:05:29 edt From: "Joseph S. D. Yao" Message-Id: <8510251505.AA24790@hadron.UUCP> To: hpcnou!dat@hplabs.csnet Subject: Re: Summary of mail headers Cc: MsgGroup@BRL.ARPA, suz@seismo.ARPA, tsp@seismo.ARPA Dave, RPA RFC 822 allows many user-defined fields. Sendmail has used return-receipt-to to have a receipt sent (by sendmail) when the message arrives at the destination machine. The Navy's TOFACS system wanted their mailer to send receipts only when the "to" and/or "cc" addressees actually read the mail. The non-portable version does this with funny mailers; the portable version does this by putting "Send-receipt: " in the header. Once the header is sent, this becomes (became?) "Sent-receipt: ", in case the mailbox header file has to be re-built. Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} 25-Oct-85 09:57:06-PDT,2113;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Fri 25 Oct 85 09:54:23-PDT Received: from usc-ecl.arpa by AOS.BRL.ARPA id a000415; 25 Oct 85 12:29 EDT Date: 25 Oct 1985 09:28-PDT Sender: ESTEFFERUD@USC-ECL.ARPA Subject: Re: More thoughts on mail headers From: ESTEFFERUD@USC-ECL.ARPA To: hpcnou!dat%hplabs.csnet@CSNET-RELAY.ARPA Cc: msggroup@BRL.ARPA Message-ID: <[USC-ECL.ARPA]25-Oct-85 09:28:18.ESTEFFERUD> In-Reply-To: <8510242122.AA08794@HP-VENUS> Hello Dave - I can appreciate your annoyance at finding some grizzled oldtimers who question seriously whether or not the new kid on the block is doing the right thng when he publishes what might be viewed by some as "The Definitive Word on What Message Headers Mean In The Real World" I am one of those who are so concerned, because we have had lots of trouble with inconsistent interpretations, which is the problem you are alsdo trying to address. Unfortunately, such things are very hard to resolve by unilateral actions by self appointed "Straightener-Outers". It more typically requires some sort of joint effort that includes enough of the old timers to avoid just recyling through all the old resolved and unresolved problems one or more additional times. So, here is a suggestion that should remove your sources of annoyance, and let you go ahead without annoying others with an apparent usurpation of implied authority to restate all the Internet Mail Header Definititons. I would just put an explanation of your project in your draft, at the beginning. This explanation should say much of what you said in the message to which I am replying-to. It should disclaim any authority to carry any formal definitions. It should be very clear about this. As I understand it, you are conducting a survey and building a document that describes how headers are really being used, versus how they may be formally defined? I think this can be very useful as we proceed to build more and more gateways among disparate mail domains. Best Regards, and Good Luck! - Stef 25-Oct-85 11:48:49-PDT,2070;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Fri 25 Oct 85 11:46:00-PDT Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Fri 25 Oct 85 09:58:52-PDT Date: 25 Oct 1985 09:56:18 PDT Subject: RFC959 Now Available From: Ann Westine 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 959: Title: File Transfer Protocol (FTP) Author: J. Postel, and J. K. Reynolds Mailbox: JKReynolds@USC-ISIB.ARPA Pages: 69 Characters: 151249 pathname: RFC959.TXT This memo is the official specification of the File Transfer Protocol (FTP) for the DARPA Internet community. The primary intent is to clarify and correct the documentation of the FTP specification, not to change the protocol. The following new optional commands are included in this edition of the specification: Change to Parent Directory (CDUP), Structure Mount (SMNT), Store Unique (STOU), Remove Directory (RMD), Make Directory (MKD), Print Directory (PWD), and System (SYST). Note that this specification is compatible with the previous edition. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 25-Oct-85 22:51:50-PDT,560;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Fri 25 Oct 85 22:51:14-PDT Received: from mit-mc.arpa by AOS.BRL.ARPA id a010123; 26 Oct 85 1:31 EDT Date: Sat, 26 Oct 85 01:30:13 EDT From: "Steven A. Swernofsky" Subject: removal To: ESTEFFERUD@USC-ECL.ARPA cc: SASW@MIT-MC.ARPA, msggroup@BRL.ARPA In-reply-to: Msg of 25 Oct 1985 09:28-PDT from ESTEFFERUD at USC-ECL.ARPA Message-ID: <[MIT-MC.ARPA].693445.851026.SASW> Please remove me from the msggroup mailing list. Thank you. -- Steve 28-Oct-85 20:28:53-PST,25034;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Mon 28 Oct 85 20:26:59-PST Received: from csnet-pdn-gw by AOS.BRL.ARPA id a001537; 28 Oct 85 21:54 EST Received: from hplabs by csnet-relay.csnet id aq02530; 28 Oct 85 21:33 EST Received: by HP-VENUS id AA15708; Mon, 28 Oct 85 17:01:14 pst Message-Id: <8510290101.AA15708@HP-VENUS> To: veeger!hpcnof!hplabs!MsgGroup@BRL.ARPA Date: Mon, 28 Oct 85 13:44:48 MST From: Dave Taylor Subject: New Copy of Mail Header Summary Organization: Hewlett Packard, Colorado Networks Operation X-Location: Fort Collins, Colorado, USA X-Mailer: msg [version 2.2] Source-Info: From (or Sender) name not authenticated. After some good discussion and feedback, here's the latest version of the document: Summary of Network Mail Headers ------------------------------- Dave Taylor Hewlett Packard, Colorado Networks Operation Last Revision: October 28th, 1985 This document contains an exhaustive description of each of the possible mail headers from electronic messages sent/received or shipped through any of the following networks: USENET (uucp), ARPANET, BITNET, and CSNET. While every effort has been made to make this list complete, there are still some headers that are not included. If any errors, inac- curacies or omissions are found, please mail the information includ- ing a sample header to me at ihnp4!hpfcla!d_taylor or hplabs!hpcnou!d_taylor. It should also be noted that this document describes the current use of the various headers, and should NOT be taken as defining the correct use (according to the various standards) of any fields. Further, where-ever possible, I've tried to indicate where the divergence appears. (This list is ordered more or less alphabetically) 1. Action: This header is used to give the recipients direction on what action needs to be taken upon receipt of this message. Example: Action: Call me (x2419) immediately upon receipt! 2. Apparently-To: This header indicates that the message is destined to a network that does not do address verification. For example, if a message were sent from ARPA to a non-ARPA address, it would have this header included. Alternatively, if the mail on the sending machine doesn't con- tain a "To:" line in the message, the mail transport will add one using this notation...(this can also happen if SMTP doesn't find a To: line in the message) Example: Apparently-To: 3. Author: This is used to credit authorship of notes/articles. This is most commonly used when mail is sent into a different network (for example, the "AUGMENT" system at McDonnell Douglas) to credit the original author, or to give credit on article excerpts (from Newspa- pers, magazines, books, etc). Example: Author: Andrew McGettrick, From his book: "The Definition of Programming Languages" Pages 16-17 4. Bcc: (Blind Carbon Copies) This is used by the sender to have copies of the message go to people without the 'main' adressees knowing about it. They are the "lowest" of the three groups of people who can receive a message (This is like giving a Xerox (tm) of your memo to your office mate or boss...) Example: Bcc: jack@NLM-VAX, my_boss 5. Bfcc: (Blind File Carbon Copy) Similar to Bcc, but a copy of the mes- sage will go to the specified file silently, rather than to another person (please see also "Fcc:" and "Fto:"). Example: Bfcc: /users/dat/mail/mailheader.2 6. Cc: This header indicates whom the secondary recpients of the mes- sage are. These people will receive copies of the message, but not via directl addressing. (This is similar to the carbon-copies func- tion on a standard office memo). Example: Cc: hplabs!hpcnof!d_taylor, joe@HARVARD.EDU 7. Comments: This is for the addition of arbitrary text in the header of an outgoing message. Example: Comments: This mail was generated by a test version of mailit, a new program that does inter-domain host verification using psychic communications. If it doesn't get the mail to you - you'll feel a slight chill... 8. Date: The date and time the message was sent. Alternatively, if the message doesn't have this field and passes through certain mail transport systems (notably 'sendmail'), this field will be added. Note: This is not correct behaviour according to the legal definition of the electronic mail protocol. Example: Date: Fri, Jan 19, 1985 12:04 MST 9. Draft-Composition-Date: This is used by smart mail front ends that detect usage of the form "mailer < file" and then do a stat(2) on the file. This field indicates the last modified date of the file being transmitted in this fashion. Example: Draft-Composition-Date: Aug 02, 85 14:50:30 MST 10. Encrypted: This header is for the sending and receiving of encrypted mail, and (usually) indicates the encryption program used. It can option- ally include a public key encryption key (which, by itself, is use- less). Example: Encrypted: public-encode, SECUREMAIL 11. Expiration-Date: This is used for mail that has a limited 'lifespan' (like an announcement of a meeting - it is just trash once the meeting has been held!). Smart mail readers/browsers will see this header and check the date against the current date. If the expiration date of the message has passed, the mailer will silently remove the mail from your incoming mailbox. Example: Expiration-Date: Aug 03, 86 12. Fcc (File Carbon Copy) This is used similar to a normal 'Cc:' header, but indicates that a copy of this message should be saved as it goes off to the wild unknown, in the specified file. Example: Fcc: /users/dat/mail/arpa/mail-headers/version2 13. From_ The From line where From isn't followed by a colon is added by the receiving mail system and simply indicates what time the mail was received. If the mail was sent by someone else on the same sys- tem, the second field will indicate their username, otherwise it is essentially useless information. Note: since this is added by the receiving mail system, it is not part of the legal definition and can vary according to the requirements of the local mail system. Example: From dat Wed Aug 7 1985 00:04:03 MST 14. From: This From line is generated by the senders mail system, and will usually indicate not only the address the message took to get there, but also the full name of the sender. Sometimes this header will be generated by a mailer en-route, in which case only the address will be present. Note: some mailers prepend their machine name to the address field of the "From:" line but this is incorrect behaviour according to the official standard. Specifically, mail should be received with a "From:" line of the form "From: user@machine.domain" (username)" where domain is UUCP, ARPA, CSNET or whatever. This is NOT currently supported on any USENET systems, only on ARPA, BITNET and CSNET. Example: From: ihnp4!dartvax!eddy (Eddy Van Halen) 15. >From Certain mailers don't update the From: line and in fact do absolutely the minimum needed to indicate passage of the message. This includes simply rewriting the "From" line (see the first "From" header above) by prefixing it with a '>' character and appending "remote from ". Note: again, according to the standard internet protocol, this is not a valid mail header and should be instead something resembling the "Received:" header (documented herein). Nonetheless, mail tran- sports should also NOT alter the From: line. Example: >From uucp Wed Sep 25 03:40:09 1985 remote from veeger 16. Fto: This can be used in place of the normal "To:" header in mail if you desire just to send the mail to a specified file, rather than to a person or persons. Why anyone would bother to use mail just to save a message to a file is unknown by the author, however!!! Example: Fto: /users/dat/saved-mail/thoughts.3 17. In-Reply-To: This header is generated when a message is a direct response to another message and can have two forms; either using the Message-Id or actually using the From: line and the Date: line. The following is an example of the latter form... Example: In-Reply-To: Message from "wrap@AMES (Joe Wrap)" of 12 Sep 85 20:37:01 EDT 18. Keywords: This is used to indicate keywords or phrases to help categorize the incoming message. It is generated by the sender... Example: Keywords: mail, electronic communications, standards, addressing 19. Mail-From: This is functionally identical to the "Received:" lines, which are much more common. Example: Mail-From: CMU-CS by UCB-VAX.ARPA (4.24/5.3) 20. Mail-from: Similar to "Mail-From:", this header is most commonly used by transmission gateways (such as an Ethernet system gateway). Example: Mail-from: SU-NET host Score rcvd at 17-Oct-85 0633-PDT 21. Message-Id: This is a unique message identification number and is generated by the sending mailer. The format for the id number is (usually): YYMMDDHHMM{SS}.@hostname{domain(s)} For example, if a message is sent by someone at MIT-LAB on the 6th of August 1985 at 9:02:03 am, the message id would be: Message-Id: <850806090203.xxxx@MIT-LAB.EDU.ARPA> Also, if the sender doesn't generate this header, a 'smartmailer' along the way will include one relative to that machine. Example: Message-Id: <8502040302.42432@HP.COM.ARPA> 22. Posted-Date: This is a permutation of the "Date:" field. See "Date:". Example: Posted-Date: Mon, 12 Aug 85 23:30:46 pdt 23. Received: This is added by each mail transport system relaying the mes- sage. It indicates sending and receiving hosts and the current date and time at that point. Oftentimes, this header will also include a unique message identification number for tracking purposes. Examples: Received: by HP-VENUS id AA00541; Mon, 7 Oct 85 10:29:09 pdt Received: from CMU-CS by UCB-VAX.ARPA (4.24/5.3) 24. Redistributed- Functionally identical to the "Resent-" header series. Note that "Resent-" is the official internet prefix for this purpose. Example: Redistributed-By: ihnp4!hpfcla!d_taylor (Dave Taylor) 25. References: This is used to indicate a referenced article or message (as opposed to "replying to" a message). Most commonly, this is used in conjunction with notes or news (electronic conferencing systems) to indicate mail in reference to a specified article or posting. Example: References: Your posting in net.mail (hpcnoe.302) of 4 Jan, 85 26. Remailed- This is also functionally identical to the official Internet header "Resent-". Please see "Resent-" for more information. Example: Remailed-To: arpavax!bitnetvax!johnson 27. Reply-To: This indicates a return address for the receiver if they desire to respond to the message. This address superscedes the address generated (en-route) on the "From:" line. Most commonly, this is used by an individual mailing for a group so that any response to the individual will go to the group instead. Example: Reply-To: HUMAN-NETS@RUTGERS 28. Resent- When someone forwards mail to a third party the original headers will be prepended with "Resent-" to preserve the informa- tion. The headers that currently are allowed to be prefixed in this manner are: Resent-Bcc: Resent-Date: Resent-From: Resent-Message-ID: Resent-Reply-To: Resent-Sender Resent-To: Resent-cc: Each field is documented elsewhere herein. 29. Return-Path: This header is added at message recption by the mail transport system and is intended to indicate the return address of the sender. This is superceded by 'Reply-To:' for responses, if it's present. Example: Return-Path: basic!doug@uw-july 30. Sender: This is used when the person originating the message is dif- ferent from the person actually sending the message. For example, if I have a secretary, my mail could be "From:" me, but the "Sender:" would be my secretary. Example: Sender: hplabs!STEFAN@USC-ECL 31. Sent: A variation of the "Date:" field. (Note: This is also used as an analogous field to the "Received:" field on some machines, but is put on as the message LEAVES a system, rather than as it is RECEIVED by a system) Examples: Sent: Friday, June 28th 1985 at 3:19 pm or Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP 1985-Oct-17 11:10:31 PST (=GMT-8) 32. Source-Info: This is added by a mail transport that is on a system such as the ARPA system that can check machine addresses against a list of valid addresses. The presence of this header indicates that there was probably either a discrepency in the list, or that the machine simply couldn't verify something for some reason... Example: Source-Info: From (or Sender) name not authenticated. 33. Subject: This indicates, in one line usually, a summarized subject of the message. Example: Subject: thoughts on your proposal... 34. Time: This is identical to the "Date:" field. Please see "Date:" for more information. Example: Time: Sun, Jan 29, 1985 17:31:02 MST 35. To: Indicates the person or persons that the mail message is directly addressed to (as opposed to 'cc:' and 'bcc:' above). The list of names may appear on an arbitrary number of lines. Example: To: Dave Taylor 36. Via: Usually indicative of a gateway transition, this is added by the gateway software transitioning from one network to another. The example below is from a message sent from the CSNET to the Usenet.. Example: Via: CSNet; 18 Sep 85 14:26-PDT Extensions and User Defined Fields ---------------------------------- There are many more headers that can be found in electronic mail (some of which are listed below) and often the personal headers are prefixed by "X-", since it is guaranteed that any extensions to the mail headers will not begin with these two letters. It is important to note that this section is by no means complete - there are a great number of strange headers floating about. I've tried to document the most common and most interesting ones here. 37. Latitude: This header indicates the relative Latitude and Longtitude (geographic location) of the sender. Theoretically, if you have a "Great Circle" program, you could feed it these entries and your own location and figure out how far away from you they are. It's of dubious use, though. Example: Latitude: 40.4166 Longitude: 86.9166 38. Organization: This is a quite common header (with it's European variant "Organisation:") and indicates the organization that the sender works for or is attending (in the case of a University). Examples: Organisation: the Antelope project, Kruislaan 312, Amsterdam Organization: Hewlett Packard, Colorado Networks Operation 39. Origin: This is mostly used to verify that the sending username is actually the person who sent it. it contains the tty device sending the message, the hostname of the machine and the date sent. Example: Origin: tty613 on hpccc; Mon, 23 Sep 85 09:48:38 PDT 40. Phase-Of-The-Moon: This is a strangely popular header that is presumed to indicate what phase the moon is in at the senders' site...more dubious infor- mation! Example: Phase-Of-The-Moon: Waning Crescent (18% of Full) 41. Phone: The telephone number by which the sender can be reached (usu- ally their work phone number). Example: Phone: +31 20 5924122, +31 20 947183 42. Postal-Address: The "overland" (non-electronic) mail address for the sender of the message. Example: Postal-Address: Dave Taylor, HP Colorado Networks, 3404 East Harmony Road Fort Collins, Colorado 80525 43. Status: This header is generated and used at the receiving end by the (Berkeley) mailx mailer and it's derivatives, and indicates the "status" of the individual message. Known values for the field are: N - new R - read RO - read, old (saved to file and re-read) Example: Status: RO 44. Sunrise: What time sunrise and sunset are at the senders location. Example: Sunrise: 6:23 Sunset: 19:08 (CST) 45. Telephone: This is the same as 'Phone:' above. Example: Telephone: (415) 857-5875 46. X-Location: This is the geographic location of the sender. Example: X-Location: Fort Collins, Colorado, USA 47. X-Mailer: This indicates what mailer the sender used to compose and actu- ally transmit the message. It's usually used to indicate non- standard mailers... Example: X-Mailer: fastmail [version 1.0] 48. X-Sent-By-Nmail_Version: This is the same as the "X-Mailer:" header, only much more specific. It should, in fact, be absorbed into the previous header. Example: X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 The Electronic Library ("The Journal") Interface Headers -------------------------------------------------------- There is also a proprietary electronic mail interface to a library/conference system/database at McDonnell Douglas Advanced Systems Division that creates the following headers... The following is an essentially verbatim transcription of informa- tion sent to the author by Duane Stone of the Advanced Systems Divi- sion of McDonnell Douglas... 49. Access: Used to declare whether a Journal item should be Public or Private (to those that are on the distribution list or Extended Access list) Example: Access: Unrestricted 50. Acknowledge-Delivery: Used to request the system mailer send back a message when it has successfully delivered the item. Example: Acknowledge-Delivery: Requested 51. Acknowledge-Receipt: Used to to ask the recipient to acknowledge receipt of the mes- sage. Example: Acknowledge-Receipt: Requested 52. Addendum-To: A pointer to a previously submitted Journal item. Example: Addendum-To: 53. Delivery-Timing: Used by the sender to indicate when the message should be sub- mitted to the mail transport system Rush: - immediate Soon: - an hour or less Defer: - overnight Start Delivery: DATE/TIME Stop Delivery: DATE/TIME (if not yet delivered) 54. Disposition-Code: Used by the system to group Journal items into one of several classes for eventual archive to tape and as an indicator of how long the archive tapes should be retained. Example: Disposition-Code: Temporary (2 years) 55. Extended-Access: Used with private Journal items to allow access by other than those on the distribution list. Example: Extended-Access: ASD.MDC 56. Length: This is computed when the message is sent and gives the reci- pients an estimate of the number of pages in the document. Example: Length: 6 pages [estimate] 57. Location: Used to submit the message to the Journal. The adressees receive a short citation with other header fields and a "Location:" field pointing to a file in an electronic library. Example: Location: 58. Part-Of: A pointer to a previously submitted Journal item. Example: Part-Of: 59. Route-To: Used to send a message "in-turn" to addressees in the "To:" field -- as opposed to the broadcast method of delivery where every- one gets the message "simultaneously". Any addresses in the "Cc:" field receive a copy of the message each time it is passed from one adressee to the enxt in the "To:" field. Example: Route-To: john, hisvax!richard 60. Signed: Created when the user emplys the Sign command; used to elec- tronically sign a message. It affixes a signature-block to a mes- sage and does a checksum on the characters in the body of the mes- sage. Access to the signature is password protected. A "Verify Signature" command is available to recipients that lets them find out if anyone has changed the body of the message since the message was signed. Example: SIGNED Duane L. Stone App. Dev. Mgr. 61. Supersedes: A pointer to a previously submitted Journal item. Example: Supersedes: 30-Oct-85 15:40:10-PST,3629;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Wed 30 Oct 85 15:39:20-PST Received: from css-ring-gw by AOS.BRL.ARPA id a002306; 30 Oct 85 12:43 EST Return-Path: Received: from hadron.UUCP by seismo.CSS.GOV with UUCP; Wed, 30 Oct 85 12:21:03 EST Received: by hadron.UUCP (4.12/4.7) id AA03097; Wed, 30 Oct 85 08:56:17 est Date: Wed, 30 Oct 85 08:56:17 est From: "Joseph S. D. Yao" Message-Id: <8510301356.AA03097@hadron.UUCP> To: hpcnou!dat@hplabs.csnet Subject: Re: New Copy of Mail Header Summary Cc: MsgGroup@BRL.ARPA Dave, I'd thought from previous mail that somebody'd caught you on these; but you still have problems with "From_" and ">From_". You also had a small problem with "Status: ". I hope the following will help. Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} ================ 13. From_ The From line where From isn't followed by a colon is the first line of the standard mail header on certain mail systems (e.g., all UNIX systems). On some systems, this is all that is recognised as a mail header; it does not have to be followed by a blank line. The first word after "From_" is the user name of the user that sent the mail. The rest of the line should contain the date and time of origination of the mail in some format. The user name field can sometimes be complicated by mail handlers that don't properly pass on the user name. When a message is passed between systems using 'uucp', the entire line has " remote from " appended to it while being sent. The receiving system is then supposed to remove this and put the system name before the user name, separated by a '!'. If the recipient is then on a further machine, this process gets repeated. This is the mechanism by which one gets names such as: ihnp4!seismo!decvax!harvard!yao Note: This is not part of the ARPA header definition and can vary according to the requirements of the local mail system. Perhaps it should instead be something resembling the "Received:" header (docu- mented herein). Nonetheless, mail transports should also NOT alter the From: line. [Dave, I don't understand that last sentence, but I left it in: it's all yours. The sentence before it should definitely reference From: and Date: rather than Received: ; but I don't know how the sentences relate. -jsdy-] Examples: From dat Wed Aug 7 1985 00:04:03 MST From jsdy Wed Sep 25 03:40:09 1985 remote from hadron From hadron!jsdy Wed Sep 25 03:40:09 1985 15. >From_ Those mailers that expect to see "From" followed by a space and no colon can not allow this pattern to actually exist in a message. Therefore, wherever it is found, it is preceded by a '>'. This is not really a part of the mail header, but a by-product of it. Example: >From the halls of Montezuma, ... 43. Status: This header is generated and used at the receiving end by the Berkeley mail reader and its derivatives (such as AT&T mailx), and indicates the "status" of the individual message. Known values for the field are: O - unread, but header was seen and message preserved R - read (first time only) RO - read, old (preserved or saved in another file) An absent "Status: " field means that the message is new and has not yet been seen. Example: Status: RO ================ PS: I notice "Send-receipt:" and "Sent-receipt:" didn't make it. Too late, or too arcane? -jsdy- 30-Oct-85 15:40:44-PST,1370;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Wed 30 Oct 85 15:40:18-PST Received: from purdue-merlin.arpa by AOS.BRL.ARPA id a003439; 30 Oct 85 13:32 EST Message-Id: <8510301831.AA19737@merlin.Purdue.EDU> Received: by merlin.Purdue.EDU; Wed, 30 Oct 85 13:31:49 EST To: MsgGroup@BRL.ARPA Subject: Re: New Copy of Mail Header Summary In-Reply-To: Your message of Wed, 30 Oct 85 08:56:17 est. <8510301356.AA03097@hadron.UUCP> Date: 30 Oct 85 13:31:41 EST (Wed) From: "Christopher A. Kent" Note: This is not part of the ARPA header definition and can vary according to the requirements of the local mail system. Perhaps it should instead be something resembling the "Received:" header (docu- mented herein). Nonetheless, mail transports should also NOT alter the From: line. Hmm. I take exception with the last sentence -- mail transports *should* alter the From: line if it's no longer accurate. For example, when a message passes through a uucp site, the From: line needs to have the sitename tacked on to the front, or the recipient will not be able to reply. This is a problem with source routed addresses in general. In the ideal world of flat name space and domain servers handling "routing" decisions, your statement is true. I think. chris ---------- 30-Oct-85 15:41:42-PST,1104;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Wed 30 Oct 85 15:41:31-PST Received: from im4u.arpa by AOS.BRL.ARPA id a007821; 30 Oct 85 16:03 EST Posted-Date: Wed, 30 Oct 85 15:00:12 cst Received: from pop.UTEXAS.EDU by im4u (4.22/4.22) id AA27611; Wed, 30 Oct 85 15:00:20 cst Date: Wed, 30 Oct 85 15:00:12 cst From: Smoot Carl-Mitchell Message-Id: <8510302100.AA12248@pop.UTEXAS.EDU> Received: by pop.UTEXAS.EDU (2.0/4.22) id AA12248; Wed, 30 Oct 85 15:00:12 cst To: msggroup@BRL.ARPA Subject: Re: New Copy of Mail Header Summary According to the interent mail standard we are required to modify From: lines. We do it here all the time. Generally our internet relay mailer checks each header line to insure that *all* hostnames are the fully qualified domain names and not nicnames, which is forbidden. Internally we use nicnames and non-fully qualified hostnames. It is far easier for a user to type smoot@sally than smoot@sally.utexas.edu. The mailers expand the host part when the message gets sent to a remote host. 31-Oct-85 00:42:50-PST,1024;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Thu 31 Oct 85 00:42:34-PST Received: from mit-multics.arpa by AOS.BRL.ARPA id a000755; 31 Oct 85 1:05 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2677025052776498@MIT-MULTICS.ARPA>; 30 Oct 1985 21:04:12 est Date: 30 Oct 85 23:20 +0100 From: Lisa_Carlson%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, MSGGROUP@BRL-AOS.ARPA Cc: Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: BBS's: they're at it again Message-ID: <131085@QZCOM> In-Reply-To: <127141@QZCOM> Wer're going to have Paul Trible's and Sen. Leahy's aides as speakers at the ENA conference next week and should have some interesting respnoses from them about this issue.... 1-Nov-85 16:12:06-PST,1667;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Fri 1 Nov 85 16:10:01-PST Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Fri 1 Nov 85 14:11:40-PST Date: 1 Nov 1985 14:09:16 PST Subject: RFC Now Available From: Ann Westine 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 962: Title: TCP-4 Prime Author: M. A. Padlipsky Mailbox: Padlipsky@USC-ISIA.ARPA Pages: 2 Characters: 2885 pathname: RFC962.TXT This memo is in response to Bob Braden's call for a transaction oriented protocol (RFC-955), and continues the discussion of a possible transaction oriented transport protocol. This memo does not propose a standard. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 7-Nov-85 17:29:49-PST,504;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Thu 7 Nov 85 17:29:44-PST Received: from radc-multics.arpa by AOS.BRL.ARPA id a019432; 7 Nov 85 19:57 EST Date: Thu, 7 Nov 85 19:51 EST From: Poulin@RADC-MULTICS.ARPA Subject: addition To: MsgGroup@BRL.ARPA Message-ID: <851108005149.063213@RADC-MULTICS.ARPA> Please add us to the MsgGroup info list. Thanks, Poulin at RADC-MULTICS Herrmann at RADC-MULTICS 9-Nov-85 12:02:56-PST,1763;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Sat 9 Nov 85 12:01:56-PST Received: from mit-multics.arpa by AOS.BRL.ARPA id a010068; 9 Nov 85 14:34 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2677864951017278@MIT-MULTICS.ARPA>; 09 Nov 1985 14:22:31 est Date: 09 Nov 85 17:56 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: MSGGROUP@BRL-AOS.ARPA Subject: Re: Summary of mail headers Message-ID: <133623@QZCOM> In-Reply-To: <8510251505.AA24790@hadron.UUCP> If you are conducting a survey of headers in actual real use, as different from what is said in any standard says, then a header used in the COM system may be of interest. The header is a variant of the "CC" header, meaning almost the same as "CC", but with the difference that you especially request anyone who prepares a reply with the "answer all" or similar command in their mail system, NOT to send such replies to the recipient in this extra header. The same thing can be handled by use of the REPLY-TO clause, but as I have pointed out in previous messages, the REPLY-TO clause is ambiguous since RFC822 specifies three different allowed non-compatible uses of this clause. I am not sure what to call this additional header we have invented in an RFC822 environment. At present we are converting to "BCC" so as to use a header which others can understand, even if this is not quite correct use of the "BCC" header. Locally, we call this special header "Single copy" but I know this is not usable in an RFC822 environment since blanks in the names of headers will be frowned upon. 10-Nov-85 08:49:39-PST,479;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Sun 10 Nov 85 08:48:53-PST Received: from ornl-msr.arpa by AOS.BRL.ARPA id a012140; 10 Nov 85 11:27 EST Received: by ORNL-MSR.ARPA (4.12/4.9) id AA12054; Sun, 10 Nov 85 11:26:03 est Date: Sun, 10 Nov 85 11:26:03 est From: "James A. Mullens" Message-Id: <8511101626.AA12054@ORNL-MSR.ARPA> To: msggroup@BRL.ARPA Subject: please add me to mail list 10-Nov-85 22:13:14-PST,3710;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Sun 10 Nov 85 22:08:59-PST Received: from su-ai.arpa by AOS.BRL.ARPA id a013700; 11 Nov 85 0:44 EST X-Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Nov-10 21:33:56 PST (=GMT-8hr) X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP Date: 1985 November 10 21:32:37 PST (=GMT-8hr) Message-id: SU-IMSSS.REM.A132454047104.G0357 From: Robert Elton Maas To:MSGGROUP@BRL.ARPA Subject:problems with toplevel domains and other proposed domains Sender: for undeliverable-mail notifications Reply-to: temporary until nameservers up Background: on the NameDroppers list arose a heated debate on what worldwide toplevel domains should be, how all the United-States domains (COM, MIL, EDU, et al) should sit under .US or .USA instead of at the very top, whether multi-national corporations such as IBM and ITT should be required to name their hosts according to the country they reside in instead of internationally, etc. But the moderator insisted that wasn't an appropriate topic, and should be moved elsewhere, suggesting MsgGroup. The MsgGroup moderator accepted: | Date: 05 Nov 85 09:19:11 PST (Tue) | From: Einar Stefferud | Your DOMAIN NAMING for mail systems topic is fine with me for MsgGroup. I haven't seen anybody actually send a message on this topic. Apparently nobody realized the topic has been moved here, everybody thinks it's dead. Oh well. On a related topic... The last I heard, Stanford still didn't have a domain, because nobody could get a working nameserver that was owned&operated by a Stanford-community host, apparently the task fell on some Unix host but nobody could get a working nameserver that ran under Unix, or somesuch, or nobody could agree who would manage the Stanford.EDU namespace because of interdepartmental rivalry. Anyway for whatever reason, it looks like Stanford may not have a subdomain for a long time. IMSSS and other Stanford hosts would like to get a domain-system address, to simplify software and ease communication. So my idea today is maybe we should punt Stanford.EDU for now. It seems the purpose of the domain system is to separate the issue of who assigns names and assures correct protocol, from the issue of what network(s) a host is connected to and where the host is located. Therefore it seems not at all unreasonable for Stanford hosts to be registered in some other domain that is willing to register them and enter their TCI/IP address or mailbridge address in the nameservers for that domain. For example, if MIT.EDU has a working registry and nameserver, why not register MIT.EDU create a sub-domain STANFORD.MIT.EDU and register IMSSS and other desperate Stanford hosts there? Later if and when STANFORD.EDU ever exists, those hosts can trickle over to that subdomain. One side-effect of such unexpected registry would be that we'd get through people's thick skulls that the naming conventions of domain system deal simply with name registry, not with network affiliation etc., and it's the job of the nameserver to map from registry to network. What does the MsgGroup community think of my idea regarding: (1) compliance with letter and spirit of name-domain system, (2) getting the job done today instead of next century, (3) technical problems, (4) likelihood of significant numbers of Stanford hosts being willing to do this, (5) political problems, (6) confusion from people getting messages that say FROM:REM@IMSSS.STANFORD.MIT.EDU, (7) any other pro/con issues?