要約

  • RFC 9590 は、サーバーがあるメールボックスの注釈を参照できないとき、対応する METADATA 応答を省いても LIST をタグ付き OK で終えられると定めている。
  • 明示的な NIL、取得不能による応答欠落、\NonExistent の階層名、子孫の一致だけを理由に返された親名は、画面では空欄に見えても証拠としては別物である。

運用画面に「LIST 成功」と表示された瞬間を考える。最上位のメールボックス名と色の注釈を一括取得し、最後に A01 OK List completed を受け取った。ところが、一つの色だけがない。

その空欄を「未設定」と呼べるのは、NIL を明示的に受け取った場合だけだ。応答そのものがなかったのか、実在しない階層上の名前だったのか、選択条件を満たす子を見せるためだけに親が返されたのかもしれない。コマンド完了だけでは区別できない。

往復を減らす拡張

RFC 9590 は LIST-METADATA 能力を定義し、LIST-EXTENDED の RETURN オプションに METADATA を加えた。従来のように LIST の後で各メールボックスへ GETMETADATA を繰り返さず、名前、LIST 属性、指定した注釈を一度に要求できる。

標準 LIST パターンと選択オプションの双方に一致する listable なメールボックスについて、サーバーは LIST に続けて一つ以上の METADATA 応答を返さなければならない。RFC 5464 では、複数のエントリーと値を一応答にまとめても、複数応答へ分けてもよい。したがって、クライアントが組み立てる単位は応答行ではなく「メールボックス名 × エントリー名」である。

同時に RFC 9590 は、注釈を参照できないメールボックスの METADATA 応答をサーバーが省略してよいとする。その場合でも LIST の最終応答は OK になり得る。最終タグは処理の終端であって、すべての局所結果を保証する総括証明ではない。

同じ空欄に見える四つの状態

NIL は明示的な結果だ。RFC 5464 では「値を持たない」ことを表す。RFC 9590 の例では、foo に色が設定されていないため、METADATA 応答の値として NIL が返る。質問への回答は存在する。

検索不能による省略には、その回答がない。対象が本来メタデータ返却の範囲内でも、対応する METADATA が観測されていない。NIL に置き換えれば、受け取っていない答えを作ることになる。

\NonExistent はさらに異なる。RFC 5258 によれば、その名前は実在するメールボックスを指さず、\NoSelect を含意する。それでも階層や購読状態の文脈では LIST に現れ得る。RFC 9590 の例も、この名前には METADATA を付けない。

SUBSCRIBED RECURSIVEMATCH では、選択条件を満たす子孫へ至る道筋として親名が返ることがある。親自身が条件を満たさなければ、親の METADATA は期待対象ではない。この欠落は検索障害ではなく選択意味論の結果である。

網羅率は母集団の設計から始まる

LIST 行の総数を分母にしてはいけない。標準パターンに合い、選択条件を満たし、要求した注釈の対象となるメールボックスを確定し、要求エントリーとの組を作る。具体値と明示的 NIL は観測済みとして数える。再帰表示だけの親は別分類にし、対象なのに応答がない組は分母から消さない。

再現可能な運用記録には、コマンドタグ、パターン、選択オプション、要求エントリー、LIST 名と属性、期待した組、観測値、NIL、欠落、再試行結果、セッションや収集の時点、キャッシュ操作が必要になる。「同期済み」という一語より、狭い事実を残すほうが後の判断に強い。

RFC 5258 は、LIST 後に子メールボックスが削除・改名され得るとも注意する。応答は時点を持つ観測であり、永久の一覧ではない。RFC 9051 の状態機械も、画面描画や利用者の認知まで証明しない。

標準化された語と運用実績を分ける

IANA には LIST-METADATA と METADATA RETURN オプションが登録されている。これは共通の語彙と参照先を作るが、採用率、製品適合性、障害率の証拠ではない。

Running-Code Primacy の読み方では、実行可能な事実はサーバーが送ったバイトとクライアントが解析できた組に限られる。最小共通仕様は相互運用の意味を定める。再試行回数、鮮度、未知値の表示、業務上の受入基準は各実装の判断であり、OK に埋め込まれてはいない。

情報源