WDIFF

draft-maes-lemonade-mobile-email-02.txt --> draft-maes-lemonade-mobile-email-03.txt

Lemonade
Internet Draft: Mobile E-mai E-mail S. H. Maes
Document: draft-maes-lemonade-mobile-email-02.txt draft-maes-lemonade-mobile-email-03.txt Oracle Corporation
Expires: August 2005 February 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 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.

Maes Expires - August 2005 [Page 1]

<Lemonade and Mobile e-mail> February 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.

Maes [Page 1]

<Mobile e-mail> February 2004

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..........................................................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.................................3 Considerations.................................4
1.4. Main actors...............................................4 Actors...............................................5
1.5. Other players in Ecosystem................................4 ecosystem................................5
2. Challenges.....................................................4 Challenges.....................................................5
2.1. Devices...................................................4 Devices...................................................5
2.2. Networks and operators....................................5

Maes Expires - August 2005 [Page 2]

<Lemonade and Mobile e-mail> February 2005

2.3. Enterprises and other e-mail service providers............6 providers............7
3. Usage models...................................................7
3.1. Usage Pattern.............................................7
3.2. Deployment models.........................................8
3.3. Deployment models..............................................6 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
4. Scope, objectives of Recommendations on Lemonade Mobile Profile: Recommendations..8 work and specifications...........10
4.1. Scope recommendations....................................10
4.2. Objectives...............................................11
4.3. Principles...............................................11
4.4. Topics to explicitly address.............................11
4.5. Proposed text change to the Lemonade charter.............12
4.5.1. Text edit proposal..................................12
4.5.2. Goals and Milestones................................15
4.5.3. Proposal for next steps.............................15
Security Considerations...........................................9 Considerations..........................................15
References.......................................................16
Version History..................................................16
Acknowledgments..................................................16
Authors Addresses.................................................9 Addresses................................................16
Intellectual Property Statement...................................9
Acknowledgment...................................................10 Statement..................................17
Full Copyright Statement.........................................10

Maes Expires - August 2005 [Page 2]

<Mobile e-mail> Frebruary 2005 Statement.........................................17

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". 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

Maes Expires - August 2005 [Page 3]

<Lemonade and Mobile e-mail> February 2005

- 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-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. 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 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
client that clients can
display instead if acting on and that informs the user). user.
- Format adaptation (attachments, page, ...) ...):
- DRM rules: 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 prevent the deployment of 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, ActiveSync, 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) 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 - August 2005 [Page 3]

<Mobile 4]

<Lemonade and Mobile e-mail> February 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 Device manufacturer, operator, enterprise, user

Maes Expires - August 2005 [Page 4]

<Mobile e-mail> February 2005

2.2.
Networks and operators

Mobile networks and operators impose additional constraints that must
be taken into account when designing mobile e-mail solutions:

Maes Expires - August 2005 [Page 5]

<Lemonade and Mobile e-mail> February 2005

- 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)
- 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. re-
established. Otherwise, additional mechanisms are needed at
the application protocol layer to establish and
maintain/recover 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 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 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 devices / device or user
are not easily scalable

Maes Expires - August 2005 [Page 6]

<Lemonade and Mobile e-mail> February 2005

- e.g. IDLE sessions for each devices tie-up ports and
create large queues.
- Support desk challenges
- Time outs introduced by numerous intermediaries

Maes Expires - August 2005 [Page 5]

<Mobile e-mail> February 2005 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. Deployment
Usage models

3.1.
Usage Pattern

The generic logical architecture and protocol usage pattern model to support mobile e-mail
include: includes:
- Mobile e-mail server (backend e.g. IMAP server) server):
- Connected (e.g. via IMAP) through This is typically a "connector" regular e-mail server. It may consist of
several servers (e.g. IMAP4 server and SMTP server or POP3
server and SMTP server).
- to a Connector:
- The connector includes any protocol adaptation required
between the e-mail server and mobile e-mail enabling server server.
- Connected: Mobile e-mail enabling server:
- Via The mobile e-mail protocol to a enabler implements the server-side
functionality of the mobile e-mail specifications.
- Mobile e-mail client:

Maes Expires - August 2005 [Page 7]

<Lemonade and Mobile e-mail> February 2005

- The mobile e-mail client implements the client-side
functionality of the mobile e-mail specifications.
- Via other protocols to The mobile e-mail protocol between the mobile e-mail client and
mobile e-mail enabling server.
- Mobile enablers that support functions like: needed by the OMA mobile
e-mail enabler. E.g.:
- Outband notifications
- Provisioning
- ...
Firewalls

3.2.
Deployment models

These different components 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 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

Maes Expires - August 200 [Page 6]

<Mobile e-mail> February 2005
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

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 - August 2005 [Page 8]

<Lemonade and Mobile e-mail> February 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"

Maes Expires - August 2005 [Page 7]

<Mobile e-mail> February 2005

* 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 - August 2005 [Page 9]

<Lemonade and Mobile e-mail> February 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

4. Scope, objectives
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 Mobile Profile: Recommendations

Will lemonade specify 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 protocol 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 specify usages of these
technologies because of a set variety of
optimizations "inspired" from 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 but not necessarily
addressing all these issues?

We recommend:
- That Lemonade aims at addressing all solution be based on profiles and extensions of the problems identified Internet
email and interoperate well with it rather completely different
approaches that are within not built on the scope of IETF. Internet email protocols that

Maes Expires - That Lemonade MUST design its protocol August 2005 [Page 10]

<Lemonade and Mobile e-mail> February 2005

may take much longer to allow use be designed and deployed and may not benefit
of its messages the year of experience that IETF and principles 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, Outband HTTP
bindings, outband notification mechanisms, ...) when ...) 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
- 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

Maes Expires - August 2005 [Page 11]

<Lemonade and Mobile e-mail> February 2005

- 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

Some of these topics are covered under the current charter; some are
addressed in the current Lemonade Profile [LEMONADEPROFILE] and some
will require new work and charter update [LEMONADECHARTER].

4.5.
Proposed text change to the Lemonade charter

See [LEMONADECHARTER]; additions are marked as <add> added text
</add> and deletions are marked as <delete> deleted text </delete>.

4.5.1. Text edit proposal

Description of Working Group:

Lemonade is tasked to provide a set of enhancements and profiles of
Internet email submission, transport, and retrieval protocols to
facilitate operation on platforms with constrained resources, or
communications links with high latency or limited bandwidth. A
<delete> primary </delete> goal of this work is to ensure that those
profiles and enhancements continue to interoperate with the existing
Internet email protocols in use on the Internet, so that these
environments and more traditional Internet users have access to a
seamless service. <add> Another goal is to ensure that those profiles

Maes Expires - August 2005 [Page 12]

<Lemonade and Mobile e-mail> February 2005

and enhancements to existing Internet email protocols support access
to e-mail from mobile devices over mobile networks in ways that:
- Can be deployed today:
- Over mobile networks:
- Considering the challenges of mobile networks (e.g.
network reliability, latency, bandwidth constraints, time-
outs, ...).
- Across the domains of the different actors involved in such
deployments (Operator, Third party service provider and e-
mail service provider (ISP, Enterprise, ...).
- With the multiple deployments models demanded by the
market
- End-to-end secure
- Compliant to typical corporate guidelines and
regulations
- Satisfy the user and market expectation:
- Are efficient:
- Optimized for bandwidth
- Optimized fro device
- Optimized for battery life
- Support the user experience and features expected for mobile
e-mail (sometimes call push e-mail):
- Push experience
- Filtering
- ...
</add>

Lemonade's work is at the crossroads of a body of work related to
Internet messaging, in particular work done by the VPIM, FAX, and
IMAPEXT IETF working groups <add> and external activities like OMA,
3GPP and 3GPP2</add>. Given the potentially broad scope of activities
this group could engage in, the group will focus specifically on the
following work items:

0. An informational RFC or RFCs will be produced on LEMONADE
architecture and the issues it seeks to address.

1. Enhance the existing IMAP4 message retrieval and message
submission (RFC 2476) protocols to satisfy the requirements for
handling streaming multimedia content. The existing standards-track
CONNEG framework will be used if content negotiation capabilities are
needed. The group will employ existing protocols (such as for
streaming) with IMAP4 instead of duplicating such functionality
within IMAP4.

2. Enhance the existing IMAP4 message retrieval and/or message
submission (RFC 2476) protocols to satisfy the requirements for
forwarding a message and/or its attachments without downloading the

Maes Expires - August 2005 [Page 13]

<Lemonade and Mobile e-mail> February 2005

message to the client and subsequently uploading the message to a
server.

3. Refine the existing IMAP4 message retrieval protocol to facilitate
its use with devices that have limited capabilities such as mobile
endpoints. At most one backwards compatible profile of IMAP4 will be
produced by this effort.

4. Define a format for message notifications for servers reporting
message status information to other servers <add> and to notify
clients outside the IMAP band of IMAP state changes. Do not specify
</add><delete>s</delete>pecify the method for delivery of those
notifications.

5. Create a specification describing the use of Internet message
services in environments where message delivery may take place using
either Internet protocols or through an MMS server using WAP to
communicate with the receiving user agent.

<add>

6. Enhance the existing IMAP4 message retrieval and/or message
submission (RFC 2476) protocols and Lemonade Profile (work in
progress) to support access to e-mail from mobile devices over mobile
network that are IP based, in the multiple deployments required for
mobile e-mail.

7. Enhance the existing IMAP4 message retrieval and/or message
submission (RFC 2476) protocols and Lemonade Profile (work in
progress) to support expectations in terms of features, performances
and user experience for mobile e-mail.

8. Create an extension of the Lemonade Profile (work in progress)
that describes how the profiles and extensions defined by Lemonade
support access to email from mobile device and in mobile IP
environments.

</add>

Any protocols defined by this working group will include appropriate
security mechanisms, including authentication, privacy, and access
control. Mandatory-to-implement security mechanisms will be specified
as needed in order to address some of the guarantee secure protocol interoperability.

Mobile enhancement will aim at being reusable by other standard
activities focused on non-IP based network or other mobile
e-mail challenges identified in this document.
deployments.

Maes Expires - August 2005 [Page 8]

<Mobile 14]

<Lemonade and Mobile e-mail> February 2005

Accordingly, Lemonade must not make assumptions on the underlying network

The transport or design choices that would prevent addressing all these area will be consulted to deal with any transport-
related issues
even if their resolution that arise, especially in regards to items 1-4 <add>
and 6 û 8 </add> above.

The IAB is outside currently working on the scope specification of IETF (network neutrality).
This implies general
guidelines and requirements for notification services. Once complete
this work will be used as input to item 4 above.

The working group is aware of several related activities in particular allowing: compression other
groups:

- 3GPP TSG T WG2 SWG3 Messaging <http://www.3gpp.org/TB/T/T2/T2.htm>
- W3C Multimodal interaction Activity <http://www.w3.org/2002/mmi/>
- Open Mobile Alliance <add>(MMS and encryption Mobile e-mail)</add>
<http://www.openmobilealliance.org/>
- 3GPP2 TSG-X <http://3gpp2.org/Public_html/X/index.cfm>

The goal is to coordinate efforts with at least these groups as
required.

While there is obvious synergy, given the
application level end-of-life of the VPIM and possibility
FAX work groups and the similar membership, the working group does
not expect to bind Lemonade coordinate with these other groups.

4.5.2. Goals and Milestones

The goals and milestones section should be accordingly updated. It
should be noted that a deliverable (Feb 05) already covers the
proposal presented above:

Feb 05 Submit IMAP4 profile for mobile devices to HTTP/HTTPS. the IESG

4.5.3. Proposal for next steps

Lemonade should discuss and submit this updated charter for IESG
approval.

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

Maes Expires - August 2005 [Page 15]

<Lemonade and Mobile e-mail> February 2005

- 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).

Version History

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

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

Maes Expires - August 2005 [Page 16]

<Lemonade and Mobile e-mail> February 2005

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

Maes Expires - August 2005 [Page 9]

<Mobile e-mail> February 2005
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.

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.

Maes Expires - August 2005 [Page 17]

<Lemonade and Mobile e-mail> February 2005

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 - August 2005 [Page 10] 18]

----