1 / 21

What is Lemonade

8 August 2005. IETF Lemonade. 2. Outline. Lemonade GoalsEnhancements to Internet email to support diverse service environmentsDrivers (from Charter/Goals Document)Current WorkTrio, Reconnect, MMS Mapping, ProfileFuture DeliveryMapping of OMA RequirementsOverview of Our Understanding of Requir

parry
Download Presentation

What is 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. What is Lemonade? Glenn Parsons gparsons@nortel.com Eric Burger eburger@brooktrout.com

    2. 8 August 2005 IETF Lemonade 2 Outline Lemonade Goals Enhancements to Internet email to support diverse service environments Drivers (from Charter/Goals Document) Current Work Trio, Reconnect, MMS Mapping, Profile Future Delivery Mapping of OMA Requirements Overview of Our Understanding of Requirements Broad Outline Work Program Going Forward Transcoding (Static and Streaming) Profile V2 Meeting OMA Protocol Requirements Extensions for Above

    3. LEMONADE formation

    4. 8 August 2005 IETF Lemonade 4 Origin of activity VPIM and FAX WGs Constituency of messaging vendors -- winding down VPIM v2 (Draft Standard), IVM T.37 (Draft Standard), FPIM, TIFF-FX But some new work is desired on… Unified Messaging (UM) ‘What is UM?’ vs ‘What is Pink Lemonade?’ Key requirements described focused on access to UM servers from thin (e.g., mobile) clients Specific IMAP extensions proposed • VPIM - server-server • IVM - client-client • LEMONADE - client-server – Clients are diverse endpoints• VPIM - server-server • IVM - client-client • LEMONADE - client-server – Clients are diverse endpoints

    5. 8 August 2005 IETF Lemonade 5 IETF LEMONADE WG License to Enhance Messaging Oriented Network Access for Diverse Endpoints Enhancements to Internet email to support diverse service environments Key Drivers Mobile and Mobile-Like (i.e., Set-Top Box) Low Bandwidth, Low Power, Limited/No Storage, and/or Limited Display)\ Chartered 2003

    6. 8 August 2005 IETF Lemonade 6 Guiding Requirements Performance Requirements Real-time Playback Avoid Base-64 Data inflation Functional Limitations Context in mailbox summary Context in mailbox search Context in mailbox quota Functional mailbox conventions Inbox, sent items, deleted items, expired item CLID Restriction indication / preservation Committed delivery to full mailbox Message Submission Limitations Forward without download Quota by context enforcement Future Delivery Support Notification Message Store to Notification protocol Evolutionary Mission Client message submission profiles for VPIM/IVM Web browsers -- 3rd party email clients Client message retrieval profiles for VPIM/IVM Web browsers -- Thin clients Multimodal -- Mobile Goals Reuse Existing Protocols Maintain Protocol Integrity Sensible Message Context Preserve Internet Infrastructure Meet Near-Real-Time Telephony Requirements Be Scalable, esp. for Video

    7. 8 August 2005 IETF Lemonade 7 LEMONADE Goals De-emphasize the requirements aspect does not strictly define requirements except so far as to reiterate those in the charter Focus on context and motivation documenting the thinking going into the lemonade design process. use-cases giving rise to certain desirable functionality as well as a collection of suggested solution approaches. Supporting descriptive background TUI, WUI concepts described as a subset of mobile messaging.

    8. 8 August 2005 IETF Lemonade 8 Charter Lemonade is tasked to provide a set of enhancements and profiles of Internet email submission, transport, and retrieval protocols to facilitate operation on platforms with constrained resources, or communications links with high latency or limited bandwidth. A primary goal of this work is to ensure that those profiles and enhancements continue to interoperate with the existing Internet email protocols in use on the Internet, so that these environments and more traditional Internet users have access to a seamless service. Lemonade's work is at the crossroads of a body of work related to Internet messaging, in particular work done by the VPIM, FAX, and IMAPEXT IETF working groups. Given the potentially broad scope of activities this group could engage in, the group will focus specifically on the following work items: 0. An informational RFC or RFCs will be produced on LEMONADE architecture and the issues it seeks to address. 1. Enhance the existing IMAP4 message retrieval and message submission (RFC 2476) protocols to satisfy the requirements for handling streaming multimedia content. The existing standards-track CONNEG framework will be used if content negotiation capabilities are needed. The group will employ existing protocols (such as for streaming) with IMAP4 instead of duplicating such functionality within IMAP4. 2. Enhance the existing IMAP4 message retrieval and/or message submission (RFC 2476) protocols to satisfy the requirements for forwarding a message and/or its attachments without downloading the message to the client and subsequently uploading the message to a server. 3. Refine the existing IMAP4 message retrieval protocol to facilitate its use with devices that have limited capabilities such as mobile endpoints. At most one backwards compatible profile of IMAP4 will be produced by this effort. 4. Define a format for message notifications for servers reporting message status information to other servers. Specify the method for delivery of those notifications. 5. Create a specification describing the use of Internet message services in environments where message delivery may take place using either Internet protocols or through an MMS server using WAP to communicate with the receiving user agent. The BOF will coordinate its efforts with : 3GPP TSG T WG2 SWG3 Messaging <http://www.3gpp.org/TB/T/T2/T2.htm> W3C Multimodal Interaction Activity <http://www.w3.org/2002/mmi/> Open Mobile Alliance <http://www.openmobilealliance.org/> 3GPP2 TSG-X <http://3gpp2.org/Public_html/X/index.cfm>

    9. LEMONADE current work

    10. 8 August 2005 IETF Lemonade 10 Lemonade Charter Items LEMONADE Goals IMAP4 extensions for VM playback IMAP4/SUBMIT extensions for forwarding IMAP4 extensions & profile for diverse endpoints Server-to-Server Notification Protocol NOTE: Server-to-Client Notification, After MUCH Debate, Was NOT Chartered Translation to and from other messaging systems

    11. 8 August 2005 IETF Lemonade 11 WG Deliverables LEMONADE Goals draft-ietf-lemonade-goals IMAP4 extensions for VM playback draft-ietf-lemonade-imap-channel IMAP4 extensions for forwarding draft-ietf-lemonade-burl draft-ietf-lemonade-urlauth draft-ietf-lemonade-catenate IMAP4 extensions & profile for diverse endpoints draft-ietf-lemonade-reconnect draft-ietf-lemonade-futuredelivery draft-ietf-lemonade-profile Server-to-Server Notification Protocol draft-ietf-lemonade-notify-s2s Translation to and from other messaging systems draft-ietf-lemonade-mms-mapping

    12. 8 August 2005 IETF Lemonade 12 Compression Analysis for Application-Level Compression Cost for Roundtrips and Complexity of Protocol Benefit Zero for Multimedia Content (very large objects, 1-3% expansion) 50% for text (small objects, trivial net gain) Analysis for Transport-Level Compression 50% compression for headers Same content benefits Tradeoff Handset CPU for every message vs. much more complexity in application-level protocol TLS might be required anyway for firewall traversal TLS with NULL Cipher gets compression “for free”

    13. 8 August 2005 IETF Lemonade 13 Forward without download Pull draft-ietf-lemonade-catenate draft-ietf-lemonade-burl draft-ietf-lemonade-urlauth SMTP Submit w/ Object Retrieval Message headers requested and sent to UA Message header delivered to GUI New message created with reference to message received in 2. Sent to UA Message with references sent to MS via IMAP, compiled message stored. Key created. Message with reference to include message in 4 sent to MTA via SMTP MTA requests MS for referenced message with key. MTA sends message via SMTP

    14. LEMONADE reaction to OMA liaison

    15. 8 August 2005 IETF Lemonade 15 OMA Mobile Email RD Network configurable users Usability General email requirements Forward without download Filtering Partial download Interoperability Network agnostic Minimize network delays Minimize bandwidth Reduce chattiness Security Authentication confidential Privacy

    16. 8 August 2005 IETF Lemonade 16 LEMONADE initial response Many met with base IMAP and SMTP Submit Views, search, synchronization, multiple clients, TLS security and compression Descriptions of how to use protocols to met protocol required Many met with in-process or planned Lemonade Extensions to same Quick reconnect, transcoding, streaming Many require SIEVE rule extensions and mechanism for configuring such (XCAP?) Auto-Response messages Push Notification filtering Most are user-agent programming and configuration Many requirements for network-based administration of client option configuration (OTA or other) A few are server-side implementation requirements Charge account for example

    17. LEMONADE future work

    18. 8 August 2005 IETF Lemonade 18 Security Security model e2e, access all keys, per message key This needs protocol work with S/MIME or PGP WGs State recovery at apps layer Persistent session layer instead Security credentials for streaming Negogiate keys, use TLS/SASL or SDP

    19. 8 August 2005 IETF Lemonade 19 Media Conversion Blob Media Conversion Need Document Editor Streaming Media Conversion Have Approach; May Need New Document Editor if Current Editor Doesn’t Deliver Leverage STI Profile to Wrap It All Up

    20. 8 August 2005 IETF Lemonade 20 Firewall Traversal Should Not Use HTTP IT Managers Do Not Want to Buy More Packet Filtering Packages Many IT Managers Need to Monitor E-Mail Traffic (E.g., SOX) Use Standard E-Mail Ports Submit, IMAP RFC2979

    21. 8 August 2005 IETF Lemonade 21 Server-to-Client Notifications Requirements needed to justify

    22. 8 August 2005 IETF Lemonade 22 LEMONADE Profile – Phase 2 Position to meet ‘left over’ IETF requirements as well as all OMA mobile email requirements Summarizes applicability of extensions to base Internet Mail Protocols

More Related