要約

  • IMAP では、検索の初回結果を正常に返しながら、要求された継続更新を断ることができる。検索コマンドの成功だけでは、更新の受け入れは確認できない。
  • PARTIAL で表示する範囲を絞っても、UPDATE が追うのは検索条件に合う集合全体の変化だ。画面の小ささと継続処理の小ささは一致しない。
  • 問われるのはキャッシュ容量だけではない。更新の順序、結果集合の出入り、終了と再同期、そして更新が受け入れられなかった事実を利用者に伝える責任がある。

「開いている」と「見張っている」の違い

未処理の依頼だけを集めたメール画面を、一日のあいだ開いておく。担当者はそこに現れる項目を見て、次に対応する案件を決める。最初に検索した時点では一覧が正しかったとしても、それだけで午後の判断まで支えられるわけではない。

このような画面では、表示が消えないことが、監視も続いていることのように受け取られやすい。だが画面を維持する仕事と、検索条件に合うメッセージの変化を追う仕事は異なる。後者が受け入れられていなければ、正しい初回結果の上に、裏付けのない継続性が重ねられることになる。

これは特定製品で確認した事故ではなく、契約の境界を考えるための例である。問題は「検索に失敗したか」だけでは捉えられない。検索そのものは成功し、その後の仕事だけが断られる場合があるからだ。

RFC 5267 は、その違いを IMAP の応答として表現する。問い合わせに答えることと、問い合わせの答えを維持し続けることを、一つの成功表示にまとめてはならない。これは単なるエラー処理の細部ではなく、将来の作業量を誰が引き受けたかという境界である。

一つの応答に二つの判断がある

CONTEXT=SEARCH と CONTEXT=SORT は、それぞれの拡張機能に対応する能力の通知である。クライアントが付ける CONTEXT オプションは、検索を再利用する意図を伝えるヒントに当たる。使用は推奨されるが、サーバーは無視してよい。検索結果をその時点に固定するものでも、UPDATE を要求するための前提でもない。

UPDATE は、検索結果の継続更新を求める。サーバーは新しいコマンドの処理中に、元の検索コマンドのタグを引数とする NOUPDATE を付け、タグなしの NO 応答でその要求を断ることができる。それでも他の返却オプションには従わなければならず、コマンド自体はタグ付きの OK で終わり得る。

ここで拒否されたのは、そのコマンドで要求した継続更新だ。すでに受け入れられていた更新ストリームが打ち切られた、という意味に読み替えてはならない。初回結果が誤っていたという証拠でもない。

この分離は、クライアントに二方向の注意を要求する。NOUPDATE を受けたからといって、利用可能な検索結果まで消す必要はない。一方、最後に OK が来たからといって、画面を継続更新中と扱ってよいわけでもない。正しい結果を残し、受け入れられなかった約束だけを表示から外す判断が必要になる。

ただし、拒否できるという記述だけを切り出すのも不正確だ。RFC 5267 は、クライアントごとに少なくとも一つの更新コンテキストを提供することを必須とし、より多く提供することを推奨している。全面的に UPDATE を断ればよいという自由裁量ではない。

SORT の継続更新には、順序を保つ追加の負担があり得る。SORT の更新を拒否したからといって、SEARCH の更新も受け入れられないとは限らない。しかし、順序を捨てた別の検索を黙って同じものとして提示すれば、今度は仕事の意味を変えてしまう。代替手段を選ぶことと、元の要件を満たすことは別である。

完了したコマンドのタグが残る理由

継続更新を受け入れた後は、コマンドのタグも仕事を終えていない。タグは、その後に届く変化を元の検索へ結び付ける役割を持つ。更新が有効なコマンドのタグを再利用した場合、サーバーは BAD を返さなければならない。

この規則は、初回の応答が終わっても運用上の関係が残ることを示している。画面に変化がない時間でも、どの条件でどの結果を追跡しているかという対応は必要だ。短いコマンド処理として集計すれば、この残存する義務が見えなくなる。

もっとも、タグは恒久的な業務識別子でも、追加の認証情報でもない。検索とその更新を対応させる範囲を超えて、長期保存された履歴や権利を保証するものではない。この局所的な役割を正確に把握することが、過大な保証を避ける第一歩になる。

運用指標も同じように分けられる。初回検索の成功数、更新要求数、受け入れ数、拒否数、現在有効なコンテキスト数は、それぞれ違う状態を表す。初回応答の成功率が高いという数字だけでは、継続表示の健全性は評価できない。

十件の表示は十件の監視とは限らない

一覧に十件だけ表示すれば、送るデータ量は小さくなるかもしれない。しかし UPDATE が扱う変化は、PARTIAL で返した範囲だけではなく、条件に合致する検索結果集合全体に及ぶ。

2023 年 6 月の RFC 9394 は、末尾側から指定する負のインデックスによる範囲や UID FETCH の修飾子を含め、PARTIAL を拡張した。同文書は、継続更新が合致集合全体を対象にすることを明示的に維持している。また PARTIAL の能力通知は CONTEXT=SEARCH とは別だ。

画面の外でメッセージが条件に合うようになったり、合わなくなったりすれば、表示範囲に入る項目も変わり得る。狭い窓を返す機能を、追跡対象を狭める機能と同一視できない理由はここにある。

SAVE との組み合わせも、表示件数だけでは仕事量を判断できないことを示す。規定された条件では、MIN、MAX、COUNT を伴わない SAVE と PARTIAL は部分集合を保存する。一方、COUNT を加えると、保存されるのは合致した集合全体になる。これは保存対象の意味を定めるもので、実装のメモリー配置まで指定するわけではない。

もう一つ、PARTIAL と CHANGEDSINCE の組み合わせでは、先に範囲を選び、その後に変更条件で絞る。これを「直近に変更された N 件」と読み替えると、問い合わせの意味が変わる。最適化の議論より前に、どの集合をどの順番で選んでいるかを確認しなければならない。

RFC から一コンテキスト当たりの必要バイト数や料金表を導くことはできない。しかし、課金や容量計画の基準を考える際に、画面上の行数だけでは足りないことは分かる。合致集合の大きさ、変化の頻度、順序の維持、以前の状態を知る必要性が、それぞれ負担を左右する。

正しい変更でも、順番を誤れば意味が変わる

結果集合への追加と削除は ADDTO と REMOVEFROM で伝えられる。クライアントは、一つの応答に複数が含まれる場合も、受信した順に処理しなければならない。サーバーには要求された順序を保つ責任がある。

メッセージのシーケンス番号を使う場合、メールボックス自体の状態変化との前後関係も重要になる。到着や追加による ADDTO は EXISTS の後、消去による REMOVEFROM は EXPUNGE の前に届く必要がある。番号が指すものを、正しい時点の状態で解釈するためだ。

同じ追加・削除の情報がすべて届いていても、適用順を無視すれば正しい結果にはならない。単に通知を欠かさず運ぶだけではなく、通知が参照する状態を保つことが、更新サービスの一部なのである。

一方、RFC は更新を適時に送ることを推奨するものの、すべての実装に共通するミリ秒単位の遅延上限を定めてはいない。これを固定時間以内の最新性保証として販売するなら、その保証には別の測定と運用上の裏付けが要る。

COUNT を受け取った場合も、サーバーが同じ数値項目を際限なく再送する仕組みだと考えるべきではない。クライアントは集合への出入りを使って件数を維持できる。利用者が見る単純な数字の背後には、変化を正しい順に解釈する仕事がある。

この更新系列は、全業務イベントを恒久保存する大域的な履歴ではない。現在の検索結果を維持するための規則を、監査記録の完全性へ拡張して読むことはできない。

キャッシュを消しても仕事は消えない

サーバー内部のキャッシュは任意だ。キャッシュを使う場合も使わない場合も、外部から見える意味は同じでなければならない。保持する結果は変化に合わせて更新するか、整合しなくなれば破棄する必要がある。CONTEXT は古い検索結果を固定して返す免許ではない。

そのため、メモリーを空ければ継続義務まで消えるとは限らない。順序を求めない検索では、変化を増分的に評価できる場合がある。順序付き検索では、結果を保持する必要性が高くなりやすい。消去されたメッセージが検索集合から外れたことを知るには、消去前の状態が必要になることもある。

RFC 5267 のセキュリティ上の考察は、正規の利用者でも大量のコンテキストでサーバーに過剰な負担をかけ得ると指摘する。アクセス権が正しいことと、継続的な消費量が持続可能であることは別の問題だ。上限、記録、実装上の工夫には意味があるが、規格は任意の商用料金や一律の資源割当量を定めていない。

更新は、対象メールボックスの選択を解除するか、元のタグを指定した CANCELUPDATE によって終わる。サーバーは資源を解放でき、クライアントは新しく検索できる。再同期のためにコンテキストを作り直すことは、しばしば簡明な方法になる。

ただし、再構築できるのは現在使える結果であって、空白期間に起きた出来事の完全な履歴とは限らない。一覧が再び正しくなったことを、連続性が一度も途切れなかった証明として扱ってはならない。

NOTIFY の過負荷は同じ拒否ではない

2009 年 2 月の RFC 5465 は NOTIFY を定義し、RFC 5267 を更新した。規定どおり組み合わせれば、UPDATE によって、検索結果へ新たに入るメールの FETCH 属性を要求することもできる。しかし、連携できることは障害状態が同一であることを意味しない。

NOTIFY の要求が最初から過大な場合には、NOTIFICATIONOVERFLOW を伴うタグ付き NO で拒否され得る。受け入れ後に継続できなくなった場合には、同じコードを伴うタグなし OK が通知を無効にし、NOTIFY NONE と同じ動作にする。

前者は受け入れ前の拒否で、後者は後からの無効化だ。どちらも、特定の検索タグに結び付いた NOUPDATE と単純に同義ではない。NOTIFY NONE が、あらゆる RFC 5267 の UPDATE コンテキストを一律に終わらせると推論する根拠にもならない。それぞれの仕組みが何を引き受け、どの応答で状態を変えたかを追う必要がある。

RFC 5465 の正誤情報 も確認が欠かせない。検証済みの技術的正誤情報 2318 は、例にある STATUS と NOTIFY の順番を改め、NOTIFY の後に STATUS を行うようにする。状態確認と通知設定の間に変化を取り逃がす隙間を作らないためだ。

対して、技術的正誤情報 4833 は報告済みの状態にとどまる。第 5.2 節と第 7 節にある FETCH と ESEARCH の順序の食い違いを指摘しているが、確定した修正順序を提示するものとして扱えない。報告者の当時の実装に関する記述も、現在の製品を調査した結果ではない。検証済みの編集上の訂正 1694、1804、3824 が、この技術的争点を解決するわけでもない。

調査時点では RFC 5267 の正誤情報 と RFC 9394 の正誤情報 の検索に該当記録はなかった。そこから実装に不具合がないと結論付けることはできない。

最新性を約束する権限と、その後始末

Lu Heng は インターネット・ガバナンスの代理関係の問題 を論じる中で、判断する権限と結果を引き受ける立場の隔たりを問題にしている。この視点を検索画面へ適用すると、商品として最新性を約束する側、継続作業を受け入れるサーバー側、その状態を表すクライアント側の責任を分けて考えられる。

同じく 主張ではなく現実を BTW Media の提供価値に据える論考 に沿えば、規格にある仕組みと実際に観測した結果は混同できない。本稿ではメールアカウントへの操作も、本番キューの測定も、現在の製品群の適合性調査も行っていない。再検索の集中、問い合わせ対応の増加、古い情報による判断は想定される経路であり、確認済みの被害ではない。

また、この分析は規格の設計者や特定企業の意図を推定するものではない。資料から確かめられるのは、初回結果と継続更新の受け入れに異なる境界があることだ。

その境界を画面まで保てば、受け入れられなかった更新を、正しい初回結果と共存させられる。境界を消せば、利用者は画面が残っていることを、誰かが監視を続けている証拠だと思うかもしれない。検索サービスの責任は、答えを出す瞬間だけでは終わらない。