Logs for lemonade@ietf.xmpp.org, 2004-11-10[07:31:11] --- amelnikov has joined [10:30:00] --- dbrashear has joined [11:30:28] --- corby has joined [11:33:55] --- corby has left [12:14:01] --- dbrashear has left: Disconnected [12:37:25] --- dbrashear has joined [14:01:17] --- dbrashear has left: Disconnected [14:15:42] --- Glenn Parsons has joined [14:17:42] --- kmurchison has joined [14:19:34] --- lisa has joined [14:20:03] Hola [14:21:43] Hi [14:29:35] We will start in a minute or so. [14:29:58] Our minute taker (Corby) has not arrived yet :-) [14:32:33] --- corby has joined [14:32:47] Aaaaand I'm here. [14:33:16] --- pguenther has joined [14:33:22] --- resnick has joined [14:33:36] Somebody has to take notes while Corby is presenting [14:35:41] --- randy has joined [14:36:23] --- kuewong has joined [14:36:27] We sill start very soon... [14:36:31] --- hardie has joined [14:38:16] welcome to Lemonade [14:38:29] Glen has a new clone. Congratulations! [14:38:56] Agenda bashing [14:39:11] --- bdesruisseaux has joined [14:39:54] Monday Recap [14:40:18] MMS Mapping, Future Deliv, and S2S are done. Looking for WGLC [14:40:38] --- rlbob has joined [14:41:02] URLAUTH: anonymous question on list. Authorths will leave it in. [14:41:03] --- hildjj has joined [14:41:09] BURL: Done,some nits [14:41:21] CATENATE: Use cases needed (Alexey) [14:41:37] Send URLAUTH, BURL, CATENATE to WGLC by Dec 1 [14:41:53] Pete: BURL, nits identified on ML? [14:42:04] Pete: WGLC BURL now. [14:42:19] Is BURL dependent on other 2? [14:42:36] Glenn: Submit all 3 at the same time for WGCL. No need to do individual submission? [14:42:48] Discussion on WGCL process. [14:43:26] CLEARIDLE/CHECKPOINT: vs. Quick Reconnect and S2C. [14:43:51] Is it apropriate in light of other tech: XMPP, SOAP, SIP, etc. [14:44:08] Definitions seem outside of charter, but we can add. [14:44:19] MSGFILTER: Seems similar to XFILTER. [14:44:20] I need to finish off CATENATE the week of Nov. 22, so I'll need examples by then. [14:44:41] Pete: no problems. [14:44:50] MSGFILTER does not scale in IMAP. [14:44:51] Thanks Alexey. [14:45:02] Subtle diff btw XFILTER and MSGFILTER. [14:45:12] Stephane: Mobile email [14:45:58] Purpose is to understand notion of mobile email and should lemonade address the notion of mobile email. [14:46:18] Mobile emai: "Access to emiail while mobile" [14:46:34] Expectation: Receive somewhat-instant notification of email [14:46:47] Efficient manipulation of email [14:46:52] e2e secure [14:47:09] Eric: Anybody surprised by this? (non-goals) [14:47:34] Eric: Noticiations can be minutes on the corporate lan. Immediate notification not necessarily the goal. [14:48:36] Mobile extensions to mail. Full scope to provide mobile email solution including IMAP, SMTP, and all associated tech. [14:48:44] Define quasi-instantaneous delivery [14:49:12] --- Glenn Parsons has left: Disconnected [14:49:35] --- Glenn Parsons has joined [14:49:53] Expect apropriate behaviour of emaild delivery when notifications are enabled. [14:50:24] Additional considerations: Fomrat adaptation (CHANNEL?) DRM rules, Provisioning, Charging (billing), etc. [14:50:43] Pete: All of this is fine, as long as everyone understands that we only work on IP based protocols. [14:51:08] Corby: Sufficient to deffine a UDP procotol, but not a WAP. [14:51:27] eric (hat off): Define a msg format and transport (hypothetical). [14:51:50] Mobile world would take GW to SMS or WAP. That's fine, but we won't do it. We will define the GW and interface, but that's it. [14:52:11] This is internet email that supports mobile environments. [14:52:40] Randall: Provisioning, tech already exists (XCAP,etc). Why do we need to redefine for Lemonade. [14:52:48] Eric: is it usefull for mail [14:53:22] WGCh: Do Provisioning after everything else has been defined. [14:53:47] Firewall: Are we considering FW and NAT traversal for this? [14:53:50] Stephane: Yes. [14:54:43] Challenges for Consumer and Enterprises; [14:55:00] FW, VPNs, E2E sec, etc. etc. etc. [14:55:08] Deployment Patterns (see slides) [14:56:07] Different deployment models for typical enterprise email setup. [14:57:26] Pete: If you were to circle everything in internet and operator space, everything in that space is not something we are working on? [14:57:49] Is Mobile e-mail enabling server etc. in the domain of IP? [14:58:01] Is the connector the edge of IP? [14:58:12] --- Glenn Parsons has left: Disconnected [14:58:16] Pete; Connector is not an IP protocol entity. [14:58:34] Greg: Connector can be an IMAP proxy. [14:58:44] Connector is a logical drawing and may not necessarily exists [14:59:20] In fact, the goal of the WG is the line from the email client to the email server. [14:59:43] There may be other servers, proxies, GW inbetween, but these are out of the scope of the WG. [14:59:45] --- hildjj has left: Replaced by new connection [14:59:48] --- hildjj has joined [15:00:14] What is the scope of Lemonade> [15:00:28] Greg: Wants all of these issues addressed (many). [15:00:51] Greg: The competition is extreme and they handle all of the scenarios, so if we don't why are we here? [15:01:14] Greg: All current email is either proprietary or proprietary derivatives of existing standards. [15:01:49] Stephane: Argument can be made to do E2E in IMAP, but reality is we will require other servers to mobilize across networks and verndor spaces. [15:02:18] (cont) Do we want to create something that can compete in the space or do we want to improve what we have? [15:03:05] We will not contrort protocols to work arround implementation deficiencies in the TCP/IP stack infra in mobile networks and devices. [15:03:18] Don't fix IP problems in the phones. [15:03:52] Eric: Timeline is next year. Most lilekely the phones will be fixed by the time we release Lemonade. [15:04:24] --- Glenn Parsons has joined [15:04:31] Eric: Apr 2004, BLOAT was proposed which would solve all these issues. Not considered for this, but just an example [15:05:18] S: Understanding that we can not keep a TCP connection up all the time, we can't fix that and we shouldn't try to fix that, but me can account for characteristics of the network. [15:05:19] FYI, the web slides are on the LEMONADE supplemental site [15:05:23] Eric: We are going to be idealistic and practical. [15:05:55] --- kuewong has left: Disconnected [15:06:18] Randy: If we have soluitions which are usefull fo general classes of problems, then we can asupport more. [15:06:33] Presentation of Lemonade Goals: [15:06:50] Comments were usefull and were incorporated into the draft. [15:07:08] All editorial nits accepted. [15:07:51] the goals document was not intended as a working requirements document, but rather as a historical record. [15:08:54] Eric: we are not going to replace IMAP, (IMAP-NG). [15:09:22] Eric: We are extending IMAP not writing replacement commands or protocols. [15:09:28] No such thing as a Lemonade protocol. [15:10:24] Discussion on Goals references. NP [15:11:21] Fix phrasing in current Goals doc [15:12:11] Q: Is the intion of MMS mapping to define MMS as the primary transpoort of Lemonade in mobnile net? [15:13:45] Randy: Mapping work hits charter item. If you have MMS system and a separate mail system, then those systems can interoperate. There is no dependency in Lemonade to MMS. [15:13:52] --- hildjj has left: Disconnected [15:13:55] Randy: Simply and interworking document. [15:14:22] --- hildjj has joined [15:14:29] Eric: Pragmatic approach to interworking protocols. [15:15:24] Randy: First step to replacing MMS or custom protocols with IP protocols to get homogeneous network system over mobile nets [15:17:30] Reminder: Slide sets available on Alternate Lemonade Page:http://flyingfox.snowshore.com/i-d/lemonade/ [15:17:58] Glenn: We are not creating a new IMAP, we are not creating a new internet email. We simply defining extensions. [15:18:40] Stephane: Needed to understand the goal of the Goals document. [15:18:53] Q&A: none [15:19:17] Eric: Mumbling: All changes are editorial in nature, so WGLC is closed. [15:19:28] No objectiosn give. Update doc and send to AD ASAP. [15:19:50] --- Glenn Parsons has left: Disconnected [15:20:06] Stephane: Goal2 item. Will have some time to discuss progress resolution? [15:20:16] Glenn: Will discuss at end of meeting. [15:20:34] ----------------------------------- [15:20:40] Stephane: Presenting Lemonade Profile [15:20:53] What should be done with profile. [15:21:20] Add the current drafts into profile content. [15:21:51] Glenn: WGCL on profile, decide if we want profile1 and go to new profile or hold profile and continue to update profile and make it a living doc. [15:22:16] Have profile1 be a living doc and continue update and limit to current drafts. [15:22:35] have revision on profile in the next 2 weeks for submission. [15:22:49] -------------------------- [15:23:09] Someone channel Alexey if he as a question or statement. [15:23:45] --- Glenn Parsons has joined [15:25:21] --- hardie has left: Lost connection [15:25:39] Note that the Stephane's slides on mobile email are in the direcotry for the 60.5 interim meeting [15:25:54] Corby presenting [15:26:56] indicates that some study is still needed on Micheal Wener's proposal [15:27:19] New SID/NEWSID param on LOGIN/AUTHENTICATE [15:27:28] Creates resumable session. Can keep on LOGOUT. [15:27:35] Send EXPUNGEs [15:27:54] Send FLAGs [15:28:25] Corby goes through states [15:31:29] --- kuewong has joined [15:31:44] Open issues: [15:32:08] - server-side state cache (can we eliminate this and have client send enough information) [15:32:26] - number of sessions per account [15:32:26] clarification that loss of SID may require resync of dynamic info (uidlist, flags) but unless the uidvalidity changes it doesn't require resync of static info [15:32:27] - timeout [15:32:30] - condstore [15:33:58] --- corby has left: Disconnected [15:35:14] --- hardie has joined [15:35:19] Cyrus points out that currently clients can reconnect without blocking while resynch [15:35:28] The CONDSTORE issue: RECONNECT extends LOGIN to report EXPUNGEs, do we want to do the same to SELECT (i.e. extend CONDSTORE a bit) [15:35:32] Cyrus suggests bandwidth reduction is a worthwhile goal [15:36:58] The timeout issue: what should be the default? Should the server be able to advertise its session expiration timeout? [15:37:08] --- paul.knight has joined [15:38:08] Discussion of implicit checkpoints: how does server know which responses client has received [15:38:39] --- kmurchison has left [15:39:30] Cyrus asks why we need SID if we already require CONDSTORE; client can use CONDSTORE to request changes [15:41:21] The currently opened mailbox is bound to the SID [15:41:43] Alexey: what is that in response to? [15:42:04] In response to the last question from Cyrus [15:42:40] So it just saves SELECT? [15:42:47] Yes [15:43:57] Maybe we can replace SID with mailbox name. But I have to check that nothing else is going to be lost after this change. [15:45:06] Randy notes that if SID only buys you ability to avoid SELECT if you get lucky and reconnect within timeout, then why not come up with another mechanism that allows you to avoid SELECT at all times, so it benefits clients that reconnect 3x week as well as those that happened to get dropped. [15:45:07] the expunge information may be, but if that is done as an extension to condstore... [15:46:28] Eric suggests this is a service provider choice (how much resources to spend and hence how long timeouts are permitted) [15:46:29] Currently the assumption is that the current mailbox state is associated with SID, so on reconnect some responses don't have to be sent to the client. [15:46:44] --- bdesruisseaux has left: Disconnected [15:47:32] Ted suggests loss of connectivity is more compelling problem than reconnect 3x week, notes that LDAP has similar problems [15:48:10] Alexey: I thought there was discussion on adding this to CONDSTORE? [15:48:16] So only CONDSTORE was needed? [15:48:39] Chris would like to do without SID if possible, adds more complexity [15:48:40] Randy: adding what to CONDSTORE? [15:49:03] Alexey: adding extra responses that aren't there now [15:49:36] RECONNECT also combines LOGIN with SELECT [15:49:39] Chris suggests that are approaches that would avoid round-trips by adding atomicity to reconnect [15:50:32] Alexey: right, so if we add the extra responses to CONDSTORE, all that RECONNECT gives you is ability to avoid SELECT, and we can have a mechanism for just that [15:51:41] Chris suggests that today very few clients use PIPELINING, and suggests one reason is the problem that an early command fails but subsequent ones run anyway, atomicity allows sequence to abort [15:52:00] Randy: maybe. Something is still bothering me about state of the selected mailbox. But I can't say what yet [15:52:19] Corby sais big problem is too much information coming back, much of it redundant [15:52:31] I've heard that Apple mail uses PIPELINING [15:53:19] Corby mentioned Thunderbird does too? [15:55:31] Cyrus to look at Alexey's document to see about adding advice on how not to be a stupid client [15:56:00] Draft is 'draft-melnikov-imap-disc-05.txt' [15:56:30] Actually -06 now [15:56:34] --- corby has joined [15:56:41] ------------------- [15:56:43] Take over [15:56:47] TRANSCODING [15:57:29] See email from Lydon on Transcoding (WED 11.10.2003) [15:57:34] if condstore is extended to do expunge bits, it may be wise to include a section describing how it affects the IMAP-DISC discussion [15:58:07] Add MIME type to CHANNELCONVERSION to indiciate capabilities. [15:58:32] Use channel command to do a particular transformation from (a) to (b) [15:59:10] Eric: Recap Vancouver discussion on transcoding. [15:59:26] IMAP server asks for the conversion to be done. [15:59:49] My client always translate(+ b+) to beer, so I get to read from (a) to beer. Distracting. [16:00:09] Phillip: Use URLAUTH to convert. [16:01:07] --- dbrashear has joined [16:01:08] If it's a streaming event use URLAUTH. On normal objects and attachments we had just normal IMAP FETCH [16:01:24] --- ray_atarashi has joined [16:01:29] Some of these formats take many many parameters (eg, video). [16:01:54] Eric: Mime type is not sufficient to do the conversion because more parameters are needed to do proper transformation. [16:01:57] hardie: those autolearning clients can be annoying, yes [16:02:15] Eric; Is this the way we want to go? [16:02:46] Gregg: Is this the consesus on view of streaming retrieval for case A. Use IMAP or RTSP? [16:03:38] What about S/MIME and resigning. [16:03:46] Was discussed in Vancouver. [16:04:03] Eric: Not solvable for enc/dec. But for signing what do we need? [16:04:14] What is on the server, stays on the server. [16:04:33] Server content never changes, but what you fetch may change and may loose it's signature/ [16:04:44] Yes, that may happen [16:05:08] They may or may not now that the content has changed, but they know that it isn't signed. [16:05:53] remove the signature as content is transformed, or leave the sig and leave it broken. [16:06:11] Transform the signed part into a hash? [16:06:48] 822 discussion on signing individual parts and then hashing the tree to confirm individual singed parts. [16:07:33] Use contenttype "multipart/alternative"? [16:08:09] Is there a way to verify the signature with out downloading the entire message. [16:08:31] What is the usecase for transcoding? [16:09:09] Client device can not handle original content of attachment. Client asks server to translate type into something the terminal can display. [16:09:38] Signing is something we need to be aware of, but not somehting we need to solve here. [16:10:10] ERIC: We need a new "Stupid Things" Draft for lemonade to add nits like this to make people aware that we thought about it. [16:10:48] To Eric: maybe this is a part of Lemonade profile? [16:11:09] Isd this a general IMAP problem? Or do other email servers have to deal with this?? [16:11:37] Side Note: Please review OPES re-charter. It is relevant to the work we are doing here and everyone needs to be aware of this [16:12:17] OPES protocol may simplify this problem by using OPES server to resign body/mime parts. [16:13:23] Randy: Cinfirm consensus. for the class of content where the content doesn't need to be streamed, client asks server to FETCH and trnascode it, second, client connects to separate server with URLAUTH and asks tranform server to do the work for it. [16:13:44] Eric: All we care about is how to hack FETCH to do transcoding. [16:14:08] Randy: Usefull for informational note to say: OPES may be usefull aproach to solving this problem. [16:14:31] Send Signing to IMAP-EXT and let those loosers deal with it :) [16:14:52] Pete: Fine to pass over to IMAP-EXT, but they may ask use to work on it. [16:14:58] Do we want to Punt? [16:15:04] Corby: if you want to delay something for long time, that is a sure way :-) [16:16:16] Stephane: Develop CHANNEL document w/o signature problem now so we can move on this for now and deal with edge cases later. [16:16:23] ----------------- [16:16:28] Filter Discussion [16:16:47] (punt should be to S/MIME) [16:17:34] Stephane: Third option: Descide in advance when a new message arives, choose what is being downloaded. [16:18:14] Use SIEVE to filter at the MTA. [16:18:52] PG: Changing the rules of what appears on your mobile can't be done quickly, and is difficult to make retroactive. [16:19:23] Pete: Chage SIVE rule to reannontate the new stuff and reannontate the current mail to take care or retroactive. [16:19:37] Sieve can be used to (a) forward selected messages to mobile, (b) move class of messages out of INBOX and only SELECT that folder, (c) use ANNOTATE to add annotation, mobile device does SEARCh and only selects items with annotation [16:20:17] PG: I'm getting trafic for messages I don't care about. Is this important when terminal gets woken up for trafic I dont want to see [16:21:41] 2 approaches. Filter to new mailboxes or filter on views. [16:21:54] Eric: Rathole we have entered before. [16:22:31] XFILTER is view mech of SQL. [16:23:08] You rmobile rules are relativey static, and even if they do change you don't care about history (retroactgive behaviour) [16:24:18] Is the usecase that you have strong filters that you have for the device and you want to change dynamically. [16:24:30] --- kuewong has left: Disconnected [16:25:06] Unless we have an argument for retroactive functionality, it will not be added to the charter. [16:25:36] Coherent proposal for quick reconnect stratgegy [16:25:48] Added to charter, more discussions needed on ML [16:25:51] ------- [16:25:53] TIMELINE [16:26:00] Dec1: Profile [16:26:07] WGLC: Pull trio [16:26:18] New Docs: S2C Notifications, Transcoding [16:26:28] ---------- [16:26:35] Interim? [16:26:40] Quick Reconnect Options [16:26:54] transcoding requirements [16:27:43] transcoding approaches [16:28:17] Interim: Jan 21-22, 2005 (afternoon-morning) [16:28:26] Host (def, Nortel-Calgary) [16:30:11] Screwup: Jan 20-21, 2005 (Thurs & Friday) [16:30:41] --- ray_atarashi has left [16:32:26] --- randy has left: Disconnected [16:32:36] THANK YOU AND GOOD NIGHT! [16:32:40] --- hildjj has left: Disconnected [16:32:43] --- paul.knight has left [16:32:47] --- resnick has left: Disconnected [16:32:58] --- amelnikov has left [16:33:13] --- hardie has left: Disconnected [16:34:04] --- corby has left: Disconnected [16:35:56] --- pguenther has left [16:37:06] --- Glenn Parsons has left: Disconnected [16:38:50] --- rlbob has left [16:41:21] --- lisa has left: Disconnected [17:58:41] --- resnick has joined [17:58:55] --- resnick has left [18:36:29] --- corby has joined [18:37:32] --- corby has left [18:40:56] --- lisa has joined [18:41:55] --- lisa has left