Кратко

  • RFC 3529 возвращал и нормальный результат, и XML-RPC fault внутри BEEP RPY; прикладная ошибка не превращалась в BEEP ERR.
  • Успешное разрешение имени, готовый канал, приватность и аутентификация партнёра не доказывали авторизацию метода, его успех или устойчивый эффект.

Главная граница RFC 3529 проходит не между запросом и ответом, а между двумя значениями ответа. Клиент помещал methodCall в BEEP MSG. Сервер помещал methodResponse в RPY. Даже если XML-RPC сообщал fault, внешний кадр оставался RPY.

На уровне BEEP это был положительный факт: одно-к-одному обмен получил связанный ответ. На уровне приложения содержание могло быть отрицательным. Система, которая считала каждый RPY успешной процедурой, записывала явно сообщённые отказы в колонку успеха.

До вызова работал отдельный автомат. Профиль начинал в состоянии boot. Инициатор отправлял bootmsg с ресурсом. Если сервер узнавал ресурс, он возвращал bootrpy, после чего состояние становилось ready. Неверная форма или неизвестный ресурс давали error либо ERR, а состояние не менялось. Это была ошибка запуска профиля, не ошибка метода.

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

Схема URI строила внешний маршрут. Authority xmlrpc.beep переходила в serverName, путь — в ресурс загрузки. При отсутствии явного порта клиент мог искать _xmlrpc-beep._tcp через SRV; если подходящей записи не было, он разрешал адрес и использовал назначенный порт. DNS выбирал назначение, но не доказывал работающий listener, совместимый профиль или результат метода.

xmlrpc.beeps требовал настроить BEEP-сессию на приватность до запуска XML-RPC-профиля. При TLS клиент сопоставлял authority с идентичностью сервера в сертификате. Это усиливало свидетельство о защищённом партнёре. Оно не создавало разрешение на метод и не подтверждало бизнес-условие или долговечную запись.

Минимальные средства безопасности датируют документ. Он называл DIGEST-MD5 и TLS с RSA/3DES. Позднейшие документы SASL и TLS изменили статус старых механизмов. Поэтому RFC 3529 полезен как история архитектурных границ, а не как современная инструкция по криптографии.

Регистрация также не была эксплуатационным свидетельством. Профиль BEEP, схемы xmlrpc.beep и xmlrpc.beeps, имя xmlrpc-beep и TCP 602 координировали символы. Реестр IANA не показывает, запущен ли код, идёт ли трафик и завершилась ли процедура.

В тот период BEEP предлагал многоканальную сессию, XML-RPC — простой формат вызова, а SOAP over BEEP — соседний вариант. BEEP Core определял управление профилями и кадрами, TCP mapping — транспорт и поток. Общая основа не объединяла доказательства: каждая ступень сохраняла собственный предмет.

Полная трасса вызова связывала исходную authority, выбранный адрес, идентичность партнёра, канал, ресурс, номер сообщения, RPY или ERR, затем нормальный результат либо fault. Для изменяющего состояние метода требовались ещё операция, версия, аудит или последующее чтение.

Повторные попытки превращали ошибку учёта в реальный риск. Разрыв до ответа оставлял выполнение неопределённым. Fault в RPY явно сообщал отрицательный результат, но без контракта метода не исключал частичный эффект. Повтор неидемпотентной операции мог удвоить изменение.

RFC 3529 имел статус Experimental. Он не доказывает распространение XML-RPC over BEEP. Зато он точно показывает: протокол может успешно доставить решение о неуспехе. Наблюдение должно хранить и доставку, и решение.

Sources