на главнуюВсе эхи RU.FTRACK
войти ?

Rntrack 2.1.2

От Michael Dukelsky (2:5020/1042) к Alexey Fayans

В ответ на Заголовок предыдущего сообщения в треде (Имя Автора)


Привет, Alexey!

02 May 2020 16:24, Alexey Fayans послал(а) письмо к Michael Dukelsky:

AF>>> Я не возражаю против обнуления флагов при упаковке, когда
AF>>> упаковываются мои письма. Транзитные должны идти так, как их
AF>>> отправили.
MD>> Не нашёл, где в FTS-0001 написано, что транзитных писем это не
MD>> касается.
AF> А где касается, нашёл? :)

Да, конечно. Все 16 битовых флагов там поделены на 2 группы: отмеченные знаком '+' не должны обнуляться перед паковкой письма в пакет; соответственно, остальные могут быть обнулены, причем по поводу локальных и транзитных писем ничего не написано, значит это относится и к тем, и к другим.

Давай посмотрим на эти две группы флагов по существу. Флаги, которые не надо обнулять, очевидно, нужны для передачи информации о характеристиках письма принимающему узлу. Напротив, флаги, которые можно обнулять, можно обнулять именно потому, что это локальные флаги, нужные для передачи информации о письме между разными программами внутри одного узла (и/или между запусками одной и той же программы). Поэтому сохранение таких флагов в письме, передаваемом другому узлу, не нужно. И это не только не нужно, но и вредно, потому что если принимающий узел не обнулит эти флаги у себя на входе, решения, принимаемые на основе состояния флага, который должен был быть локальным, а на самом деле был подсунут неким "экспериментатором", может быть ошибочным.

AF> Транзитные письма не надо трогать, задача
AF> транзитного узла - переслать всё как есть. Если отправитель не убрал
AF> какие-то флаги - это его проблема. Может быть он что-то тестит и ему
AF> нужно, чтобы письмо было отправлено именно с этими флагами.

Экспериментировать нужно у себя на узле, не мешая работе других узлов. Передача своих локальных флагов другим узлам - это манипуляция работой других узлов. Такое не нужно поощрять, сохраняя локальные флаги в транзитных письмах.

MD>>>>>> Например, сисоп поставил на письме флаг Lok
AF>>> И что будет если мне от какого-нибудь линка придёт сообщение с
AF>>> таким флагом? И что если оно транзитное?
MD>> Ты не должен отправлять такое письмо. См. FSC-0053.

AF> Не дожен отправлять и должен не отправлять - разные вещи. Сообщения,
AF> созданные в моей системе, этому правилу следуют, транзитные - нет.

AF> Этот документ носит исключительно рекомендательный характер. Там это
AF> явно написано:

AF> === Start of Windows Clipboard ===
AF> There is no need to support all or any of the below mentioned
AF> flags.
AF> === End of Windows Clipboard ===

Ну да. А стандарты интернета называются RFC - Request For Comments, то есть это и не стандарт вовсе, а просто кто-то чё-то написал и попросил прокомментировать, как классно у него получилось написать.

AF>>> Сформулируй, пожалуйста, что конкретно RNtrack не будет делать.
MD>> В соответствии с FSC-0053: Prevent message from being processed.
MD>> This includes sending, deleting, purging, and editing.

AF> Я всё ещё утверждаю, что любая работа с флагами - это editing. То есть
AF> получается, я могу убрать флаг Lok, но не могу убрать или поставить
AF> другой флаг?

Алексей, тебе нравится придираться к формулировкам?

Желаю успехов, Alexey!
За сим откланиваюсь, Michael.

... node (at) f1042 (dot) ru

--- GoldED+/LNX 1.1.5-b20170303
* Origin: ==<<.f1042.ru.>>== (2:5020/1042)

Ответы на это письмо:

From: Username
Заголовок следующего сообщения в треде может быть длинным и его придется перенести на новую строку

From: Username
Или коротким

FGHI-url этого письма: area://RU.FTRACK?msgid=2:5020/1042+5eaedb6e