29-May-84 19:07:18-PDT,164;000000000001 Date: 24 May 84 18:23:00 PDT From: MsgGroup Moderator (Einar Stefferud) To: MsgGroup Subject: MSGGROUP#2301 Survey MsgGroup.2251-2300 29-May-84 19:49:21-PDT,1138;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Tue 29 May 84 19:49:11-PDT Received: From su-score.arpa.ARPA by BRL-MIS via smtp; 29 May 84 22:10 EDT Date: Tue 29 May 84 19:01:09-PDT From: Mark Crispin Subject: Re: redistribution lists To: mike@BRL-TGR.ARPA cc: utzoo!laura@SEISMO.ARPA, MsgGroup@BRL-MIS.ARPA In-Reply-To: Message from "Mike Muuss " of Tue 29 May 84 18:58:15-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Mike - You're wrong. The DEC-20's (the machine is a PDP-10; there is no such thing as a PDP-20) don't discard the MAIL FROM field. They use it as is. The bug is that they can't tell the difference between "null MAIL FROM" and "MAIL FROM unspecified". In the former you should discard the message on failure; in the latter you should parse the header to get a sender. We only do the latter action. The problem is that we support non-Internet networks which don't negotiate something like "MAIL FROM". -- Mark -- ------- 1-Jun-84 02:21:50-PDT,1833;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Fri 1 Jun 84 02:21:30-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 1 Jun 84 4:53 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 1 Jun 84 4:50 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2632380559806888@MIT-MULTICS.ARPA>; 01 Jun 1984 04:49:19 edt Date: 31 May 84 12:23 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, msggroup@BRL-AOS.ARPA Subject: redistribution lists Message-ID: <57434@QZCOM> In-Reply-To: <57297@QZCOM> In a computer conferencing system, the organizer of a conference can remove from a conference items which do not agree with the subject of the conference. This facility should of course used with much care, but correctly used it is a very important facility in keeping discussions to the subject of the conference. This facility would be very valuable to have also in a network environment. The way it is implemented in the COM conference system, the organizer does not delete the text of the item, only the link between the item and his conference. Thus, if the same item had been sent to other receivers (people or conferences) they would continue to receive it. Also, when an organizer removes an item from a conference in COM, the organizer is encouraged to move the item to another more suitable conference. If a facility for mailing list editors to edit their mailing lists in this way is added in future message standards, I think the way COM has implemented this should be considered. 1-Jun-84 03:03:08-PDT,2458;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Fri 1 Jun 84 03:00:26-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 1 Jun 84 5:03 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 1 Jun 84 4:58 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2632380603079551@MIT-MULTICS.ARPA>; 01 Jun 1984 04:50:03 edt Date: 31 May 84 12:33 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: msggroup@BRL-AOS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Subject: Multiple sendings of the same message Message-ID: <57435@QZCOM> I have now corrected the "bug" in the COM-RFC-mail interface which caused us to send out the same message more than once in some cases. I apologize for the incovenience this has caused members of this mailing list. We all have to learn the hard way! In fact, the way the COM-RFC-mail interface did work previously is not without interest. What it did, and what caused the multiple sendings of the message, was that every time a new receiver was added to a previously sent message, the message was sent anew to all its old receivers who had already got it. From the COM viewpoint, this is not an unreasonable way of working. Because if the receiving system was a COM system, COM would not show the message again to COM users who had already read the message. What COM would do, when receiving again a message it already has received, with one or more new receivers in the TO and CC lists, would be just to update the TO and CC information in the COM data base for this text item. In this way, a COM user who wanted to find out who were the receivers of a message would always get the most up-to-date information available. But of course, a COM-RFC-mail interface should adjust itself to the standards and practices in the RFC-mail world, and I have thus modified the COM-RFC-mail interface. When developing better future mail standards, there is however reason to consider having a facility for telling previous receivers of a message that new receivers have been added to that message, preferably without having to send out the whole message again. The GILT standard has such a facility. 1-Jun-84 03:23:16-PDT,990;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Fri 1 Jun 84 03:19:46-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 1 Jun 84 5:03 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 1 Jun 84 4:59 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2632380649321309@MIT-MULTICS.ARPA>; 01 Jun 1984 04:50:49 edt Date: 31 May 84 12:53 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, msggroup@BRL-AOS.ARPA Subject: IFIP X.MHS standards discussions and implementations Message-ID: <57443@QZCOM> Is there any mailing list for people who are interested in the interpretation and implementation of the IFIP X.MHS (X.400) mail standards? If so, which mailing list? 2-Jun-84 06:30:44-PDT,3536;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Sat 2 Jun 84 06:29:28-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 2 Jun 84 8:59 EDT Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 2 Jun 84 8:50 EDT Date: 2 June 1984 08:52-EDT From: Robert Elton Maas Subject: redistribution lists --> conferences&magazines&links etc. To: Jacob_Palme_QZ%QZCOM.MAILNET@Mit-Multics.ARPA cc: MSGGROUP@Brl-Aos.ARPA It seems to me that more useful than conferences would be followup-links and magazines and keyword-access. Magazines are very close to conferences in logic design: Submitters propose articles, and the editor selects which ones will be included in each issue. What do you think of the similarity and differences? Keyword access gives an alternate way to introduce new topics/discussions from conference/magazine. Method 1 is for a customer to have a list of keywords heesh is interested in, and automatically receive in his keyword mailbox all articles with those keywords that are marked as "new-subject". Presumably all "old-subject" messages would either be received or not according to whether their predecessors were received or not (except when the customer grows tired of a topic and asks to stop receiving follow-ups from some point). Method 2 is for a customer to receive a summary of keywords in all "new-topic" messages, and then to manually pick which to read and which not. After reading such "new-topic" messages, heesh could decide whether to subscribe to the follow-up stream or not. Follow-up links are the preferred way I'd like to control what I receive and what I don't. I'd like to mark particular messages I see as interesting, so I'll receive any later message that lists it as a direct prerequisite. This would include additional information, errata, rebuttal, discussion/debate, and related topics that were sparked by the initial subject. Follow-up links are DAG (directed acyclic graph), the subject flow forks at each message, and occasionally somebody happens to write a summary message that joins together several different lines of thought that have something in common. But mostly follow-up links are tree-like, each message having one or zero prerequisite but an arbitrary number of follow-ups. Divergent branches in the tree may follow related subjects, or the topic may drift away from the original in several different directions. In a magazine or mailing list or conference it's nigh impossible to handle this divergence. Usually in a mailing list the readership must be burdened by all these divergent topics. Witness how HUMAN-NETS started with finding a public replacement for Arpanet but diverged into so many topics that at times it seems to be net.general in effect. But with follow-up links, any reader could select which branches to continue and which to prune, without adversely affecting anybody else who may have different choices. If the readership to any particular branch becomes very tiny, those who contribute could be warned; or better, whenever a messages is distributed the initial readership number could be included in the header, so persons thinking of replying would know whether to invest lots of time in a carefully-worded reply to hundreds or thousands, or slip off a quick reply to a half dozen, or not even bother if the readership has slipped to two (the author and the replyer). Has anybody provided a followup-link system for use on Arpanet? 4-Jun-84 10:27:57-PDT,2145;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 4 Jun 84 10:26:49-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 4 Jun 84 12:45 EDT Received: From csnet-pdn-gw.ARPA by BRL-AOS via smtp; 4 Jun 84 12:44 EDT Received: From hp-labs.csnet by csnet-relay; 4 Jun 84 12:16 EDT Received: by HP-VENUS id AA15587; Mon, 4 Jun 84 09:09:34 pdt Message-Id: <8406041609.AA15587@HP-VENUS> Date: Mon 4 Jun 84 09:08:26-PDT From: Scott L. McGregor Subject: Re: redistribution lists --> conferences&magazines&links etc. To: REM%mit-mc.arpa@csnet-relay.arpa, Jacob_Palme_QZ%QZCOM.MAILNET%mit-multics.arpa@csnet-relay.arpa Cc: MSGGROUP%brl-aos.arpa@csnet-relay.arpa, MCGREGOR@csnet-relay.arpa In-Reply-To: Message from "Robert Elton Maas " of Sat 2 Jun 84 05:52:00-PDT Source-Info: From (or Sender) name not authenticated. The difference between a conference and a magazine is that in a conference, control is presumed to be democratic. Anyone (everyone) is welcome to speak. A magazine has a different power structure: There is the magazine staff of writers and editors who minister to the subscribers. This is a less equitable arrangement, but is good for delivering information from those who know to those who don't. A Conference is better for tasks like brain- storming which benefit from a more equal participation. As a veteran Conferencing Systems user and a new conferencing system developer, I am acutely aware of the problem of information and decision overload. The management of the number of branching and pruning decisions will require improved systems for handling these systems automatically. The drudgery of this task given the tools currently available in most conferencing systems today is one of the things that is keeping conferencing from taking the commercial data processing world by storm. It is hoped that some breakthroughs will be achieved in this area in the not too distant future, but it we probably won't see major changes in this community for a while. ------- 4-Jun-84 20:59:59-PDT,1878;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 4 Jun 84 20:58:29-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 4 Jun 84 23:09 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 4 Jun 84 21:55 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2632701045505718@MIT-MULTICS.ARPA>; 04 Jun 1984 21:50:45 edt Date: 04 Jun 84 17:58 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, GILT_open_meeting%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, msggroup@BRL-AOS.ARPA, GILT_open_meeting%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: CCITT MHS standard, future development Message-ID: <57725@QZCOM> I just received a paper from ISO/TC 97/SC18N306, which lists plans for future work in further development of the CCITT X.400 MHS standard. The paper mentions the following points for further development: - Message services - Telematic Terminal Access to Message Handling Systems - Directory Systems - Encoding for Stored Digitized Voice - Aspects of Service Performance, Administrativa and Operation Issues - Conversion - Document Architecture - Cancellation Time - Closed User Group - Delivered Message Storage - Delivery Cancellation - Distribution List - Envelope Encryption - Limited Delivery (only delivering messages from certain originators) - Limited Submission (only accepting messages for certain receivers) - On-line Subscription - Originator-specified Alternative Recipient - Recipient-requested Redirection - Route Selection - Security Classification - Deferred Delivery Cancellation - Delivery time targets 7-Jun-84 09:58:48-PDT,3397;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Thu 7 Jun 84 09:58:00-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 7 Jun 84 12:19 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 6 Jun 84 20:23 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2632868078608597@MIT-MULTICS.ARPA>; 06 Jun 1984 20:14:38 edt Date: 05 Jun 84 18:29 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Messages_to_be_transferred_to_the_Swedish_%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, "Robert Elton Maas" , "Scott L. McGregor" cc: msggroup@BRL-AOS.ARPA, MCGREGOR@Csnet-Relay.ARPA, Messages_to_be_transferred_to_the_Swedish_%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Re: redistribution lists --> conferences&magazines&links etc. Message-ID: <57941@QZCOM> In-Reply-To: <8406041609.AA15587@HP-VENUS> In COM we have both ordinary conferences, where all participants can write whatever they want, and write-protected conferences, somewhat similar to what you call magazines. We also have different kinds of "selection conferences" into which selected entries from the normal conferences can be entered. Finally we store the "comment" links between entries into the data base, creating "sub-conferences" consisting of the items which are related directly or indirectly by comment links. There are a number of operations on such sub-conferences, such as scanning or searching in a sub- conference or skipping entries from a sub-conference. Our experience is that the sub-conference facility, or "comment tree" facility, or whathever you prefer to call it, is very much used and important for our users. Thus, we plan to put even more stress on this facility in future developments. Our experience is that the various kinds of write-protected conferences and selection conferences do provide some valuable services to some people, but in general have a problem in that too few entries are sent to them. This may be an economic problem, we have no tools at present for paying editors for such conferences, and this may be neccessary. Note that the concept of "keyword" and the concept of "conference" or "mailing list" is really very similar. Especially so in COM, where the same entry can be sent to several conferences, without forcing members of both conferences to see the entry twice. The idea of sending a note about graphics in Pascal to both the "Pascal" and the "graphics" conference/mailing list, is very similar to the idea of giving the note these two keywords. A difficulty with keywords may be that if you select items by keywords, you will get a somewhat random selection of items when you read them, depending on if someone happened to give the items the keyword you search on. With conferences and mailing lists, on the other hand, you will get a number of interrelated entries, and this is important because often the important information is not in one single item, but in the ideas created by the interrelation of items written by a number of people. 7-Jun-84 12:24:19-PDT,2537;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Thu 7 Jun 84 12:20:39-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 7 Jun 84 12:19 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 6 Jun 84 20:30 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2632868505626540@MIT-MULTICS.ARPA>; 06 Jun 1984 20:21:45 edt Date: 05 Jun 84 17:43 +0200 From: Gisle_Hannemyr_%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Gisle_Hannemyr_%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, "Robert Elton Maas" cc: msggroup@BRL-AOS.ARPA Subject: redistribution lists --> conferences&magazines&links etc. Message-ID: <57934@QZCOM> In-Reply-To: <57793@QZCOM> If I interprete your note correctly, it main theme is a suggestion for a more "structured" way of using computer conferencing. While I am symphatic to mechanisms that can augment the quality and reduce the "noise level" in C.C., I think I should report my experience with a magazine model very close to the one you are proposing. For more than a year, two friends and myself has attempted to operate an "Electronic Magazine" along those lines as part of the Oslo COM system. This system is used daily by researchers at three of Norways largest academic institutions, and we hoped that this very special group of users should form a good user base (academics usually write a lot of reports of papers). However, so far we have not received one unsolicited contribution, and even friends and collegues we have approached has not been very forthcoming. Other experimenters with this form have reported equally spectacular failures. The explanations offered for lack of success concentrates on: 1) Electronic media lack the prestige of established scientific journals. 2) A C.C. system shared by friends and neighbours is a to intimate medium to be used to publish ambitious and aspiring research papers. We shall continue our experiment another year (also failure provides some insight), but it seems that the casual, fairly unstructured way traditional C.C. operates, is so far the best format for this form communication. I have no comment on the other topics raised in your entry -- but more powerful link and search mechanisms seems like a good idea. 7-Jun-84 12:56:16-PDT,1162;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Thu 7 Jun 84 12:55:41-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 7 Jun 84 12:20 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 6 Jun 84 20:30 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2632868551486693@MIT-MULTICS.ARPA>; 06 Jun 1984 20:22:31 edt Date: 05 Jun 84 18:01 +0200 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: redistribution lists --> conferences&magazines&links etc. Message-ID: <57937@QZCOM> In-Reply-To: <57934@QZCOM> 1) Prestige I have also given that item some thoughts. Is it not somewhat astonishing that bodies like ACM or IFIP have not begun moving over to electronic publishing? Will commersial papers like Datamation be the first? I say no, that would not look so good for the academic community. 7-Jun-84 13:26:12-PDT,1869;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Thu 7 Jun 84 13:26:06-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 7 Jun 84 12:20 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 6 Jun 84 20:31 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2632868586576775@MIT-MULTICS.ARPA>; 06 Jun 1984 20:23:06 edt Date: 05 Jun 84 18:18 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, msggroup@BRL-AOS.ARPA Subject: redistribution lists --> conferences&magazines&links etc. Message-ID: <57939@QZCOM> In-Reply-To: <57937@QZCOM> IFIP is experimenting with an electronic journal called "COMPUTER COMPACTS". The journal is produced in cooperation with North-Holland Publishers, and it mainly contains abstracts of new books and papers in the computer area (not only published by North Holland) and items about forthcoming conferences in the computer area etc. They do however want to extend the scope of the journal. The journal is at present available on-line on one computer site in Germany. There is no connection at present between the journal and any mail networks, but I have talked to the editors about them sending me tapes with the journal for entry into COM, but so far I have not received any tape. The journal is not only published electronically, there is also a paper journal with the same name, containing partly the same contents but also some additional material. The editor of the journal is Judy Marcure Computer Compacts North-Holland publishers P.O. Box 1991 1000 BZ Amsterdam The Netherlands 7-Jun-84 13:50:33-PDT,2206;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Thu 7 Jun 84 13:49:03-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 7 Jun 84 12:20 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 6 Jun 84 20:33 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2632869090924895@MIT-MULTICS.ARPA>; 06 Jun 1984 20:31:30 edt Date: 05 Jun 84 19:23 +0200 From: Gisle_Hannemyr_%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Gisle_Hannemyr_%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: redistribution lists --> conferences&magazines&links etc. Message-ID: <57946@QZCOM> In-Reply-To: <57939@QZCOM> Other examples include Senders' (defunct) "On-line Scientific Journal" (report in "The Information Scientist" 2:1; and the Bristish BLEND. (B. Shackel, The BLEND System. Programme for the study of some 'electronic journals'., "Ergonomics" 25:4. These experiments also attempt to add prestige to publication by issuing parallell paper editions. Shackels paper contains references to numerous other experiments. I believe that to experiment with a "true" electronic journal you must: 1) NOT publish a parallell paper edition. Then it be just another journal that also exist in machine readable form. 2) Having it exist within the framework of a large dynamic conference system, so that one can monitor the effect of those most interesting characteristics of using a computer: a) Very short time between acceptance and publication. b) "Instant" feedback, dialogue between author and reader. Jacob Palme mentions <57941> the problem of paying the editor of such an "Electronic magazine". I am very interested in the topic, and would be happy to accept the editorship of such an magazine in COM@QZ without being paid. However, I proably could not get my University to pay for the computer time such an activity would require at the QZ Oden host, so QZ would have to donate the cycles. 8-Jun-84 07:06:45-PDT,1013;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Fri 8 Jun 84 07:03:11-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 8 Jun 84 9:24 EDT Received: From usc-ecl.arpa.ARPA by BRL-AOS via smtp; 8 Jun 84 9:16 EDT Date: 7 Jun 1984 22:08-PDT Sender: ESTEFFERUD@Usc-Ecl.ARPA Subject: [alain chesnais: X400] From: ESTEFFERUD@Usc-Ecl.ARPA To: msggroup@Brl-Aos.ARPA Cc: REMI@Cmu-Cs-C.ARPA Message-ID: <[USC-ECL] 7-Jun-84 22:08:19.ESTEFFERUD> Can anyone point us at a good source for X.400 documents .... Thanks - Stef ... Begin Enclosed Message ... Date: Fri 1 Jun 84 22:18:44-EDT From: alain chesnais ReSent-From: MsgGroup Moderator - Stefferud To: msggroup-request@BRL.ARPA Subject: X400 hi, i'm looking for documentation on the X400 protocol as well as any info thought and comments on it... could you let me know where i might find this? thanx, alain chesnais ------- ..... End Enclosed Message ... 8-Jun-84 23:19:45-PDT,815;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Fri 8 Jun 84 23:15:10-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 9 Jun 84 1:44 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 9 Jun 84 1:40 EDT Date: Sat, 9 Jun 84 01:39 EDT From: Paul Schauble Subject: Electronic conference services To: Human-Nets@RUTGERS.ARPA, MsgGroup@BRL.ARPA Message-ID: <840609053914.867567@MIT-MULTICS.ARPA> I am looking for a commercial electronic conferencing service to coordinate a project I am working on. It must be accessible from the entire continental US and Taiwan, ROC. Does anyone have knowledge or experience with any such service? As usual, I will forward a summary for the net if I get any replies. Paul 14-Jun-84 20:19:31-PDT,1363;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Thu 14 Jun 84 20:17:37-PDT Date: 14 Jun 1984 19:18:47 PDT From: POSTEL@USC-ISIF Subject: RFC 901 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 901: Title: Official ARPA-Internet Protocols Author: J. Reynolds Pages: 28 pathname: RFC901.TXT This RFC identifies the documents specifying the official protocols used in the ARPA-Internet. Annotations identify any revisions or changes planned. This memo is an official status report on the protocols used in the DARPA research community. 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. 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. ------- 20-Jun-84 12:15:28-PDT,1001;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Wed 20 Jun 84 12:14:07-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 20 Jun 84 13:56 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 20 Jun 84 13:50 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2634054297905101@MIT-MULTICS.ARPA>; 20 Jun 1984 13:44:57 edt Date: 20 Jun 84 15:34 +0200 From: Ulf_Beyschlag__CERN%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Ulf_Beyschlag__CERN%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, ESTEFFERUD@USC-ECL.ARPA cc: REMI@CMU-CS-C.ARPA Subject: [alain chesnais: X400] Message-ID: <59917@QZCOM> In-Reply-To: <[USC-ECL] 7-Jun-84 22:08:19.ESTEFFERUD> What are you looking for? Introduction articles or the Draft Recommendations? 20-Jun-84 18:59:34-PDT,1369;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Wed 20 Jun 84 18:55:51-PDT Date: 20 Jun 1984 17:58:36 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 900 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 900: Title: Assigned Numbers Author: J. Reynolds Pages: 43 pathname: RFC900.TXT This RFC specifies parameter values use in the Internet family of protocols, such as network numbers, well known ports, protocol types, and version numbers. This memo is an official status report on the protocol parameters used in the Internet protocol system. 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. 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. ------- 6-Jul-84 10:41:04-PDT,1806;000000000001 Return-Path: <@ECLB:WESTINE@USC-ISIF> Received: from ECLB by ECLC with ECLnet; Fri 6 Jul 84 10:40:58-PDT Received: from USC-ISIF by USC-ECLB; Fri 6 Jul 84 10:32:42-PDT Date: 6 Jul 1984 08:46:46 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 907 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 907: Title: Host Access Protocol Specification Author: Steve Storch Pages: 75 pathname: RFC907.TXT This document specifies the Host Access Protocol (HAP). Although HAP was originally designed as the network-access level protocol for the DARPA/DCA sponsored Wideband Packet Satellite Network, it is intended that it evolve into a standard interface SATNET and TACNET (aka MATNET) as well as the Wideband Network. HAP is an experimental protocol, and will undergo further revision as new capabilities are added and/or different satellite networks are suported. Implementations of HAP should be performed in coordination with satellite network development and operations personnel. 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. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIF.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 14-Jul-84 02:57:50-PDT,7042;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Sat 14 Jul 84 02:53:33-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 9 Jul 84 7:17 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 8 Jul 84 19:44 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2635630746362520@MIT-MULTICS.ARPA>; 08 Jul 1984 19:39:06 edt Date: 08 Jul 84 18:32 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, External_mail_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA, Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA To: External_mail_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA, Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA bcc: msggroup@BRL-AOS.ARPA Subject: Academic/Research Network Collaboration workshop Message-ID: <61859@QZCOM> Notes from the: Workshop on Academic/Research Network Collaboration =================================================== This workshop was held in Lesigny, France, on July 3-4 1984. The purpose of the workshop was to discuss cooperation between Acacemic/Research Mail networks in Europe and North America. Present at the meeting were participants from most Western European countries, from Canada, and, from the U.S.A., representatives from CSNET, MAILNET and BITNET. The European scene ------------------ The European representatives talked about plans for Academic/Research mail networks in their countries. Mail networks are already in operation in the U.K. and the U.S. with some connections to places in Canada, and European countries. Many of the European countries presented plans for national mail networks. Germany will establish a network called DFN, Deutsche Forschungsnetz, Sweden a network called SUNET, Finland a network called FUNET, Norway a network called UNINETT, the U.K. already have JANET in operation etc. There seemed to be common agreement at the meeting to use the MHS (X.400) standards for interconnection. Most of the national networks plan to use MHS internally, DFN, SUNET and FUNET will probably use MHS, while UNINETT is planning to use GILT. DFN and SUNET want to enhance MHS with those facilities which GILT has, but not MHS, put on top of the MHS protocols. The European Esprit project is planning a network which will in the beginning be an extension of the UUCP network, but will later use international standards. Esprit is also using COM as a central conference system for information exchange. The British Alvey project is presently testing the alternatives of using their own mailbox system, or using the COM or BLEND systems. It was generally felt that the MHS protocols would be most suitable for the interconnection of academic/research mail networks in the different European countries. The EARN network ---------------- An important network may be the EARN network, which will use the BITNET protocols and be connected to BITNET in the U.S. BITNET protocols are mainly implemented on IBM mainframes, but some non- IBM equipment can also connect to BITNET. IBM has promised to subsidize EARN by paying for leased lines between the European hosts and one line to the U.S. for the first four years. EARN would of course be a very valuable contribution to the interconnection of Academic Computer centres in Europe. The future of EARN is however not very safe, since CEPT, the organization for European PTT-s, has stopped EARN and put requirements which EARN may not be able to meet. The Euoropean PTT-s want EARN to use X.25 protocols instead of the IBM protocols used in BITNET, they want EARN to use public networks instead of leased lines, they would allow EARN to use leased lines for a temporary period but only if volume-dependent tariffs are imposed, these tariffs may become so high that EARN becomes unreasonable to use. Software for the connection of EARN to JANET will be developed at the Rutherford laboratories in the U.K. Software for connection to DFN will be implemented in Karlsruhe in Germany, and software for interconnection to CSNET is available in the U.S. at Wisconsin university. National Science Network ------------------------ In the U.S.A. there may be a new network called National Science Network. The basis of this network is that there are non-confirmed plans to establish 10 supercomputer centers to be available for U.S. researchers. A network is then needed to connect all those universities which do not have such centers themselves to the centers. The National Science Network, if established, will try to use existing networks like MAILNET, CSNET, BITNET, ARPANET, at least in the beginning. The network may be an important opening to get computer mail available for use by other people at universities than computer people. People involved in this project are Farber, Fuchs, Kahn, Kuo, Landweber, John Connely, Larry Lee, Rick Adrian. Canada ------ Canada has already implemented software for the MHS protocols on VAX/UNIX, VAX/VMS and IBM computers. Groups formed ------------- The meeting decided to form three working groups for studying specific issues. These three groups will be: For each group, there will be available a mailing list in the U.S. and a COM conference at QZ in Stockholm for those in Europe who cannot be reached directly via mail networks. Serious experts in these areas who are not a member of the groups will probably be able to participate if they contact the moderator of the group they want to join, even if they are not on the list of group participants below. MHS subsetting group -------------------- This group is to define a subset of the MHS standard (by selection of which optional services to provide and not provide) to use for the first international interconnections of mail systems based on the MHS standards. Members of the group are: John Demco, Canada (moderator) Dave Farber, Horn, Ansart, Steve Kille, Carcia, Palme and someone from Duesseldorf University Gateway services and specifications ----------------------------------- This group will study which services are to be provided by gateways between national academic networks, not only for mail but maybe also for other applications like file transfer. Members of the group are: Jennings (moderator), Landweberg, Bringsrud, Kirstein, Fuchs, Hutton, Demco, Fluckiger, Horn. Charging policies ----------------- This group will study policies for charging for the costs of mail networks. Members are: Kirstein, Fuchs, Palme, Landweber, Oberst, Rotert, Craigie, Pegelg, Medina. Name server group ----------------- This group will study how name servers in the various countries can be connected together. Members of this group are Oberst, Peleg, O'brion, Bilting, Bryant and Postel. 14-Jul-84 02:57:52-PDT,1882;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Sat 14 Jul 84 02:54:17-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 9 Jul 84 7:18 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 8 Jul 84 19:45 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2635630949305064@MIT-MULTICS.ARPA>; 08 Jul 1984 19:42:29 edt Date: 08 Jul 84 19:01 +0200 From: Ingemar_Falkehag%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Ingemar_Falkehag%QZCOM.MAILNET@MIT-MULTICS.ARPA, External_mail_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA, Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA To: External_mail_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA, Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: msggroup@BRL-AOS.ARPA Subject: Academic/Research Network Collaboration workshop Message-ID: <61862@QZCOM> In-Reply-To: <61859@QZCOM> Were any of the southern European countries represented (e.g. Greece, Italy, Spain and Portugal)? At a meeting two month ago in Greece organized by the Greek Systems Society the need for such networks was expressed in relation to the above countries. They are waiting for the EC mailsystem to be developed (European Community, that is). I am just on my way back to Greece and will relate your very interesting report. I will also relate it to the Computer Networking Committee of the Society for General Systems Research of which I am a member. Do you know of any mail or computer conferencing system in Spanish? Interciencia ought to be very interested in the developments. Two networks for biotechnology scientists are being initiated in Latin America and a workshop in Spain on systems thinking and development will give emphasis on communication. 14-Jul-84 02:57:54-PDT,1655;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Sat 14 Jul 84 02:54:50-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 9 Jul 84 7:18 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 8 Jul 84 19:45 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2635631000606695@MIT-MULTICS.ARPA>; 08 Jul 1984 19:43:20 edt Date: 08 Jul 84 20:42 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, External_mail_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA, Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA To: External_mail_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA, Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: msggroup@BRL-AOS.ARPA Subject: Academic/Research Network Collaboration workshop Message-ID: <61870@QZCOM> In-Reply-To: <61862@QZCOM> Yes, Manuel Medina fr}m E.T.S.E. Telecommuncio in Barcelona and Andrinano Endrizzi from the European Commission Joint Research Center in Ispra, Italy, were present. Both of them represent very advanced knowledge and research in the computer networks area. The telecommunications university in Barcelona are developing advanced networking systems based on multiprocessor Z80-based system, thus producing good systems using low cost equipment. Spain is planning to install conferencing systems at several universities, maybe PortaCOM on VAX-11/VMS computers. They will certainly want to interconnect this to the international networks. 14-Jul-84 02:59:52-PDT,1423;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Sat 14 Jul 84 02:59:20-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 12 Jul 84 7:00 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 11 Jul 84 19:57 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2635890990043765@MIT-MULTICS.ARPA>; 11 Jul 1984 19:56:30 edt Date: 11 Jul 84 14:06 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, External_mail_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA, Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA To: External_mail_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA, Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA bcc: msggroup@BRL-AOS.ARPA Subject: Academic/Research Network Collaboration workshop Message-ID: <62201@QZCOM> In-Reply-To: <61859@QZCOM> Some people have asked me for the mail addresses of the moderators at the working groups formed at the meeting in Paris. The moderator of the MHS subsetting group has the mail address: demco.ucb @ CSNET-RELAY The moderator of the Gateway services group has the mail address: Dennis_Jennings%QZCOM.MAILNET@MIT-MULTICS I do not know who are to be moderators of the other groups. I am trying to find out. 16-Jul-84 12:10:32-PDT,1102;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 16 Jul 84 12:08:38-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 16 Jul 84 14:09 EDT Received: From ucl-cs.arpa.ARPA by BRL-AOS via smtp; 16 Jul 84 13:59 EDT Date: Mon, 16 Jul 84 18:41:41 BST From: Damerell@ucl-cs.arpa To: info-vax@sri-csl.arpa, msggroup@brl-aos.arpa Subject: X25 mail & ftp I have written a document describing defects of X25 file transfer & mail, as installed on the VAX-VMS machine where I work. This message is too long to be inflicted on the whole of the mailing list, (there are lots of defects!) so I am merely sending this summary & offering to send the full message to anyone who asks for it. SUMMARY: non-uniform names, bad user interface, poor on-line Help, mail sometimes lost, cannot transfer multiple files, cannot answer network mail. Then I describe some facilities that a respectable mail system ought to provide. The full message is about 200--300 lines. If anyone asks for it, I propose to send it early in August. 19-Jul-84 20:38:48-PDT,2087;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Thu 19 Jul 84 20:35:47-PDT Date: 19 Jul 1984 13:12:40 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFCs 908 and 909 Now Available To: Request-for-Comments-List: New Requests for Comments are now available from the Network Information Center in the directory at SRI-NIC.ARPA. RFC 908: Title: Reliable Data Protocol Author: D. Velten, R. Hinden, and J. Sax Pages : 63 pathname: RFC908.TXT The Reliable Data Protocol (RDP) is designed to provide a reliable data transport service for packet-based applications. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts. Distribution of this memo is unlimited. RFC 909: Title: Loader Debugger Protocol Author: C. Welles and W. Milliken Pages : 136 pathname: RFC908.TXT The Loader Debugger Protocol (LDP) is an application layer protocol for loading, dumping, and debugging target machines from hosts in a network environment. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts. 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. ------- 24-Jul-84 19:25:34-PDT,1236;000000000001 Return-Path: Received: from BRL-MIS by USC-ECLC; Tue 24 Jul 84 19:21:17-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 24 Jul 84 21:55 EDT Received: From mit-multics.arpa.ARPA by BRL-AOS via smtp; 24 Jul 84 21:49 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2637018315536839@MIT-MULTICS.ARPA>; 24 Jul 1984 21:05:15 edt Date: 13 Jul 84 10:31 +0200 From: Ulf_Bilting%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Ulf_Bilting%QZCOM.MAILNET@MIT-MULTICS.ARPA, External_mail_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA, Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: External_mail_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA, Computer_conferencing_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA bcc: msggroup@BRL-AOS.ARPA Subject: Academic/Research Network Collaboration workshop Message-ID: <62475@QZCOM> In-Reply-To: <62201@QZCOM> Correction: John Demco's address is demco.ubc @ CSNET-RELAY (not ucb). 25-Jul-84 19:56:59-PDT,1828;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Wed 25 Jul 84 19:54:39-PDT Date: 25 Jul 1984 18:09:42 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 902 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 902: Title: ARPA-Internet Protocol Policy Author: J. Postel and J. Reynolds Mailbox: Postel@USC-ISIF.ARPA Pages: 5 pathname: RFC902.TXT The purpose of this memo is to explain how protocol standards are adopted for the ARPA-Internet and the DARPA research community. There are three important aspects to be discussed: the process, the authority, and the complex relationship between the DARPA community and the DDN community. This memo is a policy statement on how protocols become official standards for the ARPA-Internet and the DARPA research community. This is an official policy statement of the ICCB and the DARPA. 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. ------- 17-Aug-84 19:20:54-PDT,1754;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Fri 17 Aug 84 19:19:06-PDT Date: 17 Aug 1984 17:24:22 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 910 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 910: Title: Multimedia Mail Meeting Notes Author: H. Forsdick Mailbox: Forsdick@BBNF.ARPA Pages: 11 pathname: RFC910.TXT This memo is a report on a meeting about the experimental multimedia mail system (and in a sense a status report on that experiment). The meeting was held at Bolt Beranek and Newman on 23-24 July 1984 to discuss recent progress by groups who are building multimedia mail systems and to discuss a variety of issues related to the further development of multimedia systems. Representatives were present from BBN, ISI, SRI and Linkabit. 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. ------- 24-Aug-84 09:32:18-PDT,1086;000000000001 Return-Path: Received: from UCL-CS by USC-ECLC; Fri 24 Aug 84 09:31:22-PDT Date: Fri, 24 Aug 84 16:23:42 BST From: Damerell@ucl-cs.arpa To: msggroup@usc-eclc.arpa, info-vax@sri-kl.arpa cc: jennings%uwist@ucl-cs.arpa Subject: x25 ftp & mail AbAbout a month ago, I sent out a message suggesting that I had found defects in this software. I am now writing to apologise for the statements that I made . I acknowledge that I wrote in ignorance of the true facts; that namy of the things I said were severely inaccurate; and that I had no conception of the difficulties that the authors have overcome in writing this software. I wish to make an unreserved withdrawal and aploogy for the false and misleading statements that I have made. Although I wrote in good faith, I regret that I have given a completely false idea of this software. As for the longer paper that I was proposing to send out, I have suppressed it. I wish to apologise to everybody concerned, especially to the authors of the software. R.M.Damerell 7-Sep-84 19:55:31-PDT,1605;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Fri 7 Sep 84 19:50:57-PDT Date: 7 Sep 1984 18:39:54 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 911 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 911: Title: EGP Gateway under Berkeley Unix 4.2 Author: P. Kirton Mailbox: JKReynolds@USC-ISIF.ARPA Pages: 24 Characters: 57043 pathname: RFC911.TXT This memo describes an implementation of the Exterior Gateway Protocol (EGP) (in that sense it is a status report). The memo also discusses some possible extentions and some design issues (in that sense it is an invitation for further discussion). 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. ------- 27-Sep-84 22:39:58-PDT,1555;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Thu 27 Sep 84 22:37:24-PDT Date: 27 Sep 1984 21:16:52 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 912 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 912: Title: Authentication Service Author: M. StJohns Mailbox: StJohns@MIT-MULTICS.ARPA Pages: 3 Characters: 4715 pathname: RFC912.TXT This memo describes a proposed authentication protocol for verifying the identity of a user of a TCP connection. Discussion of this proposal is encouraged, and suggestions for improvements may be sent to the author. 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. ------- 29-Sep-84 22:58:11-PDT,1774;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Sat 29 Sep 84 22:57:16-PDT Date: 29 Sep 1984 22:00:22 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 913 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 913: Title: Simple File Transfer Protocol Author: M. Lottor Mailbox: MKL@MIT-XX.ARPA Pages: 15 Characters: 21784 pathname: RFC913.TXT This memo describes a proposed Simple File Transfer Protocol (SFTP). It fills the need of people wanting a protocol that is more useful than TFTP but easier to implement (and less powerful) than FTP. SFTP supports user access control, file transfers, directory listing, directory changing, file renaming and deleting. Discussion of this proposal is encouraged, and suggestions for improvements may be sent to the author. 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-Sep-84 03:15:02-PDT,1797;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Sun 30 Sep 84 03:14:11-PDT Date: 30 Sep 1984 01:03:56 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 914 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 914: Title: A Thinwire Protocol Author: D. Farber, G. Delp, and T. Conte Mailbox: Delp@UDEL-EE.ARPA Pages: 22 Characters: 58586 pathname: RFC914.TXT This RFC focuses discussion on the particular problems in the ARPA-Internet of low speed network interconnection with personal computers, and possible methods of solution. None of the proposed solutions in this document are intended as standards for the ARPA-Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to the problems, leading eventually to the adoption of standards. 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. ------- 10-Oct-84 14:30:22-PDT,1955;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Wed 10 Oct 84 14:28:08-PDT Date: 10 Oct 1984 11:10:32 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 916 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 916: Title: Reliable Asynchronous Transfer Protocol (RATP) Author: Greg Finn Mailbox: Finn@ISIF Pages: 53 Characters: 113815 pathname: RFC916.TXT Status of This Memo .Grab=10; This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This paper proposes and specifies a protocol which allows two programs to reliably communicate over a communication link. It ensures that the data entering one end of the link if received arrives at the other end intact and unaltered. The protocol, named RATP, is designed to operate over a full duplex point-to-point connection. It contains some features which tailor it to the RS-232 links now in common use. 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. ------- 15-Oct-84 16:40:16-PDT,1528;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Mon 15 Oct 84 16:38:44-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 15 Oct 84 19:03 EDT Received: from cmu-cs-a.arpa by BRL-AOS.ARPA id a008551; 15 Oct 84 12:55 EDT Date: 15 Oct 84 1247 EDT (Monday) From: don.provan@CMU-CS-A.ARPA To: msggroup@BRL.ARPA Subject: quoted names Message-Id: <15Oct84.124754.DP0N@CMU-CS-A.ARPA> I've seen this problem a couple of times, including once last night, so perhaps it's time to talk about it. Apparently, someone (at SIMTEL20) told their mailer to send mail to '"Webb Mike"@lll-mfe' with the single quotes being mine. the mailer, spotting the double quotes, said "ah ha! those are not legal, so I must quote them." my mailer dutifully removed the quotes of the quotes, looked at the string '"Webb Mike"' and said "I see no one here by that name," since none of our names have double quotes. I guess I just want to start some discussion on what went wrong here and what we can do about it. I don't see any reason for me not to run the destination mail box through the dequoter until it finds no more quotes, but since I don't control all the names our mail receiver handles, that means I'm restricting the names other sites here can use. On the other end, I can tell our users to give out names like Webb Mike without quotes, but i assume this will not be understood by most mailers (although there are still a lot of mailers that can't handle the quotes, either.) 15-Oct-84 21:13:22-PDT,1539;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Mon 15 Oct 84 21:11:38-PDT Date: 15 Oct 1984 18:35:04 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 918 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 918: Title: Post Office Protocol (POP) Author: Joyce K. Reynolds Mailbox: JKReynolds@USC-ISIF.ARPA Pages: 5 Characters: 10166 pathname: RFC918.TXT This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. 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. ------- 16-Oct-84 09:07:07-PDT,1554;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Tue 16 Oct 84 09:04:19-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 16 Oct 84 11:35 EDT Received: from su-score.arpa by BRL-AOS.ARPA id a001153; 16 Oct 84 7:25 EDT Date: Tue 16 Oct 84 04:22:36-PDT From: Mark Crispin Subject: Re: quoted names To: don.provan@CMU-CS-A.ARPA cc: msggroup@BRL.ARPA In-Reply-To: Message from "don.provan@CMU-CS-A.ARPA" of Mon 15 Oct 84 12:47:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Yes, the TOPS-20 SMTP sender/mailer (a.k.a. MMailr) will recognize that an address has "special" characters and will quote the address if so. It uses double-quote quoting when possible; if not, it uses backslash quoting (for the really hairy cases). What could have happened is that the process which queued the mail to MMailr (which I bet wasn't MM) misunderstood the quote application rules and applied SMTP quoting to the address in the envelope. Since MMailr performs this service, it was done twice. Perhaps you'll be able to tell from the message header what mail composition program wrote the message and its maintainers can be notified. On a related topic, it's been two years now and people are still using " at " in addresses (ala RFC 733). Noted culprits in the PDP-10 world are DECmail/MS and old versions of Hermes and Babyl. Something ought to be done to stamp this old software out! ------- 16-Oct-84 23:11:57-PDT,1935;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Tue 16 Oct 84 23:10:35-PDT Date: 16 Oct 1984 21:41:02 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 917 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 917: Title: Internet Subnets Author: Jeffrey Mogul Mailbox: Mogul@SU-SCORE.ARPA Pages: 21 Characters: 48326 pathname: RFC917.TXT This memo discusses subnets and proposes procedures for the use of subnets, including approaches to solving the problems that arise, particularly that of routing. A subnet of an Internet network is a logically visible sub-section of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. 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. ------- 17-Oct-84 02:34:38-PDT,1025;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Wed 17 Oct 84 02:33:49-PDT Received: from su-score.arpa by BRL-AOS.ARPA id a009933; 17 Oct 84 5:15 EDT Date: Wed 17 Oct 84 02:10:55-PDT From: Mark Crispin Subject: Re: quoted names To: WANCHO@SIMTEL20.ARPA cc: don.provan@CMU-CS-A.ARPA, msggroup@BRL.ARPA In-Reply-To: Message from ""Frank J. Wancho" " of Wed 17 Oct 84 00:14:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Frank - The problem with MM supporting " at " is not a bug, but rather removed code. I flushed the support for " at " from MM since it has been two years since RFC 733 style at's have been valid. It simplified the code and took away a few cases where the parser got confused. I guess I'll have to put it back, as enough people still haven't gotten the word that RFC 822 is *not* like RFC 733. -- Mark -- ------- 17-Oct-84 07:16:25-PDT,522;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Wed 17 Oct 84 07:15:04-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 17 Oct 84 9:46 EDT Received: from brl-tgr.arpa by BRL-AOS.ARPA id a008770; 16 Oct 84 17:51 EDT Date: Tue, 16 Oct 84 17:48:50 EDT From: Mike Muuss To: msggroup@BRL-AOS.ARPA Subject: List Move The MSGGROUP list is now being transmitted by BRL-AOS. You should still address submissions to -Mike Muuss 17-Oct-84 07:34:01-PDT,873;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Wed 17 Oct 84 07:32:29-PDT Received: from isi-uci-gw by BRL-AOS.ARPA id a012174; 17 Oct 84 10:12 EDT Date: 17 Oct 84 07:10:20 PDT (Wed) Message-ID: <267.466870220@uci-750a> To: Mark Crispin cc: WANCHO@simtel20.ARPA, don.provan@cmu-cs-a.ARPA, msggroup@brl.ARPA Subject: Re: quoted names In-reply-to: Your message of Wed 17 Oct 84 02:10:55-PDT. From: Marshall Rose Received: from Localhost by UCI-750a; 17 Oct 84 07:11:12 PDT (Wed) Sadly, addresses aren't the only thing which a lot of mailers/agents are botching. A surprisingly large number of date fields that get generated aren't 822. Of course, you never notice these things until you try using a routine that actually tries to *parse* the date string. Oh well, /mtr 17-Oct-84 07:42:04-PDT,1392;000000000000 Return-Path: Received: from BRL-MIS by USC-ECLC; Wed 17 Oct 84 07:40:47-PDT Received: From brl-aos.arpa.ARPA by BRL-MIS via smtp; 17 Oct 84 9:47 EDT Received: from simtel20.arpa by BRL-AOS.ARPA id a009666; 17 Oct 84 2:15 EDT Date: 17 Oct 1984 00:14 MDT (Wed) Message-ID: From: "Frank J. Wancho" To: Mark Crispin Cc: don.provan@cmu-cs-a.ARPA, msggroup@brl.ARPA Subject: quoted names In-reply-to: Msg of 16 Oct 1984 05:22-MDT from Mark Crispin Mark and Don, I'm the guilty party who sent the message in question, and I used the latest version of BABYL to do it. I also deliberately put the double quotes around the name "Webb Mike" as I knew BABYL doesn't handle the unquoted case properly, and MM doesn't handle it (No such local user as "Webb"), unless the double-quotes *are* used. However, Mark's analysis of the mis-quoting done by BABYL in the envelope appears correct. I will pass this exchange on to the maintainers. On the related topic, the current BABYL properly handles the " at " cases, and has for quite some time. I have yet to be able to induce HERMES to cause that form of address to slip out, yet I know one of users on another machine was able to generate that in a header... Still checking. --Frank 17-Oct-84 11:02:18-PDT,1362;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Wed 17 Oct 84 11:01:43-PDT Received: from su-score.arpa by BRL-AOS.ARPA id a013883; 17 Oct 84 13:33 EDT Date: Wed 17 Oct 84 10:26:50-PDT From: Mark Crispin Subject: Re: quoted names To: mrose@UCI-750A.ARPA cc: WANCHO@SIMTEL20.ARPA, don.provan@CMU-CS-A.ARPA, msggroup@BRL.ARPA In-Reply-To: Message from "Marshall Rose " of Wed 17 Oct 84 07:10:20-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I confess that MM and friends are guilty of botching the syntax of the date. That's because, with all the zillions of date/time syntaxes the TOPS-20 IDTIM% system call can parse and ODTIM% can generate, RFC 822 takes great pains to pick one that isn't among those zillions. Actually, I don't think it was really done deliberately, but one wonders. So, the code picks a nearest approximation, and DEC has been asked to define a new bit meaning "RFC 822 format". Where we blow it is that we don't have a comma after the day-of-week and have a hyphen before the timezone. I swear, though, if after we finally get into full compliance with RFC 822 dates they change the syntax to something incompatible AGAIN, I'll get the %&#@! ------- 17-Oct-84 12:31:41-PDT,1051;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Wed 17 Oct 84 12:30:33-PDT Received: from udel-gw by BRL-AOS.ARPA id a015204; 17 Oct 84 15:11 EDT Received: From udel-dewey.ARPA by udel-relay.ARPA id a019257 ;17 Oct 84 15:13 EDT Received: From localhost.DELAWARE by udel-dewey.DELAWARE id a009448 ;17 Oct 84 15:09 EDT Date: 17 Oct 84 15:09:20 EDT (Wed) Message-ID: <4057.466888160@udel-dewey> To: Mark Crispin cc: WANCHO@SIMTEL20.ARPA, don.provan@CMU-CS-A.ARPA, msggroup@BRL.ARPA Subject: Re: quoted names In-reply-to: Your message of Wed 17 Oct 84 10:26:50-PDT. From: Marshall Rose Actually, I wasn't knocking TOPS-20 systems (MM, et. al., in particular), but a few of the really obscure sites that are using something that is completely unlike the 822 syntax. The date parser I use doesn't have any problem with ODTIM%-generated strings, but can't pull a rabbit out of a hat... /mtr 17-Oct-84 15:36:06-PDT,3400;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Wed 17 Oct 84 15:30:57-PDT Received: from mit-multics.arpa by BRL-AOS.ARPA id a016565; 17 Oct 84 17:46 EDT Date: Wed, 17 Oct 84 17:41 EDT From: Barry Margolin Subject: RFC918: Post Office Protocol To: msggroup@BRL.ARPA Message-ID: <841017214116.403652@MIT-MULTICS.ARPA> RFC918 seems quite incomplete as it is currently written, or is at least making a number of assumptions that are not specified. 1) What is the format for messages being transmitted from the server to the workstation? The Introduction mentions RFC822, but the context seems to be referring to the way messages are transfered from the workstation to the server. Are we to assume then that messages are transfered from the server to the workstation in RFC822 format, too? 2) How are individual messages delimited? 3) When responding to RETR and RDEL commands, is the "#" meant to be taken literally, i.e. if there are 5000 characters in the mailbox, would it respond "500" or "#500"? 4) This protocol seems to be line-oriented; what is the newline character? Are you assuming NVT-ASCII? 5) Computing the mailbox character count could be difficult if the contents are to be transmitted in NVT-ASCII as opposed to the server's native character set. I am assuming that the character count is the number of characters to be transmitted, so it should be a count of NVT-ASCII characters. This can differ markedly from the number of characters stored on the host. Also, even without this problem, by requiring the server to respond with the total number of characters at the beginning it must read and format the entire mailbox before sending anything, so that it can add up the character counts of each message. Instead, I suggest that you specify a sequence to be used to indicate that the messages have all been transmitted. You could leave the character count in as an option for use by those systems for which it is easy to provide. Thus, an acceptable response to RDEL or RCEV would be either "#xxx", "+OK" (meaning that an indeterminate amount of text is coming), or "-ERR". Additionally, the "all done" indicator would only be recognized after an "end-of-message" delimiter; as long as the the all-done sequence could never be used to start a message (i.e. as long as it isn't of the form ": ") it wouldn't even have to be quoted if it were embedded in a message, like you would have to do for the end-of-message delimiter. 6) Does the character count include the inter-message delimiters? 7) There is an inconsistency in the RFC: in the Summary of Commands and Replies it specifies a reply as "-Error", but in the command descriptions they specify "-ERR". Which is it? 8) Is the "mailbox" parameter intended to be a pathname, a user name, or some system-dependent identifier? Now for a suggestion: 9) One does not always want to read all of one's mail. You might, for instance, just want the messages that came in since the last time you extracted your mail. Yes, you could use RDEL all the time, but people often like to leave messages in their mailboxes. 10) Similarly, if you don't use RDEL, then you need a way to selectively delete messages. barmar 17-Oct-84 19:11:51-PDT,1064;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Wed 17 Oct 84 19:10:53-PDT Received: from nyu-cmcl1.arpa by BRL-AOS.ARPA id a016978; 17 Oct 84 21:50 EDT Date: 17 Oct 84 21:39 EDT From: Stephen Tihor To: Margolin@MIT-MULTICS.ARPA Subject: RE: RFC918: Post Office Protocol Cc: msggroup@BRL.ARPA Message-ID: <29176F663.08560033.1984@CMCL1.NYU-CMCL1.ARPA> In-Reply-To: <841017214116.403652@MIT-MULTICS.ARPA> ; Message of 17-OCT-1984 18:06 from Barry Margolin Having an upper bound on the number of NVT-ASCII characters to be transmited is a very useful option for a small workstation which might not be able to handle swallowing and entire vacation's worth (heck a weekend's worth) of mail in one gulp. // ARPAnet: Tihor@NYU-CMCL1 UUCPnet address: ...!ihnp4!cmcl2!cmcl1!tihor \\ (( DEC Enet: RHEA::DECWRL::"""TIHOR@NYU-CMCL1.ARPA""" NYUnet: TIHOR.CMCL1 )) \\ Stephen Tihor / CIMS / NYU / 251 Mercer Street / New York, NY 10012 // ------- 18-Oct-84 13:48:13-PDT,1365;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Thu 18 Oct 84 13:47:17-PDT Received: from dcn5.arpa by BRL-AOS.ARPA id a024964; 18 Oct 84 16:25 EDT Date: 18-Oct-84 19:33:35-UT From: little@dcn5.ARPA Subject: Virtual Terminal Protocol To: header-people@MIT-MC.ARPA, msggroup@brl.ARPA, tcp-ip@SRI-NIC.ARPA I am attempting to create a virtual terminal protocol (VTP) with emphasis on solving problems created by forms mode type terminals (eg-3270). I currently view the problem with the following breakdown - Graphical (Character) Representation code for information exchange (agreement) Control Domain and Exercising modal operation transfer requests function keys out-of-band signals Display cursor addressing end-of-line/screen condition presentation attributes Does anyone have any interesting thoughts or know of problems they are having in this area?? (or are header/TCPIP/msg people the right people for this sort of thing?) Specifically - what problems do you have with TELNET?? Are there deficiencies you would like to overcome with TELNET or RFC 731? Also, does anyone have access to the new VTP spec put out recently by the Terminal Repertoire Committee of ANSI (chaired by Henry Lowe -DEC)? Mike Little - LINKABIT@DCN5 ------- 18-Oct-84 14:42:51-PDT,460;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Thu 18 Oct 84 14:40:53-PDT Received: from usc-ecl.arpa by BRL-AOS.ARPA id a025561; 18 Oct 84 17:15 EDT Date: Thu 18 Oct 84 14:11:52-PDT From: DBAKER@USC-ECL.ARPA Subject: list removal To: msggroup@BRL.ARPA I had requested removal rfrom the list and am now back on as of 0ct 11. Did you pick up an old list? Please remove me again> thanks dbaker@ecla ------- 18-Oct-84 17:41:38-PDT,789;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Thu 18 Oct 84 17:39:46-PDT Received: from brl-tgr.arpa by BRL-AOS.ARPA id a026948; 18 Oct 84 20:20 EDT Date: Thu, 18 Oct 84 20:10:05 EDT From: Ron Natalie To: little@DCN5.ARPA cc: header-people@MIT-MC.ARPA, msggroup@BRL.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: Virtual Terminal Protocol Actually, the WISCNET software that allows you to use TCP/IP to IBM-370 series machines running VM/CMS does this. They have an option negotiation that says "do 3270 style stuff" and from then on send 3270 control messages. I have been meaning to try to simulate the user end on UNIX with a termcap driven user telnet, but haven't gotten around to it. -Ron 18-Oct-84 23:25:14-PDT,1670;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Thu 18 Oct 84 23:24:54-PDT Date: 18 Oct 1984 20:48:46 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 920 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 920: Title: Domain Requirements Author: J. Postel & J. Reynolds Mailbox: Postel@USC-ISIF.ARPA Pages: 14 Characters: 28621 pathname: RFC920.TXT This memo states the requirements on establishing a Domain, and introduces the limited set of top level domains. This memo is a policy statement on the requirements of establishing a new domain in the ARPA-Internet and the DARPA research community. This is an official policy statement of the IAB and the DARPA. 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. ------- 18-Oct-84 23:25:14-PDT,136;000000000000 Date: 18 Oct 1984 23:48:46 PDT From: Msggroup-request@brl Subject: Index of [ECLC]msggroup.2301-2200 To: msggroup@brl 19-Oct-84 01:42:05-PDT,1000;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Fri 19 Oct 84 01:39:04-PDT Received: from usc-ecl.arpa by BRL-AOS.ARPA id a000639; 19 Oct 84 4:15 EDT Date: 19 Oct 1984 01:11-PDT Sender: ESTEFFERUD@usc-ecl.ARPA Subject: Re: Virtual Terminal Protocol From: ESTEFFERUD@usc-ecl.ARPA To: little@dcn5.ARPA Cc: header-people@mit-mc.ARPA, msggroup@brl.ARPA, tcp-ip@sri-nic.ARPA Message-ID: <[USC-ECL]19-Oct-84 01:11:57.ESTEFFERUD> In-Reply-To: The message of 18-Oct-84 19:33:35-UT from little@dcn5.ARPA Msggroup and header-people are both the wrong lists for this topic. Please, everyone (and especially those of you who we all know know better), refrain from dumbly copying these two lists on replies, just because the originator did not know better. I can understand innocent new netmail users making such an error, but I cannot understand why knowlegeable people blindly continue? Thanks for your forebearance, and your consideration. Stef 21-Oct-84 00:51:22-PDT,1652;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Sun 21 Oct 84 00:48:30-PDT Date: 20 Oct 1984 23:20:23 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 923 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 923: Title: Assigned Numbers Author: J. Reynolds & J. Postel Mailbox: JKReynolds@USC-ISIF.ARPA Pages: 47 Characters: 99193 pathname: RFC923.TXT This RFC documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers obsoletes RFC 900 and earlier editions. 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. ------- 22-Oct-84 23:29:59-PDT,1658;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Mon 22 Oct 84 23:28:09-PDT Date: 22 Oct 1984 22:01:25 PDT From: WESTINE@USC-ISIF.ARPA Subject: RFC 924 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 924: Title: Official ARPA-Internet Protocols Author: J. Reynolds & J. Postel Mailbox: JKReynolds@USC-ISIF.ARPA Pages: 35 Characters: 50543 pathname: RFC924.TXT This RFC identifies the documents specifying the official protocols used in the ARPA-Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC 901 and earlier editions. 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. ------- 23-Oct-84 17:28:12-PDT,1150;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Tue 23 Oct 84 17:25:53-PDT Received: from mit-multics.arpa by BRL-AOS.ARPA id a004057; 23 Oct 84 20:09 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2644876624223500@MIT-MULTICS.ARPA>; 23 Oct 1984 19:57:04 edt Date: 23 Oct 84 17:48 +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 Cc: msggroup@BRL-AOS.ARPA Subject: Re: quoted names Message-ID: <75558@QZCOM> In-Reply-To: <74674@QZCOM> FROM: Mark Crispin I swear, though, if after we finally get into full compliance with RFC 822 dates they change the syntax to something incompatible AGAIN, I'll get the %&#@! Surely they will. Do you not know that there is an international standard for calendar dates. Something like this, I believe: 1984-10-23-17.43.59 for todays date. 24-Oct-84 10:32:39-PDT,1095;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Wed 24 Oct 84 10:30:06-PDT Received: from usc-isi.arpa by BRL-AOS.ARPA id a004613; 24 Oct 84 13:07 EDT Date: 24 Oct 1984 13:05-EDT Sender: DESJARDINS@USC-ISI.ARPA Subject: Re: quoted names From: DESJARDINS@USC-ISI.ARPA To: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: msggroup@BRL-AOS.ARPA Message-ID: <[USC-ISI.ARPA]24-Oct-84 13:05:09.DESJARDINS> In-Reply-To: <75558@QZCOM> Jacob is right: the DOD policy is that if there is an international standard already in existence for something, and the standard meets the military requirements, then the standard would be used in preference to inventing something new. I would think that policy applies to calendar date/time strings (but I can't verify from my own knowledge that the syntax Jacob gave is correct). Barry Leiner or Bob Kahn could give a more definitive statement of the policy, but this is the essence of it. --Dick dJ 24-Oct-84 13:46:53-PDT,1379;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Wed 24 Oct 84 13:46:18-PDT Received: from isi-uci-gw by BRL-AOS.ARPA id a007459; 24 Oct 84 16:22 EDT Date: 24 Oct 84 13:18:10 PDT (Wed) To: msggroup@brl.ARPA cc: nic@sri-nic.ARPA Subject: Chain Letter Alert! From: Einar Stefferud Received: from Localhost by UCI-750a; 24 Oct 84 13:19:19 PDT (Wed) Please send one copy of the relevant ARPANET NEWS articles, or other DoD Policy Documents to MSGGROUP@BRL, to let us help people around the net understand what is at stake. My request is specifically to NIC to avoid getting more than one copy from helpful souls around the net. Thanks much! Stef ------- Forwarded Message Subject: chain letters From: Kevin Paetzold To: tops-20@su-score Date: Wed 24 Oct 84 13:40:14-EDT Once again the infamous network chain letters are circulating through the network. They are circulating through DECs engineering net to a very great extent. From the address lists it appears it is also circulating around the arpanet. It would probably be a good idea if we took steps to curtail this round of the chain letter before it gets any worse. I have allready taken steps to curtail it in DEC. You might want to do the same.... ------- End of Forwarded Message 26-Oct-84 07:30:35-PDT,3770;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Fri 26 Oct 84 07:29:29-PDT Received: from dcn9.arpa by BRL-AOS.ARPA id a002461; 26 Oct 84 9:58 EDT Date: Fri, 26 Oct 84 09:59:16 edt From: Phill Gross Message-Id: <8410261359.AA02821@dcn9.arpa> Received: by dcn9.arpa (4.24/3.14) id AA02821; Fri, 26 Oct 84 09:59:16 edt To: msggroup@brl.ARPA Subject: Estimate on number of Internet users I thought the message below might be of interest to arpanauts. It originated in the 'Human-Nets digest' (which I don't read) and was forwarded, with comments, to 'AIlist' by Ken Laws at SRI. (Law's added comments are in square brackets.) Any comments? ----------------------------------------------------------------------------- Date: Wed, 10 Oct 84 01:50:10 edt From: bedford!bandy@mit-eddie Subject: Net Readership [Forwarded from the Human-Nets digest by Laws@SRI-AI.] Date: Mon, 8 Oct 84 14:28 EDT From: TMPLee@MIT-MULTICS.ARPA Has anyone ever made an estimate (with error bounds) of how many people have electronic mailboxes reachable via the Internet? (e.g., ARPANET, MILNET, CHAOSNET, DEC ENET, Xerox, USENET, CSNET, BITNET, and any others gatewayed that I've probably overlooked?) (included in that of course group mailboxes, even though they are a poor way of doing business.) Gee, my big chance to make a bunch of order of magnitude calculations.... [...] USENET/DEC ENET: 10k machines, probably on the order of 40 regular users for the unix machines and 20 for the "other" machines so that's 100k users right there. [Rich Kulaweic (RSK@Purdue) notes 15k users on 40 Unix machines at Purdue, with turnover of several thousand per year. -- KIL] BITNET: something like 100 machines and they're university machines in general, which implies that they're HEAVILY overloaded, 100-200 regular active users for each machine - 10k users. [A news item in the latest CACM mentions 200 hosts at 60 sites, soon to be expanded to 200 sites worldwide. A BITNET information center is also being developed by a consortium of 500 U.S. universities, so I expect they'll all get nodes soon. -- KIL] Chaos: about 100-300 machines, 10 users per machine (yes, oz and ee are heavily overloaded at times, but then there's all those unused vaxen on the 9th floor of ne43). 1k users for chaosnet. I think that we can ignore csnet here (they're all either on usenet or directly on internet anyway...), so they count for zero. ARPA/MILNET: Hmm... This one is a little tougher (I'm going to include the 'real' internet as a whole here), but as I remember, there are about 1k hosts. Now, some of the machines here are heavily used (maryland is the first example that pops to mind) and some have moderate loads (daytime - lots of free hardware at 5am!), let's say about 40 regular users per machine -- another 10k users. I dare not give a guesstimate for Xerox. [Murray.PA@Xerox estimates 4000 on their Grapevine system. -- KIL] So it's something on the order of 100k users for the community. [...] Well, it could be 50k people, but these >are< order of magnitude calculations... [Mark Crispin (MRC@Score) notes that there are 10k addressable mailboxes at Stanford, but that the number of active users is perhaps only a tenth of this. Andy's final estimate might be inflated or deflated by such a factor. -- KIL] Now that I've stuck my neck out giving these estimates, I'm awaiting for it to be chopped off. andy beals bandy@{mit-mc,lll-crg} ----------------------------------------------------------------------------- 29-Oct-84 15:15:55-PST,2384;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Mon 29 Oct 84 15:14:16-PST Received: from mit-xx.arpa by BRL-AOS.ARPA id a018062; 29 Oct 84 18:00 EST Date: Mon 29 Oct 84 17:59:28-EST From: Greg Skinner Subject: Estimate on size of Internet users To: human-nets@MIT-MC.ARPA, msggroup@BRL.ARPA cc: info-nets%MIT-OZ@MIT-XX.ARPA I don't have the original article, but I wanted to comment on a couple of things. First off, you weren't too far off in your estimates, Bandy, but there's a couple of things you overlooked. First of all, the VAX farm (the machines on the ninth floor of tech square) are not on the Chaosnet. They are on a 10 megabit Ethernet connected via a gateway to the rest of the ARPAnet, so they are part of the Internet. In fact, these machines are on net 18. Check the map between room ne43-503 and ne43-504 (*sigh* -- my old office). Secondly, a number of the machines on the Chaosnet are either lisp machines or terminal concentrators. I have a list of a few known Chaosnet machines which have actual users on them somewhere so I can get the details, but probably there are 50 machines less than your estimate. If the Athena machines are on the Chaosnet (at the time I was still at MIT there were subnets allocated for them but I don't know if the actual machines were connected, let alone up) that will bump the number back up. Otherwise, add them on as hanging off MIT's network (pick any one you like, as all are addressable from each other one way or another). I just looked at the latest version of the NIC tables and they are listed as being on net 18. Did you include CMU's local net/campus net? That will bump the number up. It's possible though that they are on the Internet already though (net 128). I don't know if the message has gotten out here yet, but someone mentioned that IBM's internal VNET should be considered part of the Internet also. Who knows what things go on on the other side of the water? (I'm referring to whatever nets lie beyond london-gateway). Also, what goes on behind coins-gateway? This is really a question for info-nets, so they're getting it. If someone has the original they should send it there also. Have fun gang, --gregbo Gds@MIT-XX.ARPA {allegra,cbosgd,ihnp4}!houxm!gregbo (UUCP) ------- 29-Oct-84 23:24:23-PST,2372;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Mon 29 Oct 84 23:24:09-PST Date: 29 Oct 1984 22:22:54 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 925 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 925: Title: Multi-LAN Address Resolution Author: J. Postel Mailbox: Postel@USC-ISIF.ARPA Pages: 15 Characters: 31992 pathname: RFC925.TXT The problem of treating a set of local area networks (LANs) as one Internet network has generated some interest and concern. It is inappropriate to give each LAN within an site a distinct Internet network number. It is desirable to hide the details of the interconnections between the LANs within an site from people, gateways, and hosts outside the site. The question arises on how to best do this, and even how to do it at all. In RFC-917 Jeffery Mogul makes a case for the use of "explicit subnets" in a multi-LAN environment. The explicit subnet scheme is a call to recursively apply the mechanisms the Internet uses to manage networks to the problem of managing LANs within one network. In this note I urge another approach: the use of "transparent subnets" supported by a multi-LAN extension of the Address Resolution Protocol. 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. ------- 1-Nov-84 18:18:16-PST,1651;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Thu 1 Nov 84 18:13:29-PST Date: 1 Nov 1984 16:33:49 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 919 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 919: Title: Broadcasting Internet Datagrams Author: Jeffrey Mogul Mailbox: Mogul@SU-SCORE Pages: 8 Characters: 16838 pathname: RFC919.TXT We propose simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. 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. ------- 1-Nov-84 19:38:28-PST,1227;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Thu 1 Nov 84 19:38:03-PST Received: from mit-multics.arpa by BRL-AOS.ARPA id a007350; 30 Oct 84 18:52 EST Delivery-Date: 8 Oct 84 13:29 EST Date: Mon, 8 Oct 84 13:28 EST From: TMPLee@MIT-MULTICS.ARPA Subject: Size of the Internet To: Human-Nets@RUTGERS.ARPA bcc: TMPLee.DODCSC@MIT-MULTICS.ARPA Message-ID: <841008182849.536206@MIT-MULTICS.ARPA> Resent-Date: 30 Oct 84 18:41 EST Resent-From: TMPLee@MIT-MULTICS.ARPA Resent-To: msggroup@BRL.ARPA, info-nets%mit-oz@MIT-XX.ARPA, gds@MIT-XX.ARPA Resent-Comment: The recent reply from Gds suggested my original query should have gone out to these lists too. Thanks, and I hope the topic is still of interest. Resent-Message-ID: <841030234137.079459@MIT-MULTICS.ARPA> Has anyone ever made an estimate (with error bounds) of how many people have electronic mailboxes reachable via the Internet? (e.g., ARPANET, MILNET, CHAOSNET, DEC ENET, Xerox, USENET, CSNET, BITNET, and any others gatewayed that I've probably overlooked?) (included in that of course group mailboxes, even though they are a poor way of doing business.) Ted 10-Nov-84 15:44:49-PST,1604;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Sat 10 Nov 84 15:44:33-PST Received: from usc-ecl.arpa by BRL-AOS.ARPA id a013012; 10 Nov 84 18:22 EST Received: from ECLD by ECLA with ECLnet; Sat 10 Nov 84 15:19:36-PST Date: Sat 10 Nov 84 15:19:41-PST From: Bob Larson Subject: Ibm (bitnet) mail to Dec (Arpanet) Sender: BLARSON%ECLD%ECLD@usc-ecl.ARPA To: info-nets@MIT-MC.ARPA cc: msggroup@BRL.ARPA Reply-To: blarson@USC-ECL.ARPA Recently, my boss has received a mandate to establish a "campus wide" electronic mail system. One of the obstacles in this is a reasonable link between an Ibm 3081 running VM/CMS and MVS/SP (sp?) (and a couple of others) and our Dec network. The 3081 is on bitnet and 3 of our Tops 20's are on arpanet, so it is possible we could utilize a bitnet/arpanet gateway. (wiscvm) This raises a few questions about such a gateway: What turnaround can we expect? (minimum, average, and maximum) Would they be willing to handle our traffic? (At least until the project isn't my responsibility.) Is there a reasonable user interface on the IBM end (even if we have to pay for it) or will we have to write our own? Currently USC has 6 Tops20s, a couple of dozen vax/vms systems, 16 primes, a 3081 with split personalities, two 4341's (MVS??), a few vax/unix systems, and uncountable other mini's and micro's. Anyone want to tackle the job of getting them talking together? Thanks, Bob Larson Arpanet: Blarson@Usc-Ecl.Arpa Others: Use your favorite gateway to arpanet ------- 10-Nov-84 17:58:20-PST,3100;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Sat 10 Nov 84 17:56:28-PST Received: from usc-ecl.arpa by BRL-AOS.ARPA id a013241; 10 Nov 84 20:35 EST Date: 10 Nov 1984 17:33-PST Sender: ESTEFFERUD@usc-ecl.ARPA Subject: Re: Ibm (bitnet) mail to Dec (Arpanet) From: ESTEFFERUD@usc-ecl.ARPA To: blarson@usc-ecld Cc: info-nets@mit-mc.ARPA, msggroup@brl.ARPA Message-ID: <[USC-ECL]10-Nov-84 17:33:06.ESTEFFERUD> In-Reply-To: The message of Sat 10 Nov 84 15:19:41-PST from Bob Larson Hello -- It is my finding to this point that the MMDF system running on some kind of Unix (Preferably BSD 4.2) is the best central mail transfer server, since it is designed and implemented to handle most anything that can be accomodated by anything. Also, more different systems are interfaced to MMDF than any other such system. US Army Armaments Research and Development Command is transferring mail between a VAX Unix 4.2 MMDF at Dover, NJ, and a network of Primes at Rock Island, Ill. It is not totally automated yet, but ... CSnet offers PMDF (Pascal Memo Distribution Facility) which can link MMDF to VAX VMS. You are running PMDF on USC-CSE (BSD4.2) now. Perhaps also on others of your VAX VMS systems at USC. There is even a CSnet connected gateway to the new CCITT MHS X.400 International Protocols in Canada, insxtalled at UBC (Univ of British Columbia) which services a Canadian network of Univerities. I expect that most BITNET connections are between TOPS-20s and IBM systems, at places like Stanford and Columbia Universities. I would suggest that you size the problem and get yourself a 4.2 UNIX to minimize your porting problems, and install an MMDF Mail Relay, and obtain or build the required connections to all your other systems as MMDF channels which will do all the required munging and accomodating. This will keep all the munging and accomodations on one system, which would be dedicated to relaying mail. Of course, it will be expedient to relay through existing connection pairs, like the BITNET TOPS-20/IBM stuff, though we do know that there is a CSnet MMDF Phonenet connection to IBM-SJ (San Jose Research Labs), which might be available. BSD 4.2 systems are available in the full range you might need, from the Integrated Solutions 4.2 box ($18k - $31K), to the new Computer Consoles, Inc 6/32 which they claim is 7 times a VAX 780 for under $500K. My price quotes are NOT RELIABLE! Among some things that I know need to be done is to develop a combination of SMTP with MMDF Phonenet (Packet Level) so we can use the TOPS-20 SMTP/Phonenet connection software developed by MAILNET for MULTICS/TOPS-20 transfers. ECL now runs this software on its TOPS-20s to connect to MIT-MULTICS for MAILNET. UC Irvine (UCI) is looking at the same set of problems, as are a number of industrial clients. It seems to me that there should be some shareable solutions for these problems. Anyone know about other connections that we should consider? Best - Stef 10-Nov-84 19:01:20-PST,1588;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Sat 10 Nov 84 18:59:19-PST Received: from brl-tgr.arpa by BRL-AOS.ARPA id a013344; 10 Nov 84 21:48 EST Received: from rutgers-gw by BRL-TGR.ARPA id a002068; 10 Nov 84 21:41 EST Date: 10 Nov 84 21:40:52 EST From: Charles Hedrick Subject: mail to an IBM machine To: msggroup@BRL-TGR.ARPA We have a similar problem. We want to get all of our machines on campus to talk. Fortunately, except for our IBM-compatible system (an AS-9000, roughly a Hitachi version of a 3081), the rest can handle TCP on Ethernet. So the obvious solution is to put TCP up on the AS-9000. We believe that this is possible. It appears that IBM is now selling U. of Wisconsin's TCP/IP implementation for VM. Last time we checked, it used a Unibus Ethernet interface, hooked into the IBM machine using an IBM channel to Unibus adapter that somehow involved an IBM PC. We had some hints that this might be slightly slow. For MVS, the UCLA computer center has a TCP/IP implementation. As far as I know, it currently supports only a real Arpanet (i.e. 1822) interface. ACC is currently under contract to us to build an Ethernet interface for an IBM channel. It will look like their 1822 interface to the IBM system, so that it can use the UCLA software unchanged. We found one or two other vendors who were about to come up with suitable interfaces also. The original due date for the ACC interface was January, 1985. It seems to have slipped to February now. ------- 11-Nov-84 14:39:37-PST,887;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Sun 11 Nov 84 14:36:28-PST Received: from brl-tgr.arpa by BRL-AOS.ARPA id a014906; 11 Nov 84 17:23 EST Date: Sun, 11 Nov 84 17:15:43 EST From: Ron Natalie To: blarson@USC-ECL.ARPA cc: info-nets@MIT-MC.ARPA, msggroup@BRL.ARPA Subject: Re: Ibm (bitnet) mail to Dec (Arpanet) Yech. Going through Wisconsin to go across campus is disgusting. Why don't you try one of the following. 1. Buy the WISCnet code from IBM and hook up the IBM's and the other hosts on you DECnetwork with TCP/IP. 2. Get a Vax that is connected to your other networks and obtain the code from Penn State that will allow you to establish your own gateway between the IBM RSCS-based networking (what BITNET uses). I'd go with option number 1 if it were me. -Ron 12-Nov-84 12:06:40-PST,3720;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Mon 12 Nov 84 12:04:19-PST Received: from csnet-sh.arpa by BRL-AOS.ARPA id a016317; 12 Nov 84 14:39 EST Date: Mon, 12 Nov 84 14:35:26 EST To: Ron Natalie cc: blarson@USC-ECL.ARPA, info-nets@MIT-MC.ARPA, msggroup@BRL.ARPA, breeden@CSNET-SH.ARPA Subject: Re: Ibm (bitnet) mail to Dec (Arpanet) In-reply-to: Your message of Sun, 11 Nov 84 17:15:43 EST. From: Laura Breeden The WISCNET code is available to universities and colleges from the University of Wisconsin, Madison at a one-time charge of $500. A description of the software is appended to this message. If your organization is not an academic institution, the code is also available commercially from IBM (for $17K). For more information, contact your local IBM sales reps and refer to Availability Notice G320-9219. With a Series/1 front end, IBM VM hosts can use this package to connect to CSNET X25Net. Laura Breeden CSNET CIC ------------------------------------ The University of Wisconsin has implemented the DOD Internet protocols (FTP/SMTP/Telnet/TCP/IP) for IBM VM systems under con- tract to IBM. This software package, called WISCNET, is owned by IBM. IBM has licensed Wisconsin to distribute WISCNET to univer- sities and colleges. Source code [is] included with the dis- tribution... To receive WISCNET, a university or college must sign a license agreement with the University of Wisconsin and pay a one-time distribution fee of $500. Licenses may be obtained from and should be returned to: Lawrence H. Landweber Computer Science Department University of Wisconsin - Madison 1210 W. Dayton St. Madison, WI 53706 ARPANET, CSNET: landweber@wisc-rsch.ARPA UUCP: ...!{seismo,allegra,ihnp4}!uwvax!landweber Documents describing WISCNET will be sent with licenses. BRIEF OVERVIEW OF WISCNET WISCNET includes: (1) An implementation of the standard DOD protocols TCP and IP under VM/SP Release 2 or 3. (2) Implementations of the higher-level DOD protocols FTP, SMTP, and Telnet. (3) An interface between SENDFILE and SMTP. (4) Interfaces from IP to the Ethernet and Pronet local area networks (using a DACU as described below). (5) An interace from IP to the Telenet public data network (using a Series/1 as described below). TCP/IP runs in a separate disconnected virtual machine on the VM host. Similarly, each of SMTP, server FTP, and server Telnet occupies a dedicated virtual machine. User FTP and user Telnet run within a user's virtual machine under CMS. Virtual machines communicate with one another using the Virtual Machine Communication Facility (VMCF). The VM software is written almost entirely in Pascal, with a small amount of assembler-language support. Standard IBM-released software is used throughout (i.e., no modified or unreleased sys- tem software has been employed). Local area network interfaces are available for Pronet (Pro- teon Corp. - 10 Megabit/sec token ring) and Ethernet (Interlan - 10 Megabit/sec). The IBM host is connected to these local area networks via a Device Access Control Unit (DACU), which is a UNIBUS-to-channel adapter sold by IBM. There is also an inter- face to the Telenet public data network, using an X.25 implemen- tation running on a channel-attached Series/1 front end running the RPS operating system. The latter interface allows CSNET IBM VM hosts to connect to the DARPA Internet via Telenet. 12-Nov-84 15:37:07-PST,1195;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Mon 12 Nov 84 15:36:59-PST Received: from ucb-vax.arpa by BRL-AOS.ARPA id a016715; 12 Nov 84 18:15 EST Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA00422; Mon, 12 Nov 84 11:24:59 pst Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.17/4.27.4) id AA22597; Mon, 12 Nov 84 11:00:41 pst Received: by ucbopal.CC.Berkeley.ARPA (4.17/4.28) id AA06724; Mon, 12 Nov 84 11:00:32 pst Date: Mon, 12 Nov 84 11:00:32 pst From: Greg Minshall Message-Id: <8411121900.AA06724@ucbopal.CC.Berkeley.ARPA> To: blarson@USC-ECL.ARPA, ron@BRL-TGR.ARPA Subject: Re: Ibm (bitnet) mail to Dec (Arpanet) Cc: info-nets@MIT-MC.ARPA, msggroup@BRL.ARPA Note, by the way, that if you are a university, and want the Wisconsin code, you should get it direct from Wisconsin (lhl@wisconsin?), thus getting a substantial price break. We run the Wisconsin code, but only for remote logins and FTP-style file transfer (ie: we don't yet do mail over it- we use some bisync lines for that). Greg Minshall 16-Nov-84 16:43:18-PST,2024;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Fri 16 Nov 84 16:42:25-PST Received: from mit-multics.arpa by BRL-AOS.ARPA id a010740; 16 Nov 84 19:18 EST Received: from EDUCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2646951313667806@MIT-MULTICS.ARPA>; 16 Nov 1984 19:15:13 est Date: 16-NOV-1984 15:47 EST From: WILLUT%EDUCOM.MAILNET@mit-multics.ARPA To: MSGGROUP@BRL.ARPA Subject: Re: IBM (BITNET) MAIL to DEC (ARPANET) In his message of 10 Nov 1984, ESTEFFERUD@USC-ECL.ARPA mentions ECL's MAILNET software. Most MAILNET sites communicate with the hub (the MULTICS machine at MIT) over dial-up lines using the MMDF link-level protocol and SMTP. Sites with direct access to public data networks typically use X.25 instead of MMDF. Currently, MAILNET interfaces exist for the following environments: Machine Operating Mail Mfr/Model System System --------- --------- ------ Amdahl 5860 MTS $MESSAGE DEC 10 TOPS 20 MM DEC 10/20 TOPS 10 COM DEC 20 TOPS 20 MS DEC 20 TOPS 20 Mail Manager DEC PDP 11/44 UNIX JNT-Mail DEC PDP 11/70 RSTS DREAMS DEC VAX 11/750 VMS VAXMail DEC VAX 11/750 UNIX JNT-Mail DEC VAX 11/780 VMS VAXMail Honeywell 6180 Multics Multics Mail IBM 3081 MVS/Wylbur CONTACT/EMS IBM 3081D MTS $MESSAGE IBM 370 MTS $MESSAGE IBM 370 VM/CMS VM SP2 Mail IBM 4341 MTS $MESSAGE IBM 4341 VM/SP 2 PROFS NAS MVS/Wylbur CONTACT/EMS Perkin-Elmer 3220 OS32MT-R06.2 EIES Sperry 1100/82 EXEC MACC If anyone would like more information, let me know. Candy Willut, MAILNET Operations Manager WILLUT%EDUCOM.MAILNET@MIT-MULTICS.ARPA WILLUT@EDUCOM on BITNET 17-Nov-84 11:36:57-PST,2444;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Sat 17 Nov 84 11:35:20-PST Received: from mit-multics.arpa by BRL-AOS.ARPA id a012434; 17 Nov 84 14:14 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2647019137232764@MIT-MULTICS.ARPA>; 17 Nov 1984 14:05:37 est Date: 17 Nov 84 12:54 +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 Cc: Mailnet_Liaisons@MIT-MULTICS.ARPA Subject: Re: IBM (BITNET) MAIL to DEC (ARPANET) Message-ID: <79061@QZCOM> In-Reply-To: <79037@QZCOM> The University College at Dublin is working on a TOPS-20-version of the COM-RFCMAIL interface (which already exists under TOPS-10). The TOPS-20 version should probably be ready within a couple of months. COM itself already runs under TOPS-20. The advantage of using COM as an interface to mail networks, is that you can receive all mailing lists into one conference in COM for each mailing list. This allows COM users to decide themselves in which order to read mailing lists. When they enter COM, they get a listing which looks like this: You have 5 unseen letters You have 1 unseen entry in Fall DECUS COM demo planning You have 1 unseen entry in Announcement (of new) conferences You have 3 unseen entries in TOPS-10/20 SIG You have 14 unseen entries in Presentation (of new) COM users You have 10 unseen entries in OSIS European working group You have 3 unseen entries in TOPS-20 experts mailing list You have 1 unseen entry in Workstations mailing list You have 13 unseen entries in ADA mailing list You have 18 unseen entries in INFO-VAX mailing list You have 25 unseen entries in Info-Mac Mailing list You have 13 marked notices You have 94 unseen entries The listing contains those conferences they have chosen to parti- cipate in. They can then decide themselves when and in which order to read the different mailing lists. When joining a conference, they will read only entries in that mailing list until they give a command to join another conference. Old entries are also kept some months in a conference, so that new members can read old entries if they so prefer. 18-Nov-84 02:25:11-PST,1324;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Sun 18 Nov 84 02:22:26-PST Received: from usc-ecl.arpa by BRL-AOS.ARPA id a013676; 18 Nov 84 5:08 EST Date: 18 Nov 1984 02:01-PST Sender: ESTEFFERUD@usc-ecl.ARPA Subject: Re: IBM (BITNET) MAIL to DEC (ARPANET) From: ESTEFFERUD@usc-ecl.ARPA To: Jacob_Palme_QZ%QZCOM.MAILNET@mit-multics.ARPA To: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@mit-multics.ARPA Cc: msggroup@BRL-AOS.ARPA, Mailnet_Liaisons@mit-multics.ARPA Message-ID: <[USC-ECL]18-Nov-84 02:01:37.ESTEFFERUD> In-Reply-To: <79061@QZCOM> Thanks Jacob for the pointer to the TOPS-1-/TOPS-20 interface. Perhaps someone can use it to extend the reach of our growing mail internet. As for the need for COM to achieve the results you describe, we do that now at UCI for all BBoards with a BBoards system. this allows any user to be alerted to new mail in bboards of interest, and to keep bboard mail out of private inboxes. Not all sites arrange to have bboards like this, but it is quite easy to establish them on Unix or TOPS-20 systems, as has been done at UCI for both Unix and TOPS-20 systems. Users read BBoards with the same tools they use to read and process regular mail, so the two domains meld together very nicely. Cheers - Stef 19-Nov-84 02:44:32-PST,1290;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Mon 19 Nov 84 02:43:12-PST Received: from mit-multics.arpa by BRL-AOS.ARPA id a015266; 19 Nov 84 5:28 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2647160192855891@MIT-MULTICS.ARPA>; 19 Nov 1984 05:16:32 est Date: 18 Nov 84 23:26 +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, MAILNET_liaisons_group%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, MAILNET_liaisons_group%QZCOM.MAILNET@MIT-MULTICS.ARPA, msggroup@BRL-AOS.ARPA, Mailnet_Liaisons@MIT-MULTICS.ARPA Subject: Re: IBM (BITNET) MAIL to DEC (ARPANET) Message-ID: <79223@QZCOM> In-Reply-To: <[USC-ECL]18-Nov-84 02:01:37.ESTEFFERUD> Yes, TOPS-10/20 systems are on the way out, sad. But we have a system PortaCOM (written in Pascal to 98%) with basically the same functionality as the COM-10/20 system. PortaCOM will soon be available for VAX/VMS, IBM VM/CMS and MVS/TSO plus a number of other major systems. A little later also under Unix. 20-Nov-84 15:19:01-PST,1738;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Tue 20 Nov 84 15:18:20-PST Date: 20 Nov 1984 14:26:39 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 921 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 921: Title: Domain Name System Implementation Schedule - Revised Author: Jon Postel Mailbox: Postel@ISIF Pages: 13 Characters: 24018 pathname: RFC921.TXT This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet. This memo is an update of RFC-881, and RFC-897. This is an official policy statement of the IAB and the DARPA. The intent of this memo is to detail the schedule for the implementration for the Domain Style Naming System. The explanation of how this system works is to be found in the references. 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. ------- 21-Nov-84 12:07:10-PST,3475;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Wed 21 Nov 84 12:01:50-PST Received: from mit-multics.arpa by BRL-AOS.ARPA id a020685; 21 Nov 84 14:39 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2647366283375113@MIT-MULTICS.ARPA>; 21 Nov 1984 14:31:23 est Date: 21 Nov 84 05:27 +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: Subject: Conference systems versus Bulletin Board systems Message-ID: <79509@QZCOM> In-Reply-To: <[USC-ECL]18-Nov-84 02:01:37.ESTEFFERUD> Well, I have never quite understood the difference between a "computer conference system" and a "bulletin board system". Certainly there are more or less advanced versions of systems called one or the other, and perhaps some BBoard systems are less advanced than some conference systems, I am not sure. Anyway, here are some functions of COM, you will have to check if BBoard systems normally have these functions or not: (a) The computer remembers how far you have read in each conference, so that you will not be shown the same message again unless you ask for it. You can however yourself manipulate this marker of how far you have read yourself. Even if the same message is sent via two mailing lists (entered into two conferences) and you subscribe to both, you will only be shown the message once (unless you set a special mode in order to see the message when you get to it in both conferences). (b) Even if the same message is sent to you both via a mailing list and as personal mail to you, you will only be shown the message once. (c) One and the same message can easily be sent to both one or more lists and one or more persons, and a comment is by default sent to the same recipients. (d) The same message is only stored once in your computer even if it is sent to several lists and/or people. (e) Old messages are retained on disk and are retrievable for a certain time period (usually 3-12 months) using various retrieval alternatives. (f) A received message can be re-sent to any number of local conferences or people by just adding links to it, not copying the actual text on disk. (g) If a message from the network is entered into a local conference which has external (network mail) members, the message is not sent out again to the network to those members who were on the list of recipients when the message arrived. (h) Parallel conferences, with copying of all entries between them, are easily set up on several COM systems communicating via network mail. No need for a hierarchical structure to control loops. (i) In-Reply-To links are preserved in the data base and available for retrieval, e.g. to retrieve the set of all messages linked directly or indirectly by such links or to follow the links upp or down. Note: Some of the facilities listed above will, for messages not originating in a COM system, only work if the incoming messages make correct use of Message-Id and In-Reply-To fields. I am planning to add a checksum facility to the COM RFC-mail interface, so as to be able to recognize the same message coming twice even if no Message-Id is used. 25-Nov-84 11:22:48-PST,2015;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Sun 25 Nov 84 11:20:56-PST Received: from mit-multics.arpa by BRL-AOS.ARPA id a003957; 25 Nov 84 14:00 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2647709795468488@MIT-MULTICS.ARPA>; 25 Nov 1984 13:56:35 est Date: 25 Nov 84 16:21 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, MHS_implementation%QZCOM.MAILNET@MIT-MULTICS.ARPA To: MHS_implementation%QZCOM.MAILNET@MIT-MULTICS.ARPA Bcc: Announcement_conferences%QZCOM.MAILNET@MIT-MULTICS.ARPA, MHS_subsetting_group_%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people , msggroup@BRL-AOS.ARPA, mailgroup@ucl-cs..arpa, Mailnet_implementation_and_JNT-MAIL%QZCOM.MAILNET@MIT-MULTICS.ARPA, External_mail_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: MHS (X.400) implementation Message-ID: <80073@QZCOM> A new QZCOM conference with the name "MHS (X.400) implementation" has been started. The conference will to mail networks have the name "MHS_(X.400)_implemenetation", in most cases postfixed by "%QZCOM@MIT-MULTICS.ARPA". The conference/mailing list is open for anyone who is seriously interested in implementing the CCITT X.400 (MHS) message handling protocols or gateways to these protocols. In the conference/mailing list we can for example discuss how to understand and interpret the MHS recommendation, how to map existing mail system and mail network features onto the MHS structure etc. To join the conference do as follows: QZCOM users: Use the "member" command. Users at other sites: Write a letter to me personally, "Jacob_Palme_QZ %QZCOM.MAILNET@MIT-MULTICS.ARPA", do NOT write to the conference itself. 4-Dec-84 13:11:35-PST,1684;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Tue 4 Dec 84 13:11:11-PST Date: 4 Dec 1984 11:31:17 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 922 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 922: Title: Broadcasting Internet Datagrams in the Presence of Subnets Author: Jeffrey Mogul Mailbox: Mogul@SU-SCORE Pages: 12 Characters: 24832 pathname: RFC922.TXT We propose simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. 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. ------- 6-Dec-84 15:36:09-PST,1873;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Thu 6 Dec 84 15:36:02-PST Date: 6 Dec 1984 13:53:19 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 915 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 915: Title: Network Mail Path Service Author: Marc A. Elvy and Rudy Nedved Mailbox: RFC-915@HARVARD.ARPA Pages: 11 Characters: 22262 pathname: RFC915.TXT This RFC proposed a new service for the ARPA-Internet community and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. The network mail path service fills the current need of people to determine mailbox addresses for hosts that are not part of the ARPA-Internet but can be reached by one or more relay hosts that have Unix to Unix Copy (UUCP) mail, CSNET mail, MAILNET mail, BITNET mail, etc. Anyone can use the service if they have TCP/TELENET to one of the hosts with a mail path server. 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. ------- 14-Dec-84 17:41:14-PST,1779;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Fri 14 Dec 84 17:38:39-PST Date: 14 Dec 1984 16:04:34 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 926 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 926: Title: Protocol for Providing the Connectionless-Mode Network Services Author: ISO Mailbox: McKenzie@BBN-UNIX.ARPA Pages: 107 Characters: 172025 pathname: RFC926.TXT This note is the draft ISO protocol roughly similar to the DOD Internet Protocol. This document has been prepared by retyping the text of ISO DIS 8473 of May 1984, which is currently undergoing voting within ISO as a Draft International Standard (DIS). This document is distributred as an RFC for information only. It does not specify a standard for the ARPA-Internet. 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. ------- 19-Dec-84 11:43:43-PST,1872;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Wed 19 Dec 84 11:40:34-PST Date: 19 Dec 1984 09:57:11 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 927 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 927: Title: TACACS User Identification Telnet Option Author: Brian Anderson Mailbox: BAANDERS@BBN-UNIX.ARPA Pages: 4 Characters: 5702 pathname: RFC927.TXT The following is the description of a TELNET option designed to facilitate double login avoidance. It is intended primarily for TAC connections to target hosts on behalf of TAC users, but it can be used between any two consenting hosts. For example, all hosts at one site (e.g., BBN) can use this option to avoid double login when TELNETing to one another. 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. ------- 20-Dec-84 15:44:39-PST,2281;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Thu 20 Dec 84 15:41:24-PST Date: 20 Dec 1984 14:35:49 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 928 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 928: Title: Introduction to Proposed DOD Standard H-FP Author: M. A. Padlipsky Mailbox: PADLIPSKY@USC-ISI.ARPA Pages: 21 Characters: 61658 pathname: RFC928.TXT The broad outline of the Host-Front End Protocol introduced here and described in RFC 929 is the result of the deliberations of a number of experienced H-FP designers, who sat as a committee of the DoD Protocol Standards Technical Panel. It is the intent of the designers that the protocol be subjected to multiple test implementations and probable iteration before being agreed upon as any sort of "standard". Therefore, the first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author (617-271-2978 or Padlipsky@USC-ISI.ARPA.). 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. ------- 21-Dec-84 17:11:34-PST,1930;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Fri 21 Dec 84 17:10:48-PST Date: 21 Dec 1984 16:24:56 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 929 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 929: Title: Proposed Host-Front End Protocol Author: Lilienkamp, Mandell, and Padlipsky Mailbox: PADLIPSKY@USC-ISI.ARPA Pages: 56 Characters: 138234 pathname: RFC929.TXT The Host-Front End Protocol introduced in RFC-928 is described in detail in this memo. The first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author (617-271-2978 or Padlipsky@USC-ISI.ARPA). 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. ------- 7-Jan-85 11:54:20-PST,1757;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Mon 7 Jan 85 11:50:40-PST Date: 7 Jan 1985 09:30:51 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 930 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 930: Title: Telnet Terminal Type Option Author: M. Solomon, and E. Wimmers Mailbox: SOLOMON@UWISC Pages: 4 Characters: 7079 pathname: RFC930.TXT This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. Distribution of this memo is unlimited. This standard supersedes RFC 884. The only change is to specify that the TERMINAL-TYPE IS sub-negotiation should be sent only in response to the TERMINAL-TYPE SEND sub-negotiation. 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. ------- 8-Jan-85 13:16:54-PST,1705;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Tue 8 Jan 85 13:16:16-PST Date: 8 Jan 1985 11:13:29 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 931 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 931: Title: Authentication Server Author: Mike StJohns Mailbox: StJohns@MIT-MULTICS Pages: 5 Characters: 9536 pathname: RFC931.TXT This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is the second draft of this proposal (superseding RFC 912) and incorporates a more formal description of the syntax for the request and response dialog, as well as a change to specify the type of user identification returned. 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. ------- 24-Jan-85 12:55:11-PST,1777;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Thu 24 Jan 85 12:53:28-PST Date: 24 Jan 1985 11:15:42 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 932 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 932: Title: A Subnetwork Addressing Scheme Author: David D. Clark Mailbox: DClark@MIT-MULTICS Pages: 4 Characters: 9509 pathname: RFC932.TXT This RFC proposes an alternative addressing scheme for subnets which, in most cases, requires no modification to host software whatsoever. The drawbacks of this scheme are that the total number of subnets in any one network are limited, and that modification is required to all gateways. 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. ------- 27-Jan-85 09:53:11-PST,1413;000000000001 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Sun 27 Jan 85 09:52:56-PST Received: from brl-bmd.arpa by BRL-AOS.ARPA id a000323; 27 Jan 85 12:37 EST Received: from csnet-relay.arpa by BRL-BMD.ARPA id a000530; 26 Jan 85 13:23 EST Received: from hplabs by csnet-relay.csnet id ac17800; 26 Jan 85 2:43 EST Received: by HP-VENUS id AA28339; Fri, 25 Jan 85 19:05:57 pst Message-Id: <8501260305.AA28339@HP-VENUS> Date: Fri 25 Jan 85 19:06:21-PST From: "Scott L. McGregor" Subject: IBM connections to CSNet etc. To: msggroup@BRL-BMD.ARPA Source-Info: From (or Sender) name not authenticated. A while back ago I remember hearing about IBM systems gatewaying to CSNet and/or ARPANet. I am interested in finding out more information about such a gateway. If I remember clearly, U. of Wisconsin has something to do with it, but I'm not sure. If anyone can give me some pointers to published information on this interface or to knowledgable people, I would appreciate it. I am also interested in IBM connections to X.25 public networks, and to 802.3 and EtherNet LANs if some one can give me some pointers. Thank you all in advance for any help in this matter, apologies to those who would rather not have received this open letter. Scott L. McGregor Hewlett-Packard Company Corporate Data Center ------- 27-Jan-85 14:15:50-PST,1544;000000000001 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Sun 27 Jan 85 14:14:00-PST Received: from usc-ecl.arpa by BRL-AOS.ARPA id a001585; 27 Jan 85 16:55 EST Date: 27 Jan 1985 13:56-PST Sender: ESTEFFERUD@usc-ecl.ARPA Subject: Re: IBM connections to CSNet etc. From: ESTEFFERUD@usc-ecl.ARPA Reply-To: "Attn: EStefferud-MsgGroup-Moderator" To: msggroup@brl.ARPA Message-ID: <[USC-ECL]27-Jan-85 13:56:41.ESTEFFERUD> In-Reply-To: <8501260305.AA28339@HP-VENUS> Before you all dig up some of the following messages (or information) for a reply To: MCGREGOR%hplabs.csnet@CSNET-RELAY, note that I have forwared these already. If any of you want a copy of the forwarded bundle, I will be pleased to ReSend it to you on request. Best - Stef Subject: Ibm (bitnet) mail to Dec (Arpanet) 1603 chars Sat 10 Nov 84 15:19:41-PST From: Bob Larson Received: from USC-ISIF by USC-ECLC; Tue 29 Jan 85 13:01:53-PST Date: 29 Jan 1985 10:58:30 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 933 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 933: Title: Output Marking Telnet Option Author: Steve Silverman Mailbox: blankert@MITRE-GATEWAY Pages: 4 Characters: 6943 pathname: RFC933.TXT This proposed option would allow a Server-Telnet to send a banner to a User-Telnet so that this banner would be displayed on the workstation screen independently of the application software running in the Server-Telnet. 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. ------- 29-Jan-85 15:07:35-PST,2201;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Tue 29 Jan 85 15:07:26-PST Date: 29 Jan 1985 13:47:59 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 934 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 934: Title: Proposed Standard for Message Encapsulation Author: M. Rose and E. Stefferud Mailbox: MRose@UDel.ARPA, or Stef@UCI.ARPA Pages: 10 Characters: 22340 pathname: RFC934.TXT This memo concerns itself with message forwarding. Forwarding can be thought of as encapsulating one or more messages inside another. Although this is useful for transfer of past correspondence to new recipients, without a decapsulation process (which this memo terms "bursting"), the forwarded messages are of little use to the recipients because they can not be distributed, forwarded, replied-to, or otherwise processed as separate individual messages. In order to burst a message it is necessary to know how the component messages were encapsulated in the draft. At present there is no unambiguous standard for interest group digests. This RFC proposes 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. ------- 30-Jan-85 12:05:40-PST,2011;000000000001 Return-Path: Received: from USC-ISIF by USC-ECLC; Wed 30 Jan 85 12:02:36-PST Date: 30 Jan 1985 10:43:19 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 935 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 935: Title: Reliable Link Layer Protocols Author: J. Robinson Mailbox: JRobinson@BBN-Unix Pages: 13 Characters: 32335 pathname: RFC935.TXT This RFC discusses protocols proposed recently in RFCs 914 and 916, and suggests a proposed protocol that could meet the same needs addressed in those memos. The stated need is reliable communication between two programs over a full-duplex, point-to-point communication link, and in particular the RFCs address the need for such communication over an asynchronous link at relatively low speeds. The suggested protocol uses the methods of existing national and international data link layer standards. 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. ------- 30-Jan-85 21:39:43-PST,529;000000000001 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Wed 30 Jan 85 21:36:32-PST Received: from mit-mc.arpa by BRL-AOS.ARPA id a000310; 31 Jan 85 0:15 EST Date: Thu 31 Jan 85 00:14:48-EST From: Gregbo Subject: mail between IBM's internal net and other nets To: msgroup%MIT-OZ@MIT-MC.ARPA The best place to ask those kinds of questions is info-nets%mit-oz@mit-mc.arpa. Greg Skinner gds@mit-xx.arpa {allegra,cbosgd,ihnp4}!houxm!gregbo (uucp) ------- 1-Feb-85 17:49:39-PST,2508;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Fri 1 Feb 85 17:49:09-PST Date: 1 Feb 1985 15:53:44 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 936 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 936: Title: Another Internet Subnet Addressing Scheme Author: M. Karels Mailbox: Karels@Berkeley Pages: 4 Characters: 10407 pathname: RFC936.TXT There have been several proposals for schemes to allow the use of a single Internet network number to refer to a collection of physical networks under common administration which are reachable from the rest of the Internet by a common route. Such schemes allow a simplified view of an otherwise complicated topology from hosts and gateways outside of this collection. They allow the complexity of the number and type of these networks, and routing to them, to be localized. Additions and changes in configuration thus cause no detectable change, and no interruption of service, due to slow propagation of routing and other information outside of the local environment. These schemes also simplify the administration of the network, as changes do not require allocation of new network numbers for each new cable installed. This proposal discusses an alternative scheme, one that has been in use at the University of California, Berkeley since April 1984. 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. ------- 6-Feb-85 11:03:22-PST,1161;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Wed 6 Feb 85 11:02:40-PST Received: from css-ring-gw by BRL-AOS.ARPA id a019831; 6 Feb 85 13:32 EST Return-Path: Received: from hadron.UUCP by seismo.ARPA with UUCP; Wed, 6 Feb 85 13:32:28 EST Received: by hadron.UUCP (4.12/4.7) id AA28095; Wed, 6 Feb 85 12:25:52 est Date: Wed, 6 Feb 85 12:25:52 est From: "Joseph S. D. Yao" Message-Id: <8502061725.AA28095@hadron.UUCP> To: seismo!HEADER-PEOPLE@MIT-MC.ARPA, seismo!MMM-PEOPLE@USC-ISIF.ARPA, seismo!MsgGroup@BRL.ARPA Subject: Sendmail-like entity on System V? I'm not (yet) on this newsgroup, so any responders will have to mail to me directly at the address below. We very much like the way that sendmail on 4BSD works (at least, usually). One of our folk, however, has to use some System V machines. I was wondering if there was a version of sendmail for S-V? (He wants it last week, of course.) Appreciate any info. If this hasn't already been on the net, I'll summarise and put it back out. Joe Yao hadron!jsdy@seismo.{ARPA,UUCP} 6-Feb-85 14:17:01-PST,1020;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Wed 6 Feb 85 14:11:50-PST Received: from brl-tgr.arpa by BRL-AOS.ARPA id a002614; 6 Feb 85 16:46 EST Date: Wed, 6 Feb 85 16:36:00 EST From: Doug Kingston To: "Joseph S. D. Yao" cc: header-people@MIT-MC.ARPA, mmm-people@USC-ISIF.ARPA, msggroup@BRL.ARPA Subject: Re: Sendmail-like entity on System V? MMDFII has been ported to System V on the Vax. I suspect it will also work with little work on other 32bit System V implementatins. MMDFII will be released in the near future through BRL and UCL-CS under minimal licensing. Stay tuned for an announcement (1 - 2 weeks from now). MMDFII in a entire mail system including an MSG/SEND style user interface, (Cap)Mail user interface, a uucp channel, a TCP/SMTP channel, an EAN channel, a NIFTP channel, a list-processor, a Phonenet channel, and a powerful local delivery facility. -Doug- 8-Feb-85 11:19:12-PST,1688;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Fri 8 Feb 85 11:18:23-PST Date: 8 Feb 1985 09:43:17 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 937 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 937: Title: Post Office Protocol - Version 2 Author: M. Butler, J. Postel, D. Chase, J. Goldberger, and J. K. Reynolds Mailbox: JKReynolds@USC-ISIF.ARPA Pages: 24 Characters: 43762 pathname: RFC937.TXT This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. This memo is a revision of RFC%918. 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. ------- 13-Feb-85 16:56:12-PST,20600;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Wed 13 Feb 85 16:53:01-PST Received: from mit-multics.arpa by BRL-AOS.ARPA id a016910; 13 Feb 85 18:38 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2654637548878890@MIT-MULTICS.ARPA>; 13 Feb 1985 18:19:08 est Date: 03 Feb 85 16:38 +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: Lines: 402 Report from the meeting with ISO/TC 97/SC 18/WG 4 in Munich, Message-ID: <89059@QZCOM> January 14-18, 1985. (Warning: This text is about 400 lines long.) At the meeting were representatives from U.K., France, Japan, W. Germany, Sweden, Norway, Japan, Canada and the U.S.A. The main task for the ISO/TC 97/SC 18/WG 4 group is to make the CCITT standard X.400 also into an ISO standard. The group has got strong directives from many of the national standards organizations that the standard it produces must be highly compatible with X.400. The general feeling I got at the group was that since the group was not allowed to spend very much effort on meaningful technical modifications to X.400, it spent most of its time discussing what I felt was rather meaningless discussions of wordings which will not influence the way the standards will be used. I tried to take up some points where the X.400 standard is seriously deficient, but I was not able to get the group to agree to any meaningful technical improvement of X.400 even on techni- cally small (but in usage important) changes. Compatibility with the CCITT standard was obviously more important to the group than producing a good standard. I also got the impression that some of the participants of the group did not have much experience with the problems which occur when you run large computer-based message systems with thousands of participants and millions of message receptions a year. It surprises me that standards for such systems are produced by people with so little understanding of such problems. The notes below are my personal notes. They are not in any way complete, I noted down what I found interesting only, and in those subgroups which I had time to participate in. Carl-Uno Malmros reported from the CCITT directory group, that this group has decided to change from a naming graph to a naming tree in order to simplify distributed implementation. Japan claimed problems with international management domains, and proposed to stay with X.400 in this area. The German group said they preferred ISO to produce a document which just points out the differences between the CCITT X.400 recommendation and the ISO view, instead of producing a separate ISO document. The U.S. representant had the same opinion. This, however did not apply to the MTSL, where they wanted a separate ISO document. The U.K. delegation said on the other hand, that we in ISO should keep control by having our own documents, and that future develop- ment may mean that CCITT and ISO interests in this are will diverge. Japan had the same opinion, and claimed that this would save work, since the ISO document is almost ready in its format as a separate document. The chairman said that there is no procedural rule against ISO adopting a CCITT document with a suitable explanatory ISO cover, if this is what ISO wants. The chairman suggested a straw vote on the subject. Four delegations voted for basing our standard on the CCITT document (Germany, U.S.A., Japan, Canada) three voted for keeping a full separate ISO document (U.K., Norway, France). I abstained as Swedish representative. The chairman concluded that we should go on with producing the "delta" document (defining just the differences between MOTIS and the CCITT MHS). Note: This decision only applies to X.400 and X.401, not to the whole X.400 series. And the ISO group will clearly indicate that their adopting of the X.400 document as a basis only applies to the technical contents, not to the regulatory constraints in it. ISO will continue to call its standard "MOTIS" to distinguish it from the CCITT recommendation which is called by the name "MHS". We decided to split into three subgroups during the next days: (1) Functional model (the "delta" document). (2) Management issues (directories and distribution lists). (3) Message Transfer Layer Services. Between 15.30 and 17.30 on monday, the subgroup on management issues had its first meeting. The chairman of the group was Roger W. Forte of IBM, U.S.A. The chairman proposed that the group begin by discussing distribution lists, since some new ideas in this area had been contributed for this meeting. I presented the idea of a more general concept called "distributor" which in addition to the facilities of distribution lists would also encompass facilities commonly found in computer conferences, electronic bulletin boards, electronic publishing systems etc. This might entail facilities for control of message distribution not only with the sender, but also with the recipient, facilities not only for sending but also for reading and retrieving messages etc. Other group participants took up other structures which may be requrired like ordered circulation of a document in an office (e.g. en application first goes to the boss for approval, then to the order office for performance). Others mentioned voting procedures, others mentioned organizations wanting special control on who is allowed to talk to whom. The group discussed a little whether this really belongs to the area of directory systems, and in general seemed to feel that although some of the facilities of a distributor certainly must be handled by directory systems (like listing the names of distributors, storing certain capabilities of them like if anyone is allowed to add themselves to the list (open lists) or not (closed lists)), some other features might better be handled by special agents which could be called "distributor agents" and which would have much in common with ordinary user agents. Some discussion was also made of implementation issues, especially for the case of very large lists, with perhaps hundreds of thousands of subscribers, which might occur in the future. It was generally felt that such large lists would have to be split up in a tree structure, e.g. one agent distributes the message to a subagent for Germany and another subagent for France a.s.o. and then the subagent for Germany distributes it to subagents for different German states a.s.o. so that the list created in each operation is kept reasonably small. Report from Tuesday plenary meeting: Report from the functional specifications group: The work of producing the "delta" document was based on the proposal for such a document provided by the American delegation. There is a need to produce a text which describes why the ISO standard is different from the CCITT X.400 recommendation in some areas. There is a question of whether the "delta" document should replace fully all paragraphs in the CCITT document, on which there is some difference, or should it instead describe the differerences, which often will be simpler. Some basic changes: "MHS" is replaced with "MOTIS", "recommendation" with "international standard". The ISO view is that the MOTIS boundary goes through the middle of the UA, not between UA and MTA. There was a long discussion about whether ISO should include the P3 protocol or not. The present view is that it should not be included until this in the future may be felt really necessary. The decision to adopt a "delta" document in reference to the CCITT documents X.400 and X.401, instead of producing a full separate ISO text, was again opposed by one of the British delegates, who tried to reverse the decision of yesterday and threatened that he would recommend to the U.K. standards institute to reject the standard, and will thus jeopardise the possibillity to produce a standard which will be accepted. Thus, although a majority supported a delta document, the requirement for a consensus would be violated if this view was accepted. The chairman however was not willing to change the decision of yesterday, since we did not know if the U.K. institute would really act in accordance with such a recommendation by its delegate at the meeting. In the afternoon, the subgroup on management issues met again. One main topic of discussion was in which ways management domains and naming authorities can or cannot overlap. The next morning, the subgroup on management issues discussed distribution lists in the limited sense not including message storage. The group noted that unique IPMessageId-s for all messages is of prime importance for loop control, and the MHS should be redefined to make IPMessageId-s unique by (i) making the O/R name component of it compulsory (ii) specifying that for a UA having several aliases, the O/R name in the IPMessageId should either always refer to the "distinguished name" or else always refer to the original name given at document creation time, even if the UA referred to in the O/R name component of the IPmessageId later changes. Solution (ii) is probably better. The group discussed naming of distribution lists, and agreed that these names should be distinct from names of ordinary UA-s, either by an additional field, or by a separate set of naming conventions for distribution lists. Then Bob Willmot, who had previously not been present, arrived at the meeting. He was of the opinion that the IPMessageId could not be used for unique identification of documents, only for the unique identification of messages, which caused a long heated debate in the group. The general opinion of everyone except Bob Willmot was that the need for unique document identifiers is so strong and important, that we should try to use a modification of the existing IPMessageId so as to get something which works in a reasonable time. Bob Willmot argued that unique document ID-s are only needed in group communication, and should be part of special protocols for group communication, but we argued that the present MOTIS standard already includes group communication (since it includes lists of more than one recipient, and forwarding of messages) and thus that the problem exists also in MOTIS as it stands today. In further discussion of this subject Fred Sztajnkrycer and Bob Willmot said that document identification does not belong to the MTS at all. Bob Willmot said, however, that he was not unwilling to try to make the modifications of the definition of the IPMessageId which the other participants wanted. The group then discussed the handling of trace information when forwarding messages between domains. This was explained to work in the following way: Inside one management domain, trace information is kept to avoid looping inside this domain. When the message passes to another management domain, that trace information is thrown away, but global trace information is created to stop the document being passed back to the same domain again. We decided to split up into a small group to define user requirements on the directory services. We further decided to ask the plenary meeting to comment on whether the document "Management Issues in Motis" (ISO/TC 97/SC 18/WG4 N216) should develop into a standard, or should be a vehicle for discussion and new ideas. Thursday meeting with User Agent Sublayer group: A long discussion about whether a globally unique IPMessageId should be required of all IPMessages. Those who wanted this said that this will avoid confusion with separate copies of the same IPMessage being referenced, stored or delivered without notification that they do refer to the same text. Those who did not want this were afraid of incompatibility with the CCITT standard, and said that certain documents which would only be circulated in very local contexts would not need this. The group agreed on the solution to say that the O/R name component of IPMessageId-s (which makes them unique) should be kept non-mandatory, but that a strong recommendation should be given that it always should be used. The group noted later on that ISO wants more different kinds of message content types than CCITT has in its recommendation. Plenary meeting Thursday afternoon: The group decided to write to SC18 and ask if two new topics should be taken up for discussion in WG4: (i) Directories (of O/R names and addresses for MHS systems) (ii) Group communication facilities (computer conferencing, bulletin boards, mailing lists, electronic publishing etc.). I proposed that the sentence describing the purpose of MOTIS be changed to say that MOTIS is meant to provide good services for both senders and recipients of messages, not, as it says today, only for senders. This was rejected by the group, with the arguments that (i) the wording of this phrase had been discussed so many times that it is too late to change it now (ii) MOTIS, according to the majority of the group, is meant for use in an office environment. (My comment: Why is not design of systems to satisfy the needs of recipients needed in office environments?) General comment: It has been very difficult to get the people in the ISO group to understand the group communication problems which will occur when these systems are introduced in a wide scale. Some of the people in this group seem to be rather narrowminded and the only possible way to get a reasonable international standard will be to get new people active in the ISO group. Perhaps COST-11- ter could use some of its money to support activities in ISO by GILT people? Perhaps one could get the many people involved with group communication systems in the U.S. and Canada to become active in ISO work? Some differences between ISO and CCITT standards on MHS: ------------------------------------------------------- Regulatory aspects are omitted in ISO standards. Private Management Domains may exists, and may even go beyond one country according to the ISO standard. Transmission between countries need not, in the ISO model, always go via the systems provided by the PTT-s. Additional services: Content type protocol capability (checking which content types a UA is able to receive), use of distribution lists, originator-requested alternate recipients if the primary recipient cannot receive the message, latest delivery designation, typed body indication, message circulation. ---------------------------------------------------------------- Summary of main points where I and Knut Smaaland (the Norwegian representative) think we must try to get ISO to change their minds: - Handling of national character sets. A reasonable solution must be found to the problem of national characters in names of domains, organizations, user agents etc. - MOTIS wide unique IPMessageId-s. These must be mandatory and created at origination time or when a message is first submitted to MOTIS. - Comment-service, i.e. a service to get a comment on a message sent to all recipients of the message. - O/R names contain information showing if they refer to a UA or DA (Distribution list, Computer conference etc.) - Change the primary purpose paragraph to relate to the interests of both senders and recipients. Should we try to introduce these ideas from Sweden into the SC18 plenar meeting in April? Norway will probably put forward similar ideas! Friday: Final plenary session ----------------------------- ISO will write to CCITT and suggest that the character set in names (O/R names, organization names etc.) is changed to the set of all graphic characters of T.61 in order to accommodate national characters. ISO wants (a) that a sender can ask that a message is redirected by the MTS, if a recipient is not reachable, to another recipient, (b) that a recipient can ask the MTS to redirect his messages to another recipient for a certain time, (c) that an originator can prohibit such redirection for a certain document. Knut Smaaland said that the way of resolving the relations between administrative and private management domains is artificial and it would be better, in an ISO environment, to use the protocols specified for administrative management domains for all domains. The phrase about distribution lists in the text about requirements on directory services was changed to read "The distribution list expansion function can be a special function of the directory service, which may be used by different entities of MOTIS". In this way, we do not restrict which solutions may be chosen in future development of the distribution list concept. We decided to remind the relevant groups of CCITT and ISO of the character set problem in directory services and the need to choose a character set in which all names in all different languages can be represented either directly or via transcription rules. The group decided to ask SC 18 to send out for a three month first letter ballot the functional specification (delta document) and the MTSL service and message transfer protocol specification. The decision was unanimous except that U.K. voted NO on the functional specification because they did not like the "delta" format of the document (but accepted the tecnical content). If SC18 gives a positive answer on the question of group communication, an ad hoc meeting on this in May should take place. May 20-24 in Paris was decided, with Fred S as chairman. Next plenary: July 8-12 possibly in Oslo. Next to next meeting with WG4 plenary: January 13-17, 1986, somewhere in North America. Summary of impressions from the ISO WG4 meeting: ----------------------------------------------- The main problem for this ISO group is the existence of a CCITT standard and the strong wishes expressed by many national member bodies of ISO not to get two incompatible international standards. The ISO group thus is very restricted in making any changes to the CCITT standard which will give compatibility problems between systems adhering to the ISO and the CCITT standard. The work in the ISO group thus seems mainly directed at modifying the CCITT standard in ways which is not dangerous for compatibility: - Pure extensions, like the ISO facility of a sender to be able to specify a secondary recipient if the primary recipient is not available. - Changes in wording, or in the managerial practices, which do not endanger compatibility on a more technical level. Most important here of course is that ISO is designing a standard which does not require the use of any PTT MTA-s. The ISO standard thus allows non-PTT message systems to communicate directly, even across national borders, using the ISO version of the MHS standard. I guess the PTT-s will not be happy about this, but I also believe the PTT-s will find it very difficult to stop this. For example, computers in Sweden, Norway and Canada are already communicating directly with the MHS protocols (using the public X.25 networks, but not using any public MTA services) and my guess is that PTT provided MTA services will not be able to succeed by trying to enforce their usage by regulation, but only by providing a service with a quality and price which is competitive in the future market of message transfers. Much of the discussion in the group seems to be discussions of small changes in the wordings, which I do not quite see as very important for the future of message system interchange. One major disappointment was the lack of understanding among many participants of the need for better facilities for group communication. From personal discussions with participants I understood that they had very little experience with and understanding of this problem, and yet they rejected the idea without even first trying to understand what it was that they were rejecting. I can only hope that the SC 18 meeting in April will be willing to try to understand this problem before making up their minds about it. 15-Feb-85 06:15:46-PST,765;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Fri 15 Feb 85 06:14:01-PST Received: from nswc-wo.arpa by BRL-AOS.ARPA id a002726; 15 Feb 85 8:50 EST Date: 15 Feb 85 08:48 EST From: Bob Sparbel Subject: Path to CompuServe To: msggroup@brl.ARPA cc: sparbel@nswc-wo.ARPA, stew@harvard.ARPA I'm not sure this is the right place to ask this question, but I didn't know where else to try. Is there a way to send electronic mail on MILNET and have it end up at a CompuServe mail box or closed user group? If there is, please explain how carefully and in detail. Include example if you can. I am not on this group so please answer directly to me. Thanks for the help. Bob ------- 15-Feb-85 12:01:28-PST,1305;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Fri 15 Feb 85 12:00:33-PST Received: from ucb-vax.arpa by BRL-AOS.ARPA id a009459; 15 Feb 85 14:34 EST Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.41) id AA03861; Fri, 15 Feb 85 11:18:52 pst Received: from CORNELLA.BITNET by ucbjade.CC.Berkeley.ARPA (4.19/4.33.1) id AA07558; Fri, 15 Feb 85 11:19:30 pst Message-Id: <8502151919.AA07558@ucbjade.CC.Berkeley.ARPA> Date: 15 February 85 14:16 EST From: RMXJARTJ%CORNELLA.BITNET@ucb-vax.ARPA Subject: (copy) Path to Compuserve To: MSGGROUP@BRL-AOS.ARPA Originally sent from: RMXJARTJ@CORNELLA Originally sent to: SPARBEL@NSWC-WO.ARPA As far as I know the only way to send mail to Compuserve (and because it is the same idea: The Source) mailboxes is to actually be on the system. I suggested to Compuserve back in December that they investigate getting on a network and I have not logged back in to see if they responded as yet. Besides using Compuserve's dial-up system to hook into the database, you can also connect up to TELENET and connect up to Compuserve by doing this: C 202202 Which is their address via a Washington, DC node. -- Gligor Tashkovich RMXJITRY%CORNELLA.BITNET@WISCVM.ARPA 20-Feb-85 21:24:01-PST,1004;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Wed 20 Feb 85 21:20:26-PST Received: from css-ring-gw by BRL-AOS.ARPA id a000570; 20 Feb 85 23:57 EST Return-Path: Received: from hadron.UUCP by seismo.ARPA with UUCP; Wed, 20 Feb 85 23:56:17 EST Received: by hadron.UUCP (4.12/4.7) id AA10294; Wed, 20 Feb 85 23:54:41 est Date: Wed, 20 Feb 85 23:54:41 est From: "Joseph S. D. Yao" Message-Id: <8502210454.AA10294@hadron.UUCP> To: seismo!MsgGroup@BRL.ARPA Subject: Summary: Sendmail-like entity on Sysem V. Cc: jsdy@SEISMO.ARPA Thanks to all who responded. Many suggested porting sendmail itself, apparently not only easy but (what had worried me more) legal. The other major suggestion was BRL's MMDF. MMDF II has just been released. We're going to look at both to see how well we can tie them in to the existing systems. [BTW, we have news now.] Joe Yao hadron!jsdy@seismo.{ARPA,UUCP} 25-Feb-85 12:22:38-PST,1278;000000000000 Return-Path: Received: from BRL (for BRL-AOS) by USC-ECLC; Mon 25 Feb 85 12:21:13-PST Received: from mit-multics.arpa by BRL-AOS.ARPA id a026743; 25 Feb 85 14:54 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2655661837469208@MIT-MULTICS.ARPA>; 25 Feb 1985 14:50:37 est Date: 25 Feb 85 17:56 +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: "Computer conferencing" Message-ID: <92645@QZCOM> The word "computer conferencing" to designate a certain kind of computer message system has many drawbacks. Many people believe that this is some kind of simultanous conferencing medium comparable to audio or video conferencing, while in fact computer conferencing is much closer to electronic mail than to simultaneous conferencing media. Has anyone any idea for a better name for this concept? The best I can think of now is "group communication facilities in electronic message systems" but that is a little too long. Please help! 25-Feb-85 12:54:48-PST,1862;000000000000 Return-Path: Received: from USC-ISIF by USC-ECLC; Mon 25 Feb 85 12:54:34-PST Date: 25 Feb 1985 11:25:28 PST From: WESTINE@USC-ISIF.ARPA Subject: RFC 938 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 938: Title: Internet Reliable Transaction Protocol Functional and Interface Specification Author: Trudy Miller Mailbox: Trudy@ACC Pages: 16 Characters: 41583 pathname: RFC938.TXT This RFC is being distributed to members of the DARPA research community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the DARPA community, they may be interesting to a number of researchers and implementors. 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. -------