Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции ENET.SYSOP
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции ENET.SYSOP с датами от 10 Jul 13 21:42:12 до 03 May 24 12:02:39, всего сообщений: 12492
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 10340 из 12492 ===================================== ENET.SYSOP =
От   : Alexey Vissarionov               2:5020/545         15 Feb 21 04:40:04
Кому : Michiel van der Vlist                               15 Feb 21 04:40:04
Тема : Ping
FGHI : area://ENET.SYSOP?msgid=2:5020/545+6029d240
На   : area://ENET.SYSOP?msgid=2:280/5555+6029b25e
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://ENET.SYSOP?msgid=2:280/5555+602a5b69
==============================================================================
Good ${greeting_time}, Michiel!

15 Feb 2021 00:16:38, 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?
MvdV> I don't know who the author of PoC is and so I do not know his|her
MvdV> reasons. Nor do I know if these reasons are good or bad...

You can find that in FTSC archives... (TLDR: me).

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
MvdV> Semantics.

Reply is a new message with its own technical fields.

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.
MvdV> What "further processing" is there to be done on a reply from a
MvdV> PING robot? It is meant to be read by a human and that is it.

Mail routing.

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!"
MvdV> 1) What "other software"? PING replys are meant to be read by a
MvdV> human.

Or some other robot. You never know...

MvdV> 2) FSCs are proposals that for one reason or another never made it
MvdV> into a standard. So they are not binding or authoritive in any way.
MvdV> 3) FSC-0032 is about echomail, PING is about netmail.
MvdV> I still see no clear technical reason why PING robots should
MvdV> invalidate tear lines or origin lines.

Because they don't belong to a message sent back by a robot. It can either invalidate or delete them, but leaving them as they come in the request is a very unwise idea.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8 @ hkp://keys.gnupg.net
--- /bin/vi
* Origin: ::1 (2:5020/545)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.076133 секунды