Кратко

  • В модели присутствия, одним из авторов которой был Jonathan Rosenberg, OPEN в контексте мгновенных сообщений означает готовность связанного почтового ящика принять сообщение. Это не свидетельство местоположения, личности, внимания или готовности человека ответить.
  • PIDF допускает несколько tuple, включая OPEN и CLOSED для одного contact. RFC 4479 разделяет человека, сервис и устройство, чтобы характеристика одного объекта не превратилась незаметно в состояние другого.
  • Право наблюдать, получение уведомления, происхождение tuple, приём сервисом, активность устройства, доставка, показ, чтение и ответ — разные квитанции. Зелёный индикатор честен, только если его подпись не расширяет измеренный факт.

Точка горела, а ответа не было

Система распределения видит одного свободного специалиста: рядом с его именем зелёный индикатор. Ему отправляют срочное поручение, мессенджер принимает сообщение, но реакции нет. Позднее отчёт формулирует вывод: «доступный сотрудник не ответил».

Исходные события такого вывода не содержат. Возможно, OPEN относился к сервису обмена сообщениями. Приём на входе не доказывает доставку на нужное устройство и показ на экране. Отсутствие ответа не устанавливает, видел ли сообщение человек и мог ли он действовать.

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

Изначально OPEN описывал instant inbox

RFC 2778 Марка Дэя, Jonathan Rosenberg и Hiroyasu Sugano — информационная абстрактная модель. Она вводит общий словарь, а не полный протокол взаимодействия. В ней отдельно существуют presentity, служба присутствия, watcher, principal, служба мгновенных сообщений и instant inbox.

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

Подлежащее в этом определении — ящик. Статус ничего не говорит о физическом присутствии человека, недавнем вводе, внимании к окну, отношении к отправителю или намерении отвечать. Связь реальных людей, групп и программ с системными principal тоже лежит вне модели.

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

PIDF сохраняет несколько локальных состояний

RFC 3863 определяет Presence Information Data Format. Документ PIDF содержит tuple; в каждом есть status и могут быть contact, timestamp, заметки и расширения. Базовое значение — open или closed.

Сегментация нужна, когда сведения пришли от разных устройств, приложений на одном устройстве или были созданы в разное время. Поэтому спецификация разрешает двум tuple с одинаковым contact одновременно сообщать OPEN и CLOSED.

Интерпретация зависит от watcher и приложения. Следует знать, какой tuple изменился, откуда он пришёл, как соотносятся часы, какую политику применил compositor и заменило ли следующее уведомление прежнее. Стандарт не назначает одному из конфликтующих значений статус «истины о человеке».

id tuple — произвольная строка для различения и сопоставления в пределах presentity. Она не идентифицирует человека и не удостоверяет устройство. Превращение её в глобальный ключ личности добавило бы смысл, которого RFC не даёт.

Если хранить лишь конечный цвет, решение нельзя воспроизвести. Нужны subscription, последовательность NOTIFY, tuple ID, тип компонента, contact, исходное значение, источник, время публикации и получения, версия правила композиции.

Разрешение смотреть не является состоянием наблюдаемого

В RFC 3856, написанном Rosenberg, SIP SUBSCRIBE и NOTIFY переносят сведения о присутствии. Presence agent обязан аутентифицировать запрос подписки, а затем отдельно решить вопрос авторизации. Подписка может быть разрешена, отклонена или ожидать решения; уведомления несут состояние подписки и presentity.

Это четыре разных вопроса: кто watcher, что ему позволено видеть, действует ли связь наблюдения и какие данные опубликованы. Аутентификация наблюдателя не удостоверяет человека, описанного документом. Получение NOTIFY не доказывает, что опубликованное значение возникло из прямого наблюдения за человеком.

Правила приватности могут скрывать активность устройства. Исчезнувшее поле не означает idle. Завершившаяся подписка может говорить об отзыве доступа, а не об отключении сервисов. Интерфейс, который показывает потерю права наблюдать как «человек offline», переносит событие из плоскости доступа в человеческое состояние.

RFC 4479 назначает факту правильный тип

RFC 4479, автором которого является Jonathan Rosenberg, делит presentity на person, service и device. Атрибут относится к объекту, который он описывает, а не обязательно к компоненту, который его сообщил.

Телефон может сообщить «пользователь на совещании», но эта характеристика относится к человеку. Заряд батареи относится к устройству. Точка коммуникационной достижимости относится к сервису. Источник измерения и смысловой субъект — разные поля.

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

Даже компонент person — модельный фасад. Система не способна проверить, что за ним стоит ровно один человек. Коллективный help desk можно представить одной person. URI presentity координирует сведения, но не является биометрической или юридической идентификацией.

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

Недавний ввод меняет вероятность, а не статус человека

RFC 4480 Хеннинга Шульцринне, Vijay Gurbani, Paul Kyzivat и Rosenberg добавляет rich presence. Элемент user-input сообщает active или idle по настраиваемому временному порогу. Он может учитывать одно приложение или всё устройство; точное время последнего ввода допускается не публиковать.

Спецификация отмечает: давно не использовавшийся tuple всё ещё может быть OPEN. Watcher может предпочесть открытый контакт с более свежей активностью. Два сигнала вместе помогают оценить вероятность ответа.

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

Фразы «сервис принимает сообщения» и «активность замечена менее десяти минут назад» раскрывают основания. Надпись «человек доступен» прячет сделанный продуктом вывод.

Авторство тоже имеет границы

На 9 сентября 2026 года публичный профиль Jonathan Rosenberg в IETF перечислял 72 RFC и не показывал активных ролей. RFC 3856 и RFC 4479 имеют одного указанного автора; RFC 2778 и RFC 4480 созданы коллективно. Это подтверждает вклад в стандартизацию, но не контроль над консенсусом, реализациями или пользователями.

Официальная страница автора Five9 и публичный headshot дают происхождение изображения для редакционного портрета. Старая биография не используется как доказательство текущей должности. Источник изображения и актуальный трудовой статус — разные утверждения.

Каждый глагол закрывает один вопрос

Watcher аутентифицирован. Ему разрешён определённый вид. Уведомление получено. Service tuple сообщил OPEN. На устройстве был свежий ввод. Сервис принял сообщение. Клиент доставил и показал его. Человек прочитал и ответил.

События можно связать, но нельзя заменять друг другом. Если этап не наблюдался, он остаётся неизвестным. «Сервис открыт, приём подтверждён, чтение неизвестно, ответа нет» помогает расследованию. «Доступный человек проигнорировал» приписывает мотив на основании цвета.

Зелёная точка полезна, если система помнит: открыта дверь связи, а не человек.

Источники