[要約] RFC 4466は、IMAP4のABNFに関する拡張をまとめたものであり、その目的はIMAP4プロトコルの拡張性を向上させることです。
Network Working Group A. Melnikov
Request for Comments: 4466 Isode Ltd.
Updates: 2088, 2342, 3501, 3502, 3516 C. Daboo
Category: Standards Track April 2006
Collected Extensions to IMAP4 ABNF
IMAP4 ABNFに拡張機能を収集しました
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
Over the years, many documents from IMAPEXT and LEMONADE working groups, as well as many individual documents, have added syntactic extensions to many base IMAP commands described in RFC 3501. For ease of reference, this document collects most of such ABNF changes in one place.
長年にわたり、IMAPEXTおよびレモネードワーキンググループからの多くのドキュメント、および多くの個別のドキュメントは、RFC 3501で説明されている多くのベースIMAPコマンドに構文拡張機能を追加しました。。
This document also suggests a set of standard patterns for adding options and extensions to several existing IMAP commands defined in RFC 3501. The patterns provide for compatibility between existing and future extensions.
また、このドキュメントは、RFC 3501で定義されたいくつかの既存のIMAPコマンドにオプションと拡張機能を追加するための一連の標準パターンを提案しています。パターンは、既存と将来の拡張機能間の互換性を提供します。
This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516. It also includes part of the errata to RFC 3501. This document doesn't specify any semantic changes to the listed RFCs.
このドキュメントは、RFCS 2088、2342、3501、3502、および3516のABNFを更新します。また、RFC 3501からErrataの一部を含みます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Purpose of This Document ...................................2
1.2. Conventions Used in This Document ..........................3
2. IMAP ABNF Extensions ............................................3
2.1. Optional Parameters with the SELECT/EXAMINE Commands .......3
2.2. Extended CREATE Command ....................................4
2.3. Extended RENAME Command ....................................5
2.4. Extensions to FETCH and UID FETCH Commands .................6
2.5. Extensions to STORE and UID STORE Commands .................6
2.6. Extensions to SEARCH Command ...............................7
2.6.1. Extended SEARCH Command .............................7
2.6.2. ESEARCH untagged response ...........................8
2.7. Extensions to APPEND Command ...............................8
3. Formal Syntax ...................................................9
4. Security Considerations ........................................14
5. Normative References ...........................................15
6. Acknowledgements ...............................................15
This document serves several purposes:
このドキュメントはいくつかの目的を果たします。
1. rationalize and generalize ABNF for some existing IMAP extensions; 2. collect the ABNF in one place in order to minimize cross references between documents; 3. define building blocks for future extensions so that they can be used together in a compatible way.
1. 一部の既存のIMAP拡張機能のABNFを合理化および一般化します。2.ドキュメント間の相互参照を最小限に抑えるために、ABNFを1つの場所に収集します。3.将来の拡張機能のビルディングブロックを定義して、互換性のある方法で一緒に使用できるようにします。
It is expected that a future revision of this document will be incorporated into a revision of RFC 3501.
このドキュメントの将来の改訂は、RFC 3501の改訂に組み込まれることが予想されます。
This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516. It also includes part of the errata to RFC 3501. This document doesn't specify any semantic changes to the listed RFCs.
このドキュメントは、RFCS 2088、2342、3501、3502、および3516のABNFを更新します。また、RFC 3501からErrataの一部を含みます。
The ABNF in section 6 of RFC 2342 got rewritten to conform to the ABNF syntax as defined in RFC 4234 and to reference new non-terminals from RFC 3501. It was also restructured to allow for better readability. There were no changes "on the wire".
RFC 2342のセクション6のABNFは、RFC 4234で定義されているABNF構文に適合し、RFC 3501から新しい非末端を参照するように書き換えられました。「ワイヤーに」変更はありませんでした。
Section 2 extends ABNF for SELECT, EXAMINE, CREATE, RENAME, FETCH/UID FETCH, STORE/UID STORE, SEARCH, and APPEND commands in a consistent manner. Extensions to all the commands but APPEND have the same structure. Extensibility for the APPEND command was done slightly differently in order to preserve backward compatibility with existing extensions.
セクション2では、ABNFを選択、検査、作成、変更、フェッチ/uidフェッチ、ストア/uidストア、検索、および一貫した方法でコマンドを追加するために拡張します。すべてのコマンドの拡張機能が付録に同じ構造があります。追加コマンドの拡張性は、既存の拡張機能との逆方向の互換性を維持するために、わずかに異なって行われました。
Section 2 also defines a new ESEARCH response, whose purpose is to define a better version of the SEARCH response defined in RFC 3501.
セクション2では、RFC 3501で定義された検索応答のより良いバージョンを定義することを目的とする新しいESEarch応答も定義しています。
Section 3 defines the collected ABNF that replaces pieces of ABNF in the aforementioned RFCs. The collected ABNF got generalized to allow for easier future extensibility.
セクション3では、前述のRFCのABNFを置き換える収集されたABNFを定義します。収集されたABNFは、将来の拡大を容易にするために一般化されました。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively.
例では、「C：」と「S：」は、それぞれクライアントとサーバーから送信された行を示します。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
このドキュメントの「必須」、「必要はない」、「そうはない」、「すべきではない」、「必要はない」は、「要件レベルを示すためにRFCで使用するためのキーワード」で定義されていると解釈されます[キーワード]。
This section is not normative. It provides some background on the intended use of different extensions and it gives some guidance about how future extensions should extend the described commands.
このセクションは規範的ではありません。さまざまな拡張機能の使用に関する背景を提供し、将来の拡張機能が説明されているコマンドをどのように拡張するかについてのガイダンスを提供します。
This document adds the ability to include one or more parameters with the IMAP SELECT (section 6.3.1 of [IMAP4]) or EXAMINE (section 6.3.2 of [IMAP4]) commands, to turn on or off certain standard behaviors, or to add new optional behaviors required for a particular extension.
このドキュメントでは、1つ以上のパラメーターをIMAP選択（[IMAP4]のセクション6.3.1）に含めるか（[IMAP4]のセクション6.3.2）コマンドを調べること、特定の標準動作をオンまたはオフにする、または特定の拡張機能に必要な新しいオプションの動作を追加します。
There are two possible modes of operation:
操作には2つの可能なモードがあります。
o A global state change where a single use of the optional parameter will affect the session state from that time on, irrespective of subsequent SELECT/EXAMINE commands.
o 後続の選択/検査コマンドに関係なく、オプションのパラメーターを単一の使用がその時点からセッション状態に影響する場合、グローバルな状態変更。
o A per-mailbox state change that will affect the session only for the duration of the new selected state. A subsequent SELECT/EXAMINE without the optional parameter will cancel its effect for the newly selected mailbox.
o 新しい選択された状態の期間のみセッションに影響を与えるメールボックスごとの状態の変更。オプションのパラメーターなしでその後の選択/検査は、新しく選択されたメールボックスの効果をキャンセルします。
Optional parameters to the SELECT or EXAMINE commands are added as a parenthesized list of attribute/value pairs, and appear after the mailbox name in the standard SELECT or EXAMINE command. The order of individual parameters is arbitrary. A parameter value is optional and may consist of atoms, strings, or lists in a specific order. If the parameter value is present, it always appears in parentheses (*). Any parameter not defined by extensions that the server supports must be rejected with a BAD response.
選択または検査コマンドのオプションのパラメーターは、属性/値ペアの括弧付きリストとして追加され、標準の選択または検査コマンドのメールボックス名の後に表示されます。個々のパラメーターの順序は任意です。パラメーター値はオプションであり、特定の順序で原子、文字列、またはリストで構成されている場合があります。パラメーター値が存在する場合、常に括弧（*）に表示されます。サーバーがサポートする拡張機能によって定義されていないパラメーターは、悪い応答で拒否される必要があります。
Example:
例：
C: a SELECT INBOX (ANNOTATE)
S: ...
S: a OK SELECT complete
In the above example, a single parameter is used with the SELECT command.
上記の例では、Selectコマンドで単一のパラメーターが使用されます。
Example:
例：
C: a EXAMINE INBOX (ANNOTATE RESPONSES ("UID Responses")
CONDSTORE)
S: ...
S: a OK EXAMINE complete
In the above example, three parameters are used with the EXAMINE command. The second parameter consists of two items: an atom "RESPONSES" followed by a quoted string.
上記の例では、exemineコマンドで3つのパラメーターが使用されます。2番目のパラメーターは、2つの項目で構成されています。原子「応答」に続いて引用された文字列が続きます。
Example:
例：
C: a SELECT INBOX (BLURDYBLOOP)
S: a BAD Unknown parameter in SELECT command
In the above example, a parameter not supported by the server is used. This results in the BAD response from the server.
上記の例では、サーバーによってサポートされていないパラメーターが使用されます。これにより、サーバーからの反応が悪くなります。
(*) - if a parameter has a mandatory value, which can always be represented as a number or a sequence-set, the parameter value does not need the enclosing (). See ABNF for more details.
（*） - パラメーターに必須の値があり、常に数またはシーケンスセットとして表現できる場合、パラメーター値はenclosing（）を必要としません。詳細については、ABNFを参照してください。
Arguments: mailbox name OPTIONAL list of CREATE parameters
引数：メールボックス名作成パラメーターのオプションリスト
Responses: no specific responses for this command
回答：このコマンドの特定の応答はありません
Result: OK - create completed
NO - create failure: cannot create mailbox with
that name
BAD - argument(s) invalid
This document adds the ability to include one or more parameters with the IMAP CREATE command (see section 6.3.3 of [IMAP4]), to turn on or off certain standard behaviors, or to add new optional behaviors required for a particular extension. No CREATE parameters are defined in this document.
このドキュメントは、IMAP Createコマンドに1つ以上のパラメーターを含める機能（[IMAP4]のセクション6.3.3を参照）、特定の標準動作をオンまたはオフにする、または特定の拡張機能に必要な新しいオプションの動作を追加する機能を追加します。このドキュメントでは、作成されたパラメーターは定義されていません。
Optional parameters to the CREATE command are added as a parenthesized list of attribute/value pairs after the mailbox name. The order of individual parameters is arbitrary. A parameter value is optional and may consist of atoms, strings, or lists in a specific order. If the parameter value is present, it always appears in parentheses (*). Any parameter not defined by extensions that the server supports must be rejected with a BAD response.
CREATEコマンドへのオプションパラメーターは、メールボックス名の後に属性/値ペアの括弧付きリストとして追加されます。個々のパラメーターの順序は任意です。パラメーター値はオプションであり、特定の順序で原子、文字列、またはリストで構成されている場合があります。パラメーター値が存在する場合、常に括弧（*）に表示されます。サーバーがサポートする拡張機能によって定義されていないパラメーターは、悪い応答で拒否される必要があります。
(*) - if a parameter has a mandatory value, which can always be represented as a number or a sequence-set, the parameter value does not need the enclosing (). See ABNF for more details.
（*） - パラメーターに必須の値があり、常に数またはシーケンスセットとして表現できる場合、パラメーター値はenclosing（）を必要としません。詳細については、ABNFを参照してください。
Arguments: existing mailbox name new mailbox name OPTIONAL list of RENAME parameters
引数：既存のメールボックス名新しいメールボックス名オプションの名前変更パラメーターのリスト
Responses: no specific responses for this command
回答：このコマンドの特定の応答はありません
Result: OK - rename completed NO - rename failure: cannot rename mailbox with that name, cannot rename to mailbox with that name, etc. BAD - argument(s) invalid
結果：ok-完了した変更なし - 障害の変更：その名前でメールボックスの名前を変更できません。その名前などでメールボックスに名前を変更できません。悪い引数は無効です
This document adds the ability to include one or more parameters with the IMAP RENAME command (see section 6.3.5 of [IMAP4]), to turn on or off certain standard behaviors, or to add new optional behaviors required for a particular extension. No RENAME parameters are defined in this document.
このドキュメントでは、IMAPの名前変更コマンド（[IMAP4]のセクション6.3.5を参照）に1つ以上のパラメーターを含める機能、特定の標準動作をオンまたはオフにするか、特定の拡張機能に必要な新しいオプションの動作を追加する機能を追加します。このドキュメントでは、名前変更パラメーターは定義されていません。
Optional parameters to the RENAME command are added as a parenthesized list of attribute/value pairs after the new mailbox name. The order of individual parameters is arbitrary. A parameter value is optional and may consist of atoms, strings, or lists in a specific order. If the parameter value is present, it always appears in parentheses (*). Any parameter not defined by extensions that the server supports must be rejected with a BAD response.
名前変更コマンドへのオプションパラメーターは、新しいメールボックス名の後に属性/値ペアの括弧付きリストとして追加されます。個々のパラメーターの順序は任意です。パラメーター値はオプションであり、特定の順序で原子、文字列、またはリストで構成されている場合があります。パラメーター値が存在する場合、常に括弧（*）に表示されます。サーバーがサポートする拡張機能によって定義されていないパラメーターは、悪い応答で拒否される必要があります。
(*) - if a parameter has a mandatory value, which can always be represented as a number or a sequence-set, the parameter value does not need the enclosing (). See ABNF for more details.
（*） - パラメーターに必須の値があり、常に数またはシーケンスセットとして表現できる場合、パラメーター値はenclosing（）を必要としません。詳細については、ABNFを参照してください。
Arguments: sequence set message data item names or macro OPTIONAL fetch modifiers
引数：シーケンスセットメッセージデータ項目名またはマクロオプションフェッチ修飾子
Responses: untagged responses: FETCH
回答：じゃんの回答：フェッチ
Result: OK - fetch completed
NO - fetch error: cannot fetch that data
BAD - command unknown or arguments invalid
This document extends the syntax of the FETCH and UID FETCH commands (see section 6.4.5 of [IMAP4]) to include optional FETCH modifiers. No fetch modifiers are defined in this document.
このドキュメントでは、FetchおよびUID Fetchコマンドの構文を拡張し（[IMAP4]、セクション6.4.5を参照）、オプションのフェッチ修飾子を含みます。このドキュメントでは、フェッチ修飾子は定義されていません。
The order of individual modifiers is arbitrary. Each modifier is an attribute/value pair. A modifier value is optional and may consist of atoms and/or strings and/or lists in a specific order. If the modifier value is present, it always appears in parentheses (*). Any modifiers not defined by extensions that the server supports must be rejected with a BAD response.
個々の修飾子の順序は任意です。各修飾子は、属性/値ペアです。修飾子値はオプションであり、特定の順序で原子および/または文字列および/またはリストで構成されている場合があります。修飾子の値が存在する場合、常に括弧（*）に表示されます。サーバーがサポートする拡張機能によって定義されていない修飾子は、悪い応答で拒否される必要があります。
(*) - if a modifier has a mandatory value, which can always be represented as a number or a sequence-set, the modifier value does not need the enclosing (). See ABNF for more details.
（*） - 修飾子に必須の値があり、常に数値またはシーケンスセットとして表現できる場合、モディファイア値はenclosing（）を必要としません。詳細については、ABNFを参照してください。
Arguments: message set OPTIONAL store modifiers message data item name value for message data item
引数：メッセージセットオプションストア修飾子メッセージデータ項目メッセージデータ項目の値
Responses: untagged responses: FETCH
回答：じゃんの回答：フェッチ
Result: OK - store completed
NO - store error: cannot store that data
BAD - command unknown or arguments invalid
This document extends the syntax of the STORE and UID STORE commands (see section 6.4.6 of [IMAP4]) to include optional STORE modifiers. No store modifiers are defined in this document.
このドキュメントは、ストアとUIDストアコマンドの構文を拡張し（[IMAP4]、セクション6.4.6を参照）、オプションのストア修飾子を含みます。このドキュメントでは、ストア修飾子は定義されていません。
The order of individual modifiers is arbitrary. Each modifier is an attribute/value pair. A modifier value is optional and may consist of atoms and/or strings and/or lists in a specific order. If the modifier value is present, it always appears in parentheses (*). Any modifiers not defined by extensions that the server supports must be rejected with a BAD response.
個々の修飾子の順序は任意です。各修飾子は、属性/値ペアです。修飾子値はオプションであり、特定の順序で原子および/または文字列および/またはリストで構成されている場合があります。修飾子の値が存在する場合、常に括弧（*）に表示されます。サーバーがサポートする拡張機能によって定義されていない修飾子は、悪い応答で拒否される必要があります。
(*) - if a modifier has a mandatory value, which can always be represented as a number or a sequence-set, the modifier value does not need the enclosing (). See ABNF for more details.
（*） - 修飾子に必須の値があり、常に数値またはシーケンスセットとして表現できる場合、モディファイア値はenclosing（）を必要としません。詳細については、ABNFを参照してください。
Arguments: OPTIONAL result specifier OPTIONAL [CHARSET] specification searching criteria (one or more)
引数：オプションの結果仕様オプション[charset]仕様検索基準（1つ以上）
Responses: REQUIRED untagged response: SEARCH (*)
Result: OK - search completed NO - search error: cannot search that [CHARSET] or criteria BAD - command unknown or arguments invalid
結果：ok-検索完了しない - 検索エラー：[charset]または基準が悪い - コマンド不明または引数が無効であることを検索できません
This section updates definition of the SEARCH command described in section 6.4.4 of [IMAP4].
このセクションでは、[IMAP4]のセクション6.4.4で説明されている検索コマンドの定義を更新します。
The SEARCH command is extended to allow for result options. This document does not define any result options.
検索コマンドは拡張されて、結果オプションを許可します。このドキュメントは、結果オプションを定義しません。
The order of individual options is arbitrary. Individual options may contain parameters enclosed in parentheses (**). If an option has parameters, they consist of atoms and/or strings and/or lists in a specific order. Any options not defined by extensions that the server supports must be rejected with a BAD response.
個々のオプションの順序は任意です。個々のオプションには、括弧内に囲まれたパラメーター（**）が含まれる場合があります。オプションにパラメーターがある場合、それらは特定の順序で原子および/または文字列および/またはリストで構成されます。サーバーがサポートする拡張機能によって定義されていないオプションは、悪い応答で拒否される必要があります。
(*) - An extension to the SEARCH command may require another untagged response, or no untagged response to be returned. Section 2.6.2 defines a new ESEARCH untagged response that replaces the SEARCH untagged response. Note that for a given extended SEARCH command the SEARCH and ESEARCH responses SHOULD be mutually exclusive, i.e., only one of them should be returned.
（*） - 検索コマンドへの拡張機能には、別の未編成の応答が必要になる場合、または返信するためにじゅうたんの応答がない場合があります。セクション2.6.2では、検索されていない応答を置き換える新しいesearch未開増具の応答を定義します。特定の拡張検索コマンドの場合、検索とESEARの応答は相互に排他的である必要があります。つまり、そのうちの1つのみを返す必要があります。
(**) - if an option has a mandatory parameter, which can always be represented as a number or a sequence-set, the option parameter does not need the enclosing (). See ABNF for more details.
（**） - オプションに必須のパラメーターがあり、常に数字またはシーケンスセットとして表現できる場合、オプションパラメーターはenclosing（）を必要としません。詳細については、ABNFを参照してください。
Contents: one or more search-return-data pairs
内容：1つ以上の検索リターンデータペア
The ESEARCH response SHOULD be sent as a result of an extended SEARCH or UID SEARCH command specified in section 2.6.1.
ESEarch応答は、セクション2.6.1で指定された拡張検索またはUID検索コマンドの結果として送信する必要があります。
The ESEARCH response starts with an optional search correlator. If it is missing, then the response was not caused by a particular IMAP command, whereas if it is present, it contains the tag of the command that caused the response to be returned.
ESEarch応答は、オプションの検索相関器から始まります。欠落している場合、応答は特定のIMAPコマンドによって引き起こされませんでしたが、それが存在する場合、応答が返される原因となったコマンドのタグが含まれています。
The search correlator is followed by an optional UID indicator. If this indicator is present, all data in the ESEARCH response refers to UIDs, otherwise all returned data refers to message numbers.
検索相関器の後に、オプションのUIDインジケーターが続きます。このインジケータが存在する場合、ESEarch ResponseのすべてのデータはUIDを指します。
The rest of the ESEARCH response contains one or more search data pairs. Each pair starts with unique return item name, followed by a space and the corresponding data. Search data pairs may be returned in any order. Unless specified otherwise by an extension, any return item name SHOULD appear only once in an ESEARCH response.
ESEarch応答の残りには、1つ以上の検索データペアが含まれています。各ペアは、一意の返品アイテム名で始まり、その後にスペースと対応するデータが続きます。検索データペアは任意の順序で返される場合があります。拡張機能によって特に指定されていない限り、returnアイテム名はesearch応答で1回のみ表示される必要があります。
Example: S: * ESEARCH UID COUNT 5 ALL 4:19,21,28
Example: S: * ESEARCH (TAG "a567") UID COUNT 5 ALL 4:19,21,28
Example: S: * ESEARCH COUNT 5 ALL 1:17,21
The IMAP BINARY extension [BINARY] extends the APPEND command to allow a client to append data containing NULs by using the <literal8> syntax. The ABNF was rewritten to allow for easier extensibility by IMAP extensions. This document hasn't specified any semantical changes to the [BINARY] extension.
IMAPバイナリ拡張[バイナリ]は、<Literal8> Syntaxを使用してクライアントがNULを含むデータを追加できるようにするために、追加のコマンドを拡張します。ABNFは、IMAP拡張機能によって容易な拡張性を可能にするために書き直されました。このドキュメントでは、[バイナリ]拡張機能のセマンティック変更は指定されていません。
In addition, the non-terminal "literal8" defined in [BINARY] got extended to allow for non-synchronizing literals if both [BINARY] and [LITERAL+] extensions are supported by the server.
さらに、[バイナリ]で定義されている非末端「LIRELAL8」は、[バイナリ]と[リテラル]拡張機能の両方がサーバーによってサポートされている場合、非同期リテラルを可能にするように拡張されました。
The IMAP MULTIAPPEND extension [MULTIAPPEND] extends the APPEND command to allow a client to append multiple messages atomically. This document defines a common syntax for the APPEND command that takes into consideration syntactic extensions defined by both [BINARY] and [MULTIAPPEND] extensions.
IMAP MultiaPend Extension [MultiaPend]は、追加のコマンドを拡張して、クライアントが複数のメッセージを原子的に追加できるようにします。このドキュメントでは、[バイナリ]と[MultiaPend]拡張機能の両方で定義された構文拡張機能を考慮した追加コマンドの共通の構文を定義します。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
次の構文仕様では、[ABNF]で指定されているように、拡張されたBackus-Naurフォーム（ABNF）表記を使用します。
Non-terminals referenced but not defined below are as defined by [IMAP4].
参照されていないが、以下に定義されていない非末端は、[IMAP4]で定義されているとおりです。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of uppercase or lowercase characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
それ以外の場合は、言及されている場合を除き、すべてのアルファベット文字はケース非感受性です。トークン文字列を定義するために大文字または小文字の文字を使用することは、編集の明確さのみを目的としています。実装は、これらの文字列をケースに依存しない方法で受け入れる必要があります。
append = "APPEND" SP mailbox 1*append-message
;; only a single append-message may appear
;; if MULTIAPPEND [MULTIAPPEND] capability
;; is not present
append-message = append-opts SP append-data
append-ext = append-ext-name SP append-ext-value ;; This non-terminal define extensions to ;; to message metadata.
append-ext = append-ext-name sp appent-ext-value ;;この非ターミナルは、拡張機能を;;メタデータにメッセージを送ります。
append-ext-name = tagged-ext-label
append-ext-value= tagged-ext-val ;; This non-terminal shows recommended syntax ;; for future extensions.
append-ext-value = tagged-ext-val ;;この非ターミナルショーは、推奨される構文を示しています;;将来の拡張機能。
append-data = literal / literal8 / append-data-ext
append-data-ext = tagged-ext
;; This non-terminal shows recommended syntax
;; for future extensions,
;; i.e., a mandatory label followed
;; by parameters.
append-opts = [SP flag-list] [SP date-time] *(SP append-ext)
;; message metadata
charset = atom / quoted ;; Exact syntax is defined in [CHARSET].
charset = atom / quoted ;;正確な構文は[charset]で定義されています。
create = "CREATE" SP mailbox [create-params] ;; Use of INBOX gives a NO error.
create = "create" sp mailbox [create-params] ;;受信トレイを使用すると、エラーなしが得られます。
create-params = SP "(" create-param *( SP create-param) ")"
create-param-name = tagged-ext-label
create-param = create-param-name [SP create-param-value]
create-param = create-param-name [sp create-param-value]
create-param-value= tagged-ext-val ;; This non-terminal shows recommended syntax ;; for future extensions.
create-param-value = tagged-ext-val ;;この非ターミナルショーは、推奨される構文を示しています;;将来の拡張機能。
esearch-response = "ESEARCH" [search-correlator] [SP "UID"]
*(SP search-return-data)
;; Note that SEARCH and ESEARCH responses
;; SHOULD be mutually exclusive,
;; i.e., only one of the response types
;; should be
;; returned as a result of a command.
examine = "EXAMINE" SP mailbox [select-params]
;; modifies the original IMAP EXAMINE command
;; to accept optional parameters
fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
"FAST" / fetch-att /
"(" fetch-att *(SP fetch-att) ")")
[fetch-modifiers]
;; modifies the original IMAP4 FETCH command to
;; accept optional modifiers
fetch-modifiers = SP "(" fetch-modifier *(SP fetch-modifier) ")"
fetch-modifier = fetch-modifier-name [ SP fetch-modif-params ]
fetch-modifier = fetch-modifier-name [sp fetch-modif-params]
fetch-modif-params = tagged-ext-val ;; This non-terminal shows recommended syntax ;; for future extensions.
fetch-modif-params = tagged-ext-val ;;この非ターミナルショーは、推奨される構文を示しています;;将来の拡張機能。
fetch-modifier-name = tagged-ext-label
literal8 = "~{" number ["+"] "}" CRLF *OCTET
;; A string that might contain NULs.
;; <number> represents the number of OCTETs
;; in the response string.
;; The "+" is only allowed when both LITERAL+ and
;; BINARY extensions are supported by the server.
mailbox-data =/ Namespace-Response /
esearch-response
Namespace = nil / "(" 1*Namespace-Descr ")"
Namespace-Command = "NAMESPACE"
Namespace-Descr = "(" string SP (DQUOTE QUOTED-CHAR DQUOTE / nil) *(Namespace-Response-Extension) ")"
namespace-descr = "（" string sp（dquote quoted-char dquote / nil） *（namespace-response-extension） "）"
Namespace-Response-Extension = SP string SP "(" string *(SP string) ")"
namespace-response-extension = sp string sp "（" string *（sp string） "）"
Namespace-Response = "NAMESPACE" SP Namespace
SP Namespace SP Namespace
;; This response is currently only allowed
;; if the IMAP server supports [NAMESPACE].
;; The first Namespace is the Personal Namespace(s)
;; The second Namespace is the Other Users' Namespace(s)
;; The third Namespace is the Shared Namespace(s)
rename = "RENAME" SP mailbox SP mailbox
[rename-params]
;; Use of INBOX as a destination gives
;; a NO error, unless rename-params
;; is not empty.
rename-params = SP "(" rename-param *( SP rename-param) ")"
rename-param = rename-param-name [SP rename-param-value]
rename-param = rename-param-name [sp rename-param-value]
rename-param-name = tagged-ext-label
rename-param-value= tagged-ext-val ;; This non-terminal shows recommended syntax ;; for future extensions.
rename-param-value = tagged-ext-val ;;この非ターミナルショーは、推奨される構文を示しています;;将来の拡張機能。
response-data = "*" SP response-payload CRLF
Response-data = "*" SP Response-Payload CRLF
response-payload= resp-cond-state / resp-cond-bye /
mailbox-data / message-data / capability-data
search = "SEARCH" [search-return-opts] SP search-program
search = "search" [search-return-opts] sp search-program
search-correlator = SP "(" "TAG" SP tag-string ")"
search-program = ["CHARSET" SP charset SP]
search-key *(SP search-key)
;; CHARSET argument to SEARCH MUST be
;; registered with IANA.
search-return-data = search-modifier-name SP search-return-value
;; Note that not every SEARCH return option
;; is required to have the corresponding
;; ESEARCH return data.
search-return-opts = SP "RETURN" SP "(" [search-return-opt *(SP search-return-opt)] ")"
search-return-opts = sp "return" sp "（" [search-return-opt *（sp search-return-opt）] "）"
search-return-opt = search-modifier-name [SP search-mod-params]
search-return-opt = search-modifier-name [sp search-mod-params]
search-return-value = tagged-ext-val
;; Data for the returned search option.
;; A single "nz-number"/"number" value
;; can be returned as an atom (i.e., without
;; quoting). A sequence-set can be returned
;; as an atom as well.
search-modifier-name = tagged-ext-label
search-mod-params = tagged-ext-val ;; This non-terminal shows recommended syntax ;; for future extensions.
search-mod-params = tagged-ext-val ;;この非ターミナルショーは、推奨される構文を示しています;;将来の拡張機能。
select = "SELECT" SP mailbox [select-params]
;; modifies the original IMAP SELECT command to
;; accept optional parameters
select-params = SP "(" select-param *(SP select-param) ")"
select-param = select-param-name [SP select-param-value] ;; a parameter to SELECT may contain one or ;; more atoms and/or strings and/or lists.
select-param = select-param-name [sp select-param-value] ;;選択するパラメーターには1つまたは;;より多くの原子および/または文字列および/またはリスト。
select-param-name= tagged-ext-label
select-param-name = tagged-ext-label
select-param-value= tagged-ext-val ;; This non-terminal shows recommended syntax ;; for future extensions.
select-param-value = tagged-ext-val ;;この非ターミナルショーは、推奨される構文を示しています;;将来の拡張機能。
status-att-list = status-att-val *(SP status-att-val) ;; Redefines status-att-list from RFC 3501.
status-att-list = status-att-val *（sp status-att-val）;;RFC 3501のステータスアットリストを再定義します。
;; status-att-val is defined in RFC 3501 errata
;;Status-att-Valは、RFC 3501 errataで定義されています
status-att-val = ("MESSAGES" SP number) /
("RECENT" SP number) /
("UIDNEXT" SP nz-number) /
("UIDVALIDITY" SP nz-number) /
("UNSEEN" SP number)
;; Extensions to the STATUS responses
;; should extend this production.
;; Extensions should use the generic
;; syntax defined by tagged-ext.
store = "STORE" SP sequence-set [store-modifiers] SP store-att-flags ;; extend [IMAP4] STORE command syntax ;; to allow for optional store-modifiers
store = "store" sp sequence-set [store-modifiers] sp store-att-flags ;;[imap4]ストアコマンド構文;;オプションのストアモジー化器を許可します
store-modifiers = SP "(" store-modifier *(SP store-modifier) ")"
store-modifiers = sp "（" store-modifier *（sp store-modifier） "）"
store-modifier = store-modifier-name [SP store-modif-params]
store-modifier = store-modifier-name [sp store-modif-params]
store-modif-params = tagged-ext-val ;; This non-terminal shows recommended syntax ;; for future extensions.
store-modif-params = tagged-ext-val ;;この非ターミナルショーは、推奨される構文を示しています;;将来の拡張機能。
store-modifier-name = tagged-ext-label
tag-string = string
;; tag of the command that caused
;; the ESEARCH response, sent as
;; a string.
tagged-ext = tagged-ext-label SP tagged-ext-val
;; recommended overarching syntax for
;; extensions
tagged-ext-label = tagged-label-fchar *tagged-label-char ;; Is a valid RFC 3501 "atom".
Tagged-ext-label = tagged-label-fchar *tagged-label-char ;;有効なRFC 3501 "Atom"です。
tagged-label-fchar = ALPHA / "-" / "_" / "."
tagged-label-char = tagged-label-fchar / DIGIT / ":"
tagged-ext-comp = astring /
tagged-ext-comp *(SP tagged-ext-comp) /
"(" tagged-ext-comp ")"
;; Extensions that follow this general
;; syntax should use nstring instead of
;; astring when appropriate in the context
;; of the extension.
;; Note that a message set or a "number"
;; can always be represented as an "atom".
;; An URL should be represented as
;; a "quoted" string.
tagged-ext-simple = sequence-set / number
tagged-ext-val = tagged-ext-simple / "(" [tagged-ext-comp] ")"
Tagged-ext-val = tagged-ext-simple / "（" [tagged-ext-comp] "）"
This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516. The updated documents must be consulted for security considerations for the extensions that they define.
このドキュメントは、RFCS 2088、2342、3501、3502、および3516のABNFを更新します。更新されたドキュメントは、定義する拡張機能のセキュリティに関する考慮事項について参照する必要があります。
As a protocol gets more complex, parser bugs become more common including buffer overflow, denial of service, and other common security coding errors. To the extent that this document makes the parser more complex, it makes this situation worse. To the extent that this document makes the parser more consistent and thus simpler, the situation is improved. The impact will depend on how many deployed IMAP extensions are consistent with this document. Implementers are encouraged to take care of these issues when extending existing implementations. Future IMAP extensions should strive for consistency and simplicity to the greatest extent possible.
プロトコルがより複雑になると、バッファーオーバーフロー、サービス拒否、その他の一般的なセキュリティコーディングエラーなど、パーサーバグがより一般的になります。このドキュメントがパーサーをより複雑にする限り、この状況を悪化させます。このドキュメントがパーサーの一貫性を高め、したがってよりシンプルにする限り、状況は改善されます。影響は、このドキュメントと一致する展開されたIMAP拡張機能の数に依存します。実装者は、既存の実装を拡張する際にこれらの問題に注意することをお勧めします。将来のIMAP拡張機能は、可能な限り一貫性とシンプルさを求めて努力するはずです。
Extensions to IMAP commands that are permitted in NOT AUTHENTICATED state are more sensitive to these security issues due to the larger possible attacker community prior to authentication, and the fact that some IMAP servers run with elevated privileges in that state. This document does not extend any commands permitted in NOT AUTHENTICATED state. Future IMAP extensions to commands permitted in NOT AUTHENTICATED state should favor simplicity over consistency or extensibility.
認証されていない状態で許可されているIMAPコマンドへの拡張は、認証前のより大きな攻撃者コミュニティと、一部のIMAPサーバーがその状態で高い特権で実行されるため、これらのセキュリティの問題により敏感です。このドキュメントは、認証されていない状態で許可されているコマンドを拡張しません。認証されていない状態で許可されているコマンドへの将来のIMAP拡張機能は、一貫性または拡張性よりも単純さを支持する必要があります。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP4] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[CHARSET] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[Charset] Freed、N。およびJ. Postel、「Iana Charset登録手順」、BCP 19、RFC 2978、2000年10月。
[MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, March 2003.
[MultiaPend] Crispin、M。、「インターネットメッセージアクセスプロトコル（IMAP） - マルチアドペンド拡張機能」、RFC 3502、2003年3月。
[NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998.
[名前空間] Gahrns、M。and C. Newman、「IMAP4 NameSpace」、RFC 2342、1998年5月。
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997.
[リテラル]マイヤーズ、J。、「IMAP4非同期リテラル」、RFC 2088、1997年1月。
[BINARY] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, April 2003.
[バイナリ] Nerenberg、L。、「IMAP4バイナリコンテンツ拡張」、RFC 3516、2003年4月。
This documents is based on ideas proposed by Pete Resnick, Mark Crispin, Ken Murchison, Philip Guenther, Randall Gellens, and Lyndon Nerenberg.
この文書は、ピート・レストニック、マーク・クリスピン、ケン・マーチソン、フィリップ・ゲンタン、ランドール・ゲレンズ、リンドン・ネレンベルクが提案したアイデアに基づいています。
However, all errors and omissions must be attributed to the authors of the document.
ただし、すべてのエラーと省略は、文書の著者に起因する必要があります。
Thanks to Philip Guenther, Dave Cridland, Mark Crispin, Chris Newman, Elwyn Davies, and Barry Leiba for comments and corrections.
フィリップ・ギャンテル、デイブ・クリッドランド、マーク・クリスピン、クリス・ニューマン、エルウィン・デイビス、バリー・レイバにコメントと修正をありがとう。
literal8 syntax was taken from RFC 3516.
literal8構文はRFC 3516から取得されました。
Authors' Addresses
著者のアドレス
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex, TW12 2BX UK
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton、ミドルセックス、TW12 2BX UK
EMail: Alexey.Melnikov@isode.com
Cyrus Daboo
サイラス・ダブー
EMail: cyrus@daboo.name
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。