Hello mark!

11 Jan 20, mark lewis wrote to Zhenja Kaliuta:

 ZK>> - is it ok to handle the situation without failing the pkt?
 ZK>> - is it ok to make the pkt standard complied?

 ml> in my personal and professional opinion, the answer to both questions
 ml> is a resounding "yes" but with at least the following caveat...

Sorry, i didn't noticed your next mail where you highly agreed with me before
writing. Please ignore this mail. I send it because i added some details of the
consequences how works arounds can block each other.

 ml>   1. HPT is the first FTN processor to handle the defective pkt
 ml>      after the flawed (gating?) software has created it...

The first FTN processor is the flawed software that generates non FTS pkts.
No matter what that software normally does - it has a module that exports FTN
pkt and that job should be done in accordance to FTS.

 ml> once the defective pkts are already in the distribution stream,
 ml> meaning another FTN tosser has processed it, then no... mark them as
 ml> bad and set them aside with a proper logged reason...

The result is that only direct link systems are flooded with broken content.
That could be a nice idea, but because of the actual practice for network
stability improvement called multi-link routing, there are many "first HPT
tosser" that would receive the broken pkt.

This is a good example that work arounds do interfere with other work arounds.
Your idea would work for a straight star network but not for a mesh type
network.

 ml> or some such... possibly also record the identity of the processor
 ml> that created the defective packet if that's not already being done...
 ml> one might also want to log the above when the processor repairs such
 ml> a defective message and log an additional message stating the repair
 ml> decision... logging bad pkts is generally already done and adding
 ml> logging that the repair of message #xxx is being done is trivial...

 ml> others may or may not feel the same way...

Instead of all other network members waste their resources for logging, fixing
and accepting broken subjects within the network only one system needs to find
a better solution how to transfer too long subject lines into the standard pkt
format. A short and simple way is to copy the full subject line into the
message text and cut the subject short plus adding a timestamp. The timestamp
is required if the subject line is edited in the too long part only. This
change must be visible in the short line somehow to keep reply linking
searching and sorting by subject line working as usual.

 ml> i fully agree that this is a technical problem which is allowed for
 ml> by current fidonet policy

I don't think so. I'm not in details but it doesn't make sense. The FTS are the
standard valid for any FTS based networks to keep the networks running without
problems. The FTS sets the frame. If the subject line is limited any FTN
software have to be compliance to that limit - or it is not a FTS software.

The purpose of the "other technical problems" in the policy can't be used to
transform the network into a trashcan and leave the responsibility to find
useful stuff in the trash to us.

The problem of non FTS conform subject lines is a problem out of the FTN/FTS
responsibility because it's not a valid FTS pkt. Period. The decision of HPT to
move that non standard content to bad is correct. The decision not to modifiy
and not to route the broken content is the only way to tell the source of the
problem that his software has a serious bug that needs to be fixed.

 ml> basically mean a setting per FTN... possibly something like
 ml>   Repair defective pkts: yes/no

That would make it more complex. Keep it simple. It's not your/our job to fix
incoming trash. HPT should detect a broken pkt, log it and move it to bad.
That's how the broken pkt was found so hpt already works as designed.

Regards

Kai

--- GoldED+/LNX 1.1.4.7