< Lemonade Notifications and Filters>      March 2006


Lemonade
Internet Draft: Lemonade Notifications and                   S. H. Maes
Filters
Document: draft-ietf-lemonade-notifications-
01.txt
Expires: September 2006                                      March 2006


                    Lemonade notifications and filters

Status of this Memo

   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.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document discusses how to provide notification and filtering
   mechanisms to IMAP [RFC3501] as part the Lemonade profile
   [LEMONADEPROFILEBIS].

Conventions used in this document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.




Maes                   Expires - September 2006               [Page 1]


                < Lemonade Notifications and Filters>      March 2006


   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
   Copyright Notice..................................................1
   Abstract..........................................................1
   Conventions used in this document.................................1
   Table of Contents.................................................2
   1. Introduction...................................................3
   2. Objectives.....................................................3
   3. Notification logical architecture and LEMONADE Profile phase 2.4
   4. Capability Descriptions........................................5
   5. Event-based synchronization....................................6
   6. Filters........................................................7
      6.1. Next steps and future work................................7
   7. Inband notification payload....................................7
   8. Outband Notification payload...................................7
      8.1. Outband Notification Payload in Clear Text................8
      8.2. Encrypted outband notifications..........................10
   9. LEMONADE message store behavior...............................10
   10. Checking notification settings...............................10
   11. Changing notification settings...............................10
   12. LPROVISION...................................................11
         12.1.1. LSETPREF & LGETPREFS...............................12
   13. Changing filters from the client.............................14
   14. Out of scope items for IETF..................................14
   Security Considerations..........................................15
   References.......................................................15
   Appendix A.Out-of-band SMS channel binding (INFORMATIVE appendix)16
   Future Work......................................................17
   Version History..................................................17
   Acknowledgments..................................................17
   Authors Addresses................................................18
   Intellectual Property Statement..................................18
   Disclaimer of Validity...........................................18


Maes                   Expires - September 2006               [Page 2]


                < Lemonade Notifications and Filters>      March 2006


   Copyright Statement..............................................19
   Acknowledgement..................................................19


1.
   Introduction

   As the work on LEMONADE Profile ([LEMONADEPROFILE] and
   [LEMONADEPROFILEBIS]) progresses, a need has been identified to
   provide notification and filtering mechanisms to IMAP4.

   The requirements for inband and outband server to client
   notifications are documented in [OMA-ME-RD].

2.
  Objectives

   According to these analyses, there is a need to support:
   - Mechanisms for event-based (server to client) synchronization:
      - Defines the relationship between notification mechanisms and the
     IMAP4 protocol
         - To minimize the latency observed for email events on the
         email server to be reflected in the email client.
         - To avoid unnecessary polling and requests from the e-mail
         clients:
            - To reduce the total amount of data to be exchanged between
            email server and client, e.g. by allowing the email client
            to select which messages to synchronize and how to
            synchronize.
            - To reduce the amount of transactions.
      - Needs to cope with possible lost or delayed notifications
      - Support in-band (within IMAP band) and out-band notifications
     (Exchanged via other servers / enablers).
         - Specified in ways that are network transport independent but
         may contain some bindings to particular notification channels
         (e.g. SMS binary, WAP Push, SIP Notification, ...)
         - When the email client is connected to the email server, only
         inband notifications is expected take place
      - Defines notification payload for inband and outband mechanisms.
   - Server-side filtering to decide which messages will be accessible
   by the email client.
     - Filtering results into the following logical types:
         - Type A: Messages filtered out and not accessible by the email
         client (no notification, no header access, no access)
         - Type B: Messages that are accessible by the mobile e-mail
         enabler client but no outband notification takes place. Inband
         notification might however take place if email client is
         already connected to email server.
         - Type C: Messages that are accessible by the e-mail client for
         which notifications (outband or inband) are always sent to the
         email client.


Maes                   Expires - September 2006               [Page 3]


                < Lemonade Notifications and Filters>      March 2006


   - Notions of Filters:
     - View filters: Filters that determine which email messages are of
     type B and C or A
     - Notification filters: Filters that determine which email messages
     are of type C or B
     - Event filters: Filters that determines what events are to be
     notified to the client
   - Mechanisms to allow the user to update the filters from the email
   client
   - Mechanisms to allow configuration and exchange of settings between
   the client and the server in band or outband:
     - Server to client: e.g. server ID, account name, policies, …
     - Client to server: e.g. rules filters vacation notices,
     notification channel, ...

   The present document describes how this may be achieved within the
   scope of LEMONADE Profile [LEMONADEPROFILEBIS].

3.
  Notification logical architecture and LEMONADE Profile phase 2

   The target logical architectures involving the LEMONADE Profile and
   notifications are discussed in [LEMONADEPROFILEBIS].

   Figure 1 illustrates how notification and filtering can be introduced
   in the context of LEMONADE profile phase 2.



                     +--------------+_____________
                     |              |
           +---------| Notification |
           |         | Mechanism    |
           |         +----------^---+
           |Notif.              |
           |Protocol -------\  +|-+_
           |   ______|   +---\>|NF|----+____
           |  |          |     +--+    |                +-----+ _____
         __v__|   IMAP   +--+_LEMONADE +---+__ESMTP  +--+     |
        +-----+<-------->|VF| IMAP     |DF |<--------|AF| MTA |
        | MUA |\   ME-2a +--+ Store    +-^-+         +--+_____|
        |_____| \        +-------------+ |              +-----+
        +-----+--\---------------|-------+
                  \              |URLAUTH
                   \SUBMIT       |
                    \       +----v-----+_____
                     \      |          |                +-----+ _____
                      \     | LEMONADE |      ESMTP     |     |
                       ---->| Submit   |--------------->| MTA |
                   ME-2b    | Server   |                |_____|


Maes                   Expires - September 2006               [Page 4]


                < Lemonade Notifications and Filters>      March 2006


                            |__________|                +-----+
                            +----------+

   Figure 1: Filtering mechanism defined in LEMONADE Profile phase 2
   architecture.

   In Figure 1, four categories of filters are defined:

      - AF: Administrative Filters - Set up by email service provider.
   AF are typically not configured by the user and set to apply policies
   content filtering, virus protection, spam filtering etc...
      - DF: Deposit Filters - Filters that are executed on deposit of
   new emails.  They can be defined as SIEVE filters [SIEVE].  They can
   include vacation notices.
      - VF: View Filters - Filters that define which emails are visible
   to the MUA.  View filters can be defined as virtual folders [VFOLDER]
   as described in later in this document.
      - NF: Notification Filters - Filters that define for what email
   server event an outband notification is sent to the client.

   The filters are manageable from the MUA:
      - NF and DF: via SIEVE management protocol <Editor's note: Still
   to be defined>. [IMAPSIEVE] provides an example of how notification
   filters (NF) may be expressed in SIEVE.
      - VF: via VFOLDER as defined in [VFOLDER]

4.
  Capability Descriptions

   CAPABILITY can be used to support determination of support of server
   to client notification.

   The CAPABILITY command is defined in RFC3501, section 6.1.1.  The
   client sends a CAPABILITY command so it can query the server to find
   out what commands it supports.  In RFC3501, the IMAP server is
   allowed to specify additional capabilities not included in that
   specification.  A server MUST list what commands it supports.

   A server can also enumerate individually the other commands that it
   supports.

   capability_cmd =  tag SP "CAPABILITY"
   Valid States:  NOT AUTHENTICATED, AUTHENTICATED, SELECTED, or LOGOUT
   Responses:  REQUIRED untagged response: CAPABILITY
   Result:  OK - capability completed
      BAD - command unknown or arguments invalid

   Example: A server that implements Server to Client Notification and
   Filtering.
      C: a001 CAPABILITY


Maes                   Expires - September 2006               [Page 5]


                < Lemonade Notifications and Filters>      March 2006


      S: * CAPABILITY IMAP4rev1 AUTH=LOGIN IDLE LPROVISION, LSETPREF,
   LGETPREF, LNOTIFICATION, LPSEARCH
      S: a001 OK CAPABILITY completed

   LPROVISION, LSETPREF and LGETPREF refer to the mechanisms defined in
   later sections.

   LPSEARCH declares support for [VFOLDER].

   LNOTIFICATION declares support for outband notification filters and
   filter management as described in this document.

5.
  Event-based synchronization

   The addition of Server-to-client notifications transforms the
   LEMONADE profile into an event-based synchronization protocol.
   Whenever an event of the type [MSGEVENTS] occurs with the view, a
   notification can be generated. [MSGEVENTS] provides a list of
   possible events that could be notified (based on the filter
   settings).

   If the MUA is connected to the IMAP server, inband notifications are
   generated following IDLE [RFC2177].

   When the MUA is not connected, the Notification filter generates a
   notification. The notification filter may be considered as acting on
   a PUSH repository.

   All three repositories have the same set of folders. Formally, a
   repository consists of a set of folders, and each folder has both a
   name and a set of messages associated with it. The ‘‘complete
   repository’’ consists of all folders of an end user and all the
   associated messages for each of those folders.

   Note UIDs are assume the same in these repositories for a same
   message.

   This is illustrated in Figure 2.

   +----------------+        +---------------+            +------------+
   |    COMPLETE    |        |               |            |            |
   |                | (VF)   |   VIEW        |            |   PUSH     |
   |   REPOSITORY   | View   |  REPOSITORY   |Notification| REPOSITORY |
   | all the emails |Filters | emails to be  |  Filters   | important  |
   |in an end user's|========|on the mobile  |=====<?>====| emails /   |
   |                |        |               |      |     |  events    |
   | email account  |        |client(VFOLDER)|      |     |   (NF)     |
   +----------------+        +---------------+      |     +------------+
                                                    |            |


Maes                   Expires - September 2006               [Page 6]


                < Lemonade Notifications and Filters>      March 2006


                                                  IDLE           |
                                                    |          Outband
                                                    |       Notification
                                                    |            |
                                                    V            V

               Figure 2:  Filters and Repositories

   In inband notification mode, IDLE is exchanged between the MUA and
   the LEMONADE IMAP server.

   In outband notification mode, the outband notification may be a
   message (notification payload) and possibly a set of surrounding
   exchanges sent with an appropriate format to a particular IP address
   and port. This may be the address of the MUA. However, in general, it
   conforms to the interface of a notification server / mechanisms
   responsible for finalizing the format and sending the notification to
   the MUA on the client with the appropriate protocol.

   The following sections provide description of the outband
   notification payload format and mechanisms to check, set and
   notification settings.

6.
  Filters

   [SIEVE] provides an email filtering language.

   [VFOLDER] describes how the View Filter (VF) can be implemented and
   modified from the MUA.

   [SIEVENOTIFICATION] and [IMAPSIEVE] provides a mechanisms to
   associate notifications based on the [SIEVE] filter whenever messages
   are created or changed within a LEMONADE IMAP store.

   6.1.
        Next steps and future work

   [SIEVE] filters and [IMAPSIEVE] should be extended to support binding
   to all [MSGEVENTS].

7.
  Inband notification payload

   Inband notification syntax follows the IDLE specifications [RFC2177].

   Any inband notification must be considered by the MUA as a wake up
   call for the MUA to get back to the server.

8.
  Outband Notification payload




Maes                   Expires - September 2006               [Page 7]


                < Lemonade Notifications and Filters>      March 2006


   8.1.
         Outband Notification Payload in Clear Text

   The outband notification payload is in general in clear text. Server
   to Client Notification and Filtering treats the notification as a
   signal to the client to fetch the information on the server that
   awaits it.

   The suggested payload for notifications is that suggested by the OMA,
   see [OMA-EN]. This notification basically informs the client that
   some push event has happened on the server, so it must connect to
   fetch the information.

   Server to client notifications and filters treats the notificatoon as
   a MUA wake up event to fetch the information on the server that
   awaits it. The MUA MAY present other behaviors that exploit
   additional information provided in the notification. However this is
   out of scope of the specifications.

   Wake-up events consists of the following payload: <emn
   mailbox="mailat:john.doe@somewhere.com"
   timestamp="date_format_as_specified_in_[OMA-EMN]"></emn>

   The notification payload is generated by NF and sent to an
   appropriate messaging interface, appropriately formatted for that
   interface. The messaging mechanism is then responsible for sending
   the notification to the MUA.

   When the client finally connects, the server has opportunity to send
   other pending events for this client.

     Example: A new message arrives on the server and this is notified
   via out-of-band.
      S: pushes SMS with the following text:
         <emn
           mailbox="mailat:joe@foo.com"
           timestamp="2004-02-20T06:40:00Z">
         </emn>

   The notification payload is sent to an SMSC messaging interface,
   appropriately formatted for that interface. The SMSC is responsible
   for sending the SMS to the MUA.

      C: needs to connect and send any command to get the pending events
      and act upon them.
      C: A00 Login joe password <Editor’s note: to be updated based on
   Quick reconnect [CONNECT]>
      S: * SESSION SELECTED <Editor’s note: to be updated based on Quick
   reconnect [CONNECT]>
      S: * FOLDER INBOX


Maes                   Expires - September 2006               [Page 8]


                < Lemonade Notifications and Filters>      March 2006


      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.

   If EXTENDED notification format is supported by the MUA, the
   following notification may be send instead of the wake-up event as:
   The notification message is of the form:

   <tag> <notification seq no> <client-email-account -name>  <event>
   [<uid>, <sender>, <date>, <time>, <subject>, [<body.]]

   where <tag> is <tag> is ‘‘_%$L$%_’’,
   and <event> is one of
   NEW_MESSAGE
   DELETED_MESSAGE
   CHANGED_MESSAGE
   SYNC
   FULL_SYNC
   STATE_COMPARISON_SYNC
   NEW_ENC_KEY
   LOCK_DOWN

   Except for the <tag>, the notification message is encrypted using the
   encryption key.

   The different tags are:
   NEW_MESSAGE: a new message has arrived on the server
   DELETED_MESSAGE: a message has been deleted on the server
   CHANGED_MESSAGE: a message has changed on the server
   SYNC: Initiate an incremental synchronization (i.e. act as above)
   FULL_SYNC: Initiate a full synchronization (full IMAP
   synchronization)
   STATE_COMPARISON_SYNC: Compare state
   NEW_ENC_KEY: New encryption key is available to be obtained by
   LPROVISION
   LOCK_DOWN: Lock the client (in case of lost device) and erase data.

   The latter assumes that the client is able to support client lock to
   prevent usage / access to data of lost devices, or in general when
   desired by the server administrator.

   In the case of SYNC requests (incremental synchronization), the
   client sends its messages that are to be sent, describes the delete
   or change status operations to do on the server or and sending a NOOP
   message to the server and processing the responses. New messages are


Maes                   Expires - September 2006               [Page 9]


                < Lemonade Notifications and Filters>      March 2006


   fetched using UID FETCH command with the range (lastUID + 1):*. Where
   lastUID is that lastUID received so far. This typically happens when
   the server determines that the session is valid and the UID VALIDITY
   (See [IMAP-DISC]) is the same in client and server.

   In the case of FULL_SYNC requests (full synchronization), the client
   sends its messages that are to be sent, discards delete or change
   status operations to do on the server, discard its local emails (e.g.
   in INBOX) and populating the Inbox with messages using the FETCH 1:*
   command. It also rebuilds the UID-Sequence map.

   8.2.
        Encrypted outband notifications

   When using NEW_ENC_KEY, the notification are encrypted with ENC KEY.
   In the case of new encryption (NEW_ENC_KEY) and to cater for the
   unreliable nature of the notification channel, messages encrypted
   using old encryption key from a device MUST be accepted be the server
   until the server receives a message encrypted using the new key. From
   that point onward it MUST only accept the messages encrypted using
   the new key.


9.
  LEMONADE message store behavior

   Because outband notifications may be sent over unreliable channels
   (i.e. they may be lost or delayed), the server MUST keep track of the
   outband notifications that are sent via NF, until the MUA react to
   them.

   When the MUA request changes from the server, it MUST provide all the
   changes since the last time the client connected and requested
   changes (i.e. all the notifications that have not been acted upon and
   all the changes since the last notification). This ensure robustness
   to notification issues.

   If a MUA does not react to outband notifications, the server MAY stop
   sending outband notifications, expect possible periodic wake up call
   till the client reconnects.

10.
   Checking notification settings

   Mailbox annotations provide additional mechanism for the client to
   determine server settings.

   The LGETPREFS provides also an inband mechanisms  to determine these.

11.
   Changing notification settings




Maes                   Expires - September 2006              [Page 10]


                < Lemonade Notifications and Filters>      March 2006


   LETSETPREFS provides an inband mechanism to set / change notification
   and server settings.

12.
   LPROVISION

   The LPROVISION command is used to allow a device to obtain service
   specific parameters of the server. It can act differently compared to
   ANNOTATE [ANNOTATEMORE] by basing its decisions to return data
   depending on transport layer security state. This includes what
   filters have been defined.  Also, it will supply a list of all
   preferences and the values they can be set to. In addition, UDP
   information may be given when UDP notification is supported, such as
   the host name and port.  A server can return other parameters as long
   as its syntax is agreed upon with the client.

   lprovision_cmd =  tag SP "LPROVISION" SP device-id [notif-id]
   Valid States:  AUTHENTICATED or SELECTED
   Responses:  REQUIRED untagged responses XPROVISION
   Result:  OK - provision completed
               NO - can't provision this device
               BAD - command unknown, invalid argument

   <Editor’s note: device-id to be updated based on Quick Reconnect
   [CONNECT]>

   untagged LPROVISION LPREF response = "*" SP "LPROVISION" SP "LPREF"
      SP prev-name SP "(" pref_val_list ")"
   untagged LPROVISION UDP_HOST response = "*" SP "LPROVISION" SP "
      UDP_HOST" SP "(" udp_hostname ")"
   untagged LPROVISION UDP_PORT response = "*" SP "LPROVISION" SP "
      UDP_PORT" SP "(" udp_portnum ")"
   untagged LPROVISION ENC_KEY response = "*" SP "LPROVISION" SP "
      ENC_KEY " SP "(" encryptionkey ")"

   If LPROVISION is returning keys, the server should only do so in the
   following circumstances:

   a) TLS/SSL is being used
   b) SASL [RFC2222] confidentiality protection has been negotiated and
   enabled (See [XENCRYPTED])

      Example: The client issues an LPROVISION command.  The server
      returns the values of various LPREF's
      and the values they can be set to.  The server responds by
      returning the encryption key, modes, and channels supported.

      Note the syntax for returning parameters.

         C: A002 LPROVISION


Maes                   Expires - September 2006              [Page 11]


                < Lemonade Notifications and Filters>      March 2006



         S: * LPROVISION LPREF L_OUTBAND_CHANNEL (SMS NONE)
         S: * LPROVISION LPREF L_INBAND_NEW_FORMAT (NONE)
         S: * LPROVISION LPREF L_INBAND_PUSH (ON OFF)
         S: * LPROVISION LPREF L_EVENT_FILTER (NEW)
         S: * LPROVISION LPREF L_OUTBAND_FORMAT (EMN EXTENDED)
         S: * LPROVISION L_NOTIFICATION ADDRESS (address)
         S: * LPROVISION L_NOTIFICATION PORT (portnum)
         S: * LPROVISION L_ENC_KEY (enc_key)
         S: A002 OK LPROVISION completed

   The following two instructions may be supported:

         S: * LPROVISION L_UDP_HOST (udp_hostname)
         S: * LPROVISION L_UDP_PORT (udp_portnum)

   UDP HOST and UDP PORT define where the client initiates a UDP session
   for UDP notification.


12.1.1. LSETPREF & LGETPREFS

   The LSETPREF command allows a user to define certain configuration
   parameters, while the LGETPREFS command allows a user to retrieve the
   configuration values.  Any server that implements these commands must
   respond with LPREF 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 LPROVISION command as specified as
   follows.  These parameters affect how out-of-band notifications are
   sent to the client, as well as the format for sending new event
   notifications.  If the server supports LPREF they are required to
   support all of the following preferences.

   The preferences that can set with this command are as follows and
   their names start with L to identify them as the parameters
   introduced in this draft. (They may not apply in some configuration
   (e.g. no L OUTBAND ADDRESS when using UDP notifications)):

     [1] L_OUTBAND_ADDRESS - the number or email address to send out-of-
     band notification messages to the client.  This must be a valid
     address according to the out-of-band channel requirements.  This
     will not be returned in the LPROVISION command. This is not
     applicable to out-of-band UDP notifications.

     [2] L_OUTBAND_CHANNEL - the channel to send out-of-band
     notifications, either SMS, GSMSMS, JMS, WAP_PUSH, WAPWDP, MMS, SIP,
     UDP or NONE.  When NONE, the server does not send the client any
     out-of-band notifications.  The list of values may be extended with
     new values when different out-of-band channels are available. The


Maes                   Expires - September 2006              [Page 12]


                < Lemonade Notifications and Filters>      March 2006


     valid values for this preference that the server supports will be
     given in response to the LPROVISION command.

     [3] L_INBAND_NEW_FORMAT - the FETCH parameters to automatically
     send to the client when there is a new message and there is a valid
     session, or NONE.  If NONE, the server sends the client a
     traditional EXISTS message when a new message arrives in the
     folder.  Otherwise, in place of the EXISTS message, the server
     sends an untagged FETCH response with the given information.  The
     valid values for this preference that the server supports will be
     given in response to the LPROVISION command.

     [4] L_INBAND_PUSH - whether or not the server should automatically
     IDLE the server when a folder is selected.  The valid values for
     this preference that the server supports will be given in response
     to the XPROVISION command.

     [5] L_OUTBAND_FORMAT - the format to send the out-of-band
     notifications, i.e. EMN or EXTENDED.

     [6] L_EVENT_FILTER - The event filter for this user.  Possible
     values are ALL or NONE or NEW, depending on the server's
     capabilities.

   lgetpref_cmd = tag SP "LGETPREFS" SP "("
                        l_pref_list ")"
   l_pref_list = l_pref [SP ;_l_pref_list]
   l_pref = (L_OUTBAND_ADDRESS /
                 L_OUTBAND_CHANNEL / L_INBAND_NEW_FORMAT /
                 L_INBAND_PUSH / L OUTBAND FORMAT /
                 L_EVENT_FILTER)
   Valid States:  AUTHENTICATED or SELECTED
   Responses:  REQUIRED untagged LGETPREFS response with the value of
   the requested parameter.
      untagged LGETPREFS response - "*" LGETPREFS pref-pair
      pref-pair = "(" l-pref SP l-pref-val [pref-pair] ")"
   Result:  OK - command completed
            NO - command failure: can't alter preference
            BAD - command unknown or arguments invalid

   Example: The client wishes to know the current out-of-band
   notification method it has set up.  It sends an LGETPREFS command.
      C: A003 LGETPREFS (L_OUTBAND_CHANNEL)
      S: * LGETPREFS (L_OUTBAND_CHANNEL SMS)
      S: A003 0K LGETPREFS completed

   lsetpref_cmd = tag SP "LSETPREF" SP (("L_OUTBAND_ADDRESS" SP
         device_address) /



Maes                   Expires - September 2006              [Page 13]


                < Lemonade Notifications and Filters>      March 2006


          ("L_OUTBAND_CHANNEL" SP
         ("SMS"/"GSMSMS"/"JMS"/"WAP_PUSH"/"WAPWDP"/"MMS"/"UDP"/"SIP"/
         "NONE")) /
          ("L_INBAND_NEW_FORMAT" SP fetch_criteria) /
          ("L_INBAND_PUSH" SP ("ON" / "OFF")) /
          ("L_OUTBAND_FORMAT SP ("EMN" / "EXTENDED")) /

   Valid States:  AUTHENTICATED or SELECTED
   Responses:  No specific responses.
   Result:  OK - command completed
            NO - command failure: can't get a preference
            BAD - command unknown or arguments invalid

   Example: The client sets up its SMS device address and then selects
   that it wants SMS messages sent to the device, and the format of the
   SMS it wants.

      C: A002 LSETPREF L_OUTBAND_ADDRESS 13335559999
      S: A002 OK LSETPREF completed
      C: A003 LSETPREF L_OUTBAND_CHANNEL SMS
      S: A003 OK XSETPREF completed
      C: A004 LSETPREF L_OUTBAND_FORMAT EXTENDED
      S: A004 OK XSETPREF completed

   Example: The client sets the in-band NEW format to be ALL, meaning it
   wants the server to automatically send it all the headers for any new
   message.
      C: A002 LSETPREF L_INBAND_NEW_FORMAT ALL
      S: A002 OK LSETPREF L_INBAND_NEW_FORMAT completed
   From now on, whenever a new message arrives in a folder during a
   valid session, the server will try to send an untagged FETCH response
   of the new message with the specified information to the client at
   the earliest opportunity.  This untagged FETCH response replaces the
   untagged EXISTS response that IMAP sends regarding a new message.
      S: * 60 FETCH ...<headers>

13.
   Changing filters from the client

   VFOLDER also provides ways to update VF.

   NF Filter remote management mechanisms MAY rely on [MANAGESIEVE]

14.
   Out of scope items for IETF


   OMA provides ways to perform provisioning via OMA client provisioning
   and device management. Other provisioning specifications are
   available (e.g. SMS based).



Maes                   Expires - September 2006              [Page 14]


                < Lemonade Notifications and Filters>      March 2006


   OMA provides enablers to support outband notifications: the outband
   notification mechanisms.

   Also, OMA XDM may be considered also for outband filter changes.

Security Considerations

   Notifications must be secured (when useful information is send) and
   integrity should be checkable.

   It should be possible to prevent authenticate sender and prevent
   Denial of Service attack via notifications.


References

   [ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications:
      ABNF’’, RFC 2234, November 1997.
      http://www.ietf.org/rfc/rfc2234

   [ANNOTATEMORE] Daboo, C., "IMAP ANNOTATEMORE Extension", work in
      progress, draft-daboo-imap-annotatemore-xx, (work in progress).

   [GSM03.40] GSM 03.40 v7.4.0 Digital cellular telecommunications
      system (Phase 2+); Technical realization of the Short Message
      Service (SMS). ETSI 2000

   [IMAPSIEVE] Leiba, B., "Support for Sieve in Internet Message Access
      Protocol (IMAP4)", draft-ietf-lemonade-imap-sieve-0x (work in
      progress).

   [LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile",
      draft-ietf-lemonade-profile-XX.txt, (work in progress).

   [LEMONADEPROFILEBIS] Maes, S.H., Melnikov A. and D. Cridland, "
      LEMONADE profile bis", draft-ietf-lemonade-profile-bis-xx.txt,
      (work in progress).

   [MANAGESIEVE] Martin, T. and A. Melnikov, "A Protocol for Remotely
      Managing Sieve Scripts", draft-martin-managesieve-xx.txt, (work in
      progress).

   [MSGEVENTS] Newman, C., "Internet Message Store Events", draft-
      newman-lemonade-msgevent-xx.txt, (work in progress).

   [NOTIFICATIONS] Maes, S.H. and all, "Server to Client Notifications
      and Filtering", draft-maes-lemonade-notifications-server-to-
      client-XX.txt, (work in progress).



Maes                   Expires - September 2006              [Page 15]


                < Lemonade Notifications and Filters>      March 2006


   [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

   [OMA-ME-AD] Open Mobile Alliance Mobile Email Architecture Document,
      (Work in progress).  http://www.openmobilealliance.org/

   [OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document,
      (Work in progress).  http://www.openmobilealliance.org/

   [P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and
      Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn
      S-M., Xiaohui F. and Lijun Z., "Push Extensions to the IMAP
      Protocol (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in
      progress).

   [RFC2177] Leiba, B. "IMAP4 IDLE Command", RFC 2177, June 1997.
      http://www.ietf.org/rfc/rfc2177.

   [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol
      Version 4 rev1", RFC 3501, March 2003.
      http://www.ietf.org/rfc/rfc3501

   [SIEVE] SIEVE WG, http://www.ietf.org/html.charters/sieve-
      charter.html

   [SIEVENOTIFICATIONS] Melnikov, A., "Sieve -- An extension for
      providing instant notifications", draft-ietf-sieve-notify-XX.txt,
      (work in progress)

   [VFOLDER] Maes, S. and et Al., "Persistent Search Extensions and
      Virtual Folder to the IMAP Protocol", draft-maes-lemonade-vfolder-
      0x, (work in progress).

   [WAPWDP]  Wireless Datagram Protocol, Version 14-Jun-2001, Wireless
      Application Protocol WAP-259-WDP- 20010614-aWAP (WDP)

   [XENCRYPTED] Maes, S. and et Al., "XENCRYPTED", draft-maes-lemonade-
      xencrypted-xx, (work in progress).

Appendix A.
  Out-of-band SMS channel binding (INFORMATIVE appendix)

   One method for delivering wake-up notifications is by pushing the
   notification payload as a binary SMS message.  Upon receiving an SMS,
   a client would then parse the payload, determine if it is a email
   notification or some other SMS message, and process the message
   appropriately.




Maes                   Expires - September 2006              [Page 16]


                < Lemonade Notifications and Filters>      March 2006


   This has the unfortunate side effect of forcing the client to parse
   every message trying to sense what kind of message it is. The
   proposed mechanism to fix this is to utilize the binary

   SMS User Data Header (UDH) to specify a destination port, according
   to the Application Port

   Addressing Scheme in [GSM03.40] or alternatively, on CDMA networks,
   to use the WAP WDP mapping to GSM SMS [WAPWDP].

   Although any port number is usable, it might make sense to use port
   143 for consistency, which is the IANA IMAP port. Thus, OMA EMN or
   extended format notifications should be sent to port 143 via GSM SMS
   or WAP WDP. The client upon receiving the SMS will check the port
   number, and if the port is the right port, the message will be routed
   to the appropriate client application for processing.

   Because such mechanisms are network specific, a server should
   determine if a port specific SMS or WAP WDP mapping can be used based
   on knowledge of the device / network or on strategies that determine
   if the device reacts to such notifications. However, a client may
   also declare it / selecting the out-of-band notification channel as
   GSMSMS or WAPWDP as for any other notification channel.


Future Work

   [1] Complete the specification tasks and editor’s identified in this
   document:
      - Detailed NF specifications (Sieve or no sieve)
      - NF filter management protocol
      - Fix login and session based on evolution of Quick reconnect
   [CONNECT].


Version History

   Release 01
      Move SMS / WAP examples to an informative appendix.
      Restrict the exchange of keys via LPROVISION to secure exchanges.
      Differentiate ANNOTATE from LPROVISION on that basis.


   Release 00
      Initial release

Acknowledgments




Maes                   Expires - September 2006              [Page 17]


                < Lemonade Notifications and Filters>      March 2006


   The authors want to thank all who have contributed key insight in
   notifications and filtering and have authored specifications or
   drafts used in this document.


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 Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Disclaimer of Validity

   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 - September 2006              [Page 18]


                < Lemonade Notifications and Filters>      March 2006



Copyright Statement

   Copyright (C) The Internet Society (2006).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.








































Maes                   Expires - September 2006              [Page 19]