要約

  • selection option は結果集合に入る名前を決め、return option はすでに選ばれた名前へ情報を加える。要求を失った一覧には、各行が現れた理由が残らない。
  • RECURSIVEMATCH では、親自身が SUBSCRIBED を満たさなくても子孫の一致で返され、\NonExistent を伴う場合もある。CHILDINFO はその限定された因果を示す。

クリックできそうな行が、操作対象とは限らない

メールクライアントの木は、利用者に判断を急がせる。インデントは包含関係、開閉用の印は子の存在、行の選択状態はオブジェクトの実在を思わせる。だが RFC 5258 が返すのは、無条件の全体像ではなく、特定の問いへの答えである。

LIST-EXTENDED では、reference name とパターンが照合面を定める。selection option がどの名前を結果に含めるかを決め、return option がその結果へどの情報を付けるかを決める。さらに、認証主体、能力の世代、処理時点が答えの範囲を限定する。

同じサーバー状態でも、要求が違えば正しい木は変わる。購読名だけを選ぶ要求、すべてのローカル名を選んだ後で購読状態を付記する要求、リモート名まで対象にする要求、深い位置にある購読済みの子を説明するため親を返す要求は、互いに別の投影を作る。

したがって監査が保存すべきものは描画済みの木だけではない。広告された capability、サーバーとセッション、認証主体、reference name、元のパターン、正規化された照合パターン、selection と return の各 option、command tag、未タグ応答の全体、処理時刻が必要になる。問いを捨てて答えだけを保管すれば、後から行の権限を説明できない。

集合を変える指定と、行を説明する指定

selection option はメンバーシップを決める。通常、名前は少なくとも一つの正規 LIST パターンに一致し、すべての選択条件を満たさなければならない。RECURSIVEMATCH だけが、親名について明示された特別規則を持つ。

return option は選択済みの名前に情報を付けるもので、新しい名前を結果に追加してはならない。この区別を実装上の都合でつぶすと、出力の形が似ていても別の質問への答えになる。

SUBSCRIBED は両者の違いをはっきり示す。selection option として指定した場合、現存メールボックスではなく購読名を選ぶ。現存する箱が除外される一方、削除後も購読記録だけ残った名前が含まれ得る。return option として指定した場合は、基礎となる LIST がすでに選んだ名前に正確な購読状態を付けるだけで、集合を絞りも広げもしない。

SUBSCRIBED selection は同名の return option を暗黙に伴うため、選択行には \Subscribed が付く。それでも原因と注釈を区別する必要がある。移行や棚卸しでは、「購読だから選ばれた」のか、「別の理由で選ばれた行が購読済みだった」のかが重要だからだ。

LIST (SUBSCRIBED) を LSUB の別名として扱うこともできない。拡張 LIST は属性を通常の意味で正確かつ完全に返す。LSUB には歴史的な特殊挙動がある。両方を一つの「購読フォルダー一覧」に正規化すると、RFC 5258 が設けた差を消してしまう。

親自身は条件に落ちている

Foo/Baz だけが購読済みで、Foo は未購読だとする。一階層だけに一致するパターンでは子は範囲外になり、SUBSCRIBED 条件では親が落ちる。そのままなら空の結果になり、深い位置の購読項目を利用者に示せない。

RECURSIVEMATCH を加えると、サーバーは Foo と CHILDINFO (SUBSCRIBED) を返せる。親は要求の正規 LIST パターンには一致していなければならない。しかし、親を返す原因となった子孫はそのパターンに一致しなくてよい。

この行が述べるのは、「少なくとも一つの子孫が条件を満たし、その位置を説明するために親名を返した」ということだ。親が購読済みだとは述べていない。CHILDINFO を捨て、名前だけをキャッシュすれば、説明用の祖先が直接購読された箱に変質する。

さらに、画面に出たすべての行へ SELECT、移動、削除の操作を与える設計は危険である。表示に必要だった名前と、操作可能性が確認されたオブジェクトは別の現実層にある。

規格は RECURSIVEMATCH の単独使用と、REMOTE だけを併用する形を BAD にする。別の選択条件が子孫で成立したことを説明するための option だからだ。一般的な「木全体を再帰取得する」指定ではない。

存在しない親が正しく返る

IMAP の階層名では、文字列上の各祖先が実在するメールボックスである必要はない。Customers/ABC が存在しても Customers という箱は存在しない構成が可能だ。それでも、子の位置を示すには親名が要る。

この場合、親行には \NonExistent と CHILDINFO (SUBSCRIBED) が同時に付く。矛盾ではない。前者は親名が現存メールボックスを指さず、\NoSelect を含意することを示す。後者は子孫の選択条件が親行を結果へ導いたことを示す。

\Subscribed と \NonExistent も両立する。購読は名前に結び付く状態で、存在はメールボックス・オブジェクトの状態である。削除後に購読記録が残れば、両方が真になる。購読を存在証明にすると、まさに整理対象となる残留状態が見えなくなる。

RFC 2342 の NAMESPACE が扱う境界とは重なるが同じではない。NAMESPACE は個人用、他利用者用、共有の名前構造を説明し、存在やアクセスを保証しない。RFC 5258 は、発見クエリを実行した後でさえ、行の出現理由がその行自身でなく子孫にある場合を扱う。名前の文法と選択の因果は別々に記録すべきだ。

CHILDINFO は理由であって、子の識別子ではない

CHILDINFO は、非一致の祖先を返す原因になった選択条件を挙げ、少なくとも一つの子孫が条件を満たしたことを伝える。どの子かは示さない。名前も状態も固定しない。

LIST 応答から次の操作までに、別の主体が子を削除または改名するかもしれない。ACL が変わり、同じ利用者から見えなくなるかもしれない。後続の探索で該当する子が見つからなくても、クライアントは処理できなければならない。CHILDINFO は観測時点の原因であり、永続的な外部キーではない。

複数の LIST を待たずに送る場合、原因情報は応答の帰属にも役立つ。未タグの LIST 行をどの問いへ結び付けるかには、要求 option、受信順序、CHILDINFO の条件が必要になる。最終のタグ付き応答だけでは各行の業務上の意味を再構成できない。

一致した子も返す場合、サーバーは重複する CHILDINFO を省くべきだとされる。しかし SHOULD は不在推論の保証ではない。クライアントは冗長な情報を二重計上せず受け入れ、情報がないことから子がないと断定してはならない。

CHILDINFO と \HasChildren も別物だ。前者は selection によって親が現れた理由、後者はナビゲーションのためのアクセス可能な子の状態を表す。因果の来歴と構造のヒントを同じ列へ押し込めてはならない。

展開用の印は主体と時刻に束縛される

CHILDREN return option は \HasChildren または \HasNoChildren を要求する。大きな階層をすべて取得せず、折りたたまれた木を描くための効率化である。だが効率化の結果を永続的な属性へ昇格させる根拠はない。

子が実在しても、認証中の利用者が一つもアクセスできないなら、サーバーは \HasChildren を返すべきではない。ただし効率的な計算が難しいこともある。処理時には正しかった属性も、次のクリックまでに削除や権限変更で古くなる。

\HasNoChildren は、現在の認証主体がアクセスできる子メールボックスがないことを示す。あらゆる主体に対して子が存在しないとは言わない。また、子が存在せず将来も作成できないことを示す \NoInferiors とも違う。両者を永続的な「葉」フラグにすると、可視性と構造的不可能性が混同される。

安全なキャッシュキーには、サーバー、アカウントまたは主体、namespace 世代、メールボックス名、アクセス方針の世代、観測時刻が入る。展開操作は再発見の契機であり、一度の \HasNoChildren を理由に保存済み子孫を削除する命令ではない。

情報を増やしても正規台帳にはならない

REMOTE はローカルだけでなくリモートのメールボックスまで処理対象を広げる特殊な selection option で、対応する return option はない。それでも、返されたリモート名が到達可能であること、SELECT が成功すること、メッセージを読めることは証明しない。

LIST-STATUS は状態、SPECIAL-USE は役割、NOTIFY と CONTEXT は更新の仕組みを加える。RFC 4314 の ACL は、名前の出現と権利を分離する。木が豊かで新しくなっても、要求、主体、世代から独立した全体台帳にはならない。

IANA の registry は capability と mailbox name attribute の共通語彙を提供する。登録は token と規範参照の存在を示すだけで、特定サーバーの広告、実装、計算の正しさを証明しない。RFC 9051 の現代的 IMAP でも、証拠は「どのコマンドが、どの主体と状態に対して走り、なぜ各行が出たか」に戻る。

Lu Heng の reality layer の考え方を適用すると、管理責任が見えやすい。返された親は一回のクエリ結果として実在する。子はその時点で報告された原因として実在する。メールボックス、購読、権利、同期状態、画面ノードはそれぞれ別に実在する。画面から要求と応答へ、さらに独立した確認へ戻れる間だけ、抽象化は信頼できる。

情報源