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