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
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).
著作権（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とレモネードワーキンググループからの多くの文書だけでなく、多くの個々の文書は、参照を容易にするため、RFC 3501に記載されている多くのベースIMAPコマンドに構文の拡張機能を追加した、この文書は、一つの場所に、このような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.
また、このドキュメントでは、パターンは、既存および将来の拡張の間の互換性を提供する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.
この文書は、この文書では、上場のRFCに何らかの意味的な変更を指定していないそれはまたRFC 3501に正誤表の一部が含まれているRFC 2088、2342、3501、3502でABNFを更新し、3516。
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.
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.
この文書は、この文書では、上場のRFCに何らかの意味的な変更を指定していないそれはまたRFC 3501に正誤表の一部が含まれているRFC 2088、2342、3501、3502でABNFを更新し、3516。
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".
ABNFはセクションでRFC 2342の6は、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は、SELECTためABNFを拡張し、STORE / UIDストア、FETCH / UIDはFETCH、RENAME、CREATE、EXAMINE、SEARCH、および一貫した方法でコマンドを追加します。すべてのコマンドへの拡張が、APPENDは、同じ構造を有しています。 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節では、また、その目的は、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].
キーワード「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、およびこのドキュメントの「要件レベルを示すためにRFCsにおける使用のためのキーワード」[キーワード]で定義されるように解釈されるべきである「MAY」 。
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.
この文書では、（[IMAP4]のセクション6.3.2）は、特定の標準的な行動上またはオフにするには、コマンド、またはIMAPにSELECT（[IMAP4]のセクション6.3.1）と1つまたは複数のパラメータを含めるか検査する機能が追加します特定の拡張のために必要な新しいオプションの振る舞いを追加します。
There are two possible modes of operation:
二つの動作可能なモードがあります。
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のオプション・パラメータの単一の使用はその時からセッション状態に影響を与えるグローバル状態変化は、/コマンドを調べます。
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。オプションのパラメータは、新たに選択したメールボックスのためにその効果をキャンセルさせていただきますことなく、次の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 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.
SELECTまたはコマンドを調べるためのオプションのパラメータは、属性/値ペアの括弧付きのリストとして追加され、標準のSELECTまたはEXAMINEコマンドでメールボックス名の後に表示されています。個々のパラメータの順序は任意です。パラメータ値は任意であり、特定の順序で原子、ストリング、またはリストから構成されてもよいです。パラメータの値が存在する場合、それは常に（*）カッコ内に表示されます。任意のパラメータは、サーバがサポートするBAD応答で拒否しなければならない拡張によって定義されていません。
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.
上記の例では、3つのパラメータはEXAMINEコマンドで使用されています。引用符で囲まれた文字列が続くアトム「の返事」：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.
上記の例では、サーバでサポートされていないパラメータが使用されます。これは、サーバーからの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を参照してください。
Arguments: mailbox name OPTIONAL list of CREATE parameters
引数：CREATEパラメーターのメールボックス名、オプションのリスト
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 - 完了NOを作成する - 失敗作成：BADという名前のメールボックスを作成することはできません - 引数を（s）は無効
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.
この文書では、特定の標準の動作上またはオフにするには、または特定の拡張のために必要な新しいオプションの振る舞いを追加するには、（[IMAP4]のセクション6.3.3を参照）CREATEコマンドをIMAPで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.
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を参照してください。
Arguments: existing mailbox name new mailbox name OPTIONAL list of RENAME parameters
引数：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 - 完了NOの名前を変更 - 失敗の名前を変更します。その名前でメールボックスの名前を変更することはできません、その名前でメールボックスに名前を変更することができない、などBAD - 引数（s）は無効
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コマンドを使用して、一つ以上のパラメータ、特定の標準的な行動上またはオフにするには、または特定の拡張のために必要な新しいオプションの振る舞いを追加するには、（[IMAP4]のセクション6.3.5を参照）を含めるする機能を追加します。いいえ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.
RENAMEコマンドのオプションのパラメータは、新しいメールボックス名の後に属性/値ペアの括弧付きのリストとして追加されます。個々のパラメータの順序は任意です。パラメータ値は任意であり、特定の順序で原子、ストリング、またはリストから構成されてもよいです。パラメータの値が存在する場合、それは常に（*）カッコ内に表示されます。任意のパラメータは、サーバがサポートする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を参照してください。
Arguments: sequence set message data item names or macro OPTIONAL fetch modifiers
引数：配列設定されたメッセージデータ項目名またはマクロOPTIONALフェッチ修飾子
Responses: untagged responses: FETCH
回答：タグなし応答：FETCH
Result: OK - fetch completed NO - fetch error: cannot fetch that data BAD - command unknown or arguments invalid
結果：OK - 完了NOを取得 - エラーを取得： - コマンド不明または引数無効そのデータ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とUIDは任意FETCH改質剤を含むように（[IMAP4]のセクション6.4.5を参照）FETCHコマンドの構文を拡張します。ノー修飾子は、この文書で定義されているフェッチ。
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を参照してください。
Arguments: message set OPTIONAL store modifiers message data item name value for message data item
引数：メッセージデータ項目のメッセージ設定オプションストア修飾子メッセージデータ項目名値
Responses: untagged responses: FETCH
回答：タグなし応答：FETCH
Result: OK - store completed NO - store error: cannot store that data BAD - command unknown or arguments invalid
結果：OK - ストアはNOを完了 - 店舗エラー：そのデータ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.
この文書では、STOREおよびUID STOREコマンドの構文を含むように任意STORE剤（[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.
個々の修飾子の順序は任意です。各修飾子は、属性/値のペアです。修飾値は任意であり、特定の順序で原子および/または文字列及び/又はリストからなってもよいです。修飾子の値が存在する場合、それは常に（*）カッコ内に表示されます。いずれの修飾は、サーバーがサポートする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を参照してください。
Arguments: OPTIONAL result specifier OPTIONAL [CHARSET] specification searching criteria (one or more)
引数：OPTIONAL結果指定子OPTIONAL [CHARSET]仕様検索基準（一つ以上）
Responses: REQUIRED untagged response: SEARCH (*)
回答：必須タグなし応答：SEARCH（*）
Result: OK - search completed NO - search error: cannot search that [CHARSET] or criteria BAD - command unknown or arguments invalid
結果：OK - 検索はNO完了していない - 検索エラー： - 不明または引数無効なコマンドその[CHARSET]または基準BADを検索することはできません
This section updates definition of the SEARCH command described in section 6.4.4 of [IMAP4].
[IMAP4]のセクション6.4.4に記載SEARCHコマンドのこのセクションを更新定義。
The SEARCH command is extended to allow for result options. This document does not define any result options.
SEARCHコマンドは、結果のオプションを可能にするように拡張されます。このドキュメントは、任意の結果オプションを定義しません。
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.
（*） - 別のタグなしの応答を必要とするかもしれないSEARCHコマンドの拡張、または全くタグなし応答が返されます。セクション2.6.2は、検索タグなし応答を置き換える新しいESEARCHタグなしの応答を定義します。すなわち、それらの一方のみが返されるべきである、それは与えられた拡張検索コマンドを検索し、ESEARCH応答は相互に排他的である必要があります。
(**) - 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を参照してください。
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 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応答のすべてのデータがの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つまたは複数の検索データのペアが含まれています。各ペアは、スペースおよび対応するデータに続いて、独自のリターン項目名で始まります。検索データのペアは、任意の順序で返されることがあります。拡張子によって別段の定めがない限り、任意のリターン項目名はESEARCH応答に1度だけ表示すべきです。
Example: S: * ESEARCH UID COUNT 5 ALL 4:19,21,28
例：S：* ESEARCH UIDのCOUNT 5 ALL 4：19,21,28
Example: S: * ESEARCH (TAG "a567") UID COUNT 5 ALL 4:19,21,28
例：S：* ESEARCH（TAG "a567"）UIDのCOUNT 5 ALL 4：19,21,28
Example: S: * ESEARCH COUNT 5 ALL 1:17,21
例：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 BINARY拡張[BINARY]は、クライアントが<literal8>構文を使用してNULsを含むデータを追加することを可能に追加のコマンドを拡張します。 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.
また、非末端「literal8」[BINARY]で定義され、両方の[BINARY]及び[LITERAL +]拡張は、サーバによってサポートされている場合、非同期リテラルを可能にするために拡張得ました。
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コマンドの一般的な構文を定義します。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
以下の構文仕様は、[ABNF]で指定された拡張バッカス・ナウアフォーム（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" SPメールボックス1は、追加メッセージを*追加;;唯一の単一付加-のメッセージが表示されることがあります;; MULTIAPPENDは[MULTIAPPEND]機能であれば;;存在しません
append-message = append-opts SP append-data
追加メッセージ=追加-OPTS SPの追記データ
append-ext = append-ext-name SP append-ext-value ;; This non-terminal define extensions to ;; to message metadata.
追加-EXT =追加-EXT-名SPのappend-EXT-値;;これは、非ターミナル;;への拡張を定義しますメッセージメタデータに。
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 /追加データ-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
追加-OPTS = [SPフラグリスト] [SP日時] *（SP追加-EXT）;;メッセージメタデータ
charset = atom / quoted ;; Exact syntax is defined in [CHARSET].
文字セット=原子/引用された;;正確な構文は[CHARSET]で定義されています。
create = "CREATE" SP mailbox [create-params] ;; Use of INBOX gives a NO error.
作成= "CREATE" SPメールボックスには、[作成-のparams] ;; INBOXを使用すると、エラーなしを与えません。
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名[SP作成-PARAM値]
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応答を注意してください;;相互に排他的であるべきで、;;即ち、応答タイプの一方のみ;;でなければなりません;;コマンドの結果として返されます。
examine = "EXAMINE" SP mailbox [select-params] ;; modifies the original IMAP EXAMINE command ;; to accept optional parameters
検討= "EXAMINE" SPメールボックス[選択-のparams] ;;オリジナルのIMAPコマンドを調べて修正し;;オプションのパラメータを受け入れ
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フェッチ-ATT）を "）" フェッチのatt * "（" "ALL" / "FULL" / "FAST" /フェッチ-ATT /） "FETCH" SPシーケンスセットのSP =フェッチ[-修飾子フェッチ]。 ;元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が含まれる可能性があります文字列。 ;; <番号>は、オクテットの数を表し;;応答文字列インチ;; 「+」のみ許可されたときにLITERAL +の両方とされる;; BINARYの拡張機能は、サーバーによってサポートされています。
mailbox-data =/ Namespace-Response / esearch-response
メールボックスデータ= /名前空間応答/ esearch応答
Namespace = nil / "(" 1*Namespace-Descr ")"
名前空間= nilを/ "（" 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]をサポートしている場合。 ;;最初の名前空間は、個人名前空間（S）です;;第二の名前空間は、他のユーザの名前空間（S）です;;第三のネームスペースは、共有名前空間（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]を;; "RENAME" 名前を変更=宛先としてINBOXを使用することはできます;; NOエラー、しない限り、リネーム-の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名[SPリネーム-PARAM値]を
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-BYE /メールボックス・データ/メッセージデータ/能力データ
search = "SEARCH" [search-return-opts] SP search-program
検索= "SEARCH" [検索-復帰-optsの] SP検索プログラム
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.
検索相関器= SP "（" "TAG" SPタグ文字列 "）" 検索プログラム= [ "CHARSET" SPの文字セットSP]検索キー*（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)] ")"
検索リターン-optsの= SP "RETURN" SP "（" [検索リターンオプト*（SP検索-リターン-OPT）] "）"
search-return-opt = search-modifier-name [SP search-mod-params]
検索リターン-OPT =検索修飾名[SP検索-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.
検索の戻り値=タグ付き-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.
検索-MOD-の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 = SP "（" を選択-のparam *を（SP選択-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.
選択-PARAM =選択-PARAM名を[SP選択-PARAM値]を;;選択するために、パラメータが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.
ステータス・ツー・リスト=状態ツー選択*（SPステータス・ツー・セレクション）;;ステータスのドロップRFC第三千五百一からの再定義
;; status-att-val is defined in RFC 3501 errata
;;状況-ATT-VALは、RFC 3501正誤表で定義されています
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の数）/（SP番号 "RECENT"）/（ "UIDNEXT" SP NZ-数）/（ "UIDVALIDITY" SP NZ-数）/（ "UNSEEN" 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
店舗= "STORE" SPシーケンスセット[ストア修飾子] SPストア-ATT-フラグ;; [IMAP4] STOREコマンドの構文を拡張;;オプションの店舗修飾を可能にします
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 *タグ付きラベル-CHAR ;;有効なRFC 3501「原子」です。
tagged-label-fchar = ALPHA / "-" / "_" / "."
タグ付けされたラベル-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.
タグ付けされたラベル-CHAR =タグ付きラベル-FCHAR / DIGIT / "：" タグの付いた-EXT-COMP =のAString /タグ付き-EXT-コンプ*（SPタグ付き-EXT-COMP）/ "（" タグ付け-EXT-COMP「） ";;この一般的に続く拡張;;構文はnstringの代わりに使用する必要があります;; AString時に適切なコンテキストで;;拡張子の。 ;;設定されたメッセージまたは「数」ことに注意してください;;常に「原子」として表すことができます。 ;; URLは次のように表されるべき;; 「引用符で囲まれた」文字列。
tagged-ext-simple = sequence-set / number
タグ付けされた-EXT-シンプル=シーケンスセット/数
tagged-ext-val = tagged-ext-simple / "(" [tagged-ext-comp] ")"
タグ付けされた-EXT-VAL =タグ付けさ-EXT-簡単/ "（" [タグ付けさ-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.
この文書は、RFCの2088、2342、3501、3502でABNFを更新し、3516更新された文書は、それらが定義する拡張のために、セキュリティの考慮事項のために相談する必要があります。
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.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP4]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
"構文仕様のための増大しているBNF：ABNF" [ABNF]クロッカー、D.、エド、およびP. Overell、。、RFC 4234、2005年10月。
[CHARSET] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[CHARSET]フリード、N.とJ.ポステル、 "IANA文字セット登録手順"、BCP 19、RFC 2978、2000年10月。
[MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, March 2003.
[MULTIAPPEND]クリスピン、M.、 "インターネットメッセージアクセスプロトコル（IMAP） - MULTIAPPEND拡張"、RFC 3502、2003年3月。
[NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998.
[NAMESPACE] Gahrns、M.とC.ニューマン、 "IMAP4名前空間"、RFC 2342、1998年5月。
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997.
[LITERAL +]マイヤーズ、J.、 "IMAP4非同期リテラル"、RFC 2088、1997年1月。
[BINARY] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, April 2003.
[BINARY] 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.
この文書は、ピート・レズニック、マーク・クリスピン、ケンマーチソン、フィリップ・ギュンター、ランドールGellens、およびリンドン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.
コメントと修正のためのフィリップ・ギュンター、デイブCridland、マーク・クリスピン、クリス・ニューマン、エルウィン・デイヴィス、そしてバリー・レイバに感謝します。
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
アレクセイ・メルニコフISODE限定5キャッスルビジネス村の36の駅道ハンプトン、ミドルセックス、TW12 2BX英国
EMail: Alexey.Melnikov@isode.com
メールアドレス：Alexey.Melnikov@isode.com
Cyrus Daboo
サイラスDaboo
EMail: cyrus@daboo.name
メールアドレス：cyrus@daboo.name
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。