TIP: Click on subject to list as thread! ANSI
echo: fidosoft.husky
to: ZHENJA KALIUTA
from: MARK LEWIS
date: 2020-01-11 07:33:00
subject: Re: hpt long subjects and

  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)

SOURCE: echomail via QWK@docsplace.org

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.