textfiles/internet/internet.tour

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 
*.bbn.com (where * means anything is allowed).  On the other hand, 
george.random.com would not be in its authority zone. 

 Autonomous Confederation

A group of independent computer systems that trust each other 
regarding routing (see route) and reachability information.  Members of 
an autonomous confederation will believe information provided by other 
members of the confederation in preference to information received 
from systems that are not part of the confederation.
               
Autonomous System

A collection of networks controlled by one administrative authority.  
The gateways within this system are expected to trust one another and 
to share and update routing information (see route) among themselves 
by any mutually agreeable protocol.  A core gateway must also be 
designated to share routing information with other autonomous 
systems via EGP.

Backbone

A  central high-speed network connecting independent subnetworks.  
Today, the NSFNET provides a backbone network for regional networks 
such as NEARnet, CSNET, and BARRNet.

Bandwidth

The frequency width of a communications channel, usually measured in 
hertz, kilohertz, or megahertz.  For example, one channel on a satellite 
transponder might have a bandwidth of six megahertz, thereby enabling 
it to carry a television signal.  Sometimes, this term is applied to how 
much digital information a channel can carry, usually in conjunction 
with fully digital communications lines.  For example, a T1 line might 
be said to have a bandwidth of 1.544 megabits/second;  however, it 
would be more correct to say that a T1 line can carry or transmit 1.544 
megabits/second.
               
Baseband

A transmission medium where digital signals are sent without 
complicated frequency shifting.  In general, only one communication 
channel is provided at a time on a baseband system.  Ethernet is a 
baseband network.  

Baud

The number of symbols that may be sent over a communications channel 
per second.  Each symbol may be an arbitrary analog signal, and it may 
represent more than one bit of information.  For example, a 
communications channel transmitting at 2400 baud, with each symbol 
containing four bits, is capable of sending 9600 bits per second (this is 
in fact the way V.32 9600-baud modems work).
               
BBN

Bolt Beranek and Newman Inc., a 
diversified high-technology company 
in Cambridge, Massachusetts, was awarded the original contract to 
build the ARPANET and has been extensively involved in Internet 
development.  Today, BBN is responsible for managing the NNSC, CSNET, 
and NEARnet among others.  This stack is brought to you by the NNSC 
staff at BBN (Hi Mom!).

               
BITNET

Because ItÕs Time Network.  An academic and research network 
connecting approximately 2500 computers in thirty-two countries.  
This network provides interactive electronic mail, and file transfer 
services via a store-and-forward methodology based on IBM NJE 
protocols.  BITNET traffic and Internet traffic are exchanged via 
several gateway hosts.  This network is now part of the Corporation for 
Research and Educational Networking (CREN).


Broadband

A transmission medium where multiple digital channels are frequency 
multiplexed onto a single cable.  This type of network requires 
relatively complicated electronics, but is capable of carrying voice, 
data, and video all on the same medium.  Cable television systems are 
examples of broadband networks.

               
Broadcast

A technique used to send packets to all hosts on a network.  Broadcasts 
are often used in conjunction with ARP and RARP protocols on local 
area networks.
         
BSD

Berkeley Source Distribution.  This acronym is used to describe the 
versions of the UNIX operating system and its utilities developed and 
distributed by the University of California at Berkeley.  "BSD" is usually 
preceded by the version number of the distribution, e.g., "4.3 BSD" is 
version 4.3 of the Berkeley UNIX distribution.  Many Internet hosts run 
BSD software, and it has been the ancestor of many commercial UNIX 
implementations such Sun OS and SequentÕs Dynix.
               
Catenet

A term coined to describe the communications structure created when 
packet switched networks are connected by gateways.  The term 
internet without a capital I is now more commonly used. 

CCITT

ComitŽ Consultatif International de TŽlŽgraphique et TŽlŽphonique 
(International Consultative Committee on Telephone and Telegraph).  
This organization is part of the United Nations International 
Telecommunications Union (ITU) and is responsible for making 
technical recommendations about telephone and data communication 
systems.  X.25 is an example of a CCITT recommendation.  Every four 
years CCITT holds plenary sessions where they adopt new standards; a 
session is planned for 1992.
               
Checksum

A computed symbol whose value is dependent upon the entire contents 
of a message or packet.  This value is usually 
sent along with the message when it is transmitted.  The receiving 
system computes a new checksum based upon the received data and 
compares this value with the one sent with the packet. If the 
two values are the same, the receiver has a high degree of confidence 
that the data was received correctly.

Client

A computer system or process that requests a service of another 
computer system or process.  A workstation requesting the contents of 
a file from a file server is a client of the file server.
               
Connection

An agreement between two processes or hosts to pass information 
along a specified protocol path without further exchanges of addressing 
information.	

COS

Corporation for Open Systems.  An international non-profit organization 
made up of computer users and vendors.  This organizationÕs mission is 
to provide ways of testing OSI implementations.
               
CREN

Corporation for Research and Educational Networking.  This 
organization was formed in October, 1989, when BITNET and CSNET 
were combined under one administrative authority.  CREN is now 
responsible for providing networking service to both BITNET and CSNET 
users.
               
CSMA/CD

Carrier Sense Multiple Access with Collision Detection (phew!).  This is 
a characteristic of a local area network (LAN).  When multiple users 
have access to the network for transmitting data, the network avoids 
transmitting data from more than one user at a time, so that they avoid 
running into each other.  Ethernet works this way.
               
CSNET

Computers and Science Network.  A network that was established to 
provide mail forwarding and Internet connectivity to computer (and 
now other) science researchers.  This network primarily provides 
electronic mail service via dial-up lines, although X.25 and Internet 
services are available from sites that are suitably connected.  This 
network is now part of the Corporation for  Research and Educational 
Networking (CREN). 

DARPA

Defense Advanced Research Projects Agency.  An agency of the U.S. 
Department of Defense responsible for the development of new 
technology for use by the military.  DARPA (formerly known as ARPA) 
was responsible for funding much of the development of the Internet 
we know today.  The New York Times business section called DARPA 
"AmericaÕs answer to JapanÕs MITI."
               
Datagram

A packet whose routing (see route) and interpretation is independent of 
other packets being sent by that host.  Every datagram must contain a 
destination address, since it cannot rely on addressing information 
sent by previous packets.  Datagrams are a connectionless form of 
communication, and are the basic building blocks of the internet 
protocol (IPÑsee TCP/IP).

        
DDN

Defense Data Network.  A worldwide operational communications 
network serving the US Department of Defense composed of ARPANET, 
MILNET, and other portions of the Internet, used to connect military 
installations.  It is run by the Defense Communications Agency (DCA).

       
EARN

European Academic Research Network.  A network connecting European 
university and research institutions providing electronic mail and 
remote job entry facilities.  This network uses BITNET protocols and 
connects to BITNET in the U.S.

EGP

Exterior Gateway Protocol.  This protocol is used by a gateway 
representing an autonomous system to export to other gateways 
information concerning networks and gateways contained within that 
system. 

Electronic Mail

A system whereby a computer user can exchange messages with other 
computer users (or groups of users) via a communications network.  
Electronic mail is one of the most popular uses of the Internet.

Ethernet

A 10-megabit/second standard for local area networks (LANs), initially 
developed by Xerox, and later refined by Xerox, DEC, and Intel.  All hosts 
are connected to a coaxial cable where they contend for network access 
according to the CSMA/CD protocol.  

Email (or E-mail)

Shortspeak for electronic mail (q.v.).
               
FDDI

Fiber Distribution Data Interface.  A newly emerging standard for a 
fiber-optic local area network (LAN) running at 100 megabits/second.

Field

In computer messages, data files, and programs, a field is a group of 
characters that is treated as a unit.  For example, each TCP/IP packet 
contains fields for addressing and routing information (see route).

Internet users may encounter fields in the header of an electronic mail 
message.  The fields are lines that begin with a field-name followed by 
a colon and a space.  To: and From: are the only required header fields, 
but there are optional standard fields for the user, and fields that are 
added by the mail delivery system.  The format of email messages is 
defined in RFC-822.  
               
File Server

A computer whose principal purpose is to store files and provide 
network access to those files.
               
Fragment

A piece of a packet.  When a gateway is forwarding a maximum size IP 
(see TCP/IP) packet to a network that has a smaller maximum packet 
size, it is forced to break up that packet into multiple fragments for 
transport on the new network.  These fragments will be  reassembled 
by the IP layer at the destination host (or possibly by an intermediate 
gateway under some circumstances).
               
Frame

An assembly of bits at the Data Link layer of the ISO protocol stack.  
This collection of bits begins with some bits used for header 
information, and ends with some checksum bits used for error 
detection and/or correction.  All bits between the header and the 
checksum are data.      

FTAM

File Transfer, Access, and Management.  An application layer protocol 
for moving and manipulating files.
               
FTP

File Transfer Protocol. A protocol permitting a user on one Internet 
host to access and transfer files to another host over a network, such 
as the Internet.  FTP is usually the name not only of the protocol, but 
also of the program the user invokes to execute the protocol (e.g., ftp 
host.bbn.com).  This protocol is usually layered on top of TCP and IP 
(see TCP/IP).  FTP is available on several operating systems.  You can 
use the ftp command to copy computer files that contain a variety of 
information, such as software, documentation, or maps.  


Gateway

A computer used to connect together one or more networks.  This 
computer is seen as a host by the networks to which it is connected, 
but is capable of forwarding packets from one network to another.   
Gateways are also responsible for providing and receiving routing 
information to other gateways in the Internet so that they will know 
the best routes for sending packets between networks.  One may think 
of a gateway as a packet switch with whole computer networks as its 
communication links.

       
GOSIP

Government OSI Profile.  GOSIP is a collection of ISO specifications for 
mixed-vendor networks for use by the government.  Government 
networks are mandated to support GOSIP in the not-too-distant future. 
               
Header

The header is information that appears at the top of an electronic mail 
message.  See field.
   
HELLO

An inter-packet switch protocol used in the NSFNET to determine 
shortest delay routing (see route).  This protocol is only used among 
packet switches that trust each other.
               
Host

A computer that allows users to communicate with other host 
computers on a network.  Individual users communicate by using 
application programs, such as electronic mail, TELNET, and FTP.
               
ICMP

Internet Control Message Protocol.  This protocol is an integral part of 
the Internet Protocol (IPÑsee TCP/IP). The protocol is used to exchange 
error and control information among IP hosts.  For example, a gateway 
that is sent an IP datagram for which it is not the best route would 
send an ICMP redirect packet back to the originating host to inform it 
of the best route.  ICMP implementations also provide fault isolation 
capabilities such as packet echo.

IEEE 802

The IEEE standards for local and metropolitan area networks (see LAN 
and MAN).  This class of standards is further broken down by type of 
network, each of which is specified by digits after a decimal point.  For 
example, the Ethernet standard is 802.3; IBM Token Ring is IEEE 802.5.

IEN

This stands for Internet Engineering Notes.   


IMP

Interface Message Processor.  This was the name for the original 
packet switches used in the ARPANET and MILNET.   Today, the term 
Packet Switch Node or PSN is in more common usage.

Internet Address

A thirty-two-bit number that uniquely identifies an Internet host. This 
address is typically represented in eight-bit numbers (octets) 
separated by dots, e.g., 128.89.1.132.  An Internet address consists of a 
network number and a host number, and may be a class A, B, or C 
address.  A class A network address is formatted as N.H.H.H, providing 
seven bits of network number and twenty-four bits of host number (e.g., 
26.0.0.117 indicates host 117 on net 26).  A Class B network address is 
formatted as N.N.H.H, providing fourteen bits of network number and 
sixteen bits of host number (e.g.,128.89.1.132 indicates host 1.132 on 
net number 128.89).  A Class C network address is formatted as N.N.N.H, 
providing twenty-two bits of network number and eight bits of host 
address (e.g.,192.1.14.28 indicates host 28 on network number 
192.1.14).  

The Internet is the interconnection of many networks throughout the 
world that speak the same language, namely the TCP/IP protocol suite.  
Internet with a capital I refers specifically to that internet that 
contains NSFNET, MILNET, and DDN.

You may see "internet" with a small "i."  This can refer to any network 
built out of the TCP/IP protocol suite, or it might refer to networks 
using other protocol families that are composites of smaller networks. 

Internet

               
ISDN

Integrated Services Digital Network.  A public digital network designed 
to integrate voice and non-voice traffic.  This system is intended to be 
a  replacement for our current analog telephone systems, and as such is 
being standardized by the CCITT.    
               
ISO

International Standards Organization.  The international body 
responsible for establishing multivendor networking  standards.

      
Layer

Communication networks for computers may be organized as a set of 
more
or less independent protocols, each in a different layer (also called 
level).  The lowest layer governs direct host-to-host communication 
between the hardware at different hosts; the highest consists of user 
applications.  Each layer builds on the layer beneath it.  For each layer, 
programs at different hosts use protocols appropriate to the layer to 
communicate with each other.

TCP/IP has five layers of protocols, and OSI  
has seven.  The advantage of different layers of protocols is that the 
methods of passing information from one layer to another is specified 
clearly as part of the protocol suite, and changes within a protocol 
layer are prevented from affecting the other layers.  This greatly 
simplifies the task of designing and maintaining communication 
programs.

LAN

Local Area Network.  A data network intended to serve an area of only a 
few square kilometers or less.   Because the network is known to cover 
only a small area, optimizations can be made in the network signal 
protocols that permit data rates in the 10-megabyte-per-second to 
100-megabytes-per-second range today.  Wide-area communication is 
accomplished by connecting LANs together via metropolitan area 
networks (MANs) or wide-area networks (WANs).  Both Ethernet and 
FDDI are local area networks.
               
LocalTalk

A local area network (LAN) protocol developed by Apple Computer.  This 
network is designed to run over twisted pairs of telephone wire and has 
a data rate of 235 kilobits/second.  All Macintosh computers contain a 
LocalTalk interface.
               
Mail Bridge

A mail gateway that forwards electronic mail between two or more 
networks while ensuring that the messages it forwards meet certain 
administrative criteria.  A mail bridge is simply a specialized form of 
mail gateway that enforces an administrative policy with regard to 
what mail it forwards.
               
Mail Gateway

A network host that forwards electronic mail between two or more 
possibly dissimilar networks.  In the process of forwarding the mail, 
the gateway may have to reformat addresses and mail headers to 
conform with the electronic mail standards of the destination network.  
               
MAN

Metropolitan Area Network.  A data network intended to serve an area 
approximating that of a large city.  Such networks are being 
implemented by innovative techniques such as running fiber cables 
through subway tunnels.

MAP

Manufacturing Automation Protocol.  A protocol stack developed by 
General Motors following the OSI model that guarantees access to each 
host within a certain maximum time.  At the upper layers, it includes 
many of the OSI standards.  At the lower layers, it is based upon Token 
Bus (IEEE 802.4).

      
Message	

"Message" has multiple meanings:

1)  A user-defined collection of data sent 
     over a network.  

2)  A piece of text displayed on a terminal 
     screen that was sent by a user or a 
     program. 

3)  A collection of data sent from one 
     computer programming entity to 
     another. 


MILNET

MILitary NETwork.  This network was created in 1984 from parts of the 
original ARPANET.  The military users wished to have an operational 
production network, while the research community wished to have a 
network on which to continue experimenting in networking.  Therefore, 
the military users were placed on MILNET, the research users were 
placed on ARPANET, and the two networks were connected with mail 
bridges and gateways.  Today, MILNET is one of the class A networks in 
the Internet.   

MTU

Maximum Transmission Unit.  The largest  number of bits that a 
network permits to be transmitted as one packet.



NBS

National Bureau of Standards.  This organization, which was part of the 
U.S. Department of Commerce, was responsible for establishing 
standards in the United States.  It has since become the NIST.
               
Network

A computer network is a group of computers that can communicate 
electronically.  Networks can be composed of computers in a single 
building (Local Area Networks or LANs), or computers thousands of 
miles apart (Wide Area Networks or WANs).  The Internet is a 
worldwide collection of computer networks that can intercommunicate.  
The system manager and computer center staff at your site can provide 
information about your local network.

  
Network Address

A number or group of numbers that uniquely specifies a host on a 
network.  For example, 128.89.1.178 is the network address for 
nnsc.nsf.net.  Also, informally, an electronic mail address.  For 
example,  nnsc@nnsc.nsf.net is the network address for the NSF 
Network Service Center (NNSC).

NFS

Network File System.  This acronym describes a protocol developed by 
Sun Microsystems to allow a computer system to access files over a 
network as if they were on its local disks.  This protocol has been 
incorporated in products by more than two hundred companies, and is 
now a de facto Internet standard.


NIST

This stands for the National Institute for Standards and Technology 
(see NBS).

NOC

Network Operations Center.  A location from which the operation of a 
network or internet is monitored.  This center also usually serves as a 
clearinghouse for problems and efforts to resolve those problems.

NSF

National Science Foundation.  A government agency whose purpose is to 
promote the advancement of science.  NSF funds science researchers, 
scientific projects, and infrastructure to improve the quality of 
scientific research.  The NSFNET, funded by NSF, is an essential part of 
academic and research communications.

NTP

Network Time Protocol.  A protocol built on top of TCP (see TCP/IP) 
that assures accurate local time-keeping with reference to radio and 
atomic clocks located on the Internet.   This protocol is capable of 
synchronizing distributed clocks within milliseconds over long time 
periods.

ODA

Office Document Architecture.  This emerging standard defines ways in 
which text, graphics, and facsimile documents can be moved over a 
multivendor network.

OSI

Open Systems Interconnect.  Usually used as shorthand for the Open 
Systems Interconnection Reference Model (OSI Reference Model).  

OSI Reference Model

A seven-layer structure designed to describe computer network 
architectures and the way that data passes through them. This model 
was developed by the ISO in 1978 to clearly define the interfaces in 
multivendor networks, and to provide users of those networks with 
conceptual guidelines in the construction of such networks.

Packet

A collection of data sent as a unit along a packet network.  Packets are 
self-contained; each packet has its own source address and destination 
address and cannot exceed a maximum size.  Long messages are broken 
up into multiple packets for transmission over the network.

Packet Switch

See PSN.

PAD

Packet Assembler/Disassembler.  A network host designed to interface 
terminals to a packet network.

PING

Packet Internet Groper.  A program that sends packets to a remote host 
on the Internet and looks for replies.  This program works via the 
echoing facility provided by the ICMP protocol and is a way to 
determine if an Internet host is reachable from your host.		

Protocol

A mutually agreed procedure for communicating information between 
two parties.  Standard protocols are the basis for all computer 
communication.

PSN

Packet Switch Node.  A dedicated computer whose purpose is to accept, 
route, and forward packets in a packet switched network.

RDP

Reliable Datagram Protocol.  An Internet standard protocol for reliably 
sending datagrams between user programs.  This protocol is like UDP, 
but guarantees delivery and does retransmission as necessary.  This 
protocol is built on top of IP (see TCP/IP) and uses IP for datagram 
delivery.

RFC-733

An obsolete version of the Request for Comments (Standard for the 
format of ARPA Internet Test Messages, August 16, 1982) that 
specifies the format of electronic mail messages.  See RFC-822.

RFC-822

The current version of the Request for Comments that specifies the 
format of electronic mail messages.

RFC

Request for Comments.  RFCs are the principal documents used on the 
Internet to propose new protocols and services.  These documents are 
published as electronic documents on nic.ddn.mil  by the DDN NIC.

RIP

Routing Information Protocol.  A routing (see route) protocol provided 
in the Berkeley UNIX (see BSD) operating system, that permits a group 
of hosts located on a local network to share routing information.  This 
function is provided by the program routed.

Route

A path from one Internet host to another.

rcp

Remote copy.  A program and protocol provided in  the Berkeley UNIX 
operating system (see BSD) that permits files to be copied from one 
computer to another by an extension to the syntax of the UNIX cp (copy) 
command.  This protocol is largely implemented among UNIX machines, 
but the protocol is general enough that non-UNIX machines may use it.  
However, rcp does not provide the word-length adaptability and 
flexibility that the FTP protocol does.

rlogin

Remote login.  A program and protocol provided in Berkeley UNIX (see 
BSD) that permits a user on one computer to log in to another computer.  
This protocol is largely implemented among UNIX machines, but the 
protocol is general enough that non-UNIX machines may use it.  For 
example, Excelan ANNEX terminal concentrators permit users on dumb 
terminals to use the rlogin protocol to communicate with Internet 
computers.

Router

A device that chooses routings for packets.  This is a generic term and 
applies to such diverse devices as bridges (which pass packets from 
one physical LAN to another with almost no interpretation) and WAN 
gateways (which pass packets from one wide area network to another, 
doing fragmentation and reassembly as necessary). 

Server

A computer system or process that provides a service for other 
computer systems or processes to access.  A supercomputer can be 
thought of as a computation server.  A program that provides Internet 
File Transfer Protocol (FTP) access to local files is usually called an 
FTP server.

SMTP

Simple Mail Transfer Protocol.  This Internet standard network protocol 
is used to move electronic mail messages from one host to another.

SNA

Systems Network Architecture.  A proprietary networking architecture 
used by IBM and IBM-compatible mainframe computers.  Because of its 
widespread use, SNA is a de facto standard.  While it can use packet 
switched networks for transport, SNA is largely a circuit-switching 
rather than a packet-switching technology.

SNMP

Simple Network Monitoring Protocol.  This Internet standard protocol is 
used  by a network monitoring center to gather information regarding 
the status of hosts on its network or on the Internet.

Source Address

The network address of the host that originates a packet.

SPAG

Standards Promotion and Applications Group.  This European 
organization collaborates with COS to promote testing procedures and 
techniques for OSI products.

Switch

A computer responsible for routing (see route) packets in a packet 
switched network.  

T1

A communications service over leased lines and microwave links that 
runs at 1.544 megabytes per second.  The major links of the NSFNET are 
T1.  Faster services such as T3 (45 megabytes per second) are 
available, although they are not yet off-the-shelf products.  The 
NSFNET is in the process of upgrading to T3, and plans much higher 
transmission rates for the future.

TCP/IP

Transmission Control Protocol/Internet Protocol.  A Department of 
Defense standard protocol suite encompassing both network and 
transport level protocols.  While the terms TCP and IP specify two 
protocols, common usage of the two terms together has come to 
represent the entire DoD protocol suite based upon these protocols, 
including Telnet, FTP, UDP, and RDP.  Technically, this is incorrect 
usage, because other protocol stacks can be layered on top of TCP and 
IP that provide similar services, but are not part of the DoD standard 
protocols (e.g., TP-4/IP, FTAM on TCP, etc.).  Ideally, one should only 
use TCP/IP to mean the TCP protocol layered on top of the IP protocol.

TELENET

A commercial wide-area packet switching X.25 network.

TELNET

Telnet is a program that allows a computer user at one site to work on 
a computer at another site.  It is the Internet standard protocol for 
remote terminal connection service.   

Telnet requires Internet access, that is, you must be on a TCP/IP 
network that gateways to the Internet.  Unlike FTP and electronic mail, 
Telnet actually exposes you to the commands and programs of the 
remote host.

For example, you can use the telnet command to run a program in your 
directory on a supercomputer hundreds of miles away. 

TOP

Technical/Office Protocol.  A protocol stack for office automation 
developed by Boeing following the OSI model.  This protocol is very 
similar to MAP except at the lowest levels, where it uses Ethernet 
(IEEE 802.3) rather than Token Bus (IEEE 802.4).

TP-4/IP

The ISO protocol suite that performs the same functions as TCP/IP.  
TP-4 provides reliable, connection-oriented data streams using 
datagrams.  This protocol also handles error detection, synchronization, 
and retransmission, just as TCP does.

TTL

Time To Live.  A field in a datagram designed to prevent packets from 
looping indefinitely in the Internet.  Because routing information 
changes dynamically, two or more gateways may occasionally forward 
packets to each other in a loop, since each believes the other is the 
best route to the destination.  A packet is initially sent with a nonzero 
TTL field, and each gateway that forwards that packet decrements the 
value in that field.  Once the value reaches zero, a loop is assumed and 
the packet is discarded.  

UDP

User Datagram Protocol.  The Internet standard protocol for sending 
datagrams between user programs.  This protocol neither guarantees 
delivery nor does it require a connection.  As a result it is lightweight 
and efficient, but requires the application to do all error processing 
and retransmissions.  This protocol is built on top of IP and uses IP for 
datagram delivery (see TCP/IP).

UUCP

UNIX-to-UNIX-CoPy.  This was initially a program run under the UNIX 
operating system (see BSD) that permitted one UNIX system to send 
files to another UNIX system via dial-up phone lines.  Today, the term is 
more commonly used to describe the large international network made 
up of these machines using the UUCP protocol to pass netnews and 
electronic mail.

X.25

A standard networking protocol suite approved by the CCITT and ISO.  
This protocol suite defines standard physical, link, and networking 
layers only (layers 1 through 3).  X.25 networks are in use throughout 
the world.

X.400

The CCITT standard for electronic mail.  X.400 systems are in use in 
Europe, Canada, and several U.S. commercial installations.

X.500

The CCITT standard for electronic mail directory services.

XNS

Xerox Network Services.  A proprietary networking architecture 
developed by Xerox.