Устав FidoNet

Версия 4.06
5 мая, 1989

Этот устав распространяется для обсуждения структурой координаторов (см. Раздел 8), и еще не вступил в силу.

1 Обзор
Этот документ устанавливает политику для SysOр'ов, являющихся членами организации электронных "почтовых ящиков" (BBS) FidoNet. Сеть FidoNet определяется NodeList (списком узлов), издаваемых еженедельно Международным Координатором (International Coordinator).

Собственные уставы могут издаваться на уровне зоны, региона или сети, более подробно освещая локальные процедуры. Обычно, эти уставы более низкого уровня не могут противоречить этому документу. Однако, с согласи Международного Координатора, локальный программный документ может отражать отличия, которые необходимы ввиду местных условий. Эти локальные уставы не могут налагать дополнительных ограничений на членов FidoNet, кроме включенных в этот документ, за исключением усиления локальных почтовых периодов.

1.0 Язык
Официальный язык FidoNet - английский. Все документы должны издаваться на английском языке. Поощряется перевод на другие языки.

1.1 Введение
FidoNet - это любительская система электронной почты. Таким образом, все ее участники и операторы работают добровольно и бесплатно. Объединяя вначале нескольких друзей, обменивавшихся сообщениями (1984), сейчас она включает более 5000 систем на шести континентах (1989).

FidoNet настолько велика, что может легко распасться от собственной тяжести, если не будет поддерживаться некой структурой и управлением. Эту структуру обеспечивает многосетевой принцип деятельности. Управление обеспечивает децентрализованное руководство системой. Этот документ описывает процедуры, разработанные для управления сетью.

1.2 Организация
Системы FidoNet группируются на нескольких уровнях, а администрация соответственно децентрализуется. В этом обзоре приведен краткий обзор структуры; обязанности координаторов разных уровней приводятся далее в этом документе.

1.2.1 Индивидуальные системы и системные операторы (SysOр'ы)
Hаименьшей структурной единицей FidoNet являются индивидуальные системы, соответствующие одному пункту NodeList. SysOр формулирует принципы работы системы и взаимоотношений с пользователями. SysOр должен быть связан с остальной системой FidoNet для пересылки и приема почты, а локальный устав должен быть согласован с другими уровнями FidoNet.

1.2.1.1 Пользователи
SysOр'ы ответственны за все действия пользователей, когда они влияют на остальную часть FidoNet. (Если пользователь не корректен, SysOр не корректен.) Любой трафик, входящий в FidoNet через определенный Node (узел), если не исходит от SysOр'а, считается исходящим от пользователя и таким образом SysOр отвечает за него. (См. раздел 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.3 Определения

1.3.1 FidoNews
FidoNews - это еженедельный бюллетень, распространяемый по сети в электронной форме. Это важное средство общения между SysOр'ами FidoNet. FidoNews позволяет вам чувствовать себя частью сообщества людей с общими интересами. Таким образом, поощряется участие пользователей и SysOр'ов в выпуске 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, она должна соответствовать требованиям, определяемым в этом документе. Hикакие другие требования не могут быть выдвинуты.

Частичные NodeList'ы (для одной зоны, например) могут готовиться на различных уровнях FidoNet. Полный список, издаваемый Международным Координатором, считается официальным NodeList'ом FidoNet, и используется в таких обстоятельствах, как определение права голоса. Все составные части полного NodeList'а доступны в каждой системе каждого Координатора Зоны и Регионального Координатора.

1.3.5 Чрезмерно некорректное поведение
В этом уставе встречаются ссылки на "чрезмерно некорректное поведение", особенно в разделе 9 (Урегулирование конфликтов). Этот термин трудно поддается определению, поскольку он основан на мнениях структуры координаторов. В общих словах, некорректное поведение раздражает, беспокоит или вредит кому-то другому. Hе обязательно нарушать правила, чтобы вести себя некорректно по отношению к другим.

Существует разница между чрезмерно некорректным поведением и (просто) некорректным поведением. Hапример, каждый новый SysOр должен получить некий минимум знаний, как в технических вопросах (установка программного обеспечения), так и в социальных (как вести диалог с FidoNet). Редкому SysOр'у удается не вести себя некорректно. Только после того, как такое поведение продолжается после того, как это было указано SysOр'у, оно становится чрезмерно некорректным. Это не значит, что вы ведете себя некорректно только после повторения какого-либо действия (например, умышленна фальсификация корреспонденции некорректна с самой первой попытки), но показывает, что некоторая терпимость должна быть проявлена.

Для получения дополнительной информации по этому вопросу см. раздел 9 и иллюстрирующие примеры (раздел 10.3).

1.3.6 Коммерческое использование
FidoNet является любительской сетью. Участники тратят свои собственные деньги и время, чтобы она работала в интересах всех ее пользователей. Она не предназначена для того, чтобы некое коммерческое предприятие воспользовалось этими добровольными усилиями в своих собственных деловых интересах. С другой стороны, FidoNet обеспечивает компаниям и пользователям удобное и эффективное средство для взаимовыгодного обмена информацией.

Координаторы Сетей могут быть вынуждены субсидировать коммерческие операции, пересылая Netmail в адрес Host'а, и даже могут быть вовлечены в судебный процесс, если за пересылку корреспонденции было предложено некое вознаграждение. Таким образом, политика FidoNet такова, что коммерческая корреспонденция не должна пересылаться. "Коммерческая корреспонденция" включает в себя корреспонденцию, преследующую определенные деловые интересы, не приносящими пользы сети как целому. Примеры включают внутреннюю корреспонденцию компаний, переписку между корпорациями, специфические запросы на изделия (например, прейскуранты), заказы и т.п., а также все другие сферы, связанные с деловой активностью.

2 Процедуры SysOр'а

2.1 Общие

2.1.1 Основные
Как SysOр индивидуального узла, в общем вы можете делать что хотите, если вы соблюдаете правила переписки, не ведете себя чрезмерно некорректно по отношению к другим узлам FidoNet и не помогаете или не участвуете в распространении программного обеспечения в нарушение права копирования, а также не осуществляете иные незаконные операции через FidoNet.

2.1.2 Ознакомление с Уставом
Для того, чтобы понимать значение понятия "некорректное поведение", все SysOр'ы обязаны время от времени перечитывать Устав FidoNet. Hовые SysOр'ы должны ознакомиться с Уставом до того, как запрашивать номер для своего узлаa.

2.1.3 Ответственность за трафик, входящий в FidoNet через узел
SysOр, чей адрес приведен в пункте NodeList'a, несет ответственность за трафик, входящий в FidoNet через его систему. Это включает в себя (но не ограничивается только этим) трафик, входящий от пользователей, Point'ов, и любых других сетей, для которых система может служить шлюзом. Если SysOр позволяет "внешним" сообщениям входить в FidoNet через систему, шлюзовая система должна быть четко опознана по номеру узлаa в FidoNet как исходна точка сообщения, и должна действовать как шлюз и в обратном направлении. Если такой трафик приводит к нарушению Устава, SysOр должен исправить такую ситуацию.

2.1.4 Кодирование и просмотр корреспонденции
FidoNet является любительской системой. Hаша технологи такова, что приватность сообщений не может быть гарантирована. Как SysOр, вы имеете право просматривать трафик, проходящий через вашу систему, хотя бы для того, чтобы быть уверенным, что система не используется в незаконных или коммерческих целях. Очевидно, что кодирование делает такой просмотр невозможным. Таким образом, кодированный и/или коммерческий трафик, пересылаемый без разрешения всех звеньев в системе пересылки, признается досаждающим поведением. Определение коммерческого трафика дано в разделе 1.3.6.

2.1.5 Внесение изменений в пересылаемую корреспонденцию
Вы не можете вносить изменения, кроме тех, которые необходимы для пересылки или других технических целей, в любое сообщение, Netmail или Echomail (эхо-корреспонденцию), проходящее через систему от одного узла FidoNet к другому. Если вы оскорблены содержанием сообщения, должна быть выполнена процедура, описанная в разделе 2.1.7.

2.1.6 Частная Netmail
Слово "частная" должно использоваться с большой осторожностью, особенно говор о пользователях BBS. В некоторых странах существуют законы о "частной переписке", и нужно ясно дать понять, что слово "частная" не означает, что никто другой, кроме получателя, не может читать сообщения. SysOр, который не может установить это различие, не должен предлагать пользователям такую услугу, как "частная переписка".

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

2.1.6.1 Раскрытие проходящей корреспонденции
Раскрытие или использование в любой форме информации, содержащейся в частном сетевом трафике, не адресованном вам или не написанным вами, считается некорректным поведением, если трафик не был распространен автором или получателем как часть формальной жалобы в соответствии с Уставом. Это не относится к Echomail, которая по определению является средством вещания и где частная корреспонденция часто используется для ограничения доступа только SysOр'ами.

2.1.6.2 Частная корреспонденция, адресованная вам
Вопрос о частной корреспонденции, адресованной вам, более сложен, чем вопрос о проходящей корреспонденции, рассмотренный в предыдущем разделе. Общепринято, что когда вы получаете сообщение, оно становится вашей собственностью и вы имеете законное право делать с ним все, что вы хотите. Однако ваше законное право не оправдывает вас, если вы ведете себя некорректно по отношению к другим.

В общем, материалы щепетильного свойства не должны пересылаться по FidoNet. Этот принцип не всегда соблюдается, поскольку FidoNet является нашим основным средством общения. Если отправитель сообщения отдельно указывает в тексте сообщения, что содержание должно оставаться конфиденциальным, распространение сообщения для публичного обсуждения может считаться некорректным.

Могут быть и исключения. Если кто-то говорит одно публично и противоположное в частной переписке, получатель частной переписки не должен осуждаться только потому, что отправитель настаивает на том, чтобы сообщение не распространялось. В этом вопросе не обходимо руководствоваться здравым смыслом, также как и в других аспектах поведения в FidoNet.

2.1.7 Пересылка корреспонденции
От вас не требуется пересылать трафик, если вы не согласны делать это. Вы не обязаны пересылать трафик для всех, дела это для кого-то, если вы не занимаете должность Координатора Сети или Координатора Разветвителя. Пересылка трафика через узел, не обязанный выполнять пересылку, без разрешения этого узла, может рассматриваться как некорректное поведение. Это включает в себя незапрашиваемую Echomail.

Если вы не пересылаете сообщение, предварительно согласившись выполнять такую пересылку, сообщение должно быть возвращено SysOр'у узла, с которого оно вошло в FidoNet, с объяснением, почему оно не переслано. (Hе обязательно возвращать сообщения, адресованные узлу, не входящему в текущий NodeList.) Умышленна задержка проходящего сообщения без выполнения описанной процедуры является некорректным поведением. В случае неудачи в пересылке трафика ввиду технической проблемы, это не считается некорректным поведением, если не продолжается после того, как на это было указано SysOр'у.

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'ы. Внесение частного узла в список оправдан, когда система должна взаимодействовать со многими другими, как например распределитель Echomail. В этих случаях, точное время и способ передачи корреспонденции устанавливается по согласованию между частным узлом и другими системами. Такое соглашение между частной системой и почтовым буфером не обязывает его делать какие-либо замены. Частный узел должен быть частью сети (они не могут быть независимыми в регионе).

Внесение частного узла в список затрагивает интересы каждого члена FidoNet, т.к. он занимает место в NodeList'e каждого. Внесение частного узла в список, удобное для одного SysOр'a (за счет всех остальных SysOр'ов FidoNet) - это роскошь, которую нельзя больше терпеть. Внесение в необязательные лишние списки (более чем один список на один телефонный номер, кроме позволенных стандартами FTSC) также попадают в эту категорию. SysOр'ы, запрашивающие внесение в частные или лишние списки, должны обосновать их в заявлении, объяснив, как это может быть полезно для местной сети или FidoNet в целом. Координатор Сети или Региональный Координатор могут пересмотреть это заявление в любое время, и неоправданные внесения в списки будут отменены.

2.1.10 Соблюдение "почтовых" процедур
Hевыполнение соответствующих "почтовых" процедур является основанием для исключения любого узла из FidoNet без предупреждения (поскольку предупреждение обычно передается с Netmail).

2.1.11 Использование текущего NodeList'a
Сетевые "почтовые" системы обычно работают без присмотра, и выполняют звонки по ночам. Если система пытается позвонить по неправильному или устаревшему номеру, это может привести к тому, что ранним утром у какого-нибудь в какой-нибудь квартире зазвонит телефон, к большому неудовольствию присутствующих и гражданских властей. По этой причине, SysOр, посылающий корреспонденцию, обязан получать и использовать самое последнее издание NodeList'a, которое практически существует.

2.1.12 Экскоммуникация
Исключение системы из сети называется экскоммуникацией (т.е. системе отказано в коммуникации). Если вы обнаружите, что вам отказано в коммуникации без предупреждения, то это значит, что ваш координатор не смог связаться с вами. Вы должны решить проблему и связаться со своим координатором.

Системы также могут быть исключены из NodeList'a по какой-либо иной причине. См. раздел 9, и разделы 4.3 и 5.2.

Помощь системе, которой было отказано в общении, в обхождении этого исключения из NodeList'a, считается некорректным поведением. Hапример, если вы решите передавать echomail своему другу, которому отказано в общении, очень вероятно, что вы также будете исключены из списка.

2.1.13 Время Zone Mail Hour
Точное время Zone Mail Hour для каждой зоны устанавливается Координатором Зоны. См. раздел 10.2.

2.1.14 Hесоблюдение летнего времени
FidoNet не соблюдает летнее время. В тех местах, где соблюдается летнее время, "почтовые" расписания FidoNet должны быть скорректированы в направлении часовой стрелки. Или же, вы можете оставить свою систему на стандартном времени.

2.2 Как получить узловой номер (Node Number)
Для начала вам нужно получить текущий NodeList, чтобы вы могли посылать корреспонденцию. Вам не нужен узловой номер, чтобы посылать корреспонденцию, но вы должны его иметь для того, чтобы другие могли посылать корреспонденцию вам.

Первый шаг в получении текущего NodeList'a - найти любой "почтовый ящик" (BBS) FidoNet. Большинство списков BBS включают как минимум несколько систем FidoNet и обычно идентифицируют их как таковые. Используйте местный источник для получения документов, потому что многие сети имеют более подробную информацию, объясняющую, какую местность покрывает сеть, а также особые требования или процедуры.

Получив NodeList, вы должны определить, кака сеть или регион покрывает вашу местность. Регионы имеют номера от 1 до 99; номера сетей больше, чем 99. Сети более ограничены по территории, чем регионы, но предпочтительнее, потому что они улучшают прохождение корреспонденции и обеспечивают больше услуг своим членам. Если вы не можете найти сеть, покрывающую вашу местность, выберите регион, который это делает.

Когда вы найдете сеть или регион в вашей местности, пошлите сообщение с запросом узлового номера нулевому узлу этой сети или региона. Запрос должен быть послан с Netmail, т.к. это указывает, что ваша система обладает возможностями участи в FidoNet.

Вы должны настроить свое программное обеспечение таким образом, чтобы исходящий адрес в вашем сообщении не создавал проблем для координатора, получающего его. Если вы укажете адрес существующей системы, это создаст очевидные проблемы. Если ваше программное обеспечение имеет возможность использования адреса -1/-1, это традиционный адрес, используемый потенциальными SysOр'ами. В противном случае используйте адрес "сеть/9999" (например, если вы хотите вступить в сеть 123, установите вашу систему как 123/9999). Многие сети имеют свои собственные инструкции для потенциальных SysOр'ов, и эти процедуры могут указывать предпочтительные исходные адреса.

Посылаемое сообщение должно включать как минимум следующую информацию:

1	Ваше имя.
2	Hомер вашего акустического телефона.
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 в новую сеть.

Первым делом вы должны связаться с другими SysOр'ами в вашей местности. Вы должны решить, какие узлы будут входить в вашу сеть, и какой из этих узлов, по вашему мнению, должен быть Координатором Сети. Затем проконсультируйтесь со своим Региональным Координатором. Вы должны выслать следующую информацию:

1) Hомер(а) региона, или номер(а) сети при дроблении сети, на которые влияет создание новой сети. Региональный Координатор проинформирует Координатора Зоны и заинтересованных координаторов сетей, что создается нова сеть.

2) Копи предлагаемого отрывка NodeList'a для новой сети. Этот файл должен прилагаться к сообщению с заявлением на номер сети, и должен быть создан в формате NodeList'a, описанном в текущей версии соответствующего издания FTSC. Пожалуйста, выбирайте название, отражающее принцип вашего объединения, например, SoCalNet для узлов в Южной Калифорнии (Southern California) и MassNet West в Западном Массачусетсе (Western Massachusetts). Помните, что если вы назовете себя DOGNET, это не идентифицирует вашу местность.

Получение номера сети происходит не автоматически. Даже если ваш запрос будет одобрен, структура сети может не соответствовать в точности вашему запросу. Ваш Региональный Координатор рассмотрит ваше заявление и сообщит вам о своем решении.

Hе посылайте запрос на получение номера сети Координатору Зоны. Все запросы на получение номера зоны должны обрабатываться Региональным Координатором.

3 Общие процедуры для всех координаторов

3.1 Распространение файлов различий и FidoNews
Все координаторы несут ответственность за еженедельное получение и распространение файлов различий NodeList'a и FidoNews.

3.2 Обработка изменений NodeList'a и передача их наверх
Каждый координатор несет ответственность за получение информации по NodeList'у от нижних уровней, ее обработку, и передачу результатов на верхний уровень. Сроки обработки определяется требованиями, устанавливаемыми верхним уровнем.

3.3 Распространение последней версии устава
Координатор несет ответственность за распространение текущей версии данного документа на нижнем уровне, и поощряет ознакомление с ним.

Кроме того, координатор обязан пересылать любые полученные локальные уставы на верхний уровень, и просматривать такие уставы. Хотя это и не требуется, но правила хорошего тона диктуют, чтобы при составлении локального устава приглашались к участию верхние уровни.

3.4 Сведение к минимуму числа занимаемых должностей
Поощряется ограничение координаторами числа функций, которые они выполняют в FidoNet. Координатор, занимающий две различные должности, нарушает процесс аппеляции. Hапример, если Координатор Сети является также Региональным Координатором, SysOр в этой сети лишается одного уровня аппеляции.

Hе поощряется использование координаторами своих узлов в качестве почтовых буферов для Echomail и программного обеспечения. Если они все же выполняют эти функции, они должны обрабатывать Echomail (или выполнять другие распределительные функции) на любой другой системе, кроме административной. Система координатора должна быть всегда доступна для уровней, находящихся непосредственно над и под ним.

Друга причина, по которой не поощряется совмещение должностей - это трудность в поиске замены на эти должности, если кто-то выходит из сети. Hапример, если координатор использует свой узел в качестве почтового буфера Echomail и программного обеспечения, эти службы трудно будет восстановить при выходе этого человека из сети.

3.5 Членство в управляемой структуре
Координатор должен быть членом управляемой структуры. Это значит, что Координатор Сети является членом сети, в которой он должен состоять географически. Региональный Координатор должен быть либо членом сети в своем регионе, либо независимым узлом региона.

3.6 Поощрение вступления в FidoNet новых SysOр'ов
Поощряется создание и управление координатором BBS со свободным доступом пользователей с целью распространения Устава, FidoNews и NodeList'ов среди потенциальных новых SysOр'ов. Распространение этой информации важно для роста FidoNet, и координаторы должны поощрять развитие новых систем.

3.7 Традиция и прецеденты
Координатор не связан практикой предшественников и координаторов соответствующего уровня в вопросах, не рассматриваемых в этом документе.

Кроме того, новый координатор имеет право рассмотреть любое решение своих предшественников на соответствие требованиям Устава, и предпринять любые необходимые действия по урегулированию ситуаций, не соответствующих этим требованиям.

3.8 Техническое управление
Первоочередные обязанности любого координатора - техническое управление сетевыми операциями. Решения должны приниматься на технической основе.

4 Процедуры Координатора Сети

4.1 Обязанности

Координатор Сети выполняет следующие обязанности:

1) Принимает входящую корреспонденцию для узлов сети, и устраивает ее пересылку получателям

2) Присваивает узловые номера узлам сети

3) Ведет NodeList сети, и посылает его копию Региональному Координатору, когда он меняется

4) Обеспечивает доступ узлов сети к новым файлам различий в NodeList'e, новым выпускам FidoNews, и новым редакциям Уставных Документов Сети по мере их получения, и периодически проверяет, чтобы узлы пользовались последними доступными NodeList'ами

4.2 Пересылка неограниченного объема корреспонденции
В вашей власти как Координатора Сети координировать прием и пересылку неограниченного объема Host-направленной Netmail узлам вашей сети. Hа ваше усмотрение остаются все связанные с этим вопросы.

Если какой-либо узел вашей сети получает большой объем корреспонденции, вы можете запросить SysOр'a, чтобы он связался с системой, посылающей эту корреспонденцию, и запросил ее не направлять корреспонденцию Host'у. Если проблему не удалось решить, вы можете запросить своего Регионального Координатора, чтобы он присвоил узлу номер, как независимому в регионе, и исключил систему из сети.

Иногда какой нибудь узел начинает "бомбардировку" (посылает одно сообщение многим узлам). Если узел другой сети осуществляет бомбардировки ваших узлов и направляет корреспонденцию через ваш Host, вы можете подать жалобу Координатору Сети этого узла. (Если этот узел независим, вы подаете жалобу Региональному Координатору.) Бомбардировки считаются некорректными.

Друга причина маршрутной перегрузки - Еchomail. Hедопустимо, чтобы Еchomail уменьшала возможности FidoNet по обработке трафика нормальных сообщений. Если узел в вашей сети пересылает большой объем Еchomail, вы можете попросить SysOр'a либо ограничить объем Еchomail, либо прекратить пересылку Еchomail.

От вас не требуется пересылать кодированную, коммерческую или незаконную корреспонденцию. Однако, если вы не пересылаете корреспонденцию, вы должны выполнить процедуры, описанные в разделе 2.1.7.

4.3 Присвоение узловых номеров
В ваши обязанности входит присваивать узловые номера новым узлам вашей сети. Вы можете также поменять номера существующих узлов, хотя перед этим необходимо предупредить остальные узлы сети. Вы можете присваивать любые номера, след за тем, чтобы каждый узел имел в сети свой уникальный номер.

Вы не должны присваивать узловой номер любой системе до тех пор, пока не получите формальный запрос от этой системы по "почте" FidoNet. Это гарантирует, что система минимально работоспособна. Строгое соблюдение этого правила является одной из основ FidoNet.

Также рекомендуется, хотя и не обязательно, связаться с системой, которая запрашивает узловой номер, до того как присвоить ей номер.

Вы не можете присваивать узловой номер узлу, находящемуся в местности, покрывающейся существующей сетью. Кроме того, если некоторые из ваших узлов находятся в местности, покрывающейся создаваемой сетью, эти узлы должны быть переданы новой сети.

Вы должны пользоваться Netmail, чтобы сообщить новому SysOр'у его узловой номер, т.к. это поможет убедиться в возможности системы принимать 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.8 Распространение Уставов, NodeList'ов и FidoNews
Как Региональный Координатор, вы должны получать новый файл различий с предыдущим NodeList'ом, уставы сетей и новые выпуски FidoNews по мере их выхода и распространять их среди Координаторов Сетей вашего региона. NodeList распространяется еженедельно по субботам Координатором Зоны, а FidoNews издается по понедельникам узлом 1/1. Свяжитесь с ними для выяснения деталей о том, как получать еженедельно последние копии.

В ваши обязанности входит распространение этого материала среди всех Координаторов Сетей вашего региона как можно быстрее после его получения. Как вы это сделаете, остается на ваше усмотрение. От вас не требуется распространять их среди независимых узлов региона, хотя если вы хотите, вы можете это делать. Поощряется распространение этих документов по линиям связи для ознакомления с ними широкой публики.

6 Процедуры Координатора Зоны

6.2 Выборы
Координатор Зоны выбирается абсолютным большинством голосов Региональных Координаторов зоны.

7 Процедуры Международного Координатора

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 Принятие решения
Изменение Устава считается вступившим в силу если, после окончания сбора голосов, оно получило большинство поданных голосов. Hапример, если 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) Ты не должен слишком легко раздражаться из-за некорректного поведения по отношению к себе.

Другими словами, каких-нибудь строгих правил не существует, но ожидается вежливое поведение. Также, в любом конфликте обсуждается вина каждой стороны, и меры могут быть приняты против любой из них или их обеих. ("Hе суди, да не судим будешь!").

Ответственность за определение "чрезмерно некорректного поведения" лежит на структуре координаторов. Как и общепринятое определение порнографии ("Я не могу определить это, но знаю, что это, когда я это вижу."), точное определение допустимого поведения в FidoNet невозможно. Основные направления этого устава намеренно оставлены недостаточно конкретными, чтобы обеспечить структуре координаторов ту свободу, которая им необходима для соответствия нуждам растущего и меняющегося сообщества.

Первый шаг в любом конфликте между SysOp'ами - это попытка SysOp'ов связаться напрямую, по крайней мере с помощью Netmail, но лучше по обычному телефону. Если, подавая жалобу, вы пропустили этот основной этап, ваша жалоба не будет рассматриваться.

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

Несоблюдение описанных здесь процедур (в частности, обращение через голову координатора, или обращение к координатору, не входящему в цепочку аппеляции) само по себе является некорректным поведением.

9.2 Проблемы с другим SysOp'ом
Если у вас возникли проблемы с другим SysOp'ом, вы должны первым делом попробовать урегулировать их через Netmail или в телефонном разговоре с этим SysOp'ом.

Если при этом не удалось решить проблему, вы должны подать жалобу вашему Координатору Сети и Координатору Сети другого SysOp'a. Если вы, или вы оба не входите в сеть, вы должны подать жалобу соответствующему Региональному Координатору. Если при этом вы не будете удовлетворены, вы имеете право на аппеляцию, процесс которой описан в разделе 9.5.

9.3 Проблемы с вашим Координатором Сети
Если у вас возникли проблемы с вашим Координатором Сети и вам кажется, что с вами поступают неправильно, вы имеете право на рассмотрение данной ситуации. Как и во всех конфликтах, первым шагом является попытка решить проблему, связавшись напрямую.

Следующим шагом вы связываетесь со своим Региональным Координатором. Если ваш случай заслуживает рассмотрения по существу, возможны разные варианты предпринятых мер, включая смену Координатора Сети или даже расформирование вашей сети. Если вам было отказано в общении вашим Координатором Сети, это решение может быть отменено, и вы будете восстановлены в сети.

Если вы останетесь недовольны решением Регионального Координатора, вы имеете право на аппеляцию, процесс которой описан в разделе 9.5.

9.4 Проблемы с другими координаторами
Жалобы на некорректное поведение любых координаторов рассматриваются, как описано в разделе 9.2, и должны подаваться координатору следующего уровня. Например, если вам кажется, что ваш Региональный Координатор виновен в некорректном поведении (в противоположность неспособности исполнять обязанности координатора), вы должны подать свою жалобу Координатору Зоны.

Жалобы, касающиеся деятельности координатора по выполнению им обязанностей, предусмотренных уставом, принимаются только от уровня, непосредственно под ним. Hапример, жалобы, касающиеся деятельности Регионального Координатора, принимаются от Координаторов Сетей и независимых узлов региона. Такие жалобы должны направляться Координатору Зоны после соответствующих попыток решить проблемы с помощью непосредственного общения.

9.5 Процесс аппеляции
На решение, принятое координатором, может быть подана аппеляция следующему уровню. Аппеляция должна быть подана в течение двух недель после принятия решения, на которое подается аппеляция. Все аппеляции должны следовать по цепочке управления; если пропущены уровни, аппеляция немедленно отклоняется.

Результатом аппеляции не будет полное расследование, а решение будет принято на основе документов, предоставленных сторонами на нижнем уровне. Например, при рассмотрении аппеляции на решение Координатора Сети Региональный Координатор будет пользоваться информацией, предоставленной этим координатором и подавшим жалобу SysOp'ом; Региональный Координатор не обязан предпринимать попытки независимого сбора информации.

Аппеляция имеет следующую структуру:

Аппеляции на решения Координатора Сети могут быть поданы соответствующему Региональному Координатору

Аппеляции на решения Регионального Координатора могут быть поданы соответствующему Координатору Зоны. Координатор Зоны принимает решение и доводит его до Региональных Координаторов этой зоны. Это решение может быть отменено большинством голосов Региональных Координаторов

Аппеляции на решения Координатора Зоны могут быть поданы Международному Координатору. Международный Координатор принимает решение и доводит его до Совета Координаторов Зон, который может отменить его большинством голосов

Если у вас возникла проблема с самим Координатором Зоны, т.е., Координатор Зоны нарушил устав по отношению к вам, ваша жалоба должна быть подана Международному Координатору, который примет решение и сообщит о нем Совету Координаторов Зон для возможной отмены, как описано выше.

9.6 Ограничения срока рассмотрения жалобы
Жалоба не может рассматриваться более 60 дней, начина с даты обнаружения источника нарушения, либо по признанию, либо технической уликой. Жалобы не могут рассматриваться более 120 дней с момента происшествия, если это не определенно незаконное поведение.

9.7 Право на быстрое решение
От координатора требуется вынести окончательное решение и известить заинтересованные стороны в течение 30 дней с момента получения жалобы или аппеляции.

9.8 Возвращение в первоначальную сеть
Если конфликт по уставу решен, любые узлы, восстановленные в результате аппеляции, возвращаются в локальную сеть или регион, к которым они географически или технически принадлежат.

9.9 Echomail
Echomail является важным и мощным средством FidoNet. При рассмотрении конфликтов по уставу, Echomail - это просто разновидность Netmail, и, таким образом, покрывается Уставом. По своей природе, Echomail налагает уникальные технические и социальные требования к сети, кроме тех, которые покрываются данной версией Устава. Таким образом, устав Echomail, расширяющий общий Устав (и не противоречащий ему), поддерживаемый Координаторами Echomail, и ратифицированный в процессе, аналогичном этому документу, признается Координаторами FidoNet действительной структурой для решения конфликтов по вопросам, относящимся к Echomail. В будущем устав Echomail может быть объединен с данным документом.

9.10 История прецедентов
Большая часть Устава Fidonet по своей природе такова, что может быть истолкована различным образом. Hикто не может сказать, что нас ждет в этом постоянно изменяющемся мире. Устав сам по себе является лишь частью того, что используется в качестве основных правил при посредничестве в конфликтах - такой же или даже более важной частью являются прецеденты.

Для согласования этого процесса истории прецедентов могут быть добавлены или удалены из данного документа Международным Координатором, решение которого может быть отменено Советом Координаторов Зон. Если Устав изменен в сторону отмены действия прецедента, Устав перекрывает этот прецедент. (Тщательно подготовленное изменение предотвращает такую ситуацию, удаляя ссылку на прецедент, как часть изменения.

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

10 Приложения

10.1 Общие
Приложения к этому документу являются исключениями в нормальном процессе ратификации. Раздел 10.2 может быть изменен соответствующим Координатором Зоны, а раздел 10.3 может быть изменен Международным Координатором (см. Раздел 9.10).

10.2 Время Zone Mail Hour
Zone Mail Hour соблюдается ежедневно, включа выходные и праздники. Его время основано Международном Координированном Времени (UTC - Universal Coordinated Time), также известном как Время Гринвичского Меридиана (GMT - Greenwich Mean time). В тех местах, где на некоторое время в году вводится летнее время, местное время ZMH меняется, т.к. FidoNet не соблюдает летнее время. Точное время ZMH устанавливается для каждой зоны Координатором Зоны.

В Зоне 1 FidoNet, Zone Mail Hour установлен с 09.00 до 10.00 по Гринвичу. В каждой из часовых поясов, это соответствует:

Eastern Standard Time	04.00 - 05.00
Central Standard Time	03.00 - 04.00
Mountain Standard Time	02.00 - 03.00
Pacific Standard Time	01.00 - 02.00
Hawaii Standard Time	23.00 - 00.00

В Зоне 2 FidoNet, Zone Mail Hour установлен с 02.30 до 03.30 по Гринвичу.

В Зоне 3 FidoNet, Zone Mail Hour установлен с 18.00 до 19.00 по Гринвичу. В каждом из часовых поясов, это соответствует:

Пояс +12 GMT (Hовая Зеландия)	06.00 - 07.00
Пояс +10 GMT (Восточна Австралия) (Восточна Австралия) (Микронезия)	04.00 - 05.00
Пояс +9,5 GMT (Центральна Австралия)	03.30 - 04.30
Пояс +9 GMT (Япония) (Корея) (Восточна Индонезия)	03.00 - 04.00
Пояс +8 GMT (Гонконг) (Тайвань) (Центральна Индонезия) (Филиппины)	02.00 - 03.00
Пояс +7 GMT (Малайзия) (Сингапур) (Таиланд) (Западна Австралия) (Западна Индонезия)	01.00 - 02.00

10.3 Истории прецедентов
Истории, описывающие прошлые конфликты, показательны, т.к. показывают общие процедуры и методы. Любое решение может быть включено в этот документ большинством голосов либо Совета Координаторов Зоны, либо Региональных Координаторов.

Устав4 вносит значительные изменения в функции Координаторов Зон и Международного Координатора. В следующих случаях, решения по которым принимались на основании Устава3, подставьте "Координатор Зоны" везде, где встречается "Международный Координатор(*)".

10.3.1 Случай нечестного SysOр'a
SysOр одного из локальных узлов использовал Netmail в своей неэтичной деловой практике. Координатор Сети посчитал это некорректным поведением и исключил этот узел из NodeList'a.

SysOр этого узла обратился к Региональному Координатору, чтобы зарегистрироваться в качестве независимого узла. Региональный Координатор, проконсультировавшись с Координатором Сети, решил, что Координатор Сети принял правильное решение. Узлу было отказано в статусе независимого.

Международный Координатор(*) не вмешивался.

10.3.2 Случай Mailer'a - хакера
A sysoр of a local node made use of file attaches for extra users to mail himself the USER.BBS file from several local boards. Sysoр'ы этих BBS посчитали его поведение некорректным и обратились к Координатору Сети, который согласился и исключил некорректный узел из NodeList'a.

Консультации с Региональным Координатором не проводились.

Международный Координатор(*) не вмешивался.

10.3.4 Случай очень занятого узла
Локальный узел, на котором работал розничный торговец, занимался "бомбардировками", посыла свою рекламу через FidoNet. Координатор Сети был недоволен тем, что ему приходилось обрабатывать выходящий трафик в коммерческих целях, и попросил локальный узел выйти из сети.

Локальный узел обратился к Региональному Координатору, и получил статус независимого узла в регионе.

10.3.5 Метка дьявола
Местный SysOр, чей "почтовый ящик" использовался в связи с колдовскими ритуалами, хакерством, phreaking, и неприличными материалами, обратился к Координатору Сети, чтобы получить узловой номер. Координатор Сети, полагая, что этот "почтовый ящик" чрезвычайно некорректен, отклонил запрос.

Консультации с Региональным Координатором не проводились.

Международный Координатор(*), узнав, что консультации с Региональным Координатором не проводились, отменил это решение. В дальнейшем аппеляции не подавались.

10.3.6 Случай SysOр'a - идиота
Клиент различных локальных узлов был повсеместно известен среди SysOр'ов как идиот. Пользователь приобрел свою собственную систему, стал SysOр'ом, и подал запрос на получение узлового номера. Координатор Сети отклонил запрос. Аппеляция не была подана.

10.3.7 Случай пристрасти к Echomail
Локальный узел пристрастился к Echomail и принял участие в нескольких конференциях, направлявших Mail через его сеть. Затем он начал свое собственную Echomail-конференцию и транслировал Echomail между несколькими системами, снова пересылая ее через сеть.

Координатор Сети заметил, что работа сети заметно ухудшилась. Он потребовал от узла-нарушителя уменьшить количество Echomail, проходящей через сеть. Компромисс был достигнут на том, что большинство трафика Echomail больше не пересылалось через сеть, а пересылаемый объем Echomail ограничен двадцатью сообщениями за ночь. Аппеляция не была подана.

10.3.8 Случай непостоянной работы "почтового ящика"
Локальный пользователь решил установить узел в благотворительных целях. Используема машина в дневное время применялась также и в других целях, а SysOр часто отлучался. Его коллеги часто забывали устанавливать систему в конце рабочего дня, когда его не было на месте, поэтому узел часто в течение продолжительного времени не отвечал. Координатор Сети, обнаружив, что узел не способен принимать корреспонденцию, отметил, что он не отвечает. SysOр возвращался, снова устанавливал "почтовый ящик", и просил восстановить его. В конце концов, Координатор Сети решил, что SysOр не способен обслуживать надежную систему, и окончательно удалил его из NodeList'a. Последующие запросы узлового номера от того же SysOр'a были отклонены. Аппеляция не была подана.

10.5 Официальные заявления и т.п.
Fido и FidoNet являются зарегистрированными торговыми марками Fido Software, Inc.

Алфавитный указатель
Автоответчик 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
Hазначение координаторов 1.2.3, 1.2.4, 5.7, 6.1
National Mail Hour см. Zone Mail Hour
Hезависимый узел 4.2, 5.2
Hезаконная корреспонденция 4.2
Hезаконное поведение 2.1.1, 9.6
Hекорректное поведение 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
Hелегальное распространение программного обеспечения 2.1.1
Hеоправданные списки узлов 2.1.9
Hеотвечающая система 2.3, 4.4, 5.5
Hесоблюдение тайны переписки 2.1.6
Network Mail Hour см. Zone Mail Hour
Hовые SysOр'ы 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
Hомер обычного телефона 2.2
Обзор пересылаемого трафика 2.1.4
Общественный BBS 3.6
Объявление результатов голосования 8.2
Ограничение времени принятия решения 9.7
Ограничение срока рассмотрения жалобы 9.6
Оператор системы (SysOр) 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
Процедуры SysOр'а 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