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


Присутствуют сообщения из эхоконференции R50.SYSOP с датами от 13 Jul 13 00:00:02 до 13 Jul 13 00:00:02, всего сообщений: 15065
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 8096 из 15065 ======================================= R50.SYSOP =
От   : Pavel Gulchouck                  2:463/68           07 Nov 17 07:43:06
Кому : Alex Barinov                                        07 Nov 17 07:43:06
Тема : кому стандарты не писаны?
FGHI : area://R50.SYSOP?msgid=2:463/68+5a01512e
На   : area://R50.SYSOP?msgid=2:5020/5452+5a00da27
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://R50.SYSOP?msgid=2:5020/715.1+5a01c416
==============================================================================
Hi Alex!

07 Nov 17, Alex Barinov ==> Pavel Gulchouck:

AB> 05 ноя 17 08:33, Pavel Gulchouck wrote to R50C:

RC>>> есть все основания его вынести по 2.1.10, а если узел доступен,
RC>>> какая разница в каком домене располагается FQDN?

PG>> Ткни пальцем, в каком месте эти строчки противоречат FTS-5001.

AB> Пардон, промахнулся. Имелся в виду FTS-5004, а именно:

AB> If the INA flag (or any of the protocol flags) of any node carries
AB> host name built from the FTN address using DDN or any other method,
AB> that node MUST be skipped and MUST NOT appear in resulting NS zone.
AB> In general, such names SHOULD NOT appear in the nodelist.

Спасибо.
Всё-таки Виссарионов не решился в стандарте явно прописать запрет на binkp.net и сделал это иносказательно. :)

Интересно было бы услышать его комментарии о том, какие он видит для этого причины (особенно для "MUST be skipped and MUST NOT appear in resulting NS zone").

Понятно, что в INA бессмысленно указывать адрес из DDN, и понятно, что при построении DDN нужно исключить INA, в которых указана эта зона (иначе будет CNAME на себя же). Но какой смысл в прочих ограничениях?
Например, если я при регистрации узла в binkp.net помимо адреса fFF.nNN.z2.binkp.net буду автоматически генерировать дополнительный адрес наподобие a2df.binkp.net (не из FTN-адреса, а, например, случайным образом) - по сути ничего не изменится, но стандарт будет соблюдён, и это дополнительное имя уже можно будет включать в нодлист. И какой в этом смысл?
Я бы, пожалуй, так и сделал, но не люблю делать то, в чём не вижу смысла. Правильнее было бы скорректировать стандарт, который создаёт такие помехи. Ну или понять, почему в стандарте написано именно так, т.е. почему такие добавочные адреса в binkp.net были бы полезны.

Ну а насчёт несоответствия стандарту - смотрим FTA-1006:

4. SHOULD NOT
-------------

  This phrase, or the phrase "NOT RECOMMENDED" mean that there may
  exist valid reasons in particular circumstances when the particular
  behavior is acceptable or even useful, but the full implications
  should be understood and the case carefully weighed before
  implementing any behavior described with this label.

PG>> Указанные в INA адреса вполне валидные, резолвятся, по ним даже
PG>> отвечает binkp. Что не так?

AB> Всё так. Именно об этом я и написал. :-)
AB> Фраза про формальное несоответствие стандарту была ответом на ыопрос, вынесенный в сабж.

Понятно, спасибо.

              Lucky carrier,
                           Паша
                           aka  gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5-b20160827
* Origin: Опыт - это то, что мы получаем вместо того, что хотели (2:463/68)

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