                     <Lemonade and Mobile e-mail>        February 2005 
 
 
Lemonade                                                                
Internet Draft: Mobile E-mail                                S. H. Maes 
Document: 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. 
    
   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 - 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.  
 
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 - August 2005                [Page 2] 


                     <Lemonade and Mobile e-mail>        February 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 
   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.............................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..........................................15 
   References.......................................................16 
   Version History..................................................16 
   Acknowledgments..................................................16 
   Authors Addresses................................................16 
   Intellectual Property Statement..................................17 
   Full Copyright 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"; 
   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. 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 - August 2005                [Page 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 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: 

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

 
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, 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: 
 
 
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. 
      - 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 
    
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" 
    
    
         * 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. 
  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 
   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 
 
 
Maes                    Expires - August 2005               [Page 10] 


                     <Lemonade and Mobile e-mail>        February 2005 
 
 
   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  
        - 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 guarantee secure protocol interoperability. 
    
   Mobile enhancement will aim at being reusable by other standard 
   activities focused on non-IP based network or other mobile 
   deployments. 
    

Maes                    Expires - August 2005               [Page 14] 


                     <Lemonade and Mobile e-mail>        February 2005 
 
 
   The transport area will be consulted to deal with any transport-
   related issues that arise, especially in regards to items 1-4 <add> 
   and 6 û 8 </add> above. 
    
   The IAB is currently working on the specification of 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 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 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 end-of-life of the VPIM and  
   FAX work groups and the similar membership, the working group does 
   not expect to 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 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 
   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 18]