More info about UUCP

1 files changed, 1603 insertions, 0 deletions

diff --git a/share/FAQ/UUCP_Internals.FAQ b/share/FAQ/UUCP_Internals.FAQ
new file mode 100644
index 000000000000..b927122caa5a
--- /dev/null
+++ b/share/FAQ/UUCP_Internals.FAQ
@@ -0,0 +1,1603 @@
+Path: bloom-beacon.mit.edu!cambridge-news.cygnus.com!comton.airs.com!ian
+From: ian@airs.com (Ian Lance Taylor)
+Newsgroups: comp.mail.uucp,comp.answers,news.answers
+Subject: UUCP Internals Frequently Asked Questions
+Keywords: UUCP, protocol, FAQ
+Message-ID: <uucp-internals_787915801@airs.com>
+Date: 20 Dec 94 09:30:02 GMT
+Expires: 31 Jan 95 09:30:01 GMT
+Reply-To: ian@airs.com (Ian Lance Taylor)
+Followup-To: comp.mail.uucp
+Organization: Infinity Development, Waltham, MA
+Lines: 1587
+Approved: news-answers-request@MIT.Edu
+Supersedes: <uucp-internals_785496601@airs.com>
+Xref: bloom-beacon.mit.edu comp.mail.uucp:5270 comp.answers:9043 news.answers:31575
+
+Archive-name: uucp-internals
+Version: $Revision: 1.26 $
+Last-modified: $Date: 1994/10/26 02:39:07 $
+
+ This article was written by Ian Lance Taylor <ian@airs.com> and I may
+ even update it periodically.  Please send me mail about suggestions
+ or inaccuracies.
+
+ This article describes how the various UUCP protocols work, and
+ discusses some other internal UUCP issues.  It does not describe how
+ to configure UUCP, nor how to solve UUCP connection problems, nor how
+ to deal with UUCP mail.  I do not know of any FAQ postings on these
+ topics.  There are some documents on the net describing UUCP
+ configuration, but I can not keep an up to date list here; try using
+ archie.
+
+ If you haven't read the news.announce.newusers articles, read them.
+
+ This article is in digest format.  Some newsreaders will be able to
+ break it apart into separate articles.  Please don't ask me how to do
+ this, though.
+
+ This article answers the following questions.  If one of these
+ questions is posted to comp.mail.uucp, please send mail to the poster
+ referring her or him to this FAQ.  There is no reason to post a
+ followup, as most of us know the answer already.
+
+Sources
+What does "alarm" mean in debugging output?
+What are UUCP grades?
+What is the format of a UUCP lock file?
+What is the format of a UUCP X.* file?
+What is the UUCP protocol?
+What is the 'g' protocol?
+What is the 'f' protocol?
+What is the 't' protocol?
+What is the 'e' protocol?
+What is the 'G' protocol?
+What is the 'i' protocol?
+What is the 'j' protocol?
+What is the 'x' protocol?
+What is the 'y' protocol?
+What is the 'd' protocol?
+What is the 'h' protocol?
+What is the 'v' protocol?
+Thanks
+
+----------------------------------------------------------------------
+
+From: Sources
+Subject: Sources
+
+"Unix-to-Unix Copy Program," said PDP-1.  "You will never find a more
+wretched hive of bugs and flamers.  We must be cautious."
+                                                --DECWars
+
+I took a lot of the information from Jamie E. Hanrahan's paper in the
+Fall 1990 DECUS Symposium, and from Managing UUCP and Usenet by Tim
+O'Reilly and Grace Todino (with contributions by several other
+people).  The latter includes most of the former, and is published by
+        O'Reilly & Associates, Inc.
+        103 Morris Street, Suite A
+        Sebastopol, CA 95472
+It is currently in its tenth edition.  The ISBN number is
+0-937175-93-5.
+
+Some information is originally due to a Usenet article by Chuck
+Wegrzyn.  The information on execution files comes partially from
+Peter Honeyman.  The information on the 'g' protocol comes partially
+from a paper by G.L. Chesson of Bell Laboratories, partially from
+Jamie E. Hanrahan's paper, and partially from source code by John
+Gilmore.  The information on the 'f' protocol comes from the source
+code by Piet Berteema.  The information on the 't' protocol comes from
+the source code by Rick Adams.  The information on the 'e' protocol
+comes from a Usenet article by Matthias Urlichs.  The information on
+the 'd' protocol comes from Jonathan Clark, who also supplied
+information about QFT.  The FSUUCP information comes straight from
+Christopher J. Ambler; it applies to version 1.4 and up.
+
+Although there are few books about UUCP, there are many about networks
+and protocols in general.  I recommend two non-technical books which
+describe the sorts of things that are available on the network: ``The
+Whole Internet,'' by Ed Krol, and ``Zen and the Art of the Internet,''
+by Brendan P. Kehoe.  Good technical discussions of networking issues
+can be found in ``Internetworking with TCP/IP,'' by Douglas E. Comer
+and David L. Stevens and in ``Design and Validation of Computer
+Protocols'' by Gerard J. Holzmann.
+
+------------------------------
+
+From: alarm
+Subject: What does "alarm" mean in debugging output?
+
+The debugging output of many versions of UUCP (but not Taylor UUCP)
+will include messages like
+    alarm 1
+or
+    pkcget: alarm 1
+
+This message means that the UUCP package has timed out while waiting
+for some sort of response from the remote system.  This normally
+indicates some sort of connection problem.  For example, the modems
+might have lost their connection, or perhaps one of the modems will
+not transmit the XON and XOFF characters, or perhaps one side or the
+other is dropping characters.  It can also mean that the packages
+disagree about some aspect of the UUCP protocol, although this is less
+common.
+
+Using the information in the rest of this posting, you should be able
+to figure out what type of data your UUCP was expecting to receive.
+This may give some indication as to exactly what the problem is.  It
+is difficult to be more specific, since there are many possiblities.
+
+------------------------------
+
+From: UUCP-grades
+Subject: What are UUCP grades?
+
+Modern UUCP packages support grades for each command.  The grades
+generally range from 'A' (the highest) to 'Z' followed by 'a' to 'z'.
+Some UUCP packages also support '0' to '9' before 'A'.  Some UUCP
+packages may permit any ASCII character as a grade.
+
+On Unix, these grades are encoded in the name of the command file.  A
+command file name generally has the form
+    C.nnnngssss
+where nnnn is the remote system name for which the command is queued,
+g is a single character grade, and ssss is a four character sequence
+number.  For example, a command file created for the system ``airs''
+at grade 'Z' might be named
+    C.airsZ2551
+
+The remote system name will be truncated to seven characters, to
+ensure that the command file name will fit in the 14 character file
+name limit of the traditional Unix file system.  UUCP packages which
+have no other means of distinguishing which command files are intended
+for which systems thus require all systems they connect to to have
+names that are unique in the first seven characters.  Some UUCP
+packages use a variant of this format which truncates the system name
+to six characters.  HDB and Taylor UUCP use a different spool
+directory format, which allows up to fourteen characters to be used
+for each system name.
+
+The sequence number in the command file name may be a decimal integer,
+or it may be a hexadecimal integer, or it may contain any alphanumeric
+character.  Different UUCP packages are different.
+
+FSUUCP (a DOS based UUCP and news package) uses up to 8 characters for
+file names in the spool (this is a DOS file name limitation; actually,
+with the extension, 11 characters are available, but FSUUCP reserves
+that for future use).  FSUUCP defaults mail to grade D, and news to
+grade N, except that when the grade of incoming mail can be
+determined, that grade is preserved if the mail is forwarded to
+another system.  Mail and news are currently the only 2 types of
+transfers supported.  The default grades may be changed by editing
+the MAIL.RC file for mail, or the FSUUCP.CFG file for news.
+
+UUPC/extended for DOS, OS/2 and Windows NT handles mail at grade 'C',
+news at grade 'd', and file transfers at grade 'n'.  The UUPC/extended
+UUCP and RMAIL commands accept grades to override the default, the
+others do not.
+
+I do not know how command grades are handled in other non-Unix UUCP
+packages.
+
+Modern UUCP packages allow you to restrict file transfer by grade
+depending on the time of day.  Typically this is done with a line in
+the Systems (or L.sys) file like this:
+    airs Any/Z,Any2305-0855 ...
+This allows grades 'Z' and above to be transferred at any time.  Lower
+grades may only be transferred at night.  I believe that this grade
+restriction applies to local commands as well as to remote commands,
+but I am not sure.  It may only apply if the UUCP package places the
+call, not if it is called by the remote system.
+
+Taylor UUCP can use the ``timegrade'' and ``call-timegrade'' commands
+to achieve the same effect (and supports the above format when reading
+Systems or L.sys).
+
+UUPC/extended provides the symmetricgrades option to announce the
+current grade in effect when calling the remote system.
+
+This sort of grade restriction is most useful if you know what grades
+are being used at the remote site.  The default grades used depend on
+the UUCP package.  Generally uucp and uux have different defaults.  A
+particular grade can be specified with the -g option to uucp or uux.
+For example, to request execution of rnews on airs with grade 'd', you
+might use something like
+    uux -gd - airs!rnews <article
+
+Uunet queues up mail at grade 'C', but increases the grade based on
+the size.  News is queued at grade 'd', and file transfers at grade
+'n'.  The example above would allow mail (below some large size) to be
+received at any time, but would only permit news to be transferred at
+night.
+
+------------------------------
+
+From: UUCP-lock-file
+Subject: What is the format of a UUCP lock file?
+
+This discussion applies only to Unix.  I have no idea how UUCP locks
+ports on other systems.
+
+UUCP creates files to lock serial ports and systems.  On most if not
+all systems these same lock files are also used by cu to coordinate
+access to serial ports.  On some systems getty also uses these lock
+files, often under the name uugetty.
+
+The lock file normally contains the process ID of the locking process.
+This makes it easy to determine whether a lock is still valid.  The
+algorithm is to create a temporary file and then link it to the name
+that must be locked.  If the link fails because a file with that name
+already exists, the existing file is read to get the process ID.  If
+the process still exists, the lock attempt fails.  Otherwise the lock
+file is deleted and the locking algorithm is retried.
+
+Older UUCP packages put the lock files in the main UUCP spool
+directory, /usr/spool/uucp.  HDB UUCP generally puts the lock files in
+a directory of their own, usually /usr/spool/locks or /etc/locks.
+
+The original UUCP lock file format encodes the process ID as a four
+byte binary number.  The order of the bytes is host-dependent.  HDB
+UUCP stores the process ID as a ten byte ASCII decimal number, with a
+trailing newline.  For example, if process 1570 holds a lock file, it
+would contain the eleven characters space, space, space, space, space,
+space, one, five, seven, zero, newline.  Some versions of UUCP add a
+second line indicating which program created the lock (uucp, cu, or
+getty/uugetty).  I have also seen a third type of UUCP lock file which
+does not contain the process ID at all.
+
+The name of the lock file is traditionally "LCK.." followed by the
+base name of the device.  For example, to lock /dev/ttyd0 the file
+LCK..ttyd0 would be created.  On SCO Unix, the lock file name is
+always forced to lower case even if the device name has upper case
+letters.
+
+System V Release 4 UUCP names the lock file using the major and minor
+device numbers rather than the device name.  The file is named
+LK.XXX.YYY.ZZZ, where XXX, YYY and ZZZ are all three digit decimal
+numbers.  XXX is the major device number of the device holding the
+directory holding the device file (e.g., /dev).  YYY is the major
+device number of the device file itself.  ZZZ is the minor device
+number of the device file itself.  If s holds the result of passing
+the device to the stat system call (e.g., stat ("/dev/ttyd0", &s)),
+the following line of C code will print out the corresponding lock
+file name:
+    printf ("LK.%03d.%03d.%03d", major (s.st_dev),
+            major (s.st_rdev), minor (s.st_rdev));
+The advantage of this system is that even if there are several links
+to the same device, they will all use the same lock file name.
+
+------------------------------
+
+From: X-file
+Subject: What is the format of a UUCP X.* file?
+
+UUCP X.* files control program execution.  They are created by uux.
+They are transferred between computers just like any other file.  The
+uuxqt daemon reads them to figure out how to execute the job requested
+by uux.
+
+An X.* file is simply a text file.  The first character of each line
+is a command, and the remainder of the line supplies arguments.  The
+following commands are defined:
+    C command
+        This gives the command to execute, including the program and
+        all arguments.  For example,
+            C rmail ian@airs.com
+    U user system
+        This names the user who requested the command, and the system
+        from which the request came.
+    I standard-input
+        This names the file from which standard input is taken.  If no
+        standard input file is given, the standard input will probably
+        be attached to /dev/null.  If the standard input file is not
+        from the system on which the execution is to occur, it will
+        also appear in an F command.
+    O standard-output [ system ]
+        This names the standard output file.  The optional second
+        argument names the system to which the file should be sent.
+        If there is no second argument, the file should be created on
+        the executing system.
+    F required-file [ filename-to-use ]
+        The F command can appear multiple times.  Each F command names
+        a file which must exist before the execution can proceed.
+        This will usually be a file which is transferred from the
+        system on which uux was executed, but it can also be a file
+        from the local system or some other system.  If the file is
+        not from the local system, then the command will usually name
+        a file in the spool directory.  If the optional second
+        argument appears, then the file should be copied to the
+        execution directory under that name.  This is necessary for
+        any file other than the standard input file.  If the standard
+        input file is not from the local system, it will appear in
+        both an F command and an I command.
+    R requestor-address
+        This is the address to which mail about the job should be
+        sent.  It is relative to the system named in the U command.
+        If the R command does not appear, then mail is sent to the
+        user named in the U command.
+    Z
+        This command takes no arguments.  It means that a mail message
+        should be sent if the command failed.  This is the default
+        behaviour for most modern UUCP packages, and for them the Z
+        command does not actually do anything.
+    N
+        This command takes no arguments.  It means that no mail
+        message should be sent, even if the command failed.
+    n
+        This command takes no arguments.  It means that a mail message
+        should be sent if the command succeeded.  Normally a message
+        is sent only if the command failed.
+    B
+        This command takes no arguments.  It means that the standard
+        input should be returned with any error message.  This can be
+        useful in cases where the input would otherwise be lost.
+    e
+        This command takes no arguments.  It means that the command
+        should be processed with /bin/sh.  For some packages this is
+        the default anyhow.  Most packages will refuse to execute
+        complex commands or commands containing wildcards, because of
+        the security holes this opens.
+    E
+        This command takes no arguments.  It means that the command
+        should be processed with the execve system call.  For some
+        packages this is the default anyhow.
+    M status-file
+        This command means that instead of mailing a message, the
+        message should be copied to the named file on the system named
+        by the U command.
+    # comment
+        This command is ignored, as is any other unrecognized command.  
+
+Here is an example.  Given the following command executed on system
+test1
+    uux - test2!cat - test2!~ian/bar !qux '>~/gorp'
+(this is only an example, as most UUCP systems will not permit the cat
+command to be executed) Taylor UUCP will produce the following X.
+file:
+    U ian test1
+    F D.test1N003r qux
+    O /usr/spool/uucppublic test1
+    F D.test1N003s
+    I D.test1N003s
+    C cat - ~ian/bar qux
+The standard input will be read into a file and then transferred to
+the file D.test1N003s on system test2, and the file qux will be
+transferred to D.test1N003r on system test2.  When the command is
+executed, the latter file will be copied to the execution directory
+under the name qux.  Note that since the file ~ian/bar is already on
+the execution system, no action need be taken for it.  The standard
+output will be collected in a file, then copied to the directory
+/usr/spool/uucppublic on the system test1.
+
+------------------------------
+
+From: UUCP-protocol
+Subject: What is the UUCP protocol?
+
+The UUCP protocol is a conversation between two UUCP packages.  A UUCP
+conversation consists of three parts: an initial handshake, a series
+of file transfer requests, and a final handshake.
+
+Before the initial handshake, the caller will usually have logged in
+the called machine and somehow started the UUCP package there.  On
+Unix this is normally done by setting the shell of the login name used
+to /usr/lib/uucp/uucico.
+
+All messages in the initial handshake begin with a ^P (a byte with the
+octal value \020) and end with a null byte (\000).  A few systems end
+these messages with a line feed character (\012) instead of a null
+byte; the examples below assume a null byte is being used.
+
+Some options below are supported by QFT, which stands for Queued File
+Transfer, and is (or was) an internal Bell Labs version of UUCP.  
+
+Taylor UUCP size negotiation was introduced by Taylor UUCP, and is
+also supported by DOS based FSUUCP and Amiga based wUUCP and
+UUCP-1.17.
+
+The initial handshake goes as follows.  It is begun by the called
+machine.
+
+called: \020Shere=hostname\000
+    The hostname is the UUCP name of the called machine.  Older UUCP
+    packages do not output it, and simply send \020Shere\000.
+
+caller: \020Shostname options\000
+    The hostname is the UUCP name of the calling machine.  The
+    following options may appear (or there may be none):
+        -QSEQ
+            Report sequence number for this conversation.  The
+            sequence number is stored at both sites, and incremented
+            after each call.  If there is a sequence number mismatch,
+            something has gone wrong (somebody may have broken
+            security by pretending to be one of the machines) and the
+            call is denied.  If the sequence number changes on one of
+            the machines, perhaps because of an attempted breakin or
+            because a disk backup was restored, the sequence numbers
+            on the two machines must be reconciled manually.  This is
+            not supported by FSUUCP.
+        -xLEVEL
+            Requests the called system to set its debugging level to
+            the specified value.  This is not supported by all
+            systems.
+        -pGRADE
+        -vgrade=GRADE
+            Requests the called system to only transfer files of the
+            specified grade or higher.  This is not supported by all
+            systems.  Some systems support -p, some support -vgrade=.
+        -R
+            Indicates that the calling UUCP understands how to restart
+            failed file transmissions.  Supported only by System V
+            Release 4 UUCP and QFT.
+        -ULIMIT
+            Reports the ulimit value of the calling UUCP.  The limit
+            is specified as a base 16 number in C notation (e.g.,
+            -U0x1000000).  This number is the number of 512 byte
+            blocks in the largest file which the calling UUCP can
+            create.  The called UUCP may not transfer a file larger
+            than this.  Supported only by System V Release 4 UUCP, QFT
+            and FSUUCP.  FSUUCP reports the lesser of the
+            available disk space on the spool directory drive and the
+            ulimit variable in FSUUCP.CFG.
+        -N
+            Indicates that the calling UUCP understands the Taylor
+            UUCP size negotiation extension.  Not supported by
+	    traditional UUCP packages.
+
+called: \020ROK\000
+    There are actually several possible responses.
+        ROK
+            The calling UUCP is acceptable, and the handshake proceeds
+            to the protocol negotiation.  Some options may also
+            appear; see below.
+        ROKN
+            The calling UUCP is acceptable, it specified -N, and the
+            called UUCP also understands the Taylor UUCP size limiting
+            extensions.
+        RLCK
+            The called UUCP already has a lock for the calling UUCP,
+            which normally indicates the two machines are already
+            communicating.
+        RCB
+            The called UUCP will call back.  This may be used to avoid
+            impostors (but only one machine out of each pair should
+            call back, or no conversation will ever begin).
+        RBADSEQ
+            The call sequence number is wrong (see the -Q discussion
+            above). 
+        RLOGIN
+            The calling UUCP is using the wrong login name.
+        RYou are unknown to me
+            The calling UUCP is not known to the called UUCP, and the
+            called UUCP does not permit connections from unknown
+            systems.  Some versions of UUCP just drop the line rather
+            than sending this message.
+
+    If the response is ROK, the following options are supported by
+    System V Release 4 UUCP and QFT.
+        -R
+            The called UUCP knows how to restart failed file
+            transmissions.
+        -ULIMIT
+            Reports the ulimit value of the called UUCP.  The limit is
+            specified as a base 16 number in C notation.  This number
+            is the number of 512 byte blocks in the largest file which
+            the called UUCP can create.  The calling UUCP may not send
+            a file larger than this.  Also supported by FSUUCP.
+        -xLEVEL
+            I'm not sure just what this means.  It may request the
+            calling UUCP to set its debugging level to the specified
+            value.
+    If the response is not ROK (or ROKN) both sides hang up the phone,
+    abandoning the call.
+
+called: \020Pprotocols\000
+    Note that the called UUCP outputs two strings in a row.  The
+    protocols string is a list of UUCP protocols supported by the
+    caller.  Each UUCP protocol has a single character name.  These
+    protocols are discussed in more detail later in this document.
+    For example, the called UUCP might send \020Pgf\000.
+
+caller: \020Uprotocol\000
+    The calling UUCP selects which protocol to use out of the
+    protocols offered by the called UUCP.  If there are no mutually
+    supported protocols, the calling UUCP sends \020UN\000 and both
+    sides hang up the phone.  Otherwise the calling UUCP sends
+    something like \020Ug\000.
+
+Most UUCP packages will consider each locally supported protocol in
+turn and select the first one supported by the called UUCP.  With some
+versions of HDB UUCP, this can be modified by giving a list of
+protocols after the device name in the Devices file or the Systems
+file.  For example, to select the 'e' protocol in Systems,
+    airs Any ACU,e ...
+or in Devices,
+    ACU,e ttyXX ...
+Taylor UUCP provides the ``protocol'' command which may be used either
+for a system or a port.
+
+After the protocol has been selected and the initial handshake has been
+completed, both sides turn on the selected protocol.  For some
+protocols (notably 'g') a further handshake is done at this point.
+
+Each protocol supports a method for sending a command to the remote
+system.  This method is used to transmit a series of commands between
+the two UUCP packages.  At all times, one package is the master and
+the other is the slave.  Initially, the calling UUCP is the master.
+
+If a protocol error occurs during the exchange of commands, both sides
+move immediately to the final handshake.
+
+The master will send one of four commands: S, R, X or H.
+
+Any file name referred to below is either an absolute pathname
+beginning with "/", a public directory pathname beginning with "~/", a
+pathname relative to a user's home directory beginning with "~USER/",
+or a spool directory file name.  File names in the spool directory are
+not pathnames, but instead are converted to pathnames within the spool
+directory by UUCP.  They always begin with "C." (for a command file
+created by uucp or uux), "D." (for a data file created by uucp, uux or
+by an execution, or received from another system for an execution), or
+"X." (for an execution file created by uux or received from another
+system).
+
+master: S FROM TO USER -OPTIONS TEMP MODE NOTIFY SIZE
+    The S and the - are literal characters.  This is a request by the
+    master to send a file to the slave.
+        FROM
+            The name of the file to send.  If the C option does not
+            appear in OPTIONS, the master will actually open and send
+            this file.  Otherwise the file has been copied to the
+            spool directory, where it is named TEMP.  The slave
+            ignores this field unless TO is a directory, in which case
+            the basename of FROM will be used as the file name.  If
+            FROM is a spool directory filename, it must be a data file
+            created for or by an execution, and must begin with "D.".
+        TO
+            The name to give the file on the slave.  If this field
+            names a directory the file is placed within that directory
+            with the basename of FROM.  A name ending in `/' is taken
+            to be a directory even if one does not already exist with
+            that name.  If TO begins with `X.', an execution file will
+            be created on the slave.  Otherwise, if TO begins with
+            `D.' it names a data file to be used by some execution
+            file.  Otherwise, TO should not be in the spool directory.
+        USER
+            The name of the user who requested the transfer.
+        OPTIONS
+            A list of options to control the transfer.  The following
+            options are defined (all options are single characters):
+                C
+                    The file has been copied to the spool directory
+                    (the master should use TEMP rather than FROM).
+                c
+                    The file has not been copied to the spool
+                    directory (this is the default).
+                d
+                    The slave should create directories as necessary
+                    (this is the default).
+                f
+                    The slave should not create directories if
+                    necessary, but should fail the transfer instead.
+                m
+                    The master should send mail to USER when the
+                    transfer is complete (not supported by FSUUCP).
+                n
+                    The slave should send mail to NOTIFY when the
+                    transfer is complete (not supported by FSUUCP).
+        TEMP
+            If the C option appears in OPTIONS, this names the file to
+            be sent.  Otherwise if FROM is in the spool directory,
+            TEMP is the same as FROM.  Otherwise TEMP may be a dummy
+            string, such as "D.0".  After the transfer has been
+            succesfully completed, the master will delete the file
+            TEMP.
+        MODE
+            This is an octal number giving the mode of the file on
+            MASTER.  If the file is not in the spool directory, the
+            slave will always create it with mode 0666, except that if
+            (MODE & 0111) is not zero (the file is executable), the
+            slave will create the file with mode 0777.  If the file is
+            in the spool directory, some UUCP packages will use the
+            algorithm above and some will always create the file with
+            mode 0600.  This field is not used by FSUUCP, since it is
+            meaningless on DOS.
+        NOTIFY
+            This field may not be present, and in any case is only
+            meaningful if the n option appears in OPTIONS.  If the n
+            option appears, then when the transfer is successfully
+            completed, the slave will send mail to NOTIFY, which must
+            be a legal mailing address on the slave.  If a SIZE field
+            will appear but the n option does not appear, NOTIFY will
+            always be present, typically as the string "dummy" or
+            simply a pair of double quotes.
+        SIZE
+            This field is only present when doing Taylor UUCP or SVR4
+            UUCP size negotiation, It is the size of the file in
+            bytes.  Taylor UUCP version 1.03 sends the size as a
+            decimal integer, while versions 1.04 and up, and all other
+            UUCP packages that support size negotiation, send the size
+            in base 16 with a leading 0x.
+
+    The slave then responds with an S command response.
+        SY START
+            The slave is willing to accept the file, and file transfer
+            begins.  The START field will only be present when using
+            file restart.  It specifies the byte offset into the file
+            at which to start sending.  If this is a new file, START
+            will be 0x0.
+        SN2
+            The slave denies permission to transfer the file.  This
+            can mean that the destination directory may not be
+            accessed, or that no requests are permitted.  It implies
+            that the file transfer will never succeed.
+        SN4
+            The slave is unable to create the necessary temporary
+            file.  This implies that the file transfer might succeed
+            later.
+        SN6
+            This is only used by Taylor UUCP size negotiation.  It
+            means that the slave considers the file too large to
+            transfer at the moment, but it may be possible to transfer
+            it at some other time.
+        SN7
+            This is only used by Taylor UUCP size negotiation.  It
+            means that the slave considers the file too large to ever
+            transfer.
+        SN8
+            This is only used by Taylor UUCP.  It means that the file
+            was already received in a previous conversation.  This can
+            happen if the receive acknowledgement was lost after it
+            was sent by the receiver but before it was received by the
+            sender.
+	SN9
+	    This is only used by Taylor UUCP (versions 1.05 and up)
+	    and FSUUCP (versions 1.5 and up).  It means that the
+	    remote system was unable to open another channel (see the
+	    discussion of the 'i' protocol for more information about
+	    channels).  This implies that the file transfer might
+	    succeed later.
+        SN10
+            This is reportedly used by SVR4 UUCP to mean that the file
+            size is too large.
+
+    If the slave responds with SY, a file transfer begins.  When the
+    file transfer is complete, the slave sends a C command response.
+        CY
+            The file transfer was successful.
+        CYM
+            The file transfer was successful, and the slave wishes to
+            become the master; the master should send an H command,
+            described below.
+        CN5
+            The temporary file could not be moved into the final
+            location.  This implies that the file transfer will never
+            succeed.
+
+    After the C command response has been received (in the SY case) or
+    immediately (in an SN case) the master will send another command.
+
+master: R FROM TO USER -OPTIONS SIZE
+    The R and the - are literal characters.  This is a request by the
+    master to receive a file from the slave.  I do not know how SVR4
+    UUCP or QFT implement file transfer restart in this case.
+        FROM
+            This is the name of the file on the slave which the master
+            wishes to receive.  It must not be in the spool directory,
+            and it may not contain any wildcards.
+        TO
+            This is the name of the file to create on the master.  I
+            do not believe that it can be a directory.  It may only be
+            in the spool directory if this file is being requested to
+            support an execution either on the master or on some
+            system other than the slave.
+        USER
+            The name of the user who requested the transfer.
+        OPTIONS
+            A list of options to control the transfer.  The following
+            options are defined (all options are single characters):
+                d
+                    The master should create directories as necessary
+                    (this is the default).
+                f
+                    The master should not create directories if
+                    necessary, but should fail the transfer instead.
+                m
+                    The master should send mail to USER when the
+                    transfer is complete.
+        SIZE
+            This only appears if Taylor UUCP size negotiation is being
+            used.  It specifies the largest file which the master is
+            prepared to accept (when using SVR4 UUCP or QFT, this was
+            specified in the -U option during the initial handshake).
+
+    The slave then responds with an R command response.  FSUUCP does
+    not support R requests, and always responds with RN2.
+        RY MODE [ SIZE ]
+            The slave is willing to send the file, and file transfer
+            begins.  MODE is the octal mode of the file on the slave.
+            The master treats this just as the slave does the MODE
+            argument in the send command, q.v.  I am told that SVR4
+            UUCP sends a trailing SIZE argument.  For some versions of
+            BSD UUCP, the MODE argument may have a trailing M
+            character (e.g., RY 0666M).  This means that the slave
+            wishes to become the master.
+        RN2
+            The slave is not willing to send the file, either because
+            it is not permitted or because the file does not exist.
+            This implies that the file request will never succeed.
+        RN6
+            This is only used by Taylor UUCP size negotiation.  It
+            means that the file is too large to send, either because
+            of the size limit specifies by the master or because the
+            slave considers it too large.  The file transfer might
+            succeed later, or it might not (this will be cleared up in
+            a later release of Taylor UUCP).
+	RN9
+	    This is only used by Taylor UUCP (versions 1.05 and up)
+	    and FSUUCP (versions 1.5 and up).  It means that the
+	    remote system was unable to open another channel (see the
+	    discussion of the 'i' protocol for more information about
+	    channels).  This implies that the file transfer might
+	    succeed later.
+
+    If the slave responds with RY, a file transfer begins.  When the
+    file transfer is complete, the master sends a C command.  The
+    slave pretty much ignores this, although it may log it.
+        CY
+            The file transfer was successful.
+        CN5
+            The temporary file could not be moved into the final
+            location.
+
+    After the C command response has been sent (in the RY case) or
+    immediately (in an RN case) the master will send another command.
+
+master: X FROM TO USER -OPTIONS
+    The X and the - are literal characters.  This is a request by the
+    master to, in essence, execute uucp on the slave.  The slave
+    should execute "uucp FROM TO".
+        FROM
+            This is the name of the file or files on the slave which
+            the master wishes to transfer.  Any wildcards are expanded
+            on the slave.  If the master is requesting that the files
+            be transferred to itself, the request would normally
+            contain wildcard characters, since otherwise an `R'
+            command would suffice.  The master can also use this
+            command to request that the slave transfer files to a
+            third system.
+        TO
+            This is the name of the file or directory to which the
+            files should be transferred.  This will normally use a
+            UUCP name.  For example, if the master wishes to receive
+            the files itself, it would use "master!path".
+        USER
+            The name of the user who requested the transfer.
+        OPTIONS
+            A list of options to control the transfer.  It is not
+            clear which, if any, options are supported by most UUCP
+            packages.
+
+    The slave then responds with an X command response.  FSUUCP does
+    not support X requests, and always responds with XN.
+        XY
+            The request was accepted, and the appropriate file
+            transfer commands have been queued up for later
+            processing.
+        XN
+            The request was denied.  No particular reason is given.
+
+    In either case, the master will then send another command.
+
+master: H
+    This is used by the master to hang up the connection.  The slave
+    will respond with an H command response.
+        HY
+            The slave agrees to hang up the connection.  In this case
+            the master sends another HY command.  In some UUCP
+            packages the slave will then send a third HY command.  At
+            this point the protocol is shut down, and the final
+            handshake is begun.
+        HN
+            The slave does not agree to hang up.  In this case the
+            master and the slave exchange roles.  The next command
+            will be sent by the former slave, which is the new master.
+            The roles may be reversed several times during a single
+            connection.
+
+After the protocol has been shut down, the final handshake is
+performed.  This handshake has no real purpose, and some UUCP packages
+simply drop the connection rather than do it (in fact, some will drop
+the connection immediately after both sides agree to hangup, without
+even closing down the protocol).
+
+caller: \020OOOOOO\000
+called: \020OOOOOOO\000
+
+That is, the calling UUCP sends six O's and the called UUCP replies
+with seven O's.  Some UUCP packages always send six O's.
+
+------------------------------
+
+From: UUCP-g
+Subject: What is the 'g' protocol?
+
+The 'g' protocol is a packet based flow controlled error correcting
+protocol that requires an eight bit clear connection.  It is the
+original UUCP protocol, and is supported by all UUCP implementations.
+Many implementations of it are only able to support small window and
+packet sizes, specifically a window size of 3 and a packet size of 64
+bytes, but the protocol itself can support up to a window size of 7
+and a packet size of 4096 bytes.  Complaints about the inefficiency of
+the 'g' protocol generally refer to specific implementations, rather
+than to the correctly implemented protocol.
+
+The 'g' protocol was originally designed for general packet drivers,
+and thus contains some features that are not used by UUCP, including
+an alternate data channel and the ability to renegotiate packet and
+window sizes during the communication session.
+
+The 'g' protocol is spoofed by many Telebit modems.  When spoofing is
+in effect, each Telebit modem uses the 'g' protocol to communicate
+with the attached computer, but the data between the modems is sent
+using a Telebit proprietary error correcting protocol.  This allows
+for very high throughput over the Telebit connection, which, because
+it is half-duplex, would not normally be able to handle the 'g'
+protocol very well at all.  When a Telebit is spoofing the 'g'
+protocol, it forces the packet size to be 64 bytes and the window size
+to be 3.
+
+This discussion of the 'g' protocol explains how it works, but does
+not discuss useful error handling techniques.  Some discussion of this
+can be found in Jamie E. Hanrahan's paper, cited above.
+
+All 'g' protocol communication is done with packets.  Each packet
+begins with a six byte header.  Control packets consist only of the
+header.  Data packets contain additional data.
+
+The header is as follows:
+
+    \020
+        Every packet begins with a ^P.
+    k (1 <= k <= 9)
+        The k value is always 9 for a control packet.  For a data
+        packet, the k value indicates how much data follows the six
+        byte header.  The amount of data is 2 ** (k + 4), where **
+        indicates exponentiation.  Thus a k value of 1 means 32 data
+        bytes and a k value of 8 means 4096 data bytes.  The k value
+        for a data packet must be between 1 and 8 inclusive.
+    checksum low byte
+    checksum high byte
+        The checksum value is described below.
+    control byte
+        The control byte indicates the type of packet, and is
+        described below.
+    xor byte
+        This byte is the xor of k, the checksum low byte, the checksum
+        high byte and the control byte (i.e., the second, third,
+        fourth and fifth header bytes).  It is used to ensure that the
+        header data is valid.
+
+The control byte in the header is composed of three bit fields,
+referred to here as TT (two bits), XXX (three bits) and YYY (three
+bits).  The control is TTXXXYYY, or (TT << 6) + (XXX << 3) + YYY.
+
+The TT field takes on the following values:
+    0
+        This is a control packet.  In this case the k byte in the
+        header must be 9.  The XXX field indicates the type of control
+        packet; these types are described below.
+    1
+        This is an alternate data channel packet.  This is not used by
+        UUCP.
+    2
+        This is a data packet, and the entire contents of the attached
+        data field (whose length is given by the k byte in the header)
+        are valid.  The XXX and YYY fields are described below.
+    3
+        This is a short data packet.  Let the length of the data field
+        (as given by the k byte in the header) be L.  Let the first
+        byte in the data field be B1.  If B1 is less than 128 (if the
+        most significant bit of B1 is 0), then there are L - B1 valid
+        bytes of data in the data field, beginning with the second
+        byte.  If B1 >= 128, let B2 be the second byte in the data
+        field.  Then there are L - ((B1 & 0x7f) + (B2 << 7)) valid
+        bytes of data in the data field, beginning with the third
+        byte.  In all cases L bytes of data are sent (and all data
+        bytes participate in the checksum calculation) but some of the
+        trailing bytes may be dropped by the receiver.   The XXX and
+        YYY fields are described below.
+
+In a data packet (short or not) the XXX field gives the sequence
+number of the packet.  Thus sequence numbers can range from 0 to 7,
+inclusive.  The YYY field gives the sequence number of the last
+correctly received packet.
+
+Each communication direction uses a window which indicates how many
+unacknowledged packets may be transmitted before waiting for an
+acknowledgement.  The window may range from 1 to 7, and may be
+different in each direction. For example, if the window is 3 and the
+last packet acknowledged was packet number 6, packet numbers 7, 0 and
+1 may be sent but the sender must wait for an acknowledgement before
+sending packet number 2.  This acknowledgement could come as the YYY
+field of a data packet or as the YYY field of a RJ or RR control
+packet (described below).
+
+Each packet must be transmitted in order (the sender may not skip
+sequence numbers).  Each packet must be acknowledged, and each packet
+must be acknowledged in order.
+
+In a control packet, the XXX field takes on the following values:
+    1 CLOSE
+        The connection should be closed immediately.  This is
+        typically sent when one side has seen too many errors and
+        wants to give up.  It is also sent when shutting down the
+        protocol.  If an unexpected CLOSE packet is received, a CLOSE
+        packet should be sent in reply and the 'g' protocol should
+        halt, causing UUCP to enter the final handshake.
+    2 RJ or NAK
+        The last packet was not received correctly.  The YYY field
+        contains the sequence number of the last correctly received
+        packet.
+    3 SRJ
+        Selective reject.  The YYY field contains the sequence number
+        of a packet that was not received correctly, and should be
+        retransmitted.  This is not used by UUCP, and most
+        implementations will not recognize it.
+    4 RR or ACK
+        Packet acknowledgement.  The YYY field contains the sequence
+        number of the last correctly received packet.
+    5 INITC
+        Third initialization packet.  The YYY field contains the
+        maximum window size to use.
+    6 INITB
+        Second initialization packet.  The YYY field contains the
+        packet size to use.  It requests a size of 2 ** (YYY + 5).
+        Note that this is not the same coding used for the k byte in
+        the packet header (it is 1 less).  Most UUCP implementations
+        that request a packet size larger than 64 bytes can handle any
+        packet size up to that specified.
+    7 INITA
+        First initialization packet.  The YYY field contains the
+        maximum window size to use.
+
+The checksum of a control packet is simply 0xaaaa - the control byte.
+
+The checksum of a data packet is 0xaaaa - (CHECK ^ the control byte),
+where ^ denotes exclusive or, and CHECK is the result of the following
+routine as run on the contents of the data field (every byte in the
+data field participates in the checksum, even for a short data
+packet).  Below is the routine used by Taylor UUCP; it is a slightly
+modified version of a routine which John Gilmore patched from G.L.
+Chesson's original paper.  The z argument points to the data and the c
+argument indicates how much data there is.
+
+int
+igchecksum (z, c)
+     register const char *z;
+     register int c;
+{
+  register unsigned int ichk1, ichk2;
+
+  ichk1 = 0xffff;
+  ichk2 = 0;
+
+  do
+    {
+      register unsigned int b;
+
+      /* Rotate ichk1 left.  */
+      if ((ichk1 & 0x8000) == 0)
+        ichk1 <<= 1;
+      else
+        {
+          ichk1 <<= 1;
+          ++ichk1;
+        }
+
+      /* Add the next character to ichk1.  */
+      b = *z++ & 0xff;
+      ichk1 += b;
+
+      /* Add ichk1 xor the character position in the buffer counting from
+         the back to ichk2.  */
+      ichk2 += ichk1 ^ c;
+
+      /* If the character was zero, or adding it to ichk1 caused an
+         overflow, xor ichk2 to ichk1.  */
+      if (b == 0 || (ichk1 & 0xffff) < b)
+        ichk1 ^= ichk2;
+    }
+  while (--c > 0);
+
+  return ichk1 & 0xffff;
+}
+
+When the 'g' protocol is started, the calling UUCP sends an INITA
+control packet with the window size it wishes the called UUCP to use.
+The called UUCP responds with an INITA packet with the window size it
+wishes the calling UUCP to use.  Pairs of INITB and INITC packets are
+then similarly exchanged.  When these exchanges are completed, the
+protocol is considered to have been started.
+
+Note that the window and packet sizes are not a negotiation.  Each
+system announces the window and packet size which the other system
+should use.  It is possible that different window and packet sizes
+will be used in each direction.  The protocol works this way on the
+theory that each system knows how much data it can accept without
+getting overrun.  Therefore, each system tells the other how much data
+to send before waiting for an acknowledgement.
+
+When a UUCP package transmits a command, it sends one or more data
+packets.  All the data packets will normally be complete, although
+some UUCP packages may send the last one as a short packet.  The
+command string is sent with a trailing null byte, to let the receiving
+package know when the command is finished.  Some UUCP packages require
+the last byte of the last packet sent to be null, even if the command
+ends earlier in the packet.  Some packages may require all the
+trailing bytes in the last packet to be null, but I have not confirmed
+this.
+
+When a UUCP package sends a file, it will send a sequence of data
+packets.  The end of the file is signalled by a short data packet
+containing zero valid bytes (it will normally be preceeded by a short
+data packet containing the last few bytes in the file).
+
+Note that the sequence numbers cover the entire communication session,
+including both command and file data.
+
+When the protocol is shut down, each UUCP package sends a CLOSE
+control packet.
+
+------------------------------
+
+From: UUCP-f
+Subject: What is the 'f' protocol?
+
+The 'f' protocol is a seven bit protocol which checksums an entire
+file at a time.  It only uses the characters between \040 and \176
+(ASCII space and ~) inclusive as well as the carriage return
+character.  It can be very efficient for transferring text only data,
+but it is very inefficient at transferring eight bit data (such as
+compressed news).  It is not flow controlled, and the checksum is
+fairly insecure over large files, so using it over a serial connection
+requires handshaking (XON/XOFF can be used) and error correcting
+modems.  Some people think it should not be used even under those
+circumstances.
+
+I believe the 'f' protocol originated in BSD versions of UUCP.  It was
+originally intended for transmission over X.25 PAD links.
+
+The 'f' protocol has no startup or finish protocol.  However, both
+sides typically sleep for a couple of seconds before starting up,
+because they switch the terminal into XON/XOFF mode and want to allow
+the changes to settle before beginning transmission.
+
+When a UUCP package transmits a command, it simply sends a string
+terminated by a carriage return.
+
+When a UUCP package transmits a file, each byte b of the file is
+translated according to the following table:
+
+       0 <= b <=  037: 0172, b + 0100 (0100 to 0137)
+     040 <= b <= 0171:       b        ( 040 to 0171)
+    0172 <= b <= 0177: 0173, b - 0100 ( 072 to  077)
+    0200 <= b <= 0237: 0174, b - 0100 (0100 to 0137)
+    0240 <= b <= 0371: 0175, b - 0200 ( 040 to 0171)
+    0372 <= b <= 0377: 0176, b - 0300 ( 072 to  077)
+
+That is, a byte between \040 and \171 inclusive is transmitted as is,
+and all other bytes are prefixed and modified as shown.
+
+When all the file data is sent, a seven byte sequence is sent: two
+bytes of \176 followed by four ASCII bytes of the checksum as printed
+in base 16 followed by a carriage return.  For example, if the
+checksum was 0x1234, this would be sent: "\176\1761234\r".
+
+The checksum is initialized to 0xffff.  For each byte that is sent 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;
+
+When the receiving UUCP sees the checksum, it compares it against its
+own calculated checksum and replies with a single character followed
+by a carriage return.
+    G
+        The file was received correctly.
+    R
+        The checksum did not match, and the file should be resent from
+        the beginning.
+    Q
+        The checksum did not match, but too many retries have occurred
+        and the communication session should be abandoned.
+
+The sending UUCP checks the returned character and acts accordingly.
+
+------------------------------
+
+From: UUCP-t
+Subject: What is the 't' protocol?
+
+The 't' protocol is intended for use on links which provide reliable
+end-to-end connections, such as TCP.  It does no error checking or
+flow control, and requires an eight bit clear channel.
+
+I believe the 't' protocol originated in BSD versions of UUCP.
+
+When a UUCP package transmits a command, it first gets the length of
+the command string, C.  It then sends ((C / 512) + 1) * 512 bytes (the
+smallest multiple of 512 which can hold C bytes plus a null byte)
+consisting of the command string itself followed by trailing null
+bytes.
+
+When a UUCP package sends a file, it sends it in blocks.  Each block
+contains at most 1024 bytes of data.  Each block consists of four
+bytes containing the amount of data in binary (most significant byte
+first, the same format as used by the Unix function htonl) followed by
+that amount of data.  The end of the file is signalled by a block
+containing zero bytes of data.
+
+------------------------------
+
+From: UUCP-e
+Subject: What is the 'e' protocol?
+
+The 'e' protocol is similar to the 't' protocol.  It does no flow
+control or error checking and is intended for use over networks
+providing reliable end-to-end connections, such as TCP.
+
+The 'e' protocol originated in versions of HDB UUCP.
+
+When a UUCP package transmits a command, it simply sends the command
+as an ASCII string terminated by a null byte.
+
+When a UUCP package transmits a file, it sends the complete size of
+the file as an ASCII decimal number.  The ASCII string is padded out
+to 20 bytes with null bytes (i.e. if the file is 1000 bytes long, it
+sends "1000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0").  It then sends the
+entire file.
+
+------------------------------
+
+From: UUCP-G
+Subject: What is the 'G' protocol?
+
+The 'G' protocol is used by SVR4 UUCP.  It is identical to the 'g'
+protocol, except that it is possible to modify the window and packet
+sizes.  The SVR4 implementation of the 'g' protocol reportedly is
+fixed at a packet size of 64 and a window size of 7.  Supposedly SVR4
+chose to implement a new protocol using a new letter to avoid any
+potential incompatibilities when using different packet or window
+sizes.
+
+Most implementations of the 'g' protocol that accept packets larger
+than 64 bytes will also accept packets smaller than whatever they
+requested in the INITB packet.  The SVR4 'G' implementation is an
+exception; it will only accept packets of precisely the size it
+requests in the INITB packet.
+
+------------------------------
+
+From: UUCP-i
+Subject: What is the 'i' protocol?
+
+The 'i' protocol was written by Ian Lance Taylor (who also wrote this
+FAQ).  It is used by Taylor UUCP version 1.04.
+
+It is a sliding window packet protocol, like the 'g' protocol, but it
+supports bidirectional transfers (i.e., file transfers in both
+directions simultaneously).  It requires an eight bit clear
+connection.  Several ideas for the protocol were taken from the paper
+``A High-Throughput Message Transport System'' by P. Lauder.  I don't
+know where the paper was published, but the author's e-mail address is
+piers@cs.su.oz.au.  The 'i' protocol does not adopt his main idea,
+which is to dispense with windows entirely.  This is because some
+links still do require flow control and, more importantly, because
+using windows sets a limit to the amount of data which the protocol
+must be able to resend upon request.  To reduce the costs of window
+acknowledgements, the protocol uses a large window and only requires
+an ack at the halfway point.
+
+Each packet starts with a six byte header, optionally followed by data
+bytes with a four byte checksum.  There are currently five defined
+packet types (DATA, SYNC, ACK, NAK, SPOS, CLOSE) which are described
+below.  Although any packet type may include data, any data provided
+with an ACK, NAK or CLOSE packet is ignored.
+
+Every DATA, SPOS and CLOSE packet has a sequence number.  The sequence
+numbers are independent for each side.  The first packet sent by each
+side is always number 1.  Each packet is numbered one greater than the
+previous packet, modulo 32.
+
+Every packet has a local channel number and a remote channel number.
+For all packets at least one channel number is zero.  When a UUCP
+command is sent to the remote system, it is assigned a non-zero local
+channel number.  All packets associated with that UUCP command sent by
+the local system are given the selected local channel number.  All
+associated packets sent by the remote system are given the selected
+number as the remote channel number.  This permits each UUCP command
+to be uniquely identified by the channel number on the originating
+system, and therefore each UUCP package can associate all file data
+and UUCP command responses with the appropriate command.  This is a
+requirement for bidirectional UUCP transfers.
+
+The protocol maintains a single global file position, which starts at
+0.  For each incoming packet, any associated data is considered to
+occur at the current file position, and the file position is
+incremented by the amount of data contained.  The exception is a
+packet of type SPOS, which is used to change the file position.
+The reason for keeping track of the file position is described below.
+
+The header is as follows:
+
+    \007
+	Every packet begins with ^G.
+    (PACKET << 3) + LOCCHAN
+	The five bit packet number combined with the three bit local
+	channel number.  DATA, SPOS and CLOSE packets use the packet
+	sequence number for the PACKET field.  NAK packet types use
+	the PACKET field for the sequence number to be resent.  ACK
+	and SYNC do not use the PACKET field, and generally leave it
+	set to 0.  Packets which are not associated with a UUCP
+	command from the local system use a local channel number of 0.
+    (ACK << 3) + REMCHAN
+	The five bit packet acknowledgement combined with the three
+	bit remote channel number.  The packet acknowledgement is the
+	number of the last packet successfully received; it is used by
+	all packet types.  Packets which are not sent in response to a
+	UUCP command from the remote system use a remote channel
+	number of 0.
+    (TYPE << 5) + (CALLER << 4) + LEN1
+	The three bit packet type combined with the one bit packet
+	direction combined with the upper four bits of the data
+	length.  The packet direction bit is always 1 for packets sent
+	by the calling UUCP, and 0 for packets sent by the called
+	UUCP.  This prevents confusion caused by echoed packets.
+    LEN2
+	The lower eight bits of the data length.  The twelve bits of
+	data length permit packets ranging in size from 0 to 4095
+	bytes.
+    CHECK
+	The exclusive or of the second through fifth bytes of the
+	header.  This provides an additional check that the header is
+	valid.
+
+If the data length is non-zero, the packet is immediately followed by
+the specified number of data bytes.  The data bytes are followed by a
+four byte CRC 32 checksum, with the most significant byte first.  The
+CRC is calculated over the contents of the data field.
+
+The defined packet types are as follows:
+
+    0 (DATA)
+	This is a plain data packet.
+    1 (SYNC)
+	SYNC packets are exchanged when the protocol is initialized,
+	and are described further below.  SYNC packets do not carry
+	sequence numbers (that is, the PACKET field is ignored).
+    2 (ACK)
+	This is an acknowledgement packet.  Since DATA packets also
+	carry packet acknowledgements, ACK packets are only used when
+	one side has no data to send.  ACK packets do not carry
+	sequence numbers.
+    3 (NAK)
+	This is a negative acknowledgement.  This is sent when a
+	packet is received incorrectly, and means that the packet
+	number appearing in the PACKET field must be resent.  NAK
+	packets do not carry sequence numbers (the PACKET field is
+	already used).
+    4 (SPOS)
+	This packet changes the file position.  The packet contains
+	four bytes of data holding the file position, most significant
+	byte first.  The next packet received will be considered to be
+	at the named file position.
+    5 (CLOSE)
+	When the protocol is shut down, each side sends a CLOSE
+	packet.	 This packet does have a sequence number, which could
+	be used to ensure that all packets were correctly received
+	(this is not needed by UUCP, however, which uses the higher
+	level H command with an HY response).
+
+When the protocol starts up, both systems send a SYNC packet.  The
+SYNC packet includes at least three bytes of data.  The first two
+bytes are the maximum packet size the remote system should send, most
+significant byte first.  The third byte is the window size the remote
+system should use.  The remote system may send packets of any size up
+to the maximum.  If there is a fourth byte, it is the number of
+channels the remote system may use (this must be between 1 and 7,
+inclusive).  Additional data bytes may be defined in the future.
+
+The window size is the number of packets that may be sent before a
+packet is acknowledged.  There is no requirement that every packet be
+acknowledged; any acknowledgement is considered to acknowledge all
+packets through the number given.  In the current implementation, if
+one side has no data to send, it sends an ACK when half the window is
+received.
+
+Note that the NAK packet corresponds to the unused 'g' protocol SRJ
+packet type, rather than to the RJ packet type.  When a NAK is
+received, only the named packet should be resent, not any subsequent
+packets.
+
+Note that if both sides have data to send, but a packet is lost, it is
+perfectly reasonable for one side to continue sending packets, all of
+which will acknowledge the last packet correctly received, while the
+system whose packet was lost will be unable to send a new packet
+because the send window will be full.  In this circumstance, neither
+side will time out and one side of the communication will be
+effectively shut down for a while.  Therefore, any system with
+outstanding unacknowledged packets should arrange to time out and
+resend a packet even if data is being received.
+
+Commands are sent as a sequence of data packets with a non-zero local
+channel number.  The last data packet for a command includes a
+trailing null byte (normally a command will fit in a single data
+packet).  Files are sent as a sequence of data packets ending with one
+of length zero.
+
+The channel numbers permit a more efficient implementation of the UUCP
+file send command.  Rather than send the command and then wait for the
+SY response before sending the file, the file data is sent beginning
+immediately after the S command is sent.  If an SN response is
+received, the file send is aborted, and a final data packet of length
+zero is sent to indicate that the channel number may be reused.  If an
+SY reponse with a file position indicator is received, the file send
+adjusts to the file position; this is why the protocol maintains a
+global file position.
+
+Note that the use of channel numbers means that each UUCP system may
+send commands and file data simultaneously.  Moreover, each UUCP
+system may send multiple files at the same time, using the channel
+number to disambiguate the data.  Sending a file before receiving an
+acknowledgement for the previous file helps to eliminate the round
+trip delays inherent in other UUCP protocols.
+
+------------------------------
+
+From: UUCP-j
+Subject: What is the 'j' protocol?
+
+The 'j' protocol is a variant of the 'i' protocol.  It was also
+written by Ian Lance Taylor, and first appeared in Taylor UUCP version
+1.04.
+
+The 'j' protocol is a version of the 'i' protocol designed for
+communication links which intercept a few characters, such as XON or
+XOFF.  It is not efficient to use it on a link which intercepts many
+characters, such as a seven bit link.  The 'j' protocol performs no
+error correction or detection; that is presumed to be the
+responsibility of the 'i' protocol.
+
+When the 'j' protocol starts up, each system sends a printable ASCII
+string indicating which characters it wants to avoid using.  The
+string begins with the ASCII character '^' (octal 136) and ends with
+the ASCII character '~' (octal 176).  After sending this string, each
+system looks for the corresponding string from the remote system.  The
+strings are composed of escape sequences: \ooo, where o is an octal
+digit.  For example, sending the string ^\021\023~ means that the
+ASCII XON and XOFF characters should be avoided.  The union of the
+characters described in both strings (the string which is sent and the
+string which is received) is the set of characters which must be
+avoided in this conversation.  Avoiding a printable ASCII character
+(octal 040 to octal 176, inclusive) is not permitted.
+
+After the exchange of characters to avoid, the normal 'i' protocol
+start up is done, and the rest of the conversation uses the normal 'i'
+protocol.  However, each 'i' protocol packet is wrapped to become a
+'j' protocol packet.
+
+Each 'j' protocol packet consists of a seven byte header, followed by
+data bytes, followed by index bytes, followed by a one byte trailer.
+The packet header looks like this:
+
+    ^
+        Every packet begins with the ASCII character '^', octal 136.
+    HIGH
+    LOW
+        These two characters give the total number of bytes in the
+        packet.  Both HIGH and LOW are printable ASCII characters.
+        The length of the packet is (HIGH - 040) * 0100 + (LOW - 040),
+        where 040 <= HIGH < 0177 and 040 <= LOW < 0140.  This permits
+        a length of 6079 bytes, but there is a further restriction on
+        packet size described below.
+    =
+        The ASCII character '=', octal 075.
+    DATA-HIGH
+    DATA-LOW
+	These two characters give the total number of data bytes in
+        the packet.  The encoding is as described for HIGH and LOW.
+        The number of data bytes is the size of the 'i' protocol
+        packet wrapped inside this 'j' protocol packet.
+    @
+	The ASCII character '@', octal 100.
+
+The header is followed by the number of data bytes given in DATA-HIGH
+and DATA-LOW.  These data bytes are the 'i' protocol packet which is
+being wrapped in the 'j' protocol packet.  However, each character in
+the 'i' protocol packet which the 'j' protocol must avoid is
+transformed into a printable ASCII character (recall that avoiding a
+printable ASCII character is not permitted).  Two index bytes are used
+for each character which must be transformed.
+
+The index bytes immediately follow the data bytes.  The index bytes
+are created in pairs.  Each pair of index bytes encodes the location
+of a character in the 'i' protocol packet which was transformed to
+become a printable ASCII character.  Each pair of index bytes also
+encodes the precise transformation which was performed.
+
+When the sender finds a character which must be avoided, it will
+transform it using one or two operations.  If the character is 0200 or
+greater, it will subtract 0200.  If the resulting character is less
+than 020, or is equal to 0177, it will xor by 020.  The result is
+a printable ASCII character.
+
+The zero based byte index of the character within the 'i' protocol
+packet is determined.  This index is turned into a two byte printable
+ASCII index, INDEX-HIGH and INDEX-LOW, such that the index is
+(INDEX-HIGH - 040) * 040 + (INDEX-LOW - 040).  INDEX-LOW is restricted
+such that 040 <= INDEX-LOW < 0100.  INDEX-HIGH is not permitted to be
+0176, so 040 <= INDEX-HIGH < 0176.  INDEX-LOW is then modified to
+encode the transformation:
+
+    If the character transformation only had to subtract 0200, then
+    INDEX-LOW is used as is.
+
+    If the character transformation only had to xor by 020, then 040
+    is added to INDEX-LOW.
+
+    If both operations had to be performed, then 0100 is added to
+    INDEX-LOW.  However, if the value of INDEX-LOW were initially 077,
+    then adding 0100 would result in 0177, which is not a printable
+    ASCII character.  For that special case, INDEX-HIGH is set to
+    0176, and INDEX-LOW is set to the original value of INDEX-HIGH.
+
+The receiver decodes the index bytes as follows (this is the reverse
+of the operations performed by the sender, presented here for
+additional clarity):
+
+    The first byte in the index is INDEX-HIGH, and the second is
+    INDEX-LOW.
+
+    If 040 <= INDEX-HIGH < 0176, the index refers to the data byte at
+    position (INDEX-HIGH - 040) * 040 + INDEX-LOW % 040.
+
+        If 040 <= INDEX-LOW < 0100, then 0200 must be added to indexed
+        byte.
+
+        If 0100 <= INDEX-LOW < 0140, then 020 must be xor'ed to the
+        indexed byte.
+
+        If 0140 <= INDEX-LOW < 0177, then 0200 must be added to the
+        indexed byte, and 020 must be xor'ed to the indexed byte.
+
+    If INDEX-HIGH == 0176, the index refers to the data byte at
+    position (INDEX-LOW - 040) * 040 + 037.  0200 must be added to the
+    indexed byte, and 020 must be xor'ed to the indexed byte.
+
+This means the largest 'i' protocol packet which may be wrapped inside
+a 'j' protocol packet is (0175 - 040) * 040 + (077 - 040) == 3007
+bytes.
+
+The final character in a 'j' protocol packet, following the index
+bytes, is the ASCII character '~' (octal 176).
+
+The motivation behind using an indexing scheme, rather than escape
+characters, is to avoid data movement.  The sender may simply add a
+header and a trailer to the 'i' protocol packet.  Once the receiver
+has loaded the 'j' protocol packet, it may scan the index bytes,
+transforming the data bytes, and then pass the data bytes directly on
+to the 'i' protocol routine.
+
+------------------------------
+
+From: UUCP-x
+Subject: What is the 'x' protocol?
+
+The 'x' protocol is used in Europe (and probably elsewhere) with
+machines that contain an builtin X.25 card and can send eight bit data
+transparently across X.25 circuits, without interference from the X.28
+or X.29 layers.  The protocol sends packets of 512 bytes, and relies
+on a write of zero bytes being read as zero bytes without stopping
+communication.  It first appeared in the original System V UUCP
+implementation.
+
+------------------------------
+
+From: UUCP-y
+Subject: What is the '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 is a streaming protocol,
+like the 'f' protocol.  It requires an eight bit clean connection.  It
+performs error detection, but not error correction; when an error is
+detected, the line is dropped.  I do not know the implementation
+details.
+
+------------------------------
+
+From: UUCP-d
+Subject: What is the 'd' protocol?
+
+This 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.
+
+------------------------------
+
+From: UUCP-h
+Subject: What is the 'h' protocol?
+
+This 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.
+
+------------------------------
+
+From: UUCP-v
+Subject: What is the '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.
+
+------------------------------
+
+From: Thanks
+Subject: Thanks
+
+Besides the papers and information acknowledged at the top of this
+article, the following people have contributed help, advice,
+suggestions and information:
+    Earle Ake 513-429-6500 <ake@Dayton.SAIC.COM>
+    cambler@nike.calpoly.edu (Christopher J. Ambler)
+    jhc@iscp.bellcore.com (Jonathan Clark)
+    jorge@laser.satlink.net (Jorge Cwik)
+    celit!billd@UCSD.EDU (Bill Davidson)
+    "Drew Derbyshire" <ahd@kew.com>
+    erik@pdnfido.fidonet.org
+    Matthew Farwell <dylan@ibmpcug.co.uk>
+    dgilbert@gamiga.guelphnet.dweomer.org (David Gilbert)
+    kherron@ms.uky.edu (Kenneth Herron)
+    Mike Ipatow <mip@fido.itc.e-burg.su>
+    Romain Kang <romain@pyramid.com>
+    "Jonathan I. Kamens" <jik@GZA.COM>
+    "David J. MacKenzie" <djm@eng.umd.edu>
+    jum@helios.de (Jens-Uwe Mager)
+    peter@xpoint.ruessel.sub.org (Peter Mandrella)
+    david nugent <david@csource.oz.au>
+    Stephen.Page@prg.oxford.ac.uk
+    joey@tessi.UUCP (Joey Pruett)
+    James Revell <revell@uunet.uu.net>
+    Larry Rosenman <ler@lerami.lerctr.org>
+    Rich Salz <rsalz@bbn.com>
+    evesg@etlrips.etl.go.jp (Gjoen Stein)
+    kls@ditka.Chicago.COM (Karl Swartz)
+    Dima Volodin <dvv@hq.demos.su>
+    jon@console.ais.org (Jon Zeeff)
+    Eric Ziegast <ziegast@uunet.uu.net>
+
+------------------------------
+
+End of UUCP Internals Frequently Asked Questions
+******************************
+-- 
+Ian Taylor | ian@airs.com | First to identify quote wins free e-mail message:
+``You don't have to sleep.  That's just something *they* tell you to keep
+  *control* over you.  Nobody has to sleep; you're *taught* to sleep when
+  you're a kid.  If you're really determined, you can get over it.''