Network Working Group J. Wong, Ed.
Request for Comments: 4416 Nortel Networks
Category: Informational February 2006
Network Working Group J. Wong, Ed.
Request for Comments: 4416 Nortel Networks
Category: Informational February 2006
Goals for Internet Email to Support Diverse Service Environments
支持多样化服务环境的Internet电子邮件目标
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) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document is a history capturing the background, motivation and thinking during the LEMONADE definition and design process.
在设计过程中，捕获柠檬水的背景和动机。
The LEMONADE Working Group -- Internet email to support diverse service environments -- is chartered to provide enhancements to Internet mail to facilitate its use by more diverse clients. In particular, by clients on hosts not only operating in environments with high latency/bandwidth-limited unreliable links but also constrained to limited resources. The enhanced mail must be backwards compatible with existing Internet mail.
LEMONADE工作组——支持多样化服务环境的互联网电子邮件——被特许为互联网邮件提供增强功能，以方便更多不同的客户使用。特别是，主机上的客户端不仅在高延迟/带宽受限的不可靠链路环境中运行，而且还受限于有限的资源。增强邮件必须与现有Internet邮件向后兼容。
The primary motivation for this effort is -- by making Internet mail protocols richer and more adaptable to varied media and environments -- to allow mobile handheld devices tetherless access to Internet mail using only IETF mail protocols.
这项工作的主要动机是——通过使Internet邮件协议更丰富、更适合各种媒体和环境——允许移动手持设备仅使用IETF邮件协议无绳访问Internet邮件。
The requirements for these devices drive a discussion of the possible protocol enhancements needed to support multimedia messaging on limited-capability hosts in diverse service environments. A list of general principles to guide the design of the enhanced messaging protocols is documented. Finally, additional issues of providing seamless service between enhanced Internet mail and the existing separate mobile messaging infrastructure are briefly listed.
对这些设备的要求促使人们讨论在不同服务环境中，在功能有限的主机上支持彩信可能需要的协议增强功能。记录了指导增强消息传递协议设计的一般原则列表。最后，简要列出了在增强的Internet邮件和现有的独立移动消息基础设施之间提供无缝服务的其他问题。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 6
3. Messaging Terminology and Simple Model (Client-to-Server
Aspect Only) . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Messaging Transaction Models . . . . . . . . . . . . . . . 6
3.2. Mobile Messaging Transactions . . . . . . . . . . . . . . 7
3.2.1. Submission . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Notification . . . . . . . . . . . . . . . . . . . . . 7
3.2.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . 8
4. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Existing Profiles . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Voice Messaging (VPIMv2) . . . . . . . . . . . . . . . 8
4.1.2. iFax . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.3. Internet Voice Mail (IVM) . . . . . . . . . . . . . . 9
4.2. Putative Client Profiles . . . . . . . . . . . . . . . . . 9
4.2.1. TUI . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Multi-Modal Clients . . . . . . . . . . . . . . . . . 11
4.2.3. WUI . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. General Principles . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Protocol Conservation . . . . . . . . . . . . . . . . . . 13
5.1.1. Reuse Existing Protocols . . . . . . . . . . . . . . . 13
5.1.2. Maintain Existing Protocol Integrity . . . . . . . . . 13
5.2. Sensible Reception/Sending Context . . . . . . . . . . . . 13
5.2.1. Reception Context . . . . . . . . . . . . . . . . . . 13
5.2.2. Sending Context . . . . . . . . . . . . . . . . . . . 13
5.3. Internet Infrastructure Preservation . . . . . . . . . . . 14
5.4. Voice Requirements (Near Real-Time Delivery) . . . . . . . 14
5.5. Fax Requirements (Guaranteed Delivery) . . . . . . . . . . 14
5.6. Video Requirements (Scalable Message Size) . . . . . . . . 14
6. Issues and Requirements: TUI Subset of WUI . . . . . . . . . . 14
6.1. Requirements on the Message Retrieval Protocol . . . . . . 14
6.1.1. Performance Issues . . . . . . . . . . . . . . . . . . 15
6.1.2. Functional Issues . . . . . . . . . . . . . . . . . . 16
6.2. Requirements on the Message Submission Protocol . . . . . 18
6.2.1. Forward without Download Support . . . . . . . . . . . 18
6.2.2. Quota by Context Enforcement . . . . . . . . . . . . . 19
6.2.3. Future Delivery Support with Cancel . . . . . . . . . 19
6.2.4. Support for Committed Message Delivery . . . . . . . . 20
6.3. Requirements on Message Notification . . . . . . . . . . . 20
6.3.1. Additional Requirements on Message Notification . . . 21
7. Issues and Requirements: WUI Mobility Aspects . . . . . . . . 21
7.1. Wireless Considerations on Email . . . . . . . . . . . . . 21
7.1.1. Transport Considerations . . . . . . . . . . . . . . . 21
7.1.2. Handset-Resident Client Limitations . . . . . . . . . 22
7.1.3. Wireless Bandwidth and Network Utilization
Considerations . . . . . . . . . . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 6
3. Messaging Terminology and Simple Model (Client-to-Server
Aspect Only) . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Messaging Transaction Models . . . . . . . . . . . . . . . 6
3.2. Mobile Messaging Transactions . . . . . . . . . . . . . . 7
3.2.1. Submission . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Notification . . . . . . . . . . . . . . . . . . . . . 7
3.2.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . 8
4. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Existing Profiles . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Voice Messaging (VPIMv2) . . . . . . . . . . . . . . . 8
4.1.2. iFax . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.3. Internet Voice Mail (IVM) . . . . . . . . . . . . . . 9
4.2. Putative Client Profiles . . . . . . . . . . . . . . . . . 9
4.2.1. TUI . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Multi-Modal Clients . . . . . . . . . . . . . . . . . 11
4.2.3. WUI . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. General Principles . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Protocol Conservation . . . . . . . . . . . . . . . . . . 13
5.1.1. Reuse Existing Protocols . . . . . . . . . . . . . . . 13
5.1.2. Maintain Existing Protocol Integrity . . . . . . . . . 13
5.2. Sensible Reception/Sending Context . . . . . . . . . . . . 13
5.2.1. Reception Context . . . . . . . . . . . . . . . . . . 13
5.2.2. Sending Context . . . . . . . . . . . . . . . . . . . 13
5.3. Internet Infrastructure Preservation . . . . . . . . . . . 14
5.4. Voice Requirements (Near Real-Time Delivery) . . . . . . . 14
5.5. Fax Requirements (Guaranteed Delivery) . . . . . . . . . . 14
5.6. Video Requirements (Scalable Message Size) . . . . . . . . 14
6. Issues and Requirements: TUI Subset of WUI . . . . . . . . . . 14
6.1. Requirements on the Message Retrieval Protocol . . . . . . 14
6.1.1. Performance Issues . . . . . . . . . . . . . . . . . . 15
6.1.2. Functional Issues . . . . . . . . . . . . . . . . . . 16
6.2. Requirements on the Message Submission Protocol . . . . . 18
6.2.1. Forward without Download Support . . . . . . . . . . . 18
6.2.2. Quota by Context Enforcement . . . . . . . . . . . . . 19
6.2.3. Future Delivery Support with Cancel . . . . . . . . . 19
6.2.4. Support for Committed Message Delivery . . . . . . . . 20
6.3. Requirements on Message Notification . . . . . . . . . . . 20
6.3.1. Additional Requirements on Message Notification . . . 21
7. Issues and Requirements: WUI Mobility Aspects . . . . . . . . 21
7.1. Wireless Considerations on Email . . . . . . . . . . . . . 21
7.1.1. Transport Considerations . . . . . . . . . . . . . . . 21
7.1.2. Handset-Resident Client Limitations . . . . . . . . . 22
7.1.3. Wireless Bandwidth and Network Utilization
Considerations . . . . . . . . . . . . . . . . . . . . 22
7.1.4. Content Display Considerations . . . . . . . . . . . . 23
7.2. Requirements to Enable Wireless Device Support . . . . . . 24
7.2.1. Transport Requirements . . . . . . . . . . . . . . . . 24
7.2.2. Enhanced Mobile Email Functionality . . . . . . . . . 24
7.2.3. Client Requirements . . . . . . . . . . . . . . . . . 25
7.2.4. Bandwidth Requirements . . . . . . . . . . . . . . . . 25
7.2.5. Media Handling Requirements . . . . . . . . . . . . . 25
8. Interoperation with Existing Mobile Messaging . . . . . . . . 27
8.1. Addressing of Mobile Devices . . . . . . . . . . . . . . . 27
8.2. Push Model of Message Retrieval . . . . . . . . . . . . . 27
8.3. Message Notification . . . . . . . . . . . . . . . . . . . 27
8.4. Operator Issues . . . . . . . . . . . . . . . . . . . . . 27
8.4.1. Support for End-to-End Delivery Reports and
Message-Read Reports . . . . . . . . . . . . . . . . . 27
8.4.2. Support for Selective Downloading . . . . . . . . . . 27
8.4.3. Transactions and Operator Charging Units . . . . . . . 27
8.4.4. Network Authentication . . . . . . . . . . . . . . . . 28
8.5. LEMONADE and MMS . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
10.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 37
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 38
Appendix C. IAB Note: Unified Notification Protocol
Considerations . . . . . . . . . . . . . . . . . . . 38
7.1.4. Content Display Considerations . . . . . . . . . . . . 23
7.2. Requirements to Enable Wireless Device Support . . . . . . 24
7.2.1. Transport Requirements . . . . . . . . . . . . . . . . 24
7.2.2. Enhanced Mobile Email Functionality . . . . . . . . . 24
7.2.3. Client Requirements . . . . . . . . . . . . . . . . . 25
7.2.4. Bandwidth Requirements . . . . . . . . . . . . . . . . 25
7.2.5. Media Handling Requirements . . . . . . . . . . . . . 25
8. Interoperation with Existing Mobile Messaging . . . . . . . . 27
8.1. Addressing of Mobile Devices . . . . . . . . . . . . . . . 27
8.2. Push Model of Message Retrieval . . . . . . . . . . . . . 27
8.3. Message Notification . . . . . . . . . . . . . . . . . . . 27
8.4. Operator Issues . . . . . . . . . . . . . . . . . . . . . 27
8.4.1. Support for End-to-End Delivery Reports and
Message-Read Reports . . . . . . . . . . . . . . . . . 27
8.4.2. Support for Selective Downloading . . . . . . . . . . 27
8.4.3. Transactions and Operator Charging Units . . . . . . . 27
8.4.4. Network Authentication . . . . . . . . . . . . . . . . 28
8.5. LEMONADE and MMS . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
10.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 37
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 38
Appendix C. IAB Note: Unified Notification Protocol
Considerations . . . . . . . . . . . . . . . . . . . 38
Historically, a number of separate electronic messaging systems originated and evolved independently supporting different messaging modes. For example:
从历史上看，许多独立的电子消息传递系统都是独立产生和发展的，它们支持不同的消息传递模式。例如：
o Internet mail systems ([4], [10], [25]) evolved to support networked computers with messages consisting of rich text plus attachments. o Voice mail systems utilized a client with a telephone-based or an answering machine style of user interface. The telephone network was used for transport of recorded voice messages. o Fax store-and-forward users interface with a fax machine using a modified telephone-based interface. Fax machines use the telephone network for transport of fax data via modems. o SMS (Short Message Service) [58] enabled users to send short text messages between their cellular phones using the SS7 call control infrastructure ([60], [61], [63], [64], [65]) for transport.
o 互联网邮件系统（[4]、[10]、[25]）发展到支持网络计算机，其邮件由富文本和附件组成。o语音邮件系统使用具有基于电话或应答机风格的用户界面的客户端。电话网络用于传输录制的语音信息。o使用改进的基于电话的接口与传真机建立传真存储和转发用户接口。传真机使用电话网络通过调制解调器传输传真数据。o SMS（短消息服务）[58]允许用户使用SS7呼叫控制基础设施（[60]、[61]、[63]、[64]、[65]）在手机之间发送短文本消息进行传输。
In the recent past, IETF mail standards have evolved to support additional/merged functionality:
最近，IETF邮件标准已经发展到支持附加/合并功能：
o With MIME ([5], [6], [7], [8], [9], [28]), Internet mail transport was enhanced to carry any kind of digital data o Internet mail protocols were extended and profiled by VPIM ([13], [14], [15], [34]) and iFAX ([16], [17], [18], [19], [20], [21], [23]) so that enabled voice mail systems and fax machines could use the common email infrastructure to carry their messages over the Internet as an alternative to the telephone network. These enhancements were such that the user's experience of reliability, security, and responsiveness was not diminished by transport over the Internet.
o 通过MIME（[5]、[6]、[7]、[8]、[9]、[28]），增强了Internet邮件传输，以承载任何类型的数字数据。VPIM（[13]、[14]、[15]、[34]）和iFAX（[16]、[17]、[18]、[19]、[20]、[21]、[23]扩展和分析了Internet邮件协议因此，启用的语音邮件系统和传真机可以使用通用的电子邮件基础设施在互联网上传输信息，作为电话网络的替代方案。这些增强功能使得用户在可靠性、安全性和响应性方面的体验不会因互联网上的传输而减少。
These successes -- making Internet mail transport the common infrastructure supporting what were separate messaging universes -- have encouraged a new vision: to provide, over the Internet, a single infrastructure, mailbox, and set of protocols for a user to get, respond to, and manipulate all of his or her messages from a collection of clients with varying capabilities, operating in diverse environments ([46],[47]).
这些成功——使Internet邮件传输成为支持不同消息传递领域的公共基础设施——鼓励了一种新的愿景：通过Internet为用户提供单一的基础设施、邮箱和一组协议，以获取、响应，并在不同的环境中操作具有不同功能的客户机集合中的所有消息（[46]，[47]）。
The LEMONADE effort -- Internet email to support diverse service environments -- realizes this vision further by enabling Internet mail support for mobile devices and facilitating its interoperability with the existing mobile messaging universe.
柠檬水的努力——通过互联网电子邮件来支持各种服务环境——通过支持移动设备的互联网邮件并促进其与现有移动通信领域的互操作性，进一步实现了这一愿景。
In the recent past, the evolution of messaging standards for resource-limited mobile devices has been rapid:
最近，资源有限的移动设备的消息传递标准发展迅速：
o In the cellular space, SMS was enhanced to EMS (Extended Message Service) [59] allowing longer text messages, images, and graphics. With an even richer feature set, MMS (Multimedia Messaging Service) ([43], [52], [53], [56], [57]) was developed as a lightweight access mechanism for the transmission of pictures, audio, and motion pictures. MMS protocols are based in part on Internet standards (both messaging and web [24]) as well as SMS. The cellular messaging universe is a separate infrastructure adapted to deliver appropriate functionality in a timely and effective manner to a special environment. o As well, the number of different mobile clients that need to be supported keeps proliferating. (e.g., besides cellular phones there are wireless-enabled PDAs, tablet computers, etc.)
o 在蜂窝空间，SMS被增强为EMS（扩展消息服务）[59]，允许更长的文本消息、图像和图形。通过更丰富的功能集，MMS（多媒体信息服务）（[43]、[52]、[53]、[56]、[57]）被开发为一种轻量级的访问机制，用于传输图片、音频和动态图片。MMS协议部分基于互联网标准（消息和网络[24]）以及SMS。蜂窝式消息传递领域是一个独立的基础设施，适用于以及时有效的方式向特殊环境提供适当的功能。o此外，需要支持的不同移动客户端的数量不断增加。（例如，除手机外，还有无线PDA、平板电脑等）
These resource-limited mobile devices are less powerful both in processing speed and display capabilities than conventional computers. They are also connected to the network by wireless links whose bandwidth and reliability are lower, latency is longer, and costs are higher than those of traditional wire-line links, hence the stress on the need to support adaptation to a whole different service environment.
这些资源有限的移动设备在处理速度和显示能力方面都不如传统计算机强大。它们还通过无线链路连接到网络，无线链路的带宽和可靠性较低，延迟时间较长，成本高于传统的有线链路，因此强调需要支持适应整个不同的服务环境。
This document collects a number the issues impeding Internet mail protocols from directly supporting the mobile service environment. Considerations arising from these issues are documented, and in some cases possible approaches to solutions are suggested. It turns out that the enhancements to support mobile clients also offer benefits for some terminals in other environments. In particular, the enhancements address the needs of the following diverse clients:
本文档收集了一些阻碍Internet邮件协议直接支持移动服务环境的问题。记录了这些问题引起的注意事项，并在某些情况下提出了可能的解决方法。事实证明，支持移动客户端的增强功能也为其他环境中的某些终端提供了好处。特别是，这些增强功能满足了以下不同客户的需求：
o A wireless handheld device with an email client -- a Wireless User Interface (WUI) mode of user interaction is dictated by the constraints of the mobile wireless handheld operating environment. o Telephone-based voice client -- a Telephone User Interface (TUI), this is the user mode offered by a POTS set * This is a subset of the WUI and is useful in other contexts. o A multi-modal messaging client providing a coordinated messaging session using display and audio modes simultaneously. (e.g., a system consisting of a PC with a phone, or a wireless phone with both a voice circuit and data channel requiring coordination). * This is also a subset of the WUI and is useful in other contexts.
o 带有电子邮件客户端的无线手持设备——用户交互的无线用户界面（WUI）模式由移动无线手持操作环境的约束决定。o基于电话的语音客户端——电话用户界面（TUI），这是POTS集提供的用户模式。这是WUI的子集，在其他上下文中很有用。o多模式消息传递客户端，同时使用显示和音频模式提供协调的消息传递会话。（例如，由带有电话的PC或同时带有语音电路和数据通道的无线电话组成的系统需要协调）。*这也是WUI的一个子集，在其他上下文中很有用。
The rest of this document is structured as follows:
本文件其余部分的结构如下：
o A brief survey of messaging profiles - both existing and proposed. o A list of principles to be used to guide the design of Internet Messaging for diverse service environments. o Detailed discussion on enhancements to Internet mail protocols to support WUIs. o Some issues relating to the interoperation of enhanced Internet mail and the existing mobile messaging services.
o 对现有和拟议的消息传递配置文件进行简要调查。o用于指导针对不同服务环境的Internet消息传递设计的原则列表。o详细讨论增强Internet邮件协议以支持WUI。o与增强型互联网邮件和现有移动消息服务的互操作相关的一些问题。
This document refers generically to the sender of a message in the masculine (he/him/his) and to the recipient of the message in the feminine (she/her/hers). This convention is purely for convenience and makes no assumption about the gender of a message sender or recipient.
本文件泛指男性信息的发送者（他/他/他的）和女性信息的接收者（她/她/她的）。此约定纯粹是为了方便起见，不对消息发送者或接收者的性别进行假设。
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 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC2119[1]中所述进行解释。
3. Messaging Terminology and Simple Model (Client-to-Server Aspect Only)
3. 客户端到服务器方面（仅适用于客户端到服务器方面）
In the client-server model prevalent in existing messaging architectures, the client, also known as a "user agent", presents messages to and accepts messages from the user. The server, also known as a "relay/server" or a "proxy-relay", provides storage and delivery of messages.
在现有消息传递体系结构中流行的客户机-服务器模型中，客户机（也称为“用户代理”）向用户提供消息并接受来自用户的消息。服务器，也称为“中继/服务器”或“代理中继”，提供消息的存储和传递。
For a definitive description of Internet mail architecture, see [42].
有关Internet邮件体系结构的详细说明，请参见[42]。
There are two basic transactional models. In the "pull" model, the component, rather than the data flow, initiates the transaction. For example, a client may initiate a connection to a server and issue requests to the server to deliver incoming messages. Conventional email clients, web-mail clients, and WAP-based mobile clients use the "pull" model.
有两种基本的事务模型。在“pull”模型中，启动事务的是组件，而不是数据流。例如，客户机可以启动到服务器的连接，并向服务器发出请求以传递传入消息。传统的电子邮件客户端、web邮件客户端和基于WAP的移动客户端使用“拉”模式。
The "push" model differs in that the component initiating the transaction does so because of some data flow affecting it. For example, the arrival of a new message at the terminating server may cause a notification to be sent ("pushed") to a messaging client.
“推送”模型的不同之处在于，启动事务的组件之所以这样做，是因为某些数据流会影响它。例如，新消息到达终止服务器可能导致向消息传递客户端发送通知（“推送”）。
The most common functions are: "submission", "notification", and "retrieval". There may be other functions, such as "delivery reports", "read-reply reports", "forwarding", "view mailbox", "store message", etc. Each of these transactions can be implemented in either a pull or push model. However, some transactions are more naturally suited to one model or another.
最常见的功能是：“提交”、“通知”和“检索”。可能还有其他功能，如“传递报告”、“读取回复报告”、“转发”、“查看邮箱”、“存储邮件”等。这些事务中的每一个都可以在拉模式或推模式中实现。但是，有些事务更自然地适合于某个模型或另一个模型。
The following figure depicts a simple client-server model (no server-to-server interactions are shown):
下图描述了一个简单的客户机-服务器模型（未显示服务器到服务器的交互）：
(1) Message submission (2) Message notification (3) & (4) Message retrieval
(1) 消息提交（2）消息通知（3）和（4）消息检索
+-------+ +------+ +-------+
|Mail |-------(1)------>| |-----------(2)-------->|Mail |
|Client | Submit msg | | Notification /|Client |
+-------+ | | / +--+----+
| | / ^
| |<----------(3)-----+ /
|Server| Retrieval request /
| | /
| | /
| |-----------(4)-------+
| | Retrieval response
| |
+------+
+-------+ +------+ +-------+
|Mail |-------(1)------>| |-----------(2)-------->|Mail |
|Client | Submit msg | | Notification /|Client |
+-------+ | | / +--+----+
| | / ^
| |<----------(3)-----+ /
|Server| Retrieval request /
| | /
| | /
| |-----------(4)-------+
| | Retrieval response
| |
+------+
Simple Messaging Model
简单消息传递模型
"Submission" is the transaction between a client and a server by which the user of the former sends a new message to another user. Submission is a push from client to server.
“提交”是客户端和服务器之间的事务，前者的用户通过该事务向另一用户发送新消息。提交是从客户端到服务器的推送。
"Notification" is the transaction by which the server notifies the client that it has received messages intended for that client. Notification is a push from server to client.
“通知”是服务器通知客户机它已收到针对该客户机的消息的事务。通知是从服务器到客户端的推送。
All the larger mobile messaging systems implement a push model for the notification because data can be presented to the user without the user's experiencing network/transport latencies, and without tying up network resources for polling when there is no new data.
所有较大的移动消息传递系统都为通知实施推送模型，因为数据可以呈现给用户，而用户不会经历网络/传输延迟，并且在没有新数据时不会占用网络资源进行轮询。
Internet mail differs in that it has not yet seen the need for a standardized notification protocol.
Internet邮件的不同之处在于，它还没有看到需要标准化的通知协议。
"Retrieval" is the transaction between a client and a server by which the client can obtain one or more messages from the server. Retrieval can be push or pull.
“检索”是客户端和服务器之间的事务，通过该事务，客户端可以从服务器获取一条或多条消息。检索可以是推式或拉式。
Implemented in some mobile systems as an option, the push model has the advantage that the user is not necessarily aware of transport or network latencies.
推送模式作为一种选项在一些移动系统中实现，其优点是用户不一定知道传输或网络延迟。
The pull model, implemented in most systems (mobile or conventional), has the advantage that the user can control what data is actually sent to and stored by the client.
在大多数系统（移动或传统）中实现的pull模型的优点是，用户可以控制客户端实际发送和存储的数据。
Internet messaging can be made to support a variety of client and server types other than traditional email. The clients may be adapted for host restrictions such as limited processing power, message store, display window size, etc. Alternatively, clients may be adapted for different functionality (e.g., voice mail, fax, etc.). Servers may support optional mail features that would allow better handling of different media (e.g., voice mail, fax, video, etc.). A number of Internet mail profiles supporting specific application niches have been defined or proposed.
Internet消息传递可以支持除传统电子邮件之外的各种客户端和服务器类型。客户端可适用于主机限制，例如有限的处理能力、消息存储、显示窗口大小等。或者，客户端可适用于不同的功能（例如，语音邮件、传真等）。服务器可能支持可选的邮件功能，以便更好地处理不同的媒体（例如，语音邮件、传真、视频等）。已经定义或提议了许多支持特定应用领域的互联网邮件配置文件。
The following are examples of server-to-server profiles of SMTP and MIME. Except for IVM, they do not address client-to-server interactions.
以下是SMTP和MIME的服务器到服务器配置文件示例。除了IVM之外，它们不处理客户机到服务器的交互。
These profiles, RFC3801 [13] to RFC3803 [15], enable the transport of voice messages using the Internet mail system. The main driver for this work was support of IP transport for voice mail systems. As voice mail clients are accustomed to a higher degree of responsiveness and certainty as to message delivery, the functionality added by VPIMv2 includes Message Disposition
这些配置文件（RFC3801[13]到RFC3803[15]）允许使用Internet邮件系统传输语音消息。这项工作的主要驱动因素是支持语音邮件系统的IP传输。由于语音邮件客户端习惯于更高程度的响应性和消息传递的确定性，VPIMv2添加的功能包括消息处理
Notification and Delivery Status Message ([12], [3]). Voice media has also been added to multi-part message bodies.
通知和传递状态消息（[12]，[3]）。语音媒体也被添加到多部分消息正文中。
This set of profiles ([16], [17], [18], [19], [20], [21]) enables the transport of fax using Internet mail protocols. This work defined the image/tiff MIME type. Support for fax clients also required extensions to Message Delivery Notification.
这组配置文件（[16]、[17]、[18]、[19]、[20]、[21]）支持使用Internet邮件协议传输传真。这项工作定义了图像/tiff MIME类型。对传真客户端的支持还需要对邮件传递通知进行扩展。
This proposed mail enhancement (whose requirements are described in RFC 3773 [30]) targets support for the interchange of voice messaging between the diverse components (clients as well as servers) in systems supporting voice mail.
这一提议的邮件增强（其要求在RFC 3773[30]中描述）旨在支持支持语音邮件系统中不同组件（客户端和服务器）之间的语音消息交换。
It is desirable to replace proprietary protocols between telephone user interface clients and message stores with standards-based interfaces. The proprietary protocols were created to provide media-aware capabilities as well as to provide the low-latency required by some messaging applications.
希望用基于标准的接口替换电话用户界面客户端和消息存储之间的专有协议。创建专有协议是为了提供媒体感知功能，以及提供某些消息传递应用程序所需的低延迟。
An example of a TUI client is a voice mail client. Because a POTS phone lacks any intelligence, the voice mail client functionality has to be provided by a user agent networked to the mail server. The main architectural difference between a conventional voice mail system and an Internet messaging system supporting a TUI is that the voice mail system uses a specialized message store and protocols.
TUI客户端的一个示例是语音邮件客户端。由于POTS电话缺乏任何智能，语音邮件客户端功能必须由与邮件服务器联网的用户代理提供。传统语音邮件系统和支持TUI的Internet消息传递系统之间的主要架构差异在于，语音邮件系统使用专门的消息存储和协议。
The following figure depicts the architecture of current voice mail systems implementing VPIMv2:
下图描述了实现VPIMv2的当前语音邮件系统的体系结构：
|-------------|
|-------| RFC-822/MIME | |
| | |---------------------------| MTA |
| | | mail submission -> | |(E)SMTP
Telephone--|TUI|TUA| |------| |-----to
| | | Proprietary Protocol | | |another
| | |---------------------------| MS | | email
|-------| < - mail retrieval | | | server
|-------------|
mail client email server
|-------------|
|-------| RFC-822/MIME | |
| | |---------------------------| MTA |
| | | mail submission -> | |(E)SMTP
Telephone--|TUI|TUA| |------| |-----to
| | | Proprietary Protocol | | |another
| | |---------------------------| MS | | email
|-------| < - mail retrieval | | | server
|-------------|
mail client email server
|----------------voice messaging system -------------|
|----------------voice messaging system -------------|
Mail client consists of: TUI (Telephone User Interface) and TUA (Telephone User Agent)
邮件客户端包括：TUI（电话用户界面）和TUA（电话用户代理）
Communication between TUI and TUA is proprietary.
TUI和TUA之间的通信是专有的。
Email server consists of: MS (Mail Store) and MTA (Message Transfer Agent)
电子邮件服务器包括：MS（邮件存储）和MTA（邮件传输代理）
Communication between MS and MTA is proprietary.
MS和MTA之间的通信是专有的。
It is proposed that the Proprietary Protocol be replaced with an IETF standard protocol:
建议将专有协议替换为IETF标准协议：
|-------------|
|-------| RFC-822/MIME | |
| | |---------------------------| MTA |
| | | mail submission -> | |(E)SMTP
Telephone--|TUI|TUA| |------| |-----to
| | | IETF protocol | | |another
| | |---------------------------| MS | | mail
|-------| <- mail retrieval | | | server
|-------------|
mail client email server
|-------------|
|-------| RFC-822/MIME | |
| | |---------------------------| MTA |
| | | mail submission -> | |(E)SMTP
Telephone--|TUI|TUA| |------| |-----to
| | | IETF protocol | | |another
| | |---------------------------| MS | | mail
|-------| <- mail retrieval | | | server
|-------------|
mail client email server
|- voice mail system-| |-mail server-|
|- voice mail system-| |-mail server-|
Mail client consists of: TUI (Telephone User Interface) and TUA (Telephone User Agent)
邮件客户端包括：TUI（电话用户界面）和TUA（电话用户代理）
Communication between TUI and TUA is proprietary.
TUI和TUA之间的通信是专有的。
Email server consists of: MS (Mail Store) and MTA (Message Transfer Agent)
电子邮件服务器包括：MS（邮件存储）和MTA（邮件传输代理）
Communication between MS and MTA is proprietary.
MS和MTA之间的通信是专有的。
Multi-modal clients offer the advantage of coordinated voice and data modes of user interaction. Architecturally, the multi-modal client can be considered the union two user agent components -- one a TUI client, the other a simple GUI client. See the next figure. The Graphical User Agent (GUA) helps maintain the text display while the Telephone User Agent (TUA) acts on behalf of the TUI functionality.
多模式客户端提供了用户交互的协调语音和数据模式的优势。在体系结构上，多模式客户端可以被视为两个用户代理组件的联合——一个是TUI客户端，另一个是简单的GUI客户端。请参见下图。图形用户代理（GUA）帮助维护文本显示，而电话用户代理（TUA）则代表TUI功能。
This model is the norm with cellular devices supporting data access because historically they evolved from cell phones to which a data channel was added. The presentation of multiple complementary modes of interaction gives end-users their choice of the most convenient and natural working mode for a particular task. There are other situations where a multi-modal model is appropriate. (For example, a telephone sales unit needs to provide a voice (telephone) mode and conventional desktop PC mode of interaction at the same time in an integrated manner.)
该模型是支持数据访问的蜂窝设备的标准，因为从历史上看，它们是从添加了数据通道的手机演变而来的。多种互补交互模式的呈现为最终用户提供了针对特定任务的最方便、最自然的工作模式选择。在其他情况下，多模态模型是合适的。（例如，电话销售单位需要以集成方式同时提供语音（电话）模式和传统桌面PC交互模式。）
A major issue in the design of multi-modal clients -- the need to synchronize the component user agents making up a client -- is only addressed by LEMONADE to a limited extent in Section 6.3.
多模式客户端设计中的一个主要问题——需要同步组成客户端的组件用户代理——在第6.3节中，LEMONADE仅在有限的范围内解决了这个问题。
The Wireless User Interface is functionally equivalent to a conventional email client on a personal workstation, but is optimized for clients on handheld tetherless devices. Factors needing consideration include limited memory and processing power. Limited bandwidth is also relatively high cost. As already alluded to above, in many cases (e.g., cellular devices), the mobile client is multi-modal. So WUIs can be modeled as resource-and-link-limited multi-modal clients.
无线用户界面在功能上等同于个人工作站上的传统电子邮件客户端，但针对手持无绳设备上的客户端进行了优化。需要考虑的因素包括有限的内存和处理能力。有限的带宽成本也相对较高。如上所述，在许多情况下（例如，蜂窝设备），移动客户端是多模式的。因此，可以将WUI建模为资源和链接受限的多模式客户端。
These terminals require the use of protocols that minimize the number of over-the-air transactions and reduce the amount of data that need be transmitted over the air overall. Such reduction in over-the-air transmission is a combination of more efficient protocol interaction and richer message presentation choices, whereby a user may more intelligently select what should be downloaded and what should remain on the server.
这些终端需要使用协议，以最大限度地减少空中事务的数量，并减少需要通过空中传输的数据量。这种空中传输的减少是更有效的协议交互和更丰富的消息表示选择的组合，用户可以更智能地选择应该下载的内容和应该保留在服务器上的内容。
Although not an explicit goal, providing equivalent or superior functionality to the wireless MMS service [43] (as defined by 3GPP, 3GPP2, and the OMA) is desirable.
尽管不是明确的目标，但希望提供与无线MMS服务[43]（如3GPP、3GPP2和OMA所定义的）同等或优越的功能。
Proposed Wireless User Interface (WUI)/Multi-modal Clients
建议的无线用户界面（WUI）/多模式客户端
|wireless GUI client| email server
|无线GUI客户端|电子邮件服务器
(E)SMTP (client-server) |-------------|
|-------| RFC-822/MIME | |
| | |---------------------------| |
| | | mail submission -> | |(E)SMTP
-|GUI|GUA| | |-----to
| | | | IETF standard protocol |------------ |another
| | | |----------------------------to MS below| | mail
| |-------| <- mail retrieval |------------ | server
| | | |
Handheld | | | |
Device WUI | | MTA |
| | | |
| | | |
| |-------| RFC-822/MIME | |
| | | |---------------------------| |
| | | | mail submission -> | |
-|TUI|TUA| |------| |
| | | IETF standard protocol | | |
| | |---------------------------| MS | |
|-------| <- mail retrieval | | |
|-------------|
TUI client voice mail server
(E)SMTP (client-server) |-------------|
|-------| RFC-822/MIME | |
| | |---------------------------| |
| | | mail submission -> | |(E)SMTP
-|GUI|GUA| | |-----to
| | | | IETF standard protocol |------------ |another
| | | |----------------------------to MS below| | mail
| |-------| <- mail retrieval |------------ | server
| | | |
Handheld | | | |
Device WUI | | MTA |
| | | |
| | | |
| |-------| RFC-822/MIME | |
| | | |---------------------------| |
| | | | mail submission -> | |
-|TUI|TUA| |------| |
| | | IETF standard protocol | | |
| | |---------------------------| MS | |
|-------| <- mail retrieval | | |
|-------------|
TUI client voice mail server
|----------------voice messaging system ----------------|
|----------------voice messaging system ----------------|
|------WUI-----| |---mail server---|
|------WUI-----| |---mail server---|
Wireless GUI client consists of: GUI (Graphical User Interface) and GUA (Graphical User Agent)
无线GUI客户端包括：GUI（图形用户界面）和GUA（图形用户代理）
Communication between UI and UA is proprietary.
UI和UA之间的通信是专有的。
TUI client consists of: TUI (Telephone User Interface) and TUA (Telephone User Agent)
TUI客户端包括：TUI（电话用户界面）和TUA（电话用户代理）
Communication between TUI and TUA is proprietary. Communication between GUA and TUA is proprietary.
TUI和TUA之间的通信是专有的。GUA和TUA之间的通信是专有的。
Mail (email and voice mail) server consists of: MS (Mail Store) and MTA (Message Transfer Agent)
邮件（电子邮件和语音邮件）服务器包括：MS（邮件存储）和MTA（邮件传输代理）
Communication between MS and MTA is proprietary.
MS和MTA之间的通信是专有的。
This is a list of principles to guide the design of extensions for Internet Messaging systems and protocols to support diverse endpoints.
这是一个原则列表，用于指导Internet消息传递系统和协议扩展的设计，以支持不同的端点。
To the extent feasible, the enhanced messaging framework SHOULD use existing protocols whenever possible.
在可行的范围内，增强消息传递框架应尽可能使用现有协议。
In meeting the requirement "Reuse Existing Protocols" (Section 5.1.1), the enhanced messaging framework MUST NOT redefine the semantics of an existing protocol.
在满足“重用现有协议”（第5.1.1节）的要求时，增强消息传递框架不得重新定义现有协议的语义。
Extensions, based on capability declaration by the server, will be used to introduce new functionality where required.
基于服务器的功能声明的扩展将用于在需要时引入新功能。
Said differently, we will not break existing protocols.
换言之，我们不会破坏现有的协议。
When the user receives a message, that message SHOULD receive the treatment expected by the sender. For example, if the sender believes he is sending a voice message, voice message semantics should prevail to the extent that the receiving client can support such treatment.
当用户收到消息时，该消息应得到发送者期望的处理。例如，如果发送者认为他正在发送语音消息，则语音消息语义应优先于接收客户端能够支持此类处理的范围。
When the user sends a message, he SHOULD be able to specify the message context. That is, whether the network should treat the message as an text message, voice message, video message, etc. Again, this can only be complied with to the extent that the infrastructure and receiving client can provide such treatment. In practice, this would imply that the message should be in the form desired by the sender up to delivery to the receiving client.
当用户发送消息时，他应该能够指定消息上下文。也就是说，网络是否应将消息视为文本消息、语音消息、视频消息等。同样，这只能在基础设施和接收客户端能够提供此类处理的情况下进行。在实践中，这意味着在将消息传递给接收客户端之前，消息应采用发送方所希望的形式。
The infrastructure SHOULD change only where required for new functionality. Existing functionality MUST be preserved on the existing infrastructure; that is, all extensions must be backward compatible to allow for the gradual introduction of the enhancements. Messages created in an enhanced messaging context MUST NOT require changes to existing mail clients. However, there may be a degradation in functionality in certain circumstances.
只有在需要新功能时，基础结构才应更改。必须在现有基础设施上保留现有功能；也就是说，所有扩展必须向后兼容，以允许逐步引入增强。在增强消息上下文中创建的消息不得要求更改现有邮件客户端。但是，在某些情况下，功能可能会降低。
The enhanced messaging framework MUST be able to handle messages created in a non-enhanced messaging context; for example, a simple, RFC822 [2] text message.
增强消息传递框架必须能够处理在非增强消息传递上下文中创建的消息；例如，一条简单的RFC822[2]文本消息。
On the retrieval side, there are significant real-time requirements for retrieving a message for voice playback. More than any other media type, including video, voice is extremely sensitive to variations in playback latency. The enhanced messaging framework MUST address the real-time needs of voice.
在检索方面，检索用于语音播放的消息有很大的实时性要求。与包括视频在内的任何其他媒体类型相比，语音对播放延迟的变化极其敏感。增强的消息传递框架必须满足语音的实时需求。
Fax users have a particular expectation that is a challenge for enhanced Internet messaging. A person who sends a fax expects the recipient to receive the fax upon successful transmission. This clearly is not the case for Internet Mail.
传真用户有一个特殊的期望，这对增强Internet消息传递是一个挑战。发送传真的人希望收件人在成功发送后收到传真。互联网邮件显然不是这样。
Addressing this need is not in the scope of LEMONADE.
解决这一需求不在柠檬水的范围之内。
Video mail has one outstanding feature: Video messages are potentially large! The enhanced messaging framework MUST scale for very large messages. Streaming from the server to the client, in both directions, MUST be supported.
视频邮件有一个突出的特点：视频邮件可能很大！增强的消息传递框架必须针对非常大的消息进行扩展。必须支持从服务器到客户端的双向流式传输。
IMAP [10] is the Internet protocol for rich message retrieval and manipulation. The project MUST limit itself to extending IMAP where necessary and MUST not create a new protocol.
IMAP[10]是用于丰富消息检索和操作的互联网协议。项目必须限制自己在必要时扩展IMAP，并且不得创建新协议。
The real-time playback of a voice message MUST be supported so that the user experience does not differ noticeably from that of a conventional voice messaging system.
必须支持语音消息的实时回放，以便用户体验与传统语音消息系统的体验没有明显差异。
Possible solutions for this include making use of the existing incremental download capability of the IMAP protocol, or utilizing a companion streaming protocol.
可能的解决方案包括利用IMAP协议现有的增量下载功能，或利用配套的流媒体协议。
The IMAP protocol itself does not provide streaming by the strict definition of the term. It does provide for the incremental download of content in blocks. Most IMAP clients do not support this behavior and instead download the entire contents into a temporary file to be passed to the application.
IMAP协议本身不提供严格定义的流。它确实提供了以块为单位的内容增量下载。大多数IMAP客户端不支持这种行为，而是将整个内容下载到一个临时文件中，以传递给应用程序。
There are several approaches to achieve real-time playback. The first approach is to implement an IMAP client that can pass data incrementally to the application as it is received from the network. The application can then read bytes from the network as needed to maintain a play buffer. Thus, it would not require the full download of contents. This approach may require server-side development to support partial download efficiently (i.e., to avoid re-opening files and positioning to the requested location).
有几种方法可以实现实时播放。第一种方法是实现IMAP客户机，该客户机可以在从网络接收数据时将数据增量传递给应用程序。然后，应用程序可以根据需要从网络读取字节，以维护播放缓冲区。因此，它不需要完全下载内容。这种方法可能需要服务器端开发来有效地支持部分下载（即，避免重新打开文件并定位到请求的位置）。
Alternatively, the client can use the proposed IMAP channel extension [32] to request that the server make the selected content available via an alternate transport mechanism. A client can then ask the server to make the voice data available to the client via a streaming media protocol such as RTSP. This requires support on the client and server of a common streaming protocol.
或者，客户端可以使用建议的IMAP通道扩展[32]请求服务器通过替代传输机制使所选内容可用。然后，客户机可以要求服务器通过流媒体协议（如RTSP）向客户机提供语音数据。这需要在客户端和服务器上支持通用流协议。
Another important performance optimization is enabling the transport of data using more efficient native coding rather than text-like content-transfer encodings such as "base 64".
另一个重要的性能优化是使用更高效的本机编码而不是像“base 64”这样的文本内容传输编码来实现数据传输。
Standard IMAP4 uses a text-based data representation scheme where all data is represented in a form that looks like text; that is, voice data must be encoded using "base 64" into a transport encoding that adds 30% to the size of a message. Downloading or appending large messages to the server already uses substantial bandwidth.
标准IMAP4使用基于文本的数据表示方案，其中所有数据都以类似文本的形式表示；也就是说，必须使用“base 64”将语音数据编码为传输编码，从而使消息的大小增加30%。向服务器下载或附加大型邮件已经占用了大量带宽。
Possible Solutions:
可能的解决方案：
Where IMAP channel is appropriate, the external channel may be binary capable; that is, the external access may not require re-encoding. Mechanisms such as HTTP [24], FTP, or RTSP are available for this download.
在适当的IMAP信道的情况下，外部信道可以是二进制的；也就是说，外部访问可能不需要重新编码。HTTP[24]、FTP或RTSP等机制可用于此下载。
The IMAP binary extension standards proposal [31] extends the IMAP fetch command to retrieve data in the binary form. This is especially useful for large attachments and other binary components. Binary in conjunction with a streaming client implementation may be an attractive alternative to the channel extension.
IMAP二进制扩展标准提案[31]扩展了IMAP fetch命令，以检索二进制形式的数据。这对于大型附件和其他二进制组件尤其有用。二进制与流式客户端实现相结合可能是信道扩展的一个有吸引力的替代方案。
The common TUI prompt, "you have two new voice messages, six unheard messages, and one new fax message", requires more information than is conveniently made available by current message retrieval protocols.
常见的TUI提示“您有两条新的语音消息、六条未听过的消息和一条新的传真消息”，需要的信息比当前的消息检索协议方便提供的信息更多。
The existing IMAP protocol's mailbox status command does not include a count by message context [26] [27]. A possible solution is for the mail server to keep track of these current counters and provide a status command that returns an arbitrary mailbox summary. The IMAP status command provides a count of new and total messages with standardized attributes extracted from the message headers. This predetermined information does not currently include information about the message type. Without additional conventions to the status command, a client would have to download the header for each message to determine its type, a prohibitive cost where latency or bandwidth constraints exist.
现有IMAP协议的邮箱状态命令不包括按消息上下文计数[26][27]。一种可能的解决方案是邮件服务器跟踪这些当前计数器，并提供一个返回任意邮箱摘要的status命令。IMAP status命令提供从消息头中提取的具有标准化属性的新消息和总消息的计数。该预定信息当前不包括关于消息类型的信息。如果status命令没有其他约定，客户机将不得不下载每条消息的报头以确定其类型，这在存在延迟或带宽限制的情况下是一种令人望而却步的成本。
This functionality is required to present new voice messages first and then new fax messages within a single logical queue as voice mailboxes commonly do. Again, this is a question of convenience and performance. Adequate performance may only be possible if the mail server provides a sort by context or maintains a set of virtual mailboxes (folders) corresponding to message types as for "Mailbox Summary Support", Section 6.1.2.1.
需要此功能，才能在单个逻辑队列中首先显示新的语音消息，然后显示新的传真消息，就像语音邮箱通常所做的那样。同样，这是一个方便性和性能的问题。只有在邮件服务器提供按上下文排序或维护一组与“邮箱摘要支持”第6.1.2.1节中的邮件类型相对应的虚拟邮箱（文件夹）时，才能实现足够的性能。
IMAP does not support this directly. A straightforward solution is to define an extensible sort mechanism for sorting on arbitrary header contents.
IMAP不直接支持这一点。一个简单的解决方案是定义一个可扩展的排序机制，用于对任意标题内容进行排序。
Extension mailbox support requires the ability to efficiently status a mailbox other than the one currently logged into. This facility is required to support sub-mailboxes, where a common feature is to check whether other sub-mailboxes in the same family group have new messages.
扩展邮箱支持要求能够有效地对当前登录邮箱以外的邮箱进行状态设置。此功能用于支持子邮箱，其中一个常见功能是检查同一系列组中的其他子邮箱是否有新邮件。
Current mechanisms are limited to logging into each of set of mailboxes, checking status, logging out, and repeating until all sub-mailboxes are processed.
当前机制仅限于登录到每个邮箱集、检查状态、注销和重复，直到处理完所有子邮箱。
Applications that provide features such as check receipt, deleted message recovery, resave, and others, require the ability to access messages in predetermined mailboxes with specific behaviors (e.g., Outbox, Sent Items, Deleted Items, Expired Items, Drafts).
提供诸如支票收据、已删除邮件恢复、重新保存等功能的应用程序需要能够以特定行为（例如发件箱、已发送邮件、已删除邮件、过期邮件、草稿）访问预定邮箱中的邮件。
IMAP provides only a single standardized folder, the inbox. This functionality does not require new protocol additions per se, but standardized usage and naming conventions are necessary for interoperability. This functionality requires that the server provide the underlying logic to support these special folders, including automatic insertion, scheduled copying, and periodic deletion.
IMAP只提供一个标准化的文件夹，即收件箱。此功能本身不需要添加新的协议，但标准化的使用和命名约定对于互操作性是必要的。此功能要求服务器提供支持这些特殊文件夹的底层逻辑，包括自动插入、计划复制和定期删除。
Many calling features are dependent on collected caller-ID information. Clients -- such as the TUI and other service supporting user agents (e.g., WEB and WAP servers) -- may need trusted access to restricted caller-ID information for such purposes as callback. Untrusted clients must not be permitted to receive this information. A mechanism for establishing "trust" between appropriate clients and the server is required to restrict delivery of this information to the end-user only as allowed.
许多呼叫功能依赖于收集的呼叫者ID信息。客户端（如TUI和其他支持用户代理的服务（如WEB和WAP服务器））可能需要受信任地访问受限的来电显示信息，以实现回调等目的。不得允许不受信任的客户端接收此信息。需要一种在适当的客户端和服务器之间建立“信任”的机制，以限制仅在允许的情况下将此信息传递给最终用户。
Further, when messages are sent between servers within a network, a means of communicating trust is needed so that the identity of the sender can be preserved for record-keeping and certain features while ensuring that the identity is not disclosed to the recipient in an inappropriate way.
此外，当在网络内的服务器之间发送消息时，需要一种传递信任的方法，以便可以保留发送者的身份以备记录保存和某些特征，同时确保该身份不会以不适当的方式披露给接收者。
If the telephone answering application client uses IMAP4 for greeting access and message deposit, it is essential that the server provide support for simultaneous login. It is common in voice mail for an incoming call to be serviced by the telephone answering application client at the same time the subscriber is logged into her mailbox. Further, new applications such as WEB and WAP access to voice mail may entail simultaneous login sessions, one from the TUI client and one from the visual client.
如果电话应答应用程序客户端使用IMAP4进行问候访问和邮件寄存，则服务器必须支持同时登录。在语音邮件中，电话应答应用程序客户端在用户登录其邮箱的同时为传入呼叫提供服务是很常见的。此外，对语音邮件的WEB和WAP访问等新应用程序可能需要同时登录会话，一个来自TUI客户端，另一个来自可视客户端。
The existing standard does not preclude multiple accesses to a mailbox, but it does not explicitly require support of the practice. The lack of explicit support requires the server and client to adhere to a common set of practices and behaviors to avoid undesirable and unpredictable behaviors. RFC2180 [29] describes a candidate set of conventions necessary to support this multiple-access technique. It or some other method MUST be standardized as part of LEMONADE.
现有标准并不排除对邮箱的多次访问，但它并不明确要求支持这种做法。缺乏明确的支持要求服务器和客户端遵循一组常见的实践和行为，以避免出现不希望出现的和不可预测的行为。RFC2180[29]描述了支持这种多址技术所需的一组候选约定。它或其他方法必须作为柠檬水的一部分进行标准化。
It is common to forward messages or to reply to messages with a copy of their attached content. Today such forwarding requires the sender to download a complete copy of the original message, attach it to the reply or forward message, and resubmit the result. For large messages, this represents a substantial amount of bandwidth and processing. For clients connected via long-thin pipes, alternatives are required.
转发邮件或回复带有附加内容副本的邮件是很常见的。如今，这种转发要求发件人下载原始邮件的完整副本，将其附加到回复或转发邮件中，然后重新提交结果。对于大型消息，这表示大量的带宽和处理。对于通过细长管道连接的客户端，需要替代方案。
One approach is to define an extension to message submission to request the submission server to resolve embedded URLs within a message before relaying the message to the final destination. This approach is referred to as the pull approach because the message submission server must pull data from the IMAP server.
一种方法是定义消息提交的扩展，以请求提交服务器在将消息转发到最终目的地之前解析消息中的嵌入URL。这种方法称为拉取方法，因为消息提交服务器必须从IMAP服务器拉取数据。
Another approach is to add a limited message assembly and submission capability to the IMAP server. This approach muddies the distinction between the message submission protocol and that for message storage and retrieval (IMAP) because now message submission may be a side effect of message store commands. This approach is referred to as the push approach because in this case the IMAP server pushes data to the message submission server.
另一种方法是向IMAP服务器添加有限的消息汇编和提交功能。这种方法混淆了消息提交协议与消息存储和检索（IMAP）协议之间的区别，因为现在消息提交可能是消息存储命令的副作用。这种方法称为推送方法，因为在这种情况下，IMAP服务器将数据推送到消息提交服务器。
A detailed analysis of which of the two approaches is preferable as well as implementation details of both can be found in references [36], [37], [38], [39], [40], and [41].
参考文献[36]、[37]、[38]、[39]、[40]和[41]中详细分析了这两种方法中哪一种更可取以及这两种方法的实现细节。
It is common in a unified messaging system to offer separate quotas [11] for each of several message contexts to avoid the condition where a flood of email fills the mailbox and prevents the subscriber from receiving voice messages via the telephone. It is necessary to extend the protocols to support the reporting of the "mailbox full" status based on the context of the submitted message.
在统一消息系统中，通常为多个消息上下文中的每一个提供单独的配额[11]，以避免大量电子邮件填满邮箱，并阻止订户通过电话接收语音消息。有必要扩展协议，以支持基于提交邮件的上下文报告“邮箱已满”状态。
An obvious security issue needing consideration is the prevention of the deliberate misidentification of a message context with the intention of overflowing a subscriber's mailbox. It is envisioned that the message submission protocol will require the authentication of trusted submission agents allowing only those so authorized to submit distinguished messages.
需要考虑的一个明显的安全问题是防止故意错误识别消息上下文，以使订阅者的邮箱溢出。可以预见，消息提交协议将要求对可信提交代理进行身份验证，仅允许授权提交可分辨消息的代理。
Voice mail system mailboxes commonly contain voice and fax messages. Sometimes, such systems also support email messages (text, text with attachments, and multimedia messages) in addition to voice messages. Similar to the required sort by message context, quota management is also required per message context.
语音邮件系统邮箱通常包含语音和传真消息。有时，除了语音信息外，此类系统还支持电子邮件（文本、带有附件的文本和彩信）。与所需的按消息上下文排序类似，每个消息上下文也需要配额管理。
One possible use case is the prevention of multiple (large) messages of one type (e.g., email messages) from consuming all available quota. Consumption of all quota by one type prevents the delivery of other types (e.g., voice or fax messages) to the mailbox.
一个可能的用例是防止一种类型的多条（大型）消息（例如电子邮件）使用所有可用配额。一种类型使用所有配额会阻止向邮箱发送其他类型的配额（例如，语音或传真消息）。
One possible approach is to define a mechanism whereby a trusted client can declare the context of a message for the purpose of utilizing a protected quota. This may be by extensions to the SMTP-submit or LMTP[35] protocols.
一种可能的方法是定义一种机制，通过该机制，受信任的客户端可以声明消息的上下文，以利用受保护的配额。这可以通过SMTP提交或LMTP[35]协议的扩展实现。
Traditionally messages sent with "future delivery" are held in the recipient's client "outbox" or its equivalent until the appointed submission time. Thin clients used with TUIs do not have such persistent storage or may be intermittently connected and must rely upon server-based outbox queues.
传统上，“未来交付”发送的邮件保存在收件人的客户端“发件箱”或其等效文件中，直到指定的提交时间。与TUIs一起使用的瘦客户机没有这种持久性存储，或者可能是间歇性连接的，并且必须依赖于基于服务器的发件箱队列。
Such support requires extensions to message submission protocols to identify a message as requiring queuing for future delivery. Extensions to IMAP4 or SMTP are required for viewing and manipulating the outbound queue, for such purposes as canceling a future message. Server support for managing such a queue is required so that messages are sent when they are intended.
这种支持需要对消息提交协议进行扩展，以将消息标识为需要排队等待将来的传递。查看和操作出站队列时需要IMAP4或SMTP的扩展，以便取消将来的邮件。需要服务器支持管理这样的队列，以便在需要时发送消息。
Some of the architectural issues here are the same as those in "Forward without Download Support" (Section 6.2.1).
这里的一些架构问题与“无下载支持的转发”（第6.2.1节）中的问题相同。
Voice messaging service has provided a high degree of reliability and performance for telephone answering messages. The expectation is that once the caller has hung up, the message is in the mailbox and available for review. The traditional Internet mail architecture suggests these messages should be sent to the mailbox via SMTP. This approach has two limitations. The first and most manageable is that the message forwarding may take more time than is tolerable by the subscriber. The second is that the message may fail to be delivered to the mailbox. Because there is no way to return notice to the caller, the message is "lost".
语音消息服务为电话应答消息提供了高度的可靠性和性能。我们的期望是，一旦呼叫者挂断电话，邮件就在邮箱中，可以查看。传统的Internet邮件体系结构建议通过SMTP将这些邮件发送到邮箱。这种方法有两个局限性。第一个也是最容易管理的是，消息转发可能需要比订阅者所能忍受的更多的时间。第二，邮件可能无法传递到邮箱。由于无法将通知返回给呼叫者，因此消息“丢失”。
The standards community is working on an alternative to SMTP called Local Message Transport Protocol (LMTP[35]). This protocol addresses a number of limitations in SMTP when used to provide atomic delivery to a mailbox. The failure modes in this proposal are carefully controlled, as are issues of per-message quota enforcement and message storage quota-override for designated administrative messages.
标准团体正在研究SMTP的替代方案，称为本地消息传输协议（LMTP[35]）。此协议解决了SMTP在用于向邮箱提供原子传递时的一些限制。本计划书中的故障模式受到仔细控制，指定管理邮件的每封邮件配额强制执行和邮件存储配额覆盖问题也是如此。
An alternative approach is to misuse the IMAP protocol and use an IMAP-based submission mechanism to deposit a message directly into the recipient's inbox. This append must be done by a special super-user with write permissions into the recipient mailbox. Further, the message store must be able to trigger notification events upon insertion of a message into the mailbox via the Append command. The historic limitation on using IMAP4 for message sending involves the inability of IMAP to communicate a full SMTP envelope. For telephone answering, these limitations are not significant. However, the architectural issues raised by this approach are significant. See "Forward without Download Support" (Section 6.2.1).
另一种方法是滥用IMAP协议，使用基于IMAP的提交机制将邮件直接放入收件人的收件箱。此附加必须由具有收件人邮箱写入权限的特殊超级用户完成。此外，邮件存储必须能够在通过Append命令将邮件插入邮箱时触发通知事件。使用IMAP4发送邮件的历史限制包括IMAP无法传送完整的SMTP信封。对于电话应答，这些限制并不重要。然而，这种方法引起的体系结构问题非常重要。请参阅“无下载支持的转发”（第6.2.1节）。
Clients keep local information about the IMAP store. This information must be kept synchronized with the state of the store.
客户端保留有关IMAP存储的本地信息。此信息必须与存储的状态保持同步。
For example, voice mail systems traditionally notify subscribers of certain events happening in their mailbox. It is common to send an SMS or a pager notification for each message arrival event, message read event, mailbox full event, etc.
例如，语音邮件系统传统上会通知订阅者邮箱中发生的某些事件。通常为每个邮件到达事件、邮件读取事件、邮箱已满事件等发送SMS或寻呼机通知。
When implemented over IMAP-based message stores, the voice mail client needs to be notified about these events. Furthermore, when other applications access/manipulate the store, these events need to be communicated to the mail client. In some cases, the client needs to notify the user immediately. In most cases, it is a question of maintaining client/application consistency. In the case of a multimodal client, it is especially important to provide a means of coordinating the client's different modal views of the state of the store.
当通过基于IMAP的消息存储实现时，需要将这些事件通知语音邮件客户端。此外，当其他应用程序访问/操作存储时，需要将这些事件传递给邮件客户端。在某些情况下，客户端需要立即通知用户。在大多数情况下，这是一个维护客户机/应用程序一致性的问题。在多模式客户的情况下，提供一种协调客户对商店状态的不同模式视图的方法尤为重要。
Email systems have traditionally polled to update this information. There may be advantages to an event-driven approach in some cases.
传统上，电子邮件系统通过轮询来更新这些信息。在某些情况下，事件驱动方法可能具有优势。
The standards community is working on a standard for bulk server-to-client status notification. An example of such work is the Simple Notification and Alarm Protocol (SNAP) [45], which defines the expected behavior of the message store for various events, many of them triggered by IMAP commands.
标准社区正在制定大容量服务器到客户端状态通知的标准。这种工作的一个例子是简单通知和报警协议（SNAP）[45]，它定义了各种事件的消息存储的预期行为，其中许多事件是由IMAP命令触发的。
A format for message notification for servers reporting status information to other servers (e.g., IMAP4 server to SMS or pager server) MUST be defined. The method for delivery of these notifications MUST also be specified.
必须将消息服务器的状态定义为（例如，将消息服务器的状态定义为）或将消息服务器的状态定义为（例如，将消息服务器的状态定义为）。还必须指定传递这些通知的方法。
The design for this MUST take into account the IAB note: "Unified Notification Protocol Considerations" (Appendix C).
设计时必须考虑IAB注释：“统一通知协议注意事项”（附录C）。
Compared to a LAN/WAN configuration or even to a wire-line dial-up connection, the probability of an interruption to a wireless connection is very high.
与LAN/WAN配置甚至有线拨号连接相比，无线连接中断的概率非常高。
Interruptions can be due to handoff, signal fading, or stepping beyond cell coverage.
中断可能是由于切换、信号衰落或超出小区覆盖范围造成的。
In addition, because the mobile handset is also used for other types of communications, there is a relatively high probability that the data session will be interrupted either by incoming voice calls or by "pushed" messages from services such as SMS, MMS, and WAP.
此外，由于移动手持设备还用于其他类型的通信，因此数据会话被传入的语音呼叫或来自诸如SMS、MMS和WAP等服务的“推送”消息中断的概率相对较高。
It is also common in these environments that the device's IP address change within a session.
在这些环境中，设备的IP地址在会话中更改也是很常见的。
Although the capabilities of wireless handsets are rapidly improving, the wireless handset remains limited in its capability to host email clients. Currently, email access is restricted to only high-end wireless handsets.
尽管无线手机的性能正在迅速提高，但无线手机承载电子邮件客户端的能力仍然有限。目前，电子邮件访问仅限于高端无线手机。
These limitations include:
这些限制包括：
o Client size Handset-resident clients are limited in size because either the handset has limited storage space or the handset vendor/network operator has set a limit on the size of client application that can reside on the handset. o Runtime memory Wireless handsets have limited runtime memory for the use of the mobile email client. o CPU Speed Wireless handsets have CPUs that are inferior to those in conventional systems (PCs) that run email clients. o User Interface Handsets have very limited input and output capabilities. Most of them have only a rudimentary keyboard (a keypad) and a rudimentary pointing device (a text cursor).
o 客户端大小手机驻留客户端的大小是有限的，因为手机的存储空间有限，或者手机供应商/网络运营商对可以驻留在手机上的客户端应用程序的大小设置了限制。o运行时内存无线手机的运行时内存有限，无法使用移动电子邮件客户端。o CPU速度无线手机的CPU低于运行电子邮件客户端的传统系统（PC）中的CPU。o用户界面手机的输入和输出能力非常有限。它们中的大多数只有一个基本的键盘（小键盘）和一个基本的指针设备（文本光标）。
2G mobile networks enabled wireless data communications, but only at very low bandwidths using circuit-switched data. 2.5G and 3G networks improve on this. However, existing email clients require very large files (up to several MBs) -- encountered in multi-media attachments such as presentations, images, voice, and video -- to be downloaded even though mobiles cannot exploit most of the data (because of color depth and screen size limitations). Transferring such large files over the air is of questionable value even when higher wireless bandwidth is available.
2G移动网络实现了无线数据通信，但仅在使用电路交换数据的极低带宽下实现。2.5G和3G网络在这方面有所改进。但是，现有的电子邮件客户端需要下载非常大的文件（高达数MB），这些文件存在于演示文稿、图像、语音和视频等多媒体附件中，即使手机无法利用大部分数据（因为颜色深度和屏幕大小的限制）。即使在无线带宽更高的情况下，通过空中传输如此大的文件的价值也值得怀疑。
In many cases, users of mobile data services are charged by the amount of data (e.g., kilobytes) downloaded to the handset. Most users currently experience a higher per-kilobyte data charge with a wireless service than they do over a wire-line service. Users are
在许多情况下，移动数据服务的用户按下载到手机上的数据量（如千字节）收费。目前，大多数用户在无线服务中的每千字节数据费用要高于在有线服务中的每千字节数据费用。用户是
sensitive to the premium for wireless service. This results in an unwillingness to download large amounts of unnecessary data to the handset and the desire to be able to download only selected content.
对无线服务的溢价敏感。这导致不愿意将大量不必要的数据下载到手机，并且希望只下载选定的内容。
In some cases, the size of file that can be transmitted over the air to the handset is limited. This is a consequence of handset limitations (Section 7.1.2), wireless media and bandwidth issues (Section 7.1.1 and Section 7.1.3.1), and price sensitivity (Section 7.1.3.2).
在某些情况下，通过无线传输到手机的文件大小是有限的。这是手机限制（第7.1.2节）、无线媒体和带宽问题（第7.1.1节和第7.1.3.1节）以及价格敏感性（第7.1.3.2节）的结果。
Wireless terminals are currently limited in their display size, color depth, and ability to present multimedia elements (i.e., if multiple pictures are sent, the mobile can usually present only one reduced-sized picture element at a time rather than the several picture elements at once in the same display that a conventional PC email client would be able to show). Therefore, many email attachments destined for a mobile may require changes in size, color depth, and presentation method in order to be suitably displayed.
无线终端目前在显示尺寸、颜色深度和呈现多媒体元素的能力方面受到限制（即，如果发送多张图片，移动设备通常一次只能显示一个缩小尺寸的图片元素，而不是在传统PC电子邮件客户端能够显示的同一显示器中同时显示多个图片元素）。因此，许多发送至手机的电子邮件附件可能需要更改大小、颜色深度和显示方法，才能正确显示。
Wireless handsets can only display a limited set of media format types. Although PC clients support a large variety of document types (and allow on-demand "codec"/player download), mobiles have very limited support. (For example, most only support WAV audio and cannot play other formats such as AU, MP3 and AIFF.) Furthermore, although almost all new handsets sold today can display images and sound in some advanced format, support for displaying other media or application-specific formats, such as MS Office (TM), is not expected to be widespread in the near future.
无线手机只能显示有限的一组媒体格式类型。尽管PC客户端支持多种文档类型（并允许按需“编解码器”/“播放器下载”），但手机的支持非常有限。（例如，大多数手机只支持WAV音频，不能播放其他格式，如AU、MP3和AIFF。）此外，尽管今天销售的几乎所有新手机都可以以某些高级格式显示图像和声音，但支持显示其他媒体或特定于应用程序的格式，如MS Office（TM），预计在不久的将来不会普及。
As mentioned above, there are many handset types available in the market, and each has different display capabilities, screen characteristics, and processing capabilities. The mobile email service should be able to support as many handset types as possible.
如上所述，市场上有许多手机类型，每种类型都有不同的显示能力、屏幕特征和处理能力。移动电子邮件服务应该能够支持尽可能多的手机类型。
Handsets are unsuitable for perusing entire lengthy documents or presentations. Rather than go through the whole document, a mobile user is more likely to look at several pages of a document or several slides of a presentation and then take action accordingly (e.g., forward the email message to another recipient, print it, or leave the document for later retrieval from another device).
手机不适合阅读整个冗长的文档或演示文稿。与浏览整个文档相比，移动用户更有可能查看文档的几页或演示文稿的几张幻灯片，然后采取相应的行动（例如，将电子邮件转发给另一个收件人，打印它，或将文档留待以后从另一个设备检索）。
Therefore, there is a need to enable users to download not the entire attachment but rather just a selected part of it. For example, users should be able to download the "Table of Contents" of a document; to search within a document; to download the first slide of a presentation; the next slide of this presentation or a range of slides, etc.
因此，需要使用户能够下载的不是整个附件，而是其中选定的一部分。例如，用户应该能够下载文档的“目录”；在文件内搜索；下载演示文稿的第一张幻灯片；本演示文稿的下一张幻灯片或一系列幻灯片等。
The following requirements are derived from the considerations mentioned above.
以下要求源自上述考虑因素。
The mobile email protocol must anticipate transient losses of connectivity and allow clients to recover (restore state) from interrupted connections quickly and easily.
移动电子邮件协议必须预测连接的暂时性丢失，并允许客户端快速轻松地从中断的连接中恢复（恢复状态）。
IMAP4 Context
IMAP4上下文
An IMAP4 connection requires the communication socket to remain up continuously during an email session. In case of transient loss of communications, the connection must be reestablished. It is up to the client to reconnect to the server and return to an equivalent state in the session. This overhead of restoring connections is very costly in response time and additional data transmission.
IMAP4连接要求通信套接字在电子邮件会话期间持续保持打开状态。在通信暂时中断的情况下，必须重新建立连接。由客户机重新连接到服务器并返回会话中的等效状态。这种恢复连接的开销在响应时间和额外的数据传输方面非常昂贵。
To minimize the downloading of data over the air, the user MUST be able to forward a message without initially downloading it entirely or at all to the handset.
为了最大限度地减少空中数据下载，用户必须能够转发消息，而无需最初将其全部或根本下载到手机。
The mobile email protocol MUST support the ability to forward a message without retrieving it.
移动电子邮件协议必须支持转发消息而不检索消息的能力。
This requirement is identical to the TUI requirement described in "Forward Without Download Support" (Section 6.2.1).
该要求与“无下载支持的转发”（第6.2.1节）中描述的TUI要求相同。
The mobile email protocol MUST provide a solution that will enable media streaming to the wireless handset.
移动电子邮件协议必须提供一个能够将媒体流传输到无线手机的解决方案。
This requirement is similar to the TUI requirement described in "Real-Time Playback" (Section 6.1.1.1).
该要求类似于“实时回放”（第6.1.1.1节）中描述的TUI要求。
IMAP4 clients are large because IMAP4 already consists of a complex set of functions (e.g., parsing of a broad variety of MIME formats).
IMAP4客户端很大，因为IMAP4已经包含一组复杂的函数（例如，解析各种MIME格式）。
The mobile email client should be: o Small in size o Efficient in CPU consumption o Efficient in runtime memory consumption
移动电子邮件客户端应该是：o小的大小o高效的CPU消耗o高效的运行时内存消耗
To enable such extremely thin clients, in developing the mobile email protocol we should consider simplifying the IMAP functionality that handsets need to support. However, any such simplification MUST NOT limit interoperability with full IMAP servers.
为了实现这样的瘦客户端，在开发移动电子邮件协议时，我们应该考虑简化手机需要支持的IMAP功能。但是，任何此类简化都不得限制与完整IMAP服务器的互操作性。
The mobile email solution should minimize the amount of data transmitted over the air. There are several ways of pursuing this goal that can be used in conjunction.
移动电子邮件解决方案应尽量减少通过空中传输的数据量。有几种实现这一目标的方法可以结合使用。
One way is the use of content transcoding and media adaptation by the server before message retrieval in order to optimize the message for the capabilities of the receiving handset.
一种方法是在消息检索之前由服务器使用内容转码和媒体自适应，以便针对接收手持设备的能力优化消息。
Another possible optimization is to make the mobile email protocol itself simple, containing as little overhead as possible.
另一个可能的优化是使移动电子邮件协议本身简单，包含尽可能少的开销。
A third approach is to minimize the bandwidth usage as described in "Avoid Content-Transfer-Encoding Data Inflation" (Section 6.1.1.2).
第三种方法是最小化带宽使用，如“避免内容传输编码数据膨胀”（第6.1.1.2节）所述。
As described above, wireless devices have limited ability to handle media. Therefore, the server may be have to perform media manipulation activities to enable the terminal to display the data usefully.
如上所述，无线设备处理媒体的能力有限。因此，服务器可能必须执行媒体操作活动，以使终端能够有效地显示数据。
In order to support the different characteristics and capabilities of the various handset types available in the market correctly, the mobile email protocol must include provision for email content adaptation. For example, the choice of supported file formats, color depth, and screen size. Work on ESMTP transcoding (CONNEG[33]) may address this issue.
为了正确支持市场上各种手机类型的不同特征和功能，移动电子邮件协议必须包括电子邮件内容自适应的规定。例如，支持的文件格式、颜色深度和屏幕大小的选择。ESMTP转码工作（CONNEG[33]）可以解决这个问题。
To support wireless handsets, the server could transcode the message attachments into a representation that is more suitable for that device. This behavior should be based on the device capabilities negotiation as described in "Device Capabilities Negotiation" (Section 7.2.5.1). For example, a device that cannot display GIF format, and can only display WBMP, should get a WBMP image. Devices that cannot display a PDF file should get a text version of the file.
为了支持无线手机，服务器可以将消息附件转换为更适合该设备的表示形式。此行为应基于“设备能力协商”（第7.2.5.1节）中所述的设备能力协商。例如，无法显示GIF格式且只能显示WBMP的设备应获得WBMP图像。无法显示PDF文件的设备应获取该文件的文本版本。
The handset should control what transcoding, if any, is desired. It should be able to retrieve the original attachment without any changes. In addition, the device should be able to choose between "flavors" of the transcoding. ("Present the content as thumbnail image" is an example of such a specific media manipulation.)
手机应控制所需的转码（如有）。它应该能够在没有任何更改的情况下检索原始附件。此外，设备应该能够在转码的“风格”之间进行选择。（“将内容显示为缩略图”是此类特定媒体操作的一个示例。）
Again, work on ESMTP transcoding (CONNEG[33]) may address this issue.
同样，关于ESMTP转码的工作（CONNEG[33]）可以解决这个问题。
A desirable feature (but out of scope for the current LEMONADE charter) is to enable users the choice of retrieving parts of an attachment file, not just the entire attachment. The mobile email protocol should include the ability for the retrieving client to specify selected elements of an attachment for download. Such elements can be, for example, specific pages of a document, the "table of contents" of a document, or specific slides of a presentation.
一个可取的特性（但不在当前LEMONADE charter的范围内）是允许用户选择检索附件文件的一部分，而不仅仅是整个附件。移动电子邮件协议应包括检索客户端指定下载附件的选定元素的能力。例如，这些元素可以是文档的特定页面、文档的“目录”或演示文稿的特定幻灯片。
LEMONADE's charter includes the specification of how enhanced Internet mail will interoperate with existing mobile messaging services (e.g., MMS) to deliver messages to mobile clients.
LEMONADE的章程包括增强型Internet mail如何与现有移动消息服务（如MMS）互操作以向移动客户端发送消息的规范。
E.164 addressing [62] is prevalent in mobile messaging services to address recipient mobiles. Consideration should be given to supporting E.164 addressing for mobile devices in addition to RFC822 addressing.
E.164寻址[62]在移动消息服务中很普遍，用于寻址收件人手机。除了RFC822寻址之外，还应考虑支持移动设备的E.164寻址。
MMS provides a "push" option for message retrieval. The option hides network latencies and reduces the need for user-handheld interaction. If a level of support for mobiles comparable to that of MMS is desired, this mode of operation should be considered.
彩信为信息检索提供“推送”选项。该选项隐藏了网络延迟，减少了用户手持交互的需要。如果需要与MMS相当的手机支持水平，则应考虑此操作模式。
Message notification was alluded to in "Requirements on Message Notification" (Section 6.3). Internet mail has not so far standardized a server-to-client notification protocol although most existing wireless mail systems use notification to avoid needless polling. Client-to-server notification is not within the LEMONADE charter.
“信息通知要求”（第6.3节）中提到了信息通知。尽管大多数现有的无线邮件系统使用通知来避免不必要的轮询，但到目前为止，Internet mail尚未标准化服务器到客户端的通知协议。客户端到服务器的通知不在LEMONADE章程中。
Support for committed delivery is described in Section 6.2.4, but this is different.
第6.2.4节描述了对承诺交付的支持，但这是不同的。
If a push model of message retrieval is supported, the need for selective downloading and SPAM control is especially important.
如果支持消息检索的推送模式，则选择性下载和垃圾邮件控制的需要尤为重要。
Mobile network providers often operate on a "pay for use" service model. This brings in requirements for clearly delineated service transactions that can be reported to billing systems, and for
移动网络提供商通常采用“按使用付费”的服务模式。这就要求能够向计费系统报告的清晰划分的服务事务，以及
positive end-to-end acknowledgement of delivery or non-delivery of messages already mentioned in Section 8.4.1. Note that billing is specifically outside the scope of the IETF.
对第8.4.1节中已提及的消息的传递或未传递进行正面端到端确认。请注意，计费特别超出IETF的范围。
Some mobile networks require network authentication as well as application authentication.
一些移动网络需要网络身份验证和应用程序身份验证。
The 3GPP MMS Reference Architecture ([48] [54]) defines seven interfaces labelled MM1 to MM7, as below:
3GPP MMS参考体系结构（[48][54]）定义了七个标记为MM1到MM7的接口，如下所示：
3GPP MMS Reference Architecture (subset)
3GPP MMS参考体系结构（子集）
|---------| |------------|
wireless ||-------|| | |
device || MMS || | |<- MM2 ->
|| USER |---------------------------| |---------
|| AGENT |<- MM1 ->| | to
||-------|| | | another
|---------| | | MMS
| | relay/
|--------| | | server
e.g., | | | |
Email, |EXTERNAL| | |
Fax, or| SERVER |--------------------------| |
UMS | |<- MM3 ->| |
|--------| | |
| |
|---------| | |
|"FOREIGN"| | |
| MMS |-------------------------| |
| relay/ |<- MM4 ->| |
| server | | |
|---------| | |
| MMS |
|-------| |relay/server|
| | | |
| HLR |---------------------------| |
| |<- MM5 ->| |
|-------| | |
| |
|-------| | |
| MMS | | |
| USER |---------------------------| |
| DBs |<- MM6 ->| |
|-------| | |
| |
|-------| | |
| MMS | | |
| VAS |---------------------------| |
| APPs |<- MM7 ->| |
|-------| |------------|
|---------| |------------|
wireless ||-------|| | |
device || MMS || | |<- MM2 ->
|| USER |---------------------------| |---------
|| AGENT |<- MM1 ->| | to
||-------|| | | another
|---------| | | MMS
| | relay/
|--------| | | server
e.g., | | | |
Email, |EXTERNAL| | |
Fax, or| SERVER |--------------------------| |
UMS | |<- MM3 ->| |
|--------| | |
| |
|---------| | |
|"FOREIGN"| | |
| MMS |-------------------------| |
| relay/ |<- MM4 ->| |
| server | | |
|---------| | |
| MMS |
|-------| |relay/server|
| | | |
| HLR |---------------------------| |
| |<- MM5 ->| |
|-------| | |
| |
|-------| | |
| MMS | | |
| USER |---------------------------| |
| DBs |<- MM6 ->| |
|-------| | |
| |
|-------| | |
| MMS | | |
| VAS |---------------------------| |
| APPs |<- MM7 ->| |
|-------| |------------|
MMS - Multimedia Messaging Service UMS - Unified Messaging Service HLR - Home Location Register DB - Data Base VAS - Value Added Service APP - Application
彩信-彩信服务UMS-统一消息服务HLR-家庭位置寄存器DB-数据库VAS-增值服务应用程序-应用程序
The LEMONADE profile provides an enhanced IMAP mail retrieval protocol suitable for use at interfaces MM1 and MM3.
LEMONADE配置文件提供了一个增强的IMAP邮件检索协议，适合在接口MM1和MM3上使用。
In addition, if the wireless device uses a LEMONADE-enhanced IMAP user agent, the enhanced IMAP protocol can be used to access Internet mail directly, as below.
此外，如果无线设备使用柠檬水增强型IMAP用户代理，则增强型IMAP协议可用于直接访问Internet邮件，如下所示。
3GPP MMS Reference Architecture (subset)
3GPP MMS参考体系结构（子集）
|---------| |------------|
wireless ||-------|| | |
device || IMAP || | |<- MM2 ->
|| USER || | |---------
|| AGENT || | | to
||---^---|| | | another
|----|---|| | | MMS
| LEMONADE Enhanced IMAP and | | relay/
|---V----| SMTP | | server
e.g., | | | |
Email, |EXTERNAL| | |
Fax, or| SERVER |--------------------------| |
UMS | |<- MM3 ->| |
|--------| | |
| |
|---------| | |
|"FOREIGN"| | |
| MMS |-------------------------| |
| relay/ |<- MM4 ->| |
| server | | |
|---------| | |
| MMS |
|-------| |relay/server|
| | | |
| HLR |---------------------------| |
| |<- MM5 ->| |
|-------| | |
| |
|-------| | |
| MMS | | |
| USER |---------------------------| |
| DBs |<- MM6 ->| |
|-------| | |
| |
|-------| | |
| MMS | | |
| VAS |---------------------------| |
| APPs |<- MM7 ->| |
|-------| |------------|
|---------| |------------|
wireless ||-------|| | |
device || IMAP || | |<- MM2 ->
|| USER || | |---------
|| AGENT || | | to
||---^---|| | | another
|----|---|| | | MMS
| LEMONADE Enhanced IMAP and | | relay/
|---V----| SMTP | | server
e.g., | | | |
Email, |EXTERNAL| | |
Fax, or| SERVER |--------------------------| |
UMS | |<- MM3 ->| |
|--------| | |
| |
|---------| | |
|"FOREIGN"| | |
| MMS |-------------------------| |
| relay/ |<- MM4 ->| |
| server | | |
|---------| | |
| MMS |
|-------| |relay/server|
| | | |
| HLR |---------------------------| |
| |<- MM5 ->| |
|-------| | |
| |
|-------| | |
| MMS | | |
| USER |---------------------------| |
| DBs |<- MM6 ->| |
|-------| | |
| |
|-------| | |
| MMS | | |
| VAS |---------------------------| |
| APPs |<- MM7 ->| |
|-------| |------------|
MMS - Multimedia Messaging Service UMS - Unified Messaging Service HLR - Home Location Register DB - Data Base VAS - Value Added Service APP - Application
彩信-彩信服务UMS-统一消息服务HLR-家庭位置寄存器DB-数据库VAS-增值服务应用程序-应用程序
Security will be a very important part of enhanced messaging. The goal, wherever possible, is to preserve the semantics of existing messaging systems and to meet the (existing) expectations of users with respect to security and reliability.
安全性将是增强消息传递的一个非常重要的部分。目标是尽可能保留现有消息传递系统的语义，并满足（现有）用户对安全性和可靠性的期望。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[2] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[3] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[3] Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 3461，2003年1月。
[4] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[4] Myers，J.和M.Rose，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[5] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[6] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[7] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text ", RFC 2047, November 1996.
[7] Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[8] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[8] Freed，N.，Klensin，J.，和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，BCP 13，RFC 2048，1996年11月。
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[9] Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，1996年11月。
[10] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[10] Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[11] Myers, J., "IMAP4 QUOTA extension", RFC 2087, January 1997.
[11] 迈尔斯，J.，“IMAP4配额延长”，RFC 2087，1997年1月。
[12] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[12] Hansen，T.和G.Vaudreuil，“消息处置通知”，RFC 3798，2004年5月。
[13] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[13] Vaudreuil，G.和G.Parsons，“互联网邮件语音配置文件-第2版（VPIMv2）”，RFC 3801，2004年6月。
[14] Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration", RFC 3802, June 2004.
[14] Vaudreuil，G.和G.Parsons，“收费质量语音-32 kbit/s自适应差分脉冲编码调制（ADPCM）MIME子类型注册”，RFC 3802，2004年6月。
[15] Vaudreuil, G. and G. Parsons, "Content Duration MIME Header Definition", RFC 3803, June 2004.
[15] Vaudreuil，G.和G.Parsons，“内容持续时间MIME头定义”，RFC 3803，2004年6月。
[16] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J. Rafferty, "File Format for Internet Fax", RFC 3949, February 2005.
[16] Buckley，R.，Venable，D.，McIntyre，L.，Parsons，G.，和J.Rafferty，“互联网传真的文件格式”，RFC 3949，2005年2月。
[17] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration", RFC 3302, September 2002.
[17] Parsons，G.和J.Rafferty，“标签图像文件格式（TIFF）-图像/TIFF MIME子类型注册”，RFC3302，2002年9月。
[18] Allocchio, C., "Minimal GSTN address format in Internet Mail", RFC 3191, October 2001.
[18] Allocchio，C.，“互联网邮件中的最小GSTN地址格式”，RFC3191，2001年10月。
[19] Allocchio, C., "Minimal FAX address format in Internet Mail", RFC 3192, October 2001.
[19] Allocchio，C.，“因特网邮件中的最小传真地址格式”，RFC3192，2001年10月。
[20] Toyoda, K., Ohno, H., Murai, J., and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 3965, December 2004.
[20] 丰田章男，K.，大野，H.，村井，J.，和D.Wing，“使用互联网邮件的简单传真模式”，RFC 3965，2004年12月。
[21] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) - F Profile for Facsimile", RFC 2306, March 1998.
[21] Parsons，G.和J.Rafferty，“传真用标签图像文件格式（TIFF）-F配置文件”，RFC 2306，1998年3月。
[22] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[22] Gellens，R.和J.Klensin，“信息提交”，RFC 24761998年12月。
[23] Masinter, L. and D. Wing, " Extended Facsimile Using Internet Mail", RFC 2532, March 1999.
[23] Masinter，L.和D.Wing，“使用互联网邮件的扩展传真”，RFC 25321999年3月。
[24] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[24] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[25] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[25] 《简单邮件传输协议》，RFC 28212001年4月。
[26] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[26] Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[27] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003.
[27] Burger，E.，Candell，E.，Eliot，C.，和G.Klyne，“互联网邮件的消息上下文”，RFC 3458，2003年1月。
[28] Burger, E., "Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter", RFC 3459, January 2003.
[28] Burger，E.“关键内容多用途互联网邮件扩展（MIME）参数”，RFC 3459，2003年1月。
[29] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180, July 1997.
[29] Gahrns，M.，“IMAP4多址邮箱实践”，RFC21801997年7月。
[30] Candell, E., "High-Level Requirements for Internet Voice Mail", RFC 3773, June 2004.
[30] Candell，E.“互联网语音邮件的高层次要求”，RFC 3773，2004年6月。
[31] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, April 2003.
[31] Nerenberg，L.，“IMAP4二进制内容扩展”，RFC3516，2003年4月。
[32] Nerenberg, "IMAP4 Channel Transport Mechanism", Work in Progress, November 2001.
[32] Nerenberg，“IMAP4通道传输机制”，正在进行的工作，2001年11月。
[33] Toyoda, K. and D. Crocker, "SMTP Service Extensions for Fax Content Negotiation", Work in Progress, February 2003.
[33] Toyoda，K.和D.Crocker，“传真内容协商的SMTP服务扩展”，正在进行的工作，2003年2月。
[34] McRae, S. and G. Parsons, "Internet Voice Messaging (IVM)", RFC 4239, November 2005.
[34] McRae，S.和G.Parsons，“互联网语音信息（IVM）”，RFC 42392005年11月。
[35] Murchison, K. and L. Greenfield, "LMTP Service Extension for Ignoring Recipient Quotas", Work in Progress, June 2002.
[35] Murchison，K.和L.Greenfield，“忽略收件人配额的LMTP服务扩展”，正在进行的工作，2002年6月。
[36] Crispin, M., "Message Submission", Work in Progress, February 2004.
[36] Crispin，M.，“信息提交”，正在进行的工作，2004年2月。
[37] Newman, C., "Message Submission with Composition", Work in Progress, February 2004.
[37] Newman，C.，“用作文提交信息”，正在进行的工作，2004年2月。
[38] Gellens, R., "IMAP Message Submission", Work in Progress, December 2003.
[38] Gellens，R.，“IMAP信息提交”，正在进行的工作，2003年12月。
[39] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", Work in Progress, December 2003.
[39] Resnick，P.，“因特网消息访问协议（IMAP）连锁扩展”，正在进行的工作，2003年12月。
[40] Crispin, M. and C. Newman, "Internet Message Access (IMAP) - URLAUTH Extension", Work in Progress, July 2004.
[40] Crispin，M.和C.Newman，“互联网消息访问（IMAP）-URLAUTH扩展”，正在进行的工作，2004年7月。
[41] Newman, D., "Message Submission BURL Extension", Work in Progress, July 2004.
[41] Newman，D.，“信息提交BURL扩展”，正在进行的工作，2004年7月。
[42] Crocker, D., "Internet Mail Architecture", Work in Progress, July 2004.
[42] Crocker，D.，“互联网邮件体系结构”，正在进行的工作，2004年7月。
[43] Leuca, I., "Multimedia Messaging Service", Presentation to the VPIM WG, IETF53 Proceedings , April 2002.
[43] Leuca，I.，“多媒体信息服务”，对VPIM工作组的介绍，IETF53会议录，2002年4月。
[44] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.
[44] Mahy，R.，“会话启动协议（SIP）的消息摘要和消息等待指示事件包”，RFC 3842，2004年8月。
[45] Shapira, N. and E. Aloni, "Simple Notification and Alarm Protocol (SNAP)", Work in Progress, December 2001.
[45] Shapira，N.和E.Aloni，“简单通知和报警协议（SNAP）”，正在进行的工作，2001年12月。
[46] Vaudreuil, G., "Messaging profile for telephone-based Messaging clients", Work in Progress, February 2002.
[46] Vaudreuil，G.“基于电话的消息传递客户端的消息传递配置文件”，正在进行的工作，2002年2月。
[47] Burger, E., "Internet Unified Messaging Requirements", Work in Progress, February 2002.
[47] Burger，E.，“互联网统一消息要求”，正在进行的工作，2002年2月。
[48] OMA, "Multimedia Messaging Service Architecture Overview Version 1.1", Open Mobile Alliance (OMA) OMA-WAP-MMS-ARCH-v1_1- 20021101-C, November 2002.
[48] OMA，“彩信服务体系结构概述1.1版”，开放移动联盟（OMA）OMA-WAP-MMS-ARCH-v1_1-20021101-C，2002年11月。
[49] OMA, "Push Architectural Overview", Open Mobile Alliance (OMA) WAP-250-PushArchOverview-20010703-a, July 2001.
[49] OMA，“推动架构概述”，开放移动联盟（OMA）WAP-250-PushArchOverview-20010703-a，2001年7月。
[50] OMA, "Push Access Protocol Specification", Open Mobile Alliance (OMA) WAP-247-PAP-20010429-a, April 2001.
[50] OMA，“推送访问协议规范”，开放移动联盟（OMA）WAP-247-PAP-20010429-a，2001年4月。
[51] OMA, "Push Proxy Gateway Service Specification", Open Mobile Alliance (OMA) WAP-249-PPGService-20010713a, July 2001.
[51] OMA，“推送代理网关服务规范”，开放移动联盟（OMA）WAP-249-PPGService-20010713a，2001年7月。
[52] OMA, "Multimedia Messaging Service; Client Transactions Version 1.1", Open Mobile Alliance (OMA) OMA-WAP-MMS-CTR-v1_1-20021031-C, October 2002.
[52] OMA，“多媒体信息服务；客户端事务版本1.1”，开放移动联盟（OMA）OMA-WAP-MMS-CTR-v1_1-20021031-C，2002年10月。
[53] OMA, "Multimedia Messaging Service; Encapsulation Protocol Version 1.1", Open Mobile Alliance (OMA) OMA-MMS-ENC-v1_1- 20021030-C, October 2002.
[53] OMA，“多媒体信息服务；封装协议版本1.1”，开放移动联盟（OMA）OMA-MMS-ENC-v1_1-20021030-C，2002年10月。
[54] OMA, "User Agent Profile, Version 1.1", Open Mobile Alliance (OMA) OMA-UAProf-v1_1-20021212-C, December 2002.
[54] OMA，“用户代理配置文件，1.1版”，开放移动联盟（OMA）OMA-UAProf-v1_1-20021212-C，2002年12月。
[55] OMA, "Email Notification Version 1.0", Open Mobile Alliance (OMA) OMA-EMN-v1_0-20021031-C, October 2002.
[55] OMA，“电子邮件通知版本1.0”，开放移动联盟（OMA）OMA-EMN-v1_0-20021031-C，2002年10月。
[56] 3GPP, "Third Generation Partnership Project; Technical Specification Group Services and System Aspects; Service aspects; Functional description; Stage 1 Multimedia Messaging Service", 3GPP TS 22.140, 2001.
[56] 3GPP，“第三代合作伙伴关系项目；技术规范组服务和系统方面；服务方面；功能描述；第1阶段多媒体消息服务”，3GPP TS 22.140，2001年。
[57] 3GPP, "Third Generation Partnership Project; Technical Specification Group Terminals; Multimedia Messaging Service (MMS); Functional description; Stage 2", 3GPP TS 23.140, 2001.
[57] 3GPP，“第三代合作伙伴关系项目；技术规范组终端；彩信服务（MMS）；功能描述；第2阶段”，3GPP TS 23.140，2001年。
[58] 3GPP2, "Short Message Service (SMS)", 3GPP2 TSG C.S0015-0, December 1999.
[58] 3GPP2，“短消息服务（SMS）”，3GPP2 TSG C.S0015-012999年12月。
[59] 3GPP2, "Enhanced Message Service (EMS) Stage 1 Description", 3GPP2 TSG S.R0051-0 v1.0, July 2001.
[59] 3GPP2，“增强消息服务（EMS）阶段1描述”，3GPP2 TSG S.R0051-0 v1.0，2001年7月。
[60] CCITT, "Recommendations Q.700-Q.716: Specifications of Signalling System No. 7", CCITT White Book, Volume VI, Fascicle VI.7.
[60] CCITT，“建议Q.700-Q.716：第7号信号系统规范”，CCITT白皮书，第六卷，分册VI.7。
[61] CCITT, "Recommendations Q.721-Q.766: Specifications of Signalling System No.7", CCITT White Book, Volume VI, Fascicle VI.8.
[61] CCITT，“建议Q.721-Q.766：第7号信号系统规范”，CCITT白皮书，第六卷，分册VI.8。
[62] ITU, "E.164: The international public telecommunication numbering plan", ITU-T Recommendations Series E, May 1997.
[62] 国际电联，“E.164：国际公共电信编号计划”，ITU-T建议系列E，1997年5月。
[63] ITU, "Specifications of Signalling System Number 7", ITU White Book, ITU-T Recommendation Q.763.
[63] ITU，“第7号信令系统规范”，ITU白皮书，ITU-T建议Q.763。
[64] ITU, "Interface between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit", ITU-T Recommendation X.25, October 1996.
[64] ITU，“数据终端设备（DTE）和数据电路终端设备（DCE）之间的接口，用于以分组模式运行并通过专用电路连接到公共数据网络的终端”，ITU-T建议X.25，1996年10月。
[65] BELLCORE, "Specifications of Signalling System Number 7", GR-246-CORE Issue 1, December 1994.
[65] BELLCORE，“7号信号系统规范”，GR-246-CORE第1期，1994年12月。
Eric Burger Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, MA 03079 USA
Eric Burger Brooktrout Technology，Inc.美国马萨诸塞州塞勒姆博士Keewaydin 18号，邮编03079
Phone: +1 603 890-7587
EMail: eburger@brooktrout.com
Phone: +1 603 890-7587
EMail: eburger@brooktrout.com
Yair Grosu Comverse 29 Habarzel St. Tel-Aviv 69710 Israel
以色列特拉维夫哈巴泽尔街29号Yair Grosu Comverse 69710
EMail: Yair.Grosu@comverse.com
EMail: Yair.Grosu@comverse.com
Glenn Parsons Nortel Networks P.O. Box 3511 Station C Ottawa, ON K1Y 4H7 Canada
加拿大K1Y 4H7渥太华C站Glenn Parsons Nortel Networks邮政信箱3511
Phone: +1 613 763-7582
EMail: gparsons@nortelnetworks.com
Phone: +1 613 763-7582
EMail: gparsons@nortelnetworks.com
Milt Roselinsky Openwave Systems, Inc. 530 E. Montecito St. Santa Barbara, CA 93103 USA
Milt Roselinsky Openwave Systems，Inc.美国加利福尼亚州圣巴巴拉蒙特西托东部530号，邮编：93103
Phone: +1 805 884-6207
EMail: milt.roselinsky@openwave.com
Phone: +1 805 884-6207
EMail: milt.roselinsky@openwave.com
Dan Shoshani Comverse 29 Habarzel St. Tel-Aviv 69710 Israel
Dan Shoshani Comverse 29以色列特拉维夫哈巴泽尔街69710号
EMail: Dan.Shoshani@comverse.com
EMail: Dan.Shoshani@comverse.com
Alan K. Stebbens Openwave Systems, Inc. 530 E. Montecito St. Santa Barbara, CA 93103 USA
Alan K.Stebbens Openwave Systems，Inc.美国加利福尼亚州圣巴巴拉蒙特西托东部530号，邮编：93103
Phone: +1 805 884-3162
EMail: alan.stebbens@openwave.com
Phone: +1 805 884-3162
EMail: alan.stebbens@openwave.com
Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd. Dallas, TX 75214 USA
美国德克萨斯州达拉斯威廉森路7291号格雷戈里M.沃德鲁伊朗讯科技公司，邮编75214
Phone: +1 214 823-9325
EMail: GregV@ieee.org
Phone: +1 214 823-9325
EMail: GregV@ieee.org
Ari Erev and Noam Shapira (both from Comverse) contributed substantial requirements for IMAP to support a telephone-based (TUI) messaging client. Meir Mendelovich (Comverse) helped in merging the wireless requirements section. Benjamin Ellsworth (Openwave) contributed to mobile messaging architectures and requirements. Yaacov (Jerry) Weingarten (Comverse) and Stephane Maes (Oracle) provided detailed comments on the final document.
Ari Erev和Noam Shapira（均来自Comverse）对IMAP提出了大量需求，以支持基于电话（TUI）的消息传递客户端。Meir Mendelovich（Comverse）帮助合并了无线需求部分。Benjamin Ellsworth（Openwave）对移动通信体系结构和需求做出了贡献。雅科夫（杰里）温加滕（康维斯）和斯蒂芬·梅斯（甲骨文）对最终文件提供了详细的评论。
Appendix C. IAB Note: Unified Notification Protocol Considerations
附录C.IAB注释：统一通知协议注意事项
Note: dated July 10, 2003
注：日期：2003年7月10日
This note was formulated in response to an informal IESG request to look at the architectural issues surrounding a unified notification protocol. The following materials were used as reference: * draft-dusseault-s2s-event-reqs-00.txt (notification requirements) * meeting notes for the LEMONADE WG from IETF 56. * draft-shapira-snap-05.txt (protocol design for SNAP which has some aspects of a generic notification protocol) * the LEMONADE WG charter * Recent email on the Lemonade list * A few presentations from the 1998 UCI workshop on Internet-wide notification
本说明是针对IESG的一项非正式请求而制定的，该请求旨在研究围绕统一通知协议的体系结构问题。以下材料用作参考：*草案-dusseault-s2s-event-reqs-00.txt（通知要求）*IETF 56柠檬水工作组会议记录。*draft-shapira-snap-05.txt（snap协议设计，具有通用通知协议的某些方面）*柠檬水工作组章程*柠檬水列表上最近的电子邮件*1998年UCI互联网范围通知研讨会上的一些演示
* The Web pages for KnowHow, a company founded by Rohit Khare which has a proprietary Internet-wide notification system.
* 由Rohit Khare创建的KnowHow公司的网页，该公司拥有专有的互联网范围通知系统。
Thanks to Lisa Dusseault for providing these references.
感谢Lisa Dusseault提供这些参考资料。
Note that this opinion does not represent IAB concensus, it is just the opinion of the author after having reviewed the references.
请注意，本意见并不代表IAB的一致意见，它只是作者在审阅参考文献后的意见。
After the reviewing the material, it seemed that the same kinds of functionality are being asked from a generic notification protocol as are asked of desktop application integration mechanisms, like OLAY/ COM on Windows or like Tooltalk was on Solaris, but at the level of messaging across the Internet. The desire is that various distributed applications with different application specific mechanisms should be able to interoperate without having an n x n problem of having each application interact with each other application. The cannonical example, which is in a presentation by Lisa Dusseault to LEMONADE from IETF 56, is sending a notification from one application, like XMPP Instant Messaging, and having it delivered on whatever device the recipient happened to be using at the time, like SMS on a cell phone.
在审查材料之后，似乎从通用通知协议中要求的功能与桌面应用程序集成机制中要求的功能相同，如Windows上的OLAY/COM或Solaris上的Tooltalk，但在跨Internet的消息传递级别。我们希望具有不同应用程序特定机制的各种分布式应用程序能够进行互操作，而不会出现每个应用程序与其他应用程序交互的问题。Lisa Dusseault在IETF 56的LEMONADE演示中的cannonical示例是从一个应用程序（如XMPP即时消息）发送通知，并将其发送到收件人当时使用的任何设备（如手机短信）上。
The usual problem with application intergration mechanisms on the desktop is how to get the various applications to actually use the mechanism. For Windows, this is relatively easy, since most application developers see major value-added in their applications being able to play nicely with Microsoft Office. For Tooltalk, unfortunatly, Solaris developers didn't see the 10x improvement, and so it was not used outside of Sun's internally maintained applications and a few flagship applications like Framemaker. If the generic notification mechanism requires application developers and other notification protocol designers to make a major effort to utilize it, including modifying their applications or protocols in some way, the protocol could become "just another notification mechanism" rather than a unifying device, because most application developers and other protocol designers could ignore it.
桌面上应用程序集成机制的常见问题是如何让各种应用程序实际使用该机制。对于Windows，这是相对容易的，因为大多数应用程序开发人员都认为他们的应用程序能够很好地与Microsoft Office配合使用，从而带来了巨大的附加值。对于Tooltalk，不幸的是，Solaris开发人员没有看到10倍的改进，因此它没有在Sun内部维护的应用程序和一些旗舰应用程序（如Framemaker）之外使用。如果通用通知机制要求应用程序开发人员和其他通知协议设计人员做出重大努力加以利用，包括以某种方式修改其应用程序或协议，则该协议可能会成为“另一种通知机制”，而不是统一的设备，因为大多数应用程序开发人员和其他协议设计人员可能会忽略它。
So the first architectural consideration is how do clients of a particular protocol (and the word "client" is used here to mean "any entity using the protocol", they may peers or they may be client/server) actually utilize the generic notification protocol? Is there some code change required in the client or can a legacy client interoperate without change?
因此，第一个架构考虑是特定协议的客户端（这里使用的“客户端”一词表示“使用该协议的任何实体”，它们可以是对等方，也可以是客户端/服务器）如何实际使用通用通知协议？客户机中是否需要一些代码更改，或者遗留客户机是否可以在不更改的情况下进行互操作？
If you look at Fig. 1 in draft-shapira-snap-05.txt, the answer seems to be that the notifying client uses the generic protocol, SNAP in this case, to a functional entity (server? module on the receiving client?) called the "Notification Service" that processes the generic
如果您查看draft-shapira-snap-05.txt中的图1，答案似乎是通知客户机使用通用协议（本例中为snap）连接到一个称为“通知服务”的功能实体（接收客户机上的服务器？模块），该功能实体处理通用协议
notification into an application specific notification and sends that notification to the client. From this figure it looks as if the notifying client would require modification but the receiving client wouldn't.
通知转换为特定于应用程序的通知，并将该通知发送给客户端。从这个图上看，似乎通知客户端需要修改，但接收客户端不需要。
Another characteristic of application integration mechansims is that they typically focus on very simple operations, the semantics of which are shared between different applications. Examples are "here's a rectangle, display yourself in it" or "put this styled text object into the clipboard", and applications agree on what styled text means. More complicated semantics are hard to share because each application has its own particular twist on the meaning of a particular sequence of operations on a collection of objects. The result is a "least common denominator" collection of integration mechanisms, primarily focussed on display integration and, to a lesser extent, cut and paste integration.
应用程序集成mechansims的另一个特点是，它们通常专注于非常简单的操作，这些操作的语义在不同的应用程序之间共享。例如“这是一个矩形，在其中显示您自己”或“将此样式文本对象放入剪贴板”，应用程序对样式文本的含义达成一致。更复杂的语义很难共享，因为每个应用程序在对象集合上的特定操作序列的意义上都有其特定的扭曲。其结果是集成机制的“最小公分母”集合，主要集中在显示集成上，其次是剪切粘贴集成。
In the context of a generic notification protocol, this raises several possible issues. One is addressing, which is identified draft-dusseault-s2s-event-reqs-00.txt, but in a sense this is the easiest to resolve, by using existing and perhaps newly defined URIs. A more complex problem is matching the semantics of what preconditions constitute the trigger for an event across different application notification mechanisms. This is of course necessary for translating notifications between the different event notification mechanisms and the generic mechanism, but, more problematically, it is also required for a subscription service whereby subscriptions can be made to filter events using the generic notification mechanism and the subscriptions can be translated to different application specific mechanisms. Any language for expressing generic subscriptions is unlikely to support expressing the fine points in the different application notification semantics. Note that SNAP does not seem to support a subscription service so perhaps this isn't an issue for SNAP.
在通用通知协议的上下文中，这会引发几个可能的问题。一个是寻址，标识为draft-dusseault-s2s-event-reqs-00.txt，但在某种意义上，这是最容易解决的问题，可以使用现有的或者新定义的URI。一个更复杂的问题是跨不同的应用程序通知机制匹配构成事件触发器的前提条件的语义。这对于在不同的事件通知机制和通用机制之间转换通知当然是必要的，但是，更麻烦的是，订阅服务也需要它，通过订阅可以使用通用通知机制过滤事件，并且可以将订阅转换为不同的应用程序特定机制。任何表示通用订阅的语言都不太可能支持在不同的应用程序通知语义中表达细节。请注意，SNAP似乎不支持订阅服务，因此这可能不是SNAP的问题。
Another architectural issue, which was discussed earlier this year on the LEMONADE list w.r.t. some other topics, is gatewaying. The cannonical example above (message sent using XMPP and arriving via SMS on a cell phone) is actually a gateway example, because it would require translation between an IP-based messaging mechanism (XMPP) to a PSTN based mechanism (SMS). The problem with using a unified notification mechanism for this purpose is that if there are other functions common between the two, it is likely that a gateway will be built anyway. In fact, one of the work items for LEMONADE is to investigate such gateways. The value of a generic notification mechanism therefore needs to be assessed in the light of this.
另一个架构问题是网关，今年早些时候在柠檬水列表w.r.t.和其他一些主题中讨论过。例如，使用短信到达（XMONICAL）和短信到达（XMONICAL）机制，将需要在手机（XMPP）和短信到达（XMONICA）之间发送短信。为此目的使用统一通知机制的问题在于，如果两者之间存在其他通用功能，则很可能会构建网关。事实上，柠檬水的工作项目之一就是研究这样的入口。因此，需要根据这一点评估通用通知机制的价值。
These are the primary architectural issues, but there are a few others that need consideration in any major system development effort. End to end security is one, draft-dusseault-s2s-event-reqs-00.txt talks about this quite extensively, so it won't be repeated here. The major issue is how to ensure that the end to end security properties are maintained in the face of movement of the notification through the generic intermediary protocol. Another issue is scalability. Peer to peer v.s. server based mechanisms have implications for how scalable the notification mechanism would be, and this needs consideration. Extensibility needs careful consideration. What is required to integrate a new application? Ideally, with time, application developers will stop "rolling their own" notification service and simply use the generic service, but this ideal may be extremely hard to achieve, and may depend to a large extent on market acceptance.
这些是主要的体系结构问题，但是在任何主要的系统开发工作中都需要考虑其他一些问题。端到端安全是其中之一，draft-dusseault-s2s-event-reqs-00.txt非常广泛地讨论了这一点，因此这里不再重复。主要问题是如何确保在通知通过通用中介协议移动时维护端到端安全属性。另一个问题是可伸缩性。基于对等v.s.服务器的机制对通知机制的可伸缩性有影响，这需要考虑。可扩展性需要仔细考虑。集成新应用程序需要什么？理想情况下，随着时间的推移，应用程序开发人员将停止“滚动他们自己的”通知服务，而只使用通用服务，但这一理想可能极难实现，并且可能在很大程度上取决于市场接受度。
Finally, there are some considerations that aren't architectural but may impact the ultimate success of a generic notification protocol, in the sense that the protocol becomes widely deployed and used. The author's experience is that IETF has not had particular success in introducing mechanisms that unify or supplant existing proprietary mechanisms unless strong vendor and service provider by-in is there. Two examples are instant messaging and service discovery. With instant messaging, it seems that a standarized, unified instant messaging protocol has been delayed by the lack of committment from major service providers. With service discovery, weak commitment from vendors has resulted in the continued introduction of vendor specific service discovery solutions even after an IETF standard is in place. The situation with service discovery (with which the author is most familiar) resulted from a lack of major vendor committment during the end phases of the standarization process. Applying these lessions to a generic notification protocol, having important players with proprietary notification protocols on board and committed until the conclusion of the design process will be crucial. Major committment is needed from various application notification protocols before a generic mechanism could succeed. Given the amount of time and effort required in any IETF standardization work, assessing these with an objective eye is critical, otherwise, regardless of how technically well designed the protocol is, deployment success may be lacking. Having an elegently design solution that nobody deploys is an outcome that might be wise to avoid.
最后，还有一些不是架构性的考虑，但可能会影响通用通知协议的最终成功，因为该协议将得到广泛部署和使用。作者的经验是，IETF在引入统一或取代现有专有机制的机制方面没有取得特别成功，除非有强大的供应商和服务提供商。两个例子是即时消息和服务发现。对于即时消息，由于缺乏主要服务提供商的承诺，标准化、统一的即时消息协议似乎被推迟了。在服务发现方面，供应商承诺不足导致了供应商特定的服务发现解决方案的持续引入，即使在IETF标准到位之后也是如此。服务发现的情况（作者最熟悉的情况）是由于标准化过程的最后阶段缺乏主要供应商的承诺。将这些定义应用于通用通知协议，让拥有专有通知协议的重要参与者加入并承诺直到设计过程结束，这一点至关重要。在通用机制成功之前，需要来自各种应用程序通知协议的主要承诺。考虑到任何IETF标准化工作所需的时间和精力，用客观的眼光评估这些工作是至关重要的，否则，无论协议在技术上设计得多么好，部署成功都可能不够。拥有一个无人部署的设计简单的解决方案可能是明智的选择。
James Kempf July 2003
詹姆斯·坎普夫2003年7月
Author's Address
作者地址
Jin Kue Wong (Editor) Nortel Networks P.O. Box 3511 Station C Ottawa, ON K1Y 4H7 Canada
黄金贵（编辑）加拿大K1Y 4H7渥太华C站3511号北电网络邮政信箱
Phone: +1 613 763-2515
EMail: j.k.wong@sympatico.ca
Phone: +1 613 763-2515
EMail: j.k.wong@sympatico.ca
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。