Network Working Group C. Daboo
Request for Comments: 5464 Apple, Inc.
Category: Standards Track February 2009
The IMAP METADATA Extension
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "metadata" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server.
インターネットメッセージアクセスプロトコルにメタデータの拡張子は、クライアントとサーバがIMAPサーバの「注釈」または「メタデータ」を維持することが可能。メールボックスごとにまたは全体として、サーバー上の注釈を持つことが可能です。例えば、これは、特定のメールボックスの目的についてのコメントは、そのメールボックスに「添付」することができるようになる、またはサーバーのステータス情報を含む「その日のメッセージは、」サーバーにログイン誰にでも利用できるようにします。
Table of Contents
目次
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Namespace of Entries . . . . . . . . . . . . . . . . . . . 4
3.2.1. Entry Names . . . . . . . . . . . . . . . . . . . . . 5
3.3. Private versus Shared and Access Control . . . . . . . . . 6
4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 7
4.1. General Considerations . . . . . . . . . . . . . . . . . . 7
4.2. GETMETADATA Command . . . . . . . . . . . . . . . . . . . 8
4.2.1. MAXSIZE GETMETADATA Command Option . . . . . . . . . . 9
4.2.2. DEPTH GETMETADATA Command Option . . . . . . . . . . . 10
4.3. SETMETADATA Command . . . . . . . . . . . . . . . . . . . 10
4.4. METADATA Response . . . . . . . . . . . . . . . . . . . . 12
4.4.1. METADATA Response with Values . . . . . . . . . . . . 13
4.4.2. Unsolicited METADATA Response without Values . . . . . 13
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. Entry and Attribute Registration Template . . . . . . . . 16
6.2. Server Entry Registrations . . . . . . . . . . . . . . . . 16
6.2.1. /shared/comment . . . . . . . . . . . . . . . . . . . 17
6.2.2. /shared/admin . . . . . . . . . . . . . . . . . . . . 17
6.3. Mailbox Entry Registrations . . . . . . . . . . . . . . . 17
6.3.1. /shared/comment . . . . . . . . . . . . . . . . . . . 18
6.3.2. /private/comment . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Normative References . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 19
The goal of the METADATA extension is to provide a means for clients to set and retrieve "annotations" or "metadata" on an IMAP server. The annotations can be associated with specific mailboxes or the server as a whole. The server can choose to support only server annotations or both server and mailbox annotations.
メタデータ拡張の目的は、クライアントがIMAPサーバー上の「注釈」または「メタデータ」を設定し、取得するための手段を提供することです。注釈は、特定のメールボックスまたはサーバー全体に関連付けることができます。サーバは、サーバの注釈または両方のサーバとメールボックスの注釈をサポートすることを選択することができます。
A server that supports both server and mailbox annotations indicates the presence of this extension by returning "METADATA" as one of the supported capabilities in the CAPABILITY command response.
両方のサーバーとメールボックスの注釈をサポートするサーバは、CAPABILITYコマンド応答でサポートされている機能の一つとして、「メタデータ」を返すことによって、この拡張機能の存在を示しています。
A server that supports only server annotations indicates the presence of this extension by returning "METADATA-SERVER" as one of the supported capabilities in the CAPABILITY command response.
サーバのみの注釈をサポートするサーバは、CAPABILITYコマンド応答でサポートされている機能の一つとして、「メタデータ-SERVER」を返すことによって、この拡張機能の存在を示しています。
A server that supports unsolicited annotation change responses MUST support the "ENABLE" [RFC5161] extension to allow clients to turn that feature on.
迷惑注釈変更応答をサポートするサーバは、クライアントがその機能をオンにできるように、「ENABLE」[RFC5161]拡張をサポートしなければなりません。
The METADATA extension adds two new commands and one new untagged response to the IMAP base protocol.
メタデータ拡張は、2つの新しいコマンドとIMAPベースのプロトコルへの1つの新しいタグなしの応答を追加します。
This extension makes the following changes to the IMAP protocol:
この拡張は、IMAPプロトコルを次のように変更します
o adds a new SETMETADATA command
oは新しいSETMETADATAコマンドが追加されます
o adds a new GETMETADATA command
oが新しいのgetMetaDataコマンドが追加されます
o adds a new METADATA untagged response
oは新しいメタデータタグなし応答を追加します
o adds a new METADATA response code
oは新しいメタデータ応答コードを追加します
The rest of this document describes the data model and protocol changes more rigorously.
このドキュメントの残りの部分は、データモデルを記述し、プロトコルは、より厳密に変更されます。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively.
実施例において、「C：」および「S：」は、それぞれ、クライアントとサーバによって送信されたラインを示します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Whitespace and line breaks have been added to the examples in this document to promote readability.
空白や改行は、読みやすさを促進するためにこのドキュメントの例に追加されました。
Mailboxes or the server as a whole may have zero or more annotations associated with them. An annotation contains a uniquely named entry, which has a value. Annotations can be added to mailboxes when a mailbox name is provided as the first argument to the SETMETADATA command, or to the server as a whole when the empty string is provided as the first argument to the command.
全体としてメールボックスまたはサーバーには、関連するゼロ個以上の注釈を有することができます。注釈は、値を持つ一意の名前のエントリが含まれています。メールボックス名がSETMETADATAコマンドに、または空の文字列がコマンドの最初の引数として提供され、全体としてサーバへの最初の引数として提供されたときに注釈がメールボックスに追加することができます。
For example, a general comment being added to a mailbox may have an entry name of "/comment" and a value of "Really useful mailbox".
たとえば、メールボックスに追加されている一般的なコメントは、「/コメント」のエントリ名と、「本当に便利なメールボックス」の値を有することができます。
The protocol changes to IMAP described below allow a client to access or change the values of any annotation entry, assuming it has sufficient access rights to do so.
IMAPのプロトコルの変更は、それがそうするための十分なアクセス権を持っていると仮定すると、クライアントは任意の注釈エントリの値にアクセスしたり変更することができ、以下に説明しました。
Each annotation is an entry that has a hierarchical name, with each component of the name separated by a slash ("/"). An entry name MUST NOT contain two consecutive "/" characters and MUST NOT end with a "/" character.
各注釈は、スラッシュ（「/」）で区切られた名前の各成分と、階層名を持つエントリです。エントリ名は、2つの連続する「/」文字を含めることはできませんし、「/」文字で終了することはできません。
The value of an entry is NIL (has no value), or a string or binary data of zero or more octets. A string MAY contain multiple lines of text. Clients MUST use the CRLF (0x0D 0x0A) character octet sequence to represent line ends in a multi-line string value.
エントリの値がNIL（値がない）、または文字列またはゼロ以上のオクテットのバイナリデータです。文字列は、複数行のテキストを含むかもしれません。クライアントは、複数行の文字列値にCRLFラインを表現する（0x0Dを0x0Aを）文字オクテットシーケンス終了を使用しなければなりません。
Entry names MUST NOT contain asterisk ("*") or percent ("%") characters and MUST NOT contain non-ASCII characters or characters with octet values in the range 0x00 to 0x19. Invalid entry names result in a BAD response in any IMAP command in which they are used.
エントリ名は、アスタリスク（「*」）またはパーセント（「％」）の文字を含んではならないと0x19の範囲のオクテット値では0x00を非ASCII文字や文字を含めることはできません。無効なエントリ名は、それらが使用される任意のIMAPコマンドでBAD応答をもたらします。
Entry names are case-insensitive.
エントリ名は大文字と小文字を区別しません。
Use of control or punctuation characters in entry names is strongly discouraged.
エントリ名での制御や句読点の使用は強くお勧めします。
This specification defines an initial set of entry names available for use with mailbox and server annotations. In addition, an extension mechanism is described to allow additional names to be added for extensibility.
この仕様は、メールボックスとサーバーの注釈で使用可能なエントリ名の最初のセットを定義します。また、拡張機構が追加の名前は、拡張性のために添加することができるように記載されています。
The first component in entry names defines the scope of the annotation. Currently, only the prefixes "/private" or "/shared" are defined. These prefixes are used to indicate whether an annotation is stored on a per-user basis ("/private") and not visible to other users, or whether an annotation is shared between authorized users ("/shared") with a single value that can be read and changed by authorized users with appropriate access. See Section 3.3 for details.
エントリ名中の第1成分は、アノテーションの適用範囲を定義します。現在、唯一の接頭辞は「/プライベート」または「/共有」に定義されています。これらのプレフィックスは、アノテーションがユーザーごとに（「/プライベート」）および他のユーザーには見えないが記憶されているかどうかを示すために使用される、または注釈を単一の値で許可されたユーザ（「/共有」）との間で共有されているかどうかをその読み、適切なアクセス権を持つ権限のあるユーザーによって変更することができます。詳細については、3.3節を参照してください。
Entry names can have any number of components starting at 2, unless they fall under the vendor namespaces (i.e., have a /shared/vendor/ <vendor-token> or /private/vendor/<vendor-token> prefix as described below), in which case they have at least 4 components.
彼らは、ベンダーの名前空間に該当しない限り、エントリ名は、（以下に説明するように、すなわち、/共有/ベンダー/ <ベンダートークン>または/プライベート/ベンダー/ <ベンダートークン>接頭辞を有する）、2から始まる任意の数の構成要素を有することができます、その場合、それらは、少なくとも4つの成分を有します。
Entry names MUST be specified in a Standards Track or IESG-approved Experimental RFC, or fall under the vendor namespace. See Section 6.1 for the registration template.
エントリ名は標準化過程かIESGが承認した実験的RFCで指定された、またはベンダーの名前空間に該当しなければなりません。登録テンプレートについては、セクション6.1を参照してください。
These entries are set or retrieved when the mailbox name argument to the new SETMETADATA or GETMETADATA command is the empty string.
新しいSETMETADATAかのgetMetaDataコマンドへのメールボックス名引数が空の文字列であるとき、これらのエントリは、設定または取得されています。
/shared/comment
/共有/コメント
Defines a comment or note that is associated with the server and that is shared with authorized users of the server.
サーバーに関連付けられているし、それは、サーバーの権限のあるユーザーで共有されているコメントや注釈を定義します。
/shared/admin
/共有/管理
Indicates a method for contacting the server administrator. The value MUST be a URI (e.g., a mailto: or tel: URL). This entry is always read-only -- clients cannot change it. It is visible to authorized users of the system.
サーバ管理者に連絡する方法を示します。 （：またはTEL：URL例えば、mailtoの）値はURIでなければなりません。このエントリは、常に読み取り専用です - クライアントはそれを変更することはできません。これは、システムの許可されたユーザーに表示されます。
/shared/vendor/<vendor-token>
/共有/ベンダー/ <ベンダートークン>
Defines the top level of shared entries associated with the server, as created by a particular product of some vendor. This entry can be used by vendors to provide server- or client-specific annotations. The vendor-token MUST be registered with IANA, using the Application Configuration Access Protocol (ACAP) [RFC2244] vendor subtree registry.
いくつかのベンダーの特定の製品によって作成され、サーバに関連付けられている共有エントリの最上位レベルを定義します。このエントリは、サーバ - クライアントまたは固有のアノテーションを提供するために、ベンダーが使用することができます。ベンダートークンは、アプリケーション設定アクセスプロトコル（ACAP）[RFC2244]ベンダーサブツリーレジストリを使用して、IANAに登録されなければなりません。
/private/vendor/<vendor-token>
/プライベート/ベンダー/ <ベンダートークン>
Defines the top level of private entries associated with the server, as created by a particular product of some vendor. This entry can be used by vendors to provide server- or client-specific annotations. The vendor-token MUST be registered with IANA, using the ACAP [RFC2244] vendor subtree registry.
いくつかのベンダーの特定の製品で作成されたとして、サーバーに関連付けられた秘密のエントリのトップレベルを定義します。このエントリは、サーバ - クライアントまたは固有のアノテーションを提供するために、ベンダーが使用することができます。ベンダートークンはACAP [RFC2244]ベンダーサブツリーレジストリを使用して、IANAに登録されなければなりません。
These entries are set or retrieved when the mailbox name argument to the new SETMETADATA or GETMETADATA command is not the empty string.
新しいSETMETADATAかのgetMetaDataコマンドへのメールボックス名引数が空の文字列でない場合、これらのエントリは、設定または取得されています。
/shared/comment
/共有/コメント
Defines a shared comment or note associated with a mailbox.
メールボックスに関連付けられた共有コメントや注釈を定義します。
/private/comment
/プライベート/コメント
Defines a private (per-user) comment or note associated with a mailbox.
メールボックスに関連付けられた秘密（ユーザ単位の）コメントや注釈を定義します。
/shared/vendor/<vendor-token>
/共有/ベンダー/ <ベンダートークン>
Defines the top level of shared entries associated with a specific mailbox, as created by a particular product of some vendor. This entry can be used by vendors to provide client-specific annotations. The vendor-token MUST be registered with IANA, using the ACAP [RFC2244] vendor subtree registry.
いくつかのベンダーの特定の製品によって作成されたように、特定のメールボックスに関連付けられている共有エントリの最上位レベルを定義します。このエントリは、クライアント固有のアノテーションを提供するために、ベンダーが使用することができます。ベンダートークンはACAP [RFC2244]ベンダーサブツリーレジストリを使用して、IANAに登録されなければなりません。
/private/vendor/<vendor-token>
/プライベート/ベンダー/ <ベンダートークン>
Defines the top level of private entries associated with a specific mailbox, as created by a particular product of some vendor. This entry can be used by vendors to provide client-specific annotations. The vendor-token MUST be registered with IANA, using the ACAP [RFC2244] vendor subtree registry.
いくつかのベンダーの特定の製品で作成されたとして、特定のメールボックスに関連付けられた秘密のエントリのトップレベルを定義します。このエントリは、クライアント固有のアノテーションを提供するために、ベンダーが使用することができます。ベンダートークンはACAP [RFC2244]ベンダーサブツリーレジストリを使用して、IANAに登録されなければなりません。
In the absence of the ACL (Access Control List) extension [RFC4314], users can only set and retrieve private or shared mailbox annotations on a mailbox that exists and is returned to them via a LIST or LSUB command, and on which they have either read or write access to the actual message content of the mailbox (as determined by the READ-ONLY and READ-WRITE response codes as described in Section 5.2 of [RFC4314]).
ACL（アクセス制御リスト）拡張[RFC4314]がない場合には、ユーザーにのみ存在し、LISTまたはLSUBコマンドを経由して、それらに戻され、その上、彼らはどちらか持っているメールボックスにプライベートまたは共有メールボックスの注釈を設定および取得することができます読み取りまたは書き込みメールボックスの実際のメッセージ内容にアクセスする（READ-ONLYによって決定されるように読み書きを応答コードに[RFC4314]のセクション5.2に記載されているように）。
When the ACL extension [RFC4314] is present, users can only set and retrieve private or shared mailbox annotations on a mailbox on which they have the "l" right and any one of the "r", "s", "w", "i", or "p" rights.
ACL拡張[RFC4314]が存在する場合、ユーザは、設定され、それらが「L」権利および「R」、「S」、「W」のいずれかを持っている上のメールボックスにプライベートまたは共有メールボックスの注釈を取得することができ、 "I"、または "P" の権利を保有。
If a client attempts to set or retrieve annotations on mailboxes that do not satisfy the conditions above, the server MUST respond with a NO response.
クライアントが上記の条件を満たしていないメールボックスに注釈を設定または取得しようとした場合、サーバはNOで応答する必要があります。
Users can always retrieve private or shared server annotations if they exist. Servers MAY restrict the creation of private or shared server annotations as appropriate. When restricted, the server MUST return a NO response when the SETMETADATA command is used to try to create a server annotation.
それらが存在する場合、ユーザーは常に、プライベートまたは共有サーバーの注釈を取得することができます。サーバーは、必要に応じて、プライベートまたは共有サーバーの注釈の作成を制限することができます。制限された場合は、サーバーはSETMETADATAコマンドは、サーバーの注釈を作成しようとするために使用されても応答を返してはなりません。
If the METADATA extension is present, support for shared annotations is REQUIRED, whilst support for private annotations is OPTIONAL. This recognizes the fact that support for private annotations may introduce significantly more complexity to a server in terms of tracking ownership of the annotations, how quota is determined for users based on their own annotations, etc.
メタデータ拡張が存在するならば、民間のアノテーションのサポートがオプションである一方で、共有のアノテーションのサポートが必要です。これは、など、プライベート注釈のサポートはクォータが自分自身の注釈に基づいてユーザーのために決定されるか、注釈の所有権を追跡するという点で、サーバーにかなり多くの複雑さを導入する可能性があるという事実を認識し、
The new SETMETADATA command and the METADATA response each have a mailbox name argument. An empty string is used for the mailbox name to signify server annotations. A non-empty string is used to signify mailbox annotations attached to the corresponding mailbox.
新しいSETMETADATAコマンドおよびメタデータの応答は、それぞれのメールボックス名の引数を持っています。空の文字列は、サーバーの注釈を表すために、メールボックス名に使用されます。非空の文字列は、対応するメールボックスに取り付けられたメールボックス注釈を意味するために使用されます。
Servers SHOULD ensure that mailbox annotations are automatically moved when the mailbox they refer to is renamed, i.e., the annotations follow the mailbox. This applies to a rename of the INBOX, with the additional behavior that the annotations are copied from the original INBOX to the renamed mailbox, i.e., mailbox annotations are preserved on the INBOX when it is renamed.
サーバは、すなわち、注釈がメールボックスに従ってください、彼らはを参照して、メールボックスの名前が変更されたときに、そのメールボックスの注釈が自動的に移動されていることを確認すべきです。これは注釈が名前が変更されたとき、すなわち、メールボックスの注釈をINBOXに保存され、名前が変更されたメールボックスに、元の受信トレイからコピーされるという追加の行動で、INBOXの名前の変更にも適用されます。
Servers SHOULD delete annotations for a mailbox when the mailbox is deleted, so that a mailbox created with the same name as a previously existing mailbox does not inherit the old mailbox annotations.
メールボックスが削除されたときに、以前に既存のメールボックスと同じ名前で作成されたメールボックスが古いメールボックスの注釈を継承しないように、サーバーは、メールボックスの注釈を削除する必要があります。
Servers SHOULD allow annotations on all 'types' of mailboxes, including ones reporting \Noselect for their LIST response. Servers can implicitly remove \Noselect mailboxes when all child mailboxes are removed, and, at that time any annotations associated with the \Noselect mailbox SHOULD be removed.
サーバーは、そのLIST応答のための\ NOSELECTを報告するものも含め、メールボックスのすべての「種類」に注釈を許可する必要があります。すべての子メールボックスが削除されたときにサーバーが暗黙のうちに\ NOSELECTのメールボックスを削除することができ、かつ、その時点で\ NOSELECTメールボックスに関連付けられたすべての注釈を削除する必要があります。
The server is allowed to impose limitations on the size of any one annotation or the total number of annotations for a single mailbox or for the server as a whole. However, the server MUST accept an annotation data size of at least 1024 bytes, and an annotation count per server or mailbox of at least 10.
サーバは、いずれかの注釈のサイズまたは単一のメールボックスまたはサーバ全体の注釈の総数に制限を課すことを許可されています。ただし、サーバーは、少なくとも1024バイトの注釈データのサイズ、および少なくとも10のサーバーまたはメールボックスあたりの注釈数を受け入れなければなりません。
Some annotations may be "read-only" -- i.e., they are set by the server and cannot be changed by the client. Also, such annotations may be "computed" -- i.e., the value changes based on underlying properties of the mailbox or server. For example, an annotation reporting the total size of all messages in the mailbox would change as messages are added or removed. Or, an annotation containing an IMAP URL for the mailbox would change if the mailbox was renamed.
つまり、彼らは、サーバーによって設定され、クライアントによって変更することはできません - いくつかの注釈は、「読み取り専用」であってもよいです。また、このような注釈は「計算」であり得る - すなわち、メールボックスまたはサーバの特性を根本的に基づいて値が変化します。たとえば、メールボックス内のすべてのメッセージの合計サイズを報告する注釈は、メッセージが追加または削除されるように変更します。メールボックスの名前が変更された場合は、メールボックスのIMAPのURLを含む注釈が変化するであろう。
Servers MAY support sending unsolicited responses for use when annotations are changed by some "third-party" (see Section 4.4). In order to do so, servers MUST support the ENABLE command [RFC5161] and MUST only send unsolicited responses if the client used the ENABLE command [RFC5161] extension with the capability string "METADATA" or "METADATA-SERVER" earlier in the session, depending on which of those capabilities is supported by the server.
サーバーは注釈が、いくつかの「サードパーティ」によって変更された場合（4.4節を参照）を使用するために迷惑応答の送信をサポートするかもしれません。そうするためには、サーバは、[RFC5161]をENABLEコマンドをサポートしなければならないと、クライアントは、以前のセッションの機能文字列「メタデータ」または「METADATA-SERVER」でコマンドをENABLE [RFC5161]拡張を使用した場合にのみ、迷惑応答を送らなければなりません、これらの機能のどれに応じて、サーバーによってサポートされています。
This extension adds the GETMETADATA command. This allows clients to retrieve server or mailbox annotations.
この拡張は、のgetMetaDataコマンドが追加されます。これは、クライアントがサーバーまたはメールボックスの注釈を取得することができます。
This command is only available in authenticated or selected state [RFC3501].
このコマンドは、認証された又は選択された状態[RFC3501]でのみ利用可能です。
Arguments: mailbox-name
options
entry-specifier
Responses: required METADATA response
回答：必要なメタデータの応答
Result: OK - command completed NO - command failure: can't access annotations on the server BAD - command unknown or arguments invalid
結果：サーバーBAD上の注釈にアクセスすることはできません - 無効なコマンド不明または引数：OK - コマンドの失敗 - コマンドはNOを完了
When the mailbox name is the empty string, this command retrieves server annotations. When the mailbox name is not empty, this command retrieves annotations on the specified mailbox.
メールボックス名が空の文字列である場合には、このコマンドは、サーバの注釈を取得します。メールボックス名が空でない場合は、このコマンドは、指定したメールボックスの注釈を取得します。
Options MAY be included with this command and are defined below.
オプションには、このコマンドに含まれていてもよいし、以下に定義されています。
Example:
例：
C: a GETMETADATA "" /shared/comment
S: * METADATA "" (/shared/comment "Shared comment")
S: a OK GETMETADATA complete
In the above example, the contents of the value of the "/shared/ comment" server entry is requested by the client and returned by the server.
上記の例では、「/共有/コメント」サーバ・エントリの値の内容は、クライアントによって要求され、サーバによって返されました。
Example:
例：
C: a GETMETADATA "INBOX" /private/comment
S: * METADATA "INBOX" (/private/comment "My own comment")
S: a OK GETMETADATA complete
In the above example, the contents of the value of the "/private/ comment" mailbox entry for the mailbox "INBOX" is requested by the client and returned by the server.
上記の例では、メールボックス「INBOX」のための「/プライベート/コメント」メールボックスのエントリの値の内容は、クライアントによって要求され、サーバによって返されました。
Entry specifiers can be lists of atomic specifiers, so that multiple annotations may be returned in a single GETMETADATA command.
複数の注釈が単一のgetMetaDataコマンドで返されてもよいように、エントリ指定子は、アトミック指定子のリストとすることができます。
Example:
例：
C: a GETMETADATA "INBOX" (/shared/comment /private/comment)
S: * METADATA "INBOX" (/shared/comment "Shared comment"
/private/comment "My own comment")
S: a OK GETMETADATA complete
In the above example, the values of the two server entries "/shared/comment" and "/private/comment" on the mailbox "INBOX" are requested by the client and returned by the server.
上記の例では、メールボックスの「INBOX」上の2つのサーバ・エントリ「/共有/コメント」と「/プライベート/コメント」の値は、クライアントによって要求され、サーバーによって返されました。
When the MAXSIZE option is specified with the GETMETADATA command, it restricts which entry values are returned by the server. Only entry values that are less than or equal in octet size to the specified MAXSIZE limit are returned. If there are any entries with values larger than the MAXSIZE limit, the server MUST include the METADATA LONGENTRIES response code in the tagged OK response for the GETMETADATA command. The METADATA LONGENTRIES response code returns the size of the biggest entry value requested by the client that exceeded the MAXSIZE limit.
MAXSIZEオプションがのgetMetaDataコマンドで指定されている場合は、値がサーバーによって返されるエントリ制限します。指定MAXSIZE限界オクテット大きさ以下であるのみエントリの値が返されます。 MAXSIZE限界より大きな値を持つエントリがある場合、サーバは、のgetMetaDataコマンドのタグ付けされたOK応答のメタデータLONGENTRIES応答コードを含まなければなりません。 METADATA LONGENTRIES応答コードは、MAXSIZE制限を超えて、クライアントから要求された最大のエントリ値のサイズを返します。
Example:
例：
C: a GETMETADATA "INBOX" (MAXSIZE 1024)
(/shared/comment /private/comment)
S: * METADATA "INBOX" (/private/comment "My own comment")
S: a OK [METADATA LONGENTRIES 2199] GETMETADATA complete
In the above example, the values of the two server entries "/shared/comment" and "/private/comment" on the mailbox "INBOX" are requested by the client, which wants to restrict the size of returned values to 1024 octets. In this case, the "/shared/ comment" entry value is 2199 octets and is not returned.
上記の例では、メールボックスの「INBOX」上の2つのサーバ・エントリ「/共有/コメント」と「/プライベート/コメント」の値は1024個のオクテットに返された値の大きさを制限したいクライアントによって要求されています。この場合は、「/共有/コメント」エントリ値は2199個のオクテットで、返されません。
When the DEPTH option is specified with the GETMETADATA command, it extends the list of entry values returned by the server. For each entry name specified in the GETMETADATA command, the server returns the value of the specified entry name (if it exists), plus all entries below the entry name up to the specified DEPTH. Three values are allowed for DEPTH:
DEPTHオプションがのgetMetaDataコマンドで指定されている場合は、サーバによって返されたエントリの値のリストを拡張します。 getMetaDataコマンドで指定された各項目名に、サーバは、（存在する場合）指定されたエントリ名の値を返し、プラスのすべてのエントリ所定の深さまでのエントリ名以下。 3つの値がDEPTHのために許可されています。
"0" - no entries below the specified entry are returned "1" - only entries immediately below the specified entry are returned "infinity" - all entries below the specified entry are returned
「0」 - 指定されたエントリの下にはエントリは「1」が返されません - すぐに指定されたエントリの下のエントリだけが「無限大」に戻ります - 指定されたエントリの下のすべてのエントリが返されます
Thus, "depth 1" for an entry "/a" will match "/a" as well as its children entries (e.g., "/a/b"), but will not match grandchildren entries (e.g., "/a/b/c").
このように、エントリの「深さ1」「/」「/」だけでなく、その子のエントリ（例えば、「/ A / B」）が、孫のエントリと一致しません（例えば、「/ A / Bと一致します/ C "）。
If the DEPTH option is not specified, this is the same as specifying "DEPTH 0".
DEPTHオプションが指定されていない場合、これは「DEPTH 0」を指定するのと同じです。
Example:
例：
C: a GETMETADATA "INBOX" (DEPTH 1)
(/private/filters/values)
S: * METADATA "INBOX" (/private/filters/values/small
"SMALLER 5000" /private/filters/values/boss
"FROM \"boss@example.com\"")
S: a OK GETMETADATA complete
In the above example, 2 entries below the /private/filters/values
entry exist on the mailbox "INBOX": "/private/filters/values/
small" and "/private/filters/values/boss".
This extension adds the SETMETADATA command. This allows clients to set annotations.
この拡張は、SETMETADATAコマンドが追加されます。これは、クライアントが注釈を設定することができます。
This command is only available in authenticated or selected state [RFC3501].
このコマンドは、認証された又は選択された状態[RFC3501]でのみ利用可能です。
Arguments: mailbox-name
entry
value
list of entry, values
Responses: no specific responses for this command
回答：このコマンドのための特定の応答がありません
Result: OK - command completed NO - command failure: can't set annotations, or annotation too big or too many BAD - command unknown or arguments invalid
結果：注釈を設定することができない、または注釈大きすぎるか、あまりにも多くのBAD - 無効なコマンド不明または引数：OK - コマンドの失敗 - コマンドが完了NO
This command sets the specified list of entries by adding or replacing the specified values provided, on the specified existing mailboxes or on the server (if the mailbox argument is the empty string). Clients can use NIL for the value of entries it wants to remove. The server SHOULD NOT return a METADATA response containing the updated annotation data. Clients MUST NOT assume that a METADATA response will be sent, and MUST assume that if the command succeeds, then the annotation has been changed.
このコマンドは、（メールボックスの引数が空の文字列の場合）指定された既存のメールボックスまたはサーバー上で、提供する指定された値を追加または置換することによって、エントリの指定されたリストを設定します。クライアントは、それが除去したい項目の値をNILを使用することができます。サーバーは、更新されたアノテーションデータを含むメタデータのレスポンスを返すべきではありません。クライアントは、メタデータの応答が送信されることを仮定してはいけませんし、コマンドが成功した場合、その注釈が変更されたと仮定しなければなりません。
If the server is unable to set an annotation because the size of its value is too large, the server MUST return a tagged NO response with a "[METADATA MAXSIZE NNN]" response code when NNN is the maximum octet count that it is willing to accept.
その値の大きさが大きすぎるため、サーバーは、注釈を設定することができない場合NNNはそれにも構わないと思っている最大オクテット数である場合、サーバは、「[METADATA MAXSIZE NNN]」応答コードで応答なしをタグ付けしていない返さなければなりません受け入れます。
If the server is unable to set a new annotation because the maximum number of allowed annotations has already been reached, the server MUST return a tagged NO response with a "[METADATA TOOMANY]" response code.
許容注釈の最大数に既に達しているため、サーバーは新しい注釈を設定することができない場合、サーバは、「[METADATA TOOMANY]」応答コードでタグ付けされたNO応答を返すはなりません。
If the server is unable to set a new annotation because it does not support private annotations on one of the specified mailboxes, the server MUST return a tagged NO response with a "[METADATA NOPRIVATE]" response code.
サーバーは、新しい注釈を設定することができない場合は、指定したメールボックスのいずれかでプライベート注釈をサポートしていないため、サーバーは、「[METADATA NOPRIVATE]」応答コードでタグ付きNO応答を返さないしなければなりません。
When any one annotation fails to be set, resulting in a tagged NO response from the server, then the server MUST NOT change the values for other annotations specified in the SETMETADATA command.
いずれかの注釈がサーバからのタグ付けされたNO応答して、その結果、設定に失敗した場合、サーバはSETMETADATAコマンドで指定された他の注釈の値を変更しないでください。
Example:
例：
C: a SETMETADATA INBOX (/private/comment {33}
S: + ready for data
My new comment across
two lines.
)
S: a OK SETMETADATA complete
In the above example, the entry "/private/comment" for the mailbox "INBOX" is created (if not already present) and the value set to a multi-line string.
上記の例では、メールボックス「INBOX」のエントリ「/プライベート/コメントは、」作成（ない既に存在する場合）と、複数行の文字列に設定された値です。
Example:
例：
C: a SETMETADATA INBOX (/private/comment NIL)
S: a OK SETMETADATA complete
In the above example, the entry "/private/comment" is removed from the mailbox "INBOX".
上記の例では、エントリ「/プライベート/コメントは、」メールボックス「INBOX」から削除されます。
Multiple entries can be set in a single SETMETADATA command by listing entry-value pairs in the list.
複数のエントリは、リスト内のエントリと値のペアを一覧表示することで、単一のSETMETADATAコマンドで設定することができます。
Example:
例：
C: a SETMETADATA INBOX (/private/comment "My new comment"
/shared/comment "This one is for you!")
S: a OK SETMETADATA complete
In the above example, the entries "/private/comment" and "/shared/ comment" for the mailbox "INBOX" are created (if not already present) and the values set as specified.
上記の例では、エントリは「/プライベート/コメント」とメールボックス「INBOX」（ない既に存在する場合）が作成され、指定された設定値については、「/共有/コメント」。
Example:
例：
C: a SETMETADATA INBOX (/private/comment "My new comment")
S: a NO [METADATA TOOMANY] SETMETADATA failed
In the above example, the server is unable to set the requested (new) annotation as it has reached the limit on the number of annotations it can support on the specified mailbox.
上記の例では、サーバは、それが指定されたメールボックスにサポートすることができるアノテーションの数の制限に達したとして要求（新たな）注釈を設定することができません。
The METADATA response displays results of a GETMETADATA command, or can be returned as an unsolicited response at any time by the server in response to a change in a server or mailbox annotation.
METADATA応答表示のgetMetaDataコマンドの結果、またはサーバまたはメールボックス注釈の変化に応答してサーバによっていつでも迷惑応答として返すことができます。
When unsolicited responses are activated by the ENABLE [RFC5161] command for this extension, servers MUST send unsolicited METADATA responses if server or mailbox annotations are changed by a third-party, allowing servers to keep clients updated with changes.
迷惑応答は、この拡張のENABLE [RFC5161]コマンドによって活性化されると、サーバーまたはメールボックス注釈は、サードパーティによって変更された場合、サーバは、サーバが変更で更新するクライアントを維持することができ、迷惑METADATA応答を送らなければなりません。
Unsolicited METADATA responses MUST only contain entry names, not the values. If the client wants to update any cached values, it must explicitly retrieve those using a GETMETADATA command.
迷惑METADATA応答は唯一のエントリ名ではなく、値を含まなければなりません。クライアントがキャッシュされた値を更新したい場合は、明示的のgetMetaDataコマンドを使用して、それらを取得する必要があります。
The METADATA response can contain multiple entries in a single response, but the server is free to return multiple responses for each entry or group of entries, if it desires.
METADATA応答は、単一の応答で複数のエントリを含めることができますが、サーバーはそれを望むならば、エントリの各エントリまたはグループに対して複数の応答を返すために自由です。
This response is only available in authenticated or selected state [RFC3501].
この応答は、認証された又は選択された状態[RFC3501]でのみ利用可能です。
The response consists of a list of entry-value pairs.
応答は、エントリと値のペアのリストで構成されています。
Example:
例：
C: a GETMETADATA "" /shared/comment
S: * METADATA "" (/shared/comment "My comment")
S: a OK GETMETADATA complete
In the above example, a single entry with its value is returned by the server.
上記の例では、その値を持つ単一のエントリは、サーバによって返されます。
Example:
例：
C: a GETMETADATA "INBOX" /private/comment /shared/comment
S: * METADATA "INBOX" (/private/comment "My comment"
/shared/comment "Its sunny outside!")
S: a OK GETMETADATA complete
In the above example, two entries and their values are returned by the server.
上記の例では、2つのエントリとその値は、サーバによって返されます。
Example:
例：
C: a GETMETADATA "INBOX" /private/comment /shared/comment
S: * METADATA "INBOX" (/private/comment "My comment")
S: * METADATA "INBOX" (/shared/comment "Its sunny outside!")
S: a OK GETMETADATA complete
In the above example, the server returns two separate responses for each of the two entries requested.
上記の例では、サーバは、要求された2つのエントリの各々のための2つの別々の応答を返します。
The response consists of a list of entries, each of which have changed on the server or mailbox.
応答は、サーバまたはメールボックスに変更されているそれぞれのエントリのリストで構成されています。
Example:
例：
C: a NOOP
S: * METADATA "" /shared/comment
S: a OK NOOP complete
In the above example, the server indicates that the "/shared/ comment" server entry has been changed.
上記の例では、サーバーは、「/共有/コメント」サーバ・エントリが変更されたことを示しています。
Example:
例：
C: a NOOP
S: * METADATA "INBOX" /shared/comment /private/comment
S: a OK NOOP complete
In the above example, the server indicates a change to two mailbox entries.
上記の例では、サーバーは、2つのメールボックスのエントリへの変化を示しています。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234].
以下の構文仕様は、[RFC5234]で指定された拡張バッカス・ナウアフォーム（ABNF）の表記を使用します。
Non-terminals referenced but not defined below are as defined by [RFC3501], with the new definitions in [RFC4466] superseding those in [RFC3501].
非端末は、参照ではなく、[RFC3501]のものに取って代わる[RFC4466]で新しい定義を、以下に定義される[RFC3501]で定義した通りです。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
特記しないものを除いて、すべての英字は大文字と小文字を区別しません。トークン文字列を定義するための、大・小文字の使用は、編集上明確にするためです。実装は大文字と小文字を区別しないやり方で、これらの文字列を受け入れなければなりません。
capability =/ "METADATA" / "METADATA-SERVER" ; defines the capabilities for this extension.
機能= / "メタデータ" / "メタデータ-SERVER"。この拡張機能のための機能を定義します。
command-auth =/ setmetadata / getmetadata ; adds to original IMAP command
コマンド-AUTH = / setmetadata /のgetMetaData。オリジナルのIMAPコマンドに追加されます
entries = entry / "(" entry *(SP entry) ")" ; entry specifiers
エントリ=エントリ/ "（" エントリ*（SPエントリ） "）"。エントリー指定子
entry = astring ; slash-separated path to entry ; MUST NOT contain "*" or "%"
エントリー=のAString。スラッシュで区切られたエントリへのパスを、 「*」や「％」が含まれてはなりません
entry-value = entry SP value
エントリ値=エントリのSP値
entry-values = "(" entry-value *(SP entry-value) ")" entry-list = entry *(SP entry) ; list of entries used in unsolicited ; METADATA response
エントリ値=「（」エントリ値*（SPエントリ値）「）」エントリーリスト=エントリ*（SPエントリー）。迷惑で使用されるエントリのリスト。 METADATA応答
getmetadata = "GETMETADATA" [SP getmetadata-options] SP mailbox SP entries ; empty string for mailbox implies ; server annotation.
getMetaData = "のgetMetaData" [SPのgetMetaData-オプション] SPメールボックスSPエントリ。メールボックスの空の文字列を意味します。サーバーの注釈。
getmetadata-options = "(" getmetadata-option *(SP getmetadata-option) ")"
getMetaData-オプション= "（" のgetMetaData・オプション*（SPののgetMetaData-オプション） "）"
getmetadata-option = tagged-ext-label [SP tagged-ext-val] ; tagged-ext-label and tagged-ext-val ; are defined in [RFC4466].
getMetaData択=タグ付けさ-EXT-ラベル[SPタグ化EXT-VAL]。タグ付けされた-EXT-ラベルやタグ付き-EXT-VAL; [RFC4466]で定義されています。
maxsize-opt = "MAXSIZE" SP number ; Used as a getmetadata-option
MAXSIZE-OPT = "MAXSIZE" SP番号。 getMetaData-オプションとして使用
metadata-resp = "METADATA" SP mailbox SP (entry-values / entry-list) ; empty string for mailbox implies ; server annotation.
メタデータRESP =「メタデータ」SPメールボックスSP（エントリ値/エントリーリスト）。メールボックスの空の文字列を意味します。サーバーの注釈。
response-payload =/ metadata-resp ; adds to original IMAP data responses
応答ペイロード= /メタデータRESP。オリジナルのIMAPデータ応答に追加されます
resp-text-code =/ "METADATA" SP "LONGENTRIES" SP number ; new response codes for GETMETADATA
RESPテキストコード= / "メタデータ" SP "LONGENTRIES" SPの数; getMetaDataのための新しい応答コード
resp-text-code =/ "METADATA" SP ("MAXSIZE" SP number / "TOOMANY" / "NOPRIVATE") ; new response codes for SETMETADATA ; failures
RESPテキストコード= / "メタデータ" SP（ "MAXSIZE" SP数は/ "TOOMANY" / "NOPRIVATE"）。 SETMETADATAのための新規の応答コード。障害
scope-opt = "DEPTH" SP ("0" / "1" / "infinity") ; Used as a getmetadata-option
スコープ-OPT = "DEPTH" SP（ "0" / "1" / "無限大"）。 getMetaData-オプションとして使用
setmetadata = "SETMETADATA" SP mailbox SP entry-values ; empty string for mailbox implies ; server annotation.
setmetadata =「SETMETADATA」SPメールボックスSPエントリ値。メールボックスの空の文字列を意味します。サーバーの注釈。
value = nstring / literal8
値=文字列/リテラル
All entries MUST have either "/shared" or "/private" as a prefix. Entry names MUST be specified in a Standards Track or IESG-approved Experimental RFC, or fall under the vendor namespace (i.e., use /shared/vendor/<vendor-token> or /private/vendor/<vendor-token> as the prefix).
すべてのエントリは、「/共有」または接頭辞として「/プライベート」のどちらかがなければなりません。エントリ名は標準化過程かIESGが承認した実験的RFCで指定された、あるいはベンダーの名前空間接頭辞として（すなわち、使用/共有/ベンダー/ <ベンダートークン>または/プライベート/ベンダー/ <ベンダートークン>に該当しなければなりません）。
Each entry registration MUST include a content-type that is used to indicate the nature of the annotation value. Where applicable, a charset parameter MUST be included with the content-type.
各エントリの登録は、注釈値の性質を示すために使用されるコンテンツ・タイプを含まなければなりません。該当する場合は、charsetパラメータには、コンテンツタイプに含まれなければなりません。
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: [Either "Mailbox" or "Server"]
タイプ：[いずれかの「メールボックス」または「サーバー」]
Name: [the name of the entry]
名前：[エントリの名前]
Description: [a description of what the entry is for]
説明：[エントリが何のためにあるのかの説明]
Content-type: [MIME Content-Type and charset for the entry value]
コンテンツタイプ：[エントリ値のMIMEコンテンツタイプと文字セット]
RFC Number: [for entries published as RFCs]
RFC番号：[RFCとして発表されたエントリのために]
Contact: [email and/or physical address to contact for additional information]
連絡先：[電子メールおよび/または物理アドレスは、追加の詳細のために連絡します]
The following templates specify the IANA registrations of annotation entries specified in this document.
以下のテンプレートは、この文書で指定された注釈エントリのIANA登録を指定します。
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Server
種類：サーバー
Name: /shared/comment
名前：/共有/コメント
Description: Defines a comment or note that is associated with the server and that is shared with authorized users of the server.
説明：サーバーに関連付けられているし、それは、サーバーの権限のあるユーザーで共有されているコメントや注釈を定義します。
Content-type: text/plain; charset=utf-8
コンテンツタイプ：テキスト/平野。文字セット= UTF-8
RFC Number: RFC 5464
RFC番号：RFC 5464
Contact: IMAP Extensions mailto:ietf-imapext@imc.org
連絡先：IMAP拡張のmailto：ietf-imapext@imc.org
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Server
種類：サーバー
Name: /shared/admin
名前：/共有/管理
Description: Indicates a method for contacting the server administrator. The value MUST be a URI (e.g., a mailto: or tel: URL). This entry is always read-only -- clients cannot change it. It is visible to authorized users of the system.
説明：サーバーの管理者に連絡する方法を示します。 （：またはTEL：URL例えば、mailtoの）値はURIでなければなりません。このエントリは、常に読み取り専用です - クライアントはそれを変更することはできません。これは、システムの許可されたユーザーに表示されます。
Content-type: text/plain; charset=utf-8
コンテンツタイプ：テキスト/平野。文字セット= UTF-8
RFC Number: RFC 5464
RFC番号：RFC 5464
Contact: IMAP Extensions mailto:ietf-imapext@imc.org
連絡先：IMAP拡張のmailto：ietf-imapext@imc.org
The following templates specify the IANA registrations of annotation entries specified in this document.
以下のテンプレートは、この文書で指定された注釈エントリのIANA登録を指定します。
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Mailbox
タイプ：メールボックス
Name: /shared/comment
名前：/共有/コメント
Description: Defines a shared comment or note associated with a mailbox.
説明：メールボックスに関連付けられている共有コメントや注釈を定義します。
Content-type: text/plain; charset=utf-8
コンテンツタイプ：テキスト/平野。文字セット= UTF-8
RFC Number: RFC 5464
RFC番号：RFC 5464
Contact: IMAP Extensions mailto:ietf-imapext@imc.org
連絡先：IMAP拡張のmailto：ietf-imapext@imc.org
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Mailbox
タイプ：メールボックス
Name: /private/comment
名前：/プライベート/コメント
Description: Defines a private comment or note associated with a mailbox.
説明：メールボックスに関連付けられた秘密コメントや注釈を定義します。
Content-type: text/plain; charset=utf-8
コンテンツタイプ：テキスト/平野。文字セット= UTF-8
RFC Number: RFC 5464
RFC番号：RFC 5464
Contact: IMAP Extensions mailto:ietf-imapext@imc.org
連絡先：IMAP拡張のmailto：ietf-imapext@imc.org
The security considerations in Section 11 of [RFC3501] apply here with respect to protecting annotations from snooping. Servers MAY choose to only support the METADATA and/or METADATA-SERVER extensions after a privacy layer has been negotiated by the client.
[RFC3501]のセクション11のセキュリティの考慮事項がスヌーピングから注釈を保護に関してここに適用されます。サーバーは、プライバシー層は、クライアントによって交渉された後にのみ、メタデータおよび/またはメタデータ・サーバー拡張機能をサポートすることもできます。
Annotations can contain arbitrary data of varying size. As such, servers MUST ensure that size limits are enforced to prevent a user from using up all available space on a server and preventing use by others. Clients MUST treat annotation data values as an "untrusted" source of data as it is possible for it to contain malicious content.
注釈は、様々な大きさの任意のデータを含めることができます。そのため、サーバはそのサイズ制限がサーバー上で利用可能なすべてのスペースを使用し、他の人が使用することを防止することからユーザーを防ぐために施行されることを保証しなければなりません。クライアントは、それが悪意のあるコンテンツを含むすることが可能であるように、データの「信頼できない」ソースとして注釈データ値を扱わなければなりません。
Annotations whose values are intended to remain private MUST be stored only in entries that have the "/private" prefix on the entry name.
その値はプライベート残るように意図されている注釈は、唯一のエントリ名に「/プライベート」プレフィックスを持つエントリに格納されなければなりません。
Excluding the above issues, the METADATA extension does not raise any security considerations that are not present in the base IMAP protocol, and these issues are discussed in [RFC3501].
上記問題点を除くと、メタデータ拡張は、ベースIMAPプロトコルに存在しない任意のセキュリティ問題を提起せず、これらの問題は、[RFC3501]に記載されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[RFC2244]ニューマン、C.及びJ.マイヤーズ、 "ACAP - アプリケーション構成アクセスプロトコル"、RFC 2244、1997年11月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - VERSION 4rev1"、RFC 3501、2003年3月。
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.
[RFC4314]メルニコフ、A.、 "IMAP4アクセス制御リスト（ACL）拡張"、RFC 4314、2005年12月。
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[RFC4466]メルニコフ、A.およびC. Daboo、 "IMAP4 ABNFに収集された拡張機能"、RFC 4466、2006年4月。
[RFC5161] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE Extension", RFC 5161, March 2008.
[RFC5161] Gulbrandsenの、A.とA.メルニコフ、 "IMAPエクステンションを有効にする"、RFC 5161、2008年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
Appendix A. Acknowledgments
付録A.謝辞
The ideas expressed in this document are based on the message annotation document that was co-authored by Randall Gellens. The author would like to thank the following individuals for contributing their ideas and support for writing this specification: Dave Cridland, Arnt Gulbrandsen, Dan Karp, Alexey Melnikov, Ken Murchison, Chris Newman, and Michael Wener.
この文書で表現アイデアがランドールGellensが共同執筆したメッセージの注釈文書に基づいています。デイブCridland、ARNT Gulbrandsenの、ダン・カープ、アレクセイ・メルニコフ、ケンマーチソン、クリス・ニューマン、とマイケルWener：著者は、この仕様書を書くためのアイデアやサポートの貢献のために以下の個人に感謝したいと思います。
Author's Address
著者のアドレス
Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
サイラスDabooされたApple Inc. 1無限ループクパチーノ、CA 95014 USA
EMail: cyrus@daboo.name URI: http://www.apple.com/
電子メール：cyrus@daboo.name URI：http://www.apple.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2009).
著作権（C）IETFトラスト（2009）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。