Articles
back to main table of contents back to fidonews.orgInternet newsgroup<>echomail
gating service now available
By Joe Jared (1:103/301@fidonet) joejared@webworldinc.com
Special thanks to Remarq.com, (formerly supernews.com) for making control messages available to me for creation of newsgroups. If what I'm told is correct on this topic, newsgroups once added, are global in scope.
TO ANY MODERATORS INTERESTED:
Your echo can be gated to the internet on request. To initiate gating of your echo, simply send netmail or an email to one of my addresses as listed above and respond to the confirmation message. Once the echo has successfully be made global, the moderator may assume the gating duties assuming software is available to do so. The software I am currently using is compatable with most news servers and works with Windows 95/98/NT and is freeware. The key solutions however in performing this gateway are available from newsgate@webworldinc.com, a listserv open to all.
The structure as the echo would appear on the internet would be fidonet.*, where the * is the name of your echo. In some cases, it may appear as fidonet.name.*, replacing the underscores '_' with dots if deemed appropriate to the heirarchy. For example:
SIP_ACA would be mapped to fidonet.sip.aca, because it is a part of a group of echoes preceded with the keyword SIP.
Your message as the moderator of an echo would need to include heirarchy if it's not readily visible as well as a request to have it added to internet distribution. I will then respond to the elisted moderator address for all cases except where the moderator is a known highjacker, in which case the recognized moderator will take precedence. No gated echo need be elisted but it would make things easier for me if you as moderator elisted the echo.
If you are in contact with moderators of other newsgroups and would like your echomail conference merged with their newsgroup, a request from both moderators are required, and can be broken on request by either party.
As a moderator the ONLY requests honored will be to add "known" spammers to the kill list, and to add and remove it from internet distribution. The object of this gateway is to improve the volume of traffic while minimizing some of the hazards (Spam, Viruses, trojans, twits etc). A gated echo will disappear from distribution if it is deemed to be a problematic echo (I.E. too much used cowfood involved in distributing it). This service is free and as such should have reasonable expectations. Initially this system will be limited in terms of echoes that can be gated (I'm using soon to be replaced and outdated tosser that only supports 2048 echoes), but I doubt this will be a problem for a few months.
As a final note, once mail leaves or enters fidonet, it is no longer bound by policy4, nor can it be expected to, as it is no longer just fidonet mail. The gateway assumes no liablity for traffic whether it be legal or otherwise and will take prompt action once notified of an repeated offense, but it cannot be expected that all internet gated echoes will be free of clutter. One a positive note however, your echomail area will receive the exposure that it desperately needs to thrive and grow.
back to articles table of contents back to main table of contents back to fidonews.orgPacket type 2,
draft 990328
by Goran Eriksson, 2:201/505, get@get.pp.se
[Note: for full FTSC specs see http://www.ftsc.org. jb]
It seems to be the general opinion among FTSC members that packet type 2+ (and possibly others like packet type 2.2 and the packet type proposed by FSC-48) should receive FTS status.
To prepare for this I have written a document describing packet type 2 as this is the basis for all of these other packet types.
I do not expect this document to be included verbatim into a new FTS. Neither for packet type 2, nor for the other packet types.
However, I hope that the FTSC will find my document useful enough to build the new FTS documents upon it.
Therfore, I will post my latest draft in the following messages and invite you to comment on it in the NET_DEV echomail conference.
English is a foreign language to me. Purely linguistic remarks are welcome, but please send them to me by netmail or e-mail.
1. General
A packet file of type 2 has the following general layout
--------------------- | Packet header | --------------------- | Packed message | --------------------- : : --------------------- | Packed message | --------------------- | Packet terminator | ---------------------
The number of packed messages may be 0 or more.
2. Packet header
2.1. General
The packet header of a packet file of type 2 has the following general layout
Relative Size
byte offset in bytes
-----------------------
0 00H | Origin Node | 2
-----------------------
2 02H | Destination Node | 2
-----------------------
4 04H | Year | 2
-----------------------
6 06H | Month | 2
-----------------------
8 08H | Day | 2
-----------------------
10 0AH | Hour | 2
-----------------------
12 0CH | Minute | 2
-----------------------
14 0EH | Second | 2
-----------------------
16 10H | Baud Rate | 2
-----------------------
18 12H | Packet Type | 1
-----------------------
20 14H | Origin Net | 2
-----------------------
22 16H | Destination Net | 2
-----------------------
24 18H | Product Code | 1
-----------------------
25 19H | Serial Number | 1
-----------------------
26 1AH | Password | 8
-----------------------
34 22H | Origin zone | 2
-----------------------
36 24H | Destination zone | 2
-----------------------
38 26H | Reserved | 20
-----------------------
The total size of the packet header is 58 bytes.
2.2. Origin Node
This field contains information about the node number of the system having created the packet. The field contains a 16-bit binary unsigned integer in the range 0-65535.
See notes 1 and 2.
2.3. Destination Node
This field contains information about the node number of the system for which the packet was created. The field contains a 16-bit binary unsigned integer in the range 0-65535.
See notes 1 and 2.
2.4. Year
This field contains information about the year when the packet was created. The field contains a 16-bit binary unsigned integer in the range 0-66535.
See notes 2 and 3.
2.5. Month
This field contains information about the month when the packet was created. The field contains an 8-bit binary unsigned integer in the range 0-11. The following representation is used:
Month represented as January 0 February 1 March 2 April 3 May 4 June 5 July 6 August 7 September 8 October 9 November 10 December 11
See note 3.
2.6. Day
This field contains information about the day when the packet was created. The field contains an 8-bit binary unsigned integer in the range 1-31.
See note 3.
2.7. Hour
This field contains information about the hour when the packet was created. The field contains an 8-bit binary unsigned integer in the range 0-23.
See note 3.
2.8. Minute
This field contains information about the minute when the packet was created. The field contains an 8-bit binary unsigned integer in the range 0-59.
See note 3.
2.9. Second
This field contains information about the second when the packet was created. The field contains an 8-bit binary unsigned integer in the range 0-59.
See note 3.
2.10. Baud Rate
This field is filled with the 16-bit binary unsigned integer 0 by the system creating the packet. Any system receiving the packet may ignore the value of this field. For historical reasons this field is called Baud Rate.
See note 2.
2.11. Packet Type
This field is filled with the 16-bit binary unsigned integer 2 by the system creating the packet. Any system receiving the packet should check the contents of this field. If it does not contain the 16-bit binary unsigned integer 2 it is recommanded that the receiving system regards it unsafe to unpack this packet according to the format specification for packet type 2. Any further actions by the receiving system in this case are left to the implementation.
See note 2.
2.12. Origin Net
This field contains information about the net number of the system having created the packet. The field contains a 16-bit binary unsigned integer in the range 1-65535.
See notes 1 and 2.
2.13. Destination Net
This field contains information about the net number of the system for which the packet was created. The field contains a 16-bit binary unsigned integer in the range 1-65535.
See notes 1 and 2.
2.14. Product Code
This field contains information about the product code assigned to the programme creating the packet. The field contains an 8-bit binary unsigned integer in the range 0-255.
Product codes are assigned to programmes by the FTSC. See FTA-1005. That document also contains information about what product codes to use by programmes which have not yet been assigned a product code by the FTSC.
2.15. Serial Number
This field may contain information about the serial number of the programme creating the packet. The field contains a 8-bit binary unsigned integer in the range 0-255. If a programme does not want to assign any serial number to this field it should fill this field with the 8-bit binary unsigned integer 0.
2.16. Password
This field contains information about a packet level password. The field contains an array of 0-8 ASCII characters, each in the range '0'..'9', 'A'..'Z'. The programme creating the packet should fill all unused bytes in this field with the 8-bit binary unsigned value 0. Any programme receiving a packet should ignore any bytes in this field after the first occurence of an byte with the value 0. The comparison of passwords in a received packet file is done case insensitively.
Any programme receiving a packet with a password differing from the password set up between the system having created the packet and the system receiving it (including the absence of a password when one has been agreed upon) should consider the information contained in the packet about the system that has created as unreliable. Any further actions by the receiving system in this case are left to each implementation.
See note 5.
2.17. Origin Zone
This field may contain information about the zone number of the system having created the packet. The field contains a 16-bit binary unsigned integer in the range 1-65535. If a programme does not wish to enter a zone number into this field it should fill it with the 16-bit binary unsigned value 0.
See notes 1, 2 and 4.
2.18. Destination Zone
This field may contain information about the zone number of the system for which the packet was created. The field contains a 16-bit binary unsigned integer in the range 1-65535. If a programme does not wish to enter a zone number into this field it should fill it with the 16-bit binary unsigned value 0.
See notes 1, 2 and 4.
2.19. Reserved
This field is filled by the programme creating the packet with an array of bytes with the 8-bit binary unsigned value 0. Any programme receiving a packet should ignore the contents of this field.
3. Packed message format
3.1. General
The packed message in a packet file of type 2 has the following general layout
Relative
byte offset
-----------------------
0 00H | Packet Type |
-----------------------
2 02H | Origin Node |
-----------------------
4 04H | Destination Node |
-----------------------
6 06H | Origin Net |
-----------------------
8 08H | Destination Net |
-----------------------
10 0AH | Attribute |
-----------------------
12 0CH | Cost |
-----------------------
14 0EH | Date and Time |
-----------------------
34 22H | To-name |
-----------------------
| From-name |
-----------------------
| Subject |
-----------------------
| Message body |
-----------------------
The total size of the packed message is variable.
3.2. Packet Type
This field is filled with the 16-bit binary unsigned integer 2 by the system creating the packet. Any system receiving the packet should check the contents of this field. If it does not contain the 16-bit binary unsigned integer 2 it is recommanded that the receiving system regards it unsafe to unpack this packet according to the format specification for packet type 2. Any further actions by the receiving system in this case are left to the implementation.
See note 2.
3.3. Origin Node
This field contains information about the node number of the system having created the message. The field contains a 16-bit binary unsigned integer in the range 0-65535.
See notes 1 and 2.
3.4. Destination Node
This field contains information about the node number of the system for which the message was created. The field contains a 16-bit binary unsigned integer in the range 0-65535.
See notes 1 and 2.
3.5. Origin Net
This field contains information about the net number of the system having created the message. The field contains a 16-bit binary unsigned integer in the range 1-65535.
See notes 1 and 2.
3.6. Destination Net
This field contains information about the net number of the system for which the message was created. The field contains a 16-bit binary unsigned integer in the range 1-65535.
See notes 1 and 2.
3.7. Attribute
This field contains information about the attributes assigned to the message in question. This field is treated as a 16-bit bit mapped flag field with the following assignments:
Bit Meaning --- ------- 0 Private 1 Crash 4 File Attached 10 Reserved 11 File Request 12 Return Receipt Request 13 Is Return Receipt 14 Audit Request 15 File Update Request
See note 2.
3.7.1. Private
When this attribute is set the message is considered private and intended for the addressee only. See a separate document for the use of the Private attribute in echomail messages.
3.7.2. Crash
When this attribute is set the message is considered high-priority. A system that encounters a message with the Crash attribute set normally makes an effort to speed the delivery of the message in question if it is not intended for the own system. However, the actions actually to be taken upon receipt of a message with the Crash attribute set is left to each implementation.
3.7.3. File Attached
When this attribute is set it is supposed that one or more files are attached to the message. The files are transferred separately from the packet file in which the message with the File Attached attribute is contained. See also 3.12.1.
A message with the File Attached attribute set may contain a message body.
Normally a message with the File Attached attribute set must be sent directly to the destination system since ftn systems usually are not set up for the routing of non-mail files.
3.7.4. Reserved
This attribute bit is reserved for future use. It should not be checked by a programme receiving a type 2 packet.
3.7.5. File Request
When this attribute is set it is supposed that one or more files are requested from the desination system of to the message. See also 3.12.1.
A message with the File Request attribute set may contain a message body.
Normally a message with the File Request attribute set must be sent directly to the destination system since ftn systems usually are not set up for the routing of non-mail files.
3.7.6. Return Receipt Request
When this attribute is set it is assumed that the sender of the message requests a return receipt. A Return Receipt in this connection means a receipt from the final destination system that the message has arrived there. It is left to each implementation what steps to take when a message with the Return Receipt Request attribute bit is received.
3.7.7. Is Return Receipt
When this attribute is set it is assumed that the message in question is a return receipt. It is left to each implementation what steps to take when a message with the Is Return Receipt attribute bit is received.
3.7.8. Is Audit Request
When this attribute is set it is assumed that the sender of the message requests audit receipts. An Atuidt Receipt in this connection means a receipt from each of the systems transporting the message in question on its way to the final destination that the message has passed there. It is left to each implementation what steps to take when a message with the Is Audit Request attribute bit is received.
3.7.9. File Update Request
When this attribute is set it is supposed that a file update is requested from the desination system of to the message. See also 3.12.1.
A message with the File Update Request attribute set may contain a message body.
Normally a message with the File Update Request attribute set must be sent directly to the destination system since ftn systems usually are not set up for the routing of non-mail files.
3.7.10. Attribute bits 2-3, 5-9
Any programme creating a packet may set bits 2-3 and 5-9 in the message attribute field to 0. They should not be checked by a programme receiving a type 2 packet.
These attribute bits are normally only used for information interchange between different programmes on the system where the message in question is created.
3.8. Cost
This field is filled with the 16-bit binary unsigned integer 0 by the system creating the packet. Any system receiving the packet may ignore the value of this field. For historical reasons this field is called Cost.
See note 2.
3.9. Date and Time
This field is filled with a <NUL>-terminated ASCII character string representing the date and the time when the message in question was created.
The string has the following format
DD " " Month " " YY " " " " HH ":" MM ":" SS <NUL>
where
DD = "01" | "02" | "03" | ... | "31"
Month = "Jan" | "Feb" | "Mar" | "Apr" |
"May" | "Jun" | "Jul" | "Aug" |
"Sep" | "Oct" | "Nov" | "Dec"
YY = "01" | "02" | .. | "85" |
"86" | ... | "99" | "00"
HH = "00" | .. | "23"
MM = "00" | .. | "59"
SS = "00" | .. | "59"
The representation of the year contains the two last digits of the year in question. E.g. the year 1999 is represented as "99" and the year 2000 as "00".
Considering the time when packet type 2 was first put into use, values "80".."99" is assumed to represent 1980..1999 and values "00".."79" is assumed to represent 2000..2079.
The length of the string is 20 characters including the <NUL> termination.
See note 3.
3.10. To-name
This variable length field is filled with the <NUL>-terminated character string representing the name of the addressee of the message in question. In the case the programme creating the packet does not want to put any actual name there, the field should be filled with a single <NUL> character. The maximum length of the string is 36 characters including the <NUL> termination. E.g. the name Jim Brown is represented as "Jim Brown"<NUL>.
The character set used in this field is the same as given in the message body (see a separate document). If no character set is given there, the ASCII character set is used.
Character codes 1..31 may not be used within this field.
3.11. From-name
This variable length field is filled with the <NUL>-terminated character string representing the name of the sender of the message in question. In the case the programme creating the packet does not want to put any actual name there, the field should be filled with a single <NUL> character. The maximum length of the string is 36 characters including the <NUL> termination. E.g. the name Jim Brown is represented as "Jim Brown"<NUL>.
The character set used in this field is the same as given in the message body (see a separate document). If no character set is given there, the ASCII character set is used.
Character codes 1..31 may not be used within this field.
3.12. Subject
This variable length field is filled with the <NUL>-terminated character string representing the subject of the message in question. In the case the programme creating the packet does not want to put any actual subject there, the field should be filled with a single <NUL> character. The maximum length of the string is 72 characters including the <NUL> termination. E.g. the subject "FTS-0001" is represented as "FTS-0001"<NUL>.
The character set used in this field is the same as given in the message body (see a separate document). If no character set is given there, the ASCII character set is used.
Character codes 1..31 may not be used within this field.
3.12.1. File specifications
When the attribute field has bit 4, 11 and/or 15 set, the message subject field normally is replaced by a list of file specifications containing the file names the system where the message was created (directory, path and time information etc are discarded).
These file specifications are transmitted to the receiving system according to separate documents.
It should be noted that if the message is accompanied by an attached file which is to be routed via other systems before reaching the ultimate destination system, it may be essential for the intermediate systems that the message is indeed transmitted even if it is empty. By doing so, the intermediate systems will have a way of finding out the intended destination of the attached file.
It should also be noted that especially in the case of routed file attaches it is essential that file names are chosen so that they can be directly and easily handled under the same names by the respective host operating systems at the intermediate systems.
3.13. Message body
This variable length field is filled with the <NUL>-terminated character string representing the message text of the message in question. In the case the programme creating the packet does not want to put any actual text there, the field should be filled with a single <NUL> character. The maximum length of the string is unlimited. E.g. the text "FTS-0001" is represented as "FTS-0001"<NUL>.
See note 7.
The character set used in this field is the same as given in the message body (see a separate document). If no character set is given there, the ASCII character set is used.
Character codes 2..9,11..12,14..31 may not be used within this field.
Character code 141 may be used within this field irrespective of the character set used.
Character code 1 may be used only for the purpose given below.
Special considerations about certain character codes apply:
3.14. Character code 1, <SOH>
To include extra addressing and control information, the message body may contain so called kludges.
Each kludge is contained within a separate paragraph of text as defined in 3.16. A paragraph containing a kludge may not contain any other message text.
Each paragraph containing a kludge starts with <SOH> character. The <SOH> character must not appear in any other position of a paragraph.
The general format of a paragraph containing a kludge is
<SOH><Kludge tag>": "<string><CR>
where <string> is some sort of value related to the kludge in question.
If no such value is required for a certain kludge, the general format of a paragraph containing such a kludge is
<SOH><Kludge tag>":"<CR>
Developers may introduce new kludges on an experimental basis as they see fit. Kludge tags which are documented in FTS documents must however not be used in any other way than according to those FTS documents. Kludge tags which are documented in FSP or FSC documents should not be used in any other way than according to those documents.
Consequently each programme receiving a type 2 packet file should retain any unknown kludge verbatim and at an unchanged a position within the message body as possible. This is particularly essential for messages which are to be routed to another system.
The ASCII character set is used in paragraphs containing kludges.
This document describes three kludges: FMPT, TOPT and INTL.
3.14.1. FMPT
The FMPT kludge is used to give information about the point number of the sender of a message if that point number is not 0. If the point number of the sender of a message is 0 that message should not contain any FMPT kludge.
The format of a paragraph containing a FMPT kludge is
<SOH>"FMPT <point number>"<CR>
where <point number> is the ASCII representation of the point number of the sender. The point number is an unsigned integer in the range 1-65535. See note 1.
E.g. a message from point number 1 of a certain node contains the following FMPT kludge
<SOH>"FMPT 1"<CR>
Note that the format of a paragraph containing a FMPT kludge deviates from the general format given above in that it does not contain any colon after the kludge tag.
3.14.2. TOPT
The TOPT kludge is used to give information about the point number of the addressee of a message if that point number is not 0. If the point number of the addressee of a message is 0 that message should not contain any TOPT kludge.
The format of a paragraph containing a TOPT kludge is
<SOH>"TOPT "<point number><CR>
where <point number> is the ASCII representation of the point number of the sender. The point number is an unsigned integer in the range 0-65535. See note 1.
E.g. a message to point number 1 of a certain node contains the following TOPT kludge
<SOH>"TOPT 1"<CR>
Note that the format of a paragraph containing a FMPT kludge deviates from the general format given above in that it does not contain any colon after the kludge tag.
3.14.3. INTL
The INTL kludge is used to give information about the zone numbers of the sender and the addressee of a message.
The format of a paragraph containing a INTL kludge is
<SOH>"INTL "<destination address>" "<origin address><CR>
where <destination address> is the ASCII representation of the destination address and <origin address> is the ASCII representation of the origin address of the message in question. These addresses is given on the form <zone>:<net>/<node> where <zone> is the ASCII representation of the zone number, <net> is the ASCII representation of the net number and <node> is the ASCII representation of the node number. Any point number information is given in FMPT and TOPT kludges.
E.g. a message from address 1:123/4.5 to 2:345/6.7 node contains the following INTL kludge
<SOH>"INTL 2:345/6 1:123/4"<CR>
Note that the format of a paragraph containing a INTL kludge deviates from the general format given above in that it does not contain any colon after the kludge tag.
INTL kludges are also often used even when both the originating and the destination systems are in the same zone. This gives both the originating system and the destination system as well as any intermediate routing systems unambiguous zone information even in a situation where one system may be active in a number of different zones.
However, it is known that some programmes may route messages incorrectly if the INTL kludge is present in messages where both the originating and the destination systems are in the same zone.
3.15. Character code 10, <LF>
Programmes creating packet files may put <LF> characters into the message body. These characters should be disregarded by any programmes displaying the message to a user. Instead text should be formatted according to local conditions such as user preferences and/or physical/logical constraints of display equipment.
Use of <LF> characters in the message body is discouraged. However <LF> characters should not be removed from the message body of in-transit messages.
3.16. Character code 13, <CR>
The <CR> character is used for the purpose of terminating paragraphs of text. Any programme displaying the message to a user should format the text accordingly.
3.17. Character code 141, soft-<CR>
Programmes creating packet files may put soft-<CR> characters into the message body. These soft-<CR> characters are usually used to prescribe local formatting on the system where the message in question was created. These characters should be disregarded by any programmes displaying the message to a user.
Use of soft-<CR> characters in the message body is discouraged. However soft-<CR> characters should not be removed from the message body of in-transit messages.
In certain character sets, character code 141 may be used for a vital part of the character set. If it can be assumed that the message is written in such a character set, character code 141 may be used and displayed.
4. Packet file names
The name of a packet file when transmitted to another system is of the form
HHHHHHHH.PKT
where HHHHHHHH is a string of 8 hexadecimal digits in the ASCII character set and .PKT is the literal ".PKT" also in the ASCII character set.
The value for HHHHHHHH is chosen so as to minimize the risk of any system receiving several packet files with the same name before all the previously received files of that name have been processed.
5. Arcmail
To minimize the storage requirements for packet files and the time and cost for their transmission from system to system, zero or more packet files may be aggregated into compressed archives (Arcmail bundles) using lossless compression programmes. This scheme is normally called Arcmail after the programme once produced by System Enhancement Associates.
Such compression programmes are not specified by this standard but are generally available for a number of platforms.
However, the availability of suitable decompression programmes on a certain system cannot be guaranteed. Therefore Arcmail should only be used after prior agreement between the operators of the two systems involved.
When Arcmail bundles are to be used their file names when transmitted to another system is of the form
HHHHHHHH.DDN
where HHHHHHHH is a string of 8 hexadecimal digits in the ASCII character set and .DD is one of the following literals
".MO", ".TU", ".WE", ".TH", ".FR", ".SA", ".SU"
in the ASCII character set and N is a the ASCII representation of decimal digit 0-9.
See note 6.
7. Address interpretation
Packet type 2 has been in use during a long period of time during which the number and the complexity of ftn networks have increased greatly.
The addressing requirements during this period have increased. Some of these additional requirements have been met in packet type 2 by adding kludges as defined above.
The following guidelines can be given for the interpretation of the ftn addresses of type 2 packet files:
- The origin and destination zone numbers are given explicitly in the packet header if they are different from 0 and the packet is created by a programme that is known to put that information there. One such programme is QMail.
- The origin net and node numbers are given explicitly in the packet header.
- The destination net and node numbers are given explicitly in the packet header.
- The origin and destination point numbers cannot be found in a type 2 packet. (For the case of Fakenets see section 8.)
The following guidelines can be given for the interpretation of the ftn addresses of messages in type 2 packet files:
- The origin and destination zone numbers are given explicitly in an INTL kludge in the message body if there is such a kludge. (For the case of Zone Gating see section 8.)
- If there is no INTL kludge in the message body or there is an INTL kludge that is not conformant with this specification the missing zone numbers may be assumed to be equal to the originating zone number in the packet header if that information is available. (For the case of Zone Gating see section 8.)
- If any zone number cannot be determined in steps 1 and 2 it may be assumed to be equal to the zone number of the main address of the own system. (For the case of Zone Gating see section 8.)
- The origin net and node numbers are given explicitly in the message header.
- The destination net and node numbers are given explicitly in the message header. (For the case of Zone Gating see section 8.)
- The originating point number is given in the FMPT kludge in the message body if there is such a kludge.
- If there is no FMPT kludge in the message body or there is a FMPT kludge that is not conformant with this specification the originating point number may be assumed to be 0.
- The destination point number is given in the TOPT kludge in the message body if there is such a kludge. (For the case of Zone Gating see section 8.)
- If there is no TOPT kludge in the message body or there is a TOPT kludge that is not conformant with this specification the destination point number may be assumed to be 0. (For the case of Zone Gating see section 8.)
8. Fakenets
Some existing programmes have limited support for point addressing.
In order to still allow for points when such programmes are in use, sometimes a system called Fakenets or Fakenet Addressing is used.
The operator of a ftn node using Fakenets defines a special net number, not included in the general nodelist, for the points under that node.
That ftn node itself assumes the role of host for that net, i.e. assumes the address <fakenet>/0. The point systems are then assigned node numbers within that Fakenet. These node numbers are usually equal to the point numbers which they have been assigned. There may or there may not be a zone number assigned to the Fakenet. If a zone number is assigned it usually is the zone number in which the ftn node itself is active.
A ftn node operating a Fakenet should use programmes which do the readdressing of messages so that systems outside of the Fakenet need not be aware of the address allocations within the Fakenet.
E.g. assume that node 1:234/5 operates a fakenet with net number 23450. Programmes at 1:234/5 are then expected to readdress any message to 1:234/5.1 to whatever node number that point system has within the fakenet (usually 1:23450/1). Likewise, programmes at 1:234/5 are expected to readdress any messages from 1:23450/1 to a destination outside the fakenet so that they appear to originate from 1:234/5.1 (providing that is the 4-dimensional point address which Fakenet node 1:23450/1 has).
9. Zone Gating
When two zones cover different geographical areas such as two different continents the technical difficulties and costs of establishing direct communications between two systems, one in each of these zones, may be considered a problem.
For that purpose there may by administrative decisions be appointed one or more zone gates for message traffic from one zone to the other. The zone gates are systems whose operators have taken on the task of collecting and transmitting message traffic from the own zone to the foreign zone.
To allow for such zone gating the following addressing guidelines apply.
The origin address and the final destination address is given with the help of INTL, FMPT och TOPT kludges in the message body.
The message header contains the node and net numbers of the originating system and the node and network numbers of the zone gate.
Notes
Note 1
It may be noted that certain existing programmes may represent point, node, net and zone numbers as signed integers on the user interface level. E.g. node number 65535 may be represented as -1.
Note 2
Big-endian byte order (also known as Intel byte order) is used for 16- bit binary integers.
Each field containing a 16-bit binary integer is composed of two bytes O0 and O1:
+----+----+ ! O0 ! O1 ! -----+----+
where O0 contains bits 0-7 and O1 bit 8-15 of the 16-bit binary integer.
Bit 0 is the least significant bit and bit 15 is the most significant bit of the 16-bit binary integer.
Note 3
It may be noted that this document does not contain any information about how to decide the time zone used in the fields for date and time in a packet. It is however expected that most programmes use the local system time in these fields.
Note 4
It may be noted that certain existing programmes put additional restrictions on the range of valid zone numbers. E.g. the zone numbers may be restricted to 1-255 or 1-4095.
Note 5
There are a number or programmes in current use which allow also non-ASCII characters to be entered into the packet level password. E.g. character codes 128-255. There is no way within the framework of this common ftn practice to tell what character set is used in this case. Therefore it is also not possible for a programme to implement a general case translation algorithm for such characters.
Note 6
Certain existing programmes are known to produce Arcmail bundles with file names when transmitted where N may be an ASCII character in the range '0'..'9', 'A'..'F'.
Certain other existing programmes are known to produce Arcmail bundles with file names when transmitted where N may be an ASCII character in the range '0'..'9', 'A'..'Z'.
The capability of processing Arcmail bundles with such extended file names is not required by this specification and they should therefore only be used after prior agreement between the operators of the two systems involved.
Note 7
This specification specifies the size of the message body as unlimited.
For obvious reasons, each system has some maximum size for a message body and for a packet file. Furthermore the file transfer protocols specified for ftn sessions separately may also impose maximum sizes on files to be transferred from one ftn system to another.
Finally some existing programmes/platforms may have their own limits as to the maximum size of a message and to the maximum size of a packet file. E.g. some computer architectures use segmented memory and then the developer of a certain existing programme may have chosen to see to it that each data structure fits within one such segment, e.g. 64 kilobytes. Other existing programmes may have internal limits to the size of the message body, e.g. 10 or 32 kilobytes.
Procedures for splitting and recombining large messages are specified in other FTSC documents.
back to articles table of contents back to main table of contents back to fidonews.org