要約

  • Jonathan Rosenbergが関わったpresenceモデルでは、インスタントメッセージにおけるOPENは、対応する受信箱がメッセージを受け入れる準備ができているという状態である。人の居場所、注意、本人性、返答意思を示す状態ではない。
  • PIDFは複数のtupleを持ち、同じcontactについてOPENとCLOSEDが併存することも許す。RFC 4479はperson、service、deviceを分離し、報告元ではなく「何を記述する属性か」で所属を決める。
  • 認証・認可、通知、tupleの来歴、サービス受入れ、端末入力、配信、表示、読了、返答は別々の受領記録である。緑色の表示は、最後に結合できた証拠より広い意味を名乗ってはならない。

返事のない緑色

午前中から緑のままの連絡先へ、担当者が急ぎの質問を送る。送信システムは受け付けた。ところが昼になっても返答はない。画面だけを見れば「対応可能なのに返さなかった」という物語ができあがる。

その物語は、標準が発したものではない。緑色の元がOPENなら、観測したのはサービスの受付状態である。誰かが画面の前にいたか、通知が表示されたか、ほかの仕事を中断できたかは別の問いだ。

presenceは連絡先選びの不確実性を減らす。その機能を、人の行動を断定する装置へ変えてしまうと、便利さが証拠の過剰消費になる。

OPENが最初に指したのはinstant inboxだった

Mark Day、Jonathan Rosenberg、Hiroyasu SuganoによるRFC 2778はInformationalの抽象モデルである。相互運用プロトコルそのものではなく、presentity、presence service、watcher、instant message service、instant inbox、principalなどの共通語彙を定めた。

インスタントメッセージの文脈でOPENとは、関連するinstant inbox addressが、メッセージを受け入れる準備のできた受信箱に対応することを意味する。CLOSEDは受け入れられないことを意味する。他の通信手段にも類似の意味を持ち得るが、その詳細はこのモデルが決めていない。

ここで重要なのは主語である。準備ができているのは受信箱であって、人ではない。人が物理的に端末の近くにいる、送信者を認識している、連絡を望んでいる、返信を約束している、といった事実は含まれない。

受け入れ可能であることも、配送完了とは異なる。サービス入口で受け付けた後に、保存、端末への通知、画面表示、閲覧が続く。それぞれに失敗や遅延があり得る。OPENをperson_availableへ書き換えることは、単なる表示変換ではなく、観測対象のすり替えである。

PIDFは単一の正解だけを運ぶ形式ではない

RFC 3863のPIDFでは、ひとつのpresence文書に複数のtupleを入れられる。tupleにはstatusがあり、contact、timestamp、note、拡張要素を持つことができる。基本値はopenまたはclosedである。

複数tupleは、異なる端末、同じ端末上の異なるアプリ、あるいは異なる時点から得た情報を分ける。仕様は、同じcontactを持ちながら一方がOPEN、もう一方がCLOSEDという組み合わせさえ認めている。

そのときwatcherは、用途に応じて解釈する。どのtupleが更新されたか、時刻は比較できるか、情報源は何か、compositorはどの方針でまとめたか、後の通知が先の状態を置き換えたかを知る必要がある。標準は「新しい方を常に人の真実とする」とは言わない。

tupleのidは同じpresentity内で出現を区別し、過去の文書と対応付けるための任意文字列にすぎない。人の身元や端末の真正性を保証する識別子ではない。

集約後の色しか保存しない設計は、矛盾が起きた瞬間に根拠を失う。subscription、NOTIFYの順序、tuple ID、component種別、contact、値、発行時刻、受信時刻、情報源、集約方針の版を残して初めて、後から判定を再現できる。

見る権限と、見えた状態は別である

Rosenberg単著のRFC 3856は、SIPのSUBSCRIBEとNOTIFYでpresenceを扱うevent packageを定義した。presence agentは購読要求を認証し、その後に認可を判断する。購読は成功、拒否、保留となり得て、通知には購読状態とpresentityの状態が運ばれる。

認証はwatcherが誰かを扱う。認可は何を見せるかを扱う。subscription stateは観測関係の存続を扱う。PIDFは選ばれたpresence情報を扱う。どれも、対象の人が画面を見ていることを直接観測しない。

privacy方針が変われば、同じ人でもwatcherごとに見える情報が違う。device activityが消えたのは、idleになったからではなく非開示になったからかもしれない。購読終了を「本人がoffline」と表示すれば、観測権限の終了を対象の状態へ転嫁してしまう。

person、service、deviceを混ぜない

Jonathan RosenbergのRFC 4479はpresenceを三つのcomponentに分けた。personは人の状態、serviceは人へ到達する通信手段、deviceはサービスが動く物理的環境を表す。

属性は、それを報告したものではなく、それが記述するものに属する。携帯電話が「会議中」と報告しても、その属性はpersonに入る。batteryはdeviceに属する。メッセージを受け取れるURIはserviceに属する。情報源と意味上の対象を同一視しない設計である。

この区別に従えば、deviceの電源が入っていてもserviceの成功は保証されない。serviceがOPENでもpersonの意思は保証されない。device locationとperson locationも違ってよい。

さらに、person componentは一人の人を表すためのfacadeにすぎず、実際に一人の人間かどうかをシステムは検証できない。複数人のhelp deskを一人のpersonのように表現することもできる。presentity URIは調整のためのhandleであって、本人確認書類ではない。

三つを分けたまま集約すれば、障害の担当も見える。service受入れ、device活動、person申告は結合できるが、互いの名前を奪わない。

user-inputは応答可能性を推定する材料

Henning Schulzrinne、Vijay Gurbani、Paul Kyzivat、RosenbergによるRFC 4480はrich presenceを追加した。user-inputは設定された閾値に基づきactiveまたはidleを表す。特定アプリだけを測る場合も、端末全体を測る場合もあり、最後の入力時刻は省略できる。

仕様は、長く使われていないtupleでもOPENのままであり得ると説明する。watcherは、開いていて、かつ最近使われたcontactを優先できる。つまり、serviceの受入れと入力の新しさを組み合わせ、返答の可能性を推定する。

推定は証明ではない。別のアプリへの入力、バックグラウンド処理、受動的な閲覧、異なる閾値は結果を揺らす。activityが見えないのはprivacyのためかもしれない。「OPEN、10分以内に入力あり」と表示すれば、利用者は二つの根拠を評価できる。単に「本人が対応可能」とまとめれば、その評価機会を奪う。

人物への帰属も範囲を守る

2026年9月9日のIETF Datatrackerでは、Jonathan Rosenbergに72件のRFCが記録され、active roleはなかった。RFC 3856とRFC 4479は単著、RFC 2778とRFC 4480は共同著作である。この記録は標準化への貢献を示すが、IETF合意や製品実装、利用者の状態を一人が支配することを意味しない。

Five9の公式author pageと公開headshotは、編集用肖像の本人参照に使う。古い略歴から現在の役職は断定しない。画像の来歴と雇用の現況は別々の証拠である。

動詞ごとに受領記録を作る

watcherが認証された。特定のviewを認可された。NOTIFYを受けた。service tupleがOPENだった。deviceに最近の入力があった。メッセージが受け付けられた。clientへ届き、表示された。人が読み、答えた。

これらは一本の時系列に並べられるが、同じイベントではない。欠けた段階をunknownとして残すことが、正確な運用につながる。「service open、配送不明、返答なし」は次の調査先を示す。「availableな人が無視した」は、色から動機を作ってしまう。

緑の印を消す必要はない。何が緑なのかを消さなければよい。

出典