Кратко

  • RFC 1278 определил понятную человеку строку для selectors и одного или нескольких network addresses, но прямо исключил её из внутреннего хранения.
  • DNS-имя упрощало ввод формы RFC 1006; несколько IP должны были породить несколько адресов, а обратный показ закодированного значения — использовать IP-форму.
  • Макросы могли раскрываться рекурсивно и давать самую длинную замену, но зависеть от них запрещалось. Строка, словарь, DNS-наблюдение, материализованный набор и соединение были разными записями.

До соединения оставалось несколько решений

RFC 1278 вышел в ноябре 1991 года как Informational-документ. Он задавал строковое представление OSI Presentation Address.

Представляемый объект включал presentation selector, session selector, transport selector и набор network addresses. Selectors были строками октетов с разными символьными и числовыми формами. Одна Application Entity могла иметь несколько сетевых кандидатов.

В OSI Directory хранилось ASN.1-представление. Строка RFC 1278 была рассчитана на показ человеку, обычно системному администратору, и прямо не предназначалась для внутреннего хранения.

Это различие определяет жизненный цикл. Экран может использовать локальное сокращение, знакомое имя или доступный сейчас словарь. Сохранённое состояние должно оставаться объяснимым после исчезновения этих помощников. Если записать только поверхность, источник смысла останется вне записи.

Требования не отбрасывали сложные случаи. Формат должен был выражать любое допустимое значение, быть простым без selectors, поддерживать разные кодировки, TCP/IP, X.25(80), расширение и разумную компактность.

Список адресов не равнялся выбранному адресу

Грамматика ставила необязательные selectors перед network-address-list. В списке могло быть несколько элементов. Одна строка не превращала их в один действующий маршрут.

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

RFC 1277 описывал дальнейшую цепочку. Сначала Application Entity находили в OSI Directory и получали Presentation Address. Затем извлекали каждый Network Address и решали, применим ли он и каким образом. После этого устанавливали предпочтение. Только затем пытались соединиться с одним или несколькими адресами.

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

DNS-имя принадлежало моменту ввода

Форма RFC 1006 принимала точечный IP или DNS domain name. Имя предназначалось главным образом для удобного ввода.

Если оно возвращало несколько IP, следовало создать несколько network addresses. При обратном преобразовании закодированного адреса в строку требовалась IP-форма.

Так сохранялась история. Введённое имя — запись действия оператора. DNS-ответ — наблюдение в определённый момент. Созданный адресный набор — результат материализации. Новый DNS-запрос при чтении подменил бы исторический набор сегодняшним.

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

Но он не становился удостоверением. DNS не подтверждал соединение, IP literal не аутентифицировал endpoint. Нормализация лишь позволяла проверить происхождение значения.

Макрос был словарём, а не частью вечного адреса

Полные структурированные адреса получались длинными. RFC 1278 разрешал token перед = как замену общего префикса. Макрос мог ссылаться на другой и раскрываться рекурсивно. Для показа выбиралась самая длинная доступная подстановка.

Удобство переносило смысл в отдельный словарь. Изменение определения, отсутствие на другом host или расхождение промежуточной ступени могло дать другой полный адрес из того же видимого token.

Поэтому список предлагаемых стандартных макросов не был гарантией. RFC прямо говорил, что ни на один макрос нельзя полагаться. Рекомендованное слово интерфейса не становилось вечным registry contract.

Использование token, определение, цепочка раскрытия и итоговый адрес — четыре связанных состояния. Сохранить только token означает сделать словарь скрытой частью данных. Раскрытие перед сохранением фиксирует происхождение.

Общая строка не делала нижние сети едиными

RFC 1277 перечислял международные и частные X.25, изолированные OSI-сети, CLNP pilot, TCP/IP LAN с RFC 1006 и DARPA/NSF Internet. Ждать единой повсеместной OSI Network Service было непрактично.

Промежуточная схема кодировала сведения о нижней сети в Network Address. RFC 1278 давал разнородным формам общую читаемую грамматику. Единство записи не означало единства инфраструктуры или гарантированной достижимости.

Адрес мог быть допустимым, но непригодным для конкретного вызывающего узла. Пригодный кандидат мог иметь низкий приоритет. Попытка могла завершиться неудачей. Глобальная уникальность кодировки также не была authentication.

Источники и пределы

RFC 1278 подтверждает назначение строки, selectors, адресный список, DNS-ввод, генерацию нескольких адресов, IP-вывод, рекурсивные макросы и запрет зависимости. RFC 1277 используется только для контекста нижних сетей и цепочки lookup, извлечения, предпочтения и попытки.

Оба документа сообщают, что вопросы безопасности не обсуждаются. Они не доказывают надёжность макроса, стабильность DNS, разрешённость маршрута, аутентификацию endpoint или успех соединения. Они также не измеряют современное внедрение.

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