Кратко

  • RFC 1277 кодировала сведения, необходимые для попытки соединения OSI через TCP/IP или некоторые сети X.25, когда сетевой службы OSI не было.
  • Глобально уникальный формат мог указывать сеть и нести параметры транспорта; само назначение адреса не доказывало ни его маршрутизируемость, ни ответ службы.

Каталог OSI мог вернуть адрес представления, но модель предполагала, что сетевые адреса предоставляет служба сети OSI. В пилотных средах это условие выполнялось не всегда. Приложения OSI работали также в Интернете, в публичных и частных сетях X.25, а также в изолированных сетях. Если для каждого эксперимента требовалось ждать глобальную сетевую службу OSI, каталог оказался бы бесполезен именно там, где его испытывали.

RFC 1277 решала только один этап цепочки соединения. Приложение запрашивало адрес представления; затем клиенту следовало извлечь каждый сетевой адрес, определить, можно ли и как его использовать, расставить предпочтения и попытаться подключиться. Меморандум сосредоточился на извлечении. Он описал кодировки, из которых клиент мог вывести сведения о нижних уровнях, отдельно не возвращавшиеся каталогом. RFC не определяла весь процесс соединения, обнаружение маршрута или успешный обмен данными приложения.

Это разделение было важно, поскольку адрес выполнял несколько ролей. В международном X.25 адрес формы X.121 мог идентифицировать DTE и, при подходящих условиях, поддерживать маршрут через публичную сеть X.25. Но идентификатор назначения не обязательно отражал топологию: конечная система не могла считать, что каждая глобально выделенная часть адреса описывает путь. RFC 1277 подчёркивала, что IDP нужен прежде всего для назначения и что в принципе пользователь не может вывести из него маршрутизацию.

Рекомендация трактовать некоторые формы X.121 как маршруты зависела от используемой службы и формата; частные средства могли обнаружить более предпочтительные пути.

Для сетей TCP/IP, переносящих службу транспортного уровня OSI по RFC 1006, RFC 1277 использовала другую кодировку. Сначала в сетевой части шёл 12-значный адрес IPv4, затем могли следовать пятизначный номер порта и пятизначное значение набора транспортов. Последнее представляло собой 16-битное слово флагов: значения обозначали TCP и UDP; если поле отсутствовало или равнялось нулю, по умолчанию выбирался TCP. В примере RFC закодированы 10.0.0.6, порт 9 и UDP. Это правило интерпретации для попытки соединения, а не доказательство того, что адрес актуален, достижим, прослушивается или разрешает доступ.

Новый формат требовалось отличать и от адреса, применяемого настоящей сетевой службой OSI. RFC 1277 выбрала AFI Telex, поскольку он оставлял более широкую доменную часть и снижал риск путаницы с другими вариантами адресов. Короткий префикс разделял подсети, остальная часть содержала специфичные для сети данные. За компактную самодокументируемую структуру пришлось платить длинной десятичной записью. В меморандуме отмечено, что двоичная форма ASN.1 была бы привлекательной, но не помещалась в доступное адресное пространство.

Это был инженерный компромисс переходного периода, а не вечный закон адресации. Историческая заметка RFC сообщает, что подход реализовали и проверили на практике в проектах THORN и ISODE/QUIPU. Это подтверждает работоспособность предложения в тех проектах, но не массовое внедрение. Позднее RFC 1278 описала текстовое представление адресов представления для показа людям и прямо исключила внутреннее хранение; это другой уровень по сравнению с назначением и кодированием нижних уровней в RFC 1277. Рекомендации NSAP в RFC 1237 касались сетевой службы OSI без установления соединения, а не случая не-OSI, который решала RFC 1277.

Урок RFC 1277 уже, чем утверждение «адрес показывает, как подключиться». Запись каталога может содержать структуру, позволяющую клиенту выбрать интерпретацию нижних уровней. Но всё равно нужны действующий маршрут, совместимый слушающий узел, успешный обмен на транспортном уровне и ответ приложения. Если считать закодированное значение доказательством всех четырёх, назначение, интерпретация, достижимость и служба сливаются в одно утверждение, которого меморандум никогда не делал.

Источники: RFC 1277; RFC 1006; RFC 1278; RFC 1237.