[要約] RFC 5464は、IMAP METADATA拡張機能に関する仕様であり、IMAPサーバーとクライアント間でメールボックスのメタデータをやり取りするための方法を提供します。この拡張機能の目的は、メールボックスの追加情報を効率的に管理し、クライアントの機能を向上させることです。
Network Working Group C. Daboo
Request for Comments: 5464 Apple, Inc.
Category: Standards Track February 2009
The IMAP METADATA Extension
IMAPメタデータ拡張
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サーバーで「注釈」または「メタデータ」を維持できます。AnotationsをMailboxごとに、またはサーバー全体に配分することができます。たとえば、これにより、特定のメールボックスの目的に関するコメントがそのメールボックスに「添付」されるか、サーバーにログインする人が利用できるようにするサーバーステータス情報を含む「その日のメッセージ」が含まれます。
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.
サーバーとメールボックスの両方の注釈をサポートするサーバーは、「メタデータ」を機能コマンド応答のサポートされている機能の1つとして返すことにより、この拡張機能の存在を示します。
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.
サーバーアノテーションのみをサポートするサーバーは、「メタデータサーバー」を機能コマンド応答のサポートされている機能の1つとして返すことにより、この拡張機能の存在を示します。
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.
メタデータ拡張は、IMAPベースプロトコルに2つの新しいコマンドと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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
エントリの値は、ゼロ以上のオクテットの文字列またはバイナリデータです。文字列には複数のテキストが含まれる場合があります。クライアントは、CRLF（0x0D 0x0A）文字Octetシーケンスを使用して、マルチライン文字列値のラインエンドを表す必要があります。
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.
エントリ名は、アスタリスク（ "*"）またはパーセント（ "％"）文字を含めてはならず、範囲0x00〜0x19にOctet値を持つ非ASCII文字または文字を含めてはなりません。無効なエントリ名は、それらが使用されているIMAPコマンドで悪い応答をもたらします。
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.
エントリ名の最初のコンポーネントは、注釈の範囲を定義します。現在、「/プライベート」または「/共有」のプレフィックスのみが定義されています。これらのプレフィックスは、アノテーションがユーザーごと（「/プライベート」）で保存され、他のユーザーに表示されないかどうか、または認定ユーザー間で注釈が共有されるかどうかを示すために使用されます。適切なアクセスを備えた認定ユーザーによって読み、変更できます。詳細については、セクション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から始まる任意の数のコンポーネントを持つことができます（つまり、以下に説明するように、A/shared/vendor/<Vendor-Token>または/private/vendor/<Vendor-Token>プレフィックスを持っています）、その場合、少なくとも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.
サーバー管理者に連絡する方法を示します。値はURIでなければなりません（例：MailTo：またはTel：URL）。このエントリは常に読み取り専用です。クライアントは変更できません。システムの認定ユーザーに表示されます。
/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]がない場合、ユーザーは存在し、リストまたはLSUBコマンドを介してそれらに返されるメールボックスにプライベートまたは共有のメールボックスアノテーションのみを設定および取得できます。メールボックスの実際のメッセージコンテンツへの読み取りまたは書き込み（[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」のいずれかを備えたメールボックスにプライベートまたは共有のメールボックスアノテーションのみを設定および取得できます。「私」または「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.
クライアントが、上記の条件を満たさないメールボックスで注釈を設定または取得しようとする場合、サーバーは応答なしで応答する必要があります。
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.
サーバーは、呼び出されるメールボックスの名前が変更されたときに、メールボックスの注釈が自動的に移動されることを確認する必要があります。つまり、注釈はメールボックスに従います。これは、受信トレイの名前の変更に適用され、アノテーションが元の受信トレイから名前変更されたメールボックスにコピーされるという追加の動作があります。
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.
サーバーは、リスト応答のために\ 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.
サーバーは、1つの注釈のサイズまたは単一のメールボックスまたはサーバー全体の注釈の総数に制限を課すことができます。ただし、サーバーは、少なくとも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を参照）。そのためには、サーバーはenableコマンド[RFC5161]をサポートする必要があり、クライアントがセッションの早い段階でenableコマンド[RFC5161]拡張機能を使用した場合にのみ、クライアントが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
引数：Mailbox-Nameオプションエントリスペシファイア
Responses: required METADATA response
応答：必要なメタデータ応答
Result: OK - command completed NO - command failure: can't access annotations on the server BAD - command unknown or arguments invalid
結果：ok-コマンド完了なし - コマンド障害：サーバーのアノテーションにアクセスできない悪い - コマンド不明または引数無効
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.
上記の例では、「/ shared/ comment」サーバーエントリの値の内容がクライアントによって要求され、サーバーによって返されます。
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.
上記の例では、メールボックス「受信トレイ」の「/プライベート/コメント」メールボックスエントリの値の内容がクライアントによって要求され、サーバーが返品します。
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.
上記の例では、2つのサーバーエントリの値「/shared/comment」と「/private/comment」のメールボックス「受信トレイ」の値がクライアントによって要求され、サーバーによって返されます。
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制限よりも大きい値を持つエントリがある場合、サーバーには、GetMetadataコマンドのタグ付きOK応答にメタデータRengentries応答コードを含める必要があります。Metadata Longentries Responseコードは、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.
上記の例では、メールボックスの「/共有/コメント」と「/プライベート/コメント」の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:
深さオプションがGetMetadataコマンドで指定されている場合、サーバーによって返されるエントリ値のリストを拡張します。GetMetaDataコマンドで指定された各エントリ名について、サーバーは指定されたエントリ名の値（存在する場合）の値を返し、さらに指定された深さまでエントリ名の下のすべてのエントリを返します。深さに対して3つの値が許可されます。
"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」を返します - 指定されたエントリのすぐ下のエントリのみが「Infinity」を返します - 指定されたエントリの下のすべてのエントリが返されます
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は「/a」とその子供のエントリ（「/a/b」など）に一致しますが、孫のエントリと一致しません（例： "/a/b/c "）。
If the DEPTH option is not specified, this is the same as specifying "DEPTH 0".
深さオプションが指定されていない場合、これは「深さ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
結果：OK-コマンド完了なし - コマンド障害：注釈を設定できない、または注釈を大きすぎるか、または多すぎる - コマンド不明または引数が無効です
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が喜んでいる最大オクテットカウントである場合、「[メタデータ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.
許可された注釈の最大数にすでに到達しているため、サーバーが新しい注釈を設定できない場合、サーバーは「[メタデータトーマニー]」応答コードでタグ付けされた応答を返す必要があります。
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.
サーバーが指定されたメールボックスのいずれかでプライベートアノテーションをサポートしていないために新しい注釈を設定できない場合、サーバーは「[メタデータnoprivate]」応答コードでタグ付けされた応答を返す必要があります。
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.
1人の注釈が設定されず、サーバーからのタグ付き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.
上記の例では、メールボックス「受信トレイ」のエントリ「/プライベート/コメント」が作成され（まだ存在していない場合）、マルチライン文字列に設定された値が作成されます。
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".
上記の例では、エントリ「/プライベート/コメント」がメールボックス「受信トレイ」から削除されます。
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.
上記の例では、メールボックス「受信トレイ」のエントリ「/プライベート/コメント」と「/共有/コメント」が作成され（まだ存在していない場合）、指定された値が設定されています。
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.
メタデータ応答は、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.
この拡張機能の[RFC5161]コマンドを有効にする[RFC5161]コマンドによって未承諾の応答がアクティブ化される場合、サーバーまたはメールボックスの注釈がサードパーティによって変更された場合、サーバーは未承諾メタデータ応答を送信する必要があり、サーバーがクライアントを変更して最新の状態に保つことができます。
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.
未承諾のメタデータ応答には、値ではなく、エントリ名のみを含める必要があります。クライアントがキャッシュされた値を更新したい場合、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.
メタデータ応答には、単一の応答に複数のエントリを含めることができますが、サーバーは、必要に応じてエントリの各グループまたはグループごとに複数の応答を自由に返すことができます。
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]で指定されているように、拡張されたBackus-Naurフォーム（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.
command-auth =/ setmetadata / getmetadata
; adds to original IMAP command
entries = entry /
"(" entry *(SP entry) ")"
; entry specifiers
entry = astring ; slash-separated path to entry ; MUST NOT contain "*" or "%"
entry = Astring;エントリへのスラッシュ分離パス。「*」または「％」を含めてはなりません
entry-value = entry SP value
entry-values = "(" entry-value *(SP entry-value) ")"
entry-list = entry *(SP entry)
; list of entries used in unsolicited
; METADATA response
getmetadata = "GETMETADATA" [SP getmetadata-options] SP mailbox SP entries ; empty string for mailbox implies ; server annotation.
getMetadata = "getMetadata" [sp getMetadata-options] SPメールボックスSPエントリ;メールボックスの空の文字列は意味します。サーバー注釈。
getmetadata-options = "(" getmetadata-option *(SP getmetadata-option) ")"
getMetadata-options = "（" getMetadata-option *（sp getmetadata-option） "）"
getmetadata-option = tagged-ext-label [SP tagged-ext-val] ; tagged-ext-label and tagged-ext-val ; are defined in [RFC4466].
getMetadata-option = Tagged-Ext-Label [sp tagged-ext-val];タグ付き - 伸長ラベルとタグ付き - 伸長値。[RFC4466]で定義されています。
maxsize-opt = "MAXSIZE" SP number ; Used as a getmetadata-option
maxsize-opt = "maxsize" sp番号。getmetadata-optionとして使用されます
metadata-resp = "METADATA" SP mailbox SP (entry-values / entry-list) ; empty string for mailbox implies ; server annotation.
Metadata-Resp = "Metadata" SP Mailbox SP（Entry-Values / Entry-List）;メールボックスの空の文字列は意味します。サーバー注釈。
response-payload =/ metadata-resp ; adds to original IMAP data responses
Response-Payload =/ Metadata-Resp;元のIMAPデータ応答に追加します
resp-text-code =/ "METADATA" SP "LONGENTRIES" SP number
; new response codes for GETMETADATA
resp-text-code =/ "METADATA" SP ("MAXSIZE" SP number /
"TOOMANY" / "NOPRIVATE")
; new response codes for SETMETADATA
; failures
scope-opt = "DEPTH" SP ("0" / "1" / "infinity")
; Used as a getmetadata-option
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
宛先：iana@iana.org件名：IMAPメタデータの入力登録
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コンテンツタイプとcharset]
RFC Number: [for entries published as RFCs]
RFC番号：[RFCSとして公開されたエントリ用]
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
宛先：iana@iana.org件名：IMAPメタデータの入力登録
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
RFC Number: RFC 5464
RFC番号：RFC 5464
Contact: IMAP Extensions mailto:ietf-imapext@imc.org
To: iana@iana.org Subject: IMAP METADATA Entry Registration
宛先：iana@iana.org件名：IMAPメタデータの入力登録
Type: Server
タイプ：サーバー
Name: /shared/admin
名前： /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.
説明：サーバー管理者に連絡する方法を示します。値はURIでなければなりません（例：MailTo：またはTel：URL）。このエントリは常に読み取り専用です。クライアントは変更できません。システムの認定ユーザーに表示されます。
Content-type: text/plain; charset=utf-8
RFC Number: RFC 5464
RFC番号：RFC 5464
Contact: IMAP Extensions 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
宛先：iana@iana.org件名：IMAPメタデータの入力登録
Type: Mailbox
タイプ：メールボックス
Name: /shared/comment
名前： /共有 /コメント
Description: Defines a shared comment or note associated with a mailbox.
説明：メールボックスに関連付けられた共有コメントまたはメモを定義します。
Content-type: text/plain; charset=utf-8
RFC Number: RFC 5464
RFC番号：RFC 5464
Contact: IMAP Extensions mailto:ietf-imapext@imc.org
To: iana@iana.org Subject: IMAP METADATA Entry Registration
宛先：iana@iana.org件名：IMAPメタデータの入力登録
Type: Mailbox
タイプ：メールボックス
Name: /private/comment
名前： /プライベート /コメント
Description: Defines a private comment or note associated with a mailbox.
説明：メールボックスに関連付けられたプライベートコメントまたはメモを定義します。
Content-type: text/plain; charset=utf-8
RFC Number: RFC 5464
RFC番号：RFC 5464
Contact: IMAP Extensions 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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[RFC2244] Newman、C。and J. Myers、「ACAP -Application Configuration Access Protocol」、RFC 2244、1997年11月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 3501、2003年3月。
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.
[RFC4314] Melnikov、A。、「IMAP4アクセス制御リスト（ACL）拡張機能」、RFC 4314、2005年12月。
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[RFC4466] Melnikov、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. Melnikov、「IMAP Enable Extension」、RFC 5161、2008年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
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.
このドキュメントで表明されたアイデアは、Randall Gellensによって共同執筆されたメッセージ注釈文書に基づいています。著者は、次の個人に、この仕様を書くためのアイデアとサポートを提供してくれたことに感謝したいと思います。
Author's Address
著者の連絡先
Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino、CA 95014 USA
EMail: cyrus@daboo.name
URI: http://www.apple.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2009).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。