[要約] RFC 3502は、IMAPプロトコルの拡張であるMULTIAPPENDについて説明しています。MULTIAPPENDは、複数のメッセージを一度にサーバーに追加するための機能です。この拡張の目的は、効率的なメッセージの追加と処理を可能にすることです。
Network Working Group M. Crispin
Request for Comments: 3502 University of Washington
Category: Standards Track March 2003
Internet Message Access Protocol (IMAP) - MULTIAPPEND 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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes the multiappending extension to the Internet Message Access Protocol (IMAP) (RFC 3501). This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server.
このドキュメントでは、インターネットメッセージアクセスプロトコル（IMAP）（RFC 3501）へのマルチアペンディングエクステンションについて説明します。この拡張機能は、サーバー上のメールボックスに一度に複数のメッセージをアップロードするIMAPクライアントに大幅なパフォーマンス改善を提供します。
A server which supports this extension indicates this with a capability name of "MULTIAPPEND".
この拡張機能をサポートするサーバーは、「MultiaPend」の機能名でこれを示します。
Terminology
用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
「必須」、「そうしない」、「必須」、「「shall」、「shall」、「suff」、「 "not" "not"、 "may"、および「optional」は、このドキュメントの「オプション」は、[キーワード]で説明されています。
Introduction
はじめに
The MULTIAPPEND extension permits uploading of multiple messages with a single command. When used in conjunction with the [LITERAL+] extension, the entire upload is accomplished in a single command/response round trip.
MultiaPend拡張により、単一のコマンドを使用した複数のメッセージのアップロードが可能になります。[リテラル]拡張機能と組み合わせて使用すると、アップロード全体が単一のコマンド/応答ラウンドトリップで達成されます。
A MULTIAPPEND APPEND operation is atomic; either all messages are successfully appended, or no messages are appended.
マルチアドペンド付録操作はAtomicです。すべてのメッセージが正常に追加されるか、メッセージが追加されません。
In the base IMAP specification, each message must be appended in a separate command, and there is no mechanism to "unappend" messages if an error occurs while appending. Also, some mail stores may require an expensive "open/lock + sync/unlock/close" operation as part of appending; this can be quite expensive if it must be done on a per-message basis.
ベースIMAP仕様では、各メッセージを別のコマンドに追加する必要があり、アプリがあるときにエラーが発生した場合、メッセージを「非表示」するメカニズムはありません。また、一部のメールストアでは、Appendingの一部として高価な「オープン/ロック同期/ロック解除/閉じる」操作が必要になる場合があります。これは、1人あたりのベースで行う必要がある場合、非常に高価です。
If the server supports both LITERAL+ and pipelining but not MULTIAPPEND, it may be possible to get some of the performance advantages of MULTIAPPEND by doing a pipelined "batch" append. However, it will not work as well as MULTIAPPEND for the following reasons:
サーバーがリテラルとパイプライニングの両方をサポートしているが、マルチアペンドではない場合、パイプラインの「バッチ」付録を実行することにより、マルチペップのパフォーマンスの利点の一部を取得することが可能かもしれません。ただし、以下の理由により、マルチアペンドほど機能しません。
1) Multiple APPEND commands, even as part of a pipelined batch, are non-atomic by definition. There is no way to revert the mailbox to the state before the batch append in the event of an error.
1) 複数の追加コマンドは、パイプラインされたバッチの一部としてであっても、定義上、原子的ではありません。エラーが発生した場合にバッチが追加される前に、メールボックスを状態に戻す方法はありません。
2) It may not be feasible for the server to coalesce pipelined APPEND operations so as to avoid the "open/lock + sync/unlock/close" overhead described above. In any case, such coalescing would be timing dependent and thus potentially unreliable. In particular, with traditional UNIX mailbox files, it is assumed that a lock is held only for a single atomic operation, and many applications disregard any lock that is older than 5 minutes.
2) 上記の「Open/Lock Sync/ロック解除/ロック解除/閉じる」オーバーヘッドを避けるために、サーバーがパイプライン化された操作を合体することは不可能かもしれません。いずれにせよ、そのような合体はタイミングに依存し、したがって潜在的に信頼できないでしょう。特に、従来のUNIXメールボックスファイルを使用すると、ロックは単一の原子動作のためだけに保持されていると想定されており、多くのアプリケーションは5分以内のロックを無視しています。
3) If an error occurs, depending upon the nature of the error, it is possible for additional messages to be appended after the error. For example, the user wants to append 5 messages, but a disk quota error occurs with the third message because of its size. However, the fourth and fifth messages have already been sent in the pipeline, so the mailbox ends up with the first, second, fourth, and fifth messages of the batch appended.
3) エラーが発生した場合、エラーの性質に応じて、エラー後に追加のメッセージを追加する可能性があります。たとえば、ユーザーは5つのメッセージを追加したいと考えていますが、サイズのために3番目のメッセージでディスククォータエラーが発生します。ただし、4番目と5番目のメッセージはすでにパイプラインで送信されているため、メールボックスは、バッチの1番目、2番目、4番目、および5番目のメッセージになります。
Arguments: mailbox name one or more messages to upload, specified as: OPTIONAL flag parenthesized list OPTIONAL date/time string message literal
引数：メールボックス名アップロードする1つ以上のメッセージ、指定：オプションのフラグの括弧リストオプション日付/時刻文字列メッセージリテラル
Data: no specific responses for this command
データ：このコマンドの特定の応答はありません
Result: OK - append completed NO - append error: can't append to that mailbox, error in flags or date/time or message text, append cancelled BAD - command unknown or arguments invalid
結果：OK-追加完了しないNO-追加エラー：そのメールボックスに追加できない、フラグまたは日付/時刻またはメッセージテキストのエラー、キャンセルされた悪いキャンセル - コマンド不明または引数無効
The APPEND command appends the literal arguments as new messages to the end of the specified destination mailbox. This argument SHOULD be in the format of an [RFC-2822] message. 8-bit characters are permitted in the message. A server implementation that is unable to preserve 8-bit data properly MUST be able to reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content transfer encoding.
追加コマンドは、指定された宛先メールボックスの最後まで新しいメッセージとしてリテラル引数を追加します。この引数は、[RFC-2822]メッセージの形式である必要があります。8ビット文字はメッセージで許可されています。8ビットデータを適切に保存できないサーバーの実装は、[MIME-IMB]コンテンツ転送エンコードを使用して、8ビットの追加データを7ビットに可逆的に変換できる必要があります。
Note: There MAY be exceptions, e.g., draft messages, in which required [RFC-2822] header lines are omitted in the message literal argument to APPEND. The full implications of doing so MUST be understood and carefully weighed.
注：例外がある場合があります。たとえば、[RFC-2822]ヘッダー線が必要な[RFC-2822]メッセージは、メッセージのリテラル引数で省略されています。そうすることの完全な意味は、理解し、慎重に計量する必要があります。
If a flag parenthesized list is specified, the flags SHOULD be set in the resulting message; otherwise, the flag list of the resulting message is set empty by default.
フラグの括弧付きリストが指定されている場合、結果のメッセージにフラグを設定する必要があります。それ以外の場合、結果のメッセージのフラグリストはデフォルトで空に設定されます。
If a date-time is specified, the internal date SHOULD be set in the resulting message; otherwise, the internal date of the resulting message is set to the current date and time by default.
日付時間が指定されている場合、結果のメッセージに内部日付を設定する必要があります。それ以外の場合、結果のメッセージの内部日付は、デフォルトで現在の日付と時刻に設定されます。
A zero-length message literal argument is an error, and MUST return a NO. This can be used to cancel the append.
ゼロ長のメッセージ文字通りの引数はエラーであり、NOを返す必要があります。これを使用して、付録をキャンセルできます。
If the append is unsuccessful for any reason (including being cancelled), the mailbox MUST be restored to its state before the APPEND attempt; no partial appending is permitted. The server MAY return an error before processing all the message arguments.
何らかの理由（キャンセルを含む）の場合、付録が失敗した場合、追加の試行前にメールボックスをその状態に復元する必要があります。部分的な追加は許可されていません。すべてのメッセージ引数を処理する前に、サーバーはエラーを返す場合があります。
If the destination mailbox does not exist, a server MUST return an error, and MUST NOT automatically create the mailbox. Unless it is certain that the destination mailbox can not be created, the server MUST send the response code "[TRYCREATE]" as the prefix of the text of the tagged NO response. This gives a hint to the client that it can attempt a CREATE command and retry the APPEND if the CREATE is successful.
宛先メールボックスが存在しない場合、サーバーはエラーを返す必要があり、メールボックスを自動的に作成してはなりません。宛先メールボックスを作成できないことが確実でない限り、サーバーは、タグ付きNO応答のテキストのプレフィックスとして応答コード「[tryCreate]」を送信する必要があります。これにより、CREATEコマンドを試み、Createが成功した場合に追加を再試行できるというクライアントにヒントが与えられます。
If the mailbox is currently selected, the normal new message actions SHOULD occur. Specifically, the server SHOULD notify the client immediately via an untagged EXISTS response. If the server does not do so, the client MAY issue a NOOP command (or failing that, a CHECK command) after one or more APPEND commands.
メールボックスが現在選択されている場合、通常の新しいメッセージアクションが発生するはずです。具体的には、サーバーは、攻撃されていない存在する応答を介してすぐにクライアントに通知する必要があります。サーバーがそうしない場合、クライアントは1つ以上のコマンドを追加した後にNOOPコマンドを発行する（またはそれをチェックコマンドに失敗させる）ことができます。
Example: C: A003 APPEND saved-messages (\Seen) {329}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.example.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.example.net
C: Message-Id: <B27397-0100000@Blurdybloop.example.COM>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C: (\Seen) " 7-Feb-1994 22:43:04 -0800" {295}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST)
C: From: Joe Mooch <mooch@OWaTaGu.example.net>
C: Subject: Re: afternoon meeting
C: To: foobar@blurdybloop.example.com
C: Message-Id: <a0434793874930@OWaTaGu.example.net>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: 3:30 is fine with me.
C:
S: A003 OK APPEND completed
C: A004 APPEND bogusname (\Flagged) {1023}
S: A004 NO [TRYCREATE] No such mailbox as bogusname
C: A005 APPEND test (\Flagged) {99}
S: + Ready for literal data
C: Date: Mon, 7 Feb 2000 22:43:04 -0800 (PST)
C: From: Fred Foobar <fred@example.com>
C: Subject: hmm...
C: {35403}
S: A005 NO APPEND failed: Disk quota exceeded
Note: The APPEND command is not used for message delivery, because it does not provide a mechanism to transfer [SMTP] envelope information.
注：[smtp]エンベロープ情報を転送するメカニズムを提供しないため、メッセージ配信には追加コマンドは使用されません。
Modification to IMAP4rev1 Base Protocol Formal Syntax
IMAP4REV1ベースプロトコル形式的構文への変更
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
次の構文仕様では、[ABNF]で指定されているように、拡張されたBackus-Naurフォーム（ABNF）表記を使用します。
append = "APPEND" SP mailbox 1*append-message
append = "append" spメールボックス1*append-message
append-message = [SP flag-list] [SP date-time] SP literal
MULTIAPPEND Interaction with UIDPLUS Extension
UIDPLUS拡張とのマルチアドペンド相互作用
Servers which support both MULTIAPPEND and [UIDPLUS] will have the "resp-code-apnd" rule modified as follows:
MultiaPendと[uidplus]の両方をサポートするサーバーには、次のように「RESP-CODE-APND」ルールが変更されます。
resp-code-apnd = "APPENDUID" SP nz-number SP set
resp-code-apnd = "appenduid" sp nz-number spセット
That is, the APPENDUID response code returns as many UIDs as there were messages appended in the multiple append. The UIDs returned should be in the order the articles where appended. The message set may not contain extraneous UIDs or the symbol "*".
つまり、appenduid応答コードは、複数の付録に追加されたメッセージがあるのと同じくらい多くのUIDを返します。返されたuidsは、追加された記事を順番に並べている必要があります。メッセージセットには、外部のUIDまたはシンボル「*」が含まれない場合があります。
Security Considerations
セキュリティに関する考慮事項
The MULTIAPPEND extension does not raise any security considerations that are not present in the base [IMAP] protocol, and these issues are discussed in [IMAP]. Nevertheless, it is important to remember that IMAP4rev1 protocol transactions, including electronic mail data, are sent in the clear over the network unless protection from snooping is negotiated, either by the use of STARTTLS, privacy protection is negotiated in the AUTHENTICATE command, or some other protection mechanism is in effect.
MultiaPend Extensionは、ベース[IMAP]プロトコルに存在しないセキュリティ上の考慮事項を提起するものではなく、これらの問題は[IMAP]で議論されています。それにもかかわらず、STARTTLSの使用によってスヌーピングからの保護が交渉されない限り、電子メールデータを含むIMAP4REV1プロトコルトランザクションがネットワーク上でクリアされていることを覚えておくことが重要です。他の保護メカニズムが有効です。
Normative References
引用文献
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[IMAP] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.
[IMAP] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[MIME-IMB] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[Mime-Imb] Freed、N。and N. Borenstein、「Mime（多目的インターネットメール拡張）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC-2822] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
Informative References
参考引用
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997.
[リテラル]マイヤーズ、J。、「IMAP4非同期リテラル」、RFC 2088、1997年1月。
[UIDPLUS] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 1988.
[uidplus] myers、J。、 "imap4 uidplus extension"、RFC 2359、1988年6月。
[SMTP] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP] Klensin、J.、編集者、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
Author's Address
著者の連絡先
Mark R. Crispin Networks and Distributed Computing University of Washington 4545 15th Avenue NE Seattle, WA 98105-4527
マークR.クリスピンネットワークと分散コンピューティングワシントン大学4545 15th Avenue NEシアトル、ワシントン州98105-4527
Phone: (206) 543-5762 EMail: MRC@CAC.Washington.EDU
電話：（206）543-5762メール：mrc@cac.washington.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。