Re: Re: hpt long subjects and bad packets
By: Zhenja Kaliuta to Mark lewis on Sat Jan 11 2020 09:49:17
ZK> - is it ok to handle the situation without failing the pkt?
ZK> - is it ok to make the pkt standard complied?
in my personal and professional opinion, the answer to both questions is a
resounding "yes" but with at least the following caveat...
1. HPT is the first FTN processor to handle the defective pkt
after the flawed (gating?) software has created it...
once the defective pkts are already in the distribution stream, meaning another
FTN tosser has processed it, then no... mark them as bad and set them aside
with a proper logged reason...
eg: foobar.pkt - packed msg #XXX - subject field too long
or some such... possibly also record the identity of the processor that created
the defective packet if that's not already being done... that info can be
gathered from the packet header... one might also want to log the above when
the processor repairs such a defective message and log an additional message
stating the repair decision... logging bad pkts is generally already done and
adding logging that the repair of message #xxx is being done is trivial...
others may or may not feel the same way...
i fully agree that this is a technical problem which is allowed for by current
fidonet policy but also keep the above caveat in mind... other FTNs may have
different policy, though, and that should also be considered... it may lead to
the "repairing tosser" to perform this fix or sidelining based on the FTN the
packets belong to which would basically mean a setting per FTN... possibly
something like
FTN zone(s): 1-4095
FTN domain: xxxxxxxx
Repair defective pkts: yes/no
in the configuration settings... i'm thinking of this in this manner because if
the pkt is only 3D/4D, then the domain info is not available and the decision
would be made based on the zone number... if the pkt is 5D, then the domain
info is available and the decision would be made on that... YMMV is applicable
here, though...
)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)
|