1 / 27

New Drafts Towards Phase 2 of Lemonade

Stéphane H. Maes, stephane.maes@oracle.com Ray Cromwell ray.cromwell@oracle.com. New Drafts Towards Phase 2 of Lemonade. Starting to address these issues: Proposed new drafts. draft-ietf-lemonade-convert-00 S2C notifications and Filters: draft-maes-lemonade-notifications-filters-how-to-01

cairo-schultz
Download Presentation

New Drafts Towards Phase 2 of Lemonade

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Stéphane H. Maes, stephane.maes@oracle.com Ray Cromwell ray.cromwell@oracle.com New Drafts Towards Phase 2 of Lemonade

  2. Starting to address these issues:Proposed new drafts • draft-ietf-lemonade-convert-00 • S2C notifications and Filters: • draft-maes-lemonade-notifications-filters-how-to-01 • draft-maes-lemonade-notifications-server-to-client-01 • draft-maes-lemonade-lzip-02 • Remote editing: • Issues on realizing LDeliver capabilities with trio, IMAPURL and Byte Ranges • Virtual folders • draft-maes-lemonade-vfolder-01 • Intermediaries and firewalls: • draft-smaes-lemonade-intermediary-challenges-03 • draft-maes-lemonade-http-binding-03

  3. CONVERT • draft-ietf-lemonade-convert-00: • Started from draft-maes-lemonade-lconvert-01 and implemented London agreements • Comments received from Alexey to be implemented in next revision

  4. S2C Notifications • draft-maes-lemonade-notifications-filters-how-to-01 • pointing to draft-maes-lemonade-notifications-server-to-client-01 • Comments from Alexey: OK to be implemented • Capability Descriptions • draft-maes-lemonade-notifications-server-to-client-01 defines how CAPABILITY can be used to support • determination of support of server to client notification, filtering • and filter updates…

  5. S2C Notifications • Event-based synchronization • draft-maes-lemonade-notifications-server-to-client-01 describes how event-based notification can be performed. This includes a payload specification for outband notification based on OMA-EMN and possible extensions. • Inband notification is achieved via IDLE. • Could be optimized? (see clearIDLE, Checkpoint, …) (not yet in draft-maes-lemonade-notifications-filters-how-to-01) • draft-newman-lemonade-msgevent-00 provides a list of possible events that could be notified • (based on the filter settings).

  6. S2C Notifications • Filters • SIEVE provides an email filtering language. • draft-ietf-sieve-notify provides mechanisms to generate notifications • based on the SIEVE filter. • To extend as NF, VF – see Lemonade realization diagram (not yet in draft-maes-lemonade-notifications-filters-how-to-01)

  7. IETF LEMONADE Notifications MobileNotification Magic Content Flows NF Wireless Protocols(WAP Push, SMS, …) LEMONADEIMAP Store ESMTP MTA DF AF IMAP VF Manage SIEVE? MUA URLAUTH LEMONADESubmit Server SUBMIT ESMTP MTA Non-IETFStuff IETFStuff Notification Stuff

  8. S2C Notifications • Next steps • Define ways to support NF/VF and set from client (not yet in draft-maes-lemonade-notifications-filters-how-to-01) • SIEVE filters should be extend to support generating notifications based on draft-newman-lemonade-msgevent-00 to support the notions of messages of type A, B and C and view, notification and event filters described in OMA MEM AD. • The payload should follow draft-maes-lemonade-notifications-server-to-client-01 (OMA MEM + extensions?) • Notifications target the email client through other notification servers or enablers. The notifications should be sent to the appropriate server.

  9. S2C Notifications • Checking notification settings • Mailbox annotations provide additional mechanism for the client to determine server settings as discussed in draft-maes-lemonade-notifications-server-to-client-01. • draft-maes-lemonade-notifications-server-to-client-01 also provides an inband mechanisms to determine these.

  10. S2C Notifications • Changing notification settings • draft-maes-lemonade-notifications-server-to-client-01 provides an inband mechanism to set / change notification and server settings • Changing filters from the client • draft-maes-lemonade-notifications-server-to-client-01 provides LFILTER as a way to update inband the filters from the client. • See VF/NF updates (see lemonade realization diagram) (not yet in draft-maes-lemonade-notifications-filters-how-to-01)

  11. S2C Notifications • Out of scope items: • Specific bindings for SMS (SMS binary, WAP Push) notifications. • OMA client provisioning and device management and other provisioning specifications (e.g. SMS based) • OMA enablers to support outband notifications. • OMA XDM may be considered also for outband filter changes.

  12. VFolder • Create virtual folders • Permanent searchs • Support VF for mobile view etc… • Inspired from P-IMAP LPSEARCH • Comments received from Alexey to be implemented in next revision • Proposal to make Lemonade WG IETF draft • Issue / question: • Need to reserve some folder names (inbox, outbox, …)?

  13. Compression • Mobile clients (GPRS, 1xRTT) are bandwidth constrained • Mobile bandwidth is expensive • IMAP is a verbose protocol • Experiments have shown dramatic compression ratios of IMAP response sequences are achievable

  14. Solutions • Transport Layer Security (TLS) compression • But, not all TLS implementations support compression • Deployment of a codec specialized for IMAP may be infeasible • Application level encryption • New IMAP extension LZIP • Wraps an IMAP command and indicates to the server to compress all server generated responses using ZLIB • Defining specialized compression dictionary may be desirable

  15. LZIP Example C: A001 LZIP A002 FETCH 1:* ALL S: * LZIP ~{1234} S: ...[zipped response to FETCH command]... S: A001 OK LZIP completed

  16. IMAP Command Ratio UID FETCH 1:* FLAGS 3144/20408(15.4%) SELECT INBOX 249/465 (53.5%) UID FETCH n BODY[1] 1064/2003 (53.1%) LZIP Compression example ratios600 messages in INBOX

  17. TLS LZIP Roundtrips Minimum 2+ 1 minimum Complexity TLS/SSL stack + CPU overhead ZLIB + cpu overhead Comments LZIP (defining compression at the application layer) allows some clients to achieve compression without a full SSL/TLS implementation, or where the server does not support the right set of cipher suites, or where an application protocol sensitive codec may be desired Compression

  18. Remote Editing • Implementing LDeliver functionality with trio and IMAPURL

  19. OMA Requirements • USAB-21 “The mobile email client MUST allow the user to edit a partially downloaded email, for reply and/or forward and have the server send all the portions of the edited email while minimizing the amount of data that is sent to the server (e.g. sending the differences)” • USAB-25 “When replying to a list of addressees, the mobile email client MUST allow the user to edit the addresses without downloading or uploading the whole list of addresses and minimize the amount of data that is sent to the server”

  20. Approaches • IMAPURL can be extended to support partial fetch of body sections (the ‘ipartial’ grammar extension). This allows CATENATE to operate on text at a smaller granularity. • IMAPURL and IMAP could also be extended to allow header address fields to be treated as lists which can have range operations applied, or partially fetched

  21. Use Case • Reply To All/Group with large recipient list • Selectively remove or append recipients to list

  22. Problems • Composed header fields could be edited • Construction of SMTP Envelope isn’t handled • BURL doesn’t allow fetching IMAP data for envelope. Need SMTP extension as well? • Is use case too rare?

  23. SMTP Extension? • Extension parameter for MAIL/RCPT to fetch from a URL?

  24. Discussion • Ideas for solutions and syntax? • Security issues • Sending spam also becomes very efficient over low bandwidth links

  25. Intermediaries • draft-smaes-lemonade-intermediary-challenges-03 • Per London AI discusses main issues: • IDLE life time on mobile network (2.5G and even worse on 3G network) • Battery implications • Time out of intermediaries • TCP vs HTTP: • IDLE over HTTP has much longer life time • Firewall issues

  26. HTTP Binding • draft-maes-lemonade-http-binding-03 • Optional use of HTTP as binding for IMAP • Address time out differences • This binding is intended to facilitate the use of IMAP in deployments involving a variety of intermediaries • offers a standardized alternative to de facto proprietary implementations of such a feature. • HTTP allows operators to reuse similar setup and model already used for many other similar and related services, e.g. certain proprietary push e-mail and synchronization offerings, OMA Data Synchronization, Web services and Web access. • Using HTTP/HTTPS can simplify deployment in a corporate network through the potential use of a reverse proxy . • Also has the advantage of not requiring changes to any firewall configurations and reduces deployment concerns that this often presents to corporation. • In general the solution is compatible with any existing firewall. • A reverse proxy can also support deployment models that offer roles to other service providers in the value chains, as discussed in OMA Mobiel e-mail AD • Based on LDELIVER disposition: • Binding for submit on HTTP • Added security / section on caching issues

  27. HTTP Binding • Follows HTTP message model and error • Follows RFC3205 • Plan to generate bindings on: • SOAP • REST • WebDAV • Proposal to analyze these bindings too and then decide best way forward

More Related