要約

  • RFC 5257 の .priv と .shared は、注釈を誰が見て書けるかを分ける。値が永続化されても、メール送信者の発言や組織の承認にはならない。
  • COPY は共有注釈を運ぶ一方、私用注釈は現在の利用者のものだけを運ぶ。同じメールでも、移動先に残る判断材料は同じとは限らない。

引き継ぎは成功したのに、疑念だけが消えた

夜勤担当者は、問題のメールに私用注釈を残した。「添付資料の数字は再確認が必要」。同じメールにはチーム共有の「処理済み」も付いていた。朝、管理者が案件を別のメールボックスへコピーすると、メッセージと共有ラベルは到着したが、夜勤担当者の私用メモは来なかった。画面だけを見れば、疑念のない完了案件に見える。

これは必ずしも障害ではない。RFC 5257 は、他人の私用注釈を COPY で持ち出さないよう意図的に設計している。問題は、運用側がコピー成功を「文脈の完全な移管」と読み替えたことである。

メッセージと注釈は同じ画面に置ける。しかし、それぞれを生んだ主体、時刻、権限、保存経路は別だ。近接している情報を一つの声に見せる UI は便利であるほど、権威の境界を明示しなければならない。

二つの接尾辞は秘密度の格付けではない

各注釈属性には暗黙に .priv と .shared がある。取得や検索では接尾辞を省略して両方を対象にできるが、STORE、APPEND、注釈による並べ替えではどちらかを指定する必要がある。書き込み時に境界を選ばせるのは、協働と個人作業を両立するための重要な仕掛けだ。

ただし名前から余計な意味を引き出してはいけない。.priv は暗号化済み、法的秘匿、管理者からも不可視、のいずれも意味しない。.shared は査読済み、正確、組織承認済みを意味しない。接尾辞はサーバー内部の可視範囲とアクセス面を選ぶ。

センシティブなメモを共有側に置けば、権限を持つ同僚へ広がりうる。引き継ぎに不可欠な状態を私用側に置けば、チームには存在しないのと同じになる。分類の失敗は、機密漏えいと運用欠落という逆向きの損失を生む。

書けることと、代表できること

ACL 拡張がなければ、選択したメールボックスが読み取り専用か読み書き可能かで操作が決まる。ACL があれば、r 権限が私用注釈の読み書きと共有注釈の読み取りを制御し、新しい n 権限が共有注釈の作成・変更を制御する。

これは権限を狭く付与できる優れた分離だ。だが、n を持つアカウントが「承認」と書けた事実は、そのアカウントが顧客や送信者を代表した証拠ではない。メールの所有権、取引の同意、法的な代理権は ACL の外にある。

したがって監査では、最終値だけでなく、書き手、認証情報、当時の ACL、メールボックス能力を保存する必要がある。「ワークフロー用アカウントが共有値を書いた」は検証可能だ。「顧客が承認した」は、顧客へつながる別の権限連鎖がなければ成立しない。

永続性は履歴ではない

RFC 5257 は注釈をセッション限りにせず永続保存するよう求める。オフライン利用者との同期や再ログイン後の利用には必要だが、値を不変にする規定ではない。

STORE は値を作成・置換でき、NIL の保存は削除になる。存在しない値を取得すれば NIL、サイズはゼロと返る。別の履歴がなければ、「一度もなかった」「削除された」「移行先で保存できなかった」を最終状態から区別できない。

競合について RFC は Conditional STORE の利用を勧める。古いスナップショットに基づく無言の上書きを検出するためだ。しかし、競合を検出しても、どちらの判断が正しいか、基礎となる業務主体がどちらを承認したかまでは決めない。状態トークンは意味の審査官ではない。

能力表示と保存結果の間

サーバーは ANNOTATE-EXPERIMENT-1 を広告できるが、各メールボックスの実態は別途示される。NONE は利用不可、READ-ONLY は変更不可、NOPRIVATE は共有注釈のみを表す。数値は値の最大サイズを示し、メッセージ当たりの注釈数にも上限を設けられる。

移行担当者が見るべきなのは、サーバー全体の能力文字列だけではない。移行先メールボックスが私用値を受け入れるか、値の大きさや個数が範囲内か、現在の ACL で書けるかを確認しなければならない。メッセージの配送成功と注釈の配送成功は別の結果である。

サイズ超過や個数上限は、文脈の欠落として報告すべきだ。メール本体が届いたからといって警告を緑色の成功表示へ畳み込めば、利用者は判断材料が欠けたことを知らずに次の処理へ進む。

COPY は「同じ一式」を作らない

同一サーバー上の COPY では、対応サーバーはすべての共有注釈と、コピーを行う現在の利用者の私用注釈だけをコピーする。他の利用者の私用注釈をコピーしてはならない。さらに移行先の権限、読み取り専用状態、注釈対応、サイズ制限が実際の伝播を左右する。

その結果、メッセージのオクテット列が同一でも、周囲の情報集合は変わる。一人の調査メモは付いて行き、別の人のものは残る。共有ラベルは条件が合えば移り、大きすぎる値は残る。目的地で見えるものを、源の完全な写像と呼ぶことはできない。

共有注釈にも自動的な著者権威は付かない。メール受信後に別人が書き、ACL 変更後に更新し、さらに別フォルダーへ運んだ値かもしれない。COPY が伝えるのは値であって、その判断理由や代理権ではない。

検索可能性が判断を強くする

注釈値は検索でき、私用値または共有値で並べ替えられる。つまり注釈は単なる余白メモではなく、作業キュー、優先順位、自動保留、保存期間を左右しうる索引である。

影響が大きいほど、来歴を要求する必要がある。構文が正しく、ACL で読め、正常にコピーされた値でも、古い、誤っている、別の目的で書かれた可能性は残る。標準またはベンダーの名前空間登録は解釈方法を定めるだけで、個々の値を検証しない。

RFC 5464 がサーバー・メールボックス単位のメタデータを別に定義したことも重要だ。「メタデータ」という一語で、対象、書き手、移動規則、権限を平らにしてはいけない。

注釈単位の実行証跡を残す

重要な注釈には、メールボックスと UID、メッセージまたは本文部分の範囲、エントリー名、.priv/.shared、書き手と認証情報、ACL と能力のスナップショット、旧値・新値のハッシュ、状態トークン、サーバー結果、削除、サイズ・クォータ判定、下流で起きた操作を結びつける。

コピー時には、源と先、実行主体、両方の対応モード、コピーまたはスキップされた属性と理由を追加する。表示時も、注釈の書き手、時刻、可視クラスを本文から見分けられるようにする。

表現は証拠の強さに合わせる。「書き込み後、共有注釈は『承認』だった」は確かめられる。「送信者が承認した」には送信者の権限連鎖が必要だ。「全員の検討内容が移った」は、属性ごとのコピー証跡なしには言えない。

RFC 5257 はメッセージのそばに有用な記憶を置く。組織が守るべき原則は、その記憶を活用しながら、記録そのものの声に化けさせないことである。

出典