January 19-20, 2005IETF Redwood City, CA1 Lemonade 61.5 Interim Eric Burger Glenn Parsons

January 19-20, 2005IETF Redwood City, CA2 Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: –the IETF plenary session, –any IETF working group or portion thereof, –the IESG or any member thereof on behalf of the IESG, –the IAB or any member thereof on behalf of the IAB, –any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, –the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details.

January 19-20, 2005IETF Redwood City, CA3 Scribes and Transcribes ?? for Wednesday ?? For Thursday JABBER details Room: lemonadeServer: ietf.xmpp.org

January 19-20, 2005IETF Redwood City, CA4 Chair’s Agenda Status review –S2S Notification, MMS, Future Delivery, Goals Pull Trio (cooked and updated) Quick Reconnect Media Conversion Channel Profile (phase 1) Goals (phase 2)

January 19-20, 2005IETF Redwood City, CA5 Status Update Chairs

January 19-20, 2005IETF Redwood City, CA6 Lemonade Charter Review LEMONADE Goals IMAP4 extensions for VM playback IMAP4/SUBMIT extensions for forwarding IMAP4 extensions & profile for diverse endpoints Server-to-Server Notification Protocol Translation to and from other messaging systems

January 19-20, 2005IETF Redwood City, CA7 WG Deliverables LEMONADE Goals draft-ietf-lemonade-goals-05.txt IMAP4 extensions for VM playback draft-ietf-lemonade-imap-channel-02.txt IMAP4 extensions for forwarding draft-ietf-lemonade-burl-00.txt draft-ietf-lemonade-urlauth-05.txt draft-ietf-lemonade-catenate-03.txt IMAP4 extensions & profile for diverse endpoints draft-ietf-lemonade-reconnect-02.txt draft-ietf-lemonade-futuredelivery-00.txt draft-ietf-lemonade-profile-00.txt Server-to-Server Notification Protocol draft-ietf-lemonade-notify-s2s-00.txt Translation to and from other messaging systems draft-ietf-lemonade-mms-mapping-02.txt

January 19-20, 2005IETF Redwood City, CA8 What was going to be next… Updated Drafts December 1 –Profile –Reconnect WGLC –Pull Trio (CATENATE, BURL, URLAUTH) New Documents –Transcoding Area 

January 19-20, 2005IETF Redwood City, CA9 Objectives for Interim Timeline –Drafts before IETF 60Done –LC after IETF 60Done –Revisions Before IETF 61In Process –IESG Submission After IETF 61

January 19-20, 2005IETF Redwood City, CA10 WGLC Status Server-to-Server Notification Requirements –Closed, pending IETF last call MMS Mapping –Closed, new draft, pending IETF last call URLauth –Closed, new draft, pending IETF last call Future Delivery –Closed, pending revised draft Goals –Closed, new draft, pending IESG review resolution

January 19-20, 2005IETF Redwood City, CA11 Goals Kue Wong

January 19-20, 2005IETF Redwood City, CA12 IESG comments Security model –e2e, access all keys, per message key CONNEG not the right choice Trust model unclear Special mailbox uneeded State recovery at apps layer Security for streaming –Negogiate keys, use TLS/SASL Weak security considerations

January 19-20, 2005IETF Redwood City, CA13 The Trio URLAUTH – Chris Newman BURL – Chris Newman CATENATE – Pete Resnick

January 19-20, 2005IETF Redwood City, CA14 Quick Reconnect Corby Wilson

January 19-20, 2005IETF Redwood City, CA15 Lemonade 61.5 Interim Day Two Eric Burger Glenn Parsons

January 19-20, 2005IETF Redwood City, CA16 Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: –the IETF plenary session, –any IETF working group or portion thereof, –the IESG or any member thereof on behalf of the IESG, –the IAB or any member thereof on behalf of the IAB, –any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, –the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details.

January 19-20, 2005IETF Redwood City, CA17 Agenda (Day 2) Agenda Bashing Summary of Day 1 Goals Phase 2 Next Steps

January 19-20, 2005IETF Redwood City, CA18 Greg’s Replacement Barbara Vaudreuil – Born 15 January 2005

January 19-20, 2005IETF Redwood City, CA19 Summary of Day 1 Reconnect –Alexey to update Reconnect –Mike to update ClearIdle –Stéphane to provide state numbers Media Conversion –Static Conversion vs. Stream Conversion –Descriptors, Negotiation, and Control (e.g., CONNEG) –Mike to Summarize Discussion, send to list & Lyndon –Lyndon to Come Up With Whatever He Thought CHANNEL Was, and Give it Another Name or Abandon It –New ID Reliable Delivery – Sent to Alexey

January 19-20, 2005IETF Redwood City, CA20 Profile Need Examples Media Conversion Discussion (CHANNEL or otherwise) Quick Reconnect Streaming (using URLAUTH, RTSP, SIP)

January 19-20, 2005IETF Redwood City, CA21 S2S Requirements Published; What About S2S Notification Profile? –Do it or Drop it? –Bundle with S2C

January 19-20, 2005IETF Redwood City, CA22 Topics Not Chartered

January 19-20, 2005IETF Redwood City, CA23 Firewall Traversal Don’t want Enterprise tied to service provider –Hacked, proprietary firewall traversal solutions Pinhole timeouts –e.g., IDLE for more than 10 minutes –IMAP problem, or Transport Area problem? –Not really our problem, but need to prod those who’s problem it is. State Problems State What Behaviors We Would Like to See, from Application Perspective (not solutions) –Dave & Stephane –Try to solve it ourselves at Layer 7? –Push to Systems Engineering Groups, e.g, 3GPP/3GPP2, OMA?

January 19-20, 2005IETF Redwood City, CA24 Transport Optimization Bandwidth Constraints? Reducing BW?, Round-Trips (Chattiness)?, Data? Application-Aware Compression –E.g., Application knows body part is already compressed, not worth compressing entire stream (CPU Complexity) –What about using transport- level compression that “knows” not to spend cycles compressing compressed data? Is this science fiction? Need to Determine if it is a Real Problem. Is it really just a profile problem? –Á la VPIM requiring PIPELINE, etc. –Explicit Macros? –Alexey did II-D on set operations on result of SEARCH IRTF WG? –Measure protocol –See where compression would / would not help Research done outside official auspices of IETF?

January 19-20, 2005IETF Redwood City, CA25 Compression Approaches IMAP-level – per body part –E.g., Don’t compress compressed stuff; compress text Transport Level – entire stream It doesn’t matter: effective usefulness isn’t worth it Need analysis to figure out –Utility –Best choice

January 19-20, 2005IETF Redwood City, CA26 Filtering Event Types Notification Filters (e.g., Message Types) “Views” –Failed to get consensus in IMAP-EXT –IMAP-EXT didn’t consider bandwidth limitations of lemonade environment –Must Understand RDB Views (Codd & Date)

January 19-20, 2005IETF Redwood City, CA27 S2C Notification IDLE Works if Well- Connected Looking For Something Not- in-Current IMAP Session? This isn’t point; point is to determine content of notifications Can we Use SIP NOTIFY MWI (Describe in Lemonade Profile), or Do We Need to Build Something Different? Focus on Data to Transport, Don’t Get Stuck on Transport Protocol “Something for IMAP state sharing” Tie-in of Notifications and Synchronization? “IMAP Delta”, “MWI”, “IMAP Light”? Another research item

January 19-20, 2005IETF Redwood City, CA28 Next Steps Drafts Due 7 February 2005 (Really 21 Feb, but get it in early) WGLC Posted for BURL and CATENATE IETF LC Requested for MMS Mapping & S2S Notifications Meeting at IETF 62 –One or Two Slots? Two slots. –Not Monday Morning – Any Other Constraints?

January 19-20, 2005IETF Redwood City, CA29 Charter Dates Goals and Milestones: Oct 04Submit LEMONADE goals and use-cases specification to the IESG Oct 04Submit server to server notification requirements to the IESG Nov 04Submit translation to other messaging systems to the IESG Nov 04Submit IMAP/SUBMIT extensions for forward without download to IESG Jan 05Submit IMAP4 extensions for streaming multimedia to the IESG Feb 05Submit IMAP4 profile for mobile devices to the IESG Mar 05Submit server to server notification protocol to the IESG

January 19-20, 2005IETF Redwood City, CA30 Thanks! Mail List: –General Discussion: –To Subscribe: –In Body: in body 'subscribe' –Archive: ftp://ftp.ietf.org/ietf-mail-archive/lemonade/ Supplemental Work Group Page –