information must be kept synchronized with the state of the store.
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.
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.
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.
6.3.1. Additional Requirements on Message Notification
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).
7. Issues and Requirements: WUI Mobility Aspects
7.1. Wireless Considerations on Email
7.1.1. Transport Considerations
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.
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.
It is also common in these environments that the device’s IP address
change within a session.
7.1.2. Handset-Resident Client Limitations
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).
7.1.3. Wireless Bandwidth and Network Utilization Considerations
7.1.3.1. Low Bandwidth
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.
7.1.3.2. Price Sensitivity
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.
7.1.3.3. File Size Limitations
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.4. Content Display Considerations
7.1.4.1. Display Size and Capabilities
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.
7.1.4.2. Supported Media Formats
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.
7.1.4.3. Handset Type Variety
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.
7.1.4.4. Specific Attachment Display Scenarios
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.
7.2. Requirements to Enable Wireless Device Support
The following requirements are derived from the considerations
mentioned above.
7.2.1. Transport Requirements
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
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.
7.2.2. Enhanced Mobile Email Functionality
7.2.2.1. Forward without Fetch
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).
7.2.2.2. Media Streaming
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).
7.2.3. Client Requirements
IMAP4 clients are large because IMAP4 already consists of a complex
set of functions (e.g., parsing of a broad variety of MIME formats).
The mobile email client should be:
o Small in size
o Efficient in CPU consumption
o Efficient in runtime memory consumption
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.
7.2.4. Bandwidth Requirements
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).
7.2.5. Media Handling Requirements
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.
7.2.5.1. Device Capabilities Negotiation
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.
7.2.5.2. Adjusting Message Attachments for Handset Abilities
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.
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.
7.2.5.3. Handling Attachment Parts
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.
8. Interoperation with Existing Mobile Messaging
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.
8.1. Addressing of Mobile Devices
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.
8.2. Push Model of Message Retrieval [49] [50] [51]
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.
8.3. Message Notification [44] [55]
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.
8.4. Operator Issues
8.4.1. Support for End-to-End Delivery Reports and Message-Read Reports
Support for committed delivery is described in Section 6.2.4, but
this is different.
8.4.2. Support for Selective Downloading
If a push model of message retrieval is supported, the need for
selective downloading and SPAM control is especially important.
8.4.3. Transactions and Operator Charging Units
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.4. Network Authentication
Some mobile networks require network authentication as well as
application authentication.
8.5. LEMONADE and MMS
The 3GPP MMS Reference Architecture ([48] [54]) defines seven
interfaces labelled MM1 to MM7, as below:
3GPP MMS Reference Architecture (subset)
|---------| |------------|
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
The LEMONADE profile provides an enhanced IMAP mail retrieval
protocol suitable for use at interfaces MM1 and 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.
3GPP MMS Reference Architecture (subset)
|---------| |------------|
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 ->| |
|-------| | |
| |