Network Working Group P. Resnick
Request for Comments: 4469 QUALCOMM Incorporated
Updates: 3501, 3502 April 2006
Category: Standards Track
Internet Message Access Protocol (IMAP) CATENATE 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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
The CATENATE extension to the Internet Message Access Protocol (IMAP) extends the APPEND command to allow clients to create messages on the IMAP server that may contain a combination of new data along with parts of (or entire) messages already on the server. Using this extension, the client can catenate parts of an already existing message onto a new message without having to first download the data and then upload it back to the server.
インターネットメッセージアクセスプロトコル（IMAP）にCATENATE拡張は、クライアントがの一部（または全部）がすでにサーバー上のメッセージとともに、新たなデータの組み合わせを含むことがIMAPサーバー上のメッセージを作成できるようにAPPENDコマンドを拡張します。この拡張機能を使用すると、クライアントは、第1のデータをダウンロードし、それをサーバーに戻ってアップロードすることなく、新しいメッセージに既存のメッセージの一部をCATENATEすることができます。
The CATENATE extension to the Internet Message Access Protocol (IMAP) [1] allows the client to create a message on the server that can include the text of messages (or parts of messages) that already exist on the server without having to FETCH them and APPEND them back to the server. The CATENATE extension extends the APPEND command so that, instead of a single message literal, the command can take as arguments any combination of message literals (as described in IMAP [1]) and message URLs (as described in the IMAP URL Scheme [2] specification). The server takes all the pieces and catenates them into the output message. The CATENATE extension can also coexist with the MULTIAPPEND extension [3] to APPEND multiple messages in a single command.
すでにそれらをFETCHすることなく、サーバー上に存在するインターネットメッセージアクセスプロトコル（IMAP）にCATENATE拡張[1]クライアントがメッセージ（またはメッセージの一部）のテキストを含めることができ、サーバー上のメッセージを作成することができますし、バックサーバーにそれらを追加します。代わりに、リテラル単一のメッセージを、コマンド引数としてメッセージリテラルの任意の組み合わせを取ることができ、そのようCATENATE拡張はAPPENDコマンドを拡張する（IMAPに記載されているように[1]）とIMAP URLスキーム[2に記載されているように、メッセージのURL（明細書）。サーバーは、すべてのピースを受け取り、出力メッセージにそれらをcatenates。 CATENATE拡張は、単一のコマンドで複数のメッセージを追加するMULTIAPPEND延長[3]と共存することができます。
There are some obvious uses for the CATENATE extension. The motivating use case was to provide a way for a resource-constrained client to compose a message for subsequent submission that contains data that already exists in that client's IMAP store. Because the client does not have to download and re-upload potentially large message parts, bandwidth and processing limitations do not have as much impact. In addition, since the client can create a message in its own IMAP store, the command also addresses the desire of the client to archive a copy of a sent message without having to upload the message twice. (Mechanisms for sending the message are outside the scope of this document.)
CATENATE拡張のためのいくつかの明白な用途があります。やる気のユースケースは、すでにそのクライアントのIMAPストアに存在するデータが含まれ、その後の提出のためのメッセージを作成するには、リソースに制約のあるクライアントのための方法を提供することでした。クライアントはダウンロードする必要はありませんし、再アップロード潜在的に大きなメッセージ部分、帯域幅と処理の制限が同じくらい影響を与えていないため。クライアントは、自身のIMAPストアにメッセージを作成することができますので、また、コマンドは、二度のメッセージをアップロードすることなく、送信されたメッセージのコピーをアーカイブするクライアントの願望に対処しています。 （メッセージを送信するためのメカニズムは、この文書の範囲外です。）
The extended APPEND command can also be used to copy parts of a message to another mailbox for archival purposes while getting rid of undesired parts. In environments where server storage is limited, a client could get rid of large message parts by copying over only the necessary parts and then deleting the original message. The mechanism could also be used to add data to a message (such as prepending message header fields) or to include other data by making a copy of the original and catenating the new data.
拡張APPENDコマンドも望ましくない部分を取り除くことながら、アーカイブの目的のために別のメールボックスにメッセージの一部をコピーするために使用することができます。サーバ・ストレージが限られている環境では、クライアントは、必要な部分だけの上にコピーし、元のメッセージを削除することによって、大きなメッセージ部分を取り除くことができます。機構はまた、（例えば、メッセージヘッダフィールドを付加など）メッセージにデータを追加したり、オリジナルのコピーを作成し、新しいデータをcatenatingにより他のデータを含めるために使用することができます。
A server that supports this extension returns "CATENATE" as one of the responses to the CAPABILITY command.
この拡張をサポートするサーバは、CAPABILITYコマンドに対する応答の一つとして「CATENATE」を返します。
Arguments: mailbox name (The following can be repeated in the presence of the MULTIAPPEND extension [3]) OPTIONAL flag parenthesized list OPTIONAL date/time string a single message literal or one or more message parts to catenate, specified as: message literal or message (or message part) URL
引数：メッセージリテラルまたはメッセージ：メールボックス名として指定されたリテラルまたはCATENATEに1つまたは複数のメッセージ部分、OPTIONALフラグ括弧リスト任意の日付/時刻文字列単一のメッセージ（以下をMULTIAPPEND拡張[3]の存在下で繰り返すことができます） （またはメッセージの一部）URL
Responses: OPTIONAL NO responses: BADURL, TOOBIG
回答：オプションのNO応答：BADURL、がtooBig
Result: OK - append completed NO - append error: can't append to that mailbox, error in flags or date/time or message text, or can't fetch that data BAD - command unknown or arguments invalid
結果：OK - 完了NOを追加 - エラーを追加：フラグや日付/時間またはメッセージテキスト内のエラー、そのメールボックスに追加することができない、またはそのデータBADを取得することはできません - 無効不明または引数コマンド
The APPEND command concatenates all the message parts and appends them as a new message to the end of the specified mailbox. The parenthesized flag list and date/time string set the flags and the internal date, respectively, as described in IMAP [1]. The subsequent command parameters specify the message parts that are appended sequentially to the output message.
APPENDコマンドは、すべてのメッセージ部分を連結し、指定されたメールボックスの最後に新しいメッセージとして、それらを追加します。括弧フラグリストと日付/時刻文字列はIMAPに記載されているように、それぞれのフラグと内部日付を設定する[1]。後続のコマンドパラメータは、出力メッセージに順次追加されるメッセージ部分を指定します。
If the original form of APPEND is used, a message literal follows the optional flag list and date/time string, which is appended as described in IMAP [1]. If the extended form is used, "CATENATE" and a parenthesized list of message literals and message URLs follows, each of which is appended to the new message. If a message literal is specified (indicated by "TEXT"), the octets following the count are appended. If a message URL is specified (indicated by "URL"), the octets of the body part pointed to by that URL are appended, as if the literal returned in a FETCH BODY response were put in place of the message part specifier. The APPEND command does not cause the \Seen flag to be set for any catenated body part. The APPEND command does not change the selected mailbox.
APPENDの元の形が使用される場合、リテラルメッセージはIMAPに記載されるように添付されているオプションのフラグリストと日付/時刻文字列を、次の[1]。拡張形式が使用される場合、「CATENATE」とメッセージリテラルとメッセージURLの括弧内のリストは、新しいメッセージに付加されそれぞれが、以下。リテラルメッセージ（「TEXT」で示す）が指定された場合、カウントは次のオクテットは、添付されています。メッセージのURLが（「URL」によって示される）に指定されている場合はメッセージ部分を指定の場所に置かれたFETCH BODY応答で返されたリテラルかのように、身体の一部のオクテットは、そのURLが付加されていると指摘しました。 APPENDコマンドは、\見フラグは任意の鎖状に連結身体の一部に設定されることはありません。 APPENDコマンドは、選択したメールボックスは変更されません。
In the extended APPEND command, the string following "URL" is an IMAP URL [2] and is interpreted according to the rules of [2]. The present document only describes the behavior of the command using IMAP URLs that refer to specific messages or message parts on the current IMAP server from the current authenticated IMAP session. Because of that, only relative IMAP message or message part URLs (i.e., those having no scheme or <iserver>) are used. The base URL for evaluating the relative URL is considered "imap://user@server/", where "user" is the user name of the currently authenticated user and "server" is the domain name of the current server. When in the selected state, the base URL is considered "imap://user@server/mailbox", where "mailbox" is the encoded name of the currently selected mailbox. Additionally, since the APPEND command is valid in the authenticated state of an IMAP session, no further LOGIN or AUTHENTICATE command is performed for URLs specified in the extended APPEND command.
拡張APPENDコマンドで、「URL」に続く文字列は、IMAP URL [2]及び[2]の規則に従って解釈されます。本文書は、現在の認証されたIMAPセッションから現在のIMAPサーバー上の特定のメッセージまたはメッセージ部分を指すコマンドを使用して、IMAP URLの挙動を記述する。そのため、唯一の相対IMAPメッセージまたはメッセージ部分のURL（すなわち、いかなる方式や<iserver>有さないもの）が使用されます。相対URLを評価するためのベースURLは、「IMAP：//ユーザー@サーバ/」とみなされ、「ユーザー」は、ユーザの現在の認証済みユーザーの名前と「サーバ」であるところ、現在のサーバのドメイン名です。選択された状態で、ベースURLは、「IMAP：//ユーザー@サーバ/メールボックス」と見なされた場合、ここで「メールボックスは、」現在選択されているメールボックスのエンコードされた名前です。また、APPENDコマンドので、さらなるLOGIN IMAPセッションの認証された状態で有効でないか、またはコマンドを認証拡張APPENDコマンドで指定されたURLに対して実行されます。
Note: Use of an absolute IMAP URL or any URL that refers to anything other than a message or message part from the current authenticated IMAP session is outside the scope of this document and would require an extension to this specification, and a server implementing only this specification would return NO to such a request.
注：現在の認証されたIMAPセッションからのメッセージまたはメッセージの一部以外を指す絶対IMAPのURLまたはURLの使用は、この文書の範囲外であり、この仕様の拡張を必要とし、サーバはこれだけを実装仕様では、このような要求にNOを返していないでしょう。
The client is responsible for making sure that the catenated message is in the format of an Internet Message Format (RFC 2822) [4] or Multipurpose Internet Mail Extension (MIME) [5] message. In particular, when a URL is catenated, the server copies octets, unchanged, from the indicated message or message part to the catenated message. It does no data conversion (e.g., MIME transfer encodings) nor any verification that the data is appropriate for the MIME part of the message into which it is inserted. The client is also responsible for inserting appropriate MIME boundaries between body parts, and writing MIME Content-Type and Content-Transfer-Encoding lines as needed in the appropriate places.
クライアントは、[4]または多目的インターネットメール拡張（MIME）[5]メッセージ連鎖したメッセージは、インターネットメッセージ形式（RFC 2822）の形式であることを確認する責任があります。具体的には、URLが鎖状に連結されたときに、連鎖したメッセージに示されたメッセージまたはメッセージ部分からそのままサーバにコピーオクテット、、。それはデータ変換（例えば、MIME転送エンコーディング）やデータは、それが挿入されたメッセージのMIMEパートに適していることを任意の検証を行いません。また、クライアントは、身体の部分の間の適切なMIME境界を挿入し、適切な場所に、必要に応じてMIMEのContent-TypeとContent-転送エンコーディングの行を記述するための責任があります。
Responses behave just as the original APPEND command described in IMAP [1]. If the server implements the IMAP UIDPLUS extension [6], it will also return an APPENDUID response code in the tagged OK response. Two response codes are provided in Section 4 that can be used in the tagged NO response if the APPEND command fails.
応答は、元のAPPENDコマンドは、IMAP [1]に記載と同様に振る舞います。サーバはIMAP UIDPLUS拡張を実装している場合、[6]、それはまた、タグ付けされたOK応答APPENDUIDレスポンスコードを返します。 2つの応答コードは、APPENDコマンドが失敗した場合にタグ付けされたNO応答して使用することができる第4に設けられています。
When a APPEND command fails, it may return a response code that describes a reason for the failure.
APPENDコマンドが失敗した場合、それは失敗の理由を説明し、応答コードを返すことがあります。
The BADURL response code is returned if the APPEND fails to process one of the specified URLs. Possible reasons for this are bad URL syntax, unrecognized URL schema, invalid message UID, or invalid body part. The BADURL response code contains the first URL specified as a parameter to the APPEND command that has caused the operation to fail.
APPENDが指定されたURLのいずれかの処理に失敗した場合BADURLレスポンスコードが返されます。このため考えられる理由は、不正なURL構文、認識されないURLスキーマ、無効なメッセージのUID、または無効な身体の一部です。 BADURL応答コードは、操作が失敗する原因となったAPPENDコマンドのパラメータとして指定された最初のURLが含まれています。
The TOOBIG response code is returned if the resulting message will exceed the 4-GB IMAP message limit. This might happen, for example, if the client specifies 3 URLs for 2-GB messages. Note that even if the server doesn't return TOOBIG, it still has to be defensive against misbehaving or malicious clients that try to construct a message over the 4-GB limit. The server may also wish to return the TOOBIG response code if the resulting message exceeds a server-specific message size limit.
得られたメッセージは、4 GB IMAPメッセージの制限を超えてしまう場合がtooBig応答コードが返されます。クライアントが2 GBメッセージの3つのURLを指定する場合、これは、例えば、起こるかもしれません。サーバががtooBigを返さない場合でも、それはまだ誤動作または4 GBの制限を超えてメッセージを構築しようとする悪質なクライアントに対して守勢なければならないことに注意してください。サーバはまた、結果のメッセージは、サーバ固有のメッセージサイズ制限を超える場合がtooBigのレスポンスコードを返すことを望むかもしれません。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) [7] notation. Elements not defined here can be found in the formal syntax of the ABNF [7], IMAP [1], and IMAP ABNF extensions [8] specifications. Note that capability and resp-text-code are extended from the IMAP [1] specification and append-data is extended from the IMAP ABNF extensions [8] specification.
次の構文仕様は、拡張バッカス・ナウアフォーム（ABNF）[7]の表記を使用します。ここで定義されていない要素はABNFの正式な構文で見つけることができる[7]、IMAP [1]、およびIMAP ABNF拡張[8]仕様。その機能とRESPテキストコードをIMAPから延長されることに注意してください[1]仕様と、データを追加する[8]仕様IMAP ABNF拡張から延長されます。
append-data =/ "CATENATE" SP "(" cat-part *(SP cat-part) ")"
追加データ= / "CATENATE" SP "（" 猫パート*（SP猫パート） "）"
cat-part = text-literal / url
猫のパート=テキストリテラル/ URL
text-literal = "TEXT" SP literal
テキスト・リテラル= "TEXT" SPリテラル
url = "URL" SP astring
URL = "URL" のSPのAString
resp-text-code =/ toobig-response-code / badurl-response-code
RESPテキストコード= /がtooBig応答コード/ BADURL応答コード
toobig-response-code = "TOOBIG"
がtooBig・レスポンス・コード=「がtooBig」
badurl-response-code = "BADURL" SP url-resp-text
BADURL応答コード= "BADURL" SPのurl-RESP-テキスト
url-resp-text = 1*(%x01-09 / %x0B-0C / %x0E-5B / %x5D-FE) ; Any TEXT-CHAR except "]"
URL-RESPテキスト= 1 *（％x01-09 /％X0B-0C /％x0E-5B /％x5D-FE）。任意のテキスト-CHAR「]」を除きます
capability =/ "CATENATE"
機能= /「連鎖セクション」
The astring in the definition of url and the url-resp-text in the definition of badurl-response-code each contain an imapurl as defined by [2].
[2]で定義されるように、URLの定義でのAStringとBADURL応答コードの定義それぞれでurl-RESPテキストはimapurlを含みます。
Thanks to the members of the LEMONADE working group for their input. Special thanks to Alexey Melnikov for the examples.
彼らの入力のためのレモネードワーキンググループのメンバーに感謝します。例については、アレクセイ・メルニコフに感謝します。
The CATENATE extension does not raise any security considerations that are not present for the base protocol or in the use of IMAP URLs, and these issues are discussed in the IMAP [1] and IMAP URL [2] documents.
CATENATE拡張は、[2]の文書を基本プロトコルまたはIMAP URLの使用には存在しない任意のセキュリティ上の考慮事項は発生しません、これらの問題は、IMAPで議論されている[1]およびIMAP URL。
IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located at <http://www.iana.org/assignments/imap4-capabilities>. This document defines the CATENATE IMAP capability. The IANA has added this capability to the registry.
IMAP4機能は標準化過程を公開することによって登録されているかIESGは実験的なRFCを承認しました。レジストリは、現在、<http://www.iana.org/assignments/imap4-capabilities>に位置しています。この文書では、CATENATEのIMAP機能を定義します。 IANAは、レジストリにこの機能を追加しました。
Appendix A. Examples
付録A.例
Lines not starting with "C: " or "S: " are continuations of the previous lines.
始まらない行「C：」または「Sは、」前の行の継続です。
The original message in examples 1 and 2 below (UID = 20) has the following structure:
以下の実施例1及び2におけるオリジナルのメッセージ（UID = 20）以下の構造を有します。
multipart/mixed MIME message with two body parts:
2つの本体部分と混合/マルチパートMIMEメッセージ：
Example 1: The following example demonstrates how a CATENATE client can replace an attachment in a draft message, without the need to download it to the client and upload it back.
例1：次の例では、CATENATEクライアントは、クライアントにダウンロードし、それをバックにアップロードすることなく、ドラフトメッセージに添付ファイルを置き換えることができます方法を示しています。
C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
(URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=HEADER"
TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050907
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1.MIME"
URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1" TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050907
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=30" TEXT {44}
S: + Ready for literal data
C:
C: --------------030308070208000400050907--
C: )
S: A003 OK catenate append completed
Example 2: The following example demonstrates how the CATENATE extension can be used to replace edited text in a draft message, as well as header fields for the top level message part (e.g., Subject has changed). The previous version of the draft is marked as \Deleted. Note that the server also supports the UIDPLUS extension, so the APPENDUID response code is returned in the successful OK response to the APPEND command.
例2：次の例は、CATENATE拡張がトップレベルのメッセージ部分のために編集されたドラフト・メッセージのテキスト、ならびにヘッダフィールドを置き換えるために使用することができる方法を示し（例えば、対象が変更されています）。ドラフトの以前のバージョンでは、\削除済みとしてマークされています。サーバもUIDPLUS拡張をサポートしているため、APPENDUID応答コードがAPPENDコマンドに成功したOK応答で返されることに注意してください。
C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE (TEXT {738}
S: + Ready for literal data
C: Return-Path: <bar@example.org>
C: Received: from [127.0.0.2]
C: by rufus.example.org via TCP (internal) with ESMTPA;
C: Thu, 11 Nov 2004 16:57:07 +0000
C: Message-ID: <419399E1.6000505@example.org>
C: Date: Thu, 12 Nov 2004 16:57:05 +0000
C: From: Bob Ar <bar@example.org>
C: X-Accept-Language: en-us, en
C: MIME-Version: 1.0
C: To: foo@example.net
C: Subject: About our holiday trip
C: Content-Type: multipart/mixed;
C: boundary="------------030308070208000400050907"
C:
C: --------------030308070208000400050907
C: Content-Type: text/plain; charset=us-ascii; format=flowed
C: Content-Transfer-Encoding: 7bit
C:
C: Our travel agent has sent the updated schedule.
C:
C: Cheers,
C: Bob
C: --------------030308070208000400050907
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2.MIME"
URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2" TEXT {44}
S: + Ready for literal data
C:
C: --------------030308070208000400050907--
C: )
S: A003 OK [APPENDUID 385759045 45] append Completed
C: A004 UID STORE 20 +FLAGS.SILENT (\Deleted)
S: A004 OK STORE completed
Example 3: The following example demonstrates how the CATENATE extension can be used to strip attachments. Below, a PowerPoint attachment was replaced by a small text part explaining that the attachment was stripped.
例3：次の例では、CATENATE拡張子が添付ファイルを除去するために使用する方法を示しています。以下は、PowerPointの添付ファイルが添付ファイルが除去されたことを説明する小さなテキスト部分に置き換えられました。
C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
(URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=HEADER"
TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050903
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1.MIME"
URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1" TEXT {255}
S: + Ready for literal data
C:
C: --------------030308070208000400050903
C: Content-type: text/plain; charset="us-ascii"
C: Content-transfer-encoding: 7bit
C:
C: This body part contained a Power Point presentation that was
C: deleted upon your request.
C: --------------030308070208000400050903--
C: )
S: A003 OK append Completed
Example 4: The following example demonstrates a failed APPEND command. The server returns the BADURL response code to indicate that one of the provided URLs is invalid. This example also demonstrates how the CATENATE extension can be used to construct a digest of several messages.
例4：次の例では、失敗したAPPENDコマンドを示しています。サーバが提供するURLのいずれかが無効であることを示すためにBADURLレスポンスコードを返します。また、この例では、CATENATE拡張子はいくつかのメッセージのダイジェストを構築するために使用することができる方法を示しています。
C: A003 APPEND Sent (\Seen $MDNSent) CATENATE (TEXT {541}
S: + Ready for literal data
C: Return-Path: <foo@example.org>
C: Received: from [127.0.0.2]
C: by rufus.example.org via TCP (internal) with ESMTPA;
C: Thu, 11 Nov 2004 16:57:07 +0000
C: Message-ID: <419399E1.6000505@example.org>
C: Date: Thu, 21 Nov 2004 16:57:05 +0000
C: From: Farren Oo <foo@example.org>
C: X-Accept-Language: en-us, en
C: MIME-Version: 1.0
C: To: bar@example.org
C: Subject: Digest of the mailing list for today
C: Content-Type: multipart/digest;
C: boundary="------------030308070208000400050904"
C:
C: --------------030308070208000400050904
C: URL "/INBOX;UIDVALIDITY=785799047/;UID=11467" TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050904
C: URL "/INBOX;UIDVALIDITY=785799047/;UID=113330/;section=1.5.9"
TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050904
C: URL "/INBOX;UIDVALIDITY=785799047/;UID=11916" TEXT {44}
S: + Ready for literal data
C:
C: --------------030308070208000400050904--
C: )
S: A003 NO [BADURL "/INBOX;UIDVALIDITY=785799047/;UID=113330;
section=1.5.9"] CATENATE append has failed, one message expunged
Note that the server could have validated the URLs as they were received and therefore could have returned the tagged NO response with BADURL response-code in place of any continuation request after the URL was received.
サーバは、彼らが受け取ったとしてURLを検証している可能性があり、URLを受信した後ので、任意の継続要求の代わりにBADURLの応答コードでタグ付きNO応答を返さなかったかもしれないことに注意してください。
[1] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[1]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[2] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
[2]ニューマン、C.、 "IMAP URLスキーム"、RFC 2192、1997年9月。
[3] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, March 2003.
[3]クリスピン、M.、 "インターネットメッセージアクセスプロトコル（IMAP） - MULTIAPPEND拡張"、RFC 3502、2003年3月。
[4] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[4]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[5]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[6] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005.
[6]のCrispin、M.、 "インターネットメッセージアクセスプロトコル（IMAP） - UIDPLUS拡張"、RFC 4315、2005年12月。
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[7]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[8] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[8]メルニコフ、A.およびC. Dabooを、 "IMAP4 ABNFに収集された拡張機能"、RFC 4466、2006年4月。
Author's Address
著者のアドレス
Peter W. Resnick QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-1714 US
ピーター・W.レズニックQUALCOMM Incorporatedの5775モアハウスドライブサンディエゴ、CA 92121から1714米
Phone: +1 858 651 4478 EMail: presnick@qualcomm.com URI: http://www.qualcomm.com/~presnick/
電話：+1 858 651 4478 Eメール：presnick@qualcomm.com URI：http://www.qualcomm.com/~presnick/
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）によって提供されます。