💾 Archived View for spam.works › mirrors › textfiles › internet › internet.tour captured on 2023-11-14 at 10:24:18.
⬅️ Previous capture (2023-06-14)
-=-=-=-=-=-=-
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" <socrates@agora.edu>
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 <RBEAUPRE@ccr2.bbn.com>
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 <carver@herhost.org>
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 <carver@herhost.org>
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 <glynn@hishost.edu>
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 <glynn@hishost.edu>
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 <CTRL/C>). 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 <CR> 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