Internet DRAFT - draft-maes-lemonade-mobile-email
draft-maes-lemonade-mobile-email
<Lemonade and Mobile e-mail> July 2005
Lemonade
Internet Draft: Mobile E-mail S. H. Maes
Document: draft-maes-lemonade-mobile-email-04.txt Oracle Corporation
Expires: January 2006 July 2005
Lemonade and Mobile e-mail
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she becomes aware will be disclosed, in accordance with
Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Maes Expires - January 2006 [Page 1]
<Lemonade and Mobile e-mail> July 2005
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes the challenges with mobile e-mail in order to
identify the challenges that are within the mobile profile of
Lemonade.
Conventions used in this document
In examples, "M:", "I:" and "S:" indicate lines sent by the client
messaging user agent, IMAP e-mail server and submit server
respectively.
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].
An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocol(s) it
implements. An implementation that satisfies all the MUST or REQUIRED
level and all the SHOULD level requirements for a protocol is said to
be "unconditionally compliant" to that protocol; one that satisfies
all the MUST level requirements but not all the SHOULD level
requirements is said to be "conditionally compliant." When
describing the general syntax, some definitions are omitted as they
are defined in [RFC3501].
Table of Contents
Status of this Memo ........................................... 1
Abstract....................................................... 2
Conventions used in this document.............................. 2
Table of Contents.............................................. 2
1. Introduction................................................ 3
1.1. Definitions ........................................... 3
1.2. Main Expectations...................................... 3
1.3. Additional Considerations.............................. 4
1.4. Main Actors ........................................... 5
1.5. Other players in ecosystem............................. 5
2. Challenges.................................................. 5
2.1. Devices................................................ 5
2.2. Networks and operators................................. 5
Maes Expires - January 2006 [Page 2]
<Lemonade and Mobile e-mail> July 2005
2.3. Enterprises and other e-mail service providers......... 7
3. Usage models................................................ 7
3.1. Usage Pattern.......................................... 7
3.2. Deployment models...................................... 8
3.3. Deployment model A..................................... 8
3.4. Deployment model B..................................... 9
3.5. Deployment model C..................................... 9
3.5.1. Deployment model C.1.............................. 9
3.5.2. Deployment model C.2.............................. 9
3.6. Deployment model D.....................................10
4. Recommendations on Lemonade work and specifications.........10
4.1. Scope recommendations..................................10
4.2. Objectives.............................................11
4.3. Principles.............................................11
4.4. Topics to explicitly address...........................12
4.5. Lemonade goals for mobile e-mail.......................12
Security Considerations........................................12
References.....................................................13
Version History................................................13
Acknowledgments................................................14
Authors Addresses..............................................14
Intellectual Property Statement................................14
Full Copyright Statement.......................................15
1. Introduction
This document describes the challenges associated to mobile e-mail.
1.1. Definitions
Mobile e-mail is defined as "Access to e-mail while mobile";
typically from a mobile device.
1.2. Main Expectations
The main expectations for mobile e-mail are:
- To receive quasi-instantaneous notification of new e-mails
when within coverage (if setup this way)
- To reflect quasi-instantaneously new e-mail or e-mail server
events in the mobile client when within coverage
- To send quasi-instantaneously e-mail composed on mobile
client from appropriate e-mail server when within coverage or
as soon that coverage is established otherwise
- To efficiently manipulate e-mails / drafts / attachment as
needed
or as preferred
- End-to-end secure when needed (e.g. e-mails may at no point
be in clear outside enterprise domain)
Maes Expires - January 2006 [Page 3]
<Lemonade and Mobile e-mail> July 2005
- Low or at least bearable cost of usage (e.g. traffic /
bandwidth optimization, predictable cost, manageable traffic,
...)
Note that the notion of quasi-instantaneous refers to the impression
of the user and not to a particular precise duration: the user has
the feeling that something happens in a way that is quasi-
instantaneous. This may be equivalent to some desktop user experience
or sometimes be faster or slower than desktop. That is not important
as the user can usually not compare. On the other hand, some overall
behavior clearly violate this principle (e.g. if the client waits for
the user to "browse" its mailbox with a client to download the
headers or even the whole messages).
1.3. Additional Considerations
The following considerations are also important for mobile e-mail:
- Need for graceful degradation (e.g. being able to access e-
mail while mobile through other channels like voice/DTMF,
Messaging (SMS, MMS, IM, à), WAP Push and browsing
- Need for server-to-client notifications that clients can
display instead if acting on and that informs the user.
- Format adaptation (attachments, page, ...):
- Format conversion
- Adaptation to device capabilities and form factor
- streamed versus downloaded multi-media
- DRM (Digital Right Management) rules: how to respect DRM
rules like forward lock
- Provisioning / setup: These are extremely challenging on
mobile devices with limited or challenging input capabilities.
Also average users are more easily confused and unable to
correctly setup mobile phones
- Charging: Operator want to maintain charging to create a
viable business model. They may be less inclined to deploy or
support mobile email solutions that do not permit charging for
e-mail services.
- Synchronization with other clients:
- e.g. Peer to peer vs. with server (SyncML / OMA DS and other
real time synchronization protocols, ...) and how to allow a
same repository to sometimes access e-mail on the server via
mobile access over the air and sometimes access it via
synchronization with the email repository on a laptop that
itself sometimes access email from the email server.
- Relationship to PIM (agenda / Address Book): mobile e-mail
can also support the exchange of PIM events as payload or
attachments (e.g. considering the calendar or address book
repository as another e-mail folder).
Maes Expires - January 2006 [Page 4]
<Lemonade and Mobile e-mail> July 2005
1.4. Main Actors
The main actors are:
- Users
- Operators of the mobile network
- E-mail service providers:
- Service providers (e.g. Operators, other e-mail server
providers)
- Enterprises
1.5. Other players in ecosystem
Other actors influence decisions related to mobile e-mail:
- Device Manufacturers
- Client software providers
- E-mail server manufacturers:
- E-mail server
- Mobile e-mail enablement server
2. Challenges
2.1. Devices
Devices present the following challenges that directly impact mobile
e-mail:
- Constrained memory / processing power (always improving):
- Wide range to support
- Limited battery life (will remain a problem for a long
time):
- Constrains processing capability
- Constrains connectivity patterns (not always fully
connected but may be awaken via outband notifications...)
- Notifications / wake-up are to be supported by mobile
e-mail
- Constraints acceptable bandwidth
- More exotic platforms:
- Sometimes proprietary or closed
- Challenging or controlled software distribution channels:
- Installing, provisioning, supporting, upgrading,...
- E.g. DRM trusted clients
- Wide range of control models by:
- Device manufacturer, operator, enterprise, user
2.2. Networks and operators
Mobile networks and operators impose additional constraints that must
be taken into account when designing mobile e-mail solutions:
- Different underlying network technologies / bearers with
different behavior / capabilities
Maes Expires - January 2006 [Page 5]
<Lemonade and Mobile e-mail> July 2005
- Intermittent connectivity:
- Loss of coverage
- Nature of mobility (e.g. radio turned off in planes)
- Temporary IP addresses
- Unreliable delivery (Connection)
- Underlying network layer (up to transport) may drop at any
time. Even if then re-established, sessions at the transport
level are maintained only if the transport protocol provide
mechanisms to maintain it when the network connection is re-
established. Otherwise, additional mechanisms are needed at
the application protocol layer to establish and maintain or
recover session if a session is needed or assumed.
- As a result notifications schemes like IDLE perform poorly
when used as intended (i.e. without improvements) over a
reliable network
- Out band notification schemes
- Unreliable
- But can be used as "wake up / notification scheme"
- Limited bandwidth:
- Limited capabilities shared across all users
- Roaming within and across domain / operators / technologies
- Cost of usage:
- Multiple cost models (free, unlimited, per packet, per
service / type of service, ...)
- In general, costly and in need of optimization to maintain
cost acceptable enough to user and to allow operator to share
network with enough users.
- Controlled:
- Walled garden:
- Inbound and outbound traffic
- Internal traffic
- With its own authentication mechanisms etc...
- Regulated:
- QoS
- Privacy
- Exchanged data
- Reachability
- Logging
- Accountability, support desk (inexperienced users, hard to
provision)
- ...
- Huge subscriber sets
- Server scalability is critical (e-mail server / Mobile e-mail
Enabling Server / network)
- Solutions that tie-up one or more ports per device or user
are not easily scalable
- e.g. IDLE sessions for each devices tie-up ports and
create large queues.
- Support desk challenges
Maes Expires - January 2006 [Page 6]
<Lemonade and Mobile e-mail> July 2005
- Time outs introduced by numerous intermediaries, firewalls,
gateways etc
2.3. Enterprises and other e-mail service providers
Enterprises must reconcile mobile e-mail deployments with the
following requirements:
- Walled garden intranets:
- Firewalls, VPN, ...
- IT Corporate security guidelines:
- Wide range - in general VERY conservative e.g.
- Require end-to-end security
- Allowed applications / usages / content
- Firewalls / ports / protocols
- (e.g. only HTTP or HTTPS; no SSL/TLS)
- Time-outs
- No storage of company data outside intranet on
defined servers (in clear or not). This is why MMS
solutions are not acceptable. Current e-mail
infrastructure with untraceable potential
intermediate storage is accepted.
- Regulated:
- E.g. Journaling / Storage of all corporate e-mails
- Control usage costs and support (including provisioning)
- Need to integrate with existing IT infrastructure (instead
of replacing them).
- Similar scalability need of email servers / mobile email
enabling servers.
- Time outs introduced by firewalls etc...
3. Usage models
3.1. Usage Pattern
The generic usage pattern model to support mobile e-mail includes:
- Mobile e-mail server (backend e.g. IMAP server):
- This is typically a regular e-mail server. It may consist of
several servers (e.g. IMAP4 server and SMTP server or POP3
server and SMTP server).
- Connector:
- The connector includes any protocol adaptation required
between the e-mail server and mobile e-mail enabling server.
- Mobile e-mail enabling server:
- The mobile e-mail enabler implements the server-side
functionality of the mobile e-mail specifications.
- Mobile e-mail client:
- The mobile e-mail client implements the client-side
functionality of the mobile e-mail specifications.
Maes Expires - January 2006 [Page 7]
<Lemonade and Mobile e-mail> July 2005
- The mobile e-mail protocol between the mobile e-mail client and
mobile e-mail enabling server.
- Mobile enablers that support functions needed by the OMA mobile
e-mail enabler. E.g.:
- Outband notifications
- Provisioning
- ...
3.2. Deployment models
These different components may be deployed in different domains that
may be separated by firewalls.
Possible deployments include:
A: Mobile e-mail by operators: "operator hosted e-mail service"
- Device in network
- Mobile "enabled" email server in OperatorÆs Domain
- Roaming across compatible networks / operators
B: Mobile e-mail by E-mail service provider (enterprise, ISP):
- Device in operator network (including roaming)
- Mobile "enabled" email E-mail server in service provider
C: Outsourced mobile enablement of E-mail service provider:
1. By Operator (operator hosted)
2. By other third party service provider
- Device in operator network (including roaming)
- E-mail server in other domain
D: As above, but with proxies in addition to the mobile e-mail
enabling server.
3.3. Deployment model A
Deployment A is characterized by:
* In operator(s) domain:
- Mobile e-mail server (backend e.g. IMAP server)
- Connected (e.g. via IMAP) through a "connector"
- to a mobile e-mail enabling server
- Connected:
- Via mobile e-mail protocol to a mobile e-mail client
- Via other protocols to mobile enablers that support
functions like:
- Outband notifications
- Provisioning
- ...
Firewalls may exist:
- Between:
- Mobile client and mobile e-mail enabling server
- Mobile enablers and mobile e-mail enabling server
Maes Expires - January 2006 [Page 8]
<Lemonade and Mobile e-mail> July 2005
3.4. Deployment model B
Deployment B is characterized by:
* In E-mail Service Provider domain:
- Mobile e-mail server (backend e.g. IMAP server)
- Connected (e.g. via IMAP) through a "connector"
- to a mobile e-mail enabling server
- Connected:
* In Operator(s) domain:
- Via mobile e-mail protocol to a mobile e-mail client
- Via other protocols to mobile enablers that support
functions like:
- Outband notifications
- Provisioning
- ...
Firewalls may exist:
- 1) Between connectors and mobile e-mail enabling server
- 2) Between:
- Mobile client and mobile e-mail enabling server
- Mobile enablers and mobile e-mail enabling server
3.5. Deployment model C
3.5.1. Deployment model C.1
Deployment C.1 is characterized by:
* In E-mail Service Provider domain:
- Mobile e-mail server (backend e.g. IMAP server)
- Connected (e.g. via IMAP) through a "connector"
* In Operator(s) domain:
- to a mobile e-mail enabling server
- Connected:
- Via mobile e-mail protocol to a mobile e-mail client
- Via other protocols to mobile enablers that support
functions like:
- Outband notifications
- Provisioning
- ...
Firewalls may exist:
- 1) Between connectors and mobile e-mail enabling server
- 2) Between:
- Mobile client and mobile e-mail enabling server
- Mobile enablers and mobile e-mail enabling server
3.5.2. Deployment model C.2
Maes Expires - January 2006 [Page 9]
<Lemonade and Mobile e-mail> July 2005
Deployment C.2 is characterized by:
* In E-mail Service Provider domain:
- Mobile e-mail server (backend e.g. IMAP server)
- Connected (e.g. via IMAP) through a "connector"
* In third party service provider:
- to a mobile e-mail enabling server
- Connected:
* In Operator(s) domain:
- Via mobile e-mail protocol to a mobile e-mail client
- Via other protocols to mobile enablers that support
functions like:
- Outband notifications
- Provisioning
- ...
Firewalls may exist:
- 1) Between connectors and mobile e-mail enabling server
- 2) Between:
- Mobile client and mobile e-mail enabling server
- Mobile enablers and mobile e-mail enabling server
3.6. Deployment model D
Proxies are involved in front of mobile e-mail enabling server. This
allows protocol adaptation to possibly take place within the e-mail
server domain while the proxy handles the firewall challenges
[LEMONADEINTERMEDIARIES].
4. Recommendations on Lemonade work and specifications
<<EditorÆs Note: This section will evolve as the work at Lemonade
evolves and in particular as work towards a mobile profile is
inititated.>>
4.1. Scope recommendations
LemonadeÆs raison dÆŠtre and charter [LEMONADECHARTER] is to enhance
Internet email to support diverse service environments. Considering
the attention paid by the industry to mobile and/or push e-mail and
success of early proprietary solutions, it is natural that IETF
Lemonade considers enhancing its internet mail protocols to support
mobile email.
As discussed above, and as illustrated by the user experience and
features of todayÆs pioneer deployments, mobile e-mail is different
from regular internet mail confronted to the specific constraints and
limitations of the networks, the technologies and their deployments
by multiple actors... Problems are no only technical; some may be
rather linked to non-recommended deployments or usages of these
Maes Expires - January 2006 [Page 10]
<Lemonade and Mobile e-mail> July 2005
technologies because of a variety of technical, business or legal
reasons.
Other standard activities, like the OMA (Open Mobile Alliance), have
started work on mobile e-mail. It is critical that a standard mobile
e-mail solution be based on profiles and extensions of the Internet
email and interoperate well with it rather completely different
approaches that are not built on the Internet email protocols that
may take much longer to be designed and deployed and may not benefit
of the year of experience that IETF and the industry have acquired
developing, implementing and deploying e-mail.
From a timing point of view, IETF Lemonade work seems to be ideally
placed to allow rapid development of specifications to support mobile
e-mail. It is not clear that any other standard technology today can
easily be used or extended to satisfy the requirements and
expectation of an open standard mobile e-mail specification.
4.2. Objectives
So the Lemonade working group MUST look at the problems of mobile e-
mail in their entirety.
Lemonade MUST specify or a mobile e-mail protocol or specify a set of
optimizations "inspired" from mobile e-mail to address as much as can
be within the scope of IETF.
When issues are deemed beyond the scope of IETF, Lemonade SHOULD
analyze options to address all of the issues via guidelines or
recommendations to other standard activities.
If needed LemonadeÆs charter [LEMONADECHARTER] MUST be updated to
cover the above.
4.3. Principles
As design principles, it is recommended that:
- Lemonade MUST design its protocol to allow use of its messages
and principles with other transport mechanisms (e.g. HTTP
bindings, outband notification mechanisms, ...) when needed to
address some of the mobile e-mail challenges identified in this
document.
- Accordingly, Lemonade MUST NOT make assumptions on the
underlying network transport or design choices that would
prevent addressing all these issues even if their resolution is
outside the scope of IETF (network neutrality). This implies in
particular allowing:
- Compression at the application level
- Encryption
Maes Expires - January 2006 [Page 11]
<Lemonade and Mobile e-mail> July 2005
- The possibility to bind Lemonade to HTTP/HTTPS.
4.4. Topics to explicitly address
Lemonade should start investigation addressing or specifying:
- IMAP protocol optimizations (to reduce traffic between client
and server:
- Reduction of roundtrip
- Compression of data exchanges:
- Transport level
- Application level shown very useful for example when
attachments are exchanged.
- Support for notifications mechanisms:
- Client to server
- Server to server
- Filtering (setup and changes):
- Message filters
- Notifications filters
- Dealing with problems of intermediaries with respect to mobile
e-mail (see also [LEMONADEINTERMEDIARIES]):
- Implications on end-to-end security, compression and
stability of the connection.
- Realities of todayÆs deployment models and business
models.
- Attachment / body part adaptation:
- Format conversions
- Streaming
- Adaptation to device capability and form factor
- Attachment manipulation:
- Forward without download
- Others?
- Improved reliability to connection / network drops
- Efficient quick reconnect scheme
- Provisioning
4.5. Lemonade goals for mobile e-mail
The Lemonade WG must target to provide support via its Lemonade
profile and protocol specifications to the mobile e-mail enabler
specified by OMA. Requirements can be found as [OMA-ME-RD].
Security Considerations
The Mobile e-mail protocols must address / support security issues
raised by:
- The different deployment models identified in section 3. In
particular:
Maes Expires - January 2006 [Page 12]
<Lemonade and Mobile e-mail> July 2005
- End-to-end security with no message in the clear when the
mobile e-mail enabling server is outside the e-mail service
provider domain.
- No storage of e-mail (in the clear or not) outside the
control and domain of the e-mail service provider
- Secure notifications when relevant information is carried
the notifications.
- Support for the restrictions introduced by the presence of
firewalls with constraints typically met in such firewall
deployments (e.g. corporate guidelines that open only HTTP or
HTTPS ports).
- On bandwidth limited mobile networks where users pay per data
volumes and/or notifications, spam may become an important issue.
It can be mitigated with appropriate filters and server-side spam
prevention tools.
References
[LEMONADECHARTER] IETF Charter for ôEnhancements to Internet email to
support diverse service environments (lemonade)",
http://www.ietf.org/html.charters/lemonade-charter.html.
[LEMONADEINTERMEDIARIES] Maes, S.H. and D. Crocker, ôLemonade and the
challenges of Intermediaries", draft-maes-lemonade-intermediary-
challenges-xx.txt, (work in progress).
[LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile",
draft-ietf-lemonade-profile-XX.txt, (work in progress).
[OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document,
(Work in progress). http://www.openmobilealliance.org/
Version History
Revision 03:
[1] Removal of explicit text change requests in section 4.
[2] Addition of proxy-based deployment models.
[3] Reference to OMA mobile e-mail RD.
Revision 03:
[1] Editorial improvements throughout the document
[2] Extension of section 4 on recommendations including proposed next
steps for the charter and Lemonade WG activities.
[3] Addition of references
Revision 02:
[1] Added time out issue more explicitly
[2] Added recommendations
Maes Expires - January 2006 [Page 13]
<Lemonade and Mobile e-mail> July 2005
Revision 01:
[1] Editorial improvements
Acknowledgments
This document is based on discussions at Oracle, with partners as
well as in the context of mobile e-mail standard work at OMA (Open
Mobile Alliance) and at IETF Lemonade.
Authors Addresses
Stephane H. Maes
Oracle Corporation
500 Oracle Parkway
M/S 4op634
Redwood Shores, CA 94065
USA
Phone: +1-650-607-6296
Email: stephane.maes@oracle.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Maes Expires - January 2006 [Page 14]
<Lemonade and Mobile e-mail> July 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005). 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.
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.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Maes Expires - January 2006 [Page 15]
