bbs/deb-mbse
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fixed HTML codes in Fidonet documents

Browse Source
This commit is contained in:
Michiel Broek
2002-02-16 21:38:40 +00:00
parent 1fb610f935
commit 0aa608b565
42 changed files with 18330 additions and 18508 deletions
Download Patch File Download Diff File Expand all files Collapse all files

611
html/ftsc/fsc-0087.html
View File

@@ -1,305 +1,306 @@
<HTML>
<HEAD>
<TITLE>File Forwarding in Fidonet Technology Networks.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| 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-
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>File Forwarding in Fidonet Technology Networks.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| 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-
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>