Hi Paul,
         here are my suggested changes to the document. Changes are
shown as quotes. Deleted lines are marked as "> DEL:". Comments are
marked as "> COMMENT:"


Document: FTS-0501
Version:  002
Date:     1996-02-10
Title:    Mail packet format
Current Author: Paul Edwards
Current Addresses: 3:711/934{at}fidonet
Authors: Paul Edwards 3:711/934{at}fidonet
         Leonard Erickson 1:105/51{at}fidonet
Copyright: This document is released to the public domain


NOTE
----

If you intend to follow this proposal you must implement all of
it.  If you have any questions as to how certain sentences are
to be interpreted, do not hesitate to contact the author of this
document, whose address is at the top of this document.


BODY
----

This file documents the format of files that are received by
a mailer as described by the FTSCD specs.

Terms:

byte - a binary number from 0 to 255 stored in 8 bits.

integer - a 2-byte numeric data type, stored in little-endian format, 
ie low byte then high byte.  The values specified are to be treated
as unsigned integers, so there are no complications as to whether
negative numbers are represented as 2's complement, sign-magnitude
etc.  These are straight binary values.

> DEL: bytes - a sequence of bytes


A file will start off with a packet header, which is 58 bytes 
long.  The format of the packet header is:


Offset
Dec  Hex  Length   Data Type   Contents
 0    0    2       integer     originating node
 2    2    2       integer     destination node
 4    4    2       integer     4-digit year of packet creation date
 6    6    2       integer     month component of packet creation date (0-11)
 8    8    2       integer     day component of packet creation date (1-31)
10    A    2       integer     hour (0-23)
12    B    2       integer     minutes (0-59)
14    D    2       integer     seconds (0-59)
16   10    2       integer     baud (useless)
18   12    2       integer     constant value of 2, the packet type
20   14    2       integer     originating net
22   16    2       integer     destination net
24   18    1       byte        product code (optional)
25   19    1       byte        serial number (optional)
26   1A    8       bytes       password (optional)
34   22    2       integer     originating zone
36   24    2       integer     destination zone

Then comes one of the following...

Type 2...

> 38   26   20       bytes       filler (can be anything)

> COMMENT: There can not be a dual standard.

Extend Type 2+ (optional)...

40   28    2       integer     inverted capability word
42   2A    2       integer     expanded product code?
44   2C    2       integer     capability word
46   2E    2       integer     originating zone (optional)
48   30    2       integer     destination zone (optional)
50   32    2       integer     originating point (optional)
52   34    2       integer     destination point (optional)
54   36    4       bytes       product-specific field


Notes:

Any unused bytes in the password field must be NUL-filled.  The
password is normally completely NUL, and is there mainly for use
by non-mailprocessors.

> Any optional fields must be set to NULs if not used.

> COMMENT: a Technical Standard should be definite; you can't have it
> both ways.

The defined range of zone, net, node and point are 0-32767.  In
addition, net and node may have the value 0xFFFF, which represents
"-1".

The 1-byte product code is used as follows:
0x00 should be used by new programs.  For historical reasons,
most existing programs use codes from 0x00-0xFE.  0xFF is 
strictly reserved.

>          ********************************************

> After the packet header comes 0 or more NUL-terminated messages.
> The end of the packet is defined by an additional two NUL
> characters.

> DEL: The messages are stored as follows:

> DEL: First there is a 14-byte message header, then there are some
> DEL: variable-length NUL-terminated strings, then there is a text
> DEL: block, which is also NUL-terminated.

>DEL: In general, messages look like this:

> MESSAGE FORMAT:

1. message header
> 2. AREA line (if echomail)
> 3. optional control lines
> 4. user text, 30Kb maximum length
> COMMENT: user text should be limited 12-30K (say)
> 5. optional control lines
> 6. tear line (if echomail)
> 7. origin line (if echomail)
> 8. seen-by lines (if echomail)
> 9. optional control lines
> 10. NUL terminator

> 1. MESSAGE HEADER FORMAT:

> a. Fixed header
> b. Date string
> c. ToUserName string 
> d. FromUserName string 
> e. Subject string

> a. Fixed header

Offset
Dec  Hex  Length   Data Type   Contents
 0    0   2        integer     constant value of 2, the message type
 2    2   2        integer     originating node
 4    4   2        integer     destination node
 6    6   2        integer     originating net
 8    8   2        integer     destination net
10    A   2        integer     attributes
12    C   2        integer     cost (useless)

The attributes are a set of 16 bits, which have the following
meaning when set:

0x0001 - message is private
0x0002 - message to be crashed directly to destination
0x0004 - message has been read by recipient
0x0008 - message has been sent
0x0010 - subject specifies a file that accompanies message
0x0020 - message is in-transit
0x0040 - message destination is unknown (orphaned)
0x0080 - delete message after sending it
0x0100 - message was written locally
0x0200 - message is to be placed on hold to be picked up
0x0400 - officially unused, but has several unofficial uses
0x0800 - subject specifies name of file to file-request
0x1000 - return receipt requested
0x2000 - message is a return receipt
0x4000 - an audit trail is requested
0x8000 - subject specifies a file update request

> DEL:Then comes a date string, which is always 20-bytes in length,
> DEL:including the NUL terminator.  It is suggested you treat this
> DEL:as a variable length string, for historical reasons.

> b. Date string, NUL terminated

The date string can take two formats, as examples

> 1. "01 Oct 95  20:00:09"
> 2. "Sun  1 Oct 95 00:09"

> COMMENT: change example time to demonstrate zero-fill 

It is suggested that new programs always generate the first format,
but accept either format.

> COMMENT where does format #2 come from? It's not in FTS-0001.

Note:

1. The day in the first format has values from "01" to
"31" with a
leading zero.
2. The day in the second format has values from " 1" to
"31", with
no leading zero.
3. In both formats, the hours, minutes, seconds and year are zero
filled.
4. The range of days-of-weeks for the second format is "Mon",
"Tue",
"Wed" "Thu", "Fri", "Sat",
"Sun".  No language translations are
allowed.
5. The range of month for both formats is "Jan", "Feb",
"Mar", "Apr",
"May", "Jun", "Jul", "Aug",
"Sep", "Oct", "Nov", "Dec".  No
language
translations are allowed.
> DEL:6. All the characters in the date are the corresponding hex
> DEL:values from ISO 646 (same as ASCII).
> 6. Only 19 bytes are shown in the above formats, the NUL terminator
makes it 20 bytes total.

> DEL:Following the date comes the "To name", which is a maximum of 36
> DEL:characters including a terminating NUL.  There is no restriction
> DEL:on the content of this field, although it is suggested that
> DEL:implementations not put any ISO-646 defined control characters
> DEL:in this field, or the following 2 fields.

> COMMENT 1: Why limit the header strings to 36 or 72 characters?
> COMMENT 2: If there is no restriction on content, there is no
> restriction on content, so why be half-hearted about it?

> c. ToUserName string (NUL terminated)

> There is no restriction on the content of this string. Earlier
> versions were limited to 36 characters (including the NUL).
  
> DEL:After the "To name" field comes the "From
name" field, which
> DEL:follows the same rules as the "To name".

> d. FromUserName string (NUL terminated)

> There is no restriction on the content of this string. Earlier
> versions were limited to 36 characters (including the NUL).

> The next field is the "Subject" field, which follows the same rules
> as stated above, except that it is a maximum of 72 characters, not
> 36.

> e. Subject string (NUL terminated)

> There is no restriction on the content of this string. Earlier
> versions were limited to 72 characters (including the NUL).

> DEL:After the "Subject" comes a text block, which has a mixture of
> DEL:control information and message text in it.  A NUL character
> DEL:terminates the text block, thus NULs may not be imbedded in the
> DEL:text block.

> COMMENT: This is very bad. A standard should specify, not be
> argumentative. I'd delete it and go on to the control lines.

> 2. Area line (required for echomail)

> AREA:CONFERENCE 

> If the first control line is "AREA:", the message is an echomail
> message (not netmail), in the conference shown. The absebce of the
> AREA: line identifies NETMAIL

> DEL:On receipt of an echomail message, a node will normally export
> DEL:this message to 0 or more destinations, by sending multiple
> DEL:"netmail" messages to these destinations, with the same
"AREA"
> DEL:information.
> COMMENT: I don't know what any of that means.

> 3.  Optional control lines (using ^a)  

> Optional control information is sent as single lines of text,
> preceded by the ctrl-a (0x01) character. Control lines have
> the following format: 

> ^aKEYWORD data
> COMMENT: the colon was deleted to avoid the exceptions.

> Where:

> ^a          x'01' sent as the first character in the line.      
> KEYWORD     as defined in this document, or others.
> data        a keyword-dependent text string, which may be nothing.
>             The data should contain a leading space.
>    can be either  or .

The following control lines have meanings as follows:

^aINTL  

> INTL is used to send inter-zone messages, although it may also be
> used in intra-zone messages, although it is not required to be
> present.


^aFMPT 

> FMPT is used to specify the point number of the originating node. 
> It is only to be used for messages that are from points.


^aTOPT 

> This control line is used to specify the point number of the
> originating node.


^aMSGID:  

The MSGID is an optional control line which is used to uniquely
define a message.  The  field is the originating address
of the sender, not necessarly an address in the current network.
The  is a sequence of exactly 8 hex digits.  A node that
generates MSGID's guarantees that no two messages leaving his
node will contain a  that is the same as the  on
another message that was sent from this node in the last 3 years.


^aREPLY:  

The REPLY is an optional control line which is used to uniquely
define which message is being replied to.  The  and
 are both copied from the original message's MSGID
control line.

> 4. User text
> COMMENT: Both size and allowed content should be defined.

> 5. Optional control lines (using ^a)

> 6. Tear line (required)
  
---  
This control line, known as the "tear line" appears in echomail messages.
 is normally the name of the program which wrote the echomail
control lines.  A tearline may be empty, in which case it is just
"---". It is required by echomail.
> DEL:It is unknown whether this line is required in echomail or
> DEL:not.  It is suggested that new programs always generate a
> DEL:tearline, but accept a message with or without one.  This
> DEL:control line is an exception in that it does not start with a
> DEL:ctrl-A.


> 7. Origin Line (required)

! Origin:  ()
 
This control line, known as the "origin line" appears in echomail messages.
The address should be the address of the originating system in the 
current network.  It should be a 4D address, although new programs 
should accept 2D and 3D addresses also.  This control line is required 
for all echomail messages. 

> DEL:, although it is suggested that new programs allow a message to
> DEL:be processed that doesn't have one, or doesn't have an address
> DEL:in it.

> COMMENT: Standards do not suggest, they dictate.

> 8. Seen-by Line (required)

o SEEN-BY: 

The SEEN-BY control lines are used in echomail to tell which systems within 
> the current zone, this particular message has been sent to. An
inter-zone message may have the SEEN-BYs stripped before crossing the
boundary, except for both it's own address and the recipient's
address.  The inter-zone recipient may then strip all SEEN-BYs except
for it's own address, in case the sender failed to do so, plus this
way it picks up the one extra address.  The SEEN-BYs should be sorted
in numerical order.  The SEEN-BYs should always start off with
a net/node pair, although new programs should accept data starting
with a node, so long as it is not the very first line.  An example
set of SEEN-BY lines would be:

o SEEN-BY: 711/444 555 666 712/111
o SEEN-BY: 712/222 333

The SEEN-BY line from the first S to the last number before the newline,
inclusive, should not exceed 69 characters in length when generating
them (at least for new applications), but new implementations should 
accept at least 79 characters for this, although it is suggested that 
the SEEN-BY block be treated as a single buffer avoiding any line length 
limitations.  The SEEN-BYs must be in a single block.  Applications must 
be able to handle a minimum of 450 addresses in total.

> 9. Optional control lines (using ^a)

^aPATH:                                

The PATH lines are used in echomail to tell which net/nodes a message
travelled through to arrive at your node.  The addresses are in the
same format as the SEEN-BY.  However, the addresses are not stripped
at a zone boundary.  The length of the PATH line, follows the same
> rules as the SEEN-BY.

10. The message is terminated by a NUL.


Regards,
Bob
___ Blue Wave/QWK v2.12

@EOT:

---