Кратко

  • RFC 5367 позволяет начальному SUBSCRIBE с телом recipient-list создать агрегированную подписку на плоский набор ресурсов, но ответ верхнего уровня не сообщает, удалась ли подписка на каждый URI.
  • Последующие SUBSCRIBE направляются на предоставленный сервером адрес диалога и не могут переопределять список: тело списка там не имеет семантики и должно получить 415.
  • Управляемый список связан со сроком жизни подписки и должен уничтожаться после её завершения. Нулевой Expires, отзыв управляющего URI, удаление основной записи и очистка копий — разные наблюдаемые этапы.

Ноль описывал переход протокола

Значение Expires позволяет клиенту и серверу договориться о времени действия подписки. Нулевое значение используется для её прекращения, но относится прежде всего к состоянию протокольного отношения.

Если сервер принял такой запрос, можно утверждать, что он обработал намерение завершить подписку в конкретном диалоге. Нельзя без дополнительных данных утверждать, что каждый производный объект уже физически исчез.

Эта разница особенно важна для списка, который концентрирует отношения между ресурсами. Даже если отдельные URI публичны, их совместный выбор раскрывает цель наблюдения, роль оператора или структуру ответственности.

Отчёт «подписка прекращена» точен. Отчёт «все данные уничтожены» требует другой цепочки квитанций.

Список родился только в начальном запросе

UAC отправляет первый SUBSCRIBE на публичный URI ресурса списка. Хотя бы одна часть тела имеет disposition recipient-list, а Require содержит recipient-list-subscribe.

Клиент обязан принимать rlmi+xml. Архитектура тем самым разделяет две задачи: начальное тело задаёт набор, а уведомления сообщают наблюдаемое состояние его участников.

Форматом по умолчанию служит RFC 4826, однако RFC 5367 нужен плоский список. Иерархия и entry-ref не требуются; сервер может отбросить дополнительную структуру.

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

Ответ не был сводкой по всем URI

RFC 5367 прямо предупреждает: код ответа на SUBSCRIBE не содержит информации о том, удалось ли серверу подписаться на URI из списка.

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

Поэтому интерфейс должен отдельно показывать состояние диалога и покрытие набора. Знаменатель определяется каноническим списком, а не числом элементов, появившихся в последнем NOTIFY.

Если отсутствующие позиции убрать, неопределённость превратится в незаметный успех. Это улучшит показатель, но разрушит смысл измерения.

NOTIFY давал временное наблюдение

RFC 4662 задаёт модель уведомлений о событиях для списков ресурсов. rlmi+xml позволяет связать состояния отдельных ресурсов с агрегированным диалогом.

Для каждой позиции нужны канонический URI, экземпляр, состояние, версия, время наблюдения и причина завершения. «Неизвестно» и «ожидается» — полноценные значения доказательства.

Следует учитывать порядок и полноту. Старое уведомление, пришедшее позже нового, не должно откатывать состояние. Частичное обновление нельзя автоматически считать полным снимком.

Свежесть диалога и свежесть каждого ресурса тоже различны. Продлённый диалог может содержать давно не подтверждённую позицию.

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

После установления диалога UAC может посылать последующие SUBSCRIBE, чтобы продлить срок действия. Они направляются на URI, который сервер предоставил для диалога.

RFC 5367 не определяет смысла тела списка в таких запросах. Клиенту следует его не посылать, а сервер отвечает 415 Unsupported Media Type, если оно всё же пришло.

Правило не даёт праву обслуживания превратиться в право изменения охвата. Способность сохранить существующий диалог не включает способность незаметно заменить его ресурсы.

Если реализация ради удобства примет новый список, она создаст неописанную операцию изменения без ясных согласий, версии и связи с исходным решением.

Адрес продолжения имел другую власть

Начальный запрос идёт на публичный URI списка. Дальнейшие запросы используют предоставленный сервером удалённый target диалога.

С точки зрения клиента первый адрес принимает recipient-list, второй — нет. Один продукт и один метод SIP не делают поверхности взаимозаменяемыми.

Журнал должен связать публичный URI, аутентифицированного субъекта, Event, хеш набора, идентификаторы диалога, адрес продолжения и Expires. Тогда можно объяснить происхождение способности к продлению.

Синтаксически правильный запрос на неправильный адрес является ошибкой маршрутизации полномочий. Метрика, считающая только SUBSCRIBE и коды ответа, её не видит.

Управляющий URI был отдельной способностью

Первый NOTIFY может содержать Call-Info с URI и назначением purpose=list-management. Он предоставляет интерфейс для изменения списка, связанного с подпиской.

Публичный URI создаёт, URI диалога поддерживает, управляющий URI изменяет. Для каждого нужны собственные проверка субъекта, область полномочий и квитанция операции.

Факт выдачи ссылки не доказывает, что изменение произошло. Наличие ссылки в панели не доказывает, что она ещё действительна.

При завершении подписки способность управления должна быть отозвана. Иначе сохранённый URL превращается в боковой вход к объекту, утратившему законную цель.

Срок жизни списка был ограничен подпиской

RFC 5367 связывает срок жизни управляемого списка с подпиской. Когда подписка истекает или прекращается по другой причине, список следует уничтожить.

Это не косметическая уборка. Ограничение препятствует превращению временного набора наблюдения в постоянный реестр отношений.

Однако в реальной системе объект проецируется в несколько мест. Основная база, кэш, поисковый индекс, очередь, аналитическая копия, реплика и backup очищаются разными механизмами.

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

Уничтожение требовало собственной квитанции

Команда удаления доказывает намерение. Успешный ответ хранилища доказывает операцию на конкретной поверхности. Ни то ни другое автоматически не покрывает остальные копии.

Система может выпустить идентификатор tombstone, перечислить ожидаемые поверхности и собирать подтверждения. Пока одно обязательное подтверждение отсутствует, честный статус — «очистка не завершена».

Повторная обработка должна быть идемпотентной. Сбой между удалением основной записи и отметкой о завершении не должен восстанавливать список или удалять новый объект под повторно использованным идентификатором.

Для резервных копий нужен определённый срок и порядок восстановления. После восстановления tombstone должен применяться снова, иначе уничтоженная способность воскреснет вместе с данными.

Подлинность клиента не означала согласие цели

Механизм наследует требования безопасности RFC 4662 и RFC 5363. Сервер аутентифицирует и авторизует клиента, а сервис списка защищает затронутые ресурсы, включая надлежащий opt-in.

Идентичность отвечает, кто запросил наблюдение. Она не отвечает, согласился ли каждый ресурс на конкретный пакет событий, цель и длительность.

Решение политики должно связывать субъект, сервис, Event, канонический URI, цель, время и версию правила. Общая роль администратора не должна разрешать произвольные массовые списки.

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

Реестр обозначал понятия, а не выполнение

IANA регистрирует recipient-list-subscribe и list-management. Эти имена дают совместимый словарь, но не подтверждают успех отдельных подписок, действительность ссылки или уничтожение списка.

RFC 5367 был опубликован в октябре 2008 года как Standards Track и обновил RFC 3265 в части Call-Info в NOTIFY. Позднее RFC 6665 сделал RFC 3265 устаревшим. Современная реализация должна учитывать эту историю.

Статус стандарта, наличие option-tag, ответ, уведомление и запись удаления — утверждения разных уровней. Их нельзя складывать в один флаг «соответствует».

Заметки Lu Heng задают заявленную аналитическую линзу. Minimum Initial Specification объясняет, почему базовый договор не должен придумывать изменение списка при продлении. Reality Layers напоминает, что URI, ответ, уведомление и таймер — символы разных реальностей. Протокольные факты по-прежнему опираются на RFC и IANA.