Lemonade Meeting notes, IETF 65 (IETF 64.5 Interim Meeting Notes at the Bottom) Agenda Bashed. These minutes are organized topically, not chronologically. For a chronological report, please consult the Jabber logs at http://www3.ietf.org/meetings/ietf-logs/lemonade@rooms.jabber.ietf.org/2006-03-20.html and http://www3.ietf.org/meetings/ietf-logs/lemonade@rooms.jabber.ietf.org/2006-03-22.html Document Review Message Event Draft: Need additional detailed reviews, especially from diverse vendors, particular attention requested of the list of events Streaming draft not submitted. OMA Liason 1) OMA will review and get back to IETF on list of attributes necessary for conversion via the STI. After a spirited conversation, a nights passing, and study by an overnight design team the WG noted the following: - Lemonade is broader than mobile phones - Many conversions "manditory" for one area are non-sensical in another - Many of the most obvious conversions are IPR encumbered - HTML to text may be one conversion useful in all segments The WG finished the in-room discussion with a proposal to mandate a single HTML to text conversion as a mandatory-to-implement, primarily as a paperwork exercise the protocol The WG also agreed to send a liason to the OMA suggesting that the TS is the proper role to specify a subset of conversions useful for MEM. 2) The OMA clarified that the round-trip delay applied only to delay specific to the protocols and not the network. 3) Message recall is still are required feature, however, it is recognized that a valid server implementation may simply be to report that no report is available. (some confusion apparent in hindsight between a null protocol and a null implementation) This addresses the IETF concern that message recall is not useful in many topologies and may not be possible to implement securely between administrative domains. Notifications Draft The S2S requirements document will be integrated into the notifications draft. The S2S notification document has been held-up pending editorial work and the editor/author is no longer able to support such work. Further, thinking and consensus vocabulary has evolved since the document was written 4) OMA indicated that notifications need to be encrypted on the assumption that notifications will contain more than "something happened". A long discussion ensured highlighting a number of technical challenges to encrypting notifications. Among those attacks mentioned Man-in-the-middle, session hijacking, evil twin. ACTION: Chairs to engage the security directory for a discussion if issues, and in particular, risks with confidentiality without authentication Content Conversion No specific comments beyond the list of mandatory-to-implement discussed earlier. Sieve-related: - More folks are needed to review draft-ietf-lemonade-imap-sieve, with particular attention to changes about client cache impacts - ManageSieve Discussion of details moved to SIEVE working group. OMA does not want to usse managesieve... but need a way to instruct how to manage a database of various scripts. Action: Barry L. will update sive-imap and tease apart what the relationship to managesieve. draft using IMAP annotatemore to manage scripts Also some additional implications for use of manage sieve as the DF and NF interfaces are part of the enterprise messaging servers while VF and NF are envisioned to be possible in the MEM proxy. How to use manageSIEVE to manage those filters in the enterprise is unclear. Views - View and vfolder drafts to be combined... semantics of view folded into vfolder. - how to avoid multiple copies on client for multiple vfolders of same client: Sense of room.... listX? - Barry to propose an approach, list discussion sought - problem exists with multiple views on clients as well Search Within... - comment resolution accepted - Suggest not using negative numbers Vfilter... need to make explicit when the searches are re-executed... and then discuss if we agree with them. Compression Extensive on discussion ensured. A few conclusions: - TLS for compression is unlikely to be useful given the likely capabilities of considered diverse endpoints - No consensus on whether the server is intelligent enough to know when to compress objects... it can know the content, but traditionally handset best knows it's context. - Application compression most useful, but unclear whether stream-based or object encryption is preferable. - Proposal is to use StartTLS for stream conversion and to use Convert for object compression Action: Pete R. to summarize the discussion and sharpen the consensus Action: Stephan M. to propose adding a transform for object-level compression Review of OMA profile 2 status update... - Update as presented met no objection Reconnect: - new draft-05, - Alexi to take open issues to the list.. not clear resolution - 2nd call for implementation experience. IMAP URL - new revision cleaning up issues discovered in Vancouver - consensus... combine URLAUTH and IMAP URL drafts together - New document expected fixing issues and combining URLAUTH Message Encryption The WG discussed the requirement for client to message store encryption given the various topologies proposed. Earlier assumptions about using TLS encryption do not support many of the deployment models. Are those models rational in the lemonade model? There is a desire to explore object-level encryption such as draft-xencrypt. S/MIME may be the right technology, but it is the message store that is providing security services, not the sender. ACTION: engage security advisor to review the models and understand the implications. Profile BIS Agreement to merge Profile 1 and BIS to a single coherent document. This will include various fixes to Profile 1 and changes to the bis text. Specific content of BIS to be discussed on the list. Future delivery Process objection was made to this being a working group document. Decision to make it such was revised and agreement was to send the document for an IETF last call as individual contribution as soon as it is reposted as an individual submission. TCP Challenged environments The "HTTP binding" document is not within charter, however it will be reviewed by the WG. The document will be recast as BCP document describing how best to cope with TCP challenged environments. ACTION: Greg V. to provide a list of TCP challenged clients to include in an introductory section to illustrate for the need for the document. (Java Midp2, Ocap 1.0, OpenTV, ect.) Streaming media The last progress on this item was two years ago. Is it time to reconvene a design team to make progress? Charter Review No recharter envisioned at this time. However, there is a need to generating milestones to match-up with existing in-charter documents to provide better visibility into the work and schedule underway. LEMONADE Beijing - January 24-25 ========================== OMA liaison - concern from OMA on who has control and what IETF will provide - consensus that LEMONADE will provide the profile - after review of liaison as well as revised OMA AD, identified specific additional questions on:? notification encryption, a finite list of STI parameters, message recall issues, use of managed SIEVE - finalize liaison wording on mailing list Compression - TLS codec is GZIP, but compression of everything is not desirable so this is MAY - using selective ZIP compression is more appropriate, so this is MUST - consensus to document in a WG draft Firewall traversal - four possible bindings proposed:? tunnel, REST, SOAP & WebDav -- but this appears to be a lot of work - timeouts are an issue that can be solved by using tunnel approach, but SOAP is the simplest proposal - consensus to move forward with several non-standards track WG draft documents: ??????? - Firewall deployment considerations (BCP) ??????? - Firewall binding options (Informational) ??????? - Network timeouts (Informational) Notifications - consensus that the proposal is the basis for a WG draft describing VF, NF & DF - still need to decide on filter management - consensus to also make message event a WG draft Filters - IMAP SIEVE will be amended to use managed SIEVE -- but there are still some concerns with the use of SIEVE scripts for filtering... - consensus to move managed SIEVE to WG for last call - consensus to make VFOLDER a WG draft, but move SEARCH to a separate WG document Reconnect - we need a new draft before the next meeting - and we need some implementation experience feedback... LEMONADE profile-bis - includes deferred items from profile as well as the rest of the WG items based on OMA RD/AD input - include security/encryption?? Defer decision until review of proposals - still need proposals if we are to contemplate including them:? binary append, partials, proxies - consensus to merge figs 3&4 immediately and publish as WG document, have 01 ready for IETF 65 Expected before IETF 65, revised WG drafts on: ??????? Profile-bis ??????? Notifications ??????? Message event ??????? Content transformation (CONVERT) ??????? Filters (IMAP SIEVE & manage SIEVE) ??????? Quick reconnect ??????? 2192bis And new 00 WG drafts on: ??????? VFOLDER ??????? SEARCH modification ??????? Content transformation (the streaming one) ??????? Compression ??????? Firewall deployment considerations (BCP) ??????? Firewall binding options (Informational)