The Internet is a worldwide collection of thousands of computer networks that can intercommunicate. All of them speak the same Òlanguage,Ó namely the TCP/IP protocol suite. Users of any of the Internet networks can reach users on any of the other networks. The Internet started with the ARPANET, but now includes such networks as NSFNET, NEARNet, and others. Many other networks, such as BITNET, are tied to the Internet but are not an integral part of it. Approximately one million people use the Internet daily. About the Internet The Internet is a worldwide collection of thousands of computer networks that can intercommunicate. All of them speak the same Òlanguage,Ó namely the TCP/IP protocol suite. Users of any of the Internet networks can reach users on any of the other networks. The Internet started with the ARPANET, but now includes such networks as NSFNET, NEARNet, and others. Many other networks, such as BITNET and SPAN, are tied to the Internet, but are not an integral part of it. Approximately one million people use the Internet daily. The ancestry of the Internet is rooted in the ARPANET, a network developed by the Advanced Research Projects Agency (ARPA, see DARPA) to aid in the sharing of information and resources among researchers. The ARPANET, which was made operational in 1969, became an essential tool for remote login, file transfer, electronic mail and the sharing of information by interest groups. History of the Internet The ancestry of the Internet is rooted in the ARPANET, a network developed by the Advanced Research Projects Agency (ARPA, see DARPA) to aid in the sharing of information and resources among researchers. The ARPANET, which was made operational in 1969, became an essential tool for remote login, file transfer, electronic mail and the sharing of information by interest groups. Development of TCP/IP The ARPANET was growing in size while other networks were being developed. Soon the architects of the ARPANET recognized the need to communicate with other networks. They also realized that they needed new protocols (the NCP protocol suite that they had developed wasnÕt able to cope with the diverse characteristics of other networks). Therefore they designed a new architecture and protocol suite called the ARPA Internet; the protocol suite was called TCP/IP. Start of the Internet The Internet first became operational in 1983, when the ARPANET was split into two separate networks, MILNET and ARPANET, which together formed the Internet. Each was given a network number, and gateways were installed to provide packet forwarding between them. TCP/IP in the Internet When the ARPANET was split to form the Internet, the Defense Communications Agency (DCA) mandated the use of TCP/IP for all ARPANET hosts, and enforced this by modifying the packet switching software. As a result, all ARPANET hosts had to begin using TCP/IP protocols and interacting with the Internet environment. This meant that more networks and gateways could be added to the Internet without any effect on the existing network. Growth of the Internet Since its creation in 1983, the Internet has grown exponentially in terms of numbers of networks connected to it. By 1985, the number was approxiately one hundred. By 1987, the number had grown to two hundred; in 1989, it exceeded five hundred. According to tables kept at the DDN Network Information Center (DDN NIC), there were 2,218 networks connected to the Internet as of January 1990. As the Internet has grown, its underpinnings have changed. ARPANET and MILNET continued to grow, and other backbone networks were added to the Internet. One of these was CSNET, established in 1981 to provide for collaboration between computer and engineering researchers. CSNET provided Internet access from sites not served by ARPANET and MILNET. Today, CSNET has expanded to include institutions involved in science and engineering, and is one of several midlevel networks that make up NSFNET. Internet Backbone Networks NSFNET NSFNET began providing backbone Internet service in July 1986 to permit supercomputer centers (see Computing Centers) to communicate. NSFNET's scope has since expanded, and today it is the U.S. national research network. It has extended to the academic and commercial communities the TCP/IP services that were previously available to government researchers. NSFNET links midlevel networks, which in turn connect networks at universities and commercial enterprises. Therefore, NSFNET, like the Internet of which it forms a large part, is itself a network of networks. Decommissioning the ARPANET As NSFNET has grown to handle much of the interconnection load of the Internet, other networks have outgrown their usefulness and been eliminated. A milestone in this area was the decommissioning of the ARPANET in June 1990. The Defense Communications Agency shut down the ARPANET because its functions had been subsumed by the midlevel networks and NSFNET. Perhaps the greatest testimony to the architecture of the Internet is that when ARPANET, the network from which the Internet grew, was turned off, no one but network staff was aware of it. Poems about the Internet The Big Bang, or by Leonard The Birth of the ARPANET Kleinrock Requiem for the ARPANET by Vint Cerf Rosencrantz and Ethernet by Vint Cerf Untitled by Barry Boehm The Big Bang (or The Birth of the ARPANET) by Leonard Kleinrock It was back in '67 that the clan agreed to meet. The gangsters and the planners were a breed damned hard to beat. The goal we set was honest and the need was clear to all: Connect those big old mainframes and the minis, lest they fall. The spec was set quite rigid: it must work without a hitch. It should stand a single failure with an unattended switch. Files at hefty throughput 'cross the ARPANET must zip. Send the interactive traffic on a quarter-second trip. The spec went out to bidders and t'was BBN that won. They worked on soft and hardware and they all got paid for fun. We decided that the first node would be we who are your hosts And so today you're gathered here while UCLA boasts. I suspect you might be asking "What means first node on the net?" Well frankly, it meant trouble, 'specially since no specs were set. For you see the interface between the nascent IMP and host Was a confidential secret from us folks on the West Coast. BBN had promised that the IMP was running late. We welcomed any slippage in the deadly scheduled date. But one day after Labor Day, it was plopped down at our gate! Those dirty rotten scoundrels sent the damned thing out air freight! As I recall that Tuesday, it makes me want to cry. Everybody's brother came to blame the other guy! Folks were there from ARPA, GTE, and Honeywell. UCLA and ATT and all were scared as hell. We cautiously connected and the bits began to flow. The pieces really functionedÑjust why I still don't know. Messages were moving pretty well by Wednesday morn. All the rest is historyÑpacket switching had been born! Rosencrantz and Ethernet by Vint Cerf All the world's a net! And all the data in it merely packets Come to store-and-forward in the queues a while and then are Heard no more. 'Tis a network waiting to be switched! To switch or not to switch? That is the question. Whether 'Tis wiser in the net to suffer the store and forward of Stochastic networks or to raise up circuits against a sea Of packets and, by dedication, serve them. To net, to switch. To switch, perchance to slip! Aye, there's the rub. For in that choice of switch, What loops may lurk, when we have shuffled through This Banyan net? Puzzles the will, initiates symposia, Stirs endless debate and gives rise to uncontrolled Flights of poetry beyond recompense! Untitled by Barry Boehm (stanzas 1 and 2) Paul Baran came out of the wood With a message first misunderstood But despite dangers lurking The IMP's were soon working And ARPA did see it was good. So in place of our early myopia We now have a net cornucopia With IMPs, TIPs, and LANs Wideband VANs, MANs, and WANs And prospects of World Net Utopia. Requiem for the ARPANET by Vint Cerf Like distant islands sundered by the sea, We had no sense of one community. We lived and worked apart and rarely knew That others searched with us for knowledge, too. Distant ARPA spurred us in our quest And for our part we worked and put to test New thoughts and theories of computing art; We deemed it science not, but made a start. Each time a new machine was built and sold, We'd add it to our list of needs and told Our source of funds "Alas! Our knowledge loom Will halt 'til it's in our computer room." Even ARPA with its vast resources Could not buy us all new teams of horses Every year with which to run the race. Not even ARPA could keep up that pace! But, could these new resources not be shared? Let links be built; machines and men be paired! Let distance be no barrier! They set That goal: design and built the ARPANET! As so it was in nineteen sixty-nine, A net arose of BBN design. No circuit switches these, nor net complete But something new: a packet switching fleet. The first node occupied UCLA Where protocols and measurement would play A major role in shaping how the net Would rise to meet the challenges unmet. The second node, the NIC, was soon installed. The Network Info Center, it was called. Hosts and users, services were touted: To the NIC was network knowledge routed. Nodes three and four soon joined the other two: UCSB and UTAH come on cue. To monitor it all around the clock At BBN, they built and ran the NOC. A protocol was built for host-to-host Communication. Running coast-to-coast, Below the TELNET and the FTP, We called this protocol the NCP. The big surprise for most of us, although Some said they guessed, was another protocol Used more than all the rest to shuttle Mail in content flaming or most subtle. When we convened the first I Triple C, The ARPANET was shown for all to see. A watershed in packet switching art, this demo played an overwhelming part. Within three years the net had grown so large We had to ask that DCA take charge To operate a system guaranteed For R&D and military need. Exploring other packet switching modes, we built the first spread spectrum mobile nodes. The Packet Radio, the mobile net, worked on the ground and even in a jet. Deployed at SAC and Eighteenth Airborne Corps, The Packet Radio unlocked the door to what we now know as the Internet. The driver for it all was PRNET. The Packet Satellite, another new technique, was added to the net milieu. And then to shed more light upon the dark, there came the Ethernet from Xerox PARC. To these we added yet another thing from MIT: a local token ring. We saw the local net techniques compound until the list could easily confound. The Internet foundation thus was laid. Its protocols from many sources made. And through it all the ARPANET grew more; It was, for Internet, the central core. The hardware of the net was changing, too. The Honeywell was first, and then the SUE, which forms the heart of Pluribus today though where this platform sits one cannot say. The next big change was called the MBB. It emulated Honeywell, you see, so one by one they modified each node, by means of closely written microcode. Now known as 30 prefixed with a C, these nodes are everywhere from A to Z. The European MINET too was full of nodes like these from Mons to Istanbul. The second Autodin was long desired but once accepted instantly expired. Then to the rescue rode the ARPANET! And soon the MILNET by its side was set. By nineteen-eighty DoD opened its data networks soon must be aligned with Internetwork protocols, to wit: by eighty-three the TCP was IT! Soon every host that sat on ARPANET became a gateway to a local net. By eighty-six new long-haul nets appeared as ARPANET its second decade neared. The NSFNET and its entourage began a stately national dressage and soon was galloping at T1 speed outdistancing its aging peer indeed. And so, at last, we knew its course had run, our faithful servant, ARPANET, was done. It was the first, and being first, was best, but now we lay it down to ever rest. Now pause with me a moment, shed some tears. For auld lang syne, for love, for years and years of faithful service, duty done, I weep. Lay down thy packet, now, O friend, and sleep. (for ARPA, see DARPA; for the NIC, see DDN NIC; for TCP, see TCP/IP) Internet Networks CREN/CSNET (Computer and Science Network) DDN (Defense Data Net ) ESNet (Energy Sciences Network) NSFNET (National Science Foundation Network) NASA Science Network The Internet communicates via gateways with other networks such as CompuServe, MCI Mail, BITNET, FIDONet, UUNET, and USENET. The Internet has several component networks (which themselves include other networks): ¥ CREN/CSNET ¥ DDN (Defense Data Net ) ¥ ESNET (Energy Sciences Network) ¥ NASA Science Internet ¥ NSFNET (National Science Foundation Network) ¥ Terrestrial Wideband Network Internet Networks The Internet communicates via gateways with networks outside the Internet, such as CompuServe, MCI Mail, BITNET, FIDONet, UUNET, and USENET. Within the Internet there are several smaller networks (which themselves include other networks): ¥ CREN/CSNET (Computer and Science Network) ¥ DDN (Defense Data Net ) ¥ ESNET (Energy Sciences Network) ¥ NASA Science Network ¥ NSFNET (National Science Foundation Network) NSFNET Mid-Level Wide Area Networks BARRNET (Bay Area Regional Research Network) CERFNET (California Education & Research Federation Network) CICNET (Committee on Institutional Cooperation Network) JvNCNET (JvNCNet Northeast Research Regional Network) LOS NETTOS (Greater Los Angeles Area Network) MICHNET MIDNET (Midwestern States Network) MRNET (Minnesota Regional Network) NCSANET (National Center for Supercomputing Applications Network) NEARNET (New England Academic & Research Network) NEVADANET NORTHWESTNET (Northwestern States Network) NYSERNET (New York State Education & Research Network) OARNET (Ohio Academic Resources Network) PREPNET (Pennsylvania Research and Economic Partnership Network) PSCNET (Pittsburgh Supercomputing Center Network) PSINET SDSCNET (San Diego Supercomputer Center Network) SESQUINET (Texas Sesquicentennial Network) SURANET (Southeastern Universities Research Association Network) THENET (The Texas Higher Education Network) USAN (NCAR's University Satellite Network) VERNET (Virginia Education and Research Network) WESTNET (Southwestern States Network) CREN/CSNET CSNET: The Computer + Science Network is an international data communications network that supports research and education. Members of CSNET include universities, colleges, government agencies, non-profit organizations, and industrial research laboratories. CSNET is affiliated with twelve foreign university networks. CSNET and BITNET are merged into a single organization, CREN, the Corporation for Research and Educational Networking. Address: CREN/CSNET Coordination and Information Center BBN Systems and Technologies 10 Moulton St. Cambridge, MA 02138 USA E-mail: cic@sh.cs.net Phone: (617)873-2777 [CSNET hotline] DDN The Defense Data Network is a worldwide operational communications network serving the US Department of Defense. Defense Data Network. Address: SRI International Network Information Systems Center Room EJ291 333 Ravenswood Avenue Menlo Park, CA 94015 E-mail: nic@noc.ddn.mil Phone: 1-800-235-3155 or (415) 859-3695 ESNET The Energy Sciences Network is a computer data communications network managed and funded by the Department of Energy Office of Energy Research (DOE/OER). ESnet is intended for use by scientific collaborators throughout ER programs. ESnet is installed and operated by the National Energy Supercomputer Center (NERSC), formerly known as the National Magnetic Fusion Energy Computer Center (NMFECC), which is located at Lawrence Livermore National Laboratory (LLNL) in California. NERSC provides user services for ESnet. Address: NERSC L-561 Lawrence Livermore Labs Livermore, Ca. 94550 E-mail: info@es.net Phone: 1-800-33-ESNET Contacts: Jim Leighton, 415-422-4025, jfl@es.net, Network Manager Tony Hain, 415-422-4200, hain@eagle.es.net, Associate Network Manager Bob Aiken, 415-422-4474, aiken@es.net, Network Information and Services Group NASA Science Internet The NASA Science Internet (NSI) supports scientists and flight projects funded by NASA's Office of Space Science and Applications (OSSA). Users include NASA sites, and government facilities, research, and academic sites conducting NASA-funded research. The NSI is a NASA- wide network with hubs at several NASA centers. Address: Network Information Center NASA Science Network MS 233-18 NASA Ames Research Center Moffett Field, CA 94035 E-mail: nsnnic@nsipo.nasa.gov Phone: (415) 694-5859 or (FTS) 464-5859 TERRESTRIAL WIDEBAND NETWORK The Terrestrial Wideband Network supports research in high-speed networking, provides connectivity among academic and government sites, and supports a testbed for Internet protocol development and experimentation with applications. It supports a research environment for multimedia conferencing and voice/video conferencing using gateways which use a real-time connection-oriented protocol over a connectionless network. Address: Terrestrial Wideband Network c/o BBN Systems and Technologies 10 Moulton St. Cambridge, Massachusetts 02138 Attn: Karen Seo E-mail: wbhelp@bbn.com Phone: (617) 873-3427 (Terrestrial Wideband Network hotline) NSFNET The National Science Foundation Network is the backbone network of the U.S. National Science Foundation (NSF). It interconnects mid-level networks and other resources throughout the United States. The network may be used by researchers in general, according to NSF guidelines. Address: Merit Computer Network 1075 Beal Avenue Ann Arbor, Michigan 48109 E-mail: nsfnet-info@merit.edu Phone: 1-800-66-MERIT Contacts: For information about becoming a part of NSFNET, contact the NSF Network Service Center (NNSC) at BBN: NNSC Bolt Beranek and Newman Inc. 10 Moulton St. Cambridge, MA 02138 nnsc@nnsc.nsf.net (617) 873-3400 For information about NSFNET contact NSF, MERIT, or the NNSC (above): At NSF: Steve Wolff DNCRI Director (202) 357-9717 swolff@note.nsf.gov Jane Caviness NSFNET Deputy Divison Director (202) 357-9717 jcavines@note.nsf.gov Dan van Belleghem NSFNET operations and general questions At Merit: Eric Aupperle Project Director (313) 763-4897 eaupperle@merit.edu Hans-Werner Braun Principal Investigator (313) 763-4897 hwb@merit.edu BARRNet The Bay Area Regional Research Network is the Northern California regional hub of the NSFNET. BARRNet members include universities, government and private research laboratories, and corporate affiliates. Address: Pine Hall, Rm. 115 Stanford University Stanford, CA 94305-4122 Email: info@nic.barrnet.net Phone: (415) 725-1790 Contacts: William H. Yundt, Executive Director Pine Hall Rm. 115 Stanford University Stanford, CA 94305-4122 gd.why@forsythe.stanford.edu (415) 723-3104 Philip Almquist, Technical Comittee Chair Pine Hall, Rm. 115 Stanford University Stanford, CA 94305-4122 almquist@jessica.stanford.edu (415) 723-2229 Ron Roberts, Network Operating Center Manager Business hours: (415) 723-7360 After hours/weekends: (415) 723-1611 barrnet-noc@nic.barrnet.net CERFNET The California Education and Research Federation Network, CERFnet, is a regional network that operates throughout California. CERFnet membership includes universities, colleges, industrial and government facilities, hospitals, and libraries. Address: CERFnet c/o San Diego Supercomputer Center P. O. Box 85608 San Diego, California 92186-9784 Email: help@cerf.net Phone: (619) 534-5087 Contact: Karen Armstrong McKelvey mckelvey@sds.sdsc.edu CICNet CICNet is a regional network serving a seven-state region of the midwestern United States. It connects the members of the Big Ten and the University of Chicago, as well as corporate and nonprofit organizations. Address: CICNet, Inc. 2901 Hubbard Drive, Pod G Ann Arbor, MI 48105 E-mail: info@cic.net Phone: (313) 998-6103 JvNCnet JvNCnet, the North East Research Regional Network, connects research organizations concentrated in the Northeastern United States, with access to the NSFNET backbone and with international connections to several Scandinavian countries (Norway, Finland, Iceland, Sweden and Denmark), and the United Kingdom. Address: JvNCnet P.O. Box 3717 Princeton, N.J. 08543 E-mail: nisc@nisc.jvnc.net Phone: (609) 520-2000 [Sergio Heker] Contact: The JvNCnet Network Coordinator: nisc@nisc.jvnc.net or (609) 520-2000. Los Nettos Los Nettos is a regional network in the Los Angeles area. It may be used for any educational or research purpose. The member organizations are universities and research laboratories. The Information Sciences Institute (ISI) of the University of Southern California (USC) acts as the agent for Los Nettos. Address: Los Nettos c/o Ann Westine USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, California 90292 E-mail: los-nettos-request@isi.edu Phone: (213) 822-1511 (Ann Westine) MichNet MichNet is a statewide network operated by Merit. The network plans to reach out beyond Merit's traditional audience of four-year, publically supported colleges and universities in Michigan. E-mail: Merit_Computer_Network@um.cc.umich.edu Phone: (412)268-7870 Contact: Eric Aupperle (313) 764-9423 eaupperle@merit.edu Midnet MIDnet is a regional computer network for the seven midwestern states. The network provides researchers access to supercomputers and is a vehicle for exchanging information among researchers. Contact: Dale Finkelson Phone: (402) 472-5032 E-mail: dmf@westie.unl.edu MRNet The Minnesota Regional Network (MRNet) is an NSF regional network which provides communications between the nationwide NSFNET and researchers at the Minnesota Supercomputer Center, the University of Minnesota, and other educational institutions. MRNet also provides NSFNET access to several Minnesota organizations involved in high- technology research. Address: MRNet c/o Mahlon Stacy Mayo Foundation Medical Sciences 1-18 Rochester, MN 55905 Technical: MRNet c/o Jeff Wabik Minnesota Supercomputer Center 1200 Washington Street Minneapolis, MN 55415 E-mail: mrnet@nic.mr.net Phone: (507) 284-4558 (Mahlon Stacy) (612) 626-1888 (Jeff Wabik) NCSAnet NCSAnet is a regional supercomputing network that connects university and government research sites primarily located in Illinois, Wisconsin, and Indiana. The NCSAnet private corporate network is national in scale. Address: NCSAnet attn: Charlie Catlett National Center for Supercomputing Applications 605 E. Springfield Ave. Champaign, IL 61820 Email: network@ncsa.uiuc.edu Phone: (217) 244-8297 [NCSA Networking Office] NEARNET The New England Academic and Research Network, NEARnet, is a high-speed network of academic, industrial, government, and nonprofit organizations in New England. Address: NEARnet c/o BBN Systems and Technologies Corp. 10 Moulton St. Cambridge, MA 02138 Attn: John Rugo E-mail: nearnet-staff@bbn.com Phone: (617) 873-8730 [NEARnet hotline] NevadaNet NevadaNet is a state-wide network and currently serves the Desert Research Institute, the University of Nevada, Reno and the University of Nevada, Las Vegas. Address: NevadaNet University of Nevada System Computing Services 4505 Maryland Parkway Las Vegas, Nevada 89154 E-mail: info@nevada.edu Phone: (702) 739-3557 [Jim Williams] Contacts: NOC Manager: Van Weddle 702-739-3883 weddle@uns-helios.nevada.edu NIC Manager: Becky Seibert 702-784-4343 seibert@unssun.nevada.edu NorthWestNet NorthWestNet (NWNet) is a mid-level network of the National Science Foundation Network (NSFNET). NWNet provides communication with NSFNET for research centers throughout the Northwest, including sites in Alaska, Idaho, Montana, North Dakota, Oregon, and Washington. Address: Administrative: Richard Markwood Western Interstate Commission on Higher Education (WICHE) P.O. Drawer P Boulder, CO 80301-9752 Technical: Dan Jordt University Networks and Distributed Computing UW, HG-45 3737 Brooklyn Ave. NE Seattle, WA 98105 E-mail: Administrative: markwood@vaxf.colorado.edu Technical: danj@cac.washington.edu Phone: Administrative: (303) 497-0220 Technical: (206) 543-7352 Contact: The 24x7 NOC hotline number is (206) 543-5128, or noc@nwnet.net. NYSERNet NYSERNet is a midlevel network incorporating corporate, academic, and government institutions. Address: NYSERNet Inc. 165 Jordan Rd Troy, NY 12180 E-mail: info@nisc.nyser.net Phone: (518) 283-8860 OARnet The Ohio Academic Resources Network is the regional network for the state of Ohio. It serves the entire higher education community. E-mail: alison@maverick.osc.edu Phone: (614) 292-9248 Contact: Alison Brown PSCNet PSCNET is an NSF-sponsored regional research and education network. E-mail: hastings@morgul.psc.edu Phone: (412) 268-4960 Contact: Eugene Hastings PREPnet Pennsylvania Research and Economic Partnership Network, PREPnet, is a mid-level network serves Pennsylvania. Organizations operating within Pennsylvania involved in education, research, technology transfer, or the economic development of Pennsylvania participate. Address: PREPnet 530 N. Neville Street Pittsburgh, PA 15213 E-mail: prepnet+@andrew.cmu.edu Phone: (412)268-7870 Contacts: Executive Director: Thomas W. Bajzek, twb+@andrew.cmu.edu NIC Manager: Marsha L. Perrott, mlp+@andrew.cmu.edu PSINet PSINet is a US-based internetwork available throughout the continental US and in Canada, Germany, and Israel. The PSINet operations center is located in Albany NY (another office is located in Santa Clara, California). PSINet provides internetworking services to the NYSERNet user community. Address: Performance Systems International 11800 Sunrise Valley Drive - Suite 1100 Reston, VA 22091 E-mail: info@psi.com Phone: (+1-703) 620-6651 1-800-82psi82 SDSCnet SDSCnet is a network linking academic, industrial, and government affiliates with the San Diego Supercomputer Center (SDSC), which administers the network, and, by extension, NSFNET. Address: Paul Love San Diego Supercomputer Center PO Box 85608 San Diego, CA 92186-9784 E-mail: loveep@sds.sdsc.edu Phone: (619)534-5000 Sesquinet Sesquinet is a regional network in Texas. Its members include universities, research laboratories, and industrial organizations Address: Guy Almes Dept. of Computer Science Rice University Houston, Texas 77251-1892 E-mail: almes@rice.edu [Guy Almes] farrell@rice.edu [Farrell Gerbode] Phone: (713) 527-6038 [Almes], (713) 527-4988 [Gerbode] SURAnet SURAnet is an NSFNET mid-level network. SURAnet's geographic area includes the District of Columbia and thirteen states in the southeast US: Alabama, Delaware, Florida, Georgia, Kentucky, Louisiana, Maryland, Mississippi, North Carolina, South Carolina, Tennessee, Virginia and West Virginia. While SURA, the parent organization, is a consortium of academic organizations, SURAnet members comprise approximately two-thirds academic institutions and one-third non-academic sites. Address: SURAnet Computer Science Center University of Maryland College Park, MD 20742-2411 attn: Dr. Jack Hahn E-mail: hahn@umd5.umd.edu, suranet-admin@noc.sura.net Phone: (301)454-5434 [Hahn] Contacts: Network Operations Center (NOC) Hours: 0800-1630 Manager: Mark Oros Hotline: (301) 454-8055 oros@umd5.umd.edu SURAnet Personnel: suranet-admin@noc.sura.net NOC Personnel: noc-staff@noc.sura.net User Problems: help@noc.sura.net THEnet The Texas Higher Education Network is an NSFNET regional network that covers the state of Texas, with a link to the Instituto Tecnologico y de Estudios Superiores de Monterrey in Monterrey, Mexico. Network information and operations management are provided through the University of Texas (UT) System Office of Telecommunication Services (OTS). Address: Texas Higher Education Network Information Center Commons Building Room 1.156A Balcones Research Center 10100 Burnet Road Austin, TX 78758-4497 E-mail: THEnet (DECnet):+THENIC::INFO BITNET:+INFO@THENIC Internet:+info@nic.the.net SPAN:+UTSPAN::THENIC::INFO Phone: (512) 471-2444 USAN USAN (University Satellite Network) is a discipline-oriented network serving organizations that do research in the atmospheric and oceanographic sciences. Current members are the Universities of Miami, Oregon State, Penn State, Maryland, Wisconsin, the Institute of Naval Oceanography, the Naval Research Lab, and Woods Hole Oceanographic Institute. The primary use of the network is for access to supercomputer facilities at NCAR; secondary use is for access to the Internet. Address: National Center for Atmospheric Research USAN Network/Scientific Computing Division 1850 Table Mesa Drive P.O. Box 3000 Boulder, CO 80307 E-mail: morris@ncar.ucar.edu Phone: (303) 497-1282 [Don Morris] VERNet The Virginia Education and Research Network is the regional network for the state of Virginia. E-mail: jaj@crash.virginia.edu Phone: (804) 924-0616 Contacts: Jim Jokl Westnet Westnet is a regional network with nodes in the states of Arizona, Colorado, southern Idaho, New Mexico, Utah and Wyoming. The member organizations are universities, research laboratories, and commercial organizations. Addresses: Administrative: Westnet c/o Patrick J. Burns Department of Mechanical Engineering Colorado State University Fort Collins, CO 80523 Technical: Westnet c/o Carol Ward 3645 Marine Street University of Colorado Boulder, C0 80309-0455 E-mail: westnet@spot.colorado.edu Phone: (303) 491-1575 [Pat Burns] (303) 492-5860 [Carol Ward] Net Etiquette "Etiquette" means "ticket" in French. On the Internet, "netiquette" is your ticket to "travelling" (by FTP, TELNET, and electronic mail) without annoying others. Electronic mail messages can be informal, but thought should be given before they are sent. Don't send a message until you have taken time to review its contents and header. Make sure your message is correctly addressed (that you aren't copying it to a group address unintentionally or unwisely), that it is free of typos, and that you really mean what it says. Especially when sending a message to a mailing list or bboard (see Interest Groups), try to be clear and consise. Addresses When you send Internet electronic mail, make sure that the "From:" field in the headers of your messages can be used to generate replies from Internet hosts. The "From:" field should contain either a full Internet address, for example, From: socrates@agora.edu or your "signature" name plus the Internet address enclosed in "angle brackets": From: "Socrates Jones" The following From: fields will prevent people on the Internet from replying to your messages: From: groucho@cs (No domain name!) From: cs!groucho (uucp address) From: cs!groucho@fredonia.edu (This might work, but test it!) DECNET, VAX/VMS, and BITNET addresses will also have problems. Hopefully, your host gateways to the Internet through a host that rewrites addresses so that Internet hosts can reply to them. Check the address of the recipient of your message. If you are not sure of an address, don't guess. Electronic mail addresses are very unforgivingÑyou must get every character exactly right. The quickest way to check an address is by telephone. If you can't do that, try to find the domain for the organization, and send email to postmaster@domain (using the domain name). Or send a U.S. postal letter to the recipient and ask for a reply by electronic mail. If the email address is wrong, you should get the message back eventually, but it can take three days to a week to return. Many mailing lists (see Interest Groups) are distributed by 'repeater' programs. For example, when you send a message to unix- pmdf@sh.cs.net, the message is automatically re-mailed to everyone on the mailing list. Be careful of thisÑthere is nothing in the name of a repeater list to help you distinguish it from a non-repeating address. Inadvertently sending a private message to a mailing list can be embarrassing, and someone on the list might "flame" at you. Always assume a list address is a 'repeater'. Check the header before you send a message to make sure there is no extra address in the "To:" or "Cc." field. Many lists (such as dip-people) have a special "-request" address (such as dip-people-request@relay.cs.net). Be careful to send requests to be added or dropped from the list to the moderator or the -request address, and not to the whole list. Netiquette for Groups Check with your system administrator to see what newsgroups are available to you and how to use them. The following is based on The USENET Primer on How to Work With the USENET Community by Gene Spafford Never Forget that the Person on the Other Side is Human Because your interaction with the network is through a computer, it is easy to forget that there are people "out there." Situations arise where emotions erupt into a verbal free-for-all that can lead to hurt feelings. Strongly critical messages on the network are called "flames." The following will help you to avoid sending or provoking flames. Try not to say anything to others that you would not say to them in person in a room full of people. Please remember that when you send a messsage to a bulletin board or mailing list, people all over the world are reading your words. Don't attack peopleÑtry to persuade them by presenting facts. Cursing and abuse only make people less willing to help when you need it. If you are upset at something or someone, wait until you have had a chance to calm down and think about it. A cup of coffee or a good night's sleep works wonders on your perspective. Hasty words create more problems than they solve. Be Careful What You Say About Others Please rememberÑthousands of people may read your message. They quite possibly include your boss, your friend's boss, your girlfriend's brother's best friend, and one of your father's beer buddies. Information posted on the net can come back to haunt you or the person you are talking about. Think twice before you post personal information about yourself or others. Be Brief Say what you have to say succinctly and it will have a greater impact. Remember that the longer you make your article, the fewer people will bother to read it. Your Postings Reflect Upon YouÑBe Proud of Them Most people will know you only by what you say and how well you say it. Take some time to make sure each posting won't embarrass you later. Minimize your spelling errors and make sure that the article is easy to read and to understand. Use Descriptive Titles The subject line of an article enables people to decide whether or not to read your article. Tell people what the article is about before they read it. A title like "Car for Sale" does not help as much as "66 MG Midget for sale: Beaverton OR." Don't expect people to read your article to find out what it's about Ñ many won't bother. Some sites truncate the length of the subject line to forty characters, so keep your subjects short and to the point. Think About Your Audience When you post an article, think about the people you are trying to reach. Try to get the most appropriate audience for your message, not the widest. Avoid abbreviations and acronyms, if possible, and define the ones you use. If your message is of interest to a limited geographic area (apartments, car sales, meetings, concerts, etc...), restrict the distribution of the message to your local area. Some areas have special newsgroups with geographical limitationsÑcheck with your system administrator. If you want to try a test of something, don't use a world-wide newsgroup! There are newsgroups that are local to your computer or area, which should be used for this. Your system administrator can tell you what they are. Be familiar with the group you are posting to before you post. You shouldn't post to groups you don't read, or to groups you've only read a few articles fromÑyou may not be familiar with the conventions and themes of the group. One normally does not join a conversation by just walking up and talking. Instead, you listen first and then join in if you have something pertinent to contribute. Be Careful with Humor and Sarcasm Without the voice inflections and body language of personal communications, it's easy for remarks meant to be funny to be misinterpreted. Subtle humor tends to get lost. Take steps to make sure that people realize you are trying to be funny. The net has developed a symbol called the smiley face, which looks like this: :-) It points out sections of articles with humorous intent. No matter how broad the humor or satire, it is safer to remind people that you are being funny. But also be aware that frequently satire is posted without explicit indications. If an article outrages you strongly, ask yourself if it may have been unmarked satire. Several self-proclaimed connoisseurs refuse to use smiley faces, so take heed or you may make a temporary fool of yourself. Only Post a Message Once Avoid posting messages to more than one group unless you are sure it is appropriate. If you do post to multiple groups, don't post to each group separately. Instead, specify all the groups on a single message. This reduces network overhead and lets people who subscribe to more than one of those groups see the message once instead of having to wade through each copy. Please "Rotate" Messages With Questionable Content Certain messages may be offensive to some people. To make sure that these messages are not read unless they are explicitly requested, they should be encrypted. The standard encryption method is to rotate each letter by thirteen characters so that an "a" becomes an "n." This is known on the network as "rot13"; when you rotate a message the word "rot13" should be in the "Subject:" line. Most of the software used to read network articles has some way of encrypting and decrypting messages. Your system administrator can tell you how the software on your system works, or you can use the Unix command "tr [a-z][A-Z] [n-z][a-m][N-Z][A-M]". (Note that some versions of Unix don't require the [] in the "tr" command. In fact, some systems will get upset if you use them in an unquoted manner. The following should work for everyone, but may be shortened on some systems: tr '[a-m][n- z][A-M][N-Z]' '[n-z][a-m][N-Z][A-M]'ÑDon't forget the single quotes!) Summarize What You are Following Up When you are following up someone's article, please summarize the parts of the article to which you are responding. This allows readers to appreciate your comments rather than trying to remember what the original article said. It is also possible for your response to reach some sites before the original article does! Summarization is best done by including appropriate quotes from the original article. Don't include the entire article, since it will irritate the people who have already seen it. Even if you are responding to the entire article, summarize only the major points you are discussing. When Summarizing, Summarize! When you request information from the network, it is common courtesy to report your findings so that others can benefit as well. The best way of doing this is to take all the responses that you received and edit them into a single article that is posted to the places where you originally posted your question. Take the time to strip headers, combine duplicate information, and write a short summary. Try to credit the information to the people that sent it to you, where possible. Use Mail, Don't Post a Follow-up One of the biggest problems we have on the network is that when someone asks a question, many people send out identical answers. When this happens, dozens of identical answers pour through the net. Mail your answer to the person and suggest that they summarize to the network. This way the net will only see a single copy of the answers, no matter how many people answer the question. If you post a question, please remind people to send you the answers by mail and at least offer to summarize them to the network. Read All Follow-ups and Don't Repeat What Has Already Been Said Before you submit a follow-up to a message, read the rest of the messages in the newsgroup to see whether someone has already said what you want to say. If someone has, don't repeat it. Check the Headers When Following Up Some software has provisions to specify that follow-ups to an article should go to a specific set of newsgroupsÑpossibly different from the newsgroups to which the original article was posted. Sometimes the groups chosen for follow-ups are inappropriate, especially as a thread of discussion changes with repeated postings. You should carefully check the groups and distributions given in the header and edit them as appropriate. If you change the groups named in the header, or if you direct follow-ups to a particular group, say so in the body of the messageÑnot everyone reads the headers of postings. Be Careful About Copyrights and Licenses Once something is posted onto the network, it is *probably* in the public domain unless you own the appropriate rights (for example, if you wrote it yourself) and you post it with a valid copyright notice; a court would have to decide the specifics and there are arguments for both sides of the issue. Now that the US has ratified the Berne convention, the issue is even murkier. For all practical purposes, though, assume that you effectively give up the copyright if you don't put in a notice. Of course, the information becomes public, so you mustn't post trade secrets that way. Keep in mind that material that is UNIX-related may be restricted by the license you or your company signed with AT&T, so be careful not to violate it. You should also be aware that posting movie reviews, song lyrics, or anything else published under a copyright could cause you, your company, or members of the net community to be held liable for damages, so we highly recommend caution in using this material. Cite Appropriate References If you are using facts to support a cause, state where they came from. Don't take someone else's ideas and use them as your own. You don't want someone pretending that your ideas are theirs; show them the same respect. Mark or Rotate Answers and Spoilers When you post something (like a movie review that discusses a detail of the plot) that might spoil a surprise for other people, please mark your message with a warning so that they can skip the message. Another alternative would be to use the "rot13" protocol to encrypt the message so it cannot be read accidentally. When you post a message with a spoiler in it make sure the word "spoiler" is part of the "Subject:" line. Spelling Flames Considered Harmful Every few months a plague descends on the network called the spelling flame. It starts out when someone posts an article correcting the spelling or grammar in some article. The immediate result seems to be for everyone on the net to turn into a sixth grade English teacher and pick apart each other's posting. This is not productive and tends to cause people to get angry with each other. It is important to remember that we all make mistakes, and that there are many users on the net who use English as a second language. There are also a number of people who suffer from dyslexia and who have difficulty noticing their spelling mistakes. If you feel that you must make a comment on the quality of a posting, please do so by mail, not on the network. Don't Overdo Signatures Many people can have a signature added to their postings automatically by placing it in a file called "$HOME/.signature". Don't overdo it. Signatures can tell the world something about you, but keep them short. A signature that is longer than the message itself is considered to be in bad taste. The main purpose of a signature is to help people locate you, not to tell your life story. Every signature should include at least your return address relative to a major, known site on the network and a proper domain-format address. Your system administrator can give this to you. Some news posters attempt to enforce a four-line limit on signature filesÑan amount that should be more than sufficient to provide a return address and attribution. Limit Line Length and Avoid Control Characters Try to keep your text in a generic format. Many (if not most) of the people reading Usenet do so from eighty-column terminals or from workstations with eighty-column terminal windows. Try to keep your lines of text to less than eighty-characters for optimal readability. Also realize that there are many, many different forms of terminals in use. If you enter special control characters in your message, it may result in your message being unreadable on some terminal types; a character sequence that causes reverse video on your screen may result in a keyboard lock and graphics mode on someone else's terminal. You should try to avoid the use of tabs, too, since they may also be interpreted differently on terminals other than your own. Summary of Things to Remember Never forget that the person on the other side is human Be careful what you say about others Be brief Your postings reflect upon you; be proud of them Use descriptive titles Think about your audience Be careful with humor and sarcasm Only post a message once Please rotate material with questionable content Summarize what you are following up Use e-mail, don't post a follow-up Read all follow-ups and don't repeat what has already been said Double-check follow-up newsgroups and distributions. Be careful about copyrights and licenses Cite appropriate references When summarizing, summarize Mark or rotate answers or spoilers Spelling flames are considered harmful Don't overdo signatures Limit line length and avoid control characters (*)UNIX is a registered trademark of AT&T. Electronic Mail Electronic mail allows you to exchange messages with other computer users (or groups of users) via a communications network. Electronic mail is one of the most popular uses of the Internet. The Internet standard for naming computers is called the "domain system." Different computers use different software for electronic mail. UNIX systems, for example, may use UNIX mail, mh, msg, or something else. Different software uses different commands. Ask the Postmaster at your site how to use electronic mail on your system. Domain System The Internet standard for naming computers is called the "domain system." This hierarchical system references values such as country, type of organization, organization name, division name, and computer name. Below is an example: joe@bitsy.mit.edu The information in a mail address becomes more global as you read from left to right. The user's name is always to the left of an @ sign. Computer and organization names are always to the right. In the example above, the person, Joe, receives his mail on a computer called "bitsy" at MIT. Because MIT is an educational organization, it is included in the top-level domain "edu". Other top-level domains are listed below: com commercial gov government mil military org nonprofit organization net network operation and info centers Outside of the U.S., top-level domains are two-letter country codes such as these: au Australia il Israel jp Japan uk United Kingdom Finding Mail Addresses You can learn the electronic mail address of another person by asking him or by using one of the following resources: ¥ A postmaster at the recipient's organization can provide the correct address when you know the the domain name of the organization. Send a message requesting help to postmaster@domain. ¥ The DDN Network Information Center (DDN NIC) in Menlo Park, California, maintains a "white pages" directory of computer users, hosts, and domains on the Internet. You can use Telnet to access this database on a computer called nic.ddn.mil. Many computers also have a program called whois, which automatically accesses the DDN NIC database. Ask your system administrator whether your computer has whois. UNIX mail Manual This is the UNIX (see BSD) manual entry for mail, a common electronic mail system. Your site may use other electronic mail softwareÑ check with your system administrator. NAME mail - send or read mail SYNTAX mail [-v] [-i] [-n] [-e] [-s subject] [user...] mail [-v] [-i] [-n] -f [name] mail [-v] [-i] [-n] -u user mail nodename::username (If DECnet is installed.) The mail utility is an intelligent mail processing system which has a command syntax similar to ed. However, in mail lines are replaced by messages. If DECnet is installed on your system, you can also send and receive mail from other DECnet users. Sending mail. To send a message to one or more persons, type mail and the names of the people to receive your mail. Press the return key. You are then prompted for a subject. After entering a subject, and pressing the return key, type your message. To send the message, type on a blank line. You can use tilde (~) escape sequences to perform special functions when composing mail messages. See the list of options for more on tilde escape sequences. Reading mail. In normal usage mail is given no arguments and checks your mail out of the mail directory. Then it prints out a one line header of each message there. The current message is initially the first message and is numbered 1. It can be displayed using the print command. The -e option causes mail not to be printed. Instead, an exit value is returned. For the exit status, see RETURN VALUES. You can move among the messages by typing a plus sign (+) followed by a number to move forward that many messages, or a minus sign (-) followed by a number to move backward that many messages. Disposing of mail. After reading a message you can delete (d) it or reply (r) to it. Deleted messages can be undeleted, however, in one of two ways: you can use the undelete (u) command and the number of the message, or you can end the mail session with the exit (x) command. Note that if you end a session with the quit (q) command, you cannot retrieve deleted messages. Specifying messages. Commands such as print and delete can be given a list of message numbers as arguments. Thus, the command delete 1 2 deletes messages 1 and 2, while the command delete 1-5 deletes messages 1 through 5. The asterisk (*) addresses all messages, and the dollar sign ($) addresses the last message. For example, the top command, which prints the first few lines of a message, can be used in the following manner to print the first few lines of all messages: top * Replying to or originating mail. Use the reply command to respond to a message. Ending a mail processing session. End a mail session with the quit (q) command. Unless they were deleted, messages that you have read go to your mbox file. Unread messages go back to the mail directory. The -f option causes mail to read in the contents of your mbox (or the specified file) for processing. When you quit, the mail utility writes undeleted messages back to this file. The -u flag is a short way of specifying: mail -f /usr/spool/mail/user. Personal and systemwide distribution lists. You can create a personal distribution list that directs mail to a group of people. Such lists can be defined by placing a line similar to the following in the .mailrc file in your home directory: alias cohorts bill ozalp jkf mark kridle@ucbcory Cohorts is the name of the distribution list that consists of the following users: bill, ozalp, jkf, mark, and kridle@ucbcory. A list of current aliases can be displayed with the alias (a) command in mail. System-wide distribution lists can be created by editing /usr/lib/aliases. The syntax of system-wide lists differs from that of personally defined aliases. Personal aliases are expanded in mail you send. When a recipient on a personally defined mailing list uses the reply (r) option, the entire mailing list receives the response automatically. System-wide aliases are not expanded when the mail is sent, but any reply returned to the machine will have the system-wide alias expanded as all mail goes through sendmail. Options -e Causes mail not to be printed. Instead, an exit value is returned. -f Causes mail to read in the contents of your mbox file (or another file you specify) for processing. -i Causes tty interrupt signals to be ignored. This is useful when using mail on noisy phone lines. -n Inhibits the reading of /usr/lib/mail.rc. -s Specifies a subject on the command line. Note that only the first argument after the -s flag is used as a subject and that you must enclose subjects containing spaces in quotes. -u Specifies a short hand for expressing the following: mail -f /usr/spool/mail/user -v Prints the mail message. The details of delivery are displayed on the user's terminal. The following options can be set in the .mailrc file to alter the behavior of the mail command. Each command is typed on a line by itself and may take arguments following the command word and the command abbreviation. For commands that take message lists as arguments, if no message list is given, then the next message forward which satisfies the command's requirements is used. If there are no messages forward of the current message, the search proceeds backwards. If there are no good messages at all, mail cancels the command, displaying the message: No applicable messages. - Prints out the previous message. If given a numeric argument n, prints n-th previous message. ? Prints a brief summary of commands. ! Executes the ULTRIX shell command which follows. alias (a) Prints out all currently defined aliases, if given without arguments. With one argument, prints out that alias. With more than one argument, creates a new or changes an old alias. These aliases are in effect for the current mail session only. alternates (alt) Informs mail that you have several valid addresses. The alternates command is useful if you have accounts on more than one machine. When you reply to messages, mail does not send a copy of the message to any of the addresses listed on the alternates list. If the alternates command is given with no argument, the current set of alternate names is displayed. chdir (ch) Changes the user's working directory to that specified. If no directory is given, then the chdir command changes to the user's login directory. copy (co) Takes a message list and file name and appends each message to the end of the file. The copy command functions in the same way as the save command, except that it does not mark the messages that you copy for deletion when you quit. delete (d) Takes a list of messages as argument and marks them all as deleted. Deleted messages are not saved in mbox, nor are they available for most other commands. dp (or dt) Deletes the current message and prints the next message. If there is no next message, mail returns a message: at EOF. edit (e) Takes a list of messages and points the text editor at each one in turn. On return from the editor, the message is read back in. exit (ex or x) Returns to the shell without modifying the user's system mailbox, mbox file, or edit file in -f. file (fi) Switches to a new mail file or folder. If no arguments are given, it tells you which file you are currently reading. If you give it an argument, it writes out changes (such as deletions) you have made in the current file and reads in the new file. Some special conventions are recognized for the name. A pound sign (#) indicates the previous file, a percent sign (%) indicates your systemb mailbox, %user indicates the user's system mailbox, an ampersand (&) indicates your ~/mbox file, and +folder indicates a file in your folder directory. folders List the names of the folders in your folder directory. folder (fo) Switches to a new mail file or folder. The folder command functions in the same way as the file command. from (f) Takes a list of messages and prints their message headers in the order that they appear in the mail directory, not in the order given in the list. headers (h) Lists the current range of headers, which is an eighteen- message group. If a plus sign (+) is given as an argument, then the next message group is printed. If a minus sign (-) is given as an argument, the previous message group is printed. help Prints a brief summary of commands. Synonymous with ?. hold (ho, also preserve) Takes a message list and marks each message in it to be saved in the user's system mailbox instead of in mbox. The hold command does not override the delete command. ignore Adds the list of header fields named to the ignored list. Header fields in the ignore list are not printed on your terminal when you print a message. This command is frequently used to suppress certain machine-generated header fields. The Type and Print commands are used to print a message in its entirety, including ignored fields. If ignore is executed with no arguments, it lists the current set of ignored fields. mail(m) Takes login names and distribution group names as arguments and sends mail to those people. mbox Indicates that a list of messages should be sent to mbox in your home directory when you quit. This is the default action for messages if you did not set the hold option. next (n, + or CR) Goes to the next message in sequence and types it. With an argument list, it types the next matching message. preserve (pre) Takes a message list and marks each message in it to be saved in the user's system mailbox instead of in mbox . Synonymous with the hold command. print (p) Takes a message list and types out each message on the user's terminal, without printing any specified ignored fields. Print (P) Prints a message in its entirety, including specified ignored fields. quit (q) Terminates the session. All undeleted, unsaved messages are saved in the user's mbox file in his login directory; all messages marked with hold or preserve or that were never referenced are saved in his system mailbox; and all other messages are removed from his system mailbox. If new mail arrives during the session, the user receives the message "You have new mail." If given while editing a mailbox file with the -f flag, then the edit file is rewritten. A return to the Shell is effected, unless the rewrite of the edit file fails, in which case the user can escape with the exit command. reply (r) Takes a message list and sends mail to the sender and all recipients of the specified message. The default message must not be deleted. Reply (R) Replies to originator of the message. Does notreply to other recipients of the original message. respond Takes a message list and sends mail to the sender and all recipients of the specified message. Synonymous with reply. save (s) Takes a message list and a file name and appends each message to the end of the file. The messages are saved in the order in which they appear in the mail directory, not in the order given in the message list. The filename, which is enclosed in quotes, followed by the line count and character count, is displayed on the user's terminal. set (se) Prints all variable values when no arguments are given. Otherwise, the set command sets the specified option. Arguments either take the form: option=value or option. shell (sh) Invokes an interactive version of the shell. size Takes a message list and prints out the size (in characters) of each message. The size of the messages are printed in the order that they appear in the mail directory, not in the order given in the list. source (so) Reads mail commands from a file. top Takes a message list and prints the top few lines of each. The number of lines printed is controlled by the variable toplines and defaults to five. type (t) Takes a message list and types out each message on the user's terminal, without printing any specified ignored fields. Synonymous with print. Type (T) Prints a message in its entirety, including specified ignored fields. Synonymous with Print. unalias Takes a list of names defined by alias commands and cancels the list of users. The group names no longer have any significance. undelete (u) Takes a message list and marks each one as not being deleted. unset Takes a list of option names and discards their remembered values; the inverse of set. visual (v) Takes a message list and invokes the display editor on each message. write (w) Takes a message list and a file name and appends each message to the end of the file. Synonymous with save. xit (x) Returns to the Shell without modifying the user's system mailbox, mbox , or edit file in -f. Synonymous with exit. z Presents message headers in windowfulls as described under the headers command. You can move forward to the next window with the z command. Also, you can move to the previous window by using z-. The following is a summary of the tilde escape functions that you can use when composing mail messages. Note that you can only invoke these functions from within the body of a mail message and that the sequences are only executed if they are placed at the beginning of lines. ~!command Executes the indicated shell command, then returns to the message. ~? Prints a brief summary of tilde commands. ~: Executes the mail commands. (For example, the command ~:10 prints out message number 10 while ~:- prints out the previous message. ~c name ... Adds the given names to the list of carbon copy recipients. ~d Reads the file named dead.letter from your home directory into the message. ~e Invokes the text editor on the message you are typing. After the editing session is finished, you may continue appending text to the message. ~f messages Reads the named messages into the message being sent. If no messages are specified, reads in the current message. ~h Edits the message header fields by typing each one in turn and allowing the user to append text to the end or to modify the field by using the current terminal erase and kill characters. ~m messages Reads the named messages into the message being sent, shifted one tab space to the right. If no messages are specified, reads the current message. ~p Prints out the message on your terminal, prefaced by the message header fields. ~q Aborts the message being sent, copying the message to dead.letter in your home directory if the save option is set. ~r filename Reads the named file into the message. ~s string Causes the named string to become the current subject field. ~t name ... Adds the given names to the direct recipient list. ~v Invokes an alternate editor (defined by the VISUAL option) on the message. Usually, the alternate editor is a screen editor. After you quit the editor, you can resume appending text to the end of your message. ~w filename Writes the message onto the named file. ~|command Pipes the message through the command as a filter. If the command gives no output or terminates abnormally, retains the original text of the message. The command fmt(1) is often used as command to rejustify the message. ~~string Inserts the string of text in the message prefaced by a single tilde (~). If you have changed the escape character, then you should double that character in order to send it. Options are controlled via the set and unset commands. Options may be either binary or string. If they are binary you should see whether or not they are set; if they are string it is the actual value that is of interest. The binary options include the following: append Causes messages saved in mbox to be appended rather than prepended. (This is set in /usr/lib/Mail.rc on version 7 systems.) ask Causes mail to prompt you for the subject of each message you send. If you simply respond with a new line, no subject field is sent. askcc Asks you at the end of each message whether you want to send a carbon copy of the message to additional recipients. Responding with a new line indicates your satisfaction with the current list. autoprint Causes the delete command to behave like dp - thus, after deleting a message, the next one is typed automatically. debug Causes mail to output information useful for debugging mail. Setting the binary option debug is the same as specifying -d on the command line. dot Causes mail to interpret a period alone on a line as the terminator of a message you are sending. hold Holds messages in the system mailbox by default. ignore Causes interrupt signals from your terminal to be ignored and echoed as at signs (@). ignoreeof Causes mail to refuse to accept a control-d as the end of a message. msgprompt Prompts you for the message text and indicates how to terminate the message. metoo Includes the sender in the distribution group receiving a mail message. nosave Prevents mail from copying aborted messages into the dead.letter file in your home directory. quiet Suppresses the printing of the version when first invoked. verbose Displays the details of each message's delivery on the user's terminal. Setting the verbose option is the same as typing -v on the command line. The string options include the following: EDITOR Pathname of the text editor to use in the edit command and ~e escape. If not defined, then a default editor is used. SHELL Pathname of the shell to use in the ! command and the ~! escape. A default shell is used if this option is not defined. VISUAL Pathname of the text editor to use in the visual command and ~v escape. crt Threshold to determine how long a message must be before more is used to read it. escape The first character of this option gives the character to use in the place of tilde (~) to denote escapes, if defined. folder Directory name to use for storing folders of messages. If this name begins with a backslash (/) mail considers it an absolute pathname; otherwise, the folder directory is found relative to your home directory. record Pathname of the file used to record all out-going mail. If it is not defined, then out-going mail is not so saved. toplines The number of lines of a message that is printed out with the top command; normally, the first five lines are printed. RETURN VALUES If mail is invoked with the -e option, the following exit values are returned: 0 the user has mail 1 the user has no mail FILES /usr/spool/mail/* mail directory ~/mbox your read mail ~/.mailrc file giving initial mail commands /tmp/R# temporary for editor escape /usr/lib/Mail.help* help files /usr/lib/Mail.rc system initialization file Message* temporary for editing messages This is the manual entry for the mail utility on the VMS operating system, a common electronic mail system. Your site may use other electronic mail softwareÑ check with your system administrator. The VMS Personal Mail Utility (MAIL), is used to send messages to other users. For a complete description of the VMS Personal Mail Utility, including information about the MAIL command and its qualifiers, see the VMS Mail Utility Manual. Format: MAIL [file-spec] [recipient-name] Additional information available: Parameters Command_Qualifiers /PERSONAL_NAME /SUBJECT /EDIT /SELF Examples MAIL Subtopic? /personal MAIL /PERSONAL_NAME /PERSONAL_NAME=name /NOPERSONAL_NAME Specifies the personal name to be used when sending a message. This qualifier does not override the default personal name; the personal name is changed only for the current message. Specifying /NOPERSONAL_NAME removes the default personal name for the current message. MAIL Subtopic? /subject MAIL /SUBJECT /SUBJECT=text Specifies the subject of the message for the heading. If the text consists of more than one word, enclose the text in quotation marks ("). You must include a file specification on the command line to enable this qualifier. If you omit this qualifier, the message is sent without a subject notation. MAIL Subtopic? /edit MAIL /EDIT /EDIT=[(send,reply=extract,forward)] Sets the default to /EDIT for the SEND, REPLY, and FORWARD commands. MAIL Subtopic? /self MAIL /SELF /SELF Sends a copy of the message containing the file specification on the command line back to you. MAIL Subtopic? exam MAIL Examples 1. $ MAIL MAIL> This MAIL command invokes MAIL to process commands interactively. 2. $ MAIL/SUBJECT="New Project" PROJECT.DOC JONES,SMITH,ADAMS This MAIL command specifies that the file named PROJECT.DOC is to be sent to users JONES, SMITH, and ADAMS, with a subject description of New Project in the heading. 3. $ MAIL/SUBJECT="Vacation Policy Change" NEWSLETTR "@USERS" This MAIL command invokes MAIL to send the file NEWSLETTR.TXT to all the users named in the file USERS.DIS. The subject description is Vacation Policy Change. RCCA> mail You have 1 new message. MAIL> dir NEWMAIL # From Date Subject 1 IN%"RBEAUPRE@ccr2.bb 22-AUG-1990 END OF SHIFT MAIL> send To: mlbanker Subj: test Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit: this is a test message MAIL> read #1 22-AUG-1990 11:51:41.03 NEWMAIL From: IN%"RBEAUPRE@ccr2.bbn.com" "Ray Beaupre" To: TURNOVER@mikey.bbn.com CC: Subj: END OF SHIFT From: Ray Beaupre Subject: END OF SHIFT To: TURNOVER@mikey.bbn.com X-VMS-To: TURNOVER Worked in Building 20 with Max Stepp last night in the 7th Floor Lab. I was trained on the following Building 20 systems. MAIL> delete 1 MAIL> exit %MAIL-I-RECLPLSWAIT, reclaiming deleted file space. Please wait... VMS Mail Utility Manual mail(1) NAME mail - send or read mail SYNTAX mail [-v] [-i] [-n] [-e] [-s subject] [user...] mail [-v] [-i] [-n] -f [name] mail [-v] [-i] [-n] -u user mail nodename::username (If DECnet is installed.) DESCRIPTION The mail utility is an intelligent mail processing system which has a command syntax similar to ed. However, in mail lines are replaced by messages. If DECnet is installed on your system, you can also send and receive mail from other DECnet users. Sending mail. To send a message to one or more persons, type mail and the names of the people to receive your mail. Press the RETURN key. You are then prompted for a subject. After entering a subject, and pressing the RETURN key, type your message. To send the message, type on a blank line. You can use tilde (~) escape sequences to perform special functions when composing mail messages. See the list of options for more on tilde escape sequences. Reading mail. In normal usage mail is given no arguments and checks your mail out of the mail directory. Then it prints out a one line header of each message there. The current message is initially the first message and is numbered 1. It can be displayed using the print command. The -e option causes mail not to be printed. Instead, an exit value is returned. For the exit status, see RETURN VALUES. You can move among the messages by typing a plus sign (+) followed by a number to move forward that many messages, or a minus sign (-) followed by a number to move backward that many messages. Disposing of mail. After reading a message you can delete (d) it or reply (r) to it. Deleted messages can be undeleted, however, in one of two ways: you can use the undelete (u) command and the number of the message, or you can end the mail session with the exit (x) command. Note that if you end a session with the quit (q) command, you cannot retrieve deleted messages. Specifying messages. Commands such as print and delete can be given a list of message numbers as arguments. Thus, the command delete 1 2 deletes messages 1 and 2, while the command delete 1-5 deletes messages 1 through 5. The asterisk (*) addresses all messages, and the dollar sign ($) addresses the last message. For example, the top command, which prints the first few lines of a message, can be used in the following manner to print the first few lines of all messages: top * Replying to or originating mail. Use the reply command to respond to a message. Ending a mail processing session. End a mail session with the quit (q) command. Unless they were deleted, messages that you have read go to your mbox file. Unread messages go back to the mail directory. The - f option causes mail to read in the contents of your mbox (or the specified file) for processing. When you quit, the mail utility writes undeleted messages back to this file. The -u flag is a short way of specifying: mail -f /usr/spool/mail/user. Personal and systemwide distribution lists. You can create a personal distribution list that directs mail to a group of people. Such lists can be defined by placing a line similar to the following in the .mailrc file in your home directory: alias cohorts bill ozalp jkf mark kridle@ucbcory Cohorts is the name of the distribution list that consists of the following users: bill, ozalp, jkf, mark, and kridle@ucbcory. A list of current aliases can be displayed with the alias (a) command in mail. System-wide distribution lists can be created by editing /usr/lib/aliases. The syntax of system-wide lists differs from that of personally defined aliases. Personal aliases are expanded in mail you send. When a recipient on a personally defined mailing list uses the reply (r) option, the entire mailing list receives the response automatically. System-wide aliases are not expanded when the mail is sent, but any reply returned to the machine will have the system-wide alias expanded as all mail goes through sendmail. OPTIONS -e Causes mail not to be printed. Instead, an exit value is returned. -f Causes mail to read in the contents of your mbox file (or another file you specify) for processing. -i Causes tty interrupt signals to be ignored. This is useful when using mail on noisy phone lines. -n Inhibits the reading of /usr/lib/mail.rc. -s Specifies a subject on the command line. Note that only the first argument after the -s flag is used as a subject and that you must enclose subjects containing spaces in quotes. -u Specifies a short hand for expressing the following: mail -f /usr/spool/mail/user -v Prints the mail message. The details of delivery are displayed on the user's terminal. The following options can be set in the .mailrc file to alter the behavior of the mail command. Each command is typed on a line by itself and may take arguments following the command word and the command abbreviation. For commands that take message lists as arguments, if no message list is given, then the next message forward which satisfies the command's requirements is used. If there are no messages forward of the current message, the search proceeds backwards. If there are no good messages at all, mail cancels the command, displaying the message: No applicable messages. - Prints out the previous message. If given a numeric argument n, prints n-th previous message. ? Prints a brief summary of commands. ! Executes the ULTRIX shell command which follows. alias (a) Prints out all currently defined aliases, if given without arguments. With one argument, prints out that alias. With more than one argument, creates a new or changes an old alias. These aliases are in effect for the current mail session only. alternates (alt) Informs mail that you have several valid addresses. The alternates command is useful if you have accounts on more than one machine. When you reply to messages, mail does not send a copy of the message to any of the addresses listed on the alternates list. If the alternates command is given with no argument, the current set of alternate names is displayed. chdir (ch) Changes the user's working directory to that specified. If no directory is given, then the chdir command changes to the user's login directory. copy (co) Takes a message list and file name and appends each message to the end of the file. The copy command functions in the same way as the save command, except that it does not mark the messages that you copy for deletion when you quit. delete (d) Takes a list of messages as argument and marks them all as deleted. Deleted messages are not saved in mbox, nor are they available for most other commands. dp (or dt) Deletes the current message and prints the next message. If there is no next message, mail returns a message: at EOF. edit (e) Takes a list of messages and points the text editor at each one in turn. On return from the editor, the message is read back in. exit (ex or x) Returns to the shell without modifying the user's system mailbox, mbox file, or edit file in -f. file (fi) Switches to a new mail file or folder. If no arguments are given, it tells you which file you are currently reading. If you give it an argument, it writes out changes (such as deletions) you have made in the current file and reads in the new file. Some special conventions are recognized for the name. A pound sign (#) indicates the previous file, a percent sign (%) indicates your systemb mailbox, %user indicates the user's system mailbox, an ampersand (&) indicates your ~/mbox file, and +folder indicates a file in your folder directory. folders List the names of the folders in your folder directory. folder (fo) Switches to a new mail file or folder. The folder command functions in the same way as the file command. from (f) Takes a list of messages and prints their message headers in the order that they appear in the mail directory, not in the order given in the list. headers (h) Lists the current range of headers, which is an eighteen- message group. If a plus sign (+) is given as an argument, then the next message group is printed. If a minus sign (-) is given as an argument, the previous message group is printed. help Prints a brief summary of commands. Synonymous with ?. hold (ho, also preserve) Takes a message list and marks each message in it to be saved in the user's system mailbox instead of in mbox. The hold command does not override the delete command. ignore Adds the list of header fields named to the ignored list. Header fields in the ignore list are not printed on your terminal when you print a message. This command is frequently used to suppress certain machine-generated header fields. The Type and Print commands are used to print a message in its entirety, including ignored fields. If ignore is executed with no arguments, it lists the current set of ignored fields. mail(m) Takes login names and distribution group names as arguments and sends mail to those people. mbox Indicates that a list of messages should be sent to mbox in your home directory when you quit. This is the default action for messages if you did not set the hold option. next (n, + or CR) Goes to the next message in sequence and types it. With an argument list, it types the next matching message. preserve (pre) Takes a message list and marks each message in it to be saved in the user's system mailbox instead of in mbox . Synonymous with the hold command. print (p) Takes a message list and types out each message on the user's terminal, without printing any specified ignored fields. Print (P) Prints a message in its entirety, including specified ignored fields. quit (q) Terminates the session. All undeleted, unsaved messages are saved in the user's mbox file in his login directory; all messages marked with hold or preserve or that were never referenced are saved in his system mailbox; and all other messages are removed from his system mailbox. If new mail arrives during the session, the user receives the message: You have new mail. If given while editing a mailbox file with the -f flag, then the edit file is rewritten. A return to the Shell is effected, unless the rewrite of the edit file fails, in which case the user can escape with the exit command. reply (r) Takes a message list and sends mail to the sender and all recipients of the specified message. The default message must not be deleted. Reply (R) Replies to originator of the message. Does notreply to other recipients of the original message. respond Takes a message list and sends mail to the sender and all recipients of the specified message. Synonymous with reply. save (s) Takes a message list and a file name and appends each message to the end of the file. The messages are saved in the order in which they appear in the mail directory, not in the order given in the message list. The filename, which is enclosed in quotes, followed by the line count and character count, is displayed on the user's terminal. set (se) Prints all variable values when no arguments are given. Otherwise, the set command sets the specified option. Arguments either take the form option=value or option shell (sh) Invokes an interactive version of the shell. size Takes a message list and prints out the size (in characters) of each message. The size of the messages are printed in the order that they appear in the mail directory, not in the order given in the list. source (so) Reads mail commands from a file. top Takes a message list and prints the top few lines of each. The number of lines printed is controlled by the variable toplines and defaults to five. type (t) Takes a message list and types out each message on the user's terminal, without printing any specified ignored fields. Synonymous with print. Type (T) Prints a message in its entirety, including specified ignored fields. Synonymous with Print. unalias Takes a list of names defined by alias commands and cancels the list of users. The group names no longer have any significance. undelete (u) Takes a message list and marks each one as not being deleted. unset Takes a list of option names and discards their remembered values; the inverse of set. visual (v) Takes a message list and invokes the display editor on each message. write (w) Takes a message list and a file name and appends each message to the end of the file. Synonymous with save. xit (x) Returns to the Shell without modifying the user's system mailbox, mbox , or edit file in -f. Synonymous with exit. z Presents message headers in windowfulls as described under the headers command. You can move forward to the next window with the z command. Also, you can move to the previous window by using z-. The following is a summary of the tilde escape functions that you can use when composing mail messages. Note that you can only invoke these functions from within the body of a mail message and that the sequences are only executed if they are placed at the beginning of lines. ~!command Executes the indicated shell command, then returns to the message. ~? Prints a brief summary of tilde commands. ~: Executes the mail commands. (For example, the command ~:10 prints out message number 10 while ~:- prints out the previous message. ~c name ... Adds the given names to the list of carbon copy recipients. ~d Reads the file named dead.letter from your home directory into the message. ~e Invokes the text editor on the message you are typing. After the editing session is finished, you may continue appending text to the message. ~f messages Reads the named messages into the message being sent. If no messages are specified, reads in the current message. ~h Edits the message header fields by typing each one in turn and allowing the user to append text to the end or to modify the field by using the current terminal erase and kill characters. ~m messages Reads the named messages into the message being sent, shifted one tab space to the right. If no messages are specified, reads the current message. ~p Prints out the message on your terminal, prefaced by the message header fields. ~q Aborts the message being sent, copying the message to dead.letter in your home directory if the save option is set. ~r filename Reads the named file into the message. ~s string Causes the named string to become the current subject field. ~t name ... Adds the given names to the direct recipient list. ~v Invokes an alternate editor (defined by the VISUAL option) on the message. Usually, the alternate editor is a screen editor. After you quit the editor, you can resume appending text to the end of your message. ~w filename Writes the message onto the named file. ~|command Pipes the message through the command as a filter. If the command gives no output or terminates abnormally, retains the original text of the message. The command fmt(1) is often used as command to rejustify the message. ~~string Inserts the string of text in the message prefaced by a single tilde (~). If you have changed the escape character, then you should double that character in order to send it. Options are controlled via the set and unset commands. Options may be either binary or string. If they are binary you should see whether or not they are set; if they are string it is the actual value that is of interest. The binary options include the following: append Causes messages saved in mbox to be appended rather than prepended. (This is set in /usr/lib/Mail.rc on version 7 systems.) ask Causes mail to prompt you for the subject of each message you send. If you simply respond with a new line, no subject field is sent. askcc Asks you at the end of each message whether you want to send a carbon copy of the message to additional recipients. Responding with a new line indicates your satisfaction with the current list. autoprint Causes the delete command to behave like dp - thus, after deleting a message, the next one is typed automatically. debug Causes mail to output information useful for debugging mail. Setting the binary option debug is the same as specifying -d on the command line. dot Causes mail to interpret a period alone on a line as the terminator of a message you are sending. hold Holds messages in the system mailbox by default. ignore Causes interrupt signals from your terminal to be ignored and echoed as at signs (@). ignoreeof Causes mail to refuse to accept a control-d as the end of a message. msgprompt Prompts you for the message text and indicates how to terminate the message. metoo Includes the sender in the distribution group receiving a mail message. nosave Prevents mail from copying aborted messages into the dead.letter file in your home directory. quiet Suppresses the printing of the version when first invoked. verbose Displays the details of each message's delivery on the user's terminal. Setting the verbose option is the same as typing -v on the command line. The string options include the following: EDITOR Pathname of the text editor to use in the edit command and ~e escape. If not defined, then a default editor is used. SHELL Pathname of the shell to use in the ! command and the ~! escape. A default shell is used if this option is not defined. VISUAL Pathname of the text editor to use in the visual command and ~v escape. crt Threshold to determine how long a message must be before more is used to read it. escape The first character of this option gives the character to use in the place of tilde (~) to denote escapes, if defined. folder Directory name to use for storing folders of messages. If this name begins with a backslash (/) mail considers it an absolute pathname; otherwise, the folder directory is found relative to your home directory. record Pathname of the file used to record all out-going mail. If it is not defined, then out-going mail is not so saved. toplines The number of lines of a message that is printed out with the top command; normally, the first five lines are printed. RETURN VALUES If mail is invoked with the -e option, the following exit values are returned: 0 the user has mail 1 the user has no mail FILES /usr/spool/mail/* mail directory ~/mbox your read mail ~/.mailrc file giving initial mail commands /tmp/R# temporary for editor escape /usr/lib/Mail.help* help files /usr/lib/Mail.rc system initialization file Message* temporary for editing messages To invoke the message program your system uses, you would type the command's name (for this example, we are using mail, which is used on UNIX BSD systems). Add the address(es) of the recipient(s). (This example message is going to two people.) Then press return. --> mail carver@herhost.org glynn@hishost.edu You are then prompted to enter a subject. After entering a subject, press return. --> mail carver@herhost.org glynn@hishost.edu Subject: Proposal Then you can type a message. --> mail carver@herhost.org glynn@hishost.edu Subject: Proposal Hi Sue and Ed, Haven't heard from you two about the report draft. Have you finished reviewing it yet? Please pay particular attention to the sampling strategy described in Chapter 3. Thanks, Ben To send a message using this system, you would type a blank line. --> To read mail using mail on a UNIX system, type mail and press return. You will see the sender and subject of each message you have received. 3 carver@herhost.org Re: Report --> To display a message on the screen, type print. --> print 3 Received: from herhost.org by nnsc.nsf.net id From: Susan Carver Date: Weds, 10 Oct 90 10:41:37 EDT Ben, So far I have only minor changes--it looks good! I should be finished tomorrow. Sue --> You can reply to a message by typing r. --> print 3 Received: from herhost.org by nnsc.nsf.net id From: Susan Carver Date: Weds, 10 Oct 90 10:41:37 EDT Ben, So far I have only minor changes--it looks good! I should be finished tomorrow. Sue --> To delete it, type d . --> You can move among your messages by typing a plus sign (+) followed by a numberÑyou will move forward that many messages. Or type a minus sign (-) followed by a number to move backward that many messages. Message 1 Received: from nnsc@nsf.net by labs.bbn.com id From: Ed Glynn Date: Weds, 10 Oct 90 12:51:39 EDT Ben, I think it's fine except that I think the budget for film is too low by 20%. Ed --> Commands such as print and delete can be given a list of message numbers to act upon. In UNIX mail, the command delete 1 2 deletes messages 1 and 2, while the command delete 1-5 deletes messages 1 through 5. (Click the arrow to continue.) Received: from nnsc@nsf.net by labs.bbn.com id From: Ed Glynn Date: Weds, 10 Oct 90 12:51:39 EDT Ben, I think it's fine except that I think the budget for film is too low by 20%. Ed --> You can quit in two ways: (1) by typing q. You will not be able to retrieve deleted messages. Messages that you have read but not deleted will go to your "mbox" file. (2) by typing x. This leaves your messages unchanged; deleted messages can be retrieved. (End of Sample Session) Interest Groups Network interest groups include bulletin boards ("bboards") and mailing lists. Messages are distributed to people who share an interest but may not know each other. Ask your system administrator what groups are available to you. Three important, organized sources of interest groups are available to people who can exchange mail with the Internet: Internet mailing lists, BITNET LISTSERV, and USENET news. There is a lot of overlap between them. See Net Etiquette for some guidelines for using interest groups successfully. Each Internet mailing list has a moderator or coordinator. You must ask to be put on the list by sending an electronic mail message to the moderator. Internet mailing lists are not highly automated. The only problem is how to distinguish the moderator from the list. A list of Internet mailing lists (about five hundred kilobytes in size) is available by anonymous FTP from the Internet host nisc.sri.com at SRI International, Menlo Park, California. Use these commands: cd netinfo get interest-groups The interest-groups list is also available by electronic mail from the CSNET Info-Server. (The file will be split into messages of less than fifty kilobytes when sent to you.) Send a message to info-server@sh.cs.net with the following text: request: info topic: interest-groups BITNET LISTSERV is a highly automated program that automatically sends electronic mail messages and subscribes and unsubscribes users in response to formatted messages. LISTSERV programs run on many BITNET hosts. A subscribe message can be sent to any LISTSERV programÑit will be forwarded to the correct host. For a complete list of LISTSERV lists, send the command list global to any LISTSERV. Telnet is a program that allows a computer user at one site to work on a computer at another site. It is the Internet standard protocol for remote terminal connection service. Telnet requires Internet access (that is, you must be on a network that gateways to the Internet). Unlike FTP and electronic mail, telnet exposes you to the commands and programs of the remote host. For example, you can use the telnet command to run a program in your directory on a supercomputer hundreds of miles away. Remote LoginÑTelnet Telnet is a program that allows a computer user at one site to work on a computer at another site. It is the Internet standard protocol for remote terminal connection service. Telnet requires Internet access, that is, you must be on a TCP/IP network that gateways to the Internet. Unlike FTP and electronic mail, Telnet actually exposes you to the commands and programs of the remote host. For example, you can use the telnet command to run a program in your directory on a supercomputer hundreds of miles away. In most cases, the traveller must make arrangements beforehand to use telnet on a remote host. Some interactive programs allow any network traveller to log in with no password or a password that is advertised. Sometimes the password is "anonymous" and the password can be "guest." The type of activity allowed with anonymous telnet is restricted. Telnet Manual for UNIX This is the UNIX (see BSD) manual entry for telnet. telnet - user interface to the TELNET protocol Syntax: telnet [host[port]] The telnet interface is used to communicate with another host using the TELNET protocol. If telnet is invoked without arguments, it enters command mode, which is indicated by the prompt, telnet>. In this mode, telnet accepts and executes the commands listed below. If it is invoked with arguments, it performs an open command (see below) with those arguments. Once a connection is opened, telnet enters input mode. The input mode is either character-at-a-time or line-by-line, depending on what the remote system supports. In character-at-a-time mode, text is sent to the remote host as it is typed. In line-by-line mode, text is echoed locally and only completed lines are sent to the remote host. The local-echo-character, initially ^E. turns the local echo on and off, which is useful when you want to enter passwords without them echoing to the screen. In either mode, if the localchars toggle is true (the default in line mode), then the user's quit, intr, and flush characters are trapped locally and sent as TELNET protocol sequences to the remote side. Options such as toggle autoflush and toggle autosynch flush previous terminal input, as in quit and intr, in additon to flushing subsequent output to the terminal until the remote host acknowledges the TELNET sequence. To issue telnet commands when in input mode, precede them with the telnet escape character, initially the control character followed by a right bracket (^]). When in command mode, use the normal terminal editing conventions. The following commands are available: open host [ port ] Opens a connection to the named host. If the no port number is specified, telnet attempts to contact a TELNET server at the default port. The host specification may be either a host name or an Internet address specified in the dot notation. For further information, see hosts(5) and inet(3n). close Closes a TELNET session and returns to command mode. quit Closes any open TELNET session and exits telnet. z Suspends TELNET. This command only works when the user is using the csh(1). mode type The type is either line, for line-by-line mode, or character, for character-at-a-time mode. The local host asks the remote host for permission to go into one or the other mode. The remote host enters the requested mode if it is capable of it. status Shows the current status of telnet. This includes the peer one is connected to, as well as the state of debugging. display [ argument... ] Displays all, or some, of the set and toggle values (see below). ? [ command ] Accesses on-line help. With no arguments, telnet prints a help summary. If a command is specified, TELNET prints the help information for that command. send argument(s) Sends one or more special character sequences to the remote host. One or more of the following arguments can be specified: escape Sends the current telnet escape character (initially the control character followed by a right bracket, ^]). synch Sends the TELNET SYNCH sequence. This sequence causes the remote system to discard input that was previously entered but that it has not yet read. This sequence is sent as TCP urgent data and may not work if the remote system is a 4.2 BSD system. If it does not work, a lower case r may be echoed on the terminal screen. brk Sends the TELNET BRK (Break) sequence, which may have significance to the remote system. ip Sends the TELNET IP (Interrupt Process) sequence, which causes the remote system to abort the currently running process. ao Sends the TELNET AO (Abort Output)sequence, which causes the remote system to flush all output from the remote system to the user's terminal. ayt Sends the TELNET AYT (Are You There) sequence. The remote system may or may not respond. ec Sends the TELNET EC (Erase Character) sequence, which causes the remote system to erase the last character entered. el Sends the TELNET EL (Erase Line) sequence, which causes the remote system to erase the line currently being entered. ga Sends the TELNET GA (Go Ahead) sequence. Often this sequence has no significance to the remote system. nop Sends the TELNET NOP (No OPeration) sequence. ? Prints out help information for the send command. set argument value Sets a telnet variable to a specific value. The off value turns off the function associated with the variable. The current values of variables can be displayed with the display command. The following variables that can be specified: echo Toggles between local echoing of entered characters, and suppressing echoing of entered characters when in line-by-line mode. The value is initially ^E. escape Enters the telnet command mode when you are connected to a remote system. The value is initially the control character followed by a left bracket (^[). interrupt Sends a TELNET IP sequence (see send ip above) to the remote host if telnet is in localchars mode (see toggle localchars below) and the interrupt character is typed. The initial value for the interrupt character is the terminal's intr character. quit Sends a TELNET BRK sequence (see send brk above) to the remote host if telnet is in localchars mode (see toggle localchars below) and the quit character is yped. The initial value for the quit character is the terminal's quit character. flushoutput Sends a TELNET AO sequence (see send ao above) to the remote host if telnet is in localchars mode (see toggle localchars below) and the flushoutput character is typed. The initial value for the flush character is the terminal's flush character. erase Sends a TELNET EC sequence (see send ec above) to the remote system if telnet is in localchars mode (see toggle localchars below), and if telnet is operating in character-at-time mode. The initial value for the erase character is the terminal's erase character. kill Sends a TELNET EL sequence (see send el above) to the remote system if telnet is in localchars mode (see toggle localchars below) and if telnet is operating in character-at-a-time mode. The initial value for the kill character is the terminal's kill character. eof Sends this character to the remote system if telnet is operating in line-by-line mode and this character is entered as the first character on a line. The initial value of the eof character is the terminal's eof character. toggle arguments . . . Toggles (between true and false) flags that control how telnet responds to events. More than one argument may be specified and the current value of these flags can be displayed with the display command. Valid arguments for the toggle command are the following: localchars Causes the flush, interrupt, quit, erase, and kill characters to be recognized locally and transformed into appropriate TELNET control sequences if this flag is set to true. (See set above). The appropriate TELNET control sequences are: ao, ip, brk, ec, and el, respectively. For more information see the send command. The initial value for this toggle is true in line-by-line mode, and false in character at-a-time mode. autoflush Causes the telnet command to not display any data on the user's terminal until the remote system acknowledges (via a TELNET Timing Mark option) that it recognized and processed the following TELNET sequences: ao, intr, or quit. Both autoflush and localchars must be true for autoflush to work in this manner. The initial value for this toggle is true if the terminal user did not specify stty noflsh. Otherwise it is false. For further information, see stty(1). autosynch Causes the TELNET SYNCH sequence to follow the TELNET sequence that is initiated when either the intr or quit character is typed. The autosynch flag works in this manner when both the autosynch and localchars are true. This procedure should cause the remote system to begin throwing away all previously typed input until both of the TELNET sequences have been read and acted upon. The initial value of this toggle is false. crmod Toggles carriage return mode. When this mode is enabled, most carriage return characters received from the remote host are mapped into a carriage return followed by a line feed. It is useful only when the remote host sends carriage returns but never line feeds. The initial value for this toggle is False. debug Toggles socket level debugging which is useful only to the superuser. The initial value for this toggle is false. options Toggles the display of internal telnet protocol processing that deals with TELNET options. The initial value for this toggle is false. netdata Toggles the display of all network data (in hexadecimal format). The initial value for this toggle is false. ? Displays the legal toggle commands. Restrictions In line-by-line mode, the terminal's EOF character is only recognized and sent to the remote system when it is the first character on a line. Telnet --> Type telnet followed by the name of the host that you want to access. If the connection is successful, you will see a message to that effect from telnet, followed by the opening screen provided by the remote host, in this case the Boston University library catalog. WELCOME TO THE BOSTON UNIVERSITY LIBRARIES AND TO TOMUS THE ONLINE CATALOG --> You are now connected to the remote host, so you must use commands that are understood by that system. --> find author twain Your search:FIND AUTHOR TWAIN Items found:197 at ALL BOSTON UNIVERSITY LIBRARIES Press RETURN to see them, or type HELP, then press the key marked RETURN. -> Leave the remote host by using the host's quit command (in this case that command happens to be quit), or by using your system's telnet "escape" keys. You may have been told what this is when you first entered telnet (control-] may work). (End of sample session.) File Transfer ¥ File Transfer Protocol (FTP) ¥ Downloading Macintosh Files The File Transfer Protocol (FTP) is the Internet standard protocol for moving files from one computer to another. You can use the ftp command to copy computer files containing a variety of kinds of information, such as software, documentation, or maps. FTP is the name not only of the protocol, but usually also of the program the user invokes to execute it (e.g., by typing ftp host.bbn.com). FTP is available on several operating systems. File Transfer Protocol (FTP) Anonymous FTP, like Telnet, requires access to the Internet . Unlike Telnet, anonymous FTP is widely available. Anyone can become an Internet traveller by giving the command ftp host, for example, ftp cs.fredonia.edu. When the remote host prompts with login: and password: (or something similarÑdetails vary on different types of computers) the traveller types "anonymous" for the login name and "guest" for the password. After logging in, the traveller remains in a program with a restricted set of commands. Files on the remote host are usually protected so that visitors cannot change or delete them. Manual for FTP under UNIX This is the UNIX (see BSD) manual entry for ftp. ftp - file transfer program Syntax: ftp [-v] [-d] [-i] [-n] [-g] [host] The ftp command is the user interface to the ARPANET standard File Transfer Protocol. The program allows a user to transfer files to and from a remote network site. The client host with which ftp is to communicate may be specified on the command line. If the client host is specified on the command line, ftp immediately attempts to establish a connection to an FTP server on that host; otherwise, ftp enters its command interpreter and awaits instructions from the user. While ftp is awaiting commands from the user, it provides the user with the prompt: ftp>. The following commands are recognized by ftp: ! Invokes a shell on the local machine. $ macro-name [ args ] Executes the macro macro-name that was defined with the macdef command. Arguments are passed to the macro unglobbed. account [ passwd ] Supplies a supplemental password required by a remote system for access to resources once a login has been successfully completed. If no argument is included, the user is prompted for an account password in a non-echoing input mode. append local-file [ remote-file ] Appends a local file to a file on the remote machine. If remote-file is not specified, the local file name is used in naming the remote file. File transfer uses the current settings for type, format, mode, and structure. ascii Sets the file transfer type to network ASCII. This is the default type. bell Arranges for a bell to sound after each file transfer command is completed. binary Sets the file transfer type to support binary image transfer. bye Terminates the FTP session with the remote server and exits ftp. case Toggles the remote computer's file name case mapping during mget commands. When case is on (default is off), the remote computer's file names are written in the local directory with all letters in upper case mapped to lower case. cd remote-directory Changes the working directory on the remote machine to remote-directory. cdup Changes the remote machine working directory to the parent of the current remote machine working directory. close Terminates the FTP session with the remote server and returns to the command interpreter. cr Toggles the carriage return stripping during ascii type file retrieval. Records are denoted by a carriage return/linefeed sequence during ascii type file transfer. When cr is on (the default), carriage returns are stripped from this sequence to conform with the UNIX single linefeed record delimiter. Records on non-UNIX remote systems may contain single linefeeds; when an ascii type transfer is made, these linefeeds may be distinguished from a record delimiter only when cr is off. delete remote-file Deletes the file remote-file on the remote machine. debug [ debug-value ] Toggles the debugging mode. If an optional debug-value is specified, it is used to set the debugging level. When debugging is on, ftp prints each command sent to the remote machine, preceded by the string q-->. dir [ remote-directory ] [ local-file ] Prints a listing of the directory contents in the directory, remote directory, and, optionally, places the output in local file. If no directory is specified, the current working directory on the remote machine is used. If no local file is specified, output comes to the terminal. disconnect A synonym for close. form format Sets the file transfer form to format. The default format is file. get remote-file [ local-file ] Retrieves the remote-file and stores it on the local machine. If the local filename is not specified, it is given the same name it has on the remote machine. The current settings for type, form, mode, and structure are used while transferring the file. hash Toggles the hash-sign (#) printing for each data block transferred. The size of a data block is 1024 bytes. glob Toggles filename expansion for mdelete, mget, and mput. If globbing is turned off with glob, the file name arguments are taken literally and not expanded. Globbing for mput is done as in csh(1). For mdelete and mget, each remote filename is expanded separately on the remote machine and the lists are not merged. Expansion of a directory name is likely to be different from expansion of the name of an ordinary file. The exact result depends on the foreign operating system and ftp server, and can be previewed by entering: mls remote files. Neither mget nor mput is meant to transfer entire directory subtrees of files. That can be done by transferring a tar(1) archive of the subtree (in binary mode). lcd [ directory ] Changes the working directory on the local machine. If no directory is specified, the user's home directory is used. ls [ remote-directory ] [ local-file ] Prints an abbreviated listing of the contents of a directory on the remote machine. If remote-directory is left unspecified, the current working directory is used. If no local file is specified, the output is sent to the terminal. macdef macro-name Defines a macro. Subsequent lines are stored as the macro macro-name; a null line (consecutive newline characters in a file or carriage returns from the teminal) terminates macro input mode. There is a limit of 16 macros and 4096 total characters in all defined macros. Macros remain defined until a close command is executed. The macro processor interprets dollar signs ($) and backslashes (\) as special characters. A dollar sign ($) followed by a number (or numbers) is replaced by the corresponding argument on the macro invocation command line. A dollar sign ($) followed by an i signals the macro processor that the executing macro is to be looped. On the first pass, $i is replaced by the first argument on the macro invocation command line. On the second pass it is replaced by the second argument, and so on. A backslash (\) followed by any character is replaced by that character. Use the backslash (\) to prevent special treatment of the dollar sign ($). mdelete remote-files Deletes the specified files on the remote machine. If globbing is enabled, the specification of remote files will first be expanded using ls. mdir remote-files local-file Obtains a directory listing of multiple files on the remote machine and places the result in local-file. mget remote-files Retrieves the specified files from the remote machine and places them in the current local directory. If globbing is enabled, the specification of remote files will first be expanding using ls. mkdir directory-name Makes a directory on the remote machine. mls remote-files local-file Obtains an abbreviated listing of multiple files on the remote machine and places the result in local-file. mode [ mode-name ] Sets the file transfer mode to mode name. The default mode is the stream mode. mput local-files Transfers multiple local files from the current local directory to the current working directory on the remote machine. nmap [ inpattern outpattern ] Sets or unsets the filename mapping mechanism. If no arguments are specified, the filename mapping mechanism is unset. If arguments are specified, remote filenames are mapped during mput commands and put commands which are issued without a specified remote target filename. If arguments are specified, local filenames are mapped during mget commands and get commands which are issued without a specified local target filename. This command is useful when connecting to a non-UNIX remote computer with different file naming conventions or practices. The mapping follows the pattern set by inpattern and outpattern. Inpattern is a template for incoming filenames (which may have already been processed according to the ntrans and case settings). Variable templating is accomplished by including the sequences $1, $2, ..., $9 in inpattern. Use a backslash (\) to prevent this special treatment of the dollar sign ($) character. All other characters are treated literally, and are used to determine the nmap inpattern variable values. For example, given inpattern $1.$2 and the remote file name mydata.data, $1 has the value mydata, and $2 has the value data. The outpattern determines the resulting mapped filename. The sequences $1, $2, ...., $9 are replaced by any value resulting from the inpattern template. The sequence $0 is replace by the origi nal filename. Additionally, the sequence [seq1,seq2] is replaced by seq1 if seq1 is not a null string; otherwise it is replaced by seq2. For example, the command nmap $1.$2.$3 [$1,$2].[$2,file] yields the output filename myfile.data for input filenames myfile.data and myfile.data.old, myfile.file for the input filename myfile, and myfile.myfile for the input filename .myfile. Spaces may be included in outpattern, as in the exam ple: nmap $1 |sed "s/ *$//" > $1 . Use the backslash (\) to prevent special treatment of the dollar sign ($), left bracket ([), right bracket (]), and comma (,). ntrans [ inchars [ outchars ] ] Sets or unsets the filename character translation mechanism. If no arguments are specified, the filename character translation mechanism is unset. If arguments are specified, characters in remote filenames are translated during mput commands and put commands which are issued without a specified remote target filename. If arguments are specified, characters in local filenames are translated during mget commands and get commands which are issued without a specified local target filename. This command is useful when connecting to a non-UNIX remote computer with different file naming conventions or prac tices. Characters in a filename match ing a character in inchars are replaced with the corresponding character in outchars. If the character's position in inchars is longer than the length of outchars, the character is deleted from the file name. open host [ port ] Establishes a connection to the speci fied host FTP server. If an optional port number is supplied, ftp attempts to contact an FTP server at that port. If the auto-login option is on (default), ftp automatically attempts to log the user in to the FTP server (see below). prompt Toggles interactive prompting. Interactive prompting occurs during multiple file transfers to allow the user to retrieve or store files selectively. If prompting is turned off (default), any mget or mput transfers all files. proxy ftp-command Executes an ftp command on a secondary control connection. This command allows simultaneous connection to two remote ftp servers for transferring files between the two servers. The first proxy command should be an open, to establish the secondary control connection. Type the command proxy? to see other ftp commands executable on the secondary connection. The following commands behave differently when prefaced by proxy: open will not define new macros during the auto-login process close will not erase existing macro definitions get and mget transfer files from the host on the primary control connection to the host on the secondary control connection put, mput, and append transfer files from the host on the secondary control connection to the host on the primary control connection. Third party file transfers depend upon support of the ftp protocol PASV command by the server on the secondary control connection. put local-file [ remote-file ] Stores a local file on the remote machine. If remote-file is unspecified, the local file name is used in naming the remote file. File transfer uses the current settings for type, format, mode, and structure. pwd Prints the name of the current working directory on the remote machine. quit A synonym for bye. quote arg1 arg2 ... Sends the arguments that are specified, verbatim, to the remote FTP server. A single FTP reply code is expected in return. recv remote-file [ local-file ] A synonym for get. remotehelp [ command-name ] Requests help from the remote FTP server. If a command-name is specified it is supplied to the server as well. rename [ from ] [ to ] Renames the file from on the remote machine, to the file to. reset Clears the reply queue. This command re-synchronizes command/reply sequencing with the remote ftp server. If the remote server violates the ftp protocol, resynchronization may be neccesary. rmdir directory-name Deletes a directory on the remote machine. runique Toggles storing of files on the local system with unique filenames. If a file already exists with a name equal to the target local filename for a get or mget command, a .1 is appended to the name. If the resulting name matches another existing file, a .2 is appended to the original name. If this process contin ues up to .99, an error message is printed, and the transfer does not take place. The generated unique filename will be reported. Note that runique will not affect local files generated from a shell command (see below). The default value is off. send local-file [ remote-file ] A synonym for put. sendport Toggles the use of PORT commands. By default, ftp attempts to use a PORT com mand when establishing a connection for each data transfer. If the PORT command fails, ftp uses the default data port. When the use of PORT commands is disabled, no attempt is made to use PORT commands for each data transfer. This is useful for certain FTP implementations which do ignore PORT commands but, incorrectly, indicate that they have been accepted. status Shows the current status of ftp. struct [ struct-name ] Sets the file transfer structure to struct-name. By default stream structure is used. sunique Toggles storing of files on a remote machine under unique file names. The remote ftp server must support the ftp protocol STOU command for successful completion of this command. The remote server reports the unique name. Default value is off. tenex Sets the file transfer type to that needed to talk to TENEX machines. trace Toggles packet tracing. type [ type-name ] Sets the file transfer type to type name. If no type is specified, the current type is printed. The default type is network ASCII. user user-name [ password ] [ account ] Identifies the user to the remote FTP server. If the password is not specified and the server requires it, ftp disables the local echo and then prompts the user for it. If an account field is not specified, and the FTP server requires it, the user is prompted for it also. Unless ftp is invoked with auto login disabled, this process is done automatically on initial connection to the FTP server. verbose Toggles the verbose mode. In verbose mode, all responses from the FTP server are displayed to the user. In addition, if verbose is on, statistics regarding the efficiency of a file transfer are reported when the transfer is complete. By default, verbose is on. ? [ command ] A synonym for help. Command arguments which have embedded spaces may be quoted with quotation (") marks. Aborting a file transfer To abort a file transfer, use the terminal interrupt key (usually ). Sending transfers are halted immediately. Receiving transfers are halted by sending a ftp protocol ABOR command to the remote server, and discarding any further data received. The speed at which this is accomplished depends upon the remote server's support for ABOR processing. If the remote server does not support the ABOR command, an ftp> prompt appears when the remote server has completed sending the requested file. The terminal interrupt key sequence is ignored when ftp has completed any local processing and is awaiting a reply from the remote server. A long delay in this mode may result from ABOR processing, or from unexpected behavior by the remote server, including violations of the ftp protocol. If the delay results from unexpected remote server behavior, the local ftp program must be killed by hand. File-naming conventions Files specified as arguments to ftp commands are processed according to the following rules: 1) Standard input is used for reading and standard output is used for writing when the file name is specified by an en dash (-). 2) If the first character of the file name is a vertical line (|), the remainder of the argument is interpreted as a shell command. The ftp command then forks a shell, using popen(3) with the argument supplied, and reads (writes) from the stdout (stdin). If the shell command includes spaces, the argument must be quoted, as in ""| ls -lt"". A particularly useful example of this mechan ism is: "dir |more". 3) If globbing is enabled, local file names are expanded according to the rules used in the csh(1) (compare to the glob command). If the ftp command expects a single local file, such as put, only the first filename gen erated by the globbing operation is used. 4) For mget commands and get commands with unspecified local file names, the local filename is the remote filename and can be altered by a case, ntrans, or nmap setting. The resulting filename may then be altered if runique is on. 5) For mput commands and put commands with unspecified remote file names, the remote filename is the local filename and may be altered by a ntrans or nmap setting. The resulting filename can then be altered by the remote server if sunique is on. File transfer parameters Many parameters can affect a file transfer. The type can be ascii, image (binary), ebcdic, or local byte size (for PDP10's and PDP-20's generally). The ftp command supports the ascii and image types of file transfer and local byte size 8 for tenex mode transfers. The ftp command supports only the default values for the remaining file transfer parameters: mode, form, and struct. The .netrc file The .netrc file contains login and initialization information used by the auto-login process. It resides in the user's home directory. The following tokens are recognized; they may be separated by spaces, tabs, or new-lines: machine name Identifies a remote machine name. The auto-login process searches the .netrc file for a machine token that matches the remote machine specified on the ftp command line or as an open command argu ment. Once a match is made, the subse quent .netrc tokens are processed, stop ping when the end of file is reached or another machine token is encountered. login name Identifies a user on the remote machine. If this token is present, the auto-login process initiates a login using the specified name. password string Supplies a password. If this token is present, the auto-login process supplies the specified string if the remote server requires a password as part of the login process. Note that if this token is present in the .netrc file, and if the .netrc is readable by anyone other than the user, ftp aborts the auto-login process. account string Supplies an additional account password. When this token is present, the auto login process supplies the the remote server with an additional account pass word if the remote server requires it. If it does not, the auto-login process initiates an ACCT command. macdef name Defines a macro. This token functions like the ftp macdef command. A macro is defined with a specified name; its con tents begin with the next .netrc line and continue until a null line (consecu tive new-line characters) is encoun tered. If a macro named init is defined, it is automatically executed as the last step in the auto-login process. Options -d Enables debugging. -g Disables file name expansion. -i Disables interactive prompting during multiple file transfers. -n Disables autologin during an initial connection. If auto-login is enabled, ftp will check the .netrc file in the user's home directory for an entry describing an account on the remote machine. If no entry exists, ftp will use the login name on the local machine as the user identity on the remote machine, prompt for a password and, optionally, an account with which to login. -v Displays all responses from the remote server as well as all data transfer statistics. Restrictions Correct execution of many commands depends on proper behavior by the remote server. An error in the treatment of carriage returns in the 4.2BSD UNIX ascii-mode transfer code has been corrected. This correction may result in incorrect transfers of binary files to and from 4.2BSD servers using the ascii type. Avoid this problem by using the binary image type. FTP --> Type ftp followed by the address of the host you want to access. The ftp program will respond with a message. If the connection was successful, you will see a response like the one above. (Click the arrow to continue. --> ftp nic.near.net Connected to nic.near.net. 220 nic.near.net FTP server ready. Then you will normally be prompted to give a name and a password. If the system allows anonymous ftp, the name will often be "anonymous" and the password may be "guest" or you may be asked to use your username as a password. Again you will get a response. (Click the arrow to continue.) The "list" command (ls) causes the remote computer to print a list of available subdirectories and files. Below is an exercise that will show you how to change directories and transfer a file from a subdirectory. The commands you will type are printed in bold italics. ftp> After you are logged in, you can issue a few commands, such as ls to list the contents of the current directory. (Click the arrow to continue.) The "list" command (ls) causes the remote computer to print a list of available subdirectories and files. Below is an exercise that will show you how to change directories and transfer a file from a subdirectory. The commands you will type are printed in bold italics. ftp> To see the ftp commands available to you, type ? at the "ftp>" prompt. (The list of commands shown here is incomplete.) The "list" command (ls) causes the remote computer to print a list of available subdirectories and files. Below is an exercise that will show you how to change directories and transfer a file from a subdirectory. The commands you will type are printed in bold italics. ftp> Type the "status" command to check your file type. The "list" command (ls) causes the remote computer to print a list of available subdirectories and files. Below is an exercise that will show you how to change directories and transfer a file from a subdirectory. The commands you will type are printed in bold italics. ftp> To ftp text files, including files that end in ".txt" or ".ps", your file type should be ASCII. This is the default. (The ASCII setting is the same as TEXT.) (Click the arrow to continue.) The "list" command (ls) causes the remote computer to print a list of available subdirectories and files. Below is an exercise that will show you how to change directories and transfer a file from a subdirectory. The commands you will type are printed in bold italics. ftp> If you intened to ftp non-ascii files, including compressed files that end in ".Z" or object files, set your file type to binary. The "binary" setting is the same as "image." (Click the arrow to continue.) ftp> The cd command is used to change directories on the remote host. ftp> cd info-sources 250 CWD command successful. The get command is used to copy a file from the remote host to your system. Type get and the name of the file you want. You will be told when the transfer is complete. ftp> cd info-sources 250 CWD command successful. ftp> get README PORT command successful. 150 Opening ASCII mode data connection for README (1042 bytes). 226 Transfer complete. 1071 bytes received in 0.02 seconds (52 Kbytes/s). ftp> Leave ftp and close the connection by typing quit at the ftp prompt. (End of sample session.) Downloading Over the Internet you can reach archives of Macintosh files. You can get Macintosh files such as HyperCard stacks, tools, fonts, games, tips, desk accessories, cdevs, inits, demos, and applications from these archives. Before the files can be run on your Macintosh, you must ftp them and then process them. Here is a general description of how to get files from an archive to your Mac. See your system administrator or ask a Macintosh user group for more information. In summary, there are generally five steps to pulling files from Macintosh archives: 1. Transfer to your computer with ftp (using a text-only option). 2. If necessary, combine the parts. 3. Transfer to your Macintosh. 4. Run BinHex 4.0 and/or StuffIt to convert the .hqx files into either Macintosh files or compressed Macintosh files (or use a Unix program such as mcvert or xbin before transferring the file to your Macintosh.) 5. If a file is compressed, use the appropriate decompression program (usually StuffIt, or UnStuffIt) to decompress it. Step 1, ftp First, ftp to a site that has Macintosh files, such as rascal.ics.utexas.edu or the info-mac directory at sumex- aim.stanford.edu. (Note that sumex may not be available for anonymous ftp during west coast business hours.) On sumex, use the account name "anonymous" (lower-case) and enter any password. Type ls to see a list of directories, and type cd to a directory of Macintosh files. (on sumex, type cd info-mac). Type ls again to see a list of subdirectories, and type cd with the name of a subdirectory that interests you. Type ls again to see the filenames. Choose a file and ftp it (using ftp's get [filename] commandÑwith a statement like get disinfectant.hqx). An ftp transfer using a text-only option should work, since the files are normally in text format. Step 2 Some files are large and have been split into smaller pieces so that they can be more easily mailed. You must join them together. hqx files can be edited as text; therefore, you can use any word processor or the append command on your host to stitch the pieces together. There are some files in the info-mac/util directory on sumex that do this step for you (unity and united). Step 3 or 4, decode binhex file Most files are stored in BinHex 4.0 (text) format. The common practice is to label such files with .hqx extensions. To take these files and use them on your Macintosh, you must first run them through a program that will convert them from .hqx format. On Unix systems, you can use the mcvert program, stored as /unix/mcvert.shar. You can also do the conversion on your Macintosh after you transfer the file. On the Mac, use either BinHex 4.0 or StuffIt. In Stuffit, choose "Decode Binhex file" from the "Other" menu. Ask your system administrator what is the best method to use on your system. Step 3 or 4, transfer the file to your Macintosh Ask your system adminstrator what method you should use to do thisÑ such as kermit or ftp. Step 5, unstuffing Many files have been compressed to save space. You will know they have been compressed when the filename (after converting to Macintosh format) ends with a .sit, .cpt, .sea, or .pit extension. You should use StuffIt (or Unstuffit) to convert .sit and .pit compressed files into uncompressed Macintosh files. (With .pit files you need to set a special StuffIt option to decompress them, since they are not in the usual StuffIt format.) The other types, .cpt and .sea, are becoming increasingly common as Compactor gains in popularity. Both Compactor and Stuffit are in the /util directory on info/mac. In Stuffit, the name of the file you clicked on will appear in a window. Select it and then click extract at the bottom of the screen. Then select the new file(s) that appear in the window, and click the Save All button on the right. Stuffit will create the new file(s) (while preserving the stuffed .sit file). These are some of the kinds of resources available on the Internet. ¥ INTERNET RESOURCE GUIDE ¥ COMPUTING CENTERS ¥ LIBRARY CATALOGS ¥ DATA ARCHIVES ¥ WHITE PAGES ¥ MISCELLANEOUS Internet Resources These are some of the kinds of resources available on the Internet. ¥ INTERNET RESOURCE GUIDE ¥ COMPUTING CENTERS ¥ LIBRARY CATALOGS ¥ DATA ARCHIVES ¥ WHITE PAGES ¥ MISCELLANEOUS Internet Resource Guide The Internet Resource Guide is an online book that describes many services available on the Internet. You can transfer the resource guide via ftp from the subdirectory info-sources on the machine nnsc.nsf.net (see the next card). The IRG is also distributed electronically by the NSF Network Service Center (NNSC). If you wish to receive additions to the IRG in electronic mail messages, send a note to resource-guide- request@nnsc.nsf.net, and specify whether you would like them in PostScript format, text format, or whether you want to receive notices that additions are available for ftp. Internet Resource Guide How to Get and Use the Internet Resource Guide To get The Internet Resource Guide over the Internet, use the command ftp nnsc.nsf.net and then cd resource-guide. The resource-guide directory hierarchy is organized by chapter and section. Each chapter has its own subdirectory (resource- guide/chapter.#), and each section has two files in that directory, one for PostScript (section#-#.ps) and one for plain text (section#-#.txt). So, to retrieve section 1 of chapter 1, you should ftp the files: resource-guide/chapter.1/section1-1.ps (Postscript) resource-guide/chapter.1/section1-1.txt (Text) To simplify retrieval of entire chapters and chapter updates, or of the entire IRG, you can ftp compressed tar files. These include a the entire guide in text format (resource-guide-txt.tar.Z), in PostScript format (resource-guide-ps.tar.Z), or as a plain text file (wholeguide.txt). There are also files of individual chapters in both formats. The most recent changes to a chapter are in a file named chapter#-changes.tar.Z. These include Postscript and text versions of the most recently updated sections. resource-guide/chapter1-changes.tar.Z Nitty-Gritty Information about PostScript, ftp, Compress, and tar files. A Note about PostScript Documents PostScript is a formatting language used to prepare documents for printing on advanced printers such as Apple LaserWriters. PostScript files contain ASCII characters only, but are virtually unreadable because the text of the document is interspersed with numerous formatting commands and numeric symbols for printers' characters that are not part of the ASCII character set. Do not attempt to print PostScript files unless you have a printer that is specifically designed for PostScript. How to Use the ftp Command You can ftp the resource guide files from nnsc.nsf.net with a standard anonymous ftp connection: ftp nnsc.nsf.net You will see a "banner" and be promted for your login: Connected to nnsc.nsf.net. 220 nnsc.nsf.net FTP server (Version 5.59 Mon May 14 13:48:21 EDT 1990) ready. Name (nnsc.nsf.net:yourname): You should type anonymous, and then use the password guest. The password will not be displayed on your terminal. Name (nnsc.nsf.net:name): anonymous Password (nnsc.nsf.net:anonymous): 331 Guest login ok, send ident as password. 230 Guest login ok, access restrictions apply. ftp> 3) Change directory to the "resource-guide" directory: ftp> cd resource-guide 4) To get a listing of the files in the resource-guide directory, give the "dir" command (usually equivlent to the "ls" command on Unix systems). ftp> dir * ... chapter.1/section1-1.ps etc. section1-1.ps is in the chapter.1 directory. Use the "cd" command again. ftp> cd chapter.1 How to Uncompress and Extract the tar.Z Files Do not attempt to use the tar.Z files unless you have the Unix "compress" and "uncompress" commands and the "tar" command on your host computer, and your operating system is compatible with Berkeley Unix. 1) Use the "uncompress" command to replace the compressed "Z" file with a copy of the file as it was before "compress" was used: uncompress -v chapter1-ps.tar.Z chapter1-ps.tar.Z: -- replaced with chapter1.tar The result is "chapter1-ps.tar". 2) Use tar -xvf to replace the tar file with the set of directories and files in the original file. tar -xvf chapter1.tar x copyright.ps, 5931 bytes, 12 tape blocks x copyright.txt, 945 bytes, 2 tape blocks etc. ... This creates a new directory, chapter.1, with the files: copyright.ps copyright.txt intro.ps intro.txt section1-1.ps section1-1.txt etc. ... Then you throw away the files you don't wantÑeither the ".ps" files or the ".txt" files Ñand print the files that remain. For more information about the action of these commands, consult the manual for your Unix system, or give the commands "man compress" and "man tar" for online documentation. Computational resources are centers or machines that serve users who have special computing requirements. A good example of such a resource is a supercomputer center. Air Force Supercomputer Center at Kirtland AFB Arizona: University of Arizona Supercomputing Center BRL: US Army Ballistic Research Laboratory Berkeley: University of California Information Systems and Technology Calgary: SuperComputing Services, The University of Calgary CERPASS: Center for Experimental Research in Parallel Algorithms, Software and Systems Cornell National Supercomputer Facility: Center for Theory and Simulation in Science and Engineering NCAR: National Center for Atmospheric Research NCSA: National Center for Supercomputing Applications NCSC: North Carolina Supercomputing Center NERSC: National Energy Research Supercomputer Center NPAC: Northeast Parallel Architectures Center OSC: Ohio Supercomputer Center PSC: Pittsburgh Supercomputing Center SDSC: San Diego Supercomputer Center Texas: University of Texas System Center for High Performance Computing UCLA Office of Academic Computing Air Force: consulting@ddnvx1.afwl.af.mil Cornell: psfy@cornellf.tn.cornell.edu NCAR: scdinfo@ncar.ucar.edu UCLA: calloac@oac.ucla.edu Arizona: kgrmc@asuacad.bitnet or kgbat@asuacad.bitnet NCSC: info@flyer.ncsc.edu Texas: g.smith@chpc.utexas.edu CERPASS: cerpass@isi.edu Calgary: super@uncacdc.bitnet Berkeley: consult@cmsa.berkeley.edu (CMS) or consult@lynx.berkeley.edu (Cray) BRL: crimmins@brl.mil SDSC: consultant@sdsc.edu NCSA: consult@ncsaa.ncsa.uiuc.edu NERSC: consultant@nersc.gov NPAC: npac@nova.npac.syr.edu OSC: oschelp@osc.edu PSC: consult@a.psc.edu Computing Centers Many libraries allow access to their catalogs via the Internet. Such catalogs can be useful for finding books not available at a local library or to check citations or references. Some catalogs also support more extended reference facilities. Please note that online catalogs often have a limited number of ports; users are asked not to abuse their access. ARLO, The Library Catalog for the University of Colorado at Colorado Springs Boston University (TOMUS) Univ. California and California St. (MELVYL) Cleveland Public Library Catalog Colorado Alliance of Research Libraries Emory University Libraries Online Public Access Catalog Florida Center for Library Automation HOLLIS: Harvard Online Library Automation System U. Illinois at Chicago NOTIS/LUIS Info-Lib InfoTrax MAGICÑMichigan State University Libraries MIRLYN, The University of Michigan's Online Catalog Northwestern University LUIS Online Catalog Research Libraries Information Network (RLIN) U. New Mexico Gateway Penn State University Library Information and Access System (LIAS) U. Pennsylvania Libraries URSUS, University of Maine System Library Catalog U. Utah Library Card Catalog System U. Wisconsin Madison and Milwaukee Campuses Network Library System (NLS) Boston University (TOMUS) library.bu.edu (128.197.4.200) California (MELVYL) melvyl.ucop.edu (31.1.0.1) RLIN rlg.stanford.edu (36.54.0.18) Colorado pac.carl.org (192.54.81.128) Florida nervm.nerdcufl.edu MIRLYN, U. Michigan cts.merit.edu (35.1.1.6) New Mexico bootes.unm.edu (129.24.8.2) Emory University Libraries emuvm1.cc.emory.edu (128.140.1.4) MAGIC: merit.msu.edu (35.8.2.56) or magic.msu.edu (35.8.2.99) Info-Lib: umd5.umd.edu InfoTrax: infotrax.rpi.edu (128.113.1.31) ARLO: arlo.colorado.edu (128.198.26.129) Pennsylvania: pennlib.upenn.edu Wisconsin: nls.adp.wisc.edu (128.104.198.20) U. Utah: lib.utah.edu NW: pacx.acns.nwu.edu (129.105.49.2) URSUS: ursus.maine.edu (130.111.64.1) Cleveland: clevxe.cpl.org U. Illinois: uicvm.uic.edu (128.248.2.50) Penn State: lias.psu.edu (128.118.25.13) HOLLIS: hollis.harvard.edu (128.103.60.31) Data Archives The Internet is home to a wide variety of data archives. In this section we try to list the more important and the more uncommon archives. In particular, we do not list archives of mailing lists, other than those that do software distributions. Such archives can be located by asking the maintainers of the mailing lists. Archie Archive Server Listing Service COSMIC Dartmouth Dante Database Gene-Server IBM Supercomputing Program Data Base INFO-SOUTH Latin American Information System IuBio Archive for Molecular and General Biology LiMB (Listing of Molecular Biology Databases) Matrix of Biological Knowledge Archive-Server MBCRR: The Molecular Biology Computer Research Resource MEMDB: Medieval and Early Modern Data Bank University of North Carolina at Chapel Hill INFO Service NED (NASA/IPAC Extragalactic Database) NETLIB Mathematical Software Distribution System PENpages SDDAS: Southwest Research Data Display & Analysis System SERVICE Mail ServerÑDDN NIC SIMBAD SIMTEL20 Software Archives Unidata weather data program VxWorks Users Group Archive Washington University Public Domain Archives Gene Server: email "SEND HELP" to: genbank-server@uhnix2.uh.edu, Molecular Biology Databases: limb@lanl.gov SIMBAD: simbad@cfa.harvard.edu SIMTEL20 : 26.2.0.74 SDDAS: espsun.space.swri.edu Wash.: wuarchive.wustl.edu (128.252.135.4) Matrix: email "SEND HELP" to: genbank-server@uhnix2.uh.edu, COSMIC: e-mail to: cosnic@uga.bitnet or service@cossack.cosmic.uga.edu IUBIO Biology Archive: iubio.bio.indiana.edu PENpages: psupen.psu.edu (128.118.36.5) Dante: eleazar.dartmouth.edu (129.170.16.2) MEMDB: 4212001@rutmvs1.rutgers.edu NETLIB: netlib@mcs.anl.gov VxWorks: thor.atd.ucar.edu (128.117.81.51) IBM: send mail to: listserv@uicvm.cc.uic.edu, containing "get supersft help" SERVICE: e-mail to service@nic.ddn.mil with "HELP" in subject line Unidata: unidata.ucar.edu Archie: quiche.cs.mcgill.ca (132.206.3.30) login as archie. MBCRR: mbcrr.harvard.edu NED: ipac.caltech.edu Chapel Hill INFO: info.acs.unc.edu username: info INFO-SOUTH: sabio.ir.miami.edu (129.171.32.26) White Pages The Internet supports several databases that contain basic information about users, such as e-mail addresses, telephone numbers, and postal addresses. These databases can be searched to get information about particular individuals. Because they serve a function akin to the telephone book, these databases are often referred to as "white pages." (The names of the resources are followed by the addresses to use for remote login.) NASA Ames Research Center Electronic Phone Book DDN Network Information Center WHOIS Service NYSERNet/PSI White Pages Pilot Project CREN/CSNET User Name Server "ns" Knowbot Information Service This section lists diverse Internet resources that defy better categorization. Chiron: Linotype Postscript Typesetter CIAC (Department of Energy Computer Incident Advisory Capability) FASTÑA Computer Network Broker for Standard Electronic Parts Geographic Name Server MOSIS Chip Fabrication Server Nest - A Network Simulation Testbed PROPHET Vax Book Chiron: joe@wjh12.harvard.edu CIAC: email to ciac@tiger.llnl.gov or ciac@lll-crg.llnl.gov Geographic: martini.eecs.umich.edu Nest: columbia.edu (10.3.0.89) PROPHET: e-mail to prophet-help@bbn.com FAST: e-mail "REQUEST: INFORMATION TOPIC: INTRODUCTION REQUEST: END" to fast@isi.edu Vax Book decoy.uoregon.edu (128.223.32.19) MOSIS: e-mail to: mosis@mosis.edu Miscellaneous Resources This section lists diverse Internet resources that defied better categorization. Chiron: Linotype Postscript Typesetter Department of Energy Computer Incident Advisory Capability (CIAC) Geographic Name Server port 3000 on martini.eecs.umich.edu MOSIS Chip Fabrication Server Nest - A Network Simulation Testbed columbia.edu (10.3.0.89) PROPHET FAST - A Computer Network Broker for Standard Electronic Parts Vax Book DECOY.UOREGON.EDU (128.223.32.19) These are information centers (NICs) for networks in the Internet and outside it. ¥ BITNET NIC ¥ CREN/CSNET CIC ¥ DDN NIC (Defense Data Net NIC) ¥ NNSC (NSF Network Service Center) ¥ OCEANIC ¥ SPAN NIC Geographic: martini.eecs.umich.edu Nest: columbia.edu (10.3.0.89) Vax Book decoy.uoregon.edu (128.223.32.19) Network Information Centers Miscellaneous Resources This section lists diverse Internet resources that defied better categorization. Chiron: Linotype Postscript Typesetter Department of Energy Computer Incident Advisory Capability (CIAC) Geographic Name Server port 3000 on martini.eecs.umich.edu MOSIS Chip Fabrication Server Nest - A Network Simulation Testbed columbia.edu (10.3.0.89) PROPHET FAST - A Computer Network Broker for Standard Electronic Parts Vax Book DECOY.UOREGON.EDU (128.223.32.19) BITNET Information Center BITNIC provides and coordinates user support, information, and administrative services for BITNET, including: ¥ BITNEWS, an electronically distributed newsletter. ¥ On-line BITNET documentation accessible via LIST-SERV and NETSERV server. ¥ On-line and telephone assistance for campus BITNET support staff and organizations seeking BITNET membership. Network Access: Subscribe to BITNEWS by sending electronic mail to LISTSERV@BITNIC (on BITNET) with any subject and the text: SUBSCRIBE BITNEWS your- name Obtain a list of files available by sending mail with any subject and the text: SENDME NETINFO INDEX Order a file by sending mail with any subject and the text SENDME filename filetype using the filename and filetype of the file as shown in NETINFO INDEX. Address: BITNET Network Information Center EDUCOM Suite 600 1112 Sixteenth Street, NW Washington, DC 20036 Email: bitnet@bitnic (on BITNET) bitnet%bitnic@cunyvm.cuny.edu (on Internet) Phone: (202) 872-4200 Who Can Use the BITNET The BITNIC services are supported by dues from the BITNET member organizations, and their primary purpose is to assist BITNET members. The on-line newsletter and files are, however, available to all who can access BITNET with electronic mail. CREN/CSNET CIC The CREN/CSNET Coordination and Information Center provides technical and information support for members of CREN/CSNET. The CIC staff also maintains the following automated services, which can be accessed by electronic mail from CSNET hosts, and also from all other hosts that can exchange mail with the Internet. The Info-Server: info-server@sh.cs.net This automatic program distributes documents in response to specially formatted messages. Info documents are also available to Internet users through standard anonymous ftp login. For instructions about this and other services, send a message to info- server@sh.cs.net with "HELP" in the body of the message. Email/ftp: info-server@sh.cs.net Provides file transfer service to hosts that do not have access to the Internet. (In beta test.) Status: info-server@sh.cs.net The status report on the availability of exceptional CSNET systems can be retrieved from the Info-Server. The User Name Server: registrar@sh.cs.net This is a central database containing information about CSNET sites and users, which is maintained on the CIC Service Host, sh.cs.net. Users on other sites may send specially formatted messages by electronic mail, or may access the User Name Server by dial-up modem on (617) 491-2777. Internet users may telnet to sh.cs.net and log on as ns, no password required. Fixaddr: fixaddr@relay.cs.net (or fixaddr@sh.cs.net) This program is a helpful first step in converting mailing lists to up- to-date domain-style addresses. Send a message with a mailing list in the body of the message. The list should contain one address per line, in the form "user@domain", for example, "groucho@cs.fredonia.edu". Fixaddr will convert nicknames into official names. It checks both the DDN NIC host table, and the Internet domain servers, using the MX option for off-Internet hosts. It knows about non-domain-style names that have disappeared from the NIC table. Nslookup: nslookup@sh.cs.net For hosts that do not have access to domain servers. Send a message with domain names or IP addresses, one per line, in the body of the message. The nslookup program sends back a message containing all the domain nameserver records (not just the MX ones) for the named domains. Network Access Unlimited Address: CREN/CSNET Coordination and Information Center (CIC) BBN 10 Moulton Street Cambridge MA 02138 Email: cic@sh.cs.net Phone: (617) 873-2777 Who Can Use the Resource/Restrictions Open to all Internet users. Miscellaneous Information Karen Roubicek, Manager Charlotte Mooers, User Services DDN Information Center The DDN Network Information Center (NIC) assists Defense Data Network (DDN) users and potential subscribers in obtaining information about the DDN and the Internet. The NIC provides the following databases and information servers: ¥ WHOIS registry of users, hosts, domains, and networks ¥ NIC/QUERY browsing system ¥ TACNEWS server ¥ SERVICE electronic mail server The NIC provides host name translation tables, maintains domain system server files, assigns IP network numbers and autonomous system numbers, registers network users, and issues MILNET TAC access cards. The NIC is the site of the DDN Security Coordination Center (SCC). The NIC is also the source of DDN documents and the complete Internet Request For Comments (RFC) series and index. The NIC maintains a toll-free hotline from 6:00 a.m. to 5:00 p.m. (Pacific time) at 1-800-235-3155 or (415) 859-3695. Users experiencing problems with TAC login, or who have requests for NIC services, are encouraged to call. The NIC has numerous publicly accessible information files available in the following public directories: ¥ NETINFO: ¥ RFC: PROTOCOLS: ¥ SCC: ¥ IEN: ¥ DDN-NEWS: Each directory has an index. Files are available for anonymous ftp and, in most cases, are accessible via the automatic mail server SERVICE@NIC.DDN.MIL. The NIC shadows IETF information in the publicly accessible IETF: and INTERNET-DRAFTS: directories. Network Access ¥ FTP to nic.ddn.mil (192.67.67.20) to retrieve NIC files. ¥ Telnet to nic.ddn.mil to use servers or run WHOIS program. ¥ Send electronic mail to service@nic.ddn.mil to receive information via the mail server. ¥ By user Kermit server to retrieve NIC files Address: SRI International Network Information Systems Center Room EJ291 333 Ravenswood Avenue Menlo Park, CA 94015 E-mail: nic@noc.ddn.mil (for general user questions or document requests) Phone: 1-800-235-3155 or (415) 859-3695 Who Can Use the DDN NIC All services are available to users of the DDN. Many services are available to Internet users. Some services are available via electronic mail to users of networks that gateway to the Internet. Miscellaneous Information NIC role mailboxes for further assistance: NIC@NIC.DDN.MIL General user assistance and document requests REGISTRAR@NIC.DDN.MIL User registration and WHOIS updates HOSTMASTER@NIC.DDN.MIL Host, domain, network changes and updates SCC@NIC.DDN.MIL DDN network security information ACTION@NIC.DDN.MIL NIC computer operations SUGGESTIONS@NIC.DDN.MIL Comments on NIC services and publications SERVICE@NIC.DDN.MIL Automatic mail service Who Can Use the DDN NIC All services are available to users of the DDN. Many services are available to Internet users. Some services are available via electronic mail to users of networks that gateway to the Internet. Miscellaneous Information NIC role mailboxes for further assistance: nic@nic.ddn.mil General user assistance and document requests registrar@nic.ddn.mil User registration and WHOIS updates hostmaster@nic.ddn.mil Host, domain, network changes and updates scc@nic.ddn.mil DDN network security information action@nic.ddn.mil NIC computer operations suggestions@nic.ddn.mil Comments on NIC services and publications service@nic.ddn.mil Automatic mail service NNSC The NSF Network Service Center provides information services and technical assistance to NSFNET end-users. Information and documents (available online or printed) cover topics such as resources (the Internet Resource Guide), contacts at the midlevel networks and at local campuses and institutions (the Internet Managers' Phone Book), and network status reports. When prospective or current users do not know whom to call concerning their questions about NSFNET use, they should contact the NNSC by electronic mail at nnsc@nnsc.nsf.net or by telephone at (617) 873-3400. Online information is available via ftp and from the Info-Server, an automated program which distributes documents in response to specially formatted messages. For instructions about the info-server, send a message to info-server@nnsc.nsf.net with "HELP" in the body of the message. Address: NNSC BBN Systems & Technologies 10 Moulton Street Cambridge, MA 02138 Email: nnsc@nnsc.nsf.net Phone: (617) 873-3400 Who Can Use the NNSC NNSC services are geared toward users of NSFNET, however the staff will provide assistance, either directly or by referring questions to a more appropriate source for information, to users with general Internet-related questions or problems. Miscellaneous Information To receive copies of the NNSC newsletter (the NSF Network News) or other publications, please send a message to nnsc@nnsc.nsf.net. OCEANIC OCEANIC, the Ocean Network Information Center primarily supports the World Ocean Circulation Experiment (WOCE) research program. Examples of OCEANIC content are: ¥ WOCE program information ¡ Summaries of research projects with emphasis on data collection ¡ WOCE Field Program plans, resources and maps ¡ WOCE administrative information ¥ Directories of oceanographic datasets: ¡ Holdings of major data centers ¡ Directories of datasets of special interest to WOCE ¥ A WOCE data-tracking system: ¡ Datasets planned, being collected, being analyzed, and in data centers. ¥ A library of data products. OCEANIC also includes: ¥ A searchable directory of oceanographers on Internet, SPAN, Telemail (Omnet and Kosmos), and Bitnet. ¥ A searchable international oceanographic research ship schedules. OCEANIC is self-explanatory and menu-driven. Though intended to work with simple terminals, to view graphical material, you must use a terminal-emulation program compatible with the Tektronix 4010 standard. Network Access: Internet: telnet to host delocn.udel.edu (128.175.24.1) and login with username INFO. No password is required. SPAN: use SET HOST DELOCN, and login with username INFO. No password is required. TELEMAIL/ OMNET (Domestic USA): Use command GOTO SONIC. Users in Alaska should use Telenet/Omnet network address 909014 and follow the instructions above. International direct: The preferred method is via the international packet-switched network address: 311030200612Ñif your national system requires a twelve-digit address 31103020061200Ñif your national system requires a fourteen-digit address Some national systems require two zeroes in front of the address. You may need to experiment. You will connect directly into OCEANIC. No password is required. International TELEMAIL/Omnet: You may connect via Telemail/Omnet at one of these addresses: 311090900003Ñif your local network requires a twelve-digit address 31109090000300Ñif your local network requires a fourteen-digit address (NOTE: Users in Canada should use Datapac network address 1311090900014.) You will get a Telenet "@" prompt after entering this address. @ MAIL Username? your username Password? your password Once you are signed on to TELEMAIL: Command? GOTO SONIC Direct Dial-up: You may access OCEANIC directly using a modem (up to 2400 baud, set at 7,1,N). Dial (302) 645-4204. Login with user name INFO. No password is required. Address: University of Delaware College of Marine Studies Lewes, DE 19958 Attention: Katherine A. Bouton Email: Internet - bouton@delocn.udel.edu, SPAN - DELOCN::BOUTON, Telemail - K.BOUTON/Omnet Phone: (302) 645-4278 Who Can Use OCEANIC No restrictions. All oceanographers and meteorologists are welcome. Miscellaneous Information Telefax: (302) 645-4007 Telex: 7407728 WDIU UC System Manager: Walt Dabell (302) 645-4225 Internet: walt@delocn.udel.edu Span: DELOCN::WALT SPAN_NIC The Space Physics Analysis Network (SPAN) Information Center supports an interactive database system which can be accessed by logging in to the SPAN NIC host. The information in the database is grouped into six categories: (1) SPAN information section: General Information about SPAN, Administration structure of SPAN, History of SPAN (2) Query SPAN database of NODEs: Complete information about a particular node, Listing of nodes by a particular field, Complete listing of all nodes in the database (3) INTERmail syntaxes: How to send mail from SPAN to other users on other Networks and vice versa including SPAN to X.25 hosts; SPAN to NASAmail; GSFCmail; Telemail; OMNET; SPAN to Internet; SPAN to BITNET & EARN; SPAN to NSFNET; SPAN to JANET; SPAN to MFEnet; JUNET; UUCP; ACSnet (4) Important NEWS briefs: This section changes periodically to broadcast to the general SPAN public things that are happening on SPAN. (5) Access SPAN Library of documents: Have document e-mailed to you; Request document be postal mailed to you (6) How to access other Network Information Centers (NICs) Network Access Host Information Internet: 6.132 (6276) NSSDC 128.183.10.59 NSSDC.GSFC.NASA.GOV 6.133 (6277) NSSDCA 128.183.10.4 NSSDCA.GSFC.NASA.GOV NSSDC is a VAX 11/780. NSSDC is a VAX 8650. To connect to the SPAN NIC via DECNET, type: SET HOST NSSDCA and log in as user SPAN_NIC. You can also set host to NSSDC. To connect to the SPAN NIC via the Internet, telnet to either system and log in as SPAN_NIC. Dial-in and Telenet access are also availalble. Contact the SPAN NIC for details. Address: SPAN Network Information Center SPAN Operations Center NASA/Goddard Space Flight Center Code 630.2 Greenbelt, Maryland 20771 Email: NETMGR@NSSDCA.GSFC.NASA.GOV [Internet] NSSDCA::NETMGR [SPAN] Phone: 301-286-7251 or FTS 888-7251 Who Can Use the SPAN NIC All services are available to users of SPAN and the DECnet Internet. Users who are part of the Internet are also welcome to use this service. Miscellaneous Information For further assistance: Linda Porter, Acting SPAN Operations ManagerÑ for SPAN policy issues. SSL::PORTERL or PORTERL@SSL.MSFC.NASA.GOV Pat Sisson, SPAN Security ManagerÑfor security related matters. NSSDCA::SISSON or SISSON@NSSDCA.GSFC.NASA.GOV Dave Peters SPAN Internetwork ManagerÑfor interworking issues. NSSDCA::PETERS or PETERS@NSSDCA.GSFC.NASA.GOV To receive hardcopy of SPAN documents. NSSDCA::REQUEST or REQUEST@NSSDCA.GSFC.NASA.GOV Books about the Internet Douglas E. Comer. Internetworking with TCP/IP: Principles, Protocols and Architecture. Prentice Hall: Englewood Cliffs, New Jersey. 1988. Donnalyn Frey and Rick Adams. !%@:: A Directory of Electronic Mail Addressing and Networks. Second Edition, O'Reilly and Associates: Sebastopol, California., 1990. Charles Hedrick. "Introduction to the Internet Protocols" Rutgers University Computer Science Facilities Group, Piscataway, New Jersey. 1988. Ed Krol. Hitchhiker's Guide to the Internet (RFC 1118). University of Illinois, Urbana: Urbana-Champaign, Illinois. 1989. Tracy L. LaQuey. Users' Directory of Computer Networks. Digital Press: Bedford, Massachusetts. 1990. John S. Quarterman. The Matrix: Computer Networks and Conference Systems Worldwide. Digital Press: Bedford, Massachusetts. 1990. Andrew S. Tanenbaum. Computer Networks, Second Edition. 1988 Book Review by Craig Partridge Douglas E. Comer. Internetworking with TCP/IP: Principles, Protocols and Architecture. Prentice Hall: Englewood Cliffs, NJ, 1988. This book is designed to be a comprehensive introduction to the TCP/IP protocol suite used on NSFNET and numerous other networks. Comer successfully manages to explain almost every aspect of TCP-IP networking, from how packets are routed to how hostnames get looked up. The book is intended both as an introduction for the advanced undergraduate and as a reference for professionals. Often that constitutes an unhappy mix of readers: the undergraduate gets buried by technical details while the professional finds little intellectual substance amidst the introductory text. Comer, however, manages to make this mix work. The text is easy to read and avoids the mathematics and heavy technical jargon that frustrates the beginner; at the same time, it offers the professional a useful reference that at least touches on all aspects of TCP-IP networking. The bibliography is quite good and at the end of each chapter Comer points the reader towards additional reading. Book Review by Craig Partridge Donnalyn Frey and Rick Adams. !%@:: A Directory of Electronic Mail Addressing and Networks. Second Edition, O'Reilly and Associates: Sebastopol, Calif., 1990. Imagine this scenario: Your colleague at Prairie View A&M says she has an electronic mail account but doesn't know what network it is on. You want to figure out if you can send mail to her. This useful book is designed to help answer your questions. The book is organized into several parts. One section is a listing of networks, such as NSFNET, JUNET, and SPAN, showing the area each network serves, and the services it supports. Another section indexes companies by name and by their domain names (Prairie View A&M is pvamu.edu). A third section indexes geographic regions along with their affiliated networks. Other sections try to help users figure out what those e-mail error messages mean. All this information is packed into 285 easy-to-read pages. The directory is a convenient reference to have in your office. Book Review by Karen Roubicek Tracy L. LaQuey. The Users' Directory of Computer Networks. Digital Press: Bedford, Mass, 1990. Today's widespread analogy that likens computer networking to the highway system logically leads to the observation, made by Tracy LaQuey, that the network traveler needs a roadmap to get around. LaQuey intends theUser's Directory of Computer Networks to be the tool that helps network users understand the communications paths, see how they connect, locate resources (machines, services, or people) that they need, and understand some basic networking concepts. The Directory is a descendant of a 1987 volume of the same title published by the University of Texas, and edited by Carol Englehardt Kroll, which was subsequently revised by LaQuey. The current directory is divided into chapters that discuss specific networks, such as the DECnet Internet and the Internet, essays on the Domain Name System, the OSI Directory Service (X.500), Electronic Mail, and an organizational index. In this volume, LaQuey includes several more networks and has expanded the narrative about each network. Network Overviews This book successfully pulls together a lot of information in a consistent and coherent presentation. Most chapters (several of which have subchapters that describe component networks of an internet) provide descriptions that answer the same key questions about each network: What is the topology? What protocols are supported? What services are provided? What are the membership requirements? How is the network administered? What are the usage guidelines? The descriptions don't go into great technical depth, but that's not the editor's goal. LaQuey provides maps and extensive lists of hosts, contacts, and network numbers for reference purposes, but the reader comes away from a chapter chiefly with a useful overview of each network and a basic understanding of where each fits into the big picture. The essays in the final chapters are particularly helpful for users who have a limited amount of networking experience. John Quartermann presents a good summary of the complex issues of electronic mail, and provides a bibliography for those readers who want a more extensive treatment of email. Mic Kaczmarczik includes a useful set of tables designed to help users construct and send messages between many of the networks described in the directory. Paul Mockapetris contributed the chapter on domains. In a succint three and a half pages, he does a neat job of summarizing the important concepts of the domain name system and describing why the reader should care about them. A list of domain names is included. The OSI X.500 chapter contains more detail than the other essays and is less conversational in tone. The focus here is more on the technical specifics of the OSI Directory and is aimed at a more technically sophisticated audience. The final chapter, List of Organizations, is a valuable cross-reference that gives the reader a picture of the connectivity of over five thousand organizations. A shortcoming of theDirectory is one that is typical of all books dealing with an area that is developing as quickly as networkingÑsome percentage of the data is automatically outdated as soon as the text is given to the publisher. However, even if specifics change over time, such as contact names, the information that remains serves as a starting for finding the most current information. The User's Directory is impressive for several reasons. It presents a huge quantity of information in a straightforward and comprehensible way. LaQuey has done an excellent job of editing that doesn't make the user feel overwhelmed by a subject that can actually be quite overwhelming to those not immersed in network technology. LaQuey's efforts at collecting and verifying information are apparent, and her diligence proves worthwhile. This reference guide will occupy a prominent place on the bookshelves of the masses of network users who need the information that LaQuey has compiled. Book Review by Craig Partridge John S. Quarterman. The Matrix: Computer Networks and Conference Systems Worldwide. Digital Press: Bedford, Mass. 1990. This book chronicles the existing worldwide networks and discusses the history of networking. It is an indispensable reference, representing the networking community's first complete look at itself. The first part of the book is an extended introduction. It presents the basic concepts in networking, the history of many of the protocol suites, how networks are used, and who's-who listing of standards and bodies. The second half of the book lists all known computer networks, from the United States and Europe (with dozens of networks) to Thailand (TSCnet) and Costa Rica (CATIENET). The coverage is extraordinarily thorough. Much of the information comes from private communication, and many of the networks are very small (a dozen nodes or less). Book Review by Craig Partridge Andrew S. Tanenbaum. Computer Networks, Second Edition, 1988. Please note: This is a review of the first edition of this book. Andrew S. Tanenbaum.Computer Networks, Prentice-Hall, Inc. (1981) This book is . . . the introductory text most often recommended by specialists in the computer networking field. One of its great merits is its comparative approach. Using examples from SNA and DECnet, as well as TCP/IP and OSI, Tanenbaum offers a breadth of coverage that few writers can match. Nonetheless, the book shows its age. It takes a more favorable view of protocol layering than is currently in vogue and, because it was written while many transport protocols, such as TCP, were still being developed, it contains little about what has been learned in the past several years concerning transport-level problems. The book also offers no discussion of the problems of external data representations such as ASN.1. Despite these shortcomings, Computer Networks is still a good general reference book. Rumor has it that a second edition is due out this year. Click on an underlined word to see a definition. 1822 ACK Acknowledgement ANSI AppleTalk ARP ARPANET Authority Zone Autonomous Confederation Autonomous System Backbone Bandwidth Baseband Baud BBN Bolt Beranek and Newman Inc. BITNET Broadband Broadcast BSD Catenet CCITT Checksum Client Connection COS Corporation for Open Systems CREN Corporation for Research and Educational Networking CSMA/CD Carrier Sense Multiple Access with Collision Detection CSNET DARPA Defense Advanced Research Projects Agency Datagram DDN Defense Data Network EARN EGP Exterior Gateway Protocol Electronic Mail Ethernet email FDDI Fiber Distribution Data Interface Field File Server Fragment Frame FTAM File Transfer, Access, and Management FTP File Transfer Protocol Gateway GOSIP Government OSI Profile Header HELLO Host ICMP Internet Control Message Protocol IEEE 802 IEN Internet Engineering Notes IMP Interface Message Processor Internet Address Internet ISDN Integrated Services Digital Network ISO International Standards Organization Layer LAN Local Area Network LocalTalk Mail Bridge Mail Gateway MAN MAP Message MILNET MILitary Network MTU NBS National Bureau of Standards. Network Network Address NFS Network File System NIST National Institute for Standards NIC Network Information Center NOC Network Operations Center NNSC NSF Network Service Center NSF National Science Foundation NSFNET National Science Foundation Network NTP Network Time Protocol ODA Office Document Architecture OSI Open Systems Interconnect OSI Reference Model Packet Packet Switch PAD PING Protocol PSN Packet Switch Node RDP Reliable Datagram Protocol RFC-733 RFC-822 RFC Request for Comment RIP Routing Information Protocol Route rcp Remote copy rlogin Remote login Server SMTP Simple Mail Transfer Protocol SNA Systems Network Architecture SNMP Source Address SPAG Switch T1 TCP/IP TELENET Telnet TOP Technical/Office Protocol TP-4/IP TTL Time To Live UDP User Datagram Protocol UUCP UNIX-to-UNIX-CoPy X.25 X.400 X.500 XNS Xerox Network Services 1822 A hardware protocol used to connect an Internet host to a packet switch on the ARPANET and MILNET. This protocol is also called AHIP (Asynchronous Host Interface Protocol). The number 1822 comes from the BBN (Bolt Beranek and Newman) report that defined the interface for the original ARPANET. ACK Short for acknowledgement. Acknowledgement A type of message sent to indicate that a block of data arrived at its destination without error. A negative acknowledgement (NACK) indicates that the block of data was not correctly received. ANSI American National Standards Institute. This organization is responsible for approving U.S. standards in many areas, including computers and communications. Standards approved by this organization are often called ANSI standards (e.g., ANSI C is the version of the C language approved by ANSI). ANSI is a member of the International Standards Organization (ISO). AppleTalk A networking protocol developed by Apple Computer for communication between Apple Computer products and other computers. This protocol is independent of what network it is layered on. Current implementations exist on Localtalk (a 235-kilobit/second local area network (LAN)), and Ethertalk (a 10-megabit/second local area network). ARP Address Resolution Protocol. This protocol is used to dynamically bind an Internet address to a low-level physical network address. It is often used on local area networks (LANs) such as Ethernet. ARPANET One of the first heterogeneous-host packet switching networks developed for the Advanced Research Projects Agency of the Department of Defense (see DARPA). The ARPANET became operational in 1968; it was the proving ground for many of the protocols and concepts in todayÕs Internet. Authority Zone The part of a domain name that a single name server resolves. For example, if the server spooler .bbn.com is responsible for resolving all machine addresses in the domain bbn.com, then its authority zone is *.bbn.com (where * means anything is allowed). On the other hand, george.random.com would not be in its authority zone. Autonomous Confederation A group of independent computer systems that trust each other regarding routing (see route) and reachability information. Members of an autonomous confederation will believe information provided by other members of the confederation in preference to information received from systems that are not part of the confederation. Autonomous System A collection of networks controlled by one administrative authority. The gateways within this system are expected to trust one another and to share and update routing information (see route) among themselves by any mutually agreeable protocol. A core gateway must also be designated to share routing information with other autonomous systems via EGP. Backbone A central high-speed network connecting independent subnetworks. Today, the NSFNET provides a backbone network for regional networks such as NEARnet, CSNET, and BARRNet. Bandwidth The frequency width of a communications channel, usually measured in hertz, kilohertz, or megahertz. For example, one channel on a satellite transponder might have a bandwidth of six megahertz, thereby enabling it to carry a television signal. Sometimes, this term is applied to how much digital information a channel can carry, usually in conjunction with fully digital communications lines. For example, a T1 line might be said to have a bandwidth of 1.544 megabits/second; however, it would be more correct to say that a T1 line can carry or transmit 1.544 megabits/second. Baseband A transmission medium where digital signals are sent without complicated frequency shifting. In general, only one communication channel is provided at a time on a baseband system. Ethernet is a baseband network. Baud The number of symbols that may be sent over a communications channel per second. Each symbol may be an arbitrary analog signal, and it may represent more than one bit of information. For example, a communications channel transmitting at 2400 baud, with each symbol containing four bits, is capable of sending 9600 bits per second (this is in fact the way V.32 9600-baud modems work). BBN Bolt Beranek and Newman Inc., a diversified high-technology company in Cambridge, Massachusetts, was awarded the original contract to build the ARPANET and has been extensively involved in Internet development. Today, BBN is responsible for managing the NNSC, CSNET, and NEARnet among others. This stack is brought to you by the NNSC staff at BBN (Hi Mom!). BITNET Because ItÕs Time Network. An academic and research network connecting approximately 2500 computers in thirty-two countries. This network provides interactive electronic mail, and file transfer services via a store-and-forward methodology based on IBM NJE protocols. BITNET traffic and Internet traffic are exchanged via several gateway hosts. This network is now part of the Corporation for Research and Educational Networking (CREN). Broadband A transmission medium where multiple digital channels are frequency multiplexed onto a single cable. This type of network requires relatively complicated electronics, but is capable of carrying voice, data, and video all on the same medium. Cable television systems are examples of broadband networks. Broadcast A technique used to send packets to all hosts on a network. Broadcasts are often used in conjunction with ARP and RARP protocols on local area networks. BSD Berkeley Source Distribution. This acronym is used to describe the versions of the UNIX operating system and its utilities developed and distributed by the University of California at Berkeley. "BSD" is usually preceded by the version number of the distribution, e.g., "4.3 BSD" is version 4.3 of the Berkeley UNIX distribution. Many Internet hosts run BSD software, and it has been the ancestor of many commercial UNIX implementations such Sun OS and SequentÕs Dynix. Catenet A term coined to describe the communications structure created when packet switched networks are connected by gateways. The term internet without a capital I is now more commonly used. CCITT ComitŽ Consultatif International de TŽlŽgraphique et TŽlŽphonique (International Consultative Committee on Telephone and Telegraph). This organization is part of the United Nations International Telecommunications Union (ITU) and is responsible for making technical recommendations about telephone and data communication systems. X.25 is an example of a CCITT recommendation. Every four years CCITT holds plenary sessions where they adopt new standards; a session is planned for 1992. Checksum A computed symbol whose value is dependent upon the entire contents of a message or packet. This value is usually sent along with the message when it is transmitted. The receiving system computes a new checksum based upon the received data and compares this value with the one sent with the packet. If the two values are the same, the receiver has a high degree of confidence that the data was received correctly. Client A computer system or process that requests a service of another computer system or process. A workstation requesting the contents of a file from a file server is a client of the file server. Connection An agreement between two processes or hosts to pass information along a specified protocol path without further exchanges of addressing information. COS Corporation for Open Systems. An international non-profit organization made up of computer users and vendors. This organizationÕs mission is to provide ways of testing OSI implementations. CREN Corporation for Research and Educational Networking. This organization was formed in October, 1989, when BITNET and CSNET were combined under one administrative authority. CREN is now responsible for providing networking service to both BITNET and CSNET users. CSMA/CD Carrier Sense Multiple Access with Collision Detection (phew!). This is a characteristic of a local area network (LAN). When multiple users have access to the network for transmitting data, the network avoids transmitting data from more than one user at a time, so that they avoid running into each other. Ethernet works this way. CSNET Computers and Science Network. A network that was established to provide mail forwarding and Internet connectivity to computer (and now other) science researchers. This network primarily provides electronic mail service via dial-up lines, although X.25 and Internet services are available from sites that are suitably connected. This network is now part of the Corporation for Research and Educational Networking (CREN). DARPA Defense Advanced Research Projects Agency. An agency of the U.S. Department of Defense responsible for the development of new technology for use by the military. DARPA (formerly known as ARPA) was responsible for funding much of the development of the Internet we know today. The New York Times business section called DARPA "AmericaÕs answer to JapanÕs MITI." Datagram A packet whose routing (see route) and interpretation is independent of other packets being sent by that host. Every datagram must contain a destination address, since it cannot rely on addressing information sent by previous packets. Datagrams are a connectionless form of communication, and are the basic building blocks of the internet protocol (IPÑsee TCP/IP). DDN Defense Data Network. A worldwide operational communications network serving the US Department of Defense composed of ARPANET, MILNET, and other portions of the Internet, used to connect military installations. It is run by the Defense Communications Agency (DCA). EARN European Academic Research Network. A network connecting European university and research institutions providing electronic mail and remote job entry facilities. This network uses BITNET protocols and connects to BITNET in the U.S. EGP Exterior Gateway Protocol. This protocol is used by a gateway representing an autonomous system to export to other gateways information concerning networks and gateways contained within that system. Electronic Mail A system whereby a computer user can exchange messages with other computer users (or groups of users) via a communications network. Electronic mail is one of the most popular uses of the Internet. Ethernet A 10-megabit/second standard for local area networks (LANs), initially developed by Xerox, and later refined by Xerox, DEC, and Intel. All hosts are connected to a coaxial cable where they contend for network access according to the CSMA/CD protocol. Email (or E-mail) Shortspeak for electronic mail (q.v.). FDDI Fiber Distribution Data Interface. A newly emerging standard for a fiber-optic local area network (LAN) running at 100 megabits/second. Field In computer messages, data files, and programs, a field is a group of characters that is treated as a unit. For example, each TCP/IP packet contains fields for addressing and routing information (see route). Internet users may encounter fields in the header of an electronic mail message. The fields are lines that begin with a field-name followed by a colon and a space. To: and From: are the only required header fields, but there are optional standard fields for the user, and fields that are added by the mail delivery system. The format of email messages is defined in RFC-822. File Server A computer whose principal purpose is to store files and provide network access to those files. Fragment A piece of a packet. When a gateway is forwarding a maximum size IP (see TCP/IP) packet to a network that has a smaller maximum packet size, it is forced to break up that packet into multiple fragments for transport on the new network. These fragments will be reassembled by the IP layer at the destination host (or possibly by an intermediate gateway under some circumstances). Frame An assembly of bits at the Data Link layer of the ISO protocol stack. This collection of bits begins with some bits used for header information, and ends with some checksum bits used for error detection and/or correction. All bits between the header and the checksum are data. FTAM File Transfer, Access, and Management. An application layer protocol for moving and manipulating files. FTP File Transfer Protocol. A protocol permitting a user on one Internet host to access and transfer files to another host over a network, such as the Internet. FTP is usually the name not only of the protocol, but also of the program the user invokes to execute the protocol (e.g., ftp host.bbn.com). This protocol is usually layered on top of TCP and IP (see TCP/IP). FTP is available on several operating systems. You can use the ftp command to copy computer files that contain a variety of information, such as software, documentation, or maps. Gateway A computer used to connect together one or more networks. This computer is seen as a host by the networks to which it is connected, but is capable of forwarding packets from one network to another. Gateways are also responsible for providing and receiving routing information to other gateways in the Internet so that they will know the best routes for sending packets between networks. One may think of a gateway as a packet switch with whole computer networks as its communication links. GOSIP Government OSI Profile. GOSIP is a collection of ISO specifications for mixed-vendor networks for use by the government. Government networks are mandated to support GOSIP in the not-too-distant future. Header The header is information that appears at the top of an electronic mail message. See field. HELLO An inter-packet switch protocol used in the NSFNET to determine shortest delay routing (see route). This protocol is only used among packet switches that trust each other. Host A computer that allows users to communicate with other host computers on a network. Individual users communicate by using application programs, such as electronic mail, TELNET, and FTP. ICMP Internet Control Message Protocol. This protocol is an integral part of the Internet Protocol (IPÑsee TCP/IP). The protocol is used to exchange error and control information among IP hosts. For example, a gateway that is sent an IP datagram for which it is not the best route would send an ICMP redirect packet back to the originating host to inform it of the best route. ICMP implementations also provide fault isolation capabilities such as packet echo. IEEE 802 The IEEE standards for local and metropolitan area networks (see LAN and MAN). This class of standards is further broken down by type of network, each of which is specified by digits after a decimal point. For example, the Ethernet standard is 802.3; IBM Token Ring is IEEE 802.5. IEN This stands for Internet Engineering Notes. IMP Interface Message Processor. This was the name for the original packet switches used in the ARPANET and MILNET. Today, the term Packet Switch Node or PSN is in more common usage. Internet Address A thirty-two-bit number that uniquely identifies an Internet host. This address is typically represented in eight-bit numbers (octets) separated by dots, e.g., 128.89.1.132. An Internet address consists of a network number and a host number, and may be a class A, B, or C address. A class A network address is formatted as N.H.H.H, providing seven bits of network number and twenty-four bits of host number (e.g., 26.0.0.117 indicates host 117 on net 26). A Class B network address is formatted as N.N.H.H, providing fourteen bits of network number and sixteen bits of host number (e.g.,128.89.1.132 indicates host 1.132 on net number 128.89). A Class C network address is formatted as N.N.N.H, providing twenty-two bits of network number and eight bits of host address (e.g.,192.1.14.28 indicates host 28 on network number 192.1.14). The Internet is the interconnection of many networks throughout the world that speak the same language, namely the TCP/IP protocol suite. Internet with a capital I refers specifically to that internet that contains NSFNET, MILNET, and DDN. You may see "internet" with a small "i." This can refer to any network built out of the TCP/IP protocol suite, or it might refer to networks using other protocol families that are composites of smaller networks. Internet ISDN Integrated Services Digital Network. A public digital network designed to integrate voice and non-voice traffic. This system is intended to be a replacement for our current analog telephone systems, and as such is being standardized by the CCITT. ISO International Standards Organization. The international body responsible for establishing multivendor networking standards. Layer Communication networks for computers may be organized as a set of more or less independent protocols, each in a different layer (also called level). The lowest layer governs direct host-to-host communication between the hardware at different hosts; the highest consists of user applications. Each layer builds on the layer beneath it. For each layer, programs at different hosts use protocols appropriate to the layer to communicate with each other. TCP/IP has five layers of protocols, and OSI has seven. The advantage of different layers of protocols is that the methods of passing information from one layer to another is specified clearly as part of the protocol suite, and changes within a protocol layer are prevented from affecting the other layers. This greatly simplifies the task of designing and maintaining communication programs. LAN Local Area Network. A data network intended to serve an area of only a few square kilometers or less. Because the network is known to cover only a small area, optimizations can be made in the network signal protocols that permit data rates in the 10-megabyte-per-second to 100-megabytes-per-second range today. Wide-area communication is accomplished by connecting LANs together via metropolitan area networks (MANs) or wide-area networks (WANs). Both Ethernet and FDDI are local area networks. LocalTalk A local area network (LAN) protocol developed by Apple Computer. This network is designed to run over twisted pairs of telephone wire and has a data rate of 235 kilobits/second. All Macintosh computers contain a LocalTalk interface. Mail Bridge A mail gateway that forwards electronic mail between two or more networks while ensuring that the messages it forwards meet certain administrative criteria. A mail bridge is simply a specialized form of mail gateway that enforces an administrative policy with regard to what mail it forwards. Mail Gateway A network host that forwards electronic mail between two or more possibly dissimilar networks. In the process of forwarding the mail, the gateway may have to reformat addresses and mail headers to conform with the electronic mail standards of the destination network. MAN Metropolitan Area Network. A data network intended to serve an area approximating that of a large city. Such networks are being implemented by innovative techniques such as running fiber cables through subway tunnels. MAP Manufacturing Automation Protocol. A protocol stack developed by General Motors following the OSI model that guarantees access to each host within a certain maximum time. At the upper layers, it includes many of the OSI standards. At the lower layers, it is based upon Token Bus (IEEE 802.4). Message "Message" has multiple meanings: 1) A user-defined collection of data sent over a network. 2) A piece of text displayed on a terminal screen that was sent by a user or a program. 3) A collection of data sent from one computer programming entity to another. MILNET MILitary NETwork. This network was created in 1984 from parts of the original ARPANET. The military users wished to have an operational production network, while the research community wished to have a network on which to continue experimenting in networking. Therefore, the military users were placed on MILNET, the research users were placed on ARPANET, and the two networks were connected with mail bridges and gateways. Today, MILNET is one of the class A networks in the Internet. MTU Maximum Transmission Unit. The largest number of bits that a network permits to be transmitted as one packet. NBS National Bureau of Standards. This organization, which was part of the U.S. Department of Commerce, was responsible for establishing standards in the United States. It has since become the NIST. Network A computer network is a group of computers that can communicate electronically. Networks can be composed of computers in a single building (Local Area Networks or LANs), or computers thousands of miles apart (Wide Area Networks or WANs). The Internet is a worldwide collection of computer networks that can intercommunicate. The system manager and computer center staff at your site can provide information about your local network. Network Address A number or group of numbers that uniquely specifies a host on a network. For example, 128.89.1.178 is the network address for nnsc.nsf.net. Also, informally, an electronic mail address. For example, nnsc@nnsc.nsf.net is the network address for the NSF Network Service Center (NNSC). NFS Network File System. This acronym describes a protocol developed by Sun Microsystems to allow a computer system to access files over a network as if they were on its local disks. This protocol has been incorporated in products by more than two hundred companies, and is now a de facto Internet standard. NIST This stands for the National Institute for Standards and Technology (see NBS). NOC Network Operations Center. A location from which the operation of a network or internet is monitored. This center also usually serves as a clearinghouse for problems and efforts to resolve those problems. NSF National Science Foundation. A government agency whose purpose is to promote the advancement of science. NSF funds science researchers, scientific projects, and infrastructure to improve the quality of scientific research. The NSFNET, funded by NSF, is an essential part of academic and research communications. NTP Network Time Protocol. A protocol built on top of TCP (see TCP/IP) that assures accurate local time-keeping with reference to radio and atomic clocks located on the Internet. This protocol is capable of synchronizing distributed clocks within milliseconds over long time periods. ODA Office Document Architecture. This emerging standard defines ways in which text, graphics, and facsimile documents can be moved over a multivendor network. OSI Open Systems Interconnect. Usually used as shorthand for the Open Systems Interconnection Reference Model (OSI Reference Model). OSI Reference Model A seven-layer structure designed to describe computer network architectures and the way that data passes through them. This model was developed by the ISO in 1978 to clearly define the interfaces in multivendor networks, and to provide users of those networks with conceptual guidelines in the construction of such networks. Packet A collection of data sent as a unit along a packet network. Packets are self-contained; each packet has its own source address and destination address and cannot exceed a maximum size. Long messages are broken up into multiple packets for transmission over the network. Packet Switch See PSN. PAD Packet Assembler/Disassembler. A network host designed to interface terminals to a packet network. PING Packet Internet Groper. A program that sends packets to a remote host on the Internet and looks for replies. This program works via the echoing facility provided by the ICMP protocol and is a way to determine if an Internet host is reachable from your host. Protocol A mutually agreed procedure for communicating information between two parties. Standard protocols are the basis for all computer communication. PSN Packet Switch Node. A dedicated computer whose purpose is to accept, route, and forward packets in a packet switched network. RDP Reliable Datagram Protocol. An Internet standard protocol for reliably sending datagrams between user programs. This protocol is like UDP, but guarantees delivery and does retransmission as necessary. This protocol is built on top of IP (see TCP/IP) and uses IP for datagram delivery. RFC-733 An obsolete version of the Request for Comments (Standard for the format of ARPA Internet Test Messages, August 16, 1982) that specifies the format of electronic mail messages. See RFC-822. RFC-822 The current version of the Request for Comments that specifies the format of electronic mail messages. RFC Request for Comments. RFCs are the principal documents used on the Internet to propose new protocols and services. These documents are published as electronic documents on nic.ddn.mil by the DDN NIC. RIP Routing Information Protocol. A routing (see route) protocol provided in the Berkeley UNIX (see BSD) operating system, that permits a group of hosts located on a local network to share routing information. This function is provided by the program routed. Route A path from one Internet host to another. rcp Remote copy. A program and protocol provided in the Berkeley UNIX operating system (see BSD) that permits files to be copied from one computer to another by an extension to the syntax of the UNIX cp (copy) command. This protocol is largely implemented among UNIX machines, but the protocol is general enough that non-UNIX machines may use it. However, rcp does not provide the word-length adaptability and flexibility that the FTP protocol does. rlogin Remote login. A program and protocol provided in Berkeley UNIX (see BSD) that permits a user on one computer to log in to another computer. This protocol is largely implemented among UNIX machines, but the protocol is general enough that non-UNIX machines may use it. For example, Excelan ANNEX terminal concentrators permit users on dumb terminals to use the rlogin protocol to communicate with Internet computers. Router A device that chooses routings for packets. This is a generic term and applies to such diverse devices as bridges (which pass packets from one physical LAN to another with almost no interpretation) and WAN gateways (which pass packets from one wide area network to another, doing fragmentation and reassembly as necessary). Server A computer system or process that provides a service for other computer systems or processes to access. A supercomputer can be thought of as a computation server. A program that provides Internet File Transfer Protocol (FTP) access to local files is usually called an FTP server. SMTP Simple Mail Transfer Protocol. This Internet standard network protocol is used to move electronic mail messages from one host to another. SNA Systems Network Architecture. A proprietary networking architecture used by IBM and IBM-compatible mainframe computers. Because of its widespread use, SNA is a de facto standard. While it can use packet switched networks for transport, SNA is largely a circuit-switching rather than a packet-switching technology. SNMP Simple Network Monitoring Protocol. This Internet standard protocol is used by a network monitoring center to gather information regarding the status of hosts on its network or on the Internet. Source Address The network address of the host that originates a packet. SPAG Standards Promotion and Applications Group. This European organization collaborates with COS to promote testing procedures and techniques for OSI products. Switch A computer responsible for routing (see route) packets in a packet switched network. T1 A communications service over leased lines and microwave links that runs at 1.544 megabytes per second. The major links of the NSFNET are T1. Faster services such as T3 (45 megabytes per second) are available, although they are not yet off-the-shelf products. The NSFNET is in the process of upgrading to T3, and plans much higher transmission rates for the future. TCP/IP Transmission Control Protocol/Internet Protocol. A Department of Defense standard protocol suite encompassing both network and transport level protocols. While the terms TCP and IP specify two protocols, common usage of the two terms together has come to represent the entire DoD protocol suite based upon these protocols, including Telnet, FTP, UDP, and RDP. Technically, this is incorrect usage, because other protocol stacks can be layered on top of TCP and IP that provide similar services, but are not part of the DoD standard protocols (e.g., TP-4/IP, FTAM on TCP, etc.). Ideally, one should only use TCP/IP to mean the TCP protocol layered on top of the IP protocol. TELENET A commercial wide-area packet switching X.25 network. TELNET Telnet is a program that allows a computer user at one site to work on a computer at another site. It is the Internet standard protocol for remote terminal connection service. Telnet requires Internet access, that is, you must be on a TCP/IP network that gateways to the Internet. Unlike FTP and electronic mail, Telnet actually exposes you to the commands and programs of the remote host. For example, you can use the telnet command to run a program in your directory on a supercomputer hundreds of miles away. TOP Technical/Office Protocol. A protocol stack for office automation developed by Boeing following the OSI model. This protocol is very similar to MAP except at the lowest levels, where it uses Ethernet (IEEE 802.3) rather than Token Bus (IEEE 802.4). TP-4/IP The ISO protocol suite that performs the same functions as TCP/IP. TP-4 provides reliable, connection-oriented data streams using datagrams. This protocol also handles error detection, synchronization, and retransmission, just as TCP does. TTL Time To Live. A field in a datagram designed to prevent packets from looping indefinitely in the Internet. Because routing information changes dynamically, two or more gateways may occasionally forward packets to each other in a loop, since each believes the other is the best route to the destination. A packet is initially sent with a nonzero TTL field, and each gateway that forwards that packet decrements the value in that field. Once the value reaches zero, a loop is assumed and the packet is discarded. UDP User Datagram Protocol. The Internet standard protocol for sending datagrams between user programs. This protocol neither guarantees delivery nor does it require a connection. As a result it is lightweight and efficient, but requires the application to do all error processing and retransmissions. This protocol is built on top of IP and uses IP for datagram delivery (see TCP/IP). UUCP UNIX-to-UNIX-CoPy. This was initially a program run under the UNIX operating system (see BSD) that permitted one UNIX system to send files to another UNIX system via dial-up phone lines. Today, the term is more commonly used to describe the large international network made up of these machines using the UUCP protocol to pass netnews and electronic mail. X.25 A standard networking protocol suite approved by the CCITT and ISO. This protocol suite defines standard physical, link, and networking layers only (layers 1 through 3). X.25 networks are in use throughout the world. X.400 The CCITT standard for electronic mail. X.400 systems are in use in Europe, Canada, and several U.S. commercial installations. X.500 The CCITT standard for electronic mail directory services. XNS Xerox Network Services. A proprietary networking architecture developed by Xerox.