7. サーバーレスポンス (Server Responses)

リスト内の名前の 1 つと一致するフィールド名を持つヘッダーフィールドのみが含まれる. 同様に, HEADER.FIELDS.NOT によって返されるサブセットには, 一致しないフィールド名を持つヘッダーフィールドのみが含まれる. フィールドマッチングは大文字と小文字を区別しないが, それ以外は正確である. サブセット化は, ヘッダーとボディの間の [RFC-2822] 区切り空行を除外しない. 空行は, ボディも空行もないメッセージの場合を除き, すべてのヘッダーフェッチに含まれる.

     MIME パート指定子は, このパートの [MIME-IMB] ヘッダーを参照する.

     TEXT パート指定子は, メッセージのテキストボディを参照し, [RFC-2822] ヘッダーを省略する.

        ここに, 一部のパート指定子を持つ複雑なメッセージの例を示す:

   HEADER     (メッセージの [RFC-2822] ヘッダー)
   TEXT       (メッセージの [RFC-2822] テキストボディ) MULTIPART/MIXED
        TEXT/PLAIN
        APPLICATION/OCTET-STREAM
        MESSAGE/RFC822
HEADER   (メッセージの [RFC-2822] ヘッダー)
TEXT     (メッセージの [RFC-2822] テキストボディ) MULTIPART/MIXED
1        TEXT/PLAIN
2        APPLICATION/OCTET-STREAM
        MULTIPART/MIXED
1        IMAGE/GIF
1.MIME   (IMAGE/GIF の [MIME-IMB] ヘッダー)
2        MESSAGE/RFC822
2.HEADER (メッセージの [RFC-2822] ヘッダー)
2.TEXT   (メッセージの [RFC-2822] テキストボディ) MULTIPART/MIXED
2.1      TEXT/PLAIN
2.2      MULTIPART/ALTERNATIVE
2.2.1    TEXT/PLAIN
2.2.2    TEXT/RICHTEXT

     指定されたテキストの部分文字列をフェッチすることが可能である. これは, 開き山括弧 ("\&lt;"), 最初に望むオクテットのオクテット位置, ピリオド, 望むオクテットの最大数, 閉じ山括弧 (">") をパート指定子に追加することによって行われる. 開始オクテットがテキストの末尾を超えている場合, 空文字列が返される.

RFC 3501 IMAPv4 March 2003

     テキストの末尾を超えて読み取ろうとする部分フェッチは, 適切に切り捨てられる. オクテット 0 から始まる部分フェッチは, この切り捨てが発生した場合でも, 部分フェッチとして返される.

        注記: これは, 1500 オクテットのメッセージの BODY[]``&lt;0.2048>`` が, BODY[] ではなく, サイズ 1500 のリテラルを持つ BODY[]\&lt;0> を返すことを意味する.

        注記: HEADER.FIELDS または HEADER.FIELDS.NOT パート指定子の部分文字列フェッチは, ヘッダーのサブセット化の後に計算される.

     \Seen フラグは暗黙的に設定される. これによりフラグが変更される場合, それらは FETCH レスポンスの一部として含まれるべきである (SHOULD).

  BODY.PEEK[\<section>]\&lt;\&lt;partial>>
     \Seen フラグを暗黙的に設定しない BODY[\<section>] の代替形式.

  BODYSTRUCTURE
     メッセージの [MIME-IMB] ボディ構造. これは, サーバーが [RFC-2822] ヘッダーと [MIME-IMB] ヘッダー内の [MIME-IMB] ヘッダーフィールドを解析することによって計算される.

  ENVELOPE
     メッセージのエンベロープ構造. これは, サーバーが [RFC-2822] ヘッダーを構成部分に解析し, 必要に応じてさまざまなフィールドをデフォルト設定することによって計算される.

  FLAGS
     このメッセージに設定されているフラグ.

  INTERNALDATE
     メッセージの内部日付.

  RFC822
     BODY[] と機能的に同等であり, 結果のタグなし FETCH データの構文 (RFC822 が返される) が異なる.

  RFC822.HEADER
     BODY.PEEK[HEADER] と機能的に同等であり, 結果のタグなし FETCH データの構文 (RFC822.HEADER が返される) が異なる.

  RFC822.SIZE
     メッセージの [RFC-2822] サイズ.

RFC 3501 IMAPv4 March 2003

  RFC822.TEXT
     BODY[TEXT] と機能的に同等であり, 結果のタグなし FETCH データの構文 (RFC822.TEXT が返される) が異なる.

  UID
     メッセージの一意識別子.

例: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) S: * 2 FETCH .... S: * 3 FETCH .... S: * 4 FETCH .... S: A654 OK FETCH completed

6.4.6. STORE コマンド

引数 (Arguments): シーケンスセットメッセージデータ項目名メッセージデータ項目の値

レスポンス (Responses): タグなしレスポンス: FETCH

結果 (Result): OK - store 完了 NO - store エラー: そのデータを保存できない BAD - コマンド不明または引数が無効

  STORE コマンドは, メールボックス内のメッセージに関連付けられたデータを変更する. 通常, STORE はデータの更新値をタグなし FETCH レスポンスで返す. データ項目名の接尾辞 ".SILENT" はタグなし FETCH を防止し, サーバーはクライアントが更新値を自分で決定したか, 更新値を気にしないと想定すべきである (SHOULD).

      注記: ".SILENT" 接尾辞が使用されたかどうかに関係なく, 外部ソースからのメッセージフラグの変更が観察された場合, サーバーはタグなし FETCH レスポンスを送信すべきである (SHOULD). その意図は, 競合状態なしにフラグのステータスが決定されることである.

RFC 3501 IMAPv4 March 2003

  現在定義されている, 保存できるデータ項目は以下のとおりである:

  FLAGS \&lt;flag list>
     メッセージのフラグ (\Recent 以外) を引数で置き換える. フラグの新しい値は, それらのフラグの FETCH が行われたかのように返される.

  FLAGS.SILENT \&lt;flag list>
     FLAGS と同等であるが, 新しい値を返さない.

  +FLAGS \&lt;flag list>
     メッセージのフラグに引数を追加する. フラグの新しい値は, それらのフラグの FETCH が行われたかのように返される.

  +FLAGS.SILENT \&lt;flag list>
     +FLAGS と同等であるが, 新しい値を返さない.

  -FLAGS \&lt;flag list>
     メッセージのフラグから引数を削除する. フラグの新しい値は, それらのフラグの FETCH が行われたかのように返される.

  -FLAGS.SILENT \&lt;flag list>
     -FLAGS と同等であるが, 新しい値を返さない.

例: C: A003 STORE 2:4 +FLAGS (\Deleted) S: * 2 FETCH (FLAGS (\Deleted \Seen)) S: * 3 FETCH (FLAGS (\Deleted)) S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen)) S: A003 OK STORE completed

6.4.7. COPY コマンド

引数 (Arguments): シーケンスセットメールボックス名

レスポンス (Responses): このコマンドに対する特定のレスポンスはない

結果 (Result): OK - copy 完了 NO - copy エラー: それらのメッセージをコピーできない, またはその名前へコピーできない BAD - コマンド不明または引数が無効

RFC 3501 IMAPv4 March 2003

  COPY コマンドは, 指定されたメッセージを指定された宛先メールボックスの末尾にコピーする. メッセージのフラグと内部日付はコピーで保持されるべきであり (SHOULD), Recent フラグは設定されるべきである (SHOULD).

  宛先メールボックスが存在しない場合, サーバーはエラーを返すべきである (SHOULD). メールボックスを自動的に作成すべきではない (SHOULD NOT). 宛先メールボックスを作成できないことが確実でない限り, サーバーはタグ付き NO レスポンスのテキストの接頭辞としてレスポンスコード "[TRYCREATE]" を送信しなければならない (MUST). これにより, クライアントは CREATE コマンドを試み, CREATE が成功した場合に COPY を再試行できるというヒントが得られる.

  COPY コマンドが何らかの理由で失敗した場合, サーバー実装は宛先メールボックスを COPY 試行前の状態に復元しなければならない (MUST).

例: C: A003 COPY 2:4 MEETING S: A003 OK COPY completed

6.4.8. UID コマンド

引数 (Arguments): コマンド名コマンド引数

レスポンス (Responses): タグなしレスポンス: FETCH, SEARCH

結果 (Result): OK - UID コマンド完了 NO - UID コマンドエラー BAD - コマンド不明または引数が無効

  UID コマンドには 2 つの形式がある. 最初の形式では, 引数として, 関連するコマンドに適した引数を持つ COPY, FETCH, または STORE コマンドを取る. ただし, シーケンスセット引数の数値は, メッセージシーケンス番号ではなく一意識別子である. シーケンスセットの範囲は許可されているが, 一意識別子が連続することは保証されない.

  存在しない一意識別子は, エラーメッセージを生成せずに無視される. したがって, UID FETCH コマンドがデータなしで OK を返したり, UID COPY または UID STORE が操作を実行せずに OK を返したりすることが可能である.

  2 番目の形式では, UID コマンドは SEARCH コマンド引数を持つ SEARCH コマンドを取る. 引数の解釈は SEARCH と同じである. ただし, UID SEARCH コマンドの SEARCH レスポンスで返される数値は, メッセージシーケンス番号ではなく一意識別子である.

RFC 3501 IMAPv4 March 2003

  例えば, コマンド UID SEARCH 1:100 UID 443:557 は, 2 つのシーケンスセットの共通部分, すなわちメッセージシーケンス番号範囲 1:100 と UID 範囲 443:557 に対応する一意識別子を返す.

      注記: 上記の例では, UID 範囲 443:557 が現れる. 存在しない一意識別子がエラーメッセージなしで無視されるという同じコメントがここにも当てはまる. したがって, UID 443 も 557 も存在しない場合でも, この範囲は有効であり, 既存の UID 495 を含むことになる.

      また, UID 範囲 559:* は, 559 が割り当てられた UID 値より高い場合でも, 常にメールボックス内の最後のメッセージの UID を含むことに注意すること. これは, 範囲の内容が範囲の端点の順序に依存しないためである. したがって, 端点の 1 つとして * を持つ UID 範囲は, メールボックスが空でない限り, 少なくとも 1 つのメッセージ (最も番号の大きい UID を持つメッセージ) を示す.

  タグなし FETCH レスポンスの "*" の後の数値は, UID コマンドレスポンスの場合でも, 常に一意識別子ではなくメッセージシーケンス番号である. ただし, サーバー実装は, UID が FETCH へのメッセージデータ項目として指定されたかどうかに関係なく, UID コマンドによって引き起こされる任意の FETCH レスポンスの一部として UID メッセージデータ項目を暗黙的に含めなければならない (MUST).

  注記: UID メッセージデータ項目を FETCH レスポンスの一部として含める規則は, 主に UID FETCH と UID STORE コマンドに適用され, UID をメッセージデータ項目として含まない UID FETCH コマンドも含まれる. 他の UID コマンドがタグなし FETCH を引き起こす可能性は低いが, この規則はこれらのコマンドにも適用される.

例: C: A999 UID FETCH 4827313:4828442 FLAGS S: * 23 FETCH (FLAGS (\Seen) UID 4827313) S: * 24 FETCH (FLAGS (\Seen) UID 4827943) S: * 25 FETCH (FLAGS (\Seen) UID 4828442) S: A999 OK UID FETCH completed

RFC 3501 IMAPv4 March 2003

6.5. クライアントコマンド - 実験的/拡張 (Client Commands - Experimental/Expansion)

6.5.1. X`<atom>` コマンド

引数 (Arguments): 実装定義

レスポンス (Responses): 実装定義

結果 (Result): OK - コマンド完了 NO - 失敗 BAD - コマンド不明または引数が無効

  X で接頭辞されたコマンドはすべて実験的コマンドである. この仕様の一部でないコマンド, この仕様の標準または標準トラック改訂, または IESG 承認済みの実験的プロトコルは, X 接頭辞を使用しなければならない (MUST).

  実験的コマンドによって発行される追加のタグなしレスポンスも, X で接頭辞されなければならない (MUST). サーバー実装は, クライアントが関連する実験的コマンドを発行して要求しない限り, そのようなタグなしレスポンスを送信してはならない (MUST NOT).

例: C: a441 CAPABILITY S: * CAPABILITY IMAP4rev1 XPIG-LATIN S: a441 OK CAPABILITY completed C: A442 XPIG-LATIN S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay S: A442 OK XPIG-LATIN ompleted-cay

```
 サーバーレスポンス (Server Responses)
```
サーバーレスポンスには 3 つの形式がある: ステータスレスポンス, サーバーデータ, コマンド継続リクエスト. 以下のレスポンス説明で「Contents:」によって識別されるサーバーレスポンスに含まれる情報は, 構文ではなく機能によって説明される. サーバーレスポンスの正確な構文は, 正式構文 (Formal Syntax) セクションで説明される.

クライアントは常に任意のレスポンスを受け入れる準備ができていなければならない (MUST).

ステータスレスポンスは, タグ付きまたはタグなしのいずれかにできる. タグ付きステータスレスポンスは, クライアントコマンドの完了結果 (OK, NO, BAD ステータス) を示し, コマンドに一致するタグを持つ.

一部のステータスレスポンスとすべてのサーバーデータはタグなしである. タグなしレスポンスは, タグの代わりにトークン "*" によって示される. タグなしステータスレスポンスは, サーバーグリーティング, またはコマンドの完了を示さないサーバーステータスを示す.

RFC 3501 IMAPv4 March 2003

(例えば, 差し迫ったシステムシャットダウンの警告). 歴史的な理由から, タグなしサーバーデータレスポンスは「非要求データ (unsolicited data)」とも呼ばれる. ただし, 厳密に言えば, 一方的なサーバーデータのみが真に「非要求」である.

特定のサーバーデータは, 受信時にクライアントによって記録されなければならない (MUST). これはそのデータの説明に記載されている. そのようなデータは, 後続のすべてのコマンドとレスポンスの解釈に影響を与える重要な情報を伝える (例えば, メッセージの作成または破棄を反映する更新).

他のサーバーデータは, 後で参照するために記録すべきである (SHOULD). クライアントがデータを記録する必要がない場合, またはデータの記録に明らかな目的がない場合 (例えば, 進行中の SEARCH コマンドがないときの SEARCH レスポンス), そのデータは無視すべきである (SHOULD).

一方的なタグなしサーバーデータの例は, IMAP 接続が選択済み状態のときに発生する. 選択済み状態では, サーバーはコマンド実行の一部として新しいメッセージがないかメールボックスをチェックする. 通常, これはすべてのコマンドの実行の一部である. したがって, NOOP コマンドで新しいメッセージをチェックするのに十分である. 新しいメッセージが見つかった場合, サーバーはメールボックスの新しいサイズを反映するタグなし EXISTS と RECENT レスポンスを送信する. 同じメールボックスへの複数の同時アクセスを提供するサーバー実装は, 別のエージェントが任意のメッセージフラグの状態を変更したり, メッセージを expunge したりした場合, 適切な一方的なタグなし FETCH と EXPUNGE レスポンスも送信すべきである (SHOULD).

コマンド継続リクエストレスポンスは, タグの代わりにトークン "+" を使用する. これらのレスポンスは, 不完全なクライアントコマンドの受け入れと, コマンドの残りの部分への準備ができていることを示すためにサーバーによって送信される.

7.1. サーバーレスポンス - ステータスレスポンス (Server Responses - Status Responses)

ステータスレスポンスは OK, NO, BAD, PREAUTH, BYE である. OK, NO, BAD はタグ付きまたはタグなしにできる. PREAUTH と BYE は常にタグなしである.

ステータスレスポンスには, オプションの「レスポンスコード」を含めることができる (MAY). レスポンスコードは, 角括弧内のアトムの形式のデータで構成され, 必要に応じてスペースと引数が続く. レスポンスコードには, OK/NO/BAD 条件を超えた追加情報またはステータスコードが含まれ, 追加情報に基づいてクライアントが実行できる特定のアクションがある場合に定義される.

RFC 3501 IMAPv4 March 2003

現在定義されているレスポンスコードは以下のとおりである:

  ALERT

     人間が読めるテキストには, ユーザーの注意をメッセージに向けさせる方法でユーザーに提示されなければならない (MUST) 特別な警告が含まれている.

  BADCHARSET

     必要に応じて, 文字セットの括弧付きリストが続く. 指定された文字セットがこの実装でサポートされていないため, SEARCH が失敗した. オプションの文字セットリストが指定された場合, これはこの実装でサポートされている文字セットをリストする.

  CAPABILITY

     機能のリストが続く. これは, 初期の機能リストを送信するために, 初期の OK または PREAUTH レスポンスに現れることができる. これにより, クライアントがこのレスポンスを認識する場合, 個別の CAPABILITY コマンドを送信する必要がなくなる.

  PARSE

     人間が読めるテキストは, メールボックス内のメッセージの [RFC-2822] ヘッダーまたは [MIME-IMB] ヘッダーの解析におけるエラーを表す.

  PERMANENTFLAGS

     フラグの括弧付きリストが続き, クライアントが永続的に変更できる既知のフラグを示す. FLAGS タグなしレスポンスにはあるが PERMANENTFLAGS リストにはないフラグは, 永続的に設定できない. クライアントが PERMANENTFLAGS リストにないフラグを STORE しようとした場合, サーバーは変更を無視するか, 現在のセッションの残りの間だけ状態変更を保存する. PERMANENTFLAGS リストには, 特別なフラグ \* を含めることもできる. これは, メールボックスにそれらのフラグを保存しようとすることによって新しいキーワードを作成できることを示す.

RFC 3501 IMAPv4 March 2003

  READ-ONLY

     メールボックスが読み取り専用として選択されている, または選択中のアクセスが読み書きから読み取り専用に変更された.

  READ-WRITE

     メールボックスが読み書きとして選択されている, または選択中のアクセスが読み取り専用から読み書きに変更された.

  TRYCREATE

     APPEND または COPY の試行が, (他の理由ではなく) ターゲットメールボックスが存在しないために失敗している. これは, メールボックスが最初に CREATE コマンドで作成されれば操作が成功できるというヒントをクライアントに与える.

  UIDNEXT

     10 進数が続き, 次の一意識別子値を示す. 詳細についてはセクション 2.3.1.1 を参照のこと.

  UIDVALIDITY

     10 進数が続き, 一意識別子有効性値を示す. 詳細についてはセクション 2.3.1.1 を参照のこと.

  UNSEEN

     10 進数が続き, \Seen フラグが設定されていない最初のメッセージの番号を示す.

  特定のクライアントまたはサーバー実装によって定義された追加のレスポンスコードは, このプロトコルの改訂に追加されるまで, "X" で接頭辞されるべきである (SHOULD). クライアント実装は, 認識しないレスポンスコードを無視すべきである (SHOULD).