Subj : Re: hpt long subjects and bad packets
To   : Zhenja Kaliuta
From : mark lewis
Date : Sat Jan 11 2020 07:28:05

  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)

.