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

January 19-20, 2005 IETF 61.5 - Redwood City, CA 1

Lemonade61.5 Interim

Eric [email protected]

Glenn [email protected]

mailto:[email protected]



Note WellAny 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.


Scribes and Transcribes

?? for Wednesday

?? For Thursday

JABBER detailsRoom: lemonade Server: ietf.xmpp.orgLogs: http://www.xmpp.org/ietf-logs/[email protected]/


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)


Status Update

Chairs


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


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


What was going to be next…

• Updated Drafts December 1– Profile– Reconnect

• WGLC– Pull Trio (CATENATE, BURL, URLAUTH)

• New Documents– Transcoding Area


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


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


Goals

Kue Wong


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


The Trio

URLAUTH – Chris Newman

BURL – Chris Newman

CATENATE – Pete Resnick


Quick Reconnect

Corby Wilson


Lemonade61.5 Interim

Day Two

Eric [email protected]

Glenn [email protected]




Note WellAny 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.


Agenda (Day 2)

• Agenda Bashing

• Summary of Day 1

• Goals Phase 2

• Next Steps


Greg’s Replacement

Barbara Vaudreuil – Born 15 January 2005


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


Profile

• Need Examples

• Media Conversion Discussion (CHANNEL or otherwise)

• Quick Reconnect

• Streaming (using URLAUTH, RTSP, SIP)


S2S

• Requirements Published; What About S2S Notification Profile?– Do it or Drop it?– Bundle with S2C


Topics Not Chartered


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?


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?


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


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)


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


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?


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


Thanks!• Mail List:

– General Discussion: [email protected]

– To Subscribe: [email protected]

– 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/

http://flyingfox.snowshore.com/i-d/lemonade