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

  "TOPT "

where  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

  "TOPT 1"

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

  "INTL ""
"

where  is the ASCII representation of the
destination address and  is the ASCII representation
of the origin address of the message in question. These addresses is
given on the form :/ where 
is the ASCII
representation of the zone number,  is the ASCII representation
of the net number and  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

  "INTL 2:345/6 1:123/4"

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, 
Programmes creating packet files may put  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  characters in the message body is discouraged. However
 characters should not be removed from the message body of
in-transit messages.

3.16. Character code 13, 
The  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-
Programmes creating packet files may put soft- characters into the
message body. These soft- 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- characters in the message body is discouraged.
However soft- 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:

1. 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.
2. The origin net and node numbers are given explicitly in the packet
header.
3. The destination net and node numbers are given explicitly in
the packet header.
4. 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:
1. 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.)
2. 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.)
3. 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.)
4. The origin net and node numbers are given explicitly in the
message header.
5. The destination net and node numbers are given explicitly in the
message header. (For the case of Zone Gating see section 8.)
6. The originating point number is given in the FMPT kludge in the
message body if there is such a kludge.
7. 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.
8. 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.)
9. 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 /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.

---