From: http://www.ietf.org/internet-drafts/draft-dusseault-email-notif-model-00.txt Title: Email System Event Notification Model Reference: Internet Engineering Task Force (IETF) Internet Draft 'draft-dusseault-email-notif-model-00' Date: June 2007 I-D Tracker: http://ietfreport.isoc.org/idref/draft-dusseault-email-notif-model/ ============================================================================== Internet Engineering Task Force L. Dusseault Internet-Draft CommerceNet Intended status: Informational Jun 2007 Expires: November 2, 2007 Email System Event Notification Model draft-dusseault-email-notif-model-00 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 2, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Email servers have event information which is of interest to a wide variety of clients, devices and users, and this motivates an effort to tie Email servers into the existing Internet notifications architecture as described by the Common Profile for Presence (CPP). This document describes where Email servers fit into CPP and what pieces are missing. This is not purely a requirements document because it describes a specific architecture, but it makes some requirements on future documents that fill in pieces of the Dusseault Expires November 2, 2007 [Page 1] Internet-Draft Abbreviated Title May 2007 architecture. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Architecture and Terminology . . . . . . . . . . . . . . . . . 4 2.1. Basic Architecture . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 3. Addressing, Location, Capabilities . . . . . . . . . . . . . . 8 3.1. Server Addresses and Capabilities . . . . . . . . . . . . 8 3.2. Resource addressing . . . . . . . . . . . . . . . . . . . 9 3.3. Hop-by-hop authentication . . . . . . . . . . . . . . . . 9 3.4. Mail Store Information Access Control . . . . . . . . . . 10 3.5. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11 3.6. Reliability . . . . . . . . . . . . . . . . . . . . . . . 11 3.7. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. SIP Functionality . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Authenticating SIP clients to PNAs . . . . . . . . . . . . 13 5. XMPP Functionality . . . . . . . . . . . . . . . . . . . . . . 13 5.1. XMPP Addressing . . . . . . . . . . . . . . . . . . . . . 13 5.2. Authenticating to PNA . . . . . . . . . . . . . . . . . . 14 6. SIEVE and Unsolicited Notifications . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Dusseault Expires November 2, 2007 [Page 2] Internet-Draft Abbreviated Title May 2007 1. Introduction An Email server can be an IMAP server RFC 3501 [RFC3501] or a POP server RFC 1939 [RFC1939]. It could also be a Webmail server, offering email access through a presentation layer delivered over HTTP RFC 2616 [RFC2616] -- or might support other online interfaces. Although the semantic and storage models differ, these servers are sufficiently similar to be considered together for the purposes of describing interesting events originating from email message stores and how to get access to such event streams. Typically, these servers are capable of storing up to gigabytes of messages per user, handling hundreds of incoming messages per user per day, and allow clients to track which messages have been handled (typically 'seen' or 'read') and which ones are new. Work to describe a event model for mail stores has already progressed in the LEMONADE Working Group [I-D.ietf-lemonade-msgevent]. The Introduction of that draft also describes some of the demand for interoperability for producing, consuming and interpreting these events. Meanwhile, the SIEVE Working Group is working on an extension to the SIEVE email filtering language RFC 3028 [RFC3028] that allows a notification to be sent in the case of a SIEVE rule match [I-D.ietf-sieve-notify]. One way to deliver events to existing email clients is to use IMAP for in-band notifications; the Lemonade WG is working on a NOTIFY capability to provide more such functionality. This document instead focuses on out-of-band notifications. Outside of the email standards groups, two Internet event notification delivery systems have been standardized and deployed. These systems are based on SIP [RFC3261] and XMPP [RFC3920], and each was initially designed and deployed primarily as a PRESENCE SERVICE (section 2.1 of RFC 2778 [RFC2778]). Interoperability between these two systems is defined and described by the Common Profile for Presence (CPP) model RFC 3859 [RFC3859]. Both systems are architected to scale efficiently and to handle cross-domain authentication issues. Salient differences between these two systems will be described in sections [REF-TODO]. Only a few other pieces are required to encourage interoperability between vendors' products: o The abstract message event model (a chartered work item of the LEMONADE Working Group -- [I-D.ietf-lemonade-msgevent]). o A SIP Event Package mapping the event model for use in SIP Event Notifications RFC 3265 [RFC3265]. Dusseault Expires November 2, 2007 [Page 3] Internet-Draft Abbreviated Title May 2007 o A mapping of the event model for use in XMPP PubSub [xmpp-pubsub] o A standard way for email servers to deliver large streams of events into the notification system o An explanation of how clients can subscribe to certain more limited streams of events via the notification system, including how to know what server addresses and resource names to subscribe to and how to discover the capabilities of email servers and aggregators. 1.1. Requirements Language 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 RFC 2119 [RFC2119]. 2. Architecture and Terminology 2.1. Basic Architecture All the components of the desired email event infrastructure already exist (though not all the interconnections are standardized). This section describes the components. This architecture ignores the existence of SIEVE and SIEVE-generated events until section 6, as these are necessarily unsolicited notification rather than pub-sub notifications. Dusseault Expires November 2, 2007 [Page 4] Internet-Draft Abbreviated Title May 2007 +---------------+ push +----------------+ sub +--------+ | Email Server |=========>| Publisher |<------| Local | | (msg store) | raw | Notifications | | Client | |_______________| events | Aggregator |------>|________| | |________________| pub | ^ | | ----------------------|----|------------- domain bndy | subscribe | | publish | | v | +----------------+ | | Consumer | | | Notifications | | | Aggregator | | |________________| | ^ | | ----------------------|----|------------- domain bndy | subscribe | | publish | | v | +--------+ |-----------------------| Client | email access |________| (optional) The Email server or message store, which has plenty of other work to do besides worry about notification delivery, can be configured to send a stream of all events to a local "publisher notifications aggregator" (PNA). This aggregator may support XMPP, SIP or both, and certainly supports publish and subscribe functionality. Some local clients may be able to send subscribe requests directly to the publishing notifications aggregator, but in many cases clients will authenticate to a "consumer notifications aggregator" (CNA) and the CNA will forward the subscription request to the PNA and act as a proxy for notifications. The email server and PNA are in the same administrative domain. This makes much of the architecture simpler, and is likely to be the most common case anyway. Even if not all use cases can be handled with this limitation, the feasibility of the architecture thus far can be proven in practice before adding the complexity to allow different administrative domains for email server and PNA. This architecture requires a subscription request before any notifications are sent to the client. The biggest benefit here is that the subscription request is an implicit authorization, along each step of the publish-subscribe chain, for notifications to be sent later. The subscription request also provides potential for clients to customize what information is received. Dusseault Expires November 2, 2007 [Page 5] Internet-Draft Abbreviated Title May 2007 The Message Event schema [I-D.ietf-lemonade-msgevent] describes events relating to creating and editing messages, receiving messages, deleting, expiring or expunging messages, and creating, deleting and renaming mailboxes. Consider the following assumptions around the processing and bandwidth demands of events, compared to the existing demands of running a modern mail server: o For ordinary user mailboxes, we can ignore the overhead of events relating to editing and sending messages originating from the user, and consider only incoming messages (a couple of orders of magnitude more messages typically). o Quota-related, login/logout and mailbox creation events are sparse compared to incoming message events. o Notifications never carry a significant proportion of an email body. o Notifications require no extra processing of the email body beyond what email servers already do. (This doesn't prevent event information that results from processing the server does already -- e.g. a server might perform spam filtering and only generate events on new non-spam messages). Thus, we consider the length of incoming emails irrelevent to a back-of-the-envelope processing requirements calculation. o Reading and listing activities generate no event notifications (e.g. clients downloading emails, requesting mailbox listings, searches), except for the case of changing the "read" flag which typically happens once. o Each new email received by a message store for a given user generates only a handful of events (e.g. new message, message read, message expired, message expunged). That's because the typical lifecycle of an email is that it arrives, is handled, and archived or deleted once -- most emails do not go through long cycles of flag changes or other state changes. Thus, if N is the average number of emails that arrive for a given user, the number of events per user is likely to be x*N, where x is under 10, or in other words O(N) (order N). The number of notification messages sent may ultimately be greater because there may be several clients subscribed to a given event, but the estimate of O(N) still holds for the number of events that the email server must send to the PNA for potential fan-out even when notification services become very popular. Dusseault Expires November 2, 2007 [Page 6] Internet-Draft Abbreviated Title May 2007 Note that the PNA is responsible for maintaining subscriptions. The mail server sends each event once to the PNA whether there are many subscriptions for that event, just one, or zero. Each event is unaddressed, but naturally must contain enough information for the PNA to match it to the list of subscriptions. Matching events to subscriptions should be trivial if event types are named consistently, and if the resource that generated the event can be matched against either targeted or hierarchical subscriptions (e.g. through path prefix matching). The most difficult requirement here for the PNA will be to determine whether the subscription request ought succeed in the first place or be rejected due to privilege failure. It should be possible to accomodate multiple notification transports with this architecture, namely both SIP and XMPP. Clients should be able to choose which to implement. Notification servers might have to support both. The email server should implement only one transport which might be neither SIP nor XMPP. The protocol used by the mail store to send events to the PNA could be a proprietary protocol configured by the administrator of both servers. It could be a new standard TBD. The PNA could act as an IMAP client using the NOTIFY capability if the mail store supports IMAP. This architecture, together with the assumptions just stated, should ensure that the new work required for email servers to send event streams can be minimal. Essentially, the email server implementation needs to send all supported events (or limit to those types chosen by the server administrators) straight to the PNA. This delegates filtering, fanout and authorization to the PNA, where such functions already exist and can be used or adapted for email notification use cases. This architecture gives clients choice and the ability to use existing libraries. Finally, this architecture puts the demands for reliability and scale in the spots where they can be addressed most easily and with existing code -- in the existing CPP server infrastructure. 2.2. Terminology Email Server - A message store capable of receiving and storing messages for users, along with the ability to distinguish between new messages and handled messages. Mailbox - A container for Internet messages and/or child mailboxes. Dusseault Expires November 2, 2007 [Page 7] Internet-Draft Abbreviated Title May 2007 A mailbox may or may not permit delivery of new messages via a mail delivery agent. When the word "mailbox" is used in this document it might mean the top-level folder corresponding to a user's mail account, or any other within the hierarchy -- unless qualified, it could mean any kind or level of mailbox. Notifications Aggregator - Any CPP "presence service", plus support for generalized publish and subscribe functionality. Subscription - In the "PubSub" model, a client does not receive event notifications without an explicit active subscription. Subscription Request - The message (possibly relayed) in which a client requests a subscription to an event stream. 3. Addressing, Location, Capabilities This section provides an overview of how clients consuming email event streams can locate the sources of those event streams. As this is a model document this provides only a framework; implementation requirements will be stated in one or more separate documents. 3.1. Server Addresses and Capabilities We assume that an email event consumer knows the address of the email server that may or may not generate the events it's interested in. The email event consumer may be an IMAP or POP3 client already configured with the email server address, or it could be a separate device or piece of software. If it's a separate agent, we assume that the user knows the email server address and can configure that into the client. It's probably not reasonable to expect users to know the address of the PNA, however, so we need to provide some ways of getting from the email server address to the address a client can subscribe to. IMAP has a capabilities feature. If the IMAP server is configured to send events to a PNA, this should be advertised with a new capability. It's even possible to include a server address in a capability advertisement, so the IMAP server could advertise a PNA address at the same time as the capability itself. E.g. the CAPABILITY response could include "NOTIF=sip.example.com". POP3 feature advertisement will be done via the POP3 extension mechanism in [RFC2449]. If the client does not find the PNA with one of the above approaches, or is not an IMAP or POP3 client, the next step to try should be Dusseault Expires November 2, 2007 [Page 8] Internet-Draft Abbreviated Title May 2007 querying SRV records. The site hosting an email server with event streams can set up a well-known SRV record type. This could reveal the existence of a SIP server, an XMPP server or ideally both. Sites offering email event streams should support both SIP and XMPP in order to interoperate with a variety of clients. Further information on addressing can be found in the sections on SIP and XMPP. 3.2. Resource addressing Once the client has identified which server to make its subscribe request to, the client must specify which mailbox it is interested in. The most common case expected is that the client is interested in new message events for a top-level mailbox (if that's where most mail arrives) or for the special-case INBOX mailbox, followed by interest in message read counts for any mailbox. Thus, the client has to indicate to the PNA what mailbox the user is interested in -- the PNA can't assume that it can map the notification clients authentication identifier to an obvious mailbox name. For example, the XMPP user authenticated as 'xmpp://ldusseault@example.org' may wish to subscribe to the entire IMAP mailbox for 'lisadu@example.com' or to the INBOX mailbox alone or to some other mailbox. Subscription requests will have to indicate whether the subscription covers only a single mailbox, or also the mailboxes contained in the subscribed mailbox. Alternately, it would simplify the architecture if it were possible to provide just one option for hierarchical handling, but it's not yet clear which option, if any, meets most common use cases. In some cases, users will have to provide mailbox names when subscribing. For example, to configure a message waiting indicator status bar applet for a laptop, the user will have to provide not only the mail server address but also the user login for the email server, password and mailbox name unless that is assumed to be the same as the user login. A complete resource addressing solution is dependent on the addressing model of the notification transport, so this is considered further in the sections on SIP and XMPP. 3.3. Hop-by-hop authentication The link between the message store and the PNA does not require authentication of either the message store or the PNA. Generally a notifications server will not accept large streams of events from random sources anyway, instead an email provider (ISP or employer or Dusseault Expires November 2, 2007 [Page 9] Internet-Draft Abbreviated Title May 2007 other) will link together small numbers of known email servers to known notifications servers. Assuming this configuring relationship simplifies the event push solution and eliminates some questions of possible denial of service attacks. Note that even though its not required to authenticate the email server to the PNA or vice versa, a solution which does so may be easy and have useful side effects. For example, the email server could act as a client to the PNA and use existing SIP or XMPP authentication and certificate checking. The link between the PNA and CNA is authenticated both ways using existing SIP and XMPP mechanisms, and this authentication determines whether the PNA trusts that the CNA is the correct place to send notifications, and whether the CNA allows the PNA to send a stream of events. The link between the CNA and client is authenticated both ways using existing SIP and XMPP mechanisms. This determines whether the client accepts incoming messages from the CNA and trusts that the CNA has done its own authentication of PNAs further upstream. It also determines whether the CNA is willing to vouch for the client's chosen authentication identity, in the case where authentication from the client to other servers further upstream is not directly possible. 3.4. Mail Store Information Access Control In order to get access to event streams from private mail stores, the client consuming the event stream must be able to authenticate to the PNA, either as the mailbox owner or as a notifications node authorized to receive these events. The architecture described here does not necessarily involve querying the email server to authorize a subscription request because the email server will always send all published events to the PNA, thus the PNA must be capable of authorizing subscriptions. (An exception to this statement is if non-standardized mechanisms are used for communicating between PNA and the email server, but for purposes of this framework which doesn't have such a mechanism, that's considered to be equivalent to the PNA authorizing the subscription.) A PNA might be able to query an IMAP server using the IMAP ACL standard [RFC4314] to see what users have read permissions on various mailboxes, and use that to decide to authorize subscriptions. Alternately, the PNA might be configured by the administrator to know (without consulting an email server) which subscriptions to allow. Since the PNA has to be in the same domain as the email server, the choice of how the PNA authorizes subscriptions once it knows the subscriber identity can be left to implementors and administrators. Dusseault Expires November 2, 2007 [Page 10] Internet-Draft Abbreviated Title May 2007 See the section on SIP for a method of authenticating clients to the PNA. 3.5. Confidentiality It is likely that end-to-end confidentiality is NOT a requirement for email notifications to be useful. As a comparison, end-to-end confidentiality tends not to be used in instant message systems even where the full contents of messages are involved. In this case, where notifications are not required to have any message content, end-to-end confidentiality is therefore even less important. Hop-by- hop confidentiality will be required, however. 3.6. Reliability Certainly clients need some reliable information out of event streams, however this is not the same thing as requiring a fully reliably event notification transport. The most common reliability requirement is for a "message waiting" indicator to be accurate in a reasonably timely manner. To state the opposite case, it would be a bad thing if a user saw that there were no messages when in fact a message had been waiting for some time, or if a user saw that there were messages waiting when in fact all the new messages had already been handled. To a lesser extent, the number of new or unread messages must also be reasonably accurate although of course it's less important to know if there are 299 or 300 unread messages than if there are 0 or 1. This architecture offers a case where it's easier to get reasonably reliable knowledge out of an unreliable transport than it is to build a reliable transport. In other words, we should be able to design a way to know whether there are messages waiting even if some events are dropped. Some design options: Include total counts in events -- rather than simply deliver "new message" events, deliver "new messages = 299" events. Provide heartbeat subscriptions from PNA that repeat message counts -- a client can know if it is not receiving heartbeats that its information may be out-of-date Allow out-of-band verification (via IMAP and POP3 for starters) There are some kinds of notifications that do not require reliability at all. These are hints to the client that reduce the latency of actions that are going to be taken at some later point anyway. Rather than attempt to discriminate between events that require and Dusseault Expires November 2, 2007 [Page 11] Internet-Draft Abbreviated Title May 2007 do not require reliability, we assume that fully reliable event delivery may be addressed later, and in the meantime event delivery at the level of reliability provided by existing XMPP and SIP systems will be adequate for many interesting uses. It should however be noted that many SIP and XMPP systems do indeed provide high reliability at least across the servers, some offering "five nines" uptime and no single point of failure. Client libraries and existing CPP clients may or may not take full advantage of high reliability depending on need. 3.7. Spam Spam is mostly out of scope for consideration in notification architecture. When spam is filtered into particular mailboxes, mailbox subscriptions can allow the user to choose whether to receive notifications of spam or not. Although the email server implementor might be tempted to omit spam messages in message events to PNAs, it should be noted this would be a very trivial performance improvement for the email server -- the cost of sending these event notifications is insignificant compared to the cost of spam detection. There may be a use case for PNAs to interoperably detect when an email is thought to be spam (e.g. a standardized indicator in the event data ) besides relying on what mailbox it's filed into. 4. SIP Functionality SIP exchanges messages over sessions between endpoints that have SIP URIs. It's common for users to have local proxies where those URIs are resolved to account information. Thus, the user's local SIP proxy acts as the consumer notifications aggregator. Similarly, an email server can have a SIP address provided by its local SIP proxy server. In addition, SIP allows for a variable number of additional SIP proxies that can be ignored for the purpose of defining email event services over SIP, but may be transparently used in practice. The work to map email server events to SIP will include specifying a SIP event package. A SIP event package defines an "Event" header value which is the package name, and can also define a body. For email event notifications, clients must be able to specify in one SUBSCRIBE the email server, mailbox identifier and which email event(s) are desired. Because the Event header and SIP address are not intended to carry quite that much information, it might be necessary to define a SUBSCRIBE body for email events. Dusseault Expires November 2, 2007 [Page 12] Internet-Draft Abbreviated Title May 2007 4.1. Authenticating SIP clients to PNAs A feature of SIP that is quite useful for this problem is its support for authenticating a single client to multiple servers in one session. For example, a client attempting to subscribe to a private event stream first authenticates to its proxy server (the CNA) to establish its authorization to be represented by a particular address, then authenticates via the CNA to the PNA to establish its authorization to access information from the email store. For further details, see section 22.3 of RFC 3261 [RFC3261]. Once the PNA has authenticated the user, it still needs to find out whether the user is authorized to get those kinds of events from the mail server. We may need to define how IMAP ACLs can govern access to event streams, and further, how the PNA can know these ACL settings. 5. XMPP Functionality Although the core XMPP mechanisms are defined in IETF RFCs, important XMPP extensions are also defined through the XMPP Standards Foundation (xmpp.org), including pub-sub features. 5.1. XMPP Addressing In the XMPP model, clients need to know a JID (Jabber Identifier) in order to address a subscription. A JID consists abstractly of a node name and a domain. JIDs most typically have a user identifier as the node name, so in the case of a user logging in as "juliet" and a domain "example.com", one would typically have a presence and instant messaging address of "juliet@example.com". Once a JID is known, the client can discover pubsub features and browse various pubsub nodes using the Service Discovery features [xmpp-disco]. This is useful for email events, because it means Service Discovery can be used to discover the exact identifier to use to subscribe to any mailbox, if mailboxes are mapped to nodes. In order for Service Discovery to allow discovery of mailbox addresses, the PNA must support XMPP and Service Discovery and be able to map mailboxes onto pubsub nodes. This may require either a way for the PNA to query what mailboxes exist on the IMAP server, or a way for it to build a list of mailboxes by seeing them used in notifications. Having the email server support the MailboxCreate and MailboxRename event types would allow the PNA to quickly learn about new mailboxes and allow browsing via XMPP Service Discovery. Once the client browses to discover what resources exist, it naturally Dusseault Expires November 2, 2007 [Page 13] Internet-Draft Abbreviated Title May 2007 also has the correct addresses for those resources. For example, the site "example.com" could advertise the "mail_events" node under the the "juliet@example.com" JID (and all other email user JIDs). The subscribe address for events relating to the entire mailbox hierarchy would be "juliet@example.com/mail_events". Underneath that, the address for events relating to the Inbox of juliet's mailbox might be "juliet@example.com/mail_events/Inbox/". (Note that IMAP mailbox separators characters can vary -- one server might use '/' and another '.' -- but since the mailboxes are mapped to XMPP nodes, the separator for nodes in XMPP addresses is always '/'.) The next step is to identify what types of events the subscriber is interested in. XMPP pubsub supports subscription options. There's also a form-based mechanism for presenting the user directly with the subscription options, but for a well-defined domain like this one, it's probably better to bypass the options form and directly specify one of a well-known list of event-types in a well-known option. In the case that the user's identifier is not an appropriate base address for email event subscriptions, it should instead be possible for the server to advertise subscriptions at "juliet+mail_events@example.com" or some other opaque node identifier. This is harder to discover, however, so the address based on the user's account name and supporting Service Discovery is preferred. 5.2. Authenticating to PNA In the XMPP model, an authorization identity is derived from authentication and asserted by the authenticating server. Thus, juliet@example.com is authenticated by the XMPP server at example.com, and that server asserts the user's identity for use by other servers. If romeo@example.net has allowed instant messages from juliet@example.com, then the example.net server verifies that the example.com server has a certificate for the domain it asserts names in, and trusts all identifier assertions for that domain. This works great for asserting JIDs but it doesn't help us determine whether the JID xmpp://juliet@example.com is authorized to see events relating to the mailbox for juliet.capulet@example.org. For that to work, we need some way of granting email event access permissions to JIDs or a mechanism similar to SIP's for asking for additional authentication to a remote realm (the email server's realm). Further work here is TODO. Dusseault Expires November 2, 2007 [Page 14] Internet-Draft Abbreviated Title May 2007 6. SIEVE and Unsolicited Notifications Unsolicited notifications to end-user agents can be generated by an email server configured to do so, either by SIEVE or some non- standard mechanism, and be sent via SIP, XMPP, SMS or some other transport. Unsolicited notifications are more like instant messages than like presence notifications, in that no subscription request travelled the reverse path first. Because there's no subscription, there's no guarantee that the recipient will be able to understand any given event schema. Thus, unsolicited notifications are more likely to be consumed by a human user and contain human-readable text. For example, a SIEVE script could be created to send a notification saying "Urgent Message arrived" to xmpp://juliet@example.com on receipt of an email from Romeo, and this would (if permitted delivery) likely appear in Juliet's instant messaging client. Strictly speaking unsolicited notifications are no longer part of the CPP model but instead follow the Common Profile for Instant Messaging [RFC3860] model. Some of these notifications would traverse the same path as CPP event notifications: if an unsolicited notification is sent via XMPP or SIP it would still travel from the email server to PNA to CNA to client). +---------------+ target +----------------+ +--------+ | Email Server |--------->| Publisher | | Local | | (msg store) | event | Notifications |------>| Client | |_______________| msg | Aggregator | event |________| ^ |________________| msg | | | ---------------------------|------------- domain bndy | | event msg | v | +----------------+ | | Consumer | | | Notifications | | | Aggregator | | |________________| | | | ---------------------------|------------- domain bndy | | event msg | v | +--------+ |------------------------| Client | SIEVE script creation |________| Dusseault Expires November 2, 2007 [Page 15] Internet-Draft Abbreviated Title May 2007 Without subscribe and unsubscribe requests, there are a few drawbacks depending on use case: o Delivery permission is harder for the receiving client to control o it's not clear what will happen to messages received while the client is disconnected (e.g. should the CNA store the message? Should it reject the message, and if so, should the PNA stop sending such messages or continue to do so?). o Interoperability for machine-readable agents is difficult depending on the event schema The mechanism described for pubsub in section 2 -- where the email server hands events without addresses to the PNA and lets it sort out subscriptions and filters -- won't work for this type of notification. Instead, the email server would have to send targeted events to the PNA for forwarding to specific addresses. In order to get permission to send messages to an address over SIP and XMPP, the sender sometimes has to be added to a whitelist. It's possible for some SIP or XMPP clients to be configured to reject messages from unknown senders. For example, the client could be configured to reject messages from any sender that didn't already have a presence subscription approved. It's beyond the scope of this framework how that can be resolved, but we point out that clients are certainly not required to set up permissions to link incoming message blocking to presence subscriptions. 7. Acknowledgements TODO 8. IANA Considerations There are no IANA considerations introduced in this document. 9. Security Considerations This document makes no implementation requirements. However, it does make rash statements about security which need to be checked. 10. References Dusseault Expires November 2, 2007 [Page 16] Internet-Draft Abbreviated Title May 2007 10.1. Normative References [I-D.ietf-lemonade-msgevent] Gellens, R. and C. Newman, "Internet Message Store Events", draft-ietf-lemonade-msgevent-02 (work in progress), May 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [I-D.daboo-imap-annotatemore] Daboo, C., "IMAP METADATA Extension", draft-daboo-imap-annotatemore-11 (work in progress), February 2007. [I-D.ietf-sieve-notify] Melnikov, A., "Sieve Extension: Notifications", draft-ietf-sieve-notify-07 (work in progress), February 2007. [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension Mechanism", RFC 2449, November 1998. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, January 2001. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. Dusseault Expires November 2, 2007 [Page 17] Internet-Draft Abbreviated Title May 2007 [RFC3859] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004. [RFC3860] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004. [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004. [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005. [xmpp-disco] Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- Andre, "XEP-0030: Service Discovery", 2007, . [xmpp-pubsub] Millard, P., Saint-Andre, P., and R. Meijer, "XEP-0060: Publish-Subscribe", 2006, . Author's Address Lisa Dusseault CommerceNet 169 University Ave. Palo Alto, CA 94301 US Phone: 1-650-279-7365 Email: ldusseault@commerce.net Dusseault Expires November 2, 2007 [Page 18] Internet-Draft Abbreviated Title May 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Dusseault Expires November 2, 2007 [Page 19]