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

6.3 クライアントコマンド - 認証済み状態 (Client Commands - Authenticated State)

認証済み状態では、メールボックスをアトミックエンティティとして操作するコマンドが許可されます。これらのコマンドのうち、SELECT および EXAMINE はアクセスのためにメールボックスを選択し、選択済み状態に入ります。

ユニバーサルコマンド (CAPABILITY、NOOP、および LOGOUT) に加えて、次のコマンドは認証済み状態で有効です：ENABLE、SELECT、EXAMINE、NAMESPACE、CREATE、DELETE、RENAME、SUBSCRIBE、UNSUBSCRIBE、LIST、STATUS、APPEND、および IDLE。

6.3.1 ENABLE コマンド​

引数 (Arguments): 機能名

応答 (Responses): このコマンドには特定の応答がありません

結果 (Result):

  • OK - 関連する機能が有効化されました
  • BAD - 引数がないか、引数に構文エラーがあります

いくつかの IMAP 拡張機能により、サーバーは特定の状況下でこれらの拡張機能に固有の未承諾応答を返すことができます。ただし、サーバーは、クライアントがそのような拡張機能をサポートしており、したがって拡張応答データを正しく解析および処理できることを知るまで、それらの未承諾応答を送信できません (タグ付きまたはタグなし OK/NO/BAD 応答に含まれる応答コード (セクション 7.1 を参照) は例外で、常に送信できます)。

ENABLE コマンドは、クライアントが特定の拡張機能をサポートしていることを明示的に示します。これは、クライアントがサポートする拡張機能を含む単純な定数文字列を送信でき、サーバーが両方がサポートする共有サブセットを有効にするように設計されています。

ENABLE コマンドは機能名のリストを取り、サーバーに名前付き拡張機能を有効にするよう要求します。ENABLE を使用して有効にすると、各拡張機能は IMAP 接続が閉じられるまでアクティブのままになります。各引数について、サーバーは次のことを行います：

  • 引数がサーバーに既知の拡張機能でない場合、サーバーは引数を無視しなければなりません (しなければなりません)。

  • 引数がサーバーに既知の拡張機能であり、ENABLE を使用して有効にすることが特に許可されていない場合、サーバーは引数を無視しなければなりません (しなければなりません)。(拡張機能について知っていることは、必ずしもその拡張機能をサポートしていることを意味するわけではないことに注意してください。)

  • 引数がサーバーによってサポートされており、有効にする必要がある拡張機能である場合、サーバーは接続の期間中、拡張機能を有効にしなければなりません (しなければなりません)。拡張機能を一度有効にすると、それを無効にする方法はないことに注意してください。

ENABLE コマンドが成功した場合、サーバーは、上記で指定されたすべての有効化された拡張機能を含むタグなし ENABLED 応答 (セクション 7.2.1) を送信しなければなりません (しなければなりません)。拡張機能が有効化されていない場合でも、ENABLED 応答が送信されます。

クライアントは、サーバーによって有効にする必要がある拡張機能のみを含めるべきです (すべきです)。たとえば、CAPABILITY 応答で IMAP4rev1 と IMAP4rev2 の両方が通知されている場合、クライアントは IMAP4rev2 固有の動作を有効にできます。将来の RFC がこのリストに追加される可能性があります。

ENABLE コマンドは、メールボックスが選択される前の認証済み状態でのみ有効です。クライアントは、メールボックスを SELECT/EXAMINE した後に ENABLE を発行してはなりません (してはなりません)。ただし、サーバー実装は、接続の期間中にメールボックスが選択されていないか、以前に選択されていないかをチェックする必要はありません。

ENABLE コマンドは、セッション中に複数回発行できます。これは加算的です。つまり、「ENABLE a b」の後に「ENABLE c」が続く場合、単一のコマンド「ENABLE a b c」と同じです。複数の ENABLE コマンドが発行される場合、各対応する ENABLED 応答は、対応する ENABLE コマンドによって有効化された拡張機能のみを含むべきです (すべきです)。つまり、上記の例では、「ENABLE c」への ENABLED 応答に「a」または「b」を含めるべきではありません。

ENABLE のパイプライン化に制限はありません。たとえば、ENABLE を送信してから直ちに SELECT を送信したり、LOGIN の直後に ENABLE を送信したりすることが可能です。

サーバーは、ENABLE の実行の結果として CAPABILITY リストを変更してはなりません (してはなりません)。つまり、ENABLE コマンドの直後に発行された CAPABILITY コマンドは、ENABLE コマンドの前に発行された CAPABILITY コマンドと同じ機能をリストしなければなりません (しなければなりません)。これは次の例で示されています。下記の「X-GOOD-IDEA」は ENABLED できる架空の拡張機能であることに注意してください。

C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
S: t1 OK foo
C: t2 ENABLE CONDSTORE X-GOOD-IDEA
S: * ENABLED X-GOOD-IDEA
S: t2 OK foo
C: t3 CAPABILITY
S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
S: t3 OK foo again

次の例では、クライアントは条件付きストア (CONDSTORE) 拡張機能 [RFC7162] を有効にします：

C: a1 ENABLE CONDSTORE
S: * ENABLED CONDSTORE
S: a1 OK Conditional Store enabled

6.3.1.1 ENABLE コマンドを使用する可能性のある拡張機能の設計者への注意​

良い代替設計がない限り、IMAP 拡張機能の設計者は ENABLE を必要とする拡張機能を作成することは推奨されません。具体的には、展開されたサーバー応答に潜在的に互換性のない動作変更を引き起こす拡張機能 (したがって ENABLE から恩恵を受ける) は、そうでない拡張機能よりも高い複雑性コストがあります。

に最終更新