RFC2180 日本語訳
2180 IMAP4 Multi-Accessed Mailbox Practice. M. Gahrns. July 1997. (Format: TXT=24750 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Gahrns Request for Comments: 2180 Microsoft Category: Informational July 1997
Gahrnsがコメントのために要求するワーキンググループM.をネットワークでつないでください: 2180年のマイクロソフトカテゴリ: 情報の1997年7月
IMAP4 Multi-Accessed Mailbox Practice
マルチアクセスされたメールボックスが練習するIMAP4
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
1. Abstract
1. 要約
IMAP4[RFC-2060] is rich client/server protocol that allows a client to access and manipulate electronic mail messages on a server. Within the protocol framework, it is possible to have differing results for particular client/server interactions. If a protocol does not allow for this, it is often unduly restrictive.
IMAP4[RFC-2060]はクライアントがサーバに関する電子メールメッセージにアクセスして、操るリッチクライアント/サーバプロトコルです。プロトコル枠組みの中では、特定のクライアント/サーバ相互作用のための異なった結果を持っているのは可能です。 プロトコルがこれを考慮しないなら、しばしば過度に制限しています。
For example, when multiple clients are accessing a mailbox and one attempts to delete the mailbox, an IMAP4 server may choose to implement a solution based upon server architectural constraints or individual preference.
複数のクライアントがメールボックスとメールボックスを削除する1つの試みにアクセスしているとき、例えば、IMAP4サーバは、サーバの建築規制か個々の好みに基づくソリューションを実現するのを選ぶかもしれません。
With this flexibility comes greater client responsibility. It is not sufficient for a client to be written based upon the behavior of a particular IMAP server. Rather the client must be based upon the behavior allowed by the protocol.
この柔軟性と共に、よりすばらしいクライアント責任は来ています。 クライアントが特定のIMAPサーバの働きに基づいた状態で書かれているのは、十分ではありません。むしろクライアントをプロトコルによって許容された振舞いに基礎づけなければなりません。
By documenting common IMAP4 server practice for the case of simultaneous client access to a mailbox, we hope to ensure the widest amount of inter-operation between IMAP4 clients and servers.
メールボックスへの同時のクライアントアクセスに関するケースのために一般的なIMAP4サーバ習慣を記録することによって、私たちは、IMAP4クライアントとサーバの間の最も広い量の相互操作を確実にすることを望んでいます。
The behavior described in this document reflects the practice of some existing servers or behavior that the consensus of the IMAP mailing list has deemed to be reasonable. The behavior described within this document is believed to be [RFC-2060] compliant. However, this document is not meant to define IMAP4 compliance, nor is it an exhaustive list of valid IMAP4 behavior. [RFC-2060] must always be consulted to determine IMAP4 compliance, especially for server behavior not described within this document.
本書では説明された振舞いはIMAPメーリングリストのコンセンサスが妥当であると考えた何らかの既存のサーバか振舞いの習慣を反映します。 このドキュメントの中に説明された振舞いが[RFC-2060]対応であると信じられています。 しかしながら、このドキュメントはIMAP4コンプライアンスを定義することになっていません、そして、それは有効なIMAP4の振舞いに関する完全なりストではありません。 特にこのドキュメントの中に説明されなかったサーバの振舞いのためのIMAP4コンプライアンスを決定するためにいつも[RFC-2060]に相談しなければなりません。
Gahrns Informational [Page 1] RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
[1ページ]RFC2180IMAP4のマルチアクセスされたメールボックス練習1997年7月の情報のGahrns
2. Conventions used in this document
2. 本書では使用されるコンベンション
In examples,"C1:", "C2:" and "C3:" indicate lines sent by 3 different clients (client #1, client #2 and client #3) that are connected to a server. "S1:", "S2:" and "S3:" indicated lines sent by the server to client #1, client #2 and client #3 respectively.
例で「C1:」、「C2:」 そして、「C3:」 サーバに接続される3人の異なったクライアント(クライアント#1、クライアント#2、およびクライアント#3)によって送られた線を示してください、「S1:」、「S2:」 そして、「S3:」 サーバによってそれぞれクライアント#1、クライアント#2、およびクライアント#3に送られた線を示しました。
A shared mailbox, is a mailbox that can be used by multiple users.
共有されたメールボックスは複数のユーザが使用できるメールボックスです。
A multi-accessed mailbox, is a mailbox that has multiple clients simultaneously accessing it.
マルチアクセスされたメールボックスは複数のクライアントが同時にそれにアクセスするメールボックスです。
A client is said to have accessed a mailbox after a successful SELECT or EXAMINE command.
クライアントはうまくいっているSELECTかEXAMINEコマンドの後にメールボックスにアクセスしたと言われています。
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 [RFC-2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC-2119]で説明されるように本書では解釈されることであるべきですか?
3. Deletion/Renaming of a multi-accessed mailbox
3. マルチアクセスされたメールボックスの削除/改名
If an external agent or multiple clients are accessing a mailbox, care must be taken when handling the deletion or renaming of the mailbox. Following are some strategies an IMAP server may choose to use when dealing with this situation.
メールボックスの削除か改名を扱うとき、外部のエージェントか複数のクライアントがメールボックスにアクセスしているなら、注意しなければなりません。 以下に、IMAPサーバがこの状況に対処するとき、使用するのを選ぶかもしれないいくつかの戦略があります。
3.1. The server MAY fail the DELETE/RENAME command of a multi-accessed
mailbox
3.1. サーバはマルチアクセスされたメールボックスのDELETE/RENAMEコマンドに失敗するかもしれません。
In some cases, this behavior may not be practical. For example, if a large number of clients are accessing a shared mailbox, the window in which no clients have the mailbox accessed may be small or non- existent, effectively rendering the mailbox undeletable or unrenamable.
いくつかの場合、この振舞いは実用的でないかもしれません。 例えば、多くのクライアントが共有されたメールボックスにアクセスしているなら、どんなクライアントもメールボックスをアクセスさせない窓は、小さいか、または非目下であるかもしれません、事実上、メールボックスを非削除可能であるか非改名可能にして。
Example:
例:
<Client #1 and Client #2 have mailbox FOO accessed. Client #1 tries to DELETE the mailbox and is refused>
<クライアント#1とClient#2はメールボックスFOOをアクセスさせます。 クライアント#1はDELETEにメールボックスを試して、>を拒否されます。
C1: A001 DELETE FOO
S1: A001 NO Mailbox FOO is in use by another user.
C1: A001はFOO S1を削除します: A001 NO Mailbox FOOは別のユーザで使用中です。
Gahrns Informational [Page 2] RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
[2ページ]RFC2180IMAP4のマルチアクセスされたメールボックス練習1997年7月の情報のGahrns
3.2. The server MAY allow the DELETE command of a multi-accessed
mailbox, but keep the information in the mailbox available for
those clients that currently have access to the mailbox.
3.2. サーバはマルチアクセスされたメールボックスのDELETEコマンドを許容するかもしれませんが、現在メールボックスに近づく手段を持っているそれらのクライアントに利用可能にメールボックスの中の情報を保ってください。
When all clients have finished accessing the mailbox, it is permanently removed. For clients that do not already have access to the mailbox, the 'ghosted' mailbox would not be available. For example, it would not be returned to these clients in a subsequent LIST or LSUB command and would not be a valid mailbox argument to any other IMAP command until the reference count of clients accessing the mailbox reached 0.
すべてのクライアントが、永久にメールボックスにアクセスし終えたとき、それを取り除きます。 既にメールボックスに近づく手段を持っていないクライアントにとって、'代作している'メールボックスは利用可能でないでしょう。 例えば、それは、その後のLISTかLSUBコマンドでこれらのクライアントに返されないで、またクライアントがメールボックスにアクセスする参照カウントが0に達するまで、いかなる他のIMAPコマンドへの有効なメールボックス議論でないでしょう。
In some cases, this behavior may not be desirable. For example if someone created a mailbox with offensive or sensitive information, one might prefer to have the mailbox deleted and all access to the information contained within removed immediately, rather than continuing to allow access until the client closes the mailbox.
いくつかの場合、この振舞いは望ましくないかもしれません。 例えば、だれかが不快であるか機密の情報でメールボックスを作成するなら、人が、メールボックスを削除させるのを好んで、情報へのアクセスが含んだすべてがすぐに、クライアントがメールボックスを閉じるまでずっとアクセスを許すより中でむしろ取り外されました。
Furthermore, this behavior, may prevent 'recycling' of the same mailbox name until all clients have finished accessing the original mailbox.
その上、この振舞い、すべてのクライアントが、オリジナルのメールボックスにアクセスし終えるまで同じメールボックス名が'再生されること'を防ぐかもしれません。
Example:
例:
<Client #1 and Client #2 have mailbox FOO selected. Client #1 DELETEs mailbox FOO>
<クライアント#1とClient#2はメールボックスFOOを選択させます。 クライアント#1DELETEsメールボックスFOO>。
C1: A001 DELETE FOO
S1: A001 OK Mailbox FOO is deleted.
C1: A001はFOO S1を削除します: A001 OK Mailbox FOOは削除されます。
<Client #2 is still able to operate on the deleted mailbox>
<クライアント#2は削除されたメールボックス>をまだ作動させることができます。
C2: B001 STORE 1 +FLAGS (\Seen)
S2: * 1 FETCH FLAGS (\Seen)
S2: B001 OK STORE completed
C2: B001店1+旗(見られた\)S2: * 1つのフェッチがS2に旗を揚げさせます(見られた\): 完成したB001 OK STORE
<Client #3 which did not have access to the mailbox prior to the deletion by client #1 does not have access to the mailbox>
削除の前にメールボックスにクライアント#1つ近づく手段を持っていなかった<クライアント#3がメールボックス>に近づく手段を持っていません。
C3: C001 STATUS FOO (MESSAGES)
S3: C001 NO Mailbox does not exist
C3: C001状態FOO(メッセージ)S3: C001 NO Mailboxは存在していません。
<Nor is client #3 able to create a mailbox with the name FOO, while the reference count is non zero>
<、また、参照カウントが非ゼロですが、クライアント#3がFOOという名前でメールボックスを作成できない、>。
C3: C002 CREATE FOO
S3: C002 NO Mailbox FOO is still in use. Try again later.
C3: C002はFOO S3を作成します: C002 NO Mailbox FOOはまだ使用中です。 後でもう一度試みてください。
Gahrns Informational [Page 3] RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
[3ページ]RFC2180IMAP4のマルチアクセスされたメールボックス練習1997年7月の情報のGahrns
<Client #2 closes its access to the mailbox, no other clients have access to the mailbox FOO and reference count becomes 0>
<クライアント#2はメールボックスへのアクセスを終えます、そして、他のどんなクライアントもメールボックスFOOに近づく手段を持っていません、そして、参照カウントは0>になります。
C2: B002 CLOSE
S2: B002 OK CLOSE Completed
C2: B002はS2を閉じます: 完成したB002OK閉鎖
<Now that the reference count on FOO has reached 0, the mailbox name can be recycled>
参照がFOOを頼りにするので、<は0に達して、メールボックス名は再生された>であるかもしれません。
C3: C003 CREATE FOO
S3: C003 OK CREATE Completed
C3: C003はFOO S3を作成します: C003OKは完成しているのに作成します。
3.3. The server MAY allow the DELETE/RENAME of a multi-accessed
mailbox, but disconnect all other clients who have the mailbox
accessed by sending a untagged BYE response.
3.3. サーバはマルチアクセスされたメールボックスのDELETE/RENAMEを許容するかもしれませんが、untagged BYE応答を送ることによってメールボックスをアクセスさせる他のすべてのクライアントを外してください。
A server may often choose to disconnect clients in the DELETE case, but may choose to implement a "friendlier" method for the RENAME case.
サーバは、しばしばDELETE場合でクライアントを外すのを選びますが、RENAMEケースのための「より好意的な」方法を実行するのを選ぶかもしれません。
Example:
例:
<Client #1 and Client #2 have mailbox FOO accessed. Client #1 DELETEs the mailbox FOO>
<クライアント#1とClient#2はメールボックスFOOをアクセスさせます。 クライアント#1DELETEsがメールボックスFOO>です。
C1: A002 DELETE FOO
S1: A002 OK DELETE completed.
C1: A002はFOO S1を削除します: 完成したA002 OK DELETE。
<Server disconnects all other users of the mailbox>
S2: * BYE Mailbox FOO has been deleted.
<サーバはメールボックス>S2の他のすべてのユーザを外します: * BYE Mailbox FOOは削除されました。
3.4. The server MAY allow the RENAME of a multi-accessed mailbox by
simply changing the name attribute on the mailbox.
3.4. サーバは、メールボックスで単に属性という名前を変えることによって、マルチアクセスされたメールボックスのRENAMEを許容するかもしれません。
Other clients that have access to the mailbox can continue issuing commands such as FETCH that do not reference the mailbox name. Clients would discover the renaming the next time they referred to the old mailbox name. Some servers MAY choose to include the [NEWNAME] response code in their tagged NO response to a command that contained the old mailbox name, as a hint to the client that the operation can succeed if the command is issued with the new mailbox name.
メールボックスに近づく手段を持っている他のクライアントは、メールボックス名を参照でないのにするFETCHなどのコマンドを発行し続けることができます。 クライアントは彼らが古いメールボックス名を示した次の時に改名を発見するでしょう。 いくつかのサーバが、古いメールボックス名を含んだコマンドへの彼らのタグ付けをされたいいえ応答に[NEWNAME]応答コードを含んでいるのを選ぶかもしれません、新しいメールボックス名でコマンドを発行するなら操作が成功できるというクライアントへのヒントとして。
Gahrns Informational [Page 4] RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
[4ページ]RFC2180IMAP4のマルチアクセスされたメールボックス練習1997年7月の情報のGahrns
Example:
例:
<Client #1 and Client #2 have mailbox FOO accessed. Client #1 RENAMEs the mailbox.>
<クライアント#1とClient#2はメールボックスFOOをアクセスさせます。 . クライアント#1RENAMEsがメールボックス>です。
C1: A001 RENAME FOO BAR
S1: A001 OK RENAME completed.
C1: A001はバーS1にFOOを改名します: 完成したA001 OK RENAME。
<Client #2 is still able to do operations that do not reference the mailbox name>
<クライアント#2はまだ>というメールボックス名を参照でないのにする操作ができています。
C2: B001 FETCH 2:4 (FLAGS)
S2: * 2 FETCH . . .
S2: * 3 FETCH . . .
S2: * 4 FETCH . . .
S2: B001 OK FETCH completed
C2: B001は2:4(旗)S2をとって来ます: * 2 …S2をとって来てください: * 3 …S2をとって来てください: * 4 …S2をとって来てください: 完成したB001 OK FETCH
<Client #2 is not able to do operations that reference the mailbox name>
<クライアント#2はメールボックスが>と命名するその参照が操作にできません。
C2: B002 APPEND FOO {300} C2: Date: Mon, 7 Feb 1994
21:52:25 0800 (PST) C2: . . . S2: B002 NO [NEWNAME FOO
BAR] Mailbox has been renamed
C2: B002はFOO300C2を追加します: 日付: 月曜日、1994年2月7日21:52:25 0800(太平洋標準時の)C2: . . . S2: B002 NO[NEWNAME FOO BAR]メールボックスは改名されました。
4. Expunging of messages on a multi-accessed mailbox
4. マルチアクセスされたメールボックスでのメッセージの梢消
If an external agent or multiple clients are accessing a mailbox, care must be taken when handling the EXPUNGE of messages. Other clients accessing the mailbox may be in the midst of issuing a command that depends upon message sequence numbers. Because an EXPUNGE response can not be sent while responding to a FETCH, STORE or SEARCH command, it is not possible to immediately notify the client of the EXPUNGE. This can result in ambiguity if the client issues a FETCH, STORE or SEARCH operation on a message that has been EXPUNGED.
メッセージのEXPUNGEを扱うとき、外部のエージェントか複数のクライアントがメールボックスにアクセスしているなら、注意しなければなりません。 メールボックスにアクセスする他のクライアントはメッセージ通番によるコマンドを発行する中にいるかもしれません。 FETCH、ストアまたは検索命令に応じている間、EXPUNGE応答を送ることができないので、すぐにEXPUNGEについてクライアントに通知するのは可能ではありません。 クライアントがEXPUNGEDであるメッセージでFETCH、ストアまたは検索操作を発行するなら、これはあいまいさをもたらすことができます。
4.1. Fetching of expunged messages
4.1. 梢消されたメッセージでは、魅惑的です。
Following are some strategies an IMAP server may choose to use when dealing with a FETCH command on expunged messages.
メッセージが進行中のFETCHコマンドの取扱いなら梢消されたとき、以下に、IMAPサーバが使用するのを選ぶかもしれないいくつかの戦略があります。
Gahrns Informational [Page 5] RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
[5ページ]RFC2180IMAP4のマルチアクセスされたメールボックス練習1997年7月の情報のGahrns
Consider the following scenario:
以下のシナリオを考えてください:
- Client #1 and Client #2 have mailbox FOO selected. - There are 7 messages in the mailbox. - Messages 4:7 are marked for deletion. - Client #1 issues an EXPUNGE, to expunge messages 4:7
- クライアント#1とClient#2はメールボックスFOOを選択させます。 - メールボックスの中に7つのメッセージがあります。 - メッセージ4:7は削除のためにマークされます。 - クライアント#1は、メッセージ4:7を梢消するためにEXPUNGEを発行します。
4.1.1. The server MAY allow the EXPUNGE of a multi-accessed mailbox but
keep the messages available to satisfy subsequent FETCH commands
until it is able to send an EXPUNGE response to each client.
4.1.1. それがEXPUNGE応答を各クライアントに送ることができるまで、サーバは、マルチアクセスされたメールボックスのEXPUNGEを許容しますが、その後のFETCHコマンドを満たすために利用可能にメッセージを保つかもしれません。
In some cases, the behavior of keeping "ghosted" messages may not be desirable. For example if a message contained offensive or sensitive information, one might prefer to instantaneously remove all access to the information, regardless of whether another client is in the midst of accessing it.
いくつかの場合、「代作している」メッセージを保つ振舞いは望ましくないかもしれません。 例えば、メッセージが不快であるか機密の情報を含んでいるなら、人は、即座に情報へのすべてのアクセスを取り除くのを好むでしょうに、別のクライアントがそれにアクセスする中にいることにかかわらず。
Example: (Building upon the scenario outlined in 4.1.)
例: (4.1に概説されたシナリオを当てにします。)
<Client #2 is still able to access the expunged messages because the server has kept a 'ghosted' copy of the messages until it is able to notify client #2 of the EXPUNGE>
2EXPUNGEクライアント#>に通知できるまでサーバがメッセージの'代作している'写しを取っておいたので、<クライアント#2はまだ梢消されたメッセージにアクセスできます。
C2: B001 FETCH 4:7 RFC822
S2: * 4 FETCH RFC822 . . . (RFC822 info returned)
S2: * 5 FETCH RFC822 . . . (RFC822 info returned)
S2: * 6 FETCH RFC822 . . . (RFC822 info returned)
S2: * 7 FETCH RFC822 . . . (RFC822 info returned)
S2: B001 OK FETCH Completed
C2: B001は4:7RFC822 S2をとって来ます: * 4 FETCH RFC822(RFC822インフォメーションは戻った)…S2: * 5 FETCH RFC822(RFC822インフォメーションは戻った)…S2: * 6 FETCH RFC822(RFC822インフォメーションは戻った)…S2: * 7 FETCH RFC822(RFC822インフォメーションは戻った)…S2: 終了するB001OKフェッチ
<Client #2 issues a command where it can get notified of the EXPUNGE>
<クライアント#2はEXPUNGE>についてそれに通知できるコマンドを発行します。
C2: B002 NOOP
S2: * 4 EXPUNGE
S2: * 4 EXPUNGE
S2: * 4 EXPUNGE
S2: * 4 EXPUNGE
S2: * 3 EXISTS
S2: B002 OK NOOP Complete
C2: B002 NOOP S2: * 4 S2を梢消してください: * 4 S2を梢消してください: * 4 S2を梢消してください: * 4 S2を梢消してください: * 3が存在している、S2: B002は完全な状態でNOOPを承認します。
<Client #2 no longer has access to the expunged messages>
<クライアント#2はもう梢消されたメッセージ>に近づく手段を持っていません。
C2: B003 FETCH 4:7 RFC822
S2: B003 NO Messages 4:7 are no longer available.
C2: B003は4:7RFC822 S2をとって来ます: B003 NO Messages4:7はもう利用可能ではありません。
Gahrns Informational [Page 6] RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
[6ページ]RFC2180IMAP4のマルチアクセスされたメールボックス練習1997年7月の情報のGahrns
4.1.2 The server MAY allow the EXPUNGE of a multi-accessed mailbox,
and on subsequent FETCH commands return FETCH responses only for
non-expunged messages and a tagged NO.
4.1.2 サーバはマルチアクセスされたメールボックスのEXPUNGEを許容するかもしれません、そして、その後のFETCHでは、コマンドは非梢消されたメッセージとタグ付けをされたNO.のためだけの応答をFETCHに返します。
After receiving a tagged NO FETCH response, the client SHOULD issue a NOOP command so that it will be informed of any pending EXPUNGE responses. The client may then either reissue the failed FETCH command, or by examining the EXPUNGE response from the NOOP and the FETCH response from the FETCH, determine that the FETCH failed because of pending expunges.
タグ付けをされたNO FETCH応答を受けた後に、クライアントSHOULDは、どんな未定のEXPUNGE応答でも知識があるようになるようにNOOPコマンドを発行します。 次に、クライアントは未定の状態でコマンドか、NOOPからの調べるのによるEXPUNGE応答とFETCHからのFETCH応答が決定する失敗したFETCHをFETCHが失敗した再発行するかもしれません。梢消します。
Example: (Building upon the scenario outlined in 4.1.)
例: (4.1に概説されたシナリオを当てにします。)
<Client #2 attempts to FETCH a mix of expunged and non-expunged messages. A FETCH response is returned only for then non-expunged messages along with a tagged NO>
<クライアント#2は梢消されて非梢消されたメッセージのミックスをFETCHに試みます。 応答が次に、非梢消されたメッセージのためだけにaと共に返されるFETCHは>に全くタグ付けをしませんでした。
C2: B001 FETCH 3:5 ENVELOPE
S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)
S2: B001 NO Some of the requested messages no longer exist
C2: B001は3:5封筒S2をとって来ます: * 3 FETCH ENVELOPE(ENVELOPEインフォメーションは戻った)…S2: 要求されたメッセージのB001 NO Someはもう存在していません。
<Upon receiving a tagged NO FETCH response, Client #2 issues a NOOP to be informed of any pending EXPUNGE responses>
タグ付けをされたNO FETCH応答を受けるときの<、Client#2、は、どんな未定のEXPUNGE応答>においても知識があるためにNOOPを発行します。
C2: B002 NOOP
S2: * 4 EXPUNGE
S2: * 4 EXPUNGE
S2: * 4 EXPUNGE
S2: * 4 EXPUNGE
S2: * 3 EXISTS
S2: B002 OK NOOP Completed.
C2: B002 NOOP S2: * 4 S2を梢消してください: * 4 S2を梢消してください: * 4 S2を梢消してください: * 4 S2を梢消してください: * 3が存在している、S2: B002は完成したNOOPを承認します。
<By receiving a FETCH response for message 3, and an EXPUNGE response that indicates messages 4:7 have been expunged, the client does not need to re-issue the FETCH>
メッセージ3のためのFETCH応答、およびメッセージ4:7が梢消されたのを示すEXPUNGE応答を受けるのによる<、クライアントはFETCH>を再発行する必要はありません。
Gahrns Informational [Page 7] RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
[7ページ]RFC2180IMAP4のマルチアクセスされたメールボックス練習1997年7月の情報のGahrns
4.1.3 The server MAY allow the EXPUNGE of a multi-accessed mailbox, and
on subsequent FETCH commands return the usual FETCH responses for
non-expunged messages, "NIL FETCH Responses" for expunged
messages, and a tagged OK response.
4.1.3 サーバはマルチアクセスされたメールボックスのEXPUNGEを許容するかもしれません、そして、その後のFETCHでは、コマンドは非梢消されたメッセージのための普通のFETCH応答、梢消されたメッセージのための「無いフェッチ応答」、およびタグ付けをされたOK応答を返します。
If all of the messages in the subsequent FETCH command have been expunged, the server SHOULD return only a tagged NO. In this case, the client SHOULD issue a NOOP command so that it will be informed of any pending EXPUNGE responses. The client may then either reissue the failed FETCH command, or by examining the EXPUNGE response from the NOOP, determine that the FETCH failed because of pending expunges.
その後のFETCHコマンドにおけるメッセージのすべてが梢消されたなら、サーバSHOULDはタグ付けをされたNO.だけを返します。 この場合、クライアントSHOULDは、どんな未定のEXPUNGE応答でも知識があるようになるようにNOOPコマンドを発行します。 次に、クライアントは未定の状態でFETCHコマンド、またはNOOPからの調べるのによるEXPUNGE応答が決定する失敗をFETCHが失敗した再発行するかもしれません。梢消します。
"NIL FETCH responses" are a representation of empty data as appropriate for the FETCH argument specified.
「NIL FETCH応答」は適宜議論が指定したFETCHのための空のデータの表現です。
Example:
例:
* 1 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL))
* 1 FETCH (FLAGS ())
* 1 FETCH (INTERNALDATE "00-Jan-0000 00:00:00 +0000")
* 1 FETCH (RFC822 "")
* 1 FETCH (RFC822.HEADER "")
* 1 FETCH (RFC822.TEXT "")
* 1 FETCH (RFC822.SIZE 0)
* 1 FETCH (BODY ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
* 1 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
* 1 FETCH (BODY[<section>] "")
* 1 FETCH (BODY[<section>]<partial> "")
* 1 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL)) * 1 FETCH (FLAGS ()) * 1 FETCH (INTERNALDATE "00-Jan-0000 00:00:00 +0000") * 1 FETCH (RFC822 "") * 1 FETCH (RFC822.HEADER "") * 1 FETCH (RFC822.TEXT "") * 1 FETCH (RFC822.SIZE 0) * 1 FETCH (BODY ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0) * 1 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0) * 1 FETCH (BODY[<section>] "") * 1 FETCH (ボディー[<部の>]の<の部分的な>、「「)」
In some cases, a client may not be able to distinguish between "NIL FETCH responses" received because a message was expunged and those received because the data actually was NIL. For example, a * 5 FETCH (FLAGS ()) response could be received if no flags were set on message 5, or because message 5 was expunged. In a case of potential ambiguity, the client SHOULD issue a command such as NOOP to force the sending of the EXPUNGE responses to resolve any ambiguity.
いくつかの場合、クライアントはメッセージが梢消されたので受け取られた「NIL FETCH応答」とデータが実際にNILであったので受け取られたものを見分けることができないかもしれません。 例えば、*5FETCH、(旗が全くメッセージ5に設定されなかったか、またはメッセージ5が梢消されたので、FLAGS())応答を受けることができました。 潜在的あいまいさの場合では、クライアントSHOULDはEXPUNGE応答の発信にどんなあいまいさも取り除かせるNOOPなどのコマンドを発行します。
Example: (Building upon the scenario outlined in 4.1.)
例: (4.1に概説されたシナリオを当てにします。)
<Client #2 attempts to access a mix of expunged and non-expunged messages. Normal data is returned for non-expunged message, "NIL FETCH responses" are returned for expunged messages>
<クライアント#2は、梢消されて非梢消されたメッセージのミックスにアクセスするのを試みます。 非梢消されたメッセージのために正常なデータを返して、梢消されたメッセージ>のために「NIL FETCH応答」を返します。
Gahrns Informational [Page 8] RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
[8ページ]RFC2180IMAP4のマルチアクセスされたメールボックス練習1997年7月の情報のGahrns
C2: B002 FETCH 3:5 ENVELOPE
S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)
S2: * 4 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL
NIL NIL)
S2: * 5 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL
NIL NIL)
S2: B002 OK FETCH Completed
C2: B002は3:5封筒S2をとって来ます: * 3 FETCH ENVELOPE(ENVELOPEインフォメーションは戻った)…S2: * 4 封筒(無い無い無い無い無い無い無い無い無い無)S2をとって来てください: * 5 封筒(無い無い無い無い無い無い無い無い無い無)S2をとって来てください: 終了するB002OKフェッチ
<Client #2 attempts to FETCH only expunged messages and receives a tagged NO response>
<クライアント#2は梢消されたメッセージをFETCHだけに試みて、応答のタグ付けをされたノー>を受けます。
C2: B002 FETCH 4:7 ENVELOPE
S2: B002 NO Messages 4:7 have been expunged.
C2: B002は4:7封筒S2をとって来ます: B002 NO Messages4:7は梢消されました。
4.1.4 To avoid the situation altogether, the server MAY fail the
EXPUNGE of a multi-accessed mailbox
4.1.4 全体で状況を避けるために、サーバはマルチアクセスされたメールボックスのEXPUNGEに失敗するかもしれません。
In some cases, this behavior may not be practical. For example, if a large number of clients are accessing a shared mailbox, the window in which no clients have the mailbox accessed may be small or non- existent, effectively rendering the message unexpungeable.
いくつかの場合、この振舞いは実用的でないかもしれません。 例えば、多くのクライアントが共有されたメールボックスにアクセスしているなら、どんなクライアントもメールボックスをアクセスさせない窓は、小さいか、または非目下であるかもしれません、事実上、メッセージを非梢消可能に伝えて。
4.2. Storing of expunged messages
4.2. 梢消されたメッセージの格納
Following are some strategies an IMAP server may choose to use when dealing with a STORE command on expunged messages.
メッセージが進行中のストアコマンドの取扱いなら梢消されたとき、以下に、IMAPサーバが使用するのを選ぶかもしれないいくつかの戦略があります。
4.2.1 If the ".SILENT" suffix is used, and the STORE completed
successfully for all the non-expunged messages, the server SHOULD
return a tagged OK.
4.2.1 ".SILENT"接尾語が使用されていて、店がすべてのために首尾よく非梢消されたメッセージを完成するなら、サーバはタグ付けをされたOKを返すでしょうに。
Example: (Building upon the scenario outlined in 4.1.)
例: (4.1に概説されたシナリオを当てにします。)
<Client #2 tries to silently STORE flags on expunged and non- expunged messages. The server sets the flags on the non-expunged messages and returns OK>
<クライアント#2は旗を揚げようとします。静かに、ストアは梢消されて非梢消されるところでメッセージに旗を揚げさせます。 サーバは、非梢消されたメッセージに旗をけしかけて、OK>を返します。
C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN)
S2: B001 OK
C2: B001は1:7+FLAGS.SILENT(見られた\)S2を格納します: B001OK
Gahrns Informational [Page 9] RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
[9ページ]RFC2180IMAP4のマルチアクセスされたメールボックス練習1997年7月の情報のGahrns
4.2.2. If the ".SILENT" suffix is not used, and only expunged messages
are referenced, the server SHOULD return only a tagged NO.
4.2.2. ".SILENT"接尾語が使用されていなくて、梢消されたメッセージだけが参照をつけられるなら、サーバはタグ付けをされたNO.だけを返すべきです。
Example: (Building upon the scenario outlined in 4.1.)
例: (4.1に概説されたシナリオを当てにします。)
<Client #2 tries to STORE flags only on expunged messages>
<クライアント#2は梢消されたメッセージ>だけでストア旗に試みます。
C2: B001 STORE 5:7 +FLAGS (\SEEN)
S2: B001 NO Messages have been expunged
C2: B001店5: 7 +はS2に旗を揚げさせます(見られた\): B001 NO Messagesは梢消されました。
4.2.3. If the ".SILENT" suffix is not used, and a mixture of expunged
and non-expunged messages are referenced, the server MAY set the
flags and return a FETCH response for the non-expunged messages
along with a tagged NO.
4.2.3. ".SILENT"接尾語が使用されていなくて、梢消されて非梢消されたメッセージの混合物が参照をつけられるなら、サーバは、タグ付けをされたNO.に伴う非梢消されたメッセージのために旗を設定して、フェッチ応答を返すかもしれません。
After receiving a tagged NO STORE response, the client SHOULD issue a NOOP command so that it will be informed of any pending EXPUNGE responses. The client may then either reissue the failed STORE command, or by examining the EXPUNGE responses from the NOOP and FETCH responses from the STORE, determine that the STORE failed because of pending expunges.
タグ付けをされたいいえストア応答を受けた後に、クライアントSHOULDは、どんな未定のEXPUNGE応答でも知識があるようになるようにNOOPコマンドを発行します。 次に、クライアントは未定の状態でコマンドか、NOOPからの調べるのによるEXPUNGE応答とストアからのFETCH応答が決定する失敗したストアをストアが失敗した再発行するかもしれません。梢消します。
Example: (Building upon the scenario outlined in 4.1.)
例: (4.1に概説されたシナリオを当てにします。)
<Client #2 tries to STORE flags on a mixture of expunged and non- expunged messages>
<クライアント#2は梢消されて非梢消されたメッセージ>の混合物の上にストア旗に試みます。
C2: B001 STORE 1:7 +FLAGS (\SEEN)
S2: * FETCH 1 FLAGS (\SEEN)
S2: * FETCH 2 FLAGS (\SEEN)
S2: * FETCH 3 FLAGS (\SEEN)
S2: B001 NO Some of the messages no longer exist.
C2: B001店1: 7 +はS2に旗を揚げさせます(見られた\): * フェッチ1はS2に旗を揚げさせます(見られた\): * フェッチ2はS2に旗を揚げさせます(見られた\): * フェッチ3はS2に旗を揚げさせます(見られた\): メッセージのB001 NO Someはもう存在していません。
C2: B002 NOOP
S2: * 4 EXPUNGE
S2: * 4 EXPUNGE
S2: * 4 EXPUNGE
S2: * 4 EXPUNGE
S2: * 3 EXISTS
S2: B002 OK NOOP Completed.
C2: B002 NOOP S2: * 4 S2を梢消してください: * 4 S2を梢消してください: * 4 S2を梢消してください: * 4 S2を梢消してください: * 3が存在している、S2: B002は完成したNOOPを承認します。
<By receiving FETCH responses for messages 1:3, and an EXPUNGE response that indicates messages 4:7 have been expunged, the client does not need to re-issue the STORE>
メッセージ1:3の間のFETCH応答、およびメッセージ4:7が梢消されたのを示すEXPUNGE応答を受けるのによる<、クライアントはストア>を再発行する必要はありません。
Gahrns Informational [Page 10] RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
[10ページ]RFC2180IMAP4のマルチアクセスされたメールボックス練習1997年7月の情報のGahrns
4.2.4. If the ".SILENT" suffix is not used, and a mixture of expunged
and non-expunged messages are referenced, the server MAY return
an untagged NO and not set any flags.
4.2.4. ".SILENT"接尾語が使用されていなくて、梢消されて非梢消されたメッセージの混合物が参照をつけられるなら、サーバは、非タグ付けをされたノーを返して、どんな旗も設定しないかもしれません。
After receiving a tagged NO STORE response, the client SHOULD issue a NOOP command so that it will be informed of any pending EXPUNGE responses. The client would then re-issue the STORE command after updating its message list per any EXPUNGE response.
タグ付けをされたいいえストア応答を受けた後に、クライアントSHOULDは、どんな未定のEXPUNGE応答でも知識があるようになるようにNOOPコマンドを発行します。 そして、どんなEXPUNGE応答あたりのメッセージリストもアップデートした後に、クライアントはストアコマンドを再発行するでしょう。
If a large number of clients are accessing a shared mailbox, the window in which there are no pending expunges may be small or non- existent, effectively disallowing a client from setting the flags on all messages at once.
多くのクライアントが共有されたメールボックスにアクセスしているなら、ある未定のノーが梢消する窓は、小さいか、または非目下であるかもしれません、事実上、すぐにすべてのメッセージに旗をけしかけるのでクライアントを禁じて。
Example: (Building upon the scenario outlined in 4.1.)
例: (4.1に概説されたシナリオを当てにします。)
<Client #2 tries to STORE flags on a mixture of expunged and non- expunged messages>
<クライアント#2は梢消されて非梢消されたメッセージ>の混合物の上にストア旗に試みます。
C2: B001 STORE 1:7 +FLAGS (\SEEN)
S2: B001 NO Some of the messages no longer exist.
C2: B001店1: 7 +はS2に旗を揚げさせます(見られた\): メッセージのB001 NO Someはもう存在していません。
<Client #2 issues a NOOP to be informed of the EXPUNGED messages>
<クライアント#2は、EXPUNGEDメッセージ>において知識があるためにNOOPを発行します。
C2: B002 NOOP
S2: * 4 EXPUNGE
S2: * 4 EXPUNGE
S2: * 4 EXPUNGE
S2: * 4 EXPUNGE
S2: * 3 EXISTS
S2: B002 OK NOOP Completed.
C2: B002 NOOP S2: * 4 S2を梢消してください: * 4 S2を梢消してください: * 4 S2を梢消してください: * 4 S2を梢消してください: * 3が存在している、S2: B002は完成したNOOPを承認します。
<Client #2 updates its message list and re-issues the STORE on only those messages that have not been expunged>
<クライアント#2は梢消された>でないそれらの唯一のメッセージで、メッセージリストをアップデートして、ストアを再発行します。
C2: B003 STORE 1:3 +FLAGS (\SEEN) S2: * FETCH 1 FLAGS
(\SEEN) S2: * FETCH 2 FLAGS (\SEEN) S2: * FETCH 3 FLAGS
(\SEEN) S2: B003 OK STORE Completed
C2: B003店1: 3 +はS2に旗を揚げさせます(見られた\): * フェッチ1はS2に旗を揚げさせます(見られた\): * フェッチ2はS2に旗を揚げさせます(見られた\): * フェッチ3はS2に旗を揚げさせます(見られた\): 完成したB003OK店
4.3. Searching of expunged messages
4.3. 梢消されたメッセージを探すこと
A server MAY simply not return a search response for messages that have been expunged and it has not been able to inform the client about. If a client was expecting a particular message to be returned in a search result, and it was not, the client SHOULD issue a NOOP command to see if the message was expunged by another client.
サーバは梢消されたメッセージのための検索応答を絶対に返さないかもしれません、そして、それはクライアントに受け取ったことを知らせさせることができませんでした。 クライアントが検索結果で返されるべき特定のメッセージを予想していて、それが予想していなかったなら、クライアントSHOULDはメッセージが別のクライアントによって梢消されたかどうかを見るNOOPコマンドを発行します。
Gahrns Informational [Page 11] RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
[11ページ]RFC2180IMAP4のマルチアクセスされたメールボックス練習1997年7月の情報のGahrns
4.4 Copying of expunged messages
4.4 梢消されたメッセージのコピー
COPY is the only IMAP4 sequence number command that is safe to allow an EXPUNGE response on. This is because a client is not permitted to cascade several COPY commands together. A client is required to wait and confirm that the copy worked before issuing another one.
COPYは唯一のEXPUNGE応答を許容するために安全なIMAP4一連番号コマンドです。 これはクライアントがいくつかのCOPYコマンドを一緒にどっと落させることが許可されていないからです。 クライアントが、別の1つを発行する前にコピーが働いたと待って、確認するのに必要です。
4.4.1 The server MAY disallow the COPY of messages in a multi-access
mailbox that contains expunged messages.
4.4.1 サーバは梢消されたメッセージを含むマルチアクセスメールボックスの中のメッセージのCOPYを禁じるかもしれません。
Pending EXPUNGE response(s) MUST be returned to the COPY command.
未定のEXPUNGE応答をCOPYコマンドに返さなければなりません。
Example:
例:
C: A001 COPY 2,4,6,8 FRED
S: * 4 EXPUNGE
S: A001 NO COPY rejected, because some of the requested
messages were expunged
C: A001コピー2、4、6、8フレッドS: * 4 Sを梢消してください: 要求されたメッセージのいくつかが梢消されたので拒絶されたA001 NO COPY
Note: Non of the above messages are copied because if a COPY command is unsuccessful, the server MUST restore the destination mailbox to its state before the COPY attempt.
以下に注意してください。 非、COPYコマンドが失敗しているなら、サーバがCOPY試みの前にあて先メールボックスを状態に返さなければならないので、上記のメッセージはコピーされます。
4.4.2 The server MAY allow the COPY of messages in a multi-access
mailbox that contains expunged messages.
4.4.2 サーバは梢消されたメッセージを含むマルチアクセスメールボックスの中のメッセージのCOPYを許容するかもしれません。
Pending EXPUNGE response(s) MUST be returned to the COPY command. Messages that are copied are messages corresponding to sequence numbers before any EXPUNGE response.
未定のEXPUNGE応答をCOPYコマンドに返さなければなりません。 コピーされるメッセージはどんなEXPUNGE応答の前にも一連番号に対応するメッセージです。
Example:
例:
C: A001 COPY 2,4,6,8 FRED
S: * 3 EXPUNGE
S: A001 OK COPY completed
C: A001コピー2、4、6、8フレッドS: * 3 Sを梢消してください: 完成したA001 OK COPY
In the above example, the messages that are copied to FRED are messages 2,4,6,8 at the start of the COPY command. These are equivalent to messages 2,3,5,7 at the end of the COPY command. The EXPUNGE response can't take place until after the messages from the COPY command are identified (because of the "no expunge while no commands in progress" rule).
上記の例では、フレッドにコピーされるメッセージはCOPYコマンドの始めのメッセージ2、4、6、8です。 これらはCOPYコマンドの終わりのメッセージ2、3、5、7に同等です。 COPYコマンドからのメッセージが特定された後までEXPUNGE応答が行われることができない、(「どんなコマンドも中で」 規則を進行していない間、いいえが梢消する、)
Gahrns Informational [Page 12] RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
[12ページ]RFC2180IMAP4のマルチアクセスされたメールボックス練習1997年7月の情報のGahrns
Example:
例:
C: A001 COPY 2,4,6,8 FRED
S: * 4 EXPUNGE
S: A001 OK COPY completed
C: A001コピー2、4、6、8フレッドS: * 4 Sを梢消してください: 完成したA001 OK COPY
In the above example, message 4 was copied before it was expunged, and MUST appear in the destination mailbox FRED.
上記の例では、メッセージ4は、それが梢消される前にコピーされて、あて先メールボックスフレッドに現れなければなりません。
5. Security Considerations
5. セキュリティ問題
This document describes behavior of servers that use the IMAP4 protocol, and as such, has the same security considerations as described in [RFC-2060].
このドキュメントは、そういうものとしてIMAP4プロトコルを使用するサーバの働きについて説明して、[RFC-2060]の説明されるのと同じセキュリティ問題を持っています。
In particular, some described server behavior does not allow for the immediate deletion of information when a mailbox is accessed by multiple clients. This may be a consideration when dealing with sensitive information where immediate deletion would be preferred.
特に、何らかの説明されたサーバの振舞いはメールボックスがいつ複数のクライアントによってアクセスされるかという情報の即座の削除を考慮しません。 即座の削除がどこで好まれるだろうかという機密情報に対処するとき、これは考慮であるかもしれません。
6. References
6. 参照
[RFC-2060], Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, University of Washington, December 1996.
[RFC-2060]、クリスピン、M.、「バージョン4rev1"、RFC2060、ワシントン大学、1996年インターネットメッセージアクセス・プロトコル--12月。」
[RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997.
[RFC-2119]、ブラドナーS.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、ハーバード大学、1997年3月。
7. Acknowledgments
7. 承認
This document is the result of discussions on the IMAP4 mailing list and is meant to reflect consensus of this group. In particular, Raymond Cheng, Mark Crispin, Jim Evans, Erik Forsberg, Steve Hole, Mark Keasling, Barry Leiba, Syd Logan, John Mani, Pat Moran, Larry Osterman, Chris Newman, Bart Schaefer, Vladimir Vulovic, and Jack De Winter were active participants in this discussion or made suggestions to this document.
このドキュメントは、IMAP4メーリングリストについての議論の結果であり、このグループのコンセンサスを反映することになっています。 レイモンド・チェン、マーク・クリスピン、ジム・エヴァンス、エリック・フォルスバーグ、スティーブHole、マークKeasling、バリーLeiba、シド・ローガン、ジョン・マニ、Pat Moran、ラリー・オスターマン、クリス・ニューマン、バードSchaefer、ウラジミールVulovic、およびジャックDe Winterは特に、この議論の積極的な参加者であったか提案をこのドキュメントにしました。
Gahrns Informational [Page 13] RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
[13ページ]RFC2180IMAP4のマルチアクセスされたメールボックス練習1997年7月の情報のGahrns
8. Author's Address
8. 作者のアドレス
Mike Gahrns Microsoft One Microsoft Way Redmond, WA, 98072
マイクGahrnsマイクロソフト1マイクロソフト道、レッドモンド、ワシントン 98072
Phone: (206) 936-9833 EMail: mikega@microsoft.com
以下に電話をしてください。 (206) 936-9833 メールしてください: mikega@microsoft.com
Gahrns Informational [Page 14]
Gahrns情報です。[14ページ]
一覧
スポンサーリンク
