Minutes of LEMONADE BOF Thursday July 18, 2002, 3:30 pm Co-chairs: Glenn Parsons Eric Burger Minutes: Abbie Barbir Introduction ------------ . Glenn described the origin of the acronym . Agenda bashing . LEMONADE came from VPIM WG . Looked at client to server interaction . Should the work be done in FAX and VPIM? Decided to create a BOF to address these issues . 10 drafts are already in . 4 residual from the VPIM, these are closer to finish and may happen in VPIM . To subscribe to the mailing list: send message to majordomo@snowshore.com with "subscribe um" in body Archive is at http://flyingfox.snowshore.com/um_archive/maillist.html Lemonade Requirements - Eric Burger - draft-burger-um-reqts-00 -------------- . A lot of the service providers like to move internet standard way into 3GPP Question/remarks - make sure that you check what the IETF already has - Is this going to go in the direction like Midcom - Are we changing protocols that require big machines or are taking them as is - We do not have any protocols between the application and the link layer - Other issues other than memory constraints that need to be addressed - Will the charter require that this WG not touch any other protocol - Look at six years ago, this protocol must be changed and then we realized that we may not need to. SNAP is something new that needed to be happened - From application layer prospective we do not care about the lower layer we need to use the same e-mail client regardless of what, the ultimate goal is to use the same application regardless of the link layer, the question of how to go from here to there. - That what is the WG wants to do just look at that now - May be we need gateways for the next 20 years. If the WG finds that that might be interesting by itself. - We may also discover that there is no answerer at this time Lemonade Extensions - Greg Vaudreuil - draft-vaudreuil-um-issues-00 -------------- - specify the specific issues that Lemonade needs to meet for specific applications - What specific things that needs to be meet for internet mail Questions/remarks - is this mostly an IMAP document, needs to be reworked as a general purpose document - this needs to be merged with other doc and have one general purpose doc - this should be treated as a token for doing things - now there is an assumption that there is exist a profile protocol, this may not be the case. - Having more generic justification may be useful, another doc may address if there is a current solution - What is the main problem statement - We need a way for clients to negotiate with servers for a richer experience, current environment is not rich enough - Need a scenario and proper relation to a problem statement, allow us to see the changes that need to be done - In SIP we had a marketing requirements and then we needed a mid level requirements that discusses what need to be done, other document may do more down in details but all need to be able to access the top requirement doc. Basically one very high level doc. Unified messaging support for diverse clients, An architecture for Internet Mail Evolution - Kue Wong - draft-wong-umcli-00 -------------- - challenge, to enable a simple uniform access to diverse messaging by diverse client types. This is more of an approach as opposed to an architecture. Question/remarks - it seems in the wireless use case is there a way in IMAP to get the capabilities of the device. - IMAP is a pull protocol, may not fit in the current scope of a WG - If you do Transcoding from HTML to text, how u will filet that and how these capabilities will done, how about content adaptation, are you going to be deal with it or not, these need to be addressed in the requirement document. - In the case of two UAs is similar to cases where the initial connection is made with one device and then continue on another one? Perhaps the requirements doc need more work to reflect this. - Can help in scoping these extra applications - Need to move away from dependency on the main server - SIP may be able to help but it is heavy weight solution - It would really help if you frame this doc as a problem doc as opposed to an architecture, what are the needs of these wireless devices that we need to address in the WG SMTP Service extension for message Media Size declaration - Ari Erev - draft-shviedel-mediasize-00 -------------- - more directed towards a voice mail scenario, and assumes that SMTP will be extended. Questions/remarks - I do not understand why the size for context type - The context is defined only as a hint, is context confused by location maybe, you can be done using location, how the server can allocate quota based on what the client say, the client can lie. - Do you think that is useless all together, - Yes the context is useless for allocating quota - May be we should use a protected quota for a specific super client - One difference between this and the size extension is that it is less specific than this application - Not all servers well implement this - We not need that. - Question to Lisa, how about a trusted agent, UA? - We do not think of that as a UA - All depends on trust issues, which UA trust whom, there is no way of determining what the size means. - Do we really need to support a specific size unit SMTP Submission service for Future delivery - Greg White - draft-vaudreuil-futuredelivery-00 -------------- - extension to allow a user submit a message and then it gets delivered later Questions/Remarks - use SMTP to submit the message but use IMAP to edit the message - customers nee delivery windows, just deliver mail based on time of day - this also applies to the general requirements for SMTP - this and many other extensions may end up discovering SMTP submission - there are a class of things that people wanted to do and that one of the points of the submission protocols does not allow u to that without SMTP - there is a FAX doc that propose additional semantics that may need to be re-scoped to get some of the requirements here. Status Counters use cases - Ari Erev - draft-neystaft-imap-counters-00 -------------- Questions/remarks - how long before we discuss if this a WG or not? Glenn, - there is a proposed charter, need to discuss if we go from BOF to WG - we'll do that next Charter Review -------------- Questions/remarks - we need a WG, but the charter is thin on specifics - need to get the first three drafts as problems statements before a WG would go - SNAP is one the document that was mentioned, notifications is hard, WEBDAV could use that - SNAP is very specific - I support the suggestion to rework the drafts and get better charter - There is more work that need to be done before this becomes a WG - Do we need an instant for each protocol, or de we need a framework and after that in place address each protocol. - Regarding SIP notifications and it seems that SNAP solves a different problem. This charter is not too bad, I say go for it. - SNAP had poor sensibility primitives, poor job in defining in defining counters and other stuff without creating problems. No objection to this working group up to point step 3. Change item three in the charter to define requirements - We hope that SNAP gets finished before that this get chartered. - My company does a document share store, many customers are frustrated with e-mail servers with many copies of the same doc. How to store the document somewhere else and say that to the client where it is. May need to add that to step 2. is this in the scope - The way to do that is a variation on other schemes for storing doc in a different place. There are protocols that do that. It is more of a user behavior. - User can only attach by attaching to e-mail. The e-mail client has no notion of putting things. - We do not want to solve it here. - The charter is coherent but it really needs a better outline. - We need to get out of device independence work, etc.., need to look very focused. - Hum time -- Is this subject matter of interest to IETF? (good hum) - Patrik says that the charter need more clarification on issues like low bit rate and everyone agreeing what it means, where it is, is this precise enough, and why the conclusion is needed. Should continue such discussions, may should have a little more of this matter. However this looks like a good charter, discuss more on the mailing list and see if people are comfortable. Suggest we go ahead with the chartering process, with one of the early milestones being to revisit the charter.