Request for Comments: 4416 Nortel Networks
Category: Informational February 2006
Goals for Internet Email to Support Diverse Service Environments
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).
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.
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.
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.
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
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
1. Introduction
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.
In the recent past, IETF mail standards have evolved to support
additional/merged functionality:
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.
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]).
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.)
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:
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.
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.
2. Conventions Used in This Document
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].
3. Messaging Terminology and Simple Model (Client-to-Server Aspect
Only)
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].
3.1. Messaging Transaction Models
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.
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.
3.2. Mobile Messaging Transactions
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
+-------+ +------+ +-------+
|Mail |-------(1)------>| |-----------(2)-------->|Mail |
|Client | Submit msg | | Notification /|Client |
+-------+ | | / +--+----+
| | / ^
| |<----------(3)-----+ /
|Server| Retrieval request /
| | /
| | /
| |-----------(4)-------+
| | Retrieval response
| |
+------+
Simple Messaging Model
3.2.1. Submission
"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.
3.2.2. Notification
"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.
3.2.3. Retrieval
"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.
4. Profiles
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.
4.1. Existing Profiles
The following are examples of server-to-server profiles of SMTP and
MIME. Except for IVM, they do not address client-to-server
interactions.
4.1.1. Voice Messaging (VPIMv2)
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
Notification and Delivery Status Message ([12], [3]). Voice media
has also been added to multi-part message bodies.
4.1.2. iFax
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.
4.1.3. Internet Voice Mail (IVM) [34]
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.
4.2. Putative Client Profiles
4.2.1. TUI
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.
The following figure depicts the architecture of current voice mail
systems implementing 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
|----------------voice messaging system -------------|
Mail client consists of: TUI (Telephone User Interface) and
TUA (Telephone User Agent)
Communication between TUI and TUA is proprietary.
Email server consists of: MS (Mail Store) and
MTA (Message Transfer Agent)
Communication between MS and MTA is proprietary.
It is proposed that the Proprietary Protocol be replaced with an IETF
standard protocol:
|-------------|