Document: FTS-0006
Version:  002
Date:     30-Nov-1991




                            YOOHOO and YOOHOO/2U2

                    The netmail handshake used by Opus-CBCS
             and other intelligent Fidonet mail handling packages


                              Vince Perriello
                             FidoNet 1:2343/491




Status of this document:

     This FTS (FidoNet(r) Technical Standard) specifies an optional
     standard for the FidoNet community.  Implementation of the
     protocols defined in this document is not mandatory,  but all
     implementations of these protocols are expected to adhere to this
     standard.  Distribution of this document is subject to the 
     restrictions listed below.

     Fido and FidoNet are registered marks of Tom Jennings and Fido
     Software




LEGAL STUFF
-----------

The original  protocol and documentation are by Wynn Wagner III.  Updates
have  been  made  to  this  document  by  Vince Perriello,  who  also  is
responsible for most of the sample routine included with this document.

They are  released to the  public for  any use  whatsoever as long as you 
don't  modify any  transmitted  structure  or try to  make money  hawking
either the sample code or this document as if you owned them.

If you choose to use the  method  or  the  sample  routines,  you  do  so
entirely at your own risk.  It  is  possible that the routines will cause
physical damage to your equipment, an invasion of  fire ants, the plague,
or an extended visit from in-laws.  If any  of  that  stuff  (or anything
else) happens, you accept the consequences totally.


CREDITS
-------

Fido  and  Fidonet  are  registered  trademarks of Tom Jennings and  Fido
Software.

ARCmail was originated by System Enhancement Associates.

The ZModem protocol was designed by Chuck Forsberg. The SEAlink / SEAlink
Overdrive protocols are copyrighted by System Enhancment Associates.  The
TeLink protocol was designed and first implemented by Tom Jennings.

The state charts in this document were done by Vince Perriello.

Rick Huebner designed  and  implemented  the  basic  WaZOO  file  request
method.  Update  request functionality was added by Vince Perriello.  Bob
Hartman is responsible for the addition of Domain support.

FTS-0001, describing the base FidoNet protocol, was created by Randy Bush.

FTS-0007, describing enhancement to FTS-0001 using SEAlink and/or SEAlink
Overdrive, was created by Phil Becker.

YooHoo and YooHoo/2u2                                              Page 2
Overview



UPFRONT
-------

YOOHOO and YOOHOO/2U2 are  the  initial  handshakes  for the WaZOO e-mail
protocol.  They are designed to let two systems establish a common ground
for a netmail session while making  sure  that non-WaZOO software doesn't
get upset by material it can't understand.

The YOOHOO procedure begins as a single  byte  (0xf1).   If the system on
the other end doesn't reply to that byte,  no  further  YOOHOO  or  WaZOO
transmissions are attempted.  To a non-WaZOO netmail system,  the  YOOHOO
byte will simply seem like a byte of debris.

The  calling  system  initiates  the  YOOHOO  by  sending  the  attention
character.   If the receiving system seems interested, the calling system
sends a  128  byte packet containing such information as system and sysop
names as well as a "capability mask." A 16-bit CRC protects the integrity
of the 128-byte packet.

In response, the receiving  system  prepares  a  128  byte packet to send
back.  This is the YOOHOO/2U2 procedure.


FEATURES
--------

The features of YOOHOO and YOOHOO/2U2 include

      * non-interference with systems that don't understand the
        handshake

      * almost foolproof method for identifying a remote system
        and establishing a common ground for transmission

      * built-in room to expand the capabilities of WaZOO without
        having to resort to a kludge


USAGE
-----

A calling system simply uses  a  routine  that  transmits both YooHoo and
TSYNC  handshake initiating characters to the  called  system.    If  the
called system responds with an XMODEM 'NAK',  an FTS-0001 session will be
initiated.  If an 'ENQ' is received, the  `YooHoo_Sender()'  routine will
be invoked to handle the session negotiation.

A  receiving  system  can call a routine like `YooHoo_Receiver()'  if  it
detects the YOOHOO character, or just drop into the FTS-0001  logic if it
sees a TSYNC.

This simple method allows a mailer to take care of both the TSYNC and the
YOOHOO handshakes.

YooHoo and YooHoo/2u2                                              Page 3
WaZOO Protocols



PROTOCOLS
---------

Currently there are four WaZOO methods in use:

1. ZedZap 
   ------

        a Zmodem variant. The originator does a batch send then goes into a
        receive batch mode.  The called system does receive then send. In 
        the event of a file request (see description below) made by the 
        called system, one more turnaround is made to service the request.

      * Unlike the "True" Zmodem protocol described by Chuck Forsberg, 
        ZedZap routines must be able to handle a batch mode that has no 
        actual files. In other words, it is possible for there to be a 
        init sequence followed immediately by a ZFIN.

      * The maximum packet size is 8192. This is usually varied based on 
        the baud rate. For example, at 2400 it might be 2048 bytes, then 
        for 9600 baud and above the maximum of 8192 could apply. Note that
        THIS IS A SIGNIFICANT VARIATION FROM STRICT ZMODEM IMPLEMENTATION.
        (There's another WaZOO capability bit for those systems which 
        can not handle this block size)

      * Netmail packets are transmitted as files with names in the form
        "12345678.PKT". Because of this, multiple packets may be sent in 
        a single session.

      * If the calling system transmits a .REQ file for file requests, the
        receiving system can respond to it.  See "WaZOO File Requests" 
        (below) for information on the .REQ file.

2. ZedZip
   ------

        This capability is identical to ZedZap, but does not use buffers
        greater than 1K in size (like "True" Zmodem). It is also 
        permissible to send a "null" packet in a ZedZip session. This
        allows a system which must use a strict Zmodem implementation to
        participate in a WaZOO session using Zmodem.


3. DietIFNA
   --------

        The session operates like FTS-0001/FTS-0007. The notable exceptions 
        are as follows:

      * The same packet naming convention as ZedZap applies, allowing more
        than one packet to be transmitted in a single session.

YooHoo and YooHoo/2u2                                              Page 4
WaZOO Protocols



      * Telink file transfers don't even attempt to exchange file names
        using modem7. The receiving system extracts the file name from the 
        Telink or SEAlink header block.

      * If SEAlink is used, run-ahead (the number of blocks to slide) is 
        based on the baud rate:  BlocksToSlide = BaudRate / 400, up to a 
        max of 24 blocks.

      * When there is nothing to send, a system should remain quiet.  In 
        other words, the end of a session can be determined by a timeout.

      * Under no circumstances should "BARK" file request logic be active
        during a DietIFNA session. File requests, if any, should be 
        transmitted using a .REQ file.


        Many implementations of DietIfna have been accomplished by the mere
        exchange of packets, followed by straight FTS-0001/0007 code. This
        is incorrect but probably not easily remedied at this point. We have
        made an effort to document this change in "reality" in this revision
        of the document.

4. Janus
   -----

        Janus is a full-duplex simultaneous bidirectional file transfer
        protocol. In other words, it can send and receive files at the same
        time.  It's very loosely derived from ZModem and HDLC/X.25 protocol
        technology, in that it uses variable length data-typed packets, and
        that transmission of file data does not require ACKs.

        The protocol is documented elsewhere; it is beyond the scope of this
        document to do so.

YooHoo and YooHoo/2u2                                              Page 5
Choosing WaZOO Methods



How to decide which WaZOO method to use
---------------------------------------


Since the called system has all the information  necessary to decide what
WaZOO method to employ,  the best way to implement the process is for the
calling  system  to send,  in its  capability  mask,  all the  bits which
correspond to methods it can use (or wants to use)  in communicating with
the called system.  The called  system then looks at these bits and sends
back only the bit which corresponds to the method it wants to use.

If the  called system  sends  back a mask  which contains  more  than one
capability of the  calling system,  it can create a  problem situation if
one system  arrives at its choice of methods  differently from the other.
Thus, when the called system doesn't make the choice, both systems should
choose as follows:

1. Janus

2. ZedZap

3. ZedZip

4. DietIFNA

The capability highest on the list which both systems indicate ability to
execute should be the one employed.

YooHoo and YooHoo/2u2                                              Page 6
WaZOO Filename conventions



WaZOO FILENAMES
---------------


1. MESSAGE PACKETS ... xxxxxxxx.PKT

        Normal (unarchived) messages are sent in a file name that has a tag 
        of .PKT.  The "x" characters should be hex digits.


2. ARCmail ... xxxxxxxx.{MO|TU|WE|TH|FR|SA|SU}#

        Message packets are often shipped in an archive that has been
        compressed with some LZ utility.

        The file name consists of a name with hex digits. The tag is one of
        seven two-character prefixes ("MO", "TU", "WE", "TH", "FR", "SA" or
        "SU") and a number (0-9).

        This particular naming convention was established by ARCmail version
        0.60, which is a defacto standard in FidoNet.


3. FILE REQUESTS ... xxxxxxxx.REQ

        This is explained below.

        In a nutshell, the file name consists of the receiving system's 
        Fidonet address expressed as two 4-digit hex numbers.  The file tag 
        is .REQ.

        In a Janus session, the .REQ file isn't actually sent. Janus has
        a transaction system which sends the .REQ file one line at a time
        and then accepts the file(s) which the request generates.

YooHoo and YooHoo/2u2                                              Page 7
Flow of a ZedZap or ZedZip Session



FLOW OF A ZEDZAP OR ZEDZIP SESSION
----------------------------------



The calling system:


      * Send YooHoo

      * Receive YooHoo/2u2

      * In a single batch, send bundles, files, file request (.REQ) files 
        (in that order)

      * In a single batch, receive bundles, files, file requests, and 
        requested files (in that order)

      * If a file request (.REQ) file came in, send all requested files 
        in a single batch.


Receiving system:

      * Receive YooHoo

      * Send YooHoo/2u2

      * In a single batch, receive bundles, files, file requests

      * In a single batch, send bundles, files, our file requests, and 
        respond to file requests that arrived from the remote system.

      * If we sent a .REQ file in the preceding step, receive all files 
        in a single batch.


YooHoo and YooHoo/2u2                                              Page 8
WaZOO File Requests



WAZOO FILE REQUESTS
-------------------

Rick Huebner, who adapted the ZModem routines for Opus, and the architect of
the Janus file transfer protocol, designed the ".REQ file"-based file request
system.


REQ FILE:

A WaZOO file request is based on a request file.  The name of a request file
is similar to the .OUT and .FLO files used by Opus-CBCS and similar mail
products (such as BinkleyTerm).

         TEMPLATE: netnode.REQ

         EXAMPLE:  00010002.REQ   ... a request being sent to 1/2

The .REQ file is simply a text file that contains the files we want from the
remote system. Those file names can include wildcards, but should not contain
a path. Optionally, there can be a password if the sending system requires one.

The "netnode" part of the file name is built from the remote systems net and
node numbers.  Both numbers become 4-character hex numbers in the file name.

Let's say we're requesting THIS.ARC and all node lists from 12/2.  The file
name would be 000C0002.REQ.  The contents would look like this:

                  this.arc
                  nodelist.*

If the sysop of 12/2 requires a password of THAT to get the file THIS.ARC, the
REQ file contents would have to change:

                  this.arc !that
                  nodelist.*

Transaction-level passwords (of 6 or fewer characters) follow the file name:

                  !

YooHoo and YooHoo/2u2                                              Page 9
WaZOO File Requests




If the request is of the "update" genre, the type of update and the time,
expressed as a UNIX-style long decimal ASCII number, follows the name, or in
the event that there is a transaction-level password, the password. For
example, an update request for file NEWOPUS.*, where you already have a file
dated 1-January 1989, 00:00 and you live on the East Coast (GMT+06) would be:

                  NEWOPUS.* +599634000

The sign is required, it indicates the type of update request. A '+' means
that all files matching the filespec "NEWOPUS.*" newer than the shown time
will be sent, a '-' means that all matching files with dates up to and
including the indicated time will be sent.


The complete format of an action line in an REQ file is, then:

          [!][<+/->
Back Go Back