----MESSAGE-BEGIN---- <1984030708580000> Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC with TCP; Wed 7 Mar 84 17:13:56-PST Date: 7 Mar 1984 1658 PST From: Eric P. Scott Subject: DECUS foulup To: TCP-IP@SRI-NIC Reply-To: EPS@JPL-VLSI "Internetworking the ARPA Way" has been tentatively scheduled for 1:00 p.m. Friday and cut to 1 1/2 hrs. even though I had specifically requested otherwise. The "official story" is that the scheduling constraints on the submission form were never entered into the online system. I have asked the Networks Symposia Coodinator for a reschedule; we'll see what happens. -=EPS=- ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984031011465900> Return-Path: Received: from ddn1 by SRI-NIC with TCP; Sat 10 Mar 84 13:53:12-PST Date: 10 Mar 84 16:46:59 EST From: dca-pgs @ DDN1 Subject: DDN Cutover Announcement--Naval Regional Data Automation Center (NARDAC), Washington, DC To: allusers @ DDN1, allusers @ ddn2, allpoints @ isi, allusers @ nalcon, allusers @ nems, tcp-ip @ sri-nic, feinler @ sri-nic CC: ntec@nalcon, avrunin@nalcon, mitre-ddn@ddn2, dca-pgs, ddn-navy Date: 10 Mar 84 15:41:30 EST Comment: On Saturday, 10 Mar 84 (today), the undersigned witnessed a successful demonstration of NARDAC/WASH's Sperry U1100/62-DCP/40 system operating over the Defense Data Network, using Sperry's X.25 interface. The NARDAC/WASH system opened and sustained an X.25 connection with a similar Sperry system at Naval Data Automation Facility (NAVDAF), Newport, RI. The NAVDAF/Newport system was cut over to DDN in December 83. As part of the demo, UTS-20 terminal sessions were set up in both directions, with Washington terminals "passing-thru" the local Washington system to access the Newport host computer, and vice versa. This is the first known use of DDN to support Sperry UTS synchronous terminal sessions, and is a significant milestone. Other DDN-compatible Sperry capabilities will be added in coming days. TCP/IP, SMTP, FTP and Telnet will be retrofitted as they become available. I would like to take this opportunity to recognize the contribution of several individuals. The list would have to be headed by Rod Richardson, the DCA/DDN-PMO Navy Systems Implementor. It is due to his tireless efforts that the DCA side of the NARDAC-DDN initiative took shape. Also crucial to this effort was MAJ(P) Bruce Sweeny and his DDN/PMO installation team. They, along with Tony Michel and his counterpart team on the BBN side, put a "crash" effort into readying the Naval Research Laboratory IMP for the NARDAC/WASH connection. Susan Poh of MITRE accompanied me to the demo today and again demonstrated her capacity for generating many valuable ideas and suggestions in a short period of time. On the Sperry side, Frank Sweet, Judy England, and Bill Ruegg were all indispensable to this effort. Finally, I would like to thank all those on the Navy side; from NAVDAF/Newport, CDR E. Perkins and Mr. Roy Kirkpatrick; from NARDAC/WASH, Messrs. Ed Grace and Dave Brack; and from Naval Data Automation Command (NAVDAC), Messrs. Bob Murray, Chuck Trigger, and Dave Vaughan, all of whom played indispensable roles with their expertise, initiative, and dedication. Sincerely, -Pat Sullivan DCA/DDN/PMO/B616 Forwarded message(s): ----------------------------------------------------- To: dca-pgs @ DDN1 From: dca-pgs @ DDN1 Subject: DDN-NARDAC/Washington Test Observers Date: 10 Mar 84 15:28:22 EST cc: dca-pgs @ DDN1 Text: NAME ORG'N PHONE David Vaughan NAVDAC 433-4671 Bill Ruegg Sperry 556-5341 Frank Sweet Sperry 556-5341 Ed Grace NARDAC/Washington 433-3052 Dave Brack NARDAC/Washington 433-4033 Pat Sullivan DCA/DDN/PMO/B616 285-5036 Susan Poh MITRE 883-7290 Area Codes: NAVDAC/NARDAC 202, all others 703. -------------END OF FORWARDED MESSAGE(S)------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984031302391700> Return-Path: Received: from mitre by SRI-NIC with TCP; Wed 14 Mar 84 04:44:22-PST Date: 13 Mar 1984 7:39:17 EST (Tuesday) From: John Swanson Subject: Distribution list To: tcp-ip@sri-nic Could you please place me on the distribution list for tcp-ip information. Thank you. John Swanson ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984031605390000> Return-Path: Received: from USC-ISIF.ARPA by SRI-NIC with TCP; Fri 16 Mar 84 13:53:12-PST Date: 16 Mar 1984 13:39:00 PST From: POSTEL@USC-ISIF.ARPA Subject: Domain Style Names - Coming Soon To: TCP-IP@SRI-NIC.ARPA Hi: An interesting and entertaining thing will happen next Wednesday. Domain Style Names will become the normal thing for all hosts in the Internet. The Host Tables maintained by the NIC will change to have ".ARPA" appended to the official name of every host in the table. This may cause a few programs to have a few problems. If you want to try things out prior to Wednesday you can test with the table in the file DHOSTS.TXT on SRI-NIC. For more information see DDN MGT Bulletin 22, and RFCs 897 & 881. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984032005140800> Return-Path: Received: from USC-ISIB.ARPA by SRI-NIC with TCP; Tue 20 Mar 84 13:16:01-PST Date: 20 Mar 1984 13:14:08 PST Subject: Re: Message-ID Low Order Bits From: Craig Milo Rogers To: Ron Natalie , tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "Ron Natalie " of Tue, 20 Mar 84 12:25:37 EST Many months ago I wrote an 1822/IP/UDP/TFTP bootstrap for PDP-11s. I was quite surprised when the bootstrap could be used between two ARPANET hosts, or between two MILNET hosts, but not between an ARPANET host and a MILNET host. The BBN gateways put a sequence number in the four low order bits of Message-id. If someone has an archive of this mailing list, perhaps you can recover the discussion. Craig Milo Rogers ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984032007253700> Return-Path: Received: from BRL-TGR by SRI-NIC with TCP; Tue 20 Mar 84 09:36:36-PST Date: Tue, 20 Mar 84 12:25:37 EST From: Ron Natalie To: tcp-ip@sri-nic Subject: Message-ID Low Order Bits In working on the IMP interfaces for the BRL gateway, I was considering setting a non-zero value in the low order bits of the Message-ID field in the IMP leader. I want to do this to identify the control messages with the original messages as suggested by BBN Report 1822 which states: For each regular message, the Host also specifies a 12-bit identifier, the message-ID (Until mid-1973 the first eight bits of the message-id field were called the "link"). The message-id, together with the destination of the message, is used as the name of the message. The IMP will use this name to inform the Host of the disposition of the message. Therefore, if the host refrains from reusing a particular message-id value (to a given destination) until the IMP has responded about that message-id, messages will remain uniquely identified... Looking at the few versions of IP that we have here, I see that these bits are totally ignored by the receiving proccess. However, I am concerned that some ambitious hosts will not recognize IP packets with the lower bits set as IP packets. The justification for rejecting these comes from the assigned numbers document (RFC790): The name link now refers to the high order 8 bits of this 12 bit message-id field. The low order 4 bits of hte message-id field are to be zero unless specifically specified otherwise for the particular protocol used on that link. This indicates that since IP doesn't mention these bits at all, I'm not supposed to fool with them. Anyone have any reasons why I shouldn't? Perhaps an official statement "specifically specifying" that these bits are unspecified and may be set to any value by the transmitting host. Yes, I know I can kludge around this using the knowledge that messages are always kept in sequence to a destination provided the handling type is the same (I assume this also applies to the acknowledgement-RFNM and errors). -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984032106405300> Return-Path: Received: from BRL-TGR by SRI-NIC with TCP; Wed 21 Mar 84 08:55:26-PST Date: Wed, 21 Mar 84 11:40:53 EST From: Ron Natalie To: TCP-IP@Sri-Nic.ARPA, nic@Sri-Nic.ARPA Subject: Hosttable changes. Did I miss something like a previous announcement that the changes were going to be made? 5 days advance notice when two of them are on the weekend seems a little shabby to me. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984032108353400> Mail-From: STAHL created at 21-Mar-84 16:35:34 Date: Wed 21 Mar 84 16:35:34-PST From: HOSTMASTER@SRI-NIC Subject: New NIC host tables Sender: STAHL@SRI-NIC To: Host-table-distribution: ; cc: nic@SRI-NIC, hostmaster@SRI-NIC, tcp-ip@SRI-NIC Reply-To: HOSTMASTER@SRI-NIC Beginning on 21 March 84 the NIC will be providing two separate versions of the Official DoD Internet Host Table. Both versions will be available via the NIC Name Server. The newly added keyword is ALL-OLD which will get you the host table without the ".ARPA" domain names. The old format host table will still be available from the NIC until 1 May 1984 at least, and possibly longer. Hosts which are still FTPing the table will find the new "domain" style table in the file HOSTS.TXT and its corresponding binary form in HOSTS3.BIN. The old table without the ".ARPA" domain names is OHOSTS.TXT with its corresponding binary form available as OHOSTS3.BIN. The format of the file INTERNET.GATEWAYS remains unchanged. Any questions should be sent to (HOSTMASTER@SRI-NIC). - Mary Stahl / NIC ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984032611021200> Mail-From: ROODE created at 26-Mar-84 19:02:12 Date: Mon 26 Mar 84 19:02:12-PST From: David Roode Subject: DOMAINS.TXT creation To: TCP-IP@SRI-NIC cc: NIC-STAFF@SRI-NIC, Postel@USC-ISIF, HOSTMASTER@SRI-NIC Location: EJ286 Phone: (415) 859-2774 Since we are only a week and a half away from the maintenance of the top-level domain table, and two months more from the possibility of introducing new top level domains, I would like to ask if anyone is considering name servers for the top-level "domains" currently in use with certain sites' TOPS-20 mail software. A lot of official business is being conducted via these mail relays, but nothing has been heard of regarding plans for host name servers. Some "domains" in use are: DOMAIN Berknet,%Berkeley.ARPA,Berkeley DOMAIN CCnet-Columbia,%COLUMBIA-20.ARPA,COLUMBIA-20,CMU-CS-C DOMAIN CCnet-CMU,%CMU-CS-C.ARPA,CMU-CS-C,COLUMBIA-20 DOMAIN CSNet,.CSNET-RELAY.ARPA,CSNET-RELAY,RAND-RELAY DOMAIN CSNet-RAND,.RAND-RELAY.ARPA,RAND-RELAY,CSNET-RELAY DOMAIN Mailnet,%MIT-MULTICS.ARPA,MIT-MULTICS DOMAIN MIT-Chaos,%MIT-MC.ARPA,MIT-MC,MIT-XX,MIT-ML DOMAIN NYU,.NYU.ARPA,NYU DOMAIN SU-Pup,%SU-SCORE.ARPA,SU-SCORE,SUMEX-AIM DOMAIN TLnet,%CMU-CS-C.ARPA,CMU-CS-C Another candidate is: DOMAIN BITNET ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984032621310000> Return-Path: Received: from CMU-CS-A by SRI-NIC with TCP; Tue 27 Mar 84 00:10:15-PST Date: 27 Mar 84 0231 EST From: Rudy.Nedved@CMU-CS-A To: David Roode Subject: Re: DOMAINS.TXT creation CC: TCP-IP@SRI-NIC, NIC-STAFF@SRI-NIC, Postel@USC-ISIF, HOSTMASTER@SRI-NIC In-Reply-To: "David Roode's message of 26 Mar 84 22:02-EST" Message-Id: <27Mar84.023104.EN0C@CMU-CS-A> David, In reference to CCnet-CMU and TLNet "domains": I expect TLNet to go away since a better connection will soon exist between Tartan Labs and the ARPANET which will be a full IP link over a 9600 baud behind CMU-Gateway. The Tartan Lab's machines will therefore look like any Internet class C host set. The CCnet-CMU and CCnet-Columbia networks which are basically the same but differ in which relay allows what hosts to send mail to what node is going to shrink we hope and become more apart of CMU's Class B network. We expect CMU-CS-C to stop being a CCNet node shortly and another node on CCNet to take up the relay load. We also expect this process to continue and shrink the size of CCNet considerably in the near future. Therefore I don't think TLNet or CCNet should exist as domains in anybody's "new" software tables. [The CCNet hosts will probably be contained in either Columbia's sub-domain name server and/or CMU's sub-domain name server.] I do however expect CMU to have its own sub-domain as our internal name space continues up its exponential curve. We have network capable PCs and dedicated network oriented computers popping up like weeds.... Rudy Nedved Facilities Staff member CMU Computer Science/Robotics Institute ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984032706042200> Return-Path: Received: from BBNG.ARPA by SRI-NIC with TCP; Tue 27 Mar 84 08:05:08-PST Date: Tue 27 Mar 84 11:04:22-EST From: Dan Tappan Subject: Name server implimentations To: tcp-ip@SRI-NIC.ARPA Is there a later version of the domain name server spec than RFC883? I get nervous trying to impliment something, which according to the schedule is supposed to be operational within a few weeks, based on a spec with things like this in it +-----------------------------------------------+ | | | ***** WARNING ***** | | | | The following format is preliminary and is | | included for purposes of explanation only. In | | particular, the size and position of the | | OPCODE, RCODE fields and the number and | | meaning of the single bit fields are subject | | to change. | | | +-----------------------------------------------+ Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984032802100000> Mail-From: HSS created at 28-Mar-84 11:37:24 Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC with TCP; Wed 28 Mar 84 10:26:44-PST Date: 28 Mar 1984 1010 PST From: Scott McCord Subject: Has it been done? To: tcp-ip-request@sri-nic Reply-To: SMJPM@JPL-VLSI ReSent-date: Wed 28 Mar 84 11:37:24-PST ReSent-from: Harry Sameshima ReSent-to: tcp-ip@SRI-NIC Is anyone implemented tcp/ip on a host that supports 32 telnet connections simultaneously? Maybe 25?,10?,5?....and how is performance with that many users? Any info would be helpful Scott McCord ------ ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984032909060000> Return-Path: Received: from yale by SRI-NIC with TCP; Thu 29 Mar 84 11:17:33-PST Received: by YALE-BULLDOG via CHAOS; Thu, 29 Mar 84 14:13:50 EST Received: from YALE-RING by YALE-RES via CHAOS; Thu, 29 Mar 84 14:05:56 EST Subject: Gateways Date: Thu, 29 Mar 84 14:06:00 EST From: Nathaniel Mishkin To: TCP-IP@SRI-NIC.ARPA Sorry if this is rehashing some old topic, or if I'm terrible confused, but... At Yale, we have a local IP network YALE-NET (128.36). On this network we presently have some Apollos (YALE-RING), a Unix 4.1 + BBN-TCP/IP VAX (YALE) and a Unix 4.2 VAX (YALE-PENGUIN). YALE is also on ARPANET and runs Chris Kent's pseudo-gateway code. There are a number of non-ARPANET (i.e. non-network 10) sites that are reachable from from YALE, but not from YALE-RING. YALE-RING can in fact communicate with lots of ARPANET and non-ARPANET sites. It seems that the problems arise with 4.2 sites (although there could be others). From my cursory examination of the 4.2 documentation, it appears that unlike the BBN TCP/IP network support, the 4.2 support requires that sites lists all the reachable remote networks and the gateways thereto in the gateway file. That is, I didn't see a mechanism for listing full routing ("prime"?) gateways. As a result, I have developed the intuition that there are a number of 4.2 machines out there that simply list ARPANET in their gateway file and hence do not know how to reach random local networks like mine. Can someone tell me what's actually going on? Please respond to me directly since I am not on this list. Thanks. -- Nat ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984032916403100> Return-Path: Received: from BRL-TGR by SRI-NIC with TCP; Thu 29 Mar 84 18:51:51-PST Date: Thu, 29 Mar 84 21:40:31 EST From: Mike Muuss To: Nathaniel Mishkin cc: TCP-IP@sri-nic.arpa Subject: Re: Gateways 4.2 has the notion of a "default route", to be used when no other routes are explicitly indicated. To establish a default route, add this command to /etc/rc.local : /etc/route add 0 gateway-to-use 3 the "0" is for the "default route", and the "3" is a hop metric, which can be any number > 1. Best, -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984033005553600> Return-Path: Received: from yale by SRI-NIC with TCP; Fri 30 Mar 84 08:01:01-PST Received: by YALE-BULLDOG via CHAOS; Fri, 30 Mar 84 10:58:03 EST Received: from YALE-RING by YALE-RES via CHAOS; Fri, 30 Mar 84 10:55:34 EST Subject: Re: Gateways Date: Fri, 30 Mar 84 10:55:36 EST From: Nathaniel Mishkin To: Mike Muuss cc: TCP-IP@SRI-NIC.ARPA In-Reply-To: Mike Muuss , Thu, 29 Mar 84 21:40:31 EST 4.2 has the notion of a "default route", to be used when no other routes are explicitly indicated. Thanks very much. I tried this on our 4.2 system and it had the desired affect. The only reference I could find to this feature was a slightly obscure one in INTRO(4N), and not in ROUTE(8C) or ROUTED(8C) where I would have expected to find it. Does anyone know how many other 4.2 sites do not know about it? -- Nat ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984033008184100> Return-Path: Received: from USC-ISIF.ARPA by SRI-NIC.ARPA with TCP; Fri 30 Mar 84 16:22:47-PST Date: 30 Mar 1984 16:18:41 PST From: POSTEL@USC-ISIF.ARPA Subject: Re: DOMAINS.TXT creation To: ROODE@SRI-NIC.ARPA, TCP-IP@SRI-NIC.ARPA cc: NIC-STAFF@SRI-NIC.ARPA, HOSTMASTER@SRI-NIC.ARPA, cc: POSTEL@USC-ISIF.ARPA In response to the message sent Mon 26 Mar 84 19:02:12-PST from ROODE@SRI-NIC David Roode: the "domains" you list are simply Mark Crispins private hacks in his TOPS20 code. They are not registered DOMAINs. The only DOMAIN currently authorized is "ARPA". --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984033008361300> Return-Path: Received: from USC-ISIF.ARPA by SRI-NIC.ARPA with TCP; Fri 30 Mar 84 16:38:52-PST Date: 30 Mar 1984 16:36:13 PST From: POSTEL@USC-ISIF.ARPA Subject: Re: Name server implimentations To: Tappan@BBNG.ARPA, tcp-ip@SRI-NIC.ARPA cc: POSTEL@USC-ISIF.ARPA In response to the message sent Tue 27 Mar 84 11:04:22-EST from Tappan@BBNG.ARPA Dan: Please contact the author of the RFC to get up to date on the current info. That is Paul Mockapetris = MOCKAPETRIS@ISIF. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984033009352400> Return-Path: Received: from ut-sally.ARPA by SRI-NIC.ARPA with TCP; Fri 30 Mar 84 15:10:15-PST Date: Fri, 30 Mar 84 15:35:24 cst From: jsq@ut-sally.ARPA (John Quarterman) Posted-Date: Fri, 30 Mar 84 15:35:24 cst Message-Id: <8403302135.AA11144@ut-sally.ARPA> Received: by ut-sally.ARPA (4.22/4.22) id AA11144; Fri, 30 Mar 84 15:35:24 cst To: Mishkin@YALE.ARPA Subject: Re: Gateways Cc: Mike Muuss , TCP-IP@SRI-NIC.ARPA I believe the "default route" feature is also mentioned in "Installing and Operating". ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984033010400000> Return-Path: Received: from CISL-SERVICE-MULTICS.ARPA by SRI-NIC.ARPA with TCP; Fri 30 Mar 84 12:49:35-PST Date: Fri, 30 Mar 84 15:40 EST From: "Benson I. Margulies" Subject: many telnet connection To: tcp-ip@SRI-NIC.ARPA Message-ID: <840330204029.000857@CISL-SERVICE-MULTICS.ARPA> Multics supports arbitrary numbers of TCP connections. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984033012481200> Mail-From: ROODE created at 30-Mar-84 20:48:12 Date: Fri 30 Mar 84 20:48:12-PST From: David Roode Subject: Re: DOMAINS.TXT creation To: POSTEL@USC-ISIF.ARPA, TCP-IP@SRI-NIC.ARPA cc: NIC-STAFF@SRI-NIC.ARPA, HOSTMASTER@SRI-NIC.ARPA Location: EJ286 Phone: (415) 859-2774 I thought operation of a Nameserver was a prerequisite to registration as a Domain. This was the light in which I phrased the Nameserver-in-planning inquiry. RFC897 seems to state that Domains other than "ARPA" and "DDN" are going to be allowed as of 6 June 1984. A month earlier domain "DDN" is scheduled for creation and use according to RFC897, so software which expects all hostnames to end in ".ARPA" (not interpreting this as a Domain) needs to be fixed before then. I didn't mean to imply that Domains should be created willy-nilly, but that certain existing administrative entities would seem to lend themselves to identification as a Domain. The question was meant to be "are any of you working on it?" ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984033020303400> Return-Path: Received: from SU-SCORE.ARPA by SRI-NIC.ARPA with TCP; Sat 31 Mar 84 04:32:06-PST Date: Sat 31 Mar 84 04:30:34-PST From: Mark Crispin Subject: Re: DOMAINS.TXT creation To: POSTEL@USC-ISIF.ARPA cc: ROODE@SRI-NIC.ARPA, TCP-IP@SRI-NIC.ARPA, NIC-STAFF@SRI-NIC.ARPA, HOSTMASTER@SRI-NIC.ARPA In-Reply-To: Message from "POSTEL@USC-ISIF.ARPA" of Fri 30 Mar 84 16:18:41-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I find myself agreeing with Jon, although I perhaps wouldn't put it quite the way he did. The TOPS-20 mailsystem's DOMAINS.TXT functionality is merely a workaround to fufill a need not presently supplied by current protocols or standards. I would hate to see it propagate elsewhere, at least without a careful examination of the various issues involved. The principle issue is that DOMAINS.TXT simulates domain-type functionality with store-and-forward type of mailing. Internet would prefer that store-and-forward mailing didn't exist; while there are features in SMTP and RFC 822 for it these features are made useless due to the requirement that all host addresses must be valid Internet addresses. Another problem is that DOMAINS.TXT (along with the rest of the TOPS-20 mailsystem) assumes a heuristic approach to the support of domains. I believe now that this is not the correct approach to take. Heuristics have this way of being different between different implementations at different sites, or even between different software at the same site. I now believe that a modified "host table" approach is preferable, where instead of consulting a host table the software on each site consults its local cache; failing that it goes to a name server. In both cases the entire domain string is treated as a single atom by the host. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984033106122600> Return-Path: Received: from USC-ISIF by SRI-NIC.ARPA with TCP; Sat 31 Mar 84 14:14:20-PST Date: 31 Mar 1984 14:12:26 PST From: POSTEL@USC-ISIF Subject: Re: DOMAINS.TXT creation To: MRC@SU-SCORE cc: ROODE@SRI-NIC, TCP-IP@SRI-NIC, NIC-STAFF@SRI-NIC, cc: HOSTMASTER@SRI-NIC, POSTEL@USC-ISIF In response to your message sent Sat 31 Mar 84 04:30:34-PST Folks: Mark Crispin has done and is doing a great job of providing programs to support applications in the Internet environment on TOPS20. Mark's User-Telnet "TN" is widely used as is his suite of mail programs. Mark found himself supporting mail (and other) communications on TOPS20 in a fairly complex environment with several local networks and different protocol families. The Internet protocols did not at the time give any guidance on how to handle the situation. Mark invented a way to make things work. The ideas about domains were just coming into being at that time and Mark used the term to identify some of the entities in his scheme. Somehow the general development of the domains idea for the Internet as a whole did not correspond exactly to what Mark did. The Internet purposes, rules, and criteria for creating a domain turn out to be somewhat different that those Mark used. So the things that are "domains" in the mail programs in TOPS20s running Mark's programs might not be appropriate domains in the Internet. --jon. ------- ----MESSAGE-END----