Subj : hpt long subjects and bad packets To : mark lewis From : Kai Richter Date : Mon Jan 13 2020 11:56:16 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 * Origin: Monobox (2:240/77) .