Network Working Group R. Gellens, Ed.
Request for Comments: 5551 Qualcomm
Category: Informational August 2009
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.
通知和过滤机制可以使电子邮件在移动设备和其他受限制的设备（如屏幕大小、内存、数据传输速率有限的设备）上更令人愉快。通知使客户机知道重大事件（如新邮件的到达），因此它可以做出反应（如立即获取感兴趣的邮件）。过滤将可见邮件减少为一组符合“有趣”标准的邮件。此功能包含在Lemonade（增强Internet电子邮件以支持不同的服务环境）工作组的目标中。
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和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。未获得控制此类材料版权的人员的充分许可，不得修改本文件
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标准过程之外，不得在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
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].
柠檬水工作[Lemonade-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-LEMONADE-ARCH]；[OMA-ME-RD]中列出了开放移动联盟（OMA）对IMAP内（“带内”）和IMAP外（“带外”）服务器到客户端通知的要求。
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].
柠檬水配置文件的目标逻辑架构在修订后的柠檬水配置文件文档[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 | | |
| | +-----+
+----------+
+--------------+
| |....
+=========| 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中，定义了四类过滤器：
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（“带外”）的通知。这些过滤器可以在消息存储中实现，也可以在单独的通知引擎中实现。
Note that when implementing DF or NF using Sieve, the 'enotify' [SIEVE-NOTIFY] and likely the 'variables' [SIEVE-VARIABLES] Sieve extensions might be needed.
请注意，当使用Sieve实现DF或NF时，可能需要'enotify'[Sieve-NOTIFY]和'variables'[Sieve-variables]筛扩展。
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实现；因此，筛选管理协议用于客户端修改。有关更多信息，请参阅[MANAGE-SIEVE]。每邮箱通知可以使用主筛选脚本（用于发送到邮箱的通知，例如FILEINTO）和每邮箱筛选脚本（例如[IMAP-SIFE]）的组合来实现。当NF位于通知服务器内时，它不在Lemonade的范围内。
* 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显示为邮件存储的一部分（例如，使用Sieve）和外部通知服务器。这两种方法都可以使用。
+----------------+ +---------------+ +------------+
| 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
+----------------+ +---------------+ +------------+
| 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（“带内”）通知，邮件用户代理（MUA）（客户端）发出IDLE[IDLE]或后续扩展命令NOTIFY[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发送给用户或客户端的消息。当针对用户时，它们是人类消耗品，旨在提醒用户。当定向到客户端时，它们是机器可消费的，并且可以由接收器以各种方式对其进行操作，例如，从邮件存储获取数据或重新同步一个或多个邮箱、更新内部状态信息以及向用户发出警报。
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.
这些状态更改通知被发送到通知系统，该系统可能会生成警报或通知，以便传递给一个或多个客户端或用户。
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 Internet邮件协议允许邮件客户端访问和处理邮件系统上的电子邮件。根据定义和范围，这些协议不提供在邮箱状态更改时通知最终用户的脱机方法。这两种协议都没有定义在最终用户的各个邮箱中聚合状态的方法。
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.
为了向最终用户提供统一通知和一个集中式消息等待指示器（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.
通知系统可以大致分为三种通用体系结构：外部智能客户端、内部通知和单独的通知机制。
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接收通知），并通知用户或用户的邮件客户端。多年来已经使用了许多这样的系统，包括检查用户邮件假脱机的登录shell、定期轮询用户邮件服务器的笔记本电脑/台式机微型客户端等。
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]的服务器组件，或者，对于更现代的系统，最近的通知筛扩展[SIVE-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还可用于通知[Sieve-NOTIFY]。由于许多邮件系统已经提供了Sieve支持，因此这是一个相当简单和快速的部署选项，可以提供一种有用的通知形式。
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节中描述的第三种体系结构类型）。通知系统与最终用户或设备（可能使用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)
+--------+ +--------+
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).
从Lemonade的观点来看，通常仅当客户端未连接到IMAP服务器时才需要IMAP外（带外）通知（因为存在IMAP连接时使用带内通知）。因此，邮件系统能够在用户登录或注销时通知通知系统，以及使用哪个客户端（当此信息可用时），这是很有帮助的。
When Sieve is used, the Sieve engine might have access to this information.
使用SIVE时，SIVE引擎可能可以访问此信息。
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].
通知的有效负载可能包括引用导致事件的消息的URL，可能使用URLAUTH[URLAUTH]。
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.
在大多数特定于邮件的情况下，邮件系统本身执行过滤，例如，使用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 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 35012003年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.，“支持多样化服务环境的互联网电子邮件（LEMONADE）概要”，RFC 55502009年8月。
[BIFF] Gellens, R., "Simple New Mail Notification", RFC 4146, August 2005.
[BIFF]Gellens，R.，“简单的新邮件通知”，RFC 41462005年8月。
[CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, July 2008.
[背景]Cridland，D.和C.King，“IMAP4的背景”，RFC 52672008年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.和S.Hole，“条件存储操作或快速标志更改再同步的IMAP扩展”，RFC 45512006年6月。
[IMAP-SIEVE] Leiba, B., "Support for Sieve in Internet Message Access Protocol (IMAP4)", Work in Progress, February 2008.
[IMAP-SIFE]Leiba，B.，“互联网消息访问协议（IMAP4）中对SIFE的支持”，正在进行的工作，2008年2月。
[MANAGE-SIEVE] Melnikov, A., Ed., and T. Martin, "A Protocol for Remotely Managing Sieve Scripts", Work in Progress, September 2008.
[管理筛]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 54232009年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.
[通知]Gulbrandsen，A.，King，C.和A.Melnikov，“IMAP通知扩展”，RFC 54652009年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.和G.Parsons，“柠檬水体系结构-支持使用互联网邮件的开放移动联盟（OMA）移动电子邮件（MEM）”，RFC 54422009年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.，“SIEVE:电子邮件过滤语言”，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电子邮件过滤：通知扩展”，RFC 54352009年1月。
[SIEVE-VARIABLES] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008.
[SIEVE-VARIABLES]Homme，K.，“SIEVE电子邮件过滤：变量扩展”，RFC 52292008年1月。
[URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[URLAUTH]Crispin，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.
本文档的原始版本（更长更详细）由甲骨文公司的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，编辑高通公司5775 Morehouse Drive San Diego，CA 92121美国
EMail: rg+ietf@qualcomm.com
EMail: rg+ietf@qualcomm.com