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

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

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

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

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

  4. 2つの文字、"#" および "&" は、慣例的に意味を持ち、その慣例で使用される場合を除いて回避する必要があります。

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

階層的なメールボックス名をエクスポートする場合、メールボックス名は必須 (MUST) 左から右への階層構造を持ち、階層のレベルを区切るために単一の文字を使用します。同じ階層区切り文字が、単一の名前内のすべての階層レベルに使用されます。

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

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

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

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

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

修正 UTF-7 では、"&" を除く印刷可能な US-ASCII 文字はそれ自体を表します。つまり、オクテット値 0x20-0x25 および 0x27-0x7e を持つ文字です。文字 "&" (0x26) は、2オクテットシーケンス "&-" で表されます。

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

"&" は修正 BASE64 にシフトするために使用され、"-" は US-ASCII に戻すために使用されます。BASE64 から US-ASCII への暗黙的なシフトはなく、NULL シフト (BASE64 内の "-&"。US-ASCII 内の "&-" は "&" を意味することに注意) は許可されません。ただし、すべての名前は US-ASCII で開始し、US-ASCII で終了する必須 (MUST) があります。つまり、非 ASCII ISO-10646 文字で終わる名前は "-" で終了する必要があります。

これらの修正の目的は、UTF-7 の次の問題を修正することです。

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

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

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

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

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

修正 UTF-7 は慣例ですが、埋め込まれた "&" 文字を持つ任意のメールボックス名のサーバー処理に関する特定の要件を確立します。特に、サーバー実装は必須 (MUST) 修正 UTF-7 名の修正 BASE64 部分の正確な形式を保持し、そのテキストを大文字と小文字を区別するものとして扱います。名前がそうでない場合でも、大文字と小文字を区別しないか、大文字小文字を折りたたむ場合があります。

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

修正 UTF-7 規則に従わないメールストアをエクスポートするサーバー実装は必須 (MUST) 非 ASCII 文字または "&" 文字を含む任意のメールボックス名を修正 UTF-7 に変換します。

例えば、英語、中国語、日本語のテキストを混在させたメールボックス名は次のとおりです。
~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) があります。

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

サーバーに非アクティブ自動ログアウトタイマーがある場合、そのタイマーの期間は必須 (MUST) 少なくとも30分である必要があります。その間隔中のクライアントからの任意のコマンドの受信は推奨 (SHOULD) 自動ログアウトタイマーをリセットするのに十分です。

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

クライアントは可能 (MAY) あいまいさ規則 (下記参照) および基礎となるデータストリームのフロー制御制約の対象となる、コマンドの完了結果レスポンスを待たずに別のコマンドを送信できます。同様に、サーバーは可能 (MAY) あいまいさ規則の対象となる、現在のコマンドを完了する前に別のコマンドの処理を開始できます。ただし、任意のコマンド継続リクエストレスポンスおよびコマンド継続は必須 (MUST) 後続のコマンドが開始される前に交渉されます。

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

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

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

注記: UID FETCH、UID STORE、および UID SEARCH は、FETCH、STORE、および SEARCH とは異なるコマンドです。クライアントが UID コマンドを送信する場合、メッセージシーケンス番号を持つコマンドを送信する前に、完了結果レスポンスを待機する必要があります。

に最終更新