Кратко

  • RFC 1394 свёл названия территорий, телефонные коды, коды стран в telex, answerback и домены Internet в датированную таблицу. Строка описывала известное соответствие, а не работающую службу.
  • Документ не спрятал неопределённость: использовал разные отметки для двух видов отсутствующих данных, предупредил о возможных ошибках и принимал исправления по почте, email и telex.
  • Правильный код не доказывал делегирование DNS, наличие и допустимость линии, личность адресата, доставку или политическое признание страны.

Одна строка пересекала несколько инфраструктур

RFC 1394 вышел в январе 1993 года как практический указатель. Пользователь мог знать телефонный код места, но не его telex-answerback или домен Internet. Знакомое доменное окончание не обязательно подсказывало вход в публичную почтовую сеть.

В строках стояли название, телефонный код, код страны telex, answerback и Internet-домен. Там же появились коммерческие почтовые системы, территории, прежние названия и административные части. Таблица собрала в одном поисковом поле обозначения разных владельцев и технологий.

Соседство не сделало столбцы взаимозаменяемыми. Телефонный префикс обрабатывала система коммутации. Answerback жил в telex. Домен занимал место в иерархии имён. Название коммерческой почты могло указывать на провайдера, а не на территорию. Строка утверждала связь между значениями, но не была универсальной командой преобразования.

Пробелы получили явное значение

Инструкция RFC 1394 различала неизвестный телефонный код и прочую отсутствующую или неизвестную информацию разным числом чёрточек. Пустота не превращалась незаметно в один удобный ответ.

Сами связи были нерегулярны. У места могло быть несколько кодов telex. Старое и новое название могли вести к одному домену. Для территории мог быть указан Internet-суффикс, но не answerback. Бывшие государства, регионы и частные сети соседствовали ради поиска, а не потому, что им придали одинаковую правовую природу.

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

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

Две буквы не выполняли делегирование

RFC 920 ранее предложил английские двухбуквенные коды ISO 3166 для национальных доменов верхнего уровня. При этом он разделял допустимый ярлык, фактическое создание домена и публикацию сведений об администраторе и агенте. Наличие кода было только предпосылкой.

RFC 1034 описал техническую границу. Пространство DNS разделено на зоны. Сервер авторитетен лишь для ограниченной части дерева и может хранить неавторитетные данные других зон в кэше. Делегирование требует записей на границе родительской и дочерней зон и сведений, позволяющих добраться до серверов ребёнка.

Печать двух букв в RFC 1394 не создавала границу и записи. Таблица не назначала управляющего и не подтверждала ответы серверов. Делегирование следовало наблюдать у авторитетного родителя, а работоспособность — проверять в конкретный момент.

Действующая ccTLD также не обновляла соседние столбцы. Телефон, telex и DNS имели разных операторов и разные часы изменений.

Доменоподобная запись могла вести к шлюзу

Примечания о BITNET и UUCP показывали ещё одно различие. Имена вида System.BITNET и host.UUCP использовались внутри сообществ, но не были зарегистрированы в DNS. Почта из Internet нуждалась в преобразовании адреса и передаче через шлюз по принятой тогда схеме с процентным знаком.

Строка выглядела как домен, но её суффикс не разрешался обычным DNS. Практическое правило находилось у шлюза. Приём сообщения шлюзом доказывал только передачу посреднику; удалённая система, ящик и прочтение оставались следующими состояниями.

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

После кода оставались путь и разрешение

Перед длинной таблицей RFC 1394 предупредил: достижимость страны зависит от наличия соединения и от того, разрешено ли оно. Среди возможных причин отсутствия связи названы политические ограничения.

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

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

Успех тоже имел границу. Завершённый обмен показывал, что некоторый путь сработал один раз. Он не обязательно аутентифицировал человека на другом конце и не создавал вечного права повторять связь.

Включение в список не означало признание

RFC 1394 прямо отказался выносить суждение о действительности названия или существования страны. Старые и альтернативные названия собирались, чтобы пользователь с историческим термином нашёл нужную строку, а не ради дипломатического решения.

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

Более поздний RFC 1591 описал делегирование доменов верхнего уровня и обязанности назначенного управляющего. Для ccTLD требовались работающая инфраструктура, административный и технический контакты и служение местному и мировому сообществу Internet. Одновременно RFC 1591 заявил, что IANA не решает, что является страной; список ISO 3166 был выбран именно как отдельная процедура.

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

Тонкий справочник указывал на следующего свидетеля

RFC 1394 не обсуждал безопасность. Он не аутентифицировал строки, не подтверждал согласие и не гарантировал доставку. Это не делало список бесполезным, а запрещало выдавать его за удостоверение полномочий.

Документ превращал неопределённость в последовательность вопросов. Кто подтверждает код? Делегирован ли суффикс? Какой сервер отвечает авторитетно? Работает ли шлюз и маршрут? Допустимо ли использование? Приняла ли цель сообщение?

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