| 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-
BackGo Back