[要約] RFC 2359はIMAP4 UIDPLUS拡張の仕様を定義しており、メールサーバーとクライアント間で一意のメッセージ識別子（UID）を使用することを可能にします。この拡張の目的は、メッセージの一意性と効率的なメッセージ操作を提供することです。
Network Working Group J. Myers
Request for Comments: 2359 Netscape Communications
Category: Standards Track June 1998
IMAP4 UIDPLUS extension
IMAP4 UIDPLUS拡張
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 (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
IESG NOTE
IESGノート
The IMAP extension described here assumes a particular means of using IMAP to support disconnected operation. However, this means of supporting disconnected operation is not yet documented. Also, there are multiple theories about how best to do disconnected operation in IMAP, and as yet, there is no consensus on which one should be adopted as a standard.
ここで説明するIMAP拡張機能は、切断された操作をサポートするためにIMAPを使用する特定の手段を想定しています。ただし、切断操作をサポートするこの方法はまだ文書化されていません。また、IMAPでの切断操作の最良の方法については複数の理論があり、現在のところ、どれを標準として採用するべきかについてコンセンサスはありません。
This document is being approved as a Proposed Standard because it does not appear to have technical flaws in itelf. However, approval of this document as a Proposed Standard should not be considered an IETF endorsement of any particular means of doing disconnected operation in IMAP.
このドキュメントはitelfに技術的な欠陥がないように見えるため、提案された標準として承認されています。ただし、提案された標準としてのこのドキュメントの承認は、IMAPで切断された操作を行う特定の手段のIETF承認と見なされるべきではありません。
Table of Contents
目次
1. Abstract .............................................. 2
2. Conventions Used in this Document ..................... 2
3. Introduction and Overview ............................. 2
4. Features .............................................. 2
4.1. UID EXPUNGE Command ................................... 2
4.2. APPENDUID response code ............................... 3
4.3. COPYUID response code ................................. 4
5. Formal Syntax ......................................... 4
6. References ............................................ 4
7. Security Considerations ............................... 5
8. Author's Address ...................................... 5
9. Full Copyright Statement .............................. 6
The UIDPLUS extension of the Internet Message Access Protocol [IMAP4] provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients.
インターネットメッセージアクセスプロトコル[IMAP4]のUIDPLUS拡張機能は、一部のクライアント操作で使用される時間とリソースの量を削減することを目的とした一連の機能を提供します。 UIDPLUSの機能は、主に非接続型クライアントを対象としています。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
例では、「C：」と「S：」は、それぞれクライアントとサーバーによって送信された行を示します。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、および「MAY」は、「要件レベルを示すRFCで使用するキーワード」[キーワード]で定義されているように解釈されます。 。
The UIDPLUS extension is present in any IMAP4 server implementation which returns "UIDPLUS" as one of the supported capabilities to the CAPABILITY command. The UIDPLUS extension contains one additional command and additional data returned with successful APPEND and COPY commands.
UIDPLUS拡張機能は、CAPABILITYコマンドでサポートされている機能の1つとして「UIDPLUS」を返すすべてのIMAP4サーバー実装に存在します。 UIDPLUS拡張には、1つの追加コマンドと、正常なAPPENDおよびCOPYコマンドで返される追加データが含まれています。
Clients that wish to use the new command in UIDPLUS must of course first test for the presence of the extension by issuing a CAPABILITY command. Each of the features in UIDPLUS are optimizations; clients can provide the same functionality, albeit more slowly, by using commands in the base protocol. With each feature, this document recommends a fallback approach to take when the UIDPLUS extension is not supported by the server.
もちろん、UIDPLUSで新しいコマンドを使用するクライアントは、CAPABILITYコマンドを発行して、拡張機能の存在を最初にテストする必要があります。 UIDPLUSの各機能は最適化です。クライアントは、基本プロトコルでコマンドを使用することにより、速度は遅くなりますが、同じ機能を提供できます。このドキュメントでは、各機能について、UIDPLUS拡張機能がサーバーでサポートされていない場合に使用するフォールバックアプローチを推奨しています。
Arguments: message set
引数：メッセージセット
Data: untagged responses: EXPUNGE
データ：タグなしの応答：EXPUNGE
Result: OK - expunge completed NO - expunge failure (e.g. permission denied) BAD - command unknown or arguments invalid
結果：OK-消去が完了したNO-消去の失敗（許可が拒否されたなど）BAD-不明なコマンドまたは引数が無効
The UID EXPUNGE command permanently removes from the currently selected mailbox all messages that both have the \Deleted flag set and have a UID that is included in the specified message set. If a message either does not have the \Deleted flag set or is has a UID that is not included in the specified message set, it is not affected.
UID EXPUNGEコマンドは、現在選択されているメールボックスから、\ Deletedフラグが設定され、指定されたメッセージセットに含まれているUIDを持つメッセージをすべて完全に削除します。メッセージに\ Deletedフラグが設定されていないか、指定されたメッセージセットに含まれていないUIDが含まれているメッセージは影響を受けません。
This command may be used to ensure that a replayed EXPUNGE command does not remove any messages that have been marked as \Deleted between the time that the user requested the expunge operation and the time the server processes the command.
このコマンドを使用して、再生されたEXPUNGEコマンドが、ユーザーが抹消操作を要求してからサーバーがコマンドを処理するまでの間に\ Deletedとマークされたメッセージを削除しないようにすることができます。
If the server does not support the UIDPLUS capability, the client should fall back to using the STORE command to temporarily remove the \Deleted flag from messages it does not want to remove. The client could alternatively fall back to using the EXPUNGE command, risking the unintended removal of some messages.
サーバーがUIDPLUS機能をサポートしていない場合、クライアントは、STOREコマンドを使用して、削除したくないメッセージから\ Deletedフラグを一時的に削除する必要があります。あるいは、クライアントはEXPUNGEコマンドの使用にフォールバックする可能性があり、一部のメッセージが意図せず削除される危険性があります。
Example: C: A003 UID EXPUNGE 3000:3002
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: A003 OK UID EXPUNGE completed
Successful APPEND commands return an APPENDUID response code in the tagged OK response. The APPENDUID response code contains as arguments the UIDVALIDITY of the destination mailbox and the UID assigned to the appended message.
APPENDコマンドが成功すると、タグ付きOK応答でAPPENDUID応答コードが返されます。 APPENDUID応答コードには、宛先メールボックスのUIDVALIDITYおよび追加されたメッセージに割り当てられたUIDが引数として含まれています。
If the server does not support the UIDPLUS capability, the client can only discover this information by selecting the destination mailbox and issuing FETCH commands.
サーバーがUIDPLUS機能をサポートしていない場合、クライアントは、宛先メールボックスを選択してFETCHコマンドを発行することによってのみこの情報を検出できます。
Example: C: A003 APPEND saved-messages (\Seen) {310}
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id: <B27397-0100000@Blurdybloop.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:
S: A003 OK [APPENDUID 38505 3955] APPEND completed
Successful COPY and UID COPY commands return a COPYUID response code in the tagged OK response whenever at least one message was copied. The COPYUID response code contains as an argument the UIDVALIDITY of the appended-to mailbox, a message set containing the UIDs of the messages copied to the destination mailbox, in the order they were copied, and a message containing the UIDs assigned to the copied messages, in the order they were assigned. Neither of the message sets may contain extraneous UIDs or the symbol '*'.
COPYコマンドとUID COPYコマンドが成功すると、少なくとも1つのメッセージがコピーされると、タグ付きOK応答でCOPYUID応答コードが返されます。 COPYUID応答コードには、追加先メールボックスのUIDVALIDITY、宛先メールボックスにコピーされたメッセージのUIDを含むメッセージセット、およびコピーされた順序でのメッセージ、およびコピーされたメッセージに割り当てられたUIDを含むメッセージが引数として含まれます、割り当てられた順序で。どちらのメッセージセットにも無関係なUIDや記号「*」を含めることはできません。
If the server does not support the UIDPLUS capability, the client can only discover this information by selecting the destination mailbox and issuing FETCH commands.
サーバーがUIDPLUS機能をサポートしていない場合、クライアントは、宛先メールボックスを選択してFETCHコマンドを発行することによってのみこの情報を検出できます。
Example: C: A003 COPY 2:4 MEETING
S: A003 OK [COPYUID 38505 304,319:320 3956:3958] Done
C: A003 UID COPY 305:310 MEETING
S: A003 OK Done
The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. Non-terminals referenced but not defined below are as defined by [IMAP4].
次の構文仕様は、[IMAP4]によって変更された[RFC-822]で指定されている拡張バッカスナウア記法（BNF）表記を使用します。参照されているが以下で定義されていない非端末は、[IMAP4]で定義されているとおりです。
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.
特に明記しない限り、すべてのアルファベット文字は大文字と小文字を区別しません。トークン文字列を定義するための大文字または小文字の使用は、編集上の明確さのためだけです。実装は、大文字と小文字を区別しない方法でこれらの文字列を受け入れる必要があります。
resp_code_apnd ::= "APPENDUID" SPACE nz_number SPACE uniqueid
resp_code_copy ::= "COPYUID" SPACE nz_number SPACE set SPACE set
uid_expunge ::= "UID" SPACE "EXPUNGE" SPACE set
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[IMAP4] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 2060、1996年12月。
[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月。
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC-822] Crocker、D。、「Standard for the Format for ARPA Internet Text Messages」、STD 11、RFC 822、1982年8月。
There are no known security issues with this extension.
この拡張機能には既知のセキュリティ問題はありません。
John Gardiner Myers Netscape Communications 501 East Middlefield Road Mail Stop MV-029 Mountain View, CA 94043
John Gardiner Myers Netscape Communications 501 East Middlefield Road Mail Stop MV-029 Mountain View、CA 94043
EMail: jgmyers@netscape.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。