< 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 <Editors note: to be updated based on Quick reconnect [CONNECT]> S: * SESSION SELECTED <Editors 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 <Editors 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 editors 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]