Network Working Group A. Gulbrandsen
Request for Comments: 5465 Oryx Mail Systems GmbH
Updates: 5267 C. King
Category: Standards Track A. Melnikov
Isode Ltd.
February 2009
The IMAP NOTIFY 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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
This document defines an IMAP extension that allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from such mailboxes.
この文書では、クライアントは、そのようなメールボックスから追加または削除されるメッセージとして指定されたメールボックスの未承諾の通知の特定の種類を要求することを可能にするIMAP拡張を定義します。
Table of Contents
目次
1. Overview and Rationale ..........................................3
2. Conventions Used in This Document ...............................4
3. The NOTIFY Extension ............................................4
3.1. The NOTIFY Command .........................................4
4. Interaction with the IDLE Command ...............................8
5. Event Types .....................................................8
5.1. FlagChange and AnnotationChange ............................9
5.2. MessageNew .................................................9
5.3. MessageExpunge ............................................10
5.4. MailboxName ...............................................11
5.5. SubscriptionChange ........................................12
5.6. MailboxMetadataChange .....................................12
5.7. ServerMetadataChange ......................................13
5.8. Notification Overflow .....................................13
5.9. ACL (Access Control List) Changes .........................13
6. Mailbox Specification ..........................................14
6.1. Mailbox Specifiers Affecting the Currently
Selected Mailbox ..........................................14
6.2. Personal ..................................................15
6.3. Inboxes ...................................................15
6.4. Subscribed ................................................15
6.5. Subtree ...................................................15
6.6. Mailboxes .................................................16
7. Extension to SEARCH and SORT Commands ..........................16
8. Formal Syntax ..................................................16
9. Security Considerations ........................................19
10. IANA Considerations ...........................................19
10.1. Initial LIST-EXTENDED Extended Data Item Registrations ...19
11. Acknowledgements ..............................................20
12. Normative References ..........................................20
13. Informative References ........................................21
The IDLE command (defined in [RFC2177]) provides a way for the client to go into a mode where the IMAP server pushes it notifications about IMAP mailstore events for the selected mailbox. However, the IDLE extension doesn't restrict or control which server events can be sent, or what information the server sends in response to each event. Also, IDLE only applies to the selected mailbox, thus requiring an additional TCP connection per mailbox.
（[RFC2177]で定義された）IDLEコマンドは、クライアントがIMAPサーバは、それが選択したメールボックスのIMAPメールストアのイベントに関する通知プッシュモードに移行するための方法を提供します。しかし、IDLE拡張子は、サーバーイベントを送信できる制御、あるいはどのような情報サーバは、各イベントに応答して送信するかを制限するものではありません。また、IDLEは唯一ので、メールボックスあたり追加のTCP接続を必要とする、選択したメールボックスに適用されます。
This document defines an IMAP extension that allows clients to express their preferences about unsolicited events generated by the server. The extension allows clients to only receive events that they are interested in, while servers know that they don't need to go to the effort of generating certain types of untagged responses.
この文書では、クライアントは、サーバによって生成された迷惑イベントに関する自分の好みを表現することを可能にするIMAP拡張を定義します。拡張機能は、クライアントがサーバーのみが、彼らはタグなしの応答の特定の種類を生成する努力に行く必要がないことを知っていながら、彼らは、に興味のあるイベントを受け取ることができます。
Without the NOTIFY command defined in this document, an IMAP server will only send information about mailstore changes to the client in the following cases:
この文書で定義されたNOTIFYコマンドがなければ、IMAPサーバは、次の場合にのみ、クライアントにメールストアの変更に関する情報が送信されます。
- as the result of a client command (e.g., FETCH responses to a FETCH or STORE command), - as unsolicited responses sent just before the end of a command (e.g., EXISTS or EXPUNGE) as the result of changes in other sessions, and - during an IDLE command.
- 迷惑応答が他のセッションの変化の結果として（例えば、EXISTSまたはEXPUNGE）単にコマンドの終了前に送られて、そして - クライアントコマンドの結果として、（例えば、FETCHまたはSTOREコマンドへの応答をFETCH） - IDLEコマンド中。
The NOTIFY command extends what information may be returned in those last two cases, and also permits and requires the server to send information about updates between commands. The NOTIFY command also allows for the client to extend what information is sent unsolicited about the selected mailbox and to request some update information to be sent regarding other mailboxes.
NOTIFYコマンド情報は、これらの最後の2つのケースで返された、とも可能とコマンドの間の更新に関する情報を送信するためにサーバを必要とすることができるものを拡張します。クライアントは、選択したメールボックスについて迷惑送信されている情報拡張し、他のメールボックスについて送信されるように、いくつかの更新情報を要求するためにNOTIFYコマンドもできます。
The interaction between IDLE and NOTIFY commands is described in Section 4.
IDLEとNOTIFYコマンドの間の相互作用は、セクション4に記載されています。
For the new messages delivered to or appended to the selected mailbox, the NOTIFY command can be used to request that a set of attributes be sent to the client in an unsolicited FETCH response. This allows a client to be a passive recipient of events and new mail and to be able to maintain full synchronisation without having to issue any subsequent commands except to modify the state of the mailbox on the server.
配信されるか、選択したメールボックスに追加さ新しいメッセージの場合、NOTIFYコマンドは、属性のセットが求められていないFETCH応答でクライアントに送られることを要求するために使用することができます。これにより、クライアントはイベントや新しいメールの受動的な受信者であることを、サーバー上のメールボックスの状態を変更する以外の任意の後続のコマンドを発行することなく、完全な同期を維持できるようにすることができます。
Some mobile clients, however, may want mail "pushed" only for mail that matches a SEARCH pattern. To meet that need, [RFC5267] is augmented by this document to extend the UPDATE return option to specify a list of fetch-atts to be returned when a new message is delivered or appended in another session.
一部のモバイルクライアントは、しかし、メールのみ検索パターンに一致するメールに対して「プッシュ」することもできます。そのニーズを満たすために、[RFC5267]は新しいメッセージが配信されるか、別のセッションに追加されたときに返されるフェッチATTSのリストを指定するには、UPDATEのリターン・オプションを拡張するために、このドキュメントによって拡張されます。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The acronym MSN stands for Message Sequence Numbers (see Section 2.3.1.2 of [RFC3501]).
頭字語MSNは（[RFC3501]のセクション2.3.1.2を参照）メッセージシーケンス番号を表します。
Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:", by the server. "[...]" means elision.
「C：」で始まる例ラインは：サーバーにより、「S」で始まるクライアントとものによって送信されます。 "[...]" エリジオンを意味します。
IMAP servers that support this extension advertise the NOTIFY capability. This extension adds the NOTIFY command as defined in Section 5.1.
この拡張をサポートするIMAPサーバは、NOTIFY機能をアドバタイズ。セクション5.1で定義されているこの拡張は、NOTIFYコマンドが追加されます。
A server implementing this extension is not required to implement LIST-EXTENDED [RFC5258], even though a NOTIFY-compliant server must be able to return extended LIST responses, defined in [RFC5258].
この拡張機能を実装するサーバは、NOTIFY準拠のサーバは[RFC5258]で定義された拡張LIST応答を返すことができなければならないにもかかわらず、LIST-EXTENDED [RFC5258]を実装するために必要とされていません。
Arguments: "SET" Optional STATUS indicator Mailboxes to be watched Events about which to notify the client
引数：クライアントに通知することについてのイベントを見たことがオプションSTATUSインジケーターのメールボックスを「SET」
Or Arguments: "NONE"
または引数：「NONE」
Responses: Possibly untagged STATUS responses (for SET)
回答：おそらくタグなしSTATUS応答（SET用）
Result: OK - The server will notify the client as requested. NO - Unsupported NOTIFY event, NOTIFY too complex or expensive, etc. BAD - Command unknown, invalid, unsupported, or has unknown arguments.
結果：OK - 要求されたように、サーバーがクライアントに通知します。 NO - サポートされていないBADなど、複雑すぎるか、高価なNOTIFY、イベントをNOTIFY - コマンド、不明無効、サポートされていない、または未知の引数があります。
The NOTIFY command informs the server that the client listens for event notifications all the time (even when no command is in progress), and requests the server to notify it about the specified set of events. The NOTIFY command has two forms. NOTIFY NONE specifies that the client is not interested in any kind of event happening on the server. NOTIFY SET replaces the current list of interesting events with a new list of events.
NOTIFYコマンドクライアントがイベント通知のために（何のコマンドが進行中でなくても）すべての時間をリッスンし、イベントの指定されたセットについて、それを通知するために、サーバに要求サーバーに通知します。 NOTIFYコマンドは、2つの形式があります。 NONEは、クライアントがサーバー上で起こったイベントのいずれかの種類に興味を持っていないことを指定しないNOTIFY。 NOTIFY SETは、イベントの新しいリストと興味深いイベントの現在のリストを置き換えます。
Until the NOTIFY command is used for the first time, the server only sends notifications while a command is being processed, and notifies the client about these events on the selected mailbox (see Section 5 for definitions): MessageNew, MessageExpunge, or FlagChange. It does not notify the client about any events on other mailboxes.
MessageNew、MessageExpunge、またはFlagChange：NOTIFYコマンドを初めて使用されるまで、コマンドが処理され、選択されたメールボックスにこれらのイベント（定義については第5章を参照）について、クライアントに通知している間、サーバは通知のみを送信します。これは、他のメールボックス上の任意のイベントについてクライアントに通知されません。
The effect of a successful NOTIFY command lasts until the next NOTIFY command or until the IMAP connection is closed.
成功したNOTIFYコマンドの効果は、次のNOTIFYコマンドまで、またはIMAP接続が閉じられるまで続きます。
A successful NOTIFY SET command MUST cause the server to immediately return any accumulated changes to the currently selected mailbox (if any), such as flag changes and new or expunged messages. Thus, a successful NOTIFY SET command implies an implicit NOOP command.
成功するには、SETコマンドは、サーバーはすぐに、このようなフラグの変更や新規または抹消メッセージなど、現在選択されているメールボックスに蓄積されたすべての変更を（もしあれば）、復帰させる必要がありますNOTIFY。このように、成功したNOTIFY SETコマンドは、暗黙のNOOPコマンドを意味します。
The NOTIFY SET command can request notifications of message-related changes to the selected mailbox, whatever that may be at the time the message notifications are being generated. This is done by specifying either the SELECTED or the SELECTED-DELAYED mailbox selector (see Section 6.1) in the NOTIFY SET command. If the SELECTED/SELECTED-DELAYED mailbox selector is not specified in the NOTIFY SET command, this means that the client doesn't want to receive any <message-event>s for the currently selected mailbox. This is the same as specifying SELECTED NONE.
NOTIFY SETコマンドは、メッセージ通知が生成されている時であってもよい何らかの選択されたメールボックスにメッセージに関連した変化の通知を要求することができます。これは、SELECTED、または選択的に遅延メールボックスセレクタ（6.1節を参照）NOTIFY SETコマンドのいずれかで指定することによって行われます。 SELECTED / SELECTED遅延メールボックスのセレクタがNOTIFY SETコマンドで指定されていない場合、これは、クライアントが現在選択されているメールボックスのための任意の<message-イベント> Sを受信したくないことを意味します。これにより、選択NONEを指定しないと同じです。
The client can also request notifications on other mailboxes by name or by a limited mailbox pattern match. Message-related notifications returned for the currently selected mailbox will be those specified by the SELECTED/SELECTED-DELAYED mailbox specifier, even if the selected mailbox also appears by name (or matches a pattern) in the command. Non-message-related notifications are controlled by mailbox specifiers other than SELECTED/SELECTED-DELAYED.
また、クライアントは、名前または制限されたメールボックスのパターンマッチで他のメールボックスへの通知を要求することができます。現在選択されているメールボックスは、コマンドで選択したメールボックスにも名前で表示されます（またはパターンに一致する）場合でも、SELECTED / SELECTED遅延メールボックスの指定子で指定されたものとなりますため、メッセージ関連の通知が返されます。非メッセージ関連の通知は、選択/遅延選択以外のメールボックスの指定子によって制御されています。
If the NOTIFY command enables MessageNew, MessageExpunge, AnnotationChange, or FlagChange notifications for a mailbox other than the currently selected mailbox, and the client has specified the STATUS indicator parameter, then the server MUST send a STATUS response for that mailbox before NOTIFY's tagged OK. If MessageNew is enabled, the STATUS response MUST contain MESSAGES, UIDNEXT, and UIDVALIDITY. If MessageExpunge is enabled, the STATUS response MUST contain MESSAGES. If either AnnotationChange or FlagChange are included and the server also supports the CONDSTORE [RFC4551] and/or QRESYNC [RFC5162] extensions, the STATUS response MUST contain UIDVALIDITY and HIGHESTMODSEQ. Absence of the STATUS indicator parameter allows the client to avoid the additional STATUS responses. This might be useful if the client already retrieved this information before issuing the NOTIFY command.
NOTIFYコマンドは、現在選択されているメールボックス以外のメールボックスのMessageNew、MessageExpunge、AnnotationChange、またはFlagChange通知を有効にし、クライアントがSTATUSインジケータパラメータを指定した場合、サーバは前にそのメールボックスのステータス応答を送信するのはOKタグ付け通知しなければなりません。 MessageNewが有効になっている場合は、ステータス応答は、メッセージ、UIDNEXT、およびUIDVALIDITYを含まなければなりません。 MessageExpungeが有効になっている場合は、ステータス応答メッセージを含まなければなりません。 AnnotationChangeまたはFlagChangeのいずれかが含まれており、サーバもCONDSTORE [RFC4551]および/またはQRESYNC [RFC5162]の拡張機能をサポートしている場合は、STATUS応答はUIDVALIDITYとHIGHESTMODSEQを含まなければなりません。 STATUSインジケータパラメータの不在は、クライアントが追加STATUS応答を避けることができます。クライアントがすでにNOTIFYコマンドを発行する前に、この情報を取得した場合、これは便利かもしれません。
Clients are advised to limit the number of mailboxes used with NOTIFY. Particularly, if a client asks for events for all accessible mailboxes, the server may swamp the client with updates about shared mailboxes. This may reduce the client's battery life. Also, this wastes both server and network resources.
クライアントは、NOTIFYで使用するメールボックスの数を制限することをお勧めします。クライアントがアクセス可能なすべてのメールボックスのイベントを要求する場合は特に、サーバーは、共有メールボックスに関する更新情報をクライアントに圧倒ことがあります。これは、クライアントのバッテリ寿命を減らすことができます。また、これは、サーバーおよびネットワークリソースの両方を無駄にします。
For each mailbox specified, the server verifies that the client has access using the following test:
指定された各メールボックスの場合、サーバーは、クライアントが次のテストを使用してアクセスを持っていることを確認します
- If the name does not refer to an existing mailbox, the server MUST ignore it.
- 名前が既存のメールボックスを参照していない場合は、サーバはそれを無視しなければなりません。
- If the name refers to a mailbox that the client can't LIST, the server MUST ignore it. For a server that implements [RFC4314], this means that if the client doesn't have the 'l' (lookup) right for the name, then the server MUST ignore the mailbox. This behavior prevents disclosure of potentially confidential information to clients who don't have rights to know it.
- 名前は、クライアントが一覧できないことをメールボックスを参照している場合、サーバはそれを無視しなければなりません。 [RFC4314]を実装し、サーバーの場合、これは、クライアントが「L」名（ルックアップ）権を持っていない場合、サーバーはメールボックスを無視しなければならないことを意味します。この動作は、それを知る権利を持っていないクライアントに対して潜在的に機密情報の開示を防ぐことができます。
- If the name refers to a mailbox that the client can LIST (e.g., it has the 'l' right from [RFC4314]), but the client doesn't have another right required for processing of the specified event(s), then the server MUST respond with an untagged extended LIST response containing the \NoAccess name attribute.
- 名前は、クライアントがLIST（例えば、それは右の[RFC4314]から「L」を持っている）が、クライアントは指定されたイベント（複数可）の処理に必要な他の権利を持っていないし、できることをメールボックスを参照している場合サーバーは\ NoAccessをname属性を含むタグなし拡張LIST応答で応じなければなりません。
The server SHOULD return the tagged OK response if the client has access to at least one of the mailboxes specified in the current list of interesting events. The server MAY return the tagged NO response if the client has no access to any of the specified mailboxes and no access can ever be granted in the future (e.g., the client specified an event for 'Subtree Bar/Foo', 'Bar/Foo' doesn't exist, and LIST returns \Noinferiors for the parent 'Bar').
クライアントは興味深いイベントの現在のリストに指定されたメールボックスの少なくとも一つへのアクセス権を持っている場合、サーバはタグ付きOK応答を返すべきです。クライアントが指定したメールボックスのいずれかとアクセスなしにアクセスできない場合、サーバーは、これまで例えば、クライアントが「サブツリーバー/ Fooの」のイベントを指定（将来的に付与することができますタグ付きNO応答を返さないかもしれない、「バー/フー'が存在し、LISTは、親のために、\ Noinferiorsを返していません 『バー』）。
If the notification would be prohibitively expensive for the server (e.g., "notify me of all flag changes in all mailboxes"), the server MAY refuse the command with a tagged NO [NOTIFICATIONOVERFLOW] response.
通知はサーバーの法外に高価になる場合（例えば、「すべてのメールボックス内のすべてのフラグ変更が生じた場合には通知」）、サーバはタグ付きNO [NOTIFICATIONOVERFLOW]応答でコマンドを拒否することができます。
If the client requests information for events of an unsupported type, the server MUST refuse the command with a tagged NO response (not a BAD). This response SHOULD contain the BADEVENT response code, which MUST list names of all events supported by the server.
クライアントがサポートされていないタイプのイベントのための情報を要求した場合、サーバはタグ付きNO応答（BADではない）を指定して、コマンドを拒否しなければなりません。この応答は、サーバがサポートするすべてのイベントの名前をリストする必要がありますBADEVENT応答コードを、含むべきです。
Here's an example:
ここでは例を示します。
S: * OK [CAPABILITY IMAP4REV1 NOTIFY]
C: a login bob alice
S: a OK Password matched
C: b notify set status (selected MessageNew (uid
body.peek[header.fields (from to subject)]) MessageExpunge)
(subtree Lists MessageNew)
S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 9999 MESSAGES
500)
S: [...]
S: * STATUS Lists/Im2000 (UIDVALIDITY 901 UIDNEXT 1 MESSAGES 0)
S: b OK done
C: c select inbox
S: [...] (the usual 7-8 responses to SELECT)
S: c OK INBOX selected
(Time passes. A new message is delivered to mailbox
Lists/Lemonade.)
S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 10000
MESSAGES 501)
(Time passes. A new message is delivered to inbox.)
S: * 127 FETCH (UID 127001 BODY[HEADER.FIELDS (From To
Subject)] {75}
S: Subject: Re: good morning
S: From: alice@example.org
S: To: bob@example.org
S:
S: )
(Time passes. The client decides it wants to know about
one more mailbox. As the client already knows necessary
STATUS information for all mailboxes below the Lists
mailbox, and because "notify set status" would cause
STATUS responses for *all* mailboxes specified in the
NOTIFY command, including the ones for which the client
already knows STATUS information, the client issues an
explicit STATUS request for the mailbox to be added to
the watch list, followed by the NOTIFY SET without the
STATUS parameter.)
C: d STATUS misc (UIDVALIDITY UIDNEXT MESSAGES)
S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999)
S: d STATUS completed
C: e notify set (selected MessageNew (uid body.peek[header.fields (from to subject)]) MessageExpunge) (subtree Lists MessageNew) (mailboxes misc MessageNew) S: e OK done
C：Eが設定通知（MessageExpunge）選択MessageNew（UID BODY.PEEK [（）被験者へのHEADER.FIELDS]）（サブツリーがMessageNewを一覧表示します）（メールボックスその他MessageNew）S：済のE OK
If IDLE [RFC2177] (as well as this extension) is supported, then while processing any IDLE command, the server MUST send exactly the same events as instructed by the client using the NOTIFY command.
IDLE [RFC2177]（同様に、この拡張機能）がサポートされている場合は任意のIDLEコマンドを処理している間、そして、サーバは正確にNOTIFYコマンドを使用して、クライアントから指示されたのと同じイベントを送らなければなりません。
NOTIFY makes IDLE unnecessary for some clients. If a client does not use MSNs and '*' in commands, it can request MessageExpunge and MessageNew for the selected mailbox by using the NOTIFY command instead of entering the IDLE mode.
作るには、いくつかのクライアントのために不要IDLE NOTIFY。クライアントがコマンドでMSNsと「*」を使用しない場合は、NOTIFYコマンドを使用しての代わりに、IDLEモードに入ることで、選択したメールボックスのMessageExpungeとMessageNewを要求することができます。
A client that uses MSNs and '*' in commands can still use the NOTIFY command if it specifies the SELECTED-DELAYED mailbox specifier in the NOTIFY command.
それはNOTIFYコマンドで選択された遅延メールボックスの指定子を指定する場合、コマンドにMSNsと「*」を使用するクライアントは、まだNOTIFYコマンドを使用することができます。
Only some of the events in [RFC5423] can be expressed in IMAP, and for some of them there are several possible ways to express the event.
唯一[RFC5423]のイベントの一部は、IMAPで発現させることができ、そのうちのいくつかのイベントを表現するいくつかの可能な方法があります。
This section specifies the events of which an IMAP server can notify an IMAP client, and how.
このセクションでは、IMAPサーバーがIMAPクライアント、およびどのように通知することができたのイベントを指定します。
The server SHOULD omit notifying the client if the event is caused by this client. For example, if the client issues CREATE and has requested a MailboxName event that would cover the newly created mailbox, the server SHOULD NOT notify the client of the MailboxName change.
イベントはこのクライアントによって引き起こされている場合、サーバーは、クライアントに通知省略すべきです。クライアントの問題は、CREATEと新しく作成されたメールボックスをカバーするMailboxNameのイベントを要求した場合、サーバーはMailboxNameの変更をクライアントに通知すべきではありません。
All event types described in this document require the 'l' and 'r' rights (see [RFC4314]) on all observed mailboxes. Servers that don't implement [RFC4314] should map the above rights to their access-control model.
本文書に記載されている全てのイベントタイプは、すべての観察のメールボックスに（[RFC4314]を参照）「L」と「R」の権限が必要です。 [RFC4314]を実装していないサーバは、そのアクセス制御モデルに上記の権利をマッピングする必要があります。
If the FlagChange and/or AnnotationChange events are specified, MessageNew and MessageExpunge MUST also be specified by the client. Otherwise, the server MUST respond with the tagged BAD response.
FlagChangeおよび/またはAnnotationChangeイベントが指定されている場合は、MessageNewとMessageExpungeは、クライアントによって指定されなければなりません。そうしないと、サーバはタグ付きBAD応答で応じなければなりません。
If one of MessageNew or MessageExpunge is specified, then both events MUST be specified. Otherwise, the server MUST respond with the tagged BAD response.
MessageNewまたはMessageExpungeのいずれかが指定されている場合、両方のイベントを指定する必要があります。そうしないと、サーバはタグ付きBAD応答で応じなければなりません。
The client can instruct the server not to send an event by omitting the necessary event from the list of events specified in NOTIFY SET, by using the NONE event specifier in the NOTIFY SET, or by using NOTIFY NONE. In particular, NOTIFY SET ... NONE can be used as a snapshot facility by clients.
クライアントはで指定されたイベントのリストから必要なイベントを省略してイベントを送信しないようにサーバーに指示することができNOTIFY SETでNONEイベント指定子を使用して、またはNONEを知らせてはいけない使用して、SETを通知します。具体的には、SETをNOTIFY ... NONEは、クライアントによってスナップショット機能として使用することはできません。
If the flag and/or message annotation change happens in the selected mailbox, the server MUST notify the client by sending an unsolicited FETCH response, which MUST include UID and FLAGS/ANNOTATION FETCH data items. It MAY also send new FLAGS and/or OK [PERMANENTFLAGS ...] responses.
フラグ及び/またはメッセージ注釈の変更が選択されたメールボックスに発生した場合、サーバは、UIDおよびFLAGS /注釈がデータアイテムを取得含まなければならない迷惑フェッチ応答を送信することによってクライアントに通知しなければなりません。また、新しいFLAGSおよび/またはOK [PERMANENTFLAGS ...]応答を送信することができます。
If a search context is in effect as specified in [RFC5267], an ESEARCH ADDTO or ESEARCH REMOVEFROM will also be generated, if appropriate. In this case, the FETCH response MUST precede the ESEARCH response.
[RFC5267]で指定された検索コンテキストが有効である場合は、適切な場合、ESEARCH ADDTOまたはESEARCH REMOVEFROMはまた、生成されます。この場合、FETCH応答はESEARCH応答に先行しなければなりません。
If the change happens in another mailbox, then the server responds with a STATUS response. The exact content of the STATUS response depends on various factors. If CONDSTORE [RFC4551] and/or QRESYNC [RFC5162] are enabled by the client, then the server sends a STATUS response that includes at least HIGHESTMODSEQ and UIDVALIDITY status data items. If the number of messages with the \Seen flag changes, the server MAY also include the UNSEEN data item in the STATUS response. If CONDSTORE/QRESYNC is not enabled by the client and the server chooses not to include the UNSEEN data item, the server does not notify the client. When this event is requested, the server MUST notify the client about mailbox UIDVALIDITY changes. This is done by sending a STATUS response that includes UIDVALIDITY.
変更が別のメールボックスに発生した場合、サーバはステータス応答で応答します。ステータス応答の正確な内容は、種々の要因に依存します。 CONDSTORE [RFC4551]および/またはQRESYNC [RFC5162]は、クライアントで有効になっている場合、サーバーは、少なくともHIGHESTMODSEQとUIDVALIDITYステータスデータ項目が含まSTATUS応答を送信します。 \見フラグが変更されたメッセージの数の場合には、サーバは、ステータス応答でUNSEENデータ項目を含むかもしれません。 CONDSTORE / QRESYNCがクライアントで有効になっていないと、サーバーがUNSEENデータ項目を含めるしないことを選択した場合、サーバはクライアントに通知されません。このイベントが要求されると、サーバーは、メールボックスのUIDVALIDITYの変更についてクライアントに通知しなければなりません。これは、UIDVALIDITYが含まSTATUS応答を送信することにより行われます。
FlagChange covers the MessageRead, MessageTrash, FlagsSet, and FlagsClear events in [RFC5423].
FlagChangeは[RFC5423]でMessageRead、MessageTrash、FlagsSet、及びFlagsClearイベントをカバーします。
Example in the selected mailbox: S: * 99 FETCH (UID 9999 FLAGS ($Junk))
選択したメールボックス内の例：S：* 99はFETCH（UID 9999のFLAGS（$ジャンク））
And in another mailbox, with CONDSTORE in use: S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665 UIDVALIDITY 101)
そして、使用中のCONDSTOREを持つ別のメールボックス、中：S：* STATUSリスト/レモネード（HIGHESTMODSEQ 65666665 UIDVALIDITY 101）
This covers both MessageNew and MessageAppend in [RFC5423].
これは、[RFC5423]でMessageNewとMessageAppendの両方をカバーしています。
If the new/appended message is in the selected mailbox, the server notifies the client by sending an unsolicited EXISTS response, followed by an unsolicited FETCH response containing the information requested by the client. A FETCH response SHOULD NOT be generated for a new message created by the client on this particular connection, for instance, as the result of an APPEND or COPY command to the selected mailbox performed by the client itself. The server MAY also send a RECENT response, if the server marks the message as \Recent.
新しい/追加メッセージが選択されたメールボックス内にある場合は、サーバが迷惑送信することにより、クライアントは、クライアントから要求された情報を含む応答をFETCH迷惑続く、EXISTS応答を通知します。フェッチ応答は、クライアント自体によって行われる選択されたメールボックスに追加またはCOPYコマンドの結果として、例えば、この特定の接続でのクライアントによって作成された新しいメッセージのために生成されるべきではありません。サーバは最近\としてメッセージをマークした場合、サーバはまた、最近の応答を送信することができます。
Note that a single EXISTS response can be returned for multiple MessageAppend/MessageNew events.
単一の応答EXISTS複数MessageAppend / MessageNewイベントを返すことができることに注意してください。
If a search context is in effect as specified in [RFC5267], an ESEARCH ADDTO will also be generated, if appropriate. In this case, the EXISTS response MUST precede the ESEARCH response. Both the NOTIFY command and the SEARCH and SORT commands (see Section 7) can specify attributes to be returned for new messages. These attributes SHOULD be combined into a single FETCH response. The server SHOULD avoid sending duplicate data. The FETCH response(s) MUST follow any ESEARCH ADDTO responses.
[RFC5267]で指定された検索コンテキストが有効である場合は、適切な場合、ESEARCH ADDTOはまた、生成されます。この場合、応答はESEARCH応答に先行しなければなりませんEXISTS。どちらのコマンドおよびSEARCHとSORTコマンドは（セクション7を参照）を指定することができ、新しいメッセージのために返される属性を通知します。これらの属性は、単一のFETCH応答に組み合わせる必要があります。サーバーは、重複データを送信することは避けてください。 FETCH応答（複数可）の任意ESEARCHのADDTO応答に従わなければなりません。
If the new/appended message is in another mailbox, the server sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant mailbox. If the CONDSTORE extension [RFC4551] and/or the QRESYNC extension [RFC5162] is enabled, the HIGHESTMODSEQ status data item MUST be included in the STATUS response.
新しい/追加メッセージが別のメールボックスにある場合、サーバは、関連するメールボックスの迷惑STATUS（UIDNEXTのメッセージ）応答を送信します。 CONDSTORE拡張[RFC4551]及び/又はQRESYNC拡張[RFC5162]が有効になっている場合、HIGHESTMODSEQ状態データ項目は、ステータス応答に含まれなければなりません。
The client SHOULD NOT use FETCH attributes that implicitly set the \seen flag, or that presuppose the existence of a given bodypart. UID, MODSEQ, FLAGS, ENVELOPE, BODY.PEEK[HEADER.FIELDS... and BODY/BODYSTRUCTURE may be the most useful attributes.
クライアントは、暗黙のうちに\見フラグを設定する属性をFETCH使うべきではない、またはそれは、与えられたボディパーツの存在を前提とします。 UID、MODSEQ、FLAGS、ENVELOPE、BODY.PEEK [HEADER.FIELDS ...とBODY / BODYSTRUCTUREが最も有用な属性かもしれません。
Note that if a client asks to be notified of MessageNew events with the SELECTED mailbox specifier, the number of messages can increase at any time, and therefore the client cannot refer to a specific message using the MSN/UID '*'.
クライアントが選択されたメールボックスを指定してMessageNewイベントが通知されるように要求した場合、メッセージの数は、いつでも増やすことができ、したがって、クライアントはMSN / UID「*」を使用して、特定のメッセージを参照することができないことに注意してください。
Example in the selected mailbox: S: * 444 EXISTS S: * 444 FETCH (UID 9999)
選択したメールボックス内の例：S：* 444はSをEXISTS：* 444（UID 9999）FETCH
And in another mailbox, without CONDSTORE enabled: S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503)
そして、別のメールボックスにCONDSTOREせずに有効：S：* STATUSリスト/レモネード（UIDNEXT 10002のMESSAGES 503）
If the expunged message or messages are in the selected mailbox, the server notifies the client using EXPUNGE (or VANISHED, if [RFC5162] is supported by the server and enabled by the client).
消去されたメッセージまたはメッセージが選択されたメールボックスである場合は（[RFC5162]は、サーバーでサポートされ、クライアントで有効になっている場合、または消えた）、サーバはEXPUNGEを使用してクライアントに通知します。
If a search context is in effect, as specified in [RFC5267], an ESEARCH REMOVEFROM will also be generated, if appropriate.
検索コンテキストが有効である場合は、適切な場合には、[RFC5267]で指定されるように、ESEARCH REMOVEFROMはまた、生成されます。
If the expunged message or messages are in another mailbox, the server sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant mailbox. If the QRESYNC [RFC5162] extension is enabled, the HIGHESTMODSEQ data item MUST be included in the STATUS response as well.
消去されたメッセージまたはメッセージが別のメールボックスにある場合、サーバは、関連するメールボックスの迷惑STATUS（UIDNEXTのメッセージ）応答を送信します。 QRESYNC [RFC5162]拡張が有効な場合、HIGHESTMODSEQデータ項目は、同様にステータス応答に含まれなければなりません。
Note that if a client requests MessageExpunge with the SELECTED mailbox specifier, the meaning of an MSN can change at any time, so the client cannot use MSNs in commands anymore. For example, such a client cannot use FETCH, but has to use UID FETCH. The meaning of '*' can also change when messages are added or expunged. A client wishing to keep using MSNs can either use the SELECTED-DELAYED mailbox specifier or can avoid using the MessageExpunge event entirely.
クライアントが選択されたメールボックスの指定子でMessageExpungeを要求した場合、クライアントはもうコマンドでMSNsを使用することはできませんので、MSNの意味は、いつでも変更できることに注意してください。たとえば、そのようなクライアントは、FETCH使用していますが、UID FETCHを使用していることはできません。メッセージが追加されたり消去されたときに「*」の意味も変更することができます。クライアントは、選択した遅延メールボックスの指定子を使用することができますいずれかMSNsを使用し続けることを希望、または完全にMessageExpungeイベントの使用を避けることができます。
The MessageExpunge notification covers both MessageExpunge and MessageExpire events from [RFC5423].
MessageExpunge通知は、[RFC5423]の両方からMessageExpungeとMESSAGEEXPIREイベントをカバーします。
Example in the selected mailbox, without QRESYNC: S: * 444 EXPUNGE
S：選択したメールボックスで、QRESYNCのない例* 444 EXPUNGE
The same example in the selected mailbox, with QRESYNC: S: * VANISHED 5444
S：：* 5444消えQRESYNCと、選択したメールボックス内の同じ例
And in another mailbox, when QRESYNC is not enabled: S: * STATUS misc (UIDNEXT 999 MESSAGES 554)
そして、別のメールボックスでは、QRESYNCが有効になっていません：S：* STATUS雑貨（UIDNEXT 999のMESSAGES 554）
These notifications are sent if an affected mailbox name was created (with CREATE), deleted (with DELETE), or renamed (with RENAME). For a server that implements [RFC4314], granting or revocation of the 'l' right to the current user on the affected mailbox MUST be considered mailbox creation or deletion, respectively. If a mailbox is created or deleted, the mailbox itself and its direct parent (whether it is an existing mailbox or not) are considered to be affected.
これらの通知は（RENAMEで）影響を受けるメールボックス名が作成された場合には、（CREATEで）送信され、削除（DELETEで）、または名前変更されています。 [RFC4314]を実装するサーバ、許可または右影響を受けるメールボックスの現在のユーザーに「L」の取り消しをそれぞれメールボックスの作成または削除、考慮されなければなりません。メールボックスが作成または削除されている場合は、メールボックス自体とその直接の親が（それが既存のメールボックスであるかどうか）影響を受けると考えられています。
The server notifies the client by sending an unsolicited LIST response for each affected mailbox name. If, after the event, the mailbox name does not refer to a mailbox accessible to the client, the \Nonexistent flag MUST be included.
サーバーは、影響を受ける各メールボックス名のため、迷惑LIST応答を送信することにより、クライアントに通知します。 、イベントの後、メールボックス名は、クライアントがアクセスできるメールボックスを参照していない場合は、\存在しないフラグを含まなければなりません。
For each LISTable mailbox renamed, the server sends an extended LIST response [RFC5258] for the new mailbox name, containing the OLDNAME extended data item with the old mailbox name. When a mailbox is renamed, its children are renamed too. No additional MailboxName events are sent for children in this case. When INBOX is renamed, a new INBOX is assumed to be created. No MailboxName event is sent for INBOX in this case.
名前を変更し、各リスト可能メールボックスのために、サーバはOLDNAMEを含む、新しいメールボックス名の拡張LIST応答[RFC5258]を送信しますが、古いメールボックス名とデータ項目を拡張しました。メールボックスの名前が変更された場合、その子はあまりにも名前が変更されます。追加のMailboxNameのイベントは、この場合の子供たちのために送信されません。 INBOXの名前が変更された場合、新しいINBOXを作成するものとします。いいえMailboxNameのイベントは、この場合にINBOXのために送信されません。
If the server automatically subscribes a mailbox when it is created or renamed, then the unsolicited LIST response for each affected subscribed mailbox name MUST include the \Subscribed attribute (see [RFC5258]). The server SHOULD also include \HasChildren or \HasNoChildren attributes [RFC5258] as appropriate.
サーバが自動的に作成されるか、または名前が変更されたメールボックスをサブスクライブした場合、影響を受ける各加入メールボックス名の迷惑LIST応答は\サブスクライブした属性を含まなければならない（[RFC5258]を参照）。また、サーバは、\ HasChildrenまたは\ HasNoChildrenを適宜[RFC5258]を属性含むべきです。
Example of a newly created mailbox (or granting of the 'l' right on the mailbox): S: * LIST () "/" "NewMailbox"
新しく作成されたメールボックスの例（または右メールボックスの「L」の付与）：S：* LIST（）「/」「NewMailbox」
And a deleted mailbox (or revocation of the 'l' right on the mailbox): S: * LIST (\NonExistent) "." "INBOX.DeletedMailbox"
そして、削除されたメールボックス（または右メールボックスの「L」の取消し）：S：* LIST（\存在しません）「」 "INBOX.DeletedMailbox"
Example of a renamed mailbox: S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox"))
名前を変更したメールボックスの例：S：* LIST（） "/" "NewMailbox"（ "OLDNAME"（ "OldMailbox"））
The server notifies the client by sending an unsolicited LIST response for each affected mailbox name. If and only if the mailbox is subscribed after the event, the \Subscribed attribute (see [RFC5258]) is included. Note that in the LIST response, all mailbox attributes MUST be accurately computed (this differs from the behavior of the LSUB command).
サーバーは、影響を受ける各メールボックス名のため、迷惑LIST応答を送信することにより、クライアントに通知します。メールボックスは、イベント後に加入している場合にのみ場合は、\購読済み属性（[RFC5258]を参照）が含まれています。 LIST応答に、すべてのメールボックスの属性を正確に計算しなければならないことに注意してください（これはLSUBコマンドの動作とは異なります）。
Example: S: * LIST (\Subscribed) "/" "SubscribedMailbox"
例：S：* LIST（\購読） "/" "SubscribedMailbox"
Support for this event type is OPTIONAL unless the METADATA extension [RFC5464] is also supported by the server, in which case support for this event type is REQUIRED.
メタデータ拡張[RFC5464]は、このイベント・タイプのケースのサポートが要求されるサーバでサポートされていない限り、このイベント・タイプのサポートはオプションです。
A client willing to receive unsolicited METADATA responses as a result of using the MailboxMetadataChange event in the NOTIFY command doesn't have to issue ENABLE METADATA.
NOTIFYコマンドでMailboxMetadataChangeイベントを使用した結果として迷惑METADATA応答を受け取るために喜んでクライアントは、メタデータをENABLE発行する必要はありません。
The server sends an unsolicited METADATA response (as per Section 4.4.2 of [RFC5464]). If possible, only the changed metadata SHOULD be included, but if the server can't detect a change to a single metadata item, it MAY include all metadata items set on the mailbox. If a metadata item is deleted (set to NIL), it MUST always be included in the METADATA response.
サーバが要請されていないメタデータ応答を送信する（[RFC5464]のセクション4.4.2に従って）。可能であれば、唯一の変更メタデータが含まれる必要がありますが、サーバーは、単一のメタデータ項目への変更を検出できない場合、それはメールボックスに設定されているすべてのメタデータ項目を含むかもしれません。メタデータ項目は、（NILに設定）削除された場合、それは常にMETADATA応答に含まれなければなりません。
Example: S: * METADATA "INBOX" /shared/comment
例：S：*メタデータ "INBOX" /共有/コメント
Support for this event type is OPTIONAL unless the METADATA or the METADATA-SERVER extension [RFC5464] is also supported by the server, in which case support for this event type is REQUIRED.
メタデータまたはメタデータサーバ拡張[RFC5464]は、このイベント・タイプのサポートが必要とされる場合には、サーバでサポートされていない限り、このイベント・タイプのサポートはオプションです。
A client willing to receive unsolicited METADATA responses as a result of using the ServerMetadataChange event in the NOTIFY command doesn't have to issue ENABLE METADATA or ENABLE METADATA-SERVER.
NOTIFYコマンドでServerMetadataChangeイベントを使用した結果として迷惑METADATA応答を受け取るために喜んでクライアントは、メタデータを有効にするか、メタデータサーバを有効に発行する必要はありません。
The server sends an unsolicited METADATA response (as per Section 4.4.2 of [RFC5464]). Only the names of changed metadata entries SHOULD be returned in such METADATA responses. If a metadata item is deleted (set to NIL), it MUST always be included in the METADATA response.
サーバが要請されていないメタデータ応答を送信する（[RFC5464]のセクション4.4.2に従って）。変更されたメタデータエントリの名前だけは、このようなメタデータの応答で返されるべきです。メタデータ項目は、（NILに設定）削除された場合、それは常にMETADATA応答に含まれなければなりません。
Example: S: * METADATA "" /shared/comment
例：S：*メタデータ "" /共有/コメント
If the server is unable or unwilling to deliver as many notifications as it is being asked to, it may disable notifications for some or all clients. It MUST notify these clients by sending an untagged "OK [NOTIFICATIONOVERFLOW]" response and behave as if a NOTIFY NONE command had just been received.
それが要求されているように、サーバーはできるだけ多くの通知を配信できないか、不本意である場合、それはいくつかまたはすべてのクライアントの通知を無効にすることができます。これは、タグの付いていない「OK [NOTIFICATIONOVERFLOW]」応答とNOTIFY NONEコマンドがちょうど受信されたかのように振る舞うを送信することにより、これらのクライアントに通知しなければなりません。
Example: S: * OK [NOTIFICATIONOVERFLOW] ...A comment can go here...
例：* [通知のOVERFLOW] ...のコメントはここに行くことができ...
Even if NOTIFY succeeds, it is still possible to lose access to the mailboxes being monitored at a later time. If this happens, the server MUST stop monitoring these mailboxes. If access is later granted, the server MUST restart event monitoring.
NOTIFYが成功したとしても、後の時間に監視されているメールボックスにアクセスできなくすることも可能です。この問題が発生した場合、サーバーは、これらのメールボックスの監視を停止しなければなりません。アクセスは、後に付与されている場合は、サーバーは、イベント・モニターを再起動する必要があります。
The server SHOULD return the LIST response with the \NoAccess name attribute if and when the mailbox loses the 'l' right. Similarly, the server SHOULD return the LIST response with no \NoAccess name attribute if the mailbox was previously reported as having \NoAccess and the 'l' right is later granted.
サーバーは、メールボックスが右に「L」失われた場合や、\ NoAccessをname属性を持つLIST応答を返すべきです。メールボックスが以前に右後に付与されている\ NoAccessをと「L」を有するとして報告された場合は同様に、サーバーはありません\ NoAccessをname属性でLIST応答を返すべきです。
Mailboxes to be monitored can be specified in several different ways.
監視対象とするメールボックスには、いくつかの異なる方法で指定することができます。
Only 'SELECTED' and 'SELECTED-DELAYED' (Section 6.1) match the currently selected mailbox. All other mailbox specifications affect other (non-selected) mailboxes.
のみ（6.1節）は現在選択されているメールボックスに一致する「SELECTED」と「遅延選択」。他のすべてのメールボックス仕様は、他の（非選択）のメールボックスに影響を与えます。
Note that multiple <event-group>s can apply to the same mailbox. The following example demonstrates this. In this example, MessageNew and MessageExpunge events are reported for INBOX, due to the first <event-group>. A SubscriptionChange event will also be reported for INBOX, due to the second <event-group>.
その複数の<イベント・グループ>の注意は同じメールボックスに適用することができます。次の例では、このことを示しています。この例では、MessageNewとMessageExpungeイベントは、最初の<イベントグループ>によるINBOX、について報告されています。 SubscriptionChangeイベントはまた、2つ目の<イベントグループ>に、INBOXのために報告されます。
C: a notify set (mailboxes INBOX (Messagenew messageExpunge)) (personal (SubscriptionChange))
C：Aに通知セット（メールボックスINBOX（Messagenew messageExpunge））（個人（SubscriptionChange））
A typical client that supports the NOTIFY extension would ask for events on the selected mailbox and some named mailboxes.
NOTIFY拡張をサポートしている一般的なクライアントは、選択したメールボックスのイベントや、いくつかの名前のメールボックスのためにお願いします。
In the next example, the client asks for FlagChange events for all personal mailboxes except the currently selected mailbox. This is different from the previous example because SELECTED overrides all other message event definitions for the currently selected mailbox (see Section 3.1).
次の例では、クライアントは、現在選択されているメールボックスを除くすべての個人的なメールボックスのFlagChangeイベントを要求します。 （3.1節を参照してください）現在選択されているメールボックスのオーバーライド他のすべてのメッセージのイベント定義を選択したためこれは、前の例と異なっています。
C: a notify set (selected (Messagenew (uid flags) messageExpunge)) (personal (MessageNew FlagChange MessageExpunge))
C：通知設定（選択（Messagenew（UIDフラグ）messageExpunge））（個人（MessageNew FlagChange MessageExpunge））
Only one of the mailbox specifiers affecting the currently selected mailbox can be specified in any NOTIFY command. The two such mailbox specifiers (SELECTED and SELECTED-DELAYED) are described below.
任意のコマンドをNOTIFYにのみ、現在選択されているメールボックスに影響を与えるメールボックスの指定子の1を指定することができます。二つのそのようなメールボックス指定子（選択され、選択された遅延）は、以下に記載されています。
Both refer to the mailbox that was selected using either SELECT or EXAMINE (see [RFC3501], Sections 6.3.1 and 6.3.2). When the IMAP connection is not in the selected state, such mailbox specifiers don't refer to any mailbox.
両方が（セクション6.3.1および6.3.2、[RFC3501]を参照）SELECTまたはEXAMINEのいずれかを使用して、選択されたメールボックスを指します。 IMAP接続が選択された状態でない場合は、そのようなメールボックスの指定子は、任意のメールボックスを参照しません。
The mailbox specifiers only apply to <message-event>s. It is an error to specify other types of events with either the SELECTED or the SELECTED-DELAYED selector.
メールボックスの指定子は唯一の<message-イベント> Sに適用されます。選択または選択遅延セレクタのいずれかのイベントの他のタイプを指定すると、エラーになります。
The SELECTED mailbox specifier requires the server to send immediate notifications for the currently selected mailbox about all specified <message-event>s.
選択されたメールボックス指定子は、指定されたすべての<message-イベント> Sについて現在選択されているメールボックスの即時通知を送信するためにサーバを必要とします。
The SELECTED-DELAYED mailbox specifier requires the server to delay a MessageExpunge event until the client issues a command that allows returning information about expunged messages (see Section 7.4.1 of [RFC3501] for more details), for example, till a NOOP or an IDLE command has been issued. When SELECTED-DELAYED is specified, the server MAY also delay returning other <message-event>s until the client issues one of the commands specified above, or it MAY return them immediately.
SELECTED遅延メールボックス指定子は（詳細は[RFC3501]のセクション7.4.1を参照）、クライアントが消去されたメッセージに関する情報を返すことができますコマンドを発行するまでMessageExpungeイベントを遅らせるために、サーバーを必要とし、例えば、NOOPまでまたはAN IDLEコマンドが発行されました。指定されたSELECTED遅延すると、サーバーは、クライアントが上記のいずれかのコマンドを発行するまで、他の<message-イベント> Sを返す遅らせる場合もあれば、すぐに返してもよいです。
Personal refers to all selectable mailboxes in the user's personal namespace(s), as defined in [RFC2342].
個人は、[RFC2342]で定義されるように、ユーザの個人的な名前空間（S）内の全ての選択可能なメールボックスを指します。
Inboxes refers to all selectable mailboxes in the user's personal namespace(s) to which messages may be delivered by a Message Delivery Agent (MDA) (see [EMAIL-ARCH], particularly Section 4.3.3).
受信トレイは、（特に、セクション4.3.3、[EMAIL-ARCH]を参照）メッセージがメッセージ配信エージェント（MDA）によって送達することができるため、ユーザの個人的な名前空間（S）内の全ての選択可能なメールボックスを指します。
If the IMAP server cannot easily compute this set, it MUST treat "inboxes" as equivalent to "personal".
IMAPサーバは、簡単にこのセットを計算することができない場合は、「個人」と同等に「受信トレイ」を扱わなければなりません。
Subscribed refers to all mailboxes subscribed to by the user.
購読は、ユーザが加入してすべてのメールボックスを指します。
If the subscription list changes, the server MUST reevaluate the list.
サブスクリプションのリストが変更された場合、サーバーはリストを再評価しなければなりません。
Subtree is followed by a mailbox name or list of mailbox names. A subtree refers to all selectable mailboxes that are subordinate to the specified mailbox plus the specified mailbox itself.
サブツリーは、メールボックス名またはメールボックス名のリストが続いています。サブツリーは、指定したメールボックスプラス指定したメールボックス自体に従属するすべての選択可能なメールボックスを指します。
Mailboxes is followed by a mailbox name or a list of mailbox names. The server MUST NOT do a wildcard expansion. This means there is no special treatment for the LIST wildcard characters ('*' and '%') if they are present in mailbox names.
メールボックスは、メールボックス名またはメールボックス名のリストが続いています。サーバーは、ワイルドカードの拡張を行うてはなりません。これは、彼らがメールボックス名に存在している場合は、リストのワイルドカード文字のための特別な治療（「*」と「％」）が存在しないことを意味します。
If the server that supports the NOTIFY extension also supports CONTEXT=SEARCH and/or CONTEXT=SORT as defined in [RFC5267], the UPDATE return option is extended so that a client can request that FETCH attributes be returned when a new message is added to the context result set.
[RFC5267]で定義されたNOTIFYの拡張をサポートするサーバーもCONTEXT = SEARCHおよび/またはCONTEXT = SORTをサポートしている場合は、新しいメッセージが追加されたとき、属性をFETCHクライアント缶要求が返されるように、UPDATEのリターン・オプションが拡張されコンテキスト結果は設定してください。
For example:
例えば：
C: a00 SEARCH RETURN (COUNT UPDATE (UID BODY[HEADER.FIELDS (TO
FROM SUBJECT)])) FROM "boss"
S: * ESEARCH (TAG "a00") (COUNT 17)
S: a00 OK
[...a new message is delivered...]
S: * EXISTS 93
S: * 93 FETCH (UID 127001 BODY[HEADER.FIELDS (FROM TO SUBJECT)]
{76}
S: Subject: Re: good morning
S: From: myboss@example.org
S: To: bob@example.org
S:
S: )
S: * ESEARCH (TAG "a00") ADDTO (0 93)
Note that the EXISTS response MUST precede any FETCH responses, and together they MUST precede the ESEARCH response.
応答は、任意の応答をFETCH先行しなければなりませんが存在することに注意してください、と一緒に彼らはESEARCH応答に先行しなければなりません。
No untagged FETCH response SHOULD be returned if a message becomes a member of UPDATE SEARCH due to flag or annotation changes.
メッセージフラグまたは注釈変化によるUPDATE検索のメンバーになった場合に何のタグ無しフェッチ応答が返されるべきではありません。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the non-terminals "capability", "command-auth", "mailbox", "mailbox-data", "resp-text-code", and "search-key". The "modifier-update" non-terminal is defined in [RFC5267]. "mbx-list-oflag" is defined in [RFC3501] and updated by [RFC5258].
以下の構文仕様は、[RFC5234]で指定された拡張バッカス・ナウアフォーム（ABNF）の表記を使用します。 [RFC3501]は、 "検索キー" 非終端 "機能"、 "コマンド-AUTH"、 "メールボックス"、 "メールボックスデータ"、 "RESPテキストコード" を定義し、。 「修飾子更新」非末端は[RFC5267]で定義されています。 "MBX-リストoflagの" [RFC3501]で定義されており、[RFC5258]で更新されます。
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. For example, the <filter-mailboxes-selected> non-terminal value "SELECTED" must be treated in the same way as "Selected" or "selected".
特記しないものを除いて、すべての英字は大文字と小文字を区別しません。トークン文字列を定義するための、大・小文字の使用は、編集上明確にするためです。実装は大文字と小文字を区別しないやり方で、これらの文字列を受け入れなければなりません。例えば、「選択された」<フィルタ・メールボックス選択>非終端値が「選択」または「選択」と同様に処理しなければなりません。
capability =/ "NOTIFY"
機能= / "NOTIFY"
command-auth =/ notify
コマンド-AUTH = /通知
notify = "NOTIFY" SP (notify-set / notify-none)
SPの "NOTIFY" 通知=（通知するセット/通知しない-なし）
notify-set = "SET" [status-indicator] SP event-groups ; Replace registered notification events ; with the specified list of events
=「SET」[ステータスインジケータ] SPのイベントグループ通知設定。登録通知イベントを交換してください。イベントの指定されたリストを持ちます
notify-none = "NONE" ; Cancel all registered notification ; events. The client is not interested ; in receiving any events.
通知-なし= "NONE"。すべての登録済みの通知をキャンセル。イベント。クライアントは興味がありません。すべてのイベントを受け取るインチ
status-indicator = SP "STATUS"
ステータス・インジケータ= SP "STATUS"
one-or-more-mailbox = mailbox / many-mailboxes
1 - または - 以上 - メールボックス=メールボックス/多のメールボックス
many-mailboxes = "(" mailbox *(SP mailbox) ")"
多くの-メールボックス= "（" メールボックス*（SPメールボックス） "）"
event-groups = event-group *(SP event-group)
イベント・グループ=イベントグループ*（SPイベントグループ）
event-group = "(" filter-mailboxes SP events ")" ;; Only <message-event>s are allowed in <events> ;; when <filter-mailboxes-selected> is used.
イベントグループ=「（」フィルタメールボックスSPイベント「）」;; <メッセージ・イベント> Sは、<イベント>にのみ許可されてい;; <フィルタメールボックス選択>する際に使用されます。
filter-mailboxes = filter-mailboxes-selected / filter-mailboxes-other
フィルタ・メールボックス=フィルタメールボックス選択/フィルタ・メールボックス、他の
filter-mailboxes-other = "inboxes" / "personal" / "subscribed" / ( "subtree" SP one-or-more-mailbox ) / ( "mailboxes" SP one-or-more-mailbox )
フィルタ・メールボックス・他=「受信トレイ」/「個人」/「サブスクライブ」/（「サブツリー」SP一又は、それ以上メールボックス）/（「メールボックス」SP一又は、それ以上メールボックス）
filter-mailboxes-selected = "selected" / "selected-delayed" ;; Apply to the currently selected mailbox only. ;; Only one of them can be specified in a NOTIFY ;; command.
=「選択」/「選択遅延」フィルタメールボックスは、選択され;;現在選択されているメールボックスにのみ適用されます。 ;;だけそのうちの一つは、NOTIFYで指定することができます;;コマンド。
events = ( "(" event *(SP event) ")" ) / "NONE" ;; As in [MSGEVENT]. ;; "NONE" means that the client does not wish ;; to receive any events for the specified ;; mailboxes.
イベント=（ "（" イベント*（SPイベント） "）"）/ "NONE" ;; 【MSGEVENT]です。 ;; 「NONE」は、クライアントが望んでいないことを意味しません;;指定のためのすべてのイベントを受信する;;メールボックス。
event = message-event / mailbox-event / user-event / event-ext
イベント=メッセージイベント/メールボックス・イベント/ユーザーイベント/イベント-EXT
message-event = ( "MessageNew" [SP "(" fetch-att *(SP fetch-att) ")" ] ) / "MessageExpunge" / "FlagChange" / "AnnotationChange" ;; "MessageNew" includes "MessageAppend" from ;; [MSGEVENT]. "FlagChange" is any of ;; "MessageRead", "MessageTrash", "FlagsSet", ;; "FlagsClear" [MSGEVENT]. "MessageExpunge" ;; includes "MessageExpire" [MSGEVENT]. ;; MessageNew and MessageExpunge MUST always ;; be specified together. If FlagChange is ;; specified, then MessageNew and MessageExpunge ;; MUST be specified as well. ;; The fett-att list may only be present for the ;; SELECTED/SELECTED-DELAYED mailbox filter ;; (<filter-mailboxes>).
メッセージイベント=（ "MessageNew" [SP "（" フェッチ-ATTをSP（フェッチのatt *） "）"）/ "MessageExpunge" / "FlagChange" / "AnnotationChange" ;; "MessageNewは" から "MessageAppend" が含ま;; 【MSGEVENT]。 「FlagChangeは」のいずれかである;; "MessageRead"、 "MessageTrash"、 "FlagsSet"、;; "FlagsClear" [MSGEVENT]。 "MessageExpunge" ;; [MSGEVENT] "MESSAGEEXPIRE" が含まれます。 ;; MessageNewとMessageExpungeは常にMUST ;;一緒に指定します。 FlagChangeであれば;;指定された場合、MessageNewとMessageExpunge ;;指定されなければなりません。 ;;フェット-ATTのリストには、;;のために存在することができますSELECTED / SELECTED遅延メールボックスフィルタ;; （<フィルタメールボックス>）。
mailbox-event = "MailboxName" / "SubscriptionChange" / "MailboxMetadataChange" ; "SubscriptionChange" includes ; MailboxSubscribe and MailboxUnSubscribe. ; "MailboxName" includes MailboxCreate, ; "MailboxDelete" and "MailboxRename".
メールボックス・イベント= "MailboxNameの" / "SubscriptionChange" / "MailboxMetadataChange"。 「SubscriptionChange」には、 MailboxSubscribeとMailboxUnSubscribe。 ; "MailboxNameのは"、MailboxCreateを含み; "MailboxDelete" と "MailboxRename"。
user-event = "ServerMetadataChange"
ユーザーイベント=「ServerMetadataChange」
event-ext = atom ;; For future extensions
イベント-EXT =原子;;将来の拡張のために
oldname-extended-item = "OLDNAME" SP "(" mailbox ")" ;; Extended data item (mbox-list-extended-item) ;; returned in a LIST response when a mailbox is ;; renamed. ;; Note 1: the OLDNAME tag can be returned ;; with or without surrounding quotes, as per ;; mbox-list-extended-item-tag production.
OLDNAME拡張項目= "OLDNAME" SP "（" メールボックス "）" ;;拡張データ項目（MBOXリスト拡張項目）;;メールボックスがあるとき、LIST応答で返さ;;改名しました。 ;;注1：OLDNAMEタグを返すことができます;;とや引用符を囲むせず、あたりとして;; MBOX-リスト拡張項目タグの生産。
resp-text-code =/ "NOTIFICATIONOVERFLOW" / unsupported-events-code
RESP-テキストコード= / "NOTIFICATIONOVERFLOW" /サポートされていない - イベントコード
message-event-name = "MessageNew" / "MessageExpunge" / "FlagChange" / "AnnotationChange"
メッセージ・イベント名= "MessageNew" / "MessageExpunge" / "FlagChange" / "AnnotationChange"
event-name = message-event-name / mailbox-event / user-event
イベント名=メッセージイベント名/メールボックス・イベント/ユーザーイベント
unsupported-events-code = "BADEVENT" SP "(" event-name *(SP event-name) ")"
サポートされていない - イベントコード=「BADEVENT」SP「（」イベント名*（SPイベント名）「）」
modifier-update = "UPDATE" [ "(" fetch-att *(SP fetch-att) ")" ]
修飾子更新= "UPDATE" [ "（"）*（SPにフェッチをフェッチします "）"]
mbx-list-oflag =/ "\NoAccess"
MBX-リストスキン= / "\ NoAccessを"
It is very easy for a client to deny itself service using NOTIFY. Asking for all events on all mailboxes may work on a small server, but with a big server, can swamp the client's network connection or processing capability. In the worst case, the server's processing could also degrade the service it offers to other clients.
クライアントは、NOTIFY使用して自分自身にサービスを拒否することは非常に簡単です。すべてのメールボックス上のすべてのイベントのために頼むことは小さなサーバー上で動作することがありますが、大きなサーバーで、クライアントのネットワーク接続や処理能力を圧倒することができます。最悪の場合には、サーバーの処理はまた、他のクライアントに提供するサービスを低下させることができます。
Server authors should be aware that if a client issues requests and does not listen to the resulting responses, the TCP window can easily fill up, and a careless server might block. This problem also exists in plain IMAP; however, this extension magnifies the problem.
サーバーの作者は、クライアントが要求を発行し、その結果応答に耳を傾けていない場合は、TCPウィンドウを簡単に埋めることができますことに注意する必要があり、かつ不注意なサーバがブロックされる可能性があります。また、この問題は、プレーンIMAPに存在します。しかし、この拡張機能は問題を拡大します。
This extension makes it possible to retrieve messages immediately when they are added to the mailbox. This makes it wholly impractical to delete sensitive messages using programs like imapfilter. Using SIEVE [RFC5228] or similar is much better.
それらがメールボックスに追加されたときに、この拡張機能は、すぐにメッセージを取得することが可能となります。これは、完全に非現実的imapfilterなどのプログラムを使用して機密メッセージを削除することができます。 SIEVE [RFC5228]または類似を使用すると、はるかに優れています。
The IANA has added NOTIFY to the list of IMAP extensions.
IANAは、IMAP拡張子のリストにNOTIFY追加しました。
The following entry has been added to the LIST-EXTENDED response registry [RFC5258]:
次のエントリは、リストEXTENDED応答レジストリ[RFC5258]に追加されました。
To: iana@iana.org Subject: Registration of OLDNAME LIST-EXTENDED extended data item
To：iana@iana.org件名：OLDNAME LIST-EXTENDED拡張データ項目の登録
LIST-EXTENDED extended data item tag: OLDNAME
LIST-EXTENDED拡張データ項目タグ：OLDNAME
LIST-EXTENDED extended data item description: The OLDNAME extended data item describes the old mailbox name for the mailbox identified by the LIST response.
LIST-EXTENDED拡張データ項目の説明：OLDNAME拡張データ項目LIST応答によって識別されるメールボックスの古いメールボックス名を記述します。
Which LIST-EXTENDED option(s) (and their types) causes this extended data item to be returned (if any): none
どのLIST-EXTENDEDオプション（S）（およびそのタイプ）（もしあれば）、この拡張されたデータ項目が戻されます：なし
Published specification : RFC 5465, Section 5.4.
公開された仕様：RFC 5465、セクション5.4。
Security considerations: none
セキュリティの考慮事項：なし
Intended usage: COMMON
意図している用法：COMMON
Person and email address to contact for further information: Alexey Melnikov <Alexey.Melnikov@isode.com>
Personと詳細のために連絡する電子メールアドレス：アレクセイ・メルニコフ<Alexey.Melnikov@isode.com>
Owner/Change controller: iesg@ietf.org
所有者/変更コントローラ：iesg@ietf.org
The authors gratefully acknowledge the help of Peter Coates, Dave Cridland, Mark Crispin, Cyrus Daboo, Abhijit Menon-Sen, Timo Sirainen, and Eric Burger. In particular, Peter Coates contributed lots of text and useful suggestions to this document.
作者は感謝ピーター・コーツ、デイヴCridland、マーク・クリスピン、サイラスDaboo、Abhijitメノンセン、ティモ・シレーヌン、そしてエリック・バーガーの助けを認めます。特に、ピーター・コーツは、本文書にテキストや有益な提案の多くを貢献しました。
Various examples are copied from other RFCs.
種々の実施例は、他のRFCからコピーされます。
This document builds on one published and two unpublished drafts by the same authors.
この文書では、同じ著者によって発表され1および2つの未発表の草稿に基づいています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2177] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
[RFC2177] Leiba、B.、 "IMAP4 IDLEコマンド"、RFC 2177、1997年6月。
[RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998.
[RFC2342] Gahrns、M.とC.ニューマン、 "IMAP4名前空間"、RFC 2342、1998年5月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - VERSION 4rev1"、RFC 3501、2003年3月。
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.
[RFC4314]メルニコフ、A.、 "IMAP4アクセス制御リスト（ACL）拡張"、RFC 4314、2005年12月。
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[RFC4466]メルニコフ、A.およびC. Daboo、 "IMAP4 ABNFに収集された拡張機能"、RFC 4466、2006年4月。
[RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006.
[RFC4551]メルニコフ、A.とS.ホール、 "条件付きSTORE操作やクイックフラグの変更を再同期化のためのIMAP拡張"、RFC 4551、2006年6月。
[RFC5162] Melnikov, A., Cridland, D., and C. Wilson, "IMAP4 Extensions for Quick Mailbox Resynchronization", RFC 5162, March 2008.
[RFC5162]メルニコフ、A.、Cridland、D.、およびC.ウィルソン、 "クイックメールボックスの再同期のためのIMAP4拡張機能"、RFC 5162、2008年3月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
"構文仕様のための増大しているBNF：ABNF" [RFC5234]クロッカー、D.、エド、およびP. Overell、。、STD 68、RFC 5234、2008年1月。
[RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access Protocol version 4 - LIST Command Extensions", RFC 5258, June 2008.
[RFC5258] Leiba、B.とA.メルニコフ、 "インターネットメッセージアクセスプロトコルバージョン4 - LISTコマンドの拡張機能"、RFC 5258、2008年6月。
[RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, July 2008.
[RFC5267] Cridland、D.およびC.王、 "IMAP4のためのコンテキスト"、RFC 5267、2008年7月。
[RFC5423] Newman, C. and R. Gellens, "Internet Message Store Events", RFC 5423, Month 2009.
[RFC5423]ニューマン、C.とR. Gellens、 "インターネットメッセージストアイベント"、RFC 5423、月2009。
[RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464, February 2009.
[RFC5464] Daboo、C.、 "IMAPメタデータの拡張"、RFC 5464、2009年2月。
[RFC5228] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[RFC5228]ギュンター、P.、エド、およびT.ショーウォルター監督、エド、 "ふるい：メールフィルタリング言語"。。、RFC 5228、2008年1月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", Work in Progress, October 2008.
[EMAIL-ARCH]クロッカー、D.、 "インターネットメールのアーキテクチャ"、進歩、2008年10月の作業。
Authors' Addresses
著者のアドレス
Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr. 8 D-81671 Muenchen Germany
ARNT Gulbrandsenのオリックスメールシステム社Schweppermannstr。 8 D-81671ミュンヘン、ドイツ
EMail: arnt@oryx.com
メールアドレス：arnt@oryx.com
Curtis King Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
カーティスキングISODE株式会社5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国
EMail: Curtis.King@isode.com
メールアドレス：Curtis.King@isode.com
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
アレクセイ・メルニコフISODE株式会社5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国
EMail: Alexey.Melnikov@isode.com
メールアドレス：Alexey.Melnikov@isode.com