Network Working Group A. Gulbrandsen, Ed.
Request for Comments: 5161 Oryx Mail Systems GmbH
Category: Standards Track A. Melnikov, Ed.
Isode Limited
March 2008
The IMAP ENABLE Extension
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
Most IMAP extensions are used by the client when it wants to and the server supports it. However, a few extensions require the server to know whether a client supports that extension. The ENABLE extension allows an IMAP client to say which extensions it supports.
それが望んでいるし、サーバーがサポートしているとき、ほとんどのIMAP拡張機能は、クライアントによって使用されています。しかし、いくつかの拡張機能は、クライアントがその拡張をサポートしているかどうかを知るためにサーバーを必要としています。拡張を有効にIMAPクライアントは、それがサポートする拡張言うことができます。
Several IMAP extensions allow the server to return unsolicited responses specific to these extensions in certain circumstances. However, servers cannot send those unsolicited responses until they know that the clients support such extensions and thus won't choke on the extension response data.
いくつかのIMAP拡張は、サーバが特定の状況では、これらの拡張機能に固有の未承諾の応答を返すことができます。彼らは、クライアントがそのような拡張をサポートしていることを知っているので、拡張応答データに詰まらなくなるまでただし、サーバーは、これらの迷惑な応答を送信することはできません。
Up until now, extensions have typically stated that a server cannot send the unsolicited responses until after the client has used a command with the extension data (i.e., at that point the server knows the client is aware of the extension). CONDSTORE ([RFC4551]), ANNOTATE ([ANNOTATE]), and some extensions under consideration at the moment use various commands to enable server extensions. For example, CONDSTORE uses a SELECT or FETCH parameter, and ANNOTATE uses a side effect of FETCH.
これまで、拡張子は通常、サーバは、クライアントが（すなわち、その時点で、サーバーは、クライアントが拡張子を認識している知っている）拡張データを使用してコマンドを使用した後まで未承諾応答を送信することができないと述べました。 CONDSTORE（[RFC4551]）、ANNOTATE（[ANNOTATE]）、及び現時点で検討中のいくつかの拡張機能は、サーバー拡張機能を有効にするには、さまざまなコマンドを使用します。例えば、CONDSTOREはSELECTまたはFETCHパラメータを使用し、そしてANNOTATEフェッチの副作用を使用します。
The ENABLE extension provides an explicit indication from the client that it supports particular extensions. This is done using a new ENABLE command.
ENABLE拡張機能は、特定の拡張機能をサポートするクライアントからの明示的な指示を与えます。これは新しいenableコマンドを使用して行われます。
An IMAP server that supports ENABLE advertises this by including the word ENABLE in its capability list.
ENABLEサポートIMAPサーバは単語能力リストにENABLEを含むことによって、これをアドバタイズします。
Most IMAP extensions do not require the client to enable the extension in any way.
ほとんどのIMAP拡張は、どのような方法で拡張を可能にするために、クライアントを必要としません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Formal syntax is defined by [RFC5234] and [RFC3501].
正式な構文は[RFC5234]及び[RFC3501]で定義されます。
Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. The five characters [...] means that something has been elided.
「C：」で始まる例ラインはで始まるクライアントとものによって送信された「S：」サーバーで。 5つの文字[...]何かが省略されていることを意味します。
Arguments: capability names
引数：機能名
Result: OK: Relevant capabilities enabled BAD: No arguments, or syntax error in an argument
結果：OK：関連機能が有効になってBAD：いいえ引数、または構文エラーを引数に
The ENABLE command takes a list of capability names, and requests the server to enable the named extensions. Once enabled using ENABLE, each extension remains active until the IMAP connection is closed. For each argument, the server does the following:
ENABLEコマンドは、機能名の一覧を取得し、名前の拡張を可能にするためにサーバに要求します。一度ENABLE使用して有効にIMAP接続が閉じられるまで、各拡張機能はアクティブのまま。各引数には、サーバーは次の処理を行います。
- If the argument is not an extension known to the server, the server MUST ignore the argument.
- 引数は、サーバに知られて拡張されていない場合、サーバーは、引数を無視しなければなりません。
- If the argument is an extension known to the server, and it is not specifically permitted to be enabled using ENABLE, the server MUST ignore the argument. (Note that knowing about an extension doesn't necessarily imply supporting that extension.)
- 引数は、サーバに知られている拡張機能であり、具体的にENABLE使用して有効にすることを許可されていない場合、サーバーは、引数を無視しなければなりません。 （拡張について知ることは必ずしもその拡張をサポートする意味しないことに注意してください。）
- If the argument is an extension that is supported by the server and that needs to be enabled, the server MUST enable the extension for the duration of the connection. At present, this applies only to CONDSTORE ([RFC4551]). Note that once an extension is enabled, there is no way to disable it.
- 引数は、サーバによってサポートされている拡張機能であり、それを有効にする必要がある場合、サーバは接続の期間延長を有効にする必要があります。現在のところ、これはCONDSTORE（[RFC4551]）にのみ適用されます。拡張子を有効にすると、それを無効にする方法がないことに注意してください。
If the ENABLE command is successful, the server MUST send an untagged ENABLED response (see Section 3.2).
ENABLEコマンドが成功した場合、サーバはタグなしENABLED応答を（3.2節を参照）を送らなければなりません。
Clients SHOULD only include extensions that need to be enabled by the server. At the time of publication, CONDSTORE is the only such extension (i.e., ENABLE CONDSTORE is an additional "CONDSTORE enabling command" as defined in [RFC4551]). Future RFCs may add to this list.
クライアントは、サーバのみで有効にする必要が拡張子を含むべきです。出版時に、CONDSTOREは（[RFC4551]で定義されるように、すなわち、ENABLE CONDSTORE追加「コマンドを有効CONDSTORE」である）だけそのような拡張です。将来のRFCは、このリストに追加することができます。
The ENABLE command is only valid in the authenticated state (see [RFC3501]), before any mailbox is selected. Clients MUST NOT issue ENABLE once they SELECT/EXAMINE a mailbox; however, server implementations don't have to check that no mailbox is selected or was previously selected during the duration of a connection.
ENABLEコマンド任意のメールボックスが選択される前に、（[RFC3501]を参照）認証された状態でのみ有効です。クライアントは、/メールボックスを調べて選択すると、ENABLE発行してはなりません。ただし、サーバーの実装には、メールボックスが選択されていないか、以前の接続の期間中に選択されたことを確認する必要はありません。
The ENABLE command can be issued multiple times in a session. It is additive; i.e., "ENABLE a b", followed by "ENABLE c" is the same as a single command "ENABLE a b c". When multiple ENABLE commands are issued, each corresponding ENABLED response SHOULD only contain extensions enabled by the corresponding ENABLE command.
ENABLEコマンドは、セッション内で複数回発行することができます。これは、添加剤です。すなわち、「Cを有効にする」に続いて、「Bを有効にする」「B cをENABLE」は、単一のコマンドと同じです。複数のENABLEコマンドが発行されると、対応する各ENABLED応答が唯一のENABLE対応するコマンドで有効に機能拡張を含むべきです。
There are no limitations on pipelining ENABLE. For example, it is possible to send ENABLE and then immediately SELECT, or a LOGIN immediately followed by ENABLE.
ENABLEパイプライン上の制限はありません。例えば、SELECT、または直ちにENABLE続いLOGIN直ちに次いでENABLE送信とすることが可能です。
The server MUST NOT change the CAPABILITY list as a result of executing ENABLE; i.e., a CAPABILITY command issued right after an ENABLE command MUST list the same capabilities as a CAPABILITY command issued before the ENABLE command. This is demonstrated in the following example:
サーバーは、ENABLE実行した結果として能力のリストを変更してはいけません。すなわち、右ENABLEコマンドの後に発行されたCAPABILITYコマンドは、ENABLEコマンドの前に発行されCAPABILITYコマンドと同じ機能をリストする必要があります。これは、次の例で実証されています。
C: t1 CAPABILITY S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE 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 IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA S: t3 OK foo again
C：T1能力S：T1 OK FOOのC：T2 CONDSTORE X-GOOD-IDEAのSを有効にする：* ENABLED X-GOOD-アイディアS：T2 OK FOOのC：T3能力* CAPABILITY IMAP4rev1のID LITERAL + X-GOOD-IDEA SをENABLE S：* CAPABILITY IMAP4rev1のID LITERAL + X-GOOD-IDEAのSをENABLE：T3 OK FOO再び
In the following example, the client enables CONDSTORE:
次の例では、クライアントがCONDSTOREを可能にします：
C: a1 ENABLE CONDSTORE S: * ENABLED CONDSTORE S: a1 OK Conditional Store enabled
C：A1 ENABLE CONDSTORE S：* ENABLED CONDSTORE S：OK条件付きストアが有効になっA1
Contents: capability listing
内容：機能のリスト
The ENABLED response occurs as a result of an ENABLE command. The capability listing contains a space-separated listing of capability names that the server supports and that were successfully enabled. The ENABLED response may contain no capabilities, which means that no extensions listed by the client were successfully enabled.
ENABLED応答は、enableコマンドの結果として起こります。機能のリストは正常に有効化されたサーバーがサポートする機能名とのスペース区切りのリストが含まれています。 ENABLED応答は、クライアントがリストされている何の拡張機能が正常に有効化されなかったことを意味し、何の能力を含まなくてもよいです。
Designers of IMAP extensions are discouraged from creating extensions that require ENABLE unless there is no good alternative design. Specifically, extensions that cause potentially incompatible behavior changes to deployed server responses (and thus benefit from ENABLE) have a higher complexity cost than extensions that do not.
IMAP拡張の設計者には良い代替設計が存在しない場合を除き、ENABLE必要と拡張子を作成することは推奨されています。具体的には、配置されたサーバ応答に対して潜在的に互換性のない行動の変化を引き起こす（したがってENABLE恩恵を受ける）拡張子がない拡張子よりも高い複雑さのコストを持っています。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234] including the core rules in Appendix B.1. [RFC3501] defines the non-terminals "capability" and "command-any".
以下の構文仕様は、付録B.1におけるコアルールを含む[RFC5234]で指定された拡張バッカス・ナウアフォーム（ABNF）の表記を使用します。 [RFC3501]は非末端「能力」と「コマンド任意」を定義します。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
特記しないものを除いて、すべての英字は大文字と小文字を区別しません。トークン文字列を定義するための、大・小文字の使用は、編集上明確にするためです。実装は大文字と小文字を区別しないやり方で、これらの文字列を受け入れなければなりません。
capability =/ "ENABLE"
機能= / "ENABLE"
command-any =/ "ENABLE" 1*(SP capability)
コマンドいかなる= / "ENABLE" 1 *（SP機能）
response-data =/ "*" SP enable-data CRLF
応答データ= /「*」SP有効データCRLF
enable-data = "ENABLED" *(SP capability)
有効データ= "ENABLED" *（SP機能）
It is believed that this extension doesn't add any security considerations that are not already present in the base IMAP protocol [RFC3501].
この拡張は、すでにベースIMAPプロトコル[RFC3501]に存在しない任意のセキュリティ上の考慮事項を追加しないと考えられています。
The IANA has added ENABLE to the IMAP4 Capabilities Registry.
IANAは、IMAP4機能レジストリにENABLE追加しました。
The editors would like to thank Randy Gellens, Chris Newman, Peter Coates, Dave Cridland, Mark Crispin, Ned Freed, Dan Karp, Cyrus Daboo, Ken Murchison, and Eric Burger for comments and corrections. However, this doesn't necessarily mean that they endorse this extension, agree with all details, or are responsible for errors introduced by the editors.
編集者は、コメントと修正のためのランディGellens、クリス・ニューマン、ピーター・コーツ、デイヴCridland、マーク・クリスピン、ネッドフリード、ダン・カープ、サイラスDaboo、ケンマーチソン、そしてエリック・バーガーに感謝したいと思います。しかし、これは必ずしも彼らは、この拡張機能を推奨するもので、すべての詳細に同意する、または編集者によって導入されたエラーの原因であることを意味するものではありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - VERSION 4rev1"、RFC 3501、2003年3月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
"構文仕様のための増大しているBNF：ABNF" [RFC5234]クロッカー、D.、エド、およびP. Overell、。、STD 68、RFC 5234、2008年1月。
[RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006.
[RFC4551]メルニコフ、A.とS.ホール、 "条件付きSTORE操作やクイックフラグの変更を再同期化のためのIMAP拡張"、RFC 4551、2006年6月。
[ANNOTATE] Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", Work in Progress, August 2006.
[ANNOTATE] Daboo、C.とR. Gellens、 "IMAPのANNOTATE拡張"、進歩、2006年8月に作業。
Editors' Addresses
エディタのアドレス
Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr. 8 D-81671 Muenchen Germany
ARNT Gulbrandsenのオリックスメールシステム社Schweppermannstr。 8 D-81671ミュンヘン、ドイツ
Fax: +49 89 4502 9758 EMail: arnt@oryx.com
ファックス：+49 89 4502 9758 Eメール：arnt@oryx.com
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
アレクセイ・メルニコフISODE株式会社5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国
EMail: Alexey.Melnikov@isode.com
メールアドレス：Alexey.Melnikov@isode.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。