Document: FSC-0052
Version: 001
Date: 23-Sep-90
ZPTH
----
A proposal for making the PATH zone aware
Gerard van der Land
FidoNet 2:283/1.5
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r) community,
and requests discussion and suggestions for improvements.
Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
The PATH line can be a more accurate source of information than
the SEEN-BY line to determine if a message is a duplicate. TosScan
with Circular PATH Protection (CPP) enabled will consider messages
that already have your address in them as duplicates. This works fine
in conferences that are distributed within one zone, but in
conferences spread across zones it can cause problems.
Unlike SEEN-BY lines, PATH lines are not stripped at the zone
gate, because they have a very important purpose: to be able to
determine the used echomail topology and troubleshooting, like finding
the cause of duplicate messages. Unfortunately this also means that if
a message is entered at 1:283/1 and my boss would be running TosScan
with CPP enabled, the message would be considered as a duplicate,
because "283/1" is already in the PATH lines.
If such messages are not deleted but stored in a duplicate
directory, you will of course notice this happen and disable CPP, but
you can't know if messages never reach your system because they were
deleted for the same reason by another node that had CPP enabled.
That's why I have the following proposal. If a message travels
from one zone to another, the zone gateway should move all information
in the current PATH lines to kludge lines with the following format:
^aZPTH: <origin zone>:<old path info>
The receiving system in the destination zone creates a new PATH
with his address in it.
There is no need to support or allow 4D addresses in the ZPTH,
since it is only supplements the existing PATH lines.
Simple sample
-------------
A message originating at 1:154/40 arrives at 1:260/340...
^aPATH: 154/40 970 9 157/200 265/7 13/13 260/340
...and is sent to Europe. This is how I would see it:
^aZPTH: 1:154/40 970 9 157/200 265/7 13/13 260/340
^aPATH: 310/11 507/1 512/0 280/0 283/1
Now suppose that 283/1 would gate it to zone 3, it would look
like this when it gets there:
^aZPTH: 1:154/40 970 9 157/200 265/7 13/13 260/340
^aZPTH: 2:310/11 507/1 512/0 280/0 283/1
The receiving node in zone 3 now creates a new PATH line with
his address in it.
Advantages
----------
1) It enables Circular PATH Protection (CPP) on conferences that
travel across zones without the risk of messages that are
erroneous considered as duplicates and deleted.
2) A zone gate can optionally parse the ZPTH lines to see if his
zone or the destination zone has already seen the message (CZP,
Circular ZPATH Protection), which means a duplicate message will
never go to another zone. Ofcourse this could only be used if it
sure that messages shouldn't re-enter a zone.
3) You get a much better view on the used echomail topology,
sometimes it is very hard to see where a message goes from one
zone to another.
4) It will not screw up with any echomail processor as long as they
ignore unknown kludges. Only nodes gating echomail from one zone
to another would need to have a processor that supports the ZPTH
kludge.
5) It will hardly increase the size of compressed mail archives.
