1 / 30

Lemonade 61.5 Interim

This document provides a summary of the status updates and goals review discussed at the Lemonade 61.5 interim meeting. It includes updates on various drafts and deliverables related to IMAP4 extensions, server-to-server notification, media conversion, and more.

washingtond
Télécharger la présentation

Lemonade 61.5 Interim

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. Lemonade61.5 Interim Eric Burger eburger@brooktrout.com Glenn Parsonsgparsons@nortelnetworks.com IETF 61.5 - Redwood City, CA

  2. 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 3668.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. IETF 61.5 - Redwood City, CA

  3. Scribes and Transcribes ?? for Wednesday ?? For Thursday JABBER details Room: lemonade Server: ietf.xmpp.orgLogs: http://www.xmpp.org/ietf-logs/lemonade@ietf.xmpp.org/ IETF 61.5 - Redwood City, CA

  4. 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) IETF 61.5 - Redwood City, CA

  5. Status Update Chairs IETF 61.5 - Redwood City, CA

  6. 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 IETF 61.5 - Redwood City, CA

  7. 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 WG Deliverables IETF 61.5 - Redwood City, CA

  8. What was going to be next… • Updated Drafts December 1 • Profile • Reconnect • WGLC • Pull Trio (CATENATE, BURL, URLAUTH) • New Documents • Transcoding Area  IETF 61.5 - Redwood City, CA

  9. Objectives for Interim • Timeline • Drafts before IETF 60 Done • LC after IETF 60 Done • Revisions Before IETF 61 In Process • IESG Submission After IETF 61 IETF 61.5 - Redwood City, CA

  10. 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 IETF 61.5 - Redwood City, CA

  11. Goals Kue Wong IETF 61.5 - Redwood City, CA

  12. 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 IETF 61.5 - Redwood City, CA

  13. The Trio URLAUTH – Chris Newman BURL – Chris Newman CATENATE – Pete Resnick IETF 61.5 - Redwood City, CA

  14. Quick Reconnect Corby Wilson IETF 61.5 - Redwood City, CA

  15. Lemonade61.5 InterimDay Two Eric Burger eburger@brooktrout.com Glenn Parsonsgparsons@nortelnetworks.com IETF 61.5 - Redwood City, CA

  16. 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 3668.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. IETF 61.5 - Redwood City, CA

  17. Agenda (Day 2) • Agenda Bashing • Summary of Day 1 • Goals Phase 2 • Next Steps IETF 61.5 - Redwood City, CA

  18. Barbara Vaudreuil – Born 15 January 2005 Greg’s Replacement IETF 61.5 - Redwood City, CA

  19. 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 IETF 61.5 - Redwood City, CA

  20. Profile • Need Examples • Media Conversion Discussion (CHANNEL or otherwise) • Quick Reconnect • Streaming (using URLAUTH, RTSP, SIP) IETF 61.5 - Redwood City, CA

  21. S2S • Requirements Published; What About S2S Notification Profile? • Do it or Drop it? • Bundle with S2C IETF 61.5 - Redwood City, CA

  22. Topics Not Chartered IETF 61.5 - Redwood City, CA

  23. 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? IETF 61.5 - Redwood City, CA

  24. 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? Transport Optimization IETF 61.5 - Redwood City, CA

  25. 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 IETF 61.5 - Redwood City, CA

  26. 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) IETF 61.5 - Redwood City, CA

  27. 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 S2C Notification IETF 61.5 - Redwood City, CA

  28. 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? IETF 61.5 - Redwood City, CA

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

  30. Thanks! • Mail List: • General Discussion: lemonade@ietf.org • To Subscribe: lemonade-request@ietf.org • In Body: in body 'subscribe' • Archive: ftp://ftp.ietf.org/ietf-mail-archive/lemonade/ • Supplemental Work Group Page • http://flyingfox.snowshore.com/i-d/lemonade/ IETF 61.5 - Redwood City, CA

More Related