Кратко

  • RFC 5196 добавляет в PIDF динамические возможности сервиса и устройства, чтобы watcher мог лучше выбрать способ связи до контакта. Это подсказка, а не замена согласования среды, включая SDP.
  • Отрицание, отсутствие, сокрытие политикой и устаревание нельзя сводить к одному запрету: нужны отдельные следы источника, раскрытия, видимой проекции, приглашения, offer/answer и фактического результата.

От подсказки к праву вето

Базовый PIDF способен дать contact URI, не объясняя, представляет ли tuple голос, видео, сообщения или иной сервис. RFC 5196 заполняет пробел: переносит признаки возможностей RFC 3840 в модель человека, сервиса и устройства RFC 4479. До вызова watcher получает полезный ориентир.

Граница записана в самом документе. Расширение сообщает перед контактом о предпочтениях, готовности и возможностях, но не заменяет механизмы согласования среды SIP, такие как SDP. Presence может повысить вероятность удачного выбора. Только конкретные запрос, ответ, offer и answer показывают, что согласовано сейчас.

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

Не опубликовано — не значит невозможно

Presentity вправе не публиковать реальную возможность. RFC приводит пример: голос поддерживается, однако пользователь не желает раскрывать это. Правила авторизации и presence-сервер также могут ограничить или изменить данные для определённого watcher.

Формат различает явное положительное supported и явное отрицательное notsupported. Он не предлагает перечислять все несущественные отрицания. Если одно значение оказалось в обеих группах, watcher может считать его поддерживаемым. Отсутствие же не получает автоматического значения false.

Таким образом, клиенту нужны по меньшей мере разные состояния: явно поддерживается, явно не поддерживается, не раскрыто, неизвестно, просрочено и конфликтует. Иначе политика приватности превращается в технический отказ, а неполный документ — в полный инвентарь, которого никто не публиковал.

Старое утверждение могло быть правильным

Устаревание не обязательно означает ошибку источника. В момент публикации настольный телефон действительно мог не иметь видео. Затем пользователь перешёл на другой клиент, но агрегированная проекция и watcher-кэш сохранили прежнее значение. Формально корректная история была применена к новому endpoint.

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

RFC 5196 прямо не требует полного соответствия presence фактической возможности. Неполные или неверные данные способны заставить watcher счесть возможную коммуникацию невозможной либо начать попытку, которая провалится. Поэтому watcher не должен ожидать полной синхронности.

Несколько источников, несколько субъектов

Телефон, мобильный клиент, программа на рабочем столе и policy-сервис могут публиковать одновременно. RFC признаёт, что совмещение источников ведёт к потере или несоответствию данных. Композитор принимает решение, а не просто копирует XML.

Объединение возможностей создаёт воображаемое устройство со всеми функциями сразу. Пересечение скрывает реально доступный endpoint. Последнее значение имеет смысл лишь при сопоставимых часах и одном субъекте. Возможность сервиса нельзя без доказательства переносить на каждое устройство человека.

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

Два связанных, но разных квитанционных следа

Минимальная квитанция presence содержит presentity, watcher и контекст подписки; tuple, сервис или устройство; publication agent; версию; публикацию и истечение; точное значение и его положительный, отрицательный или нераскрытый статус. Далее идут правило авторизации, серверные изменения, входы композиции, конфликтное решение, хеш видимого документа и время получения.

Отдельно фиксируются решение сделать попытку, использованный сигнал, URI, выбранный endpoint, SIP-запрос и ответ, SDP offer и answer, согласованная среда, человеческая готовность и наблюдаемый результат. Ссылка соединяет цепочки, но поле ready не заменяет обе.

Это эксплуатационный вывод, а не новое требование к формату RFC 5196. Он следует дисциплине слоёв реальности Heng Lu: символ полезен, пока подчинён работающей системе. Presence должен советовать, а не запрещать самой переговорам проверить настоящее.

Sources

  1. RFC 5196 в HTML
  2. Текст RFC 5196
  3. Информационная страница RFC 5196
  4. IETF Datatracker: RFC 5196
  5. История RFC 5196
  6. Ссылки RFC 5196
  7. Errata RFC 5196
  8. RFC 3840
  9. RFC 3863
  10. RFC 4479
  11. RFC 3859
  12. RFC 4566
  13. RFC 3261
  14. RFC 2778
  15. RFC 3856
  16. RFC 3903
  17. RFC 5025
  18. Heng Lu — слои реальности и символическая власть
  19. Heng Lu — минимальная начальная спецификация
  20. Heng Lu — первичность работающего кода