Lemonade
Internet Draft: Mobile E-mai S. H. Maes
Document: draft-maes-lemonade-mobile-email-00.txt Oracle Corporation
Expires: April 2005 October 2004
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 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."
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.
Maes [Page 1]
<Mobile e-mail> October 2004
Conventions used in this document
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..........................................................1
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.................................3
1.4. Main actors...............................................4
1.5. Other players in Ecosystem................................4
2. Challenges.....................................................4
2.1. Devices...................................................4
2.2. Networks and operators....................................5
2.3. Enterprises and other e-mail service providers............6
3. Deployment models..............................................6
4. Scope, objectives of Lemonade Mobile Profile: Recommendations..8
Security Considerations...........................................9
Authors Addresses.................................................9
Intellectual Property Statement...................................9
Acknowledgment...................................................10
Full Copyright Statement.........................................10
Maes Expires - April 2005 [Page 2]
<Mobile e-mail> October 2004
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".
1.1. 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)
- Low or at least bearable cost of usage (e.g. traffic / bandwidth
optimization, predictable cost, manageable traffic, ...)
Note that the notion of quasi-instantenous 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-instantenous. 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
- Format adaptation (attachments, page, ...)
- DRM 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 prevent the deployment of 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, ActiveSync, ...)
- Relationship to PIM (agenda / Address Book)
Maes Expires - April 2005 [Page 3]
<Mobile e-mail> October 2004
1.4. Main Actors
The main actors are:
- User
- Operators of the mobile network
- E-mail service provider:
- Service provider (e.g. Operator, other e-mail server provider)
- Enterprise
1.4. 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...)
- 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
Maes Expires - April 2005 [Page 4]
<Mobile e-mail> October 2004
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
- Intermittent connectivity:
- Loss of coverage
- Nature of mobility (e.g. radio turned off in planes)
- Temporary IP addresses
- Unreliable delivery (Connection)
- 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:
- 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 itËs own authentication mechanisms etc...
- Regulated:
- QoS
- Privacy
- Exchanged data
- Reachability
- Logging
- Accountability
- ...
Maes Expires - April 2005 [Page 5]
<Mobile e-mail> October 2004
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)
- No storage of company data outside intranet
(in clear or not). This is why MMS solutions are not
acceptable
- Regulated:
- E.g. Journaling / Storage of all corporate e-mails
- Control usage costs
- Need to integrate with existing IT infrastructure (instead of
replacing them).
3. Deployment models
The generic logical architecture and protocol to support mobile e-mail
include:
- 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:
- 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
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
Maes Expires - April 2005 [Page 6]
<Mobile e-mail> October 2004
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
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
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
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"
Maes Expires - April 2005 [Page 7]
<Mobile e-mail> October 2004
* 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
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
4. Scope, objectives of Lemonade Mobile Profile: Recommendations
Will lemonade specify the mobile e-mail protocol or specify a set of
optimizations "inspired" from mobile e-mail but not necessarily
addressing all these issues?
We recommend:
- That Lemonade aims at addressing all the problems identified that
are within the scope of IETF.
- That Lemonade MUST design its protocol to allow use of its messages
and principles with other transport mechanisms (e.g. HTTP, Outband
notification mechanisms, ...) when needed to address some of the mobile
e-mail challenges identified in this document.
Maes Expires - April 2005 [Page 8]
<Mobile e-mail> October 2004
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 OMA.
This implies in particular allowing: compression and encryption at the
application level and possibility to bind Lemonade to HTTP/HTTPS.
Security Considerations
The Mobile e-mail protocols must address / support security issues raised
by:
- The different deployment models identified in section 3. In
particular:
- 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).
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.
Maes Expires - April 2005 [Page 9]
<Mobile e-mail> October 2004
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.
Full Copyright Statement
Copyright (C) The Internet Society 2004. 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 - April 2005 [Page 10]