<Lemonade Notifications and Filters> May 2006 Lemonade Internet Draft: Lemonade Notifications and S. H. Maes Filters Document: draft-ietf-lemonade-notifications- R. Cromwell 02.txt Expires: November 2006 May 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. This Internet-Draft will expire on November 30, 2006. 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]. This document also discusses the use of Lemonade notifications to implement server to server notifications. Conventions used in this document Maes Expires November 2006 [Page 1]
<Lemonade Notifications and Filters> May 2006 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]. 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 bis.....4 4. Capability.....................................................6 5. Event-based synchronization....................................6 6. Filters........................................................8 6.1. Next steps and future work................................8 7. Inband notification payload....................................8 8. Outband Notification payload...................................8 8.1. Outband Notification Payload in Clear Text................8 9. LEMONADE message store behavior...............................10 10. Provisioning and Preferences for Notification Settings.......10 10.1. Entry Names and Attributes..............................11 10.2. Provision Entries.......................................11 10.3. Preference Entries......................................12 10.4. Getting and setting preference and provisioning annotations.............................................13 11. Changing filters from the client.............................13 12. Out of scope items for IETF..................................14 13. Server to server notifications considerations................14 13.1. Scope of server to server notifications.................14 13.2. Basic Operation.........................................17 13.3. Server to server terminology............................17 Maes Expires November 2006 [Page 2]
<Lemonade Notifications and Filters> May 2006 13.4. Notification payloads...................................17 13.5. Server to server notification protocol details..........18 13.5.1. Exception Handling.................................19 13.6. Server to server complementary information..............19 13.7. Event orders............................................19 13.8. Reliability.............................................19 Security Considerations..........................................20 References.......................................................20 A. Out-of-band SMS channel binding (INFORMATIVE appendix).....22 Future Work......................................................22 Version History..................................................23 Acknowledgments..................................................23 Authors Addresses................................................23 Intellectual Property Statement..................................24 Disclaimer of Validity...........................................24 Copyright Statement..............................................24 Acknowledgement..................................................25 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, ...) Maes Expires November 2006 [Page 3]
<Lemonade Notifications and Filters> May 2006 - 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. - 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 bis The target logical architectures involving the LEMONADE Profile and notifications are discussed in [LEMONADEPROFILEBIS]. Maes Expires November 2006 [Page 4]
<Lemonade Notifications and Filters> May 2006 Figure 1 illustrates how notification and filtering can be introduced in the context of LEMONADE profile bis. +--------------+_____________ | | +---------| 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 | |_____| |__________| +-----+ +----------+ Figure 1: Filtering mechanism defined in LEMONADE Profile bis 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... Maes Expires November 2006 [Page 5]
<Lemonade Notifications and Filters> May 2006 - 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 A server supporting Lemonade notifications MUST report the following set of capabilities: IDLE, METADATA, LISTEXT, LNOTIFICATION, VFOLDER. METADATA (and by transitive dependency LISTEXT) are from the [ANNOTATEMORE] extension, used to store notification provisioning and preference information. VFOLDER declares support for [VFOLDER]. LNOTIFICATION is currently a placeholder umbrella capability declares support for outband notification filters and filter management as described in this document, which may includes works in progress such as SIEVE notification filters and filter management. 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 within 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 outband notification. The notification filter may be considered as acting on a PUSH repository. If the MUA is not connected, and outband notification is disabled, the client must perform a quick-sync on reconnect to determine Maes Expires November 2006 [Page 6]
<Lemonade Notifications and Filters> May 2006 mailbox changes. If the MUA has only momentarily lost connection, it should also attempt to use [RECONNECT]. 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. 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) | +----------------+ +---------------+ | +------------+ | | IDLE | | Outband | Notification | | V V Figure 2: Filters and Repositories In inband notification mode, the MUA issues IDLE, and notifications are sent as unsolicited responses to the MUA from 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. Maes Expires November 2006 [Page 7]
<Lemonade Notifications and Filters> May 2006 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]. However, which unsolicited responses are generated by each event is ambiguous in [RFC2177]. [CLEARIDLE] defines a more rigorous set of requirements for IDLE events, including how to monitor mailboxes when not in a selected state, however [CLEARIDLE] does not deal with all of the events defined by [MSGEVENTS]. Future work is needed to define a binding between [MSGEVENTS] and IDLE responses. In lieu of this, MUAs MAY choose to interpret unsolicited responses in IDLE as a "wake up call" to perform a sync. [IMAP-DISC] is an informative reference for how to do this efficiently. 8. Outband Notification payload 8.1. Outband Notification Payload in Clear Text The outband notification payload is in general in clear text, unless the payload carries sensitive data. 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 payload for wake-up notifications is the OMA EMN format, see [OMA-EN]. This notification, minimally, 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 notification as a MUA wake up event to fetch the information on the server that awaits it. The MUA MAY present other behaviors that exploit Maes Expires November 2006 [Page 8]
<Lemonade Notifications and Filters> May 2006 additional information provided in the notification. However this is out of scope of the specifications. Wake-up events consists of the following payload (example): <emn mailbox="mailat:john.doe@somewhere.com" timestamp="OMA-EMN-dateformat"> </emn> The mailbox URI formats are defined in [OMN-EN]. 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. 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> Here 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 using [OMA-EMN] encoding. If EXTENDED notification format is supported by the MUA, a new extended EMN element is used which contains additional XML attributes. The format of this extended EMN element is: <!ATTLIST xemn mailbox CDATA #REQUIRED timestamp CDATA #IMPLIED sequence-id CDATA #IMPLIED ;notification sequence number event CDATA #IMPLIED ;event name in [MSGEVENTS] uid CDATA #IMPLIED ;message UID sender CDATA #IMPLIED ;name of message sender datetime CDATA #IMPLIED ;date message was sent subject CDATA #IMPLIED ;subject of message > With the 'xemn' element's allowed children as Maes Expires November 2006 [Page 9]
<Lemonade Notifications and Filters> May 2006 <!ELEMENT xemn (#CDATA)> ;CDATA contains optional snippet of body of message or any text to be displayed on MUA when viewing message prior to synchronization. Extended EMN payloads should be encrypted. Example extended payload: <xemn mailbox="mailat:joe@foo.com" timestamp="2004-02-20T06:40:00Z" sender="Mike Smith <mike@foo.com>" datetime="Thu, 15 May 2006 19:51:21 -0700" sequence-id="1" uid="157" subject="Re: our meeting" > I can't make the 9:15 meeting, can we reschedule? </xemn> 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. If a MUA does not react to outband notifications, the server MAY stop sending outband notifications, except possibly periodic wake up calls until the client reconnects. 10. Provisioning and Preferences for Notification Settings It is sometimes necessary for the server to inform the client of default notification settings the first time the client is used, as well as notification capabilities of the server. It is also necessary for the client to adjust notification preferences. [ANNOTATEMORE] is used to store provisioning and preference information. The difference between a provision entry and a preference entry is that provision entries are typically read-only, global to the user, and represent capabilities, whereas preference entries are writable by the client, and per-mailbox, and represent actual settings. A client only needs to access provision information once when the device uses the Lemonade server for the first time. It MAY opt to not cache provisioning information, and re-read it on each connection, but it is not necessary. Re-provisioning MAY also be initiated manually via user action, or via out-of-band notification. Maes Expires November 2006 [Page 10]
<Lemonade Notifications and Filters> May 2006 Provision and preference data marked "private" in [ANNOTATEMORE] terminology is also inherently per-device, not per-user. Attributes marked "shared" are inherently per-user. If a user logs in as his desktop client identity, "private" preference data is separate from his mobile phone identity, rather than shared. However, "shared" preference data may be visible to all of his devices (but not other users) 10.1. Entry Names and Attributes Entry names and Attributes listed in this section SHOULD be supported by any server claiming LNOTIFICATION compliance. ABNF structure of attribute values is provided. 10.2. Provision Entries The following are server-global provision entries. /notify/outband Defines attributes related to out-of-band notification. Attribute Names = Values: "channel.priv" = "NONE" *(SP ("SMS" / "MMS" / "SIP" / "XMPP" / "UDP") = format) ;a list of supported out-of-band channels ;for the current device and their formats format = "WAKEUP" / "EXTENDED" Example: "NONE SMS=WAKEUP MMS=EXTENDED SIP=EXTENDED UDP=EXTENDED" "credential.priv" = string ;the source address or identity of the server sending the notifications, potentially with an integrity check /notify/inband Defines attributes related to in-band notifications. Attribute Names = Values: "push.shared" = event-list Maes Expires November 2006 [Page 11]
<Lemonade Notifications and Filters> May 2006 ;a space separated list of push event names supported for in-band push. TBD in Lemonade events / notification work. /notify/security Defines attributes related to negotiable security parameters for securing out of band event notification and proxied deployment models. TBD. 10.3. Preference Entries The following are per-mailbox per-device preference entries. /notify/outband Defines attributes related to chosen preference for out-of-band notification. Attribute Names=Values: "channel.priv" = "NONE" / "SMS=" format / "MMS=" format / "SIP=" format / "XMPP=" format / "UDP=" format ;for a device capable of multiple mechanisms, ;set this attribute to the desired mechanism format = "WAKEUP" / "EXTENDED" "address.priv" = string ;the phone number, email address, or ;destination endpoint for notifications ;if different from server known device default ;(e.g. device phone number, or device IP ; address on well known open port, etc) "limit.priv" = "size=" nz-number | "total=" nz-number ;the maximum number of bytes to send in ;notification payloads or the total number ;of messages to send. Both per-day /notify/inband Defines attributes related to inband push events. Maes Expires November 2006 [Page 12]
<Lemonade Notifications and Filters> May 2006 Attribute Names=Values: "msgformat.priv" = fetch-att ;RFC3501 fetch-att syntax detailing the format ;of unsolicited FETCH responses generated in-band ;for new message arrivals "push.priv" = "push" / "pull" ;specifies whether the client expects ;new messages to be pushed via the unsolicited ;FETCH response defined above, or via client ;issued FETCH in response to an EXISTS response. /notify/event Defines attributes related to event / notification filtering. "filter.priv" = "ALL" / "NEW" / "NONE" ;specifies whether no events are pushed ;NEW message events are pushed, or ALL ;events are pushed 10.4. Getting and setting preference and provisioning annotations To fetch a provision, a client should generate a GETANNOTATE command with no mailbox specified according to [ANNOTATEMORE] Example: Discover all provision parameters C: a GETANNOTATION "" /notify/* (channel credential push) S: * ANNOTATION "" /notify/outband (channel.priv "SMS=WAKEUP NONE" credential.priv "55555" push.shared "new expunged") S: a OK GETANNOTATION complete Example: Set out-of-band mechanism to "MMS" with EMN extended support C: a SETANNOTATION "INBOX" /notify/outband (channel.priv "MMS=EXTENDED") S: a OK SETANNOTATION complete 11. Changing filters from the client VFOLDER also provides ways to update VF. Maes Expires November 2006 [Page 13]
<Lemonade Notifications and Filters> May 2006 NF Filter remote management mechanisms MAY rely on [MANAGESIEVE] 12. 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). OMA provides enablers to support outband notifications: the outband notification mechanisms. Also, OMA XDM may be considered also for outband filter changes. 13. Server to server notifications considerations The following sections focus on considerations and usage of the Lemonade notifications for server to server notifications With server to server notifications, a messaging system (e.g. email server, voice mail system, etc.) submits alerts, which describe potential notification events, regarding an end user mailbox status change (e.g. new message has arrived, mailbox is full, etc.). These alerts are sent to a notification mechanisms, which may, in turn, generate an end user alert notification. Server to server notifications facilitate a solution where the messaging system initiates an end user notification, while allowing the messaging system, not to be familiar with the end user's notification preferences. The notification mechanisms are the entities which is familiar with the end user's notification preferences. Using server to server notifications, allow the messaging system to provide the end user, a unified notification experience (the same look and feel for all messaging systems' accounts), while allowing smooth integration of additional Messaging systems. 13.1. Scope of server to server notifications The suite of Internet mail protocols (POP3, IMAP4) allows different mail clients to access and manipulate electronic mail messages on a messaging system. These protocols, however, do not provide off-line methods by which an end user can be notified upon changes in the mailbox status. Further, none of the mentioned protocols defines a way to aggregate the status within the end user's various mailboxes. Maes Expires November 2006 [Page 14]
<Lemonade Notifications and Filters> May 2006 To provide an end user with the ability of unified Notification and one centralized message-waiting indication (MWI), notification mechanisms are required to aggregate the information of all the events occurring on the end user's different messaging systems. With server to server notifications, a messaging system notifies the notification mechanisms regarding events occurring in an end user's mailbox. It is important to emphasize, that server to server notifications do not deal with the communications between the notification mechanisms and the end user devices (SMS, WAP Push, MWI, etc.). For example, when an email message is deposited in an email server, the email server sends a "new message" notification to the notification service, which then notifies the end user by a Short Text Message (SMS). This process can be extended to include other mailbox events that are important to the end user, such as "mailbox full" and "message rejected" or any other mailbox status change. Each notification should include additional information that is available to the end user such as the mailbox status, message attributes, etc. The figure 3 depicts the server to server notification scope: Maes Expires November 2006 [Page 15]
<Lemonade Notifications and Filters> May 2006 +--------+ +--------+ New | | | SMS | Message | Email | \ |Gateway | -------> |Server 1| \ _ | | +--------+ \ /| +--------+ ^ \ / | \ / ^ | \ +--------------+ / | +--------+ +--------+ | _|+-------------|+ / | | MWI | Read | Voice | | || |/ | |Gateway | Message | Mail |-------->| Notification |------->| | -------> | Server | | ^ _ +| Mechanisms |\ ^ | +--------+ +--------+ | | /| +--------------- \ | | | |/ \ \| | | / ^ \ ^ \ | |/| | \ | |\| +--------+ / | | \ | | \ +--------+ Mailbox | | /| | | \| | |\ | Wap | Full | Email |/ | | | ^ \ | |_|| Push | -------> |Server 2| | | | | |\| | |Gateway | +--------+ | | | | | \ | +--------+ | | | | | |\| | | | | | | \ | | | | | | |\ | | | | | | |_|+--------+ | | | | | | | | IM | | | | | | | | |Gateway | | | | | | | | | | | | | | | | | +--------+ | | | | | | | Server to OTHER Server PROTOCOLS Notifications Figure 3: Scope of server to server notifications Maes Expires November 2006 [Page 16]
<Lemonade Notifications and Filters> May 2006 13.2. Basic Operation The messaging system notifies the notification mechanisms (which in turn MAY notify an end user) about events that occurred in the end user's mailbox. Each such notification, referring to a single mailbox event is referred to as a notification request. The notification request SHOULD contain data regarding the mailbox event which has occurred. It's RECOMMENDED that the request would not contain data regarding the end user notification destinations. This would be left to the notification mechanisms implementation. If such data has been received the notification mechanisms MAY ignore it. 13.3. Server to server terminology This specification uses the following terms: - Message Waiting Indication (MWI) A mechanism that indicates to the end user that a message is waiting in a Messaging System Examples for such action are: SMS message, WAP push message, Instant messaging notification, telephony stutter tone, etc. MWI states may be ON or OFF. - Notification Event An event that may result in a notification to the end user or may change the MWI state (ON or OFF) - Messaging System - A system that maintains a set of one or more mailboxes for end user's messages, for example: email servers, voicemail systems, etc. - Notification Mechanisms - A system, which aggregates all notification events from multiple Messaging systems to multiple end user destinations. 13.4. Notification payloads The cases of Figure 1 and Figure 3 are very similar. In both cases a message must be generated by the message store as result of a message event. This message is communicated to the messaging mechanisms. Within the context of Lemonade profile (Figure 1), the event is filtered by NF and the payload of the notification is defined in section 8. In more generic cases, the server to server notification payload can be any message. Certain may be defined to: Maes Expires November 2006 [Page 17]
<Lemonade Notifications and Filters> May 2006 - Realize the messaging mecanisms task which has caused the notification event. The task may be related to one of the following: - New message Task - New Message Deposit - Mailbox Manipulation Task (e.g. Login, Logout, etc.) -Login to mailbox -Logout from mailbox -Read message -Delete Message -Purge Message - Management Task (e.g. Mailbox Full) - Mailbox full - Mailbox full cancellation The task's types list, as defined above, SHOULD be extendable. - Provide a rich experience to the end user of the notification, without the need to actually retrieve the message. This MAY include mailbox status, message attributes, etc. - Practice different MWI behaviors (e.g. turn MWI indication off after all the messages in all the end user's mailboxes have been read). - URL, as defined in [RFC-URL] or [URLAUTH], referring to the message which has caused the event, to the notification mecanisms (and eventually, to the end user). 13.5. Server to server notification protocol details Within the more general case of server to server notification, the payload may be an arbitrary text or binary message. In both cases the interaction model is defined as: 1) An event takes place in the message store 2) The event is filtered. As a result it may be hidden or result into a notification. 3) The notification is a message in a particular payload that is prepared for the target notification mechanisms. 4) The payload is complemented with the necessary information to tell the notification mechanism how and where to send the notification. 5) The complemented payload is then formatted as required by the target notification mechanisms (i.e. the right format on the right port to be sent to the right address, possibly with an appropriate protocol binding e.g. HTTP PUT) plus the information about where / how to send the notification. This last step is imposed by the notification mechanisms and must be known by the notification generating filter. Different interfaces and bindings may be used depending on the notification channel. Maes Expires November 2006 [Page 18]
<Lemonade Notifications and Filters> May 2006 13.5.1. Exception Handling It is assumed that the interface exposed by the notification mechanisms can notify the messaging system about the outcome of the notification request (notification status message). The notification mechanisms SHOULD notify the messaging system whenever a problem has occurred. If the request has failed, the response, when available, SHOULD be coherent enough to allow the messaging system to determine the cause of the failure. The notification mechanisms SHOULD make a distinction between events in which the content of the request has caused an error (request errors), and cases in which a non-source-related reason has caused the error. The Messaging system SHOULD parse the notification status message, when available, to decide its next actions (e.g. clear the messageËs content, recompile the message data, etc.). 13.6. Server to server complementary information The server to server complementary information MUST include: - Identify the end user whose inbox has generated the notification. - Identify the end user or end target addresses or identifiers that should be informed about the notification event (not necessarily the same as the previous end user). - Decide what kind of actions, the notification mechanisms should perform, due to the notification request. 13.7. Event orders For lemonade profile bis, the event order is not important. For generic server to server notifications, the order may matter and the messaging system must provide the notifications in the order that they are generated by mailbox events. 13.8. Reliability For Lemonade profile bis, lost or delayed notifications of the MUA are not critical. A client can recover all missing events next time it connects to the server and the server MUST buffer the notifications and make them available to the MUA when it comes back to the server. Maes Expires November 2006 [Page 19]
<Lemonade Notifications and Filters> May 2006 For generic server to server notifications, it is assumed that the data in a notification request is important, and therefore a high level of reliability is needed. In such cases it MUST be possible to provide acknowledgment by the target to the messaging system or to repeat notification until such an acknowledgement is provided if supported by the notification channel. Alternatively it must be possible for the messaging system to request such repeats. Security Considerations Notifications must be secured (when useful information is sent) and integrity should be checkable. It should be possible to 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). [CLEARIDLE] M. Wener, "IMAP Extension for CLEARIDLE", draft-wener- lemonade-clearidle-02.txt, February 2005 [GSM03.40] GSM 03.40 v7.4.0 Digital cellular telecommunications system (Phase 2+); Technical realization of the Short Message Service (SMS). ETSI 2000 [IMAP-DISC] Melnikov, A. "Synchronization operations for disconnected IMAP4 clients", draft-melnikov-imap-disc-06.txt, October 2004. [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). Maes Expires November 2006 [Page 20]
<Lemonade Notifications and Filters> May 2006 [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). [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/ [RECONNECT] A. Melnikov, C. Wilson, "IMAP4 Extensions for Quick Reconnect", draft-ietf-lemonade-reconnect-06.txt, May 2006 [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) [URLAUTH] Crispin, M. and Newman, C., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", draft-ietf-lemonade-urlauth- 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). Maes Expires November 2006 [Page 21]
<Lemonade Notifications and Filters> May 2006 [WAPWDP] Wireless Datagram Protocol, Version 14-Jun-2001, Wireless Application Protocol WAP-259-WDP- 20010614-aWAP (WDP) 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. 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 - Create new MSGEVENTS draft to define mandatory event support, including new OMA required events like client LOCK_DOWN, or request the client to re-provision (including encryption keys) [2] Map MSGEVENTS to mandatory IDLE responses Maes Expires November 2006 [Page 22]
<Lemonade Notifications and Filters> May 2006 [3] Determine whether CHECKPOINT style inband event queuing is needed when client is disconnected, or whether [RECONNECT] suffices (e.g. we may need a lemonade idle event draft) [4] Possibly update MSGEVENTS, keeping what is necessary, and adding new ones like LOCKDOWN (e.g. we may need a lemonade event draft starting from [MSGEVENTS]). [5] Review and sanitize introduction of server to server notification and possibly better integrate with structure of the text. Version History Release 02 - LPROVISION/LGETPREFS/LSETPREFS removed in favor of mailbox annotations - Updated inband notification section to include discussion of [CLEARIDLE] and [MSGEVENTS] - EMN payload clarified for both wakeup and extended formats. - Some reference clean-up - Add server to server notifications based on the expired draft draft-ietf-lemonade-notify-s2s-00. 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 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, including the original work on P-IMAP. The authors want to thank the authors of the original work on Server To Server Notification Protocol Requirements (draft-ietf-lemonade- notify-s2s-00) whose material has been incorporated in the present document, in particular: Gev Decktor. Authors Addresses Stephane H. Maes Oracle Corporation 500 Oracle Parkway M/S 4op634 Maes Expires November 2006 [Page 23]
<Lemonade Notifications and Filters> May 2006 Redwood Shores, CA 94065 USA Phone: +1-650-607-6296 Email: stephane.maes@oracle.com Ray Cromwell Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA 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. Copyright Statement Maes Expires November 2006 [Page 24]
<Lemonade Notifications and Filters> May 2006 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 November 2006 [Page 25]
