On Sunday February 14 2021 22:00, you wrote to me:
MvdV>> 1) I am not a lemming, I do not just follow for the sake of MvdV>> following. Not even the "two steps before becoming the MvdV>> reference implementation".
AV> The author of PoC had some really good reasons to do that, n'est pas?
I don't know who the author of PoC is and so I do not know his|her reasons. Nor do I know if these reasons are good or bad...
MvdV>> 2) It violates my principle of "pass 'as is', unless there is a MvdV>> clear technical reason for not doing so".
AV> Reply != pass
Semantics.
MvdV>> So far I have seen no clear technical reason for invalidating MvdV>> tear lines and origin lines in a PING respons. Origin lines do MvdV>> not belong in netmail anyway, so that would be a case of GiGo. MvdV>> So.. can you give me a clear technical reason? "PoC does it", MvdV>> is not a valid clear technical reason.
AV> The robot does pass all original messages "as is". But when it AV> generates _new_ _message_ with the reply, it _must_ (as in FTA-1006) AV> make sure nothing would affect further processing of that message.
What "further processing" is there to be done on a reply from a PING robot? It is meant to be read by a human and that is it.
AV> Quoting the original message back (as in FSC-0032) could be a good AV> solution. However, the FSC-0032 explicitly states: "Kludge lines, AV> including tear lines and origins lines are not normally quoted, but AV> when they are - they must never be quoted exactly - this definitely AV> causes problems with other software!"
1) What "other software"? PING replys are meant to be read by a human. 2) FSCs are proposals that for one reason or another never made it into a standard. So they are not binding or authoritive in any way. 3) FSC-0032 is about echomail, PING is about netmail.
I still see no clear technical reason why PING robots should invalidate tear lines or origin lines.
