[要約] RFC 5551は、Lemonade通知アーキテクチャに関する規格であり、メールクライアントとサーバ間の通知の仕組みを定義しています。このRFCの目的は、メールクライアントが新しいメールの到着や変更を効率的に検出できるようにすることです。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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].
レモネード作業[レモネードプロファイル]は、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-Lemonade-arch]; Open Mobile Alliance（OMA）要件内（ "Inband"）およびof-of-of-of-IMAP（ "Outband"）サーバーからクライアント通知は[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 [レモネードプロファイル]を指します。
The target logical architecture for the LEMONADE Profile is described in the revised Lemonade Profile document [LEMONADE-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
図1：レモネードプロファイルアーキテクチャで定義されているフィルタリングメカニズム
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：デポジットフィルター：新しいメールのデポジットで実行されます。ふるいフィルター[ふるい]として定義できます。
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：フィルターを表示：クライアントにとって重要なメッセージを定義します。擬似仮想メールボックス[コンテキスト]として実装される場合があります。クライアントはこれを使用して、同期するメッセージを制限する場合があります。
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（ "Outband"）通知がいつ送信されるかを決定します。これらのフィルターは、メッセージストアまたは別の通知エンジンのいずれかで実装できます。
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-Variables] Sieve Extensionsが必要になる可能性があることに注意してください。
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：メールストアの内部の場合、これらは通常、ふるいを使用して実装されます。したがって、クライアントの変更には、ふるい管理プロトコルが使用されます。詳細については、[管理]を参照してください。Permailbox通知は、メールボックスへの配信に関する通知のためのプライマリシーブスクリプトの組み合わせ（例：FileINTO）と、[IMAPSieve]などのメールボックスへの送信などのメールごとのシーブスクリプトの組み合わせを使用して実装できます。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は、メールストアの一部（たとえば、Siveを使用する）と外部通知サーバーの両方として示されています。どちらのアプローチも使用できます。
+----------------+ +---------------+ +------------+
| 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.
In-IMAP（ "Inband"）の通知の場合、メールユーザーエージェント（MUA）（クライアント）がIDLE [IDLE]を発行するか、後継コマンドは[notify]を発行します。レモネード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（ "Outband"）の通知は、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".
「プッシュメール」の優れたユーザーエクスペリエンスでは、メールストアで「興味深い」イベントが発生した場合、クライアントが接続して再同期することができるように通知される必要があります。レモネードプロファイル[レモネードプロファイル]には、特に「外部通知」というタイトルのセクション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インターネットメールプロトコルにより、メールクライアントはメールシステム上の電子メールメッセージにアクセスして操作できます。定義と範囲により、これらのプロトコルは、メールボックスの状態が変更されたときにエンドユーザーに通知するオフラインメソッドを提供しません。どちらのプロトコルも、エンドユーザーのさまざまなメールボックス内のステータスを集約する方法を定義していません。
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アイドルを介して通知を受信する）、ユーザーまたはユーザーのメールクライアントに通知するメールシステムとは独立しています。このようなシステムは、ユーザーのメールスプールをチェックするログインシェル、ラップトップ/デスクトップの小さなクライアントが定期的にユーザーのメールサーバーを投票するなど、長年にわたって使用されてきました。
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拡張機能[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).
個別の通知システムは、エンドユーザーまたはクライアント通知からの状態変更イベント通知を分離し、メールシステムが前者を実行できるようにし、特別なシステム（存在を処理するものなど）が後者の責任を負います。メールシステムは、複数の通知配信プロトコルの代わりに1つの追加プロトコル（通知システムへの通信用）のみをサポートする必要があり、どのクライアントとどのユーザーがどのイベントに関心を持っているかを追跡する必要がないため、この分離はアーキテクチャリークリーンです。。また、電子メールだけでなく、あらゆるサービスに対して通知を生成することもできます。ただし、新しいサービス（通知システム）が必要であり、メールシステムは追加のプロトコルをサポートする必要があります（通知システムと通信）。
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.
メールシステムは、エンドユーザーのメールボックスで発生するイベントについて、State Changeイベント通知を通知システム（クライアントまたはエンドユーザーに通知する可能性がある）に送信します。そのような通知はそれぞれ、単一のメールボックスイベントを参照して、State Changeイベントと呼ばれます。
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.
State Changeイベントには、発生したメールボックスイベントに関するデータが含まれています。State Changeイベントは変更について説明しますが、通常、エンドユーザーまたはクライアントに通知をどのように、または通知するかを指定していません。これにより、エンドユーザーとクライアントの通知設定を通知サーバー内でのみ維持できます。
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接続がある場合はInband通知が使用されるため）。したがって、ユーザーがログアウトしたり、どのクライアントを使用したりするとき（この情報が利用可能な場合）、メールシステムが通知システムに通知できることが役立ちます。
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.
ほとんどのメール固有の場合、メールシステムは、たとえばSiveを使用してフィルタリング自体を実行します。
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-sequenceと呼ばれる）[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] Crispin、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.、ed。、Melnikov、A.、ed。、およびS. Maes、ed。、「多様なサービス環境（レモネード）プロファイルをサポートするインターネットメール」、RFC 5550、2009年8月。
[BIFF] Gellens, R., "Simple New Mail Notification", RFC 4146, August 2005.
[Biff] Gellens、R。、「Simple New Mail通知」、RFC 4146、2005年8月。
[CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, July 2008.
[コンテキスト] Cridland、D。およびC. King、「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] Melnikov、A。and S. Hole、「条件付き店舗運用またはクイックフラグの変更のための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月、Work in Progress。
[MANAGE-SIEVE] Melnikov, A., Ed., and T. Martin, "A Protocol for Remotely Managing Sieve Scripts", Work in Progress, September 2008.
[Manage-Sieve] Melnikov、A.、ed。、およびT. Martin、「シーブスクリプトのリモート管理のためのプロトコル」、2008年9月、進行中の作業。
[MSGEVENT] Gellens, R. and C. Newman, "Internet Message Store Events", RFC 5423, March 2009.
[Msgevent] Gellens、R。およびC. Newman、「インターネットメッセージストアイベント」、RFC 5423、2009年3月。
[IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
[アイドル] 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.、King、C。、およびA. Melnikov、「IMAP Notify Extension」、RFC 5465、2009年2月。
[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-Lemonade-arch] Burger、E。and G. Parsons、「レモネードアーキテクチャ - インターネットメールを使用したオープンモバイルアライアンス（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] Guenther、P.、ed。、およびT. Showalter、ed。、「Sive：An Email Filtering Language」、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] Melnikov、A.、ed。、Leiba、B.、Ed。、Segmuller、W。、およびT. Martin、「Sieve Emailフィルタリング：通知の拡張」、RFC 5435、2009年1月。
[SIEVE-VARIABLES] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008.
[Sieve-Variables] Homme、K。、「Sieve Emailフィルタリング：変数拡張」、RFC 5229、2008年1月。
[URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[Urlauth] Crispin、M。、「インターネットメッセージアクセスプロトコル（IMAP） - Urlauth Extension」、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.
このドキュメントのオリジナルの（そしてより長く、より詳細な）バージョンは、Oracle CorporationのStephane H. MaesとRay Cromwellによって執筆されました。
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.
現在および元の著者は、「サーバーからサーバー通知プロトコル要件」に関する元の研究の著者に感謝したいと考えています。その資料の一部は、特にGEV DeckTorの本文書に組み込まれています。
Author's Address
著者の連絡先
Randall Gellens, Editor QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA
Randall Gellens、編集者Qualcomm Incorporated 5775 Morehouse Drive San Diego、CA 92121 USA
EMail: rg+ietf@qualcomm.com