メインコンテンツまでスキップ

5. 運用上の考慮事項 (Operational Considerations)

  1. CTL およびその他の非グラフィック文字は, ユーザーインターフェースでの表現が困難であり, 避けるのが最善である.

  2. リストワイルドカード文字 ("%" と "*") はメールボックス名内で有効であるが, ワイルドカード解釈との競合のため, そのようなメールボックス名を LIST および LSUB コマンドで使用することは困難である.

RFC 3501 IMAPv4 March 2003

  1. 通常, 階層のレベルを区切るために文字 (サーバー実装によって決定される) が予約されている.

  2. "#" と "&" の 2 つの文字は, 慣例により意味を持ち, その慣例で使用する場合を除いて避けるべきである.

5.1.1. メールボックス階層命名 (Mailbox Hierarchy Naming)​

階層的なメールボックス名をエクスポートしたい場合は, メールボックス名は, 単一の文字を使用して階層のレベルを区切る, 左から右への階層でなければならない (MUST). 同じ階層区切り文字が, 単一の名前内のすべての階層レベルで使用される.

5.1.2. メールボックス名前空間命名規則 (Mailbox Namespace Naming Convention)​

慣例により, "#" で始まるメールボックス名の最初の階層要素は, 名前の残りの部分の「名前空間 (namespace)」を識別する. これにより, それぞれが独自の名前空間を持つ異なるタイプのメールボックスストアを明確に区別できる.

    例えば, USENET ニュースグループへのアクセスを提供する実装は, "#news" 名前空間を使用して, USENET ニュースグループの名前空間を他のメールボックスの名前空間から分割してもよい (MAY). したがって, comp.mail.misc ニュースグループのメールボックス名は "#news.comp.mail.misc" になり, "comp.mail.misc" という名前は別のオブジェクト (例えば, ユーザーのプライベートメールボックス) を参照できる.

5.1.3. メールボックス国際命名規則 (Mailbox International Naming Convention)​

慣例により, IMAP4rev1 の国際メールボックス名は, [UTF-7] で説明されている UTF-7 エンコーディングの修正版を使用して指定される. 修正 UTF-7 は, このプロトコルの以前のバージョンを実装するサーバーでも使用できる場合がある.

修正 UTF-7 では, "&" を除く印刷可能な US-ASCII 文字はそれ自体を表す. つまり, オクテット値 0x20-0x25 と 0x27-0x7e の文字である. 文字 "&" (0x26) は, 2 オクテットのシーケンス "&-" で表される.

その他すべての文字 (オクテット値 0x00-0x1f と 0x7f-0xff) は, [UTF-7] からさらに修正され, "/" の代わりに "," が使用される修正 BASE64 で表される. 修正 BASE64 は, それ自体を表すことができる印刷可能な US-ASCII 文字を表すために使用してはならない (MUST NOT).

RFC 3501 IMAPv4 March 2003

"&" は修正 BASE64 へのシフトに使用され, "-" は US-ASCII へのシフトバックに使用される. BASE64 から US-ASCII への暗黙のシフトはなく, ヌルシフト (BASE64 中の "-&" ; US-ASCII 中の "&-" は "&" を意味することに注意) は許可されない. ただし, すべての名前は US-ASCII で始まり, US-ASCII で終わらなければならない (MUST). つまり, 非 ASCII の ISO-10646 文字で終わる名前は "-" で終わらなければならない (MUST)).

これらの修正の目的は, UTF-7 の以下の問題を修正することである:

  1) UTF-7 はシフトに "+" 文字を使用する. これは, 特に USENET ニュースグループ名におけるメールボックス名での "+" の一般的な使用と競合する.

  2) UTF-7 のエンコーディングは, "/" 文字を使用する BASE64 である. これは, 一般的な階層区切り文字としての "/" の使用と競合する.

  3) UTF-7 は "\" のエンコードされていない使用を禁止する. これは, 一般的な階層区切り文字としての "\" の使用と競合する.

  4) UTF-7 は "~" のエンコードされていない使用を禁止する. これは, 一部のサーバーでのホームディレクトリインジケータとしての "~" の使用と競合する.

  5) UTF-7 は同じ文字列を表す複数の代替形式を許可する. 特に, 印刷可能な US-ASCII 文字はエンコード形式で表すことができる.

  修正 UTF-7 は慣例であるが, "&" 文字が埋め込まれたメールボックス名のサーバー処理に特定の要件を確立する. 特に, サーバー実装は, 修正 UTF-7 名の修正 BASE64 部分の正確な形式を保持し, そのテキストを大文字と小文字を区別するものとして扱わなければならない (MUST). 名前が他の点では大文字と小文字を区別しないか, 大文字と小文字を畳み込む場合でも同様である.

  サーバー実装は, CREATE への引数として使用される "&" 文字が埋め込まれたメールボックス名が, 正しく修正された UTF-7 構文であり, 余分なシフトがなく, それ自体を表すことができる印刷可能な US-ASCII 文字の修正 BASE64 でのエンコーディングがないことを検証すべきである (SHOULD). ただし, クライアント実装は, サーバーがこれを行うことに依存してはならず (MUST NOT), 修正 UTF-7 構文に準拠しない限り, "&" 文字が埋め込まれたメールボックス名を作成しようとしてはならない (SHOULD NOT).

  修正 UTF-7 の慣例に従わないメールストアをエクスポートするサーバー実装は, 非 ASCII 文字または "&" 文字のいずれかを含むメールボックス名を修正 UTF-7 に変換しなければならない (MUST).

RFC 3501 IMAPv4 March 2003

       例えば, ここに英語, 中国語, 日本語のテキストが混在するメールボックス名がある:
       ~peter/mail/&U,BTFw-/&ZeVnLIqe-

       例えば, 文字列 "&Jjo!" は, "!" の前に US-ASCII へのシフトが含まれていないため, 有効なメールボックス名ではない. 正しい形式は "&Jjo-!" である. 文字列 "&U,BTFw-&ZeVnLIqe-" は, 余分なシフトが含まれているため許可されない. 正しい形式は "&U,BTF2XlZyyKng-" である.

5.2. メールボックスサイズとメッセージステータス更新 (Mailbox Size and Message Status Updates)​

いつでも, サーバーはクライアントが要求しなかったデータを送信できる. 時には, そのような動作は必須 (REQUIRED) である. 例えば, サーバー以外のエージェントがメールボックスにメッセージを追加したり (例えば, 新しいメッセージの配信), メールボックス内のメッセージのフラグを変更したり (例えば, 複数のエージェントによる同じメールボックスへの同時アクセス), メールボックスからメッセージを削除したりすることもできる (MAY). サーバーは, コマンドの処理中にメールボックスサイズの変更が観察された場合, メールボックスサイズの更新を自動的に送信しなければならない (MUST). サーバーは, クライアントがそのような更新を明示的に要求することを要求せずに, メッセージフラグの更新を自動的に送信すべきである (SHOULD).

メッセージの削除に関するクライアントへのサーバー通知には, 同期エラーを防ぐための特別な規則が存在する. 詳細については, EXPUNGE レスポンスの説明を参照のこと. 特に, メールボックス内のメッセージ数を減らす EXISTS レスポンスを送信することは許可されていない. これを行うことができるのは EXPUNGE レスポンスのみである.

クライアントがサーバーからのデータの記憶についてどのような実装決定を行うかに関係なく, クライアント実装はメールボックスサイズの更新を記録しなければならない (MUST). 初期メールボックス選択後のコマンドがメールボックスのサイズを返すと想定してはならない (MUST NOT).

5.3. 進行中のコマンドがない場合のレスポンス (Response when no Command in Progress)​

サーバー実装は, 進行中のコマンドがない間にタグなしレスポンス (EXPUNGE を除く) を送信することが許可されている. そのようなレスポンスを送信するサーバー実装は, フロー制御の考慮事項に対処しなければならない (MUST). 具体的には, (1) データのサイズが基盤となるトランスポートの利用可能なウィンドウサイズを超えないことを検証するか, (2) ノンブロッキング書き込みを使用しなければならない (MUST).

RFC 3501 IMAPv4 March 2003

5.4. 自動ログアウトタイマー (Autologout Timer)​

サーバーに非アクティブ自動ログアウトタイマーがある場合, そのタイマーの期間は少なくとも 30 分でなければならない (MUST). その間隔内にクライアントから任意のコマンドを受信することは, 自動ログアウトタイマーをリセットするのに十分であるべきである (SHOULD).

5.5. 進行中の複数のコマンド (Multiple Commands in Progress)​

クライアントは, あいまいさの規則 (下記参照) と基盤となるデータストリームのフロー制御制約に従い, コマンドの完了結果レスポンスを待たずに別のコマンドを送信してもよい (MAY). 同様に, サーバーは, あいまいさの規則に従い, 現在のコマンドの処理を完了する前に別のコマンドの処理を開始してもよい (MAY). ただし, コマンド継続リクエストレスポンスとコマンド継続は, 後続のコマンドが開始される前にネゴシエーションされなければならない (MUST).

例外は, 他のコマンドの結果に影響を与えるコマンドによってあいまいさが生じる場合である. クライアントは, あいまいさが生じる場合, 待たずに複数のコマンドを送信してはならない (MUST NOT). サーバーが可能性のあるあいまいさを検出した場合, クライアントによって与えられた順序でコマンドを完了まで実行しなければならない (MUST).

あいまいさの最も明白な例は, コマンドが別のコマンドの結果に影響を与える場合である. 例えば, メッセージのフラグの FETCH と, 同じメッセージのフラグの STORE である.

明白でないあいまいさは, タグなし EXPUNGE レスポンスを許可するコマンド (FETCH, STORE, SEARCH 以外のコマンド) で発生する. タグなし EXPUNGE レスポンスは, 後続のコマンドのシーケンス番号を無効にする可能性があるためである. これは, サーバーが FETCH, STORE, SEARCH コマンドのいずれかの進行中に EXPUNGE レスポンスを送信することを禁止されているため, FETCH, STORE, SEARCH コマンドでは問題にならない. したがって, クライアントが FETCH, STORE, SEARCH 以外のコマンドを送信する場合, メッセージシーケンス番号を持つコマンドを送信する前に, 完了結果レスポンスを待たなければならない (MUST).

    注記: UID FETCH, UID STORE, UID SEARCH は FETCH, STORE, SEARCH とは異なるコマンドである. クライアントが UID コマンドを送信する場合, メッセージシーケンス番号を持つコマンドを送信する前に完了結果レスポンスを待たなければならない.