1 Обзор
1.0 Язык
1.1 Введение
1.2 Организация
1.2.1 Индивидуальные системы и системные операторы (SysOp'ы)
1.2.1.1 Пользователи
1.2.1.2 Point'ы
1.2.2
1.2.3 Сети и Координаторы Сети
1.2.3.1 Почтовые буферы сети (Network Routing Hubs).
1.2.4 Регионы и Региональные Координаторы
1.2.5 Зоны и Координаторы Зоны
1.2.6 Совет Координаторов Зон
1.2.7 Международный Координатор (International Coordinator).
1.2.8 Подчинение сверху вниз. Контроль и равновесие.
1.3 Определения
1.3.1 FidoNews
1.3.2 География
1.3.3 Zone Mail Hour ("Почтовый" Час Зоны)
1.3.4 NodeList
1.3.5 Чрезмерно некорректное поведение
1.3.6 Коммерческое использование
2 Процедуры SysOp'а
2.1 Общие
2.1.1 Основные
2.1.2 Ознакомление с Уставом
2.1.3 Ответственность за трафик, входящий в FidoNet через узел
2.1.4 Кодирование и просмотр корреспонденции
2.1.5 Внесение изменений в пересылаемую корреспонденцию
2.1.6 Частная Netmail
2.1.6.1 Раскрытие проходящей корреспонденции
2.1.6.2 Частная корреспонденция, адресованная вам
2.1.7 Пересылка корреспонденции
2.1.8 Исключительность Zone Mail Hour
2.1.9 Частные узлы
2.1.10 Соблюдение "почтовых" процедур
2.1.11 Использование текущего NodeList'a
2.1.12 Экскоммуникация
2.1.13 Время Zone Mail Hour
2.1.14 Несоблюдение летнего времени
2.2 Как получить узловой номер (Node Number)
2.3 Если вы временно покидаете сеть
2.4 Как создать сеть
3 Общие процедуры для всех координаторов
3.1 Распространение файлов различий и FidoNews
3.2 Обработка изменений NodeList'a и передача их наверх
3.3 Распространение последней версии устава
3.4 Сведение к минимуму числа занимаемых должностей
3.5 Членство в управляемой структуре
3.6 Поощрение вступления в FidoNet новых SysOp'ов
3.7 Традиция и прецеденты
3.8 Техническое управление
4 Процедуры Координатора Сети
4.1 Обязанности
4.2 Пересылка неограниченного объема корреспонденции
4.3 Присвоение узловых номеров
4.4 Ведение NodeList'a
4.5 Распространение Уставов, NodeList'ов и FidoNews
5 Процедуры Регионального Координатора
5.1 Обязанности
5.2 Присваивание узловых номеров
5.3 Поощрение создания и роста сетей
5.4 Присвоение сетевых номеров
5.5 Ведение NodeList'a
5.6 Географические освобождения
5.7 Надзор за работой сетей
5.8 Распространение Уставов, NodeList'ов и FidoNews
6 Процедуры Координатора Зоны
6.1 Общие
6.2 Выборы
7 Процедуры Международного Координатора
7.1 Общие
7.2 Выборы
8 Референдумы
8.1 Проведение референдума
8.2 Объявление и результаты
8.3 Право голоса
8.4 Механизм голосования
8.5 Голосование по Уставу в целом
8.6 Принятие решения
8.7 Вотум недоверия Координатору Зоны
8.7.1 Проведение
8.7.2 Процедура, аналогичная референдуму по уставу
8.7.3 Механизм голосования
8.7.4 Ограничение проведения вотума одним в год
9 Урегулирование конфликтов
9.1 Общие процедуры
9.2 Проблемы с другим SysOp'ом
9.3 Проблемы с вашим Координатором Сети
9.4 Проблемы с другими координаторами
9.5 Процесс аппеляции
9.6 Ограничения срока рассмотрения жалобы
9.7 Право на быстрое решение
9.8 Возврат в первоначальную сеть
9.9 Эхо-почта
9.10 Прецедент
10 Приложения
10.1 Общее
10.2 Время "почтового" часа зоны
10.3 Прецендент
10.3.1 Случай провинившегося узла
10.3.2 Случай с Hacker Mailer
10.3.3 Случай беспокойного крикуна
10.3.4 Случай очень занятого узла
10.3.5 Метка дьявола
10.3.6 Случай SysOp'a - идиота
10.3.7 Случай пристрастия к Echomail
10.3.8 Случай непостоянной работы "почтового ящика"
10.4
10.5 Официальные заявления и т.п.
1. Обзор
Этот документ устанавливает политику для SysOp'ов, являющихся
членами организации электронных "почтовых ящиков" (BBS)
FidoNet. Сеть FidoNet определяется NodeList (списком узлов),
издаваемых еженедельно Международным Координатором
(International Coordinator).
Собственные уставы могут издаваться на уровне зоны, региона
или сети, более подробно освещая локальные процедуры. Обычно,
эти уставы более низкого уровня не могут противоречить этому
документу. Однако, с согласия Международного Координатора, ло-
кальный программный документ может отражать отличия, которые
необходимы ввиду местных условий. Эти локальные уставы не мо-
гут налагать дополнительных ограничений на членов FidoNet,
кроме включенных в этот документ, за исключением усиления ло-
кальных почтовых периодов.
1.0 Язык
Официальный язык FidoNet - английский. Все документы должны
издаваться на английском языке. Поощряется перевод на другие
языки.
1.1 Введение
FidoNet - это любительская система электронной почты. Таким
образом, все ее участники и операторы работают добровольно и
бесплатно. Объединяя вначале нескольких друзей, обменивавшихся
сообщениями (1984), сейчас она включает более 5000 систем на
шести континентах (1989).
FidoNet настолько велика, что может легко распасться от
собственной тяжести, если не будет поддерживаться некой струк-
турой и управлением. Эту структуру обеспечивает многосетевой
принцип деятельности. Управление обеспечивает децентрализован-
ное руководство системой. Этот документ описывает процедуры,
разработанные для управления сетью.
1.2 Организация
Системы FidoNet группируются на нескольких уровнях, а адми-
нистрация соответственно децентрализуется. В этом обзоре при-
веден краткий обзор структуры; обязанности координаторов раз-
ных уровней приводятся далее в этом документе.
1.2.1 Индивидуальные системы и системные операторы (SysOp'ы)
аименьшей структурной единицей FidoNet являются индивидуаль-
ные системы, соответствующие одному пункту NodeList. SysOp
формулирует принципы работы системы и взаимоотношений с поль-
зователями. SysOp должен быть связан с остальной системой
FidoNet для пересылки и приема почты, а локальный устав должен
быть согласован с другими уровнями FidoNet.
1.2.1.1 Пользователи
SysOp'ы ответственны за все действия пользователей, когда они
влияют на остальную часть FidoNet. (Если пользователь не кор-
ректен, SysOp не корректен.) Любой трафик, входящий в FidoNet
через определенный Node (узел), если не исходит от SysOp'а,
считается исходящим от пользователя и таким образом SysOp от-
вечает за него. (См. раздел 2.1.3.)
1.2.1.2 Point'ы
Point - это совместимая с FidoNet система, которая не входит в
NodeList, но связывается с FidoNet через узел, являющийся для
системы BossNode'ом (узлом хозяина). Point в общем рассматри-
вается, как пользователь, например, BossNode несет ответствен-
ности за корреспонденцию от Point'а. (См. раздел 2.1.3.) Point
адресуется с помощью адреса BossNode'а по NodeList'у; напри-
мер, Point-система с BossNode'ом 114/15 может быть известна
как 114/15.12. Корреспонденция, предназначенная для Point'а,
посылается BossNode'у, который затем направляет ее Point'у.
Поддерживая Point'ы, BossNode использует личный сетевой номер,
который не должен быть виден вне связи BossNode-Point. К сожа-
лению, если Point вызывает другую систему напрямую (например,
для файлового запроса), личный сетевой номер появляется как
адрес вызывающего. В этом смысле, Point'ы отличаются от поль-
зователей, т.к. они работают с совместимыми с FidoNet
Mailer'ами, способными связываться с системами, помимо
BossNode'а.
1.2.3 Сети и Координаторы Сети
Сеть (Network) - это объединение узлов локальной географи-
ческой области, обычно определяемое областью с удобной теле-
фонной связью между собой. Сети координируют свою корреспон-
денцию для уменьшения расходов. Координатор Сети (Network
Coordinator) отвечает за ведение списка узлов сети, а также за
пересылку Netmail (сетевой корреспонденции), посылаемой членам
сети от других узлов FidoNet. Координатор Сети может обрабаты-
вать выходящую Netmail, но не обязан это делать.
Координатор Сети назначается Региональным Координатором
(Regional Coordinator).
1.2.3.1 Почтовые буферы сети (Network Routing Hubs).
Маршрутные Разветвители Сети существуют только в некоторых се-
тях. Они могут назначаться Координаторами Сети, чтобы помогать
в управлении большой сетью. Его конкретные обязанности и про-
цедуры устанавливаются по соглашению между Координатором Сети
и Разветвителем, и не обсуждаются в данном документе, кроме
того, что координатор не может делегировать ответственность
при посредничестве в конфликтах.
1.2.4 Регионы и Региональные Координаторы
Регион (Region) - это определенная географическая область,
включающая узлы, которые могут быть объединены либо не объеди-
нены в сети. Типичный регион содержит множество узлов, объеди-
ненных в сети, и несколько независимых узлов, не являющихся
частью какой-либо сети.
Региональный Координатор (Regional Coordinator) ведет список
независимых узлов региона и принимает NodeList'ы от Координа-
торов Сетей региона. Эти списки объединяются в региональный
NodeList, который затем пересылается Координатору Зоны (Zone
Coordinator). Региональный координатор не обслуживает пересыл-
ку сообщений любого узла региона.
Региональные Координаторы назначаются Координатором Зоны.
1.2.5 Зоны и Координаторы Зоны
Зона (Zone) - это большая географическая область, включающая
множество регионов и охватывающая одну или несколько стран
и/или континентов.
Координатор Зоны (Zone Coordinator) объединяет NodeList'ы от
всех регионов зоны, и создает главный NodeList и файл текущих
изменений, которые затем распространяются по FidoNet в зоне.
Координатор Зоны не обслуживает пересылку сообщений любого уз-
ла региона.
Координаторы Зон выбираются Региональными Координаторами этой
зоны.
1.2.6 Совет Координаторов Зон
В некоторых случаях Координаторы Зон работают как совет при
Международном Координаторе. Их отношения аналогичны отношениям
между президентом и его советниками. В частности, этот совет
рассматривает вопросы взаимоотношений между зонами. В эти воп-
росы входит выяснение деталей при выпуске NodeList'a, посред-
ничество в межзональных конфликтах, и другие вопросы, не ре-
шенные на нижних уровнях FidoNet.
1.2.7 Международный Координатор (International Coordinator).
Международный Координатор - это "первый среди равных" Коорди-
натор Зоны, который координирует совместный выпуск Координато-
рами Зон Главного NodeList'а.
Международный Координатор действует как председатель Совета
Координаторов Зон и как председатель избирательной комиссии
при выборах - он объявляет референдум, собирает и подсчитывает
бюллетени и объявляет результат голосования по вопросам,
касающимся FidoNet как единого целого.
Международный координатор избирается Координаторами Зон.
1.2.8 Подчинение сверху вниз. Контроль и равновесие.
Эти уровни действуют, чтобы распределить управление FidoNet на
возможно более низкий уровень, в то же время позволяя осущест-
влять скоординированную деятельность всей системы электронной
"почты". Управление становится возможным в результате подчине-
ния нижних уровней верхним. Это значит, что должностное лицо
на данном уровне ответственно перед уровнем, находящимся над
ним, и отвечает за уровни под ним.
апример, Региональный Координатор отвечает перед Координато-
ром Зоны за все, что происходит в регионе. С точки зрения Ко-
ординатора Зоны, Региональный Координатор полностью отвечает
за бесконфликтную деятельность в регионе. Точно так же, с точ-
ки зрения Регионального Координатора, Координатор Сети пол-
ностью отвечает за бесконфликтную работу в своей сети.
Если должностное лицо на любом уровне выше SysOp'а не способен
хорошо выполнять свои обязанности, должностное лицо на верхнем
уровне может заменить его. апример, если Региональный Коорди-
натор не справляется со своими обязанностями, Координатор Зоны
может заменить его.
Чтобы обеспечить контроль и равновесие на самом высоком уровне
FidoNet, из правила организации сверху вниз есть два исключе-
ния. Координаторы Зон и Международный Координатор избираются
большинством голосов координаторов более низких уровней. Ана-
логично, решения, принятые Международным Координатором могут
быть отменены Советом Координаторов Зон, а решения, принятые
Координаторами Зон, могут быть отменены Региональными Коорди-
наторами. Более подробно это описано в разделах 6 и 7. Реше-
ния, принятые координаторами других уровней, не могут быть от-
менены голосованием на нижних уровнях, но могут быть обжалова-
ны. Этот процесс описан в разделе 9.5.
1.3 Определения
1.3.1 FidoNews
FidoNews - это еженедельный бюллетень, распространяемый по се-
ти в электронной форме. Это важное средство общения между
SysOp'ами FidoNet. FidoNews позволяет вам чувствовать себя
частью сообщества людей с общими интересами. Таким образом,
поощряется участие пользователей и SysOp'ов в выпуске
FidoNews. Корреспонденция направляется в адрес узла 1:1/1;
файл, описывающий используемые форматы, можно получить из
1:1/1 и многих других систем.
1.3.2 География
Каждый уровень FidoNet географически содержится в уровне, на-
ходящемся непосредственно над ним. Определенная географическая
точка покрывается одной зоной и одним регионом этой зоны, и
либо входит в одну из сетей, либо не входит ни в одну.
Если узел находится в области сети, он должен приводиться в
списке узлов этой сети, а не как независимый в регионе. (Пер-
вичное исключение из этого правила - узел, получающий непро-
порционально большое количество "почты", направленной в адрес
Host'а (патрона); см. раздел 4.2). Границы сети основаны на
телефонных регионах, установленых местными телефонными компа-
ниями. Даже в тех областях, где плотность узлов настолько
высока, что для обслуживания данного телефонного региона тре-
буется более одной сети, географический принцип является опре-
деляющим в вопросе о том, какие узлы принадлежат к какой сети
принадлежат. Членство в сети устанавливается с учетом геогра-
фического или других чисто технических факторов. Оно не осно-
вывается на личных или социальных факторах.
В некоторых случаях границы телефонных регионов приводят к си-
туациям, когда логика подсказывает, что узел, находящийся в
одном Регионе FidoNet, должен быть приписан к другому. В этих
случаях, с согласия Координаторов Регионов и Координатора Зо-
ны, заинтересованных в этом вопросе, могут быть одобрены осво-
бождения от членства в регионе. Такие процедуры описаны в раз-
деле 5.6.
1.3.3 Zone Mail Hour ("Почтовый" Час Зоны)
Zone Mail Hour (ZMH) - это установленное время, в течение ко-
торого все узлы зоны должны иметь возможность принимать
Netmail. Каждая зона FidoNet определяет ZMH и сообщает время
своего ZMH всем остальным зонам FidoNet. См. разделы 2.1.8 и
10.2.
Zone Mail Hour ранее назывался National Mail Hour и Network
Mail Hour. Термин Zone Mail Hour более точен.
1.3.4 NodeList
NodeList - это еженедельно обновляемый файл, содержащий адреса
всех признанных узлов FidoNet. Этот файл должен быть подготов-
лен Координатором Зоны не позднее ZMH в каждую субботу, и
доступен для загрузки или файлового запроса без всякой платы.
Чтобы система была включена в NodeList, она должна соот-
ветствовать требованиям, определяемым в этом документе. ика-
кие другие требования не могут быть выдвинуты.
Частичные NodeList'ы (для одной зоны, например) могут гото-
виться на различных уровнях FidoNet. Полный список, издаваемый
Международным Координатором, считается официальным NodeList'ом
FidoNet, и используется в таких обстоятельствах, как определе-
ние права голоса. Все составные части полного NodeList'а
доступны в каждой системе каждого Координатора Зоны и Регио-
нального Координатора.
1.3.5 Чрезмерно некорректное поведение
В этом уставе встречаются ссылки на "чрезмерно некорректное
поведение", особенно в разделе 9 (Урегулирование конфликтов).
Этот термин трудно поддается определению, поскольку он основан
на мнениях структуры координаторов. В общих словах, некоррект-
ное поведение раздражает, беспокоит или вредит кому-то друго-
му. Hе обязательно нарушать правила, чтобы вести себя некор-
ректно по отношению к другим.
Существует разница между чрезмерно некорректным поведением и
(просто) некорректным поведением. апример, каждый новый SysOp
должен получить некий минимум знаний, как в технических воп-
росах (установка программного обеспечения), так и в социальных
(как вести диалог с FidoNet). Редкому SysOp'у удается не вести
себя некорректно. Только после того, как такое поведение про-
должается после того, как это было указано SysOp'у, оно стано-
вится чрезмерно некорректным. Это не значит, что вы ведете се-
бя некорректно только после повторения какого-либо действия
(например, умышленная фальсификация корреспонденции некоррект-
на с самой первой попытки), но показывает, что некоторая тер-
пимость должна быть проявлена.
Для получения дополнительной информации по этому вопросу см.
раздел 9 и иллюстрирующие примеры (раздел 10.3).
1.3.6 Коммерческое использование
FidoNet является любительской сетью. Участники тратят свои
собственные деньги и время, чтобы она работала в интересах
всех ее пользователей. Она не предназначена для того, чтобы
некое коммерческое предприятие воспользовалось этими добро-
вольными усилиями в своих собственных деловых интересах. С
другой стороны, FidoNet обеспечивает компаниям и пользователям
удобное и эффективное средство для взаимовыгодного обмена ин-
формацией.
Координаторы Сетей могут быть вынуждены субсидировать коммер-
ческие операции, пересылая Netmail в адрес Host'а, и даже мо-
гут быть вовлечены в судебный процесс, если за пересылку кор-
респонденции было предложено некое вознаграждение. Таким обра-
зом, политика FidoNet такова, что коммерческая корреспонденция
не должна пересылаться. "Коммерческая корреспонденция" включа-
ет в себя корреспонденцию, преследующую определенные деловые
интересы, не приносящими пользы сети как целому. Примеры вклю-
чают внутреннюю корреспонденцию компаний, переписку между кор-
порациями, специфические запросы на изделия (например,
прейскуранты), заказы и т.п., а также все другие сферы, свя-
занные с деловой активностью.
2 Процедуры SysOp'а
2.1 Общие
2.1.1 Основные
Как SysOp индивидуального узлаa, в общем вы можете делать что
хотите, если вы соблюдаете правила переписки, не ведете себя
чрезмерно некорректно по отношению к другим узлам FidoNet и не
помогаете или не участвуете в распространении программного
обеспечения в нарушение права копирования, а также не осущест-
вляете иные незаконные операции через FidoNet.
2.1.2 Ознакомление с Уставом
Для того, чтобы понимать значение понятия "некорректное пове-
дение", все SysOp'ы обязаны время от времени перечитывать
Устав FidoNet. овые SysOp'ы должны ознакомиться с Уставом до
того, как запрашивать номер для своего узлa.
2.1.3 Ответственность за трафик, входящий в FidoNet через узел
SysOp, чей адрес приведен в пункте NodeList'a, несет от-
ветственность за трафик, входящий в FidoNet через его систему.
Это включает в себя (но не ограничивается только этим) трафик,
входящий от пользователей, Point'ов, и любых других сетей, для
которых система может служить шлюзом. Если SysOp позволяет
"внешним" сообщениям входить в FidoNet через систему, шлюзовая
система должна быть четко опознана по номеру узлa в FidoNet
как исходная точка сообщения, и должна действовать как шлюз и
в обратном направлении. Если такой трафик приводит к нарушению
Устава, SysOp должен исправить такую ситуацию.
2.1.4 Кодирование и просмотр корреспонденции
FidoNet является любительской системой. Наша технология тако-
ва, что приватность сообщений не может быть гарантирована. Как
SysOp, вы имеете право просматривать трафик, проходящий че-
рез вашу систему, хотя бы для того, чтобы быть уверенным, что
система не используется в незаконных или коммерческих целях.
Очевидно, что кодирование делает такой просмотр невозможным.
Таким образом, кодированный и/или коммерческий трафик, пересы-
лаемый без разрешения всех звеньев в системе пересылки, приз-
нается досаждающим поведением. Определение коммерческого тра-
фика дано в разделе 1.3.6.
2.1.5 Внесение изменений в пересылаемую корреспонденцию
Вы не можете вносить изменения, кроме тех, которые необходимы
для пересылки или других технических целей, в любое сообщение,
Netmail или Echomail (эхо-корреспонденцию), проходящее через
систему от одного узлa FidoNet к другому. Если вы оскорблены
содержанием сообщения, должна быть выполнена процедура,
описанная в разделе 2.1.7.
2.1.6 Частная Netmail
Слово "частная" должно использоваться с большой осторожностью,
особенно говоря о пользователях BBS. В некоторых странах су-
ществуют законы о "частной переписке", и нужно ясно дать по-
нять, что слово "частная" не означает, что никто другой, кроме
получателя, не может читать сообщения. SysOp, который не может
установить это различие, не должен предлагать пользователям
такую услугу, как "частная переписка".
Если пользователь посылает "частное сообщение", пользователь
не может контролировать количество посреднических систем, че-
рез которые направляется сообщение. SysOp, посылающий сообще-
ние другому SysOp'у, может контролировать этот аспект, направ-
ляя сообщение непосредственно в систему получателя, и таким
образом может быть уверенным, что только получатель или ка-
кое-либо другое лицо, имеющее разрешение SysOp'а, может прочи-
тать это сообщение. Поэтому у SysOp'а и обычного пользователя
могут быть разные понятия о "приватности".
2.1.6.1 Раскрытие проходящей корреспонденции
Раскрытие или использование в любой форме информации, содержа-
щейся в частном сетевом трафике, не адресованом вам или не на-
писанным вами, считается некорректным поведением, если трафик
не был распространен автором или получателем как часть фор-
мальной жалобы в соответствии с Уставом. Это не относится к
Echomail, которая по определению является средством вещания и
где частная корреспонденция часто используется для ограничения
доступа только SysOp'ами.
2.1.6.2 Частная корреспонденция, адресованная вам
Вопрос о частной корреспонденции, адресованной вам, более сло-
жен, чем вопрос о проходящей корреспонденции, рассмотренный в
предыдущем разделе. Общепринято, что когда вы получаете сооб-
щение, оно становится вашей собственностью и вы имеете закон-
ное право делать с ним все, что вы хотите. Однако ваше закон-
ное право не оправдывает вас, если вы ведете себя некорректно
по отношению к другим.
В общем, материалы щепетильного свойства не должны пересы-
латься по FidoNet. Этот принцип не всегда соблюдается,
поскольку FidoNet является нашим основным средством общения.
Если отправитель сообщения отдельно указывает в тексте сообще-
ния, что содержание должно оставаться конфиденциальным, расп-
ространение сообщения для публичного обсуждения может счи-
таться некорректным.
Могут быть и исключения. Если кто-то говорит одно публично и
противоположное в частной переписке, получатель частной пере-
писки не должен осуждаться только потому, что отправитель
настаивает на том, чтобы сообщение не распространялось. В этом
вопросе необходимо руководствоваться здравым смыслом, также
как и в других аспектах поведения в FidoNet.
2.1.7 Пересылка корреспонденции
От вас не требуется пересылать трафик, если вы не согласны де-
лать это. Вы не обязаны пересылать трафик для всех, делая это
для кого-то, если вы не занимаете должность Координатора Сети
или Координатора Разветвителя. Пересылка трафика через узел,
не обязанный выполнять пересылку, без разрешения этого узлa,
может рассматриваться как некорректное поведение. Это включает
в себя незапрашиваемую Echomail.
Если вы не пересылаете сообщение, предварительно согласившись
выполнять такую пересылку, сообщение должно быть возвращено
SysOp'у узлa, с которого оно вошло в FidoNet, с объяснением,
почему оно не переслано. (Не обязательно возвращать сообщения,
адресованные узлу, не входящему в текущий NodeList.) Умышлен-
ная задержка проходящего сообщения без выполнения описанной
процедуры является некорректным поведением. В случае неудачи в
пересылке трафика ввиду технической проблемы, это не считается
некорректным поведением, если не продолжается после того, как
на это было указано SysOp'у.
2.1.8 Исключительность Zone Mail Hour
Zone Mail Hour - это сердце FidoNet, потому что это время,
когда Netmail пересылается между системами. Любая система, ко-
торая желает быть частью FidoNet, должна иметь возможность
принимать корреспонденцию в это время, используя протокол, оп-
ределяемый в текущей публикации Комитета Технических Стандар-
тов FidoNet (FTS-0001 во время подготовки этого документа).
Разрешается иметь большие возможности (например, для поддержки
дополнительных протоколов или расширенных "почтовых" часов),
но минимальные требования - возможность FTS-0001 во время это-
го одного часа в день.
Это время зарезервировано исключительно для Netmail. Многие
телефонные системы требуют оплату за каждый звонок, независимо
от того, установлена была связь, не установлена, или линия бы-
ла занята. Исходя из этого, любая деятельность, кроме нормаль-
ной обработки Netmail, занимающая систему во время ZMH, счита-
ется некорректным поведением. Echomail не должна передаваться
во время ZMH. Доступ пользователя (BBS) к системе запрещен во
время ZMH.
К системе, являющейся членом местной сети, могут выдвигаться
требования по соблюдению дополнительных "почтовых" часов, оп-
ределяемых Координатором Сети. Ограничения на доступ во время
местных сетевых периодов устанавливаются по усмотрению Коорди-
натора Сети.
2.1.9 Частные узлы
Редкое исключение в выполнении ZMH составляют частные узлы.
Лица, запрашивающие частные узлы, должны при возможности под-
держиваться как Point'ы. Внесение частного узлa в список оп-
равдан, когда система должна взаимодействовать со многими дру-
гими, как например распределитель Echomail. В этих случаях,
точное время и способ передачи корреспонденции устанавливается
по согласованию между частным узлом и другими системами. Такое
соглашение между частной системой и почтовым буфером не обязы-
вает его делать какие-либо замены. Частный узел должен быть
частью сети (они не могут быть независимыми в регионе).
Внесение частного узла в список затрагивает интересы каждого
члена FidoNet, т.к. он занимает место в NodeList'e каждого.
Внесение частного узла в список, удобное для одного SysOp'a
(за счет всех остальных SysOp'ов FidoNet) - это роскошь, кото-
рую нельзя больше терпеть. Внесение в необязательные лишние
списки (более чем один список на один телефонный номер, кроме
позволенных стандартами FTSC) также попадают в эту категорию.
SysOp'ы, запрашивающие внесение в частные или лишние списки,
должны обосновать их в заявлении, объяснив, как это может быть
полезно для местной сети или FidoNet в целом. Координатор Сети
или Региональный Координатор могут пересмотреть это заявление
в любое время, и неоправданные внесения в списки будут отмене-
ны.
2.1.10 Соблюдение "почтовых" процедур
Невыполнение соответствующих "почтовых" процедур является
основанием для исключения любого узлa из FidoNet без предуп-
реждения (поскольку предупреждение обычно передается с
Netmail).
2.1.11 Использование текущего NodeList'a
Сетевые "почтовые" системы обычно работают без присмотра, и
выполняют звонки по ночам. Если система пытается позвонить по
неправильному или устаревшему номеру, это может привести к то-
му, что ранним утром у какого-нибудь в какой-нибудь квартире
зазвонит телефон, к большому неудовольствию присутствующих и
гражданских властей. По этой причине, SysOp, посылающий кор-
респонденцию, обязан получать и использовать самое последнее
издание NodeList'a, которое практически существует.
2.1.12 Экскоммуникация
Исключение системы из сети называется экскоммуникацией (т.е.
системе отказано в коммуникации). Если вы обнаружите, что вам
отказано в коммуникации без предупреждения, то это значит, что
ваш координатор не смог связаться с вами. Вы должны решить
проблему и связаться со своим координатором.
Системы также могут быть исключены из NodeList'a по какой-либо
иной причине. См. раздел 9, и разделы 4.3 и 5.2.
Помощь системе, которой было отказано в общении, в обхождении
этого исключения из NodeList'a, считается некорректным поведе-
нием. апример, если вы решите передавать echomail своему дру-
гу, которому отказано в общении, очень вероятно, что вы также
будете исключены из списка.
2.1.13 Время Zone Mail Hour
Точное время Zone Mail Hour для каждой зоны устанавливается
Координатором Зоны. См. раздел 10.2.
2.1.14 Несоблюдение летнего времени
FidoNet не соблюдает летнее время. В тех местах, где соблюда-
ется летнее время, "почтовые" расписания FidoNet должны быть
скорректированы в направлении часовой стрелки. Или же, вы мо-
жете оставить свою систему на стандартном времени.
2.2 Как получить узловой номер (Node Number)
Для начала вам нужно получить текущий NodeList, чтобы вы могли
посылать корреспонденцию. Вам не нужен узловой номер, чтобы
посылать корреспонденцию, но вы должны его иметь для того,
чтобы другие могли посылать корреспонденцию вам.
Первый шаг в получении текущего NodeList'a - найти любой "поч-
товый ящик" (BBS) FidoNet. Большинство списков BBS включают
как минимум несколько систем FidoNet и обычно идентифицируют
их как таковые. Используйте местный источник для получения до-
кументов, потому что многие сети имеют более подробную инфор-
мацию, объясняющую, какую местность покрывает сеть, а также
особые требования или процедуры.
Получив NodeList, вы должны определить, какая сеть или регион
покрывает вашу местность. Регионы имеют номера от 1 до 99; но-
мера сетей больше, чем 99. Сети более ограничены по террито-
рии, чем регионы, но предпочтительнее, потому что они улучшают
прохождение корреспонденции и обеспечивают больше услуг своим
членам. Если вы не можете найти сеть, покрывающую вашу мест-
ность, выберите регион, который это делает.
Когда вы найдете сеть или регион в вашей местности, пошлите
сообщение с запросом узлового номера нулевому узлу этой сети
или региона. Запрос должен быть послан с Netmail, т.к. это
указывает, что ваша система обладает возможностями участия в
FidoNet.
Вы должны настроить свое программное обеспечение таким обра-
зом, чтобы исходящий адрес в вашем сообщении не создавал проб-
лем для координатора, получающего его. Если вы укажете адрес
существующей системы, это создаст очевидные проблемы. Если ва-
ше программное обеспечение имеет возможность использования ад-
реса -1/-1, это традиционный адрес, используемый потенциальны-
ми SysOp'ами. В противном случае используйте адрес "сеть/9999"
(например, если вы хотите вступить в сеть 123, установите вашу
систему как 123/9999). Многие сети имеют свои собственные
инструкции для потенциальных SysOp'ов, и эти процедуры могут
указывать предпочтительные исходные адреса.
Посылаемое сообщение должно включать как минимум следующую ин-
формацию:
1) Ваше имя.
2) Номер вашего акустического телефона.
3) Имя вашей системы.
4) Город и страна, где находится ваша система.
5) Телефонный номер, которым следует пользоваться при вы-
зове вашей системы.
6) Ваши часы работы, Netmail и BBS.
7) Максимальную скорость передачи информации в бодах, ко-
торую вы можете поддерживать.
8) Тип программного обеспечения Mailer'a и модем, который
вы используете.
Ваш координатор может связаться с вами, чтобы получить допол-
нительную информацию. Вся предоставляемая информация конфиден-
циальна и не будет передаваться никому, кроме лица, вступающе-
го в должность координатора после отставки текущего координа-
тора.
Вы должны указать, что вы прочитали и согласны выполнять этот
документ и все текущие уставы FidoNet.
Пожалуйста, подождите как минимум две недели, которые нужны
для обработки запроса узлового номера. Если вы посылаете свой
запрос Региональному Координатору, он может быть переслан
соответствующему Координатору Сети.
2.3 Если вы временно покидаете сеть
Если ваш узел выходит из сети на некоторое продолжительное
время (более чем 1 - 2 дня), сообщите об этом своему координа-
тору как можно быстрее. Ваш координатор не отвечает за то,
чтобы находить вас и узнавать, почему вы не отвечаете, поэто-
му, если ваша система не принимает корреспонденцию, она будет
исключена из NodeList'a.
Во время вашего отсутствия никогда не устанавливайте на свой
телефон автоответчик или другие устройства, отвечающее на те-
лефонные звонки. Если вы это сделаете, вызывающие системы бу-
дут постоянно связываться с вашим автоответчиком, что приводит
к большим телефонным счетам и считается очень некорректным.
Короче говоря, единственное, что может отвечать на вызовы в то
время, когда NodeList указывает, что ваш узел принимает кор-
респонденцию, - это FidoNet-совместимое программное обеспече-
ние, принимающее корреспонденцию.
Если вы оставляете свою систему без присмотра на более протя-
женный период времени (например, когда вы уезжаете на канику-
лы), вы должны поставить в известность об этом своего коорди-
натора. Систему могут время от времени сбоить, поэтому вы ско-
рее всего захотите сообщить вашему координатору, что это вре-
менное состояние, если это случится во время вашего
отсутствия.
2.4 Как создать сеть
Если в вашей местности несколько узлов, но нет сети, может
быть создана новая сеть. Это выгодно как для вас, так и для
остальной части FidoNet. У вас появляются более удобные воз-
можности получения файлов отличий и FidoNews, а все остальные
могут воспользоваться преимуществами Host-направленной Netmail
в новую сеть.
Первым делом вы должны связаться с другими SysOp'ами в вашей
местности. Вы должны решить, какие узлы будут входить в вашу
сеть, и какой из этих узлов, по вашему мнению, должен быть Ко-
ординатором Сети. Затем проконсультируйтесь со своим Регио-
нальным Координатором. Вы должны выслать следующую информацию:
1) Номер(а) региона, или номер(а) сети при дроблении сети,
на которые влияет создание новой сети. Региональный Ко-
ординатор проинформирует Координатора Зоны и заинтересо-
ванных координаторов сетей, что создается новая сеть.
2) Копия предлагаемого отрывка NodeList'a для новой сети.
Этот файл должен прилагаться к сообщению с заявлением на
номер сети, и должен быть создан в формате NodeList'a,
описанном в текущей версии соответствующего издания
FTSC. Пожалуйста, выбирайте название, отражающее принцип
вашего объединения, например, SoCalNet для узлов в Южной
Калифорнии (Southern California) и MassNet West в Запад-
ном Массачусетсе (Western Massachusetts). Помните, что
если вы назовете себя DOGNET, это не идентифицирует вашу
местность.
Получение номера сети происходит не автоматически. Даже если
ваш запрос будет одобрен, структура сети может не соответство-
вать в точности вашему запросу. Ваш Региональный Координатор
рассмотрит ваше заявление и сообщит вам о своем решении.
Не посылайте запрос на получение номера сети Координатору Зо-
ны. Все запросы на получение номера зоны должны обрабатываться
Региональным Координатором.
3 Общие процедуры для всех координаторов
3.1 Распространение файлов различий и FidoNews
Все координаторы несут ответственность за еженедельное получе-
ние и распространение файлов различий NodeList'a и FidoNews.
3.2 Обработка изменений NodeList'a и передача их наверх
Каждый координатор несет ответственность за получение информа-
ции по NodeList'у от нижних уровней, ее обработку, и передачу
результатов на верхний уровень. Сроки обработки определяется
требованиями, устанавливаемыми верхним уровнем.
3.3 Распространение последней версии устава
Координатор несет ответственность за распространение текущей
версии данного документа на нижнем уровне, и поощряет ознаком-
ление с ним.
Кроме того, координатор обязан пересылать любые полученные ло-
кальные уставы на верхний уровень, и просматривать такие уста-
вы. Хотя это и не требуется, но правила хорошего тона диктуют,
чтобы при составлении локального устава приглашались к участию
верхние уровни.
3.4 Сведение к минимуму числа занимаемых должностей
Поощряется ограничение координаторами числа функций, которые
они выполняют в FidoNet. Координатор, занимающий две различные
должности, нарушает процесс аппеляции. Например, если Коорди-
натор Сети является также Региональным Координатором, SysOp в
этой сети лишается одного уровня аппеляции.
Не поощряется использование координаторами своих узлов в ка-
честве почтовых буферов для Echomail и программного обеспече-
ния. Если они все же выполняют эти функции, они должны обраба-
тывать Echomail (или выполнять другие распределительные функ-
ции) на любой другой системе, кроме административной. Система
координатора должна быть всегда доступна для уровней, находя-
щихся непосредственно над и под ним.
Другая причина, по которой не поощряется совмещение должностей
- это трудность в поиске замены на эти должности, если кто-то
выходит из сети. Например, если координатор использует свой
узел в качестве почтового буфера Echomail и программного
обеспечения, эти службы трудно будет восстановить при выходе
этого человека из сети.
3.5 Членство в управляемой структуре
Координатор должен быть членом управляемой структуры. Это зна-
чит, что Координатор Сети является членом сети, в которой он
должен состоять географически. Региональный Координатор должен
быть либо членом сети в своем регионе, либо независимым узлом
региона.
3.6 Поощрение вступления в FidoNet новых SysOp'ов
Поощряется создание и управление координатором BBS со свобод-
ным доступом пользователей с целью распространения Устава,
FidoNews и NodeList'ов среди потенциальных новых SysOp'ов.
Распространение этой информации важно для роста FidoNet, и ко-
ординаторы должны поощрять развитие новых систем.
3.7 Традиция и прецеденты
Координатор не связан практикой предшественников и координато-
ров соответствующего уровня в вопросах, не рассматриваемых в
этом документе.
Кроме того, новый координатор имеет право рассмотреть любое
решение своих предшественников на соответствие требованиям
Устава, и предпринять любые необходимые действия по урегулиро-
ванию ситуаций, не соответствующих этим требованиям.
3.8 Техническое управление
Первоочередные обязанности любого координатора - техническое
управление сетевыми операциями. Решения должны приниматься на
технической основе.
4 Процедуры Координатора Сети
4.1 Обязанности
Координатор Сети выполняет следующие обязанности:
1) Принимает входящую корреспонденцию для узлов сети, и
устраивает ее пересылку получателям.
2) Присваивает узловые номера узлам сети.
3) Ведет NodeList сети, и посылает его копию Региональному
Координатору, когда он меняется.
4) Обеспечивает доступ узлов сети к новым файлам различий в
NodeList'e, новым выпускам FidoNews, и новым редакциям
Уставных Документов Сети по мере их получения, и перио-
дически проверяет, чтобы узлы пользовались последними
доступными NodeList'ами.
4.2 Пересылка неограниченного объема корреспонденции
В вашей власти как Координатора Сети координировать прием и
пересылку неограниченного объема Host-направленной Netmail уз-
лам вашей сети. а ваше усмотрение остаются все связанные с
этим вопросы.
Если какой-либо узел вашей сети получает большой объем кор-
респонденции, вы можете запросить SysOp'a, чтобы он связался с
системой, посылающей эту корреспонденцию, и запросил ее не
направлять корреспонденцию Host'у. Если проблему не удалось
решить, вы можете запросить своего Регионального Координатора,
чтобы он присвоил узлу номер, как независимому в регионе, и
исключил систему из сети.
Иногда какой нибудь узел начинает "бомбардировку" (посылает
одно сообщение многим узлам). Если узел другой сети осущест-
вляет бомбардировки ваших узлов и направляет корреспонденцию
через ваш Host, вы можете подать жалобу Координатору Сети это-
го узла. (Если этот узел независим, вы подаете жалобу Регио-
нальному Координатору.) Бомбардировки считаются некорректными.
Другая причина маршрутной перегрузки - Еchomail. Недопустимо,
чтобы Еchomail уменьшала возможности FidoNet по обработке тра-
фика нормальных сообщений. Если узел в вашей сети пересылает
большой объем Еchomail, вы можете попросить SysOp'a либо огра-
ничить объем Еchomail, либо прекратить пересылку Еchomail.
От вас не требуется пересылать кодированную, коммерческую или
незаконную корреспонденцию. Однако, если вы не пересылаете
корреспонденцию, вы должны выполнить процедуры, описанные в
разделе 2.1.7.
4.3 Присвоение узловых номеров
В ваши обязанности входит присваивать узловые номера новым уз-
лам вашей сети. Вы можете также поменять номера существующих
узлов, хотя перед этим необходимо предупредить остальные узлы
сети. Вы можете присваивать любые номера, следя за тем, чтобы
каждый узел имел в сети свой уникальный номер.
Вы не должны присваивать узловой номер любой системе до тех
пор, пока не получите формальный запрос от этой системы по
"почте" FidoNet. Это гарантирует, что система минимально рабо-
тоспособна. Строгое соблюдение этого правила является одной из
основ FidoNet.
Также рекомендуется, хотя и не обязательно, связаться с систе-
мой, которая запрашивает узловой номер, до того как присвоить
ей номер.
Вы не можете присваивать узловой номер узлу, находящемуся в
местности, покрывающейся существующей сетью. Кроме того, если
некоторые из ваших узлов находятся в местности, покрывающейся
создаваемой сетью, эти узлы должны быть переданы новой сети.
Вы должны пользоваться Netmail, чтобы сообщить новому SysOp'у
его узловой номер, т.к. это поможет убедиться в возможности
системы принимать Netmail.
Если один из узлов вашей сети действует некорректно, вы можете
предпринять любые меры, которые вам кажутся соответствующими в
данных обстоятельствах.
4.4 Ведение NodeList'a
Вы должны вносить изменения имен, телефонных номеров, и т.д. в
ваш отрывок NodeList'a как можно быстрее после получения ин-
формации от заинтересованных узлов. Вы должны также при случае
посылать сообщения каждому узлу сети, чтобы убедиться в их ра-
ботоспособности. Если узел не отвечает без предварительного
предупреждения, вы должны либо отметить это, либо исключить
узел из NodeList'a. (Узлы могут находиться в списке не отвеча-
ющих максимум две недели, после чего линия должна быть удалена
из NodeList'a.)
По вашему усмотрению, вы можете распределять часть своей рабо-
чей нагрузки на почтовые буферы. В этом случае, вы должны по-
лучать NodeList'ы от Координаторов Буферов вашей сети. Вам
потребуется вести NodeList'ы для каждого буфера вашей сети,
т.к. вы не можете расчитывать на еженедельное получение исп-
равлений от каждого Координатора Буфера. Вы должны еженедельно
собирать общий NodeList вашей сети и посылать его Регионально-
му Координатору к установленному дню и времени. Предпочтитель-
но делать это как можно позднее, чтобы внести последние изме-
нения, но принимая во внимание возможность потери связи с Ре-
гиональным Координатором и таким образом пропуска недели.
4.5 Распространение Уставов, NodeList'ов и FidoNews
Как Координатор Сети, вы должны еженедельно получать от своего
Регионального Координатора новый выпуск FidoNews и новый файл
различий с предыдущим NodeList'ом. Файл различий с предыдущим
NodeList'ом в настоящее время распространяется по субботам, а
FidoNews выходит по понедельникам. Вы должны распространять
эти файлы среди всех узлов сети, и поощряется их распростране-
ние по линиям связи.
Вы должны также получать последние версии Уставов и других до-
кументов сети, и распространять их среди узлов вашей сети.
Уставы выходят непериодично, поэтому вы должны сообщить узлам
своей сети, когда это происходит, и убедиться, что узлы в об-
щем знакомы с изменениями.
Устав, FidoNews и NodeList - это основа, которая объединяет
нас. Без них мы перестали бы быть сообществом, и стали бы
просто еще одной разрозненой группой BBS.
5 Процедуры Регионального Координатора
5.1 Обязанности
Региональный Координатор выполняет следующие обязанности:
1) Присваивает узловые номера независимым узлам региона.
2) Поощряет присоединение независимых узлов региона к су-
ществующим сетям, или создание ими новых сетей.
3) Присваивает сетевые номера сетям в своем регионе и опре-
деляет их границы.
4) Создает общий NodeList всех сетей и независимых узлов
региона и посылает его копию Координатору Зоны, когда он
изменяется.
5) Обеспечивает бесперебойную работу сетей в регионе.
6) Расространяет новые файлы различий от предыдущего
NodeList'a, Уставы и выпуски FidoNews среди Координато-
ров Сетей региона настолько быстро, насколько это воз-
можно.
5.2 Присваивание узловых номеров
Вы обязаны присваивать узловые номера независимым узлам регио-
на. Вы также можете менять номера существующих узлов сети,
предварительно сообщив об этом соответствующим узлам. Вы може-
те присваивать любые номера, следя за тем, чтобы каждый узел
имел в сети свой уникальный номер.
Вы не должны присваивать узловой номер любой системе до тех
пор, пока не получите формальный запрос от этой системы по
"почте" FidoNet. Это гарантирует, что система минимально рабо-
тоспособна. Строгое соблюдение этого правила является одной из
основ FidoNet.
Также рекомендуется, хотя и не обязательно, связаться с систе-
мой, которая запрашивает узловой номер, до того как присвоить
ей номер.
Вы должны пользоваться Netmail, чтобы сообщить новому SysOp'у
его узловой номер, т.к. это поможет убедиться в возможности
системы принимать Netmail.
Если один из узлов вашей сети действует некорректно, вы можете
предпринять любые меры, которые вам кажутся соответствующими в
данных обстоятельствах.
Если вы получаете запрос узлового номера не из своего региона,
вы должны переслать запрос соответствующему координатору само-
го низкого возможного уровня, который вы сможете определить.
Если вы получаете запрос узлового номера от нового узла, нахо-
дящегося в местности, покрываемой существующей сетью, вы долж-
ны переслать запрос соответствующему Координатору Сети, вместо
того, чтобы присваивать номер самому.
Если в местности, где находятся ваши независимые узлы, созда-
ется новая сеть, эти узлы должны быть переданы в эту сеть, как
только это будет возможно.
5.3 Поощрение создания и роста сетей
Одной из ваших основных обязанностей как Регионального Коорди-
натора является стимулирование роста сетей вашего региона.
Вы должны избегать наличия в регионе независимых узлов, нахо-
дящихся в местности, покрываемой сетью. Однако существуют оп-
ределенные случаи, когда узел не должен быть членом сети, как
например система с неограниченным объемом Netmail; см. раздел
4.2.
Если несколько независимых узлов вашего региона находятся в
одной местности, вы должны поощрять их к созданию сети, а если
это необходимо, вы можете потребовать от них создать сеть. См.
раздел 2.4. Имейте в виду, что это не значит, что вы должны
поощрять создание мелких сетей. Очевидно, что один узел не яв-
ляется сетью. Точное число узлов, которое требуется для созда-
ния эффективной сети, должно определяться по обстоятельствам,
и остается на ваше усмотрение.
5.4 Присвоение сетевых номеров
В ваши обязанности входит присвоение сетевых номеров новым се-
тям, создающимся в вашем регионе. Координатор Зоны присваивает
вам определенный диапазон сетевых номеров для этих целей. Как
часть этой функции, в ваши обязанности как Регионального Коор-
динатора входит определение границ сетей вашего региона.
5.5 Ведение NodeList'a
Как Региональный Координатор, вы выполняете двоякую роль в ве-
дении NodeList'a региона.
Во-первых, вы должны вести список независимых узлов региона.
Вы должны по возможности быстро вносить в NodeList изменения
имен, телефонных номеров и т.д.. Вы должны также при случае
посылать сообщения каждому узлу сети, чтобы убедиться в их ра-
ботоспособности. Если узел не отвечает без предварительного
предупреждения, вы должны либо отметить это, либо исключить
узел из NodeList'a. (Узлы могут находиться в списке не отвеча-
ющих максимум две недели, после чего линия должна быть удалена
из NodeList'a.)
Во-вторых, вы должны получать NodeList'ы от Координаторов Се-
тей вашего региона. Вам потребуется вести NodeList'ы для каж-
дой сети вашего региона, т.к. вы не можете расчитывать на еже-
недельное получение исправлений от каждого Координатора Сети.
Вы должны еженедельно собирать общий NodeList вашего региона и
посылать его Координатору Зоны к установленному дню и времени.
Предпочтительно делать это как можно позднее, чтобы внести
последние изменения, но принимая во внимание возможность поте-
ри связи с Координатором Зоны и таким образом пропуска недели.
5.6 Географические освобождения
Встречаются случаи, когда география местных телефонных сетей
не совпадает с регионами FidoNet. В исключительных случаях по
соглашению с заинтересованными Региональными Координаторами и
Координаторами Зон допускаются освобождения от действующего
обычно географического принципа. Такие исключения не являются
правом, и не постоянны. Когда в соответствующем регионе созда-
ется сеть, обеспечивающая доступ к освобожденному узлу по
местным телефонным линиям, такой узел перестает быть освобож-
денным. Освобождение может быть пересмотрено и отозвано в лю-
бое время любым заинтересованным координатором.
5.7 Надзор за работой сетей
В ваши обязанности входит назначение Координаторов Сетей в ва-
шем регионе. Если уходящий Координатор Сети предлагает своего
преемника, вы не обязаны принимать эту кандидатуру, хотя обыч-
но вы ее принимаете.
Вы, как Региональный Координатор, отвечаете за то, чтобы сети
в вашем регионе работали в допустимой манере. Это не значит,
что от вас требуется управлять деятельностью этих сетей; это
входит в обязанности Координаторов Сетей. о это значит, что
вы должны следить за тем, чтобы Координаторы Сетей в вашем ре-
гионе выполняли свои обязанности.
Если вы пришли к выводу, что Координатор Сети вашего региона
плохо выполняет свои обязанности, описанные в Разделе 4, вы
можете предпринять любые меры, которые, по вашему мнению, не-
обходимы для того, чтобы исправить ситуацию.
Если сеть становится настолько большой, что не может спра-
виться с прохождением трафика за время ZMH, Региональный Коор-
динатор может создать из этой сети еще одну или более новых
сетей. Эти новые сети, хотя они могут находиться в пределах
одной местной телефонной сети, при определении членства должны
все же руководствоваться географическим принципом.
Ваша обязанность, как Регионального Координатора, - поддержа-
ние с разумной периодичностью прямого контакта с сетями вашего
региона. Выбор способа выполнения этих обязанностей остается
на ваше усмотрение.
5.8 Распространение Уставов, NodeList'ов и FidoNews
Как Региональный Координатор, вы должны получать новый файл
различий с предыдущим NodeList'ом, уставы сетей и новые вы-
пуски FidoNews по мере их выхода и распространять их среди Ко-
ординаторов Сетей вашего региона. NodeList распространяется
еженедельно по субботам Координатором Зоны, а FidoNews изда-
ется по понедельникам узлом 1/1. Свяжитесь с ними для выясне-
ния деталей о том, как получать еженедельно последние копии.
В ваши обязанности входит распространение этого материала сре-
ди всех Координатов Сетей вашего региона как можно быстрее
после его получения. Как вы это сделаете, остается на ваше
усмотрение. От вас не требуется распространять их среди неза-
висимых узлов региона, хотя если вы хотите, вы можете это де-
лать. Поощряется распространение этих документов по линиям
связи для ознакомления с ними широкой публики.
6 Процедуры Координатора Зоны
6.1 Общие
Первоочередной задачей каждого из Координаторов Зон FidoNet
является ведение NodeList'a Зоны и распространение главного
NodeList'a (или файла различий) в Регионах Зоны. Координатор
Зоны также отвечает за координацию распространения документов
Устава Сети и FidoNews среди Региональных Координаторов Зоны.
В обязанности Координатора Зоны входит обеспечение бесперебой-
ной деятельности сети в Зоне, которое осуществляется назначе-
нием и надзором за Региональными Координаторами.
Если Координатор Зоны определяет, что Региональный Координатор
плохо выполняет свои обязанности, перечисленные в разделе 5,
должна быть найдена замена.
Координатор Зоны устанавливает географические границы регионов
Зоны и назначает время Zone Mail Hour.
Координатор Зоны отвечает за пересмотр и утверждение любых ге-
ографических освобождений, описанных в разделе 5.6.
Координатор Зоны отвечает за обеспечение бесперебойной работы
шлюзов между зоной и другими зонами, передающих корреспонден-
цию между зонами.
Координаторы Зон выбирают из своей среды Международного Коор-
динатора.
6.2 Выборы
Координатор Зоны выбирается абсолютным большинством голосов
Региональных Координаторов зоны.
7 Процедуры Международного Координатора
7.1 Общие
Международный Координатор - это "первый среди равных" Коорди-
натор Зоны.
Первоочередной задачей Международного Координатора является
создание главного NodeList'a, которая осуществляется управле-
нием распределения NodeList'ов Зон между Зонами. Международный
Координатор отвечает за определние новых зон, а также за веде-
ние переговоров и заключение соглашений о коммуникации с дру-
гими сетями. ("Другие сети" в этом контексте означают сети, с
которыми Fidonet взаимодействует на равных, а не "сети" в зна-
чении организационного уровня FidoNet.)
Международный Координатор также отвечает за координацию расп-
ределения Уставов Сети и FidoNews среди Координаторов Зон.
Международный Координатор отвечает за координацию деятельности
Совета Координаторов Зон. Международный Координатор является
представителем Совета Координаторов Зон.
По вопросам, не рассмотренным подробно в этом документе, Меж-
дународный Координатор может издавать конкретные толкования
или дополнения к этому Уставу. Совет Координаторов Зоны может
отменить эти документы большинством голосов.
7.2 Выборы
Международный Координатор избирается (или смещается со своего
поста) абсолютным большинством голосов Координаторов Зон.
8 Референдумы
Процедуры, описанные в этом разделе, используются при ратифи-
кации новой версии устава FidoNet и представляют собой меха-
низм изменения устава. Эта процедура также используется при
вынесении вотума недоверия Координатору Зоны.
8.1 Проведение референдума
Референдум по вопросу изменения устава проводится, когда боль-
шинство Региональных Координаторов FidoNet сообщают Междуна-
родному Координатору, что они хотят рассмотреть предлагаемую
новую версию Устава.
8.2 Объявление и результаты
Предполагаемые изменения Устава распространяются с использова-
нием той же структуры, которая используется для распределения
файлов различий NodeList'a и FidoNews. Результаты и объявле-
ния, связанные с референдумом, распространяются структурой ко-
ординаторов как часть еженедельного файла различий NodeList'a.
Международный Координатор предоставляет копии редактору
FidoNews для включения в выпуск, хотя официальное объявление и
даты голосования привязываются к распределению NodeList'a.
В случае принятия нового устава Международный Координатор
устанавливает дату его вступления в силу и объявляет ее в еже-
недельном файле различий NodeList'a. Документ вступает в силу
не позднее одного месяца после завершения голосования.
8.3 Право голоса
Каждый член структуры координаторов FidoNet на уровне и выше
Координатора Сети имеет один голос. (Координаторы почтовых бу-
феров не имеют права голоса.) В случае, если во время голосо-
вания в должность вступает новый координатор, голосовать может
либо он сам, либо его предшественник, но не оба. Если один че-
ловек совмещает более одной должности координатора, он тем не
менее имеет только один голос.
Предполагается, что Координаторы Сетей оценивают мнение членов
своей сети, и голосуют соответственно. Проводить формальное
голосование не требуется, но Координатор Сети должен проинфор-
мировать сеть о вопросах и договориться о позиции сети. Коор-
динатор Сети действует как представитель рядовых членов
FidoNet.
8.4 Механизм голосования
Фактический механизм голосования, включая вопрос о том, будет
ли голосование тайным, как будут собираться, проверяться и
подсчитываться голоса, устанавливается по усмотрению Междуна-
родного Координатора. В идеале, сбор голосов должен осущест-
вляться с помощью надежно защищенной системы связи, обеспечи-
ваемой самой FidoNet.
Для обеспечения достаточного времени обсуждения, любое голосо-
вание должно быть объявлено не позднее чем за две недели до
его начала. Время сбора голосов не должно быть менее двух не-
дель.
8.5 Голосование по Уставу в целом
Поскольку этот Устав взаимно переплетается и содержит ссылки
на себя, то сравнительно простое изменение может повлечь
несколько изменений в документе. Для упрощения процесса при
голосовании делается выбор между целыми документами, а не меж-
ду отдельными изменениями. В простейшем случае, это означает
голосование "за" и "против" по новому документу. Если рассмат-
риваются несколько альтернатив, они должны быть представлены
целыми документами, из которых выбирается один.
8.6 Принятие решения
Изменение Устава считается вступившим в силу если, после окон-
чания сбора голосов, оно получило большинство поданных го-
лосов. апример, если 350 человек имело право голоса, из них
100 подали голоса, то для объявления вступления в силу измене-
ния требуется как минимум 51 голос "за".
В случае рассмотрения нескольких изменений устава в одном го-
лосовании, версия должна получить более 50% поданных голосов,
чтобы быть ратифицированной. В этом случае голоса воздержав-
шихся от голосования влияют на результат, будучи по существу
голосами против изменения текущего устава, т.к. они увеличива-
ют количество голосов, требуемых для ратификации предлагаемых
изменений.
8.7 Вотум недоверия Координатору Зоны
8.7.1 Проведение
В исключительных случаях, Координатору Зоны может быть вынесе-
но недоверие в результате референдума. Вотум недоверия Коорди-
натору Зоны не обязательно проводится в результате нарушения
Устава. Вотум недоверия объявляется, когда большинство Регио-
нальных Координаторов зоны требуют его проведения от Междуна-
родного Координатора.
8.7.2 Процедура, аналогичная референдуму по уставу
Положения разделов 8.2 и 8.3 применимы к проведению вотума не-
доверия.
Применимо определение понятия "большинство" в разделе 8.6.
Право голоса имеют только координаторы данной зоны (даже если
Координатор Зоны является также Международным Координатором).
8.7.3 Механизм голосования
Региональный Координатор, назначенный Координатором Зоны, ко-
торому выносится вотум недоверия, устанавливает процедуры го-
лосования, проводит сбор голосов и объявляет результаты. Сме-
щение Координатора Зоны производится в течение двух недель
после окончания голосования, если вотум вынесен.
8.7.4 Ограничение проведения вотума одним в год
Смещение Координатора Зоны в первую очередь является механиз-
мом, с помощью которого сеть в целом выражает неудовольствие
толкованием Устава Координатором Зоны. В том или ином случае,
все бывают недовольны тем, как толкуется Устав. Для того, что-
бы Координаторы Зон все же толковали Устав, а не занимались бы
только тем, что защищали себя, между вотумами должен проходить
как минимум один календарный год (независимо от того, как мно-
го человек занимает пост Координатора Зоны в течение этого го-
да.)
Если Координатор Зоны уходит в отставку во время проведения
вотума, вотум считается не имеющим силы и недействительным, и
не входит в квоту "один в год".
9 Урегулирование конфликтов
9.1 Общие процедуры
Юридическая философия FidoNet может быть выражена двумя прави-
лами:
1) Ты не должен быть чрезмерно некорректным по отношению
к другим.
2) Ты не должен слишком легко раздражаться из-за некор-
ректного поведения по отношению к себе.
Другими словами, каких-нибудь строгих правил не существует, но
ожидается вежливое поведение. Также, в любом конфликте обсуж-
дается вина каждой стороны, и меры могут быть приняты против
любой из них или их обеих. ("не суди, да не судим будешь!")
Ответственность за определение "чрезмерно некорректного пове-
дения" лежит на структуре координаторов. Как и общепринятое
определение порнографии ("Я не могу определить это, но знаю,
что это, когда я это вижу."), точное определение допустимого
поведения в FidoNet невозможно. Основные направления этого
устава намеренно оставлены недостаточно конкретными, чтобы
обеспечить структуре координаторов ту свободу, которая им не-
обходима для соответствия нуждам растущего и меняющегося сооб-
щества.
Первый шаг в любом конфликте между SysOp'ами - это попытка
SysOp'ов связаться напрямую, по крайней мере с помощью
Netmail, но лучше по обычному телефону. Если, подавая жалобу,
вы пропустили этот основной этап, ваша жалоба не будет
рассматриваться.
Рассмотрение формальной жалобы - это действие, к которому не
следует легкомысленно относиться. Расследование и принятие мер
по жалобе требует времени, которое координаторы предпочли бы
потратить на более конструктивную деятельность. Тот, кто
настаивает на рассмотрении мелких жалоб по нарушению устава,
может оказаться виновным в "чрезмерно некорректной" подаче жа-
лобы. Жалобы должны сопровождаться убедительными доказательст-
вами, обычно копиями сообщений; просто голословные жалобы не
рассматриваются.
есоблюдение описанных здесь процедур (в частности, обращение
через голову координатора, или обращение к координатору, не
входящему в цепочку аппеляции) само по себе является некор-
ректным поведением.
9.2 Проблемы с другим SysOp'ом
Если у вас возникли проблемы с другим SysOp'ом, вы должны пер-
вым делом попробовать урегулировать их через Netmail или в те-
лефонном разговоре с этим SysOp'ом.
Если при этом не удалось решить проблему, вы должны подать жа-
лобу вашему Координатору Сети и Координатору Сети другого
SysOp'a. Если вы, или вы оба не входите в сеть, вы должны по-
дать жалобу соответствующему Региональному Координатору. Если
при этом вы не будете удовлетворены, вы имеете право на аппе-
ляцию, процесс которой описан в разделе 9.5.
9.3 Проблемы с вашим Координатором Сети
Если у вас возникли проблемы с вашим Координатором Сети и вам
кажется, что с вами поступают неправильно, вы имеете право на
рассмотрение данной ситуации. Как и во всех конфликтах, первым
шагом является попытка решить проблему, связавшись напрямую.
Следующим шагом вы связываетесь со своим Региональным Коорди-
натором. Если ваш случай заслуживает рассмотрения по существу,
возможны разные варианты предпринятых мер, включая смену Коор-
динатора Сети или даже расформирование вашей сети. Если вам
было отказано в общении вашим Координатором Сети, это решение
может быть отменено, и вы будете восстановлены в сети.
Если вы останетесь недовольны решением Регионального Координа-
тора, вы имеете право на аппеляцию, процесс которой описан в
разделе 9.5.
9.4 Проблемы с другими координаторами
Жалобы на некорректное поведение любых координаторов рассмат-
риваются, как описано в разделе 9.2, и должны подаваться коор-
динатору следующего уровня. апример, если вам кажется, что
ваш Региональный Координатор виновен в некорректном поведении
(в противоположность неспособности исполнять обязанности коор-
динатора), вы должны подать свою жалобу Координатору Зоны.
Жалобы, касающиеся деятельности координатора по выполнению им
обязанностей, предусмотренных уставом, принимаются только от
уровня, непосредственно под ним. апример, жалобы, касающиеся
деятельности Регионального Координатора, принимаются от Коор-
динаторов Сетей и независимых узлов региона. Такие жалобы
должны направляться Координатору Зоны после соответствующих
попыток решить проблемы с помощью непосредственного общения.
9.5 Процесс аппеляции
а решение, принятое координатором, может быть подана аппеля-
ция следующему уровню. Аппеляция должна быть подана в течение
двух недель после принятия решения, на которое подается аппе-
ляция. Все аппеляции должны следовать по цепочке управления;
если пропущены уровни, аппеляция немедленно отклоняется.
Результатом аппеляции не будет полное расследование, а решение
будет принято на основе документов, предоставленных сторонами
на нижнем уровне. апример, при рассмотрении аппеляции на ре-
шение Координатора Сети Региональный Координатор будет пользо-
ваться информацией, предоставленной этим координатором и по-
давшим жалобу SysOp'ом; Региональный Координатор не обязан
предпринимать попытки независимого сбора информации.
Аппеляция имеет следующую структуру:
Аппеляции на решения Координатора Сети могут быть поданы
соответствующему Региональному Координатору.
Аппеляции на решения Регионального Координатора могут быть
поданы соответствующему Координатору Зоны. Координатор Зоны
принимает решение и доводит его до Региональных Координато-
ров этой зоны. Это решение может быть отменено большинством
голосов Региональных Координаторов.
Аппеляции на решения Координатора Зоны могут быть поданы
Международному Координатору. Международный Координатор при-
нимает решение и доводит его до Совета Координаторов Зон,
который может отменить его большинством голосов.
Если у вас возникла проблема с самим Координатором Зоны, т.е.,
Координатор Зоны нарушил устав по отношению к вам, ваша жалоба
должна быть подана Международному Координатору, который примет
решение и сообщит о нем Совету Координаторов Зон для возможной
отмены, как описано выше.
9.6 Ограничения срока рассмотрения жалобы
Жалоба не может рассматриваться более 60 дней, начиная с даты
обнаружения источника нарушения, либо по признанию, либо тех-
нической уликой. Жалобы не могут рассматриваться более 120
дней с момента происшествия, если это не определенно незакон-
ное поведение.
9.7 Право на быстрое решение
От координатора требуется предоставление заключительного реше-
ния и уведомления сторон, которых оно касается, в течение 30
дней со времени получения жалобы или аппеляции.
9.8 Возврат в первоначальную сеть
Когда обсуждения по уставу завершены, любые узлы, восстановле-
нные в своих правах по аппеляции, возвращаются в местную сеть
или регион, которому они принадлежат географически или техни-
чески.
9.9 Эхо-почта
Эхо-почта является важной и действенной составляющей FidoNet.
При обсуждении устава Эхо-почта просто является видом сетевой
почты и поэтому регулируется уставом. По своей природе эхо-по-
чта несет уникальные технические и социальные требоования к
узлу, описанные этой версией устава. В определении этого, ус-
тав эхо-почты, который расширяет (и не противоречит) общий ус-
тав, принятый координатором эхо-почты, и утвержденный действи-
ем сходным с имеющим место в настоящем уставе, принимается
FidoNet-координаторами как действительная структура по решению
спора, относящегося к эхо-почте. В недалеком будущем устав
эхо-почты может быть объеденен с настоящим уставом.
9.10 Прецедент
В большинстве случаев, устав FidoNet является объяснительным
по своей сущности. Никто не может предугадать, что может изме-
ниться в нашей изменчивой среде. Сам устав - это только часть
используемых основных правил для решения промежуточных споров
или, что более важно - для прецедента.
Для удобства этих процессов данный раздел может быть добавлен
или удален из настоящего документа международным координатором
по решению совета зональных координаторов. Как только появляе-
тся прецедент, он отражается в документе (тщательно подготов-
ленным).
Хотя сам случай впоследствии может и не повториться, его опи-
сание не может быть удалено из устава. Описание случая приво-
дится сразу после решения, теми кто под этот случай подпадают.
Исправление текста описания случая, тоже что и ревизия - про-
цедура не свойственная организации посвященной продвижению ин-
формации.
10 Приложения
10.1 Общее
Приложения к этому уставу - исключение от нормального ратифи-
цированного процесса. Подраздел 10.2 может, соответственно ме-
стным условиям, быть изменен координатором зоны и подраздел
10.3 может быть дополнен международным координатором (см. под-
раздел 9.10).
10.2 Время "почтового" часа зоны (ZMH)
ZMH наблюдается каждый день, включая выходные и праздники.
Время основывается на всемирном координированном времени
(UTC), известным также как среднее время по Гринвичу (GMT). В
областях, которые соблюдают дневное время записи (DST) на про-
тяжении части года, местное время ZMH будет меняться из-за то-
го, что FidoNet не соблюдает DST. Точное время ZMH устанавли-
вается для каждой зоны зональным координатором.
Для 1 зоны FidoNet, ZMH установлен с 09-00 до 10-00 UTC.
В каждой временной зоне это будет:
Восточное стандартное время 4 АM до 5 АМ
Центральное стандартное время 3 АM до 4 АМ
Горное стандартное время 2 АM до 3 АМ
Тихоокеанское стандартное время 1 АM до 2 АМ
Гавайское стандартное время 11 РM до полуночи
где: АМ - время до полудня РМ - время после полудня
Для 2 зоны FidoNet, ZMH установлен с 02-30 до 03-30 UTC.
Для 3 зоны FidoNet, ZMH установлен с 18-00 до 19-00 UTC.
В каждой временной зоне это будет:
GMT + 12 зона (Новая Зеландия) от 06-00 АМ до 07-00 АМ
GMT + 10 зона (Вост.Австралия,
Папуа Новая Гвинея,
Микронезия) от 04-00 АМ до 05-00 АМ
GMT + 9.5 зона (Центр.Австралия) от 03-30 АМ до 04-30 АМ
GMT + 9 зона (Япония, Корея,
Вост.Индонезия) от 03-00 АМ до 04-00 АМ
GMT + 8 зона (Гон-Конг, Тайвань,
Центр.Индонезия,
Филиппины,
Западная Австралия) от 02-00 АМ до 03-00 АМ
GMT + 7 зона (Малайзия, Сингапур,
Таиланд,
Запад.Индонезия) от 01-00 АМ до 02-00 АМ
10.3 Прецедент
Описание событий прошедших споров является инструкцией к обще-
му руководству. Любое решение может быть включено в этот доку-
мент большинством голосов Совета Координаторов Зон или Регио-
нальными Координаторами.
Устав 4 сильно изменяет функции Зональных или Международных
Координаторов. В случаях, предусмотренных уставом 3 - Зональ-
ный Координатор заменяется Международным Координатором (*).
10.3.1 Случай провинившегося узла
SysOp местного узла использовал сетевую почту в коммерческой
практике. Сетевой Координатор заметил эту некорректность в его
поведении и исключил узел из NodeList'а.
Узел обратился к Региональному Координатору о предоставлении
независимого статуса. Региональный координатор после проверки
с сетевым координатором решил, что сетевой координатор был
прав. Предоставление независимого статуса было отложено. Меж-
дународный координатор не вмешивался.
10.3.2 Случай с Hacker Mailer
SysOp местного узла использовал файл атташе для специальных
пользователей для посылки себе файла USER.BBS из нескольких
местных систем. SysOp'ы этих систем объявили о некорректном
поведении по отношению к ним и обратились с аппеляцией к свое-
му сетевому координатору, который согласился с ними и исключил
узел ис списка. Консультаций с Региональным Координатором не
было. Международный Координатор(*) не вмешивался.
10.3.3 Случай беспокойного крикуна
Локальный узел был недоволен Координатором Сети, который, по
его мнению. не предоставлял достаточно услуг. Постоянные жало-
бы Координатору сети не удовлетворили его, поэтому он обратил-
ся к Международному Координатору(*).
Международный Координатор(*) не стал рассматривать жалобу,
т.к. жалоба не подавалась Региональному Координатору.
Локальный узел подал жалобу Региональному Координатору, кото-
рый расследовал этот случай и пришел к выводу, что какая-то
доля истины в жалобе была. Он дал совет и помог Координатору
Сети конфигурировать его систему таким образом, чтобы она обе-
спечивала более высокий уровень услуг локальным узлам.
Региональный Координатор также решил, что локальный узел был
недоволен, ожидая услуг, не требуемых обычно от Координатора
Сети. Локальный узел был проинформирован об истинных обязанно-
стях Координатора Сети, и ему также посоветовали снизить уро-
вень своих ожиданий.
10.3.4 Случай очень занятого узла
Локальный узел, на котором работал розничный торговец, занима-
лся "бомбардировками", посылая свою рекламу через FidoNet. Ко-
ординатор Сети был недоволен тем, что ему приходилось обраба-
тывать выходящий трафик в коммерческих целях, и попросил лока-
льный узел выйти из сети.
Локальный узел обратился к Региональному Координатору, и по-
лучил статус независимого узла в регионе.
10.3.5 Метка дьявола
Местный SysOp, чей "почтовый ящик" использовался в связи с ко-
лдовскими ритуалами, хакерством, phreaking, и неприличными ма-
териалами, обратился к Координатору Сети, чтобы получить узло-
вой номер. Координатор Сети, полагая, что этот "почтовый ящик"
чрезвычайно некорректен, отклонил запрос.
Консультации с Региональным Координаторм не проводились.
Международный Координатор(*), узнав, что консультации с Ре-
гиональным Координаторм не проводились, отменил это решение.
В дальнейшем аппеляции не подавались.
10.3.6 Случай SysOp'a - идиота
Клиент различных локальных узлов был повсеместно известен
среди SysOp'ов как идиот. Пользователь приобрел свою собствен-
ную систему, стал SysOp'ом, и подал запрос на получение узло-
вого номера. Координатор Сети отклонил запрос. Аппеляция не
была подана.
10.3.7 Случай пристрастия к Echomail
Локальный узел пристрастился к Echomail и принял участие в не-
скольких конференциях, направлявших Mail через его сеть. Затем
он начал свое собственную Echomail-конференцию и транслировал
Echomail между несколькими системами, снова пересылая ее через
сеть.
Координатор Сети заметил, что работа сети заметно ухудшилась.
Он потребовал от узла-нарушителя уменьшить количество Echoma-
il, проходящей через сеть. Компромисс был достигнут на том,
что большинство трафика Echomail больше не пересылалось через
сеть, а пересылаемый объем Echomail ограничен двадцатью сооб-
щениями за ночь. Аппеляция не была подана.
10.3.8 Случай непостоянной работы "почтового ящика"
Локальный пользователь решил установить узел в благотвори-
тельных целях. Используемая машина в дневное время применя-
лась также и в других целях, а SysOp часто отлучался. Его кол-
леги часто забывали устанавливать систему в конце рабочего
дня, когда его не было на месте, поэтому узел часто в течение
продолжительного времени не отвечал. Координатор Сети, обнару-
жив, что узел не способен принимать корреспонденцию, отметил,
что он не отвечает. SysOp возвращался, снова устанавливал "по-
чтовый ящик", и просил восстановить его.
В конце концов, Координатор Сети решил, что SysOp не способен
обслуживать надежную систему, и окончательно удалил его из
NodeList'a. Последующие запросы узлового номера от того же
SysOp'a были отклонены. Аппеляция не была подана.
10.5 Официальные заявления и т.п.
Fido и FidoNet являются зарегистрированными торговыми марками
Fido Software, Inc.
Алфавитный указатель
-1/-1, 2.3
Автоответчик 2.3
Административный регион 6.1
Адрес в сообщении с запросом узлового номера 2.2
Адрес для напраления материалов для FidoNews 1.3.1
Большинство 8.6, 8.7.2
Бомбардировка 4.2
BossNode 1.2.1.2
Быстрое решение 9.7
Внесение изменений в NodeList 3.2
Время обсуждения 8.2
Время сбора голосов 8.4
Время Zone Mail Hour 2.1.13, 2.1.14, 10.2
Вопросы взаимоотношений между зонами 1.2.6
Вотум недоверия 8.7
Входящая корреспонденция 2.1.6.1
Выборы координаторов 1.2.5, 6.2, 7.2
Гарантия доставки корреспонденции 1.3.6
География 1.3.2, 5.6
Голос 8
право 8.3, 8.7.2
Границы 1.3.2
Дата вступления в силу изменений в уставе 8.2
Должности 3.4
Дополнительные "почтовые" процедуры в локальных сетях 2.1.8
Доступность NodeList'а 1.3.4
Доступ пользователя во время ZMH 2.1.8
EchoMail 4.2, 9.9
Жалоба (по уставу) 2.1.6.1, 9
Загрузка пользователями 3.6, 4.5, 5.8
Заказы (коммерческие) 1.3.6
Замена координаторов 1.2.8
Замена служб 3.4
Замена узлового номера 4.3, 5.2
ZMH см. Zone Mail Hour
Знакомство с уставом 2.1.2, 2.2
Zone Mail Hour 1.3.3, 2.1.8
время 2.1.13, 2.1.14, 10.2
Зоны 1.2.5, 1.3.2
Изменение корреспонденции 2.1.5
Исключения 5.6
Исключительность Zone Mail Hour 2.1.8
Использование FidoNet в деловых целях 1.3.6
Истории прецедентов 9.10, 10.3
Как получить узловой номер 2.2
Кодирование 2.1.4, 4.2
Коммерческие сообщения 1.3.6, 2.1.4, 4.2
Контроль и равновесие 1.2.8
Конфликты 9
Координатор Сети 1.2.3
процедуры 4
замена 5.7, 9.3
Координатор Зоны 1.2.5, 6
выборы 6.2
вотум недоверия 8.7
процедуры 6
смещение 6.2
отставка во время вотума недоверия 8.7.4
Корреспонденция (Mail) 1.2.3, 4.2
Летнее время 2.1.14
Mailer 2.2
Маленькие сети 5.3
Международный Координатор 1.4.1, 1.4.9, 7
Местные телефонные сети 1.3.2
Местные уставы 1.2, 3.3
Модем 2.2
Назначение координаторов 1.2.3, 1.2.4, 5.7, 6.1
National Mail Hour см. Zone Mail Hour
Независимый узел 4.2, 5.2
Незаконная корреспонденция 4.2
Незаконное поведение 2.1.1, 9.6
Некорректное поведение 1.3.5, 1.4.8, 2.1.1, 2.1.2, 2.1.4,
2.1.6, 2.1.7, 2.1.8, 2.1.11, 2.3, 4.2, 4.3, 5.2, 9, 10
Нелегальное распространение программного обеспечения 2.1.1
Неоправданные списки узлов 2.1.9
Неотвечающая система 2.3, 4.4, 5.5
Несоблюдение тайны переписки 2.1.6
Network Mail Hour см. Zone Mail Hour
Новые SysOp'ы 2.1.2, 3.6
NodeList 1.3.4, 2.2, 4.4, 5.5
доступность 3.1, 4.5, 5.8
изменения 4.4, 5.2
текущий 2.1.11
определение 1.3.4
формат 10.3
официальный 1.3.4
Номер обычного телефона 2.2
Обзор пересылаемого трафика 2.1.4
Общественный BBS 3.6
Объявление результатов голосования 8.2
Ограничение времени принятия решения 9.7
Ограничение срока рассмотрения жалобы 9.6
Оператор системы (SysOp) 1.2.1
Оправдание частного узла 2.1.9
Освобождения, расположение узла 1.3.2, 5.6
Оскорбительные сообщения 2.1.5
Основа 4.5
Отказ в общении 2.1.12, 4.3, 5.2, 9
Отпуск (каникулы) 2.3
Отставка Координатора Зоны 8.7.4
Пересмотр решений 3.7
Пересылка 2.1.4 - 2.1.7, 4.2
Подготовка материалов для FidoNews 1.3.1
Подчинение сверху вниз 1.4.9
Point'ы 1.2.1.2, 2.1.3
Получение узлового номера 2.2
Пользователь 1.2.1.1
Почтовый буфер 1.2.3.1, 4.4
Правила 9.1
Право голоса 8.3
Преимущества членства в сети 2.2
Прецедент 3.7, 9.10, 10.3
Протокол 2.1.8
Процедуры SysOp'а 2
Разрешение конфликтов 9
Распределение голосов 8.2
Ратификация 7.1
Региональный Координатор 1.2.4
процедуры 5
замена 6.1, 9.4
Регионы 1.2.4
Референдум 1.2.7, 8
Решение проблем 9
Сети с тремя уровнями 1.2.3.1
Сеть
преимущества 2.2
границы 1.3.2, 5.4
определение 1.2.3
создание 2.4, 5.3
почтовый буфер 1.2.3.1, 4.4
количество 2.2, 5.4
Системы, оставляемые без оператора 2.3
Соблюдение "почтовых" процедур 2.1.8, 2.1.10
Совет Координаторов Зон 1.2.6, 7.1
Стандарты (FTSC) 2.1.8, 2.4
Текущий NodeList 2.1.11
Телефонные сети 1.3.2, 5.6, 5.7
Точка происхождения 2.1.3
Традиция 3.7
Требование быть в NodeList'e 1.3.4, 2.1.2, 2.2
Узловые номера 4.3, 5.2
получение 2.2
Узлы
определение 1.2.1
не отвечающий 2.3
Уровни FidoNet 1.2, 1.4
Устав 3.1, 3.3, 4.5, 5.8
Файл различий 4.5, 5.8, 8.2
FidoNews 1.3.1
доступность 3.1, 4.5, 5.8
FTSC 2.1.8, 2.1.9, 2.4
Host-направленная корреспонденция 4.2
Цепочка аппеляции 9.5
Цепочка управления 1.2.8
Частичный NodeList 1.3.4
изменение 8
жалоба 2.1.6.1, 9
знакомство с 2.1.2, 2.2
местный 1.2, 3.3
Частная сеть 1.2.1.2
Частные сообщения 2.1.6
Частные узлы 2.1.9
Членство в управляемой структуре 3.5
Чрезмерно некорректное поведение 1.2.1.1, 1.3.5, 2.1.1, 2.1.2,
2.1.4, 2.1.6, 2.1.7, 2.1.8, 2.1.11, 2.3, 4.2, 4.3, 5.2,
9, 10
Шлюз 2.1.3
Язык 1.0