要約

  • iCalendar拡張draft第08版は参加役割OWNERを加えるが、その値は表示上の手掛かりにすぎず、単独で変更権限を与えてはならないと定める。
  • JMAP Calendarsでは、owner役割の参加者が利用者のアカウント内IDに対応し、さらに現在のcalendar権限とevent制約が操作を許す必要がある。
  • 役割の解析、ID照合、認可、保存、scheduling messageの送信、remote処理、参加者による確認は別々の証拠である。

危険なcalendar objectは、壊れているとは限らない。正しい構文でparserを通り、画面にはもっともらしい「所有者」badgeが出る。障害は、その説明をsoftwareが権限へ昇格させた瞬間に始まる。

第08版draftはOWNERを参加役割として定義する。所有者は予定変更や参加者・役割の追加削除など、全員に影響する変更を行えると説明する一方、決定的な境界も置く。この役割はindicativeであり、意味は利用するcalendar exchange protocolに依存する。実装は、objectに役割があるという理由だけで変更能力を与えてはならない。

ここでは、dataが運ぶ主張とsystemが行使させる力が分離される。calendarでは、役割が日時、場所、繰り返し、参加者と同じ画面に並ぶため、両者を混同しやすい。

主張は移動できても、権限は自動では移動しない

RFC 5545はportableな表現を提供する。同じ記録がfile、mail、CalDAV store、JMAP serviceを通過しても、それぞれのaccount、identity、権限modelは同一ではない。

拡張draftは、CalDAVにおけるOWNERの権限上の意味を定義しないと明記する。受信側は役割を保存・表示できるが、周囲のprotocolにないwrite ruleを作ってはならない。IANA iCalendar registryに将来登録されても、名前と参照先が整うだけで、参加者の認証や権限付与にはならない。

Minimum Initial Specificationの考え方は、この境界に合う。共通形式は相互運用に必要な最小意味を持ち、将来のlocal policyまで集中管理しない。OWNERは共通語彙になれても、grantはprotocolと運用主体に残る。

JMAPは認可までの段階を見せる

現行のJMAP Calendars draftでは、利用者がevent ownerとなるには、Participantがowner役割を持ち、そのParticipantがaccount内の利用者のParticipantIdentityに対応しなければならない。

それでも万能なcapabilityにはならない。mayWriteOwnは、そのcalendarで権利が有効であり、利用者がevent ownerであるかeventにownerがいない場合に限って作成・変更・削除を許す。mayWriteAll、mayRSVP、mayShare、mayDeleteは別の力を表す。

CalendarEvent/setでは、serverがmyRightsを強制し、許可されない変更をforbiddenで拒否する。このverdictが権限のreceiptであり、役割は判断材料の一つにすぎない。

origin、privacy、recurrence、所属calendarも結果を狭める。event copyがscheduling originでない場合、calendar rightsが広く見えてもclientはper-user property以外を編集させてはならない。後のauthoritative updateがcopyを上書きし得るからだ。

段階 証明するもの まだ証明しないもの
解析 正しい構文にOWNERがある 誰が主張し、今も有効か
ID照合 参加者がaccount identityに対応する calendarとeventへの権利
認可 現在のruleが操作を許す 変更が成立したか
変更receipt serverが新状態を受理した messageが送られたか
配送receipt 別systemがmessageを受けた 適用・表示されたか
読み戻し 参加者が変更を見た 全copyが持続的に収束したか

保存成功は全員の予定変更成功ではない

JMAPでは、scheduled eventの変更時にmessage送信を要求できる。しかし要求はdelivery receiptではない。local copyの保存後、宛先選択、queue、transport failure、remote rejection、未読copyという段階が残る。

RFC 6638とRFC 4791は、storageとschedulingが関連しつつ別のsurfaceであることを示す。collection、利用者のscheduling authority、outbox、参加者copyは一つのatomic factではない。

信頼できる記録は、source object hash、役割の位置、account identity照合、権利version、originとprivacy、policy verdict、変更IDと前後hash、宛先選択、transport結果、参加者readbackを結ぶ。privateな予定本文は不要で、限定された結果、安定ID、digestでaccountabilityを保てる。

標準化の進行は運用実績ではない

Datatrackerは第08版をCALENDAR EXTENSIONS WGのInternet-Draft、Proposed Standard予定、publication requestedと示す。historyとshepherd write-upは手続きを記録する。まだRFCではなく、製品の実装や導入を証明しない。

同じdraftのSHOW-WITHOUT-TIMEは表示だけに作用し、衝突判定に使う時間幅を変えない。この設計規律はOWNERにも通じる。見た目やlabelが深いstateを黙って書き換えてはならない。

Running-Code Primacyが求めるのは、解決されたidentity、読み込まれたrights、実際のserver verdictの確認だ。The Policy Mirrorはidentity lookup、rights cache、origin判定、defaultに潜む力を示す。Reality Layersはsyntax、role、authority、outcomeを一つの緑表示に畳み込ませない。

経営側が問うべきは「calendarにownerと書いてあるか」ではない。「どのsystemが、どの状態に対して、どの操作を許可し、その変更が依存する人々に届いたことを何が証明するか」である。

Sources