Internet DRAFT - draft-ietf-lemonade-server-to-client-notifications

draft-ietf-lemonade-server-to-client-notifications



Lemonade                                                                
Internet Draft: Lemonade Server to Client                    S. H. Maes 
Notifications 
Document: draft-ietf-lemonade-server-to-client-               C. Wilson 
notifications-00.txt                                                    
Expires: January 2005                                         July 2004 
    
    
                  Lemonade Server to Client Notifications 
    
Status of this Memo 
 
   This document is an Internet-Draft and is subject to all provisions 
   of Section 10 of RFC2026. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html. 
    
Abstract 
    
   Lemonade server to client notifications provides some extensions to 
   the IMAPv4 Rev1 protocol [RFC3501] for optimization in a mobile 
   setting, aimed at delivering extended functionality for mobile 
   devices with limited resources.  These notifications support pushing 
   crucial changes actively to a client, rather than requiring the 
   client to initiate contact to ask for state changes.   
 
 
 
Conventions used in this document 
    
   In examples, "C:" and "S:" indicate lines sent by the client and 
   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]. 
 
 
Maes                                                          [Page 1] 
              <Lemonade Server to Client Notifications>     July 2004 
 
 
    
   An implementation is not compliant if it fails to satisfy one or more 
   of the MUST or REQUIRED level requirements for the protocol(s) it 
   implements. An implementation that satisfies all the MUST or REQUIRED 
   level and all the SHOULD level requirements for a protocol is said to 
   be "unconditionally compliant" to that protocol; one that satisfies 
   all the MUST level requirements but not all the SHOULD level 
   requirements is said to be "conditionally compliant."  When 
   describing the general syntax, some definitions are omitted as they 
   are defined in [RFC3501].   
 
 
Table of Contents 
          
   Status of this Memo...............................................1 
   Abstract..........................................................1 
   Conventions used in this document.................................1 
   Table of Contents.................................................2 
   1. Introduction...................................................3 
      1.1. The Poll Model vs. the Push Model.........................3 
      1.2. The Server-Side Filtering in Lemonade.....................4 
      1.3. Synchronization Techniques................................5 
         1.3.1. State-Comparison-Based Synchronization...............5 
         1.3.2. Event-based Synchronization..........................6 
   2. The Lemonade Server to Client Notification Design..............7 
      2.1. Implementing Filters......................................7 
         2.1.1. The View Filter......................................8 
         2.1.2. The Priority/Notification Filter.....................8 
         2.1.3. The Syntax to define Priority/Notification Filters...8 
      2.2. Connectivity Models.......................................9 
         2.2.1. In-Response Connectivity.............................9 
         2.2.2. Inband Connectivity..................................9 
         2.2.3. Outband Connectivity................................10 
      2.3. Keeping the Client In Sync with the Mobile Repository....10 
   3. Events........................................................11 
      3.1. Message Events Sent During Inband and Inresponse Mode....11 
      3.2. Folder Events............................................12 
      3.3. PIM Events...............................................12 
   4. Interactions between the Lemonade Client and Lemonade Server..12 
      4.1. Revisions to IMAPv4 Rev1 Behavior........................12 
         4.1.1. UID.................................................12 
         4.1.2. Mobile Repository...................................12 
         4.1.3. IDLE................................................13 
         4.1.4. LEMONADESETPREF & LEMONADEGETPPREFS.................13 
         4.1.5. LEMONADEFILTER......................................13 
   Security Considerations..........................................15 
   References.......................................................15 
   Normative Appendices.............................................16 
      A. Event Payload..............................................16 
 
 
Maes                    Expires - January 2005                [Page 2] 
              <Lemonade Server to Client Notifications>     July 2004 
 
 
         A.1. Event Payload in Clear Text for Lemonade Sessions.....16 
         A.2. Outband Channel Event Payload.........................16 
   Non-Normative Appendices.........................................17 
      B. Use Cases..................................................17 
         B.1. State Comparison-Based Sync...........................17 
         B.2. Event-Based Sync......................................18 
   Authors Addresses................................................19 
   Intellectual Property Statement..................................19 
   Full Copyright Statement.........................................19 
    
    
1.  Introduction 
    
   The Lemonade Server to Client Notifications extends IMAPv4 Rev1 
   [RFC3501].  The client devices in this document are assumed to be 
   wireless with limited resources.  However, this should not be seen as 
   constraining.  The Lemonade Server to Client Notifications can be 
   bound to any transport protocol for inband and outband connectivity. 
   These notifications inform the client of changes in an end user's 
   mailbox.  This document will define what events and conditions 
   generate notifications, as well as how the server will inform the 
   client of these notifications.  In addition, it covers how the client 
   will process these notifications to maintain email synchrony. 
    
   The organization of this document is as follows.  The rest of this 
   section introduces the concepts of Lemonade Server to Client 
   Notifications so the reader can gain an understanding of the concepts 
   that drive this design.  Section 2 discusses actual design decisions 
   for Lemonade Server to Client Notifications.  Section 3 defines the 
   bindings for expressing events, while Section 4 is the main body of 
   the protocol, which describes the interactions between the Lemonade 
   server and client.  Next are sections concerning security 
   considerations, and references.  Finally, there are normative and 
   non-normative appendices, which provide useful information for those 
   who wish to implement the Lemonade Server to Client Notifications.  
    
    
1.1.  The Poll Model vs. the Push Model 
    
   This section discusses two different models for exchanging 
   notifications from the server to the client.  Today, most of the 
   existing email clients implement a polling model, where the end user 
   is notified of changes to an email account only after the email 
   client polls the server for changes.  How long it takes a client to 
   learn of a change on the server is thus dependent on how often the 
   client polls for changes.  Many clients can poll at high rates so 
   that the client can quickly learn of changes and reflect them on the 
   client display to achieve a quasi-real time synchronization 
   experience for the end user.  Because the client must continuously 
 
 
Maes                    Expires - January 2005                [Page 3] 
              <Lemonade Server to Client Notifications>     July 2004 
 
 
   poll the server for changes, the bandwidth requirements can be quite 
   high and the connection quality must be good in order to provide a 
   quasi-real time experience to the user.  The periodic poll model is 
   used on conventional email clients and is illustrated in Figure 1.  
    
        +--------------------+      Poll     +--------------+ 
        |                    | <------------ |              |   
        |     Mail Server    |               | Email Client |  
        |                    | ------------> |              | 
        +--------------------+   Response    +--------------+ 
    
                     Figure 1: Periodic Poll Model 
             
   Another way to achieve synchronization is for the email server to 
   initiate a session with the client when a crucial change to an email 
   occurs, which is the push model.  When important events happen to a 
   userĘs email account, the server informs the client device about the 
   event, and then the client can respond to that event as necessary.     In this case, the client device does not need to periodically poll 
   the mail server, so the push model is particularly effective in the 
   mobile computing environment when the cost of constant polling is 
   high.  The Lemonade Server to Client Notification Specifications 
   define the semantics for pushing events to a client.  The push model 
   is seen in Figure 2. 
    
        Event   +----------------+    Push    +--------------+ 
      --------> |   Mail Server  | ---------> | Email Client |  
                +----------------+            +--------------+ 
    
                          Figure 2: Push Model 
    
1.2. The Server-Side Filtering in Lemonade 
    
   The Lemonade profile and Lemonade Server to Client Notification 
   protocol is meant to support mobile client devices with memory and 
   connectivity constraints.  Due to these constraints, an end user may 
   want to specify filters to limit the number of notifications sent. 
   These filters separate their emails into different sets that the 
   server should handle differently.  All end users have a complete 
   repository, which includes all their email messages that are stored 
   on a server.  The end user may want to receive a small subset of 
   these messages on their client device, which are to be included on 
   the mobile device.  The messages on the device are split further into 
   two categories, lower priority messages that the user chooses to wait 
   for until it can poll the server and higher priority messages that 
   the user would like to be notified of as soon as possible by the 
   server.  All three repositories have the same set of folders.   
    
   +----------------+        +--------------+             +------------+ 
 
 
Maes                    Expires - January 2005                [Page 4] 
              <Lemonade Server to Client Notifications>     July 2004 
 
 
   |    COMPLETE    |        |   MOBILE     |             |  MOBILE    | 
   |                |              POLL     |  Priority / |   PUSH     | 
   |   REPOSITORY   | View   |  REPOSITORY  |Notification | REPOSITORY | 
   | all the emails |Filters | emails to be |  Filters    | important  |  
   |in an end user's|=======>|on the mobile |============>| emails of  | 
   | email account  |        |   device     |             |  end user  | 
   +----------------+        +--------------+             +------------+ 
    
                   Figure 3: Filters and Repositories 
    
   Formally, a repository consists of a set of folders, and each folder 
   has both a name and a set of messages associated with it.  While the 
   three repositories all have folders with the same name, there may be 
   different messages in them.  The complete repository consists of all 
   folders of an end user and all the associated emails for each of 
   those folders.  Messages in the complete repository that pass the 
   view filter make up the poll repository.  An end user can specify 
   exactly one view filter per folder per device. In addition, there is 
   a second layer of filtering, called priority or notification filters, 
   and there is exactly one priority filter per folder per device.  The 
   push repository is the set of all the messages in the complete 
   repository that pass both the view and the priority filters.  
    
   From this point forth, it can be assumed that an event in this 
   document refers to only and all changes to messages in the mobile 
   repositories.   When the client connects to the server and polls for 
   messages, it can determine what changes have occurred to messages 
   that passed the view filters.  Whenever an event occurs to a message 
   that passes the view and priority filters, the server actively pushes 
   a notification to the client. 
    
1.3.  Synchronization Techniques 
    
   After a client receives a notification that informs it that changes 
   have occurred to a mailbox, it needs to employ a synchronization 
   technique to reflect the server side changes onto the client device. 
   There are many techniques for determining what the changes between a 
   server and client are. In this section, two techniques are presented 
   that aim to keep a client device in sync with a given email account, 
   meaning the set of emails on the client device is the same as that in 
   the given email account.  
     
1.3.1. State-Comparison-Based Synchronization 
    
   IMAPv4Rev1 clients use a state-comparison-based synchronization 
   technique to be in sync with an email account.  This technique 
   requires the client to ask the server for information regarding all 
   the folders and all the messages in each folder stored on the server.  
   The client must then compute the difference between the server state 
 
 
Maes                    Expires - January 2005                [Page 5] 
              <Lemonade Server to Client Notifications>     July 2004 
 
 
   and the client device state, and make all necessary changes so that 
   the client device state matches the server state.  An example of the 
   interaction between the client and server in the IMAPv4 Rev1 protocol 
   for performing a state-comparison-based sync follows.   
    
   First, the client must retrieve the folders from the server. 
      C: A002 LSUB "" "*" 
      S: * LSUB () "/" "Drafts" 
      S: * LSUB () "/" "Friends" 
      S: * LSUB () "/" "INBOX" 
      S: A002 OK LSUB completed  
    
   The client must compare its folders with the responses of the command 
   above.  If it does not have a folder, it must create that folder on 
   the client device.  If there is a folder on the device that is not in 
   any of these responses, then the client must delete that folder.   
    
   Next, the client needs to make sure that the emails in each of its 
   folders match the server.  It performs a SELECT and then a FETCH 
   command for each folder.  A sample of a SELECT and FETCH command for 
   the inbox is as follows: 
      C: A003 SELECT ~/INBOX 
      S: * 60 EXISTS 
      S: ... more untagged responses with information about the folder 
      S: A003 OK SELECT completed  
      C: A004 FETCH 1:* (FLAGS UID) 
      S: * 1 FETCH (FLAGS (\Answered) UID 120) 
      S: * 2 FETCH (FLAGS (\Seen) UID 121) 
      S: ... flags for messages with message sequence numbers 3-59 
      S: * 60 FETCH (FLAGS () UID 250) 
      S: A004 OK FETCH completed 
    
   The client must go through the full list of email messages in each 
   folder.  It must add an email in this list if it is not already on 
   the client.  It must modify any email in this list on the client 
   device to reflect any changes to the mutable flags of that message.  
   Also, it should remove any emails on the client device not in this 
   list.  After performing these operations, the client is in sync with 
   the server. 
     
1.3.2. Event-based Synchronization 
    
   Another technique is event-based synchronization. Event-based 
   synchronization is used to keep the client device in sync with the 
   server. This method requires that the client has been fully 
   synchronized with the server at some earlier point.  In the IMAPv4 
   Rev1 protocol, the client must perform a state-comparison-based sync 
   when it selects a folder, but then it can use event-based 
   synchronization to keep itself in sync after that.  Although event-
 
 
Maes                    Expires - January 2005                [Page 6] 
              <Lemonade Server to Client Notifications>     July 2004 
 
 
   based synchronization cannot totally replace state-comparison-based 
   synchronization, it is a faster alternative for the client to 
   maintain synchrony when the server is capable of change tracking for 
   a client.   
    
   In event-based synchronization, the server keeps track of what 
   changes have occurred that are not yet reflected on the client 
   device.   Such a change is called an event.  When the client finishes 
   processing all events since the last time it was in sync with the 
   server, it is again in sync with the server.  Event-based 
   synchronization is particularly effective when the server can push 
   events to the client for immediate processing.  In this case, there 
   are likely to be only a small number of events the client needs to 
   process at one time.   
    
   When a Lemonade client drops a connection or accidentally disconnects 
   the server can retain the session and cache all events during the 
   time the client is disconnected.  When the client reconnects it does 
   not need to perform a state-comparison-based synchronization again, 
   instead the server sends the list of pending events to the client. 
 
 
2.  The Lemonade Server to Client Notification Design 
    
   Lemonade Server to Client Notification assumes extensions of IMAP 
   with the same basic model, where the client connects to the server to 
   open a session to access its email account.  A Lemonade client may 
   fetch the contents of the email account or make changes to it just as 
   in IMAP.  
    
2.1.  Implementing Filters 
    
   A Lemonade server should support multiple mobile devices for each 
   email user, and should allow each device to have one unique event 
   filter and a set of view filters and priority/notification filters.  
   The server only needs to support one connection per mobile device for 
   each email user.  A mobile client connects to the Lemonade server by 
   supplying its LOGIN information, and then must inform the server of 
   this mobile clientĘs device ID, which is some unique identifier for 
   the client device.  The server and client should agree on what 
   convention to use for this ID, and it could be a hash of IMEI.  If no 
   device ID is given, then a regular IMAP session is initiated.  The 
   LOGIN information is used to specify a user, while the device ID is 
   needed to specify the mobile client.  Associated with the user and 
   device ID is exactly one view filter and exactly one 
   priority/notification filter for each folder.  These filters are 
   saved and thus persist across Lemonade sessions. Filters can be 
   modified when a Lemonade session is open. 
    
 
 
Maes                    Expires - January 2005                [Page 7] 
              <Lemonade Server to Client Notifications>     July 2004 
 
 
2.1.1. The View Filter 
    
   View filters and priority/notification filters are used to filter out 
   email messages which match certain criteria.  If an email passes 
   through the view filter, it is stored in the mobile repository. The 
   syntax for defining a view filter or notification filter includes any 
   combination of most of the search criteria as defined for the SEARCH 
   command of IMAP, in Section 6.4.4 and 7.2.5 of RFC 3501, or a days 
   filter.  The days filter filters messages received starting a certain 
   number of days before the current day.  The ALL search criteria, when 
   used alone, means that every email event satisfies the criteria.  By 
   default, view filters are set to ALL. 
    
   Whenever a view filter is modified, the client needs to perform a 
   state-comparison-based sync to keep in sync with the mobile 
   repository since the messages in the mobile repository may have 
   changed. 
    
2.1.2. The Priority/Notification Filter 
    
   Priority/Notification filters are used to select emails in the mobile 
   repository which match certain criteria.  If an email passes through 
   the notification filter, it is stored in the push repository.  The 
   syntax for defining a priority/notification filter is discussed 
   below.  By default, priority/notification filters are set to NOT ALL 
   to reduce default traffic at the cost of some delays. 
    
   Because the view filter defaults to ALL and the priority/notification 
   filter to NOT ALL, the mobile repository will mirror the complete 
   repository, but none of the messages are added to the push 
   repository.  This implies that the default behavior is equal to the 
   IMAPv4 Rev1 model. 
    
   The client does not need to do anything after it resets a 
   priority/notification filter or event filter, instead the server 
   should then only send out notifications that correspond to the most 
   up-to-date filters. 
    
2.1.3. The Syntax to define Priority/Notification Filters 
    
   The syntax for defining a priority/notification filter is ALL, NONE, 
   or NEW.  A priority/notification filter applies for all folders in a 
   push repository. 
     ALL  -- All message events concerning messages of the push 
   repository will be sent to the client, such as if the message becomes 
   seen or deleted. 
     NONE -- No events should be pushed to the client. 
     NEW  -- Only events that concern new messages arriving to the push 
   repository should be pushed to the client. 
 
 
Maes                    Expires - January 2005                [Page 8] 
              <Lemonade Server to Client Notifications>     July 2004 
 
 
     This one event filter applies for all folders. 
 
2.2.  Connectivity Models 
    
   There are three connectivity models for Lemonade Server to Client 
   Notifications, depending on the capabilities of the Lemonade server, 
   the client, and the connection available between them.  These models 
   include in-response, inband, and outband.  It is explicitly stated in 
   what situations these three connectivity models arise. 
    
2.2.1. In-Response Connectivity 
    
   The in-response binding scenario is the most basic one and implements 
   the poll model. In this case the client initiates the commands to the 
   Lemonade server and the server responds to client commands with 
   events.  In this case there is no need for a persistent connection 
   between the client and the server. The client opens a connection only 
   when it needs to send commands to the Lemonade server, and that is 
   the only time it is notified of new events. 
        +--------+                    +++ HTTP, etc.     +--------+ 
        |        |  Command           +++                |        | 
        | Client |--------------------+++--------------->|Lemonade| 
        | Device |                    +++                | Server | 
        |        |  Response + Event  +++                |        | 
        |        |<-------------------+++----------------|        | 
        +--------+                    +++                +--------+ 
                    Figure 4: In-Response connection 
 
   An in-response connection can occur in several situations:  
      [1] HTTP/HTTPS binding 
         - Server Requires: HTTP/HTTPS listener for IMAPv4  
         - Client Requires: HTTP/HTTPS client with IMAPv4 processing 
      [2] TCP Binding  
         - Server Requires: IMAPv4 
         - Client Requires: IMAPv4 + no IDLE 
 
2.2.2. Inband Connectivity 
    
   The inband binding scenario corresponds to a reliable push model.  In 
   this case the server pushes events to the client whenever they occur.  
   To do so, it must have a reliable means of communication with the 
   client, and the client should be ready to accept such notifications.  
   In this case, there needs to be a persistent connection between the 
   client and the server so that the server can push an event at any 
   time.  The client may optionally issue a request to retrieve more 
   information concerning an event.   
        
        +--------+                   OOO TCP, Persistent +--------+ 
        |        |  Push Event       OOO    HTTP, etc.   |        | 
 
 
Maes                    Expires - January 2005                [Page 9] 
              <Lemonade Server to Client Notifications>     July 2004 
 
 
        | Client |<------------------OOO-----------------|Lemonade| 
        | Device |                   OOO                 | Server | 
        |        | Optional Request  OOO                 |        | 
        |        |...................OOO................>|        | 
        +--------+                   OOO                 +--------+ 
                      Figure 5: Inband Connection 
    
   An inband connection can occur in the following situations: 
      [1] TCP Binding, Always connected, IDLE 
         - Server Requires: IMAPv4 + IDLE 
         - Client Requires: IMAPv4 + IDLE, constant TCP connection 
      [2] Any other persistent two-way connection 
         - Server Requires: IMAPv4 + IDLE 
         - Client Requires: IMAPv4 + IDLE, constant connection 
    
2.2.3. Outband Connectivity 
    
   The outband binding scenario corresponds to an unreliable push model.  
   In this case the server pushes events to the client whenever they 
   occur, to the best of its ability.  To do so, it should be able to 
   send messages to the client without the need for a persistent 
   connection.  However, the outband channel can possibly lose and 
   reorder messages, and there are no timing guarantees.  Examples of 
   out-band channels include SMS, JMS, WAP Push, and UDP.  As in the 
   inband scenario, the client may optionally open a Lemonade session 
   over an inband or in-response connection and send a command as a 
   result of receiving an event.   
    
        +--------+  Push Event   XXX SMS                 +--------+ 
        |        |<--------------XXX---------------------|        | 
        | Client |               XXX                     |Lemonade| 
        | Device |                   Inband or           | Server | 
        |        |  Request      +O+ In-response         |        | 
        |        |---------------O+O-------------------->|        | 
        +--------+               +O+                     +--------+ 
                      Figure 6: Outband Connection  
    
    
   Outband connectivity occurs in the following situations: 
      [1] A notification service from the server to the client 
         - Server Requires: A notification generator. 
         - Client Requires: A notification processor. 
          
          
2.3. Keeping the Client In Sync with the Mobile Repository 
    
   Whenever a client device opens a new session, it must perform a 
   state-comparison-based sync with the email server so that its state 
   is the same as the mobile repository.  Since the client has no way of 
 
 
Maes                    Expires - January 2005               [Page 10] 
              <Lemonade Server to Client Notifications>     July 2004 
 
 
   directly detecting only changes to the repository since the last 
   login, it needs to retrieve information about every message in the 
   mobile repository and calculate the changes itself.  After that 
   point, the client can use event-based synchronization to keep the 
   device in sync.   
    
   The Lemonade server can issue a session and track changes to a 
   selected folder for the duration of a session.  Until the session is 
   expired, the server must log all events that occur while a client is 
   offline.  This way, if the client temporarily loses a connection, it 
   does not have to worry about missing any events and needing to 
   perform another state-comparison-based sync.  A client does have the 
   option though to prematurely end a session by issuing a LOGOUT 
   command.   Additionally, Lemonade clients can remain inactive for at 
   least twenty four hours without being logged off the server and 
   without the session expiring. 
 
    
3. Events 
 
   This section contains the syntax that the server uses to send events 
   to the client. 
 
3.1. Message Events Sent During Inband and Inresponse Mode 
    
   The client can receive the following untagged responses from the 
   server: 
    
   [1] The client receives an EXISTS/RECENT event from the server 
   indicating a new message. 
         S: * 501 EXISTS  
         S: * 1 RECENT 
   Next, the client retrieves this new message using a FETCH command. 
         C: A02 FETCH 501 (ALL BODY[]) 
         S: * 501 FETCH ... 
         S: A02 OK FETCH completed 
    
   [2] The client receives an EXPUNGE event from the server from a 
   message has been permanently removed from a folder. 
         S: * 25 EXPUNGE  
   The client deletes this message from the client device, as it has 
   been removed permanently from the folder.  The client does not need 
   to send any command back to the server. 
    
   [3] The client receives an untagged FETCH event from the server, 
   which can contain just FLAG information if the event is regarding an 
   old message or possibly other information if the event is regarding a 
   new message.  This event is received if a message's flags are 


 
 
Maes                    Expires - January 2005               [Page 11] 
              <Lemonade Server to Client Notifications>     July 2004 
 
 
   changed, or in response to a new message if the user's preferences 
   are set to do so.  
         S: * 101 FETCH (FLAGS (\Seen \Deleted)) 
   The client saves the information contained in this response 
   accurately in the client device. 
 
 
3.2. Folder Events 
    
   This section will contain syntax for indicating folder events. 
    
    
3.3. PIM Events 
    
   This section will contain syntax for indicating PIM events. 
    
     
4. Interactions between the Lemonade Client and Lemonade Server 
    
   Interactions between Lemonade clients and servers are described in 
   [LEMONADEPROFILE]. 
    
   The Lemonade Server to Client Notifications also define events to be 
   sent by the server to the client.  These events notify the client 
   when there are changes to messages that match an end userĘs view 
   filters and notification filters, as well as any changes to a 
   clientĘs email folders.  The syntax defined in this section is an 
   abstract syntax, and payloads may vary according to the communication 
   mechanism used.  The normative appendix of this document describes 
   some specific payloads. 
    
    
4.1.  Revisions to IMAPv4 Rev1 Behavior 
    
4.1.1. UID 
    
   The UID of email messages MUST not change across sessions.  Changing 
   the UID of email messages requires a heavy computational burden on 
   the mobile client, so the server should avoid doing so. The UID of 
   email messages MUST not change for the duration of a session. 
    
    
4.1.2. Mobile Repository 
    
   In a Lemonade session, the client can only access messages in the 
   mobile repository.  This affects the messages returned by FETCH, UID 
   FETCH, etc.  Message sequence numbers reflect the relative position 
   of messages within the given folders of the mobile repository, so the 
   message sequence number of an email while logged in to Lemonade may 
 
 
Maes                    Expires - January 2005               [Page 12] 
              <Lemonade Server to Client Notifications>     July 2004 
 
 
   also differ from IMAP.   When returning information about the email 
   account, only messages in the mobile repository are taken into 
   account. 
    
4.1.3. IDLE 
 
   The server should implement the IDLE command from RFC 2177.  When the 
   client issues this command, the server can push changes to a folder 
   to the client.  The server may replace the EXISTS/RECENT message with 
   an untagged FETCH command as specified in [EXTENSIONS] (Section on 
   2.2.2. ” See LEMONADESETPREF & LEMONADEGETPPREFS). The client should 
   fire this command while in-session to enter inband mode, where the 
   server will actively push notifications to the client. 
 
4.1.4. LEMONADESETPREF & LEMONADEGETPPREFS 
    
   The LEMONADESETPREF command is described in [EXTENSIONS]. It allows a 
   user to define certain configuration parameters, while the 
   LEMONADEGETPREFS command allows a user to retrieve the configuration 
   values.  Any server that implements these commands must respond with 
   LEMONADEPREF as one of the capabilities in response to a CAPABILITY 
   command.  It must also announce the values these parameters can be 
   set to in the LEMONADEPROVISION command (See [EXTENSIONS]).  These 
   parameters affect how outband notifications are sent to the client, 
   as well as the format for sending new event notifications.  If the 
   server supports LEMONADEPREF they are required to support all of the 
   following preferences with at least one value to set each preference 
   to.  They are described in [EXTENSIONS]. 
      
    
4.1.5. LEMONADEFILTER 
    
   The LEMONADEFILTER command allows users to set up view filters and 
   priority/notification filters.  LEMONADEFILTER can be fired when the 
   state is AUTHENTICATED or SELECTED.  The first argument to this 
   command is the folder that that filter should be applied to, or "ALL" 
   for all folders.  Next the user specifies "V", "N", or "B" to set 
   either a view filter or a priority/notification filter, or both.  
   Following this, it must specify the filter criteria using a 
   combination of search criteria as defined for the SEARCH command of 
   IMAP, in Section 6.4.4 and 7.2.5 of RFC 3501, or the days filter.  
   The ALL search criteria, when used alone, means that every email 
   message satisfies the criteria.  Or it can specify "V" or "N" to get 
   a view filter or priority/notification filter.  In this case, the 
   last argument is "GET" to retrieve the filter.  
   By default, view filters are set to ALL, while priority/notification 
   filters are set to NOT ALL.  This means that the mobile repository 
   includes all the messages in the complete repository, but none are 
   pushed to the client, which is the IMAPv4 Rev1 model.   
 
 
Maes                    Expires - January 2005               [Page 13] 
              <Lemonade Server to Client Notifications>     July 2004 
 
 
    
   Exactly one view filter and one priority/notification filter is 
   associated with each folder for each device.  When a new view filter 
   or priority/notification filter is created, it replaces the previous 
   filter for that folder.  When a view filter is modified, the client 
   needs to perform a state-comparison-based sync on the client in order 
   for the device to be in sync with the mobile repository.  The server 
   always sends only notifications that correspond to the most up-to-
   date view filters and priority/notification filters.  All filters 
   persist across Lemonade sessions; once set, a filter on a folder 
   applies until the user changes it. 
    
   Lemonade introduces a filter, the days filter, which allows a user to 
   specify from how many days before today it would like to see emails.  
   To see only today's email, a 0 should be used for the int. 
    
   lemonadefilter_cmd = tag SP "LEMONADEFILTER"  SP ("ALL" / folder) SP     
                  (("V" / "N" / "B") SP lemonadefilter_criteria) / 
                   
                  (("V" / "N") "GET") 
   lemonadefilter_criteria = (IMAPv4Rev1_searching_criteria / 
   days_filter)  
                        [SP lemonadefilter_criteria] 
   days_filter = "DAYSBEFORETODAY" SP int 
   Valid States:  AUTHENTICATED or SELECTED 
   Responses:  untagged responses: lemonadefilterGet_resp 
   lemonadefilterGet_resp = "*" SP  "LEMONADEFILTER" SP folder SP 
   ("V"/"N")  
                      lemonadefilter_criteria  
   Result:  OK - filter created  
            NO - can't create the filter 
            BAD - invalid arguments 
    
   Example: The client creates a priority/notification filter for all 
   messages in the Inbox from "John" since Jun. 1st, 2003.   
      C: A001 LEMONADEFILTER INBOX P SINCE 1-Jun-2003 FROM "John"  
      S: A001 OK LEMONADEFILTER completed 
    
   Example:  The client asks for the view filter for all the folders. 
      C: A001 LEMONADEFILTER ALL V GET 
      S: * LEMONADEFILTER ~/INBOX V ALL 
      S: * LEMONADEFILTER ~/TRASH V NOT ALL 
      S: A001 OK LEMONADEFILTER completed 
     
   Example: Stop notifications on a particular device, fired while in 
   AUTHENTICATED mode. 
      C: A001 LEMONADEFILTER ALL P NOT ALL  
      S: A001 OK LEMONADEFILTER ALL P NOT ALL completed 
    
 
 
Maes                    Expires - January 2005               [Page 14] 
              <Lemonade Server to Client Notifications>     July 2004 
 
 
Security Considerations 
    
   The protocol calls for the same security requirements for an in-
   response and inband connectivity mode as IMAP.   
    
   For the outband connectivity mode, servers should use encryption 
   methods for notifications if sensitive information is included in the 
   payload of that notification. 
    
   When an implementation of Lemonade is proxy-based, this may create 
   new security issues.  These issues are discussed in detail in 
   Appendix C, because the issues are dependent on the implementation of 
   this protocol rather than inherent to the protocol itself. 
    
    
References 
    
   [OMA-EN] Open Mobile Alliance Email Notification Version 1.0, August 
      2002.  http://www.openmobilealliance.org/tech/docs/EmailNot/OMA-
      Push-EMN-V1_0-20020830-C.pdf 
    
   [IMAP-DISC] Austein, R.  "Synchronization Operations For Disconnected 
      Imap4 Clients", IMAP-DISC, November 1994.  
      http://asg.web.cmu.edu/cyrus/rfc/draft-ietf-imap-disc-01.html 
    
   [RFC2119] Brader, S.  "Keywords for use in RFCs to Indicate 
      Requirement Levels", RFC 2119, March 1997.  
      http://www.ietf.org/rfc/rfc2119 
    
   [RFC2180] Gahrns, M.  "IMAP4 Multi-Accessed Mailbox Practice", RFC 
      2180, July 1997.  
      http://www.ietf.org/rfc/rfc2180 
    
   [RFC2234] Crocker, D. and Overell, P.  "Augmented BNF for Syntax 
      Specifications", RFC 2234, Nov 1997.  
      http://www.ietf.org/rfc/rfc2234 
    
   [RFC2420] Kummert, H.  "The PPP Triple-DES Encryption Protocol 
      (3DESE)", RFC 2420, September 1998. 
      http://www.ietf.org/rfc/rfc2420 
    
   [RFC2616] Fielding, R. et al.  "Hypertext Transfer Protocol -- 
      HTTP/1.1", RFC 2616, June 1999.  
      http://www.ietf.org/rfc/rfc2616 
    
   [RFC2617] Franks, J. et al.  "HTTP Authentication: Basic and Digest 
      Access Authentication", RFC 2617, June 1999.  
      http://www.ietf.org/rfc/rfc2617    
    
 
 
Maes                    Expires - January 2005               [Page 15] 
              <Lemonade Server to Client Notifications>     July 2004 
 
 
   [RFC2683] Leiba, B. "IMAP4 Implementation Recommendations", RFC 2683 
      Sep 1999. 
      http://www.ietf.org/rfc/rfc2683  
    
   [RFC2177] Leiba, B. "IMAP4 IDLE Command", RFC 2177, June 1997. 
      http://www.ietf.org/rfc/rfc2177  
    
   [RFC2818] Rescorla, E. "HTTP over TLS", RFC 2818, May 2000.  
      http://www.ietf.org/rfc/rfc2818 
    
   [RFC2822] Resnick, P. "Internet Message Format", RFC 2822, April 
      2001.  http://www.ietf.org/rfc/rfc2822 
     
   [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol 
      Version 4 rev1", RFC 3501, March 2003. 
      http://www.ietf.org/rfc/rfc3501 
    
   [LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile", 
      draft-ietf-lemonade-profile-00.txt, (work in progress), July 2004. 
    
   [EXTENSIONS] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and 
      Chiu, E., "Lemonade Command Extensions", draft-maes-lemonade-
      command-extensions-00.txt, (work in progress), July 2004. 
    
    
Normative Appendices 
    
A.  Event Payload 
    
    
A.1.  Event Payload in Clear Text for Lemonade Sessions 
    
   The event payload for a Lemonade session follows the general format 
   explained in Section 1.3.2, and is in clear text. 
    
    
A.2.  Outband Channel Event Payload 
    
   The suggested payload for notifications is that suggested by the OMA, 
   see [OMA-EN]. This notification informs the client that some push 
   event has happened on the server, so it must connect to fetch the 
   information. 
    
   When the client finally connects, the Lemonade server has opportunity 
   to send other pending events for this client.  
          
     Example: new message arrives on the server and this is notified via 
   outband. 
      S: pushes SMS with the following text: 
 
 
Maes                    Expires - January 2005               [Page 16] 
              <Lemonade Server to Client Notifications>     July 2004 
 
 
         <emn  
           mailbox="mailat:joe@foo.com"  
           timestamp="2004-02-20T06:40:00Z"> 
         </emn> 
      C: needs to connect and send any command to get the pending events    
      and act upon them. 
      C: A00 Login joe password 
      S: * SESSION SELECTED 
      S: * FOLDER INBOX 
      S: * 100 EXITS 
      S: * 87 EXPUNGE 
      S: * 90 FETCH (FLAGS \Seen) 
      S: A00 OK LOGIN completed 
      C: must now act on the events on the order they are received, 
   meaning, first perform a FETCH to get new message, then expunge 
   message 87 and change flags of message 90. 
 
    
Non-Normative Appendices 
 
B. Use Cases 
    
   In this section some use cases on Lemonade are presented so that it 
   is possible to correctly understand concepts and message flow. 
    
B.1.  State Comparison-Based Sync 
    
   Each time a client logs into a new Lemonade session, it must perform 
   a state comparison-based sync.  To synchronize with the server, the 
   client needs to fetch all the new messages, and all the flags of the 
   old messages.   
    
   The client has N messages in a given folder with highest UID = X and 
   is disconnected from the Lemonade server.  It connects to the server 
   and performs the following command: 
       
      First, it retrieves all the new messages. 
         C: A01 UID FETCH X+1:* ALL 
         S: * m FETCH ... 
         S: ... <more new messages if they exist> 
         S: A01 OK FETCH completed 
       
      The client stores all this information on the device and displays  
      it.  Next, it wishes to sync up the old messages. 
         C: A02 FETCH 1:m-1 (UID FLAGS) 
         S: * 1 FETCH (UID 3242 FLAGS (\Seen ...)) 
         S: ... <info for 2 through n-1> 
         S: * n FETCH (UID 3589 FLAGS (\Seen ...)) 
         S: A02 OK FETCH completed 
 
 
Maes                    Expires - January 2005               [Page 17] 
              <Lemonade Server to Client Notifications>     July 2004 
 
 
    
    
B.2.  Event-Based Sync 
    
   During a Lemonade session, the client will receive events in the form 
   of untagged EXISTS, RECENT, EXPUNGE, or FETCH responses.  The client 
   must respond to these events.  Sometimes, it will receive these 
   events by polling, by issuing a Lemonade command, such as NOOP.  It 
   can also use IDLE so that the server can push events to the client.  
   The example following shows how the client acts during an IDLE 
   command, but it should also take the same actions (minus firing and 
   exiting IDLE mode) when it receives these events through polling.   
          
    
   A client can choose to issue an IDLE command to get events pushed to 
   it, or it can receive events from polling using NOOP or any other 
   IMAP command.  First the client issues the IDLE command: 
         C: A02 IDLE 
         S: + Ready for argument 
    
   Now the client can receive any of the three following untagged 
   responses from the server. 
    
   When the client receives an EXISTS/RECENT response from the server: 
         S: * 501 EXISTS  
      First, the client must exit from this IDLE command. 
         C: DONE 
         S: A02 OK IDLE completed 
      Next, the client retrieves this new message using a FETCH command. 
         C: A02 FETCH 501 ALL 
         S: * 501 FETCH ... 
         S: A02 OK FETCH completed 
      The client returns to IDLE mode by issuing another IDLE command. 
         C: A03 IDLE 
         S: + Ready for argument 
    
   When the client receives an EXPUNGE response from the server: 
            S: * 25 EXPUNGE  
   The client deletes this message from the client device, as it has 
   been removed permanently from the folder.  The client can remain in 
   IDLE mode. 
    
   When the client receives an untagged FETCH response from the server, 
   either signally a flag change to an old message or a new message: 
         S: * 101 FETCH (FLAGS (\Seen \Deleted)) 
   The client updates the information on the device for this message 
   appropriately. 
    
 
 
 
Maes                    Expires - January 2005               [Page 18] 
              <Lemonade Server to Client Notifications>     July 2004 
 
 
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 
    
   Corby Wilson 
   Enterprise Mobility Systems 
   Nokia 
   503 Martindale Street 
   Suite 610 
   Pittsburgh, PA 15212 
   USA 
   Phone: +1-412-576-5402 
   Email: Corby.Wilson@nokia.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 
    
 
 
Maes                    Expires - January 2005               [Page 19] 
              <Lemonade Server to Client Notifications>     July 2004 
 
 
   Copyright (C) The Internet Society 2003.  All Rights Reserved. 
        
   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. 
        
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS 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. 
    
Acknowledgement 
    
   This document is based on the work in progress described in 
   draft-maes-lemonade-p-imap-03.txt. 




















 
 
Maes                    Expires - January 2005               [Page 20]