Кратко

  • RFC 3981 сознательно сделала ядро IRIS недостаточным само по себе: полезные запросы, результаты и классы сущностей задавались схемой типа реестра, а аутентификация и сеансы — отдельным прикладным транспортом.
  • Универсальный lookup не означал универсального поиска. Корректность XML, поддержка запроса, ресурсный лимит, право на результат и успешный переход по ссылке оставались разными состояниями.

Переход по ссылке легко принять за движение к ответу. Но в распределённом реестре следующий узел может вернуть нужную запись, другой материал или ничего. Если переходы образуют кольцо, клиент вообще возвращается к исходной точке. RFC 3981 поэтому требовала следовать каждой ссылке лишь однажды. Эта небольшая предосторожность раскрывает весь замысел IRIS: общий механизм переносит подсказку, но не превращает её в доказанный результат.

RFC 3981, опубликованная в январе 2005 года, определила основанное на XML ядро Internet Registry Information Service. Её карточка, перечень исправлений и история Datatracker подтверждают статус Standards Track и последующее обновление документом RFC 4992. Они не подтверждают число внедрений, доступность сервера сегодня или успех конкретного запроса.

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

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

Смысл находился в специальных схемах. RFC 3982 и её статусная запись определили тип реестра доменов. RFC 4698 определила тип реестра адресов. Разные документы были не заплатами к неполному стандарту, а предусмотренными контейнерами для разных моделей данных.

Особенно чётко граница проходила между lookup и поиском. Lookup сверяет одно дискретное значение с одним индексом. Общая операция lookupEntity указывает тип реестра, класс и имя сущности. Частичные значения, несколько индексов или несколько запросов к индексу уже образуют поиск. RFC 3981 не вводила общий язык таких поисков для всех типов IRIS: каждый тип объявлял возможности, осмысленные для его данных и эксплуатации.

В приложении это названо «соблазном универсального клиента». Универсальная программа могла выполнить lookup и грубо показать ответ. Чтобы удобно искать и толково представлять данные, ей всё равно требовалось знание предметной области. Единый язык запросов не устранял это знание — он заставлял переводить намерение пользователя в наименьший общий знаменатель.

У публичной службы была и оборотная сторона. Гибкий поиск частичных значений по нескольким индексам полезен опытному исследователю и одновременно удобен для злоупотребления ресурсами. Ради доступности оператор мог отключить дорогие варианты. Тогда общий язык обещал бы функцию, которая фактически работала не везде. RFC 3707 и её статус сохранили предшествующие требования CRISP к поиску, распределённым переходам, версиям и нарушителям. Это контекст решения, а не статистика атак или производительности.

Сами переходы имели разную доказательную силу. Entity reference сообщала о конкретном знании другой сущности. Search continuation лишь указывала, где поиск, возможно, продолжится. Получить её — не значит достичь адресата, подтвердить его окончательную полномочность или найти запись. Ограничение «следовать один раз» не исправляло данные, а не позволяло механизму превратить неопределённость в бесконечный цикл.

Ошибки разделяли другие причины отказа. invalidName относилась к синтаксису имени, invalidSearch — к смыслу поиска, queryNotSupported — к возможности сервера, limitExceeded — к допустимым ресурсам, nameNotFound — к отсутствию в выбранном индексе, permissionDenied — к полномочиям аутентифицированной стороны. Валидный XML мог нести бессмысленный, неподдерживаемый, слишком дорогой или неразрешённый вопрос.

Транспорт тоже не был навечно вшит в ядро. RFC 3983 и её статусная страница сопоставили IRIS с BEEP. Позднее RFC 4992 обновила RFC 3981 транспортом XPC поверх TCP, дробившим и конвейеризировавшим XML; статус, исправления и Datatracker фиксируют это изменение. Новая рамка или сеанс не приобретали право толковать доменный либо адресный реестр.

В реестре схем URI IANA по-прежнему числятся iris и связанные транспортные схемы, а IETF XML Registry сохраняет пространство iris1. Эти записи доказывают регистрацию протокольных имён, но не действующее развёртывание, широкое принятие или успешный ответ.

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

Sources