要約

  • RFC 2446 の iTIP では、Attendee が送る COUNTER は代替案を提示できるが、それだけで Organizer の master entry を変更しない。Organizer の判断と、その判断を反映した後続 REQUEST は別のプロトコル上の出来事である。
  • ROLE、STATUS、PARTSTAT、SEQUENCE、各 METHOD は異なる意味を持つ。とりわけ SEQUENCE は Organizer による改訂系列を追跡するための値であり、参加者の同意、配送成功、出席、現実の実施を表す値ではない。
  • iTIP の履歴を証拠として読むには、受信バイト列、認証済み送信者、役割上の権限、METHOD と UID、Organizer の改訂、個人の参加状態、COUNTER、Organizer の判断、後続 REQUEST、配送、ローカル保存、リマインダー、実際の参加を分ける必要がある。

RFC 2446 は1998年11月、Standards Track の RFC として公開された。基礎となる RFC 2445 が iCalendar のオブジェクトとデータモデルを定義したのに対し、RFC 2446 はそのオブジェクトを使って予定調整を進める transport-independent な相互運用手続きを定義した。電子メールとの結合は RFC 2447 が扱い、後には iCalendar 本体が RFC 5545、iTIP が RFC 5546、メール結合が RFC 6047 へ更新された。

この構造で最初に区別すべきなのは Organizer と Attendee である。Organizer は予定調整の交換を開始し、master entry を制御する。招待された側は Attendee になる。しかし、このプロトコル上の役割を、ATTENDEE プロパティに記述される ROLE パラメーターと混同してはならない。ROLE は参加者について記述する属性であって、その文字列自体がメッセージ送信者の認証や master entry の変更権限を成立させるわけではない。

状態にも同じ分離がある。STATUS はイベントなどの entry 全体についての状態を示し、PARTSTAT は個々の Attendee の参加状態を表す。したがって、ある参加者の PARTSTAT が変わることと、予定全体の STATUS が変わることは同一ではない。REPLY は主として Attendee 側から参加状態を返すための METHOD であり、それを全体 entry の状態変更と読むことはできない。

METHOD も目的ごとに分けられている。PUBLISH は情報を公開するが対話的な応答を期待する方式ではない。REQUEST は受信側に処理を求め、応答を伴う予定調整に使われる。REPLY は参加者側の状態を伝える。COUNTER は既存の予定に対する代替案を提示する。DECLINECOUNTER は、Organizer がその COUNTER を受け入れないことを示す。

ここで重要なのが COUNTER の境界である。COUNTER には完全な代替 VEVENT や VTODO を含めることができる。たとえば、これは説明のための仮定だが、月曜の会議に招待された Attendee が「火曜なら参加できる」として、火曜の日付を含む完全なイベント案を返すことはできる。しかし、その COUNTER が構文解析され、UID が一致し、十分な情報を含んでいたとしても、それ自体が Organizer の master entry を火曜へ書き換えるわけではない。

Organizer がその提案を受諾するなら、Organizer 自身が再調整を行い、変更によって影響を受ける Attendees に新たな REQUEST を送る。RFC 2446 を置き換えた RFC 5546 でも、この「COUNTER の受信」と「Organizer による変更」、さらに「変更後の REQUEST」という分離は維持されている。したがって、COUNTER の存在は提案の証拠にはなっても、採用の証拠にはならない。

SEQUENCE も誤読しやすい。これは Organizer が行った改訂を追跡するための仕組みであって、投票数でも合意レベルでもない。RFC 2446 では、REPLY、REFRESH、COUNTER、DECLINECOUNTER、および委任に伴う REQUEST は SEQUENCE を増加させない。一方、ADD と CANCEL は増加させる。さらに REPLY が Organizer の過去の改訂を反映する場合もある。そのため、高い SEQUENCE 値を見ただけで「最新案に全員が同意した」と結論づけることはできない。

転送にも同様の境界がある。ある Attendee が招待を第三者へ転送しても、その未招待者が Organizer の master list に自動的に追加されるわけではない。Organizer が新しい参加者をどう扱うかを判断する必要があり、転送者がイベント属性そのものを変更することも想定されていない。配送経路で生じた事実と、master entry に反映された権威ある状態は別である。

配送順序さえ、予定の論理順序を保証しない。store-and-forward 型の転送では、CANCEL が対応する REQUEST より先に到着し得る。RFC 2446 は、対応する REQUEST をまだ持たない受信者が非ゼロ SEQUENCE の CANCEL を受け取った場合、それを一時的に保持して古い関連メッセージの到着を待つ方法を示しており、一定条件では期限切れとして扱うことも認めている。つまり、受信時刻だけでプロトコル上の因果順序を決めることにも限界がある。

さらに RFC 2446 の役割情報は認証そのものではない。Organizer や Attendee を名乗る情報をメッセージへ記述することは、送信者が本当にその主体であることを暗号学的に証明することとは違う。認証や暗号化は transport binding 側で扱われる領域であり、電子メール結合では MIME セキュリティなど別の仕組みとの関係が生じる。したがって、「Organizer と書かれている」と「認証済み Organizer が送った」は別の証拠である。

この区別を歴史資料や運用ログへ適用すると、証拠を一列に並べるだけでは不十分だと分かる。まず受信したバイト列があり、次に送信者が認証されているか、その主体に Organizer または Attendee としての権限があるかを確認する。その上で METHOD と UID、Organizer の SEQUENCE、各 Attendee の PARTSTAT、COUNTER の内容、Organizer の判断、変更後の REQUEST、配送記録、ローカルカレンダーへの保存、リマインダー、そして実際に観察された参加という層が続く。

そのため、構文解析済み COUNTER、高い SEQUENCE、配送通知、REPLY、ローカル承認行、リマインダー、画面に表示された予定は、それぞれ限定された事実しか証明しない。それら単独では Organizer の権限行使、全参加者の収束、実際の出席、予定された行為の実施までは示さない。

Heng Lu の文書は iTIP の規範を定義する一次資料ではない。本稿では、規範、権限、認証済み転送、実装、ローカル状態、現実の結果を分けて考えるための分析レンズとしてのみ扱う。この読み方を適用すると、RFC 2446 の歴史的な意味は「カレンダー招待をネットワークで運ぶ仕様」にとどまらない。提案された状態と権威ある状態、メッセージとして観察できる事実と現実世界で成立した結果を、同じものとして扱わないための境界をプロトコルの中に残したことにある。

出典