1. P-IMAP Draft Overview (http://www.ietf.org/internet-drafts/draft-maes-lemonade-p-imap-02.txt)http://www.ietf.org/internet-drafts/draft-maes-lemonade-p-imap-02.txt Stéphane H. Maes – stephane.maes@oracle.comstephane.maes@oracle.com Oracle Corporation IETF Lemonade Face-to-Face Meeting Dallas, TX June 2004

2. PIMAP: Goals and Motivations 1.Support the mobile e-mail: 1.End-to-end secure, quasi real-time 2-way propagation of e-mail events between messaging servers and mobile devices, allowing both stores to remain synchronized 2.Mobile e-mail usage scenario 3.Bandwidth optimization Not as much overhead as a session-based SyncML approach Not so much chattiness as IMAPv4 Rev1 Leveraging compression to ensure bandwidth conservation Group commands to reduce round-trips 2.Take into account the variety of available network bearers in order to adjust the message flows accordingly 3.Extend message delivery capabilities to obviate the need for SMTP 4.Directly interfaces and interoperates with IMAPv4 Rev1 Message Store 5.Basis to support generic event-based synchronization: 1.Draft proposes sections to contain PIM events if desired

3. High Level Use Cases for Mobile E-mail An e-mail arrives at the corporate server of a mobile worker. The client on the terminal is notified of the new email without excessive delay (based on preferences) and in a secure manner. Based on the preferences of the user, the notification is made available to the user or, the client securely fetches the new e-mail or portions of it (e.g., header, few first kB, whole body without attachment or whole e-mail). The mobile user experience of delay should be comparable to desktop email. The user downloads and views attachments in ways adapted to its device. An e-mail is composed by a mobile worker. Upon selecting to send the e-mail, it is immediately securely sent from the corporate e-mail server of the user (and not another server, e.g., operator provided SMTP server). Changes performed by the mobile worker in his e-mail client (e.g., deleting an e-mail or moving it from one e-mail folder to another) are properly reflected to the user mail box in the corporate server, as prescribed by the user. While mobile, a user can set and change filtering rules that specify when a new e-mail arriving at the corporate e-mail must be reflected in the mobile client.

4. High Level Use Cases for Mobile E-mail Depending on the network / service provider available to the mobile worker (e.g., underlying network technology, roaming, cost etc…), he or she can change behaviour of the mobile e-mail and appropriately provision for : Secure notification of all or filtered new e-mails (and possibly other events) through separate messaging mechanisms (e.g. SMS, MMS, Push) followed by: Automated secure retrieval in a data session Manual secure retrieval in a data session [Secure browsing access (e.g., WAP, Web, Voice) -- out of scope of work on Mobile Profile] An always on connection with notification of all or filtered new e-mails (and possibly other events) followed by automated or manual retrieval within the same session. Same or new sessions to send e-mail [The user can synchronize his e-mail over the air as mobile e-mail, using a pass through connection with another computer (e.g., cradle, Bluetooth, IRDA …) or over a direct LAN connection -- out of scope of work on Mobile Profile]

5. High Level Requirements 1.Push e-mail experience or quasi-instantaneous synchronization between client and server e-mail: 1.Bi-directional event-based synchronization 2.Manageability of email messages and folders including attachments from the client while mobile 2.Offline usage (e.g. not limited to browser-based access which is today still often the only available model for mobile users) 3.Cost structure: 1.Manageability (e.g. to be able to adapt to manage cost by setting what email to receive, how to be notified, when to synchronize, what to do with attachments, etc…) 4.Security: 1.End-to-end between mobile client and e-mail server/proxy 2.E-mail sent from the e-mail server (e.g., corporate e-mails server) instead of other servers 3.No intermediate storage outside enterprise domains. 5.Support of intermittent connectivity inherent to mobile network 6.Content Adaptation 7.Efficient exchanges of e-mail messages between client and server to optimize mobile data costs and mobile data transfer delays 8.Support of different underlying network technologies 9.Interworking with IMAPv4 Rev1

6. PIMAP: Protocol Highlights 1.Extension commands allowing clients to: 1.Set notification mode (in-band, out-band) and device address – XSETPIMAPPREF/XGETPIMAPPREF 2.Set view and notification filters - XFILTER 3.Send out messages - XDELIVER 4.Exchange compression capabilities: Leveraging compression to ensure bandwidth conservation 5.Encryption – XENCRYPTED Payload encryption 2.Combine often-used groups of commands into macros: Group commands to reduce round-trips 3.Support for various bindings to underlying protocols, for instance: 1.PIMAP over HTTPS [Mandatory] 2.PIMAP over TCP. 3.Any other network optimizations can be used 4.Support for multiple notifications mechanisms: 1.Based on OMA-EN specifications 2.Supports 1.In-band notifications (e.g. within HTTP or TCP bindings). 2.Out-band notifications (e.g. SMS, WAP Push, …).

7. PIMAP: Flows 1. Keep-Alive HTTP binding, in-band notifications HTTPS Listener PIMAP Dispatcher IMAPv4 Rev1 Message Store Events TCP Listener PIMAP Client Events/ Commands SMS WAP Push Out-band Notifications PIMAP Messaging Server Command Processing Event Handling Event Queuing 1.Client establishes and authenticates a PIMAP session over a long-lived HTTPS request. It performs an IMAP state comparison for subscribed folders. 2.It uses this request to propagate client-originated events (send, delete, etc.) 3.Server uses long-lived response to notify of server originated events. 1.Server receives notifications from the Message Store in different ways: 1.Message Store has notification rules capabilities and can actively notify the PIMAP dispatcher 2.PIMAP dispatcher opens an IDLE session to the Message Store in behalf of the user 4.Client reacts to notifications if needed (e.g. fetches body of new message) 5.If request/response ends, server maintains session and queues events. 6.Client re-establishes HTTPS request within session lifetime and retrieves events without the need for a full state comparison. Session

8. PIMAP: Flows HTTPS Listener PIMAP Dispatcher IMAPv4 Rev1 Message Store Events TCP Listener PIMAP Client Events/ Commands SMS WAP Push Out-band Notifications PIMAP Messaging Server Command Processing Event Handling Event Queuing 1.Client establishes and authenticates a PIMAP session over a TCP connection. 2.It performs an IMAP state comparison for subscribed folders. 3.Client-originated events (send, delete, etc.) are propagated. 4.Server uses connection to notify of server originated events. 1.Server receives notifications from the Message Store in different ways: 1.Message Store has notification rules capabilities and can actively notify the PIMAP dispatcher. 2.PIMAP dispatcher opens an IDLE session to the Message Store in behalf of the user. 5.Client reacts to notifications if needed (e.g. fetches body of new message). 6.Notifications may be missed when the client suddenly drops connection. 1.In this case, the server sends a RESYNC untagged response whenever the client reconnects. Session 2. TCP binding, in-band notifications

9. PIMAP: Flows HTTPS Listener PIMAP Dispatcher IMAPv4 Rev1 Message Store Events TCP Listener PIMAP Client Commands SMS WAP Push Out-band Notifications PIMAP Messaging Server Command Processing Event Handling Event Queuing 1.Client establishes and authenticates a PIMAP session over HTTPS. 2.It performs an IMAP state comparison for subscribed folders. 3.Client-originated events (send, delete, etc.) are propagated as requests. 4.Server uses SMS to notify of server originated events. 5.Client reacts to notifications if needed (e.g. fetches body of new message) over additional requests. The server maintains (cookie-based) a long-lived session and queues server events, reducing the need for full state comparisons. 6.If notifications are lost (out of coverage, etc.) the client retrieves pending events when one finally reaches its destination. 7.It is also possible that the client connects to server without even receiving the SMS. In this case, the server pushes pending events to the client in-band. Session 3. HTTPS binding, out-band notifications (e.g. SMS) Events

10. Future Work on P-IMAP 1.Allow support for a client device to track changes in multiple folders at once. 2.Enhance XZIP so that a client device can zip requests to the server. 3.Have an N most recent messages filter. 4.Allow support in out-band notifications to contain message events. 5.Complete empty sections (e.g. folder events, PIM events, …)

11. Proposal for next steps at Lemonade 1.Initiate a Lemonade IETF draft of IMAP-MP (Mobile Profile) 1.Starting from draft-maes-lemonade-p-imap-02.txt 2.Incorporating additional comments from Lemonade WG 3.Generate internet draft 00 for IETF-60 (san Diego) 2.Discuss comments, issues and next steps at IETF-60 for Mobile Profile: 1.E.g. complete future work 2.Consider specifying other bindings? 3.Consider deriving a notification IETF draft beyond mobile for IETF-61 4.Initiate a liaison with OMA on Mobile e-mail (New OMA Work Item) describing plans and status for Mobile Profile: 1.Hopefully OMA would re-use and point at IETF Lemonade Mobile Profile

12. PIMAP: Protocol Revision History 1.Updates for Release 02 1.Throughout this document - took out references to mailbox since its definition was ambiguous. Now, the terms folder, email account, and repository are used instead. 2.Section 1.2.2 - took out message events, which is now described in new section 3. 3.Section 1.4 - removed attachments behavior 4.Section 3 - new section containing event payloads 5.Old section 3.1.3 - removed this section on forwarded flags 6.Old section 3.1.4 - added resync, folder, and session untagged response syntax 7.Old section 3.1.5 - UID becomes should instead of must requirement 8.Old section 3.1.7 - took out resync, which is now in login section 9.New section 4.1.6 - a new section concerning untagged XENCRYPTED responses in place of untagged FETCH responses. 10.Old 3.2.1 - XPROVISION now just returns what XFILTERS are supported and what values some PIMAP Prefs can take on 11.Old 3.2.2 1.Took out PIMAP_OUTBAND_NEW_FORMAT 2.Added in PIMAP_INBAND_PUSH format 3.valid values for some preferences are given in XPROVISION 4.XGETPIMAPPREF -> XGETPIMAPPREFS 5.defined XGETPIMAPPREFS untagged response 12.Old 3.2.3 - defined XFILTER untagged response 13.Old 3.2.4 - dropped this section on XTERSE 14.Old 3.2.6 - changed syntax so only V & N can be given for get. 15.Old 3.2.7 1.XUIDCONVERT -> UID CONVERT 2.added untagged response syntax 16.Security Considerations section - added in that there are additional security considerations when the server is implemented through a proxy on a distrusted operator network. 17.Appendix B.2 - changed example where client gets events in response to a login command (instead of noop) 18.Appendix C - new appendix to cover security issues for proxy-based deployments of P-IMAP. 19.Appendix E.2 on further considerations, which are things to add in the upcoming releases.

13. PIMAP: Protocol Revision History 2.Updates for Release 01 1.Sections 1.1, 1.3, 2.2.1, 2.2.2, and 2.2.3 1.Added diagrams to better explain P-IMAP concepts 2.Section 1.4 1.Point 1 - changed term definition to Compression 2.Added points 5 and 6 regarding Attachment Handling 3.Section 3.1.4 1.Updated minimal P-IMAP server requirements 4.Section 3.1.5 1.Fixed the title – P-IMAP Session/Login 2.Added examples for “First Login” and “Login after Logout” cases 5.Added Section 3.1.7 1.RESYNC untagged response to solve problems with missed notifications 6.Section 3.2.2 1.XSETPREF and XGETPREF becomes XSETPIMAPPREF and XGETPIMAPPREF 2.Reduced the number of preference parameters 7.Section 3.2.3 1.Added a Days Before Today filter 8.Removed section 4 9.References 1. Added references to IMAP-DISC and RFC 2180 2.Removed references to MIMAP, NSMS 10.Appendix B 1.added example of outband notification and explained client's responsibilities 11.Appendix C 1.Removed completely, as attachment conversion is described in XCONVERT command and ways of retrieving it are discussed in RFC 2683 3.Release 00 1.Initial release published on Feb. 8th 2004