      | Document: FSC-0087
      | Version:  001
      | Date:     31 October, 1995
      |
      | Robert Williamson FidoNet#1:167/104.0

        File Forwarding in Fidonet Technology Networks
        Robert Williamson FidoNet#1:167/104.0  robert@ecs.mtlnet.org

        Purpose:
            To  document  current practices in File Forwarding and the minimum
        requirements and known extensions of the TIC file format.

        Acknowledgements:
            The  TIC  file  format  was introduced by Barry Geller, in the MSDOS
        File Forwarder, Tick.  Useful extensions to this format were introduced
        by Harald Helms, in the MSDOS FileForwarder, AllFix.

        Terminology:
        FTN - Fidonet Technolgy Network, such as FIDONET, AMIGANET or IBMNET.
              Sometimes used interchangably with the term DOMAIN.

        FNC - FileName Conversion, process of converting filenames to msdos 8.3
              format for transmission.

        FQFA - Fully Qualified FTN Address, the format is
                  FTN#Zone:Net/Node.Point

        CRC - Cyclic Redundancy Check, method to determine whether some data
              has been altered. CRC-32 is used in File Forwarding.

        TIC - a file that contains control information for the File Forwarding
            system.   These  files  are  named  xxSTAMP.TIC,  where  xx  is  an
            abbreviation  representing  the  File  Forwarding  program name and
            stamp  is  a  unixdate  stamp  truncated  to 6 characters.

        UTC  -  Universal  Time  Coordinated,  the  time  at  the  0o  meridian
            (Greenwich); previously called GMT

        forwarding  -  the  process  of  creating and sending tic files and the
                       associated  file to one's downlinks.

        ticking - the processing of reading and verifying a tic file and it's
                  associated file.

        hatching - the process of introducing a new file into a fileecho

        cross-hatching - the process of forwarding a file from one fileecho
                         (ususally restricted) to another

        Associated File - The file listed in the FILE field of the TIC file.

            Note that use of UPPERCASE on tic file keywords in this document in
            for display purposes only.

      Format of a TIC file:

        Addressing:
            In  a  tic  file  any form of FTN address representation from 3d to
            FQFA  may  be  used.   All  File  Forwarders  must  understand  the
            following formats:
              zone:net/node                 - 3D
              zone:net/node.point           - 4D
              zone:net/node@ftn             - 5D - point 0 assumed
              zone:net/node.point@ftn       - 5D
              ftn#zone:net/node.point       - fqfa

            File Forwarders should have configurable options per site as to the
            type of addressing each of it's downlinks can understand.

        Dates:
            All dates are expressed in UTC.

        TimeDateStamps:
            All  TimeDateStamps are unix TimeDateStamps (# of seconds since Jan
            1, 1960) in UTC and expressed in hexadecimal notation.

        Case Insensitivity:
            the  format is completely case-insensitive.  It is general practice
            that  the  first  letter  of a keyword is uppercase.  This is not a
            requirement.

        Order Dependancy:
            keywords are not order dependant.
            Order  dependancy  is required in some groupings of a keyword, such
            as PATH, VIA, DESC and APP.

        Modification of address fields on PassThrough:
            The  forwarding  site may modify the addresses in any keyword field
            to  make  them  compliant  with  the addressing limitations of each
            downlink.

        Stripping of SeenBys:
            The  forwarding site may strip seenbys to current FTN, ZONE or NET,
            when not forwarding outside of current FTN, ZONE or NET.  This does
            not imply nor permit the stripping of of a direct downlink which is
            outside the current strip filter.

        Keywords:
          There are no colons on keywords.

          Each keyword line is terminated with CR LF pair.

          The maximum length of a keyword line is 256 characters, including the
          CRLF termination. Some keyword lines may have a shorter limit.

          Keywords  are  separated from their data by a single space.  There is
          no space if there is no data associated with the keyword.
            eg:  ReturnReceipt

          Keywords are case-insensitive and order independant.

          Keywords not understood are to be passed-though.

          Known Keywords that are blank should not be passed though.
            For  example,  an  empty  AREADESC,  could be either dropped or the
            blank  replaced with the proper description.

          Most Keywords are passed through when processing.
            There  are  exceptions.  In some cases, a site-specific replacement
            may be created.
            Keywords marked with a ^ should not be passed-through.

          Keywords marked with a * are REQUIRED when processing a TIC file.
            If  any  of these are missing, the tic file should be considered as
            BAD and the associated file not forwarded to downlinks.

          Keywords marked with a # are CREATED when hatching or forwarding.

        *#  AREA [AreaName]
              the TagName of the file area.

            AREADESC [description of area]                    OPTIONAL
              a  short  (80 chars) description of the file area.  This could be
              the description found in FileBone.NA

        *#  FILE [File being sent]
              the name of the file being sent, no path
              the filename must conform to msdos 8.3 format, unless it is known
              that the receiving site can handle longer filenames.

        ^#  FULLNAME [original filename before FNC]           OPTIONAL FNC only
              the original filename (no path) before FileName Conversion

        *#  CRC [CRC-32 in hex]
              crc of the file being sent, 8 hexadecimal characters

        ^   MAGIC [MagicName]               OPTIONAL
              Name  under  which the file can be FREQed from the site listed in
              FROM.   This  is  NOT  passed  though when forwarding, unless the
              MAGIC  name  is  the  same  on  the  forwarding  site.  It can be
              replaced by the appropriate name.

            REPLACES [FileName]               OPTIONAL
              Filename  (no  path)  of  a  file  hatched  in  the AREA that the
              associated file replaces.  If the site expects FNC files, and the
              filename  does  not confrom to msdos 8.3 convention, the REPLACES
              name should also be FNC.

         #  DESC [Description]
              Description of the file, limited to 80 characters per line,
              including CRLF termination.
              If  multiple LDESC lines are used, the DESC line must provide the
              maximum information.  No File Forwadrer is required to passthough
              or make use of any extra DESC line after the first.

         # LDESC [multiple lines]
              A  long description of the file.  LDESC does NOT replace DESC, it
              is  used IN ADDITION to the short description.  No File Forwarder
              is required make use of LESC lines.

         #  SIZE [Bytes]              OPTIONAL, SHOULD be required
              Length of the file in bytes

            DATE [TimeDateStamp]
              TimeDateStamp of the file. Can be date of creation of archive.

           RELEASE [TimeDateStamp]
              Date  when file is TO BE released.  Usually used by SDS, but can
              be used by ADS as well.

           AUTHOR [name]
              Name  of  the author of the software package being hatched.  This
              field  is  obviously not applicable to Newsletters, Nodelists and
              Diffs and the like.

           SOURCE [authors_address]
              FTN  address of the Author of the software package being hatched.
              Not  necessary  the same as the ORIGIN hatch site.  Does not have
              to be an FTN address.

         ^ APP [program] [Application Specific Information]
              The  APP  keyword  is  a  keyword  known  to programs of the name
              indicated.  APP'S are order dependent and must be passed though.

        *#  ORIGIN [Address]
              Site where file entered the fileecho

        *^# FROM [Address] [Pwd]
              Site  that  is  forwarding  the  file  to  the next site.  Pwd is
              optional and rarely used, IF AT ALL.  Pwd is NEVER passed through.

        ^   TO [Address]                        OPTIONAL
              Site  to  which  this TIC and the assocaited file are being sent.
              This keyword is included in the .TIC file when:
                a)  the file is being routed via another system which permits
                    such routing.
                b)  the  platform  in  use  does  not  have  any  FTN  software
                    independant   method   of   associating   a  file  nd  it's
                    destination.   eg.   platforms  that  do not have filenotes
                    that   could  contain  this  information  as  part  of  the
                    filesystem.

              If  the address in the TO line is that of the receiving site, the
              field  is  not passed through when forwarding.  If the address in
              the  TO  lines  IS  NOT  that of the receiving site, it should be
              forwarded to the TO site, if a routing agreement is in place with
              the sending site.

        *^# CREATED [by] [Program Banner]
              File  Forwarder which created the TIC file.  This is generally in
              the form:
                Created [by] program_name version [copyright_info]

            VIA [FROM CREATED]                  OPTIONAL (tracking)
              Copy  of  CREATED  line of FROM, with 'Created [by]' stripped and
              FROM  prepended.   Always passed though.  The VIA is only created
              by the receiving site when forwarding. It is never created by the
              hatching  site.  Therefore, in any TIC file, the addresses in the
              FROM and VIA should never be the same.
              examples:
              Via 1:167/100 ALLFIX+ 4.31 Copyright (C) 1992,95 Harald Harms (2:281/910)
              Via FIDONET#1:167/104.0 XTick 3 Copyright (c) 1995 Robert Williamson FIDONET#1:167/104.0

        *#  PATH [Address] [TimeDateStamp] [date and time]
              Address  of  Site  which  has forwarded the file.  TimeDateStamp,
              date and time is that of when the Site received and Processed the
              file.

        * # SEENBY [Address]
              Site  which  has  received the file.  There are multiple lines of
              Seenby and they are unordered.

        *   PW [password]
              Site or Area password.  This is case-insensitive and should be at
              least 5 characters in length.

            PGP [signature]
              PrettyGoodPrivacy signature. To be discussed.

        ^    ReceiptRequest -no data-               OPTIONAL
              A  request  to the receiving system to generate a IsReturnReceipt
              (attribute  word bit 13) messsage, in the same manner it would if
              it  had  received  a message with the FileAttach an ReturnReceipt
              attributes and a subject of the filename.
              There  is  NO  requirement  to recognize this keyword.  It should
              never be passed through.

      Transmission of Files:

        The  associated file, that is, the file Listed in the FILE field of the
      TIC  file, should always be sent FIRST.  In the case of a failed session,
      sending  the  FILE  first  prevents  the  orphaning  of  the file that is
      normally caused by the deletion or movement of the TIC file to BAD.

        File  Forwarders should not move or delete orphaned TIC files, but this
      can neither be relied upon nor mandated.

        File  Forwaders  should  be  transparent  to  the  renaming  of file by
      mailers.   This  means  that  if  the  mailer renames a duplicate file by
      renaming  or  bumpinmg  a numeric extension, the File Forwarder should be
      able  to  use  the  size  and  crc fields of the TIC to find and properly
      rename the associated file referred to in the TIC.

      File  Forwaders  should  always  delete and dequeue unsent TIC files when
      re-hatching  the  same  or  updated  version  of an associated file.  The
      implementor  may  wish  to  allow  exceptions  for  periodicals  such  as
      nodediffs and newsletters.

     -to be continued-

Go Back