Network Working Group R. Gellens, Ed.
Request for Comments: 5551 Qualcomm
Category: Informational August 2009
Lemonade Notifications Architecture
Abstract
抽象
Notification and filtering mechanisms can make email more enjoyable on mobile and other constrained devices (such as those with limited screen sizes, memory, data transfer rates, etc.). Notifications make the client aware of significant events (such as the arrival of new mail) so it can react (such as by fetching interesting mail immediately). Filtering reduces the visible mail to a set of messages that meet some criteria for "interesting". This functionality is included in the goals of the Lemonade (Enhancements to Internet email to Support Diverse Service Environments) Working Group.
通知およびフィルタリングメカニズムは、モバイルおよび他の制約（例えば、限られた画面サイズを有するものなど、メモリ、データ転送速度、等）のデバイス上の電子メールをより楽しいものにすることができます。通知は、それが（例えばすぐに興味深いメールを取得することによってのように）反応することができるように（たとえば、新しいメールの到着など）の重要なイベントのクライアントに認識させます。フィルタリングは、「面白い」のためのいくつかの基準を満たすメッセージのセットに目に見えるメールを低減します。この機能は、ワーキンググループ（インターネット電子メールの機能強化は、多様なサービス環境をサポートする）レモネードの目標に含まれています。
This document also discusses the use of server-to-server notifications, and how server to server notifications fit into an architecture that provides server to client notifications.
また、このドキュメントでは、サーバー間の通知の使用について説明し、どのようにサーバーのサーバーの通知には、クライアントの通知にサーバーを提供アーキテクチャに適合します。
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Notifications Logical Architecture and LEMONADE Profile .........2
3. Event-Based Synchronization .....................................4
4. Push Email ......................................................5
5. Server-to-Server Notifications Rationale ........................5
5.1. Notifications Discussion ...................................6
5.2. Server to Server Notifications Scope .......................7
5.3. Basic Operation ............................................8
5.4. Event Order ...............................................10
5.5. Reliability ...............................................10
6. Security Considerations ........................................10
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
8. Contributors ...................................................12
The Lemonade work [LEMONADE-PROFILE] identified a need to provide notification and filtering mechanisms for use with IMAP [IMAP].
レモネードワーク[レモネード-PROFILE]は[IMAP] IMAPで使用するための通知およびフィルタリングメカニズムを提供する必要があると指摘しました。
In addition, external groups that make use of IETF work also expressed such requirements (see, for example, [OMA-LEMONADE-ARCH]; Open Mobile Alliance (OMA) requirements for within-IMAP ("inband") and out-of-IMAP ("outband") server to client notifications are listed in [OMA-ME-RD]).
また、IETFワークを利用する外部グループはまた、[OMA-レモネード-ARCH]例えば、このような要件（参照、発現、オープン・モバイル・アライアンス（OMA）の要件内-IMAP（「インバンド」）とアウトオブクライアントの通知にIMAP（ "帯域外"）サーバーは、[OMA-ME-RD]）に記載されています。
Within this document, the terms "Lemonade Profile" and "Lemonade" generally refer to the revised Lemonade Profile document, RFC 5550 [LEMONADE-PROFILE].
この文書の中で、用語「レモネードプロファイル」と「レモネード」は、一般的に改訂されたレモネードのプロフィール文書に、RFC 5550 [レモネード-PROFILE]を参照してください。
The target logical architecture for the LEMONADE Profile is described in the revised Lemonade Profile document [LEMONADE-PROFILE].
レモネードプロフィールターゲット論理アーキテクチャは、改訂されたレモネードプロフィール文書[レモネード-PROFILE]に記載されています。
Figure 1 illustrates how notification and filtering fit in the context of Lemonade.
図1は、レモネードの文脈でどのように通知し、フィルタリングのフィット感を示しています。
+--------------+
| |....
+=========| Notification |.NF.
! | Server |....
! | |^ ^ NOTE:
! +--------------+! ! NF is either in
Notif-! ! ! Notification
ications! Filter Protocol ! ! Server or IMAP
Protocol! !======================! ! Store, not both
! ! !
! ! Filter Protocol ....
! !=====================>. . +---------+
! ! +-----------.NF.---+ | |
V ! | .... | | MTA |
+-----+ IMAP |.... | LMTP/ |.... |<==SMTP
| | <======> |.VF. IMAP ....| SMTP |.AF. |
| MUA |\ ME-2a |.... Store .DF.|<=======|.... |
| | \ | ....| | |
+-----+ \ +------------------+ +---------+
\ !
\ !URLAUTH
SUBMIT\ !
\ +----v-----+
\ | | +-----+
\ | LEMONADE | SMTP | |==>SMTP
===>| Submit |===============>| MTA |
ME-2b | Server | | |
| | +-----+
+----------+
Figure 1: Filtering Mechanism Defined in
Lemonade Profile Architecture
In Figure 1, four categories of filters are defined:
図1では、フィルタの4つのカテゴリが定義されています。
1. AF: Administrative Filters: Created and maintained by mail administration. AF are typically not configured by the user and are used to apply policies, content filtering, virus protection, spam filtering, etc.
1. AF：行政フィルタ：メール投与により作成および維持。 AFは、典型的には、ユーザによって構成されていないとの方針、コンテンツフィルタリング、ウイルス対策、スパムフィルタリングなどを適用するために使用されています
2. DF: Deposit Filters: Executed on deposit of new mail. Can be defined as Sieve filters [SIEVE].
2. DF：デポジットフィルタ：新しいメールの預金に実行されます。ふるいフィルター[SIEVE]として定義することができます。
3. VF: View Filters: Define which messages are important to a client. May be implemented as pseudo-virtual mailboxes [CONTEXT]. Clients may use this to restrict which messages they synchronize.
3. VF：ビューフィルタ：クライアントにとって重要であるメッセージを定義します。擬似仮想メールボックス[CONTEXT]として実現することができます。クライアントは、同期するメッセージを制限するために、これを使用することができます。
4. NF: Notification Filters: Determine when out-of-IMAP ("outband") notifications are sent to the client. These filters can be implemented either in the message store or in a separate notifications engine.
4. NF：通知フィルタ：アウト・オブ・IMAP（「帯域外」）の通知がクライアントに送信されたときに決定します。これらのフィルタは、メッセージストアまたは別個通知エンジンのいずれかで実施することができます。
Note that when implementing DF or NF using Sieve, the 'enotify' [SIEVE-NOTIFY] and likely the 'variables' [SIEVE-VARIABLES] Sieve extensions might be needed.
ふるいを使用してDFまたはNFを実装する場合は、「enotify」[SIEVE-NOTIFY]、おそらく「変数」[SIEVE-変数]ふるいの拡張が必要となる可能性があることに注意してください。
The filters are manageable by the client as follows:
次のようにフィルターは、クライアントで管理されています。
* NF and DF: When internal to the mail store, these are typically implemented using Sieve; hence, a Sieve management protocol is used for client modifications. See [MANAGE-SIEVE] for more information. Per-mailbox notifications might be implemented using a combination of a primary Sieve script for notifications on delivery into a mailbox (e.g., FILEINTO) and a per-mailbox Sieve script such as [IMAP-SIEVE] for transfers into a mailbox. When the NF is within a notification server, it is out of scope of Lemonade.
* NFとDF：メールストアの内部が、これらは一般的にふるいを使用して実装されています。従って、ふるい管理プロトコルは、クライアント変更のために使用されます。詳細については、[-SIEVEを管理]を参照してください。メールボックスごとの通知がメールボックスに転送するためのメールボックス（例えば、のfileinto）など[IMAP-SIEVE]としてごとのメールボックスSieveスクリプトへの送達に通知するための主要なSieveスクリプトの組み合わせを用いて実現されるかもしれません。 NFは、通知サーバ内にある場合、それはレモネードの範囲外です。
* VF: via pseudo-virtual mailboxes as defined in [CONTEXT].
* VF：擬似仮想メールボックスを介して[コンテキスト]で定義されます。
In Figure 1, the NF are shown both as part of the mail store (for example, using Sieve) and as an external notification server. Either approach can be used.
図1において、NF（例えば、篩を用いて）メールストアの一部としての両方を示し、外部通知サーバの通りです。どちらのアプローチが使用することができます。
+----------------+ +---------------+ +------------+
| COMPLETE | (VF) | VIEW | (NF) | PUSH |
| REPOSITORY | View | REPOSITORY |Notification| REPOSITORY |
| |Filters| | Filters | |
| all email | | email to be | | important |
| in the account |=======|synched by the |=====<?>====| email / |
| | | mobile client | | | events |
| | | (CONTEXT) | | | |
+----------------+ +---------------+ | +------------+
| |
IDLE / |
NOTIFY Out-of-IMAP
| Notifications
| |
V V
Figure 2: Filters and Repositories
図2：フィルタおよびリポジトリ
For in-IMAP ("inband") notifications, the Mail User Agent (MUA) (client) issues IDLE [IDLE], or the successor extension command NOTIFY [NOTIFY]; the LEMONADE IMAP server sends notifications as unsolicited responses to the client.
中-IMAP（ "インバンド"）の通知については、メールユーザエージェント（MUA）（クライアント）の問題IDLE [IDLE]、または後継拡張コマンドは、[通知] NOTIFY。 LEMONADE IMAPサーバは、クライアントへの迷惑応答として通知を送信します。
Out-of-IMAP ("outband") notifications are messages sent to the user or client not through IMAP. When directed at the user, they are human-consumable and intended to alert the user. When directed at the client, they are machine-consumable and may be acted upon by the receiver in various ways, for example, fetching data from the mail store or resynchronizing one or more mailboxes, updating internal state information, and alerting the user.
アウトオブIMAP（「帯域外」）の通知がないIMAPを介してユーザまたはクライアントに送信されたメッセージです。ユーザーに向けたとき、彼らは、人間の消耗品とユーザーに警告することを目的としています。クライアントに向けられたとき、それらは機械消耗品であり、メール・ストアからデータをフェッチするか、1つまたは複数のメールボックスを再同期、内部状態情報を更新し、ユーザに警告、例えば、様々な方法で受信機によって作用することができます。
A good user experience of "push email" requires that when "interesting" events occur in the mail store, the client is informed so that it can connect and resynchronize. The Lemonade Profile [LEMONADE-PROFILE] contains more information, especially in Section 5.4.2, titled "External Notifications".
「プッシュ型電子メール」の優れたユーザーエクスペリエンスは「興味深い」のイベントがメールストアで発生した場合、それは接続して再同期することができるように、クライアントに通知されている必要があります。レモネードプロフィール[レモネード-PROFILE]は「外部通知」と題し、特に5.4.2項でより多くの情報を、含まれています。
With server-to-server notifications, a mail system generates event notifications. These notifications describe mailbox state change events such as arrival of a new message, mailbox full, and so forth.
サーバーからサーバーへの通知で、メールシステムは、イベント通知を生成します。これらの通知は、このような等々、新しいメッセージの到着、完全なメールボックス、およびとしてメールボックスの状態変更イベントを記述する。
See [MSGEVENT] for a list of such events.
このようなイベントのリストについては、[MSGEVENT]を参照してください。
These state change notifications are sent to a notification system, which may generate alerts or notifications for delivery to one or more clients or the user.
これらの状態変更通知は、1つ以上のクライアントへの配信やユーザーのアラートや通知を生成する通知システムに送信されます。
Server-to-server notifications allow the mail system to generate end user or client notifications without needing to keep track of notification settings for users or clients; the notification system maintains notification preferences for clients and users.
サーバからサーバへの通知は、メールシステムは、ユーザーまたはクライアントの通知設定を追跡するために必要とせず、エンドユーザーやクライアント通知を生成することができます。通知システムは、クライアントとユーザーの通知設定を維持します。
Using server-to-server notifications, the mail system can provide the end user with a unified notification experience (the same look and feel for accounts at all messaging systems, such as email and voicemail), while allowing smooth integration of additional messaging systems.
追加のメッセージングシステムのスムーズな統合を可能にしながら、サーバーからサーバーへの通知を使用して、メールシステムは、統一された通知の経験で（同じ表情をして、電子メールやボイスメールなど、すべてのメッセージングシステムでアカウントのために感じる）、エンドユーザに提供することができます。
The POP3 and IMAP4 Internet mail protocols allow mail clients to access and manipulate electronic mail messages on mail systems. By definition and scope, these protocols do not provide off-line methods to notify an end user when the mailbox state changes. Nor does either protocol define a way to aggregate the status within the end user's various mailboxes.
POP3およびIMAP4インターネットメールプロトコルは、メールクライアントがメールシステムに電子メールメッセージにアクセスして操作することができます。定義と範囲によって、これらのプロトコルは、時にメールボックスの状態が変化し、エンドユーザーに通知するオフライン方法を提供していません。 NORどちらのプロトコルは、エンドユーザーの様々なメールボックス内のステータスを集計する方法を定義しません。
The desire for this functionality is obvious. For example, from the very early days of electronic mail, various notifications mechanisms have been used, including login shell checks, and simple hacks such as [BIFF].
この機能のための欲求は明らかです。例えば、電子メールの非常に初期の頃から、様々な通知メカニズムは、ログインシェルの確認、および、そのような[BIFF]などの簡単なハックを含め、使用されています。
To provide an end user with unified notifications and one centralized Message-Waiting Indicator (MWI), notification mechanisms are needed that aggregate the information of all the events occurring on the end user's different messaging systems.
統一された通知と1つの集中メッセージ待機インジケータ（MWI）をエンドユーザに提供するために、通知メカニズムは、エンドユーザーのさまざまなメッセージングシステムで発生するすべてのイベントの情報を集約が必要とされています。
Server-to-server notifications allow the messaging system to send state change events to the notification system when something happens in or to an end user's mailbox.
サーバからサーバへの通知は何かが中またはエンドユーザーのメールボックスに発生したときに、メッセージングシステムは、通知システムに状態変更イベントを送信することができます。
Notification systems can be broadly grouped into three general architectures: external smart clients, intrinsic notification, and separate notification mechanisms.
外部スマートクライアント、固有の通知、及び別通知メカニズム：通知システムは、大きく3つの一般的なアーキテクチャに分類することができます。
External smart clients are agents independent of the mail system that periodically check mailbox state (or receive notifications, for example, via IMAP IDLE) and inform the user or the user's mail client. Many such systems have been used over the years, including login shells that check the user's mail spool, laptop/desktop tiny clients that periodically poll the user's mail servers, etc.
外部スマートクライアントは、定期的に（IMAP IDLEを経由して、例えば、または通知を受信）メールボックスの状態を確認し、メールシステムの独立した薬剤で、ユーザーまたはユーザーのメールクライアントに通知します。多くのそのようなシステムは、ユーザのメールスプールをチェックするログインシェル、定期的にユーザーのメールサーバーをポーリングし、ラップトップ/デスクトップ小さなクライアントなどを含め、長年にわたって使用されています
Intrinsic notification is any facility within a mail system that generates notifications, for example, the server component of [BIFF], or, for more modern systems, the recent Sieve extensions for notifications [SIEVE-NOTIFY].
固有の通知は、すべての例の通知を生成し、メールシステム内の施設、[BIFF]のサーバーコンポーネント、または、より近代的なシステムで、通知のための最近のふるい拡張[SIEVE-NOTIFY]のためです。
Separate notification systems decouple the state change event notification from the end user or client notification, allowing a mail system to do the former, and specialized systems (such as those that handle presence) to be responsible for the latter. This separation is architecturally cleaner, since the mail system only needs to support one additional protocol (for communication to the notification system) instead of multiple notification delivery protocols, and does not need to keep track of which clients and which users are interested in which events. It also allows notifications to be generated for any service, not just electronic mail. However, it requires a new service (the notification system) and the mail system needs to support an additional protocol (to communicate with the notification system).
個別の通知システムは、メールシステムは、後者の原因であるとかつての、そして専門的なシステムを（そのような存在を扱うものなど）を実行することができ、エンドユーザーやクライアント通知からの状態変化イベントの通知を切り離します。メールシステムが唯一の代わりに、複数の通知配信プロトコルの（通知システムへの通信のための）一つの追加のプロトコルをサポートする必要があり、そのクライアントを追跡する必要はありません。また、どのユーザーがどのイベントに関心があるので、この分離は、アーキテクチャクリーナーです。また、通知が任意のサービスだけでなく、電子メールのために生成することができます。しかし、それは新しいサービス（通知システム）を必要とメールシステムは、（通知システムと通信するために）追加のプロトコルをサポートする必要があります。
In addition to any external notification mechanisms, Sieve can be used for notifications [SIEVE-NOTIFY]. Since many mail systems already provide Sieve support, this can be a fairly easy and quick deployment option to provide a useful form of notifications.
任意の外部通知メカニズムに加えて、ふるいは[SIEVE-NOTIFY]通知のために使用することができます。多くのメールシステムが既にふるいサポートを提供するので、これは、通知の有用な形態を提供するために、非常に簡単かつ迅速な展開オプションをすることができます。
For the purposes of the Lemonade work, the scope of server-to-server notifications is limited to communications between the mail system and the notification system (the third architectural type described in Section 5.1). Communication between the notification system and the end user or devices (which might use SMS, WAP Push, instant messaging, etc.) is out of scope. Likewise, the scope generally presumes a security relationship between the mail system and the notification system. Thus, the security relationship then becomes the responsibility of the notification system. However, the specifics of security, trust relationships, and related issues depend on the specifics of both server-to-server notifications and notification systems.
レモネード作業の目的のために、サーバからサーバへの通知の範囲は、メールシステムと通知システム（セクション5.1で説明した第3の建築タイプ）との間の通信に限定されます。 （SMS、WAPプッシュ、インスタントメッセージングなどを使用する場合があります）通知システムおよびエンドユーザやデバイス間の通信は、範囲外です。同様に、スコープは、一般的に、メールシステムおよび通知システム間のセキュリティ関係を前提とします。このように、セキュリティの関係は、通知システムの責任となります。しかし、セキュリティ、信頼関係、および関連する問題の詳細は、サーバからサーバへの通知や通知システムの両方の仕様に依存します。
Figure 3 shows the context of server-to-server notifications; only the left side is in scope for Lemonade:
図3は、サーバからサーバへの通知の内容を示す図です。左側のみがレモネードのためのスコープ内にあります：
+--------+ +--------+
New | |_ | SMS |
Message | Mail | \ |Gateway |
-------> |Server 1| \ __| |
+--------+ \ / +--------+
^ \ /
| \ / ^
| \ +--------------+ / | +--------+
+--------+ | \ | | / | | MWI |
Read | Voice | | -| Notification |/ | |Gateway |
Message | Mail |-------->| Server |------->| |
-------> | Server | | ^ __| |\ ^ | +--------+
+--------+ | | / |(out of scope)| \ | |
| |/ | | \| |
| / ^ +--------------+ ^ \ |
|/| | \ | |\|
+--------+ / | | \ | | \ +--------+
Mailbox | | /| | | \| | |\ | WAP |
Full | Mail |/ | | | ^ \ | | \| Push |
-------> |Server 2| | | | | |\| | |Gateway |
+--------+ | | | | | \ | +--------+
| | | | | |\|
| | | | | | \
| | | | | | |\ +--------+
| | | | | | | \| IM |
| | | | | | | |Gateway |
| | | | | | | | |
| | | | | | | +--------+
| | | | | | |
| | | | | | |
Server-to- OTHER
Server PROTOCOLS
Notifications (out of scope)
(in scope)
Figure 3: Scope of Server-to-Server Notifications
図3：サーバ間の通知の対象範囲
The mail system sends state change event notifications to the notification system (which in turn might notify a client or end user) for events that occur in the end user's mailboxes. Each such notification, referring to a single mailbox event, is called a state change event.
メールシステムは、エンドユーザーのメールボックスで発生するイベントのために（順番にクライアントやエンドユーザーに通知するかもしれない）通知システムに状態変化イベント通知を送信します。それぞれのそのような通知は、単一のメールボックスのイベントを参照して、状態変化イベントと呼ばれています。
The state change event contains data regarding the mailbox event that has occurred. The state change event describes the change, but normally does not specify how or if the end user or client is notified; this allows the end user and client notification preferences to be maintained only within the notification server.
状態変更イベントが発生したメールボックスイベントに関するデータが含まれています。状態変更イベントは、変更を説明しますが、通常はエンドユーザーやクライアントが通知された方法かどうかを指定しません。これは、エンドユーザーとクライアント通知設定のみ通知サーバ内に維持することができます。
From the Lemonade viewpoint, out-of-IMAP (outband) notifications are usually desired only when the client is not connected to the IMAP server (since inband notifications are used when there is an IMAP connection). Thus, it is helpful for the mail system to be able to inform the notification system when the user logs in or out, and which client is used (when this information is available).
（IMAP接続がある場合、帯域内通知が使用されているため）、クライアントは、IMAPサーバに接続されていない場合にのみ、レモネードの観点から、アウトオブIMAP（帯域外）通知が通常望まれます。したがって、クライアントユーザーがログインするか、アウト、および使用されている場合（この情報が利用可能な場合）、メールシステムは、通知システムに通知できるようにするために有用です。
When Sieve is used, the Sieve engine might have access to this information.
ふるいを使用する場合は、ふるいエンジンは、この情報にアクセスできる場合があります。
A message is generated by the message store as a result of a state change event. This message may be delivered to the end user, a client, or to an external notification server that might deliver an equivalent message to the user or to a client.
メッセージは、状態変化事象の結果としてメッセージストアによって生成されます。このメッセージは、エンドユーザー、クライアント、またはユーザーまたはクライアントと同等のメッセージを配信する可能性がある外部の通知サーバに配信することができます。
Within the context of the Lemonade Profile (Figure 1), the event is filtered by NF. That is, the Notification Filters logically determine which state change events cause notification to the user or client.
レモネードプロフィール（図1）のコンテキスト内で、イベントは、NFによってフィルタリングされます。これは、通知フィルタは、論理的に変更イベントは、ユーザーやクライアントへの通知を引き起こした状態を判断しています。
Notifications allow for a rich end user experience. This might include conveying mailbox status, new message attributes, etc., to the user or client independent of the client's connection to the mail store.
通知は豊富なエンドユーザーエクスペリエンスを可能にします。これは、メールストアへのクライアントの接続のユーザーやクライアントの独立への運搬などのメールボックスの状態を、新しいメッセージ属性、などがあります。
Notifications also allow for different Message Waiting Indicator (MWI) behaviors (e.g., turn MWI indication off after all the messages in all the end user's mailboxes have been read, should such an unlikely thing occur in the real world).
通知はまた、異なるメッセージ待機インジケータ（MWI）の行動（例えば、そのような可能性は低いものは現実の世界で起こるべきで、読み込まれたすべてのエンドユーザーのメールボックス内のすべてのメッセージの後にMWI表示をオフにする）を可能とします。
The payload of a notification might include a URL referring to the message that caused the event, possibly using URLAUTH [URLAUTH].
通知のペイロードは、おそらくURLAUTH [URLAUTH]を使用して、イベントを発生させたメッセージを参照するURLが含まれる場合があります。
As state change events occur in the mail store, they are filtered, which is to say matched against client or user preferences. As a result, a notification may or may not be generated for delivery to the user or client.
状態変更イベントは、メールストアで発生すると、それらはクライアントやユーザーの好みに対してマッチと言うことである、フィルタリングされます。結果として、通知は、またはユーザまたはクライアントへの配信のために生成してもしなくてもよいです。
In the most general case, the mail system sends bulk state change events to an external notification server, and it is the notification server that filters the events by matching against the user's or client's preferences.
最も一般的な場合には、メールシステムは、外部の通知サーバにバルク状態変更イベントを送信し、それがユーザーまたはクライアントの好みに対して照合することによって、イベントをフィルタリングし、通知サーバです。
In the most mail-specific case, the mail system performs the filtering itself, for example, using Sieve.
最もメール特定の場合では、メールシステムは、篩を用いて、例えば、フィルタ自体を行います。
For the Lemonade Profile, the event order is generally not important. By including information such as the modification sequence identifier (called a modseq or mod-sequence) [CONDSTORE] in notifications, the receiving client can quickly and easily determine if it has already processed the triggering event (for example, if a notification arrives out of order, or if the client has resynchronized since the event was generated).
レモネードのプロフィールについては、イベントの順序は、一般的に重要ではありません。通知が外到着した場合、それは既に、例えば（トリガイベントを処理した場合、このような通知に（modseqまたはMOD-配列と呼ばれる）修飾シーケンス識別子[CONDSTORE]などの情報を含むことによって、受信したクライアントは、迅速かつ容易に決定することができますため、またはクライアント）は、イベントが生成されてから再同期している場合。
For generic server-to-server notifications, the order is likely to matter and the mail system needs to provide notifications to the notification system in the order that they occur.
一般的なサーバー間の通知の場合、順序は関係する可能性があるとのメールシステムは、彼らが起こるようにするために、通知システムに通知を提供する必要があります。
For the Lemonade Profile, lost or delayed notifications to the client are tolerated. A client can resynchronize its state (including that reported by any missing events) when it next connects to the server.
レモネードのプロフィールについては、クライアントへの失われたまたは遅延通知が許容されています。それは次のサーバに接続するとき、クライアントはその状態（欠落しているイベントによって報告されたものを含む）を再同期することができます。
For generic server-to-server notifications, it is assumed that the data in a state change event is important, and therefore a high level of reliability is needed between the mail system and any external notification systems.
一般的なサーバー間の通知のためには、状態変更イベントのデータが重要であるため、信頼性の高いレベルは、メールシステムや外部通知システム間で必要とされているものとします。
Notification content (payload) needs to be protected against eavesdropping and alteration when it contains specific information from messages, such as the sender.
通知内容（ペイロード）は、例えば、送信者などのメッセージから特定の情報が含まれている場合、盗聴や改ざんから保護する必要があります。
Even when the content is trivial and does not contain privacy-sensitive information, guarding against denial-of-service attacks may require authentication or verification of the notification sender.
内容は自明であると通知送信者の認証や検証を必要とするかもしれないサービス拒否攻撃に対する保護、プライバシー、機密情報が含まれていない場合でも。
Protocols that manipulate filters need mechanisms to protect against modification by, as well as disclosure to, unauthorized entities. For example, a malicious entity might try to delete notifications the user wants, or try to flood the target device with notifications to incur usage charges, or prevent normal use. In addition, the filters themselves might contain sensitive information or reveal interpersonal or inter-organizational relationships, as well as email addresses.
フィルタを操作するプロトコルは、不正なエンティティにによって変更から保護するだけでなく、開示するためのメカニズムを必要としています。たとえば、悪意のあるエンティティは、ユーザーが望んでいるの通知を削除しようとする、または使用料が発生、または通常の使用を防止するために、通知をターゲットデバイスをあふれしようとするかもしれません。また、フィルター自体は機密情報が含まれているか、対人や、組織間の関係だけでなく、電子メールアドレスを明らかにするかもしれません。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[LEMONADE-PROFILE] Cridland, D., Ed., Melnikov, A., Ed., and S. Maes, Ed., "The Internet Email to Support Diverse Service Environments (Lemonade) Profile", RFC 5550, August 2009.
[LEMONADE-PROFILE] Cridland、D.、エド。、メルニコフ、A.、エド。、およびS.マース、エド。、 "インターネット電子メールは、多様なサービス環境（レモネード）プロファイルをサポートするために"、RFC 5550、2009年8月。
[BIFF] Gellens, R., "Simple New Mail Notification", RFC 4146, August 2005.
[BIFF] Gellens、R.、 "シンプル新着メールの通知"、RFC 4146、2005年8月。
[CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, July 2008.
[CONTEXT] Cridland、D.およびC.王、 "IMAP4のためのコンテキスト"、RFC 5267、2008年7月。
[CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006.
[CONDSTORE]メルニコフ、A.とS.ホール、 "条件付きSTORE操作やクイックフラグの変更を再同期化のためのIMAP拡張"、RFC 4551、2006年6月。
[IMAP-SIEVE] Leiba, B., "Support for Sieve in Internet Message Access Protocol (IMAP4)", Work in Progress, February 2008.
[IMAP-SIEVE] Leiba、B.、 "インターネットメッセージアクセスプロトコル（IMAP4）でふるいのサポート"、進歩、2008年2月に作業。
[MANAGE-SIEVE] Melnikov, A., Ed., and T. Martin, "A Protocol for Remotely Managing Sieve Scripts", Work in Progress, September 2008.
[MANAGE-SIEVE]メルニコフ、A.編、およびT.マーティン、 "リモート管理Sieveスクリプトのための議定書"、進歩、2008年9月の作業。
[MSGEVENT] Gellens, R. and C. Newman, "Internet Message Store Events", RFC 5423, March 2009.
[MSGEVENT] Gellens、R.とC.ニューマン、 "インターネットメッセージストアイベント"、RFC 5423、2009年3月。
[IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
[IDLE] Leiba、B.、 "IMAP4 IDLEコマンド"、RFC 2177、1997年6月。
[NOTIFY] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP NOTIFY Extension", RFC 5465, February 2009.
[NOTIFY] Gulbrandsenのは、A.、キング、C.、およびA.メルニコフは、RFC 5465、2009年2月、 "IMAPは、拡張子をNOTIFY"。
[OMA-LEMONADE-ARCH] Burger, E. and G. Parsons, "LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail", RFC 5442, March 2009.
[OMA-レモネード-ARCH]バーガー、E.およびG.パーソンズ、 "レモネードアーキテクチャ - サポートするオープン・モバイル・アライアンス（OMA）モバイルメール（MEM）インターネットメールを使用する"、RFC 5442、2009年3月。
[OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document, (Work in progress). http://www.openmobilealliance.org/
[OMA-ME-RD]オープン・モバイル・アライアンスモバイルメール要件ドキュメント、（作業中）。 http://www.openmobilealliance.org/
[SIEVE] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[SIEVE]ギュンター、P.、エド、およびT.ショーウォルター監督、エド、 "ふるい：メールフィルタリング言語"。。、RFC 5228、2008年1月。
[SIEVE-NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. Martin, "Sieve Email Filtering: Extension for Notifications", RFC 5435, January 2009.
。。[SIEVE-NOTIFY]メルニコフ、A.、エド、Leiba、B.、エド、Segmuller、W.、およびT.マーティン、 "ふるい電子メールフィルタリング：通知のための拡張"、RFC 5435、2009年1月。
[SIEVE-VARIABLES] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008.
[SIEVE-変数]オム、K.、 "ふるいメールフィルタリング：変数の拡張"、RFC 5229、2008年1月。
[URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[URLAUTH]クリスピン、M.、 "インターネットメッセージアクセスプロトコル（IMAP） - URLAUTH拡張"、RFC 4467、2006年5月。
The original (and longer and more detailed) version of this document was authored by Stephane H. Maes and Ray Cromwell of Oracle Corporation.
このドキュメントのオリジナル（と長く、より詳細な）バージョンは、ステファン・H.マースと、Oracle Corporationのレイ・クロムウェルによって作成されました。
The current and original authors want to thank all who have contributed key insight in notifications and filtering and have authored specifications or documents used in this document.
現在、元の著者は、通知やフィルタリングの重要な洞察力を貢献してきたし、この文書で使用されている仕様や文書を執筆してきたすべての人に感謝したいと思います。
The current and original authors want to thank the authors of the original work on "Server To Server Notification Protocol Requirements", some of whose material has been incorporated in the present document, in particular, Gev Decktor.
現在、オリジナルの著者は、その材料のいくつかは、具体的には、本文書に組み込まれている、ゲブDecktor「サーバ通知プロトコル要件にサーバー」のオリジナル作品の作者に感謝したいと思います。
Author's Address
著者のアドレス
Randall Gellens, Editor QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA
ランドールGellens、エディタQUALCOMM Incorporatedの5775モアハウスドライブサンディエゴ、CA 92121 USA
EMail: rg+ietf@qualcomm.com
メールアドレス：rg+ietf@qualcomm.com