980927
Address Information Fields and Actual Address contruction

The document describes the fields present when reading a message from
one of the source formats: PKT, JAM base, Squish base or *.MSG file.
These fields contain redundant information and might sometimes be
conflicting as well. We must use these fields to contruct the actualy
sender and destination addresses and decide which fields have the
highest "trueness".

The first section describes each of the formats and the fields
available and gives them names. The second section describes the logic
to be used to construct the actual addresses.

I might decide to publish this document in the future as a base for
every FTN programmer "to get things right".


The current situation
=====================

Operations
----------

Address are constructed using the fields below and a number of
operations, for example a complete replacement with the new address.
When this occurs, the domain is probably reset to empty and address
parts not present in the new source are set to 0. For example,
assignment with a 3D address causes the point part to be set to 0.

a "Merge" can follow as well. In that case parts are taken from the
new address when they are "0" in the current part. To avoid doing
a complete "OR" with the new address, the node part is only replaced
when "0" *and* the net part was replaced as well. The net part in
turn is only replace when "0" *and* the zone part was replace. The
zone part is only replaced when currently "0". The word "Merge" will
be used in the text below to indicate this operation.


PKT file
--------

A PKT file consists of a header, followed by headers for each of the
messages. The PKT header contain 2D or 4D address info based on the
PKT type. These fields are required during security checks. The MSG
header contains 2D address fields and the body of the message can
contain kludges also containing address information.

Domain information is not present in a PKT file and neither
taken from system akas, which is an error.

PKT.OrigNode
PKT.DestNode
PKT.OrigNet
PKT.DestNet
PKT.QmOrigZone
PKT.QmDestZone
PKT.OrigZone
PKT.DestZone
PKT.OrigPoint
PKT.DestPoint
PKT.F48AuxNet
PKT.Msg.OrigNode
PKT.Msg.DestNode
PKT.Msg.OrigNet
PKT.Msg.DestNet
PKT.Msg.Intl.Dest3D
PKT.Msg.Intl.Orig3D
PKT.Msg.FmPt
PKT.Msg.ToPt
PKT.Msg.Origin4D

Address construction for the PKT security check:

PKT.Source5D:
Basically PKT.OrigZone:PKT.OrigNet/PKT.OrigNode.PKT.OrigPoint
If PKT.OrigZone is 0 then PKT.QmOrigZone is used.
If PKT.OrigNet is -1 and the header contains a valid F48 signature
then PKT.F48AuxNet is used instead.
The source is Merged with fields from our closest matching system AKA.

PKT.Destination5D:
Basically PKT.DestZone:PKT.DestNet/PKT.DestNode.PKT.DestPoint
IF PKT.DestZone is 0 then PKT.QmDestZone is used.
The destination is not used at this moment - WaterGate just processes
all PKT files it finds.

Address construction for each message in the PKT file:

PKT.Msg.Source5D:
"0":PKT.Msg.OrigNet/PKT.Msg.OrigNode."0" is used as a basis.
When found, the entire address can be replaced with
PKT.Msg.Origin4D.
A Merge can follow with the PKT.Msg.Intl.Orig3D.
When present, the point part is replaced with PKT.Msg.FmPt
The zone can still be replaced, see below.

PKT.Msg.Destination5D:
"0":PKT.Msg.DestNet/PKT.Msg.DestNode."0" is used as a basis.
A Merge can follow with the PKT.Msg.Intl.Dest3D.
When present, the point part is replaced with PKT.Msg.ToPt.
If after reading the entire body the zone still equals "0", the
PKT.Source.Zone is used (see above). If that one was "0" as well,
then the PKT.Msg.Source.Zone is used. If that one was "0" as well,
then both the PKT.Msg.Source.Zone and PKT.MSG.Dest.Zone are set
to PKT.Source.Zone - which I now understand is useless since it
will never trigger.


PKT2000 file
------------

A PKT2000 format (P2K) file consists of P2K file header with the
source / destination addresses. Each message then consists of a binary
header with address information. The body can contain an Origin line.

P2K.OrigAddr5D
P2K.DestAddr5D
P2K.Msg.OrigAddr4D
P2K.Msg.DestAddr4D
P2K.Msg.WrittenAddr4D

Address construction for the P2K security check:

!not implemented yet! P2K.OrigAddr5D and P2K.DestAddr5D should be used.

Address construction for each message in the P2K file:

!not implemented yet! P2K.Msg.OrigAddr4D and P2K.Msg.DestAddr4D should
be used, in combination with the domains from the P2K header 5D
addresses.


JAM base
--------

A JAM base contain a header file with binary headers, one for each
message - but without address information. It is followed by sub-fields
containing address information and text kludges. The body text (in
another file) can contain an Origin line. The binary fields contain
textual representation, so anything from a 2D to a 5D address can be
present.

INTL, FMPT and TOPT kludges are not supposed to be present in a JAM
base. If found anyway (created by an erroneous program), this is not
handled properly and both duplicate kludges will occur and address
information might be replaced as described under PKT.

JAM.OrigAddr (2D-5D)
JAM.DestAddr (2D-5D)
JAM.Origin4D (optional, echomail only)

Address construction on export:

JAM.Source5D:
The JAM.OrigAddr field is used as a basis.
When present, the entire address can be replaced with JAM.Origin4D.

JAM.Destination5D:
The JAM.DestAddr field is used.

If incomplete (2D) information was present only, this is not completed
and it is unspecified how the rest of the code will react to this.


Squish base
-----------

A Squish base consists of a message base header without address info.
The main file contains frames with a frame header without address
info and a message header with 4D source and destination address info.
The body text can contain several kludges with address info.

INTL, FMPT and TOPT kludges are not supposed to be present in a Squish
base. If found anyway (created by an erroneous program), this is not
handled properly and both duplicate kludges will occur and address
information might be replaced as described under PKT.

Squish.Orig4D
Squish.Dest4D
Squish.Origin4D (optional, echomail only)

Address construction on export:

Squish.Source5D:
The Squish.Orig4D field is used as a basis.
If Squish.Origin4D is present, this replaces the entire address.

Squish.Destination5D:
The Squish.Dest4D field is used as a basis.

If incomplete (2D) information was present only, this is not completed
and it is unspecified how the rest of the code will react to this.


*.MSG file
----------

A *.MSG file consists of a binary header containing 4D or 2D (Opus
format) address info. The body can contain several kludges.

MSG.OrigNode
MSG.DestNode
MSG.OrigNet
MSG.DestNet
MSG.OrigZone (not for Opus format)
MSG.DestZone (not for Opus format)
MSG.OrigPoint (not for Opus format)
MSG.DestPoint (not for Opus format)
MSG.Intl.Orig3D
MSG.Intl.Dest3D
MSG.FmPt
MSG.ToPt

AreaDef.Origin5D (points to one of the system akas)
Config.SystemAka1

Address construction on export:

MSG.Source5D:
The basis is "0":MSG.OrigNet/MSG.OrigNode."0" for Opus format and
MSG.OrigZone:MSG.OrigNet/MSG.OrigNode.MSG.OrigPoint for normal format.
When found, the entire address can be replaced with MSG.Origin.Orig4D.
A Merge can follow with the MSG.Intl.Orig3D.
When present, the point part is replaced with PKT.Msg.FmPt
If, after reading the entire body and processing all the kludges, the
zone still equals "0", then a Merge is performed with the
AreaDef.Origin5D address for echomail and Config.SystemAka1 (first
system aka) for netmail.

MSG.Destination5D:
The basis is "0":MSG.DestNet/MSG.DestNode."0" for Opus format and
MSG.DestZone:MSG.DestNet/MSG.DestNode.MSG.DestPoint for normal format.
A Merge can follow with the MSG.Intl.Dest3D.
When present, the point part is replaced with MSG.ToPt.
If, after reading the entire body and process all the kludges, the
zone still equals "0" then it is replaced with the MSG.Source5D.Zone.


The 'should be' situation
=========================

This is the second section, describing how the addresses should be
constructed for each of the cases above.

First of all, the priority should be defined: which fields are most
certain to contain the correct information. Seconds, in case of
conflicts, which field should be trusted best.

The first change I want to make is storing all the information in all
the fields and putting a single position in the code that makes the
decision on which fields should be used. A set of flags will indicate
which fields were filled in.

An interesting note is the zone part for echomail messages. The most
reliable source is probably what *.MSG tries to use: the Origin AKA
selection in the Area Definition.

For each source we must try to construct a complete 5D address.

TBD - To Be Defined

<end of file>
