Кратко

  • RFC 5264 применяет принятую частичную публикацию к локальному полному документу. Если publication не обновлена и истекает, компоновщик очищает весь её полный state, не только последнюю дельту и не переходя к предыдущей версии.
  • Надёжная запись связывает entity-tag, условие, тело, полные хеши до и после, срок, refresh, commit и влияние на составное состояние.

В журнале была зелёная дельта, а пропала целая вкладка состояния

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

Через некоторое время вклад устройства исчез. Причиной был не обратный патч, а пропущенный refresh. Срок публикации закончился, и компоновщик удалил весь накопленный документ.

Если хранить только последние тела, событие выглядит несоразмерным. Если учитывать модель soft state, оно становится точным: маленькой была передача, а объектом срока оставалась полная publication.

Полный документ существует с первого шага

Частичный режим начинается не с дельты, а с pidf-full. Он создаёт полную базу. Последующие modifying PUBLISH могут содержать pidf-diff либо снова полный state.

Компоновщик применяет операции к сохранённому документу и получает следующую полную форму. Экономия возникает в канале между PUA и компоновщиком; внутри модели состояния объект не дробится на независимо живущие XML-фрагменты.

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

Условная цепочка заменяет двойное версионирование

После успешного PUBLISH компоновщик выдаёт SIP-ETag. Обновление, модификация или удаление существующей publication предъявляет предыдущий тег в SIP-If-Match. Новый успех создаёт следующий тег.

В частичном PIDF есть атрибут version, но RFC 5264 не использует его как второй порядок публикаций. Два механизма могли бы противоречить друг другу и создать неопределённую ошибку.

Поэтому сама дельта не является полной квитанцией. Нужны Request-URI, event package, старый тег, условие, ответ и новый тег. Только вместе они показывают, какой признанный state изменялся.

История патчей не обязана пережить результат

Операции add, replace и remove выполняются последовательно. Полученный документ идёт в composition logic как полный presence state.

RFC 5264 прямо объясняет: компоновщик не хранит применённые патчи для rollback. Истечение не запускает вычитание последнего изменения и не восстанавливает предка. Вернуться к прежнему содержанию можно новой полной публикацией.

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

Срок относится к результату всех изменений

Изменение Expires действует на полную уже исправленную publication. Без refresh она целиком очищается. Поэтому последнее небольшое сообщение может предшествовать крупному исчезновению.

Обратная сторона та же: эффект давней дельты остаётся через множество refresh, потому что уже включён в текущий документ. Его жизнь определяется не возрастом исходного тела, а существованием publication.

Для оператора критична не только доля успешных patch requests, но и фактический запас времени до refresh и подтверждение его commit.

Вся publication — не обязательно весь ресурс

RFC 3903 допускает несколько издателей для одного ресурса. Компоновщик объединяет активные вклады и может использовать отдельно заданный hard state, который не истекает.

Удаление одной publication не означает автоматическое удаление остальных. Итоговая видимость зависит от оставшихся вкладов и политики композиции.

Отчёт должен назвать конкретную публикацию, перечислить оставшиеся источники и сравнить composite hashes. Фраза «исчезло всё присутствие» доказуема только после этой проверки.

До commit прежний документ действительно можно сохранить

pidf-diff не может быть начальной публикацией без полной базы. Ошибка разбора или применения документа приводит к 400 и может сопровождаться диагностикой RFC 5261. Другие ошибки до завершения всей обработки требуют 500 и возврата к исходному локальному документу.

Здесь попытка не принята, поэтому старое состояние остаётся. Истечение происходит позже над уже признанным soft state и удаляет его. Это разные переходы с разными владельцами и доказательствами.

Система событий должна различать неверное условие, невалидный patch, успешный commit, явное remove и естественное expiry. Иначе расследование теряет причинность.

Квитанция публикации и срока

Для решений с последствиями сохраняйте:

  • Request-URI, event package, издателя, presentity и идентичность publication;
  • предыдущий entity-tag, SIP-If-Match и новый SIP-ETag;
  • полный или частичный body, байты, хеш и время;
  • порядок и результат каждой patch operation;
  • хеш полного документа до и после;
  • запрошенный, предоставленный и фактический срок;
  • deadline, запрос, ответ и commit refresh;
  • явное удаление или expiry и очищенный state;
  • другие publications и hard state;
  • composite hash, версию политики и последующее уведомление; и
  • показ, автоматическое решение или человеческий результат.

Entity-tag доказывает условный порядок. Commit доказывает локальный state. Composite hash доказывает рассчитанный результат. Ни один из них без отдельной наблюдаемости не доказывает доставку watcher или действие человека.

Sources