   This file documents Taylor UUCP, version 1.06.

   Copyright (C) 1992, 1993, 1994, 1995 Ian Lance Taylor

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the section entitled "Copying" are included exactly as in the
original, and provided that the entire resulting derived work is
distributed under the terms of a permission notice identical to this
one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the section entitled "Copying" may be included in
a translation approved by the author instead of in the original English.

UUCP `y' Protocol
=================

The `y' protocol was developed by Jorge Cwik for use in FX UUCICO, a PC
uucico program.  It is designed for communication lines which handle
error correction and flow control.  It requires an eight bit clean
connection.  It performs error detection, but not error correction:
when an error is detected, the line is dropped.  It is a streaming
protocol, like the `f' protocol; there are no packet acknowledgements,
so the protocol is efficient over a half-duplex communication line such
as PEP.

   Every packet contains a six byte header:

sequence low byte
sequence high byte
     A two byte sequence number, in little endian order.  The first
     sequence number is 0.  Since the first packet is always a sync
     packet (described below) the sequence number of the first data
     packet is always 1.  Each system counts sequence numbers
     independently.

length low byte
length high byte
     A two byte data length, in little endian order.  If the high bit
     of the sixteen bit field is clear, this is the number of data
     bytes which follow the six byte header.  If the high bit is set,
     there is no data, and the length field is a type of control packet.

checksum low byte
checksum high byte
     A two byte checksum, in little endian order.  The checksum is
     computed over the data bytes.  The checksum algorithm is described
     below.  If there are no data bytes, the checksum is sent as 0.

   When the protocol starts up, each side must send a sync packet.
This is a packet with a normal six byte header followed by data.  The
sequence number of the sync packet should be 0.  Currently at least
four bytes of data must be sent with the sync packet.  Additional bytes
should be ignored.  They are defined as follows:

version
     The version number of the protocol.  Currently this must be 1.
     Larger numbers should be ignored; it is the responsibility of the
     newer version to accommodate the older one.

packet size
     The maximum data length to use divided by 256.  This is sent as a
     single byte.  The maximum data length permitted is 32768, which
     would be sent as 128.  Customarily both systems will use the same
     maximum data length, the lower of the two requested.

flags low byte
flags high byte
     Two bytes of flags.  None are currently defined.  These bytes
     should be sent as 0, and ignored by the receiver.

   A length field with the high bit set is a control packet.  The
following control packet types are defined:

0xfffe `YPKT_ACK'
     Acknowledges correct receipt of a file.

0xfffd `YPKT_ERR'
     Indicates an incorrect checksum.

0xfffc `YPKT_BAD'
     Indicates a bad sequence number, an invalid length, or some other
     error.

   If a control packet other than `YPKT_ACK' is received, the
connection is dropped.  If a checksum error is detected for a received
packet, a `YPKT_ERR' control packet is sent, and the connection is
dropped.  If a packet is received out of sequence, a `YPKT_BAD' control
packet is sent, and the connection is dropped.

   The checksum is initialized to 0xffff.  For each data byte in a
packet it is modified as follows (where B is the byte before it has been
transformed as described above):

           /* Rotate the checksum left.  */
           if ((ichk & 0x8000) == 0)
             ichk <<= 1;
           else
             {
               ichk <<= 1;
               ++ichk;
             }

           /* Add the next byte into the checksum.  */
           ichk += B;

   This is the same algorithm as that used by the `f' protocol.

   A command is sent as a sequence of data packets followed by a null
byte.  In the normal case, a command will fit into a single packet.
The packet should be exactly the length of the command plus a null
byte.  If the command is too long, more packets are sent as required.

   A file is sent as a sequence of data packets, ending with a zero
length packet.  The data packets may be of any length greater than zero
and less than or equal to the maximum permitted packet size specified
in the initial sync packet.

   After the zero length packet ending a file transfer has been
received, the receiving system sends a `YPKT_ACK' control packet.  The
sending system waits for the `YPKT_ACK' control packet before
continuing; this wait should be done with a large timeout, since there
may be a considerable amount of data buffered on the communication path.

UUCP `d' Protocol
=================

The `d' protocol is apparently used for DataKit muxhost (not RS-232)
connections.  No file size is sent.  When a file has been completely
transferred, a write of zero bytes is done; this must be read as zero
bytes on the other end.

UUCP `h' Protocol
=================

The `h' protocol is apparently used in some places with HST modems.  It
does no error checking, and is not that different from the `t'
protocol.  I don't know the details.

UUCP `v' Protocol
=================

The `v' protocol is used by UUPC/extended, a PC UUCP program.  It is
simply a version of the `g' protocol which supports packets of any
size, and also supports sending packets of different sizes during the
same conversation.  There are many `g' protocol implementations which
support both, but there are also many which do not.  Using `v' ensures
that everything is supported.

Hacking Taylor UUCP
*******************

This chapter provides the briefest of guides to the Taylor UUCP source
code itself.

System Dependence
=================

The code is carefully segregated into a system independent portion and a
system dependent portion.  The system dependent code is in the `unix'
subdirectory, and also in the file `sysh.unx' (also known as
`sysdep.h').

   With the right configuration parameters, the system independent code
calls only ANSI C functions.  Some of the less common ANSI C functions
are also provided in the `lib' directory.  The replacement function
`strtol' in `lib/strtol.c' assumes that the characters `A' to `F' and
`a' to `f' appear in strictly sequential order.  The function
`igradecmp' in `uuconf/grdcmp.c' assumes that the upper and lower case
letters appear in order.  Both assumptions are true for ASCII and
EBCDIC, but neither is guaranteed by ANSI C.  Disregarding these
caveats, I believe that the system independent portion of the code is
strictly conforming.

   That's not too exciting, since all the work is done in the system
dependent code.  I think that this code can conform to POSIX 1003.1,
given the right compilation parameters.  I'm a bit less certain about
this, though.

   The code has been used on a 16 bit segmented system with no function
prototypes, so I'm fairly certain that all casts to long and pointers
are done when necessary.

Naming Conventions
==================

I use a modified Hungarian naming convention for my variables and
functions.  As with all naming conventions, the code is rather opaque if
you are not familiar with it, but becomes clear and easy to use with
time.

   The first character indicates the type of the variable (or function
return value).  Sometimes additional characters are used.  I use the
following type prefixes:

`a'
     array; the next character is the type of an element

`b'
     byte or character

`c'
     count of something

`e'
     stdio FILE *

`f'
     boolean

`i'
     generic integer

`l'
     double

`o'
     file descriptor (as returned by open, creat, etc.)

`p'
     generic pointer

`q'
     pointer to structure

`s'
     structure

`u'
     void (function return values only)

`z'
     character string

   A generic pointer (`p') is sometimes a `void *', sometimes a
function pointer in which case the prefix is pf, and sometimes a pointer
to another type, in which case the next character is the type to which
it points (pf is overloaded).

   An array of strings (`char *[]') would be named `az' (array of
string).  If this array were passed to a function, the function
parameter would be named `paz' (pointer to array of string).

   Note that the variable name prefixes do not necessarily indicate the
type of the variable.  For example, a variable prefixed with `i' may be
int, long or short.  Similarly, a variable prefixed with `b' may be a
char or an int; for example, the return value of `getchar' would be
caught in an int variable prefixed with `b'.

   For a non-local variable (extern or file static), the first character
after the type prefix is capitalized.

   Most static variables and functions use another letter after the type
prefix to indicate which module they come from.  This is to help
distinguish different names in the debugger.  For example, all static
functions in `protg.c', the `g' protocol source code, use a module
prefix of `g'.  This isn't too useful, as a number of modules use a
module prefix of `s'.

Patches
=======

I am always grateful for any patches sent in.  Much of the flexibility
and portability of the code is due to other people.  Please do not
hesitate to send me any changes you have found necessary or useful.

   When sending a patch, please send the output of the Unix `diff'
program invoked with the `-c' option (if you have the GNU version of
`diff', use the `-p' option).  Always invoke `diff' with the original
file first and the modified file second.

   If your `diff' does not support `-c' (or you don't have `diff'),
send a complete copy of the modified file (if you have just changed a
single function, you can just send the new version of the function).
In particular, please do not send `diff' output without the `-c'
option, as it is useless.

   If you have made a number of changes, it is very convenient for me if
you send each change as a separate mail message.  Sometimes I will think
that one change is useful but another one is not.  If they are in
different messages it is much easier for me to apply one but not the
other.

   I rarely apply the patches directly.  Instead I work my way through
the hunks and apply each one separately.  This ensures that the naming
remains consistent, and that I understand all the code.

   If you can not follow all these rules, then don't.  But if you do, it
makes it more likely that I will incorporate your changes.  I am not
paid for my UUCP work, and my available time is unfortunately very
restricted.  The package is important to me, and I do what I can, but I
can not do all that I would like, much less all that everybody else
would like.

   Finally, please do not be offended if I do not reply to messages for
some time, even a few weeks.  I am often behind on my mail, and if I
think your message deserves a considered reply I will often put it aside
until I have time to deal with it.

Acknowledgements
****************

This is a list of people who gave help or suggestions while I was
working on the Taylor UUCP project.  Appearance on this list does not
constitute endorsement of the program, particularly since some of the
comments were criticisms.  I've probably left some people off, and I
apologize for any oversight; it does not mean your contribution was
unappreciated.

   First of all, I would like to thank the people at Infinity
Development Systems (formerly AIRS, which lives on in the domain name)
for permitting me to use their computers and `uunet' access.  I would
also like to thank Richard Stallman `<rms@gnu.ai.mit.edu>' for founding
the Free Software Foundation, and John Gilmore `<gnu@cygnus.com>' for
writing the initial version of gnuucp which was a direct inspiration
for this somewhat larger project.  Chip Salzenberg `<chip@tct.com>' has
contributed many patches.  Franc,ois Pinard `<pinard@iro.umontreal.ca>'
tirelessly tested the code and suggested many improvements.  He also
put together the initial version of this manual.  Doug Evans
contributed the zmodem protocol.  Marc Boucher `<marc@CAM.ORG>'
contributed the code supporting the pipe port type.  Jorge Cwik
`jorge@laser.satlink.net' contributed the `y' protocol code.  Finally,
Verbus M. Counts `<verbus@westmark.com>' and Centel Federal Systems,
Inc., deserve special thanks, since they actually paid me money to port
this code to System III.

   In alphabetical order:

     "Earle F. Ake - SAIC" `<ake@Dayton.SAIC.COM>'
     `mra@searchtech.com' (Michael Almond)
     `cambler@zeus.calpoly.edu' (Christopher J. Ambler)
     Brian W. Antoine `<briana@tau-ceti.isc-br.com>'
     `jantypas@soft21.s21.com' (John Antypas)
     `james@bigtex.cactus.org' (James Van Artsdalen)
     `jima@netcom.com' (Jim Avera)
     `nba@sysware.DK' (Niels Baggesen)
     `uunet!hotmomma!sdb' (Scott Ballantyne)
     Zacharias Beckman `<zac@dolphin.com>'
     `mike@mbsun.ann-arbor.mi.us' (Mike Bernson)
     `bob@usixth.sublink.org' (Roberto Biancardi)
     `statsci!scott@coco.ms.washington.edu' (Scott Blachowicz)
     `bag%wood2.cs.kiev.ua@relay.ussr.eu.net' (Andrey G Blochintsev)
     `spider@Orb.Nashua.NH.US' (Spider Boardman)
     Gregory Bond `<gnb@bby.com.au>'
     Marc Boucher `<marc@CAM.ORG>'
     Ard van Breemen `<ard@cstmel.hobby.nl>'
     `dean@coplex.com' (Dean Brooks)
     `jbrow@radical.com' (Jim Brownfield)
     `dave@dlb.com' (Dave Buck)
     `gordon@sneaky.lonestar.org' (Gordon Burditt)
     `dburr@sbphy.physics.ucsb.edu' (Donald Burr)
     `mib@gnu.ai.mit.edu' (Michael I Bushnell)
     Brian Campbell `<brianc@quantum.on.ca>'
     Andrew A. Chernov `<ache@astral.msk.su>'
     `jhc@iscp.bellcore.com' (Jonathan Clark)
     `mafc!frank@bach.helios.de' (Frank Conrad)
     Ed Carp `<erc@apple.com>'
     `mpc@mbs.linet.org' (Mark Clements)
     `verbus@westmark.westmark.com' (Verbus M. Counts)
     `cbmvax!snark.thyrsus.com!cowan' (John Cowan)
     Bob Cunningham `<bob@soest.hawaii.edu>'
     `jorge@laser.satlink.net' (Jorge Cwik)
     `kdburg@incoahe.hanse.de' (Klaus Dahlenburg)
     Damon `<d@exnet.co.uk>'
     `celit!billd@UCSD.EDU' (Bill Davidson)
     `hubert@arakis.fdn.org' (Hubert Delahaye)
     `markd@bushwire.apana.org.au' (Mark Delany)
     Allen Delaney `<allen@brc.ubc.ca>'
     Gerriet M. Denkmann `gerriet@hazel.north.de'
     `denny@dakota.alisa.com' (Bob Denny)
     Drew Derbyshire `<ahd@kew.com>'
     `ssd@nevets.oau.org' (Steven S. Dick)
     `gert@greenie.gold.sub.org' (Gert Doering)
     `gemini@geminix.in-berlin.de' (Uwe Doering)
     Hans-Dieter Doll `<hd2@Insel.DE>'
     `deane@deane.teleride.on.ca' (Dean Edmonds)
     Mark W. Eichin `<eichin@cygnus.com>'
     `erik@pdnfido.fidonet.org'
     Andrew Evans `<andrew@airs.com>'
     `dje@cygnus.com' (Doug Evans)
     Marc Evans `<marc@synergytics.com>'
     Dan Everhart `<dan@dyndata.com>'
     `kksys!kegworks!lfahnoe@cs.umn.edu' (Larry Fahnoe)
     Matthew Farwell `<dylan@ibmpcug.co.uk>'
     `fenner@jazz.psu.edu' (Bill Fenner)
     `jaf@inference.com' (Jose A. Fernandez)
     "David J. Fiander" `<golem!david@news.lsuc.on.ca>'
     Thomas Fischer `<batman@olorin.dark.sub.org>'
     Mister Flash `<flash@sam.imash.ras.ru>'
     `louis@marco.de' (Ju"rgen Fluk)
     `erik@eab.retix.com' (Erik Forsberg)
     `andy@scp.caltech.edu' (Andy Fyfe)
     Lele Gaifax `<piggy@idea.sublink.org>'
     `Peter.Galbavy@micromuse.co.uk'
     `hunter@phoenix.pub.uu.oz.au' (James Gardiner [hunter])
     Terry Gardner `<cphpcom!tjg01>'
     `dgilbert@gamiga.guelphnet.dweomer.org' (David Gilbert)
     `ol@infopro.spb.su' (Oleg Girko)
     `jimmy@tokyo07.info.com' (Jim Gottlieb)
     Benoit Grange `<ben@fizz.fdn.org>'
     `elg@elgamy.jpunix.com' (Eric Lee Green)
     `ryan@cs.umb.edu' (Daniel R. Guilderson)
     `greg@gagme.chi.il.us' (Gregory Gulik)
     Richard H. Gumpertz `<rhg@cps.com>'
     Scott Guthridge `<scooter@cube.rain.com>'
     Michael Haberler `<mah@parrot.prv.univie.ac.at>'
     Daniel Hagerty `<hag@eddie.mit.edu>'
     `jh@moon.nbn.com' (John Harkin)
     `guy@auspex.auspex.com' (Guy Harris)
     `hsw1@papa.attmail.com' (Stephen Harris)
     Petri Helenius `<pete@fidata.fi>'
     `gabe@edi.com' (B. Gabriel Helou)
     Bob Hemedinger `<bob@dalek.mwc.com>'
     Andrew Herbert `<andrew@werple.pub.uu.oz.au>'
     `kherron@ms.uky.edu' (Kenneth Herron)
     Peter Honeyman `<honey@citi.umich.edu>'
     `jhood@smoke.marlboro.vt.us' (John Hood)
     Mike Ipatow `<mip@fido.itc.e-burg.su>'
     Bill Irwin `<bill@twg.bc.ca>'
     `pmcgw!personal-media.co.jp!ishikawa' (Chiaki Ishikawa)
     `ai@easy.in-chemnitz.de' (Andreas Israel)
     `iverson@lionheart.com' (Tim Iverson)
     `bei@dogface.austin.tx.us' (Bob Izenberg)
     `djamiga!djjames@fsd.com' (D.J.James)
     Rob Janssen `<cmgit!rob@relay.nluug.nl>'
     `harvee!esj' (Eric S Johansson)
     Kevin Johnson `<kjj@pondscum.phx.mcd.mot.com>'
     `rj@rainbow.in-berlin.de' (Robert Joop)
     Alan Judge `<aj@dec4ie.IEunet.ie>'
     `chris@cj_net.in-berlin.de' (Christof Junge)
     Romain Kang `<romain@pyramid.com>'
     `tron@Veritas.COM' (Ronald S. Karr)
     Brendan Kehoe `<brendan@cs.widener.edu>'
     `warlock@csuchico.edu' (John Kennedy)
     `kersing@nlmug.nl.mugnet.org' (Jac Kersing)
     `ok@daveg.PFM-Mainz.de' (Olaf Kirch)
     Gabor Kiss `<kissg@sztaki.hu>'
     `gero@gkminix.han.de' (Gero Kuhlmann)
     `rob@pact.nl' (Rob Kurver)
     "C.A. Lademann" `<cal@zls.gtn.com>'
     `kent@sparky.IMD.Sterling.COM' (Kent Landfield)
     Tin Le `<tin@saigon.com>'
     `lebaron@inrs-telecom.uquebec.ca'  (Gregory LeBaron)
     `karl@sugar.NeoSoft.Com' (Karl Lehenbauer)
     `alex@hal.rhein-main.de' (Alexander Lehmann)
     `merlyn@digibd.com' (Merlyn LeRoy)
     `clewis@ferret.ocunix.on.ca' (Chris Lewis)
     `gdonl@ssi1.com' (Don Lewis)
     `libove@libove.det.dec.com' (Jay Vassos-Libove)
     `bruce%blilly@Broadcast.Sony.COM' (Bruce Lilly)
     Godfrey van der Linden `<Godfrey_van_der_Linden@NeXT.COM>'
     Ted Lindgreen `<tlindgreen@encore.nl>'
     `andrew@cubetech.com' (Andrew Loewenstern)
     "Arne Ludwig" `<arne@rrzbu.hanse.de>'
     Matthew Lyle `<matt@mips.mitek.com>'
     `djm@eng.umd.edu' (David J. MacKenzie)
     John R MacMillan `<chance!john@sq.sq.com>'
     `jum@helios.de' (Jens-Uwe Mager)
     Giles D Malet `<shrdlu!gdm@provar.kwnet.on.ca>'
     `mem@mv.MV.COM' (Mark E. Mallett)
     `pepe@dit.upm.es' (Jose A. Manas)
     `peter@xpoint.ruessel.sub.org' (Peter Mandrella)
     `martelli@cadlab.sublink.org' (Alex Martelli)
     W Christopher Martin `<wcm@geek.ca.geac.com>'
     Yanek Martinson `<yanek@mthvax.cs.miami.edu>'
     `thomasm@mechti.wupper.de' (Thomas Mechtersheimer)
     `jm@aristote.univ-paris8.fr' (Jean Mehat)
     `me@halfab.freiburg.sub.org' (Udo Meyer)
     `les@chinet.chi.il.us' (Leslie Mikesell)
     `bug@cyberdex.cuug.ab.ca' (Trever Miller)
     `mmitchel@digi.lonestar.org' (Mitch Mitchell)
     Emmanuel Mogenet `<mgix@krainte.jpn.thomson-di.fr>'
     `rmohr@infoac.rmi.de' (Rupert Mohr)
     Jason Molenda `<molenda@sequent.com>'
     `ianm@icsbelf.co.uk' (Ian Moran)
     `jmorriso@bogomips.ee.ubc.ca' (John Paul Morrison)
     `brian@ilinx.wimsey.bc.ca' (Brian J. Murrell)
     `service@infohh.rmi.de' (Dirk Musstopf)
     `lyndon@cs.athabascau.ca' (Lyndon Nerenberg)
     `rolf@saans.north.de' (Rolf Nerstheimer)
     `tom@smart.bo.open.de' (Thomas Neumann)
     `mnichols@pacesetter.com'
     Richard E. Nickle `<trystro!rick@Think.COM>'
     `stephan@sunlab.ka.sub.org' (Stephan Niemz)
     `nolan@helios.unl.edu' (Michael Nolan)
     david nugent `<david@csource.oz.au>'
     Jim O'Connor `<jim@bahamut.fsc.com>'
     `kevin%kosman.uucp@nrc.com' (Kevin O'Gorman)
     Petri Ojala `<ojala@funet.fi>'
     `oneill@cs.ulowell.edu' (Brian 'Doc' O'Neill)
     `Stephen.Page@prg.oxford.ac.uk'
     `abekas!dragoman!mikep@decwrl.dec.com' (Mike Park)
     Tim Peiffer `peiffer@cs.umn.edu'
     `don@blkhole.resun.com' (Don Phillips)
     "Mark Pizzolato 415-369-9366" `<mark@infocomm.com>'
     John Plate `<plate@infotek.dk>'
     `dplatt@ntg.com' (Dave Platt)
     `eldorado@tharr.UUCP' (Mark Powell)
     Mark Powell `<mark@inet-uk.co.uk>'
     `pozar@kumr.lns.com' (Tim Pozar)
     `joey@tessi.UUCP' (Joey Pruett)
     Paul Pryor `ptp@fallschurch-acirs2.army.mil'
     `putsch@uicc.com' (Jeff Putsch)
     `ar@nvmr.robin.de' (Andreas Raab)
     Jarmo Raiha `<jarmo@ksvltd.FI>'
     James Revell `<revell@uunet.uu.net>'
     Scott Reynolds `<scott@clmqt.marquette.Mi.US>'
     `mcr@Sandelman.OCUnix.On.Ca' (Michael Richardson)
     Kenji Rikitake `<kenji@rcac.astem.or.jp>'
     `arnold@cc.gatech.edu' (Arnold Robbins)
     `steve@Nyongwa.cam.org' (Steve M. Robbins)
     Ollivier Robert `<Ollivier.Robert@keltia.frmug.fr.net>'
     Serge Robyns `<sr@denkart.be>'
     Lawrence E. Rosenman `<ler@lerami.lerctr.org>'
     Jeff Ross `<jeff@wisdom.bubble.org>'
     Aleksey P. Rudnev `<alex@kiae.su>'
     "Heiko W.Rupp" `<hwr@pilhuhn.ka.sub.org>'
     `wolfgang@wsrcc.com' (Wolfgang S. Rupprecht)
     `tbr@tfic.bc.ca' (Tom Rushworth)
     `jsacco@ssl.com' (Joseph E. Sacco)
     `rsalz@bbn.com' (Rich Salz)
     Curt Sampson `<curt@portal.ca>'
     `sojurn!mike@hobbes.cert.sei.cmu.edu' (Mike Sangrey)
     Nickolay Saukh `<nms@ussr.EU.net>'
     `heiko@lotte.sax.de' (Heiko Schlittermann)
     Eric Schnoebelen `<eric@cirr.com>'
     `russell@alpha3.ersys.edmonton.ab.ca' (Russell Schulz)
     `scott@geom.umn.edu'
     Igor V. Semenyuk `<iga@argrd0.argonaut.su>'
     Christopher Sawtell `<chris@gerty.equinox.gen.nz>'
     `schuler@bds.sub.org' (Bernd Schuler)
     `uunet!gold.sub.org!root' (Christian Seyb)
     `s4mjs!mjs@nirvo.nirvonics.com' (M. J. Shannon Jr.)
     `shields@tembel.org' (Michael Shields)
     `peter@ficc.ferranti.com' (Peter da Silva)
     `vince@victrola.sea.wa.us' (Vince Skahan)
     `frumious!pat' (Patrick Smith)
     `roscom!monty@bu.edu' (Monty Solomon)
     `sommerfeld@orchard.medford.ma.us' (Bill Sommerfeld)
     Julian Stacey `<stacey@guug.de>'
     `evesg@etlrips.etl.go.jp' (Gjoen Stein)
     Harlan Stenn `<harlan@mumps.pfcs.com>'
     Ralf Stephan `<ralf@ark.abg.sub.org>'
     `johannes@titan.westfalen.de' (Johannes Stille)
     `chs@antic.apu.fi' (Hannu Strang)
     `ralf@reswi.ruhr.de' (Ralf E. Stranzenbach)
     `sullivan@Mathcom.com' (S. Sullivan)
     Shigeya Suzuki `<shigeya@dink.foretune.co.jp>'
     `kls@ditka.Chicago.COM' (Karl Swartz)
     `swiers@plains.NoDak.edu'
     Oleg Tabarovsky `<olg@olghome.pccentre.msk.su>'
     `ikeda@honey.misystems.co.jp' (Takatoshi Ikeda)
     John Theus `<john@theus.rain.com>'
     `rd@aii.com' (Bob Thrush)
     ppKarsten Thygesen `<karthy@dannug.dk>'
     Graham Toal `<gtoal@pizzabox.demon.co.uk>'
     `rmtodd@servalan.servalan.com' (Richard Todd)
     Martin Tomes `<mt00@controls.eurotherm.co.uk>'
     Len Tower `<tower-prep@ai.mit.edu>'
     Mark Towfiq `<justice!towfiq@Eingedi.Newton.MA.US>'
     `mju@mudos.ann-arbor.mi.us' (Marc Unangst)
     Matthias Urlichs `<urlichs@smurf.noris.de>'
     Tomi Vainio `<tomppa@fidata.fi>'
     `a3@a3.xs4all.nl' (Adri Verhoef)
     Andrew Vignaux `<ajv@ferrari.datamark.co.nz>'
     `vogel@omega.ssw.de' (Andreas Vogel)
     Dima Volodin `<dvv@hq.demos.su>'
     `jos@bull.nl' (Jos Vos)
     `jv@nl.net' (Johan Vromans)
     David Vrona `<dave@sashimi.wwa.com>'
     `Marcel.Waldvogel@nice.usergroup.ethz.ch' (Marcel Waldvogel)
     `steve@nshore.org' (Stephen J. Walick)
     `syd@dsinc.dsi.com' (Syd Weinstein)
     `gerben@rna.indiv.nluug.nl' (Gerben Wierda)
     `jbw@cs.bu.edu' (Joe Wells)
     `frnkmth!twwells.com!bill' (T. William Wells)
     Peter Wemm `<Peter_Wemm@zeus.dialix.oz.au>'
     `mauxci!eci386!woods@apple.com' (Greg A. Woods)
     `John.Woods@proteon.com' (John Woods)
     Michael Yu.Yaroslavtsev `<mike@yaranga.ipmce.su>'
     Alexei K. Yushin `<root@july.elis.crimea.ua>'
     `jon@console.ais.org' (Jon Zeeff)
     Matthias Zepf `<agnus@amylnd.stgt.sub.org>'
     Eric Ziegast `<uunet!ziegast>'