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

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

See note 3.

3.10. To-name
This variable length field is filled with the -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  character. The maximum length of the string is 36
characters including the  termination. E.g. the name Jim Brown is
represented as "Jim Brown".

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 -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
 character. The maximum length of the string is 36 characters
including the  termination. E.g. the name Jim Brown is
represented as "Jim Brown".

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 -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 
character. The maximum length of the string is 72 characters including
the  termination. E.g. the subject "FTS-0001" is represented as
"FTS-0001".

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 -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
 character. The maximum length of the string is unlimited. E.g.
the text "FTS-0001" is represented as "FTS-0001".

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, 
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  character. The
 character must not appear in any other position of a paragraph.

The general format of a paragraph containing a kludge is

  ": "

where  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

  ":"

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

  "FMPT "

where  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

  "FMPT 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.

---