Internet DRAFT - draft-maes-lemonade-mobile-email

draft-maes-lemonade-mobile-email



                     <Lemonade and Mobile e-mail>           July 2005 
 
 
Lemonade                                                                
Internet Draft: Mobile E-mail                                S. H. Maes 
Document: draft-maes-lemonade-mobile-email-04.txt    Oracle Corporation 
Expires: January 2006                                         July 2005 
    
    
                        Lemonade and Mobile e-mail 
    
Status of this Memo 
 
   This document is an Internet-Draft and is subject to all provisions 
   of Section 10 of RFC2026. By submitting this Internet-Draft, each 
   author represents that any applicable patent or other IPR claims of 
   which he or she is aware have been or will be disclosed, and any of 
   which he or she becomes aware will be disclosed, in accordance with 
   Section 6 of BCP 79. 
        
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-
   Drafts.  
        
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress."  
        
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt  
        
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
   This document is an Internet-Draft and is subject to all provisions 
   of Section 10 of RFC2026. By submitting this Internet-Draft, each 
   author represents that any applicable patent or other IPR claims of 
   which he or she is aware have been or will be disclosed, and any of 
   which he or she become aware will be disclosed, in accordance with 
   RFC 3668. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 
 
 
Maes                    Expires - January 2006               [Page 1] 





                     <Lemonade and Mobile e-mail>           July 2005 
 
 
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
Abstract 
    
   This document describes the challenges with mobile e-mail in order to 
   identify the challenges that are within the mobile profile of 
   Lemonade.  
 
Conventions used in this document 
    
   In examples, "M:", "I:" and "S:" indicate lines sent by the client 
   messaging user agent, IMAP e-mail server and submit server 
   respectively. 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in [RFC2119]. 
    
   An implementation is not compliant if it fails to satisfy one or more 
   of the MUST or REQUIRED level requirements for the protocol(s) it 
   implements. An implementation that satisfies all the MUST or REQUIRED 
   level and all the SHOULD level requirements for a protocol is said to 
   be "unconditionally compliant" to that protocol; one that satisfies 
   all the MUST level requirements but not all the SHOULD level 
   requirements is said to be "conditionally compliant."  When 
   describing the general syntax, some definitions are omitted as they 
   are defined in [RFC3501].  
    
 
Table of Contents 
          
   Status of this Memo ........................................... 1 
   Abstract....................................................... 2 
   Conventions used in this document.............................. 2 
   Table of Contents.............................................. 2 
   1. Introduction................................................ 3 
      1.1. Definitions ........................................... 3 
      1.2. Main Expectations...................................... 3 
      1.3. Additional Considerations.............................. 4 
      1.4. Main Actors ........................................... 5 
      1.5. Other players in ecosystem............................. 5 
   2. Challenges.................................................. 5 
      2.1. Devices................................................ 5 
      2.2. Networks and operators................................. 5 
 
 
Maes                    Expires - January 2006               [Page 2] 





                     <Lemonade and Mobile e-mail>           July 2005 
 
 
      2.3. Enterprises and other e-mail service providers......... 7 
   3. Usage models................................................ 7 
      3.1. Usage Pattern.......................................... 7 
      3.2. Deployment models...................................... 8 
      3.3. Deployment model A..................................... 8 
      3.4. Deployment model B..................................... 9 
      3.5. Deployment model C..................................... 9 
         3.5.1. Deployment model C.1.............................. 9 
         3.5.2. Deployment model C.2.............................. 9 
      3.6. Deployment model D.....................................10 
   4. Recommendations on Lemonade work and specifications.........10 
      4.1. Scope recommendations..................................10 
      4.2. Objectives.............................................11 
      4.3. Principles.............................................11 
      4.4. Topics to explicitly address...........................12 
      4.5. Lemonade goals for mobile e-mail.......................12 
   Security Considerations........................................12 
   References.....................................................13 
   Version History................................................13 
   Acknowledgments................................................14 
   Authors Addresses..............................................14 
   Intellectual Property Statement................................14 
   Full Copyright Statement.......................................15 
    
    
1.    Introduction 
    
   This document describes the challenges associated to mobile e-mail. 
    
1.1.     Definitions 
    
   Mobile e-mail is defined as "Access to e-mail while mobile"; 
   typically from a mobile device.  
 
1.2.     Main Expectations 
    
   The main expectations for mobile e-mail are: 
         - To receive quasi-instantaneous notification of new e-mails 
         when within coverage (if setup this way) 
         - To reflect quasi-instantaneously new e-mail or e-mail server 
         events in the mobile client when within coverage 
         - To send quasi-instantaneously e-mail composed on mobile 
         client from appropriate e-mail server when within coverage or 
         as soon that coverage is established otherwise 
         - To efficiently manipulate e-mails / drafts / attachment as 
         needed  
         or as preferred  
         - End-to-end secure when needed (e.g. e-mails may at no point 
         be in clear outside enterprise domain) 
 
 
Maes                    Expires - January 2006               [Page 3] 


                     <Lemonade and Mobile e-mail>           July 2005 
 
 
         - Low or at least bearable cost of usage (e.g. traffic / 
         bandwidth optimization, predictable cost, manageable traffic, 
         ...) 
    
   Note that the notion of quasi-instantaneous refers to the impression 
   of the user and not to a particular precise duration: the user has 
   the feeling that something happens in a way that is quasi-
   instantaneous. This may be equivalent to some desktop user experience 
   or sometimes be faster or slower than desktop. That is not important 
   as the user can usually not compare. On the other hand, some overall 
   behavior clearly violate this principle (e.g. if the client waits for 
   the user to "browse" its mailbox with a client to download the 
   headers or even the whole messages). 
    
1.3.     Additional Considerations 
    
   The following considerations are also important for mobile e-mail: 
         - Need for graceful degradation (e.g. being able to access e-
         mail while mobile through other channels like voice/DTMF, 
         Messaging (SMS, MMS, IM, à), WAP Push and browsing 
         - Need for server-to-client notifications that clients can 
         display instead if acting on and that informs the user.  
         - Format adaptation (attachments, page, ...): 
            - Format conversion 
            - Adaptation to device capabilities and form factor 
            - streamed versus downloaded multi-media 
         - DRM (Digital Right Management) rules: how to respect DRM 
         rules like forward lock 
         - Provisioning / setup: These are extremely challenging on 
         mobile devices with limited or challenging input capabilities. 
         Also average users are more easily confused and unable to 
         correctly setup mobile phones 
         - Charging: Operator want to maintain charging to create a 
         viable business model. They may be less inclined to deploy or 
         support mobile email solutions that do not permit charging for 
         e-mail services. 
         - Synchronization with other clients: 
          - e.g. Peer to peer vs. with server (SyncML / OMA DS and other 
          real time synchronization protocols, ...) and how to allow a 
          same repository to sometimes access e-mail on the server via 
          mobile access over the air and sometimes access it via 
          synchronization with the email repository on a laptop that 
          itself sometimes access email from the email server. 
         - Relationship to PIM (agenda / Address Book): mobile e-mail 
         can also support the exchange of PIM events as payload or 
         attachments (e.g. considering the calendar or address book 
         repository as another e-mail folder). 
    

 
 
Maes                    Expires - January 2006               [Page 4] 




                     <Lemonade and Mobile e-mail>           July 2005 
 
 
1.4.     Main Actors 
    
   The main actors are:   
         - Users 
         - Operators of the mobile network 
         - E-mail service providers: 
            - Service providers (e.g. Operators, other e-mail server 
            providers) 
            - Enterprises 
    
1.5.     Other players in ecosystem 
    
   Other actors influence decisions related to mobile e-mail: 
         - Device Manufacturers 
         - Client software providers 
         - E-mail server manufacturers: 
             - E-mail server 
             - Mobile e-mail enablement server 
    
2.   Challenges 
    
2.1.     Devices 
    
   Devices present the following challenges that directly impact mobile 
   e-mail: 
          - Constrained memory / processing power (always improving): 
             - Wide range to support 
          - Limited battery life (will remain a problem for a long 
         time): 
             - Constrains processing capability 
             - Constrains connectivity patterns (not always fully 
            connected but may be awaken via outband notifications...) 
                - Notifications / wake-up are to be supported by mobile 
               e-mail  
             - Constraints acceptable bandwidth 
          - More exotic platforms: 
             - Sometimes proprietary or closed 
             - Challenging or controlled software distribution channels: 
               - Installing, provisioning, supporting, upgrading,... 
                 - E.g. DRM trusted clients 
               - Wide range of control models by: 
                 - Device manufacturer, operator, enterprise, user 
    
2.2.     Networks and operators 
    
   Mobile networks and operators impose additional constraints that must 
   be taken into account when designing mobile e-mail solutions: 
       - Different underlying network technologies / bearers with 
      different behavior / capabilities 
 
 
Maes                    Expires - January 2006               [Page 5] 











                     <Lemonade and Mobile e-mail>           July 2005 
 
 
       - Intermittent connectivity: 
           - Loss of coverage 
           - Nature of mobility (e.g. radio turned off in planes) 
           - Temporary IP addresses 
           - Unreliable delivery (Connection) 
           - Underlying network layer (up to transport) may drop at any 
          time. Even if then re-established, sessions at the transport 
          level are maintained only if the transport protocol provide 
          mechanisms to maintain it when the network connection is re-
          established. Otherwise, additional mechanisms are needed at 
          the application protocol layer to establish and maintain or 
          recover session if a session is needed or assumed.  
            - As a result notifications schemes like IDLE perform poorly 
            when used as intended (i.e. without improvements) over a 
            reliable network 
       - Out band notification schemes 
           - Unreliable 
           - But can be used as "wake up / notification scheme" 
       - Limited bandwidth: 
           - Limited capabilities shared across all users 
           - Roaming within and across domain / operators / technologies 
       - Cost of usage: 
           - Multiple cost models (free, unlimited, per packet, per 
          service / type of service, ...) 
           - In general, costly and in need of optimization to maintain 
          cost acceptable enough to user and to allow operator to share 
          network with enough users. 
       - Controlled: 
         - Walled garden: 
            - Inbound and outbound traffic 
            - Internal traffic 
         - With its own authentication mechanisms etc... 
       - Regulated: 
         - QoS 
         - Privacy 
         - Exchanged data 
         - Reachability 
         - Logging 
         - Accountability, support desk (inexperienced users, hard to 
         provision) 
         - ... 
       - Huge subscriber sets 
         - Server scalability is critical (e-mail server / Mobile e-mail  
         Enabling Server / network) 
            - Solutions that tie-up one or more ports per device or user 
            are not easily scalable 
               - e.g. IDLE sessions for each devices tie-up ports and 
               create large queues. 
         - Support desk challenges 
 
 
Maes                    Expires - January 2006               [Page 6] 











                     <Lemonade and Mobile e-mail>           July 2005 
 
 
      - Time outs introduced by numerous intermediaries, firewalls, 
      gateways etc 
    
2.3.     Enterprises and other e-mail service providers 
    
   Enterprises must reconcile mobile e-mail deployments with the 
   following requirements: 
      - Walled garden intranets: 
               - Firewalls, VPN, ... 
           - IT Corporate security guidelines: 
               - Wide range - in general VERY conservative e.g. 
                   - Require end-to-end security 
                   - Allowed applications / usages / content 
                   - Firewalls / ports / protocols  
                     - (e.g. only HTTP or HTTPS; no SSL/TLS) 
                     - Time-outs 
                     - No storage of company data outside intranet on 
                     defined servers (in clear or not). This is why MMS 
                     solutions are not acceptable. Current e-mail 
                     infrastructure with untraceable potential 
                     intermediate storage is accepted. 
           - Regulated: 
               - E.g. Journaling / Storage of all corporate e-mails 
            - Control usage costs and support (including provisioning) 
            - Need to integrate with existing IT infrastructure (instead 
            of replacing them). 
            - Similar scalability need of email servers / mobile email 
            enabling servers. 
            - Time outs introduced by firewalls etc... 
    
3.   Usage models 
    
3.1.     Usage Pattern 
    
   The generic usage pattern model to support mobile e-mail includes:  
      - Mobile e-mail server (backend e.g. IMAP server):  
         - This is typically a regular e-mail server. It may consist of 
         several servers (e.g. IMAP4 server and SMTP server or POP3 
         server and SMTP server). 
      - Connector: 
         - The connector includes any protocol adaptation required 
         between the e-mail server and mobile e-mail enabling server.  
      - Mobile e-mail enabling server: 
         - The mobile e-mail enabler implements the server-side 
         functionality of the mobile e-mail specifications. 
      - Mobile e-mail client: 
         - The mobile e-mail client implements the client-side 
         functionality of the mobile e-mail specifications. 

 
 
Maes                    Expires - January 2006               [Page 7] 











                     <Lemonade and Mobile e-mail>           July 2005 
 
 
      - The mobile e-mail protocol between the mobile e-mail client and 
      mobile e-mail enabling server. 
      - Mobile enablers that support functions needed by the OMA mobile 
      e-mail enabler. E.g.: 
          - Outband notifications 
          - Provisioning 
          - ... 
    
3.2.     Deployment models 
    
   These different components may be deployed in different domains that 
   may be separated by firewalls. 
 
      Possible deployments include: 
         A: Mobile e-mail by operators: "operator hosted e-mail service" 
          - Device in network 
          - Mobile "enabled" email server in OperatorÆs Domain 
          - Roaming across compatible networks / operators 
         B: Mobile e-mail by E-mail service provider (enterprise, ISP): 
          - Device in operator network (including roaming) 
          - Mobile "enabled" email E-mail server in service provider 
         C: Outsourced mobile enablement of E-mail service provider: 
            1. By Operator (operator hosted) 
            2. By other third party service provider 
          - Device in operator network (including roaming) 
          - E-mail server in other domain 
         D: As above, but with proxies in addition to the mobile e-mail 
      enabling server. 
    
3.3.     Deployment model A  
    
   Deployment A is characterized by:  
         * In operator(s) domain:  
          - Mobile e-mail server (backend e.g. IMAP server) 
          - Connected (e.g. via IMAP) through a "connector" 
          - to a mobile e-mail enabling server 
          - Connected: 
            - Via mobile e-mail protocol to a mobile e-mail client 
            - Via other protocols to mobile enablers that support 
            functions like: 
                 - Outband notifications 
                 - Provisioning 
                                - ... 
          Firewalls may exist: 
          - Between: 
            - Mobile client and mobile e-mail enabling server 
            - Mobile enablers and mobile e-mail enabling server 
       

 
 
Maes                    Expires - January 2006               [Page 8] 











                     <Lemonade and Mobile e-mail>           July 2005 
 
 
3.4.     Deployment model B 
    
   Deployment B is characterized by:  
         * In E-mail Service Provider domain:  
          - Mobile e-mail server (backend e.g. IMAP server) 
          - Connected (e.g. via IMAP) through a "connector" 
          - to a mobile e-mail enabling server 
             - Connected: 
         * In Operator(s) domain: 
               - Via mobile e-mail protocol to a mobile e-mail client 
               - Via other protocols to mobile enablers that support 
               functions like: 
                    - Outband notifications 
                    - Provisioning 
                                - ... 
          Firewalls may exist: 
          - 1) Between connectors and mobile e-mail enabling server 
          - 2) Between: 
                 - Mobile client and mobile e-mail enabling server 
                 - Mobile enablers and mobile e-mail enabling server 
       
3.5.     Deployment model C 
    
3.5.1. Deployment model C.1 
    
   Deployment C.1 is characterized by:  
         * In E-mail Service Provider domain:  
          - Mobile e-mail server (backend e.g. IMAP server) 
          - Connected (e.g. via IMAP) through a "connector" 
    
    
    
         * In Operator(s) domain: 
          - to a mobile e-mail enabling server 
             - Connected: 
               - Via mobile e-mail protocol to a mobile e-mail client 
               - Via other protocols to mobile enablers that support 
               functions like: 
                    - Outband notifications 
                    - Provisioning 
                             - ... 
          Firewalls may exist: 
          - 1) Between connectors and mobile e-mail enabling server 
          - 2) Between: 
                 - Mobile client and mobile e-mail enabling server 
               - Mobile enablers and mobile e-mail enabling server 
    
3.5.2. Deployment model C.2 
    
 
 
Maes                    Expires - January 2006               [Page 9] 











                     <Lemonade and Mobile e-mail>           July 2005 
 
 
      Deployment C.2 is characterized by:  
         * In E-mail Service Provider domain:  
          - Mobile e-mail server (backend e.g. IMAP server) 
          - Connected (e.g. via IMAP) through a "connector" 
         * In third party service provider: 
          - to a mobile e-mail enabling server 
             - Connected: 
         * In Operator(s) domain: 
               - Via mobile e-mail protocol to a mobile e-mail client 
               - Via other protocols to mobile enablers that support 
               functions like: 
                    - Outband notifications 
                    - Provisioning 
                             - ... 
          Firewalls may exist: 
          - 1) Between connectors and mobile e-mail enabling server 
          - 2) Between: 
                 - Mobile client and mobile e-mail enabling server 
                 - Mobile enablers and mobile e-mail enabling server 
             
3.6.     Deployment model D 
             
   Proxies are involved in front of mobile e-mail enabling server. This 
   allows protocol adaptation to possibly take place within the e-mail 
   server domain while the proxy handles the firewall challenges 
   [LEMONADEINTERMEDIARIES]. 
    
4.   Recommendations on Lemonade work and specifications 
    
   <<EditorÆs Note: This section will evolve as the work at Lemonade 
   evolves and in particular as work towards a mobile profile is 
   inititated.>> 
    
4.1.     Scope recommendations 
    
   LemonadeÆs raison dÆŠtre and charter [LEMONADECHARTER] is to enhance 
   Internet email to support diverse service environments. Considering 
   the attention paid by the industry to mobile and/or push e-mail and 
   success of early proprietary solutions, it is natural that IETF 
   Lemonade considers enhancing its internet mail protocols to support 
   mobile email. 
    
   As discussed above, and as illustrated by the user experience and 
   features of todayÆs pioneer deployments, mobile e-mail is different 
   from regular internet mail confronted to the specific constraints and 
   limitations of the networks, the technologies and their deployments 
   by multiple actors... Problems are no only technical; some may be 
   rather linked to non-recommended deployments or usages of these 

 
 
Maes                    Expires - January 2006              [Page 10] 











                     <Lemonade and Mobile e-mail>           July 2005 
 
 
   technologies because of a variety of technical, business or legal 
   reasons. 
    
   Other standard activities, like the OMA (Open Mobile Alliance), have 
   started work on mobile e-mail. It is critical that a standard mobile 
   e-mail solution be based on profiles and extensions of the Internet 
   email and interoperate well with it rather completely different 
   approaches that are not built on the Internet email protocols that 
   may take much longer to be designed and deployed and may not benefit 
   of the year of experience that IETF and the industry have acquired 
   developing, implementing and deploying e-mail.  
    
   From a timing point of view, IETF Lemonade work seems to be ideally 
   placed to allow rapid development of specifications to support mobile 
   e-mail. It is not clear that any other standard technology today can 
   easily be used or extended to satisfy the requirements and 
   expectation of an open standard mobile e-mail specification.  
    
4.2.     Objectives 
    
   So the Lemonade working group MUST look at the problems of mobile e-
   mail in their entirety. 
    
   Lemonade MUST specify or a mobile e-mail protocol or specify a set of 
   optimizations "inspired" from mobile e-mail to address as much as can 
   be within the scope of IETF. 
    
   When issues are deemed beyond the scope of IETF, Lemonade SHOULD 
   analyze options to address all of the issues via guidelines or 
   recommendations to other standard activities. 
    
   If needed LemonadeÆs charter [LEMONADECHARTER] MUST be updated to 
   cover the above. 
    
4.3.     Principles 
    
   As design principles, it is recommended that: 
      - Lemonade MUST design its protocol to allow use of its messages 
        and principles with other transport mechanisms (e.g. HTTP 
        bindings, outband notification mechanisms, ...) when needed to 
        address some of the mobile e-mail challenges identified in this 
        document. 
      - Accordingly, Lemonade MUST NOT make assumptions on the 
        underlying network transport or design choices that would 
        prevent addressing all these issues even if their resolution is 
        outside the scope of IETF (network neutrality). This implies in 
        particular allowing:  
        - Compression at the application level  
        - Encryption  
 
 
Maes                    Expires - January 2006              [Page 11] 





                     <Lemonade and Mobile e-mail>           July 2005 
 
 
        - The possibility to bind Lemonade to HTTP/HTTPS. 
    
4.4.     Topics to explicitly address 
    
   Lemonade should start investigation addressing or specifying: 
      - IMAP protocol optimizations (to reduce traffic between client 
      and server: 
         - Reduction of roundtrip 
         - Compression of data exchanges: 
               - Transport level 
               - Application level shown very useful for example when 
               attachments are exchanged. 
      - Support for notifications mechanisms: 
            - Client to server 
            - Server to server 
      - Filtering (setup and changes): 
            - Message filters 
            - Notifications filters 
      - Dealing with problems of intermediaries with respect to mobile 
      e-mail (see also [LEMONADEINTERMEDIARIES]): 
            - Implications on end-to-end security, compression and 
            stability of the connection. 
            - Realities of todayÆs deployment models and business 
            models. 
      - Attachment / body part adaptation: 
            - Format conversions 
            - Streaming 
            - Adaptation to device capability and form factor 
      - Attachment manipulation: 
            - Forward without download 
            - Others? 
      - Improved reliability to connection / network drops 
      - Efficient quick reconnect scheme 
      - Provisioning 
    
4.5.     Lemonade goals for mobile e-mail 
    
   The Lemonade WG must target to provide support via its Lemonade 
   profile and protocol specifications to the mobile e-mail enabler 
   specified by OMA. Requirements can be found as [OMA-ME-RD]. 
    
Security Considerations 
    
   The Mobile e-mail protocols must address / support security issues 
   raised by: 
      - The different deployment models identified in section 3. In 
      particular: 


 
 
Maes                    Expires - January 2006              [Page 12] 



                     <Lemonade and Mobile e-mail>           July 2005 
 
 
          - End-to-end security with no message in the clear when the 
          mobile e-mail enabling server is outside the e-mail service 
          provider domain. 
          - No storage of e-mail (in the clear or not) outside the 
          control and domain of the e-mail service provider 
          - Secure notifications when relevant information is carried 
          the notifications. 
      - Support for the restrictions introduced by the presence of 
      firewalls with constraints typically met in such firewall 
      deployments (e.g. corporate guidelines that open only HTTP or 
      HTTPS ports). 
      - On bandwidth limited mobile networks where users pay per data 
      volumes  and/or notifications, spam may become an important issue. 
      It can be mitigated with appropriate filters and server-side spam 
      prevention tools. 
    
References 
    
   [LEMONADECHARTER] IETF Charter for ôEnhancements to Internet email to 
      support diverse service environments (lemonade)", 
      http://www.ietf.org/html.charters/lemonade-charter.html.  
    
   [LEMONADEINTERMEDIARIES] Maes, S.H. and D. Crocker, ôLemonade and the 
      challenges of Intermediaries", draft-maes-lemonade-intermediary-
      challenges-xx.txt, (work in progress). 
    
   [LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile", 
      draft-ietf-lemonade-profile-XX.txt, (work in progress). 
    
   [OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document, 
      (Work in progress).  http://www.openmobilealliance.org/ 
    
Version History 
    
   Revision 03: 
   [1] Removal of explicit text change requests in section 4. 
   [2] Addition of proxy-based deployment models. 
   [3] Reference to OMA mobile e-mail RD. 
 
 
   Revision 03: 
   [1] Editorial improvements throughout the document 
   [2] Extension of section 4 on recommendations including proposed next 
      steps for the charter and Lemonade WG activities. 
   [3] Addition of references 
    
   Revision 02: 
   [1] Added time out issue more explicitly 
   [2] Added recommendations 
 
 
Maes                    Expires - January 2006              [Page 13] 





                     <Lemonade and Mobile e-mail>           July 2005 
 
 
    
   Revision 01: 
   [1] Editorial improvements 
    
Acknowledgments 
    
   This document is based on discussions at Oracle, with partners as 
   well as in the context of mobile e-mail standard work at OMA (Open 
   Mobile Alliance) and at IETF Lemonade. 
 
Authors Addresses 
    
   Stephane H. Maes 
   Oracle Corporation 
   500 Oracle Parkway 
   M/S 4op634 
   Redwood Shores, CA 94065 
   USA 
   Phone: +1-650-607-6296 
   Email: stephane.maes@oracle.com 
    
Intellectual Property Statement 
    
   The IETF takes no position regarding the validity or scope of any 
   intellectual property or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; neither does it represent that it 
   has made any effort to identify any such rights.  Information on the 
   IETF's procedures with respect to rights in standards-track and 
   standards-related documentation can be found in BCP-11.  Copies of 
   claims of rights made available for publication and any assurances of 
   licenses to be made available, or the result of an attempt made to 
   obtain a general license or permission for the use of such 
   proprietary rights by implementors or users of this specification can 
   be obtained from the IETF Secretariat.  
            
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights which may cover technology that may be required to practice  
   this standard.  Please address the information to the IETF Executive  
   Director. 
    
Acknowledgement 
    
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 
    
    
 
 
Maes                    Expires - January 2006              [Page 14] 





                     <Lemonade and Mobile e-mail>           July 2005 
 
 
Full Copyright Statement 
    
   Copyright (C) The Internet Society (2005). This document is subject 
   to the rights, licenses and restrictions contained in BCP 78, and 
   except as set forth therein, the authors retain all their rights.  
        
   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.  
            
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph are 
   included on all such copies and derivative works.  However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English.  
            
   The limited permissions granted above are perpetual and will not be  
   revoked by the Internet Society or its successors or assigns. 



















 
 
Maes                    Expires - January 2006              [Page 15]