RFC4466 日本語訳
4466 Collected Extensions to IMAP4 ABNF. A. Melnikov, C. Daboo. April 2006. (Format: TXT=33752 bytes) (Updates RFC2088, RFC2342, RFC3501, RFC3502, RFC3516) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Melnikov Request for Comments: 4466 Isode Ltd. Updates: 2088, 2342, 3501, 3502, 3516 C. Daboo Category: Standards Track April 2006
コメントを求めるワーキンググループA.メリニコフの要求をネットワークでつないでください: 4466のIsode株式会社アップデート: 2088、2342、3501、3502、3516C.Dabooカテゴリ: 標準化過程2006年4月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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からの多くのドキュメントと多くの個々の文献と同様にLEMONADEワーキンググループはRFC3501で説明された多くのベースIMAPコマンドに構文の拡大を追加しています。 参照する場合に便利なように、このドキュメントは1つの場所のそのようなABNF変化の大部分を集めます。
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.
また、このドキュメントは、RFC3501で定義されたいくつかの既存のIMAPコマンドにオプションと拡大を追加するために1セットの標準のパターンを示します。 パターンは存在と今後の拡大との互換性に備えます。
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.
このドキュメントはRFCs2088、2342、3501、3502年、および3516年にABNFをアップデートします。 また、それはRFC3501に誤字の一部を含めます。 このドキュメントは記載されたRFCsへの少しの意味変化も指定しません。
Melnikov & Daboo Standards Track [Page 1] RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
メリニコフとDaboo標準化過程[1ページ]RFC4466は2006年4月に拡大をIMAP4 ABNFに集めました。
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
1. 序論…2 1.1. このドキュメントの目的…2 1.2. このドキュメントで中古のコンベンション…3 2. IMAP ABNF拡張子…3 2.1. 選んだ/がある任意のパラメタはコマンドを調べます…3 2.2. 作成コマンドを広げています…4 2.3. 改名コマンドを広げています…5 2.4. とって来る拡大とUIDはコマンドをとって来ます…6 2.5. 格納する拡大とUIDはコマンドを格納します…6 2.6. 捜す拡大は命令します…7 2.6.1. 検索命令を広げています…7 2.6.2. ESEARCH untagged応答…8 2.7. 追加する拡大は命令します…8 3. 正式な構文…9 4. セキュリティ問題…14 5. 標準の参照…15 6. 承認…15
1. Introduction
1. 序論
1.1. Purpose of This Document
1.1. このドキュメントの目的
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. ドキュメントの間の相互参照を最小にするために1つの場所でABNFを集めてください。 3. 今後の拡大のためにブロックを定義してください。そうすれば、それらは一緒にコンパチブル方法で使用できます。
It is expected that a future revision of this document will be incorporated into a revision of RFC 3501.
このドキュメントの今後の改正がRFC3501の改正に組み入れられると予想されます。
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.
このドキュメントはRFCs2088、2342、3501、3502年、および3516年にABNFをアップデートします。 また、それはRFC3501に誤字の一部を含めます。 このドキュメントは記載されたRFCsへの少しの意味変化も指定しません。
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".
RFC2342のセクション6のABNFは、RFC4234と、そして、参照の新しい非端末と定義されるようにABNF構文に従うためにRFC3501から書き直されました。 また、それは、より良い読み易さを考慮するために再構築されました。 変化が全く「ワイヤ」にありませんでした。
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
セクション2はSELECT、EXAMINE、CREATE、RENAME、FETCH/UID FETCH、ストア/UID STORE、検索、およびAPPENDコマンドのために一貫した方法でABNFを広げます。 すべてのコマンドにもかかわらず、APPENDへの拡大には、同じくらいがあります。
Melnikov & Daboo Standards Track [Page 2] RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
メリニコフとDaboo標準化過程[2ページ]RFC4466は2006年4月に拡大をIMAP4 ABNFに集めました。
structure. Extensibility for the APPEND command was done slightly differently in order to preserve backward compatibility with existing extensions.
構造。 既存の拡大との後方の互換性を保存するためにわずかに異なってAPPENDコマンドのための伸展性をしました。
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はRFC3501で定義された検索応答の、より良いバージョンを定義する目的がことである新しい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は前述のRFCsでABNFの断片を取り替える集まっているABNFを定義します。 集まっているABNFは、よりくつろいでいる将来の伸展性を考慮するために一般化されました。
1.2. Conventions Used in This Document
1.2. 本書では使用されるコンベンション
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].
キーワード“MUST"、「必須NOT」“SHOULD"、「」 「5月」は「RFCsにおける使用が要件レベルを示すキーワード」[キーワード]で定義されるように本書では解釈されることになっているべきです。
2. IMAP ABNF Extensions
2. IMAP ABNF拡張子
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.
このセクションは規範的ではありません。 それは異なった拡張子の意図している使用のときに何らかのバックグラウンドを提供します、そして、今後の拡大がどう説明されたコマンドを広げるべきであるかに関して何らかの指導を与えます。
2.1. Optional Parameters with the SELECT/EXAMINE Commands
2.1. 選んだ/審査コマンドがある任意のパラメタ
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.
このドキュメントは、ある標準の振舞いをつけたり消したりするIMAP SELECT(.1セクション6.3[IMAP4])かEXAMINE(.2セクション6.3[IMAP4])コマンドがある1つ以上のパラメタを含んでいるか、または新しい任意の振舞いを加える能力が特定の拡大に必要であると言い足します。
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 任意のパラメタのただ一つの使用があの時以来その後のSELECT/EXAMINEの如何にかかわらずオンなセッション状態に影響するところでグローバルな州の変化は命令します。
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 新しさの持続時間のためだけのセッションに影響する1メールボックスあたり1回の州の変化が状態を選択しました。 任意のパラメタのないその後のSELECT/EXAMINEは新たに選択されたメールボックスのために効果を取り消すでしょう。
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
SELECTかEXAMINEコマンドへの任意のパラメタは、属性/価値のparenthesizedリストが対にされるとき加えられて、標準のSELECTかEXAMINEコマンドにおけるメールボックス名の後に現れます。 個々のパラメタの注文は任意です。 パラメタ値は任意です。
Melnikov & Daboo Standards Track [Page 3] RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
メリニコフとDaboo標準化過程[3ページ]RFC4466は2006年4月に拡大をIMAP4 ABNFに集めました。
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.
そして、原子、ストリング、またはリストから特定の順序で成るかもしれません。 パラメタ値が存在しているなら、それは括弧(*)にいつも現れます。 BAD応答でサーバが支持する拡大で定義されなかったどんなパラメタも拒絶しなければなりません。
Example:
例:
C: a SELECT INBOX (ANNOTATE)
S: ...
S: a OK SELECT complete
C: 選んだ受信トレイ(注釈する)S: ... S: a OK SELECT完全です。
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
C: aは受信トレイ(応答(「UID応答」)CONDSTOREを注釈する)Sを調べます: ... S: a OK EXAMINE完全です。
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.
上記の例では、3つのパラメタがEXAMINEコマンドと共に使用されます。 2番目のパラメタは2つの項目から成ります: 原子「応答」は引用文字列で続きました。
Example:
例:
C: a SELECT INBOX (BLURDYBLOOP)
S: a BAD Unknown parameter in SELECT command
C: 選んだ受信トレイ(BLURDYBLOOP)S: SELECTコマンドにおけるBAD Unknownパラメタ
In the above example, a parameter not supported by the server is
used. This results in the BAD response from the server.
上記の例では、サーバによって支持されなかったパラメタは使用されています。 これはサーバからのBAD応答をもたらします。
(*) - 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.
(*)--パラメタに義務的な値(数かシーケンスセットとしていつも表すことができる)があるなら、パラメタ値は同封()を必要としません。 その他の詳細に関してABNFを見てください。
2.2. Extended CREATE Command
2.2. 拡張作成コマンド
Arguments: mailbox name
OPTIONAL list of CREATE parameters
議論: CREATEパラメタのメールボックス名前OPTIONALリスト
Responses: no specific responses for this command
応答: このコマンドのための特定の応答がありません。
Result: OK - create completed
NO - create failure: cannot create mailbox with
that name
BAD - argument(s) invalid
結果: OK--完成したノーを作成してください--失敗を作成してください: その名前BADと共にメールボックスを作成できません--、議論病人
Melnikov & Daboo Standards Track [Page 4] RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
メリニコフとDaboo標準化過程[4ページ]RFC4466は2006年4月に拡大をIMAP4 ABNFに集めました。
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コマンド(.3セクション6.3[IMAP4]を見る)がある1つ以上のパラメタを含んでいるか、または新しい任意の振舞いを加える能力が特定の拡大に必要であると言い足します。 CREATEパラメタは全く本書では定義されません。
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.
属性/価値のparenthesizedリストがメールボックス名の後に対にされるとき、CREATEコマンドへの任意のパラメタは加えられます。 個々のパラメタの注文は任意です。 パラメタ値は、任意であり、原子、ストリング、またはリストから特定の順序で成るかもしれません。 パラメタ値が存在しているなら、それは括弧(*)にいつも現れます。 BAD応答でサーバが支持する拡大で定義されなかったどんなパラメタも拒絶しなければなりません。
(*) - 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.
(*)--パラメタに義務的な値(数かシーケンスセットとしていつも表すことができる)があるなら、パラメタ値は同封()を必要としません。 その他の詳細に関してABNFを見てください。
2.3. Extended RENAME Command
2.3. 拡張改名コマンド
Arguments: existing mailbox name
new mailbox name
OPTIONAL list of RENAME parameters
議論: 新しいメールボックス名前OPTIONALが記載するRENAMEパラメタの既存のメールボックス名
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--完成したノーを改名してください--失敗を改名してください: その名前でメールボックスを改名できないで、それで名前をメールボックスに改名できませんなど。 BAD--議論病人
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 RENAMEコマンド(.5セクション6.3[IMAP4]を見る)がある1つ以上のパラメタを含んでいるか、または新しい任意の振舞いを加える能力が特定の拡大に必要であると言い足します。 RENAMEパラメタは全く本書では定義されません。
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.
属性/価値のparenthesizedリストが新しいメールボックス名の後に対にされるとき、RENAMEコマンドへの任意のパラメタは加えられます。 個々のパラメタの注文は任意です。 パラメタ値は、任意であり、原子、ストリング、またはリストから特定の順序で成るかもしれません。 パラメタ値が存在しているなら、それは括弧(*)にいつも現れます。 BAD応答でサーバが支持する拡大で定義されなかったどんなパラメタも拒絶しなければなりません。
Melnikov & Daboo Standards Track [Page 5] RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
メリニコフとDaboo標準化過程[5ページ]RFC4466は2006年4月に拡大をIMAP4 ABNFに集めました。
(*) - 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.
(*)--パラメタに義務的な値(数かシーケンスセットとしていつも表すことができる)があるなら、パラメタ値は同封()を必要としません。 その他の詳細に関してABNFを見てください。
2.4. Extensions to FETCH and UID FETCH Commands
2.4. とって来る拡大とUIDとって来コマンド
Arguments: sequence set
message data item names or macro
OPTIONAL fetch modifiers
議論: シーケンスセットメッセージデータ項目名かマクロOPTIONALフェッチ修飾語
Responses: untagged responses: FETCH
応答: 非タグ付けをされた応答: フェッチ
Result: OK - fetch completed
NO - fetch error: cannot fetch that data
BAD - command unknown or arguments invalid
結果: OK--完成したノーをとって来てください--誤りをとって来てください: そのデータBADをとって来ることができません--未知か議論病人を命令してください。
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と任意のFETCH修飾語を含むUID FETCHコマンド(.5セクション6.4[IMAP4]を見る)の構文を広げています。 フェッチ修飾語は全く本書では定義されません。
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.
個々の修飾語の注文は任意です。 各修飾語は属性/値の組です。 修飾語値は、任意であり、原子、ストリング、そして/または、リストから特定の順序で成るかもしれません。 修飾語値が存在しているなら、それは括弧(*)にいつも現れます。 BAD応答でサーバが支持する拡大で定義されなかったどんな修飾語も拒絶しなければなりません。
(*) - 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.
(*)--修飾語に義務的な値(数かシーケンスセットとしていつも表すことができる)があるなら、修飾語値は同封()を必要としません。 その他の詳細に関してABNFを見てください。
2.5. Extensions to STORE and UID STORE Commands
2.5. 格納する拡大とUID格納命令
Arguments: message set
OPTIONAL store modifiers
message data item name
value for message data item
議論: メッセージデータ項目のためのメッセージセットOPTIONAL店修飾語メッセージデータ項目名前価値
Responses: untagged responses: FETCH
応答: 非タグ付けをされた応答: フェッチ
Result: OK - store completed
NO - store error: cannot store that data
BAD - command unknown or arguments invalid
結果: OK--完成したノーを格納してください--誤りを格納してください: そのデータBADを格納できません--未知か議論病人を命令してください。
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 STOREコマンド(.6セクション6.4[IMAP4]を見る)の構文を広げています。 店修飾語は全く本書では定義されません。
Melnikov & Daboo Standards Track [Page 6] RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
メリニコフとDaboo標準化過程[6ページ]RFC4466は2006年4月に拡大をIMAP4 ABNFに集めました。
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.
個々の修飾語の注文は任意です。 各修飾語は属性/値の組です。 修飾語値は、任意であり、原子、ストリング、そして/または、リストから特定の順序で成るかもしれません。 修飾語値が存在しているなら、それは括弧(*)にいつも現れます。 BAD応答でサーバが支持する拡大で定義されなかったどんな修飾語も拒絶しなければなりません。
(*) - 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.
(*)--修飾語に義務的な値(数かシーケンスセットとしていつも表すことができる)があるなら、修飾語値は同封()を必要としません。 その他の詳細に関してABNFを見てください。
2.6. Extensions to SEARCH Command
2.6. 捜す拡大は命令します。
2.6.1. Extended SEARCH Command
2.6.1. 拡張検索命令
Arguments: OPTIONAL result specifier
OPTIONAL [CHARSET] specification
searching criteria (one or more)
議論: OPTIONAL結果特許説明書の作成書OPTIONAL[CHARSET]仕様探す評価基準(1以上)
Responses: REQUIRED untagged response: SEARCH (*)
応答: REQUIRED untagged応答: 検索(*)
Result: OK - search completed
NO - search error: cannot search that [CHARSET] or
criteria
BAD - command unknown or arguments invalid
結果: OK--完成したノーを捜してください--誤りを捜してください: それ[CHARSET]か評価基準BADを捜すことができません--未知か議論病人を命令してください。
This section updates definition of the SEARCH command described in section 6.4.4 of [IMAP4].
このセクションは.4セクション6.4[IMAP4]で説明された検索命令の定義をアップデートします。
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.
個人の選択の注文は任意です。 個人の選択は括弧(**)に同封されたパラメタを含むかもしれません。 オプションにパラメタがあるなら、それらは原子、ストリング、そして/または、リストから特定の順序で成ります。 BAD応答でサーバが支持する拡大で定義されなかった少しのオプションも拒絶しなければなりません。
(*) - 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 untagged応答を定義します。 与えられた拡張検索のためのそれが、検索とESEARCH応答SHOULDが互いに排他的であると命令して、すなわち、それらの唯一の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.
(**)--オプションに義務的なパラメタ(数かシーケンスセットとしていつも表すことができる)があるなら、オプションパラメタは同封()を必要としません。 その他の詳細に関してABNFを見てください。
Melnikov & Daboo Standards Track [Page 7] RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
メリニコフとDaboo標準化過程[7ページ]RFC4466は2006年4月に拡大をIMAP4 ABNFに集めました。
2.6.2. ESEARCH untagged response
2.6.2. ESEARCH untagged応答
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応答SHOULD、セクション2.6で.1に指定された拡張検索かUID SEARCHコマンドの結果、送ってください。
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応答におけるすべてのデータがUIDsについて言及して、そうでなければ、すべて返されたデータはメッセージ番号について言及します。
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検索データ組以上を含んでいます。 各組はユニークな不渡り手形名から始まります、続いて、スペースと対応するデータから始まります。 順不同に検索データ組を返すかもしれません。 別の方法で拡大で指定されない場合、どんな不渡り手形名前SHOULDもESEARCH応答に一度だけ現れます。
Example: S: * ESEARCH UID COUNT 5 ALL 4:19,21,28
例: S: * ESEARCH UIDが数える、5 すべての4:19、21、28
Example: S: * ESEARCH (TAG "a567") UID COUNT 5 ALL 4:19,21,28
例: S: * ESEARCH(タグ"a567")UIDカウント5、すべての4:19、21、28
Example: S: * ESEARCH COUNT 5 ALL 1:17,21
例: S: * ESEARCHカウント5、すべての1:17、21
2.7. Extensions to APPEND Command
2.7. 追加する拡大は命令します。
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 BINARY拡張子[BINARY]はクライアントが<literal8>構文を使用することによってNULsを含むデータを追加するのを許容するAPPENDコマンドを広げています。 ABNFは、IMAP拡張子で、よりくつろいでいる伸展性を考慮するために書き直されました。 このドキュメントは[BINARY]拡大への少しの意味変化も指定していません。
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.
添加、「[BINARY]と[LITERAL+]拡大の両方がサーバによって支持されるなら、[BINARY]で定義されたliteral8"は拡張するように非連動誤字誤植を考慮するようになったところ」で非端末の。
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 MULTIAPPEND拡張子[MULTIAPPEND]はクライアントが原子論的に複数のメッセージを追加するのを許容するAPPENDコマンドを広げています。 このドキュメントは[BINARY]と[MULTIAPPEND]拡大の両方によって定義された構文の拡大を考慮に入れるAPPENDコマンドのための一般的な構文を定義します。
Melnikov & Daboo Standards Track [Page 8] RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
メリニコフとDaboo標準化過程[8ページ]RFC4466は2006年4月に拡大をIMAP4 ABNFに集めました。
3. Formal Syntax
3. 正式な構文
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
以下の構文仕様は[ABNF]の指定されるとしてのAugmented BN記法(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
SPメールボックス1*が追加する=「追加」を追加してください。-通信してください。 シングルだけ、メッセージを追加する、現れるかもしれません。 MULTIAPPEND[MULTIAPPEND]能力であるなら。 プレゼントではありません。
append-message = append-opts SP append-data
メッセージを追加している=、追加、-、選ぶ、SP、データを追加します。
append-ext = append-ext-name SP append-ext-value
;; This non-terminal define extensions to
;; to message metadata.
-extにextに値を追加しているext名を追加している=SPを追加してください。 この非端末が拡大を定義する、。 メッセージメタデータに。
append-ext-name = tagged-ext-label
ext名を追加している=タグ付けをされたextラベル
append-ext-value= tagged-ext-val
;; This non-terminal shows recommended syntax
;; for future extensions.
extを追加している値はタグ付けをされたext-valと等しいです。 この非端末はお勧めの構文を示しています。 今後の拡大のために。
append-data = literal / literal8 / append-data-ext
データを追加している=文字通りの/ literal8 / appendデータext
append-data-ext = tagged-ext
;; This non-terminal shows recommended syntax
;; for future extensions,
;; i.e., a mandatory label followed
;; by parameters.
データextを追加している=タグ付けをされたext。 この非端末はお勧めの構文を示しています。 今後の拡大のために。 すなわち、義務的なラベルは続きました。 パラメタで。
append-opts = [SP flag-list] [SP date-time] *(SP append-ext)
;; message metadata
追加、-、選ぶ、=[SP現役将官名簿][SP日付-時間]*、(SPが-extに追加する、)、。 メッセージメタデータ
charset = atom / quoted
;; Exact syntax is defined in [CHARSET].
charset=原子/引用される。 正確な構文は[CHARSET]で定義されます。
create = "CREATE" SP mailbox
[create-params]
;; Use of INBOX gives a NO error.
「作成=」SPメールボックス[paramsを作成している]を作成してください。 受信トレイの使用はいいえ誤りを与えます。
Melnikov & Daboo Standards Track [Page 9] RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
メリニコフとDaboo標準化過程[9ページ]RFC4466は2006年4月に拡大をIMAP4 ABNFに集めました。
create-params = SP "(" create-param *( SP create-param) ")"
paramsを作成している=SP、「(「paramを作成している*、(SPが-paramに作成する、)、」、)、」
create-param-name = tagged-ext-label
param名を作成している=タグ付けをされたextラベル
create-param = create-param-name [SP create-param-value]
-paramに名義でparamを作成していた状態で=を作成してください。[paramに値を作成しているSP]
create-param-value= tagged-ext-val
;; This non-terminal shows recommended syntax
;; for future extensions.
paramを作成している値はタグ付けをされた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.
esearch-応答は"ESEARCH"[検索相関器][SP"UID"]*(SP検索リターンデータ)と等しいです。 その検索とESEARCH応答に注意してください。 SHOULD、互いに排他的であってください、。 すなわち、応答の1つだけがタイプされます。 あるべきです。 コマンドの結果、戻りました。
examine = "EXAMINE" SP mailbox [select-params]
;; modifies the original IMAP EXAMINE command
;; to accept optional parameters
「審査=」SPメールボックス[選んだparams]を調べてください。 オリジナルのIMAP EXAMINEコマンドを変更します。 任意のパラメタを受け入れるために
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
=「フェッチ」SPシーケンスセットSP(「(「フェッチ-att*(SPフェッチ-att)」)」という「完全である」か「すべて」/「速い」/フェッチ-att/)[フェッチ修飾語]をとって来てください。 オリジナルのIMAP4 FETCHコマンドを変更します。 任意の修飾語を受け入れてください。
fetch-modifiers = SP "(" fetch-modifier *(SP fetch-modifier) ")"
フェッチ修飾語は「(「フェッチ修飾語*(SPフェッチ修飾語)」)」というSPと等しいです。
fetch-modifier = fetch-modifier-name [ SP fetch-modif-params ]
フェッチ修飾語=フェッチ修飾語名[SPフェッチ-modif-params]
fetch-modif-params = tagged-ext-val
;; This non-terminal shows recommended syntax
;; for future extensions.
フェッチ-modif-paramsはタグ付けをされたext-valと等しいです。 この非端末はお勧めの構文を示しています。 今後の拡大のために。
fetch-modifier-name = tagged-ext-label
=タグ付けをされたextフェッチ修飾語名のラベル
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.
「literal8は」 ~「数の[「+」]」と等しく」CRLF*八重奏。 NULsを含むかもしれない五弦。 ;; <番号>はOCTETsの数を表します。 応答ストリングで。 ;; そして、ともに文字通りの+であるときにだけ、「+」が許容されている、。 BINARY拡張子はサーバによってサポートされます。
Melnikov & Daboo Standards Track [Page 10] RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
メリニコフとDaboo標準化過程[10ページ]RFC4466は2006年4月に拡大をIMAP4 ABNFに集めました。
mailbox-data =/ Namespace-Response /
esearch-response
esearchメールボックスデータ名前空間=/応答/応答
Namespace = nil / "(" 1*Namespace-Descr ")"
「(「1*名前空間Descr」)」という名前空間=無/
Namespace-Command = "NAMESPACE"
名前空間コマンドは「名前空間」と等しいです。
Namespace-Descr = "(" string SP
(DQUOTE QUOTED-CHAR DQUOTE / nil)
*(Namespace-Response-Extension) ")"
名前空間-Descrは「(「ストリングSP(DQUOTE QUOTED-CHAR DQUOTE/無)*(名前空間応答拡大)」)」と等しいです。
Namespace-Response-Extension = SP string SP
"(" string *(SP string) ")"
名前空間応答拡大は「(「ストリング*(SPストリング)」)」というSPストリングSPと等しいです。
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)
名前空間応答は「名前空間」SP名前空間SP名前空間SP名前空間と等しいです。 この応答は現在、許容されているだけです。 IMAPサーバが[NAMESPACE]を支持するなら。 ;; 最初のNamespaceはパーソナルNamespace(s)です。 第2NamespaceはOther UsersのNamespace(s)です。 第3Namespaceは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.
「改名」SPメールボックスSPメールボックス[paramsを改名している]に=を改名してください。 目的地が与えるaとしての受信トレイの使用。 いいえ誤りparamsを改名しない場合 空でない。
rename-params = SP "(" rename-param *( SP rename-param) ")"
paramsを改名している=SP、「(「paramを改名している*、(SPが-paramに改名する、)、」、)、」
rename-param = rename-param-name [SP rename-param-value]
-paramにparamに名前を改名している=を改名してください。[paramに値を改名しているSP]
rename-param-name = tagged-ext-label
paramを名前に改名している=タグ付けをされたextラベル
rename-param-value= tagged-ext-val
;; This non-terminal shows recommended syntax
;; for future extensions.
paramを改名している値はタグ付けをされたext-valと等しいです。 この非端末はお勧めの構文を示しています。 今後の拡大のために。
response-data = "*" SP response-payload CRLF
応答データは「*」SP応答ペイロードCRLFと等しいです。
response-payload= resp-cond-state / resp-cond-bye /
mailbox-data / message-data / capability-data
応答ペイロードは能力メッセージメールボックスresp-cond resp-cond-状態/不戦勝/データ/データ/データと等しいです。
search = "SEARCH" [search-return-opts]
SP search-program
検索=「検索」[検索リターンは選ばれる]SP検索プログラム
search-correlator = SP "(" "TAG" SP tag-string ")"
「(「「タグ」SPタグストリング」)」という検索相関器=SP
Melnikov & Daboo Standards Track [Page 11] RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
メリニコフとDaboo標準化過程[11ページ]RFC4466は2006年4月に拡大をIMAP4 ABNFに集めました。
search-program = ["CHARSET" SP charset SP]
search-key *(SP search-key)
;; CHARSET argument to SEARCH MUST be
;; registered with IANA.
検索プログラムは検索主要な*(SP検索キー)と等しいです["CHARSET"SP charset SP]。 検索へのCHARSET議論はそうであるに違いありません。 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.
検索リターンデータは検索修飾語名のSP検索リターン価値と等しいです。 あらゆる検索がオプションを返すというわけではないことに注意してください。 対応を持つのが必要です。 ESEARCHはデータを返します。
search-return-opts = SP "RETURN" SP "(" [search-return-opt
*(SP search-return-opt)] ")"
検索リターンが選ばれた=SPがSPを「返す」、「(「[検索リターンが選ばれた*(リターンが選ぶSP検索)]」)、」
search-return-opt = search-modifier-name [SP search-mod-params]
検索リターンが選ばれた=検索修飾語名[SPの検索のモッズ風の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.
検索リターン価値はタグ付けをされたext-valと等しいです。 返上のためのデータはオプションを捜します。 ;; 単一の「nz-数」/「数」値。 すなわち、原子として返すことができる、(;、引用) シーケンスセットを返すことができます。 また、原子として。
search-modifier-name = tagged-ext-label
=タグ付けをされたext検索修飾語名のラベル
search-mod-params = tagged-ext-val
;; This non-terminal shows recommended syntax
;; for future extensions.
検索モッズparamsはタグ付けをされたext-valと等しいです。 この非端末はお勧めの構文を示しています。 今後の拡大のために。
select = "SELECT" SP mailbox [select-params]
;; modifies the original IMAP SELECT command to
;; accept optional parameters
=「選んだ」SPメールボックス[選んだparams]を選択してください。 オリジナルのIMAP SELECTコマンドを変更します。 任意のパラメタを受け入れてください。
select-params = SP "(" select-param *(SP select-param) ")"
選んだparamsは「(「選んだparam*(SPの選んだparam)」)」というSPと等しいです。
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.
選んだparamは選んだparam名[SPの選んだparam価値]と等しいです。 または、SELECTへのパラメタが1つを含むかもしれない、。 より多くの原子、ストリング、そして/または、リスト。
select-param-name= tagged-ext-label
選んだparamの名前=のタグ付けをされたextラベル
select-param-value= tagged-ext-val
;; This non-terminal shows recommended syntax
;; for future extensions.
選んだparam-値はタグ付けをされたext-valと等しいです。 この非端末はお勧めの構文を示しています。 今後の拡大のために。
status-att-list = status-att-val *(SP status-att-val)
;; Redefines status-att-list from RFC 3501.
状態attリストは状態-att-val*と等しいです(SP状態-att-val)。 RFC3501から状態attリストを再定義します。
Melnikov & Daboo Standards Track [Page 12] RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
メリニコフとDaboo標準化過程[12ページ]RFC4466は2006年4月に拡大をIMAP4 ABNFに集めました。
;; status-att-val is defined in RFC 3501 errata
;; 状態-att-valはRFC3501誤字で定義されます。
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.
状態-att-valは/(「最近」のSP番号)/("UIDNEXT"SP nz-番号)/("UIDVALIDITY"SP nz-番号)/(「見えない」SP番号)と等しいです(「メッセージ」SP番号)。 STATUS応答への拡大。 この生産を拡張するべきです。 ;; 拡大はジェネリックを使用するべきです。 タグ付けをされたextによって定義された構文。
store = "STORE" SP sequence-set [store-modifiers]
SP store-att-flags
;; extend [IMAP4] STORE command syntax
;; to allow for optional store-modifiers
=「店」SPシーケンスセット[店修飾語]SP店att旗を収納してください。 [IMAP4]ストアコマンド構文を広げてください。 任意の店修飾語を考慮するために
store-modifiers = SP "(" store-modifier *(SP store-modifier)
")"
店修飾語は「(「店修飾語*(SP店修飾語)」)」というSPと等しいです。
store-modifier = store-modifier-name [SP store-modif-params]
店修飾語=店修飾語名[SP店-modif-params]
store-modif-params = tagged-ext-val
;; This non-terminal shows recommended syntax
;; for future extensions.
店-modif-paramsはタグ付けをされたext-valと等しいです。 この非端末はお勧めの構文を示しています。 今後の拡大のために。
store-modifier-name = tagged-ext-label
=タグ付けをされたext店修飾語名のラベル
tag-string = string
;; tag of the command that caused
;; the ESEARCH response, sent as
;; a string.
タグストリングはストリングと等しいです。 それが引き起こしたコマンドのタグ。 ESEARCH応答であって、送られる、。 ストリング。
tagged-ext = tagged-ext-label SP tagged-ext-val
;; recommended overarching syntax for
;; extensions
タグ付けをされたextはタグ付けをされたextラベルのSPのタグ付けをされたext-valと等しいです。 構文にアーチをかけることを勧めます。 拡大
tagged-ext-label = tagged-label-fchar *tagged-label-char
;; Is a valid RFC 3501 "atom".
タグ付けをされたextラベルはタグ付けをされたラベルfchar*タグ付けをされたラベル炭と等しいです。 有効なRFCは3501「原子」ですか?
tagged-label-fchar = ALPHA / "-" / "_" / "."
「タグ付けをされたラベルfcharはアルファー/「-」/"_"/と等しい」、」
tagged-label-char = tagged-label-fchar / DIGIT / ":"
「タグ付けをされたラベル炭はタグ付けをされたラベルfchar / DIGIT /と等しい」:、」
Melnikov & Daboo Standards Track [Page 13] RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
メリニコフとDaboo標準化過程[13ページ]RFC4466は2006年4月に拡大をIMAP4 ABNFに集めました。
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.
タグ付けをされたextコンピュータ=タグ付けをされたext astring/コンピュータ*、(SP、タグ付けをされたextコンピュータ) 「(「タグ付けをされたextコンピュータ」)」という/。 この一般に続く拡大。 の代わりにする、構文がnstringを使用するべきである、。 文脈で適切であるときに、astringします。 拡大について。 ;; そのメッセージセットか「数」に注意してください。 「原子」としていつも表すことができます。 ;; URLが表されるべきである、。 「引用された」ストリング。
tagged-ext-simple = sequence-set / number
簡単な状態でextにタグ付けををしている=シーケンスセット/番号
tagged-ext-val = tagged-ext-simple /
"(" [tagged-ext-comp] ")"
ext簡単な状態でタグ付けをされて、タグ付けをされたext-valが等しい、「(「[タグ付けをされたextコンピュータ]」)」という/
4. Security Considerations
4. セキュリティ問題
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.
このドキュメントはRFCs2088、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拡張子がこのドキュメントと一致しているかに依存するでしょう。 既存の実現を広げるとき、Implementersがこれらの問題の世話をするよう奨励されます。 将来の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.
NOT AUTHENTICATED状態で受入れられるIMAPコマンドへの拡大は認証、および高い特権がその状態にある状態でいくつかのIMAPサーバが走るという事実の前により大きい可能な攻撃者社会のためにこれらの安全保障問題により敏感です。 このドキュメントはNOT AUTHENTICATED状態で受入れられた少しのコマンドも広げていません。 NOT AUTHENTICATED状態で受入れられたコマンドへの将来のIMAP拡張子は一貫性か伸展性より簡単さを好むべきです。
Melnikov & Daboo Standards Track [Page 14] RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
メリニコフとDaboo標準化過程[14ページ]RFC4466は2006年4月に拡大をIMAP4 ABNFに集めました。
5. Normative References
5. 引用規格
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
VERSION 4rev1", RFC 3501, March 2003.
[IMAP4] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 4234, October 2005.
エド[ABNF]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[CHARSET] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
解放された[CHARSET]とN.とJ.ポステル、「IANA Charset登録手順」、BCP19、RFC2978、2000年10月。
[MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) -
MULTIAPPEND Extension", RFC 3502, March 2003.
[MULTIAPPEND]クリスピン、M.、「インターネットはアクセス・プロトコル(IMAP)を通信させます--MULTIAPPEND拡張子」、RFC3502、3月2003日
[NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
May 1998.
[名前空間] Gahrns、M.、およびC.ニューマン(「IMAP4名前空間」、RFC2342)は1998がそうするかもしれません。
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC
2088, January 1997.
[LITERAL+] マイアーズ、J.、「IMAP4非連動誤字誤植」、RFC2088、1997年1月。
[BINARY] Nerenberg, L., "IMAP4 Binary Content Extension", RFC
3516, April 2003.
[2進の] ネーレンバーグ、L.、「IMAP4の2進の満足している拡張子」、RFC3516、2003年4月。
6. Acknowledgements
6. 承認
This documents is based on ideas proposed by Pete Resnick, Mark Crispin, Ken Murchison, Philip Guenther, Randall Gellens, and Lyndon Nerenberg.
ピートレズニック、マーク・クリスピン、ケン・マーチソン、フィリップ・グンサー、ランドルGellens、およびリンドン・ネーレンバーグによって提案された考えに基づいていますこれが、ドキュメントである。
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.
コメントと修正をフィリップ・グンサー、デーヴCridland、マーク・クリスピン、クリス・ニューマン、Elwynデイヴィース、およびバリーLeibaをありがとうございます。
literal8 syntax was taken from RFC 3516.
RFC3516からliteral8構文を取りました。
Melnikov & Daboo Standards Track [Page 15] RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
メリニコフとDaboo標準化過程[15ページ]RFC4466は2006年4月に拡大をIMAP4 ABNFに集めました。
Authors' Addresses
作者のアドレス
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex, TW12 2BX UK
AlexeyメリニコフIsode株式会社5城のビジネス村の36駅のRoadハンプトン、ミドルセックスTW12 2BXイギリス
EMail: Alexey.Melnikov@isode.com
メール: Alexey.Melnikov@isode.com
Cyrus Daboo
サイラスDaboo
EMail: cyrus@daboo.name
メール: cyrus@daboo.name
Melnikov & Daboo Standards Track [Page 16] RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
メリニコフとDaboo標準化過程[16ページ]RFC4466は2006年4月に拡大をIMAP4 ABNFに集めました。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Melnikov & Daboo Standards Track [Page 17]
メリニコフとDaboo標準化過程[17ページ]
一覧
スポンサーリンク
