Re: Blast from the past
Here's some information about HOSTS.TXT from Jake Feinler, formerly of SRI-NIC. Alex. The SRI NIC registered hosts and maintained the official list of host names from 1970 up until the SRI NIC ceased to exist in Oct. 1992. At that time naming and addressing activities were turned over to NSI and SRI was no longer involved. However, I am not sure what the IETF discussion is referring to. HOSTS.TXT was originally an official file that hosts needed to load onto their machines to identify hostnames in headers. The file became too big for many machines, and there was network congestion due to everyone trying to download the file from the SRI machine. Consequently, some hosts started maintaining only a small subset of host names for sites with which they frequently communicated. Obviously that was a bad solution to the problem. Then the NIC provided a server that allowed one to refresh one's host tables automatically and/or query the server on the fly for a given hostname. This service was replicated at ISI and BBN (maybe other sites - I can't remember), and these additional servers refreshed their host tables from the NIC. Finally the network went to the domain naming system; however, SRI-NIC still continued to provide the official naming registration and distribution service for the Internet until we went offline. I left SRI in Sept. 1989. The NIC contract lasted until Oct. 1992. Dr. Jose Garcia-Luna, now at UC Santa Cruz, was leading the group until the contract ended. Mary Stahl and Sue Romano headed up the Name Service, so these people could give the definitive answer to the question asked.
RE: Blast from the past
At 01:59 PM 1/27/2001 -0500, John C Klensin wrote: "spooling" or "mail store" mail-receiving processes came later -- in the Multics case, not much later, as it became clear that direct-to-user-space delivery raised some security issues that no one was happy about-- but well before SMTP. Hmmm. It occurs to me that what you have highlighted is another Internet demonstration that scaling imposes more stringent demands. However this was perhaps one of the earliest examples of social effects -- larger communities have less average trustworthiness? -- than technical ones. d/
Re: Blast from the past
Jeff Weisberg wrote: quoth [EMAIL PROTECTED]: | I'm curious when HOSTS.TXT finally died completely. My memory isn't what it used to be, but at rochester.edu, I'm thinking it had to be in use until at least 89 or 90. It was in use on the math department Sun workstations when I was at University of Chicago in 1990-91. I think it was also on the campus-wide machines, too; at least, I remember having access to two different versions of the file, one much larger than the other (but not actually a superset). -- /==\ |John Stracke| http://www.ecal.com |My opinions are my own.| |Chief Scientist |=| |eCal Corp. |What if there were no hypothetical questions?| |[EMAIL PROTECTED]| | \==/
Re: Blast from the past
quoth [EMAIL PROTECTED]: | | [EMAIL PROTECTED] (Dan McDonald) writes: | | Speaking of that, does anyone know where one could find a copy (final, | historical, or otherwise) of HOSTS.TXT? I barely remember huge /etc/hosts | files, and it would be historically interesting to peruse, I think. a quick bit of altavistaing tuned up: http://www.mit.edu/afs/athena.mit.edu/reference/net-directory/host-tables/hosts.txt ; DoD Internet Host Table ; 30-Aug-90 ; Version number 983 | I'm curious when HOSTS.TXT finally died completely. | | I had a machine at Bellcore that I used for hosting a couple of | mailing lists, and I (well, it -- I automated the process) was still | periodically downloading HOSTS.TXT off of SRI-NIC.ARPA (I think) as | late as '88 or maybe even early '89 if I'm not totally My memory isn't what it used to be, but at rochester.edu, I'm thinking it had to be in use until at least 89 or 90. --jeff
RE: Blast from the past
At 03:14 PM 1/26/2001 -0500, John C Klensin wrote: With FTP, the mail was delivered more or less into the space of the receiving user. So any conversations that were done (and I can't remember much, if anything) would have needed to be done in what we would now call the receiving MUA -- there really was no _mail_ transport process. architecturally, the MAIL commands within FTP were identical to SMTP. They were an email transport protocol. Both delivermail/Sendmail and MMDF were alive an kicking before RFC821. The introduction of SMTP did not alter the roles or basic system processing of either of these applications. It just added one more transport protocol to their set. That is, however we would characterize their behaviors now, such as distinguishing activities within the MUA versus elsewhere -- it was the same before SMTP. There were other email processes that worked the same way, but the only one I know any details about was the MMDF predecessor that we did at Rand in 1978. My impression is that the Multics NCP email software had a similar architecture. d/ =-=-=-=-= Dave Crocker [EMAIL PROTECTED] Brandenburg Consulting www.brandenburg.com Tel: +1.408.246.8253, Fax: +1.408.273.6464
RE: Blast from the past
My apologies -- I should have been more precise about chronology. When we _first_ did mail-over-FTP, the norm was to deliver more or less directly into the user's file system. The notion of "spooling" or "mail store" mail-receiving processes came later -- in the Multics case, not much later, as it became clear that direct-to-user-space delivery raised some security issues that no one was happy about-- but well before SMTP. So Dave, and his chronology, are quite correct. john --On Saturday, 27 January, 2001 06:26 -0600 Dave Crocker [EMAIL PROTECTED] wrote: At 03:14 PM 1/26/2001 -0500, John C Klensin wrote: With FTP, the mail was delivered more or less into the space of the receiving user. So any conversations that were done (and I can't remember much, if anything) would have needed to be done in what we would now call the receiving MUA -- there really was no _mail_ transport process. architecturally, the MAIL commands within FTP were identical to SMTP. They were an email transport protocol. Both delivermail/Sendmail and MMDF were alive an kicking before RFC821. The introduction of SMTP did not alter the roles or basic system processing of either of these applications. It just added one more transport protocol to their set. That is, however we would characterize their behaviors now, such as distinguishing activities within the MUA versus elsewhere -- it was the same before SMTP. There were other email processes that worked the same way, but the only one I know any details about was the MMDF predecessor that we did at Rand in 1978. My impression is that the Multics NCP email software had a similar architecture.
RE: Blast from the past
In the 1980s we ran an X.400 to SMTP-RFC822 mail gateway at Wisconsin. This was during the height of the Internet / OSI protocol wars. Earlier, we also ran a BITNET to Internet mail gateway. Both used software developed at Wisconsin (an IBM VM internet protocol implementation (WISCNET) for VM for the latter and a BSD Unix implementation of the ISO/OSI protocols for the latter). Address format, protocol tranlations and option handling were a challenge.
RE: Blast from the past
Can people *please* trim the CC list on this thread - and in particular, make sure to remove "Info-Explorer"? I'm so tired of getting three copies of everything... Noel
Re: Blast from the past
At 10:30 PM -0500 1/24/01, J. Noel Chiappa wrote: PS: Those of you with sharp eyes will notice that everything has a class A address! ...and that some of those addresses still work, and appear to be used by folks directly related to the original owners. If only URLs could be so persistent... --Paul Hoffman, Director --Internet Mail Consortium
Re: Blast from the past
Paul Hoffman / IMC wrote: At 10:30 PM -0500 1/24/01, J. Noel Chiappa wrote: PS: Those of you with sharp eyes will notice that everything has a class A address! ...and that some of those addresses still work, and appear to be used by folks directly related to the original owners. If only URLs could be so persistent... However, I have to observe that this strange thing called ARPANET appears to be using private addresses :-) Brian
Re: Blast from the past
On Thu, 25 Jan 2001 16:20:54 CST, Brian E Carpenter said: However, I have to observe that this strange thing called ARPANET appears to be using private addresses :-) So damned private some people started CSNet and Bitnet because they couldnt' get Arpanet addresses ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Re: Blast from the past
* * However, I have to observe that this strange thing called ARPANET * appears to be using private addresses :-) * * And I assume there were ALGs to translate between NCP and TCP hosts... * * Nope. Dual stacks. Bob Braden *--Steve Bellovin, http://www.research.att.com/~smb * * *
Re: Blast from the past
However, I have to observe that this strange thing called ARPANET appears to be using private addresses :-) I think it was Danny Cohen who said that in the US the private networks are public and the public networks are private. Bob
RE: Blast from the past
Title: RE: Blast from the past Ah, dual stacks, a time tested transition strategy. But there was some Application Layer Gateway cruft (ALG) although not at the level of sophistication and beauty of a NAT ... From RFC 801: Because all hosts can not be converted to TCP simultaneously, and some will implement only IP/TCP, it will be necessary to provide temporarily for communication between NCP-only hosts and TCP-only hosts. To do this certain hosts which implement both NCP and IP/TCP will be designated as relay hosts. These relay hosts will support Telnet, FTP, and Mail services on both NCP and TCP. These relay services will be provided beginning in November 1981, and will be fully in place in January 1982. Initially there will be many NCP-only hosts and a few TCP-only hosts, and the load on the relay hosts will be relatively light. As time goes by, and the conversion progresses, there will be more TCP capable hosts, and fewer NCP-only hosts, plus new TCP-only hosts. But, presumably most hosts that are now NCP-only will implement IP/TCP in addition to their NCP and become dual protocol hosts. So, while the load on the relay hosts will rise, it will not be a substantial portion of the total traffic.
Re: Blast from the past
Kind of like public schools in England which are private ;-) I think NATs should be loaded with the final copy of HOSTS.TXT and assign names on the net 10 side accordingly... Ole Ole J. Jacobsen Editor and Publisher The Internet Protocol Journal Office of the CTO, Cisco Systems Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj On Thu, 25 Jan 2001, Bob Hinden wrote: However, I have to observe that this strange thing called ARPANET appears to be using private addresses :-) I think it was Danny Cohen who said that in the US the private networks are public and the public networks are private. Bob
RE: Blast from the past
we never actually did this though vint At 05:52 PM 1/25/2001 -0800, Peter Ford wrote: Ah, dual stacks, a time tested transition strategy. But there was some Application Layer Gateway cruft (ALG) although not at the level of sophistication and beauty of a NAT ... From RFC 801: Because all hosts can not be converted to TCP simultaneously, and some will implement only IP/TCP, it will be necessary to provide temporarily for communication between NCP-only hosts and TCP-only hosts. To do this certain hosts which implement both NCP and IP/TCP will be designated as relay hosts. These relay hosts will support Telnet, FTP, and Mail services on both NCP and TCP. These relay services will be provided beginning in November 1981, and will be fully in place in January 1982. Initially there will be many NCP-only hosts and a few TCP-only hosts, and the load on the relay hosts will be relatively light. As time goes by, and the conversion progresses, there will be more TCP capable hosts, and fewer NCP-only hosts, plus new TCP-only hosts. But, presumably most hosts that are now NCP-only will implement IP/TCP in addition to their NCP and become "dual protocol" hosts. So, while the load on the relay hosts will rise, it will not be a substantial portion of the total traffic.
