Кратко

  • RFC 5365 описывает SIP-сервис pager-mode сообщений: клиент передаёт плоский список URI и полезную нагрузку в одном MESSAGE, а специализированный B2BUA создаёт новый MESSAGE для каждого адресата.
  • recipient-list-history строится по правилам RFC 5364 с учётом To, Cc, Bcc и анонимности. Это не копия исходного списка, а представление для конкретного получателя, которое рекомендуется зашифровать его открытым ключом.
  • Управление должно отдельно доказывать версию входного списка, правила раскрытия, состав каждой видимой истории, её аудиторию, сохранность payload, новую транзакцию, идентичность, realm учётных данных, downstream-ответ и доставку. Один правильный компонент не оправдывает остальные.

Исходный список был планом действий, а не публичным документом

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

Клиент использует multipart MESSAGE и объявляет recipient-list-message. Сервис разбирает список по RFC 4826, канонизирует адресатов и создаёт отдельный запрос к каждому. Уже на этом этапе список является исполняемым входом, а не только приложением для чтения.

Не всякий участник списка вправе видеть всех остальных. To и Cc обычно несут один смысл раскрытия, Bcc — другой, а анонимизированная запись требует ещё одного режима. Поэтому переслать исходный XML каждому было бы не нейтральностью, а самостоятельным раскрытием.

RFC 5365 использует recipient-list-history как специально построенное тело. Подробные правила принадлежат RFC 5364. Архитектурный вывод состоит в том, что B2BUA создаёт новый объект с новой аудиторией.

Представление зависело от получателя

История помогает функциям вроде reply-to-all. Но удобство появляется только после применения политики. Сервис решает, какие неанонимные To и Cc показать, какие Bcc скрыть и как представить анонимные элементы.

В результате Боб и Кэрол могут получить одинаковый текст сообщения и разные истории. Это не рассинхронизация, если различие следует правилам раскрытия. Ошибкой было бы считать один общий hash истории доказательством для всех адресатов.

Для каждой версии нужно сохранить входной список, версию правил, получателя, включённые и исключённые элементы, причину, hash созданного тела и способ защиты. Такой набор позволяет доказать не только то, что сервис что-то скрыл, но и что он не скрыл лишнего.

Рекомендация зашифровать историю открытым ключом получателя подчёркивает персональную аудиторию. Даже правильно сформированное представление может быть неправильно защищено; эти решения требуют отдельных квитанций.

Полезная нагрузка сохранялась на другом уровне

Оставшиеся части сообщения — например текст или изображение — сервис обычно копирует. Однако multipart может также содержать security body, зашифрованный для самого сервиса списка. Получатель не является его криптографической аудиторией, поэтому такое тело нельзя копировать наружу.

После удаления списка и служебного security body может остаться одна часть. Тогда RFC требует убрать оболочку multipart/mixed. Полный набор байтов изменяется, хотя предназначенный пользователю смысл сохраняется.

Проверять нужно по частям: media type, disposition, hash, аудитория, разрешённое преобразование, причина добавления и удаления. Требование равенства всего пакета отвергнет правильную реконструкцию. Сравнение только отображённого текста пропустит вложения и структуру защиты.

История адресатов — добавленная часть, а не продолжение payload. Её правильность не выводится из hash текста, как правильность текста не выводится из состава истории.

Новая история находилась в новой транзакции

Сервис действует как специализированный B2BUA. Он завершает входную сторону как сервер и начинает выходную как клиент. Для каждого адресата должен быть новый To, новый Call-ID и отдельный счётчик CSeq; также инициализируется Max-Forwards и добавляется Via сервиса.

Request-URI теперь указывает не на сервис списка, а на конкретную цель. Call-ID и CSeq идентифицируют и упорядочивают новое взаимодействие; Via ведёт ответы; Max-Forwards задаёт новый предел циклов.

Внутренняя execution ID должна связывать родительский запрос, канонический набор, позицию адресата и попытки. Входной Call-ID не может притворяться идентификатором всех детей, а выходные Call-ID не должны терять общую причину.

Именно эта структура позволяет повторить Кэрол, не повторяя Боба. Общая история входа не превращает независимые транзакции в одну судьбу.

Отображаемый отправитель не раскрывал источник всей власти

Выходной From должен сохранять входное значение с учётом Privacy. From tag не копируется как знак продолжения того же dialog endpoint. Совмещённый privacy service имеет приоритет.

Получатель видит Alice как автора разговора, хотя запрос создал сервис. Это полезная пользовательская непрерывность, но не сквозная аутентификация.

P-Asserted-Identity передаётся, когда пришла от доверенного источника и первый выходной hop тоже доверенный. При недоверенном hop и запрошенной Privacy утверждение не должно выходить. Сервис может сам создать PAI, если аутентифицировал пользователя и умеет сопоставить его SIP или SIPS URI.

Нужны источник утверждения, способ аутентификации, mapping, Privacy, классификация входного и выходного доверия и решение. Строка имени сама по себе не объясняет, кто имел право её утверждать.

Учётные данные отвечали своему realm

Authorization и Proxy-Authorization связаны с realm, который сформулировал challenge. Если это realm MESSAGE-сервиса, поле не следует копировать downstream. Секрет, открывший дверь посредника, не предназначен серверу Боба.

Если поле относится к другому realm, RFC требует скопировать соответствующее значение. Решение контекстно: удалить всё столь же неверно, как переслать всё.

Журнал хранит тип, realm, необратимую ссылку, решение и контекст цели, но не сам секрет. Так можно доказать соблюдение границы, не создавая базу повторно используемых credentials.

Сохранность текста не имеет отношения к переносимости аутентификации. Это две разные власти с разными адресатами.

Компоненты URI не становились приказом без проверки

SIP URI может содержать header components. Сервис оценивает их по одному и может учесть, например, Accept-Contact. Специальный body hname не должен подменять полезную нагрузку и может быть отброшен.

URI может также содержать method parameter. RFC 5365 требует игнорировать просьбу о другой методе: MESSAGE-сервис создаёт только MESSAGE. Запись списка не получает права превратить его в источник INVITE или иной операции.

Следует фиксировать, что принято, отвергнуто и проигнорировано. Иначе пользователь считает, что пожелание выполнено, а оператор приписывает пришедший из данных header политике сервиса.

202 завершал лишь первый этап

После приёма сервис отвечает 202 Accepted. Спецификация прямо говорит, что ответ не сообщает об успешной доставке созданных MESSAGE. Он подтверждает получение и намерение попытаться.

Маршрут, downstream-ответ, прикладная квитанция и эффект у пользователя требуют более поздних наблюдений. RFC оставляет конкретный механизм delivery status вне scope, но не разрешает заменять отсутствие данных успехом.

Смежная RFC 5363 рассматривает множественные результаты шире. Здесь отдельный предмет — построение раскрываемого представления: ещё до результата сервис уже выбрал, кто увидит отношения между участниками и под какой защитой.

Реестр давал общий словарь, не доказательство раскрытия

IANA регистрирует recipient-list-message и связанные dispositions. Это делает capability и формат узнаваемыми. Реестр не подтверждает, что конкретный сервис правильно скрыл Bcc, применил Privacy или доставил запрос.

RFC 5365 опубликована в октябре 2008 года на Standards Track. RFC 3851 позднее устарела в линии S/MIME, включающей RFC 8551. Современная реализация выбирает актуальную криптографию, сохраняя вопрос: какой объект защищён для какой аудитории.

Minimum Initial Specification Лу Хэна служит объявленной аналитической линзой: общий слой стандартизирует минимальный контракт, а локальные решения остаются у тех, кто имеет локальную информацию. Reality Layers запрещает путать символ — hash, статус, список — с операционной реальностью. Факты протокола несут RFC и IANA.