要約

  • LANGUAGE は固定の人間向け応答を切り替え、NAMESPACE 接頭辞の翻訳表示を返せるが、その表示は共有メールボックスの別名や新しい正規名ではない。
  • アクティブ・コンパレーターは SEARCH、SORT、THREAD の一部の意味を決めるため、結果には復号、文字集合変換、比較規則、フォールバック、安全層世代の来歴が要る。

一つの設定画面が二つの決定を隠す

利用者は「日本語」を一度選べば、メニューもフォルダー名も検索も同じ言語原理で動くと思いやすい。RFC 5255 は、その期待をプロトコル上の一権限にはしていない。

LANGUAGE はサーバーの人間向け説明を選ぶ。I18NLEVEL は文字列をどう照合するかを選ぶ。前者はエラーメッセージや名前空間接頭辞の表示を変え、後者は見つかるメッセージや順序を変え得る。二つは別の機能として広告できる。

運用記録に locale だけを残すと、差異を説明できない。画面の文言だけが変わったのか、接頭辞の訳が変わったのか、比較器が変わったのか、言語的比較に失敗してオクテット比較へ移ったのかが分からない。

NAMESPACE の翻訳は正規名への案内板である

RFC 5255 の LANGUAGE は固定されたサーバー文字列に限定される。共有メールボックスにローカライズされた別名を付けることは、別の仕組みに委ねられている。翻訳表示は命名権を持たない。

TRANSLATION は正規の NAMESPACE 接頭辞に対応する表示用文字列を返す。クライアントが両者を変換しながらメールボックス名を表示する。したがって、関係を片方向のコピーにしてはならない。

表示文字列だけを永続化すると、言語切替がメールボックスの作成や移動に見える。キャッシュ、ブックマーク、権限画面、移行処理も誤った名前を正本として扱いかねない。正規接頭辞、翻訳、言語タグ、サーバー、セッション世代を一組で記録する必要がある。

LANGUAGE 応答にも状態遷移がある。一つのタグは選択された言語を示す。複数タグは利用可能な言語を列挙するだけで、現在値を変えない。要求が失敗すれば以前の言語が残る。利用者が押したボタンと、サーバーが受理した状態は別である。

default も恒久的な属性ではない。管理者が好む言語を求める指定で、現在の利用者によって結果が変わり得る。これは表示ポリシーであって、人の言語的身元ではない。

セキュリティ層の前後で選択を継承しない

LANGUAGE は認証前にも有効である。期限切れパスワードやセキュリティ失敗を理解できる言語で伝える価値があるからだ。一方、その段階はまだ保護されていない可能性がある。

能動攻撃者は LANGUAGE 交渉を抑止または改変し、STARTTLS や認証エラーを読みにくくできる。そこで RFC 5255 は、TLS または SASL のセキュリティ層が有効になった後、LANGUAGE を再発行するよう求める。

再発行は同じ希望の繰り返しではなく、新しい権威世代での選択である。ログには、保護前の要求、保護確立時刻、保護後の要求と応答、適用開始点を残すべきだ。

それでも説明文自体が認証証拠になるわけではない。LANGUAGE は資格情報を承認せず、結果コードを書き換えず、サーバー認証を代行しない。構造化された結果、人間向け説明、保護されたチャネルにはそれぞれの証跡がある。

コンパレーターは検索文の一部である

明示的選択がないときに使うのがデフォルト・コンパレーター、セッションで現在使うのがアクティブ・コンパレーターである。I18NLEVEL=1 は i;unicode-casemap を必須とし、I18NLEVEL=2 は COMPARATOR による確認と変更を加える。

アクティブな規則は、件名、本文、送信者、宛先、ヘッダーなど所定の SEARCH キーに作用する。SORT の関連キーや THREAD の件名比較にも使われる。しかし、保存されたすべての文字列を一括して正規化する規則ではない。

認証後、サーバーのデフォルトは接続中に固定されなければならない。暗黙の検索に安定した基準を与えるためである。それでも明示的な COMPARATOR はアクティブ値を変えるため、最終値だけでなく要求と応答を保存する必要がある。

必要な演算も異なる。SEARCH は部分文字列、SORT は順序、順序は等価性を必要とする。選択された比較器が演算を提供できなければ、サーバーは命令を失敗させる。比較器を選べた事実は、すべての命令を処理できる証明ではない。

比較規則に届く前の処理が結果を分ける

メッセージの文字列は最初に MIME エンコードを除去され、次に比較器が期待する文字集合へ変換される。MIME の除去に失敗する場合の一部は実装依存であり、変換や妥当性検査も失敗し得る。

部分文字列検索では、変換失敗時に解読後の元表現を i;octet で比較する。比較結果が undefined の場合にも同様のフォールバックがある。並べ替えでは、変換・検証に成功した群をアクティブ規則で、失敗群を i;octet で整列し、後者を後ろへ置く。

画面には一つの一覧しか出ないが、その内部では二つの規則が使われているかもしれない。検索一致が言語的同値ではなくバイト一致によることも、末尾のメッセージが低い順位ではなく変換失敗を示すこともある。

再現可能な証跡には、対象コーパス、フィールド、宣言文字集合、MIME 除去、変換、検証、要求と選択された比較器、フォールバック、結果集合と順序が必要である。検索語だけでは判断過程を再生できない。

内容が同じでも結果の世代は変わる

二つの実装が同じメッセージを持っていても、対応文字集合や比較器が違えば結果は異なり得る。同じサーバーでも Unicode ライブラリやデコーダーの更新後に答えが変わる可能性がある。

この差は、検索が信用できないことを意味しない。検索をバージョン付きの実行結果として扱うべきだという意味である。「見つからない」を、メッセージ不在、対象外フィールド、復号失敗、変換失敗、比較器不足、未定義結果、オクテットへの回退に分解できなければならない。

IANA の IMAP 能力登録簿には現在も LANGUAGE、I18NLEVEL=1、I18NLEVEL=2 が RFC 5255 とともに載る。登録は名前と参照先を証明するだけで、普及率、実装品質、比較アルゴリズムの同一性を証明しない。

RFC 6855 は後にユーザー名、メールアドレス、ヘッダー、メールボックス名処理へ UTF-8 を導入し、RFC 9051 は IMAP4rev1 を置き換えた。この経緯は、固定応答の言語変更が識別子全体の国際化ではなかったことを示す。

Lu Heng の現実層で考えると、翻訳表示、正規名、比較結果、安全チャネルはすべて実在する。ただし、それぞれの権威は別である。表示から正規名へ、結果から比較世代へ戻れるときだけ、一つに見える体験を安全に運用できる。

出典