Кратко

  • RFC 3983 называла канал BEEP готовым после принятия профиля IRIS и создания канала. Это подтверждало способность обмениваться сообщениями объявленных типов, но само по себе не удостоверяло сервер или пользователя.
  • Тип реестра мог задать собственную проверку сервера, выбрать базовую TLS-процедуру или явно отказаться от неё. Шифрование, пользовательская идентичность, разрешение запроса и доверие к цели перехода требовали отдельных свидетельств.

Клиент отправляет MSG, сервер возвращает RPY. Транспорт сработал, но ответ может содержать отказ, неподдерживаемый запрос или иной результат, не дающий искомых данных. RFC 3983 не позволяла успеху рамки присвоить смысл содержимого. Готовность канала была условием разговора, а не решением о том, кто говорит и что ему разрешено.

Статусная карточка, исправления и история Datatracker фиксируют Standards Track документ января 2005 года. Он сопоставил Internet Registry Information Service с Blocks Extensible Exchange Protocol. Документарный статус не показывает масштаб внедрения или доступность службы сегодня.

BEEP был выбран ради готовых средств фрейминга, аутентификации, управления соединением и согласования, а также инструментов реализации. Специальный транспорт IRIS пришлось бы снабдить похожими возможностями. HTTP, по мнению авторов, создавал путаницу с Web-приложениями и неоднородной практикой TLS; прямой TCP не давал согласования для клиента, который по переходам посещал серверы с разными параметрами. Это мотивация проекта, не сравнительная телеметрия.

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

Обслуживать не значило раскрыть запись. В стандартном шаблоне клиент посылал корректный IRIS XML в BEEP MSG, сервер отвечал IRIS XML в RPY, а ERR передавал неисправности BEEP. Тип мог определить иной совместимый шаблон, но обязан был поддерживать стандартный для lookupEntity. Ядро IRIS и его статус оставляли на уровне реестра отказ в доступе, неподдерживаемый поиск и прочие ответы. Способность перенести запрос не определяла его исход.

Серверную идентичность проверяли отдельно. При TLS tuning profile каждый тип желательно определял собственный метод; иначе применялся базовый. Клиент указывал требуемую authority через BEEP serverName. Сервер представлял сертификат X.509 с этим именем. Затем клиент выполнял криптографическую проверку TLS и отдельно сопоставлял authority с dNSName или разрешёнными формами subjectDN.

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

Контрольный список типа делал выбор явным. Спецификация обязана была задать шаблон сообщений и определить метод TLS-аутентификации сервера, выбрать базовый либо объявить полное отсутствие серверной аутентификации. Поэтому правильно принятый профиль мог открыть готовый канал в системе, намеренно не проверявшей сервер.

Пользовательская идентичность оставалась ещё одним состоянием. RFC 3983 называла SASL DIGEST-MD5 и OTP для проверки пользователя без шифрования сеанса. Она отличала TLS только для шифрования от TLS с клиентским сертификатом, добавлявшим пользовательскую аутентификацию. Анонимный доступ мог означать отсутствие tuning profile или SASL ANONYMOUS. Шифрование не доказывало пользователя, проверенный сервер не доказывал пользователя, а проверенный пользователь не получал автоматически право на результат.

Такое сочетание следовало из BEEP. RFC 3080, её статус, исправления и Datatracker задали профили, каналы, сообщения и tuning. RFC 3081 и её статус перенесли BEEP на TCP. Изменение одного свойства сеанса не становилось свидетельством остальных.

Документы того времени очерчивают доступные механизмы. RFC 2246 и статус определили TLS 1.0; RFC 2222 и статусная карточка — упомянутую SASL. RFC 2817 со статусом и RFC 2818 со статусом описывали обсуждавшиеся способы HTTP/TLS. Наличие механизма не доказывает его правильное применение в конкретном канале.

Переходы создавали границу для секретов. IRIS штатно отправляла клиента к другим серверам. RFC 3983 предостерегала от передачи учётных данных недоверенной цели, не советовала SASL PLAIN и запрещала его до шифрования TCP-сеанса. Шифрование скрывало секрет в пути, но не делало получателя достойным доверия.

Позднее RFC 4992 и её статус добавили XPC поверх TCP и обновили ядро. Это свидетельствует о модульности транспорта, но не объясняет распространение или причины выбора.

Реестр схем URI IANA по-прежнему содержит iris.beep, а реестр параметров BEEP IANA — пространства профилей и tuning. Регистрация имени не подтверждает канал, личность, разрешение или полученный результат.

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

Sources