= Сообщение: 182 из 15065 ======================================== R50.SYSOP =
От : Oleg Pevzner 2:464/5555 10 Aug 13 09:19:55
Кому : Pavel Gulchouck 10 Aug 13 09:19:55
Тема : Старые сети
FGHI : area://R50.SYSOP?msgid=2:464/5555+5205fc33
На : area://R50.SYSOP?msgid=2:463/68+52050a33
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://R50.SYSOP?msgid=2:463/68+52062c60
Ответ: area://R50.SYSOP?msgid=2:5005/77+5206ca3a
==============================================================================
Hello Pavel!
Friday August 09 2013 17:51, you wrote to me:
PG> С одной стороны, требовать от хоста поддержку PSTN странно.
PG> С другой - если это old-fashion node, у которой есть только PSTN и
PG> никакого IP - как она сможет участвовать в жизни фидо, и связь её с
PG> остальными участниками - это чья проблема?
Вопрос связности сети всегда был краеугольным камнем для фидошки. Я думаю, следует все же разграничить возможные проблемы связности, возникающие по причине лености и нерасторопности сисопа и действительные проблемы, могущие возникнуть по различным технико-технологическим причинам. Скажем, кто балда сисопу, поленившемуся поднять на своем узле один из предусмотренных протоколов, поддерживаемый хабом или хостом? А вот требование обязательного наличия качественно работающего телефона, позволяющего реально вести обмен, а также телефонного модема старого образца, который сегодня элементарно может быть просто некуда воткнуть в современную материнку - вот такое _обязательное_ требование, пожалуй, излишне. Гораздо больше вопросов у меня в плане требований не к рядовому сисопу, а к хабу и хосту - что они _обязаны_, а что _могут_ поддерживать или не могут? Особенно актуально этот вопрос звучит в контексте соображений, когда говорим о том, что будем пытаться сохранять одноузловые сети, а значит, такой узел должен быть сам себе и хостом, и хабом (или кто-то другой для него, но тогда - кто?). И что делать, если сисоп такого узла никогда не пытался и не старался брать на себя подобные сетевые функции. Я думаю, что это - как раз тот случай, о котором говорил ранее - подход должен быть сугубо индивидуальным, но у *C должен быть целый арсенал возможных легитимных предложений на выбор такому узлу. От классического перехода под регион до помощи и совместного поднятия необходимых протоколов и софта.
PG> В нынешнем полиси написано (1.2.1):
PG> "The sysop must mesh with the rest of the FidoNet system to send and
PG> receive mail" Иными словами, это всё-таки обязанность и проблема
PG> сисопа. Хост должен знать, как доставить почту любому узлу своей сети.
PG> Кому-то по binkp, кому-то через хаба, который поддерживает, скажем,
PG> ifcico, кому-то ещё как-то. А если такого пути нет (например, был хаб
PG> с поддержкой IP+PSTN, у которого в подхабнике были PSTN-only nodes, и
PG> этот хаб ушёл в даун) - увы, но в такой ситуации этим узлам нужно либо
PG> поднимать IP, либо искать другого хаба, либо тоже уходить в даун.
Пожалуй, должно пойти...
PG> Так что насчёт связности - думаю, можно требования смягчить, и
PG> оставить два условия: 1. Хост должен поддерживать на вход CM binkp и
PG> обрабатывать unsecure netmail для узлов своей сети. 2. Сисоп узла
PG> должен позаботиться о том, чтобы почта от хоста к нему доходила, чтобы
PG> хост знал, как ему доставлять почту.
Да, именно сисоп должен об этом позаботиться - это прямая обязанность сисопа. У меня вопрос по хосту. Думаю, следует четко перечислить протоколы, которые хост обязан поддерживать для того, чтобы иметь право так называться. Вот, например, ifcico должен или нет? А тот же PSTN? Hу и т.п. Я думаю, здесь важно, чтобы это прозвучало четко, внятно, без возможности домысливания и всевозможных манипулирований.
PG> Требование обработки unsecure netmail хостом может быть изменено в
PG> случае стандартизации аутентификации узлов по ключу из нодлиста или по
PG> keychains с корнем у IC. Слово "binkp" хорошо бы заменить на что-то
PG> менее конкретное, вроде "единый протокол, принятый FTSC и утверждённый
PG> IC", но не могу придумать формулировку, которая бы мне самому
PG> нравилась.
А чем тебе такая формулировка не нравится?
PG> Как ещё один вариант: сделать доставку почты по цепочке
PG> ZC->RC->Host->Node обязательной, и не специфицировать общий протокол
PG> вообще. Сисоп должен договориться об общем протоколе с хостом, хост -
PG> с RC, RC - с ZC. Сейчас стоимость междугородной доставки почты уже
PG> неактуальна, поэтому в таком роутинге нет ничего плохого (по нынешнему
PG> полиси RC не обязан доставлять почту на свой регион, а ZC - на свою
PG> зону, потому что по телефону это слишком дорого). В этом случае
PG> связность всей сети сохранится, а общий для всех протокол и директная
PG> доставка необязательны.
Я не думаю, что введение хоть малейшей обязаловки пойдет на пользу фидошке. Сам знаешь, нечасто, но возникают случаи, когда именно нестандартные пути и способы доставки почты оказываются решающими и очень нужными. Я считаю, что чем больше разрешенных официально, допустимых средств коммуникации предусмотрено, тем лучше.
OP>> Hе совсем понял, что ты имеешь в виду, когда пишешь о
OP>> возможном упразднении цифровой адресации. Если можно, этот пункт
OP>> поясни получше, пожалуйста.
PG> Это я привёл, скорее, чтобы показать, что менять общее фидошное полиси
PG> сейчас не нужно, иначе можно далеко зайти, а смысл этого не очень
PG> понятен. Его можно лишь чуть подправить, чтобы на него по-прежнему
PG> можно было опираться, но это можно решить и локальным уставом.
Ясно. Hу, в этом плане мы с тобой точно мыслим одинаково... :)
WBR, Oleg Saturday August 10 2013
E-Mail: omp<no-spam>omp.dp.ua
--- XStation
* Origin: (2:464/5555)
|
